Zugriffsrechte passend
zu wesentlichen Diensten

Verantwortung in allen wesentlichen Diensten sichtbar halten

Ein Strom-, Gas- oder Wasserversorger ist auf Menschen angewiesen, deren Arbeit sich über Büros, Außenstandorte und externe Serviceteams erstreckt. Ihre Zugriffsrechte auf Anwendungen sollten die Verantwortung widerspiegeln, die sie heute tragen. Externe Mitarbeitende, die einen Wartungsauftrag abschließen, und Beschäftigte, die in ein anderes Team wechseln, lösen jeweils eine Zugriffsentscheidung aus, für die es eine verantwortliche Person braucht.

easyIGA bietet Mitarbeitenden und Führungskräften einen verständlichen Weg, Zugriffsrechte auf Anwendungen 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. Beteiligte aus den Fachbereichen können an Entscheidungen mitwirken, während IAM-Fachleute das Identitätsmodell und die Integrationen pflegen.

Ein sinnvoller Ausgangspunkt ist ein klar abgegrenzter Service-Workflow. Wählen Sie eine Anwendung mit einer eindeutig verantwortlichen Person, ermitteln Sie die Personen, die sie nutzen, und vereinbaren Sie, was eine erfolgreiche Zugriffsänderung bestätigt. So wird aus einem breit angelegten Identitätsprogramm ein Prozess, den die Organisation prüfen und testen kann.

Eine Führungskraft im Außendienst kann erklären, für welche Arbeit eine Person eingeteilt ist; eine für die Anwendung verantwortliche Person kann erklären, welche Zugriffsrechte diese Arbeit erfordert. easyIGA gibt diesen Personen einen gemeinsamen Prozess für Anfragen und Überprüfungen, der im Hintergrund mit midPoint verbunden ist. Die folgenden beispielhaften Szenarien zeigen, wie Veränderungen in der Belegschaft und Einsätze externer Mitarbeitender diesen Prozess durchlaufen. Sie konzentrieren sich auf Anwendungsberechtigungen und die zugehörigen Nachweise. Diese sind Teil der umfassenderen betrieblichen Vorkehrungen, die einen wesentlichen Dienst am Laufen halten.

Mit den Anwendungen rund um den Betrieb beginnen

Ein Versorgungsunternehmen kann neben der Betriebstechnik Systeme für Instandhaltungsplanung, Personaleinsatzplanung und Dokumente betreiben. Ein Identitätsprojekt muss diese Anwendungsverantwortlichkeiten unterscheiden, bevor es entscheidet, was angebunden wird. Eine Kontoschnittstelle allein belegt nicht, dass automatische Änderungen für ein bestimmtes System des operativen Betriebs angemessen sind.

Wählen Sie für eine erste Phase eine Anwendung, deren Rollendefinitionen und Änderungsprozess verstanden sind. Eine Rolle in der Instandhaltungsplanung könnte ein geeignetes Beispiel sein, wenn die verantwortliche Person den Unterschied zwischen normaler Nutzung und Administration erklären kann. Die Entscheidung sollte der Bewertung der Organisation folgen, nicht einer pauschalen Annahme über die Branche.

Dokumentieren Sie, was die Integration leisten muss. Konten lesen, eine Rolle ändern und Zugriff deaktivieren sind unterschiedliche Operationen. Klären Sie, wie das Zielsystem Fehler meldet und welche Nachweise es für den Abschluss liefern kann. Eine Integration, die eine Benutzerliste bereitstellt, ist kein Beleg dafür, dass sie jede Berechtigung verwalten kann.

easyIGA macht die unterstützte fachliche Entscheidung über verständliche Anfragen und Überprüfungen zugänglich. midPoint übernimmt im Hintergrund die konfigurierten Änderungen in den Zielsystemen. Das Implementierungsteam bleibt dafür verantwortlich, den Umfang zu bestätigen und ihn mit der tatsächlichen Anwendungsversion zu testen.

Halten Sie manuelle Schritte sichtbar, wo sie weiterhin nötig sind. Eine namentlich benannte ausführende Person und ein festgelegter Bestätigungsnachweis können Teil eines gesteuerten Prozesses sein. Entscheidend ist, dass die Organisation weiß, welche Arbeit automatisiert und welche manuell erfolgt und welcher Nachweis die Entscheidung mit dem tatsächlichen Zustand im Zielsystem verbindet.

Außendiensteinsätze mit den nötigen Zugriffsrechten verbinden

Nehmen Sie als Beispiel eine Person aus der Belegschaft, die zwischen regionalen Instandhaltungsteams wechselt. Der neue Einsatz kann Zugriff auf andere Arbeitsaufträge oder Datensätze erfordern. Manche alten Berechtigungen bleiben für eine Übergabe vielleicht bestehen, andere sollten enden. Ein einzelnes Aktiv-Kennzeichen am Konto erklärt diesen Übergang nicht.

Bestimmen Sie die maßgebliche Quelle für den Einsatz. Die Personalabteilung kann für den Beschäftigungsstatus zuständig sein, während das operative Team in einem anderen freigegebenen System hinterlegt ist. Vereinbaren Sie, wie diese Angaben genutzt werden und welche verantwortliche Person Widersprüche auflöst. Ein Identitätsmodell sollte nicht stillschweigend zwischen widersprüchlichen Datensätzen wählen.

Die konfigurierten Lebenszyklus- und Provisionierungsmechanismen von midPoint verbinden Änderungen in Quellsystemen mit Rollen und Zielsystemen. easyIGA stellt rund um den unterstützten Prozess die fachliche Oberfläche für Anfragen und Überprüfungen bereit. Wie gut diese Oberfläche funktioniert, hängt von einem Rollenmodell ab, das die tatsächliche Arbeit abbildet.

Zeigen Sie im Pilotprojekt die Berechtigungen vor und nach dem Wechsel. Prüfen Sie die Zugriffsrechte, die entfernt werden sollen, ebenso sorgfältig wie die, die hinzukommen sollen. Wenn eine befristete Ausnahme gerechtfertigt ist, legen Sie fest, wer dafür verantwortlich ist und wie die Organisation sie erneut prüfen wird.

Beziehen Sie eine verspätete Aktualisierung im Quellsystem in den Test ein. Die betroffene Person und die für den Zugriff verantwortliche Person brauchen einen vereinbarten Weg zur Korrektur. Eine verständlichere Ansicht hilft Menschen, die Aufgabe zu verstehen, kann aber ohne verlässliche Informationen und eine verantwortliche Person für die Quelle nicht die richtige betriebliche Zuordnung herstellen.

Externen Serviceteams einen aktuellen Sponsor zuordnen

Die Beziehung zu einem Dienstleister kann über Jahre bestehen, während einzelne Personen und Einsätze wechseln. Zugriff auf Anwendungen braucht eine genauere Grundlage als die Tatsache, dass der Dienstleister auf einer freigegebenen Liste steht. Jede verwaltete Identität sollte mit der ausgeführten Arbeit und einer internen Verantwortung verbunden sein.

Beginnen Sie mit einer freigegebenen Quelle für Angaben zu externen Mitarbeitenden. Legen Sie den Sponsor und die für den Einsatz benötigten Anwendungen fest. Die Organisation sollte wissen, wer Zugriffe genehmigen darf und wer entscheidet, ob sie weiterhin nötig sind, wenn sich die Arbeit ändert.

Der Katalog von easyIGA stellt Zugriffsrechte mit verständlichen fachlichen Beschreibungen dar. Die konfigurierte Richtlinie steuert den Entscheidungsweg, und IAM-Fachleute ordnen die genehmigte Rolle den Berechtigungen im Zielsystem zu. Eine klare Beschreibung hilft dem Sponsor, eine Entscheidung zu treffen, ohne den technischen Namen jeder Verzeichnisgruppe kennen zu müssen.

Nutzen Sie eine Verlängerung und eine Neuzuweisung als Testfälle. Externe Mitarbeitende können beim selben Dienstleister bleiben und trotzdem an einen anderen Standort oder zu einem anderen Dienst wechseln. Die richtigen Berechtigungen können sich ändern, obwohl die zugrunde liegende Geschäftsbeziehung fortbesteht. Testen Sie diese fachliche Unterscheidung ausdrücklich.

Planen Sie auch den Fall ein, dass ein Sponsor nicht verfügbar oder ein Eintrag zur Berichtslinie fehlerhaft ist. Der Workflow sollte die Ausnahme sichtbar machen, damit die Organisation die zugrunde liegende Verantwortung korrigieren kann. Er sollte weder eine fiktive genehmigende Person erzeugen noch fehlende Informationen als Grund werten, einen Zugriff als autorisiert zu betrachten. Ein guter Prozess macht Unsicherheit bearbeitbar.

Die Grenze zur Betriebstechnik verstehen

Identity Governance kann die Verantwortlichkeit für Anwendungszugriffe unterstützen, doch Betriebstechnik bringt systemspezifische Fragen der Betriebssicherheit und Verfügbarkeit mit sich. Die anlagenverantwortliche Person muss entscheiden, welche Schnittstellen an einem Identitätsprozess teilnehmen dürfen und unter welchen Änderungskontrollen.

Zeichnen Sie die Architektur entlang des freigegebenen Umfangs. Zeigen Sie die maßgeblichen Quellen, die Governance-Plattform und die angebundenen Zielanwendungen. Kennzeichnen Sie Systeme, die außerhalb der Integration bleiben. Eine klare Grenze sagt mehr aus als ein Diagramm, das nahelegt, jedes Gerät werde über ein einziges Produkt automatisch gesteuert.

Klären Sie für jedes sensible Zielsystem, welche Auswirkung eine Kontoänderung hat. Legen Sie fest, wie sie getestet wird und wer sie autorisiert. Die Implementierung sollte den Verfahren der Organisation für betriebliche Änderungen und Wiederherstellung folgen. Diese Seite beansprucht keine direkte Unterstützung für jedes Steuerungssystem oder Gerät.

Der easyIGA-Workflow kann die fachliche Entscheidung verständlich machen. midPoint kann die Operationen ausführen, die konfiguriert sind und von der Integration unterstützt werden. Keine dieser Tatsachen belegt, dass eine geplante Änderung für den physischen Prozess hinter einem bestimmten System angemessen ist. Diese Schlussfolgerung erfordert die fachliche Bewertung durch die zuständigen Fachleute der Organisation.

Nehmen Sie die Grenze in die Abnahmenachweise auf. Protokollieren Sie die getesteten Zielsysteme, Versionen und Operationen sowie alle verbleibenden manuellen Verfahren. Wenn die erste Phase nur unterstützende Anwendungen steuert, sagen Sie das klar. Eine klar definierte erste Phase bietet eine Grundlage für spätere Bewertungen, ohne zu suggerieren, dass ungetestete Systeme des operativen Betriebs bereits abgedeckt sind.

Unvollständige Zugriffsänderungen sichtbar halten

Eine Führungskraft kann eine Anfrage genehmigen, während das Zielsystem wegen geplanter Wartung nicht verfügbar ist. Eine Entzugsoperation kann fehlschlagen, weil das Zielsystem die Anweisung ablehnt. Die Organisation muss diesen Unterschied erkennen können, statt anzunehmen, dass mit der fachlichen Entscheidung auch die technische Arbeit erledigt ist.

easyIGA unterscheidet die Ergebnisse verifiziert, ausstehend, fehlgeschlagen und unbekannt. Diese Zustände geben Beteiligten aus den Fachbereichen und den Betriebsteams eine gemeinsame Grundlage, um über das Ergebnis zu sprechen. Die Verifizierung hängt von den Daten des Zielsystems und der konfigurierten Integration ab, deshalb sollten die Nachweise für jede Anwendung im Umfang geprüft werden.

Ein aussagekräftiges Pilotprojekt in einem Versorgungsunternehmen schließt ein nicht verfügbares Zielsystem ein. Beobachten Sie den Status, solange das Zielsystem nicht erreichbar ist, und die Nachweise, die entstehen, wenn der Dienst wieder läuft. Beschreiben Sie ein nicht erreichbares System nicht als sofort aktualisiert, nur weil eine zentrale Entscheidung protokolliert wurde.

Vereinbaren Sie, wer offene Operationen bearbeitet. Das Identitätsteam kann die Integration analysieren, während eine für die Anwendung verantwortliche Person ein Problem auf Seiten des Zielsystems behebt. Die antragstellende Person sollte eine aussagekräftige Rückmeldung zum Fortschritt erhalten, und die für die Kontrolle verantwortliche Person sollte wissen, welche Änderungen noch unbestätigt sind.

Das Reporting muss diese Bedeutung bewahren. Die Zahl der Genehmigungen und die Zahl verifizierter Änderungen messen unterschiedliche Phasen. Wenn beide getrennt bleiben, erkennt die Organisation leichter, welche Arbeit noch erledigt werden muss. Zudem erhalten die Personen, die die Nachweise prüfen, ein genaueres Bild des Geschehens, als es ein pauschaler Status „abgeschlossen“ für jede genehmigte Anfrage vermittelt.

Zugriffe an der aktuell ausgeführten Arbeit überprüfen

Eine regelmäßige Überprüfung gibt der verantwortlichen Person die Gelegenheit, Berechtigungen neu zu bewerten, die früher angemessen waren. Jemand hat vielleicht die Region gewechselt oder ein Instandhaltungsprogramm abgeschlossen. Das bestehende Beschäftigungsverhältnis allein begründet nicht den Bedarf an jeder alten Anwendungsrolle.

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 Daten der Quellsysteme und der im Produkt erfassten Genehmigungshistorie ab. Diese Felder sollten getrennt interpretiert werden, und fehlende Nachweise sollten ausdrücklich erkennbar 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.

Nehmen Sie als Beispiel für eine Überprüfung eine weiterhin beschäftigte Person mit einer alten standortspezifischen Rolle auf. Bitten Sie die fachlich verantwortliche Person zu erklären, ob dieser Zugriff noch benötigt wird. Nehmen Sie einen weiteren Eintrag mit unvollständiger Historie auf und vereinbaren Sie, wie er untersucht wird. Manche Berechtigungen werden selten genutzt, deshalb ist fehlende jüngere Aktivität eine Information für eine Entscheidung und keine Regel für automatisches Entfernen.

Wenn eine prüfende Person entscheidet, dass ein Zugriff enden soll, verfolgen Sie die Operation im Zielsystem. Die für die Überprüfung verantwortliche Person braucht eine Möglichkeit, eine protokollierte Entzugsentscheidung von einer bestätigten Änderung zu unterscheiden. So wird die regelmäßige Aufsicht mit der betrieblichen Arbeit verbunden, die nötig ist, damit Berechtigungen zu den aktuellen Verantwortlichkeiten passen.

Verantwortung für Servicekonten als dauerhafte Aufgabe behandeln

Eine Anwendungsschnittstelle kann von einem Konto abhängen, das jemand angelegt hat, der die Organisation inzwischen verlassen hat. Der Zweck des Kontos kann weiterhin gültig sein, auch wenn die Person, die es ursprünglich angelegt hat, nicht mehr verfügbar ist. Ein Governance-Prozess sollte die für den Dienst verantwortliche Person und die für diesen Zweck nötigen Berechtigungen ermitteln.

Beginnen Sie mit einem repräsentativen technischen Konto. Dokumentieren Sie, welche Anwendung oder welchen Prozess es unterstützt und wer Änderungen autorisieren kann. Gehen Sie nicht davon aus, dass ein passender Personaldatensatz immer die richtige Verantwortungsbeziehung darstellt. Ein Servicekonto kann einen anderen Lebenszyklus erfordern als der alltägliche Zugriff einer Person.

Prüfen Sie während einer Evaluierung von easyIGA den unterstützten Workflow für diesen Kontotyp. Klären Sie, welche Attribute die Quelle liefert und was eine organisatorische Entscheidung bleibt. Eine Liste gefundener Konten belegt für sich genommen weder eine verifizierte Verantwortung noch eine sichere Bereinigung.

Testen Sie einen Wechsel im verantwortlichen Team. Die richtige Maßnahme kann darin bestehen, die Verantwortung zu aktualisieren und den Dienst weiterlaufen zu lassen, oder ein Konto zu entfernen, nachdem die zugehörige Abhängigkeit stillgelegt wurde. Die für die Anwendung verantwortliche Person muss die Folgen und die für die Entscheidung nötigen Nachweise verstehen.

Die Seite zu verwaisten Konten und nicht-menschlichen Identitäten bietet einen Ausgangspunkt für das Gespräch. Speicherung von Zugangsdaten, privilegierte Sitzungen und Maschinenauthentifizierung können zusätzliche Kontrollen erfordern. Identity Governance sollte Verantwortung klar machen, ohne zu suggerieren, dass sie jede technische Sicherheitsfunktion rund um das Konto ersetzt.

NIS2 und CER in das übergreifende Kontrollumfeld einordnen

Die NIS2-Richtlinie zählt Konzepte für die Zugriffskontrolle zu den Risikomanagementmaßnahmen im Bereich der Cybersicherheit (Art. 21 Abs. 2 Buchst. i). Die CER-Richtlinie befasst sich mit der umfassenderen Resilienz kritischer Einrichtungen, einschließlich Verfahren für Personal und Zugang. Ob und wie die Richtlinien anzuwenden sind, muss anhand der Umstände der Organisation und der einschlägigen nationalen Vorschriften bewertet werden. Ausgangspunkt sind die offiziellen Texte von NIS2 und CER.

Übersetzen Sie für die Produktbewertung die relevante Anforderung in eine beobachtbare Frage der Zugriffskontrolle. Wer autorisiert eine Rolle? Welche Quelle stützt das Verhältnis der Person zur Organisation? Welcher Eintrag zeigt die Entscheidung und das Ergebnis? Das Produkt sollte an dieser definierten Aufgabe gemessen werden.

Behalten Sie das umfassendere Resilienzprogramm im Blick. Identity Governance für Anwendungen gewährleistet weder den Schutz physischer Standorte noch Kontinuitätsvorkehrungen oder Notfallbereitschaft. Sie kann innerhalb des konfigurierten Umfangs Einträge und Entscheidungsprozesse beisteuern, doch diese sind nur ein Teil der Verantwortung der Organisation.

Vereinbaren Sie vor dem Pilotprojekt, welche Nachweise benötigt werden. Eine für die Kontrolle verantwortliche Person muss vielleicht eine Stichprobe prüfen, die die Anfrage, die verfügbare Genehmigungshistorie und das Ergebnis im Zielsystem umfasst. Prüfen Sie den vorgeführten Export und seine Felder im vorgesehenen Release. Auch Aufbewahrung und Zugriff auf die Nachweise brauchen betriebliche Regeln.

Dieser Ansatz macht die regulatorische Diskussion konkret, ohne eine Zertifizierung zu versprechen. Die Frage lautet dann, ob der konfigurierte Workflow einen nützlichen Teil der Nachweise der Organisation liefert und was durch andere Systeme und Verfahren bereitgestellt werden muss. Diese Entscheidung kann die für die Kontrolle verantwortliche Person prüfen und dokumentieren.

Auf midPoint aufbauen, ohne die Arbeit der IAM-Fachleute zu verbergen

midPoint ist open source. Die Konfiguration dieser Plattform für Identitätsmanagement und Identity Governance liefert die Grundlage für Identitätsdaten, Rollen und Änderungen in Zielsystemen. easyIGA ergänzt rund um midPoint die fachliche Oberfläche für Anfragen und Überprüfungen.

Eine Organisation, die midPoint bereits nutzt, kann die zusätzliche Ebene mit einer bestehenden Anwendungsrolle evaluieren. Bitten Sie eine Führungskraft, die unterstützte Aufgabe auszuführen, und bitten Sie das Identitätsteam zu erklären, was in der Konfiguration von midPoint verbleibt. Der Vergleich sollte denselben Umfang und denselben Ausnahmefall verwenden.

Legen Sie bei einem neuen Programm zuerst das Rollenmodell und die maßgeblichen Quellen fest. Der Konnektorkatalog hilft, mögliche Integrationsoptionen zu erkennen, doch die Kompatibilität mit dem Zielsystem muss für die tatsächlichen Versionen und Operationen bestätigt werden. Ein bekannter Anwendungsname ist keine vollständige Integrationsspezifikation.

Zur Arbeit der IAM-Fachleute gehören die Pflege von Mappings und das Testen von Richtlinienänderungen. Eine fachbereichsfreundliche Oberfläche macht diese Aufgaben nicht überflüssig. Stattdessen gibt sie den übrigen Beteiligten die Möglichkeit, Entscheidungen beizutragen, ohne die zugrunde liegende Plattform zu administrieren.

Die Seite von Evolveum zu Versorgungsunternehmen beschreibt Anwendungsfälle von midPoint in der Branche. Nutzen Sie für easyIGA eine unterstützende Anwendung, die Ihre Führungskraft im Außendienst und Ihre IAM-Fachleute gleichermaßen kennen. Führen Sie die fachliche Entscheidung vor und prüfen Sie anschließend gemeinsam das protokollierte Ergebnis. Ein gemeinsames Beispiel hilft dem Team, sich darauf zu einigen, welcher Teil des Prozesses verständlicher geworden ist und welche technische Arbeit für das vorgesehene Betriebsmodell weiterhin nötig ist.

Betriebsmodell und kaufmännischen Umfang abstimmen

Selbst gehosteter Betrieb ist das Standardmodell für die Bereitstellung von easyIGA. Für Organisationen ohne geeignete Infrastruktur ist auf Anfrage eine in der EU gehostete Bereitstellung verfügbar, die unser Team betreibt. Die passende Wahl hängt von den tatsächlichen Anforderungen des Versorgungsunternehmens an Betrieb und Daten ab.

Legen Sie fest, wer nach der Implementierung für den Dienst verantwortlich ist. Überwachung, Updates und Wiederherstellung brauchen benannte Zuständigkeiten. Wenn die Organisation einen bestimmten Supportumfang oder bestimmte Wiederherstellungsziele benötigt, vereinbaren Sie diese Bedingungen ausdrücklich. Eine Produktbeschreibung ist nicht als vereinbarte Service-Level-Zusage zu verstehen.

Für midPoint fällt keine Softwarelizenzgebühr an, easyIGA dagegen ist kommerziell. 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. Das veröffentlichte Modell sieht ein jährliches Abonnement pro verwalteter Identität vor; die Einführung im vereinbarten Umfang ist enthalten. Lassen Sie sich die aktuellen Preise und den Funktionsumfang für die tatsächlichen Gruppen von Mitarbeitenden, externen Mitarbeitenden und Servicekonten bestätigen.

Ein brauchbares Angebot nennt die enthaltenen Anwendungsinstanzen und Operationen. Es erläutert außerdem Migrationsarbeit, Datenbereinigung und Abnahmekriterien. Standorte mit unterschiedlichen Systemen oder Betriebsabläufen können unterschiedlichen Integrationsaufwand erfordern, auch wenn sie ähnliche Rollennamen verwenden.

Nutzen Sie die Preisseite und die Informationen zur Bereitstellung, um einen Vergleich auf Grundlage des tatsächlichen Umfangs vorzubereiten. Berücksichtigen Sie den internen Betriebsaufwand und die Umstellungskosten. Messen Sie Verbesserungen im Pilotprojekt, statt eine erfundene pauschale Einsparung auf die gesamte Organisation anzuwenden.

Einen ersten Workflow wählen, der sein Ergebnis belegen kann

Wählen Sie eine unterstützende Anwendung mit einer verantwortlichen Person. Definieren Sie die Zugriffsrolle und die Quelle der Identitätsdaten. Verwenden Sie für die erste Diskussion synthetische Identitäten, damit das Team den Prozess prüfen kann, ohne echte Personal- oder Betriebsdaten offenzulegen.

Nehmen Sie eine gewöhnliche Anfrage und einen Wechsel der Verantwortung auf. Ergänzen Sie ein nicht verfügbares Zielsystem und einen Eintrag mit unvollständiger Historie. Diese Fälle testen die fachliche Entscheidung, die technische Operation und den Umgang mit Unsicherheit. Für jeden Fall sollte ein erwartetes Ergebnis definiert sein.

Fragen Sie die Beteiligten aus den Fachbereichen, ob sie den Zugriff anhand der Beschreibung erklären können. Fragen Sie die Betriebsteams, ob sie eine Ausnahme erkennen und beheben können. Protokollieren Sie das genaue Release und die vorgeführte Konfiguration, einschließlich aller Funktionen, die noch geplant sind oder außerhalb des Umfangs liegen.

Eine erfolgreiche erste Phase sollte zu einer wiederholbaren Entscheidung über die Erweiterung führen. Die Organisation sollte wissen, welche Anwendungen und Operationen verifiziert wurden und welche eine gesonderte Bewertung brauchen. Schließen Sie weder aus einem funktionierenden Konnektor auf allgemeine Kompatibilität noch aus einem erfolgreichen Test auf eine Servicegarantie.

30-minütige Demo anfragen. Bringen Sie zum Gespräch mit unserem Team eine Frage zum Zugriff der Belegschaft aus Ihrem Versorgungsunternehmen mit und prüfen Sie daran, wie der fachliche Workflow von easyIGA und midPoint als Grundlage zu den Verantwortlichkeiten passen, die Ihr Team bereits hat.