Block 12 · Querschnitt – Lösungen

a) Unterschiede zu Scrum (2 P)

Zwei der folgenden (Text, Absatz 1):

• Kanban schreibt keine Iterationen fester Länge (Sprints) vor.
• Kanban legt keine bestimmten Rollen fest (wie Product Owner oder Scrum Master).
• Kanban kennt kein Sprint Backlog.
• Kanban beginnt mit dem bestehenden Prozess des Teams und verbessert ihn schrittweise, statt ein neues Rahmenwerk einzuführen.

b) WIP-Limit (2 P)

Ein WIP-Limit (work in progress) legt fest, wie viele Karten bzw. Aufgaben sich höchstens gleichzeitig in einer Spalte des Kanban-Boards befinden dürfen. Ist das Limit erreicht, darf niemand neue Arbeit in die Spalte ziehen; stattdessen hilft das Team, die angefangenen Aufgaben fertigzustellen. Laut Text verringert das die Kontextwechsel, macht Engpässe sichtbar und verkürzt die Zeit, die eine Aufgabe vom Start bis zur Fertigstellung braucht – auch wenn es sich anfangs langsamer anfühlt.

c) Lead time und cycle time (2 P)

Lead time (Durchlaufzeit) ist die Zeit von der Annahme einer Anfrage bis zur Auslieferung an den Kunden, einschließlich aller Wartezeiten. Cycle time (Bearbeitungszeit) umfasst nur den Zeitraum, in dem das Team aktiv an der Aufgabe arbeitet. Die lead time ist daher immer mindestens so lang wie die cycle time.

Erklärung: Die Antwort auf c) steckt in einem Satz mit dem Signalwort whereas (Gegensatz). In a) zählt nur, was im Text steht; „Kanban hat keine Meetings“ steht dort nicht und wäre auch falsch.

a) Synchrone und asynchrone Replikation (4 P)

b) Einsatzzwecke (2 P)

• Verfügbarkeit erhöhen: Fällt der Primärserver aus, wird ein Replikat zum neuen Primärserver (Failover), bei vielen Cloud-Anbietern automatisch in ein bis zwei Minuten.
• Leistung verbessern: Lesereplikate übernehmen reine Leseabfragen wie Berichte oder Produktsuchen und entlasten so den Primärserver.

c) Stellungnahme zum Verzicht auf die Datensicherung (2 P)

Der Vorschlag ist abzulehnen. Laut Text ist Replikation keine Datensicherung: Löscht jemand versehentlich eine Tabelle, wird der DELETE-Befehl innerhalb von Sekunden auf alle Replikate übertragen, die Daten sind dann überall weg. Nur eine Sicherung, mit der man auf einen früheren Zeitpunkt zurückgehen kann (point-in-time backup), schützt davor. Die nächtliche Sicherung muss also bleiben.

d) Problem bei asynchroner Replikation (2 P)

Problem: Eine Kundin ändert z. B. ihre Lieferadresse und lädt die Seite sofort neu. Die Leseanfrage landet auf einem Replikat, das die Änderung noch nicht erhalten hat, und sie sieht die alte Adresse (veraltete Daten). Ebenso kann beim Bezahlen ein veralteter Lagerbestand angezeigt werden: Eine Pflanze erscheint noch als verfügbar, obwohl sie gerade verkauft wurde.
Lösung laut Text: Leseanfragen, die aktuell sein müssen (eigene gerade gespeicherte Änderungen, Lagerbestand im Bestellvorgang), werden an den Primärserver geschickt („read-your-writes“-Konsistenz).

Erklärung: Die Fangfrage steckt in c): Viele verwechseln Replikation mit Backup. Der Text markiert die Einschränkung mit However am Absatzanfang – ein typisches Signal für die Punkte, nach denen gefragt wird.

a) Monolith und Microservices (3 P)

Eine monolithische Anwendung wird als eine Einheit gebaut und ausgeliefert. Alle Funktionen (Benutzerverwaltung, Produktkatalog, Bestellung, Zahlung) liegen in einer gemeinsamen Codebasis und nutzen meist eine Datenbank. Jede Änderung erfordert, die ganze Anwendung neu zu bauen und auszuliefern; ein Fehler in einem Modul kann das ganze System lahmlegen.

Bei einer Microservice-Architektur wird die Anwendung in kleine, unabhängige Dienste aufgeteilt. Jeder Dienst deckt eine fachliche Aufgabe ab, läuft in einem eigenen Prozess und verwaltet seine eigenen Daten. Andere Dienste greifen nur über seine API auf diese Daten zu. Die Dienste kommunizieren über das Netzwerk, meist per REST (HTTP, JSON) oder asynchron über einen Message Broker.

b) Zwei Vorteile mit Bezug zu GrünBlick (4 P)

• Unabhängige Skalierung: Nur stark belastete Dienste bekommen zusätzliche Instanzen. Beim Frühjahrsverkauf kann Nordwind den Katalogdienst des Shops vervielfachen, während Gewächshaus-Monitoring und Liefer-App mit einer Instanz weiterlaufen. Das spart Rechenleistung und Kosten.
• Unabhängige Auslieferung: Ein Dienst kann neu ausgeliefert werden, ohne das ganze System zu veröffentlichen. Ein Fehler in der Liefer-App (wie T-1046) könnte behoben und ausgeliefert werden, ohne Shop und Monitoring anzufassen.
• Fehlerisolation: Fällt ein Dienst aus, arbeiten die anderen weiter, sofern sie den Ausfall abfangen (Timeouts, Ersatzwerte). Stürzt PflanzenCheck ab, können Kundinnen und Kunden trotzdem bestellen.
• Technologiefreiheit: PflanzenCheck könnte z. B. in Python mit KI-Bibliotheken entwickelt werden, der Shop in Java.

c) Aufgaben eines API-Gateways (3 P)

Das API-Gateway ist der einzige Einstiegspunkt für alle Clients (App auf den Diensthandys, Browser der Kundschaft). Es leitet jede Anfrage an den zuständigen Dienst weiter (Routing) und übernimmt Querschnittsaufgaben wie Authentifizierung, Begrenzung der Anfragerate (rate limiting) und Protokollierung. Diese Funktionen müssen dadurch nicht in jedem Dienst einzeln programmiert werden.

d) Empfehlung (4 P)

Empfehlung: GrünBlick zunächst als gut strukturierten, modularen Monolithen entwickeln und Dienste erst herauslösen, wenn es einen klaren Bedarf gibt. Begründung mit dem Text:

• Das Team ist klein (sechs Personen). Der Text empfiehlt kleinen Teams ausdrücklich, mit einem modularen Monolithen zu beginnen.
• Ein verteiltes System ist deutlich komplexer: Netzwerkaufrufe können langsam sein oder ausfallen, die Daten liegen in mehreren Datenbanken, Transaktionen über mehrere Dienste (z. B. Bestellung, Lagerbestand und Zahlung) sind schwer umzusetzen.
• Testen und Fehlersuche kosten mehr Aufwand, weil eine Anfrage viele Dienste durchläuft.
• Der Betrieb vieler Dienste erfordert Automatisierung (Container-Orchestrierung, zentrales Logging, Monitoring), also zusätzliche Kosten und Know-how.

Ein Argument für eine spätere Aufteilung nennt der Text ebenfalls: sehr unterschiedliche Lastprofile. Der Produktkatalog mit seinen Spitzen beim Frühjahrsverkauf ist deshalb ein guter Kandidat, um ihn später als eigenen Dienst herauszulösen.

e) Versionsnummer in der URL (2 P)

Sobald externe Clients wie die Liefer-App auf den Diensthandys die Schnittstelle nutzen, müssen Änderungen abwärtskompatibel bleiben, sonst funktionieren die alten Clients nicht mehr. Mit der Versionsnummer kann Nordwind eine geänderte, nicht kompatible Schnittstelle unter /api/v2/orders anbieten, während ältere App-Versionen weiter /api/v1/orders verwenden, bis alle Geräte umgestellt sind.

Erklärung: Bei Transferfragen wie d) gibt es keine einzige richtige Entscheidung, aber die Argumente müssen aus dem Text kommen und zum Szenario passen (kleines Team, eine Lastspitze im Katalog). Das Signalwort provided that in der Fehlerisolation ist eine Bedingung: Ohne Timeouts und Ersatzwerte ziehen ausgefallene Dienste die anderen mit.

a) Zelle D2 (1 P)

=B2*C2

b) Zelle E2 (2 P)

=D2*(1-$G$2)

Englisch identisch. Gleichwertig: =D2-D2*$G$2, =D2*(100%-$G$2) oder =D2*(1-G$2) (gemischter Bezug: Zeile fest genügt beim Kopieren nach unten).

c) Formel ohne $ (2 P)

Beim Kopieren wandert der relative Bezug mit: In E3 steht =D3*(1-G3). Die Zelle G3 ist leer und wird als 0 gewertet, also rechnet die Formel 149,40 · (1 − 0) und zeigt 149,40 an – den Preis ohne Rabatt statt richtig 137,45. Gleiches gilt für E4 (187,50 statt 172,50). E2 ist zufällig richtig, deshalb fällt der Fehler leicht nicht auf.

Werte in Excel geprüft (Formeln eingegeben und nach unten kopiert).

d) Einsatzmöglichkeit (1 P)

Eine der folgenden: Kalkulation von Angeboten und Preisen, Auswertung der Umsätze je Monat und Warengruppe mit Diagramm, Planung des Budgets für Heizenergie der Gewächshäuser, Simulation eines neuen Preismodells, Inventurliste, Entwurf eines Schichtplans, Auswertung exportierter Sensordaten.

d) Zelle G2 (3 P)

=WENN(UND(F2="nein";HEUTE()-B2>14);"Mahnung";"")
=IF(AND(F2="nein",TODAY()-B2>14),"Mahnung","")

Gleichwertig: B2<HEUTE()-14, HEUTE()-B2>=15 oder verschachtelt =WENN(F2="nein";WENN(HEUTE()-B2>14;"Mahnung";"");""). Keine Bezüge mit $ nötig, alle wandern zeilenweise mit.

e) Mahnungen am 10.10.2026 (1 P)

5102 (22 Tage, nicht bezahlt) und 5104 (15 Tage, nicht bezahlt). Die Bestellungen 5106 (10 Tage), 5108 (5 Tage) und 5109 (3 Tage) sind ebenfalls offen, aber noch nicht älter als 14 Tage.

Alle Formeln in Excel eingegeben (deutsch per Formeleingabe, englisch zusätzlich zur Kontrolle); Ergebnisse identisch, Status mit HEUTE() am 10.10.2026 und mit festem Datum geprüft. Summe aller Warenwerte 2.514,83 → Mittelwert 251,483.

Erklärung: „mehr als 14 Tage“ heißt >14: Bei genau 14 Tagen gibt es noch keine Mahnung. Bei SUMMEWENN steht der Kriterienbereich vorn und der Summenbereich hinten; ohne Summenbereich würde SUMMEWENN die Textspalte C summieren und 0 liefern.

a) Zellen A6 und A7 (2 P)

A6: =$B$1+1        (oder =B1+1, da A6 nicht kopiert wird)
A7: =A6+1          (nach unten kopiert: A8 =A7+1, A9 =A8+1 …)

b) Zelle B6 (2 P)

=WOCHENTAG(A6;2)          englisch: =WEEKDAY(A6,2)

c) Zelle B4 (2 P)

=WENN(B3>=SVERWEIS(B2;Zonen!$A$2:$E$5;4;FALSCH);"ja";"nein")
=IF(B3>=VLOOKUP(B2,Zonen!$A$2:$E$5,4,FALSE),"ja","nein")

d) Zelle C6 (4 P)

=WENN($B$3>=SVERWEIS($B$2;Zonen!$A$2:$E$5;5;FALSCH);0;
      SVERWEIS($B$2;Zonen!$A$2:$E$5;3;FALSCH))
=IF($B$3>=VLOOKUP($B$2,Zonen!$A$2:$E$5,5,FALSE),0,
    VLOOKUP($B$2,Zonen!$A$2:$E$5,3,FALSE))

In Excel wird die Formel in einer Zeile eingegeben (der Umbruch dient nur der Lesbarkeit). Mit XVERWEIS: =WENN($B$3>=XVERWEIS($B$2;Zonen!$A$2:$A$5;Zonen!$E$2:$E$5);0;XVERWEIS($B$2;Zonen!$A$2:$A$5;Zonen!$C$2:$C$5)). Ebenfalls richtig: die Grundgebühr einmal in einer Hilfszelle (z. B. F1) berechnen und in C6 nur =$F$1 eintragen.

e) Zelle D6 (4 P)

=WENN(B6=7;"keine Lieferung";WENN(B6=6;C6+Zonen!$G$2;C6))
=IF(B6=7,"keine Lieferung",IF(B6=6,C6+Zonen!$G$2,C6))

Gleichwertig: =WENN(B6=7;"keine Lieferung";C6+WENN(B6=6;Zonen!$G$2;0)). Ohne Hilfsspalte B ginge auch WOCHENTAG(A6;2)=7 direkt in der Bedingung.

f) Werte bei Warenwert 125,00 (2 P)

C6 = 0,00, weil 125,00 ≥ 120,00 („Lieferfrei ab“ in Zone 3). D7 = 5,00, weil der 10.10.2026 ein Samstag ist: 0,00 + 5,00 Samstagszuschlag.

In Excel mit den Daten aus Anlage 7 nachgebaut: Alle deutschen und englischen Formeln (auch die XVERWEIS- und die Alternativ-Variante) liefern genau die Werte der Anlage; zusätzlich mit Warenwert 125,00 und 35,00 (B4 = „nein“) geprüft. Die Datumslogik wurde außerdem mit Python nachgerechnet (Seriennummer 08.10.2026 = 46303).

g) Probleme der gemeinsamen Datei (4 P)

Zwei der folgenden, jeweils mit Lösung durch die Anwendung:

Erklärung: Typische Fehler: A6 als =B1+1 schreiben und nach unten kopieren (A7 wird zu =B2+1 = 4, also kein Datum mehr) · den Spaltenindex ab Spalte A des Blattes statt ab der ersten Spalte der Matrix zählen (hier zufällig gleich, weil die Matrix bei A beginnt) · den Zuschlag außerhalb des WENN addieren, z. B. =WENN(B6=7;"keine Lieferung";C6)+WENN(B6=6;Zonen!$G$2;0): Am Sonntag wird dann Text + Zahl gerechnet, und es erscheint #WERT!.

a) Kategorien (4 P)

b) Reaktionszeit und Lösungszeit (2 P)

Die Reaktionszeit ist die maximale Zeit vom Eingang einer Meldung bis zur ersten qualifizierten Rückmeldung bzw. bis zum Beginn der Bearbeitung durch den Support. Die Lösungszeit ist die maximale Zeit vom Eingang bis zur Behebung, also bis der Service wieder funktioniert bzw. die Anfrage erledigt ist. Beide hängen von der Priorität ab und zählen nur innerhalb der vereinbarten Servicezeit.

a) Prioritäten (2 P)

T-1042: Auswirkung hoch, Dringlichkeit hoch → P1. T-1044: Auswirkung gering, Dringlichkeit gering → P4.

b) Einstufung T-1043 und T-1046 (4 P)

Ebenfalls vertretbar, wenn begründet: T-1043 Auswirkung hoch (Gewächshaussteuerung ist laut Vertrag Kernfunktion) → P1; T-1046 Auswirkung mittel (eine Nutzergruppe) → P3 oder Dringlichkeit hoch (Lieferdaten können verloren gehen) → P1.

c) SLA-Prüfung T-1042 (2 P)

P1: Reaktionszeit 15 min, Lösungszeit 4 h. Eingang Montag 10:30 Uhr (innerhalb der Servicezeit).

• Reaktion um 10:52 Uhr → 22 min > 15 min → Reaktionszeit nicht eingehalten.
• Gelöst um 13:10 Uhr → 2 h 40 min ≤ 4 h → Lösungszeit eingehalten.

d) Problem-Ticket zu T-1047 (2 P)

Das gleiche Fehlerbild tritt zum dritten Mal auf (September, T-1043, T-1047). Der Neustart des Gateways ist nur ein Workaround: Die Störung ist behoben, die Ursache aber unbekannt, und sie wird wieder auftreten – jedes Mal mit Gefahr für die Pflanzen. Ein Problem-Ticket sorgt dafür, dass der 2nd/3rd Level (bzw. der Hersteller SensoTec) die Ursache analysiert und dauerhaft beseitigt (ggf. über einen Change, z. B. ein Firmware-Update). Es verknüpft die zusammengehörenden Incidents, und der Workaround wird bis dahin als bekannter Fehler in der Wissensdatenbank dokumentiert.

a) Drei Vorteile (6 P)

Drei der folgenden, jeweils erläutert:

• Nichts geht verloren: Alle Meldungen aus Telefon, E-Mail und Portal werden zentral mit Ticketnummer erfasst. Bisher hingen sie an einzelnen Entwicklern; ist einer krank oder im Urlaub, bleibt nichts liegen, weil jeder den Verlauf im Ticket sieht.
• Priorisierung und SLA-Überwachung: Jede Meldung wird nach Auswirkung und Dringlichkeit eingestuft, die Fristen werden überwacht und bei drohender Überschreitung automatisch eskaliert. Kritische Störungen (Zahlung, Gewächshaus) werden zuerst bearbeitet; Nordwind kann die Einhaltung des Vertrags nachweisen.
• Transparenz für die Melder: Beschäftigte und Kundschaft sehen den Status ihres Anliegens und werden automatisch benachrichtigt. Das spart Nachfragen.
• Entlastung der Entwickler: Der 1st Level löst Standardfälle (Passwort, Zugänge) selbst und leitet nur echte Fehler mit vollständiger Beschreibung weiter. Die Entwickler werden seltener unterbrochen.
• Wissensaufbau: Lösungen werden dokumentiert und in der Wissensdatenbank wiederverwendet; wiederkehrende Fehler (T-1043/T-1047) fallen auf und können über das Problemmanagement dauerhaft behoben werden.
• Auswertbarkeit: Kennzahlen zu Anzahl, Kategorien und Dauer zeigen Schwachstellen von GrünBlick und helfen bei Personalplanung und Abrechnung.

b) Zwei Nachteile bzw. Risiken (4 P)

• Kosten und Aufwand: Lizenz bzw. Betrieb der Webanwendung, Einrichtung (Kategorien, Workflows, SLA-Regeln) und Schulung aller Beteiligten; jedes Ticket muss sorgfältig gepflegt werden.
• Akzeptanz und Formalismus: Beschäftigte empfinden das System als umständlich und unpersönlich und rufen weiter direkt „ihren“ Entwickler an. Dann fehlen Tickets, Statistiken werden falsch, und der Entwickler wird trotzdem unterbrochen.
• Datenschutz und Sicherheit: Tickets enthalten personenbezogene Daten (Namen, Adressen, Screenshots). Die Webanwendung muss abgesichert werden, Zugriffsrechte und Löschfristen sind nötig.
• Fehleinstufung und Verzögerung: Wird ein Ticket falsch kategorisiert oder zu niedrig priorisiert, wartet es in der falschen Warteschlange.
• Abhängigkeit: Fällt das Ticketsystem aus, ist der Support nur eingeschränkt arbeitsfähig.

c) Weg von T-1046 durch die Support-Level (4 P)

1. 1st Level (Service Desk des Pflanzenhofs): nimmt die Meldung des Lieferdienstes auf, erfasst Fehlerbild (Absturz beim Scannen seit dem Update vom 06.10.), Gerät und App-Version, stuft das Ticket ein (Incident, P2), dokumentiert den Workaround (Papierliste) und sucht in der Wissensdatenbank. Da es keine bekannte Lösung gibt: funktionale Eskalation.
2. 2nd Level (Anwendungsbetreuung Nordwind): analysiert Logs, reproduziert den Fehler, prüft Konfiguration und Daten. Stellt sich ein Programmfehler aus dem Update heraus: erneute funktionale Eskalation.
3. 3rd Level (Entwicklungsteam Nordwind): behebt den Fehler im Code und liefert einen getesteten Hotfix aus (oder nimmt das Update zurück).
4. Hierarchische Eskalation: Droht die Lösungszeit von 8 Stunden (P2) überschritten zu werden oder sind zusätzliche Ressourcen bzw. Entscheidungen nötig (z. B. Rollback, andere Aufgaben zurückstellen), informiert der Support die Teamleitung Support, danach die Projektleitung GrünBlick und gegebenenfalls die Geschäftsführung. Diese stellen Personal bereit, entscheiden und informieren den Pflanzenhof.
5. Abschluss: Lösung dokumentieren, Ticket „gelöst“, nach Bestätigung durch den Lieferdienst „geschlossen“; Eintrag in der Wissensdatenbank.

d) Zwei Kennzahlen (4 P)

• SLA-Erfüllungsquote = Tickets, deren Reaktions- und Lösungszeit eingehalten wurde, ÷ alle Tickets · 100. Zeigt, ob Nordwind den Servicevertrag erfüllt.
• Erstlösungsquote = beim ersten Kontakt gelöste Tickets ÷ alle Tickets · 100. Zeigt, wie gut der 1st Level und die Wissensdatenbank funktionieren.
• mittlere Lösungszeit je Priorität: Durchschnitt der Zeit vom Eingang bis zur Lösung; zeigt Schnelligkeit und Trends.
• Wiedereröffnungsquote: Anteil der gelösten Tickets, die wiedereröffnet werden; zeigt die Qualität der Lösungen.
• Backlog (offene Tickets und ihr Alter) oder Kundenzufriedenheit (Umfrage nach Abschluss).

Erklärung: Die Original-Aufgabe (S22) fragte nur nach „drei Vorteilen und einem Nachteil“ mit 12 Punkten, also 3 P je Punkt – entsprechend ausführlich muss erläutert werden. Funktionale und hierarchische Eskalation schließen sich nicht aus: Bei T-1046 laufen beide parallel.

a) KI, Machine Learning, Deep Learning (3 P)

• Künstliche Intelligenz ist der Oberbegriff für Systeme, die Aufgaben lösen, für die sonst menschliche Intelligenz nötig ist (erkennen, entscheiden, Sprache verstehen) – auch mit fest programmierten Regeln.
• Machine Learning ist ein Teilgebiet der KI: Das System lernt Muster und Regeln selbstständig aus Beispieldaten, statt dass ein Mensch sie programmiert. Ergebnis des Trainings ist ein Modell.
• Deep Learning ist ein Teilgebiet des Machine Learning, das tiefe künstliche neuronale Netze mit vielen Schichten nutzt; besonders geeignet für Bilder und Sprache, z. B. für PflanzenCheck.

Zusammenhang: Deep Learning ⊂ Machine Learning ⊂ KI.

b) Lernverfahren (3 P)

a) Getrennte Testdaten (2 P)

Mit den Testdaten wird geprüft, wie gut das Modell bei neuen, unbekannten Fotos funktioniert, also im späteren Einsatz. Wären die Testfotos im Training enthalten, hätte das Modell sie quasi auswendig gelernt; das Testergebnis wäre zu gut, und ein Überanpassen (Overfitting) bliebe unentdeckt.

b) Berechnung und Beurteilung (4 P)

• Genauigkeit = (210 + 1.640) ÷ 2.000 = 1.850 ÷ 2.000 = 92,5 %
• übersehene kranke Pflanzen = 90 ÷ 300 = 30 % (erkannt werden nur 70 %)

Beurteilung: Das Ergebnis reicht für einen selbstständigen Einsatz nicht aus. Fast jede dritte kranke Pflanze bleibt unentdeckt, und Krankheiten wie Mehltau oder Grauschimmel breiten sich im Gewächshaus schnell aus. Die hohe Genauigkeit täuscht, weil 85 % der Testfotos gesunde Pflanzen zeigen: Ein Modell, das immer „gesund“ meldet, käme schon auf 85 %. Außerdem stammen die Testfotos aus denselben Gewächshäusern und derselben Jahreszeit wie das Training; im geplanten Einsatz (andere Pflanzen, Kunstlicht) ist eher ein schlechteres Ergebnis zu erwarten. Vertretbar ist allenfalls ein Pilotbetrieb, bei dem PflanzenCheck nur Hinweise gibt und die Sichtkontrolle durch das Personal bleibt (Fehlalarme: 60 von 270 Meldungen, also rund 22 %).

c) Probleme der Trainingsdaten (4 P)

Rechnung mit Python nachgeprüft: Genauigkeit 0,925; Anteil übersehen 0,30; Fehlalarme unter den Meldungen 60/270 ≈ 0,222; „immer gesund“ ergäbe 0,85.

a) Einordnung nach dem EU AI Act (8 P)

b) Halluzinationen (4 P)

Entstehung: Ein Sprachmodell erzeugt Text, indem es Wort für Wort die wahrscheinlichste Fortsetzung berechnet. Es hat kein geprüftes Faktenwissen und erkennt nicht, ob eine Aussage stimmt. Fehlt eine passende Information, entsteht trotzdem eine flüssige, glaubwürdige Antwort – etwa ein erfundenes Pflanzenschutzmittel.

Maßnahmen (zwei davon):

• Antworten nur auf geprüfte eigene Quellen stützen (RAG): Produktdatenbank und Pflegeanleitungen des Pflanzenhofs; Empfehlungen nur für Produkte aus dem Sortiment.
• Themenbereich begrenzen; bei Pflanzenschutzmitteln (rechtlich und gesundheitlich heikel) an die Fachberatung verweisen.
• Quellen bzw. Produktlinks anzeigen und Hinweis „automatisch erzeugt, bitte prüfen“.
• vor der Freigabe mit typischen Kundenfragen testen, im Betrieb Feedback sammeln und auswerten.

c) KI-Coding-Assistent (4 P)

d) Akzeptanz (4 P)

Zwei der folgenden, jeweils beschrieben:

• Früh und offen informieren: Ziel ist, Krankheiten früher zu erkennen und weniger Pflanzenschutzmittel einzusetzen. PflanzenCheck unterstützt, ersetzt aber niemanden; Entscheidungen über Behandlung oder Aussortieren treffen weiter die Beschäftigten.
• Beteiligen: Workshop mit den Gewächshausteams; ihre Erfahrung wird gebraucht, um Fotos richtig zu labeln, Ergebnisse zu prüfen und das System zu verbessern (das zeigt, dass ihr Wissen wichtiger wird, nicht überflüssig).
• Keine Überwachung zusichern: Kameras nur auf die Pflanzentische ausrichten, Personen auf Fotos unkenntlich machen, Betriebsvereinbarung mit dem Betriebsrat, die eine Leistungs- und Verhaltenskontrolle ausschließt.
• Schulen und schrittweise einführen: Pilot in einem Gewächshaus, Ansprechpartner benennen, Rückmeldungen ernst nehmen, Erfolge sichtbar machen.

Erklärung: Die Einordnung hängt am Zweck, nicht an der Technik: Dieselbe Kamera-Bilderkennung ist bei Pflanzen minimal riskant und bei der Stimmung von Beschäftigten verboten. Teil d) entspricht der Logik von W23 T1 A1b; Querverweis Block 04 (Change-Management, Stakeholder).

a) Begriff (2 P)

Green IT bezeichnet Bestrebungen, Informations- und Kommunikationstechnik über ihren gesamten Lebenszyklus – Herstellung, Betrieb und Entsorgung – umwelt- und ressourcenschonend zu gestalten (z. B. weniger Energie, längere Nutzung, Recycling). Dazu gehört auch, IT so einzusetzen, dass sie in anderen Bereichen Energie und Ressourcen einspart.

b) Ziele (2 P)

Zwei von: Energieverbrauch und Stromkosten senken · CO₂-Emissionen verringern (Beitrag zur Klimaneutralität 2030) · Rohstoffe schonen und Elektroschrott vermeiden (längere Nutzung, Recycling) · Wasser- und Ressourcenverbrauch im Betrieb mit IT senken · Image und Nachhaltigkeitsbericht verbessern.

c) Zuordnung (2 P)

a) PUE Ist (2 P)

IT-Leistung = 14 · 0,32 kW + 1,02 kW = 4,48 kW + 1,02 kW = 5,50 kW
PUE = Gesamtleistung ÷ IT-Leistung = 10,45 kW ÷ 5,50 kW = 1,9

b) Verbrauch und Kosten Ist (2 P)

10,45 kW · 8.760 h = 91.542 kWh pro Jahr
91.542 kWh · 0,28 €/kWh = 25.631,76 € pro Jahr

c) Verbrauch nach der Modernisierung und Einsparung (4 P)

IT-Leistung neu = 3 · 0,55 kW + 1,05 kW = 1,65 kW + 1,05 kW = 2,70 kW
Gesamtleistung neu = 2,70 kW · 1,4 = 3,78 kW
Verbrauch neu = 3,78 kW · 8.760 h = 33.112,8 kWh pro Jahr (Kosten 9.271,58 €)

Einsparung = 91.542 kWh − 33.112,8 kWh = 58.429,2 kWh pro Jahr (≈ 64 %)
in Euro: 58.429,2 kWh · 0,28 €/kWh = 16.360,18 €
in CO₂: 58.429,2 kWh · 0,38 kg/kWh = 22.203,1 kg ≈ 22,2 t

d) Amortisation (2 P)

38.000 € ÷ 16.360,18 €/Jahr ≈ 2,3 Jahre (rund 2 Jahre und 4 Monate).

Alle Werte mit Python nachgerechnet (PUE 1,9; 91.542 kWh; 33.112,8 kWh; 58.429,2 kWh; 16.360,18 €; 22.203,096 kg; 2,32 Jahre).

Erklärung: Die Einsparung entsteht aus zwei Effekten: Die Virtualisierung senkt die IT-Leistung von 5,5 auf 2,7 kW, die neue Kühlung die PUE von 1,9 auf 1,4. Nur virtualisieren ohne neue Kühlung hätte bei gleichbleibender PUE 2,7 · 1,9 · 8.760 ≈ 44.939 kWh ergeben – in der Praxis eher mehr, weil das alte Klimagerät nicht kleiner wird (die PUE würde steigen).

a) Beobachtungen und Maßnahmen (8 P)

Vier der sechs, z. B.:

b) Datenmenge Produktbilder (4 P)

vorher: 30.000 · 4,8 MB = 144.000 MB = 144 GB pro Tag
nachher: 30.000 · 0,12 MB = 3.600 MB = 3,6 GB pro Tag
Einsparung: 140,4 GB pro Tag · 365 = 51.246 GB pro Jahr (≈ 51,2 TB; −97,5 %)
Energie: 51.246 GB · 0,03 kWh/GB ≈ 1.537 kWh pro Jahr

c) Beschaffung der Tablets (4 P)

• Kriterien (zwei davon): geringer Energieverbrauch; robust und für feuchte Umgebung geeignet (lange Lebensdauer); reparierbar, Akku tauschbar; lange Zusage für Sicherheitsupdates und Ersatzteile; Rücknahme und Recycling durch den Hersteller; schadstoffarm; ggf. generalüberholte Geräte.
• Umweltzeichen: Blauer Engel, TCO Certified (auch EPEAT oder Energy Star für die Energieeffizienz).
• Stellungnahme: Der Vorschlag ist abzulehnen. Ein großer Teil der Umweltbelastung eines Tablets entsteht bei der Herstellung; ein Austausch alle zwei Jahre statt nach vier bis sechs Jahren vervielfacht Rohstoffverbrauch, CO₂-Emissionen, Elektroschrott und Kosten. Besser: Geräte nutzen, solange sie funktionieren und Sicherheitsupdates erhalten, Akkus tauschen, Altgeräte nach sicherer Datenlöschung weitergeben oder fachgerecht recyceln.

Rechnungen mit Python nachgeprüft (144 GB; 3,6 GB; 51.246 GB; 1.537,38 kWh; 432.000 Anfragen; 864.000 Messwerte).