정진하 SK브로드밴드 정보기술원장
교량을 건설하려 할 때 예술가의 감각으로 예술성 있는 다리의 모습을 그려냈다고 하자. 현실 세계에서 그 다리를 제작해야 하는 건축가는 다리가 견뎌야 하는 하중, 지진·강풍에 견딜 수 있는 구조, 차량 통행량 등을 고려해 예술가의 창작 의지와 가장 가깝게 만들어 내려고 노력할 것이다.
여기서 IT는 건축가의 역할을 한다. 비즈니스 부서가 고객을 알고 고객에게 서비스를 제공하기 위한 프로세스를 창조해 내는 역량을 보유한 그룹이라면, IT 부서는 이러한 비즈니스 조직이 제반 활동을 성공적으로 수행하는 데 필요한 구체적인 건축물과 도구를 제공하는 프로세스 엔지니어 그룹이다. 또 비즈니스 부서에서 생각하기 어려운 전사 프로세스 측면의 통합적인 아이디어를 제공할 수 있는 통찰력을 보유한 부서이기도 하다. 기업 내에서 IT 부서에 예술가의 역할을 요구해야 한다면 이것은 프로세스혁신(PI) 같은 또 다른 영역의 역할로 간주되어야 할 것이다.
현업의 요구 사항에 IT 부서가 ‘노(No)’라고 한다면 더 이상 일을 진행할 수 없는 것일까? IT 부서의 ‘노’에는 세 가지 이유가 있을 수 있다.
먼저 우선순위 조정이 필요한 경우이다. IT 부서는 동일 비즈니스 부문의 서로 다른 팀으로부터 최우선순위의 요구 사항을 동시에 요청받기도 한다. 이 경우 요청 부서들은 프로세스 담당 부서들과 먼저 우선순위를 조정해야 한다.
두 번째는 상충되는 요구 사항들의 문제다. 각기 다른 현업 부서에서 프로세스의 동일한 부분에 대해 상충되거나 배타적인 요구 사항이 접수되어 IT 부서가 정리할 수 없는 경우다. 이 경우도 해결의 실마리는 비즈니스 부서가 갖고 있다.
마지막으로 R & C(Resource & Capability)의 문제다. IT 부서는 상시적으로 한정된 R & C를 보유하고 있기 때문에 ‘현재는 힘들다’는 얘기를 자주하게 된다. 그럼에도 불구하고 비즈니스 부서 간의 자발적인 우선순위 조정이나 이해는 통상 쉽게 이뤄지지 않는다. 이때 비즈니스 부서는 IT 부서의 R & C를 확대하기 위해 무엇을 협조해야 할 것인지 고민해야 한다. 경우에 따라 추가적인 예산을 확보하거나 프로젝트 기간을 조정할 필요가 있을 것이다.
기업의 모든 프로세스는 복수의 카테고리로 묶을 수 있다. SK브로드밴드는 13개의 상위 카테고리로 프로세스를 정리했다. 상위 프로세스 카테고리의 챔피언 부서를 정하고 하부 프로세스의 오너를 정한다. 대부분의 프로세스는 이미 정보시스템으로 구현돼 있으므로 업무 프로세스의 변화는 곧 정보시스템의 변경을 수반하게 된다.
이와 관련된 모든 회의에 IT 부서가 참석할 필요는 없어도 최소한 초기 단계에서부터 IT 부서를 개입시켜야 한다. 하부 프로세스의 변경이 개별적으로 IT 부서에 전달된다면 아무리 잘 짜여진 전사 프로세스 구조라 하더라도 수 년 안에 혼란을 겪게 될 것이다. 불명확한 프로세스 오너십은 IT 부서에 중복되거나 상충되는 요구 사항이 전달되게 함으로써 본래의 예술가(비즈니스 부서)의 요구 사항과는 전혀 다른 모습의 건축물로 변형되는 결과를 초래할 수도 있다.
기본적으로 IT 부서에 전달되는 요구 사항은 구체적이어야 한다. 이는 프로젝트 진행을 빠르고 정확하게 하는 방법 중 하나다. 새로운 업무 프로세스를 만들 때는 가능한 한 구체적으로 요구해야 한다. 필요하다면 IT 부서의 프로세스 전문가에게 도움을 받아야 한다. 중요하고 큰 규모의 요구 사항은 IT 전문가를 포함한 태스크포스 형태의 운영을 필요로 할 수도 있다.
필요 이상의 구체적인 요구는 그 요구에만 적합한 결과를 만드는 데는 도움이 될 수 있어도 전체적으로 균형 있게 짜여진 프로세스를 흐트러뜨릴 수도 있으므로 유의해야 한다. 그러나 때에 따라서는 요구 사항이 개념적이어도 무방한 경우가 있다. 기존 프로세스에서 일부분 변경이 필요할 때는 개념적으로 요구하고 즉시 IT 부서의 의견을 경청하도록 권고한다. 이 경우 프로세스 엔지니어인 IT 부서의 전문가가 대부분의 문제를 해결해 줄 수 있다.
순수미술을 하는 예술가는 그럴 필요가 없겠지만 작품을 현실 세계에서 만들어내야 한다면 예술가도 건축가가 내놓은 설계도를 함께 살펴보며 당초의 작품 의지와 달라진 점이 없는지 찾아내는 데 시간을 써야 한다. 때에 따라서는 안전과 실용성 그리고 주변 환경과의 조화를 위한 건축가의 의견에 따라 원작이 개선되는 것을 수용할 수 있어야 한다.
또 수시로 건축가와 회의를 갖고 위험을 공유하고 이를 해결하기 위해 함께 고민해야 한다. 구조물을 건설하는 과정에는 반드시 마디(단계)가 있으므로 각 마디마다 현업의 의견과 판단(의사결정)을 신속히 제공해야 한다. 이는 건축물의 안전성과 실효성에 중요한 역할을 한다. 특히 사용자인수테스트 단계에서는 비즈니스 부서의 우수한 직원들에게 철저히 준비해 임하도록 해야 한다. 나타날 수 있는 모든 형태의 오류를 잡아낼 수 있도록 랜덤 형식의 테스트도 시도하라. 새로운 시스템이 가동되는 첫날 있을 위험을 피해가는 가장 안전한 방법이다.
전자제품에 따라오는 사용설명서를 잘 읽어야 기기를 100% 활용할 수 있다. 최신 휴대폰을 통화나 단문메시지 보내기에만 쓰는 사용자가 되지 말아야 한다. 정보시스템이 전자제품과 다른 것은 제작 과정에서 사용자가 정보시스템의 오너로 함께 참여한다는 것이다. 사용설명서는 정보시스템을 완전한 작품이 되게 하는 최종 단계의 산출물이다. 사용설명서를 연애편지처럼 읽고 또 읽어서 부족한 부분을 계속 보완하도록 요구하고 완성해야 한다.
아날로그적 비즈니스(예술가)를 이해하는 IT 부서, 디지털적 IT(건축가)를 이해하는 비즈니스 부서 간의 화합에 의한 시너지는 상상 이상일 것이다. 서로 이해하고 상생하는 찰떡궁합 파트너 같은 비즈니스 부서와 IT 부서의 관계를 기대해 본다.
james_jung@skbroadband.com