In Part 2, we compared how a Case life cycle might look in Pega’s Case Life Cycle Designer versus BPMN. Here, in Part 3, we’ll consider when you should and should not use Pega’s Case Life Cycle Design tool to model the business process.
As we have seen, if you are working on understanding the business process, a model in BPMN gives you a much more ‘joined-up’ view. Ideally, by the time you get into the high level design of your Pega solution, the business will have already worked with appropriately experienced business analysts to produce models of their “To Be” business process in BPMN and those models will be the input to your Pega design. In fact, they should be an input to the Inception phase.
Despite the fact that BPMN has been an international standard for modelling business processes for more than a decade, my experience is that most BAs don’t yet know how to use it and so it’s unlikely that a business will provide robust process models as inputs to the Inception phase of your project. However, even if the business does provide robust process models, a corresponding Pega Case Life Cycle Model (CLCM) is still not necessarily advisable.
When should you consider not producing a CLCM?
You need to model an entire business process and not just the tasks that are to be implemented in Pega.
If you need to show activities that are not to be implemented in Pega, do not model the business process inside Pega. This has been true since the very first version of PegaRules more than a decade ago. You can only show in a flow rule, what is to be implemented in Pega. You can only show in a Discovery Map what is to be implemented in Pega. You can only show in a Case Life Cycle Model what is to be implemented in Pega. I have known some inexperienced BAs who have modelled activities that were not to be implemented. I have even known Certified Pega BAs who modelled, as alternative paths, functionality that was to be implemented at some point in the future, thus revealing a fundamental lack of understanding of both process modelling and Pega itself.
The business entity represented by a Pega Case can be acted on by more than one business process.
It is very important to remember that Pega tightly couples the data of a Case with the tasks that can be performed on that Case. There is no distinction. A Pega Case is both its data and its activities. However, in business architecture the definition of the characteristics of a thing are separate from (but linked to) the definitions of the one or more processes that can act upon that thing. This is what we call “separation of concerns”. If your case is a simple one, such as the expense claim example in the Pega BA and SA training courses, and only one business process can act on it, then the CLCM may be an appropriate modelling tool. However, the CLCM cannot show how more than one business process can act upon a business entity.
The business process does not require any human intervention.
A Case in Pega must have tasks that are assigned to a human to perform. If the business process requires complete automation of tasks (even if the process is started by a human), then a CLCM is not the right modelling tool.
If your business process cannot be represented by a CLCM, it doesn’t mean it cannot be implemented in Pega. Far from it, Pega is a very good tool for implementing automated business processes. Your job as a BA is to articulate the business need clearly, unambiguously and concisely. If you do that with tools and techniques other than Pega’s CLCM, rest assured that the Pega LSA will design a good technical solution.
However, if your only background in doing analysis for a Pega project is the Pega BA training course, you are likely to force your business process(es) into the CLCM when it is not appropriate, you will imply things that will confuse and misdirect the LSA, leading to delays and a dissatisfied customer.
Remember that the Pega BA training course is an “essentials” course, not an exhaustive one.
Regardess of whether a CLCM is appropriate, if the business does not bring robust process models to the table, my recommendation is that you take some time to work with the business to produce them. I would first establish the scope of the target process or processes. See the link at the end of this post for a tutorial on how to do that. In the case of a straightforward process such as the ‘Manage Expense Claim’ process we saw in Part 2, I hope you can see that it would only take a few minutes to produce the high-level view of the process in BPMN; there wouldn’t be a significant delay in producing the CLCM in Pega and you would have more confidence that the model in Pega represented the real business need. In fact, one person on the team could model the life-cycle in Pega while the BA models it in BPMN, so there would be no delay at all. This is akin to what Pega calls a “Real-time Whiteboard” session. Indeed, one of Pega’s criteria for deciding whether to run such a session is that the scope is less complex. However, if you didn’t get an accurate view of the complexity of the scope in the first place, you may mistakenly decide to use a “Real-time Whiteboard” or even “Real-time Capture” session and then find you are trying to build a prototype for a process that you don’t understand.
If the business area is much more sophisticated, such as the processes to handle a tax fraud case, there is all the more reason to model the processes in BPMN because you don’t want to get too far into your technical solution design before discovering that you haven’t understood the business process (or that the business people didn’t explain the process well).
Other advantages of modelling processes in BPMN before (or, less ideally, at the same time as you model the life cycle in Pega):
- You can show the entire business process and not just the activities that will be implemented in Pega
- You can show the business events that can impact the process
- You can show the interactions between your process and other processes / external entities
- You can link your process models to other artefacts in the business architecture, such as, business glossary, decision models, event models, role definitions, etc.
If you do decide to produce a model using BPMN (or the customer provides one), don’t forget to attach each version of the model to the Specification in Pega that corresponds to your Case Type.
Kind regards.
Declan Chellar
Related posts:
Leave a Reply