How to Evaluate Embedded BI in 5 Easy Steps
If wading through a sea of embedded BI solutions in search of the perfect fit for your product sounds daunting, it should. Wading really isn’t what you want to be doing, but it’s what SaaS providers end up doing when they launch a product search without a plan. They may happen upon a suitable solution by happenstance, but odds are they’ll instead waste valuable runway time and money testing implementations that could never work for them or their end users.
If you and your team don’t yet have a strategy for conducting your BI search, that’s okay. We’ve put together a roadmap you can use to build a plan unique to you. Foreign, multi-step processes are always easier when you have a general lay of the land, and that’s really all you need to get your search started. With attention to each of these five steps, you can be confident that the embedded BI solution you decide on is a good fit and will give your product the competitive advantage it needs to succeed in the market.
1. Develop Requirements
First off, if you don’t start out knowing exactly what you want out of an embedded BI solution, that’s okay. There’s certainly some learning-by-doing in all of this, and nomenclature plays a surprisingly central role in developing and articulating your requirements to vendors. Even general terms like “embedded BI” can mean different things to different providers, so it’s important to brush up on industry terminology as you map your requirements to the features on offer.
Take time with this step, as it will inform your entire evaluation process. While some requirements—platform compatibility, OS support, etc.—are non-negotiable no-brainers, others can be a little slipperier to pin down. You might know, for example, that your users need the ability to filter their reports, but without walking through some hypothetical use cases, you might not consider:
- The need for mandatory filtering on select reports that would otherwise return an unwieldy number of records.
- The need for dynamic date and time filters that keep reports current.
- The need for users to have control over a filter’s operator (or not).
- The need for control over whether a filter hits the database or simply limits the results already returned from the database.
This may be more granular than you wish to go as you itemize your requirements, but it illustrates the value of using hypothetical scenarios to get a clearer picture of the ideal solution. Since it’s unlikely that all requirements will be of equal importance, you might even consider developing a weighting system and using it to fine-tune your evaluation.
When you feel confident that you thoroughly understand both your business and technical requirements, it’s time to go shopping.
Once you know what you’re looking for, this step is mostly about finding the BI vendors that purport to have it. I say “purport” because, again, terminology can get tricky, and marketing materials don’t always tell the whole story.
Review sites like BetterBuys will not only give you a sense of who the top BI vendors are but also how real customers feel about their products. After narrowing down your options, you can click through to each vendor’s website for some more in-depth research.
Here are some other resources you might not have considered relevant to the research phase:
- YouTube. Sometimes BI companies post video tutorials online, giving you a better sense of the product’s user interface.
- Glassdoor. Just as an embedded BI solution becomes an extension of your product, an embedded BI vendor becomes an extension of your team. Employee reviews can tell you a lot about a company’s cohesion and communication skills.
- Support/Documentation. If the vendor in question allows the public to access its product documentation, take a peek and pay attention to clarity and thoroughness.
- BI Analysts. There are blogs and whitepapers galore on this stuff. See what the authorities have to say on the subject.
If you’re struggling to see the difference between one embedded BI provider and the next, you may need to refine your requirements a little. Alternatively, you’ve gathered all the high-level data you can, and it’s time to sit in on a demo.
Two words: come prepared. You want to be able to debrief with your team after a demo and know whether or not the product is worth taking for a test drive, so bring actual lists of questions to the call. It’s okay to steer the conversation toward the areas of most interest to you; the vendor wants to understand your needs in order to better accommodate them.
The more demos you attend, the harder it will be to keep them all straight in your head—especially since embedded BI applications tend to be nuanced. Shoot for the sweet spot of between 3 and 5 demos so as not to get overwhelmed or confused. Also, be sure to take meticulous notes during the demo and request a recording of it so that you can revisit the conversation as needed.
4. Test Implementation
Once you’ve found a solution you wish to test, the vendor will walk you through creating a minimal viable product and a proof-of-concept project. This usually constitutes a suite of reports you would either offer as canned reports to your end users or reports you could imagine them wanting to create ad hoc for themselves.
Our best advice is to really spend some time planning your POC project. Pick reports from the middle of the bell curve—neither too complex nor too simple. If recreating one of these reports or dashboards turns out to be much more involved than you’d expected, that’s a red flag. Try to loop in features you think your end users will be using, even if they’re not necessarily integral to the reports in your POC project.
Lastly, don’t spend too much time on the test implementation—do just enough to complete your evaluation. (If you find it’s taking too long to do even that, consider it a red flag.) Remember that you’re just exploring the product, not executing a full implementation.
This, the simplest step, is often the hardest to complete. There’s no right way to make your decision, but having laid the groundwork in steps one through four should at least make it easier. As a mentor of mine likes to say, “Make decisions, have reasons”—that is, as long as you have good reasons for choosing the solution you eventually select, you’ve done your due diligence.
Originally published with BetterBuys.