BI Implementation Plan
Table of contents
As companies grow and evolve, they run into data analysis problems. In a competitive landscape, companies urgently need to understand and interpret reservoirs of data, which causes them to consider implementing Business Intelligence (BI) solutions.
When customers interested in BI solutions approach IBA Group, it begins a two-way relationship. It’s crucial that partners like us understand the customer’s needs. At the same time, the customer must ensure that their company is ready for BI implementation.
In a perfect world, the customer’s company already has a single point of truth, and both management and employees understand the benefits of implementing BI solutions. But in reality, this is rarely the case. To help you understand and prepare for it, this article will walk through the BI implementation process, step by step.
Part I: What Can the Customer Do?
#1. Self-Understanding
First and foremost, the customer should understand exactly what their company needs. What answers does it need from BI? Consequently, what questions are worth asking? These questions will determine the usages and mechanics of their future BI system.
At this stage, the customer company (independently or with the help of data analysis specialists) develops an understanding of the features and advantages of BI implementation. It then communicates these concepts with all who are likely to use the BI system. In order to be truly effective, all users must have a thorough understanding of how to get the most out of BI tools.
In this education process, where do you start?
- Nurture Data Literacy. Start with Data Literacy. Study the concept in great detail. A culture of data is the foundation of successful BI development. Our first article covers the concept of data literacy and can guide you through this process. Once you understand its value, nurture the data culture within all users of the system.
- Analyze & Document Current Processes. Go over the existing data analysis processes and make detailed notes on the functionalities. This way, your company’s leaders will be well-versed on the company’s organizational structure. This knowledge will serve both ordinary employees and, if you opt to use third-party resources, your BI development team.
- Conduct a Requirements Analysis. Talk with future users of the BI system and understand their vision for the product. Write a user story and develop Terms of Reference (TOR) based on it. TOR is a crucial component of any implementation process. A good TOR cannot be vague; the more complete the description of necessary components, the better the final product will be. TOR is not a single document — it comprises a series of documents that describe individual business processes in a company (e.g.: marketing, sales, logistics).
#2. Communicate with Vendors
In step 1, we nurtured a data culture, understood the company’s current processes, and drew up a vision for future developments.
In our experience, customers’ original vision ends up changing by the time the BI implementation process is complete. Compromises are inevitable. Many factors influence the finished product, and you cannot foresee all of them at the outset.
So, our second step is communicating with vendors about what you hope to accomplish. TOR factors heavily into these conversations.
Once you submit your objectives to vendors, they will analyze your situation and propose solutions. This will help you take a more realistic look at your desires and hopes for the future system. Perhaps you’re missing a key component of implementation. Perhaps you’ve overlooked something you didn’t realize was important. If so, they will let you know. They will also provide a rough cost estimate, more information about BI capabilities in general, a comprehensive range of BI tool options, and more.
You can read our thoughts on choosing the right BI tool in our second article, which compares some of the most popular options.
#3. Data, Single Point of Truth, and Data Control Processes
The BI development process has begun, and employees are eager to use the new reporting and analytics tools that will facilitate their daily work. Before they begin, you must establish a single point in truth — or, in simpler terms, the main source of accurate data. Here, we need to take care of the following two tasks:
- Validation. Check for compliance with data type, null values, input masks, and much more.
- Documentation. Document existing structures, including changed or added ones. This may be somewhat laborious, but in the long run, it always pays off.
Changing a data source can be costly, and from our perspective, it’s always nice to work with a customer with orderly data. If you still need to put your data in order, do so as early as possible. Delaying this step will lead to higher costs and decreased quality in the future. Not to mention that building analytics on data “crutches” is bad — if not totally useless.
By executing these two steps scrupulously, you’ll get a clean data source whose information can be transformed for specific analytics and forecasting tasks. Thorough documentation of all data, its storage methods, and its business value will help in future work.
You may notice that we didn’t write about specific rules, like how to put your data in order, or how exactly documentation should look. We omitted this information because methods will differ on a case-by-case basis. (Plus, there’s a lot of valuable online literature on these topics.)
Thus concludes the preparatory stages of BI implementation. Overall, Part I is about what the customer can do to make BI implementation easier and more effective. In turn, third-party specialists will have a much easier time holding up their end of the deal.
Part II: How Should You Use the Professional Team?
To start, let’s review what you’ve already accomplished:
- You’ve begun implementing a data culture
- You’ve articulated your desires and developed a vision for your BI system, and drawn it all up in the TOR
- You’ve acquainted yourself with different BI product options
- You’ve received feedback from various implementation teams on the cost of implementation
- You’ve prepared a single point of truth
- You’ve documented your current system
Now, it’s time to decide on a development team, pick a BI tool, and solve the issue with system support.
#1. Assemble a Development Team
What should your development team look like? Each individual customer will have their own, but all teams have common roles. No project can succeed without an analyst, a developer, and a competent manager. Depending on the volume and complexity of the work, the project may need additional developers and analysts. If the project is very small, those roles may be combined.
Let’s explore each of these roles in greater depth.
- Customer (Product Owner). The customer has the best vision for the product and desired outcomes. They direct and collaborate closely with the implementation team. They determine the order of priorities and guide the team through the process.
- Product Manager. This person understands what the customer wants from the BI product. They act as a buffer between the customer and the implementation team. They are in constant touch with the customer and, if necessary, reviews the progress of the project. The manager organizes the team, prioritizes their tasks, monitors their execution, and adheres to deadlines.
- Business Analyst. A business analyst understands the customer’s business. This person documents the project and extends their understanding to the developers.
- BI Developer. The BI developer is the core of your implementation. They will handle all technical components of the process: installing software, preparing design and documentation, developing your technology at top quality.
For each of these roles, we recommend hiring qualified professionals. If you don’t, it will extend the project timeline, increase the final price, and probably decrease overall quality.
#2. Prepare for Development
Through communicating with vendors, you will optimize your TOR and decide on a BI tool. After this, you’ll transfer your TOR to the development team for evaluation and clarification. The development team will estimate execution time, identify missing information, and point out potential risks.
In our experience, customer TORs often contain multiple business processes. In these cases, we divide the TOR into several documents. Each stage must be completely self-contained. This way, you can more easily monitor overall progress. Also, you’ll get useful functionalities without waiting for the entire project to be completed.
Additionally, the manager gives optimistic, realistic, and pessimistic timeline estimates for each TOR document. Based on these documents, the manager asks the customer for final approval and prioritization. After approval, they plan the work, dividing it into phases and stages of development.
Finally, the customer and their team approve the list of tasks, their timing, and the TOR. This results in a full description of what will be done, at what stage, and in what period. In turn, the team once again verifies the requirements and commits to completing them on time.
#3. Begin Development
The development team begins their work according to the plan approved by the customer. The manager, together with the team, will establish a sequence of tasks with each stage. Each developer is responsible for their specific task. At the logical end of each phase, the team carefully checks it for compliance with the documentation and transfers it to the customer. The customer either approves or rejects the result. The TOR regulates each specific part of the process.
If the customer requests or requires additional functionality that was not part of the initial TOR, it can be added to the existing TOR as an attachment. The team will evaluate added functionality in terms of time intensity, assessing risk and ease of implementation. The customer covers all related costs. On the other hand, if the team has not implemented something from the initial TOR, it must do so.
Completed stages are transferred to the support team, and then this cycle is repeated for each subsequent stage.
#4. Product Support
No matter how well you have built your ideal system, unforeseen challenges will always necessitate support. The server may freeze, some services may stop, access rights issues may arise, among many other possibilities. Therefore, it is worth considering product support even before development.
skilled support team is just as important as a skilled development team. Support personnel ensure user satisfaction and speedy conflict resolution. This team is typically much smaller than the development team. It’s important to note that the support team is not responsible for completing old tasks, and certainly not for developing new ones. It only supports the finished, working product.
To understand the importance of a support team, think of times when you were unable to access the Internet at home. What do you do? You call customer support. What’s more frustrating than slow, ineffective support? The faster their response, the faster you get back online. With BI processes, the better your support team is, the more quickly you can access data insights without modifying the existing system.
The support staff must have sufficient access to work effectively, but it’s worth considering a system of restrictions. The support team should not have access to the underlying project architecture. Such interference can damage the system, if not cause it to fail altogether.
#5. Assess Development Efficiency
At the end of the project, you should assess its success. In our experience, this evaluation can be made in several months. But quite often, a BI product pays for itself by the end of the development stage. We even experienced one instance of a BI system paying for itself immediately when it identified an error in a tax report. Other times, BI systems have allowed marketing departments to immediately reveal illiquid goods. We are sure that you’ll witness something similar.
Conclusion
In this article, we described the BI implementation products, highlighting the stages that, in our experience, require the most attention. This is a minimal process which may be sufficient for some customers.
But minimal does not mean complete. So, our next articles will acquaint you more deeply with the world of BI. Specifically, we will discuss ETL/ELT and how it functions in BI.