<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

All Posts

Realizing Process Modelling Benefit: The Repository Dividend

Process Modelling Dividend

As organisations continue the journey to develop high levels of Business Process Management (BPM) maturity and innovate their processes, an effective process modelling platform becomes vital. Moving from static, disconnected process documentation to dynamic, flexible views of process is the key to realising process modelling benefit.

The Repository Dividend

Formal, systemic and graphic documentation of business processes is central to the process-based management philosophy. The underlying premise of BPM is that the activities that combine to achieve work outcomes can be usefully abstracted, i.e. “modelled”. The case can be made for managing process documentation in a particular way, namely through object-oriented repositories of business process data. The repository facilitates coherent creation, publication, viewing, storage, organisation and linking of business process models and their data. Properly designed and managed, object-oriented repositories significantly increase capability in model management, process analysis and improvement, change control, cross-enterprise useability, and process performance management.

Delivering Benefits

Object-oriented process repositories deliver many benefits:

  • better control over model production – higher quality at higher speed and lower cost
  • easier and more cost-efficient reuse of models and their component objects
  • integrated and consistent publication of process information
  • enhanced control over who can access the various models
  • increased ability to change process models at reduced effort
  • better control over versioning and change histories
  • ability to generate different views of process information for different audiences
  • significantly increased ability to use ‘what if’ analysis scenarios
  • ability to create and manage process variants reflecting different global requirements
  • ability to track the source and history of process information.

 A Repository Based Approach

The following table summarises the benefits of the repository-based approach:

Topic

“Flat” Files

Object Oriented Repositories

Access & Governance                                            

Can only be enforced via network or external document management system privileges

Can be tailored based on organisation process role and responsibility

Standards &  Quality Checks

Can be developed and documented, but can only be enforced manually

Modelling standards and conventions can be enforced by configuration changes; quality checks can be automated to speed their application or highlight errors in the models

Queries & Reports

Inferences and searches only (“show me models with word “x” in it”)

Queries, summaries and detailed analysis of connected objects and occurrences of objects can be easily obtained; summary views can be generated

Content Re-use

Content can be copied and pasted; but it’s impossible to control this

Controlled re-use of standardised objects reduces modelling time, improves recognition, reduces adoption risk and ensures traceability



Download Object Oriented Process Modelling Repository
Darren Wright
Darren Wright
Darren Wright, Senior Consultant with Leonardo Consulting is a specialist process architect with extensive experience in the Higher Education, Technical and Further Education and Government sectors.

Related Posts

The Ultimate Guide to Process Modelling

A new day, a new process modelling project. The project plan has been signed off, reference documentation was gathered, all stakeholders have been identified and now…now what? While process models increase in popularity and most businesses seem to agree that process models are indeed a good way of representing how an organisation creates and delivers value, there is little to no guidance on what a good process model is, how to create one and how to successfully go about executing a process modelling project. While this guide does not claim to be a silver bullet for all your process modelling problems (look at our Modelling Excellence framework for that!), it aims to be a guide for Project Managers and BPM Professionals in every stage of the modelling journey, regardless of whether you’re just kicking off a new modelling project, are in the middle of a major project, or are just looking for a refresh. Please note that this guide does not address steps to set up or configure a process modelling tool. It is focused on the activity of process modelling.   Let’s get started! This section includes topics that should be covered prior to kicking off any process modelling project. If a project is already underway, but struggling, we recommend revisiting this section to ensure the basics have been covered. If your project is already underway and going well, you may opt to skip ahead to the “Business Process Modelling” section. It’s all about the purpose… Firstly, ensure the purpose for modelling has been identified and agreed upon by all stakeholders. Whether it is communication, training, process measurement, improvement or configuration of a workflow tool, any modelling effort must serve a purpose. Major decisions such as “What modelling tool is the right one?” as well as minor decisions such as “Should I include this detail in my model?” can easily, logically and consistently be answered once the purpose has been identified. Consequently, if a clear purpose for modelling cannot be identified, no time and money should be spent on modelling as the models would end up being waste. The start of a process modelling project is also a good time to identify additional use cases for process models and pitch those to the stakeholders. The more use cases there are, the more robust the business case for process modelling becomes. Models that are re-used often are valuable to the organisation, rather than just useful for a one-off project. This does not mean that creating models for one-off use is waste. Although we generally recommend maintaining and re-using process models as much as possible, there are many valid use cases for and circumstances under which organisations choose to create process models that will be deleted once the project is completed. We do however emphasise that this purpose needs to be clearly identified and agreed upon, so nobody comes looking for the model two years later and needs to then kick off another modelling project since the former models are either out-of-date or nowhere to be found. Understanding the purpose of modelling will also help Modellers in the information elicitation and model validation stages of the project. They must always be prepared to explain what they are doing, why they are doing it and how it benefits the organisation. A strong pitch for modelling, tied back to the purpose, will help to keep stakeholders focused during workshops.

Moving From Continuous Improvement to Continuous Process Management

  Continuous process improvement is a common organizational aspiration, and it is one of the most difficult things an organization can attempt. The continuous aspect is quite a challenge, as is realizing business performance improvements—especially once the easy and obvious changes have been made. Organizations need an ‘internal improvement engine’ that replaces insistence with evidence.

Process Architecture vs the Organisation Chart

  In my working life I spend a lot of time working with client organizations to discover and capture useful models of their process architecture. In every country, industry sector, organization type and size, there is a common problem that bedevils every project. We all, and I include myself here, can too easily slip into the habit of the last 100 years (or you might argue 1,000 years) of visualizing the organization as its organization chart. Comments such as “What about the work they do in department X?” might just be a useful test for a developing process architecture, or they might indicate a lack of understanding of what the architecture represents.