구매시스템 PoC, 4주 안에 검증할 것

"PoC를 석 달 했는데 결론이 안 났습니다." 구매시스템을 검토해 본 회사에서 흔히 나오는 말입니다. 시범 운영을 시작할 때는 모두 기대가 컸습니다. 그런데 여러 부서가 각자 테스트를 하다 보니 범위가 계속 넓어졌고, 무엇을 확인하면 성공인지 정한 사람이 없었습니다. 결국 "좋은 것 같긴 한데"라는 인상만 남았습니다.

PoC(Proof of Concept, 개념 검증)는 도입 여부를 판단하기 위한 실험입니다. 실험이 판단으로 이어지려면 시작 전에 세 가지가 정해져야 합니다. 누가 책임지는가, 무엇을 대상으로 하는가, 무엇이 나오면 성공인가입니다.

이 글은 구매시스템 PoC를 4주 안에 끝내는 설계 방법을 정리합니다. 4주라는 기간은 한두 품목에서 실제 구매 한 건을 요청부터 정산까지 완료할 수 있는 최소 단위로 잡은 예시이며, 회사 규모와 품목에 따라 조정할 수 있습니다.

PoC가 결론 없이 끝나는 이유

결론 없는 PoC에는 공통점이 있습니다.

• 책임자가 없습니다. 경영진은 관심을 보였지만 운영을 맡은 사람이 없습니다. 이슈가 생기면 각 부서가 시스템 공급업체에 따로 묻고, 정리는 아무도 하지 않습니다.

• 범위가 너무 넓습니다. "이왕 하는 김에" 여러 품목, 여러 부서를 넣습니다. 설정할 것이 많아져 정작 실제 구매는 시작도 못 합니다.

• 성공 기준을 나중에 정합니다. 끝나고 나서 무엇이 좋았는지 찾습니다. 기준이 사후에 정해지면 결과는 해석에 따라 달라집니다.

• 데모 데이터로 진행합니다. 실제 요청자, 실제 공급사, 실제 결재선 없이 화면만 눌러 봅니다. 운영에서 생길 문제는 하나도 드러나지 않습니다.

네 가지는 모두 시작 전에 막을 수 있습니다. 그래서 4주 PoC의 첫 단계는 사실 "0주차", 즉 시작 전 합의입니다.

그림 1. 4주 PoC 타임라인과 주차별 산출물. 기간은 예시이며 조정할 수 있습니다.

0주차 합의서에 넣을 항목

시작 전 합의는 회의록이 아니라 한 장짜리 문서로 남깁니다. 나중에 "그건 범위에 없었다"는 논쟁을 막기 위해서입니다. 다음 항목이면 충분합니다.

• 목적: 이번 PoC로 판단하려는 질문 한 문장. 예를 들어 "이 품목의 요청부터 정산까지를 한 흐름으로 처리할 수 있는가"입니다.

• 대상: 품목, 참여 부서와 사용자, 참여 공급사.

• 기간과 판단일: 시작일, 완주 목표일, 판단 회의 날짜.

• 성공 기준과 통과 조건: KPI 세 개와 기준값, 확대를 막는 조건.

• 역할: 운영 책임자, 시스템 공급업체 담당자, 재무·IT 확인자.

• 비용과 데이터 조건: PoC 기간의 비용, 입력한 데이터를 종료 후 어떻게 처리할지.

이 문서에 경영진이 동의를 남기면 운영 책임자가 다른 부서에 협조를 요청할 근거가 생깁니다. 반대로 이 문서를 만들지 못한다면 아직 PoC를 시작할 때가 아니라는 신호입니다.

품목 1~2개를 고르는 기준

PoC 대상 품목은 "가장 문제가 큰 품목"이 아니라 "4주 안에 한 바퀴를 돌 수 있는 품목"이어야 합니다. 문제가 큰 품목은 이해관계자가 많고 계약 주기가 길어 4주 안에 결과를 볼 수 없는 경우가 많습니다.