Warum agil kein gutes Geschäftsmodell ist. - Umsatzsprung

Warum 'Agil' kein gutes Geschäfts-modell ist

Warum 'Agil' kein gutes Geschäftsmodell ist

Warum agil kein gutes Geschäftsmodell ist. - Umsatzsprung

Warum 'Agil' kein gutes Geschäfts-modell ist

‚Agil‘ ist in den meisten Fällen die bessere Methode, um Software zu entwickeln.

Ist 'agil' damit auch automatisch das beste Geschäftsmodell für SW-Entwicklungs-Unternehmen? 

Ist es nicht.  
Und genau darum geht es hier.


Wer agil entwickelt, verkauft den Kunden meist Sprints. 
 
Statt Sprints kann man natürlich auch Team-Tage verkaufen. Oder gar Stunden. 


Am Ende läuft es auf dasselbe raus: Das Unternehmen verkauft Zeit. 
 
Vor allem die Zeit ihrer Mitarbeiter.  
Das ist ein Geschäftsmodell mit großen Nachteilen. 


Natürlich auch mit Vorteilen. 
 
Was einem am Ende mehr wert ist, kann man als Eigentümer selbst entscheiden.  
Mir ist hier wichtig klar zu machen:  

Nur weil man agil entwickelt, muss man nicht Sprints verkaufen. 

Na, was denn dann? 
Bevor wir zu Alternativen kommen, werfen wir einen Blick auf die Vor- und Nachteile des agilen Geschäftsmodells: 

Die Vorteile:

Das Angebot ist simpel 

Mittlerweile verstehen viele Kunden das agile Modell.  

Es ist klar, wie es läuft: „Das sind die Leute, das sind die Konditionen.“ 

Die Kalkulation ist mit einer einfachen Multiplikation erledigt. Es müssen keine aufwändigen Angebote erstellt werden. 

Wer noch die Zeiten kennt, in denen man tageweise Aufwand in die Entwicklung und Kalkulation von Fixpreis-Projekten gesteckt hat, nur damit der Kunde dann beim Preis vom Stuhl fiel, weiß diesen Vorteil zu schätzen. 

Für viele IT-Unternehmen auch ein großes Plus: Super talentierte Verkäufer braucht man dafür nicht. 

Geringes Anbieter-Risiko 

Das Risiko, sich zu verschätzen, zu verrechnen oder Opfer von scope-creep zu werden, ist bei agiler Entwicklung deutlich geringer als bei Fixpreis-Projekten. Deadlines werden im Idealfall komplett vermieden und falls es doch welche gibt, sitzt der Kunde als Product Owner mit im Boot.

Die konfliktträchtigen Change Orders vermeidet man elegant, indem man weitere Wünsche einfach in den nächsten Sprint schiebt.

Mit anderen Worten: Wer als Software-Anbieter sein agiles Handwerk versteht, schläft gut. 

Langfristige Auslastung

Meine (völlig nicht-wissenschaftliche) Erfahrung in der Arbeit mit über 100 IT-UnternehmerInnen ist: Den meisten ist ein stabiles, zuverlässiges, kalkulierbares Geschäft wichtiger als eines, mit dem man viel Geld verdienen kann oder das beim Firmenverkauf einen guten Preis erzielt. 

Ganze Teams langfristig in Sprints zu verkaufen, kommt diesem Bedürfnis sehr entgegen.  

Hat man erst mal stabile Kundenbeziehungen und leistet solide Arbeit, muss man nicht ständig neu verkaufen: Der Kunde budgetiert die Kosten ein und bestellt zuverlässig, im Idealfall mit 12-Monats-Rahmenverträgen. Man wird quasi zur hauseigenen Entwicklungs-Abteilung.  

Die Nachteile:

Skaliert schlecht:

Zeit verkaufen skaliert schlecht. Das ist nichts Neues. Und weil Sprints zu verkaufen nichts anderes ist, als Zeit zu verkaufen, skaliert auch das schlecht. Wachstum geht nur linear und selbst das ist schon der beste Fall:  

  • Recruiting wird von der Management-Challenge zum Wachstums-Flaschenhals. Wer keine Leute findet, stagniert. 
  • Je mehr Mitarbeiter, desto höher die anteiligen Overhead-Kosten. Gleichzeitig braucht man größere Projekte, bei denen Kunden härter verhandeln. Ergebnis: der Umsatz nimmt zwar zu, aber die Marge sinkt. 
  • Mehr Mitarbeiter = mehr Führungs-Herausforderungen. Höhere Fixkosten. Mehr Projektdruck. Mehr Stress für die Eigentümer.  

Anders ausgedrückt: Wachstum ist immer schwer, Wachstum mit einem Zeit-gegen-Geld Geschäftsmodell ist richtig schwer.
Wenn Sie an Unternehmen denken, die Sie bewundern – wie viele davon verkaufen Zeit?  

Differenzierung ist schwierig 

Talentierte Mitarbeiter, bewährte Prozesse, gute Tools, Branchen Know-How und einen guten Track-Record mit wohlklingenden Namen auf der Referenzliste. Darauf darf man als Unternehmen stolz sein. 
Aber der Wettbewerb hat all das auch. 

Der agile Prozess hat Software-Entwicklungs-Unternehmen normiert. Alle folgen dem gleichen Manifesto. 
Sich von der Konkurrenz abheben? Das wird schwierig. 

Natürlich gibt es feine, wichtige Unterschiede zwischen einem Unternehmen und den anderen.  
Unterschiede, die Kunden in der Regel weder erkennen noch für besonders wichtig finden. Und deshalb selten bereit sind, dafür einen Aufpreis zu zahlen. 

Profite werden verschenkt 

Den wichtigsten Punkt habe ich bis zum Schluss aufbewahrt.

Viele Entwicklungs-Unternehmen sind großartig darin, mit ihrer Software den Kunden massive Wettbewerbsvorteile zu verschaffen, ihnen neue Umsätze zu generieren,  und Kosten zu sparen. 
Was sie oft nicht so gut schaffen ist, sich einen respektablen Anteil an dieser Wertschöpfung zu sichern. 

So berichtet mir erst kürzlich ein Unternehmer stolz, ein gutes Projekt an Land gezogen zu haben – mit einem höheren Stundensatz als üblich.  
„120.000 Euro wird das sicher und wenn es gut läuft, bestellt der Kunde sicher noch mehr.“ 
Die Wertschöpfung für den Kunden, die liegt freilich im satten  Millionenbereich.

Wer eine tolle Wertschöpfung für seine Kunden mit ROI’s von 30-50 bringt, darf stolz auf seine kreative Ingenieursleistung sein.  
Schön wäre es, für diese Leistung auch entsprechend gutes Geld zu bekommen. 

Was wäre gewesen, wenn das Unternehmen gefragt hätte: „Lieber Kunde, wenn Ihnen unser System jedes Jahr 4 Millionen Kosten spart – würden Sie dafür einmalig eine Million bezahlen?“ 
Natürlich würde er. Was für ein Geschäft!  

Aber wenn er die Option hat, sich dasselbe System für 4 Sprints á 30.000 Euro bauen zu lassen, nimmt er lieber die.
Würden wir ja auch an seiner Stelle.
 

Alternativen zu "Zeit gegen Geld"

Es gibt viele Möglichkeiten, IT-Systeme zu bepreisen: 

  • Preis pro User und Monat 
  • Lizenzkosten 
  • Transaktionsvolumen 
  • Anteil an der realisierten Wertschöpfung 
  • Grad der Zielerreichung 
  • andere kreative Varianten 
  • oder eine Kombination davon 

Die meisten dieser Modelle liegen sogar näher am Geschäftsmodell der Kunden und sind daher für diese oft leicht zu verstehen, in der Art „Für jeden Euro, den Sie zusätzlich machen, bekommen wir 20 Cent.“  
Das kapiert jeder. Der Wert ist klar. Dafür macht der Vorstand auch Extra-Budget frei. 
Für Epics, Stories und Burndown-Charts? Eher nicht. 

So bleibt oft viel Geld auf der Straße liegen.

Ich kann mich an ein Beispiel erinnern, in dem ein Klient mit einem fertigen Angebot mit der Bitte um Feedback kam , ob es daran etwas zu verbessern gibt. 

3 Stunden später war das Angebot komplett umgeschrieben, von Time & Material auf Lizenzkosten pro User und Monat.  
Das neue Angebot wurde abgegeben und prompt angenommen. 
Die Differenz für meinen Klienten: über 500.000 Euro im Laufe von 3 Jahren.
Für dasselbe System. Das zeigt, wie viel es seinem Kunden tatsächlich wert war. 

So hat auch das Entwicklungsunternehmen einen fairen Anteil daran bekommen.

Natürlich, nicht immer ist das so einfach.

  • Es erfordert das Geschäftsmodell und die Welt des Kunden im Detail verstehen zu wollen.
  • Es erfordert eine andere Haltung als die eines braven Dienstleisters, der lieber vermeidet, Dinge beim Kunden zu hinterfragen. 
  • Es braucht den Biss, sich in die Entscheidungs-Ebene vorzuarbeiten, die für solche Angebote aufgeschlossen ist (der klassische Budget-Verwalter ist das meist nicht). 

Und manchmal braucht man auch ein wenig Risiko-Bereitschaft.


Nichts davon muss man machen. 
 
Aber man kann. 

Happy Selling!