SAP Consulting · 방법론Vol. 01요구사항 도출현업의 말을 요구사항으로 바꾸는 법SAP 프로젝트에서 가장 자주 무너지는 지점은 기술이 아니다.현업이 원하는 것을 제대로 파악하지 못한 채 구축을 시작하는 순간이다.이명진 · 다온컨설팅·SAP FI 컨설턴트 · 17년·S/4HANA”현업은 결과를 안다. 하지만 그 결과를 어떻게 만드는지는 모른다.컨설턴트의 역할은 그 사이의 언어를 번역하는 것이다.”SAP 프로젝트 현장에서 반복적으로 목격하는 장면이 있다. 현업 담당자가 회의실에 앉아 이렇게 말한다. “지금 이 리포트가 맞지 않아요. 고쳐주세요.” 컨설턴트는 고개를 끄덕이고 사무실로 돌아가 요구사항 정의서를 작성하기 시작한다. 그리고 몇 주 뒤, 개발이 완료된 화면을 보여주면 현업은 다시 말한다. “이게 아닌데요.”이 실패의 원인은 개발자의 실수도, 컨설턴트의 무성의도 아니다. 현업은 애초에 원하는 결과는 알지만, 그것을 만들기 위한 요구사항을 언어화하는 능력이 없다. 이것은 당연한 일이다. 그것이 바로 컨설턴트가 필요한 이유다.문제는 많은 컨설턴트가 이 간극을 메우지 않은 채 현업의 말을 그대로 요구사항으로 기록한다는 것이다. “리포트를 수정해 달라”는 말이 요구사항 정의서에 그대로 올라간다. 그리고 프로젝트는 예측 가능한 방식으로 흔들린다.Output First: 결과물에서 시작하라나는 현업 인터뷰를 시작할 때 요구사항을 묻지 않는다. 대신 현재 사용하는 결과물을 먼저 본다. 그들이 매일 열어보는 리포트, 그들이 월말에 출력하는 엑셀, 그들이 팀장에게 보고하는 화면이다.결과물을 먼저 보는 데는 이유가 있다. 현업이 무엇을 원하는지 말로 설명하지 못하더라도, 지금 무엇이 불편한지는 결과물 앞에서 자연스럽게 드러난다. “이 숫자가 왜 이렇게 나오는지 모르겠어요”, “이 항목이 여기 있으면 안 되는데”라는 말들이 나오기 시작한다. 이것이 진짜 요구사항의 원석이다.5단계 프레임워크17년간의 SAP FI 프로젝트 경험에서 정제된 요구사항 도출 방식이다. 각 단계는 순서대로 진행되며, 이전 단계 없이 다음 단계로 넘어가지 않는다.1Output First — 결과물부터 본다현업이 현재 사용하는 리포트, 화면, 산출물을 먼저 확인한다. 요구사항을 묻기 전에 그들이 실제로 보고 있는 것을 함께 본다.2Gap 발굴 — 불편함과 빠진 것을 묻는다결과물을 보며 “이 부분이 맞지 않는 게 있나요?”, “빠진 정보가 있나요?”를 묻는다. ‘원하는 것’이 아닌 ‘불편한 것’을 질문한다.3초안 시각화 — 말이 아닌 화면으로 보여준다정리된 내용을 바탕으로 초안 화면이나 프로세스 흐름을 먼저 만들어 보여준다. 현업은 텍스트보다 화면 앞에서 더 정확하게 반응한다.4영향도 공유 — 변경이 어디까지 닿는지 설명한다요청된 변경이 연결된 프로세스, 다른 부서, 시스템 인터페이스에 어떤 영향을 주는지 명확히 전달한다. 이 단계에서 많은 요구사항이 조정된다.5확정 후 구축 — 합의된 것만 만든다화면과 프로세스가 확정된 이후에 구축을 시작한다. 구축 중 요구사항이 바뀌는 것을 구조적으로 차단한다.왜 이 순서인가이 프레임워크의 핵심은 현업에게 언어화의 부담을 주지 않는다는 데 있다. 대부분의 컨설턴트는 현업에게 “원하시는 게 뭔가요?”라고 묻는다. 이 질문은 현업을 곤란하게 만든다. 그들은 SAP의 구조를 모르고, 가능한 것과 불가능한 것을 구분하지 못한다.반면 결과물을 먼저 보여주고 “이게 맞나요?”를 묻는 방식은 현업이 가장 잘하는 것, 즉 검토와 반응을 하게 만든다. 사람은 빈 종이 앞에서 말하는 것보다 이미 그려진 그림 앞에서 훨씬 정확하게 자신이 원하는 것을 표현한다.핵심 원칙요구사항은 묻는 것이 아니라 끌어내는 것이다.현업의 언어는 ‘불편함’이다. 컨설턴트의 언어는 ‘설계’다.이 둘을 연결하는 것이 진짜 컨설팅이다.영향도 공유가 빠지면 생기는 일4단계인 영향도 공유를 생략하는 경우를 자주 본다. 현업이 원하는 대로 초안을 만들고 확정을 받은 뒤 구축에 들어가는데, 구축이 끝나고 나서야 연결된 프로세스가 깨졌다는 것을 발견한다.영향도는 단순히 기술적인 설명이 아니다. 현업이 요구사항의 trade-off를 이해하게 만드는 과정이다. “이렇게 바꾸면 A 리포트가 원하시는 방식으로 나오지만, B 프로세스에서 수작업이 한 단계 늘어납니다.” 이 설명을 들은 현업은 선택을 한다. 그 선택이 진짜 확정이다.이 방법론이 만드는 차이구축 완료 후 “이게 아닌데요”라는 말이 나오는 프로젝트와 나오지 않는 프로젝트의 차이는 기술 역량이 아니다. 요구사항을 확정하는 과정의 구조가 다르다.현업이 화면 앞에서 직접 확인하고, 영향도를 이해한 뒤 합의한 요구사항으로 구축된 시스템은 인수인계 후에도 흔들리지 않는다. 현업이 스스로 결정한 시스템이기 때문이다.컨설턴트의 역할은 현업보다 SAP를 더 잘 아는 것이 아니다. 현업이 자신의 업무를 시스템으로 설명할 수 있도록 돕는 것이다. 그 번역
의 질이 프로젝트의 성패를 가른다.#SAP#요구사항#FI컨설팅#S4HANA#프로젝트방법론다온컨설팅 · 이명진
