Über einen Typen

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

Einige Jahre lang arbeitete ein Typ, wie viele von Ihnen, als Programmierer. Nur um sicherzugehen, ich schreibe es so: "Programmierer". Denn er war 1C-Spezialist, gearbeitet in einem Produktionsunternehmen.

Davor hat er verschiedene Berufe ausprobiert – 4 Jahre lang als Programmierer in einer Franchise, Projektleiter, er konnte 200 Stunden schließen und erhielt gleichzeitig eine prozentuale Beteiligung am Projekt für das Management und beschäftigte sich ein wenig mit dem Vertrieb. Er versuchte, selbst Produkte zu entwickeln, war Leiter der IT-Abteilung in einem großen Unternehmen mit 6.000 Mitarbeitern und testete verschiedene Möglichkeiten, seine ziemlich spezielle Berufung als 1C-Programmierer anzuwenden.

Aber all diese Positionen waren irgendwie ausweglos, vor allem hinsichtlich des Einkommens. Wir alle verdienten damals ungefähr dasselbe Geld und arbeiteten unter denselben Bedingungen.

Dieser Typ fragte sich, wie man mehr Geld verdienen kann, ohne im Vertrieb tätig zu sein und ohne ein eigenes Unternehmen zu gründen.

Er hielt sich für einen cleveren Kopf und wollte in dem Unternehmen, in dem er arbeitete, eine besondere Nische finden, die zuvor noch nicht besetzt war. Idealerweise sollte das Unternehmen selbst bereit sein, jemandem in dieser Nische ein gutes Gehalt zu zahlen, um keine Täuschungen oder Übertreibungen nötig zu haben. Es sollte objektiv sein: Jemand in dieser Position sollte ein hohes Einkommen erhalten. Ein Sonderling, um es kurz zu fassen.

Die Suche verlief nicht lange. In der Firma, in der dieser Typ arbeitete, gab es eine klare Nische, die man als „Ordnung in den Geschäftprozessen“ bezeichnen kann. Jede Firma hat eine Menge Probleme. Immer funktioniert etwas nicht, und es gibt niemanden, der kommt und die Geschäftprozesse verbessert. Er beschloss also, sein Glück als Spezialist zu versuchen, der dem Eigentümer helfen kann, seine Probleme in den Geschäftprozessen zu lösen.

Zu diesem Zeitpunkt arbeitete er seit einem halben Jahr in der Firma und verdiente ein marktübliches Gehalt. Zu verlieren hatte er nichts – zumal er eine ähnliche Stelle durchaus innerhalb einer Woche finden könnte. Insgesamt dachte dieser Typ, dass nichts Schlimmes passieren würde, selbst wenn es nicht klappen sollte und er gefeuert wird.

Er fasste den Mut und sprach den Eigentümer an. Er schlug vor, den problematischsten Prozess im Unternehmen zu verbessern. Zu diesem Zeitpunkt war es die Lagerbuchhaltung. Heute ist es allen, die in dieser Firma arbeiten, sogar peinlich, an die damaligen Probleme zu denken, denn die vierteljährlichen Bestandsaufnahmen zeigten Abweichungen von bis zu mehreren Prozent zwischen dem Buchhaltungssystem und den tatsächlichen Beständen. Sowohl hinsichtlich der Kosten als auch der Menge und der Anzahl der Positionen. Das war eine echte Herausforderung. Das Unternehmen hatte nur vier Mal im Jahr korrekte Bestände im Buchhaltungssystem – am Tag nach der Inventur. Und genau diesen Prozess brachte unser Kollege in Ordnung.

Der Mann einigte sich mit dem Eigentümer darauf, die Abweichungen aus der Bestandsaufnahme um die Hälfte zu reduzieren. Zudem hatte der Eigentümer nicht viel zu verlieren, da bereits verschiedene Mitarbeiter versucht hatten, die Situation zu korrigieren, und die Aufgabe insgesamt als nahezu unlösbar galt. Das weckte großes Interesse, denn wenn es ihm gelingt, wird er automatisch als jemand angesehen, der Ordnung schaffen und unlösbare Probleme lösen kann.

So stand er vor der Aufgabe, innerhalb eines Jahres die Abweichungen der Bestandsaufnahme um 50 % zu reduzieren. Zu Beginn des Projektes wusste er nicht, wie er das erreichen sollte, erkannte jedoch, dass die Lagerverwaltung eine einfache Angelegenheit ist, weshalb es ihm gelingen dürfte, etwas Nützliches zu erreichen. Zudem schien es nicht so schwierig, die Abweichungen von mehreren Prozentpunkten auf einen einstelligen Prozentsatz zu reduzieren. Alle, die im Bereich Beratung oder ähnlichen Tätigkeiten gearbeitet haben, wissen, dass die meisten Prozessprobleme durch relativ einfache Maßnahmen behoben werden können.

Von Januar bis Mai bereitete er sich vor, automatisierte einige Abläufe, überarbeitete den Geschäftsprozess der Lagerbuchhaltung, änderte die Arbeitsabläufe der Lageristen und Buchhalter und stellte das gesamte System um, ohne es jemandem zu zeigen oder davon zu erzählen. Im Mai gab er allen neue Anweisungen, und nach der ersten Inventur des Jahres begann ein neues Leben – die Arbeit nach seinen Regeln. Um die Ergebnisse zu beobachten, führte das Unternehmen in der Folge die Inventuren häufiger durch – alle zwei Monate. Bereits die ersten Ergebnisse waren positiv, und bis zum Ende des Jahres lagen die Abweichungen bei den Überprüfungsergebnissen bei weniger als einem Prozent.

Der Erfolg war enorm, aber man glaubte nicht an seine Beständigkeit. Der Junge selbst zweifelte daran, dass das Ergebnis Bestand haben würde, wenn er sich zurückzog und aufhörte, den Prozess zu beobachten. Dennoch war das Ergebnis vorhanden, und der Junge erhielt alles, was er mit dem Eigentümer vereinbart hatte. Nachdem einige Jahre vergangen waren, bestätigte sich die Beständigkeit des Ergebnisses – über mehrere Jahre lagen die Abweichungen konstant bei 1 %.

Er entschied sich dann, das Experiment zu wiederholen und schlug dem Eigentümer vor, einen weiteren problematischen Prozess – die Versorgung – zu optimieren. Es gab Engpässe, die es verhinderten, die von unseren Kunden gewünschten Mengen zu liefern. Wir einigten uns darauf, dass die Engpässe im Laufe eines Jahres halbiert werden würden, und er würde zusätzlich 10-15 Projekte im Zusammenhang mit 1C – zur Automatisierung verschiedener Geschäftsprozesse und anderem Kram – durchführen.

Im zweiten Jahr gelang es erneut, alles erfolgreich abzuschließen, die Engpässe wurden um mehr als das Doppelte verringert, alle IT-Projekte wurden erfolgreich abgeschlossen.

Da das Gehalt bereits alle Ansprüche dieses Typen für die kommenden zwei Jahre erfüllte, entschied er sich, ein wenig sesshaft zu werden, sich zu beruhigen und an einem gemütlichen, warmen Ort zu sitzen, den er sich selbst geschaffen hatte.

Was stellte es dar? Formal war er IT-Direktor. Aber wer er tatsächlich war, ist schwer zu verstehen. Was macht ein IT-Direktor eigentlich? Normalerweise verwaltet er die IT-Infrastruktur, leitet die Systemadministratoren, implementiert das ERP-System und nimmt an Sitzungen des Vorstandes teil.

Eine seiner wesentlichen Aufgaben war die Mitwirkung an Veränderungsprozessen, insbesondere die Initiierung und Entwicklung dieser Prozesse, das Finden und Vorschlagen von Lösungen, die Anwendung neuer Managementmethoden, die Begutachtung vorgeschlagener Änderungen, die Analyse der Effizienz anderer Funktionen und Abteilungen und letztlich die aktive Beteiligung an der strategischen Unternehmensentwicklung, einschließlich der eigenständigen Erstellung eines umfassenden strategischen Plans für das gesamte Unternehmen.

Ihm wurde ein Freiraum gewährt. Er konnte an jeder Besprechung teilnehmen, zu der er zuvor keinen Zugang hatte. Er saß dort mit einem Notizbuch, schrieb etwas auf oder hörte einfach zu. Selten sprach er. Dann begann er, auf seinem Telefon zu spielen — behauptete, damit arbeite das assoziative Gedächtnis besser.

Bei Besprechungen gab es selten nützliche Beiträge von ihm. Er ging, dachte nach, und dann kam eine E-Mail — entweder mit Kritik, einer Meinung, Vorschlägen oder einer Beschreibung von Lösungen, die er bereits umgesetzt hatte.

Aber meist organisierte er die Besprechungen selbst. Er identifizierte das Problem, entwickelte Lösungsvorschläge, bestimmte die Beteiligten und zog alle ins Besprechungszimmer. Und dort — wie er es konnte. Überzeugte, motivierte, bewies, diskutierte, errang Erfolge.

Inoffiziell galt er als die dritte Person im Unternehmen, nach dem Eigentümer und dem Geschäftsführer. Natürlich nervte er alle „Gesichter des Unternehmens“ enorm, beginnend mit Nummer 4. Besonders wegen seiner ausgefransten Jeans und bunten T-Shirts sowie der Zeit des Eigentümers.

Der Eigentümer widmete ihm jeden Tag 1 Stunde. Jeden Tag. Sie unterhielten sich, diskutierten Probleme, Lösungen, neue Geschäfte, Entwicklungsrichtungen, Kennzahlen und Effizienz, persönliche Entwicklung, Bücher und einfach — das Leben.

Aber dieser Kerl war seltsam. Es schien, als wäre alles in Ordnung, man sollte einfach glücklich sein und das Leben genießen. Doch das war nicht genug für ihn. Er entschied sich, zu reflektieren.

Ihm wurde interessant, warum es ihm gelungen ist, während es anderen nicht gelungen ist. Der Eigentümer drängte ihn ebenfalls: Er sagte, er wolle, dass auch andere Ordnung schaffen, denn es gibt viele Manager, die in der Regel mit dem operativen Management und der strategischen Planung beschäftigt sind, aber praktisch niemand kümmert sich um systematische Änderungen ihrer Prozesse. Möglicherweise steht in ihren Stellenbeschreibungen, dass sie ihre Prozesse beschleunigen und deren Effizienz erhöhen sollen, aber in der Realität kümmert sich niemand darum. Warum ist das so? Auch ihm wurde es interessant, und so ging er, 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 die Produkte besser als die japanischen zu machen. Doch es stellte sich heraus, dass sein Kollege nicht wusste, was Kontrollkarten von Shewhart sind, was statistisches Prozessmanagement bedeutet, und nur flüchtig vom Deming-Kreis in der Qualitätskontrolle gehört hatte. Na gut…

Er wandte sich an einen anderen stellvertretenden Direktor und schlug vor, Controlling einzuführen. Auch hier fand er jedoch keine Unterstützung. Später erfuhr er von Boundary Management und schlug allen stellvertretenden Direktoren vor, den systematischen Teil dieses Ansatzes zu implementieren, um die Prozesse zu verbessern. Doch trotz vieler Gespräche wollte sich niemand wirklich damit befassen; vielleicht war es ihnen uninteressant oder zu kompliziert. Letztlich schien keiner der Kollegen eine klare Vorstellung davon zu haben, worum es ging.

Insgesamt erzählte er alles, was er wusste und in der Firma anwendete. Doch keiner verstand ihn wirklich. Bis heute können sie nicht nachvollziehen, weshalb es beispielsweise gelang, die Bestandsaufnahme zu korrigieren, was Controlling und Boundary Management damit zu tun haben.

Schließlich wandte er sich an seine Programmierer – das Team bestand aus drei Personen. Er erklärte das Konzept des Boundary Managements, Controlling, Qualitätsmanagement, Agile und Scrum... Und zu seiner Überraschung verstanden sie alles und konnten sogar mit ihm darüber diskutieren, einschließlich technischer und methodischer Feinheiten. Sie erkannten, warum die Projekte in der Lagerhaltung und der Beschaffung erfolgreich waren. Da dämmerte es ihm: Tatsächlich sind es die Programmierer, die die Welt retten werden.

Die Programmierer, so erkannte er, sind die Einzigen, die in der Lage sind, sich detailliert mit den Geschäftsprozessen auseinanderzusetzen.

Warum gerade sie? Eine eindeutige Antwort fand er eigentlich nicht. Er formulierte lediglich einige stichpunktartige Andeutungen.

Erstens kennen Programmierer die spezifischen Geschäftsbereiche und verfügen über ein tiefergehendes Wissen als alle anderen im Unternehmen.

Darüber hinaus verstehen Programmierer wirklich, was ein Prozessalgorithmus ist. Das ist wichtig, weil Geschäftsprozesse Algorithmen sind, und die Elemente darin möglicherweise nicht einfach aufeinander abgestimmt sind. Zum Beispiel besteht im Beschaffungsprozess, an dem der Kollege gearbeitet hat, der erste Schritt darin, einen Jahresbeschaffungsplan aufzustellen, und der zweite ist der tägliche Einkauf. Diese Schritte sind direkt miteinander verbunden, was bedeutet, dass die Menschen gemäß diesem Algorithmus arbeiten sollten – einen Jahresbeschaffungsplan erstellen und gleichzeitig die Bestellungen ausführen. Der Jahresbeschaffungsplan wird einmal im Jahr erstellt, während Bestellungen bis zu 50 Mal am Tag eingehen. An diesem Punkt endet der Algorithmus, und man muss gemäß ihm arbeiten. Tatsächlich, so überlegte er, stellt das Wissen um Algorithmen für Programmierer einen Wettbewerbsvorteil dar, denn jeder andere Mensch, der nicht damit vertraut ist, versteht einfach nicht, wie ein Geschäftsprozess funktionieren sollte und wie man ihn darstellen kann.

Ein weiterer Vorteil von Programmierern, wie der Typ sagt, ist, dass sie ausreichend freie Zeit haben. Wir alle wissen, dass ein Programmer oft dreimal so lange für eine Aufgabe benötigt, wie eigentlich nötig wäre, und nur wenige bemerken das. Dies stellt wiederum einen Wettbewerbsvorteil dar, denn um einen Geschäftsprozess zu optimieren, braucht man viel freie Zeit – um zu denken, zu beobachten, zu lernen und zu experimentieren.

Die meisten Manager, so der Typ, haben diese freie Zeit nicht und sind sogar stolz darauf. Das bedeutet jedoch tatsächlich, dass man nicht effektiv sein kann, weil die Zeit für Effizienzsteigerung fehlt – ein Teufelskreis. In unserer Kultur ist es angesagt, beschäftigt zu sein, weshalb alles beim Alten bleibt. Für uns Programmierer ist das jedoch ein Vorteil. Wir können uns freinehmen und über alles nachdenken.

Programmierer, sagte er, können ein Informationssystem schnell ändern. Das ist nicht in allen Unternehmen anwendbar, aber überall, wo er gearbeitet hat, konnten Änderungen nach Belieben vorgenommen werden. Besonders, wenn sie niemandes Arbeit betreffen. Zum Beispiel könnte er ein System starten, das heimlich die Aktivitäten der Benutzer misst und diese Informationen dann verwendet – um die Effektivität der Buchhaltung zu analysieren und die Kosten für die Buchführung zu überwachen.

Und das Letzte, was ich aus seinen Worten in Erinnerung behalten habe – Programmierer haben Zugriff auf eine große Menge an Informationen, da sie administrative Zugriffsrechte im System besitzen. Daher können sie diese Informationen in ihrer Analyse nutzen. Niemand sonst in einem gewöhnlichen Werk hat solche Ressourcen.

Und dann ging er. Während der vorgeschriebenen zweiwöchigen Kündigungsfrist haben wir ihn gezwungen, seine Erfahrungen zu teilen, weil wir das, was er getan hat, fortführen wollten. Außerdem wurde seine Position vakant.

Über mehrere Tage hinweg setzten wir ihn auf einen Stuhl, schalteten die Kamera ein und zeichneten seine Monologe auf. Wir baten ihn, von allen durchgeführten Projekten, Methoden, Ansätzen, Erfolgen und Misserfolgen, Ursachen und Auswirkungen sowie den Portraits der Führungskräfte zu erzählen, usw. Wir schränkten ihn nicht besonders ein, da wir nicht wussten, was in seinem Kopf vor sich ging.

In seinen Monologen war natürlich hauptsächlich allerlei Unsinn und Gelächter - er war in ausgezeichneter Stimmung, da er aus dem Hinterland nach Petersburg aufbrach. Aber wo sollte man in Petersburg arbeiten? Bei Gazprom, natürlich.

Dennoch gelang es uns, einige nützliche Informationen aus seinen Monologen herauszuholen. Ich erzähle, was ich im Gedächtnis habe.

Hier sind also die Empfehlungen dieses Kerlchens. Für diejenigen, die versuchen möchten, Ordnung in den Geschäftsprozessen zu schaffen.

Für solche Aufgaben benötigt man vor allem ein gewisses Maß an "Abgebrühtheit". Man darf keine Angst haben, den Job zu verlieren, Risiken einzugehen oder Konflikte mit Kollegen zu haben. Ihm fiel das leicht, denn er hatte seinen Weg begonnen, als er erst sechs Monate im Unternehmen gearbeitet hatte und noch keine enge Beziehung zu jemandem aufgebaut hatte – und das hatte er auch nicht vor. Er wusste, dass Menschen kommen und gehen, und dass für ihn seine eigenen Ergebnisse und deren Bewertung durch den Geschäftsinhaber entscheidend waren. Wie seine Kollegen zu ihm standen, war ihm damals wenig wichtig.

Ein weiterer Punkt ist, dass man, um diese Arbeit effektiv zu erledigen, leider lernen muss. Aber nicht auf MBA-Kursen, nicht in Seminaren und nicht an Universitäten, sondern selbstständig. In seinem ersten Projekt, das ein Lager betraf, handelte er intuitiv, hatte keinerlei Wissen darüber, was "Qualitätsmanagement" ist.

Als er begann, Literatur zu lesen und Methoden zur Effizienzsteigerung zu erkunden, entdeckte er Technologien, die er bereits anwendete. Er hatte sie intuitiv genutzt, doch stellte sich heraus, dass es sich dabei nicht um seine eigene Idee handelte; vieles war bereits lange zuvor dokumentiert worden. Allerdings benötigte er viel mehr Zeit, als wenn er sofort das passende Buch gelesen hätte. Es ist wichtig zu verstehen, dass beim Erlernen einer bestimmten Methode keine einzige, selbst die fortschrittlichste, alle Probleme eines Geschäftsprozesses vollständig lösen kann.

Ein weiterer Punkt ist, dass je mehr Methoden Sie kennen, desto besser sind Sie darauf vorbereitet. Ein Beispiel dafür ist Miyamoto Musashi, einer der berühmtesten Schwertkämpfer des alten Japans und der Autor des Stils mit zwei Schwertern. Er lernte an einer Schule bei einem Meister, reiste dann durch Japan und kämpfte gegen verschiedene Gegner. Wenn er auf jemanden traf, der stärker war, pausierte seine Reise eine Weile, und Musashi ging in die Lehre. So eignete er sich im Laufe der Jahre Fähigkeiten verschiedener Praktiken verschiedener Meister an und entwickelte seine eigene Schule, indem er etwas Eigenes hinzufügte. Am Ende erlangte er ein einzigartiges Meisterschaftsniveau. Das Gleiche gilt hier.

Natürlich kann man wie Unternehmensberater handeln. Im Grunde sind das großartige Leute. Aber normalerweise kommen sie, um eine bestimmte Methode umzusetzen, und meistens nicht die, die das Unternehmen wirklich braucht. Auch wir hatten solche traurigen Situationen: Niemand weiß, wie man ein Problem löst, und niemand möchte darüber nachdenken, wie es zu lösen ist. Wir beginnen, entweder im Internet zu recherchieren oder einen Berater zu rufen und fragen ihn, was uns helfen kann. Der Berater denkt nach und sagt, dass wir die Theorie der Beschränkungen implementieren sollten. Wir zahlen ihm für die Empfehlung, investieren in die Umsetzung, aber das Ergebnis bleibt aus.

Warum passiert das? Weil der Berater gesagt hat, dass wir dieses System implementieren sollen, und alle ihm zugestimmt haben. Das ist zwar schön, aber eine Methode löst nicht alle Probleme selbst eines einzigen Geschäftsprozesses, insbesondere wenn unsere Ausgangsvoraussetzungen nicht mit denen übereinstimmen, die für die Implementierung der Methode erforderlich sind.

In der Praxis, die der Kollege empfiehlt, sollte man das Beste auswählen und das Beste umsetzen. Nicht die Methoden ganz übernehmen, sondern ihre wichtigsten Merkmale, Eigenschaften und Praktiken herausgreifen. Und das Wichtigste ist, das Wesentliche zu verstehen.

Nehmen wir beispielsweise Scrum oder Agile. In seinen Monologen wiederholte der Junge mehrfach, dass nicht alle die Essenz von Scrum vollständig verstehen. Auch er hatte das Buch von Jeff Sutherland gelesen, das einigen als "leichte Lektüre" erscheint. Für ihn war es jedoch eine tiefgründige Lektüre, denn eines der grundlegenden Prinzipien von Scrum ist das Qualitätsmanagement, was im Buch direkt angesprochen wird.

Dort wird über das Toyota-Produktionssystem gesprochen, über die Art und Weise, wie Jeff Sutherland Scrum in Japan vorstellte, wie es sich dort etabliert hat und wie es ihrer Philosophie nahekommt. Sutherland erläuterte die Bedeutung der Rolle des Scrum Masters und den Deming-Zyklus. Die Rolle des Scrum Masters besteht darin, den Prozess ständig zu beschleunigen. Alles andere, was es bei Scrum gibt – die schrittweise Abgabe, die Kundenzufriedenheit und die klare Aufgabenliste für den Sprintzeitraum – ist ebenfalls wichtig, aber all dies sollte immer schneller voranschreiten. Die Arbeitsgeschwindigkeit sollte in den Maßeinheiten, in denen sie gemessen wird, stetig zunehmen.

Vielleicht liegt es am Übersetzen, denn bei uns wurde das Buch als „Scrum – eine revolutionäre Projektmanagement-Methode“ übersetzt. Würde man den englischen Titel wörtlich übersetzen, hätte man „Scrum – doppelt so viel in der Hälfte der Zeit“, was schon im Titel auf Geschwindigkeit als zentrale Funktion des Scrums hinweist.

Als dieser Typ Scrum einführte, verdoppelte sich die Geschwindigkeit im ersten Monat ohne wesentliche Änderungen. Er fand Ansatzpunkte für Veränderungen und passte Scrum so an, dass es wesentlich schneller funktionierte. Das Einzige, was im Internet erwähnt wird, ist die Frage: „Wir haben die Geschwindigkeit verdoppelt, aber was machen wir nun mit dieser Geschwindigkeit?“ Doch das ist ein ganz anderes Thema…

Außerdem empfahl er persönlich mehrere Methoden, die er als grundlegend und essenziell bezeichnete.

Die erste Methode ist das Boundary Management (Grenzenmanagement).

Er wird in "Skolkowo" unterrichtet, andere Bücher und Materialien gibt es, laut dem jungen Mann, nicht. Er hatte einmal das Glück, einer Vorlesung eines Professors aus Harvard beizuwohnen, der über Boundary Management lehrt, sowie einige Artikel in der Harvard Business Review über die Arbeiten von Eric Trist zu lesen.

Boundary Management bedeutet, die Grenzen zu erkennen und mit ihnen zu arbeiten. Es gibt viele Grenzen, sie sind überall – zwischen Abteilungen, zwischen verschiedenen Arten von Aufgaben, zwischen Funktionen, zwischen operativer und analytischer Arbeit. Das Wissen über Boundary Management offenbart keine höheren Wahrheiten, ermöglicht es jedoch, die Realität aus einem anderen Blickwinkel – durch die Linse der Grenzen – zu sehen. Somit kann man diese verwalten – dort aufbauen, wo es notwendig ist, und dort entfernen, wo sie stören.

Doch am häufigsten sprach der junge Mann über Controlling. Es war fast eine Obsession für ihn.

Controlling, kurz gesagt, ist managementbasierte Steuerung anhand von Zahlen. Hier ist, wie er sagte, jeder Teil der Definition wichtig – sowohl "Steuerung" als auch "basierend auf" und "Zahlen".

Er sagte, dass wir bei allen drei Aspekten des Controllings schlecht abschneiden. Besonders wenn man berücksichtigt, dass sie eng miteinander sowie mit anderen Teilen des Geschäftssystems verbunden sind.

Das erste Problem ist die Qualität der Zahlen. Es gibt zu wenige, und sie sind von niedriger Qualität.

Ein erheblicher Teil der Zahlen stammt damals aus dem Informationssystem 1C. Die Qualität dieser Zahlen in 1C ist, wie er behauptete, unzureichend. Mindestens aufgrund der Möglichkeit, Daten rückwirkend zu ändern.

Es ist klar, dass die Entwickler von 1C daran keine Schuld tragen — sie beachten lediglich die Anforderungen des Marktes und die Mentalität der heimischen Buchhaltung. Aber für die Zwecke des Controllings sollten die Prinzipien der Datenverarbeitung in 1C im konkreten Unternehmen geändert werden.

Laut seinen Angaben durchlaufen die Daten aus 1C eine halbautomatische Bearbeitung, beispielsweise mit Excel. Eine solche Bearbeitung erhöht weder die Qualität der Daten noch die Schnelligkeit.

Letztendlich wird der endgültige Bericht von jemand anderem noch einmal überprüft, um sicherzustellen, dass keine fehlerhaften Zahlen an die Leitung übermittelt werden. So gelangen die Zahlen in schöner, geprüfter Form, aber sehr spät zum Empfänger. In der Regel nach Ende des Zeitraums (Monat, Woche usw.).

Hier ist alles ganz einfach, sagte er. Wenn die Zahlen für Januar Ihnen im Februar vorliegen, können Sie bereits nicht mehr auf die Aktivitäten im Januar reagieren, denn der Januar ist bereits vorbei.

Wenn die Zahlen auf der Buchhaltung basieren und das Unternehmen ganz gewöhnlich ist, mit vierteljährlicher Mehrwertsteuermeldung, erhält der Leiter relativ angemessene Zahlen nur einmal im Quartal.

Dann wird es klar. Erhalten Sie die Zahlen einmal im Monat – Sie können 12 Mal im Jahr basierend auf diesen Zahlen steuern (d.h. das Controlling durchführen). Bei vierteljährlicher Berichterstattung steuern Sie 4 Mal im Jahr. Außerdem gibt es einen Bonus – die Jahresberichterstattung. Einmal mehr die Kontrolle übernehmen.

Die restliche Zeit erfolgt die Steuerung in der Regel blind.

Wenn (und falls) die Zahlen schließlich auftauchen, stellt sich das zweite Problem – wie steuert man basierend auf Zahlen? Bei diesem Punkt seiner Überlegungen konnte ich nicht zustimmen.

Der Mann erklärte, dass das Auftauchen von Zahlen, die der Geschäftsführer zuvor nicht hatte, einen Wow-Effekt auslösen würde. Er würde die Zahlen betrachten und manipulieren, Personen ins Büro zitieren, Erklärungen und Untersuchungen fordern. Nachdem er mit den Zahlen gespielt, Analysen durchgeführt und drohend allen Mitarbeitern versprochen hat, dass „ich jetzt definitiv nicht von euch ablassen werde“, wird der Geschäftsführer sehr schnell wieder beruhigt sein und die Sache fallenlassen. Er wird aufhören, das Werkzeug zu benutzen. Doch die Probleme bleiben bestehen.

Das passiert, 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 anfangen soll. Was mitzu tun ist – weiß er, aber was er tun soll – nicht. Tun – das ist das, was oben beschrieben wurde (schimpfen, spielen). Machen – das ist der tägliche Geschäftsprozess.

Er behauptete, dass es ganz einfach sei: Die Zahl muss Teil des Geschäftsprozesses werden. Im Geschäftsprozess muss klar sein: wer, was und wann etwas tun muss, wenn die Zahl von der Norm abweicht (in allen Varianten – über die Grenzen, unter die Grenzen, Ausreißer, Trends, Nichterfüllung des Quantils usw.)

Und hier hat er das zentrale Dilemma angesprochen: Die Daten sind vorhanden, sie sollten Teil des Geschäftssystems werden, um die Effizienz des Managements zu steigern, doch… das geschieht nicht. Warum?

Weil der russische Manager seinem Konkurrenten keinen Teil seiner Macht überlassen wird.

Die Konkurrenten des russischen Managers – ein qualitativ hochwertiger und funktionierender Geschäftsprozess, durchdachte, gegenseitig vorteilhafte Anreize und die richtige Automatisierung – werden ihn leider arbeitslos machen.

Das klingt doch verrückt, oder? Besonders wenn es um die Manager geht. Gut, ich habe es erzählt, jetzt liegt es an Ihnen, zu entscheiden.

Ein wenig weniger, aber immer noch zu viel, meiner Meinung nach, sprach er über Scrum.

Er betonte unbedingt, dass Sie Scrum lesen und in der Praxis ausprobieren sollten. Wenn Sie sagen, Sie haben es gelesen, aber nicht ausprobiert – dann wissen Sie nichts. Es ist besser, ein Buch zu lesen, zum Beispiel von Sutherland, als Artikel und allerlei Leitfäden (was für ein Unsinn?) im Internet.

Scrum, so sagte er, wird nur durch Praxis erlernt, wobei die ausgeführten Arbeiten unbedingt gemessen werden müssen. Versuchen Sie persönlich die beiden wichtigsten Rollen – den Produktinhaber und den Scrum Master.

Es ist besonders wichtig, so der junge Mann, die Rolle des Scrum Masters praktisch zu erleben, wenn man die Anzahl der im Sprint abgeschlossenen Aufgaben erhöhen kann, ohne Ressourcen und Kosten des Sprints zu steigern.

Ein weiteres seiner Top-Themen war TOC (Theory of Constraints).

Laut dem jungen Mann handelt es sich dabei um grundlegende Prinzipien zur Effizienzsteigerung, die in fast jedem Bereich, in jedem Geschäftsprozess und in jedem Geschäftssystem anwendbar sind.

Als er erfuhr, dass wir mit TOC nicht vertraut sind, hörte er sofort auf zu erzählen. Er fügte nur hinzu, dass er uns nicht das Vergnügen nehmen möchte, die Bücher von Eliyahu Goldratt zu lesen. Eine ähnliche Empfehlung gab er wie beim Scrum — lesen und ausprobieren. Egal auf welcher Position Sie sich befinden oder welche Arbeit Sie leisten, es gibt immer Möglichkeiten, die Effizienz mit TOC-Methoden zu steigern.

Dann, als ihm offenbar die Methoden ausgingen, sagte er: Mischen Sie die Prinzipien, um anwendbare Lösungen für spezielle Situationen zu schaffen.

Das ist, sagt er, die wichtigste Empfehlung, der Schlüssel zum Erfolg. Verstehen Sie die Prinzipien, die Essenz, und schaffen Sie einzigartige anwendbare Lösungen — Geschäftsprozesse und Geschäftssysteme.

Dann versuchte er, ein Zitat zu erinnern, und schließlich musste er im Internet nachsehen. Es stellte sich heraus, dass das Zitat aus dem Artikel „Auf den Schultern von Giganten“ von Eliyahu Goldratt stammt:

„Es gibt einen Unterschied zwischen anwendungsbezogenen Lösungen und den fundamentalen Konzepten, auf denen diese Lösungen basieren. Konzepte sind allgemein, während anwendungsbezogene Lösungen eine Anpassung der Konzepte an eine spezifische Umgebung sind. Wie wir bereits gesehen haben, ist eine solche Anpassung nicht einfach und macht die Entwicklung bestimmter Elemente der Lösung notwendig. Wir müssen uns daran erinnern, dass eine anwendungsbezogene Lösung auf den zugrunde liegenden Annahmen (manchmal verborgenen) über die spezifische Umgebung basiert. Man sollte nicht erwarten, dass diese anwendungsbezogene Lösung in einer Umgebung funktioniert, für die die zugrunde liegenden Annahmen nicht zutreffen.“

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

Quelle: habr.com