SAP PLM for Process Industries: Packaging Matters!

Introduction

The SAP PLM solution for Process Industries has made substantial progress recently through enhancement packs, both in terms of UI and functionality. One area that may receive attention in future is how the solution covers product packaging. Process industries (PI), especially those related to consumer products (such as food and beverages, personal care, hygiene products, etc.), attach great importance to packaging design and a significant portion of product design efforts is spent on designing the packaging, artwork and labelling. They use specialized software to handle different aspects of this matter. There is a variety of software available to support the structural design of packaging (the so called packaging CAD applications), for creating artworks, and for ensuring labelling compliance. Different product groups within the same organization sometimes use different tools to accomplish the same thing. In general, such tools are preferred that allow maximum creativity, while integration is of secondary importance. This is understandable, but over time, the organization realizes that only an integrated process allows effective collaboration and shorter design cycles.

How does SAP PLM help?

Well, to start with, Recipe Development has a special specification category called Packaging that you can use for creating specifications that represent packaging items, and these specifications can be linked to material masters. When you add packaging specification in a recipe, it is automatically excluded from composition calculations, etc. You can store various properties of the packaging material in the specification, and this helps in searching for a packaging that can be reused. This is the basic functionality offered by Recipe Development. Still, we are leaving out two important aspects – the geometric design (CAD models) of packaging, and the artwork.

CAD integration

SAP recently announced acquisition of the Engineering Control Center (ECTR) solution that was previously offered by their partner, DSC. This solution replaces the earlier ‘CAD Desktop’. Can it be used in the context of packaging? Potentially, yes. But there are some gaps that SAP or their partners need to address before that. First of all, the ECTR needs installation of connectors specifically designed for the CAD application in question. These connectors are available for most popular mechanical CAD solutions (AutoCAD, Creo, SolidWorks, NX, Catia, etc.), but not yet for any of the popular ‘packaging CAD’ solutions. Another issue is – would the existing functionality of ECTR be sufficient? As of today, ECTR allows you to link document info records (that hold the CAD files) with material masters. Specification masters do not enter the picture. But SAP PLM for PI is all about specifications and recipes. Extending the ECTR to handle specification masters may be a possible solution, but it may also overcomplicate the tool. A really intelligent solution will link specification properties with document characteristics that can be ultimately derived from CAD. So, for example, if a box designed in CAD weighs 10 g, this info should flow from CAD to the linked DIR and then to the ‘weight’ property of the packaging specification. A practical solution would be to perhaps not use packaging specifications at all, and introduce packaging once basic MBOM is generated out of the recipe.

Artwork

The artwork for a product packaging is usually a file (or a set of files) that can be handled using existing DMS functions. Something lightweight like EasyDMS is most appropriate for the users of this department, who would want to spend more of their time in creative works in Adobe Illustrator or similar applications. But there is a catch. These applications are mostly run on Apple computers, and EasyDMS runs only on Windows! Secondly, these applications usually have their own ‘workflows’ which have to be suitably blended within the overall process. I am tempted to think out the box (package?) here. ECTR already has EasyDMS-like features (drag and drop an original file to create a DIR, for example). Also, ECTR being a Java application, should be able to run on an Apple machine as well. Can SAP create a lighter version of ECTR for this use case? Maybe they can, though it doesn’t appear to be on their near term roadmap.

Labelling

Labelling is where SAP PLM can play on its current strengths. The label creation functionality allows you to generate a label out of a recipe or specification, and then modify and enrich with additional information for regulatory compliance, etc. The label set (so called since it can hold multiple labels for the same recipe, each representing a different SKU and/or target market) is a technical object by itself, and can have workflows, statuses and links to documents. A very useful feature is the xml output that can potentially be used as input for artwork applications.  

What is my take?  

All in all, mapping the business process and objects in packaging represents a very interesting challenge for a PLM solution. SAP PLM has many pieces which fit straightaway into the puzzle, and some which need to be cut around the edges! Partners have a great opportunity of creating and selling a packaged solution around these ideas. Packaging, as I said, matters a lot!

A Serendipity Called Object Sets?

The most important point in the ROI argument for SAP PLM (or any PLM solution for that matter) is the reduction in product development cycle time. This reduction is achieved basically in 2 ways – by streamlining the whole process of creating and managing product definition, and by efficient reuse of available designs, knowledge-base and network. To be able to quickly find out existing objects that could be reused, we need robust classification and search functionalities, and SAP PLM has both of these. PLM Search has been likened to Google search for design engineers because of its ability of searching objects of different kinds based on a keyword or phrase. But is that always sufficient? Perhaps not. There are certain scenarios where you need more than a simple keyword search, and complementary features like Object Sets can play an important role in future, which is what I want to suggest in this blog.

Let’s first look at how the whole thing must have evolved. When you want to be able to find an object – a physical object - easily, you are expected to organize all objects nicely. So, on a shop floor, there should be ‘a place for everything, and everything in its place’. This is the first and obvious approach, even when it comes to enterprise software. You classify things (material masters, documents) based on various attributes and search the objects based on a combination of values for one or more attributes. But this approach has two problems inherent in it: Firstly, you must have a complex classification hierarchy and myriad characteristics to capture all possible information in a structured way, and then ensure that each object is classified properly within that hierarchy. Not a very attractive idea for a modern enterprise where the database just keeps growing every day with a lot of ‘unstructured’ information coming in continuously. This is where Enterprise Search, or PLM Search comes in. For every word or phrase you enter as the search criteria, it produces a limited set of objects which possibly has what you are looking for.

There is no doubt that this ‘cross-object’ search capability of PLM Search comes very handy in most circumstances, but does it cover all possible scenarios? Let us say, you are a bike manufacturer with 20 main models and 200 variants, and you want to make a list of all rubber parts in models exported to a specific market. How do you use PLM Search here? It’s quite easy to find which models are exported to that market – the sales folks will give you that data, or you can find through classification within product structures. Let’s say now you have a list of 25 product variants that are sold in the market in question. Separately, you can compile a list of all rubber parts that are used in all the models. Imagine now you have a list of 300 unique rubber parts. What next? Of course, someone can write an ABAP report that will explode the BOMs for selected variants and then filter them for rubber parts. What if such a situation occurs often? I think there is a potential solution – the object sets.

The object set is a feature that came with EhP7, and is currently available only in SAP PLM for Process Industries. With object sets, you can create collections of objects of your choice, and share them with others. One important use case is in recipe formulation where you can add an entire object set to a recipe instead of individual substances. As of the moment, object sets apparently do not support BOMs. But if they did in some near future, SAP could potentially extend PLM Search to work within object sets. You get the idea? In our example above, all one has to do is add the variants to an object set, and perform a search within. The result could be defined as a new object set that people could share with each other for augmenting with more objects. You could think of entirely new workflow scenarios where object sets interact with each other and with people.

Comments? Thoughts?