Επτά πλαίσια συμβουλευτικής για την υλοποίηση SAP και AI

Όταν ένα πρόγραμμα SAP ή AI κολλάει, η αιτία είναι συνήθως δομική, και επτά απλά πλαίσια τη βρίσκουν. Χαρτογραφήστε την τρέχουσα κατάσταση. Συμφωνήστε ποιος αποφασίζει τι με ένα RACI. Συνδέστε τη δουλειά με επιχειρησιακές δυνατότητες. Βρείτε βασικές αιτίες με τα πέντε γιατί. Ιεραρχήστε τις απαιτήσεις με το MoSCoW. Ιεραρχήστε τους κινδύνους με βάση το τι μπορεί πραγματικά να σταματήσει το πρόγραμμα. Τρέξτε ένα πραγματικό post-mortem μετά από κάθε φάση. Ο οδηγός αυτός απευθύνεται σε διευθυντές προγραμμάτων, συμβούλους και χορηγούς στην υλοποίηση SAP και AI. Ξεκινήστε από τον πίνακα παρακάτω: βρείτε το σύμπτωμά σας και χρησιμοποιήστε πρώτα το αντίστοιχο πλαίσιο.

Μια εταιρεία μέσων ενημέρωσης μεσαίου μεγέθους στο Κατάρ έκανε rollout του SAP σε διάφορες περιοχές. Τα οικονομικά και οι προμήθειες έμπαιναν σε παραγωγή στην πρώτη φάση. Ήθελε επίσης μοντέλα πρόβλεψης AI στις αναφορές της.

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

Ήταν εκείνη η ενδιάμεση φάση. Πολύ νωρίς για να το πεις αποτυχία. Πολύ αργά για να προσποιηθείς ότι θα διορθωθεί από μόνο του.

Εφαρμόσαμε τα πλαίσια βήμα προς βήμα. Δεν ήταν όλα ευπρόσδεκτα στην αρχή. Ορισμένες συνεδρίες ήταν σιωπηλές. Άλλες ξέφυγαν. Η δομή όμως έκανε τη δουλειά ευκολότερη: η ομάδα σταμάτησε να γυρίζει γύρω γύρω, το backlog έγινε διαχειρίσιμο και οι περιπτώσεις χρήσης AI απέκτησαν πραγματικούς υπευθύνους. Το έργο μπήκε σε παραγωγή οκτώ εβδομάδες πιο αργά από το προγραμματισμένο. Όχι τέλειο. Αλλά παραδόθηκε, και η δεύτερη φάση ξεκίνησε σε καλύτερο έδαφος, με λιγότερους αγνώστους.

Έχω χρησιμοποιήσει εκδοχές και των επτά σε 23 χρόνια υλοποιήσεων σε προγράμματα SAP, Oracle και AI στον Κόλπο, στην Ευρώπη και αλλού. Κανένα δεν είναι εξωτικό. Όλα δουλεύουν αν τα εφαρμόσετε με πειθαρχία και όχι ως ασκήσεις τεκμηρίωσης.

Αντιστοιχίστε το σύμπτωμα με το πλαίσιο:

Σύμπτωμα που βλέπετε	Πλαίσιο	Τι παράγει	Τυπική προσπάθεια
Οι χρήστες ενέκριναν τις απαιτήσεις αλλά εξακολουθούν να είναι μπερδεμένοι	1. Χαρτογράφηση τρέχουσας κατάστασης	Ένας κοινός χάρτης του πώς γίνεται πραγματικά η δουλειά σήμερα	3 έως 5 ημέρες workshops
Οι αποφάσεις αναπηδούν από συνάντηση σε συνάντηση	2. RACI στις κρίσιμες αποφάσεις	Ονομαστικοί υπεύθυνοι αποφάσεων για τις 20 έως 30 βασικές αποφάσεις	Ένα workshop, μετά επιβολή
Οι χορηγοί έχουν αποσυρθεί από «το έργο IT»	3. Χαρτογράφηση δυνατοτήτων	Η πρόοδος αναφέρεται ως επιχειρησιακές δυνατότητες	Ενσωματωμένο στο fit-to-standard
Ο ίδιος τύπος σφάλματος συνεχίζει να επιστρέφει	4. Πέντε γιατί	Μια βασική αιτία που μπορείτε να αλλάξετε	Μία συνεδρία με διευκολυντή ανά πρόβλημα
Όλα έχουν σημανθεί ως υψηλής προτεραιότητας	5. MoSCoW	Ένα ιεραρχημένο πεδίο εφαρμογής με ρεαλιστική λίστα Must Have	Μία κοινή συνεδρία επιχείρησης και IT
Το μητρώο κινδύνων φαίνεται εντάξει αλλά η ομάδα νιώθει ένταση	6. Ιεράρχηση κινδύνων	Ξεχωριστές λίστες για κινδύνους που σταματούν το πρόγραμμα και για ενοχλητικούς κινδύνους	Εβδομαδιαία αναθεώρηση 30 λεπτών
Τα ίδια λάθη επαναλαμβάνονται φάση μετά τη φάση	7. Post-mortem	Τρεις έως πέντε αλλαγές με υπευθύνους	Μισή ημέρα μετά από κάθε φάση

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

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

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

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

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

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

Ένας πίνακας RACI (Responsible, Accountable, Consulted, Informed) δίνει σε κάθε απόφαση και παραδοτέο έναν υπεύθυνο. Ένα πρόσωπο είναι Accountable και μπορεί να είναι και Responsible ή να το αναθέσει. Οι Consulted δίνουν τη γνώμη τους. Οι Informed ακούν το αποτέλεσμα.

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

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

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

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

Στο SAP Activate αυτό αντιστοιχεί στα workshops fit-to-standard στο Explore. Κάθε διαδικασία εντός πεδίου είναι μια δυνατότητα, και κάθε κενό ανάμεσα στο τυπικό SAP και στην απαιτούμενη δυνατότητα είναι μια απόφαση: αποδοχή του τυπικού, διαμόρφωση μιας παραλλαγής ή επέκταση. Η διατήρηση της συζήτησης σε επίπεδο δυνατότητας κρατά την προσοχή της επιχείρησης σε όλη τη διάρκεια της κατασκευής, και αποκαλύπτει δυνατότητες που όλοι θεωρούσαν εντός πεδίου αλλά κανείς δεν επιβεβαίωσε.

Όταν το ίδιο είδος προβλήματος εμφανίζεται συνεχώς σε sprints ή φάσεις, το μπάλωμα κάθε περίπτωσης δεν βοηθά. Η αιτία βρίσκεται ανάντη.

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

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

1. 01Σφάλματα στη δοκιμαστική φόρτωσηΤο σύμπτωμα
2. 02Λάθος αντιστοιχίσεις πεδίωνΓιατί απέτυχε η φόρτωση
3. 03Η προδιαγραφή δεν αναθεωρήθηκεΓιατί ήταν λάθος οι αντιστοιχίσεις
4. 04Ο ιδιοκτήτης ορίστηκε πολύ αργάΓιατί δεν αναθεωρήθηκε η προδιαγραφή
5. 05Το σχέδιο δεν είχε την εξάρτησηΓιατί καθυστέρησε ο ιδιοκτήτης

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

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

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

Το MoSCoW (Must have, Should have, Could have, Won't have this time) επιβάλλει την επιλογή. Το Must Have είναι το ελάχιστο που χρειάζεται για το go-live. Το Should Have είναι σημαντικό αλλά όχι εμπόδιο. Το Could Have είναι επιθυμητό αν το επιτρέπουν ο χρόνος και ο προϋπολογισμός. Το Won't Have αναβάλλεται ρητά.

Η πειθαρχία βρίσκεται στη γραμμή του Must Have. Το πρώτο πέρασμα μιας άσκησης MoSCoW συνήθως βάζει πολύ περισσότερα στο Must Have απ' όσα πρέπει. Η καθοδήγηση DSDM από το Agile Business Consortium, από όπου προέρχεται το MoSCoW, θέτει ανώτατο όριο 60% της προσπάθειας στα Must Have και προειδοποιεί ότι ένα υψηλότερο ποσοστό θέτει σε κίνδυνο την παράδοση. Το κενό ανάμεσα στο πρώτο πέρασμα και σε μια ρεαλιστική λίστα είναι ως επί το πλείστον υποθέσεις που δεν έχουν δοκιμαστεί.

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

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

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

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

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

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

Ένα χρήσιμο post-mortem θέτει τέσσερις ερωτήσεις. Τι σχεδιάζαμε να πετύχουμε και τι πετύχαμε; Τι πήγε καλά και πρέπει να επαναληφθεί; Τι πήγε άσχημα και τι το προκάλεσε; Τι θα κάναμε διαφορετικά; Πρέπει να τελειώνει με τρεις έως πέντε συγκεκριμένες ενέργειες με υπευθύνους, όχι με ένα έγγραφο που συνοψίζει τι έγινε.

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

Στο Κατάρ, το post-mortem έτρεξε αμέσως μετά το go-live και εστίασε στη δράση, όχι στην ενοχοποίηση. Είναι μεγάλο μέρος του γιατί η δεύτερη φάση ξεκίνησε σε καλύτερο έδαφος.

Τα πλαίσια δεν έχουν αλλάξει. Έχει αλλάξει ο τρόπος που εφαρμόζονται, με τρεις τρόπους.

Η σύνταξη έγινε ταχύτερη, η ακρόαση όχι. Τα εργαλεία AI μετατρέπουν πλέον απομαγνητοφωνήσεις workshops και έγγραφα διαδικασιών σε έναν χάρτη πρώτου περάσματος μέσα σε λεπτά, και το SAP Cloud ALM μπορεί να συντάξει απαιτήσεις από απομαγνητοφωνήσεις fit-to-standard. Τα ίδια τα workshops παίρνουν όσο χρόνο έπαιρναν πάντα, επειδή η ακρόαση είναι το ζητούμενο. Ο χρόνος που εξοικονομείται στη σύνταξη πρέπει να πάει στο να αμφισβητήσετε τον χάρτη με ανθρώπους.

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

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

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

Τι είναι τα πλαίσια συμβουλευτικής και γιατί τα χρησιμοποιούν τα έργα SAP;

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

Χωρίς μία, κάθε ομάδα καταφεύγει στο δικό της νοητικό μοντέλο: αποτελέσματα διαδικασιών, αρχιτεκτονική ή χρονοδιάγραμμα και πόροι. Πλαίσια όπως η χαρτογράφηση τρέχουσας κατάστασης, το RACI και το MoSCoW κάνουν τη διαφωνία ρητή και επιλύσιμη. Το SAP Activate είναι το ίδιο ένα πλαίσιο για φάσεις, gates και παραδοτέα. Αυτά τα επτά δουλεύουν μέσα σε αυτό και χειρίζονται τα δομικά και ανθρώπινα ζητήματα που η μεθοδολογία μόνη της δεν λύνει.

Πώς λειτουργεί η χαρτογράφηση τρέχουσας κατάστασης σε μια υλοποίηση SAP;

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

Τροφοδοτεί τα workshops fit-to-standard στη φάση Explore του SAP Activate, όπου η τρέχουσα κατάσταση γίνεται η βάση αναφοράς που συγκρίνεται με τις τυπικές διαδικασίες του SAP. Ολοκληρώστε την προτού ξεκινήσουν αυτά τα workshops, αλλιώς η ανάλυση κενών σας στηρίζεται σε υποθέσεις.

Τι είναι η ιεράρχηση MoSCoW και πότε χρησιμοποιείται στα προγράμματα SAP;

Το MoSCoW ταξινομεί τις απαιτήσεις σε Must have, Should have, Could have και Won't have this time. Τα Must Have είναι το ελάχιστο για το go-live. Τα Won't Have εξαιρούνται ρητά ώστε να μην επιστρέψουν κρυφά.

Είναι πιο χρήσιμο στο Explore, όταν τα ευρήματα fit-gap οδηγούν αποφάσεις επέκτασης, και στο Realize, όταν τα σφάλματα και οι βελτιώσεις ανταγωνίζονται για χρόνο κατασκευής. Το συνηθισμένο πρόβλημα είναι πάρα πολλά Must Have στο πρώτο πέρασμα. Το DSDM προτείνει όχι περισσότερο από 60% της προσπάθειας στα Must Have. Ένας διευκολυντής που αμφισβητεί το καθένα, με την επιχείρηση και το IT στην ίδια συνεδρία, σας φέρνει εκεί.

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

Ως συζήτηση, όχι ως ενημέρωση κατάστασης. Ξεκινήστε με ανοιχτές ερωτήσεις όπως «Ποια είναι η μεγαλύτερη ανησυχία σας αυτή την εβδομάδα που δεν βρίσκεται στο μητρώο;» προτού περάσετε το μητρώο.

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

Τι κάνει ένα post-mortem χρήσιμο μετά από ένα go-live SAP;

Συγκεκριμένες, εφαρμόσιμες αλλαγές για την επόμενη φάση. Μια περίληψη του τι έγινε είναι καταγραφή, όχι post-mortem.

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

Πώς βοηθούν τα πλαίσια συμβουλευτικής στην υλοποίηση AI σε περιβάλλοντα SAP;

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

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