When the modelers create a Business Process they must specify two things: the process logic and the process data.
The process logic is the description of the activities and events that take place during the execution of one instance of the business process. For example, for an imaginary BP:
when a fax arrives, the customer should be validated before going on. If the user is valid, then… ; at the end a fax should be sent back to the client.
In terms of executable business process, we should rewrite the process logic in a more structured fashion, as follows:
- when the event fax arrives is detected, then the process is launched.
- The first task is to determine what is the customer number
- then the customer number is used to validate the customer,
- then… ;
- at the end, a fax should be generated;
- the user must print it and
- sent the printed fax back to the customer.
Of course, the final form depends on the level of granularity and of detail of the (web) services that should be used, as well as of the information that the users of the system should introduce. In this case, the rewritten process logic can be easily translated to BPMN.
Ideally, the description of the process logic should satisfy the business needs. However, the resulting description cannot be executed because some elements are not there, as explained here. This is what happened with our first model. We must then complement this description with another layer of description.
The second level of specification is the process data. The current description of the process logic does not indicate more than the sequencing of both tasks and events. However, nothing has been said about how to use data for making decisions (if-else scenarios). Another important issue is data manipulation.
Nevertheless, in real life, every time that some event happens during a business process, some data is taken and sent to other systems, transformed into some useful result, and those results are communicated back to the process in order to use them some time in the future of the execution of the process.
This is what we do using forms, notebooks, post-its, IT systems. This information is resilient and many of the future decisions of how to handle the processing will be done on the basis of these data. That’s why they are called process data. In most cases, these data are simply transferred to a new system without any transformation.
Let us see un example of a very ordinary dialog over the phone:
- Carlos : Hi Susan, I just received a fax from a customer, could you help me validate him?
- Susan: Of course. Just give me the customer number, and the family name.
- Carlos: His customer number is: CN-CNCNCN-CN, and his last name is LNLNLN.
- Susan: OK. Give me a second. The customer FNFNFN, LNLNLN, identified with the number CN-CNCNCN-CN is valid. You can go ahead.
- Carlos: Thank you. Excuse me one more time, but: do you know how to make a claim in this new system?
- Susan: I’m not sure, but I think you should press the button “Customer Is Valid” in order for the system to know that I validated the customer for you.
- Carlos: Yeah, I see. Something new appeared on the screen. It asks me to print a response letter for the customer.
- Susan: Just do it. It will print a model reply letter with the reference number of the claim.
- Carlos: It’s done. But it’s also printing something on the sticker printer. It’s a sticker with the reference number and some barcode.
- Susan: You’re done. You stick the barcode to the incoming fax. Then you put it in the binder that is marked “Claims Dpt.”. The system will send them a message immediately so they know they have something pending in your office.
- Carlos: Yeah, I see. Before I had to call them all the time so they could come take it. It was not really effective with these guys.
- Susan: It’s improving. You’ll see. Don’t forget to take the other half of the sticker and put it on your logging book along with the date.
- Carlos: OK. Thanks for all your time and comprehension. Sorry if it took too long.
- Susan: Don’t care. Bye.
All these data: fax, “Customer is valid”, sticker, reference number, customer number, customer last name, customer first name, nature of the fax(claim), date, etc. are stored temporarily in order to perform a series of tasks. Some of these are physical data, other are just logical data and data references. The most important feature of those is that they are local and private to one instance of the business process:
- The fax is unique (one instance in paper, received at a time/date),
- the reference number is unique (the system should guarantee a sequential number for each request),
- the validation is unique (the customer is valid at the date/time of the request, but it might not be the case before or after),
- etc.
Therefore, the process logic is now complete: We know what event to expect or what activity should take place, and also what it takes to perform each activity.
We didn’t have enough space to cover the manipulation itself, and how to transform data. This will be done in a series of entries labeled “Process Data”.
