It would be great to see a table of requirements, matching the customer's view of what is required with SAP's view of what they think is required and hence what they support .... Jan-Peter Oeser, July 5, 2005 Copyright © by Peter Illing
For those who were at this year's spring CWG in Germany, as well as for those who were unable to make it, it might be interesting to hear what some of your fellow members took away from this illustrious gathering.
Here the opinions of an "old rabbit" (the meaning of this horrid Germanism: old rabbits haven't been caught, so they must be smart ).
Jan-Peter Oeser, Siemens AG, Leipzig, has spent some of the best years of his life helping Siemens to integrate the IPC into its way of doing business. He has worked on product modeling, of course, but think about this: he has spent a lot of time with product engineers as they do their CAD drawings. While they do that, they also create tables of options, of specifications, ok let's be blatant: they are creating tables of characteristic values! Jan-Peter rips these tables out of their hands while the ink is still drying, and he takes them straight to the Siemens' product modelling workshop. Why would he do such a thing? For those of you who were there, just remember how often the topic of tables and constraints came up at this last CWG. This point is so important that we will come back to it many times. And at the other end of things, he has been known to prowl among the massive switchboards as they take shape on the factory floor ... where assembly workers consult an IPC-based configuration system on PCs right on the shop floor.
As a brief preface: the IPC veterans know exactly what issues they have and are very focused on them. Jan-Peter ignored my general questions about the CWG and went straight to his – and his company's - concerns. If this contribution seems critical … good! Let's get a dialog going. We'll hear from SAP on these topics and we hope to hear what other members have to say, because this interview lives at the intersection of configuration technology and the business process.
As for the subject matter, topics such as "multi-instantiable bill of material positions" and "maximal BOM" may not be familiar to you. If they are not, please prowl around the web site. We are doing our best to turn it into a place where you can learn.
And now on to Jan-Peter:
What I heard at the CWG conference is that SAP's plans for the CRM arena are to give us more "Sales", but less "Sales Integration".
Marcus Behrens - in his presentation - said there will be more emphasis on Sales in CRM 2005.The R/3 part - now called ERP - will be more backend oriented.
The problem is that the sales requirements go much further [than is covered by CRM] (and are properly described in
this paper from the CWG Review: "Optimization and the Slotting Problem").
The "Sales" tools should really be designed and organized to support sales. Here's what is missing in SAP's current approach:
- there is too little support for systems solutions (configurations made of multiple products, which may be quite simple even though the resulting system is quite complex)
- the sticking point is multi-instantiable bill of material positions. SAP's out-of-the-box solution only supports you if you have a vanilla configuration that you can comfortably handle with maximal BOMS.
- CRM provides a way of mapping from your sales configuration to a production order in R/3. This CRM mapping doesn't cover AM (Advanced Mode), of course, but it also only covers 10% of the non-AM configurations.
- You can work around SAP's very limited out-of-the-box integration, but you need to do lots of conversion: ... one of the many reasons for conversion is logistics: you configure an entire solution, but you can't ship it all at once. Just one example: Panelboards are usually sent in two shipments: the box is sent very early, and can be put in place during the early phases of building construction. The builders don't want the actual circuit breakers and switches until months later, when they are putting the wiring in the semi-finished building.
- There is a major requirement for reporting between sales and logistic; and for more opportunities to take action during the transaction.
In my opinion, if Advanced Mode is not available, then the IPC is useless for sales. I reject the statement that AM is only for a small set of customers. For example: many of the companies making "simple" configurations are vendors of simple products, which they may sell via the internet, and also of solutions, which are made up of those simple products.
The Lenze presentation at the CWG was a perfect example. They want to start from a functional description and derive from it the product structure and constructional description, They cannot currently find at SAP the means to configure such solutions at sales time ... so they extended the SAP offering with software they developed themselves. There are a lot of companies who have similar scenarios.
In a switchboard scenario, this would mean these steps:
- taking as input a single-line diagram of electrical functions
- interpret it as the specification of electrical devices
- let the configurator generate the modules and sections to hold the devices
- let the configurator organize the sections into a switchboard
- let the configurator generate a multi-level bill of materials to tell manufacturing how to build the switchboard.
From our Siemens prospective there are many sales-related requirements that are very application-dependent. Just one example: We use static delivery lead times for planning the delivery of Siemens switchboards. We therefore don't absolutely need direct access to R/3 at configuration time, but: when an outstanding quotation is accepted as a sales order, at that point we want direct access so that in order to recalculate and confirm the delivery date(s) for the customer just before he presses the order button.
Among current VC users most are not happy with [the product model] they have. They have a configuration environment for historical reasons. It is not simple for them to change, but they would jump at a migration path.
Most companies are using far too many people to translate sales orders to production orders. Although they know that they would like to improve their sales configuration environment, and some may have the desire to improve their manufacturing configuration environment, most of them don't even realize how much unnecessary effort they are putting into the translation of sales orders into production orders. Most people haven't even considered these issues yet.
Maximal BOMs Have 90-99% redundancy: companies wind up creating many similar BOMs which they wouldn't need if they could use multiple instantiation. They are so busy with production that they don't have time for improvements in the sales configuration environment.
For the future of the CWG, we have requirements to present; and we need clear feedback from SAP on which of these requirements it can accept and which not. If SAP doesn't support certain things, then they should make it very clear where the boundaries are, eg: we don't support sales configuration EXCEPT for the special case of a maximum BOM w/ a direct translation from the CRM sales order to the ERP production order. In any other case, the translation is left to the customer.
It would be great to see a table of requirements, matching the customer's view of what is required with SAP's view of what they think is required and hence what they support. [Note to the reader: Jan-Peter provided such a table and it will appear shortly in an article under his name.]
thanks for your contribution, Jan-Peter.
Please send comments to Peter Illing, at email@example.com.