시스템을 도입했는데 아무도 안 씁니다

현장의 질문들 - 20

시스템을 열었는데 자료가 안 올라옵니다. 교육도 했고 독려도 했는데 달라지지 않습니다.
여기서 대개 "왜 안 쓰는가"를 묻게 됩니다. 그런데 질문을 바꾸는 편이 낫습니다.
지금 이 일은 어디에서 보고되고 있습니까.
대부분의 경우 답이 이미 있습니다. 주간회의에서 말하고, 월간보고로 올리고, 결재 문서로 남깁니다. 그 루트는 시스템이 들어오기 전부터 돌아가고 있었고, 지금도 돌아갑니다.
그러면 시스템 입력은 같은 내용을 한 번 더 적는 일이 됩니다.
안 쓰는 것이 아닙니다. 두 번 하기 싫은 것입니다.

왜 이렇게 됐는가

짚고 넘어갈 것이 하나 있습니다.
대부분의 연구소에는 연구관리를 전담하는 사람이 없습니다. 연구하던 사람이 어느 날 그 일을 맡습니다. 본업이 따로 있고, 시스템 구축은 그 위에 얹힌 일입니다.
그래서 두 가지가 벌어집니다. 무엇을 담을지 정할 시간이 부족하고, 열고 나면 그 사람은 원래 연구로 돌아갑니다.

여기에 몇 가지가 겹칩니다. 현업이 아니라 IT 부서가 주도했거나, 경영진이 필요해서 시작했는데 쓰는 사람은 지금이 편하거나, 업무를 정리하는 과정 없이 바로 시스템부터 만들었거나.

이 원인들은 지금 화면을 고쳐서 해결되지 않습니다. 목적부터 다시 맞춰야 하고, 그건 다른 이야기입니다.
다만 열고 난 뒤에 생긴 문제는 지금 손댈 수 있습니다. 이 글은 그쪽을 다룹니다.

"이미 다른 데 보고했는데"

저희가 만난 곳에서, 안 쓰인다고 하시는 경우 대개 다른 루트로 이미 보고하고 있었습니다. 주간회의, 월간보고, 결재 문서 같은 것입니다.

그리고 그 루트가 진짜입니다.
회의에서 말한 것이 실제로 반영되고, 결재가 올라가야 일이 진행됩니다. 시스템은 그다음입니다. 시간이 남으면 채우고, 없으면 미룹니다.

그러면 이런 순서로 굳어집니다.

시스템 통계로는 입력이 되고 있는 것으로 나옵니다. 건수가 잡히고 정착률이 보고됩니다. 그런데 그 안에 든 것은 회의 자료를 옮겨 적은 요약입니다.
가장 나쁜 상태입니다. 안 쓰이는데 쓰이는 것으로 보입니다.

도움은 없고, 보이기만 합니다

두 번 적는 것보다 더 큰 것이 있습니다.

주간회의는 내 일을 위해 합니다. 막힌 것을 말하고, 판단을 받고, 도움을 얻습니다. 말한 것이 그 자리에서 쓰입니다.
시스템 입력은 그렇지 않습니다. 적어 넣어도 나에게 돌아오는 것이 없습니다. 누군가 보려고 두는 것으로 느껴집니다.

같은 내용을 두 번 적는 것보다, 두 번째가 나를 위한 것이 아니라는 점이 더 큽니다.

여기서 한 가지가 더 붙습니다. 문제나 지연을 시스템에 남기면 그대로 드러납니다. 회의에서는 상황을 설명하며 말할 수 있는데, 시스템에는 그냥 남습니다.
그래서 정작 위로 올라가야 할 것이 안 올라갑니다. 경영진이 알아야 할 주요 문제와 위험이 시스템에는 없고, 다른 루트로만 흐르거나 아예 늦게 알려집니다.

그 루트가 시스템에서 나오게 합니다

없애야 할 것은 시스템 입력이 아니라 이중 입력입니다.

주간회의를 없애라는 뜻이 아닙니다. 그 회의 자료가 시스템에서 나오게 하면 됩니다.
각자 적어 온 자료를 모아 회의하는 대신, 시스템에 있는 것으로 회의합니다. 회의에서 나온 결정과 다음 할 일을 그 자리에서 남기면, 그것이 다음 주 자료가 됩니다.

그러면 시스템 입력이 회의 준비가 됩니다. 두 번이 한 번이 되고, 적은 것이 그 자리에서 쓰입니다.

월간보고도, 결재 문서도 같습니다. 어느 루트든 지금 손으로 만들고 있다면, 그것이 시스템에서 나오게 하는 것이 먼저입니다.

옛 방식을 억지로 닫을 필요는 없습니다

병행 기간을 두는 것은 자연스럽습니다. 문제는 병행이 아니라, 두 방식이 서로 무관하게 굴러가는 것입니다.

닫는 것보다 잇는 것이 낫습니다. 옛 방식이 시스템에서 나오기 시작하면, 닫으라고 하지 않아도 한쪽으로 모입니다.

계획을 적는다는 것

이중 입력을 없애도 남는 부담이 하나 더 있습니다.

연구 프로젝트 관리는 다른 시스템과 성격이 다릅니다.
회계나 구매는 일이 끝나면 기록이 생깁니다. 연구 프로젝트는 본인이 계획을 세우고, 그 계획과 비교당합니다.
내가 적은 것이 나중에 나를 평가하는 근거가 됩니다. 그러니 계획을 느슨하게 잡거나, 아예 안 적거나, 나중에 결과에 맞춰 고치게 됩니다.

느슨하게 만들면 해결될까요

부담스러우니 임의로 두자는 대응이 흔합니다. 계획을 안 적어도 되게 하고, 늦어도 표시가 안 나게 하고, 나중에 언제든 고칠 수 있게 합니다.

그런데 그러면 시스템이 아무것도 못 합니다.
계획을 언제든 고칠 수 있으면 계획 대비 실적이라는 말 자체가 없어집니다. 늦어도 표시가 안 나면 무엇이 밀렸는지 알 수 없습니다.

부담을 줄이려고 느슨하게 만들었는데, 느슨해서 아무도 안 보게 됩니다. 안 보는 시스템은 다시 안 쓰이는 시스템이 됩니다.

반대로 조이기만 해도 안 됩니다. R&D는 계획이 바뀌는 것이 정상입니다. 해보고 아니면 방향을 바꿉니다. 그런데 시스템이 그것을 전부 지연으로 표시하면, 제대로 한 사람이 손해를 봅니다. 그러면 연구원은 계획을 아예 안 적게 됩니다.

정해야 할 것은 어디까지 열어둘 것인가입니다

모두 고정하면 현실과 어긋나고, 모두 열어두면 계획이 아닙니다. 경계를 정하는 일입니다.

계획 변경 — 무엇을 승인받고 무엇을 알아서 바꾸는가

과제 목표나 최종 종료일처럼 바꾸면 안 되는 것은, 처음 확정할 때와 같은 절차를 다시 거칩니다. 그 안의 세부 일정은 연구책임자가 바꾸되 이력이 남습니다.
경계를 정해 두면 계획이 굳지도 않고 흐물흐물해지지도 않습니다.

진행 상태 — 무엇을 날짜로 보고 무엇을 판단에 맡기는가

계획서에 있는 주요 시점은 날짜로 관리합니다. 착수, 중간 점검, 단계 전환, 종료 같은 것입니다.
다만 그 사이의 진행 상태까지 시스템이 자동으로 계산하려 하면 어긋납니다. 날짜만 비교해서는 방향을 바꾼 것과 늦어진 것을 구분할 수 없습니다. 그 구간은 연구책임자가 판단하게 두는 편이 정확합니다.

시스템이 계산한 것보다 사람이 판단한 것이 정확한 경우가 있습니다.

다만 열어둔 구간이 길면 안 됩니다

확인이 일어나는 지점을 정해 두어야 합니다. 단계가 넘어가는 자리, 중간 결과가 나오는 자리, 다음으로 갈지 정하는 자리.
그 지점에서는 반드시 확인됩니다. 상태를 다시 보고, 계획과 맞는지 따집니다.

문제는 그 지점 사이가 너무 벌어질 때입니다. 반년 동안 확인하는 자리가 하나도 없으면, 그 기간은 사실상 관리 밖입니다. 마지막에 가서야 밀린 것을 알게 됩니다.

그리고 이 경계는 과제마다 다릅니다

납기가 걸린 수탁과제와 탐색 과제에 같은 규칙을 적용하면, 한쪽에는 과하고 다른 쪽에는 모자랍니다.
획일적으로 적용하지 않고 업무 성격과 중요도에 따라 차등을 두는 것. 이것이 임의성을 다루는 방법입니다.

열어둔다는 것은 판단을 맡기는 것이지, 기록을 안 남긴다는 뜻이 아닙니다. 왜 그렇게 판단했는지는 남습니다. 그래야 나중에 되짚을 수 있습니다.

이건 화면 설정이 아니라 규칙의 문제입니다. 정하지 않고 알아서 하라고 두면, 각자 안전한 쪽으로 갑니다.

사람 탓이 아닙니다

안 쓰는 것은 대개 합리적인 선택입니다.
그 사람에게 시스템은 일을 하나 더 늘리는 것이었습니다. 늘어난 일은 밀립니다. 이미 보고할 곳이 있는데 한 번 더 적으라고 하면, 미루는 쪽이 합리적입니다.

교육을 더 하거나 독려하는 것으로는 바뀌지 않습니다. 일이 줄어야 씁니다.

그리고 일을 줄이는 것만으로는 부족합니다. 적은 것이 나를 불리하게 만들지 않는다는 것도 있어야 합니다. 그건 설득이 아니라 규칙으로 정해집니다.

둘 다 지금 할 수 있는 일입니다. 손으로 만들고 있는 보고 자료가 무엇인지, 그리고 계획을 고치는 규칙이 정해져 있는지부터 확인해 보십시오.

관련 글

[현장의 질문들] 전자연구노트 구축 절차와 준비할 것
[현장의 질문들] 연구과제관리 시스템은 무엇을 관리합니까
[현장의 질문들] 공유폴더 자료관리는 어디까지 됩니까