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.
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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.