04. ITIL 적용 사례 - 마무리 정리

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 적용 현실)

시스템 유지 보수(System Maintenance, SM) 조직에서 일하면서 다양한 조직간의 갈등을 제3자로서 보기도 했고 직접 경험하기도 했다.  

"SM조직 <-->고객 조직과의 갈등"

"SM 내부의 IT팀<-->업무 운영팀과의 갈등"

"고객 IT팀<-->SM IT팀과의 갈등"

갈등을 조직 구조상의 관계보다는 "고객과 IT"라는 관점에서 다시 정리하면 다음과 같이 크게 정리할 수 있을 것 같다. 

"고객<--> 고객 IT"

"고객<--> SM IT"

"고객 IT<-->SM IT"

"SM IT<-->SM 업무운영"

IT 운영과 관련된 모든 조직들간에 갈등이 있다는 것이다. 이 갈등 관계를 개선하기 위해서 어떻게 해야 할까를 나름대로 고민한 포스트라 할 수 있다. 앞의 글들을 읽어보았다면 달봉이 의도는 이런 갈등 해결을 당사자들간의 태도나 개인적인 노하우로 해결하려는  것이 아님을 알 수 있다. 달봉이는 이 문제를 개인 역량문제보다는 체계와 시스템의 문제로 보려고 하고 있다. 

참고로, 

이번 포스트는 달봉이가 근무하고 있는 곳의 조직 구조에 대한 이야기를 할 것은 아니지만 잠깐 소개하는 것이 이해에 도움이 될 것 같다. 앞에서 "고객 IT팀"으로 표현하고 있는 팀은 SM 조직과는 별도로 고객사에 있는 "IT 담당 팀"을 말한다. SM조직에도 IT팀이 있는데, SM의 IT팀에서는 HW/NW, SW적인 인프라를 각각 담당하고 있다. "인프라", "기술지원"팀으로 불린다. "SM 운영팀"은 업무 어플리케이션을 운영하는 팀을 말한다. 

■고객<-->IT 관계

우선 IT의 대외 관계 개선에 대한 방안을 알아볼 것이다. 그러나 방안이 현실적으로 한계가 있을 것이라는 것을 인정할 것이다. 그래서 차선책으로 IT 대내 정비에 대해 생각해 볼 것이다.

☞ IT, 대외 관계 개선 방안 - ITIL 적용 및 한계

고객과 IT의 갈등을 해결할 수 있는 방법을 검토하다 보면 결국에 가서는 주로 "ITIL 기반의 ITSM(IT Service Management) 체계를 도입하자"는 것에 도달하게 된다. 이러한 접근으로 해결하려는 노력은 잘 알려진 방법이다.  많은 이와 관련해서 많은 아티클과 논문도 나온다. 이런 결론에 도달하게 되는 가장 큰 이유는 ITIL에서 제시하는 28개의 프로세스 중에서 "SLM(Service Level Management)"때문일 것으로 본다. SLM이 바로 고객과 IT와의 갈등 구조를 없애고 합리적인 관계를 형성하는 것을 목표로 하는 프로세스이기 때문이다. 

그러나 달봉이 개인적인 생각도 그렇고, SLM을 컨설팅하는 사람들의 얘기도 들어보면 "고객의 의식과 조직 문화의 변화없이 IT만의 노력으로는 SLM에 의한 해결은 힘들다"는 것이다. 문화적인 측면뿐만 아니라 수익 모델의 특성상 특히 제조업 및 서비스업등에서 SLM을 도입하는 것은 쉽지 않은 일로 보인다. 이런 업종의 수익 모델에서 IT는 "leading 역할"보다는 "지원 역할"이기 때문이다. 그리고 권위주의와 "갑-을"관계에 의지하고 있는 수직적 구조의 조직상에서는 bottom-up 방식으로는 SLM 관계 확립은 사실상 힘들다고 보여진다. 인식이 깨어난 경영자로부터의 top-down 방식의 쓰나미가 내려오지 않는 이상. 

ITIL기반의 ITSM 체계의 도입에는 의식과 문화의 변화 뿐만 아니라 더구나 재무적인 투자 지원도 있어야 한다. 의식 변화도 없는데, 재무적인 투자 지원에 대한 정당성을 확보하기란 엄청 힘들것으로 보인다. 아무리 비재무적인 성과가 힘을 얻고 있어도 BSC(balanced score card)에서 가장 힘있는 관점은 아직은 "재무적인 관점"이다. 재무적인 관점에서 SLM이 얼마나 많은 도움이 될지 증명하지 않으면 투자에 대한 정당정 확보가 힘들다. SLM에 대한 재무적인 정당성 확보를 위해서는 다시 비재무적인 관점을 재무적인 관점에 연결시켜주는 BSC 체계 확인이 선행되어야 할지도 모른다. 많은 조직에 있어서 비재무적인 투자에 대한 인식을 가지고 있지 않은 경영진을 대상으로 합리적으로 설득하기 위해서 필요한 부분은 끝도 한도 없어 보인다.

경영진과 조직원들의 의식의 변화없이 단순히 ITSM 솔루션만 도입해서 쉽게 해결하려고 하는 것이 얼마나 실패할 가능성이 많은지는 ITSM의 사상과 ITIL의 practice를 공부해 보다보면 쉽게 알 수 있다. 솔루션이 도입되어 성공적으로 정착하기 위해서는 우선적으로 경영진과 현업 사용자들이 SLM을 거부감없이 받아들여야 한다. ITSM, ITIL이 SLM에 얼마나 의존적인 체계인지를 알게 되면 단순한 솔루션 도입이 문제를 해결해 줄 수 없다는 것을 알게 된다. 

또한 ITIL에서 두번째로 중요하게 생각하고 있는 프로세스가 "변경관리"이다. 변경 관리는 조직의 서비스 자산과 configuration을 "정의(!!)"하고 그것에 가해지는 모든 변경은 기록,모니터링, 관리하는 것이다. 서비스 자산과 configuration를 정의하고 변경을 관리하는 프로세스는 "지속적으로 서비스를 개선"할 수 있는 구조를 만들기 위한 사전 필수 프로세스이다. 

근데, 현실에서는 서비스 자산과 현재의 configuration을 정의하는 부분부터 힘든것 같다. 그리고 업무 프로그램 또는 IT 시스템의 모든( ALL !!) 변경 내용은 변경 관리자(Change Manager)에 의해서 관리되어야 하지만 이것도 만만찮다. 달봉이가 지금 근무하는 조직에서처럼 어디선가 자체적으로 변경을 하고 끝내버리는 구조라면, 이런 중앙 집중적인 구조로 바뀌는데 많은 노력이 필요할 것이다. 그래서 단순한 ITSM 솔루션 도입이 아니라 ITSM 도입을 위한 컨설팅 및 별도의 프로젝트가 진행되어서 조직원들 대상으로 하는 변화에 대한 교육이 있어야 한다. 

※ 참고로, 앞에서 모든 변경 사항을 관리해야 한다고 했지만, 모든 것을 변경 관리자(또는 변경 관리 위원회)를 통해서 "승인"되어야 한다는 것은 아니다. ITIL에서는 몇 가지 종류의 변경이 있고, 이 중에서 "Standard Change"같은 변경은 노트북 배포처럼 이미 절차가 잘 정의된 변경은 관리는 되어야 하지만 승인없이도 환경에 적용될 수 있다. 

☞ IT, 대내 정비 방안 - ITIL 적용 현실론

아직 경영과 경영 전략에 대해서는 잘은 모르지만 아무리 제조업 및 서비스 업종에서라도 "고객과 IT의 합리적인 관계 수립"이 

경영 전략에 반하는 것은 아닐 것이라고 믿고 있다. "고객<->IT"의 합리적인 관계 수립이 필요하지만 bottom-up이 힘들다면 top-down을 기다리고 있어야만 할까? 명민한 지도자 동지가 재림할때까지 손놓고 가많히 있어야 하는가? IT에 속한 우리가 지금 할 수 있는 일은 없을까?  지금은 손놓고 있어야 하나? 

지금 달봉이가 낼 수 있는 아이디어는 언젠가 "고객과 IT에 대한 관계 확립"을 위한 투자가 정당성을 확보할 수 있는 그 순간을 기다리면서 준비를 하고 있어야 한다는 것이다. 그러나 언제 올지도 모르는 그 순간만을 위해 무작성 준비를 하자는 것은 아니라고 본다. 준비해야 하는 그 내용은 지금 당장의 이슈도 해결할 수 있어야 한다. 그럼 어디서부터 뭘 준비해야 할까? 

IT가 제공하는 "서비스"가 고객에게 전달되는 다음과 같은 구조를 생각해 보자.

고객 <- 서비스 <- IT 서비스 제공자

SLM은 고객과 <--> IT 서비스 제공자간의 관계에 대한 합의이다.이것은 앞에서 말한 훌륭한 지도자가 오기를 기다려야만 하는 부분이다. 그러나 ITIL에는 외부 고객과의 합의뿐만 아니라 IT  서비스 제공 조직 내부의 관계도 구체적으로 계약에 의해서 확립되기를 권고하고 있다. 제대로된 대고객 서비스가 제공되기 위해서는 IT 서비스 제공자 조직 내부에서는 "프로세스와 역할,조직"이라는 것이 확립되어야 한다는 것이다. 다시 말하면, IT 서비스 제공 조직 내부의 프로세스와 역할,조직이 SLM 정확히는 SLA(Service Level Agreement)에서 "측정할 수 있는(measurable)" 구조로 되어 있지 않으면 안된다는 것이다. 

참고로, 

ITIL에서는 "프로세스와 역할"을 "process와 function"이라고 정의하고 있다. 여기서 function이라 함은 전담 조직 또는 역할을 의미한다.

대부분의 IT 내부 조직간의 갈등의 원인은 "프로세스와 역할이 정의되지 않았거나 부적절하게 정의"되어 있기 때문이다. 달봉이는 우선 IT 내부의 업무 처리 프로세스들이 ITIL에서 제시하는 best pracice를 참조해서 변화되어야 한다고 본다. ITIL에서 제시하는 28개의 프로세스와 현재 자신이 속해있는 조직의 프로세스를 비교해 보면, 자신의 조직에 얼마나 많은 구멍이 있는지 알 수 있게 된다. 이 구멍들은 결국 갈등의 원인이 될 수 있다. 물론 ITIL의 프로세스들이 모두 현실적인 것은 아닐 수도 있다. 너무 과한 부분이 있다는 것도 알 수 있다. 

요는 ITIL에서 제일 중요하다고 여겨지는 SLM이 도입될 수 있는 내,외적인 여건이 성숙되지 않았다 하더라도 내부의 업무 처리 프로세스는 그 best practice를 기준으로 정비하자는 것이다. 

참고

조직이 오래되어서 구성원들의 경험이 많다 하더라도 프로세스 정의을 한번에 완성하려면 물론 돈이 투입되어야 할 것이다. 프로세스 정리 작업이 초기부터 시작되어 지금까지 꾸준히 전담해서 진행해온 사람이 있었으면 지금쯤은 아마 한꺼번에 돈을 투자하지 않아도 충분히 질 좋은 프로세스 정의가 나왔을 것이다. 그러나 현실적으로 힘들것이다. 경제가 어려워지면 기업은 원가를 줄이기 위한 작업이 제일 먼저 일어나는 곳이 바로 비용 및 공통 원가를 줄이는 곳에서부터 시작된다. 제조업 및 서비스업에서 IT는 비용 및 공통 원가이다. IT에 대한 투자부터 줄인다는 얘기다. 그렇지만 해야 한다. IT의 누군가는 내부적인 프로세스를 정의해야 한다.

■IT(고객)<-->IT(SM) 관계

두번째 "IT(고객)<-->IT(SM)"의 갈등 구조는 ITIL의 Foundation에서는 찾을 수 없는 사례이다. ITIL에서는 "IT와 업무" 관계만을 고려하고 있다. IT는 모두 동종으로 보고 있다. 그러나 달봉이가 있는 조직에서처럼 현실적으로 이런 형태의 관계도 아웃소싱 계약에 의해서 많이 만들어지고 있다. 

"IT-IT 갈등 구조"도 달봉이가 관심을 갖는 주제중의 하나이다.  달봉이는 이 관계의 문제도 ITIL을 참조해서 해결 방안을 찾으려고 노력하고 있다. "IT-IT"구조의 갈등은 계약 관계를 떠나서 같은 입장의 IT 조직으로서 프로세스와 역할 정의가 되지 않았거나 또는 되었더라도 불명확하게 되었다는 것을 의미할 것으로 추정할 수 있다. 즉 ITIL에서 제공하는 IT 내부의 프로세스 정의를 참조해서 해결하고 싶은 것이다.

이 부분에 대해서는 이전 포스트에서 잠깐 언급했다.

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

■SM IT<-->SM 업무운영 관계

처음에 달봉이가 해결하려고 고민했던 갈등 구조는 앞의 두 경우와는 좀 다른 성격의 관계였다. IT의 SM 조직 내부에서 "SM IT <--> SM 업무 운영"간의 갈등 관계였다. 달봉이는 "SM IT팀"에서  기술지원을 담당하고 있다. "SM IT<--> SM 업무 운영"간의 갈등을 고민하면서 얻은 결론을 미리 말하면 이렇다.

같은 조직 내부의 하위 팀간에도 "서비스 제공자와 고객" 구조의 문제로 보고 대응해야 한다는 것이다.

따라서, "업무 운영팀"도 IT팀의 "고객"으로 봐야 한다는 것이었다. 인프라와 기술지원의 특성상 같은 SM에 속하는 팀이라도 업무 운영팀으로부터 서비스를 요구받고 제공해야 하는 관계인 것이다.

해서 아이디어를 얻은 것은 고객과 IT간에 SLA(Service Level Agreement)가 이뤄지듯이 IT 내부 조직간에도 SLA와 유사한 합의가 이뤄져야 한다는 것이었다. 이것은 달봉이의 주장이 아니라 ITIL의 주장이다. 바로 OLA( Operational Level Agreement)로서 이것은 IT 서비스를 제공하는 조직내의 하위 부서,팀간의 합의( written arrangement)를 말한다.SLA에 대 고객 서비스가 정의되어 있어야 하는 것처럼 OLA에도 내부 조직간의 필요한 서비스가 정의되어 있어야 한다.  

IT의 인프라와 기술지원은 대 고객에 제공되는 서비스를 만들어내는 어플리케이션이 잘 작동하도록 하는 기반을 제공해서 서로 공조하고 협력해야 하는 팀들로서 "같은 조직"하에 있어야 한다는 것이 달봉이의 생각이다( 자세한 내용은 뒤의 " '인프라'와 '기술지원' 관계 및 역할 정의"에서 설명한다).즉 SM의 IT내에서 인프라와 기술지원은 같은 조직으로서 SM의 운영팀을 대상으로 해서 주고 받아야 하는 서비스가 정의되어야 한다는 것이다. 

업무 운영팀에서는 해당 문제가 인프라 문제인지 기술지원팀과 관련된 문제인지 구분을 잘 하지 못한다. 즉 인프라 팀과 기술지원팀을 한 조직으로 해야 하는 이유이다. 단일 창구를 통해서 IT팀에 접수가 되면 적절한 처리 프로세스는 내부적으로 진행되어야 한다.

인프라 팀과 기술 지원팀이 같은 조직에 속해야 함을 별도로 정리했다.

■"인프라"와 "기술지원" 관계 및 역할 정의  

달봉이가 근무하는 SM 조직 내부의 IT팀을 좀더 들여다 보면 소위 "인프라"와 "기술지원"으로 나뉘어져 있다. 관리대상이 HW/NW냐 SW/AP인가에 따라서 구분해놓은 듯 하다. 이 두 팀은 조직도에서 정의되는 것을 보면 왜 이럴까 하는 정도였다. 같은 팀으로 묶였다가 또 어떤 때는 다른 팀으로 묶였다가 그리고 나서 다시 같은 팀으로 묶였다가. 이렇게 조직 구조가 자주 바뀌고 구조에 대한 자신감이 없는 것처럼 보이는 것은 이 조직에 대한 정의를 어떻게 해야 할지를 모르고 있다는 것으로 보였다. "인프라", "기술지원" 팀 자신들도 어떻게 정의해야 할지 몰라서 엑셀 조직도에서 그려지는대로 이리 뭉쳤다 저리 뭉쳤다는 하는 것 같았다. 

그러면서 느끼게 된것은 "인프라와 기술지원팀"의 조직 구조에 대한 자신감 부족(?)은 IT를 "운영 및 관리"를 하는 조직이라는 소극적인 시각과 내부적인 시각때문이었다는 결론을 짓게 되었다. 만약 IT팀을 "대 고객 서비스를 제공해야 하는" 책임을 갖는 존재로 인식했다면 조직에 대한 인식은 지금과는 다르게 되었을 것이라는 생각을 하게 되었다. 

"서비스"를 제공해야 하는 객체로 추상화시키게 되면 그 객체를 "잘 만들어 내는데 필요한 IT 내부의 요건들이 무엇일까를 고민하게 될 것으로 본다. ITSM에서는 "질 좋은 서비스를 만들어 낼 수 있는 IT 내부의 역량"을 "프로세스와 역할(function)"으로 정의하고 있다. 

참고로, 

서비스를 잘 제공하기 프로세스와 function을 IT의 "서비스 역량(Service Capacity)"이라는 용어로 정의하고 있다. 즉 ITIL에서는 프로세스와 역할 및 조직이 정의되지 않으면 대 고객 서비스에 대한 역량이 없다고 보는 것이다. IT가 대 고객 서비스를 구현하기 위해서 설계할때는 서비스 역량 뿐만 아니라 리소스( 인력 포함), 조직(Organization), 기술(Technology)도 함께 고려되어야 한다고 한다. 

"질 좋은 서비스를 만들어 내기 위한" 관점에서 보면 "인프라"와 "기술지원"은 떨어질 수 없는 관계임을 알 수 있다. 이 두 조직을 단순히 각각 하드웨어와 어플리케이션을 각각 유지 보수하는 조직으로 인식하게 되면 별개의 조직이 되지만, 품질 좋은 서비스를 제공하기 위한 목적이라면 두 팀간의 Good communication이 얼마나 중요한가를 조금만 생각해보면 알게 된다. 이 두 조직간의 밀접한 관계는 별도의 문서로 정리했다. 

■ 공유 및 내재화 그리고 지속적인 서비스 향상

마지막으로 "정의" 만큼이나 중요한 것이 바로 "공유를 통한 내재화"임을 언급하고 싶다. 정의에 참여한 몇몇 사람, 그룹에서만 공유되면 소용없다. 소위 조직내에서의 "내재화"라는 실제적인 목표가 달성되지 않고 "정의"로만 그치게 되면 무의미하다. 무슨 외부 인증기관의 인증을 받기 위한 작업이 아니다. 실제적인 효과가 필요한 문제이다. 꾸준한 교육을 통한 조직 구성원들간에 "내재화"가 되어 문화로 만들어져야 한다. 이렇게 해야 "인물의 역량에 따라서 효과 및 능률에 굴곡이 있는 것이 아니라 소위 체계에 의해 운영되는 조직이 되는 것"이라고 본다.

SLA나 OPA에서 가장 중요한 특성은 "측정가능(measurable)"해야 한다는 것이다. 측정 가능해야 비교를 통한 개선이 가능해지기 때문이다. 이때 측정 관점은 "서비스 관점" 즉 "고객의 만족도 점수"로 통합되어져야 한다는 것이 ITIL에서 주장하는 SLM의 정신이고 이것이 "IT를 서비스"로 보자는 사상의 진정한 개념이다. 

※ "고객의 만족도 점수"를 어떻게 측정해야 하는지는 별도의 문제이다. 설문 조사를 하든, 서비스 요청에 대한 후기에서 평가를 요청받든 아니면 일대일 면담을 할 수 있는 인공지능 로봇을 도입하든. 

■ 정리 후기

달봉이가 처음에 현재 직장의 기술지원에서 일을 시작할때는 너무 힘들었다. "이전부터 그래왔다"는 식으로 많은 일들이 달봉이에게 넘어왔다. 텃세처럼 느껴지기도 했다. 역할 및 책임의 구분을 위한 기준도 없었고, 정의도 되어 있지 않았다. "SM 업무팀"과의 갈등도 있었다. 

SM의 각 팀들은 자신들이 하는 일과 역할에 대해서 정의를 해야 하는 시기도 있었다. 경기가 좋지 않게 되면서, 경비를 줄여야 하는 고객이 각 팀 및 개인들이 하는 일들을 알고 싶어 했던 것 같다. 처음에는 "SM 내부에 팀과 역할에 대한 정의가 있지 않을까? 그것도 없이 어떻게 SM 조직이 운영될까?"하는 생각을 했다.근데 없었다. 아무도 SM의 "인프라"와 "기술지원" 팀의 하는일과 역할을 만족할만하게 내어 놓지 않았다. 구두로 몇몇의 주장과 의견이 있을 뿐이었다. 내가 고객이라고 해도 답답했을 것 같았다.

그때부터 달봉이가 속한 "기술지원"팀의 역할 그리고 더 나아가 "인프라"팀을 포함한 SM의 IT팀에 대해서 역할을 정의하는데 관심을 갖기 시작했다. 하는일에 대한 설명을 요구받으면 언젠가는 촤~악 펼쳐보여주고 싶었다. 그러나 쉽게 끝나지 않았다. 초기 버전의 결과는 같은 IT팀원에게도 호응을 받지 못했다. 시간이 흘러서 보니 너무 기술적이고 세세했다. 무슨일을 하네 무슨일을 하네가 모두 기술적인 부분이었다.

그러다가 ITSM의 사상을 떠올리고 내 조직의 내부에 집중하던 시선을 외부로 돌렸다. 업무 프로세스 상 SM의 기술지원과 인터페이스를 해야 하는 외부가 누구이고 그들은 우리가 뭘하는 팀으로 봐야 할까? 그때부터 SM 업무 운영팀도 SM IT팀의 입장에서는 고객이라는 관점을 갖게 되었다. 그러면서 "어떻게 해야 외부에서 우리팀에 기대하는 역할과 우리팀 자신이 정의하고 있는 우리의 역할을 일치시킬 수 있을까"를 고민했다. 내부에서 무슨일을 하는지보다는 외부 고객의 관점에서 우리가 어떤 서비스를 제공하는지에 대해서 "정의하고 공유"하는 것이 하는 것이 답이라고 생각했다. ITSM적인 사상으로 접근하자는 생각을 하게 되었다. 이렇게 해서 "개인적인 프로젝트"가 시작되었다.

개인적인 프로젝트의 산출물을 정리했다

2016/07/27 - [02.관리-IT] - "관리가 무엇인지"를 배우다.