소프트웨어에 맞춰 비즈니스 프로세스를 변경한다? 마치 꼬리가 개의 몸통을 흔드는 사례처럼 들린다. 소프트웨어는 비즈니스를 지원해 기업이 가능한 효율적으로 운영될 수 있도록 도와야 하는 존재일 따름이기 때문이다.
하지만 로우 코드(Low Code) 소프트웨어 개발 플랫폼 개발사 트랙비아(TrackVia)의 설문조사에 따르면 오늘날 이런 행태를 보이는 기업이 무려 82%에 달했다. 소프트웨어의 작동 방식에 맞춰 비즈니스 영업 활동 또는 프로세서의 일부를 변경한다고 보고한 기업들이다.
그렇다면 기업 소프트웨어를 기준으로 기업의 운영 방식을 결정하는 것이 문제가 있는 행태일까?
결정 요소
우선 고려해야 할 사항은 소프트웨어가 어떤 작업을 하는지, 또 기업에 경쟁 우위가 어디에서 비롯되는지라고 포레스터 데이브 발로텔리가 말했다.
그는 “비즈니스 프로세스가 기업 경쟁력을 크게 차별화하지 못하는 경우 소프트웨어에 맞춰 프로세스를 변경할 만한 이유가 충분하다. 예를 들어 여러 무료 또는 저비용 표준 이메일 서버와 서비스를 이용할 수 있는데도 맞춤형 이메일 서버를 운영해야만 할 이유가 있는 기업은 거의 없다”라고 말했다.
기업에 경쟁 우위를 제공한다는 판단에 특정 비즈니스 영업 활동 또는 프로세스를 변경하고 싶지 않은 경우가 있을 수 있다. 이 때에는 해당 비즈니스 부분을 운영하기 위해 사용하는 소프트웨어가 반드시 기존의 영업 활동 및 프로세서와 정확히 일치해야 한다. 그리고 모든 기업이 처한 환경은 각각 다르기 때문에 필요에 정확히 부응하는 소프트웨어 애플리케이션을 얻는 가장 확실한 방법은 맞춤형 애플리케이션 개발이다.
하지만 이 접근방식에는 비용이라는 단점이 존재한다. 맞춤형 애플리케이션은 값이 비쌀 수 있으며 개발 기간이 불확실하거나 생각보다 오래 걸리기 쉽다.
더욱이 상황이 악화되고 있다. 애플리케이션 개발 시점에는 영업 활동 및 프로세스에 완벽하게 맞췄을지라도 기업이 소프트웨어가 완성되기 전에 새로운 기회, 기술, 기타 변화가 나타날 수 있다. 즉, 소프트웨어를 사용할 준비가 될 즈음에 더 이상 현재의 비즈니스 방식에 맞지 않는 위험이 있다.
그러면 소프트웨어에 맞춰 비즈니스를 변경하거나(처음부터 피하려고 했던 부분) 소프트웨어를 변경해야 한다. 후자의 경우 더 많은 돈과 시간이 소요되면서도 같은 일이 발생하지 않을 것이라는 보장이 없다.
덜 급진적인 접근방식은 벤더, 제 3자, 내부 인력 등을 통해 (구내로 운영하거나 서비스형으로 액세스할 수 있는) 기존의 소프트웨어 제품을 취하고 수정해 기업의 영업 활동 및 프로세스에 맞추는 것이다.
바톨레티는 “하지만 이것도 값이 비싸고 결과가 확실하지 않을 수 있다. 소프트웨어 수정에 2년이 소요되고 모든 변경사항 때문에 수 백만 달러가 지출될 수 있다”라고 말했다.
그는 또 기초 제품의 업데이트 사이클에서 벗어날 수 있는 위험이 있다고 덧붙였다. 왜냐하면 기초 소프트웨어를 업데이트할 때마다 기초 소프트웨어와 예상대로 호환되는지 시험하고 필요에 따라 수정해야 하기 때문이다. 이 작업이 완료될 즈음에 기초 소프트웨어가 다시 업데이트되고 맞춤 기능 중 일부가 포함돼 있을 수 있다.
오픈소스 기초 제품을 취해 요건에 맞추어 코드를 수정함으로써 수정된 애플리케이션의 총 비용을 줄일 수 있을 것이다. 자체 또는 외주 개발자를 통해 이행하거나 경우에 따라 전문 역량을 가진 오픈소스 프로젝트 후원자가 실시하는 수정을 적용할 수 있다.
하지만 바톨레티는 오픈소스 소프트웨어를 수정해서 비용을 절감할 수 있을 것이라는 생각을 버리는 것이 좋다고 말했다. 그는 “오픈소스는 과거 비싼 상품들의 대안이었지만 이제는 다르다. 유지보수 및 지원 문제로 인해 오픈소스 기업에 수 년 동안 얽매이게 된다”라고 말했다.
어쨌든 언뜻 보기에는 최소 비용 옵션이 보존하고자 하는 영업 활동 또는 프로세스에 가까운 (경쟁 우위를 제공하는) 기성 솔루션을 선택하는 것이 적절한 타협안이다. 기성 솔루션은 여러 조직들이 사용하도록 개발됐으며 훨씬 큰 사용자층이 개발 비용을 분담하기 때문에 라이선스 비용이 낮을 가능성이 높다.
문제는 기성 솔루션이 특수한 영업 활동 및 프로세스와 일치하기 않기 때문에 조직 스스로가 적응해 소프트웨어에 맞춰야 한다는 점이다. 이 프로세스 리엔지니어링(Re-engineering)은 일부 비용이 발생하며 직원들이 새 프로세스에 적용하도록 재교육하는 추가 비용이 발생한다.
또 직원들이 새로운 프로세스에 적응하면서 일정량의 생산성 손실이 발생할 가능성도 있고 해당 소프트웨어가 사용하는 다양한 용어 또는 명명법 등의 겉으로 보기에는 중요해 보이지 않는 요소들로 인해 비즈니스 운영 방식의 변화가 요구되면서 더 많은 비용이 발생할 수 있다.
다시 문제의 핵심을 짚어보고. 새 애플리케이션을 개발하거나 기존의 것을 수정하는 것이 비싸고 위험할 수 있지만 경쟁 우위를 제공하는 영업 활동 또는 프로세스를 보존할 수 있는 이점이 있다. 아니면 기존의 소프트웨어에 더욱 적합하도록 영업 활동 및 프로세스를 변경할 수 있으며, 이를 위해 일부 경쟁 우위를 포기해야 하지만 위험이 더 낮다. 이 경우 관련 비용도 낮을 수 있지만 영업 활동 및 프로세스 변경 자체의 비용이 존재한다.
가치 판단
따라서 중요한 것은 원하는 경쟁 우위가 생각만큼 가치가 있는지 여부다. 기업이 최선의 방식으로 운영되고 있는가? 아니면 시간이 지남에 따라 무계획에 가까운 차선택으로 발전했는가?
이는 IT보다는 비즈니스 문제다. 그러나 많은 기성 애플리케이션에 각종 비즈니스 영업 활동을 지원하는 기능이 포함돼 있다. 산업용 소프트웨어의 경우에는 더욱 그런 경향이 있다.
이런 맥락에서 다시 살펴보면 기업들 중 82%가 소프트웨어에 맞춰 영업 활동 또는 프로세스를 변경한다는 점이 그리 충격적이지 않을 수 있다. 많은 기업들이 보다 효율적이고 입증된 운영 방식으로 이행하고 있으며 이를 통해 값 비싼 커스텀 작업 없이 산업 표준 소프트웨어의 이점을 누릴 수 있다는 뜻일 수 있는 것이다.
어쩌면 이런 기업들은 또 경쟁 우위를 영업 활동과 프로세스가 아니라 디지털 혁신의 특징인 고객 경험에서 찾고 있다는 뜻일 가능성이 높다. dl-ciokorea@foundryco.com
