Every single process model that you create is part of a larger ecosystem, an ecosystem of dependency and relationships. It definitely is because in real life, your processes are related to one another. In this video, we talk about what that ecosystem framework is, and how to place your models in there.
Every single model tells a story of the organization, a story of how processes deliver value. However, on its own, it may not fully describe what's going on. More specifically, it may not describe the relationships and the dependencies, which means that each process model that you create on its own may not be able to show you an impact cause at the start of the process, and its effects downstream.
The way process models are linked to one another is through relationships and dependencies. And to show that, we use the process architecture. The process architecture is a 30,000 foot view of the value that your organization delivers to its external and internal stakeholders. The process architecture can be thought of as a set of processes that can be categorized in three areas: Strategic processes on the top, for example, strategic planning, then in the middle of that architecture you have your core processes. Your core processes are the processes that sets you aside from your competitors. For a university, it may be how they create graduates, on the quality of those graduates. And finally the support processes. Support processes are required to carry out the core processes, and these are in the form of your finance processes, IT processes, HR processes. Not organizational units, but processes.
So in this process architecture, every single one of your process models needs to be connected. The connections can be thought of in the form of relationships and dependencies. Simply put, the outcomes or outputs of the first process need to become triggers or inputs into the next process. We find this to be a one to many relationships and that's okay - that's one way to ensure that there is connectivity.
Another way would be to uniquely identify each process model within that architecture. For example, you might use numbers to do so. Numbers that make sense to you. So four numbers might indicate a fourth level process model, three numbers might indicate three, and so on, you get the idea. But you could also give it a unique identifier to identify where it lives within that process. In other words, does it live in the core, does it live in the strategic, does it live in the support?
A combination of using inputs and outputs, outcomes and triggers from one process to another and connecting those up in an architecture using unique identifiers is the best way to ensure that your process models are kept in ecosystem of connectivity and relationships. You want this because an impact that's caused upstream in the process may have effects downstream. The only way is to understand this through the dependencies and relationships.