Software und Lizenzmodelle passend auswählen

Was du nach dieser Lektion kannst

Ein Sozialunternehmen betreibt drei Reparaturwerkstätten. Bisher verwalten die Teams Geräte, Ersatzteile und Termine in mehreren Tabellen. Nun soll eine gemeinsame Software entstehen. Drei Wege stehen zur Wahl: eine fertige Cloud-Anwendung, eine selbst betriebene Open-Source-Anwendung oder eine Individualentwicklung.

Die Entscheidung lässt sich nicht auf “billig” oder “Open Source” verkürzen. Eine passende Lösung erfüllt die Anforderungen, darf wie vorgesehen genutzt werden und bleibt über den betrachteten Zeitraum wirtschaftlich betreibbar.

Nach dieser Lektion kannst du:

• Softwarearten nach ihrem Einsatzzweck unterscheiden,
• Standardsoftware und Individualsoftware passend einordnen,
• Lizenzbegriffe von Kosten- und Vertriebsmodellen trennen,
• Gesamtkosten mit vorgegebenen Annahmen vergleichen,
• eine Auswahl nachvollziehbar begründen.

Die Lektion gehört zu Lernfeld 5 und bereitet auf den ersten Teil der Abschlussprüfung vor. Die Fachinformatikerausbildungsverordnung verlangt dort unter anderem, Hard- und Software auszuwählen und die Beschaffung einzuleiten. Der Prüfungskatalog konkretisiert diesen Bereich mit Softwarearten, Auswahlkriterien, Urheberrecht und Lizenzmodellen.

Software zuerst nach ihrer Aufgabe einordnen

Bevor du Produkte vergleichst, klärst du, welche Aufgabe die Software übernimmt. Drei Gruppen helfen bei der ersten Orientierung.

Systemsoftware stellt grundlegende Funktionen für den Betrieb eines Computers bereit. Dazu gehören etwa Betriebssysteme und systemnahe Verwaltungswerkzeuge.

Anwendungssoftware unterstützt eine fachliche Aufgabe. Die Werkstattverwaltung aus unserem Beispiel ist Anwendungssoftware, weil sie Termine, Geräte und Ersatzteile für den Arbeitsprozess verwaltet.

Entwicklungssoftware hilft dabei, Software zu erstellen oder zu prüfen. Dazu gehören integrierte Entwicklungsumgebungen, Compiler und Debugger. Eine integrierte Entwicklungsumgebung bündelt typischerweise Editor, Ausführung und Fehlersuche.

Anforderungen entscheiden vor dem Produktnamen

Das Werkstattteam formuliert zunächst sein Anforderungsprofil. Die Lösung soll 18 Beschäftigte unterstützen und diese Muss-Kriterien erfüllen:

• Rollen für Annahme, Werkstatt und Verwaltung,
• Import der vorhandenen Gerätedaten,
• Export in einem dokumentierten Format,
• Zugriff von allen drei Standorten,
• nachvollziehbare Aktualisierungen und Datensicherung,
• ein dokumentierter Auftragsstatus.

Wunschkriterien sind eine Programmierschnittstelle, ein mobil gut nutzbarer Auftragsdialog und deutschsprachiger Support. Sie verbessern die Lösung, sind aber nicht automatisch Ausschlusskriterien.

Diese Trennung ist wichtig. Ein niedriger Preis kann eine fehlende Muss-Funktion nicht ausgleichen. Erst wenn eine Variante grundsätzlich geeignet ist, vergleichst du Kosten und weitere Eigenschaften.

Standardsoftware oder Individualsoftware

Standardsoftware wird für viele Kunden und wiederkehrende Aufgaben entwickelt. Sie ist meist schneller verfügbar und verteilt Entwicklung sowie Pflege auf mehrere Nutzer. Dafür passt sie nicht automatisch zu jedem betrieblichen Ablauf.

Individualsoftware wird für einen konkreten Auftrag entwickelt oder stark auf ihn zugeschnitten. Sie kann besondere Abläufe genau abbilden. Das Unternehmen übernimmt damit aber mehr Verantwortung für Spezifikation, Entwicklung, Tests, Betrieb und Weiterentwicklung.

Eine Standardlösung kann angepasst werden, ohne dadurch zur Individualsoftware zu werden. Konfigurierbare Rollen, eigene Felder oder ein Logo ändern den Produktcharakter nicht. Umgekehrt ist eine Eigenentwicklung nicht automatisch besser anpassbar. Ohne verständlichen Quellcode, Tests und Dokumentation kann auch sie schwer zu ändern sein.

Lizenz, Quellcode und Preis sind verschiedene Fragen

Software ist urheberrechtlich geschützt. Eine Lizenz beschreibt, unter welchen Bedingungen du sie nutzen darfst. Vertrag, Lizenztext und das Urheberrechtsgesetz bilden deshalb einen eigenen Prüfbereich neben Funktionen und Kosten.

Bei proprietärer Software legt der Rechteinhaber die eingeräumten Nutzungsrechte fest. Der Quellcode ist normalerweise nicht zur freien Änderung und Weitergabe freigegeben. Das Produkt kann gekauft, gemietet oder nach tatsächlicher Nutzung abgerechnet werden.

Open-Source-Software wird unter einer Lizenz bereitgestellt, die mehr als den bloßen Einblick in den Quellcode erlaubt. Die Open Source Definition verlangt unter anderem die Weitergabe des Quellcodes sowie die Möglichkeit, abgeleitete Werke zu erstellen und zu verteilen. Die genauen Pflichten unterscheiden sich zwischen den Lizenzen.

Ein Beispiel ist die GNU General Public License, kurz GPL. Sie ist eine Copyleft-Lizenz. Wer eine bearbeitete GPL-Software weitergibt, muss dabei die Lizenzbedingungen beachten und den Empfängern die entsprechenden Freiheiten erhalten. Für eine konkrete Veröffentlichung prüft ein Betrieb den vollständigen Lizenztext und lässt rechtliche Zweifelsfälle fachkundig klären.

Auch diese Begriffe beschreiben unterschiedliche Ebenen:

• Eine End User License Agreement (EULA) ist eine Vereinbarung mit Bedingungen für Endnutzer.
• Eine OEM-Lizenz wird häufig zusammen mit Hardware oder über einen bestimmten Vertriebskanal angeboten. Entscheidend sind die konkreten Bedingungen des Angebots.
• Pay-per-Use ist ein Abrechnungsmodell nach Nutzung. Es sagt allein noch nicht, welche urheberrechtlichen Nutzungsrechte eingeräumt werden.
• Software as a Service (SaaS) beschreibt die Bereitstellung als Dienst. Auch hier müssen Vertrag, Abrechnung, Datenzugriff und Beendigung getrennt geprüft werden.

Gesamtkosten über den Betrachtungszeitraum vergleichen

Für die Werkstätten bleiben nach der Muss-Prüfung zwei Standardlösungen übrig. Alle Zahlen sind neu erstellte Planungsannahmen für diese Lektion und keine Marktpreise.

Variante Cloud: 19 Euro je Nutzer und Monat für 18 Nutzer. Die einmalige Einrichtung dauert 8 Stunden. Der interne Kostensatz beträgt 70 Euro je Stunde.

Variante selbst betrieben: kein Lizenzentgelt, 900 Euro Hosting pro Jahr, 32 Stunden für die Einführung und 24 Stunden interner Betriebsaufwand pro Jahr. Auch hier gilt ein Kostensatz von 70 Euro je Stunde.

Für das erste Jahr rechnest du:

Cloud = 19 € × 18 × 12 + 8 h × 70 €/h
      = 4.104 € + 560 €
      = 4.664 €

Selbst betrieben = 900 € + 32 h × 70 €/h + 24 h × 70 €/h
                 = 900 € + 2.240 € + 1.680 €
                 = 4.820 €

Die Cloud-Variante ist unter diesen Annahmen im ersten Jahr 156 Euro günstiger. Dieser Abstand ist klein. Schon zusätzlicher Support, Preisänderungen oder ein anderer Betriebsaufwand können das Ergebnis verändern.

Die Kostenrechnung beantwortet nur die Frage, was unter den gewählten Annahmen anfällt. Sie zeigt nicht automatisch, welche Variante fachlich besser passt. Dazu prüfst du zusätzlich:

• Erfüllung aller Muss-Kriterien,
• Schnittstellen und Datenexport,
• Update- und Sicherheitskonzept,
• Verfügbarkeit von Support und internem Wissen,
• Aufwand bei Vertragsende oder Produktwechsel,
• erlaubte Nutzung, Anpassung und Weitergabe,
• Barrierefreiheit und Bedienbarkeit.

Eine Auswahl Schritt für Schritt begründen

Der Auswahlprozess lässt sich als kleine Entscheidungskette lesen. Ein früher Ausschluss spart Detailrechnungen für ungeeignete Varianten.

Für unser Szenario könnte eine Begründung so beginnen:

Die Cloud-Standardsoftware erfüllt alle Muss-Kriterien und ist unter den angegebenen Annahmen im ersten Jahr mit 4.664 Euro geringfügig günstiger. Sie verlangt außerdem weniger internen Einrichtungs- und Betriebsaufwand. Vor der Beschaffung prüfen wir noch die Vertragsbedingungen, den Datenexport, die zugesicherte Verfügbarkeit und die Kostenentwicklung über die geplante Nutzungsdauer. Die selbst betriebene Open-Source-Lösung bleibt eine Alternative, wenn Kontrolle über Betrieb und Anpassungen höher gewichtet wird und das nötige Fachwissen dauerhaft verfügbar ist.

Die Begründung nennt Ergebnis, Bedarf und offene Prüfstellen. Sie behauptet nicht, dass ein Produkt für jeden Betrieb die beste Wahl wäre.

Das Wichtigste für deine nächste Auswahl

• Beginne mit dem betrieblichen Bedarf, nicht mit einem Produktnamen.
• Trenne Muss-Kriterien von gewichtbaren Wünschen.
• Standardsoftware und Individualsoftware unterscheiden sich vor allem bei Passung, Einführungszeit und Verantwortung über den Lebenszyklus.
• Open Source, proprietär, SaaS und Pay-per-Use beantworten unterschiedliche Fragen.
• Vergleiche Gesamtkosten statt nur Lizenzentgelte.
• Dokumentiere Annahmen und offene Prüfstellen zusammen mit der Empfehlung.

Damit steht das Grundgerüst. Du kannst nun eine Softwareentscheidung so aufbauen, dass eine andere Person den Weg vom Bedarf bis zur Empfehlung nachvollziehen kann.

Quellenbasis und Abgrenzung

Der Lernfeldbezug folgt Lernfeld 5 des KMK-Rahmenlehrplans. Die Fachinformatikerausbildungsverordnung verlangt im ersten Teil der Abschlussprüfung die Auswahl von Hard- und Software. Der AP1-Prüfungskatalog konkretisiert den Themenbereich mit Softwarearten, Standard- und Individualsoftware, Open Source, proprietärer Software sowie Lizenz- und Abrechnungsmodellen.

Das wiederkehrende Aufgabenmuster “Fremdbezug gegen Eigenentwicklung” wurde aus vorhandenen Beispielprüfungen abstrahiert. Szenario, Anforderungen, Zahlen, Aufgaben und Lösungen dieser Lektion sind eigenständig erstellt. Sie bilden keine echte Prüfungsaufgabe ab und sagen keine Aufgabe für einen konkreten Prüfungstermin voraus.

Die rechtliche Einordnung stützt sich auf die besonderen Bestimmungen für Computerprogramme in §§ 69a bis 69g Urheberrechtsgesetz und auf die Open Source Definition. Die Lektion erklärt Auswahlfolgen auf Ausbildungsniveau. Sie ersetzt keine Prüfung eines konkreten Lizenztexts, Vertrags oder rechtlichen Einzelfalls.

Belegmatrix