Today, many companies have very cleverly built websites to trace in great detail how their users behave: who clicked what, when, and how often. This information is used to continuously improve these websites and their offerings.
Therefore it is strange that there are still companies out there deploying new business systems, such as ERP, document management, CRM, and customer portals, while doing nothing to collect statistics on their user-activity on these systems.
Wouldn’t it be useful to know which functions or transactions are the most popular and which of these are hardly used? Don’t you want to know how much new data gets created per day, how much data is updated, and how much data is archived? What about tracing which user groups do not use the system enough, and learning from your frequent-user-groups? Do you know how many users finished a reservation or registration transaction compared to the number of started transactions?
This kind of information is
- vital during the deployment of a new business system. How else to measure success and user acceptance?
- essential to proof the original business case. How else to calculate e.g. the through put time of the new order-to-cash process?
- fundamental to steer application development in the right direction. How else to make sure the right features and functions will be used?
- crucial to keep check on your master-data quality. How else do you know how many new documents, material codes, and customer registrations your company creates daily?
Why isn’t this kind of information collected? I have seen 3 major reasons.
- Collecting and reporting system-usage statistics is always a function with the lowest priority in the requirement list of a new system. When the project is already late and over budget, all the “nice to have” features are left out.
Remedy: Make it a number one requirement for any new system you implement.
- Even when user activity monitoring is a standard system feature, as for example with Microsoft’s Sharepoint, data security policies (perhaps unintentionally) restrict the execution rights of these functions to a few system administrators; the application owner has no easy way to get the usage reports.
Remedy: Don’t get caught in data security policies; make it part of the system requirement that application owners and other stakeholders can easily get this information.
- It is just an inconvenient truth –better to be denied as the application owner probably already knows that the usage of his/her system is too low, but so much effort has been put into it already…
Remedy: Obviously, this type of behavior should be avoided through a company culture of openness and tolerance for failure when lessons are learned.
So, just for good measure, do increase the value your business systems bring by actively following and acting upon system usage-statistics.