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.
No comments:
Post a Comment