SAP 프로젝트 의사결정 기록, 아무도 안 읽는 주방 게시판
SAP 구축 프로젝트에서 회의록은 쌓이는데 결정의 이유는 사라지는 이유와, 현업 담당자가 무엇을 남겨야 하는지 정리했습니다.
안녕하세요, Rabbit입니다! 🐰
새 매장을 준비하던 시절, 주방 벽에 게시판이 하나 있었습니다. 매주 회의를 하고 나면 누군가 종이를 한 장 붙였습니다. 넉 달이 지나자 게시판은 종이로 빼곡했습니다.
그런데 개업하고 두 달쯤 지나 문제가 생겼을 때, 그 게시판에서 답을 찾은 사람은 아무도 없었습니다. 종이에는 “동선 관련 논의함”, “발주 방식 협의함”만 적혀 있었거든요. 무엇을 논의했는지는 있는데, 무엇으로 정했고 왜 그렇게 정했는지가 없었습니다.
SAP 구축 프로젝트에서 가장 자주 반복되는 일입니다. 회의록은 성실하게 쌓이는데, 정작 오픈 후에 필요한 것은 거기 없습니다.
- 프로젝트 회의록은 대개 “무엇을 논의했는지”만 남고 “왜 그렇게 정했는지”는 빠진다.
- 이유가 없는 결정은 담당자가 바뀌는 순간 아무도 설명할 수 없는 설정이 된다.
- 현업 담당자가 남겨야 할 것은 회의 내용이 아니라 결정의 근거다.
논의는 남고 결정은 사라진다
프로젝트 회의는 대부분 기록됩니다. 참석자, 안건, 논의 사항이 표 안에 정리되어 공유 폴더에 올라갑니다. 문제는 그 표에 “결정” 칸이 있어도 대개 한 줄로 끝난다는 점입니다. “협의 완료”, “현업 확인 후 진행” 같은 문장이죠.
넉 달 뒤 그 문장을 읽는 사람에게 이건 아무 정보가 아닙니다. 무엇을 협의했는지, 어떤 선택지가 있었는지, 왜 이쪽을 골랐는지가 없으니까요.
그래서 오픈 후에 “이 항목은 왜 필수값으로 잡혀 있나요”라는 질문이 나오면 답할 수 있는 사람이 없습니다. 기록은 있는데 답이 없는 상태입니다. 이게 프로젝트가 새 매장을 여는 다섯 고비를 넘는 동안 조용히 쌓이는 부채입니다.
말한 것과 이해된 것이 다르다
현업이 “우리는 보통 이렇게 합니다”라고 말하면, 컨설턴트는 그 말을 시스템 언어로 번역해서 듣습니다. 이 번역 과정에서 조용히 어긋나는 일이 자주 있습니다.
주방장이 “재료는 보통 아침에 받습니다”라고 말했다고 해보죠. 여기서 ‘보통’은 “대개 그렇지만 급하면 오후에도 받는다”는 뜻이었는데, 설계자는 이걸 “입고는 오전에만”으로 옮겨 적을 수 있습니다. 둘 다 거짓말을 하지 않았는데 결과는 달라집니다.
이런 어긋남은 회의 자리에서는 거의 드러나지 않습니다. 양쪽 다 합의했다고 믿고 넘어가니까요. 드러나는 건 오픈 후 오후에 자재가 들어왔을 때입니다.
💡 핵심: 회의록에 “입고는 오전”만 적으면 이 문제를 못 잡습니다. “대부분 오전이지만 긴급 건은 오후에도 발생함 — 예외 처리 필요”까지 적어야 잡힙니다. 남겨야 하는 건 결론이 아니라 결론에 붙은 조건입니다.
답을 미루면 표준으로 굳는다
현업이 “그건 좀 더 생각해 보겠습니다”라고 하는 순간이 있습니다. 실무가 바빠서, 혹은 어느 쪽이 나은지 판단이 안 서서 미룹니다.
프로젝트는 그 자리에서 멈추지 않습니다. 일정이 있으니 어딘가는 채워져야 하고, 결국 표준 기능이나 다른 회사 사례가 그 자리에 들어갑니다. 그 자체는 나쁜 선택이 아닙니다. 검증된 레시피를 쓰는 데는 이유가 있으니까요.
문제는 그게 선택이었다는 기록이 안 남는다는 점입니다. 현업이 검토해서 표준을 택한 것과, 현업이 답을 안 줘서 표준으로 채워진 것은 화면상 똑같아 보입니다. 나중에 그 설정을 바꾸려 할 때 “이건 왜 이렇게 됐나”에 아무도 답하지 못하는 이유입니다.
그래서 결정을 미룰 때도 기록이 필요합니다. “현업 판단 보류 — 표준안으로 진행, 오픈 후 재검토 필요”라고 한 줄 남기는 것과 아무것도 안 남기는 것은 완전히 다릅니다.
사람이 바뀌면 이유가 사라진다
프로젝트는 길고, 그동안 사람은 바뀝니다. 컨설턴트가 교체되고, 현업 담당자가 인사이동으로 빠지고, 개발자가 다른 프로젝트로 옮겨 갑니다.
머릿속에만 있던 맥락은 이때 전부 사라집니다. 남는 건 시스템 설정값과 “협의 완료”라고 적힌 회의록뿐입니다.
특히 위험한 건 예외를 위해 넣은 설정입니다. 특정 상황을 처리하려고 만든 조건이 있는데 그 상황이 기록되지 않으면, 나중에 보는 사람 눈에는 그냥 불필요하게 복잡한 설정으로 보입니다. 정리하겠다고 손댔다가 원래 막으려던 문제가 다시 터집니다.
만든 사람은 떠나고 쓰는 사람은 남습니다. 기록은 그 사이를 잇는 유일한 다리입니다.
현업이 남겨야 할 것
컨설턴트가 쓰는 회의록과 현업이 남겨야 할 기록은 목적이 다릅니다. 전자는 프로젝트 관리용이고, 후자는 오픈 후에 읽힐 기록입니다.
거창할 필요는 없습니다. 결정이 날 때마다 네 가지만 붙여두면 충분합니다.
- 무엇으로 정했나 — 실제 확정된 내용을 문장으로
- 어떤 선택지가 있었나 — 검토했지만 안 고른 안도 함께
- 왜 이쪽인가 — 우리 업무의 어떤 사정 때문인지
- 어떤 조건이 붙나 — 예외 상황, 나중에 다시 볼 지점
네 번째가 가장 자주 빠지고, 가장 자주 필요해집니다.
그림 1. 결정이 날 때마다 남겨야 할 네 가지
이 기록은 Fit/Gap 분석에서 표준과 우리 방식의 간격을 재고 무엇을 손볼지 정할 때 특히 중요합니다. 그때 내린 판단의 근거가 남아 있어야, 나중에 그 간격을 다시 조정할 수 있습니다.
Rabbit의 한 끗
프로젝트가 끝나면 산출물이 한 무더기 남습니다. 설계서, 테스트 결과서, 매뉴얼. 그런데 오픈 후 실제로 가장 자주 찾게 되는 질문은 “이거 어떻게 쓰나요”가 아니라 “이거 왜 이렇게 됐나요”입니다.
전자는 매뉴얼에 있습니다. 후자는 대개 어디에도 없습니다.
프로젝트에서 현업이 남긴 이유만큼만 시스템에 설명이 남습니다. 회의에서 아무리 좋은 판단을 했더라도, 그 판단의 근거가 기록되지 않으면 넉 달 뒤에는 그냥 이유를 알 수 없는 설정이 됩니다. 😎
더 읽어보기