A company’s approach and it’s attitude to it’s Business Processes will define it’s Customer’s experience and the level of exposure it has to the long arm of the Regulators. Considering the impact that both can have on the bottom line of the balance sheet, isn’t it better to adopt a more strategic approach to how you manage them?
Many organisations have legacy documents either in text based SOP’s or rudimentary graphical representations of their processes and procedures which typically have been captured using widely available none-specialised drawing tools in addition to Business As Usual activities. Such a tactical approach to process management fails to deliver on envisaged or potential Business Benefits forecasted at the outset and the reputation of Business Process Management initiatives become tarnished. Does this mean that BPM should be banished as ‘we’ve already done it’?
The problem is that tactical use of BPM techniques is a bit like herding cats: each project has a kick-off phase, which typically includes reviewing any documented evidence of the ‘As-Is’ process. However, wheredocumentation exists, it is more often than not, out of date. It was captured as part of the last project that touched the business area and it died when the project wrapped up. So the project teams go about re-capturing the current process that is the focus of their current project. Unfortunately, this is an all too common scenario that costs business an immense amount of time and effort, which will probably be repeated when the next project is initiated.
And what if projects cross in their efforts? Using documents to describe the area of work being delivered means that there is no single overview of which Projects are currently touchingparts of the Business Processes. What is needed is a higher level overview of what projects are doing what and to which business processes.This achievable but not with a tactical approach and certainly not with non-standard process documents.
Enterprise BPMS provides Organisations with Business model objects that enables a single view of many artifacts, not just Business Processes, whichmeansthat the process documentation is graphical representation of how the model objects are utilised across the enterprise. What this means is from any given perspective, be it a single Process, a piece of IT architecture, organisationalResources, Compliance Requirements or Strategy view point, we can identify the dependencies thatexist across the business model and where they are deployed in the organisation.