차세대 시스템 구축이 왜 어려운가?

차세대 구축, 솔루션 구축 프로젝트들이 많이 진행된다.
PI를 통해 업무를 개선하고 이를 반영한 시스템을 구축한다. 다들 호기롭게 문제없을 듯이 진행을 하지만 막상 시작하면 여러가지 어려움을 겪는다. 가장 자주 겪는 어려움은 PI의 개선 방향을 시스템에 반영하는 작업이다. 왜냐면 다들 기존의 업무방식을 바꾸지 않으려고 하기 때문이다.
그럼 사람들이 바뀌면 시스템 구축이 잘되고 변화가 잘될까?
그렇지 않다
사람들이 쉽게 간과하는 것이 있다.
PI의 결과물은 상위수준의 개선 방향이다. 이걸 어떻게 구체화하느냐? 그리고 이걸 시스템에 어떻게 담을 것 인가는 전혀 다른 이야기다. 예를 들어 누군가가 미니카, 혹은 목업 형태의 차를 준다. 그리고 이걸로 자동차를 만들라고 한다. 그럼 차를 쉽게 만들수 있을까? 자동차 디자인 만으로 차가 완성되지는 않는다. 이 디자인을 가능하게 하기 위해서는 차를 전기차로 할 것인가? 아니면 가솔린차로 할 것인가? 엔진은 뒤에 설치할 것인가 앞에 설치할 것인가 등 많은 고민이 필요하다. 마찬가지로 PI의 결과물은 개선 방향이고 그것을 가능하게 하는 프로세스까지 설계할 수는 있다. 하지만 그 프로세스가 원할하게 수행되기 위해서는 많은 업무 기준과 업무 단계별로 관리해야 할 데이터 등에 대한 정의가 필요하다. PI 이후에 시스템개발팀이 들어오면 처음하는 것이 시스템 설계이다. 이 설계를 위해서 업무요건을 다시 정의하고 이 요건에 맞추어 시스템을 설계한다. 업무 흐름을 정의하고 화면을 정의하고 데이터를 정의하고 인터페이스를 정리한다.
PI를 통해 프로세스 설계까지 나왔다고 해도 그것을 다시 시스템에 구현하기 위해서는 몇단계를 더 상세화하는 작업이 진행이 되는데 이 과정에서 PI의 개선방향이 온전히 시스템에 반영되지 않는다. 왜냐면 그 개선방향이 과연 개발 가능한 것인가에 대한 고민이 들어가고 개발이 가능하더라도 개발팀이 개발할 역량을 가지고 있느냐에 대한 고민이 필요하다. 시스템을 개발하러 들어온 개발팀이 PI 산출물을 보면 늘 하는 이야기가 있다. 뜬구름잡는 이야기만 잔뜩 적어놓았다는 이야기를 한다. 이론적이고 이상적인 이야기를 많이 한다. 그럴수밖에 없는 것이 PI의 개선방향은 오늘의 방향뿐만 아니라 먼 훗날의 나아갈 방향까지 포함되어 있다. 그리고 개선방향이라는 것이 하나의 업무에만 반영되는 것이 아니다. 모든 업무에 개선방향에 담긴 철학이 반영되어야 하는데 이런 부분이 시스템 설계팀이 들어왔을 때 개선방향에 대한 충분한 이해가 없다면 모든 업무에 제대로 반영되기가 어렵다. 그럼 PI를 설계한 사람들이 업무흐름을 포함한 요건을 다 정의한다면 잘 될까?  그런데 그렇게 진행하기가 어려운 이유는 프로세스 관점과 시스템개발 관점이 다르기에 사용하는 용어가 다르고 필요한 역량이 다르다. PI를 설계한 사람들에게 시스템 개발을 위한 설계를 맡겨도 시스템 개발팀에서 다시 시스템에 맞추어 설계를 해야한다.
결국은 시스템과 프로세스를 다 이해하는 사람이 중간에서 조율을 해주면서 관리해줘야 하는데 이런 사람이 생각보다 많지 않다.
결국 시스템개발팀은 개선방향 중에 이번에 가능한 개발범위와 다음에 구축해야할 개발범위를 구분하고 개선방향의 철학을 업무에 잘 반영하도록 하는 역할을 수행해야 하는데 이 과정을 거쳐서 시스템을 개발하다 보면 어느 사이에 개발된 시스템은 기존 시스템과 별차이가 없게 된다. 몇 개의 편리성이 추가되었을 뿐 많은 부분이 기존시스템과 같은 시스템이 구축된다.
 
그럼 PI를 시스템에 대한 이해가 높은 사람들이 하면 어떻게 될까? 그럼 너무 현실적인 이야기만 하게되어 개선방향이 너무 제한적으로 나오게 된다.
 
결국 이 문제는 풀리지 않는 밸런스의 문제로 남을 수밖에 없다. 현실적인 PI와 현실적인 시스템개발이냐? 이상적인 PI와 현실적인 시스템이냐? 
 
PI와 시스템간의 조율이 하나의 허들이라면 시스템을 개발하는 개발자의 역량 또한 하나의 제약요소이다. 개발사의 역량에 대해서는 다음 시간에 계속해서 이야기하도록 하겠다