기술경영 방법론을 적용한 기획서 — 어떻게 관리되고 있습니까

AI 시대의 MOT - 2

몇 해 만에 중장기 사업 전략을 다시 세웁니다.
먼저 이전 자료를 엽니다. 그때 무엇을 보고 이 방향을 정했는지 확인하려는 것입니다.
그런데 파일에는 결론만 있습니다.
시장 전망 수치는 적혀 있는데 어디서 온 것인지 모릅니다. 기술 우선순위는 정해져 있는데 무엇과 비교한 결과인지 없습니다. 그때 함께 검토했다가 접은 방향이 있었을 텐데, 그것도 남아 있지 않습니다.
분명히 근거가 있었을 겁니다. 자료도 봤고, 비교도 했고, 회의도 여러 번 했습니다.

기술경영 방법론에는 이런 기법들이 들어 있습니다

먼저 무엇이 있는지 보겠습니다.

몇 개는 이미 쓰고 계실 겁니다.

델파이는 전문가에게 익명으로 여러 번 물어 의견을 좁히는 방법입니다. AHP는 평가 항목을 둘씩 짝지어 비교해 가중치를 구합니다. ECV는 단계별 성공 확률을 곱해 과제의 기대 가치를 계산합니다.

하나하나가 다 쓸 만합니다. 수십 년에 걸쳐 다듬어진 것들입니다.

이 방법론은 실제로 적용되고 있습니다

여기서 흔한 오해가 하나 있습니다. 배우기만 하고 안 쓴다는 것이요.

그렇지 않습니다.

과제를 발의할 때 시장 자료를 찾습니다. 우선순위를 정할 때 평가표를 만들고 점수를 매깁니다. 심의에서는 투자 대비 회수를 따집니다. 진도 관리에는 단계를 나누고 게이트를 둡니다.

이름을 붙이지 않았을 뿐, 이미 방법론대로 일하고 있습니다. 그리고 그 결과로 기획서가 나옵니다.

그 기획서는 어디로 갑니까

기획서가 완성되면 결재를 올립니다. 심의를 통과하면 과제가 시작됩니다.

그리고 그 파일은 공유 폴더로 갑니다.

과제관리시스템에는 과제명과 기간과 예산이 등록됩니다. 기획서는 첨부 파일로 붙습니다.

그것으로 끝입니다.

그 기획서가 어떤 시장 전망 위에서 만들어졌는지는 어디에도 항목으로 없습니다
우선순위를 정할 때 쓴 가중치가 무엇이었는지 남지 않습니다
함께 올라왔다가 떨어진 것들이 왜 떨어졌는지는 심의 회의록에도 대개 없습니다

남는 것은 통과한 것의 결론뿐입니다.

적용하는 것도 사람, 챙기는 것도 사람입니다

왜 이렇게 되는지 보면, 기법들의 공통점이 하나 보입니다.

전부 사람이 수행합니다.

델파이를 돌리려면 누군가 전문가 명단을 만들고 설문을 보내고 결과를 정리해야 합니다. 로드맵을 그리려면 워크숍을 잡고 자료를 준비해야 합니다. 평가표는 담당자가 만듭니다.

방법론 자체에는 "이걸 하라"가 없습니다. 사람이 판단해서 시작해야 움직입니다.

그래서 그 사람이 바쁘면 안 하고, 바뀌면 멈춥니다.

결과물은 문서로 나옵니다

두 번째 공통점이 더 중요합니다.

방법론의 산출물을 떠올려 보십시오. 전부 문서입니다. 로드맵 한 장, 포트폴리오 매트릭스 한 장, 평가표 한 장, 기획서 한 부.

문서는 만들어진 순간의 사진입니다. 그때의 판단이 그 형태로 굳습니다.

그리고 문서에는 세 가지 성질이 있습니다.

완성되면 닫힙니다. 내용을 고치려면 새 버전을 만들어야 합니다. 그래서 한 번 결재가 끝난 문서는 대개 그대로 둡니다.

항목끼리 연결되지 않습니다. 로드맵에 적힌 기술과 평가표에 적힌 항목이 같은 것을 가리켜도, 두 파일은 서로를 모릅니다. 사람이 읽고 머릿속에서 이어야 합니다.

읽어야 압니다. 어디에 있는지 알아야 열 수 있고, 열어야 무엇이 적혀 있는지 알 수 있습니다.

이것도 이상한 일이 아니었습니다. 보고하고 승인받는 데는 문서가 맞습니다. 사람이 읽고 결정하는 것이니까요.

다만 보고가 끝난 뒤에도 그 내용이 쓰이려면, 문서가 아닌 다른 형태가 하나 더 있어야 합니다.

그래서 처음부터 다시 합니다

이 두 가지가 겹치면 앞의 장면이 나옵니다.

이전 기획서에는 결론만 있습니다. 그 결론이 어떤 전망 위에 서 있었는지, 무엇과 비교해서 그 순서가 나왔는지는 그것을 만든 사람의 머릿속에 있었습니다.

그 사람은 다른 일을 하고 있거나, 회사에 없습니다.

그래서 이번 전략을 세울 때 이전 것을 참고 자료로만 씁니다. 양식은 가져오고 내용은 다시 만듭니다.

시장 자료를 다시 찾고, 평가표를 다시 짭니다. 그때 했던 일을 다시 합니다.

방법론은 다시 돌아갑니다. 그런데 쌓이지는 않습니다.

다시 하는 시점도 대개 정해져 있습니다. 연말이거나, 몇 해에 한 번이거나. 왜 그 시점인지는 뒤에서 따로 보겠습니다.

방법론에 원인이 있는 것이 아닙니다

여기까지 보면 방향이 정해집니다.

델파이를 더 잘 돌리는 법을 배운다고 이 문제가 풀리지 않습니다. 평가표를 더 정교하게 만들어도 마찬가지입니다.

방법론은 충분합니다. 없는 것은 그 결과물이 관리될 수 있는 형태로 남지 않는다는 것입니다.

파일은 남습니다. 그런데 파일은 사람이 찾아서 열어봐야 하는 물건입니다.

그래야 다음에 그 위에서 시작할 수 있습니다.

다음 편에서 볼 것

그런데 왜 그런 항목을 만들지 않았을까요.

만들 줄 몰라서는 아닙니다. 회계도 생산도 그런 항목을 갖고 있으니까요.

다음 편에서는 조금 다른 데를 보겠습니다. 연구과제가 실패하면 누가 책임지는가, 그리고 그 책임 구조가 기획서에 무엇을 적게 만드는가입니다.

관련 글

[AI 시대의 MOT · 0편] 기술경영은 왜 시스템으로 남지 않습니까 — 사람이 수행한다는 전제 위에서

[이론과 현장] 법인의 기억은 어디에 있습니까 — 디지털 엔터프라이즈

[이론과 현장] 기업의 지식이란 무엇입니까 — 암묵지를 형식지로 바꾸려다 실패한 뒤