Overview: It’s common for companies to consider moving from another BI platform to Microsoft BI in order to reduce licensing costs, to take additional advantage of familiar tools, or to expand the body of workers capable of developing and supporting the Microsoft BI system. Following are some considerations when embarking on such a project.
Fact-Finding about Existing Reports
One of the first things you may wish to tackle is creating an inventory of reports to be converted. Good thinking. You may want to do this in parallel with some of the other items listed in the other sections.
- Consolidation opportunities (for example, could 8 reports be consolidated to 1 with use of appropriate parameter selections?)
- Level of complexity for each report (so that perhaps you can try to start with easier reports before tackling more difficult ones)
- Priority level of each report (start with: high value, less effort)
- Category of each report (such as by subject area, or by data source)
- Data source(s) required for each report (and will all data sources exist going forward?)
- Interactivity requirements for each report (such as hyperlinks, drill-down, drill-through)
- Decision of which reporting tool is most suitable for each report (SSRS and Excel and Power View and PerformancePoint all have their particular strengths)
- Any cosmetic changes, improvements, or fixes permitted during conversion (if any changes are permitted during conversion that is)
- Export requirements (this may drive decision on which reporting tool in the Microsoft BI toolset is most appropriate)
- Subscription and alerting requirements (this may drive decision on which reporting tool in the Microsoft BI toolset is most appropriate)
Planning - BI Change Management
This section includes some of the more broad items to consider which can affect the scope and timing of the project.
- Identify business rules from the previous toolset's metadata layer (here we are looking for logic embedded in another reporting tool’s metadata layer that needs to be replicated in ETL or elsewhere in the BI system – reproducing a Business Object Universe or a Cognos Framework Manager Model can be done with the BI Semantic Model, but it could take you by surprise and expand the scope & the schedule)
- Identify data movement and ETL processes used by the previous toolset (here we are looking for any data sources that will no longer exist, or need to be replicated in the new system)
- Understand security constraints for report access and data access (obviously very important – how much work this is depends on the particulars of your environment and the role the old BI system may have played with regard to security)
- Develop process for testing & validating converted reports (is a comparison of new results vs. old results acceptable for testing, and does the testing require sign-off from a functional user?)
- Determine if an automated conversion tool will be used, or if all reports will be redesigned from scratch (this is a big decision – no tool can convert every single report 100% perfectly, but it might save some time especially for basic reports)
- Identify needs and requirements for governance, auditing and change management (such as approvals required and version history to retain, among many other things)
Planning - BI Training and Documentation
You can’t spend too much time on training and documentation. Trust me on this.
- Determine how report developers will get trained on new set of tools (perhaps a combination of classroom training, on-the-job training, and assistance from a consulting firm that specializes in Microsoft BI)
- Determine the extent of user training that will be optimal
- Finalize naming conventions & reporting standards (to facilitate a consistent user experience & more efficient development experience)
- Finalize documentation requirements (this may or may not change with the introduction of a new system)
Planning - BI Environment
These items are focused on the technical components of the BI infrastructure.
- Planning for the new BI portal (this is the delivery piece – I can’t overstate how important it is to plan this out well)
- Structure of the overall site (often this is a SharePoint BI Center which includes the enterprise site and team/departmental sites)
- Structure of report libraries (often by subject, by user base, and/or by report type)
- Structure for supporting objects (such as data sources, starter reports)
- Structure for training and documentation materials (such as quick start guides, FAQs, how-to videos)
- Need for custom metadata columns (such as purpose, description, report owner, who to contact for help)
- Plan for the backend BI environment (this is the ETL and database piece – critical to ensure performance is optimal)
- Security for the BI environment, including access to ad-hoc reporting tools and data source connections (the structure of the new BI portal will often be very inter-mingled with security requirements)
- Template(s) for standardization of report sets (to speed developer productivity and ensure a consistent user experience)
- Preparation for ongoing monitoring of query loads from new system and resources required to continue to monitor
- Plan for how Self-Service BI will complement the Corporate BI system, if applicable
ROI and Cost/Benefit of New BI System
This type of analysis can be difficult. The organizations that do formal ROI and payback calculations already have formulas to do this, so I’ll just list a few things to consider with a BI system.
- Costs: Include things like hardware, software licensing, cloud services, consulting services, IT support time, developer time, administrator time, time invested in training, ongoing software maintenance costs, etc
- Benefits: Include things like cost savings, improved productivity, increase in sales, increase in customer retention, new capabilities, increase in agility, support for strategic goals, faster access to information, broader access to information, etc
Strategies for User Adoption of New BI System
Here you want to consider things that will encourage adoption of the new system. If a user has a poor initial experience with a system it can take a long time to win them over again.
- Communication plan (such as timing of rollout, what is expected during testing cycles, schedule of reports to be converted, what users should do during the interim)
- Support plan (first level support, second level, and if “power users” will get involved with support at all)
- Training plan (if applicable – at a minimum, some helpful documentation is usually a great idea)
Hope this gives you some things to think about.