Project A

In this project, you are asked to do some of the tasks of the first phase of "business process engineering" on the process described pages 4 and 6 of the book (this is the phase before any re-engineering task). More precisely, you are asked to
1) identify the components of this process (and of one sub-process) using the WSF,
2) identify the resources of this process,
3) identify the concerns of the user, client and management,
4) identify the critical success factors of this process,
5) give a Petri-net of this process in the PNLF notation (see Section 5 below).

Apart from point 5, examples of such exercises have been given in the lecture notes of the modules 1 to 3. Click here to access a more detailed example that takes the Case Study pages 263-266 of the book as a basis (note: use this example as a model but submitting 3 or 4 pages instead of 5 is sufficient). As in these examples, since you have little information, you will need to make assumptions.

This project is due on Saturday September 10th 2005 midnight. Deliverable: an HTML document (with the same structure as this one) to be deposited in the digital dropbox. There should not be any image in this HTML document since the PNLF notation is a textual notation (like many other graph-based formalisms, Petri nets have many notations, some being textual such as PNLF and XML-based notations, and some being graphic like the notation used in the book).


1. System components

1.1. WSF elements for the whole process


1.2. WSF elements for one particular task

Select one of the tasks of the whole process (they are listed page 4 of the book) and decompose this task, that is, consider it as a sub-process. Please list at least 8 tasks for this subprocess. Intead of a list of tasks, you may give a Petri net in the PNLF notation but you are not required to.


2. Resources

First, construct a table that identifies the Resource Task and Resources available for the whole process (similar to Figure 3.5 page 82 of the book). Please invent resource names and divisions.

Resource class Resources
. .


Second, construct a table identifying Task, Role and Organisational Unit (similar to Figure 3.5 page 82).

Task Role organizational unit
. . .


Third, instead of constructing a Resource Classification diagram for the whole process as in Figure 3.1 page 77, you will represent this Resource Classification in the notation used for the learning journal. Use the following representation of the Figure 3.1 page 77 as a model. Note that uppercases are only used at the beginning of proper names. 

person_in_Atlanta
  instance: Chas  Mary  Peter  Trudy  Jack  Kevin  John  Anita;

person_in_Denver
  instance: Carl  Yvonne  Frank;

person_in_purchasing_departement
  instance: Chas  Peter  Kevin;

person_in_sales_departement
  instance: Mary  Carl  Trudy  Jack  Yvonne  John  Anita  Frank;
 
secretary
  instance: Chas  Mary  Carl;

office_employee
  specialization: head_of_departement  salesperson;

  head_of_departement
    instance: Peter  Trudy;

  salesperson
    instance: Anita  Frank;


3. Concerns of the user, client and management

Use the above cited example as model. No need to be long.


4. Critical Success Factors

Identify the pertinent indicators or measures of performance for each CSF (eg number of requests processed per hour, requests to be filled within four hours, respond to a customer inquiry within one hour, etc). Remember they must be quantifiable. Keep in mind the seven work system principles as you develop the CSFs (Topic 2 of Module 2). Use the above cited example as model.


5. Petri-net

Convert figure 1.2 of the book (page 6) into a Petri net. To represent it, use the PNLF notation I introduced in my document about PIPE and Woflan.
In this project, you may - but are not required to - represent the Petri net (in the PNLF notation) for the sub-process you introduced in Section 1.2 (no point will be added if you represent it). If you do, you can do it here on in Section 1.2.

Do not directly convert Figure 1.2 of the book (page 6) into a Petri net. The reason is that Figure 1.2 does not properly represent the process described page 4 of the book. For example, the approval task refered to in task 10 (page 4) and its two possible outcomes have to be represented, and the decision to pay or not after the legal proceedings must be represented too. Furthermore, in accordance with the representation conventions described in my document on PIPE/Woflan/PNLF, I want you to use 1) implicit OR splits, not explicit OR-splits (see page 59), 2) explicit names for the tasks and for their input/output places. The names used for tasks in Figure 1.2 are not explicit at all, and a direct representation of Figure 1.2 would use explicit OR-splits (note that only implicit OR splits can be used in PIPE, and page 56 explains why using an implicit OR split is sometimes adequate when using an explicit OR split is not). Thus, for example, you should definitely NOT write
  [Reaction *t12]
    { yes->(*c16)->[Pay *t15],
      no->(*c14)->[Objection *t13]
    }.
but you should write
  [recording_of_the_client's_reaction *t12]->
    (acceptance_of_the_amount_to_be_paid?)
      { yes->[payment_of_the_claim *t15],
        no->[assessment_of_the_client's_objection *t13]
      }.
Note how "-", "_", lowercases and variables (e.g. "*t13") are used (details are in my document on PIPE/Woflan/PNLF); the following has 6 errors (3 on line 1 and 2 on line 3) and penalties will of course apply if you make such/similar careless errors:
  [Recording_of_the_client's-reaction *t12]-
    (acceptance_of_the_amount_to_be_paid?)
      { yes-->[payment_of_The_claim *t15]
        no->[assessment_of_the_client's_objection *t13]
      }.
Note that this is only an example, there may be more/other connections from [recording_of_the_client's_reaction *t12].

Other precisions: