Was der Betrieb kostet, wenn das Projekt fertig ist

Die Anwendung ist abgenommen, die Schlussrechnung bezahlt, alle sind zufrieden. Und dann läuft das Ding. Auf einem Server, den jemand bezahlt. Mit Sicherungen, die jemand prüft. Mit Zugängen, die jemand vergibt, wenn eine neue Mitarbeiterin anfängt.

Über diesen Teil wird selten gesprochen, weil er beim Angebot noch weit weg ist. Er entscheidet aber darüber, ob die Software in drei Jahren noch tut, was sie soll, oder ob sie an einem Dienstagvormittag stehenbleibt und niemand weiß, warum.

Wer im Netz nach Zahlen sucht, findet fast nur Website-Kosten: Hosting, Domain, Pflege. Für eine gebaute Anwendung wird die Frage anders beantwortet, nämlich meistens gar nicht. Deshalb hier die Posten einzeln, und danach die Frage, die kaum jemand stellt.

Was kostet die Wartung einer Software pro Jahr?

Eine allgemeingültige Zahl dafür gibt es nicht, und du solltest misstrauisch werden, wenn dir jemand eine nennt.

Es kursiert eine Faustregel: fünfzehn bis fünfundzwanzig Prozent der Entwicklungskosten pro Jahr. Die Zahl klingt handfest, aber sie lässt sich auf keine belastbare Quelle zurückführen. In den Quellen, die sie verwenden, steht keine Erhebung dahinter, und die Obergrenze schwankt je nach Anbieter zwischen zwanzig und vierzig Prozent. Das ist keine Kennzahl, das ist ein Gefühl, das sich durch Wiederholung verfestigt hat.

Brauchbar ist die Regel trotzdem für eine Sache: als Erinnerung daran, dass der Betrieb einen erheblichen Anteil ausmacht und nicht mit einem Rundungsbetrag abgetan ist. Wer wissen will, was es bei ihm kostet, schreibt die Posten einzeln auf.

Welche Posten fallen wirklich an?

Acht Positionen decken fast jede gebaute Anwendung ab. Nicht alle treffen auf jeden Fall zu, aber jede sollte bewusst gestrichen und nicht vergessen werden.

• Betrieb der Anwendung. Der Server oder Dienst, auf dem sie läuft. Der Preis hängt daran, wie viele Leute gleichzeitig damit arbeiten und wie viel gerechnet wird.
• Datenbank. Wird gern mit dem Server in einen Topf geworfen und ist doch ein eigener Posten, sobald sie getrennt läuft. Sie ist auch die Stelle, an der man am wenigsten sparen sollte.
• Sicherungen. Speicherplatz für die Kopien, und zwar an einem anderen Ort als die Anwendung selbst. Eine Sicherung auf demselben Server ist keine.
• Domain und Zertifikat. Kleiner Posten, aber wenn er ausläuft, steht die Anwendung.
• Überwachung. Etwas, das meldet, wenn die Anwendung nicht mehr antwortet. Ohne das erfährst du es von deinen Mitarbeitern, im besten Fall.
• Aktualisierungen. Jede Anwendung besteht zum größten Teil aus fremden Bausteinen, und in denen werden laufend Sicherheitslücken gefunden und geschlossen. Diese Aktualisierungen einzuspielen und danach zu prüfen, ob noch alles läuft, ist wiederkehrende Arbeit.
• Zugänge und Rechte. Jemand kommt neu dazu, jemand geht, jemand wechselt die Abteilung. Bei fünf Personen macht man das nebenbei, bei fünfzig ist es eine Aufgabe.
• Änderungen. Kein Betrieb bleibt drei Jahre gleich. Ein Feld kommt dazu, ein Ablauf ändert sich, eine Auswertung wird gebraucht. Dafür gehört ein Budget eingeplant, sonst wird jede Kleinigkeit zur Verhandlung.

Zur Website gehört dieselbe Rechnung, und sie wird meist getrennt geführt, obwohl beides im selben Betrieb läuft und aus demselben Topf bezahlt wird. Wenn du ohnehin gerade aufschreibst, was laufend anfällt, nimm sie mit dazu. Ob dort alles in Ordnung ist, lässt sich an ein paar Stellen prüfen, die man von außen nicht sieht.

Was läuft automatisch, und was braucht einen Menschen?

Das ist die Trennlinie, die in Angeboten fast immer fehlt, und sie erklärt die meisten bösen Überraschungen.

Automatisch läuft: der Server, die Datenbank, die nächtliche Sicherung, die Erneuerung des Zertifikats, die Meldung bei einem Ausfall. Das sind Dinge, die man einmal einrichtet und die danach ohne Zutun weiterlaufen.

Einen Menschen braucht: die Entscheidung, ob eine Aktualisierung eingespielt wird und wann. Der Blick auf die Meldung, wenn nachts etwas fehlgeschlagen ist. Das Zurückspielen einer Sicherung, wenn es ernst wird. Die Frage, warum ein bestimmter Vorgang seit Dienstag nicht mehr ankommt.

Anders gesagt: Automatisierung senkt den Aufwand, sie beseitigt ihn nicht. Wer eine Anwendung ohne einen zuständigen Menschen betreibt, betreibt sie so lange gut, bis das erste Mal etwas nicht nach Plan läuft.

Wer betreibt die Software nach dem Projekt?

Das gehört vor das Projekt, nicht danach. Drei Wege sind üblich, und jeder hat eine Bedingung.

Der Entwickler betreibt weiter. Der bequemste Weg, weil derjenige die Anwendung kennt. Die Bedingung: Es braucht eine klare Abrede, was in der Pauschale enthalten ist und was extra kostet, und in welcher Zeit reagiert wird, wenn etwas steht.

Ein anderer Dienstleister übernimmt. Möglich, aber nur, wenn die Anwendung übergabefähig ist. Das ist sie nicht automatisch, sondern nur, wenn sie von Anfang an so gebaut wurde.

Der Betrieb wandert nach innen. Sinnvoll, wenn jemand da ist, der sich damit befassen kann und will. Die Bedingung ist eine Anleitung, die auch jemand versteht, der nicht dabei war.

In allen drei Fällen gilt derselbe Grundsatz, und er ist wichtiger als jede Preisverhandlung: Die Konten laufen auf dich, nicht auf den Dienstleister. Der Serveranbieter, die Domain, die Datenbank, der Zugang zum Quellcode. Wer das nicht durchsetzt, kann später nicht wechseln, ohne bei null anzufangen.

Was gehört in die Übergabe?

Diese Liste gehört in den Vertrag, nicht ans Ende der Zusammenarbeit. Sechs Punkte:

1. Zugang zu allen Konten, auf deinen Namen. Server, Domain, Datenbank, Mailversand, jeder Fremddienst, der eingebunden ist. Nicht als geteiltes Passwort, sondern als eigenes Konto, aus dem du andere entfernen kannst.
2. Der vollständige Quellcode in deinem eigenen Repository. Nicht als ZIP-Datei per Mail, sondern in einem Konto, das dir gehört, mit der ganzen Entstehungsgeschichte.
3. Eine Anleitung zum Neuaufsetzen. Also: Wie bringt man die Anwendung auf einem leeren Server zum Laufen? Diese Anleitung ist der einzige belastbare Beweis dafür, dass die Übergabe funktioniert.
4. Zugriff auf die Sicherungen, und ein getestetes Zurückspielen. Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Einmal ausprobieren, im Beisein von beiden.
5. Eine Liste der laufenden Verträge mit Kündigungsfristen. Welche Abos hängen an der Anwendung, was kosten sie, wann laufen sie aus.
6. Eine Übersicht, was automatisch läuft und was jemand anstoßen muss. Mit dem Hinweis, woran man merkt, dass etwas nicht gelaufen ist.

Wenn ein Dienstleister bei dieser Liste ausweicht, ist das die wichtigste Information, die du in dem Gespräch bekommst.

Was passiert, wenn nichts gewartet wird?

Zunächst nichts, und genau das ist das Tückische daran. Eine Anwendung, die niemand anfasst, läuft weiter, oft monatelang.

In dieser Zeit passiert Folgendes im Hintergrund: Zertifikate laufen ab. In den fremden Bausteinen, aus denen die Anwendung besteht, werden Sicherheitslücken bekannt und veröffentlicht. Anbieter von Schnittstellen schalten alte Versionen ab. Die Sicherung läuft ins Leere, weil sich ein Zugang geändert hat, und niemand bekommt es mit, weil niemand hinsieht.

Der Ausfall kommt dann selten schleichend, sondern an einem Tag, an dem eine Kleinigkeit kippt. Und der Aufwand, eine drei Jahre nicht angefasste Anwendung wieder auf einen aktuellen Stand zu bringen, ist regelmäßig höher als die Wartung, die man sich gespart hat. Das liegt daran, dass viele kleine Aktualisierungen zusammen ein großer Sprung sind, bei dem man nicht mehr weiß, welche davon etwas kaputt gemacht hat.

Wann reicht auch weniger?

Nicht jede Anwendung braucht dasselbe Maß. Drei Fragen entscheiden.

Steht die Anwendung im Internet oder nur im Haus? Etwas, das von außen erreichbar ist, braucht Aktualisierungen zeitnah. Ein Werkzeug, das nur im Betriebsnetz läuft, verträgt einen ruhigeren Takt.

Was passiert, wenn sie einen Tag steht? Wenn dann die Auftragsannahme steht, ist das etwas anderes, als wenn eine Auswertung später kommt. Danach richtet sich, wie schnell jemand reagieren muss, und das ist der Posten, der den Preis am stärksten treibt.

Liegen personenbezogene Daten darin? Wenn ja, ist die Frage nach Aktualisierungen und Zugriffsrechten keine Komfortfrage mehr.

Bei einer kleinen internen Anwendung ohne sensible Daten kann die Antwort lauten: Sicherungen laufen automatisch, Aktualisierungen einmal im Quartal, sonst nach Aufwand. Das ist eine vertretbare Entscheidung, solange sie bewusst getroffen wurde und nicht aus Versehen entsteht.

Wie du es überschlägst

Nimm die acht Posten von oben und setz für jeden eine Zahl ein, die du entweder kennst oder erfragen kannst. Bei den ersten fünf sind es Preise von Anbietern, die man nachschlagen kann. Bei den letzten dreien ist es Arbeitszeit: Wie viele Stunden im Jahr rechnest du für Aktualisierungen, Zugangsverwaltung und kleine Änderungen?

Diese Summe ist deine Zahl. Sie ist belastbarer als jeder Prozentsatz aus dem Netz, weil sie aus deinem Fall stammt. Und sie gehört in denselben Vergleich wie der Anschaffungspreis, wenn die Frage ansteht, ob die Rechnung über fünf Jahre für ein fertiges Produkt oder für etwas Eigenes besser aussieht.

Der häufigste Fehler ist nicht, dass jemand zu wenig einplant. Der häufigste Fehler ist, dass gar nicht darüber gesprochen wird und die Posten dann einzeln und überraschend auftauchen.