A FEW WORDS ABOUT

REENGINEERING





Reengineering was the fashionable way for companies to re-organize during the first half of the 1990's and the trend is expected to continue during the next few years. Reengineering aims to optimize the major business processes of a company, take advantage of today's technologies and know-how, and meet today's market requirements. It involves redesign of the company's processes and the application of Information Technology to the new workflow with the aim of obtaining competitive advantage.

Reengineering implies a major reorganization of a company's business processes with the objective of making very large improvements in customer service metrics such as reducing product development time by 75%.

Product development - before reengineering
Reengineering is particularly appropriate in companies with traditional organizations. Such companies have product development processes that are slow and expensive, and don't result in products that satisfy potential customers. Among the characteristics of such organizations are multi-level hierarchies, departmental empires, use of specialist jargon within these empires, walls built to demarcate departmental frontiers, and serial workflow through the departments. All these barriers slow down the flow of work and information.

In such an organization it takes a long time for a new product to go through the Marketing-Engineering-Manufacturing chain. First of all, Marketing defines the product. This doesn't take long because Marketing people are bright, and they want to get the product on the market before the competition. However, Engineering is over-burdened with far too many projects, so can't start work immediately on the new product. When it does get the time, it can't meet Marketing's requirements. It goes back to Marketing and suggests changes. Marketing has also thought of some changes, and the engineers try to develop something from the new ideas. When they have defined it down to the last detail, they pass it over to Manufacturing. Manufacturing can't produce the product the way it has been designed, and asks Engineering to change it. The changes will have such an effect that Engineering has to check with Marketing, only to find that Marketing has realized that additional functions are needed. The engineers see if they can develop the new, new idea. This iterative process continues until the departments eventually agree the product can be produced and released to the market. By then the product will be late to market, too expensive, and won't meet customer requirements.

Engineering data - before reengineering
For most of the product development process, information is all-important. It's all people can work with since the product doesn't physically exist. Yet in the traditional organization, information is not valued or managed the same way as other company assets.

The detailed ownership and procedures for each piece of information is difficult to resolve, and often it is not resolved. As a result, people do their own thing. If they are to be held responsible for a task using certain information, they want to have that information under their control. As most information is used by people in several departments, and each is held responsible for tasks using that same information, several people want to have the same information under their control. Each one invents their own rules on how the information is managed, structured, stored, and used.

Marketing creates product specifications and believes it is responsible for them. Engineering can't use them in the form it gets them from Marketing, so converts them to something else. Which version is now the official version? Can Marketing be held responsible for modifications made in Engineering? No, because it doesn't have authority over Engineering. Sometimes Engineering doesn't understand exactly what is required, so it takes a best guess. Then it finds that it has to modify its guess because Marketing wants to modify the original specification. It gets difficult when you start making interpretations of interpretations. Oh is that what you meant, Virginia? We thought you meant the opposite.

In the traditional departmental organization, everyone is responsible for their own work. When it comes to information, this means that each department structures the information the way that is most suitable for its own needs, uses the terminology that is most appropriate for its discipline, stores information on the medium that it finds to be most effective, and defines the information elements as a function of its own needs. This leads to the department working in the most effective way for its own needs, but creates problems when the information is transferred to another department.

The result of the departmental approach to using and managing information is that the product development process is slow, expensive and riddled with errors. All along the process, time is wasted, unnecessary overhead is added, and there is a lot of non-value-adding translation of information. Problems occur as paper is shuffled from one desk to another and from one department to another. On the shop floor, the result is expensive rework and scrap as the wrong parts are produced. Any transfer of information to a customer is scary beyond words - who knows what might happen?

The departmental approach leads to a lot of time being wasted as information is converted and transferred. Access to information is slow. There is always the danger that data will be lost. Copies of the same information differ, and time is lost in discussions trying to reconcile differences. Due to all the time lost with information problems, projects overrun. People can't find existing information, so there is little reuse of information - instead money and time are wasted as people continually reinvent the wheel. As the departments use different formats and structures of information, it is often simplest for them to transfer information on paper. Once on paper it can be destroyed, lost, or mislaid.

Product development - after reengineering
Companies reengineer because they are under intense cost, quality and time-to-market pressure as they are squeezed by rapidly advancing technology, demanding customers and aggressive competitors. These factors force them to decrease product development costs and overall product costs, reduce product development cycle time, and improve quality. To achieve this they have to reengineer themselves in such a way that high quality products can be developed very quickly in response to customer requirements. This means changing the company structure, optimizing processes, implementing crossfunctional product line oriented teams, breaking down barriers between departments, removing hierarchical levels, and allowing information and work to flow horizontally. Reengineering changes the way a company works. It changes the way processes fit together, changes the way people think and work, changes the way information is used and the way systems fit together.

Implementing reengineering
Reengineering is difficult and time-consuming. For it to succeed, a company needs to have a culture that will allow it to go through a long period of upheaval and transformation. There needs to be consensus at the top management level that reengineering is necessary, and a commitment to carry it through even if it leads to temporary problems. Top management must be able and willing to put a lot of time and effort into reengineering. Middle managers must be truly supportive of the change, and not just pay lip service to reengineering, while continuing to fight old departmental wars.

'Reengineering' is just one word, but to do it means all sorts of tasks such as rewriting job descriptions, modifying processes, introducing new reward systems, modifying work procedures, reworking computer systems, retraining, changing financial reporting, changing proposals and contracts, and changing supplier and customer relationships.

Engineering data - after reengineering
In the reengineered company, there is very little information flow 'up the ladder', and few barriers to 'horizontal' information flow. Engineering data is a strategic resource and its management a key issue. Improving the use, quality and flow of engineering information is a high priority.
Reengineering leads to many information-related tasks addressing the availability and use of information, the management of legacy information, access to life cycle data, information about customized products, information exchange with suppliers, information interchange with customers, exchange of information among team members, use of information by off-site team members, the productivity of information use in the business processes, etc.

So why reengineer before addressing EDM/PDM?
Over the last few years we've developed an eight-level model of the major components of the Engineering environment:

The components should be addressed top-down, starting with the market and customers.

Reengineering follows the same route. It's a massive effort in which the product development process, people, information and systems undergo fundamental change. The information flows and systems (including the EDM/PDM system) in place before reengineering are likely to undergo fundamental change reflecting changes to the product development process.

Rather than running the risk of implementing EDM/PDM, then reengineering and re-implementing EDM/PDM, there's a good case for reengineering first and then implementing EDM/PDM.

PRODUCT DEVELOPMENT WORLD | HOME | TOP OF PAGE

Copyright 1998 by John Stark