Eisberg

Jeder weiß, was ein Eisberg ist - ein großes Stück Eis, das im Ozean schwimmt. Jeder erinnert sich, was mit dem Eisberg nicht stimmt - nur ein kleiner Teil davon ist sichtbar, der sich über der Wasseroberfläche befindet, der Rest ist verborgen. Und wie viel ist da, dieser Rest - niemand weiß es.

Ähnliches gilt für Daten in automatisierten Systemen.

Wir sehen normalerweise die Daten selbst. Dokumente wie Liefer- oder Empfangsrechnungen, Überweisungen, Zahlungen usw. Verzeichnisse - Nomenklatur, Gegenparteien, Einheiten. Wir sehen die Aufgaben, sowohl gewöhnliche als auch prozessuale. Wir sehen die Überreste - wie viel Waren auf Lager sind, wer uns Geld schuldet, wie viele Defizite wir haben usw.

Alle Daten, einzeln oder in Kombination, bilden einen bestimmten Zustand. Zum Beispiel befindet sich unser Lager zu jedem Zeitpunkt in einem bestimmten Zustand. Wir sagen es - der Zustand des Lagers. Oder den Status von Forderungen oder Verbindlichkeiten oder den Status von Aufgaben oder den Status von Prozessen.

Wir sind durchaus in der Lage, den Zustand sofort zu beurteilen - sowohl in einem automatisierten System als auch im Leben. Geschätzt, weglaufen und vergessen.

Dann, nach einiger Zeit, stoßen wir wieder auf dieselben Daten oder dieselbe Situation. Wir machen wieder eine sofortige Einschätzung des Staates - wir sagen "alles ist gut" oder "alles ist schlecht". Dies wird ein zweites, drittes, einhundertfünfundzwanzigstes Mal wiederholt.

Wenn wir die Situation als kritisch einschätzen, werden wir sie wahrscheinlich irgendwie korrigieren. Und wenn nicht? Ja, die Situation ist nicht sehr gut, aber es scheint, dass Sie leben können. Dies geschieht häufig bei operativen Besprechungen - jemand wirft eine Frage auf, erzählt die Situation und gibt eine Bewertung ab. Jeder stöhnt oder klappert mit den Zungen und ... was? In der Regel vergessen sie. Bis zum nächsten Mal, bis jemand anderes aufpasst.

Jedes Mal wird eine negative Situation verwöhnt, weil wir es wie zum ersten Mal sehen. Jemand erinnert sich natürlich - oh, es ist schon passiert, ich erinnere mich nicht, wie vor einem Monat oder vielleicht sechs Monaten. Sie stöbern in dem Inhaber eines zu guten Gedächtnisses, um zu schweigen - lassen Sie die Situation als besser als sauber wie ein Baby angesehen werden.

Warum passiert das? Was fehlt in den negativen Situationsinformationen? Es gibt eine sofortige Bewertung, ziemlich hochwertig und detailliert. Wie kann man den Satz „hier ist alles schlecht“ fortsetzen, damit sie mit neuen Farben spielt und informativer wird?

Es ist sehr einfach, den Satz fortzusetzen: "Hier ist alles schlecht und für eine lange Zeit." Die Zeit oder Dauer des Staates ist die Information, die für eine angemessene Entscheidung benötigt wird.

Im Leben versteht das jeder. Lassen Sie mich einige Beispiele nennen.

"Ich habe nicht genug Geld" - eine sofortige Beurteilung erfordert einen chirurgischen Eingriff. „Ich habe seit einem Jahr nicht mehr genug Geld“ - wow, wir haben hier ein systemisches Problem, über das wir nachdenken und etwas im Leben ändern müssen.

"Etwas tut meinem Bein weh" - na ja, man weiß nie, er hat vielleicht Zeit gedient oder das Wetter beeinflusst Arthritis. "Mein Bein ist seit sechs Monaten wund" - sofort in die Klinik laufen.

"Ein Kind hat eine Zwei gebracht" - gut gemacht, es ist höchste Zeit, Zweien werden für das Gleichgewicht benötigt. "Ein Kind bringt nur zwei für das ganze Quartal" - oh, du Idiot ist minderjährig, was machst du dort, morgen gehe ich zur Schule, wo ist die Telefonnummer deines Klassenlehrers.

Ähnliches gilt für Geschäftssysteme.

"Der Kunde schuldet uns eine Million" - zahlen Sie, was Sie belästigen. „Der Kunde schuldet uns jetzt seit sechs Monaten eine Million“ - deine Mutter, wo hast du gesucht?

"Es gibt fünf dringende Positionen in der Defiziterklärung" - die Beschaffer werden bestellen, weshalb Menschen nicht gezogen werden sollten. „Fünf dringende Positionen sind seit zwei Monaten in einer Defizitposition“ - deshalb sinken die Verkäufe! Ziehen Sie alle dringend auf den Teppich, kaufen Sie sofort!

"Programmierer haben meine Aufgabe überfällig" - ja sie alle Aufgaben also, keine Sorge. Wird es tun. "Programmierer haben meine Aufgabe bereits seit zwei Monaten überfällig" - verdammt, ich wollte diese Arschlöcher schon lange zerstreuen, was machen sie dort überhaupt?

Wie Sie sehen können, verleiht die Dauer einer Bedingung, insbesondere einer negativen, der Information eine neue Dimension. Es war, als gäbe es flache, langweilige Informationen, mit denen nicht klar war, was zu tun ist, aber ein dreidimensionales Bild erhalten wurde. Das Analysieren einer Situation und das Treffen einer Entscheidung wird viel einfacher.

Hier ist alles so offensichtlich, dass ich es gar nicht glauben kann - sind solche Banalitäten ein separates Kapitel im Lehrbuch wert? Um diese Frage zu beantworten, werfen Sie einen Blick auf Ihr Informationssystem.

Finden Sie viele Bedingungen mit gemessener Dauer? Traditionell gibt es zwei Berichte, die auf dem Iceberg-Prinzip basieren: illiquide Vermögenswerte und Zahlungsrückstände. Sehen Sie übrigens illiquide Vermögenswerte? Nicht in allen gängigen Systemen sind illiquide Vermögenswerte zu sehen.

Leider gibt es in Informationssystemen nicht einmal einen Begriff von „Staat“. Es gibt Daten und Mittel, um sie aus verschiedenen Blickwinkeln zu betrachten. Eine schicke Weite für einen Analysten, der gerne in großen Zahlenreihen herumstochert, aber nicht genug vernünftige Informationen, um Entscheidungen zu treffen. Darüber hinaus spielt es keine Rolle, wer die Entscheidung trifft - die Person oder das System selbst.

Es gibt verschiedene Möglichkeiten, das Iceberg-Prinzip umzusetzen. Traditionell - Stapelabrechnung, wenn dem Informationsarray ein Trennzeichen hinzugefügt wird - ein Stapeldokument. Zum Beispiel kam die Ware im Lager an - wir erinnern uns nicht nur an die Nomenklatur und Menge, sondern auch an den Beleg - die Rechnung. Die Rechnung hat ein Datum und daraus können wir immer das Fälligkeitsdatum berechnen. Dasselbe tun sie beispielsweise bei Forderungen - sie speichern nicht nur die Gegenpartei und den Betrag, sondern auch das Dokument, aus dem diese Schuld entstanden ist - beispielsweise eine Lieferrechnung oder eine Vorauszahlung an den Lieferanten.

In technischer Hinsicht schafft das Parteidokument viele Schwierigkeiten.

Erstens wird die Anzahl der Datensätze in Tabellen erhöht. Aus einem Eintrag "Hülse, 10 Stück" können zehn Einträge werden - "Hülse 1 Stück ab dem 01.09.2017", "Hülse 1 Stück ab dem 09.12.2017" usw.

Zweitens werden Chargenstornierungsalgorithmen benötigt. Wenn Sie beispielsweise versenden (d. H. Waren abschreiben), müssen Sie wissen, von welcher Charge der Rest abzüglich ist. Oder wenn Sie vom Käufer bezahlen, müssen Sie angeben, für welchen Versandbeleg das Geld eingegangen ist. Es werden zwei Ansätze verwendet: entweder die automatische Berechnung von Chargen oder deren manuelle Anzeige. Automatische Chargenauswahl sind die bekannten Abschreibungsstrategien von FIFO (erste, früheste Charge) und LIFO (erste, letzte Charge). Die manuelle Chargenidentifikation wird üblicherweise bei der Buchung von Zahlungen verwendet.

Das dritte, eher methodische Problem besteht darin, dass das reale Leben dem Batch-Stornierungsalgorithmus nicht folgt. Der Ladenbesitzer nimmt das Teil aus dem Regal, aber nicht das, das das Programm ausgewählt hat. Er weiß nicht, was FIFO ist.

Es stellt sich ein technisch komplexes System heraus, dessen Ergebnisse selten verwendet werden. Ich spreche nicht von Buchhaltung oder Management Accounting, bei dem die Kosten für Abschreibungen anhand von Losen berechnet werden. Ich spreche über die Messung der Dauer eines negativen Zustands - illiquide Vermögenswerte. Wie viele mussten Sie wirklich, regelmäßig und effektiv bei illiquiden Vermögenswerten beobachten?

Die zweite Möglichkeit besteht nicht darin, die Dauer aller Zustände zu speichern, sondern sie gegebenenfalls zu berechnen. Dies ist eine sofortige Schätzung der Dauer. Zum Beispiel kann man illiquide Vermögenswerte in einem Lager finden, ohne Lose zu lagern. Es gibt viele Möglichkeiten - zum Beispiel das Verständnis der aktuellen Salden und den Rückblick auf den Warenverkehr. Wenn es keine Bewegungen gab, dann liegt vor uns ein illiquider Vermögenswert.

Diese Methode hat nicht die Nachteile der Stapelabrechnung - sie erfordert keine Speicherung großer Datenmengen und erschwert die aktuelle Arbeit nicht. Der Hauptvorteil der Chargenabrechnung - die Speicherung der Dauer - liegt jedoch nicht darin. Sie sehen eine Schätzung der Dauer nur sofort zu einem bestimmten Zeitpunkt. Wir gingen hinein, schauten, schätzten, gingen aus - die Bewertung der Dauer verschwand.

Einerseits - okay, das ist okay. Sie können einen Algorithmus zur Berechnung der Dauer verwenden und in die Prozesse einbetten. Lassen Sie das System reagieren, wenn sich der negative Zustand hinzieht. Leider ist die augenblickliche Schätzung der Dauer nicht so augenblicklich - die Systemressourcen werden für die Berechnung aufgewendet, sodass nur die Geräuschkosten pro Minute, die Sie nicht ausführen, anfallen.

Eine sofortige Schätzung der Dauer kann für nicht sehr wichtige Prozesse verwendet werden, die nicht jeden Tag überwacht werden müssen. Zum Beispiel die gleichen illiquiden Vermögenswerte, wenn Sie den Prozess der Veräußerung aufbauen - einmal im Monat führen Sie Berechnungen durch, bestimmen die Liste der am häufigsten angesammelten Gegenstände, bilden die Aufgabe, sie zu veräußern (z. B. Verkauf mit Rabatt oder Verschrottung).

Die dritte Möglichkeit besteht darin, den zugeschnittenen Status zu berechnen, zu trennen, zu speichern und zu verfolgen.

Zum Beispiel haben Sie eine Defizitabrechnung - eine Liste der Waren, die Sie kaufen müssen. Für Produktion, Verkauf, Reparaturen usw. Es macht keinen Sinn, die gesamte Defizitrechnung zu überwachen - ziemlich abgelaufene Positionen. Diese früheren Positionen sind hervorzuheben, weil es nicht viele davon geben wird?

Speichern Sie einfach an einer separaten Stelle im System eine Liste der abgelaufenen Artikel mit Mengen und vor allem dem Datum des Auftretens. Immerhin gibt es dort nicht immer abgelaufene Stellen? Sobald sie erscheinen - denken Sie daran, und das Datum des Erscheinens wird der Ausgangspunkt der Dauer sein.

Dann macht das System alles selbst. Überprüft regelmäßig das Defizit - prüft, ob Positionen abgelaufen sind. Wenn nicht, ausgezeichnet, dann hat der negative Zustand aufgehört. Die gespeicherte Liste überfälliger Positionen kann vergessen und aus dem System gelöscht werden (hier können Sie sie nach eigenem Ermessen als Andenken belassen, d. H. Für eine retrospektive Analyse oder ein Motivationssystem). Wenn abgelaufene Positionen immer noch knapp sind, ist dies auch gut (für das System), da Sie nichts tun müssen, die Uhr tickt und die Dauer wächst.

Eine Person, die ein überfälliges Defizit überwacht, wird einfach glücklich sein. Erstens kann er nicht mehr im Auge behalten - richten Sie einfach eine Benachrichtigung über die Verzögerung ein. Zweitens müssen Sie nicht mehr herausfinden, ob die Verzögerung lange aufgetreten ist - die Dauer wird automatisch angezeigt. Drittens ist es nicht erforderlich, den Moment des Verschwindens der Verzögerung zu verfolgen - das System informiert Sie, wenn die Dinge gut laufen.

Für Sie als Business-Programmierer ist es viel einfacher, Antwortprozesse in einem Business-System zu erstellen. Während es kein Verständnis für die Dauer gibt, sind Sie gezwungen, die Person sofort zu ziehen, sobald ein negativer Zustand aufgetreten ist. Und dein „Zucken“ hängt ständig vor deiner Nase wie ein roter Lappen.

Wenn es eine Dauer gibt, wird die Einstellung feiner - Sie wählen selbst den Moment, in dem Sie einer Person ein Problem zeigen möchten. Sie können auch eine Farbanzeige auswählen, die auf der Dauer des negativen Zustands basiert. Zum Beispiel gelb - ein Tag, rot - zwei oder mehr Tage usw.

Gleichzeitig können Sie ein vorgelagertes Antwortsystem erstellen. Zeigen Sie dem Lieferanten beispielsweise zunächst die Verzögerung des Defizits. Einen Tag später, wenn nicht beseitigt, an den Versorgungschef. Drei Tage später an den kaufmännischen Leiter. In einer Woche - zum Regisseur.

Darüber hinaus verstehen Sie: Sein Wesen hängt von der Ebene ab, auf die die Aufgabe gestiegen ist. Sie bitten den Lieferanten, die Verzögerung zu beseitigen - er muss die Position bestellen. Sie bitten den Supply Manager, aufmerksam zu sein und möglicherweise die Positionen an einen anderen Lieferanten zu übertragen. Sie sagen dem Direktor, dass der gesamte Versorgungsservice irgendwie seltsam funktioniert und Systemänderungen erforderlich sind.

Hauptmerkmale dieser Methode: separate Speicherung von Statusdaten und deren automatische Aktualisierung. Technisch implementiert nach dem Prinzip "Auto Task", auf das später noch eingegangen wird.

Dabei werden Sie sicherlich andere Wege finden, um die Dauer des Zustands zu bestimmen, d. H. die Größe des Unterwassereisbergs. Möglicherweise programmieren Sie in Systemen, in denen die von mir aufgeführten Methoden nicht funktionieren. Dann müssen Sie nach Ihren eigenen suchen.

Hauptsache - vergessen Sie beim Programmieren eines Business-Systems nicht das Prinzip "Eisberg".

Insbesondere wenn Sie die Partitionsabrechnung verwenden möchten, muss diese während des Entwurfs entspannt werden. Nachträglich wird sie nur schwer bereitgestellt.

Eine sofortige Beurteilung der Dauer, wie die "AutoTasks", kann jederzeit erfolgen. Schalten Sie es auch aus. In dieser Leichtigkeit liegt ihr Vorteil.

Ich werde einige Beispiele für die Verwendung des Eisbergs aus meiner Praxis geben.

Das erste Beispiel sind Aufgabenverwaltungssysteme. Es gibt eine Aufgabe oder eine Aufgabe oder ein Memo. Es gibt einen Initiator, es gibt einen Darsteller. Wenn die Aufgabe in die Arbeit aufgenommen wird, ist alles klar - es gibt eine Frist, und Sie können schnell feststellen, ob alles mit der Aufgabe gut ist oder nicht.

Das Problem hat aber auch einige Zwischenzustände. Zum Beispiel hat der Initiator es geschrieben, gesendet und der Executor muss es für die Arbeit akzeptieren. Akzeptanz in der Arbeit ist ein bestimmtes Zeichen in einer Aufgabe. Bis der Auftragnehmer es ablegt, ist der Zustand der Aufgabe der Unterwasserteil des Eisbergs. Keine verdammte Sache ist klar, als er sich endlich dazu entschließt.

Ich habe einfach gehandelt - ich habe das Datum der Annahme hinzugefügt, um als separates Feld in der Aufgabe zu arbeiten. Akzeptiert - das Datum wurde erinnert. Und das Datum des Sendens der Aufgabe an den Testamentsvollstrecker ist bereits vorhanden. Dementsprechend erhalten wir zwei Dauern eines negativen Zustands. Bis zur Annahme der Aufgabe ist die Dauer die Differenz zwischen dem aktuellen Datum und dem Versanddatum. Wenn der Auftragnehmer es dennoch akzeptiert hat, erscheint das genaue Intervall zwischen Annahme und Versand, das im System für immer gespeichert und für die weitere Analyse verwendet wird.

Eine ähnliche Situation mit einer unverständlichen Dauer tritt auf, wenn der Auftragnehmer die Arbeit ausgeführt und zur Überprüfung an den Initiator gesendet hat. Wenn er dort nachschaut, ist es nicht bekannt. Jeder anständige Programmierer, der direkt mit dem Endbenutzer zusammenarbeitet, wird bestätigen, dass Aufgaben beim Test sehr oft einfrieren. Darüber hinaus kann es physisch bereits überprüft werden, der Benutzer mag alles, aber er macht sich nicht die Mühe, sich in das System einzuloggen und eine Notiz zu machen.

Die Lösung ist ähnlich. Wir fügen der Aufgabe zwei Daten hinzu: Als der Auftragnehmer zur Überprüfung schickte und der Initiator reagierte, akzeptierte er das Ergebnis oder kehrte zur Überarbeitung zurück. Dementsprechend ist die Dauer des Überprüfungsstatus immer verfügbar, und wir können die Überprüfungszeit der Aufgabe normalisieren. Nun, das war es nicht.

Mein Lieblingsbeispiel ist die Beschaffung. Bei Aufgaben ist alles einfach - es gibt immer ein Objekt, in dem genau diese Aufgabe aufgezeichnet ist, und Sie können diesem Objekt Felder hinzufügen, in denen Daten zur Dauer des Status gespeichert sind.

Und Beschaffung ist ein Strom. Niemand dort wird bei klarem Verstand separate Aufgaben stellen. Stellen Sie sich vor - ein Mädchen sitzt und bestellt Buchsen. Täglich. Die gleichen Buchsen. Und auch Wellen, Bolzen, Muttern, Metall, Schmiedeteile, Stanzteile usw.

Es gibt nur Informationen darüber, was bestellt werden muss. Ja, es geschieht auf verschiedenen Detailebenen - manchmal nur eine Liste von Artikeln und Mengen, manchmal - von Empfängern, Auftragnehmern, Bestellungen, Einheiten usw. Diese Informationen sind jedoch immer augenblicklich wie ein Blitz. Ich ging hinein - Sie sehen, Sie müssen 1020 Stück bestellen. Eine Minute später trat er ein - wow, es ist schon 1200, weil sich die Situation geändert hat.

Die Beschaffer verstehen dies und nutzen es. Bei Besprechungen, Nachbesprechungen und Mitarbeitern wird oft versucht, den Käufern auf den Grund zu gehen, aber von ihnen wie Wasser von einer Ente. Sie sagen es ihnen - Jungs, und welche Buchsen fehlen? Gestern entstand also nur ein Bedürfnis! - Beantworte diese. Wie ist gestern Nun, gestern. Ich schwöre, ich bin letzten Morgen in einen Mangel geraten, es gab keine Büsche!

Um zu beweisen, dass die Ärmel gestern waren, können Sie nur das Backup erhöhen. Natürlich werden lebende Menschen nicht jeden Tag Backups abholen, daher entwickeln müde Verkäufer und Hersteller ihre eigene Version der Iceberg-Ausdrucke. Zum Beispiel betreten sie das System am Montag, sehen sich das Defizit an und drucken es aus. Wenn ein Problem auftritt oder Reiben mit Lieferanten, zeigen Sie ihnen dieses Stück Papier.

Aber es ist leicht, einem solchen Stück Papier auszuweichen. Die Verkäufer sagen - was schiebst du mir hier rein? Ja, am Montag gab es nicht genug Ärmel, na und? Bereits am Dienstag gab es so viele, dass jeder genug gehabt hätte! Und was Sie heute im System sehen, ist erst gestern entstanden.

Dann sind sie auch gezwungen, sich an Papierangelegenheiten zu beteiligen - sie drucken nicht nur einen Mangel, sondern geben auch die Lieferanten zur Unterschrift. Und Liefertermine werden gebeten, anzubringen. Sie verstehen, dass der Prozess in Bezug auf Effizienz sehr mittelmäßig ist.

Prinzip Iceberg arbeitete in Aufgaben, aber nicht in der Versorgung. Die Verkäufer verstanden, dass etwas getan werden musste, und begannen, Aufgaben für Einkäufe festzulegen - sie erstellten das Objekt direkt, stellten eine Liste mit Positionen auf und warteten auf die Ausführung. Zuerst fing es an zu klappen, dann lehnten die Lieferanten solche Aufgaben dumm ab, mit einem Kommentar wie "Wir müssen keine separaten Anweisungen für unsere Routinearbeit geben". Im Allgemeinen lautet der richtige Kommentar: Wenn Sie eine Aufgabe für alle festlegen, müssen die Reinigungskräfte mit dem System verbunden werden.

Das Problem wurde durch Auto-Tasks und Iceberg gelöst, das standardmäßig vorhanden ist. Die Autotask riecht einfach nach einem Defizit, löst die fehlenden Positionen nach Darstellern auf und bildet einige Objekte, die Informationen darüber enthalten, was bei Lieferanten bestellt werden muss. Das Datum der automatischen Aufgabenbildung wird automatisch festgelegt, ebenso wie das Ausführungsdatum, d.h. Platzierung von Positionen bei Lieferanten.

Wenn zum Beispiel 100 Buchsen erforderlich waren und der Lieferant 70 bestellt hat, wird die Autotask nicht geschlossen, sondern einfach angepasst - jetzt müssen Sie 30 Positionen platzieren.Was wichtig ist, ist das Startdatum des negativen Zustands, d.h. Defizit bleibt gleich. Eine Person bestellte 70 Positionen für ein Zeitintervall und 30 für ein anderes.

Mit der Anwendung des Eisbergs wurde das Problem sehr schnell gelöst, da es unmöglich war, etwas zu verbergen. Erstens erfolgt die Bilanzierung der Dauer des Defizits im Zusammenhang mit Positionen und Mengen und zweitens unter Bezugnahme auf den Auftragnehmer. Natürlich wurde sofort ein bestimmter KPI für den Lieferanten geboren - wie viel Prozent der Positionen, die er pünktlich bestellt (es scheint, dass er den Tag von dem Moment an erfüllen musste, in dem der Bedarf entstand).

Eisberg fällt gut auf Buchhaltung. Für diejenigen stimmt schließlich irgendwo immer etwas nicht. Negative Salden sind in einer Vielzahl von Konten oder in Registern vorhanden, die sie hassen. Vorschüsse werden trotz der Anwendung der Wiederherstellung der Siedlungsreihenfolge nicht gezählt. Ganz zu schweigen von den Gesamtbilanzen ohne Menge und umgekehrt.

Im normalen Zustand des Systems ohne Eisberg ist es schwierig, zur Buchhaltungsabteilung zu gelangen. Der einzige Weg zu beweisen, dass die Nachteile seit einem Monat hängen, ist ein Backup. Aber auch sie sind keine Dummköpfe - sie werden sagen, dass es vor einem Monat Nachteile gab, dann haben wir sie entfernt und jetzt sind wir wieder rausgekommen, Sie Programmierer haben etwas durcheinander gebracht. Wenn sich die Lieferanten einfach entschuldigen, ohne die Probleme auf andere zu verlagern, haben sich die Buchhalter lange - ich weiß nicht, bewusst oder nicht - eine Methode wie künstlichen Zeitdruck ausgedacht.

Es gibt einen anständigen Programmierer im Unternehmen, der sich um den Stand der Buchhaltung kümmert. Er sieht die Nachteile im Hintergrund und sagt den Buchhaltern - liebe Tanten, was machst du, lass es uns beseitigen! Zuerst sagen sie - ja, natürlich werden wir beseitigen, es liegt in unserem Interesse. Nachteile werden uns beim Schließen des Quartals stark behindern. In diesem Moment - sagen wir, dies ist Mai - kein Zeitdruck, d.h. Niemand hat eine begrenzte Zeit, um das Problem zu lösen. Daher wird die Aufgabe, die Ordnung wie erwartet wiederherzustellen, auf die entfernte Box verschoben.

Es ist fast unmöglich, die Bildung negativer Residuen durch Methoden zur Überwachung der aktuellen täglichen Arbeit zu verhindern. Auch wenn Sie negative Abschreibungen verbieten, erfolgt eine Korrektur der Gemeinde. Deshalb seufzt und wartet unser anständiger Programmierer.

So erinnert der Programmierer den Buchhalter beispielsweise vor Ende Juni mehrmals daran, dass es schön wäre, die Nachteile zu beseitigen. Je näher die Frist rückt, desto aggressiver wird die Antwort - verdammt noch mal, es geht Sie nichts an, bringen Sie uns nicht bei, wie man arbeitet, und am Ende ignorieren Sie sie völlig.

Und dann kam der Juli, es ist notwendig, das Quartal zu schließen. Jetzt muss das Problem im Zeitdruckmodus gelöst werden - so schnell und effizient wie möglich, da außer den Minuspunkten noch viel zu tun ist. Wenn Sie als Programmierer in der Fabrik gearbeitet haben, wissen Sie, was gerade passiert - die Aufgabe wechselt schnell und schön von der Buchhaltung zu den Programmierern.

Es ist zu spät, um empört zu sein, obwohl Programmierer es versuchen. Aber Buchhalter geben eiserne Argumente - alles, einmal, ist es notwendig, die Berichterstattung zu übergeben, und es gibt soooo Geldstrafen, dass das Unternehmen geschlossen werden muss. Es gibt nichts mehr für den Führer, der den Missbrauch des Programmierers und Buchhalters mildert, wie er auf die Seite des letzteren treten soll - die Bedrohung klingt zu real. Der Programmierer dort jammert etwas, wie dies die Arbeit eines Buchhalters ist, er weiß, was zu tun ist, und im Allgemeinen kostet ein Programmierer das Unternehmen dreimal so viel wie ein Buchhalter, und all dies ist falsch, aber es ist zu spät - es wurden künstliche Zeitprobleme verursacht.

Es endet normalerweise so: Der Programmierer erklärt sich bereit, die Minuspunkte mit seinen eigenen Händen zu beheben, und der Manager und der Buchhalter versprechen, dieses systemische Problem zu lösen, nachdem der Zeitdruck beseitigt wurde. Und so - jedes Mal.

Die Lösung des Problems ist ähnlich wie bei der Lieferung. Wir führen für jede Variante des Pfostens eine automatische Aufgabe durch. Beispielsweise berechnen und zeigen wir die Minuspunkte im Turnaround, legen den Verantwortlichen und vor allem das Datum fest, an dem die Aufgabe für den Eisberg aufgetreten ist. Sobald ein Minus aufgetreten ist, wird eine automatische Aufgabe angezeigt, die bei Streitigkeiten als Argument verwendet werden kann.

Es ist klar, dass das Rechnungswesen diese Aufgaben ignoriert. Aber dann wird etwas auftauchen, das dem Programmierer bei Besprechungen mit dem Management fehlt - Fakten. Hier ist der Pfosten, hier ist das Datum seines Auftretens, hier ist die Dauer des negativen Zustands - zum Beispiel ein Monat. Die Hauptsache ist, die Informationen korrekt einzureichen - schauen Sie, lieber Leiter, unsere Buchhaltung befindet sich seit einem Monat in einem unkontrollierbaren Zustand. Wir haben keine Ahnung, wie viel unser Lager kostet, wie viel wir angefallen sind, weil wir Nachteile haben. Sie verstehen, lieber Führer, der Punkt liegt nicht in den Minuspunkten, sondern in Bezug auf die Buchhaltung. Minus ist eine extreme Situation, ein offensichtlicher und offensichtlicher Fehler. Und es gibt immer noch implizite, die für das Auge nicht sichtbar sind, Ihnen jedoch die Möglichkeit nehmen, die Daten zu verwenden. Gut und so weiter.

Sogar Iceberg fragt direkt nach Prozessen, bei denen Übereinstimmung besteht. Anträge für Geldausgaben, Verträge, Spezifikationen, Budgets, Pläne, die Ausgabe von Spezialkleidung usw. bis ins Unendliche.

Bürokraten lieben Koordination, aber nicht als einen Prozess, der durchgeführt werden muss, sondern als einen Prozess, der endlos verzögert werden kann. Der naive Programmierer, der beauftragt wurde, die Zustimmung des Hauptbuchhalters oder Finanzdirektors zum Vertrag hinzuzufügen, handelt einfach und unprätentiös - fügt diesem Vertrag ein bestimmtes Feld wie „Einverstanden“ hinzu. Er weiß nichts über Eisberg und verurteilt daher den Prozess der Aushandlung von Vereinbarungen über einen langsamen und schmerzhaften Tod.

Die Koordination wird dynamisch endlos sein, wenn der Vertrag nicht sehr wichtig ist und nicht im Sichtfeld des Direktors liegt. Und die Initiatoren der Verträge werden keine andere Wahl haben, als regelmäßig zum Hauptbuchhalter zu laufen, um herauszufinden, wann das große Abendmahl stattfinden wird.

Iceberg löst das Problem sofort und schnell. In diesem Fall reicht es aus, zwei Daten zu kennen - wann es zur Genehmigung gesendet wurde und wann es stattgefunden hat. Die Dauer des Inkonsistenzzustands wird in diesem Fall elementar berechnet, und Sie können diese Zeit trivial normalisieren.

Ich tat dies mit der Koordination von Verträgen, bei denen die Kette aus mehreren Personen bestand - dem Abteilungsleiter, dem Finanzier, dem Buchhalter und dem Anwalt. Jeder erhielt einen Tag zur Genehmigung, und Iceberg erhöhte den Prozentsatz der Treffer in diesem Zeitraum auf 90%.

Dann begann jedoch das Problem - als die Vereinbarung vereinbart und auf Papier unterzeichnet wurde, werden beide Kopien an die Gegenpartei gesendet, um ihre Unterschrift und sein Siegel anzubringen. Dementsprechend sollte das Blatt Papier dann zurückkommen, um in das Archiv der Rechtsabteilung zu gelangen.

Personen, die sich zuvor über die lange Genehmigung beschwert hatten, hatten es jedoch nicht eilig, die Originale der Verträge an Anwälte zu übergeben. Sie haben es im Allgemeinen vergessen - es reicht ihnen, dass der Vertrag unterzeichnet ist und Sie mit der Gegenpartei zusammenarbeiten können. Hier heulten die Anwälte - es ist unmöglich, ohne die Originale, jeder Scheck wird der Firma so Auschwitz passen, dass es nicht genug scheint.

Dementsprechend schien ein anderer Eisberg die Originale der Verträge zu übergeben. Zuweisung eines Monats für normale und 100 Tage für Außenhandelsabkommen. Und alles hat funktioniert. Besonders als Anwälte anfingen, neue Verträge abzulehnen, bis die alten übergeben wurden. Im System war ständig ein Bild der Anzahl und des Zeitpunkts fehlgeschlagener Verträge verfügbar, und angesichts der Bedeutung dieses Themas stand es unter ständiger Kontrolle des Managements. Niemand möchte zu oft in den Interessensbereich des Regisseurs gelangen, deshalb haben sie die Originale fast immer pünktlich übergeben.