‘바다를 끓이려 하다 外’ ITSM을 망가뜨리는 5가지

ITSM은 최종 사용자에게 IT 서비스를 설계하고 제공하기 위한 정책 및 절차다. IT 지원 또는 헬프 데스크를 넘어 비즈니스 요구사항을 충족하기 위해 IT 서비스를 지속적으로 개선하는 데 필요한 모든 모니터링, 관리 및 문제 해결을 다룬다.

효과적인 ITSM을 위해서는 무엇보다도 서버 및 데이터베이스와 같은 기술 구성요소가 어떤 애플리케이션을 지원하는지 파악하고 해당 지식을 적절히 문서화하며 지원 프로세스를 미세 조정해야 한다. 시간이 지남에 따라 이러한 관계와 의존성이 더욱 복잡해짐에 따라 ITSM은 지나치게 비싸지고 비즈니스보다는 기술에 지나치게 집중하게 될 수 있다. 여기 ITSM이 잘못될 수 있는 몇 가지 흔한 잘못들과 이를 피하는 방법을 살펴본다.

바다를 끓이려 시도하기
코펜하겐 공항의 IT 자산 및 서비스 관리 책임자인 크리스찬 호르트키에르는 “너무 많이 너무 빠르게 하지 말라”라고 강조했다. 그의 조직은 서비스나우의 ITSM 플랫폼을 활용해 ‘사고 관리 및 변경 관리와 같은 핵심 ITSM부터 시작’했지만, 노트북과 소프트웨어와 같은 플랫폼으로 활용을 제한했다. 

그 후 공항은 ITSM을 출입카드 및 주차허가 정리와 같은 다른 서비스로 서서히 확장했다. “처음부터 모든 서비스를 제공했다면, 시간과 자원이 필요했기 때문에 우리는 비참하게 실패했을 것이다”라고 그는 말했다.

사용자들을 위한 지식 기반을 만드는 것은 “우리가 지나치게 야심을 가졌던 분야다. 그러나 이를 업그레이드하고 유지하기 위한 적절한 프로세스를 실행하지 못했다”라고 그는 말했다. 부정확하고 시대에 뒤떨어진 정보를 샅샅이 검토하는 것은 문제를 바로잡을 때 시간과 노력이 필요할 수 있다고 호르트키에르는 덧붙였다.

가트너의 선임 연구이사인 크리스 매트체트는 “핵심 기능부터 소규모로 시작하여 정기적으로 검토한다. AI와 같은 고급 활동으로 넘어가기 전에 확실히 IT 조직 문화의 일부라고 느끼도록 해야 한다”라고 조언했다. 

또 프로세스를 자동화하기 전에 문서화하고 최적화할 것을 그는 제안했다. “프로세스가 근본적으로 깨진다면 자동화는 계속해서 잘못된 결과만을 가져다줄 수 있다”라는 설명이다.

호르트키에르에게 첫 번째 단계 중 하나는 서비스나우를 활용하여 일반적으로 CMDB라고 하는 공통의 데이터소스를 만드는 것이었다. 그는 “CMDB는 비즈니스 어플리케이션에 잘 문서화된 링크를 갖고 있다. 예를 들어, CMDB를 사용하여 어떤 서버에 어떤 서비스가 종속되어 있는지 추적하면 IT 직원이 어떤 운영 중단이 가장 중요한지 결정하여 복구를 시작하고 사용자에게 해당 문제를 신속하게 알리는 데 도움이 된다”라고 전했다.

ITSM용 ITIL 프레임워크를 사용하는 고객은 명확하고 잘 정의된 IT 서비스 카탈로그 및 관리 프로세스를 만들어야 한다고 검사 및 테스트 회사인 앱플러스(Applus)의 CTO인 루베 아빌라 칼보는 조언했다. 

그는 “ITIL은 각 단계가 적절히 문서화되고, 책임이 명확하며, 서비스가 약정된 SLA로 제공되도록 보장하는 절차가 시행 중인 경우 프로세스, 역할 및 책임을 명확하게 정의할 수 있다는 것을 암시한다. 이를 제공하지 못하면 서비스 문제가 잘못된 직원에게 전달되기 때문에 비용이 더 많이 들고 서비스의 질이 낮아질 수 있다”라고 말했다.

농업 화학 회사인 코르테바의 글로벌 최종 사용자 서비스 책임자인 세실 블랙번은 사용자 지원 티켓이 주말 동안 일한 팀이 아니라 일하지 않은 팀을 지원하기 위해 전달되었던 때를 기억한다. 그녀는 “비즈니스 서비스를 해당 서비스를 제공하는 IT 구성요소와 동일시하는 어려움 때문에 우리의 비즈니스는 중단되기까지 했다”라고 말했다.

비즈니스를 간과
ITSM에서 ‘IT’에 초점을 맞추고 싶은 유혹이 있지만, ITSM의 진정한 목표는 비즈니스 서비스를 제공하는 것이다. 비즈니스를 염두에 두고 ITSM을 설계하지 않고 비즈니스 용어로 ITSM의 이점을 설명하지 못하면 채택이 줄고 비즈니스에서 ITSM을 더 혼란스럽게 사용하게 된다.

호르트키에르는 “현업 담당자라면 IT가에 얼마나 많은 사고가 생겼는지 전혀 신경 쓰지 않는다. 신경 쓰는 것은 내 애플리케이션, 내 애플리케이션에 얼마나 많은 사고가 있는지, 그리고 그것들이 어떻게 해결됐는지다 ”라고 말했다. 

그는 이어 사고를 올바른 구성 항목과 연계할 수 있다면, 그리고 나서 올바른 비즈니스 애플리케이션으로 연결된다면 의미 있는 보고서를 CEO에게 제공할 수 있다면서 “이러한 서비스가 공항 운영 개선에 어떻게 도움이 되는가 라는 맥락에서 말할 수 있다”라고 전했다.

코르테바가 서비스나우 ITSM을 사용하여 해결한 과제는 서로 다른 IT 구성 요소를 연결하는 것이었다. 

코르테바의 엔터프라이즈 서비스 통합 책임자인 크쉬티 바하두는 “덕분에 애플리케이션 소유자가 비즈니스에 제공할 애플리케이션을 구축하기 위해 서버, 데이터베이스 및 방화벽 팀을 추적할 필요가 없어졌다”라고 말했다.

애리조나 길버트 타운의 기술 담당 부책임자 유진 메히아와 그의 팀은 1,600명의 직원을 위한 경험을 개선하는 것을 ITSM 노력의 주요 비즈니스 동인으로 삼았다. 그와 IT 리더 팀은 매월 직원 설문 조사를 사용하여 원격 작업을 용이하게 하기 위한 웹 인터페이스 및 모바일 앱의 품질과 같은 기능 개발의 성공 여부를 측정한다. 그들은 시스코 통합 커뮤니케이션 매니저와 웨백스 연락센터를 사용하여 서비스 요청 및 문제 해결을 위한 호출 대열을 관리한다.

ITSM에 자금을 지원해야 하는 최고위 경영진에게 직원 경험에 대한 이러한 집중은 “매우 매력적”이라고 포레스터의 분석가인 윌 맥키온-화이트는 말했다.

소통 실패
불분명한 의사소통은 비즈니스에 ITSM의 가치를 설명하고, ITSM 노력을 적절히 조직하며, 구축에 대한 기대치를 설정하고, ITSM에 대한 적절한 자금을 확보하는 것을 훨씬 더 어렵게 만든다.

IT 구성 요소를 비즈니스 애플리케이션에 매핑하고, 이러한 애플리케이션의 소유권을 IT 및 비즈니스 스폰서에게 할당하고, 이러한 스폰서에게 비즈니스에 대한 각 애플리케이션의 역할뿐만 아니라 최적의 사용 방법과 최종적으로 교체 시기를 설명하도록 요청하는데 CMDB를 사용할 것을 호르트키에르는 권고했다.

장례용품 및 서비스 제공업체인 서비스 인터내셔널의 통신 및 IT 지원 담당 이사인 토마스 스미스는 일정에 대해 솔직할 것을 권장한다. 

그는 “우리가 과거에 저질렀고 지금도 저지르고 있는 큰 실수 중 하나는 ‘우리는 3개월 안에 그것을 완성할 것이다’라고 말하는 것이다”라고 마했다. 그는 ITSM 툴이나 서비스의 결함을 이해하고 “비즈니스 프로세스 소유자에게 ‘우리는 이를 해결할 계획이 있다’고 말할 것”을 권장했다.

BMC의 헬릭스 ITSM 플랫폼을 사용하여 생성한 것과 같은 SLA 조건이 “모든 것은 가능한 한 빨리 해결되어야 한다고 생각하는” 사용자의 기대치를 설정하고 불만을 줄이는 데 도움이 될 수 있다고 칼보는 전했다.

또한 명확한 커뮤니케이션을 통해 비즈니스 소유자들은 커스터마이제이션이 유지 보수의 골칫거리가 되는 시기에 대해 합의하는 데 도움이 될 수 있다고 맥키온-화이트는 말했다. 그는 “모두가 자신들이 이해하는 방식으로 조직의 요구를 충족시키려고 노력하고 있다. 그러나 그것들은 고객 결과, 리스크 관리 감소 등과 같은 문제에 맞춰 조정되지 않을 수 있다”라고 말했다.

그가 사용한 이반티 뉴런(Ivanti Neurons)과 같은 ITSM 지원 툴에서 사용자가 필요로 하는 것을 구체적으로 정의하는 것도 필요하다고 스미스는 말했다. 

예를 들어, “사용자가 W-9 형태, 웹 상의 이점 인터페이스에서 보고 있는 것, 또는 ‘화면이 계속 충돌한다’는 것이 무엇을 의미하는지”등이 포함될 수 있다고 그는 전했다. 

그에 따르면 HR 인력은 사고와 서비스 요청 간의 차이를 이해하지 못할 수 있다. 이로 인해 그러한 요구사항을 확정하기 어려울 수 있다. 그는 IT 및 비즈니스 사용자와 상의하여 용어와 정의를 공유함으로써 모든 사람이 각 요구사항이 의미하는 바를 이해하고 우선순위에 동의하도록 하라고 조언했다.

과도한 커스터마이제이션
맥키온-화이트는 과도한 맞춤화가 ITSM 프로젝트에서 겪는 큰 문제 중 하나라고 진단했다. 고객들이 ‘정당하다고 생각하는 이유로’ ITSM 시스템을 수정한다. 시스템이 더 많이 변경되고 이러한 변경을 수행한 직원들이 시간이 지남에 따라 회사를 떠나면서, “변경사항의 내용과 이유를 재구성할 수 없어 ITSM 시스템의 관리 및 업그레이드가 더 어려워진다. 

“문제는 맞춤화 되는 각각의 개별 기능이 아니라 그 모든 맞춤화가 함께 작동하는 방식이다”라고 그는 말했다. ITSM 플랫폼의 구성 요소 간 상호 작용 횟수와 복잡성 때문에 한 가지를 건드리면 다른 것이 망가지기 때문이다. 

바하두는 동의하면서 압력을 견뎌낼 것을 권고한다. “언젠가는 처리할 수 있는 예외 사항이 더 많아지고 툴이 너무 맞춤화 되어 유지 관리가 어려워진다는 사실을 깨닫게 될 것이다”라고 그는 말했다.

메히아는 ITIL&ITSM 툴을 만든 사람들이 ‘전문가’이기 때문에 “많은 맞춤형을 수행하는 대신 가능한 한 많은 워크플로우를 독창적으로 사용하고 프로세스와 워크플로우를 변경하고자 한다”라고 말했다. 

실시 후 망각
ITSM은 시한부 프로젝트로는 완전히 구현될 수 없다고 매트체트는 강조했다. 지속적인 관리 및 교육을 제공하지 못하면 특히 비즈니스 요구사항과 ITSM 툴 자체가 변화함에 따라 ITSM의 효율성이 저하될 수 있다.

대부분의 ITSM 툴은 서비스형 소프트웨어(SaaS)로 제공되는데, 이는 고객이 아닌 소프트웨어 공급자가 기본 인프라를 유지한다는 의미다. 맥키온-화이트는 “고객이 고객 서비스, 탄력성 향상, 변경 리스크 감소, 더 나은 사고 관리 프로세스, 문제 해결에 도움이 되는 모든 사람이 올바른 정보를 얻고 진행 중인 작업 상태를 이해할 수 있도록 한두 명이 진행 중인 최적화를 수행할 수 있도록 계획해야 한다”라고 말했다.

호르트키에르는 ITSM이 특히 더 발전된 플랫폼으로 이동할 때, 새로운 프로세스에서 사용자들을 위한 지속적인 교육이 필요하다고 강조했다. 그는 “대시보드, 보고서, 단축키에 이르기까지 ITSM이 일상 업무에 적용할 수 있는 멋진 기능, 화려한 기능, 비즈니스 효과를 알려야 한다. ITSM 화면을 설정할 수 있는 여러 방식으로 생산성을 높이고 일상 업무에 도움을 줄 수 있다”라고 그는 말했다.

수많은 IT 이니셔티브와 마찬가지로 서비스 관리는 비즈니스 요구를 중심으로 설계될 때 그 가치가 명확하게 전달되며, 장기적인 숨겨진 기술 부채가 발생하지 않는다.

dl-ciokorea@foundryco.com