전편에 이어 사용자 통지에 대한 얘기를 계속해보겠다.
■통지로부터 ‘소외’되는 사용자들
응용시스템에 친숙해진 사용자 입장에서는, 어느 날 갑자기 바뀐 ‘메뉴’나 ‘사용방법’에 대해서 당황할 수 밖에 없다. 바뀐 응용시스템에서 헤매다가 일부 사용자들은 스스로 바뀐 부분을 찾아내기도 하고, 일부 사용자들은 바뀐 부분을 알아내기 위해 IT조직으로 직접 문의하기도 한다.
이들은 바뀐 응용시스템 정보에 대해 통지 받지 못한 ‘소외된’ 사용자들이다. 하지만, 대부분의 IT조직들은 이러한 사용자 혼란을 방지하기 위해 응용시스템의 변경에 대해서는 사전에 사용자들에게 충분히 통지하고 있다고 주장(?)한다.
그러나 응용시스템의 변경이 발생한 직후, 이들 IT조직이 접수한 사용자 요청이나 불만기록 등을 살펴보면, 위와 같은 불편을 호소하는 사용자들의 ‘불만’ 섞인 문의가 자주 발견된다.
IT조직은 분명히 통지를 했다는 데, 왜 사용자들은 이렇게 불편을 호소하는 걸까? 서로의 진술(?)이 엇갈리는 상황이다. 경험에 따르면, 이런 상황은 IT조직이 알고 있는 ‘통지대상자’가 ‘제한’적이거나, IT조직의 ‘통지방법’이 ‘효과적이지 않은’ 경우가 대부분이다.
■통지방법의 문제점들
상당수의 국내 IT조직은 응용시스템의 메뉴나 사용방법의 변경 내용을 ‘요청자’ 즉, ‘변경을 요청한 사용자’에게만 변경 결과를 ‘직접’ 통지하고 있다. 응용시스템을 사용하는 ‘나머지’ 사용자들에게는 특별한 통지가 없거나, 공용 게시판의 게시물을 활용하여 ‘나머지’ 사용자에게 통지하고 있다.
‘나머지’ 사용자들에게 통지하고 있지 않는 IT조직은 생각보다 많다. 그 이유의 첫 번째는 통지할 이유가 없다는 것이다.
IT조직이 판단하기에 ‘사소’한 응용시스템의 변경이라고 판단하는 경우는 요청자에게만 그 처리 경과와 결과를 통지한다는 것이다. 그러나, 경험에 의하면 이러한 주장을 하는 IT조직은 응용시스템이 ‘사소’한 것인지 아니면 ‘중요’한 것인지에 대한 특별한 기준이 없는 경우가 많다.
개발자나 응용시스템 변경에 관련된 IT담당자의 ‘자의’적인 판단에 의하거나, 단순히 변경의 물리적인 크기에 의해서만 사소한 것과 그렇지 않은 것을 판단하는 것이다.
크기가 작은 변경이라 할지라도, 사용자들의 업무 프로세스에 지장을 초래하는 변경인 경우는 반드시 사용자들에게 이 사실을 통지해주어야 한다. 이것은 사용자 위주의 IT 서비스 마인드의 기본원칙이다.
■공용게시판을 통한 통지방법의 문제
공용게시판을 통해 통지하는 경우는 공용게시판의 ‘활용도’에 따라 사용자 통지의 효과가 좌우된다.
IT관련된 다양한 공지사항을 다루는 공용게시판을 사용자통지의 경로로 활용하는 경우, 사용자들이 얼마나 자주 공용게시판에 접속해서 게시물을 살펴보는지가 사용자 통지 성공의 첫 번째 변수이다.
또 사용자들이 공용게시판에 자주 방문을 하더라도 게시물의 제목에서 직관적으로 사용자 본인의 응용시스템과 관련이 있는 내용인지를 알 수 있어야 한다. 이것이 사용자 통지 성공의 두 번째 변수이다. 하지만 이러한 두 가지 변수들이 성공적으로 IT조직의 사용자통지 목적을 달성하도록 도와주고 있다고 보기에는 어려운 경우들을 많이 발견하게 된다.
사용자 통지의 ‘공간’을 만들어놓고, 사용자통지를 위한 안내 게시물을 올려놓고 있다고 해서 사용자에 대한 의무를 다했다고 주장하는 IT조직을 만나게 된다. 사용자 통지의 ‘실패’를 ‘사용자측의 무관심’이라고 주장하는 것이다. 물론 IT조직의 입장에서는 열심히 통지하고 있는데 사용자들이 관심을 가져주지 않는 부분에 대해서는 IT조직의 억울함에 충분히 공감할 수 있다.
하지만, 열심히 하는 것과 실효성과는 분명하게 구분이 되어야 한다. 그래야만 IT조직 노력을 인정받을 수 있기 때문이다. 사용자들의 주 업무는 IT가 아니기 때문에 IT조직이 마련한 공용게시판의 효과성에 대해서는 항상 스스로 문제 의식을 가질 필요가 있다.
■장애 통지의 문제점들
IT조직은 사용자가 궁금해 하는 내용을 통지해야 한다. 예를 들어 장애가 발생한 경우, 사용자들이 통지 받고 싶어하는 내용은 어떤 것일까? 사용자들이 통지 받고 싶어하는 내용은 장애의 원인이나 내용보다는 당연히 ‘언제 다시 사용할 수 있을까?’이다.
사용자들은 IT를 사용하지 못한다는 현실을 받아들인 이후에는, IT를 사용하지 않는 업무를 먼저 챙기거나, 중단되지 않는 IT를 활용한 업무를 우선 처리하게 된다. 따라서 다시 사용할 수 있는 시간만 알려준다면 장애에 대한 사용자통지는 목적을 달성할 수 있다.
IT조직의 장애 통지의 내용을 들여다보면, 발생한 사실 위주로 구성되어 있으며, 사용자들이 언제 IT를 다시 사용해도 되는지에 대해서는 사전에 또는 진행 중간에 적절하게 통지되는 경우가 드물다. IT의 재개 시간을 어떻게 알 수 있느냐고 반문할 수 있겠지만, 서비스 수준 합의서(SLA)가 존재하는 IT조직의 경우, 대부분 서비스 목표로 IT시스템의 재개 시간(i.e. 장애복구목표시간)을 미리 정해놓고 있다.
최악의 경우라도 IT시스템의 재개시간을 넘기지 않도록 IT조직은 준비하고 있으므로, 장애가 발생하는 경우 약속된 재개 시간을 사용자들에게 미리 알려준다면, 사용자들은 그 시간 동안 다른 업무를 할 수 있도록 배려하게 되는 것이다.
■사용자 통지와 사용자 만족도
통지는 IT의 사용자들의 ‘답답함’을 해결해주고 IT조직과 사용자간의 양방향 커뮤니케이션을 유도하는 시발점이다. 따라서 적절한 타이밍에 적절한 정보를 제공해준다면 IT조직에 대한 만족도를 절대적으로 향상시킬 수 있다. 장애가 발생한 ‘사실’보다는, 그 사실을 ‘제때’ 알려주지 않는데 대한 사용자 분노가 더 크다는 것은 알려진 사실이다.
또, IT조직은 소외된 사용자가 발생하지 않도록 하기 위해서 응용시스템 별 사용자 그룹의 분포를 잘 이해해야 한다.
IT조직들은 대부분의 응용시스템의 사용자 정보를 인사 정보와 연결시켜 놓고 있다. 하지만 인사정보에는 정직원만이 포함되어 있을 뿐, 계약직, 도급 인력 및 파트너 인력들은 인사정보가 명확하지 않는 경우가 있어 여전히 소외된 사용자가 발생할 가능성이 있다.
관련기사
- [칼럼]사용자 통지를 사소하게 다루는 IT조직들-12009.08.07
- [칼럼]‘프로젝트’에서 ‘운영’, 전환과정의 문제점들2009.08.07
- 예스24 또 속였나?..."1차 해킹 때 백업망도 랜섬웨어 감염"2025.08.14
- 삼성·SK, 올 상반기 R&D에 '적극 투자'…AI 시대 준비2025.08.14
또 일부 응용시스템들은 태생의 문제(?)들로 인해 인사정보와는 별개로 사용자정보가 구축되어 있는 경우도 있기 때문에 사용자 그룹의 분포를 일목요연하게 파악하기가 어려울 수 밖에 없다. 가장 좋은 사용자 목록 관리의 이미지는, 사용자통지를 전담하는 IT직원이나 서비스데스크 상담원에게 응용시스템 별로 또는 조직 별로 자유롭게 조회할 수 있는 사용자 목록을 제공하는 것이다.
ITIL 기반의 서비스 관리를 수행하고 있는 IT조직은, 이러한 사용자 목록을 구성정보데이터베이스(CMDB)에 포함되거나 연결되도록 한다면 사용자 통지를 위한 최상의 인프라를 갖출 수 있다고 볼 수 있다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.