ITSM 솔루션 ‘고객 맞춤형 서비스’

시작은 누구에게나 잊지 못할 순간이 된다. 하지만 그만큼 잘 잊혀지는 것 또한 시작의 순간일 것이다.
ITSM의 첫 프로젝트를 마친 소감을 나와 같이 ITSM을 처음 접한 입문자들에게공유하고 싶어 이 글을 쓰고자 한다.

ITSM을 처음 접한 순간 IT업계에서 일하는 사람이라면 누구나 한번쯤 ITSM(IT Service Management, IT 서비스 관리)을 접하게 될 것이다. 현재 에스티이지(STEG) 회사에서 재직 중인 필자도 K사와의 금융 프로젝트 중 E-GENE ITSM Solution을 처음 접하게 되었다. 프로젝트 과정에서 ITIL(IT Infrastructure Library, 정보기술 인프라 라이브러리) V3를 기반으로 ITSM을 구축하였는데, 당시 중점적으로 다루었던 ‘장애 관리’와 ‘문제 관리’ 프로세스에 관해 설명하고자 한다.

장애·문제 관리 프로세스의 이해 장애·문제 관리 프로세스란 무엇일까? ITIL V3의 표준 관점에서, 장애는 ‘정보 기술 운영 서비스에 영향을 주는 예상치 못한 사건’이라고 정의되고, 문제는 ‘단순한 사고가 원인이 되어 발생하지만, 근본 원인을 파악 할 수 없는 사건’이라고 정의된다. 즉, 해결 방안을 알고 있으면 ‘장애’, 해결 방안을 찾아야 한다면 ‘문제’로 쉽게 구분할 수 있다.

장애·문제 체계 고도화 3대 핵심 전략

고객 중심의 장애·문제 관리 구현 필자와 K사와의 금융 프로젝트 중, K사는 ‘협업중심의 맞춤형 개선 및 장애 분석’, ‘장애 예방 기능 강화’, ‘문제·구성 관리 연동을 통한 장애 관리와 문제 관리 효율성 증대’를 요구하였다. 이에 맞추어 필자가 구현한 장애·문제 관리 프로세스의 핵심 기능은 다음과 같다.

● 장애·문제 관리 프로세스 표준화
● 장애 등급 자동화
● 장애 전파
● 타 시스템 연계SR등록
● 장애 처리 소요시간 로직화
● 장애·문제 관리 작업 지시
● 장애 보고서 기능 심화
● 장애·문제 관리 연계 처리

ITSM의 기본적인 기능인 듯 보이지만, 기존 ITSM 프로세스와 엄연히 다르다.
무엇이 다른가? 그 답은 ‘장애 관리’와 ‘문제 관리’ 프로세스로 나누어 설명하도록 하겠다.

장애 관리 프로세스 장애 관리 프로세스는 크게 다음과 같은 4단계로 진행된다.
장애 등록 – 장애 접수 및 전파 – 장애 처리 – 장애 종결

<1단계: 장애 등록>
고객으로부터 장애가 등록되면, 정의된 업무 시스템(CI 구성 항목)에 따라 CI별 처리 담당자들에게 장애 SR이 자동 할당 되도록 구현하였다.

<2단계: 장애 접수 및 전파>
이 단계는 필자가 K사와 작업할 당시, 타 장애 프로세스와 가장 구별된 부분이다.
K사는 장애의 범위를 ‘서비스 중지’뿐만 아니라 ‘어플리케이션(업무시스템) 오류로 인한 서비스 장애’도 포함하도록 넓힌 관리를 요구했기 때문이다. 따라서 필자는 긴급도와 영향도 구분에 따라 장애 등급을 자동으로 산출하는 기능과, 고객이 직접 선택한 어플리케이션에 의해 장애 영향도가 자동적으로 부여 될 수 있는 기능을 구현하였다. 또한 장애 발생 내역을 고객에게 실시간으로 공유하기 위해 어플리케이션(업무시스템)에 따른 담당자, 팀장, 부서장 등을 전파 그룹으로 세팅하고 사용자를 추가 및 삭제 할 수 있는 기능도 추가하였다.

<3단계: 장애 처리>
필자는 이 단계에서 장애 원인을 빠르게 파악하고 장애 처리를 신속하게 진행하는 것에 초점을 맞추었고, 이에 기존과 다른 체계 3가지를 구축할 수 있었다.
첫째, K사는 ‘장애 관리’ 프로세스와 ‘변경 관리’ 프로세스의 독립적인 처리가 가능한 체계를 요구하였다. 일반적인 시스템은 두 프로세스가 연관되어 있는데, 이는 비교적 빠르게 처리되어야 하는 ‘장애 관리’ 프로세스의 처리 소요시간을 불필요하게 길게 하여 불편하다는 의견이었다.
이에 필자는 장애 처리 시 장애 원인 해결에 프로그램·데이터 변경이 필요할 경우, 하위 프로세스를 두어 이관 처리하는 구조를 ‘장애 관리’ 프로세스와 ‘변경 관리’ 프로세스가 독립적으로 종결될 수 있는 체제로 구축하였다. 두 프로세스가 연관은 되어 있지만 각자 따로 처리가 가능하게 함으로써 장애를 보다 빠르게 전파하고 처리하는 것이 가능해 질 수 있었다.

둘째, SLA 지표 관리에서 장애 적기 처리율을 산출하기 위해 사용되는 장애 처리 소요시간은 일반적으로 ‘분’으로 표시된다. 예를 들어 1시간이 걸렸다면 60분, 8시간이 걸렸다면 480분으로 표시된다. 하지만 만약 1880분이라는 비교적 큰 수로 표시된다면 고객이 그 단위를 ‘시간’ 단위로 다시 환산하기까지 다소 시간이 소요될 것이다. 이를 위해 실질적인 데이터는 추후 계산 산출을 위해 수정하지 않지만, 고객이 보는 UI 화면에서는 일, 시간, 분 단위로 쉽게 시간을 파악할 수 있는 체제를 구축하여 고객의 만족을 이끌어 냈다. (예를 들어, 1880분은 1일 7시간 20분으로 표시된다.)

셋째, 장애 담당자의 1차 해결이 안 될 경우 2선 장애 처리자에게 작업을 할당하는 작업 지시 방식으로 ‘장애 관리의 세분화’를 구현했다.

<4단계: 장애 종결>
필자는 장애 종결 단계에서 고객의 니즈를 충족시키고, 불필요한 업무를 줄이는 것에 집중하였다. 장애 보고서에 장애 등록·접수부터 장애 처리, 종결까지의 기본 정보와 상세 조치 내역 및 결과를 포함하고, 자세한 처리 내역은 Time Chart형식으로 기록되도록 구현하였다. 또한 향후 조치 계획 및 재발 방지 대책 내용을 입력 필드만 제공하는 것이 아니라 장애 유형에 따른 타 시스템과 연계 할 수 있도록 구현하여 지속적인 장애 예방 및 개선 체계를 수립할 수 있도록 하고, 장애 종료 후 장애 보고서를 인쇄 할 수 있도록 구현하여 고객이 별도의 문서로 보고서를 재작성하는 수고를 줄였다.

문제 관리 프로세스 문제 프로세스는 크게 다음과 같은 5단계로 진행된다.
문제 등록 – 해결 방안 도출 – 해결 방안 실행 – 결과 확인 – 문제 종료

TIL V3의 표준 관점에서, 장애 관리와 문제 관리는 연동하여 관리되어야 한다. 따라서 장애 관리 시스템 내에서 해결하지 못한 장애건에 관하여 문제 관리 프로세스로 전환하고, 문제 해결 후 해결한 사항을 KMDB(지식 관리)로 등록하여 앞으로의 문제를 관리하게 된다.
문제 관리의 핵심 기능은 장애 관리와 동일한 형태로 구현되어 따로 설명하진 않겠다.

핵심적인 성공 요인은 무엇일까? ITIL은 프레임워크일 뿐, 고객 맞춤형 솔루션은 아니다. STEG 솔루션 서비스 본부 CS팀 민창선 수석은 “ITIL은 조직이 준수하는 것이 아닌 준용하는 프레임워크로써, ITIL V3를 바탕으로 하는 ITSM의 구현은 각각의 조직 현황에 적합한 통합적인 프로세스 접근 방법을 바탕으로 이를 현실화 시킬 수 있는 유연한 ITSM 솔루션의 지원으로 이루어져야 한다.”고 하였다.
실제로 필자는 STEG에서 자체적으로 보유하고 있는 E-GENE 솔루션군의 핵심 기술인 Workflow engine을 이용함과 동시에 고객의 니즈를 파악하여 ‘고객 맞춤 프로세스’를 제공할 수 있었다.

마무리하며… 모든 기업이 자신만의 ITSM을 가지고 있듯이 필자의 회사에선 E-GENE 5.2버전 솔루션을 업그레이드 중에 있고, None-Project 기반으로 SMB 시장에 최적화된 STEG E-GENE™ ITSM 솔루션인‘E-GENE™ Lightning’을 구축 중에 있다. 사용자들이 간단한 설정을 통해 사용 가능한 Out of The Box 형태의 솔루션이다. STEG는 ‘서비스 기술의 살아있는 진화 유전자’를 모토로 기업의 지속적인 경쟁력을 높이기 위해, 보다 확실한 솔루션을 기업에게 제공하기 위해 노력 중이다. 필자 또한 이 첫 경험을 모티브로 생각을 더욱 구체화시켜 끊임없이 연구한다면 기업에게 탁월한 서비스를 제공할 수 있다고 확신한다.

– R&D본부 솔루션 개발팀 이소영 전임 –

---

◈ 에스티이지 구축사례 바로가기