시스템 - 도입, 그럼 무엇을 먼저 해야 합니까

현장의 질문들 - 3

다 맞는 말인데, 그래서요

지난 글에서 왜 시스템이 정착되지 않는지를 여섯 가지로 정리했습니다.

그 글을 읽으신 분들이 하실 법한 반응이 있습니다. "다 맞는 말인데, 그래서 뭘 어떻게 하라는 겁니까."

정당한 질문입니다. 원인을 아는 것과 시작하는 것은 다른 일이니까요. 그리고 대부분의 조직에는 지금 돌아가는 업무가 있고, 그것을 멈출 수 없습니다.

오늘은 그 이야기입니다. 무엇을 먼저 해야 하는지, 전환기를 어떻게 넘기는지, 그리고 바뀌는 것과 남는 것을 어떻게 나누는지에 대해서요.

업무 구조화(PI)는 선택 사항이 아닙니다

먼저 이것부터 분명히 하겠습니다.

지난 글에서 정착 실패의 첫 번째 원인으로 옮길 원본이 없는 것을 화면부터 만든다는 점을 짚었습니다. 판단과 전제와 검토 내용은 지금 하지 않는 일이라 종이에도 엑셀에도 없고, 그래서 화면을 만들어도 빈 칸으로 남는다고요.

이 문제는 나중에 보완할 수 있는 것이 아닙니다. 오픈하고 나서 "이제 여기에 적어주세요"라고 하면 아무도 안 적습니다. 무엇을 적어야 할지 모르고, 적을 근거도 없기 때문입니다.

이 작업이 부담스러운 이유도 분명합니다. 시간이 걸리고, 그 일을 하는 사람들이 직접 해야 하고, 무엇보다 눈에 잘 안 보입니다. 그래서 대부분 건너뜁니다.

그런데 이 작업에는 눈에 보이는 산출물이 있습니다. 뒤에서 다시 말씀드리겠습니다.

어떻게 정리하는가

업무 구조화를 어느 범위부터 시작할지는 회사마다 다릅니다. 업무 유형이 셋뿐인 곳과 스물인 곳이 같을 수 없고, 여유가 있는 곳과 없는 곳도 다릅니다. 그건 각자의 사정에 맞춰 정하시면 됩니다.

다만 정리하는 방법 자체는 대체로 같습니다.

하나, 그 업무에서 어떤 활동이 이루어지는지 나눕니다. 신규 과제 검토라면 시장 조사, 대안 비교, 기술 타당성 검토, 규제 요건 확인, 선정. 이 정도로 나뉩니다.

둘, 활동마다 무엇을 확인해야 하는지 뽑습니다. 여기서 그 일을 오래 한 사람이 필요합니다. 그리고 앞선 글에서 이야기한 대로 이 대목이 가장 어렵습니다. 물어보면 "그냥 그렇게 하는 거야"라는 답이 나오니까요.

방법이 하나 있습니다. 가장 최근에 그 일을 한 건을 놓고 되짚는 것입니다. 이번에 무엇을 봤는지, 어디서 걸렸는지, 무엇을 확인 안 했으면 큰일 났을지. 추상적으로 묻는 것보다 훨씬 잘 나옵니다.

셋, 어떤 판단이 어디서 일어나는지 표시합니다. 확인하는 일과 판단하는 일은 다릅니다. 판단하는 자리에는 근거와 대안과 전제가 함께 남아야 합니다.

넷, 실제로 돌려보고 다듬습니다. 다음에 그 일이 생기면 정리한 것을 들고 해봅니다. 빠진 것이 나오고, 쓸데없는 것도 드러납니다. 고칩니다.

시스템 없이도 시작할 수 있습니다

여기서 중요한 점이 있습니다.

위 네 단계는 시스템이 없어도 할 수 있습니다. 문서 한 장으로 시작해도 됩니다. 그리고 그 문서만으로도 이미 효과가 납니다. 다음 사람이 그것을 들고 시작하니까요.

이게 왜 중요하냐면, 앞선 글에서 이야기한 문제 하나가 여기서 풀립니다. 업무 구조화는 중간 산출물이 없어 보인다는 것 말입니다.

실제로는 있습니다. 활동 구분과 확인 항목이 나오고, 그것을 돌려서 다듬은 결과도 나옵니다. 보고할 것이 생깁니다.

그리고 이 순서로 가면 시스템을 만들 때 훨씬 수월합니다. 화면에 무엇이 들어가야 하는지가 이미 정해져 있으니까요. 요구사항을 짜내는 것이 아니라 정리된 것을 옮기는 일이 됩니다.

전환기를 설계합니다

기존 방식과 새 방식이 동시에 돌아가는 기간은 피할 수 없습니다. 문제는 그 기간을 설계하지 않고 방치하는 것입니다.

세 가지를 정해 두어야 합니다.

언제까지 병행할지 날짜로 정합니다. "익숙해질 때까지"는 기한이 아닙니다. 끝이 없으면 영원히 병행하고, 영원히 병행하면 새 방식은 끝내 자리를 못 잡습니다.

어느 것이 원본인지 정합니다. 두 곳에 다 있는데 내용이 다르면 어느 쪽이 맞습니까. 이걸 미리 정해두지 않으면 매번 확인해야 하고, 확인하는 비용이 쌓이면 사람들은 한쪽만 보게 됩니다. 그리고 대체로 예전 쪽을 봅니다.

무엇부터 끊을지 정합니다. 한 번에 다 끊을 수는 없으니 순서가 필요합니다.

가장 먼저 끊을 것은 회의 자료입니다

병행을 끝내는 데 가장 효과적인 지점이 하나 있습니다. 회의입니다.

앞선 글에서 정보가 회의에서 말로 사라진다는 이야기를 했습니다. 그리고 그 구조가 유지되는 한 시스템은 껍데기로 남는다고요.

그래서 회의 자료를 없애는 것부터 합니다.

주간회의에 별도 자료를 만들어 오지 않습니다. 시스템 화면을 열어놓고 시작합니다. 각자 자기 과제 화면을 띄우고, 거기 있는 것을 보면서 이야기합니다.

이 한 가지가 여러 개를 동시에 해결합니다.

자료 만드는 시간이 없어집니다. 조직에 따라서는 이것만으로도 상당한 시간이 절약됩니다.

입력할 이유가 생깁니다. 회의에서 그 화면을 보니까 채워야 합니다. 독려할 필요가 없습니다.

경영진이 시스템을 열게 됩니다. 앞선 글의 여섯 번째 원인이 여기서 자동으로 해결됩니다.

그리고 결정이 그 자리에 남습니다. 화면을 보며 이야기하다가 정해진 것을 그 자리에 적습니다. 회의록을 따로 만들 필요가 없습니다.

관리 방식은 바뀝니다. 그게 정상입니다

여기서 프로젝트 관리 업무의 성격을 하나 짚겠습니다.

회계나 구매는 잘 안 바뀝니다. 기준이 밖에 정해져 있고, 바뀌어도 예고가 있습니다. 그래서 한 번 잘 만들어 두면 오래 씁니다.

프로젝트 관리는 다릅니다.

정부 정책이 바뀌면 과제 기획 방식이 달라집니다. 경영진이 바뀌면 무엇을 중요하게 볼지가 달라집니다. 새 분야에 진출하면 지금까지 안 보던 것을 봐야 합니다. 규제가 강화되면 확인 항목이 늘어납니다. 경쟁 상황이 급변하면 검토 단계를 줄여야 할 때도 있습니다.

이건 예외가 아니라 이 업무의 성격입니다. 그래서 관리 방식은 바뀝니다. 바뀌어야 정상입니다.

그렇다면 필요한 것은 바뀌지 않게 하는 것이 아니라, 바뀔 때 제때 반영하는 것입니다.

여기서 흔히 두 가지 실패가 나옵니다.

하나는 처음에 완벽하게 설계하려는 것입니다. 모든 경우를 다 담으려 하면 설계가 길어지고, 완성됐을 때는 이미 조건이 바뀌어 있습니다.

다른 하나는 바꿀 수 있게 만들어 놓고 아무도 안 바꾸는 것입니다. 이게 더 흔합니다. 고칠 수 있다는 것과 실제로 고쳐지는 것은 다릅니다.

그래서 적기에 반영되게 하려면 두 가지가 필요합니다.

누가 바꿀 수 있는지 정해져 있어야 합니다. 확인 항목 하나 추가하는 데 개발자를 불러야 한다면, 그 시스템은 금방 현실과 어긋납니다. 그리고 어긋난 시스템은 아무도 안 씁니다. 현장에서 고칠 수 있어야 합니다.

언제 바꾸는지 계기가 있어야 합니다. 바꿀 수 있다고만 해두면 아무도 안 바꿉니다. 반기에 한 번 점검한다든지, 새 유형의 일이 생기면 그때 정리한다든지, 사고가 나면 그 항목을 추가한다든지 하는 규칙이 있어야 합니다.

바뀌는 것과 남는 것을 나눕니다

그런데 모든 것이 바뀌어도 되는 것은 아닙니다. 여기서 구분이 필요합니다.

바뀌는 쪽은 절차와 관리점입니다.

어떤 단계를 거치는가. 각 단계에서 무엇을 확인하는가. 누가 검토하고 누가 승인하는가. 어느 시점에 무엇을 보는가. 어떤 서류가 필요한가.

이건 정책과 상황에 따라 계속 달라집니다. 그리고 달라져야 합니다.

남는 쪽은 기록입니다.

어떤 자료를 봤는가. 어떤 판단을 내렸고 근거가 무엇인가. 어떤 대안을 검토하다 접었는가. 무엇을 전제로 삼았는가. 검토 의견이 무엇이었는가.

이건 절차가 어떻게 바뀌든 남아야 합니다.

이 구분이 왜 중요한지는 몇 년 뒤에 드러납니다.

3년 전에 비슷한 검토를 했습니다. 그 사이 검토 절차가 두 번 바뀌었습니다. 그런데 지금 알고 싶은 것은 그때 무엇을 보고 어떻게 판단했는지입니다. 절차가 바뀌었다고 그 기록을 못 읽게 되면, 회사는 자기 과거에 접근할 수 없습니다.

정착됐는지 어떻게 압니까

마지막으로 판단 기준입니다.

접속률이나 입력 건수 같은 지표는 별 의미가 없습니다. 시키면 접속하고, 시키면 입력합니다.

실제 신호는 이런 것들입니다.

묻기 전에 시스템에서 찾아봅니까. 예전에 어떻게 했는지 궁금할 때, 사람을 붙잡기 전에 시스템을 여는지요.

회의에서 자료 대신 화면을 엽니까. 이게 되면 절반은 된 것입니다.

안 쓰던 사람이 아쉬워서 쓰기 시작합니까. 다른 사람들이 쓰면서 자기만 정보가 없어지는 상황이 생기면, 독려 없이도 들어옵니다.

그리고 이 항목도 넣어달라는 요청이 현장에서 올라옵니까.

마지막이 가장 확실한 신호입니다. 요청이 올라온다는 것은 그 사람이 그 시스템을 자기 것으로 여기기 시작했다는 뜻입니다. 남의 것이면 불평은 해도 개선 요청은 안 합니다.

정리하면

업무 구조화는 건너뛸 수 없습니다. 오픈하고 나서 보완할 수 있는 것이 아니라, 안 하면 반드시 실패하는 선행 작업입니다. 그리고 이 작업은 시스템 없이도 시작할 수 있고, 그 자체로 산출물이 나옵니다.

전환기는 설계합니다. 병행 기한을 날짜로 정하고, 어느 것이 원본인지 정하고, 회의 자료부터 끊습니다.

관리 방식은 바뀝니다. 완벽하게 설계하려 하지 말고, 현장에서 고칠 수 있게 만들고 언제 고칠지 계기를 정해 둡니다.

다만 바뀌는 것과 남는 것은 나눕니다. 절차와 관리점은 바뀌고, 자료와 판단과 전제와 검토 의견은 남습니다.

정착 여부는 접속률이 아니라 요청으로 판단합니다.

지난 글에서 초반에는 부담이 반드시 늘어난다는 이야기를 했습니다. 그 구간을 어떻게 짧게 만드느냐가 사실상 이 일의 전부이고, 그 답은 빨리 넣는 것이 아니라 순서를 지키는 것에 있다고 봅니다.