프로젝트 유형별 관리 - 고객이 있는 B2B 프로젝트

DX·AIX 출발점 - 5

3편까지 업무의 속성과 현재 상황을 봤습니다. 이제 그 속성을 실제 프로젝트에 적용합니다.
이 편이 다루는 프로젝트는 목표(目標)를 회사가 정하지 않습니다. 고객의 요구와 승인(承認)이 목표를 정합니다.

같은 B2B라도 관리의 무게중심은 둘로 갈립니다.

배타적이지 않습니다. 한 프로젝트가 둘 다 무거울 수 있습니다. 다만 어느 쪽이 무거운지에 따라 시스템에서 먼저 갖춰야 할 것이 달라집니다.

관리체계 준수형 — 고객사의 표준을 디지털로 옮깁니다

이 유형에서는 고객사가 프로젝트 유형별로 표준 Activity와 산출문서 체계(내부 승인 절차 포함)를 이미 정해 놓은 경우가 많습니다. 자동차 산업의 APQP가 대표적입니다.

3편에서 "현재에 맞춰 시작하라"고 한 것은, 회사가 스스로 절차를 정해야 하는 프로젝트, 곧 다음 편에서 다룰 유형에 해당합니다. 관리체계 준수형은 다릅니다. 절차와 문서 체계를 고객사가 이미 정해서 요구하므로, 회사가 새로 판단할 것이 없습니다. 그 표준을 시스템으로 옮기는 것이 시작입니다.

이 유형에서는 진도(進度)를 두 가지로 확인할 수 있습니다. Activity의 일정으로 보거나, Activity별 산출문서의 현황으로 봅니다. 어디까지 문서가 나왔고, 승인되었는지가 곧 진행 상황입니다.

문서 하나하나는 다음 생애주기(生涯週期)를 관리해야 합니다.

각 문서는 개정번호(Revision)로 관리됩니다. 어느 버전이 지금 유효한 것인지, 그리고 이전 버전에서 무엇이 왜 바뀌었는지가 함께 남아야, 나중에 문제가 생겼을 때 어느 시점의 어떤 근거로 결정되었는지를 되짚을 수 있습니다.

고객사와의 회의록도 예외가 아닙니다. 회의록은 반드시 공유되고, 해당 Activity와 연계되어 이력 조회가 가능해야 합니다. 회의에서 나온 합의가 어느 Activity, 어느 문서 버전에 반영됐는지 추적할 수 있어야 하기 때문입니다.

평가·Comment 중심형 — 기록의 부담을 나눠서 집니다

화장품·건강기능식품 ODM처럼 처방(處方) 개발이 핵심인 경우, 절차보다 고객사의 샘플 평가 이력이 중요합니다. 모든 처방의 모든 샘플 차수(次數)가 이력으로 남아야 합니다.

이때 핵심은 기록을 2단계로 나누는 것입니다.

트랜잭션 업무를 다루는 시스템은 시스템에 입력하는 것이 곧 업무 수행 그 자체입니다. 발주를 승인하는 일은 시스템에 승인을 입력하는 것과 같아서, 사용자의 업무 부담을 별도로 고려할 필요가 없습니다.

프로젝트성 업무는 다릅니다. 1편에서 다룬 대로 실제 수행(실험)과 시스템에 남기는 기록이 분리되어 있습니다. 그래서 시스템 운영 자체가 실제 업무 위에 얹히는 추가 부담이 되고, 이 부담을 반드시 고려해야 합니다.

연구원에게 고객사 수준의 상세 입력을 실험실에서 요구하면, 그 부담이 곧 gap이 되어 입력이 밀립니다. 부담을 지는 주체를 나누면, 각자에게 필요한 만큼만 요구하게 되어 이 gap이 애초에 생기지 않습니다.

두 기록은 분리되어 있지만 연결되어야 합니다. 어느 처방 차수가 어느 고객 평가와 연결되는지가 없으면, Comment를 받았을 때 어느 처방을 수정해야 하는지 되짚을 수 없기 때문입니다.

요구가 바뀌면 무엇을 남겨야 합니까

두 유형 모두, 진행 중 고객의 요구나 평가 결과가 바뀔 수 있습니다. 그때 남겨야 할 것은 같습니다.

무엇이 바뀌었는가 (이전 사양·처방과 바뀐 사양·처방)

우리가 무엇으로 대응했는가 (재설계, 재처방)

고객이 이를 승인·평가했는가 (승인 기록, Comment)

관리체계 준수형에서는 이것이 문서의 개정번호에, 평가·Comment 중심형에서는 샘플 차수의 이력에 담깁니다. 형태는 다르지만 원칙은 같습니다.

처음에는 어디부터 시작합니까

관리체계 준수형은 고객사의 표준이 이미 있으므로, 그 표준을 그대로 시스템에 옮기는 것이 출발점입니다. 새로 설계할 것이 적습니다.

평가·Comment 중심형은 다릅니다. 내부 처방 이력부터 간편하게 시작하고, 고객 평가 이력은 그다음입니다. 처음부터 둘을 한 번에, 한 화면에 담으려 하면 3편에서 경계한 "미리 넣는 욕심"이 됩니다.

두 유형 모두, 여기서 쌓인 기록이 AI가 참조할 Data가 됩니다. 문서의 개정 이력이나 평가 Comment가 쌓이면, AI가 비슷한 사례를 찾아 대응 방향을 제안하는 데 쓰일 수 있습니다. 다만 그 전에 사람이 기록을 남기는 것이 먼저입니다.

정리 — 목표는 고객에게, 기록의 형태는 유형에 따라

고객이 있는 B2B 프로젝트는 목표를 고객이 정합니다. 다만 무게중심은 절차(관리체계 준수형)일 수도, 평가(Comment 중심형)일 수도 있습니다.

전자는 고객사의 표준을 옮기는 일이고, 후자는 기록의 부담을 나누는 일입니다. 어느 쪽이든 핵심은 같습니다. 무엇이 바뀌었고, 어떻게 대응했고, 고객이 무엇을 확인했는지를 남기는 것입니다.

이 편에서 다룬 두 유형의 설계—고객사 표준을 그대로 옮기는 것, 기록을 2단계로 나누는 것—는 정해진 정답이 아닙니다. 연구원과 고객 대응 담당자가 실제로 어떻게 일하는지를 먼저 이해했기 때문에 나온 설계입니다.

프로젝트성 업무를 시스템으로 구현할 때는, 업무의 성격을 먼저 파악하고 그 실제 수행 방식에 맞춰 시스템을 맞추는 것이 중요합니다. 반대로 하면, 즉 시스템의 틀에 업무를 맞추려 하면 3편에서 다룬 gap이 생기고 시스템은 겉돕니다.

다음 편에서는 반대의 경우, 곧 회사가 스스로 목표를 정하는 개발 프로젝트를 살펴보겠습니다.

관련 글

[DX·AIX 출발점 · 1편] 관리 대상 업무 이해 - 프로젝트성 업무 vs 트랜잭션 업무

[DX·AIX 출발점 · 2편] 관리 대상 업무 이해 - 프로젝트성 업무는 어떻게 나뉩니까

[DX·AIX 출발점 · 3편] 관리 대상 업무 이해 - 성장단계, 처음 구축하는 기업