16-M. 본사 관리 기능 상세

군집	기능	주 화면
M-1 매장 실체·온보딩	3	SC-H05 매장 마스터·온보딩
M-2 모니터링	4	SC-H01 KPI · SC-H02 이상징후 · SC-H03 드릴다운 · SC-H04 브리핑
M-3 표준·권한	3	SC-H06 배포 · SC-H07 권한 · SC-H11 공지
M-4 지원·인센티브	2	SC-H14 지원 프로그램 · SC-H19 기여도
M-5 플랫폼	5	SC-H09 모델품질 · SC-H10 지식베이스 · SC-H12 개발자포털 · SC-H16~18

16-M. 본사 관리 — RIAHN CONNECT 기능 상세

M-1. 매장 실체·온보딩 — 3개

RC-M-17매장(가맹점) 마스터1차

R5 AdminSC-H05

목적: 490개 매장을 등록하고 관리한다. M-01이 다루는 매장의 등록 원장
트리거: 개점, 이전, 계약 변경, 폐점
입력: 매장 코드 체계 · 계층(직영/가맹·지역) · 개점일 · 계약 정보 · 사업자등록번호
규칙: 코드 체계와 계층을 정의한다 — 지역·유형별 집계(M-01)가 여기에 의존한다. 개설 시 표준 마스터를 복제해 초기 설정을 채운다(M-06). 폐점 시 데이터 처리 절차가 필요하다 — 고객·매출을 어디까지 보존할지, 미사용 회원권 잔액(C-20)을 어떻게 처리할지
결과: 매장 마스터 확정, 모든 매장 단위 집계의 기준
예외: 폐점 매장의 회원권 잔액은 고객에게 채무가 남는다. 인근 매장 이관인지 환불인지 정해야 한다
미결: 폐점 시 회원권 잔액 처리 (이관 vs 환불) — 선불업 규제와 맞물린다

RC-M-19폐점 처리1차

R5SC-H05

목적: 문 닫는 매장을 정리한다. 고객에게 채무가 남는다는 점이 핵심
트리거: 폐점 결정
입력: 매장 데이터 · 미사용 회원권·포인트 잔액(C-20) · 소속 디자이너 · 계정
규칙: 처리 항목이 넷이다. ①고객·매출 데이터 보존 범위 ②회원권 잔액을 인근 매장으로 이관할지 환불할지 ③소속 디자이너 이동·퇴사(F-15) ④계정 비활성. 잔액 처리가 가장 무겁다 — 폐점해도 고객이 선불한 돈은 남아 있고, 인근 매장 이관은 사용가능범위(C-04)가 매장전용이면 불가능하다
결과: 매장 비활성, 잔액 처리, 계정 정리
예외: 데이터를 지우면 과거 매출 집계가 깨진다. 매장은 비활성으로 두고 이력은 남긴다
미결: 회원권 잔액 처리 (이관 vs 환불) — 선불업 규제와 맞물린다

RC-M-05매장 온보딩 관리1차

R5SC-H05

목적: 새 매장이 실제로 쓸 수 있는 상태가 되기까지를 관리한다
트리거: 신규 매장 도입 결정
입력: 온보딩 단계 정의 · 설정 완료 여부(K 도메인) · 이관 진행(I-07·I-09)
규칙: 단계별 진행 상태를 추적한다 — 계약 → 마스터 복제 → 설정 입력 → 데이터 이관 → 병행 운영 → 전환. K-13·K-14·K-15가 미설정이면 발송·회원권·결제가 막히므로 체크리스트에 넣는다. 이관율(I-09)이 기준에 못 미치면 다음 단계로 못 넘어가게 한다
결과: 온보딩 진행 상태, 전환 가능 판정
예외: 실증 10개와 확산 490개의 절차가 다르다. 확산 단계에서는 자동화 비중을 높여야 한다

RC-M-03매장 상세 드릴다운1차

R4/R5SC-H03

목적: 특정 매장 하나를 파고든다
트리거: KPI 목록에서 매장 선택, 이상징후 알림에서 진입
입력: 매장 단위 지표(D 도메인) · 이력 · 온보딩 상태 · 이슈
규칙: 매장 화면(SC-M20)과 같은 지표를 보되 본사 관점의 비교값을 함께 낸다 — 전국 평균, 동일 지역, 동일 규모 대비. 개인정보는 집계로만 본다
결과: 조회. 지원 제안(M-15)·에스컬레이션(F-12)으로 진입
예외: 이관이 덜 된 매장은 지표가 불완전하다. 이관율을 함께 표시해 오판을 막는다
미결: "개인정보는 집계로만 본다"는 규칙을 지킬 수 있는가 — 본사가 개별 디자이너 성과를 보기로 결정됐다(15번 5장 27번). 디자이너는 개인정보 주체이므로 이 규칙과 정면으로 부딪힌다

M-2. 모니터링 — 4개

RC-M-01전 매장 KPI 대시보드1차

R4/R5SC-H01

목적: 490개를 한 화면에서 훑고 이상한 곳을 찾는다
트리거: 로그인, 정기 조회
입력: 매장별 핵심 지표(D-01·D-06) · 매장 마스터(M-17) · 목표(D-15)
규칙: 매장 목록에 지표를 붙이고 정렬·필터로 이상한 곳을 찾게 한다 — 490행을 눈으로 훑는 건 불가능하다. 지역·유형·규모로 묶어 보고, 이상 표시를 시각으로 준다. 실증 단계(10~30개)와 확산 단계의 밀도가 다르므로 뷰를 나눈다
결과: 조회, 드릴다운(M-03) 진입
예외: 신규·이관 중 매장은 지표가 불완전하다. 비교에서 제외하거나 별도 구간으로 둔다

RC-M-02이상징후 감지·알림2차

자동 → R4SC-H02

목적: 490개 중 문제 있는 곳을 자동으로 골라낸다(S16)
규칙: 매출 급락 등을 감지해 우선순위를 매긴다. 매장 단위 D-09와 기준을 맞추되 본사는 매장 간 상대 비교를 함께 본다

RC-M-04슈퍼바이저 방문 브리핑2차

R4SC-H04 (D6 모바일)

목적: 매장 방문 전에 무엇을 볼지 준비한다(S17)
규칙: 방문 전 자동 브리핑과 체크리스트를 낸다. 현장에서 쓰므로 모바일(D6) 이다

RC-M-09모델 품질 모니터링2차

R5SC-H09

목적: 추천·예측이 계속 맞고 있는지 본다
규칙: 정확도 추이와 드리프트를 본다. 학습 데이터 제외 반영(J-12) 현황도 여기서 확인한다

M-3. 표준·권한 — 3개

RC-M-06표준 마스터 배포1차

R5SC-H06

목적: 본사 표준을 490개에 내린다
트리거: 표준 메뉴·정책 개편, 신규 매장 개설
입력: 표준 메뉴(K-03) · 온톨로지 · 자동화 기본값(K-12) · 배포 대상 매장
규칙: 덮어쓰기 여부와 잠금 항목을 항목별로 정한다 — 이게 이 기능의 본체다. 매장이 추가한 메뉴를 지울지 병합할지, 매장이 조정한 임계값을 되돌릴지. 배포 전 영향 미리보기(몇 개 매장의 어떤 값이 바뀌는지)를 보여준다. 단계적 배포와 롤백이 가능해야 한다
결과: 표준 배포, 매장별 반영 결과
예외: 배포 실패 매장이 생긴다. 부분 반영 상태로 두지 않는다
미결: 항목별 잠금 범위 — K 도메인의 "설정 잠금 범위 정의" 후보와 같은 문제

RC-M-08권한·계정 통합 관리1차

R5SC-H07

목적: 전사 역할 체계를 정하고 계정을 관리한다
트리거: 역할 체계 설계, 본사 인원 변동, 다중 매장 소속 처리
입력: 역할 정의(J-04) · 본사·매장 계정 · 다중 매장 소속(F-14)
규칙: 역할 체계는 본사가 정의하고 매장은 그 안에서 부여만 한다(K-07). 다중 매장 근무 디자이너(F-14)의 소속을 여기서 처리한다. 권한 변경은 감사 로그(J-05)에 남는다
결과: 역할 체계, 계정 권한
예외: 본사 계정이 매장 데이터를 보는 범위를 명시한다. 전 매장 열람은 감사 대상

RC-M-13본사 공지 배포1차

R5SC-H11

목적: 매장에 알리고 읽었는지 확인한다
트리거: 정책 변경, 공지 사항 발생
입력: 공지 내용 · 대상 매장 · 확인 요구 여부
규칙: 대상을 지정해 보내고 확인 여부를 추적한다. 확인이 필요한 공지는 매장 대시보드(SC-M02)에 고정된다. 발송은 E-14 인프라를 쓰며 정보성으로 분류된다(K-06)
결과: 공지 전달, 확인 현황
예외: 확인율이 낮으면 재발송·상위 통보(K-17)로 이어진다

M-4. 지원·인센티브 — 2개

RC-M-15지원 프로그램 제안·신청2차

R1 신청SC-M41 SC-M43

목적: 진단 결과를 근거로 본사가 매장을 돕는다. 데이터가 실제 지원으로 이어지는 통로
트리거: 진단 결과 도출(M-03), 매장 신청
입력: 매장 진단 점수 · 추천 액션 · 지원 유형(마케팅비 매칭·교육 우선권) · 예산
규칙: 흐름이 넷이다. ①진단 기반 추천 액션 제시 ②지원 제안 ③매장 신청(SC-M41) ④본사 심사·예산 배분·집행 추적(SC-H14). 심사는 승인 워크플로를 타고 예산 한도 안에서 배분한다
결과: 지원 확정, 집행 이력
예외: 신청이 예산을 초과하면 우선순위 기준이 필요하다

RC-M-18지원 심사·예산 배분2차

R5SC-H14

목적: 매장 신청을 심사하고 예산을 나눈다
트리거: 매장 신청 접수(M-15)
입력: 신청 건 · 예산 한도 · 매장 진단 점수(M-03) · 우선순위 기준
규칙: 승인 워크플로를 타고 예산 한도 안에서 배분한다. 신청이 예산을 초과하면 우선순위 기준이 필요하다 — 진단 점수가 낮은 곳을 도울지, 효과가 클 곳을 도울지는 정책 판단이다. 집행 결과를 추적해 다음 배분에 반영한다
결과: 심사 결과, 예산 배분, 집행 이력
예외: 탈락 매장에 사유를 회신하지 않으면 불신이 쌓인다
미결: 신청 초과 시 우선순위 기준