Στον χώρο του IT, η αλλαγή είναι αναπόφευκτη. Τα λειτουργικά συστήματα πρέπει να ενημερωθούν, οι εφαρμογές να αναβαθμιστούν, οι πολιτικές ασφαλείας να ενισχυθούν, ο εξοπλισμός να αντικατασταθεί και οι υποδομές να προσαρμοστούν σε νέες επιχειρησιακές ανάγκες. Ένα περιβάλλον που δεν αλλάζει δεν παραμένει σταθερό. Σταδιακά γίνεται ευάλωτο, ασύμβατο και δυσκολότερο στη συντήρηση.
Το πραγματικό πρόβλημα, επομένως, δεν είναι αν θα πραγματοποιηθούν αλλαγές. Είναι αν αυτές οι αλλαγές θα εισαχθούν με τρόπο ελεγχόμενο, προβλέψιμο και κατανοητό από όλους όσοι επηρεάζονται.
Μια αλλαγή μπορεί να είναι τεχνικά σωστή και παρ’ όλα αυτά να αποτύχει επιχειρησιακά. Ένα update μπορεί να εγκατασταθεί επιτυχώς, αλλά να διακόψει μια κρίσιμη διασύνδεση. Μια νέα πολιτική ασφαλείας μπορεί να μειώσει το ρίσκο, αλλά να εμποδίσει τους χρήστες να ολοκληρώσουν την εργασία τους. Μια μεταφορά υπηρεσίας μπορεί να ολοκληρωθεί χωρίς errors, αλλά να αφήσει το support team απροετοίμαστο για τα προβλήματα που θα ακολουθήσουν.
Το Change Management υπάρχει για να περιορίζει αυτή την απόσταση ανάμεσα στην τεχνική υλοποίηση και στο πραγματικό αποτέλεσμα.
Μια επιτυχημένη αλλαγή δεν είναι απλώς εκείνη που εφαρμόστηκε σύμφωνα με το αρχικό σχέδιο. Είναι εκείνη που πέτυχε τον στόχο της χωρίς να δημιουργήσει περιττή διακοπή, χωρίς να εισαγάγει μη αποδεκτό ρίσκο και χωρίς να αφήσει την ομάδα σε χειρότερη θέση από εκείνη στην οποία βρισκόταν πριν.
Το Change Management δεν είναι γραφειοκρατία
Σε αρκετές ομάδες, το Change Management αντιμετωπίζεται ως διοικητική υποχρέωση. Ένα ticket συμπληρώνεται, κάποιος εγκρίνει την αλλαγή και η διαδικασία θεωρείται ολοκληρωμένη. Όταν συμβαίνει αυτό, η πραγματική αξία του Change Management χάνεται.
Ο σκοπός του δεν είναι να προσθέσει εμπόδια στους engineers ούτε να καθυστερήσει κάθε τεχνική εργασία. Ο σκοπός του είναι να δημιουργήσει τις συνθήκες μέσα στις οποίες η αλλαγή μπορεί να πραγματοποιηθεί με τη μεγαλύτερη δυνατή πιθανότητα επιτυχίας.
Μια σωστή διαδικασία πρέπει να βοηθά την ομάδα να απαντήσει σε βασικά ερωτήματα. Γιατί χρειάζεται η αλλαγή; Τι ακριβώς πρόκειται να τροποποιηθεί; Ποιες υπηρεσίες εξαρτώνται από το συγκεκριμένο σύστημα; Ποιοι χρήστες θα επηρεαστούν; Τι θα συμβεί αν η εφαρμογή αποτύχει; Πόσο γρήγορα μπορεί να γίνει αποκατάσταση; Πώς θα επιβεβαιωθεί ότι το αποτέλεσμα είναι πράγματι σωστό;
Όταν αυτά τα ερωτήματα απαντώνται εγκαίρως, η διαδικασία δεν αποτελεί γραφειοκρατικό βάρος. Αποτελεί εργαλείο τεχνικής σαφήνειας και επιχειρησιακής προστασίας.
Γιατί αποτυγχάνουν τεχνικά σωστές αλλαγές
Οι περισσότερες προβληματικές αλλαγές δεν αποτυγχάνουν επειδή κανείς δεν γνώριζε πώς να εκτελέσει την τεχνική εργασία. Αποτυγχάνουν επειδή το πλαίσιο γύρω από την εργασία δεν είχε κατανοηθεί επαρκώς.
Ένας administrator μπορεί να γνωρίζει ακριβώς πώς να αναβαθμίσει έναν server, αλλά να μην έχει πλήρη εικόνα των εφαρμογών που εξαρτώνται από αυτόν. Ένας network engineer μπορεί να εφαρμόσει σωστά μια αλλαγή σε VLAN, αλλά να μην έχει ενημερωθεί ότι μια παλαιότερη συσκευή χρησιμοποιεί στατική ρύθμιση. Ένας developer μπορεί να αναπτύξει μια νέα έκδοση χωρίς σφάλματα, αλλά η βάση δεδομένων να έχει αλλάξει με τρόπο που καθιστά το rollback πρακτικά αδύνατο.
Η τεχνική ορθότητα ενός βήματος δεν εγγυάται την επιτυχία ολόκληρης της αλλαγής. Οι σύγχρονες υποδομές αποτελούνται από αλληλεξαρτήσεις. Εφαρμογές, accounts, APIs, certificates, policies, συσκευές, δίκτυα και ανθρώπινες διαδικασίες συνδέονται μεταξύ τους με τρόπους που συχνά δεν είναι πλήρως καταγεγραμμένοι.
Για αυτόν τον λόγο, η διαχείριση αλλαγών πρέπει να εξετάζει το σύστημα ως σύνολο και όχι μόνο το στοιχείο που πρόκειται να τροποποιηθεί.
Οι βασικές κατηγορίες αλλαγών
Δεν χρειάζονται όλες οι αλλαγές το ίδιο επίπεδο αξιολόγησης και έγκρισης. Μια επαναλαμβανόμενη και αποδεδειγμένα ασφαλής διαδικασία δεν πρέπει να αντιμετωπίζεται με τον ίδιο τρόπο όπως μια σημαντική αναβάθμιση παραγωγικού συστήματος.
Οι standard changes είναι επαναλαμβανόμενες, καλά τεκμηριωμένες και χαμηλού ρίσκου αλλαγές. Έχουν εκτελεστεί αρκετές φορές, διαθέτουν γνωστή διαδικασία και μπορούν να θεωρούνται προεγκεκριμένες όταν τηρούνται συγκεκριμένες προϋποθέσεις. Ένα παράδειγμα μπορεί να είναι η δημιουργία ενός λογαριασμού βάσει καθορισμένου προτύπου ή η εγκατάσταση εγκεκριμένου λογισμικού σε συγκεκριμένη κατηγορία συσκευών.
Οι normal changes απαιτούν αξιολόγηση, σχεδιασμό και έγκριση πριν από την εφαρμογή. Η πολυπλοκότητα της διαδικασίας πρέπει να προσαρμόζεται στο πραγματικό ρίσκο. Μια μικρή αλλαγή διαμόρφωσης μπορεί να χρειάζεται έναν σύντομο τεχνικό έλεγχο, ενώ μια αναβάθμιση κρίσιμης υποδομής μπορεί να απαιτεί λεπτομερές σχέδιο, συντονισμό πολλών ομάδων και συγκεκριμένο maintenance window.
Οι emergency changes πραγματοποιούνται όταν υπάρχει άμεση ανάγκη αποκατάστασης σοβαρού incident, κλεισίματος κρίσιμου κενού ασφαλείας ή αποτροπής σημαντικής επιχειρησιακής ζημιάς. Το γεγονός ότι μια αλλαγή είναι επείγουσα δεν σημαίνει ότι δεν χρειάζεται διαδικασία. Σημαίνει ότι η διαδικασία πρέπει να είναι ταχύτερη, με περιορισμένο αλλά σαφές επίπεδο έγκρισης, καταγεγραμμένη αιτιολόγηση και υποχρεωτική ανασκόπηση μετά την εφαρμογή.
Η σωστή κατηγοριοποίηση εμποδίζει δύο αντίθετα προβλήματα. Αποφεύγει την υπερβολική γραφειοκρατία για απλές εργασίες και ταυτόχρονα εμποδίζει τις σημαντικές αλλαγές να παρουσιάζονται ως ασήμαντες για να εφαρμοστούν γρηγορότερα.
Risk και impact δεν είναι το ίδιο
Ένα από τα συχνότερα λάθη στην αξιολόγηση μιας αλλαγής είναι η σύγχυση ανάμεσα στην πιθανότητα αποτυχίας και στο μέγεθος των συνεπειών.
Το risk αφορά την πιθανότητα να παρουσιαστεί πρόβλημα σε συνδυασμό με τη σοβαρότητα του αποτελέσματος. Το impact αφορά το εύρος και την ένταση της επίδρασης που θα έχει η αλλαγή ή μια πιθανή αποτυχία της.
Μια αλλαγή μπορεί να έχει μικρή πιθανότητα αποτυχίας, αλλά εξαιρετικά μεγάλο impact. Η ανανέωση ενός certificate, για παράδειγμα, μπορεί να είναι τεχνικά απλή. Αν όμως το certificate χρησιμοποιείται από μια κρίσιμη εφαρμογή και η αντικατάσταση γίνει λανθασμένα, η υπηρεσία μπορεί να σταματήσει να λειτουργεί για όλους τους χρήστες.
Αντίθετα, μια αλλαγή μπορεί να έχει μεγαλύτερη πιθανότητα μικρών προβλημάτων, αλλά περιορισμένο επιχειρησιακό αντίκτυπο. Η ενημέρωση ενός εργαλείου σε ένα μη κρίσιμο test environment μπορεί να προκαλέσει ασυμβατότητες, χωρίς όμως να επηρεάζει την παραγωγική λειτουργία.
Μια ουσιαστική αξιολόγηση πρέπει να εξετάζει τον αριθμό των χρηστών που επηρεάζονται, τη σημασία της υπηρεσίας, τις χρονικές απαιτήσεις αποκατάστασης, τις τεχνικές εξαρτήσεις, την ύπαρξη διαθέσιμου workaround και τη δυνατότητα επιστροφής στην προηγούμενη κατάσταση.
Το ερώτημα δεν είναι μόνο «πόσο πιθανό είναι να αποτύχει;». Είναι επίσης «τι θα συμβεί στην επιχείρηση αν αποτύχει;».
Ανακαλύπτοντας τις πραγματικές εξαρτήσεις
Πριν από μια σημαντική αλλαγή, η ομάδα πρέπει να γνωρίζει τι εξαρτάται από το σύστημα που πρόκειται να τροποποιηθεί. Στην πράξη, αυτή η πληροφορία δεν είναι πάντοτε πλήρης.
Ένας server μπορεί να φιλοξενεί περισσότερες υπηρεσίες από όσες αναφέρονται στο documentation. Μια εφαρμογή μπορεί να χρησιμοποιεί ένα παλιό service account που κανείς δεν θυμάται. Ένας εκτυπωτής μπορεί να επικοινωνεί με μια επιχειρησιακή εφαρμογή μέσω στατικής IP. Ένα scheduled task μπορεί να εκτελείται μόνο μία φορά τον μήνα και να μη συμπεριλαμβάνεται στους συνηθισμένους ελέγχους.
Η χαρτογράφηση των εξαρτήσεων χρειάζεται συνδυασμό τεχνικών δεδομένων και ανθρώπινης γνώσης. Configuration records, network flows, logs, monitoring, application owners και support teams μπορούν να αποκαλύψουν διαφορετικά τμήματα της εικόνας.
Όσο πιο κρίσιμη είναι η αλλαγή, τόσο λιγότερο ασφαλές είναι να βασίζεται αποκλειστικά στη μνήμη ενός ανθρώπου.
Το Change Management λειτουργεί καλύτερα όταν συνδέεται με σωστή τεκμηρίωση υποδομών, ενημερωμένο asset inventory και ξεκάθαρη ιδιοκτησία υπηρεσιών. Όταν αυτά απουσιάζουν, κάθε μεγάλη αλλαγή μετατρέπεται σε διαδικασία ανακάλυψης άγνωστων εξαρτήσεων την τελευταία στιγμή.
Το implementation plan πρέπει να μπορεί να εκτελεστεί από άλλον άνθρωπο
Η περιγραφή μιας αλλαγής ως «upgrade the server» ή «update the network configuration» δεν αποτελεί implementation plan.
Ένα σωστό σχέδιο πρέπει να περιγράφει τα βήματα με αρκετή ακρίβεια, ώστε ένας άλλος κατάλληλα καταρτισμένος engineer να μπορεί να κατανοήσει τι πρόκειται να συμβεί, με ποια σειρά και κάτω από ποιες προϋποθέσεις.
Πριν από την έναρξη πρέπει να είναι γνωστά τα απαιτούμενα backups, οι έλεγχοι διαθεσιμότητας, οι εκδόσεις λογισμικού, τα απαραίτητα permissions, οι υπεύθυνοι και η αναμενόμενη διάρκεια. Κατά την εφαρμογή πρέπει να υπάρχουν συγκεκριμένα checkpoints. Μετά την ολοκλήρωση πρέπει να εκτελεστούν σαφείς validation checks.
Το σχέδιο πρέπει επίσης να περιλαμβάνει κριτήρια διακοπής. Αν ένα συγκεκριμένο βήμα διαρκέσει περισσότερο από το αναμενόμενο, αν ένας κρίσιμος έλεγχος αποτύχει ή αν το maintenance window πλησιάζει στο τέλος του, η ομάδα πρέπει να γνωρίζει αν θα συνεχίσει, αν θα ενεργοποιήσει rollback ή αν θα μεταβεί σε εναλλακτικό σχέδιο.
Η σαφήνεια αυτή δεν αφαιρεί την τεχνική κρίση από τον engineer. Του παρέχει ένα πλαίσιο μέσα στο οποίο μπορεί να πάρει καλύτερες αποφάσεις όταν οι συνθήκες δεν εξελίσσονται όπως αναμενόταν.
Η σημασία του testing πριν από την παραγωγή
Η φράση «λειτούργησε στο test environment» είναι χρήσιμη, αλλά δεν αποτελεί από μόνη της εγγύηση επιτυχίας.
Ένα test environment έχει αξία μόνο όταν αντιπροσωπεύει αρκετά καλά τις κρίσιμες συνθήκες της παραγωγής. Οι εκδόσεις, οι πολιτικές, οι integrations, οι λογαριασμοί και οι ροές δεδομένων πρέπει να είναι αρκετά κοντά στην πραγματική κατάσταση ώστε τα αποτελέσματα να έχουν νόημα.
Σε αρκετές περιπτώσεις, η πλήρης αντιγραφή του production environment δεν είναι εφικτή. Αυτό δεν σημαίνει ότι το testing πρέπει να εγκαταλειφθεί. Σημαίνει ότι τα όριά του πρέπει να καταγραφούν.
Η ομάδα πρέπει να γνωρίζει ποια σενάρια δοκιμάστηκαν, ποια δεν μπορούσαν να δοκιμαστούν και ποιο πρόσθετο monitoring χρειάζεται μετά την εφαρμογή.
Το testing πρέπει επίσης να επικεντρώνεται στις πραγματικές επιχειρησιακές λειτουργίες. Το γεγονός ότι ένας server απαντά σε ping ή ότι μια εφαρμογή φορτώνει τη σελίδα εισόδου δεν σημαίνει ότι η αλλαγή είναι επιτυχής. Μπορεί να μη λειτουργεί η αυθεντικοποίηση, η εκτύπωση, η αποστολή email, η επικοινωνία με τρίτα συστήματα ή μια λειτουργία που χρησιμοποιείται μόνο από συγκεκριμένο τμήμα.
Η τελική επιβεβαίωση πρέπει να βασίζεται σε end-to-end σενάρια και όχι μόνο στην τεχνική διαθεσιμότητα μεμονωμένων components.
Baseline και post-change validation
Για να αξιολογηθεί αν μια αλλαγή βελτίωσε ή επιδείνωσε την κατάσταση, χρειάζεται σημείο σύγκρισης.
Πριν από την εφαρμογή πρέπει να καταγραφούν βασικά δεδομένα. Η υγεία των υπηρεσιών, οι χρόνοι απόκρισης, η χρήση πόρων, τα ενεργά integrations, τα σχετικά logs και η επιτυχία κρίσιμων business transactions μπορούν να λειτουργήσουν ως baseline.
Μετά την αλλαγή, οι ίδιοι έλεγχοι πρέπει να επαναληφθούν. Η σύγκριση επιτρέπει στην ομάδα να εντοπίσει προβλήματα που δεν οδηγούν σε πλήρη διακοπή, αλλά υποβαθμίζουν τη λειτουργία.
Ένα σύστημα μπορεί να θεωρείται online και παρ’ όλα αυτά να έχει διπλάσιο χρόνο απόκρισης. Μια εφαρμογή μπορεί να επιτρέπει login, αλλά να δημιουργεί αυξημένα errors στο background. Μια υπηρεσία μπορεί να λειτουργεί για τους περισσότερους χρήστες, αλλά να έχει χάσει τη σύνδεσή της με έναν συγκεκριμένο integration partner.
Το post-change validation πρέπει να απαντά στο αν το σύστημα λειτουργεί όπως πριν, αλλά και στο αν επιτεύχθηκε ο λόγος για τον οποίο πραγματοποιήθηκε η αλλαγή.
Το rollback plan δεν είναι μια γενική υπόσχεση
Πολλά change records περιλαμβάνουν ως rollback plan τη φράση «restore the previous version». Αυτή η περιγραφή δεν είναι αρκετή.
Ένα πραγματικό rollback plan πρέπει να εξηγεί ποια δεδομένα θα επανέλθουν, ποια configuration files θα αντικατασταθούν, πόσο χρόνο απαιτεί η διαδικασία, ποιος έχει την εξουσία να την ενεργοποιήσει και ποια θα είναι η επίδραση στις συναλλαγές που πραγματοποιήθηκαν μετά την αλλαγή.
Μερικές αλλαγές είναι εύκολα αναστρέψιμες. Μια ρύθμιση μπορεί να επανέλθει στην προηγούμενη τιμή ή ένα virtual machine snapshot να αποκατασταθεί μέσα σε συγκεκριμένο χρόνο.
Άλλες αλλαγές δεν μπορούν να αναστραφούν χωρίς απώλεια ή σύνθετη επεξεργασία. Ένα database schema migration, μια αλλαγή μορφής δεδομένων ή μια μεταφορά χρηστών σε νέο authentication system μπορεί να δημιουργήσει νέα δεδομένα που δεν είναι συμβατά με την προηγούμενη έκδοση.
Σε αυτές τις περιπτώσεις μπορεί να χρειάζεται roll-forward strategy. Αντί να επιστρέψει το σύστημα στην προηγούμενη κατάσταση, η ομάδα διορθώνει γρήγορα το νέο περιβάλλον και το οδηγεί σε λειτουργική κατάσταση.
Το σημαντικό είναι να μην παρουσιάζεται το rollback ως θεωρητική δυνατότητα. Πρέπει να είναι τεχνικά εφικτό, χρονικά ρεαλιστικό και, όπου είναι δυνατόν, δοκιμασμένο πριν από την αλλαγή.
Επικοινωνία πριν, κατά τη διάρκεια και μετά την αλλαγή
Το Change Management δεν είναι μόνο τεχνική διαδικασία. Είναι επίσης διαδικασία συντονισμού.
Οι χρήστες, το support team, οι application owners, η διοίκηση και οι τεχνικές ομάδες δεν χρειάζονται την ίδια πληροφορία. Χρειάζονται όμως όλοι την πληροφορία που είναι απαραίτητη για τον ρόλο τους.
Οι τελικοί χρήστες πρέπει να γνωρίζουν πότε θα πραγματοποιηθεί η αλλαγή, ποια υπηρεσία θα επηρεαστεί, αν χρειάζεται να κάνουν κάποια ενέργεια και πού θα αναφέρουν πρόβλημα.
Το support team χρειάζεται πιθανές επιπτώσεις, γνωστά συμπτώματα, workaround, escalation path και τρόπο επιβεβαίωσης ότι ένα νέο ticket σχετίζεται με την αλλαγή.
Οι τεχνικές ομάδες χρειάζονται λεπτομερές implementation plan, ownership, communication channel και σαφή κατανομή αποφάσεων.
Η διοίκηση συνήθως χρειάζεται συνοπτική εικόνα του επιχειρησιακού ρίσκου, της αναμενόμενης διάρκειας και της κατάστασης ολοκλήρωσης.
Η έλλειψη σωστής επικοινωνίας μπορεί να μετατρέψει μια επιτυχημένη τεχνική αλλαγή σε επιχειρησιακή αποτυχία. Οι χρήστες μπορεί να θεωρήσουν μια προγραμματισμένη διακοπή ως incident, το support να δεχθεί περιττό όγκο tickets και διαφορετικές ομάδες να ξεκινήσουν παράλληλες ενέργειες αντιμετώπισης του ίδιου προβλήματος.
Maintenance windows και πραγματικός επιχειρησιακός χρόνος
Η επιλογή της κατάλληλης χρονικής στιγμής δεν πρέπει να βασίζεται μόνο στο πότε είναι διαθέσιμη η τεχνική ομάδα.
Μια αλλαγή πρέπει να προγραμματίζεται με βάση τη χρήση της υπηρεσίας, τις επιχειρησιακές περιόδους αιχμής, τη διαθεσιμότητα των κατάλληλων ανθρώπων και τον χρόνο που απαιτείται για validation και rollback.
Ένα maintenance window δεν πρέπει να καλύπτει μόνο την αναμενόμενη διάρκεια της εγκατάστασης. Πρέπει να περιλαμβάνει χρόνο για προετοιμασία, ελέγχους, απρόβλεπτες καθυστερήσεις και ασφαλή αποκατάσταση.
Αν μια αλλαγή χρειάζεται δύο ώρες και το rollback άλλες δύο, ένα παράθυρο δύο ωρών δεν είναι πραγματικά επαρκές.
Εξίσου σημαντική είναι η διαθεσιμότητα των application owners και του support team. Μια αλλαγή που ολοκληρώνεται αργά τη νύχτα χωρίς κάποιον να μπορεί να επιβεβαιώσει τις πραγματικές επιχειρησιακές λειτουργίες μεταφέρει απλώς το ρίσκο στην επόμενη ημέρα.
Emergency changes χωρίς απώλεια ελέγχου
Κατά τη διάρκεια ενός σοβαρού incident, η πίεση για άμεση δράση είναι μεγάλη. Αυτή είναι ακριβώς η στιγμή που οι λανθασμένες αλλαγές μπορούν να επιδεινώσουν την κατάσταση.
Μια emergency change χρειάζεται σαφή στόχο. Πρέπει να αντιμετωπίζει το ενεργό incident ή το άμεσο security risk και όχι να χρησιμοποιείται ως ευκαιρία για πρόσθετες βελτιώσεις που μπορούν να περιμένουν.
Η έγκριση μπορεί να είναι συντομότερη και να δοθεί από περιορισμένο αριθμό εξουσιοδοτημένων ανθρώπων. Παρ’ όλα αυτά, η αλλαγή πρέπει να καταγράφεται, να υπάρχει διαθέσιμο rollback ή recovery plan και να ορίζονται οι βασικοί έλεγχοι επιτυχίας.
Μετά την αποκατάσταση, απαιτείται αναδρομική ανασκόπηση. Η ομάδα πρέπει να καταγράψει τι εφαρμόστηκε, γιατί επιλέχθηκε, ποιο ήταν το αποτέλεσμα και αν η επείγουσα αλλαγή δημιούργησε τεχνικό χρέος ή νέα ρίσκα.
Το emergency change δεν πρέπει να μετατρέπεται σε τρόπο παράκαμψης της κανονικής διαδικασίας. Αν μια ομάδα χαρακτηρίζει συστηματικά τις αλλαγές ως επείγουσες, το πρόβλημα βρίσκεται συνήθως στον προγραμματισμό, στην ιδιοκτησία ή στην ίδια τη διαδικασία έγκρισης.
Ο ρόλος του Change Advisory Board
Το Change Advisory Board, όταν χρησιμοποιείται σωστά, δεν είναι μια ομάδα που εγκρίνει μηχανικά κάθε τεχνική ενέργεια.
Ο ρόλος του είναι να προσφέρει διαφορετικές οπτικές πάνω στο ρίσκο, στις εξαρτήσεις, στον χρονισμό και στη συνολική επίδραση μιας σημαντικής αλλαγής. Η σύνθεσή του πρέπει να προσαρμόζεται στο είδος της αλλαγής. Δεν χρειάζονται οι ίδιοι άνθρωποι για μια αλλαγή δικτύου, μια εφαρμογή HR ή μια αναβάθμιση συστήματος πληρωμών.
Το CAB δεν πρέπει να αντικαθιστά την τεχνική ευθύνη της ομάδας που υλοποιεί την αλλαγή. Ούτε πρέπει να εγκρίνει κάτι που δεν κατανοεί επαρκώς μόνο και μόνο επειδή συμπληρώθηκαν όλα τα απαιτούμενα πεδία.
Σε ώριμα περιβάλλοντα, οι απλές και επαναλαμβανόμενες αλλαγές αυτοματοποιούνται ή μετατρέπονται σε standard changes. Η συλλογική αξιολόγηση επικεντρώνεται στις αλλαγές που έχουν πραγματικά σημαντικό ρίσκο, αβεβαιότητα ή επιχειρησιακό αντίκτυπο.
Change Management και automation
Η αυτοματοποίηση μπορεί να βελτιώσει σημαντικά τη διαδικασία αλλαγών, αλλά δεν καταργεί την ανάγκη για Change Management.
Ένα automated deployment pipeline μπορεί να εφαρμόσει μια αλλαγή με συνέπεια, να εκτελέσει tests και να μειώσει τα χειροκίνητα λάθη. Infrastructure as Code μπορεί να καταγράψει τις τροποποιήσεις, να επιτρέψει peer review και να δημιουργήσει επαναλήψιμες υποδομές.
Παρόλα αυτά, ένα τέλεια αυτοματοποιημένο λάθος παραμένει λάθος. Αν η αλλαγή βασίζεται σε λανθασμένη απαίτηση ή αν δεν έχουν εντοπιστεί οι πραγματικές εξαρτήσεις, η αυτοματοποίηση απλώς επιτρέπει στο πρόβλημα να εφαρμοστεί γρηγορότερα και με μεγαλύτερη συνέπεια.
Η ιδανική σχέση είναι συμπληρωματική. Το Change Management ορίζει γιατί, πότε και κάτω από ποιες προϋποθέσεις πρέπει να πραγματοποιηθεί η αλλαγή. Η αυτοματοποίηση βοηθά να εφαρμοστεί με ελεγχόμενο, επαναλήψιμο και επαληθεύσιμο τρόπο.
Post-implementation review και οργανωτική μάθηση
Η αλλαγή δεν ολοκληρώνεται όταν τελειώσει το maintenance window.
Μετά την εφαρμογή πρέπει να εξεταστεί αν επιτεύχθηκε ο στόχος, αν εμφανίστηκαν απρόβλεπτα προβλήματα, αν η εκτίμηση ρίσκου ήταν σωστή και αν το implementation plan ανταποκρινόταν στην πραγματικότητα.
Μια post-implementation review δεν πρέπει να χρησιμοποιείται για την απόδοση ευθυνών. Πρέπει να βοηθά την ομάδα να μετατρέπει την εμπειρία σε βελτιωμένη διαδικασία.
Αν μια αλλαγή ήταν επιτυχής και επαναλαμβανόμενη, μπορεί να γίνει υποψήφια για standardization και automation. Αν απέτυχε, πρέπει να εξεταστεί ποιο μέρος της διαδικασίας δεν λειτούργησε. Ήταν λανθασμένη η τεχνική λύση, ελλιπές το testing, ασαφές το ownership ή ανεπαρκής η επικοινωνία;
Οι απαντήσεις πρέπει να ενημερώνουν το documentation, τα templates, τα monitoring checks και τις μελλοντικές αποφάσεις.
Μια ώριμη ομάδα δεν μετρά μόνο πόσες αλλαγές ολοκληρώθηκαν. Εξετάζει πόσες πέτυχαν χωρίς incident, πόσες χρειάστηκαν rollback, πόσες προκάλεσαν απρόβλεπτη υποβάθμιση και πόσο αποτελεσματικά μετατράπηκαν τα μαθήματα σε βελτιώσεις.
Τα συχνότερα anti-patterns
Ένα από τα πιο επικίνδυνα anti-patterns είναι η αλλαγή χωρίς ξεκάθαρο owner. Όταν κανείς δεν έχει την τελική ευθύνη, οι αποφάσεις καθυστερούν και η ομάδα δυσκολεύεται να αντιδράσει σε αποτυχία.
Εξίσου προβληματική είναι η αλλαγή χωρίς μετρήσιμα success criteria. Αν δεν έχει οριστεί τι σημαίνει επιτυχία, μπορεί να ολοκληρωθεί τεχνικά χωρίς να έχει λυθεί το αρχικό πρόβλημα.
Ένα ακόμη συχνό λάθος είναι η πραγματοποίηση πολλών ανεξάρτητων αλλαγών στο ίδιο maintenance window. Όταν παρουσιαστεί πρόβλημα, γίνεται δύσκολο να προσδιοριστεί ποια μεταβολή το προκάλεσε.
Η μη ρεαλιστική εκτίμηση χρόνου, η απουσία application owner, το μη δοκιμασμένο rollback και η ενημέρωση των χρηστών την τελευταία στιγμή αποτελούν επίσης ενδείξεις ανώριμης διαδικασίας.
Το πιο σοβαρό anti-pattern, όμως, είναι η δημιουργία μιας κουλτούρας στην οποία οι άνθρωποι αποκρύπτουν μικρές αλλαγές για να αποφύγουν τη διαδικασία. Όταν το Change Management γίνεται τόσο βαρύ ώστε οι engineers προσπαθούν να το παρακάμψουν, η λύση δεν είναι περισσότερος έλεγχος. Είναι ο επανασχεδιασμός της διαδικασίας ώστε το επίπεδο διακυβέρνησης να αντιστοιχεί στο πραγματικό ρίσκο.
Η ανθρώπινη πλευρά της αλλαγής
Μια αλλαγή μπορεί να είναι τεχνικά άρτια και να αποτύχει επειδή οι άνθρωποι δεν ήταν έτοιμοι να τη χρησιμοποιήσουν.
Η εισαγωγή ενός νέου εργαλείου, μιας διαφορετικής διαδικασίας αυθεντικοποίησης ή ενός νέου τρόπου εργασίας επηρεάζει καθημερινές συνήθειες. Οι χρήστες μπορεί να μη γνωρίζουν γιατί γίνεται η αλλαγή, να φοβούνται ότι θα δυσκολέψει την εργασία τους ή να μην έχουν λάβει την κατάλληλη εκπαίδευση.
Σε αυτές τις περιπτώσεις, το IT Change Management συναντά το Organizational Change Management.
Η τεχνική ομάδα πρέπει να συνεργάζεται με τους business owners, την εκπαίδευση, την εσωτερική επικοινωνία και το support. Η επιτυχία δεν μετριέται μόνο από το αν το νέο σύστημα είναι διαθέσιμο. Μετριέται και από το αν οι άνθρωποι μπορούν να το χρησιμοποιήσουν σωστά, αν γνωρίζουν πού θα βρουν βοήθεια και αν η αλλαγή προσφέρει το υποσχόμενο όφελος.
Η τεχνολογία αποτελεί μόνο το μισό της εξίσωσης. Το άλλο μισό είναι η υιοθέτηση.
Change Management ως μηχανισμός εμπιστοσύνης
Μια καλά σχεδιασμένη διαδικασία αλλαγών δημιουργεί εμπιστοσύνη.
Οι τεχνικές ομάδες γνωρίζουν ότι οι σημαντικές αποφάσεις θα αξιολογηθούν, ότι θα υπάρχει χρόνος για testing και ότι δεν θα κληθούν να εφαρμόσουν αλλαγές χωρίς επαρκή προετοιμασία.
Οι χρήστες γνωρίζουν ότι οι προγραμματισμένες διακοπές θα ανακοινωθούν και ότι θα υπάρχει υποστήριξη όταν κάτι αλλάζει.
Η διοίκηση γνωρίζει ότι το ρίσκο δεν αγνοείται και ότι οι σημαντικές αλλαγές συνδέονται με επιχειρησιακές προτεραιότητες.
Η εμπιστοσύνη αυτή δεν δημιουργείται από περισσότερα forms. Δημιουργείται όταν η διαδικασία είναι συνεπής, αναλογική και διαφανής.
Τελικές σκέψεις
Το Change Management δεν έχει στόχο να αποτρέψει την αλλαγή. Έχει στόχο να επιτρέψει την αλλαγή χωρίς να μετατρέψει κάθε βελτίωση σε πιθανό incident.
Οι καλύτερες διαδικασίες δεν είναι εκείνες που απαιτούν τις περισσότερες εγκρίσεις. Είναι εκείνες που βοηθούν την ομάδα να κατανοήσει το ρίσκο, να προετοιμάσει τις εξαρτήσεις, να εφαρμόσει την αλλαγή με συνέπεια και να επιβεβαιώσει ότι το επιχειρησιακό αποτέλεσμα είναι σωστό.
Η τεχνική υλοποίηση παραμένει σημαντική, αλλά δεν αποτελεί ολόκληρη την εικόνα. Χρειάζονται σαφής ιδιοκτησία, ρεαλιστικό testing, πρακτικό rollback, σωστή επικοινωνία και παρακολούθηση μετά την εφαρμογή.
Μια αλλαγή θεωρείται επιτυχημένη όταν δεν χρειάζεται να εξηγηθεί ως «τεχνικά ολοκληρωμένη, αλλά με ορισμένα προβλήματα». Θεωρείται επιτυχημένη όταν επιτυγχάνει τον σκοπό της, προστατεύει τη λειτουργία και αφήνει την ομάδα με περισσότερη γνώση από όση είχε πριν.
Αυτό είναι το πραγματικό νόημα του Change Management στο IT. Δεν είναι η διαχείριση των tickets της αλλαγής. Είναι η διαχείριση της αβεβαιότητας που συνοδεύει κάθε αλλαγή.