Entwickeln und beschaffen

    Individualentwicklung richtig einsetzen

    Von Redaktion techport.ai, IT-Beratung · Zuletzt aktualisiert am

    Individualsoftware hat im Mittelstand einen schlechten Ruf, und oft zu Unrecht. Sie ist der Grund, warum manche Unternehmen einen Prozess beherrschen, den der Wettbewerb nicht abbilden kann. Sie ist aber auch der Grund, warum in anderen Unternehmen ein zentrales System von genau einer Person abhängt, die nichts dokumentiert hat.

    Der Unterschied liegt nicht in der Entscheidung für oder gegen Eigenentwicklung, sondern darin, wofür sie eingesetzt wird und unter welchen Bedingungen. Für einen Prozess, der Ihr Geschäft unterscheidbar macht, kann sie die richtige Wahl sein. Für Aufgaben, die tausend andere Unternehmen genauso haben, ist sie fast immer die teurere.

    Woran Sie es merken

    • Eine geschäftskritische Anwendung wird von einer einzigen Person gepflegt.
    • Es gibt keine Testumgebung, Änderungen werden im laufenden System gemacht.
    • Der Quellcode liegt beim Dienstleister, und im Vertrag steht dazu nichts.
    • Niemand weiß, welche Bibliotheken verwendet werden und ob sie noch gepflegt sind.

    Warum das passiert

    Eigenentwicklungen beginnen klein und aus gutem Grund: Ein Standardprodukt passt nicht, ein kleines Werkzeug löst das Problem in zwei Wochen. Dieses Werkzeug wird nützlich, wächst und wird nach einigen Jahren geschäftskritisch, ohne je den Status eines Systems bekommen zu haben. Es gibt keine Übergabe, keine Dokumentation, keine Tests und kein Budget für Pflege, weil es formal nie ein Projekt war. Der Aufwand wird erst sichtbar, wenn etwas nicht mehr funktioniert oder die Person geht.

    So gehen wir vor

    1. Entscheidung begründen. Wir prüfen vor jeder Eigenentwicklung drei Alternativen: Standardsoftware, Anpassung eines vorhandenen Systems oder Änderung des Prozesses. Eigenentwicklung wird gewählt, wenn der Prozess wirklich unterscheidend ist oder wenn kein Markt für die Anforderung existiert, und die Begründung wird festgehalten.
    2. Bedingungen festlegen. Wir klären vorab, was zum Ergebnis gehört: Quellcode, Dokumentation, automatisierte Tests, Umgebungen für Entwicklung und Test, Nutzungs- und Bearbeitungsrechte, Übergabe an Dritte und Regelungen für Wartung und Weiterentwicklung.
    3. Abhängigkeiten begrenzen. Wir sorgen dafür, dass mindestens zwei Personen oder ein Dienstleister plus eine Person im Haus das System verstehen, dass gängige Technik statt Nischenlösungen verwendet wird und dass verwendete Bausteine gepflegt und lizenzrechtlich geprüft sind.
    4. Betrieb einplanen. Wir kalkulieren von Anfang an mit laufendem Aufwand für Aktualisierungen, Sicherheitskorrekturen und Anpassungen, typischerweise ein spürbarer Anteil der ursprünglichen Entwicklungskosten pro Jahr. Ohne diesen Posten ist jede Eigenentwicklung zu billig gerechnet.

    Was Sie davon haben

    • Eigenentwicklung dort, wo sie einen Vorteil bringt, statt überall dort, wo etwas fehlte.
    • Systeme, die auch nach einem Personalwechsel weiterentwickelt werden können.
    • Klare Rechte am Ergebnis, die auch bei einem Streit mit dem Dienstleister tragen.

    Aus unseren Projekten

    Die Frage nach dem Quellcode ist in bestehenden Verträgen überraschend oft ungeregelt oder zugunsten des Dienstleisters geregelt. Solange die Zusammenarbeit gut läuft, spielt das keine Rolle. Sobald sie endet, entscheidet dieser Punkt darüber, ob Sie das System weiterbetreiben oder neu bauen. Wir prüfen deshalb bei bestehenden Eigenentwicklungen zuerst die Vertragslage und erst danach die Technik. Der zweite regelmäßige Befund betrifft Bausteine aus offenen Quellen: Sie sind fast immer im Einsatz, selten inventarisiert und gelegentlich seit Jahren ohne Aktualisierung, was sowohl ein Sicherheits- als auch ein Lizenzthema ist.

    Häufige Fragen

    Sollen wir eigene Entwickler einstellen oder einen Dienstleister beauftragen?

    Für eine einzelne Anwendung ist ein Dienstleister meist sinnvoller, weil eine Person allein weder Vertretung noch Austausch hat. Eigene Entwicklung lohnt sich, wenn Software Teil Ihres Produkts ist oder wenn Sie dauerhaft mehrere Anwendungen betreiben. In diesem Fall braucht es mindestens zwei Personen, sonst haben Sie das Abhängigkeitsproblem nur intern.

    Wie stellen wir sicher, dass eine Eigenentwicklung wartbar bleibt?

    Durch drei Dinge, die im Vertrag stehen und geprüft werden: automatisierte Tests für die zentralen Abläufe, eine Dokumentation, die eine dritte Person in die Lage versetzt weiterzuarbeiten, und regelmäßige Aktualisierung der verwendeten Bausteine. Wartbarkeit entsteht nicht durch guten Willen, sondern durch Zusagen, die überprüfbar sind.

    Sprechen wir über Individualentwicklung richtig einsetzen

    Im Erstgespräch klären wir in dreißig Minuten, wo bei Ihnen der größte Hebel liegt und ob wir die Richtigen dafür sind.

    Weiterführend

    Zurück zum Feld Entwickeln und beschaffen