KPI가 중요하다는 것은 여러가지 이유로 알 수 있다.
하지만 이번에는 KPI 를 만드는 것이 얼마나 어렵고,
간사한(혹은 똑똑한) 직원들이 많은지 알아보자.
예를들어 A라는 시스템의 활용율을 높히기 위한 KPI 를 만든다고 가정해보자.
A라는 시스템을 활용함으로서 더이상 수작업으로 자료를 만들거나 메일을 보내지 않아도 된다.
이를 위해 거금을 들여서 A라는 시스템을 만들었고,
이 A 시스템이 잘 만들어졌다는 것에 대한 증거, 그리고 활용을 높히기 위한
일환으로 A시스템 활용율 이라는 KPI 를 만들었다.
A시스템활용률
A시스템을 사용하거 되면서 고객사에 자료를 보내면 기록이 남는다.
이 기록의 개수를 이용해서 활용률을 만든다면 간단하게
A시스템을 이용해서 보낸 자료수 / 전체 고객에게 보낸 자료수
로 하면 된다. 간단하지 않은가?
어떻게 측정할 것인가?
직원들은 이 KPI 를 늘리기 위해 최대한 A시스템을 사용할것이고, 메일 사용을 지양할 것이다.
전체 고객에게 보낸 자료 수는 A시스템을 이용한 수 + 메일 보낸 수 로 집계하면 될 것이다.
그리고 모든 기록은 A시스템에 저장이 되도록 하여, 메일을 사용했는지, 아니면 시스템을 사용했는지?
확인 할 수 있도록 만들었다.
날자 | 데이터내용 | 고객사 | 사용시스템 |
2023-01-01 | AAA | 가 | A시스템 |
2023-01-04 | BBB | 나 | 메일 |
2023-01-07 | CCC | 가 | A시스템 |
2023-01-10 | DDD | 라 | 메일 |
2023-01-13 | EEE | 가 | A시스템 |
짜잔, 이렇게 KPI 를 만들었다. 이제 A시스템의 활용률도 올라갈 것이고,
직원들의 업무 효율도 늘어나겠지?
꼼수가 있었다.
시스템을 사용해서 일을 하면 위의 표와 같이 사용시스템이라는 곳에
어떤 시스템을 사용했는지, 기록이 되는 곳이 있는데, 직원들이 일단 급하고 귀찮으니까,
메일로 일을 처리하고, 나중에 시스템으로 다시 작업을 하고 나서
시스템 작업을 근거로 시스템 관리자에게 "메일" 이라는 내용을 "A시스템" 으로
수정해 달라고 요청을 하는 것이다.
시스템 담당자 입장에서는, 직원이 시스템을 이요한 기록이 있으니,
굳이 왈가왈부하지 않고 시스템 데이터를 "메일" 에서 "A시스템" 으로 수정을 해주었다.
일단 급하니까, 메일로 일을 하고, 나중에 KPI 를 위해서
한번 더 시스템 작업과 데이터 수정을 요청하게 되는, 삼중 작업을 하고 있는 것이었다.
이런 이유로 실제 KPI 점순는 높게 나오고 있었으나, 직원들의 근심걱정이 이만저만이 아니었다.
데이터 변경 요청율
자, 데이터 변경을 요청하면 시스템 활용률을 높힌다는 우리의 목적과는 달라지니,
데이터 변경을 최소화 해야 한다. 그래서 "데이터변경 요청률" 이라는 KPI 를 하나 더 만들었다.
(악몽의 시작) 데이터 변경 요청률이 한달에 2건이상 넘어가면 감점을 주기 시작한다.
이런 KPI 가 생겼으니, 이제 데이터 변경 요청이 적어지리라.
시스템 사용률을 높히려면 이제 강제로라도 시스템을 사용하는 방법 밖에 없다.
또 꼼수가 있었다.
그래도 급하면 위에서 빨리하는 방법을 찾으라고 하는 턱에
좋은 방법을 생각해냈다. 일단 고객사에는 메일을 수작업으로 빨리 보내놓고, 기록을 하지 않는 것이다.
그리고 메일기록을 만들지 않은 다음, 나중에 금요일즈음에 시간을 내서
그 한주동안 보낸 메일을 시스템에 입력하면 된다.
이렇게 하면 메일을 보내고, 기록을 남기지 않고, 따로 보관했다가, 몰아서 시스템에 입력한다.
기록은 좀 늦게 입력이 되겠지만, KPI 점수는 다 지킬 수 있고, 위에서 빨리 하니까 좋아하고, 잘 된다. ㅋㅋㅋ
하지만 역시 KPI 때문에 업무가 꼬이고, 더 힘들어진 것은 사실이다.
적시 데이터 입력률
고객사는 메일을 월요일에 받았는데, 자꾸 D+3, D+4 에 시스템 입력이 되는 일이 빈번하다.
아무래도 수작업으로 처리하고, 시스템 입력만 나중에 하는 것으로 보인다.
이를 막기 위해 "적시 데이터 입력률" 이라는 KPI 를 하나 더 만든다.
고객사가 데이터를 받은 날짜 + 다음날까지 입력을 해야 한다. 만약 +2, +3 일이 되면 감점을 받게 된다.
...
여기까지 보면 시스테 활용률을 늘리기 위해서
A시스템활용률, 데이터변경요청율, 적시데이터입력률 등의 KPI 가 무한정 생기는 것을 볼 수 있다.
KPI 는 KPI 대로, 현업은 그에 대한 이해 없이 그냥 바뀌지 않고 하려는 습성 때문에
이런일이 자주 벌어진다.
가장 좋은 것은 KPI 를 만들기 이전에
A시스템을 만들었고, 이 시스템을 사용하면 어떤 점이 좋고 (효율이 올라가며, 데이터 정합성이 높아진다. 등등)
사용을 유도 하는 일이 잘 선행되었으면 좋았을 텐데, 서로간의 소통없이
무작정 KPI 만 만들고 지켜라, 불합리가 있을 수도 있지만 지켜라 등등의
방법으로 일이 진행되면 이런 웃을 수 없는 일이 생긴다.
'개발자 이야기' 카테고리의 다른 글
수작업이 많은 업무의 위험성 (0) | 2023.09.04 |
---|---|
스페셜리스트와 제네럴리스트 그리고 DX (0) | 2023.08.18 |
미국 회사 파견 이야기 (엄청난 개인주의) (0) | 2023.02.10 |
OpenAI 에서 특정한 글을 발행 요청하는 법 (자동 글쓰기, python) (0) | 2023.02.10 |
OpenAI 에서 자신의 API Key 생성하는 법 (0) | 2023.02.10 |
댓글