Was ist Zug?

Druck ist unökonomisch auf längere Sicht. Druck ist in den meisten Fällen kontraproduktiv. Der Schaden, den Druck erzeugt, besteht in Halden, die Kapital binden oder gar verbrennen, und in Verformungen von Ressourcen, die deren Leistungsfähigkeit schrittweise reduzieren. Darüber habe ich im vorherigen Posting geschrieben.

Bewegung in Richtung eines Ziels kann aber nicht nur durch Druck (push) stattfinden. Druck mag zwar naheliegen und eine lange Geschichte haben – aber es geht auch anders. Es geht auch mit Zug (pull).

Zug ist das Gegenteil von Druck. Aber woran kann man Zug erkennen, wie kann man Zug herstellen?

Ich glaube, Zug braucht nicht viel. Arbeit findet schon im pull-Modus statt wenn sie...

• …selbstbestimmt und…
• …auf ein selbstgewähltes Ziel ausgerichtet ist.

Das sind die primären Merkmale von Zug.

• Das Ziel sichert zu, dass ein Ergebnis entsteht.
• Selbstgewählt muss das Ziel sein, um Verformungen zu vermeiden. Wer nicht tut, was er möchte, wer nicht versteht, was er tun soll, der verbiegt sich auf Dauer. Das bedeutet natürlich nicht, niemand dürfte einem anderen ein Ziel vorschlagen. Mehr aber auch nicht. Ein Vorschlag ist ein Angebot, das man ablehnen kann. Eine Bitte äußert nur, wer auch ein Nein akzeptieren kann. Ohne Angebot, ohne Bitte findet jedoch keine Wahl statt; es gibt ja keine Entscheidungsfreiheit.
• Selbstbestimmt muss die Arbeit sein, um Verformungen zu vermeiden. Im Zug besteht Freiheit der Wahl im Hinblick auf Zeit, Ort, Mittel, um das Ziel zu erreichen. Dazu gehört natürlich auch, Begrenzungen dieser Selbstbestimmung zu akzeptieren.

Zug setzt also fundamental Wahl voraus. Wer keine Wahl hat, wem keine alternativen Optionen offenstehen, der gerät leicht unter Druck.

Bedeutet das aber Chaos? Nein. Lässt sich damit ein Unternehmen betreiben oder eine Software auf den Markt bringen? Ja. Das beweist nämlich jedes Unternehmen durch seine Existenz. Unternehmen sind per definitionem selbstbestimmte Einheiten, die ein selbstgewähltes Ziel verfolgen.

Unsere ganze Marktwirtschaft basiert auf Zug. Denn Nachfrage ist nichts anderes als Zug. Unternehmen reagieren auf Nachfrage mit Produktion. In der Marktwirtschaft gibt es keinen Druck. Der könnte zwar durch systemrelevante Größen entstehen, doch davor schützen (weitgehend) Regulierungsmaßnahmen.

Das Gegenteil hat man im Kommunismus versucht. Dort herrschte Druck. Dort wurde Produktion verordnet und Konsum quasi erzwungen. Unternehmerische Selbstbestimmung gab es nur in Ausnahmefällen. Die historische Quittung für einen solchen Versuch der Steuerung über Druck ist ausgestellt. Es hat nicht funktioniert. Historisch gesehen ist der Kommunismus mit seiner Planwirtschaft ein Experiment von kurzer Dauer gewesen.

Was im Großen wunderbar funktioniert und kein Unternehmer und auch kein Manager missen möchte, soll nun im Kleinen, d.h. Unternehmen nicht funktionieren. Viel, viel einfachere Gebilde als eine Nation oder auch die ganze Welt sollen mit Zug nicht erfolgreich sein können? Das kann ich nicht glauben.

Zugegeben, mit Druck Ziele zu erreichen, ist zunächst einfacher. Aber ist es auf Dauer erfolgreicher? Ist es erfolgreicher für ein Unternehmen? Ist es erfolgreicher für die Gesellschaft? Ich glaube weder das eine noch das andere.

Selbstbestimmte Arbeit auf selbstgewählte Ziele führt nicht ins Chaos. Sie ist vielmehr die Bedingung für die Möglichkeit von mehr Flexibilität, Reaktionsschnelligkeit, Innovationsfähigkeit und Freude.

Denn wer sagt, dass selbstbestimmte Projektbeteiligte nicht dasselbe wollen können? Wer sagt, dass die nicht kohärent und konsequent auf dasselbe Ziel hin arbeiten können?

Selbstbestimmung und Entscheidungsfreiheit bedeuten nicht, dass es keine Einschränkungen geben darf. Sich die nächsten 3 Jahre auf die Entwicklung eines CRM-Systems zu konzentrieren, sich auf die Nutzung von Java und Eclipse zu beschränken, alle Arbeit im Büro zu verrichten, sich bei der Arbeit durch zugerufene Aufträge unterbrechen lassen… all das ist mit Selbstbestimmung und Entscheidungsfreiheit vereinbar. Es ist sogar mit ihr vereinbar, den Weisungen von jemandem anderen zu folgen.

Das alles schränkt Selbstbestimmung und Entscheidungsfreiheit nicht ein, solange es immer wieder in Frage gestellt werden darf. Solange Beschränkungen freiwillig sind und nicht die Reflexion über sie inklusive Möglichkeit zur Veränderung aushebeln, sind sie Mittel, die der Erreichung des Zieles dienen können.

Manche Mittel mögen dabei träger sein als andere. Unternehmensstandort oder Geschäftsmodell stehen eher weniger häufig zur Disposition als Arbeitszeit oder Entwicklungsplattform. Letztlich sollte es jedoch kein Tabu geben.

Umgekehrt bedeutet das, je mehr Beschränkungen es gibt, je größer Tabuzonen, je seltener und enger die Reflexion, desto geringer Selbstbestimmung und damit auch Zug.

Und wie soll nun ein Unternehmen seine Ziele erreichen können, wenn seine grundsätzliche interne Funktionsweise die einer Marktwirtschaft ist? In Prozessen. Wie denn sonst? Das funktioniert doch auch im Großen. Wo bedarf ist, bilden sich Prozesse, die Rohstoffe in Produkte umwandeln.

Sie haben Strom, Wasser, ein Dach über dem Kopf, einen überquellenden Supermarkt, ein Auto, einen Computer, Bücher… Sie leben nicht “von der Hand in den Mund”, d.h. ohne Prozesse. Sie sind vielmehr Endpunkte und Bestandteile eines komplexen Prozessnetzwerks.

Für ein Papierbuch greifen Holzproduktion, Papierproduktion, Druck, Vertrieb, Buchhandel ineinander, um Ihnen den Gegenstand in die Hand zu bringen. Damit der auch noch einen Inhalt hat – sonst hätten Sie das Buch kaum nachgefragt –, stößt von der Seite ein zweiter Prozesse beim Druck dazu. Da greifen Autor, Lektor, Layout ineinander.

Alle arbeiten autonom. Überall herrscht Zug [1]. Und das Ganze funktioniert. Es gibt keinen Mangel an Büchern.

Warum nun sollte die Arbeit in selbstorganisierten Prozessen innerhalb (!) von Unternehmen nicht funktionieren? Unternehmen, die so nicht arbeiten können, d.h. wollen, und behaupten, das ginge nicht, sind für mich keine Experten. Würden wir denen glauben, hätten wir auch keine Eisenbahn. Denn Reit-Experten hatten vor deren Erfindung vorausgesagt, dass der Mensch bei größerer als Galoppgeschwindigkeit schlicht ersticken würde.

Damit selbstbestimmte Einheiten in Prozessen nicht unter Druck geraten, muss allerdings noch eine Voraussetzung geschaffen werden. Die Einheiten müssen entkoppelt sein. Ohne Entkopplung keine Autonomie.

Das Mittel zur Entkopplung sind Warteschlangen. Der Materialfluss zwischen Prozessschritten ist also nicht synchron, sondern asynchron. Eine upstream Einheit darf der folgenden Einheit nichts diktieren. Es gibt nicht einmal einen direkten Kontakt zwischen beiden Einheiten. Zwischen ihnen steht vielmehr eine Warteschlange oder allgemeiner ein Puffer.

Upstream Einheiten schieben ihre Erzeugnisse lediglich in Puffer. Auf die dürfen sie Druck ausüben. Das sichert auch ihnen Autonomie zu.

Downstream Einheiten entnehmen aus ihnen vorgelagerten Puffern das Material, an dem sie arbeiten wollen. Wann sie wollen. Das sichert ihnen Autonomie zu.

In den Prozessen der Marktwirtschaft gibt es überall diese Puffer. Der Holzproduzent kann einen solchen Puffer haben: das sind Stapel geschlagenen Holzes im Wald. Der Papierproduzent kann einen solchen Puffer im Eingang haben – er lagert eingekauftes Holz bis zur Verarbeitung – und/oder im Ausgang – er lagert produziertes Papier bis zum Verkauf. Der Drucker hat auch einen solchen Puffer im Eingang usw.

Es gibt sogar Marktteilnehmer, die das Puffern zu ihrem Geschäft gemacht haben: Grossisten, Logistiker, Supermärkte…

Dass es in der Marktwirtschaft einen Trend zu kleineren Puffern und zu mehr just-in-time Produktion gibt, widerspricht nicht dem pull-Prinzip. Selbst wenn es keine Puffer mehr gäbe, weil alles ad hoc JIT produziert und geliefert werden könnte, würde immer noch ausschließlich nach Bedarf produziert. Das bedeutet, es würde nur auf Zug produziert [2].

Dass selbstbestimmte Einheiten entkoppelt durch Warteschlangen in Prozessen erfolgreich arbeiten, ist natürlich kein Selbstgänger. (Dass Einheiten unter Druck erfolgreich arbeiten, aber auch nicht.)

Mehrerlei ist ständig zu beobachten:

• Sind die Prozesse und die Produktionseinheiten auf das Ziel ausgerichtet (Kohärenz, Alignment)?
• Wie sind die Puffer dimensioniert und ausgelastet? 
• Wie sind die Kapazitäten der Produktionseinheiten dimensioniert und ausgenutzt?
• Wie sind die Kapazitäten der Produktionseinheiten auf einander abgestimmt?

An all diesen Parametern kann und muss man schrauben für ein optimales Ganzes.

Aber das ist der Trick: Es geht um ein optimales Ganzes und nicht einheitenbezogene Optimierung. Und es steht vor allem eines nicht zur Debatte: die Autonomie der Produktionseinheiten. Deren Aufgabe ist schlicht, ihre Kapazität auf die Entnahme von Material aus Puffern, dessen Transformation und die Übertragung von Resultaten in Puffer zu konzentrieren.

Aus Puffern arbeiten für Puffer. Darum geht es. Alles daran geschieht in Selbstbestimmung – aber nicht auf Kosten des Ganzen. Dafür wird durch periodische Reflexion gesorgt. Dafür sorgen aber auch Puffer- und Kapazitätsbegrenzungen. Ultimativ ergeben die sich aus dem Markt für den die Prozesse produzieren. Dessen Begrenzungen wirken zurück auf den Prozess. Sie üben “back pressure” aus, dem sich die Dimensionierungen von Puffern und Produktionseinheiten nicht dauerhaft entziehen können.

Aber auch wenn hier Druck ins Spiel kommt, widerspricht das nicht dem Prinzip der Produktion im Zug. Im Gegenteil! Dem Druck von außen kann am ehesten entsprochen werden, wenn intern die Organisation möglichst flüssig ist. Und das ist sie, wenn sie aus lose gekoppelten autonomen Einheiten besteht. Der Beweis kommt wieder aus der Marktwirtschaft. Wenn sie sich nicht als flexibel, ja geradezu antifragil erwiesen hat, was dann?

Nochmal zum Abschluss:

Zug herrscht umso mehr, je selbstbestimmter entkoppelte Produktionseinheiten in einem Prozess auf ein Ziel ausgerichtet sind.

Inwiefern das bei Ihnen der Fall ist, können Sie ja mal überlegen. Wie selbstbestimmt fühlen Sie sich in Ihrer Arbeit? Welche Begrenzungen gibt es, wieviele davon dürfen Sie hinterfragen oder gar aufheben? Findet Hinterfragen (Reflexion) statt? Was sind die Ziele Ihrer Arbeit? Wieviele und auf welcher Ebene davon sind wirklich Ihre eigenen? Wie klar sind die Prozesse zur Erreichung dieser Ziele? Gibt es Puffer, wie sichtbar sind sie? Haben die Puffer eine definierte Kapazität? Geschieht der Materialfluss ausschließlich über Puffer und in Autonomie?

 

PS: Ich habe mir selbst auch diese Fragen gestellt. Die Antworten waren ernüchternd. Als Selbstständiger arbeite ich natürlich grundsätzlich autonom. Aber ich habe mich selbst unter Druck setzen lassen, indem ich Puffer abgebaut habe. Das Ergebnis: Ich habe wichtige Aufgaben nicht verlässlich erledigt. Bedient wurde vor allem das Dringende.

Darauf habe ich nun reagiert. Ich habe alle Notifikationen abgestellt. Ich lasse mich nicht mehr unterbrechen, nicht von Email, nicht von Twitter, Facebook, einem Newsreader, SMS oder Telefon [3]. Alle Informationen, die zu mir fließen, fließen in Puffer. Aus denen Bediene ich mich, wenn ich Lust oder Bedarf habe. So schütze ich meine Autonomie.

Das bedingt natürlich, dass ich diese Puffer auch tatsächlich prüfe, um für meine Umwelt verlässlich zu sein. Doch das ist eben meine selbstgewählte Aufgabe. Wenn ich Beziehungen haben will – berufliche wie private –, dann muss ich mich um deren Input kümmern. Das bedeutet jedoch nicht, dass ich mich von ihm bestimmen lasse. Ich kümmere mich, wann ich will – mit allen Konsequenzen.

Endnoten

[1] Zug herrscht selbstverständlich im Herstellungsprozess des physischen Buches. Die Beteiligten sind Unternehmen. Zug herrscht auch zwischen Lektor und Autor. Lektor und Layout und Vertrieb sitzen traditionell jedoch in einem Verlag. Der mag als Unternehmen intern noch über Druck organisiert sein. Das vernachlässige ich hier aber einmal. Es geht ja auch anders, wie freie Lektoren und freie Layouter beweisen. In Zukunft wird sich auch gerade hier einiges durch die Möglichkeiten des self-publishing verändern. Autoren sind nicht mehr auf Verlage angewiesen. Die Buchveröffentlichungskompetenz der Verlage schrumpft damit auf ihren Vertrieb bzw. ihre Reichweite zur Sichtbarmachung von Titeln zusammen.

[2] Ein Merkmal von Druck sind Halten. Was ist der Unterschied zwischen einer Warteschlage bzw. einem Puffer und einer Halde? Halden sind ungewollte Puffer. Halden entstehen, wo die Kapazität von Puffern überschritten wird. Das geschieht natürlich sofort, wo die Puffergröße 0 ist und angeliefertes Material (oder ein Auftrag) nicht sofort verarbeitet wird.

Wo das Material im Fluss wenig materiell ist – hört sich nach einem Gegensatz an, oder? ;-) -, also bei “Knowledgeprozessen” wie der Softwareentwicklung, sind Halden allerdings selten sichtbar. Sie sind nicht sichtbar, weil es sie scheinbar nicht gibt. Man lässt neue Aufgaben sich einfach nicht irgendwo zwischen Produktionsschritten auftürmen, sondern nimmt sie an. Man tut so, als würde man sofort mit der Verarbeitung beginnen. Der Wille dazu mag auch da sein – nur die Kapazität ist es oft nicht. Denn mit jeder weiteren angenommenen, aber noch nicht abgeschlossenen Aufgabe sinkt die Kapazität zur Bewältigung einer Aufgabe. Dazu kommen “Umschaltkosten” für den Wechsel zwischen Aufgaben.

Das Ergebnis ist Unzuverlässigkeit der Produktionseinheit. Aber da keine Halde sichtbar ist, da noch nicht einmal sichtbar ist, wieviele Aufgaben gerade in Arbeit sind, ist die Unzuverlässigkeit immer wieder ein Mysterium – dem man mit mehr Druck versucht Herr zu werden.

[3] Nur noch für Privates lasse ich mich durch Whatsapp unterbrechen.

Was ist Druck?

Zug ist ökonomischer als Druck. Davon bin ich überzeugt. Aber was ist denn Zug? Wie kann man Zug (pull) von Druck (push) unterscheiden? Die Antwort bin ich noch Kommentator Mike M schuldig.

Bisher schien es mir einfach, Zug zu erkennen. Liegt der denn nicht auf der Hand, wenn er vorhanden ist? Aber Mikes Nachfrage hat mich widererwarten ein bisschen ins Schwitzen gebracht. “Ich erkenne ihn, wenn ich ihn sehe” ist zu wenig. Also: Was ist Zug?

Um das zu beantworten, ist erstmal zu klären, was Druck ist. Zug ist ja nicht nur die Abwesenheit von Druck, sondern das Gegenteil. Das habe ich ja auch mit der kleinen Bilderserien hier verdeutlichen wollen. Ein anderes Beispiel, das mir später eingefallen ist: der Umgang mit Anhängern.

Stellen Sie sich vor, diese Anhänger nicht zu ziehen, sondern zu schieben. Das geht nicht. Das geht zumindest nicht, solange sie so flexibel gekoppelt sind.

Anders ist das bei einem Zug. Da ist der Name zwar normalerweise Programm: bei einem Zug wird mit einer Zugmaschine gezogen wie bei einem LKW-Gespann. Aber bei einem Zug können Waggons auch geschoben werden. Das Bild lässt also nicht erkennen, in welche Richtung der Zug gerade fährt.

Einen Zug über Druck zu bewegen – klingt widersprüchlich, oder? - ist trotz der relativ flexiblen Kopplung der Waggons möglich, weil die auf Schienen laufen. Das Gespann kann sich beim Druck nicht verziehen.

Womit wir bei der Definition von Druck wären. Wikipedia sagt:

“Der Druck ist ein Maß für den Widerstand, den Materie einer Verkleinerung des zur Verfügung stehenden Raumes entgegensetzt.”

Das versuche ich mal zu übersetzen und zu verallgemeinern, damit der Begriff Druck auch auf nicht-physikalische Systeme anwendbar ist:

Druck entsteht, wenn mehr Leistung bei gleicher oder reduzierter Optionenzahl erbracht werden soll.

Beispiel 1: Eine Maschine in einem Herstellungsprozess kann 4 Teile pro Minute verarbeiten. Bisher wurden ihr diese 4 Teile auch geliefert. Aber nun hat man entschieden, den Prozess upstream zu optimieren und es werden zukünftig 6 Teile pro Minute angeliefert. Die Maschine gerät damit unter Druck.

Beispiel 2: Das Entwicklungsteam hat sich für die Woche 4 User Stories vorgenommen. Am Donnerstag kommt der Geschäftsführer aber herein und sagt, er brauche ganz dringend noch eine Einschätzung zu einer Ausschreibung, an der man sich beteiligen wolle. Dafür seien 200 Seiten bis Freitag Mittag durchzuarbeiten und einzuschätzen. Das Team gerät damit unter Druck.

Druck entsteht in beiden Fällen, weil von einer Ressource mehr erwartet wird, ohne dass ihre Kapazität erhöht würde. Eine Maschine kann darauf gar nicht von sich aus reagieren; die ist emotionslos. Der Druck zeigt sich in einer wachsenden Warteschlange/Halde vor der Maschine. In einem Prozess stellt sie die Verformung dar, die wir in der physischen Welt so leicht als Zeichen von Druck erkennen.

Bei Menschen ist das anders. Die sind grundsätzlich autonom und können entscheiden, wie sie mit höherer Leistungsforderung umgehen. Deshalb ist es oft auch schwierig, Druck zu erkennen.

Die Industrie ist inzwischen sensibilisiert. Die Lean-Bewegung hat Druck als Problem und Warteschlangen als Symptom erkannt. Toyota hat demonstriert, welchen Gewinn es bringt, von Druck auf Zug umzustellen.

Ansonsten aber… entweder macht man sich keine Gedanken oder man hält Druck für unvermeidbar oder man findet ihn sogar wünschenswert. Warum auch nicht? Druck kann doch auch sexy sein, oder?

Nein, Druck ist nicht sexy. Bis zu einem gewissen Grad ist er natürlich, unvermeidbar und auch nicht schädlich, nein, sogar bekömmlich. Aber sorgloser Umgang mit Druck, Druck als Standardmittel zur Ergebniserzielung, das ist kontraproduktiv.

In Beispiel 2 entsteht Druck entweder durch die unausgesprochene Annahme, dass das Team nicht nur seine 4 User Stories erledigen, sondern auch noch das Dokument durcharbeiten wird. Oder er entsteht, weil das Team nicht glaubt, die Arbeit an den User Stories zugunsten des Dokumentes herunterfahren zu dürfen.

Ob die Zahl der Optionen tatsächlich eingeschränkt wird oder die leistende Ressource das nur so wahrnimmt, ist nicht ausgemacht und auch egal. Entscheidend ist das Gefühl von Druck.

Problematisch ist nun, wozu dieses Gefühl von Druck führt: zu Verformungen.

Menschliche Ressourcen verbiegen sich, um den höheren Anforderungen gerecht zu werden. Das wird auch als ganz normal angesehen. “Dienst nach Vorschrift” ist verpönt. Der ist nämlich Ausdruck von “Unverbiegbarkeit” [1].

Verformungen bei Menschen sind z.B.:

• Überstunden, d.h. länger arbeiten
• Erhöhung der Leistung, d.h. schneller arbeiten
• Isolation, d.h. selbstbezogener arbeiten
• Absenkung des Qualitätsanspruchs, d.h. weniger sorgfältig arbeiten

Diese Verformungen sind hoffähig oder gar erwünscht (z.B. Überstunden), teilweise sind sie aber auch nur schwer oder spät erkennbar (z.B. reduzierte Qualität). In jedem Fall führen sie auf Dauer zu Demotivation oder Schlimmerem [2]. Wer Druck sorglos einsetzt läuft Gefahr, Kosten durch eines der großen K´s zu erzeugen: Kündigung, Krankheit, Keine Lust, Kundenverlust.

Das mag dem Druckausübenden im Moment egal sein, so wie es einem upstream Produktionsschritt egal sein mag, vor einem downstream Schritt eine Halde zu erzeugen. Aufs Ganze gesehen ist es jedoch kontraproduktiv und teuer. Am Ende verdient eine Organisation ihr Geld ja nicht mit lokaler Optimierung, sondern als optimales Ganzes.

Lokale Optimierung hat immer einen begrenzten Horizont. Ihr Bezugspunkt sind daher vor allem Kosten. Ob lokal mehr Output wirklich zu einem besseren Ergebnis (Durchsatz, Ertrag) der gesamten Organisation führt, kann lokal nicht ermessen werden.

Und die Summe lokaler Optimierungen ist nicht automatisch ein optimales Ganzes.

Eine Maschine kann nur 4 Teile pro Minute verarbeiten, sie ist in dieser Hinsicht unverformbar. Also stauen sich Teile, die darüber hinaus angeliefert werden, vor der Maschine. Das ist das Ergebnis einer höheren Leistungsanforderung (6 statt 4 angelieferte Teile pro Minute) bei gleicher Optionenzahl (unveränderte Kapazität der Maschine).

Ein Team kann 4 User Stories pro Woche verarbeiten. Wenn eine weitere Leistungsanforderung auftritt, dann sind die Zahl der Optionen. Man darf nicht mehr soviele Fehler machen wie bei der ursprünglichen Planung einkalkuliert. Man darf nicht mehr soviel Freizeit haben, wie im Vertrag steht. Man darf sich die Zeit weniger frei einteilen, wie ursprünglich angenommen.

Das gilt umso mehr, je höher die ursprüngliche Auslastung war. Wenn 4 User Stories bedeutet hätten, das Team arbeitet jeden Tag nur 4 Stunden und spielt ansonsten am Kicker, dann würde das zusätzlich zu lesende Dokument keinen Druck erzeugen. (Klar, die Freiheit, sich zwischen Kicker und Arbeit zu entscheiden, würde abnehmen. Aber da Kicker spielen nicht der Zweck des Teams in der Organisation ist, halte ich das für vernachlässigbar ;-)

Teams, die nicht (nahezu) voll ausgelastet sind, kenne ich jedoch nicht. Deshalb erzeugen Änderungen an der geforderten Leistung oder gar Forderungen nach mehr Leistung unmittelbar Druck.

Das kann mit einer Autobahn verglichen werden. Wenn die nachts nur schwach befahren ist, kommt es durch zusätzlich auffahrende Fahrzeuge oder Unfälle kaum zu Behinderungen. Wenn die Autobahn in der Rush Hour jedoch ausgelastet ist, dann führt zusätzliche Last oder eine unerwartete Reduktion der Kapazität zu Staus oder sogar echten Autohalden bei Unfällen.

Druck ist allemal auf Dauer also nicht ökonomisch. Er ist lokal leicht zu erzeugen und führt lokal und kurzzeitig vielleicht auch zu einem Erfolg. Aufs Ganze gesehen jedoch ist Druck kontraproduktiv.

Endnoten

[1] “Dienst nach Vorschrift” ist natürlich kontraproduktiv. Da fehlen Respekt und Flexibilität. Beides ist nötig in Organisationen, weil es erstens um Menschen geht und zweitens sich menschliche Prozesse nicht optimal formalisieren lassen.

Dennoch finde ich es überlegenswert, inwiefern etwas mehr “Dienst nach Vorschrift” nicht auch heilsam für Organisationen sein kann. Denn dann kann es zu Haldenbildung wie in Industrieprozessen kommen. Damit gibt es dann sichtbare Ansatzpunkte für die Optimierung aufs Ganze hin.

[2] Menschen sind unterschiedlich belastbar. Wie stark sie sich verformen lassen oder können, wie schnell und weit sie anschließend auch wieder “back to normal” kommen… das ist ganz verschieden. In jedem Fall ist ihre Elastizität begrenzt. Bei ständigem Druck nimmt sie ab. Auch Menschen leiern sozusagen aus, werden schlaff – oder verhärten.

Vergleich von Flow-Designs für Kata Ordered Jobs

So unterschiedlich können Flow-Designs sein. Ich hatte es schon geahnt, doch nun ist es öffentlich.

Am 1.11.2013 hatte ich ermuntert, Flow-Designs für die Kata Ordered Jobs “einzureichen”. Auslöser dahinter war ein Flow-Design, dass Entwickler eines Kunden von mir in einem Coding Dojo unter sich erarbeitet hatten. Sie wollten einfach Flow-Design üben. Das sah so aus, als sie mich schließlich um Rat fragten:

Was mich daran überraschte: Dem Lösungsansatz ist nicht anzusehen, um welches Problem es eigentlich geht. “Process”, “Release”, “Save”, “Output” sind ganz allgemeine Begriffe. Auch der fließende “Job” erhellt nicht wirklich, wie (!) die Lösung funktioniert. Die Musik spielt in “Process” – aber genau die Funktionseinheit wurde nicht verfeinert.

Ob das auch anderen Interessenten an Flow-Design so geht/gehen würde? Das wäre schade, denn ich glaube, so führt Flow-Design zu keiner großen Verbesserung der Verständlichkeit und Evolvierbarkeit von Software.

Es ist ja gerade der Trick an Flows, dass bei ihnen die Syntax so minimal ist, dass sie eine Domänensemantik nicht verrauscht.

Fünf “Einsendungen” hat es dann auf meinen Aufruf hin gegeben. Vielen Dank an die fleißigen Entwerfer! Die möchte ich hier allerdings nicht in ihrer Funktionstauglichkeit bewerten, sondern nur formal gegenüberstellen. Wie sich zeigt, gibt es nämlich mehrere Aspekte, in denen sie sich unterscheiden.

Darstellung

Flow-Design setzt auf… Flüsse. Der Name ist Programm. Die können handgemalt sein wie oben oder in einem Tool wie Visio ordentlich “gesetzt” werden:

Überrascht hat mich daher die folgende Darstellung:

Aber nicht wegen der “squiggly lines” bin ich überrascht, sondern wegen der Gewichtung der Darstellung. Hier sind zwar auch Pfeile im Spiel und stehen für Datenflüsse. Doch prominenter scheinen mit die Abhängigkeiten. Da ist ein DGraph von mehreren Flow-Funktionseinheiten abhängig. Oder? Nein, umgekehrt. Jetzt sehe ich es: Die Funktionseinheiten sind vom DGraph abhängig. Ich war nur einen Moment verwirrt, weil die Abhängigkeiten von unten nach oben zeigen. Das ist eher ungewöhnlich (in Flow-Designs allemal), finde ich.

Im oberen Entwurf gibt es auch eine Abhängigkeit (zu “nextOrderNumber”). Doch die ist zurückhaltender dargestellt; sie steht dem Fluss nicht im Weg.

Die Darstellung bzw. Gewichtung von Abhängigkeiten unterscheidet sich also in Flow-Designs durchaus. Das ist bis zu einem gewissen Grad auch ok, finde ich. Doch wenn die Abhängigkeiten scheinbar die Oberhand gewinnen, wenn der Fluss nicht mehr im Vordergrund steht, dann finde ich einen Vorteil von Flow-Design verschenkt.

Detaillierungsgrad

Wie das erste Diagramm zeigt, können Flow-Designs sehr unspezifisch sein. “Process” passt auf nahezu jedes Problem. Ähnlich empfinde ich aber auch noch bei “Sort” im dritten Diagramm – zumindest solange dann nicht weiter verfeinert wird. So bleibt die Lösung im Dunkeln; die Last liegt voll auf der Codierung und ist damit die Verantwortlichkeit nur eines Entwicklers.

Dito im folgenden Entwurf, wo noch klarer wird, dass die Aufgabe eigentlich nicht vom Flow, sondern von der Datenstruktur DGraph gelöst wird. So eine Datenstruktur samt Algorithmus zur topologischen Sortierung “einzukaufen”, ist natürlich legitim. In der Praxis würde man es womöglich sogar anstreben, um sich eigenen Aufwand zu sparen. Doch das funktioniert natürlich nur, wenn es eine Lösung “einzukaufen” gibt. Und hier war es an der Aufgabe vorbei, da es ja gerade darum ging, selbst einen Lösungsansatz zu formulieren.

Andererseits können Flows natürluch auch sehr detailliert sein:

In diesem und weiteren Flows der “Einreichung” wird der Algorithmus genau beschrieben. Jede Funktionseinheit wird mit 2-3 Zeilen Code umsetzbar sein, schätze ich. Für mich ist das sogar zu detailliert, zumindest für die Implementierung. Bei Entwurf mag man mal so tief einsinken… doch dann würde ich wieder einige Ebenen nach oben steigen beim Codieren. Nicht für jede Funktionseinheit lohnt wirklich eine eigene Funktion.

Lösungen können also zu grob sein, dann helfen sie nicht wirklich. Andererseits können sie auch zu detailliert sein, dann fangen sie an zu rauschen. Die Kunst besteht mithin darin, eine angemessene mittlere Granularität zu finden. Die ist natürlich ein Stück subjektiv und erfahrungsabhängig ;-)

Abstraktion

Flows entwerfen, ist etwas anderes als zu codieren. Es geht um Abstraktion von den Niederungen der textuellen Programmiersprachen. Nur dadurch gewinnt der Entwurf Geschwindigkeit und Überblickscharakter. Es geht darum, eine Karte zu schaffen, nicht eine (Miniatur)Landschaft zu herzustellen.

Auch hier gilt es, die Balance zu finden. Am einen Ende des Spektrums ist der Globus, d.h. eine sehr grobe Karte, die alles zeigt. Das ist völlig ok, nein, unumgänglich – sollte nur nicht wie im vorletzten Diagramm dabei bleiben. Die schrittweisen Verfeinerungen, die auch im Code erhalten werden können und sollen, machen das Flow-Design aus.

In die falsche Richtung geht es aus meiner Sicht jedoch, wenn sich in die Karten Artefakte aus dem Terrain einschleichen. Das ist der Fall, wenn der Fluss nicht mehr deklarativ ist, sondern imperativ wird. Das ist hier z.B. der Fall:

Ein “ForEach” ist beim Flow-Design fehl am Platze; der Begriff steht erstens für eine explizite Kontrollanweisung, wo es doch um Datenflüsse geht, und zweitens ist er frei von jedem Domänenbezug.

Dicht darauf folgen Schleifen jeder Art, z.B.

Sie lassen sich einfach nicht mit dem Integration Operation Segregation Principle (IOSP) in der Implementation mit 3GL vereinbaren.

Ein Flow-Designs beschreiben Datenflüsse, dazu gehören mindestens zwei Punkte, um eine Strecke für den Fluss abzustecken und ihm eine Richtung zu geben. Andererseits dürfen die Flüsse aber auch nicht umkippen und zu Kontrollflüssen degenerieren. Abstraktion im Entwurf bedeutet also, soweit wie möglich eine deklarative Domänensprache zur Lösung eines Problems zu finden.

Anforderungstreue

Überrascht hat mich schließlich auch die Kreativität der Lösungen. Die Vorgaben waren ja klar. Es galt, ein Interface zu implementieren.

Doch das hat nicht in allen Lösungen dazu geführt, auch dieses Interface sichtbar zu machen. Manchmal wurde aus dem geforderten Register() nur ein AddJob(). Manchmal war solch eine Funktionalität aber auch gar nicht zu sehen:

Am anderen Ende des Spektrums dann wieder eine recht treue Abbildung der Anforderung:

Kreativität ist bei der Findung eines Lösungsansatzes selbstverständlich wichtig. Allerdings sollte sie sich dort austoben, wo die Anforderungen notwendig Lücken haben. Das, was der Kunde beschreibt, das, was klar erkennbar ist, sollte hingegen treu übernommen werden. Sonst leidet die Verständlichkeit. Man bedenke immer den anderen Entwickler oder sich selbst in der Zukunft. Da wird dann U in den Anforderungen gelesen, aber im Entwurf ist ein X zu sehen…

Ich weiß, das ist manchmal schwer. Da hat man seine Coding-Standards. Da wallt die Erfahrung in einem auf. Das will alles berücksichtigt werden. Doch ich glaube, wir tun gut daran, uns solchen Regungen nicht gleich hinzugeben. Etwas Disziplin in der Beschränkung der Kreativität hilft der Verständlichkeit.

Fazit

Dass die Entwürfe so weit auseinander gehen, hätte ich doch nicht gedacht. Auch mit den überschaubaren Mitteln des Flow-Design ist also große Bandbreite möglich. Einerseits schön – andererseits aber auch wieder eine ernüchternd. Die guten alten Tugenden Maßhaltung und Genauigkeit und Fokussierung gelten auch im Flow-Design.

Mir hat der Vergleich der Entwürfe sehr geholfen. Und ich hoffe, dass es Ihnen ein bisschen auch so geht.

Bitte raustreten für besseren Fluss

Am Flughafen kann man lernen, Fluss herzustellen. So geschehen, als ich gestern von Hamburg nach Köln geflogen bin. Und gleich wird es wohl wieder geschehen, wenn ich zurückfliege.

Beim Boarding sollen ja in kürzester Zeit hunderte Passagiere durch ein Nadelöhr in die Maschine fließen. Da Nadelöhr ist die Prüfung der Bordkarte. Heute passiert das durch assistiertes Scannen.

Je Fluggast dauert das 4-5 Sekunden, schätze ich mal. Von Durchgehen kann da keine Rede sein. Und so entsteht ein ausgewachsener Stau vor den Scannern.

Das ist ok, die Passagiere murren nicht. Man fließt zwar nicht schnell, aber man fließt. Es ist absehbar, wann man drankommt, weil es vorwärts geht. Dafür sorgt das Flugsteigpersonal auch, indem es Variationen in der Durchschleusungsdauer von vornherein bedenkt. Menschen, die langsamer sind (Ältere, Behinderte, Kinder), werden gesondert zu Beginn durchgeschleust. Für die ist die Bearbeitungszeit länger oder gar unbestimmt lang, jenachdem, welche Hilfe sie benötigen. Damit will man den Fluss der Masse nicht aufhalten. Ein guter Gedanke.

Trotz dieser Maßnahme kann es jedoch passieren, dass die Prüfung bei den restlichen Passagieren unterschiedlich lange dauert. Mal 3 Sekunden, mal 6 Sekunden. Aber das ist ok. Die Variationen halten sich in Grenzen. Fluss entsteht.

Bis, ja, bis es zu einem Sonderfall kommt. Da rückt ein Passagier vor, der immer noch nicht seine Bordkarte gefunden hat. Da steht plötzlich ein Passagier am Scanner, der auf dem Smartphone seine Bordkarte nicht findet. Oder was auch immer. Es kann passieren, dass die Verarbeitungszeit für plötzlich und unerwartet stark ansteigt. Der langsame, jedoch stetige Fluss kommt zum Erliegen. Nach spätestens 20 Sekunden wir Murren laut. Köpfe recken sich. Was ist da los?

Solche Sonderfälle kann man nicht vermeiden. Trotz Vorsichtsmaßnahmen, trotz weitgehend homogenen Aufwands kann es immer zu Ausreißern kommen. Und das merkt man erst, wenn man die Verarbeitung schon begonnen hat. Was dann?

Bis zu einer gewissen Grenze muss das keine besondere Konsequenz haben. Shit happens. Also bleibt man ruhig und gibt dem Fluggast 10 Sekunden, um sich zu sortieren. Oder 12 Sekunden. Danach geht es wieder flüssig wie erwartet weiter.

Jenseits dieser Grenze jedoch, ist es klug, Maßnahmen zu ergreifen. Dann ist es klug, den "Störenfried" auszusondern. Raus mit ihm aus dem normalen Verarbeitungsfluss! Er muss den Weg freimachen für die anderen. Wer seine Bordkarte sucht, muss dafür nicht beim Scanner stehen. "Bitte treten Sie zur Seite!" Dort hat man dann alle Zeit der Welt oder kann sogar Hilfe in Anspruch nehmen.

Und genauso sollte es im Fluss der Softwareentwicklung sein. Um eine Homogenisierung der Größe von Features/User Stories sollte man sich bemühen. Dann kann Fluss entstehen. Für mich liegt diese Größe im Bereich von 0,5 bis 2 Tagen.

Bei aller Mühe gibt es jedoch keine Garantie, dass die Features/User Stories dann aber auch wirklich nur diesen Aufwand benötigen. Es kann mal schneller gehen - sehr schön, aber wohl eher selten. Es kann mal langsamer gehen - macht nichts, solange es im Rahmen ist. Dieser Rahmen ist vielleicht 0,5 Tage bei einer Aufgabe von geschätzten 2 Tagen.

Wird der Variationspuffer jedoch überschritten, gilt es, eine Konsequenz zu ziehen. Die lautet für mich: Raus aus dem Fluss!

Wenn eine Blockade auftritt, sollte das Feature/die User Story nicht einfach im Fluss belassen werden, um dort an ihr herumzudoktern. Stattdessen gilt es, den Weg für andere zu machen. Dann kann man abseits überlegen, wie das Problem gelöst werden kann.

Wer mit einem Taskboard arbeitet (oder einem Kanban-Brett), der sollte dafür eine eigene Schwimmbahn "Notaufnahme" oder so vorsehen. (Genauso, wie es eine für "Forschungsaufgaben" geben sollte.)

Dann wird deutlich, wo Hilfe nötig ist, ohne den Fluss zu behindern. Dann kann auch eine Repriorisierung stattfinden: Ist es jetzt wichtig, auf diesen Sonderfall weitere Ressourcen zu werfen? Oder ist es wichtig, andere Features/User Stories am Fließen zu halten?

Solange so ein Sonderfall einfach nur einen Platz des WIP-Limits im Hauptfluss belegt, stört er das ganze System. Klar, dann würde dieses Vorkommnis in einem CFD irgendwann zu sehen sein - aber das ist spät. In der Zwischenzeit ist es zu einem unnötigen Stau gekommen. Als würde ein liegengebliebener Wagen nicht von der Fahrbahn genommen.

Shit happens. Darauf sollte möglichst zeitnah reagiert werden, um nicht noch Folge-Shit entstehen zu lassen. Wie das geht, zeigt die Behandlung von unvorhersehbaren Variationen in der Passagierabfertigung am Flugsteig sehr schön, finde ich.

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.