직무의 모든 측면이 변화했다. 이제는 성과 지표도 바뀔 때다. 여기 디지털 시대에 IT의 비즈니스 가치를 입증하는 방법을 정리했다.
통신 네트워킹 기업 시에나(Ciena)의 CIO 크레이그 윌리엄스는 2019년 회사의 경영진이 IT팀을 어떻게 평가할지 정확히 알고 있다. 그들은 인재 관리(공석 확충까지의 소요 기간, 리더십 개발 수료 직원 수 등), 수익 참여(IT 직원당 매출), 변화 관리(새로운 소셜 미디어, 데이터, 협업 툴 도입율) 등과 같은 각종 지표를 살펴볼 것이다.
과거와 크게 달라진 지표들이다. 윌리엄스는 “과거 IT는 주로 업타임(Uptime)과 SLA(Service Level Agreement) 충족 등을 기준으로 평가됐다”라고 말했다. 지금 지금껏 IT는 99.999% 가용성을 목표로 삼고 해결된 티켓의 수에 대한 목표를 가지곤 했다.
윌리엄스는 지금도 이런 지표를 유지하고 있지만 “핵심 요구는 이제 가치, 비즈니스 지원, 수익 기여 이익 쪽으로 바뀌었다”라고 말했다.
2017년 900명의 IT 리더를 대상으로 통합 통신 기업 퓨즈(Fuze)가 실시한 설문조사에서 3/4 이상이 IT가 비즈니스 성공을 유도하고 IT의 혁신 능력이 비즈니스에 필수적이라고 생각한다고 답했다.
하지만 응답자 대부분은 비즈니스 책임자들이 비용 절감에 집착한다고 생각했으며 49%는 IT 부서의 성공이 제대로 측정되지 않았다고 밝혔다. “설문조사 결과 IT 전문가들은 혁신과 변화에 대한 능력을 평가 받는 것에 대해 꽤 관심이 있었다”라고 퓨즈의 CIO 크리스 콘리가 말했다.
분명 IT 리더들은 비즈니스 리더의 파트너로서 자리잡고 싶어하며 조직을 디지털 미래로 안내할 준비가 되어 있다. 그렇다면 아직도 임원진의 눈길을 끌지 못하는 구식 지표로 자신의 성공을 측정하는 사람이 많은 이유는 무엇일까?
KPI(Key Performance Indicator)를 비즈니스 목표나 결과에 연계시킬 수 없다면, 진정한 가치를 제공하지 못하는 “무의미한 지표”라고 디지털 경험 모니터링 기업 캐치포인트(Catchpoint)의 이사 던 파지흐가 말했다.
IT 리더가 측정을 멈추거나 최소한 비즈니스 담당자에게 더 이상 이야기하지 말아야 할 KPI는 무엇이 있을까? 그 예와 함께 대안을 살펴본다.
업타임(Uptime)
“100%에 가까운 업타임은 더 이상 성공의 표시가 아니다. 당연한 것이다”라고 일리노이의 네이퍼빌(Naperville, Illinois)에 위치한 의료 IT 컨설팅 기업 IA(Impact Advisors)의 부사장 아담 탤링어가 말했다.
그는 이어 “수도꼭지에서 물이 나올 때마다 배관공을 응원할 필요는 없다. 수도꼭지를 돌렸는데 물이 나오지 않으면 문제가 있는 것이다”라고 덧붙였다.
여러 KPI와 마찬가지로 업타임 자체만 보게 되면 오해할 수 있다. 예를 들어, 가상화된 소프트웨어 계층이 포함된 시스템이 있다. 네트워크는 제대로 기능할 수 있지만 그런 가상화 계층이 제대로 작동하지 않으면 사용자는 여전히 필요한 앱에 액세스할 수 없다. “이것을 업타임이라고 부른다면 거짓말이다”라고 그가 말했다.
파지흐도 동의했다. 업타임이 유용할 수는 있지만 비즈니스 결과와 직접 연계되었을 경우에만 그렇다는 설명이다. “가용성도 중요하지만 SLA에 어떤 영향을 끼치는지도 중요하다. 고객들과 사이트의 99.99% 가용성에 대해 계약하는 경우 비즈니스 리더는 해당 SLA의 맥락에서 가용성을 고려할 것이다”라고 그녀는 말했다.
심지어 SLA가 없더라도 웹사이트 다운타임(Downtime)은 고객 만족도에 큰 영향을 끼칠 수 있으며, 사이버 먼데이(Cyber Monday)에 사이트가 다운되는 경우에는 더욱 그럴 것이라고 파지흐는 덧붙였다.
단 비즈니스 담당자와 이런 정보를 공유하지 않더라도 업타임은 IT가 주된 의무를 충족하기 위해 수집해야 하는 기본적인 지표 중 하나라고 오라일리 미디어(O’Reilly Media)의 수석 데이터 사이언티스트 벤 로리카가 말했다.
그는 “서비스를 항상 유지되어야 한다. 확인목록을 통해 유용하지 않은 KPI를 제외할 수는 있지만 상황 유지를 위해 추적해야 하는 지표의 기준이 있다”라고 말했다.
MTTR(Mean Time To Repair)
MTTR은 오해의 소지가 있는 지표이다. 특히 IT 직원이 이를 이용해 자신의 성과가 평가된다는 사실을 알고 있을 때는 더욱 그렇다.
파지흐는 “보상과 연결되는 경우 왜곡의 소지가 있다. 티켓을 완전히 해결하기 전에 종료되기도 한다. 그렇게 되면 나중에 새로운 티켓이 열린다. 다양한 방식으로 조작이 가능하다. MTTR은 분명 추적해야 할 매우 중요한 지표이지만 정확히 추적해야 한다. 다른 지표와 어떻게 연계되어 있는지 자문해 보아야 한다”라고 말했다.
의도적인 조작이 없더라도 MTTR은 여러 요소를 고려하지 못하기 때문에 그다지 유용하지 않을 수 있다고 탤링어가 말했다. “심지어 다운타임이 없는 고장 해결 문제에도 MTTR을 사용할 수 있다. 아니면 부서 또는 기업 전체가 아니라 한 사용자에게만 영향을 끼치고 있을 수 있다. 그 문제가 얼마나 중요한지는 그리 감안되지 않는다”라고 말했다.
게다가 그는 해결 시간 제대로 된 지표가 아닌 경우가 많다며 “몇 초 만에 해결되는 문제도, 몇 개월이 걸리는 문제도 있다. 만족스러운 해결이 있고 미봉책일 수도 있다. 해결 시간 만으로는 측정되지 않는 변인들이다”라고 설명했다.
최초 호출 해결(First call resolution)
이 또한 단순히 적용하기에는 몹시 불확실한 KPI라고 탤링어가 말했다. “문제에 따라 크게 좌우된다. 누군가 비밀번호를 잊어버리는 경우 최초 호출 해결 비율은 매우 높겠지만 2차 또는 3차 지원으로 적절히 전달되는 문제의 경우에는 그렇지 않을 것이다”라고 그는 말했다.
예를 들어, 온라인 저장소 기업 박스(Box)는 최근 잊어버린 비밀번호를 처리하는 방식을 바꾸었다. 예전에는 잘못된 비밀번호를 3회 입력하면 직원의 계정이 한 시간 동안 잠겼었다. 하지만 박스의 IT팀은 최근 휴대폰을 이용한 이중 인증을 이용하여 스스로의 계정을 잠금 해제하는 툴을 배치했다. 이런 단순한 변화로 매월 약 2,000건의 업무 지원 센터 호출이 사라졌다.
박스 IT 팀의 이 시도는 사용자 경험을 개선했으며 반복적인 작업을 없애 IT 작업의 지루함을 달래 주었고 IT 프로젝트를 위한 자원을 확보했다. 하지만 박스가 최초 호출 해결을 KPI로 측정했다면 이 변화로 인해 백분율이 크게 저하되었을 가능성이 높다.
예산 및 일정 준수
많은 IT 조직들이 프로젝트의 예산 및 일정 준수로 성공을 측정한다. 문제는 이것이 본래 설정된 파라미터에 대해 IT의 성과를 측정할 뿐 완료된 프로젝트로 비즈니스적 수익이 발생했는지 여부에 대해서는 알 수 없다는 점이다.
캘리포니아의 알리소 비에호(Aliso Viejo)에 위치한 CMH(Carrington Mortgage Holdings)의 CIO 브렌트 라스무센은 “프로젝트가 제대로 도입되고 비즈니스 프로세스가 바뀌며 측정 가능하고 투명해지기 전까지는 비즈니스 부문이 수익을 얻지 못한다”라고 말했다.
즉 일반적으로 업타임 등 예산을 준수하는 것은 오늘날의 IT 부문에서 ‘탁상 행정’에 불과하다고 그는 강조했다.
대안 KPI
상기 KPI가 더 이상 IT의 성공을 입증하지 못한다면 IT 리더는 무엇을 측정해야 할까? 그 답은 특정 조직에 무엇이 중요한지에 따라 다르며, 이는 기업마다 다를 뿐 아니라 같은 기업에서도 시간에 따라 달라진다. 한 해는 급격한 확장이 주된 목표였다가 다음 해에는 수익 극대화가 가장 큰 목표이고 그 다음 해에는 오래가는 브랜드 구축이 목표가 될 수 있다. IT가 측정해야 하는 KPI를 제대로 판단하는 유일한 방법은 비즈니스 리더와 사용자들에게 무엇이 중요한지 파악하는 것이다.
비즈니스에 무엇이 필요한지 파악하는 방법에 대한 전문가의 조언을 들어보자.
상담부터 시작하라
비즈니스 리더들에게 중요할 가능성이 매우 높은 사용자 만족도를 측정하고 싶다면 모두에게 설문조사를 발송하거나 지원을 요청한 사용자에게 후속 설문조사를 발송하고 싶을 것이다. 하지만 적절한 준비가 없다면 실수를 할 수 있다고 탤링어가 말했다.
그는 “갑자기 설문조사를 발송해서는 안 된다. 데이터가 너무 많고 특정 시점에 연락하는 사람들에게 변동성이 너무 크다. 부서 또는 조직 리더와 함께 관계 구축에 좀 더 초점을 둘 것이며 ‘앞으로 우리는 이렇게 측정할 것이다’라고 말하면서 피드백을 요청하는 것이 좋다. 이런 관계를 형성한 후에 설문조사를 이용할 수 있다”라고 말했다.
계속해서 이유를 찾으라
“가장 큰 문제는 비즈니스 리더가 IT 조직에게 자신의 목표와 목적을 밝히지 않을 때 발생한다.”고 파지흐가 말했다. 예를 들어, 비즈니스 리더는 단순히 IT에 외부 고객을 위한 사용자 경험을 개선해야 한다고 말할 수 있다. 그 이유는 해당 기업이 고객층을 키우려 시도하고 있으며 불만족한 고객들이 떠나면서 천(Churn)이 발생할 수 있기 때문이다. 이 때문에 고객 경험을 중시하는 것이지만 이런 이유를 IT와 항상 공유하지는 않는다.
따라서 좀 더 자세히 살펴보아야 한다. 파지흐는 “중요한 이유가 무엇인지 물어보라 첫 번째 답변이 실제 비즈니스 이유가 아닐 수도 있기 때문에 여러 번 질문해야 할 수도 있다.
‘가용성이 중요해? 왜?’
‘사용자들이 더 만족하니까.’
‘그게 그 비즈니스와 무슨 상관이 있는데?’
‘더 만족하면 사이트에서 더 많은 시간을 보내고 더 많이 구매하잖아.'”
이렇게 답을 찾으면 비즈니스 목표를 달성하는 더 좋은 방법이 있을 수도 있기 때문에 정말로 유용할 수 있다고 그녀가 설명했다. 예를 들어, 99.999%를 추구하는 대신에 고객들의 관심을 끌 만한 기능을 추가하는 것이 더 나을 수도 있다. “가용성에 집중하고 고객들이 원하는 기능을 구축하지 않으면 이를 놓칠 수 있다”라고 그녀가 말했다.
지표를 구체적인 비즈니스 결과와 연계시키고 결과를 달성했는지 확인하라
라스무센은 매년 모든 부서의 리더들과 함께 1:1로 IT가 진행할 프로젝트와 IT가 각각에 소요할 시간과 자원에 관해 결정한다. 또한 해당 프로젝트로 예상되는 비즈니스 이익에 대해 합의한다.
그리고 나면 라스무센과 그의 팀이 실제로 해당 프로젝트에 소요된 시간과 자원을 추적하여 계획된 예산을 준수했는지 파악한다. 하지만 그것이 전부가 아니다. 또한 원하는 비즈니스 결과를 달성했는지도 판단한다.
그는 “프로젝트 전에 먼저 벤치마크를 하기 때문에 측정할 수 있는 것을 먼저 측정한다”라며, 예를 들어, 마케팅 프로젝트의 경우 리드 제너레이션, 접촉, 확인한 이메일, 현재 프로모션 발송 능력 등을 측정할 수 있다고 전했다.
라스무센은 “그리고 나서 그 효과를 파악하기 위해 해당 기준에 맞추어 새로운 솔루션을 살펴본다”라고 설명했다.
그와 그의 직원들은 이 과정을 TOFU(Take Ownership and Follow Up)라 부른다. 이 과정은 IT의 모든 프로젝트에 적용된다. 준수성 프로젝트의 경우 사고 수를 측정한다. 직원들의 작업 부하를 줄이기 위한 로봇 공정 자동화 프로젝트의 경우 워크로드 수치가 반영되기를 바란다.
그는 “해당 년도에 10명에 대한 예산을 요청할 것으로 예상했지만 실제로는 8명일 수 있다. 비즈니스에서 더 많은 부분을 담당하든지 사람들이 해고 또는 재배치된 것이다. 해당 작업에서 절감된 부분을 측정할 수 있어야 한다.” 그렇지 않으면 “무형의 것들이 너무 많아진다”라고 말했다.
따라서 추적할 적절한 지표를 찾는 것이 중요하다. 하지만 지표만으로는 IT의 성과에 대한 전체적인 그림을 완전히 파악할 수 없다는 사실을 기억해야 한다. 윌리엄스는 이렇게 말했다.
“KPI는 바람이 부는 방향을 알려주지만 오늘이나 내일의 일기예보까지 제공하는 것은 아니다. 중요한 KPI에 대한 대화다.”dl-ciokorea@foundryco.com
