The Middle Way

by John Boyd

BPR sounded plausible, especially for bureaucracy-laden organizations. It even worked wonders in some rare cases, although it never went as smoothly as planned. Had the managers and employees who escaped BPR's downsizing been reprogrammable robots, BPR might have been widely successful. Unfortunately, the human staff were too frail to cope with the drastic changes demanded of them.

Revolution or evolution?
"It was too radical," says Augst-Wilhelm Scheer, founder of IDS Prof. Scheer, a Germany-based IT (information technology) consulting and enterprise software company. "It could be successful, but you risked losing everything." So over the years, a more realistic approach has emerged: the evolutionary method known as Business Engineering, which advocates optimizing what is working and changing what is not.

Business Engineering has something in common with the Japanese concept of kaizen, or "continuous improvement," says Scheer. But it goes further by centering in on using IT to streamline, redesign, or change an enterprise's processes. By process, here, we mean a series of activities that generate value for the organization -- for example, building a product, delivering a product, and billing a customer for the product -- rather than the multitude of individual tasks that make up each process.

Driving Business Engineering is packaged software called Enterprise Resource Planning (ERP) that can be used to run most business processes. Along with client/server, ERP provides the means of distributing information throughout an enterprise to where it can be most effectively used, thus helping it become more flexible, responsive, and competitive.

ERP also integrates all the information used in these processes, automatically updating it as changes occur. This data integration means that Production knows what's happening in Sales and Marketing, while top management knows what's happening everywhere. ERP provides the same look and feel throughout the enterprise, whether the user is an accountant in Osaka or a salesman in Oslo.

Custom vs. packaged
Contrast this to the time-honored way of a company custom-developing its own software for each function, such as accounting. While these independent systems don't talk to each other so well, the advantage is that a business gets code that suits its working style nicely. That's something rarely matched by a generic package written for the masses.

Custom-built was the norm in US and European companies up to the mid-'80s. But there it has gradually given way, first to function-specific packages, and now enterprise-wide ERP software from vendors like SAP, Baan, Oracle, People Soft, and -- more recently -- Fujitsu, with its Glovia software.

The same changeover has yet to happen in Japan and much of Asia, though the process has begun. According to a survey conducted by the Ministry of International Trade and Industry, custom-ordered software in Japan accounted for 86% of all software development in 1996.

"But [Japan] can't continue in this way," says Scheer. "The cost of packaged software -- even with consulting charges included -- is just 20% that of custom-developing your software." Packaged software is also updated faster, to include innovations that help companies address changing markets. "It's almost impossible for a company to keep up with the developments in packaged software when it develops its own software," says Scheer.

The modular approach
Nevertheless, many Japanese companies are still reluctant to change their individual working ways to suit the dictates of a foreign software package that doesn't properly accommodate Japan's business culture. So what's the answer? Scheer says there is a middle way between dependence on custom development and the wrenching move to generic packages.

While each Japanese corporation may have its own way of going about things, the fundamental business processes are the same as anywhere else in the world. They still need to make things, sell them, then bill their customers. IDS Prof. Scheer, which provides front-end graphics modeling tools to design business processes for implementation on ERP, is developing component software that will let a company turn off unwanted functions in SAP's popular R/3 ERP software, and at the same time integrate new custom-developed functions into R/3's reference model. This is being aided by SAP's and other ERP vendors' movement to an open object-oriented component solution that will facilitate this mix-and-match answer.

Eventually, says Scheer, companies will buy ERP components from several vendors to use along with their own modules. The result, he says, will be "a real Japanese-oriented answer."

John is still looking for a middle way between fail mail and snail mail. If you know of one, you can try contacting him at boyd@gol.com.

Back to the table of contents