Αξιολόγηση κινδύνων έργου SAP: η πρακτική εκδοχή

Μια αξιολόγηση κινδύνων έργου SAP απαριθμεί ό,τι θα μπορούσε να εκτροχιάσει το πρόγραμμα και βαθμολογεί κάθε κίνδυνο με βάση την πιθανότητα και τον αντίκτυπο. Κάθε κίνδυνος παίρνει έναν ονομαστικό υπεύθυνο και μια απάντηση συμφωνημένη πριν συμβεί, και η λίστα αναθεωρείται κάθε εβδομάδα. Οι κίνδυνοι που βυθίζουν τα προγράμματα SAP σπάνια είναι εκπλήξεις: μετάπτωση δεδομένων, ενοποίηση, διαθεσιμότητα ανθρώπων, παρέκκλιση πεδίου εφαρμογής και υιοθέτηση. Ο οδηγός απευθύνεται σε διευθυντές προγραμμάτων και χορηγούς που θέλουν ένα μητρώο κινδύνων που αλλάζει αποφάσεις και όχι ένα που μένει σε φάκελο. Σας δίνει μια μήτρα με βαθμολογία, ένα πρότυπο μητρώου, τρεις δημόσιες αποτυχίες ως παραδείγματα και τους κινδύνους που προσθέτουν το RISE with SAP και το clean core. Ξεκινήστε βάζοντας έναν ονομαστικό υπεύθυνο σε κάθε κίνδυνο που ήδη έχετε.

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

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

Οι κίνδυνοι δεν ήταν εκπλήξεις. Ήταν τεκμηριωμένοι. Κανείς δεν έδρασε.

Πεδίο εφαρμογής. Το έργο ξεκινά με τυπικά modules. Μετά κάποιος προσθέτει «μόνο μία αναφορά ακόμη», μετά ένα dashboard, μετά μερικές βελτιώσεις. Ο κίνδυνος είναι οι αλλαγές πεδίου που εισάγονται άτυπα σε workshops, email και συζητήσεις στους διαδρόμους και που ο υπεύθυνος του έργου μαθαίνει μόνο αφού έχει τελειώσει η παραμετροποίηση. Ο οδηγός μου για την αποφυγή του scope creep καλύπτει τους ελέγχους.

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

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

Χρονοδιάγραμμα. Ένα καθυστερημένο blueprint στριμώχνει τις δοκιμές, αλλά η ημερομηνία του go-live μένει σταθερή. Το UAT, η εκπαίδευση και η προετοιμασία δεδομένων γίνονται βιαστικά. Το ίδιο μοτίβο εμφανίζεται σε σχεδόν κάθε πρόγραμμα που χάνει μια πύλη φάσης και δεν μετακινεί το επόμενο σχέδιο.

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

Αυτές οι περιπτώσεις είναι δημόσιες και καλά τεκμηριωμένες. Τα μοτίβα επαναλαμβάνονται σε κάθε κλίμακα.

Lidl: περίπου 500 εκατ. € σε επτά χρόνια

Η Lidl ξεκίνησε το έργο eLWIS στο SAP for Retail το 2011, έκανε go-live σε ορισμένες μικρότερες χώρες και το εγκατέλειψε το 2018 με αναφερόμενο κόστος περίπου 500 εκατ. €. Μία ευρέως αναφερόμενη αιτία: η Lidl αποτιμούσε τα αποθέματα σε τιμές αγοράς, ενώ το τυπικό μοντέλο λιανικού του SAP χρησιμοποιεί τιμές λιανικής. Η Lidl προσάρμοσε το σύστημα αντί να αλλάξει την πρακτική και η εταιρεία δήλωσε ότι οι αρχικοί στόχοι δεν μπορούσαν να επιτευχθούν με εύλογη προσπάθεια.

Δίδαγμα: μια αναντιστοιχία ανάμεσα στο μοντέλο δεδομένων σας και στο standard του SAP είναι κίνδυνος της πρώτης εβδομάδας, όχι ανακάλυψη του πέμπτου έτους.

HP: περίπου 400 εκατ. $ χαμένα έσοδα

Το 2004 η HP μετέφερε μέρος της επιχείρησής της σε servers σε ένα ενοποιημένο σύστημα παραγγελιών και εφοδιαστικής αλυσίδας βασισμένο στο SAP. Παραγγελίες έπεφταν ανάμεσα στο legacy front end και το SAP και χρειάζονταν χειρωνακτική δουλειά, και το backlog διπλασιάστηκε. Ο CEO της HP είπε ότι τα προβλήματα κόστισαν στην ομάδα servers και αποθήκευσης περίπου 400 εκατ. $ σε έσοδα και 275 εκατ. $ σε λειτουργικό κέρδος, αφήνοντας ένα backlog 120 εκατ. $. Ο CIO της HP είπε αργότερα ότι η ομάδα είχε σχεδιάσει τρεις εβδομάδες διακοπών και έπρεπε να είχε έκτακτο σχέδιο για τέσσερις έως έξι.

Δίδαγμα: διαστασιολογήστε το έκτακτο σχέδιο για ένα κακό cutover, όχι για ένα μέσο, και χτίστε αποθέματα ή buffers καναλιών πριν κάνετε τη μετάβαση.

Nike: πάνω από 100 εκατ. $ χαμένες πωλήσεις

Το 2000 η Nike έκανε go-live με το λογισμικό σχεδιασμού ζήτησης i2 πριν από το πρόγραμμά της SAP ERP. Το λογισμικό είχε προσαρμοστεί βαριά ώστε να δουλεύει με τα legacy συστήματα της Nike, έτρεχε αργά και κατέρρεε υπό τον όγκο προϊόντων. Παρήγγειλε υπερβολικά πολλά από κάποια παπούτσια και πολύ λίγα από άλλα. Η Nike έχασε πάνω από 100 εκατ. $ σε πωλήσεις και η μετοχή της έπεσε περίπου 20%. Η Nike μετέφερε αργότερα τον βραχυπρόθεσμο και μεσοπρόθεσμο σχεδιασμό στο SAP.

Δίδαγμα: ποτέ μην υποθέτετε ότι μια ενοποίηση δουλεύει μέχρι να έχει τρέξει σε παραγωγικό όγκο με πραγματικά δεδομένα.

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

1. Τεκμηρίωση πεδίου εφαρμογής: χάρτα έργου, εγκεκριμένο πεδίο εφαρμογής και υπογεγραμμένες απαιτήσεις. Αν δεν υπάρχουν, ο κίνδυνος πεδίου εφαρμογής είναι ήδη υψηλός.
2. Δεσμεύσεις πόρων: γραπτές δεσμεύσεις από τους επικεφαλής τμημάτων, πίνακας δεξιοτήτων για τους κρίσιμους ρόλους και ονομαστικός αναπληρωτής για κάθε βασική θέση.
3. Προϋπολογισμός και χρονοδιάγραμμα: εγκεκριμένος προϋπολογισμός με αποθεματικό για απρόβλεπτα και χρονοδιάγραμμα ελεγμένο απέναντι σε συγκρίσιμα προγράμματα. Έξι μήνες και ελάχιστη χρηματοδότηση για πλήρες rollout είναι κίνδυνος που πρέπει να επισημανθεί τώρα.
4. Δεσμεύσεις προμηθευτών: συμβόλαια με επίπεδα υπηρεσίας και ποινές. Στο RISE, οι ευθύνες της SAP και η διαδρομή κλιμάκωσης.
5. Τεχνικό τοπίο: συμβατότητα legacy, πολυπλοκότητα μετάπτωσης δεδομένων, μοντέλο ανάπτυξης και σχέδιο clean core για κάθε προσαρμοσμένη εργασία.
6. Αρχεία προηγούμενων έργων: μητρώα κινδύνων, αρχεία ζητημάτων και post-mortems από προηγούμενα προγράμματα SAP ή ERP. Οι περισσότεροι κίνδυνοι δεν είναι καινούργιοι.

Βαθμολογήστε κάθε κίνδυνο σε πιθανότητα και αντίκτυπο από 1 έως 5 και πολλαπλασιάστε. Το παρακάτω παράδειγμα είναι ένα τυπικό σημείο εκκίνησης για ένα πρόγραμμα S/4HANA. Οι δικές σας βαθμολογίες θα διαφέρουν.

Κίνδυνος	Πιθανότητα (1-5)	Αντίκτυπος (1-5)	Βαθμολογία	Προτεραιότητα
Αποτυχία μετάπτωσης δεδομένων	4	5	20	Υψηλή
Καθυστερήσεις ενοποίησης	4	4	16	Υψηλή
Περιορισμοί πόρων	4	4	16	Υψηλή
Υπέρβαση προϋπολογισμού	3	5	15	Μεσαία
Προσαρμοσμένος κώδικας στον πυρήνα που μπλοκάρει αναβαθμίσεις	3	5	15	Μεσαία
Scope creep	4	3	12	Μεσαία
Κενά κάλυψης δοκιμών	3	4	12	Μεσαία
Απόδοση υπό φορτίο αιχμής	3	4	12	Μεσαία
Κενά συμμόρφωσης	2	5	10	Μεσαία
Καμία διαδρομή κλιμάκωσης προς τη SAP (RISE)	2	5	10	Μεσαία
Χαμηλή υιοθέτηση από τους χρήστες	3	3	9	Μεσαία
Έκθεση σε κόστος συνδρομής ή αδειών	2	4	8	Μεσαία
Τα KPI δεν παρακολουθούνται	3	2	6	Χαμηλή

Οι βαθμολογίες 16 και άνω χρειάζονται ονομαστικό υπεύθυνο και ενέργεια τώρα. Οι βαθμολογίες από 8 έως 15 χρειάζονται παρακολούθηση με καθορισμένο trigger κλιμάκωσης. Κάτω από 8, κρατήστε τον κίνδυνο στο μητρώο χωρίς να ξοδέψετε προτεραιότητα χρόνου. Οι βαθμολογίες είναι σημείο εκκίνησης, όχι ετυμηγορία: ένα κενό συμμόρφωσης με βαθμολογία 10 μπορεί να γίνει 25 σε έναν ρυθμιζόμενο κλάδο.

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

Πεδίο	Τι να γράψετε	Παράδειγμα
Κίνδυνος	Το γεγονός, σε μία πρόταση	Τα κύρια δεδομένα προμηθευτών δεν καθαρίζονται πριν από το mock load 2
Υπεύθυνος	Ένα ονομαστικό πρόσωπο	Επικεφαλής πληρωτέων λογαριασμών
Βαθμολογία	Πιθανότητα × αντίκτυπος	4 × 5 = 20
Trigger	Το μετρήσιμο σημείο στο οποίο ενεργείτε	Ποσοστό διπλότυπων πάνω από 5% στην εξαγωγή του mock 1
Απάντηση	Αποφυγή, μετριασμός, μεταφορά ή αποδοχή, με την ενέργεια	Μετριασμός: δύο αναλυτές πληρωτέων στον καθαρισμό για τρεις εβδομάδες
Επόμενη αναθεώρηση	Ημερομηνία	Η αναθεώρηση κινδύνων της επόμενης Δευτέρας
Κατάσταση	Ανοιχτός, υπό ενέργεια, κλειστός	Υπό ενέργεια

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

Ο προσαρμοσμένος κώδικας είναι ξεχωριστή κατηγορία κινδύνου. Στο S/4HANA Cloud Public Edition, ο προσαρμοσμένος κώδικας στον πυρήνα δεν είναι δυνατός. Οι επεκτάσεις περνούν από το SAP BTP, released APIs ή εργαλεία key-user. Στο private cloud και στο on-premise μπορείτε ακόμη να τροποποιήσετε τον πυρήνα, και οι συνεργάτες που το έχουν συνηθίσει θα το κάνουν. Αυτό το τεχνικό χρέος βγαίνει στην επιφάνεια στην πρώτη μεγάλη αναβάθμιση. Παρακολουθήστε πόσες από τις εντοπισμένες προσαρμογές έχουν συμφωνημένη προσέγγιση clean core, ελέγξτε την εμπειρία του συνεργάτη στις επεκτάσεις BTP και στήστε ένα φόρουμ αναθεώρησης μέχρι το τέλος του Explore.

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

Η AI βοηθά με τα χαρτιά, όχι με την κρίση. Οι βοηθοί που βασίζονται στο Joule στο SAP Cloud ALM και εργαλεία όπως το Microsoft Copilot μπορούν να συντάξουν εγγραφές μητρώου και πακέτα για την επιτροπή καθοδήγησης από αναφορές κατάστασης, αρχεία ελαττωμάτων και πρακτικά. Αυτό επιταχύνει τη συντήρηση του μητρώου σε προγράμματα με καθαρά δεδομένα πηγής. Βρίσκει κινδύνους που είναι ήδη ορατοί στα δεδομένα. Δεν αποφασίζει ποιοι κίνδυνοι αξίζουν ενέργεια, δεν κάνει τους υπευθύνους να δράσουν και δεν κλιμακώνει τους κινδύνους που η ηγεσία θα προτιμούσε να αγνοήσει.

1. Εντοπίστε κινδύνους στις πέντε κατηγορίες. Τρέξτε workshops με το IT, την επιχείρηση και τους προμηθευτές: ο καθένας βλέπει διαφορετικούς κινδύνους. Στο RISE, συμπεριλάβετε τις επαφές της SAP σε τουλάχιστον ένα. Οι κίνδυνοι που συνήθως χάνουν οι ομάδες: το IT και η επιχείρηση να περιμένουν διαφορετικά πράγματα, κακώς ορισμένες εξωτερικές ενοποιήσεις, υπεύθυνοι UAT που δεν είναι διαθέσιμοι και άτυπες αλλαγές πεδίου εφαρμογής.
2. Βαθμολογήστε κάθε κίνδυνο σε πιθανότητα και αντίκτυπο, με πραγματικούς αριθμούς όπου είναι δυνατόν.
3. Ορίστε έναν υπεύθυνο ανά κίνδυνο. Ένα πρόσωπο, όχι μια ομάδα. Χωρίς υπεύθυνο, δεν υπάρχει παρακολούθηση ούτε επίλυση.
4. Ορίστε την απάντηση πριν προσγειωθεί ο κίνδυνος. Αποφυγή, μετριασμός, μεταφορά ή αποδοχή. Το «παρακολούθηση και αντίδραση» δεν είναι σχέδιο. Είναι αναβληθείσα απόφαση.
5. Αναθεωρείτε εβδομαδιαία. Ελέγξτε τους ανοιχτούς κινδύνους, προσθέστε νέους, αναβαθμολογήστε όπου άλλαξαν οι συνθήκες και κλιμακώστε ό,τι πλησιάζει το trigger του. Φέρτε τους κορυφαίους κινδύνους στην επιτροπή καθοδήγησης με προτεινόμενη απόφαση και όχι με ένα χρώμα.

1. 01ΕντοπισμόςΚαι οι πέντε κατηγορίες
2. 02ΒαθμολόγησηΠιθανότητα × αντίκτυπος, 1 έως 5
3. 03Ανάθεση υπευθύνουΈνα πρόσωπο, όχι ομάδα
4. 04Ορισμός απάντησηςΑποφυγή, μετριασμός, μεταφορά ή αποδοχή
5. 05Εβδομαδιαία αναθεώρησηΑναβαθμολόγηση, κλιμάκωση κοντά στα triggers

16 ή περισσότερο: ονομαστικός υπεύθυνος και ενέργεια αυτή την εβδομάδα

Τι είναι η αξιολόγηση κινδύνων σε ένα έργο SAP;

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

Πώς χτίζετε μια μήτρα κινδύνων για ένα έργο SAP;

Καταγράψτε κινδύνους σε πεδίο εφαρμογής, πόρους, τεχνικούς, χρονοδιάγραμμα και υιοθέτηση, συν το clean core και την κλιμάκωση προς τη SAP στο RISE. Βαθμολογήστε καθέναν σε πιθανότητα και αντίκτυπο από 1 έως 5 και πολλαπλασιάστε. Θεωρήστε το 16 και άνω υψηλό, το 8 έως 15 μεσαίο και το κάτω από 8 χαμηλό. Δώστε σε κάθε μεσαίο και υψηλό κίνδυνο έναν υπεύθυνο και ένα μετρήσιμο trigger, όπως «αν η ολοκλήρωση του UAT είναι κάτω από 80% την εβδομάδα 16, η ημερομηνία του go-live πηγαίνει για αναθεώρηση». Αναβαθμολογήστε εβδομαδιαία και σε κάθε πύλη φάσης.

Ποιοι είναι οι συχνότεροι κίνδυνοι στις υλοποιήσεις SAP;

Η αποτυχία μετάπτωσης δεδομένων, επειδή τα δεδομένα legacy είναι σχεδόν πάντα πιο ακατάστατα από όσο εκτιμήθηκε. Οι καθυστερήσεις ενοποίησης, ειδικά με μη τεκμηριωμένες διεπαφές legacy και προμηθευτές τρίτων. Το scope creep που συμπιέζει τις δοκιμές και την εκπαίδευση. Οι περιορισμοί πόρων, όπως βασικά άτομα που τραβιούνται αλλού ή χρήστες που δεν είναι διαθέσιμοι στο UAT στο κλείσιμο του μήνα. Η χαμηλή υιοθέτηση από εκπαίδευση που δείχνει οθόνες αντί να προσομοιώνει τη δουλειά. Στο RISE, προσθέστε τον προσαρμοσμένο κώδικα στον πυρήνα και την έλλειψη διαδρομής κλιμάκωσης προς τη SAP.

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

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

Ποιος πρέπει να έχει την ευθύνη των κινδύνων σε ένα πρόγραμμα SAP;

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

Τι συμβαίνει όταν παραλείπεται η αξιολόγηση κινδύνων ERP;

Σε μεγάλη κλίμακα, έχετε περιπτώσεις όπως η Lidl, που εγκατέλειψε το έργο SAP λιανικού το 2018 έπειτα από περίπου 500 εκατ. €. Ή η HP, της οποίας η μετάβαση στο σύστημα παραγγελιών SAP το 2004 κόστισε στην ομάδα servers της περίπου 400 εκατ. $ σε έσοδα. Σε μικρότερη κλίμακα ο μηχανισμός είναι ο ίδιος: αναντιστοιχίες μοντέλου δεδομένων που βρίσκονται αργά, ενοποιήσεις που αποτυγχάνουν σε παραγωγικό όγκο και αποτυχίες υιοθέτησης από αδύναμη εκπαίδευση. Οι κίνδυνοι ήταν εντοπίσιμοι πριν γίνουν προβλήματα.