At this point, you should be at least ready to consider a business intelligence (BI) solution for your midsize company—and you may even be outright convinced that it's the right tool for your business. So how do you go about successfully adding a BI solution without disrupting your company? Without breaking the bank? Without having to add staff members with specialties you've never even heard of before? My goal in this chapter is to help answer exactly those questions, with practical advice for bringing BI into your midsize company.
Before we continue, I want to just briefly review and summarize some of the hurdles that BI has traditionally faced. Keep in mind that these hurdles are potentially a problem for any size company; as I go, I'll outline why big companies choose to accept these downsides, and how midsize companies can avoid them entirely.
BI systems are typically seen as incredibly complex. That's because, to a large part, the underlying business systems and processes that a BI solution must model are also complex. In other words, if you have a huge, complex company, then your BI system is likely to be huge and complex also.
Big companies accept this as a fact of life simply because everything in a big company is big and complex. Payroll systems. Accounting systems. Customer relationship management (CRM) systems. Enterprise resource planning (ERP) systems. Asset tracking systems. Heck, just filing an expense report in a big company can be like trying to pass a bill in Congress— everything is complicated. To a large degree, big companies can't avoid that complexity. They're subject to a lot of legal scrutiny, for one thing. Microsoft, for example, has to be very cautious about how its various business units interact, simply because they're almost continually sued over the results of those interactions.
Midsize companies, however, can often avoid some of that complexity—and typically try very hard to do so. Midsize companies don't often have international divisions, multiple lines of business, and mergers and acquisitions to deal with. Midsize companies often use off‐the‐shelf software or services for things like accounting, customer management, stock management, and so on. That makes midsize companies inherently less complicated, and a less‐complicated company will have less‐complicated options for BI.
The analogy I've used before is that of a house: Building a giant company's BI solution is a lot like building an entire city. No other city is going to be exactly like it, so you wind up with a lot of complex architectural and design elements. You have many different buildings, each of which have a different purpose and must be built for that purpose. You can't use off‐the‐shelf engineering numbers; you have to work all the math from scratch. Nothing is standardized; everything will be completely custom and there will be a lot of it to deal with. All that customization and complexity makes the building process complex: Permits are complicated (and there are a lot of them) engineering drawings (tons of them) are more complicated, even things like grading plans and landscaping designs will naturally be more complicated. The upside is that you get an entire city in the end; the downside is that it takes a lot of time, money, and effort—and a lot of wasted effort because "custom" also means a lot of wrong turns, backing up, and re‐doing things. Another downside is that trying to build it all in one go will mean a lot of backtracking and wasted effort, a lot of redone work, and a lot of projects that start but simply never get finished.
For me, a midsize company's BI solution is more like a nice house in a master‐planned community. There's still a lot of quality in the construction—in fact, the quality can often be higher than the custom mansion because the tradesmen are building several units that are basically the same, and they work out all the glitches early on. The house can still have a lot of semi‐custom options and elements, so they're not cookie‐cutter (because midsize businesses certainly aren't cookie‐cutter), but many of those options are pre‐engineered, so they're easier to build and less expensive, and they can be plugged into the base home design without a lot of grief and turmoil.
So are BI systems complex? Yes—if the underlying company is complex. Midsize companies tend to avoid that kind of complexity on their own, however, so a midsize company BI solution is likewise much less complicated.
Complexity leads to expense, and because BI systems are typically seen as complicated, they're also typically seen as expensive. And they can be. Big businesses typically need them to be expensive because that expense is what pays for a BI system that can match the underlying complexity of the giant business itself.
Midsize businesses don't need to automatically spend a fortune on a BI solution. There's just no need. Prepackaged BI solutions—what I'll call a software appliance—can be purchased for a much lower, fixed price than a custom‐built, massive‐enterprise BI project. Software appliances are entirely self‐contained—you may just install a single software application onto a server, or you may even purchase the solution from a value‐added reseller who just shows up with a preinstalled machine and plugs it into your network. With a software appliance or "prepackaged" approach, your costs are also known fully, up front, before you make an acquisition. You can decide then if it's "expensive" or not, and know that the price tag is all you'll pay—because the BI solution is prepackaged and selfcontained, there's no chance for scope creep, for never‐ending implementation projects, or for consultants that have been in one of your offices for longer than half your employees.
I've saved my worst‐case BI story for this last chapter. I once worked for a company—a large credit card‐issuing bank—that decided to implement a major BI project. They were sticking with a specific division of the company, figuring that would be easier and less disruptive than trying to go whole‐hog with the entire company all at once. This particular division employed about 12,000 people (although many were part‐timers), and had literally millions of customers.
The BI project took 2 years before it was finally complete and every consultant went home. In the meantime, the division had to bring on another 1000 employees to offset the resources that wound up being tied up almost full‐time on the BI project. They spent forever figuring out what reports they would need, what dashboards would look like, where data was coming from, where data needed to go, what spreadsheets would contribute and need to be updated—it was nuts. There were seven different data warehouse designs in all, because every time they'd complete one design, they'd realize that it was missing a few things and end up having to start over.
Twenty IT people—including myself, unfortunately—were on this project almost full‐time for 2 years. We emerged from it completely unaware of what else was happening in the company. Most of us occupied fairly senior positions in IT, yet we were essentially clueless about the state of our own department because we'd been entirely focused on this BI project for so long.
"Disruptive?" You bet. BI can be disruptive. Now, our project was not a shining example of BI even in a very large company, but the point is that BI can get away from you, and that's when it starts being disruptive. Can you imagine a tenth of your IT staff occupied for several months on nothing but a BI project?
The good news is that, with a prepackaged BI software appliance designed for a midsize company, you'll never have to imagine that. There's no discovery to be done. No reports to design. No data warehouses to design, redesign, discard, and design again. No dashboards to design. It's all done for you—all you have to do is install it and configure a few connections. It doesn't have to be any more "disruptive" than installing a new messaging server into your infrastructure. Yes, someone will have to spend some time on it—but that time will be measured in days, not months or years.
There are a few ways you can choose to approach BI, even as a midsize company that plans to use a prepackaged software appliance. You could, for example, go for a companywide BI solution that encompasses everything you do; you could choose to instead focus on a smaller initial project. Your choices in this matter will help define your costs, so what choices can you make that will minimize acquisition and implementation costs, while delivering real, tangible value?
Before I dive in, I want to re‐emphasize one point I've tried to make throughout this book: BI is not just reporting. It's easy to see where someone might think BI was just fancy reporting because BI tends to focus on dynamic reports, static reports, scorecards, dashboards—all of which are, really, a kind of report. True BI, however, should be the whole, integrated reporting + analysis + planning. Call it Corporate Performance Management if you like (some folks do). Gather data. Analyze it in various ways. Make tentative decisions, and see how they affect the data outcome. Make final decisions, and have them modify your planning systems dynamically to make implementing those decisions seamless and easier. Repeat, as shown in Figure 4.1.
Figure 4.1: The Corporate Performance Management life cycle.
This is what true BI is all about. Not just delivering data in visually‐stunning dashboards, but giving you real tools to spot trends and underlying causes, to make decisions, and to make those decisions happen.
In previous chapters, I've mentioned a couple of approaches to data warehouse design. These are both very high‐level philosophies, both espoused by very high‐level experts in the field. The first is the topdown approach, which says that you have to start be creating a data warehouse for the entire company, then break that down into smaller data marts for different departments and purposes. The second is the bottomup approach, which more or less states the opposite: That you start with smaller data marts that are very task‐specific, then gradually aggregate them into a companywide data warehouse.
Proponents on both sides of the debate have very scathing and witty things to say about their opponents, and I don't propose to have a final answer on the subject in this short book. However, what I will say is this: Philosophy and debate is all very well and good, but the practical realities of the business world sometimes mean you make a compromise. For me, bottomup is that compromise.
Yes, you have to think about your entire company. But implementing a companywide BI solution is obviously more complex than one that just serves a specific department. As we've already seen, complexity = time = expense; a companywide system is desirable but it isn't always the most practical starting point for a midsize company. What's often more practical and approachable is to implement a prepackaged BI software appliance for one part of the company. Learn how to use it. Gain some experience with it. Then, gradually, add in another part of the company. And another. And another.
Will a BI solution built in pieces be as good as one that was built from the top‐down approach? Well, that depends. My normal answer would be "maybe, maybe not," which isn't very definitive—because it depends a lot on how well the pieces were designed. My answer in this book, however, is "it doesn't matter." That's because you're not building the BI solution, nor are you building the data warehouse; you're using a predesigned one. If you start with one department or the entire company, that prepackaged software appliance is the same either way. You can't make a design mistake—but you can save yourself a lot of time, effort, expense, and even frustration by starting small, and working your way up to the entire companywide view.
Depending on the exact solution you choose, you might wind up with separate, independent BI systems for different divisions—which can be united into a companywide system. Other BI solution vendors may offer a single system that can start out small and grow to include other departments, and eventually the entire company. This is a point to investigate as you begin researching and evaluating specific solutions; neither approach is wrong, but understanding the approach that a vendor has chosen is certainly important.
I once worked for an international retailer. We shipped product to hundreds of stores from three distribution centers worldwide; we also managed a small direct‐mail business for customers who didn't have a store in their immediate area. One of the company's biggest frustrations was our shipping costs. We'd negotiate the best deals we could with various carriers, but there was always this sense that shipping was a vast, black pit into which we just poured money. Our executive team was notoriously detail‐oriented—they'd reengineered a number of our business processes and had saved hundreds of thousands of dollars in so doing. But shipping just felt like this untouchable component—it cost what it cost, and all you could do was negotiate lower rates. They were also frustrated with what they perceived as inconsistent delivery times and other details—they couldn't make sense of exactly what their money was getting for them.
It was the first area the company chose for a BI solution. In fact, it was the untouchable, unknowable nature of shipping that made our executives even consider a BI solution. Everything else they'd tried hadn't given them any insight into shipping; maybe BI could prove itself by doing what they couldn't accomplish on their own.
A couple of months later, we had a pretty basic BI solution in place and our executives were already getting answers—surprising ones. Their strategy had been to offer exclusivity to a given carrier in return for deeper discounts, and to send packages that were as close as possible to the carrier's maximum size and weight. Some what‐if scenarios in the BI system suggested that even with modest discounts, we'd save money—and get better delivery times—with somewhat smaller packages, and if we used several carriers, selecting them based on the proximity of their hubs to our stores. Within a year, the BI system had paid for itself in shipping savings.
Not long after, we started plugging the BI system into more areas of the company. We could punch in proposed sales figures for a given month and see exactly what we'd probably be spending on shipping, see if the distribution center staff would need more or fewer parttimers to handle the restocking workload, and even predict how long the loss prevention department would need to audit the sales. As I was preparing to leave the company, a single dashboard could even tell you how much loss to expect for a given sales amount (it was surprisingly non‐linear—we saw greater losses at very low and very high sales amounts, but less loss for average sales), leading to a whole new set of initiatives to combat that loss. It was exciting.
The lesson is to focus on where you have the most pain. Start your BI effort there. There are a few reasons for doing so:
Select the area of your business that has the most of these factors, and you'll be giving a BI solution the best opportunity to help you improve the business.
Like most appliances, software appliances are often modular in nature. Need an icemaker for your freezer? Want to add the ice cream maker attachment to your kitchen stand mixer? Want to add a new reporting module to your BI solution? No problem: Extensible appliances are nothing new, and they give you the ability to buy just what you need, just when you need it, so you're saving money and effort.
Every BI solution vendor will obviously follow different patterns for their tool set, but in general, the capabilities break into two halves:
Figure 4.2: Using a dashboard from a BI analysis package.
Figure 4.3: An example BI report.
You may find other modules, too, such as modules that support Microsoft Excel connectivity, which can be a boon for spreadsheet jockeys in your company who are comfortable using Excel for data analysis.
Whatever you do, make sure you have a plan in the back of your head to extend your BI solution to other areas of your company. Discuss those possibilities with each BI solution vendor that you speak with and let them help guide you toward a solution that can accommodate those growth plans. Your plans might change, but having a solution in place with the right flexibility will help ensure that you can get where you want to go.
I've been involved in a number of high‐priced software acquisitions, and I hate negotiating with salespeople. Frankly, I'm not very good at it. I never know if their first price is really the price or if they expect me to haggle them down. If they do, I don't ever understand why they just couldn't bring me that price in the first place.
When it comes to prepackaged software solutions, however, you're rarely going to find yourself having to negotiate—and you shouldn't have to with a midsize company BI solution. Solutions like this are a known quantity for the vendor; in serving a midsize business audience, good vendors will focus on standardized pricing.
While on the subject of price, however, I do have a caution to offer: Don't seek out a do‐ityourself solution. Even if you've got the world's best data warehousing and BI expert on your staff, a roll‐your‐own BI solution is nearly always going to cost you more time and money in the long run than a packaged solution. I've seen just a couple of midsize companies go the build‐our‐own route, and after a couple of years of sustained effort, they finally gave up and just bought something. When they did, they got a system that did more than their homegrown system, had it up and running in a few days, and spent less on software maintenance than they'd been paying the two staffers who had developed and were maintaining, their in‐house "solution." One of those companies' decision was driven purely by staffing—their BI expert quit, leaving them without anyone who understood how the BI system had been built or how it worked under the hood. They had no choice but to either hire someone else—and salaries in that specialization had gone way up at that time—or buy a prepackaged solution.
I've said before that midsize businesses can and should implement a right‐sized BI solution without needing expensive consulting services or specialized new hires. Here are some tips for doing so.
Look for a BI solution that could accurately be described as a software appliance. I've used that term before, as a synonym for prepackaged; what exactly does it mean? Consider your corporate firewall. There are a couple of ways you can go when choosing a firewall—a dedicated firewall software package, which often runs on an OS such as Windows or Linux, or a powerful hardware firewall, like those from Cisco. These all involve a fairly complex level of configuration, and you'll probably need an expert to at least set the thing up initially, if not to help maintain it on an ongoing basis. Configuration often requires something akin to programming, which definitely requires specialized expertise. In some cases, you may need other pre‐requisites in order to make the firewall solution work, such as an authentication server, logging server, and other elements.
The point here is that you have to buy the software and/or components, hook it into your infrastructure, redesign your infrastructure to accommodate it, then fully program the thing with all the settings it needs to operate and that you need to fit your business needs. Alternatively, you buy a firewall appliance. This is a box that plugs into AC power and into your network. Configuration is often much simpler, typically Web‐based, and usually wizard‐driven. You have fewer options to worry about, fewer things you could potentially do wrong, and you likely won't need an expert to get the thing working properly. Many can even self‐discover certain information about your network so that you don't have to configure those things manually.
I'm using firewalls as an example because they're a common network element that can be had both as a "complex" solution and as a prepackaged, preconfigured appliance. For midsize companies, I recommend the latter approach for a BI solution: Find an "appliance."
It might not be a literal box you plug in, but it shouldn't be far from that. It should:
That's how you get a BI solution that your current IT team can deploy. In fact, look for a BI solution that's available as a free trial. If the vendor is so confident of their ease‐ofdeployment that they feel they can offer a do‐it‐yourself trial—with perhaps a short PDF "evaluator's guide" to walk you through setup—then you've probably found something that can accurately be described as a "software appliance."
As I've written earlier in this chapter, your ideal BI solution will often come broken into modules so that you can buy just the bits you want. Another approach is to offer "editions," where successively higher editions offer greater and greater functionality. I prefer the modular approach because with it you can buy just what you need; with "editions" I always find myself stuck with the next‐higher edition than I really want just because of one or two "must‐have" features.
Spend some time working with trial versions, and/or speaking with the solution vendor, to understand exactly what capabilities each module or edition offers. Even if you're focused on saving money, don't forgo critical functionality—doing so could spell failure for your BI project, and many companies don't like to give something a second chance if the first attempt fails. In other words, don't buy more than you need, but certainly don't buy less, either.
As I've written before, you need to make sure you're buying a solution that can grow with you—and you need to understand how that growth will physically happen. Here's an example: Years ago, back when Microsoft Exchange Server was still new, Microsoft released a "Standard" edition and an "Enterprise" edition. The primary difference between the two was their storage capacity: The Standard edition had an arbitrary limit on how much it could store, while the Enterprise edition supported the maximum Windows disk size at the time.
The problem occurred when people on the Standard edition ran out of room and decided to upgrade. There basically was no upgrade path; you had to buy Enterprise, install it, and then migrate all of your mailboxes to it—and then decommission the old server, typically without receiving any credit or refund for the cost of its license.
Make sure your BI solution doesn't stick you in the same boat. With a modular product, you should be able to just add on new modules as needed. If you're using a product that's built around feature "editions," make sure you have a way to grow to the next edition without having to start form scratch. That might involve paying an upgrade fee and entering a new license code, for example, rather than installing a whole new product and migrating your data, reports, configuration, and other work.
How will your existing IT team manage your new BI solution? A BI solution—even one that is prepackaged as a software appliance—still has maintenance and monitoring requirements. Someone needs to make sure it's up and running, and that it's running in a healthy condition. If something goes wrong—like it gets low on disk space—you'll want to know before that becomes a real problem. Will the BI solution need periodic database maintenance? Who will perform that? How hard is it to do?
The more pre‐packaged and appliance‐like a solution is, the more I would expect it to do these things largely on its own. Sure, you'll still have to do OS‐level maintenance—patches and so forth—but your IT staff is well‐equipped to do that kind of basic upkeep. The solution might maintain its own database, and might even take care of its own monitoring, perhaps by sending someone an email if a problem condition is detected. Some solutions might offer options for sending notifications to an operations monitoring console, although the more pre‐packaged the solution is, the less I might expect that option. I would certainly expect an appliance‐style solution to provide its own monitoring, often through an administrative console.
Ideally, the entire product should be easy to administer, perhaps through a Web‐based console. Figure 4.4 shows an example of how easy it should be to add new data connections to the data warehouse, for example: A nice, well laid‐out Web console can make otherwisecomplicated tasks easier for your existing IT staff to understand and accomplish.
Figure 4.4: Administration through a simple Webbased console.
If a BI solution uses an external database—maybe it requires you to provide a Microsoft SQL Server, or Oracle server, for example—I might expect to handle the maintenance of that database myself. However, such a solution would not be an "appliance" in my opinion; appliances don't require you to "Bring Your Own Database."
So you can deploy a midsize BI solution with your existing IT staff; can you do so without distracting and disrupting your day‐to‐day business? The trick in doing so is to require a minimum of cost, specialized expertise, and specialized software, as well as a minimum of training. Let's see how a properly‐designed midsize BI system might accomplish that.
I've already explained how a fixed‐price BI solution is desirable, and how a modular solution design lets you buy just the pieces you need. Those factors, combined with the ability of your existing IT staff to deploy and maintain the BI solution, leads to a lower startup cost. A low startup cost helps contribute to a less‐disruptive BI implementation project; fewer eyes will be nervously watching every step, giving the project an opportunity to be completed and put into use without anyone panicking about the mounting expenses. Besides, high‐priced systems in midsize companies almost always lead to agonizing, sometimes antagonistic battles about whether the company should even pursue the solution. That sort of thing puts everyone off‐track, disrupting managerial relationships and distracting people from day‐to‐day business. A lower startup cost lets everyone have a better discussion about the project's merits without quite as many eyes bugging out over an exorbitant price tag.
Finally, a fixed price solution makes everyone involved with the company's financials feel better. Start talking about consultants and services and fees, and everyone gets nervous because they just know the bill will keep going up and up and up. An appliance‐style solution with a fixed, known‐up‐front cost is a known quantity that can be considered and accepted; knowing that the price won't continue to climb is another way to prevent disruption.
There's no better way to disrupt a company than to bring in a truckload of high‐priced geeks—sorry, consultants—who will be not only working on the project you hired them for but also disrupting everything else going on in the company. Before long, half your IT staff has stars in their eyes and are ready to run off and join the high‐paid consultants, and the consultants have managed to halfway redesign everything in your data center that wasn't broken.
A prepackaged, appliance‐style solution avoids that by simply not requiring very much in the way of specialized expertise. The expertise is builtin to the product, ready to be used; you don't need much more to get it installed and working.
Users should be able to access much of the BI solution's analysis functionality through simple‐to‐use, self‐service consoles. Web consoles are more easily accessible from a variety of devices and OSs, and give your users a single, consistent "knowledge portal" through which they can access a range of information. Web consoles can offer rich functionality, too—Figure 4.5 shows an example of a complex analysis that a user can conduct through a Web interface.
Figure 4.5: Easytouse Web interfaces minimize disruption.
Web interfaces also mean you don't have to deploy software to everyone's desktop. That's a huge thing, given how disruptive software deployments can be—combined with the training and pain almost always associated with new software.
Speaking of training, you can minimize the learning curve for your users by selecting software that's intelligently and intuitively designed. For example, Figure 4.6 shows an excerpt from a Web dashboard. Someone looking at this might wonder, "Why are margins in golf equipment the way they are?" A well‐designed user interface will allow users to drill down and answer that question by doing what the user will tend to do naturally: Click on the "Golf Equipment" item.
Figure 4.6: Starting with a welldesigned user interface…
If clicking leads the user to another layer of data, they'll continue to explore. Figure 4.7 shows where the first click took them—to a breakdown of different types of golf equipment—an intelligent next step in a line of free‐form investigation. Users don't need to know any database query languages, or even understand that they're using a BI system or a data warehouse. They're just exploring company data to look for patterns, trends, and underlying reasons.
Figure 4.7: …allows users to drill everdeeper into the data…
By continuing to support additional layers of drill‐down, this user interface allows a user to continue looking for the root cause of the problem. Here, it appears that putters are the lowest‐margin item. Should the company just discontinue putters? Another click—and another drill‐down—is warranted.
Figure 4.8: …until they find the root cause.
As shown in Figure 4.8, it's one brand of putters that's actually dragging down the category. Now, this user can make a business decision based on facts, not on gut instinct or bad assumptions. It took longer for me to write this narrative than it would have taken a real user to actually reach this conclusion—all without any format business analytics training. That's the value of a well‐designed user interface: immediate results, less disruption to the business.
Users who are comfortable with an existing toolset should be able to use them, if possible. As I've mentioned before, many midsize business users are incredibly proficient with Excel spreadsheets—so why not let them continue using a tool that they're skilled with?
If you have some of these "spreadsheet jockeys" in your company, having a BI system that supports them—by delivering BI data to Excel, and allowing them to work with it there—is a must‐have feature. Although Excel isn't for everyone, it can be incredibly powerful and empowering for someone who has invested the time to use it, and because they're working in a comfortable, familiar environment, you'll find that these "spreadsheet jockeys" will be amongst the first to grasp the power of BI, and to start making a return on your BI investment.
Big businesses can often afford a big sacrifice if they see a big benefit. Midsize companies, however, have to be a lot more careful. Disrupting a dozen employees for 3 months is hardly even noticeable for a giant company; for a midsize company, however, it can distract vital assets for an unforgivably long time.
That's why BI isn't "one size fits all." What works for an enormous enterprise—months of fact‐finding, specialized consultants to build data warehouse designs, lengthy implementations and even lengthier training—just doesn't fit a midsize business model. What can work for a midsize business, however, are smaller‐sized BI solutions that— although they would never work for a huge company—fit nicely into a midsize company's needs, available resources, and available time.
I've used the word prepackaged a lot in this book, and in the beginning I worried about using that exact term. Prepackaged, to many people, seems like it might mean lowerquality, like a prepackaged, frozen dinner. That's not what I mean at all. In the technology industry, prepackaged software products power most aspects of most midsize companies, from financial management to customer relationship management. Even the office productivity suite you're using—a word processor, a spreadsheet, and perhaps a small database application—are prepackaged. Prepackaged does not mean lower quality or less powerful. For me, prepackaged means an easy‐to‐install, easy‐to‐learn piece of software that handles 90% or more of the functions that 90% of business users require. It means no lengthy, expensive customizations required. In the world of BI solutions, prepackaged solutions designed to fit a midsize company are the best way to implement BI. Frankly, even huge enterprises would use prepackaged BI solutions if they had the option—they'd save a fortune and a lot of time. This is an advantage that midsize companies can capitalize on: The ability to use a prepackaged BI solution brings you big‐company power without the big‐company price or time commitment.
We've covered a lot of ground in a short space. In the first chapter, I explained what "business intelligence" really is, and why you might want it in your company. In the second chapter, I explained the ways in which BI becomes a reality—starting with how you assemble data and analyze it to make better decisions for your company. The third chapter was a chance to play "mythbusters," debunking concepts like the "fact" that BI can disrupt your business or that BI is only for large companies. In this chapter, I offered some tips and practices for bringing BI into your company in a productive, practical manner.
I hope you've found this information to be useful, and I hope that BI is on your radar not only as a useful set of technologies but as an obtainable, practical idea for helping you and your company make better decisions about your future. Thanks for reading.