News and Webinars - AGIMENDO

Commenting and why you underestimate your system in the process

Written by Timo Hasenohr | Sep 6, 2021 7:37:50 AM

[Article] Commentary is everywhere today - in social networks, at sporting events, in newspaper columns and not least in applications in working life. In the process, they are increasingly becoming instruments of communication in social networks, whereas otherwise, they continue to fulfill their original purpose.

Supporting understanding

This original goal states that comments are to be understood as hints that facilitate the understanding of a text or event or make it possible in the first place. This is the case, for example, when following a football match on the radio. Without a commentator who, unlike the listeners, sees the game before his eyes and can explain what is happening on the football pitch, the football match on the radio would be no fun.

It is the same when, for example, figures and values are commented on in a business application. Because there, too, the person commenting always knows something that others looking at the same number or value do not (cannot) know. For example, the production manager knows why the production figure for yesterday deviates by 10% from the remaining days or from the plan. The manager may only see the deviation value and be surprised.

With his commentary, the production manager thus performs the same function as the radio commentator: he creates an understanding for the events.

 

Good commentaries are worth their weight in gold

Three criteria are important for a good commentary:
"what", "where" and "why" commentary is made. If we stick to this example and hold the failure of a machine responsible for the 10% deviation, the deviation value alone calls up big question marks in the eyes of the managing director - an appropriate comment on it, on the other hand, explains it. What is commented on: a deviation. Where is it commented: in yesterday's report. Why is it commented: because it has exceeded a value limit (e.g. deviation from plan higher than 6%).

The comment, therefore, saves unnecessary time spent trying to find out why the deviation is so high. A comment in the right place by the right person with the appropriate knowledge is therefore simply worth its weight in gold.

 

The right time is crucial

In addition to these three criteria, there is another one: the "when". Comments can be made at different times - and are often not even specifically defined. Everyone involved can comment at their own discretion. This is where the real value lies.

In our example, for example, the interest in the deviation on exactly the same day is very high, because the manager wants to know whether it is a one-time deviation or a permanent change in the production figure on this machine.

So if comments are made tied to specific events, the message content increases immensely. It can be assumed that, for example, major changes, deviations and the rejection of an application always attract enormous interest from those involved. Requesting comments on these events is therefore a measure that not only increases the content of the comment, but is also a relief for all involved.

That is why more and more companies are taking the next step and "requesting" comments, so to speak, for just such predefined events. In our example with the production figure, we have already established that a deviation was commented on. But if a comment had not been mandatory when this deviation occurred - who knows whether the production manager would have taken the time to comment? Or whether he would have assumed that the manager must have known about the machine failure.

 

The system as comment helper

Event-related commenting is the new approach. It not only offers the possibility of requesting time-related comments on events, figures or values, but also the possibility of involving the system itself in the commenting process. That is, when the system knows that an event has occurred. And that is not so seldom the case. Modern systems are aware of many things and know everything from status transitions (e.g. application has been approved, status changes from "applied for" to "approved") to changes (e.g. the planned production quantity of a machine has been increased by 20% for the next quarter) to deviations (as in our example).

This knowledge, written down in a comment, almost always corresponds to a note that facilitates the understanding of an event. As a rule, the system is also happy to share this information with its users. You just have to ask it.