|
이 정렬 연습의 결과는 차별화 및 비차별화 ERP 기능과 해당 기능이 구성되는 방식에 대한 기능 맵입니다(대화형 참조). 대부분의 분류는 최고 수준에서 이루어질 수 있지만, 훨씬 더 세분화되어야 하는 일부 영역이 있습니다. 예를 들어, 대화형에서 볼 수 있듯이 구색 관리의 대부분은 상품 기능으로 간주되지만 수요 예측은 이 회사가 경쟁업체와 차별화하려는 부분입니다.
인터렉티브
우리는 장애가 있는 개인에게도 웹사이트에 대한 동등한 접근권을 제공하기 위해 노력하고 있습니다. 이 콘텐츠에 대한 정보를 원하시면 기꺼이 도와드리겠습니다. McKinsey_Website_Accessibility@mckinsey.com 으로 이메일을 보내주세요.
잘 설계된 기능 맵은 비즈니스 가치에 따라 업그레이드해야 할 모듈 클러스터를 결정하는 데도 도움이 됩니다.
이러한 관점은 비즈니스가 아닌 공급업체가 기능 및 현대화 요구 사항의 경계를 정의하는 일반적인 표준에 대한 강력한 균형을 제공합니다. 이러한 상황은 많은 기존 기업에서 IT가 아닌 이해관계자들조차 '금융'이나 '공급망' 현대화 프로젝트보다는 'ERP 공급업체 X' 업그레이드 프로젝트에 대해 이야기하는 사실에서 종종 반영됩니다.
시스템의 가치가 낮은 부분을 업그레이드하는 데 드는 비용과 위험을 줄이는 데 중점을 둡니다.
ERP 요소를 차별화하는 첫 번째 버킷의 경우 CIO는 즉각적인 업그레이드를 추진해야 합니다. 그러나 두 번째 버킷인 비차별적 ERP 요소의 경우 비용과 위험을 관리하기 위해 신중하게 업그레이드 순서를 지정해야 합니다. 이러한 방식으로 업그레이드는 단일 다년간의 프로젝트에서 각각 몇 달 동안 지속되는 일련의 소규모 소프트웨어 프로젝트로 변환됩니다. 이러한 범위 축소는 위험(소규모 프로젝트 = 작은 위험)을 낮추고 신속하게 가치를 창출하는 혁신 프로그램에 더 효과적으로 할당할 수 있는 지출을 미루게 됩니다.
우리는 IT가 모놀리식 ERP 설정의 복잡성을 줄이기 위해 세 가지 단계를 수행함으로써 이러한 이점을 얻을 수 있다는 것을 발견했습니다(전시물).
전시하다
우리는 장애가 있는 개인에게도 웹사이트에 대한 동등한 접근권을 제공하기 위해 노력하고 있습니다. 이 콘텐츠에 대한 정보를 원하시면 기꺼이 도와드리겠습니다. McKinsey_Website_Accessibility@mckinsey.com 으로 이메일을 보내주세요.
1. 불필요한 연결 분리
다른 애플리케이션과의 연결이 다양하기 때문에 코어 시스템을 교체하는 것은 어려운 작업이 될 수 있습니다. 이러한 연결 중 일부는 표준 기능(예: 지급 계정)을 수행하고 공급업체의 모든 아키텍처 지침을 따르며 유지 관리가 쉽습니다. 이러한 연결은 설계된 작업을 수행하고 있으므로 건드리면 안 됩니다. 그러나 해결 방법 또는 맞춤형 솔루션을 생성하여 데이터베이스에 직접 액세스하는 것이 더 쉽다는 개발자의 결정과 같이 다양한 이유로 마련되는 임시 솔루션인 시스템 부분 간에는 많은 연결이 있는 경우가 많습니다. 모듈식 인터페이스를 사용하는 것보다 이러한 연결의 엄청난 양과 고유성으로 인해 현대화 노력은 복잡해지고 시간이 많이 걸립니다.
이러한 복잡성을 줄이기 위한 첫 번째 단계는 핵심 시스템과 연결되는 애플리케이션 사이에 새로운 계층을 만드는 것입니다. 흔히 파사드(Façade)라고 부른다. 모든 새로운 연결은 ERP 시스템의 데이터에 액세스하는 API를 통해 이 파사드 레이어로 이동됩니다. 이러한 방식으로 수많은 연결이 핵심 시스템에서 분리됩니다. 이는 모든 연결 애플리케이션에 영향을 주지 않고 모듈식 아키텍처 측면 구현과 같이 시스템 내에서 변경을 수행할 수 있다는 큰 이점을 제공합니다. 외관은 1년 이내에 개발될 수 있습니다. 100% 완벽할 필요는 없습니다. 단지 기능적이어야 합니다.
그러나 개발자는 사용을 강제하는 효과적인 거버넌스가 없다면 좋은 외관조차 사용하지 않을 것입니다. 이를 수행하는 한 가지 방법은 예를 들어 오랜 승인 메커니즘을 거치지 않고 핵심 팀의 누군가가 개별 인터페이스를 구축할 때까지 기다리지 않고도 제품 팀이 핵심 기능에 액세스할 수 있도록 허용하는 것입니다. 이러한 "당근" 외에도 새로운 프로토콜을 따르지 않는 사람들에 대한 처벌과 같은 "채찍"도 필요할 수 있습니다.
플랫폼 플레이: 기술 회사처럼 운영하는 방법
2. 사용자 정의 추출
대부분의 핵심 시스템은 복잡한 보고 기능부터 맞춤형 액세스 프로토콜에 이르기까지 맞춤화되었습니다. 각 사용자 정의는 새로운 환경으로 마이그레이션되어야 하며 종종 어떤 방식으로든 수정되어야 하는데, 이는 해당 복잡성으로 인해 위험할 수 있습니다. 이 문제를 해결하려면 기업은 마이크로서비스를 통해 액세스할 수 있는 디지털 플랫폼(일반적으로 클라우드)을 구축해야 합니다. 디지털 플랫폼의 수와 기능은 다양할 수 있습니다. 예를 들어, 일부 회사에서는 고객 대면 기능을 위한 하나의 플랫폼, 공급망용 플랫폼, ERP 시스템 자체를 위한 플랫폼을 만들 것입니다. 플랫폼은 맞춤형 기능을 이동시킬 수 있는 곳이자 새로운 코드가 개발되는 곳이 됩니다.
어떤 사용자 정의가 가장 중요한지 평가하는 것이 중요합니다. 이 프로세스에서는 더 이상 필요하지 않고 제거할 수 있는 많은 사용자 정의 항목을 필연적으로 발견하므로 업그레이드가 단순화됩니다.
3. 코어 축소
코어에서 사용자 정의가 제거되면 코어 자체를 가장 필요한 기능으로 축소하기 시작해야 합니다.
이는 본질적으로 대규모 시스템에 내장되어 있는 복잡한 연결을 제거하는 분해 프로세스입니다. 이러한 방식으로 개발자와 엔지니어는 시스템의 다른 부분에 영향을 주지 않고 특정 기능을 교체하거나 개선할 수 있습니다. 이 프로세스에는 일반적으로 코드 베이스 정리도 포함되어 이해하기 쉬워지고 수정 또는 교체가 쉬워집니다.
앞에서 언급한 바와 같이 이러한 분리 프로세스는 ERP 시스템 내에서 표준 작업을 수행하는 회계 또는 통제와 같은 기능 영역을 건드릴 필요가 없습니다. 창고 관리, 수요 예측 또는 운송과 같이 기능적 이유 없이 긴밀하게 결합된 코어의 일부인 경우가 많은 기능만이 핵심 ERP 시스템 외부에 상주할 수 있는 후보입니다.
ERP 업그레이드는 대규모이고 복잡하며 필요합니다. 특히 비즈니스 압력이 증가하고 클라우드 및 ERP 제공업체가 새로운 소프트웨어와 서비스를 출시함에 따라 더욱 그렇습니다. 그러나 제품 및 플랫폼 접근 방식을 취함으로써 기업은 가치를 창출하는 업그레이드에 우선 순위를 부여하고 그렇지 않은 업그레이드의 위험을 줄일 수 있습니다. 이러한 방식으로 기업은 비용을 더 효과적으로 관리하고 결과를 개선할 수 있습니다.
저자 소개
Oliver Bossert 는 McKinsey 프랑크푸르트 사무소의 파트너, Florian Nocker 는 뮌헨 사무소의 파트너, Christoph Schrey 는 시카고 사무소의 파트너, Murat Soganci 는 도쿄 사무소의 제휴 파트너입니다.
|