[IT지식 칼럼] 디지털 전환의 축
정인호 PM, Management Contents.
인터넷에서 ERP 컨설팅 Best Practice 구축 성공 사례를 찾던 중 우연히 남미 대륙 쪽에 한 ERP 컨설팅 전문가가 올린 내용을 보고서 참신한 내용이 있어서 계속 자료를 받아 보다가, 하나의 일관된 주제를 찾았는데, 그 메시지는 본인과 같은 수준의 컨설턴트를 만나는 것이 그 어떤 기업에게는 큰 행운이라는 것이었습니다. 과장된 듯 하지만, 국내에서도 그와 비슷한 경력을 가진 전문가가 더욱 상세하게 기술적인 내용까지 곁들여서 매우 유익한 내용으로 가득한 책도 있었는데, 역시 유능한 컨설턴트의 희소성에 대하여 강조하고 있었습니다.
국내에서는 1990년대 초반 즈음부터 ERP가 부각되면서 동시에 BPR, 혹은 Best Practice라는 용어가 마치 ERP에 탑재된 사양인 것처럼 인식되어 오다가, 최근에는 ERP가 BPR 도구라고 내세우는 경우는 관련 사업체 누구도 언급을 회피하는 것 같은 느낌이 들 정도로 희소해 진 것 같습니다.
이번에는 그러한 상황에 대해서 가볍게 한번 짚어보았으며 합니다.
ERP에는 환경 설정이라는 기능 영역이 있습니다. 그리고 ERP의 구축에 대해서는 Customization이냐 Configuration이냐를 놓고 갑론을박도 있습니다. 그리고 그 중심에 환경설정의 역할에 대한 논의가 깊이 있게 다루어져야 하는데, 아직 제 기억으로는 그 ERP 시스템의 운영 환경 설정에 대해서 상세하게 다루는 경우를 별로 못 본 것 같습니다.
ERP가 국내에 도입 된 이후 이제는 거의 필수 항목으로 자리를 잡았는데, 최근 들어서는 ERP 환경 설정과 BPR, 혹은 ERP 환경 설정과 Best Practice의 구성과 같은 제목으로 구체적인 성공 사례 혹은 구축 사례를 언급하는 경우를 별로 못 보게 된 데에는, 아마도 이제는 ERP 도입 초기에, ERP가 곧 BPM 혹은 Best Practice라는 총론적인 관점으로의 접근은 특별한 사항이 될 수 없고, 영업에 도움이 되지 않기 때문이기도 하며, 실제 BPR이라고 말할 수 있을 정도의 프로젝트는 통상 중견 기업 이상 규모의, BPR 비용을 감당할 수 있을만한 규모가 되어야 할 텐데, 그런 기업들은 그 성공과 실패의 여부를 떠나서 이미 투자를 완료한 상태이기 때문이 아닌가 생각됩니다. 그리고 또 한편으로는, 이제는 그 BPR 사례를 언급하려면 말로나 혹은 제안서에 올리는 수준이 아니라 실제 ERP 구축 및 BPR 운영의 사례를 제시해야하는 단계인 관계로, 부담이 되고, 그래서 다소 불편한 것은 아닐까 생각해 봅니다.
ERP 구축 경험이 쌓인 Vendor의 경우에는, 정상적인 수준의 소프트웨어 업체라면, 그 시스템 안에 그들의 구축 경험을 심어 두게 마련이며, 자연히 Best Practice (이하 BP)와 BPR을 위한 기능적인 요소와 업무 논리의 전개를 위한 경우의 수를 Metrics 형태로, 혹은 함수 형태로 일종의 Library 상태로 관리를 할 것입니다. 그리고 그 ERP의 기능 프로그램의 재사용을 위해 SOA (서비스 지향적인 객체 구조의 지향) 방식으로 구현을 합니다.
이렇게 구축된 기능 요소들은 ERP 시스템 안에서 각각 다른 형태로 존재합니다. 환경 설정이라는 기능 영역에서는 업무 규칙이나 절차의 방법과 적용 여부를 설정하고, 마스터 데이터 관리 영역에서는 각 운영 자원들의 속성을 설정하여, BP의 구현을 위한 디지털 체계를 세웁니다.
그런데, 이 부분의 이해가 일반인의 수준으로는 감당하기 어렵다는 데 문제가 있습니다.
그리고 어렵게 되는 가장 큰 이유는 그 적용 방식에 있는 것 같습니다. 즉, ERP 시스템이 기술적인 관점으로 전개된다는 것입니다. 디지털 정합성의 관점으로 ERP 시스템이 전개되고, ERP 전문가 수준의 역량이 필요하며, 주로 ERP 구축 컨설팅 생산성 중심으로 진화해온 구조이기 때문일 것입니다.
즉 UX (User Experience)는 그 안에 존재하지만 부분적으로만 보이게 되는데, 예를 들어본다면, ERP 전문가들은 먼저 Master Data를 설정하려고 합니다. 왜냐하면 그 영역이 이후 모든 프로그램의 전개 방식에 영향을 주기 때문입니다. 그런데 정작 사용자는 Master Data라는 개념 자체가 별로 와 닿지 않을 것입니다. 물론 기업 내부에 정보시스템 담당 부서, 즉 전산실이라는 조직이 있다면 말은 잘 통하겠습니다만, 그렇다면 ERP Vendor의 BP 혹은 BPR 구현에 대한 책임은 그 순간에 모호해 지고 말 것입니다. 즉 ERP 구축 책임의 한계가 기업측으로 기울어 지며, ERP 업체의 구축 영역은 원가 맞추기, 즉 그들의 시스템이 제공하는 논리가 원가, 그리고 재무제표라는 커다란 함수와 그 연산 공식의 정답 확인 및 도출을 위한 일부 조정 작업으로, 자연스레 한정될 것입니다.
기업 규모가 더 커서, 그 전산실이 정보화 전략을 구축하고, 기업의 업무 프로세스를 변화시키는, 즉 기업의 전사적 BPR을 담당하는 위치에 있다면 모르겠으나, 그런 경우는 극소수일 것입니다.
그러면 다른 방식으로 접근해서, 기업 사용자가 그 마스터 데이터와 업무 환경 설정을 왜 해야하는 가에 대한 접근으로 진행해 본다면 어떨까 생각해 봅니다. 즉 그 기초 정보를 구축하는 이유가 결국은 재무제표의 올바른 출력을 위한 사전 준비 단계이며, 그들이 기존에 해오던 업무 처리 방식과 정보와는 어떻게 연계되는지를 제시하고, 그 기초 정보들이 다시 그들의 본연의 업무 처리에 어떻게 나타나서 그들의 업무를 정확하고 투명하며, 일관성 있게 하고, 그로부터 도출된 정보들이 어떻게 경영자의 의사 결정에 반영되어, 다시 각 현업의 업무 평가로 이어지는 지 그 순환 Cycle을 제시하는 방식으로 바꾸어 본다면 그 자체로 BPR이 되고, 그 결과로 현업은 디지털 시스템의 속성을 이해하게 되며, 그 결과로 기업 스스로 자율적으로 BP를 만들어가는 디지털 문화가 형성되지 않을까 합니다. ERP 구축 기간과 비용이 문제가 예상되는 것도 사실입니다.
칼럼의 제목과 같이 디지털 전환의 축이 누구인가에 대하여, 다시 돌아가 본다면, 최근까지도 명쾌히 풀리지 않는 논의가 CIO, CDO (Chief Data Manager), 혹은 전산실의 Position에 대한 것입니다.
분명한 것은 그 Position을 ERP 업체가 취할 수는 없습니다. 간혹 최근까지도 그런 경우가 있었습니다만, 글로벌 최고 명성의 컨설팅 전문 업체에 모든 것을 믿고 맡겼다가 실패 사례로서 법정으로 가는 경우를 가끔 보게 됩니다. 전 세계적으로 클라우드 ERP 사업이 기대했던 폭발적인 이익 창출이 안되는 이유도 이와 많이 다르지 않을 것입니다.
기업이 스스로 변한다는 것은, 혹은 기업 각각 그 내부에 완벽한 CIO 혹은 CDO를 가지게 되는 것은 극소수의 경우가 될 것이며, 해답은 기업 자율 역량의 강화이지만, 그것을 위한 해결책은 ERP 업체와 전문 컨설팅 업체가 어떻게 변해야 할 것인가의 문제일 것 같습니다. 왜냐하면 그들은 축적된 정보가 있고, 경험을 보유한 전문 인력이 있으며, 더더군다나 이 영역이 바로 사업의 기회이기 때문이며, 그들이 변화해 가야할 그 디지털 서비스의 전환을 위한 축 또한 내부에 있어서 대부분 그들 내부의 변화만으로도 엄청난 개선을 이룰 수 있을 것이기 때문입니다.