Σχεδιασμός κατανομής πόρων για έργα SAP

Ο σχεδιασμός κατανομής πόρων για ένα έργο SAP σημαίνει να αποφασίσετε ποιους ρόλους χρειάζεστε, σε ποια φάση του SAP Activate, για πόσες ώρες την εβδομάδα, και μετά να ελέγχετε κάθε εβδομάδα αν η πραγματικότητα εξακολουθεί να ταιριάζει. Στελεχώστε ανά ρόλο και όχι με γενικό αριθμό ατόμων. Προσαρμόστε το σχέδιο στην καμπύλη των φάσεων: λειτουργικά στελέχη στο Explore, τεχνικά στο Realize, δεδομένα, Basis και αλλαγή στο Deploy. Επιβεβαιώστε τη διαθεσιμότητα γραπτώς με τους άμεσους προϊσταμένους. Ο οδηγός αυτός απευθύνεται σε διευθυντές προγραμμάτων, PMO και CIO που χτίζουν ή διασώζουν ένα σχέδιο πόρων S/4HANA. Χρησιμοποιήστε τους πίνακες FTE και τα εύρη ημερήσιων χρεώσεων παρακάτω ως αφετηρία.

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

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

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

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

1. Αριθμός ατόμων ανά ρόλο και ανά φάση του Activate. Όχι ενιαία κατανομή. Το Explore δεν μοιάζει καθόλου με το Realize.
2. Ώρες την εβδομάδα που επιβεβαιώνει ο άμεσος προϊστάμενος. Γραπτώς, όχι εικαζόμενες.
3. Ταυτόχρονες δεσμεύσεις ανά άτομο. Κάποιος που εμφανίζεται στο 100% και καλύπτει επιπλέον την υποστήριξη παραγωγής θα αποδώσει πολύ λιγότερα.
4. Αναπλήρωση για κάθε ρόλο της κρίσιμης διαδρομής. Η διασταυρούμενη εκπαίδευση δεν είναι προαιρετική σε ένα πρόγραμμα 18 μηνών.
5. Εξαρτήσεις ανάμεσα στις ροές εργασίας. Καθεμία με ονομαστό υπεύθυνο, ημερομηνία και διαδρομή κλιμάκωσης, ορατή από τη μέρα που ολισθαίνει.
6. Ρυθμός ενημέρωσης. Εβδομαδιαίος στις ενεργές φάσεις. Το σχέδιο της εκκίνησης είναι η έκδοση ένα.

Τα σχέδια πάνε στραβά όταν ο σχεδιαστής χρησιμοποιεί γενικούς ρόλους IT. Το SAP χρειάζεται συγκεκριμένη λειτουργική και τεχνική εξειδίκευση. Το τυπικό σύνολο για ένα πρόγραμμα S/4HANA:

Ηγεσία προγράμματος. Διευθυντής προγράμματος, επικεφαλής PMO και αρχιτέκτονας λύσης. Ο αρχιτέκτονας είναι υπεύθυνος για τη συνοχή του σχεδιασμού ανάμεσα στα modules.

Λειτουργικοί σύμβουλοι. Ένας επικεφαλής ανά module εντός εύρους: Χρηματοοικονομική Λογιστική (FI), Controlling (CO), Διαχείριση Υλικών (MM), Πωλήσεις και Διανομή (SD), Προγραμματισμός Παραγωγής (PP), Extended Warehouse Management (EWM), καθώς και Διαχείριση Ανθρώπινου Δυναμικού (HCM), Συντήρηση Εγκαταστάσεων (PM) και Project System (PS) όπου εμπίπτουν στο εύρος. Αν εξακολουθείτε να τρέχετε το κλασικό Warehouse Management (WM), σχεδιάστε τη μετάβαση: τα δικαιώματα χρήσης του μέσω του compatibility pack στο S/4HANA on-premise έληξαν στο τέλος του 2025.

Τεχνικοί σύμβουλοι. Προγραμματιστές ABAP για αναφορές, διεπαφές, μετατροπές, βελτιώσεις, φόρμες και ροές εργασιών (RICEFW), και για επεκτάσεις clean-core σε released APIs ή στο SAP BTP. Ειδικοί ενσωμάτωσης για το SAP Integration Suite (Cloud Integration, παλαιότερα CPI), το SAP Process Orchestration όπου εξακολουθεί να λειτουργεί, και κάθε middleware τρίτων.

Πλατφόρμα. Σύμβουλοι Basis για HANA, kernel patches, transports, αντιγραφές συστημάτων και συντονισμό απόδοσης. Σύμβουλοι ασφάλειας για σχεδιασμό ρόλων, ανάλυση διαχωρισμού καθηκόντων και SAP GRC Access Control όπου εμπίπτει στο εύρος.

Δεδομένα. Ειδικοί μετάπτωσης που χρησιμοποιούν την εφαρμογή «Migrate Your Data» του SAP S/4HANA Migration Cockpit (η παλαιότερη συναλλαγή LTMC είναι deprecated), το Migration Object Modeler για προσαρμοσμένα αντικείμενα και το SAP Data Services για σύνθετους μετασχηματισμούς. Ο οδηγός μου για το γιατί αποτυγχάνει η μετάπτωση δεδομένων SAP εξηγεί γιατί αυτή η ομάδα πρέπει να ξεκινά νωρίτερα από ό,τι επιτρέπουν τα περισσότερα σχέδια.

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

Πλευρά πελάτη. Επιχειρησιακοί αναλυτές (ένας ανά κύριο module), ιδιοκτήτες διαδικασιών (ένας ανά πεδίο διαδικασιών) και δοκιμαστές από τις λειτουργίες για το UAT.

Το να αντιμετωπίζετε αυτούς τους ρόλους ως εναλλάξιμες θέσεις είναι το συχνότερο λάθος σχεδιασμού. Ένας ανώτερος σύμβουλος FI δεν μπορεί να διευθύνει workshop σχεδιασμού SD. Ένας junior προγραμματιστής ABAP δεν μπορεί να σχεδιάσει μια ενσωμάτωση. Για τις αρμοδιότητες ανά ρόλο, δείτε τη λίστα μου με τους βασικούς ρόλους της ομάδας υλοποίησης SAP.

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

Prepare (συνήθως εβδομάδες 1 έως 4). Ελαφριά. Διευθυντής προγράμματος, αρχιτέκτονας και ένας επικεφαλής ανά module για τον καθορισμό του εύρους. Οι επιχειρησιακοί χρήστες επιβεβαιώνουν το εύρος. Οι ομάδες Basis και ασφάλειας ξεκινούν τη ρύθμιση των περιβαλλόντων.

Explore (συνήθως μήνες 2 έως 5). Βαριά σε λειτουργικούς συμβούλους και επιχειρησιακούς χρήστες, με τα workshops σχεδιασμού να καθορίζουν το χρονοδιάγραμμα. Το ABAP και η ενσωμάτωση είναι ελαφριά μέχρι να παρθούν οι αποφάσεις σχεδιασμού. Το Basis προετοιμάζει τα συστήματα sandbox και ποιότητας.

Realize (συνήθως μήνες 5 έως 12). Βαριά σε τεχνικούς: παραμετροποίηση, ανάπτυξη, δοκιμές μονάδας και ενσωμάτωσης. Το φορτίο ABAP κορυφώνεται. Οι επιχειρησιακοί χρήστες μπαίνουν στους κύκλους δοκιμών. Η ομάδα δεδομένων χτίζει αντικείμενα μετάπτωσης και τρέχει δοκιμαστικές εκτελέσεις (dry runs).

Deploy (συνήθως μήνες 12 έως 14). Βαριά σε μετάπτωση δεδομένων, Basis, ασφάλεια, αλλαγή και εκπαίδευση. Το UAT καταναλώνει επιχειρησιακή δυναμικότητα. Οι πρόβες cutover απαιτούν ομάδες στον ίδιο χώρο. Ξεκινά ο σχεδιασμός του hypercare.

Run (από τον μήνα 14· το hypercare συνήθως 30 έως 90 ημέρες). Ελαφριά βασική ομάδα και βαριά κάλυψη υποστήριξης. Το Basis και η διαχείριση εφαρμογών αυξάνονται, ενώ οι σύμβουλοι μειώνονται.

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

1. PrepareΠερίπου 11 FTEΕβδομάδες 1 έως 4. Οι επικεφαλής ορίζουν το εύρος, το Basis στήνει τα περιβάλλοντα
2. ExploreΠερίπου 36 FTEΜήνες 2 έως 5. Λειτουργικοί σύμβουλοι και επιχειρησιακοί χρήστες
3. RealizeΠερίπου 56 FTE, η κορύφωσηΜήνες 5 έως 12. Ανάπτυξη, με κορύφωση του φορτίου ABAP
4. DeployΠερίπου 42 FTEΜήνες 12 έως 14. Δεδομένα, Basis, ασφάλεια, αλλαγή
5. RunΠερίπου 12 FTEΑπό τον μήνα 14. Το hypercare συνήθως 30 έως 90 ημέρες

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

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

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

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

1. Εικονική διαθεσιμότητα. Κάποιος που εμφανίζεται στο 100% τρέχει επίσης το κλείσιμο μήνα και την υποστήριξη παραγωγής. Ρωτήστε πόσες ώρες την εβδομάδα, τι άλλο δουλεύει και αν ο άμεσος προϊστάμενός του το έχει επιβεβαιώσει γραπτώς.
2. Κοινόχρηστοι ρόλοι χωρίς όρια. Ένα άτομο κάνει ταυτόχρονα σχεδιασμό λύσης, δοκιμές και διαχείριση αλλαγής. Χωρίστε τις αρμοδιότητες ανά εργασία και όχι ανά τίτλο και μην κάνετε ποτέ ένα άτομο κρίσιμο σε δύο σημεία ταυτόχρονα.
3. Απουσία χρόνου των επιχειρησιακών χρηστών. Τα workshops καθυστερούν και οι εγκρίσεις του UAT παίρνουν εβδομάδες περισσότερο. Δεσμεύστε τον χρόνο γραπτώς, με υπογραφή του επικεφαλής του τμήματος, παρακολουθήστε τη συμμετοχή και κλιμακώστε νωρίς τα μοτίβα.
4. Καθόλου απόθεμα. Μία απουσία κολλάει μια ροή εργασίας. Χτίστε περιθώριο σε επίπεδο εργασίας και όχι μόνο σε επίπεδο φάσης και εκπαιδεύστε διασταυρούμενα τουλάχιστον ένα άτομο σε κάθε βασικό ρόλο.
5. Σχέδιο που δεν ενημερώνεται ποτέ. Χτίζεται στην εκκίνηση και δεν αναθεωρείται. Αναθεωρήστε το εβδομαδιαία στην ενεργή υλοποίηση, συνδέστε το με τις πύλες φάσεων και ενημερώστε το όταν αλλάζει η πραγματικότητα.

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

Διαμορφώστε το ανά φάση. Το φορτίο ενός προγραμματιστή ABAP στο Explore διαφέρει από το Realize. Οι επιχειρησιακοί χρήστες κορυφώνονται στο Explore για τον σχεδιασμό και στο Deploy για το UAT. Η ενιαία κατανομή φαίνεται ισορροπημένη στα χαρτιά και αποτυγχάνει στην πράξη.

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

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

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

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

Brownfield μεσαίας αγοράς (5 έως 15 εκατ. $, περίπου 12 μήνες)

Τυπικό εύρος: μία νομική οντότητα ή μικρός όμιλος, τρία ή τέσσερα modules (συνήθως FI, CO, MM, SD), τυπικές διαδικασίες και περιορισμένη ειδική ανάπτυξη.

Ροή εργασίας	Prepare	Explore	Realize	Deploy	Run
Διευθυντής προγράμματος	1	1	1	1	0,5
Αρχιτέκτονας λύσης	1	1	1	0,5	0
Λειτουργικοί σύμβουλοι (FI/CO, MM, SD και ένας ακόμη)	1	4	4	2	1
ABAP και τεχνικοί	0	1	3	1	0,5
Ενσωμάτωση	0	0,5	2	1	0,5
Basis	0,5	0,5	1	2	1
Ασφάλεια και εξουσιοδοτήσεις	0	0,5	1	1,5	0,5
Μετάπτωση δεδομένων	0	1	2	3	0
Επικεφαλής δοκιμών	0	0,5	1	1	0
Αλλαγή και εκπαίδευση	0,5	1	1	2	0,5
Επιχειρησιακοί αναλυτές πελάτη	1	4	3	2	1
Μέγιστο συνολικό FTE	5	14	20	17	5

Brownfield επιχείρησης (30 έως 80 εκατ. $, 15 έως 18 μήνες)

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

Ροή εργασίας	Prepare	Explore	Realize	Deploy	Run
Διευθυντής προγράμματος και PMO	2	2	3	3	1
Αρχιτέκτονες λύσης (επικεφαλής και ανά module)	2	3	3	1,5	0,5
Λειτουργικοί σύμβουλοι (όλα τα modules εντός εύρους)	2	10	12	5	2
ABAP και τεχνικοί	0	3	8	3	1
Ενσωμάτωση και middleware	0,5	2	5	2	1
Fiori και UI5	0	1	3	1	0,5
Basis	1	1	2	4	2
Ασφάλεια και GRC	0,5	1,5	2	3	1
Μετάπτωση δεδομένων	0	2	5	6	0,5
Δοκιμές	0,5	1	3	4	0
Αλλαγή και εκπαίδευση	1	2	3	5	1
Επιχειρησιακοί αναλυτές πελάτη	2	8	7	5	2
Μέγιστο συνολικό FTE	11	36	56	42	12

Ημερήσιες χρεώσεις ανά ρόλο και περιοχή (2024 έως 2025)

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

Ρόλος	Onshore US/UK/DE	GCC (UAE/KSA)	Nearshore (LatAm/EE)	Offshore (India)
Αρχιτέκτονας λύσης (ανώτερος)	2.000 έως 3.500 $	1.500 έως 2.500 $	900 έως 1.500 $	500 έως 1.000 $
Λειτουργικός σύμβουλος (ανώτερος)	1.500 έως 2.800 $	1.200 έως 2.000 $	700 έως 1.400 $	300 έως 700 $
Λειτουργικός σύμβουλος (μεσαίου επιπέδου)	1.000 έως 1.800 $	800 έως 1.400 $	500 έως 900 $	200 έως 500 $
ABAP και τεχνικός (ανώτερος)	1.400 έως 2.500 $	1.000 έως 1.800 $	600 έως 1.200 $	300 έως 700 $
Ειδικός ενσωμάτωσης	1.500 έως 2.800 $	1.100 έως 1.900 $	700 έως 1.300 $	350 έως 800 $
Basis	1.400 έως 2.200 $	1.000 έως 1.800 $	600 έως 1.100 $	300 έως 700 $
Ασφάλεια και GRC	1.500 έως 2.500 $	1.100 έως 1.900 $	700 έως 1.300 $	350 έως 800 $
Μετάπτωση δεδομένων	1.300 έως 2.200 $	1.000 έως 1.700 $	600 έως 1.100 $	300 έως 700 $
Επικεφαλής αλλαγής και εκπαίδευσης	1.200 έως 2.000 $	900 έως 1.500 $	500 έως 1.000 $	250 έως 600 $
Junior σύμβουλος (οποιοσδήποτε ρόλος)	800 έως 1.400 $	500 έως 900 $	400 έως 700 $	150 έως 350 $

Η κατανομή onshore, nearshore και offshore

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

Τα προγράμματα του ιδιωτικού τομέα των ΗΠΑ τρέχουν συνήθως με 30 έως 60% onshore ανά FTE. Το onshore συγκεντρώνεται στην αρχιτεκτονική, την αλλαγή, την επιχειρησιακή ανάλυση και τους ανώτερους λειτουργικούς ρόλους, όπου η εγγύτητα στην επιχείρηση μετράει. Το offshore συγκεντρώνεται στο ABAP, στην ανάπτυξη ενσωματώσεων και στην εκτέλεση της μετάπτωσης δεδομένων, όπου η δουλειά προδιαγράφεται πιο εύκολα. Τα ομοσπονδιακά προγράμματα των ΗΠΑ είναι συχνά πλήρως onshore, με περιορισμούς US-person, ανάλογα με τον φόρτο εργασίας.

Τα προγράμματα του GCC τρέχουν συνήθως με 60 έως 70% onshore, επειδή οι τοπικοί κανόνες πρόσληψης και οι απαιτήσεις αραβικής γλώσσας ανεβάζουν το ποσοστό. Η δουλειά offshore γέρνει προς κέντρα της Νότιας Ασίας λόγω της επικάλυψης ωραρίου. Τα ευρωπαϊκά προγράμματα ποικίλλουν: η μεταποίηση τρέχει συχνά γύρω στο 50% onshore, ενώ ο δημόσιος τομέας και οι ρυθμιζόμενοι κλάδοι πηγαίνουν υψηλότερα για λόγους κατοικίας δεδομένων.

Ένα συνηθισμένο λάθος είναι η βελτιστοποίηση της κατανομής μόνο ως προς το κόστος. Μια ομάδα 80% offshore με 20% αρχιτέκτονες onshore φαίνεται φθηνή στο λογιστικό φύλλο. Τα κρυφά κόστη είναι ο καθημερινός κύκλος παράδοσης και τα πιο αργά workshops σχεδιασμού χωρίς το επιχειρησιακό πλαίσιο. Η φθηνότερη ομάδα σπάνια παραδίδει το φθηνότερο πρόγραμμα. Όταν συγκρίνετε συνεργάτες, ο οδηγός μου για τους συνεργάτες υλοποίησης SAP ανά tier καλύπτει πώς διαφέρουν οι χρεώσεις και η σύνθεση των ομάδων μεταξύ τους.

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

Τι είναι ο σχεδιασμός κατανομής πόρων στα έργα SAP και γιατί έχει σημασία;

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

Τα έργα SAP εξαρτώνται από συγκεκριμένα άτομα: τον επικεφαλής FI/CO που καταλαβαίνει το λογιστικό σας σχέδιο, τον ειδικό μετάπτωσης που γνωρίζει τα legacy δεδομένα σας, τον επικεφαλής αλλαγής με τις σχέσεις στην επιχείρηση. Όταν δεν είναι διαθέσιμοι τη σωστή στιγμή, η δουλειά σταματά ή γίνεται λάθος. Πολλές καθυστερήσεις που φαίνονται τεχνικές είναι στην πραγματικότητα προβλήματα πόρων.

Πώς προκαλεί καθυστερήσεις σε έργα SAP η κακή κατανομή πόρων;

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

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

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

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

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

Πώς πρέπει να χειριστώ την αποχώρηση ενός βασικού ατόμου στη μέση του έργου;

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

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

Πότε πρέπει να κλιμακώσω ένα πρόβλημα πόρων;

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

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

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

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

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