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.
../../../_images/request_3x2.png

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.
../../../_images/work_order_3x2.png

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
../../../_images/planned_activity_3x2.png

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
../../../_images/actual_activity_3x2.png

Actual Activity icon

../../../_images/cpm_sequence.png

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.

../../../_images/cpm_ex_1.png

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.

../../../_images/cpm_ex_2.png

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.

../../../_images/cpm_ex_3.png

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.

../../../_images/cpm_ex_4.png

Step 4. Record what actually happened

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.

../../../_images/vse_ea_AMN_with_Defn_method_Activities.png

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.

../../../_images/vse_ea_Study2_Activities.png

Series of Process Management objects with triggers

See SysML - Collaborative Process Management Example for details

For more information see: SysML - Collaborative Process Management Diagram.

Section author: Judith Crockford