Business intelligence projects are designed to allow organizations to make better long term strategic decisions. In theory, BI allows organizations to collect organize and use data in a manner that increases their market share. However, reality is often different from theory, and this is certainly true in the case of most business intelligence projects.
Previous studies have shown that about 80 percent of all BI projects fail, while only 20 percent are a success. When you factor in the high costs necessary to implement such projects, it is easy to see why many organizations have lost faith in BI. However, it would be simplistic as well as inaccurate to say that the problem lies with BI itself. Many prominent corporations have successfully implemented business intelligence projects to great effect. This is an indication that the failure of most BI projects lies elsewhere.
- Just Implement, Don’t care of Planning
- Just Implement, Don’t care of Business
- Just Implement, Don’t care of TCO
- Just Implement, Don’t care of Future Issues
- Just Implement, Don’t care of Data Quality
- Just Implement, Don’t care of Future Changes
- Just Implement, Don’t care of Future needs
- Just Implement, Don’t care of Shopping
- Just Implement, Don’t care of Dash Boards
- Just Implement, Don’t care of Work Quality
- Just Implement, Don’t care of Performance
[is-gateway name="Exforsys" id="social"]
It is important for stakeholders to understand that BI implementation is a long term process and develop a clear cut plan which is compatible with the BI tools they intend to use. Implementation of BI project should not be done haphazardly since adequate planning as well as time duration is essential for BI applications to function properly.
BI planning should take place “before” the company begins searching for a BI vendor. Many stakeholders and upper managers believe that if they simply purchase the application, and begin using it, they will be successful. However, this is like buying a car in Philadelphia with the goal of driving it to New York, without having any clue how you will get there. It isn’t enough to just buy the car; you need a map, knowledge of how to drive the car and a detailed plan on how you will drive it from Philadelphia to New York. Otherwise, you will get lost.
This is precisely what happens to most organizations that attempt BI implementation. They purchase BI application, but they have no plan as to how they will use it. As a result, they get lost when trying to implement it, and this leads to frustration which eventually causes them to give up. Because they give up, the BI project becomes little more than a very expensive paper weight.
In order for a BI project to be a success, an organization must do more than just purchase an application with the expectation of it being a magic bullet. Such expectations will lead to disappointment. Any company that wishes to master BI must develop a plan in advance, and this planning must involve the transformation of the entire firm in such a way which is compatible with the application they intend to use.
First and foremost, the implementation of a BI project must have the endorsement of upper management. Without this endorsement, the project will be doomed from the start. When deciding to implement a BI project, upper management should also plan the creation of a training tool which is designed to teach employees the usage of the app. It isn’t enough for a handful of employees or managers to understand a BI project; everyone in the organization must understand it and how it will make the firm more profitable. It is also important for organizations to understand “why” they need a business intelligence project in the first place. It isn’t enough to just say that the project is needed because competitors are using it; this is unacceptable. A more detailed “why” should be given, as this will lead to the proper planning which is necessary for successfully implementing the project?
An expression I will use to describe this phenomenon is called “why leads to how.” What I mean by this is that a company must first decide why they need a BI project. Once they have a why, they next need a how. The why and how are closely correlated, and one naturally follows the other. It is the “how” that will lead to the decision of which vendor to use, because once you have a why and a how, you will have a plan, and this plan will allow you to purchase an app from a vendor who meets your needs.
Because large organizations are often compartmentalized, conflicts can occur between departments, especially when one department makes a decision that negatively impacts another. For instance, while the IT department may see a clear need for a BI project, other departments may see no such need, and may refuse to adapt to the project. As a result, a scenario is created in which IT embraces a BI application, while other departments or upper management are less enthusiastic about it.
Without the full support of the other departments, the BI project is not utilized across the organization, and its implementation is ultimately a failure. The necessity of an organization fully supporting a BI project is directly correlated to the proper planning of the project. When the project isn’t fully supported, the planning for its implementation will likely be insufficient, and this lack of efficient planning will make it difficult for the project to succeed.
BI project failures can often be attributed to a lack of synergy among the different departments that comprise a firm. It simply isn’t enough for the IT department to embrace it; the project must be embraced by the entire organization in order to succeed, and this embrace starts with the leadership.
There are a number of reasons as to why an organization may need a BI project. Many of these reasons are often technical in nature, and may only be fully understood by the IT department. For example, there could be a situation where there are multiple reporting systems, and each of these systems needs the support of IT. Because such systems are becoming outdated, there may be a need for updates. There could also be a need to replace reporting tools which are fat client with newer ones that are web based. Such a replacement will require the removal of numerous servers, which would save a lot of time as well as money for the people that need to manage them.
However, these technical issues will often be poorly understood by the other departments and upper management. When an IT department desires a BI project, they should focus less on the technical reasons for its implementation, and emphasize more on business reasons. The other departments will be concerned with their own affairs, and upper management will be concerned with the bottom line. Unless a ROI (return on investment) or cost benefit analysis can be clearly demonstrated, it is unlikely that the other departments or upper management will fully embrace a BI Project. This relates to the “why leads to how” expression that I stated previously.
Companies will often find themselves in situations where one department will see a clear need for better information, while another department may see no such need. For this reason, the goal of IT or any other department that wishes to initiate a BI project should be the education of the other departments and stakeholders. They should be able to fully articulate the benefits and needs of the project, and how it will better the entire organization, as opposed to just their department.
Many departments that decide to implement a BI project operate with the assumption that once they implement it, the people will come. This is a faulty assumption that should be discarded. Instead, these departments will want to communicate with senior management, explaining to them how BI technology can be utilized in a manner that increases the organization’s bottom line. The technical details of the project are best left at the door, as it may confuse senior managers who are primarily concerned with results, and not how those results are achieved.
There is always the possibility that upper management will not see the need for such a project, and if they don’t, you can be sure that other departments won’t either. Therefore, if the IT department chooses to press forward with the implementation anyway, they should be held accountable for its failure (which is likely). A business intelligence project simply cannot succeed when it doesn’t have the full support of senior management and other departments.
Regarding business intelligence, there seems to be a perception that the BI component doesn’t have a cost, since it is already included within the database. Additionally, many stakeholders factor in the costs for the infrastructure and the need to service it, without considering the TCO (total cost of ownership). This is yet another reason why many BI projects fail.
In order for a BI project to be a success, the TCO must always be considered. There have been cases where companies used their BI applications to acquire data from Excel, and then managers spent hours each day working with it, trying to decide which products they needed to promote more often, and in which stores they needed to promote them. Because more than two dozen managers spent a quarter of their business day doing this, it was estimated that the company actually spent over half a million dollars each year. In three years, that would grow to $1.5 million. Over 10 years, that would grow to a staggering $5 million.
However, what if this organization had a BI tool that allowed its managers to get their information in seconds, rather than hours? In that case, the company would save $500,000 a year. When a company is considering the implementation of a BI project, they must look beyond the license fees. Equally (and some would argue more important), is the need to look at TCO. Factoring in TCO will better allow the organization to get a ROI which is more accurate.
One common mistake which increases the costs of a BI project is a failure to properly handle data integration, especially when multiple applications are involved. This one issue will often single handedly determine the success or failure for a BI project. Many companies simply don’t understand the challenges of managing data with BI until the project is initiated. Even in cases where IT has the ability to deal with these challenges, the cost for the company can be very high. This is true regardless of whether a company relies on their internal IT department, or an outside source.
Some of the other challenges that organizations will face in successfully implementing BI is the delivery of the tool to multiple end users, enhancing ease of use for users that are nontechnical, and developing capabilities for BI which are customized. Unless the organization is able to achieve all of these things successfully, a scenario can occur in which users fail to adopt the BI app, a problem which is consistently seen. Even in cases where end users are willing to adopt the application, any issues with the three aspects mentioned above will make the problem worse. Companies that succeed with BI often do so because they start small. Once the BI implementation reaches an enterprise level, any problems that do occur can be serious ones.
Many organizations initiate BI projects without first running a RACT test. RACT is acronym which stands for Relevant, Accurate, Consistent, and Timely. Unless a business intelligence project can pass this test, then it should be considered a failure, and the creators of the project should go back to the planning phase.
The R (relevant) of RACT answers the question of who needs the deliverables. Additionally, it asks one of the most important questions of all, which is what problem is meant to be solved by the project implementation? Once an organization has an answer to these two questions, this will better allow it to figure out the cost. When factoring in costs, the organization will want to emphasize TCO rather than other fees which are more obvious.
The A (accurate) of RACT indicates the accuracy of the reporting, as well as the dashboards. If this information is inaccurate, then the organization should go back to the beginning. The reason for this is because inaccurate reporting is a sign that the project is already unsuccessful, and pushing forward anyway will make things worse(and more expensive).
The C (consistent) of RACT indicates that all the information and reporting must be consistent.
The T (timely) of RACT means that the information must be available when needed. It isn’t enough to just have access to information; that information must be made available in a timely manner.
Unless a BI project can pass this stringent test, then an organization has no business going forward with it, as doing so will only ensure the project’s failure.
The RACT test is important because it will better allow organizations to differentiate “corporate data” from “strategic data.” Corporate data is the data that is usually raw, data which is often readily available. Strategic data, on the other hand, is data which will give organizations business wisdom, wisdom which will allow them to grow their profits consistently. Put another way, corporate data is transactional in nature; strategic data deals with long term strategy and planning.
While corporate data is crucial for dealing with the logistical aspects of a business, such as the supply chain or accounts receivable, it is insufficient to carry out the marketing process, as well as the management of sales. As a result, corporate data alone will not allow an organization to grow its market share, nor will it allow for an increase in revenue and thus profit.
The reason for this is because the corporate data is merely a byproduct for the ERP (order entry system), which is created mainly for the purpose of shipping orders within a timely manner. The ERP is not designed to use strategic data in a manner that makes it useful for marketing.
The problem with most BI projects is that they combine complex software with raw ERP data. This is insufficient since the data from the ERP will generally not contain information which is related to marketing intelligence. This is why many BI projects do not readily offer the strategic direction which is needed to expand the business, which would essentially leave the marketing team in a situation where they’re struggling to get the data they need in order to increase revenues. This is also why many marketing and sales teams frequently abandon BI projects.
The RACT test is best thought of as a screening tool which allows one to determine whether or not a BI project should even be initiated. Without such a test, an organization or department will be unable to spot the problems that will eventually lead to a costly failure. It is important to see BI as being more than just a piece of software. It is better thought of as a process, one which will allow a firm to transform corporate data into strategic data that will be accurate and relevant.
When considering BI, the goal of an organization should be the integration of corporate and strategic data. This will comprise things such as the customer segmentation, sales projection and competitive analysis. This process is best completed by running a RACT test first. In a nutshell, this test will allow an organization to determine whether or not it is ready for BI. While there is no question that business intelligence is effective in allowing organizations to increase their bottom line, they can only accomplish this if they are prepared for BI. Business intelligence projects are often long and complex, and this requires preparation and changes on the part of the firm.
When it comes to a BI project, the quality of the data is critically important. When the data is wrong, then the decisions made based on that data will also be wrong. These wrong decisions will eventually cause the department or organization to lose faith in the project. In cases where a data warehouse is being utilized, it will be necessary to filter out data which is incorrect. This should be done during the ETL (Extract, Transform and Load) stage.
The proper management of the data is closely correlated to a data warehouse which has good data. The best way to deal with problems in data quality is to mitigate the problem at its source. In this case, the source would be the source systems, as this is where information is placed.
A number of studies indicate that companies lose almost $10 million each year as a result of poor data. Other studies have also shown that bad data leads to an increase in customer dissatisfaction, which will consequently lead to a loss in customers, increasing the losses further. When organizations attempt to implement BI, some of the problems that they face are an inability to find the information necessary to perform their tasks, as well as mistakenly using the wrong information.
As you can see, the quality of the data is not something that should be taken lightly. An additional cause for concern is an increase in the corporate data that companies must digest; studies indicate that this corporate data is growing at a rate of over 40 percent per year. The fundamental challenge of business intelligence software is that such software is much more advanced than the structure and quality of the data. Many firms find that after spending millions on such software, the only thing they have to show for it is an ocean of data, much of which they can’t make much use of.
It isn’t uncommon for a BI app to be completely inept when it comes to providing strategic data or analysis. It will often be necessary for a large team of analysts to download the corporate data, place it within spreadsheets like Excel, and then manipulate and clean the data in such a way that it can be useful. This process can take hours or days, and it costs companies huge amounts of money.
Even when it is known that transactional (corporate) data has errors, oftentimes these errors are not fixed, and they are then placed within the BI systems, making a bad problem worse.
It doesn’t help that many departments within organizations fail to communicate with each other. The marketing or sales departments will often assume that the problem lies with IT, and they will expect IT to resolve the issue, while the IT department will assume that it is a business issue, one which should be corrected by the sales or marketing team. As a result, neither side takes action, nor the data is rarely corrected. This will eventually cause employees to give up on the BI implementation, and they continue to place incorrect data within the BI system, compounding the problem until it becomes too difficult or expensive to solve.
When an analyst uses the typical BI system to answer a question regarding profits or market share, they will often have to wait days in order to get a response. The reason for this is because they will need to process the queries, send them to the spreadsheet, and then cleanse the errors (often manually), while using look ups from external sources of data. Last, they will need to construct pivot tables that will assist in finding the needed answers. Each time the analyst wants an update, they will need to start the entire process over again.
Not only is this method highly inefficient, it also creates a scenario where the correction of the data is based on the assumptions of the analyst, which itself can lead to problems. Many departments have team meetings where much of the time is spent bickering about whose version of the data is right, rather than dealing with the issues that are more important. The numbers that are presented by finance often won’t match those offered by marketing. What everyone needs is one version of the facts, but because different sides are running distinct queries, with different assumptions, this is easier said than done.
Though the IT department may control the physical storage and security of the data, it is the marketing and sales departments that must control the strategic meaning of this data, and they must be able to audit and manage its quality. Analysts who spend a lot of time cleaning the data should focus instead on being data stewards who clean and structure corporate data through the usage of market intelligence which is external. This should be done prior to placing this data in the data warehouse of the BI system. This should be done on a weekly basis.
Many of the requirements which are necessary for a BI project this year will be outdated by next year. It is crucial to understand that BI systems evolve, as with all complex systems. Therefore, users will need to adopt the application in a manner which will allow them to handle the new requirements which will come.
It is necessary for stakeholders to ensure that their organization is not only prepared for this change, but also capable of displaying the flexibility which is needed to properly harness it. However, having an organization which is prepared is not enough. It is also important to be selective in the BI application that will be utilized. The application which is chosen should match the flexibility of the users, as well as the inevitable changes which will occur in the market. The budget for the BI implementation should also allow for this.
One common mistake that enterprises make is the manner in which they approach BI implementation. It is best to see business intelligence as being cyclical. Each cycle of the project must provide greater insight; a new angle for the firm which will raise more questions that must be answered. In other words, there is no such thing as “finishing” a BI project. Like night and day, one naturally gives way to the other, in a cycle which is endless.
Many firms fail to receive a return on their investment, because they choose BI tools which are inflexible. Even if an organization has the preparation and flexibility which is necessary to successfully use a BI app, they will still fail if they choose an inferior application. A good analogy to describe this is an expert electrician who chooses inferior tools for his job. Regardless of his skill and preparation, the quality of his work will still decline.
The new generation BI tools are user friendly, and they can assist companies in exploiting the jewels of information which can be found in their respective markets. Many of these “jewels” will be hidden within sands of data. Good BI tools will allow casual users to become power users. One feature which is commonly seen in high end BI applications is advanced data visualization.
This emphasis on visualization is due to the fact that much of human sensory perception is based on vision, while only a smaller portion is based on the other senses. In fact, the human brain is better at detecting trends within shapes and patterns as opposed to gaining such data using spreadsheets.
Some firms have chosen to embrace these applications without consulting with their IT departments first. However, it would be a mistake to think that these applications are IT free, or that the IT department is no longer useful. Building and maintaining a strong relationship between the marketing, sales and IT department is always important. The reason for this is because it is necessary to be sure that the quality of the data is high. Furthermore, it is necessary as it ensures that there is a single version of the facts. The self-serving function seen in some BI applications allows for the user to carry out exploration for the data, without the need to ask the IT department for data marts or reports which are predefined. The reason for this is because it would slow down the analysis.
The compartmentalization of large organizations often gives rise to scenarios where the needs of one department will conflict with those of another. When this happens during a BI project implementation, it can cause that project to fail. When speaking of business intelligence, we often hear the expression “one version of the truth.” What this implies is that successfully implementing BI involves more than just high end software; there is also a need to deal with the politics and conflict that will inevitably occur between departments.
The effort that is required to properly model data is formidable. This task becomes more arduous when you consider the fact that the truth is rarely in plain view. Business information which is highly valuable will often need to be mined, and it will need to be taken from data which is disparate. The data from which the needed info will be taken will also exist in multiple databases and programs, much of which are incompatible. Because of this, it is important to realize that it could take months (and extreme attention to detail) in order to combine and prep the data in a way that will allow you to get the valuable info you need.
One large pharmaceutical company found it necessary to take data from fourteen different systems, and each of these systems handled a portion of its business which was distinct. The goal was to gain a solid financial picture of the multibillion dollar firm. The IT department for this company started the process by designing numerous software interfaces, which would be responsible for connecting the fourteen distinct systems to the data warehouse, which was used as a single place for information.
The challenge that this company faced was that the terms for the business and the financial aspects of the organization were designated differently in each of the systems which contributed the data. In other words, though the pharmaceutical company was able to bring all the data together, it ultimately failed. The reason it failed is because data standards were not properly utilized.
Acquiring data from a single location is only one part of successfully implementing BI. Companies must learn to place a greater importance on information content, as opposed to how this content is delivered. In the case of the pharmaceutical company mentioned above, they needed to spend months creating a new collection of standards which would allow them to cut the data into the proper context. While the reporting tools are a necessary component of BI implementation, they are useless if they aren’t combined with the correct data structure and information.
When it comes to establishing standards for business and finance, it is important to realize that this process doesn’t end. To reach a single version of the truth, it will be necessary to ask questions. And this process of asking questions is something that should be seen as an ongoing process. When a firm implements a BI project, even with established reports and definitions, situations may still arise in which people will want different definitions.
For instance, one department may need depreciation factored into their calculations, while another department may not need it at all. Sometimes, upper management may want to have costs taken from the portion of business where they are reported, and recorded in a standalone mode. Most companies handle these requests by designing a lot of reports which are ad hoc to deal with each request. This will eventually lead to problems, problems which could eventually cause the BI implementation to stagnate.
It is better to design a way in which the requests for change can be channeled through a committee, which would be responsible for reviewing them, and then accepting or denying them after review. That way, changes can be done within a central database, which will allow for the newer reports to be created.
In situations where the numbers may be divided into different departments, they will still be placed into one number for the whole company, a number which will represent the bottom line. It does require more work, but it is much better to spend more time altering things within the database. The truth should always be seen as a phenomenon which constantly moves, and because it is in constant movement, you must be able to do the necessary work for altering the database, as opposed to allowing each user to make adjustments within their reports.
It is a mistake to believe that there is a standard for BI implementation, and organizations which hold this belief are liable for making mistakes when shopping for an application. Many companies think that the best way to approach a BI implementation is via a purchase through their current vendor. They believe that the ERP, CRM or analytics tools offered by these vendors are sufficient for their needs.
The chosen vendors will often have an advantage over their competitors since they will be able to offer various cost incentives, not to mention the ability to leverage their current relationship with the firm. Many of these vendors will also take advantage of the fears and uncertainty that stakeholders will generally hold with regard to implementing BI. However, after using the products offered by these vendors, many organizations will find out later on that integrating their entire organization within the BI tools offered by these vendors is very expensive, more expensive than if they had carried out a proper analysis of the available tools, comparing them to their needed requirements.
Even for a small business, the usage of BI can increase its growth and profits, but only when it is properly deployed. In order for this to occur, the business can’t just use the products offered by any vendor, even if that vendor already has a solid relationship with the company. Unfortunately, many companies simply don’t shop wisely when it comes to choosing a vendor for their BI implementation, and this mistake will often cause the project to fail later on.
Prior to searching for a vendor, it will first be necessary for a company to have a deep understanding of the regions, customers or products which are profitable to their business. Having this information will better allow them to choose a vendor who will help them expand. Additionally, it will also be important for the company to have knowledge of the customers or segments which are causing the company to lose cash.
If the business has more than a few dozen customers, then the Pareto Principle (80/20 principle) will be revealed. In such cases, a few of these clients will bring in about 50 percent of the profits, while the rest will generate much less. It is difficult for many companies to figure out which clients belong in each category. By strategically using business intelligence applications, they will be able to answer these questions, and more.
However, businesses will need to look for vendors that can provide them with complete solutions. This includes client support which involves training from the vendor, as well as vendor representatives who are locally available. Regarding the product itself, businesses should only choose those applications which have the flexibility to sustain multiple types of data. The processing speed and ability to perform several operations simultaneously should also be a factor.
Is the application stable? Will it remain reliable in the years ahead? Basic security should be included, such as usernames and password systems. The application should also be functional, with the ability to drill through what if scenarios or queries which are ad hoc. As simple as it may sound, many companies have difficulty implementing BI because they choose apps with interfaces that are too difficult to use. Not only should the interface be easy to use, but the learning curve should be simple as well. The last thing that should be factored in is the cost. Unfortunately, for many businesses this is the first item on the list. They look at cost first, and all the other features second. However, high quality BI applications will be worth the price, and attempting to choose an application purely based on price can lead to major problems later on which are much more costly.
The best method for choosing a BI application is to do so by quantifying the needed criteria. Businesses should build a matrix which transforms the answers received into a percentage based answer which can be quantified.
The dashboard is best thought of as the “eye” which allows organizations to peer into their data, and it is the wisdom they gain from this data which will allow them to make progress. However, most of the dashboards offered by BI vendors today are little more than bar charts which have been placed on a page. Additionally, many of these dashboards are less intelligent than they should be. While the graphics have certainly improved, and users are better able to interact with the charts, the simple presentation which is shown on the screen has not been vastly improved, and the charts are less useful than they should be.
The dashboard is the most basic tool for providing business intelligence. The first dashboards appeared during the 1980s, and while some say they have improved since then, others argue that they’ve largely remained the same. It can be problematic to place pie and bar charts on a screen, and expect that the viewers will be able to understand their meaning and what is important. It is risky to assume that the viewer has the ability to interpret these charts, and draw the proper conclusion. Many BI vendors believe that pretty or interactive dashboards are the key to success; that they will assist viewers in making better decisions.
However, the failure to adopt BI tools, as well as the billions which have been spent (and lost) on these applications indicate that there is a need for change. It is inaccurate to say that the technology has failed; it is better to look at the reasons that more firms aren’t successfully using the technology. One good place to start is looking at the dashboards which are used to display the information.
Another problem with most contemporary dashboards is their inability to prioritize information. It is one thing to show charts which are geared towards a certain context. It is another thing to prioritize information in a manner which makes it similar to the news, with stories or headlines that people can watch in order to decide if they want to take a certain action. One reason why newspapers have stood the test of time, whether in an electronic or print form, is because they are shown in a format which the human mind can understand. How many BI dashboards are able to communicate the tale of its charts the way newspapers do?
The third problem that many organizations will encounter with BI dashboards is their inability to assist people in taking actions based on the info received. Most dashboards which are action enabled place an emphasis on the discovery of data, and they also analyze by looking at root causes. However, these features cannot compete with the traditional process where people collaborate via dialogue, discussing certain issues or opportunities.
Regardless of the visual appeal of a dashboard, it will need a great deal of planning. A dashboard which shows info that is inconsistent, or which doesn’t properly flow with other organizational data, may eventually cause a loss of confidence in the application, which will eventually cause departments to stop using it. The data comprised by the dashboard must be verified and analyzed for accuracy, because if it isn’t, it will be little more than a nice looking picture with no value. The implementation of the dashboard must play an important role in the project.
The development of service oriented architecture and other web based services is another way to improve dashboards. Organizations are now gaining the ability to construct their own dashboards, which will allow them to get the data they need to make decisions, and show the data in a manner that is appealing and easy to understand. Mobile apps can also be offered which will give easy to use data for mobile platforms. The solution to the problem of BI dashboards may be the adoption of BI tools which are self-service.
The success of a BI implementation will be heavily dependent on knowledge of how the organization functions. Those who work to implement business intelligence apps will need to know the location of the data, and how this data is used. Working with analysts who have this information can save the company millions of dollars over the long term. At the same time, many companies choose to outsource their BI projects to others.
The danger of outsourcing a BI project is that few outside sources will understand the policies, history, or customer demographics of a given firm. While these vendors may be capable of making up for a shortage of skills, they won’t be able to replace the knowledge of employees who have worked with the firm for years. When a company chooses to outsource its entire BI project, it will often find itself in a scenario where it will be necessary terminate the project, working in-house instead. This transition can be both time consuming as well as expensive.
Often, consultants will not be able to understand a business within a span of few weeks, especially if the business is large and established. Consultants are best utilized for providing resources that a company doesn’t have, with the goal of transferring this knowledge to in-house employees. Not only will this allow companies to reduce their dependence on consultants, it will also allow them to increase employee morale, as they gain the knowledge that will allow them to adopt the new processes.
In many companies, you will find few employees who actually understand the inner workings of their firm. Fewer understand the data and culture which is necessary for proper BI implementation. As a result, many companies find that they must depend on an outside source for this process, a consultant that will work with them during the project’s implementation. However, it can be extremely difficult to find a consultant who is truly interested in the business, and not just lining their own pocket. Even harder is finding a consultant who sees your business as being their business.
In this context, consultants are similar to mercenaries. While they may be highly trained, their loyalty to the organization which employs them is always in question. The reason it is in question is because they are outsiders, merely hired to complete a task. Their primary incentive for completing this task is money, and because of this, the quality and outcome of their work may be lower than it should be. At the end of the day, the consultant is there to do a job, and that consultant makes his or her money by working with multiple clients. As a result, their concentration will often be divided.
The problems mentioned in the above paragraphs are compounded when companies choose consultants based on cost, rather than quality. When planning a BI project, many companies focus too much on the consultant’s hourly rate. A greater emphasis should be placed on the deliverable. It is important to remember that price is what you pay, and value is what you get. Paying a lower price doesn’t guarantee that you will get greater value (and the same can be said for paying a higher price as well).
Many companies choose to emphasize price over value, and as a result, they often lose far more money over the long term than they would have if they had focused on value. For example, let us say that a firm decides to a hire a consultant for their business intelligence project. The firm chooses this consultant primarily because he is “cheaper” than the others. Little attention was paid to the value of his work.
After the BI project is completed and the consultant is on his way, the company then begins having problems. Not only did the consultant do a poor job during the implementation, he is no longer available and fails to respond to emails and phone calls. The problems with BI continue to grow, and the company spends huge sums trying to fix them (unsuccessfully). The problems begin to affect the customers, and as a result, they begin using rival companies. Eventually, the company abandons the BI app, and the amount of money they lost in customers and trying to repair the problem are ten times higher than the rate they paid the consultant.
This is what happens to companies that emphasize price over value. A price is a price. It may be high and it may be low. But it shouldn’t been seen as an indicator of anything, unless it is compared to the value that is being offered. When choosing a consultant, it is important to look at value and deliverables first, rather than price.
The first step towards successfully implementing BI is to insource rather than outsource. It is much better to use an internal source for implementation as opposed to an outsider who has very little stake in the project. The loyalty and quality of a consultant will always be questionable, and they will never have the insight that long term employees will have. An in-house team will have a much greater stake in the project, as they are a part of the company and its outcome will help or hinder them.
If an in-house team doesn’t currently exist, then the company should create one. Employees should be recruited or trained who have the ability to implement the BI project. If a consultant must be used, he should always be regarded with caution, and the firm should seek to extract as much knowledge from them as possible so they are no longer needed. The goal should be to transfer this knowledge to the in-house team, where it can be used for the creation of a BI project which is home grown. Creating an in-house team for BI may be time consuming up front, but the strategic wisdom that the company will gain over the long term will be well worth it.
When showcasing their products, vendors will typically show their applications processing data which is no more than a hundred thousand records. The problem with such demonstrations is that they’re often insufficient for the needs of a large company, and this isn’t discovered until the production implementation is started. Most large enterprises need applications which are capable of handling hundreds of millions of records, and there are a few enterprises which need applications capable of handling billions of records. Clearly, an application that can only handle a few hundred thousand records isn’t useful to these organizations.
Despite this, many organizations choose to use such applications anyway, and the end result is inevitably disaster. Even if an application is capable of handling the data a company currently has, what about a year from now? Two years? BI applications must be scalable, because the inflow of data will be. While some companies wisely choose products which can support larger volumes of data, they fail to factor in both the volume of users as well as the concurrency.
It is important to understand that business intelligence involves a great deal of data, raw data that will have to be integrated within multiple systems. Only then can this data be turned into information. Performance management is an important consideration because it allows an organization to leverage this information. In many respects, the information is far more valuable than the actual data, since the process of data transformation and integration will result in info that can be used to make strategic decisions.
While numerous executives have acknowledged that BI can provided data in the form of reports, dashboards, and querying, they still felt that most of these mainstream products were inefficient. The reason for this lack of content is because simply reporting information will not lead to improved results. Actions must be taken based on the information which will allow the company to grow. While having access to BI is crucial, it often comes at the expense of departments requesting enhancements that IT simply can’t provide.
The ability to extend BI throughout the company is critical, and will determine the company’s profitability. However, management and improvement are not identical. It is possible for a person to manage and break even. Improvement, by contrast, is the way in which you win. Performance involves the ability to deploy BI. Without performance considerations, business intelligence has no direction.
Business intelligence is the platform that will allow for queries and reports. It should be considered the foundation. However, performance management is the mechanism by which strategy will arise, and it will give businesses the ability to leverage the systems and processes that can ultimately enhance their performance. A failure to consider performance management is one of the key reasons why BI implementations fail. BI only works when data is attached to decisions, and performance management in conjunction with BI is the way in which this happens.
Performance management and business intelligence should never be implemented in isolation. When they are integrated, the success of the project will grow. While software can enable you to do many things, it is the thinking that will ultimately decide the outcome. It is necessary to be able to visualize the possibilities to take full advantage of PM and BI.
The first step in successfully managing performance is to choose a vendor/app that is capable of handling the data a company already possesses. Additionally, the chosen product must also be scalable. Once a vendor/app has passed this test, the company must also ensure that the product will be capable of supporting both user and data volumes. Because runaway queries are a problem for many departments, the chosen product should include safety mechanisms which are capable of arresting them.
This is crucial as not every company has the resources to use DBA monitoring which is dedicated. Though this type of monitoring can find and destroy negative query threads, doing so can be very costly. Success with a BI project will ultimately be determined by making the proper choices, as well as choosing the proper technology and processes. However, the importance of people should never be underestimated it. It is the people who will ultimately make or break the project.
While business intelligence is one of the key components in obtaining performance management, this is only possible when the business intelligence is available across the enterprise. Companies today are tasked with making business decisions which are effective; however, these decisions must also be made within a timely manner, and they must be made throughout the key areas of the business.
In the past, it was possible to handle company challenges within departments; today, both managers as well as executives must be able to handle changing conditions within the level of the enterprise. The ability to properly utilize information throughout the enterprise will allow one version of the truth to emerge; one which is actionable.
Reference – Thanks to Raed Alhadhoud for sharing the base for this white paper.[is-gateway name="Exforsys" id="social"]