The Fit/Gap Analysis is one of the most Important Phases with any BI Applications Project. Any gap not Identified will lead to an incorrect Design and ultimately to a “wrong” Implementation.
What is often the case in BI Apps Projects is that the Customer formulates the Requirements (Afterall this is also used for RFI’s/RFP’s) without taking a look at the provided Standard in the first Place. The Problem we have with BI Apps is often that the Customer uses the OLTP (e.g. Siebel/Peoplesoft) for a certain number of Years and then buy’s the Standard Analytical System (BI Apps).
The Customer is expecting that all Standard Requirements that were used to build the plain OOTB Standard Software are used 1:1 for building the OOTB Analytical System. However, in truth this is not the Case. Also one needs to keep in mind that BI Apps is built to accommodate Data from multiple OLTP Systems with somewhat different Concepts. One particular Example of this is with Siebel and the Position Based Security. With Siebel it’s possible to have many Employees to share one Position, however in BI Apps only the Primary Employee of the Position is allowed to see the data, thus requireing more or less a one Employee per Position Concept. This is described in more detail in the following Post: https://biapplications.wordpress.com/2014/01/13/primary-positionowner-based-security/.
Taking a look at the OOTB Standard Transactional System from Oracle, we find the following Situation with Regards to the Requirements:
The Requirements that are used to build the Transactional System aren’t documented. Typical Documentations like Use Cases, Business Processes (Flow Charts) and Textual Description are missing. The Design is also very often undocumented, but at least ER-Diagrams exist.
Much the same is true for the OOTB Analytical System, BI Apps.
Thus, gathering Requirements and doing the Fit/Gap Analysis much depends on the Knowledge of the Team and the ability to derive the undocumented Req. from the Implementation in kind of a reverse Engineering approach.
Accepting this Fact the best Methods is to actually deliver a working OOTB Implementation of BI Apps first and then placing the Business Side in front of it and explaining the (their) data that the Business is seeing. And use this to (re-)write the Requirements.
Actually talking about the plain OOTB Standard and about the actual Customer data, can be much easier than reading through hundreds of Customer Requirements and using this Project approach increases the sensitivity to the most Important Requirements for the Customer.
Thus I argue for a shared Fit/Gap Analysis between the Customer and the Implementation Partner instead of Technically deriving the Fit/Gap based on the Requirements Document of the Customer by the Implementation Partner.