When talking to a software provider about embedding dashboards, reporting, and analysis capabilities there are two hurdles we need to get over: 1) Why OEM? and 2) Why Us? I thought I’d take a minute to talk about the first hurdle – Why OEM?
The “Why OEM” argument is a build vs. buy argument, and pretty much all BI vendors should have the same message (albeit some are better at delivering these benefits than others) – lower development costs, fast time to market, better capabilities, and so on. This is an important argument, as our win/loss reports show this is what we are competing with “build” about 60 percent of the time.
The lower development costs part of this argument is really the weakest – not because it isn’t true, but because most software companies are only at the beginning of their pain when they come to us. They realize they have two developers working on the expanding reporting/dashboard/BI requirements, but it isn’t yet a team of five people and, let’s face it, those two people are probably not going to lose their jobs but get re-purposed. The real pain is in the future and not yet realized, so it’s a hard argument to get through an ROI process.
I was in NYC recently meeting with a prospect and they brought up COGS (cost of goods sold) twice. I told them if you are making this decision based purely on cost, and your requirements are basic, then I didn’t need to be there.
The “fast time to market” can be really compelling, especially if the need for a BI product is a revenue driver. Often companies are looking at a BI module as a separate offering that they can sell into their existing customer base. Having a compelling product six months early can mean millions of dollars (yes, literally millions) to them.
The killer reason to OEM, in my opinion, is better capabilities. You should see the software companies that come to us two-three years AFTER they made the decision to build it themselves or utilize components. Ouch. My favorite is the one we refer to internally as having “frame-on-frame” technology (not a good thing). The reality is that market expectations change, and not only do you have to spend development resources building NEW features, but also re-visiting the ones you already have.
In my view, if the need exists to provide your customers with more than just basic reporting, pursuing the OEM approach is a no-brainer.