You are on page 1of 12

2 0 1 1 W H I T E PA P E R

Embedding BI into Your Software Solution Best Practices

by Michael Emerson, Integrated Growth Solutions

Embedding BI into Your Software Solution Best Practices

Analytics can add 20% to 30% to top line revenue.

More and more software companies are considering the addition of an analytics module to their product suite. This strategy has compelling business value--analytics can add 20% to 30% of top line revenue to your organizations top line. This represents your organizations best opportunity to add revenue and profit for both the short and long term. But analytics provides critical value beyond just cross-selling. You are likely under pressure from customers who want more powerful insight into the inner workings of your application. As business intelligence becomes more pervasive in the business environment, all types of employees are aware of the powerful capabilities that are generally available. They expect you to provide historical insight, drill down dashboards, and ad hoc reporting. Additionally, your most sophisticated and most valuable customers are the ones most likely to make the loudest demands. While adding an analytics offering is attractive for both positive and negative reasons, it also represents a new territory for those who have focused on their core product line. This white paper offers practical advice on how to plan for, build, and ultimately market an analytics product. If you execute your product development and rollout well, you can grow your business, build customer satisfaction, and improve the stickiness of your product. But like any great opportunity, success requires careful planning and attention to detail.

The Business Rationale and Business Case

Your analytics initiative will reflect the strategic approach that you take. On the low end of the spectrum, you can fill a tactical hole in your product line with some type of reporting capability. This responds to your customer most pressing demand and is the least resource intensive approach you can take. Typically, this type of offering is sold at a low cost or included with your core product license. Low investment equals low reward. Aggressive plans to add significant revenue to your product line will require more intensive planning and investment. Market data shows that customers are quite willing to pay for more advanced functionality that enables them to effectively use information to make more money. You must be prepared to sell the business value of the insight that you deliver in your product.

2010 Birst

Embedding BI into Your Software Solution Best Practices

Defining a Revenue Stream

The broader and more sophisticated your products, the more that you will achieve with analytics.
The most obvious incremental benefit to your organization is increased license revenue. Software companies report that they are able to charge their customers anywhere from 20% to 30% of the cost of their base product for an analytics up-sell. With a well thought through product design, this ratio is imminently achievable. Analytics also have near universal potential to penetrate your customer base. Over 80% of your customer base will have significant interest in adding new analytics capability. With an aggressive sales and marketing plan, you might reach these prospects with 18 to 24 months of your launch.

Indirect Benefits
But direct revenue is only one stream of value that you get with your new analytics product. Some of the indirect benefits that should be a part of your product include: Improved ability to sell your core product. A well-designed analytics product can dramatically increase the appearance of your product line in a demonstration. Successful companies come to sell the power of an analytics offering. Increased customer satisfaction. Users at all levels love to have information available to them. Analytics can increase user engagement and loyalty more than anything else that you do. Improved executive sponsorship. In all likelihood, executives do not use your product. However, they are interested in results. A well delivered dashboard can engage your sponsors attention like nothing else. While hard to quantify, this indirect benefits may be every bit as large as the direct revenue upside. In general, the broader and more sophisticated your product line, the more that you stand to gain by adding an analytics product

The Investment Side

Of course, the cost side must also be considered. Your pro forma should include the following: Up front license and technology acquisition Cost of data and product integration Royalties for technology Maintenance Infrastructure (if you are delivering a complete solution, especially SaaS based) Customer service and support

2010 Birst

Embedding BI into Your Software Solution Best Practices

Choosing a software vendor with demonstrated templating capabilities should be one of the first boxes to check in your vendor evaluation.

Fortunately, the available options are more affordable than ever before. Open Source offerings emphasize zero technology costs. While attractive, you will need to plan for more secondary costs because of reduced support and infrastructure resources that are included in their free offering. They may also include less functionality than their counterparts whose commercial orientation requires favorable value compared to the competition. You should also understand your customers commercial requirements--some do not allow embedded Open Source technology.

Designing and Building the Product

While you are finalizing the business side of the equation, you will need to consider the broad list of product issues that will determine the nature and breadth of your product offering.

Think Product, Not Reporting System

When large corporations develop an analytic system, they focus on specific audiences and the varied requirements of each. These requests can reach hundreds of pages and document hundreds of reports and views that are required to supply the organizations needs for information. You should avoid this big bang approach to developing a product. It will likely fail. Rather, you should start with a core set of metrics (business formulas) that will be most meaningful to your customer base. Define the dimensions (the business concepts that are used to interpret results such as time, territories, and product hierarchies) that will be required for building an analytics framework. Armed with these building blocks, you can create the information that each of your customers will require. One question that often comes up is what is the number of standard reports that you should have available. Unfortunately, this can become a war between competitors who try to create a stack of standard reports that is at least one bigger than each other. In reality, standard reports are typically more important to your sales team than to your customers. Having a list of standard reports that demonstrates the value of your analytics offering is important to facilitate customer acquisition. In reality, standard reports are rarely used out of the box by anyone other than your pre-sales consulting team; information requirements are just too fickle and unique to be delivered in a canned fashion. You and your customers will be much better served by a half dozen templates that can serve as a starting point for your customers to work from. Choosing a

2010 Birst

Embedding BI into Your Software Solution Best Practices

Because of the visual and experiential nature of analytics, the use of prototypes and iterations is the best way to reach a final design.

software vendor that has demonstrated templating capabilities should be one of your first boxes to check in your vendor evaluation.

Its All About Product Continuity

Nothing is more important that complete UI and data continuity between your analytics and core products. Small inconsistencies will torpedo your new product offering. Customers have a sixth sense about inconsistencies between different modules. Field names should be consistent. Concepts should be align. Branding should carry through from one screen to the next. Fortunately, well-architected web-based applications are up to the task. By using service-oriented architecture (SOA), data and functionality can be passed between modules in a totally transparent fashion. Making a buy versus build decision does not require you to forego seamless functionality. One of the big decisions that you will have to make will concern the degree of UI integration with your current product. Getting this done right is one of the biggest success factors for a great product. Software users want to move quickly from their day job of taking action to understanding what is happening. When you make that transition seamless, you have already made a major step towards launching a great new product.

As a software developer, you are fully aware of the value of iterative product development. Even if you have the best product managers in your industry, they can never fully predict what your customers will want from software once it is complete. Because of the visual and experiential nature of analytics, the use of prototypes and iterations is the best way to reach a final design. So let your customers experience the product for themselves. Once they have something in front of them, customers can usually provide quick and meaningful feedback. Iteration also allows you to uncover small, yet potentially significant, nuances that must be designed into the analytics application. Special formulas or unique metrics are a part of every business environment and can disrupt your plans if not identified during the design phase of the project. Having a prototype that your customers can view will usually expose these types of complexities that can be turned into selling features if done correctly.

Cast a Wide Net

Your plans to build an analytic product will center around your own operational data and application functions. Analytics start with visibility into all of your modules and the data that is created in the process of executing your software.

2010 Birst

Embedding BI into Your Software Solution Best Practices

For an analytical product, keeping data over time is central to the value of process.

In some cases, this may require integration with two or more data repositories. If you have built your product line from the combination of several products, pulling this together will require considerable care and analysis. Selecting a technology that allows for complex data integration will be key. You should not overlook the opportunity to bring in external or third party data that may dramatically improve the value of your analytics product. Take for example, a publisher of customer self-service software that was driven by customer demand to add analytics to their product offering. Reports and dashboards allowed managers to track trends in products, customers, and source of customer interaction. The value of this information was immense. It allowed for quick changes when customers had issues with certain products or features. But the publisher took this one step further. They added information about other systems that deepened the insight available to the users. Rather than a tactical reporting tool, they enabled their users to use deep insight into the whole customer experience process. Another publisher built an analytics product to manage and analyze data from customer surveys. The data was used to support the on-site managers of stores and restaurants. In todays environment, making sure that every customer leaves your location satisfied is critical to business success. But the publisher took this process one step further and added other financial and operational data into their offering. Now their customers could make conclusions about the relationship between customer experience and financial success. The value of this information is enormous.

But Not Too Much Data

While the integration of multiple data sources into your analytics product is very valuable, you should avoid the temptation to compete with in-house data warehouses and analytics capabilities. You should provide one core view of your operational data and supplement it with one or two other sources of data. This approach will provide maximum value to your buyer while avoiding the appearance of making your product overly complex.

Think About Data Over Time

Most software products keep information for as long as it is needed to complete a transaction or functional unit of work. Information comes into existence when a user takes some action and often time disappears once the required work has been completed. In many cases, because of the volumes of data that are involved, deleted data as it is used is a part of a standard function. When a customer asks for something, once that something is satisfied, there is little value in keeping a long historical script.

2010 Birst

Embedding BI into Your Software Solution Best Practices

Careful planning can help you minimize the demand for custom reports.

But for an analytical product, keeping data over time is central to the value of process. Users want to understand trends and how one period of time compares to another period of time. You should be very careful to understand how your customers chunk up time into meaningful reporting buckets. Many industries have fiscal calendars that drive reporting and analysis. Having an analytic product that aligns with your customer views will greatly increase the value of what you are bringing to market. It is also a great opportunity to differentiate yourself from your competition. One of the implications of keeping data for longer periods of time is that data volumes can become quite large. Fortunately the cost of storage and the power of technology continue to escalate. Generally, information is valuable for at least a full year and in some applications, three or four years. You should make a careful decision about this parameter and err on the side of being generous with your data retention. You can always cut back if you find that customers do not require deeper historical data. The good news is that industrial strength analytics technology can accommodate all of the data required to answer all types of business questions. Make sure you choose a technology that aligns with these requirements.

Decide on the Role of Your Customer

One big issue that always arises with the deployment of an analytics product is that of customer enablementshould customers be allowed to design their own reports or should funnel all report requests through you. Like most tough questions, the answer is it depends. First, you should do everything that you can to reduce the amount of customer work required to get the information that they need. Variables such as geography and time should be setup as visual filters which users can easily modify to get at the information that they require. Doing a complete job of filter configuration will go a long ways towards reducing your customers needs for custom reports. Of course, the diversity of data requirements demands some level of customization. Having a product that allows for easy configuration of reports is critical to meet a wide variety of needs. Customers should be properly trained and perhaps certified to do their own reports. Additional license fees may also be assessed. Careful planning can help you minimize the demand for custom reports. When more flexibility is required, you can still deliver to the needs of your customers. Most often they will be lazy (in a business sense) and want you to do the work for them. Some publishers have had good success in selling subscription service (e.g., $5K/month for a certain amount of report work). These types of arrangements can be profitable and valuable to your customers.

2010 Birst

Embedding BI into Your Software Solution Best Practices

Each user type or role will likely have dramatically different requirements for your new product.

Designing Reports and Dashboards

Of course, the heart of any analytics product development is the creation of the reports and dashboards. Ultimately, this is what your customers will see and will use to judge the quality of your product. Over delivering here will ensure the success of your product and enhance your entire brand.

Consider Roles of Your Users

Many different users have need for an analytical product. Each user type or role will likely have dramatically different requirements for your new product. While each situation is unique, we generally see a handful of user types: Senior managers. Typically they want standard reports that are color coded to highlight out of the ordinary results. Many times, these individuals will prefer to have reports e-mailed to them so they dont have to learn how to login to the new product. (Even if they would have more fun if they did!) Dashboard Users. They have similar requirements to senior managers, but are more engaged with your product. They have very specific needs, but tend to prefer dashboards that enable them to do a limited amount of data exploration or drill downs. While senior managers see a result and move on, this group asks questions and tries to find out some insight into the phenomenon that they observe. Analysts. These are the few individuals who will get maximum value from your new product. They tend to require ad hoc needs and are the ones who are asked to answer specific and special business questions as they arise. Administrators. These team members setup and manage the reporting environment. They also setup and evolve new reports. Most often one administrator is required for each major location where the product is to be delivered from.

Focus on Metrics
You should pay particular attention to the metrics (business formulas) that you deliver to your customers. Oftentimes, powerful metrics can be complex to calculate, but easy to understand by the business user. For example, percent growth year over year, is a common metric used by a variety of business segments. This requires the calculation of output at two different reporting periods and then an additional calculation of percent change is applied. This metric is easy to understand, but fairly difficult to achieve without the proper data and application sophistication. You should be very diligent during your product design and technology selection phase to define the types of metrics that you will need to be successful.

2010 Birst

Embedding BI into Your Software Solution Best Practices

Finally, support services must be purchased which quickly closes the gap between open source and commercial software products.

Selecting a Technology Partner

You will have several choices available to you to create you analytics product. A wide range of technologies and delivery models. Here are some of the key options and issues to consider.

Build it yourself
As the available options for commercial products have increased, the popularity of this approach continues to decline. Today, users expect more capabilities than what you can reasonably build yourself. It certainly is possible to build a tactical reporting capability, but providing exciting data visualization, ad hoc, and drill-down functions far exceeds most companys appetitive for new technology. This is a good place to start, but ultimately will encourage your customers to want more.

Open Source
Open source java toolkits represent a single step above the build it yourself approach. These tools have one big and tempting advantage to considerthey are free to license. However, free is a starting point, not an ending point. Products such as Jaspersoft deliver a foundation of broad reporting functions. Developers can build on these types of platform to create competitive products. However, the orientation of these products is much more of a development platform and only address the reporting application. You still have to make investments in data integration, meta data management, and data model development that are required to make these open source products work in your environment. Finally, support services must be purchased which quickly closes the gap between open source and commercial software products. Several of our customers made significant investments in this direction prior to moving on to work with us. While the initial investment was tempting, the long term cost of working with Open Source technology proved to be unsustainable.

On-Premise Products
Commercial on-premise licensed products have dominated the BI product category for the past decade. While maturity is the strength of these products, it also represents their greatest weakness. Many of them have been built on platforms that predate the current technologies of today. Furthermore, many of these products have been accumulated through acquisitions and business moves that have created a complex maize of incompatible and disconnected capabilities. These products require you to manage your own ETL, metadata and data models. They may also have different presentation layers for the web and for the

2010 Birst

Embedding BI into Your Software Solution Best Practices

Top tier analytics providers will have the experience to be your planning partner in the early part of your relationship.

desktop. Sorting through all of this can be challenging to say the least. You should make sure that you understand what product configuration that you are looking at and what you are buying.

SaaS Product
SaaS BI offerings now represent a viable option for software vendors looking for a turn-key option to fill their analytics gap. Of course this is most attractive to SaaS software vendors who are closely aligned with the whole notion of cloudbased computing. But even on-premise software vendors should consider this approach before they make a final decision. The primary advantage of this approach is that it is totally turn-key and eliminates the need to invest in new technology and expertise required to get to market. Because of the relative immaturity of this paradigm, software developers should make sure that their potential SaaS BI provider can provide the flexibility and scalability that is required to be successful. In addition to the capabilities that have already been discussed in this white paper, the ability to access multiple sources of data in different locations is key.

Aligning to Your Business Model

When selecting a technology partner, you will have to negotiate a business deal that aligns with the business realities of your business. Traditionally analytics products have required significant up front investment with a long trailing curve of high margin revenue. This up-front investment required at least four major expendituresreporting software license, support, enablement costs, and application construction. Traditional on-premise approaches such as this often cost upwards of a half million dollars before the first dollar of customer revenue found its way to your ledger sheet. It is unlikely that your current business model aligns with this type of investment. Many emerging analytics companies offer an extreme alternative to this approachfree software. While this approach does minimize (at least initially) the software license component of the above equation, they may create many other issues that will increase risk and limit the long-term revenue opportunity of the product. Most of the free download offers are desktop licenses that have limited scalability and analytics power. While you want to align revenue with your investment, you should never compromise your long-term upside as it justifies prudent work to achieve your business goals. You should expect your chosen vendor to work with you to put together a financial offer that makes sense for your business. Top tier analytics providers will have the experience to be your planning partner in the early part of your relationship.


2010 Birst

Embedding BI into Your Software Solution Best Practices

Managing Risk
Plan on 2 or 3 rounds of refinement and you will create something with a high probability of commercial success.
Given the wide variety of available technology and concomitant costs, the only real reason not to proceed with an analytics opportunity concerns the risks involved. The formula for reduced risk falls out of the issues that have been addressed in this paper. When choosing technology, your evaluation should weight these issues equally with the marquee issues such as ease of use and power for metrics. When you have evaluated options on both sides, your choice of vendor partners will be quite clear. Reducing risk involves: Iterate with your customers. Plan on 2 or 3 rounds of refinement and you will create something with high probability of commercial success. Make sure of metrics. Most analytics product development efforts hinge on the ability to create the metrics that your customers demand. Do careful due diligence on the ability of your chosen technology to make calculations that make complex data into easy to understand dashboards. Align your business with your vendor deal. Nothing more needs to be said. The good news is that risk is imminently manageable. At no time has it been easier to build analytics products while minimizing the risk that your business must take on to go to market.

Going to Market
Once you have made the decision to build and deploy an analytics product, you will want to think about how you will go to market. Because of the marquee value of the new product in your portfolio, the planning for this launch should begin as soon as you have begun the development effort. So here are some tips to get the word out and quickly begin your journey towards a rapid payback on your investment: Make a separate launch of the new offering. We generally find that it works best to highlight your new offering in a stand alone announcement as opposed to wrapping it in with other release offerings. Emphasize the ROI dimension. Your new product can be talked about in a variety of ways. Focusing on how new insight will increase the economic value of your total product line is a key to winning hearts and souls of your audience. Start with your new prospects. Software publishers are quickly faced with the choice between selling into the base or selling to new prospects. We find that you can get the most value by using the excitement value of your new marquee product. Once you have rolled out to your prospecting environment, you can circle back and up-sell to your customers.


2010 Birst

Embedding BI into Your Software Solution Best Practices

Birst, Inc. 153 Kearny St., 3rd floor San Francisco, CA 94108 Email: Toll Free Phone: (866) 940-1496

Adding an OEM-based analytics product provides you with a path to increase your top line with minimal risk and impact on your own precious development cycles. Not only will it add to your top line, it can provide a way for your customers to get more from their current investment in your company. Benefits such as improved customer satisfaction and loyalty are great secondary benefits that will add to the health of our customer relationships.

About the Author

Mr. Emerson is Managing Director of Integrated Growth Solutions, a strategic consultancy that specializes in helping companies use technology and analytics to grow their business. He has extensive experience in bringing analytics products to market. He was the Chief Product Officer at Protagona, a high growth company that was recognized by the London Stock Exchange as the number one growth company of 2000. He held senior executive positions at Doubleclick, Siebel and Aprimo. In every case he has led efforts to launch successful analytics products. Mr. Emerson can be reached at


2010 Birst