The Importance of Data in Digital Employee Experience
When it comes to measuring DEX, there is nothing more important than data. Without it, IT is flying on a hope and a prayer. With it, IT at least has a chance at comprehending the end user experience.
How many employees experience Microsoft Teams or Zoom crashing daily?
It is a simple question, but if IT cannot answer how many employees have a critical application crash in the middle of using it on a daily basis, what exactly can IT answer?
It is not enough to look at incidents at the service desk to understand how end users are taking it upon themselves to call. Or just looking at customer satisfaction surveys. It is especially not enough to assume everything is fine unless Microsoft tells you there is an outage.
Without statistics like this, IT simply is not paying attention in the places where it should be paying attention and getting statistics like this starts with gathering data and gathering a lot of it.
In the context of employee’s devices, collecting events like system crashes, application crashes, boot time and network connectivity is an absolute must if IT wants to better understand the reality of what is happening on their devices throughout the enterprise.
To collect data like this, enterprises need a platform to collect this data. Typically, an agent continuously running in the background while the user does their job and feeding the data to a server which will warehouse it. That raw data can then be measured, analyzed and in many cases be used to fix technology that has gone awry, thus improving experience for users.
A fundamental piece to DEX is the data. Although not the most important, that comes later.
What should be collected?
Traditionally in IT, data is collected from the server systems. This makes sense to a certain degree because we know users are connecting to a system, so gathering data from these systems is an easy thing to do and makes the exercise easier. The issue is, it’s only telling half the story and in most cases server data does not paint a picture of what was happening to the end user.
Take for example looking at users using a SaaS application. Data can be collected from the server side to see connections that are occurring on each device.
If you think about all of the events that happen on a given device, collecting EVERYTHING, is simply not possible. That would require an immense amount of storage, and ultimately the vast majority of this data would be useless. There are though certain data that should be captured from a device to gain insight.
Application use is one of the most important data events to capture on a device. By application I mean installed applications and also web applications. With the use of SaaS products rising, it’s important that web interactions are captured through the browser. Data such as page load times, failed connections, pages will be very relevant to measuring how a web application is performing.
In an enterprise chances there are still a fair amount of desktop installed applications. These would be your Office 365, Acrobat, SAP for instance. For these applications, we can capture events such as crashing, not responding, network traffic and of course execution events.
Other performance events such as high CPU/memory/IO can provide insight into how slow a device is performing for an end user. Rest assured that if an end user is constantly using a device where the CPU is spiking, it’s effecting their productivity significantly.
I won’t go into detail about all of the events to capture on a device, but here are some more that are crucial
Blue screens
Disk failures
Page faults
Software installations/uninstalls
Network connections
User logons
Print jobs
Where should the data go?
In terms of where you store this data, this may depend on the platform being used in the enterprise, but likely this is going to be centralized SaaS database of sorts. Some platforms will store a certain amount of data locally on the devices an agent is running on, but ultimately this data will end up in a database. As you can imagine, attempting to store raw data like this will take some very efficient architecture that can handle both the storage and querying of such data, with cloud computing this now possible.
Data retention will likely be an issue depending on the number of devices an organization has, so it be necessary to take some of this important raw data and extract it from the platform and place it in the organizations private cloud. Doing this ensures there can be historical storage and analysis of the raw data.
What should be done with it?
This is where things get interesting. It is critical that enterprises come up with a plan on how to perform analysis at scale on their data. While pulling this data into visualization tools can help this, what many enterprises are finding is that this does not scale well. Reports and dashboards are a great way to visualize and tell a story of the data, but inefficient. way of observing trends and issues at scale. Dashboards are only as good as the users looking at them, and just having one is not enough.
When it comes to finding problems, this is where some advanced alerting comes into play. Take for instance attempting to identify applications that are frequently crashing on your devices. This would require a staff member to go through a dashboard to look at each and every application. It doesn’t take much to understand, that this is a task that computers can do much better. Proper and sophisticated alerting should be setup to perform automated analysis and measurements on data to take action on issues occurring. What action depends on what maturity level the organization is currently at, so it could be simply sending an email to a distribution list, creating an incident, or even automating the solution to the issue entirely.
From my perspective the cash value of data in terms of DEX is the actions being done to resolve the problems. Yes, simply knowing what the problems are can provide insight and has some value, but actually resolving it is where the impact will be felt from the end user.