Zug ist ökonomischer

Dieses Arrangement fand sich neulich auf dem Wohnzimmertisch meiner Freundin. Noch nicht weihnachtlich – es ist ja erst Mitte November – aber trotzdem hübsch und Gemütlichkeit verbreitend so mit den Kerzen und ein bisschen Obst.

Nur leider war es mir im Weg. Ich wollte an dem Tisch mit meinem ebenfalls hübschen und vor allem ungemein praktischen neuen MacBook Pro nämlich arbeiten. Also musste es weichen.

Da ich faul war und ein schnelles Ergebnis suchte, habe ich es nicht abräumen wollen. Also schob ich es von mir weg.

Und dabei wurde mir klar, wie schädlich Druck (push) ist.

Sehen Sie: Das ganze schöne Arrangement verformt sich. Es leistet dem Druck Widerstand. Deshalb werfen sich die Servietten auf. Die Kerzenständer sind träge und weichen nur widerwillig. Obst und Kerzenständer kollidieren, Zwischenräume – Puffer – schrumpfen.

Erschrocken hielt ich in meinem Schub inne. Das sah nicht schön aus. Ich wollte ja das Arrangement nicht kaputt machen, sondern nur auf die Schnelle etwas Platz machen.

Genau: Auf die Schnelle. Wie es in Projekten, im Geschäftsleben und auch sonst immer wieder sein soll. Auf die Schnelle sollen Ergebnisse erzielt werden. Und das Mittel der Wahl ist dann… Druck. Der liegt immer irgendwie auf der Hand. Der lässt sich schnell aufbauen. Man muss ja nur etwas anschieben, also Forderungen aufstellen – und schon wird das Ergebnis hergestellt. Oder?

Doch, so funktioniert das. Ich habe ja auch mein Ergebnis bekommen: Platz für das MacBook. Das ging einfach und schnell. Leider hat sich dabei das Arrangement unschön verformt. Mein Ergebnis habe ich mit Druck also auf Kosten eines Systems hergestellt.

Das wollte ich nicht. Also habe ich es noch einmal probiert. Jetzt mit Zug (pull).

Wie anders das Verhalten des Arrangements da war! Erstaunlich. Das Ergebnis – Platz fürs MacBook – war dasselbe. Diesmal jedoch mit viel weniger Kollateralschäden. Das Arrangement blieb nahezu vollständig in Form.

Ein Paar “Zuglinien” entstanden in den Servietten, ein paar Positionsveränderungen gab es bei Obst und Kerzenständern. Alles in allem waren das jedoch vernachlässigbare Verformungen. Ich hatte eher den Eindruck, dass sich das Arrangement ausgerichtet hatte. Es folgte willigem dem Zug in Richtung auf ein durch ihn repräsentiertes Ziel (die Tischkante).

Außerdem war der Kraftaufwand für den Zug geringer als für den Druck.

In Summe war der Effekt mit pull also deutlich besser als mit push. Platz habe ich mit beiden Maßnahmen geschaffen – doch beim Zug gab es weniger Nebeneffekte, weil “das System” weniger Widerstand geleistet hat.

Zug scheint mir also ökonomischer, ja, nachhaltiger. Denn wenn ich nicht nur auf den Platz schaue, den ich schaffen wollte, sondern auch auf das Arrangement, dann ist ja deutlich, dass für dessen Zweck “hübsch Aussehen” mit Druck mehr Aufwand betrieben werden muss. Nach Druck muss ich das Arrangement wieder herstellen. Mehrfaches Platzschaffen würde mehrfache erhebliche Eingriffe ins Arrangement bedeuten. Anders mit Zug. Da bleibt das Arrangement nahezu unverändert. Nicht nur kostet Zug weniger Kraft, auch muss ich hinterher viel weniger Aufwand für eine Wiederherstellung des Arrangements treiben. Das kann sich nur vorteilhaft auf die Haltbarkeit aller beteiligten Materialien auswirken.

Das – so glaube ich – ist nicht anders als bei Organisationen (Unternehmen, Teams). Da lässt sich mit Druck natürlich Veränderung erzielen. Vielleicht sogar schneller als mit Zug. Denn auch in meinem Fall musste ich für den Zug aufstehen und um den Tisch gehen.

Aber das schnelle Ergebnis scheint mir oft Schäden zu verursachen. Der Druck führt zu Verformungen im gedrückten System. Wenn man mit dem noch weitere Ergebnisse erzielen will, dann kostet es Aufwand, es wieder herzustellen. Das geht auch nicht verlustfrei.

Anders beim Zug. Die Organisation richtet sich auf das Ziel aus. Verformungen sind minimal oder gar dem Ergebnis dienlich. Weniger Wiederherstellungsaufwand ist zu treiben. Die Organisation ist schneller bereit, ein nächstes Ergebnis herzustellen.

eBook-Veröffentlichung im Fluss

Bücher veröffentlichen ist heute ganz einfach. Eigentlich. Denn ein bisschen Tüfteln muss noch sein, um den Prozess flüssig hinzubekommen. Aber ich denke, jetzt habe ich das im Griff. Ein Gespräch mit einem Lektor eines deutsches Fachbuchverlags neulich auf einer Konferenz hatte mich motiviert, es nochmal zu versuchen. Wir hatten darüber nachgedacht, was gerade Fachverlage tun können, um ihre Berechtigung in Zeiten des self publishing zu behalten.

Dazu fiel mir vor allem ein, dass sie Autoren helfen könnten, möglichst schnell und einfach Schreibmotivation in ein Buch umzusetzen. Der heutige Prozess mit Exposé, das vom Verlag erstmal abgesegnet werden muss, über Manuskript, das in Wochen und Monate verfeinert wird, bis zur Druckfahne und dann schließlich einem Druck… der ist nämlich sehr lang und weilig. Der schreckt so manchen would-be-Autor ab und lässt Buchprojekte trotz aller Verträge immer wieder auch unterwegs verrecken.

Klar, in dem Prozess entsteht auch Qualität, wenn er denn überhaupt begonnen und bis zum Ende durchlaufen wird. Aber ist diese Qualität wirklich immer den Aufwand wert? Bei so manchem Fachbuch bin ich da doch im Zweifel. Viele Lektorate sind fachlich überfordert und/oder überlastet, so dass das Resultat den Kaufpreis und damit den Aufwand kaum rechtfertigt.

Und andererseits kommt wahrscheinlich so mancher interessante Gedanke gar nicht erst an die Öffentlichkeit. Der Gedankeninhaber fühlt sich abgeschreckt durch den Verlagsprozess und der Verlag erwartet einen gewissen Umfang, der sich auch lohnt zu publizieren. Unter 150 Seiten mag man eher kein Buch beginnen. Schade um die Gedanken, die es in angemessener Darstellung nur auf vielleicht 90 Seiten bringen. Sie sind zu klein für ein Buch – und ein Blog hat ja auch nicht jeder Denker.

So hab ich im Gespräch mit dem Lektor gedacht, da könnten sich Verlage durch leichte, einfache Angebote noch in die Herzen von Autoren spielen. Oder… Hm… gibt es das nicht irgendwie schon? Was fehlt denn wirklich? Mit Kindle Direct Publishing und Createspace hatte ich ja schon Erfahrungen gesammelt im Zusammenhang mit einem eigenen kleinen Sachbuch und dem Roman einer Bekannten.

Also habe ich mich nochmal aufgemacht zu einem weiteren Veröffentlichungsexperiment. Inhaltlich wollte ich dafür nichts Neues produzieren. Es ging mir ja um den Veröffentlichungsprozess. Also habe ich einige zusammenhängende Artikel aus meinem englischen Blog zur Veröffentlichung in einem Buch ausgewählt.

Hier meine aktuellen Erfahrungen in drei Phasen:

1. Das Manuskript

Auch wenn ich den Inhalt des Buches schon hatte, musste ich ihn noch in ein Manuskript gießen. Blogbeiträge kann man nicht einfach veröffentlichen. Anders als bisher wollte ich aber nicht MS Word als Schreibwerkzeug benutzen. Daraus eBooks zu machen, war insbesondere bei meinem kleinen Sachbuch durchaus noch umständlich.

Stattdessen wollte ich es mal mit Markdown versuchen. Markdown verheißt Konzentration auf den Text. Die Formatierungsmöglichkeiten sind beschränkt, das Tooling ist einfacher. Es gibt für Mac und Windows einige Editoren, die Markdown zu einem Kinderspiel machen. Man kommt gar nicht in die Versuchung, spezielle Formatierungen einzusetzen, die bei eBooks ohnehin nicht sichtbar sind.

Hier ein Beispiel der Anfang des 2. Kapitels meines Experimentalbuches in Mou (für Mac OSX, unter Windows bietet sich MarkdownPad an):

Markdown-Dateien sind Textdateien. Bilder sind nicht eingebettet. Das bedeutet, die Kontrolle über deren Auflösung ist direkter als bei Word: Es gilt, was auf der Platte liegt.

Für Markdown gibt es verschiedene Konvertierungen, allemal die nach HTML. Aber ich habe es mir einfacher gemacht, um von Markdown zum eBook zu kommen…

2. Die eBook-Herstellung

Die Wahl von Markdown fürs Schreiben war auch beeinflusst durch die Publishing-Plattform Leanpub. Dort will man es Autoren so leicht wie möglich machen, vom Manuskript zum eBook zu kommen. Genau das, was ich dem Lektor vermitteln wollte.

Wenn man bei Leanpub ein Buchprojekt aufsetzt, wird ein Dropbox-Verzeichnis bei Leanpub erstellt, das mit dem Autor geteilt wird. In dieses Verzeichnis legt er sein Manuskript als Markdown-Texte und den Abbildungen, so dass die Dateien zu Leanpub hin synchronisiert werden.

Und wenn er eine Version seines eBooks herstellen will, dann drückt er auf einen Knopf im Leanpub-Adminbereich seines Buchprojektes.

Kurz darauf steht das eBook als PDF, mobi und ePub Version in seiner Dropbox.

Ein Leanpub-Konto und ein Leanpub-Buchprojekt lassen sich in wenigen Minuten aufsetzen. Die Technik ist also kein Problem. Sie tritt sogar so weit in den Hintergrund, dass man nicht anders kann, als sich auf den Inhalt zu konzentrieren: das Manuskript und die Metadaten im Projekt wie Klappentext, Autorenbeschreibung und vor allem Titelbild. Gerade das Titelbild kann da nochmal eine ordentliche Bremse sein. Denn wer gerne schreibt, muss nicht unbedingt auch gerne “malen”.

Wer sich davon nicht ins Bockshorn jagen lassen will, der verzichtet erstmal auf ein eigenes Titelbild und lebt mit dem von Leanpub generierten textuellen Titelblatt.

Vom Text zur ePub/mobi eBook-Datei ist es mit Leanpub ein Kinderspiel. Das ist fast so einfach, wie einen Blogartikel zu schreiben. Nur etwas Obacht bei Bildern! Die müssen eine passende Auflösung haben. Aber Leanpub meldet, wenn die bei Herstellung der Print-Version nicht groß genug erscheint. Ein paar Runden sind also ggf. zu drehen, bis Auflösungen und Bildgrößen im Text stimmen. Übung macht aber auch hier den Meister. Für einen ersten eBook-Schuss sollte das in jedem Fall kein Hindernis sein.

Aber was nun tun mit den eBook-Dateien?

3. Die Veröffentlichung

Leanpub hilft nicht nur bei der Herstellung von eBook-Dateien, sondern auch bei deren Monetarisierung. Wer nicht nur den Preview- sondern auch den Publish-Knopf drückt, der veröffentlicht sein Buch ohne weiteren Aufwand im Leanpub online Buchladen.

Da kann man sehr komfortabel festlegen, wieviel man damit verdienen will. Und den Leser steht es durchaus frei, einen ihnen genehmen Preis zu zahlen:

Wer mag, kann sein Buch auch schon als work-in-progress Werk anbieten. Interessenten können sich dann registrieren. Und wer schon kauft, wird später über Updates informiert.

Das ist alles sehr bequem für Autoren wie Leser, finde ich. Doch die Reichweite von Leanpub ist natürlich gering. Dort geht niemand zum Stöbern hin. Wer also weiter gesehen werden will, der muss bei amazon & Co vertreten sein.

Das ist zum Glück denkbar einfach. Leanpub stellt sich dem nicht entgegen, sondern motiviert dazu offensiv. Also habe ich die Print-Version meines eBooks genommen und bei lulu.com sowie Createspace eingetragen, um daraus Papierbücher machen zu können [1]:

Das Titelbild musste ich dafür zwar leicht in den Abmessungen verändern, aber ansonsten war es sehr einfach: Leanpub-PDF hochladen, Klappentext eintragen, Titelbild hochladen, fertig. Jetzt warte ich noch auf die Proofs für die Bücher, bevor ich sie zum Verkauf bei lulu.com und amazon freischalte.

Aber nicht nur mit der Papierversion des Buches möchte ich natürlich weithin sichtbar sein bei amazon. Dort soll auch das eBook erhältlich sein. Das könnte ich über Kindle Direct Publishing leicht selbst machen, indem ich das Leanpub mobi-File dort hochlade – aber amazon will von mir, dass ich ein US-Steuerformular ausfülle. Das mag ich nicht. Da sind mir die Konsequenzen nicht klar.

Deshalb gehe ich einen kleinen Umweg über die Veröffentlichungsplattform xinxii. Dort habe ich einen Eintrag für das Buch angelegt und mein mobi-File hochgeladen.

Und von dort habe ich die Distribution über amazon angestoßen. Das ist kostenfrei und dauert leider 7-10 Tage… aber es bleibt sehr einfach. So ist denn mein Experimentalbuch jetzt auch bei amazon zu haben:

Der Preis ist bei Leanpub, xinxii und amazon derselbe. Kostenlos kann ich es leider bei xinxii nicht anbieten, also habe ich mich für den kleinstmöglichen Preis entschieden: 0,99 EUR. Aber ich denke, das sollte einer breiten Lektüre nicht im Wege stehen. Für weniger Geld als einen Coffee-to-go ist hier längerer Genuss zu haben :-) Das Thema: Was Nachrichtenorientierung eigentlich in der objektorientierten bedeutet.

Fazit

Selbstverlag ist kein Hexenwerk. Die Technik steht im Hintergrund. Autoren können sich auf Idee und Text konzentrieren. Von dort ist der Weg einfach zum eBook-Dateien, eBook-Veröffentlichungen auf verschiedenen Plattformen inklusive den großen und sogar einem echten Papierbuch.

Meine Empfehlung derzeit:

1. Manuskript in Markdown aufsetzen
2. Schnelle, womöglich iterative Veröffentlichung als eBook auf Leanpub
3. Sobald zufrieden mit Inhalt und Form weitreichender veröffentlichen bei amazon & Co. Dafür die Hilfe von xinxii in Anspruch nehmen.
4. Und als Krönung mit Createspace das Buch auf Papier bringen. (lulu ist für Belegexemplare teurer und hat mit seinem Shop natürlich nicht die Reichweite wie amazon.)

Das Gespräch mit dem Lektor war an einem Freitag. Am Sonntag danach hat mich der Ehrgeiz gepackt, zu sehen, wie einfach eine Veröffentlichung sein kann. Am Sonntag Abend war das eBook bei Leanpub fertig nach ca. 5-6 Stunden Aufwand der Umsetzung der Blogartikel nach Markdown. Am Montag war es bei xinxii veröffentlicht und zur Distribution bei amazon eingereicht – Aufwand 15 Minuten. Am Montag war es bei Createspace und lulu.com zum Druck eingetragen – Aufwand 1 Stunde für die Anpassung des Titelbildes und des Klappentextes.

Wer ein Manuskript in Markdown vorliegen hat, ist mit einem halben Tag weltweit am Start mit seinem Buch. Wer noch keines hat, tut sich einen Gefallen, in Markdown zu schreiben bzw. nach Markdown zu konvertieren. Ich habe mich damit auch bis neulich noch nicht ganz wohl gefühlt – aber das Gefühl habe ich inzwischen überwunden. Leanpub hat mich überzeugt. Noch nie war der Weg zu eBook-Dateien guter Qualität so kurz, finde ich.

Davon können sich Verlage eine Scheibe abschneiden. Denn da ist noch room for improvement, würde ich sagen. Warum Leanpub als Gegner und nicht als Ansporn oder Partner ansehen?

Endnoten

[1] Ein Tipp zum Format des Print-Buches: Es lohnt sich, darüber schon möglichst früh im Klaren zu sein, welches Format eine Print-Version des Buches haben soll. Denn das sollte zumindest von Leanpub wie dem Printbuch-Herstellen (Createspace, lulu) unterstützt werden. Ich habe mich für dieses Buch für US-Paperback entschieden.

Investitionssicherheit – Meine Definition

Investitionssicherheit scheint keine Definition zu haben. Wikipedia schweigt. Der Duden schweigt. Kaum zu glauben. Der Begriff wird zwar benutzt – Google findet knapp 290.000 Seiten dazu –, doch alle scheinen eine Definition vorauszusetzen – die ich leider nicht finde. Und das, wo es mir doch so wichtig geworden ist als eines der anzustrebenden Ziele in der Softwareentwicklung. Also muss ich mir wohl selbst Gedanken machen, was genau darunter zu verstehen ist.

Was eine Investition ist, findet sich noch bei Wikipedia. Dort ist eine Investition in der Geschäftswelt eine Verwendung finanzieller Mittel, um Gewinn zu steigern, vor allem durch Sachanlage. Platt gesagt: Ein Unternehmen gibt Geld für eine Sache aus, damit es am Ende mehr Geld hat.

Beispiel: Ein Frisör kauft für 250 EUR einen Powerföhn, um pro Tag 1 Kunden mehr bedienen zu können (ein Umsatzplus von 50 EUR) und pro Woche 3 Kunden das Föhnen als Dienstleistung zusätzlich zu verkaufen (ein Umsatzplus von 3 x 5 EUR). Motto: Selber föhnen kann man zuhause; wer zum Frisör geht, soll es bequem haben.

Pro Monat ist das also ein Umsatzplus von 4 x (50 + 3 x 15) = 4 x 95 = 380 EUR. Dafür sind keine weiteren Fixkosten nötig, sondern nur die Investition in den Powerföhn. (Einen erhöhten Stromverbrauch lasse ich mal außen vor ;-)

Würde die sich lohnen? Selbstverständlich. Es wäre eine erfolgreiche Investition. Schon nach einem Monat wären die Kosten durch das Umsatzplus wieder eingespielt – und sogar noch 130 EUR zusätzlich. Im ersten Jahr wären die Mehreinnahmen 130 EUR + 11 x 380 EUR = 4.310 EUR. Das nennt man einen guten Return-on-Investment (ROI), würde ich sagen.

Was ist nun aber die Sicherheit in Bezug auf diese Föhn-Investition? Ist die umso größer, je sicherer (verlässlicher, erwartbarer) durch die Sachanlage das Ziel “1 Kunde mehr pro Tag und 3 Mal Föhnen pro Woche mehr” erreicht wird? Was, wenn die Kunden knapp bei Kasse sind und pro Woche nur einer sich föhnen lassen will? Was, wenn der Powerföhn nur mehr Leerlauf herstellt, weil die Kunden schneller fertig sind, aber keine weiteren anstehen, die bedient werden könnten?

Das sind legitime Fragen, es gibt also ein Risiko bei der Investition. Es ist unsicher, ob die Investition in den Powerföhn sich auszahlt. Doch dieses Risiko hat nichts mit dem Powerföhn selbst zu tun. Es ist vorhanden bei gegebenen Eigenschaften des Powerföhns. Und ob die dazu führen, dass ein gewünschtes Ergebnis eintritt… daran kann der Powerföhn nichts ändern. Er kann nur wie vom Hersteller versprochen leisten, wenn er leisten soll.

Neben dem Risiko, das in einer Idee/Maßnahme steckt – Kommt es zu den Einsätzen die Powerföhns wie gewünscht? –, gibt es aber noch ein zweites. Das steckt in der Sachanlage selbst. Da lautet die Frage nämlich: Wie sicher ist es, dass die Sachanlage leistet, wie versprochen und geplant?

Es könnten ja Kunden im Frisörladen Schlange stehen und alle sich bequem föhnen lassen wollen. Nur leider streikt der Powerföhn: Er läuft zu schnell heiß, andauernd müssen Ersatzteile gekauft werden, die Temperatur ist nicht stabil, so dass Kunden sich über Kopfhautrötungen bzw. Verkühlung beschweren… In dem Fall wäre das Konzept grundsätzlich aufgegangen – aber die Investition in den Powerföhn verfehlt. Besser wäre vielleicht gewesen, den Ultraföhn des Wettbewerbers zu nehmen. Wer weiß…? Investitionen haben also ein in der Sachanlage inhärentes Risiko. Oder umgekehrt: Investitionen haben eine mehr oder weniger große Sicherheit.

Der Begriff Investitionssicherheit steht mithin für eine Wahrscheinlichkeit, dass eine Sachanlage für das investierte bzw. absehbar noch nachzuschießende Geld (Reparaturen, Wartung) über einen festgelegten Zeitraum leistet, was sie leisten soll.

Beim Powerföhn scheint die Investitionssicherheit sehr groß, würde ich sagen. Zwischen 4.310 EUR und 250 EUR ist soviel Luft, da kann der Powerföhn auch ein paar Mal kaputtgehen oder gar neu gekauft werden, und es entsteht immer noch ein Umsatzplus – sofern “der Markt”, d.h. die Nachfrage im Laden den Erwartungen entspricht.

Auch wenn Software immateriell ist, also eher keine Sachanlage darstellt, bietet sie natürlich auch Investitionssicherheit. Wer eine Fibu-Software kauft, hat die Idee, dadurch den Gewinn zu steigern. Wahrscheinlich soll das durch Reduktion von Kosten geschehen, vielleicht aber auch durch Steigerung von Umsatz, weil der buchhaltende Geschäftsführer wieder mehr Zeit hat, sich um den Verkauf zu kümmern.

Ob dieser Gewinnzuwachstraum in Erfüllung geht, hängt zumindest zum Teil davon ab, ob die Fibu-Software tatsächlich leistet, was sie leisten soll. Und zwar nicht nur heute, sondern auch in Zukunft. Und das ist der Knackpunkt: “auch in Zukunft”.

Investitionssicherheit hat auch bei Software natürlich mit der unmittelbaren heutigen Funktionalität und Qualität zu tun. Kann eine Software rechnen? Ist die Berechnung korrekt? Ist die Berechnung schnell genug?

Anders als in der materiellen Welt verfallen Funktionalität und Qualität jedoch nicht. Es gibt keinen Verschleiß. Was die Software heute kann, kann sie auch noch morgen und übermorgen. Haltbarkeit ist kein Problem bei Software. Wo ein Föhn mit der Zeit durch Gebrauch (oder sogar bei Nichtgebrauch) schwächeln mag, ist Software immer bereit wie am ersten Tag.

Ob diese Bereitschaft jedoch genügt…? Wie schon früher argumentiert, tut sie das nicht. Investitionssicherheit jenseits des Offensichtlichen und damit ganz eigentlich bedeutet bei Software das Gegenteil von dem, was sie bei Hardware bedeutet, nämlich Wandelbarkeit.

Wer in eine Fibu oder einen online Shop oder ein HUD für online Poker oder ein CRM investiert, der empfindet die Sicherheit nur als hoch, wenn die Software sich in einem abschätzbaren Kostenrahmen über den festgelegten Zeitraum auch verändern lässt. Veränderungen sollen also erstens überhaupt möglich bleiben und zweitens nicht zu teuer werden.

Die Investitionssicherheit ist mithin gering, wenn bei einer erwarteten Nutzungsdauer von 5 Jahren die Entwickler nach 4 Jahren anfangen zu sagen, dass eine Veränderung kaum mehr einbaubar ist. Besser wäre gewesen, das schon 2 Jahre vorher getan zu haben, weil es jetzt überproportional teuer wird. In dem Fall leistet die Softwareanlage nicht, was sie leisten soll, auch wenn am Anfang niemand wusste, was einmal nötig sein würde. Aber so ist das halt mit Software. Da ist Software besonders.

Und deshalb ist Investitionssicherheit für mich eine ganz eigene Anforderung getrennt von Funktionalität und Qualität, auf deren Erfüllung ebenso konstant geachtet werden muss. Also muss es dafür auch einen echten Stakeholder geben.

Keine Veränderung ohne echten Stakeholder

Das größte Problem von Unternehmen heute scheint mir ein Mangel an Stakeholdern. An echten Stakeholdern. Denn ohne echte Stakeholder bleiben Veränderungen stecken.

Für mich ist ein Stakeholder zunächst einmal jemand, der etwas haben will. So sieht Wikipedia das auch - nur viel ausführlicher.

Sie werden jetzt denken, “Daran mangelt es doch aber gar nicht. Alle möglichen Leute und Gruppen wollen ständig etwas haben.” Da haben sie natürlich recht. Deshalb braucht es aus meiner Sicht auch noch etwas mehr, um Stakeholder zu sein. Ohne Zusatz ist Stakeholder nämlich nichts anderes als ein Management-Ausdruck für “Dreijähriger”.

Und wahrlich, an Dreijährigen, die sich lauthals etwas wünschen und dann erwarten, dass das auch ASAP von einem Weihnachtsmann geliefert wird, weil sie sich sonst trotzig auf den Boden werfen oder mit dem großen Bruder drohen, mangelt es in Organisationen nicht.

Ein echter Stakeholder ist aber anders. Der will nicht nur haben, der sitzt nicht einfach auf einem Königsthron. Nein, der setzt sich dafür ein, indem er immer wieder Zug auf den Lieferanten und andere Stakeholder ausübt.

Ein echter Stakeholder versteht zweierlei:

1. Er ist nicht allein mit seinen Wünschen an den Lieferanten. Bei allem Interesse, sie erfüllt zu bekommen, ist er deshalb um Balance und Ausgleich im Feld der Zugspannungskräfte der vielen Stakeholder bemüht.
2. Wünsche werden nicht einfach erfüllt, nur weil man sie äußert. Es braucht vielmehr kontinuierliche Präsenz beim Lieferanten, um immer wieder deutlich zu machen, “was wichtig ist”.

Für mich ist ein prototypischer echter Stakeholder der Bauherr eines Familienhäuschens. Der hat einen Wunsch geäußert und Lieferanten beauftragt (Bauunternehmer, Handwerker). Aber der lehnt sich danach nicht zurück. Ich kenne keinen Bauherren, der nach Auftragserteilung auf eine ausgedehnte Reise gegangen wäre, um im Anschluss ein schlüsselfertiges Haus zu beziehen. Vielmehr ist der Bauherr ständig auf der Baustelle. Mal mit Zuckerbrot, mal mit Peitsche. Jeden Tag erscheint er und macht den Ausführenden klar, was er will. Insbesondere weist er auf Mängel hin.

In der Softwareentwicklung sehe ich ein solches Verhalten jedoch eher nicht. Dort gibt es eine Menge Stakeholder - aber keine echten. Es tut mir leid, sagen zu müssen, aber meist sehe ich nur einen Kindergarten. Eine Menge Leute laufen aufgeregt umeinander und wünschen sich Berge an Veränderungen… nur keiner hat Zeit, an diesen Veränderungen zu ziehen. Regelmäßig “verreisen” sie nach Auftragserteilung.

Stakeholder ziehen nicht, sondern sie drücken. Sie drücken Teams Aufgaben rein und erwarten, dass die wie von Zauberhand einfach richtig erledigt werden.

So funktioniert es aber nicht. Wie jeder Häuslebauer weiß. Ein Grund, der auf der Hand liegt, sind Mängel in der Wunschformulierung. Ein anderer sind die vielfältigen Kräfte, die auf Lieferanten einwirken. Die werden ja nicht nur von einem Stakeholder gepresst, sondern von vielen. Da entscheiden sie dann immer wieder neu, wie sie am besten ihren Arsch retten.

Dazu kommt, dass oft die Fähigkeiten zur Wunscherfüllung nicht so ausgeprägt sind, wie ein Stakeholder es sich das wünscht. Und schließlich fragen sich Lieferanten sehr schnell “Wozu der ganze Mist? Wozu soviel Stress?”, wenn der Stakeholder nicht zieht. Das ist dann die Sinnfrage.

Und wie sieht der ominöse Zug aus? Wodurch unterscheidet es sich vom Druck?

1. Erstes Merkmal von Zug ist die wiederkehrende Frage, wie und wo ein Merkmal der beauftragten Lieferung überprüft werden kann. Selbstverständlich nimmt der echte Stakeholder dann die Überprüfung selbst vor. Das ist ein Kennzeichnen jedes nicht-industriellen Herstellungsprozesses, würde ich sagen. Was aus einer Fabrik kommt, wurde dort bereits überprüft; darauf verlasse ich mich als Konsument. Was aber nicht aus einer Fabrik kommt - ein Haus oder eine Software - kann und muss ich als Auftraggeber selbst überprüfen. Ein Stakeholder ist also Abnehmer. Das meine ich genau so: Der Stakeholder überprüft. Er lässt sich nichts präsentieren, sondern begeht und nutzt selbst (oder beauftragt dazu eine vom Lieferanten unabhängige Instanz) [1].
2. Zweites Merkmal von Zug ist die Präsenz des Stakeholders. Er begibt sich immer wieder zum Lieferanten bzw. Herstellungsort. Er ist vor Ort, um Fragen zum Fortgang zu stellen oder durch seine Anwesenheit es leichter zu machen, gefragt zu werden. Eine “Politik der offenen Tür” ist zuwenig. “Ihr könnt jederzeit kommen, um zu fragen.” ist ein wichtiges Angebot. Weniger darf nicht sein. Nur reicht es eben nicht. Immer wieder gibt es nämlich Barrieren, die verhindern, es in genügendem Maße zu nutzen.
3. Schließlich halte ich es für wichtig, dass ein Stakeholder mithilft. Natürlich soll er sich seinen Wunsch nicht selbst erfüllen. Aber er soll helfen, Hindernisse für den Lieferanten aus dem Weg zu räumen [2]. Das ist nicht nur produktiv mit Blick auf die Wunscherfüllung, sondern auch motivationsstiftend beim Lieferanten. Der sieht sich dann als Partner und nicht nur als austauschbarer Leibeigener.
4. Dass ein Stakeholder auch eine gewisse Macht braucht, muss ich nicht weiter betonen, oder? Ein echter Stakeholder kann selbst über Ressourcen entscheiden, um seinen Wunsch erfüllt zu bekommen. Er muss niemanden fragen.

Die Formulierung eines Wunsches durch einen Stakeholder ist für mich weniger wichtig als die Abnahme. Natürlich muss ein Wunsch erst formuliert werden, bevor ein Lieferant sich aufmachen kann, ihn zu erfüllen. Doch gerade in der Softwareentwicklung ist diese Formulierung notorisch mangelhaft. Sie ist kaum mehr als ein frommer Wunsch. Umso mehr, je weiter der Liefertermin in der Zukunft liegt.

Deshalb ist die Gewichtung von Beauftragung/Planung und Abnahme z.B. in verbreiteter Scrum-Praxis aus meiner Sicht falsch. Es wird zu viel Gewicht auf das Sprint Planning gelegt und zu wenig auf den Sprint Review (oder allgemeiner: auf die Abnahme).

Stakeholder gibt es viele. Aber echte Stakeholder… die sind rar.

Mindestens deshalb hapert es auch allerorten bei der Erfüllung von Wünschen. Das können Softwarefunktionen sein, das können Qualitäten von Software sein, das kann die Wandelbarkeit von Software sein, das kann die Einführung eines Tools sein, das kann die Einführung eines Prozesses sein, das kann die Umstellung auf Papierlosigkeit sein usw. usf.

Die Regel ist, dass gewünscht wird - und dann glaubt man, dass die Erfüllung schon eintreten wird. Manchmal werden markige Sprüche im Gang aufgehängt (“Qualität ist nicht verhandelbar!”), doch wer daran zieht, bleibt im Dunkeln. Und ob überhaupt die Fähigkeiten existieren, die Wünsche zu erfüllen, ist auch nicht klar.

Befehle, Maximen, Regelwerke, Incentives, Strafen… es gibt viele Wege, Druck auszuüben. Die werden alle angewandt. Und man wundert sich, dass die gewünschten Effekte nur schwer erreicht werden.

Dabei ginge es viel leichter, glaube ich. Zug statt Druck lautet die Zauberformel. Die braucht allerdings etwas, das viele wohl nur schwer aufbringen können oder wollen: persönliches Engagement.

Denn um an Ergebnissen zu ziehen, muss man ja da sein. Man muss durch Präsenz und Nachfragen und Erklären immer wieder deutlich machen, dass man die Ergebisse wirklich, wirklich will.

Insofern suche ich bei der Problemanalyse in Teams und Organisation zuerst nach echten Stakeholdern. Solange es die nicht gibt, liegt ein Wurzelproblem vor.

Und umgekehrt muss für jedes Veränderungsziel ein echter Stakeholder benannt sein. Wo das schwer fällt, ist schon wieder ein Wurzelproblem aufgedeckt [3].

Echte Stakeholder sind für mich also absolut zentral. Damit getan ist es allerdings nicht. Denn es ist eine Sache, überhaupt erst einmal Zug herzustellen. Doch wie reagiert ein Lieferant darauf? Wie kann er darauf reagieren? Beispiel Clean Code Development. Wer dafür einen echten Stakeholder einsetzt, ist schon einen Schritt weiter als andere. Die Entwickler müssen nur auch in der Lage sein, Clean Code zu produzieren. Der Wille allein genügt hier leider nicht. Woher kommt aber das Wissen, die Fähigkeit?

Einem echten Stakeholder ist deshalb oft zumindest in der Anfangsphase ein Lehrer beizuordnen. Der sorgt dafür, dass Lieferanten in die Lage versetzt werden, dem Zug des Stakeholders zu entsprechen. Mal kann der Lehrer im Hause sitzen, mal findet er sich in einem Seminar, mal braucht es einen Coach über längere Zeit.

Veränderung braucht insofern nicht nur Zug, sondern auch Befähigung. Wir müssen aufhören, daran zu glauben, dass Veränderungen einfach so “auf Befehl” erreicht werden. Umso weniger, je “weicher” sie sind, d.h. je mehr sie mit Gewohnheiten, Glaubenssätzen, Kultur zu tun haben. Ebenso, wo Wünsche unscharf sind oder Risiken hoch. Dann braucht es auch Zug im obigen Sinne und Lernschleifen.

Endnoten

[1] Insofern sind für mich die meisten Scrum Sprint Reviews eine Farce. Da präsentieren Entwickler und der Stakeholder ProductOwner lässt sich entertainen. Das ist für mich kein Zug.

[2] Die Konkrete Hilfestellung kann ein Stakeholder natürlich delegieren. Aber sofern Hindernisse außerhalb des Lieferanten liegen, ist es genauso die Verantwortung des Stakeholders, an ihrer Beseitigung zu arbeiten wie die des Lieferanten. Es geht ja um ein Gesamtergebnis; Stakeholder und Lieferant sind in Bezug darauf ein Team. Wunschkonzert und Ponyhof sind woanders.

[3] Das ist übrigens ein sehr häufiges Wurzelproblem. Denn heute sind ja alle schon mit ihrem Tagesgeschäft voll ausgelastet. Wie soll man denn da noch die zusätzliche Rolle eines echten Stakeholders einnehmen können?

Wenn Veränderungen es schwer haben in Organisationen, dann ist das also kein Wunder. Man stellt sich jeden Tag wieder selbst ein Bein, indem man versucht, Menschen voll auszulasten mit dem Tagesgeschäft. Das mag heute effizient sein - aber auf längere Sicht ist es kontraproduktiv, weil damit Kapazität für notwendige Veränderungen fehlt.

Mitmachen: Flow-Designs gesucht

Für Programmieraufgaben gibt es ja nicht nur eine Lösung. Aber wie bunt die Lösungswelt ist, ist andererseits auch nicht ganz klar. Deshalb würde ich mich freuen, wenn Sie mitmachen würden bei der Sammlung von Lösungen.

Zu einem kleinen Programmierproblem möchte ich Lösungen in Form einer kleinen Bilderausstellung veröffentlichen. Dann können wir darüber diskutieren. Allerdings geht es mir nicht um Quellcode, sondern um visuelle Lösungen.

Also:

Ich suche Lösungen zum Problem “Ordered Jobs” in Form von Flow-Designs.

Datenflüsse sollen im Mittelpunkt stehen. Aber wer die mit weiteren Bildern garnieren möchte, ist dazu herzlich eingeladen.

Die Ausdrucksmittel des Flow-Designs habe ich in vielen Publikationen beschrieben und über die Jahre verfeinert. Leider bin ich noch nicht dazu gekommen, einen aktuellen Stand an einem Ort zusammenzufassen. Mea culpa. Aber es gibt einen Spickzettel, der größtenteils aktuell ist und die Notation knapp beschreibt. Alternativ beschreiben einige Artikel unter der Überschritz “OOP as if you meant it” nochmal in Kürze meine aktuelle Sicht zu Flow-Design.

Wer mitmachen will, schreibt am besten einen Kommentar zu diesem Artikel mit einem Link zu einem PDF mit seinem Entwurf. Oder es können Links zu yuml.me Grafiken sein; mit den Aktivitätsdiagrammen kann man Flow-Designs recht ordentlich beschreiben. Oder schicken Sie mir eine Email mit einem PDF.

Am Ende bastle ich dann eine Zusammenschau mit ein paar Anmerkungen zu dem, was mir auffällt. Und ich lege auch meine Vorstellung von einer Lösung vor. Dann gibt es eine “Ausstellungseröffnung” hier im Blog :-)

Zu gewinnen gibt es nichts – außer Erkenntnissen.

Wer macht mit? Einsendeschluss ist der 30.11.2013.

Ich bin gespannt auf die Vielfalt der Lösungsansätze.

Und hier nun die Aufgabe in epischer Länge. Sie ist auch im Fundus der Programmier-Katas der CCD School zu finden.

Class Kata Ordered Jobs by Clean Code Developer School

Knapp daneben macht auch nicht zufrieden

Software macht dem Kunden Spaß, wenn seine Anforderungen erfüllt werden. Dafür ist er bereit, Geld auszugeben. Und was sind seine Anforderungen?

Für mich gibt es drei Säulen, auf denen zufriedenstellende Software ruht:

• Funktionalität
• Primäre Qualität
• Investitionssicherheit

Dass Software funktional ihren Dienst erfüllen muss, um zufrieden zu stellen, liegt auf der Hand. Eine Taschenrechner-Anwendung, die nicht korrekt rechnet, ist ihr Geld nicht wert.

Wenn der Taschenrechner aber nicht deutlich schneller rechnet als ein Mensch, dann ist etwas falsch. Ohne eine hohe primäre Qualität “Performance” ist er also sein Geld auch nicht wert. Er würde sogar nicht einmal geschrieben. Die primären Qualitäten sind mithin die hauptsächlichen Treiber der Softwareentwicklung.

Und schließlich wird niemand das Geld für die Entwicklung in die Hand nehmen, wenn nicht sichergestellt ist, dass die Nützlichkeit des Resultats lange bzw. lange genug erhalten bleibt. Investitionssicherheit ist gefragt. Die allerdings sieht für Software anders aus als für Hardware.

Das hatte ich schon ausführlich in einem früheren Blogartikel beschrieben. Doch jetzt ist mir klar geworden, wie diese Sichtweise auch sonst im Leben hilfreich ist. Neulich bin ich nämlich Bahn gefahren und ein mobil-Sonderheft der DB lag auf meinem Tisch, Thema: Nachhaltigkeit.

Dazu ist mir meine Bahncard eingefallen, die in diesem Jahr ebenfalls nachhaltig grün ausgefallen ist.

Farblich bewegt sich die Bahn also durchaus in eine positive Richtung. Mehr ökologisches Denken schadet ihr und uns allen sicherlich nicht.

Aber…

Mir stieß das Sonderheft auf, weil es eine aus meiner Sicht derzeit falsche Priorisierung darstellt. Es preist die Bemühungen der Bahn in Bezug auf die 3. Säule an, Investitionssicherheit. Die Bahn soll nicht nur heute funktionieren, sondern auch in Zukunft. Klar.

Weder Software noch die Bahn wird aber gemacht, um nachhaltig zu sein. Höhere Priorität müssen Funktionalität und primäre Qualitäten haben. Erst wenn es da stimmt, dann wird Nachhaltigkeit überhaupt relevant.

Im Hinblick auf Funktionalität und primäre Qualitäten stimmt es jedoch gerade nicht bei der Bahn. Züge, die nicht fahren, stellen grundsätzliche mangelnde Funktionalität dar. Züge, die grob unpünktlich sind, verletzen die primären Qualitäten Verlässlichkeit und Geschwindigkeit. Nicht funktionierende Türen und Toiletten, steckdosenfreie Waggons, fehlende Reservierungsanzeigen usw. verletzen sekundäre Qualitäten wie Bequemlichkeit oder gar Sicherheit.

Die beiden hauptsächlichen Säulen, auf denen die Bahn ruht – Funktionalität und Qualität – sind also morsch und bröckelig. Ihnen ist immer weniger zu trauen. Und da findet es die Bahn wichtig, in die dritte Säule zu investieren? Das ist bestenfalls naiv und schlimmstenfalls fahrlässig. Denn die Investition in diese Form der Nachhaltigkeit kann die Nachhaltigkeit in Bezug auf die Zwecke der Bahn untergraben.

Dasselbe kann natürlich auch Software passieren. Wo Funktionalität und Qualitäten im Argen liegen, sollte nicht mit Nachhaltigkeitsoffensiven “green washing” betrieben werden. Clean Code und ein Blick auf Wandelbarkeit oder Produktionseffizienz ist wichtig. Doch das ist kein Selbstzweck. Ein Ausbalancieren mit den Hauptzwecken der Software ist wichtig.

Die Bahn macht mich mit ihrem Fokus nicht zufrieden. Der liegt mindestens knapp neben dem, was ich von ihr zuallererst will. Genauso müssen wir aufpassen, in der Softwareentwicklung mit gut gemeinten Maßnahmen nicht das Wesentliche zu verfehlen.

Wann tut Veränderung Not?

Als Berater und Trainer für Softwareprojekte stelle ich mir immer wieder die Frage, wann eine Organisation eigentlich Hilfe benötigt? Wann sollte sie sich verändern? Mit meiner Hilfe oder auch einfach durch Eigenleistung.

Ich komme gern in jedes Projekt und gebe einen Impuls oder begleite eine Veränderung des Produktionsprozesses oder der Architektur. Das macht mir Spaß, damit verdiene ich mein Geld. Befriedigend ist es allerdings nur, wenn meine Hilfe auch wirklich nötig ist. Wann ist das der Fall, wie kann man das feststellen?

Eine Analogie kommt mir in den Sinn: Wann ist es nötig, einem Menschen in Gesundheitsdingen zu helfen? Klar, natürlich nur, wenn der das will. Aber auch dann stellt sich ja die Frage, wie krank jemand ist.

Beispiel “dicker Mann”: Ist der Mann auf dem Bild rechts gesund? Er scheint sich ja seines Lebens zu freuen, wenn er so für das Foto posiert.

Ich traue mich nicht zu beurteilen, ob er gesund ist. Er mag nach meinem Ideal nicht gesund aussehen. Aber wer bin ich, dass ich meinen Maßstab als universell gültig ansehen könnte? Reicht es denn nicht, dass er sich wohlfühlt?

Doch, ich glaube, das reicht. Wer sich wohlfühlt, der ist gesund.

Mit einer Einschränkung: Das Wohlgefühl sollte nicht nur in einer Situation abgefragt werden, sondern unter Veränderungen. Denn Leben ist nicht statisch, sondern dynamisch. Irgendwas passiert ja immer. Wir müssen uns immer wieder unterschiedlichen Herausforderungen stellen.

Der Mann auf dem Bild wird aufstehen und aus dem Haus gehen wollen. Schafft er das? Er wird mit unterschiedlicher Witterung fertig werden müssen. Schafft er das? Er wird plötzlich einem Auto ausweichen müssen, das er bei der Straßenquerung übersehen hat. Schafft er das? Er wird sich einen Platz in einem Flugzeug oder Zug suchen müssen. Schafft er das? Oder er wird, wie der Mann in dieser Geschichte durch ein Drehkreuz gehen müssen. Schafft er das?

Wie schon in einem anderen Blogartikel beschrieben, halte ich die Fähigkeit, Veränderungen kompensieren zu können, für eine zentrale Anforderung an Gesundheit. Wer sich gesund nennen will, muss anpassungsfähig sein.

Solche Anpassungsfähigkeit hat aus meiner Sicht zwei Seiten: eine subjektive und eine objektive. Es gibt einige objektive Anforderungen, die alle Menschen erfüllen können müssen, wenn sie als Gesund gelten wollen. Dazu zähle ich mal die Fähigkeit, auf eine unerwartete Ansprache von hinten nicht mit einem Herzschlag zu reagieren oder bei einer Temperatursteigerung von 20° auf 30° Celsius nicht an einem Hitzschlag zu sterben.

Jenseits relativ enger objektiver Grenzen ist das Feld subjektiver, ganz persönlich als notwendig angesehener Kompensationsfähigkeit weit. Ich persönlich fühle mich nur gesund, wenn ich zu meiner Wohnung im 4. Stock über die Treppe zügig hochgehen kann. Neulich haben jedoch zwei Frauen einige Regale bei mir abgeholt, die ich per ebay Kleinanzeigen verschenkt hatte, die mit dem 4. Stock nicht wirklich zurecht kamen. Sie waren Anfang 30, sehr korpulent und haben mich mehrfach gefragt, wie ich das denn aushalten würde, so hoch droben ohne Fahrstuhl zu leben.

Aber wie gesagt, selbst wenn ich diese Frauen für nicht gesund halten mag… Sie selbst fühlen sich bestimmt nicht so. Jedenfalls nicht in dem Maße, wie ich sie einschätze.

Und ich fühle mich nicht ungesund, wenn ich mich heute nicht in der Lage sehe, aus dem Stand einen Marathon zu laufen. Ein passionierter Triathlet kann das jedoch anders sehen.

Wie viel Kompensationsfähigkeit ist also nötig? Im Wesentlichen nur so viel wie man meint zu brauchen. Der Mann oben im Bild hält sich vielleicht für gesund, weil er Drehkreuze und Flugzeuge vermeidet und zuhause bleibt, um keinen Autos ausweichen zu müssen. Er hat dann sein Leben so eingerichtet, dass Veränderungen/Anforderugen, die Sie und ich kompensieren könnten, an ihn gar nicht erst herangetragen werden.

Das halte ich für völlig legitim. Jeder ist da seiner Gesundheit Schmied.

Jetzt von der Analogie zurück zur Softwareproduktion.

Organisationen sind für mich auch Organismen, die gesund oder krank sein können. Deshalb reicht auch dort nicht die Frage, ob sich eine Organisation gerade wohl fühle, um den Gesundheitszustand zu beurteilen. Vielmehr ist zu fragen, inwiefern sie sich fähig sieht, Veränderungen zu kompensieren.

Die Antwort auf diese Frage hängt natürlich davon ab, welche potenziellen Veränderungen eine Organisation überhaupt sieht. Wo können denn Herausforderungen lauern? Was ist das Äquivalent einer unerwarteten Ansprache von hinten oder einem Bus hinterherlaufen zu müssen?

Ich glaube, Organisationen im Allgemeinen und Softwarehersteller im Besonderen haben davon eine nur recht schwammige Vorstellung. Man baut nicht gezielt Kompensationsfähigkeiten auf, sondern mokelt einfach vor sich hin. Hauptsache man verdient genug Geld. Damit lässt sich doch im Grunde alles kompensieren, oder?

Da bin ich anderer Meinung. Aber das möchte ich hier gar nicht vertiefen. Ich will vielmehr überlegen, wo denn die Veränderungsherausforderungen lauern könnten. Vor Augen habe ich dabei ein Softwareunternehmen, das vielleicht 20 Jahre am Markt ist. Das sagt, es gehe ihm gut. Und als Beleg wird nicht nur der aktuelle Umsatz angeführt, sondern auch das Unternehmensalter. Ist das denn nicht Beweis genug für Gesundheit?

Ich erlaube mir, anderer Meinung zu sein. Nur weil jemand vielleicht 80 Jahre alt ist und sich gerade gut fühlt, heißt das noch nicht, dass er gesund ist. Der einzige Nachweis für Gesundheit liegt in der Zukunft durch Meisterung deren Herausforderungen.

Insofern glaube ich, dass mache, einige, wahrscheinlich sogar viele Unternehmen etwas zu selbstsicher sind, was ihre Gesundheit angeht.

Was hätte Lehman Brothers wohl im Jahr 2007 zur eigenen Gesundheit gesagt? Der Aktienkurs – als ein akzeptierter Gesundheitsindikator – sah doch stabil aus.

Leider war man dann doch aber weniger kompensationsfähig, als man dachte, würde ich sagen. Man rekelte sich wie der Mann oben auf dem Bett – und konnte nicht auf das Feuer reagieren, das ausbrach – obwohl es auch noch mitverschuldet war.

Eine Organisation, die schon 20 Jahre lebt, hat natürlich einige Erfahrung gesammelt. Sie hat selbstverständlich Kompensationsfähigkeit bewiesen. Doch ich glaube, dass wir diese Fähigkeit zunehmend unterschätzen. Wir haben immer noch ein veraltetes Bild im Kopf, nämlich das einer relativ statischen Welt. Denn in der ist vergangener Erfolg Garant für zukünftigen Erfolg.

Es gibt zwei Wege, sich gesund zu definieren: Man baut Kompensationsfähigkeit aus – oder man korrigiert seine Ansprüche nach unten. Mir scheint letzteres in weiten Bereichen synonym mit Altern zu sein. Wer älter wird, meint, sich bestimmten Herausforderungen nicht mehr stellen zu müssen.

Das ist natürlich legitim.

Aber es funktioniert nur, wo man unter Kontrolle hat, welche Veränderungen man kompensieren muss.

Da scheint es mir gerade für Softwareunternehmen jedoch Grenzen zu geben. Man unterschätzt bei aller Erfahrung des Unternehmensalters, dass es zu Veränderungen kommen kann, ob man will oder nicht. Und man unterschätzt, wie groß die sein können. Manche hat man überhaupt nicht auf dem Schirm und wähnt sich in einer statischen Welt.

• Produktmarkt: Veränderungen in den Anforderungen an die Produkte lassen sich nicht kontrollieren. Kunden wollen immer mehr. Was sie wollen, ist letztlich nicht vorherzusehen. Wie schnell, mir wie viel Aufwand kann eine Organisation auf neue Anforderungen vom Markt reagieren? Nur weil man bisher ja auch irgendwie reagiert hat, heißt das nicht, dass man auch in Zukunft ökonomisch reagieren kann. Was wird also getan, um Kompensationsfähigkeit zu erhalten oder gar auszubauen?
• Technologien: Technologien ändern sich. Darauf muss reagiert werden können. Früher oder später. Wie einfach ist das möglich? Neue Technologien können Aufwände senken oder Märkte erhalten/erschließen. Was wird getan, um hier Kompensationsfähigkeit zu erhalten oder gar auszubauen?
• Personalmarkt: Weil sich Technologien entwickeln, entwickelt sich auch der Personalmarkt. Wie ist ein Unternehmen darauf vorbereitet, dass morgen die Fachkräfte die man heute braucht, nicht mehr zu finden sein werden? Was wird getan, um hier Kompensationsfähigkeit zu erhalten oder gar auszubauen?
• Codemenge: Völlig unterschätzt wird das Wachstum der Codemenge, gerade weil man Erfolg hat. Diese zwangsläufige Veränderung braucht Kompensationsfähigkeit ganz eigener Art. Wer heute mit 50.000 LOC umgehen kann, kann nicht unbedingt mit 500.000 LOC in gleicher weise ökonomisch umgehen. Was wird getan, um hier Kompensationsfähigkeit zu erhalten oder gar auszubauen?

Wer meint, in diesen und anderen Unternehmensgesundheitsdimensionen heute ausreichend oder gar mit Puffer kompensationsfähig zu sein, den beglückwünsche ich. Das ist wunderbar.

Doch auch dann bleibt noch eine Frage offen: Wie sieht es denn in der Zukunft aus? Ich halte es für sehr wichtig, Kompensationsfähigkeiten zu beobachten. Ich persönlich kann das z.B. täglich beim Treppensteigen. Wenn ich merke, dass ich kurzatmig werde, dann ist meine Kompensationsfähigkeit gesunken. Dann sollte ich gegensteuern – auf die eine oder andere Weise. Ich kann ins Erdgeschoss ziehen oder mit Fitnesstraining beginnen. Je nach Anspruch. Welcher meiner ist, können Sie sich denken ;-)

Aber weiß auch eine Organisation, wie sich ihre Kompensationsfähigkeit entwickelt? Kann sie überhaupt gegensteuern, wenn die Tendenz nach unten zeigt?

Davon hängt letztlich ab, ob ich zum Einsatz komme. Denn meine Aufgabe ist es, Kompensationsfähigkeit herzustellen bzw. aufzubauen. In Zukunft werde ich darauf noch mehr achten und schauen, in welchen Bereichen es einen Mangel an Kompensationsfähigkeit gibt – und inwiefern darüber Bewusstsein besteht. Denn wenn ich entgegen den gesundheitlichen Grundvorstellungen eines Unternehmens anfange, Kompensationsfähigkeit aufzubauen, wird es früher oder später zum Konflikt kommen – oder meine Bemühungen verpuffen. Das macht dann keiner Seite Spaß.