CSC Home PageSkip to Main Content
About Us | Services | Client Results | Insights | Contact Us | Careers
Corporate Governance
Investor Relations
Newsroom
Cycling Sponsorship
Locations
Blogs, Podcasts, Videos & RSS
E-mail Story Story Feedback Print Version
Features
Home Page Home Arrow Features 2003
Changing Business by Changing Business Processes


The following article appeared in the June – August 2003 edition of CSC World.

By Ronald Brown

Business processes are living, breathing things that have lives of their own. That is especially true of the complex and dynamic processes that add the most business value and distinguish an organization from its competitors.

There is nothing static about them, so they cannot be captured forever in lines of code. Organizations all over the world nonetheless keep trying to do just that.

The price organizations have paid for using inadequate technology to get their high-value processes under IT control is very high: less business control over those very processes. Fortunately, technology now is available to increase both kinds of control over business processes.

Categorizing business processes

The business processes that are crucial to an organization’s strategy also are the most complex and dynamic. "Complex and dynamic" mean the processes have many steps and participants, and the participants are free to run a process in a way that is best suited to the situation they are in. Those are the most difficult to get under IT control, but they are not the only ones an organization must review if it wants to change the way it does business.

Figure 1 graphically represents a way to categorize business processes by strategic importance and complexity. One way to review these processes in terms of the degree of IT control is to look at the graph in vertical slices.

Starting at the left axis, the first slice would take up about 15 percent. Judging from process deployments in several industry sectors, the processes in that slice, being simple and static, are best done inside a package. Although development takes a long time and packages are not easy to change once completed, they make sense for simple processes.

The second slice extends another 15 percent to the right. Being slightly more complex, each of the processes in this slice probably spans more than one package, going across such systems as customer relationship management and inventory or billing. Rules engines are among the technologies that are good at coping with that level of complexity, so we can construct some business rules to orchestrate a process across packages in a fairly simple fashion.

The third slice adds 40 percent, which puts the line 70 percent of the way across the diagram. These processes are even more complex and dynamic, and workflow software vendors are pouring a lot of money into research and development on them. Their goal is to move the line even farther to the right by packaging even more complex processes. Despite investing a lot of money — and driving up the license fees — they haven’t moved that line very far. That suggests they’ve reached the limits of their technology.

The remaining 30 percent includes all the really interesting business processes. The ones in the upper-right quadrant are the high-value processes that distinguish an organization from its competitors. These processes also have been out of the reach of traditional technology.

Dumbed-down discriminators

Traditional technology has dealt with these processes by dumbing them down, by moving them to the left on the diagram, making them less complex and easier to fit into a package. The further a process moves to the left, the less strategic value it has. Packaged processes also are less likely to allow a company to distinguish itself from its competitors, who probably are using similar software. Companies using similarly packaged processes find they have to reverse engineer those processes from the constraints of the packages. Those complex, dynamic processes have to flex in all sorts of directions over time to meet subtle changes in the environment, and that’s very hard to do inside a package configuration.


Complex processes also cannot be confined to one package. Managers who try to review a process today would have to chase it across several departments and software packages. One department’s package would show one slice of the process. Then there would be a little manual bit in between the next department’s package, which would show another slice of the process. There would not even be consistent terms across all the departments. What one department calls an account ID another will call a customer number, and these numbers will most likely be of different lengths and formats and contain different values. Because it is almost impossible to put all the pieces of the process together, it also is nearly impossible to do two of the tasks at the end of the process life cycle: analyze and improve (see Figure 2).

Using BPM to shorten the process life cycle

Traditional IT does a fairly good job with the first part of the process life cycle, but it is hopeless at facilitating the second part. A process that can’t be analyzed can’t be changed. Change would be politically difficult even if it were technically possible. The top part of the process life cycle usually takes a couple of years and a lot of money. If it took a few years and a few million dollars to implement a process, who’s going to be brave enough to suggest that it needs improvement? "It cost us $10 million and now you want to change it? And take another six months?"

For all the lack of success in putting high-value processes under IT control, organizations have good reason to keep trying. Business processes are the levers a company uses to drive its business in the desired direction. A Business Process Management (BPM) approach not only shortens development time, but provides the complete end-to-end view of processes that organizations need to work those levers. With a full audit trail of the process, including the manual bits, with consistent terminology and metadata throughout, organizations can start viewing, monitoring, and controlling the things that are important to their business model and business strategy.

BPM does not so much change processes — which are things people do — as allow people to change them by providing a supporting technology that is much more flexible than anything that exists today. The trend toward componentization in packaged software is a small step in the same direction. BPM takes a larger step by providing a disciplined way to connect those components — static bits of functionality — even across heterogeneous, proprietary applications.

Using BPM, bits of functionality can be extracted to a business process engine which is designed to permit process engineers to combine them in any way they like through a diagramming interface. As soon as you save the diagram, it becomes executable. Using a technology based on pi-calculus (see "Concurrency Theory and Business Process Management: Q&A With Robin Milner"), the business process engine collapses the "design, implement, execute" stages of the process life cycle into one stage.

BPM thus delivers instant gratification, which completely changes the philosophy within organizations. The traditional practice is to spend time and money in a futile attempt to make a process package 100 percent accurate — it has to be 100 percent accurate because changing it is too expensive and time-consuming. BPM, on the other hand, allows managers to go to market with a 60 percent correct process, which can be improved quickly as and where experience shows improvement is needed.

Live, breathe and change

It’s worth repeating that business processes are living, breathing things. If they are to deliver business value, they must be brought under control. That does not mean shackling them or putting them in cages. It means allowing them to adapt to their environment. Business Process Management allows processes to be flexible, giving managers more control over strategy.

Eventually the mathematical concepts underlying BPM will work their way into process packages, making them more dynamic and easier to combine. Most of you reading this article will be retired by then. In the meantime, there are business process engines.

Ronald Brown is technical director for CSC Consulting and Systems Integrations in the U.K.. He runs CSC’s architectural engineering services and enterprise technology integration practices for Europe, the Middle East and Africa regions.

Related Information:

Contact Us and Let Our Experience Help You Produce Results.

Learn more about CSC’s business process outsourcing capabilities.

© Copyright 2008 Computer Sciences Corporation | Privacy Policy | RSS