H διαθεσιμότητα υπάρχει στο λεξιλόγιό μας, στις μετρήσεις και στους στόχους μας. Υπάρχει στις απαιτήσεις της διοίκησης, δίνεται και ως buzz word “πέντε εννιάρια” (99,999%) αλλά τι ακριβώς μετράμε και τι θα έπρεπε να μετράμε?
Στις περισσότερες περιπτώσεις μετράμε τη διαθεσιμότητα βάση του χρόνου που το σύστημα ήταν εκτός λειτουργίας μέσα στο συνολικό χρόνο ενός έτους (αφαιρώντας τη μη διαθεσιμότητα λόγω προγραμματισμένων εργασιών). Ακούγεται λογικό, ίσως είναι ένας καλός τρόπος να ξεκινήσεις, σίγουρα δεν είναι σωστό.
Καταρχήν χρειαζόμαστε τη διαθεσιμότητα της υπηρεσίας. Θα πρέπει πάντα να σκεφτόμαστε τις επιχειρησιακές και επιχειρηματικές λειτουργίες. Η διαθεσιμότητα των επιμέρους συστατικών μιας υπηρεσίας (για παράδειγμα server, εφαρμογή) σίγουρα μας ενδιαφέρει και πρέπει να κρατάμε την πληροφορία αλλά αυτό που έχει σημασία είναι αν ο τελικός αποδέκτης είχε την υπηρεσία όταν την ήθελε η όχι.
Θα πρέπει λοιπόν καταρχήν να μετράμε τη διαθεσιμότητα όχι (ή όχι μόνο) στο σύνολο του χρόνου αλλά στον παραγωγικό χρόνο. Για παράδειγμα αν μια υπηρεσία χρησιμοποιείται μόνο εργάσιμες μέρες και ώρες μας ενδιαφέρει η διαθεσιμότητα μέσα σ’ αυτό το διάστημα.
Θα πρέπει να ξέρουμε τις περιόδους αυξημένης ζήτησης και να έχουμε μια ειδική, εστιασμένη μέτρηση για αυτές τις περιόδους. Με απλά λόγια, η υπηρεσία ήταν διαθέσιμη όταν η επιχείρηση την είχε μεγαλύτερη ανάγκη? Υπάρχουν περιπτώσεις που ο στόχος ως ποσοστό πιάνεται αλλά η υπηρεσία δεν ήταν διαθέσιμη, όταν για παράδειγμα λόγω αυξημένης ζήτησης το σύστημα βγήκε εκτός λειτουργίας.
Το business impact θα πρέπει να συνυπολογίζεται. Για να το πάω και ένα βήμα παρακάτω, θα πρέπει να αξιολογήσετε και τη βαρύτητα που έχουν διαφορετικοί αποδέκτες της υπηρεσίας. Κάποιοι κάνουν μεγαλύτερη χρήση σε όγκο, άλλοι έχουν μεγαλύτερη εξάρτηση γιατί αποτελεί κομμάτι μιας επόμενης διεργασίας, άλλοι είναι πιο σημαντικοί λόγω θέσης ή προβολής. Θα πρέπει να αναγνωρίσετε όλες τις διαφορετικές ανάγκες και να αποδώσετε βαρύτητες ώστε η μέτρηση της διαθεσιμότητας να αντικατοπτρίζει την εικόνα που έχουν οι πελάτες μας για την υπηρεσία που τους δίνουμε.
Το DevOps έχει μπει στο λεξιλόγιο της Πληροφορικής τα τελευταία 3-4 χρόνια και καθώς αναφέρεται συχνά σε συζητήσεις, σε blogs και σε συνέδρια πιστεύω πως αξίζει να το συζητήσουμε και να δούμε και τη σύνδεσή του με το IT Service Management.
Η αλήθεια είναι πως δύσκολα θα βρείτε ορισμούς, ακόμα και από το «νονό» του DevOps τον Patrick Debois, ενώ αρκετοί από αυτούς που βρήκα είναι άστοχοι.
Στη Wikipedia για παράδειγμα ορίζεται ως μέθοδος ανάπτυξης λογισμικού:
«DevOps (a portmanteau of “development” and “operations”) is a software development method that stresses communication, collaboration and integration between software developers and Information Technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations».
O Patrick Debois το αποκαλεί κίνημα (movement), ενώ ο Rob England το χαρακτηρίζει φιλοσοφία. Η ουσία που μας ενδιαφέρει είναι πως, το DevOps πρεσβεύει τη στενή συνεργασία μεταξύ των τμημάτων που αναπτύσσουν εφαρμογές (development) με τα τμήματα που είναι επιφορτισμένα με τη λειτουργία υποδομών και εφαρμογών (operations). Στόχος του είναι να ενισχύσει την ευέλικτη ανάπτυξης της πληροφορικής (πείτε το και agile…) τις σταθερότερες υπηρεσίες και τη δυνατότητα για συχνότερες αλλαγές.
Πιστεύω πως βλέπετε ήδη κοινά σημεία με το IT Service Management. Θα τόνιζα εδώ τα οφέλη από την ενίσχυση της ομαδικότητας και διάχυσης της γνώσης, που επιταχύνεται όταν υπάρχει ευρεία συμμετοχή ειδικοτήτων σε μια ομάδα εργασίας. Επίσης η ευρύτερη συμμετοχή ειδικοτήτων ενισχύει την κουλτούρα συνεχούς βελτίωσης, ειδικότερα στο να μαθαίνουμε από τα λάθη μας. Όσο πιο άνετη και ανοιχτή γίνεται μια ομάδα στο να παραδέχεται και να αναλύει τα λάθη της τόσο πιο γρήγορα βρίσκει τρόπους να τα διορθώσει και κυρίως να αποτρέψει την επανάληψή τους. Αν η πρακτική αυτή γίνεται και σε μικρούς σύντομους κύκλους (προσέγγιση scrum) τότε θα βλέπουμε συνεχή βελτίωση σε fast forward.
Με αφορμή τα δημοφιλή πλέον σε όλους Capital Controls σκέφτηκα να σας πω μερικά πράγματα για την προσέγγιση του ITSM στα οικονομικά. Αναφορά στη Χρηματοοικονομική Διαχείριση (Financial Management) λοιπόν, το οποίο είναι και από τα απαιτούμενα για το ISO 20000.
Στην αγορά της Πληροφορικής και των Τηλεπικοινωνιών η απαίτηση για παροχή λύσεων και υπηρεσιών στον ελάχιστο χρόνο και με το μικρότερο κόστος γίνεται όλο και πιο επιτακτική.
Πελάτες και πάροχοι είναι αναγκασμένοι να μελετούν την επιχειρηματική σκοπιμότητα (Business Cases) ώστε να δικαιολογήσουν επαρκώς το κόστος των νέων ή τροποποιημένων υπηρεσιών που ζητούν ή προσφέρουν αντίστοιχα.
Το Financial Management περιλαμβάνει υπολογισμούς όπως για παράδειγμα η Απόδοση των Επενδύσεων (Return on Investment), ο Εσωτερικός Βαθμός Απόδοσης (Internal Rate of Return), καθώς και βοήθεια για την εκτίμηση της συνολικής αξίας της επένδυσης. Αυτό όμως που αρκεί να θυμάστε είναι η εφαρμογή 3 διεργασιών:
Accounting
Οι παραγγελίες και τα έξοδα (αγορές, ενοικιάσεις, αναλώσεις) πρέπει να καταγράφονται αναλυτικά.
Η λεπτομέρεια στην καταγραφή θα μας βοηθήσει να συνθέσουμε ένα ακριβές μοντέλο κόστους και
θα μας επιτρέπει να κατανοήσουμε και να υπολογίζουμε την επίδραση, από οικονομικής άποψης, των νέων ή τροποποιημένων υπηρεσιών.
Budgeting
Η καλή μέρα από το πρωί φαίνεται ! Η διαδικασία κατάρτισης του προϋπολογισμού επιτρέπει την πρόβλεψη και τον έλεγχο της κατανομής των πόρων στην οργάνωση. Ο προϋπολογισμός είναι η πρόβλεψη “Τι χρήματα θα διατεθούν” και με τη λογιστική παρακολουθούμε “Πού πήγαν αυτά τα χρήματα”.
Charging
Ο τιμοκατάλογος των υπηρεσιών πρέπει να είναι σαφής, συνοπτικός και επικοινωνημένος ώστε να μην υπάρχουν αμφισβητήσεις στις χρεώσεις. Για το εσωτερικό του οργανισμού μπορείτε να εφαρμόσετε εικονικές χρεώσεις ώστε να υπάρχει η αίσθηση της αξίας και μεγαλύτερη εκτίμηση για τις υπηρεσίες που παρέχονται.
Μαζί με την επεξεργασία αριθμών να θυμάστε το ABC (Accounting, Budgeting, Charging), φροντίστε για την εφαρμογή του και είστε στο σωστό δρόμο για πετυχημένο Financial Management.
Εν μέσω μίας μεγάλης κρίσης και ανάμεικτων συναισθημάτων από την επίτευξη της συμφωνίας με τους ευρωπαίους εταίρους, θα ήθελα να μοιραστώ μαζί σας μερικές σκέψεις.
Αυτό που μας χρεώνουν είναι η άρνηση, όλα αυτά τα χρόνια, να προχωρήσουμε σε αναγκαίες μεταρρυθμίσεις. Οι μεταρρυθμίσεις χρειάζονται πρωτίστως στο Δημόσιο αλλά όχι μόνο. Αν θέλουμε πραγματικά να αποδώσουν και να δούμε ανάπτυξη θα πρέπει να υλοποιηθούν μεταρρυθμίσεις απ’ όλους τους συμμετέχοντες στην παραγωγική διαδικασία.
Ενώ η βιομηχανία και η πρωτογενής παραγωγή στη χώρα μας βρίσκονται σε εξαιρετικά χαμηλά επίπεδα, στην Ελλάδα δραστηριοποιούνται 850.000 Μικρό-Μεσαίες Επιχειρήσεις (άρα στην μεταποίηση και στις υπηρεσίες) προσφέροντας το 87% της συνολικής απασχόλησης.
Συμπερασματικά θα πρέπει να στηριχθούμε σ’ αυτές τις Μικρό-Μεσαίες Επιχειρήσεις για την ανάπτυξη. Έχοντας ως απτό παράδειγμα χώρες πολύ μικρότερες από εμάς που καταφέρνουν να ευημερούν στον τομέα των υπηρεσιών, είμαι πεπεισμένος πως μπορούμε εύκολα και γρήγορα να πετύχουμε ακόμα και καλύτερα αποτελέσματα. Διαθέτουμε ανθρώπινο δυναμικό με ιδιαίτερα υψηλό επίπεδο σε γνώσεις και ικανότητες.
Το απαραίτητο όμως είναι, να καταλάβουν οι Επιχειρήσεις την ανάγκη και τη χρησιμότητα των μεταρρυθμίσεων και να δεσμευτούν στην υλοποίησή τους, με στόχο την παροχή υψηλού επιπέδου υπηρεσιών χωρίς ιδιαίτερους περιορισμούς σε γεωγραφικά όρια.
Ο καλύτερος τρόπος να προχωρήσετε με τις μεταρρυθμίσεις είναι η εφαρμογή IT Service Management το οποίο έχοντας μια προσέγγιση με επίκεντρο τον πελάτη και βασισμένη στη δημιουργία αξίας τόσο για τον τελικό χρήστη, όσο και για την ίδια την επιχείρηση αποτελεί τη βάση για τη δημιουργία υγιούς επιχειρηματικότητας εστιασμένης στη δημιουργικότητα, την καινοτομία, την παραγωγική διαδικασία και τη γνώση, ενώ παράλληλα προωθεί μια κουλτούρα διαρκούς βελτίωσης.
Το ιδανικό βέβαια σενάριο είναι πιστοποιήσετε και να πείσετε εαυτούς και αλλήλους (εντός και εκτός συνόρων) για την αξιοπιστία και την οργάνωσή σας, με ένα ISO 20000.
Όλοι συμφωνούμε πως πρέπει τα πράγματα να αλλάξουν και είναι πιστεύω η κατάλληλη στιγμή, αρκεί όλοι να αποφασίσουμε να δράσουμε.
Η Επιχειρηματική κ Επιχειρησιακή Συνέχεια (Business Continuity Management) έχει εξαιρετικό ενδιαφέρον και ακόμα περισσότερο η μελέτη, η σχεδίαση και η υλοποίηση ενός πλάνου ενεργειών, που θα παρέχουν τη δυνατότητα η Επιχείρηση να δουλεύει ακόμα και μετά από καταστροφικά συμβάντα. Καθώς οι υπηρεσίες εξαρτώνται ολοένα και περισσότερο από την τεχνολογία, η Συνέχεια των Υπηρεσιών Πληροφορικής και Τηλεπικοινωνιών αποκτά αυξανόμενη σημαντικότητα, ενώ αποτελεί και απαίτηση κανονιστικών πλαισίων, όπως για παράδειγμα αυτό των Τραπεζικών οργανισμών.
Το ITIL τοποθετεί το ΙΤ Service Continuity Management (ITSCM) στον κύκλο ζωής του Service Design. Κατά τη φάση του σχεδιασμού μιας υπηρεσίας θα πρέπει καταγράψουμε τις απαιτήσεις των πελατών για τη διαθεσιμότητα της και τις επιπτώσεις (Impact) όταν αυτή δε λειτουργεί.
Το Business Impact Analysis (BIA) θα πρέπει να μας δώσει:
- Τον τύπο της επίπτωσης (απώλεια εσόδων, κόστος, φήμη, ασφάλεια, μη συμμόρφωση κλπ);
- Το πόσο αντέχει ο οργανισμός χωρίς τη συγκεκριμένη υπηρεσία;
- Το ελάχιστο επίπεδο στο οποίο μπορεί να επανέλθει η υπηρεσία και για πόσο χρόνο;
- Το μέγιστο χρόνο για πλήρη αποκατάσταση της υπηρεσίας
Συνήθως δημιουργούμε ένα γράφημα Επιπτώσεων προς χρόνο (Impact versus Time) το οποίο το έχουμε και ως οδηγό για το Σχέδιο Ανάκαμψης που θα δημιουργήσουμε. Για παράδειγμα αν οι επιπτώσεις είναι πολύ μεγάλες σε πολύ σύντομο χρονικό διάστημα θα πρέπει να επικεντρωθούμε στα προληπτικά μέτρα (preventive measures). Τα μέτρα θα προκύψουν μετά την ανάλυση των κινδύνων ώστε να είναι συγκεκριμένα και ιεραρχημένα.
Το Σχέδιο Ανάκαμψης θα περιλαμβάνει και τον ή τους τρόπους ανάκαμψης που έχουμε:
- Manual, για παράδειγμα να συμπληρώσουμε με το χέρι μια φόρμα ή απόδειξη
- Reciprocal, όταν υπάρχει συμφωνία με έναν τρίτο οργανισμό να καλύψει την υπηρεσία
- Gradual, η σταδιακή επαναφορά μέρους της υπηρεσίας με μέσο η μακροπρόθεσμο χρονικό ορίζοντα
- Intermediate, βραχυπρόθεσμη αποκατάσταση της υπηρεσίας με χρήση ενναλακτικών εγκαταστάσεων και ημιαυτόματη μεταγωγή των υπηρεσιών
- Fast, Αποκατάσταση εντός ωρών
- Immediate, καμία απώλεια της υπηρεσίας
Είναι δυστυχώς συχνό φαινόμενο με το που παραδίδεται σε λειτουργία ένα νέο ή βελτιωμένο σύστημα, δίκτυο ή υπηρεσία, να παρουσιάζονται θέματα και δυσλειτουργίες που οδηγούν σε πολύωρες ή και πολυήμερες διακοπές της διαθεσιμότητας.
Έχοντας συζητήσει με συναδέλφους αρκετές τέτοιες περιπτώσεις συμπεραίνω πως σπάνια η τεχνολογία είναι το πρόβλημα. Σχεδόν σε όλες τις περιπτώσεις υπάρχει το απλό λάθος του να θεωρούμε πως κάτι δουλεύει, επειδή μας το έχει αναφέρει ο συνεργάτης ή ο προμηθευτής, και έτσι να μην το τεστάρουμε διεξοδικά. Συνιστώ λοιπόν την εξής προσέγγιση:
Αντιμετωπίστε κάθε περίπτωση ως μοναδική και νέα και ακολουθήστε όσα περιγράφει το ITIL στο lifecycle «Service Transition».
Δώστε ιδιαίτερη σημασία στο integration τόσο του Hardware όσο και του Software. Για παράδειγμα το compatibility της έκδοσης της εφαρμογής με την έκδοση του λειτουργικού και των άλλων εφαρμογών ή το compatibility καρτών δικτύου με το SAN switch.
Βεβαιωθείτε ότι εξοπλισμός, εφαρμογές, security, άνθρωποι, άδειες, διαδικασίες είναι σύμφωνα με το design και συμβαδίζουν με την εγκεκριμένη αρχιτεκτονική.
Αφιερώστε χρόνο σε πιλοτική λειτουργία σε όσο το δυνατόν πιο αντιπροσωπευτικές, με το πραγματικό περιβάλλον, συνθήκες (για παράδειγμα φόρτος δεδομένων ή transactions) και σχεδιάστε με λεπτομέρεια το πλάνο μετάπτωσης στην προηγούμενη κατάσταση αν κάτι πάει στραβά. Αν εμπλέκονται υπηρεσίες τρίτων φροντίστε να τους ενημερώσετε και να βεβαιωθείτε πως δεν θα κάνουν ενέργειες που πιθανά να επηρεάζουν το έργο σας.
Το πλάνο του release and deployment θα πρέπει να φροντίζει για τον ελάχιστο αντίκτυπο στην λειτουργία του οργανισμού (ωράρια λειτουργίας, περιόδους αιχμής), να έχει φροντίσει για την κατάλληλη εκπαίδευση του προσωπικού που θα υποστηρίξει το νέο ή βελτιωμένο σύστημα, δίκτυο ή υπηρεσία και να έχει ενημερώσει όλους τους εμπλεκόμενους όπως χρήστες, διαχειριστές συστημάτων, HelpDesk ή Service Desk κλπ. Επίσης ορίστε σημεία στα οποία κατά τη διάρκεια του deployment θα αξιολογείτε, με βάση συμφωνημένα κριτήρια, την πρόοδο και τη σωστή συμπεριφορά των συστημάτων και θα αποφασίζετε αν «προχωράμε ή γυρίζουμε πίσω».
Η Διαχείρισης Δυναμικότητας (Capacity Management) έχει ως στόχο τη δημιουργία ενός οργανισμού ικανού να εξασφαλίσει τις υποδομές και τους απαιτούμενους πόρους ώστε να καλύπτονται οι τρέχουσες και οι μελλοντικές απαιτήσεις υπηρεσιών προς τις επιχειρήσεις, διασφαλίζοντας παράλληλα ότι όλοι οι πόροι αποκτούνται, παρέχονται και διαχειρίζονται με το αποδοτικότερο τρόπο.
H Διαχείριση της Δυναμικότητας πρέπει να καλύπτει τρία επίπεδα:
- Resources, διαχείριση της χρήσης και της απόδοσης των επιμέρους πόρων όπως servers, telecom lines, Virtual Machines, εκτυπωτές, αλλά και των επιμέρους συστατικών που επηρεάζουν την απόδοση όπως για παράδειγμα CPU, μνήμη, bandwidth, IOPS κλπ.
- Service, στο επίπεδο αυτό εξετάζουμε το σύνολο των συστημάτων που συνεργάζονται για την παροχή μιας υπηρεσίας, διαχειριζόμαστε τις ανάγκες της υπηρεσίας σε πόρους και την κάλυψη των αναγκών των χρηστών της υπηρεσίας. Για παράδειγμα η προσθήκη ή η αφαίρεση servers ή bandwidth ανάλογα με την αυξομείωση του αριθμού των χρηστών μιας υπηρεσίας μέσα στο χρόνο.
- Business, το υψηλότερο επίπεδο όπου χρειαζόμαστε κυρίως τις μελλοντικές επιχειρηματικές ανάγκες, τον στρατηγικό σχεδιασμό του οργανισμού και τις προβλέψεις για τον αριθμό των πελατών ανα υπηρεσία.
Για να πετύχει το Capacity Management σε κάθε επίπεδο χρειάζεται:
- Συνεχής Επιτήρηση της ζήτησης και σύνδεσή της με τις προβλέψεις και την τρέχουσα δυναμικότητα.
- Ανάλυση όλων των δεδομένων φόρτου, κίνησης, επιδόσεων, αιτημάτων και παραπόνων ώστε να κατανοήσετε και να προβλέψετε την ανάγκη σε πόρους.
- Επιτήρηση Επιδόσεων, θα χρειαστείτε ένα καλό και αξιόπιστο εργαλείο monitoring για συστήματα και υπηρεσίες σε σχέση με τα SLAs. Επενδύστε χρόνο στον ορισμό και το fine tuning των thresholds ώστε να εντοπίζετε εγκαίρως σημεία που πρέπει να επέμβετε και τις διακυμάνσεις στην απόδοση.
- Πρόβλεψη. Δημιουργήστε ένα ετήσιο Capacity Plan σαν πρώτο βήμα δείξτε σε απλή μορφή την ετήσια διακύμανση της ζήτησης σε σχέση με τους υφιστάμενους πόρους. Στον επόμενο κύκλο εμπλουτίστε το με τις προβλέψεις του business και τo επίπεδο των SLAs.
Σε συνέχεια του προηγούμενου άρθρου, μεταφέρω σήμερα μερικές ακόμα σκέψεις και απόψεις γύρω από την εφαρμογή του Incident Management.
- Μην ακολουθείτε τυφλά τις καλές πρακτικές των μεθοδολογιών. Κάθε οργανισμός είναι μοναδικός, χρησιμοποιήστε το ITIL ως πολύτιμο σύμβουλο και οδηγό αλλά προσαρμόστε την διαδικασία πάνω στις ιδιαιτερότητες του περιβάλλοντος σας (για παράδειγμα μέγεθος οργανισμού, κανονιστικό πλαίσιο) πριν την εφαρμόσετε. Στην περίπτωση επιλογής off-the-shelf εργαλείων, θα πρέπει να είσαστε ιδιαίτερα προσεκτικοί ώστε να καλύπτουν τις δικές σας ανάγκες.
- Ανθρώπινο Δυναμικό. Χρειάζεστε προσωπικό με τις κατάλληλες γνώσεις και εμπειρία και τη δημιουργία ομαδικότητας για την αντιμετώπιση σύνθετων περιστατικών. Μια καλή ομάδα μπορεί να καλύψει τις αδυναμίες της διαδικασίας αλλά, δυστυχώς, ακόμα και η τέλεια διαδικασία θα είναι αναποτελεσματική αν έχετε λάθος ή ανεκπαίδευτους ανθρώπους.
- Δείκτες Επιδόσεων.
Οι δείκτες επιδόσεων (KPIs) είναι απαραίτητοι και θα σας βοηθήσουν να βελτιώσετε τη διαδικασία, φροντίστε όμως οι πληροφορίες να συλλέγονται με εύκολο και όσο το δυνατόν πιο αυτοματοποιημένο τρόπο ώστε να μην αποτελούν εμπόδιο και μείνουν αχρησιμοποίητοι.
- Ο ρόλος του Incident Management είναι κομβικός. Αναγνωρίστε τον ώστε να του δώσετε την απαιτούμενη σημασία αλλά και να τον εκμεταλλευτείτε κατάλληλα. Ο χρόνος επίλυσης των περιστατικών για παράδειγμα, έχει άμεση σχέση με την παραγωγικότητα και το κόστος, ενώ η σωστή κατηγοριοποίηση των βλαβών θα σας οδηγήσει σε εστιασμένες ενέργειες βελτίωσης της τεχνολογίας, εισαγωγής αυτοματισμών και εκπαίδευσης των χρηστών.
- Φροντίστε την «βιτρίνα» του οργανισμού σας. Το Incident Management (μαζί με το Service Desk) αποτελεί από τα σημεία της συχνότερης επαφής του business με το ΙΤ. Πέρα από τη διατήρηση της διαθεσιμότητάς και της παραγωγικότητας, επηρεάζει την καθημερινή σας αξιολόγηση από εσωτερικούς και εξωτερικούς πελάτες. Φροντίστε το λοιπόν ανάλογα και χρησιμοποιήστε το ως εργαλείο marketing.
Είμαι βέβαιος πως από την εμπειρία μπορείτε να συμπληρώσετε την παραπάνω λίστα, περιμένω λοιπόν τις δικές σας σκέψεις και απόψεις.
Το Incident Management, είναι ίσως η πιο γνωστή διαδικασία του ITIL και προ απαιτούμενη για κάθε εφαρμογή IT Service Management (ITSM) ή ISO 20000. Με αφορμή μια διαδικτυακή συζήτηση, στην οποία συμμετείχα, θα ήθελα να σας μεταφέρω μερικές ουσιαστικές σκέψεις και απόψεις που διατυπώθηκαν.
- Σκεφτείτε για ποιο λόγο θέλετε να εφαρμόσετε Incident Management.Η απάντηση «για να αντιμετωπίζονται οι βλάβες των συστημάτων» δεν είναι επαρκής. Θα πρέπει πέρα από την υποδομή και την τεχνολογία και να γίνει κατανοητό πως μιλάμε για την υποστήριξη της επιχειρηματικής λειτουργίας και των χρηστών (άνθρωποι οι οποίοι υποστηρίζουν ανθρώπους).
- Μη ξεκινάτε με το Incident Management επειδή είναι γνωστό ή γιατί φαίνεται μια καλή αφετηρία. Ίσως μια άλλη διαδικασία να είναι πιο αναγκαία (πχ change management). Βεβαιωθείτε επίσης πως θα αλλάξετε και θα ενισχύσετε την τρέχουσα διαδικασία στην ουσία της και στον τρόπο που αντιμετωπίζετε τους χρήστες και όχι μόνο στον έλεγχο και στη γραφειοκρατία.
- Δείτε την υπηρεσία πέρα από τη διαδικασία. Πάντα μιλάμε για υπηρεσίες προς πελάτες. Είναι σημαντικό να αντιμετωπίζουμε ως πελάτες ακόμα και εσωτερικούς χρήστες αλλά και συναδέλφους. Θα πρέπει επίσης, να κατανοήσουμε τι σημαίνει Incident για τον τελικό χρήστη και πόσο επιχειρηματικά κρίσιμο μπορεί να είναι ακόμα και ένα PC ή ένας εκτυπωτής λόγω ρόλου (πχ εκτύπωση καρτών επιβίβασης την ώρα αιχμής), χρονικής στιγμής (πχ υποβολή προσφορών σε διαγωνισμό), η περιόδου (πχ κλείσιμο ισολογισμού).
- Επιλέξτε αν θα προσεγγίσετε το Incident Management την πλευρά της προσφοράς ή της ζήτησης. Φαινομενικά ταυτόσημο και όμως τόσο διαφορετικό. Η πλευρά της προσφοράς (supply side) βασίζεται σε πρακτικές της αγοράς και στο τι κάνει ο ανταγωνισμός. Η πλευρά της ζήτησης (demand side) προσαρμόζεται στις επιχειρηματικές και επιχειρησιακές ανάγκες του πελάτη. Για παράδειγμα η υποστήριξη 9πμ-5μμ μπορεί να είναι καλή πρακτική, αλλά να μην εξυπηρετεί ένα εργοστάσιο που δουλεύει 7πμ-7μμ.
Μερικές ακόμα απόψεις θα σας μεταφέρω στο επόμενο άρθρο.
Η εφαρμογή ενός προγράμματος IT Service Management (ITSM) σίγουρα δεν είναι απλή υπόθεση, υπάρχουν όμως μερικά απλά σημεία που θα βοηθήσουν την προσπάθειά σας.
- Ενεργή Συμμετοχή, όλων όσους αφορά η κάθε διεργασία (process), χρήστες, πελάτες, τεχνικούς, διαχειριστές από την αρχή. Συζητήστε τις αλλαγές από την υπάρχουσα κατάσταση πριν την εφαρμογή της διεργασίας και βεβαιωθείτε πως είναι κατανοητή απ’ όλους.
- Τεκμηρίωση, κάθε διεργασία να είναι γραμμένη και τόσο απλά ώστε είναι κατανοητή ακόμα και από άτομα που την διαβάζουν για πρώτη φορά. Χρησιμοποιήστε απλά διαγράμματα που συνοδεύονται από επεξηγηματικό κείμενο για κάθε βήμα της διεργασίας.
- Σαφείς ρόλοι, περιγράψτε με απλά λόγια τις αρμοδιότητες, τα όρια των ενεργειών, και την επικοινωνία που απαιτείται σε κάθε περίπτωση. Είναι χρήσιμο να κάνετε πρόβες και δοκιμές ώστε να υπάρχει πλήρης κατανόηση.
- Μικρά και σταθερά βήματα, μην επιχειρήσετε να εφαρμόσετε όλες τις διεργασίες μαζί την ίδια στιγμή. Προχωρήστε στη σταδιακή υλοποίηση, με περίοδο δοκιμαστικής εφαρμογής ώστε να προσαρμοστούν όλοι και να έχετε χρόνο για απαιτούμενες μικροδιορθώσεις.
- Μην χαλαρώνετε, ορίστε έναν υπεύθυνο (process owner) για κάθε διεργασία, ο οποίος θα έχει και την ευθύνη για την λειτουργία της, την αξιολόγηση των ανθρώπων και της ίδιας της διεργασίας, τις αλλαγές και τις βελτιώσεις.
- Επικοινωνία, ο ακρογωνιαίος λίθος για την επιτυχή εφαρμογή των διεργασιών είναι η συνεχής και τακτική επικοινωνία με όλους τους εμπλεκομένους ώστε να κατανοήσουν τι προσπαθούμε να πετύχουμε και τα προσδοκώμενα επιχειρησιακά και επιχειρηματικά οφέλη.
Από ποιο σημείο θα ξεκινήσετε εξαρτάται από το περιβάλλον σας και την ωριμότητα του οργανισμού. Μπορείτε να χρησιμοποιήσετε ως οδηγό το ISO 20000 και να καλύψετε τις διεργασίες που σας λείπουν σε σχέση με τις απαιτήσεις του προτύπου. Αν δεν υπάρχουν διεργασίες θα πρότεινα να ξεκινήσετε με τα Resolution Processes (Incident, Problem) και τα Control Processes (Change, Release & Deployment, Configuration).
