Πώς να αποφύγετε τη διόγκωση του εύρους σε μια υλοποίηση SAP

Αποφεύγετε τη διόγκωση του εύρους (scope creep) σε μια υλοποίηση SAP κάνοντας κάθε αλλαγή ορατή και δύσκολη στην έγκριση. Γράψτε τι είναι εκτός εύρους με την ίδια προσοχή που γράφετε τι είναι εντός. Περάστε κάθε αίτημα από έλεγχο αλλαγών, με εκτίμηση επίπτωσης σε χρόνο, κόστος και ποιότητα. Απαιτήστε συμβιβασμό για κάθε προσθήκη. Ορίστε ημερομηνία παγώματος του εύρους με στήριξη από τα στελέχη και βάλτε την ίδια πειθαρχία στη σύμβαση με τον SI. Ο οδηγός απευθύνεται σε διευθυντές προγραμμάτων, χορηγούς και PMO σε προγράμματα S/4HANA. Χρησιμοποιήστε τον πίνακα κόστους αλλαγής και τις ρήτρες συμβολαίου παρακάτω στο επόμενο πακέτο σας για την επιτροπή καθοδήγησης.

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

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

Αυτά δεν είναι οριακές περιπτώσεις. Είναι ο συνηθέστερος τρόπος με τον οποίο αποτυγχάνουν τα προγράμματα SAP.

Ξεκινά αθώα. Ένας επικεφαλής της επιχείρησης ζητά «μόνο μία μικρή αλλαγή». Μετά άλλη μία. Η φράση «ήδη που είμαστε εκεί, απλώς...» έχει εκτροχιάσει περισσότερες υλοποιήσεις SAP από οποιαδήποτε τεχνική πρόκληση.

Δούλεψα με έναν πελάτη λιανικής όπου ξεκινήσαμε καθαρά: βασική Χρηματοοικονομική Λογιστική και βασική Διαχείριση Υλικών. Έξι μήνες μετά, ο CMO ήθελε αναλύσεις πελατών. Μετά ο COO χρειάστηκε προηγμένες λειτουργίες αποθήκης. Το αρχικό χρονοδιάγραμμα εννέα μηνών απειλούνταν. Αντέδρασα και απέρριψα και τα δύο αιτήματα. Αυτή η πειθαρχία είναι η δουλειά.

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

Ένας βιομηχανικός πελάτης ξεκίνησε με 10 προσαρμοσμένες αναφορές και κατέληξε σε 47, με την καθεμία να προσθέτει χρόνο σχεδιασμού, κατασκευής και δοκιμών. Το workstream αναφορών και μόνο ξεπέρασε τον προϋπολογισμό κατά 200%.

200%

υπέρβαση προϋπολογισμού του workstream αναφορών, όταν η ολίσθηση του εύρους ανέβασε τις προσαρμοσμένες αναφορές από 10 σε 47

Πηγή: Πρόγραμμα βιομηχανικού πελάτη

Προειδοποιητικά σημάδια

Αυτά είναι τα σημάδια που παρακολουθώ και η αντίδραση σε καθένα:

Προειδοποιητικό σημάδι	Υποκείμενη αιτία	Αντίδραση
Το «μόνο ένα ακόμη πράγμα» γίνεται καθημερινή γλώσσα	Ασαφή όρια εύρους	Επαναδιατυπώστε τη baseline με τους επικεφαλής της επιχείρησης· επιβάλετε τυπικό έλεγχο αλλαγών
Επικεφαλής της επιχείρησης προσθέτουν λειτουργίες άτυπα	Καμία κατανόηση της επίπτωσης στα επόμενα στάδια	Περάστε κάθε αίτημα από εκτίμηση επίπτωσης· δείξτε το κόστος
Το χρονοδιάγραμμα επεκτείνεται χωρίς τυπικό ανασχεδιασμό	Σιωπηρή διεύρυνση του εύρους	Κάντε σημεία ελέγχου του εύρους· ανασχεδιάστε με έγκριση του συμβουλίου αλλαγών
Η τεκμηρίωση δεν ταιριάζει πια με όσα έχουν χτιστεί	Άτυπος χειρισμός του εύρους, χωρίς έλεγχο εκδόσεων	Ενημερώνετε προδιαγραφές και σχέδια με κάθε εγκεκριμένη αλλαγή
Η κατανάλωση προϋπολογισμού προπορεύεται της προόδου	Κρυφή προσπάθεια από αδιαχείριστες αλλαγές	Παρακολουθήστε την προσπάθεια ανά πακέτο εργασίας· διερευνήστε τις αποκλίσεις
Η ομάδα δουλεύει νύχτες και Σαββατοκύριακα για να καλύψει τη διαφορά	Το εύρος υπερβαίνει τη δυναμικότητα	Κλιμακώστε στο συμβούλιο αλλαγών· επιβάλετε απόφαση για το εύρος
Αλληλοκατηγορίες μεταξύ επιχείρησης, IT και συνεργάτη	Το εύρος έχει ήδη ξεφύγει από κάθε έλεγχο	Παγώστε το εύρος, κάντε ανασκόπηση βασικής αιτίας, επαναφέρετε τη baseline

Όλα συνδέονται

Το SAP δένει τα πάντα μεταξύ τους. Τα οικονομικά επηρεάζουν την εφοδιαστική αλυσίδα. Το HR αγγίζει τη μισθοδοσία. Οι πωλήσεις συνδέονται με τα αποθέματα. Μία αλλαγή μπορεί να σπάσει δέκα πράγματα.

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

Η πίεση του «μία φορά σε μια δεκαετία»

Οι περισσότερες εταιρείες υλοποιούν SAP μία φορά κάθε 10 έως 15 χρόνια. Κάθε τμήμα ξέρει ότι δεν θα έχει άλλη ευκαιρία για μια δεκαετία. Κανείς δεν θέλει να ακούσει «φάση 2», που στις περισσότερες οργανώσεις σημαίνει ποτέ. Έτσι όλα σπρώχνονται στο τρέχον έργο και η λίστα εύρους γίνεται λίστα επιθυμιών.

Τι αλλάζει το clean core

Το clean core βάζει ένα τεχνικό φρένο στην προσαρμογή. Στο S/4HANA Cloud Public Edition, η τροποποίηση του πυρήνα δεν είναι δυνατή: οι επεκτάσεις περνούν μέσω δημοσιευμένων API, on-stack ή side-by-side στο SAP BTP. Στο Private Edition και στο on-premise η τροποποίηση είναι ακόμη δυνατή, αλλά οι οδηγίες της SAP τη θεωρούν έσχατη λύση, επειδή κάθε μία προσθέτει δουλειά στις αναβαθμίσεις.

Η χρήσιμη παρενέργεια είναι η πειθαρχία στο εύρος. Ένα αίτημα «απλώς να προσθέσουμε αυτό το βήμα έγκρισης στο τυπικό order-to-cash» παύει να είναι μια ανέμελη συζήτηση παραμετροποίησης και γίνεται επέκταση με δικό της κόστος σχεδιασμού, κατασκευής και δοκιμών. Βάλτε ένα φόρουμ ανασκόπησης επεκτάσεων κάτω από την επιτροπή καθοδήγησης, με έναν αρχιτέκτονα που μπορεί να εγκρίνει ή να απορρίψει, και πολλά από αυτά τα αιτήματα σταματούν πριν μπουν στη baseline. Τα προγράμματα on-premise χωρίς αυτό το φόρουμ επιστρέφουν στις παλιές συνήθειες. Ο οδηγός μου για το clean core εξηγεί πώς να στήσετε ένα.

1. Ορίστε το εύρος με ρητές εξαιρέσεις. Τεκμηριώστε τι είναι εκτός εύρους με την ίδια προσοχή που τεκμηριώνετε τι είναι εντός και πάρτε έγκριση και για τα δύο. Η ασάφεια είναι εκεί όπου ξεκινούν οι διαφωνίες.
2. Τρέξτε τυπικό έλεγχο αλλαγών με συνέπειες. Κάθε αλλαγή χρειάζεται εκτίμηση επίπτωσης σε κόστος, χρόνο και ποιότητα, ορατή σε όποιον την εγκρίνει.
3. Επικοινωνήστε τα όρια του εύρους σε κάθε συνεδρίαση της επιτροπής καθοδήγησης. Δείξτε την κατάσταση του εύρους με μια απλή προβολή κόκκινο, πορτοκαλί, πράσινο. Μεγάλο μέρος της ολίσθησης είναι παρεξήγηση.
4. Γράψτε ένα σχέδιο διαχείρισης εύρους. Ορίστε πώς αξιολογούνται, εγκρίνονται, κλιμακώνονται και παρακολουθούνται οι αλλαγές, ώστε κάθε workstream να τις χειρίζεται με τον ίδιο τρόπο. Το πρότυπο εύρους έργου SAP που έχω γράψει δίνει μια αρχική δομή.
5. Δώστε προτεραιότητες με MoSCoW. Must have, Should have, Could have, Won't have αυτή τη φορά. Πιέστε σθεναρά να μείνει σύντομη η λίστα Must have.
6. Κρατήστε έλεγχο εκδόσεων σε κάθε απόφαση. Κάθε εγκεκριμένη αλλαγή ενημερώνει τη baseline. Κάθε απορριφθείσα αλλαγή καταγράφεται με τον λόγο.
7. Απαιτήστε συμβιβασμούς. Αν μπει μια νέα απαίτηση, κάτι άλλο βγαίνει. Τα must-have γίνονται γρήγορα προαιρετικά όταν κοστίζουν κάτι.

Τρεις τεχνικές που έχω χρησιμοποιήσει κάνουν αυτές τις στρατηγικές να κρατήσουν.

Πειθαρχία στις υπογραφές. Κάντε τους επικεφαλής της επιχείρησης να υπογράφουν τις εγκεκριμένες απαιτήσεις. Σε ένα πρόγραμμα, ένας επικεφαλής της επιχείρησης ορκιζόταν ότι δεν είχε εγκρίνει ποτέ μια συγκεκριμένη ροή διαδικασίας. Παρουσιάσαμε το έγγραφο με την υπογραφή του και η διαφωνία τελείωσε. Η υπογραφή δεν είναι γραφειοκρατία. Εμποδίζει την ίδια διαφωνία να ξεκινήσει ξανά έξι μήνες αργότερα.

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

Δείξτε το κόστος της αλλαγής. Μια αλλαγή κατά τον σχεδιασμό μπορεί να κοστίσει 5.000 δολάρια. Η ίδια αλλαγή κατά τις δοκιμές μπορεί να κοστίσει 50.000 δολάρια. Βάλτε ένα απλό διάγραμμα αυτού μπροστά στους ανθρώπους και τα ανέμελα αιτήματα επιβραδύνονται.

Αυτά είναι ενδεικτικά εύρη κόστους αλλαγής για προγράμματα S/4HANA στην αγορά των ΗΠΑ. Διαφέρουν ανάλογα με την πολυπλοκότητα και τον συνεργάτη. Χρησιμοποιήστε τα ως άγκυρες, όχι ως προσφορές.

Φάση	Τυπικό κόστος μικρής αλλαγής	Τυπικό κόστος μεσαίας αλλαγής
Explore (σχεδιασμός)	2 χιλ. $ έως 10 χιλ. $	10 χιλ. $ έως 30 χιλ. $
Αρχές Realize	5 χιλ. $ έως 20 χιλ. $	20 χιλ. $ έως 80 χιλ. $
Μέσα Realize (κατασκευή)	15 χιλ. $ έως 50 χιλ. $	50 χιλ. $ έως 200 χιλ. $
Τέλη Realize (δοκιμές)	30 χιλ. $ έως 100 χιλ. $	100 χιλ. $ έως 400 χιλ. $
Deploy και cutover	80 χιλ. $ έως 300 χιλ. $	300 χιλ. $ έως 1 εκατ. $+
Hypercare (μετά το go-live)	150 χιλ. $ έως 500 χιλ. $	500 χιλ. $ έως 2 εκατ. $+

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

Ρήτρες συμβολαίου που μετρούν

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

Ρήτρα	Σκοπός
Εύρος με ρητές εξαιρέσεις	Περιορίζει τι καλύπτει η σταθερή τιμή και αφαιρεί την ασάφεια για τα πρόσθετα
Προσυμφωνημένες τιμές για συνηθισμένες αλλαγές	Κλειδώνει τις τιμές για αναφορές, διεπαφές και αλλαγές παραμετροποίησης πριν έρθει η πίεση
Συνέχεια των συμβούλων	Εμποδίζει τους νέους συμβούλους να ανοίγουν ξανά αποφάσεις που έχουν κλείσει και να διευρύνουν το εύρος
Εξουσία έγκρισης και από τις δύο πλευρές	Εμποδίζει τους κατώτερους συμβούλους να υπόσχονται λειτουργίες που κανείς δεν ενέκρινε
Τιμολόγηση βάσει ορόσημων	Δένει την πληρωμή με εγκεκριμένα παραδοτέα, όχι με τον χρόνο που πέρασε
Κριτήρια αποδοχής ανά παραδοτέο	Ορίζει το «τελείωσε» πριν κάποιος αρχίσει να διαφωνεί
Ρήτρα επεκτάσεων clean core	Απαιτεί οι επεκτάσεις να χρησιμοποιούν δημοσιευμένα API ή το SAP BTP· γλιτώνει επανεργασία στην πρώτη μεγάλη αναβάθμιση

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

Συμβούλιο ελέγχου αλλαγών

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

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

Το εύρος κινείται μόνο μέσω του συμβουλίου

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

Οι περισσότερες αποφάσεις πρέπει να μένουν σε επίπεδο συμβουλίου. Μόνο οι πραγματικές διαφωνίες πηγαίνουν στον χορηγό, κάτι που τον κρατά εμπλεκόμενο χωρίς να τον πνίγει. Κάντε ανασκόπηση εύρους με τους επικεφαλής των workstream κάθε δύο εβδομάδες και αναφέρετε τα αιτήματα που υποβλήθηκαν, εγκρίθηκαν και απορρίφθηκαν. Όταν οι άνθρωποι βλέπουν «15% αύξηση εύρους αυτόν τον μήνα» σε μια αναφορά προόδου, η συμπεριφορά αλλάζει.

Κάποιες αλλαγές είναι απαραίτητες. Ένας φαρμακευτικός πελάτης μου βρέθηκε αντιμέτωπος με νέους κανονισμούς του FDA στη μέση της υλοποίησης. Έπρεπε να μπουν. Αυτό δεν είναι διόγκωση του εύρους. Αυτό είναι η πραγματικότητα.

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

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

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

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

Ένας άλλος πελάτης χρησιμοποίησε ένα σύστημα με μάρκες: κάθε τμήμα έπαιρνε τρεις μάρκες αλλαγής για ολόκληρο το έργο. Θέλετε μια αλλαγή; Ξοδέψτε μια μάρκα. Οι άνθρωποι σκέφτηκαν σοβαρά τι μετράει και τα «must-have» ξαναεξετάστηκαν μόλις κόστισαν σε περιορισμένο νόμισμα.

Καμία από τις δύο προσεγγίσεις δεν είναι περίπλοκη. Και οι δύο θέλουν πειθαρχία και στήριξη από την ηγεσία. Το τεστ κάθε διαδικασίας εύρους είναι η ημέρα που ο COO μπαίνει στην αίθουσα του έργου με «μόνο μία μικρή αλλαγή». Χτίστε τη για εκείνη την ημέρα.

Τι είναι το scope creep σε ένα έργο SAP;

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

Οι θεμιτές αλλαγές εύρους ακολουθούν διαδικασία και συνοδεύονται από προσαρμογές χρονοδιαγράμματος και προϋπολογισμού. Το scope creep φτάνει άτυπα και παρακάμπτει τον έλεγχο αλλαγών.

Ποιες είναι οι συνηθέστερες αιτίες του scope creep στα έργα SAP;

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

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

Πώς αλλάζει το clean core τον κίνδυνο scope creep;

Προσθέτει ένα τεχνικό φρένο. Στο S/4HANA Cloud Public Edition ο πυρήνας δεν μπορεί να τροποποιηθεί, οπότε κάθε κενό γίνεται επέκταση με δικό της κόστος σχεδιασμού, κατασκευής και δοκιμών. Στο Private Edition και στο on-premise η τροποποίηση είναι δυνατή αλλά προσθέτει δουλειά στις αναβαθμίσεις, γι' αυτό οι οδηγίες της SAP την αποθαρρύνουν.

Ένα φόρουμ ανασκόπησης επεκτάσεων, με έναν αρχιτέκτονα που έχει εξουσία απόφασης, σταματά πολλά αιτήματα πριν μπουν στη baseline. Χωρίς αυτό το φόρουμ, τα προγράμματα on-premise γυρίζουν στις παλιές συνήθειες.

Ποια είναι η διαφορά ανάμεσα στο scope creep και το gold-plating;

Το scope creep προέρχεται από την επιχείρηση: αιτήματα πέρα από όσα συμφωνήθηκαν. Το gold-plating προέρχεται από την ομάδα παράδοσης: πολυπλοκότητα που κανείς δεν ζήτησε.

Στους όρους του SAP, το gold-plating είναι ένας σύμβουλος που χτίζει περίτεχνη λογική ροής εργασίας όπου θα αρκούσε απλή δρομολόγηση. Το scope creep είναι ο COO που ζητά προηγμένες λειτουργίες αποθήκης έξι μήνες μέσα σε ένα έργο με εύρος βασικού MM. Και τα δύο διογκώνουν το κόστος και τον χρόνο και θέλουν την ίδια πειθαρχία.

Πώς δομείτε μια διαδικασία ελέγχου αλλαγών που πραγματικά δουλεύει;

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

Αυτός ο τελευταίος κανόνας και μόνο φιλτράρει τα αιτήματα που δεν είναι πραγματικά κρίσιμα.

Μπορείτε να αποφύγετε εντελώς το scope creep;

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

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

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

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

Όταν ο CEO πρέπει να εγκρίνει προσωπικά κάθε αλλαγή μετά το πάγωμα, η λίστα μένει πολύ σύντομη.