The Leonardo Blog

Hey everyone and welcome once again to the process sessions. In this video I'll be talking about resolving the process modeler's dilemma. What is the dilemma? You might ask. It's a delicate balance of conformance, accuracy, and fit for purpose for every single process model you have. Imagine this you have to create a process model for your senior management group and you decide to put in a process model that they can understand easily. Chances that that process model is fit for the purpose of your presentation, but it may be thin on details such as granularity. It might also not conform to those standards that the organization conforms to. Now it may be the case that that's happened, and if it has ever happened to you, or if you can imagine it you're not alone. That's why you need to resolve the modeler's dilemma.

Here are 5 key BPM roles that your organization needs to implement successful business process management practice. The Leader The leader's role is to ensure that there is a proper vision, mission and strategy for the practice and that's important because that sets the scene of where the practice goes. Particularly essential to bring in new business and create the value proposition of why the team exists and this is crucial because that will set the space and time and budget for the work to be done. The Architect The architect's primary aim is to deliver on the value. Now the value, once agreed on, has to be delivered and implemented in a proper way so that entire life cycle from inception of value to delivery has to be handled by the architect. The architect also is in the business of relationships. The relationships fall under three categories: Relationships of people, relationships of processes, the relationships of technologies, The architect has to be across all of those elementsand it's quite important that they handle this and understand dependencies because that's what you want to get at the end of the day.

Today we are talking about the purpose of modeling or as I like to call it the bedrock of everything to do with process modeling. Without it, don't even start. There are many reasons why you would process model. Those reasons may range from the requirement of a visualization right to process improvement. Interestingly enough, there was a survey conducted about a few years ago by the good folks at BPTrends that looked at all possible aspects that managers, architects and the like of people in our profession do who conduct any kind of process modeling and why they would do such a thing.

The scope of modeling refers to the left and right limit of your process modeling effort. There are three aspects of scope and the scope of modeling. Firstly, I'll discuss what scope is, why we need scope and why it's important. Finally we’ll examine how to derive scope. What is Scope? Scope refers to the left and right limit of your process modeling effort. Why is scope important? Scope is important because it helps you identify how much effort you and your team require to do any kind of process modeling. This is essential, especially if you're planning ahead and identifying what your start and finish point is. From an organizational standpoint, it could be a value chain. From a departmental viewpoint, it may be something a little bit smaller. But, defining the scope is an important part of your modeling excellence journey. Remember, it's always enhanced by an understanding of the purpose of why you're modeling.

As noted previously, one of the foundations of Business Process Management is a business process architecture. In fact, in our view, it is the first of the seven enablers of BPM, and indispensable for process-based management in any organisation. This article explores the ways in which a process architecture can assist to prioritise and manage portfolios of projects. Project Scoping The first benefit of using a process architecture in managing projects is that it assists with project scoping. Understanding the boundaries of the project (i.e. what it will and won’t change in the business) is fundamental to understanding which processes it will affect. A process architecture is of great value in this, as it allows a top-down, coordinated approach to assessing scope. Because a process architecture collects processes in a hierarchy, grouping related processes together, it is easier to see the scope of a project by assessing which parts of the process hierarchy it will affect. This offers two major advantages: Scale can be assessed quickly by looking at how many processes the project will affect, and to what depth. Scope boundaries can be set against a commonly understood and agreed reference point; that is, by setting limits on which processes the project is allowed to modify and which ones it will not affect.