Moin Community,

hier findet Ihr meinen genehmigten Projektantrag, nachdem ich nach einer Korrektur alle Anforderungen der SIHK zu Hagen erfüllt habe.

Auf der Basis des Antrages habe ich mein Projekt umgesetzt, die Projektdokumentation erstellt und am Donnerstag mit der Projektpräsentation und dem Fachgespräch erfolgreich abgeschlossen.

Hoffe, das meine persönliche success story hilfreich für andere angehende Fachinformatiker:innen ist.

Viele Grüße
Heiko

# IHK-Projektantrag: SDS Versand Optimierer

**Prüfung:** Winter 2025/2026  
**IHK:** Hagen  
**Ausbildungsberuf:** Fachinformatiker/-in Fachrichtung Anwendungsentwicklung  
**eingereicht:** 07. September 2025
**korrigiert:** 17. Oktober 2025
**genehmigt:** 30. Oktober 2025

---

## Prüfungsbewerber

**Name:** Have Fun  
**Identnummer:** 123456  
**E-Mail:** <hhf@dings.da>  
**Telefon:** +49 123 456789

**Ausbildungsbetrieb:** IBB Institut für Berufliche Bildung AG  
**Betrieblicher Betreuer / Ausbilder:** Herr Vorname Nachnahme  
**E-Mail Ausbilder:** <service.west@***.***>

**Projektunternehmen:** ACME Ltd, Neverland

---

## 1. Thema der Projektarbeit

**Entwicklung und Implementierung eines User-Exits im SAP ECC 6.0 System zur Integration der Dokumentenempfänger-Verwaltung aus den Modulen EH&S (Produktsicherheit) und SD (Vertrieb) in eine einheitliche Transaktion für die rimpido GmbH und deren Kunden.**

---

## 2. Geplanter Bearbeitungszeitraum

- **Beginn:** 30. Oktober 2025
- **Ende:** ca. 08. Dezember 2025
- **Gesamtaufwand:** 80 Stunden

---

## 3. Ausgangssituation

### 3.1 Projektumfeld

Die ACME ist ein SAP EH&S-Spezialist, der SAP-Lösungen für Gefahrstoff-Management entwickelt. Das Unternehmen betreut Kunden in der chemischen Industrie, Pharmazie und im Maschinenbau.

### 3.2 IST-Analyse - Aktueller Prozess

Bei der täglichen Verwaltung von Sicherheitsdatenblatt-Empfängern müssen die Mitarbeiter der Fachabteilungen **HSE&Q** (1 Mitarbeiter) und **Vertrieb** (2 Mitarbeiter) derzeit folgende zeitaufwändige Schritte durchführen:

| Schritt | Transaktion | Beschreibung | Zeitaufwand |
| --- | --- | --- | --- |
| 1 | VD02 (SAP SD) | Kundenstammdaten öffnen | 2,5 Min |
| 2 | VD02 | Partnerfunktionen: Empfänger-Adressen manuell suchen und ändern | 8,5 Min |
| 3 | CG02 (SAP EH&S) | Gefahrstoff-Spezifikation öffnen | 2,0 Min |
| 4 | CG02 | SDB-Versand: Dokumentenempfänger-Liste abgleichen | 7,0 Min |
| 5 | Manuell | Konsistenz zwischen beiden Modulen prüfen | 5,0 Min |
| **GESAMT** | | | **25 Min/Vorgang** |

### 3.3 Messbare Probleme

| Problem | IST-Wert | Auswirkung |
| --- | --- | --- |
| **Zeitaufwand** | 25 Min/Vorgang | Täglich 15-20 Vorgänge = 6-8 Stunden/Tag für 3 Mitarbeiter |
| **Fehlerrate** | 12% Inkonsistenzen | Zwischen SD- und EH&S-Daten (Messung vom 15.09.2025) |
| **Personalkosten** | 900 €/Monat | Für redundante Arbeitsschritte |
| **Kundenzufriedenheit** | 2-3 Reklamationen/Woche | Durch falsche Empfänger-Zuordnung |

### 3.4 Systemumgebung

- **SAP ECC 6.0** (Enhancement Package 8)
- **SAP EHS 3.0** (Environment, Health & Safety)
- **SAP SD** (Sales & Distribution - Standard-Funktionalität)
- **Entwicklungsumgebung:** SAP GUI 7.70, ABAP Workbench

### 3.5 Kernproblem

Es existiert **keine integrierte SAP-Standardfunktion** zur gleichzeitigen Verwaltung von Dokumentenempfängern in den Modulen:

- **SD** (Vertrieb/Kundenstamm)
- **EHS** (Gefahrstoff-Spezifikation)

### 3.6 Geschäftliche Auswirkungen

-  Verlust von 6-8 Arbeitsstunden/Tag durch Doppelarbeiten (3 Mitarbeiter in 2 Fachabteilungen)
-  Compliance-Risiko durch fehlerhafte Empfänger-Zuordnungen
-  Kundenbeschwerden durch verspätete oder fehlerhafte SDB-Zustellung

### 3.7 Lösungsmöglichkeiten

| Option | Beschreibung | Bewertung |
| --- | --- | --- |
| **1. Drittanbieterlösung** | 3E ERC+ Suite oder CHEMDOX |  Hohe Lizenzkosten, aufwendige Schnittstellen |
| **2. DMS-Integration** | Dokumentenmanagementsystem der rimpido GmbH |  Zusätzliche Schnittstellen, kein SAP-Standard |
| **3. User-Exit (Eigenentwicklung)** | Maßgeschneiderte Lösung im bestehenden SAP-ERP-System |  **EMPFOHLEN** - Kosteneffizient, integriert |

### 3.8 Empfohlene Lösung

**Neuentwicklung eines User-Exits im bestehenden SAP-ERP-System der rimpido GmbH.**

Die anderen Optionen wurden nicht weiter verfolgt, da sie entweder mit der aufwendigen Entwicklung weiterer Schnittstellen verbunden sind oder zusätzliche Lizenzkosten verursachen würden.

---

## 4. Projektziel

### 4.1 Hauptziel

Entwicklung einer **integrierten SAP-Transaktion**, die Dokumentenempfänger-Daten aus beiden Modulen (SD + EHS) in einer **einheitlichen Oberfläche** darstellt und **synchron verwaltet**.

### 4.2 Funktionale Anforderungen

-  Anzeige aller relevanten Partnerfunktionen aus Kundenstamm (VD03)
-  Verknüpfung mit EH&S-Spezifikationsdaten (CG03)
-  Bearbeitungsfunktion für Empfänger-Zuordnungen
-  Plausibilitätsprüfung und Validierung bei Änderungen
-  Protokollierung aller Änderungen (Change Documents)

### 4.3 User Stories

| # | Rolle | Ziel |
| --- | --- | --- |
| **US-1** | HSE&Q-Mitarbeiter | Alle Dokumentenempfänger eines Kunden in einer Oberfläche sehen |
| **US-2** | Fachanwender im Vertrieb | Empfänger-Änderungen ohne Systemwechsel durchführen |
| **US-3** | Qualitätsverantwortlicher | Nachvollziehen, wer wann welche Änderungen vorgenommen hat |

### 4.4 Messbare Erfolgskriterien

| Kriterium | IST-Wert | SOLL-Wert | Messverfahren |
| --- | --- | --- | --- |
| **1. Bearbeitungszeit** | 25 Min/Vorgang | 17 Min/Vorgang (30% Reduktion) | Zeitmessung bei 20 Testvorgängen |
| **2. Fehlerrate** | 12% Inkonsistenzen | < 2% | Stichproben-Kontrolle über 2 Wochen |
| **3. Benutzerfreundlichkeit** | 3,2/5,0 | ≥ 4,2/5,0 | User-Feedback-Fragebogen |
| **4. Systemwechsel** | 2 Transaktionen/Vorgang | 1 Transaktion | Transaktions-Counting |

### 4.5 Technische Anforderungen

| Aspekt | Spezifikation |
| --- | --- |
| **Entwicklungsansatz** | User-Exit / Enhancement in bestehender SAP-Transaktion |
| **Architektur** | Model-View-Controller (MVC) Pattern |
| **Datenintegration** | RFC-Calls zwischen SD- und EH&S-Modulen |
| **Oberfläche** | ALV Grid mit Edit-Funktionalität |
| **Berechtigungskonzept** | Integration in bestehendes SAP-Rollenkonzept |

---

## 5. Zeitplanung

**Gesamtaufwand:** 80 Stunden über 6 Projektphasen mit 4 Stunden vorgesehenem Puffer

### Phase 1: Analysephase (4 Stunden)

#### Arbeitspaket 1.1: IST-Aufnahme (2 Stunden)

- **Inhalt:** Workflow-Analyse aktueller Prozess, Screenshot-Dokumentation
- **Ergebnis:** IST-Dokumentation

#### Arbeitspaket 1.2: Anforderungsworkshop (2 Stunden)

- **Inhalt:** Interview mit 3 Fachanwendern (HSE&Q), Requirements Engineering
- **Ergebnis:** Anforderungskatalog

**Meilenstein:** Vollständige IST-/SOLL-Analyse erstellt und von Stakeholdern abgenommen

---

### Phase 2: Konzeptionsphase (12 Stunden)

#### Arbeitspaket 2.1: Technisches Konzept (4 Stunden)

- **Inhalt:** Systemarchitektur, Datenmodell, Schnittstellen-Design
- **Ergebnis:** Systemarchitektur-Dokument

#### Arbeitspaket 2.2: UI-Konzept (4 Stunden)

- **Inhalt:** Mockups, Navigation, ALV-Grid-Design
- **Ergebnis:** UI-Mockups und Spezifikation

#### Arbeitspaket 2.3: Pflichtenheft (4 Stunden)

- **Inhalt:** Funktionale und technische Spezifikation
- **Ergebnis:** Detailliertes Pflichtenheft

**Meilenstein:** Technisches Konzept freigegeben, Entwicklung kann starten

---

### Phase 3: Implementierungsphase (36 Stunden)

#### Arbeitspaket 3.1: Datenmodell (12 Stunden)

- **Inhalt:** RFC-Module für SD/EHS-Integration, Datenstrukturen
- **Ergebnis:** Funktionale RFC-Module

#### Arbeitspaket 3.2: Business Logic (8 Stunden)

- **Inhalt:** Validierung, Plausibilitätsprüfung, Change Documents
- **Ergebnis:** Vollständige Geschäftslogik

#### Arbeitspaket 3.3: User Interface (12 Stunden)

- **Inhalt:** ALV Grid, Edit-Funktionen, Navigation
- **Ergebnis:** Funktionsfähige Benutzeroberfläche

#### Arbeitspaket 3.4: Integration (4 Stunden)

- **Inhalt:** Einbindung in bestehende Transaktion, Berechtigungsprüfung
- **Ergebnis:** Integrierte Lösung

**Meilenstein:** Funktionsfähiger Prototyp im Entwicklungssystem

---

### Phase 4: Testphase (8 Stunden)

#### Arbeitspaket 4.1: Testkonzept (3 Stunden)

- **Inhalt:** Testfälle, Testdaten, Abnahmekriterien
- **Ergebnis:** Testkonzept-Dokument

#### Arbeitspaket 4.2: Systemtest (3 Stunden)

- **Inhalt:** Unit-Tests, Integrationstests im Testsystem
- **Ergebnis:** Testprotokolle

#### Arbeitspaket 4.3: Code-Review (2 Stunden)

- **Inhalt:** Peer-Review mit einem weiteren Entwickler, Git-Integration, Dokumentation
- **Ergebnis:** Freigegebener Code

**Meilenstein:** Alle Tests erfolgreich, Lösung bereit für Produktionsübernahme

---

### Phase 5: Einführungsphase (5 Stunden)

#### Arbeitspaket 5.1: Anwenderschulung (3 Stunden)

- **Inhalt:** Schulung von 3 Mitarbeitern (1x HSE&Q, 2x Vertrieb)
- **Ergebnis:** Geschulte Anwender

#### Arbeitspaket 5.2: Produktionsübernahme (2 Stunden)

- **Inhalt:** Transport ins Produktivsystem, Go-Live
- **Ergebnis:** Produktive Lösung

**Meilenstein:** Lösung produktiv im Einsatz

---

### Phase 6: Qualitätssicherung und Dokumentation (15 Stunden)

#### Arbeitspaket 6.1: QS-Konzept (2 Stunden)

- **Inhalt:** Qualitätssicherungsmaßnahmen definieren
- **Ergebnis:** QS-Konzept

#### Arbeitspaket 6.2: QS-Durchführung (1 Stunde)

- **Inhalt:** Code-Qualität, Performance-Tests
- **Ergebnis:** QS-Bericht

#### Arbeitspaket 6.3: QS-Dokumentation (2 Stunden)

- **Inhalt:** Testergebnisse, Verbesserungsvorschläge
- **Ergebnis:** QS-Dokumentation

#### Arbeitspaket 6.4: Projektdokumentation (10 Stunden)

- **Inhalt:** Vollständige technische und fachliche Dokumentation
- **Ergebnis:** IHK-Projektdokumentation

**Meilenstein:** Vollständige Projektdokumentation für IHK-Prüfung

---

### Zusammenfassung Zeitplanung

| Phase | Dauer | Prozent |
|-------|-------|---------|
| Phase 1: Analysephase | 4 h | 5,0% |
| Phase 2: Konzeptionsphase | 12 h | 15,0% |
| Phase 3: Implementierung | 36 h | 45,0% |
| Phase 4: Testphase | 8 h | 10,0% |
| Phase 5: Einführung | 5 h | 6,3% |
| Phase 6: QS & Dokumentation | 15 h | 18,8% |
| **Puffer (Reserve)** | 4 h | 5,0% |
| **GESAMT** | **80 h** | **100%** |

**Kritischer Pfad:** Phase 3 (Implementierung) → Phase 4 (Tests) → Phase 5 (Einführung)

**Risikopuffer:** 5% je Phase für unvorhergesehene Probleme bereits einkalkuliert

---

## Status

 **Antrag bei IHK Hagen eingereicht:** 17. Oktober 2025  
 **Genehmigung erteilt:** 30. Oktober 2025  
 **Projektstart geplant:** 30. Oktober 2025

---

## Kontakt

**Projektverantwortlicher:** Have Fun  
**E-Mail:** <hf@dings.da>  
**Telefon:** +49 123 4567890

**Betrieblicher Betreuer:** Herr Vorname Nachname (IBB Institut für Berufliche Bildung AG)  
**E-Mail:** <service.west@***.***>

**Projektunternehmen:** ACME  
**Adresse:** Neverland im Land des roten Pavians

Bearbeitet Samstag um 18:274 Tage von charmanta
Anonymisierung

ich bin mal so frei Deinen Namen im Klartext da rauszunehmen ?

vor 2 Minuten, charmanta hat gesagt:

ich bin mal so frei Deinen Namen im Klartext da rauszunehmen ?

Kannst Du gerne machen, falls es hier im Forum notwendig ist.

In unseren Folgeprojekten für weitere Azubis bei GitHub und auch über Discord wüssten wir allerdings schon gerne, für welche Azubis/Umschüler:innen wir unsere Erfahrungen bereitstellen.

Deshalb habe ich meinen Praktikums-Betrieb nicht aus dem Klartext herausgenommen.

Sorry da war ich schneller. In der Regel wünschen Betriebe keine Klartextnennung

Gerade, charmanta hat gesagt:

Sorry da war ich schneller. In der Regel wünschen Betriebe keine Klartextnennung

Kein Problem!

Die beiden Betriebe, in welchen ich meine Praktika absolviert habe wünschen sich entgegengesetzt der Regel unterstützende Angebote zu bieten.

Es ist auch unwahrscheinlich, das ich noch mal von meinem ehemaligen Bildungsträger "mit rechtlichen Konsequenzen" konfrontiert werde.

Mein Wunsch ist es, sowohl die positiven Erfahrungen mit Azubis/Umschüler:innen zu teilen als auch konstruktive Ansatzpunkte zu liefern - das manche Bildungsträger hier mMn ihre Qualität massiv verbessern müssen.

Glückwunsch zur bestandenen Prüfung. Ich hoffe sehr, dass ich hier falsch liege, aber mir scheint der Projektantrag hier mit hoher Wahrscheinlichkeit durch die KI generiert zu sein. Insbesondere die verwendeten Setzung von Sonderzeichen wie "#" und "*" sowie die Formatierung der Tabelle lassen darauf schließen.

Ich persönlich rate dazu, die KI maximal zur Unterstützung/Hilfestellung zu benutzen. Sollte ich Dir mit meiner Behauptung Unrecht getan haben, bitte ich im Voraus um Entschädigung.

Abschließend hat es aber funktioniert und daher wiederhole ich mich sehr gerne und beglückwünsche Dich nochmals. Alles Gute für Deinen weitere Karriereweg und Deine Zukunft..

Am 17.1.2026 um 23:07, Muff Potter hat gesagt:

Ich hoffe sehr, dass ich hier falsch liege, aber mir scheint der Projektantrag hier mit hoher Wahrscheinlichkeit durch die KI generiert zu sein. Insbesondere die verwendeten Setzung von Sonderzeichen wie "#" und "*" sowie die Formatierung der Tabelle lassen darauf schließen.

Ich persönlich rate dazu, die KI maximal zur Unterstützung/Hilfestellung zu benutzen. Sollte ich Dir mit meiner Behauptung Unrecht getan haben, bitte ich im Voraus um Entschädigung.

Moin, ich kann Deine Einschätzung nachvollziehen - möchte das gerne korrigieren.

Grundsätzlich schreibe ich allen Text-Content zunächst per Hand in Visual Studio Code in Markdown, deshalb die KI-typischen Merkmale - welche Du aufgezeigt hast.
Habe deshalb den Codeblock hier auch als Format Markdown ins Forum gesetzt.

Anschließend exportiere ich dann in die gängigen Formate - zur Not auch mal .docx oder .pptx falls es erforderlich ist.

Bezüglich Deinem Hinweis zum Einsatz der KI als Unterstützung/Hilfestellung hast Du ebenfalls zu 100% recht. In meiner Dokumentation hatte ich GitHub Copilot genannt und daraus wurde dann auch eine erwartbare kritische Frage im Fachgespräch.

Meine Antwort war, das wir GitHub Copilot ähnlich wie die Rechtschreib- oder Syntaxkorrektur als 3. Code-Reviewer eingesetzt haben und noch Fehler aufgezeigt haben, welche 3 Menschen vorher manchmal übersehen haben. Diese Art der Verwendung ordne ich als Unterstützung/Hilfestellung ein.

vor 7 Minuten, Mysteryland hat gesagt:

In meiner Dokumentation hatte ich GitHub Copilot genannt und daraus wurde dann auch eine erwartbare kritische Frage im Fachgespräch.

Meine Antwort war, das wir GitHub Copilot ähnlich wie die Rechtschreib- oder Syntaxkorrektur als 3. Code-Reviewer eingesetzt haben und noch Fehler aufgezeigt haben, welche 3 Menschen vorher manchmal übersehen haben. Diese Art der Verwendung ordne ich als Unterstützung/Hilfestellung ein.

Ich hoffe, dass sich die einzelnen IHK dazu bald verbindlich und möglichst bundesweit einheitlich positionieren.
Diese von Firmen geschätzte und genutzte Technik, so in einer Grauzone zu belassen, ist vollkommen unproduktiv.
Im Hochschulbereich verwenden wir schon seit einiger Zeit Richtlinien für den Umgang und Einsatz, die Art der Quellenangabe usw.
Teilweise vergeben wir Aufgaben, die einen Einsatz von KI zwingend mit einer % Zahl vorschreiben.
Ohne diesen mit KI generierten Anteil, kann keine Bewertung mehr mit 'Sehr gut' erfolgen.

Wäre also gut, wenn die Prüfungsordnung(en) der IHK dies eindeutig ansprechen und regeln würden.

vor 6 Minuten, hellerKopf hat gesagt:

Im Hochschulbereich verwenden wir schon seit einiger Zeit Richtlinien für den Umgang und Einsatz, die Art der Quellenangabe usw.

Alles wieder sehr gute Punkte, welche Du aufzeigst - danke!

Bei den Quellenangaben hatte ich in meiner Doku in den Fussnoten Wikipedia verwendet, wurde schon vor dem Beginn der Präsentation vom Prüfungs-Ausschuss darauf hingewiesen das dies keine gültige Quellenangabe ist. Hier wäre mehren mehr und genauere Vorgaben im Vorfeld hilfreicher gewesen.

vor 3 Minuten, Mysteryland hat gesagt:

Prüfungs-Ausschuss darauf hingewiesen das dies keine gültige Quellenangabe ist. Hier wäre mehren mehr und genauere Vorgaben im Vorfeld hilfreicher gewesen.

Das sollte eigentlich kein Problem sein:

Die vollständige Angabe von Wikipedia besteht aus:

• Suchwort

• Jahr der letzten Bearbeitung

• ,In Wikipedia‘

• Permanentlink
  
  siehe https://www.bachelorprint.de/apa-zitieren/apa-zitieren-beispiele/wikipedia/
  
  Da es sich bei deiner Projektdoku ja nicht um eine Arbeit, nach wissenschaftlichen Kriterien handelt, sondern nur die Quelle deiner Recherchen dargelegt wird, sollte das passen.

vor 12 Minuten, hellerKopf hat gesagt:

Die vollständige Angabe von Wikipedia besteht aus:

• Suchwort

• Jahr der letzten Bearbeitung

• ,In Wikipedia‘

• Permanentlink

Nächster guter Punkt! Es hat seinen Grund, warum ich meinen Projektantrag gerne teile und zur Diskussion stelle. Bei der Dokumentation dann lieber erst mal die entsprechenden Auszuüge.