이 시리즈의 첫 번째 부분에서는 공급업체에 대해 건강하지 못한 의존 관계를 형성하게 되는 원인과, 무엇보다도 이것이 우리 회사에 어떤 문제를 초래할 수 있는지에 대해 살펴보았습니다.
오늘은 이러한 의존성을 피하기 위해 우리가 무엇을 할 수 있는지 살펴보겠습니다.
1. 프로세스 및 시스템에 대한 노하우와 개발 계획을 자체적으로 보유한다
만약 IT 문제에 대해 신경 쓰지 않기로 결정하고 IT 공급업체에 막연한 지침만 내린다면, 이는 의존성을 키우는 지름길입니다. 놀랍게도 이러한 접근 방식은 종종 공급업체 자체에 문제를 야기하기도 합니다. 시간이 지나면 고객의 요구사항이 서로 겹치고 복잡하게 얽히게 되며, 새로운 요구사항을 충족시키는 것이 공급업체에게 큰 부담이 되기 때문입니다.
경쟁력을 유지하고자 하는 기업이라면, IT를 업무 프로세스를 지원하고 개선하며 성과를 측정하는 도구로 인식하는 것이 중요합니다. 이를 실천하는 방법은 그리 어렵지 않습니다. 오늘날에는 프로세스를 종합적으로 파악하고 효과적인 계획을 수립할 수 있게 해주는 충분한 방법론과 표준이 마련되어 있기 때문입니다:
- 엔터프라이즈 아키텍처 – 조직의 목표를 설명하고, 이러한 목표를 비즈니스 프로세스를 통해 달성하는 방법, 그리고 기술이 이러한 프로세스를 어떻게 지원할 수 있는지를 다루는 방법론입니다. 자세한 내용은 “부실한 엔터프라이즈 아키텍처에 발목 잡히지 마세요”라는 기사를 참고하시기 바랍니다. 엔터프라이즈 아키텍처에 대한 가장 잘 알려진 두 가지 접근 방식은 The Open Group과 Zachmann의 웹사이트에서 확인할 수 있습니다.
- 프로세스 설명 – 가장 잘 알려져 있고 널리 사용되는 표준은 오픈 매니지먼트 그룹(www.omg.org)에서 제정했습니다. BPMN(비즈니스 프로세스 모델 및 표기법) 사양에 따라 프로세스를 설명하면, 경영진은 회사 내에서 이루어지는 프로세스를 쉽게 파악하고 기록할 수 있습니다.
- 사용자 설명서 – 반드시 공급업체가 작성해 서랍 속에 넣어두고 먼지만 쌓이게 할 필요는 없습니다. 좋은 방법은 사용자가 일상 업무에서 애플리케이션을 사용하는 방법을 보여주는 동영상을 제작하는 것입니다. 이를 통해 제품 지원과 신규 사용자 교육을 간소화할 수 있습니다. 이러한 동영상은 대개 몇 분 길이에 불과하며, 시스템을 효과적으로 사용하는 데 필요한 모든 내용을 설명합니다. 예를 들어, 연구 프로젝트에서 Yammer를 사용하는 방법 가이드나 온라인 쇼핑몰에서 상품을 주문하는 방법 가이드를 확인해 보세요.
모든 표준 및 방법론에는 각 분야를 상세히 설명하는 포괄적인 문서와 학습 자료가 함께 제공됩니다. 제 경험상, 특정 기업에 적합한 방법론의 요소를 선별해 줄 전문가를 고용하는 것이 좋습니다.
자사의 노하우를 표준화된 형태로 정리해 둔다면, 기업 발전을 이끌어낼 수 있는 주제를 논의할 수 있는 도구를 확보할 뿐만 아니라, 현재 및 잠재적 공급업체 대다수와 공감대를 형성할 수 있다는 확신을 얻을 수 있습니다.
업무 프로세스와 정보 흐름에 변화를 주고 싶다면, 먼저 업무 조직 구조부터 변경해 보십시오. 모델 수준에서 변경하거나 시범 운영을 통해, 해당 변화가 기대하는 효과를 가져올지 테스트해 보십시오. 그런 다음 변화로 인한 이점과 도입 비용을 산정하십시오. 모든 것이 계획대로라면 시스템을 수정하기 시작하고, 그렇지 않다면 아무런 문제 없이 조치를 중단할 수 있습니다. 이 과정을 외부 공급업체에 전적으로 맡길 경우, 이미 자원을 투입한 프로젝트를 중단할 용기를 가진 사람은 거의 없습니다.
2. 어떠한 경우에도 해당 데이터는 본인의 소유여야 합니다
데이터는 당사의 공급업체에 저장되어 있었는데, 최근 그들과 관계가 틀어지면서 그들이 데이터의 소유권은 자신들에게 있다고 주장하고 있습니다... 안타깝게도 이런 상황은 생각보다 드문 일이 아닙니다. 흔히 생각하는 것처럼 클라우드 서비스나 호스팅 공급업체에서는 자주 발생하지 않지만, 데이터가 공급업체가 완전히 통제하는 ‘블랙박스’ 안에 저장되는 맞춤형 개발 시스템에서는 가장 흔히 발생하는 문제입니다.
이는 공급자가 고객을 통제하에 두는 전통적인 방식입니다. 이 문제는 일반적으로 두 가지 방법으로 해결할 수 있습니다. 데이터를 직접 통제하거나, 사용 가능한 형식으로 데이터를 확보할 수 있는 신뢰할 수 있는 방법을 마련하는 것입니다.
예를 들어, 공급업체 웹사이트에 가입하여 확보한 이메일 연락처를 관리하는 서비스를 들 수 있습니다. 첫 번째 방법은 해당 데이터를 자사 시스템에 복제해 두는 것이며, 두 번째 방법은 공급업체 시스템에 저장된 정보를 정기적으로 다운로드하여 ‘만일의 경우’를 대비해 자사 시스템에 보관하는 것입니다.
데이터 저장 방식이 명확히 문서화되어 있는 우리 시스템에서도, 데이터를 표준 테이블, 데이터베이스 또는 XML로 내보내는 방법론을 마련해 두면 새로운 시스템과의 통합을 크게 원활하게 할 수 있습니다. 데이터 추출 절차, 내보내기 기능의 검증, 그리고 형식에 대한 명확한 문서화를 수립하는 것이 중요합니다. 왜냐하면 데이터를 검색해야 하는 결정적인 순간이야말로, 내보내기 기능이 작동하지 않거나 완벽하게 내보낸 데이터가 우리가 처리할 수 없는 형식으로 인코딩되어 있다는 사실을 발견하기에 가장 최악의 순간이기 때문입니다.
공급업체로부터 새로운 기능이나 시스템 변경 사항을 도입할 때는 상기 요구 사항을 반드시 확인해야 합니다.
3. 애플리케이션에 대한 지적 재산권 보유
애플리케이션의 소유권은 해당 애플리케이션의 소스 코드 또는 설계에 대한 소유권을 의미합니다. 만약 우리가 소스 코드를 통제할 수 없다면, 공급업체를 변경하고자 할 때 기존 공급업체가 코드의 핵심 부분을 소유하고 있어 이를 무상으로 제공하지 않으려 할 위험이 있습니다. 계약서에 소유권을 명확히 규정함으로써 이러한 위험을 피할 수 있습니다. 즉, 요청된 변경 사항의 결과로 개발된 코드는 전적으로 당사의 소유임을 명시하거나, 해당 변경 사항이 당사가 무료로 사용하고 배포할 수 있도록 허용하는 라이선스 하에 생성되었음을 명시해야 합니다.
계약상 소유권을 확보했다고 하더라도, 계약을 해지하려는 공급업체가 우리에게 소스 코드를 제공해 줄 것이라는 보장은 없습니다. 따라서 소스 제어 시스템, 위키 및 기타 문서를 제3자에게 보관하도록 하고, 파트너사가 특정 시점에 특정 장소에 데이터를 저장할 의무를 지게 하여 우리가 최신 버전에 접근할 수 있도록 하는 것이 매우 바람직합니다.
4. 기능 확장보다는 시스템 통합
웹 서비스 API(응용 프로그램 프로그래밍 인터페이스)는 이제 많은 상용 및 오픈 소스 애플리케이션에서 흔히 볼 수 있는 기능이 되었습니다. 이는 애플리케이션 사용자가 이용할 수 있는 모든 기능이 서로 다른 시스템과 애플리케이션 간에도 활용될 수 있음을 의미합니다.
이 인터페이스를 정의하는 데 프로토콜과 표준을 활용함으로써, 이러한 서비스들은 통합된 통신 수단이자 플랫폼이 됩니다. 즉, 특정 언어나 운영 체제로 작성된 애플리케이션도 완전히 다른 방식으로 구현된 시스템에서 접근할 수 있게 됩니다. 데이터는 XML이나 JSON과 같은 공통 형식으로 전송되며, 두 시스템의 코드베이스는 완전히 독립적인 상태를 유지합니다.
요즘에는 모든 사용자가 시스템 통합이 어떤 것인지 쉽게 상상할 수 있습니다. 결국 우리 모두는 서로 통합된 웹 애플리케이션 서비스를 사용하고 있습니다. 예를 들어, 구글 캘린더와 구글 연락처, 지메일 등이 그렇죠. 기존 캘린더 대신 다른 캘린더를 사용하기로 결정했다면, 기존 데이터와 연결하기만 하면 됩니다. 하지만 회계용으로만 구매했던 자체 시스템을 점차적으로 공급업체에 의뢰해 CRM 모듈이나 서비스 모듈 등을 추가 개발해 온 경우에는 이러한 방식의 시스템 변경이 불가능합니다.
이 논리는 클라우드 서비스 제공업체가 서비스 형태로 제공하는 시스템(SaaS – Software as a Service)과의 통합에도 동일하게 적용됩니다. 웹 서비스를 활용하면 개별 애플리케이션 간의 의존성을 분리할 수 있어, 전체 시스템의 유연성과 투명성이 향상됩니다. 반대로, 서로 다른 모듈 간에 고정된 연결을 사용하면 공급업체가 사용자에 대한 의존도를 높이기 쉬워지고, 코드의 복잡성이 증가하며, 시스템의 유연성은 가장 유연성이 낮은 부분의 수준에 머물게 됩니다.
5. 표준 시스템에 대한 수정을 최소화하도록 노력하십시오
표준 구현 방식을 최대한 그대로 유지하면서 필요한 시스템을 구축하도록 노력하십시오. 대개 귀사는 공급업체의 첫 번째 고객이 아닙니다. 시스템 구축 과정에서 공급업체가 다른 고객사와의 협업을 통해 쌓아온 경험을 최대한 활용하십시오. 일부 프로세스를 훨씬 더 효율적으로 구현할 수 있다는 사실이나, 이전에 간과했던 특정 데이터가 오히려 경쟁 우위로 작용하게 될 것이라는 점에 놀라게 될 것입니다.
애플리케이션의 기능에 큰 변경이 필요한 경우, 향후 새 버전으로의 전환이 상당히 복잡해질 수 있으며, 개발 및 배포 측면에서 어떤 전환이든 어려움이 따를 것입니다.
6. 여러 공급업체를 활용하십시오
시스템 설계, 개발, 배포 및 운영 전반을 직접 관리하고 공급업체에 맡기지 마십시오. 예를 들어, 비즈니스 분석가와 개발자를 분리하는 것이 좋습니다. 또한 개발 팀 외부의 테스터가 시스템을 테스트하도록 하는 것이 좋습니다. 이렇게 하면 업무가 더 효율적으로 수행될 뿐만 아니라, 결함 없는 제품을 확보할 가능성도 훨씬 높아집니다. 운영을 다른 당사자(예: 클라우드 서비스 제공업체)가 담당하는 경우, 해당 업체가 개발자들에게 시스템 운영 문제를 최소화하는 제품을 제공하도록 독려할 것임을 반드시 확인하십시오.
7. 계약서에 해지 절차를 명시하고, 공급업체에 대한 위약금 조항을 포함한다.
계약서에는 협력 관계 종료에 대해 어떻게 명시되어 있나요? 3개월 전에 통보하면, 그 이후부터는 대금 지급을 중단하고 공급업체는 지원을 중단한다는 내용인가요? 그건 정말로 턱없이 부족한 조건입니다.
통지 기간 동안 공급업체가 귀하에게, 또는 새로운 공급업체에게 직접 제공해야 하는 문서의 종류와 그 품질을 명확히 명시해야 합니다. 3항에 언급된 설계, 소스 코드 및 기타 문서에 대한 지적 재산권을 확보해 두셨다면 더욱 좋습니다. 공급업체와 계약을 체결할 때는, 2위와 3위를 차지한 업체들에게 낙찰자가 개발 및 유지보수 업무를 인계할 경우 어떤 사항이 필요한지 확인해 보는 것이 좋습니다.
8. 공급업체에 향후 개발 계획을 알린다
공급업체와 장기적인 파트너십을 구축하십시오. 단순히 기능상의 변경 사항뿐만 아니라 개발 계획과 전략적 과제에 대해서도 정기적으로 논의한다면, 공급업체는 현재의 요구사항뿐만 아니라 미래의 요구사항까지 충족할 수 있는 안정적이고 효율적이며 비용 효율적인 시스템 아키텍처를 제안해 줄 수 있습니다. 요구사항을 명확히 하기 위해, 예를 들어 요구사항을 다음과 같은 범주로 분류하는 MuSCoW 기법을 활용할 수 있습니다:
- 꼭 필요한 것 – 꼭 필요한 것
- ~했어야 했는데 – ~했어야 했는데
- ~할 수도 있었을 텐데 – 있으면 좋겠네요
- 이번에는 그럴 수 없다 – 이번에는 그럴 필요가 없다
9. 다른 당사자들의 의견과 제안을 듣는다
한곳에 갇혀 있지 말고, 트렌드를 따르며, 최선의 접근 방식과 모범 사례를 찾아보고, 모든 상황을 주시하십시오. 제3자의 의견을 듣기 위해 전문 업체를 고용하세요. 그들은 기술적 관점과 전략적 관점 모두에서 여러분의 결정을 평가해 줄 것입니다. 비용이 비싸지 않아도 됩니다. 또한 이러한 자문은 실수를 방지하는 데 도움이 되므로 그만한 가치가 있습니다. 제 경험에 비추어 말씀드리자면, 공급업체가 자사가 초래한 문제를 해결하기 위해 고객에게 수백만 크로나를 투자하도록 강요한 사례를 알고 있습니다. 그런데 컨설턴트가 조사한 결과, 문제의 원인이 다른 곳에 있었기 때문에 그 투자는 문제를 전혀 해결하지 못할 것이라는 사실이 밝혀졌습니다.
컨설턴트는 전략 수립, 수요 창출, 대안 평가, 그리고 예상치 못한 관점에서 사안을 바라보는 데 도움을 줄 수 있습니다. 또한 공급업체를 점검하고 귀사에 가장 유리한 결과를 얻을 수 있도록 지원합니다. 컨설턴트는 귀사가 특정 공급업체에 의존하지 않기를 원하며, 귀사의 노하우가 경쟁 우위로서 갖는 가치를 잘 인지하고 있다는 점을 항상 염두에 두어야 합니다.
적절한 공급업체 선정은 위험 관리와 직결됩니다
이 글을 읽으신 후에는 공급업체를 단순한 종속 관계가 아닌, 여러분의 성공을 함께 이룰 파트너로 만드는 방법에 대해 더 명확한 이해를 얻으셨으리라 믿습니다. 불쾌한 상황을 예방하기 위해서는 꾸준한 리스크 관리를 실천하고, 현재의 요구 사항과 미래의 유연성 사이에서 균형을 잡는 해결책을 선택해야 합니다. 앞서 언급한 원칙들을 준수함으로써, 여러분은 올바른 공급업체와 새로운 시스템을 선택할 수 있을 것입니다.
