PI만으로는 부족합니다 — 시스템 도입 전에 정할 것들

현장의 질문들 - 30

시스템을 만들기 전에 업무를 정리해야 한다는 이야기를 자주 듣습니다. 흔히 PI라고 부릅니다.
맞는 말입니다. 다만 PI는 "어떻게 할지"를 정하는 일입니다.
그 앞에 "무엇을, 왜"가 있어야 합니다.
무엇을 시스템으로 할 것인가. 그 업무에서 무엇을 관리할 것인가. 이것이 정해지지 않은 채 흐름부터 그리면, 그린 것을 나중에 다시 그리게 됩니다.
그리고 PI가 다루지 않는 일도 따로 있습니다.
그것들이 빠지면 구축 단계에서 뒤늦게 나옵니다. 그때 나오면 일정이 밀리거나, 급하게 정하고 넘어가게 됩니다.

1단계: 대상 업무를 정합니다

무엇을 시스템으로 할 것인지부터 정해야 합니다.
당연해 보이는데, 실제로는 "연구 업무 전반" 정도로 시작하는 경우가 많습니다. 그러면 범위가 계속 늘어납니다.

그리고 성격이 다른 둘을 갈라야 합니다

가르는 기준은 하나입니다. 계획이 있는가.

트랜잭션 업무에는 계획이 없습니다. 계약이 들어오면 처리하고, 지급이 발생하면 기록합니다. 일이 생기면 정해진 대로 합니다.

프로젝트성 업무에는 계획이 있습니다. 무엇을 언제까지 어떻게 할지를 먼저 정하고, 그것과 실제를 비교합니다.

시험 의뢰를 접수하고 결과를 회신하는 일은 전자입니다. 과제를 기획하고 수행하는 일은 후자입니다.

목표가 있는 것과 계획이 있는 것은 다릅니다

여기서 자주 헷갈립니다. 매출 목표, 생산 목표가 있으니 그것도 계획이 아니냐는 것입니다.

아닙니다.

목표는 "얼마"만 말합니다. 어떻게 갈지는 들어 있지 않습니다.

계획은 경로입니다. 무엇을 언제 어떤 순서로 할지가 들어 있고, 그래서 상황이 바뀌면 바뀝니다.

매출이 미달이면 더 팔라고 합니다. 목표를 다시 짜지 않습니다. 과제 계획이 안 맞으면 계획을 다시 짭니다.

둘을 같은 방식으로 정리하면 어긋납니다

절차를 정하는 방식으로 프로젝트를 다루면 매번 예외가 됩니다. 반대로 계획 대비 실적으로 트랜잭션을 다루면 관리할 계획이 없습니다.

그래서 이 구분이 먼저입니다. 여기서 갈라 두지 않으면 뒤의 작업이 전부 섞입니다.

그리고 밖에서 들어오는 정보를 다루는 일도 대상이 될 수 있습니다. 시장과 규제와 경쟁을 파악해 계획에 반영하는 일입니다. 다만 이건 성격이 또 달라서 따로 다루겠습니다.

2단계: 무엇을 관리할지 정합니다

대상이 정해지면 그다음은 관리 내용입니다.
이 업무에서 무엇을 남기고 무엇을 볼 것인가. 일정인지, 산출물인지, 판단인지.

이것이 활동 정의의 바탕이 됩니다

무엇을 관리할지가 정해져야 활동이 나옵니다.

과제를 수행하려면 반드시 거치는 일들이 있습니다. 배합을 설계하고, 시험하고, 안정성을 보고, 규제를 확인합니다. 그것들을 어느 크기로 자를지가 여기서 정해집니다.

그리고 활동이 정해져야 템플릿도, 확인 항목도, 지난 사례 참조도 가능해집니다.

이걸 건너뛰고 화면부터 만들면, 나중에 활동을 정할 자리가 없습니다.

PI의 성격이 달라집니다

여기서부터가 흔히 말하는 PI입니다. 현재 방식을 그리고, 바꿀 것을 정하고, 새 방식을 설계합니다.

다만 앞의 두 단계를 거치면 이 일의 성격이 달라집니다.

짧아지는 것이 아니라 다른 일이 됩니다.

PI가 다루지 않는 두 가지

그리고 PI 뒤에도 빠지는 것이 있습니다.
PI는 프로세스를 봅니다. 누가 무엇을 어떤 순서로 하는가. 그런데 시스템이 돌려면 그것만으로는 안 됩니다.

쓰기 전에 정해 두어야 하는 것들

흐름을 아무리 잘 그려도, 그 안에서 만들어지는 자료를 어떻게 다룰지는 나오지 않습니다.

넷 다 성격이 같습니다. 쓰기 전에 정해 두어야 하고, 나중에 못 붙입니다.

이것이 지식이 쌓이는 그릇입니다

자료를 시스템에 넣는 것과 쌓이는 것은 다릅니다.

분류가 있어야 찾을 수 있고, 마스터가 있어야 같은 것이 같은 이름으로 남습니다. 그래야 나중에 꺼내 쓸 수 있습니다.

이것이 없으면 넣어두는 것이지 쌓이는 것이 아닙니다.

정해진 항목에 값을 넣는 것과는 다릅니다. 항목은 화면을 만들 때 정하면 되지만, 자료를 어떻게 나눌지는 미리 정해 두지 않으면 안 됩니다.

이미 쌓인 것에 소급하려면 하나씩 다시 열어봐야 합니다.

기존 자료를 어디까지 옮길 것인가

새 시스템을 열면 그날부터 시작하는 것이 아닙니다.

지금까지의 자료가 있고, 그것을 어디까지 옮길지 정해야 합니다. 전부 옮기면 정리되지 않은 것이 그대로 들어오고, 안 옮기면 과거를 볼 수 없습니다.

둘 다 PI 보고서에는 없는데, 구축할 때 반드시 나옵니다. 그리고 그때 나오면 급하게 정하게 됩니다.

결과물은 사용자가 볼 수 있어야 합니다

PI 결과물은 대개 문서입니다. 현재 방식도, 새 방식도, 개선 과제도 문서로 나옵니다.

그런데 그것은 PI를 수행한 사람의 결과물입니다.

사용자는 프로세스도를 봐도 잘 모릅니다

그려 놓은 화살표가 자기 업무에서 무엇을 뜻하는지, 매일 하는 그 일이 어떻게 달라지는지가 안 보입니다.

그래서 검토 회의에서는 고개를 끄덕이고, 시스템이 나온 뒤에 "이게 아닌데"가 나옵니다.

보이면 압니다

화면을 보면 자기 일이 보입니다. 어디에 무엇을 넣어야 하는지, 지금보다 나은지 아닌지.

다 만들고 나서 알게 되는 것을, 만들기 전에 보는 것입니다. 문서로 합의하고 나중에 만드는 것이 아니라, 만들어 보면서 합의합니다.

결과물의 형태가 달라지는 것입니다.

PI를 다시 정의합니다

PI가 프로세스 개선으로 정의된 데는 이유가 있습니다.
그때 시스템이 담던 것이 트랜잭션 업무였기 때문입니다. 회계, 구매, 급여, 재고. 결재 흐름을 전자화하고 절차를 표준화하는 일이었습니다.

트랜잭션 업무에서는 앞의 논의가 필요 없었습니다

트랜잭션 업무는 절차가 이미 정해져 있습니다. 그러면 그 절차를 그리고 다듬으면 됩니다.

프로세스 개선이라는 정의가 정확히 맞는 대상이었습니다.

그리고 앞에서 말씀드린 것들이 그때는 필요하지 않았습니다.

그때는 그 방식이 맞았습니다. 대상이 달랐기 때문입니다.

지금은 프로젝트성 업무가 들어왔습니다

관리 대상이 넓어졌습니다.

PI는 왼쪽 열을 대상으로 만들어졌습니다. 계획이 없으니 절차만 그리면 됐고, 정량이니 항목만 정하면 됐습니다.

오른쪽은 다릅니다.

계획이 있으니 그 계획이 바뀝니다. 큰 흐름은 있는데 그 안이 정해지지 않습니다. 그리고 관리해야 할 것은 그 안입니다. 무엇을 시도했고, 왜 그렇게 정했고, 무엇이 나왔는지.

흐름을 그려도 그 안은 채워지지 않습니다.

그리고 나오는 정보가 정성입니다. 정량 정보는 항목을 정하면 끝나는데, 정성 정보는 무엇을 어느 단위로 남기고 나중에 어떻게 찾을지가 함께 정해져야 합니다.

그러면 정의도 따라가야 합니다.

그러면 세 가지가 들어갑니다

흐름은 그 안에 포함됩니다. 다만 흐름만으로는 안 됩니다.

앞에서 말씀드린 것들이 전부 여기에 들어갑니다. 대상을 가르는 일도, 관리 내용을 정하는 일도, 분류체계도, 기존 자료를 어디까지 옮길지도.

따로 붙는 일이 아니라 원래 한 일입니다.

관련 글

[현장의 질문들] 전자연구노트 구축 절차와 준비할 것
[현장의 질문들] 시스템을 도입했는데 아무도 안 씁니다
[현장의 질문들] R&D 과제 계획의 단위 — 무엇을 온톨로지의 클래스로 잡을 것인가