Initial Situation

A global medical technology company with over 50,000 employees in Europe, America and Asia has several relatively independent business units with independent product lines. Manufacturing is not very automated in all business areas due to low volumes and high product values. Lead times in development and manufacturing are very high due to administrative processes and regulatory requirements. Data is distributed in many places in the company. Information has different contents and change statuses at different storage locations, which leads to expensive delays of many months or even years, especially in the case of production start-ups and changes. Due to the high proportion of manual work, production can only be utilized to capacity in 2-shift operation. Parts production, which is centralized across all business areas, is a bottleneck in this respect, repeatedly hindering the assembly of components and also final assembly, with the result that customer orders are delivered late. Delivery times are unacceptably high for customers, so some customers turn to the competition despite an excellent image.

Another challenge is the safeguarding of expert knowledge. In one business unit in particular, knowledge relevant to success has not been documented in the company for many years and has been irretrievably lost with retirement and fluctuation.

At the start of the project, there is a productive PLM environment in only one of the business units. The other areas only use the PDM functionality. Only in centralized parts production is an MES system in use. Nevertheless, manufacturing is not very automated. All other areas operate without MES support. The ERP system is the central hub for data management and process control in all business areas. In this area, too, many work processes have to be supported manually. The potential for error is correspondingly high.

The company has no knowledge of the condition and exact configuration of the products on the market because the changes resulting from service calls are not documented. For this reason, there are always unsuccessful and expensive missions because the required parts for the service are not available.

Question
  • The market challenge is: how can lead times be significantly reduced, manufacturing automated and expert knowledge secured within the company?
  • How can the human error factor be supported in such a way that error costs are reduced?
  • How can inconsistent information be avoided and manual workflows reduced?
  • And how can information about the current condition of the products in use be ensured in the future?
  • How can the tool selection in the areas be reduced so that ideally only one tool with the task-specific information needs to be used per area?
  • How can multiple data entry into different tools be avoided?
  • How can the effort involved in maintaining a large number of applications and their interfaces with each other be reduced?
  • And how can the many alternative data and information repositories be eliminated?
Solution

All parties involved have recognized that data management must be standardized by aligning the future 3 main systems of the solution in the areas of ERP, PLM and MES, thus forming a closed loop. In the course of a tool consolidation, the functionality of the majority of all tools is to be integrated into these 3 main applications. The goal here is to ensure that a uniform data status is created for every piece of information in every system. The existing PDM systems of the business units will be unified and, as a first step, expanded into a fully-fledged PLM system that includes the disciplines of systems engineering, CAD data management, product data management, BOM management (engineering BOM and manufacturing BOM), release as well as change management and configuration management. In a parallel step, Material Management and Service Management (incl. Service BOM) will be added. The existing MES system will be rolled out to all business units and better utilized in all manufacturing disciplines. This also includes the introduction of digital work instructions and quality assurance in assembly using electronic torque wrenches, whose torque values are automatically stored and thus made traceable. For this purpose, it is necessary to transfer the Manufacturing BOM including product data visualization to the MES system. In addition, due to quality management requirements, the bill of processes (BOP) for each individual screw must be much more granular and therefore defined, maintained and then transferred directly to the MES system in the PLM area. The expensive and time-consuming definition and maintenance of the bill of processes (BOP) in the ERP system is no longer necessary. The bill of resources (BOR) is left in the ERP system due to personnel, fixed asset and procurement management. In the service area, operations are digitally documented in the PLM system and transferred to the service BOM so that the current configuration is known. In addition, the service BOM will serve as a digital twin for future add-on services. All 3 main systems are connected via interfaces and it is ensured that the data statuses remain consistent in all systems. Change management across all 3 main systems is realized via mutual triggering and a web client of the PLM system.

Implementation

For the architecture of the closed loop it is necessary to define the leading system. Since the ERP system has the most inventory data and already controls mission-critical processes, the ERP system is set as the leading system and the material number as the leading index in the other two systems. The CAD data connection is given by the already existing PDM functionality. In the first step, the engineering BOM is derived from the design BOM on the basis of an example product and the necessary adjustments are implemented. In the next step, the engineering BOM is overloaded with all possible variants and options and managed via a professional configuration management solution. The manufacturing BOM is defined via configuration management.

A parallel task is the development of the generic BOM in Systems Engineering, in which the specifications, certifications, material compliance and software development are to be integrated. The engineering BOM is derived from the contents of the generic BOM and the design BOM. Geometry data from the ECAD area is transferred to the Design BOM via the Mechanical CAD system. Product data from ECAD was generally not transferred. Company-wide standard parts management controlled via ECAD PDM is already linked to the CAD solution, as is the industry-specific classification solution for finding individual parts and components. However, this classification solution must be made available in the PLM system and workflows for creating new standard parts must be made available in the PLM system.

The existing connection of the PDM system to the ERP system will be extended further and further in the course of the project so that all processes that can be automated will gradually be implemented.

However, the project suffered a serious setback with the unsuccessful derivation of the Manufacturing BOM from the Engineering BOM, because this also interrupted the completion of the closed loop towards the MES system. The PLM supplier’s development work to solve the root cause took 2 years and the project was frozen during this time. The resumption is still ongoing and further progress suggests that the planned solution may eventually be implemented.

Project Method

The project was set up in an agile manner from the beginning and scaled up to program level using SAFe. Involved members of solution and control teams received exemplary training and were supported by experienced Agile Masters. For me, it was my first exposure to the SAFe scaling framework. Solution teams have worked with a mixture of Scrum and Kanban (Scrumban). A sprint cycle covered 2 weeks and a product increment covered 5 sprints. The 5th sprint was used for concentrated bug fixing and for the preparation, execution and follow-up of the PI meeting. A business analyst assisted each of two business units in defining requirements and trained members of the business unit teams. Requirements determination was carried out at the beginning using an MVP and subsequently with the current release in each case.

Challenge

The independence of the business units led to very different project support, up to and including refusal. While the first business units set standards, latecomers had to slog through an elaborate change management process, further reducing the hardly existing motivation. Leading business units have defended their solutions to the maximum extent possible in the event of change requests because they were already in productive operation.

The company did not prepare employees from the specialist departments of larger business units (especially latecomers) for the changes using necessary HR programs. As a result, neither an adjustment of the corporate processes nor a development target planning for the affected employees took place – let alone the then necessary target conversations with the employees. For this reason, these business units and their departments did not release employees for solution definition. The solution was therefore determined by means of a process mapping of value stream analyses with the target processes. Employee acceptance could never be established. On the other hand, the advancing business units formed departmental project teams with experienced key users and presented goals, which were then developed by project team members, validated in the departments and ultimately introduced with great acceptance on the basis of pilot projects.

Using the ERP material number as a part number in the PLM system caused important PLM standard functionality to stop working. Reason was that the part number of the CAD and product inventory data in the PDM area (Design BOM) differed from the new part number of the Engineering BOM (material number from the ERP system). In the overall architecture of the closed loop, however, this was the lesser evil to be accepted.

Both the PLM system and the MES system have not yet provided the necessary functionality during the project. The PLM system could not visualize legacy data correctly because either the absolute “or” relative transformation matrix was available in the legacy data. The visualization of the assemblies in the logistically re-sorted Manufacturing BOM was therefore incorrect. Enrichment of legacy data was impractical because it was frequently reused, changing in different versions, and the result of enrichment across multiple version levels would have led to an unacceptably poor result. Also the handling of additional quantities compared to the design data such as e.g. for standard parts (e.g. mounting kits) was an unexpected challenge. For this reason, it was not possible to provide a visualization of the production order from the Manufacturing BOM into the MES system in the first attempt. As a result, neither the digital work instructions nor the quality assurance solution could be put into operation with the electronic torque wrenches. Instead, as before, the Manufacturing BOM had to be derived from the Engineering BOM from the PLM system without visualization in the ERP system. As a result, the bill of processes (BOP) was not generated in the PLM area as originally planned, but in a slimmed-down form in the ERP area, as before, and then passed on to the MES system together with the resource bill of material (BOR). The intended optimization of production was not possible at that time. Only in a 2-year later step could this challenge be solved by the PLM provider and thus open the way for a direct transfer from PLM to MES.

The MES system was designed as a standard system with different industry solutions. However, the company had combined all manufacturing disciplines, including single-part production, electronics manufacturing and assembly, into one facility and must adhere to strict compliance requirements. Nevertheless, the existing MES system is to be adopted on the basis of the implementations already carried out. It was only at a late stage that the provider of the MES solutions agreed to adapt the software to the customer’s needs in the project in such a way that almost all requirements could be met. In the meantime, the company had already started implementing the MES solution included in the ERP system. The outcome is open and the goal of closed loop manufacturing according to the original objective has not been achieved to date.

However, a new platform strategy from the PLM and MES provider reveals a promising solution.

Project Information

Project Duration: 1.5 years until project freeze

Project Team: start with 1 solution architect, 18 members in 2 teams just before project freeze

Project Budget: commissioning at 3-month intervals based on project success

Conclusion

This project is a good example of the fact that exemplary project preparation and project implementation do not guarantee a positive project outcome. Agile project methods are always recommended when the path to the goal is unknown. This also includes that solutions and tools necessary for the project goal are not available. That’s exactly what happened here. At the very end of the project, the project might have needed to be frozen more quickly to save budget and resources. In my opinion, this was the only point where the Solution Manager reverted to old behaviors of a planning organization and did not act in an exemplary manner by delaying the Freeze decision and hoping for a solution. In agility, a freeze or stop is not a failure, but an elementary component of success for optimized use of resources.

My Employer

My employer provided the solution teams for the PLM implementation, the business analysts and a solution architect at the solution level for the entire closed loop.

My Role

I had the role of Business Analyst in the project and was responsible for requirements determination, consulting with good practices based on the MVP, and solution determination together with the Technical Architects at the team level and alignment with the Solution Architect at the solution level. I conducted the requirements determination partly with customer project teams and partly on the basis of value stream analyses as well as process and data mappings derived from them, which were subsequently verified and adapted through several rounds of workshops. In addition, I trained the business teams for the application, created necessary training materials for it, supported the Technical Architects with data and process mapping, implemented some small requirements, took care of the coordination with the ERP team and supported the Solution Management with the preparation and execution of the PI meetings. I supported my Indian colleagues in settling in and dealing with the authorities.