- what are the use cases for CDP? (This really means, when should you use a CDP and when should you use something else?)
- what are the capabilities of a CDP? (This really means, what are the unique features I’ll find only in a CDP? It might also mean, what features do all CDPs share and which are found in some but not others?)
- which CDPs have which capabilities? (This really means, which CDPs match my requirements?)
- can someone create a standardized CDP Request for Proposal? (This comes from vendors who are now receiving many poorly written CDP RFPs.)
1. defining a set of common CDP use cases
2. identifying the CDP capabilities required to support each use case
3. identifying the capabilities available in specific CDPs
4. having buyers specify which use cases they want to support
5. auto-generating an RFP that lists the requirements for the buyer’s use cases
6. creating a list of vendors whose capabilities match those requirements
What’s interesting is that steps 1-3 describe information that could be assembled once and used by all buyers, while steps 5 and 6 are purely mechanical. So only step 4 (picking use cases) requires direct buyer input. This means the whole process could be made quite easy.
(Actually, there’s one more bit of buyer input, which is to specify which capabilities they already have available in existing systems. Those capabilities can then be excluded from the RFP requirements. The capabilities list could also be extended to non-CDP capabilities, since most use cases will involve other systems that could have their own gaps. These nuances don’t change the basic process.)
As a sanity check, I’ve built a small Proof of Concept for this approach using an Excel spreadsheet. I'm happy to say it works quite nicely. I'll share a simplified version here to illustrate how it works. In particular, I'll show just a few capabilities, use cases, and (anonymous) vendors. .
We’ll start with the static data.
The columns are:
- Capability: a system capability.
- Description: a description of the capability. This can both help users understand what it is and be a requirement in the resulting RFP. Or, we could create separate RFP language for each capability. This could go into more detail about the required features.
- CDP Feature: indicates whether the capability would be found in at least some CDPs. The CDP RFP can ignore features that aren't part of the CDP, but it's still important to identify them because they could create a gap that makes the use case impossible. For example, consider the first row in the sample table, whether the Web system can accept external input. This isn't a CDP feature but it's needed to deliver the use case for Real time web interactions.
- Use Cases: shows which capabilities are needed for which use case. For items that relate to a specific channel, each channel would be a separate use case. In the sample table, Single Source Access is specifically related to the Point of Sale channel while Real Time Interactions are specifically related to Web
- Vendor Capabilities: these indicate whether a particular vendor provides a particular capability.
The second table looks at the items that depend on user input. The only direct user inputs are to choose which use cases apply (not shown here) and to indicate which capabilities already exist in current systems. All other items are derived from those inputs and the static data.
- Nbr Use Cases Needing: this shows how many use cases require this capability. It’s the sum of the capability values for the selected use cases.
- Already Have: this is the user’s input, showing which of the required capabilities are already available. In the sample table, the last row (site tag) is an existing capability. Since it exists, you can leave it out of the RFP.
- Nbr Gaps: the number of use cases that need the capability, excluding capabilities that are already available. These are gaps. Using the number of cases, rather than a simple 1 or 0, provides some sense of how important it is to fill each gap.
- Nbr CDP Gaps: the number of gap use cases that might be enabled by a CDP. The first row iIn the example, Web – accept input (ability of a Web site to accept external input) isn’t a CDP attribute, so this value is set to zero.
- Gaps Filled by Vendor: the number of CDP Gaps filled by each vendor, based on the vendor capabilities. A total at the bottom of each column shows the sum for all capabilities for each vendor. This gives a rough indicator of which vendors are the best fit for a particular user.
The main outputs of this process would be:
- List of gaps, prioritized by how many use cases each gap is blocking and divided into gaps that a CDP could address and gaps that need to be addressed by other systems.
- List of CDP requirements, which is easily be transformed into an RFP. A complete RFP would have additional questions such as vendor background and pricing. But these are pretty much the same for all companies so they can be part of a standard template. The only other input needed from the buyer is information about her own company and goals. And even some goal information is implicit in the use cases selected.
- List of CDP vendors to consider, including which vendors fill which gaps and which have the best over-all fit (i.e., fill the most gaps). This depends on having complete and accurate vendor information and will be a sensitive topic with vendors who hate to be excluded from consideration before they can talk to a potential buyer. So it's something we might not do right away. But it’s good to know it’s an option.
Beyond the Basics
We could further refine the methodology by assigning weights to different use cases, to capabilities within each use case, to existing capabilities, and to vendor capabilities. This would give a much more nuanced representation of real-world complexity. Most of this could be done within the existing framework by assigning fractions rather than ones and zeros to the tables shown above. I’m not sure how much added value users would get from the additional work, in particular given how uncertain many of the answers would be.
We could also write some rules to make general observations and recommendations based on the inputs, such as what to prioritize. We could even add a few more relevant questions to better assess the resources available to each user and further refine the recommendations. That would also be pretty easy and we could easily expand the outputs over time.
What’s Next?
But first things first. While I think I’ve solved the problem conceptually, the real work is just beginning. We need to refine the capability categories, create proper RFP language for each category, define an adequate body of use cases, map each use case to the required capabilities, create the RFP template, and research individual vendor capabilities. I’ll probably hold off on the last item because of the work involved and the potential impact of any errors.
Of course, we can refine all these items over time. The biggest initial challenge is transforming my Excel sheet into a functioning Web application. Any decent survey tool could gather the required input but I’m not aware of one that can do the subsequent processing and results presentation. A more suitable class of system would be the interactive content products used to generate quotes and self-assessments. There are lots of these and it will be a big project to sort through them. We’ll also be constrained by cost: anything over $100 a month will be a stretch. If anybody reading this has suggestions, please send me an email.
In the meantime, I’ll continue working with CDP Institute Sponsors and others to refine the categories, use cases, and other components. Again, anyone who wants to help out is welcome to participate.
This is a big project. But it directly addresses several of the key challenges facing CDP users today. I look forward to moving ahead.
No comments:
Post a Comment