Process Thinking is a theme that has a predominant presence in many transformation efforts, since it is important in bridging the business and the ERP world. But its relevance is rivaled by this one other theme, more and more referred to as Services Thinking. We have entered the Services Era.
The ArchitectedERP e-book sets forth the Services Thinking concept. It is positioned as a conceptual placeholder for any thinking or concept relevant for managing and executing business services and processes on the one hand and the automated support of these on the other. The concept can help you to:
Structure your understanding of new business and IT hypes and trends;
Determine the relevance and completeness of those, and;
Determine the risks associated to them.
The shift from a traditional functional mindset towards Process Thinking in the form we currently know it, started back in the early nineties of the past century. A (business) process was defined as “a specific ordering of work activities across time and space, with a beginning and an end, and clearly defined inputs and outputs” (Davenport, 1993). This definition probably works fine for the majority of us, albeit that this specific ordering merits some attention.
Standardizing the way your organization works by catching work activities in a business process is commonly regarded advantageous in case you need to repeatedly produce identical results and assure the delivery of constant quality. Well-defined and implemented business processes are executed more effectively and efficiently and it enables normative process performance control. The specific ordering in practice however often is a fixed ordering allowing for little flexibility, especially not if the process is supported by ERP functionality.
There are many scenarios thinkable in which the ordering of activities is not so fixed, or not even fixed at all. Just think of yourself, receiving an e-mail. Or the turning in of a found wallet containing large amounts of cash and a phone number connected to someone allegedly accused of drugs trafficking. Are these human-centric scenarios still to be called processes? What if your organization has no need for tightly-coupled activity sequences? When you rather want your business to be agile, allowing for processes to be created on the fly? And position changeability as a primary design goal, in order for your organization to become as volatility-proof as possible?
The Services Thinking concept intends to address these requirements. It aims at implementing just big enough business services supported by just big enough chunks of IT functionality, focusing on those business domains where agility is key. Why? This helps you deliver business capabilities in manageable independent pieces, supported by congruently proportioned IT functionality. From an IT point of view, the architecture style which supports this concept is by and large referred to as a Services-Oriented (Application) Architecture (SOA) where the order in which functionality is executed is managed through a Business Process Management Suite, that should for one enable end-users to dynamically adjust business rules.
So by using this framework you can for instance settle your internal debates around SAP-related directions, like on what to do around Business Process Management automation (BPM), Identity Management (IDM), Business Rules (BRM), Analytics (BW), or Composite Applications (CE).
