A11_Fachkonzept_dezentrale_Beschaffung_V1.0_final__002_.pdf

[Seite 1]

Fachkonzept zur Einführung einer Softwarelösung für

die dezentrale Beschaffungen (SRM-Ablösung)

Verfasser: Projektteam

Datum: 25.09.2026

Version: Version 1.0

[Seite 2]

Inhalt

Abkürzungsverzeichnis ................................................................................................................................................ 3

Abbildungsverzeichnis ................................................................................................................................................. 3

1. Ausgangssituation und Ziele ............................................................................................................................... 4

2. Einordnung der Beschaffung an der TUD ......................................................................................................... 5

2.1. Zuständigkeiten ........................................................................................................................................... 6

2.2. Wertgrenzen ................................................................................................................................................. 7

2.3. Warengruppen ............................................................................................................................................. 7

2.4. Kontierung .................................................................................................................................................... 8

3. Relevante Prozesse ............................................................................................................................................... 9

3.1. Rollen ........................................................................................................................................................... 10

3.2. Bestellarten ................................................................................................................................................. 11

3.3. Benutzerbezogene Einstellungen ........................................................................................................... 12

4. Funktionale Anforderungen .............................................................................................................................. 13

4.1. Benutzerspezifische Anforderungen ...................................................................................................... 13

4.2. Prozessschrittübergreifende Anforderungen ....................................................................................... 13

4.3. Anforderungen an das Anlegen von Einkaufswagen ........................................................................... 15

4.3.1. Spezifische Anforderungen der Warengruppe Wissenschaftl. (Groß-)Geräte, Messtechnik und Laborbedarf ................................................................................................................................................. 17

4.3.2. Spezifische Anforderungen der Warengruppe Software ............................................................ 18

4.3.3. Spezifische Anforderungen der Warengruppe Tagung, Veranstaltung und Bewirtung ........ 18

4.4. Anforderungen an die Genehmigerfindung ......................................................................................... 18

4.5. Anforderungen an die Genehmigung von Einkaufswagen ................................................................. 19

4.6. Anforderungen an die Bearbeitung der Bestellung ............................................................................. 20

4.7. Anforderungen an das Löschen und Stornieren von Einkaufswagen ............................................... 20

4.8. Anforderungen an die Bearbeitung des Wareneingangs ................................................................... 20

4.9. Anforderung aus der Exportkontrolle .................................................................................................... 21

4.10. Anforderungen an Berichte und Reports .............................................................................................. 22

4.11. Anforderungen an Dokumente ............................................................................................................... 22

5. Schnittstellen ....................................................................................................................................................... 22

6. Customizing und Administration ..................................................................................................................... 23

7. Umsetzungsberatung und Migration .............................................................................................................. 24

[Seite 3]

Abkürzungsverzeichnis

BANF Bestellanforderung

D1 Dezernat 1 – Finanzen und Beschaffung

SAP-MM SAP Modul Materials Management

SAP-SRM (oder SRM) SAP Supplier Relationship Management

SG 1.2 Sachgebiet 1.2 – Zentrale Beschaffung und Anlagenbuchhaltung

TUD Technische Universität Dresden

Abbildungsverzeichnis

Abbildung 1: Übersicht der Produktgruppen .......................................................................................................... 8 Abbildung 2: Grobprozess „Waren und Dienstleistungen beschaffen“ ............................................................... 9 Abbildung 3: IT-unterstützte Prozessschritte im Self-Service-Beschaffungsprozess ....................................... 10

[Seite 4]

1. Ausgangssituation und Ziele

Die Technische Universität Dresden (TUD) setzt für die dezentrale Beschaffung als Self-Service- Beschaffungsprozess seit vielen Jahren SAP Supplier Relationship Management (kurz SAP-SRM) ein.

SAP-SRM wird genutzt, um Bestellungen eigenverantwortlich in den Struktureinheiten erfassen bzw. Bedarfe an die Zentrale Beschaffung melden zu können. Der Self-Service-Beschaffungsprozess wird mit Anlegen eines Einkaufswagens und Erfassung der Positionen durch eine Auswahl aus angebundenen externen Katalogen, Freitextbestellungen, Kopieren früherer Anforderungen aus Freitextbestellungen und internen Lagern initiiert. Darauf folgt ein Genehmigungsworkflow. Genehmigte Einkaufswagen werden anschließend in das SAP-Modul Materialwirtschaft (kurz: SAP-MM) übertragen und dort weiterverarbeitet. DerWareneingang wird im SAP-SRM erfasst, und zentral in SAP MM verbucht. Rechnungen werden außerhalb des SRM verarbeitet. Der Bezug eines Einkaufswagens zu dazugehörigen Rechnungsbelegen im SAP-Modul FI wird im SAP-SRM dargestellt. Das Einholen von Angeboten wird bisher dezentral nicht digital unterstützt. Das Berichtswesen konzentriert sich auf die Finanz- /Controllingperspektive mit SAP-Standardberichten des Controllings und kundenspezifischen Report- Painter/Writer Berichten.

Aktuell wird SAP ERP 6.0, Enhancement Package 8 mit den Modulen FI, FI-AA, CO, MM, SRM, HCM, PS, PM und RE-FX eingesetzt. Das Fiori-Launchpad wird für Self-Service-Prozesse (z.B. Abwesenheitsmanagement, Ausgangsrechnungen) verwendet. Die zugrundeliegende SAP-Datenbank ist MaxDB. Dokumente werden mittels SAP Archivelink im Dokumentenmanagementsystem d.velop documents abgelegt. Das SAP-System der TUD besteht aus den Systemen E01 (Entwicklung), Q01 (Qualitätssicherung) und P01 (Produktiv) jeweils mit dem Mandanten 100. Darüber hinaus gibt es weitere Mandanten zum Testen sowie für die Qualifizierung der Mitarbeiter im System Q01.

Für die Aktualisierung der SAP-Systemlandschaft soll SAP S/4 HANA als Kernsystem weiter genutzt werden, wobei das SAP Fiori Launchpad für alle SAP-basierten Self-Service-Prozesse der zentrale Einstiegspunkt an der TUD ist. Die SAP-Systemlandschaft soll auch zukünftig on-premise) betrieben werden. In einzelnen Funktionen werden bei Bedarf auch Cloud-Lösungen angebunden. Für das bestehende SAP ERP-System wird eine Migration nach S/4 HANA mit Konvertierung des gesamten SAP- Systems inkl. HCM geplant.

SRM wurde durch SAP zum 31.12.2027 abgekündigt und entspricht vor allem hinsichtlich der Benutzeroberflächen nicht mehr modernen Standards.

Für SAP-SRM wird daher nach einem Ersatz gesucht. Die bisherigen mit der Beschaffung zusammenhängenden Geschäftsprozesse sollen in ihrer Struktur und Verankerung im SAP-System beibehalten werden. Daher soll die neue Softwarelösung für die Vorerfassung und Genehmigung von Beschaffungen über ein Add-On im SAP-System implementiert werden. Für den Bestellprozess soll wie bisher das SAP-Modul MM genutzt werden.

Von der neuen Softwarelösung wird eine vollumfängliche Prozessunterstützung für die dezentrale Bestellabwicklung von der Beschaffungsinitiierung über den Freigabeworkflow bis zur Anbindung an SAP-MM erwartet. Eventuell erforderliche Anpassungen der Einstellungen im SAP-System sollen im Einführungsprojekt mit vorgenommen werden (z.B. Nachrichtenausgabe mit PDF-Druck sowie dem E- Mail- und EDI-Versand (IDOCs)). Die neue Softwarelösung muss unter SAP ECC 6.0 eingeführt werden und nur mit geringen Umstellungsaufwand auch mit S/4 HANA genutzt werden können. Die Self-Service- Funktionalitäten der neuen Software müssen in das TUD-FIORI Launchpad integrierbar sein.

Die Authentifizierung im SAP Fiori Launchpad erfolgt über die TUD-interne Installation von Shibboleth mit Daten aus der zentralen Benutzerverwaltung (IDM). Die SAP GUI ist hauptsächlich für Poweruser im Einsatz, der Zugriff auf die dezentrale Beschaffungslösung erfolgt über den Browser.

[Seite 5]

In diesem Fachkonzept werden nicht die Gesamtprozesse betrachtet, sondern nur die in SRM abgebildeten Prozessteile bzw. die für eine Ablösung und Ergänzung relevanten Inhalte.

2. Einordnung der Beschaffung an der TUD

Zur Einordnung werden die fachlichen Grundlagen der Beschaffung an der TU Dresden im Ist-Zustand beschrieben, welche grundsätzlich mit der neuen Softwarelösung gewährleistet bleiben müssen (Soll- Zustand). Dazu wird zum besseren Verständnis auch der Ist-Zustand der technischen Umsetzung beschreiben. Es wird jeweils bewertet, welcher Teil der beschriebenen Grundlagen in der neuen Softwarelösung weiter zu erreichen ist („SOLL“ auf einer groben Ebene). In den nachfolgenden Kapiteln zu den Anforderungen wird dies dann im Detail weiter ausgeführt.

Beschaffung an der TUD meint den Erwerb von Waren und Dienstleistungen, die die TUD für Forschung, Lehre und Verwaltung benötigt, einschließlich der Ermittlung des Bedarfs, der Auswahl und Durchführung des Vergabeverfahrens, der Auswahl von Lieferanten, der Bestellung, der Warenannahme und der Lagerung. Das Hauptziel ist die bedarfsgerechte Bereitstellung der erforderlichen Güter in der definierten Qualität und Menge, zum richtigen Zeitpunkt und am vorgesehenen Ort, unter Minimierung der entstehenden Kosten. Die Beschaffung ist durch eine umfassende Beschaffungsrichtlinie geregelt, welche die Einhaltung des Vergaberechts, interner Vorgaben sowie die Berücksichtigung von Umwelt- und Nachhaltigkeitsaspekten sicherstellt.

Folgende Grundsätze sind zu berücksichtigen: • Beschaffungen müssen nach geltendem Vergaberecht erfolgen (Vergaben haben grundsätzlich im Wettbewerb zu erfolgen). • Ein 4-Augen-Prinzip ist sicherzustellen (ein:e Einkäufer:in und mindestens ein:e andere:r Genehmiger:in). • Grundsätze der Wirtschaftlichkeit & Sparsamkeit sind einzuhalten. • Umwelt- und Nachhaltigkeitskriterien sind zu berücksichtigen (z.B. „Blauer Engel“, FSC/PEFC, TCO- Siegel). • Vor der Beschaffung ist zu prüfen, ob der Bedarf durch interne Ressourcen (z. B. vorhandene Infrastruktur oder Zwischenlager) gedeckt werden kann und ob die Folgekosten in einem angemessenen Verhältnis zum Nutzen stehen und gedeckt sind. • Sofern erforderlich, ist vor der Beschaffung zu prüfen, ob Energieversorgung und Entsorgung gesichert sind, Transportwege (Türöffnungen) und Standort (Deckentragfähigkeit) ausreichend dimensioniert sind, Bau- und Installationsarbeiten nicht erforderlich sind, die Bereitstellung von Anschlüssen in der Telekommunikationsanlage nicht erforderlich ist, die Schaffung zusätzlicher Anschlüsse an das Campusnetz nicht erforderlich ist sowie zu belegen, dass wegen gegebener Zuständigkeit Betriebstechnik, Staatsbetrieb Sächsisches Immobilien- und Baumanagement, Arbeitssicherheit, Strahlenschutz oder Gesundheitsdienst kontaktiert wurden. • Nicht gestattet ist die Nutzung von Portalen, wie z.B. „Kleinanzeigen“ oder „Marketplace“, das Einkaufen mit Kundenkarten, Bonuskarten, ShoppingCards o.Ä. auf Namen und Rechnung der TUD, die private Bestellung im Namen der TUD.

Diese Definitionen, Ziele und Grundsätze haben weiter Bestand und müssen auch mit der neuen Lösung für die dezentrale Beschaffung grundsätzlich möglichst effizient unterstützt werden.

Die Beschaffung an der TUD ist dezentral organisiert, was bedeutet, dass Struktureinheiten Beschaffungen bis zu einem Auftragswert von 5.000,00 EUR netto eigenverantwortlich durchführen können, aber nicht zwingend müssen. Ab einem Auftragswert von 5.000,00 EUR netto ist die zentrale

[Seite 6]

Beschaffung im Sachgebiet 1.2 - Zentrale Beschaffung und Anlagenbuchhaltung zuständig. In diesem Fall ist ein elektronischer Beschaffungsantrag an die zentrale Beschaffung zu richten. Ziel der dezentralen Beschaffung ist es, den Prozess effizient, flexibel und rechtskonform zu gestalten, indem kleinere Beschaffungen direkt von den Struktureinheiten verantwortet werden. Dies soll zeitliche Verzögerungen minimieren, die Eigenverantwortung stärken und den Verwaltungsaufwand reduzieren. Alle Beschaffungen werden obligatorisch über SAP-SRM abgewickelt, mit Ausnahme folgender Sachverhalte: • Baumaßnahmen und gebäudetechnische Anlagen • Chemikalien (erfolgt über die Softwarelösung GoeChem) • Dienstreisen (Fahrt- und Übernachtungskosten) • Personaleinstellungen • Gebühren (z.B. GEZ, IHK, Patentgebühren) • Leihe • Mietverträge (ohne Immobilien) • Erstattung von Auslagen durch Beschäftigte

Darüber hinaus gelten für einige Produktkategorien/Warengruppen weitere besondere Regelungen, welche zu berücksichtigen sind.

Die Aufbau- (Einteilung in dezentrale („self-service“) und zentrale Beschaffung) und Ablauforganisation (4- Augen-Prinzip, Prüfvorgänge, Steuerung des Beschaffungsprozesses zwischen Organisationseinheiten über Wertgrenzen und anhand von Inhalten über das Kriterium Warengruppe) sollen grundsätzlich weiter beibehalten werden.

2.1. Zuständigkeiten

Für die Gestaltung und Durchführung der Beschaffungsprozesse als Ganzes an der TUD ist das Sachgebiet 1.2 – Zentrale Beschaffung und Anlagenbuchhaltung verantwortlich. Die Zuständigkeit für die operative Durchführung der Beschaffungen liegt dabei nicht allein im Sachgebiet 1.2:

Beratung zu und Bestellungen von Waren und Dienstleistungen werden durch die zentralen Beschaffer:innen des SG 1.2 vorgenommen. Dies betrifft insbesondere Bestellungen ab einer Wertgrenze (derzeit ab einem Auftragswert von 5.000,01 EUR netto), den Abschluss von Rahmenverträgen und langfristigen Verträgen sowie gesondert geregelte Produktgruppen (z. B. Möbel, Wartungs- bzw. Serviceverträge oder Miet- und Leasingverträge).

Darüber hinaus gibt es in den dezentralen Struktureinheiten geschulte Bevollmächtigte (quasi zentrale Besteller:innen über SAP-MM), welche eigenverantwortlich Bestellungen bis zu dieser Wertgrenze (Ausnahme: Möbel, Wartungs- bzw. Serviceverträge oder Miet- und Leasingverträge) im Rahmen der verfügbaren Mittel, unter Beachtung der Beschaffungsrichtlinie und der Voraussetzung eines in SAP angelegten Lieferanten/Geschäftspartners, vornehmen können.

Für folgende Produktkategorie/Warengruppen gibt es abweichende Verantwortlichkeiten: • Baumaßnahmen und gebäudetechnische Anlagen: Dezernat Gebäudemanagement • Kraftfahrzeuge: Gebäudemanagement, SG Infrastrukturelles Gebäudemanagement, Gruppe Transport und Verkehr • Literatur: Sächsische Landes- und Universitätsbibliothek (SLUB) in eigenem IT-System und Verwaltungsbücherei • Chemikalien: Zentrale Chemikalienausgabe (ZCA)

Die beschriebenen Zuständigkeiten müssen auch in der neuen Softwarelösung abbildbar sein.

[Seite 7]

2.2. Wertgrenzen

Gemäß der Beschaffungsrichtlinie der TUD sind folgende Vergabearten je nach Auftragswert entsprechend den aktuellen Rechtsgrundlagen möglich: • Direktkäufe ohne Vergleichsangebote bis zu einem Auftragswert von 500,00 EUR netto • Freihändige Vergabe mit mindestens drei Vergleichsangeboten bei einem Auftragswert von 500,01 bis 25.0000 EUR netto • Nationale Ausschreibung bei einem Auftragswert von 25.000,01 EUR bis 215.999,99 EUR netto • Europaweite Ausschreibung ab einem Auftragswert von 216.000,00 EUR

Für die Beschaffung von Waren und Dienstleistungen sind folgende Wertgrenzen zu berücksichtigen: • bis zu einem Auftragswert von 5.000,00 EUR netto können Bestellungen durch die Struktureinheiten in eigener Verantwortung erfolgen (dezentrale Beschaffung), d.h. mit Genehmigung eines Einkaufswagens wird im SAP-MM eine Bestellung erstellt und an den Lieferanten verschickt • ab einem Auftragswert von 2.000,00 EUR netto erfolgt eine zusätzliche Genehmigung des Einkaufswagens durch die Haushalts- und Drittmittelverwaltung ab einem • ab einem Auftragswert von 5.000,01 EUR netto erfolgen Bestellungen durch die zentrale Beschaffung (Sachgebiet 1.2 - Zentrale Beschaffung und Anlagenbuchhaltung), d.h. mit Genehmigung eines Einkaufswagens wird eine Bestellanforderung (BANF) im SAP-MM zur weiteren Bearbeitung erstellt • Bestellpositionen mit Anlagenbezug sind ab einem Anschaffungswert von 150 EUR netto, sowie zur Anlage zugehörige Bestellpositionen (z.B. Notebook-Komponenten) auch unter einem Wert von 150 EUR netto, durch die Anlagenbuchhaltung in SAP-MM freizugeben und zu inventarisieren

Die genannten Wertgrenzen und davon abhängige, beschriebene Bearbeitungszuständigkeiten (dezentral/zentral) sind auch mit der neuen Softwarelösung zu unterstützen.

bisherige technische Umsetzung: • zusätzliche Genehmigung des Einkaufswagens: zweistufiger Genehmigungsworkflow • Trennung in Bestellung/BANF: programmierte Regel bei der Übergabe der Einkaufswagen an SAP- MM • Inventarisierung: Freigabestrategie im Modul MM abhängig vom Kontierungstyp. Der Kontierungstyp wird anhand der Produktkategorie/Warengruppe ermittelt.

2.3. Warengruppen

Die Begriffe „Produktkategorie“ und „Warengruppe“ werden synonym verwendet.

Der Erwerb von Waren und Dienstleistungen wird anhand von Warengruppen klassifiziert. Derzeit gibt es an der TUD 172 verschiedene Warengruppen, welche fachlich in folgende Warencluster zusammengefasst werden:

[Seite 8]

Abbildung 1: Übersicht der Produktgruppen

Die Warengruppen sind so strukturiert, dass sie entweder nur für Verbrauchskontierung oder Anlagenkontierungen genutzt werden können, nicht für beides. Dadurch sind für die meisten „Artikelgruppen“ zwei fast gleichlautende Warengruppen (eine für Artikel unter und eine für Artikel über 150,- € Wert) vorhanden.

Abweichend vom Wert einer Einzelposition muss dann eine „Anlagen“-relevante oder ggf. sachfremde Warengruppe verwendet werden, wenn es sich um eine Ergänzung zu einer Anlage handelt. In diesen Fällen wird die Warengruppe des Hauptartikels verwendet, obwohl der Einzelartikel ggf. unter 150,- € kostet oder sachlich eigenständig einer anderen Warengruppe angehört.

bisherige technische Nutzung:

Zu jeder Warengruppe ist in einer kundeneigenen Mapping-Tabelle je möglichem Kontierungstyp das jeweils entsprechende Sachkonto hinterlegt. Die Anwender:innen pflegen im Beschaffungsvorgang positionsweise nur die Produktkategorie/Warengruppe und können das Sachkonto nicht direkt beeinflussen.

Über die kundeneigene Mapping-Tabelle wird gesteuert, ob zu einer Warengruppe eine Anlagenkontierung erforderlich ist.

Die Warengruppen werden außerdem zur organisatorischen Steuerung genutzt (siehe oben): Über kundeneigene Regeln werden Folgebelege bei einzelnen Warengruppen spezifischen Einkäufergruppen sowie Freigabestrategien im SAP-MM zugeordnet (z.B. bei Fahrzeugen, Software und Chemikalien) und bei einzelnen Warengruppen BANFEN unabhängig von der Wertgrenze erzeugt.

Beim Anlegen eines Einkaufswagens muss für jede Position eine Warengruppe ausgewählt werden.

Bei Übernahme von Belegpositionen aus über Punch-Out angebundenen Webshops werden Produktkategorien/Warengruppen auf Basis eines kundeneigenen Mappings basierend auf dem Referenzstandard eClass Version 5.0 vorgeschlagen. Wenn der angebundene Webshop für einen Artikel oder grundsätzlich keine eClass-Werte zu den Positionen liefern kann, wird eine Dummy- Produktkategorie/Warengruppe ergänzt, die ein manuelles Ändern durch die Anwender:innen erzwingt.

Die vorhandenen Warengruppen und ihre Struktur müssen auch mit der neuen Softwarelösung weitergenutzt werden. Warengruppenvorschläge auf Basis des kundeneigenen Mappings für über Webshops importierte eClass-Werte zu Einkaufswagenpositionen müssen weiter vorhanden sein. Eine manuelle und automatische abweichende Zuordnung von Warengruppen muss weiter möglich bleiben (siehe auch unten Abschnitt „Rahmenvertrag“). Sachkonten müssen weiterhin auf Basis der ausgewählten Warengruppen automatisch zugeordnet werden. Die vorhandenen kundeneigenen Tabellen können dafür nachgenutzt werden.

2.4. Kontierung

Die Begriffe „Finanzierungselement“ und „Kontierungselement“ werden synonym verwendet.

[Seite 9]

An der TUD wird auf Kostenstellen, PSP-Elemente, Aufträge und Anlagen kontiert. Es wird aktuell ein Buchungskreis (=1000) verwendet. Die Kontierungselemente (Kostenstellen, PSP-Elemente sowie deren Kombinationen mit Anlagen, Aufträgen und statistischen Innenaufträgen), die ausgewählt werden können, werden aus SAP-Standardtabellen abgerufen.

Auf Basis der ausgewählten finanzierungsrelevanten Kontierungselemente Kostenstelle und PSP-Element werden im Workflow die Genehmiger:innen zugeordnet. Das Regelwerk unterscheidet sich zwischen der

1. und 2. Workflowstufe.

bisherige technische Umsetzung der Genehmigerfindung:

Erste Genehmigungsstufe (dezentral): Die Zuständigkeiten für die Genehmigung werden je Finanzierungselement (Kostenstelle, PSP) über die sogenannte „Digitale Unterschriftenkarte“ in SAP hinterlegt. Die Bearbeiterfindung im Workflow ermittelt die Bearbeiter über zugehörige kundeneigene Tabellen. Die Vertretungsfunktion des SAP-Standardworkflows wird nicht genutzt. Jede Person muss eigenständig bei ihren Kontierungselementen hinterlegt werden.

Zweite Genehmigungsstufe (zentral): Die Zuständigkeit für die Genehmigung werden je Finanzierungselement in einer weiteren kundeneigenen Tabelle gepflegt. Die Genehmigerfindung der zweiten Stufe nutzt die Vertretungsfunktion des SAP-Standardworkflows. Darüber werden Bearbeitergruppen/-pools abgebildet.

Die vorhandenen Kontierungselemente müssen auch mit der neuen Softwarelösung weitergenutzt werden können. Die Genehmigerfindung muss auch zukünftig zweistufig das kundeneigene Regelwerk verwenden, welches die Aufbau- und Ablauforganisation der Genehmigung abbildet.

3. Relevante Prozesse

Der Prozess zur Beschaffung von Waren und Dienstleistungen lässt sich grob in folgende Abschnitte unterteilen:

Abbildung 2: Grobprozess „Waren und Dienstleistungen beschaffen“

Im Rahmen der dezentralen Beschaffung liegt der Fokus auf den weiß gekennzeichneten Prozessabschnitten, welche mit Self-Service-Funktionalitäten unterstützt werden.

Zu unterscheiden ist entsprechend der Zuständigkeiten in den Self-Service-Beschaffungsprozessen: • Angebote dezentral einholen • Waren und Dienstleistungen dezentral erfassen und zentral automatisiert beschaffen (bis zu einem Auftragswert von 5.000,00 EUR netto) • Bedarf an Waren und Dienstleistungen elektronisch an die Zentrale Beschaffung melden (ab einem Auftragswert von 5.000,01 EUR) sowie hierfür Angebote zentral einholen • Wareneingang (dezentral und zentral) bearbeiten

[Seite 10]

Im SRM werden diese Self-Service-Beschaffungsprozesse bisher in folgenden weiß gekennzeichneten Prozessschritten IT-seitig unterstützt:

Abbildung 3: IT-unterstützte Prozessschritte im Self-Service-Beschaffungsprozess

Im Rahmen der Bedarfsqualifizierung wird der Bedarf identifiziert und geklärt, ob ausreichend finanzielle Mittel für eine Beschaffung vorhanden sind. Darüber hinaus wird geprüft, ob der Bedarf durch vorhandene interne Ressourcen (z. B. Dresden Technologieportal) gedeckt werden kann. Soll eine Beschaffung erfolgen, wird eine erschöpfende Leistungsbeschreibung erstellt, welche eindeutig, vollständig und herstellerneutral ist. Liegen Alleinstellungsmerkmale vor, ist eine Begründung der Vergabeentscheidung erforderlich. Diese Vorarbeiten werden mit SRM an der TUD aktuell nicht unterstützt.

Bei einem Auftragswert ab 500,01 EUR netto sind 3 Vergleichsangebote einzuholen oder das Alleinstellungsmerkmal zu begründen. Über die Vergabeentscheidung ist in Form des Preisspiegels ein entsprechender Vermerk zu erstellen. Die dezentrale Angebotseinholung wird mit SRM an der TUD nicht unterstützt. Zentral werden für Anfragen und Angebots die SAP-Standardtransaktionen ME4* verwendet.

Der Self-Service-Beschaffungsprozess wird von den Dezentralen Beschaffer:innen durch Anlegen eines Einkaufswagens in SRM initiiert und zur Genehmigung abgesendet.

Die Prüfung und Genehmigung des Einkaufswagens erfolgt in SRM durch die zuständigen Personen (4- Augen-Prinzip). Je nach Auftragswert ist ein bis zu zweistufiger Genehmigungsprozess zu durchlaufen.

Bei einem Auftragswert unter 5.000 EUR netto wird die Bestellung danach zentral im SAP-Modul MM erzeugt und an den Lieferanten versendet. Besteht ein Anlagenbezug, erfolgt über eine Freigabestrategie vorab in SAP-MM noch die Pflege des Anlagenstammsatzes und danach die Freigabe der Bestellung durch die Anlagenbuchhaltung.

Bei einem Auftragswert ab 5.000,01 EUR netto oder abhängig von spezifischen Warengruppen wird nach der Genehmigung des Einkaufswagens eine Bestellanforderung (BANF) im SAP-MM zur weiteren Bearbeitung durch die Zentrale Beschaffung erzeugt. Wird in begründeten Fällen der Lieferant im Einkaufswagen nicht eingetragen (z. B. wenn der Lieferant durch die Zentrale Beschaffung ermittelt werden soll), wird unabhängig vom Auftragswert eine Bestellanforderung (BANF) im SAP-MM zur weiteren Bearbeitung durch die Zentrale Beschaffung erzeugt. Wird der Lieferant nicht eingetragen ist zwingend eine Begründung anzugeben. Die Zentrale Beschaffung wandelt die Bestellanforderungen nach Abschluss der jeweils zutreffenden Vergabeverfahrensarten in Bestellungen um und versendet diese.

Im Rahmen des Wareneingangs ist die Lieferung der Ware bzw. Erbringung der Dienstleistung auf Ordnungsmäßigkeit und Übereinstimmung mit der Bestellung zu prüfen und der Erhalt zu dokumentieren. Der Wareneingang wird bei direktem Bezug von Einkaufswagen – Bestellung oder Einkaufswagen – BANF – Bestellung grundsätzlich dezentral erfasst. In Sonderfällen wird der Wareneingang durch die zentrale Beschaffung erfasst.

3.1. Rollen

In den Prozessen sind folgende übergreifende „Business“-Rollen vorhanden. Es ist jeweils vermerkt, wenn es eine entsprechende SAP-seitige Berechtigungsrollen dazu gibt

[Seite 11]

• Dezentrale Beschaffer:in: Person, die Einkaufswagen anlegen, ändern, absenden, löschen bzw. stornieren sowie den Wareneingang zu dezentralen Vorgängen erfassen, ändern, löschen oder stornieren darf (SAP-Berechtigungsrolle für SRM-Beschaffung) • Ansprechpartner:in: Person, die für Rückfragen/Rücksprachen zur Verfügung steht. Entspricht in der Regel dem:der Dezentralen Beschaffer:in, kann aber auch eine andere Person sein (nicht technisch abgebildet) • Genehmiger:in in der ersten Stufe: Person, die als Kostenstellen- und Projektverantwortliche für das Budget verantwortlich sind und damit Einkaufswagen freigegeben dürfen. Diese Personen wurden als solche auf der Digitalen Unterschriftenkarte hinterlegt. (SAP-Berechtigungsrolle für SRM-Genehmigung) • Genehmiger:innen in der zweiten Stufe: Person, die als Verantwortliche der Haushalts- und Drittmittelverwaltung Einkaufswagen freigeben darf. (SAP-Berechtigungsrolle für SRM- Genehmigung) • Zentrale Beschaffer:in: • Controller:in: Person, die für die Planung, Steuerung und Kontrolle von Budgets verantwortlich ist. • Stammdatenpflege: Person, die für die Verwaltung und Pflege von Lieferanten-Stammdaten verantwortlich ist. • Systemadministration: Person, die für die Verwaltung, Administration und Wartung der Softwarelösung zuständig ist.

3.2. Bestellarten

Für die Self-Service-Beschaffungsprozesse stehen verschiedene Bestellarten zur Verfügung, welche über entsprechende Belegarten im SAP-MM gesteuert werden.

Webshopbestellung:

In der jetzigen Softwarelösung stehen über die OCI-Standardschnittstelle angebundene Lieferantenkataloge für die dezentrale und zentrale Beschaffung sowohl im SRM als auch SAP-MM zur Auswahl. Durch den Absprung über das Lieferantenkatalog-Logo wird eine Punchout-Session initiiert und eine automatische Weiterleitung zur Oberfläche des angebundenen Lieferantenkatalogs durchgeführt. Die ausgewählten Artikel werden im Warenkorb des Lieferanten gesammelt und anschließend als Datensatz an die Softwarelösung übergeben. Die Daten werden im Einkaufswagen entsprechend um weitere Daten, wie beispielsweise die Kontierung, ergänzt.

Da es sich hierbei um eine Katalogbestellung handelt und Daten aus dem Lieferantenkatalog ans System geliefert werden, die anwenderseitig nicht verändert werden dürfen, sind die betreffenden Felder für die Bearbeitung in der Oberfläche gesperrt. Die Nutzung von Webshopanbindungen muss auch in der zukünftigen Lösung möglich sein, die entsprechende Feldsteuerung muss grundsätzlich ebenfalls gewährleistet sein. Es müssen TUD-seitig grundsätzlich sowohl Webshops von Einzelanbietern als auch Marktplätze per OCI-Schnittstelle anbindbar sein.

Katalogbestellung:

Aktuell werden im SRM keine internen Kataloge genutzt. Zukünftig soll es möglich sein, lieferantenbezogen Artikelpreislisten in das System zu laden oder dort manuell zu pflegen. Durch einen lieferantenbezogenen Einstieg in den Katalog sollen die Artikel in Einkaufswagen übernommen werden können. Die Daten werden im Einkaufswagen entsprechend um weitere Daten, wie beispielsweise die Kontierung, ergänzt.

[Seite 12]

Da es sich hierbei um eine Katalogbestellung handelt und vereinbarte Daten nicht verändert werden dürfen, sollen die betreffenden Felder für die Bearbeitung in der Oberfläche gesperrt werden. Rahmenvertragsbestellung:

Die Zentrale Beschaffung pflegt in SAP-MM für mit Lieferanten abgeschlossene Rahmenverträge und - vereinbarungen Mengen- und Wertkontrakte. Mit den Rahmenvertragspartnern werden grundsätzlich Punch-Out-Kataloganbindungen vereinbart. Über diese wird der Rahmenvertrag als Bezugsquelle (im Vergleich zu weiteren im Webshop angebotenen Artikeln) bereitgestellt und per OCI bei Auswahl der entsprechenden Artikel zurück an SRM übergeben. Wenn der betreffende Einkaufswagen in eine Bestellung überführt wird, kann diese darüber als Rahmenvertragsabruf ausgewertet werden.

Bestellungen aus Rahmenverträgen sind als Kataloganbindung abgebildet, aber keine eigene Belegart im dezentralen Bestellwesen. In der Oberfläche des SRM wird derzeit visuell unterschieden zwischen ‚Kataloge mit Rahmenvertrag‘ und ‚Lieferantenkataloge‘ ohne Rahmenvertrag. Damit wird verdeutlicht, ob die Notwendigkeit zur Einholung von Angeboten besteht.

bisherige technische Umsetzung:

Für Artikel, die im SAP-MM als Wert- oder Mengenkontraktposition angelegt sind und die eine Warengruppe erhalten sollen, die vom Wert der aus dem Webshop mitgelieferten Produktkategorie/Warengruppe abweicht, wird eine kundeneigene Tabelle gepflegt. Dies ist erforderlich, da viele der aktuellen Rahmenvertragsartikel eine Anlage ergänzen sollen und deshalb abweichend von ihrem Einzelwert die Produktkategorie/Warengruppe des Hauptgegenstands erhalten sollen. Beispiele: PC und Maus/Verpackungspositionen (Trockeneis…).

Der Bezug zu Mengen- und Wertkontrakten im SAP-MM muss auch mit der neuen Softwarelösung möglich sein. Eine abweichende Zuordnung von Warengruppen zu Rahmenvertragsartikeln muss ebenfalls weiter möglich sein. Die vorhandene kundeneigene Tabelle kann dafür nachgenutzt werden.

Freitextbestellung:

Neben der Nutzung von angebundenen Webshops werden Bedarfe über „Freitext“-Positionen erfasst. Der prinzipielle Aufbau des Einkaufswagens von Freitextbestellungen entspricht dem Einkaufswagen für Katalogbestellungen.

Freitextpositionen müssen mit der neuen Softwarelösung weiter erfasst werden können.

Bestellung von Lagermaterial (intern):

Es gibt an der TUD mehrere interne Lager, über die mit der SRM Materialien bezogen werden können. Nach Erfassung und Genehmigung des Einkaufswagens in SRM wird zentral in SAP-MM eine Reservierung für das Material im betreffenden Lager angelegt. Diese wird von der zentralen Lagerverwaltung in SAP-MM weiterbearbeitet. Grundlage hierfür sind die im SAP angelegten Material- und Lagerstammdaten, auf die die dezentrale Softwarelösung zurückgreift.

Lagerabrufe müssen mit der neuen Softwarelösung weiter möglich sein können.

3.3. Benutzerbezogene Einstellungen

Die Anlieferadressen der TUD werden teils sogar spezifisch je Einkaufswagenposition gepflegt oder hängen von dem:r dezentralen Beschaffer:in ab. Es gibt außerdem noch weitere user-bezogene Merkmale/Vorbelegungen.

bisherige technische Umsetzung:

Die Merkmale werden von den Dezentralen Beschaffer:innen im SRM über benutzerspezifische Einstellungen oder am SAP-Benutzerstamm als Benutzerparameter gepflegt. Bestimmte

[Seite 13]

Benutzerparameter werden auch zentral durch die SAP-Basisadministration an den Benutzerstammsätzen hinterlegt.

Die neue Softwarelösung muss weiterhin benutzerabhängige Einstellungen ermöglichen.

4. Funktionale Anforderungen

4.1. Benutzerspezifische Anforderungen

Folgende Funktionalitäten müssen benutzerspezifisch vorhanden sein:

• Als Dezentrale Beschaffer:in möchte ich die Möglichkeit haben, für mich Stellvertreter:innen zu hinterlegen, welche unbegrenzt oder für definierte Zeiträume meine Einkaufswagen bearbeiten und dafür Wareneingänge bestätigen können. Damit sollen Unterbrechungen in der Bearbeitung der Beschaffungsvorgänge verhindert werden. • Als Dezentrale Beschaffer:in möchte ich auswählen können, ob zu den jeweiligen Status der Beschaffungsvorgänge (In Genehmigung, Genehmigt, Bestellung verschickt, Wareneingang ausstehend) Benachrichtigungen per E-Mail an mich verschickt werden, damit ich nicht so oft aktiv in das Bestellsystem schauen muss und dennoch nicht verpassen möchte, wenn ich aktiv werden muss. • Als Stellvertreter:in möchte ich auswählen können, ob zu den jeweiligen Status der Beschaffungsvorgänge (In Genehmigung, Genehmigt, Bestellung verschickt, Wareneingang ausstehend) Benachrichtigungen per E-Mail auch an mich verschickt werden sollen, damit ich nicht so oft aktiv in das Bestellsystem schauen muss, weil ich selten Beschaffungen erfasse und deshalb nicht verpassen möchte, wenn ich aktiv werden muss. • Als Genehmiger:in möchte ich automatisch per E-Mail über vorliegende Vorgänge informiert werden, damit ich nicht täglich aktiv in meine Fiori-Inbox schauen muss. Optional möchte ich die E- Mailbenachrichtigungen für mich abstellen können. • Als Dezentrale Beschaffer:in möchte ich mir Lieferadressen hinterlegen können. Eine davon kann als Standard-Adresse markiert werden, die in jedem meiner neuen Einkaufswagen vorgeblendet wird. Bei der Adresseingabe sollen die eingegebenen Werte auf Plausibilität (z.B. bei Postleitzahl nur Zahlenformat) geprüft werden. Hinweis: Eine Beratung durch die Auftragnehmerin und ggf. Lösung für die Bereitstellung von Informationen darüber, welcher Lieferant welchen Versanddienstleister nutzt und welche Texte/Textlängen dieser auf seinen Adressetiketten ermöglicht (z.B. lieferantenabhängige Infotexte o.ä.) ist erwünscht. • Als Dezentrale Beschaffer:in möchte ich für diverse Felder meine eigenen Vorschlagswerte als Favoriten speichern und vorgeschlagen bekommen. Dazu zählen mindestens Kontierungen und Warengruppen).

4.2. Prozessschrittübergreifende Anforderungen

Folgende Funktionalitäten müssen über alle Prozessschritte hinweg gegeben sein: • Als Anwender:in möchte ich soweit sinnvoll an der TUD vorhandene Apps möglichst auch für den dezentralen Beschaffungsprozess mitnutzen (z.B. Fiori-Inbox), um Systemvielfalt zu reduzieren.

[Seite 14]

• Als Anwender:in (egal in welcher Rolle) möchte ich ein zentrales Dashboard mit einem Live-Status aller Beschaffungsvorgänge einsehen können, unabhängig davon, in welchem Zustand (in Bearbeitung, in Genehmigung, abgeschlossen…) sie sich befinden, damit ich jederzeit einen Überblick über den aktuellen Fortschritt, den Status und mögliche Verzögerungen habe. • Als Anwender:in möchte ich während der Bearbeitungszeit des Vorgangs je Auftrag/Anforderung sehen können, bei wem der Vorgang derzeit zur Genehmigung (möglichst mit Information, ob es sich um eine Vertretung handelt) liegt, um nötigenfalls nachhaken zu können. • Als Anwender:in möchte ich meine Beschaffungsvorgänge schnell finden. Dazu erwarte ich Such- und Recherchefunktionen, die mindestens die Möglichkeit „Volltextsuche“, Suche nach Einkaufswagen/Beschaffungsvorgangsnummer, SAP-Bestellnummer, Lieferant, Finanzierungselement, Status, Warengruppe, Zeitraum der Erstellung/ des Absendens und nach Möglichkeit zentral von der TUD festlegbare Kriterien umfasst. • Als Anwender:in möchte ich meine Beschaffungsvorgänge sowie Listen von Suchergebnissen filtern und sortieren können, um Vorgänge schneller finden zu können. Als Filter- und Sortierkriterien sollen neben dem Status der Beschaffungsvorgänge die o.g. Suchkriterien zur Verfügung stehen. • Als Anwender:in möchte ich im Beschaffungsvorgang sehen, wer für die Bearbeitung des aktuellen Status zuständig ist, damit ich bei Verzögerungen oder Anpassungsbedarfen oder ergänzenden Informationen die betreffende Person kontaktieren kann. • Als Anwender:in möchte ich, dass meine Beschaffungsvorgänge einen Status erhalten, damit ich nachvollziehen kann, wie der aktuelle Stand ist und was noch zu tun ist. Als Status benötige ich mindestens „Gesichert“ (Einkaufswagen wurde angelegt und gespeichert, aber noch nicht zur Genehmigung abgeschickt); „In Genehmigung“ (Einkaufswagen wurde abgeschickt, aber noch nicht vollständig genehmigt); „Genehmigt“ (Einkaufswagen wurde vollständig genehmigt); „Bestellung verschickt“ (Bestellung wurde an Lieferanten versendet); „Abgelehnt“ (Einkaufswagen wurde vollständig abgelehnt). • Als Dezentrale Beschaffer:in möchte ich in meinem Beschaffungsvorgang auch Informationen aus nachgelagerten Prozessschritten sehen können (Belegnummern wie Bestellnummer, Bestellanforderungsnummer, Wareneingangsbelegnummer, Rechnungsbelegnummer; Zustand des jeweiligen Genehmigungsworkflows mit zuständigen Personen), damit ich bei Bedarf die Nummern und Statusangaben für eine eindeutige und damit effiziente Kommunikation mit den betreffenden Kolleg:innen oder dem Support nutzen kann. • Als Dezentrale Beschaffer:in möchte ich auch unabhängig vom Anlegen eines konkreten Einkaufswagens oder dem Erstellen von Angebotsanfragen den Bestand an Lieferanten nach verschiedenen Kriterien durchsuchen können. Dazu gehören Name, Ort…. Das Suchergebnis soll mir als Liste zur Verfügung gestellt werden. Eine Suche mit Fuzzy-Logik ist wünschenswert. • Als Anwender:in möchte ich automatische Benachrichtigungen und Eskalationen bei definierten Verzögerungen (z.B., wenn für eine Bestellung 2 Wochen nach dem geplanten Liefertermin kein Wareneingang gebucht wurde) mit Handlungsvorschlägen erhalten, damit ich rechtzeitig reagieren kann, bevor größere Probleme entstehen. • Als Anwender:in möchte ich perspektivisch möglichst automatisiert E-Mails zum Beschaffungsvorgang in PDF konvertieren und im Dokumentenmanagementsystem ablegen können. • Als Anwender:in möchte ich Dokumente (z.B. Rechnungen) aus dem Dokumentenmanagementsystem einsehen können, um medienbruchfrei auf alle Informationen zu einem Beschaffungsvorgang zugreifen zu können.

[Seite 15]

• Als Anwender:in kann ich bei Bedarf eine Vertragsnummer aus dem SAP-System zuordnen. Das soll auch zukünftig möglich bleiben. • Als Anwender:in möchte ich den Lieferanten jederzeit zu laufenden Beschaffungsvorgängen kontaktieren können, um Rückfragen klären zu können. • Als Anwender:in möchte ich direkt aus der neuen Softwarelösung heraus den technischen und fachlichen TUD-internen Support kontaktieren können, damit ich mir den Medienbruch des Wechsels in ein anderes Kommunikationswerkzeug und damit Arbeitszeit spare.

4.3. Anforderungen an das Anlegen von Einkaufswagen

Folgende Funktionen sollen die dezentralen Beschaffer:innen beim Anlegen von Einkaufswagen unterstützen: • Als Dezentrale Beschaffer:in möchte ich grundsätzlich alle Vorgänge als „Einkaufswagen“ ausgehend vom FIORI Launchpad anlegen können, um für benötigte Waren oder Dienstleistungen eigenverantwortlich bestellen, Lagerware zu reservieren oder den Bedarf an die zentrale Beschaffung melden zu können. Ich erwarte, dass die Finanzierungsprüfung durch eine weitere Person erfolgt und diese meinen Einkaufswagen genehmigt, Rückfragen stellt oder ablehnt. Erst nach erfolgter Genehmigung des Einkaufswagens erfolgt die zentrale automatische Erzeugung von Bestellungen bzw. Lagerreservierungen bzw. die Weiterbearbeitungen als Bestellanforderung (BANF) im SAP-MM durch die Zentrale Beschaffung. • Als Dezentrale:r Beschaffer:in möchte ich externe Warenkörbe im .csv – Format in einen neuen Einkaufwagen importieren können, um Bestellungen in nicht per Punch-Out angebundenen Webshops möglichst aufwandsarm in das SAP-System übertragen zu können. • Als Dezentrale Beschaffer:in möchte ich einen Einkaufswagen speichern können, um meine bereits erfassten Eingaben zu einem späteren Zeitpunkt weiterbearbeiten zu können. • Als Dezentrale Beschaffer:in möchte ich aus gesicherten Einkaufswagen eine Vorlage für neue Bestellungen anlegen und einzelne Positionen aus einem alten Einkaufswagen in einen neuen Einkaufswagen kopieren können, um neue Einkaufswagen schneller zu erstellen. • Als Dezentrale Beschaffer:in möchte ich ausgehend vom Einkaufswagen Anfragen an bis zu drei Lieferanten (z.B. per E-Mail) versenden können, um Angebote einzuholen. • Als Dezentrale Beschaffer:in möchte ich bei der Dokumentation der Vergabeentscheidung unterstützt werden, um den regelungskonform zu beschaffen. Folgende Angaben sind erforderlich: Vergabetatbestand/Begründung, Erklärende:r) • Als Dezentrale Beschaffer:in möchte ich auch abweichende Mehrwertsteuersätze angeben können, um Bestellungen verschiedener Warengruppen und aus dem Ausland abbilden zu können. • Als Dezentrale Beschaffer:in möchte ich Unterstützung bei der Aufteilung von Bestellpositionen, z.B. wie Bezugsnebenkosten zu berücksichtigen, um die korrekte Abwicklung des Bestellvorgangs sicherzustellen. • Als Dezentrale Beschaffer:in möchte ich unterstützende Hinweise zum Anlegen des Einkaufswagens möglichst Lieferantenbezogen erhalten, um die korrekte Abwicklung des Bestellvorgangs sicherzustellen. • Als Dezentrale Beschaffer:in möchte ich weitere Informationen über Mouse-Over oder per Link auf relevante Dokumente (z.B. die TUD-Beschaffungsrichtlinie sowie PDF-Formulare) oder weitere Hilfsmittel und IT-Systeme erhalten können. Formulare möchte ich zur Bearbeitung öffnen, lokal speichern und ausgefüllt auf Positionsebene wieder hochladen können. Das IT-System kann hierzu auch auf außerhalb des Systems bereitgestellte Dokumente und Formulare der TUD zurückgreifen (Intranet, Dokumentenmanagementsystem u.a.).

[Seite 16]

• Als Dezentrale Beschaffer:in möchte ich Rabatte/Abzüge gerne eindeutig im Einkaufswagen pflegen können. Der Rabatt sollte idealerweise automatisch von allen Positionspreisen abgezogen werden. Außerdem möchte ich gerne eine negative Position für einen Rabatt eintragen können, die dann nicht von allen anderen Einzelpositionen abgezogen wird, sondern pauschal vom Einkaufswagenwert. • Als Dezentrale Beschaffer:in möchte ich dem Einkaufswagen Dateianhänge anfügen können, um TUD-intern Angebote oder zusätzliche Informationen für eine Bestellung mitgeben zu können. • Als Dezentrale Beschaffer:in möchte für einen Einkaufswagen Informationen (z.B. Bezeichnung des Einkaufswagens) auf Kopfebene pflegen können. • Als Dezentrale Beschaffer:in möchte ich, dass die Informationen (z.B. Ansprechperson, Bedarfsbegründung, Lieferant, Lieferadresse, Kontierung, Warengruppe) auf Kopfebene für alle Positionen übernommen, auf einmal gepflegt und auf Positionsebene geändert werden können. • Ich möchte erkennen können, welche Informationen an den Lieferanten übermittelt werden oder intern verbleiben. • Als Dezentrale Beschaffer:in möchte ich darüber hinaus folgende Informationen pro Position in einem Einkaufswagen einpflegen oder vorgeschlagene Werte ändern können: Lieferant, Beschreibung, Warengruppe, Artikelnummer Lieferant, Menge; Mengeneinheit, Preis, Preiseinheit, Währung, Buchungskreis, Finanzierungselemente, Kostenverteilung auf Finanzierungsquellen, Lieferantentext, interne Notiz. • Als Dezentrale Beschaffer:in möchte ich Unterstützung bei der Zuordnung der richtigen Warengruppe, um die passende Warengruppe zu finden und meinen Beschaffungsvorgang korrekt zu kontieren. Damit entspricht die Kostenzuordnung den TUD-Regeln, den Genehmiger:innen wird eine schlüssige Projekt- und Haushaltsbewirtschaftung erleichtert. Außerdem werden erst über eine einheitliche Anwendung von Warengruppen für die zentrale Beschaffung und auch das Nachhaltigkeitsmanagement strategische Einkaufsüberlegungen anhand von zentralen Auswertungen zu Warengruppen plausibel. Es ist mindestens eine Warengruppensuche anhand von Suchbegriffen erforderlich, Hilfetexte dazu sind wünschenswert. Anhand von meinen Texteingaben soll eine passende Warengruppe vorgeschlagen werden. Bei Positionen, die aus Webshops übernommen werden, soll direkt eine plausible Warengruppe mitgegeben werden. Deshalb ist ein aktuelles Mapping der TUD – Warengruppen mit dem Klassifizierungssystem des Webshops erforderlich. Hinweis: Im Rahmen des Einführungsprojektes soll mindestens das vorhandene eClass-Mapping auf eine Version höher 10.0, wenn aus Kosten-/Nutzensicht sinnvoll, die aktuelle Version 16.0 erarbeitet werden. Vom Softwareanbieter werden hierzu best-practice Beispiele und Beratung erwartet. Über die Erweiterung des Mappings der Warengruppen auf weitere Klassifizierungssysteme (z.B. UNSPSC) soll mit Hilfe der Beratung im Projekt abhängig von Kosten/Nutzen-Betrachtung entschieden werden. Die Umsetzung erfolgt optional. • Als Dezentrale Beschaffer:in möchte ich, dass die Softwarelösung optional zukünftig die Anbindung eines kundeninternen LLM für den Vorschlag von plausiblen Warengruppen ermöglicht, um in einer Ausbaustufe KI-unterstützte Warengruppenvorschläge anhand einer extrem flexiblen Eingabe von Textbausteinen erstellt werden können. Damit spare ich mir als Dezentrale Beschaffer:in noch mehr Zeit und benötige weniger Vorwissen zu den Begrifflichkeiten. • Auf Basis der Warengruppe der Position werden in Verbindung mit dem Kontierungstyp aktuell automatisch Sachkonten bzw. das Dummy-Sachkonto (bei Anlagenbezug) abgeleitet, welche nicht verändert werden können. Ich möchte auch zukünftig nur die Warengruppe prüfen und ggf. pflegen und nicht das Sachkonto selbst eingeben müssen. Das senkt den Arbeitsaufwand und die

[Seite 17]

Einstiegshürde in der Erfassung der dezentralen Beschaffung Außerdem dient dies Vereinheitlichung des Buchungsverhaltens und damit der Steigerung der Datenqualität bzw. Vergleichbarkeit von Statistiken. • Als Dezentrale Beschaffer:in muss ich Positionen mit mehreren, verschiedenen Finanzierungsquellen versehen können. (Splitfinanzierung). Varianten in der Aufteilung der Finanzierung abhängig vonWerte, Menge und prozentualer Aufteilung müssen möglich sein. Die Auswahl des Kontierungstyps soll auf Basis der Warengruppe (mit oder ohne Anlagenbezug) systemseitig automatisch eingeschränkt werden. Hierzu kann eine bereits bestehende kundeneigene Mappingtabelle nachgenutzt werden. • Als Dezentrale Beschaffer:in möchte ich bei einem Auftragswert ab 50.000 EUR brutto auf die Mitnutzungsprüfung hingewiesen werden und weitere Informationen zur zugrundeliegenden Regelung (Rundschreiben RS D1/0407) erhalten. • Als Dezentrale Beschaffer:in möchte ich bei einem Auftragswert ab 50.000 EUR brutto im Einkaufswagen die außerhalb des Beschaffungssystems erfolgte Mitnutzungsprüfung bestätigen und eine Begründung eingeben können, um den Regelungen konform zu beschaffen. • Als Dezentrale Beschaffer:in möchte ich je nach Warengruppe erforderliche Zusatzangaben als Prüffelder eingeben (z.B. Bestätigung der Mitnutzungsprüfung, Bestätigung der DFG-Förderung bei Forschungsgroßgeräten) sowie ergänzende Unterlagen (z.B. Agenda und Teilnahmeliste bei Bewirtungen) anfügen können, um regelungskonform Waren und Dienstleistungen bestellen können. • Als Dezentrale Beschaffer:in möchte ich angeben können, ob die Beschaffung durch EU-Mittel (Abfrage) finanziert wird und wenn ja, die erforderlichen Angaben (gem. Formular D1.2/40 - Prüfvermerk für die Beurteilung der Binnenmarktrelevanz bei öffentlichen Aufträgen im Unterschwellenbereich im Rahmen der Vorhaben Europäischen Territorialen Zusammenarbeit sowie den Förderrichtlinien des EFRE, JTF, und des ESF Plus zur Stärkung des Europäischen Forschungs- und Bildungsraumes) zur Prüfung der Binnenmarktrelevanz eingeben zu können, um die Informationen zur Binnenmarktrelevanz an die zentrale Beschaffung zu übermitteln. • Als Dezentrale Beschaffer:in möchte ich ausgehend von einem Einkaufswagen nach Lieferanten über eine Suchhilfe suchen. Wünschenswert wäre eine fuzzy-logic unterstützte Suchhilfe. Wenn ein Lieferant nicht gefunden wird, möchte ich die mir vorliegenden Kontaktdaten in eine Eingabemaske eingeben und an die Stammdatenpflege zur Prüfung und Anlage eines neuen Lieferanten übermitteln können. • Als Stammdatenpflege möchte ich die Information erhalten, dass ein Lieferant geprüft und angelegt werden soll, um Bestellungen vornehmen zu können. • Als Dezentrale Beschaffer:in möchte ich, dass erfasste Eingaben im Einkaufswagen auf Vollständigkeit (mind. Kontierung, Preis, Lieferadresse) und Wertgrenzen geprüft werden, um ggf. erforderliche Zusatzangaben abzufordern. • Als Dezentrale Beschaffer:in möchte ich mit Absenden des Einkaufswagens den Genehmigungsworkflow je Bestellposition initiieren, damit automatisch der:die zuständige Genehmiger:in ermittelt wird (zur Genehmigerfindung siehe Kapitel 4.4).

4.3.1. Spezifische Anforderungen der Warengruppe Wissenschaftl. (Groß-)Geräte, Messtechnik und Laborbedarf • Als Dezentrale Beschaffer:in muss ich als Pflichtangaben bestätigen, dass die Voraussetzungen für das Aufstellen der technischen Geräte sichergestellt sind, indem vermerkt wird, ob Ver- und Entsorgung mit Energie gesichert ist, Transportwege (Türöffnungen) und Standort (Deckentragfähigkeit) ausreichend dimensioniert sind, erforderliche Bau- und Installationsarbeiten

[Seite 18]

die Bereitstellung von Anschlüssen in der Telekommunikationsanlage und die Schaffung zusätzlicher Anschlüsse an das Campusnetz geklärt sind. Darüber hinaus möchte ich belegen, dass wegen gegebener Zuständigkeit Betriebstechnik, Staatsbetrieb Sächsisches Immobilien- und Baumanagement, Arbeitssicherheit, Strahlenschutz oder Gesundheitsdienst kontaktiert wurden.

4.3.2. Spezifische Anforderungen der Warengruppe Software • Als Dezentrale Beschaffer:in möchte ich beim Anlegen eines Einkaufswagens mit Auswahl der Warengruppe Software auf das Formular „ANTRAG – Software beschaffen (Eigenankauf)“ hingewiesen werden, um vor der Beschaffung eine Genehmigung einholen zu können. • Als Dezentrale Beschaffer:in möchte ich bei jeder Position mit Auswahl der Warengruppe Software das Formular „ANTRAG – Software beschaffen (Eigenankauf)“ als Dokument dem Einkaufswagen anfügen können, um einen Nachweis für die vorherige Prüfung und Genehmigung zu liefern.

4.3.3. Spezifische Anforderungen der Warengruppe Tagung, Veranstaltung und Bewirtung • Als Dezentrale Beschaffer:in möchte ich weitere Informationen zu den zugrundeliegenden Regelungen (Bewirtungsrichtlinie der TUD, Reisekostenordnung) erhalten, um regelkonform Bedarfe zu erfassen. • Als Dezentrale Beschaffer:in möchte ich zusätzliche Angaben zur Veranstaltung, Begründung des dienstlichen Erfordernisses, (vorläufige) Teilnehmerliste, (vorläufige) Agenda, Gesamtbewirtungskosten pro Teilnehmenden erfassen können, um alle bearbeitungsrelevanten Informationen den zentralen Beschaffer:innen zur Verfügung zu stellen. • Als Dezentrale Beschaffer:in möchte ich bestätigen können, dass ich die Bestimmungen der Bewirtungsrichtlinie und der Reisekostenordnung gelesen habe und diese einhalte, um regelkonform zu arbeiten. • Als Dezentrale Beschaffer:in möchte ich gefragt werden, ob es weitere Beschaffungen zur Bewirtung der Veranstaltung gibt und wenn ja, dann eine Querverbindung herstellen können, um die Gesamtbewirtungskosten pro Teilnehmenden nicht zu übersteigen.

4.4. Anforderungen an die Genehmigerfindung

Die Genehmigenden werden auf Basis der im Einkaufswagen angegebenen Finanzierungselementen (Kostenstellen, PSP-Elemente) ermittelt. Die Zuordnung zwischen Finanzierungselementen und Genehmiger:innen basiert auf einer kundenindividuellen Lösung (Digitale Unterschriftenkarte), bei der die Genehmiger:in auf Basis der in den Positionen des Einkaufswagens hinterlegten Finanzierungselementen gefunden werden. Die Softwarelösung muss diese Daten aus kundenspezifischen SAP-Tabellen ziehen, um die Genehmiger:in zuzuweisen.

Das System muss das Vier-Augen-Prinzip technisch sicherstellen. Dabei müssen die Rollen „Dezentrale Beschaffer:in“ und „Genehmiger:in“ innerhalb desselben Beschaffungsvorgangs zwingend durch unterschiedliche Personen wahrgenommen werden, d.h. eine Person mit Genehmigungsberechtigung darf grundsätzlich selbst Bestellungen erfassen, jedoch keine von ihr selbst angelegten Bestellungen genehmigen. In solchen Fällen muss die Genehmigung durch eine andere berechtigte Person erfolgen. Pro Genehmigungsstufe können mehrere Genehmigende hinterlegt werden (z. B. mehrere Genehmigende für eine Kostenstelle). In diesem Fall ist der Vorgang allen berechtigten Genehmigenden zur Bearbeitung und Benachrichtigung bereitzustellen. Für die Freigabe des Vorgangs genügt jedoch die einmalige Genehmigung durch eine der berechtigten Personen. Sobald eine berechtigte Person den Vorgang genehmigt bzw. bearbeitet hat, gilt der Genehmigungsschritt als abgeschlossen. Für die übrigen Genehmigenden besteht dann kein weiterer Handlungsbedarf mehr.

[Seite 19]

Ab einer konfigurierbaren Wertgrenze müssen die Bearbeiter:innen des zweiten Genehmigungsschritts automatisiert aus einer kundenspezifischen SAP-Tabelle ermittelt und dem Vorgang zugeordnet werden. Die Anbindung sowie Auswertung der kundeneigenen SAP-Tabelle muss durch die Softwarelösung unterstützt werden.

Im Einkaufswagen müssen die für den jeweiligen Genehmigungsprozess ermittelten Genehmigenden transparent angezeigt werden. Die Informationen müssen den an der Bearbeitung beteiligten Nutzenden jederzeit nachvollziehbar zur Verfügung stehen.

4.5. Anforderungen an die Genehmigung von Einkaufswagen

Folgende Funktionen sollen die Genehmiger:innen beim Genehmigen von Einkaufswagen unterstützen: • Als Genehmiger:in möchte ich Vorgänge im FIORI Launchpad, möglichst unter Nutzung der App „My Inbox“, bearbeiten können. In den Workflow-Aufgaben finden sich analog zur Fiori Inbox die Aufgaben einer Person. Die Anzahl der offenen Aufgaben wird im Fiori Launchpad direkt in der Kachel angezeigt, um direkt auf die Aufgaben zugreifen zu können. • Als Genehmiger:in möchte ich automatisch per E-Mail über vorliegende Vorgänge informiert werden, damit ich nicht täglich aktiv in meine Fiori-Inbox schauen muss. Optional möchte ich die E- Mailbenachrichtigungen für mich abstellen können. • Als Genehmiger:in möchte ich eine oder mehrere Stellvertreter:innen benennen können, die meine Einkaufswagen in Vertretung dauerhaft oder über festlegbare Zeiträume bearbeiten dürfen. Für Genehmiger:innen der 1. Stufe muss dazu auf die an der TUD implementierte Digitale Unterschriftenkarte verwiesen werden. Für Genehmer:innen der 2. Stufe muss ein eigenständiges Vertretungssystem vorhanden sein. • Als Genehmiger:in möchte ich meine Aufgaben im Master-Detail Format angezeigt bekommen, damit die Informationen übersichtlich dargestellt und die Funktionen für die Weiterverarbeitung vorhanden sind. Für die Bearbeitung stehen alle Daten des Einkaufswagens (inkl. der angehängten Dokumente und Notizen) zur Einsicht zur Verfügung. • Als Genehmiger:in möchte ich einen Vorgang speichern können, um meine gemachten Eingaben (siehe unten) zu einem späteren Zeitpunkt weiterbearbeiten zu können • Als Genehmiger:in möchte ich Vorgänge genehmigen oder ablehnen bzw. an Dezentrale Beschaffer:innen Rückfragen stellen oder zur Bearbeitung zurückgeben können, indem eine Begründung als Kommentar erfasst wird. • Als Genehmiger:in möchte ich die Kontierung von Einkaufswagen ändern können, um Finanzen steuern zu können. Mit Hinterlegung einer anderen Kontierung ist der Einkaufswagen zur Genehmigung an den:die zuständige:n Genehmigerin, weiterzuleiten, um die Genehmigung zu erteilen. • Als Genehmiger:in möchte ich, dass der:die Dezentrale Beschaffer:in automatisch per Mail über die Ablehnung bzw. Rückgabe (inkl. Grund) informiert wird, um aktiv werden zu können. • Als Dezentrale Beschaffer:in möchte ich mit der finalen Genehmigung eines Einkaufswagens automatisch eine Benachrichtigung per Mail erhalten, um Kenntnis vom aktuellen Status zu haben. Sofern im Einkaufswagen eine Ansprechperson hinterlegt hat, soll diese ebenfalls über die Genehmigung per Mail informiert werden

Die Genehmigungen müssen protokolliert werden.

[Seite 20]

4.6. Anforderungen an die Bearbeitung der Bestellung

Die neue Softwarelösung muss die nachfolgend beschriebenen, schon bestehenden Abläufe der Bestellung im SAP-MM weiter ermöglichen. Im Projekt sollen außerdem die ebenfalls nachfolgend beschriebenen Änderungen erarbeitet werden. Nach der vollständigen Genehmigung des Einkaufswagens wird der vollständige Datensatz an SAP-MM übergeben und folgende Szenarien können auf Basis der Wertgrenze und Warengruppe eintreten: • Bestellung wird angelegt und an den Lieferanten als PDF via E-Mail oder via EDI versendet sowie die Bestellkopie an den:die Dezentrale Beschaffer:in geschickt. Im Ausnahmefall wird bei Lieferanten der Bestellversand über Druck in der Zentralen Beschaffungsstelle ausgesteuert. Die EDI-xml-Struktur ist aktuell um kundeneigene Segmente für spezifische Angaben ergänzt. • Bestellung wird angelegt, aber lieferantenspezifisch nicht verschickt, sondern per E-Mail an den:die Dezentrale Beschaffer:in geschickt, um Bestellungen in Online-Portalen bei Zahlung auf Rechnung vorzunehmen. • Bestellung wird angelegt und steht bei Anlagenbezug (anlagenbezogene Warengruppe) der Anlagenbuchhaltung im SAP-MM zur Freigabe (via Freigabestrategie) und weiteren Bearbeitung zur Verfügung. Mit Freigabe durch die Anlagenbuchhaltung wird die Bestellung an den Lieferanten als PDF via E-Mail versendet sowie die Bestellkopie an den:die Dezentrale Beschaffer:in geschickt. • Bestellanforderung (BANF) wird angelegt und steht der Zentralen Beschaffung zur weiteren Bearbeitung zur Verfügung. Die Bestellung wird anschließend mit Bezug zur Bestellanforderungsnummer und der Einkaufswagennummer durch die Zentrale Beschaffung ausgelöst.

4.7. Anforderungen an das Löschen und Stornieren von Einkaufswagen

Folgende Funktionen sollen die Dezentralen Beschaffer:innen unterstützen:

• Als Dezentrale Beschaffer:in möchte ich Einkaufswagen bis zum Absenden (vor Übergabe an den Genehmigungsworkflow) löschen können. • Als Dezentrale Beschaffer:in möchte ich abgeschickte Einkaufswagen bis zur vollständigen Genehmigung zurückholen, ändern und erneut zur Genehmigung übergeben können. • Als Dezentrale Beschaffer:in möchte ich eine im SAP-MM angelegte Bestellung ganz oder positionsweise stornieren können, indem der Einkaufswagen oder einzelne/mehrere Positionen davon von mir storniert oder gelöscht werden. Für dieses Szenario werden umfangreiche Warnhinweise und ggf. ein gesondertes Vorgehen benötigt, da dies den Ausnahmefall darstellen soll und vorab sorgfältig geprüft werden muss.

4.8. Anforderungen an die Bearbeitung des Wareneingangs

Der Wareneingang kann für dezentrale Bestellungen dezentral durch die Beschaffer:innen erfasst werden. Folgende Szenarien können bei einem Wareneingang vorliegen: • vollständige Lieferung(en) • mehrere Teillieferungen bis zur vollumfänglich gelieferten Bestellmenge • mehrere Teillieferungen ohne die Bestellmenge vollumfänglich zu beliefern • Positionen, die nicht geliefert werden können (Storno-Szenario)

Folgende Funktionen sollen die Dezentralen Beschaffer:innen beim Erfassen des Wareneingangs unterstützen:

[Seite 21]

• Als Dezentrale Beschaffer:in möchte ich den Wareneingang für meine Einkaufswagen sowie für die Einkaufswagen der Personen, die ich vertrete, vornehmen und dabei folgende Informationen angeben können: Lieferdatum, Buchungsdatum, Lieferscheinnummer, Empfangene Menge, Letzte Lieferung/Endlieferkennzeichen, Startdatum/Endedatum bei Produkten mit Laufzeiten. Vorschlagswerte unterstützen mich dabei (Tagesdatum für die Datumsfelder, offene Menge der bestellten Position). • Als Dezentrale Beschaffer:in möchte ich den erhaltenen Lieferschein bei der Wareneingangsbuchung als Dokument auf Positionsebene hochladen können. • Als Dezentrale Beschaffer:in möchte ich nach einer erfolgten Buchung des Wareneingang diesen ganz oder anteilig stornieren können. Änderungsgründe sollen angegeben werden können, um Korrekturgründe zu dokumentieren. • Als Dezentrale Beschaffer:in möchte ich nach erfolgter Buchung des Wareneingangs, eine Möglichkeit haben, eine Rücksendung unter Angabe von Rücklieferungsgründen abzubilden und den Lieferanten zur Rücklieferung via E-Mail zu kontaktieren, um z.B. das Rücksendeetikett anzufordern • Als Dezentrale Beschaffer:in möchte ich bei einer unvollständigen Lieferung der Bestellmenge durch Setzen eines Endlieferkennzeichens vermerken, dass keine weiteren Lieferungen erwartet werden. • Als Dezentrale Beschaffer:in möchte ich kenntlich machen können, dass zu einer oder allen Positionen eines Einkaufswagens keine Rechnung mehr erwartet wird, um einen Obligoabbau zu ermöglichen. • Als Dezentrale Beschaffer:in möchte ich einzelne Positionen oder den gesamten Einkaufswagen stornieren können, wenn die Positionen der Bestellung gar nicht geliefert werden können. Der Vorgang wird damit abgeschlossen und das Obligo automatisch abgebaut. • Als Dezentrale Beschaffer:in möchte ich keine Einkaufswagen mehr in meinem Arbeitsvorrat sehen, deren Vorgang abgeschlossen ist. Zum Abschluss führen neben Wareneingang/Rechnungseingang/Ausgleich auch Löschkennzeichen/Erledigtkennzeichen in einer bzw. allen daraus erzeugten Banf- und/oder Bestellpositionen. • Als Dezentrale Beschaffer:in möchte ich bei der Erfassung von mangelhaften Lieferungen, (Menge entspricht nicht Bestellung, Produkt entspricht nicht Bestellung, Ware nicht termingerecht geliefert) sowie bei der Erfassung von Retouren unterstützt werden. • Als Dezentrale Beschaffer:in möchte ich vom Wareneingang heraus eine Mängelanzeigemit Standardtextbausteinen je Szenario per E-Mail an den Lieferanten versenden können.

4.9. Anforderung aus der Exportkontrolle

Folgende Funktionen soll die Softwarelösung bieten: • Die Softwarelösung muss an folgenden Zeitpunkten prüfen, ob der Lieferant im SAP-MM den Status „gesperrt“ hat: bei Lieferantenauswahl, vor Bestellung, und bei Wareneingangserfassung. Der Grund für die Sperre eines Lieferanten soll an Dezentrale Beschaffer:innen übermitteln werden (Notiz aus Kreditor), um den Dezentralen Beschaffer:innen zusätzliche Informationen bereitzustellen und Rückfragen zu minimieren. • Die Softwarelösung muss mit den Ergebnissen exportkontrollrechtlicher Prüfungen umgehen können.

[Seite 22]

4.10. Anforderungen an Berichte und Reports

Folgende Funktionen soll die Softwarelösung bieten: • Als Anwender:in möchte ich Berichte und Vorgänge über das FIORI Launchpad nutzen können, um Systemvielfalt zu reduzieren. • Als Anwender:in möchte ich Berichte und Vorgänge im Format xls, csv und pdf exportieren können. • Als Anwender:in möchte ich die eigenen Aufträge und Anforderungen, in Historien aufrufen, um Vorgänge nachvollziehen zu können • Als Anwender:in möchte ich in den Historien meiner Einkaufswagen auch den Status des Auftrages bzw. der Anforderung sowie den Genehmigungs- und Änderungsverlauf sehen, um nachträglich den Verlauf der Beschaffung nachvollziehen zu können. • Als Anwender:in möchte ich Filter- und Suchmöglichkeiten (auch für Beschreibungen der Vorgänge und nach Vorgangsnummer) haben, um nach Einkaufsvorgängen suchen und diese anhand von Kriterien (z.B. Einkaufswagennummer, SAP-Bestellnummer, Lieferant, Finanzierungselement, Status, Warengruppe, Zeitraum, ggf. individuell definierte Kriterien) filtern zu können (vgl. 4.2). • Als Controller:in möchte ich über Berichte die Möglichkeit erhalten, einen Überblick über die Einkaufswagen zu bekommen, die sich in Bezug auf die von mir verantworteten Finanzierungselemente aktuell in Genehmigung befinden. Damit erhalte ich rechtzeitig Überblick über die Entwicklung der Kostenstellen/PSP-Budgets und damit eine Steuerungsmöglichkeit. • Als Zentrale Beschaffer:in möchte ich erweiterte Reporting- und Auswertungsfunktionen nutzen können, um Durchlaufzeiten, Bottlenecks und andere relevante Kennzahlen zu analysieren, um dadurch unsere Beschaffungsprozesse kontinuierlich zu optimieren. Diese Auswertungen sollen als vorkonfigurierte Berichte zur Verfügung stehen, exportiert und individualisiert (z.B. Filterung nach Struktureinheiten oder Zeiträumen) werden können.

4.11. Anforderungen an Dokumente

Als Dezentrale Beschaffer:in möchte ich Dokumente an Einkaufswagen und Wareneingänge auf Kopf- und Positionsebene hochladen können (vgl. Kapitel 4.3). Dabei möchte ich erkennen können, ob diese Dokumente intern im System verbleiben oder falls ein Prozess das vorsieht an Lieferanten verschickt werden.

Als Anwender:in möchte ich beim Aufruf der Einkaufswagen die hochgeladenen Dokumente sowie die Belege zum Beschaffungsprozess aus dem SAP-System einsehen können.

Als nicht unmittelbar am Beschaffungsprozess beteiligte Person möchte ich die Dokumente zum Beschaffungsprozess zukünftig im Dokumentenmanagement als Bestandteil einer Akte einsehen können. (Anmerkung: Dieser Prozess ist im Projekt nicht technisch umzusetzen, die Softwarelösung muss jedoch eine Aussteuerung der Ablage von Dokumenten ermöglichen.)

Als Systemadministration möchte ich, dass die Aussteuerung der Dokumentablage über Repositories sowie deren Änderung bei einer eventuellen Migration der Dokumentablage möglich ist.

5. Schnittstellen

Um die Integration in verschiedene Systeme und Prozesse sicherzustellen, muss die neue Softwarelösung vordefinierte Schnittstellen besitzen.

[Seite 23]

Hervorzuheben ist hierbei die Anbindung bzw. Integration in das ERP-System der TUD SAP ERP 6.0, um eine reibungslose Kommunikation zwischen den Bedarfsstellen und den Lieferanten sowie eine automatische Übertragung von Daten wie Bestellungen, Genehmigungen oder Budgetprüfungen zu ermöglichen.

Darüber hinaus ist eine Schnittstelle zum Dokumentenmanagementsystem der TUD d.velop erforderlich, um Dokumente zum Beschaffungsprozess dort zukünftig als Bestandteil einer Akte einsehen zu können.

Externe Webshops werden über OCI-Schnittstellen angebunden, um Warenkörbe aus Webshops einlesen zu können. Hierbei wird der Standard, ggf. erweitert um Felder, verwendet. Die Schnittstellen zu den Webshops sind bereits im jetzigen SRM-System vorhanden und müssen an die neue Softwarelösung angepasst werden. Darüber hinaus müssen Massenuploads aus importierten Dateien im xls-oder csv- Format für Webshops/Einkaufswagen und interne Kataloge möglich sein.

Die Möglichkeit, zukünftig einen Markplatz über eine OCI-Schnittstelle anzubinden, muss in der neuen Softwarelösung vorhanden sein.

6. Customizing und Administration

Die neue Softwarelösung muss die Möglichkeit für kundenindividuelles Customizing und Administration durch die Systemadministration sicherstellen. Die folgenden Funktionalitäten sollen vorhanden sein: • Als Systemadministration möchte ich, soweit sinnvoll, an der TUD vorhandene Apps möglichst auch für den dezentralen Beschaffungsprozess konfigurieren können, um Betriebsaufwände zu reduzieren. • Als Systemadministration möchte ich für kundenindividuelle sowie Standardfelder kundenindividuelle Hilfstexte konfigurieren können. • Als Systemadministration möchte ich kundenindividuelle Felder auf Kopf- und Positionsebene sowie den nachfolgend genannten Abschnitten konfigurieren sowie die Möglichkeit in Abhängigkeit bestimmter Feldinhalte (z.B. definierte Einträge einer Auswahlliste), eine andere Sicht (z.B. Registerkarte, Dialogfenster) mit anderen Felder einblenden zu können, um zukünftige Prozessanpassungen unterstützen zu können. Die Länge der Datenfelder sollte sich an SAP orientieren. • Als Systemadministration möchte ich die Möglichkeit haben, sowohl Standard- als auch kundenindividuelle Felder flexibel als read-only zu konfigurieren. Neben systemseitigen Standard- Pflichtfeldern können zusätzlich weitere kundenindividuelle und Standardfelder als Pflichtfelder definiert werden. • Als Systemadministration möchte ich die Aussteuerung von Eingaben in muss- und kann-Eingaben oder Wertänderungen der Prüfkriterien anpassen können. Wünschenswert ist eine Erweiterbarkeit der Prüfkriterien und deren Darstellung. • Als Systemadministration möchte ich die Eingabe und Fortschreibung zusätzlicher Werte ins SAP- System ermöglichen, um vorhandene Prozesse weiter (z.B. Nutzung der Aktennummer) oder zukünftige Prozessanpassungen unterstützen zu können (Beispiel: Optimierung der Datenerhebung für Intrastat-Meldungen, vgl. dazu Kapitel 4.3). • Als Systemadministration möchte ich nicht änderbare Werte zentral voreinstellen können (z.B. Buchungskreis) und die Bearbeitbarkeit von Feldern ändern können. • Als Systemadministration möchte ich die Möglichkeit haben Warengruppe nutzerspezifisch verfügbar zu machen.

[Seite 24]

• Als Systemadministration möchte ich lieferantenbezogene Hilfetexte bereitstellen können, um bei der Anlage des Einkaufswagens bestmöglich zu unterstützen. • Als Systemadministration möchte ich das Mapping/ein Regelwerk von erforderlichen Zusatzangaben zu Warengruppe anpassen können, um auf Anforderungen reagieren zu können. Das Mapping/Regelwerk ist teils aktuell noch nicht vorhanden und muss ggf. im Einführungsprojekt der neuen Softwarelösung prozessual entworfen und technisch abgebildet werden. Es wird von einer Umsetzung im SAP-System ausgegangen. • Als Systemadministration möchte ich automatische Benachrichtigungen und verschiedene Eskalationsstufen konfigurieren können, um die Anwender:innen bestmöglich zu unterstützten. • Als Systemadministration möchte ich für exportierbare Berichte Corporate Design-Templates einrichten und anpassen können, um auf neue Anforderungen reagieren zu können. • Als Systemadministration möchte ich exportierbare Berichte individuell konfigurieren und ändern können, um auf neue Anforderungen reagieren zu können. • Als Systemadministration möchte ich den Zugriff auf neue Dokumentenarten ergänzen können, um den Zugang zu Dokumenten aus dem Dokumentenmanagementsystem zu ermöglichen • Als Systemadministration möchte ich, dass die Aussteuerung der Dokumentablage über Repositories sowie deren Änderung bei einer Migration der Dokumentablage möglich ist. • Als Systemadministration möchte ich einen Monitor zur Verfügung haben, über den alle Einkaufswagen ab Status „Gesichert“ sowie Einkaufswagen, die während der Verarbeitung auf Fehler gelaufen sind, mit entsprechender Fehlermeldung eingesehen werden können. • Als Systemadministration möchte ich die Möglichkeit haben, die Verarbeitung von fehlerhaften Einkaufswagen bei beispielsweise technischen Fehlern oder Verbindungsabbrüchen neu zu starten. • Als Systemadministration möchte ich die Möglichkeit haben, Einkaufswagen auf andere Anwender:innen übertragen zu können (z. B. bei anwender:innenseitig nicht ausreichend gepflegter Stellvertretungsregeln, gleichzeitiger Abwesenheit, etc.), um eine Bearbeitung zu ermöglichen. • Als Systemadministration möchte ich, dass SAP-Fehler, die in der weiteren Verarbeitung im SAP- System erzeugt wurden, an die Softwarelösung zurückgemeldet werden, damit ich diese sowohl als Administrator:in einsehen und beheben als auch als Anwender:in in meinem Einkaufswagen nachvollziehen kann.

Kundenindividuelle Umsetzungen, die über Customizing hinausgehen und Erweiterungen der Logik beinhalten, müssen über standardisierte SAP-Erweiterungstechniken, wie z.B. BAdIs, implementierbar sein.

Im Einführungsprojekt werden Vorschläge oder Konzepte zur Konfiguration im SAP-System erwartet.

7. Umsetzungsberatung und Migration

Grundsätzlich wird eine Standardisierung von Prozessen verfolgt. Die Softwarelösung soll nur so weit wie erforderlich kundenspezifisch angepasst werden. Im Einführungsprojekt wird daher, neben der Bereitstellung und Konfiguration der Softwarelösung, Prozessberatung mit der Empfehlung von Best Practice – Geschäftsprozessen erwartet.

Das soll einen Vergleich einer standardnahen Nutzung des SAP-Systems und der angebotenen Softwarelösung zu kundenspezifischen Anforderungen und deren eventuellen Abweichungsgrad vom jeweiligen Standard ermöglichen. Für den Fall von mehreren alternativen Umsetzungsmöglichkeiten sollen jeweils Kosten-/Nutzenvergleiche angestellt und über Anpassungen entschieden werden können.

[Seite 25]

Die Ablösung von SAP-SRM soll zu einem noch festzulegenden Stichtag erfolgen, an dem die neue Softwarelösung produktiv gesetzt wird. Dabei werden keine Altdaten übernommen, sondern ausschließlich neue, bereinigte Datenstrukturen und Prozesse implementiert. Altdaten bleiben im Altsystem für Archivierungs- und Reportingzwecke zugänglich. Für die Übergangsphase wird sichergestellt, dass alle zwischenzeitlich entstandenen Daten (z. B. offene Bestellungen) manuell oder automatisiert in das neue System überführt werden.

Der Rollout der neuen Softwarelösung erfolgt schrittweise, um die Einführung kontrolliert und risikoarm zu gestalten. Dabei wird die neue Softwarelösung in einer ausgewählten Organisationseinheit (z. B. einer Struktureinheit oder einem Standort) eingeführt, um die neuen Prozesse und das System im Echtbetrieb zu validieren und Optimierungspotenziale zu identifizieren. Nach erfolgreicher Pilotierung wird die Softwarelösung sukzessive auf weitere Struktureinheiten ausgerollt. Mit Abschluss des Rollouts wird das Altsystem deaktiviert und die verbleibenden Daten werden archiviert.