먼저 예전에 썼던 data 관리에 관한 글을 전제로 하여 풀어 나갈 예정이므로, 먼저 링크의 글을 참고하시기 바란다. 그리고 이 글은 다음 글의 2번, 좋은 회사의 두 가지 방향성 가운데 하나인 system/best practice 중심의 회사에 대한 글의 보충이다. 그러니, 이 글도 읽어주시는 게 도움이 된다.
원래 쓰려고 했던 업무 효율성에 관해 연재될 글의 2번. 좋은 회사의 두 가지 방향을 넣으려고 했고, 그 중에 System/Best Practice 중심의 회사에 대해 쓰려다 보니 너무 길어질 것 같아서, 이를 독립시켜 IT System은 왜 항상 이 모양일까라는 내용으로 적어 보겠다.
1. 들어가며
회사에는 여러 가지 IT System이 존재한다. 많은 대기업들이 SAP나 Oracle의 ERP를 사용하고 있으며, 이에 추가하여 각종 SCM(Supply Chain Management) 시스템, SRM(Supply Relation Management) System, Order Management System, WMS(Warehouse Management System), CRM System, 원가 관리 System, MRP(Material Resource Planning) 시스템, 구매 발주 System, 생산공정의 MES System, PLM(Product Lifecycle Management) System, 리스크 관리 시스템, 수주 산업에서 Profoma 같은 일정 관리 시스템 등등을 별도로 운영하거나 ERP와 연동하여 운영한다.
이러한 IT System이 가지는 문제와 이것들이 회사에서 왜 잘 안 돌아가는지에 대해 몇 자 적어보고자 한다. 내용은 거의 전적으로 위의 링크 중 첫 번째 것과 대동소이하다.
2. IT System에 대해 가지는 전형적인 불만
2.1. 원하는 data가 없다
나는 일을 하면서 data를 다룰 일들이 많아서, 이 시스템을 통해서 data를 제공 받으려 하면 거의 항상 난관에 부딪쳤다. 그 이유는 첫 번째 글에 잘 나와 있다. 항상 내가 원하는 data는 없다. 그것이 중요하지 않다고 생각했기 때문에 관리되지 않았고 따라서 system에 data로 입력되어 있지도 않은 경우가 허다했다.
그러다 보니, 이미 존재하는 몇 개의 data를 나름의 가정으로 연결하여 완벽한 정합성을 가지는 data는 아니더라도 나름 궁여지책으로 다듬어서 사용할 수 밖에 없었다. 내가 가지는 불만은 한마디로 정리하자면 ‘왜 늘 내가 정말 원하는 data는 없는가?’가 첫 번째 불만이 된다. (물론 나름의 이유는 위에서 규명하였다.)
2.2. IT System 때문에 오히려 불편하고 일이 더 늘어났다
또 다른 불만은 IT System이 들어와서 일을 줄여주기는 커녕, 오히려 일이 더 늘어났다는 불만이 있다. 이것은 왜 그럴까? 이후에 밝혀 보기로 한다.
2.3. 막연한 불만과 불평
이건 IT System이 입이 없다 보니까, 회사에 불만은 있고 이 모든 원흉은 옆 부서 김부장인데, 김부장 XXX라고 욕하면 문제가 되기 때문에 ‘우리 회사는 System이 개판이야.’라고 하는 경우라 다루지 않고 넘어간다.
3. IT System 도입 시에 드는 망조
IT System은 많은 수작업을 컴퓨터가 자동으로 하게 해준다. 그리고, 각자의 PC에 나름의 방식으로 정리되어 있어 수많은 왜곡이 발생할 수 있는 것들을 모두 한 곳에 모아서 서로 연결시키고 통합하여 관리한다. 그래서, 효과적인 관리가 가능하게 한다. 다들 이런 이상을 가지고 돈을 들여서 IT System을 까는데, 늘 결과는 늘 신통치 않다. 왜 그럴까?
나는 IT Consulting을 해본 적도 없고, ERP의 MM 모듈 같은 거에 들어가서 직접 발주 한 번 내본적이 없고, MRP 한 번 돌려본 적이 없으니, 옆에서 지켜보면서 느낀 문외한인 제3자로서의 단상이라고 봐주시길 바란다.
IT System은 package화 되어 있어서, 이걸 그대로 회사에 깐다고 돌아가는 경우는 많지 않다. 그 회사의 업무와 matching을 시키기 위해서는 두 가지가 필요하다.
1. 그 회사의 업무 프로세스와 그 프로세스에서 나오는 중간 산출물(output)들을 IT System이 예정하고 있는 input과 output에 맞춰 줘야 한다.
2. 반대로 IT System도 해당 회사의 업무에 맞도록 표준 package를 그대로 깔지 않고, customize하여 사용하여야 하고, 표준 package에는 없는 해당 회사가 필요로 하는 추가 기능들을 add-on으로 개발해서 깔아 주어야 한다.
자, 여기서 문제가 발생한다.
3.1. 표준 프로세스의 부재와 현업 에이스의 차출 불가
회사가 주먹구구로 돌아가고 있어, 각 업무의 flow가 제대로 정의되어 있지 않고, 해당 세부 업무(activity)를 마치고 난 산출물(output)이 명확히 표준화되어 정의되어 있지 않다면, IT System에서 입력 값을 얻을 수 없다. 따라서, IT System을 깔기에 앞서 PI(Process Innovation)을 하게 된다.
BPR(Business Process Reengineering)이라 이름 붙이던 PI라고 이름 붙이던 어쨌거나 지금 하고 있는 업무를 바탕으로 그 업무를 쪼개고 각 업무의 연결 고리를 Flow로 연결하고, 그래서 나오는 결과는 output으로 정의해야 한다. 그 output은 IT System에 입력 가능한 형태로 표준화되어야 할 것이고….
ERP를 도입을 시도하다가 실패하거나, 도입은 하였으나 잘 돌아가지 않는 회사들은 대부분 여기서 삑사리가 난다. 내가 옆에서 살펴본 바에 의하면 망조는 두 가지 형태로 나타난다. 표준 프로세스가 없으니, 이걸 전산으로 옮기려고 하면 PI에 과도한 resource가 투입된다.
망조의 한 가지 방향은 회사의 모든 업무 프로세스를 표준화하자니, 엄두가 안 난다. 그래서, 대충 적당히 하고 끝낸다. 단순히 IT 시스템 도입을 위한 사전 준비인 PI(Process Innovation)이 언감생심 ‘혁신’ 또는 ‘변화 관리’라는 거창한 타이틀을 달고 있는 것은 이것이 단순히 전산 시스템을 깔기 위한 게 아니라, 회사의 현재까지 쌓인 업무 방식들을 재정비하고 그것을 표준화하는 과정이기 때문이다.
당연히 표준화해서 일을 한다고 해서 갑자기 돈을 못 벌던 회사가 엄청나게 수익이 좋아지거나 그러지는 않는다. 즉, 그 효과는 당장은 나타나지 않고, 다른 경쟁력 향상의 기반이 될 뿐이다. 따라서, IT 시스템이 망조로 가는 지름길이 열리는데, 바로 각 부서에서 자신들의 best practice를 참고하고 현재 업무를 개선하여 표준화하는 데 필요한 인력들이 차출된다.
그리고, 전형적으로 각 팀에서 에이스가 나서도 모자랄 이 일에 팀에서 당장은 없어도 되는 계륵 같은 존재들이 PI 또는 Change Agent라는 이름으로 차출된다. 당장 내 부서의 KPI 달성하는 게 중요하지, 전사적으로 장기간의 경쟁력 기반을 모호한 형태로 형성하는 일에 팀 에이스를 내주지는 않는다. 그래서, 이 프로젝트의 리더가 회장님 아들이 아닌 한 에이스 차출이 어렵다.
일을 잘 모르는 주니어들이 적당히 와서, ‘아마 이렇지 않을까’로 프로세스를 정립하면….. 정상적인 상황에서는 돌아가는데, 온갖 변동성이 발생하는 경우 IT System이 이를 예정하고 있지 않기 때문에 제대로 안 돌아간다.
그러면 에이스들은 빡쳐서 외친다. ‘아니, 뭐 System을 이 따위로 만들어 놨어.’
그래서, 그 프로세스를 가장 잘 알고, 발생할 수 있는 모든 경우의 수를 알고 그것들이 다 무리 없이 돌아가도록 처리하려면 팀에서 경험이 많고 똘똘한 에이스가 차출되어야 한다. 막상 시스템이 오픈을 하는 Go Live 시간은 잡혀 있고, 차출된 TFT 인력들은 이 생지옥에서 벗어나고 싶고, 자포자기 하는 심정으로 ‘어떻게든 돌아가게만 하고, 쓰다가 나중에 바로 잡자.’라는 생각을 하게 된다.
요약) 해당 부서의 업무 프로세스를 가장 잘 아는 사람이 모든 경우의 수와 trouble 상황을 고려하여 best practice가 되는 프로세스를 정립하여야 하나, 에이스들이 불참하여 trouble shooting 상황을 고려하지 않아 프로세스 혁신이 아닌 전산 시스템의 사전 준비로 마감됨.
3.2. 외부 전문가의 산업에 대한 이해 부족과 전체 operation 간의 상관 관계 통찰 미흡
나머지 한 방향의 망조는 IT System을 담당하는 컨설팅 업체나 전산 업체 쪽에서 발생한다. 이들은 해당 IT System의 전문가이고 다양한 경험을 가지고 있다. 이를테면 ERP 중에 독일의 SAP는 – 나는 SAP를 사랑한다. – 간결하고 명확한 프로세스를 염두에 두고 구성되어 있다. 아래와 같은 여러 개의 모듈로 구성되어 있다.
○ 회계관련 모듈
· 재무회계(FI : Financial Accounting)
· 관리회계(CO : Controlling)
· 자금관리(TR : Treasury)
○ 물류관련 모듈
· 판매 및 영업관리(SD : Sales and Distribution)
· 구매 및 자재관리(MM : Materials Management)
· 생산관리(PP : Production Planning)
· 품질관리(QM : Quality Management)
· 설비관리(PM : Plant Maintenance)
○ 인사관리관련 모듈
· 인사관리(HR : Human Resources)
문제는 여기서 일하는 컨설턴트도 사람인지라 해당 모듈에 대한 전문가일 수는 있지만, 회사의 전체 운영을 모르고, 해당 산업에 대한 이해도도 높지 않을 수 있다. 그러면, 해당 산업이나 회사와 맞지 않는 표준 모듈에서 벗어나려고 하지 않거나, 이후에 미칠 파장을 고려하지 못한 채로 프로세스와 시스템을 정립할 수도 있다.
참 아이러니한 상황인 것이, 현업의 에이스는 회사 Operation과 Process를 꿰뚫고 있어야 하고, 컨설턴트는 이를 어떻게 표준화해서 System으로 옮겨낼까에 대해 역할을 나누어야 할 터인데, 둘 다 해당 회사의 전체를 조망할 수 있는 통찰력이 없으면, 혁신 프로젝트가 아니라 단순 전산 시스템 도입 프로젝트가 된다.
요약) 컨설턴트가 해당 산업에 대한 이해 부족, 해당 프로세스가 전체 operation에 미치는 영향과 관련성에 대한 인식 부족으로 단순히 해당 모듈 전문가일 경우, 몸에 맞지 않는 표준 Package를 입게 되거나 몸에 맞추다 보니, 다른 프로세스에서 구멍이 숭숭 뚫린 옷을 입게 된다.
4. IT System 도입 후에 벌어지는 처참한 결과
4.1. 중복 작업
이렇게 어떻게든 기한에 맞춰 open한 IT System은 현업의 실무와 유리되어 전산 시스템으로 돌아간다. 시스템에서 실시간으로 업무가 돌아가는게 아니라, 예전처럼 각자 PC에서 엑셀로 일은 다 해놓고, 다시 그걸 시스템에 입력한다. 시간이 더 걸린다.
4.2. 실물과 전산의 불일치
여전히 결재판이 돌아다니고 출력하여 검수한다. 실물과 ERP 상의 데이타는 하나도 안 맞는다. 즉, ERP 상에는 부품 재고가 10대분이 있다고 나와 있는데 실물로는 9개가 있거나 11개가 있다. 게다가, 예전 같으면 수정 권한이 있어서 실물을 보고, 결재를 받은 후에 전산에 들어가서 수정하면 되었는데, ERP는 그걸 금지하고 있다. 이제 입이 나와서 ‘아니 이런 X, 누구 좋으라고 돈 들여서 이런 XX 같은 걸 깔아놨어.’
4.3 일과 전산의 불일치
시스템 상에서는 중간에 이러이러한 중간 산출물이 나와서 다음 부서로 넘기면 그걸 바탕으로 어떻게 처리하라고 설계 되어 있으나, 일을 그렇게 하지는 않는다. 일은 그냥 한 부서에서 알아서 하도록 백지 위임하고, ERP 권한만 가지고 입력만 대행해 준다.
4.4. Data 입력을 위한 업무 증가
예전에는 좋은 게 좋은 거고, 그냥 알음 알음해서 하던 일들이 많았는데 (예를 들면, 보유하고 있는 자재들의 전체 중량만 관리하면 되었는데, 이제 종류 별로 각각의 중량을 다 입력하도록 설계해 놓았다.) 이제 같은 것은 같게 다른 것은 다르게 다 관리를 하라고 한다. 인력을 추가로 지원해 준 건 없는데, 업무량은 늘었고, 다시 한 번 ‘아니 X, 전산이라는 게 사람 일을 편하게 해주라고 있는건데, 돈 들여서 깔아놨더니 별 쓸 데 없는 걸 다 집어넣으라고 해서, 오히려 일을 만드네 만들어.’
5. 그래도 ERP 등 전산 시스템의 도입이 혁신인 이유
위에서 살펴본 바와 같이 ERP와 같은 IT System 도입의 Key Success Factor는 사전 PI(Process Innovation)가 잘 되어야 하고, 이와 더불어 중요한 것이 바로 사후의 변화 관리이다.
만약에 어떤 회사가 정말 아름다운 프로세스의 오퍼레이션 역량을 가지고 있다고 하자. 모든 것은 다 측정되고 관리되고, 표준화 되어 있고, 그에 따라 모든 사람들이 일하고 있다고 하자. 위에서 언급한 [좋은 회사의 두 가지 방향]에서 전자에 해당하는 System/Best Practice 중심의 좋은 회사라고 하자.
이들은 아직 ERP는 도입하고 있지 않다가 ERP 도입을 검토하기로 했다. 이들에게 ERP가 똑바로 돌아가지 않을 이유가 없다. 그리고, 도입 후에 매우 편해지고, 커다란 성과를 거두게 될 것이다. 그 이유는 이미 그들은 완벽하게 PI가 되어 있고, 따라서 단순히 지금하고 있는 일을 전산으로만 옮기면 되기 때문이다.
각 부서가 해야 할 일은 다 정의되어 있고, 그에 따라 필요한 양식과 근거들이 모두 표준화되어 있고, 실제로 모든 부품의 표준 재고가 설정되어 있고, 실시간으로 그 재고가 파악되고 있고, 모든 작업자의 동작이 분석되어 있으며 그 동작의 소요 시간이 표준에 반영되어 있고, 실제로 그에 따라서 일을 하고 있다면, 그냥 그걸 ERP라고 하는 그릇에 담으면 된다.
도요타가 ERP를 도입하지 않았거나 도입하였다고 하더라도 매우 늦게 도입한 걸로 아는데, 도요타면 200조가 넘는 회사임에도 불구하고 PI 기간이 그렇게 오래 걸리지 않을 거라 예상한다. 그리고, 그렇게 ERP를 깔고 난 다음에 하는 일도 손으로 기입하거나 Excel에 하던 걸 ERP에서 실시간으로 입력하거나 조회하면 되기 때문에 오히려 일이 줄어든다.
좋은 회사의 두 가지 방향 중에서 System 중심의 회사는 IT System을 통해서 일이 딱딱 돌아가도록 된다. 굳이 다른 사람과 커뮤니케이션 할 필요 없이도 각자가 맡은 바를 충실히 하여 Forwarding을 하면 결과가 아름답게 나온다. 모든 것들을 큐브처럼 쪼개고 그 개별 큐브의 일이 완결성을 가져서, 모아 놓으면 커다란 최종 결과물이 완벽하게 돌아간다.
이게 System 중심의 회사가 추구하는 모습일 것이다. (동기 부여 중심의 회사는 이와 다르다.) 각 부서에서 하는 일들이 각자의 완결성을 가지고 있어, 각 업무를 완료하고 후행 부서로 Forwarding하면, 최종 결과로서 그 일이 잘 된다는 가정하에서 그러한 수준까지 PI를 통해 도달하고자 한다.
물론 그 정도의 수준에 도달하기 어려우니 그 일들을 전체적으로 조율하고 각 기능 부서 간의 이해 관계가 아닌 전사의 이익을 위하도록 Cross Functional한 조직을 만들기도 하고, 시어머니인 Control Tower를 두기도 하고, 하나의 조직에서 유한한 가용 자원을 기민하게 대처하며 사용하도록 Functional Organization이 아닌 사업부제를 운영하기도 하지만.
ERP가 혁신이요 변화 관리인 이유는 ERP 도입을 계기로 PI를 하기 때문이다. 기존에 문제가 있는 주먹 구구식으로 운영되던 프로세스를 뜯어 고치고 Best Practice로 재정립하는 기회로 삼기 때문에 ERP 도입을 혁신으로 포장하고, Process “Innovation”이라는 거창한 이름을 붙인다. 그리고, 그렇게 변화된 업무 방식과 프로세스를 사람들이 따르게 하기 위한 변화 관리가 필요하다.
그러나, 실제로 그러한가? PI는 개판이고, 사후 변화 관리도 역시 처참하여 주먹구구식 프로세스가 전산에 반영되고, 이후에 주먹구구식 프로세스나 쓸데 없는 삽질 프로세스가 들어간 일을 하며 불만이 쌓인다. 마치 공부를 잘 하는 아이는 새로운 걸 배울 때 이미 알고 있는 지식이나 기반이 튼튼하기 때문에 오히려 공부해야 할 양이 상대적으로 줄어든다. 잘 되는 집은 잘하고 있는 게 다른 일을 더 잘하게 하는 기반이 된다.
서로서로 노력해야 IT는 도움이 된다
그냥 여기까지 써야겠다. IT System이 문제가 아니라, IT System이 반영하고 있는 실제로 돌아가는 업무 자체가 문제고, 그 간극을 메우기 위한 PI(Process Innovation)에 충분히 노력을 들이지 않으면, IT System 도입은 혁신이 아닌 돈만 먹는 요물이 될 것이다.
그리고, 현업은 자기들의 업무를 반영하는 거니까 에이스들 좀 보내고, 컨설턴트는 자기 모듈 말고, 그 앞뒤 뿐만 아니라 전체 회사의 흐름에 대한 이해를 높이기 위해 노력해야 한다. 공동의 팀으로 일할 테니, 서로 힘을 합쳐야 제대로 된 결과물이 나올 것이다. 뭐, 항상 그렇듯이 프로젝트가 빠그러지면, 서로를 탓할 것이고.
이상. IT 컨설팅은 해본 적도 없지만, 부실한 IT System 때문에 data 모으느라 고생한 1인이.
원문 : darrel76
