Selbst gebaute Tools im Betrieb: wann einfach machen, wann prüfen lassen
Eine Auswertung für das nächste Meeting. Ein Rechner für die eigene Kalkulation. Eine Liste, die endlich nicht mehr auf drei Excel-Dateien verteilt ist. Solche Werkzeuge baut man sich heute mit KI an einem Abend, ohne Entwickler und ohne ausgefeilte Architektur.
Das ist in Ordnung. Ein Tool, das nur Sie selbst benutzen, muss nicht gebaut sein, als müsse es zehn Jahre laufen. Wenn es tut, was es soll, reicht das. Geht es kaputt, baut man es neu.
Das gilt mit zwei Einschränkungen. Die Daten darin müssen sich leicht ersetzen lassen. Schon die Kalkulation oder die zusammengeführte Liste kann nach ein paar Monaten Einträge enthalten, die es sonst nirgends mehr gibt. Und an den Ergebnissen darf keine Entscheidung hängen, bei der ein Fehler teuer wird.
Das Tool bleibt gleich, seine Rolle wächst
Schwierig wird es, wenn das Tool unverändert bleibt, aber seine Rolle wächst.
Ein Kollege fragt, ob er es auch nutzen kann. Jemand trägt zum ersten Mal Kundendaten ein. Eine andere Abteilung übernimmt die Ergebnisse, ohne sie selbst noch einmal zu prüfen. Oder das Tool soll ins Netz, damit mehr Menschen darauf zugreifen können.
Auf Freelancer-Portalen tauchen inzwischen Anfragen auf wie: „Mit Claude fertig gebaute App, muss nur noch online.“ Das „nur noch“ ist die Stelle, an der es kippt. Mit dem Schritt ins Netz kommen Fragen dazu, die vorher keine Rolle gespielt haben: wer sich anmelden kann, wer was sieht und wer sich kümmert, wenn das Tool nicht erreichbar ist.
In keinem dieser Fälle muss sich eine Zeile Code ändern. Was sich ändert, ist die Tragweite, wenn etwas schiefgeht.
Vier Fragen zum Einordnen
Wer hängt davon ab? Dazu gehören nicht nur die Menschen, die das Tool bedienen, sondern auch die, die von seinen Ergebnissen betroffen sind. Rechnet Ihr eigener Kalkulationsrechner falsch, fällt das womöglich niemandem auf, und das Angebot geht trotzdem raus. Arbeiten andere damit oder verlassen sich auf seine Ergebnisse, trifft ein Fehler Menschen, die nicht wissen, wie das Tool entstanden ist und wo seine Grenzen liegen.
Was passiert, wenn es ausfällt? Fällt ein persönlicher Rechner einen Tag aus, rechnet man von Hand. Hängt ein Prozess im Betrieb daran, etwa die Planung oder die Annahme von Aufträgen, steht dieser Prozess still. Und manchmal fällt ein Tool gar nicht sichtbar aus, sondern liefert still falsche Ergebnisse.
Was kostet es, es neu zu machen? Der Code ist mit KI schnell neu geschrieben. Die Daten darin, die Einstellungen und die Abläufe, die sich inzwischen auf das Tool eingestellt haben, sind es nicht. Je länger ein Tool im Einsatz ist, desto mehr hängt an Dingen, die sich nicht neu erzeugen lassen.
Wer kümmert sich, wenn sich etwas ändert? Angebundene Dienste ändern ihre Schnittstellen, verwendete Bibliotheken brauchen Sicherheitsupdates, Anforderungen wachsen. Irgendwer muss das Tool dann anpassen. Ist das die Person, die es an einem Abend gebaut hat, und ist sie noch da, wenn es so weit ist?
Die vier Fragen sind in zwei Minuten gestellt. Am einfachsten stellt man sie, sobald man überlegt, ob das Tool auch für andere nützlich wäre.
Drei Situationen
Wie unterschiedlich die Antworten ausfallen, zeigen drei typische Situationen.
Ein Rechner, den nur Sie nutzen. Er nimmt Eingaben, rechnet und zeigt ein Ergebnis. Gespeichert wird nichts, jedes Ergebnis lässt sich jederzeit neu erzeugen. Lassen sich die Ergebnisse leicht kontrollieren und hat ein Fehler überschaubare Folgen, wäre eine aufwendige Prüfung meist unverhältnismäßig. Dann reicht es oft, ein paar Ergebnisse von Hand nachzurechnen. Fließen die Ergebnisse direkt in Angebote oder Bestellungen, lohnt ein genauerer Blick.
Eine gemeinsame Liste, die mehrere Kollegen pflegen. Jetzt verändern mehrere Menschen dieselben Daten. Dann sollte klar sein, wer was sehen und ändern darf und ob es eine Sicherung gibt, falls jemand versehentlich etwas überschreibt oder löscht. Das lässt sich oft mit überschaubarem Aufwand klären. Geklärt sein sollte es, bevor die Liste die einzige Quelle für diese Daten ist.
Eine Anwendung mit Kundenzugang oder mit Ergebnissen, auf die sich ein Prozess verlässt. Kunden melden sich an und sehen ihre Aufträge oder Rechnungen. Oder die Produktion plant nach dem, was die Anwendung ausgibt. Hier reichen ein paar erfolgreiche Testläufe nicht mehr. Dass die Anwendung im normalen Gebrauch funktioniert, sagt nichts darüber, ob ein Kunde die Daten eines anderen sehen kann, wenn er die Adresse im Browser leicht verändert, oder was passiert, wenn ein angebundener Dienst nicht antwortet. Das muss man gezielt prüfen. Dafür sollte jemand mit entsprechender Erfahrung draufschauen, der die Anwendung nicht selbst gebaut hat.
Die Folgen bestimmen den Prüfbedarf
Wie viel Prüfung ein Tool braucht, hängt vom Einsatz und seinen möglichen Folgen ab. Ob es mit KI, mit einem Baukasten oder von Hand entstanden ist, spielt dafür kaum eine Rolle. Für die Prüfung selbst ist die Bauweise trotzdem wichtig. Jede Plattform und jede Art zu bauen hat ihre typischen Schwachstellen, und wer prüft, sollte sie kennen.
Eine Prüfung muss nichts finden
Wer jemanden holt, um eine Anwendung zu prüfen, erwartet ein Ergebnis. Und wer geholt wird, kommt ungern mit leeren Händen zurück. Ein Bericht mit zwölf Punkten sieht nach Arbeit aus, einer mit „keine wesentlichen Risiken“ schnell nach verschwendetem Geld.
Dazu kommt: Auch mir fallen in fremdem Code nach einer Stunde zehn Dinge auf, die ich anders gebaut hätte. Das heißt noch lange nicht, dass eines davon ein Problem für Ihren Einsatz ist.
Deshalb gehört zu einer brauchbaren Prüfung, dass „in den geprüften Bereichen keine wesentlichen Risiken für den vorgesehenen Einsatz“ ein zulässiges Ergebnis ist. Manchmal ist es sogar das wertvollste. Man muss es vorher nur erlauben.
Bevor Ihr Tool diesen Schritt macht, kann ich es mir ansehen. Im ersten Gespräch klären wir, wer es nutzt, welche Daten es verarbeitet und wo es laufen soll. Manchmal zeigt sich schon dort, dass keine Prüfung nötig ist. Mehr dazu unter Selbst gebaute Anwendungen prüfen.