공급업체 종속을 피하면서 워크플로/BPM/RPA/ERP/CRM 시스템을 선택하도록 회사를 준비시키는 방법

그다음 종속을 막는 요구사항을 정리하세요: 개방형 형식의 데이터 및 사건 이력 내보내기, 문서화된 API, BPMN 표준으로 작성된 프로세스, 자체 설정 권한, 그리고 명확한 계약 해지 규정. 오늘 식별할 수 있는 리스크를 명시하세요. 순진하게 생각하지 말고 모든 리스크를 기록하세요. 제안서는 여러분 자신의 시나리오와 다년간 총소요비용(투자 비용 더하기 반복되는 운영 비용)을 기준으로 비교하세요. 라이선스, 갱신, 교육, 팀 유지, 변경, 마이그레이션 모두 포함됩니다. 공급업체가 핵심 컨설턴트를 잃을 가능성, 관리자와 개발자를 AI로 대체하기로 결정할 가능성, 현재 운영체제 지원을 중단할 가능성이 얼마나 되는지도 생각해보세요.

이 글은 문서 흐름, 비용 청구서, 계약서 또는 신청서 처리를 정리하고자 하며, 한 사람에서 다음 사람으로 정해진 규칙에 따라 업무를 이어가는 도구인 워크플로 시스템 선택을 앞둔 기업 및 지방공기업(spółka komunalna) 경영진을 위한 것입니다. 선택지는 보통 세 가지입니다: 완성형 BPM 플랫폼, 로우코드 도구, 또는 맞춤 제작된 전용 시스템이며, 아래 원칙은 셋 모두에 적용됩니다. 잘못된 선택의 결과를 보통 책임지는 재무이사(CFO)에게도 유용합니다.

공급업체 종속이 처음부터 생기는 이유

종속은 한 번의 잘못된 결정에서 비롯되는 경우가 드뭅니다. 보통은 회사가 알아차리기도 전에 시작됩니다: 프로세스가 자체 문서가 아니라 공급업체 도구 안에 기술되고, 데이터와 사건 이력은 쉽게 꺼낼 수 없는 형식으로 저장되며, 설정은 도입 파트너만 알고 있고, 계약서는 도입에 대해서는 많이 말하지만 회사가 떠나고 싶을 때 무슨 일이 일어나는지는 거의 언급하지 않습니다. 몇 년 후 시스템이 더 이상 필요를 충족시키지 못해도 시스템 교체 비용이 유지 비용보다 커집니다.

1단계. 공급업체와 논의하기 전에 프로세스를 기술하라

제안요청서가 작성되기 전에 시스템이 처리해야 할 흐름을 기술해 두는 것이 좋습니다: 누가 사안을 접수하고, 누가 어떤 순서로 승인하며, 예외와 임계값은 무엇인지(예를 들어 특정 금액 이상일 때 다른 경로), 기한은 무엇이고, 감사에 대비해 어떤 결정 기록이 남아야 하는지. 다양한 도구가 이해할 수 있는 BPMN 표준으로 작성하는 것이 가장 좋습니다. 그러면 프로세스 기술서는 시스템이 아니라 회사의 소유가 됩니다.

이런 기술서 없이는 솔루션이 아니라 공급업체의 프레젠테이션을 비교하게 됩니다. 모든 시연은 좋아 보이는데, 공급업체가 가장 까다로운 예외가 아니라 자신들의 최고 시나리오를 보여주기 때문입니다.

2단계. 이미 보유한 것을 점검하라

일부 흐름은 이미 회사가 보유한 도구로 처리할 수 있는 경우가 많습니다: CRM, 업무별 시스템, 문서관리 시스템, 오피스 패키지. 때로는 분석 결과 새 시스템이 필요 없고 절차나 설정 변경만으로 충분하다는 결론이 나옵니다. 이런 자산 점검은 또한 새 시스템이 처리해야 할 통합, 예를 들어 재무회계 시스템 및 KSeF(폴란드 전자세금계산서 시스템)와의 연동, 그리고 오늘날 정보가 소실되는 지점을 보여줍니다. 더 자세히: IT 시스템 자산 점검.

3단계. 종속을 막는 요구사항

다음 요구사항은 희망사항이 아니라 제안요청서의 조건으로 명시하는 것이 좋습니다:

1. 데이터 및 사건 이력 내보내기를 개방형이고 문서화된 형식으로, 언제든지, 추가 비용 없이.
2. 문서화된 API로 다른 시스템과 통합할 수 있어야 하며, 다른 사업자도 이를 사용할 권리가 있어야 함.
3. 표준(BPMN)으로 기술된 프로세스를 내보내고 다른 곳에서 재현할 수 있어야 함.
4. 설정 권한을 자체 팀이나 임의의 파트너가 변경 문서와 함께 행사할 수 있어야 함.
5. 계약 해지 규정: 전환 기간, 데이터 마이그레이션 지원, 그리고 사전에 알려진 비용.
6. 유지보수 파트너 선택권: 도입 후 제조사 지원을 잃지 않고 다른 도입 업체로 전환할 수 있는지.

RPA, ERP, CRM에도 똑같이 적용된다

이 원칙들은 회사의 업무를 정리하는 모든 시스템에 적용됩니다. 그러나 매번, 무엇을 얻고자 하는지 질문하는 것부터 시작하는 것이 좋습니다. 그 답에 따라 애초에 올바른 종류의 도구를 선택하는지가 결정되기 때문입니다.

RPA. 첫 번째 질문은 다음과 같습니다: 왜 BPM이 아니라 RPA인가? 소프트웨어 로봇은 기존 시스템 내에서 사람의 반복적인 작업을 대신하지만 프로세스 자체를 바꾸지는 않습니다. 반면 BPM은 프로세스 자체를 정리합니다. 목표가 사람들을 시스템 간 데이터 입력에서 해방시키는 것이라면 로봇으로 충분할 수 있습니다. 목표가 더 새롭고 짧은 업무 흐름이라면 로봇은 종종 기존 방식을 고착화시킵니다. 로봇은 다른 시스템의 화면과 형식에 의존하기도 합니다: 그 중 하나라도 바뀌면 로봇이 멈출 수 있으므로, 시나리오 유지 비용을 알고 제조사 도구 밖에 그 기술서를 보관해 두는 것이 좋습니다.

ERP. 여기서 핵심 질문은 다음과 같습니다: ERP가 모범 사례와 완성된 프로세스를 제공해주길 바라는가, 아니면 경쟁 우위를 만드는 우리만의 프로세스를 지원해주길 바라는가? 전자의 경우 시스템 표준을 유지하고 변경을 최소화하는 것이 좋습니다. 변경할 때마다 업데이트와 파트너 교체가 어려워지기 때문입니다. 후자의 경우에는 때때로 단순한 ERP를 민첩한 BPM 시스템으로 감싸서, 핵심을 개조하지 않고도 회사를 차별화하는 프로세스를 변경하는 방식이 더 효과적입니다. 두 경우 모두 재무, 재고, 인사 데이터와 KSeF 및 은행과의 통합은 이력 전체와 함께 완전히 꺼낼 수 있어야 합니다.

CRM. 제안서 비교를 시작하기 전에 CRM이라는 개념으로 무엇을 의미하는지 정해야 합니다: 고객 서비스 프로세스 정리, 다채널 영업, 아니면 계약 수주 플랫폼. 이는 사용자도, 통합도, 성공 지표도 각기 다른 세 가지 별개의 프로젝트입니다. 어떤 유형을 선택하든, 접촉 이력과 동의 내역이 포함된 고객 데이터베이스 내보내기 및 영업·고객서비스 시스템과의 API 연동은 부가 사항이 아니라 제안요청서의 조건이 되어야 합니다.

4단계. 라이선스 가격이 아니라 총소요비용을 비교하라

제안서는 다년간 총소요비용을 기준으로 비교하는 것이 좋습니다: 구매 및 도입, 유지보수 및 라이선스, 개발, 그리고 계약 해지 비용. 가장 저렴한 라이선스가 3년 차에는 가장 비쌀 수 있습니다. 프로세스를 변경할 때마다 한 파트너에게 유료 작업을 의뢰해야 한다면 말입니다. 비교는 여러분 자신의 시나리오로 하는 것이 가장 좋습니다: 각 공급업체가 여러분 회사의 동일한 까다로운 사례를 보여주게 하세요. 제안서 평가에 대해 더 알아보기: 제안서 평가 및 공급업체와의 협상.

5단계. 인수 검수 및 유지보수 계약

시스템은 공급업체의 주장이 아니라 사전에 합의된 테스트 시나리오와 기준에 따라 인수 검수하는 것이 좋습니다. 유지보수 계약서는 오류가 얼마의 시간 내에 수정되는지, 누가 얼마의 비용으로 변경을 수행하는지를 명시해야 하며, 데이터 내보내기 및 계약 해지에 관한 조항을 확인해야 합니다.

실제 사례

다국적 기업 자회사 그룹에서 한 회사는 중앙 ERP 시스템을 사용하면서 동시에 조달-결제(procure-to-pay) 그룹의 재무 프로세스를 자동화해야 했고, 이는 기업 조달 가이드라인(corporate purchasing guidelines)에 따라야 했습니다. 그룹웨어용 기업용 도구를 선택하고 싶은 강한 유혹이 있었지만, 이는 상당히 비쌌고 독립성 요건이나 문제 발생 시 쉬운 탈출 요건을 충족하지 못했습니다.

이해관계자들과의 회의에서 우리는 완성형 솔루션의 표준 기능을 넘어서는 상세한 요구사항 기술서를 작성했습니다. 업무별 시스템과의 통합을 위한 여러 대안적 방법과 단일 공급업체에 종속될 위험을 줄이는 메커니즘을 개발했습니다. 그 결과 표준에 기반한 일관된 애플리케이션 전략과, 기술 전문가가 아닌 프로세스 소유자들과의 짧은 회의를 통한 프로토타이핑으로 새로운 흐름이 민첩하게 만들어지는 환경이 탄생했습니다. 이 환경은 ERP 시스템을 감싸는 형태로, 회사가 차별화되는 영역에서 대규모 도입 비용 없이 높은 유연성을 제공합니다.