|
ISP(정보화전략계획)의 불편한 진실 | ||||||||
| 목표는 기업 청사진 제시…ISP 역할론 재정비 필요해 | ||||||||
| ||||||||
|
글로벌 컨설팅 회사들은 지식관리시스템이 수행한 많은 프로젝트 자료를 모아 공유한다. 여기에 'ISP' 또는 'Information Strategic Planning'이라는 키워드로 검색하면 한국에서 정보화전략계획(ISP)이라고 말하는 프로젝트 산출물은 안 나온다. 왜 그럴까. ISP는 제임스 마틴에 의해 만들어져 해외에서 1990년 전후 한동안 유행했던 정보공학(Information Engineering) 방법론 중 맨 처음에 있는 계획 단계를 의미한다. 정보공학 방법론 핵심은 분할 접근하는 방식이다. 이 방법론은 대규모 복잡한 업무 시스템을 쉽게 개발하는 데 목적이 있다. 시스템으로 구현할 전체 업무를 모듈 단위로 쪼개 놓고 구현해야 할 기능을 정의한 다음 모듈별로 구현하는 것이다.
ISP 목적은 기업 전략과 기술 변화를 반영해 톱다운으로 기업 전체 업무 기능과 데이터, 정보 요구 상위 수준을 그려내는 데 있다. IT과제를 뽑는 것과 무관하며 ISP로 프로세스혁신(PI) 과제를 뽑는 우리 관행과는 거리가 멀다. ISP 결과 기반으로 시스템 설계가 이뤄지고 시스템 구축이 수행되는 것이 정보공학 방법론 요체다. ISP는 IT전략을 대체할 수도 없고 IT거버넌스나 IT운영을 ISP 범위 안에 포함하는 것도 사실상 불가능하다. 시스템 개발에 컴포넌트 개발 등 반복적 개발 방법론을 쓴다면 ISP는 더 관계가 없다. 국내에서는 1990년 후반부터 정보공학 방법론이 유행했다. 당시 ISP라는 단어가 전반적인 IT플래닝 개념으로 인식됐다. 지금은 ISP의 정확한 개념과 범위를 정의하기 어려울 정도로 다양한 용도로 쓰인다. ISP면 IT플래닝 모든 것을 다룰 수 있는 것처럼 보인다. IT전략 수립을 위해 ISP는 쓸 수 없다. 새로운 비즈니스 전략을 실행하기 위해 현재 IT가 해야 할 일을 정의하는 것이라면 IT전략이라는 수단을 써야 한다. 비즈니스 과제 실행을 지원하는 IT과제를 뽑는 일이야말로 IT전략 요체다. ISP는 거기에 적합한 수단이 아니다. 전략 수립은 목표 청사진을 정의하고 이를 달성하기 위해 해야 할 일을 정의하는 것을 의미한다. IT과제는 해야 할 '일'을 의미하지 달성해야 할 '청사진'을 의미하진 않는다. '달성해야 할 무엇(What to achieve)'과 '해야 할 일(How to achieve it)'을 분리해 사고하는 것은 전략을 수립하는 과정에서 무척 중요하지만 종종 간과된다. 국내에서 ISP 프로젝트를 수행하면 과제가 도출된다. 혹자는 이를 PI과제라고 부른다. 여기에 해외 선진사례와 다른 몇 가지 중요한 차이점이 있다. 첫째, 해외 선진사례에서 ISP는 과제를 정의하는 일과 전혀 상관이 없다. 업무기능, 데이터, 정보 요구에 대한 시각을 정의하는 것이므로 오히려 달성해야 할 청사진을 정의하는 일에 가깝다. 하지만 국내 ISP에서는 달성해야 할 청사진과 그 청사진을 달성하기 위해 필요한 과제를 모두 식별한다. 이건 해외 선진사례에서는 IT전략 프로젝트다. 둘째, 해외 선진사례에서는 달성해야 할 청사진을 만들기 위해서는 상위의 큰 그림을 그려야 한다. 하지만 국내 ISP 프로젝트에서 청사진을 정의하는 작업은 큰 그림을 그리는 것이 아니라 구현 단계 논리설계를 작성하는 정도로 상세하다. 이건 IT 아키텍처 설계 프로젝트나 구현 프로젝트 논리 설계다. 현미경으로 지구를 볼 수 없듯 상세한 디자인으로는 큰 그림을 볼 수 없다. 큰 그림을 못 보면 과제를 정의하는 데 더 힘들다. 셋째, 해외 선진사례에서는 '달성해야 할 무엇'과 '그 무엇을 달성하기 위해 해야 할 일'이 명확히 분리돼 있다. 한국에서는 그 두 가지가 바로 '과제' 안에 섞여있다. 과제를 도출하는 것이 목적인 ISP 프로젝트 산출물을 보면 도출된 그 과제가 바로 '달성해야 할 무엇'이다. 동시에 '그 무엇을 달성하기 위해 해야 할 일'이기도 하다. 이렇게 되면 온전히 '해야 할 일'만 뽑아 장기적인 프로젝트 포트폴리오와 프로젝트 로드맵을 관리해야 하는데 이게 쉽지 않다. 프로젝트 포트폴리오라는 개념도 생소하고 프로젝트 로드맵은 있지만 프로젝트 구분이 안 된다. 그래서 주로 하나의 프로젝트만 나온다. 그 프로젝트를 주로 차세대 프로젝트라 부르거나 PI·ERP 프로젝트라 부른다. 넷째, 해외에서는 IT전략으로 나온 과제는 순수한 IT과제지만 한국 ISP로 나온 과제는 운영 과제다. PI 과제라고 불리는 것도 그 때문이다. 운영이란 사람·조직, 프로세스, 기술이 동시에 작동되면서 비즈니스 결과물을 만드는 과정이다. 전사 아키텍처(EA)플래닝, IT거버넌스 플래닝 등 다른 IT 플래닝을 위해 ISP를 쓸 수도 없다. 기업 업무 간, IT시스템 간 연계성을 강화해 마치 하나의 유기체처럼 협업 수준을 높이려면 EA를 써야 한다. EA는 기업내부 구성 부문 간 협업 수준을 높이기 위해 기업이라는 건축물을 조형하는 아키텍처 종류 중 하나다. ISP는 대규모 시스템 개발 시 맨 앞 단계에서 시스템 업무기능과 데이터, 정보 요구에 대한 상위수준 시각을 기술하는 데 적합하다. 그것도 정보공학 방법론을 채택했을 때가 그렇고 컴포넌트 기반 개발 방법론을 채택했다면 다른 방식의 플래닝 단계를 적용해야 한다. 국내서 수행되는 대부분 시스템통합(SI) 성격을 지닌 차세대시스템 개발은 성격상 반복적 개발 방법론보다는 정보공학 방법론에 가깝다. 따라서 ISP가 바로 적합한 수단이 된다. 국내에서 ISP는 어떤 IT플래닝이든 대부분 담을 수 있다는 것이 마치 진실처럼 전해지지만 실제로는 국내 ISP는 어느 IT플래닝이든 제대로 담기 힘들다는 것이다. 이것이 ISP의 불편한 진실이다. | ||||||||
ISP(정보화전략계획)의 불편한 진실
2012. 2. 24. 15:09
