KUKA, which is headquartered in Augsburg, is one of the world’s leading suppliers of automation solutions. KUKA offers customers everything from a single source: from robots and cells to fully automated systems and their networking. The company, which was founded over 120 years ago, employs around 14,200 people worldwide and generated revenues of 3.2 billion euros in the 2018 financial year.

The first step in the company’s transformation program – “Power ON KUKA 2020″ – was to standardize the process and system landscape in the engineering-to-order (ETO) sector. ETO is the term KUKA uses to describe everything relating to the development of custom-built production systems for the automation of manufacturing processes– in contrast to its configure-to-order (CTO) business involving robotic components and systems. The PLM migration project was driven first and foremost by the ETO sector, as Project Manager Matthias Binswanger affirms. However, the project also had to be synchronized with the consolidation of the global ERP landscape that was taking place at the same time.

KUKA previously had a very heterogeneous ERP and PLM landscape, which was partly due to the increasing scope of the group structures. For example, the ETO specialists in Augsburg worked with a local SAP instance and an older version of the former Eigner system, Oracle Agile e6. After an in-depth system selection process, KUKA decided to implement the Teamcenter PLM system from Siemens Digital Industries Software as the global solution for all its ETO locations.

Teamcenter is intended to support the future product engineering process, including functional engineering, manufacturing process planning and simulation, as well as control engineering change management. To do this, it has to be familiar with the relationships between the mechanical, electrical and fluid components of the functional units (for example valves, sensors and their processes), which were mapped in a separate application in the old world. Changes are part of the ETO sector’s everyday business because the systems are often designed before the products to be manufactured on them are fully defined. “One major challenge is the complexity that results from the sheer volume of changes to thousands of components,” explains Binswanger.

PLM implementation was already underway when KUKA launched the parallel consolidation of the heterogeneous ERP landscape in order to give greater transparency to its project activities. The simultaneous changeover to SAP S/4HANA considerably increased the complexity of the PLM migration, as Binswanger explains: “To introduce the new solutions, we made use of a clear project control mechanism with a flexible, multi-stage project structure that did not previously exist in this form. This went hand-in-hand with changes to the engineering processes and methods, which in turn had repercussions for the PLM landscape and therefore also had a big impact on PLM migration.”

To migrate the PLM system, the project team called on the services of the experts from PROSTEP, who brought to the project not only their PLM expertise and many years of experience in performing migrations but also PROSTEP’s proven OpenPDM integration platform. “There aren’t many companies that have certified connectors to Agile e6 and Teamcenter. As a result, there was really no real alternative to PROSTEP,” explains Binswanger. The PLM consulting and software company also assisted the customer during the cleansing of the master data prior to the start of the migration. When considering this step, it is important to understand that at KUKA materials, BOMs, etc. are currently created in the PLM system, or in both systems, and then published to the ERP system.

While the changeover to SAP S/4HANA was to follow the “big bang” approach, KUKA chose the soft route for its PLM migration, with the legacy and new systems temporarily coexisting. Although Teamcenter is the target system for the new architecture, the idea was to conclude any open projects in the old PLM environment. Binswanger explains that migrating them all in one fell swoop would have required enormous effort. Agile only works with documents, materials, BOMs and structures, whereas the CAD data is managed using a file-based approach or in containers. Teamcenter, on the other hand, provides interfaces to all the CAD systems, system versions and releases used at KUKA, which means that CAD files in different formats can be stored together with the materials for the first time.

Direct synchronization of the PLM data

The changeover to SAP S/4HANA and the temporary coexistence of the two PLM systems meant that the migration resembled a billiards shot across three cushions. First of all, Agile e6 had to be updated and interfaced with the new ERP system so that materials and BOMs could be correctly linked to the new project structure. It was then necessary to connect the two PLM systems in order to achieve the cross-system synchronization of standard parts, catalog parts and other materials. Binswanger explains why it was not sufficient to simply synchronize them via SAP: “PLM data with no logistical relevance is not published to the ERP system in the first place. However, this data is important for the Teamcenter users so that they can re-use the materials stored in Agile.”

The OpenPDM integration platform provides the basis for PLM data synchronization. It is designed to transfer all the materials between the two system environments and not only the standard and catalog parts. PROSTEP adapted the Teamcenter connector a number of times in order to take account of changes in the data model. All types of document are now also transferred together with the PLM metadata. Automatic quality checks ensure that the documents meet the requirements of the Teamcenter data model. “We have an activity-driven application which automatically synchronizes the data sent to Teamcenter every five minutes, that is to say it creates new materials together with their attributes, structures and documents or updates modified ones,” says Binswanger.

Contrary to the original planning, KUKA decided to actively shut down the legacy system rather than simply phasing it out gradually. This allows the company to save on the high license and maintenance costs involved in operating two systems. In order to meet requirements regarding traceability, the documents relating to long since completed projects also have to be migrated to Teamcenter. Binswanger explains that in order to do this, it will be necessary to relax the quality requirements a little and store the documents uncleansed in a separate archive, where they can be accessed only for reading and printing.

Data selection and cleansing

Due to the simultaneous changeover to SAP S/4HANA, the PLM migration in Augsburg started later than planned but with considerably higher-quality input data. The project team took advantage of the delay to implement a clearly structured, documented OpenPDM-based process for cleansing the data. One clear specification was that, of the 3.3 million data records in the old SAP solution, only those materials that are relevant for future projects should be transferred to the new environment. Therefore, it was first necessary to identify the data that needed to be migrated.

On the basis of over a dozen criteria and taking account of various attributes, PROSTEP calculated the so-called Total Article List (TAL) from the 3.3 million data records in SAP and Agile. The TAL is a list of all the articles that have been ordered or installed in systems, used for service purposes in recent years or are still in stock. It now comprises “only” 1.2 million articles. According to Binswanger, PROSTEP’s ability to resolve the structures and identify the components for any given article is of decisive importance.

The TAL controlled not only the big-bang migration of the SAP data but also acted as master for the selective cleansing and migration of the PLM data. In particular, the repeat parts (standard parts, purchased parts, semi-finished products, etc.) had to be augmented with additional data and classified before being imported into Teamcenter. To do this, KUKA used the software classmate from simus systems together with other solutions. OpenPDM controlled the entire cleansing process, from the extraction of the data to manual or automatic cleansing through to validation of the results, and also generated the corresponding quality reports. A total of approximately 80,000 articles passed through one or other of the programs in the “data washing machine”. Only the data that ultimately met all the quality criteria was automatically imported into Teamcenter.

In Augsburg, SAP S/4HANA, a new Agile version and Teamcenter all went live on the same day. An important milestone for KUKA. According to Binswanger, PROSTEP, its OpenPDM software platform and its expertise played a key role. KUKA successfully took advantage of the migration project to cleanse its database of unnecessary clutter.

The Teamcenter application was continuously further developed after the go-live. This repeatedly required adaptations to OpenPDM, which PROSTEP implemented in agile sprints. One major challenge was to migrate the documents from ongoing Agile projects because the data models in the two systems are very different. The last hurdle for the time being was the changeover to the new Teamcenter version 12, which required a change of integration platform version. Thanks to PROSTEP’s support, the company was also able to surmount this hurdle without any problems.