Illustration: Example of ticket management insights in Splunk when used to collect and analyze such data
My role in past organizations has always been that of a sort of jolly, transversal, with a 360-degree view around what happens in today’s digital agenda. I have preferred to keep a consultancy style while getting my own hands dirty in the developing steps of a typical IT project.
These last two years I have had the opportunity to take part in many processes of transformation in different SMB (Small and Medium Business) handling topics of digitalization, change management, analytics, and data-driven strategies. However, my perception is that of a gap between what these organizations can realistically implement and how they behave to achieve this.
There is an urgent need to establish change as a core competency.
Two sides of this urge:
- Excessive amount of data organizations produce
- Difficulty to provide insights and business value
Both these lead to delay and confusion in terms of technology choice and developing the talent needed.
Most of the organizations I have worked with underestimate the values and richness of the data they use, preserve or eliminate. That is why I talk about remodelling processes prior to thinking about data.
Here I bring an example! Anytime we hear about big data, open-data, public data, we hear about different correlated problems: lack of standards (example of open data: two regions in Italy, Lombardy and Piedmont, have totally different formats), security, privacy and data consistency (most of the data is already obsolete or of poor quality) losing utility and increasing the level of difficulty to obtain value.
A few years ago, in a small company (but essentially “sensitive” to technology and innovation issues), the way its service desk team was working was to let inside the office (collegues knocking on their door continuously) and complaining! It was their “all-time ticket management” system.
The introduction of a Cloud-based product (there are many names out there: ServiceNow, Salesforce, Zendesk, CA and so on) ultimately shaped out the way collegues faced with IT. Groups of agents were associated with specific departments in order to solve related tickets and share information between them. SLA-s were introduced to respect priorities, urgencies and QoS. Employees opened tickets using their accounts from different channels (intranet, web, social networks…). Within a few months they also started to resolve their own and each other complaints.
A knowledge management repository was being enriched in the Cloud service aggregating information in searchable folders. The response time was 40% less than what it used to be. By analyzing categories of tickets in a tree-based structure, they understood that most of the problems occurred as a domino effect (a problem caused other sub problems, in the same business area). Data analysis (count of keywords, time to be resolved, the steps undertaken and other KPI-s) made possible the detection of patterns (similar problems may require similar solutions!).
In addition, communication between different departments (Marketing, Sales, IT, CRM) was improved while information was immediately available through the Cloud service desk communities and forums. Flows of communication changed. Data of this kind is being now analyzed.
Cloud was the paradigm, the product was the medium for, but what really made possible the remodeling was a change in their attitudes. This turned out to be a successful model since engaged all the actors (IT team, collegues from other business units, and the management) and leveraged the power of data.
It seems like “minimum-required” mindset (“I do the minimum as far as laws, compliances or supervisors expect me to do”) stop organizations from taking strategic decisions by implementing change management processes.
It seems to me that before defining a date-driven strategy, better start remodeling processes.