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.
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.
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.
In this week’s Process Session, we talk about the importance of selling your process model benefits using best practice marketing tactics and approaches. The transcript below has been lightly edited.
Sandeep: Selling the benefits of process modeling is difficult. In fact it’s one of the hardest things that any process modeling project undergoes. A lot of traditional ways of selling process models have been questioned before and some of them have not worked. Others may have but what we’re offering today is a fresh new way to look at how process models have been sold. More importantly the benefits of these process models.
I’d like to introduce you to Daniel Weatherhead who’s our marketing manager in Leonardo Consulting. He is here today to answer some of our questions and provide some guidelines on how process modeling or models can benefit from a marketing perspective.
Welcome to the show Daniel.
Daniel: Thanks Sandeep. It’s great to be here today.
Sandeep: So before we get into actually answering the question of how process modeling can leverage marketing, let’s get some of the basics correct first. So Dan in your point of view, what are some of the basic techniques the world of marketing can inform and can educate the people in the modeling world?
Daniel: What we’re talking about is a shift - a shift away from what we would call the old outbound marketing tactics. These are the tactics of the previous generation - the generation before. Interruptive tactics that don’t necessarily look to inform and educate but were very much placed there interruptively into people’s lives. Now think about your television ads, your radio ads, your newspaper, advertisements. These are the sort of things that shout at you. They are one-way traffic. People didn’t necessarily go seeking those messages.
Inbound marketing seeks to be different. It's where the actual audience, the reader, the customer is active in the way that they go out and source information. We as marketers or marketing communication professionals are looking to not just push a message but mostly to offer value. So we’re looking to educate and position our products and services, or the things that we specialize in – in an education realm – so we’re offering true value to the person who is on the other end. That might be the form of a blog or a video (like what we’re doing right now) or a downloadable discussion paper, podcast or some sort of a template.
Though that conversation where we’re positioning the person, business or the product as a thought leader in the space - as someone who can be trusted and relied upon. We’re not just trying to interrupt them and sell, sell, sell. More importantly is that activity needs to be follow-up actionable. With the bit of content – the market activity needs to be actionable. It can’t just be something that sits out there and doesn’t have an endpoint or followup.
So if someone reads a blog, if someone watches a video, there needs to be a clear ‘go and do this’ at the end of it.
We start to use other communication platforms like social media, targeted timely email campaigns to push those messages and push those pieces of educational content of value to the customers at the right time.
Sandeep: I think it’s interesting that you bring up inbound as opposed to the traditional ways of putting it in your face messaging, because I think in a lot of process models tend to or at least professionals in the process model industry tend to want to put models in the face of people so that they can so that they’ll think about them each time they need them.
I also like what you’re saying in a different way to approach the same problem is to draw them in, offer the value, get them excited about process models and the benefits of the process models. So bring them in as opposed to pushing it out forward.
On that note, would you offer some techniques - some specific technical steps that people listening in can follow in order to make sure that the, the benefits of process models are realized, by the audience, by the correct audience and they’re excited about having process models which as we know are valuable elements of any organization to understand the tendencies, relationships. How do we get them excited about this?
Daniel: I suppose if you strip back and you use some of those marketing tactics that marketers tend to use - it is very much knowing what you’re selling.
What actually are you selling? That’s not something that necessarily is difficult for people – most people have a good understanding of what it is that they’re doing -whether it selling be a toothbrush or an iPhone or a pair of headphones. They have an understanding about some of those key needs of the customer - but where the seams come apart in that process is that you start to not understand who we’re selling to.
Generally we talk about these big segment audiences as our target market. It might be a demographic. It might be a geographical spread about who we’re targeting. Inbound marketing looks at a much narrower focus or narrow target. We call that a persona. You might be familiar with persona. Persona is where you actually build up a profile of a target buyer. Rather than just getting small demographics, we start to think about what are the targets pain points in this area. What drives them in terms of their business? What are their challenges? How can we answer those challenges? What are the questions that they have?
What are the communication channels of this person may or may not focus on? What does their day look like? What are they do on the way to work? Do they have other pressures they bring in to their workplace? We all have other pressures we bring in to our workday - so let’s actually address those in the messaging that we do. So as we build up this persona of what this person looks like, we’re then able to execute marketing tactics accordingly.
I use ‘marketing’ in inverted commas because these tactics aren’t just in the realm of marketing. They just happen to be lumped in with us sometimes - but we can then leverage a whole range of tactics to suit that persona.
It might be the sort of information that we’re writing for them; it might be the video that we’re creating for them; it might be the sort of language we use and the way that we construct a blog post or it might be even the platform we use to reach that person. I suppose that that’s when we start to talk about communication channels.
Social media is just another form of communication. So if we think about things like emails and digital communication platforms, social media is just another way to do that - to reach people. But obviously we’ve got some of those personas to address.
How do we use social media blend to communicate accordingly those specific messages with those specific people. We might target them on Twitter or we might target them on LinkedIn. We might be using some of your internal social media channels. How do we start to engage people in a way that enables that informal conversation? We call it the 'digital watercooler' - where they might be able to share work in an open way for your team to start engaging where they may not normally. There’s a whole form of those internal platforms where people are allowed to informally communicate and chat and start to share ideas.
The whole idea is that as they share those ideas your team they will become more confident in the way that they build process models, build collaboration, build an understanding about what each other is doing in the business.
What we’re seeingis that an understanding of that persona now reaching out to a desired outcome in terms of the way they communicate and collaborating using some of those newer social media or newer communication platforms.
Sandeep: So I really like the idea of a persona and actually understanding your audience. I know that there’s tons of the internet about how to create personas and all this. So we won’t go into that in this session but certainly understanding your audience helps a lot and love the fact that there is a digital watercooler. I can just imagine that as, as you said it and input the process modeling world, the digital model cooler will actually make a lot of sense, to have a place where people can collaborate and really exploring the communication channels in which collaboration can be enabled. You talked about social media. I think that is absolutely crucial especially with the workforce that we are seeing these days.
There are so many social channels that you can explore doing that. My mom has about 11 ways to contact me - so you know, there is all of that and the organizations that I’ve been involved in especially I have seen at least 1 form of internal social collaboration point.
I think process modelers can actually leverage a lot of that and create their own digital water cooler to enable that collaboration.
So when, when I listen to all of this, I’m actually quite intrigued about what can do and how we can apply a lot of these techniques and a lot of these tactics that you speak about there. Do we wait until we’re done with process models to get excited about this -at what point in our journey should we be thinking about marketing our process models?
Daniel: As the marketer in the room I’m going to say you should be thinking about that yesterday. You should be starting right from the outset. From my perspective the reason why that should happen right from the start is because as we go about building those process models or as we go through that project and then we get to the point of starting to sell those models more broadly in the business, to have them used and useful - if we’re able to point to places on the project - even for people who are participating in the project - they can go and see where this collaboration is happening.
The great thing about social media channels most of them but they’re pretty open. They’re transparent. By building that internal transparency we’re able to see the communications that’s happening
If someone else has got the same sort of questions, they can see the exchange that is happening. We see that online every single day in the billions of forum post that go online that show us all collectively learning from each other’s questions and answers. If we can enable that within our own project and when we say enable that, we really to actually want to build those communication platforms. We want to encourage our teams to be using those.
We should be taking away that informal layer of composing a composed post and putting it out there - we want this to be a conversation - and so that’s where those Twitter like streams or Facebook like stream or, or slack like messaging apps; that’s where those tools encourage that informal conversation that go back and forth.
That again is visible and transparent by the person at the top. That needs to happen now. That needs to happen right at the start- not at the end, because then we’re starting to look back and say “Why was that conversation captured at the start?” We want to have these things captured from the start and have those strategic conversations now.
Sandeep: So it’s really common for a lot of projects especially for modeling projects to kind of leave it until the end. And I can see the, the benefit of actually starting way up ahead sooner rather than later because then you create that buzz. And not only do you create that buzz and awareness, what I’m also hearing from you is you’re creating an inclusive environment where people who are involved in projects like that can, can actually contribute to the project.
I think that that’s very valuable and, and immediately I can see some benefits - I’ll be excited if I was involved in a project way up ahead and people asking me for my input and I had some influence in the way things went.
I agree that the best time to start would be as soon as possible or at the start of the project. So, at that start of the project, would I as a process modeling professional bring along someone like yourself to be part of the team so a marketing professional, a marketing guru - someone who’s an expert in this field to come along and join me on the journey?
Daniel: Yes – as I said before, having someone who’s a communication professional involved - whether that be someone who’s a marketing person with a capital M or someone who is just engaged in leading communications for the project – who is able to point to people and say - “We need to be looking over the horizon - not just at the project we’re having to do right now but actually what’s it going to look like when we deliver this.”
Starting to think about the key personas that we’re going to have to address in the business is to get them engaged and excited. To have that person who can tie that all together, who is not necessarily doing the day to day modeling – for me that is crucial.
The job of that person that ties together all those strands, to actually help position, to help the modeler who has the expertise but maybe doesn’t maybe have the knowledge to tie that to a persona, and to tie that to an outcome, to tie that to a particular tactic - that’s where I see the role of the marketer to help in those situations.
The modeler is there just trying to do the work that he or she is trying to do - getting into thinking strategically - not just about the work they’re doing today - but what they’re doing now and how it’s going to impact someone when the modeler’s delivered of being used - that’s very, very difficult.
Having someone who’s the professional -who can create that strategic goal of what’s going to be delivered and what’s the benefit, as well as starting to that point to and create that timely bits of communication - whether that be social media or otherwise –within the organization to address those personas that have been agreed to by that team. That person is crucial for me to help build that engagement; the current engagement; the future engagement and also that excitement of delivering that unsexy model to the business.
Sandeep: So I think that, that, that there’s a lot of good insight here. I feel like world of marketing and the world of process modeling need to collaborate to in order to achieve success for any kind of process modeling project, any kind of process modeling endeavor and most importantly the process modeling journey as obviously as we all know we don’t stop at a single process, we keep going. So the ways that I can see, a lot of the principles of marketing being employed in the process modeling is more about the inbound - rather than putting it out into people’s faces - then I can also see some of the key techniques by creating the digital watercooler. I love that term.
Using personas and social media as a way to interact and understand your audience, - start at the at the word go - don’t wait until it’s too late. Don’t wait until the end of the project and involve the professionals like the marketing managers of the world. Every organization, every large organization at least should have access to a marketing professional. So involve them in the project as soon as you possibly can. I think some great insights come out of this discussion. So thank you very much for your time Daniel. and I really appreciate those insights you’ve given us.
Daniel: Great chatting and all the best on your modeling journey everyone.
Sandeep: All right. Now worries at all - so if you like this video click on the like button. , be sure to connect with us, Daniel and myself on LinkedIn and follow us on Twitter – and we’ll see you next time.
Have you been asked to do a process model and you just don't know the amount of detail that you need to do a successful process model? The level of granularity that you have in your process model will determine how useful it will be.
Any process model that you create has to stop somewhere.
Now I'm not just talking about the left and right limits of that process. That's important but I'm talking about the level of detail that you place into that process. It is very tempting for us as process professionals to go in and have a look at all of the detailed processes and model those out because that's the stuff that's easy to obtain. Either by watching somebody do it or by looking up existing documentation. But when do you know it's time to stop? Well that's just as critical.
The depth of process modeling is determined by the highest level to the lowest level of modeling. The highest level being the abstract level and the lowest level being the tactical level.
So in other words, from the abstract to the tactical, you need to make some leaps and bounds about how much granularity there is. Determining this granularity and keeping it consistent will ensure that process models created across your organization are consistent with your thinking. They're consistent to provide value to the organization and consistent for any end user consuming these process models to know what to expect. The key to ensuring the right level of granularity is, revisit your purposeful modeling. The purpose of modeling defines how much detail you require in these process models. More importantly, if you're going to use these process models for say communication then you need to ensure you're capturing the what of any kind of process.
An example could be clearing of a purchase order. The ‘what’ is, well, clearing up the purchase order. The ‘how’ is the detailed steps of where to click, the five to seven or so clicks on the application that determine the successful clearance of a purchase order.
So when you're process modeling all these tiers you need to be aware of which tier you're going to use for the right purpose.
Communication tiers are usually higher and of course tactical or more detailed information is usually at the lower tiers. Once you determine the kind of granularity you require based on your purpose of modeling, you are then able to extend that onto your conventions and standards and ensure that it remains as part of the way you work going forward.
So don't forget that each time you process model, it's tempting to stay at the lower levels but you need to bring yourself up to the abstract level and work your way down. The top down approach will ensure that the depth of modeling is consistent throughout the effort of process modeling in your organization. Now I'm not saying that every single process model needs to be the same amount of granularity. It depends on the purpose. The purpose highly determines how much information you put in each process model. The higher the level, the less information and of course the lower the level, the more detail that you want to put in there.
But ensure that you know you have an end game in mind. This kind of thinking of the detail helps you identify when to stop modeling and always approach from a top down -from an abstract to a tactical level.