Vor einigen Jahren plädierten einige Beratungsunternehmen für „Zurück zum Standard“. Wenn es nicht Standard war, musste es entfernt werden: Add-Ons und benutzerdefinierte Codes mussten verschwinden. Nicht-Standard war böse. Manche Menschen betrachten die „Zurück zum Standard“ auch heute noch als positive Maßnahme, unabhängig vom Inhalt.
Die Wahrheit ist, dass die anfängliche SAP-Implementierung oft zu einer Zeit begann, als das Reengineering von Geschäftsprozessen „à la mode“ war, und ein Mangel an Funktionalität, gemischt mit einer solchen BPR, führte oft dazu, dass benutzerdefinierte Spezifikationen in das SAP-System eingebettet wurden.
Dann verbesserten Unternehmen Geschäftsprozesse nicht immer zum Besten, aber meistens aus guten Gründen.
Ich sehe zwei Gründe dafür, „zurück zum Standard“ zu gehen, und zwei Gründe, „außerhalb des Standards“ zu bleiben.
Grund 1 – Zurück zum Standard
Ich erinnere mich an ein Projekt mit einer erstaunlichen Liste von 2000 spezifischen Anforderungen. Ich bin nur wenige Monate vor dem Livegang als Integrationsexperte eingestiegen. Das ERP dieses Unternehmens hatte zwei Schlüsselprozesse, die den Unterschied ausmachten: Kostengünstiger Transport und Anreize für Vertriebsmitarbeiter.
Bei der kundenspezifischen Entwicklung bezogen sich nur 3 von 2000 Anforderungen auf diese Schlüsselprozesse! Wenn kundenspezifische Entwicklung keinen Mehrwert bringt, ist es natürlich eine Verbesserung, sie loszuwerden.
Grund 2 – Zurück zum Standard
Ein weiterer offensichtlicher Grund für „Zurück zum Standard“ ist, wenn eine neue Standardfunktion entwickelt wurde, die benutzerdefinierte Verwendungen irrelevant macht. Bei der Umstellung auf S/4 sind einige Änderungen abhängig von der Version der S/4 HANA- Vereinfachungsliste obligatorisch. Beispielsweise die Verlagerung von Hausbankdaten aus dem Customizing in die Stammdaten. Sie können die Vorteile eines solchen Prozesses in Frage stellen, aber Sie müssen Ihren Prozess ändern und potenzielle benutzerdefinierte Codes loswerden.
Grund 1 – Außerhalb des Standards bleiben
Wenn es ein „einzigartiges Wertversprechen“ für diese Änderung gibt. Wenn die kundenspezifische Entwicklung eindeutig ein wichtiger Bestandteil Ihres Unternehmens ist, um sich von anderen abzuheben. Was Sie einzigartig macht, ist wahrscheinlich kein Softwarestandard: Es gibt kein SAP-Standardfeature für Airbnb.
Grund 2 – Außerhalb des Standards bleiben
Wenn Sie die geschäftliche Begründung für die kundenspezifische Entwicklung nicht verstehen. Die Verbesserung des Standards erfordert Zeit und Mühe. Es gibt wahrscheinlich einen Grund für diese Investition. Bevor Sie eine Verbesserung entfernen, würde ich vorschlagen, eine Untersuchung darüber durchzuführen, wer dies getan hat und warum.
Das Leben von IT-Systemen ist eine andauernde Bewegung
Aus meiner Sicht ist das Leben von IT-Systemen kein „Zurück zum Standard“-Ansatz. Es beinhaltet eine kontinuierliche Bewegung hin zu Geschäftsrelevanz, Benutzerfreundlichkeit und Kosteneffizienz. Standard ist einfacher zu implementieren und oft die beste Option. Aber ein flächendeckendes „Zurück zum Standard“ ist kein vernünftiger Ansatz. Wenn Sie ein Auto fahren und zum Standard zurückkehren, gehen Sie am Ende zu Fuß!
Wenn Sie eine S/4 HANA -Implementierung durchlaufen, werden Sie versucht sein, sich an das Standardmodell des Unternehmens anzupassen. Aber wann sollten Sie zur Standardeinstellung zurückkehren oder Ihr Altsystem replizieren?
Erfahren Sie in diesem On-Demand-Webinar, wie Sie die S/4-Migrationszeiten und die Gesamtbetriebskosten Ihrer SAP-Systeme bei der Migration zu S/4HANA reduzieren können. Jetzt ansehen! https://info.tjc-group.com/webinar-data-archiving
SAP verfolgt einen pragmatischen Ansatz: Es ist Ihre Entscheidung und Sie haben Optionen. Es ist wahrscheinlich sinnvoll, neue Funktionen zu übernehmen, aber Sie haben das Recht, vorhandene Funktionen beizubehalten.
Bei einem fanatischen „Zurück-zum-Standard“-Ansatz kann der „ Wechsel zu neuen (S/4)-Standards “ einige Fallstricke mit sich bringen – die aus einem Mangel an Verständnis für die aktuellen Prozesse stammen; vor allem wenn man sie entfernt.
Das Entfernen eines bestehenden Prozesses ist am einfachsten: Es ist kein Austausch, kein Design oder keine Reflexion erforderlich. Niemand ist anwesend, um den bestehenden Geschäftsprozess zu befürworten.
Wenn Sie hören, dass „Mit HANA das Volumen stark reduziert wird und die Alterung ein neuer Prozess ist, müssen Sie in Ihrem neuen System keine Archivierung vornehmen.“ – auch hinterfragen. Auch hier müssen Sie zunächst verstehen, was und warum Sie im Rahmen der S/4 HANA-Konvertierung keinen Archivierungsprozess einbeziehen müssen. Fragen Sie einen Fachexperten, um herauszufinden, was die Fallstricke sein könnten und welche Vorteile es haben könnte, wenn Sie zuerst die SAP-Archivierung als Teil Ihres Migrationsplans abonnieren.
Glücklicher Weg zu S/4 .
Weil Ihre Daten wichtig sind.
Thierry JULIEN, CEO und Gründer der TJC Group
