최영석BSI코리아 심사위원 YoungSug.Choi@bsigroup.com
2009.07.17 / AM 09:38최영석
[지디넷코리아]국내 IT조직들을 관찰하면서 꼭 다루고 싶었던 문제점들 중에 하나가 ‘사용자 통지’에 대한 것들이다. 사용자 통지를 단순히 IT조직의 ‘친절함’을 사용자들에게 과시하는 정도로만 이해하고 있는 IT조직들이 아직도 많다.
통지를 제때 받지 못하거나, 전달에 실패하는 경우, 사용자들은 IT를 이용해서 본인의 업무를 처리하는 데 큰 불편을 겪거나, 불필요한 시간을 허비하게 된다. IT를 비즈니스와 연결시키는 큰 그림도 중요하지만, 실제 비즈니스 활동을 수행하는 사용자들이 IT를 사용함에 있어 겪는 불편함을 최소화하는 것도 중요하다는 것을 강조하고 싶다.
통지 시점, 통지 내용, 통지 대상자 및 통지 방법 등의 통지 활동 전반에 산재해 있는 문제들로 인해 사용자들을 지속적으로 소외(?)시키거나, 불만을 제기하게 만들고 있는 일부 IT조직에 대해 알아보자.
지면상 2회로 나누어서 다루어 보겠다.
■통지란 무엇인가?
통지(Notification)는 필요한 사람들에게 적절한 시기에 약속된 방법으로 정보를 알려주는 활동이다.
서비스 분야에서는 주로 접수 여부와 처리 결과를 알려주는 활동을 얘기하지만, IT분야에서는 장애와 변경과 같은 사건들이 발생하는 경우에도 통지가 일어나게 되므로, 일반적인 서비스 분야보다는 좀더 넓고 복잡하다고 할 수 있다.
통지는 발생하는 동기에 따라서 수동적인(Reactive) 통지와 적극적인(Proactive) 통지로 나누어 볼 수 있다.
수동적인 통지는 사용자의 요청이나 장애가 발생한 이후에 확인(confirmation)이나 정보공유의 목적으로 정보를 사용자에게 전달하는 것을 의미한다. 적극적인 통지는 사용자의 요청이나 장애가 발생하지 않았더라도, 사용자에 영향을 주는 사건이 발생했거나 발생할 것으로 예측되는 경우, 사용자들에게 미리 정보를 알려주는 적극적인 활동이다.
IT를 둘러싸고 발생하는 ‘사건’에 따라서는 ‘사용자 요청’에 대한 통지와 ‘변경 및 장애’에 대한 통지로도 나누어 볼 수 있다. ‘사용자 요청’에 대한 통지는 사용자에게 접수 확인, 진행 상태 및 이슈사항에 관련된 정보를 전달하는 것을 의미한다.
‘변경 및 장애’에 대한 통지의 경우는 사용자들에게 변경과 장애의 발생 사실, 진행 상태 및 이슈사항에 관련된 정보를 전달하는 활동으로 볼 수 있겠다.
■‘확인’ 통지가 부실한 경우
수동적인 통지이면서 사용자 요청에 관련된 ‘확인(confirmation)’ 통지는 가장 기본적인 통지 활동이라고 볼 수 있다. 패밀리레스토랑에 가서 주문을 할 때, 또는 계산할 때 우리는 ‘확인’ 통지를 경험한다. 주문한 내용을 접수하는 종업원이 주문내용을 ‘다시 한번’ 불러주거나, 계산 시 현금을 받은 경우 얼마를 받았다라고 굳이(!) 알려준다.
이렇게 귀찮을 정도로 확인을 해주는 이유는 무엇일까?
‘확인’ 통지는 요청자가 본인이 요청한 내용이 접수되었는지를 확신하게 해주는 좋은 실행사례 중의 하나다. 식당에서 추가적인 주문을 했을 때 종업원의 ‘확인’ 통지가 없는 경우, 계속 기다려야 하는 지 아니면, 다시 한번 외쳐야(!)하는지 고민한 경험을 떠올려 보면 이해를 할 수 있다.
‘확인’ 통지와 관련하여 국내IT조직의 현실을 살펴보자. 우선 사용자 요청을 전문적으로 처리하는 ‘서비스데스크(Service desk)’의 유무에 따라 ‘확인’ 통지의 적용 여부가 극명하게 갈린다.
서비스데스크가 없는 IT조직의 경우, 통지 활동 전반이 불규칙적이다. 이들 조직은 사용자의 요청을 접수하는 IT담당자가 ‘개발자’나 ‘운영자’와 같은 엔지니어인 경우가 대부분이고, 사용자 요청을 접수하고 통지하는 활동들을 대부분 ‘구두’로 처리하고 있다.
국내정서로 볼 때, IT엔지니어가 사용자 요청에 대해 친절하게 확인을 해주는 모습은 여전히 어색하며, 구두로 처리되는 접수 및 통지 활동은 IT담당자의 기억력이나 꼼꼼함에 의존할 수 밖에 없다.
서비스데스크가 있는 IT조직도 ‘확인’ 통지가 원활하지 않는 경우가 있다. 이들 조직의 대부분은 사용자 요청의 전 과정을 IT시스템으로 관리하고 있다. 하지만 일부 IT조직들은 IT시스템에는 ‘확인’ 통지 기능이 없거나, 있어도 사용하지 않고 있다는 사실을 발견하게 된다. 그 이유를 살펴보면, ‘확인’ 통지의 필요성을 이해하지 못하거나, ‘그런 것까지, 왜?’라는 다소 시니컬한 인식이 깔려있다는 것을 느끼게 한다.
■사용자 문의와 통지 관련 사례
사용자 문의에 대한 IT조직의 ‘통지’ 활동이 실제 어떻게 일어나고 있고 문제점이 무엇인지를 간단한 사례를 통해 알아보자. 한 사용자가 IT조직으로 전화를 했다. 본인이 사용하는 응용시스템에서 특정 값을 입력하면 에러가 발생한다고 한다. 입력기능이 처리가 되어야만 자신의 업무가 종료된다는 말을 덧붙였다.
접수한 IT직원은 사용자에게 접수내역에 대한 ‘확인’통지를 하고 IT조직의 내부의 개발자에게 문의한 결과 임시로 처리할 수 있는 방법을 알아냈으며, 이 문제를 근본적으로 해결하기 위해서는 응용시스템의 수정이 필요하다는 것을 확인했다.
IT직원은 임시로 처리할 수 있는 방법과 향후 응용시스템에 대한 수정될 것이라는 사실을 사용자에게 통지한 후, 요청 건을 종료 처리하였다.
1주일 후 동일한 사용자로부터 또 전화가 왔다. 언제까지 임시 처리 방법으로 사용해야 하는 지를 문의하였다. 상담원은 다시 개발자에게 확인하였고, 이미 응용시스템의 수정이 이틀 전에 완료되었다는 사실을 알게 되었고 정상적인 방법으로 응용시스템을 사용하면 된다는 내용으로 사용자에게 ‘통지’하였다.
■통지의 ‘연속성’ 문제
위의 사례에서, IT직원은 기본적인 ‘확인’ 통지와 ‘임시 처리 방법’에 대한 통지를 정상적으로 수행했다. 하지만 사용자가 임시 처리 방법을 언제까지 사용할 것인지, 즉 IT내부적으로 응용시스템의 수정이 완료되는 시점에 대해서는 미리 ‘통지’하지 않았다.
여기에서 통지의 ‘연속성’문제가 발생한다. 통지의 ‘연속성’은 ‘사용자 입장’에서의 궁금함과 불편함이 완전히 종료될 때까지, 필요한 정보를 적절한 시점에 사용자에게 전달하는 것을 의미한다.
위의 사례의 경우, 통지의 연속성을 보장하기 위해서는 ‘확인’통지-> ‘임시처리방법’통지->’문제완전해결’통지까지를 연속적으로 사용자에게 제공하여야 한다. 이 사용자는 언제까지 임시처리방법의 불편함을 감수해야 하는지가 궁금했으나, 이에 대한 IT조직의 통지가 없어서 이틀간의 업무 손해(?)를 떠안은 후에 결국 전화를 하게 된 사례다.
이처럼 사용자입장에서 연속적이지 않는 통지는, 또 다른 불만을 야기하거나, 기존 통지를 위한 IT조직의 ‘노력’을 평가절하시킬 수 있다.
■통지의 연속성을 어떻게 보장할 것인가?
IT내부의 프로세스를 잘 이해하고 있는 사람은 눈치챘겠지만, 위와 같은 통지의 연속성 문제를 해결하기 위해서는, IT 내부적으로 두 가지 문제를 해결해야 한다.
첫째는, 위와 같은 사용자 문의 건은 ‘문제완전해결’통지 전까지는 IT직원이 해당 요청 건을 종료하지 않아야 한다. 접수한 IT직원과 상위 관리자는 항상 ‘열려’있는 상태의 요청 건에 대해서만 관심을 가지고 처리하기 때문이다. 사용자 통지가 원시(!)적인 IT조직의 경우는 ‘확인’통지 이후 사용자 문의 건을 종료시키기도 한다.
둘째는, 사용자 문의 건을 해결하기 위해 응용시스템 수정이 완료되었다는 사실이, 접수한 IT직원에게 적절한 시기와 방법으로 ‘통지’되어야 한다. 이것은 IT조직내의 ‘사용자 요청 프로세스’와 ‘변경 프로세스’간의 인터페이스가 긴밀해야만 가능하다. IT직원을 통해 사용자 요청이 변경프로세스로 전달되고, 사용자 요청을 해결하기 위한 변경이 진행되며, 이 과정에서 변경의 ‘상태’를 포함한 정보가 다시 사용자 요청 프로세스를 거쳐, 최초 접수한 IT직원에게 전달되는 흐름이 일관성 있게 유지되어야 한다.
언급한 사례 이외에도 다양한 통지의 연속성 문제들을 만나게 된다. 이들 사례들을 근본적으로 해결하기 위해서는 IT내부 프로세스를 긴밀하게 가져갈 수 밖에는 없다는 사실을 알아야 한다. 다음 칼럼에서는 ‘통지로부터 ‘소외’되는 사용자’에 대한 이야기를 해 보겠다.
Posted by 홍반장
