Toni Luhti
Sep 10, 2021
When we talk about individual use cases for data, we do not mean whole processes (such as a production line, customer support, etc.) that utilize data, not whole business functions where data plays a keyrole (such as invoicing or sales), nor large entities such as a data-driven business models or digital e-commerce businesses. When we talk about individual use cases, we mean a small concrete and as easily as possible delimited entity that is implemented with the help of data that generates value and can be measured. These could be, for example, the number of internal meetings in the company (which would hopefully lead to a change in management culture) or even the optimization of travel costs during the sales process (i.e. data understanding whether travel affects the time span of closed deal or success rate in sales). That is, practically any single object where data is utilized.
However, these use cases and uses of the data can be very difficult or easy, or those that directly or only indirectly affect the company's operations. In a previous blog, we already went through the direction in which data making should start, but we go through how to simply classify use cases and what to choose from there for the first implementations.
There are several use cases that consist of many use cases, i.e., they have dependencies. All these use cases are excluded from this classification, because it goes without saying that they should not be implemented first. If one use case is only possible after a few other smaller use cases have already been done, this may be the big goal to keep in mind all the time but break it down into smaller sub-use cases, each of which is already beneficial on its own. According to a sales example given earlier, such a goal could be the overall performance of B2B sales from data consisting of, for example, the following use cases, each of which is already valuable in itself:
- Number of customer contacts of an individual sales person
- Travel expenses of an individual sales person
- The number of customers served by a single person
- Customer satisfaction per sales person
- Number of sales won per sales person
- Number of lost deals per sales person
- Number of customer contacts (meetings) needed per won deal per seller
- Duration of the closed sales in days
- and so on...
But how are these individual use cases classified? The first classification factor is impact. If the use case does not really affect anything and the results are not significant, it is not advisable to start the use case first. The next factor is feasibility. If the use case is not genuinely feasible right now, it will easily become too difficult and money and time will be wasted before the benefits. In addition to this, you should evaluate the cost, know-how and ease. Too difficult, expensive, or challenging use cases shouldn’t be the first to implement because after that, organizations learn that doing data with something would be too difficult and expensive for their organization, so it’s hard to get enough priority for the data strategy later.
Once you have collected several different use cases for data and classified them according to the above criteria, you will easily get an idea of fully feasible, sufficiently effective and suitably easy use cases through which it is easy to start building a data culture step by step. For many companies, Death Valley data usage is precisely too difficult and globally interesting use cases that will take years to implement. However, the best examples are just the opposite and will be implemented in a few weeks. Think about this, IN WEEKS!