02. ITIL 적용 사례- "IT-IT 갈등"

2016/02/16 - [02.관리-IT] - 01. ITIL 적용 사례 - "IT-업무 갈등"

2016/02/16 - [02.관리-IT] - 02. ITIL 적용 사례- "IT-IT 갈등"

2016/02/16 - [02.관리-IT] - 03. ITIL 적용 사례 - 문제 처리

2016/02/16 - [02.관리-IT] - 04. ITIL 적용 사례 - 마무리 정리(ITIL 적용 현실)

ITIL에서 설명하는 조직 모델과는 조금 다른 경우를 생각해보자. 달봉이가 일하는 곳에서의 SM은 아웃소싱으로 되어 있어서, 고객 조직과 SM 조직은 계약관계로 되어 있다. 현재 달봉이가 있는 조직에서는 고객 조직에도 IT 조직이 포함되어 있다. 즉 현업IT팀이 SM의 IT팀과 별도로 존재한다. 이 현업 IT팀은 SM의 전체 조직을 관리하고 있다. 물론 이 팀은 내부적으로는 현업 사용자들로부터의 IT에 대한 요구사항을 받고, IT 전략과 정책을 수립하는 등의 역할도 하게 될 것이다. 

현업 IT팀 - 고객 IT팀. 업무 시스템 사용자팀 SM IT팀 - 이 팀은 업무 시스템 운영팀과 IT 팀( 인프라, 기술지원 담당)으로 구분된다.

이런 조직 구조에서 현업 IT팀과 SM의 IT팀과의 다음 대화를 살펴보자. 실제로 있었던 대화 내용이다.

☞ 현업 IT팀 

   저는 이 어플리케이션을 개발하기 위해서 다른 어플리케이션에서 사용하고 있는 윈폼 UI 프레임워크를 사용하고 싶습니다.

   윈폼 프레임워크를 사용해서 사용자의 메뉴 관리나 권한 관리를 그대로 사용하고 싶기때문입니다. 

   다만 메뉴 출력 방식을 다르게 하고 싶습니다. 기술적으로 가능하겠습니까?

☞ SM IT팀 

   기술적으로 가능한지 여부의 문제가 아닙니다. 

   영향도와 안정성의 문제입니다. 

   요구사항을 받아들이자면 UI 프레임워를 수정해야 합니다. 

    이것은 다른 어플리케이션의 안정성에 영향을 주게 됩니다. 

    담당자로서 그 안정성의 위험을 감수할 수 없습니다. 

    성격상 그 어플리케이션은 웹으로 구현하는 것이 맞을 것 같은데, 이 기회에 웹 프레임워크를 도입해서 사용하세요.  

☞ 현업 IT팀 

    비용과 공수를 최소화하기위해서입니다. 

    SM팀은 고객이 원하면 해 줘야 하는 것 아닌가요?

☞ SM IT팀 

     f~~! blah,blah #$%^~~~

작은 예이기는 하지만 회사 생활이 힘들어지는 것은 이런 작은 갈등 때문이다. 원론적으로 보면 이런 예든, 이익과 관련된 갈등이건 동일한 구조의 갈등으로 볼 수 있다. 이 케이스도 이전에 본 케이스에서와 같이 SLA가 없고, 변경 관리 프로세스와 프로세스 담당 역할이 정의되어 있지 않다는 문제가 공통적으로 있다. 

ITIL에는 이런 고객 IT와 SM IT간의 구조를 예로 한 직접적인 정의는 없는 듯 하다( ITIL의 마스터 단계에서는 나오는지 모르겠다). 하지만 ITIL이 제시하는 "고객<->IT"와의 관계로 위 상황을 분석해 보면 아래와 같다. 고객과 <->IT 사이에 제공되고 받는 것은 "서비스"이다. 두 조직간의 대화 레벨은 서비스 레벨이여야 한다. 즉, 고객은 요구하는 서비스를 설명하고 IT는 그 서비스를 제공해야 한다. 그 서비스가 어떻게 구현되는지 결정하는 것은 IT의 몫이다. 고객이 WHAT을 요구하면 IT는 HOW를 결정하는 것이다. 이렇게 현업 IT팀을 고객으로 해석하면 분명 현업 IT팀이 월권을 하고 있다.  

그러나 현업 IT팀은 고객이면서도 IT에 관여하고 있다는 것이 문제이다. 이런 상황이라면 현업 IT팀이 IT에서 무엇을 어떻게 얼만큼의 R & R을 수행해야 하는지 정확히 정의해야 하고 상호 공유해야 한다. 달봉이는 이 경우도 ITIL을 참조해서 해결 방안을 찾고 싶다. 우선 ITIL에서 제시하는 모든 프로세스는 단계별로 아래와 같다. 

■ 서비스 전략 단계 프로세스

- 전략 관리, 서비스 포트폴리오 관리, 재무 관리, 현업 사용자의 요구사항 관리, 현업 사용자와의 비즈니스 관계 관리

■ 서비스 설계 단계 프로세스

- SLM 관리, 공급자 관리

- 기술적 관련 프로세스( 가용성 관리, 정보 보안 관리, IT 서비스 연속성 관리, 용량/성능 관리 ), 

- 서비스 카테고리 관리, 서비스 조정(coordination) 관리

■ 서비스 전환 단계 프로세스

- 서비스 자산(Sevice Asset)관리, configuration 관리

- 변경 관리

- 전환 계획 및 지원

- 릴리스 및 배포 관리

■ 서비스 운영 단계 프로세스

- 이벤트 관리, 인시던트 관리, 문제 관리, 서비스 요청 수행, 접근제어 

■ 지속적 서비스 개선 단계 프로세스

- 서비스 측정 및 베이스 라인 관리

- CSF(Critical Success Factor), KPI, 메트릭 관리

이렇게 프로세스들을 정리해놓고 보면 어느 프로세스가 IT의 어느팀에서 관리해야 하는지 대충 눈에 들어온다. 전략적인 차원, 전술적인 차원 그리고 운영적인 차원이라는 기준을 정의해 놓을 수 있을 것이다. 전략을 수립하고 CSF(Critical Success Factor) 기반의 KPI를 설계하는 등의 프로세는 현업 IT팀에서 담당한다. 그리고 운영 차원의 프로세는 SM IT팀에서 맡는다.

문제는 전술적인 차원의 프로세스이다. 이 프로세스들은 설계와 결정이 필요한 프로세스들이 많다. 그래서 두 IT팀에서 모두 관여를 해야 한다. 설계 단계의 프로세스들의 경우는, 프로세스에서 요구하는 전문성에 따라서 양쪽에서 분리,관리하도록 협의가 필요할 수 있다. 

이때 중요한 것은 순전히 영업적인 이익에 따라서 분리하는 것은 문제가 있다. 프로세스들은 IT 내부의 문제로서 기술과 관련 프로세스들이다. 이것을 영업적인 기준으로 구분하면 양측 IT팀간의 마찰이 있을 위험이 있을 것으로 보인다. 이때 필요한 것이 컨설팅업체처럼, 제3자적 관점을 갖는 조직을 구성해서 이용할 수도 있을 것 같다.