SAP와 AI 딜리버리를 위한 컨설팅 프레임워크 7가지

SAP나 AI 프로그램이 멈출 때 원인은 대개 구조적이고, 간단한 프레임워크 일곱 가지로 그 원인을 찾을 수 있습니다. 현행 프로세스를 맵핑합니다. RACI로 누가 무엇을 결정하는지 합의합니다. 작업을 비즈니스 역량에 연결합니다. 5 Whys로 근본 원인을 찾습니다. MoSCoW로 요구사항의 순위를 매깁니다. 프로그램을 실제로 멈출 수 있는 것을 기준으로 리스크의 순위를 매깁니다. 단계가 끝날 때마다 제대로 된 사후 검토를 합니다. 이 글은 SAP와 AI 딜리버리를 맡은 프로그램 매니저, 컨설턴트, 스폰서를 위한 것입니다. 아래 표에서 지금 보이는 증상을 찾아, 맞는 프레임워크부터 써 보십시오.

카타르의 한 중견 미디어 기업이 여러 지역에 걸쳐 SAP를 도입하고 있었습니다. 1단계에서 재무와 구매가 가동될 예정이었습니다. 리포팅에 AI 예측 모델도 넣고 싶어 했습니다.

6주 차가 되자 지연이 슬금슬금 생겼습니다. 현업 사용자들은 요구사항에 서명했지만 무엇을 받게 되는지는 여전히 헷갈린다고 했습니다. AI 활용 사례는 제안됐지만, 데이터를 누가 소유하는지, 결과물을 어떻게 쓸지 말할 수 있는 사람이 없었습니다. 사람들은 회의에 늦게 오거나 아예 오지 않았습니다.

어중간한 시기였습니다. 실패라고 부르기엔 이르고, 저절로 나아지리라 믿기엔 늦은 때였습니다.

우리는 프레임워크를 단계별로 적용했습니다. 처음부터 환영받은 것은 아닙니다. 조용한 세션도 있었고, 옆길로 새는 세션도 있었습니다. 그래도 구조가 있으니 일이 쉬워졌습니다. 팀은 제자리를 맴돌기를 멈췄고, 백로그는 다룰 만해졌으며, AI 활용 사례에는 실제 책임자가 생겼습니다. 프로젝트는 계획보다 8주 늦게 Go-Live했습니다. 완벽하지는 않았습니다. 하지만 안착했고, 2단계는 모르는 것이 줄어든 더 나은 기반에서 시작했습니다.

저는 걸프 지역과 유럽 등에서 SAP, Oracle, AI 프로그램을 23년간 수행하며 이 일곱 가지의 변형을 모두 써 왔습니다. 특별한 것은 하나도 없습니다. 문서 작성 연습처럼 하지 않고 규율을 갖고 적용하면 모두 효과가 있습니다.

증상에 맞는 프레임워크를 고르십시오.

보이는 증상	프레임워크	산출물	일반적인 소요
사용자가 요구사항에 서명했지만 여전히 헷갈려 함	1. 현행 프로세스 맵핑	지금 업무가 실제로 이루어지는 방식에 대한 공통 맵	워크숍 3~5일
의사결정이 회의마다 미뤄짐	2. 핵심 의사결정에 대한 RACI	핵심 의사결정 20~30건의 지정된 책임자	워크숍 1회, 이후 집행
스폰서가 “IT 프로젝트”에서 손을 뗌	3. 역량 맵핑	비즈니스 역량으로 보고하는 진행 상황	Fit-to-Standard에 포함
같은 유형의 결함이 계속 되풀이됨	4. 5 Whys	바꿀 수 있는 근본 원인	이슈당 퍼실리테이션 세션 1회
모든 것이 높은 우선순위로 표시됨	5. MoSCoW	현실적인 Must Have 목록을 갖춘 범위 순위	비즈니스와 IT 합동 세션 1회
리스크 로그는 멀쩡해 보이는데 팀은 긴장함	6. 리스크 순위화	프로그램을 멈출 리스크와 성가신 리스크의 별도 목록	매주 30분 검토
단계마다 같은 실수가 되풀이됨	7. 사후 검토	책임자가 있는 변경 3~5건	단계 종료 후 반나절

프로그램 초기에 가장 흔한 실수는 무엇이 있는지 문서화하기 전에 해결책으로 뛰어드는 것입니다. 프로세스 문서는 대개 낡았습니다. 사람들은 일이 실제로 돌아가는 방식이 아니라 돌아가야 하는 방식을 설명합니다. 그 둘 사이의 간극에 구축 문제가 숨어 있습니다.

쓸모 있는 현행 프로세스 맵은 관리하는 사람이 아니라 실제로 일하는 사람들과 함께하는 워크숍 3~5일이 걸립니다. 순서대로 나열한 프로세스 단계, 각 단계에서 쓰는 시스템, 수작업 개입과 임시방편, 부서 간 데이터 흐름이 들어갑니다.

아무도 말하지 않아서 눈에 보이지 않게 된 수작업 단계, 너무 오래 돌아가서 이제는 표준 프로세스로 취급되는 임시방편, 모두가 알지만 아무도 고치지 않은 데이터 품질 문제를 찾으십시오.

카타르에서는 현행 프로세스 맵을 문서가 아니라 사용자 워크숍에서 얻었습니다. 서명된 요구사항을 둘러싼 혼란이 풀리기 시작한 것이 그때였습니다.

제대로 하면 현행 프로세스 맵은 며칠이면 됩니다. 문서 수집 작업으로 다루면 몇 달이 걸리고, 아무도 믿지 않는 결과물이 나옵니다.

의사결정권은 SAP와 AI 프로젝트에서 가장 자주 빠져 있는 구조적 요소입니다. 모두가 의견은 있습니다. 최종 결정을 누가 내리는지는 아무도 모릅니다. 의사결정은 다음 회의로 넘어가고, 그 회의는 운영위원회에 미루고, 운영위원회는 다시 실무 그룹으로 돌려보냅니다.

RACI 매트릭스(Responsible, Accountable, Consulted, Informed)는 모든 의사결정과 산출물에 책임자를 지정합니다. Accountable은 한 명이며, 그 사람이 Responsible을 겸하거나 위임할 수 있습니다. Consulted는 의견을 냅니다. Informed는 결과를 전달받습니다.

실무 방식은 이렇습니다. 현 단계에서 가장 중요한 의사결정 20~30건을 나열하고, 의사결정자가 참석한 자리에서 RACI 워크숍을 엽니다. 배정을 두고 이견이 생겼다면 무언가를 알게 된 것입니다. 거버넌스가 불분명하거나, 권한을 둘러싼 정치적 다툼이 있다는 뜻입니다. 어느 쪽이든 14주 차가 아니라 2주 차에 드러내십시오.

집행이 없는 RACI는 장식입니다. 이름은 실제 권한을 가진 사람과 일치해야 합니다. 책임을 실명이 아닌 직책명에 배정하는 것은 누가 리스크를 소유하느냐는 대화를 피하는 방법입니다.

SAP와 AI 프로그램은 비즈니스가 볼 수 없는 기술 작업을 많이 만들어 냅니다. 지금 만들고 있는 것과 그것이 가져와야 할 성과 사이의 연결이 추상적이 됩니다. 스폰서는 손을 떼고, 실제로는 비즈니스의 결정에서 비롯된 지연이 “IT 프로젝트” 탓이 됩니다.

역량 맵핑은 시스템 기능을 비즈니스 역량, 즉 조직이 할 수 있어야 하는 일에 연결합니다. 구매 오더 워크플로가 구성되었는지를 추적하는 대신, 조직이 공급업체 청구서를 수령 후 3일 이내에 처리할 수 있는지를 추적합니다. 구성은 수단입니다. 역량이 성과입니다.

SAP Activate에서는 이것이 Explore 단계의 Fit-to-Standard 워크숍에 대응합니다. 범위 내 각 프로세스가 하나의 역량이고, SAP 표준과 요구 역량 사이의 각 간극이 하나의 의사결정입니다. 표준을 수용할지, 변형을 구성할지, 확장할지입니다. 대화를 역량 수준에 두면 구축 내내 비즈니스의 관심이 유지되고, 모두가 범위에 있다고 가정했지만 아무도 확인하지 않은 역량이 드러납니다.

같은 종류의 문제가 스프린트나 단계를 넘어 계속 나타난다면, 건건이 패치하는 것은 도움이 되지 않습니다. 원인은 상류에 있습니다.

5 Whys는 가장 간단한 근본 원인 도구입니다. 문제가 왜 일어났는지 묻고, 그것이 왜 일어났는지 다시 물으며, 바꿀 수 있는 것에 이를 때까지 계속합니다. 다섯 번이면 대개 진짜 원인에 닿습니다. 두 번에서는 대개 증상에서 멈춥니다.

데이터 마이그레이션 사례입니다. 시험 적재에 데이터 품질 오류가 있습니다. 이것이 증상입니다. 왜일까요? 원천 추출본의 필드 맵핑이 잘못되었습니다. 왜일까요? 맵핑 명세를 업무 데이터 소유자가 한 번도 검토하지 않았습니다. 왜일까요? 데이터 소유자는 맵핑이 끝난 뒤에야 지정되었습니다. 왜일까요? 계획에 데이터 소유자 참여가 맵핑의 선행 조건으로 들어가 있지 않았습니다. 이것이 근본 원인이며, 해결책은 데이터 수정이 아니라 거버넌스 결정입니다. SAP 데이터 마이그레이션이 실패하는 이유에 관한 제 글을 보면 이 똑같은 연쇄가 얼마나 자주 나타나는지 알 수 있습니다.

1. 01시험 적재 오류증상
2. 02잘못된 필드 맵핑적재는 왜 실패했는가?
3. 03명세 미검토맵핑은 왜 잘못되었는가?
4. 04소유자 지정 지연명세는 왜 검토되지 않았는가?
5. 05계획의 선행 조건 누락소유자는 왜 늦게 지정되었는가?

근본 원인은 데이터 수정이 아니라 거버넌스 결정입니다

비난 없는 자리에서 하는 근본 원인 분석은 솔직한 답을 끌어냅니다. 책임을 따지는 자리에서는 방어적인 태도만 나옵니다. 퍼실리테이터의 역할은 대화를 사람이 아니라 프로세스에 머물게 하는 것입니다. 구조적 사고와 문제 해결에 관한 제 가이드는 “왜”를 묻기 전에 어수선한 문제를 쪼개는 방법을 다룹니다.

SAP와 AI 범위 논의에는 합의의 함정이 늘 있습니다. 아무도 트레이드오프를 하고 싶어 하지 않으니 모든 것이 높은 우선순위가 됩니다. 모든 것이 높은 우선순위이면 아무것도 그렇지 않으며, 구축 팀은 전부 하려 듭니다.

MoSCoW(Must have, Should have, Could have, 이번에는 Won't have)는 선택을 강제합니다. Must Have는 Go-Live에 필요한 최소한입니다. Should Have는 중요하지만 걸림돌은 아닙니다. Could Have는 시간과 예산이 허락하면 바람직한 것입니다. Won't Have는 명시적으로 미룹니다.

규율은 Must Have 선에 있습니다. MoSCoW 작업의 첫 번째 패스는 보통 Must Have에 지나치게 많이 담깁니다. MoSCoW의 출처인 Agile Business Consortium의 DSDM 가이드는 Must Have에 들어가는 노력의 상한을 60%로 두고, 그 이상은 딜리버리를 위험에 빠뜨린다고 경고합니다. 첫 패스와 현실적인 목록 사이의 간극은 대부분 검증되지 않은 가정입니다.

MoSCoW는 비즈니스와 기술 담당자가 같은 자리에서 진행하십시오. 따로 하면 IT의 Must Have 목록과 비즈니스의 Must Have 목록이 서로 양립할 수 없는 것으로 드러나고, 구성이 시작된 뒤에야 누군가 이를 조율합니다.

대부분의 리스크 레지스터는 발생 확률과 영향도로 점수를 매긴 긴 목록이며, 월 단위로 검토하고, 거의 움직이지 않는 RAG 상태가 붙어 있습니다. 리스크를 기록할 뿐 행동을 이끌지는 못합니다.

프로그램을 멈출 수 있는 리스크와 프로그램을 어렵게 만들 뿐인 리스크를 나누십시오. 앞의 그룹에는 책임자, 대응 계획, 주간 가시성이 필요합니다. 뒤의 그룹은 모니터링하면 됩니다.

카타르에서는 리스크 로그가 서류상으로는 멀쩡해 보였지만 모두가 신경이 곤두서 있었습니다. 월간이 아니라 주간으로 검토하는 빠른 리스크 영향도 매트릭스가 진짜 우려를 끌어냈습니다.

레지스터는 멀쩡해 보이는데 팀이 긴장해 있다면 거의 언제나 무언가를 숨기고 있는 것입니다. 레지스터가 진실은 아닙니다. 그 주변의 대화가 진실입니다. “14번 항목의 상태가 어떻습니까?”보다 “어젯밤 무엇 때문에 잠을 설쳤습니까?”를 묻는 주간 검토가 더 많은 것을 드러냅니다. 점수 산정과 책임자 지정에 쓸 템플릿은 제 SAP 리스크 평가 매트릭스에서 볼 수 있습니다.

단계나 Go-Live 이후의 사후 검토는 같은 실수가 다음 단계에서 되풀이되는 것을 막아 줍니다. 일정에 압박이 걸리면 가장 먼저 잘리는 것이기도 합니다.

쓸모 있는 사후 검토는 네 가지를 묻습니다. 무엇을 달성하려 했고 무엇을 달성했는가? 무엇이 잘되었고 반복해야 하는가? 무엇이 잘못되었고 원인은 무엇인가? 다르게 한다면 무엇을 바꾸겠는가? 일어난 일을 요약한 문서가 아니라, 책임자가 있는 구체적 실행 항목 3~5건으로 끝나야 합니다.

흔한 실패는 팀이 결정을 검토하기보다 변호하는 정당화 작업이 되는 것입니다. 미래 지향으로 유지하십시오. 질문은 6주 차의 지연을 누가 일으켰느냐가 아닙니다. 다음 단계에서 그런 지연을 막으려면 어떤 구조적 변화가 필요하냐입니다.

카타르에서는 사후 검토를 Go-Live 직후에 열었고, 비난이 아니라 실행에 초점을 맞췄습니다. 2단계가 더 나은 기반에서 시작한 데는 이것이 큰 몫을 했습니다.

프레임워크는 달라지지 않았습니다. 적용하는 방식은 세 가지 면에서 달라졌습니다.

초안 작성은 빨라졌지만 경청은 그렇지 않습니다. AI 도구는 이제 워크숍 녹취록과 프로세스 문서를 몇 분 안에 1차 맵으로 만들어 주고, SAP Cloud ALM은 Fit-to-Standard 녹취록에서 요구사항 초안을 작성할 수 있습니다. 워크숍 자체는 예전과 똑같이 시간이 걸립니다. 경청이 핵심이기 때문입니다. 초안 작성에서 아낀 시간은 그 맵을 사람들과 함께 검증하는 데 써야 합니다.

RACI 초안은 완성된 채 나오지만, 어려운 부분은 그대로 남습니다. 범용 AI 어시스턴트는 헌장과 작업 패키지 목록만 주면 1분 만에 RACI를 만들어 냅니다. 규율은 협상으로 옮겨 갑니다. 모든 칸마다 권한과 에스컬레이션에 대한 진짜 대화가 필요합니다. 초안을 만드는 데서 아낀 시간은 그 어려운 대화에 써야 합니다.

AI가 자리에 있으면 MoSCoW가 더 어려워집니다. AI가 매긴 요구사항 순위는 그럴듯하고 깔끔하지만, 현지의 정치 상황에 대해서는 자주 틀립니다. 이를 검증 없이 받아들이는 컨설턴트는 백지에서 시작하는 컨설턴트보다 더 나쁜 우선순위 목록을 만듭니다. AI 초안은 출발점으로 다루고, 정답으로 삼지 마십시오.

이 프레임워크들 위에서 발휘하는 판단력의 가치는 오히려 커졌습니다. 컨설턴트로서 이런 역량을 키우고 있다면, SAPopedia의 커리어 경로가 SAP 커리어의 단계마다 어떤 역량이 중요한지 정리해 줍니다.

컨설팅 프레임워크란 무엇이며 SAP 프로젝트는 왜 이를 사용합니까?

분석, 의사결정, 문제 해결을 위한 구조화된 접근법입니다. SAP와 AI 프로그램에서는 업무 리더, 아키텍트, 프로젝트 매니저, 통합 담당자, 스폰서에게 공통의 방법을 줍니다.

공통의 방법이 없으면 각 그룹은 제각각의 사고 모델로 돌아갑니다. 프로세스 성과, 아키텍처, 아니면 일정과 리소스입니다. 현행 프로세스 맵핑, RACI, MoSCoW 같은 프레임워크는 의견 차이를 명시적으로 드러내고 해소할 수 있게 합니다. SAP Activate는 그 자체가 단계, 게이트, 산출물을 위한 프레임워크입니다. 이 일곱 가지는 그 안에서 작동하며, 방법론만으로는 풀리지 않는 구조적, 인적 문제를 다룹니다.

SAP 구축에서 현행 프로세스 맵핑은 어떻게 진행합니까?

구성을 시작하기 전에, 기존 문서가 말하는 방식이 아니라 프로세스가 실제로 돌아가는 방식을 문서화합니다. 프로세스를 운영하는 사람들과 워크숍을 열어 만드십시오. 단계, 시스템, 인수인계, 수작업 개입, 임시방편을 다룹니다.

이 맵은 SAP Activate의 Explore 단계에 있는 Fit-to-Standard 워크숍으로 이어지며, 거기서 현행 상태가 SAP 표준 프로세스와 비교하는 기준선이 됩니다. 워크숍이 시작되기 전에 끝내십시오. 그렇지 않으면 갭 분석이 가정 위에 서게 됩니다.

MoSCoW 우선순위화란 무엇이며 SAP 프로그램에서는 언제 사용합니까?

MoSCoW는 요구사항을 Must have, Should have, Could have, 이번에는 Won't have로 분류합니다. Must Have는 Go-Live의 최소 요건이고, Won't Have는 명시적으로 제외해 슬그머니 되돌아오지 못하게 합니다.

가장 유용한 때는 Fit-Gap 결과가 확장 결정을 좌우하는 Explore 단계, 그리고 결함과 개선 요청이 구축 시간을 두고 경쟁하는 Realize 단계입니다. 흔한 문제는 첫 패스에서 Must Have가 너무 많다는 것입니다. DSDM은 Must Have에 노력의 60%를 넘기지 말라고 권고합니다. 비즈니스와 IT가 같은 세션에 앉아 퍼실리테이터가 하나하나 따져 물으면 그 선에 도달합니다.

SAP 프로젝트에서 효과적인 리스크 검토는 어떻게 진행합니까?

상태 보고가 아니라 대화로 진행합니다. 레지스터를 훑기 전에 “레지스터에 없는, 이번 주 가장 큰 우려는 무엇입니까?” 같은 열린 질문으로 시작하십시오.

우선순위가 높은 리스크마다 무엇이 바뀌었는지, 어떤 조치를 했는지, 추세가 나아지는지, 대응 계획이 여전히 맞는지 물으십시오. 몇 주째 조치 없이 같은 등급에 머무는 리스크는 과소평가된 경우가 많습니다. 활발한 단계에서는 매주 검토하고, 운영위원회에는 전체 레지스터가 아니라 상위 5개를 상태와 다음 조치와 함께 보여 주십시오.

SAP Go-Live 이후 유용한 사후 검토란 무엇입니까?

다음 단계를 위한 구체적이고 실행 가능한 변화입니다. 일어난 일을 요약한 것은 기록이지 사후 검토가 아닙니다.

무엇을 이루려 했는지, 무엇을 이뤘는지, 무엇이 통했고 무엇이 통하지 않았는지를 다룹니다. “리소스가 부족했다” 같은 표면적 설명 아래로 파고드십시오. 리소스 계획이 틀렸는지, 범위가 틀렸는지, 에스컬레이션 경로가 끊겼는지를 따져 봅니다. 책임자와 기한이 있는 변경 3~5건으로 마무리하십시오.

컨설팅 프레임워크는 SAP 환경의 AI 도입에 어떻게 도움이 됩니까?

AI 프로젝트는 SAP 프로젝트와 같은 구조적 이유로 실패하고, 몇 가지가 더해집니다. 소유자가 없는 데이터, 정의되지 않은 성공 지표, 결과물을 바탕으로 행동하는 합의된 프로세스의 부재입니다.

현행 프로세스 맵핑은 모델에 필요한 데이터를 누가 소유하고 그 품질이 어떤지 보여 줍니다. RACI는 누가 결과물을 검증하고, 누가 그에 따라 행동할지 결정하며, 틀렸을 때 누가 책임지는지 답해 줍니다. MoSCoW는 필수 활용 사례와 흥미로운 활용 사례를 구분합니다. 열다섯 개를 한꺼번에 시작하지 말고, 책임자와 성공 지표가 분명한 필수 활용 사례 두세 개로 시작하십시오.