이 글의 핵심
- 대시보드가 늘어도 결정이 바뀌지 않는 이유는 데이터 부족이 아닙니다. 지표가 결정 주체, 회의 주기, 임계값, 행동과 연결되어 있지 않아서입니다.
- 연결이 없는 지표는 장식입니다. 관제센터를 운영하면서 확인했더니, 결정에 실제로 쓰이는 지표는 전체 화면에서 일부에 불과했습니다. 나머지는 화면에 있을 뿐 아무도 보지 않았습니다.
- 화면을 내리면 남은 지표에 요구가 붙기 시작합니다. 장식일 때는 아무도 손을 대지 않던 지표가, 결정에 연결되고 나서는 조직이 스스로 다듬었습니다.
대시보드를 새로 들여놓고 나서 결정이 빨라졌다는 조직을 저는 많이 만나지 못했습니다. 화면은 늘었는데 회의에서 꺼내는 숫자는 이전과 같은 경우가 더 흔합니다.
데이터가 부족해서가 아닙니다. 저는 차량 관제센터를 직접 설계하고 운영하면서 이 상황을 먼저 겪었습니다. 수집할 수 있는 항목을 전부 화면에 올렸더니, 화면은 인상적이었는데 결정은 이전과 달라지지 않았습니다. 막힌 곳은 데이터 양이 아니라, 지표와 결정이 연결되지 않아서였습니다.
화면이 늘수록 실제로 보는 화면은 적어졌습니다
관제센터를 처음 구성할 때 저희는 욕심을 부렸습니다. 시스템이 내보내는 항목을 전부 화면에 올렸습니다. 차량별 운행 상태, 실시간 위치, 구간 이력, 일별 집계, 이상 발생 현황까지. 화면 수는 상당했고 완성도 있어 보였습니다.
몇 달 뒤 운영 현황을 점검했습니다. 화면마다 최근 열람 기록을 확인했더니, 실제로 결정에 쓰인 지표는 전체에서 일부뿐이었습니다. 나머지는 화면에 있을 뿐 아무도 보지 않았습니다. 화면을 만들고 유지하는 비용은 계속 나가는데, 결정에 영향을 준 화면은 절반도 되지 않았습니다.
저는 이때부터 데이터 설계를 더하는 일보다 덜어내는 일로 보기 시작했습니다. 수집할 수 있다는 것과 결정에 쓴다는 것은 처음부터 다른 문제입니다. 그 두 가지를 혼동한 것이 처음 실수였습니다.
이게 조직 구조 탓이기도 합니다. 데이터를 만드는 쪽(IT팀, 분석팀)과 결정을 내리는 쪽(운영, 영업, 현장)이 분리되어 있으면, 데이터팀은 수집할 수 있는 것을 올리고 결정하는 쪽은 자기 결정에 맞는 화면을 요청하지 않습니다. 두 쪽이 연결되지 않은 채로 화면만 쌓입니다.
그래서 지금도 대시보드를 새로 설계할 때 저는 지표 목록보다 결정 목록을 먼저 물어봅니다. 어떤 결정을 매일, 매주 내리고 있는가. 그 결정을 내릴 때 지금 무엇이 불확실한가. 그 불확실함을 줄여줄 숫자가 무엇인가. 이 세 가지 질문에 답이 나온 지표만 화면에 올립니다. 현장이 어떻게 일하는지를 먼저 보지 않고 지표를 설계하면, 현장에서 실제로 쓰는 판단 기준과 화면에 올라간 숫자가 처음부터 어긋납니다.
지표가 작동하려면 네 가지가 붙어야 합니다
관제센터에서 결정에 쓰인 지표와 그렇지 않은 지표를 비교했더니 차이가 네 가지로 정리됐습니다.
| 조건 | 확인 질문 | 비어 있으면 |
|---|---|---|
| 주인 | 이 지표로 결정하는 사람이 정해져 있는가 | 아무도 반응하지 않음 |
| 주기 | 매일인가, 주간 회의인가, 월간인가 | 어쩌다 한 번 열람 |
| 임계값 | 어느 선을 넘으면 움직이는가 | 보고도 판단이 안 됨 |
| 행동 | 임계값을 넘었을 때 무엇을 하는가 | 회의만 늘어남 |
네 가지 중 하나라도 비어 있으면 그 지표는 장식입니다. 주인이 없으면 아무도 반응하지 않습니다. 임계값이 없으면 보고도 어느 쪽으로 움직여야 할지 판단이 안 됩니다. 행동이 없으면 확인하고 끝납니다. 주기가 없으면 어쩌다 한 번 열람합니다. 네 가지가 모두 붙은 지표는 수가 적어도 조직이 움직입니다.
저희 관제센터에서 실제 운영을 돌린 지표는 손에 꼽을 정도였습니다. 그 가운데 하나가 차량별 이상 운행 발생 횟수였습니다. 책임자는 운행 관리자, 주기는 매일 오전 9시, 임계값은 차량당 주 3회 초과, 행동은 해당 차량 점검 우선 배정이었습니다. 이 지표 하나가 점검 배차 결정을 매일 바꿨습니다.
처음에는 지표가 많을수록 결정이 잘 된다고 생각했습니다. 실제로는 반대였습니다. 지표 수가 많으면 어느 것을 봐야 할지 파악하는 데 시간이 먼저 들어갑니다. 이 비용이 쌓이면 정작 결정이 늦어집니다.
임계값을 어떻게 정하느냐는 질문을 자주 받습니다. 처음에는 현장의 감각에서 출발하면 됩니다. 지금까지 이 숫자가 어느 선을 넘었을 때 문제가 됐는지를 현장 담당자에게 물으면 숫자가 나옵니다. 처음 정한 임계값이 정확하지 않아도 됩니다. 지표가 결정에 붙어 돌아가기 시작하면 임계값도 점차 다듬어집니다.
이 경험을 하고 나서 ERP를 직접 만들 때도 화면 설계는 결정 목록에서 출발했습니다. 어떤 결정을 언제 누가 내리는가를 먼저 정하고 나서 화면을 구성했습니다. 순서를 바꾸니 출시 뒤 쓰지 않는 화면이 현저히 줄었습니다.
화면을 내렸더니 남은 지표에 요구가 붙었습니다
지표 정리는 회의에서 했습니다. 화면마다 같은 질문을 하나씩 던졌습니다. 이 화면을 보고 지난달 바꾼 결정이 무엇인가. 답이 나오면 남겼고, 침묵이 길어지면 내리기로 했습니다.
화면을 내리는 일은 생각보다 어려웠습니다. 만든 사람이 있고, 요청한 부서가 있었습니다. 몇 개 화면은 설득에 시간이 걸렸습니다. 그래도 기준은 하나였습니다. 지난달 이 화면을 보고 실제로 바꾼 결정이 있는가.
없어져서 문제가 된 화면은 거의 없었습니다. 몇 달이 지나도 아무도 다시 찾지 않았습니다.
달라진 건 남은 화면에서였습니다. 임계값을 조정해 달라, 담당자 알림을 더 붙여 달라, 주간 회의 화면에서 바로 볼 수 있게 해 달라는 요청이 들어왔습니다. 지표가 결정에 연결되자 조직이 지표를 스스로 다듬기 시작했습니다. 장식이었을 때는 아무도 손을 대지 않던 지표들이었습니다.
화면을 내리면 나중에 필요한 것을 놓친다는 우려가 나옵니다. 화면을 내리는 것이지 데이터를 지우는 것이 아닙니다. 원본 데이터는 그대로 쌓입니다. 필요해지면 화면은 하루면 다시 만들 수 있습니다. 쓰지 않는 화면을 유지하는 비용은 잘 안 보일 뿐 계속 나갑니다. 화면이 많아질수록 정작 봐야 할 지표의 자리도 좁아집니다.
지금 운영 중인 대시보드에 던질 질문 하나
지금 있는 대시보드를 열고 화면마다 물어보십시오. 지난달 이 화면을 보고 바꾼 결정이 무엇인가. 답이 나오지 않는 화면이 몇 개인지 세어보시면, 다음 데이터 예산을 어디에 써야 할지가 보입니다.
지표가 결정에 연결된 조직은 AI 분석 도구를 도입할 때도 성과가 다릅니다. 쌓이는 데이터 가운데 무엇이 자산이고 무엇이 비용인지는 다음 글에서 이어 다룹니다. 지금 운영 중인 대시보드에서 네 가지 조건이 모두 붙은 지표는 몇 개입니까.
AI 요약 기반 보고를 받고 결정할 때 빠진 정보를 어떻게 확인합니까 AI가 요약했다고 읽은 것이 됩니까에서 이어집니다.
부서마다 지표 계산이 달라서 회의가 길어지는 문제를 해결하는 방법은 지표 정의가 부서마다 다르면 대시보드 회의는 숫자 싸움이 됩니다에서 이어집니다.
보고서에 지표가 너무 많아서 어디를 봐야 할지 모르겠습니다. 줄이자고 하면 나중에 필요할 수 있다는 말이 나옵니다. 지표는 늘어나는데 없애는 기준이 없습니다에서 이어집니다.