SAP PLM Recipe Development – How to do integrated Status and Change Management?

[Simon_Z]

This blog belongs to a series of blogs regrouped on the SCN page “SAP PLM Recipe Development for Beginners”.

PLM stands for Product Lifecycle Management. The lifecycle of a product is usually its design > creation > launch > optimization > obsolescence. These phases somehow have to be managed in the SAP system, for example with corresponding system statuses.

So the question arises: "How can you manage the lifecycle of a product, across all objects, with SAP Recipe Development? What are the system capabilities? What are the options?"

Before we can answer this question, we should first take a look at the most relevant objects that SAP Recipe Development is dealing with. Those are:

• materials
• specifications (possibly also lower level specifications)
• recipes (possibly also lower level recipes)
• BOMs
• optionally ECRs
• labels, print reports, building blocks, … are not considered at the moment

Let’s now take a closer look at those objects one by one. Let’s try to understand how the lifecycle can be managed individually on each of those objects.

Material

In the SAP Material Master is a field “X-plant material status”. This field is often used to manage the lifecycle of the material also in the context of SAP RD.

SAP Material Master - SAP GUI on the left and SAP WEB-UI on the right

Specification

As far as the specification is concerned here we have several possible ways of managing the lifecycle:

• using the identifier
• RD Specification Header Status
• EHS Specification Status

Specification identifier for status indication

If you want to keep it simple and if all you need is an indicator if your specification is “in creation” or “released” you might consider using an additional identifier for this purpose. It is simple but there is no control mechanism whatsoever on the specification and its usage.

  

EHS Specification Status

If you are working with different ratings, usages, regions, … the EHS Specification Status might be exactly what you need. This status does not only allow to control the behavior of the specification (“editable” when “in process” and “non editable” when “released”) but is also integrated with SAP ECN (Engineering Change Numbers). This allows you to manage the time span when a certain status is valid.

Example:

• On the 01.01.2012 the specification was set to status “released”
• From the 01.01.2012 till 08.08.2012 the specification is on status “released” which prevents users to change any attributes or characteristics in the specification.
• On the 08.08.2012 a user creates a new Engineering Change Number (valid from the 08.08.2012) and applies it to the specification.
• The status of the specification jumps back to “in process” and is editable again. The user changes “attribute 1” in the spec from A to B. Saves and changes the status to “released”.

• The specification now has two change states:
  • Change state before 08.08.2012  - with attribute 1 = value A
  • Change state after 08.08.2012 – with attribute 1 = value B

       

RD Specification Header Status

If you are mainly concerned that the specification status works seamlessly in conjunction with the recipe, you might be in favor of using the Specification Header Status. This status does not only dispose of status network which is based on the same configuration and integration logic the status of the recipe but also allows to make use of so called “attributes”.

Those attributes do not only allow to manage the behavior of the specification itself (e.g. editable or not editable) but also its usage in other objects (e.g. a specification on status “obsolete” cannot be used as a new input item in a recipe).

        

Recipe

When you create a recipe you quickly find out that the recipe does not have an own independent number range. Instead, the recipe number is composed of:

• Number of the output specification (FD-O3010)
• Recipe Alternative (000)
• Recipe Version (001)

So, in addition to the recipe status, which allows to manage the behavior of the recipe (editable, non-editable) and also allows to trigger so called recipe consistency checks, the recipe.

Optionally, you can also enable the use of change number for recipes of a specific recipe type in SPRO (ECN for Recipes).

BOM

The Bill of material also has a status and also allows the use of Engineering Change Numbers (ECN). When a Recipe is synchronized via the GSS-tool (GSS Recipe to BOM Synchronization) it is mandatory to use an ECN for this synchronization.

If a new recipe version with a new ECN (and corresponding new validity date) is synchronized to the same BOM (where the predecessor recipe version was earlier already synchronized), the positions in the BOM / Recipe which have been changed during this synchronization are automatically updated in the BOM.

ECR

The Engineering Record (SAP component PLM-WUI-OBJ-ECR) is an additional, optional object which allows to group several other objects in one ECR. The ECR is an umbrella which can contain several specifications, recipes, materials,… which are all related to the same product development project.

Without ECR, the product development project manager would probably list all objects (specifications, recipes, …) in one excel sheet. This excel sheet would be updated by his team members, a status per item would be tracked and they would send the excel file back and forth by email. Finally, after the successful ending of the project, they might try to save the excel file in a non-editable format (e.g. pdf file) and archive it somewhere. That is in short the function of the ECR.

And, yes, the ECR also has its own status field and status network. This status network does not only manage the behavior of certain field and columns in the ECR (e.g. “editable” on status “in work” and “not editable” on status “released”), but also allows to trigger events such as integrated workflows.

Lifecycle integration across all objects

There is no golden path, no right or wrong! What is needed is a thorough evaluation of the pros and cons of each of the above listed options.

Therefore, in every SAP Recipe Development implementation you have to ask yourself:

• How do we manage changes in general from a business perspective?
• Which of the above mentioned optionsare most suitable for us.
• Shall we use ECN? If yes, for which objects?
• Are we using the inheritance function for EHS specifications? If yes, did we consider the dependencies on status management?
• What is more appropriate for us EHS specification status or RD specification header status?
• Do we have lower level specifications which are listed or inherited to higher level specifications? If yes, what are the implications on status management?
• How do we use Recipe Alternative and Recipe Version in our specific case?
• How does our recipe structure look like? Are we working with higher and lower level recipes? What are the implications on status management if we are changing a lower level recipe in an existing recipe structure?
• Are we using ECR at all? If yes, what other objects are used in the ECR.

After those questions have been clarified, you will be a step closer to an integrated product lifecycle management for your SAP Recipe Development solution. And, you might also want to start thinking about Recipe Development mass change scenarios.