Ο μήνας πυρετού του Παγκόσμιου Κυπέλλου Ποδοσφαίρου έχει ολοκληρωθεί αλλά ας δούμε λίγο τα πράγματα μέσα από τον φακό της στρογγυλής Θεάς. Στα πλαίσια της στρατηγικής χαρτογράφησης υπηρεσιών, οι χώρες που δεν έχουν ιδιαίτερες δυνατότητες κατάκτησης του βαρύτιμου τροπαίου προτιμούν το «fair play», δεν εκφράζουν έντονα παράπονα όταν ηττούνται και προσπαθούν να κοντράρουν στα ίσα μεγάλους αντιπάλους. Τα φαβορί αγωνίζονται πάντα για τον πρωταθλητισμό.
Στον σχεδιασμό υπηρεσιών ο κατάλογος υπηρεσιών αφορά τον κατάλογο εμπορευμάτων και αναμνηστικών κάθε εθνικής ομάδας. Τα SLAs αφορούν το φίλαθλο κοινό που πρέπει να υποσχεθεί να μην επιτρέψει την απρεπή συμπεριφορά και τον χουλιγκανισμό, ενώ για τα OLAs οι διαιτητές οφείλουν να υποσχεθούν το ίδιο στους φιλάθλους. Η διαχείριση διαθεσιμότητας και χωρητικότητας καταπολεμά την «μαύρη αγορά» μη εξουσιοδοτημένων reseller εισιτηρίων. Το Information Security εκδίδει ανακοινώσεις προς τους φιλάθλους για να προσέχουν τα προσωπικά τους αντικείμενα ενώ η διαχείριση προμηθευτών συμβουλεύει το κοινό να μην αγοράζει απομιμήσεις εμπορευμάτων.
Στα πλαίσια μετάβασης υπηρεσιών, η διαχείριση αλλαγών αφορά την αλλαγή υποστηριζόμενης ομάδας όταν αυτή αποκλειστεί από την διοργάνωση ενώ το Configuration Management βοηθά στην εύκολη αναγνώριση και ταυτοποίηση φιλάθλων. Το Release Management αποσκοπεί στο «διασκεδάστε υπεύθυνα»! Η δοκιμαστική περίοδος υπηρεσίας δεν μπορεί να λείψει από μια παγκόσμια διοργάνωση και απαιτεί υπομονή και ευγνωμοσύνη στην διοργανώτρια χώρα. Όσο για την διαχείριση γνώσης, ο φίλαθλος κόσμος γνωρίζει καλύτερα.
Αναφορικά με τις λειτουργίες υπηρεσιών, η διαχείριση πρόσβασης φροντίζει ώστε να εισέρχονται στο γήπεδο φίλαθλοι με εισιτήρια. Όσοι δεν έχουν εισιτήριο, θα εκμεταλλευτούν τις εγκαταστάσεις της κοντινής μπυραρίας και μέσω Request Fulfillment θα ικανοποιηθούν τα αιτήματα τους για μια παγωμένη μπύρα. Κατά την διάρκεια της αναμέτρησης οι παίκτες δεν πρέπει να προσποιούνται τραυματισμούς (συμβάντα) και όταν οι ίδιοι παίκτες προσποιούνται συνεχώς τραυματισμούς τότε έχουμε πρόβλημα. Τα γεγονότα αφορούν φυσικά τα Γκολ!
Τέλος, η συνεχής βελτίωση υπηρεσίας αποσκοπεί στο ότι η Ελλάδα μπορεί να σκαρφαλώσει υψηλότερα από την 12η θέση που κατέχει στην παγκόσμια κατάταξη της FIFA.
Η Διαχείριση Διαμόρφωσης (Configuration Management) συνεχίζει να αποτελεί πεδίο έντονων συζητήσεων στην κοινότητα του IT Service Management και όχι άδικα.
Όλοι δηλώνουν πως αντιλαμβάνονται τη σημαντικότητα του Configuration Management και σχεδόν όλοι χρησιμοποιούν τη Βάση Δεδομένων Διαχείρισης Διαμόρφωσης (CMDB) ως ταυτόσημη έννοια.
Σε σχέση με τη CMDB, αρκετοί δηλώνουν πως έχουν σε εξέλιξη τη δημιουργία της, ελάχιστοι έχουν μια που να λειτουργεί, ενώ πολλοί δηλώνουν πως το έργο που είχαν απέτυχε για διάφορους λόγους με κυριότερο την έλλειψη υποστήριξης από την ανώτερη διεύθυνση.
Ο κίνδυνος όταν ερμηνεύουμε το Configuration Management ως CMDB είναι να μείνουμε στα στενά όρια της απλής καταγραφής των CIs, αλλοιώνοντας όμως έτσι το νόημα, την ευρύτητα και τη σημαντικότητα της έννοιας.
Το Configuration Management δεν είναι απλώς η καταγραφή των παγίων ενός οργανισμού. Έχει ως κύριο αντικείμενο να καταγράψει τις σχέσεις και εξαρτήσεις μεταξύ των στοιχείων (CIs) που αποτελούν κάθε υπηρεσία που παρέχει ο οργανισμός.
Στην δεδομένη και αυξανόμενη πολυπλοκότητα του περιβάλλοντος Πληροφορικής και Τηλεπικοινωνιών χρειαζόμαστε
Άμεση εικόνα των υπηρεσιών και υποδομών
Βελτίωση του προγραμματισμού της αλλαγής και αξιολόγηση του επιχειρηματικού κινδύνου
Υποστήριξη της διαχείρισης του κύκλου ζωής των πόρων ΙΤ
χρήση αδειών ελέγχου και συμμόρφωσης (compliance, audit)
Καταγραφή των οικονομικών στοιχείων για την κοστολόγηση και χρέωση
Ένα καλά σχεδιασμένο και ακριβή CMDB είναι ένα κρίσιμο μονοπάτι ανάμεσα σε IT Service Management, IT Operations και διαδικασίες IT Διακυβέρνηση στην υποστήριξη βασικών επιχειρηματικών δραστηριοτήτων.
Τα οφέλη για τον οργανισμό Πληροφορικής και τους εταίρους του αντικειμενικά ακολουθούν τις αρχές value chain economics
Ο κατάλογος υπηρεσιών αποτελεί αναπόσπαστο κομμάτι της παροχής υπηρεσιών του οργανισμού προσδοκώντας την αναμόρφωση του ρόλου του IT από technology-centric σε business value-centric.
Το Γλωσσάριο του ITILv3 ορίζει τον Κατάλογο Υπηρεσιών ως «βάση δεδομένων ή δομημένο έγγραφο που περιέχει πληροφορίες για όλες τις υπηρεσίες πληροφορικής και τηλεπικοινωνιών που βρίσκονται σε επιχειρησιακή λειτουργία, συμπεριλαμβανομένων όσων είναι διαθέσιµες προς υλοποίηση. Ο κατάλογος υπηρεσιών αποτελεί τµήµα του χαρτοφυλακίου υπηρεσιών και περιέχει πληροφορίες για δύο τύπους υπηρεσιών πληροφορικής και τηλεπικοινωνιών: τις υπηρεσίες πρώτης γραµµής που είναι ορατές στην επιχείρηση και τις υποστηρικτικές υπηρεσίες τις οποίες χρειάζεται ο πάροχος υπηρεσιών για την παροχή των υπηρεσιών πρώτης γραµµής». Ο ορισμός θα μπορούσε να αναπτυχθεί περαιτέρω διασπώντας τον κατάλογο σε δύο πτυχές το Customer/Business View με επιχειρηματικούς όρους και το Technical View σε τεχνικούς όρους.
Συνθέτοντας τον κατάλογο υπηρεσιών στοχεύουμε στην πλήρη κατανόηση του τι μπορεί και τι δεν μπορεί να εξυπηρετήσει το IT. Επιπρόσθετα, ο κατάλογος υπηρεσιών σήμερα, δεν μπορεί να χαρακτηρίζεται μόνο από καταγεγραμμένες επεξηγήσεις υπηρεσιών και αντίστοιχα SLAs αλλά να πλαισιώνεται με business process models που τηρούνται κατά την διαδικασία υλοποίησης, βάση των οποίων το IT και οι πελάτες λειτουργούν. Το πραγματικό governance επιτυγχάνεται όταν οι συνθήκες και οι έλεγχοι στον κατάλογο υπηρεσιών έχουν ήδη εφαρμογή στις διεργασίες παράδοσης υπηρεσιών του οργανισμού.
Κοιτάζοντας το customer-friendly κατάλογο υπηρεσιών, ο επιχειρηματικός πελάτης ενδιαφέρεται για τις υπηρεσίες που αξιοποιεί, το επίπεδο υποστήριξης που απολαμβάνει καθώς και την μείωση κόστους που αποφέρει το IT στις επιχειρηματικές δραστηριότητες του οργανισμού του. Από την άλλη πλευρά, ο τελικός χρήστης του πελάτη, εξετάζει τις υπηρεσίες που μπορεί να χρησιμοποιήσει, τι συμπεριλαμβάνει η κάθε υπηρεσία και ποιά η λειτουργικότητα της. Τέλος, το Service Management του πάροχου υπηρεσιών ως υπεύθυνο των κατάλογων, φροντίζει, σε συνεργασία και με το Marketing, να ανανεώνει συχνά τις παρεχόμενες υπηρεσίες, τα αντίστοιχα SLAs καθώς και τα μείζων μετρήσιμα σημεία ανά υπηρεσία.
Με απασχολεί αρκετά έντονα, όπως και αρκετούς φίλους της στήλης, το θέμα του Bring Your Own Device (BYOD) σε επιχειρηματικό και επιχειρησιακό επίπεδο.
Διαβάζω σε αρκετά άρθρα την αβασάνιστη, κατά την προσωπική μου άποψη, τοποθέτηση πως η υιοθέτηση του BYOD αυξάνει την παραγωγικότητα των εργαζομένων ή καθιστά έναν εργοδότη, πιο ευέλικτο, πιο ελκυστικό και πιο αποδοτικό.
Σίγουρα βρισκόμαστε σε μια εποχή που και η τεχνολογία εξελίσσεται ραγδαία αλλά και οι χρήστες, έχουν ξεπεράσει τις «φοβίες» τους με τους υπολογιστές. Όλο και περισσότεροι έχουν στη κατοχή τους laptop, smart-phone ή tablet (πολλές φορές και όλα μαζί) και η χρήση τους για πρόσβαση στο εταιρικό δίκτυο και στις εφαρμογές και δεδομένα προβάλλεται ολοένα και περισσότερο ως καλή ιδέα, ως ανάγκη ή και ως αναπόφευκτη πραγματικότητα.
Προσωπικά θεωρώ πως το ζητούμενο θα πρέπει να είναι η δημιουργία συνθηκών υποστήριξης της κινητικότητας (mobility) με ανάπτυξη υποδομών, μεθόδων, εργαλείων, εφαρμογών και αυτοματισμών, ώστε να υπάρχει η δυνατότητα πρόσβασης στις εφαρμογές και την πληροφορία στο σημείο, στη μορφή και τη στιγμή που την χρειάζονται οι εργαζόμενοι.
Η δημιουργία των κατάλληλων συνθηκών είναι αυτή που θα αυξήσει την παραγωγικότητα και την αποδοτικότητα και όχι το αν θα φέρει ο εργαζόμενος την προσωπική συσκευή του.
Η βεβιασμένη μάλιστα, υιοθέτηση του BYOD εγκυμονεί κυρίως κινδύνους ασφάλειας, αλλά επίσης θέματα κυριότητας εταιρικών πόρων, σε ορισμένες περιπτώσεις πνευματικής ιδιοκτησίας, ελλιπούς υποστήριξης και επιχειρηματικής συνέχειας.
Θα συνιστούσα, καταρχήν την προσεκτική δημιουργία των συνθηκών που αναφέραμε (συμπεριλαμβανομένων των πολιτικών και των διαδικασιών) και στη συνέχεια μια προσέγγιση ελεγχόμενης παροχής επιλεγμένων τεχνολογιών και συσκευών, Choose your Own Device (CYOD), όπου ο υπάλληλος θα έχει την επιλογή της προσωπικής του προτίμησης αλλά κυρίως ο οργανισμός θα διατηρεί τον έλεγχο, θα μπορεί να παρέχει υποστήριξη και θα εξασφαλίζει την απαιτούμενη ασφάλεια.
Στον κόσμο του IT, το να αναδεικνύουμε νέους τρόπους και συνδυασμούς σχεδιασμού και λειτουργιών υπηρεσιών έχει καταστεί σημαντικό κομμάτι της καθημερινότητας μας. Ένας συνδυασμός εξ αυτών, το DevOps, αφορά την μίξη της ανάπτυξης και υποστήριξης, καθόλη την διάρκεια του κύκλου ζωής της υπηρεσίας με μια agile προσέγγιση. Το DevOps έχει αγκαλιαστεί από την γενιά εταιριών όπως Google, Amazon, Flickr, LinkedIn και Facebook.
Η διαφορά του DevOps από το ITIL, επικεντρώνεται κυρίως, στους μικρότερους χρόνους της μετάβασης υπηρεσίας (service transition). Για παράδειγμα, ο μέσος χρόνος που απαιτείται από την παράδοση μιας νέας έκδοσης από την ομάδα ανάπτυξης μέχρι την υλοποίηση της υπολογίζεται στις έξι εβδομάδες, ανεξάρτητα του μεγέθους της έκδοσης και της ενημέρωσης παράδοσης προς το service management. Διάφορες αναλύσεις δείχνουν ότι με αυτήν την προσέγγιση υπάρχει μια συνεχής καθυστέρηση παραδοτέων. Τα αίτια σχετίζονται στον συνδυασμό διαδικασιών όπου χρειάζεται re-testing της υπηρεσίας που έχει ήδη ελεγχθεί από την ομάδα ανάπτυξης και υπάρχει αναμονή στην αποδοχή της αλλαγής από το Change Advisory Board. Το Flickr αναφέρει μέχρι και δέκα επιτυχώς υλοποιημένες εκδόσεις ανά ημέρα στην παραγωγή, χωρίς καμία έκδοση να έχει χαρακτηριστεί ως «επείγουσα». Αυτό μπορεί να χαρακτηριστεί ακραίο από οργανισμούς που διαθέτουν παραδοσιακούς μηχανισμούς έκδοσης υπηρεσιών.
Η προσέγγιση του DevOps, στοχεύει στην διαχείριση του κύκλου ζωής της υπηρεσίας από μια ιδία ομάδα ανθρώπων, αρχομένης από την συλλογή προδιαγραφών, σχεδιασμό, ανάπτυξη, testing, υλοποίηση μέχρι και υποστήριξη. Η ομάδα είναι επίσης υπεύθυνη για τις επιχειρηματικές σχέσεις με πελάτες καθώς και προμηθευτές. Αυτό που το DevOps απορρίπτει στις λειτουργίες του, είναι οι πολλαπλοί ρόλοι του service management, που απαιτούν απανωτά handovers από τον σχεδιασμό στην ανάπτυξη, από την ανάπτυξη στο testing, κ.ο.κ., που απαιτούν μηχανισμούς μεταφοράς τεχνογνωσίας με κίνδυνο να «χαθεί» γνώση.
Κάποιοι οργανισμοί ήδη λειτουργούν στην συνταγή του DevOps με ITIL, επιδιώκοντας να επωφεληθούν απο τις ώριμες βέλτιστες πρακτικές και την εμπειρία του ITIL σε συνδυασμό με την αναδυόμενη agile προσέγγιση του DevOps.
Πρέπει να ομολογήσω πως στην προσπάθειά μου να καλύψω μεγάλο μέρος των εννοιών και πρακτικών που μας οδηγούν στην εφαρμογή του IT Service Management, δεν τόνισα όσο θα έπρεπε τη σημασία της Διαχείρισης της Γνώσης με έμφαση στην ανανέωση της γνώσης.
Θα σας εξηγήσω τι εννοώ. Την προηγούμενη εβδομάδα φίλος CIO, με μεγάλη εμπειρία στο ITSM, μου μετέφερε την δυσάρεστη έκπληξη που είχε όταν ανακάλυψε πως έμπειρα και εκπαιδευμένα άτομα των ομάδων του μπέρδευαν έννοιες και διαδικασίες. Μου ανέφερε δύο χαρακτηριστικές περιπτώσεις: στην πρώτη ορισμένοι διαχειριστές συστημάτων ανέφεραν ως incident τις επαναλαμβανόμενες κλήσεις που είχαν από συγκεκριμένους χρήστες για δυσλειτουργία σε μια εφαρμογή. Στη δεύτερη περίπτωση ένας διαχειριστής δεύτερου επίπεδου υποστήριξης κατά τη διερεύνηση του root cause ενός incident ζήτησε από τεχνικούς του πρώτου επιπέδου υποστήριξης εργασίες για τις οποίες όμως λόγω γνώσεων και δικαιωμάτων πρόσβασης αυτοί έπρεπε να ζητήσουν από τους μηχανικούς του δευτέρου επιπέδου υποστήριξης.
Πριν βιαστούμε να βγάλουμε συμπεράσματα, να τονίσω πως τα άτομα και στις δύο περιπτώσεις ήταν εκπαιδευμένα, πιστοποιημένα στο αντικείμενό τους, έμπειρα, είχαν περάσει το ITIL Foundation, είχαν επίσης αλλάξει ρόλους και αρμοδιότητες μέσα στον οργανισμό τουλάχιστον 2 φορές τα τελευταία 5-6 χρόνια.
Παρόμοια περιστατικά θα βρείτε σε κάθε οργανισμό, σε μικρότερο η μεγαλύτερο εύρος. Η ύπαρξη των διαδικασιών δεν διασφαλίζει την απόλυτη και σωστή εφαρμογή τους και η όποια εκπαίδευση έχει γίνει δεν διασφαλίζει πως θα θυμόμαστε τα πάντα μετά από μερικά χρόνια. Θα πρέπει να φροντίζουμε σε τακτικά διαστήματα να φρεσκάρουμε τις γνώσεις των ανθρώπων μας στη θεωρία αλλά και στις διαδικασίες μας. Για επιλεκτικά θέματα πρέπει να χρησιμοποιούμε εκπαιδευτικά κέντρα η εξωτερικό επαγγελματία εισηγητή, αλλά τα περισσότερα θα συμβούλευα να γίνονται εσωτερικά με δικό μας «εισηγητή» σε μικρές ομάδες 3-4 ατόμων.
Η γνώση αποτελεί στρατηγικό πόρο και η διαχείρισή της περιλαμβάνει την συχνή επανάληψη και επικαιροποίηση όπως επίσης τον εντοπισμό, τη διανομή και την υιοθέτηση ιδεών και εμπειριών.
Το Service Desk (Κέντρο Εξυπηρέτησης) αποτελεί μία από τις πλέον εξέχουσες έννοιες του ITIL καθώς η ύπαρξη ενός κεντρικού σημείου επαφής για τους χρήστες αποτελεί ακρογωνιαίο λίθο στην οικοδόμηση ενός πελατοκεντρικού οργανισμού.
Το Service Desk δέχεται τις κλήσεις σε περίπτωση διακοπής μιας υπηρεσίας, τα αιτήματα για νέες υπηρεσίες και προϊόντα καθώς και τα παράπονα των εσωτερικών και εξωτερικών πελατών. Αποτελεί το πρώτο σημείο επαφής με το τμήμα πληροφορικής και επηρεάζει σε σημαντικό βαθμό την εικόνα και τη γνώμη που θα διαμορφώσει ο πελάτης για μας.
Η οργάνωση και η αξιοπιστία του Service Desk μπορεί ως ένα βαθμό να αντισταθμίσει τις ελλείψεις σε άλλους τομείς, μπορεί όμως εξίσου να δώσει μια κακή εντύπωση σε ένα κατά τα άλλα αποτελεσματικό οργανισμό.
Για την οργάνωση ενός κέντρου εξυπηρέτησης ακολουθούμε τις γενικές προτροπές του ITIL αλλά πρέπει να λαμβάνονται υπ’ όψιν ένα μεγάλο πλήθος παραγόντων όπως ο τρόπος και οι ώρες λειτουργίας των πελατών, πιθανές περίοδοι μεγάλου φόρτου, η ωριμότητα των εφαρμογών και η εμπειρία των χρηστών, η γεωγραφική διασπορά των πελατών, η κρισιμότητα των υπηρεσιών κ.α. Οι παράγοντες αυτοί θα διαμορφώσουν τη σύνθεση του Service Desk, τις ώρες λειτουργίας του, τα άτομα ανά βάρδια, τα εργαλεία του και τις διαδικασίες κλιμάκωσης συμβάντων.
Θα πρέπει βέβαια να έχετε στο μυαλό σας πως εκτός από την τεχνολογία εξελίσσονται και οι χρήστες, έχουν ξεπεράσει τις «φοβίες» τους με τους υπολογιστές και είναι σε θέση να κάνουν αρκετά πράγματα μόνοι τους. Μπορούμε λοιπόν δίνοντας κατάλληλα εργαλεία και αυτοματισμούς, εύκολα να μεταφέρουμε στους χρήστες αρκετές ενέργειες. Το Service Desk μπορεί έτσι να επικεντρωθεί στα πιο σύνθετα προβλήματα, στη διαχείριση των πολλών νέων συσκευών, όπως προκύπτουν από την άνθιση του Bring Your Own Device (BYOD) και κυρίως να συμβάλει στη διαχείριση της σχέσης με τον πελάτη και των προσδοκιών του.
Η υλοποίηση και η διαχείριση έργων πληροφορικής και τηλεπικοινωνιών αποτελεί σίγουρα σημαντικό μέρος της λειτουργίας των οργανισμών και των εταιριών πληροφορικής.
Είναι αλήθεια πως στο ITIL δεν υπάρχει σαφής αναφορά στη Διαχείριση Έργων με τον συγκεκριμένο όρο, δηλαδή Project Management, αποτελώντας συχνό θέμα συζήτησης, πολλών ερωτημάτων και αφορμή κριτικής, ιδιαίτερα αν σκεφτεί κανείς πως ο ίδιος οργανισμός, το OGC δηλαδή, που δημιούργησε το ITIL έχει δημιουργήσει και τη μεθοδολογία Διαχείρισης Έργων PRINCE2.
Το ITIL περιγράφει λειτουργίες, δραστηριότητες και αρμοδιότητες, για παράδειγμα στο Service Design και πολύ περισσότερο στο Service Transition, που άπτονται της διαχείρισης έργων όπως τις βρίσκουμε και στο PRINCE2 και στο PMBOOK. Η τοποθέτηση μου είναι πως τα έργα αποτελούν μέρος της Διαχείρισης Υπηρεσιών και θα πρέπει να διαχειρίζονται με δομημένο τρόπο και σύμφωνα με τις υπάρχουσες μεθοδολογίες.
Η εμπειρία δείχνει όμως πως οι Project Managers τείνουν να εστιάζουν περισσότερο στην ανάπτυξη και εγκατάσταση της λύσης και λιγότερο στις λειτουργικές και τις απαιτήσεις υποστήριξης, με αποτέλεσμα να παρουσιάζονται προβλήματα όπως υπερβάσεις στο κόστος των υπηρεσιών, συνεχείς διορθωτικές αλλαγές, απώλεια πελατών η και εμπιστοσύνης προς τον οργανισμό.
Θεωρώ λοιπόν πως αυτό που λείπει από το ITIL, είναι η περιγραφή της σχέσης μεταξύ Διαχείρισης Υπηρεσιών και Διαχείρισης Έργων και αυτό που λείπει από τις μεθοδολογίες της Διαχείρισης Έργων είναι η έμφαση στη σημασία του Service Transition και η εξοικείωση των Project Managers με βασικές αρχές της Διαχείρισης Υπηρεσιών.
Είχα ιδιαίτερη ανταπόκριση από εσάς που θέλετε να ασχοληθείτε με το IT Service Management, σχετικά με το προηγούμενο θέμα της στήλης για τη διαδικασία Διαχείρισης Προβλημάτων (Problem Management). Καθώς επιβεβαιώνεται μια δυσκολία στην κατανόηση και εφαρμογή της Διαχείρισης Προβλημάτων θα προσπαθήσω με απλά παραδείγματα να ξεκαθαρίσουμε ορολογία και πρακτικές:
Έστω λοιπόν ότι ένας χρήστης αναφέρει στο κέντρο εξυπηρέτησης (Service Desk) πως δεν μπορεί να εκτυπώσει ένα PDF αρχείο. Εδώ έχουμε ένα συμβάν (incident) και ανοίγεται μια κλήση.
Καθώς ο τεχνικός δεν βρίσκει λύση και ο χρήστης βιάζεται, του εγκαθιστά έναν από τους εκτυπωτές που βρίσκονται σε άλλο γραφείο και καταφέρνει έτσι να εκτυπώσει το έγγραφο. Εδώ έχει δοθεί μια εναλλακτική λύση, ένα work-around.
Ο τεχνικός πρέπει να δηλώσει ότι έδωσε εναλλακτική λύση και από τη στιγμή που ο χρήστης δουλεύει, το κέντρο εξυπηρέτησης πρέπει να κλείσει το Incident. Προσέξτε αυτό το σημείο καθώς η κλήση δεν πρέπει να παραμείνει ανοιχτή ούτος ώστε να έχουμε αξιόπιστες πληροφορίες και στατιστικά.
Πρέπει όμως ταυτόχρονα να καταγραφεί το γεγονός ως πρόβλημα (problem record). Τις περισσότερες φορές αυτό αποδεικνύεται το πιο αδύναμο σημείο και χρειάζεται να έχουν εκπαιδευτεί πολύ καλά τα άτομα του Service Desk.
Από αυτό το σημείο αναλαμβάνει ο Problem Manager να βρει το αίτιο. Δείτε το σε αντιστοιχία με το Crime Scene Investigation (CSI) που βλέπουμε στην τηλεόραση. Αρκετή έρευνα, συλλογή στοιχείων, ανάλυση, εξομοίωση του συμβάντος και αρκετές ερωτήσεις (η τεχνική των 5 ‘Γιατί;’ ίσως σας φανεί χρήσιμη).
Στο παράδειγμά μας η αιτία εντοπίστηκε σε έναν driver και στις ρυθμίσεις του registry. Ο Problem Manager θα πρέπει να εισηγηθεί μία τεκμηριωμένη αλλαγή ώστε να δοθεί οριστική λύση στο πρόβλημα και να αρθεί το work around.
Η ενημέρωση της βάσης δεδομένων με τα γνωστά σφάλματα(Known Errors database) είναι το απαραίτητο τελευταίο βήμα.
Ο Problem Manager σίγουρα δεν μπορεί να καλύψει όλα τα πιθανά γνωστικά αντικείμενα και είναι αναγκαία η υποστήριξη του management ώστε να του παρέχεται, κατά περίπτωση, η συνδρομή των εξειδικευμένων μηχανικών.
Στους περισσότερους οργανισμούς, η Διαχείριση Προβλημάτων (Problem Management) μοιάζει ως ο φτωχός συγγενής της Διαχείρισης Συμβάντων (Incident Management) και του κέντρου εξυπηρέτησης (Service Desk).
Ενώ το κέντρο εξυπηρέτησης και η διαχείριση συμβάντων λαμβάνουν συνήθως επαρκείς πόρους όσον αφορά το προσωπικό, την κατάρτιση τη συνεχή λειτουργία και τα εργαλεία η Διαχείριση Προβλημάτων είναι συχνά κάτι που «πρέπει να γίνει αλλά αργότερα (όταν θα έχουμε περισσότερο χρόνο)».
Αρκετά κοινή διαπίστωση είναι ότι οι οργανισμοί πιστεύουν ότι κάνουν διαχείριση των προβλημάτων, ενώ στην πραγματικότητα το μόνο που κάνουν είναι να αντιδρούν σε σοβαρά περιστατικά και φυσικά ελάχιστοι κάνουν προληπτική διαχείριση προβλήματος, που είναι η επένδυση στον τομέα της πληροφορικής ώστε να προλαμβάνονται περιστατικά που επηρεάζουν σοβαρά τη διαθεσιμότητα των υπηρεσιών.
Η πιθανότερη αιτία είναι ότι τα προβλήματα συχνά συγχέονται με τα συμβάντα (εναλλάσσοντας ακόμα και την ορολογία) ή θεωρούνται ως μια κατάσταση κατά την εξέλιξη ενός συμβάντος και όχι ως μια ξεχωριστή οντότητα που απαιτεί διαφορετική αντιμετώπιση.
Να πούμε λοιπόν πως θεωρούμε συμβάν (Incident) κάθε μη προγραμματισμένη διακοπή της λειτουργίας μιας υπηρεσίας ή κάποιου επί μέρους συστήματος. Αντίστοιχα η διαχείριση συμβάντων διασφαλίζει την ταχύτερη δυνατή αποκατάσταση της ομαλής λειτουργίας της υπηρεσίας.
Πρόβλημα (Problem) είναι το αίτιο ενός ή περισσότερων συμβάντων. Στην πιο απλή μορφή τους αναγνωρίζουμε ένα πρόβλημα όταν έχουμε επαναλαμβανόμενα ίδια συμβάντα. Το αίτιο δεν είναι συνήθως γνωστό τη στιγμή της καταγραφής ενός προβλήματος και η διεργασία διαχείρισης προβλημάτων είναι υπεύθυνη για την περαιτέρω διερεύνηση ώστε να προλαμβάνει τα συμβάντα ή να ελαχιστοποιεί τον αντίκτυπο των συμβάντων που δεν μπορούν να αποτραπούν.
Θα χρειαστείτε ένα ιδιαίτερα πρόθυμο και κινητοποιημένο άτομο να αναλάβει την πρόκληση του Problem Management. Συμβουλή, μην περιοριστείτε στην ανάλυση πρωταρχικού αιτίου (root cause) αλλά πάρτε την κυριότητα ενός προβλήματος από την αναγνώριση του μέχρι την εφαρμογή της απαιτούμενης αλλαγής και την οριστική επίλυσή του.
