관리 대상 업무 이해 - 프로젝트성 업무 vs 트랜잭션 업무

DX·AIX 출발점 - 2

관리체계(管理體系)를 구축하기에 앞서 선행되어야 하는 것은 기능 목록이 아니라, 대상 업무의 속성(屬性) 파악입니다. 이 순서가 바뀌면, 우리 업무를 시스템에 맞추는 것이 아니라 시스템이 잘하는 기능에 업무를 끼워 맞추게 됩니다.
시장에는 이미 다양한 패키지(Package)가 나와 있고, 소개 자료의 기능은 대체로 훌륭합니다. 다만 그 기능이 우리 조직의 업무 속성과 부합(符合)하는지는, 소개 자료만으로는 판단할 수 없습니다.
그래서 순서가 바뀌면 안 됩니다. 기능을 먼저 보는 것이 아니라, 속성을 먼저 확인하는 것이 관리체계 구축의 출발점입니다.

우리 회사가 하는 일은 어떤 속성을 가지고 있습니까

"우리 회사는 어떤 일을 합니까"라고 물으면, 대개 업종으로 답합니다. 제약회사입니다, 부품을 만듭니다, 연구소입니다.

그런데 그 안을 들여다보면 성격이 전혀 다른 일들이 섞여 있습니다.

신약 후보물질을 찾는 일과, 매달 재무를 마감하는 일. 새 거래처를 뚫는 일과, 기존 거래처의 발주를 처리하는 일. 이 둘은 같은 회사 안에 있어도 관리되어야 하는 방식이 다릅니다.

앞선 0편에서 "관리는 비교가 아니라 갱신"이라고 했습니다. 그런데 이 말이 회사의 모든 업무에 똑같이 적용되지는 않습니다. 그러려면 먼저 업무를 나눠서 봐야 합니다.

두 가지 성격 — 프로젝트성과 트랜잭션

업무를 나누는 기준은 Plan의 유무(有無)입니다.

프로젝트성 업무는 목표(Target)를 세우고, 그 목표를 향해 가는 Plan을 갖습니다. 목표는 이번 일을 위해 의도(意圖)를 갖고 설정한 것이고, Plan은 그 목표에 도달하는 방법을 설계하는 것입니다.

트랜잭션 업무는 Plan이 없습니다. 정해진 이벤트(Event)가 발생하면, 이미 정해진 절차대로 진행됩니다. 마감일이 오면 마감을 하고, 검사 주기가 오면 검사를 합니다. 방법을 새로 설계할 필요가 없습니다.

Plan은 고정되지 않습니다

프로젝트성 업무에 Plan이 있다는 것과, 그 Plan이 고정되어 있다는 것은 다른 이야기입니다.

진행 중에 상황이 바뀌면, Plan은 다음 중 하나로 움직입니다.

트랜잭션 업무는 이런 일이 구조적으로 일어나지 않습니다. 매출 목표는 미달할 수는 있어도, "이벤트가 발생하면 절차대로 처리한다"는 방식 자체를 폐기하거나 보류하지는 않습니다.

이 차이가 0편에서 다룬 내용과 이어집니다. 계획이 비교가 아니라 갱신이어야 한다는 건, Plan을 가진 프로젝트성 업무에만 해당하는 이야기였습니다.

트랜잭션은 프로젝트성 업무의 결과를 처리합니다

두 성격은 서로 무관하게 따로 존재하지 않습니다. 프로젝트성 업무가 끝나면, 그 결과를 처리하는 트랜잭션 업무가 새로 생깁니다.

신약이 개발되면(프로젝트) 그때부터 양산과 품질관리(트랜잭션)가 시작됩니다. 신제품이 나오면(프로젝트) 그때부터 발주·생산·판매 처리(트랜잭션)가 돌아갑니다.

즉 트랜잭션 업무의 상당수는, 과거의 프로젝트성 업무가 남긴 결과물입니다. 이 연결을 보지 못하면, 지금 반복되고 있는 일이 원래 어떤 판단에서 시작되었는지를 놓치게 됩니다.

기업 전체를 훑어보면 이렇게 나뉩니다

프로젝트성 업무는 연구개발에만 있는 게 아닙니다. 조직 전체에 퍼져 있습니다.

R&D 부서만 프로젝트성 업무를 하는 게 아니라는 뜻입니다. 모든 부서가 트랜잭션 업무와 프로젝트성 업무를 동시에 갖고 있습니다.

같은 이름의 일이 둘 다 될 수 있습니다

여기서 흥미로운 지점이 하나 있습니다. 이름이 같아도, 상황에 따라 성격이 바뀝니다.

"품질검사"는 대개 트랜잭션입니다. 정해진 주기(이벤트)가 오면, 정해진 항목을 정해진 기준으로 봅니다. Plan이 필요 없습니다. 그런데 "왜 이 배치에서만 불량이 났는지 원인을 찾는다"는 순간, 이건 프로젝트성 업무로 바뀝니다. 없던 Plan이 새로 필요해집니다 — 조사 목표를 정하고, 그 목표를 향한 조사 계획을 세워야 하기 때문입니다.

이 전환이 안 보이면 문제가 생깁니다. 트랜잭션을 관리하던 방식(정해진 체크리스트, 정기 보고)을 그대로 프로젝트성 업무에 적용하면, 원인을 찾는 일이 체크리스트를 채우는 일로 축소됩니다.

왜 이 구분이 관리의 출발점이어야 합니까

0편에서 다룬 "계획은 비교가 아니라 갱신"이라는 원칙은, 사실 프로젝트성 업무에만 해당하는 이야기였습니다.

트랜잭션 업무는 애초에 목표가 흔들리지 않습니다. 이번 달 재무 마감은 다음 달에도 같은 방식으로 합니다. 여기서는 "계획대로 됐는가"를 확인하는 기존 방식이 지금도 맞습니다.

반면 프로젝트성 업무는 목표 자체가 진행 중에 흔들릴 수 있습니다. 이 업무에서는 "지켰는가"보다 "지금도 맞는 방향인가"를 계속 물어야 합니다.

즉 관리 방식을 정하기 전에, 먼저 이 업무가 어느 쪽인지부터 알아야 합니다. 구분이 안 된 채로 하나의 방식으로 관리하면, 트랜잭션에는 불필요한 논의가 붙고, 프로젝트성 업무에는 형식적인 체크만 남습니다.

정리 — 업무의 명칭이 아니라 속성이 먼저입니다

우리 회사가 하는 일을 업종 하나로 규정할 수 없는 이유가 여기 있습니다. 같은 회사 안에도 트랜잭션 업무와 프로젝트성 업무가 섞여 있고, 심지어 같은 이름의 일도 상황에 따라 성격이 바뀝니다.

그래서 "연구관리", "영업관리"처럼 업무의 명칭 하나만 보고 관리체계를 도입하면 문제가 됩니다. 그 명칭 안에는 대개 Plan이 필요한 프로젝트성 업무와, Plan 없이 이벤트로 돌아가는 트랜잭션 업무가 함께 섞여 있습니다. 이걸 하나의 방식으로 뭉뚱그려 관리하면, 트랜잭션에는 불필요한 절차가 붙고 프로젝트성 업무에는 형식적인 체크만 남습니다.

그러면 프로젝트성 업무는 구체적으로 어떤 속성들로 나뉠까요. 다음 편에서 이어가겠습니다.

관련 글

[DX·AIX 출발점 · 1편] AI시대 '관리' 재정의 — Paradigm Shift

[AI 시대의 MOT · 5편] 연구관리는 사람이 아니라 기능으로 적어야 합니다