Business Intelligence is software system designed to derive the Business Values from a Business and primarily it is meant to analyze the different business operations and associated activities like cost forecast, performance management, sales projection and production management. Its success depends on various factors like fulfillment of user requirements, user experience & flexibility of the solution, momentum of BI strategy at management level and the organizational IT policies created for the adoption BI system.It is necessary to follow the best practices and guidelines created by an individual or a consulting firm to make the BI initiative a big success with sensationalized ROI(Return On Investment). SDLC of a BI Project involves a complex project management and execution strategies to conclude it successfully. The initiative starts with business requirement analysis, the development ends at deployment to production server and the final delivery ends with the post-deployment activities like Change Request Management, finalization of user manual, internal adoption strategies and practices, strategies to bring BI as part of Enterprise Social Networking practices and planning & training practices for Support & Maintenance.
2. Strategize Well Your BI Requirements:
BI initiative devised to fulfill the BI requirements varies from organization to organization. It (BI initiative) may be meant to have a completely new BI System or sometimes it is initiated for one or two specific BI Modules only.In both the cases, it is possible to implement them on top of the existing BI system or a consider a new BI Platform. Along with Budget, Planning and Management, requirement analysis of BI System plays a vital role to make really successful.
Good analysis of BI requirements drives the initiative to success. There are some theoretical aspects associated with the requirement analysis but in practicality, it can be executed under certain good practices and guidelines. In today’s BI Market, BI initiative, either at module level or at system level, it should be considered as an organizational initiative rather than departmental or individual responsibility for the best Business Values Additions and higher ROI (Return on Investment). Starting from the Use-Case Analysis, consider the importance of participation of Business Analysts, BI Architect and users, CEO, COO, CFO and CMO to capture the holistic view of the requirements. It is the right time to bring the Enterprise Social Networking sites into action. A closed group of community can be created to get the requirement updates and opinions over the already expressed requirements and it can be considered as ‘Pre-Deployment GAP-Analysis’. Here, the whole requirements are captured as free-flowing diagrams inside a chart-paper or in a special editor using the digital pen/stylus before laying down all the details into the actual FDS- requirement details document. Business Analyst takes this responsibility with the help of Solution/Business Intelligence Architect. Once the requirement are completely gathered in an industry standard document format i.e. FDS along followed by SRS, do the internal review of the captured requirements among the team members. In this exercise, get the opinion from Technical Analyst or BI Architect to know initial feasibility of the solution to cover the solution for all the requirements.
The BI Solution always comprises of one or more than one modules. The overall requirements can be divided into modules and finally they can be grouped into requirements for Enterprise Reporting Solution, BI Dashboard/Business Cockpit/Dashboard, Business Analytics (Standard Analytics, Predictive Analytics and Self-Predictive Analytics) and OLAP.
There are more than two to three dozens of BI Platforms in BI market and each one is best for one specific sets of BI functionality & features. It makes the selection of BI Platform a very serious task at organization level but there are ways and best practices for conclude the selection process with international standards. To start with the selection process, firstly, initiate an activity to create the detailed information about the BI Platforms through the comparative analysis. It is a good idea to finalize the group of BI Tools as the first elimination process before moving ahead with the actual finalization steps. The best BI Platforms should be selected through two well-defined processes i.e. comparative analysis followed by POC (Proof Of Concept). So to start with this process, create the features-comparison sheets using Spreadsheet Processor (MS Excel, OpenOffice Spreadsheet etc.) or a report using Free/OSI BI System considering all parameters like features, licensing polices, ownership acquisition type (installer setup, Cloud SAAS or OEM type), availability of resource pool in market, expense/charges of consultants/experts and case-studies of successful BI implementation in same business domain for each of the BI Platform. These details can be collected from various sources like direct vendor interactions, IT-magazines, IT Newspaper/Portal, e-books and groups and communities on social networking sites. Here, some of the vendors can be eliminated straightforward if they don’t meet the requirements of core/fundamental functionality. But, it is a bad idea to finalize the BI Platform simply based on this fact/comparison sheet. The best practice is achieved by initiating the process of POC with pre-defined sets of requirements to generate the limited numbers of reports, analytics, KPI, Scorecard/Dashboard and OLAP models.
Now, the communication with BI vendors can be triggered to finalize the actual date of starting the POC. Business data is the asset of each and every business process and an organization and it should be treated with full responsibility and under certain documented guidelines. Irrespective of level of comfort in relation with vendors, always sign an NDA(Non Disclosure Agreement) to protect the data, concepts that’ll be used to create BI Solution .The requirements and expectation from POC must be documented well enough and give the same to all vendors finalized for BI POC. Involve key users to get the feedback on user-experience, look and feel and easiness of usage. Similarly, get the opinion of technical experts regarding the robustness of architecture, API, integration compatibility and easiness in customization.
When requirement are gathered completely into a well formatted document i.e. FDS, start conceptualizing the BI Solution to be deployed using the selected BI Platform. Now,it is the time to start building fully working prototype of the final BI Solution in HTML or the prototype designer tool like Serena-Prototype-Composer2009R1. This type of Prototype designer helps in maintaining standards and makes easier to add change request come across till the completion of production deployment. Alternatively, it is a great idea to enhance the deliverable of POC further to make a POC deploy-able to production environment. In this consideration, time and efforts towards Prototype of POC increases at least by 50% but the time fame to deliver final solution will be reduced and changes of re-occurrence of the technical glitches will be minimal. The following points should be considered thoroughly while designing the prototype taking the points from the requirement document: –
1. In Ad-Reports:
a. The color combinations and other look and feel parameters like font size and name, logo and report-footer text like ‘Powered by PentahoBI’.
b. The type of reports and layout supported by the finalized BI Platforms, it could be the default types leveraged by the platforms or custom-report supported by the programming extensions.
c. Number of grouping and group-headers labels, font name and font size at each grouping levels.
d. Nature of drill-downs, whether it is intra-report or inter-report,or two level drill/expansion.
e. The name of report-portion or target reports to drill from main reports or on subsequent drilling.
f. The header-names and sample data should be relevant.
a. The color combinations and other look and feel parameters like font size and name, logo and footer text like ‘Powered by PentahoBI’.
b. The type of report and layout supportable by the finalized BI Platforms, it could be the default types leveraged by the platforms or custom design report supported by the programming extension.
c. The typed of visuals and sample data, even if it is necessary to have more than one interface for single Analytics.
d. The header-names and sample data should be relevant, and all look and feel details of all.
a. The types of Visuals, specific type of Charts/Graphs.
b. The columns for dimensions and measures.
c. The user specific KPI sets and nature and number of expansion in OLAP report.
Designing a software solution is an art of amalgamating the business process,software platforms and business information into a best possible fashion. The business requirements, the functionality supported by the BI Platform and budget and resource allocated to the project or module are the key parameters to be considered while designing the BI Solution.
User Experience is always driven by easiness and intuitiveness of the user-interface available either by default or through the customization. So, create the standard and the best combination of Layouts, Colors, Fonts and labels. Preciseness of the business information brings up greater user-acceptance and helps in gaining the higher ROI. So consider these points while conceptualizing the BI Solution.Keep the appropriate type of charts or graphs and other visuals and it is great idea to keep the uniformity of chart type for better presentation, readability and easiness.
To bring all of them into reality, some standard practices are taken into action. Apart from tertiary documents, two main documents are created to support the development process or stage and they are SRS(Software Requirement Specifications) and DDS. All core technical stuffs like the Architecture details & diagrams, details about the finalized software platforms and other associated software components are placed inside SRS. All design related details including summary of functionality from FDS, a report/analytics/KPI/OLAP specific screenshot taken from the Prototype, data-fields details, SQL statement or procedure names to be used in designing the report object are placed into DDS. These document are generally designed, updated or altered by senior techno-functional resources along with Technical/Solution Architect or Solution Designer.
It is a time to look for the resources of different skills sets depending upon the project size and readiness of other related software environments like transaction system and Data Warehouse. If Data Warehouse and Data marts are the parts of BI solution then start sub-project and it requires BI resources of different skill set. Considering the complexity of the BI Platform, it is always a great strategy to have specialized team of Data Warehouse just like the BI Developers team.
The actual report or Analytics/KPI/OLAP designing process can be divided into two parts – data modeling and interface designing. In Ad-Hoc reports designing, check or update the query given inside the DDS and make it fully compatible with all changes added till now and use the same for report designing. The designing of Analytics and OLAP varies from BI Platform to Platform but the fundamental steps always remain same. Against each requirement set given inside the FDS and summarized inside DDS, all associated data points logically mapped to the database-fields are taken from DDS. If they are not there, the request to get the same can be raised to the Project Manager or to Team Lead for the earliest update. The testing team or member is informed putting all other members into the loop for the completion of each of the report object. In my opinion, it is great and imperative practice to use Enterprise Social Networking sites for this kind of collaborative updates.
Users always love to have a comprehensive, intuitive and visuals-oriented User Guide/Manual and it is better idea to start designing the same once the developmental efforts starts and complete only when all the solution gets ready for production testing. Any change in the functionality and screens placed inside the report objects namely Reports, Analytics and Dashboard should be updated whenever the new changes are added or updated. It gives a really updated and compact User Manual. The feedback or suggestion regarding the contents and types of details looking can be taken in collaborative ways using an Enterprise Social Networking Platform.
7. Leverage Enterprise Social Platforms:
Organizations have started adopting the Enterprise Social Networking as a core Collaborative Platform. Create an intra-organizational community or group to start with putting the updates about the BI solution, different technical updates and request for the feedback from the user an peoples across the organization. This is next generation method of delivering the solution considering the interests of all users and group of users. If the Enterprise Social Networking is not implemented or still in pipeline stage, this step can be avoided but same can be leveraged later on whenever it becomes ready for use.
8. Create Testing and UAT/UWT Plans:
Now, it is time to test the smart efforts placed so far. Create the Test-Cases covering all functionality mentioned and detailed inside all three documents SRS, FDS and DDS. It is always better to have very comprehensive Test Cases against each of the module or one deliverable unit. If there is more than one module to be tested, follow the approach of catching one at time. The defects or errors reported during the first iteration/testing should be fixed before moving into another iteration of testing. And, the same approach should be follow for rest of the modules. It will remove 100% of all technical defects and 99.5 % of functional issues or defects. Now, schedule a UAT with internal Business Analysts & BI/Solution Architect and users and incorporate all defects reported during these activities. After this, schedule a session with all users, CXO and people connected in this project and present the solution for feedback mostly for functional correctness and easiness . This process is UAT (User Acceptance Test) and UWT (User Walk Through).
Now, time to add the final beatification to the solution. All change requests from UAT and suggestion gathered through Enterprise Social Networking sites should be incorporated before moving the solution into production stage or LIVE. The UAT/UWT should be iterated depending upon the quantum of the suggestion or feedback on previous UAT/UWT. It is possibly great idea to take the solution into production on modular basis.
9. Conduct Interactive Sessions:
When the fixes are added for all change requests, take the solution into production stage or LIVE and repeat the testing of all functionality and features to make ensure that whatever were passed on stage/testing environment are available in production environment too. After that, a final interactive/intuitive presentation can be prepared. It can include the videos presentation with audio. Publish this also into Enterprise Social Networking Sites for comments and suggestions. All suggestions, feedback and comments by target BI solution users and other associated team member are incorporated inside the final Presentation and Video to be presented in Final UWT. The final copy with latest updates can be made available to all through mail or using Social Networking Sites.
10. Schedule Final UWT :
Now, it is time to predict and discuss the actual values addition of the BI Solution and its future road-map to get the higher ROI. Schedule a final-combined meeting session with all Business Analysts associated in the project, CXO, end-users, power-users and Enterprise Solution Architect or Business Architect. Time to present the finalized Audio-Video Presentations, Power Point Presentations of all ready modules to educate users in best way about the solution and working steps. It should include the roadmap of the BI solution and strategies to get the higher ROI from the solution. All the best.
Author: Amrit Chhetri, http://about.me/achhertrib