Как изглежда структурираната система за заявки за домоуправители

Заявката е прост запис. Тя е и най-важният структурен примитив в съвременната оперативна работа, от обслужването на клиенти на авиокомпаниите през управлението на инциденти в болниците до поддръжката на сгради.

Тази статия обяснява какво е заявка, какво прави системата около заявките полезна и какво се променя, когато преместите управлението на сгради върху нея.

Заявката е просто запис с четири свойства

Махнете жаргона и заявката е парче работа с четири елемента метаданни, прикачени към него:

1. Идентификатор, обикновено число като #0042. За да можете да се позовавате на него без двусмислие.
2. Статус, къде се намира в работния процес. Нов, В процес, В очакване на потвърждение, Затворен.
3. Отговорник, лицето, което в момента е отговорно за придвижването му напред.
4. История, всяка промяна, която някой е направил, с времеви печати.

Това е всичко. Всичко останало (категории, приоритети, прикачени файлове, коментари) е незадължителна украса. Четирите свойства по-горе превръщат оплакването в проследявана задача вместо в забравено съобщение.

Сравнете това със съобщение в чат. Едно съобщение в чат има съдържание. Това е всичко. То няма идентификатор (освен позицията си в потока), няма статус, няма отговорник, няма история. Затова не можете да движите работен процес върху него.

Защо четирите свойства имат значение поотделно

Идентификатор

Когато двама души обсъждат проблем, те трябва да знаят, че говорят за същия проблем. В чат правите това чрез цитиране: “онова с асансьора от вчера” или “течът в 4Б, за който водопроводчикът каза, че е уплътнението”. Веднага щом бизнесът ви има повече от пет едновременни проблема, това става двусмислено.

Номер на заявка (#0042, #0089) го решава завинаги. Всеки живущ, управител или изпълнител може да се позове на заявка по нейния номер с нулева двусмисленост. Това звучи тривиално. То премахва около 15% от цялото объркване в типичен управленски работен процес.

Статус

Статусът е там, където се случва магията. Статусът превръща свободния разговор в крайен автомат:

Живущият не е нужно да пита “някакво развитие?”. Той може да види статуса. Управителят не е нужно да помни кои проблеми чакат водопроводчика. Той филтрира по статус. Собственикът не е нужно да чете 200 съобщения, за да знае колко проблема са отворени този месец. Той ги преброява.

Статусът е и там, където живее автоматизацията. Когато статусът се промени, се случват неща: задействат се известия, живущите получават сигнал, изпълнители се възлагат. Това е невъзможно в чат, защото чатът няма понятие за състояние.

Отговорник

Всяка заявка, във всеки момент от жизнения си цикъл, има точно едно лице, отговорно за придвижването ѝ напред. Когато живущият подаде, отговорникът е управителят на сградата (или насочен изпълнител). Когато управителят я възложи на изпълнител, изпълнителят става отговорник. Когато изпълнителят я отбележи като готова, живущият става отговорник. Той трябва да потвърди или да отвори отново.

Това е единствената функция, която разбива “трагедията на общото” на груповия чат, където всеки вижда проблема и никой не се заема с него.

История

Пълен лог на всяка промяна на статуса, всяко възлагане, всеки коментар. Ключово по три причини:

1. Отчетност. Когато дойде сезонът на събранията, можете да изготвите точна хронология на това как е обработен всеки проблем.
2. Разпознаване на модели. Шест месеца по-късно ще откриете, че 40% от ВиК проблемите ви са в една и съща сграда, което сочи към структурен проблем, който собственикът трябва да адресира.
3. Въвеждане. Когато се присъедини нов управител, той може да превърти назад историята на всяка сграда и да разбере какво се случва.

Какво добавя “системата около заявките”

Заявката сама по себе си е запис. Системата за заявки добавя работния процес около нея:

• Насочване. Когато се създаде заявка, при кого отива? Повечето системи за заявки използват правила: “категория = ВиК → възложи на водопроводчик Х”. Управителят не решава.
• Известия. Когато статусът се промени, кой получава сигнал? Отговорникът, докладвалият, понякога наблюдател.
• Филтриране. “Покажи ми всички Нови заявки в Сграда 12, невъзложени на никого, по-стари от 24 часа.” Две кликвания.
• Групови действия. “Затвори 30 заявки, които са В очакване на потвърждение от повече от две седмици.” Едно действие.

Тези операции не съществуват в работен процес, базиран на чат. Няма начин да “филтрираш всички отворени проблеми във четири сгради” в WhatsApp, защото нищо в WhatsApp не знае какво е “отворен проблем”.

Минималният жизнеспособен работен процес за заявки за сграда

Не ви трябва корпоративна платформа с 200 функции. Минималният полезен работен процес за заявки за управление на сгради има:

• Заглавие + описание + по избор категория + по избор снимка. Самият доклад.
• Поле за статус с най-много 5 стойности. Нов, В процес, В очакване на потвърждение, Затворен, Отворен отново. Всичко повече е свръхинженерство.
• Възлагане на една от три роли. Управител, изпълнител, живущ.
• Известия при възлагане и промяна на статуса. За да не се налага хората да отварят приложението, за да знаят, че нещо се е случило.
• Обхват по сгради. Всяка заявка принадлежи на сграда, всеки потребител вижда само сградите, в които е член.

Това е цялото ядро. Ако инструмент ви предлага това, в интерфейс, който живущите могат да ползват без обучение, имате каквото ви трябва.

Възраженията, които винаги изникват

“Моите живущи никога няма да ползват това.”

Около 70% ще ползват. Другите 30% ще пишат на живущ, който го ползва, и той ще препубликува проблема. Не ви трябва 100% приемане, за да уловите оперативните ползи. Трябва ви достатъчно приемане, за да направите списъка източника на истината.

“Опитахме това с имейл и не се получи.”

Имейлът не е система за заявки. Имейлът няма статус, няма споделен списък, няма възлагане, няма филтър, няма насочване. Третирането на имейла като система за заявки се проваля, защото имейлът не е такава.

“Вече имаме Excel таблица за това.”

Excel таблицата е по-близо до система за заявки, отколкото е груповият чат. Тя има идентификатори и нещо като колона за статус. Но пак няма известия, няма съвместна работа в реално време, няма повърхност към живущите и няма автоматизация. Тя е запис на работа. Тя не е работен процес.

Промяната в нагласата

Най-трудното при преминаването към система за заявки е менталната промяна от “аз съм системата” към “системата е системата, а аз я надзиравам”. Управителите, които усвоят това, се мащабират до 10+ сгради. Управителите, които не го усвоят, продължават да са човешкият маршрутизатор, докато изгорят.

Първата седмица усеща странно, защото не отговаряте постоянно. После осъзнавате, че сградите вървят гладко без намесата ви в реално време, и причината е, че самият работен процес върши работата, която преди живееше в главата ви.

Това е цялата игра.