1. EPC 기능 다이어그램은 최소한 하나의 시작 이벤트(시작 이벤트는 프로세스 인터페이스를 따를 수 있음)로 시작하고 최소한 하나의 종료 이벤트(종료 이벤트는 프로세스 인터페이스 앞에 올 수 있음)로 끝나야 합니다.

2. 프로세스가 진행되는 동안 이벤트와 기능이 번갈아 진행되어야 합니다. 프로세스의 추가 과정에 대한 결정은 기능별로 이루어집니다.

3. 다이어그램의 권장 기능 수는 20개 이하입니다. 다이어그램의 기능 수가 20개를 크게 초과하는 경우 최상위 프로세스가 잘못 식별되어 모델을 조정해야 할 가능성이 있습니다. .

4. 이벤트 및 기능에는 프로세스 진행 상황을 반영하여 엄격하게 하나의 수신 연결과 하나의 출력 연결이 포함되어야 합니다.

5. 위 다이어그램의 기능을 둘러싼 이벤트 및 명령문( 그림 16)는 함수 분해 다이어그램의 초기/결과 이벤트 및 명령문이어야 합니다( 그림 17).

6. 다이어그램에는 단일 연결이 없는 개체가 포함되어서는 안 됩니다.

7. 각 병합 운영자는 최소한 두 개의 들어오는 연결과 하나의 나가는 연결만 가져야 하며, 분기 운영자는 최소한 두 개의 들어오는 연결과 최소한 두 개의 나가는 연결을 가져야 합니다. 운영자는 동시에 여러 개의 수신 및 발신 연결을 가질 수 없습니다.

8. 운영자가 "이벤트" 요소에서 들어오는 연결이 있는 경우 "기능" 요소로 나가는 연결이 있어야 하며 그 반대의 경우도 마찬가지입니다.

9. 단일 이벤트 뒤에는 "OR" 또는 "XOR" 연산자가 올 수 없습니다.

10. 연산자는 기능만 또는 이벤트만 결합하거나 분기할 수 있습니다. 기능과 이벤트의 동시 병합/분기는 불가능합니다.

11. 분기를 분기하는 연산자와 이러한 분기를 병합하는 연산자가 일치해야 합니다. 분기 연산자 “AND”와 합집합 연산자 “OR”을 사용할 수도 있습니다.

허용되는 상황의 예( 그림 18, 그림 19, 그림 20, 그림 21):

그림 18	그림 19	그림 20	그림 21

받아들일 수 없는 상황의 예( 그림 22).

ARIS 툴킷에서 비즈니스 프로세스를 모델링하는 데 사용되는 ARIS EPC 표기법은 특정 결과 달성을 목표로 상호 연관된 작업을 수행하는 논리를 반영하는 일련의 이벤트 및 기능입니다.

ARIS EPC 모델은 일련의 이벤트 중심 기능 형태로 비즈니스 프로세스를 실행하기 위한 알고리즘을 설명하기 위한 것입니다. ARIS EPC 모델은 기능의 순서에 중점을 두고 비즈니스 프로세스 모델의 조건을 설명하기 위해 비즈니스 프로세스를 실행하기 위한 복잡한 알고리즘을 설명할 수 있는 이벤트와 규칙을 사용합니다.

ARIS EPC 모델의 기능은 "송장 승인 수신"과 같은 이벤트에 의해 트리거되고 "송장이 승인됨" 또는 "송장이 승인되지 않음"과 같은 이벤트로 끝납니다. 기능을 실행한 결과 비즈니스 프로세스를 추가로 실행할 수 있는 옵션이 하나만 있는 경우, 즉 결과적으로 하나의 이벤트만 생성되고 그 이후에는 다음 함수가 오게 되는데, 이들 함수 사이의 이벤트는 그려지지 않을 수도 있습니다.

ARIS EPC 표기법의 비즈니스 프로세스 모델은 반드시 하나 이상의 이벤트 또는 다른 비즈니스 프로세스 모델에 대한 인터페이스로 시작하고 끝납니다. 인터페이스를 반영하기 위해 특수 객체인 "프로세스 인터페이스"(객체 유형 "함수")가 사용됩니다.

ARIS EPC 모델을 생성할 때 동일한 문서가 한 기능에 대해 나가는 문서이고 다음 기능에 대해 들어오는 문서인 상황이 발생할 수 있습니다. 이러한 경우 모델의 인체 공학적 측면을 개선하기 위해 하나의 들어오는 연결(생성되거나 조정된 기능에서)과 하나의 나가는 연결(사용되는 기능으로)이 있는 하나의 문서 표현을 사용하는 것이 허용됩니다. .

EPC 모델은 연결을 끊을 수 없습니다. 다른 개체와 연결되지 않은 개체를 모델에 배치하면 오류가 발생합니다.

기능과 관련된 문서의 위치는 일반적으로 다음과 같습니다. 왼쪽 상단에는 수신 문서가 있고 왼쪽 하단에는 발신 문서가 있으며 수행자는 일반적으로 기능 오른쪽에 위치합니다.

ARIS EPC 모델에는 다음 정보가 표시됩니다.

• 수행되는 기능
• 기능 정보 자원(수신/발신 문서)
• 이벤트
• 프로세스 인터페이스
• 논리 연산자
• 수행자(직위, 비즈니스 역할)
• 정보 시스템

ARIS EPC의 이벤트 명명 규칙

이벤트 이름에는 상태 변경에 대한 명사와 구두 설명이 포함되어야 합니다. 예: '거래가 완료되었습니다.'

ARIS EPC의 함수 명명 규칙

함수의 이름을 지정하려면 실제 이름을 사용해야 합니다. 이름은 수행되는 기능을 설명하는 동사 명사와 해당 기능이 수행되는 개체를 나타내는 명사의 두 부분으로 구성되어야 합니다. 기능 이름은 "고객 연락처 검색"과 같이 대문자로 시작하는 개체의 짧은 이름으로 구성됩니다.

ARIS EPC에서 역할/직위 명명 규칙

비즈니스 역할의 이름(개인 유형)은 수행자에게 할당된 책임의 본질과 일치해야 합니다. 원칙적으로 제목에는 "...에 대한 책임"이라는 문구가 포함됩니다. 직위(직위)는 직원 배치표에 따라 작성됩니다.

문서 명명 규칙

객체는 문서(정보 매체)(종이 및/또는 전자 형식)에 해당합니다. 문서에 이름을 지정하려면(사용된 기호에 관계없이) 실제 이름을 사용해야 합니다.

ARIS EPC의 정보 시스템 명명 규칙

정보 시스템(응용 시스템 유형)의 이름을 지정하려면 확립된 이름을 사용해야 합니다.

프로세스 인터페이스 명명 규칙

프로세스 인터페이스는 인접한 프로세스에 대한 링크를 표시합니다. 프로세스 인터페이스의 이름은 비즈니스 프로세스의 인접한 부분을 설명하는 모델의 이름에 해당합니다. 인터페이스는 설명되는 비즈니스 프로세스의 일부가 아닌 비즈니스 프로세스 모델을 참조하는 데 사용될 수 있습니다.

"연, 맹인의 버프 및 태그
숨바꼭질, 공, 도약, 줄넘기,
그리고 간단하고 간단하며 줄넘기 만하면됩니다.
음, 간단하고 간단합니다. 줄넘기만 하면 됩니다!!!”

A. 브라타레프

이 기사를 준비하는 동안 나는 놀라운 사실을 발견했습니다. EPC 표기법에 대해 매우 간단하고 인기가 있으며(BPMN보다 더 인기가 있다는 의견이 있습니다) Wikipedia에는 ​​영어, 독일어, 체코어의 4개 언어로만 작성된 기사가 있습니다. 그리고 우즈벡어. 게다가 이 글들은 꽤 짧습니다. 아마도 기사가 끝날 무렵 독자 여러분과 저는 그 이유를 이해하게 될 것입니다.

EPC 표기법이 1990년대 초에 개발되었다는 사실부터 시작하겠습니다. ARIS 방법론을 개발하는 동안 프로세스 구성 요소로 사용됩니다. EPC의 창시자는 Wilhelm-August Scheer 교수로 간주됩니다. 그의 이름만으로도 일반인은 경외감을 느끼게 됩니다(큰 소리로 말하고 영감을 얻습니다). 이 존경받는 사람이 일했던 교수진의 이름에 대해 무엇을 말할 수 있습니까? University Universität des Saarlandes의 Institut für Wirtschaftsinformatik입니다.

EPC 표기법을 만드는 목적은 프로세스 내에서 수행되는 기능이 다이어그램 내에서 전역 의미를 갖도록 프로세스를 설명하는 기능이었습니다. 즉, EPC 다이어그램의 기능 실행이 반드시 명확하게 정의되는 것은 아니지만 프로세스에 따라 달라질 수 있습니다. 다이어그램의 다른 노드 상태, 때로는 서로 매우 멀리 떨어져 있음.

표기법의 이름은 Event-driven Process Chain을 의미하며, 이는 EPC 표기법 다이어그램의 중심 요소가 이벤트임을 명확하게 나타냅니다. 이벤트는 특정 참가자의 특정 작업 수행을 발생시킵니다. 작업이 완료되면 또 다른 이벤트가 생성되고 시스템이 프로세스 내에서 나타나는 상태가 최종 이벤트로 간주되는 상태에 도달할 때까지 계속됩니다.

표기법의 기능을 명확하게 보여주기 위해 최근 따뜻한 기후에서 완료된 휴가에서 영감을 받은 일상적인 예를 사용하겠습니다. 존경받는 호텔인 Ivo Petkov의 접수원은 손님 중 한 명으로부터 자신의 방에 있는 세면대를 긴급 교체해 달라는 요청을 받습니다. 그의 임무는 고객의 요청을 이행하는 것이며 EPC 용어로 시스템을 "클라이언트로부터 세면대 교체 요청을 받았습니다" 상태에서 "클라이언트의 요청이 충족되었습니다" 상태로 만드는 것임이 분명합니다.

초안 다이어그램에 표시된 두 가지 상태를 표시하면 다이어그램이 얼마나 읽기 쉬운지 즉시 알 수 있습니다. 각 요소에는 고유한 모양뿐만 아니라 고유한 색상도 있기 때문입니다. 따라서 이벤트는 빨간색 육각형으로, 기능은 모서리가 둥근 녹색 직사각형으로, 공연자는 노란색 타원으로 표시됩니다.

그럼 예로 돌아가 보겠습니다. Ivo는 클라이언트로부터 요청을 받은 직후에 가정부에게 클라이언트의 요청을 이행하기 위한 요청을 보내야 하며, 이를 통해 시스템은 "Fulfillment request sent(이행 요청 전송됨)" 상태가 됩니다. 하녀는 창고에 있는 물품을 사용하여 Ivo의 요청을 이행합니다. 그리고 여기에서 처음으로 프로세스의 병렬화가 나타납니다. 가정부가 필요한 세탁 용품(예: 샤워 젤)이 현재 재고가 없다는 것을 이해하면 아마도 마지 못해 시스템을 "Fulfillment of 요청이 불가능합니다” 상태에서 Ivo는 고객과 그리 유쾌하지 않은 대화를 해야 하며 시스템이 어떤 상태로 갈지는 고객의 성향과 싸우는 경향에만 달려 있습니다. 창고에 손님에게 필요한 모든 물품이 있는 경우 가정부는 자신에게 전달된 요청을 성공적으로 이행하고 Ivo에 이행을 보고하며 Ivo는 이를 고객에게 보고합니다. 그리고 모두가 행복하게 살다가 같은 날 죽는다.

이 간단한 프로세스는 그림 1과 같이 즐겁게 윙크하는 빨간색, 녹색, 노란색 다이어그램에 반영됩니다.

쌀. 1. 호텔에서 고객 요청을 처리하는 과정을 보여주는 EPC 다이어그램

그리고 이제 전통에 따르면 표기법의 장점과 단점이 설명됩니다.

EPC 다이어그램을 처음 접했을 때, 앞서 언급했듯이 읽기가 매우 쉽다는 점에 매우 만족했습니다. 각 블록은 모양과 색상으로 강조 표시되어 있으며 수행자, 필요한 자료, 목록을 강조 표시하는 것이 매우 쉽습니다. 가능한 시스템 상태, 기능 프로세스 중에 수행되는 상태 목록입니다. 이것은 의심할 여지 없이 큰 장점입니다. 고객은 EPC 표기법으로 표시되는 경우 EDMS를 구현할 때 비즈니스 프로세스 다이어그램을 읽는 데 어려움을 겪지 않을 것입니다. 그러나 아마도 고객은 그렇게 많은 수의 상태로 인해 혼란을 겪을 것입니다. 실제로 그 상태로 인해 회로가 크게 성장하기 때문입니다. 우리의 예에서도 일부 4개의 함수는 최대 5개의 상태를 생성했습니다(초기 상태는 포함하지 않음). 때때로 당신은 궁금해합니다: 왜 그것들을 모두 지적합니까? 예를 들어, 총책임자의 계약에 동의한 후 별도의 블록에 "계약이 동의되었습니다"를 표시하고 서명한 후 "계약이 서명되었습니다"를 표시해야 하는 이유는 무엇입니까? 추가 프로세스가 여전히 남아 있는 경우 선의. 솔직히 말하면 캡틴 오비어스가 아닌 이상 그럴 필요는 없습니다.

그리고 때로는 함수가 시스템을 전환할 상태를 식별하는 방법이 명확하지 않은 경우도 있습니다. 이 간단한 예를 준비하는 동안에도 바로 이 순간과 관련된 몇 가지 어려움을 겪었습니다.

EPC 다이어그램의 장점은 IDEF0 다이어그램과 마찬가지로 각 기능의 입력 및 출력 데이터를 표시하고 블록 간 입력 및 출력 데이터 이동 논리를 추적할 수 있다는 점입니다. 또한 동일한 IDEF0과 달리 프로세스를 병렬화하여 대체 분기 중 하나만 따라갈 수 있게 되었습니다(IDEF0에서는 실행에 병렬성을 추가하면 모든 병렬 기능이 동시에 실행됩니다). 각 단계마다 출연자를 지정할 수 있는 것도 장점인 것 같았습니다(읽기: 기능).

하지만! IDEF0에서는 각 분해 수준에서 실행자가 한 번씩 표시되며, 실행자가 실행하는 모든 블록에는 그를 대신하여 화살표가 그려집니다. EPC에서는 Executor가 수행하는 액션 수를 계산하기 위해 모든 액션 블록을 살펴보고 필요한 Executor가 표시되어 있는지 확인해야 합니다.

이 표기법은 프로세스 실행을 모니터링하는 관점에서 매우 편리해 보였습니다. 각 기능은 확실히 시스템을 새로운 상태로 전환하며, 각 기능을 실행한 후 시스템이 원하는 상태로 전환되는지 여부를 확인할 수 있습니다. 상태가 실제로 이루어졌습니다. 그러나 즉시 질문이 생겼습니다. 이것이 정말로 필요한가요? 예를 들어, 나는 그런 욕망을 거의 갖지 않습니다 =)

따라서 일반적으로 EPC 표기법은 비즈니스 프로세스를 설명하는 데 불편한 것 같습니다. 이벤트에 대한 관심이 너무 많고 작업에 대한 관심이 너무 적으며 특히 수행자 또는 사용된 자료를 기반으로 한 그룹화에 대한 관심이 너무 적습니다. 예, 그녀는 단순합니다. 예, 그녀는 아름답습니다. 그리고 예, 불행하게도 다른 많은 사람들처럼 제가 그녀에 대해 말할 수 있는 것은 그게 전부입니다. =)

그리고 UML 및 BPMN 표기법에 대한 기사가 점점 더 가까워지고 있습니다.

(4.14 - 21명이 평가함)

비즈니스용 악보

음악이 우리를 묶었어요
우리의 비밀이 됐어

이 기사의 모든 비문은 Mirage 밴드의 "Music Has Connected Us"라는 노래에서 가져온 것입니다.

클래식 음악에서 음악가는 작곡가의 손에 있는 악기이며 음표에 따라 연주합니다. 대중음악에서는 음악가가 직접 작곡하는 경우가 가장 많으며 즉흥 연주에는 음표가 전혀 포함되지 않습니다. 클래식이 된 유명한 즉흥 연주는 악보로 번역되어 편곡이 바뀌고 새로운 사운드와 분위기가 추가되어 새로운 삶을 살게 됩니다.

마찬가지로, 숙련된 즉흥 연주자로 성장한 비즈니스는 새로운 수준으로 나아가기 위해 사실을 종이에 기록하여 현재 상황을 분석하고 개선을 위한 결정을 내려야 합니다.

최근에는 비즈니스 프로세스(BP)에 대한 설명을 점점 더 자주 찾을 수 있습니다. "스스로". 기사를 쓰게 된 것은 바로 이러한 상황이었습니다. 불행하게도 내가 우연히 본 문서의 대부분은 진지한 업무에 거의 쓸모가 없었습니다. 근본적으로 틀렸다는 말은 아니지만, 많은 누락으로 인해 그 존재를 즉시 잊어버리고 싶었습니다. 이러한 누락이 무엇인지, 이를 처리하는 방법은 이 기사의 과정에서 파악하여 점차적으로 문제의 본질에 접근할 것입니다. 우리는 많은 기술적인 세부사항을 피하려고 노력할 것이지만, 그것들을 완전히 피할 수는 없습니다. 왜냐하면... 대화의 주제가 그것을 요구합니다.

정말 나인가요?
모든 것에 대한 답을 찾을 수는 없습니다

이 문서는 문서 준비를 내부 전문가에게 맡겨 비즈니스 프로세스 설명을 절약하려는 사람들을 대상으로 합니다. 결국 회사에서는 비즈니스 프로세스에 대한 설명이 필수가 아니며 모든 것이 설명 없이도 작동합니다. 그러나 안정된 회사에는 권한을 양도하는 메커니즘이 있는데, 이를 "직무 설명"이라고 합니다. 사업이 복잡하고 직위가 중요한 경우에는 직무 설명을 더 쉽게 이해할 수 있도록 그리는 것이 유용합니다. 비즈니스, 특히 판매를 더욱 투명하게 만들기 위해서는 일반적인 설명에서 비즈니스 프로세스를 축적하는 것이 필요합니다.

"BP 설명" 문서는 회사의 재구성(또는 현재 유행하는 대로 리엔지니어링)이 필요한 경우 특히 관련성이 높습니다. 이 경우 문서는 다음 용도로 사용됩니다.

1. 그 위에 전투 지도에서와 같이 계획된 변형의 본질을 표시하고,
2. 변환 참가자를 최신 상태로 유지하고,
3. 손가락이 아닌 펜을 사용하여 부서장과 외부 전문가에게 작업을 할당하세요.

문서를 직접 준비하면 다음과 같은 장점이 있습니다.

• 더 저렴하게 작동합니다.
• 내부 전문가로서 자신의 고유 사업 관행에 더 정통합니다.

제3자 컨설턴트는 먼저 해당 주제의 용어와 주요 기능은 물론 업계 표준을 연구해야 합니다. 시간이 걸립니다. 사실, 그는 설명 방법과 내용을 더 잘 알고 있습니다. 특정 규칙, 일반적으로 허용되는 표기법 및 특수 소프트웨어가 있습니다. 그러한 표기법의 예는 그림 1에서 볼 수 있습니다. 1 및 그림. 2.

IDEF0 표기법

IDEF0을 사용하여 전원 공급 장치를 설명하는 예

우리에게 강의하지 마세요

나한테 강의하지 마세요.
엄마 이거 소용없어요

이것이 정말 필요한가요? -감독은 모든 표준을 준수하면 결과 비용이 크게 증가한다고 합리적으로 가정하여 질문합니다. 제가 아는 이사 중 한 명은 다음과 같이 추론했습니다: "제3자 전문가를 초대하는 것은 비용이 많이 드는 사업이지만 우리의 작업은 간단합니다. 왜 이러한 모든 표기법이 필요한가요? 그리고 전문가는 때때로 후크로 무언가를 그리는데 아무것도 아닙니다." 분명, 인정하기 불편해서 아직 뒤처져 있다는 건 당신이 치러야 할 대가다."

동의합니다. 작업이 간단하다면 왜 귀찮게 합니까? 그리고 복잡하다면 단순화해야 하고 화려한 표기법으로 복잡하게 만들지 않아야 합니다. 결국 아름다운 후크를 사용하면 뚜렷한 이점이 없습니다. 명백한 것이 없다고해서 아무것도 없다는 의미는 아닙니다. 이러한 규칙과 표기법은 컨설턴트가 지루해하지 않도록 고안된 것이 아닙니다... 비즈니스에 참여하는 사람은 유용한 모든 것이 분명하지는 않다는 것을 잘 알고 있습니다. 글쎄요, 숨겨진 긍정적인 부분을 찾아보고 이를 위해 문제의 역사를 살펴보겠습니다.

전원 공급 장치 설명 시장은 매우 오랫동안 존재해 왔습니다. 그러나 지난 15년 동안 기업의 회계 및 관리 자동화라는 새로운 산업의 출현으로 인해 급속한 발전을 이루었습니다. 성장하는 시장은 새로운 표기법을 생각해낸 신규 이민자들에게 돌파구를 마련하고 자신의 자리를 확고히 할 수 있는 기회를 제공했습니다. 예를 들어, 지난 몇 년 동안 러시아 시장에서는 IDS Scheer(ARIS의 주요 공급업체 - 그림 3 참조) 측의 대규모 광고 및 정보 캠페인을 통해 자동화된 프로세스를 설명하는 전문가 계층이 탄생했습니다.

ARIS 표기법을 사용하려면 비즈니스 프로세스에 대한 매우 세부적인 내용이 필요합니다.

ERP(자원관리), CRM(고객관계), MRP(생산계획) 등의 시스템 구축은 필연적으로 프로세스의 변화를 가져오며, 이를 사전에 계획하지 않으면 원하는 것보다 결과가 좋지 않을 수 있습니다. 또한 자동화는 정보와 함께 작동하므로 어떤 정보가 누구에 의해 생성되고 어디서 왔으며 어디로 가는지 아는 것이 유용합니다. 그러나 자동화 도입을 위한 특별한 표기법은 여기에 뿌리를 내린 적이 없으며 거의 ​​사용되지 않습니다.

러시아의 비즈니스 프로세스에 대한 설명은 이 분야의 인상적인 GOST 수(3.1109, 34, ISO 등)에도 불구하고 비교적 최근의 추세입니다. 이제 자체 비즈니스 프로세스에 대한 설명 품질이 향상되어 은행이 가장 좋습니다. 사실, 다른 상업 구조와는 달리 은행은 인프라 조직이므로 법으로 정의된 엄격한 규정의 틀 안에 있습니다. 은행은 당일 관리 원칙에 따라 운영됩니다. 결과적으로 은행의 비즈니스 프로세스에 대한 간단한 설명(기호를 사용하지 않고 러시아어로)도 더 자세한 것으로 나타났습니다. 표준, 용어, 역할 및 규칙을 정의하는 수많은 규정을 기반으로 구축되었습니다. 이러한 표준은 은행 환경에서 일반적으로 허용되는 언어이며 비즈니스 프로세스에 대한 설명은 모든 전문가가 쉽게 읽을 수 있습니다.

상업 구조에서 비즈니스 프로세스를 설명하려면 예비 용어 사전이 필요합니다. 그리고 그것을 준비하고 조정하기 시작할 때 많은 사람들은 동일한 것이 부서마다 다르게 호출된다는 사실에 직면합니다. 자세히 살펴보면, 서로 다른 이름이 실제로 서로 다른 의미를 담고 있음이 밝혀졌습니다. 용어 조정은 비즈니스 프로세스를 설명하는 데 있어 가장 노동 집약적인 프로세스 중 하나입니다. 이 프로세스를 시작하고 실행하는 것이 중요합니다. 저는 회사 자체 부서에서 대부분의 업무를 맡을 수 있습니다. 왜냐하면 회사의 활동을 규제해야 할 필요성이 프로세스와 절차를 더욱 체계적으로 조직화하기 때문입니다.

자동화를 위해 설명이 필요한 경우 역순서도 가능합니다. 비즈니스 프로세스 변경은 정보 시스템 구현과 병행하여 이루어지며, 새로운 비즈니스 프로세스에 대한 설명은 "즉시" 수행되며 시스템 문서와 통합됩니다.

직원

나는 모든 것을 잊었다
우리는 수년 동안 가르쳐 왔습니다.

이상하게도 중소기업에서는 표기법 선택과 설명의 정확성이 더 중요합니다. 대기업은 일반적으로 직원의 상호 호환성으로 인해 프로세스 유연성이 더 높습니다. 중요한 사항의 실행이 2~3명의 의사 결정권자에게만 국한되는 소규모 기업의 경우 프로세스 경로를 잘못 표시하면 근본적으로 잘못된 솔루션 개념이 발생할 수 있습니다. 결과가 중요하기 때문에 도구도 중요하지만 어떻게 선택해야 할까요?

각 표기법은 특정 작업 범위에 맞게 조정되었습니다. 우리는 관리 자동화 프로젝트의 틀 내에서 비즈니스 프로세스를 변화시키는 것이 가장 시급한 작업이라고 생각할 것입니다. 이러한 목적을 위해 널리 사용되는 좋은 도구 세트가 있습니다. 이는 러시아 GOST, 동일한 ARIS, IDEF 및 EPC입니다(그림 4 및 그림 5).

EPC 표기법

EPC를 이용한 비즈니스 프로세스 설명

책이 특정 언어로 쓰여졌다면 가장 중요한 것은 그 언어를 알고 읽을 수 있는 독자가 있다는 것입니다. 이를 바탕으로 BP를 설명하는 가장 일반적인 표준이 최고입니다.

표기법을 선택할 때 또 다른 중요한 기준은 친숙한 소프트웨어 도구를 사용할 수 있는 능력입니다. 예를 들어, 2002년 Microsoft Business Solution은 특수 소프트웨어 솔루션과 함께 Navision 정보 시스템에 대한 On-Target 표기법을 제공했습니다. On-Target 표기법을 아는 사람이 아무도 없을 뿐만 아니라 소프트웨어 환경에서도 이를 연구하는 데 시간이 필요할 것입니다. 저는 IDEF 표기법과 매우 널리 퍼져 있으며 IDEF 다이어그램을 그리는 데 필요한 도구 세트가 있는 Visio 프로그램을 사용하는 것을 긍정적인 예로 부르고 싶습니다(그림 6).

Visio에서 수행되는 IDEF 비즈니스 프로세스

물론, 전원 공급 장치에 대한 설명은 이해하기 쉬울 것 같기 때문에 단어로 간단하게 설명할 수도 있고 (자신이 만든) 다양한 기호를 사용할 수도 있습니다. 그러한 설명이 있는 것이 없는 것보다는 낫지만 표준을 유지하는 것은 여전히 ​​유용합니다.

소리의 충만함과 깊이

무엇이 나를 여기로 끌어들이는지 모르겠어요

1. 시간이 오래 걸릴 것이다
2. 문서 작성 중에 일부 세부정보가 변경됩니다.

일반적인 실수는 표기법에 맞게 설명을 맞추려고 하는 것입니다. 예를 들어, ARIS 형식으로 절차를 설명하려고 합니다. 필요하지 않은 경우 설명에서 명백한 중복을 달성합니다.

그러나 더 흔한 실수는 문서 깊이가 부족하다는 것입니다. 결과적으로 업무에 적합하지 않은 형식적인 문서가 되는 것입니다. 이 과정에서 모든 중요한 세부 사항을 명확히 해야 합니다.

멜로디는 음표가 아닌 소리의 연속입니다.

오늘은 잊어버려
아무도 논쟁이 필요하지 않습니다

이는 전원 공급 장치를 어떤 표기 없이 간단히 단어로 설명할 수 있음을 의미합니다. 물론 표기법이 더 정확하지만 그게 중요한 것은 아닙니다. 설명 BP는 최종 제품이 아니라 새로운 성과를 위한 도구일 뿐입니다. 이는 향후 적극적인 사용에 적합해야 함을 의미합니다. 대부분의 DIY 문서의 주요 문제점은 사용하기 불편하다는 것입니다. 예를 들어, 그러한 문서 중 하나는 Microsoft Word에서 수행한 작업에 대한 설명과 PowerPoint에서 만든 그림으로 구성되어 있으며, 프로그램에서 프로그램으로 이동하는 것이 매우 불편했고, 이를 모두 하나의 문서로 가져오는 데 많은 시간이 걸렸습니다. 문서에는 다음 속성이 있어야 합니다.

1. 명확한 순서와 섹션 그룹화를 갖습니다. 개념적으로 총체적이어야 합니다(일반적으로 이는 개념이 있으면 해당 개념을 사용하는 방법을 배웠음을 의미합니다).
2. 사업 단위를 명확하게 식별하고 명확한 이름과 번호를 부여합니다.
3. 비즈니스 프로세스를 명확하게 강조하고 명확한 이름과 번호를 부여합니다.
4. 혼동을 방지하는 방식으로 요소에 번호를 매겨야 합니다(이렇게 하면 검색이 훨씬 쉬워집니다). 예를 들어 문서에서 부서 번호 1의 번호는 Dept.001이어야 하고 비즈니스 프로세스 번호 1의 번호는 BP001이어야 합니다. ;
5. 문서에는 트리 구조의 콘텐츠 섹션이 있어야 합니다.
6. 회사는 통합된 유기체이며 비즈니스 프로세스가 중단되지 않습니다. 회사는 항상 다른 사업부, 사업부 및 부서와 연결되어 있습니다. 이러한 연결을 반영하기 위해 하이퍼링크를 사용할 수 있습니다. 이렇게 하면 정보를 더 쉽게 찾고 한 개체에서 다른 개체로 이동할 수 있습니다.

이를 위해 하이퍼링크를 지원하는 텍스트 편집기를 사용할 수 있습니다.

어떤 사람들은 전문 음악 그룹에 실제 음악가가 한두 명 있으면 충분하다고 믿습니다. 성실한 음악 감정가는 이에 동의하지 않습니다. 이러한 대화는 전문가와 창의적인 개인이 부족하기 때문에 발생합니다.

기업도 비슷한 어려움을 겪고 있습니다. 자신의 회사를 머리부터 발끝까지 잘 아는 좋은 전문가는 거의 없으며 매우 바쁩니다. 비즈니스 프로세스를 스스로 분석함으로써 우리는 비용을 절약하고 시간도 절약할 수 있습니다. 그러나 전원 공급 장치를 설명하는 데 가장 적합한 것을 선택하는 것이 항상 가능한 것은 아닙니다. 낮은 직급의 수행자에게 루틴을 맡길 수도 있지만, 그럴 경우 프로세스가 지연될 위험이 있습니다. 그러한 문서를 구성하는 원칙을 무시하면 비효율적일 위험이 있습니다(결과는 사용할 수 없으며 없는 것과 같습니다).

핵심 전문가 및 경험이 풍부한 컨설턴트와의 제휴를 통해 최고의 품질과 속도로 문서 준비가 가능합니다. 그 결과 비즈니스 프로세스(예: 회사 비즈니스의 용어)를 설명하기 위한 합의된 언어와 추가 문제를 해결하기에 충분할 만큼 상세한 설명 자체가 만들어집니다.

모든 설득에 응답하여 반복합니다.
그들은 우릴 갈라놓지 않을 거야, 안돼

이 기사의 모든 비문은 Mirage 그룹의 "Music Connected Us" 노래에서 가져온 것입니다.

제3자 컨설턴트는 다른 컨설턴트가 이해할 수 있고 종종 사례에 더 적합한 표기 언어로 문서를 작성합니다. 이 모든 고리를 이해하지 못하시나요? 하지만 이러한 표기법은 전혀 복잡하지 않습니다. 배울 가치가 있을까요?

"정보가 더 명확하게 전달될수록 해당 정보를 받는 사람이 더 빠르고 정확하게 인식할 수 있습니다." 이 진실은 마케팅 담당자, 교육자 및 연구자들이 오랫동안 적극적으로 사용해 왔습니다. 매니저도 빠지지 않았다. 이 기사에서는 EPC 표기법을 가장 널리 사용되는 최신 방법 중 하나로 설명합니다. 이를 통해 복잡한 작업을 편리하게 설명할 수 있을 뿐만 아니라 프로젝트나 프로세스의 모든 참가자가 훨씬 더 정확하고 이해하기 쉽게 만들 수 있습니다.

그래픽 모델링 표준 출현의 역사

이제 사회의 모든 프로세스의 발전 속도가 빨라지고 시스템이 더욱 복잡해짐에 따라 사람에게 영향을 미치는 기술인 경영도 엔지니어링 시스템 관리와 ​​마찬가지로 시스템 관리 능력을 습득해야 합니다. 지난 세기 90년대 초에는 “ 리엔지니어링 Michael Hammer와 James Champy는 자신의 책 Reengineering the Corporation에서 이 정의를 처음으로 소개했습니다." 그리고 그 이후에 비즈니스의 '엔지니어링'이라는 개념이 등장했습니다. 첫 번째가 비즈니스 프로세스의 재설계라면, 두 번째는 효과적인 조직 시스템을 처음부터 설계하는 것입니다.

이러한 추세는 조직을 시스템으로 설명하고 구성하는 방법에 대한 검색이 오랫동안 성공적으로 진행되어 왔음을 나타냅니다. 경영을 예술뿐만 아니라 과학으로도 생각한다면 다른 과학 분야와 마찬가지로 공식과 법칙을 고정하기 위한 고유한 표기 시스템이 필요합니다. 이러한 시스템 솔루션은 다양한 활동 분야의 엔지니어, 화학자, 물리학자, 수학자 등이 성공적으로 사용합니다.

조직체인 사회경제시스템은 자연과학보다 훨씬 다양하고, '공리'와 경영공식을 단일하게 기록하는 형태는 아직까지 발견되지 않았다. 그러나 길은 이미 포장되어 있습니다. 그리고 그것은 주어진 결과를 달성하기 위한 절차를 설명할 수 있는 잘 알려진 흐름도에서 시작됩니다. 그러나 불행하게도 순서도의 시각적 기능은 매우 제한적이며 비즈니스 관리 프로세스의 다양한 요소를 모두 표시할 수 없습니다.

오늘날 창의적인 활동 과정에서 사람과 시스템의 상호 작용을 묘사할 수 있는 순서도 옵션이 많이 개발되었습니다. 기업 활동의 모든 측면을 보다 완벽하게 설명하기 위해 도구 세트로 결합됩니다. 이러한 도구를 모델링 방법론이라고 합니다. 가장 완전하고 잘 알려진 것은 그 중 세 가지입니다.

• ARIS(통합 정보 시스템 아키텍처);
• SADT(구조적 분석 및 설계 기술);
• UML(통합 모델링 언어).

(확대하려면 클릭)

기업의 활동을 완전하고 포괄적으로 설명하려면 방법론에 포함되어 표기법이라고 하는 다양한 그래픽 표준을 사용해야 합니다. 그러나 좁은 문제를 해결하려면 해당 설명을 위해 고안된 표기법을 선택하는 것으로 충분합니다. 위는 이 기사에서 논의할 그래픽 표기법 유형 중 하나입니다.

EPC 표기법의 특징

EPC(Event-driven Process Chain) 모델링 표기법은 특정 작업을 수행하는 과정에서 상호 작용 알고리즘을 구축하는 데 중점을 둡니다. 주요 요소는 다음과 같습니다.

• 작업을 시작하거나 종료하는 이벤트
• 시스템을 한 상태에서 다른 상태로 전환하는 작업(작업)
• 작업 수행자;
• 자원 및 작업 결과(입력 및 출력).

이 표기법은 Wilhelm-August Scheer가 작성하고 1990년대 초에 개발한 ARIS 방법론의 필수적인 부분입니다. 이전 섹션의 끝 부분에서 그림은 EPC 표기법을 사용하여 작업을 표준화하는 프로세스의 개요를 보여줍니다. 이 표기법을 사용하여 조직의 비즈니스 프로세스를 설명하는 기능을 고려해 보겠습니다. 다이어그램의 본질을 탐구하지 않고도 빨간색과 녹색 요소가 번갈아 가며 즉시 눈에 띕니다. 이는 표기법 이름에 내재된 일련의 이벤트 및 프로세스입니다. 모델 요소의 구성은 네 가지 주요 위치에 따라 결정됩니다.

프로세스 모델을 설명하는 과정에서 정보 시스템을 사용할 가능성이 높습니다. 그런 다음 특별한 3단계 요소 집합을 사용하여 이를 표시할 수 있습니다( 주황색).

1. IS – 정보 시스템.
2. IC 모듈.
3. IS 기능.

데이터베이스는 전통적으로 원통 형태의 자체 이미지를 가지고 있습니다. 정보 시스템 없이, 데이터베이스 없이 시스템을 사용하는 것은 오늘날 나에게는 불가능해 보입니다. 기능 간의 전환 논리를 표시하기 위해 병렬 작업 실행 또는 이벤트 발생 조건을 지정하는 데 도움이 되는 논리 연산자가 사용됩니다. 함수와 이벤트를 병합하거나 분기하는 옵션을 표시합니다. 논리 연산자는 "AND", "OR" 및 "배타적 OR"의 세 가지뿐입니다. 시스템마다 다른 그래픽 기호를 사용할 수 있습니다.

EPC 표기법에서 논리 연산자의 표기 및 사용

EPC 차트 구성 알고리즘

보시다시피, 이 표기법의 확실한 이점은 다이어그램 구성을 위한 직관적인 요소 집합과 규칙입니다. 프로세스 다이어그램을 만들려면 특수 프로세스 모델링 프로그램을 사용하는 것이 좋습니다. EPC의 경우 이는 주로 ARIS 시스템입니다. 그러나 비용이 많이 들고 상당히 복잡하며 부서의 활동을 합리화하기 위한 소규모 정기 프로젝트에는 사용되지 않습니다.

표기법의 단순성과 대중성은 EPC 표기법을 포함하여 비즈니스 프로세스를 그리기 위한 다른 도구의 생성을 자극했습니다. 그 중 가장 간단한 것은 Visio입니다. Visio의 템플릿 중 하나는 "EPC 다이어그램"입니다. 나에게 가장 유용한 도구는 Business Studio 시스템입니다. 여기에서는 프로세스를 그리는 기능 외에도 참가자를 위한 문서(프로세스 규정) 및 작업 지침을 자동으로 생성할 수 있으므로 성과 표준 개발 프로세스의 일상적인 부분이 크게 단순화됩니다.

다양한 프로그램에서 보조 요소의 색상과 지정은 약간 다를 수 있지만 항상 일반적인 규칙을 따릅니다. 기사의 첫 번째 섹션에 제시된 EPC 표기법의 예는 이 표기법을 사용하기 위한 단순화된 알고리즘을 반영합니다. 단계별로 살펴보겠습니다.

모든 단계를 완료한 후, 우리는 수행자가 이해할 수 있는 프로세스 실행을 위한 세부 계획을 받습니다. 그리고 명확하게 정의된 이벤트와 결과를 통해 프로세스의 모든 중요한 단계에 대한 제어 지점을 설정할 수 있습니다. 그리고 기사 시작 부분에 게시된 시각적 모델의 예를 다시 언급합니다.

EPC 표기법의 장점과 단점

단순성과 접근성 외에도 EPC를 사용하면 다음과 같은 장점이 있습니다.

1. 간단한 순서도와 달리 하나의 다이어그램에 모든 중요한 조직 요소를 표시할 수 있습니다.
2. 이는 모델의 다양한 수준에서 사용될 수 있습니다. 즉, 글로벌 프로세스를 모두 설명하고 각 기능 블록이 하위 프로세스가 될 수 있다는 사실로 인해 자세한 지침을 작성하는 데 사용할 수 있습니다.
3. 하나의 시리즈에 여러 이벤트를 입력할 수 있으므로 프로세스의 복잡한 병렬화를 쉽게 수행할 수 있습니다.

동시에, 이 표기법은 다음과 같은 단점으로 인해 유일무이한 표기법이 되지 못했습니다.

1. 모든 사소한 작업에 대해 이벤트를 생성해야 하므로 계획이 크게 복잡해집니다.
2. 불편한 업무 추적으로 인해 조직이 붕괴될 가능성이 높습니다.
3. 입력 및 출력을 고품질로 등록하면 직사각형과 화살표로 회로에 과부하가 발생하여 교차하기 시작하여 회로 인식이 더욱 복잡해집니다.
4. 작업을 병렬화할 때 실행자를 반영하는 것은 매우 어렵습니다. 한 사람이 일련의 기능을 수행하는 경우 화살표로 인해 그림이 더욱 복잡해집니다. 수행자가 여러 명이거나 긴 화살표를 그리고 싶지 않은 경우 수행자와 함께 "타원"을 복제해야 합니다. 이 모든 것이 곧 다이어그램의 완전한 혼란으로 이어질 수 있습니다.

내 경험에 따르면 이 표기법으로 작성된 로컬 작업 절차는 개발자와 지침 사용자 모두에게 매우 편리하다고 말할 수 있습니다. 이 표기법은 다양한 프로젝트 참가자에게 직관적인 언어로 프로젝트 작업 분배를 시각적으로 계획할 수 있으므로 프로젝트 관리자에게도 적합합니다. 그리고 기업 활동의 보다 복잡한 다단계 모델을 개발하려면 다른 모델링 표기법이 더 적합하며 다음 기사에서 이를 고려할 것입니다.