Ende des Jahres ziehen alle langsam Bilanz.

Für mich war dieses Jahr das Projekt der Implementierung von Single Sign On (SSO) zwischen SAP und Windows in Erinnerung geblieben. In diesem Artikel werde ich über die Erfahrungen mit Implementierung und Projektmanagement, Fallstricke, Ergebnisse und Schlussfolgerungen berichten.

Das Unternehmen ist ein großes Transportunternehmen in Belgien, das U-Bahn, Straßenbahn und Bus kombiniert. Es gibt mehr als 10.000 Mitarbeiter, von denen fast zweitausend Backoffice-Mitarbeiter sind, die viele Tools verwenden: Unternehmenswebsite, E-Mail, Anwendungsservice, Sharepoint, Archivar und natürlich SAP.

SAP ist überall: von der Buchhaltung und Personalabteilung über die Registrierung der Bewegung von Transporteinheiten, die Dokumentation von Unfällen, Analysen, Beschaffung, Lagerung usw.

Problem:

• SAP for PC User ist eine separate Anwendung, für die Sie Ihr Passwort eingeben müssen
• Zuerst müssen Sie ein Passwort anfordern und sich dann daran erinnern. Der technische Support muss Anrufe entgegennehmen, um Kennwörter zu erstellen und zu ändern.
• Aus Sicht des Benutzers ist ein zusätzliches Passwort ein zusätzlicher Aufwand. Leute speichern Passwörter auf Papier oder machen sie zu einfach. Sicherheit schreit über grobe Verstöße.
• Die Mindestanforderungen für ein Kennwort für einen PC stimmen nicht mit den Kennworteinstellungen in SAP überein. Wenn Sie sie auf einen gemeinsamen Nenner bringen, ist es besser, SSO sofort zu implementieren.

Ziel: Implementieren Sie ein SSO zwischen Windows und SAP, damit sich der Benutzer bei der Anmeldung bei Ihrem PC-Konto bei SAP anmelden kann, ohne ein Kennwort einzugeben.

Wenn Sie sich nicht mit SAP beschäftigen, wird Sie dieser Artikel aus Sicht des Projektmanagements interessieren, da die Pioniere dieser Details (in Klammern) angegeben werden.

Unter dem Schnitt:

1. Geltungsbereich
   1.1 Umfang Menschen
   1.2 Umfangssysteme
2. Komponenten
   2.1 Systemparameter ändern
   2.2 Windows Active Directory (AD)
   2.3 SAP Secure Login Client (SLC)
   2.4 Einen SAP-Benutzer an seine AD binden
   2.5 Ändern der Datei SAP logon.ini
3. Testen
4. SNC ist eine Sicherheitslücke
5. Teamarbeit
6. Geschäftsinformationen
7. Übersetzungsschwierigkeiten
8. Zusammenfassung und Schlussfolgerungen

Einführung

Wenn Sie nicht gerne Standardkegel ausfüllen möchten, finden Sie hier eine Liste von Fragen, die Sie zu Beginn des Projekts selbst klären sollten:

• Projektumfang (Systeme, Benutzer - in welcher Reihenfolge implementieren wir, wo ist die Priorität und was kann verworfen werden, wenn etwas schief geht, welche Benutzer sollten Zugriff erhalten usw.)
• Die vom Projekt betroffenen Hauptabteilungen (Auch wenn das Projekt tangential ist, ist es dennoch wichtig, dass alle im Voraus informiert werden)
• Ihre Befugnisse (Es ist nicht sehr einfach, hier wegzulaufen - in einem europäischen Unternehmen basiert alles auf Zustimmung und freiwilligem Wunsch zu helfen. Wenn die Abteilung angibt, dass sie keine Ressourcen haben, ist es fast unmöglich, Druck auszuüben und zu „erzwingen“. Sie können jedoch beispielsweise einen externen Berater um Hilfe bitten.)
• Timing (Für das gesamte Projekt und für bestimmte Teile)
• Genehmigungsverfahren (bürokratische Vorschriften - in einem großen Unternehmen ist dies nicht die letzte Frage)
• Mögliche Schwierigkeiten (Alle. Möglich. Schwierigkeiten.)

Wir haben die Mitgliedschaft im Projekt mehrmals geändert: Zunächst waren es nur die Berechtigungsabteilung in SAP und die Administratorenabteilung (Grundkomponenten). Dann kamen die Abteilung für Autorisierung in Windows (Active Directory, AD) und die Abteilung für die Implementierung von Updates (Verpackung) hinzu, dann die Abteilung für Datenbanken und die Abteilung für mobile Anwendungen usw.

Ein externer Berater wurde für die technische Seite der Angelegenheit eingeladen, und der Projektmanager (PM) wurde zu mir als Person, die an der Autorisierung in SAP beteiligt ist (daher werden in diesem Artikel mehr Details zur Autorisierung in SAP als in anderen Artikeln enthalten sein).

Eine wichtige Klarstellung: Jeder Zugriff, den wir in SAP gewähren, wird angepasst. Wir verwenden nicht die Standardrollen, die das System bietet, sondern erstellen neue Rollen, nach Abteilung, Position, Funktion. Bisher haben wir keine Synchronisation zwischen SAP- und Windows AD-Benutzern. Wenn Ihr Benutzer beispielsweise über Administratorrechte im lokalen Netzwerk verfügt, bedeutet dies nicht, dass er auch Administrator in SAP ist.

1. Geltungsbereich

1.1 Umfang Menschen

Die Mitarbeiter unseres Unternehmens verwenden SAP über eine Anwendung auf einem Personal Computer (Thin Client - SAP Logon GUI), aber nicht nur. Wie werden die Benutzer gezählt, die unter die Verteilung fallen?

Wir haben alle zugrunde gelegt, die sich täglich über SAP Logon (SAP User Type Dialogue) von Laptops aus verbinden. In dieser Kategorie das gesamte Backoffice - Verwaltungspersonal, Bukhs, Ichars, Entwickler, Tester, Logistik usw.

Ausgeschlossen:

• diejenigen, die einen Desktop-Computer haben, keinen Laptop
• 8.000 Benutzer, die niemals die SAP-Anmeldung öffnen, sondern SAP über die Website und Anwendungen verwenden (SAP-Benutzertyp Kommunikation)
• alle externen Benutzer (keine Mitarbeiter, müssen sich aber über VPN am System anmelden)

1.2 Umfangssysteme

In unserem Unternehmen verwendet SAP sechs aktive Landschaften ( ECC, BI, SRM, Netweaver, PI, Solution Manager ), ohne die Sandboxen. Jeder von ihnen hat seine eigene DEV , ACC , PRD - d.h. Tatsächlich sind es 6 * 3 = 18 Systeme.

Durch Vokalabstimmung wurde beschlossen, nur die ersten vier Landschaften aufzunehmen. PI und SM werden von einem engen Kreis von Administratoren verwendet und erfordern eine Aktualisierung des Systems selbst (zumindest eine Aktualisierung der SAP_BASIS-Komponente auf Version 740). Andernfalls wird die Transaktion sncwizard nicht unterstützt, und die manuelle Ausführung ist für 10 bis 20 Personen zu mühsam.

2. Komponenten

Personen, die an diesen Details interessiert sind, finden auf der SAP-Website schrittweise Anweisungen sowie die verschiedenen verfügbaren Methoden (wir haben SSO basierend auf Kerberos ausgewählt , dies ist jedoch nicht immer eine offensichtliche Option).

Aus einer sehr vereinfachten Sicht (von mir) ist SSO ein Add-On in SAP, mit dem Sie sich mit Ihrem Windows-Konto anmelden können. Sie schalten den Computer ein, geben das Passwort ein und doppelklicken nur, um sich bei SAP anzumelden.

Damit Magie funktioniert, benötigen Sie 5 Komponenten:

2.1 Ändern von Systemparametern (Instanzen SAP)

Im SAP-System ( ECC , BI , SRM , Netweaver ) müssen Sie den Parameter snc / enable = 1 aktivieren. Dies erfolgt über den sncwizard und umfasst die Vorbereitung, den Neustart des Systems und die letzten Aktivierungsschritte.

Wir haben die Parameter vorher und nachher mit Hilfe dieser Berater, Unterstützung durch andere Abteilungen und Versuch und Irrtum herausgefunden. Das Schwierigste dabei war, das System neu zu starten.

Es ist immer schwierig, PRD in der Produktion neu zu starten, da rund um die Uhr gearbeitet wird. Und in einem Transportunternehmen ist dies doppelt komplizierter: Der Transport bewegt sich von fünf Uhr morgens bis ein Uhr morgens, auch am Wochenende. Alle Schwierigkeiten mit PRD betreffen nicht nur die Mitarbeiter des Unternehmens, sondern die gesamte Stadt und Zehntausende von Menschen. Mit anderen Worten - Sie müssen die Zeit minimieren, in der das System nicht verfügbar ist, und wenn möglich mit anderen Updates kombinieren. Gleichzeitig sollte die Bürokratie nicht unterschätzt werden: Neustart ist ein Datum, eine Uhrzeit, eine Dauer (wenn die Parameter nicht beim ersten Mal gespeichert werden) und eine Geschäftsbenachrichtigung.

Wir hatten vier SAP PRD-Systeme: ECC, Netweaver, SRM, BI - zum Neustart

ECC ist das wichtigste, alle Echtzeitdaten und Haupttransporte sind daran gebunden: Busse, Straßenbahnen.

Daten aus dem Netweaver- System (Unfälle, mobile Anwendungen) sowie aus ECC-Systemen werden bereits um 3 Uhr morgens verwendet. Wenn die Straßenbahn nicht fährt, gehen die Reparaturmannschaften.

SRM- System - hauptsächlich für die Beschaffung verwendet und jeden Tag nach 18:00 Uhr verfügbar.

Bei BI besteht die Schwierigkeit darin, dass an Wochenenden Datenflüsse vom ECC zum System geleitet werden. Außerdem werden Berichte aus dem BI manchmal vom Top-Management außerhalb der Geschäftszeiten verwendet.

Insgesamt dauerte es 2 Wochen, um alle PRDs neu zu starten.
Dem PS-Neustart jedes PRD-Systems gingen Neustarts aller DEV und ACC voraus, die einfacher zu koordinieren sind, aber auch eine Planung erfordern.

2.2 Windows Active Directory (AD)

Für Active Directory muss ein spezieller technischer Benutzer (SAP Kerberos) erstellt werden. Dieser Benutzer wird sich an Windows wenden, um eine Kopie des Eingabetickets für SAP zu erhalten. Ein solcher AD-Service-Benutzer reicht für alle SAP-Systeme aus.

Dieser Teil wurde vollständig von unserem externen Berater und dem Active Directory-Team erstellt. Er enthielt mehrere Iterationen, um die Parameter zu verfeinern und die spezielle Bibliothek zu konfigurieren, aber für mich blieb er eher eine "Black Box".

2.3 Installieren des SAP Secure Login Client (SLC) auf dem Computer eines Benutzers

Dieses Programm selbst macht nichts. Sie benötigen es, um ein Ticket von AD zu speichern, das Ihren Benutzer bei der Anmeldung bei einer Windows-Sitzung bestätigt, und dieses Ticket bei Bedarf zur Autorisierung an SAP zu senden. SLC kann sofort zu Beginn des Projekts für alle Benutzer installiert werden - ohne die anderen SSO-Komponenten funktioniert es sowieso nicht.

2.4 Einen SAP-Benutzer an seinen AD-Benutzer binden

Wie bereits erwähnt, gibt es in unserem Unternehmen keine Einzelbenutzerverwaltung. Der Zugriff auf verschiedene Systeme erfolgt über verschiedene Teams. In diesem Fall unterscheidet sich die Benutzeranmeldung in SAP vom Benutzernamen in Windows. Beispielsweise ist Benutzer # 45011 in AD Ivan Ivanov oder IVANOVI . Es ist dieser Haufen, der in SNC ausgefüllt werden muss (über die Transaktion SU01, Feld SNC, p: CN = ADname @ domain).

Unser Unternehmen verfügt nicht über SAP Identity Management. Daher mussten zwei Probleme gelöst werden: neue Benutzer erstellen und die Parameter bestehender Benutzer aktualisieren.

Erstellen Sie neue Benutzer
Im Hauptsystem (ECC) werden jeden Arbeitstag 4-6 neue Anmeldungen erstellt, dies sind fast 1000 neue Benutzer pro Jahr. Der Prozess ist automatisiert: Beim Erstellen eines Benutzers gibt das Programm seine Adresse, seinen Namen und die Grundeinstellungen ein. Wir haben beschlossen, dass das Programm bei der Benutzererstellung auch das SNC-Feld ausfüllt, unabhängig davon, ob die Person danach SSO in SAP benötigt oder nicht.

Der Haken war, dass Sie für jeden Benutzer einen eindeutigen eigenen Namen in AD eingeben müssen, d. H. es ist nicht für jeden der gleiche Parameter - d.h. Es ist erforderlich, dass das Programm selbst in AD nach dem Benutzernamen sucht und diesen in SAP ausfüllt.

Der Entwickler hat das Programm schnell aktualisiert. Der Code und die grundlegenden Tests dauerten 2 Tage, aber die Daten für die Überprüfung in ACC passten nicht zu uns (AD wurde nicht aktualisiert), sodass wir die Änderungen sofort an PRD schickten. Es stellte sich heraus, dass alles komplizierter ist als wir dachten. Im Verlauf der Untersuchung kamen wir zu folgendem Schema:

1. Zunächst werden Benutzer im HR-System erstellt (in SAP sind sie in PA20 zu sehen).
2. Dann werden sie zusammen mit Daten über die Abteilung, Position, Position, ob es sich um das führende Glied usw. handelt, in die Z-Tabelle kopiert.
3. Dann werden die Benutzerdaten an AD gesendet und hier erstellt das System einen Benutzer in Windows und gibt ihm einen Namen in AD und E-Mail
4. Der PI-Fluss in diesem Diagramm dient lediglich dazu zu verstehen, dass es sich um einen Drittanbieterprozess des dritten Systems handelt
5. Die Daten werden zurück in SAP kopiert (in der neuen Z-Tabelle), diesmal nur die AD-Namen und Mail-Adressen
6. In der letzten Phase wird das Z-Programm gestartet, das Benutzer in SAP ( SU01 ) erstellt. Nicht alle Benutzer, die im HR-System erstellt werden, werden später in SAP erstellt. Es gibt viele, die SAP letztendlich nicht verwenden

Es dauerte fast zwei Wochen, um zu suchen, Änderungen zu koordinieren und einen Zeitplan für das Aktualisieren und Laden / Entladen von Tabellen zu vereinbaren. Es war eine Frage der Synchronisation - das Benutzererstellungsprogramm (Punkt 6) sollte unbedingt gestartet werden, nachdem alle anderen Programme bereits ausgearbeitet und die Daten in Tabellen kopiert wurden. Infolgedessen haben wir zwei Wochen lang nachverfolgt, wann und zu welchem ​​Zeitpunkt das Programm endete, und das Programm getestet.

Wenn Benutzer mit dem ausgefüllten SNC-Feld erstellt werden, jedoch ohne die erforderlichen AD-Namen, können Sie in SU01 alle unglücklichen Benutzerassoziierten sehen, die an einen nicht vorhandenen AD-Benutzer gebunden sind.

Aktualisieren vorhandener Benutzereinstellungen
Gerade weil unser Login SAP und Windows nicht übereinstimmen, konnten wir die Standard-SAP-Lösung für die Massenfüllung im SNC-Feld ( RSUSR300 via SNC1-Programm ) nicht verwenden.

Infolgedessen habe ich die Daten von 10.000 vorhandenen Benutzern mithilfe eines provisorischen Skripts ( SAP eCATT ) aktualisiert , Benutzerdaten manuell hochgeladen und eine Variante erstellt. Um erfolgreich zu sein, musste ich beide eCATT-Systeme in PRD und ACC für Änderungen öffnen und Entwicklern Millionen von Cookies versprechen.

2.5 Ändern der Datei SAP logon.ini

Technisch ist dies 1 Minute. In den Dateieigenschaften muss nur beachtet werden, dass eine Verbindung über SNC verfügbar ist .

Die Schwierigkeit besteht darin, dass sich diese Datei lokal auf dem PC des Benutzers befindet und zweitausend Benutzer sie ändern müssen.

Tatsächlich war für uns die endgültige Implementierung der Moment, in dem die neue Datei sap.logon.ini unter den Benutzern verteilt wurde, anstatt die PRD-Parameter zu ändern. Denn selbst wenn die ersten vier Komponenten bereits fertig sind und die letzte fünfte nicht, wird keine Magie stattfinden.

Mit dem letzten Absatz kam ein kleiner Vorfall. Ich habe dem Management gemeldet, dass wir 2.000 Benutzer haben, auf denen das Update installiert sein wird, und als es Zeit für die Implementierung war, haben sie mir einen Status gesendet, in dem 3.500 von ihnen waren. Ich fühlte mich unwohl. Das liegt daran, dass ich meinerseits nur aktive SAP-Benutzer gesehen habe, aber in Wirklichkeit wurde das Update an alle persönlichen Laptops gesendet, die viel mehr im Unternehmen sind. Gott sei Dank sind keine technischen Fehler aufgetreten.

3. Testen

Wie teste ich SSO? Entweder funktioniert es oder nicht. Unser Entwickler schnaubte und sagte, dass Sie nichts testen müssen. Sobald alles in der Sandbox funktioniert, müssen Sie es an die Produktion senden. Natürlich. Niemand wird sagen, dass er Code mit Fehlern schreibt.

Sie müssen überprüfen:

• Funktioniert die SAP-Anmeldung direkt nach dem Neustart mit SSO?
• können Benutzer SSO verwenden, wenn sie mit VPN verbunden sind
• Schwierigkeiten für Entwickler anderer Systeme beim Ändern der SAP-Anmeldung

SSO ist kein Programm, es ist schwierig, es konsequent zu implementieren. DEV - ACC - PRD. Trotzdem sind erste Tests erforderlich, um alles zu erfassen, was möglicherweise schief gehen könnte. In diesem Fall wird die Verteilung der neuen SAP logon.ini getestet, wenn alle Komponenten bereits ausgeführt werden. Wir haben DEV und ACC mit Entwicklern und die neue SAP logon.ini mit PRD mit einer Auswahl von Geschäftsbenutzern getestet.

Was sie gefunden haben:

• Manchmal (1 Fall pro 500) müssen Sie SAP Logon oder SLC vollständig neu installieren
• Hauptbenutzer , die das Recht haben, andere Benutzer zu ändern (mehr dazu im nächsten Absatz)

4. SNC ist eine Sicherheitslücke

Was ist mit dem Ändern des SNC-Feldes?
Tatsache ist, dass Sie durch Ändern des SNC-Felds eines anderen Benutzers (in SU01) in Ihr eigenes eine Verbindung unter dem Konto eines anderen Benutzers herstellen können, ohne das Kennwort zu ändern. Das System fragt Sie einfach, welchen Benutzer Sie auswählen sollen, Ihren oder einen anderen. Wenn Sie dies jedoch tun, wird morgen niemand etwas bemerken, da das Passwort unverändert geblieben ist.

In jedem Unternehmen gibt es Personen, die sich mit Benutzerverwaltung beschäftigen . In der Regel überwachen diese Personen die Benutzererstellung ( SU01 ) und den Zugriff für sie ( PFCG ) sowie Kennwortaktualisierungen. Es ist logisch, dass sie auch das SNC- Feld ausfüllen können.

Das Problem tritt auf, wenn das Unternehmen die Benutzerverwaltung und nur die Hauptbenutzer trennen muss. Administratoren erstellen Benutzer, und Schlüsselbenutzer ändern bei Bedarf ihre Daten: Benutzerparameter, seine Sprache, seinen Standort usw.

In SAP gibt es keinen separaten Kontrollschritt zum Ändern des SNC-Feldes. Jeder, der das Recht hat, den Benutzer zu ändern (Objekt S_USER_GRP, ACTVT 02 ), kann auch das SNC-Feld ändern (während das Ändern des Kennworts dasselbe Objekt erfordert, jedoch mit ACTVT 05 ).

Es kann verschiedene Lösungen geben:

• Nehmen Sie Schlüsselbenutzern Zugriffsrechte auf SU01 weg und geben Sie als Antwort allen SU2 und SU3, wo der Benutzer seine eigenen Parameter ändern kann
• Nehmen Sie Zugriffsrechte für SU01 weg und geben Sie im Gegenzug eine Z-Transaktion aus, bei der die Registerkarte SNC nicht angezeigt wird
• Verlassen Sie SU01, aber schützen Sie das SNC-Feld mit einer speziellen Steuerung

Aus diesem Grund haben wir die letztere Option ausgewählt, indem wir ein benutzerdefiniertes Berechtigungsobjekt erstellt und das SU01-Programm daran gebunden haben. Wie sich später herausstellte, hat SAP jedoch eine ähnliche Lösung: Sie können die erweiterte Wartung ( Hinweis 1882254 ) für einzelne SU01-Felder aktivieren.

5. Teamarbeit

Während des Projekts stieß ich auf alle Schwierigkeiten der Teamarbeit und entdeckte viele grundlegende Wahrheiten:

• Es ist nie viel Zeit . Die Zeitspanne ist die beste, die der PM bieten kann.
• Es sollte einen grundlegenden Projektplan geben , der jedoch jede Woche überprüft werden muss, sodass ein großer Spielraum für Flexibilität bleibt. Irgendwo bewegten wir uns schneller, irgendwo trampelten wir auf der Stelle.
• Erwachsene Onkel in der IT-Abteilung unterscheiden sich manchmal nicht im Verhalten von den Mädchen in der Buchhaltung : Sie weigern sich, miteinander zu arbeiten, einfach weil sie die Person nicht mögen. Und wieder ist es notwendig, Probleme der Unterordnung zu lösen.
• Oft behindern Abteilungen die Genehmigung des Projekts , da nicht klar ist, wer für die Umsetzung verantwortlich ist und wessen Budget zusätzliche Stunden fallen. Es ist wichtig, dass Manager alles direkt besprechen.
• Hin und wieder treten unvorhergesehene Situationen auf . Das Beste, was sein kann, ist eine rechtzeitige Kommunikation, ein Brief, ein Anruf, eine SMS an alle Beteiligten.
• Es gibt nichts Besseres als ein persönliches Treffen . Fragen werden um ein Vielfaches schneller gelöst als per E-Mail besprochen. Auf der anderen Seite sollte auf alle persönlichen Vereinbarungen sofort ein nachfolgender Brief folgen (um zu reparieren und nicht zu vergessen)
• PM in einem IT-Projekt kann nur Menschen vertrauen . Sie haben keine Ahnung, wie viel Zeit diese oder jene Aktion benötigt: Erstellen eines Benutzers in AD für Kerberos, 10 Minuten oder drei Tage? Und es gibt keine Möglichkeit zu überprüfen, ob die Tests wirklich abgebrochen wurden oder ob jemand herumalbern wollte. Es bleibt nur zu vertrauen.

Darüber hinaus hängt vieles von der Ausdauer des Beraters ab. Jemand allein oder ein Entwicklungsberater oder PM sollte so frech sein wie eine Kugel und durch die Wände einer Bürokratie schlagen. In diesem Fall hatte ich teilweise Glück, unser eingeladener Berater war nervig und manchmal unerträglich (es war schwer, ihn etwas zu hören), aber er kannte sein Geschäft: Er meldete Probleme und stoppte sofort und beruhigte sich nicht, bis das Problem gelöst war.

6. Informationen für Unternehmen

In einem großen Unternehmen müssen Änderungen, die Endbenutzer betreffen, rechtzeitig erfolgen und besser im Voraus angekündigt werden.

In unserem Fall mussten alle Benutzer darüber informiert werden, dass sie jetzt kein Passwort für die Eingabe von SAP benötigen. Außerdem musste eine technische Dokumentation für die 1. Supportlinie mit allen möglichen Fehlern bereitgestellt werden, die nach der Implementierung auftreten können.

Ich muss zugeben, dass mit der Kommunikation alles, was schief gegangen sein könnte.

Erstens haben wir die Benutzer auf der Unternehmenswebsite über SSO informiert und nicht per Brief. Wie oft lesen Sie eine Unternehmenswebsite? SAP .

- , , , , , , , ( - ?) , .

- , Go Live, , ( 2 ), . .

7. fuck-up

5- SSO SAP, , .

: . , — . . 2- , 500 -. .

. “use a default language SAP logon” — , , ( SU01 , Defaults ). « SAP» .

, -, .

- .

8.

SSO — , . , 1-2 , 3- .

. . , , , .

Viele Dinge über SSO sind vielleicht schon lange bekannt, zumindest Google. Zum Beispiel über eine Serveranforderung an AD oder das SNC-Feld. Aber es gibt so etwas wie einen ewigen Zeitmangel. Als Spezialist müssen Sie googeln und als Projektmanager (insbesondere wenn Sie es in der ersten halben Stunde nicht herausfinden können und keine spezielle Ausbildung haben) sollten Sie den kürzesten Weg zu einer Lösung finden.

 ,     ,   . 

Feststoffe:

• Die Hauptzeit in 3 Monaten wurde für die Koordinierung und Koordinierung der Maßnahmen aufgewendet
• Die an diesem Projekt beteiligten Abteilungen begannen, die Arbeit des anderen besser zu verstehen.
• Während des Testens müssen Sie sich an der Stelle des Endbenutzers vorstellen - was Sie in der Informationsnachricht und in den Grundeinstellungen sehen möchten.
• SSO für SAP ist implementiert. Die Benutzer sind glücklich und haben bereits die Zeiten vergessen, in denen das Kennwort von SAP gespeichert werden musste. Rufen Sie seltener den technischen Support an, Prost.