Posts mit dem Label Agile beyond IT werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Agile beyond IT werden angezeigt. Alle Posts anzeigen

Dienstag, 11. Juli 2023

Computer Aided Design und Digital Prototyping

Bild: National Archives / Combined Military Service Digital Photographic Files - CC0 1.0
Eine der grundlegenden agilen Praktiken ist das in kleinen Schritten vorangetriebene Inspect & Adapt. Man bringt eine neue Produkt-Version zum Kunden oder Anwender und schaut sich an was der damit macht. Wenn dieser Realitätstest überstanden wird kommt die nächste Version, wenn nicht wird die letzte überarbeitet. Aber was macht man, wenn das nicht geht oder es sehr teuer wäre?


Vor allem im Hardware-Bereich gibt es immer wieder derartige Fälle, was nicht nur die Entwicklung von Prototypen von Maschinen, Fahrzeugen und Geräten umfasst, sondern auch die von Bauwerken und Gebäuden. Zum Einen können die eingebauten Rohstoffe teuer sein, zum anderen sind die Einzelteile fest miteinender verbunden, um Belastbarkeit und Stabilität zu gewährleitsten. Ein "Auseinandernehmen und neu Zusammensetzen" geht also nicht so einfach.


Will man sich nicht darauf verlassen, alles beim ersten mal richtig zu machen (was, wenn es nicht klappt, gerade bei Bauwerken richtig teuer werden kann)  braucht man also eine Alternative, mit der man einem Inspect & Adapt zumindest nahe kommen kann. Eine mittlerweile weit verbreitete ist das so genannte Computer Aided Design (CAD), bei dem ein neues Gebäude-, Maschinen- oder Gerätebau-Vorhaben vor der eigentlichen Umsetzung durch mehrere digitale Simulations-Durchläufe geht.


Die entsprechenden Erfahrungswerte vorausgesetzt können damit eine ganze Reihe von Annahmen im Voraus überprüft, gegebenenfalls angepasst und erneut überprüft werden, noch bevor die eigentliche Konstruktion begonnen hat. Die häufigsten dertigen Überprüfungen beziehen sich auf Statik und Stabilität, es sind aber auch zahlreiche andere denkbar, vom voraussichtlichen Materialverschleiss bis hin zum Verhalten von Menschenmengen oder Luftströmen in einem Gebäude.


Natürlich kann man auf diese Weise nicht alles vorhersehen, was später in der Realität eintreffen wird, zumindest einen Teil der Validierungen kann man aber vorwegnehmen. Ein Fall, der das nachvollziehbar macht, ist der Wind-Widerstand von Hochhäusern, der erst ab einer bestimmten Höhe des Baus spürbar wird. Da übliche Windrichtungen und -stärken bekannt sind, ist es möglich, den Bauplan so lange zu optimieren, bis zu starke Schwankungen des fertigen Gebäudes im Voraus auszuschliessen sind.


Ein anderer Einsatzbereich ist die Berechnung möglicher Varianten eines bestehenden Hardware-Produkts, z.B. eines Fahrzeugs, einer Maschine oder eines Haushaltgeräts. Sollen diese besonders günstig, leistungsstark, robust, umweltfreundlich oder sparsam im Verbrauch sein, kann auf Basis des bestehenden Produkts ein digitaler Protyp entwickelt werden, mit dem die gewünschte Variante auf Umsetzbarkeit und mögliche Probleme überprüft wird.


Mit Hilfe derartiger Vorgehensweisen lässt sich das erreichen, was der auf dieser Website schon mehrfach erwähnte Grossprojekt-Forscher Bent Flyvbjerg "thinking slow, acting fast" genannt hat, also eine schnelle Umsetzung hochkomplexer Vorhaben durch eine auf Virtualisierung beruhende Validierung von Annahmen noch im Planungszeitraum. Noch mehr Shift Left geht nicht.

Donnerstag, 9. März 2023

Agile Workforce

Bild: Pexels / Yan Krukau - Lizenz

Wie stark die agile Bewegung über ihr ursprüngliches Umfeld in der Produktentwicklung von Software (und Hardware) hinausgewachsen ist, lässt sich an einem besonderen Phänomen beobachten: es gibt mittlerweile die ersten Hypes und Buzzwords die zu diesen Ursprungsgebieten keinen Bezug mehr haben und dort auch weitgehend unbekannt sind. Ein Beispiel dafür aus den letzten Jahren ist die "Agile Workforce". Was soll das jetzt schon wieder sein?


Zunächst kurz zur Begriffserklärung: "Workforce" wird meistens mit "Belegschaft" übersetzt, was aber die Bedeutung nicht zur Gänze wiedergibt. "Arbeitskraft" kommt ihr schon näher, ist im Deutschen aber bereits anders belegt. Die sinngemässe Übersetzung wäre in etwa "die Gesamtgruppe aller Arbeiter", woraus sich ergibt, dass "Agile Workforce" eine Angestelltengruppe beschreibt, die zu agilem Arbeiten in der Lage ist. Der eine oder andere wird jetzt bereits ahnen, wo diese Idee her kommt.


Fast alles was man bei einer Literatur-Recherche zu Agile Workforces findet, kommt aus dem HR-Bereich, und das mit einem besonderen Schwerpunkt auf Personalentwicklung. Es handelt sich dabei also nicht um eine Zustandsbeschreibung, sondern um ein Zielbild, an dessen Erreichung Personal- und Learning & Development-Abteilungen sowie externe Dienstleister arbeiten wollen, um so ihren Beitrag dazu zu leisten, dass ihre Unternehmen oder Kunden agil arbeiten können.


Der Nebel lichtet sich durch diese Erkenntnis etwas, einiges bleibt aber unklar. Was genau kann denn im Rahmen der Personalentwicklung gemacht werden, um die Belegschaft zu agilem Arbeiten zu befähigen? Wer in der Literatur nach Antworten hierauf sucht, wird sich erstmal durch eine Buzzword-Wolke kämpfen müssen, in der in verschiedenen Konstellationen Begriffe wie Mindset, Kultur, Werte und Prinzipien aufgezählt und als notwendig bezeichnet werden. Nicht falsch, aber auch nicht hilfreich.


Klarer wird es wenn man sich vor Augen hält, dass es zwei Dimensionen von Personalentwicklung gibt: Positionsorientiert und Potentialorientiert. In der ersten Dimension werden einzelne Personen auf bestimmte Aufgaben vorbereitet, z.B. die eines Product Owners oder DevOps Engineers. Das kann durch Aus-, Fort- und Weiterbildung geschehen, alternativ auch durch gezielte Rekrutierungen. Hier finden oft klassische HR-Techniken Verwendung, etwa Assessment Center und Schulungen.


Schwerer tun sich die meisten Firmen mit der zweiten, potentialorientierten Dimension. Die findet statt, wenn es noch nicht um die Besetzung bestimmter Positionen geht, sondern darum, unternehmensweit einen Talentpool an qualifizierten Mitarbeitern aufzubauen. Im Fall der angestrebten Agile Workforce sollen dabei möglichst viele Mitarbeiter auf einer abstrakten Ebene verstanden haben, was Agilität bedeutet, um dieses Wissen in allen potentiell möglichen Rollen anwenden zu können.


In der Praxis tritt diese Wissensvermittlung dann meistens in Form von Workshops zu Kultur und Werten auf, was auch grundsätzlich richtig ist. Schliesslich handelt es sich gerade bei diesen beiden Phänomenen um organisationsweit vorhandene Faktoren, die in praktisch jeder denkbaren Position Wirkung entfalten können. Vor allem in Umfeldern, in denen bereits agile Frameworks im Einsatz sind, können sie sogar wesentlich dazu beitragen, dass diese funktionieren wie gedacht.


Wie derartige Workshops aussehen können ist nochmal ein Thema für sich, grundsätzlich sollte aber vermittelt werden was Kultur und Werte sind, wie sie vor allem dort wo es keine (oder widersprüchliche) Prozessvorgaben gibt, den Arbeitsalltag prägen und wie sie gestaltet sein müssen um sicherzustellen, dass die von den agilen Frameworks bewusst offen gelassenen Lücken im Einzelfall so gefüllt werden, dass agiles Arbeiten möglich ist.


Beide Personalentwicklungs-Dimensionen sind aber auch nicht ohne Risiko: überall dort, wo nur für die Zukunft geschult oder geworkshopt wird, werden die vermittelten Inhalte durch ihre Gegenläufigkeit zur noch gelebten Praxis als Paradoxe Kommunikation wahrgenommen und ggf. abgelehnt werden. Und falls die Durchführung von Schulungen selbst zum Messkriterium für die Schaffung einer Agile Workforce wird, ist ein Abkippen in den agil-industriellen Komplex hochwahrscheinlich.


Das heisst natürlich nicht, dass man die Arbeit an der Herstellung einer Agile Workforce unterlassen sollte, man sollte es aber (wenig überraschend) selbst auf Basis agiler Prinzipien tun, also in kurzen Zyklen, ohne zu langen Planungsvorlauf und mit regelmässigen Validierungen und Feedbackschleifen. Dann kann es zu einem "Learning by doing" kommen, und zwar nicht nur bei den zu agilisierenden Angestellten, sondern auch bei den damit beschäftigten HR- und Learning & Development-Abteilungen selbst. Ein nicht zu unterschätzender Seiteneffekt.

Donnerstag, 9. Februar 2023

Agile HR (II)

Bild: Unsplash / Jason Goodman - Lizenz

Agile Arbeitsweisen auf Bereiche ausserhalb der Produktentwicklung übertragen zu wollen trifft immer wieder auf die gleichen Widersprüche: das wäre doch etwas ganz Anderes, heisst es regelmässig, die Rahmenbedingungen und Arbeitsgegenstände wären völlig unterschiedlich, das könne man doch nicht gleich behandeln, etc. Dass die Gemeinsamkeiten grösser sind als von vielen gedacht kann man aber an Beispielen aufzeigen, z.B. im Bereich agile HR.


Auch Human Ressources hat ein Produkt (oder eine Dienstleistung), nämlich Bereitstellung von allem was zur Gewinnung, Bindung, Organisation, Entlohnung und Qualifizierung von Personal notwendig ist. Der Kunde, bzw. die Zielgruppe ist dabei das Personal selbst,1 das durch das sich Anstellen Lassen, den Verbleib oder die Kündigung dafür sorgt, dass auch hier ein Markt mit Angebot und Nachfrage entsteht, auf dem sich das durch HR vertretene Unternehmen behaupten muss.


Vor allem in grossen Unternehmen ist dieses HR-Produkt dabei oft von hinterfragbarer Qualität. Obwohl gut gemeint und mit nicht unerheblichem Aufwand erstellt wird es von den Angestellten häufig als nicht den Bedürfnissen entsprechend, sich nicht den Gegebenheiten anpassend und nur hinter bürokratischen Hürden erreichbar wahrgenommen. Die HR-Dienstleistungen schnell und unbürokratisch (🡒 agil) an Zielgruppenwünsche anzupassen sollte in Zeiten des Fachkräftemangels daher ein Ziel sein.


Die Änderungen die man zu diesem Zweck vornehmen kann sind denen in der Produktentwicklung sehr ähnlich. Ein in beiden Bereichen vorzufindender Klassiker ist zum Beispiel die Umstellung von Komponenten- oder Spezialistenteams auf crossfunktionale Teams, die möglichst viele Teile der HR-Dienstleistungen selbst erbringen können. Diese müssen dann nicht mehr ständig auf die Zulieferung anderer Spezialistenteams warten und werden alleine dadurch flexibler und schneller.


Aber ist eine klassische HR-Einheit denn wirklich Komponenten- oder Spezialisten-basiert aufgestellt? Bei näherer Betrachtung definitiv. Recruiting, Onboarding, Career Development, Compensation, Learning and Development, Diversity Management und Change Management bilden fast überall klar von einander abgegrenzte organisatorische Silos, die jedes für sich nur eine Teilleistung erbringen und mit den jeweils anderen nur mittelgut abgestimmt sind (mit Langsamkeit, Bürokratie und schlechter Qualität als Folge).


Eine Möglichkeit es besser zu machen wären gemischte Vollzeit-Teams, von denen jedes einzelne möglichst alle Aspekte der HR-Tätigkeiten abdecken kann. Und überall dort wo diese Tätigkeiten für viele Menschen erbracht werden müssen kann die Skalierung nicht nur durch Aufspaltung in Spezialistenteams erfolgen, sondern genau so gut dadurch, dass den Zielgruppen-Einheiten (Ressorts, Abteilungen, o.ä.) jeweils ein crossfunktionales HR-Team zugeordnet wird.


Ist eine solche Umstellung anspruchsvoll und anstrengend? In vielen Fällen ja. Ist die Sicherstellung übergreifend gleicher Qualitätsstandards eine Herausforderung? Definitiv. Wird die Umstellung von Hoch-Spezialisierung auf das in diesem Kontext nötige T-Shape-Profil allen HR-Fachkräften leicht fallen? Mit an Sicherheit grenzender Wahrscheinlichkeit nicht. Und ist all das nicht eine gute Begründung dafür, crossfunktionale, agile HR-Teams doch nicht anzustreben? Nein, ist sie nicht. Die Idee ist und bleibt gut.


In der Produktentwicklung sind all diese Herausforderungen schliesslich auch gegeben, und trotzdem wurde dort wieder und wieder der Beweis erbracht, dass kleine, crossfunktionale, agil arbeitende Vollzeit-Teams die ideale Organisationsform sind um den Bedürfnissen entsprechende, an sich ändernde Gegebenheiten anpassbare und unbürokratisch erbrachte Produkte und Dienstleistungen zu erstellen. Und damit kommen wir zurück zum Anfang.


Bei genauer Betrachtung sind die die Gemeinsamkeiten von Produktentwicklung und HR grösserals man im ersten Gedanken annehmen würde, und selbst wenn das agile Arbeiten ursprünglich explizit für die Produktentwicklung erfunden wurde ist eine Übertragung sowohl machbar als auch sinnvoll. Man muss nur bereit sein sich darauf einzulassen.


1Eine zweite, ganz andere Kunden- bzw. Zielgruppe ist das Unternehmen selbst.

Freitag, 6. Januar 2023

Extreme Contracts

Wer mich kennt weiss, dass Jacopo Romei mich in dem Moment dieses Vortrags schon halb überzeugt hatte, in dem er ankündigte, seine folgenden Ausführungen auf seiner Abneigung gegen Muda (無駄), also die im Toyota Production System beschriebenen nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten basieren zu lassen. Seine Extreme Contracts sollen dementsprechend bewirken, dass die durch viele herkömmliche Verträge versehentlich erzwungene Durchführung nicht wertstiftender Tätigkeiten unterbleibt.



Auf den Kern reduziert besteht die Idee extremer Verträge daraus, dass diese nur für jeweils einen Sprint von einer Woche zu einem immer gleichen Fixpreis geschlossen werden. Nach jedem kann die beauftragende Seite überprüfen ob das Ergebnis für sie wertvoll ist - und wenn nicht, entscheiden nicht zu bezahlen (wenn das passiert muss sie allerdings damit rechnen, dass der beauftragte Dienstleister nicht für weitere einwöchige Fixpreisverträge zur Verfügung steht). Die entfallende Muda besteht dabei aus den nicht mehr notwendigen Aufwänden für Aufwandsschätzung und Preisverhandlung. Eine interessante Idee mit vielen Implikationen, über die ich nochmal genauer nachdenken muss.

Montag, 26. Dezember 2022

Wie der Staat wieder handlungsfähig wird

Bild: Pixabay / Borevina - Lizenz

Wenn es etwas gibt, das als Inbegriff von fehlender Agilität gilt, dann ist es die staatliche Verwaltung. Warum diese Betrachtung etwas zu einseitig ist habe ich bereits an anderer Stelle aufgeschrieben, im Grossen und Ganzen ist es aber leider so, dass Schwerfälligkeit und Langsamkeit in vielen Behörden vorherrschen. Umso interessanter ist ein aktueller Fall, der zeigt, dass auch dort wo bisher die Bürokratie dominierte erstaunliche Verbesserungen möglich sind.


Die Rede ist von dem Bau des Flüssiggas-Terminals in Wilhelmshaven, dessen beschleunigte Genehmigung und Erstellung in einem Artikel der Zeit beschrieben wird. Das Ausmass dieser Beschleunigung wird bereits durch das Nebeneinanderhalten der Zeiträume deutlich: normalerweise wird bei Vorhaben dieser Art von acht Jahren (!) ausgegangen, in diesem Fall waren dagegen für die gesamte Zeit von Beschlussfassung bis Inbetriebnahme nur 10 Monate nötig.


Der grösste Zeitgewinn ist dabei offensichtlich in der Genehmigungsphase erzielt worden, alleine die scheint im Normalfall bis zu sechs Jahre (!) zu dauern. Die bemerkenswert einfache Lösung: einmal pro Woche hat ein gemeinsamer Call aller an der Genehmigung beteiligten Behörden stattgefunden, in dem geklärt wurde wer als nächstes was an wen zuzuliefern hat. Diese direkte Abstimmung hat schnell Ergebnisse geliefert, für die es sonst einen wochenlangen Schriftverkehr gebraucht hätte.


Dass diese Runden stattfinden konnten und arbeitfähig waren wurde durch eine weitere bemerkenswert einfache Massnahme möglich: realistische Personalplanung. Statt unterbesetzte Dienststellen mit Arbeit zu überhäufen und darauf zu hoffen, dass es irgendwie gut geht wurde darauf geachtet, dass ausreichende Arbeitskapazitäten verfügbar gemacht wurden um die anstehenden Aufgaben zu erledigen. Ein für Grossorganisationen keineswegs selbstverständliches Vorgehen.


Etwas komplizierter war der Umgang mit anderen Ressourcen: den Baustoffen (vor allem Stahl). Statt den klassischen Weg zu gehen, zuerst einen Plan zu erstellen und dann nach den in ihm vorgesehenen Baustoffen zu suchen (die in diesem Moment ggf. nicht verfügbar wären), wurden nach einer ersten Grobschätzung zuerst die Baustoffe gekauft um dann erst basierend auf deren Verfügbarkeit die Baupläne zu erstellen. So konnten die Bauarbeiten direkt beginnen.


Eine zusätzliche Beschleunigungsmassnahme war die Aufhebung der strikten Sequenzialität aller Vorgänge. Dort wo die Erteilung von Genehmigungen absehbar war wurde bereits mit der Umsetzung begonnen, die offiziellen Freigaben wurden nachgeliefert wenn sie fertig waren. Verbunden war das allerdings mit der Vorgabe im eventuellen Fall einer doch verwehrten Genehmigung alles bis dahin Gebaute wieder rückgängig zu machen.


Die Bereitschaft sich darauf einzulassen war auch Teil von etwas Grösserem: der Einsicht, dass sich nicht alles vorhersagen und planen lässt, und dass es deswegen zu Kostensteigerungen kommen kann die dann zu tragen sind. Diese Einsicht steht in deutlichem Gegensatz zur in Grossvorhaben üblichen Praxis Kostensteigerungen mit Sparmassnahmen an anderen Stellen kompensieren zu wollen, die meistens zu schlechteren (und langfristig sogar teureren) Ergebnissen führen.


Zuletzt kamen noch kleinere Massnahmen dazu, etwa verkürzte Fristen für die öffentliche Auslegung der Pläne. In Kombination haben alle diese Massnahmen dazu geführt, dass ein Grossprojekt in nur einem Zehntel der Zeit umgesetzt werden konnte die sonst für vergleichbare Vorhaben notwendig ist. Das Beispiel des Flüssiggas-Terminals in Wilhelmshaven zeigt, dass auch staatliche Grossprojekte schnell und unbürokratisch realisiert werden können, wenn es denn gewollt ist.


Die Frage die bleibt - wenn das einmal möglich war, warum nicht öfter so?

Dienstag, 27. September 2022

Beyond Budgeting

Bild: Pixabay / StevePB - Lizenz

Die agile Produktentwicklung hat Vieles nachhaltig verändert: den Umgang mit Abnehmern und Kunden, die Durchführung der Qualitätssicherung, die handwerklichen Praktiken der Softwareentwicklung und vieles mehr. Ein zentraler Bereich der Unternehmensführung ist allerdings eher unberührt geblieben - der Budgetierungsprozess. Glücklicherweise gibt es aber hier einen kompatiblen, zeitgleich entstandenen Ansatz, der diese Lücke füllen kann. Die Rede ist von Beyond Budgeting.


Ähnlich wieim Fall von #NoEstimates steht hinter Beyond Budgeting eine überzeugte (und in verschiedenen Firmen hoch erfolgreiche) Community, nach aussen sorgt die etwas unglückliche Namensgebung aber dafür, dass es oft gar nicht erst zu einer näheren Beschäftigung mit diesem Ansatz kommt. Dabei soll hier keineswegs der Budgetierungsprozess abgeschafft werden, er soll erhalten bleiben, nur eben deutlich verbessert.


Dieser Verbesserungsbedarf wird aus verschiedenen problematischen Aspekten der klassischen Budgetierung abgeleitet. Dazu gehört vor allem die Fixierung auf die Budget-Planung für ganze Kalenderjahre und die harte Verknüpfung von Arbeits-Paketen (und Arbeits-Erlaubnissen) mit diesen Budgets, aber auch die in dieser Jahresplanung oft enthaltene Vermischung von Prognosen und Zielen oder die Kopplung von Gehaltsbestandteilen an aus diesen Jahreszielen abgeleitete persönliche Ziele.


Über diese Budgetierungs-nahen Grundlagen hinaus sind nach und nach weitere Kritikpunkte an häufigen Elementen des traditionellen Budget-Managements in Beyond Budgeting aufgenommen worden, etwa an dem Nicht-Weitergeben von Informationen in die Belegschaft, an zu detaillierter Regulierung von Arbeitsprozessen, an zu bürokratischen Reporting-Strukturen und an der Optimierung auf interne Effizienz statt auf Nutzen für den Endkunden.


Bei der Antwort auf die Frage wie all das besser organisiert werden könnte bleibt Beyond Budgeting absichtlich unklar, da zu konkrete Empfehlungen in vielen Einzelfällen nicht passen würden, zumindest wurden als Richtlinie aber zwölf leitende Prinzipien verfasst:

  1. Purpose
    Engage and inspire people around bold and noble causes; not around short-term financial targets
  2. Values
    Govern through shared values and sound judgement; not through detailed rules and regulations
  3. Transparency
    Make information open for self-regulation, innovation, learning and control; don’t restrict it
  4. Organisation
    Cultivate a strong sense of belonging and organise around accountable teams; avoid hierarchical control and bureaucracy
  5. Autonomy
    Trust people with freedom to act; don’t punish everyone if someone should abuse it
  6. Customers
    Connect everyone’s work with customer needs; avoid conflicts of interest
  7. Rhythm
    Organise management processes dynamically around business rhythms and events; not around the calendar year only
  8. Targets
    Set directional, ambitious and relative goals; avoid fixed and cascaded targets
  9. Plans and forecasts
    Make planning and forecasting lean and unbiased processes; not rigid and political exercises
  10. Resource allocation
    Foster a cost conscious mind-set and make resources available as needed; not through detailed annual budget allocations
  11. Performance evaluation
    Evaluate performance holistically and with peer feedback for learning and development; not based on measurement only and not for rewards only
  12. Rewards
    Reward shared success against competition; not against fixed performance contracts

Um die Idee greifbarer zu machen gibt es mittlerweile neben diesen Leitlinien aber auch verschiedene Good Practices, die in verschiedenen Büchern zu diesem Thema nachzulesen sind.


Die naheliegende erste Praktik ist eine rollierende Planung anstelle einer Kalenderjahr-basierten. Das kann in der Realität so aussehen, dass zwar für z.B. fünf Quartale im Voraus geplant wird, dass diese Planungen aber nach jedem Quartal überprüft und angepasst werden. Dadurch entfernt sich die Umsetzung nie länger als drei Monate von der Planung, gleichzeitig wird vermieden, dass der Planungsvorlauf zu Jahresende nur noch wenige Wochen beträgt.


Ein ähnlich klarer Bruch mit verbreiteten Budgetierungs-Mustern ist es, Budgets nicht mehr mit Arbeitspaketen oder Projekten zu verknüpfen, sondern mit der durchgehenden Finanzierung von langlebigen, stabilen Teams. Woran die arbeiten kann weiterhin durch klare Priorisierungen gesteuert werden, bei einer Änderung der Umsetzungs-Planungen ist es aber nicht mehr nötig, aufwändig die Budget-Zuteilungen zu verändern.


Ebenfalls häufig ist die Entkoppelung von Prognose und Zielsetzung. In den Prognosen für den jeweiligen Planungszeitraum wird nur berücksichtigt was wahrscheinlich ist, das was wünschenswert ist (die Ziele) wird in einem zweiten, getrennten Dokument festgehalten. Das gilt auch dann (und sogar ganz besonders dann) wenn die wahrscheinlichen Zahlen unschön oder sogar bedrohlich sind. Sie zu verändern nur weil andere Zahlen schöner wären ändert schliesslich die Sachlage nicht.


Auch bei den Zielen (sowohl bei Geschäftszielen als auch bei Zielen von Personen oder Personen-Gruppen) ist eine kontinuierliche Setzung und Nachverfogung besser als eine Orientierung am Jahresrhythmus. Das bedeutet nicht zwingend, dass sie nur für kürzere Umsetzungszeiträume gesetzt werden, z.B. für Monate oder Quartale. Sie können auch für längere Zeiträume gesetzt werden, müssen dann aber in kurzen Zyklen immer wieder überprüft und an aktuelle Entwicklungen angepasst werden.


Bei der Art der Zielsetzung geht Beyond Budgeting ebenfalls eigene Wege. Statt zahlengebundener Ziele (z.B. Gewinn-Volumen oder Anzahl an Geschäftsabschlüssen) findet man eher relative Ziele, also solche, deren Zielsetzung es ist besser zu sein als eine Vergleichsgruppe. Das kann bedeuten, dass eine ganze Firma sich das Ziel setzt besser zu sein als der Marktdurchschnitt, es kann aber z.B. auch bedeuten, dass eines von 50 Vertriebsteams sich das Ziel setzt zu den besten 10 zu gehören.


Neben diesen sind zahllose weitere Praktiken möglich, die von Unternehmen zu Unternehmen unterschiedlich sein können. Auch die Entwicklung eigener Ideen ist möglich, solange sie den oben genannten Prinzipien nicht wiedersprechen. Und da sich die Communities von Beyond Budgeting und agiler Produktentwicklung in den letzten Jahren angenähert haben umfasst das auch mögliche Kombinationen von beidem (auch dazu gibt es in verschiedenen Büchern Beispiele).


Für jeden der in seiner Organisation die agile Transition ganzheitlich vorantreiben will ist Beyond Budgeting daher ein sehr zu empfehlender Ansatz. Und wenn die Namensgebung als zu kontrovers wahrgenommen werden sollte - man kann es auch agile Budgetierung nennen, wichtig ist, dass die dahinter stehenden Ideen umgesetzt werden, nicht der Name.