Über einen Jungen

Die Geschichte ist echt, ich habe alles mit meinen eigenen Augen gesehen.

Ein paar Jahre lang arbeitete ein Junge, wie viele von euch, als Programmierer. Ich schreibe das mal so: "Programmierer". Denn er war 1C-Spezialist, auf Festanstellung in einem Produktionsunternehmen.

Davor hat er verschiedene Berufe ausprobiert – 4 Jahre lang als Programmierer in einer Fachfirma, Projektleiter, er konnte 200 Stunden gleichzeitig abrechnen und erhielt einen Prozentsatz vom Projekt, für die Leitung und war ein wenig im Verkauf tätig. Er versuchte, selbst Produkte zu entwickeln, war Leiter der IT-Abteilung in einem großen Unternehmen mit 6.000 Mitarbeitern, und suchte nach verschiedenen Wegen, seine Programmiererfahrung – als 1C-Spezialist – zu nutzen.

Aber all diese Positionen waren irgendwie ausweglos, vor allem in Bezug auf das Einkommen. Wir verdienten damals alle etwa gleiches Geld und arbeiteten unter den gleichen Bedingungen.

Dieser Junge begann sich zu fragen, wie man mehr Geld verdienen könnte, ohne im Verkauf tätig zu sein und ohne ein eigenes Geschäft zu gründen.

Er hielt sich für clever und beschloss, eine Nische in dem Unternehmen zu finden, in dem er arbeitete. Diese Nische sollte etwas Besonderes sein, niemand anderes war dort tätig. Und er wollte, dass das Unternehmen selbst von sich aus bereit war, einer Person in dieser Nische Geld zu zahlen, ohne dass jemand belogen oder etwas schöngeredet werden musste. Es sollte objektiv sein: Man müsste dafür viel Geld zahlen. Ein komischer Kerl, in einem Wort.

Die Suche dauerte nicht lange. In dem Unternehmen, in dem dieser Junge arbeitete, gab es eine vollkommen freie Nische, die man grob als "Ordnung in den Geschäftsprozessen schaffen" bezeichnet kann. Jedes Unternehmen hat eine Menge Probleme. Es funktioniert immer etwas nicht, und es gibt niemanden, der kommt und die Geschäftsprozesse korrigiert. Er beschloss also, sich als Spezialist zu versuchen, der dem Eigentümer hilft, seine Probleme in den Geschäftsprozessen zu lösen.

Zu diesem Zeitpunkt arbeitete er seit einem halben Jahr im Unternehmen und erhielt ein durchschnittliches Gehalt am Markt. Er hatte nichts zu verlieren – zumal er eine ähnliche Arbeit innerhalb einer Woche finden konnte. Insgesamt dachte dieser Junge, dass nichts Schlimmes passieren würde, falls es plötzlich nicht klappt und er entlassen wird.

Er fasste den Mut, um den Eigentümer aufzusuchen. Er schlug ihm vor, den problematischsten Prozess im Unternehmen zu verbessern. Zu diesem Zeitpunkt war das die Lagerbuchführung. Jetzt schämen sich alle, die in dieser Firma arbeiten, sogar, an die damaligen Probleme zu denken, aber die vierteljährlichen Inventuren zeigten Abweichungen von mehreren Prozent zwischen dem Buchhaltungssystem und den tatsächlichen Beständen. Sowohl bei den Kosten als auch bei der Menge und der Anzahl der Positionen. Das war eine Katastrophe. Das Unternehmen hatte in der Buchhaltung nur viermal im Jahr tatsächlich korrekte Bestände – am Tag nach der Inventur. Diesen Prozess brachte unser Kerl in Ordnung.

Der Kerl vereinbarte mit dem Eigentümer, dass er die Abweichungen aus den Inventurergebnissen halbieren sollte. Außerdem hatte der Eigentümer nicht viel zu verlieren, da bereits verschiedene Mitarbeiter versucht hatten, alles zu reparieren, und die Aufgabe insgesamt als nahezu unlösbar galt. Das befeuerte das Interesse enorm, denn wenn es gelingt, würde der Kerl automatisch zu einer Person, die Ordnung schaffen und unlösbare Aufgaben lösen kann.

So stand er vor der Aufgabe, innerhalb eines Jahres die Abweichungen aus den Inventurergebnissen um die Hälfte zu reduzieren. Zu Beginn des Projekts hatte er keine Vorstellung davon, wie er das erreichen sollte, aber er wusste, dass die Lagerbuchführung eine einfache Angelegenheit ist, und dass es ihm trotzdem gelingen würde, etwas Nützliches zu tun. Zumal es nicht so schwierig ist, die Abweichungen von mehreren Prozent auf ein paar Prozent zu reduzieren. Alle, die im Bereich Beratung oder ähnlicher Tätigkeiten gearbeitet haben, wissen, dass die meisten Probleme eines Prozesses mit relativ einfachen Maßnahmen behoben werden können.

Von Januar bis Mai bereitete er sich vor, automatisierte ein wenig, schrieb den Geschäftsprozess der Lagerbuchhaltung um, änderte die Arbeitsabläufe der Lagerarbeiter, Buchhalter und überarbeitete das gesamte System, ohne jemandem etwas zu zeigen oder zu erzählen. Im Mai verteilte er neue Anweisungen an alle, und nach der ersten Inventur des Jahres begann ein neues Leben – die Arbeit nach seinen Regeln. Um das Ergebnis zu beobachten, begann das Unternehmen, die Inventuren häufiger durchzuführen – alle zwei Monate. Bereits die ersten Ergebnisse waren positiv, und bis zum Ende des Jahres fielen die Abweichungen bei den Prüfungsergebnissen auf weniger als einen Prozent.

Der Erfolg war gewaltig, aber man glaubte nicht an seine Beständigkeit. Der junge Mann selbst zweifelte daran, dass das Ergebnis bestehen bleibt, wenn er sich zurückzieht und aufhört, den Prozess zu beobachten. Dennoch war das Ergebnis da, und der junge Mann erhielt alles, was er mit dem Eigentümer vereinbart hatte. Einige Jahre später wurde die Beständigkeit des Ergebnisses bestätigt – mehrere Jahre hielt die Abweichung bei etwa 1 %.

Da beschloss er, das Experiment zu wiederholen, und bat den Eigentümer, einen weiteren problematischen Prozess zu verbessern – die Beschaffung. Dort gab es Engpässe, die es nicht zuließen, die Mengen zu liefern, die unsere Kunden möchten. Man einigte sich darauf, dass die Engpässe im Laufe eines Jahres halbiert werden und der Typ noch 10-15 Projekte im Zusammenhang mit 1C durchführen wird – zur Automatisierung verschiedener Geschäftsprozesse und anderer solcher Dinge.

Im zweiten Jahr gelang es wieder erfolgreich, die Engpässe wurden um mehr als das Doppelte reduziert, alle IT-Projekte wurden erfolgreich abgeschlossen.

Da das Gehalt bereits alle Anforderungen des jungen Mannes mehr als erfüllt hatte, wurde er für etwa zwei Jahre ruhiger, wollte sich etwas stabilisieren und einen gemütlichen Platz einnehmen, den er sich selbst geschaffen hatte.

Was bedeutete das? Formal war er IT-Direktor. Aber wer er tatsächlich war, ist schwer zu verstehen. Denn womit beschäftigt sich ein IT-Direktor? In der Regel verwaltet er die IT-Infrastruktur, leitet die Sysadmins, führt ERP-Systeme ein und nimmt an den Sitzungen des Vorstands teil.

Bei diesem Typen war eine seiner Schlüsselaufgaben die Teilnahme an Veränderungsprozessen, vor allem die Generierung und Initiierung dieser Prozesse, das Suchen und Anbieten von Lösungen, die Anwendung neuer Managementmethoden, die Bewertung vorgeschlagener Änderungen, die Analyse der Effizienz anderer Funktionen und Abteilungen und schließlich die direkte Teilnahme an der strategischen Entwicklung des Unternehmens, bis hin zur eigenständigen Entwicklung des strategischen Plans für die gesamte Firma.

Ihm wurde ein Freibrief gegeben. Er konnte an jedes Meeting teilnehmen, zu dem er vorher keinen Zugang hatte. Er saß dort mit einem Notizbuch, hat etwas aufgeschrieben oder einfach nur zugehört. Er sprach selten. Dann begann er, auf dem Handy zu spielen – er behauptete, dass so die assoziative Gedächtnisleistung besser sei.

Bei Meetings gab er selten etwas Nützliches von sich. Er ging, dachte nach, dann kam eine E-Mail – entweder mit Kritik oder mit Meinungen, Vorschlägen oder einer Beschreibung von Lösungen, die er bereits umgesetzt hatte.

Aber meistens organisierte er die Meetings selbst. Er fand ein Problem, entwickelte Lösungsvorschläge, bestimmte die Interessierten und brachte sie alle in den Besprechungsraum. Und dort – wie er konnte. Überzeugte, motivierte, bewies, stritt, setzte sich durch.

Inoffiziell galt er als die dritte Person im Unternehmen, nach dem Eigentümer und dem Direktor. Natürlich nervte er alle „Gesicht der Firma“, beginnend mit Nummer 4, furchtbar. Besonders mit seinen zerrissenen Jeans und bunten T-Shirts, und noch – mit der Zeit, die der Eigentümer ihm widmete.

Der Eigentümer widmete ihm jeden Tag eine Stunde. Jeden Tag. Sie sprachen, diskutierten Probleme, Lösungen, neue Geschäftsmodelle, Entwicklungsrichtungen, Kennzahlen und Effizienz, persönliche Entwicklung, Bücher, und einfach – das Leben.

Aber dieser Kerl war seltsam. Eigentlich – sitz einfach da und freu dich, das Leben ist gelungen. Aber nein. Er beschloss, zu reflektieren.

Es wurde interessant für ihn: Warum hat er es geschafft, und die anderen nicht? Der Eigentümer drängte ihn ebenfalls: Er sagte, er möchte, dass auch die anderen es schaffen, Ordnung zu schaffen, denn es gibt viele Manager, die in der Regel mit operativem Management und strategischer Planung beschäftigt sind, aber praktisch niemand beschäftigt sich mit systemischen Veränderungen ihrer Prozesse. In ihrer Stellenbeschreibung mag vermerkt sein, dass sie ihren Prozess beschleunigen und dessen Effizienz steigern müssen, aber in der Realität kümmert sich niemand darum. Warum ist das so? Auch der Typ wurde neugierig, warum, und er ging, um mit all diesen Managern zu sprechen.

Er ging zum stellvertretenden Direktor für Qualität und schlug vor, Kontrollkarten von Shewhart einzuführen, um sicherzustellen, dass das Produkt besser als das japanische wäre. Aber es stellte sich heraus, dass der Kollege nicht wusste, was Kontrollkarten von Shewhart sind, was statistisches Prozessmanagement ist, und nur am Rande etwas über die Anwendung des Deming-Zyklus im Qualitätsmanagement gehört hatte. Na gut…

Er ging zu einem anderen stellvertretenden Direktor und schlug vor, Controlling einzuführen. Aber auch hier fand er keine Unterstützung. Kurz darauf erfuhr er von Boundary Management und bot allen stellvertretenden Direktoren an, den systematischen Teil dieser Methodik einzuführen, um die Prozesse zu verbessern. Aber so oft er auch sprach, wollte niemand wirklich wissen, worum es ging. Vielleicht war es ihnen uninteressant oder zu kompliziert. Aber in der Tat kam niemand dahinter.

Er erzählte also alles, was er wusste und in der Firma angewendet hatte. Aber niemand verstand ihn wirklich. Bis heute ist ihnen unverständlich, warum zum Beispiel alles im Lagerbestand korrigiert werden konnte, und was Controlling und Boundary Management damit zu tun haben.

Zuletzt kam er zu seinen Programmierern – im Team waren es 3 Personen. Er sprach über Boundary Management, über Controlling, über Qualitätsmanagement, über Agile und Scrum… Und zu seiner Überraschung verstanden sie alles und konnten sogar irgendwie mit ihm diskutieren, einschließlich der technischen und methodischen Feinheiten. Sie erkannten, warum die Projekte im Lager und in der Beschaffung erfolgreich waren. Und da hatte der Typ einen Geistesblitz: Tatsächlich werden die Programmierer die Welt retten.

Die Programmierer, verstand er – die einzigen, die in der Lage sein würden, sich angemessen und mit der nötigen Detailgenauigkeit mit den Geschäftsprozessen auseinanderzusetzen.

Warum gerade sie? Tatsächlich fand er darauf keine eindeutige Antwort. Er formulierte nur einige stichpunktartige Andeutungen.

Erstens kennen Programmierer die Fachgebiete des Geschäfts, und zwar kennen sie sie besser als alle anderen Menschen im Unternehmen.

Darüber hinaus verstehen Programmierer wirklich, was ein Prozessalgorithmus ist. Das ist wichtig, weil Geschäftsprozesse Algorithmen sind und die Elemente darin banal nicht abgestimmt sein können. Zum Beispiel im Beschaffungsprozess, an dem der Typ arbeitete, ist der erste Schritt die Erstellung eines Jahres-Einkaufsplans und der zweite die tägliche Bestellung. Diese Schritte sind direkt verbunden, das heißt, es wird angenommen, dass die Leute nach diesem Algorithmus arbeiten sollten – den Jahres-Einkaufsplan zu erstellen und gleichzeitig die Bestellung auszuführen. Der Jahres-Einkaufsplan wird einmal im Jahr erstellt, während die Bestellung bis zu 50 Mal am Tag eingeht. An diesem Algorithmus endet es, und man muss danach arbeiten. Tatsächlich dachte er, für Programmierer ist das Wissen um Algorithmen ein Wettbewerbsvorteil, weil jeder andere, der damit nicht vertraut ist, einfach nicht versteht, wie der Geschäftsprozess funktionieren sollte und wie man das darstellen kann.

Ein weiterer Vorteil von Programmierern, so sagte der Typ, ist, dass sie genügend freie Zeit haben. Wir alle verstehen, wie ein Programmierer dreimal so viel Zeit für eine Aufgabe aufwenden kann, als sie tatsächlich benötigt, und kaum jemand bemerkt es. Das ist wieder ein Wettbewerbsvorteil, denn um einen Geschäftsprozess in Ordnung zu bringen, muss man viel freie Zeit haben – nachdenken, beobachten, lernen und ausprobieren.

Die meisten Manager, so sagte der Typ, haben diese freie Zeit nicht und sind stolz darauf. Obwohl das faktisch bedeutet, dass eine Person nicht effizient sein kann, weil sie keine Zeit hat, um die Effizienz zu steigern – ein Teufelskreis. In unserer Kultur ist es schick, beschäftigt zu sein, deshalb bleibt alles beim Alten. Für uns Programmierer ist das ein Vorteil. Wir können freie Zeit finden und über alles nachdenken.

Programmierer, erzählte er, können Informationssysteme schnell ändern. Das gilt nicht für alle Unternehmen, aber überall, wo er gearbeitet hat, konnte man beliebige Anpassungen vornehmen, die man für angemessen hielt. Besonders, wenn sie nicht die Arbeit anderer betreffen. Zum Beispiel konnte er ein System starten, das heimlich die Handlungen der Benutzer überwacht und diese Informationen dann zur Analyse der Effizienz der Buchhaltung sowie zur Nachverfolgung der Kosten der Buchführung verwendet.

Und das Letzte, woran ich mich aus seinen Worten erinnere – Programmierer haben Zugang zu einer großen Menge an Informationen, da sie über Administratorzugang zum System verfügen. Daher können sie diese Informationen in ihrer Analyse nutzen. Niemand sonst in einer normalen Fabrik hat solche Ressourcen.

Dann ging er. Während der vorgesehenen zweiwöchigen Kündigungsfrist haben wir ihn gezwungen, sein Wissen zu teilen, weil wir das, womit er beschäftigt war, fortsetzen wollten. Außerdem wurde seine Position vakant.

In den folgenden Tagen setzten wir ihn auf einen Stuhl, schalteten die Kamera ein und zeichneten seine Monologe auf. Wir baten ihn, über alle abgeschlossenen Projekte, Methoden, Ansätze, Erfolge und Misserfolge, Ursachen und Folgen, Portraits von Führungskräften usw. zu erzählen. Wir setzten ihm dabei keine besonderen Grenzen, da wir nicht wussten, was in seinem Kopf vorging.

In den Monologen war natürlich hauptsächlich viel Unsinn und Spaß – er war in guter Stimmung, da er aus der Provinz nach Petersburg zog. Und wo sollte man in Petersburg arbeiten? Natürlich bei Gazprom.

Aber wir konnten einige nützliche Informationen aus seinen Monologen herausziehen. Ich werde erzählen, was ich in Erinnerung habe.

So, die Empfehlungen des Typen. An diejenigen, die versuchen möchten, Ordnung in den Geschäftsprozessen zu schaffen.

Um sich mit einer solchen Arbeit zu beschäftigen, muss man erstens ein gewisses Maß an 'Kälte' haben. Man darf keine Angst haben, seinen Arbeitsplatz zu verlieren, keine Angst haben, Risiken einzugehen und keine Angst vor Konflikten mit Kollegen haben. Ihm fiel das leicht, weil er seinen Weg begann, als er nur ein halbes Jahr im Unternehmen gearbeitet hatte und nicht die Möglichkeit hatte, mit jemandem Kontakt aufzunehmen, und auch nicht vorhatte, dies zu tun. Er verstand, dass Menschen kommen und gehen, und für ihn zählten nur seine eigenen Ergebnisse und deren Bewertung durch den Geschäftsinhaber. Ob die Kollegen gut oder schlecht über ihn denken – das interessierte ihn damals wenig.

Der zweite Punkt ist, dass man leider, um effektiv in dieser Arbeit zu sein, lernen muss. Aber man lernt nicht an einer MBA-Programm, nicht in Kursen, nicht an Universitäten, sondern selbstständig. Zum Beispiel in meinem ersten Projekt, das sich mit einem Lager beschäftigte, handelte ich intuitiv, hatte keine Ahnung, wusste nur, was "Qualitätsmanagement" ist.

Als er anfing, die Literatur zu lesen, welche Methoden zur Effizienzsteigerung es gibt, entdeckte er die Technologien, die er angewendet hatte. Er wandte sie intuitiv an, aber es stellte sich heraus, dass es nicht seine Erfindung war, sondern alles schon lange geschrieben wurde. Doch er verschwendete viel Zeit, viel mehr, als wenn er gleich das richtige Buch gelesen hätte. Hier ist nur wichtig zu verstehen, dass, wenn man eine spezifische Methode studiert, keine davon, selbst die fortschrittlichste, alle Probleme der Geschäftsprozesse vollständig lösen kann.

Der zweite Punkt ist, dass je mehr Methoden man kennt, desto besser ist es. Zum Beispiel lebte im alten Japan Miyamoto Musashi – einer der bekanntesten Schwertkämpfer, der einen Stil mit zwei Schwertern entwickelte. Er lernte in einer Schule bei einem Meister, reiste dann durch Japan und kämpfte gegen verschiedene Leute. Wenn jemand stärker war, stoppte das Reisen für eine Weile, und Musashi wurde Schüler. In der Folge erwarb er in einigen Jahren Fähigkeiten verschiedener Praktiken unterschiedlicher Meister und formte seine eigene Schule, indem er etwas Eigenes hinzufügte. Am Ende entwickelte er ein einzigartiges Meisterschaft. Hier ist es das gleiche.

Man kann natürlich wie Unternehmensberater handeln. Im Allgemeinen sind sie großartige Leute. Aber in der Regel kommen sie, um eine bestimmte Methode anzuwenden, und implementieren nicht die Methode, die das Unternehmen benötigt. Auch wir hatten solche traurigen Situationen: Niemand weiß, wie man das Problem löst, und niemand will darüber nachdenken, wie es zu lösen ist. Wir fangen an, entweder im Internet zu suchen oder einen Berater zu rufen, und fragen ihn, was uns helfen kann. Der Berater denkt nach und sagt, dass wir die Theorie der Einschränkungen einführen sollten. Wir zahlen ihm für die Empfehlung, investieren in die Implementierung, aber das Ergebnis ist null.

Warum passiert das? Weil der Berater gesagt hat, dass wir ein bestimmtes System implementieren sollen, und alle ihm zugestimmt haben. Das ist großartig, aber eine Methode löst nicht alle Probleme auch nur eines Geschäftsprozesses, insbesondere wenn die Ausgangsvoraussetzungen – unsere und die, die für die Implementierung der Methode erforderlich sind – nicht übereinstimmen.

In der Praxis, die der Junge empfiehlt, sollten wir das Beste nehmen und das Beste implementieren. Nicht die Methoden vollständig übernehmen, sondern ihre Schlüsselfunktionen, Tricks und Praktiken übernehmen. Und das Wichtigste – man muss den Kern verstehen.

Nehmen wir, sagte er, zum Beispiel Scrum oder Agile. In seinen Monologen hat der Junge mehrmals wiederholt, dass nicht jeder den Kern von Scrum ganz versteht. Er hat auch das Buch von Jeff Sutherland gelesen, das einigen als „leichte Lektüre“ erscheint. Er empfand es als tiefgründige Lektüre, denn eines der grundlegenden Prinzipien von Scrum ist das Qualitätsmanagement, das in dem Buch direkt angesprochen wird.

Dort wird über das Toyota Production System geschrieben, darüber, wie Jeff Sutherland Scrum in Japan vorstellte, wie gut es sich dort etabliert hat und wie nah es ihrer Philosophie war. Und Sutherland sprach über die Bedeutung der Rolle des Scrum Masters und über den Deming-Kreis. Die Rolle des Scrum Masters besteht darin, den Prozess kontinuierlich zu beschleunigen. Alles andere, was es in Scrum gibt – die schrittweise Abgabe, die Kundenzufriedenheit, eine klare Liste der Arbeiten für den Sprint – ist auch wichtig, aber das alles sollte immer schneller voranschreiten. Die Arbeitsgeschwindigkeit sollte ständig in den Einheiten wachsen, in denen sie gemessen wird.

Vielleicht liegt es daran, dass das Buch, das wir haben, als „Scrum – eine revolutionäre Methode zur Projektverwaltung“ übersetzt wurde. Übersetzt man den englischen Titel wörtlich, würde es heißen: „Scrum – doppelt so viel in halb so viel Zeit“, das heißt, selbst im Titel wird auf Geschwindigkeit als Schlüsselmerkmal von Scrum verwiesen.

Als dieser Junge Scrum einführte, verdoppelte sich die Geschwindigkeit in den ersten Monaten ohne besondere Änderungen. Er fand Ansatzpunkte für Veränderungen, modifizierte das Scrum für sich selbst, damit es viel schneller funktionierte. Das Einzige, was, wie im Internet geschrieben wird, bleibt, ist die Frage: „Wir haben die Geschwindigkeit verdoppelt, nun bleibt die Frage, was wir mit dieser Geschwindigkeit anfangen?“ Aber das ist bereits ein ganz anderes Gebiet...

Außerdem empfahl er persönlich mehrere Methoden. Er nannte sie fundamental und grundlegend.

Die erste – Boundary Management.

Es wird am „Skolkowo“ unterrichtet, andere Bücher und Materialien gibt es angeblich nicht. Er hatte das Glück, an einer Vorlesung eines Professors aus Harvard teilzunehmen, der Boundary Management lehrt, und einige Artikel in der Harvard Business Review über die Arbeiten von Erik Trista zu lesen.

Boundary Management bedeutet, dass man in der Lage sein muss, Grenzen zu erkennen und mit ihnen zu arbeiten. Grenzen gibt es überall – zwischen Abteilungen, zwischen verschiedenen Arten von Arbeiten, zwischen Funktionen, zwischen operativer und analytischer Arbeit. Das Wissen über Boundary Management offenbart keine höheren Wahrheiten, ermöglicht jedoch, die Realität aus einer etwas anderen Perspektive zu sehen – durch die Linse der Grenzen. Und entsprechend kann man mit ihnen umgehen – dort errichten, wo es nötig ist, und dort abbauen, wo sie stören.

Aber viel und oft sprach der Junge über Controlling. Er hatte irgendwie eine Obsession für dieses Thema.

Controlling, kurz gesagt, ist Management auf der Basis von Zahlen. Dabei ist, wie er sagte, jeder Teil der Definition wichtig – sowohl "Management", als auch "auf der Basis" und "Zahlen".

Bei uns, so sagte er, steht es schlecht um alle drei Bestandteile des Controllings. Besonders wenn man bedenkt, dass sie eng miteinander sowie mit anderen Teilen des Geschäftssystems verbunden sind.

Das erste, was schlecht ist – die Zahlen. Es gibt zu wenige und sie sind von schlechter Qualität.

Einen großen Teil der Zahlen haben wir damals aus dem Informationssystem 1C entnommen. So war die Qualität der Zahlen in 1C, wie er behauptete, unzureichend. Mindestens wegen der Möglichkeit, Daten nachträglich zu verändern.

Es ist klar, dass die Entwickler von 1C keine Schuld daran tragen – sie berücksichtigen nur die Anforderungen des Marktes und die Mentalität der einheimischen Buchführung. Aber für die Zwecke des Controllings wären die Arbeitsprinzipien von 1C mit Daten besser an das konkrete Unternehmen anzupassen.

Danach durchlaufen die Zahlen aus 1C, so seine Worte, eine halbautomatische Verarbeitung, zum Beispiel mit Excel. Solch eine Verarbeitung fügt den Daten weder Qualität noch Schnelligkeit hinzu.

Schließlich wird der endgültige Bericht noch von jemandem überprüft, um nicht versehentlich Zahlen mit Fehlern an den Leiter weiterzugeben. Infolgedessen kommen die Zahlen beim Empfänger schön, geprüft, aber sehr spät an. Gewöhnlich – nach Ende des Zeitraums (Monats, Woche usw.).

Und hier, so sagte er, ist alles sehr einfach. Wenn die Zahlen für Januar im Februar bei Ihnen ankommen, können Sie die Aktivitäten im Januar nicht mehr steuern. Denn der Januar ist bereits vorbei.

Wenn die Zahlen auf der Buchhaltung basieren und das Unternehmen ganz gewöhnlich ist, mit vierteljährlichen Mehrwertsteuererklärungen, erhält der Geschäftsführer relativ angemessene Zahlen einmal im Quartal.

Danach ist es klar. Wenn Sie die Zahlen einmal im Monat erhalten, haben Sie die Möglichkeit, anhand der Zahlen zu steuern (d.h. Controlling durchzuführen) 12 Mal im Jahr. Wenn Sie Quartalsberichte praktizieren, steuern Sie 4 Mal im Jahr. Plus Bonus – Jahresbericht. Noch einmal die Möglichkeit, das Steuer in die Hand zu nehmen.

Die restliche Zeit wird das Management in der Regel blind durchgeführt.

Wenn (und falls) die Zahlen tatsächlich erscheinen, tritt das zweite Problem in Kraft – wie man auf der Grundlage von Zahlen steuert? Mit diesem Punkt seiner Überlegungen konnte ich mich einfach nicht anfreunden.

Der Typ behauptete, dass, wenn der Geschäftsführer vorher keine Zahlen hatte, deren Auftauchen einen Wow-Effekt auslösen würde. Er wird die Zahlen betrachten und drehen, Menschen vorladen, Erklärungen und Ermittlungen fordern. Nachdem er mit den Zahlen gespielt hat, Analysen durchgeführt hat und den Mitarbeitern drohend versprochen hat: 'Jetzt lasse ich euch nicht mehr in Ruhe', wird der Geschäftsführer sehr schnell wieder beruhigt sein und diese Angelegenheit fallen lassen. Er wird aufhören, das Werkzeug zu nutzen. Die Probleme bleiben jedoch bestehen.

So passiert es, sagte er, aufgrund unzureichender Kompetenzen des Geschäftsführers. Vor allem im Controlling. Der Geschäftsführer weiß einfach nicht, was er mit diesen Zahlen machen soll. Was cer tun sollte, weiß er, was er machen sollte – nicht. Machen – das ist es, was oben beschrieben wurde (beschweren, spielen). Tun – das ist der tägliche Geschäftsprozess.

Er behauptete, dass alles ganz einfach sei: Die Zahl muss Teil des Geschäftsprozesses werden. Im Geschäftsprozess sollte klar sein: wer, was und wann bei Abweichungen der Zahl von der Norm handeln muss (alle Varianten – oberhalb der Grenze, unterhalb der Grenze, Überschreitung des Korridors, Trendvorhandensein, Nichterfüllung des Quantils usw.)

Und hier skizzierte er das zentrale Dilemma: Die Zahl ist da, sie muss Teil des Geschäftssystems werden, um die Effizienz des Managements zu steigern, aber… das passiert nicht. Warum?

Weil der russische Geschäftsführer seinem Konkurrenten kein Stück seiner Macht überlassen wird.

Die Konkurrenten des russischen Geschäftsführers – hochwertige und funktionierende Geschäftsprozesse, durchdachte gegenseitige Motivation und richtige Automatisierung – werden ihn leider ohne Arbeit lassen.

Was für ein Unsinn, oder? Besonders in Bezug auf die Führungskräfte. Egal, ich habe es erzählt, jetzt entscheidet selbst.

Etwas weniger, aber trotzdem viel zu viel, wie ich finde, hat er über Scrum gesprochen.

Er hat unbedingt gesagt, dass ihr Scrum lesen und in der Praxis ausprobieren sollt. Wenn ihr, sagt er, gelesen habt, aber es nicht ausprobiert habt – dann wisst ihr nichts. Es ist besser, ein Buch zu lesen, zum Beispiel von Sutherland, anstatt Artikel und irgendwelche Guides (was für ein Quatsch?) im Internet.

Scrum, sagte er, wird nur durch Praxis verstanden, und mit den erforderlichen Messungen der erledigten Arbeitsvolumen. Probiert zwei der wichtigsten Rollen selbst aus – den Product Owner und den Scrum Master.

Besonders wichtig ist es, so der Typ, die Rolle des Scrum Masters praktisch zu erfahren, wenn ihr den Umfang der während eines Sprints abgeschlossenen Aufgaben erhöhen könnt, ohne Ressourcen und Kosten des Sprints zu erhöhen.

Und ein weiteres Top-Thema von ihm war die TOC (Theorie der Einschränkungen von Systemen).

Das sind, so der Typ, grundlegende Prinzipien zur Effizienzsteigerung, die in nahezu jedem Bereich, in jedem Geschäftsprozess und in jedem Geschäftssystem im Allgemeinen angewendet werden können.

Als er erfuhr, dass wir mit TOC nicht vertraut sind, hörte er auf zu erzählen. Er fügte nur hinzu, dass er uns nicht das Vergnügen nehmen würde, die Bücher von Eliyahu Goldratt zu lesen. Er gab eine ähnliche Empfehlung wie für Scrum – lest und probiert es aus. Egal, in welcher Position ihr euch befindet, welche Arbeit ihr verrichtet, es gibt Möglichkeiten zur Effizienzsteigerung mithilfe von TOC.

Danach schien ihm der Fundus an Methoden erschöpft, und er sagte: mischt die Prinzipien, um anwendungsorientierte Lösungen in konkreten Situationen zu schaffen.

Das, sagt er, ist die Hauptempfehlung, der Schlüssel zum Erfolg. Versteht die Prinzipien, den Kern, und kreiert einzigartige anwendungsorientierte Lösungen – Geschäftsprozesse und Geschäftssysteme.

Dann versuchte er, ein Zitat zu erinnern, am Ende musste er ins Internet gehen. Es stellte sich heraus, dass das Zitat aus dem Artikel „Auf den Schultern von Riesen“ von Eliyahu Goldratt stammt:

„Es gibt einen Unterschied zwischen praktischen Lösungen (Anwendungen) und den fundamentalen Konzepten, auf denen diese Lösungen basieren. Konzepte sind allgemein, praktische Lösungen sind die Anpassung von Konzepten an eine spezifische Umgebung. Wie wir bereits gesehen haben, ist eine solche Anpassung nicht einfach und erfordert die Entwicklung bestimmter Elemente der Lösung. Wir müssen uns daran erinnern: Eine praktische Lösung basiert auf den grundlegenden Annahmen (manchmal - versteckt) über die spezifische Umgebung. Man sollte nicht erwarten, dass diese praktische Lösung in einer Umgebung funktioniert, für die die grundlegenden Annahmen nicht zutreffen.“

Er sagte, dass die Arbeit eines Programmierers und eines „Optimierers von Geschäftsprozessen“ sehr ähnlich sei. Und er ging.

Quelle: habr.com