Kaip atrodo struktūruota gedimų registravimo sistema administratoriams

Užklausa (angl. ticket) yra paprastas įrašas. Kartu tai svarbiausias struktūrinis šiuolaikinio operatyvinio darbo elementas: nuo aviakompanijų klientų aptarnavimo iki ligoninių incidentų valdymo ir pastatų priežiūros.

Šiame straipsnyje paaiškinama, kas yra užklausa (daugiabutyje: gedimo pranešimas), kas daro naudingą sistemą aplink užklausas ir kas pasikeičia, kai namų administravimas perkeliamas į tokią sistemą.

Užklausa yra tiesiog įrašas su keturiomis savybėmis

Nuėmus žargoną, užklausa yra darbo vienetas su keturiais prie jo pridėtais duomenimis:

1. Identifikatorius, dažniausiai numeris, pavyzdžiui, #0042. Kad į ją galėtumėte nurodyti nedviprasmiškai.
2. Būsena, t. y. kurioje darbo eigos vietoje ji yra. Naujas, Vykdomas, Tikrinamas, Išspręstas.
3. Atsakingas asmuo, t. y. žmogus, kuris šiuo metu atsako už jos judėjimą į priekį.
4. Istorija, t. y. kiekvienas bet kieno atliktas pakeitimas su data ir laiku.

Tiek. Visa kita (kategorijos, prioritetai, priedai, komentarai) yra neprivalomi papildai. Šios keturios savybės paverčia skundą sekama užduotimi, o ne pamiršta žinute.

Palyginkite tai su žinute pokalbyje. Žinutė turi turinį. Ir tiek. Ji neturi identifikatoriaus (išskyrus vietą pokalbio sraute), būsenos, atsakingo asmens ar istorijos. Todėl ant jos neįmanoma pastatyti darbo eigos.

Kodėl kiekviena iš keturių savybių svarbi

Identifikatorius

Kai du žmonės aptaria gedimą, jie turi žinoti, kad kalba apie tą patį gedimą. Pokalbyje tai daroma citatomis: „tas vakarykštis reikalas su liftu“ arba „nuotėkis 24 bute, apie kurį santechnikas sakė, kad kalta tarpinė“. Kai tik jūsų įmonėje vienu metu atvirų gedimų daugiau nei penki, tai tampa dviprasmiška.

Užklausos numeris (#0042, #0089) išsprendžia tai visam laikui. Bet kuris gyventojas, administratorius ar meistras gali nurodyti užklausą jos numeriu be jokios dviprasmybės. Skamba kaip smulkmena. Tai pašalina apie 15 % visos painiavos įprastoje administravimo darbo eigoje.

Būsena

Būsena laisvą pokalbį paverčia būsenų mašina:

Gyventojui nereikia klausti „ar yra naujienų?“. Jis mato būseną. Administratoriui nereikia prisiminti, kurie gedimai laukia santechniko. Jis filtruoja pagal būseną. Įmonės vadovui nereikia skaityti 200 žinučių, kad sužinotų, kiek gedimų šį mėnesį atvira. Jis juos suskaičiuoja.

Būsenoje gyvena ir automatizavimas. Kai būsena keičiasi, vyksta veiksmai: išsiunčiami pranešimai, gyventojai informuojami, meistrams priskiriami darbai. Pokalbyje tai neįmanoma, nes pokalbis neturi būsenos sąvokos.

Atsakingas asmuo

Kiekviena užklausa kiekvienu savo gyvavimo ciklo momentu turi lygiai vieną žmogų, atsakingą už jos judėjimą į priekį. Kai gyventojas pateikia pranešimą, atsakingas yra namo administratorius (arba meistras, kuriam pranešimas nukreiptas). Kai administratorius priskiria jį meistrui, atsakingu tampa meistras. Kai meistras pažymi darbą kaip atliktą, atsakingu tampa gyventojas: jis turi patvirtinti arba atidaryti iš naujo.

Būtent ši savybė sulaužo grupės pokalbiui būdingą „bendro turto tragediją“, kai visi mato gedimą, bet niekas juo nesirūpina.

Istorija

Išsamus kiekvieno būsenos pakeitimo, kiekvieno priskyrimo ir kiekvieno komentaro žurnalas. Svarbus dėl trijų priežasčių:

1. Atskaitomybė. Kai ateina visuotinio susirinkimo laikas, galite pateikti tikslią chronologiją, kaip buvo tvarkomas kiekvienas gedimas.
2. Pasikartojančių problemų atpažinimas. Po pusmečio pastebėsite, kad 40 % jūsų santechnikos gedimų yra tame pačiame name: tai ženklas, kad laikas bendrijos valdybai pasiūlyti vamzdynų remontą.
3. Naujų darbuotojų įvedimas. Kai prisijungia naujas administratorius, jis gali peržiūrėti bet kurio namo istoriją ir suprasti, kas vyksta.

Ką prideda „sistema aplink užklausas“

Pati užklausa yra įrašas. Užklausų sistema aplink ją prideda darbo eigą:

• Paskirstymas. Kam užklausa atitenka, kai ji sukuriama? Dauguma sistemų naudoja taisykles: „kategorija = santechnika → priskirti santechnikui X“. Administratoriui nereikia spręsti.
• Pranešimai. Kam pranešama, kai keičiasi būsena? Atsakingam asmeniui, pranešusiajam, kartais stebėtojui.
• Filtravimas. „Parodykite visas naujas Žirmūnų g. 12 namo užklausas, niekam nepriskirtas ir senesnes nei 24 valandos.“ Du paspaudimai.
• Masiniai veiksmai. „Uždarykite 30 užklausų, kurios laukia patvirtinimo ilgiau nei dvi savaites.“ Vienas veiksmas.

Pokalbiais grįstoje darbo eigoje šių operacijų nėra. Messenger programėlėje neįmanoma „išfiltruoti visų atvirų gedimų keturiuose namuose“, nes niekas joje nežino, kas yra „atviras gedimas“.

Minimali daugiabučio gedimų darbo eiga

Jums nereikia 200 funkcijų turinčios verslo platformos. Minimali naudinga užklausų darbo eiga namų administravimui turi:

• Pavadinimą, aprašymą, pasirenkamą kategoriją ir pasirenkamą nuotrauką. Pats pranešimas.
• Būsenos lauką su ne daugiau kaip 5 reikšmėmis. Naujas, Vykdomas, Tikrinamas, Išspręstas, Atidarytas pakartotinai. Daugiau yra perteklinis sudėtingumas.
• Priskyrimą vienam iš trijų vaidmenų. Administratorius, meistras, gyventojas.
• Tiesioginius (push) pranešimus apie priskyrimą ir būsenos pasikeitimą. Kad niekam nereikėtų atidaryti programėlės norint sužinoti, kad kažkas įvyko.
• Atskyrimą pagal namus. Kiekviena užklausa priklauso namui, o kiekvienas naudotojas mato tik tuos namus, kurių narys jis yra.

Tai ir yra visas branduolys. Jei įrankis jums tai siūlo su sąsaja, kuria gyventojai gali naudotis be mokymų, turite viską, ko reikia.

Prieštaravimai, kurie iškyla visada

„Mano gyventojai niekada tuo nesinaudos.“

Maždaug 70 % naudosis. Kiti 30 % parašys kaimynui, kuris naudojasi, o šis perkels gedimą į programėlę. Norint gauti operacinę naudą, nereikia 100 % gyventojų. Reikia tiek, kad gautųjų dėžutė taptų vieninteliu tiesos šaltiniu.

„Bandėme tai daryti el. paštu, ir nepavyko.“

El. paštas nėra užklausų sistema. Jame nėra būsenų, bendros gautųjų dėžutės, priskyrimo, filtrų ar paskirstymo. Naudoti el. paštą kaip užklausų sistemą nepavyksta, nes ji tokia nėra.

„Tam jau turime Excel lentelę.“

Excel lentelė yra arčiau užklausų sistemos nei grupės pokalbis. Joje yra identifikatoriai ir tam tikras būsenos stulpelis. Tačiau joje vis tiek nėra pranešimų, bendradarbiavimo realiuoju laiku, gyventojams matomos dalies ir automatizavimo. Tai atlikto darbo įrašas. Tai ne darbo eiga.

Mąstysenos pokytis

Sunkiausia pereinant prie užklausų sistemos yra mąstysenos pokytis nuo „sistema esu aš“ prie „sistema yra sistema, o aš ją prižiūriu“. Administratoriai, kurie tai įsisavina, išauga iki 10 ir daugiau namų. Tie, kurie ne, ir toliau lieka gyvu komutatoriumi, kol perdega.

Pirmoji savaitė atrodo keista, nes nuolat nereaguojate. Tada suprantate, kad namai veikia sklandžiai be jūsų įsikišimo realiuoju laiku, o priežastis ta, kad pati darbo eiga atlieka darbą, kuris anksčiau gyveno jūsų galvoje.