10 λάθη εκσυγχρονισμού ERP που πρέπει να αποφύγετε

Τα λάθη εκσυγχρονισμού ERP που πονούν περισσότερο είναι στρατηγικά, όχι τεχνικά: το go-live ως τέρμα, η αντιγραφή παλιών διαδικασιών στο νέο σύστημα, η πολύ όψιμη έναρξη της δουλειάς στα δεδομένα και στην αλλαγή, το χτίσιμο των πάντων μέσα στο ERP και η υπογραφή αδειών χωρίς πενταετές μοντέλο. Σπάνια φαίνονται σε πραγματικό χρόνο. Βγαίνουν στην επιφάνεια μετά το go-live, όταν οι υποσχεθείσες αποδόσεις δεν εμφανίζονται και οι παρακάμψεις επιστρέφουν.

Απευθύνεται σε CIO, CFO και διευθυντές προγραμμάτων που σχεδιάζουν ή διασώζουν έναν εκσυγχρονισμό S/4HANA ή άλλου ERP. Κάθε λάθος παρακάτω έρχεται με το πώς μοιάζει στην πράξη και τη διόρθωσή του, και ακολουθούν μια λίστα πρώιμης προειδοποίησης μίας σελίδας και τι σημαίνουν οι αλλαγές της SAP το 2026.

Έχω παρακολουθήσει καλά χρηματοδοτημένα έργα με έμπειρες ομάδες και πλήρες επιτελείο συμβούλων να υστερούν παρ' όλα αυτά. Η αιτία σπάνια είναι το σύστημα. Είναι τα κενά στην ιδιοκτησία, στον σχεδιασμό της ενοποίησης και στην επικοινωνία ανάμεσα σε ομάδες που παίρνουν αλληλεξαρτώμενες αποφάσεις.

1. Το go-live ως τέρμα

Μόλις το σύστημα τεθεί σε λειτουργία, πολλές ομάδες υποθέτουν ότι η βαριά δουλειά τελείωσε. Τότε ξεκινά η πραγματική πίεση: η καθημερινή λειτουργία, οι μεταβαλλόμενες απαιτήσεις και η πραγματική συμπεριφορά των χρηστών πιέζουν τον σχεδιασμό.

Έχω δει έργα όπου η συντονιστική επιτροπή διαλύεται αμέσως μετά το go-live. Έξι μήνες αργότερα η υιοθέτηση είναι στάσιμη και κανείς δεν κατέχει το backlog.

Η λύση: χρηματοδοτήστε μια περίοδο διακυβέρνησης 6 έως 12 μηνών μετά το go-live. Επεκτείνετε την εντολή της συντονιστικής επιτροπής. Παρακολουθήστε την υιοθέτηση των διαδικασιών, όχι μόνο τη διαθεσιμότητα. Ορίστε πύλες ποιότητας μετά το go-live με επώνυμους υπεύθυνους.

2. Μεταφορά παλιών διαδικασιών χωρίς επανεξέταση

Έχω δει ολόκληρες αλυσίδες έγκρισης να ξαναχτίζονται ακριβώς όπως ήταν, ακόμη κι όταν οι μισοί από τους εμπλεκόμενους δεν είχαν καμία σχέση με την τρέχουσα διαδικασία. Κανείς δεν είχε ρωτήσει αν τα βήματα χρειάζονταν ακόμη. Το αποτέλεσμα ήταν ένα σύγχρονο ERP που έτρεχε παλιές ροές εργασίας: μια ακριβότερη εκδοχή αυτού που είχαν ήδη.

Η εκδοχή του S/4HANA: προσαρμοσμένες batch εργασίες που μεταφέρθηκαν αυτούσιες από το ECC, χτισμένες πάνω σε δομές πινάκων που δεν υπάρχουν πια. Η μετάβαση είναι τεχνικά καθαρή. Η επιχειρηματική λογική είναι σπασμένη.

Η λύση: ξανασχεδιάστε τις διαδικασίες πριν από το χτίσιμο. Περάστε τις ομάδες λειτουργιών, οικονομικών και παράδοσης από κάθε ροή εργασίας μαζί και αμφισβητήστε κάθε βήμα.

Παλιός τομέας	Τι πάει συχνά στραβά	Τι να κάνετε αντί γι' αυτό
Προσαρμοσμένος κώδικας από το ECC	Αχρησιμοποίητος προσαρμοσμένος κώδικας μεταφέρεται στο S/4HANA	Εκτελέστε ανάλυση χρήσης και τους ελέγχους προσαρμοσμένου κώδικα της SAP και αποσύρετε τον αχρησιμοποίητο κώδικα
Παλιές ροές εργασίας	Ξαναχτίζονται ροές έγκρισης ενώ πλέον είναι δυνατή η αυτοματοποίηση	Ξαναδείτε τες με τους υπευθύνους της επιχείρησης και χρησιμοποιήστε τυπικές εφαρμογές Fiori ή το SAP Build Process Automation
Μη τυπικά κύρια δεδομένα	Οι ευέλικτες παλιές ρυθμίσεις αποτυγχάνουν στους ελέγχους του S/4HANA	Καθαρίστε και εναρμονίστε πριν από τη μετάβαση, με το SAP MDG όπου ταιριάζει
Αναφορές σε παλιούς πίνακες	Η άμεση πρόσβαση σε πίνακες δεν ταιριάζει με το μοντέλο δεδομένων του S/4HANA	Ξαναχτίστε σε CDS views
Κρυφές χειροκίνητες παρακάμψεις	Παράπλευρες διαδικασίες επανεμφανίζονται μετά το go-live	Χρησιμοποιήστε process mining πριν από τη μετάβαση και ψηφιοποιήστε τα κενά

3. Πολύ όψιμη έναρξη της μεταφοράς δεδομένων

Το να μεταφέρετε κακά δεδομένα σε νέο ERP είναι σαν να μετακομίζετε χωρίς να πετάξετε τίποτε. Η ακαταστασία έρχεται μαζί σας και είναι πιο δύσκολο να καθαριστεί όταν βρίσκεται μέσα σε ένα δομημένο σύστημα.

Κάποτε είδα ένα go-live να αποτυγχάνει επειδή κανείς δεν πρόσεξε ότι ένα βασικό σύνολο δεδομένων είχε εγγραφές από πέντε διαφορετικές επιχειρησιακές μονάδες, καθεμία με δική της λογική κωδικοποίησης. Η τεχνική μεταφορά ήταν σωστή. Τα δεδομένα δεν ήταν αξιοποιήσιμα. Οι αναφορές χάλασαν, οι χρήστες έχασαν την εμπιστοσύνη και ο καθαρισμός μέσα σε ζωντανό σύστημα κράτησε μήνες.

Η λύση: κάντε τα δεδομένα ομάδα εργασίας με επιχειρησιακή ευθύνη. Ορίστε υπευθύνους διαδικασιών, όχι μόνο τεχνικούς συμβούλους. Αποφασίστε τι θα φέρετε, τι θα αρχειοθετήσετε και τι θα ξαναχτίσετε πριν ξεκινήσει η μεταφορά. Εκτελέστε τουλάχιστον δύο πλήρεις δοκιμαστικές φορτώσεις (mock loads), με χάρτη εξαρτήσεων για τη σειρά φόρτωσης και καθορισμένη επαναφορά για κάθε φόρτωση. Το κείμενό μου για το γιατί αποτυγχάνει η μεταφορά δεδομένων στο SAP εμβαθύνει.

4. Η διαχείριση αλλαγής ως δευτερεύουσα εργασία

Η συνηθισμένη εκδοχή: η διαχείριση αλλαγής είναι «ήδη καλυμμένη», που σημαίνει λίγες διαφάνειες, ένα demo και μία συνεδρία εκπαίδευσης πριν από το go-live.

Οι άνθρωποι δεν αντιστέκονται επειδή αντιπαθούν την αλλαγή. Αντιστέκονται όταν κανείς δεν εξηγεί γιατί αλλάζουν τα πράγματα ή πώς τους βοηθά. Ακολουθούν το σύστημα όσο χρειάζεται για να περάσουν τη λίστα ελέγχου και μετά γυρίζουν στα λογιστικά φύλλα.

Η συνηθισμένη αφορμή είναι η πίεση του χρονοδιαγράμματος: η εκπαίδευση συμπιέζεται για να ανακτηθεί χρόνος, οι χρήστες πλημμυρίζουν στο go-live και το επιπλέον hypercare κοστίζει περισσότερο από την εκπαίδευση που κόπηκε.

Η λύση: δώστε στη διαχείριση αλλαγής δικό της προϋπολογισμό, χρονοδιάγραμμα και ανώτερο υπεύθυνο από την αρχή. Χαρτογραφήστε νωρίς τους ρόλους, βρείτε τοπικούς πρωταθλητές (champions) και παρακολουθήστε KPI υιοθέτησης δίπλα στα τεχνικά ορόσημα. Ο οδηγός μου για το σχέδιο διαχείρισης αλλαγής περιγράφει τη δομή.

5. Σχεδιασμός γύρω από τους οδικούς χάρτες των προμηθευτών

Έχω δει ομάδες να βασίζουν τη στρατηγική ενοποίησής τους σε μια μελλοντική έκδοση ενός προμηθευτή, για να τη δουν να μετατίθεται κατά 12 μήνες. Στο μεταξύ έμειναν κολλημένες να χτίζουν προσωρινές παρακάμψεις, και οι παρακάμψεις έγιναν μόνιμες.

Οι προμηθευτές χτίζουν οδικούς χάρτες (roadmaps) για ευρείες ομάδες πελατών. Η επιχείρησή σας σπάνια βρίσκεται στο κέντρο αυτού του σχεδιασμού.

Η λύση: αντιμετωπίστε τον οδικό χάρτη ως μία εισροή. Σχεδιάστε γύρω από ό,τι είναι γενικά διαθέσιμο σήμερα, δοκιμάστε τις νέες λειτουργίες σε sandbox πριν βασιστείτε σε αυτές και μετρήστε τα οφέλη του οδικού χάρτη ως πλεονέκτημα, όχι ως προϋπολογισμό.

6. Κανένα σχέδιο απόσυρσης για τα παλιά συστήματα

Κάποτε είδα μια εταιρεία να πληρώνει εξαψήφιο ποσό τον χρόνο για να κρατά σε λειτουργία ένα παλιό σύστημα για έξι χρήστες που χρειάζονταν να βγάλουν αναφορές δύο φορές τον χρόνο. Κανείς δεν είχε φτιάξει σχέδιο απόσυρσης.

Η λύση: βάλτε την απόσυρση (decommissioning) στο καταστατικό του έργου από την πρώτη ημέρα, με τη συμμετοχή νομικών, συμμόρφωσης και διακυβέρνησης δεδομένων, όχι μόνο του IT. Συμφωνήστε περιόδους διατήρησης και προσέγγιση αρχειοθέτησης πριν από το go-live, χαρτογραφήστε και αποσυνδέστε κάθε διεπαφή προς το παλιό σύστημα και αναθέστε σε μία ομάδα τη δουλειά να το κλείσει.

7. Υποτίμηση της πολυπλοκότητας της ενοποίησης

Όταν αποτυγχάνει η ενοποίηση, η επιχείρηση το προσέχει πριν από το IT, επειδή οι ροές εργασίας σταματούν στη μέση της διαδικασίας στην παραγωγή και όχι σε σύστημα δοκιμών.

Το συνηθισμένο μοτίβο: το IT και η επιχείρηση υποθέτουν η μία ότι η άλλη έχει ορίσει τις απαιτήσεις ενοποίησης. Καμία δεν το έχει κάνει. Μέχρι να εμφανιστούν τα κενά στις δοκιμές, δεν υπάρχει χρόνος για επανασχεδιασμό.

Η λύση: ξεκινήστε τον σχεδιασμό της ενοποίησης στη φάση blueprint. Ορίστε κάθε σενάριο, το middleware, την αντιστοίχιση και τους όγκους μηνυμάτων, και ξεκαθαρίστε με την επιχείρηση πραγματικού χρόνου έναντι batch ανά διεπαφή. Ορίστε υπεύθυνο διεπαφής με SLA πριν από το go-live. Για τα νέα προγράμματα SAP το middleware είναι το SAP Integration Suite. Το SAP PI/PO φεύγει από τη βασική συντήρηση στο τέλος του 2027.

8. Η υπόθεση ότι το ERP μπορεί να χειριστεί τα πάντα

Έχω δουλέψει σε έργα όπου οι ομάδες έχωναν σύνθετες ροές υπηρεσιών (αιτήματα IT, αιτήματα παγίων, δρομολόγηση κλιμακώσεων) μέσα στο ERP επειδή δεν ήθελαν να εμπλέξουν εξωτερικά συστήματα όπως το ServiceNow. Το αποτέλεσμα ήταν προσαρμοσμένα πεδία παντού, χειροκίνητες παρακάμψεις και χρήστες κολλημένοι σε μια διαδικασία που ποτέ δεν ταίριαζε.

Το ERP είναι καλό σε δομημένες, συναλλακτικές, οικονομικά αγκυρωμένες διαδικασίες. Οι εξειδικευμένες πλατφόρμες κάνουν καλύτερα τα αιτήματα υπηρεσιών IT, την ενορχήστρωση ροών εργασίας και τη διαχείριση γνώσης.

Η λύση: αποφασίστε σκόπιμα τι δεν θα χτίσετε στο ERP. Χρησιμοποιήστε επεκτάσεις side-by-side στο SAP BTP για τις εξαιρέσεις, και το ServiceNow ή κάτι παρόμοιο για την ενορχήστρωση έξω από τον συναλλακτικό πυρήνα. Το άρθρο μου για τον εκσυγχρονισμό του ERP με SAP και ServiceNow καλύπτει αυτόν τον διαχωρισμό.

9. Υποτίμηση του μακροπρόθεσμου κόστους αδειοδότησης

Ξέρω μια ομάδα που διπλασίασε τη δαπάνη αδειοδότησης τον δεύτερο χρόνο επειδή χρειαζόταν μία λειτουργία πίσω από άδεια ανώτερης βαθμίδας. Η επιχειρηματική περίπτωση είχε μοντελοποιήσει μόνο το κόστος του go-live.

Οι άδειες ERP χρεώνουν χρήστες, ενότητες, συναλλαγές και χρήση APIs, και το κόστος κλιμακώνεται με την επιχείρηση είτε το έχετε προγραμματίσει είτε όχι. Στη SAP, το μοντέλο Digital Access σημαίνει ότι έγγραφα που δημιουργούνται από συστήματα τρίτων μπορεί να φέρουν κόστος άδειας που δεν ήταν στο αρχικό εμπορικό μοντέλο. Στο RISE και στο SAP GROW, οι αριθμοί Full User Equivalent (FUE) αυξάνονται με την υιοθέτηση.

Η λύση: χτίστε ένα μοντέλο αδειών τριών έως πέντε ετών πριν υπογράψετε. Αντιστοιχίστε ρόλους σε τύπους αδειών, μοντελοποιήστε την αύξηση των FUE σε μια ρεαλιστική καμπύλη υιοθέτησης, κατανοήστε την έμμεση πρόσβαση (indirect access) πριν συνδέσετε εξωτερικά συστήματα και ελέγξτε τους ανενεργούς χρήστες μετά το go-live.

10. Το ERP ως έργο IT

Το πιο συνηθισμένο και πιο επιζήμιο μοτίβο. Ο σχεδιασμός ξεκινά στο IT, τον οδηγεί το IT και λύνει προβλήματα του IT.

Έχω δει ομάδες να πετυχαίνουν κάθε ορόσημο στα χαρτιά ενώ η επιχείρηση εξακολουθεί να ρωτά γιατί τίποτε δεν αισθάνεται καλύτερο. Αυτό συνήθως σημαίνει ότι το ERP χτίστηκε για τις χθεσινές διαδικασίες, χωρίς επικεφαλής λειτουργιών, οικονομικών ή εμπορικών στον σχεδιασμό.

Η λύση: βάλτε εμπορικά, οικονομικά και λειτουργικά στελέχη στη συντονιστική επιτροπή από την αρχή. Γράψτε τη στρατηγική ευθυγράμμιση στο καταστατικό, όχι μόνο το τεχνικό εύρος. Δοκιμάστε τους στόχους του προγράμματος απέναντι σε αποτελέσματα επιπέδου διοικητικού συμβουλίου πριν ξεκινήσει ο σχεδιασμός.

Χρησιμοποιήστε την σε κάθε συντονιστική επιτροπή. Αν υπάρχει προειδοποιητικό σημάδι, ο επώνυμος υπεύθυνος αναφέρει γι' αυτό μέχρι να φύγει.

1. ΚαταστατικόΙδιοκτησία και κόστοςΚανένα στέλεχος λειτουργιών ή οικονομικών, κανένα πενταετές μοντέλο αδειών, καμία ημερομηνία απόσυρσης
2. BlueprintΣχεδιασμός διαδικασιών και ενοποίησηςΗ σημερινή διαδικασία αντιγράφεται, οι διεπαφές παραμένουν ασχεδίαστες
3. Πρώτο mock loadΔεδομέναΚαμία αναφορά ποιότητας δεδομένων ακόμη
4. Go-liveΤι ακολουθείΚαμία χρηματοδοτούμενη διακυβέρνηση για τους 12 μήνες μετά

Λάθος	Πρώιμο προειδοποιητικό σημάδι	Υπεύθυνος
1. Το go-live ως τέρμα	Κανένα χρηματοδοτούμενο σχέδιο διακυβέρνησης για τους 12 μήνες μετά το go-live	Χορηγός
2. Αντιγραμμένες παλιές διαδικασίες	Τα workshops σχεδιασμού ξεκινούν από οθόνες «πώς το κάνουμε σήμερα»	Υπεύθυνοι διαδικασιών
3. Όψιμη δουλειά στα δεδομένα	Καμία αναφορά ποιότητας δεδομένων πριν από το πρώτο mock load	Επικεφαλής μεταφοράς δεδομένων
4. Η αλλαγή ως δευτερεύουσα εργασία	Το σχέδιο αλλαγής είναι ένα ημερολόγιο εκπαίδευσης	Επικεφαλής αλλαγής
5. Εξάρτηση από οδικό χάρτη	Μια απόφαση σχεδιασμού περιμένει μια λειτουργία που δεν έχει κυκλοφορήσει	Αρχιτέκτονας λύσης
6. Καμία απόσυρση	Καμία ημερομηνία απόσυρσης για κανένα παλιό σύστημα στο καταστατικό	PMO
7. Υποτιμημένη ενοποίηση	Οι διεπαφές δεν έχουν σχεδιαστεί μέχρι το τέλος του blueprint	Επικεφαλής ενοποίησης
8. ERP για τα πάντα	Προσαρμοσμένα αντικείμενα για μη συναλλακτικές ροές εργασίας	Αρχιτέκτονας επιχείρησης
9. Αδειοδότηση	Κανένα πενταετές μοντέλο αδειών στην επιχειρηματική περίπτωση	CFO
10. Πρόγραμμα μόνο του IT	Η συντονιστική επιτροπή δεν έχει στέλεχος λειτουργιών ή οικονομικών	Χορηγός

Ανάπτυξη. Για τα νέα προγράμματα SAP, η προεπιλογή είναι το RISE with SAP στο SAP Cloud ERP Private ή το SAP GROW στην public edition (SAP Cloud ERP) για μεσαίες εταιρείες. Οι νέες on-premise εγκαταστάσεις είναι σπάνιες. Οι πελάτες ECC αντιμετωπίζουν λήξη της βασικής συντήρησης στις 31 Δεκεμβρίου 2027, κάτι που μικραίνει τον χρόνο που υπάρχει για να διορθωθούν τα λάθη 2, 3 και 7.

Clean core. Η SAP βαθμολογεί πλέον τις επεκτάσεις σε τέσσερα επίπεδα clean core, από το A (μόνο εγκεκριμένα APIs, side by side στο BTP ή μέσα στο σύστημα με ABAP Cloud) έως το D (όχι clean). Η public edition επιτρέπει μόνο το επίπεδο A, κάτι που επιβάλλει τη συζήτηση πίσω από το λάθος 2. Η private edition εξακολουθεί να επιτρέπει κλασικές επεκτάσεις, οπότε η πειθαρχία πρέπει να προέλθει από τη διακυβέρνηση. Ο κλασικός προσαρμοσμένος κώδικας είναι αυτό που κάνει κάθε αναβάθμιση έργο. Το κείμενό μου για τη στρατηγική clean core πηγαίνει πιο βαθιά.

AI στα εργαλεία παράδοσης. Το Joule βρίσκεται πλέον στο SAP Cloud ALM και στο SAP Activate Roadmap Viewer, και το SAP Build Code χρησιμοποιεί το Joule για την ανάπτυξη επεκτάσεων. Ρωτήστε τους συνεργάτες πώς αντικατοπτρίζονται τα εργαλεία AI στον τιμοκατάλογό τους. Αν δεν αντικατοπτρίζονται, είτε η τιμή είναι υψηλή είτε η εξοικονόμηση πηγαίνει στο περιθώριό τους.

Εργαλεία κύκλου ζωής. Το SAP Cloud ALM είναι το εργαλείο διαχείρισης κύκλου ζωής για προγράμματα cloud. Το Solution Manager 7.2 φεύγει από τη βασική συντήρηση στο τέλος του 2027, οπότε τα τοπία που τρέχουν και τα δύο χρειάζονται σχέδιο για τη μετάβαση.

Τα δέκα λάθη δεν άλλαξαν. Άλλαξε το κόστος του να τα κάνετε. Σε ένα πρόγραμμα RISE, η απόφαση για το clean core, το μοντέλο ανάπτυξης και το μοντέλο FUE ορίζονται όλα τις πρώτες εβδομάδες της κινητοποίησης. Το παράθυρο για να τα επηρεάσετε είναι σύντομο.

Γιατί οι προσπάθειες εκσυγχρονισμού ERP υστερούν μετά το go-live;

Οι περισσότερες ομάδες σχεδιάζουν έως το go-live και σταματούν. Κανείς δεν κατέχει τις βελτιώσεις, την ανατροφοδότηση, τις διορθώσεις διαδικασιών ή το backlog. Η διάλυση της συντονιστικής επιτροπής στο go-live είναι το πιο αξιόπιστο σημάδι προβλήματος. Χρηματοδοτήστε 6 έως 12 μήνες διακυβέρνησης μετά το go-live από την πρώτη ημέρα.

Ποιος είναι ο κίνδυνος της αντιγραφής παλιών διαδικασιών σε νέο ERP;

Το νέο σύστημα κληρονομεί τις παλιές αναποτελεσματικότητες με υψηλότερο κόστος. Ειδικά στις μεταβάσεις S/4HANA, ο προσαρμοσμένος κώδικας και οι batch εργασίες που χτίστηκαν για πίνακες του ECC συχνά δεν δουλεύουν, οπότε η μετάβαση μπορεί να είναι τεχνικά καθαρή ενώ η επιχειρηματική λογική είναι σπασμένη.

Πώς βλάπτει η κακή ποιότητα δεδομένων έναν εκσυγχρονισμό ERP;

Διπλοί προμηθευτές, ασυνεπή κύρια δεδομένα, παλιοί κωδικοί και ελλιπείς εγγραφές περνούν όλα στο νέο σύστημα αν δεν τα καθαρίσει κάποιος πρώτα. Οι αναφορές χαλάνε, οι χρήστες παύουν να εμπιστεύονται τους αριθμούς και ο καθαρισμός μέσα σε ζωντανό σύστημα παίρνει μήνες.

Γιατί η διαχείριση αλλαγής υποτιμάται τόσο συχνά στα έργα ERP;

Επειδή δεν φαίνεται σε ένα σχέδιο έργου όπως η παραμετροποίηση. Τα στελέχη υποθέτουν ότι αρκούν λίγες συνεδρίες εκπαίδευσης. Η διαχείριση αλλαγής είναι η προετοιμασία των ανθρώπων για ό,τι θα αλλάξει πραγματικά στην καθημερινή τους δουλειά, πριν από το go-live. Εργαλεία ψηφιακής υιοθέτησης όπως το WalkMe, που πλέον ανήκει στη SAP, βοηθούν με καθοδήγηση μέσα στην εφαρμογή, αλλά δεν αντικαθιστούν την εξήγηση του γιατί.

Γιατί τα παλιά συστήματα συνεχίζουν να τρέχουν χρόνια μετά το go-live του ERP;

Επειδή κανείς δεν σχεδίασε να τα κλείσει. Όλοι εστιάζουν στο να τεθεί σε λειτουργία το νέο ERP, και τα παλιά συστήματα μένουν για συμμόρφωση, για αναφορά ή για ασφάλεια. Η απόσυρση πρέπει να είναι στο εύρος από την πρώτη ημέρα, με τη συμμετοχή νομικών και συμμόρφωσης.

Πώς αλλάζουν το RISE with SAP και το clean core αυτά τα λάθη;

Στην public edition, οι κανόνες clean core καθιστούν αδύνατη τη βαθιά παραμετροποίηση, κάτι που επιβάλλει τη συζήτηση για τις διαδικασίες πίσω από το λάθος 2. Στην private edition, οι κλασικές επεκτάσεις επιτρέπονται ακόμη, οπότε το clean core εξαρτάται από τη διακυβέρνηση. Η ενοποίηση μετακινείται στο SAP Integration Suite καθώς λήγει η συντήρηση του PI/PO. Η αδειοδότηση γίνεται ζήτημα αύξησης FUE. Η απόσυρση γίνεται πιο επείγουσα, επειδή η παράλληλη λειτουργία παλιών συστημάτων προσθέτει κόστος πάνω από μια πολυετή συνδρομή.