SAP Fiori Role 설정 — 권한 설계와 사용자 교육의 짝패
5편에서 데이터소스의 동기화 전략을, 6편에서 운영 직후 일탈 사례를 봤다. 7편의 질문은 다르다 — 그래서 누가 그 시스템을 어떻게 쓰는가. PCE 전환 프로젝트에서 Fiori Role 설계와 사용자 교육은 서로 다른 작업처럼 보이지만, 실제로는 같은 결정의 두 얼굴이다. 한 그룹사 PCE 전환 사례에서, RZ040부터 사용자 매뉴얼까지 4단 매핑이 어떻게 변화관리 자체가 되었는지 본다.
RZ040 — Role 설계가 변화관리의 출발점이다
Role은 권한의 명단이 아니라 변화관리 대상자의 명단이다.
RZ040(사용자 Role 정의서)은 SAP에서 누가 무엇을 할 수 있는가를 모듈 단위로 정리한 산출물이다. 본 프로젝트의 As-is 분석 폴더에는 RZ040이 FI·MM·SD·CO·PP·QM·IM·EX 8개 모듈로 각각 잡혀 있다. 8개 파일이 따로 분리된 것은 우연이 아니다 — 모듈마다 권한 단위가 다르고, 변화관리 강도도 다르다. FI(재무)의 Role 한 줄과 PP(생산)의 Role 한 줄은 같은 무게로 다뤄질 수 없다.
Role은 본질적으로 한 사람의 하루를 정의한다. SD Role을 받은 영업담당자는 그 안에서만 화면을 본다. PP Role을 받은 생산담당자는 다른 화면을 본다. 그러니까 Role 정의서가 모듈별로 완성되는 순간, 그 모듈을 쓰는 사용자 명단도 함께 고정된다. Role 정의가 끝나는 순간 변화관리 대상자 명단이 함께 끝난다 — Role 한 줄 옆에 어떤 부서, 어떤 역할의 사용자가 따라붙는지 채워두면 변화관리 부서는 그 명단으로 교육 계획을 짜기 시작한다.
Catalog Group → Tile — Role을 화면 위에 펼치기
Catalog Group은 Role과 Tile의 다리다.
Fiori 환경에서 사용자가 실제로 보는 것은 Tile이다. Tile은 SAP 트랜잭션이나 앱을 화면 위 작은 카드로 펼친 단위다. Role이 정의됐어도, 그 Role에 어떤 Tile이 붙는가가 따로 매핑되어야 한다. 그 다리가 Catalog Group이다 — Role에 Catalog Group을 묶고, Catalog Group에 Tile을 묶는 2단 구조다.
이 매핑은 한 번에 끝나지 않는다. 본 프로젝트의 Role 카탈로그 타일 리스트가 세 버전(8월·9월 v1.0 두 버전)에 걸쳐 누적된 것이 그 증거다 — Role 설계가 진화하면서 어떤 Tile을 누가 보는가도 함께 진화한다. 이 진화가 8편(Cutover) 직전까지 이어지는 게 정상이다. Tile이 보이지 않으면 Role이 정의돼 있어도 사용자에게는 의미가 없다. 권한이 살아 있어도 화면이 안 뜨면 일은 멈춘다. K4 Fiori Role Tile Check List가 별도 산출물로 잡혀 있는 이유는, 이 매핑의 마지막 점검이 오픈 직전에 반드시 필요하기 때문이다.
사용자 매뉴얼 — Role × Tile의 교육 형태
사용자 매뉴얼은 Role을 받은 사용자에게 전달되는 물리적 형태다.
본 프로젝트의 사용자 매뉴얼 폴더 구조를 보면 왜 매뉴얼이 변화관리의 결과물인지 분명해진다. 모듈별 폴더(FI/MM/SD…) 안에 기준정보관리, 총계정원장관리, 비즈플레이 같은 업무 단위로 매뉴얼이 정렬되어 있다. 이 업무 단위가 Tile 묶음에 그대로 대응한다. 즉 매뉴얼 한 권 = Tile 한 묶음 = Role 한 부분이다.
이 짝패가 무너지면 사용자 교육이 불완전해진다. Role은 정의됐는데 그에 해당하는 매뉴얼이 없거나, 매뉴얼이 있는데 Role과 매핑되지 않는 경우 — 둘 다 교육 범위의 공백을 만든다. 매뉴얼 작성이 늦어진다는 것은 사용자 교육 범위가 불확실하다는 뜻과 같다. 본 프로젝트의 매뉴얼 폴더에 비즈플레이 기본 세팅, 카드영수증 경비처리(PC), 카드영수증 경비처리(모바일), 인택스 경비처리 식으로 사용자가 실제로 만나는 화면 단위까지 매뉴얼이 쪼개진 것이 정상 패턴이다. 매뉴얼이 Tile 단위로 작성될 때 변화관리는 이미 사용자 손 안에서 일어난다.
| 산출물 | 입력 | 출력 |
|---|---|---|
| RZ040 Role 정의서 | As-is 업무 분석 | 모듈별 Role + 사용자 명단 |
| Catalog Group | Role | Tile 묶음 |
| Tile Check List | Catalog Group | 화면 단위 권한 매핑 |
| 사용자 매뉴얼 | Tile | 사용자 교육 packet |
한 줄로
Role 설계는 권한 명단이 아니라 변화관리 명단이다. RZ040 → Catalog Group → Tile → 매뉴얼의 4단 매핑이 일관되게 작동하면, 사용자 교육은 별도 단계가 아니라 Role 설계의 자연스러운 연장이 된다. 반대로 매핑 한 단이 끊기면 Cutover 직전에 누가 무엇을 못 한다는 이슈가 모듈별로 터진다. 이 짝패가 D-Day 운영에서 어떻게 작동하는지는 8편(Cutover & Go-Live)에서 다시 다룬다.

댓글
댓글 쓰기