Building Reliable Process Models: BPMN Events

An introduction to the meaning of Events in BPMN.

This video is a short introduction to the meaning of the shapes but is not an exhaustive tutorial on how to use them.

Twitter
Visit Us
LinkedIn
Follow by Email
RSS

Building Reliable Process Models: BPMN Pools and Lanes

An introduction to the meaning of Pools and Lanes in BPMN.

This video is a short introduction to the meaning of the shapes but is not an exhaustive tutorial on how to use them.

Twitter
Visit Us
LinkedIn
Follow by Email
RSS

Building Reliable Process Models: Defining Process Scope

Rather than jumping straight into modelling process steps, set out the scope of the process first. Here is a method you can use to do that.

Twitter
Visit Us
LinkedIn
Follow by Email
RSS

BPMN 2.0: What is it? Why use it?

Before we get into the vocabulary and grammar of BPMN 2.0, let’s have a quick look at what it is and why I think you should be using it for process modelling.

If you find this tutorial useful, please subscribe to my YouTube channel for more. Thank you.

Twitter
Visit Us
LinkedIn
Follow by Email
RSS

Defining Process Scope

As a business process modeler, you might find yourself modelling what you think is one process, only to find that it is several processes. This can dramatically alter your estimate of how much effort is required.

I learned this to my cost many years ago. This video outlines my approach to defining the scope of a business process, so you can better estimate how many processes need to be modelled, mitigate the risk of your work expanding unexpectedly, keep yourself focused on what is relevant and provide clarity to all stakeholders from the outset.

This tutorial is aimed at people who are new to process modelling and experienced process modelers who want to take a more structured approach.

If you find this tutorial useful, please subscribe to my YouTube channel for more. Thank you.

Twitter
Visit Us
LinkedIn
Follow by Email
RSS

Identifying User Stories and Deriving Acceptance Criteria

Most Product Owners I have met do not have a method for identifying candidate user stories or deriving acceptance criteria for those stories.

CAVEAT: I believe you should only model to the level of detail needed, regardless of what type of model you are using. If the team were building a process to allow employees to claim back business expenses, I would not spend a lot of time modelling the process because the process itself is unlikely to be complex. However, I have never worked on a project where the processes were not complex and I have found that it is the process models themselves that tell you what your candidate user stories are (although not all of them will come from process models). This blog post is in the context of complex business operations.

I have been on a few projects now where the Product Owners were new to the concept of user stories. In some cases, the POs received no training at all prior to taking up their role and had no Agile Coach to guide them.

My experience is that when the user story is the only technique available to POs and BAs, avoidable misunderstandings always come to light during playbacks, testing and even in production. Yes, I know Agile is meant to allow you to quickly iterate and enhance but that is too often used as an excuse not to do any analysis or planning.

User stories do not exist in isolation from one another. When user stories are plucked out of conversations with users about complex business operations instead of being derived from models of those operations, you can be left with a jigsaw puzzle instead of a picture of those operations. Yes, you can put the picture together from the pieces but the whole idea of a puzzle is that it is meant to be difficult and take you a long time. Who wants to build business operations and software like that?

This “puzzle” approach leads to some or all of the following problems:

  • Not identifying all the user stories
  • Identifying some wrong ones
  • Not fully understanding how the user stories relate to each other
  • User stories that negatively impact each other (one user not knowing or caring about another user’s needs)
  • User stories that do not support the strategic goals of the business or, worse, contradict those goals
  • User stories being written from the PO’s or BA’s perspective (“As a BA…”) instead of the business perspective
  • User stories missing the value statement (“So that…”) – missing because it was not understood or, worse, the user story added no value to the business
  • Missing acceptance criteria
  • Incorrect acceptance criteria

The way a real jigsaw puzzle is produced is analogous to the approach you should be taking: you have the picture first and then you break it up into pieces (user stories). The only difference is that understanding where each piece fits should subsequently be easy, not puzzling.

My approach is like that. You make a picture (it can be a simple sketch or a life-like oil painting, depending on the need) and you use the picture to decide what pieces you need. Whenever someone needs to know the context of any particular piece, they hold it up against the picture. End of analogy.

Here is my approach, in brief:
<collaborate>

  1. Consider each atomic task in a business process model draft as a candidate for a user story. This won’t always be the cause, as some tasks can be grouped into a single user story:
    • The label of the lane in which the task appears often (not always, sometimes the task beneficiary is not the task performer) gives you the “As a…” clause.
    • The label of the task becomes the “I need” statement.
    • The business value that you documented as meta-information about the task (I hope you did that) becomes the “So that…” statement.
  2. Based on how the process flows within your model, draft test scenarios:
    • Your test scenario will cover several atomic tasks and so several user stories.
    • Use a phrase such as “Verify that…” for each test point in your scenario.
  3. Draft the training material (if you’re required to do so).
  4. Amend the process model if the test scenarios and training material reveal flaws.
  5. Each “Verify that…” phrase becomes a candidate acceptance criterion in your candidate user story.
  6. Iterate.

</ collaborate>

A certain amount of this work needs to be done before any software development project starts, otherwise you have no initial Product Backlog. You don’t wait until the models, scenarios and user stories are perfect and complete because they are never perfect and complete. However, you need to get them to a state where they are good enough to act as a foundation for the current project and as a baseline for future enhancements.

Anyway, that is my method. It is not the method but it works for me and it is certainly better than no method.

Do you have another method that works?

Kind regards,

Declan Chellar

The copyright of this blog post belongs to me, Declan Chellar, you may not reproduce any part of it without my written permission.

 

Twitter

Visit Us
LinkedIn

Follow by Email
RSS

Pega Case Life Cycle Model – Part 3

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:

Twitter

Visit Us
LinkedIn

Follow by Email
RSS

Sizing process complexity

A lot of people think the complexity of a process is about the number of stages and steps it has but it’s not.

I have often seen BAs do an initial analysis of a business process by producing a diagram like this:

This is fine, as long as you have already established the scope of the process (see the end of this post for a link to a tutorial on that) and you are planning to elaborate the process beyond this simplistic diagram. Unfortunately, I have been on projects where the BA thought that was enough. A poor way to understand the complexity is simply to count up the number of stages and steps. However, a process is more than a count of its steps. The real complexity from a software implementation point of view lies primarily in two things:

  • The decision points throughout the process
  • The points where any software you are going to build will need to interface with other software systems

Any other steps are going to be about gathering data either to make decisions during the process you are modelling or to send to other processes or display data to the user.

I won’t go into interfaces because they are for the technical solutions architect to explore (although the BA may be involved in identifying those interface points). In any case, if your process model is technology-agnostic, then interfaces will not be relevant yet.

The significance of decision points is often overlooked, however, largely due to a lack of awareness of the power of decision modelling. Most BAs I’ve met still think in terms of business rules, instead of decision logic. Moreover, they often start thinking about business rules too late. As soon as you have defined the scope of the business process, you should ask the business what key decisions need to be made within each process stage. At this point, the order of them is not important. It’s unlikely the business will be able to remember every step that needs to be performed in the process but it is quite likely they will remember the important decisions that need to be made.

You need to understand two things about a business decision at this stage in your analysis:

  • Roughly how many outcomes it can have
  • Roughly how many data items are needed as inputs

This information is enough to be able to ‘t-shirt size’ those decisions. I don’t have a formula for calculating the complexity of a business decision based on those two pieces of information but I’m sure you can see that a decision that can produce two possible outputs based on three inputs will be a lot simpler to analyse, model, test and implement that one that can produce five possible outputs based on 300 separate input data.

The technical solutions architect will size any interface points and you can produce something like this:

In this example, the zeroes represent steps that just gather or present data, while the ambers and blues represent decision points and interface points.

When asking the business to identify the decisions they have to make, help them identify hidden decisions, i.e., ones that they are so used to making that they don’t give them much thought. Examples could be: duplicate checks, whether to send an email, how to determine what data to put in that email, data validation logic, etc. In a loan application process, don’t assume that the only decision being made is whether to approve the loan.

Taking a decision-focused view of the business process will reveal the true sophistication of the process.

Kind regards.

Declan Chellar

Related posts:

Twitter

Visit Us
LinkedIn

Follow by Email
RSS

Pega Case Life Cycle Model – Part 2

In Part 1, we went through some of the key terms Pega terms in Case Life Cycle modelling. Here, in Part 2, we’ll compare modelling a Case life cycle using Pega 7’s modelling tool with BPMN 2.0.

The life cycle view of a Case in Pega 7 is similar to the Discovery Map in Pega 6.

Case lifecycle example in Pega 7

However, other than the sequence of the three primary stages, it is not possible to show the flow of the life cycle in Pega 7. If you are using it as a high-level technical solution design tool, that’s fine, but it conceals too much of the process flow to be useful in gaining (and displaying) an initial understanding of the business process. As an analysis tool, it has the same weaknesses as its predecessor, the Discovery Map. In this model, it’s not explicit that ‘Review Claim (2)’ is actually an alternate path. Moreover, while you can see that ‘Approval Rejection’ is an alternate stage, you cannot see where it branches from the primary.

Using BPMN, however, you can see at a glance the high-level view of the entire life cycle, what the key stages are, what the primary path is (which I have marked in blue below), what roles are involved, what the alternate activities are (in grey) and what the business exceptions are (in pink) and then drill down into the sub-process according to your audience.

The high level view of the 'Manage Expense Claim' process in BPMN.

Even with this high-level overview of the business process, you can start to build test scenarios to make sure the process works at a business level before implementing anything in Pega. I’m a big fan of testing the business logic before you implement, so that when you test the software, you are testing only that the software works and not that the business logic makes sense.

Notice that I have re-used the sub-process “Review Expense claim”. Any differences can be handled by alternate paths in the child diagram or in the logic of any decision points in the child diagram. In the Case Life Cycle Model, such re-use is not obvious, nor even suggested. The fact that “Review Claim (1)” and “Review Claim (2)” are labelled differently means they are different processes in Pega.

In Pega 7, you can model the flow of a particular path through a particular Stage (remember, this is what Pega calls a ‘process’). Take the ‘Review Claim (1)’ process from the Pega life cycle model above, for example:

Pega Flow Rule

Here is the corresponding diagram for the ‘Review Expense Claim’ sub-process in BPMN:

Review Expense Claim sub-process in BPMN.

I’m sure you can see that if you gave that diagram to Pega developers instead of a textual use case, they would find it much easier to understand what flow to build.

This sub-process diagram covers both Pega processes “Review Claim (1)” and “Review Claim (2)”. How? By handling the difference inside the decision logic for the task “Determine Further Review Required”. In essence, one of the factors taken into account by the logic is the user’s business role; if it is “Director”, then a further review is not required.

Note: in Pega flows, the diamond shape represents a Decision Rule that holds the implementation of the decision logic. In BPMN, the diamond shape (called a ‘gateway’) simply interrogates the outcome of the decision logic, while a model of the logic itself sits in a Decision Model behind the corresponding ‘business rule’ task (in this case, ‘Determine Further Review Required’).

Here’s an important point for traceability: I would add a Specification in Pega of type User Story to represent any atomic tasks in the BPMN model. In the case of ‘Determine Further Review Required’ the actual business logic I would model and test in a Decision Model of the same name. The logic (business rules) in the Decision Model would essentially be the requirements. Neither a Process Model nor a Pega Specification is an appropriate mechanism for modelling business logic. Any Decision Rules in Pega could be traced back to the Decision Model via the relevant Specification and the ‘Determine Further Review Required’ activity in the Process Model.

I hope you have found this post useful. Thanks for taking the time to read it. For bonus points, have another look at the second BPMN diagram above (click here if you don’t want to scroll back up) and tell me:

  • Why I assigned the Business Rule type to the task ‘Determine Further Review Required’
  • Why I assigned the Service type instead of the Send type to the ‘Notify Employee’ tasks

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.

Kind regards.

Declan Chellar

Related posts:

Twitter

Visit Us
LinkedIn

Follow by Email
RSS

What is a Business Architect?

Some years ago, I was asked: ‘What is the difference between a Business Analyst and a Business Architect?’

My reply was that a Business Architect was someone who can apply the techniques of business analysis to an architectural framework in a technology-agnostic way. There are other differences but that was what occurred to me at the time.

However, that led me to ask myself: ‘What is a Business Architect?’ I think there are two types, broadly speaking. One would be someone who can truly shape a business and decide, or at least advise, what its business model should be, what strategies it should put in place and what it needs to do to implement those strategies. I am not that type of business architect. That kind of strategic advisory role requires deep knowledge and insight into a particular business and a particular industry. However, the people with that knowledge often lack the formal language/framework to model their ideas. As the poet John Ciardi said: “The language of experience is not the language of classification” (which is why, on software development projects, simply writing requirements in business language so often leads to business people saying during UAT: “Yeah, but that’s not what we meant”).

My area of expertise is the language of classification, or, rather, languages because each modelling technique is a language of sorts with its own vocabulary, grammar and syntax. Modelling techniques also allow variations in method and style, which are effectively dialects. In other words, I am a technician, not a strategist. I am a ghost writer. I cannot tell you what your strategic goals should be but I can help you put structure on them to make them clear and unambiguous. I cannot tell you what your business model should be but I can help you describe it formally in the language of the Business Model Canvas. In asking you the kind of questions the rigour of the canvas demands, I can help you articulate things that are so normal to you that you wouldn’t otherwise have thought they needed to be articulated, or help you think of things you wouldn’t otherwise have thought of at all.

Business Architecture is typically defined as:

‘A blueprint of the enterprise that provides a common understanding of the
organization and is used to align strategic objectives and tactical demands.’
1

With that in mind, I would say the strategist provides the content of that blueprint, while the technician provides the form. Ideally, an organisation would have a Business Architect who is a combination of strategist and technician but a strategist would likely not have the time to gain experience in the detail of technical models of the 2nd row of the Zachman Framework. On the other hand, a technician would not likely have the time to gain the business experience. However, their experience and skill sets are complementary. In fact, my view is that the 1st row of the Zachman Framework is where the two types of Business Architect mostly collaborate.

If I were to be precise, and those who have worked with me know that is one of my strengths, I would label myself a “Business Architecture Analyst” in that I analyse the architecture of a business, rather than the business itself.

Well, I’m glad I cleared that up.

What are your thoughts?

Kind regards.

Declan Chellar

Twitter

Visit Us
LinkedIn

Follow by Email
RSS