Wednesday, 17 May 2017 12:20

Product Manager’s Guide to Embedded BI: Empowerment with Self-Service Analytics

Written by

A product’s roadmap is no secret to its product manager. The job entails planning future development in response to requests for enhancements, new requirements, and competitors’ offerings.

One priority making it to the top of the list for product development is intuitive self-service business intelligence (BI), data analytics, and visual data discovery. End users across a wide range of industries expect these capabilities in the applications they use regularly. Self-service BI helps organizations spot outliers and trends, improve business processes, save money, and grow revenue.

Software Vendors Respond to Growing Demand for Self-Service BI

Software companies realize the benefits of improving analytics in their solutions. Delivering value extends beyond simply offering self-service functionality. It requires the ability to embed analytics in the workflow where users need them to make decisions and to give users the ability to create new reports and dashboards for true data exploration.

However, coding this functionality in-house poses complications:

  • Lengthy time to market – an analytics project beyond superficial functionality may take years to launch, especially if analytics is not a core competency of the developers tasked with the project
  • Opportunity costs – resulting from having developers focus on analytics and deferring essential development of enhancements, upgrades, or other changes; licensing of toolkits beyond the use of open source libraries and toolkits adds to the expense line
  • Ongoing maintenance and enhancements
  • Scalability – resale requires developing a BI application that is customizable, scalable, and compatible with other infrastructures

Purchasing and embedding an analytics offering from a third-party software company with a core competency in analytics is a more cost effective approach. Many options for embedded analytics products exist in the market today. Understanding the differences between these products starts with scoping:

  • Functional needs – like self-service, a short learning curve, easy-to-use query functionality, real-time reports and responsiveness across devices
  • Business needs – project costs and return on investment (ROI), factors associated with selling the solution profitably (licensing, third-party support costs, updates to existing infrastructure requirements, add-on product cost, personnel resource requirements), and long-range organizational issues (growth plans, ability to scale a growing customer base, pricing model for monetizing analytics)
  • Technical needs – organization’s technology stack, database and other data source technologies, availability of the different technical resources and skillsets needed to support the project (deploying the BI tool in the cloud, on-premise or as a hybrid, or requirements for a data warehouse or changes to an existing database)

Where to Start – Research and Product Demonstrations

Early research takes place using software review sites that offer verified reviews from the user base and studying research reports published by industry analyst firms that specialize in BI. Vendor websites are another source for information. They may include case studies to learn how they handle BI implementations.

An organization will often target three to six vendors for product demos. To narrow down the list of prospective product trials to two or three, an organization can use a comparison matrix to prioritize and track requirements against the different solutions. Demonstrations need not be exhaustive, but there are key takeaways from each:

  • Does the solution work with the organization’s technology stack?
  • Does the solution does it have the ability to utilize specific functionality required by the software company, like a particular type of visualization?
  • Does pricing align with the organization’s budget?
  • How will the end user experience look?
  • What will the deployment process entail?

Additional questions might include:

  • Is there support for arithmetic operations like addition, subtraction, and aggregation?
  • What database support exists?
  • Is complete white labeling of the solution available?
  • Is it fully web-based, or do desktop dependencies exist?
  • Is there a user interface (UI) for administering tenants and mapping data fields, or is coding required?
  • How long before the solution is live?
  • What percentage of customers embed the solution?
  • What options for monetizing analytics exist?
  • What have companies charged for it?

Obtaining Value from Trials and References

The next step is conducting the software trial to vet the software against an organization’s key test cases.

The goal of the trial should be to create a core set of analytics deliverables -- reports, dashboards, visualizations, and key performance indicators (KPIs) most important to an organization’s customers. The trial allows companies to:

  • Vet the embedding process and integration
  • Test how solutions handle user and database security
  • Determine support for multi-tenancy
  • Confirm compliance with regulatory standards like HIPAA, SOC2, or PCI

References from other customers using the same software version trialed, and in the same vertical and of approximately the same size are gold. Listening carefully to answers to specific questions can expose red flags. Use conversations with references to obtain clarity into issues that the demo only lightly touched upon, and determine how easy it is to work with the company. Suggested questions to ask include:

  • How long have you been using this product?
  • What were the major reasons for choosing this solution? What were your expectations? Has this product met your expectations?
  • How long did it take to embed analytics? Did you encounter any problems during the process?
  • Was your implementation on time and within budget?
  • How many end users are using the analytics solution? 
  • Has the solution allowed you to monetize analytics in your application? What model are you using to monetize analytics?
  • Did the product require any workarounds?
  • How much internal IT support was needed for the project? How much support did the vendor provide?
  • Overall, how satisfied are you with the solution? Would you choose the vendor again?
  • Was there anything you wish you had known before implementing this solution?

Beta Testing and Phased Roll Outs to Identify Deployment Issues

In addition to trialing functionality and soliciting feedback from others, organizations should assess how well the solution will deploy on existing infrastructure. Organizations may require a scaling strategy, such as scaling up by upgrading hardware and memory or scaling out by replicating servers, adding load balancers or containerizing with a solution like Docker.

It is not easy to predict performance without knowing what to expect of self-service BI regarding usage. Many software companies opt for a soft launch of a beta release to one or two customers. Discounted pricing to beta customers is offset by the value obtained from their involvement in beta testing, which can address issues early on before they become system-wide problems.

Rolling out functionality in stages can help ensure stability. For example, by gradually introducing features, companies can identify potential stresses to application infrastructure from increased demand. Other companies may opt to deploy analytics as a standalone BI portal. A less robust, in-context analytics experience, this is the fastest approach to implementing analytics when speed to market is most important.

Avoiding Licensing Pitfalls

A product’s licensing model is an important factor in ensuring monetization of analytics. Organizations create value with improved analytics in one of four ways:

  • Selling enhanced functionality as an add-on
  • Winning new business
  • Retaining current customers
  • Reducing service costs

The embedded BI product selected should not lock a company into an unworkable price model. Scaling can dramatically influence overall costs. User- or session-based pricing models can reduce ROI as businesses grow and the number of end users expands.

Organizations should look for a licensing structure that complements the value derived from analytics, is easy to understand, and maintains transparency regarding costs associated as the application scales. When determining pricing, also consider proprietary software, infrastructure enhancements, and ongoing maintenance.

Contract Negotiations

A company’s flexibility and responsiveness during negotiations are excellent indicators of how a company will operate as an OEM partner. Lengthy, drawn out legal processes that outweigh moving quickly to address needs often foreshadow future implementation and services processes.

A list of recommended service partners and suggested service hours can indicate a solution’s maturity and how well it is designed for embedding. Look for a model based on shared value creation. A line item for a discount of any size should call into question the vendor’s commitment to a partnership. Showing a big number is often an attempt to sell value, and then an arbitrarily assigned discount indicates what they believe they can extract as a total cost.

Conclusion

The movement of self-service analytics from a nice-to-have to an application requirement need not be a burden for application development teams. With proper planning, product managers can ensure deployment of a rich analytics interface that helps end users gain more value from data, takes the report creation workload off developers, and allows opportunities for further monetization of the application.

Read 7681 times
Marcus Hodges

Marcus Hodges, project manager at Izenda, a provider of embedded BI and analytics software, uses his experience as a Business Analyst to support his work as a project manager at Izenda. He has managed more than 35 integrations of embedded BI and analytics, managing the integration timeline and onboarding process for each client.

© BA Times.com 2019

macgregor logo white web