Business process management (BPM) is a relatively new term bandied about by system integrators, workflow vendors and partners in an attempt to convey the benefits this new technology brings to their clients. However, BPM and how it evolved is often not clearly understood.
General understanding of BPM technology is, at best, that it is essentially another form of workflow, or business process automation, or that it is a process management extension for Enterprise Application Integration (EAI). Yes, it is - but it is also so much more.
In its infancy, the concept started out as business process re-engineering` (BPR). Authors of BPR handbooks urged companies to "think out of the box" and to change the way they did business, in order to transform themselves from an also-ran into a market leader in the shortest space of time. BPR, as it became known, was the darling of business consultancies during the 1980s and early 1990s. Businesses were swept away in the BPR tidal wave, in much the same way as they were by the dot-com hype a few years later, because it promised to improve quality, streamline and generally drastically improve their organisations.
Unfortunately, many of us who were around at that time understand now that these were somewhat extravagant claims and the promises of BPR and its supporters - the prevalent business management consultancies of the day -did not really materialise. Few companies were willing to endure the "big bang" approach of BPR by throwing away all their hard work invested in their existing systems. What they were really looking for, at the time, was the ability to improve the efficiencies of individual existing processes, re-using most of their existing technologies.
What did materialise were substantial charges from the above-mentioned consultants, who worked in a manner that had everything to do with spending as much billable time as possible on developing a theoretical BPR framework for their clients` organisations - without any element of risk and reward built into it.
The other problem was the very theoretical nature of the end-product of BPR. Although many good ideas were raised, and on paper looked extremely good, in practice it did not quite pan out that way. Generally the carefully and lengthily planned BPR framework and resolutions became lost in a deluge of hypotheses and change management issues - with very little real value emerging for disgruntled clients at the end of the day.
In this way BPR - and many consultancies with it - seemed for a while to have died a rather undignified death, brought about by the inherent inability of BPR to be put into practise in any meaningful way.
However, the need for organisational efficiency remained central to business agendas, which resulted in the rapid adoption and success of workflow.
Workflow, in essence, provided an automation of business processes within an organisation, thereby bringing about much of the streamlining and business process efficiencies that its less successful predecessor - BPR - had promised, yet failed to deliver.
Workflow became extremely successful in departmental-type process automation. In other words, workflows or business processes were automated for different divisions within an enterprise - for example, sales, administration, finance, human resources. This was fundamentally due to the processes being owned by individual department heads who were looking to improve their own environments without thinking of the "big picture". What was not being catered for in this departmental workflow scenario, however, was the issue of commonality. In other words, processes or sub-processes that were common across the entire enterprise.
This is where BPM fits in. The need for an over-arching business process management system became clear, once the issue of commonality of processes was recognised. BPM made it possible to see, automate and control all the business processes throughout the enterprise, even if these processes were to span external customers and/or suppliers. This is for example, where local banks have made huge strides. At one, for example, the bank has taken the credit risk assessment process - an element common across various divisions such as vehicle finance, micro-loans and current account, credit card and home loan applications - and made it available to be used not only departmentally, but also for cross-selling and cross-reference purposes, across the entire organisation.
Another excellent organisational example of BPM at work is the establishment of the Tele-Management Framework (TMF), an international group of the world`s major telecommunications companies, including Telkom, which have established a set of common business process automation or workflow templates to work from, based on universal 'best practice` processes to be implemented on top of a BPM architectural framework.
From these examples, it is clear that BPM is the key technology that holistically manages an enterprise`s business processes, controlling the various sub-processes across disparate applications, and linking them together at a higher, more strategic, level; thereby rendering it an essential component of every modern organisation`s business process automation agenda. BPM is no longer the domain of the IT manager or departmental head. Rather it gives, for the first time, the ability for the CEO, CFO and CIO quantifiable end-to-end control over the business processes in the enterprise.
Or, in the words of Staffware`s Chief Technology Officer, Jon Pyke: "BPM is the next step up from workflow...It is workflow at a different speed."
Share
Editorial contacts