비즈니스 프로세스 모델링

Business process modeling

이 기사는 전문 지식을 기반으로 기업의 개념적인 비즈니스 프로세스 모델을 만들고 제시하는 일반적인 수동 작업을 설명합니다. IT 시스템의 디지털 트레이스를 기반으로 트랜잭션 비즈니스 프로세스 모델을 자동으로 평가하려면 프로세스 마이닝을 참조하십시오.

비즈니스 프로세스 모델 표기법을 사용한 정규 흐름을 갖는 프로세스의 비즈니스 프로세스 모델링 예

비즈니스 프로세스 모델링(BPM)은 주로 비즈니스 프로세스 관리, 소프트웨어 개발 또는 시스템 엔지니어링에 사용되며, 현재 비즈니스 프로세스를 분석하고 안전하고 일관되게 적용하며 개선하고 자동화할 수 있도록 기업의 프로세스캡처하고 표현하는 작업입니다. BPM은 일반적으로 비즈니스 분석가가 모델링 분야에 대한 전문 지식을 제공하고, 모델링 중인 프로세스에 대한 전문 지식을 보유한 주제 전문가가 수행하거나, 일반적으로 둘 다로 구성된 팀이 수행합니다. 또는 프로세스 마이닝 도구를 사용하여 IT 시스템의 디지털 트레이스(예: 이벤트 로그)에서 프로세스 모델을 직접 도출할 수 있습니다.

Andreas Gadatsch에 따르면 프로세스 모델링은 기술적 및 개념적 관점에서 비즈니스 프로세스의 비즈니스 영역에서 현실의 섹션을 매핑하는 «입니다.

개요

비즈니스 프로세스 모델링의 초점은 행동(활동)의 흐름을 표현하는 데 있으며, Hermann J. Schmelzer와 Wolfgang Sesselmann에 따르면 고객이 기대하는 특정 서비스를 생성하고 그 결과가 회사에 전략적으로 중요한 의미를 갖는 부가 가치 활동의 교차 기능 식별에 대한 «를 구성했습니다. 이들은 회사 경계를 넘어 고객, 공급업체 또는 경쟁업체의 활동을 포함할 수 있습니다.»[2] (Chapter 2.1 Differences between processes and business processes) ← automatic translation from German

그러나 데이터 및 비즈니스 객체(투입/산출물로서), 공식 조직역할(책임/책임/협의/정보에 입각한 사람, RACI 참조), 리소스 및 IT 시스템은 물론 지침/지시(작업 장비), 요구 사항, 주요 수치 등과 같은 다른 품질(사실)도 모델링할 수 있습니다.

이러한 특성이 비즈니스 프로세스 모델링에 더 많이 포함될수록 비즈니스 프로세스 모델의 추상화는 현실을 더 잘 반영하며 비즈니스 프로세스 모델은 더 복잡해집니다. «복잡함을 줄이고 모델의 이해성과 투명성을 향상시키기 위해 뷰 개념을 사용하는 것이 좋습니다.»[1]또한 비즈니스 정보학의 5개 관련 독일어를 사용하는 학교의 관점 개념을 간략하게 비교합니다[1](Chapter 2.4 Views of process modeling) ← automatic translation from German. 1) August W. 쉬어, 2) 후베르트 외스테르, 3) 오토 K. Ferstl and Elmar J. Sinz, 4) Hermann Gehring 및 5) Andreas Gadatsch 뷰 개념에 대한 자세한 내용은 회사 매핑(독일어)에서도 확인할 수 있습니다.

용어 뷰(August W). 쉬어, 오토 K. FerstlElmar J. Sinz, Hermann GehringAndreas Gadatsch)는 모든 경영정보학 학교에서 획일적으로 사용되는 것은 아닙니다. 대체 용어는 디자인 차원(Hubert Ossterle) 또는 관점(Zachman)입니다.

M. 로즈만, A. 슈베그만과 P. 델프만은 또한 관점의 개념에서 단점을 봅니다. «각 관점에 대한 정보 모델을 별도로 생성하여 부분적으로 중복적으로 생성하는 것을 고려할 수 있습니다. 그러나 중복은 항상 유지 보수 작업을 증가시키고 모델의 일관성을 위태롭게 합니다. »

Andreas Gadatsch에 따르면 비즈니스 프로세스 모델링프로세스 정의프로세스 관리와 함께 비즈니스 프로세스 관리의 일부로 이해됩니다.[1]

비즈니스 프로세스 모델링은 전체적인 기업 매핑(독일어)의 중심적인 측면이기도 합니다. 이는 시장뿐만 아니라 기업 사명 진술, 기업 정책/기업 거버넌스, 조직 구조, 프로세스 조직, 애플리케이션 아키텍처, 규정 및 이익 그룹의 매핑도 다룹니다.

프로세스 맵을 관리, 핵심 및 지원 프로세스로 분류하는 일반적인 방법

유럽 비즈니스 프로세스 관리 협회 EABPM에 따르면, «에는 세 가지 유형의 엔드 투 엔드 비즈니스 프로세스가 있습니다.

  • 리더십 프로세스
  • 실행 프로세스
  • 프로세스 지원.»

이 세 가지 프로세스 유형은 모든 회사에서 식별할 수 있으며 비즈니스 프로세스 모델을 구조화하기 위한 최상위 수준으로 거의 예외 없이 실제로 사용됩니다.[5] 대신 리더십 프로세스라는 용어는 일반적으로 관리 프로세스라는 용어를 사용합니다. 실행 프로세스라는 용어 대신 코어 프로세스라는 용어가 널리 사용되고 있습니다.[2] (Chapter 6.2.1 Objectives and concept) ← automatic translation from German, [6] (Chapter 1.3 The concept of process) ← automatic translation from German, [7] (Chapter 4.12.2 Differentiation between core and support objectives) ← automatic translation from German, [8] (Chapter 6.2.2 Identification and rough draft) ← automatic translation from German

그런 다음 핵심 프로세스공급망 관리(SCM), 고객 관계 관리(CRM) 및 제품 라이프사이클 관리(PLM)에서 다음 단계로 구성/분해하면 SCOR 모델과 같은 대규모 조직 및 업계 협회의 표준 모델도 비즈니스 프로세스 모델링에 통합할 수 있습니다.

역사

플로우 차트, 기능 플로우 블록 다이어그램, 제어 플로우 다이어그램, Gantt 차트, PERT 다이어그램, IDEF와 같은 비즈니스 프로세스를 모델링하는 기술은 20세기 초부터 등장했습니다. Gantt 차트는 1899년경에 처음으로 등장한 차트, 1920년대의 흐름도, 1950년대의 Functional Flow Block Diagram 및 PERT, 1970년대의 Data Flow Diagram 및 IDEF 중 하나였습니다. 현대적인 방법 중에는 통합 모델링 언어비즈니스 프로세스 모델 표기법이 있습니다. 그러나 이는 비즈니스 프로세스를 문서화하는 데 수년간 사용된 방법론의 일부에 불과합니다.[9] '비즈니스 프로세스 모델링'이라는 용어는 1960년대 S에 의해 시스템 엔지니어링 분야에서 만들어졌습니다. Williams는 1967년 '비즈니스 프로세스 모델링은 행정 통제를 향상시킵니다'라는 글을 썼습니다.[10] 그의 아이디어는 물리적 제어 시스템에 대한 더 나은 이해를 위한 기술을 비즈니스 프로세스에 유사한 방식으로 사용할 수 있다는 것이었습니다. 1990년대가 되어서야 이 용어가 인기를 끌었습니다.

1990년대에 '프로세스'라는 용어는 새로운 생산성 패러다임이 되었습니다.[11] 기업은 기능절차 대신에 프로세스에서 사고하도록 권장되었습니다. 프로세스 사고는 구매에서 공급, 주문 검색에서 판매 등 회사 내 사건의 연쇄를 살펴봅니다. 전통적인 모델링 도구는 시간과 비용을 설명하기 위해 개발된 반면, 현대적인 도구는 교차 기능 활동에 중점을 둡니다. 이러한 교차 기능 활동은 복잡성과 의존성의 증가로 인해 그 수와 중요성이 크게 증가했습니다. 새로운 방법론에는 비즈니스 프로세스 재설계, 비즈니스 프로세스 혁신, 비즈니스 프로세스 관리, 통합 비즈니스 계획 등이 포함되며, 그 중에서도 "기업을 구성하는 전통적인 기능 전반에 걸쳐 프로세스를 개선하는 것을 목표로 합니다."[11]

소프트웨어 엔지니어링 분야에서 '비즈니스 프로세스 모델링'이라는 용어는 소프트웨어 개발 중 관행 상태에 더 집중하는 것을 목표로 일반적인 소프트웨어 프로세스 모델링에 반대했습니다.[12] 그 당시(1990년대 초반)에는 비즈니스 프로세스를 설명하기 위한 기존 및 새로운 모델링 기술이 모두 '비즈니스 프로세스 모델링 언어'로 통합되었습니다.[citation needed] Object Oriented 접근 방식에서는 비즈니스 응용 시스템 사양화에 필수적인 단계로 간주되었습니다. 비즈니스 프로세스 모델링은 데이터 수집, 데이터 흐름 분석, 프로세스 흐름도 및 보고 시설을 지원하는 새로운 방법론의 기본이 되었습니다. 1995년경, 비즈니스 프로세스 모델링 및 구현을 위한 최초의 시각적 지향 도구가 발표되었습니다.

비즈니스 프로세스 모델링의 목적

비즈니스 프로세스 모델에 미치는 영향요인

비즈니스 프로세스 모델링의 목적은 일반적으로 그래픽으로 엔드 투 엔드 프로세스를 표현하는 것이며, 이를 통해 복잡한 현실 사실이 균일한(체계화된) 표현을 통해 문서화되고 실질적인(품질)으로 축소됩니다. 프로세스 문서화에 대한 규제 요구 사항은 품질 관리, 정보 보안 관리 또는 데이터 보호와 같은 여기서도 종종 역할을 합니다.

비즈니스 프로세스 모델링은 일반적으로 환경 요구 사항을 결정하는 것부터 시작합니다. 첫째, 모델링의 목표(비즈니스 프로세스 모델링의 적용)를 결정해야 합니다. 비즈니스 프로세스 모델은 이제 다기능 방식으로 사용되는 경우가 많습니다(위 참조). 둘째, 생성할 모델의 속성이 요구 사항을 충족해야 하므로 모델 주소를 결정해야 합니다. 그 다음 모델링할 비즈니스 프로세스를 결정합니다.

모델에 표현될 비즈니스 프로세스의 품질은 모델링의 목표에 따라 지정됩니다. 일반적으로, 이것들은 그들 사이의 관계를 포함하여 프로세스를 구성하는 기능뿐만 아니라 공식적인 조직, 입력, 출력, 자원, 정보, 미디어, 트랜잭션, 이벤트, 상태, 조건, 운영방법과 같은 여러 가지 다른 특성도 포함합니다.

세부적으로 비즈니스 프로세스 모델링의 목표는 다음과 같습니다.

  • 회사의 업무 프로세스에 대한 문서화
    • 비즈니스 프로세스에 대한 지식을 얻다
    • 사업부를 해당 규정과 매핑합니다.
    • 비즈니스 프로세스를 다른 위치로 이전합니다.
    • 절차 및 작업 지침에서 규칙 집합에 대한 외부 프레임워크를 제공합니다.
    • 비즈니스 파트너 또는 협회의 요구 사항(예: 인증)을 충족합니다.
    • 경쟁자(예: 입찰)에 비해 유리한 점을 얻기 위해
    • 법적 규제 준수(예: 중요 인프라 운영자, 은행 또는 무기 생산자)
    • 직원들을 훈련시키거나 익숙하게 하다
    • (예: 직원 이탈로 인한) 지식 손실을 피하기 위해
    • 품질 및 환경 관리를 지원합니다
  • 공정 성과 지표의 정의 및 공정 성과의 모니터링
    • 공정 속도를 높입니다
    • 사이클 시간을 줄입니다
    • 품질을 높입니다
    • 노동, 재료, 스크랩 또는 자본 비용과 같은 비용을 절감하기 위해
  • 비즈니스 프로세스 최적화 준비 / 구현(일반적으로 현재 상황 분석으로 시작)
    • 새로운 조직 구조를 도입하다
    • 회사 업무를 아웃소싱하다
    • 회사 프로세스를 재설계, 합리화 또는 개선하기 위해(예: CMM의 도움을 받아)
  • 자동화 또는 IT 지원과 같은 정보 기술 프로젝트 준비 - 워크플로우 관리 시스템을 사용합니다.
  • 인터페이스 및 SLA 정의
  • 회사 프로세스의 모듈화
  • 회사의 부품, 파트너 및 경쟁사 간 벤치마킹
  • 모범 사례 찾기
  • 조직의 변화를 수반하다
    • 판매 또는 부분 판매와 같은
    • 회사 또는 회사의 부분의 인수 및 통합과 같은 것.
    • IT 시스템 또는 조직 구조의 도입 또는 변경 등
  • (EFQM 등) 경기 참가.

비즈니스 프로세스 모델링 적용

비즈니스 프로세스 모델링 자체는 기업의 재무적 성공에 직접적인 기여를 하지 않기 때문에 기업의 가장 중요한 목표인 수익 창출 의도에서 비즈니스 프로세스 모델링에 대한 동기가 없습니다. 따라서 기업이 비즈니스 프로세스 모델링에 참여하는 동기는 항상 각각의 목적에서 비롯됩니다. Michael Rosemann, Ansgar Schwegmann Patrick Delfmann은 비즈니스 프로세스 모델링의 동기로 여러 가지 목적을 열거합니다.

  • 프로세스에 대한 커뮤니케이션 효율성을 높이기 위해 프로세스에 대한 투명성을 높이는 것을 «으로 하는 조직 문서화(비즈니스 기능을 재배치하거나 복제하기 위한 프로세스 템플릿 작성 기능 포함)
  • 프로세스 최적화(예: Kaizen, Six Sigma 등을 통해 총 주기 시간(TCT)을 제어하고 단축함으로써) 또는 프로세스 표준화를 목표로 하는 «(혁명적) 비즈니스 프로세스 재엔지니어링 및 지속적(진화적) 프로세스 개선 »의 의미에서 프로세스 중심 재구성
  • 지속 가능성 »에 맞춰진 프로세스의 계획, 구현 및 제어와 같은 지속적인 프로세스 관리
  • DIN ISO/IEC 9001에 따른 인증(또는 ISO/IEC 14001, ISO/IEC 27001 등에 따른 인증)
  • 기업 고유의 구조 및 성능을 선택된 내부 또는 외부 참조와 «으로 비교하는 것으로 정의되는 벤치마킹. 프로세스 모델링의 맥락에서는 프로세스 모델(구조 벤치마킹)의 비교 또는 프로세스 주요 수치 »의 비교를 포함할 수 있습니다.
  • « 지식경영은 지식 »의 파악, 획득, 활용, 개발 및 유통 과정을 개선하기 위해 기업의 지식자원에 대한 투명성을 높이는 것을 목표로 합니다.
  • «가 종종 (소프트웨어별) 참조 모델의 형태로 기능을 문서화하는 ERP 소프트웨어의 선택 소프트웨어 선택 »를 위해 회사별 프로세스 모델과 이러한 소프트웨어별 모델을 비교하는 것도 합리적입니다.
  • 모델 기반 사용자 정의, 즉 참조 모델 » 구성을 통한 소프트웨어의 « 매개변수화를 통해 상용 기성 소프트웨어 »의 구성을 «합니다.
  • 소프트웨어 개발, 요구사항 엔지니어링 »의 일부로서 개념적 수준에서 개발될 소프트웨어에 대한 요구사항 설명을 «에 사용하는 프로세스
  • 프로세스 모델이 인스턴스화 가능한 워크플로 모델 생성의 « 기반이 되는 워크플로 관리 »
  • 시간 »에 따른 시스템 거동을 조사하는 «을 목적으로 한 시뮬레이션과 순수 모델 뷰 »으로 드러나지 않는 약점의 « 파악

BPR(Business Process Re-engineering)

1984년 MIT에서 "1990년대의 경영"이라는 제목으로 시작된 광범위한 연구 프로그램에서 프로세스 재공학의 접근 방식은 1990년대 초에 등장했습니다. 이 연구 프로그램은 1990년대 이후의 경쟁 환경에서 조직이 생존하고 번영할 수 있는 방법에 대한 정보 기술의 영향을 탐구하기 위해 고안되었습니다. 최종 보고서에서 N. Venkat Venkatraman은[15] 그 결과를 다음과 같이 요약합니다. 새로운 프로세스를 정보 기술과 병행하여 계획할 때 생산성을 가장 크게 향상시킬 수 있습니다.

이 접근법은 마이클 M 뿐만 아니라 토마스 H. 데이븐포트[16] 맡았습니다. 해머제임스 A. Champy[17] 오늘날 우리가 이해하고 있는 비즈니스 프로세스 재공학(BPR)으로 발전시켜 비용, 품질, 서비스 및 시간과 같은 측정 가능한 성능 지표의 개선을 달성하기 위해 비즈니스 프로세스가 근본적으로 재구성됩니다.

비즈니스 프로세스 리엔지니어링은 부분적으로 "녹색 분야"에서 출발하기 때문에 기존 기업에서 직접 구현할 수 없다는 비판을 받아 왔습니다. Hermann J. Schmelzer와 Wolfgang Sesselmann은 다음과 같이 평가합니다. «BPR에 대한 비판은 여러 측면에서 학문적 성격을 가지고 있습니다. … 제기된 비판의 몇 가지 논점은 실제적인 관점에서 정당화됩니다. 여기에는 지나치게 급진적인 접근 방식이 실패의 위험을 수반한다는 지적이 포함됩니다. 조직과 직원들이 BPR에 대한 충분한 준비가 되어 있지 않은 경우에는 특히 문제가 됩니다. »

Thomas H. Davenport에 따르면 BPR에 대한 높은 수준의 접근 방식은 다음과 같습니다.

  1. 혁신을 위한 프로세스 식별
  2. 변경 레버 식별
  3. 프로세스 비전 개발
  4. 기존 프로세스 이해
  5. 새로운 프로세스 설계 및 프로토타입 제작

경영시스템 인증

국제표준화기구(ISO 및 공식 로고는 등록 상표임)

ISO/IEC 27001:2022를 통해 관리 시스템에 대한 표준 요구 사항은 이제 모든 주요 ISO 표준에 대해 표준화되었으며 프로세스 특성을 가지고 있습니다.

프로세스 처리를 위한 ISO에 따른 관리시스템에 대한 일반표준 요구사항

ISO/IEC 9001, ISO/IEC 14001, ISO/IEC 27001 표준에서 이는 각각의 경우 4.4장에 고정되어 있습니다.

ISO/IEC 9001:2015

Clause 4.4 품질관리 시스템 및 프로세스

ISO/IEC 14001:2015

조항 4.4. 환경관리시스템

ISO/IEC 27001:2022

4.4절 정보보안 관리체계

비즈니스 프로세스 최적화

Hermann J. Schmelzer와 Wolfgang Sesselmann은 공정 최적화를 위한 예로 그들이 언급한 세 가지 방법의 개선 분야(총 사이클 시간(TCT)의 제어 및 감소, KaizenSix Sigma)는 공정이라고 지적합니다. TCT(Total Cycle Time)의 경우 비즈니스 프로세스(엔드 투 엔드 프로세스) 및 하위 프로세스이며, Kaizen은 프로세스 단계활동이고 Six Sigma는 하위 프로세스, 프로세스 단계활동입니다.[2]

총 사이클 시간(TCT)의 경우 헤르만 J. 슈멜저(Hermann J. Schmelzer)와 볼프강 세셀만(Wolfgang Sesselmann)은 다음과 같은 주요 특징을 나열합니다.[2]

  • 프로세스 흐름을 방해하는 장벽 식별
  • 장벽 제거 및 프로세스 대체
  • 차단막 제거의 효과 측정
  • 측정된 변수와 대상의 비교

따라서 TCT에 대한 비즈니스 프로세스 모델링은 장벽, 장벽 처리 및 측정에 대한 적절한 문서화를 지원해야 합니다.

Kaizen 툴을 보면 처음에는 비즈니스 프로세스나 비즈니스 프로세스 모델링과 직접적인 연관성이 없습니다. 그럼에도 불구하고 카이젠과 비즈니스 프로세스 관리는 서로에게 이익이 될 수 있습니다. «비즈니스 프로세스 관리의 맥락에서 KAIZEN 목표는 비즈니스 프로세스 및 하위 프로세스의 목표에서 직접 도출됩니다. 이 링크는 KAIZEN 조치가 비즈니스 목표를 지원하도록 보장합니다. »

Six Sigma는 요구 사항을 충족하는 공정 결과의 비율이 6 σ 또는 백만 개의 공정 결과에 대해 3.4개의 오류만 발생하도록 오류를 방지하고 공정 능력을 향상시키도록 설계되었습니다. Hermann J. Schmelzer와 Wolfgang Sesselmann은 다음과 같이 설명합니다. « 기업은 종종 4 σ 수준에서 상당한 저항에 부딪히므로 비즈니스 프로세스 재설계(Six Sigma용 설계)의 의미에서 비즈니스 프로세스를 재설계해야 합니다.»[2] 재현 가능한 프로세스 능력 측정을 위해서는[2](Chapter 6.3.4 Six Sigma) ← automatic translation from German 비즈니스 프로세스에 대한 정확한 지식이 필요하며 비즈니스 프로세스 모델링은 Six Sigma 설계에 적합한 도구입니다. 따라서 식스시그마는 SIPOC에 따른 비즈니스 프로세스 모델링을 방법론의 필수적인 부분으로 사용하며, SIPOC를 이용한 비즈니스 프로세스 모델링은 식스시그마의 표준 도구로 자리매김하고 있습니다.

기업간 비즈니스 프로세스 모델링

기업 간 비즈니스 프로세스 모델링의 목적은 외부 이해 관계자의 영향을 분석에 포함하거나, 비즈니스 프로세스의 기업 간 비교 가능성을 달성하는 것입니다. 예를 들어 벤치마킹을 가능하게 하는 것입니다.

Martin Kugler는 이러한 맥락에서 비즈니스 프로세스 모델링을 위해 다음과 같은 요구 사항을 나열합니다.[18]

  • 다양한 회사의 직원들은 비즈니스 프로세스 모델을 이해해야 하므로 모델링 기법(표현)에 대한 친숙도가 특히 중요합니다.
  • 비즈니스 프로세스 모델링의 수용은 표현의 단순성에 따라 증가합니다. 명확하고, 이해하기 쉽고, 가능한 한 자기 설명적이어야 합니다.
  • 다양한 기업 내에서 다양한 표현이 사용되기 때문에 일관된 이해와 수용을 달성하기 위해서는 기업 간 비즈니스 프로세스 모델의 제시가 다양한 기업에서 표준화되어야 합니다.
  • 가치 사슬을 따라 있는 다양한 회사(공급자, 제조업체, 소매업체, 고객)는 일반적으로 서로 다른 산업에서 오기 때문에 산업 중립적인 모델링 기법(표현)을 사용해야 합니다.

토픽

영업활동 분석

프레임워크 조건 정의

비즈니스 활동의 분석은 성공적인 비즈니스 프로세스 모델링을 위한 프레임워크 조건을 결정하고 정의합니다. 여기가 회사가 시작해야 할 곳입니다.

비즈니스 프로세스 모델을 구조화하기 위한 접근 방식을 개발합니다. 관련 목적전략 모두 공정 맵에 직접적인 영향을 미칩니다.

비즈니스 프로세스 모델링의 장기적인 성공을 위한 이러한 전략은 시장 지향적 관점 및/또는 리소스 기반 관점으로 특징지을 수 있습니다. 요르크 베커(Jörg Becker)와 볼커 마이스(Volker Meise)는 설명합니다. «시장 관점에서 산업과 경쟁사의 행동이 기업의 전략을 직접 결정하는 반면, 자원 중심 접근법은 기업의 장단점을 분석하고 이로부터 전략의 발전 방향을 도출함으로써 내부 관점을 취합니다.»[7] 그리고 더 나아가: «시장 기반 관점과 자원 기반 관점 사이의 문헌에서 처음 공식화된 대안적 성격은 이제 차별화된 관점으로 전환되었습니다. 핵심 역량 접근 방식은 기존의 시장 지향적 접근 방식과 함께 사용되는 성공 가능성을 설명하는 데 중요한 기여를 하는 것으로 간주됩니다.[7]따라서 프로세스 맵은 회사의 전략에 따라[7](Chapter 4.7 Combination of views) ← automatic translation from German 시장 개발, 자원 최적화 또는 균형 잡힌 비즈니스 프로세스 모델이 될 것입니다.

비즈니스 프로세스 식별

이후 기업의 비즈니스 활동을 분석함으로써 기업의 비즈니스 프로세스를 식별하고 차별화합니다(비즈니스 프로세스 분석 참조). 비즈니스 프로세스는 특정 고객 또는 고객 그룹을 위해 특정 서비스 또는 제품(특정 목표에 봉사하기 위해)을 생산하는 관련되고 구조화된 행동(활동)의 모음입니다.

유럽 비즈니스 프로세스 관리 협회 EABPM: «프로세스 설계 또는 리엔지니어링의 첫 단계로서 현재 프로세스에 대한 공통된 이해와 목표와의 일치가 확립되어야 합니다. »

특히 BPR(Business Process Re-engineering) 지지자들은 현재의 프로세스를 분석하는 데 관련된 노력을 반복적으로 문헌에서 비판하고 있으며, 대상 상태에 대한 정의를 즉시 시작해야 한다고 제안합니다.

반면에 Hermann J. Schmelzer와 Wolfgang Sesselmann은 문헌에서 BPR(Business Process Re-engineering)의 급진적 접근 방식에서 제기된 비판에 대해 논의하고 평가하며, «은 있는 그대로의 분석을 수행할 것을 권고합니다. 조직 개편은 현재의 약점을 알아야 그것들을 제거할 수 있습니다. 분석 결과는 프로세스 재설계가 필요한 이유에 대한 논거도 제공합니다. 현재 상태에서 목표 상태로 전환하기 위한 초기 상황을 아는 것도 중요합니다. 그러나 분석 노력은 좁은 범위 내에서 유지되어야 합니다. 또한 분석 결과가 재설계에 너무 큰 영향을 주지 않아야 합니다. »

프로세스 맵을 관리, 핵심 및 지원 프로세스로 분류하는 일반적인 방법

업무 프로세스 구조화 - 프로세스 맵 구축

Timo Fürmann은 다음과 같이 설명합니다. «비즈니스 프로세스가 식별되고 이름이 지정되면 이제 개요로 컴파일됩니다. 이러한 개요를 프로세스 맵이라고 합니다. »

시장 주도 기업을 위한 프로세스 맵 예

Jörg Becker와 Volker Meise는 비즈니스 프로세스를 구조화하기 위한 다음 활동 목록을 제공합니다.

  • «주요 공정의 열거,
  • 공정 경계의 정의,
  • 각 프로세스의 전략적 관련성 판단,
  • 프로세스 개선 필요성 분석 및
  • 프로세스 »의 정치적, 문화적 의미 판단

비즈니스 프로세스의 구조화는 일반적으로 관리, 핵심지원 프로세스 간의 구분에서 시작됩니다.

  • 관리 프로세스는 회사의 운영을 지배합니다. 일반적인 관리 프로세스에는 기업 지배 구조와 전략적 관리가 포함됩니다. 그들은 기업 목표를 정의하고 목표 달성을 모니터링합니다.
  • 코어 프로세스core_business를 구성하고 주요 가치 스트림을 생성합니다. 일반적인 운영 프로세스는 구매, 제조, 마케팅판매입니다. 눈에 보이는 직접적인 고객 혜택을 창출합니다.
  • 지원 프로세스는 운영 리소스를 제공하고 관리합니다. 그들은 비즈니스 운영의 원활한 실행을 보장함으로써 핵심 및 관리 프로세스를 지원합니다. 회계, 채용, 기술 지원 등이 그 예입니다.
리소스 중심 회사의 프로세스 맵 예

비즈니스 프로세스 모델링의 장기적인 성공을 위한 전략을 기반으로 핵심 프로세스 구조화

핵심 비즈니스 프로세스가 기업의 식별된 비즈니스 프로세스의 대부분을 분명히 차지하기 때문에 핵심 프로세스를 다시 세분화하는 것이 일반적인 관행이 되었습니다. 이에 대한 접근 방식은 회사 유형과 사업 활동에 따라 다릅니다. 이러한 접근 방식은 비즈니스 프로세스 모델링의 정의된 적용비즈니스 프로세스 모델링의 장기적인 성공을 위한 전략에 의해 크게 영향을 받습니다.

주로 시장 기반 전략의 경우, 엔드 투 엔드 핵심 비즈니스 프로세스는 종종 고객 또는 공급업체에서 소매업체 또는 고객으로 정의됩니다(예: "제안에서 주문까지", "주문에서 송장까지", "주문에서 배송까지", "아이디어에서 제품까지" 등). 자원을 기반으로 한 전략의 경우 핵심 업무 프로세스는 중앙 기업 기능("주문 획득", "자재 조달 및 제공", "제품 개발", "서비스 제공" 등)을 기반으로 정의되는 경우가 많습니다.

시장 관점이나 리소스 관점에 명확한 초점을 두지 않고 차별화된 관점에서 핵심 비즈니스 프로세스는 일반적으로 CRM, PLM 및 SCM으로 나뉩니다.

  • CRM(Customer Relationship Management)은 고객 확보, 견적 및 주문 작성, 지원 및 유지보수를 위한 비즈니스 프로세스를 설명합니다.
  • PLM(Product Lifecycle Management)은 제품 포트폴리오 계획, 제품 계획, 제품 개발 및 제품 유지 관리에서 제품 중단 및 개별 개발에 이르는 비즈니스 프로세스를 설명합니다.
  • SCM(Supply Chain Management)은 공급업체 관리에서 구매 및 모든 생산 단계에 이르는 비즈니스 프로세스를 설명하며, 해당되는 경우 설치 및 커미셔닝을 포함합니다.
가치 중심 기업을 위한 공정도 예제

그러나 핵심 비즈니스 프로세스를 구조화하는 다른 접근 방식도 일반적입니다. 예를 들어 고객, 제품 또는 판매 채널의 관점에서 볼 수 있습니다.

  • "고객"은 특정 고객 그룹(예: 개인 고객, 비즈니스 고객, 투자자, 기관 고객)에 할당할 수 있는 비즈니스 프로세스를 나타냅니다.
  • "제품"은 제품별 비즈니스 프로세스(예: 경상 계정, 증권 계정, 대출, 발행)를 나타냅니다.
  • "판매 채널"은 고객 확보 및 지원 유형(예: 직접 판매, 파트너 판매, 온라인)에 일반적인 비즈니스 프로세스를 나타냅니다.

기업의 비즈니스 프로세스를 구조화한 결과는 프로세스 맵(예: 가치 사슬 다이어그램으로 표시됨)입니다. Hermann J. Schmelzer와 Wolfgang Sesselmann은 다음과 같이 덧붙입니다. «비즈니스 프로세스 사이에는 연관성과 종속성이 있습니다. 서비스 및 정보 전송을 기반으로 합니다. 비즈니스 프로세스를 이해, 관리 및 제어하려면 이러한 상호 관계를 아는 것이 중요합니다. »

업무 프로세스의 정의

비즈니스 프로세스 정의 예 제품 개발

비즈니스 프로세스의 정의는 종종 회사의 핵심 프로세스에서 시작됩니다.

  • 자체 시장 요구 사항을 충족합니다.
  • 대부분 독립적으로/독립적으로 그리고 다른 사업 영역과 독립적으로 운영됩니다.
  • 회사의 사업 성공에 기여하고,

회사를 위하여

비즈니스 프로세스 정의 예 고객 관계 관리

비즈니스 프로세스의 범위는 관리 가능한 수의 하위 프로세스를 포함하는 동시에 전체 비즈니스 프로세스 수를 합리적인 범위 내에서 유지하도록 선택해야 합니다. 사업 단위당 5~8개의 비즈니스 프로세스는 일반적으로 회사의 성능 범위를 다룹니다.

각 비즈니스 프로세스는 독립적이어야 하지만 프로세스는 상호 연결되어 있습니다.

비즈니스 프로세스의 정의에는 다음이 포함됩니다. 완료 시 달성해야 할 결과는 무엇입니까? 이를 달성하기 위해 어떤 활동이 필요합니까? 처리해야 할 대상(주문, 원자재, 구매, 제품 등)은? 시작점과 종료점을 정의합니다. 운영 목표의 정의.

기업 문화(변화에 대해 더 개방적이거나 현상 유지에 대해 더 보호적임)와 커뮤니케이션에 따라 비즈니스 프로세스를 정의하는 것은 쉬운 작업일 수도 있고 어려운 작업일 수도 있습니다. 이는 조직의 책임 있는 구성원(예: 부서장)이 이를 기꺼이 지원하는지 여부에 따라 달라집니다. 이러한 맥락에서 의사소통은 상당히 중요하며, Jörg Becker와 Volker Meise는 다음과 같이 설명합니다. «조직 설계 측정에서 의사소통 전략의 목적은 » ... (그리고 비즈니스 프로세스 모델링은 일반적으로 비즈니스 프로세스 최적화, 즉 프로세스 조직의 변경이 뒤따릅니다 - 관련 당사자들은 이 사실을 알고 있습니다) ... «조직 구성원들이 계획된 구조를 지지하도록 설득해야 합니다.»[7] 그러나 상당한 저항이 발생하는 경우[7](Chapter 4.15 Influencing the design of the regulatory framework) ← automatic translation from German 외부 지식을 사용하여 비즈니스 프로세스를 정의할 수도 있습니다.

SCRUM으로 "제품 수명주기 관리"를 예시적으로 표현한 가치사슬 다이어그램

일반 공정 식별 및 개별 공정 식별

Jörg Becker와 Volker Meise는 두 가지 접근 방식(일반 프로세스 식별개별 프로세스 식별)을 언급하고 일반 프로세스 식별에 대해 다음과 같이 언급합니다. «일반 프로세스 정의에서는 모든 기업에서 동일한 기본적이고 일반적으로 유효한 프로세스가 존재한다고 가정합니다.» 다음으로 « 상세 참조 모델은 일반 프로세스 식별에도 사용할 수 있습니다. 이들은 개별 사례에 적응해야 하지만 이미 조직 구조가 조정된 조직의 산업 또는 애플리케이션 시스템별 프로세스를 설명합니다. »

Jörg Becker와 Volker Meise는 개별 프로세스 식별에 대해 다음과 같이 말합니다. «개별 또는 단일 프로세스 식별에서 각 기업의 프로세스는 고객의 요구와 경쟁 상황에 따라 다르며 개별 문제 상황에 따라 귀납적으로 식별할 수 있다고 가정합니다. »

비즈니스 프로세스 정의의 결과는 일반적으로 가치 사슬 다이어그램으로서 비즈니스 프로세스의 대략적인 구조입니다.

비즈니스 프로세스의 추가 구조화

비즈니스 프로세스를 하위 프로세스로 분해하는 예 - 마일스톤, 비즈니스 유닛, 데이터 개체 및 IT 시스템으로 보완

지금까지 만들어진 비즈니스 프로세스의 개략적인 구조는 이제 자체 속성을 가지면서도 비즈니스 프로세스의 목표 달성에 기여하는 하위 프로세스로 분해됩니다. 이러한 분해는 비즈니스 프로세스 모델링의 장기적인 성공을 위한 애플리케이션전략에 의해 상당한 영향을 받아야 하며, 이러한 방식으로 정의된 하위 프로세스의 맞춤화가 목적전략 구현에 기여하는 한 계속되어야 합니다.

이렇게 만들어진 하위 프로세스는 회사의 의도된 운영 목표를 달성하기 위해 절차가 수행되는 방식을 설명하기 위해 모델을 사용합니다. 모델은 현실(또는 목표 상태)을 추상화한 것이며, 모델의 구체적인 형태는 용도(애플리케이션)에 따라 달라집니다.

그런 다음 필요한 경우 비즈니스 프로세스 모델링 중에 하위 프로세스를 추가로 분해할 수 있습니다. 비즈니스 프로세스가 마일스톤으로 구분된 일련의 단계로 표현될 수 있다면 단계로 분해되는 것이 일반적입니다. 가능한 경우, 마일스톤을 다음 단계의 분해로 전환하는 것은 일반적인 이해에 기여합니다.

비즈니스 프로세스의 추가 구조화의 결과는 일반적으로 가치 사슬 다이어그램에 표시된 하위 프로세스의 계층 구조입니다. 모든 비즈니스 프로세스의 분해 깊이가 동일하지 않은 것이 일반적입니다. 특히, 안전과 관련이 없고, 비용이 많이 들거나, 운영 목표에 기여하는 비즈니스 프로세스는 훨씬 더 깊이 있게 분해됩니다. 마찬가지로, (훨씬 나중에) 계획된 프로세스의 분해의 예비 단계로서, 공통 이해는 먼저 텍스트 설명이나 거북이 다이어그램[19] 같은 가치 사슬 다이어그램보다 더 간단하거나 덜 복잡한 수단을 사용하여 개발될 수 있습니다(예: 거북이 그래픽과 혼동하지 마십시오!).

프로세스 책임 부여

공정 책임의 피라미드에 대한 표본

완전하고 자체적으로 포함된 프로세스를 요약하여 책임자 또는 팀에게 전달합니다. 프로세스 소유자는 성공에 대한 책임을 지고, 프레임워크 조건을 만들고, 자신의 접근 방식을 다른 프로세스 소유자의 접근 방식과 조정합니다(RACI책임 참조). 나아가 업무 프로세스 간의 정보 교환도 책임집니다. 이러한 조정은 전반적인 목표 지향성을 달성하기 위해 필요합니다.

비즈니스 프로세스 모델링

공정 체인의 설계

특정 IT 시스템 및 모델링 기법을 사용하여 비즈니스 프로세스를 문서화하는 경우 일반적으로 이를 모델링이라고 합니다. 문서의 결과는 비즈니스 프로세스 모델입니다.

PDCA에 중첩된 모델모델이 됨
모델링모델링이 동일합니다.

비즈니스 프로세스 모델을 그대로 모델링을 통해 만들어야 하는지 아니면 모델링을 해야 하는지에 대한 질문은 정의된 애플리케이션비즈니스 프로세스 모델링의 장기적인 성공을 위한 전략에 의해 크게 영향을 받습니다. 비즈니스 활동의 분석, 비즈니스 프로세스의 정의비즈니스 프로세스의 추가 구조화를 포함한 이전 절차는 어떤 경우에도 권장됩니다.

그대로의 모델링

안스가르 슈베그만(Ansgar Schwegmann)과 마이클 라스케(Michael Laske)는 « 현황 파악은 약점을 파악하고 개선 가능성을 현지화하는 기초라고 설명합니다. 예를 들어, 조직의 단절이나 IT 침투 부족과 같은 약점을 파악할 수 있습니다. »

모델링과 마찬가지로 다음과 같은 단점이 있습니다.

  • 다운스트림 목표 모델링에 반영하지 않고 오래된 구조와 프로세스를 채택할 수 있기 때문에 최적의 목표 프로세스를 개발하기 위한 프로젝트에 참여하는 사람들의 창의성이 억제됩니다.
  • 상세한 실제 모델을 만드는 것은 상당한 노력을 나타내며, 또한 인터페이스 및 책임 전환에서 프로젝트 참가자 간의 합의에 도달하는 데 필요한 노력에 의해 영향을 받습니다.

어쨌든 BPR(Business Process Re-engineering)이 계획되어 있는 경우 이러한 주장은 특히 중요합니다.

Ansgar Schwegmann과 Michael Laske모델링의 여러 장점을 나열합니다.[20]

  • 현재 상황을 모델링하는 것은 약점과 개선 가능성을 식별하는 기초가 됩니다.
  • 현재 상태에 대한 지식은 대상 상태로의 마이그레이션 전략을 개발하기 위한 전제 조건입니다.
  • 현재 상태 모델링은 기존 상황에 대한 개요를 제공하며, 이는 특히 새로 참여하는 프로젝트 참가자 및 외부 프로젝트 참가자에게 유용할 수 있습니다.
  • 현재 모델링은 프로젝트 참가자를 교육하고 도구와 방법을 소개하는 출발점이 될 수 있습니다.
  • 현재 모델은 관련 문제가 간과되지 않도록 나중에 대상 모델링을 위한 체크리스트 역할을 할 수 있습니다.
  • 목표 상태가 적어도 일부 영역에서 현재 상황과 매우 유사한 경우 목표 모델링을 위한 시작 모델로 현재 모델을 사용할 수 있습니다.

다음과 같은 다른 이점도 찾을 수 있습니다.

  • 관리시스템 인증 지원에 적합한 모델입니다.
  • 현재 모델은 조직 문서화의 기초가 될 수 있습니다(조직의 서면 규칙, 사양 및 규정 등).
  • 워크플로우 관리를 위한 요구사항은 그대로의 모델(프로세스의 정의, 반복률 등)을 기반으로 확인할 수 있습니다.
  • 개편 후 달성한 주요 수치와 비교하고 조치의 성공 여부를 측정하기 위해 현재 모델을 기반으로 주요 수치를 수집할 수 있습니다.
모델링할 대상

Mario Speck과 Norbert Schnetgöke모델링의 목표를 다음과 같이 정의합니다. «목표 프로세스는 회사의 전략적 목표를 기반으로 합니다. 이는 기업의 모든 하위 프로세스 및 개별 활동을 목표 기여도와 관련하여 분석해야 함을 의미합니다. 따라서 부가가치로 식별할 수 없고 적어도 하나의 비금전적 기업 목적에 부합하지 않는 하위 프로세스나 활동은 비즈니스 프로세스에서 제거해야 합니다.»

또한 모델이 되는 데 있어 가치가 있음을 입증한 5가지 기본 원칙을 나열합니다.

  • 하위 프로세스와 개별 작업을 병렬 처리하는 것이 순차 처리보다 바람직하며, 최적화 가능성이 더 큽니다.
  • 하위 프로세스의 개발은 한 사람 또는 그룹이 가능한 한 일관되게 수행해야 하며, 이를 통해 최상의 모델 품질을 달성할 수 있습니다.
  • 개별 하위 프로세스 및 처리 중 개별 활동에 대해 자체 모니터링이 가능해야 합니다. 이를 통해 품질 보증 비용을 절감할 수 있습니다.
  • 그렇지 않은 경우 각 프로세스에 대해 적어도 한 명의 내부 고객/사용자를 정의해야 합니다. 이는 고객 인식을 강화하고 프로세스 성능의 평가 가능성을 향상시킵니다.
  • 목표 프로세스를 도입하는 동안 발생하는 학습 효과를 고려해야 합니다. 이는 가치 창출에 대한 직원의 인식을 강화합니다.

모델링 또는 모델링할 비즈니스 프로세스 모델은 다음과 같이 구성됩니다.

하위 프로세스

구분
비즈니스 프로세스 세분화 프로세스 판매 파이프라인을 단계에 따라 하위 프로세스로 구분

8월 W. 셰어는 그의 강의에서 다음과 같이 말했다고 합니다. 프로세스는 프로세스입니다. 이는 거의 모든 프로세스가 더 작은 프로세스(하위 프로세스)로 분해될 수 있기 때문에 용어의 재귀성을 표현하기 위한 것입니다. 이 점에서 비즈니스 프로세스, 주 프로세스, 하위 프로세스 또는 기본 프로세스와 같은 용어는 프로세스 분해 수준을 명명하려는 필사적인 시도일 뿐입니다. 비즈니스 프로세스, 주 프로세스, 하위 프로세스 또는 기본 프로세스의 세분화에 대해 보편적으로 유효한 합의가 없기 때문에 용어는 보편적으로 정의되지 않고 각 비즈니스 프로세스 모델의 맥락에서만 이해할 수 있습니다.

또한 일부 독일어권 경영정보학 학교에서는 (행동(활동)의 순서를 나타낸다는 의미에서) 프로세스기능(기업 기능 소유자에게 명확하게 할당된 구분된 기업 기능/행동(활동) 영역이라는 의미에서)이라는 용어를 사용하지 않습니다.

일반적인 회사 조치를 발췌한 함수 트리, 판매 파이프라인 관련 함수 표시

예를 들어, 8월 W. Scheer's ARIS 기능 뷰의 기능을 제어 뷰의 프로세스로 사용할 수 있으며, 그 반대의 경우도 사용할 수 있습니다. 이는 이미 정의된 프로세스나 기능을 전반적으로 재사용할 수 있다는 장점이 있지만, 기능 보기의 적절한 목적이 희석되어 ARIS 사용자가 더 이상 프로세스기능을 서로 분리할 수 없다는 것을 의미하기도 합니다.

첫 번째 이미지는 비즈니스 프로세스 Edit 판매 파이프라인이 단계에 따라 하위 프로세스(행동 순서(활동)를 나타내는 의미)로 어떻게 세분화되었는지를 가치 사슬 다이어그램으로 보여줍니다.

두 번째 이미지는 역량 및 책임 계층의 영역을 기반으로 구성된 전형적인 기능(기업 기능/행동(활동) 영역을 구분하여 기업 기능 소유자에게 할당한다는 의미에서)을 발췌한 것입니다. 비즈니스 프로세스 Edit sales pipeline을 지원하는 기업 기능은 기능 트리에 표시됩니다.

활용도

비즈니스 프로세스는 더 이상 의미 있는 분해가 되지 않을 때까지 하위 processes로 분해될 수 있습니다(smallest 의미 있는 하위 프로세스 = 기본 프로세스). 일반적으로 비즈니스 프로세스의 모든 분해 수준은 동일한 방법론으로 문서화됩니다. 공정 기호. 한 수준의 분해를 모델링할 때 사용되는 프로세스 기호는 일반적으로 기본 프로세스 수준에 도달할 때까지 다음 수준의 하위 프로세스를 나타냅니다. 가치 사슬 다이어그램은 종종 비즈니스 프로세스, 주 프로세스, 하위 프로세스기본 프로세스를 나타내는 데 사용됩니다.

워크플로

워크플로우는 한 사람의 작업, 단순하거나 복잡한 메커니즘, 여러 사람의 그룹,[21] 직원 조직 또는 기계(IT-시스템 포함)의 작업으로 선언된 일련의 작업을 설명하는 것입니다. 따라서 워크플로우는 항상 기본 프로세스 수준에 위치합니다. 워크플로우는 실제 작업의 추상화, 작업 공유, 작업 분할 또는 기타 유형의 순서로 구분되어 표시될 수 있습니다. 제어 목적을 위해 워크플로우는 선택된 측면에서 실제 작업의 뷰일 수 있습니다.

기능(작업)

기본 프로세스의 작업, 세 가지 다른 접근 방식에 의해 결정되는 작업 순서
구분

기능이라는 용어는 종종 기업 기능 소유자에게 할당된 구분된 기업 기능/작업(activita) 영역기본 프로세스 수준의 원자 활동(task)에 대해 동의어로 사용됩니다. 함수라는 용어의 이중적인 의미를 피하기 위해 BPMN의 명명법에 따라 기본 과정 수준의 원자 활동에 작업이라는 용어를 사용할 수 있습니다. 현대의 도구는 작업과정으로 자동 변환하는 기능도 제공합니다. 작업기본 프로세스로 업그레이드해야 하는 프로세스 분해 수준을 언제든지 추가로 생성할 수 있습니다.

활용도

그런 다음 기본 프로세스 수준에서 사용되는 그래픽 요소는 기능(작업)의 도움을 받아 (시간 논리) 시퀀스를 설명합니다. 기본 프로세스 내의 기능(작업)의 순서는 입출력 관계 또는 마일스톤에 의해 아직 지정되지 않은 경우 서로의 논리적 연결(논리 연산자 또는 게이트웨이에 의해)에 의해 결정됩니다. 프로세스를 보다 명확하게 설명하기 위해 추가 그래픽 요소를 사용하여 인터페이스, 상태(이벤트), 조건(규칙), 이정표 등을 설명하는 것이 일반적입니다. 사용되는 모델링 도구에 따라 매우 다른 그래픽 모델링 기술(모델)이 사용됩니다.

프로세스 모델의 가독성을 유지하기 위해 마스터 데이터를 별도의 뷰로 아웃소싱하기 위한 FAD(Function Allocation Diagram) 샘플

또한, 기능(작업)은 설명의 정확성을 향상시키고/또는 세부 정보의 수를 증가시키기 위한 목적으로 입력, 출력, 시스템, 역할 등을 설명하기 위한 그래픽 요소로 보완될 수 있습니다. 그러나 이러한 추가 사항은 모델을 빠르게 혼란스럽게 만듭니다. 설명의 정확성과 명확성 사이의 모순을 해결하기 위해 크게 두 가지 해결책이 있습니다. 입력, 출력, 시스템, 역할 등을 설명하기 위한 추가 그래픽 요소를 FAD(Function Allocation Diagram)에 아웃소싱하거나 질문/응용에 따라 이러한 요소를 선택적으로 표시/숨깁니다. 이미지에 표시된 기능 할당 다이어그램은 기능(작업)에 입력, 출력, 시스템, 역할 등을 설명하기 위한 그래픽 요소를 매우 잘 추가한 것입니다.

마스터 데이터(Artifacts)

마스터 데이터라는 용어는 The Open Group (The Open Group Architecture Framework, TOGAF) 또는 John A. Zachman (Zachman Framework)에 의해 정의되지도 않으며, 비즈니스 정보학의 5개 관련 독일어를 사용하는 학교 중 어느 곳에서도 정의되지도 않습니다. 1) August W. 쉬어, 2) 후베르트 외스테르, 3) 오토 K. Ferstl and Elmar J. Sinz, 4) Hermann Gehring 및 5) Andreas Gadatsch이며 문헌에 적합한 용어가 없을 때 일반적으로 사용됩니다. 운영상 관련된 객체에 대한 기본적인 정보를 나타내는 데이터를 총칭하는 것으로 업무 프로세스의 기본적인 정보가 아닌 기본적인 정보를 의미합니다.

8월 W. ARIS에서 Scheer, 이것은 조직 보기, 데이터 보기, 기능 보기성능 보기의 기본 정보가 될 것입니다.[22] (Chapter 1 The vision: A common language for IT and management) ← automatic translation from German (회사 매핑(독일어) 참조)

Andreas Gadatschin GPM(Ganzheitliche Prozessmodellierung(독일어), 전체적인 프로세스 모델링을 의미)의 경우, 이는 조직 구조 보기, 활동 구조 보기, 데이터 구조 보기애플리케이션 구조 보기의 기본 정보가 될 것입니다.[1] (Chapter 3.2 GPM - Holistic process modelling) ← automatic translation from German (회사 매핑(독일어) 참조)

오토 케이를 위해서. Ferstlund Elmar J. Sinz in SOM(Semantic Objekt modell), 이것이 비즈니스 계획리소스 수준의 기본 정보가 될 것입니다. (회사 매핑(독일어) 참조)

마스터 데이터는 예를 들어 다음과 같습니다(비즈니스 프로세스 모델링을 위한 기능 요구 사항 정의 섹션 참조).

  • 공정이 이루어지는 사업부.
  • 프로세스를 실행하기 위해 정보가 필요한 비즈니스 개체
  • 그 과정에 의해 생산되는 제품
  • 프로세스를 실행할 때 지켜야 할 정책
  • 과정에서 발생하는 위험
  • 공정 능력을 높이기 위해 실시하는 조치
  • 프로세스의 거버넌스를 보장하기 위해 수행되는 제어
  • 비즈니스 프로세스 실행을 지원하는 IT 시스템
  • 프로세스를 프로세스 단계로 나누는 이정표
  • 기타.

비즈니스 프로세스 모델링에 마스터 데이터를 추가함으로써 동일한 비즈니스 프로세스 모델을 다양한 애플리케이션에 사용할 수 있으며, 결과적인 시너지 효과를 통해 비즈니스 프로세스 모델링에 대한 투자 수익을 보다 신속하게 달성할 수 있습니다.

비즈니스 프로세스 모델링에서 마스터 데이터에 얼마나 많은 가치를 부여하는지에 따라, 모델의 가독성에 부정적인 영향을 미치지 않으면서도 마스터 데이터를 프로세스 모델에 내장하거나 마스터 데이터를 별도의 뷰로 아웃소싱하는 것이 여전히 가능합니다. 함수 할당 다이어그램.

마스터 데이터가 비즈니스 프로세스 모델에 체계적으로 추가되는 경우 이를 아티팩트 중심 비즈니스 프로세스 모델이라고 합니다.

아티팩트 중심의 비즈니스 프로세스

아티팩트 중심의 비즈니스 프로세스 모델은 비즈니스 프로세스의 운영 사양을 포착할 수 있는 매우 유연한 솔루션을 제공하기 때문에 비즈니스 프로세스 모델링을 위한 종합적인 접근 방식으로 부상했습니다. 특히 비즈니스 관련 데이터 개체, 수명 주기 및 관련 서비스를 특성화하여 "인공물"로 알려진 비즈니스 프로세스의 데이터를 설명하는 데 중점을 둡니다. 아티팩트 중심 프로세스 모델링 접근 방식은 비즈니스 운영의 자동화를 촉진하고 워크플로우 제정 및 진화의 유연성을 지원합니다.[23]

외부 문서 및 IT 시스템 통합

외부 문서와 IT 시스템을 통합하면 비즈니스 프로세스 모델의 부가가치를 크게 높일 수 있습니다.

예를 들어, 지식 데이터베이스의 객체 또는 규칙 프레임워크의 문서에 직접 액세스하면 일상 생활에서 비즈니스 프로세스 모델의 이점이 크게 증가하여 비즈니스 프로세스 모델링을 수용할 수 있습니다. 관련된 모든 IT 시스템은 특정 이점을 활용하여 서로 교차 수정할 수 있습니다(예: 서로 연결하거나 파일 구조를 표준화하는 것).

  • 지식 데이터베이스의 짧은 응답 시간, 비교적 많은 감사인 수, 매우 빠른 콘텐츠 수정 및 콘텐츠 게시에 대한 낮은 요구 사항을 특징으로 합니다(: 위키로 구현).
  • 규칙 프레임워크를 법적으로 준수하는 문서(예: 문서 관리 시스템 시스템으로 구현된 특수 교육을 받은 감사인 수가 매우 적고, 검증된 내용의 적응 및 내용 공개에 대한 높은 요구 사항을 특징으로 합니다.
  • 프로세스의 그래픽 표현을 BPM 시스템에 의해 통합, 중간 정도의 감사인, 내용의 적절한 적응, 내용의 릴리스에 대한 약간의 요구 사항을 특징으로 합니다.

지식 데이터베이스의 모든 관련 개체 및/또는 규칙 프레임워크의 문서가 프로세스에 연결된 경우 최종 사용자는 이 정보에 대한 컨텍스트 관련 액세스 권한을 가지며 연결된 시스템의 각각의 파일링 구조를 숙지할 필요가 없습니다.

외부 시스템의 직접 연결은 현재 측정 결과 또는 시스템 상태를 프로세스에 통합하는 데에도 사용할 수 있습니다(예를 들어 프로세스의 현재 작동 상태를 표시하는 데 사용할 수 있습니다). 위젯을 표시하고 외부 시스템의 출력을 표시하거나 외부 시스템으로 이동하여 사전 구성된 대화 상자로 트랜잭션을 시작합니다.

외부 시스템에 대한 추가 연결은 예를 들어 전자 데이터 교환(EDI)에 사용될 수 있습니다.

도구들

비즈니스 프로세스 모델링 도구는 비즈니스 사용자에게 비즈니스 프로세스를 모델링하고, 이러한 모델을 구현 및 실행하며, 실행된 데이터를 기반으로 모델을 개선할 수 있는 기능을 제공합니다. 따라서 비즈니스 프로세스 모델링 도구는 비즈니스 프로세스에 대한 투명성을 제공할 수 있을 뿐만 아니라 기업 비즈니스 프로세스 모델과 실행 메트릭을 중앙 집중화할 수 있습니다.[24] 모델링 도구는 또한 사용자가 팀을 이루어 작업하는 복잡한 프로세스를 공동으로 모델링할 수 있으며, 이를 통해 사용자는 공동으로 모델을 공유하고 시뮬레이션할 수 있습니다.[25] 비즈니스 프로세스 모델링 도구는 비즈니스 프로세스 자동화 시스템과 혼동되어서는 안 됩니다. 두 가지 방법 모두 프로세스 모델링을 초기 단계와 동일하게 수행하며, 프로세스 자동화를 통해 '실행 가능한 다이어그램'을 얻을 수 있고 기존 그래픽 비즈니스 프로세스 모델링 도구와는 크게 다르다는 차이점이 있습니다.[citation needed]

모델링 및 시뮬레이션

모델링 및 시뮬레이션 기능을 통해 사전 실행 "What-if" 모델링 및 시뮬레이션이 가능합니다. 실제 수행된 메트릭 분석을 기반으로 실행 후 최적화를 사용할 수 있습니다.[24]

모델링 기법

일부 비즈니스 프로세스 모델링 기법은 다음과 같습니다.

BPMN(Business Process Model and Notification)
정규 흐름을 갖는 프로세스에 대한 비즈니스 프로세스 모델 및 표기법의 예

BPMN(Business Process Model and Notification)은 비즈니스 프로세스 모델에서 비즈니스 프로세스를 지정하기 위한 그래픽 표현입니다.

BPMN은 원래 BPMI(Business Process Management Initiative)에 의해 개발되었으며 2005년 두 조직이 합병된 이후 OMG(Object Management Group)에 의해 유지되고 있습니다. BPMN의 버전 2.0은 2011년 1월에 출시되었으며,[26] 이 시점에서 기존의 공증 및 다이어그램 요소와 함께 도입된 실행 의미론의 도입을 반영하여 비즈니스 프로세스 모델 및 표기법으로 이름이 수정되었습니다. OMG 규격이지만 BPMN도 ISO 19510으로 비준되었습니다. 최신 버전은 2014년 1월에 발행된 BPMN 2.0.2입니다.[27]
라이프사이클 모델링 언어(LML)

라이프사이클 모델링 언어(LML)시스템 엔지니어링을 위해 설계된 개방형 표준 모델링 언어입니다. 개념, 활용, 지원 및 은퇴 단계의 전체 라이프사이클을 지원합니다. 프로그램 관리, 시스템 및 설계 엔지니어링, 검증검증, 배포 및 유지보수를 포함한 모든 라이프사이클 분야를 하나의 프레임워크로 통합합니다.[28] LML은 원래 LML 운영위원회에서 설계한 것입니다. 이 사양은 2013년 10월 17일에 출판되었습니다.

이는 UML, SysML과 같은 모델링 언어로 위험 분석 및 스케줄링과 같은 추가적인 프로젝트 관리 용도를 지원합니다. LML은 공통 언어를 사용하여 엔티티, 속성, 일정, 비용 및 관계와 같은 모델링 요소를 정의합니다.[29]
주체 중심의 업무 프로세스 관리

주체 지향 비즈니스 프로세스 관리(S-BPM)는 비즈니스 프로세스 오케스트레이션 또는 안무를 구성하는 행위자(주체)를 기반으로 한 커뮤니케이션 뷰입니다.[30] 모델링 패러다임은 5개의 심볼을 사용하여 모든 프로세스를 모델링하고 실행 가능한 형태로 직접 변환할 수 있습니다.

각 비즈니스 프로세스는 메시지를 교환하는 두 개 이상의 주제로 구성됩니다. 각 주체는 내부 행동(캡슐화)을 가지며, 이는 서로 다른 상태 간의 제어 흐름으로 정의되며, 이는 메시지를 수신하고 전송하며 무엇인가를 수행합니다. 실용적인 사용과 구문 당화를 위해 더 많은 요소를 사용할 수 있지만 반드시 필요한 것은 아닙니다.

2011년과 2012년에 S-BPM은 가트너의 하이프 사이클(Hyp Cycle)에 포함되었습니다.
인지기능 강화 자연어 정보 분석 방법

인지 강화 자연어 정보 분석 방법(CogNIAM)은 데이터, 규칙, 프로세스 및 의미론과 같은 지식의 다양한 차원을 통합하는 것을 목표로 하는 개념적 사실 기반 모델링 방법입니다. 이러한 차원을 나타내기 위해 OMG(Object Management Group)의 세계 표준 SBVR, BPMNDMN이 사용됩니다. NIAM의 후계자인 CogNIAM은 지식 과학자 Sjir Nijssen의 연구를 기반으로 합니다.[citation needed]

CogNIAM은 사람, 문서 및 소프트웨어에서 수집한 지식을 분류하여 구조화합니다. 이를 위해 CogNIAM은 이른바 '지식 삼각형'을 사용합니다.[31] CogNIAM의 결과는 적용하는 사람과 무관합니다. 결과 모델을 사용하면 지식을 다이어그램 형식뿐만 아니라 제어된 자연어로 표현할 수 있습니다.[32]
이벤트 기반 프로세스 체인(EPC)
보다 복잡한 EPC 다이어그램의 예(독일어).

EPC(Event-Driven Process Chain)는 비즈니스 프로세스 모델링을 위한 흐름도의 한 유형입니다. EPC는 엔터프라이즈 리소스 계획 실행을 구성하고 비즈니스 프로세스 개선을 위해 사용할 수 있습니다. 작업 공유에서 자동 워크플로우 인스턴스를 제어하는 데 사용할 수 있습니다.

이벤트 기반 프로세스 체인 방식은 1990년대 초에 August-Wilhelm Scheer에 의해 Universität des Saarlandes(Saarlands 대학의 비즈니스 정보 시스템 연구소)의 통합 정보 시스템 아키텍처(ARIS) 프레임워크 내에서 개발되었습니다.[33]
통합 정의(IDEF)
IDEF 방식: 시스템 엔지니어 툴박스의 일부

IDEF는 처음에는 ICAM Definition의 줄임말로 1999년에 Integration Definition으로 이름이 변경된 시스템 및 소프트웨어 엔지니어링 분야의 모델링 언어 계열입니다. 기능 모델링에서 데이터, 시뮬레이션, 객체 지향 분석 및 설계, 지식 습득에 이르기까지 광범위한 용도를 다룹니다. 이러한 정의 언어들은 미 공군의 자금 지원 하에 개발되었으며, 여전히 그 언어들과 다른 군사 및 미 국방부(DoD) 기관들에 의해 가장 일반적으로 사용되고 있지만, 공공 영역에 있습니다.

IDEF 제품군 중 가장 널리 인식되고 사용되는 구성 요소는 SADT의 기능 모델링 언어 빌드인 IDEF0과 정보 모델 및 데이터베이스 설계 문제를 해결하는 IDEF1X입니다.
통합 모델링 언어(UML)
UML 로고

통합 모델링 언어(UML)는 시스템 설계를 시각화하는 표준 방법을 제공하기 위한 범용 시각 모델링 언어입니다.[34]

UML은 행동 다이어그램, 상호 작용 다이어그램, 구조 다이어그램의 세 가지 주요 그룹으로 나눌 수 있는 많은 유형의 다이어그램에 대한 표준 표기법을 제공합니다.

UML을 만든 것은 원래 소프트웨어 설계에 대한 서로 다른 표기 체계와 접근 방식을 표준화하려는 욕구에서 비롯되었습니다. 1994-1995년 Rational Software에서 개발되었으며 1996년까지 Rational Software가 주도했습니다.[34]

1997년, UML은 OMG(Object Management Group)에 의해 표준으로 채택되었고, 그 이후로 이 조직에 의해 관리되고 있습니다. 2005년에는 국제표준화기구(ISO)와 국제전기기술위원회(IEC)에서도 ISO/IEC 19501 표준으로 UML을 발표하였습니다.[35] 그 이후로 UML의 최신 개정 사항을 다루기 위해 주기적으로 표준이 개정되었습니다.[36]

소프트웨어 공학에서 대부분의 실무자는 UML을 사용하지 않고 비공식적으로 손으로 그린 다이어그램을 생성합니다. 그러나 이러한 다이어그램에는 종종 UML의 요소가 포함됩니다.[37]: 536
형식화된 행정 표기법(FAN)
공식화된 관리 표기법(FAN)은 다양한 조직의 관리자가 운영의 흐름과 순서를 설명하고 책임을 식별하며 트랜잭션을 정의하고 통합할 수 있도록 하는 방법입니다. 그 목적은 추가적인 시스템화를 위해 특정 시스템을 구현하는 모드를 공식화하는 것입니다. 원래 스페인어로 MECAF(Metodo de expression de circuitos administrativeos formalizado)라고 불림
HPM(Harbarian Process Modeling)
HPM 공정도

HPM(Harbarian Process Modeling)은 조직에서 내부 프로세스 정보를 얻은 다음 시각적으로 효과적이고 간단한 방식으로 해당 정보를 문서화하는 방법입니다.

HPM 방식에는 두 가지 레벨이 포함됩니다.

  1. 공정 다이어그램: 특정 프로세스 또는 워크플로우에 대한 높은 수준의 개요.
  2. 시스템 다이어그램: 각 프로세스의 상관관계는 물론 다양한 입력, 출력, 목표, 피드백 루프 및 외부 요인을 매핑합니다.

프로그래밍 언어 도구

BPM 제품군 소프트웨어는 BPM 엔진을 활용하기 위해 엔터프라이즈 애플리케이션을 구축할 수 있는 프로그래밍 인터페이스(웹 서비스, 애플리케이션 프로그램 인터페이스(API))를 제공합니다.[24] 이 구성 요소는 종종 BPM 제품군의 엔진으로 언급됩니다.

BPM을 위해 도입되는 프로그래밍 언어는 다음과 같습니다.[38]

일부 공급업체별 언어:

비즈니스 프로세스 모델링과 관련된 다른 기술로는 모델 중심 아키텍처와 서비스 중심 아키텍처가 있습니다.

관련개념

사업참조모델

미국 연방정부 비즈니스 레퍼런스 모델의[39]

비즈니스 참조 모델기업, 서비스 조직 또는 정부 기관의 기능적 및 조직적 측면에 초점을 맞춘 참조 모델입니다. 일반적으로 참조 모델은 어떤 것의 기본 목표나 아이디어를 구현하고 다양한 목적을 위한 참조로 살펴볼 수 있는 어떤 것의 모델입니다. 비즈니스 참조 모델은 조직의 비즈니스 운영을 수행하는 조직 구조와 무관하게 설명하는 수단입니다. 다른 유형의 비즈니스 참조 모델은 비즈니스 프로세스, 비즈니스 기능 및 비즈니스 영역의 비즈니스 참조 모델 간의 관계를 나타낼 수도 있습니다. 이러한 참조 모델은 계층별로 구성할 수 있으며 서비스 구성 요소, 기술, 데이터 및 성능 분석을 위한 기반을 제공합니다.

가장 익숙한 비즈니스 참조 모델은 미국 연방 정부의 비즈니스 참조 모델입니다. 이 모델은 이를 수행하는 기관과는 별개로 연방 정부의 비즈니스 운영을 설명하기 위한 기능 중심 프레임워크입니다. 비즈니스 참조 모델은 연방 정부의 일상적인 비즈니스 운영을 설명하기 위한 조직적이고 계층적인 구성을 제공합니다. 조직도, 위치도 등 조직을 설명하기 위한 많은 모델이 존재하지만, 이 모델은 기능 중심 접근 방식을 사용하여 비즈니스를 제시합니다.[40]

업무 프로세스 통합

비즈니스 프로세스와 데이터 모델[41] 간의 상호 작용 예

비즈니스 프로세스 모델의 정교화로 간주될 수 있는 비즈니스 모델은 일반적으로 비즈니스 데이터 및 비즈니스 조직과 비즈니스 프로세스를 보여줍니다. 비즈니스 프로세스와 정보 흐름을 보여줌으로써 비즈니스 이해 관계자가 비즈니스 엔터프라이즈를 정의, 이해 및 검증할 수 있도록 하는 비즈니스 모델을 제공합니다. 비즈니스 모델의 데이터 모델 부분은 비즈니스 정보가 저장되는 방식을 보여주며, 이는 소프트웨어 코드를 개발하는 데 유용합니다. 비즈니스 프로세스 모델과 데이터 모델 간의 상호 작용 예는 오른쪽 그림을 참조하십시오.[41]

일반적으로 비즈니스 모델은 비즈니스 분석 프로세스의 일부인 인터뷰를 수행한 후 생성됩니다. 인터뷰는 퍼실리테이터가 주제 비즈니스 프로세스에 대한 정보를 추출하기 위해 일련의 질문을 하는 것으로 구성됩니다. 인터뷰 진행자는 비즈니스 프로세스 정보를 제공하는 사람은 진행자가 아니라 참가자임을 강조하기 위해 진행자로 언급됩니다. 퍼실리테이터가 해당 비즈니스 프로세스에 대한 지식을 어느 정도 가지고 있어야 하지만, 이는 비즈니스 전문가를 인터뷰하는 실용적이고 엄격한 방법의 숙달만큼 중요하지 않습니다. 이 방법은 대부분의 기업에서 기업 전체의 정보를 수집하기 위해 촉진자 팀이 필요하며, 모든 면담자의 결과를 작성하고 통합해야 하기 때문에 중요합니다.[41]

비즈니스 모델은 프로세스의 현재 상태를 정의하는 것으로 개발되며, 이 경우 최종 제품은 "있는 그대로" 스냅샷 모델 또는 프로세스가 무엇이 되어야 하는지에 대한 개념으로 "있는 그대로" 모델이 됩니다. 비즈니스 분석가는 "있는 그대로"와 "있는 그대로" 모델을 비교 및 대조함으로써 기존 비즈니스 프로세스와 정보 시스템이 건전하고 약간의 수정만 필요한지, 또는 문제를 수정하거나 효율성을 개선하기 위해 재설계가 필요한지 여부를 판단할 수 있습니다. 따라서 비즈니스 프로세스 모델링 및 후속 분석을 통해 기업의 운영 방식을 근본적으로 재구성할 수 있습니다.[41]

비즈니스 프로세스 재엔지니어링

비즈니스 프로세스 리엔지니어링 주기 다이어그램

비즈니스 프로세스 리엔지니어링(BPR)은 조직 내 및 조직 전반에 존재하는 프로세스효율성과 효과를 개선하는 것을 목표로 합니다. 비즈니스 프로세스를 "깨끗한 슬레이트" 관점에서 검토하여 최적의 구성 방법을 결정합니다.

비즈니스 프로세스 재공학(BPR)은 조직이 업무를 수행하는 방식을 근본적으로 재고할 수 있도록 지원하기 위한 민간 부문 기술로 시작되었습니다. 리엔지니어링의 핵심 자극제는 정교한 정보 시스템과 네트워크의 개발과 배치였습니다. 선도적인 조직은 현재의 업무 방식을 개선하는 대신 혁신적인 비즈니스 프로세스를 지원하기 위해 이 기술을 사용합니다.[42]

업무프로세스관리

기사 업무 프로세스 관리 참조.

변경 관리 프로그램은 일반적으로 개선된 비즈니스 프로세스를 실행하기 위해 사용됩니다. 소프트웨어 설계의 발전으로 BPM 모델이 완전히 실행 가능해지고(그리고 시뮬레이션 및 왕복 엔지니어링이 가능해지는) 비전이 현실에 가까워지고 있습니다.

프로세스 모델의 적응

비즈니스 프로세스 관리에서는 프로세스 흐름을 정기적으로 검토하고 필요한 경우 최적화(적응)합니다. 이러한 프로세스 흐름의 적응은 지속적인 개선 프로세스 또는 비즈니스 프로세스 리엔지니어링에 의해 유발되는지에 관계없이 개별 하위 프로세스 또는 전체 비즈니스 프로세스를 업데이트하는 것을 수반합니다.

참고 항목

참고문헌

  1. ^ a b c d Andreas Gadatsch: Management von Geschäftsprozessen / Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker, 2차 개정 및 확장판, Vieweg, Braunschweig/Wiesbaden 2002, ISBN 978-3-528-15759-3
  2. ^ a b c d e f g h i 헤르만 J. 슈멜저와 볼프강 세셀만: Geschäfts profess in der Praxis, 9th Edition, Hanser, Munich 2020, ISBN 978-3-446-44625-0
  3. ^ a b c d e f g h i j k Michael Rosemann, Ansgar Schweegmann and Patrick Delfmann: Vorbeitung der Prozessmodellierung in Jörg Becker, Martin Kugler and Michael Rosemmamm(출판사): Prozess management: Ain Leitfaden zur Prozessorientierten Organizationgestaltung, 2차 수정 및 확장판, Springer, Berlin/Heidelberg/New York 2002, ISBN 978-3-540-00107-2
  4. ^ a b 유럽 비즈니스 프로세스 관리 협회 EABPM(출판사): 비즈니스 프로세스 관리 공통 지식 기관 - BPMCBOK®, 2차 버전, Verlag Dr. Götz Schmidt, Gie ßen 2009, ISBN 978-3-921313-80-0
  5. ^ 지식 데이터베이스: 6 einfachen Schritenzur Prozesslandkarte, DER PROZESS MANGER GmbH (마지막 접속: 2024년 1월 25일)
  6. ^ 요르크 베커(Jörg Becker)와 디터 칸(Dieter Kahn): Der Prozessim Fokus in Jörg Becker, Martin Kugler and Michael Rosemammamm(출판사): Prozess management: Ein Leitfaden zur Prozessiorienterten Organizationgestaltung, 2차 수정 및 확장판, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
  7. ^ a b c d e f g 요르크 베커와 볼커 마이스: Jörg Becker, Martin Kugler 및 Michael Rosemammamm(출판사): Prozess management: Ain Leitfaden zur prozessorientierten Organizationgestaltung, 2차 수정 및 확장판, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
  8. ^ a b Mario Speck and Norbert Schnetgöke: Solmodellierung und Prozessoptimierung in Jörg Becker, Martin Kugler and Michael Rosemammamm(출판사): Prozess management: Ain Leitfaden zur Prozessorientierten Organizations gestaltung, 2차 수정 및 확장판, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
  9. ^ 토마스 듀프렌 & 제임스 마틴 (2003). "E-Business를 위한 프로세스 모델링". 정보 시스템 엔지니어링을 위한 INFS 770 방법: 지식 관리 및 E-Business. 2003년[dead link]
  10. ^ Williams, S. (1967) "비즈니스 프로세스 모델링으로 관리 제어 향상", In: Automation. 1967년 12월, 44-50쪽.
  11. ^ a b Asbjørn Rolstadås (1995). "비즈니스 프로세스 모델링 및 리엔지니어링" in: 성과관리: 비즈니스 프로세스 벤치마킹 접근법 p. 148-150.
  12. ^ 브라이언 C. 워보이즈 (1994). 소프트웨어 프로세스 기술: 제3차 유럽 워크숍 EWSPT'94, 프랑스 빌라드 드 랑스, 1994년 2월 7일-9일: 진행. 252쪽.
  13. ^ John Miltenburg, David Sparling: 총 순환 시간 관리감소: Elsevier International Journal of Production Economics, 1996, 12월, 89-108페이지
  14. ^ 마이클 몰터: Die Prozesse orientete Applications Landshaft 8월-W. 셰어, 볼프람 요스트, 칼 바그너(출판인): Von Prozess modellen zu laffähigen Anwendungen, 스프링어 베를린, 하이델베르크, 2005, ISBN 3-540-23457-8
  15. ^ N. Venkat Venkatraman: M. S. Scott Morton(출판사)의 IT로 인한 비즈니스 재구성: 1990년대 주식회사: 정보기술과 조직의 변혁, 초판, 옥스퍼드 대학교 출판부 1991, ISBN 978-0-19-506358-5
  16. ^ Thomas H. Davenport: 프로세스 혁신: 정보기술을 통한 리엔지니어링 작업, Harvard Business Press, Boston 1993, ISBN 978-0-87584-366-7
  17. ^ 마이클 M. 망치, 제임스 A. 챔피: 회사 재설계: 비즈니스 혁명을 위한 선언문, 하퍼 비즈니스, 1993, ISBN 978-0-88730-640-2
  18. ^ 마틴 쿠글러: 공급망 관리 고객 관계 관리 - Jörg Becker, Martin Kugler 및 Michael Rosemammamm의 확장 기업(출판사): Prozess modellierung für 확장 기업: Ain Leitfaden zur Prozessorientierten Organizationgestaltung, 2. 수정 및 확장판, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
  19. ^ a b Timo Füerman: Prozess management: Kompaktes Wissen, Konkrete Umsetzung, Praktische Arbeitshilfen, Hanser, München 2014, ISBN 978-3-446-43858-3
  20. ^ a b 안스가르 슈베그만과 마이클 라스케: Istmodellierung und Istanalyse in Jörg Becker, Martin Kugler and Michael Rosemammamm(출판사): Prozess management: Ain Leitfaden zur prozessorienterten Organizationgestaltung, 2차 수정 및 확장판, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-00107-7
  21. ^ 예: ISO 12052:2006 참조
  22. ^ 8월-W. 샤이어: ARIS: 8월-W에 Von der Vision zur praktischen Geschäftsprozess steuerung. Scheer and Wolfram Jost(Hrsg): ARIS inder Praxis: Gestaltung, Impelierung und Optimierung von Geschäftsprozessen, Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-43029-6
  23. ^ Yongchareon, Sira (2015). "A View Framework for Modelling and Change Validation of Artifact-Centric Inter-Organizational Business Processes". Information Systems. 47: 51–81. doi:10.1016/j.is.2014.07.004.
  24. ^ a b c 2007년 6월 27일 Wayback Machine에서 Workflow/Business Process Management(BPM) 서비스 패턴 아카이브 2009-01-13. 2008년 11월 29일 접속.
  25. ^ Christensen, Lars Rune & Thomas Hildebrandt (2017) 의료 부서의 모델링 협력 작업. 제8차 지역사회 및 기술에 관한 국제회의 의사진행. 트로이, 프랑스. ACM.
  26. ^ OMG. "BPMN 2.0". Retrieved 2011-03-29.
  27. ^ "About the Business Process Model and Notation Specification Version 2.0.2". www.omg.org. Retrieved 2020-12-07.
  28. ^ LML Steering Committee. "LML Specification". Retrieved 2023-03-01.
  29. ^ "About Lifecycle Modeling Language". LML Steering Committee. Retrieved 2014-06-05.
  30. ^ Fleischmann, Albert; Stary, Christian (2011). "Whom to talk to? A stakeholder perspective on business process development". Universal Access in the Information Society. 11 (2): 1–28. doi:10.1007/s10209-011-0236-x.
  31. ^ 쉬르 니센과 앙드레 르 캣. Kennis Gebaseerd Werken], 2009. p. 118-148
  32. ^ 니센, 헤라두스 마리아, 테렌스 아이단 할핀. 개념 스키마와 관계형 데이터베이스 설계: 사실 지향적 접근. 프렌티스 홀 주식회사 1989.
  33. ^ <transoldtip="A.-W. Scheer (2002). " newtip="A"-W.Scheer(2002年)。">A.-W.셰이어(2002 年) </ </trans><transold tip="ARIS. Vom Geschäftsprozess zum Anwendungssystem" newtip="阿里斯。vm Gesch ftsprozess zum Anwendungssystem">阿里斯。vm Geschftsprozess zum Anwendungs system</trans>. 스프링어. 20쪽.
  34. ^ a b , Unified Modeling Language User Guide, The (2 ed.). Addison-Wesley. 2005. p. 496. ISBN 0321267974. 샘플 내용 보기, 이력 찾기
  35. ^ "ISO/IEC 19501:2005 - Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.3". Iso.org. 2005-04-01. Retrieved 2015-05-07.
  36. ^ "ISO/IEC 19505-1:2012 - Information technology - Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure". Iso.org. 2012-04-20. Retrieved 2014-04-10.
  37. ^ Baltes, Sebastian; Diehl, Stephan (2014-11-11). "Sketches and diagrams in practice". Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. FSE 2014. Hong Kong, China: Association for Computing Machinery. pp. 530–541. arXiv:1706.09172. doi:10.1145/2635868.2635891. ISBN 978-1-4503-3056-5. S2CID 2436333.
  38. ^ "Business Process Modelling FAQ". Archived from the original on 2008-11-09. Retrieved 2008-11-02.
  39. ^ FEA (2005) FEA 레코드 관리 프로파일, 버전 1.0. 2005년 12월 15일.
  40. ^ Wayback Machine에서 보관FEA 통합 참조 모델 문서 2010-10-11. 2007년 10월.
  41. ^ a b c d 폴 알. Smith & Richard Sarfaty (1993). CASE(Computer Aided Software Engineering) 도구를 사용하여 구성 관리를 위한 전략 계획을 작성합니다. 1993년 국가 DOE/계약자 및 시설 CAD/CAE 사용자 그룹을 위한 문서.
  42. ^ 비즈니스 프로세스 리엔지니어링 평가 가이드, Wayback Machine에서 보관, 1997년 5월.

추가읽기

외부 링크