SAP S/4HANA and the Future of SAP PLM

SAP recently released its most ambitious software application in recent history – SAP Business Suite for HANA, or SAP S/4HANA, which is an amalgamation of the HANA platform and the Business Suite. Though we had the Suite ‘on’ HANA earlier, S/4HANA differs in that it runs only on HANA and has been optimized and (I believe) significantly rewritten for it. The current version just has ERP (and PLM) as far as I could understand, but the vision is to have SCM, SRM and CRM as well in the same application server, eliminating the need for all middleware between these components.

Following points immediately come to mind:

1. Database neutrality has been a strong point so far for SAP. S/4HANA departs from that principle. This may give jitters to some customers, as database migrations are not as easy as one would like to believe, and there is the additional question of vendor lock-in. The first question doesn’t arise for customers (especially in SME segment) who are going for ERP for the first time, or are migrating to SAP from, say, Oracle, since they have to migrate database anyway. As for vendor lock-in, that is a fact of life in the ERP world
2. Two lines of code: SAP says it will support the existing Business Suite till 2025. This means that till then they will need to maintain 2 sets of code – the ‘anyDB’ version, and ‘4HANA’ version. Both of these will compete for investment internally at SAP, who will have to put a significant marketing dollars in the newer solution so as to justify its development further
3. Multi-tenancy: It remains to be seen how this really works. If it turns out to be as good as other modern SaaS applications that we’ve seen, then SAP will finally have a home-grown  winner in the cloud

 (Image courtesy: SAP)

What does the launch of S/4HANA mean for SAP PLM? A lot. First of all, SAP PLM has always been targeted at the installed-base of SAP ERP, and any gains for the latter would directly impact the market for the former. Secondly, from a technology perspective, SAP PLM has always been embedded within ERP, a fact that sometimes works against it when prospective buyers from engineering/R&D compare it with competitor products that are independent and therefore more under ‘their’ control. This is a battle of perception, which will be easier to fight when SAP aggressively goes to market with its ‘all-in-one-box’ vision, targeted at higher echelons within the customer organization. How far it is going to succeed, only time will tell.

How will S/4HANA shape SAP PLM as a solution? Potentially, in multiple ways. First of all, PLM will benefit from the HANA database and we can expect better solutions on Product Development Costing and even more contextual analytics. The existing functionalities could improve in performance. Newer functionalities could potentially be rolled out faster. I expect new functionalities to be delivered in the Fiori UI, and there will also be a gradual move to Fiori for the entire solution. This may cause some disruption, just as the transition to Web Dynpro did. I am sure the two UIs will coexist for some years to come.

SAP S/4HANA is also being offered as a multi-tenant solution in the cloud, and if SAP has thought through the technical impact of this on the PLM solution (content server integration, front-end components like CAD connectors, etc.), it will mean SAP PLM is finally being offered as a cloud solution (as part of ERP, that is).

All in all, I am very optimistic personally about the success of S/4HANA, and its positive impact on SAP PLM. I am especially happy that SAP will now hopefully talk more once again about applications than the platform – having now created the best platform that a great enterprise application deserves.

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!

BOM Redlining: Adding Colour to Your BOM!

BOM Management is without doubt one of the fundamental components of PLM. So much so, that BOM Management is not discussed as a separate functionality or module at all, when we talk about SAP PLM. Part of the reason could be that the functionality is mostly already present in ERP, and therefore can  be readily consumed by PLM users. Nevertheless, SAP PLM does have something in addition - BOM redlining! This interesting tool came about with Enhancement Pack 6, and the good thing is that it is almost entirely out-of-the-box, i.e. it doesn't require any special configuration.

So what exactly is BOM redlining? Imagine a BOM with most items in the familiar grey/blue colour, but some standing out in red or green. What could it be? Now think of the word redlining - it typically means adding a transparent layer over a drawing, etc., and writing something over it. Right? So there you are - BOM redlining lets you create a layer over the original BOM where you can make changes without changing the underlying BOM. You create redlining to suggest changes to a BOM such as addition or deletion of items, changes in quantity, etc. Depending on the changes you are suggesting, the items become red, yellow or green. The redlining can then be reviewed by someone and approved. All that you have to do then is click on Apply button, and voila! the original BOM is changed as per the suggestions in the redlining. You can even insert items for which you haven't yet created material masters. For that you have time till you are actually applying the changes to original BOM.

When do we use BOM redlining? One may think that question is already answered - whenever we plan a change in a BOM, we can use this feature. But there is a catch. What if you are using CAD integration? Would you implement a change in BOM through just the redlining without making any changes to the geometric models in CAD? This may be possible for some items, for example, consumables and variable length items. But in majority of the cases, one would imagine that a change in BOM would necessitate some or the other change on CAD side. In this scenario, the change must start with the CAD model and copied to the engineering BOM from within Engineering Control Center. For recording a suggestion, you can always use the comment option in the viewer. Incidentally, that is also called 'redlining'. Should we then use BOM redlining in process industries? Not really, because there the changes would first be implemented in a recipe. I can think of 2 scenarios where BOM redlining can be used. First, in complex multilevel assemblies, there could be some subassemblies that are not maintained in CAD. Second, for changes in manufacturing BOM which are done independent of engineering BOM. You make such changes in mBOM and then in Product Structure Synchronization (PSS) decide intelligently which of these changes should be accepted or overwritten in the next round of BOM syncing.

You can create a redlining for a BOM by clicking on the 'Redlining' button in the BOM screen. But matters get slightly confusing here. You always land at the default redlining that is called REDLINING1. You need to click on the 'Create' button to create a new redlining which then becomes available via a dropdown. I think this is not very intuitive and hopefully we will see some improvement soon. A BOM redlining can be added to an Engineering Record, though that is not strictly required.

Incidentally, BOM redlining has a very different meaning in some other (non-SAP) PLM applications. There it means comparison of a BOM between two revisions where the result shows up something similar to the redlining in SAP PLM, namely, rows of items with colours based on whether the items are present, absent or different between the two BOMs being compared. SAP PLM users can use the BOM comparison feature from ERP, which uses mathematical icons to show equivalence between rows of BOMs being compared, but it would be a good idea for SAP to reuse underlying code of redlining for a BOM compare function in web UI, in future. 

Finally, an interesting titbit: If you look at IMG for BOM redlining, you realize that it is a special case of a generic object called redlining. Which means you can extend redlining function to other objects. But SAP strongly recommends against using it for any other standard objects than the BOM. All you have in IMG is a couple of BAdIs with standard code, which you can extend, for example, to add fields to be displayed, etc. 

Do share your thoughts!

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?

SAP's Engineering Control Center - A Step in the Right Direction

Recently SAP announced it has acquired the Engineering Control Center from DSC Software AG, and the new solution will replace the old CAD Desktop interface for integrating CAD applications with SAP PLM. Engineering Control Center, or ECTR as it is generally known, was available as a partner add-on from DSC. By acquiring it and replacing CAD Desktop with it, SAP has achieved many objectives - dramatic UI improvement, significantly improved functionality, and a definitive roadmap for the future.

Let's look at these 3 aspects in detail. First of all, the ECTR is refreshingly better on the UI front as compared to the ABAP dynpro-based CAD Desktop. The layout is more modern with drag-and-drop feature that helps you achieve in a single move what would otherwise have taken several clicks and screens. It uses a familiar way of organizing objects with a folder structure on the left and object detail/preview panes on the right. SAP's 3D Visual Enterprise is embedded in the preview. Context menus and multiple icon bars provide alternative ways of carrying out different actions.

On the functionality front, there are many new improvements. ECTR provides a window for your workflow inbox, and also alerts on the objects you choose to keep an eye on. This should allow at least some design engineers to completely bypass the NetWeaver Business Client (NWBC) based UI for PLM, and work completely within ECTR. There is a demo video on YouTube that shows a new object called Change Process which is similar to Engineering Record, but appears to be a coordinating object over several Engineering Records. It is not yet clear if this is an out of the box feature that customers will get when they buy ECTR licenses from SAP, or something they will have to purchase from DSC as an optional add-on. In any case, it is an interesting concept. There are situations where changes have to be carried out in products that are owned by different owners, each of whom would like to have their own Engineering Record to carry out the changes, and yet the statuses of these ERs have to come together somewhere. Many customers have done custom development, especially in the PPM solution, to somehow achieve this. A standard functionality on this will definitely find many takers.

Lastly, SAP says it plans to enhance ECTR to cover not just mechanical CAD applications but also ECAD, embedded software, simulation engineering, and so on. This adds a significant strategic dimension to this acquisition. As of now, it is not even clear whether the new ECTR even supports all the mCAD applications that the CAD Desktop supported. However, since SAP has made the strategic decision in April 2014 itself, the integration partners would have already started their work. It would also be interesting to see if the announcement triggers interest among newer partners to develop connectors to individual CAD applications. In such a scenario, customers will have a wider choice.

All said and done, it remains to be seen how popular the new interface becomes. There is very little clarity as yet on pricing - whether ECTR will come bundled with PLM licenses and customers only have to buy licenses for connectors to individual CAD applications, or they have to pay for ECTR over and above connectors and PLM application licenses. It is hoped these details are made available soon. Pricing is a sensitive factor in emerging markets, and it is hoped SAP goes for an aggressive pricing and targets for volumes that are waiting to be tapped within their ERP installed-base.