Lastenheft: Digitale Plattform zur Steuerung und Abrechnung von Fremdfirmenleistungen
Facility Management: Fremdfirmenmanagement » Strategie » Prozessoptimierung » Lastenheft: Digitale Plattform
Lastenheft: Digitale Plattform zur Steuerung und Abrechnung von Fremdfirmenleistungen
Industrieunternehmen sind bei der Instandhaltung und Projektdurchführung oft auf Fremdfirmen angewiesen. Die Koordination und Abrechnung dieser Dienstleistungen stellt jedoch eine komplexe Herausforderung dar. Fremdfirmenleistungen – also von externen Dienstleistern erbrachte Arbeiten – werden heute vielfach mit hohem manuellem Aufwand verwaltet. Laut einer aktuellen Branchenstudie arbeiten noch rund 90 % der Industrieunternehmen bei der Erfassung und Auswertung von Fremdfirmeneinsätzen mit manuellen Prozessen (z. B. Excel-Listen), während nur 11 % eine wirklich digitale Plattform dafür einsetzen. Diese Lücke führt zu Ineffizienzen: Überstunden, Abweichungen von Vertragskonditionen, verzögerte Projekte und mangelnde Kostentransparenz sind häufig die Folge. In einer Umfrage berichteten 60 % der Unternehmen von Termin- und Budgetüberschreitungen bei Projekten – ein Indikator dafür, dass das Fremdfirmenmanagement optimiert werden muss.
Vor dem Hintergrund der digitalen Transformation und Industrie 4.0 besteht ein dringender Bedarf, die Steuerung externer Dienstleister durch eine integrierte Softwarelösung zu verbessern. Eine solche digitale Plattform soll die Zusammenarbeit mit Fremdfirmen, die Erfassung erbrachter Leistungen und die Abrechnung deutlich effizienter, transparenter und revisionssicher gestalten. Dieses Lastenheft beschreibt ausführlich und produktneutral die Anforderungen an eine derartige Plattform für einen industriellen Bergbaubetrieb. Ziel ist es, ein vollständiges und formal belastbares Ausschreibungsdokument bereitzustellen, das alle notwendigen funktionalen und nicht-funktionalen Kriterien für die Auswahl einer optimalen Lösung festhält.
- Zielsetzung
- Hintergrund
- Begriffsdefinitionen
- Funktionale
- Nicht-funktionale
- Muss- und Soll-Kriterien
- Kriterien
- Zusammenfassung
Zielsetzung:
Die einzuführende Plattform soll insbesondere ermöglichen, Fremdfirmenabrechnungen automatisiert gegen Vertragskonditionen zu prüfen, Leistungen in Echtzeit zu erfassen und zu validieren, Dienstleister performancebasiert zu analysieren und Prognosen (Predictive Analytics) zu erstellen. Durch nahtlose Integration mit SAP S/4HANA (Module Einkauf, Instandhaltung und Buchhaltung) wird ein durchgängiger Informationsfluss sichergestellt. Rollenbasierte Dashboards sollen allen Beteiligten – vom Instandhaltungsleiter bis zum Buchhalter – stets aktuelle Kennzahlen liefern. Überdies muss die Lösung höchsten Sicherheitsanforderungen genügen (Cloud-Betrieb, SOC 2-konform, mandantenfähig) und flexibel skalierbar sein, um zukünftigen Anforderungen gewachsen zu sein.
Hintergrund
Das ausschreibende Unternehmen ist ein Industriebetrieb mit umfangreichem Einsatz externer Dienstleister. Fremdfirmen übernehmen dabei z. B. Wartungs- und Instandhaltungsaufgaben, Projektarbeiten oder Spezialdienstleistungen im Tagebau und Untertagebau. Bisher werden die Leistungen dieser Partnerfirmen oft dezentral erfasst (etwa durch handschriftliche Rapporte, Excel-Dateien oder isolierte Subsysteme) und die Rechnungsprüfung erfolgt manuell durch Abgleich mit Verträgen und Bestellungen. Dieses Vorgehen ist fehleranfällig und bindet erhebliche personelle Ressourcen. Zudem fehlen konsolidierte Echtzeit-Informationen über den aktuellen Fremdfirmeneinsatz: Weder Management noch operative Entscheider haben jederzeit einen Überblick, wie viele externe Kräfte auf dem Werksgelände sind, welche Arbeiten in welchem Umfang geleistet wurden und wie diese im Verhältnis zu Verträgen stehen. Auch die Performancebewertung der Dienstleister erfolgt bislang nur rudimentär oder retrospektiv, wodurch Potentiale zur kontinuierlichen Verbesserung ungenutzt bleiben.
Zielsetzung: Durch die Einführung einer integrierten Plattform sollen folgende übergeordnete Ziele erreicht werden:
Effizienzsteigerung: Automatisierung der Rechnungsprüfung und Wegfall redundanter manueller Dateneingaben. Dadurch sollen Fehler vermieden, Prozessdurchlaufzeiten verkürzt und Kosten gesenkt werden (Vermeidung von „cost leakage“ durch Falschabrechnungen).
Transparenz und Echtzeitsteuerung: Zentrale, jederzeit abrufbare Übersicht über laufende Fremdfirmeneinsätze, geleistete Stunden, Kostenstände und Vertragsauslastung. Führungskräfte sollen in der Lage sein, auf Basis von Echtzeitdaten fundierte Entscheidungen zu treffen, etwa bei Planabweichungen unmittelbar gegenzusteuern.
Vertrags- und Compliance-Sicherheit: Sicherstellen, dass alle Abrechnungen den vertraglichen Konditionen entsprechen (z. B. vereinbarte Einheitspreise, Höchstmengen, Rabattstaffeln) und automatische Eskalation bei Abweichungen. Einhaltung interner Richtlinien sowie rechtlicher Vorgaben (z. B. steuerliche Anforderungen an Rechnungen, Dokumentationspflichten, DSGVO bei Personaldaten).
Integrationsfähigkeit: Reibungsloser Datenaustausch mit dem bestehenden SAP S/4HANA-System, um Doppeleingaben zu vermeiden und Buchhaltungsprozesse zu beschleunigen. Die Lösung wirkt als Erweiterung der vorhandenen IT-Landschaft und nutzt deren Stammdaten (z. B. Lieferanten, Material, Kostenstellen) sowie Bewegungsdaten (Bestellungen, Wareneingänge, Rückmeldungen).
Performance Management: Einführung eines Kennzahlensystems zur Bewertung der Fremdfirmen (Lieferanten-Performance). So können z. B. Termintreue, Qualitätskennzahlen und Kostenabweichungen systematisch erfasst und Dienstleister vergleichbar gemacht werden. Auf dieser Basis können Steuerungsmaßnahmen (etwa gezielte Gespräche mit leistungsschwachen Lieferanten oder bevorzugte Auftragsvergabe an leistungsstarke) ergriffen werden.
Zukunftsorientierung durch Analytics: Nutzung von Predictive Analytics, um aus historischen Daten vorausschauende Analysen abzuleiten. Beispielsweise können damit Trends erkannt werden – welche Dienstleister zeigen sich langfristig am zuverlässigsten? Wo drohen künftige Budgetüberschreitungen? – und proaktive Maßnahmen getroffen werden. Die Plattform soll damit einen Beitrag zur strategischen Planung leisten.
Skalierbarkeit und Flexibilität: Die Lösung muss mit den Anforderungen mitwachsen. Das bedeutet einerseits die technische Skalierbarkeit (mehr Benutzer, mehr Datenvolumen, zusätzliche Standorte oder Geschäftseinheiten), andererseits Flexibilität in der Abbildung neuer Prozesse oder Vertragsmodelle, ohne dass aufwändige Programmierarbeiten nötig werden.
Geltungsbereich (Scope)
Dieses Lastenheft umfasst die Anforderungen für die Auswahl und Implementierung einer „Vendor Management“-Lösung speziell zugeschnitten auf die industrielle Fremdfirmensteuerung im Bergbau.
Im Scope liegen alle Funktionalitäten von der Erfassung der Leistung durch den Dienstleister bis zur Prüfung und Verbuchung der Abrechnung:
Im Scope: Automatisierte Rechnungsprüfung, Leistungsverifizierung via Echtzeitdaten (u. a. Zugangskontrolle am Werkstor, Arbeitszeiterfassungssysteme), Verwaltung von Verträgen und Bestellungen in Bezug auf Fremdleistungen, Erstellung und Monitoring von KPIs (Key Performance Indicators) für Dienstleister, Berichts- und Analysefunktionen (inkl. prädiktiver Auswertungen), Benutzer- und Rollenverwaltung, sowie Schnittstellen zu SAP S/4HANA und ggf. weiteren relevanten Systemen (z. B. Zeiterfassung, Zutrittskontrolle). Ebenfalls im Fokus stehen die Systemarchitektur (Cloud-Lösung) und Betriebsanforderungen wie Sicherheit, Verfügbarkeit, Mandantenfähigkeit und Datenschutz. Die Plattform soll mandantenfähig sein, sodass mehrere Standorte oder Geschäftsbereiche – oder perspektivisch auch externe Partner – auf einer Instanz mit logisch getrennten Daten arbeiten können.
Außerhalb Scope: Nicht Gegenstand dieses Lastenheftes sind die Beschaffung der Fremdleistungen selbst (d. h. die Ausschreibung und Vergabe von Aufträgen an Fremdfirmen wird weiterhin im SAP-Einkaufsmodul abgewickelt). Ebenso wenig deckt die Plattform klassische EHS-Funktionen (Environment, Health & Safety) wie Sicherheitsunterweisungen oder Permit-to-Work-Prozesse ab – solche Aspekte könnten ggf. über Schnittstellen an bestehende EHS-Systeme angebunden werden, sind aber hier nicht primär gefordert. Das Lastenheft konzentriert sich auf die betriebswirtschaftliche Steuerung und Abrechnung der Fremdfirmenleistungen. Auch projektbezogene Funktionen außerhalb des Fremdfirmenmanagements (z. B. Projektplanung, internes Ressourcenmanagement) sind nicht Teil der Anforderungen, außer sie stehen in direktem Zusammenhang mit Fremdfirmen (etwa Abstimmung von Fremd- mit Eigenleistungen in der Einsatzplanung).
Um Missverständnisse zu vermeiden, werden im Folgenden zentrale Begriffe und Abkürzungen, die in diesem Lastenheft verwendet werden, kurz definiert:
Fremdfirma / Dienstleister: Ein externes Unternehmen, das auf Werkvertrags- oder Dienstleistungsbasis Leistungen für den Auftraggeber (den Bergbaubetrieb) erbringt. Beispiele: Wartungsfirma, Gerüstbauer, Bohrunternehmen. Deren Fremdfirmenmitarbeiter sind Personen, die im Auftrag dieser Firmen im Werk tätig sind.
Fremdfirmenleistung: Eine von einer Fremdfirma erbrachte Arbeit oder Serviceleistung. Dies kann zeitbasiert (z. B. Stundenlohnarbeiten) oder mengen-/einheitsbasiert (z. B. Preis pro Tonne gefördertes Material, Pauschalbetrag pro inspizierte Maschine) abgerechnet werden, je nach Vertragsart.
Vertragskonditionen: Die im Dienstleistungs- oder Werkvertrag bzw. in der Bestellung vereinbarten Bedingungen für die Abrechnung der Fremdfirmenleistung. Dazu zählen Preise (Stundensätze, Einheitspreise), Rabattvereinbarungen, Leistungsumfang, Höchstgrenzen, Abrechnungszyklen, Zahlungsbedingungen usw.
Digitale Plattform / System: In diesem Kontext die Software-Lösung, welche alle geforderten Funktionen integriert bereitstellt – typischerweise eine Webanwendung (ggf. ergänzt um mobile Apps) mit einer zentralen Datenbank im Hintergrund. Sie dient als zentrales Vendor-Management-System für Fremdfirmen.
SAP S/4HANA: Das unternehmensweit eingesetzte ERP-System (Enterprise Resource Planning) der SAP SE in der Version S/4HANA. Relevante Module sind u. a. MM (Materials Management, inkl. Einkauf/Beschaffung), PM (Plant Maintenance, Instandhaltung) und FI/CO (Finanzwesen und Controlling). Die neue Plattform muss mit diesen Modulen integriert werden, d. h. Daten austauschen können (siehe Anforderungen zu Integration).
Gate-Access / Zugangskontrolle: Elektronisches System zur Zutrittssteuerung am Werkgelände (z. B. Drehkreuze oder Schranken mit Kartenscannern). Im Kontext der Leistungserfassung sollen Gate-Access-Daten Auskunft geben, wann Fremdfirmenmitarbeiter das Gelände betreten und verlassen haben (Authentifizierung per Werksausweis o. Ä.).
Arbeitszeiterfassung: System(e) zur Registrierung der Arbeitszeit, z. B. elektronische Stempeluhr oder digitale Zeiterfassungssoftware, die von Fremdfirmenmitarbeitern genutzt wird. Diese Daten (Kommen/Gehen-Zeiten, Pausen, Schichtdauer) dienen als Echtzeitnachweis geleisteter Stunden.
Echtzeitdaten: Daten, die nahezu ohne zeitliche Verzögerung aus operativen Systemen erfasst und in die Plattform eingespeist werden. Hier: vor allem Zugangs- und Zeitstempeldaten, ggf. auch Maschinendaten oder Sensorinformationen. Echtzeit bedeutet z. B., dass ein Eintritt am Werkstor innerhalb weniger Sekunden im System sichtbar ist.
Rollenbasierte Benutzeroberfläche: Ein Bedienkonzept, bei dem Nutzer je nach ihrer Rolle im Unternehmen unterschiedliche Sichten und Berechtigungen haben. Beispiel: Ein Einkäufer sieht Vertrags- und Bestelldaten, ein Schichtführer kann die Anwesenheit der Fremdfirmen vor Ort einsehen, ein Buchhalter prüft Rechnungen, etc. Die Benutzerrolle bestimmt, welche Menüs, Funktionen und Daten dem User in der UI (User Interface) präsentiert werden.
Dashboard: Übersichtsseite innerhalb der Plattform, die wichtige Kennzahlen (KPIs), Statusanzeigen und Benachrichtigungen grafisch aufbereitet in Echtzeit darstellt. Dashboards dienen der Echtzeitüberwachung und Entscheidungsunterstützung, z. B. durch Ampelindikatoren für Budgetverbrauch oder Diagramme zur Leistung.
Performanceanalyse (von Dienstleistern): Systematisches Messen und Bewerten der Leistung von Fremdfirmen anhand definierter Kriterien. Typische KPIs (Key Performance Indicators) können sein: Termintreue (Einhaltung von Zeitplänen), Qualität (Fehlerquoten, Nacharbeit), Arbeitssicherheit (Unfälle, Zwischenfälle), Produktivität (Output pro Zeiteinheit) und Kostenabweichung (tatsächliche vs. geplante Kosten). Die Plattform soll solche Kennzahlen erfassen, auswerten und vergleichen können (siehe funktionale Anforderungen).
Predictive Analytics (prädiktive Analyse): Form der Advanced Analytics, bei der aktuelle und historische Daten verwendet werden, um zukünftige Ereignisse oder Trends vorherzusagen. Mittels statistischer Methoden und Algorithmen des maschinellen Lernens werden Modelle erstellt, die Wahrscheinlichkeiten für bestimmte Ereignisse berechnen (z. B. Kostenüberschreitungen bis Jahresende, Personalausfälle, etc.). Die prädiktive Analyse hilft, proaktiv zu steuern, indem z. B. frühzeitig Gegenmaßnahmen bei negativen Prognosen ergriffen werden können. (Abgrenzung: Prescriptive Analytics ginge einen Schritt weiter und würde konkrete Handlungsanweisungen ableiten, ist aber hier nicht explizit gefordert.)
Cloud-Hosting: Betrieb der Software in einer Cloud-Umgebung (entweder Public Cloud oder Private Cloud), d. h. die Infrastruktur wird vom Anbieter oder einem Cloud-Service bereitgestellt. Der Zugriff erfolgt typischerweise über das Internet mittels Browser. Die Forderung sicheres Hosting (Cloud) impliziert, dass moderne Sicherheitsstandards wie ISO/IEC 27001-Zertifizierung, SOC 2 Type II Auditierungen und aktuelle Verschlüsselungsverfahren angewendet werden.
Mandantenfähig (Multi-Tenant): Die Software-Architektur erlaubt es, mehrere Mandanten – z. B. verschiedene Tochtergesellschaften, Geschäftsbereiche oder externe Kunden – in einer gemeinsamen Instanz zu betreiben, ohne dass sie gegenseitig Zugriff auf Daten haben. Jeder Mandant ist logisch isoliert. Für den Betreiber ergeben sich dadurch Vorteile in Wartung und Skalierung, da nicht für jeden Mandanten ein separater System-Stack betrieben werden muss.
SOC 2 (System and Organization Controls 2): Ein Prüfungsrahmen für Dienstleistungsunternehmen zur Gewährleistung von Datensicherheit. SOC 2-Prüfberichte evaluieren ein System hinsichtlich vordefinierter Trust Services Principles: Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz. Eine SOC 2-konforme Plattform erfüllt strenge Anforderungen in diesen Bereichen, was für cloudbasierte Lösungen in Bezug auf Kundendaten essenziell ist.
Skalierbarkeit: Eigenschaft der Software und Infrastruktur, steigende Belastungen handhaben zu können. Horizontal skalierbar bedeutet z. B., dass zusätzliche Server/Instanzen bei wachsender Nutzerzahl oder Datenmenge hinzugefügt werden können. Vertikal skalierbar bedeutet, dass die Leistung pro Server erhöht werden kann (CPU, RAM). Flexible Skalierbarkeit impliziert, dass das System sowohl bei kleinen Nutzerzahlen wirtschaftlich betrieben werden kann als auch bei starker Zunahme (z. B. Verdopplung der Fremdfirmen oder Einsätze) performant bleibt, ohne komplette Neuarchitektur.
Muss-Kriterium: Eine Anforderung, die zwingend erfüllt sein muss. Fehlt die Erfüllung auch nur eines Muss-Kriteriums, kann die angebotene Lösung in der Regel nicht akzeptiert werden (Ausschlusskriterium). Solche Anforderungen sind im Text typischerweise mit „muss“ oder „erforderlich“ formuliert.
Soll-Kriterium: Eine wünschenswerte Eigenschaft oder Funktion („nice-to-have“), die nicht absolut entscheidend ist, aber die Lösung deutlich verbessert. Soll-Anforderungen sollten nach Möglichkeit erfüllt werden; eine Nichterfüllung führt jedoch nicht automatisch zum Ausschluss, sondern zu Abzügen in der Bewertung. Im Text gekennzeichnet durch Formulierungen wie „sollte“ oder „vorteilhaft wäre“.
Funktionale Anforderungen
In diesem Kapitel werden die fachlichen und technischen Funktionen beschrieben, die die digitale Plattform abdecken muss. Die Anforderungen sind thematisch gruppiert. Jede Gruppe wird zunächst erläutert, gefolgt von einer Liste konkreter Kriterien. Dabei wird – sofern sinnvoll – zwischen Muss- und Soll-Kriterien unterschieden.
Automatisierte Vertrags- und Rechnungsprüfung
Beschreibung: Eine Kernfunktion der Plattform ist die automatisierte Prüfung von Fremdfirmenrechnungen gegen die hinterlegten Vertragskonditionen. Jede vom Dienstleister gestellte Rechnung (bzw. Leistungsnachweis) soll systematisch mit den im System vorhandenen Vertrags- und Bestelldaten abgeglichen werden. Damit wird sichergestellt, dass nur das abgerechnet wird, was vereinbart und tatsächlich geleistet wurde. Manuelle Prüfaufwände werden minimiert und Fehlabrechnungen – sei es durch Irrtum oder unzulässige Mehrforderungen – unterbunden. Die Plattform fungiert hierbei als eine Art vorgelagerte Rechnungsprüfung vor der eigentlichen Buchung im ERP. Sie entlastet die Mitarbeitenden, da Differenzen automatisch erkannt und angezeigt werden. Zudem ermöglicht sie ein einheitliches, regelbasiertes Vorgehen bei der Rechnungsprüfung.
Wichtige Aspekte sind: Unterstützung verschiedener Vertragsmodelle (etwa Rahmenverträge mit Abruf, Einzelbestellungen, Werkverträge mit Abnahme, Dienstverträge auf Zeit&Material-Basis), Handhabung von Preis- und Mengenabweichungen (Toleranzen, Überziehungen, Mindermengen), sowie die Abbildung von abgestuften Genehmigungsworkflows für Ausnahmefälle. Die Plattform sollte regelbasiert arbeiten – z. B. hinterlegte Prüfregeln je Vertragsart – und idealerweise aus den erkannten Abweichungen dazulernen (z. B. häufige Fehler identifizieren).
Anforderungen (Vertrags- und Rechnungsprüfung):
| Muss | Soll |
|---|---|
| Die Plattform muss in der Lage sein, eingehende Rechnungsdaten bzw. Leistungsnachweise der Fremdfirma automatisiert mit den Vertragskonditionen abzugleichen. Dabei sind Position für Position die vereinbarten Preise, Mengen und Konditionen heranzuziehen. Abweichungen (z. B. abgerechnete Menge größer als vertraglich vorgesehen, nicht vereinbarte Zusatzposition, falscher Preis) müssen vom System automatisch erkannt und gekennzeichnet werden. | Das System sollte eine regelbasierte Prüfungs-Engine bieten, die flexibel anpassbar ist (z. B. Schwellenwerte für Toleranzen, Rundungsregeln, Mehrwertsteuerprüfung etc.). Idealerweise können Administratoren neue Prüfregeln hinzufügen oder ändern, ohne Programmieraufwand (parametrierbares Regelwerk). |
| Unplausible oder nicht vertragskonforme Abrechnungen müssen gesperrt bzw. zur Überprüfung zurückgestellt werden. Das System soll in solchen Fällen Benachrichtigungen/Alerts an definierte Rollen (z. B. Sachbearbeiter Rechnungsprüfung oder Einkauf) senden. Idealerweise ist ein Workflow integriert, der es ermöglicht, die Abweichung zu begründen und eine Freigabe durch berechtigte Personen (z. B. Budgetverantwortliche) einzuholen, bevor die Rechnung an die Buchhaltung weitergeleitet wird. | Wünschenswert ist eine Lernfähigkeit bzw. intelligente Komponente, die aus abgelehnten oder korrigierten Rechnungen Muster erkennt (z. B. systematische Überstundenzuschläge, die fehlen) und zukünftige Prüfungen verbessert (Ansatz Machine Learning, optional). |
| Die Lösung muss verschiedene Vertrags- und Abrechnungsarten unterstützen: z. B. Werkverträge mit Abrechnung nach Leistungsfortschritt, Dienstverträge auf Zeit- und Materialbasis, Pauschalverträge, Rahmenverträge mit Einzelabrufen. Für jede Art müssen passende Prüflogiken konfigurierbar sein. Beispielsweise bei Zeitverträgen Abgleich von Stundenlohnsätzen und Stundensummen, bei Einheitspreisverträgen Abgleich gelieferter Mengen gegen Vertragsmenge, etc. | Bei Feststellung von Abweichungen sollte die Plattform Unterstützung bei der Klärung bieten – etwa durch Vergleichsansichten (Rechnung vs. Vertrag vs. tatsächlich erfasste Leistung) und die Möglichkeit, Kommentierungen oder Klärungsanfragen an den Dienstleister direkt über das System zu senden. |
| Vertrags- und Bestelldaten sollen in der Plattform verfügbar sein (über manuelle Eingabe oder Import aus SAP, siehe Integration), sodass die Rechnung gegen diese Stammdaten validiert werden kann. Insbesondere müssen die vereinbarten Preise, Rabatte, Zahlungsbedingungen, Leistungszeitraum und ggf. Vertragslimits (Budget, Mengenobergrenzen) im System hinterlegt und für Prüfzwecke herangezogen werden. | |
| Protokollierung: Jeder Prüfschritt und jede manuelle Übersteuerung (Freigabe trotz Warnung etc.) muss für Revisionszwecke protokolliert werden (wer hat wann was freigegeben oder geändert). Diese Prüfhistorie ist Bestandteil der Compliance-Anforderungen. |
Integration mit SAP S/4HANA (Einkauf, Instandhaltung, Buchhaltung)
Beschreibung: Die nahtlose Integration der Plattform mit dem ERP-System SAP S/4HANA ist von entscheidender Bedeutung, da viele relevante Daten dort geführt werden. Dadurch wird ein durchgängiger Prozess „von der Bestellung bis zur Bezahlung“ ermöglicht, ohne Medienbrüche.
Drei SAP-Bereiche sind besonders relevant:
Einkauf (MM): Hier werden Bestellungen oder Rahmenverträge mit Fremdfirmen angelegt, die Preise, Mengen und Konditionen festlegen. Die Plattform muss diese Einkaufsdaten einlesen können (z. B. um zu wissen, welche Artikel/Leistungen bestellt wurden, zu welchem Preis und in welchem Umfang).
Instandhaltung (PM): In SAP PM werden Wartungsaufträge angelegt, die auch Fremdleistungen enthalten können (sogenannte Fremdvorgänge in Arbeitsaufträgen). Zudem werden dort Rückmeldungen über die Durchführung der Arbeiten erfasst. Eine Integration erlaubt der Plattform, Informationen über geplante Fremdfirmeneinsätze aus Wartungsaufträgen zu erhalten sowie ggf. Rückmeldungen an SAP zu senden, wenn Leistungen erbracht wurden.
Buchhaltung (FI/CO): Schließlich müssen die geprüften Rechnungsdaten in die Finanzbuchhaltung überführt werden – sei es als Buchung im Kreditorenmodul (FI-AP) oder zur Kostenkontierung im Controlling (CO). Idealerweise werden an SAP nur bereits validierte/genehmigte Rechnungen weitergegeben, um dort den Zahlungsprozess anzustoßen.
Darüber hinaus könnten auch Stammdaten wie Lieferanten, Kostenstellen, Auftragsnummern etc. aus SAP übernommen werden, um Doppelpflege zu vermeiden. Die Integration sollte möglichst in Echtzeit oder nahe Echtzeit erfolgen, zumindest aber tagesaktuell synchronisiert. Bei der Integration ist auf Nutzung standardisierter Schnittstellen (z. B. SAP OData Services, BAPIs oder IDocs) zu achten, um die Wartbarkeit sicherzustellen. Zudem muss sichergestellt sein, dass die Integrationen sicher (authentifiziert, verschlüsselt) erfolgen und keine Dateninkonsistenzen entstehen.
Anforderungen (Integration mit SAP):
| Muss | Soll |
|---|---|
| Die Plattform muss SAP S/4HANA integrieren, insbesondere die Module MM (Einkauf), PM (Instandhaltung) und FI/CO (Finanzen/Controlling). Dies bedeutet: Abruf von relevanten Stammdaten (z. B. Lieferantenstamm, Material/Leistungsstamm, Kostenstellen, Auftrags-/Projektnummern) und Bewegungsdaten (Bestellungen, Vertragsvereinbarungen, Wartungsaufträge) aus SAP; sowie Rückspielung von Abrechnungs- und Leistungsdaten (z. B. bestätigte Leistungsmengen, Rechnungsbeträge, Freigabevermerke) an SAP. | Echtzeit bzw. Near-Real-Time: Die Datenintegration sollte in Echtzeit oder nahezu in Echtzeit erfolgen. Beispielsweise wäre es optimal, wenn ein Wartungsauftrag, der in SAP angelegt oder geändert wird, innerhalb von Minuten in der Plattform erscheint. Bei Rechnungsfreigaben sollte die Übergabe an SAP automatisch ohne manuellen Zwischenschritt angestoßen werden. Falls Echtzeit nicht möglich ist, soll zumindest ein eng getakteter Synchronisationsmechanismus (z. B. jede Stunde) implementiert sein. |
| Einkaufsintegration: Bestelldaten und Rahmenvertragsdaten aus SAP müssen in der Plattform verfügbar gemacht werden können. Insbesondere muss das System z. B. eine offene Bestellung zu einer Fremdfirma erkennen und die dort enthaltenen Positionen, Mengen und Preise importieren, um eingehende Leistungen/Rechnungen korrekt zuordnen und prüfen zu können. Änderungen in SAP (etwa Nachträge, Mengenänderungen, Preisänderungen) müssen synchronisiert werden, damit die Plattform stets aktuelle Vertragsbedingungen kennt. | Technische Entkopplung: Die Plattform sollte offene Schnittstellen (REST APIs, oData) bereitstellen, über die SAP (oder auch andere Systeme) die Daten austauschen können. Ebenso sollte sie in der Lage sein, SAP-Standardschnittstellen (IDoc, BAPI) zu konsumieren. Auf proprietäre Punkt-zu-Punkt-Lösungen ist möglichst zu verzichten, um die Wartbarkeit zu erhöhen. |
| Leistungserfassung/Rückmeldung: Die Plattform muss ermöglichen, erbrachte Leistungen (Stunden, Mengen etc.), die über die Plattform erfasst und freigegeben wurden, an SAP zurückzumelden. Beispielsweise könnte nach Prüfung der Leistung automatisch ein Service-Eintrittsblatt (Service Entry Sheet) im SAP erstellt oder ein Wareneingang auf eine Dienstleistungsbestellung verbucht werden. Dies stellt sicher, dass die Leistung auch im ERP dokumentiert und für die Rechnungsprüfung in SAP (MIRO) bereitsteht. | Weitere Integrationen: Perspektivisch sollte die Lösung auch mit anderen Systemen integrierbar sein, etwa einem Dokumentenmanagement (zur Archivierung von Rechnungen oder Leistungsnachweisen), einem E-Mail-System (für Benachrichtigungen) oder einem Business-Intelligence-Tool. Diese Offenheit für Integration wird als Soll-Kriterium bewertet. |
| Buchhaltungsintegration: Für freigegebene Rechnungen muss eine Übergabe an SAP FI (Finanzbuchhaltung) erfolgen, damit die Rechnung in der Kreditorenbuchhaltung verbucht und bezahlt werden kann. Dies kann z. B. durch Erzeugen eines Buchungsbelegs oder einer vorerfassten Eingangsrechnung in SAP geschehen. Wünschenswert ist auch die Übernahme der Kontierung (Kostenstelle, Projekt, Auftrag) aus SAP oder umgekehrt die Rückübertragung der im Plattform-Workflow gewählten Kontierung. | |
| Datenkonsistenz: Es muss gewährleistet sein, dass Daten zwischen SAP und der Plattform konsistent bleiben. Beispielsweise wenn eine Bestellung in SAP storniert wird, darf keine Leistung mehr auf diese im Plattform-System erfasst werden können. Solche Konsistenzfälle müssen durch Synchronisationslogik oder Plausibilitätsprüfungen abgedeckt werden. |
Leistungserfassung und Echtzeit-Datenvalidierung
Beschreibung: Ein zentrales Unterscheidungsmerkmal der gewünschten Plattform ist die Fähigkeit, erbrachte Leistungen in Echtzeit zu erfassen und zu validieren. Dies meint, dass direkt am Ort und Zeitpunkt der Leistungserbringung relevante Daten gesammelt werden, um später eine lückenlose und korrekte Abrechnung zu ermöglichen. Beispiele: Wenn ein Fremdfirmen-Mitarbeiter das Betriebsgelände betritt (Gate-Access), wird Zeit und Identität erfasst. Wenn er sich an einer Anlage anmeldet oder eine Arbeit beginnt, wird dies registriert. Solche Datenpunkte (Zeitstempel, Zugangsdaten, ggf. GPS-Ort bei mobiler Arbeit) dienen dazu, die vom Dienstleister gemeldeten Leistungen (z. B. „8 Stunden Arbeit von MA X am 10.05.“) automatisch zu verifizieren.
Die Plattform soll Schnittstellen zu Echtzeitdatenquellen bieten. Dazu zählen primär das Zutrittskontrollsystem am Werkstor und das Arbeitszeiterfassungssystem. Optional könnten auch Maschinen- und Sensordaten einbezogen werden – z. B. die Betriebsstunden einer Maschine, wenn der Dienstleister nach Geräteeinsatz abrechnet. Die in Echtzeit erfassten Daten werden mit den Soll-Vorgaben aus Vertrag/Bestellung abgeglichen, um Abweichungen unmittelbar aufzuzeigen. Darüber hinaus ermöglicht die Echtzeit-Erfassung auch die Überwachung der Anwesenheit externer Mitarbeiter im Werk aus Sicherheitsgründen (dies kann in Zusammenarbeit mit HSE relevant sein, ist aber hier vor allem für die Leistungskontrolle wichtig).
Anforderungen (Leistungserfassung & Echtzeitdaten):
| Muss | Soll |
|---|---|
| Die Plattform muss Daten von Zugangskontrollsystemen (Gate-Access) und Arbeitszeiterfassungssystemen in Echtzeit oder Nahe-Echtzeit übernehmen können. D. h. sobald ein Fremdfirmenmitarbeiter ein- oder auscheckt, sollen diese Ereignisse im System gespeichert werden (Name/ID der Person, Zeitstempel, Ort falls relevant). Diese Daten dienen als Grundlage, um die tatsächliche Anwesenheitsdauer und den möglichen Leistungszeitraum zu bestimmen. | Das System sollte mobile oder dezentrale Erfassungsmöglichkeiten bieten, um Leistungen direkt am Einsatzort zu dokumentieren. Beispielsweise könnten Fremdfirmen-Vorarbeiter über eine mobile App Arbeitsfortschritte oder erbrachte Mengen eingeben, die dann vom System mit anderen Daten (Zeitstempeln, Sensorwerten) gegengeprüft werden. Eine mobile App wäre auch hilfreich, um z. B. digitale Unterschriften für Leistungsnachweise vor Ort einzuholen. |
| Anhand der Echtzeitdaten muss die Plattform eine Validierung der gemeldeten Leistungen durchführen. Konkret: Wenn ein Dienstleister z. B. 10 Arbeitsstunden für einen Tag abrechnet, aber die Gate-Access-Daten zeigen, dass der Mitarbeiter nur 8 Stunden auf dem Gelände war, so muss das System dies erkennen und als Abweichung markieren. Ebenso kann überprüft werden, ob die Anzahl der auf dem Gelände anwesenden Mitarbeiter mit den vertraglich geplanten Ressourcen übereinstimmt. | Echtzeit-Überwachung: Es sollte möglich sein, dass autorisierte Nutzer (z. B. Schichtleiter, Werksschutz) in einem Dashboard live sehen können, welche Fremdfirmen gerade vor Ort sind, wie viele Personen von welcher Firma anwesend sind und ggf. seit wann. Dies dient sowohl der Kontrolle als auch der Sicherheit (z. B. Evakuierungsmanagement). Diese Anforderung überschneidet sich mit Dashboards (siehe nächsten Abschnitt). |
| Schnittstellenvielfalt: Die Lösung muss offene Schnittstellen oder Konnektoren für gängige Systeme zur Zeiterfassung und Zutrittskontrolle bieten. Das umfasst z. B. Unterstützung für Systeme mit RFID-Karten, biometrische Zugangssysteme oder turnusbasierte Zeiterfassung. Sollte das Unternehmen mehrere verschiedene Systeme an unterschiedlichen Standorten nutzen, muss die Plattform entsprechend flexibel sein. | Zusätzliche Datenquellen: Wünschenswert ist, dass auch IoT-Daten oder Maschinendaten einbezogen werden können, sofern sie relevant für die Leistung sind. Beispiel: Der Dienstleister rechnet nach Bohrmetern ab, und ein Sensor liefert die tatsächlich gebohrten Meter einer Maschine – solche Daten könnten direkt ins System fließen zur Validierung. Diese Art von Integration wird als Soll angesehen und kann im ersten Schritt optional bleiben, sollte aber perspektivisch möglich sein. |
| Datenverknüpfung: Die Echtzeit-Leistungsdaten müssen in der Plattform mit den jeweiligen Aufträgen/Leistungen verknüpft werden. Zum Beispiel: Ein Fremdfirmenmitarbeiter wird bei Zutritt einem bestimmten Auftrag oder einer Kostenstelle zugeordnet (ggf. durch Vorausplanung oder Auswahl im System). So kann man später genau sehen, welche Zeit und Aktivität zu welchem Auftrag gehörte. Falls eine automatische Zuordnung nicht immer möglich ist (z. B. Mitarbeiter ist für mehrere Aufträge vor Ort), muss es eine Möglichkeit geben, die erfassten Zeiten manuell oder halbautomatisch dem richtigen Vorgang zuzuweisen. | |
| Datengenauigkeit und -schutz: Alle erfassten personenbezogenen Echtzeitdaten müssen gemäß Datenschutzrichtlinien behandelt werden. Die Plattform muss sicherstellen, dass z. B. Zeiterfassungsdaten nur zu legitimen Zwecken (Abrechnung, Sicherheit) genutzt werden und die Speicherung im Einklang mit DSGVO erfolgt (z. B. begrenzte Aufbewahrungsdauer für Roh-Zugangsdaten, Pseudonymisierung wo möglich). |
Rollenbasierte Benutzeroberfläche und Echtzeit-Dashboards
Beschreibung: Die Plattform wird von unterschiedlichen Benutzergruppen mit verschiedenen Interessen verwendet. Ein zentrales Erfordernis ist daher eine rollenbasierte Benutzeroberfläche, die jedem Anwender einen auf seine Aufgaben zugeschnittenen Zugang ermöglicht. Das erhöht sowohl die Usability (Benutzer sehen nur Relevantes, weniger Komplexität) als auch die Sicherheit (keine unberechtigten Zugriffe auf vertrauliche Daten).
Typische Rollen könnten sein:
Einkauf/Contract Manager: hat Einblick in Verträge, Bestellungen, Konditionen; pflegt Vertragsstammdaten; überwacht Vertragsauslastung.
Rechnungsprüfer/Buchhaltung: sieht eingehende Rechnungen, Prüfergebnisse, gibt Rechnungen frei; Fokus auf finanziellen Aspekten.
Instandhaltungsingenieur/Produktion: plant Einsätze, sieht welche Fremdfirmen gerade im Werk sind, bestätigt Leistungserbringung (Abnahmen).
Sicherheitsbeauftragter/Werksschutz: überwacht Zutritte, bekommt Alarm, wenn Unbefugte vor Ort sind oder wenn Personen ohne Freigabe anwesend sind (Schnittstelle EHS).
Dienstleister (Externe Rolle): kann ggf. über ein Portal eigene Einsätze einsehen, Zeiten erfassen, Dokumente hochladen (z. B. Lieferscheine, Leistungsberichte) und den Status seiner Rechnungen verfolgen.
Die Dashboards in der Anwendung sollen konfigurierbare Übersichtsseiten sein, die in Echtzeit Kennzahlen und Statusinformationen anzeigen. Beispiele für Dashboard-Widgets: Anzahl Fremdfirmen-Mitarbeiter aktuell vor Ort, geleistete Stunden heute vs. geplant, Kostenverbrauch im laufenden Monat vs. Budget, Anzahl offene Rechnungen zur Freigabe, Performance-Score je Dienstleister (Ampel), etc. Durch Echtzeit-Dashboards kann proaktiv gesteuert werden; kritische Abweichungen werden sofort sichtbar.
Jeder Rolle sollen entsprechende Dashboards bereitgestellt werden. Zusätzlich sollte es möglich sein, die Dashboards zu personalisieren (innerhalb der durch die Rolle erlaubten Daten), um individuelle Schwerpunkte zu setzen.
Anforderungen (UI und Dashboards):
| Muss | Soll |
|---|---|
| Die Plattform muss ein rollenbasiertes Berechtigungskonzept implementieren. Benutzerkonten werden Rollen oder fein-granularen Berechtigungsprofilen zugeordnet, welche bestimmen, welche Module, Funktionen und Daten jeweils sichtbar oder bearbeitbar sind. Beispielsweise muss es möglich sein, dass ein Dienstleister-Manager zwar die für ihn relevanten Auftrags- und Leistungsdaten sieht, aber keine vertraulichen internen Kostendaten. Umgekehrt sieht die Buchhaltung Rechnungsdetails, jedoch keine operativen Wartungspläne. Die Rechteverwaltung muss mindestens auf Funktionsebene und Objektebene differenzieren (z. B. „darf alle Berichte sehen“ vs. „darf nur Berichte für Bereich X sehen“). | Personalisierung: Benutzer sollten ihre Dashboards innerhalb gewisser Grenzen anpassen können. Zum Beispiel Widgets aus einer Bibliothek auswählen, Layout verändern oder Filter setzen (z. B. Fokus auf bestimmte Projekte oder Zeiträume). Dies erhöht die Akzeptanz, da jeder die für ihn wichtigsten Kennzahlen hervorheben kann. |
| Granularität und Administrierbarkeit: Es muss eine administrierbare Benutzer- und Rollenverwaltung geben, in der neue Benutzer angelegt und ihnen Rollen zugewiesen werden können. Rollen sollen hinsichtlich Rechte (CRUD-Operationen auf Datenobjekte, Modulzugriff) konfigurierbar sein. Im Idealfall können bestehende Rollen als Templates dienen und angepasst oder verfeinert werden. | Benachrichtigungen: Neben statischen Dashboards sollte das System auch ein Benachrichtigungssystem beinhalten (z. B. als Teil des UI, oder per E-Mail/SMS Push). Rollenabhängig bekommen Nutzer proaktive Hinweise, z. B. „Neue Rechnung X eingetroffen und geprüft – bitte Freigabe erteilen“, oder „Dienstleister Y hat Performance-Warnstufe erreicht“. Solche Notifications fördern die Echtzeit-Steuerung über das reine Dashboard hinaus. |
| Die Benutzeroberfläche muss übersichtlich, intuitiv und web-basiert sein. Moderne Usability-Standards sind einzuhalten (konsistente Navigation, ansprechendes UI-Design, kurze Ladezeiten – siehe auch Nicht-funktionale Anforderungen zur Usability). Für alle Hauptrollen sollten Übersichtsseiten (Dashboards) zur Verfügung stehen, die die wichtigsten Informationen auf einen Blick bieten. | Mehrsprachigkeit der UI: Falls der Einsatz in mehrsprachigen Teams oder international geplant ist, sollte die Oberfläche mehrsprachig zur Verfügung stehen (Deutsch/Englisch mindestens). Jeder Benutzer könnte die bevorzugte Sprache einstellen. Dieses Kriterium ist insbesondere relevant, wenn externe Dienstleister Zugänge erhalten (z. B. internationale Firmen). – Hinweis: Sollte die Lösung nicht mehrsprachig sein, ist das kein absolutes Ausschlusskriterium, solange Deutsch voll unterstützt wird, aber es würde als Nachteil bewertet. |
| Echtzeit-Dashboards: Das System muss Dashboards anbieten, die Echtzeitdaten anzeigen. Dazu gehört etwa: Live-Update der aktuellen Personenanzahl auf dem Gelände; Aktualisierung der Kostenzähler, sobald neue Leistungen erfasst werden; Anzeige von Alerts (z. B. „Rechnung über 50.000 € wartet seit 2 Tagen auf Freigabe“). Die Echtzeitfähigkeit kann mittels WebSocket/Push-Technologie umgesetzt sein, oder durch sehr häufige Refreshes – Hauptsache, der Benutzer sieht stets den aktuellen Stand ohne manuelles Neuladen. | |
| Kontextsensitive Hilfen: Für eine hohe Benutzerfreundlichkeit muss das System an geeigneten Stellen Hilfestellungen bieten (z. B. Tooltipps, Hilfeseiten oder ein Online-Handbuch). Insbesondere komplexe Funktionen wie die Einrichtung von Prüfregeln oder das Erstellen von Reports sollten dokumentiert und ggf. mit Tutorials hinterlegt sein. Dies erleichtert die Einführung und täglichen Nutzung erheblich. |
Performanceanalyse und Kennzahlen der Dienstleister
Beschreibung: Ein entscheidender Mehrwert der Plattform besteht darin, über die Abrechnung hinaus die Leistungsfähigkeit der Fremdfirmen messbar zu machen. Bisher liegen solche Bewertungen oft subjektiv oder verteilt vor (z. B. einzelne Erfahrungsberichte von Fachabteilungen). Das System soll eine zentrale Datenbasis schaffen, um die Performance jedes Dienstleisters anhand quantitativer Kennzahlen (KPIs) zu bewerten. Diese Kennzahlen werden aus den erfassten Betriebsdaten und evtl. manuell erfassten Bewertungen generiert. Ziel ist es, Vergleichbarkeit herzustellen und datenbasierte Entscheidungen bei zukünftigen Vergaben zu unterstützen (Vendor Rating).
Wichtige Performance-Kriterien können sein (die konkrete Gewichtung kann vom Unternehmen festgelegt werden):
Termintreue: Hält der Dienstleister vereinbarte Termine ein? (z. B. Prozentsatz der Aufträge, die fristgerecht abgeschlossen wurden.)
Kostenperformance: Bleibt der Dienstleister im Kostenrahmen? (Vergleich Soll-Kosten vs. Ist-Kosten pro Auftrag, Häufigkeit von Nachträgen.)
Qualität der Arbeit: Anzahl der Mängelrügen, Qualitätsmängel, Notwendigkeit von Nacharbeiten oder Wiederholungsarbeiten.
Arbeitssicherheit: Anzahl von meldepflichtigen Unfällen oder Sicherheitsverstößen, die Dienstleistermitarbeiter betreffen.
Produktivität/Effizienz: Output pro Zeiteinheit (sofern messbar, z. B. Meter Bohrung pro Tag), Verhältnis produktive zu unproduktiver Zeit etc.
Administrative Zuverlässigkeit: Pünktlichkeit und Korrektheit der Rechnungsstellung, Vollständigkeit von Dokumentationen, Mitwirkung bei Dokumentationspflichten.
Die Plattform sollte über Berichte und Scorecards jedem Dienstleister einen Performance-Überblick geben. Dies könnte z. B. ein Lieferanten-Steckbrief sein mit Kennzahlen und ggf. einem Rating (z. B. Schulnoten- oder Ampelsystem). Außerdem sollte der Verlauf über die Zeit sichtbar sein (Trendanalysen: verbessert sich der Dienstleister oder wird er schlechter?). Solche Informationen sind intern nützlich (für Lieferantengespräche) und können auch dem Dienstleister feedbackartig zurückgespiegelt werden.
Anforderungen (Performanceanalyse):
| Muss | Soll |
|---|---|
| Das System muss die Erfassung und Berechnung von Leistungskennzahlen (KPIs) für Dienstleister ermöglichen. Die relevanten KPIs werden gemeinsam mit dem Auftraggeber definiert, aber das System muss die Flexibilität bieten, diese Kennzahlen aus den Basisdaten abzuleiten. Beispielsweise kann aus der Differenz geplanter Endtermin vs. tatsächlicher Endtermin eine Kennzahl „Termintreue in Tagen Verzögerung“ berechnet werden. Solche Berechnungen müssen konfigurierbar sein (z. B. via Formeln oder Scripting im System). | Es sollte möglich sein, gewichtete Gesamtbewertungen zu erstellen. Zum Beispiel könnte das Unternehmen definieren, dass Termintreue 30 %, Qualität 30 %, Kostenperformance 20 %, Sicherheit 20 % in eine Gesamt-Score fließen. Das System sollte diese Gewichtung berücksichtigen und eine aggregierte Scorecard je Lieferant ausgeben (etwa 85/100 Punkte oder „Lieferant A = Note 2,0“). Dies wäre hilfreich als Management-Summary. |
| Es muss Berichte bzw. Dashboards pro Dienstleister geben, welche die wichtigsten KPIs übersichtlich darstellen. Ein Einkäufer oder Qualitätsmanager soll auf einen Blick erkennen können, wie ein Dienstleister im letzten Quartal performt hat. Grafische Aufbereitungen (Balken-/Liniencharts für Trend, Tacho-/Ampelanzeigen für aktuelle Bewertung) sind wünschenswert, um komplexe Daten schnell erfassbar zu machen. | Das System sollte erlauben, zusätzliche Bewertungskriterien manuell zu erfassen, die nicht direkt aus Zahlen ableitbar sind. Beispielsweise könnte der Projektleiter nach Abschluss eines Projekts eine subjektive Bewertung des Dienstleisters eingeben (Skala 1–5 oder Freitextkommentar). Diese könnte ins Gesamtbild mit einfließen oder zumindest in Berichten sichtbar sein. Damit können „weiche“ Faktoren berücksichtigt werden. |
| Die Plattform muss die Vergleichbarkeit zwischen Dienstleistern unterstützen. Das heißt, ein berechtigter Nutzer sollte z. B. zwei oder mehr Dienstleister nach bestimmten Kennzahlen nebeneinanderstellen können (Benchmarking). Beispielsweise ein Ranking der Dienstleister nach Unfallhäufigkeit, oder ein Vergleich der Stundensätze gegen Produktivität. Solche Vergleiche helfen bei Entscheidungen, welchen Dienstleister man bevorzugt beauftragt. | Alarmierung: Wenn ein Dienstleister bestimmte Schwellenwerte überschreitet (z. B. KPI „Termintreue“ fällt unter 80 % oder es gab >3 Sicherheitsvorfälle im Jahr), sollte das System automatisch einen Alarm oder Hinweis generieren. Dies könnte im Dashboard erscheinen oder per E-Mail an verantwortliche Personen gehen, damit frühzeitig Maßnahmen ergriffen werden (z. B. Gespräch mit dem Lieferanten, Audits, etc.). |
| Trendanalysen: Für jede Kennzahl muss das System historische Verläufe speichern und darstellen können. Es soll erkennbar sein, ob ein Dienstleister sich verbessert oder verschlechtert (z. B. Chart über die letzten 8 Quartale oder Ampelhistorie). Dadurch können langfristige Entwicklungen beurteilt werden. | |
| Export und Berichtswesen: Die ermittelten Performancekennzahlen müssen exportierbar sein (Excel, PDF-Berichte) und für Audits oder Meetings zur Verfügung gestellt werden können. Idealerweise sind Standardberichte für regelmäßige Meetings (z. B. quartärliche Lieferantenbewertung) bereits vorhanden oder können leicht konfiguriert werden. |
Predictive Analytics und Reporting
Beschreibung: Über das operative Tagesgeschäft hinaus soll die Plattform Management und Fachbereichen Analysen und Prognosen liefern. Reporting umfasst hierbei klassische Abfragen und Auswertungen (Was ist passiert? Wo stehen wir?), während Predictive Analytics die vorausschauende Komponente abdeckt (Was wird wahrscheinlich passieren?). Beide Aspekte greifen ineinander und nutzen den gleichen Datenpool.
Reporting: Die Lösung soll umfangreiche Berichtsfunktionen bieten.
Dazu gehören Standardreports wie z. B.:
Monats- und Quartalsberichte über Fremdfirmenleistungen und -kosten pro Kostenstelle/Bereich.
Übersicht der aktuell laufenden Verträge und deren Auslastung (Vertragswert vs. bereits abgerufen/abgerechnet).
Rechnungsdurchlaufzeiten (vom Eingang bis zur Zahlung) als KPI für Prozessqualität.
Auflistung der Fremdfirmenmitarbeiter mit den meisten Einsatzstunden (für Monitoring von z. B. Arbeitsschutzlimits).
Predictive Analytics:
Basierend auf historischen Daten und aktuellen Trends sollen Prognosemodelle helfen, zukünftige Entwicklungen abzuschätzen.
Beispiele:
Kostenprognose: Anhand des bisherigen Monatsverbrauchs an Fremddienstleisterkosten prognostiziert das System das Jahresende-Ergebnis je Kostenstelle und warnt ggf. vor Budgetüberschreitung.
Personalbedarfsprognose: Analyse vergangener Projekte zur Ermittlung, welcher Fremdpersonalbedarf in bevorstehenden Projekten wahrscheinlich ist (z. B. typische Spitzenzeiten, erforderliche Qualifikationen).
Risikoprognose: Identifikation von Projekten, bei denen aufgrund bestimmter Indikatoren (z. B. bereits jetzt Verzug + bestimmter Dienstleister mit schlechter Performance) die Wahrscheinlichkeit hoch ist, dass es zu Problemen kommt. Das System könnte solche Projekte flaggen.
What-if-Analysen: Möglichkeit, Szenarien durchzuspielen (z. B. „Was passiert mit den Kosten, wenn die Stundensätze um 5% steigen?“ oder „Wie würde ein Ausfall von Dienstleister X kompensiert werden können?“).
Für Predictive Analytics werden häufig ML-Algorithmen auf den vorhandenen Daten angewandt. Es ist nicht zwingend erforderlich, dass die Plattform out-of-the-box komplexe KI-Modelle mitbringt, aber zumindest sollte sie die Datenbasis so aufbereiten (und Schnittstellen bereitstellen), dass solche Analysen möglich sind. Ein Pluspunkt wäre, wenn bereits bestimmte prädiktive Funktionen implementiert sind.
Anforderungen (Analytics & Reporting):
| Muss | Soll |
|---|---|
| Die Plattform muss eine Reporting-Komponente enthalten, die es ermöglicht, Standardberichte zu Fremdfirmenmanagement abzurufen. Diese Berichte sollten aussagekräftige Kennzahlen und Listen enthalten, gegliedert nach für den Betrieb wesentlichen Strukturen (z. B. Berichte je Standort, je Kostenstelle, je Projekt, je Dienstleister). Der Inhalt der Standardberichte wird in Abstimmung mit dem Auftraggeber festgelegt und sollte konfigurierbar sein. | BI-Integration: Es sollte möglich sein, das System an externe Business-Intelligence-Tools anzubinden (z. B. via ODBC/JDBC oder APIs). Falls das interne Reporting nicht alle gewünschten Tiefenanalysen abdecken kann, könnten so Daten in ein Data Warehouse fließen und dort weiter analysiert werden. Dieses Kriterium ist ein Soll, da es von der Datenstrategie des Unternehmens abhängt. |
| Ad-hoc-Analyse: Berechtigte Benutzer (z. B. Controller, Power-User) müssen die Möglichkeit haben, individuelle Abfragen und Berichte zu erstellen. Das kann über integrierte Tools (wie einen Query-Builder mit GUI) oder zumindest über direkte Abfragemöglichkeiten (Export nach Excel und dort Pivotierung) erfolgen. Idealerweise bietet das System eine Drag-and-drop-Oberfläche für Analysen, in der Felder (z. B. „Dienstleistername“, „Monat“, „Kosten“) frei kombiniert werden können. | Eingebaute Prognosemodelle: Wünschenswert (Soll) ist, dass die Plattform bereits einige Predictive Analytics-Funktionalitäten mitliefert. Etwa eine Forecast-Funktion für Kosten: Auf Basis bisheriger Ausgaben pro Monat berechnet das System automatisch eine Hochrechnung für das Jahresende und visualisiert diese. Oder ein Modul zur Anomalie-Erkennung, das ungewöhnliche Muster (z. B. plötzlich stark steigende Stunden in einem Bereich) erkennt und meldet. Diese Funktionen würden den Wert der Lösung steigern, sind aber als Soll-Kriterien klassifiziert. |
| Datenhistorie: Das System muss Daten historisch vorhalten, um Trends ermitteln zu können. D. h. es darf keine rein überschreibende Speicherung ohne Archiv geben. Vielmehr sollen z. B. für jedes Jahr die Leistungs- und Kostenwerte erhalten bleiben (auch wenn Verträge enden), um Längsschnittanalysen durchführen zu können. | Simulation und What-if: Die Möglichkeit, Szenarien durchzuspielen, sollte gegeben sein. Z. B. erlaubt ein Kosten-Dashboard das Verändern von Parametern (Stundensatz X +10 %) und zeigt unmittelbar die Auswirkung auf das Jahresbudget. Solche Simulationsfunktionen helfen bei der Planung (z. B. Budgetverhandlungen, Rate Card Anpassungen mit Dienstleistern). |
| Predictive-Funktionen (Grundlage): Die Plattform muss zumindest die Grundlage für prädiktive Analysen bereitstellen, indem sie strukturierte Daten und ggf. vorgefertigte Algorithmen anbietet. Zum Beispiel sollte sie historische Zeitreihendaten so präsentieren können, dass man eine Trendlinie und Forecast darauf legen kann. Wenn keine komplexen KI-Funktionen eingebaut sind, muss zumindest der Datenzugriff offen sein, sodass externe Data-Science-Tools die Daten ziehen und Modelle erstellen können. | |
| Benutzerfreundlichkeit im Reporting: Trotz der Komplexität von Analytics muss die Handhabung für Endanwender verständlich sein. Das heißt, Berichte sollten mit wenigen Klicks abrufbar sein, Visualisierungen klar beschriftet und interaktiv (Filtern, Drill-down) wo möglich. Dokumentation und Schulung für diese Komponenten sind erforderlich, damit die Nutzer den vollen Nutzen daraus ziehen können. | |
| Ausgabe und Export: Alle Berichte und Analysen müssen in gängigen Formaten ausgebbar sein (PDF-Report für Management, Excel-Export für weitere Datenverarbeitung). Auch ein zeitgesteuerter Reportversand (z. B. Monatsreport automatisch per E-Mail an definierte Empfänger) sollte möglich sein, um wiederkehrende Aufgaben zu automatisieren. |
Nicht-funktionale Anforderungen
Neben den fachlichen Funktionen spielen Qualitätsanforderungen und Rahmenbedingungen eine entscheidende Rolle für den Erfolg der Plattformeinführung. Im Folgenden sind die nicht-funktionalen Anforderungen aufgeführt, die sicherstellen, dass die Lösung sicher, zuverlässig, skalierbar und benutzerfreundlich ist. Viele dieser Kriterien sind Muss-Kriterien, da sie grundlegende Erwartungen an professionelle Softwarelösungen darstellen.
Sicherheit und Compliance
Beschreibung: Angesichts sensibler Unternehmensdaten (Kosten, Verträge, Personenzeiten) ist ein höchstes Maß an IT-Sicherheit unerlässlich. Gleichzeitig müssen alle einschlägigen Compliance-Vorgaben (Gesetze, Normen, interne Richtlinien) erfüllt werden. Gerade bei Cloud-Lösungen ist das Vertrauen in die Sicherheitsmechanismen des Anbieters ausschlaggebend. Hier sind Zertifizierungen wie SOC 2 und ISO 27001 als Indikatoren heranzuziehen, die belegen, dass der Dienstleister etablierte Sicherheitskontrollen implementiert hat. Zusätzlich gelten in der EU die Anforderungen der DSGVO (Datenschutz-Grundverordnung) für den Umgang mit personenbezogenen Daten – im Kontext Fremdfirmen wären das z. B. Namen, Ausweisnummern, Zeitstempel der Mitarbeiter. Die Plattform muss so gestaltet sein, dass Datenschutzgrundsätze (Datensparsamkeit, Zweckbindung, Auskunftsrecht usw.) eingehalten werden können.
Sicherheit umfasst u. a. Zugriffsschutz (Authentifizierung, Rollen und Berechtigungen – vgl. funktionale Anforderungen), Datenverschlüsselung, Schutz vor Cyberangriffen (z. B. OWASP Top 10 für Webanwendungen, DDoS-Schutz), regelmäßige Backups und Notfallwiederherstellung, sowie Monitoring und Logging sicherheitsrelevanter Events. Compliance-seitig sind neben DSGVO ggf. branchenspezifische Vorgaben (im Bergbau z. B. Berichtspflichten gegenüber Aufsichtsbehörden, falls Fremdfirmen bestimmte Arbeiten ausführen) relevant, die unterstützt werden müssen.
Anforderungen (Sicherheit & Compliance):
| Muss | Soll |
|---|---|
| Der Anbieter/die Plattform muss nachweislich ein hohes Sicherheitsniveau gewährleisten. Idealerweise liegt eine Zertifizierung nach ISO/IEC 27001 vor oder ein aktueller SOC 2 Type II Report. Insbesondere die Trust Principles von SOC 2 – Security, Availability, Processing Integrity, Confidentiality, Privacy – müssen adressiert sein. Der Bieter sollte entsprechende Nachweise in der Angebotsphase liefern können (z. B. Zertifikate, Auditberichte). | Penetrationstests & Schwachstellenmanagement: Es sollte etabliert sein, dass regelmäßig Penetrationstests durch unabhängige Experten durchgeführt werden und erkannte Schwachstellen zeitnah behoben werden. Der Anbieter sollte Security-Patches zeitnah einspielen können (auch das gehört zur Compliance). Wenn die Lösung individuell entwickelt wird, sollte ein Secure Development Lifecycle (nach OWASP o. ä.) nachgewiesen werden können. |
| Zugangssicherheit: Die Lösung muss ein robustes Authentifizierungssystem haben. Nutzerkonten sind durch starke Passworte (Passwortrichtlinie) zu schützen; vorzugsweise wird auch 2-Faktor-Authentifizierung (2FA) unterstützt (Sollte falls nicht standardmäßig). Falls im Unternehmen ein zentrales Identity Management (z. B. Active Directory, SAML) genutzt wird, muss die Plattform Single Sign-On (SSO) integrieren können, um den Benutzern eine nahtlose und sichere Anmeldung zu ermöglichen. | Protokollierung und Audit: Alle sicherheitsrelevanten Ereignisse (Login-Versuche, Änderungen von Berechtigungen, etc.) sollten protokolliert werden. Zudem sollten Audit-Logs vorhanden sein, die Zugriffe auf sensible Daten nachvollziehbar machen (wer hat wann welche Daten eingesehen/verändert). Diese Logs müssen vor Manipulation geschützt und für einen definierten Zeitraum aufbewahrt werden, damit im Fall eines Security Incidents forensische Analysen möglich sind. |
| Rechte- und Rollenmanagement: (Siehe funktionale Anforderungen) – hier non-funktional ergänzt: Es muss sichergestellt sein, dass das Berechtigungsmodell keine Umgehungen zulässt (z. B. darf ein externer Dienstleister keine Möglichkeit haben, durch URL-Manipulation auf andere Daten zuzugreifen). Das System muss umfassend getestet sein auf Zugriffsschutz. Auch Administratorenrechte sollten staffelbar sein (Prinzip der minimalen Rechte). | Rechtskonformität sonstige: Je nach Ausgestaltung können weitere Compliance-Aspekte relevant sein. Z. B. steuerrechtliche Vorgaben an elektronische Rechnungen (Stichwort GoBD, elektronische Archivierung) – die Plattform sollte kompatibel sein mit XRechnung/ZUGFeRD-Formaten, falls elektronische Rechnungen mit öffentlichen Auftraggebern ausgetauscht werden. Oder Nachweisführung Arbeitsschutz: falls relevant, sollte man nachhalten können, wer unterwiesene Personen waren etc. Diese Dinge sind als Soll-Kriterien zu betrachten, die je nach Angebot bewertet werden. |
| Verschlüsselung: Alle sensiblen Daten müssen angemessen verschlüsselt sein. Daten in Ruhe (at rest) auf Servern/ in der DB sind durch Verschlüsselung zu schützen (z. B. AES-256 Standard). Daten in Übertragung (in transit) müssen durch aktuelle Protokolle wie TLS 1.2+ gesichert werden. Dies gilt sowohl für die Benutzerschnittstelle (HTTPS für Web) als auch für Integrationsschnittstellen (APIs). | |
| Datenschutz (DSGVO): Das System muss DSGVO-konform sein, sofern personenbezogene Daten von EU-Bürgern verarbeitet werden. Dies beinhaltet u. a.: Einwilligungs- oder Berechtigungskonzepte für personenbezogene Daten der Fremdfirmenmitarbeiter, Möglichkeit zur Auskunft und Löschung (z. B. wenn ein Mitarbeiter nicht mehr tätig ist, müssen seine persönlichen Daten nach gewisser Zeit anonymisiert oder gelöscht werden, solange es nicht gegen Aufbewahrungspflichten verstößt). Zudem ist sicherzustellen, dass Daten nur zu definierten Zwecken verwendet werden (hier: Abrechnung, Einsatzsteuerung) und nicht zweckentfremdet. Eine Auftragsverarbeitungsvereinbarung wird Teil des Vertrags mit dem Softwareanbieter sein. | |
| Backup und Disaster Recovery: Der Anbieter muss Konzepte für regelmäßige Backups und schnelle Wiederherstellung im Fehlerfall vorweisen. Ein Datenverlust (über das erlaubte RPO hinaus) ist inakzeptabel. Beispielsweise sollte mindestens täglich ein Backup erfolgen und eine Wiederherstellungszeit (RTO) von wenigen Stunden bei einem Totalausfall garantiert sein. Nach Möglichkeit sollten Backups verschlüsselt und an geographisch getrennten Orten aufbewahrt werden. | |
| Hochverfügbarkeit: Sicherheit umfasst auch Verfügbarkeit. Die Cloud-Plattform muss eine hohe Uptime gewährleisten, vorzugsweise >99 % im Jahresmittel. Wartungsfenster sollen planbar und möglichst außerhalb der Hauptnutzungszeiten liegen. Redundante Auslegung (z. B. mehrere Server, Ausfallsicherung) wird vorausgesetzt, damit ein einzelner Hardware- oder Softwarefehler nicht zum Ausfall des gesamten Systems führt. | |
| Mandantentrennung: Da die Software mandantenfähig sein soll, muss garantiert sein, dass Mandantendaten strikt voneinander getrennt sind. Ein Mandant darf keinerlei Möglichkeit haben, auf Daten eines anderen zuzugreifen. Dies sollte architektonisch (z. B. durch Mandanten-ID in jedem Datensatz und entsprechende Filters in allen Abfragen) und organisatorisch (Mandanten-Administration getrennt) umgesetzt sein. Mandantenfähigkeit erstreckt sich auch auf Konfigurationen: möglichst sollten Einstellungen pro Mandant vorgenommen werden können, ohne global zu wirken (sofern z. B. zwei unterschiedliche Geschäftsbereiche leicht abweichende Prozesse haben). |
Architektur, Betrieb und Skalierbarkeit
Beschreibung: Die Anforderungen an Architektur und Betrieb der Plattform stellen sicher, dass die Lösung technisch zukunftsfähig, effizient und gut in die IT-Landschaft integrierbar ist. Gefordert ist ein Cloud-basiertes System, was in der Regel bedeutet, dass der Softwareanbieter die Anwendung in einem Rechenzentrum hostet (SaaS – Software as a Service). Für den Kunden ist wichtig, dass diese Cloud-Architektur mandantenfähig und skalierbar ist, um sowohl aktuelle Bedürfnisse abzudecken als auch Wachstum oder geänderte Anforderungen zu verkraften. Außerdem spielen Aspekte wie Performance (Schnelligkeit der Anwendung), Portabilität (Verfügbarkeit auf verschiedenen Endgeräten) und Wartbarkeit (wie einfach können Updates eingespielt werden, Konfigurationen vorgenommen werden) eine Rolle.
In industriellen Umgebungen ist auch die Robustheit der Lösung wichtig: Sie sollte auch unter erschwerten Bedingungen (z. B. schwankende Internetverbindung an entlegenen Standorten) möglichst stabil laufen. Falls Cloud-Verbindung temporär wegfällt, sollte die Anwendung dies z. B. puffern oder es sollte Fallback-Lösungen geben.
Skalierbarkeit bedeutet konkret: die Plattform soll z. B. problemlos von 50 auf 500 gleichzeitige Nutzer ausgebaut werden können; die Datenbank soll wachsende Datenmengen (Millionen von Datensätzen über Jahre) performant verwalten können; neue Standorte oder Mandanten sollen konfigurationsseitig hinzugefügt werden können, ohne dass separate Installationen nötig sind. Mandantenfähigkeit (siehe Definition) ermöglicht dabei effizienteres Skalieren, weil nicht für jeden Mandanten eigene Server benötigt werden. Wenn allerdings aus Politikgründen eine dedizierte Instanz für den Auftraggeber erforderlich wäre (Private Cloud), sollte der Anbieter dies auch ermöglichen können – sprich: Multi-Tenancy als Option, aber notfalls Single-Tenant-Betrieb in isolierter Umgebung, falls gefordert.
Betrieb in der Cloud bringt auch Anforderungen an Monitoring und Support mit sich: Der Anbieter sollte den Zustand der Anwendung kontinuierlich überwachen (Systemhealth, Performance-Metriken) und proaktiv reagieren, bevor der Kunde etwas merkt. Zudem braucht es klare SLAs (Service Level Agreements) hinsichtlich Support (Reaktionszeit bei Störungen, Verfügbarkeit der Hotline etc.).
Anforderungen (Architektur & Skalierbarkeit):
| Muss | Soll |
|---|---|
| Die Software muss als Cloud-Lösung bereitgestellt werden (SaaS). Das bedeutet, der Zugriff erfolgt über Internet, der Betrieb wird vom Anbieter sichergestellt. Alternative Bereitstellungsmodelle (Private Cloud, On-Premises) können optional angeboten werden, sofern sie der Sicherheit nicht abträglich sind, aber der primäre Erwartungsrahmen ist eine Cloud-Lösung, um Wartungsaufwand auf Anbieterseite zu belassen. | Offline-Fähigkeit/Pufferung: Es wäre vorteilhaft, wenn gewisse Kernfunktionen auch bei temporär fehlender Netzwerkverbindung nicht komplett blockieren. Beispielsweise könnte eine mobile App im Offline-Modus Daten zwischenspeichern (erfasste Leistungen) und später synchronisieren. Oder das Web-Frontend puffert Eingaben, falls die Verbindung kurz hakt. In der Bergbau-Praxis kann es Remote-Situationen geben, wo Connectivity ein Thema ist – eine robuste Anwendung berücksichtigt das (Soll-Kriterium). |
| Die Architektur muss mandantenfähig sein (siehe Definition oben). Für den Auftraggeber bedeutet dies, dass ggf. verschiedene Organisationseinheiten im Unternehmen als getrennte Mandanten auf derselben Plattform agieren können, oder dass man später andere Partner (z. B. Tochterfirmen) aufschalten könnte. Daten-Isolation ist Pflicht, Performance-Isolation wünschenswert (d. h. ein Mandant mit sehr hoher Last sollte die anderen nicht ausbremsen). | Konfigurierbarkeit statt Programmierung: Es sollte möglich sein, Anpassungen an Prozessen, Workflows, Formularen etc. durch Konfiguration vorzunehmen statt durch Code-Anpassungen. Ein anpassbares Regelwerk (siehe Rechnungsprüfung), flexible Report-Designer und Administrationsoberflächen für z. B. Drop-Down-Werte ermöglichen, dass das System auch bei Prozessänderungen schnell mitgezogen werden kann. Dieser Punkt beeinflusst die total cost of ownership: Je weniger (kostenintensive) Entwicklungsleistungen für Änderungen nötig sind, desto besser. |
| Skalierbarkeit: Die Lösung muss nachweislich skalieren können. Der Bieter sollte angeben, welche Maximallasten im produktiven Einsatz unterstützt werden (z. B. Anzahl gleichzeitiger Benutzer, Transaktionen pro Stunde). Insbesondere muss die Plattform mit wachsenden Fremdfirmen-Einsätzen skalieren: Wenn sich z. B. die Zahl der erfassten Stunden pro Jahr verdoppelt oder zehnmal so viele Geräte angebunden werden, darf das System nicht inakzeptabel langsam werden. Technisch sollte dies durch horizontale Skalierung (Load Balancer + zusätzliche Application Server, skalierbare Cloud-Datenbank, etc.) erreicht werden. Die Skalierungsmechanismen (manuell vs. auto-scaling) kann der Anbieter erläutern. | Dokumentation und Schnittstellen: Aus architektureller Sicht sollte der Anbieter eine umfangreiche Dokumentation bereitstellen – sowohl für Endnutzer (Benutzerhandbücher) als auch technisch (Schnittstellen-Dokumentation, Datenmodellbeschreibung soweit relevant, Admin-Guides). Dies erleichtert Integration und Betrieb erheblich. |
| Performance: Die Anwendung muss performante Reaktionszeiten aufweisen, auch bei hoher Last. Als Richtwert kann gelten: Für typische Benutzeraktionen (Öffnen eines Dashboards, Aufrufen einer Vertragsdetailseite, Buchen einer Leistung) sollte die Antwortzeit im Mittel < 2 Sekunden liegen. Komplexe Auswertungen dürfen etwas länger dauern, sollten aber nach Möglichkeit < 5–10 Sekunden bleiben. Diese Werte sind Zielgrößen, Abweichungen sind begründbar, aber insgesamt muss die Bedienung flüssig sein, damit die Anwenderakzeptanz hoch ist. | |
| Browser- und Device-Kompatibilität: Die Web-Oberfläche muss mit allen gängigen modernen Browsern kompatibel sein (Chrome, Firefox, Edge, Safari in jeweils aktueller Version). Zudem sollte sie responsive sein, sodass sie auf verschiedenen Bildschirmgrößen (Desktop, Tablet, notfalls Smartphone) nutzbar ist. Falls eine dedizierte mobile App Teil der Lösung ist (z. B. für Android/iOS), muss diese die Kernfunktionen für den Außeneinsatz unterstützen. | |
| Wartbarkeit & Updates: Die Software muss wartbar sein, d. h. der Anbieter sollte regelmäßige Updates/Patches einspielen können, ohne lange Unterbrechungen im Betrieb. Idealerweise erfolgen Updates nahezu transparent (im Hintergrund, in wartungsarmen Zeiten, mit Vorankündigung). Der Bieter muss darlegen, wie Upgrades gehandhabt werden (Frequenz, Downtime, Rückfalloptionen bei Problemen). Aus Sicht des Kunden ist wichtig, dass die Lösung über Jahre aktuell gehalten wird (Weiterentwicklung) und Sicherheitsupdates unverzüglich erhalten kann. | |
| Monitoring & Support: Für den laufenden Betrieb muss der Anbieter ein Monitoring betreiben, das wichtige Systemmetriken überwacht (Serverauslastung, Antwortzeiten, Fehlerraten). Der Kunde erwartet, dass der Anbieter im Problemfall proaktiv reagiert. Zudem muss ein Support-Konzept bestehen: z. B. ein 2nd/3rd-Level Support, erreichbar zu definierten Zeiten, der im Fehlerfall Unterstützung bietet. Entsprechende SLAs (z. B. Reaktionszeit < 1h bei kritischem Systemausfall; < 24h bei normalen Anfragen) sollten im Angebot klar definiert sein. | |
| Betriebsrat/Organisations-Aspekte: Bei der Einführung einer solchen Plattform sind interne Mitbestimmungsgremien (Betriebsrat) zu beteiligen, gerade weil Mitarbeiterdaten erfasst werden (Anwesenheitszeiten). Die Software muss daher Features bieten, die mitbestimmungskonform einstellbar sind (z. B. welche personenbezogenen Daten genau sichtbar sind, Auswertungsmöglichkeiten ggf. einschränkbar, Pseudonymisierung). Diese Anforderung ist zwar eher prozessual, aber relevant: Der Anbieter sollte Erfahrung haben im Rollout solcher Systeme und entsprechende Einstellungen bereitstellen können. |
Integrationsfähigkeit und Offenheit
(Hinweis: Einige Integrationspunkte wurden bereits unter funktionalen Anforderungen genannt, hier werden übergreifende Erwartungen formuliert.)
Beschreibung: Die Plattform wird eingebettet in eine bestehende IT-Landschaft. Neben SAP könnten weitere Systeme relevant sein – von LDAP-Verzeichnissen (für Benutzerauthentifizierung) über E-Mail-Server (für Benachrichtigungen) bis hin zu Fachdatenbanken. Die langfristige Akzeptanz hängt auch davon ab, wie gut das System mit anderen Tools „spricht“. Daher ist eine hohe Integrationsfähigkeit gefordert: klare APIs, Unterstützung von Datenstandards und Formaten, sowie Import/Export-Funktionen.
Auch im Hinblick auf Zukunftssicherheit ist Offenheit wichtig: Der Kunde möchte sich nicht in eine proprietäre Sackgasse manövrieren. Sollte es in Zukunft z. B. notwendig sein, bestimmte Daten in ein Data Lake zu laden oder ein anderes Tool anzubinden, muss dies möglich sein. Idealerweise bietet der Hersteller auch kontinuierlich Integrationsmodule für gängige Anwendungen (Office 365, gängige BI-Tools etc.).
Anforderungen (Integrationsoffenheit):
| Muss | Soll |
|---|---|
| Die Plattform muss über dokumentierte Programmierschnittstellen (APIs) verfügen (z. B. REST/JSON-basierte Webservices), die es erlauben, zentrale Funktionen auch von externen Programmen auszulösen bzw. Daten abzurufen. Beispiel: Eine API, um eine neue Leistungsmeldung anzulegen; eine API, um alle offenen Rechnungen auszulesen. Diese Offenheit ermöglicht es der internen IT, bei Bedarf selbst Erweiterungen oder Datenabfragen zu entwickeln. | Standard-Konnektoren: Wünschenswert ist, dass bereits vorkonfigurierte Konnektoren für verbreitete Systeme existieren. SAP haben wir abgedeckt. Weitere könnten sein: Mailserver (für Benachrichtigung – z. B. SMTP-Settings konfigurierbar), Active Directory/LDAP (für Nutzer-Authentifizierung und -Provisionierung), Power BI/Tableau (vorgefertigte Connectoren zu BI-Tools). Je mehr Integrationspunkte ab Werk unterstützt werden, desto besser – dies wird positiv bewertet, ist aber kein Muss, solange die generische API offen ist. |
| Datenimporte und -exporte: Es muss möglich sein, Stammdaten und Bewegungsdaten in gängigen Formaten zu importieren bzw. exportieren. Z. B. CSV/Excel-Import für Stammdateninitialisierung (Lieferantenliste), PDF-Export für Rechnungen, evtl. auch XML-Formate für e-Invoicing (sofern genutzt). Auch Massen-Updates (z. B. neue Preisliste für einen Dienstleister einspielen) sollten via Upload-Funktion unterstützt werden. | Modularität und Erweiterbarkeit: Die Software-Architektur sollte modular aufgebaut sein, sodass bei Bedarf einzelne Module ergänzt oder deaktiviert werden können. Z. B. falls der Kunde ein eigenes Modul für Besucherregistrierung hat, sollte er das ggf. statt eines mitgelieferten nutzen können, ohne dass Kernfunktionen leiden. Ebenso sollte es möglich sein, später neue Module (vielleicht liefert der Anbieter in Zukunft ein KI-Modul nach) nahtlos zu integrieren. |
| Keine proprietären Lock-Ins bei Daten: Der Kunde muss jederzeit Herr seiner Daten bleiben. Das System muss ermöglichen, alle Daten in einem gängigen Format zu exportieren (z. B. für einen möglichen späteren Systemwechsel). Ein Daten-Export aller relevanten Informationen (in einer dokumentierten Struktur) ist erforderlich. Nur so kann eine technologische Abhängigkeit mit Risiko vermieden werden. | Interoperabilität Standards: Falls branchenrelevante Standards existieren, sollte die Lösung diese unterstützen. Z. B. OPC-UA für Maschinendaten (falls relevant für IoT-Integration), oder HR-XML für Personaldaten, oder gängige Schnittstellen im Procurement (cXML, etc.). Dies ist ein weiches Kriterium – da Technologieoffenheit gefordert ist, wird eine Lösung, die sich gut in Standardarchitekturen einfügt, bevorzugt. |
| Entwicklungs-Werkzeuge: Falls der Kunde kleinere Anpassungen vornehmen will (z. B. ein eigenes Eingabeformular oder Report), muss der Anbieter Wege aufzeigen, wie dies geschehen kann. Sei es durch bereitgestellte SDKs, durch Scripting-Fähigkeit innerhalb der Anwendung oder durch No-Code/Low-Code-Ansätze. Komplett geschlossene Systeme, bei denen jede Anpassung nur durch den Hersteller gegen hohen Aufwand möglich ist, erfüllen dieses Kriterium nicht. | Versionierung und Test: Bei Integrationen ist es wichtig, dass Änderungen versioniert sind. Z. B. API-Versionierung: Die Plattform sollte Updates so handhaben, dass bestehende Integrationen nicht brechen (Abwärtskompatibilität oder Parallelbetrieb alter/new API-Version). Außerdem sollte es für den Kunden möglich sein, ein Test- bzw. Sandbox-System der Plattform zu erhalten, in dem Integrationen gefahrlos getestet werden können, bevor man sie produktiv nutzt. Dies wird als Soll-Kriterium erwartet (in vielen SaaS-Angeboten ist ein Testmandant Standard). |
Benutzerfreundlichkeit und Schulung
Beschreibung: Die Akzeptanz der neuen Plattform im Unternehmen steht und fällt mit der Benutzerfreundlichkeit (Usability). Selbst die beste Funktion nützt nichts, wenn Anwender sie nicht bedienen können oder wollen. Daher werden hier Anforderungen formuliert, die sicherstellen sollen, dass die Software ergonomisch, leicht erlernbar und im Arbeitsalltag effizient nutzbar ist. Dazu gehören Aspekte des UI-Designs (Übersichtlichkeit, Konsistenz), aber auch die Verfügbarkeit von Schulungsunterlagen und ggf. Trainings für die unterschiedlichen Benutzergruppen.
Gerade weil Nutzer aus verschiedenen Abteilungen mit unterschiedlichem IT-Hintergrund damit arbeiten werden (von Ingenieuren in der Instandhaltung bis zu kaufmännischen Sachbearbeitern in der Buchhaltung, und auch externe Partner), muss die Lösung intuitiv gestaltet sein. Gängige Bedienkonzepte (z. B. Anlehnung an Office-Oberflächen oder bekannte Web-UI-Patterns) sind von Vorteil, da sie Wiedererkennungseffekte bieten. Auch sollten Oberflächen möglichst an den Prozessfluss angepasst sein – z. B. ein geführter Workflow für die Rechnungsfreigabe anstelle von verstreuten Einzelmasken.
Anforderungen (Usability & Schulung):
| Muss | Soll |
|---|---|
| Intuitive Bedienung: Die Anwendung muss eine klare und konsistente Benutzeroberfläche aufweisen. Alle wichtigen Funktionen sollten mit wenigen Klicks erreichbar sein, ohne dass der Benutzer tiefe technische Kenntnisse braucht. Masken sollen logisch aufgebaut sein, Fachbegriffe einheitlich und verständlich verwendet werden. Wo möglich, sollen Voreinstellungen und Automatismen den Nutzer unterstützen (z. B. automatische Vorauswahl des aktuellen Datums, sinnvolle Standardfilter). | Anpassbare Oberflächen: Falls verschiedene Nutzer doch unterschiedliche Präferenzen haben, sollte die Software z. B. erlauben, Spaltenanordnungen in Tabellen zu ändern, Felder ein-/auszublenden (per individuellem Profil speichern) oder zwischen Darstellungsmodi zu wählen (Kacheln vs. Liste, Dunkelmodus, etc.). Solche Personalisierungen sind Soll-Anforderungen, die die Zufriedenheit steigern können. |
| Ergonomie: Das Design muss ergonomisch sein, d. h. längeres Arbeiten in der Anwendung soll nicht ermüden oder frustrieren. Dazu gehören ausreichende Performance (s.o.), ein klares visuelles Design (z. B. gute Lesbarkeit durch ausreichenden Kontrast, sinnvoller Einsatz von Farben und Symbolen) und eine durchdachte Navigation. Es soll jederzeit erkennbar sein, wo im System man sich befindet (Breadcrumbnavigation oder Überschriften) und wie man zurück bzw. weiter kommt. | Schulung und Trainings: Der Anbieter sollte Schulungen für die unterschiedlichen Nutzergruppen anbieten. Beispielsweise Key-User-Trainings (für diejenigen, die das System administrieren oder als Multiplikatoren dienen) und Endanwenderschulungen. Wenn Präsenzschulungen nicht praktikabel sind, sollten zumindest eLearning-Module oder Tutorials zur Verfügung gestellt werden. Dieser Punkt ist ein Soll-Kriterium, da er eher in der Einführungsphase relevant ist; dennoch wird die Fähigkeit des Anbieters, hier zu unterstützen, bei der Bewertung berücksichtigt. |
| Fehlertoleranz und Hilfestellung: Die Software muss fehlertolerant sein und den Nutzer bei Fehleingaben unterstützen. Konkrete Anforderungen: aussagekräftige Fehlermeldungen (nicht „Error code 500“, sondern z. B. „Eingabefehler: Datum liegt in der Vergangenheit“), wo möglich Validierung schon während der Eingabe (z. B. Formatprüfungen, Pflichtfelder kennzeichnen). Zudem sollten Eingaben nicht einfach ohne Warnung verworfen werden – der Nutzer sollte Chancen zur Korrektur haben. | Mehrsprachigkeit: (Bereits erwähnt, hier der Vollständigkeit halber) – sollte die Plattform neben Deutsch auch Englisch und ggf. weitere Sprachen unterstützen, insbesondere wenn im Unternehmen nicht alle Anwender deutschsprachig sind oder Dienstleister Zugriff haben, die international tätig sind. |
| Dokumentation & Online-Hilfe: Für alle Benutzer muss eine verständliche Dokumentation verfügbar sein. Dies kann in Form eines Online-Hilfesystems in der Anwendung selbst sein (Kontext-Hilfe, F1-Funktionalität) und als ausführliches Benutzerhandbuch (PDF/Online). Gerade für seltene Aktionen (z. B. Jahresabschluss-Auswertungen) braucht der Nutzer eventuell eine Anleitung. Die Hilfetexte sollten in deutscher Sprache vorliegen und idealerweise auf die kundenspezifische Konfiguration angepasst werden können. | Feedback-Kultur: Es wäre positiv, wenn die Software Möglichkeiten bietet, Benutzerfeedback aufzunehmen (z. B. „Feedback senden“-Button), oder der Anbieter einen Mechanismus hat, wie er im laufenden Betrieb von Key-Usern Verbesserungswünsche entgegennimmt. Dies ist kein Muss, signalisiert aber Kundennähe und kontinuierliche Verbesserung. |
| Barrierefreiheit: Soweit erforderlich (z. B. für Mitarbeiter mit Handicap, gesetzliche Vorgaben), muss die Anwendung grundlegende Prinzipien der Barrierefreiheit einhalten. Dazu zählen Skalierbarkeit der Schrift, Bedienbarkeit mit der Tastatur, kompatibel mit Screenreader (für blinde Nutzer) in den wichtigsten Bereichen. Auch wenn dies im industriellen Kontext vielleicht weniger gefordert wird, stellt es doch einen Qualitätsaspekt dar – falls die Software z. B. nach BITV/WCAG2.1 teilweise zertifiziert ist, wäre das positiv. |
Wartung und Support (Anforderungen an den Anbieter)
Beschreibung: Neben der Software selbst sind auch Dienstleistungen des Anbieters relevant. Gerade in einem kritischen System für Abrechnung erwartet der Auftraggeber zuverlässigen Support, klare Abmachungen zur Servicequalität und Unterstützung bei der Implementierung. Einige dieser Punkte wurden bereits gestreift (z. B. SLAs in Architektur). Hier werden sie zusammengefasst und ergänzt um Anforderungen, die direkt an den potenziellen Bieter gestellt werden (was dieser im Zuge der Ausschreibung nachweisen oder zusichern sollte).
Anforderungen (Wartung & Anbieterleistungen):
| Muss | Soll |
|---|---|
| Implementierungsunterstützung: Der Anbieter muss in der Lage sein, das System beim Kunden einzuführen, was typischerweise Beratungsleistungen umfasst: Prozessanalyse, ggf. Migrationskonzepte (falls Alt-Daten übernommen werden sollen), Customizing der Lösung auf die spezifischen Bedürfnisse des Bergbaubetriebes, Schulung der Mitarbeiter (siehe oben) und Begleitung des Go-Live (Hypercare-Phase). Ein detaillierter Implementierungsplan (mit Aufwandsschätzung, Zeitplan, Meilensteinen) wird vom Anbieter erwartet. | Weiterentwicklung und Roadmap: Der Anbieter sollte darlegen können, wie er die Lösung fortentwickelt. Eine Produkt-Roadmap für kommende Funktionen oder Verbesserungen wäre wünschenswert, damit der Kunde weiß, wie zukunftssicher die Lösung ist. Gerade Themen wie KI-gestützte Funktionen oder erweiterte Analytics könnten perspektivisch interessant sein. Dies fließt als qualitative Bewertung ein (kein Muss, aber zukunftsorientierte Anbieter punkten hier). |
| Service Level Agreements: Der Anbieter muss klare SLAs für Betrieb und Support anbieten. Dazu zählen mindestens: garantierte Verfügbarkeit der Anwendung (z. B. 99 % Monatsmittel, mit definierten Wartungsfenstern), Reaktionszeiten im Support (z. B. Priorität 1 Störung – Reaktion in 1 Stunde, Lösung innerhalb 8 Stunden) und Update-Zyklen (wie oft werden | Onboarding der Dienstleister: Da auch Fremdfirmen eventuell im System agieren (z. B. Zeiterfassung via Portal), sollte der Anbieter ein Konzept haben, wie diese externen Benutzer verwaltet werden können (Self-Service-Registrierung? Zentrale Pflege durch Admins?) und wie man diese anfangs schult oder unterstützt (z. B. Infomaterial, Hotline). Obwohl Fremdfirmen nicht die Endkunden des Softwareanbieters sind, ist deren Zufriedenheit indirekt relevant für den Erfolg. |
| Support-Struktur: Es muss ein Supportkonzept geben, typischerweise 2nd-Level (Hersteller-Support) und optional 1st-Level (lokal oder durch Partner). Der Ansprechpartner für den Kunden im Fehlerfall muss klar definiert sein (Ticket-System, Hotline). Support in deutscher Sprache wäre von Vorteil (gerade für Endanwenderfragen), ist aber zumindest für 2nd-Level nicht zwingend, sofern Englisch fließend beherrscht wird. | Vertragliches & Hosting-Standort: Wünschenswert ist, dass das Hosting in einem für den Auftraggeber geeigneten Rechtsraum stattfindet (z. B. EU für DSGVO). Falls der Anbieter nicht selbst hostet, sondern auf Hyperscaler (AWS, Azure etc.) setzt, sollen entsprechende Informationen geliefert werden. Zudem sollte der Vertrag Regelungen zu Haftung, Gewährleistung, Exit-Strategie (z. B. Herausgabe der Daten am Ende) enthalten, die marktüblich sind. Diese Punkte werden juristisch geprüft, aber auch inhaltlich bewertet (kein Muss-Kriterium in der Wertung, aber wichtig für Vertragsschluss). |
| Referenzen und Erfahrung: Der Bieter muss nachweisen können, dass er Erfahrung mit vergleichbaren Projekten hat. Referenzprojekte – idealerweise in der Industrie / im Anlagen- oder Bergbauumfeld – sind anzugeben. Dies reduziert das Risiko für den Auftraggeber, da ein Anbieter, der die Domäne kennt (z. B. Anforderungen wie SAP-Integration, spezifische Prozesse) deutlich weniger Einarbeitungszeit benötigt. |
Muss- und Soll-Kriterien (Übersicht)
In der folgenden Tabelle sind alle wichtigen Anforderungen aus obigen Kapiteln nochmals zusammengefasst. Zur besseren Übersicht ist angegeben, ob es sich um ein Muss-Kriterium (erforderlich) oder Soll-Kriterium (wünschenswert) handelt. Diese Klassifizierung hilft in der Angebotsbewertung, die Lösungen der Bieter hinsichtlich Erfüllungsgrad einzuordnen.
Alle Muss-Kriterien müssen erfüllt sein, damit ein Angebot in die engere Wahl kommt; Soll-Kriterien bringen Mehrwert und können z. T. durch höhere Bewertung honoriert werden.
| Anforderungsbereich | Kriterium | Priorität |
|---|---|---|
| Vertrags-/Rechnungsprüfung | Automatischer Abgleich von Rechnungen mit Vertragskonditionen | Muss |
| Erkennung und Alert bei Abweichungen (Preis, Menge, etc.) | Muss | |
| Unterstützung unterschiedlicher Vertragsarten (Werkvertrag, Dienstvertrag, Pauschalen) | Muss | |
| Konfigurierbare Prüfregeln (Toleranzen, Workflow bei Abweichung) | Soll | |
| Protokollierung aller Prüfschritte und Freigaben | Muss | |
| SAP-Integration | Übernahme von Bestelldaten und Verträgen aus SAP S/4HANA | Muss |
| Rückmeldung bestätigter Leistungen/Rechnungen an SAP (FI/CO, MM, PM) | Muss | |
| Echtzeit- bzw. near-real-time Synchronisation mit SAP | Soll | |
| Nutzung standardisierter SAP-Schnittstellen (IDoc/BAPI/OData) | Soll | |
| Leistungserfassung (Echtzeit) | Echtzeit-Übernahme von Gate-Access (Zutritt) und Zeiterfassungsdaten | Muss |
| Automatischer Abgleich gemeldeter Stunden mit Anwesenheitsdauer | Muss | |
| Mobile Erfassung vor Ort (App oder Web) | Soll | |
| Schnittstellen zu IoT/Maschinendaten für Leistungsnachweis | Soll | |
| Live-Übersicht der anwesenden Fremdfirmen im Dashboard | Soll | |
| Benutzeroberfläche & Dashboards | Rollenbasiertes Rechtemodell (Zugriff nach Benutzerrolle) | Muss |
| Intuitive Web-Oberfläche, responsive Design | Muss | |
| Echtzeit-Dashboards mit wichtigsten KPIs | Muss | |
| Konfigurier-/personalisierbare Dashboard-Widgets | Soll | |
| Benachrichtigungssystem (E-Mail/Push bei Ereignissen) | Soll | |
| Mehrsprachige Oberfläche (de/en) | Soll | |
| Performanceanalyse (KPIs) | Erfassung von Dienstleister-Kennzahlen (Termintreue, Qualität, etc.) | Muss |
| Dienstleisterberichte/Scorecards mit KPI-Visualisierung | Muss | |
| Vergleich/Ranking mehrerer Dienstleister (Benchmarking) | Muss | |
| Aggregierte Gesamtbewertung/Rating je Dienstleister | Soll | |
| Trendanalyse über Zeit (Historie der KPIs) | Muss | |
| Automatische Alerts bei Schwellwert-Verletzungen (Performance) | Soll | |
| Analytics & Reporting | Standardberichte (Monatsreports, Vertragsauslastung etc.) | Muss |
| Ad-hoc-Reporting (freies Abfragen, Pivotieren) | Muss | |
| Datenhistorisierung für mehrjährige Auswertungen | Muss | |
| Grundfunktionen für Predictive Analytics (Trend, Forecast) | Muss | |
| Vorgefertigte Prognosemodelle (Kostenforecast, Risikomodell) | Soll | |
| Exportmöglichkeiten (Excel/PDF) und Berichtversand | Muss | |
| Sicherheit | Zertifizierte Cloud-Sicherheit (ISO 27001, SOC2) | Muss |
| Starke Authentifizierung, SSO-Unterstützung | Muss | |
| Verschlüsselung der Daten (TLS, AES256 etc.) | Muss | |
| DSGVO-Konformität (Datenminimierung, Löschkonzept) | Muss | |
| Mandantenfähigkeit (strikte Mandantentrennung) | Muss | |
| Protokollierung sicherheitsrelevanter Ereignisse (Audit-Trail) | Soll | |
| Architektur & Betrieb | Cloud-basierte SaaS-Lösung (vom Anbieter gehostet) | Muss |
| Hohe Verfügbarkeit (>99% Uptime) | Muss | |
| Horizontale/vertikale Skalierbarkeit (mehr Benutzer/Daten) | Muss | |
| Performante Reaktionszeiten (<2s im Mittel) | Muss | |
| Unterstützung moderner Browser (Chrome, Firefox, Safari, Edge) | Muss | |
| Mobile Nutzbarkeit (Browser oder App) | Muss | |
| Regelmäßige Updates/Patches durch Anbieter | Muss | |
| Offline-Fähigkeit für zeitweilige Verbindungsverluste | Soll | |
| Integrationsfähigkeit | Dokumentierte offene API (REST/JSON o. ä.) | Muss |
| Import/Export-Schnittstellen für Stammdaten und Bewegungsdaten | Muss | |
| Anbindung E-Mail/SMTP für Notifications | Muss | |
| AD/LDAP-Integration für Benutzerverwaltung | Soll | |
| Möglichkeit der Data Warehouse/BI-Anbindung (ODBC, API-Zugriff) | Soll | |
| Keine proprietäre Datensperre (Daten jederzeit exportierbar) | Soll | |
| Usability | Konsistente, intuitive UI (geringe Einarbeitung nötig) | Muss |
| Kontext-sensitive Hilfe, Dokumentation (deutsch) | Muss | |
| Fehler-Handling mit klaren Meldungen | Muss | |
| Anpassbare Listen/Masken (z. B. Spaltenwahl) | Soll | |
| Barrierefreiheit Grundfunktionen (Screenreader/Tastatur) | Soll | |
| Schulungsmaterial / Trainingsangebote | Soll | |
| Support & Wartung (Anbieter) | Implementierungsunterstützung (Setup, Customizing, Schulung) | Muss |
| Betriebs-SLA (Verfügbarkeit, Reaktionszeiten) | Muss | |
| Support-Hotline/Ticket deutsch oder englisch, zügige Reaktion | Muss | |
| Regelmäßige Produktweiterentwicklung (Roadmap) | Soll | |
| Nachweis von Referenzen im vergleichbaren Umfeld | Muss | |
| Hosting in EU (oder konform mit kundenspez. Vorgaben) | Soll |
Kriterien zur Bieterbewertung
Im Vergabeverfahren werden die eingehenden Angebote anhand der Erfüllung der obigen Anforderungen und weiterer Kriterien bewertet. Dabei gelten alle Muss-Kriterien als Ausschlusskriterien – ein Anbieter, der auch nur ein Muss-Kriterium nicht erfüllt, kann nicht berücksichtigt werden. So wird sichergestellt, dass nur Lösungen in die engere Wahl kommen, die den Kernanforderungen genügen.
Die endgültige Bieterbewertung erfolgt anschließend multi-kriteriell. Um dies transparent zu gestalten, sind folgende Bewertungsdimensionen vorgesehen (mit einer beispielhaften Gewichtung in Prozent):
Funktionale Leistungsfähigkeit (40 %) : Wie gut erfüllt das Angebot die funktionalen Anforderungen? Werden darüber hinaus sinnvolle Zusatzfunktionen (Soll-Kriterien) angeboten? Hier fließt z. B. ein, in welchem Umfang die Soll-Kriterien abgedeckt sind, wie durchdacht die Workflow-Umsetzung ist, und wie flexibel das System an die Prozesse angepasst werden kann. Die Bedienbarkeit für Endanwender ist ebenfalls Teil dieser Kategorie.
Technische Architektur & Integrationskonzept (20 %) : Bewertung der nicht-funktionalen Qualität: Sicherheit, Skalierbarkeit, Architekturansatz, Schnittstellen. Auch Aspekte wie Mandantenfähigkeit, Performance-Konzept und Cloud-Betriebsmodell werden hier beurteilt. Ein zukunftsfähiger, offener Architekturentwurf mit überzeugendem Sicherheitskonzept erhält eine hohe Wertung.
Wirtschaftlichkeit (20 %) : Gesamtkostenbetrachtung des Angebots (Total Cost of Ownership über z. B. 5 Jahre). Hier werden Lizenzkosten/Subscription-Gebühren, Implementierungskosten, Schulungskosten und laufende Betriebskosten berücksichtigt. Günstigere Angebote erhalten in dieser Kategorie mehr Punkte, wobei ein reiner Preisvergleich nur zwischen technisch/funktional als geeignet bewerteten Lösungen erfolgt.
Implementierung & Support (10 %) : Qualität des Einführungs- und Betreuungskonzepts. Dazu zählen der vorgeschlagene Projektplan, Ressourcen des Anbieters, das Schulungskonzept, sowie die Supportorganisation (Reaktionszeiten, Support-Portal, Sprachunterstützung, Referenzen für Supportqualität). Ein Anbieter, der z. B. einen lokalen Partner für schnellen Vor-Ort-Support anbieten kann, wird positiv bewertet.
Anbieterqualifikation (10 %) : Erfahrung des Anbieters und langfristige Perspektive. Referenzprojekte, spezifisches Branchen-Know-how (Bergbau/Industrie), Größe und Stabilität des Unternehmens, Innovationskraft (Roadmap) und ggf. bestehende Partnerschaften (z. B. SAP-Zertifizierung) werden hier einbezogen. Der Auftraggeber möchte sicherstellen, dass der gewählte Partner über die erforderliche Kompetenz und Zuverlässigkeit verfügt, das Projekt erfolgreich umzusetzen und das System langfristig zu betreuen.
Bewertungsmatrix für Angebote (Kriterien und Gewichtung)
| Bewertungskriterium | Gewichtung | Bemerkungen |
|---|---|---|
| Erfüllung funktionale Anforderungen (Muss & Soll) | 40 % | Funktionsabdeckung, Usability, Zusatznutzen |
| Technische Lösung (Architektur, Sicherheit, Integration) | 20 % | Cloud-Konzept, Skalierbarkeit, Schnittstellen |
| Wirtschaftlichkeit (Preis & Folgekosten) | 20 % | Lizenz-/Abo-Kosten, Betriebs- und Implementierungskosten |
| Implementierungskonzept & Support | 10 % | Einführungsstrategie, Schulung, SLAs, Supportstruktur |
| Anbieterkompetenz und Referenzen | 10 % | Erfahrung, Branchen-Referenzen, Zukunftssicherheit |
| Gesamt | 100 % |
Die Bieter werden gebeten, ihr Angebot entsprechend dieser Kriterien aufzubereiten. Insbesondere sollte deutlich hervorgehen, in welcher Form jede Anforderung erfüllt wird (Muss: voll erfüllt oder nicht, Soll: erfüllt oder nicht, ggf. mit Beschreibung). Zudem sind für die bewertungsrelevanten Kriterien Nachweise bzw. Erläuterungen zu liefern: z. B. Architektur-Whitepaper, Sicherheitszertifikate, Demo-Zugang zur Usability-Beurteilung, Referenzberichte anderer Kunden, sowie eine transparente Kostenaufstellung.
Zusammenfassung
Dieses Lastenheft beschreibt eine umfassende, technologieoffene Anforderungsliste für die Einführung einer digitalen Plattform zum Management und zur Abrechnung von Fremdfirmenleistungen in einem Bergbauunternehmen. Die Lösung soll aktuelle manuelle Prozesse ablösen und durch Automatisierung, Integration und Echtzeit-Datenverfügbarkeit erhebliche Verbesserungen in Effizienz, Transparenz und Steuerungsmöglichkeit erzielen. Durch die strukturierte Gliederung in funktionale und nicht-funktionale Anforderungen sowie die Kennzeichnung von Muss- und Soll-Kriterien bietet das Dokument eine klare Grundlage für potenzielle Anbieter, um passende Lösungen vorzuschlagen.
Die Schwerpunkte liegen auf: automatisierter Rechnungsprüfung gegen Verträge, tiefer SAP S/4HANA-Integration, Echtzeit-Erfassung von Leistungsdaten (z. B. über Gate-Access, Zeiterfassung), einer rollenbasierten Benutzeroberfläche mit Dashboards, der Etablierung eines Kennzahlensystems zur Performanceanalyse von Dienstleistern, sowie auf modernen Analytics-Fähigkeiten (einschließlich prädiktiver Auswertungen). Nicht-funktional wurden hohe Anforderungen an IT-Sicherheit, Cloud-Betrieb, Skalierbarkeit und Benutzerfreundlichkeit formuliert, um sicherzustellen, dass die eingeführte Plattform den industriellen Einsatzbedingungen und Compliance-Vorgaben gerecht wird.
Mit diesem Lastenheft wird ein formal belastbares Dokument vorgelegt, das als Grundlage für die Ausschreibung und Anbieterbewertung dient. Es soll sicherstellen, dass die ausgewählte Lösung produktneutral und anbieterunabhängig aufgrund objektiver Kriterien gewählt wird, und dass sie die genannten Ziele des Unternehmens vollumfänglich unterstützt. Die ausführliche Darstellung und hohe Qualitätsanforderung (inhaltlich wie sprachlich) soll allen Stakeholdern – von Fachexperten über IT bis hin zum Management – ein gemeinsames Verständnis des Projektumfangs vermitteln. In der nächsten Phase (Pflichtenheft durch den gewählten Anbieter) werden die hier definierten Was-Anforderungen in ein konkretes Wie-Konzept umgesetzt. Zunächst jedoch bildet dieses Lastenheft den Maßstab, an dem sich alle Angebote messen lassen müssen, um die bestmögliche Lösung für die industrielle Fremdfirmensteuerung zu realisieren.