Who should read this?

This document is intended for software vendors (ISV’s) and business process outsourcers (BPO’s) wanting to increase deal size, win more deals and improve customer stickiness by embedding packaged, advanced analytical capabilities as part of their application.

Why should you read this?

• The software and outsourcing industries are increasingly competitive businesses and vendors need to continue to innovate cheaper, faster and better than the competition
• Vendors need to provide thought leadership for their customers and demonstrate unmatched domain expertise
• ISV’s and BPO’s need to demonstrate rapid, quantifiable ROI
• According to a 2008 Gartner report, most enterprise reporting and data warehouse projects fail primarily due to the complexity of the data in business systems, vendors can guide their customers through the complexity

The vendor customer relationship

Every vendor designs, markets and sells its application or services to solve specific problems for its customers.  Here are a few examples.

Vendors are engaged by prospects to address their specific business pains.  Through the sales cycle, the prospect will generally evaluate multiple vendors for a match to their needs.  The vendor will demonstrate software capabilities and possibly prove out concepts that will provide the prospect with comfort that the vendor will meet their needs.  The prospect will select the vendor and the two parties will set off on a journey to start solving problems.

Through the installation and implementation process, the solution is tailored for the customer, the users are trained on how to get maximum benefits, and the customer is taught how to maintain the application.  Once the solution is implemented, what happens?  The customer is happy with the solution; their users punch all the buttons and they just enjoy seeing the applications do stuff?  Sure, but the customer needs some sort of proof that the application is solving their problems.  They need reports!

Now what

One of two things will happen to address the reporting need.

1. The customer is forced to build their own reports with 3^rd party tools
2. The vendor builds and delivers some reports as part of the application
   • Building a home-grown reporting solution
   • Embed a 3^rd party reporting / BI / Performance Management solution

In the first case, the vendor has no control over what the customer is doing.  Because the customer has little understanding of the underlying data structures and relationships, there is a high likelihood that the customer could pull the information incorrectly or misinterpret the data.  This can lead to making bad decisions or incorrect assumptions.  As mentioned earlier, according to Gartner, this is the primary reason that enterprise reporting and data warehousing projects fail.

In the second case vendors will often rush to deliver a reporting solution and simply dump out easily accessible data into lists and charts.  I have seen too many reports such as Call Logs, Current Sales Orders, and Customers by Demographics delivered as the basis of a reporting and analytic solution.

Building a home-grown, custom reporting solution can be very costly and will limit flexibility, scalability and capability.  BI and Performance Management is generally outside the core competencies of the development staff and becomes a resource drain on development resources limiting core application innovation.

To avoid the resource and cost problems, vendors will choose to embed a 3^rd party reporting tool.  This provides additional capabilities to the vendor and allows resources to focus on innovation within the core application.  However, vendors will limit the use of these 3^rd party products to delivering basic reporting through interactive reports, fancy charts or even ad hoc capabilities.

Checking the reporting box

When the vendor provides these basic reporting capabilities, I call this “checking the reporting box”.  The vendor is delivering enough reporting functionality to allow them to check a box stating that they provide reporting as part of their application, a common requirement of any company evaluating an enterprise application.

Figure 1 – A common example of a report that allows a vendor to check the reporting box, but which provides little or no value proof.

Having the requirement of reporting included with an application is necessary, but it’s how the requirement checkbox is worded.  The checkbox is often phrased “Do you have reporting with your application?” The vendor, providing even the most basic reporting capabilities, can then safely check the box, stating “Yes, we deliver reporting as part of our application”.  I don’t intend to imply that this is a negative.  Operationally, most of these reports are needed and verify that proper actions are being taken and the application is functioning properly.  The customer needs more!

There are four issues I find with reporting solutions from vendors who simply do enough to check the reporting box.

• Their reporting typically does nothing to verify the claims that a vendor makes regarding its solution
• The vendor delivers no intellectual property or thought leadership to serve as a differentiator which leads to more wins and larger deals
• There is little or no charge to the customer for the additional capability and therefore the vendor looks at it as a cost center not as a revenue opportunity
• It does nothing to expand the user community of the vendor’s application within the customer

Look for Part 2 of this entry covering how the ISV/BPO executes on The “Beyond the checkbox” strategy.