|
|
www.johnstark.com |
|
|
|
Re-engineering is a specific type of re-organization that aims to optimize the major business processes of a company, so that they take advantage of today's technologies and know-how, and meet today's market requirements. Typically, a company that is re-engineered won't have changed its organization for more than a decade. During that time, internal bureaucracy, turf battles, and cosmetic changes to the organization chart will have added unnecessary operations to the business. Externally, customer needs will have changed, and of course, technological capabilities (in particular, Information Technology) will have undergone revolutionary change. Clearly, there's a case to be made for taking a broom to the cobwebs, investigating if there's not a better way of organizing activities to meet customer requirements, and making the consequent changes. In practice, re-engineering will have a different scope in different companies. In some companies, it may only mean that the key business process for a simple product has to be identified, understood, and reorganized. Often, it will be more complex, and involve fundamental changes in the way a complex product with a long lifecycle is developed, produced and serviced by a complex organization. In this environment, typical of engineering and manufacturing companies, engineering data and processes are distributed over many locations. The complexity implies that the potential for improvement when re-engineering traditional engineering and manufacturing organizations will be great, but that the re-engineering task will be difficult. Among the chief characteristics of traditional 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 business. Their removal is an obvious target for re-engineering. As the barriers come down, it becomes clear that the activities that previously appeared to belong to individual departments are part of the overall product life cycle process, and that the information previously hidden in special languages is used throughout the product life cycle process. This is where EDM/PDM can play a role, as it manages a lot of this information, and many of these processes. EDM/PDM is the type of system that doesn't really fit in a traditional organization. Its real benefits come when it is used cross-functionally, a difficult objective in traditional departmental organizations. EDM/PDM can work well in a re-engineered environment, but is not a tool to be used to re-engineer the organization. Re-engineering changes the way a company works. This implies changing the way processes fit together, changing the way people work, and changing the way systems fit together. Just implementing an EDM/PDM system won't make these changes happen. Progress must be made with these changes before implementing EDM/PDM, otherwise the difficulties and problems associated with traditional organizations will impede progress to successful EDM/PDM. To carry out re-engineering, a company needs to have people who can think horizontally (along the flow of the product life cycle) instead of vertically (up and down the corporate hierarchy), since the principal aim of re-engineering is generally to reduce cycle time. The company needs people who understand how the product is produced today, and have the right mix and range of knowledge and know-how to be able to see how it could be produced differently in the future. It needs people at all stages of the process who can visualize how to work differently, and are willing to take the risk of working differently. To carry out re-engineering, a company needs to have most of the basic computer and communications systems and infrastructure in place. It needs to have a good understanding of the way the systems work, and the way they fit together. It needs to have built up know-how about the best way to implement systems, and to have developed ways of overcoming problems associated with new systems. The current systems should fit the current way of doing business, but not be cemented into place so that any attempt to modify them will lead to disaster. If the company doesn't have the basic systems, it needs to get them working before re-engineering. The company needs to have a culture that will allow it to go through a period of upheaval and transformation. There needs to be consensus at the top management level that re-engineering is necessary, and a commitment to carry it through even if it leads to some temporary problems. Top management must be willing to put a lot of time and effort into re-engineering. Middle managers must be supportive of the changes that will come. If they only pay lip service to re-engineering, while continuing to fight old departmental wars, the process will take much longer. Engineers and other participants in the life cycle must also support the re-engineering process. Most important of all, perhaps, from the point of view of Engineering, is that the company's engineering activities need to be well-organized. Some of the hierarchy should already have been removed from the organization, leaving it fairly flat, and allowing information and work to flow horizontally through it. The engineering process, and the other processes that use engineering data, need to be well understood. Process improvement should already have been carried out in engineering and other life cycle processes. The most appropriate engineering techniques should be in use. Concurrent Engineering should have been adopted. Team working should be generally accepted throughout the organization. Product structures, and related data structures, should have been clearly defined. Computer systems should have been implemented to support the engineering process, and integrated where appropriate to make data available to the people who use it when they need it. The IS organization should no longer see itself as a brilliant but long-suffering group that unfortunately has to work with the technologically-retarded rest of the company, but as an organization that provides support for the product life cycle. Most companies will find that they don't meet all these requirements, but that doesn't mean that they can't improve. It just means that they have to get themselves into better shape before full-scale re-engineering. Before embarking on re-engineering, companies should look back over their recent history to understand to what extent they have been able to change in the past. Is there any reason to believe their future behavior will differ from past behavior? If everyone behaved the same way in the next twelve months as they had over the last twelve months, would re-engineering succeed? Has top management been heavily involved in changing the operations of the business? Have middle managers demonstrated that they really want change? Loose talk of using EDM/PDM to re-engineer the business should be discouraged. Re-engineering is difficult, and should not be mixed up with other projects. Implementing EDM/PDM is also difficult. Trying to do the two together will probably lead to disaster. |