BPMS란 무엇인가요? 비즈니스 프로세스 관리 설명

BPMS(Business Process Management System)는 정해진 프로세스를 모델링하고 실행한 뒤, 실행 중인 업무를 모니터링하는 소프트웨어입니다. 실행 기능이 강점으로, 작업 순서를 적용하고 업무를 할당하며 처리 결과를 기록합니다. 반면 전체 업무를 조망하는 데는 한계가 있습니다. 시스템에 맡긴 업무만 실행하고 보고할 수 있기 때문입니다.

이 가이드에서는 BPMS의 기능과 실제로 도입하게 되는 다섯 가지 구성 요소, 그리고 그 한계를 살펴봅니다. 이어서 실행 소프트웨어와 프로세스 인텔리전스를 비교합니다. 프로세스 인텔리전스는 실행을 기존 시스템에 맡기고, 여러 시스템의 데이터를 한곳에 연결해 사용자와 AI 도구가 활용할 수 있도록 합니다.

BPMS란 무엇인가요?

BPMS는 Business Process Management System의 약자입니다. 일부 공급업체는 Business Process Management Suite라는 명칭을 사용하기도 합니다. 어느 쪽이든 프로세스를 정의하고, 업무를 그 흐름에 따라 전달하며, 실행 현황을 모니터링하는 소프트웨어를 가리킵니다.

BPM(Business Process Management)은 업무가 수행되는 방식을 이해하고 설계·측정·개선하는 방법론입니다. BPMS는 이를 지원하는 소프트웨어의 한 종류입니다. BPMS를 구매하지 않고도 BPM을 실천할 수 있으며, BPMS를 도입했다고 해서 프로세스를 잘 관리하고 있다는 뜻은 아닙니다.

BPMS의 범위는 시간이 지나며 달라졌습니다. 처음에는 workflow engine에서 출발해 모델링, 양식, 모니터링 기능을 더한 제품군으로 확장됐고, 이제는 팀이 프로세스 애플리케이션 전체를 구성하는 로코드 플랫폼까지 포함합니다. 이처럼 범위가 다양하다 보니 공급업체마다 BPMS를 다르게 설명합니다. 비즈니스 프로세스 관리 소프트웨어를 평가할 때는 명칭보다 다음 네 가지를 확인하세요. 프로세스를 모델링하고 실행할 수 있는지, 관련 시스템과 연결되는지, 프로세스 인스턴스의 실행 현황을 보여주는지 살펴보세요.

BPMS를 구성하는 다섯 가지 요소는 무엇인가요?

제품마다 기능을 묶는 방식은 다르지만, 비즈니스 프로세스 관리 시스템은 일반적으로 다음 다섯 가지 요소로 구성됩니다.

1. 모델러. 보통 BPMN 2.0으로 프로세스를 정의합니다. 모델은 업무 흐름을 설명하고, 실행 가능한 시스템에서는 프로세스를 실행하는 기반이 됩니다. 프로세스 모델 설계에 관한 자세한 내용은 BPMN 모델러를 참고하세요.
2. 실행 엔진. 프로세스 인스턴스를 생성하고 조건을 평가하며, 업무를 할당하고 타이머를 시작하며, 기한이 지난 업무를 상위 단계로 전달합니다.
3. 양식, 규칙, 역할. 사용자가 입력할 정보와 확인할 업무, 다음 단계에 적용할 규칙을 결정합니다.
4. 통합. ERP·CRM 시스템, 데이터 웨어하우스, API 게이트웨이 등의 애플리케이션과 데이터를 주고받습니다. 통합 작업은 도입 과정에서 상당한 비중을 차지할 수 있습니다.
5. 모니터링 및 저장소. 대시보드에서 실행 중인 인스턴스의 상태를 확인할 수 있습니다. 저장소는 프로세스 버전 관리와 변경 통제를 지원합니다.

workflow engine은 이 구성 요소 중 하나입니다. BPMS는 엔진에 도구와 관리 기능을 더해 더 넓은 프로세스를 정의하고 지원하며 모니터링합니다.

BPMS는 프로세스 문서만으로 할 수 없는 어떤 일을 하나요?

프로세스 문서는 업무가 어떻게 진행되어야 하는지 설명합니다. BPMS는 설정된 규칙에 따라 업무를 전달하고 추적할 수 있습니다. 예를 들면 다음과 같습니다.

• 정해진 시간 동안 대기한 업무를 상위 단계로 전달합니다.
• 설정된 기준을 충족하는 인스턴스를 승인 절차로 보냅니다.
• 각 인스턴스가 거친 경로를 기록합니다.
• 주변 애플리케이션을 여러 개 수정하지 않고도 설정을 바꿔 업무 흐름을 업데이트할 수 있습니다.

이러한 기능은 일관된 업무 전달과 명확한 책임 소재가 필요하고, 시스템이 실행하는 인스턴스를 확인해야 할 때 유용합니다. 그렇다고 실제 프로세스의 모든 업무가 BPMS 안에서 이뤄진다는 뜻은 아닙니다. 프로세스를 문서화하거나 현재 운영 방식을 파악하는 것이 우선이라면 실행 소프트웨어가 첫 단계로 적합하지 않을 수 있습니다.

BPMS, workflow engine, RPA, process mining, process intelligence는 어떻게 다른가요?

이 다섯 가지 기술은 프로세스 관리의 서로 다른 영역을 다룹니다. 아래 표에서 각 기술의 기능과 답을 찾는 데 도움이 되는 질문을 확인할 수 있습니다.

RPA와 BPMS는 프로세스 변경에 서로 다른 방식으로 접근합니다. RPA는 기존 프로세스의 업무를 자동화합니다. BPMS는 정의한 프로세스를 실행하며, 이를 통해 업무 전달 방식이 달라질 수 있습니다. 업무를 자동화하기 전에 프로세스를 재설계하면 해당 업무를 없앨 수 있는지 확인하세요. process mining으로 자동화 기회 찾기에서 자세히 알아보세요.

Process mining과 BPMS도 서로 다른 질문에 답합니다. Process mining은 이벤트 데이터를 분석해 실제 업무가 시스템을 어떻게 거치는지 보여줍니다. BPMS는 설계된 흐름을 실행하고 처리하는 인스턴스를 보고합니다. 모델이 실제 업무와 일치하는지 확인할 때 이 차이가 중요합니다.

표의 마지막 항목인 process intelligence는 나머지 기술을 연결합니다. 실행은 가장 적합한 시스템에 맡기고, 모든 시스템의 기록을 읽어 프로세스를 하나의 모델로 정리합니다. 다른 시스템은 모두 이 모델을 기준으로 측정합니다. BPMS는 자체 인스턴스를 보고하지만, process intelligence는 어느 한 플랫폼도 실행하지 않는 업무를 포함해 프로세스 전체를 보여줍니다.

BPMS 하나로 모든 프로세스를 실행할 수 없는 이유는 무엇인가요?

BPMS가 프로세스 관리의 해답처럼 보일 수 있지만, BPMS가 관리하지 않는 시스템을 세어 보면 한계가 드러납니다. 실제 프로세스는 ERP, CRM, 티켓 관리 도구, 공급업체 포털, 스프레드시트, 여러 이메일함을 거칩니다. 플랫폼은 모델링한 업무만 실행하고, 나머지는 다른 곳에서 계속 진행됩니다.

이 간극은 도입 전에 알아둘 만한 세 가지 문제로 이어집니다.

표준을 재사용하는 대신 맞춤 workflow를 만듭니다. BPMS는 도구 모음이므로 프로세스마다 별도 프로젝트가 필요합니다. 자체 변형을 모델링하고, 단계를 직접 정의하며, 다른 수많은 조직도 운영하는 흐름을 별도로 관리해야 합니다. 주문부터 대금 회수까지, 구매부터 지급까지, 사고 관리 같은 업계 표준 참조 모델을 재사용하지 않고 플랫폼마다 다시 구축합니다. 같은 시스템을 쓰는 부서끼리도 동일한 프로세스의 서로 다른 버전을 운영할 수 있습니다.

실행 중심 플랫폼은 전체 상황을 놓치기 쉽습니다. BPMS는 무엇을 실행하는지를 기준으로 평가되므로, 관심과 예산이 플랫폼 안의 흐름에 집중됩니다. 여러 팀과 시스템, 국가를 넘나들지만 BPMS가 실행하지 않는 프로세스는 담당자가 없는 경우가 많습니다. 실행 속도를 높이는 것과 조직의 업무 방식을 이해하는 것은 별개의 일입니다.

BPMS에는 한계가 있으며, 예외가 계속 쌓입니다. 긴급 주문, 우수 고객, 이메일만 받는 공급업체처럼 모든 프로세스에는 예외가 있습니다. BPMS에서는 예외마다 설정된 분기와 양식, 통합, 유지 관리할 workflow가 추가됩니다. 업무 표준화를 위해 도입한 플랫폼에 특별 사례가 쌓이고, 이를 이해하는 사람은 점점 플랫폼 담당 팀으로 한정될 수 있습니다.

그렇다고 BPMS가 나쁜 도구라는 뜻은 아닙니다. 다만 프로세스 정보를 한곳에서 관리하는 단일 기준으로는 적합하지 않을 수 있습니다.

IT 비즈니스 프로세스 관리와 일반 비즈니스 프로세스 관리의 차이

간극은 IT 비즈니스 프로세스 관리에서 특히 두드러집니다. 하나의 업무가 티켓 대기열, 변경 일정, 여러 애플리케이션과 그 사이의 승인 절차를 거치기 때문입니다. 단일 비즈니스 프로세스 소프트웨어로는 이 모든 과정을 확인하기 어렵습니다.

비즈니스 부문에서도 다른 형태로 같은 문제가 나타납니다. 주문부터 대금 회수까지, 구매부터 지급까지, 직원 온보딩 같은 프로세스도 여러 시스템을 거칩니다. 다만 서비스 데스크가 아니라 운영 부서에서 처리하므로 대기 시간이 티켓 수가 아닌 일수로 나타나고, 시스템 간 흐름이 처음부터 끝까지 문서화된 경우도 드뭅니다.

이 차이는 구매할 소프트웨어에도 영향을 줍니다. 서비스 관리 플랫폼은 자신이 관리하는 티켓을 기준으로 평가되므로, 보고되는 시간은 플랫폼의 경계에서 끝납니다. 공급업체 응답, 신용 확인, 이메일 승인처럼 플랫폼 밖에서 진행되는 업무는 내부에서 볼 수 없습니다. 어느 부서가 프로세스를 맡든 방법은 같습니다. 각 단계를 기록하는 시스템의 이벤트 데이터를 바탕으로 실제 경로를 재구성한 다음, 문서화된 흐름과 비교합니다.

거의 사용하지 않는 BPMS를 계속 유지해야 할까요?

많은 조직이 실행 엔진을 목적으로 BPMS를 구매했지만 결국 사용하지 않았습니다. 도입은 계획보다 오래 걸렸고, 초기 흐름은 파트너가 설정했으며, 현업은 기존 시스템을 계속 사용했습니다. 지금은 소수의 사용자가 다이어그램을 그릴 때만 여는 모델러 라이선스와, 아무도 시작하지 않는 실행 환경의 유지 비용만 남아 있습니다.

이럴 때는 플랫폼이 하나로 묶어 제공한 두 가지 역할을 분리해 살펴봐야 합니다. workflow engine은 업무를 실행하고, 모델 저장소는 프로세스 지식을 보관하도록 만들어졌습니다. 두 번째 역할만 수행하고 있다면 문서화 도구로 쓰기 위해 실행 플랫폼 비용을 지불하는 셈입니다. 문서화 방식으로는 복잡하고 기술 의존도가 높으며 비용도 많이 듭니다.

이 항목 대부분에 해당한다면 실행 플랫폼에 애초에 설계되지 않은 지식 관리 역할까지 맡기고 있는 것입니다. 해결책은 실행 환경을 더 늘리는 것이 아닙니다. 지식 관리에 특화된 도구로 옮기세요. 모든 프로세스를 한곳에 모으고, 각 시스템의 데이터와 연결하며, 필요한 사용자와 AI 어시스턴트가 읽을 수 있도록 관리할 수 있습니다. 실행 환경을 운영할 필요도 없습니다.

실제로 실행하는 프로세스에는 BPMS를 계속 사용하세요. 프로세스 지식은 릴리스 주기에 얽매이지 않고 확장할 수 있는 곳으로 옮기세요.

Process intelligence는 BPMS와 어떻게 다른가요?

실행 기능이 없는 것은 결함이 아니라 의도적인 선택입니다. Process intelligence는 실행을 맡지 않습니다. 실행 시스템은 다양하며, 보유하고 있는 플랫폼이 언제나 최선의 선택인 것도 아니기 때문입니다. RPA, AI 에이전트, workflow 관리 시스템, ERP 자체 workflow, 그리고 사람이 직접 수행하는 업무는 각기 다른 상황에서 적합합니다. 업무를 실행하는 도구는 해당 역할에 맞춰 선택해야 합니다.

반면 지식 관리는 여러 시스템에 나눠 맡길 수 없습니다. 실행 시스템마다 자체 프로세스 지도를 관리하면 프로세스가 무엇인지, 고객에게 어떤 변형이 실제로 적용됐는지, 다음에 어떤 단계를 자동화해야 하는지 누구도 명확히 답하기 어렵습니다. 업무 담당자와 새롭게 업무에 활용되는 AI 어시스턴트를 위해 프로세스 지식을 한곳에 모으는 일은 실행 자체를 맡는 것보다 중요합니다.

여기에 데이터의 이점이 있습니다. BPMS는 자체 인스턴스를 보고하지만, process intelligence 플랫폼은 모든 시스템의 이벤트 데이터를 연결하므로 BPMS가 보지 못한 업무까지 보여줍니다. BPMS, ERP, 자동화 도구가 모두 기준으로 삼을 단일 모델도 관리할 수 있습니다.

모델을 실제 업무에 맞추려면 process mining이 필요한 이유는 무엇인가요?

BPMS는 내부에서 실행되는 인스턴스를 보고할 수 있습니다. 그렇다고 사람들이 프로세스를 완료하는 데 거치는 모든 경로를 기록한다는 뜻은 아닙니다. 흔히 다음 세 가지 문제가 생깁니다.

• 업무가 실행 엔진 밖에서 진행됩니다. 누군가 이메일로 예외를 처리한 뒤 나중에 시스템을 업데이트할 수 있습니다. 모델이 나타내는 것보다 실제 업무가 오래 걸렸는데도 인스턴스는 규정을 준수한 것처럼 보일 수 있습니다.
• 같은 결과에 다른 시스템을 거쳐 도달합니다. 팀에서 ERP, 스프레드시트 또는 공급업체 포털을 사용할 수 있습니다. 해당 업무가 BPMS에 입력되지 않으면 대시보드에 프로세스 전체가 표시되지 않습니다.
• 모델이 실제 업무를 따라가지 못합니다. 게시 시점에는 정확했던 프로세스도 팀이 각자 다른 방식을 적용하면서 실제 운영과 달라질 수 있습니다. 모델 업데이트에 시간이 걸리면 이런 차이가 계속 남을 수 있습니다.

그 결과 잘 관리되고 있지만 실제 업무 방식과는 맞지 않는 모델이 남습니다. Process mining으로 이를 다시 실제 업무에 맞출 수 있습니다. 시스템이 이미 기록한 이벤트 데이터를 읽고, 모델링되지 않은 경로까지 포함해 실제로 진행된 흐름을 재구성합니다.

적합성 검사는 프로세스 모델과 이벤트 데이터를 비교해 실제 실행이 설계와 다른 지점을 보여줍니다. Process mining은 실제 기록에 나타난 변형과 지연, 재작업을 보여줍니다. 프로세스 모델링과 process mining을 함께 활용해야 하는 이유에서 의도한 흐름과 실제 결과를 함께 살펴봐야 하는 이유를 알아보세요.

실행 기능을 개발하지 않기로 한 이유는 무엇인가요?

프로세스 플랫폼에 물어볼 만한 질문입니다. 프로세스를 모델링하고 실행 현황을 확인할 수 있는데, 실행 기능도 제공하지 않는 이유는 무엇일까요? BPMS가 만들어진 배경에는 당연히 실행 기능도 필요하다는 판단이 있습니다. 우리는 다른 길을 택했습니다. 빠뜨린 기능이 아니라 의도적인 결정입니다.

실제로 ProcessMind는 workflow를 실행할 권한을 요구하지 않습니다. 기존 시스템은 계속 업무를 실행하고, 해당 업무에 관한 지식은 한곳에 모아 최신 상태로 유지합니다. 나중에 실행 시스템을 RPA 봇에서 AI 에이전트로, 기존 workflow에서 새 workflow로 바꾸더라도 모델과 기록, 측정 결과는 그대로 유지됩니다. ProcessMind를 만든 이유에서 이 배경을 자세히 설명합니다.

ProcessMind는 BPMS와 어떻게 함께 사용하나요?

ProcessMind는 BPMS가 아니며 업무를 실행하지 않습니다. BPMS, ERP 또는 자동화 플랫폼이 프로세스 실행을 계속 담당합니다. 이것이 의도한 방식입니다. 각 프로세스에 가장 적합한 실행 시스템을 유지하고, 모든 프로세스에 관한 지식을 한곳에 모읍니다.

실제로 process intelligence는 다음과 같이 활용됩니다.

• 구축 전: 관련 시스템의 이벤트 데이터를 분석해 실제 경로와 변형, 예외를 확인합니다. 목표 프로세스를 BPMN 2.0으로 모델링하고, 프로세스 시뮬레이션으로 변경 사항을 검증한 다음 workflow를 설정합니다.
• 구축 후: 계속 데이터를 분석해 실제 실행이 설계와 일치하는지, 현장의 임시 대응이 어느새 표준 업무 방식으로 자리 잡았는지 확인합니다.

BPMS는 업무를 실행합니다. Process intelligence는 실행할 가치가 있는 업무가 무엇인지 판단하고, 결과가 실제 업무 방식과 일치하는지 확인합니다.

BPMS, RPA, process intelligence 중 무엇을 선택해야 하나요?

적합한 시작점은 현재 파악한 내용과 해결하려는 문제에 따라 달라집니다.

다음과 같은 경우 process intelligence부터 검토하세요.

• 현재 프로세스 운영 방식에 대해 구성원들의 의견이 다릅니다.
• 프로세스가 여러 시스템을 거치며, 주요 workflow 밖에서 업무가 진행되기도 합니다.
• 프로세스가 느리다는 사실은 알지만 원인은 모릅니다.
• 보유한 BPMS의 workflow engine을 사용하지 않고 있으며, 프로세스 지식을 유용한 곳에 보관하고 싶습니다.

다음과 같은 경우 BPMS를 검토하세요.

• 프로세스를 이해하고 있으며 표준화할 수 있을 만큼 안정적입니다.
• 업무가 여러 팀에 걸쳐 진행되며, 인계 절차의 전달 방식이나 책임 소재를 명확히 해야 합니다.
• 여러 애플리케이션을 일일이 수정하지 않고도 규칙을 적용하고 변경 사항을 관리해야 합니다.

다음과 같은 경우 RPA를 검토하세요.

• 프로세스가 안정적이고 반복적입니다.
• 자동화할 만큼 업무가 자주 발생합니다.
• 애플리케이션을 변경할 수 없지만 인터페이스를 통해 해당 단계를 자동화할 수 있습니다.

올바른 순서를 지키려면 두 가지 원칙을 따르세요. 실행 소프트웨어를 도입하기 전에 프로세스를 측정하고, 업무를 자동화하기 전에 재설계로 해당 업무를 없앨 수 있는지 확인합니다.

BPMS 도입 전에 어떻게 평가해야 하나요?

주문부터 대금 회수까지, 구매부터 지급까지, 온보딩, 사고 처리처럼 이름과 담당자가 분명한 프로세스 하나부터 시작하세요. 어떤 프로세스를 말하는지 정하지 않은 채 ’운영’처럼 범위가 넓은 영역을 평가하지 마세요. 그런 다음 네 단계를 진행합니다.

1. 이벤트 데이터 찾기

   어떤 시스템이 프로세스 기록을 보유하고 있는지, 기록에 사례 식별자와 활동, 타임스탬프가 있는지 확인합니다. 비즈니스 프로세스 관리 도구는 의도한 흐름을 설명하고, 실제 실행 여부는 이벤트 로그로 확인할 수 있습니다.

2. 설계와 실제 실행 결과 비교

   모델에 드러나지 않는 경로와 지연, 예외를 찾습니다. 실제 데이터를 대상으로 가장 적합한 BPMS 후보를 평가하면 기능 비교표보다 유용합니다. BPMS가 프로세스의 어느 부분을 실제로 맡게 될지 확인할 수 있기 때문입니다.

3. 근거를 바탕으로 필요한 조치 결정

   필요한 해결책은 BPMS일 수도 있고, 프로세스 재설계나 단계 하나의 변경, 또는 별도 조치가 필요하지 않은 경우일 수도 있습니다. 도구를 먼저 정하지 말고 조사 결과에 따라 선택하세요.

4. 구축 후에도 계속 측정

   플랫폼은 실행하는 업무를 보고할 수 있습니다. workflow를 운영한 뒤에도 프로세스가 실제 업무와 일치하는지는 여러 시스템의 이벤트 데이터를 통해 확인할 수 있습니다.

프로세스가 BPMS와 연결되지 않은 시스템까지 거친다면, 초기 측정에서 그 사실이 드러납니다. 실행 기능 도입 여부를 판단할 때 비교해야 할 대상이 바로 이것입니다.