Zugriffsrechte, die der Arbeit
an jedem Standort folgen

Zugriff an der Arbeit jedes Standorts ausrichten

Eine Ingenieurin, die eine Raffinerie betreut, eine externe Fachkraft für die Instandhaltung und eine Bürokraft benötigen unterschiedliche Zugriffsrechte. Ihre Verantwortlichkeiten können sich ändern, wenn ein Projekt endet oder eine Person zwischen Standorten wechselt. Das Identitätsprogramm muss diese Änderungen mit den Berechtigungen in den Anwendungen verbinden, die diese Personen nutzen.

easyIGA bietet Mitarbeitenden und Führungskräften eine verständliche Möglichkeit, Zugriffsrechte auf Anwendungen zu beantragen, zu genehmigen und zu überprüfen. midPoint stellt die zugrunde liegende Identity-Governance-Plattform bereit und führt die konfigurierten Änderungen in den angebundenen Systemen aus. Die Personen, die für eine fachliche Entscheidung verantwortlich sind, können mitwirken, ohne midPoint selbst zu administrieren.

Beginnen Sie in der Öl- und Gasbranche mit einem Prozess, dessen Verantwortlichkeit klar ist. Eine Anwendung für die Instandhaltungsplanung oder ein Dokumentensystem für Projekte eignet sich gut als erster Umfang. Legen Sie fest, welche Personen Zugriff benötigen, in welchem Standort- oder Projektkontext dies geschieht und wer berechtigt ist, den Zugriff zu genehmigen. Klären Sie dann, welche Einträge im Zielsystem bestätigen, dass sich der Zugriff tatsächlich geändert hat.

Wer am Standort als Sponsor zuständig ist, muss verstehen, warum eine externe Fachkraft eine Projektanwendung benötigt. Wer die Identitäten administriert, muss wissen, welche Rolle sich ändern soll und ob das Zielsystem die Operation angenommen hat. easyIGA verbindet diese Perspektiven im Workflow für Anfragen und Überprüfungen. Die folgenden Beispielszenarien behandeln die Anwendungen rund um die Arbeit am Standort, einschließlich der Entscheidungen zu Verantwortlichkeit und Integration, die dort nötig sind, wo die Unternehmens-IT auf die Betriebstechnik (OT) trifft.

Ein Wartungsstillstand zeigt den Zugriffslebenszyklus

Betrachten Sie zur Veranschaulichung einen Wartungsstillstand (Turnaround), für den externe Fachkräfte für einen festgelegten Zeitraum an einen Standort kommen. Das Projektteam weiß, wer erwartet wird, doch der Zugriffsprozess muss auch wissen, was jede Person tun darf. Ein Name auf einer Liste externer Mitarbeitender ist noch keine vollständige Entscheidung über Berechtigungen.

Beginnen Sie mit der Quelle der Identitätsdaten. Entscheiden Sie, ob der Datensatz der externen Person aus einem Personalsystem, einem genehmigten Register für externe Mitarbeitende oder einer anderen maßgeblichen Quelle stammt. Klären Sie, wer als Sponsor zuständig ist und welche Informationen nötig sind, um diese Person von jemandem mit ähnlichem Namen zu unterscheiden. Die Implementierung sollte sich nicht auf eine formlose E-Mail als dauerhaften Identitätsnachweis stützen.

Beschreiben Sie anschließend den Zugriff in Begriffen, die die projektverantwortliche Person versteht. Die Rolle kann etwa die Instandhaltungsplanung oder eine festgelegte Dokumentensammlung betreffen. Der Katalog von easyIGA bietet einen fachlich verständlichen Ausgangspunkt, während die Konfiguration die genehmigte Rolle den Berechtigungen im Zielsystem zuordnet. Die Beschreibung im Katalog muss den tatsächlichen Umfang erklären.

Am Ende des Projekts braucht die Organisation eine Entscheidung über die Zugriffsrechte, die bestehen bleiben. Externe Mitarbeitende können vollständig ausscheiden oder in einem anderen Einsatz weiterarbeiten. Alle Konten zu entfernen ist dabei ebenso wenig eine Lösung wie alle Berechtigungen zu belassen; nötig ist eine ausdrückliche Lebenszyklusregel. Definieren Sie die neue Beziehung und die Berechtigungen, die sich daraus ergeben.

Spielen Sie dieses Szenario im Pilotprojekt von Anfang bis Ende durch. Zeigen Sie die erste Anfrage, ihre Genehmigung und das protokollierte Ergebnis. Ändern Sie dann die Zuweisung und prüfen Sie die alten Berechtigungen. So werden die Übergaben zwischen Projektleitung, Identitätsadministration und der für die Anwendung verantwortlichen Person sichtbar.

Standortverantwortliche mitentscheiden lassen

Ein zentrales IT-Team betreut die Systeme womöglich, ohne zu wissen, warum eine externe Fachkraft an einem bestimmten Standort Zugriff braucht. Die Standortleitung versteht die Arbeit, kennt aber womöglich nicht den technischen Namen der benötigten Rolle. Der Workflow sollte es jeder Person ermöglichen, die Informationen beizutragen, für die sie tatsächlich zuständig ist.

easyIGA stellt Anfragen in fachlich verständlichen Workflows dar. Die konfigurierte Richtlinie bestimmt den jeweiligen Entscheidungsweg. Eine Organisation kann diese Struktur nutzen, um die Genehmigung von Zugriffsrechten zu einer klar verantworteten fachlichen Aufgabe zu machen statt zu einer informellen Anweisung, die zwischen Teams weitergereicht wird.

Legen Sie vor der Konfiguration fest, wer welche Rolle genehmigen darf und was geschieht, wenn diese Person abwesend oder nicht mehr zuständig ist. Die Implementierung sollte zeigen, wie das vorgeschlagene Release diese Fälle unterstützt. Gehen Sie nicht von einer ungetesteten Vertretungs- oder Eskalationsregel aus, nur weil es eine Schaltfläche zum Genehmigen gibt.

Bei einer standortspezifischen Rolle braucht die genehmigende Person eine zutreffende Beschreibung des Anwendungszugriffs. Die Beschreibung sollte nicht nahelegen, dass eine Berechtigung in einer Anwendung eine weiter reichende betriebliche Befugnis verleiht. Ein System für Instandhaltungsaufzeichnungen und die Erlaubnis, an Anlagen zu arbeiten, sind getrennte Angelegenheiten, sofern Ihr genehmigter Prozess sie nicht ausdrücklich verknüpft.

Nehmen Sie in die Evaluierung eine Anfrage mit unvollständigen Angaben zum Sponsor auf. Das Team sollte das Problem erkennen und die Anfrage zur Korrektur weiterleiten können. Eine fehlende fachlich verantwortliche Person ist ein betriebliches Problem, das gelöst werden muss. Sie ist kein Grund, eine entscheidende Person zu erfinden oder die Anfrage als automatisch genehmigt zu behandeln.

Offline-Zielsysteme als betriebliche Gegebenheit behandeln

Manche Umgebungen können keine ständige Verbindung zu jedem relevanten System bereitstellen. Selbst ein normalerweise angebundenes Zielsystem kann während einer Wartung nicht verfügbar sein. Eine zentral getroffene Identitätsentscheidung beweist nicht, dass ein isoliertes Zielsystem die Änderung bereits erhalten und umgesetzt hat.

easyIGA unterscheidet zwischen verifizierten, ausstehenden, fehlgeschlagenen und unbekannten Ergebnissen. Das hilft der Organisation, eine abgeschlossene Entscheidung von einer bestätigten Operation zu trennen. Welche Bestätigung verfügbar ist, hängt vom Konnektor und vom Verhalten des Zielsystems ab. Das sollte für jedes System im Umfang bewertet werden.

Klären Sie, was eine ausstehende Änderung betrieblich bedeutet. Soll ein Zugriff enden, muss das zuständige Team wissen, ob das Zielsystem die Anweisung umgesetzt hat und welche Kontrollen gelten, solange keine Bestätigung vorliegt. Die angemessene Reaktion hängt vom System und von den Verfahren der Organisation ab; sie lässt sich nicht auf ein allgemeingültiges Versprechen auf einer Website reduzieren.

Ein sinnvoller Test bezieht bewusst ein nicht verfügbares Zielsystem ein. Beobachten Sie den protokollierten Status, die Informationen, die dem Betriebspersonal zur Verfügung stehen, und das Verhalten, nachdem die Verbindung wiederhergestellt ist. Prüfen Sie, wie doppelte oder wiederholte Operationen in der konfigurierten Integration behandelt werden. Halten Sie das tatsächliche Ergebnis fest, statt anzunehmen, dass automatische Wiederholungsversuche jeden Fehler beheben.

Das Reporting sollte diese Unterscheidung beibehalten. Wer jeden genehmigten Entzug von Zugriffsrechten als abgeschlossen zählt, kann unerledigte Arbeit verdecken. Eine klare Übersicht über offene Operationen gibt den Verantwortlichen für Standort und Anwendung eine Grundlage für die Nachverfolgung. Sie verhindert außerdem, dass eine fachliche Genehmigung zu einem irreführenden Nachweis über den aktuellen Zustand eines Kontos im Zielsystem wird.

Vor der Anbindung die Grenze zwischen IT und OT ziehen

Betriebstechnik (OT) unterstützt physische Prozesse. Ein Gespräch über Identity Governance sollte klären, welche Anwendungen und administrativen Schnittstellen geeignete Integrationsziele sind und welche außerhalb des Umfangs bleiben. Dass ein Identitätskonnektor vorhanden ist, ist keine Erlaubnis, Änderungen in einer sensiblen Betriebsumgebung zu automatisieren.

Beginnen Sie mit der für die Anlage verantwortlichen Person und den betrieblichen Anforderungen. Ermitteln Sie, welche Auswirkung eine Änderung an einem Konto oder einer Berechtigung hat. Legen Sie fest, wie diese Änderung getestet, genehmigt und bei Bedarf rückgängig gemacht wird. Die Identitätsimplementierung muss dem Änderungsmanagement der Organisation und den Einschränkungen des Zielsystems folgen.

In einer ersten Phase kann sich der Umfang auf die Unternehmensanwendungen und die Anwendungen für die Belegschaft rund um den Betrieb beschränken. Instandhaltungsplanung, Dokumentenzugriff und die Zusammenarbeit mit Lieferanten können klare fachliche Verantwortliche haben, ohne dass dies eine direkte Kontrolle über eine Steuerung in der Produktion bedeutet. Die Auswahl muss der Bewertung der Organisation folgen, nicht einem allgemeinen Branchendiagramm.

midPoint bietet Mechanismen für die konfigurierte Identitätsintegration. easyIGA liefert fachlich verständliche Entscheidungen rund um den unterstützten Workflow. Keine der beiden Beschreibungen belegt, dass ein bestimmtes Industriesystem kompatibel ist, dass eine Verbindung sicher ist oder dass die Governance von Anwendungen ein spezialisiertes OT-Sicherheitsprogramm ersetzt.

Halten Sie die Grenze im Abnahmeprotokoll sichtbar. Geben Sie an, welche Systeme angebunden wurden, welche Operationen vorgeführt wurden und welche manuell oder außerhalb des Umfangs blieben. Ein Diagramm sollte die tatsächlich genehmigte Beziehung zwischen den Ebenen zeigen. Vermeiden Sie eine große Sammlung von Anwendungslogos, die suggeriert, jede betriebliche Schnittstelle sei bereits integriert.

Zugriff nach Projekt und Verantwortung prüfen

Externe Mitarbeitende können ein Projekt abschließen, während ihr Arbeitgeber weiterhin aktiver Lieferant bleibt. Wer fest angestellt ist, kann an einen anderen Standort wechseln und dabei Berechtigungen behalten, die zur bisherigen Rolle gehörten. Zugriffsüberprüfungen helfen einer verantwortlichen Person, diese Berechtigungen anhand der aktuellen Verantwortung neu zu bewerten.

easyIGA zeigt die zu überprüfenden Zugriffsrechte mit den verfügbaren Nachweisen an. „Letzte Nutzung“, „Gewährt von“ und „Genehmigt von“ hängen von den angebundenen Quellen und der erfassten Genehmigungshistorie ab. Eine prüfende Person sollte verstehen, welche Fakten vorliegen und welche nicht verfügbar bleiben.

Legen Sie bei einer Projektüberprüfung zuerst die zu prüfenden Identitäten und den Anwendungsumfang fest. Die projektverantwortliche Person kann vielleicht den Dokumentenzugriff beurteilen, nicht aber ein technisches Servicekonto, das eine Integration unterstützt. Wer beides ohne Erklärung derselben prüfenden Person zuweist, riskiert eine abgeschlossene Kampagne mit schwachen Entscheidungen.

Eine sinnvolle Stichprobe enthält eine Person, die den Standort gewechselt hat, eine externe Fachkraft, deren Einsatz beendet ist, und eine Berechtigung mit unvollständiger Historie. Das sind Beispielfälle, keine Aussagen über eine automatische Erkennung in easyIGA. Zeigen Sie, wie das vorgeschlagene Release jeden Eintrag darstellt und wie die prüfende Person zu einer Entscheidung kommt.

Bei Anfragen, die über das Produkt gestellt werden, protokolliert easyIGA die antragstellende Person und die erfassten Genehmigungsschritte. Zugriffsrechte, die außerhalb von easyIGA vergeben wurden, werden gesondert ausgewiesen; dafür dienen die von midPoint protokollierten Erstellungsdaten. Bei historischen Einträgen kann die genehmigende oder vergebende Person fehlen; fehlende Informationen werden ausdrücklich angezeigt.

Servicekonten fest einem verantwortlichen Team zuordnen

Ein Konto, das von einer Schnittstelle zur Einsatzplanung oder einem Reporting-Job genutzt wird, kann weiterhin nötig sein, auch wenn die Person, die es ursprünglich eingerichtet hat, ausgeschieden ist. Wer jedes Konto wie ein Mitarbeiterkonto behandelt, trifft deshalb womöglich eine falsche Entscheidung über das Entfernen. Nicht-menschliche Identitäten brauchen eigene Angaben zu Verantwortlichkeit und Zweck.

Ermitteln Sie zuerst die Anwendung oder den Prozess, der von dem Konto abhängt. Legen Sie das dafür verantwortliche Team und die benötigten Berechtigungen fest. Klären Sie, wie Zugangsdaten und Laufzeitberechtigungen durch die zuständigen Sicherheitskontrollen verwaltet werden; diese Seite behauptet nicht, dass easyIGA einen Tresor für privilegierte Zugriffe oder ein System für das Secrets-Management ersetzt.

Eine Evaluierung im Bereich Identity Governance kann untersuchen, wie das Konto abgebildet und wie die Verantwortlichkeit überprüft wird. Der vorgeschlagene Workflow sollte den Unterschied zwischen einer zugeordneten Person und dem für den Dienst verantwortlichen Team verständlich machen. Eine vorgeschlagene Personenzuordnung beweist nicht automatisch, dass das Konto dem Beschäftigungslebenszyklus dieser Person folgen sollte.

Wählen Sie für die Demo ein repräsentatives technisches Konto aus. Beschreiben Sie, was ausfallen würde, wenn es deaktiviert würde, und wer berechtigt ist, über eine Änderung zu entscheiden. Fragen Sie, wie der Eintrag einer Verantwortung zugeordnet bleibt, wenn sich das verantwortliche Team ändert. So wird ein anderer Lebenszyklus sichtbar als beim gewöhnlichen Austritt von Mitarbeitenden.

Der Überblick zu verwaisten Konten und nicht-menschlichen Identitäten bietet weiteren Kontext. Prüfen Sie den Workflow und die Integrationsabdeckung des aktuellen Releases, bevor Sie dies in den Kaufumfang aufnehmen. Ein klarer Prozess für die Verantwortlichkeit ist auch dann nützlich, wenn manche Nachweise eine Untersuchung erfordern, vorausgesetzt, die Unsicherheit ist sichtbar.

midPoint als Basis mit klaren Verantwortlichkeiten nutzen

midPoint ist open source und deckt Identitätsmanagement und Identity Governance ab. Seine Konfiguration verbindet Identitätsquellen mit Rollen und Operationen in Zielsystemen. easyIGA ergänzt midPoint um die fachliche Benutzererfahrung für Anfragen und Zugriffsentscheidungen.

Für ein bestehendes midPoint-Team bietet dies eine Möglichkeit, die zusätzliche Benutzererfahrung zu bewerten, ohne von einem Ersatz von midPoint auszugehen. Behalten Sie im Vergleich dieselbe Anwendung und dieselbe Rolle bei. Bitten Sie die fachlich beteiligte Person, die unterstützte Aufgabe zu erledigen, und die technische Fachkraft, die zugrunde liegende Konfiguration und den Ausnahmepfad zu erklären.

Der Konnektorkatalog ist ein Ausgangspunkt für die Recherche zur Integration. Prüfen Sie die genaue Systemversion, die Authentifizierungsmethode und die benötigten Operationen. Ein Zielsystem kann Konten bereitstellen und einige Berechtigungen zugleich über eine separate Schnittstelle abbilden. Diese Unterscheidung beeinflusst sowohl den Umfang als auch die Nachweise.

Die Mappings und die Richtlinienkonfiguration bleiben in der Verantwortung technischer IAM-Fachleute. Ein gut lesbares Anfrageformular bereinigt keine inkonsistenten Quelldaten und schafft kein sicheres Rollenmodell. Nehmen Sie diese Aufgaben in den Umsetzungsplan auf, damit die fachliche Benutzerfreundlichkeit auf einem Identitätsmodell beruht, das die Organisation versteht.

Die Seite zu Öl und Gas von Evolveum bietet Branchenkontext zu midPoint. Verbinden Sie diese technische Grundlage mit einer easyIGA-Demo der von Ihnen gewählten Standortanwendung. Die als Sponsor zuständige Person kann die Zugriffsbeschreibung bewerten, die für die Anwendung verantwortliche Person kann die abgebildete Verantwortung prüfen, und das Identitätsteam kann bestätigen, wie die konfigurierte Änderung das Zielsystem erreicht. So hat jede beteiligte Person eine klare Rolle bei der Abnahme des vorgeschlagenen Prozesses.

Nachweise wählen, die der Standort tatsächlich nutzen kann

Eine Audit-Anfrage kommt oft erst nach dem betrieblichen Ereignis. Hat die Organisation nicht vereinbart, welche Einträge aufbewahrt werden, kann die Rekonstruktion der Entscheidung bedeuten, mehrere Systeme zu durchsuchen und mit Personen zu sprechen, die ihre Rolle bereits gewechselt haben.

Definieren Sie die Anforderungen an Nachweise gemeinsam mit dem Workflow. Die Person, der beantragte Zugriff und die Entscheidung sind relevant, aber ebenso das protokollierte Ergebnis. Eine genehmigte Anfrage, die ihr Zielsystem nie erreicht hat, sollte von einer verifizierten Änderung unterscheidbar bleiben.

Bitten Sie für die Evaluierung die für die Kontrolle verantwortliche Person, eine Stichprobe auszuwählen. Verfolgen Sie sie von der fachlichen Anfrage über die verfügbare Historie bis zum Ergebnis im Zielsystem. Prüfen Sie den vorgeführten Export im vorgeschlagenen Release, statt anzunehmen, dass jedes Feld der Oberfläche in jedem Exportformat erscheint.

Die Aufbewahrung von Nachweisen und der Zugriff darauf sind betriebliche Entscheidungen. Legen Sie fest, wer Einträge abrufen darf, wie lange sie benötigt werden und welche sensiblen Informationen sie enthalten. Ein Quellfeld sollte nicht nur deshalb erfasst werden, weil ein Konnektor es lesen kann. Sein Zweck in der Kontrolle sollte nachvollziehbar sein.

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 Anwendbarkeit und die maßgeblichen nationalen Vorschriften muss die Organisation selbst bewerten. Siehe dazu den offiziellen NIS2-Text. Ein Identitäts-Workflow unterstützt einen definierten Teil des Kontrollumfelds; er begründet für sich allein weder eine umfassendere Einhaltung regulatorischer Vorgaben noch die Resilienz eines Standorts.

Den gesamten Lieferumfang 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 für Sie organisieren und in Ihr Angebot aufnehmen. easyIGA hat ein kommerzielles Abonnementmodell; veröffentlicht ist eine jährliche Gebühr pro verwalteter Identität, wobei die Einführung im vereinbarten Umfang enthalten ist. Holen Sie ein aktuelles schriftliches Angebot für die tatsächlich benötigten Identitätsgruppen und Funktionen ein.

In der Öl- und Gasbranche sollte der Umfang erklären, wie Standorte, Umgebungen und Gruppen externer Mitarbeitender gezählt werden. Eine einzelne Unternehmensanwendung kann mehrere Instanzen mit unterschiedlichen Betriebsregelungen haben. Klären Sie, ob die vorgeschlagene Lieferung jede Instanz abdeckt und wie die Verantwortung für Zugriffsrechte über alle Instanzen hinweg gepflegt wird.

Berücksichtigen Sie die Verantwortlichkeiten für Datenbereinigung und Migration. Ein Register externer Mitarbeitender mit inkonsistenten Kennungen kann Vorarbeit erfordern, bevor es zu einer zuverlässigen Identitätsquelle wird. Ein alter Rollenkatalog muss womöglich fachlich überprüft werden, bevor er als verständliche Auswahl von Zugriffsrechten dargestellt werden kann. Diese Tätigkeiten sollten im Projektplan sichtbar sein.

Berücksichtigen Sie neben der Erstkonfiguration auch den laufenden Betrieb. Klären Sie, wer Konnektoren nach Upgrades der Zielsysteme pflegt, wer fehlgeschlagene Operationen behebt und wer Rollendefinitionen aktualisiert, wenn sich die Arbeit ändert. Eine inbegriffene Einführung ist keine unbegrenzte Zusage für jede künftige Integration.

Nutzen Sie das Preismodell und den Kostenrechner mit Ihren eigenen Zahlen. Messen Sie den aktuellen Bearbeitungsaufwand und vergleichen Sie ihn mit einem Pilotprojekt für denselben Prozess. Behandeln Sie eine hypothetische Verringerung des Zeitaufwands der Mitarbeitenden nicht als garantierte Kosteneinsparung. Ein belastbarer Business Case hält Annahmen und gemessene Ergebnisse getrennt.

Den Betrieb vorbereiten, bevor der Rollout ausgeweitet wird

Beginnen Sie mit einem abgegrenzten Anwendungsumfang und einer verantwortlichen Person. Dokumentieren Sie die Quelldaten, die beantragten Rollen und die Operationen in den Zielsystemen. Vereinbaren Sie, was die fachlich beteiligte Person sehen soll und was das Betriebspersonal tun soll, wenn der Prozess nicht abgeschlossen werden kann.

Bei easyIGA ist der selbst gehostete Betrieb der Standard. Auf Anfrage ist auch eine in der EU gehostete Bereitstellung verfügbar, die für Sie betrieben wird. Wählen Sie das Bereitstellungsmodell anhand Ihrer eigenen Anforderungen an Infrastruktur und Sicherheit und legen Sie dann die Verantwortlichkeiten für Support und Wiederherstellung fest. Der Standort einer Bereitstellung allein belegt weder die Verfügbarkeit des Dienstes noch seine Eignung für eine zugangsbeschränkte Umgebung.

Spielen Sie den regulären Ablauf und die Ausnahmefälle durch, bevor Sie weitere Standorte hinzufügen. Nehmen Sie einen fehlerhaften Quelldatensatz, eine nicht verfügbare Anwendung und einen Rollenwechsel auf, der alte Zugriffsrechte entzieht. Halten Sie das Verhalten des tatsächlichen Releases und der tatsächlichen Konfiguration fest. Verwenden Sie synthetische Identitäten, bis die Organisation die Nutzung echter Daten genehmigt hat.

Entscheiden Sie nach dem Pilotprojekt, welche Nachweise eine Ausweitung stützen. Dazu sollte gehören, ob die Beteiligten aus dem Fachbereich die Anfrage verstehen und ob das Betriebspersonal Ausnahmen lösen kann. Eine erfolgreiche Demo einer Anwendung sollte zu einem klar abgegrenzten nächsten Schritt führen, nicht zu der Annahme, dass alle Zielsysteme gleichwertig sind.

Demo anfragen. Bringen Sie dazu ein nicht sensibles Beispiel aus Ihrer eigenen Arbeit mit. Das Gespräch kann sich dann auf die Zugriffsentscheidung, die beteiligten Systeme und die Nachweise konzentrieren, die nötig sind, um von einer ansprechenden Oberfläche zu einem betrieblich tragfähigen Prozess zu kommen.