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