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