Einkauf & IT-Sachverstand
Warum Kosten zu häufig aus dem Ruder laufen
Wer heute IT-Lösungen, SaaS oder vernetzte Technik einkauft, kauft im Hintergrund viele Dinge ein, die nicht unmittelbar sichtbar sind. Komplexe Kostentreiber, technische Abhängigkeiten und Betriebsrisiken bleiben häufig verborgen – und werden im Vertrag nicht sauber „gepackt“. Gleichzeitig gilt: Auch klassische Technik (z. B. Netzanlagen) enthält heute immer IT-Komponenten. Genau hier hilft der frühe Blick eines unabhängigen IT-Sachverständigen: um Kosten, Risiken und Abhängigkeiten sichtbar zu machen, bevor sie eingekauft werden.
Genau an dieser Schnittstelle zwischen Einkauf, IT, Vertrag und Projektrisiko wird ein früher sachverständiger Blick wirtschaftlich besonders wertvoll.
Warum überhaupt einen Sachverständigen anfragen?
Die typische Fehlannahme lautet: „Wir kaufen doch nur ein Produkt“, „das ist doch nur eine Plattform wie Amazon“ oder „den Rest regeln wir später im Projekt“. In Wirklichkeit werden heute häufig vernetzte Systeme, laufend weiterentwickelte Software, Cloud-Leistungen, IT-Services, Open-Source-Anteile oder eingeschränkte Nutzungsrechte beschafft. Was einfach aussieht, kann im Hintergrund technisch, rechtlich und betrieblich hochkomplex sein.
Soll das Risiko vor Vertragsschluss sauber geklärt werden – oder nach Vertragsabschluss als Nachforderung, Eskalation, Zusatzaufwand, Releaseproblem, Betriebsstörung oder Dauerärger wieder auftauchen? Wer früh anfragt, verschiebt Probleme nicht nach hinten – sondern reduziert sie.
Genau hier beginnt der praktische Nutzen eines IT-Sachverständigen: bevor technische, vertragliche und wirtschaftliche Risiken fest in der Beschaffung verankert werden.
Die naive Frage aus dem Einkauf – und warum sie so aufschlussreich ist
„Warum sollen wir bei einer Einkaufsplattform, die wir einkaufen wollen, überhaupt IT-Anforderungen ansetzen? Die wird doch so funktionieren wie Amazon.“
Genau an dieser Frage wird der Denkfehler sichtbar:
Die Oberfläche wirkt simpel – Suche, Upload, Bestelllogik, Rollen, Freigaben.
Dahinter stehen jedoch Softwarearchitektur, Datenverarbeitung, Berechtigungskonzepte, Upload-Funktionen,
Schnittstellen, Sicherheitsmechanismen, Protokollierung, Updates, Lizenzlogik und Betriebsmodelle.
Was die Einkäuferin sieht
- eine Oberfläche
- eine Prozessunterstützung
- eine Plattform „wie Amazon“
Was tatsächlich eingekauft wird
- ein komplexes IT-System
- ein Sicherheits- und Betriebsmodell
- eine langfristige technische und vertragliche Abhängigkeit
Warum IT-Anforderungen nötig sind
- weil Funktionen abgesichert sein müssen
- weil Risiken vertraglich beherrschbar bleiben müssen
- weil spätere Probleme sonst schon mit eingekauft werden
Amazon ist keine „einfache Website“, sondern ein hochkomplexes, massiv abgesichertes IT-System. Eine beschaffte Einkaufsplattform wirkt äußerlich ähnlich – hat aber nicht automatisch dasselbe Sicherheitsniveau. Genau deshalb sind IT-Anforderungen im Einkauf kein Luxus, sondern betriebliche Vorsorge.
Stand der Technik: Anforderungen müssen aktuelle Betriebsrealität abdecken
Wer heute Software, Plattformen oder vernetzte Systeme einkauft, sollte den Stand der Technik anfordern. Detaillierte Beschreibungen - vor allem von typischen Funktionalitäten wie Sicherheit, benötigte Admin-Funktionen, Rechte-Konzepte, Datensicherung, Einhalten der DSGVO usw. - werden schnell veralten. Ein vertraglich vereinbartes Update-Verfahren zum "Aufrüsten" auf den jeweiligen Stand der Technik spart relevante Folgekosten.
Beispiel: Passwortrichtlinien
Für die Vergabe persönlicher Passwörter muss es selbstverständlich sein, dass die zugehörigen Passwortrichtlinien frei konfigurierbar sind. Dazu gehören insbesondere organisatorisch anpassbare Anforderungen an Länge, Komplexität, Gültigkeit, Historie und Änderungslogik.
Beispiel: Admin-Funktionen
Es muss selbstverständlich sein, dass alle typischen Admin-Funktionen genutzt werden können. Diese sollten gerade nicht abschließend aufgezählt werden, weil sich der Umfang professioneller Administrationsanforderungen laufend erweitert. Entscheidend ist die grundsätzliche, praxistaugliche Administrierbarkeit des Systems.
Beispiel: Betriebsfähigkeit
Ein professionelles System muss so ausgestaltet sein, dass typische Anforderungen aus Betrieb, Sicherheit, Berechtigungssteuerung, Mandantenfähigkeit, Protokollierung und Weiterentwicklung im Rahmen der geforderten Verfügbarkeit umgesetzt werden.
Anforderungen zum Stand der Technik dürfen nicht zu eng und nicht statisch formuliert werden. Sonst erhält man formal erfüllte Verträge, aber praktisch unzureichende Systeme.
Lastenheft, Ausschreibung und Abnahme: Viele spätere Probleme entstehen bereits in den Ausschreibungsunterlagen
Viele IT-Projekte – oder Projekte mit IT-Anteilen – überschreiten Zeit und Budget, weil die vertraglichen Grundlagen dem Anbieter zu viele Spielräume für Change Requests lassen. Die Probleme beginnen häufig schon im Einführungskonzept, bei unklaren Anforderungen und unvollständigen Unterlagen – und setzen sich bei der späteren Präzisierung von Fachprozessen fort.
Die Folge: Leistungen werden nachträglich konkretisiert – und damit kostenpflichtig. Was fachlich „noch geklärt werden muss“, wird wirtschaftlich schnell zum Nachtrag.
Mit gezielten vertraglichen Vereinbarungen lassen sich hier frühzeitig klare Grenzen setzen – und unnötige Mehrkosten vermeiden. (Siehe auch: Should-Cost-Analyse )
Beschreiben: Projektorganisation
- Anteil vor-Ort-Arbeit
- Mitwirkungspflichten vom Fachbereich
- Reporting & Eskalationsmanagement
- Test- & Abnahmeverfahren
- ...
Kriterienkatalog professionell aufsetzen
- jede Anforderung eindeutig und einzeln formulieren
- fachliche und IT-seitige Anforderungen konsequent trennen
- KO-Kriterien klar definieren und verbindlich festlegen
- ...
Ausschreibung fachlich, technisch und vertraglich schärfen
- Lastenheft als Rahmen
- Kriterienkatalog und Bewertungslogik als revisionssichere Grundlage der Lieferantenauswahl festlegen
- Anbieter sollen die Ausschreibungsunterlagen aus eigener Sicht auf Konsistenz und Umsetzbarkeit prüfen
- ...
Eine optimale Vergabe erfordert mehr als einen „sauberen“ Ausschreibungsprozess. Entscheidend ist, dass projektspezifische Anforderungen vollständig und belastbar in den Ausschreibungsunterlagen abgebildet werden.
Bei vernetzten Produkten geht es nie nur um das Gerät
Produkte mit Netzanschluss oder digitaler Kommunikation sind heute oft Teil eines größeren Systems: mit Firmware, Schnittstellen, Fernzugriff, Benutzerrechten, Update-Mechanismen und Abhängigkeiten zu Drittsystemen. Das gilt für Technik im Netzbetrieb ebenso wie für Ladeinfrastruktur, Sensorik, Gateways, Steuerungen oder smarte Komponenten.
Typischer Denkfehler
- „Wir kaufen ein Gerät“
- „Der Hersteller wird das schon sicher gebaut haben“
- „IT schaut später einmal drauf“
Tatsächliche Realität
- Firmware und Embedded Software sind mitgekauft
- Fernwartung und Updates beeinflussen den Betrieb
- Schnittstellen und Berechtigungen erzeugen Angriffsflächen
Warum externe Prüfung hilft
- Anforderungen präzisieren
- kritische Lücken sichtbar machen
- Prüf- und Vertragsinhalte sauber strukturieren
Wer ein vernetztes Produkt einkauft, entscheidet immer auch über Softwarequalität, Sicherheitsniveau, Supportfähigkeit und spätere Betriebsstabilität.
Bei SaaS werden oft nicht Produkte gekauft, sondern Abhängigkeiten
Bei SaaS beschafft man regelmäßig keine klassische Softwarelizenz, sondern ein Bündel aus Nutzungsrechten, Betriebsmodell, Datenzugriff, Rollenlogik, Serviceversprechen, Open-Source-Anteilen und Exit-Fragen. Gerade deshalb ist eine frühe sachverständige Einordnung sinnvoll: weil sich die größten Probleme häufig nicht aus der Oberfläche, sondern aus den Vertragsdetails, der technischen Einbettung und fehlender Exit-Fähigkeit ergeben.
Fragen zu Nutzungsrechten
- Wer darf was in welchem Umfang nutzen?
- Welche Mandanten-, Rollen- und Rechtestruktur gilt?
- Was passiert bei Wachstum, Umorganisation oder Konzernbezug?
Fragen zum Betrieb
- Wie werden Updates eingespielt?
- Welche Verfügbarkeit ist realistisch und nachweisbar?
- Wie laufen Incident-, Eskalations- und Supportprozesse?
Fragen zu Open Source und Kosten
- Welche Bibliotheken und Fremdkomponenten sind enthalten?
- Welche Rechte und Pflichten folgen daraus?
- Welche Kostenrisiken entstehen bei Releasewechseln und im Betrieb?
Eine SaaS-Anwendung kann funktional überzeugen und trotzdem in Rechten, Betriebslogik, Open-Source-Abhängigkeiten oder Exit-Fähigkeit so schwach ausgestaltet sein, dass später hohe Zusatzkosten oder operative Blockaden entstehen.
IT-Services: Einer der Bereiche mit den häufigsten Folgekosten
Gerade im Bereich IT-Services entstehen besonders häufig vermeidbare Folgekosten. Der Grund ist meist nicht der angebotene Tagessatz, sondern die zu weich formulierte Leistung: unklare Abgrenzungen, fehlende Qualitätskriterien, unpräzise Servicezusagen, offene Verantwortlichkeiten und eine zu späte Klärung der Zusammenarbeit mit internen Teams.
Typische Ursachen
- unklare Leistungsbeschreibung
- offene Schnittstellen zu internen Teams
- schwammige Reaktions-, Eskalations- und Supportregeln
- fehlende Messbarkeit von Qualität und Ergebnissen
Typische Folgen
- Zusatzaufwände und Change Requests
- dauerhafte Diskussionen über Zuständigkeiten
- Mehrkosten im Betrieb statt im Angebot
- Unzufriedenheit trotz formal „laufender“ Leistung
Warum Sachverstand hilft
- Leistungsgrenzen klarer definieren
- Abnahme- und Qualitätskriterien schärfen
- Serviceversprechen in prüfbare Form bringen
- Folgekosten schon vor Vertragsschluss sichtbar machen
Der Bereich IT-Services gehört zu den Beschaffungsfeldern, in denen Organisationen besonders häufig die teuersten Folgekosten tragen müssen – nicht weil der Preis im Angebot zu hoch war, sondern weil die Leistung im Vertrag zu unklar beschrieben wurde.
Praxisbeispiel: Warum selbst etablierte IT-Lösungen kritisch geprüft werden sollten
Die verbreitete Annahme lautet: „Wenn eine Plattform teuer, bekannt und professionell wirkt, wird sie sicherheitlich schon sauber sein.“ Genau diese Annahme ist riskant.
Im Umfeld einer großen, bekannten Einkaufsplattform wurde beobachtet, dass der Upload von XLS-Dateien zugelassen war. Aus Anwendersicht wirkt das zunächst völlig normal: „Man lädt eben eine Excel-Datei hoch.“
Technisch ist die Lage jedoch deutlich kritischer: XLS-Dateien können Makros enthalten. Makros sind nicht nur Inhalte, sondern potenziell ausführbare Logik. Damit kann eine Upload-Funktion, die fachlich praktisch erscheint, sicherheitlich zu einem problematischen Einfallstor werden.
Was der Einkauf sieht
- Datei-Upload funktioniert
- Anwender können komfortabel arbeiten
- fachliche Anforderung scheint erfüllt
Was der IT-Sachverstand sieht
- potenzielles Risiko durch ausführbare Inhalte
- Frage nach Dateiprüfung, Filterung und Sicherheitslogik
- Prüfbedarf bei Upload-Konzept, Betriebsmodell und Schutzmaßnahmen
Die eigentliche Lehre
- teure Software ist nicht automatisch sicher
- Marktpräsenz ersetzt keine technische Prüfung
- scheinbar kleine Funktionen können große Wirkung haben
Drei weitere Beispiele, warum ein früher sachverständiger Blick sinnvoll ist
Das Upload-Beispiel ist nur ein Fall. Die eigentliche Schwierigkeit besteht darin, dass Risiken oft in ganz normalen Standardfunktionen stecken.
Beispiel 1: Passwortregeln sind nicht frei konfigurierbar
Eine Plattform erlaubt persönliche Kennwörter, aber die Regeln zu Länge, Komplexität, Historie oder Änderungslogik sind nur eingeschränkt anpassbar. Fachlich wirkt das System nutzbar – im Betrieb scheitert es jedoch an Sicherheitsvorgaben, internen Standards oder besonderen Anforderungen des Auftraggebers.
Beispiel 2: Typische Admin-Funktionen sind nur teilweise nutzbar
Das System bietet fachliche Funktionen, aber typische administrative Eingriffe, Konfigurationen oder Steuerungsmöglichkeiten sind nur rudimentär vorhanden oder durch den Anbieter exklusiv kontrolliert. Dann entsteht im Alltag unnötige Abhängigkeit – und jede Sonderanforderung wird teuer.
Beispiel 3: Open-Source-Bausteine verschieben Risiken in den Betrieb
Eine Lösung wirkt zunächst preiswert und modern. Später zeigt sich jedoch, dass einzelne Bibliotheken, Plattformkomponenten oder Releasewechsel zusätzlichen Prüf-, Anpassungs-, Wartungs- oder Lizenzaufwand auslösen. Was im Angebot günstig erschien, kann über den Lebenszyklus deutlich teurer werden, wenn Transparenz, Risikobewertung und vertragliche Klarheit fehlen.
Zusatzumsätze sind bei vielen Anbietern Teil des Geschäftsmodells. Gutes Claim-Management beginnt deshalb im Einkauf: Anforderungen müssen so klar und nachhaltig formuliert werden, dass kostenpflichtige Nachforderungen möglichst keinen Raum haben.
Typische Szenarien, die vom Einkauf auch IT-Sachverstand verlangen
Szenario 1: „Nur eine Plattform“
Eine Einkaufs- oder Serviceplattform wirkt auf den ersten Blick einfach. Tatsächlich hängen daran Rollenmodelle, Upload-Funktionen, Schnittstellen, Sicherheitsfragen und Verfügbarkeitszusagen.
Szenario 2: Vernetztes Produkt im Feld
Ein technisches Produkt mit Netzanschluss soll beschafft werden. Die Fachfunktion ist klar – aber Updatefähigkeit, Fernzugriff, Logging und Absicherung wurden nicht sauber adressiert.
Szenario 3: SaaS mit kurzer Projektlaufzeit
Der Vertrag soll schnell unterschrieben werden. Genau dann fehlen oft klare Aussagen zu Nutzungsrechten, Datenrückgabe, Support, Open-Source-Transparenz oder Integrationsgrenzen.
Szenario 4: IT-Service mit weicher Leistungsbeschreibung
Support, Betrieb, Transition oder Weiterentwicklung werden beauftragt, aber Leistungen, Rollen, Reaktionszeiten und Qualitätskriterien bleiben unscharf.
Szenario 5: Stand-der-Technik-Fragen bleiben offen
Ob Passwortregeln, Admin-Fähigkeiten, Mandantenlogik oder Protokollierung: Das System „kann etwas“, aber nicht das, was professioneller Betrieb tatsächlich verlangt.
Szenario 6: Später droht Streit
Unklare Leistungsgrenzen, unpräzise Zusagen oder fehlende Abnahmekriterien führen später zu Nachträgen, Verzögerungen und gegenseitigen Schuldzuweisungen.
In vielen Projekten stellt sich die entscheidende Frage erst später: Entspricht die gelieferte Leistung tatsächlich den Anforderungen? Sind technische Mängel vorhanden oder wurden Leistungen nicht vollständig erbracht?
Für diese Situationen steht ein unabhängiger IT-Sachverständiger zur Verfügung – zur fachlichen Einordnung, Bewertung und gutachterlichen Unterstützung.
Nicht erst bei Störung, Eskalation oder Nachtrag – sondern solange Anforderungen, Leistungsgrenzen und Vertragslogik noch gestaltet werden können.
Je digitaler, vernetzter oder servicebasierter die Beschaffung ist, desto sinnvoller ist es, vor Vertragsschluss einen IT-Sachverstand einzubeziehen.
Bereits beim Risikopuffer ergibt sich ein relevantes Einsparpotenzial.
Besser vor der Ausschreibung prüfen und optimieren als später teuer nachsteuern.
Die Verbindung von Beschaffungskompetenz und IT-Sachverstand spart Aufwand und Kosten
Auch vermeintlich „kleine“ Beschaffungen können erhebliche Zusatzkosten verursachen. Gerne stehen wir Ihnen mit unserer Erfahrung und IT-Sachkompetenz zur Verfügung.
Ansprechpartner: Dr. Manfred Fitzner
Unabhängiger IT-Sachverstand für Software, Leistungsbeschreibungen, Abnahme, Risikobewertung und tragfähige Einkaufsentscheidungen