Δοκιμές απόδοσης SAP: τι πρέπει να γνωρίζουν οι ηγέτες IT

Οι δοκιμές απόδοσης SAP αποδεικνύουν, πριν από το go-live, ότι οι κρίσιμες συναλλαγές, οι εργασίες παρασκηνίου και οι διεπαφές πληρούν τους συμφωνημένους χρόνους απόκρισης υπό παραγωγικούς όγκους. Ξεκινήστε τες στον σχεδιασμό, τρέξτε δοκιμές όγκου και φόρτου στο Realize μόλις σταθεροποιηθεί η παραμετροποίηση, ολοκληρώστε τον κύκλο πριν από τις δοκιμές αποδοχής χρηστών (UAT) και κάντε τα αποτελέσματα πύλη για το cutover. Ο οδηγός απευθύνεται σε CIO, διευθυντές προγραμμάτων και επικεφαλής δοκιμών σε προγράμματα S/4HANA, συμπεριλαμβανομένου του RISE with SAP. Καλύπτει τι να δοκιμάσετε, ποιος έχει την ευθύνη, πώς γράφονται τα κριτήρια αποδοχής και τι αλλάζει στο cloud. Ξεκινήστε από τον πίνακα κριτηρίων αποδοχής: αν δεν μπορείτε να τον συμπληρώσετε, δεν είστε έτοιμοι να δοκιμάσετε.

Τα προβλήματα απόδοσης στα προγράμματα SAP σχεδόν πάντα ανακαλύπτονται μετά το go-live. Τα tiles του Fiori λήγουν (timeout) όταν συνδέονται 300 χρήστες στην αλλαγή βάρδιας. Οι αναφορές Z παγώνουν επειδή κάποιος έτρεξε ένα ερώτημα ανοιχτού οικονομικού έτους σε πίνακα με 50 εκατομμύρια εγγραφές. Οι εργασίες παρασκηνίου επικαλύπτονται στο κλείσιμο μήνα και η εκτέλεση καταχωρίσεων διακόπτεται.

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

Δεν είναι οριακές περιπτώσεις. Είναι προβλέψιμες. Το μόνο ερώτημα είναι αν το πρόγραμμα τις δοκίμασε ή αν τις ανακαλύπτει η επιχείρηση με πραγματικές παραγγελίες σε εξέλιξη.

Δοκιμές απόδοσης σε όλο το SAP Activate

1. 01

   Explore

   Εντοπίστε κινδύνους απόδοσης στον σχεδιασμό. Η αρχιτεκτονική και η δομή των αναφορών κρίνουν το αποτέλεσμα πριν γραφτεί κώδικας.

2. 02

   Realize

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

3. 03

   Pre-UAT

   Ολοκληρώστε τον πλήρη κύκλο απόδοσης πριν από το UAT, όχι ως μέρος του.

4. 04

   Cutover

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

5. 05

   Hypercare

   Παρακολουθήστε τα ζωντανά KPI για 30 έως 60 ημέρες. Οι περισσότερες οπισθοδρομήσεις βγαίνουν στον πρώτο κύκλο κλεισίματος.

Σε ένα σύστημα ECC σε παραδοσιακή βάση δεδομένων, οι δοκιμές απόδοσης σήμαιναν δοκιμές φόρτου στον application server και στη βάση δεδομένων: χρόνος εκτέλεσης ABAP, απόδοση SQL, προγραμματισμός εργασιών. Το front end ήταν το SAP GUI, που σπάνια εξέπληττε κανέναν.

Στο S/4HANA, με front ends Fiori, επεκτάσεις στο SAP BTP και ενοποίηση μέσω SAP Cloud Integration (CPI), η απόδοση εξαρτάται από πολλά επίπεδα ταυτόχρονα. Ένα αργό tile του Fiori μπορεί να είναι μια μακρά κλήση ABAP, ένα timeout του gateway, μια υπηρεσία OData που δεν σχεδιάστηκε για ταυτόχρονα αιτήματα ή καθυστέρηση δικτύου σε υβριδική διάταξη. Οι δοκιμές μόνο στο back end δεν θα το βρουν. Οι δοκιμές σε ολόκληρη τη διαδρομή θα το βρουν.

1. 01Εκκίνηση tileΚαταιγίδες login στην έναρξη βάρδιας
2. 02Κλήση ODataTimeouts του gateway, υπηρεσίες που δεν χτίστηκαν για ταυτοχρονισμό
3. 03Επεξεργασία ABAPΧρονοβόρες κλήσεις ABAP
4. 04Ανάγνωση βάσης δεδομένωνΑνοιχτές επιλογές σε μεγάλους πίνακες
5. 05RenderingΣυν καθυστέρηση δικτύου για απομακρυσμένους χώρους

Ένας χρόνος απόκρισης, μετρημένος από άκρο σε άκρο

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

1. Οι δοκιμές φόρτου (load testing) ελέγχουν τη συμπεριφορά υπό αναμενόμενο όγκο. Η λέξη-κλειδί είναι «αναμενόμενος». Χρειάζεστε πραγματικούς όγκους συναλλαγών, αριθμούς χρηστών και ταυτόχρονες συνεδρίες. Πολλές δοκιμές φόρτου αποτυγχάνουν επειδή χρησιμοποίησαν εκτιμήσεις όγκου που όλοι ήξεραν ήδη ότι ήταν αισιόδοξες.
2. Οι δοκιμές πίεσης (stress testing) σπρώχνουν πέρα από τα όρια σχεδιασμού για να βρουν πού σπάει το σύστημα. Αν οι όγκοι θα διπλασιαστούν σε δεκαοκτώ μήνες, σας λένε αν η αρχιτεκτονική θα αντέξει και αν η διαστασιολόγηση γίνεται πρόβλημα πριν από την επόμενη αναθεώρηση υποδομής.
3. Οι δοκιμές αντοχής (soak testing) τρέχουν σταθερό φορτίο για παρατεταμένο διάστημα ώστε να αποκαλύψουν προβλήματα που χτίζονται με τον χρόνο: διαρροές μνήμης, κατακερματισμό και αντιπαράθεση αλυσίδων εργασιών σε επαναλαμβανόμενες εκτελέσεις. Είναι η δοκιμή που παραλείπεται συχνότερα, και εκείνη που θα είχε πιάσει την αποτυχία κλεισίματος μήνα που περιγράφεται παρακάτω.
4. Οι δοκιμές από άκρο σε άκρο (end-to-end testing) ακολουθούν ολόκληρη τη διαδρομή που κάνει ένας χρήστης: εκκίνηση tile, κλήση OData, επεξεργασία ABAP, ανάγνωση βάσης δεδομένων, rendering. Είναι ο μόνος τρόπος να βρεθούν προβλήματα που είναι αόρατα όταν κάθε επίπεδο δοκιμάζεται μόνο του.

Αλλαγή βάρδιας και αιχμή login. Όταν 200 χρήστες ανοίγουν το Fiori launchpad στις 8 το πρωί, η αυθεντικοποίηση και το rendering του launchpad εκτινάσσονται. Ένα σύστημα που είναι εντάξει εκτός αιχμής μπορεί να είναι άχρηστο σε εκείνο το παράθυρο αν δεν δοκιμάστηκαν ποτέ ταυτόχρονες συνδέσεις. Σε μεταποίηση, λιανικό εμπόριο και χρηματοοικονομικές υπηρεσίες, οι καταιγίδες login παράγουν τα πιο ορατά παράπονα της πρώτης ημέρας.

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

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

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

Χρήστες σε πολλές περιοχές. Η καθυστέρηση δικτύου επηρεάζει κάθε συναλλαγή. Μια παραγγελία πώλησης που παίρνει δύο δευτερόλεπτα στη χώρα φιλοξενίας μπορεί να φαίνεται χαλασμένη 3.000 μίλια μακριά αν κανείς δεν δοκίμασε από εκεί. Το RISE μεταφέρει τη φιλοξενία στη SAP, αλλά η καθυστέρηση εξακολουθεί να εξαρτάται από την περιοχή που επιλέγετε και από τη δρομολόγηση προς τους χρήστες σας.

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

Στοιχείο	Συνθήκη φορτίου	Όριο επιτυχίας	Υπεύθυνος
Δημιουργία παραγγελίας πώλησης (VA01 ή εφαρμογή Fiori)	150 ταυτόχρονοι χρήστες καταχώρισης παραγγελιών	Κάτω από 3 δευτερόλεπτα για το 95% των συναλλαγών	Υπεύθυνος διαδικασίας order-to-cash
Πρώτη φόρτωση Fiori launchpad στην έναρξη βάρδιας	Μέγιστος αριθμός ταυτόχρονων login για τη μεγαλύτερη βάρδια	Κάτω από 5 δευτερόλεπτα για το 95% των χρηστών	Επικεφαλής λειτουργιών IT
Αλυσίδα εργασιών κλεισίματος μήνα	Όγκοι περιόδου κλεισίματος, πλήρης αλληλουχία	Ολοκληρώνεται εντός του συμφωνημένου παραθύρου κλεισίματος χωρίς διακοπές	Financial controller
Διεπαφή εισερχόμενων παραγγελιών	Μέγιστος ωριαίος όγκος μηνυμάτων	Καμία συσσώρευση ουράς παλαιότερη από 15 λεπτά	Επικεφαλής ενοποιήσεων
Αναφορά custom μεγάλου όγκου	Πλήρης όγκος παραγωγικών δεδομένων, τυπική επιλογή	Κάτω από 60 δευτερόλεπτα. Οι ανοιχτές επιλογές μπλοκάρονται	Υπεύθυνος αναφοράς

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

Ζητήστε καθένα από αυτά με το όνομά του:

Προσδοκία	Τι πρέπει να παραδοθεί	Γιατί μετράει
Επίπεδα υπηρεσίας απόδοσης	Όρια ανά συναλλαγή, διεπαφή και εργασία, με επιτυχία και αποτυχία	Εμποδίζει τη γνώμη του UAT να υπερισχύσει των στοιχείων
Εύρος βάσει κινδύνου	Ιεράρχηση με βάση τον όγκο χρηστών, τα σημεία ενοποίησης και την εξάρτηση δεδομένων	Βάζει τους κύκλους δοκιμών στα φορτία που μετράνε
Συμμετοχή πολλών ομάδων	Basis, υποδομή, λειτουργικές, ασφάλεια και ενοποιήσεις παρούσες κατά τις εκτελέσεις	Αποτρέπει τη μετακύλιση ευθυνών όταν εμφανίζονται κενά
Έτοιμα εργαλεία και περιβάλλοντα	Γεννήτριες φορτίου (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), παρακολούθηση και ανανεώσεις δεδομένων έτοιμες πριν ξεκινήσουν οι κύκλοι	Κάνει ρεαλιστική την προσομοίωση
Ρεαλιστικά δεδομένα δοκιμών	Κύρια δεδομένα παραγωγικού όγκου, πραγματικές κλήσεις διεπαφών, αντιπροσωπευτικός συνδυασμός συναλλαγών	Κάνει τα αποτελέσματα να προβλέπουν τη συμπεριφορά στο go-live
Αναφορές απόδοσης	Συνδυασμός φορτίου, χρόνοι απόκρισης, CPU και μνήμη, χρόνοι εκτέλεσης εργασιών, ποσοστά σφαλμάτων	Δίνει στην έγκριση του cutover βάση στοιχείων
Σχέδιο παρακολούθησης μετά το go-live	KPI προς παρακολούθηση για τις πρώτες 30 έως 60 ημέρες	Επιβεβαιώνει ότι το ζωντανό σύστημα μένει εντός των δοκιμασμένων ορίων

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

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

Δοκιμές με μικρούς όγκους δεδομένων. Ένας πελάτης με 200.000 ανοιχτές γραμμές παραγγελιών συμπεριφέρεται διαφορετικά από έναν με 5.000. Φίλτρα που επιστρέφουν αμέσως στις δοκιμές λήγουν στην παραγωγή. Γεμίστε με όγκο τις περιοχές υψηλού κινδύνου.

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

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

Το RISE χωρίζει την ευθύνη

Στο RISE with SAP, η SAP έχει την υποδομή: διαστασιολόγηση, περιοχή hyperscaler, δίκτυο και διαθεσιμότητα πλατφόρμας. Ο πελάτης και ο συνεργάτης έχουν το επίπεδο εφαρμογής. Το έγγραφο ρόλων και ευθυνών του RISE της SAP το λέει καθαρά: ο εντοπισμός και η βελτιστοποίηση δαπανηρών εντολών SQL παραμένει στον πελάτη, εκτός αν αγοράσετε τις πρόσθετες υπηρεσίες εφαρμογών της SAP.

Μια συνηθισμένη αποτυχία στα προγράμματα RISE είναι η παραδοχή ότι η SAP θα πιάσει τα προβλήματα απόδοσης επειδή τρέχει την υποδομή. Θα πιάσει τα προβλήματα υποδομής. Δεν θα πιάσει μια κακοσχεδιασμένη υπηρεσία OData, μια αναποτελεσματική εργασία ABAP ή μια ροή ενοποίησης που δεν κλιμακώνεται. Γράψτε τον διαχωρισμό στη χάρτα και στο σχέδιο δοκιμών:

1. SAP: διαθεσιμότητα υποδομής και απόκριση σε επίπεδο πλατφόρμας
2. Συνεργάτης: απόδοση εφαρμογής υπό το καθορισμένο φορτίο, συμπεριλαμβανομένων των επεκτάσεων και των ροών ενοποίησης
3. Πελάτης: αποτελέσματα σε επίπεδο διαδικασίας, όπως ο χρόνος εκτέλεσης του κλεισίματος και η διακίνηση παραγγελιών, και η απόφαση αποδοχής

Το Public Edition και το GROW περιορίζουν το εύρος

Στο S/4HANA Cloud Public Edition, που συνήθως αγοράζεται μέσω GROW with SAP, η SAP τρέχει δοκιμές απόδοσης στην multi-tenant πλατφόρμα της ως μέρος του δικού της προτύπου προϊόντος και δεν περιμένει από τους πελάτες να δοκιμάσουν φόρτο στο κοινό σύστημα. Οι δοκιμές σας μετατοπίζονται σε ό,τι είναι δικό σας: προσαρμοσμένες ενοποιήσεις, επεκτάσεις, αναφορές και analytics μεγάλου όγκου, την αλληλουχία κλεισίματος και ενοποίησης και τη διαδρομή δικτύου από τους χώρους σας. Τα προβλήματα απόδοσης στην ίδια την πλατφόρμα πηγαίνουν στην υποστήριξη της SAP.

Η AI βοηθά με τα scripts, όχι με την αρχιτεκτονική

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

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

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

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

Ελέγχουν πώς συμπεριφέρεται το SAP υπό ρεαλιστικό φορτίο: χρόνους απόκρισης για συναλλαγές χρηστών, χρόνους εκτέλεσης για εργασίες παρασκηνίου, διακίνηση για διεπαφές και χρήση πόρων υπό ταυτόχρονη εργασία.

Η λειτουργική ορθότητα και η απόδοση είναι διαφορετικές ιδιότητες. Μια συναλλαγή που είναι σωστή για έναν χρήστη μπορεί να λήξει (timeout) για 200. Μια εργασία που τρέχει σε δέκα λεπτά με δεδομένα δοκιμής μπορεί να τρέχει ώρες σε παραγωγικούς όγκους. Το να το ανακαλύψετε μετά το go-live διαταράσσει τις λειτουργίες, επιβάλλει έκτακτες αλλαγές και πλήττει την εμπιστοσύνη των χρηστών όταν η υιοθέτηση είναι πιο εύθραυστη.

Πότε πρέπει να ξεκινούν οι δοκιμές απόδοσης σε ένα πρόγραμμα SAP;

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

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

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

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

Γράψτε το ρητά στο RACI: ποιος εγκρίνει τα κριτήρια αποδοχής, ποιος έχει την ευθύνη της αποκατάστασης όταν αποτυγχάνουν τα κριτήρια και ποιος μπορεί να μπλοκάρει το go-live για λόγους απόδοσης.

Πώς αλλάζει το RISE with SAP την ευθύνη των δοκιμών απόδοσης;

Η SAP έχει την υποδομή: διαστασιολόγηση, περιοχή, δίκτυο και διαθεσιμότητα πλατφόρμας. Ο πελάτης και ο συνεργάτης έχουν την απόδοση της εφαρμογής: παραμετροποίηση, επεκτάσεις, σχεδιασμό OData και Fiori, ροές ενοποίησης και KPI διαδικασιών. Το έγγραφο ρόλων και ευθυνών του RISE της SAP αφήνει τη βελτιστοποίηση SQL στον πελάτη, εκτός αν αγοραστούν πρόσθετες υπηρεσίες SAP.

Γράψτε τον διαχωρισμό στα κριτήρια αποδοχής ώστε κάθε όριο να έχει υπεύθυνο.

Ποια είναι τα συχνότερα προβλήματα απόδοσης του SAP Fiori;

Τέσσερα μοτίβα καλύπτουν τα περισσότερα. Οι καταιγίδες login στην έναρξη βάρδιας, όταν εκτινάσσονται η αυθεντικοποίηση και το rendering του launchpad. Οι υπηρεσίες OData που επιστρέφουν μεγάλα σύνολα αποτελεσμάτων ή κάνουν πολλές κλήσεις στο back end ανά αλληλεπίδραση. Το επίπεδο gateway που γίνεται από μόνο του σημείο συμφόρησης, γι' αυτό πρέπει να παρακολουθείται κατά τις δοκιμές. Και οι προσαρμοσμένες ή βαριά τροποποιημένες εφαρμογές, όπου οι τυπικές παραδοχές απόδοσης δεν ισχύουν.

Πώς ορίζετε κριτήρια αποδοχής απόδοσης για το SAP;

Ονομάστε τη συναλλαγή, το φορτίο και το όριο. Για παράδειγμα: «Η δημιουργία παραγγελίας ολοκληρώνεται σε λιγότερο από 3 δευτερόλεπτα για το 95% των συναλλαγών με 150 ταυτόχρονους χρήστες στον ρόλο καταχώρισης παραγγελιών.» Αυτό μπορεί να δοκιμαστεί.

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

Τι συμβαίνει αν παραλειφθούν ή συμπιεστούν οι δοκιμές απόδοσης;

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

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