기존 워크플로우 관리 시스템은 해당 워크플로우 프로세스 정의가 각 신규 사례를 인스턴스화하는 방식으로 작동합니다. 즉, 각 사례에 대해 신규 워크플로우 인스턴스를 생성합니다. 워크플로우 엔진은 해당 워크플로우 프로세스 정의에 따라 이 사례에 대해 활성화할 활동을 계산합니다. 활성화된 각 활동에 대해 작업 항목이 생성되어 해당 역할을 가진 각 사용자의 작업 폴더에 배치됩니다. 사용자는 작업 폴더에서 작업 항목을 선택하고 적절한 활동을 시작하는 등의 작업을 시작합니다. 하나의 작업 항목이 여러 사용자의 작업 폴더에 나타날 수 있지만 한 명의 사용자만 해당 활동을 수행합니다. 작업 항목을 선택하면 워크플로우 관리 시스템이 관련 응용 프로그램을 시작하고 해당 작업의 실행 결과를 모니터링합니다. 사용자는 작업 폴더에 있는 작업 항목만 볼 수 있으며 작업 항목을 선택하면 해당 활동의 실행과 관련된 정보 [2 ~ 4] 만 얻을 수 있다는 점에 유의해야 합니다.
2. 사례 기반 개념 엔지니어링 프로젝트 워크플로우 관리는 하나의 작업으로 볼 수 있으며 많은 프로세스와 활동으로 구성됩니다. 그러나 제조업 등 산업부문과는 달리 공사 건설 과정은 매우 복잡하며, 이런 복잡성은 약한 구조성과 다변성의 두 가지 측면으로 나눌 수 있다. 프로젝트 건설 정보의 약 90% 가 구조화되지 않은 문서 정보인 것처럼, 엔지니어링 건설의 대부분의 처리 과정은 구조화되지 않거나 약한 구조화 작업 과정에 속합니다. 이러한 비정형 또는 약한 정형 프로세스를 지원하기 위해 기존 워크플로우 관리 기술을 채택할 수 없습니다. 동시에, 엔지니어링 건설 분야에는 설계 변경, 엔지니어링 청구, 입찰 구매 등과 같은 고도로 구조화된 관리 프로세스가 있습니다. 이러한 관리 프로세스의 수는 적지만 매우 중요합니다. 시공문제의 85% 가 공예와 관련이 있고 제품과의 관계가 크지 않기 때문에 공사 과정에서 관리 워크플로우를 어떻게 자동화할 것인가는 여전히 중요한 의미가 있다는 연구결과가 나왔다. 그러나 이러한 관리 워크플로우는 어느 정도 가변적이며 고정 사전 프로세스 정의가 있는 기존 워크플로우 관리 기술에 크게 의존하므로 효과적인 지원을 제공할 수 없다는 점에 유의해야 합니다. 사실, 많은 연구가들은 유연성이 부족하여 기존의 워크플로우 관리 기술이 엔지니어링 관행에서 종종 실패로 끝나는 경우가 많다고 지적합니다. 기존 워크플로우 관리 기술의 유연성이 부족한 주된 이유는 경로가 워크플로우를 구동하는 유일한 메커니즘이기 때문입니다. 즉, 작업은 미리 고정된 인과 관계를 기반으로 한 작업 폴더에서 다른 작업 폴더로 흐릅니다. 따라서 최종 프로세스 모델은 너무 단순하거나 너무 복잡하고 불투명합니다. 이러한 이유로 최근 몇 년 동안 일부 학자들은 소위 사건 처리 시스템을 제시하여 근본적인 사상 변화를 주장하였습니다. 즉, 워크플로는 예정된 경로에 의해 구동되어서는 안 되며 사례에 의해 추진되어야 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 기존의 워크플로우 관리 기술은 워크플로우 프로세스에서 "무엇을 해야 하는가" 에 초점을 맞추고 있으며, 사례 처리 기술은 비즈니스 목표를 달성하기 위해 "무엇을 할 수 있는가" 에 초점을 맞추고 있습니다. 사례 처리 기술은 새로운 워크플로우 관리 방법으로 유연하고 지식 집약적인 비즈니스 프로세스를 지원할 수 있는 새로운 가능성을 제공합니다. 실제로 사례 처리 원칙의 적용은 네덜란드의 하이제만스라는 대형 건설회사의 일부 프로젝트에서 큰 성공을 거두었다. 간단히 말해서, 사례는 워크플로우 프로세스의 한 예이며 워크플로우 참가자가 처리해야 하는 객체입니다. 엔지니어링 건설 분야에서는 구체적인 설계 변경 프로세스, 구체적인 엔지니어링 청구 프로세스 및 구체적인 입찰 조달 프로세스가 될 수 있습니다. 사례를 워크플로우 프로세스를 실행하여 만든 제품 (시공 관리 프로세스의 제품은 정보) 으로 보는 경우 워크플로우 프로세스를 실제로 구동하는 것은 제품의 특성입니다. 제품의 특성에 초점을 맞추면 한 작업 폴더에서 다른 작업 폴더로 기존 푸시 지향 경로를 풀 지향 메커니즘 (한 사례에 대한 데이터 객체 중심) 으로 변환할 수 있습니다. 사례 기반 워크플로우 관리 방법을 더 자세히 설명하기 위해 UML (Unified Modeling Language) 을 통해 해당 객체 모델을 제안했습니다 (그림 2).
3. 사례 기반 프로젝트 워크플로우 관리 프로세스 정의 사례 기반 프로젝트 워크플로우 관리의 경우 프로세스 정의도 필요합니다. 전통적인 시공 공예는 서로 갈라진 것으로 여겨진다. 정보 시스템이 없을 때, 정보는 고립되어' 정보의 외딴 섬' 을 형성한다. 정보 시스템이 적용된 후, 이미 일정한 작업 흐름이 형성되었다. 그러나 비즈니스 프로세스 리엔지니어링 (BPR) 도구를 기반으로 엔지니어링 프로젝트 워크플로우를 설명하는 프로세스 관리 개념을 적용하여 정보 시스템의 워크플로우를 통합하고 최적화할 필요가 있습니다. 프로세스 정의에 의해 생성된 프로세스 모델은 전체 워크플로우 관리 시스템의 기초입니다. 많은 워크플로우 관리 시스템의 개발 플랫폼은 사용자가 실제 비즈니스 프로세스를 직관적으로 모델링할 수 있는 시각적 프로세스 모델링 도구를 제공합니다. 설정된 프로세스 모델은 직접 시스템에서 지원할 수 있습니다. 프로세스 모델링 방법에는 활성 네트워크 다이어그램, 직접 그래프, 통합 정의법 (IDE F3) 및 Petri 네트워크가 있습니다. 이 중 Petri 네트워크 프로세스 모델링 방법이 최근 몇 년 동안 학계에서 가장 주목받고 있습니다 [5,6]. 단순화된 페트리 네트 모델은 작업 관리 프로세스를 모델링하는 데 사용됩니다. 일반적인 작업 관리 과정에서 팀 리더는 먼저 팀 구성원 중 한 명에게 작업을 완료하도록 요청합니다. 팀 구성원은 자신의 역량 및 다양한 제약 조건에 따라 임무 요구 사항을 확인한 다음 팀 리더에게 응답을 보냅니다. 팀 멤버가 임무를 완료할 수 없다고 생각하는 경우 팀 책임자는 적절한 다른 팀 멤버를 찾아야 합니다. 팀 구성원이 임무를 완료할 수 있는 능력이 있음을 확인하면 팀장은 임무를 상세히 설명하고 팀 멤버에게 보냅니다. 팀 구성원이 임무에 대한 자세한 설명을 이해하지 못할 경우 임무가 이해되고 실행될 때까지 질문을 할 수 있습니다. 팀 리더는 팀 멤버가 제출한 임무 결과를 원래 임무 상태 선언과 비교합니다. 비준하면 업무 성과를 제출하다. 그렇지 않으면 팀 리더는 임무를 다시 팀 구성원에게 반환합니다 (그림 3).
4. 사례 기반 워크플로우 관리 시스템 아키텍처 이전 섹션의 분석을 통해 그림 4 는 사례 기반 워크플로우 관리 시스템 아키텍처를 보여 주며 워크플로우 관리 연합이 제시한 참조 모델과 거의 일치합니다 [7]. 시스템의 논리적 설계에는 프로세스 정의, 사용자 역할 할당, 데이터 처리 설계, 양식 정의, 사례 승인, 할당 등이 포함됩니다. 워크플로우 실행 서비스의 워크플로우 엔진은 전체 시스템의 핵심이며 워크플로우 프로세스 인스턴스 실행, 사례 활동의 상태 제어, 사용자 사례 목록 유지 관리 및 외부 자원에 대한 액세스를 주로 담당합니다. 관리 모니터링 도구는 실행 중 프로세스 인스턴스의 상태를 모니터링하고 관리합니다. 워크플로우 엔진은 프록시를 통해 프로세스 데이터, 사용자 정보 및 문서 정보와 같은 데이터베이스 리소스에 액세스할 수 있습니다. 클라이언트 응용 프로그램은 프로세스 인스턴스 실행 중 수동 개입이 필요한 작업을 처리할 수 있는 방법을 제공합니다. 호출된 응용 프로그램은 프로세스 인스턴스가 실행되는 동안 워크플로우 실행 서비스에 의해 호출되는 응용 프로그램 데이터를 처리하는 외부 응용 프로그램 (예: 문서 관리 모듈) 입니다. 그림의 몇 가지 WAPI (워크플로우 애플리케이션 그림 인터페이스) 는 식별된 개발 플랫폼에 따라 달라집니다. 이 프레임워크에 따르면 Lotus Domino/ Notes 의 Flow2 Mark 워크플로우 개발 플랫폼을 통해 이를 수행할 수 있습니다.
5. 사례 그림 5 는 사례 기반 엔지니어링 프로젝트 워크플로우 관리 시스템의 인터페이스를 보여 줍니다. 워크스테이션의 위쪽 창은 현재 실행 중이거나 보고 있는 프로세스이며 하위 프로세스를 포함할 수 있습니다. 왼쪽 아래 창에는 현재 프로세스의 활동 및 하위 프로세스가 적절하게 표시됩니다. 아래 오른쪽 창에는 현재 프로세스와 관련된 양식, 문서 등의 정보가 있습니다. 그림에서 볼 수 있듯이 시스템의 현재 프로세스는 설계 시나리오 변경 요구 사항을 등록하는 하위 프로세스와 설계 시나리오 수정, 새 설계 시나리오 검토, 배포 보관 등 설계 시나리오의 변경입니다. 이 인터페이스의 경우 1 활동과 하위 프로세스의 상태는 할 일, 진행 중, 완료, 건너뛰기, 다시 실행 등이 될 수 있습니다. 예를 들어, 장삼 (디자이너라고 가정) 이 새로운 설계 방안에 대한 승인이 없는 집행 역할은 이 활동을 건너뛸 수 있습니다. ② 열린 양식은 어떤 데이터가 강제적이고 어떤 것이 제한되어 있는지를 지적해야 한다. 예를 들어, 설계 방안 심사표의' 동의 여부' 는 강제 데이터여야 한다.
더 많은 공사/서비스/구매 입찰 정보, 낙찰률 향상, 공식 홈페이지 고객서비스 아래쪽을 클릭하여 무료 상담:/#/? Source=bdzd