시스템을 깔았는데, "예전엔 말로 하면 됐는데"가 나옵니다

구축의 순서 - 2

"예전엔 말로 하면 됐는데"

시스템을 도입하고 석 달쯤 지나면 이 말이 나옵니다.
틀린 말이 아닙니다. 실제로 그랬으니까요. 과제 방향을 바꿀 일이 생기면 소장실에 들어가서 설명하고 승낙을 받았습니다. 십 분이면 끝났습니다.
지금은 화면을 열고, 변경 사유를 적고, 무엇을 검토했는지 고르고, 관련 부서 의견을 받습니다. 같은 일에 한 시간이 걸립니다.
그래서 어떻게 되나. 예전 방식으로 돌아갑니다. 먼저 말로 정하고, 시스템에는 나중에 결과만 적습니다.

화면이 불편해서가 아닙니다

시스템에는 결론만 남습니다. 애초에 그걸 남기려고 만든 게 아닌데 그렇게 됩니다.

여기서 흔히 나오는 진단이 있습니다. 시스템이 불편해서 그렇다, 화면을 고치면 된다. 반은 맞고 반은 틀립니다.

구두로 하던 일을 시스템에 넣는다는 것은 화면 문제가 아닙니다. 그 회사가 20년간 일해온 방식을 건드리는 일입니다.

세 가지가 동시에 바뀝니다.

하나, 안 하던 말을 해야 합니다. 구두 보고는 결론만 말하면 됐습니다. "그 건은 A로 가겠습니다." 시스템은 왜 B를 안 골랐는지, 무엇을 전제로 했는지를 묻습니다. 전에 없던 일이 생긴 것으로 느껴집니다.

둘, 말이 남습니다. 구두는 흐릅니다. 기록은 남습니다. 3년 뒤에 누군가 열어볼 수 있다는 것 자체가 부담이 됩니다.

셋, 순서가 굳어집니다. 구두로는 급하면 건너뛰고 나중에 채웠습니다. 시스템은 순서대로 요구합니다.

의사결정은 그 회사의 일하는 방식과 직결되어 있습니다. 그래서 시스템에 넣는 순간 문화와 부딪힙니다. 기능이 부족해서가 아닙니다.

여기서 미리 말씀드리겠습니다. 문화를 바꾸자는 이야기가 아닙니다. 부딪히는 범위를 좁히자는 이야기입니다.

첫 번째 선별 — 무엇이 이미 담겨 있는 일인가

지난 글에서 단위기능을 적어보자고 했습니다. 적었으면 이제 가릅니다.

첫 번째 기준은 두 가지 질문입니다.

둘 다 예이면 Transaction 업무입니다. 주문을 받고, 자재를 청구하고, 대금을 지급하고, 프로토콜대로 실험을 수행하고 결과를 기록합니다. 앞선 시리즈에서 거래 처리라고 부른 것과 같은 것입니다.

둘 중 하나라도 아니면 의사결정 업무입니다. 어떤 후보를 고를지, 다음 단계로 갈지, 무엇을 규격으로 삼을지. 절차가 없고, 누가 어떤 정보를 보느냐에 따라 결과가 달라집니다.

여기서 저항의 크기가 갈립니다.

Transaction 업무를 시스템에 넣으면 저항이 적습니다. 원래 절차가 있었고 시스템이 그 절차를 옮긴 것뿐입니다. 의사결정 업무를 넣으면 저항이 큽니다. 원래 절차가 없었고 구두와 감으로 하던 일이니까요.

그리고 저항이 큰 쪽이 이번 구축의 대상입니다. 쉬운 쪽은 이미 되어 있습니다.

경계는 회사마다 다릅니다

주의할 것이 하나 있습니다. 같은 일이 회사에 따라 다른 쪽에 놓입니다.

원료 공급사를 바꾸는 일을 예로 들겠습니다.

어느 쪽이 맞는 것도 아닙니다. 그 회사가 다루는 원료의 위험도와 그동안의 경험이 그 경계를 만들었습니다. 남의 회사 기준을 가져오면 있어도 될 심의가 새로 생기거나, 있어야 할 심의가 사라집니다.

지난 글에서 타사 사례가 그대로 안 맞는다고 했는데, 경계선의 위치가 다른 것도 그 이유 중 하나입니다.

Transaction 쪽은 이번 대상이 아닙니다

가르고 나면 대개 Transaction 쪽이 훨씬 많습니다. 그리고 그 대부분은 이미 관리되고 있습니다. ERP가 있고, PLM이 있고, 규제산업이면 전자연구노트도 있습니다.

이번 구축의 대상이 아닙니다. 중요하지 않아서가 아니라 이미 담을 그릇이 있어서입니다.

이걸 짚고 가야 하는 이유가 있습니다. 시스템 구축이라고 하면 회사 전체를 다시 그리려는 시도가 나오기 쉽습니다. 그러면 범위가 감당할 수 없게 커지고, 이미 잘 돌아가던 일까지 흔들립니다.

손대지 않는 범위를 먼저 정하는 것이 범위 설정의 절반입니다.

두 번째 선별 — 이력이 남아야 하는가

여기서 끝내면 문제가 생깁니다. "그럼 의사결정은 전부 시스템에 넣으라는 거냐"가 되니까요.

그건 무리입니다. 판단은 하루에도 수십 번 일어납니다. 실험 순서를 바꾸는 것도 판단이고, 회의를 미루는 것도 판단입니다. 다 넣으려 들면 아무도 못 씁니다.

그래서 한 번 더 가릅니다. 의사결정 중에서 이력이 남아야 하는 것만 고릅니다.

세 가지 질문에 대봅니다.

셋 중 하나라도 예이면 남깁니다. 아니면 안 남깁니다.

대보면 이렇게 갈립니다.

판단이니까 다 남기는 것이 아닙니다. 판단 중에서도 골라 남깁니다.

앞에서 문화와 부딪힌다고 했는데, 여기가 그 답입니다. 구두로 하던 일을 전부 시스템에 넣으면 회사 전체가 저항합니다. 이력이 남아야 하는 것만 골라 넣으면 부딪히는 면적이 작아집니다.

골라낸 것만 마스터에 설정합니다

그러면 그 판단을 매번 해야 합니까. 그렇지 않습니다.

한 번 골라서 마스터와 표준에 설정해두면 됩니다. 그다음부터는 설정된 것만 시스템에 담깁니다.

이게 중요한 이유가 있습니다.

세세한 것까지 다 설계하려 들면 마스터가 끝없이 커집니다. 그리고 마스터가 커지면 입력 화면도 같이 커집니다. 고를 것이 많아지고, 고르기 싫어지고, 안 쓰게 됩니다.

반대로 중요한 것만 설정하면 마스터가 작습니다. 작은 마스터가 곧 간결한 화면입니다.

그리고 설정되지 않은 것은 애초에 담기지 않습니다. 매번 "이건 남겨야 하나" 하고 고민할 필요가 없어집니다. 마스터가 곧 범위입니다.

그리고 나중에 넓힙니다

여기서 오해가 생길 수 있어 덧붙이겠습니다. 처음에 좁게 잡는 것이 영원히 좁게 간다는 뜻은 아닙니다.

시스템이 안착하고 나면 상황이 달라집니다.

사람들이 익숙해집니다. 처음에는 부담이던 입력이 몇 달 지나면 손에 붙습니다. 쓸모가 보이기 시작합니다. 조회해서 뭔가 나오는 경험을 하고 나면, "이것도 넣어두면 좋겠다"는 말이 현업에서 먼저 나옵니다. 요구가 구체적이 됩니다. 처음에는 무엇이 필요한지도 모르지만, 반년 쓰고 나면 무엇이 아쉬운지가 분명해집니다.

그때 마스터에 항목을 더합니다. 처음부터 다 넣는 것보다 이 순서가 훨씬 안전합니다.

반대 순서는 어렵습니다. 넓게 시작해서 줄이는 것은 실패로 읽히고, 이미 만든 화면을 걷어내는 일도 간단하지 않습니다. 좁게 시작해서 넓히는 것만 자연스럽게 됩니다.

흔한 실수 하나

마지막으로 한 가지만 짚겠습니다.

업무를 가른다면서 조직도를 그리기 시작하는 경우가 있습니다. 어느 부서가 무엇을 하는지부터 정리하려 드는 것이죠.

지난 글에서 단위기능과 Role을 구분했습니다. 단위기능은 일 자체이고 Role은 그 일을 맡은 자리입니다. 지금 하는 일은 일을 가르는 것이지 사람을 나누는 것이 아닙니다.

부서부터 그리면 두 가지가 어긋납니다. 한 부서가 Transaction과 의사결정을 둘 다 하는 경우를 못 담고, 하나의 결정에 여러 부서가 걸리는 경우도 못 담습니다.

일을 먼저 가르고, Role은 나중에 붙입니다.

이 단계의 산출물

문서가 아닙니다. 업무 목록과 그 성격 판정입니다.

오른쪽 열에 '예'가 붙은 것들이 다음 단계로 넘어갑니다. 그리고 그 목록이 곧 마스터에 설정될 것들입니다.

다음 편에서는

담을 것을 골랐으면, 이제 담을 자리를 만들어야 합니다.

결정이 어디에 걸릴 것인가. 코드 체계와 표준분류 이야기입니다. 그런데 여기서 대부분의 회사가 한 번 실패합니다. 3년 걸려 만든 분류체계가 만들자마자 낡는 이유를 다음 편에서 다루겠습니다.