Lassen Sie uns über die praktische Anwendung eines sehr interessanten Themas sprechen - des systemischen Denkens.
Es gibt viele Prinzipien und Methoden im systemischen Denken. Ich empfehle dringend, die einschlägige Literatur zu lesen. Zum Beispiel ein einfaches und interessantes
Buch . Heute werden wir nur ein Prinzip ansprechen - emergente oder aufkommende Eigenschaften von Systemen.
Ich erzähle Ihnen von der Theorie und vor allem von den praktischen Aspekten der Anwendung. In unserem Leben - Programmierer, Implementierer, Architekten, Analysten und Projektmanager.
Zunächst jedoch eine kleine Theorie.
Systeme und Eigenschaften
Bei der Arbeit beschäftigen wir uns fast immer mit Systemen - komplexen Sammlungen von Menschen, Prozessen, Beziehungen (formell und informell), expliziten und verborgenen Führungskräften, materiellen Objekten, Informationssystemen, Kunden, Lieferanten, Geräten usw. bis ins Unendliche.
Wenn Sie alle Elemente vor sich haben, sie kennen oder sogar sehen - zum Beispiel alles an einem Ort zusammenfassen -, dann ist dies kein System, sondern eine Reihe von Elementen. Nur ein paar Details.
Wie macht man aus diesem Haufen ein System? Sie müssen die Elemente an ihre Stelle setzen und einschalten - starten Sie das System in Arbeit.
Dies wird von gewöhnlichen Programmierern oder Ingenieuren gut verstanden. Hier ist der Programmcode, hier ist ein Computer oder Server, hier sind die Eingabedaten für die Verarbeitung. Drücken Sie ON - das System funktioniert. Nun, oder hat nicht funktioniert, wenn ein Fehler vorliegt.
In Systemen, die aus Menschen bestehen, ist normalerweise das Gegenteil der Fall, und dieser Unterschied ist der Schlüssel. Systeme von Menschen haben vor Ihnen gearbeitet und werden nach Ihnen arbeiten. Aber sie werden in Ihrer Gegenwart nicht
mit Ihnen zusammenarbeiten . In Ihrer Gegenwart sind sie keine Systeme mehr und verwandeln sich wieder in eine Reihe von Elementen.
Zurück zum obigen Beispiel, als Sie alles und alle Elemente des Systems an einem Ort gesammelt haben. Was hast du getan Sie haben
das System ausgeschaltet.
Was ist der Unterschied zwischen dem Ein- und Ausschalten des Systems? Menschen mögen das Gleiche, die gleichen Positionen, die gleichen Prozesse, den gleichen Führer - alles ist vorhanden.
Der Unterschied in den Eigenschaften des Systems, die sich nur manifestieren, wenn es "eingeschaltet" ist, dh wenn das System läuft.
Beispiele für solche Systemeigenschaften gibt es überall, Sie können sie ohne Schwierigkeiten finden.
Ein Fernseher ohne Strom ist ein ausgeschaltetes System, das uns nicht seine Hauptfunktion zeigt - das Anzeigen eines Bildes. Schalten Sie den Fernseher ein - Sie sehen das Bild, die Funktion erscheint. Wenn Sie Wasser auf einen funktionierenden Fernseher spritzen, sehen Sie eine neue Eigenschaft des Systems, die Sie möglicherweise nicht kennen.
Solche Eigenschaften des Systems werden als
emergent oder
auftauchend bezeichnet .
Sie entstehen, wenn ein System aus einer Reihe von Elementen zusammengesetzt und eingeschaltet wird. Beide Bedingungen sind wichtig - es ist sowohl zusammengebaut als auch eingeschaltet. In unserem Fall, wenn es sich nicht ausschalten lässt.
Unsere Aufgabe ist es also, das System zu verstehen, um es anschließend zu ändern. Wie verstehe ich das System?
Nicht ausschalten
Es ist sehr einfach, sie zu beobachten, ohne sie auszuschalten.
Genau wie wir den Code debuggen - schalten Sie ihn ein und sehen Sie, was passiert. Grundsätzlich können Sie den Code mit Ihren Augen debuggen, aber mit einem Ausdruck - erinnern Sie sich am Institut daran, „ein Programm aufzulisten“? Aber so scheinen es nur wenige Menschen zu tun. Die Systeme, die wir erstellen, sind zu komplex. Viele Abhängigkeiten, denen wir nicht unterliegen, aber beim Debuggen daran zu basteln, ist eine undankbare Aufgabe.
Bei herkömmlichen Nicht-Computersystemen ist dies noch komplizierter. Es gibt keine "Auflistung". Stellen Sie sich vor, wie hoch es wäre, mit „menschlichen“ Systemen zu arbeiten, wenn das Kontrollkästchen „Bei abgefangenen Ausnahmen anhalten“ vorhanden wäre.
Wie schalten wir das System normalerweise aus:
- Wir sprechen individuell mit den Mitarbeitern
- Wir sprechen mit allen Mitarbeitern gleichzeitig
- Wir bringen alle zu einer informellen Veranstaltung
- Wir stellen eine Anfrage an die Mitarbeiter, stellen eine Aufgabe ein und fordern einen Bericht an
- Bitte beschreiben Sie ihre Aktivitäten oder schreiben Sie einen Geschäftsprozess
- Treffen von Führungskräften bei einem Meeting
- Wir fragen ehemalige Mitarbeiter, wie das System funktioniert
- Usw.
Es stellt sich heraus, dass alle unsere üblichen Aktionen zum Herunterfahren von Systemen führen und versuchen, die aufkommenden Eigenschaften einer Reihe von Elementen zu verstehen.
Sherlock Holmes hat bei diesem Job hervorragende Arbeit geleistet, er nannte es Abzug - um das Bild im Detail zu verstehen. Er hatte zwar keine andere Wahl - Sie werden den Verbrecher nicht bitten, das Verbrechen in Gegenwart des Suchgenies erneut zu begehen.
Unsere Situation ist einfacher und es besteht die Möglichkeit, funktionierende, unveränderte Systeme zu beobachten.
Die beste Methode ist natürlich, ständig im System präsent zu sein, ein Teil davon zu sein und es gleichzeitig aus der Ferne zu beobachten. Dies ist beispielsweise der Pfad eines Scrum Masters. Und per Definition die Rolle des unmittelbaren Vorgesetzten. Es sei denn natürlich, er führt keine Besprechungen durch, anstatt zu arbeiten.
Ein ähnliches Beispiel ist beispielsweise ein Trainer in einer Fußballmannschaft. Dort gehört es zur Aufgabe, das System in seiner ganzen Kraft in Aktion zu überwachen.
Was machen wir, Büroangestellte, geteilt durch Trennwände, Schränke, manchmal Kontinente?
Führen Sie eine verdeckte Überwachung persönlich oder mit technischen Mitteln durch.
Beobachtung
Persönliche Beobachtung ist nicht immer möglich, alles hängt von Ihrer Position bezüglich des beobachteten Systems ab.
Wenn Sie in einer Organisation arbeiten, können Sie Ihren Arbeitsplatz einfach dort platzieren, wo sich das System befindet - Personen, deren Interaktion Sie verstehen möchten.
Zuerst sind Sie ein Fremdelement, das das System ausschaltet. Aber nach und nach werden sie sich an dich gewöhnen und aufhören, auf dich zu achten.
Um sich schneller an Sie zu gewöhnen, tun Sie so, als wären Sie nicht besonders daran interessiert, was um Sie herum passiert. Sie können so tun, als würden Sie begeistert am Computer arbeiten, Ihre Kopfhörer aufsetzen und die Musik einschalten - aber leise, um zu hören, was um Sie herum passiert. Geben Sie nicht vor, Gespräche zu hören. Genauer gesagt, tun Sie so, als würden Sie nicht auf Gespräche hören. Ich denke, weiter werden Sie selbst herausfinden, wie Sie beitreten können.
Wenn sich in Ihrem Team Personen befinden, denen der Beitritt zum System leichter fällt, können Sie diese mit einer übersichtlichen Installation senden.
Sie können eine Vielzahl von
Tools verwenden, um die Aktionen von Personen in den Systemen zu verfolgen . Sie werden nicht das gesamte System auf diese Weise sehen, aber zumindest werden Sie herausfinden, ob Benutzer Ihre Tools verwenden oder nicht. In Worten sagen sie eine Sache, aber in Wirklichkeit eine andere.
Die Praxis zeigt, dass normalerweise 2-5 Tage ausreichen, um sich ein Bild vom System zu machen. Dies ist kein äußerst genaues Bild, sondern eine Skizze, die eine allgemeine, integrale Sicht auf das System vermittelt.
Die Skizze kann anschließend bereits ohne Beobachtung mit Details ergänzt werden. Ergänzen Sie beispielsweise mit Hypothesentestdaten, Daten von Steuerungssystemen usw.
Interessanterweise hilft die Beobachtung bei der Entwicklung von Vorhersagefähigkeiten. Prognosen helfen dabei, anhand von Erfahrungen und Kenntnissen über das Verhalten von Systemen schnell zu verstehen, welche Methoden und Änderungen funktionieren und Ergebnisse bringen und welche nicht. Dies ist eine weitere Anwendung des systemischen Denkens und der aufkommenden Eigenschaften von Systemen. Wir werden im Folgenden darauf eingehen.
Daher ist die Überwachung eines funktionierenden Systems, das nicht ausgeschaltet ist, eine hervorragende Methode, die nur schwer durch etwas ersetzt werden kann. Beobachtung hilft, das System so genau, unparteiisch und objektiv wie möglich ohne Interpretation zu sehen.
Jede andere Option ist die
Interpretation oder Projektion in einem bestimmten Koordinatensystem. Vor allem, wenn Sie von seinem Leiter nach dem System fragen (wie so oft). Dies gilt nicht nur für die Arbeit des Programmierers, sondern auch für den Tagesablauf des Managements.
Tatsächlich ist dieser Ansatz nichts Neues, er wird häufig in bestimmten Bereichen verwendet.
Im Einzelhandel und im Dienstleistungssektor werden beispielsweise Testkäufer eingesetzt - Personen, die gezielt in ein Geschäft, ein Hotel usw. geschickt werden, damit sie das System so sehen können, wie es ist.
Neu bei diesem Ansatz ist die Verwendung in der Arbeit eines normalen Unternehmens, in der Regel nicht im Zusammenhang mit der Einzelhandelsproduktion. Wir nehmen die alte bekannte Methode, finden eine neue Anwendung.
Prognose
Nun zur Prognose. In der Arbeit eines Programmierers tritt häufig eine Situation auf, in der Sie eine Prognose über den Erfolg eines Projekts abgeben müssen. In der Regel handelt es sich um Projekte der internen Organisationsentwicklung des Unternehmens. Einfach ausgedrückt, über Entwurfsänderungen.
Sie fragen normalerweise nach Projekten anderer Leute - solchen, an denen ein Business-Programmierer nicht beteiligt ist. Das heißt, über Projekte, die nicht nach den Regeln der Business-Programmierung durchgeführt werden, sondern nach der Regel "wie ich kann".
Ein Business-Programmierer sagt nach einer kurzen Untersuchung der Informationen über ein geplantes Projekt normalerweise, dass daraus nichts Nützliches werden wird. Oder - es wird überhaupt nichts klappen. Der Unterschied ist klar: Das Projekt kann erfolgreich, pünktlich und budgetgerecht abgeschlossen werden, bringt jedoch keinen Nutzen für das Unternehmen.
Die geäußerte Meinung, d.h. Die Prognose eines Business-Programmierers führt normalerweise zu negativen Reaktionen - Depressionen, Wut, Ablehnung, „Wer bist du?“, „Handeln“ Gott auf Erden oder was? " usw.
Eine negative Reaktion verstärkt sich, wenn die Prognose wahr wird, und sie wird sehr oft wahr.
Allerdings ist nicht alles so traurig, und nach und nach gewöhnen sich die Menschen an eine solche "Supermacht" eines Business-Programmierers und setzen sie sogar zum Wohle des Unternehmens oder des eigenen Unternehmens angemessen ein. Einige führen sogar Aufzeichnungen über Prognosen - ein Notizbuch, in dem sie ankreuzen: „Er hatte Recht.“ Zum Beispiel hatten zwei meiner Kollegen ein solches Notizbuch. Ich weiß es nicht wirklich, virtuell oder real.
Nun wollen wir sehen, wie ein Business-Programmierer solche Prognosen erstellt.
Woher kommen die Prognosen?
Es geht darum, Kenntnisse über das Systemverhalten zu nutzen.
Das Änderungsprojekt enthält immer mindestens zwei Systeme: variabel und sich ändernd.
Variabel -
was wir verbessern werden . Geschäftsprozess, Einheitsarbeit, Interaktion von Funktionen usw. Wir werden es das
Objekt der Veränderung nennen .
Veränderung -
derjenige, der Veränderungen erfindet, implementiert und implementiert . Einfach ausgedrückt, das Change-Implementierungsteam. Wir werden sie das
Thema der Veränderung nennen .
Beide Systeme bestehen aus einer Reihe von Elementen und Beziehungen zwischen ihnen. Dies sind Menschen, Informationssysteme, Ziele, formelle und informelle Beziehungen, Managementmodell, Führungsansätze, einflussreiche Kräfte usw.
In dem Subjekt, d.h. Für das Projekt und das Team der Änderungen gibt es bestimmte Elemente - den Algorithmus zur Auswahl der zu implementierenden Methoden, das Ziel und die Motivation des Projektmanagers und des Teams, die Implementierungsmethode, die Prinzipien des Projektmanagements, Managementansätze zur Bewertung des Fortschritts und der Ergebnisse des Projekts, Teampläne für das Leben nach dem Projekt, die Auswahl des zu lösenden Problems usw. .d.
Niemand kann alle Elemente und Zusammenhänge zuverlässig sehen, selbst der erfahrenste Business-Programmierer. Aber einige, ein bestimmter Teil wird von jedem gesehen - dem Projektmanager der Implementierung, dem Leiter des Unternehmens und allen umliegenden Kollegen.
Es ist jedoch der Business-Programmierer, der die genaueste Prognose liefert. Jeder schaut auf das Gleiche. Siehe das Objekt, siehe Thema, Projektplan, Ressourcen, Umgebung. Die Prognose ist jedoch grundlegend anders. Warum?
Die Antwort ist sehr einfach und sogar langweilig: Ein Business-Programmierer berücksichtigt
historische Informationen . Historische und statistische Informationen zum Verhalten ähnlicher Systeme.
Das Ergebnis des Change-Implementierungsprojekts besteht aus einer
Kombination von zwei Systemen - einem Objekt und einem Subjekt. Wenn die Systeme nicht richtig passen, ist das Ergebnis negativ.
Wenn ein neues Projekt von Änderungen geplant wird, sich aber die Systeme des Objekts und des Subjekts nicht wesentlich geändert haben, wird das Ergebnis höchstwahrscheinlich ähnlich sein. Dieselben Leute versuchen, dieselbe Methode in derselben Einheit zu implementieren.
Es gibt viele Beispiele. Wenn Sie sich die Geschichte der Einführung von Änderungen in Ihrem Unternehmen systematisch ansehen, werden Sie eine Bestätigung dieses Musters sehen.
Sie können auf der Straße nach Beispielen suchen, jetzt genau das richtige System - „Winter“ heißt. Winter + Stadt + diese, wie sie, welcher Schnee entfernt werden soll. Jahre vergehen und das Ergebnis ist ähnlich. Weil alle Systeme unverändert vorhanden sind. Oh ja, manchmal ist der Winter ohne Schnee - dann ist das Ergebnis sehr gut. Wem gehört es?
Der schwierigste Teil dieses Ansatzes besteht darin, festzustellen, ob
es Unterschiede in den Systemen gibt oder nicht. Dazu müssen Sie lernen, die Elemente und Beziehungen des Systems nach Wichtigkeit zu ordnen - um seine wichtigsten, systembildenden Elemente und Beziehungen hervorzuheben.
Es gibt kein einziges Rezept, es gibt viele Möglichkeiten. Es gibt zum Beispiel die bei McKinsey entwickelte 7S-Methode, die das System in 7 Teile zerlegt. Ich persönlich ziehe es vor, mich nicht einzuschränken, sonst können Sie sich etwas Neues ansehen.
Das Verstehen der Schlüsselelemente kann intuitiv erfolgen, aber Sie müssen sich selbst überprüfen, weil Die Qualität der Intuition hängt vom aktuellen Stand Ihrer Entwicklung als Business-Programmierer ab und kann Sie täuschen.
Durch Hervorheben von Schlüsselelementen können Sie eine Vorhersage schneller erstellen, ohne auf Details einzugehen und ohne das Rauschen zu untersuchen. Sie sehen nur, dass die Schlüsselelemente beider Systeme an Ort und Stelle bleiben, und Sie können sicher sein, dass das Ergebnis mit hoher Wahrscheinlichkeit wiederholt wird.
Je öfter Sie diese Übung machen, desto schneller entwickeln sich Ihre Fähigkeiten und desto genauer werden Ihre Vorhersagen.
In unserem Land gibt es einen so beliebten Ausdruck: „Sie wollten das Beste, aber es stellte sich wie immer heraus“. Jetzt, nachdem Sie gelesen haben, verstehen Sie, dass hier etwas fehlt. Es wäre korrekter "sie wollten das Beste, handelten wie immer, nun, das ist das Ergebnis ...".
Ich habe ein Beispiel für einen solchen Ansatz bei unserem Außenminister Sergej Lawrow gesehen. Auf einer Pressekonferenz nach einem Treffen mit US-Außenminister Rex Tillerson sagte Lawrow: „In Bezug auf die spezifischen Probleme Syriens, insbesondere von B. Assad, haben wir heute historische Exkursionen besprochen, und R. Tillerson sagte, er sei eine neue Person und ziehe es vor, nicht in die Geschichte einzutauchen und mit den heutigen Problemen umgehen. Die Welt ist jedoch so gestaltet, dass wir in der Gegenwart kaum Erfolg haben können, wenn wir nicht aus der Vergangenheit lernen. “
Dann listete Lawrow mehrere Beispiele auf - Kombinationen von Systemen des Objekts und des Subjekts mit demselben Ziel des Subjekts - die Einführung eines Demokratiemodells durch den Sturz des Diktators. NATO und Irak, NATO und Libyen. Und prognostizierte das Ergebnis einer Kombination aus NATO und Syrien.
Bisher scheint Lawrow recht zu haben.