|
Now-a-days many vendors provide industry, sector and function-specific 'pre-designed' BI models to increase the speed to market for their clients.
These pre-designed models include:
- The pre-defined dimensional models in Data Warehouse
- The pre-designed ETL routines. There routines essentially have a data template and as long as one is able to furnish the data (from a single or multiple sources) or its sub-set, the ETL program will not be requiring a customization.
- The pre-configured OLAP layer, whereby pre-defined multi-dimensional databases (refer what is OLAP)
- The predefined reports and analytics for BI reporting and analysis tools.
- The pre-defined KPIs for the performance management tools.
The claims by the BI vendors are:
- Best in class DW models incorporating best-in-class practices.
- Reduce the speed to market by nearly 30-40%.
- Reduce the expenses on the analysis and design.
- These models fulfill most or the typical information needs of a function or a business for a given industry.
- Extensive documentation is available
- Significantly better production support capability with well trained resources on the given models and design.
Tricks to evaluate and manage Pre-defined BI frameworks/LDMs
The above said benefits are obvious, expected and significant, if truly realized. Here are some of the cautions one needs to undertake to ensure that one is able to appropriately evaluate the pre-configured platform and thereafter operate it to its maximum potential:
Look at the capability of these LDMs before purchase:
How much information needs these pre-defined models, will be able to meet is also a question, which needs to be whetted in detail. We would recommend it to be done at two levels:
- A BI expert within your organization to review the schemas of the model. By going through the dimensional tables and the fact table grains, one is able to make good sense of the capability of these models.
- List down as comprehensively as possible the statements of your information needs. This includes list of say 50-60 information needs for each function (this can be done fairly quickly if your have functional super users involved). Over and above this, you can share the current reports, scorecards and dashboards. One can ask the vendor to respond on if their pre-defined models would address these information needs. To be fair, you cannot expect LDMs to 100% meet your requirements, but as long as they are addressing most of them, it should be with-in the acceptable range. For the information, which is not addressed by LDMs, it could be worth to check on if the gaps are related to specific needs of an organization or they are general industry requirements. If the LDMs are missing what can be considered as ‘generic information needs of the industry’, one should become more diligent.
Look at the extensibility and flexibility of BI Models:
It will be impractical to assume that an organization will be able to meet all its critical information needs from the pre-defined models. There will always be situations due to the organization specific business and operational models, where the pre-configured models may need to change. The flexibility with which these models can be enhanced to meet the customized information needs is the key. The best way to proceed with this is to pick-up the gaps (as mentioned in the previous point), and ask vendor to comment on the potential effort and time involved.
It will be the best indicator for the flexibility and extensibility. One has to keep in mind that any change in the pre-defined model will be having an end to end impact on the ETL design, OLAP model, and the end-user tools set-up.
Question your BI information needs:
Typically, for transaction systems, the best practice is to fit your processes and needs as per the packaged core systems. For example it better to mould your self for SAP, instead of changing SAP ERP system, as the costs of changes and retrofitting for subsequent up-grades will be huge. However, one cannot apply the same intensity of discipline for the information needs.
The information needs are continuously evolving and one can contain them only to a certain extent. If a BI platform places a constraint on what information you can derive out of the available data, it largely defeats the purpose. However, if given information need requires huge change in the LDMs, it may be decided to have a separate stand-alone way to cater to that need. To be cautious, these kinds of instances should be rare.
Do a sample check on the detailed definition of data fields and measures:
Though the headings of your logical data model attributes and measures may sound familiar, one should look at the detailed definition of some of the critical attributes. For example, in life insurance 'Annual first year premium' (AFYP) is a known term, but its important to look at the detailed definition used in the LDM. If the data is picked from source systems, without any changes, it is lesser of an issue.
Impact of changes in the LDMs on your maintenance cost:
One needs to have clarity on what will be the impact on the annual maintenance cost of these LDMs, once they are changed. We are of opinion that it should not be linear with the cost of making changes.
The method of change:
Even if you are able to change the LDMs easily, one needs to work with the Vendor to understand on how the changes will be done. Here are few of the questions that need to be asked:
A new attribute will be added?
A new instance will be added?
A new schema will be created?
Check on the Best Practices
Performance and Scalability
Typically these frame-works are built on sophisticated and well-known system components in terms of data-base, ETL tools, OLAP layers etc... As we have mentioned before, a good part of the performance of BI is driven by the way we model and design our BI, over these state-of-the-art tools. One should take references from the market on how well these frame-works are able to deliver in terms of response time- not only on their frame-work but also on the frame-works, which have undergone customization. Sometimes the response time on pre-configured frame-works is good, as they are well tested in the lab. However, there are nothing like ‘ideal driving conditions’. One will need to look at if the frame-works will work on the shop-floor, after going through range of diverse applications and some changes.
NOTE- We have listed ONLY FEW of the considerations for LDMs. The message of this tip is to apply in-depth diligence to ensure that the LDMS are truly delivering to the promised benefits.
What is the other edge of the sword?
LDMs or pre-defined BI frame-work is a well integrated set-up. If it does not have most or all of the above traits, it can become a significant change management pain, and escalating costs. It also impacts your production support cost, as any kind of change in these pre-defined frame-works will escalate the production effort (if they are not flexible). Sometimes organizations end-up creating additional cubes etc, as a stand-alone work-around so to meet their needs, without making much of changes in these frame-works. If that happens, it will be unfortunate, as the fundamental goals of having integrated BI platform gets impacted. |
