시스템으로 경영하라

비즈니스와 IT 연계

운영과 전략적인 면에서 IT의 중요성

오늘날 조직과 비즈니스에서 IT의 역할과 영향력이 극적으로 변해온 것은 누구나 아는 사실이다. IT는 이미 후선 지원 프로세스 관리를 뒷받침하는 전통적인 역할을 넘어 핵심 비즈니스 프로세스에 빼놓고 생각할 수 없는 중추적인 역할을 하고 있다.

지난 십여 년 동안 우리는 IT가 두 가지의 분야에서 기여하는 바를 보았다. 첫째, 수작업의 자동화로 거래비용이 감소했고 종업원의 생산성이 향상됐다. IT 사용이 운영성과를 높이고 운영비용도 절감했다. 둘째, IT를 경쟁우위 구현수단(Enabler)으로 활용해 새로운 방법으로 제품과 서비스를 시장에 제공하는 한편, 비즈니스 프로세스의 근본적인 재설계를 도모했다.

전략적인 구현수단으로서의 잠재적인 역할 때문에 IT는 더욱 최고 경영진의 주요 과제가 되었다. IT는 전략을 위한 필수 선택이 되었고, 경영진은 IT의 전략적 가치와 IT가 기업에 가져오는 경쟁 우위를 말하기 시작했다. 최근 IT의 전략적인 역할을 보는 이해가 높아지기는 했지만, IT에 투자해 정말 비즈니스 성과를 올릴 수 있을까 하는 우려는 여전하다.

리차드 놀란(Richard Nolan)과 워렌 맥팔란(F. Warren Mcfarlan)은 IT를 다양한 관점에서 바라보고자 하였다. 비용 절감과 효율성 증대, 조직 구조와 상품 그리고 서비스의 점진적 개선 등 IT가 제공할 수 있는 기회는 많기만 하다는 주장이다. 새로운 IT 기반 서비스를 제공함으로써 얻는 전략적 우위는 곧 고객 가치의 창출로 이어진다는 지적이다. 이러한 주장에는 흔쾌히 동의한다. IT가 운영상의 성과나 전략적 우위를 제공하는지 하는 물음을 놓고 왈가왈부하는 것은 쓸모없는 일이다. 분명 IT는 두 가지 모두 제공하기 때문이다. IT는 갈수록 성숙도를 더해가면서 보통의 자원처럼 계량하고 관리할 수 있게 되었다. 동시에 오늘날 비즈니스 프로세스에서 IT가 맡는 전략적 역할은 계속 성장할 게 틀림없다.

IT를 통한 비즈니스 트랜스포메이션(BT)

IT를 통한 BT의 본질

IT를 통한 BT는 조직의 네 가지 핵심 요소, 즉 제품, 프로세스, 사람, 기술에 심대한 영향을 미치는 복잡하고 장기적인 변화 프로세스이다. 혁신이나 전략의 수정으로 이 같은 변혁의 성격을 정의하며 결과적으로 신제품의 출시나 재설계된 비즈니스 프로세스의 반영이 이뤄진다. 완전히 새로운 어플리케이션 계획이 지원되며 관련 종업원들은 새로운 기술과 역량을 필요로 한다. 일반적으로 변혁은 몇 년에 걸쳐 다양한 조직에 두루 나타난다. 이런 경험의 폭과 깊이가 더해갈 때 조직은 스스로 형태를 바꾼다.

IT를 통한 BT는 정확히 말해서 제품이나 프로세스 또는 두 가지의 복합적인 비즈니스 요구에서 출발한다. 즉, IT를 통한 BT를 IT 관리자나 그 부서에만 맡길 수는 없는 노릇이다. 대신 비즈니스 파트너가 적극적으로 나서며, 비즈니스 경영진은 지원과 후원을 아끼지 않는 리더십을 발휘해야 한다. 이를 위해 비즈니스 경영진에게 필요한 새로운 역량이 바로 비즈니스․IT 연계 전략, 엔터프라이즈 아키텍처, 프로그램 리더십을 두루 겸비한 기본 소용이라 하겠다.

세 가지 필수 원칙

IT를 통한 BT의 관리에는 필요한 세 가지 원칙이 있다. 비즈니스․IT 연계 전략, 엔터프라이즈 아키텍처, 프로그램 리더십이 바로 그것이다. 이들 원칙은 각기 다른 목표를 가지면서도 서로 의존적이다.

이 세 가지 원칙을 전략적인 해석과 그 인식에 따라 계층적으로 배치해 보면, 비즈니스․IT 연계 전략은 전략 개발에 최고 권한을 갖는다. 전략적 목표는 프로그램과 프로젝트의 포트폴리오에서 자세히 설명되어야 한다. 이 포트폴리오는 프로그램 개발을 이끄는 바탕이며, 프로젝트 개발의 핵심을 이룬다. 엔터프라이즈 아키텍처는 프로그램 리더십의 각 계층을 전략적으로 해석하는 데 매우 중요한 역할을 수행한다.

원칙들 사이에 서로 연계를 생성하는 산출물에 초점을 맞추어 보면, 엔터프라이즈 아키텍처는 비즈니스․IT 연계 전략을 위해 현재 상태의 아키텍처 및 아키텍처 관점의 통찰을 제공한다. 비즈니스․IT 연계 전략은 엔터프라이즈 아키텍처에 의해 정교하게 다듬어져 아키텍처의 원리를 형성하는 방향으로 나아가며, 이는 곧 아키텍처 미래의 풍경을 상세하게 만드는 밑그림이 된다. 다시 말해서 나아갈 방향의 우선순위를 정하고 기술적 제약을 극복하는 데 초점을 맞춘 아키텍처 이행 계획(로드맵)을 규정해야만 하는 것이다. 프로그램 리더십 원칙(Program Leadership Thread)은 프로그램과 프로젝트의 포트폴리오를 정해 현재 상태에서 미래의 비전을 완성해가는 쪽으로 참고가 되어야 한다. 아키텍처 로드맵은 예산이나 필요한 자원 등의 정보를 추가해 세밀하게 완성되며, 이때 프로그램 및 프로젝트의 주요 이정표가 정해진다. 마지막으로 프로그램과 프로젝트가 완료되면 아키텍처의 전체적인 밑그림이 변화한다. 일반적으로 볼 때 이게 곧 아키텍처의 미래로 이끄는 지향점이 된다.

비즈니스․IT 연계 전략

장기적 비즈니스․IT 연계 전략의 필요성

비즈니스․IT 연계 전략 개발은 장기적인 안목으로 IT를 이용해 비즈니스 모델을 짜는 고도로 체계화한 창의적 프로세스이어야 한다. 비즈니스․IT 연계 전략 개발의 목표는 비용효율을 극대화하는 방법으로 IT를 활용해 비즈니스 가치를 끌어올리는 것이다.

비즈니스․IT 연계 전략은 정보를 수집하고 그 본질을 통찰하여 얻어낸 안목을 토대로 장기적인 관점에서 세운 비즈니스 목표에 IT를 융합시킨 비전을 완성하는 하나의 프로세스이다. 비즈니스․IT 연계 전략은 이미 결정을 내린 선택 사항도 능동적으로 다시 생각하기 때문에 개방적이고도 수평적인 사고의 특징을 갖는다. 결단이 예리하면서도 심도가 깊을 수밖에 없는 이유이다. 비즈니스․IT 연계 전략은 IT와 비즈니스 프로세스의 성공적인 접목을 통해 비즈니스 가치를 극대화하는 것을 목표로 한다. 이는 일을 바르게 하는 것(doing things right)이 아니며, 최적의 선택, 곧 올바른 일을 하는 것(doing the right things)을 찾아내는 집중력이다.

비즈니스․IT 연계 전략의 결과

비즈니스․IT 연계 전략 프로세스의 유형적 결과물은 비즈니스․IT 연계 전략 계획이라는 문서다. 이 계획은 기업의 주요 비즈니스 동인(Business Driver)과 IT 구현수단이 무엇인지 드러낸다. 비즈니스․IT 연계 전략 계획은 추후 3~5년 동안 IT 측면에서 추구해야 할 방침을 설명하며, 이해관계자들이 숙지한 명확하고 실행 가능한 목표를 지녀야 한다. 비즈니스․IT 연계 전략 계획은 끊임없는 재검토와 개선을 위한 기반으로서의 역할을 한다.

훌륭한 비즈니스․IT 연계 전략 계획에는 두 가지 특성이 있다. 첫째, 분석적인 관점에서 볼 때 타당해야 한다. 분석은 자세해야 하고, 결정의 근거는 논리적이어야 하며, 전체적인 계획은 일관성을 가져야 한다. 프로젝트와 로드맵은 일관성 있는 논거에 의해 전략적 비즈니스 목표와 맞물려야 한다. 둘째, 비즈니스․IT 연계 전략 계획은 이해관계자들에게 효과적으로 전달될 수 있게끔 작성되어야 한다. 즉, 여러 부류의 사람들이 별다른 어려움 없이 이해할 수 있어야 한다. 기술을 잘 모르는 경영진과 IT 부문 전문가 모두에게 쉽고도 자세하게 계획을 짠다는 것은 결코 쉬운 일이 아니다. 비즈니스․IT 연계 전략의 수립과 작성이 까다로운 이유이다.

비즈니스․IT 연계 전략 계획은 그 자체가 목표가 아니고, 다만 이 전략이 목표로 하는 무형적 결과를 달성하기 위한 수단이다. 여기서 말하는 무형적인 결과란 명확성, 일관성, 헌신이다. 이 세 가지 가운데 명확성과 일관성은 언제 어떤 상황에서도 의식해야만 하는 가치이다. 세 번째 것인 헌신 역시 아무리 강조해도 지나침이 없는 것이기는 하나, 조직 체계와 당사자들의 이해관계에 따라 어쩔 수 없이 큰 진폭을 갖는다. 또 헌신을 강요하는 것만큼이나 우스꽝스러운 게 또 있을까? 자발적으로 우러나와야 하는 게 헌신이라는 점에서 명확성과 일관성에 더욱 큰 비중을 두는 게 현명하다.

엔터프라이즈 아키텍처

엔터프라이즈 아키텍처란?

엔터프라이즈 아키텍처에는 다양한 정의가 있으며, 엔터프라이드 아키텍처 프레임워크와 방법론은 더 많은 논의를 불러일으키고 있다. 먼저 아키텍처라는 용어는 두 가지 의미로 사용된다. 한 가지는 청사진이나 표준, 원칙 같은 결과물의 의미로서 사용한다. 다른 하나는 이러한 결과물을 만들어내는 프로세스라는 뜻이다. 가트너는 프로세스의 본질을 강조하면서 엔터프라이즈 아키텍처를 다음과 같이 정의했다.

기업의 미래를 제시하며 그 기술적 발달을 가능하게 만들어주는 핵심 원칙과 모델을 소통하는 가운데 창조하는 노력이야말로 비즈니스 버전을 현실로 바꾸어내는 원동력이다.

로스(Ross)와 웨일(Weill), 로버트슨(Robertson)은 비즈니스 실행의 기초를 다져주는 도구로서의 엔터프라이즈 아키텍처 역할을 강조하는 또 다른 정의를 선보였다.

엔터프라이즈 아키텍처는 기업 운영 모델의 통합과 표준화 요구 사항을 반영하는 비즈니스 프로세스와 IT 인프라 논리를 체계화한 것이다. 엔터프라이즈 아키텍처는 긴 안목으로 기업의 프로세스 시스템, 그리고 기술에 접근하면서 각 개별 프로젝트를 실행할 능력 개발을 목표로 한다. 당장의 요구를 즉각적으로 채워달라는 근시안적 태도는 금물이다.

필자의 관점에서 엔터프라이즈 아키텍처는 두 가지 이유(전략에서 설계로의 전환, 복잡성의 정복) 때문에 IT를 통한 비즈니스 변화에 필수적이다.

먼저 엔터프라이즈 아키텍처는 전략을 설계로 전환시키기 위한 필수적인 요소다. 엔터프라이즈 아키텍처는 하나의 전략이나 하나의 설계가 아니라, 사실 서로를 이어주는 연결고리다. 상세화의 수준과 내용의 세밀성 측면에서 엔터프라이즈 아키텍처와 설계는 다르다. 엔터프라이즈 아키텍처의 핵심은 출발점으로서의 비즈니스․IT 연계 전략을 이해하고, 프로젝트의 근간이 되는 원칙을 정의해 설계 영역을 줄여서 상세 설계를 진행하고 실제 IT 밑그림을 변경하는 것이다.

두 번째로, 엔터프라이즈 아키텍처는 합리적인 비용으로 목적에 맞는 기민하고 견실한 정보기술 솔루션 창조를 목표로 하면서 정보기술에서 필연적인 복잡성을 정복하는 데 필요하다. 어느 정도는 엔터프라이즈 아키텍처에서 표준화와 합리화로 복잡성을 줄이지만, 수백 가지의 어플리케이션으로 구성된 대규모의 구조에서는 피할 수 없이 복잡성이 끼어들게 마련이다. 이것이 바로 엔터프라이즈 아키텍처의 보조적 역할을 요구하는 이유다. 어느 정도 수준의 복잡성이 불가피할 때에는 복잡성을 통제하거나 복잡성에게 통제당하거나 하는 두 가지의 선택만이 있을 뿐이다.

엔터프라이즈 아키텍처 기능의 조직화

아키텍처의 본질은 전략을 설계하고 변환하고 복잡성을 극복하는 것이다. 이것은 응집성과 유연성, 그리고 지속 가능한 IT 밑그림을 만드는 것이지만 개별 프로젝트가 아키텍처 원칙과 모델을 모두 지켜나갈 때만 가능하다. 따라서 아키텍처의 특징은 거시적 관점에서 이를 경험하지만, 각 프로젝트 단위라고 할 수 있는 미시적 관점에서 아키텍처가 부담으로 느껴진다. 결과적으로 엔터프라이즈 아키텍처를 담당하는 조직이 필요하고 아키텍처 지침을 강제하는 권한을 주어야 한다. 이 조직을 아키텍처 보드(Architecture board)라 한다.

일반적인 규칙으로 보면 엔터프라이즈 아키텍처 구조는 성숙도 수준이 높아질수록 더 중요해진다. 조직의 성숙도가 높아질수록, 더 많은 책임과 권한이 아키텍처 보드에 부여된다. 엔터프라이즈 아키텍처 조직에서 아키텍처 보드와 아키텍처 팀을 구별해야 한다.

아키텍처 보드는 엔터프라이즈 아키텍처와 연관된 목적을 이루기 위한 책임과 의무를 갖는다. 이것은 아키텍처 결과물 승인을 담당하는 관리 그룹으로, 엔터프라이즈 아키텍처의 유지 보수를 감독하고 아키텍처 규정 준수의 집행을 보증한다. 대부분의 회사에서 CIO나 IT 관리자는 아키텍처 활동의 초기 스폰서다. 하지만 엔터프라이즈 아키텍처는 비즈니스 도메인뿐만 아니라 IT 도메인도 포괄하기 때문에, 아키텍처 보드에는 임원진 또한 필요하다. 아키텍처 보드는 일상적인 운영 활동을 아키텍처 팀의 멤버에게 위임한다.

아키텍처 팀은 엔터프라이즈 아키텍처의 기능의 일상적인 활동을 담당한다. 팀은 원칙과 아키텍처 모델이 참고해야 할 지침을 정의하고 관리하며, 프로젝트 계획과 설계를 재검토하고 아키텍처 이슈를 비즈니스 입장에서 충고한다. 아키텍처 팀은 엔터프라이즈 아키텍처에서 다른 도메인을 위한 개별 아키텍트들로 구성되고, 리드 아키텍트가 이 조직을 이끈다. 아키텍처 팀은 아키텍처 보드의 책임 아래 운영된다.

성공적인 엔터프라이즈 아키텍트는 특정한 기술을 가진 전문 분야와 역량을 결집할 수 있어야 한다. 기술 분야에 치중할 수밖에 없는 아키텍처일지라도 갈수록 비즈니스 부분 요구를 소화할 수 있는 소양을 키워가는 것은 중요하다. 정보관리가 기술 도메인에서 비즈니스 도메인으로 옮겨가고 있는 것 역시 같은 맥락에서 이해해야 한다.

프로그램 리더십

변화의 가속

조직은 안팎으로 변화의 요구에 직면하고 있다. 그러나 이런 변화 요구를 전략적으로 접근하면, 조직의 변화를 이끄는 원동력으로 삼을 수 있다.

변화의 동인은 항상 존재했지만 지난 십 년 동안 변화의 속도는 몰라볼 정도로 빨라졌다. 우리는 그 동안 비교적 안정적이던 조직조차 끊임없이 변화해야만 환경에 적응할 수 있다는 것이 전혀 이상할 것이 없는 일반적인 상황으로 바뀌는 과정을 보아왔다. 그 결과 변화의 주도와 기존 관심의 지속 사이의 전통적인 균형이 뿌리부터 철저히 흔들리고 있다.

갈수록 복잡해지면서 빨라지는 변화는 조직에 많은 압력을 가한다. 변화를 주로 하려는 노력은 조직의 부족한 인적 자원을 충당할 것과 IT 밑그림의 변화를 수용할 능력을 요구한다. 변화에 맞추려는 예산이 조직의 전체 예산에 상당한 부담으로 작용하면서 재정상태에 직접적인 영향을 끼친다. 변화에 수반되는 리스크는 변화 계획 자체에만 국한하지 않으며, 조직 전체에 영향을 미친다. 결론적으로 말해서 변화를 관리할 방법론이 필요하다.

의사소통 단절과 관리 소홀

날로 복잡해지고 빨라지는 변화를 따라잡기 위해 대개 조직들은 전통적인 프로젝트 관리 방법에서 프로그램 리더십 접근법으로 옮겨가고 있다. 이는 점진적인 이동이라기보다는 성장통을 안겨주는 몇 가지 주요 단계를 거치며 비약적으로 이루어진다.

전형적인 성장 경로는 변화의 필요성을 명확히 표명하는 비즈니스 전략을 수립하는 것으로 시작한다. 프로젝트가 식별되면, 프로젝트 팀이 만들어지고 필요한 작업을 진행한다. 프로젝트의 수를 관리할 수 있을 때, 경영은 전체 비즈니스․IT 연계 전략과 프로젝트 목표를 고려할 여유를 얻는다. 프로젝트 관리자는 비즈니스와 IT 양쪽 모두를 고려해 프로젝트를 조정한다.

프로젝트의 수와 규모의 증가에 따라, 조정 메커니즘은 더 이상 효력을 발휘하지 못한다. 비즈니스․IT 연계 전략에 모든 프로젝트를 접목하는 것은 관리의 복잡성을 너무 높일 뿐만 아니라 두 분야의 역학관계 조정이 충분히 이루어지지 못하게 만든다. 하지만 다른 조정 메커니즘이 그 자리를 메워 주는 것도 아니므로 이런 상황이 계속되다 보면 불충분한 조정의 여파가 분명히 드러난다. 조정 실패에 따라 전략과 프로젝트 사이의 소통이 두절되며, 관리 소홀 상황이 빚어진다.

프로젝트의 수적 증가 외에, 의사소통 단절과 관리 소홀을 불러오는 두 번째 원인은 기업이 처한 복잡한 환경이다. 프로젝트들은 갈수록 다른 조작 단위까지 영향을 미치며 지리적 경계를 뛰어넘고 있다. 이러한 프로젝트를 통제하기 위해서는 성숙된 프로그램 리더십이 필요하다.

프로그램 수행

프로그램 수행은 프로그램과 프로젝트의 성공적인 실행을 가능하게 하고 제어하기 위한 원칙과 방법론, 프로세스의 적용이다. 전형적인 프로그램 수행 요소에 프로젝트가 성공할 수 있는 조건 생성을 포함하는데, 이 조건은 개별 프로젝트의 범위 내에서 만들어 낼 수 없는 것이다. 또 다른 특징으로는 프로젝트 사이의 종속성을 관리하고 서로 다른 프로젝트의 범위를 조율하며 전반적인 계획에 반영하는 것이다. 적절한 프로그램 수행관리를 위해서는 실행 프로세스와 그 프로세스를 실천에 옮길 조직이 필요하다.

프로그램 리더십 조직

프로세스를 실행하는 데 필요한 조직을 다루고 그에 따른 역할과 책임을 살펴보자.

■ 포트폴리오 오피스 / 최고기관(COE)

포트폴리오 오피스의 목적은 포트폴리오 관리를 용이하게 하고 조직에 가장 필수적인 것을 프로젝트 포트폴리오에 반영하는 것이다. 포트폴리오 오피스는 경영진에게 직접 보고하는 영구적인 독립 조직이다. 전사 포트폴리오 오피스는 최고 이사회에 직접 보고하고, 사업부 포트폴리오 오피스는 사업부 관리자에게 직접 보고 한다.

■ 조정 위원회(스폰서)

조정 위원회는 맡고 있는 프로그램과 모든 프로젝트를 책임진다. 이 위원회는 프로그램의 오너이자 주연인 고위 경영진으로 구성되며 이들은 결과에 전적으로 책임을 진다. 이 고위 경영진은 조정 위원회의 의장 역할도 맡는다. 조정 위원회의 다른 멤버는 참여하는 단위조직과 이사회의 수석 대표들이다.

■ 프로그램 관리자

프로그램 관리자는 조정 위원회에 직접 보고하고 조정 위원회는 설정된 제약/한계 내에서 일일 단위로 프로그램을 실행할 권한을 위임한다. 목표는 시간과 예산을 준수하고, 의도했던 새롭거나 향상된 역량의 품질을 유지하는 것이다. 프로그램 관리자의 주 업무는 프로그램을 넘어서 개발의 일관성과 내부 일관성을 보장하는 것이다.

■ 비즈니스 변화 관리자

비즈니스 변화 관리자는 조정 위원회에 직접 보고하고 조정 위원회에서 권한을 위임 받아 프로그램 관리자가 실현한 새로운 역량을 활용해 비즈니스 이익과 전략 목표를 실현한다. 비즈니스 변화 관리자는 공식적으로는 프로그램 조직의 일부가 아니지만 적절한 검사를 보증하고 프로그램 관리자와 균형을 잡는다.

■ 프로젝트 관리조직(PMO)

PMO는 프로그램 관리자와 프로젝트 관리자를 지원한다. 본질적으로 PMO는 지원조직이고 프로젝트는 프로그램 관리자가 이끌어 가지만, 프로세스에 표준을 도입하기 위한 권한을 위임 받는다.

■ 프로그램 디자인 권한(PDA)

프로그램 디자인 권한(PDA)은 프로그램 관리와 프로그램 청사진(To-be 프로세스의 정의, 요구 사항과 적용)에 대한 프로젝트 팀에 안내와 조언을 제공하는 지배 구조의 역할을 한다. PDA는 정보 허브로, 솔루션을 주도하고 설계 이슈를 해결하며, 의사 결정을 용이하게 하기 위해 프로그램 안팎의 모든 관계자와 밀접한 협업을 통해 운영한다.

* * *

본 도서 정보는 우수 도서 홍보를 위해 원저작권자로부터 정식인가를 얻어 도서의 내용 일부를 발췌 요약한 것으로, 저작권법에 의하여 원저작권자의 정식인가 없이 무단전재, 무단복제 및 전송을 할 수 없으며, 원본 도서의 모든 출판권과 전송권은 원저작권자에게 있음을 알려드립니다.