Τα πιο συχνά σημεία όπου «σπάει» η ροή εγγράφων
Στον δημόσιο τομέα, και ειδικά στην τοπική αυτοδιοίκηση, το ηλεκτρονικό πρωτόκολλο δήμος συχνά αντιμετωπίζεται ως η βασική απάντηση στο πρόβλημα της διαχείρισης εγγράφων. Στην πράξη όμως, ένα σύστημα πρωτοκόλλου λύνει συγκεκριμένα προβλήματα μόνο όταν τοποθετηθεί σωστά μέσα στη συνολική διοικητική ροή. Αν όχι, απλώς αντικαθιστά το χειρόγραφο βιβλίο με μια οθόνη, χωρίς να αλλάζει ουσιαστικά τίποτα.
Τα πιο συνηθισμένα σημεία αστοχίας δεν βρίσκονται στο «αν υπάρχει εφαρμογή», αλλά στο πώς φτάνει ένα έγγραφο στην εφαρμογή, ποιος το χρεώνεται, πώς παρακολουθείται και πότε θεωρείται ότι ολοκληρώθηκε η διαχείρισή του.
- Πολλαπλά κανάλια εισόδου χωρίς ενιαία καταγραφή. Ένα αίτημα μπορεί να φτάσει με email, μέσω ΚΕΠ, από τη θυρίδα του gov.gr, με φυσική κατάθεση στο πρωτόκολλο ή ακόμη και απευθείας σε μια υπηρεσία. Αν ο δήμος δεν έχει κοινό κανόνα για το πού πρωτοκολλείται πρώτο, δημιουργούνται διπλοεγγραφές ή, χειρότερα, αιτήματα που δεν εμφανίζονται ποτέ κεντρικά.
- Ασαφής διάκριση μεταξύ πρωτοκόλλησης και διεκπεραίωσης. Πολλοί οργανισμοί θεωρούν ότι μόλις δοθεί αριθμός πρωτοκόλλου, το θέμα «μπήκε σε σειρά». Όμως άλλο η καταχώριση και άλλο η ουσιαστική ανάθεση, παρακολούθηση και απάντηση. Έτσι, έγγραφα μένουν σε εκκρεμότητα ενώ τυπικά φαίνονται καταχωρισμένα.
- Χρεώσεις σε λάθος υπηρεσία ή πρόσωπο. Κλασικό παράδειγμα είναι ένα αίτημα για βεβαίωση ΤΑΠ που χρεώνεται γενικά στη Διεύθυνση Οικονομικών χωρίς να προσδιορίζεται τμήμα ή υπάλληλος. Το αποτέλεσμα είναι να «κάθεται» σε κοινόχρηστο inbox ή σε λίστα εκκρεμοτήτων χωρίς ιδιοκτήτη.
- Έλλειψη κανόνων για τα συνημμένα και τα συνοδευτικά. Σε τεχνικές υπηρεσίες, πολεοδομικά θέματα ή αιτήματα καταστημάτων, τα συνοδευτικά έγγραφα είναι κρίσιμα. Αν το πρωτόκολλο καταγράφει μόνο το βασικό αίτημα και όχι τα σχέδια, τις υπεύθυνες δηλώσεις ή τις εγκρίσεις, η υπηρεσία αναγκάζεται να ψάχνει εκτός συστήματος.
- Παράλληλη λειτουργία χαρτιού και ψηφιακού χωρίς σαφείς κανόνες. Σε αρκετούς δήμους το έγγραφο πρωτοκολλείται ηλεκτρονικά, αλλά μετά εκτυπώνεται, μπαίνει σε φυσικό φάκελο και κυκλοφορεί από γραφείο σε γραφείο. Αυτό δεν είναι ψηφιακή ροή· είναι διπλή δουλειά.
Ένα ρεαλιστικό παράδειγμα είναι τα αιτήματα πολιτών για αποκατάσταση βλάβης στον δημοτικό φωτισμό. Αν το αίτημα έρχεται από τηλεφωνικό κέντρο, email ή φόρμα και δεν συνδέεται με ενιαίο αριθμό υπόθεσης, η τεχνική υπηρεσία μπορεί να λάβει τρεις διαφορετικές αναφορές για το ίδιο σημείο. Το πρωτόκολλο τότε δεν μειώνει τον φόρτο· τον πολλαπλασιάζει.
Πώς συνδέεται το πρωτόκολλο με εισερχόμενα αιτήματα και εσωτερικές χρεώσεις
Η αξία που έχει το ηλεκτρονικό πρωτόκολλο δήμος φαίνεται όταν λειτουργεί ως κόμβος μεταξύ εισερχόμενων αιτημάτων, εσωτερικής διακίνησης και λογοδοσίας. Δεν αρκεί να δίνει αριθμό. Πρέπει να απαντά σε τέσσερα πρακτικά ερωτήματα: τι ήρθε, από ποιον, σε ποιον ανατέθηκε και σε ποιο στάδιο βρίσκεται.
Στην καθημερινότητα ενός δήμου, τα εισερχόμενα δεν είναι ομοιογενή. Άλλο ένα αίτημα δημότη για κοπή χόρτων, άλλο μια εισαγγελική παραγγελία, άλλο μια απόφαση χρηματοδότησης, άλλο ένα τιμολόγιο προμηθευτή. Αν όλα μπαίνουν στο ίδιο «καλάθι» χωρίς κατηγοριοποίηση και κανόνες δρομολόγησης, το σύστημα γίνεται απλός αποθηκευτικός χώρος.
Η σωστή σύνδεση συνήθως περιλαμβάνει τα εξής:
- Ενιαία είσοδο εγγράφων. Όλα τα κανάλια πρέπει να οδηγούν σε κοινή καταγραφή, είτε μέσω κεντρικού πρωτοκόλλου είτε μέσω διαλειτουργικότητας με άλλες εφαρμογές.
- Τυποποιημένες κατηγορίες αιτημάτων. Για παράδειγμα, αιτήματα καθαριότητας, βεβαιώσεις, οικονομικά έγγραφα, νομικά έγγραφα, τεχνικά αιτήματα. Αυτό επιτρέπει αυτόματες ή ημι-αυτόματες χρεώσεις.
- Σαφή επίπεδα χρέωσης. Πρώτα στη μονάδα, μετά στο τμήμα, μετά στον χειριστή όπου χρειάζεται. Όχι απλώς «στάλθηκε στη Διεύθυνση».
- Παρακολούθηση προθεσμιών. Ειδικά για αιτήματα πολιτών και διοικητικές υποχρεώσεις, η ύπαρξη ημερομηνίας παραλαβής χωρίς ειδοποίηση καθυστέρησης δεν βοηθά τη διοίκηση.
Παράδειγμα: δημότης υποβάλλει αίτηση για χορήγηση βεβαίωσης μη οφειλής. Αν η αίτηση εισαχθεί μέσω ψηφιακής θυρίδας και το σύστημα την πρωτοκολλήσει αυτόματα, το επόμενο βήμα πρέπει να είναι η χρέωση στο αρμόδιο τμήμα εσόδων, με ένδειξη εκκρεμοτήτων και δυνατότητα επισύναψης της απάντησης. Αν αντίθετα η αίτηση πρωτοκολληθεί αλλά μετά σταλεί με email «για ενέργεια», η ιχνηλασιμότητα χάνεται.
Αντίστοιχα, στις εσωτερικές χρεώσεις, το πρόβλημα δεν είναι μόνο τεχνικό αλλά και οργανωτικό. Σε πολλούς δήμους, οι χρεώσεις γίνονται βάσει προσώπων και όχι ρόλων. Όταν ο υπάλληλος λείπει, μετακινείται ή αλλάζει θέση, οι εκκρεμότητες μένουν κρεμασμένες. Ένα ώριμο σύστημα πρέπει να υποστηρίζει χρέωση σε οργανική μονάδα και δευτερευόντως σε συγκεκριμένο χειριστή.
Ποια λάθη κάνουν οι υπηρεσίες στην υιοθέτηση νέου συστήματος
Η αποτυχία στην υιοθέτηση δεν οφείλεται συνήθως στο λογισμικό καθαυτό. Οφείλεται στο ότι η υπηρεσία προσπαθεί να περάσει σε νέο σύστημα χωρίς να έχει συμφωνήσει πρώτα πώς θέλει να δουλεύει. Έτσι, το νέο εργαλείο φορτώνεται με παλιές συνήθειες.
- Ψηφιοποίηση της υφιστάμενης αταξίας. Αν ο δήμος έχει ήδη ασάφεια στις αρμοδιότητες, στο ποιος παραλαμβάνει τι και στο πώς κλείνει μια υπόθεση, το νέο σύστημα δεν θα το διορθώσει από μόνο του. Απλώς θα καταγράφει πιο καθαρά το χάος.
- Έμφαση στην αρχική καταχώριση και όχι στον κύκλο ζωής. Πολλές υλοποιήσεις δίνουν βάρος στην οθόνη πρωτοκόλλησης, αλλά όχι στις μεταχρεώσεις, στην αναζήτηση, στα στάδια επεξεργασίας και στο κλείσιμο υπόθεσης.
- Έλλειψη εκπαίδευσης με πραγματικά σενάρια. Η γενική παρουσίαση «πατάτε εδώ για νέο έγγραφο» δεν αρκεί. Οι χρήστες χρειάζονται παραδείγματα από τη δική τους δουλειά: πώς χειρίζομαι αίτημα δημότη, πώς απαντώ σε έγγραφο Αποκεντρωμένης Διοίκησης, πώς επισυνάπτω γνωμοδότηση νομικής υπηρεσίας.
- Απουσία κανόνων ονοματοδοσίας και μεταδεδομένων. Αν άλλος γράφει «ΑΙΤΗΣΗ», άλλος «Αίτηση δημότη», άλλος «ΒΕΒΑΙΩΣΗ», η αναζήτηση γίνεται αναξιόπιστη. Το πρόβλημα φαίνεται μετά από μήνες, όταν πρέπει να βρεθεί γρήγορα μια υπόθεση.
- Μη ρεαλιστική απαίτηση να αλλάξουν όλα σε μία μέρα. Η μετάβαση χρειάζεται φάσεις. Πρώτα τα βασικά εισερχόμενα και οι κεντρικές χρεώσεις, μετά οι πιο σύνθετες ροές, όπως διαβιβάσεις μεταξύ υπηρεσιών ή σύνδεση με οικονομικά και τεχνικά συστήματα.
Συχνό παράδειγμα είναι η εγκατάσταση νέου πρωτοκόλλου χωρίς να έχει προηγηθεί χαρτογράφηση των τύπων εγγράφων. Την πρώτη εβδομάδα όλα φαίνονται λειτουργικά. Τον δεύτερο μήνα όμως η γραμματεία δεν ξέρει ποια κατηγορία να επιλέξει για αιτήματα σχολικών επιτροπών, οι τεχνικές υπηρεσίες κρατούν δικό τους αρχείο Excel και η διοίκηση θεωρεί ότι «το σύστημα δεν τραβάει». Στην πραγματικότητα, λείπει ο κοινός τρόπος εργασίας.
Τι πρέπει να δει η διοίκηση πριν επιλέξει λύση
Η διοίκηση ενός δήμου δεν πρέπει να ξεκινά από το ερώτημα «ποιο σύστημα να αγοράσουμε;», αλλά από το «σε ποια σημεία χάνουμε χρόνο, ευθύνη και εικόνα». Μόνο έτσι μπορεί να αξιολογήσει αν μια λύση ηλεκτρονικού πρωτοκόλλου είναι ουσιαστική ή αν απλώς θα προσθέσει άλλη μία εφαρμογή στο ήδη σύνθετο περιβάλλον του φορέα.
Πριν από την επιλογή λύσης, αξίζει να εξεταστούν τουλάχιστον τα παρακάτω:
- Πραγματική ενσωμάτωση στην καθημερινή ροή. Το σύστημα πρέπει να υποστηρίζει τον τρόπο που κινούνται τα έγγραφα στον δήμο, όχι να απαιτεί διαρκείς παρακάμψεις με email, τηλέφωνα και χειρόγραφες σημειώσεις.
- Διαλειτουργικότητα. Χρειάζεται να συνδέεται με ψηφιακές θυρίδες, email, συστήματα αιτημάτων πολιτών, ενδεχομένως οικονομικές ή διοικητικές εφαρμογές. Αν λειτουργεί απομονωμένα, η πληροφορία διασπάται.
- Ρόλοι, δικαιώματα και ιχνηλασιμότητα. Η διοίκηση πρέπει να μπορεί να δει ποιος παρέλαβε, ποιος χρεώθηκε, ποιος ενήργησε και πότε. Αυτό είναι κρίσιμο για λογοδοσία, ειδικά σε ευαίσθητα ή επείγοντα θέματα.
- Ευκολία χρήσης για μη εξειδικευμένους χρήστες. Σε έναν δήμο δεν είναι όλοι καθημερινοί χρήστες πληροφοριακών συστημάτων. Αν η καταχώριση είναι περίπλοκη, οι υπηρεσίες θα βρουν τρόπο να την παρακάμπτουν.
- Δυνατότητα σταδιακής ωρίμανσης. Μια καλή λύση επιτρέπει να ξεκινήσει ο φορέας από τα βασικά και να προσθέτει ροές, αυτοματισμούς και διασυνδέσεις χωρίς να ξηλώνει ό,τι ήδη λειτουργεί.
- Αναφορές διοίκησης. Δεν αρκεί η λίστα πρωτοκόλλων. Χρειάζονται δείκτες: πόσα αιτήματα εκκρεμούν ανά υπηρεσία, ποιοι χρόνοι απόκρισης εμφανίζονται, πού συσσωρεύονται καθυστερήσεις.
Ένα πρακτικό τεστ πριν την επιλογή είναι να ζητηθεί από τον υποψήφιο ανάδοχο να δείξει τρία πραγματικά σενάρια: εισερχόμενο αίτημα δημότη, εσωτερική χρέωση σε δύο υπηρεσίες και απάντηση με πλήρες ιστορικό. Αν σε αυτά τα βασικά βήματα χρειάζονται πρόχειρες λύσεις εκτός συστήματος, τότε η εφαρμογή δύσκολα θα στηρίξει την καθημερινή λειτουργία.
Εξίσου σημαντικό είναι να εξεταστεί αν ο δήμος διαθέτει εσωτερική ετοιμότητα. Υπάρχει απόφαση για ενιαίο σημείο εισόδου; Έχουν οριστεί υπεύθυνοι ανά υπηρεσία; Υπάρχουν πρότυπα κατηγοριοποίησης; Αν όχι, ακόμη και η καλύτερη τεχνολογική επιλογή θα αποδώσει περιορισμένα.
Συμπερασματικά, το ηλεκτρονικό πρωτόκολλο βοηθά πραγματικά όταν οργανώνει την ευθύνη, μειώνει τα χαμένα βήματα και δίνει καθαρή εικόνα της πορείας κάθε εγγράφου. Όταν όμως εφαρμόζεται χωρίς κανόνες ροής, χωρίς σαφείς χρεώσεις και χωρίς σύνδεση με τα πραγματικά εισερχόμενα του δήμου, απλώς μεταφέρει το πρόβλημα από το χαρτί στην οθόνη.