Διάσωση έργου SAP: πώς σώζετε ένα πρόγραμμα που έχει ξεφύγει

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

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

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

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

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

Μερικά μοτίβα που θα αντιμετώπιζα ως σήματα διάσωσης:

1. Η κατάσταση είναι πράσινη, το σύστημα όχι. Οι αναφορές λένε ότι το μεγαλύτερο μέρος της ανάπτυξης έχει ολοκληρωθεί, αλλά το δοκιμαστικό σύστημα δεν μπορεί να τρέξει ένα βασικό order to cash.
2. Ο σχεδιασμός έχει υπογραφεί, η ανάπτυξη τον αγνοεί. Η διαμόρφωση έγινε από σημειώσεις workshops, όχι από τον εγκεκριμένο σχεδιασμό.
3. Το σχέδιο έχει ημερομηνία go-live, κανείς δεν μπορεί να εξηγήσει πώς θα φτάσει εκεί. Οι δοκιμές, οι φορτώσεις δεδομένων και οι πρόβες cutover δεν έχουν ρεαλιστική θέση.
4. Το εύρος μόνο μεγαλώνει. Η λίστα WRICEF (reports, interfaces, conversions, enhancements, forms και workflows) εξακολουθεί να ανεβαίνει πολύ μετά τη φάση Explore.

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

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

Αυτό καλύπτει κάθε έλεγχος και αυτό σας λέει μια διαφωνία:

Έλεγχος	Τι εξετάζω	Το ερώτημα που απαντά	Αν διαφωνεί με τους άλλους
Κατάσταση προγράμματος	Σχέδιο, αναφορές κατάστασης, RAID log, ανοιχτά αιτήματα αλλαγής, δαπάνες σε σχέση με τον προϋπολογισμό	Τι πιστεύει το πρόγραμμα για τον εαυτό του;	Η αναφορά είναι αισιόδοξη ή αποσυνδεδεμένη από την υλοποίηση
Σχεδιασμός	Σχεδιασμός επιχειρησιακών διαδικασιών, αποτελέσματα fit-to-standard, λίστα WRICEF, ανοιχτές αποφάσεις σχεδιασμού	Τι υποσχέθηκαν στην επιχείρηση;	Η ανάπτυξη έχει απομακρυνθεί από όσα συμφωνήθηκαν, ή ο σχεδιασμός δεν ολοκληρώθηκε ποτέ
Τι έχει εγκατασταθεί	Τα συστήματα ανάπτυξης και δοκιμών, διαμόρφωση, transports, προσαρμοσμένος κώδικας, φορτώσεις δεδομένων μέχρι τώρα	Τι υπάρχει πραγματικά σήμερα;	Έχει αναφερθεί πρόοδος σε δουλειά που δεν υπάρχει στο σύστημα

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

Οι αναφορές κατάστασης και τα έγγραφα σχεδιασμού είναι ισχυρισμοί. Το σύστημα είναι απόδειξη.

Ποιος πρέπει να κάνει τους ελέγχους

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

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

Το 2018 δούλεψα στη διάσωση ενός προγράμματος αεροπορίας. Τα modules είχαν εγκατασταθεί, αλλά τίποτα δεν είχε διαμορφωθεί με βάση τις επιχειρησιακές απαιτήσεις.

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

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

Στα 21 προγράμματα SAP που έχω οδηγήσει ή διασώσει, το μεγαλύτερο λάθος που βλέπω είναι ο ελλιπής σχεδιασμός στην αρχή της υλοποίησης. Μια διάσωση είναι συχνά αυτός ο σχεδιασμός που έλειπε, γινωμένος αργά και υπό πίεση.

Δύο άλλες αιτίες εμφανίζονται ξανά και ξανά:

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

Η πλευρά του προϋπολογισμού, μαζί με το γιατί η φάση Explore είναι εκεί όπου τα κόστη πηδούν, καλύπτεται στο άρθρο μου για το γιατί τα έργα SAP ξεπερνούν τον προϋπολογισμό. Δεν θα το επαναλάβω εδώ.

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

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

Η ακολουθία διάσωσης ενός προγράμματος SAP

1. 01

   Διάγνωση

   Κατάσταση, σχεδιασμός και ό,τι έχει εγκατασταθεί, ελεγμένα το ένα με το άλλο.

2. 02

   Ανάκτηση του εύρους

   Εύρος που ανήκει στον πελάτη, παγωμένο, με κάθε αλλαγή κοστολογημένη.

3. 03

   Νέο baseline

   Ένα νέο σχέδιο χτισμένο σε στοιχεία, με απόθεμα από τη δική σας πλευρά.

4. 04

   Πύλες στις φάσεις

   Μια πύλη ποιότητας στο τέλος κάθε φάσης που απομένει.

5. 05

   Πρόβες και cutover

   Πλήρεις πρόβες πριν επιβεβαιωθεί ημερομηνία go-live.

1. Πάρτε πίσω την ιδιοκτησία του εύρους

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

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

2. Κάντε νέο baseline μία φορά, με βάση στοιχεία

Μια διάσωση παίρνει ένα νέο baseline, όχι μια σειρά μικρών μετατοπίσεων. Χτίστε το από ό,τι δείχνει το σύστημα, όχι από ό,τι έλπιζε το παλιό σχέδιο.

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

Κρατήστε απόθεμα 10 έως 20% από τη δική σας πλευρά, που αποδεσμεύεται μόνο για συγκεκριμένους κινδύνους. Το συγγενικό άρθρο μου για το κόστος μετάβασης σε S/4HANA εξηγεί τι καθορίζει τους αριθμούς.

3. Βάλτε μια πύλη ποιότητας στο τέλος κάθε φάσης

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

Στο SAP Activate, η φάση Explore περιλαμβάνει workshops fit-to-standard, και οι εγκεκριμένες απαιτήσεις διαφορών μπαίνουν στο product backlog για τη Realize. Αν το πρόγραμμα βγήκε από την Explore χωρίς ολοκληρωμένο σχεδιασμό, γυρίστε πίσω και ολοκληρώστε τον. Το SAP Cloud ALM υποστηρίζει πύλες ποιότητας ως σημεία ελέγχου με λίστες ελέγχου, που εμφανίζονται στην επισκόπηση του έργου, οπότε η πύλη δεν χρειάζεται να ζει σε ένα υπολογιστικό φύλλο.

4. Κάντε πρόβες πριν δεσμευτείτε σε ημερομηνία

Σε μια μετατροπή brownfield προγραμματίζω τρεις δοκιμαστικές μετατροπές πριν από το cutover. Τα προγράμματα με προβλήματα συχνά κόβουν πρόβες για να κερδίσουν χρόνο, κάτι που μεταφέρει τον κίνδυνο στο Σαββατοκύριακο του go-live.

Το downtime του cutover που έχω δει κυμαίνεται από ένα Σαββατοκύριακο έως μία εβδομάδα. Ένα πρόγραμμα που διασώζεται πρέπει να γνωρίζει τον αριθμό του από μια πρόβα, όχι από μια εκτίμηση.

5. Ελέγξτε την προθεσμία με την οποία πραγματικά δουλεύετε

Για το SAP ERP 6.0 στα enhancement packages 6 έως 8, η κύρια συντήρηση λήγει στις 31 Δεκεμβρίου 2027, με προαιρετική εκτεταμένη συντήρηση έως το τέλος του 2030 με επιβάρυνση δύο ποσοστιαίων μονάδων (SAP News). Μια διάσωση που σπρώχνει μια μετάβαση από ECC πέρα από το 2027 πρέπει να προβλέψει ανοιχτά στον προϋπολογισμό την εκτεταμένη συντήρηση.

Μην αφήσετε την ημερομηνία του 2027 να επιβάλει ένα go-live που δεν στηρίζουν οι πρόβες. Ένα καθυστερημένο go-live κοστίζει τέλη συντήρησης. Ένα αποτυχημένο κοστίζει πολύ περισσότερα.

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

Αυτές είναι οι ερωτήσεις που θα έκανα πριν αποφασίσω:

1. Μπορείτε να μας δείξετε το εγκατεστημένο σύστημα, ζωντανά, σε σχέση με τον υπογεγραμμένο σχεδιασμό; Όχι ένα περιβάλλον επίδειξης και όχι διαφάνειες.
2. Ποια αντικείμενα WRICEF έχουν αναπτυχθεί, δοκιμαστεί και μεταφερθεί με transport, και ποια απλώς αναφέρονται ως ολοκληρωμένα;
3. Ποιος είναι ο high-level σχεδιασμός σας για την ολοκλήρωση, και σε ποιες αναφορές μπορούμε να τηλεφωνήσουμε όπου διασώσατε ένα πρόγραμμα σαν το δικό μας; Οι αναφορές και ο high-level σχεδιασμός είναι τα δύο πράγματα που ζητώ από κάθε συνεργάτη πριν υπογράψω.
4. Τι χρειάζεστε από εμάς που δεν παίρνετε; Οι αποφάσεις που λείπουν και οι key users μερικής απασχόλησης είναι συχνά η μισή ιστορία.
5. Για πελάτες RISE with SAP: ποια ζητήματα ανήκουν στη SAP και όχι στον συνεργάτη, και ποιος τα κλιμακώνει;

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

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

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

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

Τι είναι η διάσωση έργου SAP;

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

Πώς ξέρω αν το έργο SAP μου χρειάζεται διάσωση;

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

Τι πρέπει να γίνει την πρώτη εβδομάδα της διάσωσης μιας υλοποίησης SAP;

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

Πρέπει να αντικαταστήσουμε τον συνεργάτη υλοποίησης SAP κατά τη διάσωση;

Όχι αυτόματα. Ζητήστε από τον συνεργάτη να δείξει το εγκατεστημένο σύστημα σε σχέση με τον υπογεγραμμένο σχεδιασμό, και να σας δώσει έναν high-level σχεδιασμό για την ολοκλήρωση με αναφορές από παρόμοιες διασώσεις.

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

Γιατί οι μεταβάσεις σε SAP S/4HANA βγαίνουν εκτός πορείας;

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

Θα σπρώξει μια διάσωση τη μετάβαση από ECC πέρα από την προθεσμία του 2027;

Ενδέχεται. Η κύρια συντήρηση για το SAP ERP 6.0 στα enhancement packages 6 έως 8 λήγει στις 31 Δεκεμβρίου 2027, και η προαιρετική εκτεταμένη συντήρηση διαρκεί έως το τέλος του 2030 με επιβάρυνση δύο μονάδων. Προβλέψτε στον προϋπολογισμό την εκτεταμένη συντήρηση αντί να επιβάλετε ένα go-live που δεν στηρίζουν οι πρόβες σας.