Business Intelligence What SAP didn't tell you about creating and using business intelligence, and why

Creating value through the use of information systems to gain critical insights into how a business is functioning, meeting the needs of customers or not, coordinating with suppliers and managing costs is one of the greatest values of Business intelligence (BI) systems. Intuitively, BI and analytics are seen as a means to significantly reduce risk while increasing the profitability of a business (Yeoh, Koronios, 2010). The question that often arises in any organization after implementing a BI or analytics system is why the strategies created based on the expensive BI and analytics system are not more effective and profitable than those executed before (Chussil, 2005). This paper analyzes the reasons why BI and analytics projects succeed or fail, and it often has little if anything to do with what an enterprise software tells a company during a sales cycle, providing insights into what SAP fails to tell customers when they purchase software.

SAP Never Tells A Client That Aligning to a Clear Business Need or Objective is Critical For BI Applications to Deliver Value

Ironically the need that often drives enterprises to seek out a BI, analytics or EPM solutions during the evaluation process take a secondary role relative to the system and process-based integration points that take the majority of time to complete (Werther, 1999). SAP fails to tell customers that training is required on how to use these BI platforms are provided to customers. There is an element of truth to that criticism, as often SAP and other enterprise software vendors will send in six to ten sales reps, professional services experts and process re-engineering teams to sell their services once an application has been purchased, all at an incremental cost to the user (Chussil, 2005). Organizations purchasing enterprise software often get mired in the minutiae of implementing the expensive software they bought and less on staying on track to solving the problems they had in the first place (Ariyachandra, Frolick, 2008).

An example of this comes from Suzuki America, which purchased the entire SAP suite of BI applications to better manage analytics and reporting of their dealer channel selling the Suzuki autos. The VPs of Marketing and Sales designed with minute detail every metric they wanted on the dashboards, down to the type of measurement indicators and update frequency. The IT staff at Suzuki diligently worked to create mock-ups and mastered the integration points throughout the SAP system. SAP has an exceptionally easy series of Web services interfaces for integrating with legacy systems, and the Suzuki IT team had the entire system up and running in less than a month. All of this occurred while the dealer channel was swelling with inventory as interest rates climbed and the economy began to slow down in 2007. The result was that as inventories climbed, more analytics and KPIs were added to the dashboard. Soon, the limits of SAP were reached and the dashboard project was scrapped because it had so many metrics it was unusable. This is a prime example of what happens when an organization takes its eyes off the initial goal and gets too enamored with technology. A friend was the Market Research Manager at Suzuki at the time and relayed this story, which he says was one of the more frustrating professional experiences he has had.

Having a clear objective is critical to creating a culture that will accept change and take ownership of new systems and processes (Sherman, 2006). This is one of the most critical pivot points in any BI, analytics or EPM implementation. Any implementation must stay on-goal and focused if it is going to have enough stability to make it through the many other challenges on its way to permanently adding value to an organization (Ariyachandra, Frolick, 2008).

SAP Never Warns Customers About Change Management

Just as the senior management team at Suzuki vacillated and lacked focus on just exactly what the goal was of their dashboards, a small manufacturer of computer equipment, Orange Micro, had a CEO that galvanized change. Known for not using a laptop and handwriting his notes, he was a man in his 70s at the time and had achieved remarkable success in the IBM sales organization during the last thirty years. He understood how well BI and analytics could transform a business; he had sold some of the very first BI systems decades ago. When his manufacturing business was having trouble staying up with the order rates and forecasts...

He not only started using a laptop, he authored the majority of the reports and made it clear he expected his marketing, sales and supply chain managers to do the same. Adoption was immediate, accurate and the company, within 120 days, was already seeing the results. This story illustrates a fundamental concept of any successful change management strategy, and that is executive leadership must be vested, completely committed to the change for it to be successful (Srica, 2008). When senior management gets onboard a change management initiative, the odds drastically increase of its success (Sherman, 2006) which is a point that SAP never makes when discussing their software.
SAP Never Defines How Legacy and Enterprise System Integration Is More Difficult than it Appears

One of the country's leading producers of emergency vehicles has an SAP R/3 system running its manufacturing operations and had opted to use their own databases to manage the change orders that customers file to customize their fire trucks, ambulances and mobile command posts. A change order is a document that moves through manufacturing and defines what modifications are necessary to modify a vehicle to meet specific needs. These change orders cost not just materials but time and re-work of the production flow. This manufacturer wanted to know how much this was costing, and if certain change orders should be rejected or not. Using the analytics and BI applications from SAP, they tackled this problem and found that nearly 60% of the change orders requested never actually made it to the purchase order stage (meaning the customer was just "kicking tires" so to speak to see if the modification could be done). The results showed that the smallest customers were using change orders to hold their place in the production line as they worked with local governments to sell vehicles. Change orders had turned into a way to save a spot in line, not an actual change request to a vehicle. Based on this, the integration of systems, which took months and millions of dollars to complete, was taken on successfully. Without the insight into how the change orders were being used however, there would have been no compelling need or goal to drive the integration efforts forward. This was a prime example of a business need to provide greater clarification and control over the process driving more effective use of integration. SAP had never mentioned the complexity of this process.

Key Performance Indicators and Metrics of Performance Vary By Strategy

Printronix began business with an innovative dot matrix technology and hammerbank design that could produce reams of printed output in minutes. It was ideal for the massive enterprise accounting systems that dominated mainframe and minicomputers during the 1980s and 1990s. As the market shifted to PCs, Printronix moved into graphics printing and bar coding, material handling, and other vertical markets. Manufacturing operations were run on an SAP R/3 instance and Business Objects, SAP Analytics and BI, and several other applications were in use internally. The Finance VP was one of the founders of Printronix, as was the Marketing VP and CEO. All three had defined a series of just ten metrics they would manage the company with very day. For decades the three would meet at 10am in the Finance VPs' office, review the figures, and choose their strategies and decisions for the day.

As the marketing, sales and service organizations grew, the product strategies became more complex. The company went into a build-to-order and product customization strategy, which forced the forecast of top assemblies, or the key component used for creating a printer. This led to a proliferation of analytics for everyone in the cross-functional team to use. Soon, there were well over three dozen reports in use. The CIO stopped by the morning meeting and asked why there had to be so many reports generated on the build-to-order program, and was told that at just 11% of revenue, that many reports was definitely overkill. An e-mail went out later that day from the CEO asking for just a single report for the build-to-order program and rationalization for any further ones would have to be approved by him. The company found that out of those dozens of reports, only five metrics really mattered. All that effort from IT and just a few metrics being used -- and they were variations from the ten the founders…