Χρονοδιάγραμμα υλοποίησης SAP: 5 λάθη που πρέπει να αποφύγετε

Το χρονοδιάγραμμα υλοποίησης SAP είναι το σχέδιο ανά φάση, από το Discover μέχρι το hypercare. Για ένα έργο σε public cloud, η ανασκόπηση εκατοντάδων έργων από έναν product expert της SAP τοποθετεί το τυπικό go-live στους πέντε με επτά μήνες. Τα εταιρικά προγράμματα σε private cloud ή on-premise χρειάζονται πολύ περισσότερο από έναν χρόνο. Το αν θα αντέξει το σχέδιό σας εξαρτάται λιγότερο από τη μεθοδολογία και περισσότερο από πέντε λάθη σχεδιασμού: ημερομηνίες που κλειδώνουν πριν οριστεί το εύρος, μετάπτωση δεδομένων που ξεκινά αργά, πύλες ποιότητας που παραλείπονται, πρόωρη εκπαίδευση και go-live σε περίοδο αιχμής. Ο οδηγός απευθύνεται σε διευθυντές προγραμμάτων και χορηγούς έργων που χτίζουν ένα σχέδιο ή προσπαθούν να σώσουν ένα. Χρησιμοποιήστε τον πίνακα φάσεων ως σκελετό και ελέγξτε τον απέναντι στα πέντε λάθη. Κάθε επιπλέον μήνας καθυστέρησης μπορεί να σημαίνει 100.000 $ ή περισσότερα σε αμοιβές συμβούλων.

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

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

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

Λάθος 1: ορισμός προθεσμιών πριν γίνει κατανοητό το εύρος

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

Η λύση: κλειδώστε το χρονοδιάγραμμα μετά το Explore, όχι στο kickoff, και πείτε το από την αρχή στο διοικητικό συμβούλιο. Προσθέστε περιθώριο 15-20% πάνω από την εκτίμηση του προμηθευτή.

Λάθος 2: η μετάπτωση δεδομένων αντιμετωπίζεται ως ομάδα εργασίας που ξεκινά αργά

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

Η λύση: ξεκινήστε το data profiling στο Discover, όχι στο Realize. Τρέξτε μια πλήρη δοκιμαστική μετάπτωση στο Realize πριν αρχίσουν οι δοκιμές ολοκλήρωσης. Αν η δοκιμή αποτύχει, έχετε χρόνο να το διορθώσετε. Αν το ανακαλύψετε στο cutover, δεν έχετε. Το κείμενό μου για το γιατί αποτυγχάνει η μετάπτωση δεδομένων SAP καλύπτει αναλυτικά τον κύκλο των δοκιμαστικών μετατπτώσεων.

Λάθος 3: παράλειψη των πυλών ποιότητας υπό πίεση χρονοδιαγράμματος

Η πύλη ανάμεσα στο Realize και το Deploy είναι αυτή που οι ομάδες παραλείπουν συχνότερα, γιατί εκεί κορυφώνεται η πίεση να «γίνει απλώς το go-live». Η παράλειψη των πυλών ποιότητας για να «μείνουμε στο χρονοδιάγραμμα» προκαλεί μεγαλύτερες καθυστερήσεις αργότερα.

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

Λάθος 4: εκπαίδευση των χρηστών δύο μήνες πριν από το go-live

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

Η λύση: προγραμματίστε την εκπαίδευση δύο με τρεις εβδομάδες πριν από το go-live. Αξιοποιήστε τους power users ως εκπαιδευτές, γιατί οι άνθρωποι μαθαίνουν από συναδέλφους που εμπιστεύονται. Σχεδιάστε συνεδρίες υπενθύμισης κατά το hypercare. Ολόκληρη την προσέγγιση θα τη βρείτε στο άρθρο μου για τις στρατηγικές εκπαίδευσης SAP.

Λάθος 5: προγραμματισμός του go-live σε περιόδους αιχμής της επιχείρησης

Η Hershey έκανε go-live στο σύστημά της με SAP R/3, Siebel και Manugistics τον Ιούλιο του 1999, τρεις μήνες αργότερα από το σχέδιο και κατευθείαν μέσα στη σεζόν παραγγελιών του Halloween. Ο διευθύνων σύμβουλός της είπε στους αναλυτές ότι τα προβλήματα θα εμπόδιζαν τη Hershey να παραδώσει παραγγελίες Halloween αξίας 100 εκατ. $. Το δίδαγμα είναι προφανές και εξακολουθεί να αγνοείται.

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

Το SAP Activate αντικατέστησε την παλιά μεθοδολογία ASAP. Οι έξι φάσεις του είναι ο σκελετός κάθε σχεδίου S/4HANA, σε cloud ή on-premise. Οι διάρκειες παρακάτω είναι αφετηρίες σχεδιασμού για ένα εταιρικό πρόγραμμα, όχι υποσχέσεις.

1. 1Discover2 έως 4 εβδομάδες. Έξοδος: υπογεγραμμένο εύρος και κριτήρια επιτυχίας
2. 2Prepare3 έως 6 εβδομάδες. Έξοδος: εγκεκριμένη χάρτα έργου, γραπτή δέσμευση πόρων
3. 3Explore4 έως 8 εβδομάδες. Έξοδος: αποφάσεις για τα κενά με υπευθύνους, κλειδωμένο χρονοδιάγραμμα
4. 4Realize8 έως 16 εβδομάδες. Έξοδος: επιτυχής δοκιμαστική μετάπτωση, κλειστές δοκιμές ολοκλήρωσης
5. 5Deploy2 έως 4 εβδομάδες. Έξοδος: έγκριση UAT, πρόβα κλεισίματος, απόφαση go/no-go
6. 6Run4 έως 8 εβδομάδες hypercare. Έξοδος: σφάλματα κάτω από το όριο, υπογεγραμμένη υποστήριξη

Φάση	Τυπική διάρκεια	Τι συμβαίνει	Πύλη εξόδου πριν από την επόμενη φάση
Discover	2-4 εβδομάδες	Επιχειρηματική μελέτη (business case), εύρος, επιλογή μοντέλου υλοποίησης (public cloud, private cloud ή on-premise)	Υπογεγραμμένο εύρος και μετρήσιμα κριτήρια επιτυχίας
Prepare	3-6 εβδομάδες	Ένταξη της ομάδας, διακυβέρνηση, αρχιτεκτονική συστημάτων (system landscape), βασικό σχέδιο, μητρώο κινδύνων	Εγκεκριμένη χάρτα έργου, ονομαστοί υπεύθυνοι αποφάσεων ανά module, γραπτές δεσμεύσεις πόρων
Explore	4-8 εβδομάδες	Workshops Fit-to-Standard, κατάλογος κενών (gap log), κατάλογος RICEFW (αναφορές, διεπαφές, μετατροπές, βελτιώσεις, φόρμες, ροές εργασίας)	Αποφάσεις για τα κενά καταγεγραμμένες με υπευθύνους, κλειδωμένο χρονοδιάγραμμα
Realize	8-16 εβδομάδες	Παραμετροποίηση, ανάπτυξη, δοκιμές μονάδας και ολοκλήρωσης, δοκιμαστικές μετατπτώσεις	Επιτυχής δοκιμαστική μετάπτωση, κλειστές δοκιμές ολοκλήρωσης
Deploy	2-4 εβδομάδες	Δοκιμές αποδοχής χρηστών (UAT), πρόβα cutover, εκπαίδευση τελικών χρηστών, τελική φόρτωση	Έγκριση UAT, επιτυχής πρόβα κλεισίματος, απόφαση go/no-go
Run	4-8 εβδομάδες hypercare	Υποστήριξη στον χώρο εργασίας, καθημερινή διαλογή (triage), παράδοση στην υποστήριξη	Ανοιχτά σφάλματα κάτω από το συμφωνημένο όριο, υπογεγραμμένη μετάβαση στην υποστήριξη

Πού πηγαίνει πραγματικά ο χρόνος

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

Στο Prepare ξεκινούν οι τεχνικές καθυστερήσεις. Στο RISE with SAP την υποδομή την παρέχει η SAP. Στο on-premise την στήνουν ο πελάτης και ο συνεργάτης, και κάθε ολίσθηση εδώ μεταδίδεται σε όλη τη συνέχεια. Πάρτε τις δεσμεύσεις πόρων γραπτώς. Η προφορική διαθεσιμότητα εξανεμίζεται.

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

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

Το Deploy χρειάζεται σχέδιο cutover με ακριβή βήματα, ώρες και υπευθύνους. Το «μετάπτωση δεδομένων» δεν είναι βήμα.

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

Συνεργάστηκα με έναν πάροχο υγείας που είχε τρεις μήνες καθυστέρηση και αντιμετώπιζε υπέρβαση προϋπολογισμού 2 εκατ. $. Κάναμε επανεκκίνηση με τα workshops Fit-to-Standard του SAP Activate. Η ομάδα βρήκε 28 διαδικασίες οικονομικών και εφοδιαστικής αλυσίδας που μπορούσαν να τρέξουν χωρίς καμία προσαρμογή. Τα λόγια του υπευθύνου του έργου: «Χάσαμε μήνες σχεδιάζοντας πράγματα που η SAP είχε ήδη φτιάξει.» Επανήλθαν στο χρονοδιάγραμμα μέσα σε έξι εβδομάδες και έκαναν go-live στην ώρα τους.

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

Το Clean Core το κάνει ακόμη πιο ξεκάθαρο. Στο S/4HANA Cloud Public Edition οι τυπικές διαδικασίες είναι η μόνη επιλογή και οι επεκτάσεις βρίσκονται στο SAP BTP ή σε δημοσιευμένα (released) APIs. Σε private cloud και on-premise μπορείτε ακόμη να τροποποιείτε, αλλά οι οδηγίες Clean Core της SAP σπρώχνουν προς την ίδια κατεύθυνση. Όταν κάθε κενό απαιτεί απόφαση για επέκταση στο BTP με συγκεκριμένο κόστος, η συζήτηση για τις προσαρμογές γίνεται πιο ειλικρινής.

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

1. Public cloud (GROW with SAP, S/4HANA Cloud Public Edition, που πλέον πωλείται ως SAP Cloud ERP). Ένας product expert της SAP που εξέτασε εκατοντάδες έργα τοποθετεί το τυπικό go-live στους πέντε με επτά μήνες. Η προσφορά GROW Fast της SAP, που παρουσιάστηκε στις αρχές του 2026, στοχεύει σε δύο με τέσσερις μήνες με σταθερό εύρος. Τα μεγάλα έργα σε public cloud διαρκούν 12 μήνες ή περισσότερο.
2. Private cloud (RISE with SAP, που πλέον ονομάζεται SAP Cloud ERP Private) και on-premise. Το εταιρικό εύρος διαρκεί συνήθως 12-24 μήνες. Στο RISE την υποδομή τη διαχειρίζεται η SAP, κάτι που αφαιρεί μέρος της δουλειάς του Prepare. Δεν αφαιρεί την προσπάθεια για τα δεδομένα, τις δοκιμές και την αλλαγή.

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

Κλάδος	Εύρος σχεδιασμού	Τι το παρατείνει
Μεταποίηση	14-20 μήνες	Ποιότητα BOM και διαδρομών παραγωγής (routing), ρύθμιση MRP, απαιτήσεις QM
Λιανικό εμπόριο και καταναλωτικά αγαθά	12-18 μήνες	Ενσωμάτωση POS, όγκος κύριων δεδομένων, παράθυρα εποχικής αιχμής
Φαρμακευτικά	16-22 μήνες	Επικύρωση GxP, ιχνηλασιμότητα παρτίδων, σειριοποίηση
Επιχειρήσεις κοινής ωφέλειας	15-20 μήνες	Διαχείριση συσκευών, δομές τιμολόγησης χρεώσεων, ενσωμάτωση GIS και SCADA
Δημόσιος τομέας	18-24 μήνες	Λογιστική κονδυλίων (fund accounting), κανονισμοί προμηθειών, επιβάρυνση εγκρίσεων, εντοπιότητα δεδομένων
Αυτοκινητοβιομηχανία	16-22 μήνες	Εφοδιαστική αλυσίδα just-in-time, έλεγχος μηχανολογικών αλλαγών
Αεροδιαστημική και άμυνα	20-26 μήνες	Κυβερνητική υποβολή στοιχείων, λογιστική προγραμμάτων, ασφαλείς εφοδιαστικές αλυσίδες
Πετρέλαιο και φυσικό αέριο	18-24 μήνες	Λογιστική κοινοπραξιών (joint venture), δραστηριότητες έντασης παγίων
Χρηματοπιστωτικές υπηρεσίες	14-20 μήνες	Σχεδιασμός ρόλων για διαχωρισμό καθηκόντων, ρυθμιστική επικύρωση

Τι αλλάζουν τα εργαλεία AI και τι δεν αλλάζουν

Το SAP Joule for Consultants έγινε γενικά διαθέσιμο το 2025. Απαντά σε ερωτήσεις παραμετροποίησης από τη δική βάση γνώσεων της SAP, συμπεριλαμβανομένων των SAP Notes, και εξηγεί κώδικα ABAP. Το SAP Build Code, γενικά διαθέσιμο από τον Μάρτιο του 2024, παράγει κώδικα επέκτασης σε Java και JavaScript στο SAP BTP με το Joule.

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

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

1. Αργοπορημένες αλλαγές εύρους. Κλειδώστε το εύρος στο τέλος του Explore. Από εκεί και πέρα, μια επιτροπή ελέγχου αλλαγών εγκρίνει κάθε αλλαγή με συνημμένο τον αντίκτυπό της στο χρονοδιάγραμμα και στον προϋπολογισμό.
2. Ποιότητα δεδομένων. Οι περισσότερες εταιρείες παραλείπουν την αξιολόγηση δεδομένων στον σχεδιασμό. Ξεκινήστε μία τώρα. Τα κακά δεδομένα είναι η πιο συνεπής αιτία αποτυχίας των δοκιμαστικών μετατπτώσεων.
3. Στενώματα πόρων. Πάρτε γραπτές δεσμεύσεις από τους προϊσταμένους τμημάτων για συγκεκριμένα πρόσωπα και ημερομηνίες. Εκπαιδεύστε αναπληρωτή για κάθε κρίσιμο ρόλο.
4. Καθυστερήσεις αποφάσεων. Κλιμακώστε τις διαφωνίες για το εύρος μέσα σε 48 ώρες. Μην αφήνετε τις αποφάσεις να περιμένουν τις μηνιαίες αναθεωρήσεις.
5. Καθυστερημένη διαχείριση αλλαγής. Αρχίστε να μιλάτε με τους τελικούς χρήστες στο Prepare, όχι δύο εβδομάδες πριν από το go-live.

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

Όσον αφορά τα εργαλεία: το SAP Cloud ALM είναι η βασική πλατφόρμα της SAP για τη διαχείριση της υλοποίησης. Η κύρια συντήρηση του SAP Solution Manager 7.2 τελειώνει στα τέλη του 2027, με εκτεταμένη συντήρηση επιλεγμένων λειτουργιών έως το 2030 για πελάτες που παίρνουν την εκτεταμένη συντήρηση του Business Suite. Το SAP Best Practices Explorer αποσύρθηκε το 2023. Το περιεχόμενο διαδικασιών βρίσκεται πλέον στο SAP Signavio Process Navigator.

Πόσο διαρκεί μια υλοποίηση SAP το 2026;

Εξαρτάται από το μοντέλο υλοποίησης, το εύρος και τον κλάδο. Η ανασκόπηση εκατοντάδων έργων από έναν product expert της SAP τοποθετεί το S/4HANA Cloud Public Edition στους πέντε με επτά μήνες και την προσφορά GROW Fast της SAP, με σταθερό εύρος, στους δύο με τέσσερις. Τα εταιρικά προγράμματα σε RISE with SAP private cloud ή on-premise διαρκούν συνήθως 12 έως 24 μήνες. Τα προγράμματα του δημόσιου τομέα και της αεροδιαστημικής ξεπερνούν τακτικά τους 20 μήνες.

Πώς επηρεάζει το RISE with SAP το χρονοδιάγραμμα;

Το RISE μεταφέρει την ευθύνη της υποδομής στη SAP, κάτι που αφαιρεί μέρος της δουλειάς της φάσης Prepare. Δεν συντομεύει τη μετάπτωση δεδομένων, τις δοκιμές, την εκπαίδευση ή τη λήψη αποφάσεων, που είναι εκεί όπου πηγαίνει ο περισσότερος χρόνος. Η πειθαρχία Clean Core μπορεί να συντομεύσει το Realize, αν σταματήσει την ειδική ανάπτυξη πριν ξεκινήσει.

Πώς φτιάχνω ένα σχέδιο ορόσημων για μια υλοποίηση SAP;

Ξεκινήστε με τις έξι φάσεις του SAP Activate και γράψτε μετρήσιμα κριτήρια εξόδου για κάθε πύλη. Εντοπίστε τις δραστηριότητες της κρίσιμης διαδρομής και τις αλληλεξαρτήσεις σε κάθε φάση. Αντιμετωπίστε τις πύλες ως υποχρεωτικές στάσεις, παρακολουθήστε εβδομαδιαία σε σχέση με το σχέδιο και διαχειριστείτε το στο SAP Cloud ALM.

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

Οι μεγαλύτεροι είναι το εύρος (modules, οντότητες, ενοποιήσεις), ο όγκος των προσαρμογών, η ποιότητα δεδομένων, ο αριθμός χρηστών και η γεωγραφική διασπορά, η ταχύτητα λήψης αποφάσεων και η ρυθμιστική επικύρωση. Το μοντέλο υλοποίησης βρίσκεται πάνω από όλους. Το public cloud είναι το ταχύτερο, επειδή το εύρος και οι διαδικασίες είναι περιορισμένα. Το on-premise με βαριές προσαρμογές είναι το βραδύτερο.

Πώς μπορώ να επιταχύνω μια υλοποίηση SAP;

Εφαρμόστε το Fit-to-Standard με αυστηρότητα, επειδή κάθε προσαρμογή που αποφεύγετε εξοικονομεί εβδομάδες. Ξεκινήστε τον καθαρισμό δεδομένων στο Discover. Διαθέστε επιχειρησιακούς πόρους με πλήρη απασχόληση αντί να τους δανείζεστε με μερική. Συμφωνήστε τις διαδρομές έγκρισης πριν ξεκινήσει η παραμετροποίηση και ετοιμάστε το σχέδιο cutover κατά το Realize και όχι μετά.

Να επιλέξω big bang ή σταδιακή εισαγωγή του SAP;

Το big bang βάζει τα πάντα σε παραγωγή ταυτόχρονα. Είναι συνολικά ταχύτερο και πιο ριψοκίνδυνο, και ταιριάζει σε μικρότερο εύρος ή σε οργανισμούς με ισχυρή διαχείριση αλλαγής. Η σταδιακή εισαγωγή γίνεται ανά module, τοποθεσία ή επιχειρησιακή μονάδα. Έχει μικρότερο ρίσκο και διαρκεί περισσότερο, και ταιριάζει σε μεγάλους ομίλους με πολλές οντότητες. Πολλά προγράμματα μεσαίου μεγέθους επιλέγουν υβριδική λύση: τα βασικά οικονομικά μονομιάς, οι λειτουργίες σταδιακά.

Ποιες είναι οι συχνότερες αιτίες καθυστέρησης στα έργα SAP;

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

Τι συμβαίνει μετά το go-live του SAP;

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