안녕하세요, 비즈니스 혁신 파트너 BSG입니다.

SAP 구축 프로젝트를 겪어본 분이라면 익숙한 장면이 있습니다.

몇 달 동안 순조로웠습니다.
설계도 끝났고, 개발도 마쳤고, 모듈별 테스트도 통과했습니다.
일정표에는 초록색 불이 켜져 있었죠.

그런데 오픈 2주 전, 갑자기 문제가 쏟아지기 시작합니다.
해결해야 할 목록이 하루에도 수십 개씩 늘어나고, 회의가 잦아지고, 야근이 시작됩니다.
그리고 누군가 조심스럽게 "오픈 연기"라는 단어를 꺼냅니다.

왜 문제는 늘 마지막에 한꺼번에 몰려올까요? 오늘은 그 구조를 들여다보겠습니다.

문제가 늦게 생기는 게 아닙니다, 늦게 보이는 겁니다

먼저 짚고 싶은 게 있습니다.

오픈 직전에 쏟아지는 문제들은 대부분 그때 생긴 게 아닙니다.
이미 몇 달 전부터 있었는데, 그때서야 드러난 것입니다.

프로젝트 후반부에 처음으로 일어나는 일들이 있거든요.
실제 데이터가 들어오고, 모든 모듈이 한 번에 연결되고, 현업이 진지하게 시스템을 써보고, 실제 권한으로 로그인해봅니다.
이 모든 게 마지막 몇 주에 겹칩니다.

그러니 문제도 마지막 몇 주에 한꺼번에 보이는 겁니다.

이유 ① — 따로는 되는데, 이어 붙이면 안 됩니다

모듈별 테스트는 대개 잘 통과합니다.
영업은 영업대로, 물류는 물류대로, 회계는 회계대로요.

그런데 실제 업무는 모듈 하나로 끝나지 않습니다.
판매 오더가 들어오면 출하가 되고, 청구가 나가고, 회계 전표가 만들어지고, 원가에 반영됩니다.
하나의 흐름이 네다섯 개 모듈을 관통하죠.

각 구간이 따로 정상이어도, 이어 붙였을 때 앞 단계의 값이 뒤 단계의 기대와 어긋나는 경우가 생깁니다.
그리고 이 연결 테스트는 대개 통합 테스트 단계에서야 처음 제대로 해봅니다.

이유 ② — 테스트 데이터는 깨끗하고, 진짜 데이터는 지저분합니다

개발과 테스트 단계에서는 대개 만들어낸 데이터를 씁니다.
필수 항목이 다 채워져 있고, 중복도 없고, 규칙도 잘 지킨 깔끔한 데이터죠.

그러다 기존 시스템에서 실제 데이터를 이관해 넣는 순간 상황이 달라집니다.
같은 거래처가 세 개씩 있고, 단위가 빠진 자재가 있고, 10년 전 단종된 품목이 살아 있습니다.

지난 글에서 다룬 마스터 데이터 이야기가 바로 여기서 청구서를 내밉니다.
깨끗한 데이터에서 잘 돌던 시스템이, 진짜 데이터 앞에서 멈추는 거죠.

이유 ③ — 현업이 마지막에 처음 제대로 봅니다

가장 흔하고, 가장 뼈아픈 이유입니다.

프로젝트 초반 설계 단계에서 현업 담당자들은 바쁩니다.
본업이 있으니까요.
그래서 워크숍에 대리로 참석하거나, 중간에 빠지거나, "알아서 잘 해주세요"라고 맡깁니다.

그러다 사용자 테스트 단계에서 실제로 화면을 써보고 이렇게 말합니다.
"이거 우리가 일하는 방식이 아닌데요."

이 말이 오픈 2주 전에 나오면 대응할 시간이 없습니다.
같은 말이 설계 단계에서 나왔다면 몇 시간짜리 수정이었을 텐데요.

이유 ④ — 예외는 아무도 적어두지 않았습니다

설계 단계에서는 주로 정상 흐름을 다룹니다.
주문이 들어오고, 출하하고, 청구하는 기본 과정이요.

그런데 실제 업무의 상당 부분은 예외입니다.
반품, 부분 출하, 단가 소급, 월말 역분개, 해외 법인 간 거래, 고객별 특수 조건. 현업은 이걸 매일 처리하지만, 너무 익숙해서 말로 꺼내지 않습니다.

그러다 테스트에서 누군가 "그럼 반품은요?"라고 묻는 순간, 아무도 설계하지 않은 영역이 드러납니다.

이유 ⑤ — 권한은 늘 마지막에 붙입니다

개발과 테스트 단계에서는 대개 모든 권한을 가진 계정으로 작업합니다.
그래야 빠르니까요.

그러다 오픈을 앞두고 실제 사용자별 권한을 넣으면, 갑자기 안 되는 게 생깁니다.
조회는 되는데 저장이 안 되고, 승인 버튼이 안 보이고, 필요한 보고서에 접근이 막힙니다.

기능이 문제가 아니라 권한이 문제인데, 이것도 마지막에야 발견됩니다.

그럼 어떻게 앞당길 수 있을까

핵심은 하나입니다. 마지막에 몰려 있는 '처음 해보는 일들'을 앞으로 당기는 것.

흐름 단위로 일찍 테스트합니다.
모듈별 테스트를 끝낸 뒤 통합하는 게 아니라, 주문부터 회계까지 이어지는 대표 시나리오 몇 개를 초기부터 반복해서 돌려봅니다.
연결에서 생기는 문제를 몇 달 먼저 만날 수 있습니다.

실제 데이터를 일찍, 여러 번 넣어봅니다.
이관 리허설을 오픈 직전에 한 번 하는 대신, 프로젝트 중간중간 반복합니다.
할 때마다 데이터 문제가 드러나고, 정리할 시간이 생깁니다.

핵심 현업을 계약 조건처럼 확보합니다.
프로젝트에 참여할 현업 담당자와 투입 비율을 시작 전에 정하고, 그 시간을 실제로 비워줍니다.
이건 프로젝트팀이 아니라 경영진이 결정해줘야 하는 일입니다.

예외 목록을 따로 만듭니다.
정상 흐름 설계가 끝나면, "평소와 다르게 처리하는 경우"만 모아 워크숍을 한 번 더 합니다.
현업이 당연하게 여겨 말하지 않던 것들이 여기서 나옵니다.

권한 테스트를 별도 단계로 둡니다.
실제 사용자 권한으로 업무를 끝까지 수행해보는 테스트를 오픈 전에 따로 잡아둡니다.

전환 리허설을 합니다.
오픈 당일의 순서 — 기존 시스템 중단, 데이터 이관, 검증, 오픈 — 를 실제처럼 미리 해봅니다.
몇 시간이 걸리는지, 어디서 막히는지 알게 됩니다.

'예측 가능한 프로젝트'라는 것

결국 좋은 프로젝트는 문제가 없는 프로젝트가 아닙니다.
문제를 일찍 만나는 프로젝트입니다.

같은 결함이라도 설계 단계에서 발견하면 회의 한 번으로 끝나고, 오픈 2주 전에 발견하면 야근과 일정 연기로 이어집니다.
차이는 발견 시점뿐입니다.

BSG가 26년간 수많은 SAP 프로젝트를 수행하며 가장 중요하게 여기는 것도 이 부분입니다.
올해 SAP로부터 공식 인증을 받은 'BSG Velocity for SAP GROW Fast' 역시 같은 철학에서 출발했습니다.
검증된 사전 구성과 정해진 범위, 반복된 방법론으로 리스크를 줄이고 결과를 예측 가능하게 만드는 것이죠.

마무리

오픈 2주 전의 혼란은 운이 나빠서 생기는 게 아닙니다.
마지막에 처음 해보는 일이 너무 많아서 생깁니다.

그래서 프로젝트를 시작할 때 이렇게 물어보시길 권합니다.
"우리는 무엇을 마지막에 처음 해보게 되는가?"

그 목록을 앞으로 당기는 만큼, 오픈 날의 긴장은 줄어듭니다.

SAP 구축이나 전환을 앞두고 계시다면, 계획 단계에서 BSG와 함께 점검해보시죠.

출처 :  BSG Partners SAP 구축 프로젝트 경험 기반 
기획 : 도예원