I hope you don't mind if I give you my take on this. I have copied your questions into my email and attached answers.
1. Is there generally only one BUC per Business event?
· Generally true, but not necessarily. I could imagine a BUC being joined midway for example, by a higher-level Business Event occurring, so a BUC with multiple entry points. Similarly, a BUC could be triggered by several Business Events. However, when you see such things it is an opportunity to questions and perhaps redesign at the Business level and gain even more benefits, by problem simplification.
2. We generally use multiple PUC for a BUC. Is this correct?
· Absolutely.. it is quite normal to see sequences of manual and automated process. An important point here is to recognise opportunities for re-use of PUC and possible process simplification.
3. How do you recommend we break down PUC's. By functional area? By department?
· A PUC will have a Primary Actor who (usually) initiates the “conversation”. That Actor would come from a department and will need to have a recognisable title from your organisation. A PUC spread over multiple departments sounds a little suspicious to me and I guess I would need to see the detail before commenting further. I would not rule it out, but it could reflect a conflict between the BUC and PUC structure.
4. Here is the project we are working with. (I think I have written about this before)
5. Processing applications on line-
6. One business event will be 'Person fills in application form online'
a. OK with that
7. The Business Use Case will be something like 'Process Application' form
a. Ok again
8. This is where things get a little bit murky for us. The application form will be passed from one department to another.
a. If in the passing there is a manual intervention, for example a document is printed out and then goes for approval before going into the PUC, then this would imply 2 or more PUCs. Alternatively, one PUC could do it, if it maintained a State about the document… as in “Stage 1 OK”, “Stage 2 OK”, “Stage 3 pending”, meaning that the document if reopened in the PUC, would start with Stage 3 processing. However, this could get complex and it is a trade off between fewer PUC and flexibility. Personally I would go for separate PUCs and anchor them off one higher level window, so that the user does not get to see that there are different PUCs in use.
9. Is it a separate business event for each time the application form is passed from department on or is it still under the one business event
a. I see this as a hierarchy of Business Events. The first one can trigger one or more subsequent events. This concept allows easy tracking of events and process. You can sometimes handle this by naming conventions. If the top level BE is BE1, then the subsequent BEs are BE1.1, BE1.2 and so on. This can get messy though if BE1.1 might also be used by another BE process say BE2.
b. Each BE triggers a BUC and then one or more PUC. It would be sensible to keep a spreadsheet view of all of this. As James knows I am not a proponent of diagrams because, although they present concepts well, they do not allow you easily to track (significant) changes or analyse. A simple table of BUC against PUC does. It is terse and easy to manage.
10.(Person fills in application form online)
a. Which them presumably goes back into the PUC and then into the containing BUC , which may or may not trigger the PUC to issue and acceptance or whatever.
I hope this helps. Please feel free to contact me again
Oak Lodge Consulting Ltd
20 Back Road
Tel: 01223-890390; Fax: 0870-7063077
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.