We have a shared Access recipe database for our networked production machines. The data is used both for automatic and guided setup via HMI computers (PCs and panels) connected to different equipment (PLCs, printers etc.) in our factory.

The data input come from different sources. Some data were inherited from older systems, others manually input. Our problem or challenge is to get consistent data. So the management wants to have only one dynamic data source - SAP.

I’m familiar with the Microsoft environment, and have basically myself built our current recipe system.

The recipe database has one main table. Some of the fields in this main table in turn relates to sub-tables.

We make different kind of products (product groups). Not all data (fields) are relevant for all products or machines. This is easily masked out in Access or any other usable database tools.

My problem is I can’t figure out a rational way of organizing the recipe data in SAP. We use the SAP Material Number as key. By my understanding the recipe values should be stored as some kind of material properties in SAP Material Master. But the structure of the SAP Material Master is fixed and do not allow any additional fields or related tables. The SAP database seems inaccessible to me.

It would be nice to hear fro anyone who have successfully integrated SAP as source for recipe data.

 

Well, I have been told by a number of people who have dealt with this very problem that SAP just does not support what you want to do directly. They all ended up creating a fair amount of stuff outside SAP to take the SAP recipes and make them something usable to the plant floor equipment.

This is not a problem unique to SAP. These things are created by accounting and IT people who know almost nothing about running a plant. Every company I know of that has tried to hook their plant floor equipment to their accounting systems has run into the same thing. That's why there are so many people out there making a living creating the hooks that go back and forth between these packages and the plant equipment.

 

From what I have seen of SAP (which is more than I would have liked), you don't want to interface directly into the database. First, the SAP people will generally have a heart attack at even the thought of you going directly into their database. Secondly, they will need to change how things work in the ERP system on a regular basis, and they won't want your systems as a dependency on their design.

What you want to do is to have the SAP people give you an interface via a web service or even a flat file that will give you the recipes in a defined and stable format. There's a lot of ways of doing this, but it normally consists of some custom programming on each end.

It would typically work that your application would regularly ask SAP for updates, or else SAP would push the updates down to your application (depending on who is willing to be the client and who is willing to be the server). Your program would then take that data and update your own database with the recipe information (after checking it for errors, of course). The rest of your system out to the plant should remain pretty much as is.

Your problems might arise if the information that you need simply isn't *in* the SAP system, but that isn't something that you can solve from your end. What you need to do is to sit down with your ERP people and work out what needs to be done on both ends to accommodate this.

I would suggest that whatever you do, keep it *simple* and don't stick a dependency on Microsoft's acronym of the week into it. That would be inserting a long term dependency that you may not be able to support without a major overall of the whole thing in a few years. If you end up with a web service, stick with basic JSON or XML and avoid layering on a lot of unnecessary rubbish like SOAP, as you really don't need anything that complex for this.

 

Thank you Bob and Michael.

You confirm what I've more or less already learned. I foresee a long battle...

I really want to hear some success stories. Come on all you control guys out there (and ERP-guys for that matter)! Give me just a glimpse of hope before going to war!

 

I'm not a specialist in this area, but pretty much every ERP integration project that I have heard of did it as I described earlier. Don't get stuck on how SAP is organised internally, that doesn't matter because that will change over time.

You need to write up a document where you say "I need this information" and you define exactly what each piece of information is. Then you have to sit down with your ERP people and discuss it with them and ask them how they can provide it. I would expect them to say that they would want to provide it by generating a report "document" which they either download to you or you download from them. Whether that's through a text flat file which you have to parse, or whether it's as a web service document (which you also have to parse), is a matter of how their system works.

I'm assuming that somewhere in here you have already talked to the management (and other stakeholders) who wanted the ERP integration to see what their actual goals are for this.

Your ERP is probably batch oriented. That is, it wants to deal in bundles of summarised data on a shift by shift basis, not part by part real time processing. Also, you may be paying data centre charges based on per-report or CPU time usage. You better find out who is holding the bag for any costs as they might have something to say about it as well.

The "hard" part is going to be finding out what people really want and what the ERP system is capable of. I don't think the actual implementation is really going to be that hard as you are just adding a new source of input for the existing system.

Be sure that there is a clear document defining what the ERP team is responsible for providing so that everyone will have this as a reference for use in the inevitable ERP upgrades and changes in the future.