Tipps zur Außerbetriebnahme von SAP (ohne EPI-USE)

Der Wandel liegt in der Luft

Der größte Teil meines Berufslebens hat sich um SAP gedreht, und wir erleben derzeit einen monumentalen Wandel in Bezug auf den Ort, an dem die Menschen ihre SAP-Systeme hosten, wobei alle Branchen mit Ausnahme der Hochsicherheitsbranchen den Schritt in die Cloud machen. In vielen Fällen wird dies als ein Wendepunkt angesehen, an dem Unternehmen die jahrzehntelange Geschichte ihrer SAP-Altsysteme hinter sich lassen und mit S/4HANA in der Cloud neu beginnen wollen.

Vor kurzem habe ich entdeckt, dass dies nicht nur auf die SAP-Welt beschränkt ist, und ich habe eine Theorie. Die späten Neunziger bis Mitte der Nullerjahre waren eine beispiellose Periode der IT-Umstellung, beginnend mit der Jahr-2000-Problematik und dann mit der Einführung des Internets für Verbraucher und der allgemeinen Verwendung von EDI in der Lieferkette. Die Unternehmen waren gezwungen, in großem Umfang in ihre IT-Systeme zu investieren, und haben seitdem bis zum letzten Tropfen aus ihnen herausgepresst.  

Die Auslagerung von rund 20 Jahren Historie in die Cloud ist nicht nur teurer, sondern bringt Sie auch an die Grenzen, was die Unternehmensstruktur angeht, oder führt zu einer massiven ETL-Komponente des Projekts. Das Endergebnis....Legacy-Systeme in allen Formen und Größen gibt es zuhauf.

Warum auf mich hören?

Ich arbeite seit 20 Jahren mit SAP und habe mich in den letzten 15 Jahren intensiv mit SAP-Datenmanagement beschäftigt. In den letzten zwei Jahren habe ich an mehr Stilllegungsprojekten gearbeitet als in den 18 Jahren davor zusammen.

In diesem Blog führe ich Sie durch eine Checkliste, die ich für die Stilllegung von SAP zusammengestellt habe, und gebe Ihnen zu jedem Punkt einige Hintergrundinformationen.

Dies ist ein allgemeiner Leitfaden für einige der Herausforderungen und ein kostenloser Ratschlag (hoffentlich liest mein Chef dies nicht) für alle, die diesen Weg gehen wollen und sich für einen Alleingang entschieden haben oder für die Stilllegung an eine bestehende Technologielösung gebunden sind.  

Halten Sie auch Ausschau nach meinem Folgeblog , in dem ich für jeden Tipp/jede Herausforderung erkläre, wie wir (EPI-USE) die Aufgabe vereinfachen oder sogar ganz vermeiden können.

Genug geschwafelt... kommen wir zu den Tipps

• Das Archivsystem wird nicht wie SAP aussehen
• Nicht alles, was heute in SAP gemacht wird, wird auch im Archivsystem gemacht
• Es wird ein Kompromiss erforderlich sein

Im Rahmen des Projekts werden Sie mit einer Vielzahl von Menschen zu tun haben, von IT-Beratern, die Ihnen bei der Technologie helfen, über interne IT-Teams bis hin zu einer Vielzahl von Geschäftsanwendern, von denen einige vielleicht mehr IT-Kenntnisse haben als andere. Außerdem werden sie größtenteils von den Irrungen und Wirrungen der neuen Systemimplementierung abgelenkt sein. Dies ist besonders wichtig, wenn Sie SAP verlassen wollen. Erwartungsmanagement ist also wichtig.

 
Das neue System kann aus einer Reihe von Gründen nicht wie SAP aussehen, aber es ist auch wichtig, darauf hinzuweisen, dass Sie das vielleicht nicht wollen. Ja, die Benutzer haben derzeit das Stockholm-Syndrom für die SAP-GUI, aber auf dem neuen System werden sie keine SAP-GUI verwenden. Selbst wenn das neue System S/4HANA ist, werden sie stattdessen Fiori verwenden.

Es ist auch wichtig, immer wieder darauf hinzuweisen, dass Tests und Validierungen nicht mit dem Gedanken durchgeführt werden sollten, dass Sie A als gleichwertig mit B abzeichnen. Dies ist nicht das System, das SAP ersetzt; es ist nur das System, das Sie davor bewahrt, für immer ein "reines" SAP-System betreiben zu müssen. Die Nutzung wird fast vom ersten Tag an nachlassen und kann tage- oder sogar wochenlang völlig ungenutzt bleiben, aber es wird einen gewissen Compliance-Zweck erfüllen. Das Vorhandensein der Daten ist weitaus wichtiger als ihre Darstellung. Die Gewissheit, dass die Daten vorhanden sind, ist wichtiger als die Frage, wie schwer sie zu durchsuchen und abzurufen sind oder wie lang die Antwortzeiten eines Archivsystems sein mögen. Übertreiben Sie es nicht mit der Brillanz oder der Benutzerfreundlichkeit Ihrer Lösung, auch wenn Sie anfangs das Gefühl haben, dass sie beide Qualitäten hat. Sie und Ihre Benutzer werden im Laufe der Zeit zweifellos zu Kompromissen gezwungen sein.

• Sie brauchen keine "Point-in-Time-Backup"-Optionen und keine hohe Verfügbarkeit

Derjenige, der das System für die Stilllegung bereitstellt, ist sich möglicherweise nicht über den Verwendungszweck im Klaren und greift auf die Standardoptionen für Backup und Disaster Recovery (DR) zurück. Diese werden in der Regel in einem Spektrum von Optionen angeboten, die sich an der Gefahr bzw. den Kosten orientieren, wenn etwas Schreckliches passiert. Je weniger Unterbrechungen Sie für Ihr Unternehmen wünschen, desto mehr werden Sie bezahlen. Bei der "Point-in-Time-Backup" Methode kann ein Backup wiederhergestellt werden, wobei die Datenbankprotokolle erneut auf die Datenbank angewendet werden, um sie genau auf den Zeitpunkt vor dem Einschlag der Bombe/Hardwareausfall/Benutzer, der fälschlicherweise einen 5 Jahre alten Batch-Job erneut ausführt/Maus, die das Kabel durchkaut, zu bringen (ggf. löschen).

Das Schöne an stillgelegten Daten ist, dass sie sich nicht ändern. Machen Sie sich klar, was sich im Hinblick auf die Präferenzen der Benutzer ändern könnte, und arbeiten Sie dann entsprechend an der erforderlichen Sicherungsstrategie. Es ist sehr wahrscheinlich, dass ein Backup des stillgelegten Systems nach einem Jahr Nutzung in einer Woche identisch mit dem Backup der nächsten Woche sein wird. Auch die erforderliche SLA-Zeit, um wieder online zu sein, liegt wahrscheinlich nicht im normalen Bereich für ein IT-System. Wir können wahrscheinlich mit einem Ausfall von einer Stunde leben.

TLDR: Dieser Anwendungsfall liegt außerhalb des Spektrums am unteren Ende; lassen Sie sich nicht von jemandem für eine bessere Sicherung und DR bezahlen, als Sie benötigen.

• Konzentration auf die Anwendungsfälle und nicht auf die Daten im System
• In den Gesprächen sollten Sie darauf hinweisen, dass nicht alle derzeitigen SAP-Aktivitäten bei der Stilllegung des Systems erforderlich sein werden.  
  

Level 1 (Leicht) - Finde 2x2 Legosteine in einer Kiste mit Tausenden von Legosteinen
Stufe 2 (Mittel) - Die Suche nach der Nadel im Heuhaufen
↓
Stufe 9 (sehr schwierig) - Identifizierung aller benötigten Daten aus einem SAP-System

In einem modernen SAP-System gibt es mehr als 70k kundenspezifische Tabellen. Viele davon enthalten zwar Standarddaten, aber für eine Branche oder einen Geschäftsprozess, der nichts mit der Tätigkeit Ihres Unternehmens zu tun hat.

Ich würde schätzen, dass es etwa 3-5 Tausend Tabellen mit Daten gibt, die Sie tatsächlich benötigen. Beginnen Sie mit den Anwendungsfällen und suchen Sie die Daten, die Sie zur Unterstützung benötigen. ST05-Traces sind sehr nützlich, um zu sehen, wohin eine bestimmte Transaktion führt, aber Sie können auch die technische Hilfe von F1 verwenden; achten Sie nur auf Strukturen (Daten, die wahrscheinlich aus mehreren Tabellen kombiniert wurden) im Gegensatz zu transparenten Tabellen. Nutzen Sie die Workshops, um die Anwendungsfälle zu identifizieren und sie zur Freigabe zu dokumentieren. Bitten Sie die Teilnehmer, sich zu überlegen, was in einem Monat, in einem Jahr und in drei Jahren nach der Abschaltung von SAP noch gefragt werden wird. Hinterfragen Sie, ob es sich bei einem Anwendungsfall um etwas handelt, das sie heute tun, oder um etwas, das sie auch dann noch brauchen, wenn das SAP-System nicht mehr das produktive System der Aufzeichnungen ist.

• Werden sie auch außer Dienst gestellt werden?
• Gibt es Datendopplungen? Aus welchem System sollen die Daten übernommen werden?

Für die meisten Unternehmen, die SAP einsetzen, ist es das Hauptsystem für die Finanzen und das Zentrum ihres IT-Universums. Viele Dinge haben eine Schnittstelle zu diesem System und fungieren als Dolmetscher zwischen SAP und der Außenwelt. Möglicherweise verfügen Sie über andere SAP-Technologien, die mit ERP integriert sind, wie CRM und SRM. Stellen Sie sicher, dass Sie eine Liste der peripheren Systeme für die Workshops bereithalten. Das Projekt, das SAP ersetzt, sollte bereits über diese Liste verfügen und wissen, welche Systeme gleichzeitig abgeschaltet werden. Vergewissern Sie sich, dass alle Systeme, die in den "Soll"-Entwurf aufgenommen wurden, noch über historische Daten aus der Zeit verfügen, als sie mit SAP verknüpft waren, und streichen Sie diese dann von Ihrer Liste. Nutzen Sie die Workshops für die verbleibenden Systeme, um zu prüfen, ob die Daten in den peripheren Systemen tatsächlich benötigt werden. Werden die Schlüsseldaten in SAP ERP repliziert, oder handelt es sich um die endgültigen Versionen der Daten? Ein Beispiel: SRM sendet Bestellungen an ERP, wobei die nicht verarbeiteten Bestellungen keine Daten sind, die in Zukunft benötigt werden. Wenn benötigte Daten in zwei Systemen vorhanden sind, sollten Sie die Komplexität des Abrufs für jedes System prüfen und sich für das Einfachere entscheiden.  

• Die Dokumente werden möglicherweise nicht in der Datenbank gespeichert oder in einem separaten Repository abgelegt.
• Können mit der neuen Technologie auch nicht persistente Dokumente erstellt werden?
• Diejenigen in einem separaten Repository: Stammen sie aus einem anderen System, und wird dieses System außer Betrieb genommen?

Es ist wichtig, den Menschen zu erklären und sie immer wieder daran zu erinnern, dass es bei der Stilllegung um strukturierte und unstrukturierte Daten gehen wird:

• strukturiert, wobei die Tabelleneinträge heruntergeladen und in einer anderen Datenbank gespeichert werden;
• unstrukturiert sind die PDFs, Word-Dokumente usw., die entweder für einen Partner vervielfältigt oder aus Gründen der Einhaltung von Vorschriften aufbewahrt werden müssen, oder die es den Geschäftsanwendern ermöglichen, eine Frage endgültig zu beantworten. Beispiele hierfür sind Gehaltsabrechnungen, Rechnungs-PDFs und spezielle Finanzberichte, die für Wirtschaftsprüfer benötigt werden.

Erinnern Sie die Benutzer immer wieder daran, dass das Stilllegungssystem nicht über die Logik von SAP verfügen wird. Alles, was Tabellendatensätze mit Logik kombiniert, um eine genau definierte Ausgabe zu erzeugen, muss also möglicherweise für alle Kombinationen ausgeführt werden, bevor das System abgeschaltet wird. Dazu können auch system-/unternehmensspezifische Z/Y-Berichte gehören.

Wenn die unstrukturierten Daten in SAP persistiert werden, können sie in SAP Office oder in einem Content Server gespeichert werden. Bevor man dies für die unstrukturierten Daten im Umfang untersucht, würde ich empfehlen, zunächst die Frage zu stellen: Woher kommt oder wohin geht das Dokument? Mit anderen Worten: Gibt es eine Middleware, die das Dokument durchlaufen hat und von der ebenfalls eine Kopie existieren könnte? Was ist die Zukunft dieses Systems? Wie zugänglich ist es für Endbenutzer? Ist es einfacher, die Dokumente aus diesem System zu extrahieren als aus SAP?

Wenn Sie die Dokumente aus SAP abrufen müssen, geschieht dies programmatisch oder durch Bildschirmautomatisierung wie Robotic Process Automation (RPA). Wenn die Dokumente in einem Content-Server gespeichert sind, ist es dann einfacher, sie direkt von dort oder von SAP zu übernehmen?

• Strukturierte Daten enthalten viele Kennungen: 01 = Frau, 02 = Mann, usw. Werden diese benötigt?
• Materialien, Bestellungen, Kundenaufträge und viele andere erlauben dem Benutzer, Texte einzugeben. Diese werden in Clustertabellen gespeichert und können nicht direkt in der Tabelle gelesen werden.

Strukturierte Daten wurden in SAP in einer Art und Weise gespeichert, die für die Verwendung im System am effizientesten war, und nicht in dem Format, das am besten geeignet ist, um sie aus dem System herauszulösen und nutzbar zu machen. Ein wichtiges Beispiel hierfür sind die Beschreibungen, die Teil der Konfiguration sind. Das relationale Datenbankmanagementsystem erzwingt, dass ein Feld in Tabelle A nur einer der möglichen Einträge in Tabelle B sein kann, und die Beschreibung der Bedeutung der Werte kann nur einmal in Tabelle B gespeichert werden, nicht mehrfach in Tabelle A.

Beispiele hierfür sind Titel wie Frau, Fräulein und Herr oder Auftragsarten. In einigen Fällen weiß der Benutzer vielleicht instinktiv, was der technische Code bedeutet, aber wird er sich in drei Jahren daran erinnern, wenn er die alten SAP-Daten schon lange nicht mehr angesehen hat? Wahrscheinlich nicht.

In den Workshops wird es daher wichtig sein, zu bestimmen, welche zugehörigen Konfigurationstabellen gespeichert werden müssen, damit die Beschreibungen angezeigt werden können. Sie müssen dann sehen, ob das gewählte Archivsystem diese auf einfache Weise speichern kann. Überlegen Sie auch, ob Sie wirklich alle von SAP unterstützten Sprachversionen benötigen oder nur bestimmte Sprachen.

Text scheint etwas so Einfaches zu sein, wenn man ihn mit Notepad betrachtet. Hinter einfachen Zeichenketten verbirgt sich jedoch eine komplexe Welt. Nicht zuletzt die Art und Weise, in der Text ein gutes Ziel für die Komprimierung zur Verringerung des Volumens sein kann, so dass er nicht immer direkt abrufbar ist. In SAP gibt es zwei Tabellen, STXH und STXL, die mit einer Vielzahl von Datentypen verknüpft sind. Mit der Transaktion TAANA können Sie sehen, wie viele Datensätze es für jede Textart gibt. Auf den meisten Systemen sind es Millionen. Der eigentliche Text wird in einem in STXL gespeicherten Cluster komprimiert, so dass Sie SAP-Funktionsbausteine verwenden müssen, um darauf zuzugreifen.

In den Workshops würde ich empfehlen, herauszufinden, welche Tabellen verwendet werden, und diese Liste auf die benötigten (nicht gewünschten, benötigten) Tabellen zu reduzieren. Der Grund dafür ist, dass SAP nicht fest im Griff hatte, wie die Entwickler mit diesen Tabellen verbunden sind. Normalerweise gibt es eine direkte Verknüpfung mit einem Schlüssel wie der Lieferantennummer oder der Bestellnummer, aber es gibt auch einige merkwürdige Fälle, wie z. B. einen der Texte zum Fertigungsauftrag, der einen Schlüssel verwendet, der den Fertigungsauftrag enthält, dem aber die Nummer des verwendeten Mandanten vorangestellt ist. Dies ist überflüssig, da die Produktionsaufträge und die Texttabellen mandantenspezifisch sind. Ich gehe davon aus, dass dies entweder das erste und letzte Projekt dieses Entwicklers mit SAP war, oder es war ihm später so peinlich, dass er es erst zugegeben hat, als es schon zu spät war. Was ich damit sagen will... Ich würde nicht empfehlen, alle STXH\L-Zeilen zu entclustern, weil Sie möglicherweise nicht einmal in der Lage sind, sie alle mit den Geschäftsdaten zu verknüpfen, auf die sie sich beziehen.

• Benötigt jemand nur die Daten oder auch die Änderungshistorie der Daten?

Da SAP das wichtigste Aufzeichnungssystem für viele Dinge ist, werden Änderungen immer dann aufgezeichnet, wenn sie eintreten. In den allermeisten Bereichen werden diese in einem stillgelegten System nicht benötigt. In bestimmten Branchen könnten Änderungen an Rezepten, Materialien oder Chargen erforderlich sein. Genau wie bei den Texten würde ich nicht empfehlen, alle Bereiche zu übernehmen. Finden Sie heraus, welche Bereiche benötigt werden, und prüfen Sie dann erneut, ob eine programmatische Lösung oder eine Bildschirmautomatisierungslösung am besten geeignet ist. Für die meisten Bereiche liegen die Änderungen in... einem anderen Cluster (Tabellen CDHDR und CDPOS), aber für HR sollten Sie im PCL4-Cluster suchen.

• Nehmen Sie in den Plan auf, was zu tun ist, wenn etwas übersehen wird. Dies kann dazu beitragen, zu bestimmen, wie viel/wenig ein Gebiet zu nehmen hat.
• Machen Sie das schon FRÜH im Projekt, das hilft allem!

Dokumentation ist bei jedem Projekt wichtig, aber bei diesem Projekt wird die Aufmerksamkeit der beteiligten Teams begrenzt sein, und es besteht die Bereitschaft, sich schnell zu einigen, um zu dringlicheren Angelegenheiten zurückzukehren.

 
Erstellen Sie einen Plan, was und wie stillgelegt werden soll. Bitten Sie jeden Bereich des Unternehmens, seinen Teil abzusegnen.

• Der Umfang der Tests sollte in einem angemessenen Verhältnis zu den Kosten für die vorübergehende Wiederinbetriebnahme des Systems stehen.

Wie ich bereits erwähnt habe, ist dieses Projekt wahrscheinlich nicht das dringlichste auf der Aufgabenliste von irgendjemandem (außer vielleicht Ihnen, wenn Sie der Projektleiter sind). Denken Sie daran, wenn Sie die Geschäftsanwender um Tests/Validierung bitten. Warten Sie, bis mehrere Anwendungsfälle für die Validierung bereit sind, und bitten Sie dann um deren Zeit, anstatt viele Anfragen für kleine Zeitfenster zu stellen.

Meines Erachtens gibt es einige Schlüsselfragen, die man sich stellen muss, wenn man überlegt, wie viele Tests notwendig sind:

• Allgemeine Frage: Wie schwierig wird es sein, den Zugang zum System wiederherzustellen, wenn etwas übersehen wurde?
• Anwendungsfall für Anwendungsfall: Was sind die Auswirkungen, wenn Daten fehlen? Und für wen?

Wenn wir Daten im Rahmen einer Veräußerung außer Betrieb genommen haben, stand der Zugang zu den Systemen auf Messers Schneide. In dieser Situation ist die Prüfung/Validierung von entscheidender Bedeutung, und die Freigabe könnte rechtsverbindlich sein. Wenn die Daten noch abrufbar sind, dies aber mit Kosten/Aufwand verbunden ist, dann sollten die Tests in einem angemessenen Verhältnis zu den Kosten stehen.

Auf dieses Ergebnis wird ein Koeffizient für den Geschäftsbereich und den spezifischen Datentyp angewandt. In den meisten Ländern müssen die Buchhaltungsunterlagen mindestens sieben Jahre lang aufbewahrt werden, und die Nichteinhaltung dieser Vorschrift kann im Extremfall zu einer Gefängnisstrafe für die Geschäftsführer des Unternehmens führen. Hoffentlich ein unwahrscheinliches Ergebnis im Falle eines versehentlichen Versäumnisses aufgrund von Unzulänglichkeiten im Projektumfang.

• Vermarkten Sie Ihre Lösung intern für andere Systemstilllegungen.
• Unabhängig davon, was Sie verwenden, ist der Kosten-ROI umso besser, je mehr Systeme Sie einbauen können.
• Planen Sie den Beitritt anderer Systeme zu einem späteren Zeitpunkt unter Berücksichtigung von Berechtigungen, erwartetem Speicherplatz/Rechenleistung usw.

Vielleicht gibt es Unternehmensbereiche, die von der SAP-Entwicklung nicht betroffen sind. Haben sie traditionelle Systeme vor Ort oder in der Cloud gehostete Systeme? Nehmen Sie sich zehn Minuten Zeit, um deren IT-Experten und Geschäftsprozessverantwortliche über Ihr Projekt zu informieren.

Wohin auch immer Sie Ihre SAP-Daten verlagern, Sie werden in Zukunft weitaus kosteneffizienter sein, wenn Sie Freunde haben, die das Stilllegungssystem gemeinsam nutzen. Fragen Sie Ihren Technologieanbieter, welche Einschränkungen auftreten könnten, wenn Sie später andere Systeme stilllegen wollen. Gibt es irgendwelche Lizenzbeschränkungen? Ist es besser, mehr Rechenleistung und Speicherplatz einzuplanen, als Sie nur für die SAP-Daten benötigen? Gibt es etwas, das Sie bei den Berechtigungen für die SAP-Daten berücksichtigen sollten, um sie für andere Benutzer, die später dem System beitreten, zukunftssicher zu machen?

• Entfernen Sie den Zugang zu SAP und verfolgen Sie alle Anfragen für einen erneuten Zugang.

Planen Sie nach Möglichkeit ein, dass Ihr SAP-System während der Stabilisierungs-/Hyper-Care-Phase des neuen Systems und vielleicht noch ein wenig darüber hinaus zur Verfügung steht. Die Benutzer haben genug zu tun. Wenn sie also etwas in den SAP-Daten überprüfen müssen, lassen Sie sie das in SAP tun. Sperren Sie dann ihren SAP-Zugang und bitten Sie sie, das neue Stilllegungssystem zu benutzen.

VORSICHT: Lassen Sie die Benutzer nicht daran hängen (lesen Sie diesen Blog über die versteckten Kosten von reinen Anzeigesystemen). Dies geht Hand in Hand mit Tipp 12. Die Dauer der Phasen hängt davon ab, wie machbar/kostspielig es ist, SAP aus einem Backup wiederherzustellen.

• Prüfen Sie Ihre SAP-Lizenzen - können Sie das System auch nach Beendigung der Wartung nur anzeigen lassen?  

Je nach Ihrem Vertrag mit SAP können Sie Ihr altes System so lange als reines Anzeigesystem behalten, wie Sie möchten. Selbst wenn Sie einen aktualisierten Vertrag unterzeichnet haben (vielleicht bei der Erneuerung der SAP-Wartung nach einer Unterbrechung), kann ein technischer Benutzer immer auf ein altes SAP-System zugreifen, auch wenn die Geschäftsbenutzer dies nicht können.

Dokumentieren Sie Ihren Plan, wie jemand Daten aus SAP erhalten kann, die im Projekt übersehen wurden. Stellen Sie sicher, dass der Plan einen schnellen Zugang zu den Daten und die richtige Benachrichtigung sowie die Verfügbarkeit von Fähigkeiten beinhaltet, damit Sie das Projekt für eine kleine (hoffentlich nur eine) Zugabe wieder aufleben lassen können, um diesen zusätzlichen Datensatz herauszuholen und ins Archiv zu stellen.

Irgendwann kommt der Punkt, an dem Sie eine Sicherungskopie erstellen und das System komplett abschalten möchten. Wann genau das geschehen soll, hängt davon ab, was es kosten würde, das System wieder in Gang zu bringen. All dies sollte in diesem Plan enthalten sein.

• Einbeziehung von Workshops mit internen UND externen Prüfern

Dieser Tipp tanzt etwas aus der Reihe, da die letzten Tipps chronologisch mit dem Ende Ihres Projekts geordnet wurden. (Es sei denn, es gibt eine Stelle in einem Zombie-Film, an der sie ganz am Ende unerwartet zurückkehren. Sie wissen schon, was ich meine). 24 Fiskalperioden später" könnten wir einen Film nennen. Jedes Jahr wird es irgendeine Art von Prüfung geben, und diese wird wahrscheinlich auch Ihre stillgelegten Daten umfassen. Es gibt keine Garantie dafür, dass die Person oder sogar das Unternehmen, das die Prüfung in einem Jahr durchführt, auch die Prüfung im nächsten Jahr durchführt, so dass dieser Bereich Aufmerksamkeit erfordert.

Berufen Sie einen Workshop mit internen und externen Prüfern ein und erläutern Sie den Zweck des Projekts und fragen Sie sie, was sie in den nächsten x Jahren brauchen werden. Nehmen Sie dies in das Konzept auf und lassen Sie es von ihnen abzeichnen. Es ist zu hoffen, dass die Person, die die Unterschrift leistet, zumindest für die Organisation arbeitet, die für das erste Mal, dass diese Prüfung durchgeführt wird, verantwortlich ist. Mit jemandem, der im Jahr 2 andere Berichte wünscht, lässt sich leichter verhandeln, wenn das vorherige Audit reibungslos verlaufen ist. Erklären Sie klar und deutlich, dass es sich um strukturierte und unstrukturierte Daten handelt und dass wir zwar die Tabelleneinträge, nicht aber die ABAP-Logik haben werden. Finden Sie heraus, welche Berichte ausgeführt werden sollen, und stellen Sie sicher, dass diese in Ihrem RPA- oder programmatischen Ansatz für unstrukturierte Daten enthalten sind.

Das war nur ein Scherz (sozusagen, aber es ist eine nützliche Information). Hüten Sie sich vor falschen Anforderungen wie "Berichterstattung". Die Frage "Gibt es APIs, um die Daten von einem externen Analysewerkzeug zu lesen?" wird häufig gestellt, ist aber nur selten eine tatsächliche Anforderung, für die jemand bereit ist zu zahlen. Mit jedem Tag, an dem das System existiert, werden die Daten für die Berichterstattung immer weniger nützlich. Das soll nicht heißen, dass dies keine feste Anforderung in Ihrem Projekt sein wird, aber es ist ein guter Punkt, an den man sich erinnern sollte; andere Leute können mit vermeintlichen Anforderungen kommen, die in einer idealen Welt gut wären, aber das erste sein werden, was gekürzt wird, wenn die Projektkosten überprüft werden müssen. Sparen Sie allen Beteiligten etwas Zeit und hinterfragen Sie einfach, ob eine Anforderung für historische, statische Daten sinnvoll ist.

Wenn Sie dies interessant fanden, lesen Sie doch meinen Folgeblog, in dem ich erkläre, wie wir Ihnen helfen können, diesen Prozess zu vereinfachen.