Πώς μοιάζει ένα δομημένο σύστημα βλαβών για διαχειριστές πολυκατοικιών

Ένα ticket (δελτίο βλάβης) είναι μια απλή εγγραφή. Είναι επίσης το πιο σημαντικό δομικό στοιχείο της σύγχρονης λειτουργικής δουλειάς, από την εξυπηρέτηση πελατών των αεροπορικών εταιρειών μέχρι τη διαχείριση περιστατικών στα νοσοκομεία και τη συντήρηση κτιρίων.

Αυτό το άρθρο εξηγεί τι είναι ένα ticket, τι κάνει χρήσιμο το σύστημα γύρω από τα tickets, και τι αλλάζει όταν μεταφέρετε τη διαχείριση πολυκατοικιών σε ένα τέτοιο σύστημα.

Ένα ticket είναι απλώς μια εγγραφή με τέσσερα χαρακτηριστικά

Αν αφαιρέσετε την ορολογία, ένα ticket είναι μια δουλειά με τέσσερα στοιχεία συνδεδεμένα πάνω της:

1. Έναν αριθμό, συνήθως κάτι σαν #0042. Ώστε να αναφέρεστε σε αυτό χωρίς αμφιβολία.
2. Μια κατάσταση, το σημείο όπου βρίσκεται στη ροή εργασίας. Νέα, Σε εξέλιξη, Αναμονή επιβεβαίωσης, Κλειστή.
3. Έναν υπεύθυνο, τον άνθρωπο που αυτή τη στιγμή έχει την ευθύνη να το προχωρήσει.
4. Ένα ιστορικό, κάθε αλλαγή που έκανε οποιοσδήποτε, με ημερομηνία και ώρα.

Αυτό είναι όλο. Όλα τα άλλα (κατηγορίες, προτεραιότητες, συνημμένα, σχόλια) είναι προαιρετικά στολίδια. Τα τέσσερα παραπάνω χαρακτηριστικά μετατρέπουν ένα παράπονο σε εργασία που παρακολουθείται αντί για ένα ξεχασμένο μήνυμα.

Συγκρίνετέ το με ένα μήνυμα σε chat. Ένα μήνυμα σε chat έχει περιεχόμενο. Τίποτε άλλο. Δεν έχει αριθμό (εκτός από τη θέση του στο scroll), ούτε κατάσταση, ούτε υπεύθυνο, ούτε ιστορικό. Γι’ αυτό δεν μπορείτε να τρέξετε μια ροή εργασίας πάνω του.

Γιατί μετράει το καθένα από τα τέσσερα χαρακτηριστικά

Αριθμός

Όταν δύο άνθρωποι συζητούν μια βλάβη, πρέπει να ξέρουν ότι μιλούν για την ίδια βλάβη. Σε ένα chat αυτό γίνεται με παραπομπές: «το θέμα με το ασανσέρ από χθες» ή «η διαρροή στο Β2 που ο υδραυλικός είπε ότι ήταν η φλάντζα». Μόλις η επιχείρησή σας έχει πάνω από πέντε ταυτόχρονες βλάβες, αυτό γίνεται διφορούμενο.

Ένας αριθμός (#0042, #0089) το λύνει για πάντα. Κάθε ένοικος, διαχειριστής ή τεχνικός μπορεί να αναφερθεί σε μια βλάβη με τον αριθμό της χωρίς καμία αμφιβολία. Ακούγεται ασήμαντο. Εξαφανίζει περίπου το 15% της σύγχυσης σε μια τυπική ροή διαχείρισης.

Κατάσταση

Η κατάσταση μετατρέπει μια ελεύθερη συζήτηση σε μηχανισμό καταστάσεων:

Ο ένοικος δεν χρειάζεται να ρωτήσει «υπάρχει κάποιο νέο;». Βλέπει την κατάσταση. Ο διαχειριστής δεν χρειάζεται να θυμάται ποιες βλάβες περιμένουν τον υδραυλικό. Φιλτράρει ανά κατάσταση. Ο ιδιοκτήτης της εταιρείας δεν χρειάζεται να διαβάσει 200 μηνύματα για να ξέρει πόσες βλάβες είναι ανοιχτές αυτόν τον μήνα. Τις μετρά.

Η κατάσταση είναι επίσης το σημείο όπου ζει ο αυτοματισμός. Όταν αλλάζει η κατάσταση, συμβαίνουν πράγματα: στέλνονται ειδοποιήσεις, ενημερώνονται οι ένοικοι, ανατίθενται τεχνικοί. Αυτό είναι αδύνατο σε ένα chat, γιατί το chat δεν έχει έννοια κατάστασης.

Υπεύθυνος

Κάθε βλάβη, σε κάθε στιγμή του κύκλου ζωής της, έχει ακριβώς έναν άνθρωπο υπεύθυνο να την προχωρήσει. Όταν ο ένοικος τη δηλώνει, υπεύθυνος είναι ο διαχειριστής της πολυκατοικίας (ή ένας τεχνικός στον οποίο δρομολογήθηκε). Όταν ο διαχειριστής την αναθέτει σε τεχνικό, υπεύθυνος γίνεται ο τεχνικός. Όταν ο τεχνικός τη σημειώνει ως έτοιμη, υπεύθυνος γίνεται ο ένοικος. Πρέπει να επιβεβαιώσει ή να την ανοίξει ξανά.

Αυτό είναι το ένα χαρακτηριστικό που σπάει την «τραγωδία των κοινών» του group, όπου όλοι βλέπουν τη βλάβη και κανείς δεν την αναλαμβάνει.

Ιστορικό

Ένα πλήρες αρχείο κάθε αλλαγής κατάστασης, κάθε ανάθεσης, κάθε σχολίου. Κρίσιμο για τρεις λόγους:

1. Λογοδοσία. Όταν έρθει η ώρα της γενικής συνέλευσης, μπορείτε να παρουσιάσετε ένα ακριβές χρονολόγιο του πώς χειριστήκατε κάθε βλάβη.
2. Εντοπισμός μοτίβων. Έξι μήνες μετά, θα διαπιστώσετε ότι το 40% των υδραυλικών βλαβών σας είναι στην ίδια πολυκατοικία, πράγμα που δείχνει ένα δομικό πρόβλημα που πρέπει να αντιμετωπίσουν οι ιδιοκτήτες.
3. Ένταξη νέων συνεργατών. Όταν έρχεται ένας νέος διαχειριστής, μπορεί να διατρέξει το ιστορικό οποιασδήποτε πολυκατοικίας και να καταλάβει τι συμβαίνει.

Τι προσθέτει «το σύστημα γύρω από τα tickets»

Ένα ticket από μόνο του είναι μια εγγραφή. Ένα σύστημα προσθέτει τη ροή εργασίας γύρω του:

• Δρομολόγηση. Όταν δημιουργείται μια βλάβη, σε ποιον πηγαίνει; Τα περισσότερα συστήματα χρησιμοποιούν κανόνες: «κατηγορία = υδραυλικά → ανάθεση στον υδραυλικό Χ». Ο διαχειριστής δεν χρειάζεται να αποφασίσει.
• Ειδοποιήσεις. Όταν αλλάζει η κατάσταση, ποιος ειδοποιείται; Ο υπεύθυνος, αυτός που τη δήλωσε, μερικές φορές κάποιος που την παρακολουθεί.
• Φιλτράρισμα. «Δείξε μου όλες τις Νέες βλάβες στην Πολυκατοικία 12, χωρίς υπεύθυνο, παλαιότερες από 24 ώρες.» Δύο κλικ.
• Μαζικές ενέργειες. «Κλείσε 30 βλάβες που βρίσκονται σε Αναμονή επιβεβαίωσης πάνω από δύο εβδομάδες.» Μία ενέργεια.

Αυτές οι λειτουργίες δεν υπάρχουν σε μια ροή εργασίας που βασίζεται σε chat. Δεν υπάρχει τρόπος να «φιλτράρετε όλες τις ανοιχτές βλάβες σε τέσσερις πολυκατοικίες» στο Viber, γιατί τίποτα στο Viber δεν ξέρει τι είναι μια «ανοιχτή βλάβη».

Η ελάχιστη βιώσιμη ροή βλαβών για μια πολυκατοικία

Δεν χρειάζεστε μια εταιρική πλατφόρμα με 200 λειτουργίες. Η ελάχιστη χρήσιμη ροή βλαβών για τη διαχείριση πολυκατοικιών έχει:

• Τίτλο + περιγραφή + προαιρετική κατηγορία + προαιρετική φωτογραφία. Η ίδια η δήλωση.
• Πεδίο κατάστασης με το πολύ 5 τιμές. Νέα, Σε εξέλιξη, Αναμονή επιβεβαίωσης, Κλειστή, Άνοιξε ξανά. Οτιδήποτε περισσότερο είναι υπερβολή.
• Ανάθεση σε έναν από τρεις ρόλους. Διαχειριστής, τεχνικός, ένοικος.
• Ειδοποιήσεις push σε κάθε ανάθεση και αλλαγή κατάστασης. Ώστε να μη χρειάζεται να ανοίξει κανείς την εφαρμογή για να μάθει ότι κάτι συνέβη.
• Διαχωρισμό ανά πολυκατοικία. Κάθε βλάβη ανήκει σε μια πολυκατοικία, και κάθε χρήστης βλέπει μόνο τις πολυκατοικίες στις οποίες είναι μέλος.

Αυτός είναι όλος ο πυρήνας. Αν ένα εργαλείο σάς τα δίνει αυτά, σε ένα περιβάλλον που οι ένοικοι μπορούν να χρησιμοποιήσουν χωρίς εκπαίδευση, έχετε ό,τι χρειάζεστε.

Οι αντιρρήσεις που ακούγονται πάντα

«Οι ένοικοί μου δεν θα το χρησιμοποιήσουν ποτέ.»

Περίπου το 70% θα το χρησιμοποιήσει. Το υπόλοιπο 30% θα στείλει μήνυμα σε έναν ένοικο που το χρησιμοποιεί, και αυτός θα περάσει τη βλάβη. Δεν χρειάζεστε 100% υιοθέτηση για να κερδίσετε τα λειτουργικά οφέλη. Χρειάζεστε αρκετή υιοθέτηση ώστε τα εισερχόμενα να γίνουν η πηγή της αλήθειας.

«Το δοκιμάσαμε με email και δεν δούλεψε.»

Το email δεν είναι σύστημα βλαβών. Το email δεν έχει κατάσταση, κοινά εισερχόμενα, ανάθεση, φίλτρα ή δρομολόγηση. Αν χρησιμοποιείτε το email σαν σύστημα βλαβών, θα αποτύχει, γιατί δεν είναι.

«Έχουμε ήδη ένα Excel γι’ αυτό.»

Ένα Excel είναι πιο κοντά σε σύστημα βλαβών από ό,τι ένα group. Έχει αριθμούς και ένα είδος στήλης κατάστασης. Εξακολουθεί όμως να μην έχει ειδοποιήσεις, πραγματική συνεργασία σε πραγματικό χρόνο, οθόνη για τους ενοίκους και αυτοματισμό. Είναι αρχείο εργασίας. Δεν είναι ροή εργασίας.

Η αλλαγή νοοτροπίας

Το πιο δύσκολο όταν περνάτε σε ένα σύστημα βλαβών είναι η νοητική μετάβαση από το «εγώ είμαι το σύστημα» στο «το σύστημα είναι το σύστημα, κι εγώ το επιβλέπω». Οι διαχειριστές που το εσωτερικεύουν φτάνουν τις 10+ πολυκατοικίες. Όσοι δεν το κάνουν συνεχίζουν να είναι ο ανθρώπινος δρομολογητής μέχρι να εξαντληθούν.

Η πρώτη εβδομάδα μοιάζει παράξενη, γιατί δεν απαντάτε συνεχώς. Μετά συνειδητοποιείτε ότι οι πολυκατοικίες λειτουργούν ομαλά χωρίς τη δική σας παρέμβαση σε πραγματικό χρόνο, και ο λόγος είναι ότι η ίδια η ροή εργασίας κάνει τη δουλειά που πριν ζούσε στο κεφάλι σας.