6 λόγοι για τους οποίους τα έργα αυτοματοποίησης ρομποτικών διαδικασιών (RPA) αποτυγχάνουν και πώς να τα αποφύγετε

Φωτογραφία από το chuttersnap στο Unsplash

Η ρομποτική διαδικασία αυτοματισμού (RPA) είναι ένα καυτό θέμα στους τομείς αυτοματισμού και AI. Ουσιαστικά, το RPA είναι ένα εργαλείο λογισμικού που επιτυγχάνει την αυτοματοποίηση με τη μίμηση ανθρώπινων ενεργειών βασισμένων σε κανόνες και επαναλαμβανόμενων. Το RPA χρησιμοποιεί ένα ρομπότ ή bot για να αυτοματοποιήσει τις διαδικασίες. Σήμερα, υπάρχουν πολλοί πωλητές RPA στον κλάδο, με τους κύριους παίκτες να είναι Automation Anywhere (AA), Blue Prism και UiPath. Εάν είστε μια μικρή επιχείρηση ή ένας σπουδαστής που εξερευνά το πεδίο RPA, οι περισσότεροι προμηθευτές παρέχουν επίσης μια κοινοτική έκδοση των εργαλείων τους που είναι ελεύθερα να χρησιμοποιήσουν.

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

Οι φάσεις SDLC του έργου RPA
1. Σχεδιασμός: Επιλογή της σωστής διαδικασίας αυτοματοποίησης 2. Ανάλυση: Οι απαιτήσεις μάχη 3. Σχεδιασμός: Πώς να αποφύγετε τη δημιουργία ενός κακού σχεδιασμού λύσης 4. Ανάπτυξη: Αναγνωρίζοντας τις περιβαλλοντικές διαφορές μπροστά 5. Δοκιμές: Σενάρια δοκιμών που συχνά χάνονται στο RPA έργα 6. Υπερ-περίθαλψη: Τι γίνεται αν το ρομπότ δυσλειτουργεί πάρα πολύ συχνά;

1. Σχεδιασμός: Επιλέγοντας τη σωστή διαδικασία για αυτοματοποίηση

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

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

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

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

Η πρόσβαση σε μια διαδικασία με τις δύο προσεγγίσεις διασφαλίζει τη σκοπιμότητα της RPA και αποφεύγει να σπαταλάει πόρους στις επερχόμενες δραστηριότητες.

2. Ανάλυση: Οι απαιτήσεις μάχη

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

Φωτογραφία από τον James Pond στο Unsplash

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

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

3. Σχεδιασμός: Πώς να αποφύγετε τη δημιουργία ενός κακού σχεδιασμού λύσης

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

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

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

Συμβουλές σχεδίασης λύσεων RPA: 1. Η βασική λογική βρόχου για τη διεκπεραίωση όλων των εγγραφών (εισαγωγή δεδομένων) θα πρέπει να είναι σε θέση για κάθε διαδικασία
2. Το ρομπότ θα πρέπει να παράγει αποτελέσματα για κάθε εγγραφή (εισαγωγή δεδομένων), όπως "OK", "απέτυχε" και παρατηρήσεις αν χρειαστεί 
3. Το ρομπότ πρέπει να ειδοποιεί τον χρήστη όταν έχει ολοκληρώσει μια διαδικασία μέσω αναδυόμενου παραθύρου, ηλεκτρονικού ταχυδρομείου κλπ.
4. Προγραμματισμός αναστροφής: εάν συμβεί κάποιο σφάλμα, επιστρέψτε στο βήμα X για να συνεχίσετε την επεξεργασία της επόμενης εγγραφής
5. Προγραμματισμός αναστροφής: αν συμβεί βλάβη στο σύστημα, σταματήστε τη διαδικασία και κλείστε την εφαρμογή πριν βγει το ρομπότ
6. Βεβαιωθείτε ότι όλες οι εφαρμογές που χρησιμοποιούνται είναι κλειστές πριν από την έξοδο του ρομπότ

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

4. Ανάπτυξη: Αναγνωρίζοντας τις μελλοντικές περιβαλλοντικές διαφορές

Τα ρομπότ RPA βασίζονται στη διεπαφή χρήστη (UI) για να μάθουν πώς και πότε πρέπει να εισάγουν ένα πλήκτρο συντόμευσης, να κάνουν κλικ ή να εκτελέσουν μια λειτουργία. Ίδιες οθόνες εφαρμογών σε όλα τα περιβάλλοντα (Ανάπτυξη, δοκιμή αποδοχής από το χρήστη (UAT) και ειδικά περιβάλλοντα παραγωγής) θα βοηθούσαν στη βελτίωση της διαχείρισης της διαδικασίας ανάπτυξης. Ωστόσο, οι συμπεριφορές εφαρμογής είναι συχνά ελαφρώς διαφορετικές σε κάθε περιβάλλον και όταν χρησιμοποιούνται από διαφορετικούς τύπους χρηστών. Έτσι, ο κύριος του έργου θα πρέπει να προγραμματίσει σχέδια «έκτακτης ανάγκης» όταν εντοπιστεί μια τέτοια διαφορά.

Φωτογραφία από τον Kevin Ku στο Unsplash

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

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

5. Δοκιμές: Δοκιμαστικά σενάρια που συχνά χάνονται σε έργα RPA

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

Σενάρια σχετιζόμενα με το RPA - Σενάρια παράθυρου, αντικειμένου που δεν βρέθηκε - Πολλαπλά ρομπότ που εκτελούν την ίδια διαδικασία ταυτόχρονα - Όλες οι εφαρμογές έκλεισαν πριν το ρομπότ βγει - Το αρχείο καταγραφής αποθηκεύεται και διαβάζεται για κάθε εκτέλεση διαδικασίας
Σενάρια που σχετίζονται με την επιχείρηση - Σενάριο εισαγωγής δεδομένων που δεν παρέχεται - Επιτυχής εισαγωγή ονόματος, ηλικίας και αποθήκευσης προφίλ πελάτη - Το αποτέλεσμα υπολογισμού είναι σωστό - Εκτυπώστε το αποτέλεσμα σφάλματος αν το όνομα δεν παρέχεται και συνεχίστε με το - Αριθμός επεξεργασίας FTE αποθηκευμένου (macro KPI)

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

6. Υπερ-φροντίδα: Τι γίνεται αν το ρομπότ λειτουργεί πολύ συχνά;

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

Μπορούμε να ορίσουμε ένα σενάριο ως "RPA ρομποτάκι δυσλειτουργία" εάν η εκτέλεση της διαδικασίας δεν έχει επιτευχθεί ο στόχος του αναμενόμενου αποτελέσματος / βασικών δεικτών επιδόσεων (KPI), που συνήθως καθορίζονται στο χάρτα έργου.

Ορισμένο δείγμα RPA KPI περιλαμβάνει: 
- Αριθμός αποθηκευμένων FTE (macro KPI) -% χρόνου / χρόνου που χρειάζεται ανθρώπινη παρέμβαση - Αριθμός αρχείων προς επεξεργασία ανά ώρα / ημέρα - Αριθμός εγγραφών που υποβλήθηκαν σε επεξεργασία με επιτυχία από το ρομπότ

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

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

Φωτογραφία από τον Phillip Glickman στο Unsplash

Ευτυχισμένη αυτοματοποίηση!