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)에서 다시 다룬다.
댓글
댓글 쓰기