Iceberg

Everyone knows what an iceberg is - a big piece of ice that floats in the ocean. Everyone remembers what is wrong with an iceberg - only a small part of it is visible, which is above the surface of the water, the rest is hidden. And how many of them are there, this rest - nobody knows.

The situation is similar with data in automated systems.

We usually see the data itself. Documents, such as invoices for shipment or receipt, transfers, payment orders, etc. Reference books - nomenclature, contractors, divisions. We see tasks, both ordinary and process ones. We see the remnants of how much goods are in stock, who owes us money, how many deficits we have, etc.
')
Any data, individually or in aggregate, form a certain state. For example, our warehouse, at any given time, is in a state. We say so - the state of the warehouse. Or the state of receivables, or payables, or the status of tasks, or the state of processes.

Instantly assess the state, we are quite capable - and in an automated system, and in life. Appreciated, fled and forgotten.

Then, after some time, we again come across the same data, or situation. We again make an instant assessment of the state - we say “everything is good” or “everything is bad”. This is repeated the second, third, one hundred and twenty-fifth time.

If we assess the situation as critical, then, probably, we will somehow correct it. And if not? Yes, the situation is not very good, but it seems you can live. This is often the case at operational meetings - someone raises a question, tells a situation, gives an assessment. Everyone groans, or clanks his tongues and ... what? As a rule - they forget. Until the next time, until again someone pays attention.

A negative situation every time gets indulgence, because we see it, as if for the first time. Someone, of course, recalls - oh, that was already, I don’t remember, like a month ago, or maybe six months. The owner of a too-good memory is being shouted to be silent - let the situation be considered as clean as a baby.

Why it happens? What is missing in the information about the negative situation? The instant assessment is sufficiently qualitative and detailed. How to continue the phrase “everything is bad here,” so that it starts playing with new colors and becomes more informative?

To continue the sentence is very simple: “everything is bad here, and for a long time already”. Time, or the duration of the state - the information that is needed for adequate decision making.

In life, it is clear to everyone. I will give a couple of examples.

"I do not have enough money" - instant assessment, requires prompt intervention. “I haven't had enough money for a year now” - wow, we have a systemic problem here that we need to think hard about and change something in life.

“Something hurts my leg” - well, you never know, you can sit out, or the weather affects arthritis. “My leg hurts something for half a year already” - urgently run to the polyclinic.

“The child brought a deuce” - well done, it's high time, deuces are needed for balance. “A child brings only two deuces the whole quarter” - oh, you are a minor moron, what are you doing there, tomorrow I’ll go to school, where your class teacher’s phone is.

Similarly in business systems.

"The client owes us a million" - well, pay what you pester. “The client owes us a million half a year already” - your mother, and where did you look?

"In the deficit statement, five urgent positions" - will order suppliers, which is in vain to pull people. “For five months now, there are five urgent positions in the deficit position” - this is why sales are falling! Immediately drag everyone to the carpet, immediately purchase!

“Programmers have overdue my task” - yes, they’re all tasks like that, don’t worry. Will do. “Programmers have already delayed my task by two months” - pancake, have I wanted to disperse these assholes for a long time, what are they doing there?

As you can see, the duration of the state, especially the negative one, gives the information a new dimension. It was as if there was a flat, boring information, with which it is not clear what should be done, but a three-dimensional picture was obtained. Analysis of the situation and decision making becomes much easier.

Everything is so obvious here that I can’t even believe it - are such banalities worth a separate chapter of the textbook? To answer this question, look in your information system.

Many will find states with measured duration? Traditionally, there are two reports on the principle of “Iceberg”: illiquid assets and arrears. Do you, by the way, see illiquid assets? Not in all, even common systems, illiquid assets can be seen.

Unfortunately, in information systems, even the concept of "state" is not. Present data and their means of viewing, from different angles. Chic space for the analyst who likes to poke around in large arrays of numbers, but little sensible information for decision-making. Moreover, it does not matter who makes the decision - the person or the system itself.

There are several ways to implement the “Iceberg” principle. Traditional - batch accounting, when a separator is added to the information array - batch document. For example, the goods came to the warehouse - we remember not only the nomenclature and quantity, but also the receipt document - the invoice. The invoice has a date, and from it we can always calculate the term of the balance. Similarly, they are received, for example, with receivables - they store not only the counterparty and the amount, but also the document that created this debt - for example, the invoice for shipment, or an advance payment to the supplier.

In technical terms, the party document creates many difficulties.

First, it increases the number of records in the tables. One entry "Sleeve, 10 pieces" can turn into ten entries - "Sleeve 1 piece from 09/01/2017", "Sleeve 1 piece from 12/09/2017", etc.

Secondly, batch write-off algorithms are needed. For example, when shipping (ie, writing off the goods) you need to know from which party to minus the rest. Or, when paying from the buyer, you need to indicate for which shipment document the money came. Two approaches are used: either automatic calculation of batches, or their manual indication. Automatic batch selection is a known write-off strategy for a FIFO (first is the earliest batch) and LIFO (first is the latest batch). Manual batching is usually used in posting payments.

The third problem, rather, is methodical - real life does not obey the algorithm for writing off lots. The storekeeper will take a part from the shelf, but not the one chosen by the program. He does not know what FIFO is.

It turns out a technically complex system, the results of which are rarely used. I am not talking now about accounting or management accounting, which uses lots to calculate the cost of write-off. I'm talking about measuring the duration of a negative state - illiquid assets. Have you ever seen a lot of real, regularly and efficiently working processes on illiquid?

The second method is not to store the duration of all states, but to calculate it if necessary. This is an instant estimate of duration. For example, you can find illiquid assets in stock without storing lots. There are many ways - for example, understanding current balances, look back at the movement of goods retrospectively. If there were no movements, then there is illiquid in front of us.

This method has no drawbacks of batch accounting - it does not require storing large amounts of data and does not complicate current work. But the main advantage of the batch accounting - storage of duration - is not in it. You see the estimated duration only instantly, at a particular point in time. Came, looked, estimated, left - the assessment of duration disappeared.

On the one hand - ok, nothing terrible. You can take the algorithm for calculating the duration, and build in the processes - let the system react when the negative state is delayed. But, alas, the instantaneous estimate of the duration is not so instantaneous - the resources of the system are spent on the calculation in such a way that only the noise is worth it, you do not run into every minute.

Instant duration can be used - for not very important processes that should not be monitored every day. For example, the same illiquid assets, when you build the process of getting rid of them - once a month you make calculations, determine the list of the most stale positions, form the task of getting rid of them (for example, selling at a discount or scrap).

The third way is to calculate, separate, store and track the docked state.

For example, you have a deficit list - a list of goods that need to be purchased. For production, sales, repairs, etc. It makes no sense to monitor the entire deficit list - rather overdue positions. These overdue positions are worth highlighting, because there will not be many of them?

Just save in a separate place in the system a list of overdue items, with quantities and, most importantly, the date of occurrence. There are not always overdue positions there? As soon as they appear, you memorize, and the date of appearance will be the point of reference for the duration.

Further, the system does everything itself. Periodically looks at the deficit - checks whether there are overdue positions. If not - fine, then the negative state has stopped. The saved list of overdue positions can be forgotten and deleted from the system (here, at your discretion, you can leave it to memory, ie, for retrospective analysis or motivation system). If overdue positions are still in short supply, it is also good (for the system), because you don’t need to do anything, the clock ticks, the duration increases.

The person who looks after the delay in deficiency will be just happy. First, he can no longer look - just set up a notification about the appearance of the delay. Secondly, you no longer need to figure out how long the delay has appeared - the duration will be shown automatically. Thirdly, it is not necessary to track the time of the disappearance of the delay - the system will let you know when things go smoothly.

As a business programmer, it will be much easier to build response processes in a business system. While there is no understanding of the duration, you are forced to jerk the person as soon as the negative state has arisen. And your "twitching" will hang constantly in front of your nose, like a red rag.

When there is a duration, the setting becomes more subtle - you choose the moment when you show the person the problem. Color display can also be selected based on the duration of the negative state. For example, yellow - one day, red - two or more days, etc.

At the same time, you can build an upstream response system. For example, first the delay in the deficit to show the supplier. A day later, if not eliminated - the head of supply. In three days - to the commercial director. A week later - the director.

Moreover, you understand: the very essence of the task depends on the level to which the task was raised. You ask the supplier to eliminate the delay - he must order the position. You ask the supply manager to pay attention and, possibly, transfer the positions to another supplier. You tell the director that the entire supply service is somehow strangely working, you need systemic changes.

The key features of this method are: separate storage of state data and their automatic updating. Technically implemented using the principle of "Avtozadachi", which will be discussed below.

In the process, you will surely find other ways to determine the duration of the state, i.e. values ​​of the underwater part of the iceberg. You may be programming in such systems where the methods I have listed do not work - then you have to look for your own.

The main thing - do not forget about the principle of "Iceberg" when programming a business system.

Especially if you want to use batch accounting - you need to lay it back when designing, in retrospect it unfolds with great difficulty.

The instantaneous duration estimate, like the Autotasks, can be enabled at any time. Well, turn it off too. In this lightness - their advantage.

I will give a few examples of using the Iceberg from my practice.

The first example is task management systems. There is a task, or an assignment, or a memo. There is an initiator, there is a performer. When the task is accepted, everything is clear - there is a deadline, and you can quickly determine whether everything is good with the task or not.

But the task has certain intermediate states. For example, the initiator wrote it, sent it, and the performer must take it into work. Accepting a job is a sign of a task. Until the executor puts it down, the state of the task is the underwater part of the iceberg. Not a damn thing is clear when he finally deigns to do it.

I acted simply - I added the date of acceptance into the work by a separate field in the task. Accepted - the date was remembered. And the date of sending the task to the performer is already there. Accordingly, we get two durations of the negative state. While the task is not accepted in the work, the duration is equal to the difference between the current date and the date of dispatch. When, nevertheless, the performer accepted it, the exact interval between acceptance and dispatch appears, which is permanently remembered in the system and used for further analysis.

A similar situation, with incomprehensible duration, occurs when the contractor has done the work and sent it to the initiator for verification. When he checks there - is not known. Any decent programmer who works directly with the end user will confirm that the tasks often hang on checking. Moreover, physically it may already be checked, the user likes everything, but he does not bother to log in and make a mark.

The solution is the same. We add two dates to the task - when the executor sent for review, and when the initiator reacted - he accepted the result or returned it for revision. Accordingly, the duration of the check state is always at hand, and we can normalize the task check time. Well, that was not to be.

My favorite example is purchasing. With tasks, everything is simple - there is always some object in which this task is recorded, and you can add fields to this object that store data on the duration of the state.

And purchases are a stream. There, no one in their right mind would set any separate tasks. Well, imagine yourself - a girl is sitting, ordering sleeves. Everyday. Same bushings. And also shafts, bolts, nuts, metal, forgings, stampings, etc.

There is only information that needs to be ordered. Yes, it can be of different levels of detail - sometimes it’s just a list of nomenclature and quantities, sometimes in the context of recipients, contractors, orders, divisions, etc. But this information is always instantaneous, like a flash. I went in - see, you need to order 1020 pieces. A minute later, he went in, already 1200, because the situation has changed.

Providers understand this and take advantage of it. At meetings, debriefings and operatives, purchasers often try to get to the bottom, but they are like water off a duck's back. They say - e, guys, and what sleeves are missing? So this yesterday only need has arisen! - answer those. Like yesterday? Well, yesterday. I swear, I went into deficiency yesterday morning, there were no sleeves!

It is possible to prove that the bushes were yesterday, only by lifting the backup. Of course, living people will not raise backups every day, so tired salespeople and production workers come up with their own version of Iceberg - printouts. They call, for example, on Monday to the system, look into the deficit, and print it. When a problem arises, or float with suppliers, show them this piece of paper.

But from such a paper is easy to dodge. Supplies say-what are you slipping me here? Yes, there were not enough sleeves on Monday, so what? Already on Tuesday there were so many of them that it would be enough for everyone in abundance! And what you see in the system today arose only yesterday.

They are then also forced to participate in paperwork - they do not just print a deficit, but also give suppliers for a signature. And the delivery time is asked to put down. You understand that the process of effectiveness is very so-so.

Principle Iceberg worked in tasks, but did not work in supplies. The sellers understood that they had to do something, and began to set tasks for the purchases - they create the object directly, apply a list of positions to it, and wait for the execution. At first it began to turn out, then the suppliers began to stupidly reject such tasks, with a comment like "we don’t need to put separate orders on our routine work." In general, the correct comment - if for every sneeze to set the task, then the cleaners will have to be connected to the system.

The problem was solved by autotasks and Iceberg, which is enabled there by default. Autotask just looks at the deficit, breaks down the missing positions by performers, and forms some objects containing information about what needs to be ordered from suppliers. The date of the formation of the task is fixed automatically, as well as the date of execution, i.e. posting positions with suppliers.

If it was necessary, for example, 100 sleeves, and the supplier ordered 70, the task does not close, but is simply corrected - now you need to place 30 positions. What is important is the date of the beginning of the negative state, i.e. deficiency remains the same. A person ordered 70 positions in one time interval, and 30 positions after another.

With the use of Iceberg, the problem was quickly resolved, because it was impossible to hide anything. First, the record of the duration of the deficit is maintained in the context of positions and quantities, and secondly, with reference to the performer. , , KPI – (, , ).

. – - - . , , . , . , .

, , . , , . – , , , , , , , - . , , – , – , .

, . , – , , ! – , , , . , . – , – , .. – . , , .

, , . – . , .

, , , . , – , , , , , .

, . – , , . , , – .

, . – , , , , . , , , – . - , , , , , , , – .

, , : - , . – .

– . – , , , , , . , , , .

, . , – . , , – , . – , , , , , , . , , , . – , . , , . .

, . , , , , , . , .

, , , , . , , – , «». , .

, – - , . , , , - .

. – , . , .

, – , , . , 90 %.

, , – , , . , , .

, , . – , , . – , , .

, , . , 100 -. , . , , . , , , . , .