A common problem experienced by companies with diverse operations is that of standardizing processes.
Finding a balance is a complex activity that involves:
a) having enough processes definition to drive end to end processes and hence results for the company
b) enough tolerance for variations between departments/functions that that appropriate differing approaches can be taken
Having a federated model of processes enables this balance – so that a standard end to end processes is used (for inputs, outputs, required standards) but function specific variations can be incorporated.
For example if we have an end to end process for development and ops, we may want to utilize Agile or CMMI for systems and software development, 6 Sigma for manufacturing, ITIL for operations. We can define the workflow at a level that defines the inputs and outputs for each major area/function but leaves the method for satisfying the end to end process requirements to each area/function team.
Each of the areas need to work in unison to deliver the product, service & objectives of the company. Yet human beings are the resource behind most workflows. And we is try to enforce procedures that are standardized across the company, but are not necessarily perceived as relevant or appropriate, you’re going to get pushback if not outright rejection.
Processes are to help the company build and deliver on its objectives – not necessarily to get a perfect enterprise process architectural implementation.
An example that I often use is that of road rules. Yes, everyone has been trained in the rules of the road. But why do we need to police them? Because people still break them. So why do we think we can perfectly define procedures to an incredible level of detail and expect people to follow them? Nice in a perfect world, but perfect is the enemy of good-enough…