프로세스 모델링: 어떤 방법을 어디에 쓰는지 — 그리고 각 다이어그램이 어디에서 멈추는지

프로세스 모델은 빨리 그려지지만 거의 똑같은 속도로 쓸모없어집니다. 잘못되었기 때문이 아니라 — 상자들은 대개 맞습니다. 문제는 그것이 제작된 질문에 답하지 못한다는 점입니다. 어디서 시작해야 할지 알기 위해 그리지만, 제공되는 것은 모든 단계가 똑같이 중요해 보이는 구조뿐입니다.

이 글은 두 축으로 구성됩니다. 첫째, 기법: 어떤 방법이 무엇에 적합한지, 실제로 어떤 기호가 필요한지, 적절한 범위를 어떻게 찾는지, 어떤 순서로 진행해야 하는지. 둘째, 한계: 어떤 표기법에도 적혀 있지 않지만 다이어그램만으로는 어떤 단계가 흐름을 멈추는지 알려주지 않는 네 가지 값입니다.

프로세스 모델링이란?

프로세스 모델링은 표준화된 기호로 단일 업무 프로세스를 그래픽으로 표현하는 것입니다. 네 가지 질문에 답합니다: 무엇이 흐름을 촉발하는가? 어떤 작업이 어떤 순서로 이어지는가? 어디에서 분기되고 누가 결정하는가? 무엇으로 끝나는가?

일상에서는 용어들이 뒤섞여 사용되지만 의미하는 바는 다릅니다:

프로세스랜드카르테는 도시 지도이고, 프로세스모델은 한 도로의 길 안내입니다. 둘을 한 이미지에 억지로 넣으면 프레젠테이션 뒤에 아무도 다시 보지 않는 200개의 상자가 생깁니다. 그 위 단계가 어떻게 만들어지는지는 Prozesslandkarte erstellen에 나와 있습니다.

모델의 용도:

• 온보딩: 신규 직원이 구두 설명 대신 흐름을 볼 수 있습니다
• 감사 및 인증: ISO 9001은 어쨌든 이 구조를 요구합니다
• 시스템 전환: 소프트웨어가 구현하기 전에 무엇을 그려야 하는지
• 인수인계: 작업이 책임을 넘기는 지점들
• 예외사항: 어디에도 적혀 있지 않아 각자 다르게 처리하는 경우들

모델이 적합하지 않은 경우:

• 우선순위 매기기. 모든 상자가 동일하게 보입니다.
• 작업량 추정. 한 단계가 10분일 수도, 4일일 수도 있습니다.
• 용량 계획. 프로세스가 얼마나 자주 실행되는지는 다이어그램에 없습니다.

As-is와 To-be: 먼저 존재하는 것을 그리세요

프로세스 모델링에는 두 가지 모델 유형이 있습니다. As-is-Modell은 현재 상태를 보여줍니다: 오늘 실제로 흐름이 어떻게 진행되는지. 군더더기, 재작업, 공식적으로 존재하지 않는 Excel 파일도 포함됩니다. To-be-Modell은 변경 후의 목표 상태를 보여줍니다.

순서는 협상의 여지가 없습니다: 먼저 As-is, 그다음 To-be. 목표부터 시작하면 알지 못하는 흐름을 최적화하는 셈입니다.

그러나 대부분의 안내서가 생략하는 세 번째 단계가 그 사이에 들어갑니다: 측정입니다. As-is에서 바로 나온 To-be는 희망 목록에 불과합니다. 워크숍에서 가장 크게 논의된 단계를 개선할 뿐인데, 그것이 흐름을 멈추는 단계일 가능성은 드뭅니다. 큰 소리로 논의되는 단계는 불쾌한 단계이고, 비싼 단계는 조용히 일이 멈추는 지점입니다.

실용 규칙: To-be 모델은 정확히 하나의 단계에 대해 만들어집니다. 그 단계는 측정이 지목한 단계입니다. 나머지는 당분간 그대로 둡니다.

프로세스 모델링: 방법 개요

Flussdiagramm

가장 단순한 형태: 시작, 작업, 결정의 다이아몬드, 끝. 누구나 별도 교육 없이 이해할 수 있어 그 가치가 있습니다. 여러 역할이 관여하면 한계가 드러납니다 — 그때는 책임이 상자 내부의 텍스트로만 남아, 시간이 손실되는 인수지점이 사라집니다.

Swimlane-Diagramm

동일한 흐름이지만 각 역할에 레인을 할당합니다. 장점은 미려함이 아니라 명확한 정보입니다: 레인을 벗어나는 모든 화살표는 인수인계입니다. 인수인계는 아무도 책임을 지지 않거나 아무도 시작하지 않아 작업이 멈추는 지점입니다. 여러 부서를 넘는 흐름에는 Swimlane이 표준 선택입니다.

BPMN 2.0

Object Management Group의 국제 표준으로 약 150개의 기호, 기계 판독 가능. 강점은 명확성입니다: BPMN 모델은 내보내고, 검증하고, 프로세스 엔진으로 실행할 수 있습니다. 약점은 학습 곡선 — 실무자 측에서는 자발적으로 읽지 않는 경우가 많습니다.

모델이 실행되거나 외부 검증을 받거나 수년간 유지보수될 경우 BPMN을 사용하세요. 명성을 위해 쓰지 마세요. 부서가 교차검토한 깔끔한 Swimlane 다이어그램은 아무도 열어보지 않는 정확한 BPMN 모델보다 더 가치가 있습니다.

EPK와 eEPK

이벤트-기반 프로세스 체인은 이벤트("Anfrage ist eingegangen")와 기능("Anfrage erfassen")이 엄격히 교대로 이어지며, AND/OR/XOR 연결자를 사용합니다. 독일어권에서는 ARIS로 널리 사용됩니다. 확장된 EPK는 각 기능에 조직 단위와 정보 객체를 추가합니다 — 즉 누가 어떤 것으로 단계를 수행하는지 표기합니다.

강점이자 약점인 강제된 교대는 유발자(트리거)를 말하게 만들지만 모델을 두 배로 길게 만듭니다. 내부에 이미 EPK 자산이 있다면 유의미합니다. 새로운 모델을 새로 시작하는 경우는 드뭅니다.

SIPOC

다섯 칸: 공급자, 입력, 프로세스, 출력, 고객. 흐름도는 아니고 범위를 정하는 도구입니다. 한 시간 안에 작성되며 대다수 모델링이 실패하는 질문을 해소합니다: 프로세스는 어디서 시작하고 어디서 끝나는가? 프로세스 부분은 의도적으로 거칠게 — 5~7 블록으로 유지합니다.

Wertstromanalyse

린 관리에서 나왔습니다. 자재와 정보 흐름을 그리며 각 단계에 수치(처리시간, 대기시간, 재고, 결함률)를 기입합니다. 따라서 고전적 방법 중 유일하게 본질적으로 정량적입니다. 제조가 주된 대상이며, 사무 프로세스에서는 재고가 이메일함의 대기열이 되어 적용이 더 번거롭지만 불가능하지 않습니다.

Wertschöpfungskette와 Detailmodell

같은 스펙트럼의 양끝입니다. Wertschöpfungskette는 내부가 비어 있는 5~9 블록을 보여주어 경영진과 외부용으로 적절합니다. Detailmodell은 하위 프로세스, 예외, 시스템을 포함해 모든 단계를 보여주어 IT 인수인계용입니다. 둘 다 정당합니다. 한 다이어그램에 두 세부도가 섞이면 무용해집니다: 영업에 대해 세 상자, 그다음 승인 절차에 14상자처럼요.

어떤 방법을 선택할까? 세 가지 질문

1. 여러 역할이나 부서가 관련되어 있나요? 예 → Swimlane. 아니요 → Flussdiagramm.
2. 모델을 나중에 실행·내보내기·외부검증할 예정인가요? 예 → BPMN 2.0.
3. 자재·재고·대기시간이 문제인가요? 예 → Wertstromanalyse.

범위가 불명확하면 먼저 SIPOC를 하십시오. 나머지는 취향 문제이며, 표기법 선택은 모델을 읽는 사람들이 공유하지 않을 수 있어 나쁜 조언입니다.

프로세스 모델링 기호

일반 기호는 플로우차트 전통에서 유래하며 도구 간에 대체로 동일합니다:

• 타원(종결자): 프로세스의 시작과 끝
• 사각형: 작업 또는 활동
• 다이아몬드: 결정, 출구에 라벨이 붙음
• 화살표: 흐름의 방향
• 양옆이 두꺼운 사각형: 다른 곳에 모델링된 하위프로세스
• 평행사변형: 입력 또는 출력으로서의 데이터
• 밑면이 물결 모양인 사각형: 문서
• D형(반원형): 지연, 즉 대기시간
• 윗면이 비스듬한 사각형: 수동 입력 — 실제로는 매체 단절의 가장 신뢰할 수 있는 표시

BPMN에서는 주요 다섯 가지를 이렇게 부릅니다: 시작 이벤트(얇은 원), 작업(모서리가 둥근 사각형), 배타적 게이트웨이(X가 있는 다이아몬드), 시퀀스 흐름(실선 화살표), 종료 이벤트(굵은 원). 대부분의 흐름은 이들로 표현할 수 있습니다.

두 가지 규칙이 기호 목록보다 더 중요합니다: 모든 다이아몬드에는 라벨이 붙은 출구가 있어야 합니다 — "ja"/"nein" 또는 조건. 그리고: 모든 경로는 끝나야 합니다. 빈 곳으로 빠지는 분기는 다이어그램에서 미적 결함이고 현실에서는 결코 완료되지 않는 작업입니다.

프로세스 모델링: 여섯 단계

1단계: 경계 설정

무엇이 프로세스를 시작하는가(트리거)와 무엇이 끝나는가(결과)를 서면으로 두 문장만 적으세요. 이것 없이 시작하면 작업 중 모델이 계속 확장됩니다 — 모든 대화가 앞뒤로 무언가를 덧붙입니다. 이 때문에 2일이면 될 모델링이 3주가 되곤 합니다.

2단계: 작업을 수행하는 사람들로부터 단계 수집

책임자에게 묻지 마십시오. 그들은 목표 흐름을 알고 있습니다. 실제와 목표의 차이가 바로 찾고자 하는 것입니다. 현장에서 반드시 묻는 다섯 질문:

• 어떤 일이 이 작업을 촉발하며, 어떻게 알 수 있나요?
• 시작하기 위해 무엇이 필요하고 그것은 어디서 오나요?
• 가장 자주 무엇을 기다리나요?
• 무언가가 없거나 시스템이 동작하지 않으면 무엇을 하나요?
• 지침과 다르게 여기서 무엇을 다르게 하나요 — 그리고 그 이유는?

3단계: 세분화 수준 결정

범위를 결정하는 규칙: 하나의 단계는 한 역할이 한 번에 한 번에 시스템에서 완료하는 작업 조각입니다. 역할이 바뀌거나 시스템이 바뀌거나 작업이 중단되면 새 단계가 시작됩니다.

일반 비즈니스 프로세스에서는 보통 8~15단계가 나옵니다. 50단계가 나오면 키 입력까지 모델링하는 것입니다. 4단계 정도 나오면 부서를 모델링하는 것입니다.

4단계: 그리기

위의 세 질문으로 방법을 정한 뒤 예외 없이 첫 번째 흐름을 그립니다: 왼쪽에서 오른쪽으로의 정상 흐름. 그다음 분기들을 추가하되 모두는 아닙니다. 일반적으로 프로세스의 약 1/3이 예외이며 그 중 2~3개 정도의 빈번한 예외만 모델링합니다. 나머지는 옆에 텍스트로 둡니다.

5단계: 교차검토 받기

완성된 다이어그램을 2단계에서 참여한 동일한 사람들에게 되돌려 보내 한 가지 질문만 하세요: "어디가 틀렸나요?" "괜찮나요?"라고 묻지 마십시오 — 그 질문에는 모두가 예라고 대답합니다. 경험상 2~4곳이 수정되고 그중 적어도 하나는 사소하지 않습니다.

6단계: 숫자 붙이기

대부분 안내서에서 빠지는 단계이며 이 단계 없이는 모델이 장식에 머물러 있습니다. 단계마다 네 가지 수치를, 필요하면 추정치로 적으세요:

• 기간(범위): 낙관적, 전형적, 비관적 — 평균이 아님
• 그 앞의 대기시간: 누군가 시작하기 전에 얼마나 오래 작업이 쌓이는가
• 빈도: 한 달에 그 단계가 몇 번 실행되는지, 예외 비율 포함
• 역할과 시스템, 추가로: 매체 단절 여부(예/아니오)

왜 평균 대신 범위를 쓰나: 평균값을 프로세스 체인에 넣으면 루프, 분기, 공유 처리자가 있으면 체계적으로 너무 낙관적으로 계산됩니다. 자세한 설명은 Ihr Excel rechnet richtig und liegt trotzdem falsch에 있습니다.

예시: 견적 프로세스 모델

다음 모델은 당사의 샘플 분석 AN-2026-01에서 온 것입니다. 고객에서 수집한 것이 아니라 구성된 예시입니다 — 구조는 전형적인 중견기업 흐름을 본떠 만들었고 수치는 500회 시뮬레이션에서 나왔습니다. 여기서 중요한 것은 그림과 측정의 차이가 방법의 속성이지 영업 비밀이 아니라는 점입니다.

Swimlane, 6단계, 4역할:

                 ┌────────────┐                              ┌──────────────┐
Innendienst   ●──│ 01 Anfrage │                              │ 05 Angebot   │──▶ ● 
                 │  erfassen  │                              │   schreiben  │
                 └─────┬──────┘                              └──────▲───────┘
                       │                                            │
                 ┌─────▼──────┐                                     │
Konstruktion     │ 02 Techn.  │                                     │
                 │  Klärung   │                                     │
                 └─────┬──────┘                                     │
                       │                                            │
                 ┌─────▼──────┐   ┌───────────┐   nein     ┌────────┴────┐
Kalkulation      │ 03 Kalku-  │──▶│ 04 Frei-  │───────────▶│ Rückfrage   │
                 │   lation   │   │   gabe?   │            │ (Ausnahme)  │
                 └────────────┘   └─────┬─────┘            └─────────────┘
                                        │ ja
                                        ▼
Vertrieb                          06 Versand & Nachfassen ──▶ ●

다이어그램은 정확합니다. 누가 어떤 순서로 무엇을 하는지 보여주고, 세 가지 매체 단절(E-Mail, Excel, Word)을 나타냅니다. 답하지 않는 것은: 이 여섯 단계 중 어느 단계가 흐름을 멈추는가?

그래픽적으로는 여섯 단계가 모두 동일하게 보입니다. 계산상은 그렇지 않습니다:

{
  "caption": "Auslastung je Rolle im Ist-Zustand. Musteranalyse AN-2026-01, konstruiert, 500 simulierte Durchläufe",
  "unit": "%",
  "data": [
    { "label": "Konstruktion", "value": 118, "tone": "critical" },
    { "label": "Kalkulation", "value": 86 },
    { "label": "Vertriebsinnendienst", "value": 74 },
    { "label": "Vertriebsleitung", "value": 41 }
  ]
}

어떤 역할의 부하가 100퍼센트를 넘습니다 — 처리할 것보다 더 많은 작업이 들어오고 있어 그 단계 앞에 대기열이 쌓입니다. 모델에서는 이 역할이 네 개 레인 중 하나로 동등하게 보입니다(Vertriebsleitung은 41% 가동률).

그에 따라 통과시간은 숫자가 아니라 범위입니다:

[
  { "label": "Durchlaufzeit P10", "value": "1,8", "unit": "Tage", "note": "der schnelle Fall" },
  { "label": "Durchlaufzeit P50", "value": "4,6", "unit": "Tage", "note": "der typische Fall" },
  { "label": "Durchlaufzeit P90", "value": "11,2", "unit": "Tage", "tone": "critical", "note": "was zusagbar wäre" },
  { "label": "Läufe über Kapazität", "value": "34", "unit": "%", "tone": "critical" }
]

전형적 경우와 약속 가능한 경우 사이에 두 배 차이가 있습니다. 어떤 다이어그램에서도, 표기법에 상관없이 이 차이는 보이지 않습니다. 전체 샘플 분석의 전후 비교는 Der Angebotsprozess, der in der Konstruktion liegen bleibt에서 확인하세요.

어떤 표기법에도 적혀 있지 않은 네 가지 수치

모델이 병목을 보여주지 못하는 현실적인 이유는 표기법이 구조를 설명할 뿐 부하를 설명하지 않기 때문입니다. 계산을 위해서는 BPMN이나 EPK에도 없는 네 가지 값이 필요합니다:

1. 도착률(Ankunftsrate) — 프로세스가 얼마나 자주 촉발되는지, 그리고 얼마나 불균형하게 발생하는지. 주당 40건은 월~금 고르게 오는 40건과 다릅니다.
2. 시간의 분산(Streuung der Dauern) — "2시간"이 아니라 "1~4시간, 보통 2시간" 같은 범위. 분산이 없으면 대기열이 생기지 않아 계산이 지나치게 낙관적입니다.
3. 용량(Kapazität) — 실제로 그 단계를 처리할 수 있는 인원수와 그들의 근무시간 비율. 다이어그램의 한 레인은 한 사람일 수도, 여덟 사람일 수도 있습니다.
4. 달력(Calendar) — 근무시간, 휴가, 특정 요일에만 승인되는 업무 등. 계산상 3시간 걸리는 흐름도 야간을 넘기면 하루가 소요됩니다.

이 네 값은 모델링 중, 위의 6단계 중 6단계에서 직접 수집하는 것이 가장 좋습니다. 도형에서 계산으로 넘어가는 지점이자 모델이 실질적 조치로 이어질지 장식에 그칠지를 결정하는 순간입니다.

흔한 실수

1. 너무 세밀하게 모델링함. 프로세스에 200개의 상자. 해결책: 3단계 규칙 — 역할, 시스템, 한 번에 완료되는 작업.

2. 목표(Soll)를 그렸지 실제(Ist)를 그리지 않음. 모델에 재작업이 없다면 이런 경우입니다. 실제 흐름에는 항상 재작업이 존재합니다.

3. 관리자와만 이야기함. 공식 절차만 나오며 실제와의 차이가 사라집니다. 그 차이가 전체 작업의 성과입니다.

4. 체면 때문에 표기법 선택. BPMN을 전문적으로 보인다고 선택하면 아무도 교차검토하지 않습니다 — 교차검토가 없는 모델은 주장에 불과합니다.

5. 예외 무시. 정상 흐름만 그렸는데 30%의 경우는 다르게 진행됩니다. 2~3개의 흔한 예외는 그림에 포함하고 나머지는 텍스트로 적으세요.

6. 숫자 없음. 모델이 완성되었지만 "우선 무엇을 하죠?"라는 질문이 의견 싸움으로 남습니다.

7. 소유자나 갱신 계기가 없음. 책임자와 정기적 갱신 계기가 없는 모델은 12개월 후에는 잘못된 상태가 됩니다.

무엇으로 모델링할까?

초기 버전은 종이, 화이트보드, 포스트잇이면 충분합니다. 포스트잇은 옮길 수 있고, 깔끔한 다이어그램은 누구에게도 이의를 제기하게 하지 않습니다. 정식 문서는 일반 다이어그램 도구로 충분합니다 — 단일 프로세스에는 도구가 가장 작은 문제입니다. 수년간 유지하거나 실행할 모델은 저장소, 버전관리, 승인 기능이 있는 BPM 제품군이 필요합니다; 관리되는 프로세스가 10개 미만이면 보통 비용 대비 이득이 적습니다.

워크숍에서 바로 타이핑할 경우

예외적으로 언급할 가치는 있습니다. 워크숍에서 아무도 상자를 그리지 않는 경우가 흔한 중단 원인입니다: 그리는 사람은 따라가지 못하고, 필기하는 사람은 나중에 옮기거나 아예 옮기지 않습니다. 당사 데스크탑 애플리케이션 FlowVisual에는 이를 위한 입력줄이 있습니다: 단계마다 한 줄, Enter로 다음 줄, 흐름은 자동으로 연결됩니다.

Anfrage kommt rein
Angebot rechnen @Vertrieb 20-40min
Freigabe @Chef 5min ?über 10k
Nacharbeit @Vertrieb !fehlende Angaben

네 가지 마커만 있습니다: @ 역할, 시간 범위는 기간, ?는 조건, !는 문제점. 모두 자율적입니다 — 아무 표시 없는 줄도 유효하며 누군가 말하지 않은 것은 빈 상태로 남아 창작된 0이 모델에 들어가지 않습니다. 처음부터 비어 시작하기 싫으면 여섯 가지 템플릿(Angebot, Rechnungsfreigabe, Reklamation, Onboarding, Servicedesk, Auftragsabwicklung)을 열거나 기존 절차서를 불러오면 됩니다; 제안된 각 단계는 원문 인용과 파일을 포함하고 개별 수락됩니다.

요점은 그리기가 아니라 그 다음에 가능한 일들입니다: 역할, 기간, 빈도가 이미 줄에 있으므로 완성된 그림은 다음 섹션의 네 가지 값을 일부 이미 포함하며, 계산 가능해져 단순 감상이 아니라 수치 분석이 가능합니다. 그 방식의 전체 과정은 Wenn es noch keinen Prozess gibt 섹션에 설명되어 있습니다.

중요한 것은 도구 선택보다 모델이 사람들이 실제로 일하는 곳에 있어야 한다는 점입니다. 부서가 접근할 수 없는 도구에 저장된 다이어그램은 관리되지 않습니다 — 출력되어 벽에 걸리고 오래 후에 구식이 됩니다.

결론

프로세스 모델링은 명확한 규칙이 있는 수공업입니다: 먼저 경계를 정하고, 수행자와 이야기하고, 목적에 맞는 표기법을 선택하고, 역할과 시스템당 한 단계로 나누고, 예외는 적절히 포함시키고, 교차검토를 받으세요. 이를 따르면 보통 1~2일 안에 유용한 모델을 얻을 수 있습니다.

모델이 제공하지 않는 것, 더 나은 표기법으로도 제공하지 않는 것은 무엇을 우선적으로 개선할지의 순서입니다. 이를 위해서는 각 상자에 숫자를 붙이고 계산을 해야 합니다 — 도착률, 분산, 용량, 달력. 다이어그램은 계산을 위한 전제이며 답이 아닙니다.

다음 단계:

1. 트리거와 결과를 두 문장으로 적으세요
2. 수행자들과 2~3회의 대화를 하고 위의 다섯 질문을 물어보세요
3. Swimlane으로 그려 8~15단계로 구성하세요
4. "어디가 틀렸나요?"라는 질문으로 교차검토를 받으세요
5. 단계별로 기간(범위), 대기시간, 빈도, 매체단절을 추가하세요
6. 그다음에야 어디를 개입할지 결정하세요

추가 자료:

• Prozesslandkarte erstellen — 단일 모델 위의 단계
• Lay bare: den Ist-Zustand beziffern — FLOWREFY-메서드의 두 번째 단계, 즉 상자에 적는 정확한 수치
• Prozessanalyse — 모델을 신뢰할 수 있는 진술로 바꾸는 방법

계산용 도구: 무료 Prozesskosten-Rechner로 모델화한 흐름이 한 달에 얼마인지, 절감 가능성 및 단계별 분해를 몇 분 안에 산정할 수 있습니다.