Πρότυπα υλοποίησης SAP: οδηγός ανά φάση

Το SAP Activate προσφέρει ένα πρότυπο για σχεδόν κάθε παραδοτέο ενός προγράμματος S/4HANA. Θα τα βρείτε στο SAP Activate Roadmap Viewer και, στα προγράμματα cloud, μέσα στο SAP Cloud ALM. Το να τα βρείτε είναι εύκολο. Το δύσκολο είναι να ξέρετε ποια να τα πάρετε στα σοβαρά.

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

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

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

Φάση	Πρότυπο	Υπεύθυνος	Εγκρίνεται πριν από
Prepare	Έγγραφο αντικειμένου έργου	Διευθυντής προγράμματος (εγκρίνει ο χορηγός)	Την έναρξη του Explore
Prepare	Επιχειρηματική αιτιολόγηση	CFO ή ιδιοκτήτης της επιχείρησης	Την αποδέσμευση της χρηματοδότησης
Prepare	Πίνακας ενδιαφερομένων	Διευθυντής προγράμματος	Την κράτηση των εργαστηρίων Explore
Explore	Φύλλο απαιτήσεων και fit-gap	Αρχιτέκτονας λύσης με τους ιδιοκτήτες διαδικασιών	Την έναρξη του Realize
Realize	Αρχείο παραμετροποίησης	Επικεφαλής λειτουργικοί σύμβουλοι	Τη μεταφορά κάθε transport στο QA
Realize	Μητρώο προσαρμοσμένης ανάπτυξης	Επικεφαλής ανάπτυξης	Την έναρξη της κατασκευής σε οποιοδήποτε αντικείμενο
Realize	Στρατηγική δοκιμών	Διευθυντής δοκιμών	Την έναρξη των δοκιμών ολοκλήρωσης συστήματος
Realize	Σχέδιο μετάβασης δεδομένων	Επικεφαλής μετάβασης δεδομένων	Την πρώτη δοκιμαστική φόρτωση
Deploy	Σχέδιο cutover	Διευθυντής cutover	Την τελική γενική πρόβα
Deploy	Αξιολόγηση ετοιμότητας go-live	Διευθυντής προγράμματος (υπογράφει ο χορηγός)	Τη σύσκεψη go/no-go
Run	Μοντέλο υποστήριξης hypercare	Επικεφαλής παροχής υπηρεσιών	Το go-live
Run	Φύλλο παρακολούθησης απόδοσης	Επικεφαλής Basis	Το go-live

Το Activate έχει έξι φάσεις: Discover, Prepare, Explore, Realize, Deploy και Run. Συνδυάζει περιεχόμενο SAP Best Practices, καθοδηγούμενη παραμετροποίηση και μια ευέλικτη προσέγγιση υλοποίησης. Για τους περισσότερους πελάτες το Discover γίνεται πριν υπογραφεί το συμβόλαιο, γι' αυτό τα πρότυπα παρακάτω ξεκινούν από το Prepare.

1. 01DiscoverΣυνήθως πριν υπογραφεί το συμβόλαιο
2. 02PrepareΈγγραφο αντικειμένου, επιχειρηματική αιτιολόγηση, πίνακας ενδιαφερομένων
3. 03ExploreΦύλλο απαιτήσεων και fit-gap
4. 04RealizeΑρχείο παραμετροποίησης, μητρώο ανάπτυξης, στρατηγική δοκιμών, σχέδιο μετάβασης δεδομένων
5. 05DeployΣχέδιο cutover, ετοιμότητα go-live
6. 06RunΜοντέλο hypercare, παρακολούθηση απόδοσης

Κάθε πρότυπο υπογεγραμμένο πριν από την πύλη του

Η ακολουθία των φάσεων δεν είναι προαιρετική. Δούλεψα με έναν λιανέμπορο που προσπάθησε να παραλείψει τμήματά της και κατέληξε να ξανακάνει τρεις μήνες δουλειάς. Κάθε quality gate υπάρχει για έναν λόγο.

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

Τι άλλαξε στα εργαλεία για το 2026

Η δομή του Activate είναι η ίδια όπως ήταν. Τα εργαλεία γύρω της έχουν μετακινηθεί.

1. Το SAP Cloud ALM φιλοξενεί τα πρότυπα στα προγράμματα cloud. Είναι ο διάδοχος του Solution Manager από τη SAP και περιλαμβάνεται στο SAP Enterprise Support και σε συνδρομές cloud όπως το RISE with SAP. Το αντικείμενο, οι απαιτήσεις, τα σχέδια δοκιμών και οι εργασίες cutover μπορούν να βρίσκονται εκεί με ιχνηλασιμότητα μεταξύ τους. Το Solution Manager 7.2 βγαίνει από την κύρια συντήρηση στο τέλος του 2027, με εκτεταμένη συντήρηση έως το 2030 για ορισμένες λειτουργίες, οπότε τα υπάρχοντα on-premise τοπία έχουν μερικά χρόνια και όχι μια δεκαετία.
2. Το Joule βρίσκεται πλέον μέσα στα εργαλεία της μεθοδολογίας. Η SAP έκανε το Joule διαθέσιμο στο Activate Roadmap Viewer το 2025 και στο SAP Cloud ALM, ώστε μια ομάδα να ζητά καθοδήγηση για εργασίες ή να συντάσσει περιεχόμενο από τον οδικό χάρτη. Επιταχύνει το πρώτο προσχέδιο. Δεν αντικαθιστά εκείνον που υπογράφει το fit-gap.
3. Το Clean Core είναι πλέον κανόνας σχεδιασμού, με επίπεδα. Τον Αύγουστο του 2025 η SAP αντικατέστησε το τριεπίπεδο μοντέλο επεκτασιμότητας με τέσσερα επίπεδα clean core, από A έως D. Το επίπεδο A χρησιμοποιεί μόνο released API, είτε στο SAP BTP είτε μέσα στο σύστημα με ABAP Cloud. Το επίπεδο D δεν είναι καθόλου καθαρό. Το πρότυπο fit-gap χρειάζεται μια στήλη για το πού θα καταλήξει κάθε κενό.
4. Το public edition στενεύει το fit-gap. Η SAP προωθεί πλέον το S/4HANA Cloud Public Edition ως SAP Cloud ERP, που πωλείται σε μεσαίες εταιρείες ως SAP GROW. Ισχύουν οι ίδιες έξι φάσεις με ελαφρύτερα τεκμήρια και επιτρέπονται μόνο επεκτάσεις με released API, οπότε η στήλη «gap» έχει λιγότερες πιθανές απαντήσεις.

Τα έργα που παραλείπουν αυτή τη βάση το πληρώνουν στο Explore και στο Realize.

Πρότυπο αντικειμένου έργου

Ορίζει τι περιλαμβάνει το έργο και τι όχι. Όταν κάποιος προσπαθήσει να προσθέσει αντικείμενο τρεις μήνες μετά (και θα προσπαθήσει), αυτό το έγγραφο είναι το σημείο αναφοράς. Ο χάρτης έργου SAP (project charter) βρίσκεται πάνω από αυτό και φέρει τη λεπτομέρεια της διακυβέρνησης.

Ενότητα	Λεπτομέρειες
Τίτλος, χορηγός, PM	Υλοποίηση SAP S/4HANA Finance, CFO, ονομαστικά οριζόμενος senior PM
Υπόβαθρο	Η τρέχουσα κατάσταση και ο λόγος της αλλαγής
Στόχοι	Μείωση του κύκλου κλεισίματος από 14 ημέρες σε 5, κατάργηση χειροκίνητων συμφωνιών
Εντός αντικειμένου	FI/CO, ενσωμάτωση MM/SD, μετάβαση δεδομένων, UAT, go-live
Εκτός αντικειμένου	Ενότητες HR, μετάβαση παλιών αναφορών, ενσωματώσεις τρίτων πέρα από το ERP
Παραδοχές	Ο εκτελεστικός χορηγός είναι διαθέσιμος για μηνιαία SteerCo, τα δεδομένα δοκιμών συμφωνούνται έως την Εβδομάδα 6
Περιορισμοί	Σταθερή ημερομηνία go-live, μόνο εσωτερικοί πόροι για την παραμετροποίηση
Παραδοτέα	Παραμετροποιημένο σύστημα, σχέδια δοκιμών, σχέδιο cutover, εκπαιδευτικό υλικό
Χρονοδιάγραμμα	Prepare: Εβδομάδες 1-4, Explore: Εβδομάδες 5-10, Realize: Εβδομάδες 11-26
Έγκριση	Απαιτείται υπογραφή του χορηγού του έργου και του PMO πριν ξεκινήσει το Explore

Πρότυπο επιχειρηματικής αιτιολόγησης

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

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

Ενότητα	Λεπτομέρειες
Υπεύθυνος και σύνοψη	CFO ή διευθυντής προγράμματος, γιατί τώρα, τι αλλάζει, τι μένει ίδιο
Δήλωση προβλήματος	Συγκεκριμένα επιχειρησιακά προβλήματα (διάρκεια κύκλου κλεισίματος, χειροκίνητες παρακάμψεις, ηλικία συστήματος)
Προτεινόμενη προσέγγιση	Greenfield / brownfield / επιλεκτική, με σύνοψη αντικειμένου
Οφέλη	Ποσοτικοποιημένα: ημέρες λιγότερες στον κύκλο κλεισίματος, εξοικονόμηση FTE, μείωση ποσοστού σφαλμάτων, μείωση ελεγκτικού κινδύνου
Κόστος και χρηματοδότηση	Υλοποίηση, άδεια ή συνδρομή, χρόνος εσωτερικών πόρων, απρόβλεπτα, πηγή προϋπολογισμού
Κίνδυνοι	Οι τρεις κορυφαίοι, με πιθανότητα και επίπτωση
Σύσταση	Προχωρήστε / προχωρήστε υπό όρους / αναβολή, με αιτιολόγηση

Πίνακας ταυτοποίησης ενδιαφερομένων

Χαρτογραφεί όλους όσους επηρεάζονται από την υλοποίηση και το επίπεδο επιρροής τους. Σας δείχνει με μια ματιά ποιος χρειάζεται εβδομαδιαίες ενημερώσεις και ποιος χρειάζεται απλώς μια προειδοποίηση πριν από το go-live.

Ενδιαφερόμενος	Ρόλος	Ενδιαφέρον	Επιρροή	Εμπλοκή
Group CFO	Εκτελεστικός χορηγός	ROI προγράμματος, βελτίωση κλεισίματος οικονομικών	Υψηλή	Μηνιαία SteerCo, εβδομαδιαία γραπτή ενημέρωση
Διευθυντής IT	Τεχνικός υπεύθυνος	Σταθερότητα συστήματος, ενσωμάτωση, ασφάλεια	Υψηλή	Εβδομαδιαίο συμβούλιο προγράμματος, καθημερινά κατά το Realize
Οικονομικός διευθυντής	Βασικός ιδιοκτήτης διαδικασιών	Σχεδιασμός FI/CO, διαδικασία κλεισίματος	Υψηλή	Εργαστήρια στο Explore, υπογραφή UAT
Διευθυντές εργοστασίων	Επηρεαζόμενοι χρήστες	Αλλαγές διαδικασιών MM/PP	Μεσαία	Μηνιαία επικοινωνία αλλαγής, συμμετοχή στο UAT
Τελικοί χρήστες (AP/AR)	Χειριστές	Αλλαγές σε επίπεδο συναλλαγής	Χαμηλή	Εκπαίδευση, υποστήριξη hypercare
Εσωτερικός έλεγχος	Διακυβέρνηση	Ιχνηλασιμότητα, έλεγχοι, συμμόρφωση	Μεσαία	Ανασκοπήσεις τεκμηρίων στα quality gates

Χρησιμοποιήστε τον ίδιο πίνακα για να σχεδιάσετε τα εργαστήρια του Prepare που καταγράφουν τις απαιτήσεις υψηλού επιπέδου ανά τμήμα. Αριθμήστε αυτές τις απαιτήσεις στη μορφή που θα χρησιμοποιήσετε στο Explore (REQ-001 και ούτω καθεξής), ώστε τίποτα να μην αριθμηθεί ξανά αργότερα και να διατηρηθεί η ιχνηλασιμότητα προς το αρχικό αίτημα.

Το Explore είναι εκεί όπου παίρνει μορφή η υλοποίηση. Αυτά τα πρότυπα αποκαλύπτουν το χάσμα ανάμεσα σε ό,τι κάνει η SAP εκτός κουτιού και σε ό,τι χρειάζεται η επιχείρηση.

Πρότυπο χαρτογράφησης απαιτήσεων και fit-gap

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

Η ανάλυση fit-gap δείχνει στη συνέχεια πού η τυπική SAP καλύπτει κάθε ανάγκη και πού όχι. Είναι πραγματικό άνοιγμα ματιών για τους περισσότερους πελάτες μου. Μου αρέσει να παρακολουθώ τη στιγμή που μια ομάδα συνειδητοποιεί ότι μπορεί να χρησιμοποιήσει την τυπική λειτουργικότητα αντί για ακριβό προσαρμοσμένο κώδικα.

Κρατώ και τα δύο σε ένα φύλλο, με μια στήλη για τη διαδρομή επίλυσης. Στο S/4HANA κάθε κενό χρειάζεται ρητή απάντηση: τυπική παραμετροποίηση, επέκταση key user, επέκταση προγραμματιστή μέσα στο σύστημα ή επέκταση side-by-side στο SAP BTP. Οι κλασικές τροποποιήσεις στον κώδικα της SAP είναι η πιο ακριβή απάντηση και πρέπει να απαιτούν ονομαστικά οριζόμενο εγκρίνοντα.

Req ID	Απαίτηση	Στοιχείο SAP	Fit / Gap	Διαδρομή επίλυσης	Αναφορά δοκιμής
REQ-001	Αυτοματοποιημένες εγγραφές κλεισίματος μήνα	FI-GL, κλείσιμο περιόδου	Fit	Παραμετροποίηση προτύπων επαναλαμβανόμενων εγγράφων	TC-001
REQ-002	Έγκριση παραγγελίας αγοράς μέσω Fiori	MM προμήθειες, εφαρμογή έγκρισης Fiori	Gap (δεν υπάρχει στο ECC)	Τυπική εφαρμογή S/4HANA και παραμετροποίηση ροής εργασίας	TC-003
REQ-003	Αυτοματοποίηση ενδοεταιρικής τιμολόγησης	SD τιμολόγηση, ενσωμάτωση FI	Gap	Παραμετροποίηση ενδοεταιρικής τιμολόγησης	TC-010
REQ-004	Παρακολούθηση batch jobs	Εφαρμογή Application Jobs	Fit	Τυπική εφαρμογή	TC-015
REQ-005	Πύλη αυτοεξυπηρέτησης προμηθευτών	SAP Ariba ή πύλη προμηθευτών	Gap	Ενσωμάτωση Ariba	TC-020
REQ-006	Αρχειοθέτηση δεδομένων σύμφωνη με GDPR	ILM, αρχειοθέτηση δεδομένων	Gap	Παραμετροποίηση πολιτικής ILM	TC-025
REQ-007	Αναφορά κέντρων κόστους σε πραγματικό χρόνο	CO, ενσωματωμένη αναλυτική ή SAC	Gap	Ενσωματωμένη αναλυτική ή ζωντανή σύνδεση SAC	TC-030
REQ-008	Υποστήριξη 500 ταυτόχρονων χρηστών	Διαστασιολόγηση HANA	Gap (δοκιμάστηκαν 300)	Έλεγχος διαστασιολόγησης και αναβάθμιση υποδομής	TC-035

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

Πρότυπο παρακολούθησης παραμετροποίησης

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

1. Αναγνωριστικό παραμετροποίησης και ενότητα: [π.χ. MM-CONF-001, MM]
2. Διαδρομή IMG και αντικείμενο παραμετροποίησης: [π.χ. Πίνακας T161, τύποι εγγράφων PO]
3. Σκοπός και επηρεαζόμενη επιχειρηματική διαδικασία
4. Ποιος την έκανε και πότε
5. Αριθμός αιτήματος transport: [π.χ. DEVK900123]
6. Βασικές τιμές: πριν και μετά
7. Συνδεδεμένες περιπτώσεις δοκιμής
8. Κατάσταση επικύρωσης και έγκρισης

Μητρώο προσαρμοσμένης ανάπτυξης

Κάθε προσαρμοσμένο αντικείμενο παίρνει μια γραμμή πριν γράψει κανείς κώδικα. Ένας πελάτης μου μείωσε τον προσαρμοσμένο κώδικά του κατά 30%, επειδή το μητρώο έδειξε πού η τυπική SAP θα δούλευε μια χαρά.

Dev ID	Αντικείμενο	Περιγραφή	Προγραμματιστής	Προσπάθεια (ώρες)	Κατάσταση	Τύπος επέκτασης
CD-001	Πλακίδιο Fiori: επισκόπηση κέντρου κόστους	Πλακίδιο αναφοράς CO σε πραγματικό χρόνο για τα οικονομικά	Προγραμματιστής Fiori	12	Ολοκληρώθηκε	Επέκταση προγραμματιστή
CD-002	Αναφορά ενδοεταιρικής τιμολόγησης	Αναφορά για συμφωνία IC	Προγραμματιστής ABAP	20	Σε εξέλιξη	Επέκταση προγραμματιστή
CD-004	Εφαρμογή κατάστασης πληρωμής προμηθευτών	Εφαρμογή Fiori για ερωτήματα πληρωμών AP	Προγραμματιστής BTP	10	Αναμονή QA	Side-by-side στο BTP
CD-005	Ειδοποίηση παραλαβής εμπορευμάτων	Εκκίνηση email με την καταχώριση παραλαβής εμπορευμάτων	Προγραμματιστής ενσωματώσεων	24	Προγραμματισμένο	Βασισμένο σε συμβάντα, στο BTP

Πρότυπο στρατηγικής δοκιμών

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

Ενότητα	Λεπτομέρειες
Αντικείμενο	Λειτουργικές, ενσωμάτωσης, παλινδρόμησης, απόδοσης, UAT σε όλες τις ενότητες εντός αντικειμένου (οι δοκιμές διείσδυσης ανήκουν στο InfoSec)
Περιβάλλοντα	DEV, QA, UAT (προπαραγωγικό), staging για την τελική επικύρωση
Εργαλεία	Διαχείριση δοκιμών στο SAP Cloud ALM ή Jira/Xray, αυτοματοποίηση με Tricentis Tosca ή παρόμοιο, απόδοση με JMeter ή LoadRunner
Κύκλος ζωής ελαττωμάτων	Νέο, Σε εξέλιξη, Επιλύθηκε, Επαληθεύτηκε, Κλειστό, με βαρύτητα και προτεραιότητα που ορίζονται στο triage
Κριτήρια εξόδου	Όλα τα κρίσιμα ελαττώματα κλειστά, ληφθείσα υπογραφή UAT, ποσοστό επιτυχίας παλινδρόμησης τουλάχιστον 95%, επίτευξη των στόχων απόδοσης

Πρότυπο σχεδιασμού μετάβασης δεδομένων

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

Ενότητα	Λεπτομέρειες
Αντικείμενο	Κύρια δεδομένα πελατών, κύρια δεδομένα προμηθευτών, ανοιχτές εγγραφές, κύρια δεδομένα υλικών, υπόλοιπα αποθεμάτων, ιεραρχίες κέντρων κόστους
Συστήματα προέλευσης	ECC 6.0 EHP 7 (κύριο), παλιό σύστημα HR (αντιστοιχίσεις εργαζομένων σε κέντρα κόστους)
Σύστημα προορισμού	S/4HANA (τρέχουσα έκδοση)
Αντιστοίχιση και κανόνες	Πελάτες και προμηθευτές σε Business Partner, κέντρα κόστους στη νέα ιεραρχία, αφαίρεση άκυρων τραπεζικών στοιχείων, συγχώνευση διπλοεγγραφών
Εργαλεία μετάβασης	SAP S/4HANA Migration Cockpit (κύριο), Migration Object Modeler για προσαρμοσμένα αντικείμενα, scripts για προεπεξεργασία
Στρατηγική φόρτωσης	Δοκιμαστική φόρτωση στο QA, delta μετάβαση και συμφωνία, cutover στην παραγωγή
Προσέγγιση επικύρωσης	Πλήθος εγγραφών από την πηγή στον προορισμό, τυχαία δειγματοληψία 10%, αναφορές συμφωνίας υπολοίπων
Σχέδιο επαναφοράς	Αντίγραφο ασφαλείας πριν από το cutover, παλιό σύστημα σε αναμονή για 48 ώρες

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

Πρότυπο σχεδιασμού cutover

Χαρτογραφεί το παράθυρο διακοπής ώρα με την ώρα. Κάθε εργασία, κάθε υπεύθυνος, κάθε ώρα έναρξης. Η ομάδα σας δεν πρέπει ποτέ να στέκεται αδρανής στις 2 τα ξημερώματα αναρωτώμενη τι να κάνει στη συνέχεια.

Συμφωνήστε σε τέσσερα πράγματα πριν γράψετε τη λίστα εργασιών: το παράθυρο (για παράδειγμα Παρασκευή 22:00 έως Σάββατο 06:00), την ένδειξη που προκαλεί επαναφορά, πόσο γρήγορα μπορεί να ενεργοποιηθεί ξανά το παλιό σύστημα και τα smoke tests που αποδεικνύουν ότι το νέο σύστημα δουλεύει. Έπειτα η ακολουθία εργασιών:

Βήμα	Περιγραφή	Υπεύθυνος	Ώρα έναρξης	Κατάσταση
1	Πάγωμα του συστήματος ECC (χωρίς καταχωρίσεις)	Basis	22:00	Σε αναμονή
2	Τελική εξαγωγή δεδομένων και συμφωνία	Επικεφαλής μετάβασης δεδομένων	22:30	Σε αναμονή
3	Εκτέλεση παραγωγικής φόρτωσης μετάβασης	DBA	23:00	Σε αναμονή
4	Εισαγωγή των υπόλοιπων transport στην παραγωγή	Basis	00:30	Σε αναμονή
5	Εναλλαγή DNS και load balancer στο S/4HANA	Δίκτυο	01:30	Σε αναμονή
6	Smoke test: καταχώριση FI, παραλαβή εμπορευμάτων, παραγγελία πώλησης	Επικεφαλής QA	02:00	Σε αναμονή
7	Επιχειρηματική επιβεβαίωση και απόφαση go/no-go	Διευθυντής προγράμματος	03:00	Σε αναμονή
8	Άνοιγμα του συστήματος στους χρήστες της επιχείρησης	Basis	06:00	Σε αναμονή

Αξιολόγηση ετοιμότητας go-live

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

Τομέας	Έλεγχοι (ο καθένας απαντιέται με ναι ή όχι, με τεκμήρια)
Λειτουργικός	Δοκιμασμένες βασικές διαδικασίες, ολοκληρωμένα σενάρια μεταξύ ενοτήτων, καταγεγραμμένα ανοιχτά ελαττώματα P1/P2, επιβεβαίωση ετοιμότητας από τους key users
Δεδομένα	Ολοκληρωμένες φορτώσεις κύριων δεδομένων, επικυρωμένα δεδομένα συναλλαγών, εγκεκριμένες αναφορές συμφωνίας, επιβεβαιωμένο πάγωμα του παλιού συστήματος
Τεχνικός	Εγκεκριμένο σχέδιο cutover, transport στην παραγωγή, προγραμματισμένα batch jobs, ρυθμισμένη παρακολούθηση
Άνθρωποι	Ποσοστό κάλυψης εκπαίδευσης, επικυρωμένοι ρόλοι πρόσβασης, στελεχωμένη ομάδα hypercare, κοινοποιημένο σχέδιο υποστήριξης
Απόφαση	Καταγεγραμμένοι κρίσιμοι κίνδυνοι και μέτρα μετριασμού, Go / No-go / Υπό όρους, έγκριση με όνομα, ρόλο και ημερομηνία

Μετά το go-live, η δουλειά αλλάζει σχήμα. Αυτά τα πρότυπα συνοδεύουν το σύστημα και την ομάδα μέσα από το hypercare και στη σταθερή λειτουργία.

Πρότυπο υποστήριξης μετά την υλοποίηση

Οργανώνει τον τρόπο που χειρίζεστε τα προβλήματα μετά την εκκίνηση. Χωρίς αυτό, κάθε πρόβλημα γίνεται P1.

Ενότητα	Λεπτομέρειες
Παράθυρο hypercare	Εβδομάδες 1-4 μετά το go-live: κάλυψη 24/7
Κανάλια υποστήριξης	Ουρά περιστατικών ServiceNow (κύρια), ειδικό κανάλι συνομιλίας, τηλεφωνική γέφυρα για προβλήματα P1
Επίπεδα υποστήριξης	1: service desk (κωδικοί πρόσβασης, πλοήγηση, γνωστά προβλήματα), 2: λειτουργικοί σύμβουλοι (ερωτήματα διαδικασιών, μικρή παραμετροποίηση), 3: Basis και ανάπτυξη (σφάλματα συστήματος, απόδοση, διεπαφές)
SLA (απόκριση / επίλυση)	Κρίσιμο 15 λεπτά / 2 ώρες, Υψηλό 30 λεπτά / 4 ώρες, Μεσαίο 4 ώρες / 1 ημέρα, Χαμηλό 1 ημέρα / 3 ημέρες
Παρακολούθηση	SAP Cloud ALM ή Solution Manager, καθημερινή ανασκόπηση καταγραφής σφαλμάτων
Κριτήρια εξόδου	Κανένα ανοιχτό πρόβλημα P1/P2, όλα τα περιστατικά τεκμηριωμένα, τελική υπογραφή παράδοσης

Πρότυπο παρακολούθησης απόδοσης

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

Μέτρο	Στόχος	Εργαλείο	Όριο ειδοποίησης	Υπεύθυνος
Χρόνος απόκρισης διαλόγου (95ο εκατοστημόριο)	Κάτω από 1 δευτερόλεπτο	ST03 / SAP Cloud ALM	2 δευτερόλεπτα	Ομάδα Basis
Ολοκλήρωση εργασιών παρασκηνίου	100% σύμφωνα με το πρόγραμμα	SM37 / Application Jobs	Οποιαδήποτε αποτυχημένη εργασία	Επικεφαλής λειτουργιών
Χρόνος ερωτήματος βάσης δεδομένων	Κάτω από 200ms	SAP HANA cockpit	500ms	DBA
Διαθεσιμότητα συστήματος	Πάνω από 99,5%	SAP Cloud ALM	Κάτω από 99%	Υποδομή
Ποσοστό σφαλμάτων διεπαφών	Κάτω από 1%	Παρακολούθηση SAP Integration Suite	2%	Επικεφαλής middleware
Ποσοστό επιτυχίας σύνδεσης	Πάνω από 98%	Αρχείο καταγραφής ελέγχου ασφάλειας	Κάτω από 95%	Επικεφαλής ασφάλειας
Χρόνος εκτέλεσης εργασιών κλεισίματος μήνα	Εντός του συμφωνημένου παραθύρου	Χρονοπρογραμματιστής εργασιών	Ξεπερνά τη βάση αναφοράς κατά πάνω από 30%	Οικονομικές λειτουργίες

Τα quality gates σταματούν ένα πρόβλημα μιας φάσης από το να γίνει ακριβή επανεργασία στην επόμενη. Ο οδηγός μου για τα quality gates SAP εξηγεί πώς να τα στήσετε. Εδώ είναι γιατί μετράνε.

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

Ορίστε κριτήρια επιτυχίας/αποτυχίας σε κάθε gate. «Το 95% των δοκιμών παλινδρόμησης πρέπει να περάσει». «Όλα τα σενάρια ενσωμάτωσης FI είναι πράσινα». Τέτοια κριτήρια σάς δίνουν μια υπερασπίσιμη βάση για να κρατήσετε τη γραμμή όταν η επιχείρηση θέλει να ξεκινήσει σε μια ημερομηνία ανεξάρτητα από την ποιότητα.

Σε ένα από τα έργα μου, το quality gate μας σταμάτησε όταν είχε περάσει μόλις το 75% των δοκιμών ενσωμάτωσης. Διορθώσαμε πρώτα τα προβλήματα αντί να βιαστούμε. Αυτό γλίτωσε τον πελάτη περίπου €100.000 σε έκτακτες διορθώσεις μετά την εκκίνηση.

Ένα gate που ο χορηγός μπορεί να το ακυρώσει με ένα τηλεφώνημα δεν είναι gate. Γράψτε ποιος μπορεί να το άρει πριν το χρειαστείτε.

Τι είναι η μεθοδολογία SAP Activate;

Το SAP Activate είναι η μεθοδολογία υλοποίησης της SAP για το S/4HANA και τα άλλα προϊόντα cloud. Τρέχει σε έξι φάσεις (Discover, Prepare, Explore, Realize, Deploy, Run) και συνδυάζει περιεχόμενο SAP Best Practices, καθοδηγούμενη παραμετροποίηση και ευέλικτη παράδοση.

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

Ποια φάση του SAP Activate έχει τα πιο σημαντικά πρότυπα;

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

Δεύτερο έρχεται το Explore. Τα κενά στα έγγραφα fit-gap και χαρτογράφησης απαιτήσεων αναδύονται ως ελαττώματα UAT μήνες αργότερα, όταν η διόρθωσή τους κοστίζει πολύ περισσότερο από όσο θα κόστιζε την τρίτη εβδομάδα του Explore.

Μπορείτε να προσαρμόσετε τα πρότυπα του SAP Activate;

Ναι. Κρατήστε περίπου το 80% της τυπικής δομής και αλλάξτε μόνο ό,τι είναι ειδικό για το δικό σας πλαίσιο: επικύρωση φαρμακευτικού κλάδου, κανόνες προμηθειών δημόσιου τομέα, έλεγχοι SOX. Προσθέστε τα στην αρχή του Prepare και όχι στο Deploy.

Μην προσαρμόζετε τη δομή των quality gates, την ακολουθία των φάσεων ή τα υποχρεωτικά τεκμήρια (έγγραφο αντικειμένου, επιχειρηματική αιτιολόγηση, αξιολόγηση ετοιμότητας go-live).

Δουλεύουν τα πρότυπα του SAP Activate τόσο για greenfield όσο και για brownfield;

Ναι. Η κύρια διαφορά βρίσκεται στο Explore. Μια μετατροπή brownfield μεταφέρει την υπάρχουσα παραμετροποίηση, οπότε το fit-gap εστιάζει στο τι πρέπει να αλλάξει, ποιον προσαρμοσμένο κώδικα μπορεί πλέον να αντικαταστήσει το τυπικό S/4HANA και ποιος καθαρισμός δεδομένων χρειάζεται πριν από τη μετατροπή. Ένα πρόγραμμα greenfield ξεκινά από τα SAP Best Practices και επιβεβαιώνει ποιες τυπικές διαδικασίες ταιριάζουν.

Το σχέδιο cutover διαφέρει επίσης. Μια μετατροπή συστήματος brownfield ακολουθεί διαφορετική ακολουθία από ένα go-live greenfield με πλήρη μετάβαση δεδομένων.

Πόσο λεπτομερές πρέπει να είναι ένα σχέδιο cutover;

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

Συμφωνήστε τα κριτήρια επαναφοράς πριν ξεκινήσει το cutover: ποιες συνθήκες προκαλούν επιστροφή στο παλιό σύστημα, ποιος παίρνει αυτή την απόφαση και έως ποια ώρα. Οι αποφάσεις επαναφοράς που παίρνονται στις 4 τα ξημερώματα χωρίς προσυμφωνημένα κριτήρια είναι από εκεί όπου ξεκινούν οι καταστροφές μετά το go-live.