Gezielte Benachrichtigung für Bereitschaftstechniker

Welcome to the POB User Group Online Community! Forums PUG DACH Gezielte Benachrichtigung für Bereitschaftstechniker

Tagged: 

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #2887
    Stefan Reichelt
    Participant

    Hallo,

    wir diskutieren gerade sehr angeregt zum Thema Bereitschaft. Bislang haben wir es immer umgangen bzw. sehr oberflächlich gelöst, nun soll es aber doch ein wenig verfeinert werden.

    Situation:
    In einem bestimmten Zeitraum, z.B. nach 18 Uhr und Feiertags, kommt ein Ticket für eine bestimmte Benutzergruppe an.
    Zu diesem Zeitpunkt hat ein bestimmter Benutzer gerade Bereitschaft (meistens für eine Woche, es kann aber auch jeden Tag anders sein), und er soll dazu aktiv und gezielt benachrichtigt werden.

    Frage: Wie löst man das am elegantesten? Wir haben schon ein paar Überlegungen dazu angestellt, mich würden aber erstmal eure Ideen dazu interessieren. Standet ihr schon selbst vor dieser Herausforderung? Wenn ja, wie habt ihr sie gelöst?

    #2888
    Timm
    Member

    Die Antwort ist simpel:
    …die Lösung liegt, wo speicherst du die Information speicherst welcher Benutzer an welchem Kalendertag Bereitschaft hat 😉

    Mir fällt nichts ein wo ich diese Info sinnvoll in POB speichern könnte.
    Ich würde die Lösung auch so bauen wollen, dass es auch für andere Gruppen andere Bereitschaften geben kann…

    Meine Lösung:
    Ich würde diese Information auslagern und ausserhalb von POB lösen
    Eine eigene Tabelle mit 3 Spalten (Date / Group-ID / User-ID)
    Dann würde ich eine kleine Applikation (alá WebService) bauen der ich genau einen Wert übergebe “Group-ID” über die Group-ID und das Datum schaut das Programm in der Tabelle nach und

    Variante 1.)
    returned dir die User ID

    oder

    Variante 2.)
    Du übergibst dem Programm noch deine Case-ID und das Programm manipuliert
    dir direkt den Case und erzeugt eine Mail (entweder direkt oder über Trigger)

    Ich hoffe das du damit etwas anfangen kannst, das wäre meine Lösung…

    LG
    Timm

    #2889
    Stefan Reichelt
    Participant

    Danke für deine Antwort!
    Oh, das Hinterlegen sehe ich nicht so als Problem an. Dafür gibt es ja den Benutzerkalender. Dort sind auch alle Spalten drin, die man braucht – und man kann es gleich in der Resource Overview in einer schicken Gantt-Übersicht betrachten. Die eigentliche Herausforderung ist dort, die Bereitschaftszeiten aus bestehenden Tools (Schichtplaner, Sharepoint-Kalender) irgendwie ins POB zu bekommen.

    Der Trigger, der am Ende herausfindet, dass das gerade eingetroffene Ticket innerhalb eines Bereitschaftsfensters aufschlägt, erscheint mir viel komplexer als das Hinterlegen der Bereitschaftszeiten – von der Aktion, die den richtigen Techniker ermitteln muss, mal ganz abgesehen.

    Ich würde es schon gern wie immer mit Bordmitteln lösen. Selbstgebastelte Notlösungen sind bei uns nicht so gern gesehen…

    #2890

    Ich hätte in der Theorie eine technisch-organisatorische Lösung:

    Part 2: Benachrichtigung des richtigen Bereitschaftsmenschen:

    Wir haben uns eine Abfrage und Ansicht auf die aktiven Benutzer gestaltet.
    Wenn der Bereitschaftsinhaber sein Wendia offen lässt und die anderen Mitarbeiter dies schließen, hättest du den richtigen Mail-Empfänger(‘Aktiv seit’ <> leer).

    Part 1: Wann ist eine Bereitschaftsmail abzusetzen:

    Wir haben uns noch nicht mit den Benutzerkalendern befasst. Doch theorethisch sollte man doch einen Benutzer “Bereitschaft” anlegen können und zieht seine Anwesenheit über einen Dataload aus deinen Fremdsystemen?!

    Eine Idee?

    #2892
    Stefan Reichelt
    Participant

    Part 2: Ich gehe mal davon aus, dass der Bereitschaftstechniker im Bett liegt und durch ein eindringliches Signal aus ebenjenem geworfen werden soll. Somit hat er sein POB gerade nicht offen, und das muss auch nicht sein.

    Part 1:
    Rein theoretisch ist es überhaupt kein Thema, für jede individuelle Bereitschaftsperiode (z.B. heute von 18:00 bis 8:00 morgen früh) einen separaten Eintrag mit zugeordnetem Benutzer zu hinterlegen. Wir müssen davon ausgehen, dass es pro Team mindestens einen, manchmal gar zwei Bereitschaftler geben kann. Ein einzelner Dummy-Bereitschaftsnutzer müsste ja ständig geändert werden, je nach diensthabendem Techniker/Supporter.

    Gehen wir also mal davon aus, dass wir mit Benutzerkalender-Einträgen arbeiten. In einigen Fällen ist das simpel (ich lasse einfach aus den dort organisatorisch notwendigen Tasks automatisch einen solchen Eintrag generieren), in anderen Fällen wird es für mich als Programmier-Laie echt schwer, weil ich per Dataload ein Tool anzapfen muss, das mit dbase-Dateien arbeitet (wenn da jemand einen Tipp hat, wäre ich sehr dankbar).

    Wir haben nun also Kalendereinträge, und wir nehmen an, dass ich ein Merkmal mitgebe, das diese Einträge als Bereitschaft markiert. Diese haben je ein Von- und ein Bis-Datum. Nach unserer aktuellen Idee muss nun POB bei einem eingehenden Ticket schauen, ob in der zugeordneten verantwortlichen Gruppe ein Benutzer existiert, der mit einem jetzt gerade aktiven Bereitschaftskalender-Eintrag verbunden ist. In diesem Fall ist genau jener Nutzer zu informieren. Wenn zwei gefunden werden, soll die Mail an beide gehen. Die weiteren Bedingungen (manchmal, je nach Prio und Servicekalender, soll keine Benachrichtigung aktiv werden) lasse ich mal außen vor, um es nicht zu kompliziert zu machen.

    Wir müssen also ein Message-Event bauen, das eine recht komplexe Bedingung dahinter liegen hat:
    Jetzt (getdate()) trifft ein Ticket für Gruppe x ein, wobei in dieser Gruppe (mindestens) ein Nutzer y existiert, zu dem ein jetzt gerade aktiver Bereitschaftskalendereintrag z (getdate() liegt zwischen z.Von und z.Bis) existiert.

    Das daraufhin aktivierte Mailtemplate soll nun eine Mail an alle Nutzer verschicken, die in der verantwortlichen Gruppe sind und gerade Bereitschaft haben.

    Macht das Sinn?

    #2894

    Das scheint mir mit weitaus mehr Aufwand als nötig verbunden.

    Was ist denn mit einem Haken im Benutzer, der aktiviert werden muss, wenn man Bereitschaft hat? (Aus Erfahrung weß ich, dass Jahrespläne desöfteren verändert werden, daher kaum statisch abbildbar).

    Den einen Kalender des “Bereitschaft” würde ich anlegen, um den Pflege-Aufwand zu minimieren(nur einer statt allen) und zusätzlich auch die Überprüfung der Zeiten zu vereinfachen(jeder kann in diesem Kalender nachschauen, wann Bereitschaft besteht).

    Vielleicht kann man diese Informationen (Kennzeichen und Kalender) miteinander verbinden, sodass sich auch die Aufteilung erkennen lässt …

    #2895
    Stefan Reichelt
    Participant

    Guter Einwand. Ich bin mir nur nicht sicher, ob ein solcher Haken wirklich weniger Aufwand bedeuten würde, schließlich müsste dieser ständig aktualisiert werden. Er müsste um Punkt 18 Uhr gesetzt und um Punkt 8 Uhr morgens wieder entfernt werden – ansonsten müsste das PQL noch komplexer gestrickt werden, um die Zeitraumsprüfung live durchzuführen. Wenn es dann noch zeitliche Unterschiede pro Team gibt (angenommen, an der US-Ostküste sitzt ein Team, das von 21 bis 7 Uhr dortiger Zeit Bereitschaft hat), wird es richtig fies.
    Ich muss dabei anmerken, dass kein Benutzer schreibenden Zugriff auf das Benutzerfenster bekommt, deshalb können wir die Verantwortung auch nicht auf einen lokalen Anwender auslagern.

    Ich greife deine Idee aber gern auf und spinne sie weiter: Der Haken könnte durchaus existieren, und zwar als virtuelle, berechnete Spalte. Diese schaut auf die Kalendertabelle und springt auf TRUE, wenn zum Zeitpunkt des Aufrufs ein aktiver Bereitschaftskalendereintrag existiert. Ich glaube, das bringt mich ein ganzes Stück weiter. Danke für die Anregung!

    #2911
    Stefan Reichelt
    Participant

    Das ist übrigens die Definition der virtuellen Spalte für den Benutzer-Haken “Currently on call”

    select top 1 1 from User_Calendar c where c.user_pk=user_pk and getdate() between c.from_date and c.to_date and c.Virtual_IsOnCall = 1

    Funktioniert wunderbar. Jetzt kommt noch ein berechneter Haken für die Falltabelle, der anzeigt, ob der aktuelle Fall bereitschaftsrelevant ist. Die Anlage der Benutzerkalender funktioniert schon prima.

    #2912
    Stefan Reichelt
    Participant

    Den zweiten Haken lasse ich weg, das bekomme ich auch per PQL im Rahmen der normalen Condition hin. Meine Tests sehen richtig gut aus. Ich würde sagen, das Thema ist erledigt.

    Danke für eure Gedanken dazu!

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.