2015.09.23

박승남의 畵潭 | 패키지 혹은 프로크루스테스의 침대?

박승남 | CIO KR


일상에서 7

소프트웨어 패키지를 버립시다!
오늘은 조금은 도발적인 주제를 이야기하려 합니다.
(휜 것을 펴려면 반대로 세게 힘을 주어야 하기 때문에, 그리고 논쟁에서 한편에 서면 약간의 진영논리가 생기기 때문에 조금 한쪽에 치우친 의견이 포함되어 있음을 이해 부탁 드립니다.)

그리스신화에 프로크루스테스라는 도적이 나옵니다. 이 도적은 아테네 교외에 살면서 지나가는 나그네를 집으로 유인한 뒤 쇠침대에 눕히고, 신장이 침대보다 길면 수족을 절단하고 짧으면 뽑아 늘여 죽였다고 합니다. 여기서 융통성이 없거나 자기가 세운 일방적인 기준에 다른 사람들의 생각을 억지로 맞추려는 아집을 비유하는 ‘프로크루스테스의 침대’라는 말이 생겨났습니다.

스프트웨어 패키지, 특히 ERP패키지를 보면 이 프로크루스테스의 침대가 떠오릅니다. 원래 전산은 사용자의 프로세스를 수용하여 자동화하는 것인데, 반대로 ERP패키지는 ERP시스템의 프로세스를 사용자가 따라 해야 하는 특이한 구도입니다. 물론 과거에는 현업의 프로세스가 ERP의 프로세스에 비하여 뒤쳐져 있었고, 그 동안 ERP패키지가 각 산업의 발전에 기여해 온 것은 충분히 인정합니다. 하지만 이제는 IT가 범용기술이 되고 고객의 IT수준이 높아졌고, 일상적으로 발생하는 고객의 프로세스 혁신활동을 IT패키지가 따라잡을 수 없어 발목을 잡는 현상이 발생하고 있습니다. 그리고, 소프트웨어 패키지는 수 많은 고객들의 요건을 모두 수용하는 범용성 때문에, 장점도 있지만 고객에 특화되지 못하고 성능 면에서도 손실이 있을 수 밖에 없습니다. 여러분은 패키지의 기능 중 실제 얼마나 사용하고 있습니까?

저는 이제 IT패러다임을 다시 원래대로 바꿔야 한다고 생각합니다.
고객의 요건이 목적이고 IT는 방법입니다. 그런데, 지금의 일부 소프트웨어 패키지를 보면 목적과 방법이 바뀐 것 같습니다. 이제는 IT시스템에 현업 프로세스를 맞추는 것이 아니라, 다시 처음으로 돌아가서 현업 프로세스에 맞게 시스템이 지원되어야 합니다.
이를 위해, 소프트웨어 제조사는 다양한 고객의 요건을 수용할 수 있는 좀 더 유연한 패키지를 만들어야 하고, 환경과 능력이 되는 기업은 자체개발을 활성화해야 한다고 생각합니다.

패키지는 패키지 대로의 이점이 있듯이, In-house 개발에는 다음과 같은 이점이 있습니다.
1. 현업의 요구와 프로세스 혁신에 빠르고 정확하게 발 맞출 수 있고,
2. 불필요한 모듈이 없기 때문에 고성능을 제공하고, 저비용으로 구축이 가능하고,
3. 패키지를 제공하는 S/W벤더사로부터, CIO를 일상적으로 괴롭히는 License issue로부터 자유로워집니다.

제가 지금 다니는 회사에서 경험한 사례를 보면 이러한 시도가 충분히 가능하다고 생각합니다.

1. 그룹의 2개 계열사만 S사의 ERP 패키지를 사용하고 있고, 그 외 10여개사는 자체 개발한 ERP를 사용하고 있습니다. 현업만족도, 유연성, 비용 등 대부분 분야에서 자체 개발한 ERP가 우수하다고 평가하고 있습니다. 그리고, 최근에 그룹에서 인수한 회사에서 사용하던 O사의 ERP를 자체 ERP로 재구축중입니다.

2. 그룹내 물류회사에 S사의 C물류패키지를 도입하려 했습니다. 그런데, C패키지와 고객사의 프로세스의 큰 Gap때문에 패키지에서 고객사의 프로세스 수용이 어려워서 프로젝트가 난항을 겪다가, 결국 자체 개발로 방향을 선회하여 완료할 수 있었습니다.

3. 공장내 많은 설비들을 관리하기 위해 I사의 패키지를 사용하고 있었습니다. 분석을 해보니 2년간의 소프트에어 유지보수비면 자체개발을 할 수 있었습니다. 패키지를 대체하여 자체 개발한 결과, 이전보다 매우 높은 응답속도와 고객만족, 비용절감을 얻었습니다.

물론 자체 개발로 모든 것을 해결할 수도 없고, 대부분 회사가 자체 개발이 어려운 환경입니다.

위의 저희 그룹 경우도 In-house 개발이 가능했던 배경에는, 철강산업특성과 업계1위로서의 차별화된 그리고 자부심이 있는 회사의 프로세스가 타 회사에 비하여 ERP 패키지와 Gap이 컸고, 이를 수용하기에는 패키지의 수정이 너무 많이 필요하여 패키지 도입의 의미가 줄어들었고, 업무지식이 충분한 SM과 SI개발인력이 있어서, 특화된 프로세스를 살릴 수 있는 자체개발을 추진할 수 있었던 면도 있습니다. 그리고 기술적으로는 소프트웨어 개발 Tool, 각종 Framework가 발전했기에 자체 개발이 가능했습니다. 이점도 있지만 자체개발 시 글로벌 지원, 기술인력 수급, 규모의 경제필요, OS Update 등에 따른 변경관리 등 문제점과 단점 또한 많이 존재합니다.

자체개발을 화두로 던졌지만, 저 또한 기업의 조직/업무 특성과 IT인력구조 등의 IT환경에 따라 패키지가 적합한 영역이 여전히 더 많이 존재한다고 생각합니다.

하지만, 원래 프로그램을 개발하던 전산실이 이제는 지나친 Outsourcing 여파로 본연의 핵심역량도 기능도 잃어버리고 IT 구매부서가 되어 가는 것 같아서, 어느 정도는 ‘균형’ 있는 ‘자주적’ IT를 구현하자는 생각으로 제 의견을 몇 자 적었습니다.


침대가 위의 그림처럼 기요틴(길로틴)이 되어서는 안 되는 것처럼,
IT가 현업프로세스 혁신의 걸림돌이 되어서는 안되겠습니다.
이제는 밖에서 파는 도시락만 살 것이 아니라, 가끔은 집밥도 해먹어야 하지 않을까요?

*박승남 상무는 현재 세아그룹의 IT부문을 이끌고 있으며, 이전에는 대교 CIO를 역임했으며, 한국IDG가 주관하는 CIO 어워드 2012에서 올해의 CIO로 선정됐다. CIO로 재직하기 전에는 한국IBM과 시스코시스템즈코리아에서 21년 동안 근무했다. ciokr@idg.co.kr
 



2015.09.23

박승남의 畵潭 | 패키지 혹은 프로크루스테스의 침대?

박승남 | CIO KR


일상에서 7

소프트웨어 패키지를 버립시다!
오늘은 조금은 도발적인 주제를 이야기하려 합니다.
(휜 것을 펴려면 반대로 세게 힘을 주어야 하기 때문에, 그리고 논쟁에서 한편에 서면 약간의 진영논리가 생기기 때문에 조금 한쪽에 치우친 의견이 포함되어 있음을 이해 부탁 드립니다.)

그리스신화에 프로크루스테스라는 도적이 나옵니다. 이 도적은 아테네 교외에 살면서 지나가는 나그네를 집으로 유인한 뒤 쇠침대에 눕히고, 신장이 침대보다 길면 수족을 절단하고 짧으면 뽑아 늘여 죽였다고 합니다. 여기서 융통성이 없거나 자기가 세운 일방적인 기준에 다른 사람들의 생각을 억지로 맞추려는 아집을 비유하는 ‘프로크루스테스의 침대’라는 말이 생겨났습니다.

스프트웨어 패키지, 특히 ERP패키지를 보면 이 프로크루스테스의 침대가 떠오릅니다. 원래 전산은 사용자의 프로세스를 수용하여 자동화하는 것인데, 반대로 ERP패키지는 ERP시스템의 프로세스를 사용자가 따라 해야 하는 특이한 구도입니다. 물론 과거에는 현업의 프로세스가 ERP의 프로세스에 비하여 뒤쳐져 있었고, 그 동안 ERP패키지가 각 산업의 발전에 기여해 온 것은 충분히 인정합니다. 하지만 이제는 IT가 범용기술이 되고 고객의 IT수준이 높아졌고, 일상적으로 발생하는 고객의 프로세스 혁신활동을 IT패키지가 따라잡을 수 없어 발목을 잡는 현상이 발생하고 있습니다. 그리고, 소프트웨어 패키지는 수 많은 고객들의 요건을 모두 수용하는 범용성 때문에, 장점도 있지만 고객에 특화되지 못하고 성능 면에서도 손실이 있을 수 밖에 없습니다. 여러분은 패키지의 기능 중 실제 얼마나 사용하고 있습니까?

저는 이제 IT패러다임을 다시 원래대로 바꿔야 한다고 생각합니다.
고객의 요건이 목적이고 IT는 방법입니다. 그런데, 지금의 일부 소프트웨어 패키지를 보면 목적과 방법이 바뀐 것 같습니다. 이제는 IT시스템에 현업 프로세스를 맞추는 것이 아니라, 다시 처음으로 돌아가서 현업 프로세스에 맞게 시스템이 지원되어야 합니다.
이를 위해, 소프트웨어 제조사는 다양한 고객의 요건을 수용할 수 있는 좀 더 유연한 패키지를 만들어야 하고, 환경과 능력이 되는 기업은 자체개발을 활성화해야 한다고 생각합니다.

패키지는 패키지 대로의 이점이 있듯이, In-house 개발에는 다음과 같은 이점이 있습니다.
1. 현업의 요구와 프로세스 혁신에 빠르고 정확하게 발 맞출 수 있고,
2. 불필요한 모듈이 없기 때문에 고성능을 제공하고, 저비용으로 구축이 가능하고,
3. 패키지를 제공하는 S/W벤더사로부터, CIO를 일상적으로 괴롭히는 License issue로부터 자유로워집니다.

제가 지금 다니는 회사에서 경험한 사례를 보면 이러한 시도가 충분히 가능하다고 생각합니다.

1. 그룹의 2개 계열사만 S사의 ERP 패키지를 사용하고 있고, 그 외 10여개사는 자체 개발한 ERP를 사용하고 있습니다. 현업만족도, 유연성, 비용 등 대부분 분야에서 자체 개발한 ERP가 우수하다고 평가하고 있습니다. 그리고, 최근에 그룹에서 인수한 회사에서 사용하던 O사의 ERP를 자체 ERP로 재구축중입니다.

2. 그룹내 물류회사에 S사의 C물류패키지를 도입하려 했습니다. 그런데, C패키지와 고객사의 프로세스의 큰 Gap때문에 패키지에서 고객사의 프로세스 수용이 어려워서 프로젝트가 난항을 겪다가, 결국 자체 개발로 방향을 선회하여 완료할 수 있었습니다.

3. 공장내 많은 설비들을 관리하기 위해 I사의 패키지를 사용하고 있었습니다. 분석을 해보니 2년간의 소프트에어 유지보수비면 자체개발을 할 수 있었습니다. 패키지를 대체하여 자체 개발한 결과, 이전보다 매우 높은 응답속도와 고객만족, 비용절감을 얻었습니다.

물론 자체 개발로 모든 것을 해결할 수도 없고, 대부분 회사가 자체 개발이 어려운 환경입니다.

위의 저희 그룹 경우도 In-house 개발이 가능했던 배경에는, 철강산업특성과 업계1위로서의 차별화된 그리고 자부심이 있는 회사의 프로세스가 타 회사에 비하여 ERP 패키지와 Gap이 컸고, 이를 수용하기에는 패키지의 수정이 너무 많이 필요하여 패키지 도입의 의미가 줄어들었고, 업무지식이 충분한 SM과 SI개발인력이 있어서, 특화된 프로세스를 살릴 수 있는 자체개발을 추진할 수 있었던 면도 있습니다. 그리고 기술적으로는 소프트웨어 개발 Tool, 각종 Framework가 발전했기에 자체 개발이 가능했습니다. 이점도 있지만 자체개발 시 글로벌 지원, 기술인력 수급, 규모의 경제필요, OS Update 등에 따른 변경관리 등 문제점과 단점 또한 많이 존재합니다.

자체개발을 화두로 던졌지만, 저 또한 기업의 조직/업무 특성과 IT인력구조 등의 IT환경에 따라 패키지가 적합한 영역이 여전히 더 많이 존재한다고 생각합니다.

하지만, 원래 프로그램을 개발하던 전산실이 이제는 지나친 Outsourcing 여파로 본연의 핵심역량도 기능도 잃어버리고 IT 구매부서가 되어 가는 것 같아서, 어느 정도는 ‘균형’ 있는 ‘자주적’ IT를 구현하자는 생각으로 제 의견을 몇 자 적었습니다.


침대가 위의 그림처럼 기요틴(길로틴)이 되어서는 안 되는 것처럼,
IT가 현업프로세스 혁신의 걸림돌이 되어서는 안되겠습니다.
이제는 밖에서 파는 도시락만 살 것이 아니라, 가끔은 집밥도 해먹어야 하지 않을까요?

*박승남 상무는 현재 세아그룹의 IT부문을 이끌고 있으며, 이전에는 대교 CIO를 역임했으며, 한국IDG가 주관하는 CIO 어워드 2012에서 올해의 CIO로 선정됐다. CIO로 재직하기 전에는 한국IBM과 시스코시스템즈코리아에서 21년 동안 근무했다. ciokr@idg.co.kr
 

X