- OPERATING MODELS -
Operating Models bridge the gap between process design and business operations
Definition
In their most basic form, Operating Models dictate where and how critical activities are performed across an organization. In the context of a business transformation, an Operating Model is the blueprint for how resources are organized in enterprise entities and how they should interact with each other to achieve the strategic objectives of the business. Operating Models therefore show the execution of business processes across different enterprise structures including all involved business partners (vendors, customers).
Operating Models in Business Flows
Business Flows, our framework for business transformation, provides a distinctive approach that integrates the utilization of End-to-End business processes (scenarios) and Operating Models as the primary blueprint for organizational transformation.
Methodology
In Business Flows an Operating Model is defined by a set of flows. Each flow distinguishes the exchange of information, material, service, or value between a “sending” and a “receiving” enterprise structure. These flows are accomplished with the help of business processes, hence every flow in the context of an Operating Model can be linked to an End-to-End scenario and/or business process. We take all the flows, including the related information, the involved organizational units, and business partners and create an object-relation model which is embedded in the process repository.
Example
It is important to understand that companies typically require several Operating Models. Each Operating Model may have the same business model as an objective (e.g., after-sales repairs as a service) but will vary heavily depending on the complexity of the involved enterprise structures and their organizational and geographic characteristics. Simply speaking, the more “boundaries” the flows must cross, the more complex the Operating Models become, and the more complex the required business processes typically are.
A simple example (Fig. 1) is the difference between providing services to customers within a country or to customers outside of the country. In this example, regular customers inside the country don’t have to initiate a pick-up repair order because a regular pick-up service is provided (Milk run) whereas companies outside the country do.
After the Operating Models of the above-mentioned example are created we can now filter and drill down into the specifics. In Fig. 2 we have filtered the model for the “EU non-AT customers” and all its flows. You see two Material Flows (inbound to the Service Center and outbound from the Shipping Point) and Information and Value Flow interactions with the Commercial Unit. In this perspective, the intercompany flows (i.e. the material flow between the Service Center and the Shipping Point) have been deliberately hidden although they are included in the model.
Fig. 2 also shows the attributes of a selected flow and its linked business process (Perform goods receipt for customer-owned material) as well as the relevant End-to-end scenario (ASS Repair centre services processing Fig. 3). Navigating via the URL to the End-to-end scenario allows us to validate each process against the specific sequence of interactions of the operating model. In this example, it would be interesting to check if the I2O Outbound logistics process fulfils all requirements for the cross-border shipment (Fig. 2 - Material Flow ‘outbound repair’).
Uses and benefits
Using our Operating Models bridges the gap between business and IT by facilitating communication and creating the synergy between your strategy, its implementation and execution. They support the implementation and change management during build and roll-outs, adding considerable value to the success of your Business Transformation. You will be able to create a common understanding of how it all (people, processes and technology) fits together. The Operating Models help you communicate the WHY and the WHAT you are changing to internal and external stakeholders at various instances along the transformation lifecycle for:
Supporting the business case for the ERP transformation project
Scoping and process design
Validating process models against ‘real world scenarios’
Conducting fit/gap workshops
Defining subsets of E2E scenarios and processes to fit certain template shapes/roll-outs
Deriving test scenarios
Analyzing all use cases related to specific E2E scenarios