DAMA Part 3: Enterprise Information Structures and Challenges at the Engineering and Manufacturing Level

This week in my series of posts looking at the topic of DAMA I’m going to focus on enterprise information structures, then challenges at the engineering and manufacturing level. Don’t forget to read up on part 1 and part 2 before hand.

Enterprise information structures

The 1970s and 1980s saw enormous IT investment by electronics manufacturing companies, but with different software systems being developed for each part of the enterprise.

At a business level, the main investment areas were:

• Manufacturing resource planning (MRP) and enterprise resource planning (ERP),
• Engineering resources planning
• Customer relationship management (CRM
• Product Data Management (PDM)

There are still some issues concerning effective interoperability between these IT systems but, from the DAMA perspective, the critical issue is vertical integration. By vertical integration I mean how communications is achieved from MRP down to development, from ERP down to development, from CRM down to development and from PDM down to development. In other words, it can be viewed as a problem of how existing IT systems communicate vertically with the entire product development layer of processes, people, tools and methods.

If that wasn’t complicated enough, the fact that each R&D location may have different instances of the CRM, MRP and ERP systems, or different releases of the same basic systems; which mean that for example different component standards may exist –  puts the problem into a whole different league of Design complexity.

Implementation of the DAMA philosophy doesn’t involve throwing out all existing business systems, it involves finding effective ways to communicate with them to address the challenging “Work in Progress / Process” of Engineering teams.

However, but it will inevitably involve consolidation or harmonization of the EDA environment at the engineering level. Here, a quick fix using data translators is a recipe for disaster – not only are such translators never 100% accurate, but when errors are introduced they can be time-consuming and expensive to locate and its destroying all of “Design anywhere” – where companies can make use of 24 / 7.

DAMA challenges at the engineering and manufacturing level

At the electrical and electronics engineering level, component database symbols, geometries, technologies and rule sets need to be harmonized while legacy data still needs to be maintained. So does the whole product development environment, if consistent data is to be created.

Manufacturing data has to be centralized too, taking account of different assembly lines, assembly tolerances, soldering processes, geometry differences and CAM post-processes.

If the product specification is not accurately defined in great detail at the start, problems arising further down the line become ever more complex and costly to resolve – called “Cost of Change”.

Is it really too late to solve problems at this stage when considering the extreme high costs and delays involved?

The greatest challenge to accurate product definition is usually the lack of qualified information from other areas of the business. Often the information transfer that does take place occurs through coffee talks rather than through vertically integrated systems. In many instances development takes place largely in isolation and then the design goes through continual modifications to make it fit ever-changing specifications.

When a draft specification has been created, it needs to be cross-checked throughout every department that it will impact in some way: sales and marketing, product management, purchasing, production, after-sales-service…

Crucially, the product definition must take account of the capacity and capabilities of the design and development team. The limitations of business processes and tools also need to be considered. All too often, sales and marketing will promise customers something that the enterprise is either not capable of delivering at all, or not capable of delivering within the time frame demanded.

Finally, for the various departments, partners and locations of an enterprise to work together successfully there needs to be an agreed specification for how data is to be distributed – it’s one thing to have consistent data, it’s another to make sure that it’s always available in the right place at the right time.

Independent research by Baxton (formerly Deloitte Tohmatsu Consulting, Japan) has shown that although design itself makes up a relatively small portion of product costs, some 80%  of costs of the overall product are determined at the design stage. Also, 50% of the revenue that can be achieved through the sales of the product is determined in the design phase.

This is what makes design and development the cornerstone of implementing the DAMA philisophy. It’s simply not practical to approach the situation from any other perspective.

To drive DAMA from the design environment, a system such as that shown in Figure 3 needs to be implemented.

At the heart of the system is an Enterprise Component Database containing data on all components that may be found throughout the enterprise. This is dynamically linked to each division or department that in turn has its own related Divisional Component Database. A Divisional Configuration Management tool then manages overall integration with mechanical design tools, the divisional bill of materials (BOM) database, divisional EDA and data storage.

Once engineering harmonization has been achieved, vertical integration from engineering into other business processes through a well-integrated IT environment is the key to success. However, as the engineering harmonization is usually the most time-consuming part of the project, vertical integration work is usually carried out in parallel.

Finally, there needs to be effective communications links to subsidiaries, suppliers, EMS partners and others in the form of a‘B2B engineering portal’. Most companies already have business information portals, but not engineering portals that tie in design and development both across the organization and to external suppliers and partners.

An engineering portal such as Zuken’s ‘elecTrade’ enables greatly improved communications between internal and external facilities and partners in a secure and controlled way. A centralised database of all design data and parts lists can be accessed and updated over the web by any authorized personnel.

Next week

I’ll be back to conclude this topic to talk more about design driven product life-cycle management, how you can do it in practice by working with Zuken and the potential payback.