Start Your Digital Manufacturing Journey: 4 Steps to Your Smart Factory
We have collected 4 dedicated steps to start your journey towards a smart factory!
Even if you are not a consultant or a developer, this article is for you, particularly if you are from the customer side. It may help you to establish some design principles and governance to ensure that the solution you are being delivered and you massively investing in includes best practices.
When designing a solution, I do not hardcode anything if possible! If you are a developer or a consultant, you understand what I mean.
This is what I call quick and dirty!
Quick because writing is straight forward, it does not cost much, and dirty because the value in yellow above, JAPAN, 10%, and 15% are internal constants to the formula. They cannot be changed easily, except going in configuration again, changing values and re-activating the IBP planning area.
Now let’s imagine you have 10, 20, 50 of these quick hardcoded things, disseminated in the design that includes maybe 500 to 1,000 key figures, you end up with a solution that is difficult to maintain and evolve.
Even worse, if your customer tells you, “We wish to rapidly change 10 to 12% for JAPAN and 23% for others”, this simple business request, full of sense, becomes a CR!! An IT change request, to be validated, tested, budgeted etc.
You probably see where I am getting at. With such definitions, you have successfully and efficiently created a frozen IBP design that can only be changed by means of IT tasks. The exact opposite of an agile solution business people request.
Let’s now imagine we do not want the values above to be fixed anymore. We wish to introduce parameters that can be maintained separately by you, the consultant, and even business people. If the latter decided to change something in future, it would not be an issue.
That sounds interesting, doesn’t it?
Going back to the previous example, we transform the given formula as follows:
At the same time, we state in a simplistic parameter table accessible to you and the business:
With this new setup, JAPAN receives 10%, others 15%, and if business decides to change country and rebates, they simply maintain the table entries. No change of key figures in the formulas, no transport, no nothing except testing indeed!
This is what I call a more agile design, although ideally, the genuine agile solution could also be business people directly maintaining the formula. But this is another debate.
Nothing yet in this regard. IBP being closed for any specific development (not cool), there are no ways to complement that gap with a robust custom development and a Ztable as often done in ABAP.
I have placed an Influence item to ask SAP to introduce a standard global parameter concept in IBP to avoid workarounds. Let’s see how it goes here.
From this point the article becomes technical!
For the time being, let’s get around the gap. Below is the solution I suggest to close this gap, even if it is not ideal.
Important statements are:
So, adding attributes is a touchy option, particularly if the IBP implementation already exists. That means changing master data types and integration jobs. Each solution has a cost; however, the proposed idea keeps this change as small as possible, although opening your design for 10, 50, 100 flexible parameters.
Adding attributes is not global to a planning area. Attributes are attached to master data types like product, product-location, etc.! Obviously, if we need a parameter that depends on Product Master, we can add this as an attribute to the Product Master.
Basically, we now have two options to extend a global design with many parameters.
We create a new master data type (MDT), say PARAM, made up of the many attributes we need as parameters, plus a key attribute.
Example based on previous figures:
With the Manage Master Data Fiori app, we maintain one single record of this MDT.
We insert the new PARAM MDT in our planning area, and we assign all attributes (parameters) to all our planning levels. Warning, we set the ParamKey of the MDT as a root attribute in all planning levels. If we do this in an initial IBP design it should not be an issue, although a little more to do. If this is for an existing implementation that also means a lot of change as all planning objects (PLOBs) have to be reconsidered with the ParamKey. As we have only a single record of PARAM, the root for ParamKey is unique and does not multiply the number of PLOBs.
From this point, all key figures in this design can use the parameters freely. Job done but costly!
With this option, I don’t wish to alter the PLOB structure (root) of the many planning levels. I wish to keep things slim.
The question therefore is: Which dimension is the most used one in IBP? Product, indeed!
What if I attach to the Product MDT just one additional attribute to be ParamKey identical to the one defined in the MDT Param?
What if I attach to all planning levels, the parameters defined in MDT Param; however not changing any root?
If you do so, the planning area activation fails with “PLOBID blabla ….failed” ☹
The trick is to create an intermediate Virtual MDT between Product and Param MDT, then attach to the planning area the Virtual MDT, not the simple MDT. By doing so, the root resolution is working and active. Full success!
Cherry on the cake, the ParamKey can be multiple, defining different parameter sets, without adding any additional PLOB.
I am sure you need a step-by-step guide to see things happening.
Step 1 – Create a new Master Data Type (simple), say DLEPARAM made of one key attribute and many parameter attributes.
Going back to our example: DLEPAREAID (key), COUNTRY, LOWREBATE, HIGHREBATE. You have no limitation and are free to add many other attributes with each one representing a functional parameter (alpha or integer, don’t use decimal). In the below example, I badly named the parameters Param1, 2, 3, 4. Better, you give them explicit names to help in reading the formula later.
Step 2 – Once activated you can already use the Manage Master Data Fiori App to maintain your parameters. Pay attention to creating records, at least one:
Step 3 – Add also the DLEPAREAID attribute to your Product MDT and set it as mandatory.
Step 4 – Create a Virtual MDT that links Product and Param MDT. Here, its name is DLEPRODPARAM. Because this is a Virtual MDT, IBP will automatically establish the link between products and parameters. This is the trick! As shown below, product and parameters are linked with the DLEPAREAID attribute.
Step 5 – Don’t forget to add to this MDT the parameters we want to use later.
Step 6 – Link this new PRODPARAM MDT to your planning area, not the simple DLEPARAM.
Step 7 – Finally assign the parameters and DLEPAREAID attributes to all planning levels that include the product dimension.
Result – You can now create keyfigures and formulas using parameters that can be changed freely in the Manage Master Data app.
Enjoy IBP!
We have collected 4 dedicated steps to start your journey towards a smart factory!
Discover the key challenges in pharma logistics for cell and gene therapies with insights from Camelot Management Consultants.
From manual effort and handling system complexity to focusing on what IT employees do best: keeping the technological backbone of the organization strong and efficient
We have a look into the challenges of a purchaser within a company and its respective challenges when it comes to (reference) data handling and the negative impacts insufficient measures have on daily work.
