Most of the problems in process-orientation come from the fact, that processes are viewed as global artifacts independent and above of functions (business components). Hence for example the problem of cross functional processes and lack of authority of process owners in the organization. If we would build the whole enterprise using component orientation -- that is encapsulate the processes inside business components, and allow only interactions of business components based on well-defined interfaces (SLAs), then there will be no such problems, as every process owner is in full control of its processes and resources needed to perform these. Additionally enterprise would be way more agile (and self-organizing),
as responses to the possible changes are localized into the components, any
components can be replaced with the best in industry (outsourced) without any
adverse effects to business as whole, and the global flows of activities will
adjust themselves to the optimal in given context. If you look from the customer's perspective, then
processes are encapsulated inside the component with which you interact. For example if customer requests for loan offer from sales component, and receives the response from sales component, then it doesn't matter to him/her what other business components are involved and how. In this case sales component management is completely
in charge of the process which is used to produce the response (or service), as
it is not crossing borders of component, and component management has SLAs for
all the services that it needs/uses from other components -- so there is no
need for matrix-organization (with the dual and often conflicting command lines) at all. To the sales component doesn't actually matter how (using what process) the underwriting is done by the risk management component as long as the SLA for underwriting is not breached. |
Random Thoughts >