서울 
청주 
부산 
제주 
▲ 이성우 칼럼니스트
가죽, 고치다를 의미하는 혁(革)자가 있다. 새신(新)과 함께해 혁신(革新)이라는 글자를 만든다. 가죽을 새롭게 한다는 뜻인 만큼 어렵고 고통스러운 변화를 의미한다. 하지만 일상생활에서는 너무도 쉽게, 자주 혁신이 필요하다고 얘기된다.
주역에는 택화혁(澤火革)이라는 괘를 설명한다. 연못이 위에 있고 아래에 불이 있으니 연못의 물과 불이 서로 힘을 겨루면서 대립하고 있는 상황이다. 큰 변화가 필요함을 의미한다.
물이 불보다 강하면 불이 꺼지고, 불이 물보다 강하면 물은 증발해 없어져 버린다. 결국 어떤 변화를 원하든지 때가 중요한 것이다. 혁신도 때가 되면 이뤄질 수 있는 것이다. 때를 기다릴 줄 알아야 한다.
기업 8괘의 경우는 연못은 리더나 경영자고 불은 고객이나 제품이다. IT조직관점에서는 IT를 비용으로만 인식하고 압력을 가하고 있는 경영자고 고객은 현업의 시스템 사용자로 설명할 수 있다.
실제 시스템을 사용하는 사람들은 IT의 필요성을 인식하고 있으나 눈에 보이는 결과를 선호하는 경영자들은 IT를 비용의 블랙홀로 인식하고 있는 상황이다. 근본적인 변화가 필요한 상황이다. IT 개발방법의 혁신을 통해 획기적인 비용절감에 기여하고 있음을 증명해야 하는 상황이다.
정보시스템은 무형의 데이터, 정보들을 만들어 내고 이를 활용해 현상에 대한 조회, 분석, 이력관리 등을 제공한다. 업무처리 및 의사결정을 지원해 주는 것이 주요 기능이다. 실제 진행하고 있는 일들을 대행해 주기 때문에 업무처리를 하는 실 사용자들의 입장에서는 도움이 되는 것을 느낄 수 있으며 필요성을 강조하게 된다.
하지만 주로 의사결정을 하는 경영진들은 실제 업무를 하는 것이 아니라 판단을 주로 하기 때문에 정보시스템에서 제공되는 기본 정보에는 항상 뭔가 부족한 것을 느끼게 된다.
물론 수많은 정보들이 존재하지만 여러 단계의 분석, 추출 과정을 거쳐야 간접적으로 의사결정에 필요한 정보들을 받아 볼 수 있게 된다. 그래도 아직 필요한 정보를 충분히 얻지 못하기 때문에 경영진들은 투자대비 효과에 대한 불만을 계속 가지게 되는 것이다.
근본적인 문제는 현재의 업무처리 방식과 의사결정 방법 사이에 큰 차이가 존재한다는 것이다. 비즈니스 프로세스를 개선하거나 혁신을 해야 차이를 줄일 수 있다. 이는 정보시스템 운영과는 다른 차원이므로 우선 운영 차원에서 혁신을 어떻게 해야 하는지 점검해 보겠다.
IT 개발 업무 R&R 재정립
시스템의 개발방법을 바꾸기 위해서는 우선 관련인력부터 확인해 봐야한다. 시스템을 요구하는 사용자가 있으며 시스템 구축 및 관리를 책임지는 IT 조직과 실제 시스템을 개발하고운영하는 외주벤더가 있다.
세 가지 부문들이 SDLC(Software Development Life Cycle)라고하는 프로그램 개발주기 과정에 관여한다. 하지만 앞서 얘기했듯이 외주업체가 대부분의 과정을 책임지고 운영하고 있는 것이 현실이다. IT 조직은 계약 및 예산확보를 중심으로 벤더관리수준의 업무를 진행 한다.
여기서 모순이 발생 한다. 기업이 경영환경에 맞는 시스템을 개발하기 위해서는 자신들의 요구사항을 제대로 요구하고, 이를 시스템으로 구현하기 위해서 현재와 미래의 Gap을 분석하고 외주벤더에게 개발을 의뢰해야 한다. 하지만 실상은 전체를 외주벤더에 의존하고 있다.
내 일을 남이 대신하고 있으니 문제는 없다. 하지만 비용통제가 안되고 To-Be의 실현 가능성을 사전에 확인하기가 어려워진다. 오픈하고 난 후 뒤늦게 사용자들과 확인을 하며 재 수정하는 혼란을 겪을 수밖에 없는 것이다. 무슨 일이 진행되고 있는지 알 수 없는 것이 문제다. 통제를 하고 관리를 하기 위해서 IT 조직의 역할부터 재정립해야 한다.
내재화 가능범위 확정
IT 조직에게 요구되는 새로운 기능은 다름 아닌 IT의 내재화다. 사용자의 요구사항을 비즈니스에 맞게 이해하고 현재 시스템과의 차이를 분석하고 새로운 기능을 설계하는 과정을 이제는 IT 조직이 주도적으로 진행해야 한다.
과거의 SDLC 모델에서는 외부 컨설턴트 주도의 As-Is 분석, To-Be 도출에 따라, 각 회사들의 사업특성을 감안하기보다는 일반 표준프로세스에 업종특성을 일부 감안한 To-Be 프로세스가 설계됐다.
As-Is 분석, To-Be설계를 현업의 주도하에 진행하고, 컨설턴트는 이를 가이드 하도록 하면, 사업의 특성을 좀 더 반영해 실제 현업이 To-Be를 받아들일 때 충격이 덜할 것이고, 향후 거버넌스를 운영할 때도 프로세스를 완전히 이해한 상태이므로 운영에 부담이 덜 하게 된다.
덧붙여 기존과 같이 컨설턴트에 의해 작성된 To-Be 프로세스는 향후 안정화 이후 거버넌스 운영 시에도 문제가 된다. 프로세스 혁신인력, 사용자가 주도하지 않았기 때문에 프로세스의 설계목적 및 영향도를 체감하지 못할 것이기에 변화필요가 있을 때 제대로 된 방향성을 잡기 힘들어 진다.
하지만, 사용자 주도하에 프로세스혁신을 진행할 경우 이슈가 발생 했을때 프로세스의 변화포인트를 제대로 잡고 제대로 된 의사결정을 할 수 있을 가능성이 높아지게 된다.
영향도분석의 활용
요구사항 분석단계에서 작성되는 영향도 분석에 대한 거버넌스를 확고히 해 개발 요구 시 반드시 제출토록 해야 한다. 영향도 분석은 IT 조직이 책임지고 운영하고 이를 To-Be 설계에 반영해 필요한 연관 부분의 개선이 누락되는 것을 방지해야 한다.
이 과정이 지켜지지 않을 경우 프로그램 변경으로 인한 예기치 못한 문제가 발생하고 요구된 개발 보다 범위가 확장돼 개발비용 증가 및 시스템 운영에 지장을 초래하게 된다. 그러므로 거버넌스를 통해 준수하도록 하고 의무사항으로 확고히 하는 것이다. IT 조직의 새로운 역할로서 반드시 정착시켜야 한다.
절감 실적 모니터링
거버넌스를 강화해 새로운 개발방법을 실행하면서 실제로 절감되는 작업량과 개발기간 단축 등을 모니터링하고 공유해야 한다. 사용자들에게 실질적인 변화가 무엇인지를 보여줘야 하고 경영자들에게는 절감되는 비용을 직접 보여줘야 신뢰를 얻을 수 있다.
매번 프로그램 변경 시 마다 보여주기는 힘들다. 그렇지만 1년치를 누적해 집계하면 외주 계약 갱신시 기본데이터로 활용할 수 있고 계약금액을 실제로 줄일 수 있다.
이 기사에 대해 어떻게 생각하시나요?
추천해요
좋아요
감동이에요
화나요
슬퍼요
추천해요0
좋아요0
감동이에요0
화나요0
슬퍼요0
대하역사소설 ‘우리나라 삼국지’ 
연재소설 ‘최초의 당신’
기사제보 
