기업은 혁신을 위해 비즈니스 프로세스를 간소화하거나 새로운 비즈니스를 위해 새로운 기술을 도입하려 한다. 이 때 솔루션 제공 기업들은 최신 기능을 탑재한 자사 대표 제품의 최신 버전을 활용하는 파일럿 프로젝트를 제안하곤 한다.
새로운 파일럿 프로젝트를 수행할 때는 인력, 시간, 인프라와 같은 리소스가 소비된다. 파일럿 프로젝트의 성공의 요건은 부담 없는 환경에서 이 기술을 테스트 한 뒤 결정하는 것이다. 기술이 아직 준비되지 않았거나 해당 기업이 기술을 운용할 준비가 되지 않았다면 미련 없이 시스템을 종료하거나 재고해야만 한다.
리미니스트리트(Rimini Street,지사장 김형욱)는 기업용 솔루션 도입 파일럿 프로젝트 중단을 고려해볼 ‘체크리스트’를 발표했다.
리미니스트리트는 전 세계 IT 및 재무 의사 결정자를 대상으로 ‘IT 혁신의 현황: 우선순위와 과제(The State of IT Innovation: Priorities and Challenges)’에 대한 설문조사를 실시했다. 조사 결과에 따르면, 의사 결정자의 절대 다수(89%)는 회사가 혁신에 더 많이 투자해야 한다고 생각하며, 응답자 대다수(77%)가 "현상 유지", 즉 시스템 및 IT 인프라스트럭처의 기본 유지 보수 및 지원에 너무 큰 비용을 사용하는 것이 혁신에 대한 투자를 가로막는 최대 장애물이라고 지적했다.
리미니스트리트는 경영진이 비용 손실을 최소화하기 위해 진행중인 파일럿 프로젝트의 중단을 고민할 때 검토해야 할 체크리스트를 발표했다. .
1. 파일럿 프로젝트 진행으로 개선된 사항에 대한 프로젝트 성공 평가 지표 및 활용 사례가 없다면 중단을 고려해야 한다
주관적인 의견이 공정한 평가를 방해한다. 따라서 프로젝트 관리 전문가들은 어떤 파일럿이든 시작하기 전에 구체적이고 합의된 성공 지표가 필요하다고 강조한다. 미리 성공 지표를 지정하고 그에 따라 평가하겠다는 의지가 없으면 파일럿 수행 후 부가 가치를 창출했는지 여부를 확인할 수 없다.
미리 평가 지표를 설정해 놓으면 사후 책임 전가 및 상호 비난도 줄어들게 된다. "위험을 감수하는 기업" 혁신 기업으로 칭찬받을 수 있지만 정작 실패와 연결되는 것을 바라는 사람은 거의 없다. 프로젝트 완료 이후인 사후 점검이 아닌 "사전 점검(premortum)" 방식을 고려해 보자. 먼저 잠재적인 문제점을 규명하고, 모든 사람의 의견을 기록으로 남겨 이후에 "책임을 전가"하는 태도를 방지할 수 있다. 이런 사전 점검 리스트는 팀에서 잠재적인 문제점을 체크리스트로 만들어 활용할 수 있다.
2. 파일럿 프로젝트에 새로운 솔루션을 도입하는 것이 최선의 방법인지를 지속적으로 점검하라
기업용 소프트웨어 벤더들은 자신들의 소프트웨어가 고객의 모든 사업을 성공으로 이끄는 최고의 수단이라며 홍보한다. 하지만 벤더가 귀사의 비즈니스에 합당한 목표를 제시했더라도 과연 그들이 제시하는 최신 소프트웨어 또는 업그레이드가 목표를 달성하기 위한 최선책일지 아니면 기존 플랫폼으로도 충분히 가능하지 않을까 매번 점검해야 한다.
기업용 소프트웨어 벤더는 제품 공급으로 끝나지 않고, 고객의 IT 인프라 최적화를 위한 지원에 나서야 한다. 리미니스트리트의 "IT 혁신의 현황(The State of Innovation)" 조사 결과, 응답자의 81%가 더 명확한 제품 로드맵을 보고 싶다고 말했다. 이 경우 각자의 IT 아키텍처 계획에 해당 로드맵이 어떻게 부합하는지 알 수 있다. 그밖에 80%는 기존 IT 인프라 최적화에 더 많은 지원을 받고 싶어한다.
반면 현재 이용 중인 기업용 소프트웨어 제공업체가 혁신의 속도를 높이고 비즈니스 전략을 가속하는 데 도움이 되고 매우 만족한다는 응답자는 10명 중 3명도 되지 않았다(28%).
리미니스트리트는 제 3자(써드파티) 엔터프라이즈 지원 비즈니스 고객들로부터 매년 약 3만여 건의 지원 요청을 받아 처리한다. 이러한 요청의 65%, 즉 약 2만 여 건이 사용자 개발 코드 또는 인터페이스, 통합, 성능 튜닝에 관한 것이다. 주요 기업용 솔루션 벤더들은 기본 소프트웨어 관련이슈만을 지원하며 사용자 개발코드 부분은 전혀 지원하지 않는다.
3. ‘파일럿 프로젝트’에 대한 관계자들의 정확한 이해부족이나, 프로젝트 수행 중 진행된 주요 CxO의 변화로 의도치 않은 방향으로 프로젝트가 영향을 받고 있는지 점검해야 한다
리미니스트리트의 프로젝트 관리 전문가인 리치 미로노프(Rich Mironov)에 따르면 다양한 구성원이 "파일럿"이라는 용어에 대해 종종 공인되지 않은 서로 다른 정의를 사용한다는 것이 근본적인 문제일 수도 있다고 한다. 일부는 파일럿 프로젝트를 "조사" 또는 "실험"으로 간주하고 (성공이든 실패든) 어떤 결과도 받아 들인다. 즉 보통 '이런, 프로젝트가 잘 안 되었군, 어쨌든 이 인프라를 구축하는 사태를 피하게 되어 다행이야'라고 생각한다는 것이다.
주로 비즈니스 측면에서 "파일럿"을 "자사 솔루션의 최초 구현 또는 실제 환경에 도입한 최초의 고객"으로 보는 이들도 있다. 이와 같이 정의한 경우 프로젝트를 종료하기가 매우 힘들어진다. 일단 고객으로 등록하면 '그냥 한 번 시도 해 본 것이다'라며 번복할 기회는 없다는 태도다. 이러한 부담은 없는지를 검토해야 한다.
또한 최고 경영진의 변화로 파일럿 프로젝트가 탄력을 받을 수도, 아니면 막다른 길에 이를 수도 있다. 그러므로 해당 기업 경영진이 안정적인지 그리고 경영진의 변화가 파일럿에 어떤 영향을 줄 수 있는지 살펴볼 필요가 있다. 프로젝트가 보류되거나, 다른 프로젝트로 대체되고 예산도 재편될 수 있다.
4. 지나친 외부 지원 의존이나 허가 받지 않은 쉐도우IT 솔루션의 적용, 또는 향후 전사적 확장성이 부족한 파일럿 프로젝트는 중단한다.
프로젝트 진행 시에 외부의 여러 파트너와 일할 수도 있다. 각 파트너는 고유의 개발 로드맵 및 구현 프로토콜을 가지고 있기 때문에 일정을 변경해야 할 경우 여의치 않을 수도 있다. 이러한 종속 관계가 유지 보수 및 개발에도 문제가 될 수 있다.
또한 공식적으로 허가된 파일럿이라면 적어도 그 내용이 평가 지표가 적용되어 매우 명확하여 목표를 달성하지 못하거나 보안 결함과 같은 다른 문제가 발생하는 경우 신속하게 처리할 수 있어야 한다.
문제는 허가 받은 사업부(LOB) 애플리케이션처럼 보이지만 실상은 그렇지 않은 연구 개발 프로젝트인 경우가 있다는 것이다. 이것을 "쉐도우 IT(shadow IT)" 프로젝트라고 하는데, 쉐도우 IT의 경우 직원들이 부수적으로 애플리케이션을 개발하거나 구입하고 이에 따라 또 하나의 ERP 프로세스를 더하게 되어 하위그룹의 구성원들의 업무가 추가된다. 시범 사업이 지속될수록 문제를 발생시킨다. 이러한 시도는 사업라인이 진행하기엔 상당히 무모하다.
파일럿이 제한된 환경에서 성공을 거두더라도 확장되지 않거나 복잡한 비즈니스 프로세스 종속 관계에 부합하지 못해 폐기해야 하는 사례도 있다. 확장성 부족으로 다른 국가 또는 다른 사업부의 요구를 충족하지 못해 폐기되는 경우도 있다. 이를 다시 진행하려면 막대한 추가 지원 비용이 투입되어야만 한다.
5. 총 파일럿 프로젝트에 투자된 비용(TCP) 효율성을 점검해야 한다
IT 조직이 "현상 유지"에도 분투하고 있는 상황에서, 파일럿이 특별히 야심 찬 프로젝트가 아니더라도 리소스 소요는 부담으로 작용한다.
엔터프라이즈 솔루션 벤더는 초기에 직접 비용이 거의 또는 전혀 발생하지 않는다고 주장한다. 하지만 특정 벤더의 파일럿에 참여하면 수많은 얼리 어댑터(베타 테스터) 중 하나가 된다는 사실을 기억해야 한다.
또한 파일럿 기간이 종료되면 귀사에 유익했든 유익하지 않았든 간에 소프트웨어 비용을 지불하도록 규정한 계약 조항이 있을 수도 있으므로 주의해야 한다. 이러한 측면에서 보면 벤더의 제품 사이클에서 벗어나 절감한 비용을 해당 기업에 특히 필요한 혁신에 재투자하는 것이 훨씬 안전할 수도 있다.
이향선기자