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. As long as 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. Here, of course, a certain KPI was born for the supplier - what percentage of the items he orders on time (it seems he had to keep within a day, since the need arose).

    Well lays Iceberg on accounting. After all, those who are like - constantly somewhere somewhere is not right. Negative balances are present, on a variety of accounts, or on the registers they hate. Advances are not credited, despite the use of the restoration of the settlement sequence. Not to mention the sum balances without quantity, and vice versa.

    In the normal state of the system, without the Iceberg, it is difficult to get to the bottom of accounting. The only way to prove that the minuses have been hanging for a month is a backup. But they, too, are not fools - they will say that yes, there were minuses a month ago, then we removed them, and now we’ve got out again, it’s you, the programmers, got it wrong. If the suppliers simply otmazyvayutsya, without shifting the problems to others, then the accountants have come up with a long time - I do not know, consciously or not - such a method as artificial time pressure.

    There is a decent programmer at the enterprise who cares about the state of accounting. He sees cons in revolving, and says to accountants - cute aunts, what are you doing, let's eliminate! They first say - yes, of course, we will eliminate, it is in our interests. Cons strongly hurt us at the close of the quarter, be sure to eliminate. At this moment - let's say it is May - no time pressure, i.e. There is no limited time for solving the problem. Therefore, the task of restoring order, as expected, is deposited in the far box.

    It is almost impossible to prevent the creation of negative residues by monitoring current, daily work. Even if the write-off is banned to a minus, there is a patch correction. Therefore, our decent programmer sighs, and waits.

    Before the end of June, the programmer, let's say, reminds the accountant a few more times that it would be nice to remove the minuses. The closer the term, the more aggressive the answer becomes - piss off, it's not your business, don't teach us to work, and, in the end, a complete disregard.

    And then came July, it is necessary to close the quarter. Now the task must be solved in time-trouble mode - as quickly and efficiently as possible, because there is still a lot of things to do, apart from the minuses. If you worked as programmers in a factory, then you know what happens at this moment - the task is quickly and beautifully shifted from accounting to programmers.

    It's too late to resent, although programmers are trying. But accountants give iron arguments - everything, once, it is necessary to hand over the statements, and there are sooooo fines, that the company will have to be closed. The manager, who moderates the curse of the programmer and the accountant, has no choice but to stand on the side of the latter - the threat sounds too real. The programmer there is something whining, like it is the work of an accountant, they know perfectly well what to do, and in general the programmer costs the company three times more than the accountant, and all this is wrong, but it's too late - an artificial time trouble has been created.

    It usually ends this way: the programmer agrees to fix the minuses himself, but the manager and the accountant vow to deal with this systemic problem after time troubles are eliminated. And so - every time.

    The solution is a similar supply. We do an autotask for each version of the joint - for example, we calculate and show the minuses in the revision, set the responsible and, most importantly, the date of the problem, so that the Iceberg will turn out. Now, as soon as a minus has arisen, a task appears, and it can be used as an argument in disputes.

    It is clear that the accounting department will ignore these tasks. But then there will be what the programmer lacks at meetings with the management - facts. Here is a joint, here is the date of its occurrence, here is the duration of a negative state — a month, for example. The main thing is to submit information correctly - look, dear manager, our accounting has been in an uncontrollable state for a month already, we have no idea how much our warehouse costs, how much we incur because we have minuses. You understand, dear manager, the matter is not in minuses, but in relation to accounting. The minus is an extreme situation, an obvious and obvious mistake. And there are still implicit ones that are not visible to the eye, but make it impossible for you to use the data. Well, and so on.

    Even Iceberg directly asks in any processes where there is agreement. Applications for the expenditure of funds, contracts, specifications, budgets, plans, the issuance of special clothes and so on, ad infinitum.

    Bureaucrats love coordination, not as a process to be done, but as a process that can be endlessly delayed. A naive programmer who has been assigned the task of adding a GlavBuk or Chief Financial Officer to the contract is simple and simple — he adds a certain field to this contract, such as “Agreed”. He does not know about the Iceberg, so he condemns the process of negotiating contracts for a slow and painful death.

    Dynamic reconciliation will be indefinitely, if the contract - some not very significant, and is not in the field of view of the director. And the initiators of the treaties will have nothing left to do but periodically run to the chief accountant to find out when the great mystery will happen.

    Iceberg solves the problem immediately and quickly. In this case, it is enough to know two dates - when sent for approval, and when it took place. The duration of the inconsistency state in this case is calculated elementarily, and it is possible to normalize this time.

    I did so with the agreement of contracts, where the chain consisted of several people - the head of the unit, the financier, the accountant and the lawyer. Each was given a day for approval, and the Iceberg brought the percentage of hitting in this period to 90%.

    Then, however, the problem began on the other side - when the contract is agreed and signed on paper, both copies are sent to the counterparty to put his signature and stamp. Accordingly, the piece of paper must then go back to get into the archive of the legal department.

    But people who had previously complained about the long coordination did not hurry to hand over the original contract to lawyers. They generally forgot about it - it is enough for them that the contract is signed, and it is possible to work with the counterparty. Here the lawyers wailed - it is impossible without the originals, any verification would suit the company such Auschwitz, which does not seem like a little.

    Accordingly, another Iceberg appeared, for the delivery of the original contracts. They took a month for ordinary, and 100 days for foreign trade agreements. And everything earned. Especially when lawyers began to reject new contracts until the old ones are handed over. The picture about the number and terms of non-resigned contracts was constantly available in the system, and, in view of the importance of this issue, was constantly monitored by the management. No one wants too often to fall into the sphere of interest of the director, so they almost always handed over the originals on time.

    Also popular now: