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

The Leonardo Blog

Sandeep Johal

Recent Posts:

6 Steps to Follow When Designing Modeling Standards & Conventions

It's quite a challenge to keep a whole stack of process models consistent across a different set of stakeholders. You do this through conventions, and today I'll be talking to you about six steps that you can undertake to design good conventions.

How to Use Process Models

Have you thought about how process models will be used in your organization? If you have, that's great. Have you thought about the second time they'll be used, the third, or the fourth time? Here are some tips on how to ensure continuous use of your process models. There is no point in creating process models without a purpose. The point is now how do you ensure that the second and the third time that you use your process models, it's just as effective as the first time. I go back to my mantra which says, create a process model once, it's useful. Use it again, it's valuable. The secret sauce in making sure that any organization uses process models over and over again is not scientific except it's just about making sure that these process modeling activities are well embedded in existing organizational methodologies. Some of the methodologies that I'll be talking about today include change management methodology, process improvement methodology, and project management methodology.

How to Keep Process Models Consistent

Models created by different people in different parts of the organization with a different set of skills often create very, very different models. Now, this can be a problem because you are trying to keep models consistent.  Why would you want to keep process models consistent across different areas of your organization? Well, one simple reason. You want to keep widespread use of your process models.  That's what makes them valuable. And in order to get that widespread use, people in different parts of the organization need to be able to understand these process models. Take for example our language. You're able to understand me because we agreed that the English language is spoken in a certain way with certain structure, certain grammatical tense, and because of that, I'm able to communicate. Same way with process models.

Resolving the Modeler's Dilemma

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.

5 Key BPM Roles You Need For a Successful BPM Practice

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.

    Related Posts