Block 04 · Projektmanagement – Lösungen

a) Projektmerkmale (3 P) – drei der folgenden

• Einmaligkeit: Lindenhof führt erstmals eine mobile, papierlose Pflegedokumentation mit App, Webportal und CareBill-Schnittstelle ein – in dieser Kombination gab es das im Unternehmen noch nicht.
• Zeitliche Begrenzung: Laufzeit vom 01.02.2027 bis 30.11.2027, Go-Live am 01.11.2027.
• Klare Zielvorgabe: messbare Ziele, z. B. Dokumentationsaufwand um mindestens 30 % senken, Abrechnung bis zum 5. Werktag.
• Begrenzte Ressourcen: Budget 420.000 €, festes Team (Projektleiter, Product Owner, vier Entwickler/innen …).
• Komplexität / Risiko: viele Beteiligte (Pflege, Verwaltung, Betriebsrat, Datenschutzbeauftragter, CareBill-Hersteller), Schnittstelle zu Fremdsoftware, Gesundheitsdaten.
• Eigene Projektorganisation: Projektleiter Tobias Wendt, Scrum-Team mit Product Owner und Scrum Master.

b) Magisches Dreieck (3 P)

Zeit, Kosten und Leistung/Qualität hängen voneinander ab. Wird die Zeit um zwei Monate verkürzt und bleiben die Kosten gleich, muss die Leistung bzw. Qualität nachgeben: Zum Go-Live stehen weniger Funktionen zur Verfügung (z. B. Auswertungen im Webportal erst später), Pilotbetrieb und Tests werden verkürzt – Fehler, etwa bei der Übergabe an CareBill, werden eher in den Echtbetrieb getragen; Schulungen werden gedrängt. Alternativ müsste mehr Personal eingesetzt werden (Überstunden, zusätzliche Entwickler), was die Kosten erhöht und das feste Budget sprengt.

Erklärung: „Einmaligkeit“ heißt nicht, dass es so etwas weltweit noch nie gab, sondern dass die Bedingungen für dieses Vorhaben einmalig sind. In b) reicht „geht nicht“ nicht – gefragt ist, welche Größe nachgeben muss.

a) Stakeholder-Tabelle (8 P) – vier der folgenden

b) Umgang mit dem Betriebsrat (2 P)

Der Betriebsrat ist ein kritischer Stakeholder (hoher Einfluss, negative Einstellung) und muss intensiv betreut werden: frühzeitig und regelmäßig einbinden (z. B. Teilnahme an Sprint Reviews, eigener Abstimmungstermin), Bedenken ernst nehmen und offenlegen, welche Daten gespeichert und ausgewertet werden, und gemeinsam die Betriebsvereinbarung erarbeiten (Zweckbindung, keine Leistungskontrolle).

Erklärung: Die Beispielzeile (Geschäftsführerin) zählt nicht. Häufiger Fehler: nur „Kunde“ und „Nutzer“ nennen – gerade Betriebsrat und Datenschutzbeauftragter haben hier großen Einfluss.

a) Begriffe (8 P)

b) Befürchtungen und Maßnahmen (6 P)

c) Projekterfolg prüfen (4 P) – zwei der folgenden

• Soll-Ist-Vergleich der Projektziele nach einigen Monaten Betrieb: Dokumentationszeit je Einsatz messen (Ziel: von 4,0 auf höchstens 2,8 Minuten = −30 %), Abrechnungstermin (bis 5. Werktag?), Fehlerquote der Nachweise (< 0,5 %?), alle vier Standorte papierlos?
• Termin und Budget: Go-Live am 01.11.2027 erreicht, Kosten innerhalb von 420.000 €?
• Abnahme: Abnahmeprotokoll ohne wesentliche Mängel, Anforderungen aus dem Pflichtenheft erfüllt.
• Zufriedenheit und Nutzung: Befragung von Pflegekräften, PDL und Verwaltung; Nutzungsquote der App, Anzahl Supportanfragen, wird noch auf Papier dokumentiert?
• Abschlussbericht und Lessons-Learned-Workshop mit Bewertung aller Abweichungen.

d) Change Request „Angehörigenportal“ (4 P)

1. Erfassen: Die Anforderung wird als formaler Änderungsantrag (Beschreibung, Begründung, Antragstellerin, Nummer) aufgenommen – nicht einfach „nebenbei“ umgesetzt.
2. Bewerten: Kranich schätzt Aufwand und Kosten (Nachtragsangebot wegen Festpreis), Auswirkung auf den Go-Live-Termin, zusätzliche Risiken (Datenschutz beim Zugang Angehöriger, Testaufwand) und Nutzen.
3. Entscheiden: Der Auftraggeber bzw. Lenkungsausschuss (Dr. Esser) entscheidet – annehmen (mit Budget- und ggf. Terminanpassung), ablehnen oder auf Phase 2 verschieben.
4. Umsetzen und dokumentieren: Bei Annahme Product Backlog, Projektplan, Budget und Vertrag anpassen; die Entscheidung dokumentieren und allen Beteiligten mitteilen.

Erklärung: Typischer Fehler in a): Meilenstein als „Abschnitt“ oder „Phase“ erklären – er ist ein Zeitpunkt. In d) gilt: Ein Change Request wird immer erst bewertet und vom Auftraggeber entschieden; die Pflegedienstleitung kann den Umfang nicht allein erweitern.

a) Zuordnung (3 P)

b) Werte des agilen Manifests (2 P) – zwei der folgenden

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

c) Zweck des WIP-Limits (1 P)

Das WIP-Limit begrenzt die Anzahl der Aufgaben, die gleichzeitig in einer Spalte bearbeitet werden. So wird Überlastung und paralleles Anfangen vieler Aufgaben vermieden, Engpässe werden sichtbar und Aufgaben werden schneller fertig.

Erklärung: Der Sprint selbst ist ebenfalls ein Event, das Sprint-Ziel eine Verpflichtung zum Sprint Backlog. Prinzipien (z. B. „Änderungen sind willkommen“) statt Werte werden mit 0,5 P bewertet.

a) Events (6 P)

b) User Stories (4 P) – Beispiele

• „Als Pflegekraft möchte ich Leistungen auch ohne Mobilfunkempfang erfassen, damit ich in Orten ohne Netz nichts auf Papier nachtragen muss.“
• „Als Pflegekraft möchte ich die Navigation zur nächsten Adresse mit einem Fingertipp starten, damit ich ohne Suchen schnell zum nächsten Einsatz komme.“
• „Als Pflegedienstleitung möchte ich Einsätze per Drag & Drop einer anderen Tour zuweisen, damit ich Krankmeldungen am Morgen innerhalb von zehn Minuten umplanen kann.“
• „Als Pflegedienstleitung möchte ich jederzeit sehen, welche Einsätze erledigt sind, damit ich bei Verzögerungen rechtzeitig reagieren kann.“

Erklärung: Das Review betrifft das Produkt und findet mit Stakeholdern statt; die Retrospektive (nicht gefragt) betrifft die Zusammenarbeit im Team.

a) Wer schreibt, wer entscheidet? (2 P)

Jeder Projektbeteiligte darf User Stories schreiben – Entwickler, Tester, Designer und sogar Anwender (1 P). Über die Reihenfolge der Umsetzung entscheidet der Product Owner, der für das Product Backlog verantwortlich ist (1 P).

b) Die „three Cs“ (3 P)

• Card: der kurze, schriftliche Text der Story.
• Conversation: das Gespräch zwischen Product Owner, Entwicklern und Anwendern, in dem die Details geklärt werden.
• Confirmation: die Akzeptanzkriterien, mit denen geprüft wird, ob die Story richtig umgesetzt wurde.

c) Akzeptanzkriterien und Definition of Done (4 P)

Akzeptanzkriterien gehören zu genau einer Story und beschreiben das erwartete Verhalten aus Sicht des Anwenders (1 P). Die Definition of Done gilt für alle Backlog-Einträge gleichermaßen und beschreibt allgemeine Qualitätsanforderungen (Code geprüft, automatische Tests bestanden, auf dem Testsystem installiert) (1 P).

• Beispiel Akzeptanzkriterium (Story „Offline-Erfassung“): „Ohne Netz erfasste Leistungen bleiben gespeichert und erscheinen spätestens eine Minute nach Wiederherstellung der Verbindung im Webportal.“ (1 P)
• Beispiel DoD: „Code wurde von einer zweiten Entwicklerin geprüft, alle Unit-Tests sind grün, die neue App-Version ist auf den Testtablets installiert.“ (1 P)

d) INVEST-Prüfung (4 P) – zwei der folgenden

• Small: Die Story bündelt mehrere große Funktionen (Offline-Erfassung, Synchronisation, Benachrichtigung der Angehörigen) und passt nicht in einen Sprint – sie ist ein Epic.
• Testable: „schnell und benutzerfreundlich“ ist nicht messbar; es lassen sich keine prüfbaren Akzeptanzkriterien ableiten.
• Valuable: Der Nutzen („damit …“) fehlt, die Rolle „Benutzer“ ist unklar (Pflegekraft? PDL? Angehörige?) – der Wert für eine bestimmte Nutzergruppe ist nicht erkennbar.
• Estimable: Wegen Größe und vager Formulierung kann das Team den Aufwand nicht schätzen.
• Independent: Die Teile hängen voneinander ab (Synchronisation setzt Offline-Speicherung voraus) und lassen sich so nicht unabhängig planen.

e) Aufgeteilte Stories (4 P) – Beispiele

• „Als Pflegekraft möchte ich Leistungen ohne Mobilfunkempfang erfassen, damit ich auch in Funklöchern papierlos dokumentieren kann.“
  Akzeptanzkriterium: Bei fehlender Verbindung werden erfasste Leistungen verschlüsselt auf dem Tablet gespeichert und als „noch nicht übertragen“ gekennzeichnet.
• „Als Pflegedienstleitung möchte ich, dass offline erfasste Leistungen automatisch übertragen werden, sobald wieder Netz verfügbar ist, damit ich einen aktuellen Überblick über erledigte Einsätze habe.“
  Akzeptanzkriterium: Spätestens 60 Sekunden nach Wiederherstellung der Verbindung sind alle lokal gespeicherten Einträge auf dem Server; es entstehen keine doppelten Einträge.
• Auch richtig: eine Story für die Angehörigen-Information, wenn sie als eigene, kleine Story mit Rolle „Angehörige/r“ formuliert ist (fachlich gehört sie in Phase 2).

f) Schätzen laut Text (3 P)

Geschätzt wird in Story Points, nicht in Stunden; sie geben die Größe einer Story relativ zu anderen Stories an und berücksichtigen Aufwand, Komplexität und Unsicherheit (1 P). Das ganze Entwicklungsteam schätzt gemeinsam mit Planning Poker (1 P), damit unterschiedliche Sichtweisen früh diskutiert werden und ein gemeinsames Verständnis der Story entsteht (1 P).

Erklärung: In a) ist „nur der Product Owner schreibt Stories“ falsch – laut Text darf jeder schreiben, der PO ordnet. Bei englischen Texten werden die Antworten im Text gesucht; Vorwissen ist nur Hilfe zum Verstehen.

a) Unterschied (2 P)

Funktionale Anforderungen beschreiben, was das System leisten soll – seine Funktionen und sein Verhalten (1 P). Nicht-funktionale Anforderungen beschreiben, wie gut bzw. unter welchen Rahmenbedingungen es das tut – Qualitätseigenschaften wie Leistung, Sicherheit, Benutzbarkeit, Zuverlässigkeit sowie technische, rechtliche und organisatorische Vorgaben (1 P).

b) Zuordnung (3 P)

Erklärung: Nr. 4 beschreibt wie sicher Daten gespeichert werden – Sicherheitsanforderungen zählen nach IHK-Lösungen zu den nicht-funktionalen Anforderungen. Nr. 2 und 6 enthalten Messgrößen (3 Sekunden, 99,5 %), typisch für nicht-funktionale Anforderungen.

a) Zuordnung (3 P)

b) Ersteller und Bedeutung für die Abnahme (3 P)

Das Lastenheft hat der Auftraggeber, die Lindenhof Pflege gGmbH (Geschäftsführung und PDL), vor der Vergabe erstellt; es beschreibt die Anforderungen aus ihrer Sicht und war Grundlage für das Angebot (1 P). Das Pflichtenheft hat der Auftragnehmer, die Kranich Softwarehaus GmbH, auf Basis des Lastenhefts erstellt; es beschreibt, wie und womit die Anforderungen umgesetzt werden (1 P). Nachdem Lindenhof das Pflichtenheft bestätigt hat, ist es verbindliche Vertragsgrundlage: Bei der Abnahme wird geprüft, ob PflegeMobil die dort festgelegten Leistungen und Abnahmekriterien erfüllt; was nicht darin steht, ist eine Zusatzleistung (Change Request) (1 P).

c) Beobachtung im Vergleich zum Interview (4 P)

Vorteil: Die Beobachtung zeigt den tatsächlichen Arbeitsablauf unter echten Bedingungen – Arbeiten mit Handschuhen, Funklöcher, Zeitdruck zwischen den Einsätzen, Unterschrift in der Wohnung. Auch unbewusste Tätigkeiten und Umgehungslösungen werden sichtbar, die eine Pflegekraft im Interview gar nicht erwähnen würde (2 P).

Nachteil: hoher Zeitaufwand für wenig Breite – ein ganzer Tag ergibt die Sicht nur einer Pflegekraft an einem Standort; zudem ist eine fremde Person in den Wohnungen der Patienten anwesend (Privatsphäre, Einwilligung, Datenschutz), und die Pflegekraft verhält sich beobachtet evtl. anders (2 P).

Erklärung: Prüffrage für a): Beschreibt der Satz ein Ziel oder Bedürfnis des Kunden (Lastenheft) oder eine technische Entscheidung des Dienstleisters (Pflichtenheft)? Merkhilfe: Lastenheft vom Laien (Kunde) – Was?; Pflichtenheft vom Profi (Dienstleister) – Wie?

a) Funktionale Anforderungen (6 P) – drei der folgenden

• Tourenplanung: Die PDL kann im Webportal Einsätze per Drag & Drop Touren zuweisen und bei Krankmeldungen umplanen; die geänderte Tour erscheint auf dem Tablet der Pflegekraft.
• Leistungserfassung: Die Pflegekraft erfasst in der App die je Einsatz erbrachten Leistungen.
• Unterschrift: Patientin bzw. Patient unterschreibt den Leistungsnachweis auf dem Tablet.
• Navigation: Die App startet per Fingertipp die Navigation zur Adresse des nächsten Einsatzes.
• Statusübersicht: Das Portal zeigt der PDL, welche Einsätze erledigt sind.
• Änderungsprotokoll: Jede Änderung an der Dokumentation wird mit Benutzer, Zeitpunkt und Inhalt protokolliert.
• Monatsabschluss/Export: Das System prüft die Nachweise je Patient auf Vollständigkeit (fehlende Unterschriften) und übergibt sie im XML-Format der CareBill-Importschnittstelle.
• Fernsperrung: Ein verlorenes Tablet kann zentral gesperrt und gelöscht werden.

b) Nicht-funktionale Anforderungen, messbar (6 P) – drei der folgenden

• Zuverlässigkeit / Offline-Fähigkeit: „Erfassung und Unterschrift funktionieren ohne Netzverbindung vollständig; offline gespeicherte Daten werden nach Wiederverbindung innerhalb von 60 Sekunden ohne Datenverlust übertragen.“
• Benutzbarkeit (Handschuhe): „Alle Schaltflächen der Erfassungsmaske sind mindestens 15 × 15 mm groß.“
• Effizienz der Bedienung: „Eine Standardleistung lässt sich mit höchstens drei Fingertipps erfassen; im Usability-Test benötigen 9 von 10 Pflegekräften nicht länger als mit dem Papierformular.“
• Sicherheit / Zugriffsschutz: „Eine Pflegekraft kann ausschließlich die Daten der Patienten ihrer eigenen Tour des Tages abrufen (Rollen- und Rechtekonzept, im Test mit fremder Tour geprüft).“
• Nachvollziehbarkeit / Revisionssicherheit: „Änderungen an Dokumentationseinträgen werden mit Benutzer, Zeitstempel sowie altem und neuem Wert protokolliert; Protokolleinträge können nicht gelöscht werden.“
• Kompatibilität: „Die App läuft auf den beiden jeweils neuesten Android-Hauptversionen.“
• Leistung: „Eine Umplanung im Webportal ist nach höchstens 2 Sekunden gespeichert und spätestens nach einer Minute auf dem Tablet sichtbar (bei Netzverbindung).“

c) MoSCoW (4 P)

Begründung (3): Das Angehörigenportal ist ausdrücklich für Phase 2 vorgesehen (Anlage 1 und Notiz der Geschäftsführung in Anlage 3). Es wird in diesem Release bewusst nicht umgesetzt („Won’t have this time“), damit Budget und Go-Live-Termin für die zwingenden Funktionen gesichert sind.

d) „schnell und einfach“ (2 P)

Die Formulierung enthält keine Messgröße und keinen Grenzwert; „schnell“ und „einfach“ sind subjektiv. Bei der Abnahme lässt sich nicht objektiv entscheiden, ob die Anforderung erfüllt ist – das führt zu Streit zwischen Auftraggeber und Auftragnehmer. Außerdem werden zwei Anforderungen vermischt. Besser: z. B. „Start der App in höchstens 3 Sekunden“ und „Erfassung mit höchstens drei Fingertipps“.

Erklärung: Typischer Fehler in b): eine messbare Formulierung ohne Zahl („möglichst große Schaltflächen“). Ob „nur eigene Patienten sehen“ als funktional (Anzeige der eigenen Tour) oder nicht-funktional (Zugriffsschutz) gezählt wird, hängt von der Formulierung ab – beides wird akzeptiert, aber nicht doppelt.

a) Risiko und Problem (2 P)

Ein Risiko ist ein mögliches, zukünftiges Ereignis, das nur mit einer gewissen Wahrscheinlichkeit eintritt und dann die Projektziele gefährdet (1 P). Ein Problem ist bereits eingetreten und muss sofort behandelt werden (1 P). Beispiel: Ein möglicher Lieferengpass bei den Tablets (R2) ist ein Risiko; sagt der Lieferant die Lieferung tatsächlich ab, ist es ein Problem.

b) Strategien (4 P)

Erklärung: Vermindern kann an der Wahrscheinlichkeit oder am Schaden ansetzen; Verschlüsselung verhindert den Verlust nicht, begrenzt aber den Schaden.

a) Risikowerte und Rang (3 P)

R4 und R7 teilen sich Rang 4 (auch „4 und 5“ ist richtig).

b) Risikomatrix (3 P)

Sofort Maßnahmen erforderlich (RW ≥ 12): R3 (16), R5 (15) und R1 (12).

c) Gegenmaßnahmen (4 P)

• R3 – fehlender Empfang / Synchronisationskonflikte: Die App wird „offline-first“ entwickelt: alle Daten werden lokal verschlüsselt gespeichert und später mit Konflikterkennung (Zeitstempel/Versionsnummer, nichts wird stillschweigend überschrieben) synchronisiert; Test genau in den bekannten Funklöchern während des Pilots. Strategie: vermindern.
• R5 – Betriebsvereinbarung nicht rechtzeitig: Betriebsrat sofort einbinden und den Entwurf gemeinsam erarbeiten (Zweckbindung, keine Leistungskontrolle); Meilenstein „Betriebsvereinbarung unterzeichnet“ vor den Pilotstart legen, regelmäßige Termine. Strategie: vermindern (ein Pilot ohne Vereinbarung wird zusätzlich vermieden).

Erklärung: Die Schwelle „≥ 12“ stammt aus Anlage 5 – R4 und R7 haben zwar das höchste Schadensausmaß (5), wegen der geringen Wahrscheinlichkeit aber nur RW 10.

a) Problem → Risiko → Gegenmaßnahme (8 P)

b) Zwei weitere Risiken (6 P) – Beispiele

c) Subunternehmer (2 P)

Strategie: Übertragen (Risikotransfer) (1 P). Neues Risiko, z. B.: Abhängigkeit vom Subunternehmer (Terminverzug, schlechte Qualität, Insolvenz), fehlendes eigenes Know-how für Wartung und Fehlerbehebung, Abstimmungs- und Schnittstellenprobleme, zusätzlicher Datenschutzaufwand (Auftragsverarbeitung) (1 P).

d) Regelmäßige Wiederholung (2 P)

Risiken verändern sich im Projektverlauf: neue Risiken kommen hinzu (z. B. durch Change Requests oder Erkenntnisse aus dem Pilot), Eintrittswahrscheinlichkeiten und Schäden ändern sich (R1 entfällt, sobald die Testumgebung bereitsteht), und die Wirkung der Maßnahmen muss überprüft werden. Nur mit einer aktuellen Risikoliste kann rechtzeitig gegengesteuert werden.

Erklärung: In a) ist das Problem schon da – das Risiko ist die mögliche Folge für das Projekt. „Die PDL hat keine Zeit“ noch einmal als Risiko hinzuschreiben, bringt keine Punkte.

a) Kategorien (2 P)

Klassische (sequenzielle, plangetriebene) Vorgehensmodelle, z. B. Wasserfallmodell oder V-Modell (1 P); agile (iterativ-inkrementelle) Vorgehensmodelle, z. B. Scrum oder Kanban (1 P).

b) V-Modell (4 P)

Erklärung: Je „höher“ die Teststufe, desto gröber die Entwurfsstufe, gegen die geprüft wird. Der Abnahmetest validiert gegen die Anforderungen des Kunden.

a) Horizontal und vertikal (4 P)

Ein horizontaler Prototyp bildet eine Schicht des Systems – meist die Benutzungsoberfläche – in der Breite ab (viele oder alle Masken), ohne dahinterliegende Logik und Datenhaltung. Er dient dazu, Bedienung und Abläufe mit den Anwendern abzustimmen (2 P).

Ein vertikaler Prototyp realisiert einen schmalen, ausgewählten Funktionsausschnitt vollständig durch alle Schichten (Oberfläche, Logik, Datenhaltung, Schnittstellen). Er dient dazu, die technische Machbarkeit zu prüfen (2 P).

b) Eignung (4 P)

• Leistungserfassung mit Pflegekräften testen → horizontaler Prototyp (z. B. Klick-Dummy auf dem Tablet): Es geht um Bedienung – Größe der Schaltflächen mit Handschuhen, Zahl der Schritte, Erfassungsdauer im Vergleich zum Papier. Logik ist dafür nicht nötig; der Prototyp ist schnell erstellt und leicht änderbar (2 P).
• Offline-Speicherung und Synchronisation prüfen → vertikaler Prototyp („Durchstich“): Eine Leistung wird in der App erfasst, lokal gespeichert, nach Wiederverbindung synchronisiert und in der Server-Datenbank abgelegt. Nur so lassen sich Konflikte, Datenverlust und Verhalten bei Netzabbruch über alle Schichten testen (2 P).

c) Risiken des Prototypings (2 P) – zwei der folgenden

• Auftraggeber oder Nutzer halten den Prototyp für fast fertig → falsche Erwartungen an Termin und Kosten.
• Zusätzlicher Aufwand und zusätzliche Kosten.
• Wegwerf-Code wird aus Zeitdruck ins Produkt übernommen → schlechte Qualität und Wartbarkeit.
• Nicht-funktionale Anforderungen (Performance, Sicherheit) und Dokumentation werden vernachlässigt.

Erklärung: Der horizontale Prototyp für die Oberfläche ist typischerweise ein Wegwerf-Prototyp; der vertikale Durchstich kann evolutionär weiterentwickelt werden, wenn er sauber programmiert ist.

a) Klassisch und agil (8 P)

b) Begründung mit der Stacey-Matrix (6 P)

App und Webportal: Die Anforderungen der Pflegekräfte und der PDL sind zu Beginn noch unklar und ändern sich beim Ausprobieren (Bedienung mit Handschuhen, Erfassungsablauf, Darstellung der Tour); technisch ist die Offline-Synchronisation für das Team teilweise Neuland. Das Vorhaben liegt damit im Bereich „komplex“ → agiles Vorgehen mit kurzen Sprints und regelmäßigem Feedback (3 P).

CareBill-Schnittstelle: Die Anforderungen sind klar und stabil (festes XML-Format der Importschnittstelle, bekannte Abrechnungsregeln), die Technik ist bekannt (XML-Export). Das Vorhaben liegt im Bereich „einfach“ bzw. „kompliziert“ → gut im Voraus planbar, klassisches Vorgehen (z. B. V-Modell mit festgelegten Teststufen). Zusätzlich verlangt die Abhängigkeit vom Hersteller (Testumgebung mit sechs Wochen Vorlauf) eine verbindliche Terminplanung (3 P).

c) Nachteile des Wasserfallmodells (4 P) – zwei der folgenden

• Die Anforderungen der Pflegekräfte hätten zu Beginn vollständig feststehen müssen, obwohl sie sich erst beim Ausprobieren ergeben → Gefahr, an den Bedürfnissen vorbei zu entwickeln.
• Lauffähige Software gibt es erst spät; Fehler (z. B. Synchronisationsprobleme in Funklöchern) würden erst in der Testphase kurz vor dem Go-Live entdeckt → teure Nacharbeit, Terminrisiko.
• Erkenntnisse aus dem Pilotbetrieb ließen sich nur schwer und teuer einarbeiten.
• Die Nutzer wären kaum beteiligt → geringere Akzeptanz bei der Einführung.

d) Spiralmodell (2 P)

Das Spiralmodell ist ein iteratives, risikogetriebenes Vorgehen: Das Projekt durchläuft mehrere Zyklen (1 P), und in jedem Zyklus werden vor der Entwicklung zuerst die größten Risiken analysiert und z. B. durch Prototypen reduziert (Ziele festlegen → Risiken analysieren → entwickeln und testen → nächsten Zyklus planen) (1 P).

Erklärung: Gute Antworten in a) bleiben nicht allgemein („agil ist flexibel“), sondern sagen, was in PflegeMobil konkret passiert – z. B. dass Pilot-Erkenntnisse im nächsten Sprint umgesetzt werden können.

a) Gründe für Ablehnung (2 P) – vier der folgenden

Angst vor Arbeitsplatzverlust · Angst vor Überforderung durch neue Technik · Angst vor Überwachung/Leistungskontrolle · Mehrarbeit während der Umstellung · Gewohnheit („Es hat doch immer funktioniert“) · Verlust von Kompetenz oder Status · fehlende Information, Unsicherheit · schlechte Erfahrungen mit früheren Einführungen · Nutzen nicht erkennbar.

b) Maßnahmen zur Akzeptanzförderung (2 P) – vier der folgenden

frühzeitige, offene Information · Beteiligung der Betroffenen (Workshops, Key-User, Feedback zu Prototypen) · Schulungen · Ansprechpartner und Support · Pilotphase mit Freiwilligen · Einbindung des Betriebsrats, Betriebsvereinbarung · Nutzen aufzeigen, schnelle Erfolge sichtbar machen · Zusagen zur Arbeitsplatzsicherheit · Feedbackkanal.

Erklärung: „Nennen“ verlangt nur Stichworte; Erläuterungen bringen keine Zusatzpunkte.

a) Befürchtungen und Maßnahmen (6 P)

b) Konflikt mit Frau Lange (4 P)

• Frühzeitiges persönliches Gespräch mit Geschäftsführung bzw. Projektleitung: Sorge ernst nehmen, Ziele und Gründe erklären.
• Verbindliche Zusage der Geschäftsführung, dass niemand entlassen wird (Anlage 7).
• Neue Aufgaben aufzeigen: Kontrolle und Korrektur der Nachweise bleiben (ca. 20 Stunden pro Monat), dazu Klärung mit den Pflegekassen, Bearbeitung abgelehnter Abrechnungen.
• Ins Projekt einbinden: Ihr Wissen über die Abrechnungsregeln ist für Plausibilitätsprüfung, Testfälle und Abnahme der CareBill-Schnittstelle unverzichtbar – z. B. als Key-Userin; Qualifizierung für die neuen Aufgaben.

Erklärung: Konfliktlösung bedeutet hier nicht, Frau Lange zu „überzeugen“, sondern ihre berechtigte Sorge durch Zusagen und eine neue, wertgeschätzte Rolle aufzulösen (Win-win).

a) Ziele des Workshops (6 P) – drei der folgenden

• Informieren und Gerüchte ausräumen: Was die Spracheingabe kann und was nicht (Aufnahme nur auf Knopfdruck, kein Dauermithören; die KI schlägt vor, die Pflegekraft entscheidet und gibt frei), warum sie geplant ist (weniger Schreibarbeit).
• Befürchtungen und Erwartungen sammeln (z. B. Kartenabfrage) und ernst nehmen: Überwachung, Datenschutz in den Wohnungen, Fehlerkennung, Arbeitsverdichtung.
• Beteiligung: Pflegekräfte gestalten Regeln und Anforderungen mit und melden sich freiwillig für die Pilotgruppe.
• Befürworter, Unentschlossene und Gegner erkennen; Befürworter als Multiplikatoren stärken.
• Nutzen und Status quo bewusst machen: heutiger Dokumentationsaufwand, erwartete Entlastung.
• Vereinbarungen festhalten: nächste Schritte, Pilot, Feedbackkanal, Termin für die Auswertung.

b) Vorteile der Pilotgruppe (4 P) – zwei der folgenden

• Erprobung unter echten Bedingungen (Fernseher und Angehörige im Raum, Fachbegriffe, Funklöcher) bei begrenztem Risiko: Probleme werden erkannt und behoben, bevor alle betroffen sind.
• Messbare Entscheidungsgrundlage: tatsächliche Erkennungsrate (≥ 90 %?) und Zeitersparnis werden ermittelt; ein Abbruch ist ohne großen Schaden möglich.
• Akzeptanz: Die Pilotteilnehmenden werden zu Fürsprechern und berichten Kolleginnen und Kollegen aus erster Hand.
• Geringe Kosten in der Erprobungsphase (wenige Lizenzen, kleiner Schulungsaufwand).

c) Betriebsrat (4 P)

Die Spracheingabe ist eine technische Einrichtung, die dazu geeignet ist, Verhalten oder Leistung der Beschäftigten zu überwachen (Aufnahmen, Zeitpunkte, Dauer). Dafür hat der Betriebsrat ein Mitbestimmungsrecht (§ 87 Abs. 1 Nr. 6 BetrVG) – ohne seine Zustimmung darf sie nicht eingeführt werden; die bestehende Betriebsvereinbarung muss erweitert werden (2 P). Mögliche Regelungen (je 1 P):

• Zweckbindung: Nutzung nur für die Pflegedokumentation, Verbot der Auswertung zur Leistungs- oder Verhaltenskontrolle.
• Aufnahme nur nach aktivem Auslösen durch die Pflegekraft; Audiodaten werden nach der Umwandlung in Text sofort gelöscht.
• Zugriffsrechte und Speicherort (nur EU); Löschfristen.
• Freiwilligkeit bzw. Tastatureingabe bleibt als Alternative; Regeln für die Pilotphase.

Erklärung: Entscheidend ist die Eignung zur Überwachung – ob der Arbeitgeber tatsächlich überwachen will, spielt für die Mitbestimmung keine Rolle.

a) Kostenarten (4 P) – Beispiele

b) Make-or-Buy (2 P)

Entscheidung, ob eine Leistung selbst erstellt („Make“, Eigenentwicklung) oder von außen bezogen wird („Buy“, Kauf von Standardsoftware oder einer Komponente bzw. Fremdvergabe an einen Dienstleister) (1 P). Entschieden wird anhand von Kriterien wie Kosten, Zeit, eigenem Know-how, Abhängigkeit und Anpassbarkeit – in PflegeMobil z. B. beim Modul „automatische Tourenvorschläge“ (1 P).

Erklärung: Kostenarten sind Oberbegriffe (Personal-, Sach-, Lizenzkosten …), Beispiele sind die konkreten Posten aus der Situation.

a) Festpreis Kranich (4 P)

b) Einmalige Gesamtkosten (4 P)

Das Budget von 420.000 € wird eingehalten; es bleibt eine Reserve von 52.776 € (ca. 12,6 %).

c) Laufende Kosten pro Jahr (2 P)

MDM 120 × 3 € × 12 = 4.320 € · Mobilfunk 120 × 8 € × 12 = 11.520 € · Hosting 450 € × 12 = 5.400 € · CareBill-Wartung 900 € · Wartungsvertrag 1.800 € × 12 = 21.600 € → 43.740 € pro Jahr.

Erklärung: Häufige Fehler: Arbeitszeit der Pflegekräfte in der Schulung vergessen (sie kostet Geld, auch wenn keine Rechnung kommt), laufende Kosten in die einmaligen Kosten mischen oder monatliche Beträge nicht auf das Jahr hochrechnen.

a) Zukauf statt Eigenentwicklung (4 P)

Vorteile (zwei der folgenden): schneller einsatzbereit (6 bzw. 4 Wochen statt ca. 4 Monate) · geringere Gesamtkosten über fünf Jahre · erprobte Lösung mit Spezialwissen des Anbieters zur Routenoptimierung, das Kranich fehlt → geringeres technisches Risiko · Wartung und Weiterentwicklung durch den Anbieter · eigene Entwickler bleiben frei für die Kernfunktionen.

Nachteile (zwei der folgenden): Abhängigkeit vom Anbieter (Preiserhöhungen, Produkteinstellung) · eingeschränkte Anpassbarkeit an Besonderheiten der Pflege (feste Zeitfenster, möglichst dieselbe Pflegekraft) · laufende Lizenz- bzw. Abokosten · bei Variante C Datenschutzproblem: Patientenadressen werden auf Server in den USA übertragen · Know-how bleibt beim Anbieter.

b) Gesamtkosten über fünf Jahre (4 P)

c) Nutzwertanalyse (6 P)

Mit Gewichten als ganze Zahlen (30 × 3 = 90 …) ergeben sich 660 / 755 / 530 – ebenfalls richtig.

d) Empfehlung (4 P)

Empfohlen wird Variante B (RouteMaster SDK): Sie hat den höchsten Nutzwert (7,55) und die geringsten Gesamtkosten über fünf Jahre (43.700 €). Die Daten bleiben auf dem eigenen Server im EU-Rechenzentrum, und mit ca. sechs Wochen ist das Modul rechtzeitig vor dem Go-Live einsatzbereit. Variante C scheidet trotz niedriger Kosten praktisch aus, weil Patientenadressen in die USA übertragen würden; Variante A ist am teuersten und langsamsten, und dem Team fehlt das Know-how (2 P).

Schwäche der Nutzwertanalyse: Gewichte und Punkte sind subjektiv – mit anderen Gewichten (z. B. Kosten nur 15 %, Unabhängigkeit 30 %) läge A mit 7,65 vor B mit 6,95; die Zahlen täuschen eine Genauigkeit vor, die es nicht gibt. Außerdem kann ein schwerer Mangel (Datenschutzverstoß bei C) durch gute Werte bei anderen Kriterien „ausgeglichen“ werden – deshalb sollten K.-o.-Kriterien vorher geprüft werden (2 P).

Erklärung: Kosten- und Nutzwertvergleich zeigen hier in dieselbe Richtung. Interessant wird es, wenn sie sich widersprechen – dann muss die Empfehlung abwägen.

a) Vollständiger Netzplan (4 P)

Ergänzte Werte: Vorgang 1 FP = 0 · Vorgang 3 FEZ = 7, SAZ = 9, SEZ = 12, GP = 5, FP = 0 · Vorgang 4 FAZ = 7, FEZ = 9, SAZ = 12, SEZ = 14, GP = 5, FP = 5 · Vorgang 5 SAZ = 14, SEZ = 18, GP = 0, FP = 0.

Rechenweg (Auszug): FEZ(3) = 4 + 3 = 7 · FAZ(4) = FEZ(3) = 7 → FEZ(4) = 9 · Rückwärts: SEZ(4) = SAZ(5) = 14 → SAZ(4) = 12 · SEZ(3) = SAZ(4) = 12 → SAZ(3) = 9 · GP(3) = 9 − 4 = 5 · FP(3) = FAZ(4) − FEZ(3) = 7 − 7 = 0 · FP(4) = FAZ(5) − FEZ(4) = 14 − 9 = 5.

b) Kritischer Pfad und Dauer (2 P)

Kritischer Pfad: 1 → 2 → 5; Dauer: 18 Tage.

Erklärung: Vorgang 3 hat 5 Tage Gesamtpuffer, aber keinen freien Puffer: Verzögert er sich, beginnt Vorgang 4 sofort später. Erst Vorgang 4 „besitzt“ den Puffer bis zum Start von Vorgang 5. Die 18 Tage passen zur Dauer von Vorgang B im Rollout-Netzplan (PM-08.3).

a) Netzplan (7 P)

Vorwärts: G hat drei Vorgänger → FAZ(G) = max(FEZ D = 17; FEZ E = 13; FEZ F = 14) = 17. Rückwärts: B hat zwei Nachfolger → SEZ(B) = min(SAZ D = 7; SAZ E = 11) = 7; A: SEZ(A) = min(SAZ B = 4; SAZ C = 7) = 4.

b) Kritischer Pfad und Dauer (2 P)

Kritischer Pfad: A → B → D → G → H; Dauer des Teilprojekts: 24 Arbeitstage.

c) Testumgebung dauert 12 statt 8 Tage (3 P)

C hat einen Gesamtpuffer von 3 Tagen. Die Verlängerung um 4 Tage übersteigt den Puffer um 1 Tag → das Teilprojekt endet einen Tag später, nach 25 Tagen. C wird kritisch; der neue kritische Pfad ist A → C → F → G → H (C: 4 → 16, F: 16 → 18, G: 18 → 23, H: 23 → 25). B und D haben nun je 1 Tag Gesamtpuffer.

Erklärung: Typischer Fehler in c): „C ist nicht kritisch, also keine Auswirkung“. Ein nicht kritischer Vorgang verschiebt das Ende sehr wohl, sobald die Verzögerung seinen Gesamtpuffer übersteigt.

a) Erweiterter Netzplan (14 P)

Vorgangsliste aus dem Text: A (5, –) · B (18, A) · C (6, A) · D (12, A) · E (4, C) · F (10, B und D) · G (6, F) · H (8, E und G) · I (5, G) · J (2, H und I).

Wichtige Rechenschritte: FAZ(F) = max(FEZ B = 23; FEZ D = 17) = 23 · FAZ(H) = max(FEZ E = 15; FEZ G = 39) = 39 · FAZ(J) = max(FEZ H = 47; FEZ I = 44) = 47 · SEZ(G) = min(SAZ H = 39; SAZ I = 42) = 39 · SEZ(A) = min(SAZ B = 5; SAZ C = 29; SAZ D = 11) = 5.

b) Kritischer Pfad und Gesamtdauer (3 P)

Kritischer Pfad: A → B → F → G → H → J; Gesamtdauer: 49 Arbeitstage.

c) Freier Puffer und Gesamtpuffer am Beispiel C (2 P)

Der Gesamtpuffer ist die Zeit, um die ein Vorgang verschoben oder verlängert werden kann, ohne dass sich das Projektende verschiebt. Der freie Puffer ist die Zeit, um die er sich verschieben kann, ohne dass sich der früheste Anfang eines Nachfolgers verschiebt. C (Schulungskonzept) hat GP = 24 Tage: Er könnte bis zu 24 Tage später fertig werden, ohne den Go-Live zu gefährden. Sein FP ist aber 0: Jede Verzögerung verschiebt sofort den frühesten Beginn von E (Schulungsunterlagen), weil E direkt anschließt – der Puffer liegt „hinter“ E.

d) Verzögerungen (4 P)

• (1) D + 4 Tage: D hat GP = FP = 6 Tage. D endet dann am Tag 21 statt 17; F kann trotzdem erst am Tag 23 beginnen (wegen B). → keine Auswirkung, Ende bleibt Tag 49.
• (2) I + 5 Tage: I hat nur GP = 3 Tage. I endet am Tag 49 statt 44; J kann erst am Tag 49 statt 47 beginnen. → Das Teilprojekt endet 2 Tage später, am Tag 51; I wird kritisch (neuer kritischer Pfad A → B → F → G → I → J).

Erklärung: Die häufigsten Fehler: E als Vorgänger von F statt von H eintragen (die Schulungsunterlagen werden erst für die Schulung gebraucht) und bei H das Maximum vergessen. Wer den Text zuerst in eine Vorgangsliste übersetzt, vermeidet beides.

a) Zeitpunkt und Ziel (2 P)

Die Machbarkeitsanalyse findet vor dem eigentlichen Projektstart statt, in der Initialisierungsphase bzw. vor dem Projektauftrag oder der Vergabe (1 P). Sie prüft, ob das Vorhaben unter den gegebenen Rahmenbedingungen realisierbar und sinnvoll ist, und liefert eine Entscheidungsgrundlage (durchführen, anpassen, verwerfen), damit keine Fehlinvestition entsteht (1 P).

b) Kriterien (2 P) – vier der folgenden

technische · wirtschaftliche · rechtliche · organisatorische bzw. personelle · zeitliche Machbarkeit (auch: ökologische).

Erklärung: Die Machbarkeitsanalyse beantwortet „Können und sollen wir das?“, die Risikoanalyse im laufenden Projekt „Was kann schiefgehen?“.

Zwei der folgenden Kriterien, jeweils benannt und am Projekt erläutert:

• Technische Machbarkeit: Lässt sich das Vorhaben mit verfügbarer Technik und vorhandenem Know-how umsetzen? Für PflegeMobil: Kann eine App offline Daten erfassen und später konfliktfrei synchronisieren (viele Funklöcher im Landkreis)? Bietet CareBill eine Importschnittstelle (XML), die angebunden werden kann? Gibt es geeignete Tablets und eine zentrale Geräteverwaltung? Hat Kranich Erfahrung mit Android und Synchronisation?
• Wirtschaftliche Machbarkeit: Stehen Kosten und Nutzen in einem sinnvollen Verhältnis, ist das Projekt finanzierbar? Für PflegeMobil: einmalige Kosten (Entwicklung, 120 Tablets, Lizenzen, Schulung) und laufende Kosten gegenüber Zeitersparnis bei Dokumentation und Verwaltung, schnellerer Abrechnung und weniger nicht abrechenbaren Leistungen; Einhaltung des Budgets von 420.000 €; Amortisation.
• Rechtliche Machbarkeit: Ist das Vorhaben rechtlich zulässig? Für PflegeMobil: Gesundheitsdaten (Art. 9 DSGVO) – Datenschutz-Folgenabschätzung, Hosting in der EU, Verschlüsselung, Rechtekonzept; Mitbestimmung des Betriebsrats; Anforderungen an die Dokumentation bei Prüfungen durch den Medizinischen Dienst und an die Abrechnung mit den Pflegekassen; Anerkennung der Unterschrift auf dem Tablet.
• Organisatorische / personelle Machbarkeit: Passt das Vorhaben zu Personal und Abläufen? Für PflegeMobil: Können 118 Pflegekräfte, teils ohne Tablet-Erfahrung, rechtzeitig geschult werden? Reicht ein Teilzeit-Administrator für 120 Tablets? Hat die PDL Zeit für die Projektarbeit? Wie hoch ist die Akzeptanz?
• Zeitliche Machbarkeit: Ist der Termin realistisch? Für PflegeMobil: Go-Live 01.11.2027 trotz Lieferzeit der Tablets, sechs Wochen Vorlauf für die CareBill-Testumgebung und notwendiger Betriebsvereinbarung vor dem Pilot?

Erklärung: Das entspricht genau dem Aufgabentyp aus W25 T1 A1a. Der Projektbezug bringt die Hälfte der Punkte – Fakten aus der Ausgangssituation nutzen.

a) Prüfung der Varianten (8 P)

b) Empfehlung (4 P)

Die Spracheingabe sollte in der geplanten Form nicht umgesetzt werden: Variante 1 scheitert rechtlich (US-Server für Gesundheitsdaten) und ist in Funklöchern nicht nutzbar; Variante 2 scheitert am Budget, an der Hardware, an der zu geringen Erkennungsrate und am Termin. Empfehlung an die Geschäftsführerin: Phase 2 zunächst ohne Spracheingabe abschließen und die Spracheingabe mit Änderungen neu prüfen – z. B. einen Anbieter mit Servern in der EU suchen, Diktate offline zwischenspeichern und bei Netz übertragen, vorab einen Pilot mit zehn Freiwilligen durchführen, die Betriebsvereinbarung erweitern und den Termin auf Ende 2028 verschieben.

Erklärung: Eine Machbarkeitsanalyse endet nicht mit „ja/nein“ je Kriterium, sondern mit einer Gesamtempfehlung. Ein einziges „nicht machbar“ in einem K.-o.-Bereich (Recht) reicht, um eine Variante in der vorliegenden Form zu stoppen.

a) Unterschied (2 P)

Quantitativer Nutzen lässt sich in Zahlen bzw. Geld messen, z. B. eingesparte Stunden oder Euro (1 P). Qualitativer Nutzen lässt sich nicht oder nur schwer in Zahlen ausdrücken und wird beschrieben, z. B. Zufriedenheit oder Image (1 P).

b) Beispiele (2 P)

Quantitativ: 1,5 Minuten weniger Dokumentation je Einsatz (rund 6.500 Stunden pro Jahr); 7.800 € pro Jahr weniger Druck- und Papierkosten; 4 % weniger gefahrene Kilometer. Qualitativ: zufriedenere Pflegekräfte (kein Nachtragen am Wochenende); bessere, prüfsichere Dokumentation; attraktiverer Arbeitgeber; mehr Transparenz für die PDL.

Erklärung: Ein qualitativer Nutzen kann manchmal nachträglich gemessen werden (z. B. per Umfrage) – entscheidend ist, dass er sich nicht direkt in Geld ausdrücken lässt.

Erklärung: Wie in S24 zählt die Perspektive: Derselbe Effekt (schnellere Abrechnung) ist für die Verwaltung Arbeitserleichterung und für die Geschäftsführung Liquidität.

a) Jährlicher quantitativer Nutzen (6 P)

b) Amortisationsdauer (3 P)

Jährlicher Rückfluss = 265.000 € − 43.740 € = 221.260 € · Amortisationsdauer = 367.224 € ÷ 221.260 € pro Jahr ≈ 1,66 Jahre (ca. 1 Jahr und 8 Monate).

Mit den Ersatzwerten: (265.000 € − 45.000 €) = 220.000 € · 360.000 € ÷ 220.000 € ≈ 1,64 Jahre.

c) Nur zahlungswirksame Effekte (4 P)

Mehrerlös durch weniger nicht abrechenbare Leistungen: 9.500.000 € × (0,8 % − 0,2 %) = 57.000 € · Zahlungswirksamer Nutzen = 10.200 € + 13.200 € + 57.000 € = 80.400 € · Rückfluss = 80.400 € − 43.740 € = 36.660 € pro Jahr · Amortisationsdauer = 367.224 € ÷ 36.660 € ≈ 10,0 Jahre (Ersatzwerte: 35.400 €; 360.000 € ÷ 35.400 € ≈ 10,2 Jahre).

Beurteilung: Rein finanziell amortisiert sich das Projekt erst nach etwa zehn Jahren – deutlich länger als die übliche Nutzungsdauer von Tablets (3–5 Jahre) und Software. Der große Nutzen aus a) besteht vor allem aus gewonnener Arbeitszeit (6.500 Stunden, rund vier Vollzeitstellen), die nicht automatisch Geld spart, weil niemand entlassen wird. Wirtschaftlich wird sie erst, wenn sie genutzt wird – für zusätzliche abrechenbare Einsätze, weniger Überstunden und Aushilfen oder als Entlastung im Fachkräftemangel. Die Entscheidung sollte daher nicht allein an der Amortisationsdauer hängen, sondern auch die qualitativen Nutzen einbeziehen.

d) Qualitative Nutzen (3 P) – drei der folgenden

• bessere Dokumentationsqualität und Rechtssicherheit bei Prüfungen durch den Medizinischen Dienst
• Entlastung und Zufriedenheit der Pflegekräfte → attraktiver Arbeitgeber, geringere Fluktuation
• mehr Zeit für die Patienten → höhere Pflegequalität und Patientenzufriedenheit
• Transparenz und bessere Steuerung durch die Echtzeitübersicht der PDL
• besserer Datenschutz (verschlüsselte Daten statt Papierakten im Auto)
• Nachhaltigkeit (papierlos) und modernes Image

Erklärung: Die zweite Rechnung ist der Kern der Aufgabe: Eine ehrliche Projektbegründung trennt zahlungswirksame von kalkulatorischen Einsparungen. Wer die laufenden Kosten vergisst, kommt auf zu kurze Amortisationszeiten (1,39 bzw. 4,6 Jahre).