8/13/2019 Sap With Ippe

http://slidepdf.com/reader/full/sap-with-ippe 1/4

 

« SAP with GUIXT offline (funny movie) 

How To Get (or Keep) Your Rates Up »

To IPPE or not to IPPE, that is the question?

Ok fellow SAP’ler within SAP automotive, this is for you. 

I have worked at multiple client in the automotive industry using the SAP automotive solution. And we always

study to use IPPE or use BOM, routing, work centers, production resource tools. You do know what the IPPE is

right? A little refresher (skip that if have configured IPPE and worked with it):

iPPE is basically made up of abstract elements, which are especially shaped in Customizing

for specific applications. The basic elements of iPPE are:

Nodes

 Variants

 Alternatives

Relationships

The applications of iPPE are:

Product structure for reproducing BOM data

Process structure for reproducing routing data

Factory layout for reproducing production lines

8/13/2019 Sap With Ippe

http://slidepdf.com/reader/full/sap-with-ippe 2/4

Additional applications include:

Concept

Early Engineering

Production Resource

In a nutshell, the IPPE is a node based structure (located in the PLM module) that can "integrate" with VC and

the Project system. I have worked at clients, configured and set-up IPPE, loaded data and the client asked for a

study to use IPPE on not to use IPPE. In short these were our main findings:

1.   Assuming one end-product has 15,000 to 30,000 parts and VC (Variant Configuration),

multiple alternate production lines, work centers, routing, alternate parts (dependent on VC

or other selection criteria) is used together than an IPPE structure would have ~800,000 to

1,000,000 lines (or more). 

2.  The maintenance of an IPPE is more complicated (find a typo or logical mistake in 1 million

lines) 

3.  The use of ECM (Engineering Changes) added to the IPPE structure. In easy terms, with each

ECM you add lines with a valid from/to if you have many ECM dependency over a period of a

 year with 1,000 ECM’s. These ECM’s may have to create multiple lines based on VC, line

design or alternate parts selection (could be easily an other 1,000 per ECM). That would addan other 1,000,000 lines to the existing IPPE. 

4.  The legacy system of the client is more BOM "structured" than IPPE like and the conversion

from legacy master data into SAP was easier into BOMs, routings etc. than into IPPE 

5.   We encountered "buffer issues" (memory) and load timing issues with loading mass IPPE

structures 

6.  The advantage in using IPPE: 

7.  line design can be integrated into the IPPE structure  

8.  MRP with Rapid Planning Matrix is faster 

9.  Fast backflush can be used (faster that "regular" backflush) (However at the end we still used

the fast backflush through an interface with a standard BOM) 

10.   You can use a graphic to display your model using IPPE (useful on the top levels, but

confusing at the lower (mass data) levels) 

In short look into YOUR requirements and do a study/assessment before you invest multi millions in that next

purchase and/or installation. At the end the clients decided not to use IPPE but use standard BOM, routings, VC

etc.

Some details about the alternative:

8/13/2019 Sap With Ippe

http://slidepdf.com/reader/full/sap-with-ippe 3/4

1.  If you are using BOMs, routings, VC for a client that need to backflush lesser end-products

 without the the backflush has to create mass goods issues for the parts you will not have

problems. Off course you still need a powerful SAP system, however you d not need to make

any changes and standard SAP can be used.  

2.  If you need to use BOMs, routings, VC for a client with mass data that creates backflushes in

short intervals than you may need a more powerful backflush. In that case I used:  

3.  Still standard BOMs, VC etc. however the rapid backflush (from APO) was used and

integrated into SAP. This was done together with SAP (and that is my recommendation, don’t

try that by yourself), they build an interface function that "translated" the standard data into

the structure that is used for the rapid backflush transaction. 

4.  The rapid backflush is really fast (much faster than the standard backflush). The rapid

 backflush is using a different way to backflush, it "collects" data from multiple backflush first

and analyse if there are parts that are common in multiple backflush’es than the backflush

summarize and creates the "real" goods issues for the parts.  

 What experiences do you had about "IPPE or not IPPE"? Any takers in regards to IPPE or BOMs? Let me know.

Explore posts in the same categories: Uncategorized 

This entry was posted on February 4, 2009 at 4:38 pm and is filed under Uncategorized. You can subscribe viaRSS 2.0 feed to this post's comments.

You can comment below, or link to this permanent URL from your own site. 

2 Comments on “To IPPE or not to IPPE, that is

the question?” 

1.  Savas Yazici Says:

February 11, 2009 at 7:38 am 

Hi Ralph,

What a wonderful summary! We need more… 

What I believe is, IPPE -although as you have mentioned, has certain complexities- would be the best modelling tool

within the near future of SAP, especially for the complex product structures. Let me add one more point about IPPE

– PM (Plant Maintenance) integration. There is a sub-module of PM (now at the core but previously was existing

only for IS-AD) called configuration control management CCM. By CCM, one may check the “legitimacy” of the

existing actual configurations with the baseline configuration shaped by IPPE Product Structure. This is very helpful

if you have a vast product structure with a requirement of checking whether your pieces of equipment in operation

has a true configuration on it. Let me give a basic example: assume that you have a plane product structure with

several hundred thousand parts on it. And assume that regularly you receive changes on the product structure (i.e.

8/13/2019 Sap With Ippe

http://slidepdf.com/reader/full/sap-with-ippe 4/4

don’t use that part any more, or you can use this part interchangeably with that one etc.). Every change should be

checked with the real, actually existing planes. This is very hard to manage. Therefore what you do is introduce

several links/relationships within the real, existing planes (pieces of equipment or functional locations for some

cases) and then do the checks whether these new changes apply to your plane and whether you need to replace

some parts or not.

Therefore it is very helpful to have a standard product model which “controls” the real, actually existing systems in

operation.

What is missing or what is a “nice to have” functionality is (to my knowledge still in SAP ECC 6.0 it does not exist in

terms of an integrartion with IPPE) to have IPPE a standardizing tool for maintenance organization (Work centers)

and maintenance task lists (like your process models). And also it would be very nice to have a modelling tool (via

IPPE) that may help the users to have mass changes in their maintenance plans. For this latter requirements, there

is a solution proposed by SAP but it is using DMS and it is much more primitive than IPPE may provide.

Another possible area which may be improved is an integration between IPPE-PS-PM. As you know, we are using

PS-PM integration for large scale maintenance jobs. Even there is a new tool called Maintenance Event Builder for

this purpose. So for the near future, if we have a link between the three modules (IPPE, PM and PS), then we may

also standardize these large scale maintenance jobs. All these nice to have functionality was developed with the

help of tolerant ABAP’ers in one of my previous projects. This required too much effort and costed a lot which I do

not think most of the companies may be willing to invest.

Kind Regards

Savas

p.s. By the way, I am becoming a fan of your blog. So please continue writing.

Reply 

2.  Sreeni Says