이번 포스팅에선 ITSM의 허와 실에 대해 아주 주관적인 의견을 적어보고자 합니다.
일단 ITSM이 무엇이고 또 무엇이 좋은지는 대충 저번 포스팅을 통해 눈치챌 수 있습니다.
대부분의 큰 회사나 관공서 등등에서는 ISO 2000인증 및 CMMI 레벨 등을 따기 위해 관련 프로세스 정비와 시스템 도입을 해왔고 또 할 것입니다.
하지만 인증심사만 통과했다고 될 일은 아닙니다. 실재로 ITSM 내재화가 잘 되어야 됩니다. 그리고 인증점검도 1년에 한번 씩 나오기 때문에
드물지만 잘못하면 자격을 박탈당할 수도 있습니다.
근데 ITSM내재화.. 이게 참 어렵습니다.
사실 보통 ITSM을 추진하는 부서나 팀은 실제 개발,운영팀과는 별도로 꾸려져 있습니다.
물론 ITSM추진 부서(혹은 팀)가 개발,운영팀의 업무를 모르는 것은 아니지만
어찌 되었던 프로세스를 만드는 부서와 그 프로세스를 따라가야만 하는 부서로 나뉘어지고
결국 즉 성격은 다르겠지만 갑,을 관계가 만들어 집니다.
여기서 문제가 시작됩니다.
ITSM이란 것이 분명 좋은 것은 맞는데 실제 개발하고 운영하는 사람 입장에서는 여러가지 애로사항이 있습니다.
이해하기 쉽도록 예를 들어 봅시다.
변경에 관해서 살짝 봅시다.
변경관리에 의해 소스의 변경은 반드시 CAB(변경자문위원회)를 통해 승인을 받고
변경을 하고 나면 CRB(변경검토위원회)를 거치게 되어 있습니다.
하지만 아무리 큰 회사도 결국 작은 조직으로 나눠지기 마련인데 그 작은 개발 조직에서 CAB, CRB를 구성해서
변경을 수행하기엔 좀 무리수가 있어보입니다.
그래서 위원회란 이름에 맞지 않게 CAB,CRB를 한 명만 지정하여(관리자급) 해당 기능을 수행하도록 하는 경우가 생깁니다.
만약 한줄만 고쳐서 빨리 릴리즈 되는데 CAB나 CRB를 담당한 분이 부재중이라면,
그럼 상황이 애매해집니다.
더군다나 소스의 릴리즈 내지는 소스를 체크아웃하려면 승인단계를 지나야만 가능하도록 시스템 구현이 되어있기 때문에
(즉 물리적으로 승인이 나지 않으면 소스의 수정 및 반영이 안된다는 이야기..)
개발담당자는 빨리 개발을 해야겠는데 짜증이 날 수 밖에 없습니다.
이런 상황이 자주오게 되면 개발담당자가 자기를 CAB,CRB를 시켜달라고 ITSM주관부서에 요구할 수도 있습니다.
즉 CAB,CRB가 그야말로 형식적으로만 존재하고 개발담당자 본인이 변경을 맘대로 하는 경우도 생깁니다.
이와는 반대로 ITSM주관부서의 애로사항도 있습니다.
보통 SLA계약에서 주요 지표중에 고객요청에대한 납기준수율이란 것이 있습니다.
고객의 요청을 받으면 납기준수일을 정해서 이를 지켜야 된다는 자주 사용되는 지표입니다.
그런데 보통 납기준수율을 거의 99%이상 유지됩니다.
왜일까요? 그만큼 뛰어나게 서비스를 운영하기 때문일까요?
물론 그럴수도 있고 아닐 수도 있습니다.
피터드러커가 말했듯이 측정할 수 없는 건 관리할 수 없다라는 원칙에 따라
고객의 모든 요청은 ITSM에 의거 인시던트로 관리하게 되는데요.
이때 이 정보를 시스템에 입력하게 되어 있습니다.
즉 관련 내용을 ITSM시스템에 입력해야 하는 것인데요.
문제는 납기준수율을 99% 유지하기 위해서 몇가지 꼼수가 가능합니다.
아예 인시던트 등록을 안해서 아예 모수를 낮추는 꼼수가 있을테구요. (물론 이건 CSR처리건수 라는 지표로 보완이 가능할지 모르지만 근본적인 해결책이라 보기는 힘듭니다)
납기준수 날자를 고객과 합의하에 변경을 하는 꼼수가 있습니다. (혹은 합의하지 않고? - 물론 이는 ITSM관리 부서에서 컨트롤해서 잡아내야겠죠)
즉 고객이랑 대화해서 8월2일이 납기인데.. 대화하고 요구사항을 더 듣다 보니 납기준수날자를 8월5일로 미루겠다 그래서 시스템에 납기 날자를 변경하는 것입니다.
이건 당연한거 아니냐? 이게 왜 꼼수냐 할 수 있겠는데요.
보통 고객사와 서비스제공자인 현업개발팀과의 관계가 갑과 을의 관계는 맞지만 서로 같이 일을 많이 하다보면 친해질 수 밖에 없습니다.
그래서 보통 납기준수율을 거의 100%가 될 수 밖에 없는 경우가 의외로 많이 생깁니다.
납기준수율이라는 지표의 존재 이유는 납기준수율이 떨어지면 그 원인을 파악하자는데 있습니다.
인력이 부족한 것이냐? 아니면 요구사항이 너무 많아서 그런 것이냐?
근데 납기준수율은 위의 꼼수들로 인해 거의 99%이상이므로 실제로 인력이 부족하는 등 문제가 생겨도
조기에 발견할 수 없게되고 결국 납기준수율은 별 의미가 없는 지표가 되버린거죠.
이상 두가지의 경우의 예를 들었는데요. 무엇보다 ITSM내재화가 잘 안되고 꼼수가 생기는 이유는
실제로 개발을 진행하거나 서비스를 제공하는 현업개발팀의 이해를 완전히 이끌어내지 못했다는 데 있겠습니다.
무작정 다른 회사들이 한다고 ITSM을 도입하기 전에 충분히 현업개발팀에 대한 교육이 선행되지 않으면
삐걱삐걱될 수 있습니다.
물론 이렇더라도 ITSM도입을 하는 것은 IT관리를 투명화한다는 점에서 적극 추천하고
많은 기업이 이미 시행착오 끝에 지금은 ITSM내재화를 성공적으로 이뤄서 IT서비스 효율이 높아졌다는 것도 사실이지만
위에서 언급한 함정에 빠지지 않도록 노력도 게을리 하지 않아야 겠습니다. :)
변화에 대하여 : http://blog.naver.com/zacra/120197623910
UI/UX에 대한 쉬운 이해 : http://blog.naver.com/zacra/120197578988
C구조대의 더 많은 정보, 글, 사진은 아래 자밥 스튜디오 페이지에서도 볼 수 있어요 ^^
http://www.facebook.com/zabobstudio
