Sie wollen für ein IT-Vorhaben Angebote einholen, und die erste Frage jedes Anbieters lautet: „Haben Sie dazu etwas Schriftliches?“ Dieses Schriftliche ist das Lastenheft. Wer es hat, bekommt Angebote, die sich vergleichen lassen. Wer es nicht hat, bekommt drei Angebote für drei verschiedene Projekte.
Dieser Beitrag zeigt, was ein Lastenheft ist, was für ein IT-Projekt hineingehört, was ausdrücklich nicht, und wie Sie damit eingehende Angebote prüfen. Er richtet sich an Geschäftsführung, Inhaber und Verantwortliche ohne eigene IT-Abteilung.
Was ist ein Lastenheft?
Ein Lastenheft ist das Dokument, in dem der Auftraggeber festhält, was er erreichen will und unter welchen Bedingungen. Es beantwortet vier Fragen:
- Wo stehen wir, und warum soll sich etwas ändern?
- Welches Ergebnis soll danach existieren?
- Was gilt dabei als Rahmen: Bestand, Daten, Betrieb, Zeit, Budget?
- Woran erkennen wir, dass das Ergebnis erreicht ist?
Das Lastenheft beschreibt also das Was und das Wozu. Das Wie bleibt offen, weil es Sache des Anbieters ist, einen Weg vorzuschlagen. Genau darin liegt sein Wert: Es ist die Schablone, an der jedes Angebot gemessen wird.
Lastenheft und Pflichtenheft: wer schreibt was
Die beiden Begriffe werden oft in einem Atemzug genannt und im Alltag auch vermischt. Die gebräuchliche Trennung ist einfach:
| Lastenheft | Pflichtenheft | |
|---|---|---|
| Frage | Was soll erreicht werden, und wozu? | Wie und womit wird es umgesetzt? |
| Schreibt | Auftraggeber | meist der Auftragnehmer, als Antwort |
| Zeitpunkt | vor dem Angebot | mit oder nach dem Angebot |
| Zweck | Angebote vergleichbar machen | Umsetzung festlegen und abnehmbar machen |
Für Ihre Entscheidung heißt das: Das Lastenheft ist Ihr Dokument, es entsteht zuerst, und es bleibt der Maßstab, wenn später ein Pflichtenheft vorliegt. Passt das Pflichtenheft nicht mehr zum Lastenheft, hat der Anbieter etwas anderes verstanden, als Sie gemeint haben. Das sollten Sie vor der Beauftragung wissen, nicht danach.
Lastenheft für ein IT-Projekt: was hineingehört
Ein brauchbares Lastenheft für Software, ERP, CRM oder eine Schnittstelle hat meist sieben Teile. Länge ist dabei kein Qualitätsmerkmal. Entscheidend ist, dass jeder Teil beantwortet ist.
1. Ausgangslage und Ziel
Zwei bis fünf Sätze: Was ist heute, was stört, was soll anders sein? Nicht „Wir brauchen ein neues CRM“, sondern „Kundendaten liegen in drei Dateien und einem Postfach, Angebote werden doppelt angelegt, niemand sieht den Stand eines Auftrags“. Das Ziel ist ein Zustand, kein Produkt.
2. Das geschuldete Ergebnis
Was soll nach dem Projekt existieren und funktionieren? „Ein System, in dem Vertrieb und Innendienst denselben Auftrag sehen“ ist ein Ergebnis. „Einführung eines CRM“ ist eine Tätigkeit. Der Unterschied entscheidet später, was abnehmbar ist.
3. Anforderungen mit Gewichtung
Listen Sie Anforderungen einzeln und kurz auf, jede mit einer Gewichtung: muss, soll, kann. Eine Anforderung ist gut formuliert, wenn man an ihr nachprüfen kann, ob sie erfüllt ist. „Schnell“ lässt sich nicht prüfen, „ein Auftrag erscheint innerhalb von fünf Minuten im zweiten System“ schon. Die Werte müssen aus Ihrem Betrieb stammen, nicht aus einer Vorlage.
4. Bestand und Schnittstellen
Welche Systeme laufen schon, welche Daten liegen wo, womit muss das Neue reden? Das ist der Teil, den fast alle Vorlagen zu kurz halten und der in der Praxis die Kosten treibt. Ein Anbieter, der Ihren Bestand nicht kennt, kalkuliert ihn als unproblematisch. Schreiben Sie auf, was Sie wissen, und markieren Sie, was Sie nicht wissen.
5. Daten und Betrieb
Wer ist fachlich für die Daten zuständig? Was muss übernommen werden, was nicht? Wer betreibt das System nach dem Start, wer bekommt Zugänge, wer haftet für Ausfälle? Dazu gehören auch Datenschutzfragen, die Ihr Betrieb ohnehin klären muss. Wem Code, Daten und Konten nach der Übergabe gehören, gehört ebenfalls hierher.
6. Rahmen: Zeit, Budget, Mitwirkung
Nennen Sie einen Zeitrahmen und, wenn Sie können, ein Budget oder eine Spanne. Ein genannter Rahmen verhindert, dass Angebote in Größenordnungen auseinanderliegen, die sich nicht erklären lassen. Schreiben Sie außerdem, was Ihre Seite beiträgt: Wer entscheidet, wer steht für Fragen bereit, welche Zugänge liefern Sie bis wann?
7. Abnahmekriterien
Woran erkennen Sie, dass geliefert wurde? Ein Fall, der durchläuft, ein Bestand, der übereinstimmt, ein Dokument, das existiert. Diese Kriterien sind der Teil, der später den Streit verhindert. Wie sich die Abnahme auf Vergütung und Gewährleistung auswirkt, steht im Beitrag Woran erkennt man, dass ein IT-Angebot nicht trägt?.
Was nicht ins Lastenheft gehört
Ebenso wichtig ist, was fehlt. Drei Dinge schreiben Sie nicht hinein.
Die Lösung. „Wir wollen Produkt X mit einer Schnittstelle über Y“ ist keine Anforderung, sondern eine Vorentscheidung. Sie nehmen damit dem Anbieter die Möglichkeit, einen besseren Weg vorzuschlagen, und Ihnen die Möglichkeit, Wege zu vergleichen. Beschreiben Sie das Problem und das Ergebnis, nicht die Technik.
Wünsche ohne Gewicht. Eine Liste mit achtzig gleich wichtigen Punkten zeigt nicht, was zählt. Anbieter bepreisen dann alles oder nichts. Wenn jede Zeile „muss“ heißt, ist keine Zeile ein Maßstab.
Annahmen, die Sie nicht geprüft haben. „Die Schnittstelle des alten Systems ist dokumentiert“ gehört nur hinein, wenn jemand es gesehen hat. Ist es unklar, steht dort „unklar“. Ein Lastenheft, das Annahmen als Tatsachen behandelt, verschiebt das Risiko unbemerkt zu Ihnen.
Lastenheft schreiben in fünf Schritten
Der Weg ist wichtiger als die Vorlage. Eine ausgefüllte Vorlage ist noch kein Lastenheft, wenn niemand die Fragen dahinter beantwortet hat.
- Problem benennen. Eine halbe Seite, ohne Produktnamen. Wer das Problem nicht in drei Sätzen erklären kann, ist für das Lastenheft noch zu früh dran.
- Beteiligte hören. Sprechen Sie mit denen, die das heutige System täglich benutzen, nicht nur mit denen, die es bezahlen. Die wichtigsten Anforderungen stehen meist nicht in Konzepten, sondern in Gewohnheiten.
- Bestand aufnehmen. Systeme, Datenquellen, Schnittstellen, Verantwortliche. Das kostet Zeit und ist der Teil, der Angebote verlässlich macht.
- Anforderungen gewichten und prüfbar machen. Jede Zeile einmal fragen: Woran würden wir sehen, dass das erfüllt ist? Was keine Antwort hat, wird gestrichen oder umformuliert.
- Gegenlesen lassen. Von jemandem, der nicht am Text mitgeschrieben hat. Fragt diese Person „Was ist hier gemeint?“, wird jeder Anbieter dieselbe Frage stellen, aber erst nach der Unterschrift.
Angebote gegen das Lastenheft lesen
Der Nutzen zeigt sich, wenn die Angebote eintreffen. Legen Sie jedes neben das Lastenheft und prüfen Sie vier Dinge:
- Deckt es die Muss-Anforderungen ab? Fehlt eine, steht sie als Ausnahme im Angebot oder gar nicht. Beides ist eine Information.
- Nennt es das Ergebnis oder die Tätigkeit? Ein Angebot, das Ihr Ergebnis in Verben umschreibt, hat den Maßstab nicht übernommen.
- Stehen die Annahmen zum Bestand drin? Ein Anbieter, der Ihre Systeme nicht gesehen hat und es nicht sagt, hat sie als einfach unterstellt.
- Passt die Abnahme zu Ihren Kriterien? Wenn nicht, wird später über „fertig“ verhandelt.
Mit demselben Raster lassen sich die Angebote untereinander vergleichen. Das ist mehr wert als ein Vergleich der Summen: Sie sehen, welcher Preis welchen Schnitt abdeckt. Wie Sie ein einzelnes Angebot darüber hinaus auf Tragfähigkeit prüfen, steht im Beitrag IT-Angebot prüfen. Für ein Architekturkonzept gilt ein ähnlicher Maßstab, beschrieben in Wie Sie ein Architekturkonzept prüfen.
Typische Fehler
Häufig liegt es an wenigen Mustern, wenn ein Lastenheft nichts nützt:
- Es wird vom späteren Anbieter geschrieben, sodass dessen Lösung zur Anforderung wird.
- Es beschreibt ein Produkt statt eines Problems.
- Es ist so lang, dass niemand es liest, oder so kurz, dass es nichts festlegt.
- Es kennt den Bestand nicht und sagt das nicht.
- Es hat keine Abnahmekriterien, sodass am Ende „fertig“ Meinungssache ist.
- Es wird nach der Beauftragung nicht mehr angefasst, obwohl sich die Lage ändert.
Wann Sie kein Lastenheft brauchen
Nicht jede Beschaffung braucht eines. Es lohnt nicht, wenn:
- Sie ein Katalogprodukt mit öffentlicher Preisliste kaufen. Dann genügt eine kurze Bedarfsliste, und die Frage ist, ob Sie das Produkt brauchen.
- Die Entscheidung schon gefallen ist und das Dokument nur die Akte füllen würde. Dann erzeugt es einen Ordner, keine Klarheit.
- Das Vorhaben so klein ist, dass ein gescheiterter Auftrag weniger kostet als das Schreiben.
- Sie noch gar nicht wissen, was das Problem ist. Dann steht zuerst eine Analyse an, und das Lastenheft ist ihr Ergebnis, nicht ihr Anfang.
Auch bei Ablösungen gewachsener Systeme ist die Reihenfolge wichtig: Erst die Entscheidung zwischen Neubau, Ablösung und Weiterbetrieb, dann das Lastenheft. Die Kriterien dafür stehen in Neu bauen, ablösen oder weiterbetreiben.
Wenn niemand im Haus das Lastenheft prüfen kann
Manchmal ist das Dokument fast fertig und die Unsicherheit bleibt: Ist der Bestand vollständig beschrieben? Sind die Abnahmekriterien prüfbar? Fehlt eine Schnittstelle, die später teuer wird? Genau dafür ist die Technische Begleitung gedacht: laufende Unterstützung für Unternehmen ohne IT-Leitung, bei der Entscheidungen gegengezeichnet und Dienstleister eingeordnet werden. Ab 1.900 € netto im Monat.
Liegt statt eines Lastenhefts schon ein Angebot auf dem Tisch und eine Frist läuft, ist die Architektur-Zweitmeinung der kürzere Weg: eine Woche, 1.400 € netto, ein Dokument mit klarer Aussage. Wenn nach einem Dienstleisterwechsel vieles unklar ist, hilft vorab der Beitrag Was nach einem Dienstleisterwechsel zuerst zu prüfen ist.