Software kaufen

Was Individualsoftware kostet, und was die Zahl wirklich bestimmt

Angebote zum selben Briefing unterscheiden sich routinemäßig um den Faktor fünf. Nicht, weil jemand zu viel verlangt — meist, weil sie Verschiedenes anbieten.

9 Min. Lesezeit Plexowave

Wir werden keine Preisliste veröffentlichen, und Sie sollten bei jedem vorsichtig sein, der es tut. Eine Zahl, die Ihren Anforderungen nie begegnet ist, ist eine Marketingzahl, und ihr Zweck ist, ein Gespräch zu beginnen, nicht genau zu sein. Was wir tun können, ist zu erklären, was die Zahl bewegt, damit Sie die Angebote lesen können, die Sie erhalten, und ein günstiges von einem unvollständigen unterscheiden.

Warum dasselbe Briefing völlig verschiedene Angebote erhält

Drei Gründe, und nur einer davon betrifft die Stundensätze.

Das erste ist die Auslegung des Umfangs. „Ein CRM für unser Vertriebsteam“ kann eine Leadliste mit Erinnerungen sein oder ein System mit Angebotserstellung, Freigabeworkflow, Telefonieanbindung und gebietsbezogener Auswertung. Beides sind ehrliche Lesarten. Die Angebote unterscheiden sich um den Faktor zehn.

Das zweite ist, was der Preis enthält. Manche Angebote decken nur die Entwicklung ab. Andere schließen Discovery, Datenmigration, Parallelbetrieb, Schulung, Deployment, eine Supportphase und die Korrekturen nach dem ersten Kontakt mit echten Nutzern ein. Das zweite ist meist die größere Zahl und fast immer die kleinere Gesamtsumme, weil die ausgeschlossene Arbeit trotzdem anfällt.

Das dritte ist der Stundensatz, und er zählt von den dreien am wenigsten. Ein Team zum halben Satz, das dreimal so lange braucht, ist nicht günstiger, und eine Entwicklung, die wiederholt werden muss, ist zu keinem Satz günstig.

Die sieben Dinge, die die Zahl am stärksten bewegen

  1. Die Anzahl unterschiedlicher NutzerrollenJede Rolle ist ein eigener Satz aus Bildschirmen, Berechtigungen und Tests. Ein System mit einer Rolle ist ein Bruchteil desselben Systems mit fünf, selbst wenn die zugrunde liegenden Daten identisch sind. Das ist meist der größte Einzeltreiber und wird im Briefing fast immer unterschätzt.
  2. Integrationen, und wer sie kontrolliertEine Integration mit einer dokumentierten modernen API ist planbare Arbeit. Eine Integration mit einem Altsystem, einer undokumentierten Datenbank, einem Anbieter, mit dem Termine vereinbart werden müssen, oder einem Portal ganz ohne API ist die am wenigsten planbare Arbeit im Projekt. Zwei gleichnamige Integrationen können sich um den Faktor zehn unterscheiden.
  3. DatenmigrationSaubere Daten aus einem System zu migrieren ist Routine. Ein Jahrzehnt Tabellen mit uneinheitlichen Codes, doppelten Parteien und Ausnahmen, an die sich niemand erinnert, zu migrieren, ist Archäologie. Die Arbeit steckt in den Ausnahmen, und niemand weiß, wie viele es sind, bis jemand nachsieht.
  4. Offline- und Mobilanforderungen„Es sollte auch auf Telefonen laufen“ kann ein responsives Layout meinen, das nahezu kostenlos ist, oder eine offlinefähige App mit Konfliktmodell für die Synchronisation, die ein Projekt für sich ist. Beides steht im selben Satz und wird sehr unterschiedlich kalkuliert.
  5. Compliance- und AuditanforderungenGesetzliche Berichte, Audit-Trails, Datenstandort, Aufbewahrungsregeln und Zugriffsprotokollierung sind echtes Engineering, keine Formalität. Sie schränken auch die Architektur ein, weshalb sie deutlich mehr kosten, wenn man sie spät entdeckt, als wenn man sie von Anfang an kennt.
  6. Wie stark sich die Anforderungen ändern werdenKein Mangel — eine Eigenschaft. Ist die Domäne gut verstanden und stabil, ist ein fester Umfang erreichbar. Bauen Sie etwas wirklich Neues, wird sich der Umfang bewegen, und ein Festpreisvertrag wird entweder dafür aufgepolstert oder führt zum Streit. Beides ist schlechter, als von vornherein ehrlich damit umzugehen.
  7. Performance und Skalierung, falls wirklich nötigDie meisten Geschäftssysteme haben moderate Last und sollten nicht so gebaut werden, als hätten sie sie nicht. Brauchen Sie aber echte Nebenläufigkeit, große Datenmengen oder strikte Antwortzeiten, dann ist das Architektur, Infrastruktur und Tests — und es muss vor der ersten Designentscheidung bekannt sein.

Was die Zahl weniger bewegt, als die meisten erwarten

Die Anzahl der Bildschirme. Bildschirme sind der sichtbare Teil und deshalb der Teil, den Briefings aufzählen, aber eine gut strukturierte Anwendung teilt den Großteil ihrer Mechanik zwischen ihnen. Zwanzig Bildschirme über einem sauberen Datenmodell kosten weit weniger als acht über vier Systemen, die sich widersprechen.

Visuelles Design, in Maßen. Eine durchdachte, konsistente Oberfläche auf Basis eines Designsystems ist nicht der teure Teil. Eine maßgeschneiderte visuelle Identität mit eigener Illustration und Animation kann es sein, aber das ist eine separate Entscheidung, die Sie unabhängig treffen können.

Die Wahl einer gängigen Technologie. Debatten über Frameworks ändern die Gesamtsumme selten. Was sie ändert, ist, ob die Leute, die es bauen, den Stack gut kennen und ob das auch für die gilt, die ihn danach pflegen.

Wie Sie zu einer Schätzung kommen, auf die Sie sich verlassen können

  • Bringen Sie die echten Unterlagen mit, keine Beschreibung. Ihre tatsächliche Preisliste, eine echte Rechnung, eine laufende Tabelle, den Bericht, den Ihr Vorgesetzter jeden Montag verlangt. Zwanzig Minuten mit echten Dokumenten schlagen eine Stunde ihrer Beschreibung.
  • Nennen Sie die drei Dinge, die zutreffen müssen, damit sich das Projekt lohnt. Das sind Ihre Anforderungen. Alles andere im Briefing ist verhandelbar, und zu wissen, was was ist, erlaubt ein Angebot mit klarem Umfang statt mit Aufschlag.
  • Fragen Sie, was das Angebot ausschließt. Die Antwort sagt mehr als die Zahl. Migration, Schulung, Parallelbetrieb und die Korrekturphase nach dem Start sind die üblichen Auslassungen.
  • Verlangen Sie es in Phasen, mit etwas früh im Produktivbetrieb. Ein Phasenplan bringt Schätzfehler zutage, solange sie klein sind — und gibt Ihnen die Option aufzuhören.
  • Fragen Sie nach der riskantesten Annahme. Wer die Arbeit tatsächlich geschätzt hat, antwortet sofort. Wer sagt, es gebe kein Risiko, hat nicht hingesehen.

Festpreis, Aufwand oder gedeckelt

Ein Festpreis passt zu gut verstandenem Umfang und verlagert das Risiko auf den Anbieter, der es einpreist. Das funktioniert, und der Preis dafür ist, dass Änderungen zu Vertragsereignissen werden — was alle defensiv macht, genau wenn das Projekt Flexibilität braucht.

Abrechnung nach Aufwand passt zu explorativer Arbeit und ist das ehrliche Modell, wenn der Umfang sich bewegt, aber sie erfordert Vertrauen und gibt Ihnen keine Obergrenze, sofern Sie keine setzen.

Ein gedeckeltes Modell je Phase ist meist das Beste davon: eine feste Zahl für eine Phase, deren Umfang wirklich verstanden ist, an jeder Phasengrenze mit dem Gelernten neu geschätzt. Sie bekommen Planbarkeit, wo sie möglich ist, und Flexibilität, wo sie es nicht ist.

Der billigste teure Fehler

Allein nach Preis auswählen und in achtzehn Monaten neu bauen. Das ist häufig genug, um für Erstkäufer das Standardergebnis zu sein. Die Warnzeichen sind stets dieselben: ein Angebot deutlich unter den anderen ohne Erklärung, keine Discovery vor der Zahl, keine Fragen zu Ihren Daten und ein Liefertermin, der unterstellt, während der Entwicklung werde nichts dazugelernt.

Ein Angebot, das niedriger ist, weil der Anbieter die Domäne versteht und Ähnliches gebaut hat, ist tatsächlich der bessere Preis. Ein Angebot, das niedriger ist, weil Migration, Tests und Parallelbetrieb fehlen, ist derselbe Preis, später gezahlt, in schlechterer Reihenfolge.

Fragen

Häufige Fragen.

Warum nennen Sie auf Ihrer Website keine Preisspanne?

Weil eine Spanne, die weit genug ist, um ehrlich zu sein, zu weit ist, um zu nützen, und eine, die eng genug ist, um zu nützen, für die meisten Anfragen falsch wäre. Wir verbringen lieber eine Stunde mit Ihren tatsächlichen Anforderungen und geben Ihnen eine Zahl mit niedergeschriebenen Annahmen.

Berechnen Sie die Discovery-Phase?

Ein erstes Gespräch und eine grobe Einschätzung kosten nichts. Eine richtige Discovery — mit Ihrem Team sitzen, Ihre echten Unterlagen lesen, eine Spezifikation und eine belastbare Schätzung erstellen — ist kostenpflichtige Arbeit, und das Ergebnis gehört Ihnen, ob Sie mit uns weitermachen oder nicht.

Welche laufenden Kosten sollten wir nach dem Start einplanen?

Planen Sie Hosting, Monitoring und ein Änderungsbudget ein. Das Änderungsbudget lässt man gern weg, und genau es entscheidet, ob das System in drei Jahren noch nützlich ist. Software, die sich nicht ändern lässt, wird ersetzt.

Ist ein Stundensatz oder ein Projektpreis besser für uns?

Für einen wirklich verstandenen Umfang gibt Ihnen ein gedeckelter Preis je Phase Planbarkeit. Für explorative Arbeit ist Stundenabrechnung ehrlicher — ein Festpreis auf unklaren Umfang ist entweder aufgepolstert oder steuert auf Streit zu.

Stehen Sie gerade vor dieser Entscheidung?

Beschreiben Sie das Problem statt der Lösung. Wenn die Antwort ein Produkt ist, das Sie kaufen können, oder gar keine Software, sagen wir das.

Projekt starten