Η υλοποίηση και η διαχείριση έργων πληροφορικής και τηλεπικοινωνιών αποτελεί σίγουρα σημαντικό μέρος της λειτουργίας των οργανισμών και των εταιριών πληροφορικής.
Είναι αλήθεια πως στο 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 ώστε να του παρέχεται, κατά περίπτωση, η συνδρομή των εξειδικευμένων μηχανικών.