Was Sie klären sollten, bevor Sie eigene Software entwickeln lassen
Projekte, die auf halbem Weg stehen bleiben, scheitern selten an der Technik. Sie scheitern an Fragen, die der Betrieb über sich selbst nie beantwortet hat.
Veröffentlicht am 4 Min. Lesezeit
Niemand kommt und fragt nach eigener Software. Man kommt und beschreibt ein Durcheinander: eine Tabelle, an der drei Personen gleichzeitig arbeiten, ein Werkzeug, das das meiste kann, und einen Umweg, den seit Jahren niemand mehr bemerkt.
Wenn es dann so weit ist, eigene Software entwickeln zu lassen, fühlt sich der Entscheid oft schon gefällt an. Und am Bauen scheitern diese Projekte selten. Sie scheitern an dem, was vorher niemand geklärt hat, und das liegt fast immer auf Ihrer Seite des Tisches, nicht auf der des Entwicklers.
Was sollten Sie klären, bevor Sie eigene Software entwickeln lassen?
Vier Punkte, alle vor Umfang und Preis: ob Sie Ihren Ablauf beschreiben können, ohne auf einen Bildschirm zu zeigen, wer entscheiden darf, wenn zwei Personen sich uneinig sind, in welchem Zustand Ihre Daten wirklich sind, und wem am Ende Quellcode, Zugänge und Dokumentation gehören.
Können Sie den Ablauf erklären, ohne die Software zu öffnen?
Versuchen Sie es einmal laut. Was kommt herein, wer fasst es an, was muss zutreffen, damit es weiter geht, und was passiert, wenn etwas fehlt.
Die meisten Betriebe erzählen den Normalfall in zwei Minuten und verbringen den Rest des Gesprächs mit Ausnahmen. Genau diese Ausnahmen sind das Projekt. Eine Regel wie «wir stellen am Monatsende Rechnung, ausser bei den zwei Kunden, bei denen wir es anders machen» muss zu etwas Ausdrücklichem werden: einer Einstellung, einer Berechtigung, einer Ausnahme, die jemand auslösen darf. Jeder dieser Punkte ist ein Entscheid, und jeder Entscheid, den Sie nicht treffen, trifft jemand anderes für Sie, indem er rät.
Ein Dokument brauchen Sie dafür nicht. Aber wenn niemand im Betrieb die Arbeit erklären kann, ohne sie am Bildschirm vorzuführen, beginnt das Projekt mit einer Aufnahme des Ist-Zustands. Das sollten Sie vorher wissen und nicht unterwegs merken.
Wer darf entscheiden?
Benennen Sie eine Person. Geben Sie ihr die Befugnis, stellvertretend für alle Nein zu sagen, und sorgen Sie dafür, dass sie regelmässig wirklich Zeit dafür hat, nicht nur dann, wenn es gerade passt.
Das klingt nach Formsache und ist der stärkste Hinweis darauf, ob ein Projekt fertig wird. Software erzwingt Fragen, um die sich ein Betrieb bequem herumgedrückt hat: Was ist eigentlich ein Kundendatensatz, welche Abteilung hat bei einem Status recht, darf ein Auftrag ohne Preis existieren. Wandern diese Fragen in eine Runde, werden sie später wieder aufgemacht. Wieder aufgemachte Entscheide sind der Grund, warum Umfang wächst und ein halb gebautes System am Ende von allem zwei Varianten hat.
In welchem Zustand sind Ihre Daten?
Das unterschätzen alle, auch Leute, die täglich damit arbeiten.
Daten, die für Menschen völlig brauchbar sind, sind für eine Maschine oft unbrauchbar. Dieselbe Kundin dreimal unterschiedlich erfasst. Telefonnummern mit und ohne Formatierung. Ein Bemerkungsfeld, das eine Bedeutung trägt, die nie jemand aufgeschrieben hat. Eine Statusspalte, in der vier Werte Schreibvarianten desselben Wortes sind.
Das zählt gleich doppelt. Einmal, weil die Daten vor dem Umzug bereinigt werden müssen, und einmal, weil das neue System Regeln durchsetzt, die das alte durchgehen liess, und damit alles sichtbar macht, was still im Argen lag. Nehmen Sie eine Stichprobe Ihrer Datensätze, etwa hundert, und lesen Sie sie richtig durch, bevor jemand die Übernahme offeriert. Es ist das Günstigste, was Sie im ganzen Projekt tun können.
Wem gehört es, wenn es fertig ist?
Hinter der Frage «was ist, wenn der Entwickler weg ist» steckt eigentlich die Eigentumsfrage, und die gehört in die Vereinbarung, nicht ins Wohlwollen. Drei Dinge brauchen Ihren Namen: der Quellcode, in einem Verzeichnis, auf das Sie zugreifen können; die Zugänge, also Domain, Hosting und Drittanbieterdienste auf Sie registriert und nicht auf eine Agentur; und eine Dokumentation, die eine andere Fachperson ohne Übergabegespräch lesen kann.
Fragen Sie auch, worauf es gebaut wird. Etwas Gewöhnliches und weit Verbreitetes bedeutet, dass die nächste Person leicht zu finden ist. Etwas Ausgefallenes verkleinert den Kreis, gelegentlich auf eine einzige Person.
Was danach von Ihnen verlangt wird
Eigene Software ist keine Anschaffung, die abgeschlossen ist. Browser ändern sich, Plattformen ändern sich, die angebundenen Dienste ändern sich, und was zwei Jahre lang unangetastet blieb, war nicht stabil, sondern hat sich entfernt. Planen Sie Aufmerksamkeit dafür ein, nicht nur für den Bau.
Rechnen Sie damit, dass die erste Fassung an einigen Stellen falsch ist. Das ist kein Planungsfehler, sondern das, was passiert, wenn Menschen etwas benutzen, statt es sich vorzustellen. Die nützliche Frage an einen Anbieter lautet, wie Änderungen nach dem Start ablaufen, denn damit leben Sie tatsächlich.
Und wenn sich der Ablauf selbst noch von Monat zu Monat ändert, warten Sie. Einen Prozess festzuschreiben, den Sie gerade erst erfinden, heisst dafür zu bezahlen, dass ein Entscheid dauerhaft wird, den Sie im Frühling wieder umdrehen.
Wenn die ehrliche Antwort kleiner ausfällt
Wenn Ihr heutiges Werkzeug das meiste kann und die Lücke jemanden ein paar Minuten pro Woche kostet, haben Sie vermutlich kein Softwareprojekt. Sie haben eine Anbindung, eine kleine Automatisierung oder eine Auswertung, die es noch nicht gibt. Das lässt sich günstiger ausprobieren und günstiger wieder verwerfen.
Gut laufen die Projekte, bei denen der Betrieb mit einem erklärbaren Ablauf kommt, mit einer Person, die entscheiden darf, und mit einem realistischen Bild der eigenen Daten. Nichts davon braucht eine Entwicklerin, und alles davon macht die Offerten, die Sie erhalten, überhaupt erst vergleichbar.
Wenn wir gemeinsam draufschauen und zum Schluss kommen, dass eine Verbindung zwischen zwei bereits bezahlten Werkzeugen genügt, dann sagen wir Ihnen das.