Beyond the Checkbox - Part IV

Chris Tyler from Cognos will be joining us for a series of Blogs focused on driving performance for ISVs and OEMs. We will be publishing his Blogs on Thursdays for the next four weeks. Chris is a subject matter expert on getting his clients to elevate value to their customers.

This is the final part of this series. In Part III, we discussed the typical way vendors address their customers reporting needs, by simply checking the reporting box and delivering little or no value to their customers. Here will discuss a better way.

A Better Way - How to change the game

The customer should word their requirement “Do you have an analytical application which proves your application improves the performance of my organization as it relates to increasing our win rates by 7% year over year, reducing sales cycle times by 13%, and increasing our deal sizes by 5% year over year?” I’m sure the vendor would have a much tougher time checking that box, but, that is what the customer truly needs to know.

Figure 2 – An example of an analytic report which shows the business impact and provides context as to what it means to the business, what else to look for and what to do next.

Most enterprise purchases are fairly significant investments and the vendors are often very willing to present case studies where the return on investment, ROI, is achieved in, say, 14 months. Few vendors can actually prove it with their reporting solutions. If the vendor has gone through the process to measure the ROI and understand how it achieves the ROI, why not take that same thought process and put it into an Analytical Application that can be delivered? These types of analytical applications tend to increase customer satisfaction and stickiness, and become a significant, additional revenue stream.

What should the vendor be doing to deliver the value proof? How can the vendor go Beyond the Checkbox? Here are several ways. All of these should leverage and highlight the intellectual property and knowledge of the customer the vendor has.

Identify the value points

Identify 3-7 reasons why customers should buy your application. These become the value points which translate into metrics. These should be SMART (Specific, Measurable, Actionable, Realistic and Time-based).

Domain	Value Statements	SMART Metrics
CRM	Reduce sales cycle times Increase deal sizes Increase win rates Reduce cost of sales	Days to closure Average deal size growth Win/loss rates Cost of sales
Security	Reduce risk exposure Decrease intrusions Improve Data Governance and Compliance	# of threats identified/thwarted as it relates to system criticality and sensitivity % of critical systems adhering to corporate standards
Human Capital Management	Decrease attrition rates of high value employees Improve employee satisfaction Properly manage talent pool Increase successful recruiting rates	Attrition rates for top performers Employee satisfaction % of employees within 1-2 years of retirement Tenure / attrition rates of employees by recruiting source

Define the metrics

Build a business glossary to define the metric. This should contain what we refer to as the “What?, Why?, So What?, Now What?” This should be able to explain the intent of the metric. All metrics should relate somehow back to the value points identified earlier. If they don’t, there is typically no reason to track it.

Setting targets

The vendor should allow the customer to set targets for the various metrics and if applicable, any tolerances which may be acceptable. Comparing the actual values from the transactional data to the targets set by the customer, allows the user to see if they are on the right track to achieve their results.

Simplify taking action

There may be a need to share the content with another user, a user may want to comment on the performance, there may need to be some action plan set in motion to improve the performance, a user may want to subscribe to the content, or there may be a need to drill into the detail behind the metric.

Content should be in context

Content in context can imply that it is related to the logged in user or is specific to the current view within the vendor’s application. There are a variety of ways to accomplish this ranging from a tight API-level integration to a loosely-coupled web-based integration using URL’s, all depending on the capabilities of the vendor application.

About the author

Chris Tyler has been working for the past 4+ years with Independent Software Vendors (ISV’s) and Business Process Outsourcers (BPO’s) to help them address the specific needs of embedding BI into their platforms. He has seen some great successes and some dismal failures. Some commonalities with the successes are that the vendor delivering the application actually put some thought and intellectual property into their content. The failures typically did not.

Beyond the Checkbox - Part III

Chris Tyler from Cognos will be joining us for a series of Blogs focused on driving performance for ISVs and OEMs.  We will be publishing his Blogs on Thursdays for the next four weeks.  Chris is a subject matter expert on getting his clients to elevate value to their customers. 

This is Part III of this series.  In Part II we discussed the ways a vendor may choose to address the needs of their customer as it relates to reporting.  We will show here, the typical way vendors address that with a reporting solution.

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

About the author

Chris Tyler has been working for the past 4+ years with Independent Software Vendors (ISV’s) and Business Process Outsourcers (BPO’s) to help them address the specific needs of embedding BI into their platforms.  He has seen some great successes and some dismal failures.  Some commonalities with the successes are that the vendor delivering the application actually put some thought and intellectual property into their content.  The failures typically did not.

Beyond the Checkbox - Part II

Chris Tyler from Cognos will be joining us for a series of Blogs focused on driving performance for ISVs and OEMs.  We will be publishing his Blogs on Thursdays for the next four weeks.  Chris is a subject matter expert on getting his clients to elevate value to their customers.  

In part I of this series, we discussed the relationship between vendor and customer and how there comes a point where the customer determines the need to have reports from the system.  In this part, we will look at the typical ways a vendor approaches the solution for those reporting needs.

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 
1. Building a home-grown reporting solution
2. 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.  Additionally, BI and Performance Management is 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 can choose to embed a 3rd party reporting tool. These 3rd party applications generally provide additional capabilities to the vendor and allows development resources to focus on innovation within the core application.  However, vendors will limit the use of these 3rd party products to delivering basic reporting through interactive reports, fancy charts or even some ad hoc capabilities. 

About the author

Chris Tyler has been working for the past 4+ years with Independent Software Vendors (ISV’s) and Business Process Outsourcers (BPO’s) to help them address the specific needs of embedding BI into their platforms.  He has seen some great successes and some dismal failures.  Some commonalities with the successes are that the vendor delivering the application actually put some thought and intellectual property into their content.  The failures typically did not.

Because you can...doesn't mean you should

We do a number of things in the name of business intelligence.  We say we have to have real time information.  We have to have hundreds of reports.  We have to be able to look at everything in every direction.

Business Intelligence software promises us this and make this seem like an achievable goal.  And yes it would be great to know everything about everything and get a perfect 360 degree view of the organization.

Yet it is not really achievable, actually not even close.  Instead ask what are the goals & objectives of the organization, and how does this support that end.  We are very quick to say "we can do that" but we need to temper that with "why should we do that?"  Think of the goal of a dashboard - to provide real-time information on a specific subject.  I have known many managers that constantly stare at the screen to see if anything moved.  

What we really need is to understand how to use the function of time and integrate that into a analytical management process.  What would you get more out of, a tactical dial that shows us one KPI, or a meeting at the end of the day to review a number of KPIs?

Beyond the Checkbox - Part I

Chris Tyler from Cognos will be joining us for a series of Blogs focused on driving performance for ISVs and OEMs.  We will be publishing his Blogs on Thursdays for the next four weeks.  Chris is a subject matter expert on getting his clients to elevate value to their customers.  

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.

Domain	Value Statements
CRM	Reduce sales cycle times Increase deal sizes Increase win rates Reduce cost of sales
Security	Reduce risk exposure Decrease intrusions Improve Data Governance and Compliance
Human Capital Management	Decrease attrition rates of high value employees Improve employee satisfaction Properly manage talent pool Increase successful recruiting rates

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!

About the author

Chris Tyler has been working for the past 4+ years with Independent Software Vendors (ISV’s) and Business Process Outsourcers (BPO’s) to help them address the specific needs of embedding BI into their platforms.  He has seen some great successes and some dismal failures.  Some commonalities with the successes are that the vendor delivering the application actually put some thought and intellectual property into their content.  The failures typically did not.

Analytics & Actionable Information

I have worked on many projects where the outcome was "just provide us actionable information."  While this is always the goal, I find most people use this term quite loosely, as if it were merely an additional option.  In reality this is quite difficult to create.  Many things need to come together to create action, and it is far more than just information or a report.

To create effective actionable information, we need to integrate people, information, and tools.  We also need to have the right skills at different times.  All too often, the expectation is for IT to write a single report that will answer all questions.  Yet, what typically happens is that report often just creates more questions as IT cannot predict all of the needs.  All this has done is create more activity for IT and delayed action.

Let's look at this from more of a process point of view...how would it look:

First of all, we have a tremendous amount of data.  And it would be easy to argue way too much data, hence the need to create some layer of relevance.  How often do we get lost looking for what we need, or recreate something because we don't understand the business rules of the data we find.  All of this is wasted effort that ends up costing the business money and time.

We have the information we need, now we need a good analytical mind to review the data creating various analytical models or what-if scenarios.  What typically happens here is a finance, or IT analyst runs a few numbers.  This is probably OK for many instances, but the best options would be to both a mind of the business as well as a statistical curiosity (though at this stage we need more of a statistician).  IT and Finance often lack both of these to some degree - as their primarily skill is data or fiscal governance.

Now we have some level of analytical information, but still have some work to do.  In general the statistical mind tries to cram in too much detail and wants to discuss the process of discovery, instead of the finding.  To transform analytical information into action, we need the business to present the finding in executive terms - the value created.  The presentation is more than likely to include multiple reports, synthesized into a couple of charts.  The next step is to foster a discussion of the recommendations and potential options.  The discussion will focus on gathering feedback and coalescing them into an agreed upon plan.  It is common here for people to not feel comfortable with the information and ask for additional information and analysis, but we need to fight the urge to delay and put the best foot forward.  There will be times when the need for rework is great, but if the discussion included the right people and the facts then there should be enough to make a decision and move forward.

The risk is creating a culture of endless analysis.