It is great to see an emergence of customers implementing a multiple Process Library architecture, and we are pleased to discuss here what it delivers, the benefits of such an approach and the latest features developed to support it.
Multiple Process Library architecture works brilliantly to support organisations where:
- Business Units are quite independent and each have their own ways of working.
- The relationship with the customer/supplier involves more than one Business Unit, so there is a need to understand the end-to-end process across the organisation.
- Core functions such as HR and Finance support all of the Business Units, with a standardised process.
Accordingly each Business Unit needs its own Process Library containing their own processes, which they are able to capture and update. Maps within each library need to be able to link, both within the Business Unit library and across other Business Unit libraries, where they form part of a cross-functional process. Core functions such as HR and Finance need their own libraries, containing their own internal processes.
These usually need to be confidential. However, the standardised core processes which support all the Business Units (e.g. the expenses claim process) have to be accessible from each of the Business Unit specific libraries, so that users of each Business Unit specific library can access all the processes that they might need (both Business Unit specific and core) from just one place.
Business Units must not be able to alter core processes that they don't own. So for example, only Finance can alter the expenses claim process and not Marketing and Communications, even though Marketing and Communications will be able to access the expenses claim process from their own library.
Search must only return results for the library searched. So for example, anyone searching for 'working at height' in the Civil Engineering Library must only have results returned from that library and not from the Utilities 'working at height' process from the Utilities' Library. There must be however, the option to search across all libraries - a global search - should the end user want to view all available business processes.
Such multiple Process Library architectures ensure that:
- End users can easily and quickly find all the information that is relevant to them (and only that information).
- The creation, maintenance and ownership of process documentation remains with the relevant Business Unit/Core Function.
- At the same time, standardisation is supported where appropriate.
- There is a central platform or mechanism for the entire business to collaborate, communicate and improve their end-to-end processes.
Triaster recommends setting up a multiple Process Library architecture as follows:
- A top level, global Process Library is set up, that enables search functionality across all Live library content and acts as a channel to each individual library (Business Unit and Core Function). It is often designed to represent the business as a whole.
- Process Libraries are set up for each Business Unit and Core Function , which 'hang' from the Global Library. Each Business Unit/Core Function Process Library is wholly independent and is controlled by its own Library Administrator. Each Library has its own homepage designed for the Business Unit/Core Function area it represents.
Feature: Library specific search, alerts and approvals
- Search is now library specific and the search results yield documents and processes relating to that specific library.
- Alerts and approvals are now library specific and the library search yields only processes and documents pertaining to that library.
Feature: Library cross-library linking
- Of course linking maps with off-page connectors has always been possible within libraries. Triaster has now developed the ability to hyperlink across libraries using off-page connectors. This enables an end-to-end process view of the organisation making the customer/supplier relationship visible across the business. Cross-library links are represented by a coloured off-page connector and the links are preceded by the library name so the end-user is aware of when they are entering a new library.
Feature: Inheritable processes and documents (custom publish)
- In addition, Triaster has introduced the concept of inheritable content which enables processes and/or documents to be pulled from one Core Function Process Library into a Business Unit Process Library. For example, Human Resources might want to share the updated recruitment process that everyone should use. Finance might want to share the updated expenses claim process and forms that should be used. The Core Function Library Administrator simply drops the approved process into an inherited process folder within their own (Live/Master) map store and following a global library publish, the process is inherited by the other libraries.
The inheritable content functionality is maintained through a text file which can be edited by the Library Administrator(s) to enable the scaling of the architecture to include more libraries as required. Triaster strongly recommends that a multiple Process Library architecture is supported by a central governance group that agrees and maintains a governance framework which is adopted and adhered to by the whole organisation. We also recommend that the central governance group sets up author user groups, to support and sustain the collaboration and communication across all areas.