Individualsoftware und Maßsoftware

Der Nutzerbetrieb ist ein entscheidender Bestandteil des Projektteams, da er die Perspektive der Endanwender einbringt. Diese Rolle sorgt dafür, dass die entwickelten Lösungen den tatsächlichen Bedürfnissen der Nutzer entsprechen. Zudem fungiert der Nutzerbetrieb als Bindeglied zwischen den technischen Entwicklern und den Anwendern, was die Kommunikation und das Verständnis fördert. Durch regelmäßiges Feedback kann der Nutzerbetrieb zur kontinuierlichen Verbesserung des Projekts beitragen.

Individualsoftware wird für ein bestimmtes Unternehmen und dessen Abläufe entwickelt, statt als fertiges Produkt an viele verkauft zu werden. Sie bildet Prozesse so ab, wie sie tatsächlich laufen – dafür trägt das Unternehmen Entwicklung, Betrieb und Weiterentwicklung selbst, die bei Standardsoftware im Lizenzpreis enthalten sind.

Der Preis ergibt sich aus Aufwand mal Tagessatz – nicht aus einer Preisliste. Entscheidend für den Aufwand sind drei Dinge: die Anzahl unterschiedlicher Abläufe, die Anzahl der Schnittstellen zu anderen Systemen und die Anforderungen an Rechte und Nachvollziehbarkeit. Wer eine belastbare Zahl will, braucht vorher ein Konzept.

Ein MVP (Minimum Viable Product) ist die kleinste Fassung einer Software, die im Alltag echten Nutzen stiftet. Nicht ein unfertiges Produkt, sondern ein fertiges kleines. Der Sinn: Annahmen früh an der Wirklichkeit prüfen, statt sechs Monate an Funktionen zu bauen, die niemand braucht.

Ein Lastenheft beschreibt, welches Problem gelöst werden soll – nicht, wie. Hinein gehören Ausgangslage, Ziele, die Abläufe mit ihren Sonderfällen, die betroffenen Systeme, Mengengerüste und Rahmenbedingungen. Wer stattdessen technische Lösungen vorschreibt, verschenkt genau die Erfahrung, für die er einen Dienstleister bezahlt.

Wenn mehrere Personen gleichzeitig damit arbeiten, wenn niemand mehr weiss, welche Datei die aktuelle ist, wenn Formeln nur eine Person versteht, oder wenn ein Fehler darin echten Schaden anrichten würde. Solange eine Person allein damit arbeitet und ein Fehler harmlos ist, ist Excel völlig in Ordnung.

Vendor Lock-in bedeutet, dass ein Wechsel des Anbieters unverhältnismässig teuer oder praktisch unmöglich wird. Bei Individualsoftware entsteht er selten durch den Code, sondern durch Fehlendes: kein Zugang zum Repository, keine Dokumentation der Umgebung, keine Datenexporte, keine zweite Person mit Kenntnis des Systems.

In der Regel ja. Der übliche Weg beginnt mit einer Bestandsaufnahme: Code sichten, Abhängigkeiten prüfen, Sicherheitslage bewerten. Danach wird stabilisiert, nicht sofort umgebaut. Ein Neubau ist die Ausnahme – er wirkt attraktiv, unterschätzt aber regelmässig, wie viel unsichtbares Wissen im alten System steckt.

Das hängt weniger an der Technik als an drei anderen Faktoren: wie klar die Anforderungen sind, wie schnell Entscheidungen fallen und wie viele Fremdsysteme angebunden werden müssen. Ein erster nutzbarer Stand ist meist in Wochen erreichbar, ein vollständiges System mit mehreren Schnittstellen braucht Monate.

Selten an der Technik. Die häufigsten Ursachen sind: unklares Ziel, niemand mit Entscheidungsbefugnis, wachsender Umfang ohne wachsendes Budget, und die Nutzerinnen und Nutzer wurden erst am Ende gefragt. Alle vier sind organisatorisch – und alle vier lassen sich vorher erkennen.

Eine API ist eine vereinbarte Art, wie zwei Programme miteinander sprechen. Das eine fragt etwas an, das andere antwortet in einer festgelegten Form. Der Vorteil gegenüber einem direkten Zugriff auf fremde Datenbanken: Beide Seiten können sich intern ändern, solange sie die Vereinbarung einhalten.

Nicht am Preis und nicht an der Technologieliste. Aussagekräftig sind vier Dinge: Referenzen, mit denen Sie sprechen dürfen; ein Angebot, das auch beschreibt, was nicht enthalten ist; Transparenz über die Betriebskosten nach dem Start; und die Bereitschaft, von einem Vorhaben abzuraten.

Im Kern drei Dinge: sicher anmelden, den eigenen Vorgang sehen, etwas anstossen können. Alles Weitere – Dateien, Benachrichtigungen, Auswertungen, Rechnungen – kommt danach. Ein Portal scheitert selten an fehlenden Funktionen, sondern daran, dass die Daten darin nicht aktuell sind.

In der Regel in zwei bis drei Terminen: zuschauen, wie heute gearbeitet wird; den Ablauf gemeinsam aufzeichnen; die Sonderfälle durchgehen. Ergebnis ist eine Beschreibung, aus der sich ein belastbarer Aufwand ableiten lässt. Der Wert steckt nicht im Dokument, sondern in den Fragen, die dabei zum ersten Mal gestellt werden.

Ein klickbarer Prototyp klärt in einer Stunde mehr als ein dreissigseitiges Konzept in einer Woche. Menschen können schlecht beurteilen, ob eine Beschreibung zu ihrem Arbeitsalltag passt – aber sofort sagen, ob ein Bildschirm funktioniert. Das Konzept bleibt trotzdem nötig, aber als Ergebnis, nicht als Ausgangspunkt.

Anhand vorher vereinbarter Kriterien, nicht nach Gefühl. Üblich ist eine Testphase mit echten Daten und echten Nutzern, eine Liste festgestellter Abweichungen mit Einstufung nach Schwere, und eine Abnahme, die kleine Mängel nicht blockiert. Wer erst bei der Abnahme über Kriterien spricht, verhandelt zum schlechtesten Zeitpunkt.

Nicht einzeln entscheiden, sondern sammeln. Jeder Wunsch kommt auf eine sichtbare Liste mit geschätztem Aufwand. Regelmässig – etwa alle zwei Wochen – wird priorisiert: Was kommt rein, was fliegt dafür raus, was wartet. So bleibt der Rahmen erhalten, ohne dass gute Ideen verloren gehen.

Nicht nur der Quellcode. Dazu gehören: Zugang zum Repository, Betriebsdokumentation, Zugangsdaten in Ihrem Besitz, eine Beschreibung der Umgebung und mindestens eine Schulung für die späteren Nutzer. Ohne diese fünf Dinge haben Sie Software, aber keine Kontrolle darüber.

Eine Datenbank speichert Daten strukturiert und sorgt dafür, dass viele Personen gleichzeitig damit arbeiten können, ohne sich gegenseitig zu überschreiben. Das ist der entscheidende Unterschied zu einer Datei: Eine Excel-Tabelle kann immer nur eine Person sinnvoll bearbeiten, eine Datenbank hundert.

Für die meisten Unternehmen die Cloud: schneller startklar, keine Investition, Ausfallsicherheit inklusive. Ein eigener Server lohnt sich, wenn rechtliche Vorgaben es verlangen, sehr hohe und gleichmässige Last besteht oder bereits ein Rechenzentrum vorhanden ist. Die Kostenfrage entscheidet seltener als gedacht.

Skalierbar heisst: Das System bleibt nutzbar, wenn die Menge wächst – mehr Nutzer, mehr Daten, mehr Vorgänge. Wichtig ist die ehrliche Frage, wie viel Wachstum realistisch ist. Software für hundert Nutzer, die für hunderttausend gebaut wurde, ist unnötig teuer und komplizierter im Betrieb.

Weil sonst jede Änderung ein Risiko ist. Automatisierte Tests prüfen in Minuten, ob nach einer Anpassung noch alles funktioniert, was vorher funktioniert hat. Ohne sie wird jede Weiterentwicklung mit der Zeit teurer und riskanter – bis sich niemand mehr traut, etwas anzufassen.

Technische Schuld entsteht, wenn eine schnelle Lösung gewählt wird statt einer sauberen. Wie bei einem Kredit zahlt man dafür Zinsen: Jede spätere Änderung dauert etwas länger. Das ist nicht per se falsch – man muss nur wissen, dass man Schulden aufnimmt, und sie irgendwann tilgen.

Ja, auf Bundes-, Landes- und teilweise EU-Ebene – die Programme ändern sich allerdings häufig, laufen aus und werden neu aufgelegt. Wichtigste Regel: Der Antrag muss vor der Beauftragung gestellt sein. Wer zuerst beauftragt und dann beantragt, verliert den Anspruch in der Regel vollständig.

Mit drei Fragen: Unterscheidet uns dieser Prozess vom Wettbewerb? Gibt es ein Produkt, das ihn zu mindestens 80 Prozent abdeckt? Können wir mit den verbleibenden 20 Prozent leben? Nur wenn die erste Frage mit Ja und die dritte mit Nein beantwortet wird, ist eigene Entwicklung die richtige Wahl.

Der Kern ist die Warenwirtschaft: Bestände, Bestellungen, Lieferanten, Preise. Individuelle Entwicklung wird dort interessant, wo Standardsysteme an Grenzen stossen – kundenspezifische Preislisten, Staffelungen, Rahmenverträge, EDI-Anbindungen und Kundenportale mit eigenen Konditionen.

Der Kern ist die Verbindung von Projekt, Zeit und Rechnung: Wer arbeitet woran, wie lange, und was davon ist abrechenbar. Wenn Zeiterfassung, Projektplanung und Fakturierung in getrennten Systemen liegen, geht regelmässig abrechenbare Leistung verloren.

Zwischen ERP und Maschine klafft in vielen Betrieben eine Lücke: Das ERP kennt Aufträge, die Maschine kennt Takte, aber niemand weiss in Echtzeit, wo ein Auftrag steht. Individuelle Entwicklung setzt meist genau dort an – Auftragsverfolgung, Rückmeldung aus der Fertigung, Qualitätsdokumentation.

Mitgliederverwaltung mit Beitragseinzug ist der Kern. Dazu kommen Kommunikation, Veranstaltungen und häufig ein Mitgliederbereich. Die Besonderheit gegenüber Unternehmen: wechselnde ehrenamtliche Betreuung – die Software muss ohne Einarbeitung bedienbar sein und darf nicht von einer Person abhängen.

Immer dann, wenn ein Dienstleister personenbezogene Daten in Ihrem Auftrag verarbeitet – also auch beim Hoster, bei der Softwarewartung mit Zugriff auf Echtdaten und beim Support. Der Vertrag nach Art. 28 DSGVO muss vor Beginn der Verarbeitung geschlossen sein, nicht danach.

Fast jede moderne Software nutzt Open-Source-Bausteine. Die meisten Lizenzen – MIT, Apache, BSD – erlauben kommerzielle Nutzung ohne Auflagen ausser der Nennung. Vorsicht ist bei sogenannten Copyleft-Lizenzen wie der GPL geboten: Sie können verlangen, dass abgeleitete Software unter derselben Lizenz veröffentlicht wird.

Das hängt vollständig davon ab, was Sie vorher geregelt haben. Mit Repository-Zugang, eigenen Zugangsdaten und Betriebsdokumentation ist ein Wechsel unangenehm, aber machbar. Ohne diese drei Dinge steht Ihr System still, bis jemand es rückwärts erschliesst – das dauert Wochen und kostet ein Vielfaches.

Weder grundsätzlich sicherer noch unsicherer als Standardsoftware – es kommt auf Bauweise und Pflege an. Standardsoftware wird von vielen geprüft, ist aber auch ein lohnenderes Ziel. Individuelle Software ist weniger im Fokus, bekommt aber nur die Aufmerksamkeit, die man ihr bezahlt.

In Schritten, nicht an einem Stichtag. Bewährt hat sich der Parallelbetrieb: Das neue System übernimmt zunächst einen Bereich, das alte läuft weiter. Erst wenn der neue Bereich stabil läuft, folgt der nächste. Eine Umstellung an einem einzigen Wochenende ist die riskanteste Variante.

Der Preis ergibt sich aus dem geschätzten Aufwand in Personentagen multipliziert mit dem Tagessatz – bei der Ouhud GmbH beträgt dieser nach Aufwand – verbindliche Spanne nach dem Erstgespräch. Für die drei üblichen Größenklassen gelten bei uns hängt vom Umfang ab – Festpreis nach der Konzeptphase, hängt vom Umfang ab – Festpreis nach der Konzeptphase und hängt vom Umfang ab – Festpreis nach der Konzeptphase. Belastbar wird eine Zahl aber erst nach einem Konzept, weil dieselbe Beschreibung acht Wochen oder acht Monate bedeuten kann.

Häufig ist genau das der richtige Weg, und ein Softwarehaus, das pauschal davon abrät, sollte man misstrauisch betrachten. Eine Standardplattform anzupassen ist günstiger und schneller, solange die Anpassungen als eigene Module neben dem Kern liegen. Teuer wird es erst, wenn in den Kern eingegriffen wird — dann zahlt man bei jeder Hauptversion erneut.

Der Vergleich Jahresgehalt gegen Tagessatz führt regelmäßig in die Irre, weil beim Angestellten nur etwa 200 von 365 Tagen produktiv verfügbar sind und Nebenkosten, Ausstattung und Einarbeitung hinzukommen. Ein Angestellter lohnt sich bei dauerhafter, gleichmäßiger Auslastung; ein Dienstleister bei Vorhaben mit Anfang und Ende oder bei Bedarf an Wissen, das man nicht ganzjährig braucht.

Nur, wenn sie ausdrücklich vereinbart wurden – eine Vertragsstrafe entsteht nie aus dem Gesetz, sondern immer aus einem Strafversprechen (§ 339 BGB). Welche Regelung die Ouhud GmbH anbietet, steht hier: auf Anfrage. Ohne solche Vereinbarung bleibt dem Auftraggeber der Verzugsschaden, den er beziffern und beweisen muss.

Die Priorisierung von Anforderungen in einem Projekt mit begrenztem Budget und Zeitrahmen erfordert eine strukturierte Vorgehensweise. Zunächst sollten die Anforderungen nach ihrem geschäftlichen Wert und ihrer Dringlichkeit bewertet werden. Methoden wie MoSCoW (Must have, Should have, Could have, Won't have) oder die Kano-Analyse können dabei helfen, die wichtigsten Anforderungen zu identifizieren. Zudem ist es wichtig, Stakeholder einzubeziehen, um sicherzustellen, dass die Prioritäten den tatsächlichen Bedürfnissen entsprechen.