Collaborative Process Management ################################ Collaborative Process Management ******************************** ======== Overview ======== The management of a collaborative process works along side the other information that is tracked for the models. Much of the management objects will be used to record "why" something is being (has been) done, and what was used to do it. The |Collaborative Process Management| objects are: * Request: * This is a request for something(s) (which can be a study, requirement or breakdown). It has a name and description to record more information about what is requested. It records when it was requested, who requested it, and who was it requested of, and what the status of the request is (e.g. has it been accepted or rejected). It can also record which |collaborative process management| object triggered the request. .. figure:: /objects/images/request_3x2.png :scale: 100% Request icon * Work Order: * This is the order to do something(s) (which can be a study, requirement or breakdown). It has a name and description to record more information about what is ordered. It can record the request(s) that it is a response to, who ordered it, what the status of the order is (e.g. it a new order, or has it been approved). It is also linked to all the planned activities that it is controlling. .. figure:: /objects/images/work_order_3x2.png :scale: 100% Work Order icon * Planned Activity: * This is the plan for doing something (the subject of the planned activity), e.g. creating a new Model Type or Collaborative Model Template, e.g. executing an Associative Model Network, e.g. creating the results data for a Model Instance, e.g. Running a |quality gate|. For other options see |SysML - Collaborative Process Management Diagram| * It can have planned start and end date, and has a status. It can also identify the planned method and resources to be used. * It can be assigned to people, organisations, teams or even tools (for automatic execution of something). * Note: Planned Meetings are specialisations of Planned Activity, so all the above also applies to these, though there are additional features also. See Quality Gates for more details .. figure:: /objects/images/planned_activity_3x2.png :scale: 100% Planned Activity icon * Actual Activity: * This is what actually happened to something; see planned activity above for examples. There could have been many actual activities for one plan, or many plans but only one actual activity. * Similarly to planned activities it has an actual start and end date, and can also identify the actual method and resources used. * The status is likely to have more options than a planned activity because it needs to record the failure modes, rather than just cancelled. Though these options are business rules so outside the scope of the Business Object Model. * It records the organisation/people/tools that did the activity. * Note: Actual Meetings are specialisations of Actual Activity, so all the above also applies to these, though there are additional features also. See Quality Gates for more details .. figure:: /objects/images/actual_activity_3x2.png :scale: 100% Actual Activity icon .. figure:: /objects/images/cpm_sequence.png :scale: 100% Sequence of Collaborative Process Management objects ===================== Simple example of use ===================== This is a simple scenario describing one way to use the different |collaborative Process Management| objects. It uses the |Very Simple Example|, of a beam of constant cross section that is supported at one end, and deflection occurs at the other. It also assumes a set of business rules for lifecycle (status) of the objects. Some work has been done that has identified a problem with excessive deflection. Someone then requests that a new study is launched to try and resolve the issue by investigating an alternative wall thickness. So the Request is triggered by the earlier deflection calculation activity, it applies to the new deflection study, is requested by someone (requestor), and is sent to someone (recipient). The recipient then approves or rejects the Request, and the status is changed. .. figure:: /objects/images/cpm_ex_1.png :scale: 100% Step 1. Request the study Once the Request has been approved, someone then orders some work. This creates a WorkOrder which applies to the same deflection study, is in response to the Request, and is ordered by someone. This too can have a lifecycle. .. figure:: /objects/images/cpm_ex_2.png :scale: 100% Step 2. Order the study The work is then planned for the study. Someone creates an Associative Model Network which has a plan controlled by the study work order, and within that AMN creates the models and their plans also controlled by the work order. These plans can include who it is assigned to, and this could be a specific person, or assigned to an organisation or team, or even assigned to a tool like a workflow engine. The plans can also specify the methods and tools that are planned to be used. .. figure:: /objects/images/cpm_ex_3.png :scale: 100% Step 3. Plan the activities for the study Someone then accepts the assignment and an actual activity is created with a status of "New" and linked to the plan. They start the work and the status changes to "In_work". They complete the work, and the status changes to "Completed", and the methods and tools used are identified, to complete the definition of what actually happened. .. figure:: /objects/images/cpm_ex_4.png :scale: 100% Step 4. Record what actually happened .. rst-class:: expand ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Representation using Business Object Model classes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The diagram below shows the first study which is to compute the deflection of the beam. The |collaborative Process Management| objects are shown in orange. .. figure:: /objects/images/vse_ea_AMN_with_Defn_method_Activities.png :scale: 100% Process Management for Study, Associative Model network and Model Instance The first study concluded that there was in sufficient accuracy in the deflection computation, as well as too much deflection, so requests, and then orders a second study to be undertaken. .. figure:: /objects/images/vse_ea_Study2_Activities.png :scale: 100% Series of Process Management objects with triggers See SysML - Collaborative Process Management Example for details For more information see: SysML - Collaborative Process Management Diagram. .. sectionauthor:: |Judith Crockford| .. include:: /objects/documents/main/Keywords.rst