About Us  |  Search  | FAQ  | Contact Us
Workflow
Home
Banking
STP
Risk Management
BCM
CLS
Human Resources
e-commerce
Features
Smarts Cards
Interviews
Optimise CRM
Data Warehousing
Disaster Recovery
Swift Messaging
Securities
M-commerce
Africa
Finance
BPM & Workflow
Capital Markets
Global Custody
Outsourcing
 

Page last updated
February 15, 2003

 

 

I

What's happened to Workflow?

www.staffware.com

If you're not confused about what's been happening in the world of workflow, then you haven't been paying attention. Over the past 18 months or so, there has been an explosion of interest in Business Processes and what we need to do with them; hasn't taken long has it? So, why the fuss? More importantly, why the confusion?

What is a Process?
Well let's go back to some fundamental ideas. First and foremost, we should consider what a process is. The simplest way to get a common and unambiguous definition is take a literal interpretation of the word "process" and where better than Webster Dictionary.

Webster Dictionary of 1913 defines a process thus: A series of actions, motions, or occurrences; progressive act or transaction; continuous operation; normal or actual course or procedure; regular proceeding. Simple enough one would think, so moving forward almost 100 years we see that process has become much more ; a well known figure in the Information Technology defined them as: "[processes] can be used to ease integration between partners and customers, communicate more effectively with customers, glean the most out of enterprise applications, and to reuse existing assets rather than perpetually start from scratch." ; so we should dig a little further.

Read any management guru's view on running an enterprise and the underlying fundamental base point is; the process. Processes exist because organisations do. They are the fundamental underpinning of all business transactions, the least common denominato, in plain terms, they "are the way things get done around here."

Business Processes exist to support the simple dream of the average (if there is such a thing) entrepreneur. Most people start a business to make money; to do so requires four "simple" steps as follows:

1. Take an order (sometimes called selling)

2. Source the product (buy it, build it, whatever)

3. Fulfil the order

4. Get Paid

No rocket science there then. A simple four-step process. But this simple vision collapses when you look more closely at each of the steps.

Take step 2 for example. What's happened to Workflow? In order to source the product, lots of things need to have happened or will need to happen. For example, and this is not an exhaustive list:

1. You will need to buy in the raw components

2. You will need to manufacture certain elements

3. You will need to maintain and manage stock levels

4. You will need to provide packaging

The list is almost endless, but you can see where this is going

All of the resultant sub-processes are designed and implemented to support the high level vision. They are the "why" things are done. So why the sudden rise in interest in Business Process Management?

Business Software has long been used to support key business processes, there is nothing new in this notion. What has changed though, is the realisation that the easiest way for organisations to be competitive, manage costs, be viable, be flexible and responsive, is to understand and improve the structure and execution of their business processes. And that deploying process based software is key to achieving that.

So we are not trying to solve any new problems; just solving them differently, more cheaply, more quickly and more effectively. How? By seeing those problems as a set of well defined and integrated processes rather than isolated, stove-pipe solutions which are rigid in structure, difficult to maintain and costly to implement ; and worse still; obsolete by the time they are implemented.

Dave McCoy of the Gartner Group encapsulated the above objective in his definition of Business Process Management back in March 2001 when he defined BPM as: "a blending of process management/workflow with application integration technology to support rich human interaction and deep application connectivity."

And all this to fulfil the CEO's desire to:

1. Take an order

2. Source the product

3. Fulfil the order

4. Get Paid

So why the confusion between Business Process Management and Workflow?

BPM V Workflow
This issue is what many pundits in the industry, from Product Marketing types to Industry Analysts, are hanging their hats on; that there is a difference between Workflow Technology and Process Management. This is at the heart of the confusion.

If an entire new market is to be produced, we need a fight; but most Technologists and Analysts know that the distinction is a fine one; if indeed there is one at all. So let's look at the perceptions, myths and some analogies.

Workflow
Starting off with workflow, for several years now there have been 4 main myths that those of us in the industry have had to live with.

Myth #1: Workflow Automation = Re-engineering
The first myth, that of workflow automation and business process re-engineering as being one and the same, is largely historic, and is unlikely to figure as an impediment in today's market. However, it has been included here for completeness. This perception was accentuated by the fact that at one time, almost every press article, conference, or seminar dealing with workflow automation included a discussion about business process re-engineering. People used to talk about them in the same breath.

Some Analysts still include business process re-engineering in discussions about workflow rather than focusing on the technology. The media includes business process re-engineering in news stories about workflow automation because we (vendors) like to show off examples of how our product changed the way a customer does business.

Re-engineering and workflow automation are not, and were never the same. It is important to understand this distinction. BPR simply looked at best practice methods for processing, whilst workflow automation actually implemented the technology to support these processes.

Myth #2: Workflow Automation is Difficult.
The idea that workflow automation is difficult is another popular myth. Since it is perceived to be difficult, people shy away from adopting the technology. Workflow automation by itself is not "difficult." However, if you select a business process that is complex, it follows that the resulting workflow implementation will take longer, especially if significant integration with systems is required. As with any technology, it is the nature of the problem that is addressed which determines the complexity.

Myth #3: Electronic Forms software is a Workflow Solution.
Similarly, believing that electronic forms software provides a solution for workflow automation is another myth. It is true that electronic forms are commonly used as the delivery mechanism in workflow automation. However, electronic forms are only one of the many technologies used in workflow automation. By themselves, electronic forms do not provide workflow automation.

Myth #4: Workflow Automation is based upon document lifecycles.
Probably the myth at the heart of the debate between Workflow and BPM. Workflow automation has the reputation that it is suitable only for well defined, static clerical processes; i.e. people-to-people deployment. This myth stems from the fact that many Document Management and Imaging solutions vendors quickly realised that the only way of adding value to scanning a document or filling in an electronic form was to do so as part of a well defined business process. Therefore it followed, that in the early years of workflow deployment, most systems were part of an overall Electronic Document Management solution; but this is no longer the case and hasn't been for some time.

BPM
If you look at BPM, there are very similar dynamics at work as those that shaped the perception of workflow. As I mentioned above, workflow became synonymous with document technology because of the need of EDM vendors to add value. Well the same thing is happening here, only this time it is the Enterprise Application Vendors who are trying to set the agenda; and in doing so, create another IT market.

The act of integrating two systems together definitely has a value; a point to point connection that eases the work required to get information out of one system and into another adds significant value to an organisation ; no doubt about that. Once you have a requirement to integrate more than two systems, then you begin to define a formal business process; so what better way of augmenting the EAI offering than to offer some toolset to manage that process; a neat idea. The focus of these systems is a data centric mechanism for tying applications together; but it is not and never will be the full picture.

This is where the technologies of BPM and Workflow merge. True BPM; An Amalgam of Workflow and EAI technology True Business Process Management is an amalgam of traditional workflow and the "new" BPM technology. It then follows that as BPM is a natural extension of; and not a separate technology to; Workflow, BPM is in fact the merging of process technology covering 3 process categories: interactions between (i) people-to-people; (ii) systems-to-systems and (iii) systems-to-people; all from a process-centric perspective. This is what true BPM is all about.

But what is the problem we are helping customers solve? There are two:

1. The needs of the Business Process Owner; the CEO. Those four simple steps mentioned above is key to all of this

2. But we must also address the needs of the Data Owner; the CIO The CEO - In tough economic times, one thing moves to the top of the CEO's agenda - the need to improve business processes. Rapid payback and quick return on investment become crucial. As well as reducing costs, the CEO needs to improve business controls, and provide quicker response to customers. And above all else, the CEO needs to deliver improved business processes by harmonising with existing infrastructures and technologies, such as ERP and CRM. The only effective way of achieving these objectives is to improve the effectiveness and flexibility of end-to-end processes.

By implementing BPM, the business community will be able to build and execute processes that are designed with customers in mind, deliver better quality, faster and at lower costs, and retain competitive advantage by being able to execute processes that deliver the business strategy. The CEO doesn't care about systems integration or the concepts of straight through processing, however valid that may be. But the CEO does care about monitoring how the business is performing, being able to react to changes in the market, handling exceptions quickly and effectively and having a complete view of the organisation.

The CIO; has the task of making sure the needs of the CEO are fully met quickly, effectively and with zero disruption to the business. Systems implemented in today's rapidly changing technology world must show fast ROI and bring benefits to the bottom line, without having to discard what works.

Providing technology that enables users to map out the business process in clear graphical notation is an important aspect of the technology, but it's only part of the solution. Being able to execute that process, facilitate simple integration with legacy systems and commercially available packages and monitor/manage how those processes are executing, are also vital components. Furthermore, BPM as defined here, enables the CIO to implement new applications quickly and tie the front office applications and the back office systems. This reduces maintenance costs, time to deploy and makes the IT function far more responsive to the business needs.

Web Services; the final part of the puzzle?
One cannot ignore the impact that web services will have on this BPM technology. The current efforts required to integrate systems using "legacy" EAI technology will soon be a thing of the past. If Web Services technology manages to deliver on its promise, much of what we see today as BPM components (the EAI Tools, the middleware etc.) will become things of the past. Scalable and robust workflow engines will come to the fore as we have never seen before.

Much of the plumbing to tie systems together will become transparent to the systems integrators and the process owners. What we will see is the rise of asynchronous, people centric process implementations; with simple integration deployment that is a consequence of the process, not the driver.

Conclusion
In summary, BPM is an extension to Workflow technology; and could be defined as essentially the same thing but going at different speeds. In the 10 or so years I have been involved in this technology, I don't recall ever seeing a system which did not integrate with a legacy environment, nor have I seen one which didn't have some aspect of straight through processing system-to-system integration.

However, the notion that system-to-system integration is the be all and end all of process management is not only a fallacy, it is also dangerous. Studies have shown that of all the identified business processes, only 4% can be defined as truly STP solutions; people are always involved. And the simple fact remains that people do business with people. It's people who design and execute an organisation's business processes and, in turn, it's the processes, which represent an organisation's competitive differentiators in the marketplace. By adopting a process-centric approach (as opposed to a data-centric one), every level of the organisation gains a much deeper and broader understanding of the way that the business is conducted. And using business processes as the process integration roadmap for integrating the underlying application and data infrastructure enables organisations to concentrate on the 'Why' of their business and not on the 'What'; and it's the 'Why' that drives a business's success.

On reflection, I believe that much of what we see today in the EAI arena is doomed. Web services will change all that, more importantly asynchronous process management and web services will change it. The current crop of EAI vendors are rapidly shifting their focus to web services, but the data centric, synchronous approach, taken by these products will not be the answer. Nomenclature is unimportant; the difference between workflow and BPM is as fine as the difference between clothing and apparel. Arguably both these terms are wrong; the real answer is Business Process Integration or BPI. EAI is dead, long live BPI.

Jon Pyke
Staffware Corp.

 


 

 
 

 

Home  |  About Us  |  Search  | FAQ  | Contact Us