<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">

Sandeep Johal

Find me on:

Recent Posts

A BPM Success Story with Nuno Serra

Sandeep Johal Sandeep Johal on October 18, 2016

BPM is a journey that a lot of us aspire to take. It is one that we're convinced brings about value. But is that the case really? There are so many instances where we get asked at conferences and at our client's about the actual benefits of BPM.

How many BPM success stories actually delve into practical BPM actions that you and I can implement tomorrow and get immediate benefits out of? Sure we talk about transformation, but it's all about showing a successful journey and successful steps in that journey as we move forward.

Nuno Serra from UniPartner talks in this chat about his successful journey in a specific BPM project. 

Sandeep Johal: Nuno is a very well-known consultant in BPM and has much experience in improvement, transformation work for over two decades. Thanks for chatting Nuno.

Nuno Serra: It's my pleasure to be here and to share with you one of the projects we have done here in Portugal which I believe it's somewhat of a unique project and different from the others that we typically do.

Sandeep: Nuno, tell us a little bit more about what this project was trying to achieve.

Nuno:  This initiative started as a project of the Portuguese National Archives and the main goal was to build process catalog to support interoperability between government agencies. By doing this they were changing the way they fund their activities. Traditionally they used an organizational and a thematic approach by separating what ministry X or Ministry Y did instead of looking at the purpose and the function that they all prefer. This would lead to creating a common understanding, a common language that could be used as a semantic instrument to connect all the ministries.

Sandeep: We find that connecting people is exactly what BPM does best. What was it that the goal of this project was when you embarked on it?

Nuno: Firstly we had to identify and elicit all the government business processes. We had to do this in a way that could cover all the ministries of the central government. Also we would have to achieve a common understanding, so we had to look into the businesses in a way that everyone could agree upon. 

Sandeep: Not an easy task at all I can see Nuno. What is it that you can share with us in terms of the actual positives and impact that your process or your project made on this particular initiative?

The first goal was to have organizations collaborating in the project. They had the opportunity to join or not to join the project at that stage, so we had to convince. We were able to convince 130 different organizations to join the project and participate. Also we had a timeline to do this. We had three months to build a a pilot, and then we had eight months to reach the other organizations. The pilot we did with 25 organizations of the Ministry of Culture, and the other eight months we were able to replicate the process we tested with the Ministry of Culture with all the other ministries. We did that by implementing well-defined cycles, and we had five different cycles with different work groups organized of course functionally according to the business functions. The result was the identification of over 1200 business processes, and we were able to do that by talking with 700 participants. This bottom-up approach was key to reaching consensus about the output, the process catalog.

Also we had to do at the same time a top-down approach to build the macro-structure where the processes fit in. We had to identify the government business functions, currently they are 19, and we had to divide those functions into sub-functions. Then at the third level we had the processes. It was very important to combine these two approaches, the top-down and the bottom-up approach.

Sandeep: Sounds like a huge undertaking, and I'm impressed at how much you've actually achieved. Getting consensus in the government is one challenge that most of us only hope to be able to overcome. That was just one challenge, what about some of the other challenges that you faced Nuno while you were doing this project?

Nuno: By combining the top-down and the bottom-up approach, we had to reach different people within the organizations. We had to find the people that had the overall view of the business, and we also had to reach the people that have a deep understanding of each business process. It was very challenging to communicate to the organization what kind of contributions we were looking for so that they could indicate the right people for each work session. Secondly, well, the ministry that was leading the project disappeared. We had elections, there was a change in government, and in the middle of the process we had to resell the project to the new leadership.

In the context of changing parties in the government and changing the government structure, we had to explain that, what we were doing. First, the functional approach would make the outcome independent of the government organization because if we are targeting what the government does, it doesn't matter how the government is organized. That was the key selling point in this change. Also the large participation base, we had only two and a half people working in the project so it was not visible to keep personal communication with 700 participants. For that, we implemented a portal to convey all communication electronically and to make all the information that we gathered available to all participants regardless of the organization they belong to or the function they work on.

Finally, but not less important, we had to start agreeing on definitions. There is not a clear definition, a common one at least, of what a business process is, where it starts, where it ends. We had to do that in order to have the processes in the catalog defined under the same rules. It was also key to achieving the longevity of these instruments. 

Sandeep: BPM is definitely the way to go. We have seen some benefits come out of that, and we have seen some big benefits come out of consistency and having a central place to go to find information. That in its own right is already a big benefit that any organization with different opinions, definitions of stuff can read from. What I'd like to know is, now that we've inspired a few people to think there's still hope in the BPM journey, what other kind of advise can you provide for those who are embarking on a BPM journey? Give them words of encouragement, what would you say?

Nuno: First of all, it's critical to involve the people that work on the processes day by day. We did that in a large-scale elicitation project, and we should do that also in smaller-scale organizational level projects. Also we need to look both at the business view and the IT view, because most of the optimizations that come from these projects rely on new applications and technology, so it's critical to align the business view with the IT view and how the new business processes will be supported by applications and technology. By the end of the day, we have to do a value and even in projects that aim to create a common understanding, common instruments, a common catalog, we need to establish clear goals on how to implement and what to achieve by implementing the common instruments. Of course by having a common process catalog, we are able to digitalize processes and share those common processes between different organizations. We use a lot of the information we produce, and we can provide that as the best practice to implement that process.

Also we can look at the value of information that is produced during the execution of the business process. When we look at the archives, usually we find lots of information that no longer has value, and we keep assigning resources to store and to manage that non-valuable information. By assigning a business value to the information that is generated by each business process, we are able to more efficiently manage a lot of our archives, we can reduce cost, and we can focus the resources we have in the most valuable information. Those were the main goals for implementing such shared common instruments.

Sandeep: Wise words there from Nuno. Thank you very much for joining us, I hope our viewers did get some inspirational words and words of comfort knowing that the BPM journey can be yours, successful one and as practical applications for us. Thank you very much for joining us Nuno. 

New Call-to-action

Topics: BPM - Business Process Management

BPMN Myths Debunked with Stephen White

Sandeep Johal Sandeep Johal on October 10, 2016

In this interview with Stephen White, who was closely involved in the developed of the BPMN language, we discussed the myths that been swirling around the internet about BPMN. More specifically, we talk about some crowd-sourced myths and weaknesses that people had been discussing on the BPMN wikipedia page.

Sandeep Johal: The first myth is that there is ambiguity and confusion in sharing BPMN models.

Stephen White: To me this more of a tool vendor issue, perhaps. A lot of it just had to do with mobility or quality of the import export capabilities of the tool. I've soon tools that are very good at it, and other tools that are not as good at it. When you share a BPMN model, you might have issues importing it into a different tool. You might have to do some work after that, but I think that is a vendor issue. The specification itself gives the XML schema or metamodel  behind it so that tools can do that.

There were a couple of minor issues and I think that OMG has been addressing that. There's a committee that does interchange formats, and they've been working on that, and showing demonstrations at conferences. I think any of the technical issues are being solved, and I think it's mainly up to the tool vendors to support that .

Sandeep: Next myth ... That BPMN does not allow for routine work.

Stephen: Don't really understand this at all. I think that's kind of what one of it's main capabilities is ... is to be able to create simple straight through processes, a series of activities. We got ways of doing looping based on data or based on a list of items. Like if you have an invoice and you have a bunch of items in that, you can do a loop that supports or that manages all the different items on the list. I think BPMN does this very well and kind of what it was designed for.

Sandeep: Next myth ... BPMN does not support knowledge work.

Stephen: It does support some knowledge working capability. Our case management processes are unstructured. When BPMN was created back in the early 2000s, those kind of unstructured processes were out in the business world. We knew about them, but weren't able to get in all the things that we needed to do to support that. We created a subprocess called an ad hoc process where you could do the activities in any order that you want, and create a condition to say when you're done. This was kind of a step in that direction, but it wasn't complete. In version 2, we didn't add enough to it at that point.

In the meantime, OMG also created another standard called case management model and notation, CMMN, to kind of fill in the gaps there. Unfortunately, it's a separate spec so if you want to do unstructured processes, you go to CMMN. If you want to do the structured ones plus maybe a little bit of unstructured, you go to BPMN. I think this in the long run could be addressed by BPMN 3.0 where we can consolidate that. We can use one tool, one model, to create all the variations of business processes. 

Sandeep: Converting BPMN models to executable environments is impossible.

Stephen: I don't see that at all. I think that's really up to business process management tool. There are tools out there that do this. You can go into a BPMN tool, import a business BPMN model, and then create, make it executable. You can do that now. They're lots of tools that do that. It's really handled by the BPMN tool. I worked at IBM. They do that. Other tools do that, so I think this myth should be busted.

Sandeep: There is no support for business rules.

Stephen: First off, BPMN isn't intended to do business rule or decision modeling. It's intended to do business process modeling as we discussed. It does provide hooks into these other tools or other models. For example, there's a task in BPMN called a business rule task. It specifically was added so that BPMN tool could use that task to interact with a decision engine or business rule engine, come back results, and get it back to the process. BPMN has the technical capabilities to support it, but it wasn't intended to do that kind of modeling.

Sandeep: BPMN is way too complicated.

Stephen: This is kinda been a long standing complaint. It was there even before we finished the first specification. I kind of get the complaint. When we started building BPMN, we were intending it to be for business people. It had to be simple enough for business people to do and understand. We didn't want it to be very technical looking. It had to be graphical, etc. It had to be simple, but all the people in the room would have had years of experience with actual business processes. We had been consultants. We had trained people. 

We had understood what the issues are for our business people out in the world, and real business processes are complicated. If you look at one company, they need a special kind of loop. You go to another company, they need a transaction or something. You go to another company, they have some other requirement. We add those things up, there's a lot a little details that have to be added to the business process. Real business processes are complex, so it has to be complicated but it has to be simple at the same time.

We knew this going in, and so we came up with an approach to try to deal with that. That approach was to build some simple building blocks. For example, we have 3 main objects. We have circles for events, rectangles for activities, and diamonds for gateways. Those are the basic elements, so there's 3 things. You can see them. They look very easy. You can create models with them, and you have that simplicity. To add the complexity, you can add then variations of those things. You can add different types of tasks, different types of gateways.

There we add the different markers to tell people what is this particular type of task, what is this for,  what do those behaviors mean. With the basic building blocks, you can build up the complexity within the simple structure. That was the intent, and that was the approach we took. I guess it's up to individual people to decide whether we were successful in that approach.

Sandeep: Finally, last question is what about BPMN 3.0? Do you know anything about it?

Stephen: At this point, I don't think there's any major effort in OMG  to do 3.0. I would like to see it done eventually, and I think it will be. To be honest, for tool vendors to add a new support to new standards, it is a lot of work. The vendors out there that created version 2 kind of want the stability in the marketplace for awhile. You want to be able to build up the customers they have, and they also want to gather more requirements over the time. We'll know more about what is needed for a version 3. A couple of the things that we mentioned earlier, certainly we need a beefed up support for case management or unstructured type processes.

We could add lower level processes at doing service level modeling. Those are the model inside of a tasks. How do you implement those kind of things? There are things at both high and low levels that could be added to BPMN in version 3. Unfortunately, I don't know exactly when that'd happen. When it does, I certainly would like to be involved.

Watch Process Modeling Excellence Video Seminar - 45 minutes! 

Topics: BPM/EA Technology, The Process Session

The Origins of BPMN: Interview with Stephen White

Sandeep Johal Sandeep Johal on October 7, 2016

BPMN is a well-known modeling notation. It stands for Business Process Model and Notation. Much has been discussion about this notation, however many people aren't aware of how to use this notation, and more importantly, when to use this notation. In this chat we talk to Stephen White who was involved in development of this modeling language.

Sandeep Johal: Stephen is a clear master in this field, because he was involved in the team that developed BPMN.  Steve, let's start with the first question that's on my mind at least.

Can you tell us a little bit more about what BPMN is?

Stephen White: Okay, sure. BPMN defines how a specialized type of flow chart can be used to represent business processes, and as you mentioned, it's a model and notation, so it does define the graphical elements, the shapes and the markers of those elements, and it is a model since it explicitly defines the behaviors of those elements, the semantics of them, how they relate to each other, so that you could simulate or even execute or automate those business processes.

Sandeep: Great. That's good to know that it is a way to represent business processes. The question is, why does it exist in the form that it does?

Stephen: Okay. Well, it started back with an organization called Business Process Management Institute or BPMI, which formed in late 2000, and they were developing an XML execution language, a very technical process execution language, and they wanted to have a graphical notation as a front-end, and at the time, there were also competing notations and tools in the marketplace. There was a lot of them, too many. But many of those tool vendors actually got together with BPMI or in BPMI and they had to develop their own notations, so it had a lot of skin in the game, and they were involved in creating BPMN. They saw a need to create a common standard. I think the last time, we talked about what are the benefits of a common standard and these vendors, there was 25-30 of them at the time, saw that need. 

Sandeep: Steve, I understand that you were involved very heavily in the BPMN development journey. Would you care to share some of your experiences of being involved in such a phenomenal initiative? 

Stephen: I attended the early BPMI meeting in 2001 and volunteered to chair the notation working group when that was formed. I was fortunate that my company at the time, SeeBeyond and also later at IBM, allowed me to spend a lot of time on BPMN. I was the chair of the working group, was able to set the agenda, create the by-laws, set up all the different options for the notations that we were working on. We would discuss them and vote on them and so forth.

Actually, I found that even though we had 25 or 30 competing companies involved in this group, we were actually a very good group to work with. I was very pleased that we didn't have any major conflicts. We were all very polite and there was no issues. It was a very pleasant process, surprisingly. You would think there would be a lot more drama involved at that time but, there wasn't. It was a good experience.

We continued working on that. I ended up writing the majority of that first BPMN 1.0 specification. After a couple years, BPMN started gaining some momentum. A lot of tool vendors were supporting it at the time and eventually, BPMI merged in with the OMG, which was a larger standards organization. It had, itself, created its own process standards. Most notable was the UML activity diagram. When BPMI and BPMN came into the OMG, there was a little bit of issues there, little territorial spats. There was no major drama but there was an issue there because there were multiple competing standards there within the same organization. But, I think BPMN's success in the marketplace had helped win people over [inaudible 00:05:16]. They couldn't not support it because it was so successful, partly. The OMG did officially approve the standard and then began work on version two. Version two also included some of the larger companies which weren't involved earlier, like IBM, [inaudible 00:05:38], SMP. Given that kind of support, it even gained more momentum in the marketplace.

I continued work on that. Did a lot of the writing of that BPMN 2.0 specification and overall, that was a good experience. We finished that specification probably in 2011.

Sandeep: Could you maybe give us some thoughts on what type of scenarios you would use or most appropriate for the use of BPMN?

Stephen: Okay. In some sense, I'd like to caution more on this topic because I think my experience, people tend to think of BPMN as being business process management. Business process management, BPM, even though it has business process in the name, is a lot more than process. If you look at business process management, you have strategy, you have data, you have organization aspects, you have business roles, you have services, you have risks and policies and functions and so forth; process being one part of that. It's a key part but, it's just one part. I would caution people not to over think about what BPMN can do. It was designed to specifically deal with process and basically only process. It is not a data model. You can use your own data model and hook into BPMN. It's not a business role model, etc. It is if you need to do business processes, you would use BPMN as part of a larger BPM solution.

Sandeep: Obviously that begs the question of when not to use BPMN. Any thoughts on that?

Stephen: There are some specialized versions of business processes that BPMN doesn't cover at this point. If you're looking at a very low level model of how services interact, for example, when you're implementing a business process, BPMN doesn't really cover that natively yet, or very unstructured case management processes. It covers it a bit but probably not enough. I think we can talk about that a little bit more, later on. There are some specialized aspects of business processes where there might be other tools or models out there that would do that.


Watch Process Modeling Excellence Video Seminar - 45 minutes! 

Topics: BPM - Business Process Management, Process Modelling

Process Modeling Notation with an Expert: Interview with Stephen White

Sandeep Johal Sandeep Johal on October 3, 2016

Business process modelling notation is something that has plagued many process modelers all around the world. One of the key things that gets asked is, "What sort of notation should any process model be using?" In this chat - Sandeep Johal talks to world-renowned expert and thought-leader in this space - Stephen White from BPM Advantage. Stephen led the initiative of the BPMN development. BPMN, as most of us know, stands for business process model and notation. 

Sandeep Johal: We've got many questions for you Steve. Many, many questions so let's get started right away. First let's dive in by just setting the stage. Tell us, in your own words, what process modelling notation is?

Stephen White: Basically it's a human readable language for defining the structure and contents of a process. In this case, in this context, we're talking about business processes. To emphasize, it is a language. That means it has a defined vocabulary and it's a semantics. As such, being a language, it allows an organization to use that language to tell the stories of the work that they do. For example, these stories could be about how the organization interacts with its customers or how it does its finances or how it works with its employees and human resources etc. This language allows them to create, define, in a reusable format, the work that they do. 

Sandeep: It's quite ... I get from what you're saying, process modelling notation is an important thing to have. Can you elaborate a little bit more of why it'll be important for all of us, in the modelling space, to consider and make sure that it is front and center? 

Stephen: Sure. It's important because it does provide a consistent way to capture the work. Beyond just having someone writing up an explanation or write a few paragraphs about what that is. The notation could be the front end of an underlying model. This model defines how the processes work. By creating a model, supported with the proper tool, an organization can understand, analyze, begin changing and even automate those processes. Like any other language, it does require some learning so people do need to learn the vocabulary and how that language works. 

Sandeep: It seems to me that themes such as consistency and having a modelling notation that allows a larger group of people to understand what's being said, it's crucial. I've talked about this on several of my own videos and what I don't cover is the types of notations there are out there. As I understand it, there is more than a handful. Could you tell us a little bit more about that?

Stephen: There's been many, many process notations out there over the years and there's many types of them. Some of them are, you could say, are textual so they are, like a programming language is a textual notation. Or they could be structured in rule format or tree structured and some of these might have icons to represent different ... The way the process behaves. More commonly though, they are graphical in that they are based on a flow chart. Not all of them but most of them are based on similar variations of flow charts. There's been many "standard" ones and I can just list off a few of them.

One could be the UML activity diagrams, event process chains which are EPCs, going way back to 1962, WFMC created XPDL and Government created standards like IDEF, IDEF3 and so forth. There was even one called YAWL, which is Y-A-W-L, which stands for Yet Another Workflow Language which was just to notate that there are plenty of them out there. There are lots of them. Those are the, what you would call, standard ones. There's lots of other ones, proprietary ones, created by tool vendors or by academics in universities who are studying business processes and wanted to create their own languages.

Sandeep: With so much choice out there Steve, I can probably guess what my next question's going to be, it's all about how does a modeler select which notation he or she should use in their process modelling effort?

Stephen: First off, I would say pick a standard. Don't necessarily pick one that someone has created and it's isolated in its own. Pick a standard because standards have usually an ecosystem around them. What I mean by that is there are tools that support that standard. There are resources, such as books, papers, training, available for people to understand that standard. There are people who have learned it. They've been trained on it and so there's consultants out there who understand it. With this ecosystem, an organization who is trying to make this decision knows that if they pick something that is supported out there then they save money on training.

They don't have to train everybody who comes in and works on it or retrain if they change the tool. Using a standard means that they are usually transportable between tools if you do change a tool so pick a standard. In my case, I'm biased of course, so I would pick the BPMN standard which was developed just for the purpose of creating basically an ecosystem for the end users. As background, BPMN was started mainly because there were so many standards or different notations out there, so many tools that were out there. 

There were too many and it was difficult for organizations to pick and choose what they wanted to do, to pick something that would last them and create internal information that they can reuse. When BPMN started, there were quite a few process modelling tool vendors who joined that effort. These were people who had created their own notations, but they saw that there was a need for a common language that a lot of tools can use, the community can support and people can get trained on.

That was the purpose of creating BPMN, to create a language that the industry could support. It's actually been very successful in that regard since there are more than eighty tools right now that support it. There are books about it, there are people training, training classes and so forth. It is probably the most widely used language. Given that, I would think that it would be a good choice. It wouldn't be a bad choice to pick BPMN.

Sandeep: There are many other notations out there that people can select. If I understand correctly, there are really three aspects that I picked up from what you've just said. They are just pick a standard based on the, first off, what are you trying to do. Ensure that it has wide tool support and finally it has a rich set of references such as training etc. 

Stephen: Yeah, that's basically it. Certainly you want the tools, you want the reference material and you want people who understand the language and the overall ecosystem that supports that. A lot of times, in my experience working with companies that have used non-standards or even some standards that aren't supported by tools, what they ended up getting is a large set of materials and they end up ... It becomes shelf wear. They print out all these documents, they put them on a shelf and then maybe they'll look at it at some point. It just becomes a lot of work to create a lot of material without much use in the future. That way using a model supported by a tool that has standard, then that way it becomes an electronic asset that is transportable, executable etc.

Sandeep: That helps most modelers make the decision as to what modelling tool or modelling notation rather to select. What we often get is this whole step into getting or just taking something on, not really thinking it through and then regretting it down the road. The number of times people have told me this issue, it makes me think that there should be a framework to help out. With these three factors that we mentioned which is pick a standard with a purpose, wide tool support and a rich set of references, I think our viewers can have a very ... Something they can hang onto, hold onto to provide some guidance as to which modelling notation to get.

If they do a comparison of several modelling notations, especially the ones that you mentioned before, and did that, honestly and perhaps a few stakeholders, I believe that there is a lot of value that they can bring into selecting the right notation. Speaking of actually references, what are your thoughts on where our viewers can get more information about modelling notation?

Stephen: Specifically focusing on BPMN, there is, if you want to know about that language, there's the BPMN specification which is a technical document of course. It does go into the details, what is the language, what is the vocabulary, what do the images look like, what do they mean so there is that. You can get that at the OMG website, will provide the link for that. There's other reference material there as well. You can buy books, amazon.com has books on BPMN. There are websites that have posters that define the elements of the language, what they look like, what they mean and so forth so as reference material. There are also online training courses, many courses out there to get trained and certified. I'm actually developing my own course, should be out in the very near future. There's lots of resources out there.

Sandeep: That's good to know that modelling notation is something that the larger community does take seriously, and has accordingly the right amount of information out there to check. In this case, particularity with BPMN, there seems to be a rich set of resources that our viewers can tap into. I think that is a great insight into process modelling notation, how to approach it and what it is and, most importantly, how to select the best kind of notation that fits a viewer's modelling purpose. With that, I'd like to thank you very much for your time Steve. It's been great having you on Process Sessions and we hope to see you again next time.

Stephen: Great Sandeep, thanks. I enjoyed it.

Enterprise Transformation EA 


Topics: BPM - Business Process Management, The Process Session

Are You a Process Preventer or Resolver?

Sandeep Johal Sandeep Johal on September 29, 2016

Chances are, if you're watching this video, either you or somebody you know, is in the profession of business process management, or BPM. Business process management professionals have a very unique role to play in any organization. They get to see across processes, across the organization - not just siloed departments. This view can bring so much value across the organization. Not to mention that a lot of BPM professionals are fairly smart. Having said all that, why aren't people in the whole entire organization just absolutely raging at their door, wanting them to work at every single project, every single piece of work?

BPM professionals have become ubiquitous in a lot of organizations, but they still suffer from the one challenge, which is, how can their services be continuously of value to an organization? People often question how their role brings in value. Business process management professionals have a unique point of view that stretches across the organization. All organizations tend to have some form of hierarchical structure, which business process management professionals transcend, and are able to give you the viewpoint from a process perspective. They live, they breathe, and they work the process.

Having such a unique point of view from the word go, makes BPM professionals very, very useful in any organization, but here's the thing. 

When you think about firefighters, versus those people who are employed to prevent fires, which one of those two roles do you think is more sexy?

I'm guessing most of us said, firefighters. That's true. I would say the same thing. Firefighters resolve, whereas, those people who prevent fires, those people who install the fire hydrants, the smoke detectors, the exit signs, those people are the preventers.

When you've got preventers and resolvers sitting side-by-side, the more sexy heroes are always going to be the resolvers.

This is true in an organization, as well. BPM professionals, we are the preventers. We don't get the limelight like the resolvers do. This is perfectly fine, because the objective of any BPM professional is to prevent issues from happening in the future. There may be issues that you resolve right now, but the intention of true process management is to resolve things that have yet to occur. We're the preventers of future problems.

If you know where you fall within that spectrum of preventer and resolver, you understand the kind of limelight the organization receives you from. If you want to be an effective BPM professional whose door is constantly knocked for help and for support, you need to be able to provide both things.

Be a preventer, and a resolver.

Download Object Oriented Process Modelling Repository

Topics: BPM - Business Process Management, The Process Session, Process Modelling