Ein weiteres Stück eines Lehrbuchs über Business-Programmierung.
Grenzprozesse lassen sich am besten automatisieren. Es klingt kitschig, aber eine solche Empfehlung wird bei weitem nicht immer umgesetzt.
Situationen sind immer noch häufig, wenn der Prozess die Grenze überschreitet, ohne automatisierte Systeme zu verwenden. In vielen Unternehmen werden Papiernotizen, Anträge, Bestellungen usw. verwendet. Dies gilt natürlich nicht nur für die Grenzen zwischen den Abteilungen - Mitarbeiter desselben Dienstes sündigen auch mit Papierstücken.
Wenn ein Mitarbeiter den Prozess in Papierform an einen anderen übergibt, ist es äußerst schwierig, den Status dieser Aufgabe zu verfolgen. Die elementare, weit verbreitete Methode, eine solche Aufgabe zu verlieren, drückt sich in der Ausdrucksweise „sauber unter dem Stoff“ aus. Es ist gut, wenn der Mitarbeiter solche Papierstücke auf seinem Desktop stapelt - dann ist zumindest das Volumen der Anwendungen sichtbar. Theoretisch kann sogar ein bestimmtes Stück Papier in diesem Stapel gefunden werden und bestimmen, wie lange es in dieser Warteschlange war.
Eine Methode zum Übertragen eines Prozesses per E-Mail ist ebenfalls üblich. Leider ist dieser Ansatz auch nicht gut. In gewissem Sinne ist es sogar noch schlimmer als ein Stapel Papiere, weil E-Mail-Clients verfügen nicht über ausreichende Funktionen, um Briefe als Aufgaben zu verwalten. Eine Person wird nur einen Berg von Buchstaben haben, was kaum möglich ist, den Zustand der Warteschlange zu bestimmen.
Über die mündliche Übertragung von Aufgaben und nicht erwähnenswert. Wie sie sagen, flog in ein Ohr, flog in das andere.
Es gibt einen weiteren unangenehmen Moment, der mit der Kenntnis der Grenzen verbunden ist. Wenn eine Person die Aufgabe einer anderen Person übergeben hat - auf Papier, mündlich oder per E-Mail -, gehört der Aufgabenträger nun zur zweiten. Aus formaler, moralischer und oft technischer Sicht kann sich der erste nicht mehr mit den Aufgaben des zweiten befassen. Mit einer bestimmten Unterordnungsstruktur können Sie natürlich tiefer in einen Stapel Papiere graben, aber das Lesen der E-Mails eines anderen ist bereits zu viel. Es ist immer noch irgendwie möglich, den Status einer oder mehrerer Ihrer Anwendungen, Ihrer Prozessinstanzen, herauszufinden, aber es ist fast unmöglich, den allgemeinen Status der Warteschlange „an der Grenze“ zu beurteilen.
Wir brauchen also ein automatisiertes Grenzkontrollsystem. Es hat mehrere wichtige Anforderungen.
Die erste Anforderung besteht darin, dass das System die Warteschlange und die darin enthaltenen Aufgaben eindeutig identifizieren muss. Selbst in entwickelten automatisierten Systemen ist dies nicht immer möglich. Wenn Sie eine Person bitten, die Wendung ihrer Aufgaben im Programm anzuzeigen, kann sie etwas demonstrieren - sie zeigt eine Liste von Dokumenten an, wendet einige Filter und Sortierungen an und Sie erhalten eine Liste von Aufgaben. Wenn Sie den Programmierer fragen, wird er dasselbe tun, nur nicht in der Liste der Dokumente, sondern höchstwahrscheinlich durch Abfragen der Daten.
Der Schlüsselbegriff hier ist "wenn Sie fragen." Und wenn Sie nicht fragen? Für einen Business-Programmierer kann diese einfache Frage („Was ist, wenn Sie nicht fragen?“) Ein klares Kriterium für die korrekte Identifizierung der Grenze sein. Wenn Sie als externer Beobachter ohne Aufforderung eines Mitarbeiters eine Liste seiner Aufgaben anzeigen können, ist die erste Anforderung erfüllt - die Warteschlange wird identifiziert.
Mit der scheinbaren Einfachheit dieses Kriteriums werden Sie feststellen, dass die meisten automatisierten Systeme es nicht erfüllen. Das Verständnis der Warteschlange, wie sie sich nur im Kopf eines Mitarbeiters befand, selbst unter Zar Gorokh und Büronotizen, blieb im automatisierten System. Diese Situation ist bekannt und scheint normal zu sein, weil "jeder sie hat". Wenn Sie als Business-Programmierer diesen Prozess verbessern möchten, müssen Sie die Warteschlange identifizieren.
Die zweite Anforderung besteht darin, dass die Warteschlange vor Aufgaben zerlegt werden muss, d. H. zu einfachen Entitäten, die verständliche Handlungen erfordern. Es kommt vor, dass die Warteschlange identifiziert zu sein scheint, aber Aufgaben aus verschiedenen Prozessen darin gemischt sind. In diesem Fall ist die Steuerbarkeit und Steuerbarkeit der Warteschlange eine ernste Frage.
Das Kriterium ist einfach: Wenn Sie, ohne einen Mitarbeiter zu fragen, Ihnen für jede bestimmte Aufgabe mitteilen können, was zu tun ist, wird die Warteschlange korrekt zerlegt. Wenn die Antwort lautet "es ist notwendig zu verstehen" oder "es ist notwendig, es irgendwie zu reparieren" oder "hat noch nicht ausgesehen", dann ist die Zerlegung schlecht. Das System und der Prozess hängen weiterhin vom Mitarbeiter ab.
Die dritte Voraussetzung ist, dass die Prioritäten für die Erfüllung der Aufgaben klar sind. Das Prinzip ist das gleiche wie bei den vorherigen Kriterien. Wenn Sie die Warteschlange von der Seite betrachten und die Reihenfolge der Aufgaben sehen, sind die Prioritäten klar. Wenn Sie oder Verbraucher des Prozesses den Mitarbeiter nach Prioritäten fragen oder diese Prioritäten jeden Tag zurücksetzen müssen, wird die Warteschlange schlecht verwaltet.
Die vierte Anforderung besteht darin, dass die von der Aufgabe in der Warteschlange verbrachte Zeit, d.h. Das Prinzip "Eisberg" wird angewendet. Die aufgewendete Zeit ist normalerweise mit den Ausführungsprioritäten verknüpft, es gibt jedoch auch Konflikte.
Zum Beispiel basiert das Prioritätssystem auf doppelter Sortierung - zuerst die Wichtigkeit, dann das Datum der Aufgabe. In diesem Fall wird es bei einer großen Anzahl wichtiger Aufgaben niemals das Unwichtige erreichen. Wenn der Prozess so ist, dass die ewige Nichterfüllung einiger Aufgaben als Norm angesehen wird, ist das in Ordnung. In der Regel ist es bei Streaming-Prozessen jedoch wichtig, alle Aufgaben zu erledigen.
Daher muss die gegenseitige Beeinflussung von Priorität und Zeit in der Warteschlange überwacht werden. Wenn Sie beispielsweise das Prioritätssystem angegeben haben, fügen Sie der in der Warteschlange verbrachten Zeit einen Gewichtskoeffizienten hinzu, damit die Aufgabe bei einem bestimmten Wert unabhängig von ihrer Wichtigkeit an die Oberfläche schwebt.
Das Kriterium ist also einfach: Wenn Sie sehen, dass jede Aufgabe Zeit in der Warteschlange hat, ist die Anforderung erfüllt. Ein typischer Fehler ist die Meinung, dass es ausreicht, das Datum der Problemstellung zu kennen und zu sehen, da in diesem Fall die in der Warteschlange verbrachte Zeit leicht berechnet werden kann. Automatisierung ist wirklich einfach. Aber im Kopf zu rechnen ist viel schwieriger, und kein einziger vernünftiger Mitarbeiter wird dies tun. Daher wird die in der Warteschlange verbrachte Zeit bei der Arbeit nicht berücksichtigt.
Die fünfte Anforderung ist egal wie banal, aber der Ausführende der Aufgabe muss bekannt sein. Wenn die Wahl des Auftragnehmers durch einen automatisierten Algorithmus geregelt wird, sollte der Zeitpunkt verstanden werden, zu dem dieser Algorithmus ausgeführt wird.
Solange die Aufgabe keinen Executor hat, wird sie nicht gelöst. Der Auftragnehmer muss nicht jeder bestimmten Aufgabe zugewiesen werden - es reicht zu verstehen, dass die Lösung für alle Aufgaben der identifizierten Warteschlange einer bestimmten Person zugewiesen ist.
Die Wahl eines Auftragnehmers führt häufig dazu, dass eine Warteschlange in Fällen leer ist, in denen der Auftragnehmer im Prozess nicht eine bestimmte Person, sondern eine Position oder Abteilung bestimmt. In diesem Fall wird empfohlen, die Auswahl des Executors als separate Aufgabe vorzunehmen, die der Manager oder ein bestimmter Dispatcher ausführen sollte. Während die Wahl des Auftragnehmers keine Aufgabe, sondern ein Privileg ist, bleibt die Warteschlange an dieser Stelle ständig hängen.
Das Kriterium ist einfach: Wenn Sie von der Seite der Linie schauen, müssen Sie genau wissen, wer die Aufgabe erledigen wird.
Die sechste Anforderung aus den höheren Bereichen der Business-Programmierung: Das System muss in der Lage sein, Warteschlangen aus verschiedenen Prozessen anzuzeigen und zu vergleichen. Im allgemeinen Fall wird eine solche Anforderung niemals erfüllt, sodass wir nur über den Grad der Einhaltung sprechen können.
Das Problem besteht normalerweise darin, dass unterschiedliche Warteschlangen, Aufgaben und Prozesse unterschiedliche Systementitäten mit nicht zusammenhängenden Eigenschaften sind. In einer Warteschlange befindet sich eine Prozessinstanz, in einer anderen jedoch nicht. Eine Aufgabe hat ein Produktionsdatum, die andere nicht. Usw.
Angesichts einer solchen Vielfalt von Entitäten löst normalerweise niemand die Aufgabe, alle Warteschlangen „in einem Fenster“ zu steuern - weder in automatisierten Systemen noch in der manuellen Steuerung. Daher bleibt der Status der Warteschlangen - sowohl Momentan als auch Metriken pro Periode - ein Rätsel, was die Effektivität der Verwaltung und Analyse verringert.
Teilweise helfen Prozesssteuerungssysteme, die eine Vielzahl von Primärdokumenten zu einzelnen Entitäten "zusammenfassen". So erscheinen Prozesskarten, allgemeine Aufgaben und Adressierungseinheiten.
Aber für einen Business-Programmierer ist dieser Ansatz leider nicht sehr geeignet.
Erstens führt die Anwendung von Prozessen in der Regel zu einer Komplikation der Automatisierung - weniger in der Entwicklungsphase als vielmehr in späteren Änderungen. Der Prozess mit der Karte, den Ausführenden, den Aktionen und Bedingungen an sich ist ein Objekt der Automatisierung mit allen sich daraus ergebenden Konsequenzen - Notwendigkeit von Wartung, Debugging, Koordination usw.
Zweitens kann aufgrund des „Eins-Viele“ -Konflikts in der Regel kein reales Bild von Prozessen gezeichnet werden. Die meisten Prozesszeichnungssysteme möchten, dass jeweils ein Objekt ausgeführt wird, auch wenn das Objekt mehrere Objekte enthält.
Zum Beispiel der Prozess der Ausführung einer Bestellanforderung. Wenn Sie eine End-to-End-Zuordnung dieses Prozesses zeichnen, stellt sich heraus, dass dieselbe Anwendung vom Anfang bis zum Ende ausgeführt wird. Nach der Prozesslandkarte muss derselbe Lieferant mit jeder Anwendung als Teil der Prozessinstanz separat arbeiten.
In der Realität nimmt der Lieferant überhaupt nicht am End-to-End-Prozess teil. Er hat seine eigene Karte, an deren Eingang sich eine Reihe von Anwendungen befindet. Darüber hinaus jeden Tag - mit einem anderen Volumen (einschließlich manchmal leer). Nach dem Ausführen einer bestimmten Anwendung von dieser ersten Instanz kehrt die Verwaltung zu einem einzelnen Prozess zurück.
Ein solcher Prozess kann nur mit verschachtelten Prozessen gezeichnet werden, was normalerweise erfolgreich ist, aber die Einfachheit und Klarheit des Algorithmus geht verloren - er wird technisch, für Programmierer verständlich, aber nicht für lebende Personen und das Management geeignet.
Drittens sind solche Prozesse anfällig für Bürokratisierung - sie bemühen sich, sie zu „Stahlbeton“ zu machen, sie zu koordinieren, auszudrucken und ins Regal zu stellen. Dieser Ansatz widerspricht den Prinzipien der schnellen Automatisierung und ist daher nicht für die Business-Programmierung geeignet. Das Konkretisieren von Prozessen, insbesondere während des Debugging-Zeitraums, entspricht dem Drucken von Programmcode.
Und viertens bieten Entwickler von Mechanismen zum Zeichnen von Prozessen, die nur von der Programmiererlogik geleitet werden, keine Tools zur Warteschlangenverwaltung an. Dementsprechend funktioniert es nicht, unterwegs alle Linien an den Grenzen zu analysieren und miteinander zu vergleichen. Sie müssen noch Ihre eigenen Werkzeuge erfinden.
Die Methode zum Zeichnen von "Stahlbeton" -Prozessen kann als Hilfsmittel verwendet werden, es wird nicht viel Schaden anrichten. Oder es kann am Ende des Projekts verwendet werden, um die konfigurierten Prozesse beizubehalten. Bis zum nächsten Projekt.
Vergessen Sie jedoch nicht den dritten Punkt - die Tendenz zur Bürokratisierung. Wenn Sie den Eindruck haben, dass Sie das System für eine Weile erhalten können, sind die übrigen Mitarbeiter und Manager der gegenteiligen Meinung: Berühren Sie nicht, was funktioniert. Das von Ihnen erstellte, debuggte und implementierte System wird sich Ihnen widersetzen.
Es ist viel besser, das Prinzip "Automatische Aufgabe" oder ähnliches zu verwenden, wenn Ihr System Entitäten hat, die an laufende Prozesse "anhängen" und Aufgaben in einer Warteschlange erstellen können. Das Prinzip selbst wird später betrachtet.
Eine einzelne Entität zum Verwalten von Warteschlangen an Grenzen liefert zunächst ein einziges Koordinatensystem - die Metriken aller Prozesse in denselben Einheiten. Jeder Prozess kann - sofort und im Nachhinein - im gleichen Maßstab bewertet werden.
Die sofortige Auswertung kann beispielsweise in einem gemeinsamen Prozesssteuerungsfeld implementiert werden. Nicht in der traditionellen allgemeinen Prozesslandkarte, die ohne Scrollen nicht auf einem Bildschirm angezeigt werden kann, sondern in Form einer einfachen Liste, auch ohne Zahlen, mit einem Farbdisplay wie einer Ampel. Dies führt zu einer Liste von zwei Spalten: Prozess und Status.
Die Option ist etwas interessanter - keine Liste von Prozessen, sondern eine Liste von Problempunkten. In diesem Fall geht es um eine Autotask, einen bestimmten Knotenpunkt eines bestimmten Prozesses, der eindeutig mit dem Leben vergleichbar ist. Zum Beispiel "Vereinbarung von Verträgen durch einen Anwalt". Es reicht aus, alle Punkte aufzulisten, ihren Status anzuzeigen und so zu sortieren, dass die problematischsten oben angezeigt werden.
Eine solche sofortige Bewertung aller Prozesse ist trotz ihrer offensichtlichen Einfachheit und Offensichtlichkeit äußerst selten. Jetzt verstehst du warum.
Eine retrospektive Warteschlangenanalyse ist noch seltener, da die meisten Systeme überhaupt nicht die erforderlichen Daten enthalten. Solche Daten sind nur verfügbar, wenn das Iceberg-Prinzip vollständig genutzt wird, wenn nicht nur die momentane Zustandszeit gespeichert wird, sondern auch deren Verlauf.
Wie Sie sehen, ist die Automatisierung der Grenzkontrolle im Allgemeinen nicht kompliziert. Es ist wichtig, keine künstlichen Schwierigkeiten bei der Verwendung von „Stahlbeton“ -Prozessen zu verursachen und die Prinzipien der schnellen Automatisierung zu ignorieren. Die Ansätze und Kriterien, die Sie zur Automatisierung der Grenzzustände von Prozessen verwenden müssen, sind Ihnen jetzt bekannt.