프로세스 매핑 기초: BPMN 없이 시작하기

먼저 "as-is", 그 다음 "to-be"

프로세스 매핑에 대한 가장 흔한 오해: 지도를 그리기 전에 "어떠해야 하는지"를 알아야 한다. 아닙니다. 먼저 "지금 무슨 일이 일어나고 있는지"를 알아야 합니다.

"as-is" 지도는 오늘 프로세스가 실제로 어떻게 작동하는지 보여줍니다——문서에 적힌 것이 아니라. 많은 중소기업에서 주문 접수, 청구, 고객 온보딩 프로세스가 수년째 바뀌지 않았지만 어디에도 기록되어 있지 않습니다. 이 공백이 자동화로 전환할 때 가장 큰 위험입니다: 문서화되지 않은 프로세스를 자동화하면 오류도 자동화됩니다.

도구는 복잡할 필요가 없습니다: 포스트잇, Miro 보드, 또는 Excel 4열 표로 충분합니다. BPMN을 배울 필요도, Visio를 살 필요도 없습니다.

as-is 지도가 완성되면 "to-be" 설계가 훨씬 쉬워집니다. 무엇이 변할지가 아니라 무엇이 남는지가 보입니다——최적화 결정은 직관이 아닌 실제 데이터에 근거합니다.

1시간 만에 프로세스 매핑: 4열 접근법

복잡한 도구 없이 프로세스를 매핑하려면 4열 Excel 표 또는 Miro 스트립으로 충분합니다. 각 행은 하나의 단계를 나타내며, 열은 다음과 같습니다:

1. 단계 — 무엇을 하는가? 짧은 동사형: "청구서 생성", "승인 대기", "시스템 입력". 2. 누가 하는가? 사람 이름이 아닌 역할 이름: 회계, 영업 담당자, 고객. 3. 입력은 무엇인가? 이 단계를 시작하는 데 필요한 것: 양식, 이메일, 승인, 시스템 레코드. 4. 출력은 무엇인가? 이 단계 이후 생성되는 것: 문서, 알림, 데이터베이스 레코드.

이 4열은 단순한 스윔레인 다이어그램과 유사하며 소프트웨어 지식이 필요 없습니다. 프로세스를 아는 두세 명과 포스트잇을 사용해 1시간 워킹 세션으로 전체 표를 채울 수 있습니다.

지도 완성 후 각 단계에 이 질문을 던지세요: "이 단계를 자동화할 수 있나? 제거할 수 있나? 합칠 수 있나?" 이 세 가지 질문이 불필요한 복잡성을 제거합니다.

매핑된 프로세스가 자동화 준비가 된 시점

매핑된 모든 프로세스가 자동화 준비가 된 것은 아닙니다. 자동화로 이동하기 전에 네 가지 기준을 충족해야 합니다.

1. 반복 빈도: 프로세스가 주당 최소 두세 번 반복된다면 자동화 비용이 정당화됩니다. 한 달에 한 번 하는 예외적 작업에는 자동화가 보통 불필요합니다.

2. 표준화된 입력: 프로세스를 시작하는 입력이 표준화되어 있다면——특정 이메일 형식, 폼 응답, 시스템 알림——자동화가 훨씬 안정적으로 작동합니다. 입력이 매번 다르다면 먼저 데이터 표준화 단계가 필요합니다.

3. 인간 판단의 양: 프로세스 핵심 단계에서 많은 주관적 결정이 내려진다면 해당 단계를 먼저 단순화하거나 규칙 기반으로 만들어야 합니다. 자동화는 규칙 기반 단계를 자동화할 수 있지만, 모호한 결정은 불가합니다.

4. 오류 허용도: 프로세스의 오류가 고객 손실, 법적 위반, 재정적 손해로 직결된다면 자동화 전 포괄적인 테스트가 필수입니다.

네 가지 기준을 모두 충족하는 프로세스가 자동화 준비가 가장 잘 된 것입니다.

프로세스 매핑은 첫 단계입니다. 매핑을 마친 뒤에는 디지털 전환을 어디서 시작할지와 부문별 자동화 접근법을 살펴보세요.

대부분의 팀이 건너뛰는 단계: 실무자와 직접 대화하기

프로세스 맵이 잘못되는 가장 큰 이유는 노력이 부족해서가 아니라, 엉뚱한 사람에게 물었기 때문입니다. 관리자는 프로세스가 원래 돌아가야 하는 방식대로 — 흔히 몇 년 전 설계된 그대로 — 설명합니다. 실제로 주문을 처리하고, 송장을 입력하고, 지원 티켓에 답하는 사람은 편법(workaround)이 섞인 버전을 알고 있습니다. 시스템이 한 번 오류를 낸 뒤로 추가로 하게 된 확인 작업, 공식 승인 절차가 너무 느려서 비공식적으로 구하는 두 번째 승인 같은 것들입니다. 맵이 경영진이 믿고 있는 것만 반영한다면, 존재하지도 않는 프로세스를 자동화하게 됩니다.

편법은 걸러내야 할 잡음이 아니라, 이 작업 전체에서 가장 유용한 신호입니다. 아무도 공식적으로 승인하지 않은 별도의 스프레드시트, 티켓팅 시스템 대신 사용하는 왓츠앱 그룹, 세 개 시스템에 다시 입력해야 하는 출력 양식 — 이런 것들은 하나같이 공식 프로세스가 실제 필요를 충족시키지 못한 지점을 가리킵니다. 이를 맵에 명시적으로 기록하되, 누가 왜 만들었는지도 함께 적으십시오. 대개 이는 교육 공백이나 자동화 기회, 때로는 둘 다를 곧바로 가리킵니다.

모든 예외를 맵에 담으려 하지 마십시오. 가능한 모든 분기를 담으려는 맵은 읽을 수 없게 되고 아무도 유지보수하지 않게 됩니다. 대신 주요 경로와, 의미 있을 만큼 자주 발생하는 두세 가지 예외만 담으십시오 — 누락된 서류, 거절된 결제, 제출 후 주문을 변경하는 고객 같은 것들입니다. 그보다 드문 것들은 흐름도 자체가 아니라 짧은 "알려진 예외" 메모에 담아두어야 합니다.

마지막으로, 단일 팀 내부의 단계보다 부서 간 인계(handoff)에 가장 세심하게 주목하십시오. 대부분의 프로세스는 부서 내부에서는 원활히 돌아가다가, 영업이 운영팀에, 혹은 운영팀이 재무팀에 무언가를 넘기는 바로 그 지점에서 무너집니다. 맵에 있는 모든 인계 지점에 명확한 담당자와, 양측이 생각하는 "완료"의 명시적인 기준을 표시하십시오. 이런 인계 지점이야말로 오늘날 소통 오류가 가장 많은 시간을 잡아먹는 곳이며, 실제로 구축을 시작했을 때 자동화가 가장 빠르게 성과를 내는 곳이기도 합니다.