업무를 계속 진행하게 하는 비즈니스 워크플로 예외 경로

일상적인 워크플로 문제에 명확한 경로가 필요한 이유

대부분의 워크플로는 다이어그램에서 간단해 보입니다. 누군가 요청을 제출하고, 관리자가 승인한 다음, 팀이 작업을 완료합니다. 실제 업무는 좀처럼 이렇게 직선적으로 진행되지 않습니다. 비용 센터가 비어 있는 양식이 도착하거나, 고객이 예외 처리를 요청하거나, 승인자가 기한을 놓칠 수 있습니다.

정해진 경로가 없으면 프로세스가 멈춥니다. 사람들은 채팅에 세부 정보를 복사하고, 알림 이메일을 보내거나, 문제를 추적할 스프레드시트를 만들기 시작합니다. 원래 요청은 여러 사람이 같은 정보의 서로 다른 버전을 가지고 있는 동안 처리되지 않은 상태로 남습니다.

명확한 비즈니스 워크플로 예외를 설정하면 요청을 프로세스 안에서 계속 관리할 수 있습니다. 워크플로는 요청자에게 누락된 정보를 요청하고, 거부 사유와 함께 요청을 반환하거나, 기한이 지난 작업을 대체 담당자에게 할당할 수 있습니다. 모든 사람이 현재 상태와 다음에 조치해야 할 사람을 확인할 수 있습니다.

이렇게 하면 보고서도 더 유용해집니다. 구매 요청 10건이 예산 코드 입력을 기다리고 있다면 접수 양식에 반복되는 문제가 있다는 뜻입니다. 요청이 자주 수동 검토로 넘어간다면 승인 규칙을 조정해야 할 수 있습니다. 채팅 메시지는 이런 패턴을 감추기 쉽습니다.

프로세스 오류와 비즈니스 결정은 서로 다르게 처리해야 합니다. 프로세스 오류는 필수 데이터가 없거나 잘못되어 워크플로를 멈추게 합니다. 예를 들어 직원이 영수증 없이 비용 청구를 제출할 수 있습니다. 이때 워크플로는 청구를 반환하고 직원이 무엇을 추가해야 하는지 알려야 합니다.

비즈니스 결정에는 판단이 필요합니다. 주문 금액이 일반적인 지출 한도를 넘더라도, 공급업체가 긴급한 교체 부품을 필요로 한다면 관리자가 승인할 수 있습니다. 데이터는 완전하지만 규칙만으로 결과를 결정할 수는 없습니다.

두 경우를 모두 일반적인 «오류»로 처리하면 혼란이 생깁니다. 요청자는 필드를 수정해야 하는지, 증빙을 제출해야 하는지, 결정을 기다려야 하는지 알기 어렵습니다. 모든 예외에 이해하기 쉬운 이름, 명확한 담당자, 정해진 결과를 부여하세요.

예를 들어 AppMaster에서 구축한 워크플로는 불완전한 요청을 제출자에게 돌려보내고, 정책 예외는 관리자에게 보낼 수 있습니다. 요청 기록은 여러 받은편지함 사이를 이동하지 않고 한곳에 남습니다. 이 단순한 선택만으로도 많은 후속 작업을 줄일 수 있습니다.

워크플로를 만들기 전에 예외를 정의하세요

정상적인 진행이 멈추는 순간에는 명확한 경로가 필요합니다. 먼저 정보 누락, 거부된 요청, 기한 초과 작업, 수동 검토가 필요한 사례라는 네 가지 일반적인 비즈니스 워크플로 예외를 정리하세요. 각각에 «문제가 발생함» 같은 모호한 상태가 아니라 고유한 규칙이 필요합니다.

각 예외에 대해 발생 조건, 담당자, 기한, 다음 작업을 문서화하세요. 누가 답변해야 하는지 몰라 요청이 대기열에 남는 일을 막을 수 있습니다.

각 경로가 작업을 요청자에게 돌려보낼지, 요청을 종료할지 일찍 결정하세요. 정보 누락은 보통 제출한 사람에게 돌아갑니다. 거부된 요청은 수정할 수 있도록 반환할 수 있지만, 고정된 정책을 위반한 요청은 명확한 사유와 함께 종료해야 합니다. 직원이 다시 제출할 수 있는지 추측하게 만들어서는 안 됩니다.

현재 상태를 설명하는 상태 이름을 사용하세요. «요청자 응답 대기», «거부됨», «기한 초과», «수동 검토 필요»가 «예외 2»나 «조치 대기»보다 좋습니다. 목록을 훑어보는 사람도 무슨 일이 있었고 다음에 누가 처리해야 하는지 이해할 수 있어야 합니다.

원래 요청의 기한뿐 아니라 예외 자체에도 기한을 설정하세요. 예를 들어 요청자에게 영업일 기준 이틀 안에 누락된 송장을 업로드하도록 할 수 있습니다. 응답이 없으면 워크플로가 알림을 보내고, 정해진 기간이 지나면 요청을 종료할 수 있습니다. 이렇게 하면 오래된 작업이 조용히 쌓이는 일을 막을 수 있습니다.

노코드 앱에서는 예외를 눈에 보이는 상태 변경과 비즈니스 프로세스의 별도 경로로 구축하세요. AppMaster의 시각적 Business Process Editor를 사용하면 결정을 매핑하고, 담당자를 지정하고, 요청을 다음 단계로 전달할 수 있습니다. 상태 목록, 알림, 직원 화면에서 같은 표현을 사용하세요.

정보가 누락된 요청 전달하기

빈 필드가 있는 요청을 승인 가능한 작업과 같은 대기열에 두어서는 안 됩니다. «정보 대기» 같은 명확한 상태를 부여하고 활성 승인 경로에서 분리하세요. 그러면 검토자가 요청을 놓쳤다고 생각하지 않고, 진행이 멈춘 이유를 확인할 수 있습니다.

상태가 바뀌면 요청자에게 직접 메시지를 보내야 합니다. «추가 정보 필요»처럼 모호한 메모는 피하세요. 누락된 항목을 이름으로 밝히고, 어떤 답변이 적절한지 설명하세요. 예를 들면 «이 구매 요청을 검토하려면 공급업체 견적서를 첨부하고 월별 비용을 입력해 주세요»라고 안내할 수 있습니다.

원래 요청은 열어 두고 수정할 수 있게 하세요. 요청자는 부서, 예산 코드, 설명을 다시 입력하지 않고 견적서를 추가하거나 날짜를 고칠 수 있어야 합니다. 좋은 워크플로 예외 처리 경로는 이미 확인한 세부 정보와 메모, 요청 상태가 변경된 시간을 함께 보존합니다.

반환 경로를 명확히 하세요

요청자가 누락된 정보를 추가하면 정해진 다음 단계로 요청을 보내세요. 보통은 해당 정보를 요청한 사람에게 돌아갑니다. 새 정보가 결정에 영향을 준다면 첫 번째 승인 단계로 돌아가야 할 수도 있습니다.

누락된 필드나 문서, 응답 책임자, 업데이트를 확인하는 검토자, 응답 기한, 요청이 종료될 때의 종료 사유를 기록하세요. 이 기록은 나중에 발생하는 질문을 해결해 줍니다. 관리자는 송장 요청이 느린 재무 승인 때문이 아니라 세금 서류를 기다리고 있었다는 사실을 확인할 수 있습니다.

알림과 종료 규칙을 사용하세요

응답 기한 전에 알림을 설정하세요. 영업일 기준 이틀 뒤 한 번, 기한 당일 한 번 알림을 보내는 방식이 실용적입니다. 먼저 요청자에게 알림을 보내고, 프로세스상 에스컬레이션이 필요한 경우에만 요청자의 관리자에게 참조로 보내세요.

비즈니스 워크플로 예외에는 종료 지점도 필요합니다. 정해진 기간 동안 아무도 응답하지 않으면 요청을 «불완전»으로 종료하고 사유를 기록하세요. 요청을 삭제하지는 마세요. 요청자는 새 요청을 제출할 때 이전 이력이 필요할 수 있습니다.

AppMaster 같은 노코드 워크플로 도구는 요청 상태를 저장하고, 알림을 보내고, 시각적 비즈니스 프로세스를 통해 업데이트된 양식을 검토자에게 다시 전달할 수 있습니다. 동료가 무엇이 누락되었는지, 누가 처리해야 하는지, 아무 조치도 하지 않으면 어떻게 되는지를 바로 알 수 있어야 합니다.

맥락을 잃지 않고 거부된 요청 처리하기

거부된 요청이 받은편지함이나 모호한 상태 속으로 사라져서는 안 됩니다. 제출한 사람은 무엇이 문제였는지, 누가 결정했는지, 수정할 수 있는지 알아야 합니다. 나중에 질문이 생겼을 때 관리자도 같은 기록을 확인해야 합니다.

사유를 자유 형식의 댓글에만 남기지 말고 구조화된 필드에 저장하세요. 구매 요청 양식에는 «예산 없음», «중복 요청», «승인 누락», «정책 위반» 같은 사유를 제공할 수 있습니다. 선택한 사유에 담기지 않는 내용은 짧은 댓글 필드에 추가하세요.

이렇게 하면 보고서를 더 쉽게 활용할 수 있습니다. 관리자는 대부분의 요청이 비용 센터 누락 때문에 실패하는지, 정책이 혼란을 주기 때문인지 확인할 수 있습니다. 또한 검토자가 «예산 초과»와 «예산이 너무 높음»처럼 같은 사유를 여러 방식으로 작성하는 문제도 줄어듭니다.

거부된 요청에는 세 가지 결과가 있을 수 있습니다. 견적서 누락, 불분명한 업무상 사유, 잘못된 금액처럼 요청자가 수정할 수 있는 문제라면 수정을 위해 반환하세요. 승인되지 않은 공급업체 사용이나 허용 한도 초과처럼 명시된 규칙을 위반했다면 종료하세요. 관리자나 컴플라이언스 담당자의 판단이 필요한 불확실한 사례는 수동 검토로 보내세요.

반환된 요청에는 원래 세부 정보, 첨부 파일, 승인 이력을 남겨야 합니다. 새 요청을 만들지 말고 기존 요청을 수정하도록 요청자에게 안내하세요. 워크플로는 상태를 «수정 요청»으로 설정하고 요청자에게 다시 할당한 뒤, 선택된 거부 사유와 검토자 메모를 보낼 수 있습니다.

요청자가 다시 제출하면 새 버전을 기록하고 적절한 검토자에게 보내세요. 이전 거부 이력은 남겨 두어야 합니다. 그래야 요청이 왜 중단되었고 요청자가 문제를 해결했는지 확인할 수 있습니다.

종료된 요청도 같은 방식으로 관리해야 합니다. 요청자, 검토자, 결정일, 거부 코드, 메모, 첨부된 증거를 하나의 기록에 보관하세요. 요청자는 자신이 종료한 요청을 볼 수 있어야 하고, 관리자는 팀의 전체 이력을 확인할 수 있어야 합니다.

AppMaster에서는 데이터 모델에 요청 상태, 거부 사유, 검토자 메모, 결정일, 이력 테이블을 포함할 수 있습니다. 시각적 비즈니스 프로세스를 통해 수정 가능한 요청을 요청자에게 돌려보내고 정책 위반을 자동으로 종료할 수 있습니다. 일상적인 수정은 계속 진행하면서 최종 결정은 기록으로 남길 수 있습니다.

기한 초과 작업 규칙 설정하기

모든 작업에 같은 기본 타이머를 적용하지 말고 업무에 맞는 기한을 설정하세요. 관리자는 일반적인 비용 승인을 영업일 하루 안에 처리할 수 있지만, 법무 검토에는 5일이 필요할 수 있습니다. 팀의 업무량도 중요합니다. 담당자가 하루 대부분을 고객 응대에 쓰고 있다면 2시간이라는 기한은 의미가 없습니다.

기한 규칙을 워크플로에 명시하세요. 시간이 언제부터 시작되는지, 주말을 포함하는지, 어떤 이벤트가 작업 완료를 의미하는지 정해야 합니다. 명확한 규칙이 있으면 금요일 늦게 도착한 요청이나 다른 팀의 정보를 기다리는 요청을 두고 논쟁할 필요가 줄어듭니다.

기한 전에 알림을 보내세요. 허용된 시간의 75%가 지났을 때 알림을 보내면 담당자가 조치할 시간을 확보하는 데 도움이 됩니다. 5일 작업이라면 4일째에 알림을 보낼 수 있습니다. 작업 이름, 기한, 현재 담당자, 필요한 조치를 포함하세요. «대기 중인 작업이 있습니다»라는 메시지만으로는 할 일이 분명하지 않습니다.

기한이 지나면 결정 권한이 있는 지정된 사람이나 역할에 다음 작업을 할당하세요. 기한이 지난 작업을 공용 받은편지함으로 보내지 마세요. 책임이 감춰지고 또 다른 기한 초과 작업이 생기기 쉽습니다.

지연 유형에 맞춰 결과를 정하세요. 누락된 컴플라이언스 확인처럼 안전한 결정을 막는 작업이 늦어졌다면 요청을 일시 중지하세요. 원래 담당자가 자리를 비웠거나 처리할 여력이 없다면 재할당하세요. 내부 메모 지연처럼 다음 단계에 영향을 주지 않는다면 상태를 표시한 채 계속 진행할 수 있습니다. 고객과의 약속, 결제, 외부 기한에 영향을 주는 지연은 관리자에게 에스컬레이션하세요.

반복되는 에스컬레이션에도 한도를 두세요. 예를 들어 구매 요청을 한 번 늦게 알림을 보낸 뒤 구매 담당자에서 조달 책임자로, 영업일 하루가 더 지나면 재무 관리자로 전달할 수 있습니다. 새 담당자가 이전 메모와 첨부 파일을 확인할 수 있도록 요청 이력은 그대로 유지해야 합니다.

비즈니스 워크플로 예외에는 알림만 필요한 것이 아닙니다. 담당자, 결정 규칙, 기록된 결과가 필요합니다. AppMaster에서는 시각적 비즈니스 프로세스를 통해 늦은 작업을 적절한 사람에게 전달하고 별도의 기한 추적 스프레드시트 없이 요청을 계속 진행할 수 있습니다.

사람들이 실제로 사용할 수 있는 수동 검토 단계 추가하기

일부 요청은 규칙에 맞지 않습니다. 공급업체 이름이 낯설어 보이거나, 비용이 일반적인 한도를 넘거나, 두 필드의 내용이 충돌할 수 있습니다. 이런 사례는 자동 경로가 아니라 사람이 결정해야 합니다.

수동 검토 프로세스의 범위를 분명히 하세요. 판단이 필요한 요청만 보내고, 검토로 넘긴 이유를 보이게 하세요. «검토 필요»처럼 모호한 상태는 검토자가 워크플로가 멈춘 이유부터 알아내야 하므로 불필요한 작업을 만듭니다.

검토자에게 충분한 맥락 제공하기

검토 화면에는 원래 요청, 예외를 발생시킨 필드나 규칙, 이전 메모, 관련 파일이 표시되어야 합니다. 구매를 승인하는 관리자는 금액, 공급업체, 예산 코드, 요청자, 견적서를 한곳에서 확인할 수 있어야 합니다.

다음 워크플로 경로에 맞는 선택지를 검토자에게 제공하세요. 승인 후 요청을 다음 단계로 보내기, 거부하고 종료하기, 수정하도록 요청자에게 반환하기, 지정된 사람이나 팀으로 에스컬레이션하기가 여기에 해당합니다. 모든 예외 결정에는 짧은 사유를 입력하도록 하세요. «예산 초과»나 «서명된 견적서 누락» 같은 사유는 요청자가 조치할 방향을 알려 주고 다음 검토자에게 기록을 남깁니다. 일반적인 승인에는 긴 설명이 필요하지 않습니다.

결정에도 기한을 설정하세요

아무도 결정을 맡지 않으면 수동 작업도 기한 초과 작업이 될 수 있습니다. 표준 구매 요청을 검토자에게 할당할 때 영업일 기준 이틀 같은 기한을 설정하세요. 기한 전에 알림을 보내고, 담당자가 자리를 비웠다면 대체 검토자나 관리자에게 요청을 전달하세요.

결정 권한이 있는 사람이 누구인지 명확하지 않은 상태에서 같은 요청을 모든 사람에게 동시에 보내지 마세요. 서로 충돌하는 답변이 나올 수 있습니다. 먼저 한 명의 담당자를 지정하고 각 조치를 기록한 뒤 최종 결정이 내려지면 요청을 잠그세요.

AppMaster에서는 Business Process가 예외를 검토 작업으로 전달하고, 결정과 메모를 저장한 다음 승인, 거부, 수정 요청 경로 중 하나로 진행할 수 있습니다. 작업은 원래 요청과 연결된 상태로 남기 때문에 이메일을 뒤져 이력을 다시 구성할 필요가 없습니다.

예시: 경로를 벗어난 구매 요청

직원이 2,400달러 상당의 새 모니터를 구매해 달라는 요청을 제출합니다. 요청에는 품목 목록과 부서가 포함되어 있지만 공급업체 견적서가 없습니다. 워크플로는 이를 관리자에게 보내는 대신 상태를 «정보 대기»로 설정하고 다음 작업을 요청자에게 할당합니다.

요청자는 누락된 문서와 기한을 명시한 메시지를 받습니다. 관리자는 불완전한 요청을 받지 않으므로 승인 대기열을 제대로 활용할 수 있습니다. 요청자가 견적서를 업로드하면 워크플로는 업로드 시간을 기록하고 상태를 «예산 검토 준비»로 변경한 뒤 재무 담당자에게 요청을 보냅니다.

재무팀은 남은 부서 예산을 확인한 후 금액이 월별 한도를 초과한다는 이유로 요청을 거부합니다. 거부된 요청 워크플로는 원래 양식, 견적서, 메모, 승인 이력을 함께 보관합니다. 상태는 «예산 거부»로 바뀌고 요청자는 «주문 금액을 1,800달러로 줄이거나 다음 달까지 기다려 주세요»라는 명확한 안내를 받습니다.

요청자는 모니터 두 대를 빼고 다시 제출합니다. 워크플로는 요청자에게 처음부터 다시 시작하게 하지 않고 새로운 재무 검토 작업을 만듭니다. 재무팀은 수정된 금액을 승인합니다. 상태는 «관리자 승인 대기»로 바뀌고, 관리자는 이전 거부의 전체 이력과 함께 작업을 받습니다.

승인이 늦게 도착하는 경우

관리자에게는 이틀의 영업일이 주어집니다. 둘째 날 워크플로가 알림을 보냅니다. 기한이 지나면 기한 초과 작업 관리가 상태를 «관리자 승인 기한 초과»로 바꾸고 관리자의 팀 리더에게 에스컬레이션 작업을 할당합니다.

요청자도 업데이트를 받습니다. 요청 기록에서 요청이 에스컬레이션된 결정을 기다리고 있으며 원래 기한과 에스컬레이션 시간이 언제인지 확인할 수 있습니다.

팀 리더는 예산 메모와 공급업체 견적서를 확인한 후 주문을 승인합니다. 워크플로는 요청 상태를 «구매 승인»으로 설정하고 구매 담당자에게 주문 작업을 할당하며 요청자에게 주문을 진행할 수 있다고 알립니다.

이 예시는 비즈니스 워크플로 예외에 고유한 상태와 담당자가 필요한 이유를 보여 줍니다. 각 분기는 한 사람에게 다음 작업을 알려 주고, 요청자는 채팅으로 계속 확인하지 않아도 업데이트를 받습니다. 구매팀이 주문을 종료한 뒤에도 기록에는 견적서 요청, 재무팀의 거부, 수정 제출, 늦은 승인, 최종 결정이 남습니다.

예외 경로를 구축할 때 흔히 하는 실수

팀은 먼저 정상 경로를 구축한 다음 나머지 모든 상황을 하나의 포괄적인 경로에 추가하는 경우가 많습니다. 이 경로는 대개 바쁜 관리자에게 도착합니다. 정보 누락, 거부된 요청, 늦은 승인은 서로 다른 사람과 행동이 필요합니다. 모두 한 받은편지함으로 보내면 지연이 생기고 팀이 개선할 수 있는 패턴도 보이지 않게 됩니다.

무슨 일이 있었고 무엇을 해야 하는지 알려 주는 이름을 사용하세요. «문제»나 «주의 필요» 같은 표현은 검토자가 모든 항목을 열어 본 뒤에야 판단하게 합니다. «공급업체 견적서 누락», «재무팀에서 거부», «승인이 이틀 지연됨» 같은 라벨은 다음 담당자에게 유용한 출발점을 제공합니다.

몇 가지 설계 규칙을 따르면 예외가 이메일을 주고받는 작업으로 변하지 않습니다.

• 각 예외를 처리할 수 있는 담당자에게 보내고, 부재에 대비한 대체 담당자도 지정하세요.
• 기한이 지나기 전에 담당자에게 알리고, 아무도 응답하지 않으면 에스컬레이션하세요.
• 검토자가 항목을 거부, 반환, 승인하기 전에 사유를 선택하고 짧은 메모를 남기도록 하세요.
• 수정이 요청되더라도 원래 요청, 첨부 파일, 이전 메모를 그대로 유지하세요.
• 예외가 시작된 시간, 처리한 사람, 종료된 시간을 기록하세요.

조용히 지나가는 기한은 특히 문제가 됩니다. 아무도 처리하지 않은 작업이 며칠 동안 남아 있어 모두가 다른 사람이 담당한다고 생각할 수 있습니다. 기한 초과 작업 관리 규칙은 먼저 담당자에게 알리고, 정해진 시간이 지나면 지정된 관리자에게 알려야 합니다. 24시간 후 한 번 알림을 보내고 48시간 후 에스컬레이션하는 식으로 측정 가능한 규칙을 사용하세요.

검토 단계에도 경계가 필요합니다. 검토자가 이유를 기록하지 않고 어떤 결정이든 내릴 수 있다면 수동 검토 프로세스를 개선하기 어렵습니다. 시간이 지나면 비용, 정책, 증거 누락, 잘못된 양식 필드 중 무엇이 문제였는지 알지 못한 채 같은 요청이 반복해서 반환될 수 있습니다.

수정을 위해 요청이 돌아올 때는 요청을 보존하세요. 요청자는 제출한 정보 옆에서 거부 사유를 확인하고 영향을 받은 필드만 수정한 다음 같은 기록을 다시 제출할 수 있어야 합니다. 새 요청을 만들면 맥락이 사라지고 작업이 중복되며 거부된 요청 워크플로에 대한 보고서의 정확성이 떨어집니다.

좋은 워크플로 예외 처리는 누구나 빠르게 이해할 수 있는 기록을 남깁니다. 무엇이 실패했는지, 다음 작업의 담당자가 누구인지, 요청이 왜 다른 경로로 바뀌었는지를 보여 줍니다.

빠른 점검과 다음 단계

워크플로 예외로 인해 요청이 이름 없는 대기열에 남아서는 안 됩니다. 각 예외 경로에 대해 시작되는 사건, 담당자, 종료시키는 작업을 정하세요. 그러면 비즈니스 워크플로 예외가 막판에 원인을 추적하는 일이 아니라 일상적인 작업이 됩니다.

워크플로를 공개하기 전에 빈 필수 필드, 거부, 기한 초과처럼 모든 예외를 시작하게 하는 조건이 명확한지 확인하세요. 여러 사람이 요청을 볼 수 있더라도 다음 작업을 담당할 사람은 한 명으로 지정하세요. 메시지에는 무슨 일이 있었는지, 수신자가 무엇을 해야 하는지, 언제까지 해야 하는지를 적어야 합니다. 조치가 필요한 직원이 현재 상태와 결정 이력을 확인할 수 있도록 하고, 기한이 지난 작업은 공용 받은편지함이 아니라 지정된 사람이나 역할에게 에스컬레이션하세요.

현실적인 사례로 경로를 테스트하세요. 첨부 파일 없이 요청을 제출하고, 사유와 함께 요청을 거부하고, 승인 작업을 기한이 지난 상태로 두어 보세요. 올바른 사람이 유용한 메시지를 받고 배경을 다시 묻지 않아도 작업을 완료할 수 있는지 확인해야 합니다.

거부된 요청 워크플로에는 요청자에게 돌아가는 경로도 필요합니다. 원래 요청, 거부 사유, 검토자 메모를 함께 보관하세요. 요청자는 이전 결정을 잃게 되는 중복 기록을 만들지 않고 문제를 수정해 다시 제출할 수 있어야 합니다.

기한 초과 작업 관리를 위해 각 기한을 놓친 뒤 어떤 일이 발생할지 정하세요. 첫 번째 알림은 작업 담당자에게 보낼 수 있습니다. 이후 에스컬레이션은 담당자의 관리자나 대체 검토자에게 보낼 수 있습니다. 알림을 영원히 보내지는 마세요. 누군가 작업을 완료, 재할당, 연장 또는 종료해야 하는 시점을 정하세요.

AppMaster를 사용하면 시각적 비즈니스 프로세스로 이러한 경로를 만들 수 있습니다. 팀은 워크플로 로직을 직접 작성하지 않고도 상태 변경, 기한, 알림, 승인, 수동 검토를 모델링할 수 있습니다. 먼저 처리량이 많은 프로세스 하나를 선택하고, 실제 사용자의 도움을 받아 예외 사례를 테스트한 뒤, 실제 업무에서 빈틈이 드러나면 경로를 조정하세요.

처음 몇 주가 지나면 워크플로를 검토하세요. 가장 자주 발생하는 예외를 세고 수동 검토 메모를 읽어 보세요. 같은 누락 정보가 반복해서 지연을 일으킨다면 요청 양식을 바꾸거나 앞단에 확인 단계를 추가하세요. 초기에 작은 수정을 하면 나중에 예외가 쌓이는 일을 막을 수 있습니다.