Die Methode
Ein System besteht aus Menschen und Software.
Wir trennen das eine nicht vom anderen — und wir beginnen nicht bei der Anforderung, sondern bei der Sprache Ihrer Mitarbeiter, die täglich in diesem System arbeiten.
Ein Jahr Reorganisation, ein halbes Jahr Ausschreibung, dann beginnt endlich die Entwicklung — und am Ende passt die Software zu einer Organisation, die es so nicht mehr gibt.
Diese Reihenfolge existiert, weil Beratungen und IT-Abteilungen so aufgestellt sind. Doch Organisationen funktionieren nicht so. Deshalb behandeln wir Menschen und Software als ein System und verändern beide in derselben Bewegung.
Vor der Methode
Andere wissen schon vor dem ersten Gespräch, wie sie arbeiten werden. Wir nicht.
Wir sehen uns zuerst an, welche Art von Problem vor Ihnen liegt und danach entscheidet sich, wie wir vorgehen.
Klar
Ursache und Wirkung sind bekannt. Es gibt eine geregelte Praxis.
Ergebnis: eine schlichte, funktionierende Prozesslösung. Unspektakulär, und genau richtig.
Kompliziert
Der Zusammenhang ist analysierbar, aber nicht offensichtlich. Es braucht Expertise.
Ergebnis: eine gefundene und angewandte Methode — oft zusammen mit Software, die den Ablauf trägt.
Komplex
Ursache und Wirkung zeigen sich erst im Rückblick. Vorabplanung führt in die Irre.
Ergebnis: eine Sonde, ein Experiment, ein Prototyp und daraus das, was tatsächlich trägt.
Deshalb handeln wir nicht nach einem Ablauf, den man statisch von oben nach unten abarbeitet. Wir handeln aus unserem Repertoire. Welche Schritte greifen, entscheidet der Befund — nicht der Projektplan.
UNSER REPERTOIRE
Orientieren
Feststellung der Art des Problems und was überhaupt möglich ist, bevor eine Entscheidung über das eigentliche Vorgehen fällt.
Sprache
Das System entsteht aus der Sprache, die im Unternehmen tatsächlich gesprochen wird. Nicht aus einem Lastenheft und nicht nur aus der technischen Übersetzung davon.
Ableiten
Aus der kuratierten Sprache werden Zustände, daraus Swarmlets: kleine, eigenständige Einheiten, die genau die Begriffe verwenden, die die Menschen selbst benutzen.
Erproben
In komplexen Lagen wird schnell und risikoarm experimentiert, um die nächsten Schritte zu erkennen.
Liefern
Was trägt, geht auch in Betrieb - als Software, als neue Organisationseinheit oder in manchen Fällen sogar als eigenes Unternehmen.
Erhoben wird, was gesagt wird — nicht, was ein Analyst daraus macht.
Was keinen Beitrag leistet, wird nicht modelliert und nicht gebaut.
Der Zweck steht fest, bevor über den Weg gesprochen wird.
Ein Swarmlet ist eine eigenständige Einheit mit eigenem Zustand, kein Modul in einem Ablaufdiagramm.
Was im Unternehmen einen Namen hat, behält ihn auch im System.
Der Code entsteht aus dem Sprachmodell des Geschäfts und bleibt daran gebunden.
Unsere Software „OneCrew“ ist so entstanden. Daran lässt sich die Geschwindigkeit dieser Methode ablesen.
Ein Swarmlet, das seinen Zweck verloren hat, wird nicht mehr gepflegt, nicht refaktoriert und nicht mitgeschleppt. Es wird verworfen, und an seiner Stelle wächst ein neues. Das ist nur möglich, weil es keinen gemeinsamen Datenbestand gibt, über den die Teile aneinander hängen - denn jede Einheit trägt ihren Zustand selbst.
Die Folge
In den meisten Unternehmen bindet nicht der Bau neuer Systeme den größten Teil des
IT-Budgets, sondern der Unterhalt alter Systeme. Das ist die Folge antiquierter Bauart.
Wir bei SWARMATIC haben verstanden, dass sich dieser Posten nicht optimieren lässt.
Er lässt sich vermeiden.
Kein Altlastenbestand, der mitwächst
Wenn eine Einheit ersetzbar ist, ohne die anderen anzufassen, entsteht keine Altlast, die niemand mehr anrührt. Was nicht mehr passt, verschwindet.
Änderung ist der Normalfall, nicht das Projekt
Eine Anpassung braucht keinen Umbau und keine Freigabekette. Sie betrifft eine Einheit, und die wird neu gewachsen.
Die Organisation darf sich weiter verändern
Der übliche Grund, eine Reorganisation zu unterlassen, ist die Software, die dann nicht mehr passt. Dieser Grund fällt weg - und damit die stillste Bremse in vielen Unternehmen.