Mir reicht’s. Immer ist die ICT schuld!

Klemmt eine automatische Eingangstür, streikt der Parkplatzschranken in der Parkgarage oder am Parkplatz – wer ist schuld? Die ICT. Reißt die Inhouse-Telefonie auf den Handhelds (die via WLAN läuft) ab, schließt die OP-Türe nicht automatisch – wer erhält das Fehler-Ticket? Richtig, die ICT. Wer kriegt keine Nachspeise, wenn in der Kantine das Kassensystem streikt? Die ICTler*innen, eh klar (aber ohne spezielle Diätanforderung!). Wen trifft der heilige Zorn des Herrn Direktors – by the way, wir brauchen mehr Frauen in Aufsichtsräten und Vorständen – wenn das Tischtelefon schweigt? Wer hat keine Zeit für eine Schale duftenden Kaffee, wenn im Anmeldungscounter der Multifunktionsdrucker muckt? Wen trifft der Zorn der Haustechnik, wenn die Videokamera bei der Lieferantenzufahrt keine oder nur unscharfe Bilder liefert? Es gibt für alles nur eine Antwort: die ICT!

Ich habe mir in einem meiner aktuellen Spitals-Projekte als Consultant/Begleitende Kontrolle das ausgefertigte ICT-Testkonzept zur Prüfung vorlegen lassen. Sechs Seiten PDF, 8 Kapitel mit Inhalt, Terminen, Umfang Hardware und Software, Beschreibung des Staging & Testing Room, in dem die Clients (PCs, Notebooks und Drucker) konfiguriert werden und eine kurze Zusammenfassung, was der Nutzer an Daten beisteuern muss und was der AN (Auftragnehmer) zu erledigen hat. Es hatte eindeutig mehr den Charakter einer sehr kurzen und knappen Liefer- und Leistungsbeschreibung (copy & paste aus dem Angebotsschreiben) denn eines ICT-Testkonzeptes.

Was hätte ich mir als ICT-Testkonzept zumindest erwartet? Die oben beschriebenen PDF-Seiten hätten als Beschreibung der Ausgangslage zur IBS (Inbetriebsetzung) »Testumfang« ohne Frage bereits verwendet werden können.

• allgemeine Situation (Ziele, Partner, Umgebung)
• Voraussetzungen (Abgrenzungen, Vorgaben, Bedingungen)

Dazu ergänzt um die Kapitel »Testinhalt(e)« – was/welche Parameter werden getestet?

• allgemeine Testbeschreibung (Verantwortlichkeiten, Testobjekte, Testarten, etc.)
• Testfälle

Dabei sollte der Fokus auf den durch den AN durchzuführenden respektive auszulösenden (!) Tests liegen. Diese müssen schlüssig und vollständig in »Testfällen« aufgezeigt werden. Beispielhaft Röntgen:

Ohne Anspruch auf Vollständigkeit!

Oftmals ist ICT lediglich der Transporteur der Testdaten, wenn z. B. Schnittstellen und Systeme der TGA (Technische Gebäudeausrüstung) und des Technischen Dienstes getestet werden. Hierzu sind jedoch auch alle Expert*innen des ICT-Teams entsprechend gefragt: NAC (Network Access Control), Firewall, Serverhousing, HW/SW, Applications usw. Hier müssen alle an einem Strang ziehen.

Wie ich die eingangs beschriebenen Fehlertickets persönlich abarbeiten würde?

Zuerst einmal die jeweiligen Messprotokolle des physischen Permanent Links, welcher für den entsprechend fehlerhaft gemeldeten Client gepatcht wurde, prüfen. Wurden alle Autotest- Parameter am Tester richtig eingestellt, ist das Testergebnis positiv in allen Details? Wenn JA, dann einen Channel-Link-Test durchführen (lassen). Hierbei wird der physikalische Link inklusive der jeweiligen Patchkabelverbindungsübergänge gemessen, sollte ebenfalls in allen Autotest-Parametern positiv ausfallen. Es kann dann auch gleich ein sogenannter Link Runner-Test durchgeführt werden. Damit checkt man, ob am anderen Ende die Aktivkomponente/der Switchport aktiv gepatcht und konfiguriert ist, also erreicht werden kann. VLan und PoE+ sowie einige interessante Features mehr, darunter die wichtigste Authentifizierungsfunktion IEEE 802.1X Wireless und kabelgebundenes LAN, können mitverfolgt werden. Wenn alle diese Parameter inkl. der Linklänge im Grünen, also positiven Bereich liegen und die Firewall-Settings OK sind, ist definitiv die ICT unschuldig und diese Schnittstelle sauber und mängelfrei. Nun liegt es an der TGA, deren System und interne Konfiguration nochmals zu testen.

Lassen Sie mich noch ein paar Praxistipps einstreuen: Klemmende automatische Eingangstür – Kieselsteinchen verkeilt? Parkplatzschranke – Parkgebühren-Ignorierer mit dem Auto dagegengerollt und daher mechanisch beschädigt? Handheld-Inhouse-Telefonie reißt unmotiviert ständig ab – WLAN Settings und Review (Ekahau Ausmessungsprotokolle) überprüfen – ggf. Störung aufgrund zu viel gesetzter Access Points (Kanalstörung)? OP-Türe schließt nicht automatisch – Vor-Ort-Prüfung, ob nicht das OP-Personal einen Papierkorb oder sonstigen Platzhalter in die Lichtschranke gestellt hat! Im Anmeldecounter auf einen Kaffee vorbeischauen und dabei Sichtprüfung, ob der MFD (Multifunktionsdrucker) noch immer am ursprünglich gepatchten RJ45-Dosenauslass verortet ist, oder ob ihn das dortige Personal nicht aus »praktischen Gründen« an die andere Wand geschoben und an der dortigen Datendose angesteckt hat …

Das Wichtigste wäre eine aussagekräftige User-Beschreibung des Fehlers/Mangels im Ticket. Denn „Drucker funktioniert nicht“ lässt viele Fehleroptionen zunächst offen.

Bevor mich Leser und mein lieber Chefredakteur wieder fragen, ob dies meiner lebhaften Fantasie entsprungen sei – nein, alles selbst so und oftmals noch heftiger erlebt, fast »erlitten«, aber das wäre Jammern auf hohem Niveau. Und das tun wir ja nicht, gell!

Bleiben oder werden Sie schnell gesund –

Herzlich, Ihre Rudolfine Zachbauer-Zick

Weitere Informationen auf  www.techart.co.at