일단 구축했는데, 6개월 뒤에 조회해보니 아무것도 안 나옵니다

구축의 순서 - 5

"일단 시작하고 나중에 정리하죠"

구축 착수 회의에서 자주 나오는 말입니다.
맞는 말처럼 들립니다. 완벽하게 준비하고 시작하려다 1년을 보내느니, 일단 쓰면서 다듬자는 것이죠. 실제로 이 판단으로 시작한 프로젝트가 많습니다.
6개월이 지납니다. 데이터가 꽤 쌓였습니다. 이제 조회를 해봅니다.
아무것도 안 나옵니다.
같은 기술을 누구는 이렇게 적고 누구는 저렇게 적었습니다. 부서명은 옛날 이름과 지금 이름이 섞여 있습니다. 과제 분류는 사람마다 기준이 다릅니다. 데이터는 쌓였는데 묶이지 않습니다.

PI 단계에서 가장 먼저 밀리는 것

시스템을 만들기 전에 대개 PI 단계를 거칩니다. 프로세스를 다시 보고 앞으로 어떻게 일할지를 정하는 단계입니다.

여기서 하는 일을 세어보면 대체로 이렇습니다. 현행 프로세스 분석, 개선안 설계, 요건 정의, 화면 구성.

마스터는 대개 뒤로 밀립니다. 데이터니까 나중에 넣으면 된다고 생각합니다. 그리고 실제로 재미도 없습니다. 코드 목록을 만드는 일은 프로세스를 그리는 일보다 눈에 안 띕니다.

그런데 마스터는 데이터가 아니라 구조입니다.

무엇을 무엇이라 부를지, 무엇을 어떤 축으로 나눌지가 정해져야 화면이 나옵니다. 입력란에 무엇을 넣을지, 선택지에 무엇을 띄울지가 다 마스터에서 옵니다.

마스터를 뒤로 미루면 화면부터 다시 그리게 됩니다. 순서가 반대여서 생기는 재작업입니다.

무엇이 기초 마스터인가

목록은 생각보다 길지 않습니다.

앞선 글들에서 하나씩 다룬 것들입니다. 2편에서 단위기능을 골랐고, 3편에서 용어와 분류를 정했습니다.

이것들이 정해져 있어야 입력이 선택이 됩니다. 안 정해져 있으면 자유 입력이 되고, 자유 입력은 사람마다 다르게 적히고, 다르게 적힌 것은 묶이지 않습니다.

어디까지 갖추면 시작할 수 있나

그렇다고 전부 완벽하게 갖추고 시작할 수는 없습니다. 항목마다 기준이 다릅니다.

두 항목만 짚겠습니다.

조직·사용자는 전부 있어야 합니다. 누가 검토하고 누가 승인하는지가 안 정해지면 아무것도 굴러가지 않습니다. 여기는 예외가 없습니다.

표준분류는 지금 도출 가능한 만큼 다 만듭니다. 부분만 만들면 다음 대상을 넣을 때마다 손보게 되고, 그때마다 앞서 만든 것과 기준이 맞는지 다시 봐야 합니다. 분류를 여러 번 만드는 셈이 됩니다. 축 하나를 반만 만들 수는 없습니다.

다만 "도출 가능한 만큼"입니다. 회사가 아직 다루지 않는 기술까지 미리 넣을 필요는 없습니다. 모르는 것은 못 만들고, 그건 나중에 갱신 경로로 들어옵니다. 지난 글에서 본 그 경로입니다.

전사에서 관리하고, 모든 시스템이 가져다 씁니다

여기서 한 가지 짚고 갈 것이 있습니다. 기초 마스터는 개별 시스템의 것이 아닙니다.

지금 대부분의 회사에서는 시스템마다 자기 코드를 갖고 있습니다. ERP에 품목 코드가 있고, PLM에 제품 분류가 있고, 연구 쪽에는 또 다른 것이 있습니다. 같은 것을 시스템마다 다르게 부르고 있습니다.

지난 글에서 본 부서 사일로가 시스템 층에서 반복되는 것입니다. 그리고 이 상태로는 시스템 간에 데이터가 오가도 이어지지 않습니다.

그래서 기초 마스터는 전사 차원에서 관리하고, 모든 시스템이 그것을 가져다 씁니다.

부서가 관리하면 조직개편 때 사라집니다. 특정 시스템이 관리하면 그 시스템의 사정에 맞춰집니다. 어느 쪽에도 매이지 않은 자리가 필요합니다.

이것을 거버넌스라고 부릅니다. 누가 만들고 누가 승인하고 언제 검토하는지를 정해두는 일인데, 세부는 회사마다 다릅니다. 다만 그 자리가 있어야 한다는 것은 어느 회사나 같습니다.

좁히되, 팀이나 과제로 좁히지 않습니다

마스터 체계가 갖춰져 있다면 적용 범위는 좁혀도 됩니다. 오히려 좁게 시작하는 편이 낫습니다.

다만 무엇을 기준으로 좁히느냐가 중요합니다.

흔히 한 팀부터, 또는 한 과제부터 하자고 합니다. 그러면 반쪽만 남습니다.

하나의 결정에는 여러 부서가 걸립니다. 제제팀만 쓰기로 하면, 품질이나 생산의 검토의견이 들어올 자리가 없습니다. 2편에서 검토 기능을 세운 이유가 그건데, 팀으로 좁히면 그게 무의미해집니다.

과제 단위도 비슷합니다. 그 과제가 끝나면 무엇이 남는지가 애매해집니다. 다음 과제로 넘어갈 때 규칙을 또 만들게 되고요.

의사결정 유형으로 좁힙니다.

2편에서 이력이 남아야 할 결정들을 골랐습니다. 그중에서 먼저 담을 것을 정합니다. 단계 진입 심의부터 할 수도 있고, 위탁처 선정부터 할 수도 있고, 회차 판정부터 할 수도 있습니다.

하나의 유형을 정하면, 그 유형은 회사 전체에서 같은 방식으로 기록됩니다. 어느 팀이 하든, 어느 과제에서 나오든 같습니다. 검토의견도 필요한 부서에서 다 들어옵니다.

어느 유형부터 시작할지는 회사마다 다릅니다. 1편에서 본 사업모델이 그 답의 절반입니다. 결정이 드물고 무거운 회사와 잦고 가벼운 회사는 먼저 담을 것이 다릅니다.

확장할 때 늘어나는 것은 데이터뿐입니다

이게 마스터 체계를 먼저 갖추는 진짜 이유입니다.

거버넌스가 갖춰져 있으면, 나중에 확장할 때 늘어나는 것은 데이터뿐입니다.

기술 코드를 스무 개로 시작했다가 이백 개가 되어도 구조는 그대로입니다. 새 축을 하나 더해도, 축을 다루는 방식이 이미 정해져 있으니 그 규칙대로 붙이면 됩니다. 새 부서가 들어와도 조직 마스터에 한 줄 늘어날 뿐입니다.

의사결정 유형을 더하는 것도 마찬가지입니다. 단계 진입 심의로 시작했다가 위탁처 선정을 더하고, 그다음 회차 판정을 더합니다. 구조는 그대로고 유형만 늘어납니다.

반대로 거버넌스가 없으면 확장할 때마다 구조를 다시 정합니다.

이번엔 누가 승인하지, 이번엔 어떻게 나누지. 매번 처음부터 논의합니다. 그리고 그 논의는 대개 흐지부지됩니다. 급한 일이 아니니까요.

과거는 소급하지 않습니다

마지막으로 하나만 더 짚겠습니다.

마스터를 갖추고 나면 이런 이야기가 나옵니다. "그럼 지난 자료도 다 정리해서 넣어야 하나요."

넣지 않습니다.

오늘부터의 것만 넣습니다. 과거 자료는 있는 자리에 그대로 두고, 필요할 때 연결만 붙입니다.

지난 글에서 코드를 나눠도 과거를 재분류하지 않는다고 했는데, 같은 원리입니다. 과거를 정리해야 미래로 갈 수 있다는 전제를 없애야 시작이 됩니다.

그리고 실무적으로도 그렇습니다. 지난 10년치를 정리하는 데 6개월을 쓰면, 그사이 사람들의 관심이 식습니다.

정리하면

• 마스터는 데이터가 아니라 구조입니다. PI 단계에서 뒤로 밀리기 쉬운데, 밀면 화면부터 다시 그리게 됩니다.
• 표준분류는 도출 가능한 만큼 다 만듭니다. 부분만 만들면 여러 번 만들게 됩니다. 다만 모르는 것은 못 만들고, 그건 갱신 경로로 들어옵니다.
• 기초 마스터는 전사에서 관리합니다. 부서가 관리하면 조직개편 때 사라지고, 시스템이 관리하면 시스템마다 달라집니다.
• 좁히되 의사결정 유형으로 좁힙니다. 팀이나 과제로 좁히면 두껍지만 반쪽이 됩니다.
• 확장할 때 늘어나는 것은 데이터와 유형뿐입니다.
• 과거는 소급하지 않습니다.

다음 편에서는

여기까지가 시작하기 전의 이야기였습니다. 이제 실제로 굴러가야 합니다.

그런데 여기서 대부분이 한 번 더 넘어집니다. 시스템은 켜졌는데 아무도 안 쓰는 상태가 옵니다. 구축이 실패해서가 아니라, 구축 완료와 정착이 다른 문제이기 때문입니다.

왜 6개월 만에 멈추는지, 그리고 무엇이 있어야 안 멈추는지를 다음 편에서 다루겠습니다.