이 글은 이사회, 그리고 시스템 구매에 서명하는 사람들을 위한 것이다: 관공서의 사무국장(sekretarz)과 회계관(skarbnik), 지방공기업(spółka komunalna) 대표이사, 재무이사, 회사 대표. 또한 입찰 절차나 견적 요청서를 준비하면서, 경영진이 문서를 승인하기 전에 무엇을 점검해야 하는지 알고 싶어 하는 IT 부서장을 위한 글이기도 하다.
이 문제가 발생하는 이유
공급업체와의 문제 대부분은 발주기관 쪽에서, 그것도 계약 체결 훨씬 전에 그 원인이 발생한다. 악의에서 비롯된 것은 아니다: 발주 준비는 조직 내에 그럴 시간과 역량이 좀처럼 없는 작업이며, 공급업체는 기꺼이 그 부담을 덜어주려 한다. 이미 완성된 설명서, 시연, 견적을 가지고 온다. 그 결과 발주기관은 자신이 필요로 하는 것이 아니라 공급업체가 팔 수 있는 것을 구매하게 된다. 또 다른 문제는 구매 결정이 대부분 실무 부서의 손에 남아 있고, IT 부서는 단지 보안 관문 역할만 한다는 점이다. 표준과 장기적인 IT 전략이 없다 보니, 조직은 위험을 완화하기 위한 틀에 항상 부합하지는 않는 구매를 하게 된다.
나는 이러한 실수를 관공서에서도, 기업에서도 똑같이 목격한다. 다른 것은 구매 방식일 뿐, 그 작동 기제는 같다.
열두 가지 실수
- 단일 공급업체의 제안서나 프레젠테이션을 기반으로 작성된 요구사항. 아직 수행업체를 선정하기도 전에 경쟁을 제한하고 의존관계를 고착시킨다. 이 문제는 입찰공고(SWZ)에서의 공급업체 종속 글에서 더 자세히 다뤘다.
- 사업 책임자의 부재. 프로젝트에는 형식상 관리자가 있지만, 프로세스가 어떻게 작동해야 하는지를 결정할 이사회의 위임을 받은 사람은 아무도 없다.
- 계약 체결 전 인수 기준과 테스트 시나리오의 부재. 인수 과정은 프로젝트 산출물이 도입 성공 기준을 충족하는지를 점검하는 절차가 아니라 해석을 둘러싼 분쟁이 되어 버린다.
- 현재 보유하고 있는 것에 대한 무지. 기존 계약, 라이선스, 기능 중 어떤 것이 새 시스템과 중복되는지 모른 채 새 시스템을 구매한다.
- 누락된 연동(integration). 새 시스템이 어떤 시스템과 데이터를 주고받아야 하는지, 어느 방향으로, 어느 시스템이 상위(마스터) 역할을 하는지, 어떤 데이터를 어떤 형식으로 주고받는지, 그리고 공급업체가 이를 알고 있으며 필요한 메커니즘을 제공하고 그 지속적인 작동에 대한 책임을 질 것인지에 대한 확인이 빠져 있다.
- 한 문장으로 처리된 데이터 마이그레이션. 어떤 데이터를, 어느 기간의 것을, 누가 정제하고, 누가 결과를 검증할지 정해지지 않은 채로 남는다.
- 프로세스 기술 대신 기능 목록 형태의 요구사항. 기능이 있냐고 물으면 어느 공급업체든 “예”라고 답한다. 그러나 여러분의 구체적인 사례를 어떻게 처리할 것인지 물으면 답변은 제각각 달라진다.
- 총비용이 아닌 초기 가격만 비교. 라이선스는 시작에 불과하다. 유지보수, 변경, 연동에 대한 비용은 수년에 걸쳐 지불된다. 이 메커니즘에 대해서는 총소유비용(TCO)과 삶아지는 개구리 글에서 다뤘다.
- 범위 변경 원칙의 부재. 누가 변경을 요청하고, 누가 그 비용을 산정하며, 누가 승인하는지 정해져 있지 않다.
- 해지 조건이 없는 계약. 데이터 반출, 문서 인계, 유지보수를 다른 업체로 이관하는 것에 관한 조항이 없다. 위험 완화 수단도 없다.
- 공급업체 표준양식을 그대로 받아들인 유지보수 계약. 이 경우 서비스 수준, 대응 시간, 변경 비용을 한쪽 당사자가 일방적으로 정하게 된다.
- 기한 직전까지 미뤄진 결정. 법정 기한이나 기존 시스템 지원 종료 시점이 임박하면, 제안서를 비교하거나 협상할 여지가 더 이상 남지 않는다.
1번부터 3번까지의 실수가 근본 원인이다. 이를 제거하면 나머지 대부분은 실행 단계가 아니라 준비 단계에서 이미 드러난다.
의회, 감사위원회 또는 본사 입장에서 가장 중요한 것은 공급업체 선정 결정에 문서화된 근거가 있는지 여부다. 위의 열두 가지 항목은 동시에, 경영진이 발주 문서를 승인하기 전에 반드시 던져봐야 할 질문 목록이기도 하다.
실무 사례
우리 고객사 중 한 곳은 ERP 시스템 공급업체로부터, 도입 중인 문서관리시스템(EZD/e-Doręczenia, 전자문서관리 및 전자배송 시스템)과 거래처 데이터를 문제없이 주고받을 수 있다는 답변을 받았다. 그러나 문서관리시스템은 대개 실제 거래(고객이 되거나 공급업체가 되는 등)가 발생한 거래처뿐 아니라 모든 거래처의 데이터를 보관한다. 새로운 거래처 데이터의 생애주기는 대개 실제 거래가 발생하기 훨씬 전부터 시작되기 때문이다.
도입 과정에서, ERP 시스템 공급업체 측에서 거래처 데이터의 양방향 교환을 위해 API 인터페이스를 조정하는 비용이, KSeF(국세청 전자인보이스 시스템) 연동, OCR, WIES, 통계청(GUS) 데이터 연동, 그리고 최종적으로 재무회계시스템으로의 데이터 반출까지 포함한 비용 서류 흐름 도입 프로젝트 전체 비용의 80%에 달한다는 사실이 드러났다. 처음에 공급업체와 정확히 논의되지 않았던 이 단 하나의 연동이 사실상 프로젝트 비용을 두 배로 늘려버렸다.
독립 자문이 필요한 경우
이미 비슷한 발주를 여러 차례 준비해 본 경험 있는 팀이 있다면, 이 목록은 점검용으로 활용하면 된다. 독립적인 시각이 의미를 가지는 경우는, 발주 규모가 조직 차원에서 크거나, 요구사항이 단일 공급업체와의 접촉 속에서 만들어졌거나, 결정을 감사기관, 의회 또는 본사 앞에서 방어해야 하거나, 발주기관 측에 이러한 시스템을 속속들이 아는 사람이 아무도 없을 때다.
입찰공고 게시나 견적 요청서 발송 전에 문서를 검토하거나, 요구사항과 테스트 시나리오를 준비하거나, 이미 제출된 제안서를 평가해 드릴 수 있다. 관공서의 경우 출발점이 조금 다른데, 이는 지방자치단체(JST)를 위한 페이지에서 설명하고 있다.