Ordivis Service
Vier ITIL-Vorgangstypen in einem Prozess, Priorität aus Dringlichkeit und Auswirkung statt aus Bauchgefühl, und ein Portal, das Ihre gesamte Belegschaft nutzen darf – Endanwender kosten nichts.
# Priorität wird abgeleitet, nicht geraten Dringlichkeit hoch (3 Stufen) Auswirkung mittel (3 Stufen) ↓ Priorität 2 – Hoch SLA-Ziel Reaktion 1 h Business Hours SLA-Ziel Lösung 8 h Eskalation bei 80 % Gruppe 2nd Level Netzwerk
Ein Service Desk ist die zentrale und einzige Anlaufstelle – der Single Point of Contact – zwischen Anwendern und der IT-Organisation. Er nimmt Störungen und Anfragen entgegen, ordnet sie ein, steuert ihre Bearbeitung über alle beteiligten Gruppen hinweg und verantwortet die Kommunikation bis zum Abschluss.
Das Entscheidende steckt im letzten Halbsatz: Der Service Desk bleibt verantwortlich, auch wenn die eigentliche Lösung woanders passiert. Ein Ticket, das an das Netzwerkteam übergeben wurde, ist nicht „weg“ – es ist weiterhin ein Vorgang, für den jemand dem Anwender gegenüber geradesteht. Genau daran scheitern die meisten Sammelpostfach-Lösungen.
Ein Helpdesk löst Störungen: Anwender meldet, jemand behebt, Fall zu. Ein Service Desk ist breiter angelegt und für den gesamten Servicebezug zuständig – neben Störungen also auch Serviceanfragen aus einem Katalog, Änderungen, Informationen und die Weiterentwicklung der Services selbst. Kurz gefasst: Der Helpdesk ist reaktiv, der Service Desk steuert zusätzlich.
Praktisch merkt man den Unterschied an einer einzigen Frage: Kann ein Anwender bei Ihnen etwas bestellen – einen Zugang, ein Notebook, eine Freigabe – oder nur etwas melden? Wenn nur Letzteres geht, betreiben Sie einen Helpdesk.
Ein geteiltes Postfach funktioniert erstaunlich lange und bricht dann schlagartig zusammen. Es kennt keinen Status, keine Zuständigkeit und keine Frist; niemand weiß, ob eine Mail bearbeitet wird oder zweimal, und ausgewertet werden kann gar nichts. Spätestens wenn Sie belegen müssen, wie schnell Sie reagiert haben – gegenüber der Geschäftsführung, einem Auditor oder einer Aufsichtsbehörde – ist ein Postfach kein Nachweis.
Alle vier ITIL-Vorgangstypen laufen im selben Ticket-Lebenszyklus – mit demselben Journal, denselben Gruppen und denselben SLA-Regeln.
Eine Störung: Etwas funktioniert nicht wie zugesagt. Ziel ist die schnellstmögliche Wiederherstellung des Service – notfalls per Workaround, die Ursache kommt später.
Die Ursache hinter wiederkehrenden Störungen. Incidents werden gebündelt, der Workaround dokumentiert und die dauerhafte Behebung verfolgt.
Eine geplante Änderung mit Risikoklasse, Genehmigungspfad und CAB-Termin. Standard-, Normal- und Notfall-Changes mit konfigurierbaren Genehmigern.
Eine Standardanforderung aus dem Katalog – Zugang, Gerät, Freigabe. Mit Formular, Genehmigungsschritt und definiertem Ablauf statt Zuruf.
Dringlichkeit und Auswirkung, je dreistufig, ergeben die Priorität – ableitbar statt frei wählbar. Damit priorisieren zehn Agenten vergleichbar, und die Entscheidung ist im Nachhinein begründbar.
Die Aktivitätshistorie ist eingerückt gegliedert: Was ist passiert, wer hat es getan, was wurde kommuniziert. Die Ursprungs-E-Mail steht mit im Journal.
Tickets sind gruppenbasiert sichtbar – Mitgliedschaft je Benutzer oder je Rolle. Das 2nd Level sieht, was es angeht, nicht alles.
Mehrere Ziele je Vorgang, Reaktions- und Lösungszeit, Geschäftszeiten und Kalender berücksichtigt. Eskalation bei drohender Verletzung – vorher, nicht im Monatsbericht.
Tickets entstehen aus einem überwachten Posteingang. Unbekannte Absender werden im lokalen Kontakteverzeichnis automatisch angelegt, Antworten laufen über Reply-To zurück in den Vorgang.
Ein Blazor-Portal für Endanwender: Ticket melden, Status verfolgen, Wissensartikel lesen, Standardanforderungen bestellen. Unbegrenzt viele Nutzer, kostenfrei.
Lösungswege aus dem Ticket heraus auffindbar und verknüpfbar. Freigegebene Artikel erscheinen im Portal – das senkt das Ticketaufkommen, statt es nur zu verwalten.
Tickets hängen an Configuration Items. Über die CMDB ist sofort sichtbar, welche Services betroffen sind – die Grundlage für belastbare Auswirkungsangaben.
Zufriedenheitsabfrage nach Ticketabschluss. Kategorien und Unterkategorien sind frei pflegbar, sodass Auswertungen zu Ihrer Organisation passen.
Störungen aus CheckMK, PRTG, Zabbix oder Nagios/Icinga werden automatisch zu Vorgängen. Wiederholungen landen als Kommentar am bestehenden Ticket, die Entwarnung schließt es wieder – und ein aktives Wartungsfenster unterdrückt die Anlage ganz.
Eine Sturmbremse bündelt Massenereignisse zu einem Sammelvorgang, flatternde Dienste werden als solche erkannt. Und wer als Agent schon am Ticket gearbeitet hat, behält Vorrang vor der Automatik.
Anmeldung am eigenen Identitätsanbieter – Entra ID, Keycloak oder ein anderer OIDC-Provider, dazu die integrierte Windows-Anmeldung per Kerberos. Gruppen und Claims werden auf Ordivis-Rollen abgebildet.
Viele Ticketsysteme rechnen nach Nutzern ab – und meinen damit alle. Das führt zu einer absurden Situation: Man beschränkt den Zugang zum Self-Service-Portal, um Lizenzen zu sparen, und bekommt die Tickets stattdessen per E-Mail und Anruf. Die Software wird günstiger, der Betrieb teurer.
Ordivis Platform rechnet nach benannten Named-User in zwei Rollen ab: Administratoren mit vollem Funktionsumfang und Service-Desk-Agenten für die reine Ticketbearbeitung. Endanwender im Portal sind unbegrenzt und kostenfrei – ebenso wie Assets, CIs und IP-Adressen.
| Rolle | Was sie darf | Lizenzpflichtig |
|---|---|---|
| Administrator | Voller Funktionsumfang inklusive Service Desk, Konfiguration, alle Module | Ja, benannt |
| Service-Desk-Agent | Ticketbearbeitung – günstigere Rolle für reine Bearbeitung | Ja, benannt |
| Endanwender im Portal | Tickets melden und verfolgen, Wissensartikel lesen, Services bestellen | Nein – unbegrenzt |
Ein Service Desk ist die zentrale und einzige Anlaufstelle (Single Point of Contact) zwischen Anwendern und der IT-Organisation. Er nimmt Störungen und Anfragen entgegen, ordnet sie ein, steuert ihre Bearbeitung über alle beteiligten Gruppen hinweg und verantwortet die Kommunikation bis zum Abschluss – auch dann, wenn die eigentliche Lösung woanders passiert.
Ein Helpdesk löst Störungen: Anwender meldet, jemand behebt, Fall zu. Ein Service Desk ist breiter angelegt und für den gesamten Servicebezug zuständig – neben Störungen also auch Serviceanfragen aus einem Katalog, Änderungen, Informationen und die Weiterentwicklung der Services. Der Helpdesk ist reaktiv, der Service Desk steuert zusätzlich.
Aus zwei je dreistufigen Größen: der Dringlichkeit (wie schnell muss es gelöst sein) und der Auswirkung (wie viele Anwender oder wie kritische Prozesse sind betroffen). Daraus wird die Priorität abgeleitet, statt sie frei wählen zu lassen – das macht Priorisierung zwischen Agenten vergleichbar und im Nachhinein begründbar.
Nein. Abgerechnet wird nach benannten Named-User in zwei Rollen: Administratoren und Service-Desk-Agenten. Endanwender, die im Self-Service-Portal Tickets melden und verfolgen, sind unbegrenzt und kostenfrei. Der Rollout an die gesamte Belegschaft ist damit keine Budgetfrage.
Ja. Aus einem überwachten Posteingang werden Tickets erzeugt, die Ursprungsnachricht bleibt im Journal sichtbar. Unbekannte Absender werden automatisch im lokalen Kontakteverzeichnis angelegt, Antworten laufen über die Reply-To-Adresse zurück in den Vorgang.
Die SLA-Engine führt mehrere Ziele je Vorgang – typischerweise Reaktions- und Lösungszeit – und berücksichtigt Geschäftszeiten und Kalender. OLA-Ziele lassen sich zusätzlich auf Ebene der Support-Gruppen führen. Bei drohender Verletzung wird eskaliert, bevor die Frist reißt; die Auswertung landet im Reporting.
Ja. Ordivis Platform läuft als native Windows-Dienst-Infrastruktur mit eigener PostgreSQL-Datenbank vollständig in Ihrem Rechenzentrum. Für Ticketsysteme ist das besonders relevant, weil Tickets regelmäßig personenbezogene Daten und Angaben zu Sicherheitsvorfällen enthalten.
Eine Android-App ist gebaut und läuft auf dem Gerät – mit Offline-Warteschlange, damit Erfassungen im Feld auch ohne Verbindung nicht verloren gehen. Sie ist allerdings noch nicht allgemein verfügbar: Gehärtete Anmeldung, Push-Benachrichtigungen und der Verteilweg stehen noch aus. Der Stand steht im App-Changelog und in der Roadmap.
Ja. Störungen aus CheckMK, PRTG, Zabbix, Nagios/Icinga oder jedem anderen Werkzeug werden über einen Stapel-Endpunkt zu Vorgängen; alternativ genügt ein Monitoring-Postfach mit Parser-Profil. Entscheidend ist, was nicht passiert: Wiederholungen erzeugen keinen zweiten Vorgang, sondern einen Kommentar am ersten. Die Entwarnung schließt den Vorgang nach einer Nachlaufzeit selbst. Ein aktives Wartungsfenster unterdrückt die Anlage, eine Sturmbremse fasst Massenereignisse zu einem Sammelvorgang zusammen, und flatternde Dienste werden als flatternd geführt statt als Ticketlawine.
Ja, über OpenID Connect – Entra ID, Keycloak oder ein anderer OIDC-Provider. Der Code-gegen-Token-Tausch läuft server-seitig (Broker-Modell), im Client liegt kein Geheimnis, PKCE ist erzwungen. Die E-Mail-Domain bestimmt Mandant und Anmeldedienst, Konten entstehen bei der ersten Anmeldung, IdP-Gruppen werden auf Ordivis-Rollen abgebildet. Für Domänen-Arbeitsplätze gibt es zusätzlich die integrierte Windows-Anmeldung per Kerberos. Ein nächtlicher Abgleich deaktiviert Konten, die beim Anmeldedienst gesperrt oder entfernt wurden.
Alle ITIL-Praktiken in einer Suite – vom Incident bis zum Change, ohne Modul-Aufpreise.
Der CI-Bezug am Ticket: Priorisierung nach echten Abhängigkeiten statt nach Gefühl.
Sicherheitsmaßnahmen laufen als Vorgänge im selben System – kein Excel daneben.
Von der E-Mail über die SLA-Uhr bis zur CSAT-Abfrage – in einer Demo per Videokonferenz.