Unsuccessful examples of BI development. Part 1
Table of contents
Common Problems that Arise When Developing BI Systems
You’ve spent time and money integrating a BI product into your business. Now, you want to be sure that the development was successful, and the product takes root in the company. In other words: You want to be sure that your time and money wasn’t wasted.
What are the common pitfalls of BI system development, and how can they be avoided?
Choosing the BI product most suited to your needs does not necessarily mean it will be successfully developed and have a long life within your business. We periodically work with companies who already have BI products, but want to switch to another one, claiming that “the previous product is bad.” In these situations, we ask the client, “What product do you have?” The answer is almost irrelevant; we know that their current BI product is both expensive and high-quality. This means that our job is to develop an analogue of what a customer already has. Plus, we know that, in 3–5 years, the client will again declare that “BI products are useless.”
There are a number of situations which lead companies to this conclusion. When it happens, it’s not because BI products are useless. BI products are incredibly sophisticated — it just takes a some expertise to know how to use them effectively.
In the previous article, we described how choosing the right BI product is not as simple as it might seem. In this article, we will demonstrate common challenges that we have faced — through our customers’ businesses, and within our own — while developing and maintaining BI systems.
In simple terms, the lifecycle of any BI product looks like this:
All development begins with analysis. Here, we encounter our first conflict.
Problem #1: Lack of Knowledge
One of the most frustrating problems we face when developing BI products is that customers are unable to answer questions about their underlying data. These customers prefer not to use our analysts, but also doesn’t provide an employee from their side who understands what’s needed for good analysis. Some customers do provide an employee, but don’t relieve them of their daily tasks. So, they end up attending to their own business first, only answering our questions if they have time.
This results in a long BI development process, with many more roadblocks than is necessary. Data verification turns into a nightmare; the employee who tests data or checks final numbers simply says, “This data doesn’t match my report,” without elaborating. Afterwards, it’s almost impossible to understand why they reached this conclusion, or what data they were using for verification (or why).
The problem lies in the internal processes of the organization. With better communication and mutually available data, we can avoid this challenge altogether.
When we can get through this stage successfully, we proceed to the development process. At this stage, another challenge awaits us:
Problem #2: Lack of Interest in Development
Within this problem are two possible scenarios. The first has a solution — the second doesn’t.
Scenario 1: Managers and Employees
A high-level manager understands the importance of developing a BI system, but lower-level employees don’t. They merely see it as a source of extra work.
Fortunately, this problem is solvable. If the managers understand the benefits of analytics, they will accept our advice and develop a culture of analytics within the company. When they appreciate the importance of business analytics, the whole team comes to understand that developing a BI system is not just more busy work. It moves everyone forward as a unit.
Situation 2: Managing Companies and Subsidiary Companies
In large holdings, managing companies often instruct their subsidiaries to develop a BI system. But when the subsidiary doesn’t understand the mechanics or importance of the BI, they’re interested only in executing the budget — not in making the most of the BI system itself.
From our perspective, this circumstance is bound for failure. If developing the system is a mere budgetary formality, we can put the system in place, but then it will only exist — not be used to its full potential. Efficiency from its use will be close to zero.
Problem #3: Inability to Develop Analytics Systems
Here, the customer understands the importance of analytics — “It’s a must-have in the modern world, I’m in!” So, the development stage begins, and it seems that everything is there: data, understanding, and the motivation to do it well.
But when we dive deeper, we find that there is no meaningful data. Perhaps data is there, but it was entered improperly (e.g.: a field in a table is not mandatory, so users left it blank). Perhaps manually entered data contains mistakes, like spelling errors. Whatever the case, such errors impede the development of BI systems.
Fortunately, there are solutions.
Non-meaningful data can be made meaningful, and most companies are willing to do it. By cleansing the data, configuring dimensional tables, and more, companies turn erroneous information into meaningful data, nipping the problem in the bud. Some companies hire students to rewrite data manually; others do so in-house. Still others design automatic handlers and add the filling rules to the original source system.
Data cleansing not only leads to data perfection, but also to a much more thorough understanding what data you currently have, and what data you still need. This leads customers to consider areas of improvement they never considered before, increasing their motivation and efficiency. Through close analysis of business processes, everyone sees the effectiveness of BI systems, and cultures of data flourish.
Problem #4: Cutting Corners
There are two areas in which, in an effort to save money, customers spend too little on important processes, and hurt themselves in the long-term: development and maintenance.
Scenario 1: Saving on Development
The customer believes that their IT department will quickly and easily understand how to develop their BI platform. So, they buy licenses, order initial development, and then refuse services from third-party developers.
What happens next? The in-house IT department tries to figure the product out by googling it. For a while, it seems like everything is working well. When problems arise, if the IT department insists that the product must work with a delay, or that the product cannot perform a particular task, the customer takes them at their word.
After a couple of years, the BI system turns into one big crutch, as the IT team didn’t have a thorough understanding of the product to begin with. Trying to save money, the customer overestimated the extent to which the IT team could handle development, and blames the product.
The natural continuation of BI product development is follow-up support. Its role in the long-term success of the product is enormous!
Scenario 2: Saving on Maintenance
The customer ordered the installation and development of a BI product from a third company. Good call. However, after a while, they think they no longer need the services of the development team, and decide to cope with support and improvement internally. They hand the project over to their own IT department for “further care and maintenance.”
In this situation, the BI system lives a bit longer. But if your employees develop an appetite for analytics, asking for more and more, the IT department will respond by integrating new elements into the initial version, causing system performance to drop.
Why did performance drop? Did the IT department perform badly? Absolutely not! IT departments cannot intimately know every product you decide to develop. They have many other tasks to accomplish. They never studied analytics, and they don’t know the difference between “Boston Matrix” and “abc-xyz analysis.” So, how can they offer you an analytics solution?
The people who develop BI systems have been working with these products for years. They understand the products’ technical features and best practices. They passed the exams. They know what to offer, how to develop it, and most importantly, which solution suits each customer. They can adapt any product to any organization, understanding how best to help the entire BI system “fly.” They can predict risks and explain how to avoid them.
Think of it like going to the dentist. When you have a toothache, you look for a Doctor of Dental Science who’s qualified to examine and treat it. You pay them for an hour of their time, and your problem is solved. You don’t ask a local nurse to google the problem and treat your tooth based on the search results. If you did, you’d pay them for the time it takes to search, to try a solution, and then to try other solutions when the first inevitably fails. Maybe, at the end of that expensive, time-consuming process, they would be able to treat your tooth — but would you really sleep peacefully after receiving such shaky treatment? Moreover, if something went wrong in the future, wouldn’t you say that the filling was low-quality? Even if you paid less, would you really have saved on it? Unlikely!
The same applies to BI system maintenance. When troubleshooting with an in-house IT department, each decision requires trial and error, prolonging the process. Users wait longer for their analytics, delaying analytics performance. With these obstacles, what will the lifecycle of a BI product in your company be? We guess short — in 3–5 years, you’ll have to start the process all over again. That means you’ll have lagged behind your competitors all those years. While they were getting their cavities filled, you were googling the difference between “molars” and “canines.”
Rather than scrimping on BI system maintenance, it’s best to hire professionals who have seen these problems before, and can solve them without lengthy (and unnecessary) trial and error.
Problem #5: Haste Makes Waste
BI systems change with the times. Features and data sets must be added, deleted, or otherwise modified based on the customers’ evolving needs. When customers entrust us with BI system maintenance, we know this is part of our responsibilities.
Some situations require deep changes which will impact many parts of the BI system. In these instances, we advise customers that it will take some time to make the proper decisions and incorporate the change(s). Customers sometimes disagree, urging us to complete the task more quickly (“Better yesterday!”). So, we propose a solution that can be implemented more quickly, but that will come with risks. We explain that creating a “crutch” like this is not true problem-solving. The customer will agree, and we will institute this method.
More often than not, the customer never returns to this area, because in the short-term, the solution works well. The customer begins to think, “Thank goodness we didn’t spend a month making the improvement — we achieved it in a week. We spent fewer hours, and it works just as well. I’m a super manager, and I’ll address all future conflicts this way.”
Getting used to fixing problems with “crutches” means that improvements are mediocre, and over time, the whole system comes to rely on substandard functions. In the end, this “super manager” will bring the whole system to its knees, compromising its stability.
So, did they actually save money? Not at all! After a certain length of time, “crutches” will have to be re-addressed, meaning much more work just to make the system functional — or developing a new product and starting all over again. This will call for reverse-engineering and auditing the existing system — another long, difficult journey.
Conclusion
In this article, we followed the full BI system development cycle. To be sure, this is not an exhaustive list of all of the problems you could face, but in our experience, they’re the most painful and costly. The solution to any particular problem is not always perfectly clear, but we believe it’s useful to know the most common conflicts that arise during the development cycle.
In summary:
- Successfully developing a BI system doesn’t depend on the specific product or the company assisting in development. Developers always want you to be satisfied so that you tell others about their great work. Therefore, it is in their interests to do the work as well as possible.
- Successfully developing a BI system depends only on you — the business processes and culture of analytics in your company. We can’t influence your business processes, but we will do our best to influence you! We’ll guide the development process, explaining and assisting at every stage, seeking to improve your company’s data culture. It’s up to you to recognize the value of our expertise!
In the next article, we will shed more light on the problems we highlighted here and will help you overcome them based on our experience.
