비즈니스 프로세스 모델링 기술. 비즈니스 프로세스 모델링은 어떤 작업을 해결하는 데 도움이 됩니까?

비즈니스 모델링 분야에서 연구를 수행한 결과 자동화된 정보 시스템 개발에서 작업 흐름의 선택 및 통합에 대한 특정 세부 사항을 규제하는 수백 가지 방법, 방법론, 프로세스, 표준이 이미 있음이 나타났습니다. 최근까지 비즈니스 분석 및 비즈니스 모델링과 관련된 작업은 IS 디자이너에게 인기가 없었습니다. 그들의 역할은 그다지 명백하지 않으며 모든 방법론에서 받아들여지지 않습니다. 문제는 AIS가 비즈니스 모델의 형태로 개발(선택)되는 기업에 대한 정보를 수집하는 것입니까, 아니면 이 단계를 건너뛰고 즉시 시스템 요구 사항을 형성하고 개발을 시작할 가치가 있습니까?

고객과 개발자는 항상 이야기합니다. 다른 언어들. 일반적인 이해어려움을 겪고 개발되는 이 프로세스는 시간이 걸리지만 그 중요성을 과대평가할 수 없습니다. 개발 대상. 개발자가 더 나아가 고객의 기업에서 비즈니스를 수행하는 특성을 자세히 조사하면 먼저 AIS 요구 사항을 더 잘 이해할 수 있고 두 번째로 요구 사항 공식화에 고객과 함께 참여할 수 있습니다. , 누락된 요구 사항 분석 등

안정적인 시장 상황으로 인해 최근 수십 년 동안 매우 인기 있는 비즈니스 프로세스 분석(비즈니스 모델링) 작업은 보다 일반적인 작업인 문제 영역 분석 문제 영역 분석(APO)의 일부로 간주되어야 합니다. 문제 영역 분석에 전념하는 작업은 지난 세기 중반에 국내 문헌에 나타났습니다. 이 주제는 작업 접근 방식 및 전문가 시스템 엔지니어링과 불가분의 관계가 있습니다. 모델링 분야의 첫 번째 단계는 지능형 시스템 구축에서 수행되었습니다. AIS 구축 작업과 같은 "보다 일상적인" 작업의 경우 이러한 방법이 나중에 적용되기 시작했습니다. 지식 추출 전략은 분석가의 작업과 크게 교차하며, 하위 작업으로 축소하고 상태 공간에서 검색하여 문제를 해결하는 방법은 비즈니스 분석, 소프트웨어 시스템의 분석 및 합성의 다양한 방법에 반영되며 이 목록은 계속됩니다. . 논문은 조직 시스템의 설명에서 특정 모델과 방법의 적용이 얼마나 효과적인지에 대한 질문을 조사합니다.

이 문제를 해결하기 위해서는 CIS 구축의 한 단계로서 비즈니스 분석 자체의 목표와 목표를 결정할 필요가 있습니다.

모델링의 관점에서 요구사항 분석(RA)과 문제 도메인 분석(DPA)은 근본적으로 다른 프로세스입니다.

APO는 모델 생성의 고전적인 목표를 추구합니다. 객체(자동화된 기업 또는 조직 시스템 조직 시스템 - OS, OS)가 있고 분석가의 임무는 필요한 정확도로 생성된 모델에 이 객체를 반영하는 것입니다. 개발 프로세스 다이어그램은 그림 3에 나와 있습니다.

반대로 요구 사항 분석은 가상의 아직 존재하지 않는 객체(AIS)를 모델링하는 것을 목표로 합니다. 저것들. 먼저 모델을 만든 다음 이를 기반으로 개체를 합성합니다. 이제 AIS 생성을 위한 일반화된 "공식"을 고려하십시오.

OS->M(OS)->M(AIS)->M"(AIS)->M""(AIS)->M"""(AIS)->AIS

조직 시스템 분석 후 모델 M(OS)을 생성할 수 있습니다. 비즈니스 분석(문제 영역) 모델입니다.

문제 영역 분석을 통해 다음을 격리할 수 있습니다.

• - 한편으로는 OS 내에서 구현되는 작업 및 기능과 OS와 환경 간의 통신 기능,
• - 한편, 주제 영역의 구조(처음에 - 개념적 모델 수준에서),
• - 셋째 - 정보 및 처리 요구 사항.

자동화 대상 기능을 선별하여 시스템의 기능적 요구 사항을 식별하기 위한 기반을 얻습니다. AFS 단계에서 수집된 나머지 정보는 비기능 요구 사항을 검색하는 데 사용됩니다. 결과적으로 AIS 모델의 첫 번째 근사값인 M(AIS)로 AT 모델을 얻습니다.

심층 분석 및 설계, 분석 모델 M"(AIS), 설계 모델 M""(AIS) 및 구현 모델 M""(AIS)을 각각 형성합니다.

구현 수준 모델을 사용하면 AIS 자체를 프로그램, 정보 및 조직 요소 집합으로 결합할 수 있습니다.

AIS는 조직 시스템 M "(OS)의 모델이며 모델링주기를 닫습니다. 이러한 프로세스 간의 관계를 명확히하기 위해 생성 된 AIS도 OS와 관련된 모델이라는 점에 유의해야합니다. 따라서 AT 문서를 생성하면 AT 문서는 OS 모델의 모델에 지나지 않기 때문에 "2차 모델"을 생성합니다. 물론 APO 모델이 없으면 AT 모델을 생성할 수 있지만 동시에 원본 모델(즉, AIS)을 합성할 때 OS에 대한 지식 없이 불일치 상황에 빠질 위험이 있습니다. ) OS이므로 실행 가능하지 않습니다.

AIS 개발 프로세스는 BPwin 프로그램에서 다이어그램 형태로 표시할 수 있습니다. 그림 4는 AIS 개발 단계를 보여줍니다. 최상위 다이어그램 - 프로그램 만들기(그림 4)는 개발 및 테스트라는 두 개의 두 번째 수준 다이어그램으로 구성됩니다.

개발은 프로그램 프레임워크 구축과 프로그램 본체 작성으로 구성됩니다.

3단계 프로그램의 틀 구축

4단계 프로그램 본체 생성.

5단계 테스트

비즈니스 모델링을 고려한 후 비즈니스 프로세스로 넘어 갑시다. 비즈니스 프로세스의 방법론에 대한 연구는 프로세스를 세 가지 범주로 나눌 수 있는 가능성으로 이어집니다.

• - 조직 시스템 분석 및 개선을 목표로 하는 모델(예: SWOT, VCM, BPR, CPI/TQM/ISO9000, BSC),
• - SADT, DFD, IDEF1, IDEF3, IDEF5 등과 같은 범용 모델,
• - 자동화에 사용하도록 특별히 설계된 모델(예: ISA, BSP, ARIS, RUP).

문제 영역을 설명하기 위해 가장 발전된 모델은 ARIS 방법론에서 제안됩니다. ARIS 아키텍처는 조직에서 다음 하위 시스템을 구분합니다.

• - 조직적. 조직의 구조를 결정합니다 - 단위, 직책 및 특정 개인의 계층 구조, 이들 간의 다양한 연결 및 구조 단위의 영토 바인딩.
• - 기능의. 조직에서 수행되는 기능을 정의합니다.
• - 입력/출력의 하위 시스템. 사용 및 생산되는 제품 및 서비스의 흐름을 결정합니다.
• - 정보용(데이터 하위 시스템). 정보(데이터)에 대한 획득, 보급 및 액세스를 설명합니다.
• - 관리 프로세스의 하위 시스템. 이벤트 및 메시지를 통한 기능 실행을 위한 논리적 순서를 정의합니다. 제어 서브시스템은 시간적으로 떨어져 있는 다양한 종류의 메시지 집합이라고 말할 수 있습니다.
• - 조직 목표의 하위 시스템. 프로세스 실행 중에 달성한 목표의 계층 구조를 설명합니다.
• - 생산 수단의 하위 시스템. 기본 및 보조기구생산.
• - 인적 자원의 하위 시스템. 조직 직원의 고용, 교육 및 승진에 대해 설명합니다.
• - 조직 구조 배열의 하위 시스템. 조직 단위의 지역 위치를 설명합니다.

이 분할은 어느 정도 조건부입니다. 선택한 "하위 시스템"은 시스템 분석의 의미에서 하위 시스템이 아닙니다. 침투하고 교차합니다. 오히려 그들은 일련의 연구 주제, 연구 대상에 대한 다른 견해를 나타냅니다. 비즈니스 프로세스 개선의 원칙은 네 가지 접근 방식을 기반으로 합니다. Fast Decision Analysis(FAST) 기술; 프로세스 벤치마킹; 프로세스 재설계; 프로세스 리엔지니어링.

현재 변환 구현에 사용되는 여러 가지 방법과 도구가 있습니다. 비즈니스 프로세스를 경제 시스템의 요소로 설명하고 분석하기 위한 계층적 모델을 구성하는 방법입니다. 동시에 문제 진술과 모델링의 목표를 명확하게 공식화하는 것이 매우 중요하며 이는 적절한 방법과 도구의 선택을 결정합니다.

기능적 모델링의 문제, 즉 기존의 프로세스나 우리가 이상적으로 얻고자 노력하는 프로세스의 기술을 해결하기 위해 구조해석 및 설계의 방법론인 SADT Structured Analysis and Design Technigue 기술이 널리 사용되고 있다.

SADT 방법론의 주요 아이디어는 기업의 나무와 같은 기능 모델을 구축하는 것입니다. 첫째, 기업의 기능은 세부 사항 없이 일반적으로 설명됩니다. 이러한 설명을 컨텍스트 다이어그램이라고 합니다. 외부 세계와의 상호 작용은 입력(기능에 의해 소비되거나 수정되는 데이터 또는 개체), 출력(기능의 주요 출력, 최종 제품), 제어(기능을 안내하는 정책 및 절차) 및 메커니즘(필요한 자원). 컨텍스트 다이어그램을 생성할 때 모델링의 목적, 범위(시스템의 구성 요소로 간주되는 것과 외부 영향으로 간주되는 것에 대한 설명) 및 관점(모델이 구축되는 위치)은 공식화. 일반적으로 전체 시뮬레이션 시스템의 작동을 담당하는 사람 또는 개체의 관점이 관점으로 선택됩니다.

또한 일반 기능은 큰 하위 기능으로 나뉩니다. 이 과정을 기능적 분해라고 합니다. 그런 다음 각 하위 기능은 더 작은 기능으로 분해되며 필요한 설명이 자세히 설명될 때까지 계속됩니다. 무화과. 2는 기능 모델의 노드 트리라고 하는 기능 트리를 보여줍니다.

다이어그램의 각 노드는 다이어그램 설명의 별도 조각에 해당합니다. 모델은 계층적으로 배열된 일련의 다이어그램이며 각 다이어그램은 일부 기능 또는 작업(활동)에 대한 설명입니다.

다이어그램의 활동은 사각형(기능 블록)으로 표시됩니다. 각 직무는 기능이나 직무를 나타내며 "제품 만들기", "고객 서비스" 등과 같이 동작을 나타내는 동사 또는 동사구로 참조됩니다. 화살표는 명사로 표시되며 작품을 서로 연결하고 외부 세계. 조직의 구조를 나타내는 모델과 달리 기능 모델의 최상위 다이어그램 작업은 아래 작업의 제어가 아닙니다. 하위 수준 작업은 상위 수준 작업과 동일하지만 더 자세히 설명합니다.

새로운 정보 기술을 개발할 때 특정 작업장에서 구현되는 프로세스에 중점을 두는 것이 좋습니다.

비즈니스 프로세스는 한 작업 공간에서 다른 작업 공간으로 전달되는 정보의 흐름입니다. 작업에는 여러 비즈니스 프로세스가 포함될 수 있습니다.

외부 엔터티(그림 10a) - 이 직원이 상호 작용하는 개체(예: 공급업체, 고객 등)

드라이브(그림 10b) - 모든 데이터 저장소

비즈니스 프로세스의 단계(그림 10c) - 특정 절차를 수행할 때 직원의 일련의 작업(예: 문서 발행, 보고서 생성 등) 블록 상단에서 직원의 위치 하단에는 절차를 구현하는 특정 작업의 내용이 표시됩니다.

데이터 흐름(그림 10d) - 연결의 특성을 나타냅니다(화살표 위에 특정 문서의 이름을 표시하는 것이 좋습니다).

데이터 분석은 다음과 같습니다.

ㅏ. 각 작업에 대해 솔루션에 필요한 데이터 목록이 작성되고 분류가 가능합니다. 데이터 구별: 입력(초기), 규범 및 참조, 유효(출력, 계산)

비. 데이터 구조는 제목(이름), 유형, 속성으로 정의됩니다.

씨. 정보 객체(IO)의 형성

디. 정보 객체 간의 링크 설정.

각 정보 개체는 논리적으로 관련된 속성 집합을 형성합니다. 표 1은 IO의 예를 보여줍니다.

표 1. IO "고객 조직 회계 저널"

세부 사항의 구성에 따라 IO의 구조가 결정됩니다. 각 IO에는 고유한 이름이 있습니다.

인스턴스는 컬렉션입니다. 특정 값세부. IO에는 많은 인스턴스가 있습니다. 각 IO 인스턴스는 하나 이상의 속성으로 구성된 키로 고유하게 식별되어야 합니다.

정보 논리 모델은 정보 개체 집합과 이들 간의 구조적 연결 형태로 주제 영역을 반영하는 데이터 모델입니다.

그림 12는 ILM의 예를 보여줍니다.

폴더가 형성됩니다-문서 세트, 전체 시스템의 분해가 구축됩니다. 폴더는 검토를 위해 주제 영역의 전문가(즉, 기업 활동의 모델링된 부분에 정통한 사람)에게 보내집니다. 컨텍스트 다이어그램 수준에서 이것은 기업의 관리자, 첫 번째 분해 수준-부서장 등에서 일반 수행자까지일 수 있습니다. 더 분해하기 전에 현재 수준에서 전문가의 모든 의견을 다이어그램에 추가해야 합니다. 따라서 각 전문가는 자신이 가장 유능한 부분에서 모델을 보완합니다. 그 결과 기존의 단점을 시각화하고, 비즈니스 프로세스를 리디렉션 및 개선하고, 생산 비용을 분석하고, 정보 시스템을 만드는 기초 역할을 할 수 있는 시스템에 완전히 적합한 모델입니다.

비즈니스 모델링 프로그램 분석을 통해 비즈니스 모델링 프로세스를 수행하기 위해 BPwin은 IDEF0 외에도 두 가지 모델링 표준(표기법)인 DFD 및 하나의 모델에서 프로세스 모델 및 지원을 생성할 수 있는 고유한 프로그램이라는 결론을 내릴 수 있습니다. IDEF3. 이 세 가지 표기법 각각을 사용하면 엔터프라이즈의 다양한 측면을 고려할 수 있습니다.

• 1) IDEF0 다이어그램은 기업의 비즈니스 프로세스를 설명하도록 설계되었으며 프로세스의 원재료로 사용되는 개체 또는 정보, 작업 결과, 제어 요소 및 이에 필요한 리소스를 이해할 수 있습니다.
• 2) IDEF0 표기법은 비즈니스 프로세스의 공식적인 결점을 식별할 수 있게 하여 기업 활동 분석을 크게 용이하게 합니다.
• 3) 데이터 흐름 다이어그램(Data Flow Diagramming, DFD)은 작업 흐름 및 정보 처리를 설명하는 데 사용됩니다.

각 표준의 기능을 고려한 IDEF3가 선호될 수 있으며 워크플로 다이어그램이라고도 하는 정보 흐름의 상호 작용 논리를 설명하는 데 더 적합합니다. 정보 흐름에 대한 그래픽 설명, 정보 처리 프로세스와 개체 간의 관계를 사용하는 모델링 표기법입니다. 이러한 프로세스의 일부입니다.

기업의 비즈니스 프로세스를 설계할 때 기존 작업 조직 AS-IS(As is)의 기능 모델이 구축됩니다. AS-IS 모델을 기반으로 "누가 무엇을 했는지"와 각 사업부가 프로세스에 추가하는 내용에 대해 서로 다른 사업부 간에 합의가 이루어집니다.

AS-IS 모델을 사용하면 "내일 수행할 작업"으로 이동하기 전에 "오늘 수행할 작업"을 파악할 수 있습니다. 정보 시스템의 도입은 필연적으로 기업의 기존 비즈니스 프로세스의 재구성으로 이어질 것입니다. 기능 모델 분석을 통해 가장 많이 사용되는 위치를 이해할 수 있습니다. 약점새로운 비즈니스 프로세스의 이점은 무엇이며 어떻게 중대한 변화기존 비즈니스 조직 구조가 영향을 받습니다. 비즈니스 프로세스를 자세히 설명하면 기능이 언뜻 명백해 보이는 경우에도 조직의 단점을 식별할 수 있습니다. 비효율적인 활동의 징후는 쓸모없고 관리되지 않는 중복 작업, 비효율적인 문서 흐름( 원하는 문서적시에 적소에 나타나지 않음), 관리에 대한 피드백 부족(작업 결과에 영향을 받지 않음) 및 입력(객체 또는 정보가 비합리적으로 사용됨) 등

질문에 답하기 위해 기업은 미래에 어떻게 작동해야 합니까? 개편의 이득(손실)은? AS-IS 모델에서 발견된 단점은 비즈니스 프로세스의 새로운 구성 모델인 TO-BE(As it will) 모델을 생성하여 수정할 수 있습니다. TO-BE 모델은 정보 시스템 구현의 결과를 평가하고 작업을 수행하는 대안/최선의 방법을 분석하고 기업이 미래에 어떻게 기능할 것인지 문서화하는 데 필요합니다. 일반적으로 여러 TO-BE 모델이 구축되며, 그 중에서 일부 기준에 따라 최상의 모델이 선택됩니다(그림 7). 예를 들어, 각 TO-BE 모델은 특정 정보 시스템에 해당할 수 있습니다.

많은 기준이 있으며 가장 중요한 것을 결정하는 것은 쉽지 않습니다. 기업 정보 시스템 구현 후 비즈니스 프로세스의 효율성을 결정하기 위해서는 미터법이 필요합니다. 품질을 정량화해야 합니다.

BPwin은 분석가에게 모델 평가를 위한 두 가지 도구인 ABC(Activity Based Costing) 및 UDP(User Defined Properties)를 제공합니다. ABC는 다국적 기업에서 널리 사용되는 방법론이며 정부 기관조직의 비용 동인을 식별합니다.

비용 분석은 프로세스의 총 비용을 결정하기 위해 작업과 관련된 비용을 수집하는 데 사용되는 회계 규칙입니다. 기업의 기능에 대한 자세한 이해 없이 정량화가 불가능하기 때문에 비용 분석은 작업 모델을 기반으로 합니다.

일반적으로 ABC는 비용의 출처를 이해하고 기업의 재구성을 위해 원하는 작업 모델의 선택을 용이하게 하는 데 사용됩니다(Business Process Re-engineering, BPR). 원가 분석을 통해 제품의 실제 제조 원가 결정, 고객 지원의 실제 원가 파악, 비용이 가장 많이 드는 작업(먼저 개선해야 할 작업) 식별 등과 같은 문제를 각각의 문제에서 해결할 수 있습니다. AS-모델 IS 및 TO-BE.

따라서 우리는 비용 분석을 통해 정보 시스템 도입의 결과가 무엇인지, 실제로 생산성과 경제적 효과의 증가로 이어질 것인지, 그리고 어떤 것을 평가할 수 있다고 결론지었습니다.

또한 BPwin을 사용하면 상당히 효과적인 비용 추정을 할 수 있지만 이러한 추정에서 매우 정확하다고 주장하지는 않습니다. 정확한 비용 계산을 위해 전문 비용 분석 도구 EasyABC를 사용할 수 있습니다. BPwin은 양방향 내보내기(EasyABC에서 가져오기)를 지원합니다. 비용 분석 결과는 특별 보고서 BPwin - ABC에서 시각화됩니다. ABC를 사용하면 시스템의 비용 및 시간 특성을 평가할 수 있습니다. 비용 지표가 충분하지 않은 경우 UDP 사용자가 정의한 속성인 고유한 메트릭을 도입할 수 있습니다.

이 안에 명제 Computer Associates의 AllFusion 라인 요소가 고려됩니다.

주요 소스를 연구하고 분석한 후 도구 자체인 BPwin 프로그램을 통해 결론을 도출합니다. ISO9000 표준 준수를 위해 구조 설계, 비용 절감, 불필요한 작업 제거, 유연성 및 효율성 향상. BPwin은 한 번에 IDEF0 미국 연방 표준, IDEF3 및 DFD의 세 가지 모델링 표기법을 지원하며 자동화 정보 시스템 설계 분야의 고유한 소프트웨어 도구입니다. 모든 프로세스를 분석한 그림 14는 요구 사항 분석 및 기타 소프트웨어 엔지니어링 워크플로와 같은 모든 프로세스를 보여주는 단락 끝에 제시되어 있습니다.

"비즈니스 모델링" 워크플로는 AIS에 대한 요구 사항 분석 및 구성의 기초 역할을 하며 오류를 방지할 수 있습니다. "환경 관리" 워크플로는 형식, CASE 도구 및 작업 절차를 규제하는 AT 작업 그룹에 대한 초기 정보를 제공합니다.

프로젝트 관리 워크플로는 요구 사항 사양을 기반으로 합니다. 전략적 및 전술적 계획, 중간 이정표(예상 결과)의 형성은 시스템 요구 사항과 밀접하게 연결되어 있습니다.

분석 및 설계 작업 흐름은 AT에서 제공한 초기 데이터를 기반으로 수행됩니다. 이러한 워크플로는 어느 정도 병렬로 실행됩니다. 요구 사항과 관련된 문제가 발견되면 이 워크플로에서 AT 워크플로로 피드백이 제공됩니다.

"테스트" 워크플로는 테스트 프로세스(테스트 시나리오 등)를 관리하는 요구 사항 모델 및 추가 사양을 기반으로 합니다.

"구현" 워크플로의 경우 요구 사항과 관련이 없습니다. 한편, 그룹에서 선택한 프로세스에서 공식적으로 제공되지 않더라도 모든 프로젝트 워크플로에서 요구 사항을 분석하고 고려해야 하는 것은 당연합니다. 사람들은 실수를 하고, 프로젝트 초기 단계에서 실수는 단계를 거치면서 눈덩이처럼 커집니다. 따라서 프로젝트의 성공에 관심이 있는 모든 팀원이 요구 사항 사양을 살펴보고 자신에게 할당된 작업이 이러한 요구 사항을 충족하는지 확인하는 것이 유용합니다. 이를 통해 사양의 오류를 추적할 수 있는 피드백을 구성할 수 있습니다. 구현 팀이 요구 사항 수집 및 분석 팀과 분리되어 있기 때문에 많은 프로젝트가 중단되었습니다.

관리의 주요 측면 중 하나는 인식 및 분석에 편리한 설명의 제어 대상(조직 또는 시스템)의 가시성("투명성")을 제공하는 것입니다. 제어 개체는 임무를 결정하는 프로세스 네트워크로 나타낼 수 있으며, 이는 관리에 대한 프로세스 접근 방식입니다. 제어 개체 프로세스의 식별 및 설명을 통해 이러한 프로세스를 명확하게 이해, 관리 및 개선할 수 있습니다. 모델링이라는 절차를 통해 프로세스에 대한 적절한 설명이 가능합니다. "모델링"이라는 용어는 상호 작용하는 구성 요소 및 이들 사이의 관계 집합으로서 시스템에 대한 정확하고 충분하며 간결하고 이해하기 쉬운 분석 설명을 생성하는 프로세스로 이해되어야 합니다.

비즈니스 프로세스 모델링 단계.

1 단계. 조직의 관리 시스템 진단.

조직의 기존 관리 시스템에 대한 진단을 수행하는 것은 다음 작업을 해결해야 하기 때문입니다.

문제 해결에서 공무원과 부서의 상호 작용에서 문제 영역 식별;

비즈니스 프로세스로의 후속 분해와 함께 주요 및 보조 활동 할당

내부 규제 문서의 투명하고 질서 있는 시스템을 만들기 위한 전제 조건 형성.

이 단계에서 부서장과의 인터뷰가 진행되고 회사의 조직 구조가 분석되며 후속 개발을 위해 규제 문서의 예비 목록이 작성되고 프로세스 모델링 형식이 결정됩니다.

2단계. 기존 비즈니스 프로세스의 모델링.

이 단계의 주요 작업은 일련의 작업, 수행자 간의 책임 분담, 시기 및 작업 결과를 표시하는 비즈니스 프로세스 모델을 만드는 것입니다. 이 모델은 프로젝트의 이 단계를 구현할 때 조직의 비즈니스 프로세스 구현을 그래픽으로 표현한 것입니다.

기능 모델 및 다이어그램의 생성은 다음 순서로 발생합니다.

정보 수집에는 다음 활동의 조합이 포함될 수 있습니다. 문서 읽기, 기존 운영 관찰, 전문가 그룹에 질문하기, 한 명 이상의 전문가 인터뷰, 자신의 지식 사용 및 시스템 운영에 대한 허구적 설명(수정 가능) .

연구 대상의 분해. 객체를 분해할 때 무엇보다 전체 시스템의 입력 및 출력 데이터에 주의를 기울여야 합니다. 전체 시스템의 분해는 주요 데이터 유형 목록과 시스템의 주요 기능으로 시작됩니다. 이렇게 함으로써 정상과 비정상 상황을 모두 고려하여 시스템의 주요 기능을 정신적으로 검토하고, 피드백그리고 가능한 오류.

• 3. SADT에서 모델링한다는 것은 A0 및 A-0 다이어그램을 만드는 것을 의미합니다. 이 두 다이어그램은 연구 중인 시스템에 대한 모든 것을 최소한의 세부 정보로 완전히 알려줍니다. 모델링을 시작하기 전에 이를 준비하고, 정보를 수집하고, 연구 대상을 분해(분해 - 다이어그램 A0은 시스템의 가장 중요한 기능과 객체를 강조 표시)한 다음 이 분해를 일반화해야 합니다(다이어그램 A-0은 시스템을 다음과 같이 취급합니다. 이름을 부여하고 가장 중요한 입력, 제어, 출력 및 메커니즘을 결정합니다.)
• 3.1. 목적과 관점의 선택.
• 3.2. 데이터 목록을 컴파일합니다. 이 경우 데이터가 적은 것보다 많은 것이 좋습니다. 데이터를 유형별로 즉시 그룹화할 수 있습니다.
• 3.3. 기능 목록 만들기. 시스템의 기능은 사용되는 데이터 유형에 따라 더 잘 결합됩니다. 그런 다음 기능을 그룹(3개에서 6개)으로 결합합니다. 이러한 그룹은 동일한 수준의 복잡성을 갖고 각각 유사한 작업 및 목표를 갖는 거의 동일한 작업 범위 및 기능을 포함하는 것이 바람직합니다.
• 3.4. 다이어그램 A0(A0 - A-0)의 구성 및 일반화. 모든 SADT 다이어그램에는 해당 컨텍스트를 포함하는 상위 다이어그램이 있습니다. A0의 컨텍스트는 전체 모델의 일반화인 A-0입니다. 이 다이어그램에는 여러 가지 목적이 있습니다. 일반 기능시스템이 사용하거나 생산하는 기본 유형 또는 데이터 세트 세트를 제공하고 주요 데이터 유형 간의 관계를 나타내어 구별합니다.
• 3.5. 제한된 객체의 분해. 분해 프로세스의 시작은 고려된 다이어그램의 블록을 선택하고 이 블록과 해당 호로 정의된 개체를 고려하는 것으로 구성됩니다. 동시에, 먼저 분해가 A0 다이어그램의 많은 측면을 드러내고 이 블록의 다른 블록의 향후 분해에 더 큰 영향을 미칠 그러한 블록을 고려해야 한다는 점을 고려해야 합니다. 체계. 가장 의미 있는 블록을 선택할 때 우세와 기능적 복잡성 및 이해 가능성을 모두 고려해야 합니다. 첫 번째 분해에 가장 적합한 블록은 고려 중인 시스템의 본질에 가장 깊이 침투할 수 있는 블록입니다.
• 3.6. 반복 검토 프로세스.
• 3.7. 시뮬레이션 완료. 모델 또는 그 일부의 분해는 모델이 목표를 달성하기에 충분한 세부 수준에 도달한 경우 종료됩니다. 블록의 기능이 이미 분해된 모델의 다른 부분과 매우 유사하다는 것이 밝혀지면 블록 분해를 종료할 수 있습니다. 따라서 세부사항의 충분성, 추상화 수준의 변화, 관점의 변화, 유사한 기능이 분해를 종료하는 주요 기준입니다.
• 3.8. 문서 참조: Kalyanov, GN CASE-technologies. 구조 시스템 분석(자동화 및 응용) / G.N. 칼리노프. - M:, Lori, 2002. - S.76-80 ..

기능 모델 분석을 통해 가장 약한 부분이 어디인지, 새로운 비즈니스 프로세스의 장점은 무엇인지, 비즈니스 조직의 기존 구조에 얼마나 큰 변화가 일어날 것인지를 이해할 수 있습니다. 비즈니스 프로세스를 자세히 설명하면 기능이 언뜻 명백해 보이는 경우에도 조직의 단점을 식별할 수 있습니다. 프로젝트의 이 단계에 대한 작업 결과는 조직 활동의 현재 상태(또는 별도의 활동 영역)를 설명하는 일련의 비즈니스 프로세스 모델이 됩니다. 개발된 모델 세트는 관련 비즈니스 프로세스의 최적성과 최적화를 평가하기 위한 기초입니다. 참조: Vendrov, A.M. 현대적인 방법정보 시스템 설계 수단 / A.M. Vendrov. - M.: 재정 및 통계, 2005. - P.176. .

3단계. 비즈니스 프로세스의 최적성 및 최적화 평가.

조직의 향후 활동의 최적성은 구현 품질에 달려 있기 때문에 이 단계는 전체 프로젝트 과정에서 핵심입니다. 최적성을 평가할 때 비즈니스 프로세스의 다음 매개변수가 분석됩니다. 초기 데이터("입력")의 유효성 및 신뢰성 제어 조치의 완전성과 적시성, 그 존재; 비즈니스 프로세스 절차 구현의 틀 내에서 행동의 최적성; 최적의 작업 시간; 자원의 충분성; 최종 결과("출력물")의 품질, 타당성 및 신뢰성과 후속 비즈니스 프로세스 구현을 위한 충분성.

나열된 매개변수에 대한 최적성 평가를 수행하면 다음 결과를 얻을 수 있습니다.

• - 직원(부서) 및 "무책임 영역" 간의 부당한 기능 중복 식별.
• - 비즈니스 프로세스의 효율성을 감소시키는 비최적 영역 식별.
• - 비즈니스 프로세스 비용을 줄이기 위한 준비금 식별.

이 단계의 작업 결과는 조직의 비즈니스 프로세스 개선 제안을 포함하여 지정된 평가 매개 변수에 따른 비즈니스 프로세스 분석에 대한 보고서입니다. 이 보고서는 비즈니스 프로세스의 최적 모델 개발을 위한 기초입니다("있는 그대로").

4 단계. 변경 사항 구현 조직.

이 단계 구현의 주요 목적은 직원들이 일상 활동에서 비즈니스 프로세스 구현을 위한 새로운 모델을 이해하고 사용하도록 하는 것입니다. 따라서 직원의 변화에 ​​대한 저항이 줄어듭니다.

조직 활동에 변경 사항을 도입하면 다음 작업 세트가 구현됩니다.

• - 새 모델 도입을 위한 목표와 활동, 절차 및 형식을 명확히 하기 위해 변경을 수행할 책임이 있는 직원에게 브리핑합니다.
• - 개발된 비즈니스 프로세스 모델의 실제 작업 수행 가능성과의 편차를 식별하기 위해 회사 기능의 새로운 표준에 대한 파일럿 운영을 모니터링합니다.
• - 시운전 결과에 따른 비즈니스 프로세스 모델 조정 참조: 엔터프라이즈 비즈니스 프로세스 개편 프로젝트의 위임 사항. 액세스 모드: http://www.fineexpert.ru/content.asp?mID=60&ID=128&mode=w .

5단계. 규제 문서 개발

비즈니스 프로세스의 규제 - 관리 시스템의 진단 단계에서 고정된 구성의 비즈니스 프로세스에 대한 지침 개발 및 조정. 물론 일련의 규제 문서 작성은 전체 프로젝트의 주요 결과이지만 그럼에도 불구하고 구현해야 합니다.

6 단계. 규제 문서의 구현.

이 단계 구현의 주요 목적은 직원들이 일상 활동에서 비즈니스 프로세스 구현을 위한 새로운 모델을 이해하고 사용하도록 하는 것입니다. 따라서 기업 직원의 변화에 ​​대한 저항이 감소합니다.

개발 된 규제 문서 구현 작업의 구현은 진단 단계에서 유망한 것으로 확인 된 비즈니스 프로세스의 활동을 규제하는 전체 프로젝트의 논리적 결론입니다.

비즈니스 프로세스는 생산자의 자원을 소비하고 가치를 창출하며 결과를 소비자에게 전달하는 논리적이고 순차적이며 상호 연결된 일련의 활동입니다. 조직이 비즈니스 프로세스를 최적화하도록 장려하는 주요 이유 중에는 비용 또는 생산 주기 기간 단축, 소비자 및 국가의 요구 사항, 품질 관리 프로그램의 구현, 회사 합병, 내부 조직 모순 등이 있습니다.

비즈니스 프로세스 모델링을 통해 회사가 전체적으로 작동하는 방식, 외부 조직, 고객 및 공급업체와 상호 작용하는 방식뿐만 아니라 각 작업장에서 활동이 구성되는 방식을 결정할 수 있습니다.

비즈니스 프로세스 모델링은 효과적인 치료법기업 재편의 다양한 단계에서 발생하는 위험을 예측하고 최소화하는 수단 인 회사 활동을 최적화하는 방법을 찾습니다. 이 방법을 사용하면 각 개별 프로세스와 조직의 모든 비즈니스 프로세스에 대한 비용 견적을 집계할 수 있습니다.

비즈니스 프로세스의 모델(설명)을 생성하기 위한 방법론(표기법)은 개체가 현실 세계이들 사이의 링크는 모델로 표시됩니다.

비즈니스 모델은 기업의 실제 또는 의도된 활동을 반영하는 비즈니스 프로세스에 대한 공식화된(그래픽, 표, 텍스트, 기호) 설명입니다.

가장 단순한 경우 비즈니스 모델은 단일 다이어그램으로 구성될 수 있지만 비즈니스 프로세스는 일반적으로 너무 복잡하고 다차원적이기 때문에 실제로는 거의 허용되지 않습니다. 이러한 프로세스의 모델에는 다음 구성 요소가 포함됩니다.

• - 대표. 각 보기는 비즈니스 프로세스의 특정 측면을 반영합니다. 뷰는 특정 관점을 반영하고 해당 관점과 관련되지 않은 세부 정보를 숨기는 추상화입니다.
• - 다이어그램. 각 보기는 비즈니스 프로세스의 구조적 및 동적 측면을 반영하는 다양한 유형의 일련의 다이어그램으로 구성됩니다.
• - 개체 및 프로세스. 개체는 프로세스에서 사용되는 리소스(재무, 물질, 인적, 정보)를 나타냅니다.

모든 비즈니스 프로세스 모델링 방법의 가장 중요한 개념은 개체 및 관계의 개념입니다. 모델의 각 개체는 소위 주제 영역(조직)의 일부 실제 개체를 반영합니다. , 사람, 문서, 기계 및 장비, 소프트웨어 등 원칙적으로 동일한 방법 내에서 실제 세계의 다른 엔터티를 반영하는 모델 개체도 다릅니다. 링크는 개체 간의 관계를 설명하기 위한 것입니다. 이러한 관계에는 시간 경과에 따른 실행 순서, 정보 흐름을 통한 통신, 다른 개체에 의한 사용 등이 포함될 수 있습니다.

각 개체와 링크는 실제 개체의 특정 특성을 반영하는 여러 매개변수 또는 속성으로 특징지어집니다. 속성의 구성은 모델을 사용하여 표시되는 조직의 실제 개체 유형에 따라 다릅니다. 속성은 개체 번호, 이름, 설명, 실행 기간(기능의 경우), 비용 등과 같은 특성일 수 있습니다. 실제로 조직 모델을 만들 때 모델 개체의 속성 설명은 비즈니스 프로세스 모델링을 위한 특수 도구를 사용하여 수행됩니다. . 이를 통해 특정 계산이 수행되고 프로세스의 분석 및 평가가 수행되는 비즈니스 프로세스의 가장 간단한 "설명"에서 더 복잡한 "모델"을 만들 수 있습니다.

비즈니스 프로세스 모델은 넓은 범위사용자(비즈니스 분석가, 일반 직원 및 회사 경영진)이며, 해당 분야의 비전문가가 구축하는 경우가 많습니다. 정보 기술, 가장 널리 사용되는 모델은 그래픽 유형으로 특정 방법론에 따라 비즈니스 프로세스가 시각적으로 표시됩니다. 그래픽 이미지-- 주로 상자와 화살표로 구성된 차트. 이러한 표현은 각 개체 및 연결의 다양한 속성(색상, 배경, 스타일 등) 및 속성(무게, 크기, 비용, 시간 등)으로 표현되는 높은 다차원 정보 콘텐츠를 갖습니다. 최근 몇 년 동안 비즈니스 프로세스 모델링을 위한 소프트웨어 도구 개발자는 그래픽 모델을 다른 유형의 모델, 특히 실행 가능한 모델로 변환하는 데 많은 관심을 기울였습니다. 그 목적은 비즈니스 프로세스의 자동화와 실행과 관련된 정보 시스템의 통합. 비즈니스 리엔지니어링 금융

비즈니스 프로세스 모델링의 목표는 일반적으로 다음과 같이 공식화됩니다.

• - 조직의 구조와 조직에서 발생하는 프로세스의 역학에 대한 이해를 제공합니다.
• - 조직의 현재 문제와 해결 가능성에 대한 이해를 제공합니다.
• — 고객, 사용자 및 개발자가 조직의 목표와 목표에 대해 동일한 이해를 공유하도록 보장합니다.
• - 조직의 비즈니스 프로세스를 자동화하는 소프트웨어에 대한 요구 사항 형성을 위한 기반을 만듭니다.

비즈니스 모델 적용의 주요 영역은 비즈니스 프로세스 리엔지니어링입니다. 동시에 현재 및 향후 활동의 모델을 구축하고 첫 번째 상태에서 두 번째 상태로 전환하기 위한 계획 및 프로그램을 구축해야 합니다. 모든 현대 기업은 복잡한 시스템이며 그 활동에는 상호 영향을 미치는 수만 가지 기능 및 운영의 실행이 포함됩니다. 사람은 그러한 시스템이 어떻게 작동하는지 자세히 이해할 수 없습니다. 이것은 그의 능력의 한계를 넘어선 것입니다. 따라서 소위 "AS_IS"(있는 그대로) 및 "AS_TO_BE"(있는 그대로) 모델을 만드는 주요 아이디어는 해당 기업이 무엇을 하는지(할 것인지), 어떻게 기능하는지(할 것인지)를 이해하는 것입니다. 기능) 목표를 달성하기 위해.

미래 소프트웨어 시스템의 목적은 무엇보다도 현대 정보 기술을 통해 비즈니스 문제를 해결하는 것입니다. 소프트웨어 요구 사항은 비즈니스 모델을 기반으로 형성되며 시스템 설계 기준은 주로 최대한의 만족을 기반으로 합니다. 비즈니스 프로세스 모델은 컨설턴트가 권장 사항 및 결론을 개발하기 위해 사용하는 중간 결과가 아니라는 점에 유의해야 합니다. 그들은 건설 목표에 따라 매우 실용적인 중요성을 지닌 독립적인 결과입니다.

따라서 비즈니스 모델링의 다음 목표를 구분할 수 있습니다.

• - 표준 "있는 그대로"의 비즈니스 프로세스에 대한 설명
• - 기업의 "병목 현상"을 식별하고 제거하는 효과적인 수단입니다.
• - 위험을 예측하고 최소화하기 위한 도구
• - 후속 자동화를 위한 회사의 활동에 대한 설명.

비즈니스 모델링 작업:

• - 사업 개편
• - 사업자 인증
• - 기업경영을 위한 정보시스템 적용

비즈니스 프로세스 모델은 다음 질문에 답해야 합니다.

• 1. 원하는 최종 결과를 얻기 위해 어떤 절차(기능, 작업)를 수행해야 합니까?
• 2. 이러한 절차는 어떤 순서로 수행됩니까?
• 3. 고려하는 비즈니스 프로세스 내에 어떤 제어 및 관리 메커니즘이 존재합니까?
• 4. 프로세스 절차는 누가 수행합니까?
• 5. 각 프로세스 절차에서 사용하는 입력 문서/정보는 무엇입니까?
• 6. 프로세스 절차에서 생성되는 출력 문서/정보는 무엇입니까?
• 7. 프로세스의 각 절차를 완료하는 데 필요한 리소스는 무엇입니까?
• 8. 절차 실행에 적용되는 문서/조건은 무엇입니까?
• 9. 절차 및 프로세스의 구현을 전체적으로 특징짓는 매개변수는 무엇입니까?

현재 많은 비즈니스 리더들이 다양한 목적을 위해 조직에서 프로세스 모델링 프로젝트를 시작하고 있습니다. 이러한 목표는 두 그룹으로 나눌 수 있습니다. 첫 번째 그룹의 목표를 달성하면 조직의 특정 문제에 대한 솔루션을 제공하고 활동의 효율성을 높여야 합니다. 이 경우 비즈니스 프로세스 설명 프로젝트에서 실제적이고 실질적으로 중요한 결과가 예상됩니다. 두 번째 목표 그룹은 슬로건 목표로 특징지을 수 있습니다. 조직의 누구도 프로젝트에서 어떠한 효과도 기대하지 않으며, 정치적 목표를 달성하기 위해 개발되거나 재정 자원 할당에 대한 정당화 역할을 합니다.

첫 번째 목표 그룹에서는 비즈니스 프로세스를 설명하는 프로젝트가 개발될 몇 가지 방향을 선택해야 합니다. 실제로 관리자는 우선 작업이 진행되는 방식과 효율성이 감소하는 부분(재정적 손실 발생)을 이해하는 작업을 설정합니다. 비즈니스 프로세스 모델의 결과 세트는 미래에 자동화 목적으로 사용될 것이라고 가정합니다. 또한 모델에서 기존 워크플로 시스템에 대한 정보를 얻고 필요한 변경 등을 수행하려고 합니다. 여러 식별이 가능하다. 특징이 단계에서 최고 수준의 관리자가 작업 설명을 공식화합니다.

• - 문구의 모호함 및 정의 부족(예: 프로세스)
• - 프로젝트 목표를 달성하기 위한 명확한 기준이 부족합니다.
• - 비즈니스 프로세스 모델의 결과 집합이 미래에 어떻게 사용될 것인지에 대한 이해 부족.

이러한 기능은 대부분 관리자가 조직의 프로세스 관리 시스템을 개발하는 수단 중 하나로 비즈니스 프로세스를 설명하는 것의 중요성을 나타내지 않는다는 사실을 반영합니다. 그러나 사실 비즈니스 프로세스 모델 자체는 관리 도구가 아닙니다. 그러나 규제 문서 작성, 활동 분석 및 일부 의사 결정을 위한 기초 역할을 할 수 있습니다.

비즈니스 프로세스 모델:

• - 정확성과 방법론을 소개합니다.
• - 하나의 일관된 프레젠테이션을 제공합니다.
• - 프로세스, IT 시스템, 조직 구조, 정보 및 데이터를 통합합니다.
• - 관계를 보고 분석할 수 있습니다.
• - 정확성, 검토 및 테스트 프로세스를 확인하는 데 도움이 됩니다.
• - 가정 시나리오를 평가하기 위한 유익한 환경을 제공합니다.
• - 프로세스 변경의 신속한 구현을 위한 기반입니다.

따라서 비즈니스 프로세스 모델링 프로젝트의 목표를 정의해야 합니다. 설정된 목표에 따라 다양한 접근 방식(방법론)을 사용하여 조직의 비즈니스 프로세스를 설명할 수 있습니다. 프로젝트 구현 방법론은 이 프로젝트에 할당된 목표와 자원의 양을 고려하여 개발(적응)되어야 합니다.

소개

1. 비즈니스 프로세스 모델링

2. 비즈니스 프로세스의 분류

3. 비즈니스 프로세스 모델링 표준

결론

사용된 소스 목록

소개

"비즈니스 프로세스 모델링"의 개념은 엔터프라이즈 관리의 복잡한 자동화를 위해 설계된 복잡한 소프트웨어 제품의 시장 출현과 동시에 대부분의 분석가의 삶에 들어왔습니다.

이러한 시스템은 항상 회사 활동에 대한 심층적인 사전 프로젝트 조사를 의미합니다. 이 설문 조사의 결과는 활동 관리에서 "병목 현상"을 제거하기 위해 별도의 단락에서 권장 사항이 작성된 전문가 의견입니다.

이 결론에 따라 자동화 시스템을 구현하기 직전에 소위 비즈니스 프로세스 재구성이 수행되며 때로는 회사에 매우 심각하고 고통 스럽습니다. 물론 수년에 걸쳐 발전한 팀은 항상 "새로운 방식으로 생각"하기가 어렵습니다. 기업에 대한 이러한 포괄적인 조사는 항상 복잡하고 경우에 따라 크게 다릅니다.

복잡한 시스템을 모델링하는 이러한 문제를 해결하기 위한 잘 정립된 방법론과 표준이 있습니다. 이러한 표준에는 IDEF 방법론 계열이 포함됩니다. 이들의 도움으로 다양한 섹션에서 광범위한 복잡한 시스템의 활동 모델을 효과적으로 표시하고 분석할 수 있습니다. 동시에 시스템 프로세스 검사의 폭과 깊이는 개발자 자신이 결정하므로 생성된 모델에 불필요한 데이터가 과부하되지 않도록 합니다.

비즈니스 프로세스 모델링을 사용하면 기업이 전체적으로 작동하는 방식, 외부 조직, 고객 및 공급업체와 상호 작용하는 방식뿐만 아니라 각 개별 작업장에서 활동이 구성되는 방식을 분석할 수 있습니다.

"비즈니스 프로세스 모델링" 개념의 정의에 대한 몇 가지 접근 방식이 있습니다.

- 이것은 관리자가 일반 직원의 작업 방식과 일반 직원의 동료 작업 방식 및 모든 활동의 최종 결과를 알 수 있도록하는 기업의 비즈니스 프로세스에 대한 설명입니다.

비즈니스 프로세스 모델링- 이것은 기업의 활동을 개선할 기회를 찾는 효과적인 수단입니다.

모델링 비즈니스 프로세스- 기업 재편의 다양한 단계에서 발생하는 위험을 예측하고 최소화할 수 있는 도구입니다.

비즈니스 프로세스 모델링개별적으로 취한 각 프로세스와 기업의 모든 비즈니스 프로세스를 합산하여 비용을 추정할 수 있는 방법입니다.

현대 기업은 지속적으로 활동을 개선해야 합니다. 이를 위해서는 새로운 기술 및 비즈니스 관행의 개발, 활동의 최종 결과의 품질 향상, 물론 새롭고 더 나은 도입이 필요합니다. 효과적인 방법기업의 관리 및 조직.

비즈니스 프로세스생산자의 자원을 소비하고 가치를 창출하며 그 결과를 소비자에게 제공하는 논리적이고 일관되며 상호 연결된 일련의 활동입니다. 조직이 비즈니스 프로세스를 최적화하도록 장려하는 주요 이유 중에는 비용 또는 생산 주기 기간 단축, 소비자 및 국가의 요구 사항, 품질 관리 프로그램의 구현, 회사 합병, 내부 조직 모순 등이 있습니다.

비즈니스 프로세스 모델링기업의 활동을 최적화하는 방법을 찾는 효과적인 도구이며, 기업 재편의 다양한 단계에서 발생하는 위험을 예측하고 최소화하는 도구입니다. 이 방법을 사용하면 각 개별 프로세스와 조직의 모든 비즈니스 프로세스에 대한 비용 견적을 집계할 수 있습니다.

비즈니스 프로세스 모델링 결정은 일반적으로 그림 1에 표시된 이유로 이루어집니다.

그림 1 - 비즈니스 프로세스 모델링을 결정한 이유

비즈니스 프로세스 모델링은 회사 활동의 여러 측면에 영향을 미칩니다.

조직 구조의 변화;

부서 및 직원의 기능 최적화;

관리자의 권리와 의무의 재분배;

내부의 변화 규범 문서및 운영 기술.

시뮬레이션의 목적받은 정보의 분석 처리에보다 편리한 시각적 그래픽 형식으로 회사 및 비즈니스 프로세스에 대한 지식을 체계화합니다. 모델은 조직의 비즈니스 프로세스 구조, 구현 세부 사항 및 워크플로우 순서를 반영해야 합니다.

조직의 비즈니스 프로세스 모델링에는 구조 및 상세의 두 단계가 포함됩니다.

구조적조직의 비즈니스 프로세스 모델링은 BPwin 툴킷을 사용하여 IDEF0 표기법으로 수행하거나 Rational Rose 툴킷을 사용하여 UML로 수행할 수 있습니다. 자세한 모델링은 UML에서 수행됩니다.

구조 모델링 단계에서 모델은 다음을 반영해야 합니다.

기존 조직 구조;

시뮬레이션된 비즈니스 프로세스 실행에 사용되며 주요 의미에 대한 설명과 함께 작업 흐름 모델링에 필요한 문서 및 기타 엔티티

보다 일반적인 그룹에서 개인 비즈니스 프로세스까지의 계층 구조를 반영하는 비즈니스 프로세스의 구조

행위자 간의 문서(데이터, 자료, 리소스 등) 생성 및 이동 순서를 반영하는 최종 비즈니스 프로세스의 상호 작용 다이어그램.

상세한비즈니스 프로세스 모델링은 동일한 모델에서 수행되며 필요한 세부 사항을 반영해야 하며 조직 활동에 대한 명확한 보기를 제공해야 합니다.

자세한 비즈니스 프로세스 모델에는 다음이 포함되어야 합니다.

반영하는 일련의 선례 가능한 옵션비즈니스 프로세스를 "있는 그대로" 실행

비즈니스 프로세스의 순서를 자세히 설명하는 작업 다이어그램

워크플로 체계를 반영하는 상호 작용 다이어그램.

사업 운영- 비즈니스 활동의 한 행위의 내용을 구성하는 일련의 조치, 절차.

사업 운영은 일반적으로 미리 결정된 행동 계획에 따라 상품 배치를 생산하거나 구매하는 것으로 시작하여 상품 판매 및 이익 창출로 끝납니다. 비즈니스 거래라고도 함 업무.

업무 기능기업이 스스로의 생존과 목적을 달성하기 위해 해결하는 과제이다. 함수는 질문에 답합니다 무엇을 해야할지. 물론 회사의 틀 내에서 많은 기능을 구분할 수 있습니다. 따라서 모든 비즈니스 시스템에는 재무 관리, 생산, 판매와 같은 기능이 있어야 합니다.

비즈니스 모델 -회사가 하는 일과 돈을 버는 방법입니다(Tom Malone).

사업 전략이론이 있고 비즈니스 모델은 가설이다 (Nicholas Carr)

비즈니스 모델내부 및 외부 환경단일 시스템 내의 회사.

2. 비즈니스 프로세스의 분류

다음 분류를 할당합니다.

비즈니스 프로세스의 위치에 따라 조직 구조회사는 다음 비즈니스 프로세스를 구분합니다.

수평 프로세스 - 수평적 상호작용을 반영하는 프로세스

개별 수평 프로세스 - 개별 직원(조직 단위)이 수행하는 프로세스

교차 기능 수평 프로세스 - 많은 직원(조직 단위)이 수행하는 프로세스

수직 프로세스 - 수직을 따라 직원(조직 단위)의 상호 작용을 반영하는 프로세스

통합 프로세스 - 프로세스 참가자의 상호 작용을 수직 및 수평으로 표시하는 프로세스입니다.

복잡성 정도에 따라 다음이 있습니다.

단일 프로세스 - 단음절 프로세스;

중첩 프로세스 - 보다 복잡한 프로세스의 일부인 단일 프로세스(매크로 프로세스)

관련 프로세스는 특정 알고리즘에 따라 선택되고 순차적으로 구현되는 단일 프로세스입니다.

목적에 따라:

주요 비즈니스 프로세스 - 제품 생성 및 클라이언트에 대한 구현과 관련된 실제 운영 작업의 구현을 보장하는 수평적 비즈니스 프로세스 - 이들은 기업의 제품과 직접 관련되어 부가가치 창출에 영향을 미치는 운영 프로세스입니다.

지원 비즈니스 프로세스 -주요 프로세스의 실행을 보장하는 수평 비즈니스 프로세스는 생산 된 상품 및 서비스와 직접 관련이 없지만 부가가치 작업을 수행하는 것은 불가능합니다.

비즈니스 프로세스 관리 - 회사의 활동, 핵심 및 지원 비즈니스 프로세스를 관리하는 수직적 비즈니스 프로세스입니다. 이들은 전략 형성, 사업 계획 및 통제 프로세스입니다.

조직 목표의 계층 구조에서 위치에 따라:

최상위 비즈니스 프로세스 - 회사에 가장 중요한 회사의 전략적 목표를 구현하기 위한 프로세스입니다.

중간 수준의 비즈니스 프로세스 - 전술적 목표의 구현을 목표로 하는 비즈니스 프로세스

운영 목표의 구현을 목표로 하는 하위 수준 비즈니스 프로세스의 비즈니스 프로세스.

상세 수준에 따라:

매크로 프로세스 - 최상위 비즈니스 프로세스를 설명하는 데 필요한 세부 수준으로 확장된 비즈니스 프로세스

하위 프로세스 - 중간 수준의 비즈니스 프로세스를 설명하는 데 필요한 세부 수준의 비즈니스 프로세스

마이크로 프로세스 - 세부 수준이 최대인 비즈니스 프로세스는 하위 수준 비즈니스 프로세스를 설명하는 데 사용됩니다.

균형 성과 기록표의 주요 구성 요소:

금융 비즈니스 프로세스;

클라이언트 비즈니스 프로세스;

비즈니스 - 생산 공정;

개발, 학습 및 성장의 비즈니스 프로세스.

기능적 모델링 표준 IDEF0

IDEF0 표준은 관리에 대한 프로세스 접근 방식의 고전적인 방법으로 간주됩니다. 프로세스 접근 방식의 주요 원칙은 조직 구조가 아닌 비즈니스 프로세스에 따라 조직의 활동을 구성하는 것입니다. 가치있는 소비자에게 중요한 결과를 형성하는 비즈니스 프로세스이며 향후 처리해야 할 개선 사항입니다.

기준IDEF0 모든 주제 영역의 개체에 대한 기능적 모델을 구축하도록 설계된 일련의 규칙 및 절차입니다.

모델IDEF0 복잡한 개체를 블록으로 표시되는 구성 요소로 분해하는 설명서가 포함된 일련의 다이어그램입니다. 각 주요 블록의 세부 사항은 다른 다이어그램에서 블록으로 표시됩니다. 각 세부 다이어그램은 이전 수준의 다이어그램에서 블록 분해입니다. 각 분해 단계에서 이전 수준의 다이어그램을 상위 다이어그램이라고 합니다. 모델의 총 수준 수(컨텍스트 수준 포함)는 5-6을 초과하지 않아야 합니다. 연습에 따르면 이것은 모든 산업에서 현대 기업의 완전한 기능 모델을 구축하기에 충분합니다.

IDEF1 정보 모델링 표준

IDEF1 표준은 기업 비즈니스 내의 정보 흐름 간의 관계를 분석하고 연구하기 위한 도구로 개발되었습니다. "있는 그대로" 원칙에 따라 기업 정보 구조의 시각적 모델을 구축하기 위한 도구로 IDEF1 방법론을 적용합니다. 모델 구축의 예가 그림 2에 나와 있습니다.

그림 2 - IDEF1 모델 구축의 예

정보 모델의 주요 구성 요소는 다음과 같습니다.

다이어그램 - 일련의 규칙에 따라 사용된 데이터의 구성 및 논리적 관계를 나타내는 정보 모델의 구조적 이미지

사전 – 모델의 각 요소 값은 텍스트 조각으로 설명됩니다.

IDEF1 방법론의 기본 개념은 엔터티 개념입니다. 본질실제 또는 추상 객체로 정의된 집합 독특한 속성알려진 속성이라고 합니다. 각 엔티티에는 이름과 속성이 있습니다.

하위 시스템 번호는 이를 식별하는 역할을 합니다. 이름 필드에서 서브시스템의 이름은 주제와 해당 정의 및 추가가 포함된 문장 형식으로 입력됩니다.

이 프로세스는 특정 알고리즘에 따라 입력 데이터 스트림을 출력 데이터 스트림으로 변환하는 것입니다. 물리적으로 프로세스는 다양한 방식으로 구현될 수 있습니다. 입력 문서를 처리하고 보고서를 발행하는 조직(부서)의 하위 부서, 프로그램, 하드웨어 구현 논리 장치 등이 될 수 있습니다.

데이터 흐름 다이어그램의 프로세스는 그림 4와 같이 묘사됩니다.

프로세스 번호는 이를 식별하는 데 사용됩니다. 이름 필드에 활성 모호하지 않은 동사가 포함된 문장으로 프로세스의 이름을 입력합니다. 부정형(계산, 계산, 확인, 결정, 생성, 수신) 뒤에 대격 명사가 붙습니다. 예: "납세자 정보 입력", "현재 비용에 대한 정보 제공", "입금 확인".

물리적 구현 필드의 정보는 프로세스가 수행 중인 조직, 프로그램 또는 하드웨어 장치의 부분을 나타냅니다.

데이터 저장 장치는 언제든지 저장 장치에 넣고 일정 시간이 지나면 불러올 수 있는 정보를 저장하는 추상적인 장치이며 삽입 및 추출 방법은 무엇이든 될 수 있습니다.

데이터 저장 장치는 마이크로피시, 파일 캐비닛의 서랍, RAM의 테이블, 자기 매체의 파일 등의 형태로 물리적으로 구현될 수 있습니다.

데이터 저장 장치는 문자 "D"와 임의의 숫자로 식별됩니다. 드라이브의 이름은 디자이너에게 가장 큰 정보 콘텐츠의 관점에서 선택됩니다.

데이터 저장소는 일반적으로 미래 데이터베이스의 프로토타입이며 여기에 저장된 데이터의 설명은 데이터 모델과 일치해야 합니다.

데이터 흐름은 소스에서 수신자로 연결을 통해 전송되는 정보를 정의합니다. 다이어그램의 데이터 흐름은 흐름 방향을 나타내는 화살표로 끝나는 선으로 표시됩니다. 각 데이터 스트림에는 해당 콘텐츠를 반영하는 이름이 있습니다.

DFD 계층 구조를 구축하는 주요 목표는 시스템에 대한 설명을 모든 세부 수준에서 명확하고 이해할 수 있게 만들고 이들 간의 관계가 정확하게 정의된 부분으로 나누는 것입니다.

결론

최근 몇 년 동안 IDEF 가족의 방법론에 대한 러시아의 관심이 꾸준히 증가하고 있습니다. 동시에 IDEF3–5와 같은 표준에 대한 관심은 이론적인 반면 IDEF0에 대한 관심은 실질적으로 정당합니다.

그러나 대부분의 관리자는 여전히 IDEF 표준 모델링의 실제 적용을 기존 비즈니스 관리 시스템을 최적화하는 효과적인 방법보다 패션에 대한 찬사로 간주합니다. 아마도 이것은 이러한 방법론의 실제 적용에 대한 현저한 정보 부족과 대다수 출판물의 필수 소프트웨어 편향 때문일 것입니다.

현재 러시아 기업의 재무 및 경제 활동에 대한 조사 및 분석을 위한 거의 모든 프로젝트가 건설과 관련되어 있다는 것은 비밀이 아닙니다. 자동화 시스템관리. 이로 인해 대다수를 이해하는 IDEF 표준은 정보 기술의 도입과 조건부로 분리 할 수 ​​없었지만 도움을 받으면 문자 그대로 연필과 종이로 작은 지역 문제도 효과적으로 해결할 수 있습니다.

결론적으로 모델을 만들어 기업의 비즈니스 프로세스를 분석한다는 아이디어의 가장 큰 장점은 다용성이라는 점을 강조하고 싶습니다. 첫째, 비즈니스 프로세스 모델링은 기업 활동 개선 및 경쟁력 강화와 관련된 거의 모든 질문에 대한 답입니다. 둘째, 이 방법론을 구현한 기업의 책임자 또는 경영진은 기업을 독립적으로 개선하고 미래를 예측할 수 있는 정보를 갖게 됩니다.

1. Voinov I.V. 경제 시스템 및 프로세스 모델링. ARIS 모델 구축 경험 [텍스트]: 모노그래프 / I.V. Voinov - M.: SUGU, 2002. - 392 p.

2. 볼코프 O.N. 비즈니스 프로세스 모델링을 위한 표준 및 방법론 [텍스트]: 교과서. 대학 수당 / O.N. 볼코프. - M.: ASV, 2000. - 145p.

3. Grigoriev D.I. 기업의 비즈니스 프로세스 모델링 [텍스트]: 교과서. 수당 / D.I. Grigoriev. - M.: IRTs, 2006. - 214p.

4. Kalyanov G.N. 비즈니스 프로세스의 모델링, 분석, 재구성 및 자동화 [텍스트]: 교과서. 수당 / G.N. 칼리노프. -M.: 재정 및 통계, 2006. - 319p.

5. Pinaev D.K. 비즈니스 프로세스 모델링: 컴플렉스에 대해 사용 가능 [텍스트]: Ref. 수당 / D.K. Pinaev. -M.: RGAS, 2003. - 247p.

튜터링

주제를 배우는 데 도움이 필요하십니까?

당사의 전문가는 귀하가 관심 있는 주제에 대해 조언하거나 개인 교습 서비스를 제공할 것입니다.
신청서 제출상담을 받을 가능성에 대해 알아보기 위해 지금 바로 주제를 표시합니다.

기존 비즈니스 프로세스를 식별 및 설명(비즈니스 프로세스 분석)하고 새로운 비즈니스 프로세스를 설계(비즈니스 프로세스 설계)하는 활동. 비즈니스 모델링은 분야 및 프로세스에서 별도의 하위 프로세스라고도 합니다 ... ... Wikipedia

비즈니스 모델링은 비즈니스 객체(사업부, 직책, 자원, 역할, 프로세스, 운영, 정보 시스템, 정보 매체 등)에 대한 설명과 관계 표시를 포함하여 조직 모델을 형성하는 활동입니다 ... ... 비즈니스 용어집

제어 조치와 자원의 도움을 받아 프로세스의 입력이 프로세스의 결과인 출력으로 변환되는 일관되고 목적이 있으며 규제된 활동의 시스템입니다. ... Wikipedia

비즈니스 모델링은 기존 비즈니스 프로세스(비즈니스 프로세스 분석)를 식별 및 설명하고 새로운 비즈니스 프로세스를 설계(비즈니스 프로세스 설계)하는 활동입니다. 비즈니스 모델링은 규율 및 개인이라고도합니다 ... ... Wikipedia

비즈니스 프로세스는 소비자를 위한 특정 제품 또는 서비스를 만드는 것을 목표로 하는 일련의 상호 관련된 활동 또는 작업입니다. 명확성을 위해 비즈니스 프로세스는 비즈니스 프로세스 순서도를 사용하여 시각화됩니다. ... ... Wikipedia

조직이 경제적, 사회적 및 기타 형태의 가치를 창출하고 고객에게 전달하고 획득하는 방법을 논리적으로 설명합니다. 비즈니스 모델 개발 프로세스는 비즈니스 전략의 일부입니다. 이론적으로 그리고 ... ... Wikipedia

정보 시스템 개발에서 주제 영역의 개체 동작에 대한 일련의 규칙, 원칙, 종속성(도메인 인간 활동시스템이 지원하는). 그렇지 않으면 비즈니스 로직이 규칙의 구현이라고 말할 수 있습니다 ... ... Wikipedia

비즈니스 시뮬레이션은 내부 조건에 따라 해당 실제 경제 단위(기업, 기업, 산업, 국가의 세분)에 가능한 한 가까운 경제 시스템의 대화형 모델입니다. 비즈니스 ... 위키백과

- (시뮬레이션) 연구 목적으로 마케팅 상황을 모방합니다. 컴퓨터 시뮬레이션을 통해 사용 가능한 모든 정보가 컴퓨터에 로드되어 마케팅 전략에 대한 가능한 옵션을 비교할 수 있습니다. 에… … 비즈니스 용어집

서적

• 비즈니스 모델링, Osipova Tatyana. 이 책은 Print-on-Demand 기술을 사용하여 귀하의 주문에 따라 제작됩니다. 비즈니스 프로세스 모델링 또는 다음을 기반으로 하는 비즈니스 모델링…
• 비즈니스 모델링 및 데이터 분석. Microsoft Excel로 실제 문제를 해결하는 Winston Wayne L. Wayne Winston은 다음을 사용합니다. 실제 작업데이터를 빠르게 분석하고, 의사 결정을 내리고, 재고를 확보하고, 보고서를 작성하고, 데이터를 처리하고, 분석을 구축하는 방법을 알려줍니다.