Nachdem ich im 1. Teil das Unternehmen und seine Organisationsstruktur ein wenigeingegangen bin, geht es nun weiter mit dem 2. Teil mit den:
Aufgaben und Erfahrungen
Als studentischer Mitarbeiter war ich 3 Tage (20h Regelung während des Semesters) in der Woche vor Ort. Meine Aufgabe war es ein sogenanntes Ad-Hoc-Reporting-Tool mit einem Webfrontend für meine Abteilung zu konzipieren und umzusetzen.
Zum Hintergrund: Es gibt innerhalb der Abteilung bestimmte „standard“ Datenbank-Queries, die unregelmäßig an das Datenbank-System (IBM DB2) des Hosts (Mainframes) geschickt werden, um anhand der Ergebnisse den aktuellen Status und somit auch „Staus“/Probleme der Vertragsbearbeitung zu erkennen.
Diese mussten jedoch immer manuell anhand eines DB2-Desktopclients abgeschickt werden – der User musste sich also sowohl mit DB-Queries (da öfter geringe Anpassung nötig) als auch dem Clienttool auskennen. Zudem konnte diese Funktionalität nicht ortsabhängig genutzt werden, da es für den DB2-Client kein Webfrontend gab.
Weiter hatten nur entsprechende User mit den dazugehörigen Rechten im DB2-System Zugriff auf das Datenbank-System, es sollten jedoch auch User mit weniger Zugriffsrechten Zugriff auf bestimmte, nicht sensible DB2-Queries haben.
Somit sollte das Reporting-Tool auch ein Rechte- und Loggingkonzept für die Queries beinhalten, das an den persönlichen Windows-Benutzeraccount gekoppelt ist. Dem entsprechenden User werden also nur Abfragen bereitgestellt, die für ihn „geeignet“ sind und zusätzlich wird die Verwendung von DB2-Abfragen zur Nachverfolgung gespeichert.
Dabei sollten die Queries weiterhin wie o.g. teilweise durch den User an einigen vorgegebenen Stellen dynamisch anpassbar bleiben und diese Eingaben gegen den dort erlaubten Datentyp validiert werden.
Das Reporting-Tool sollte später mit anderen Inhouse-Tools der Abteilung zusammenarbeiten und für jeden vorbeischauenden Mitarbeiter auf einem großen Flachbild-TV innerhalb der Abteilung leicht verständlich den Status der Vertrags-Verarbeitung auf dem Host/Mainframes darstellen.
Ok – genug mit den Details 😉 und weiter zu der weniger technischen
Projektorganisation, -vorgaben und -verlauf
Dabei wurden öfter abteilungsinterne Meetings angesetzt, um den Status und Features des Projektes zu diskutieren und Probleme sowie Unklarheiten bei der Umsetzung zu beseitigen. Dabei werden (i.d.R. bei größeren Meetings) Protokolle angefertigt, die das Gesagte und die weiteren Planungsschritte festhalten und anschließend intern an die Beteiligten (digital) verteilt werden.
Der Zeitplanung wurde dabei von meinem Vorgesetzten ein grober Rahmen gesteckt, der von mir detaillierter mit den einzelnen Arbeitspaketen ausgefüllt werden musste, um den realen Workload genauer zu planen. Dieser wurde dann anschließend noch mal zusammen diskutiert.
Parallel zur Umsetzung des Projektes wurde verlangt, dass die Dokumentation bzw. das Datenverarbeitungskonzept und die Modelle stets aktuell gehalten werden, damit Vorgesetzte und indirekt Beteiligte sich auch ohne ein Gespräch stets ein Bild über meine geplanten Umsetzungen machen konnten ;-).
Know-How bezüglich der technischen abteilungsinternen Voraussetzungen und der Umsetzung musste ich mir parallel dazu selbstständig aneignen, da diese größtenteils für mich noch neu waren.
Im 3. Teil berichte ich abschließend noch einmal von den persönlichen Erfahrungen, einigen Umgewöhnungen und weiteren Dingen.
Jacob