Comments on Brightwork Articles on SAP Integration

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

This article contains comments from articles on SAP Integration.

Introduction

These comments are in response to the articles on SAP integration.

Comment #1: From Jumpy Monkey

“I’ve recently found your website and have found your articles very helpful in understanding SAP Core Interface. The company I work for is embarking on two new projects which bring a requirement for CIF. We have both SAP TM and EWM projects underway and they represent our first venture into SAP SCM. We have been running SAP ECC for many years however. As you can imagine, SCM presents new challenges for us.

I have a simple question for you. Typically what teams are involved when building/managing SAP CIF? I am with our Basis team and I expect Basis is involved in the initial setup (Logical System Name, Client assignment, RFCs, etc). My company may be leaning toward including CIF Integration Model management as a Basis role. Based on your informative site, that role would be better suited for our new SCM teams (TM, EWM).

Just wondering what your experience at other companies has shown.”

This is a great question that is often not approached correctly on APO projects. One of the major reasons is that SAP misleads clients as to how much work the CIF is to operate. They do these competitive reasons to make executives think the integration between SAP applications will be far less work than integration between a non-SAP application and SAP. This strategy works very well. In the sales process the CIF is presented as a great technology that essentially pre-integrates SAP R/3 to APO. It all is is presented as so simple and easy to use. However, while it works well for SAP in the sales process, it disadvantages the implementation because the CIF takes quite a bit of effort to set up, but then also is a heavy maintenance item for the duration under which APO is implemented. It never really seems to trail off in terms of being an issue on a project. In many meetings, years after the initial implementation the CIF serves as a source of frustration but also and source of blame for things that go wrong in the application. The executives also end up confused as to why the implementation has so many problems with the CIF. However, the CIF is simply a poor middleware application that takes many resources to maintain. SAP consultants will try to sugarcoat this in different ways to their clients (“well it’s not the CIF, its something in the application, or we just had to clear the queue”), however, the fact is a lot of problems the CIF has should be automated and managed in development. Some of the things the CIF trips up on are elementary and wold make a middleware vendor like Informatica fall down laughing if they saw the CIF in action.

That is really background to your question, but important to understand. So the CIF really requires both a Basis type resource and an SAP APO module application resource to effectively run. In the beginning of the CIF’s life on the project, the SAP APO module resource will do most the work. The Basis resource is important for setting up the environment so that it is optimized to run the CIF and the CIF is pretty resource consuming. In addition to the Basis work you described, the CIF has a habit of getting jammed. This means it must be manually cleared. Either resource can do this. However, as the Basis resource should probably be responsible for monitoring the CIF, it makes sense for them to clear it. However when things go wrong, its often because there is some data inconsistency that requires the knowledge of the applications that are being connected by the CIF. This is where the SAP APO module resource comes back into play, and in fact in some occasions, the APO resource must pull in an R/3 module resource in order to get to the bottom of the issue. The R/3 resource may need to make a change to say, how a sales order field is created so that it does not confuse something on the APO side. So unfortunately the CIF role is a shared one between Basis and the APO resource.

In terms of staffing, I have traditionally seen the CIF consume 1/4 of the time of the APO resource and around 1/4 of the time of the Basis resource. But the problem is sometimes this goes up substantially for a few weeks. However, is also depends upon how many modules are implemented. It also depends upon the modules in question. Both TM and EWM are modules without a lot of installs behind them. Also, both are short duration planning systems. That is they don’t plan very far out into the future, and they are almost in the executional space. This means they will have more data flow across the CIF than the core planning modules in APO. TM is a bit of a black box as it has been greatly changed in just the past few years. However, EWM is a known quantity at this point, and it requires a heavy staffing. Both modules are risky implementations, so the implementing company needs to staff them heavy to have a better chance of pulling them off. If a company had no idea about this or thinks these are just like any other SAP APO module they are in for a rude awakening. Therefore, the projected staffing consumption for the CIF for these modules should be more than 1/4 for EWM and TM (possibly up to 1/3 for each) and then probably 1/3 of one Basis resource to support both.

Would You Like to Comment and Have it Added to This Thread?

Just provide your comment in the chatbox in the lower left of this screen.