Как фирма за теренен сервиз с 24 души пусна служебно приложение за 10 седмици
Регионална монтажна фирма се давеше в хартиени работни листове и вечерни телефонни обаждания. Ето честната история как изградихме и пуснахме служебно приложение за теренен сервиз за десет седмици — какво отрязахме, какво се счупи и какво наистина се промени.

Фирмата, която ни се обади, не искаше приложение. Искаше да спре да губи по час всяка вечер в един и същ разговор: техник звъни в офиса и изброява кои поръчки са свършени, какви материали са вложени и кой клиент не е бил вкъщи. Някой в офиса записва всичко, въвежда го в три системи и седмица по-късно открива, че два работни листа липсват, а една фактура е грешна. Това беше истинският проблем. Приложението беше просто формата, която решението случайно прие.
Това е казус за реален проект, анонимизиран. Става дума за монтажна и поддръжкова фирма с 24 души — представете си отопление, вентилация и свързаните с тях повиквания — работеща в цял регион с осем буса по пътищата в повечето дни. Променихме няколко идентифициращи детайла и няма да се преструваме, че числата са одитирана наука. Но историята е истинска, включително частите, в които сбъркахме нещо и трябваше да го връщаме назад. Точно тези части обикновено са най-полезни, затова ги оставихме.
Ако управлявате бизнес за теренен сервиз и са ви оферирали шестцифрена сума и деветмесечен срок за служебно приложение, това е контрааргументът. Десет седмици, фокусиран обхват и инструмент, който техниците наистина отваряха сами, без да ги гоним. Ето как мина.
Проблемът: бизнес, движен от хартия и телефонни обаждания
Когато седнахме със собственика и офис мениджъра, повърхностното оплакване беше „трябва да станем дигитални“. Само по себе си това не значи нищо, затова го пренебрегнахме и вместо това наблюдавахме работата. Прекарахме един ден в офиса и една сутрин в буса. До обяд истинският проблем беше очевиден и нямаше нищо общо с това, че технологиите са стари.
Всеки техник носеше папка с работни листове с индиго. На обекта надраскваше свършената работа, отмяташе няколко полета, записваше материали и взимаше подпис от клиента. Горното копие се връщаше в офиса в крайна сметка — понякога същата вечер, понякога в петък в смачкана купчина. После офисът въвеждаше всеки лист в инструмента за планиране, отново във фактуриращия софтуер и трети път в електронна таблица, която собственикът ползваше, за да следи кои поръчки са за фактуриране. Три пъти въвеждане на едно и също. Два от тези пъти внасяха нови грешки.
Цената не беше само офис часовете. Беше забавянето. Поръчка, приключена в понеделник, можеше да не бъде фактурирана до следващата седмица, защото хартията още не беше изплувала. Клиенти звъняха да питат за работа, за която офисът не знаеше, че е свършена. А когато лист изчезнеше напълно — което се случваше по-често, отколкото някой признаваше — тази поръчка просто никога не се фактурираше. Никой не можа да ни каже колко пари излизаха така през вратата, което само по себе си беше показателно.
“Мислеха, че имат проблем с документацията. Всъщност имаха проблем с паричния поток, преоблечен като папка с листове.”

Какво съзнателно не изградихме
Най-бързият начин да взривиш десетседмичен срок е да казваш „да“ на всичко. Затова, преди да напишем и ред код, написахме списък с неща, които приложението няма да прави — и накарахме собственика да се съгласи с него на глас. Това е най-малко бляскавата част от всеки проект и единствената най-голяма причина да бъде пуснат навреме.
Списъкът с желания, събран в два разговора, имаше около трийсет функции. GPS проследяване на бусове. Портал за резервации, обърнат към клиента. Складова наличност в целия склад. Автоматична оптимизация на маршрути. Пълен CRM. Доклади за щети със снимки и анотации. Отчитане на работно време с експорт за заплати. Всяка от тях беше разумна идея. Всяка от тях беше и начин никога да не приключиш.
Свихме обхвата до едно изречение, по същия начин, по който бихме посъветвали всеки малък бизнес: техникът трябва да може да види днешните поръчки, да запише какво е свършил и никой да не го въвежда отново. Всичко, което не служеше на това изречение, отиде в списък „по-късно, може би“. Този списък още съществува. По-голямата част от него никога не е липсвала.
- Извън: GPS проследяване на бусове — атмосфера на наблюдение, която никой в екипа не искаше, решаваща проблем, който нямаха.
- Извън: клиентски портал за резервации — отделен проект с отделна аудитория; включването му щеше да удвои срока.
- Извън: пълна складова наличност — полезна някой ден, но не на критичния път към по-бързо фактуриране.
- Извън: оптимизация на маршрути — висока сложност, нисък реален резултат за географията на тази фирма.
- Вътре: днешен списък с поръчки, дигитални работни листове, отчитане на материали, подпис на клиента, снимки, мигновена синхронизация с офиса.
Какво всъщност прави приложението
Сведено до същината си, приложението е почти отегчително просто — и това е комплимент. Техникът го отваря сутрин и вижда поръчките си за деня, по ред, с адреса, клиента, историята на този обект и какво се очаква да направи. Влиза в поръчка и всичко, което преди живееше в папката, сега живее на екрана.
На обекта записва свършената работа от кратък чеклист, добавя материали от списък с търсене (така че „медно коляно 22мм“ са две докосвания, а не догадка за изписването), щраква една-две снимки, ако нещо трябва да се документира, и подава телефона на клиента за подпис с пръст. Натиска „готово“. Това е всичко. В мига, в който има сигнал, всичко се синхронизира с офиса — без телефонно обаждане, без хартия, без повторно въвеждане.
Детайлът, който имаше най-голямо значение: работи без сигнал
Приложенията за теренен сервиз живеят или умират заради едно нещо, което демото никога не показва: какво се случва в сутерен с котелно помещение без покритие. Ако приложението замръзне или изгуби данни в секундата, в която чертичките изчезнат, техниците ще го изоставят за седмица и ще сте изградили скъпо преспапие. Затова го изградихме офлайн-първо от първия ден. Всичко работи напълно без връзка; устройството пази данните и синхронизира в мига, в който може. Техникът никога не мисли за това, което е точно целта.
Страната на офиса: един екран, без повторно въвеждане
Офисът не получи разпростряло се табло. Получи един екран, показващ поръчките, докато приключват, всяка с прикачен лист, материали, снимки и подпис. Оттам приключена поръчка се превръща във фактура с вече попълнени данни — офисът я проверява и я изпраща, вместо да я въвежда от нулата. Свързахме го с фактуриращия софтуер, който вече ползваха, вместо да го заменяме, защото замяната на работещ софтуер по средата на проекта е начинът десетседмичните срокове да станат десетмесечни.

Десетте седмици, честно
Десет седмици не е магическо число; това е, което този обхват отне с една двойка дизайнер-разработчик и наистина ангажиран клиент. Ето приблизително как се разпредели времето — включително седмицата, която загубихме, защото да се преструваме, че проектите вървят съвършено, не помага на никого.
- 1Седмици 1–2: Наблюдавай, не питайВозихме се с тях, седяхме в офиса и нанесохме реалния работен процес на стена. Написахме обхвата от едно изречение и списъка „няма да изграждаме“ и получихме одобрение и за двете преди какъвто и да е дизайн.
- 2Седмици 3–4: Кликаема формаИзградихме кликаем прототип — без истински код, само екрани — и го дадохме в ръцете на двама техници. Обратната им връзка уби три от предположенията ни рано, което е най-евтиното място да сбъркаш.
- 3Седмици 5–7: Изграждане на ядротоСписъкът с поръчки, дигиталните листове, материалите, подписът, снимките и офлайн синхронизиращият двигател. Синхронизацията беше трудната част и изяде по-голямата част от седмица 7.
- 4Седмица 8: Седмицата, която загубихмеИнтеграцията с фактурирането ни се опъна. Интерфейсът на съществуващия софтуер беше по-капризен, отколкото твърдеше документацията му, и изгорихме седмица в чисто мапване на полета. Струваше си — повторното въвеждане беше целият проблем, който решавахме.
- 5Седмици 9–10: Пилот и шлифованеДва буса пуснаха приложението наистина, докато другите шест останаха на хартия. Поправихме каквото изплува от пилота, после го разгърнахме за всички с една кратка обучителна сесия.
Да накараш теренния персонал наистина да го ползва
Можеш да изградиш най-доброто приложение за теренен сервиз на света и да гледаш как умира, защото 55-годишен техник с двайсетгодишна мускулна памет за папката решава, че не е за него. Възприемането не е технически проблем и не можеш да го решиш с функции. Отнесохме се към него като към реалния проект, който е.
Три неща свършиха тежката работа. Първо, направихме процеса на обекта по-бърз от хартията, не просто дигитален — по-малко докосвания от надрасквания, материали, които избираш, вместо да изписваш, подпис, вместо да гониш четлив такъв. Ако приложението беше дори малко по-бавно от папката, щеше да се провали, и то заслужено. Второ, подбрахме внимателно двамата пилотни техника: един тихо уважаван от другите, един открито скептичен. Да спечелиш скептика струваше повече от всякакъв маркетинг.
Трето, никой не беше накаран да се почувства глупав. Обучението беше двайсет минути, приложението беше съзнателно очевидно, а офис мениджърът стана човекът за обръщане през първите две седмици, така че никой техник да не се почувства изоставен. За три седмици хартиените работни листове изчезнаха — не забранени, просто изоставени, защото приложението беше наистина по-лесният път.
“Възприемането не се печели в обучението. Печели се, като направиш новия начин по-бърз от стария още от първия опит.”
Какво се промени — резултатите
Тук ще внимаваме, защото казусите обичат да цитират точни числа, които се разпадат при разпит. Тези цифри са собствените на фирмата, взети няколко месеца след разгръщането, и са по-скоро ориентировъчни, отколкото лабораторно точни. Но посоката е недвусмислена и съвпада с това, което собственикът усеща ден за ден.
| Какво измервахме | Преди | След |
|---|---|---|
| Време от свършена поръчка до изпратена фактура | 5–8 дни | Същия или следващия ден |
| Офис часове за повторно въвеждане на данни от поръчки | ~10 ч/седмица | Под 2 ч/седмица |
| Изгубени или нефактурируеми работни листове | По няколко на месец | На практика нула |
| Вечерни обаждания „изброй ми поръчките си“ | Ежедневно, всеки бус | Изчезнаха |
Заглавието, което вълнуваше собственика, обаче не беше в тази таблица. Беше паричният поток. Когато фактурите излизат същия ден вместо седмица по-късно, парите влизат с около седмица по-рано в целия бизнес — за всяка отделна поръчка. За фирма с 24 души, работеща на тесни маржове, тази промяна във времето имаше по-голямо значение от всяка отделна ефективност. Възстановените офис часове бяха хубаво нещо. Да ти плащат седмица по-рано, всеки път, беше истинската награда.

Какво бихме ви казали, ако обмисляте същото
Повечето от поуките тук не са специфични за теренния сервиз. Това е, което бихме казали на всеки малък бизнес, изкушен да поръча софтуер по поръчка, и струват повече от самото приложение.
Свивайте обхвата безпощадно и напишете списъка си „няма да изграждаме“ преди списъка за изграждане. Наблюдавайте реалната работа, преди да проектирате каквото и да било — собствениците описват процеса, който биха искали да имат, не този, който всъщност провеждат. Пилотирайте на малко и оставете скептиците да обърнат останалите. И се свържете с инструментите, които вече ползвате, вместо да ги заменяте, поне в началото. Нищо от това не е хитро. Всичко това е, което направи десет седмици възможни вместо десет месеца.
Още едно, тихото: приложението никога не беше смисълът. Смисълът беше да ти плащат по-рано и да спре едни и същи данни да се въвеждат три пъти. Можехме да решим част от това с готови инструменти и за някои фирми това е правилният избор. За тази, хаотичната смесица от записване на обекта, офлайн реалност и съществуваща фактурираща система означаваше, че фокусираното изграждане по поръчка се изплати бързо. Честният отговор на „приложение или готово?“ е: зависи, и всеки, който отговори мигновено, ви продава нещо.
Имате теренен екип, който още работи на хартия?
Ако вашите хора са по обектите, а офисът въвежда наново деня им всяка вечер, почти със сигурност вътре се крие фокусирано приложение. Ще погледнем реалния ви работен процес и ще ви кажем честно дали си струва да се изгражда — и какво да оставите настрана.
Вижте как изграждаме служебни приложенияЧести въпроси
Реалистични ли са десет седмици, или това беше специален случай?
Защо приложение по поръчка вместо готов софтуер за теренен сервиз?
Коя беше най-трудната част технически?
Как го приеха по-възрастните техници?
Можехте ли да автоматизирате повече от него?

Have a nice day е софтуерно студио, което помага на малките и средните предприятия да се дигитализират — автоматизация, изкуствен интелект и софтуер по поръчка, който работи в ежедневната дейност, а не само на слайдове.