2018.01.26

기고 | CIO가 알아야 할 IT전략 수립 7단계

David Gee | CIO Australia
IT전략의 책무와 강점은 조직에 놀라운 영향을 끼칠 수 있다. 이 전략의 효과는 당연히 자신의 재임 기간에 누리는 성공의 수준과 직접적인 상관관계가 있다.



효율적인 기술 전략을 수립하는 7단계에 대해 알아보자.

1단계: 팀을 꾸려라
CIO가 전략 전체를 처음부터 끝까지 주도하고 유도해야 한다. 그렇다고 해서 CIO가 직접 모든 일을 할 필요는 없다. 주인의식이 있는 사람들로 팀을 구성한다. 모두가 전략을 지지해야 한다.

이 주제에 열의를 갖고 직접 보고서를 찾아보며 팀원이 동참하도록 한다. 실제로 더욱 강력한 전략에 집중해야 하는 리더, 즉 다른 사람들과 잘 어울리고 존중하며 도전을 원하는 사람이 누군지를 생각해야 한다.

과거, 필자는 사람들이 필자와 긴밀하게 협력하고 전략 구축을 돕게 하려고 ‘CIO의 사무실(Office of the CIO)’을 만들어 활용했다. 이는 참여도를 높이고 팀원의 기술 개발에 도움이 된다. 이전의 역할에서 필자는 스킵 레벨(Skip Level) 관리자 중 일부가 필자의 직접적인 리더보다 IT전략에 대해 더욱 잘 안다는 사실을 발견했다.

2단계: 비즈니스 목표에 맞추라
전통적인 접근방식은 비즈니스 전략에 맞추는 것이다. CIO는 정의상 비즈니스 부문의 일원이자 IT를 대표하기 때문에 이런 과정에서 다른 사람과 자신을 교육하여 비즈니스를 깊이 이해해야 한다.

이 참여 및 피드백 과정은 목표에 맞추기 위해 필수적이다. 맞추는 것이 ‘자연스러운’ 상태가 아니며 투입값에 대해 개방적이고 중요한 것에 대한 실질적인 입장을 취해야 하는 것은 사실이다.

CEO, COO, CFO 등의 책임자와 연결하는 것으로는 부족하다. 임원 동료들도 답이 없을 때가 있다.

경험상 프로세스 전체가 완료되었을 때 모든 임원이 프로젝트의 우선순위 설정 방식을 이해하고 수락했는지를 확인하게 된다. 그렇다고 해서 그들이 모두 ‘만족’한다는 뜻은 아니지만, 그 전략이 비즈니스의 목표를 반영하고 거기에 동의한다는 것이다.

3단계: 적절한 계획을 수립하라
올바른 매개변수(parameters)들을 준비하고 최소 2년, 이상적으로는 3년 동안 정확히 어떤 일이 일어나야 하는지를 보여주는 계획을 수립한다. 안타깝게도 많은 기업이 근시안적인 1개년 계획을 수립한다.

팀원이 특정 세부사항에 대해서는 다소 확신이 없고 시간이 지나면 일정 목표에 도달한다고 가정하는 것은 맞지만 장기적인 목표에 지속해서 집중하는 것이 중요하다. 계획 과정에서 사람들이 특정 작업을 완수하도록 요청하면 공급을 초과하는 경우가 많고 동료들은 자신만의 ‘선호’ 프로젝트가 있을 것이다.

중장기적인 관점을 가지면 진정한 혁신을 계획하고 실행할 수 있게 된다. 이런 대대적인 변화는 항상 예상보다 많은 시간과 노력이 필요하기 때문에 이를 팀에 주지시키도록 하자.

필자는 한때 기술 전략을 수립하지 않고 5년 동안 조직에서 근무한 적이 있다. 당시 많은 전략적인 프로젝트가 비즈니스 목표와 연관되어 있었지만 포괄적인 계획이나 의제가 없었다. 계획도 있었고 프로젝트도 성공했지만 모두 ‘1개년’ 관점이었다. 아무도 그 이상을 계획하지 않았기 때문에 전략보다 작전이 우선시 되었다.

4단계: 아키텍처 로드맵과 전략을 맞추라
IT전략과 아키텍처 로드맵을 반드시 완전히 맞춰야 하며 ‘원하는 것, 필요한 것, 주어진 것’을 명확히 해야 한다. 아키텍처 로드맵은 주어진 조건을 들여야 볼 수 있도록 하며 현재와 미래의 상태를 파악하게 한다.

아키텍처 로드맵은 현재 애플리케이션과 하드웨어 인프라의 성숙도에 대한 기술적인 관점을 제공해야 한다. 이 장비의 수명이 언제 끝나는지 강조해야 하며, 아무도 이에 대해 논의하고 싶어 하지 않는 경우가 많다. 새로운 비즈니스 계획을 기존 앱과 시스템의 개선에 연계시키면 IT전략을 위해 적절한 균형을 유지하는 데 필요한 현실 점검을 제공한다.

아키텍처 로드맵을 IT그룹과 나머지 비즈니스 부문 사이의 논의를 대표하는 ‘인공물’로 활용하는 것이 좋다.

현업 임원들과 너무 많은 것을 공유하기를 주저하는 것은 당연하다. 사실 아키텍처 및 전략팀은 공통적인 어휘와 이해를 구성하기 위해 주요 이해 당사자들과 소통해야 하기 때문에 공유하지 않는 것 자체가 실수다. 우선 세부적인 기술 아키텍처가 비즈니스 전반에 걸쳐 계획된 변화를 지원하는 방법을 설명해야 한다.

5단계: 전략적으로 선택하라
기업 규모에 상관없이 CIO는 모든 요구를 충족하고 싶어 한다. 하지만 재정과 자원은 항상 부족하다. 이 때문에 현업 임원은 항상 어려움을 겪고 지나친 약속에 대한 압박이 존재한다. 이런 한계를 명확히 하는 것이 바로 CIO의 임무다.

비즈니스에 명확한 비즈니스 전략과 우선순위가 있는 순간이 있겠지만 솔직히 그렇지 않다고 생각한다. 최고의 계획을 세운 기업이라도 계획 시한을 벗어나는 ‘임시’ 규제나 전략 프로젝트가 있게 마련이다.

계획 가정을 확인하고 전략에 정확히 무엇이 포함돼 있는지 확실히 하는 중요한 요령이 있다. 예를 들어, 연초의 인력 활용도는 100%일 수 있지만 휴일, 교육, 공석이 발생하게 된다.

생각해야 하는 또다른 핵심은 필자가 ‘발견’이라고 말하는 것이다. 항상 위에서 시작돼 조사가 필요한 전략적인 디지털 프로젝트 같은 것이 있게 마련이다. 이를 위한 계획이 있어야 예산이 할당될 수 있다.

6단계: ‘IT의 비즈니스’를 실현하라
IT전략은 IT를 관리하는 방식에 대한 프레임워크를 제공해야 한다. 필자는 이것을 ‘IT의 비즈니스’라 부르며 이 프레임워크에는 구조, 역량, 능숙도 등의 ‘조직적인 아키텍처’ 측면이 포함된다.

이 의제를 끌어내 기업은 IT가 얼마나 개선되고 있는지 파악하도록 해야 한다. ‘IT의 비즈니스’는 IT를 실행하여 참여 모델과 비즈니스를 통합하고 좀 더 구체적으로 데브옵스 또는 애자일 방법론을 팀에게 가르치는 방식을 다뤄야 한다.

이 단계에서 대상 운영 모델을 개발하고 현재 상황에 도전해야 한다.


7단계: 끝을 맺으라
거의 끝난 것 같지만 아직 끝나지 않았다. 광범위하고 표적화된 메시지를 사용한 참여와 소통의 과정이 중요하다. 이를 위해 IT부서 내의 임원 및 동료와 공유하는 포괄적인 계획이 필요하다.

이런 참여 시점이 전반적인 IT전략 시간표와 맞아 떨어지려면 반복과 계획이 필요하다. 이런 참여의 과정을 통해 실질적인 끝맺음이 이미 이뤄지고 마지막 검토 시 새로운 것이 나타나는 일이 없게 된다.

전략을 끝맺고 지지하면 기업 전반에 걸쳐 더욱 광범위하게 공유할 수 있다. CEO와 임원들에게서 이런 수준의 지지를 확보하는 것이 중요한 단계며 확실한 지원을 확보하는 데 도움이 된다.

이제 준비가 끝났다. 행운을 빈다.

*David Gee는 일본 메트라이프생명 CIO며 그 전에는 CUA CIO를 지냈다. ciokr@idg.co.kr
 
2018.01.26

기고 | CIO가 알아야 할 IT전략 수립 7단계

David Gee | CIO Australia
IT전략의 책무와 강점은 조직에 놀라운 영향을 끼칠 수 있다. 이 전략의 효과는 당연히 자신의 재임 기간에 누리는 성공의 수준과 직접적인 상관관계가 있다.



효율적인 기술 전략을 수립하는 7단계에 대해 알아보자.

1단계: 팀을 꾸려라
CIO가 전략 전체를 처음부터 끝까지 주도하고 유도해야 한다. 그렇다고 해서 CIO가 직접 모든 일을 할 필요는 없다. 주인의식이 있는 사람들로 팀을 구성한다. 모두가 전략을 지지해야 한다.

이 주제에 열의를 갖고 직접 보고서를 찾아보며 팀원이 동참하도록 한다. 실제로 더욱 강력한 전략에 집중해야 하는 리더, 즉 다른 사람들과 잘 어울리고 존중하며 도전을 원하는 사람이 누군지를 생각해야 한다.

과거, 필자는 사람들이 필자와 긴밀하게 협력하고 전략 구축을 돕게 하려고 ‘CIO의 사무실(Office of the CIO)’을 만들어 활용했다. 이는 참여도를 높이고 팀원의 기술 개발에 도움이 된다. 이전의 역할에서 필자는 스킵 레벨(Skip Level) 관리자 중 일부가 필자의 직접적인 리더보다 IT전략에 대해 더욱 잘 안다는 사실을 발견했다.

2단계: 비즈니스 목표에 맞추라
전통적인 접근방식은 비즈니스 전략에 맞추는 것이다. CIO는 정의상 비즈니스 부문의 일원이자 IT를 대표하기 때문에 이런 과정에서 다른 사람과 자신을 교육하여 비즈니스를 깊이 이해해야 한다.

이 참여 및 피드백 과정은 목표에 맞추기 위해 필수적이다. 맞추는 것이 ‘자연스러운’ 상태가 아니며 투입값에 대해 개방적이고 중요한 것에 대한 실질적인 입장을 취해야 하는 것은 사실이다.

CEO, COO, CFO 등의 책임자와 연결하는 것으로는 부족하다. 임원 동료들도 답이 없을 때가 있다.

경험상 프로세스 전체가 완료되었을 때 모든 임원이 프로젝트의 우선순위 설정 방식을 이해하고 수락했는지를 확인하게 된다. 그렇다고 해서 그들이 모두 ‘만족’한다는 뜻은 아니지만, 그 전략이 비즈니스의 목표를 반영하고 거기에 동의한다는 것이다.

3단계: 적절한 계획을 수립하라
올바른 매개변수(parameters)들을 준비하고 최소 2년, 이상적으로는 3년 동안 정확히 어떤 일이 일어나야 하는지를 보여주는 계획을 수립한다. 안타깝게도 많은 기업이 근시안적인 1개년 계획을 수립한다.

팀원이 특정 세부사항에 대해서는 다소 확신이 없고 시간이 지나면 일정 목표에 도달한다고 가정하는 것은 맞지만 장기적인 목표에 지속해서 집중하는 것이 중요하다. 계획 과정에서 사람들이 특정 작업을 완수하도록 요청하면 공급을 초과하는 경우가 많고 동료들은 자신만의 ‘선호’ 프로젝트가 있을 것이다.

중장기적인 관점을 가지면 진정한 혁신을 계획하고 실행할 수 있게 된다. 이런 대대적인 변화는 항상 예상보다 많은 시간과 노력이 필요하기 때문에 이를 팀에 주지시키도록 하자.

필자는 한때 기술 전략을 수립하지 않고 5년 동안 조직에서 근무한 적이 있다. 당시 많은 전략적인 프로젝트가 비즈니스 목표와 연관되어 있었지만 포괄적인 계획이나 의제가 없었다. 계획도 있었고 프로젝트도 성공했지만 모두 ‘1개년’ 관점이었다. 아무도 그 이상을 계획하지 않았기 때문에 전략보다 작전이 우선시 되었다.

4단계: 아키텍처 로드맵과 전략을 맞추라
IT전략과 아키텍처 로드맵을 반드시 완전히 맞춰야 하며 ‘원하는 것, 필요한 것, 주어진 것’을 명확히 해야 한다. 아키텍처 로드맵은 주어진 조건을 들여야 볼 수 있도록 하며 현재와 미래의 상태를 파악하게 한다.

아키텍처 로드맵은 현재 애플리케이션과 하드웨어 인프라의 성숙도에 대한 기술적인 관점을 제공해야 한다. 이 장비의 수명이 언제 끝나는지 강조해야 하며, 아무도 이에 대해 논의하고 싶어 하지 않는 경우가 많다. 새로운 비즈니스 계획을 기존 앱과 시스템의 개선에 연계시키면 IT전략을 위해 적절한 균형을 유지하는 데 필요한 현실 점검을 제공한다.

아키텍처 로드맵을 IT그룹과 나머지 비즈니스 부문 사이의 논의를 대표하는 ‘인공물’로 활용하는 것이 좋다.

현업 임원들과 너무 많은 것을 공유하기를 주저하는 것은 당연하다. 사실 아키텍처 및 전략팀은 공통적인 어휘와 이해를 구성하기 위해 주요 이해 당사자들과 소통해야 하기 때문에 공유하지 않는 것 자체가 실수다. 우선 세부적인 기술 아키텍처가 비즈니스 전반에 걸쳐 계획된 변화를 지원하는 방법을 설명해야 한다.

5단계: 전략적으로 선택하라
기업 규모에 상관없이 CIO는 모든 요구를 충족하고 싶어 한다. 하지만 재정과 자원은 항상 부족하다. 이 때문에 현업 임원은 항상 어려움을 겪고 지나친 약속에 대한 압박이 존재한다. 이런 한계를 명확히 하는 것이 바로 CIO의 임무다.

비즈니스에 명확한 비즈니스 전략과 우선순위가 있는 순간이 있겠지만 솔직히 그렇지 않다고 생각한다. 최고의 계획을 세운 기업이라도 계획 시한을 벗어나는 ‘임시’ 규제나 전략 프로젝트가 있게 마련이다.

계획 가정을 확인하고 전략에 정확히 무엇이 포함돼 있는지 확실히 하는 중요한 요령이 있다. 예를 들어, 연초의 인력 활용도는 100%일 수 있지만 휴일, 교육, 공석이 발생하게 된다.

생각해야 하는 또다른 핵심은 필자가 ‘발견’이라고 말하는 것이다. 항상 위에서 시작돼 조사가 필요한 전략적인 디지털 프로젝트 같은 것이 있게 마련이다. 이를 위한 계획이 있어야 예산이 할당될 수 있다.

6단계: ‘IT의 비즈니스’를 실현하라
IT전략은 IT를 관리하는 방식에 대한 프레임워크를 제공해야 한다. 필자는 이것을 ‘IT의 비즈니스’라 부르며 이 프레임워크에는 구조, 역량, 능숙도 등의 ‘조직적인 아키텍처’ 측면이 포함된다.

이 의제를 끌어내 기업은 IT가 얼마나 개선되고 있는지 파악하도록 해야 한다. ‘IT의 비즈니스’는 IT를 실행하여 참여 모델과 비즈니스를 통합하고 좀 더 구체적으로 데브옵스 또는 애자일 방법론을 팀에게 가르치는 방식을 다뤄야 한다.

이 단계에서 대상 운영 모델을 개발하고 현재 상황에 도전해야 한다.


7단계: 끝을 맺으라
거의 끝난 것 같지만 아직 끝나지 않았다. 광범위하고 표적화된 메시지를 사용한 참여와 소통의 과정이 중요하다. 이를 위해 IT부서 내의 임원 및 동료와 공유하는 포괄적인 계획이 필요하다.

이런 참여 시점이 전반적인 IT전략 시간표와 맞아 떨어지려면 반복과 계획이 필요하다. 이런 참여의 과정을 통해 실질적인 끝맺음이 이미 이뤄지고 마지막 검토 시 새로운 것이 나타나는 일이 없게 된다.

전략을 끝맺고 지지하면 기업 전반에 걸쳐 더욱 광범위하게 공유할 수 있다. CEO와 임원들에게서 이런 수준의 지지를 확보하는 것이 중요한 단계며 확실한 지원을 확보하는 데 도움이 된다.

이제 준비가 끝났다. 행운을 빈다.

*David Gee는 일본 메트라이프생명 CIO며 그 전에는 CUA CIO를 지냈다. ciokr@idg.co.kr
 
X