Skip to Content

Parallel implementations – Implementing SAP R/3 and SAP BI together – Pitfalls

Many people talk about implementing both the ERP as well as the BI solution together to save time. I too was asked to implement a BI solution for a client when their R/3 was yet to go live and was being implemented. Some nightmares  recounted….

No control over business processes …
What does this mean : Your typical backbone extractors like the LO cockpit extractors for Sales Order Header and Line Item  can change overnight and you have to change your entire data flow along with that. This does not happen once or twice – likely  
to happen frequently leading to hair splitting situations where entire data flows have to be redone including the reports.   Here the Sales Order processing workflow is just an example I have taken.

No proper data to test
All the data in your R/3 development system is test data and that too it is more of a graveyard of old data where data across   the timelines when business processes were changes will exist. With neither client or you know what correct data is. This  
leads to delays in asking the client to input valid data ( often a few records ) and then loading the same and validating the  data.

Too many clients
You will come across golden clients , development clients , sand box clients , IDES clients and all sorts of clients and in  many cases different clients are used by different functional teams to tinker around with the process and test out their  process models and data is scattered and to get this data into one DEV client takes time since the changes have to be done  here again. For the functional team , it in all likelihood will be an SPRO checkbox , but might mean a sea of change for BI.

Too many reports
The client has these set of reports he/she wants but is not sure if the reports need to be delivered out of R/3 or BI – this leads to each sides claiming that the other side can do it easily and leads to lost time and effort. In many a case the report will be delivered by BI but then someone from the R/3 side will write a program to deliver the same in R/3 and the client seeing that the data is more current – embrace the same or worse still – compare both. The other side of the story is also too familiar…

Lack of Scope
The implementation will be more focused towards modules rather that specific requirements since the ERP is not stable yet. This will mostly lead to almost a new implementation of BI starting after the ERP is stabilized due to the sea of changes requested.

If possible avoid such a scenario or if this is not possible a watertight scope needs to be in place and test data / data access needs to be proper.

Again I have just recounted what I have observed , maybe it is not as bad as it is made out to be and such projects can be delivered on track and in time and in scope with better management and control over requirements.

You must be Logged on to comment or reply to a post.
  • I think this is great to mention.  I'm sure a lot of clients think it can be done like this and these points can now be communicated to them.   Thanks for the points..
  • And I know it... But when it comes to implementation, there is different logic in the customers mind. They want to do ERP and BI as ONE project, and that's it. Period. That's the situation I am right now, where ERP and BI side have exactly the same deadlines for deliverables, which means that ERP can introduce change on their side till the very last moment 🙁
    • We ended up reimplementing the whole thing after the ERP went live and stabilized...!!! escaped by the skin of our teeth since the scope was small to start with....
  • I am in the same situation where ECC and BI are being implemented simultaneously.
    The important aspect is to define the scope of reports to be delivered in ECC and BI.
    Next step would be to have clearly defined functional specifications and change requirements to be taken through change control board.