Zugriffe der Belegschaft
klar bei ihren Verantwortlichen

Klare operative Verantwortung für Belegschaftszugriffe

Eine Organisation der Telekommunikationsbranche vereint Büropersonal, Technikerinnen und Techniker im Außendienst und externe Serviceteams. Ihre Arbeit kann sich über Geschäftsanwendungen und spezialisierte operative Systeme erstrecken, für die jeweils eine andere Person verantwortlich ist. Identity Governance verbindet die aktuelle Verantwortung einer Person mit den nötigen Zugriffsrechten und mit der Entscheidung, die diese Rechte freigibt.

easyIGA bietet Mitarbeitenden und Führungskräften einen fachlich verständlichen Weg, Anwendungszugriffe zu beantragen, zu genehmigen und zu überprüfen. midPoint stellt die zugrunde liegende Identity-Governance-Plattform bereit und führt konfigurierte Änderungen in angebundenen Systemen aus. Diese Aufteilung belässt die technische Konfiguration bei den IAM-Fachleuten und macht die fachliche Entscheidung zugleich für die Personen zugänglich, die dafür verantwortlich sind.

Beginnen Sie mit den Identitäten der Belegschaft, statt anzunehmen, dass jede Teilnehmeridentität in dasselbe Programm gehört. Eine Plattform für die Kundenauthentifizierung und der Zugriff von Mitarbeitenden auf eine interne Anwendung dienen unterschiedlichen Zwecken. Diese Seite behandelt den zweiten Fall und die damit verbundenen Verantwortlichkeiten rund um externe Mitarbeitende und technische Konten.

Wenn jemand aus dem Außendienst zwischen regionalen Teams wechselt, muss die für den Service verantwortliche Person verstehen, welche Anwendungsberechtigungen zum neuen Einsatz gehören. Wer die Änderung im Betrieb bearbeitet, braucht einen verlässlichen Identitätsdatensatz und eine Möglichkeit, das Ergebnis zu bestätigen. easyIGA verbindet die fachliche Entscheidung mit diesem technischen Prozess. Die folgenden beispielhaften Szenarien verfolgen Änderungen bei Außendiensteinsätzen, bei den Verantwortlichkeiten von Dienstleistern und bei Anwendungszugriffen, damit jedes Team sieht, wo seine Arbeit beginnt und endet.

Dort ansetzen, wo Außendiensteinsätze Zugriffe ändern

Nehmen Sie als Beispiel eine fiktive Technikerin im Außendienst, die in ein anderes Regionalteam wechselt. Sie braucht vielleicht Zugriff auf ein System für Arbeitsaufträge im neuen Gebiet, während sie Berechtigungen aus dem bisherigen Einsatz nicht mehr benötigt. Die Organisation braucht eine verlässliche Quelle für diese Änderung und eine festgelegte Regel für die betroffenen Anwendungen.

Ein HR-Datensatz kann das Beschäftigungsverhältnis belegen, ohne jeden operativen Einsatz abzubilden. Ein System zur Personaleinsatzplanung enthält vielleicht weitere Angaben. Das Implementierungsteam muss festlegen, welche Quelle für welche Angabe maßgeblich ist und wie Widersprüche aufgelöst werden, bevor diese Angaben Berechtigungen steuern.

Die konfigurierten Lebenszyklus- und Provisionierungsmechanismen von midPoint bilden die Grundlage für Änderungen in angebundenen Systemen. easyIGA ergänzt rund um midPoint die fachliche Oberfläche für Anfragen und Überprüfungen. Eine verständliche Oberfläche löst keine unklare Entscheidung darüber, welche Quelle maßgeblich ist; diese Entscheidung muss die Organisation ausdrücklich treffen.

Nutzen Sie den regionalen Wechsel als Pilotfall. Ermitteln Sie die alten und die neuen Zugriffsrechte und führen Sie dann die konfigurierte Änderung vor. Prüfen Sie die Berechtigungen, die entzogen werden sollen, ebenso wie die hinzukommenden. Wenn eine Ausnahme für einen bestimmten Zeitraum Zugriff auf beide Regionen erlaubt, dokumentieren Sie ihren geschäftlichen Zweck und den Prozess, mit dem sie erneut geprüft wird.

Die Technikerin sollte die Anfrage verstehen können, ohne die internen Namenskonventionen des Verzeichnisses kennen zu müssen. Wer die Änderung im Betrieb bearbeitet, sollte eine unvollständige Änderung im Zielsystem erkennen können. Diese beiden Sichten auf denselben Prozess zeigen, ob die vorgeschlagene Lösung die Menschen unterstützt, die auf sie angewiesen sind.

Dienstleisterzugriffe über den Vertrag hinaus verantworten

Im Netz- und Servicebetrieb können externe Teams mit wechselnden Einsätzen beteiligt sein. Ein Dienstleistervertrag begründet eine Geschäftsbeziehung, doch Anwendungszugriffe brauchen einen verantwortlichen internen Sponsor und einen klaren Zweck. Der Zugriffsprozess sollte diese Unterscheidung bewahren.

Legen Sie einen maßgeblichen Datensatz für die Person oder die verwaltete Identität an. Bestimmen Sie den Sponsor und die Anwendungen, die für die Arbeit nötig sind. Der Name eines Dienstleisters sollte nicht automatisch allen Personen, die diesem Unternehmen zugeordnet sind, dieselben Berechtigungen gewähren.

Im Anfragekatalog von easyIGA lässt sich der Zugriff in fachlicher Sprache beschreiben. Die konfigurierte Richtlinie bestimmt den Genehmigungsweg. Ihre IAM-Fachleute ordnen die Rolle den Berechtigungen im Zielsystem zu und legen fest, welche Nachweise die Operation bestätigen.

Nehmen Sie in die Evaluierung eine externe Person auf, deren Vertrag weiterläuft, deren Einsatz sich aber ändert. Das ist ein nützlicher Test, weil ein einfaches Kennzeichen „Dienstleister aktiv“ möglicherweise nicht ausreicht, um den richtigen Zugriff zu begründen. Bitten Sie den Sponsor zu entscheiden, welche Berechtigungen weiterhin gerechtfertigt sind, und zeigen Sie, wie der unterstützte Workflow diese Entscheidung protokolliert.

Testen Sie auch den Fall, dass ein Sponsor die Organisation verlässt. Das Konto kann technisch aktiv bleiben, während die fachliche Verantwortung unklar wird. Vereinbaren Sie, wer die offenen Überprüfungsaufgaben übernimmt und wie diese Änderung im Identitätsmodell gepflegt wird. Ein Konto braucht während seiner gesamten Nutzungsdauer eine Person, die verantwortlich darüber entscheidet, nicht nur bei seiner Erstellung.

Business-Support-Systeme von der Netzsteuerung trennen

Eine Telekommunikationsumgebung kann Anwendungen für den Kundenservice, Abrechnungssysteme und Werkzeuge für den Netzbetrieb umfassen. Sie sollten nicht als austauschbare Zielsysteme behandelt werden, nur weil jedes davon Konten enthält. Die Auswirkung einer Berechtigungsänderung kann in diesen Systemen sehr unterschiedlich sein.

Ermitteln Sie zuerst die Operationen, die die geplante Integration ausführen soll. Das Lesen von Konten, das Anlegen von Benutzern und das Ändern detaillierter Berechtigungen sind getrennte Funktionen. Klären Sie für jede davon die verwendete Schnittstelle und die Version des Zielsystems. Eine Integration, die Benutzer liest, ist kein Beleg dafür, dass sie jede operative Berechtigung sicher verwalten kann.

Wählen Sie für eine erste Evaluierung von easyIGA einen Workflow mit einer klar für die Anwendung verantwortlichen Person und einem vereinbarten Änderungsprozess. Das kann eine interne Anwendung für Arbeitsaufträge oder eine festgelegte administrative Rolle betreffen. Halten Sie den Umfang so klein, dass die verantwortliche Person die vorgesehenen Berechtigungen erklären und das Ergebnis überprüfen kann.

Netzsteuerung, privilegierte Sitzungen und Secrets-Management können zusätzliche Systeme und Verfahren erfordern. Diese Seite behauptet nicht, dass easyIGA diese Kontrollen ersetzt oder jedes Netzwerkgerät direkt steuert. Die Identitätsarchitektur sollte zeigen, welche Verantwortlichkeiten jede Komponente übernimmt.

Dokumentieren Sie die Grenze im Abnahmeprotokoll. Wenn eine manuelle Operation bestehen bleibt, legen Sie die ausführende Person und die erwartete Bestätigung fest. Wenn ein Zielsystem nicht sofort ein Ergebnis zurückgeben kann, vereinbaren Sie, wie die offene Arbeit verfolgt wird. Der Nutzen entsteht durch einen Prozess mit klarer Bedeutung, nicht durch ein Diagramm, das eine umfassende Automatisierung suggeriert.

Richtlinienergebnisse neben der Genehmigung zeigen

Eine Führungskraft, die über einen Zugriff entscheidet, muss wissen, was die Rolle erlaubt und ob sie mit bestehenden Verantwortlichkeiten in Konflikt steht. Technische Informationen aus Richtlinien sind nützlich, wenn sie die Person im Moment der Entscheidung in einer verständlichen Form erreichen.

easyIGA wertet zum Zeitpunkt der Genehmigung das Ergebnis der in midPoint konfigurierten Ausschlussrichtlinien aus und zeigt es an. Ein Konflikt, der dieser Konfiguration bekannt ist, kann deshalb angezeigt werden, bevor die genehmigende Person entscheidet. Die Organisation bleibt dafür verantwortlich, die Rollen und die Kombinationen festzulegen, die sie einschränken will.

Eine beispielhafte Richtlinie in der Telekommunikation könnte bestimmte administrative Verantwortlichkeiten innerhalb eines Geschäftsprozesses trennen. Die maßgebliche Regel müssen die Verantwortlichen für die Anwendung und für die Kontrolle festlegen. Sie sollte weder aus einem generischen Rollennamen abgeleitet noch als fertige Richtlinie dargestellt werden, die jeder Telekommunikationsanbieter braucht.

Vergleichen Sie bei der Demo eine gewöhnliche Anfrage mit einer, die einen Konflikt auslöst. Bitten Sie die genehmigende Person, das Problem anhand der angezeigten Informationen zu beschreiben. Bitten Sie dann das technische Team, die Konfiguration zu zeigen, die das Ergebnis erzeugt hat. So verbinden Sie das Verständnis der Nutzenden mit dem tatsächlichen Mechanismus.

Das Erstellen und Simulieren von Regeln in easyIGA sind geplante Funktionen. Halten Sie sie von der bereits verfügbaren Anzeige der Richtlinienergebnisse getrennt. Genehmigungen sind auch in Microsoft Teams möglich; der unterstützte Workflow und die Nachweisfelder im vorgeschlagenen Release müssen jedoch vorgeführt werden. Der gekaufte Funktionsumfang sollte dem Workflow entsprechen, den das Team tatsächlich testet.

Serviceteams den tatsächlichen Stand zeigen

Eine Genehmigung ist keine Bestätigung, dass sich der Anwendungszugriff geändert hat. Das Zielsystem kann nicht erreichbar sein, eine Operation ablehnen oder keinen ausreichenden Nachweis für den Abschluss liefern. Wer auf das Ergebnis wartet, braucht einen Status, der diese Möglichkeiten abbildet.

easyIGA unterscheidet die Ergebnisse verifiziert, ausstehend, fehlgeschlagen und unbekannt. Das hilft der antragstellenden Person zu verstehen, warum eine genehmigte Anfrage noch nicht abgeschlossen ist, und gibt dem Betrieb eine Grundlage, den Fall zu untersuchen. Wie detailliert die verfügbaren Angaben sind, hängt vom Zielsystem und von der konfigurierten Integration ab.

Ein Pilotprojekt in der Telekommunikation sollte gezielt ein nicht erreichbares Zielsystem testen. Beobachten Sie den Status der Anfrage vor und nach dem Zeitpunkt, an dem das Zielsystem wieder erreichbar ist. Prüfen Sie, welcher Eintrag das spätere Ergebnis bestätigt und ob offene Arbeit sichtbar bleibt. Ein Wiederherstellungsweg sollte vorgeführt und nicht allein aus dem Vorhandensein eines Wiederholungsmechanismus abgeleitet werden.

Legen Sie die Verantwortung für Ausnahmen über Organisationsgrenzen hinweg fest. Ein zentrales Identitätsteam sieht vielleicht die fehlgeschlagene Operation, während ein Anwendungsteam für das Zielsystem verantwortlich ist. Vereinbaren Sie, wie die relevanten Informationen die Person erreichen, die das Problem lösen kann, und wer die antragstellende Person im Fachbereich informiert.

Unterscheiden Sie im Management-Reporting die Zahl der getroffenen Entscheidungen von der Zahl der verifizierten Änderungen. So verdeckt eine scheinbar abgearbeitete Genehmigungswarteschlange keine unerledigte technische Arbeit. Die Unterscheidung ist besonders nützlich, wenn mehrere Anwendungsteams einen gemeinsamen fachlichen Zugriffsprozess nutzen, die Änderungen in ihren Zielsystemen aber unterschiedlich genau bestätigen.

Berechtigungen überprüfen, wenn sich Teams und Dienste ändern

Ein neuer Dienst oder eine organisatorische Änderung kann verändern, welche Berechtigungen eine Person braucht. Zugriffsüberprüfungen geben der verantwortlichen Führungskraft oder der für die Anwendung verantwortlichen Person die Gelegenheit, bestehende Zugriffsrechte an der aktuellen Arbeit neu zu bewerten. Der Umfang der Überprüfung sollte klar machen, welche Entscheidung von jeder Person erwartet wird.

easyIGA zeigt Zugriffsrechte in der Überprüfung mit dem verfügbaren Kontext an. „Letzte Nutzung“, „Gewährt von“ und „Genehmigt von“ hängen von den Einträgen der angebundenen Systeme und der erfassten Genehmigungshistorie ab. Diese Felder helfen nur, wenn ihre Bedeutung und ihre Lücken klar bleiben.

easyIGA protokolliert bei Anfragen, die über das Produkt gestellt werden, die antragstellende Person und die erfassten Genehmigungsschritte. Zugriffsrechte, die außerhalb von easyIGA vergeben wurden, werden anhand der von midPoint erfassten Erstellungsangaben gesondert gekennzeichnet. Historischen Einträgen kann eine genehmigende oder vergebende Person fehlen; fehlende Informationen werden ausdrücklich angezeigt.

Nutzen Sie ein Beispiel, in dem eine Technikerin die Verantwortung gewechselt, aber eine alte Berechtigung behalten hat. Bitten Sie die prüfende Person zu erklären, ob sie noch benötigt wird. Nehmen Sie einen zweiten Eintrag mit unvollständiger Historie auf. Die Evaluierung sollte zeigen, wie aus Unsicherheit eine zu klärende Frage wird statt einer automatischen Genehmigung.

Prüfen Sie nach einer Entscheidung, einen Zugriff zu entziehen, das Ergebnis im Zielsystem. Eine Überprüfungskampagne kann die richtige fachliche Entscheidung protokollieren und trotzdem offene Arbeit in einer Anwendung hinterlassen. Vereinbaren Sie, wer nachfasst und welcher Eintrag den Abschluss belegt. So wird die Überprüfung Teil eines gepflegten Zugriffsprozesses statt einer isolierten periodischen Pflichtübung.

Technische Konten an ihren Zweck gebunden halten

Telekommunikationsdienste können von Anwendungs- und Integrationskonten abhängen, die keine Mitarbeitenden repräsentieren. Ein solches Konto unterstützt vielleicht einen Reporting-Job oder eine Schnittstelle zwischen Geschäftssystemen. Sein Lebenszyklus sollte diesem Zweck und dem verantwortlichen Team folgen, nicht einer zufälligen Verknüpfung mit der Person, die es angelegt hat.

Dokumentieren Sie zuerst die Abhängigkeit. Halten Sie fest, was das Konto tut, welche Berechtigungen es braucht und wer eine Änderung autorisieren darf. Der Eintrag in der Identity Governance sollte der Organisation helfen, die Verantwortung zu verstehen, ohne Zugangsdaten oder unnötige sensible Informationen gegenüber prüfenden Personen aus den Fachbereichen offenzulegen.

Die Zuordnung zu einer aktuell beschäftigten Person ist nicht immer die richtige Antwort auf die Frage nach der Verantwortung. Ein Konto, das von einem Dienst genutzt wird, braucht vielleicht ein verantwortliches Team und einen anderen Überprüfungsprozess. Klären Sie, wie das vorgeschlagene easyIGA-Release den jeweiligen Fall abbildet und welche Nachweise aus dem Zielsystem verfügbar sind.

Wählen Sie für das Pilotprojekt ein technisches Konto aus. Fragen Sie, was passiert, wenn das verantwortliche Team umorganisiert oder die Anwendung außer Betrieb genommen wird. Der Test sollte zwischen einem Wechsel der Verantwortung und der Deaktivierung des Kontos unterscheiden. Die Folgen beider Maßnahmen sollte die für die Anwendung verantwortliche Person verstehen.

Die Seite zu nicht-menschlichen Identitäten und verwaisten Konten bietet zusätzlichen Kontext. Betrachten Sie sie als Ausgangspunkt für ein Gespräch über den Umfang, nicht als Beleg für eine flächendeckende Erkennung oder automatische Behebung. Jeder Kontotyp und jede Operation im Zielsystem, die in die Evaluierung einbezogen werden, brauchen eigene Nachweise.

midPoint als konfigurierte Identitätsgrundlage nutzen

midPoint stellt die zugrunde liegenden Mechanismen für Identitätsmanagement und Identity Governance bereit. midPoint ist open source und für technische Teams öffentlich dokumentiert. easyIGA ergänzt auf dieser Grundlage seine fachliche Oberfläche für Anfragen, Entscheidungen und Überprüfungen.

Eine Organisation, die midPoint bereits betreibt, kann die zusätzliche Oberfläche anhand einer bestehenden Anwendungsrolle vergleichen. Bitten Sie die beteiligte Person aus dem Fachbereich, dieselbe Aufgabe im vorgeschlagenen Workflow auszuführen. Bitten Sie das Identitätsteam zu erklären, welche Konfiguration unverändert bleibt und welche Integrationsarbeit für das vorgesehene easyIGA-Release nötig ist.

Beginnen Sie bei einer neuen Implementierung mit dem Identitätsmodell statt mit einer Liste von Anwendungslogos. Legen Sie fest, welche Quelle maßgeblich ist und wie Rollen fachliche Verantwortlichkeiten abbilden. Klären Sie, welche Operationen jedes Zielsystem bereitstellt, bevor Sie sich auf einen Automatisierungsumfang festlegen.

Die Übersicht der Konnektoren ist für diese Recherche nützlich. Ein aufgeführter Konnektor muss trotzdem gegen die Version und das Berechtigungsmodell des Zielsystems validiert werden. Ob eine Integration passt, ist eine konkrete technische Frage und kein Versprechen, dass sich jedes System ohne zusätzlichen Aufwand anbinden lässt.

Die Seite von Evolveum zur Telekommunikation beschreibt Anwendungsfälle von midPoint in der Branche. Eine Demo von easyIGA kann auf dieser Grundlage mit einer internen Anwendung und einem geänderten regionalen Einsatz arbeiten. Bitten Sie die für den Service verantwortliche Person, den beantragten Zugriff zu bewerten, und das Identitätsteam, die Operation im Zielsystem zu prüfen. Ihre Beobachtungen helfen festzustellen, ob der vorgeschlagene Workflow zur Übergabe zwischen zentraler Administration und regionalem Betrieb passt.

Verantwortung für Sicherheit und Betrieb überprüfbar machen

Ein Identitätsprogramm für die Belegschaft unterstützt die Verfahren der Organisation zur Zugriffskontrolle. Es sollte sich neben Authentifizierung, Kontrollen für privilegierte Zugriffe und der Reaktion auf Sicherheitsvorfälle einfügen, und die Grenze zwischen den Komponenten muss dabei klar sein. Keine einzelne Genehmigungsoberfläche stellt die Sicherheit der gesamten Serviceumgebung her.

Die NIS2-Richtlinie zählt Konzepte für die Zugriffskontrolle zu den Risikomanagementmaßnahmen im Bereich der Cybersicherheit (Art. 21 Abs. 2 Buchst. i). Den maßgeblichen Anwendungsbereich und die nationale Umsetzung muss die Organisation selbst bewerten. Die offizielle Richtlinie ist die Quelle für diesen rechtlichen Kontext und keine Zertifizierung von easyIGA.

Bei der Bereitstellung wird easyIGA standardmäßig selbst gehostet. Für Organisationen ohne geeignete Infrastruktur ist auf Anfrage eine in der EU gehostete Bereitstellung verfügbar, die unser Team betreibt. Prüfen Sie die Verantwortlichkeiten für Betrieb und Support in der vorgeschlagenen Vereinbarung. Ein Hosting-Standort begründet weder eine Zusage zur Serviceverfügbarkeit noch einen vollständigen Auftragsverarbeitungsvertrag.

Legen Sie fest, wer fehlgeschlagene Operationen überwacht, wer Konfigurationsänderungen testet und wie die Wiederherstellung nachgewiesen wird. Auch ein Geschäftsbetrieb rund um die Uhr braucht ausdrückliche Vereinbarungen zu Abdeckung und Eskalation; diese sollten nicht aus den in der Branche üblichen Betriebszeiten abgeleitet werden.

Die Sicherheitsinformationen und die Seite zu den Bereitstellungsoptionen bieten einen Ausgangspunkt. Das nützliche Ergebnis der Due-Diligence-Prüfung ist ein vereinbartes Verantwortungsmodell mit den Nachweisen, die für die Abnahme des Service nötig sind. Halten Sie in diesen Unterlagen Produktfunktionen, organisatorische Verfahren und vertragliche Zusagen als getrennte Teile fest.

Teilnehmeridentitäten vom Umfang für die Belegschaft getrennt halten

Eine Kundin eines Telekommunikationsanbieters und eine Technikerin im Außendienst können beide digitale Identitäten haben, ihre Zugriffsbeziehungen unterscheiden sich aber. Teilnehmerregistrierung, Abrechnung und Authentifizierung haben eigene Anforderungen. Der IGA-Umfang für die Belegschaft auf dieser Seite sollte ohne gesonderte technische und fachliche Bewertung nicht auf diese Funktionen ausgeweitet werden.

Machen Sie diese Unterscheidung in einer Angebotsanfrage ausdrücklich. Benennen Sie die Beschäftigten und externen Mitarbeitenden, deren Zugriffe auf interne Anwendungen verwaltet werden. Führen Sie technische Konten gesondert auf und erläutern Sie ihren betrieblichen Zweck. Verwenden Sie nicht die Gesamtzahl der Teilnehmeridentitäten als Ersatz für einen festgelegten Umfang verwalteter Identitäten.

Wenn eine Anwendung für die Belegschaft Kundendaten anzeigt, sollte die für die Anwendung verantwortliche Person die relevanten Rollen der Mitarbeitenden und die Genehmigungsbefugnis festlegen. Der Governance-Prozess kann dann diese internen Berechtigungen bewerten. Er stellt nicht die Identität von Kundinnen und Kunden fest und ersetzt nicht die Kontrollen rund um Kundenauthentifizierung und Dienstberechtigungen.

Den Preis mit den enthaltenen Leistungen vergleichen

Für midPoint fällt keine Softwarelizenzgebühr an. Einige Funktionen von midPoint, etwa Simulationen, Hochverfügbarkeits-Clustering oder eine andere Datenbank als PostgreSQL, erfordern ein Evolveum-Abonnement, das wir organisieren und in Ihr Angebot aufnehmen. easyIGA ist kommerziell und hat ein veröffentlichtes jährliches Abonnementmodell pro verwalteter Identität; die Einführung im vereinbarten Umfang ist enthalten. Lassen Sie sich die aktuellen Preise und den genauen Funktionsumfang in einem schriftlichen Angebot bestätigen.

Ermitteln Sie als Organisation der Telekommunikationsbranche die Gruppen, die verwaltet werden sollen. Mitarbeitende, externe Mitarbeitende und Servicekonten können unterschiedliche Anforderungen mit sich bringen, auch wenn sie in derselben Anwendungsumgebung vorkommen. Legen Sie ausdrücklich fest, wie gezählt wird und wie Wachstum behandelt wird.

Listen Sie die Anwendungsinstanzen und die erforderlichen Operationen auf. Eine Anbindung an ein Verzeichnis auf Gruppenebene kann etwas anderes sein als die detaillierte Verwaltung von Berechtigungen in einer Fachanwendung. Migration, Datenbereinigung und Abnahmetests sollten im Umfang sichtbar sein, statt stillschweigend als Teil einer einzelnen Konnektor-Position angenommen zu werden.

Bewerten Sie den Business Case anhand des gemessenen Bearbeitungsaufwands. Erfassen Sie die aktuellen Anfragevolumina, die aktive Administrationszeit und den Aufwand für die Klärung von Ausnahmen. Vergleichen Sie denselben Prozess in einem Pilotprojekt. Frei werdende Kapazität ist nützlich, ist aber weder automatisch eine Kosteneinsparung noch eine garantierte Verringerung des Personalbestands im Betrieb.

Die Preisseite und die Gegenüberstellung mit midPoint unterstützen dieses Gespräch. Nutzen Sie eine 30-minütige Demo, um einen Workflow für Zugriffe der Belegschaft mit einem gewöhnlichen Fall und einer Ausnahme durchzugehen. Die Demo kann dann klären, was das vorgeschlagene Produkt für Ihre Nutzerinnen und Nutzer ändert und was das technische Team weiterhin konfigurieren und betreiben muss.