Избор на приложение за обход на HGV, което отговаря на изискванията

Ако избирате приложение за ежедневна проверка за шофьори на HGV, основният въпрос не е дали може да замени хартията. Важно е дали записите, които генерира, ще ни помогнат да обясним системите си на DVSA и, ако е необходимо, на Комисаря по транспорта. Приложение с привлекателен списък не е достатъчно, ако оставя пропуски около детайлите на дефектите, времевите марки, подписването, контрола на VOR или доказателствата, че ремонтите са завършени преди превозното средство да бъде върнато в експлоатация.

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

Какво трябва да прави приложението за ежедневна проверка на практика

Минимумът, който едно приложение за проверка на HGV операции трябва да поддържа, е процесът на докладване на дефекти от шофьорите, зададен в нормалната практика на операторската лицензия в Обединеното кралство. Това означава, че то трябва да прави повече от просто представяне на списък с гуми, светлини и огледала с отметка до всеки елемент.

Очакваме то да изпълнява пет основни задачи.

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

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

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

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

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

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

Ако също така управляваме ванове под праговете на HGV, същата система все още може да бъде полезна, но трябва да помним, че рамката на операторската лицензия е различна. Рискът от несъответствие за 44-тонен артикул и лек ван не е идентичен, дори ако и двете се възползват от дисциплиниран процес на ежедневна проверка.

Как да сравняваме качеството на доказателствата, а не само отметките

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

Започнете с подписи. Трябва да разгледаме как шофьорът подписва проверката и какво означава този подпис в системата. Свързан ли е с именуван вход, дата и час, и точното съдържание на списъка, завършено в този момент? Или е просто драсканица на екран, която може да е добавена по-късно? Полезен запис на подписа трябва да показва кой е завършил проверката и да заключва това подаване като част от одитната следа.

След това, погледнете времевите марки. Нуждаем се от повече от просто деня. Правилният запис трябва да показва времето на подаване и, идеално, всякакви по-късни действия като преглед на дефекта, решение за VOR, подписване на ремонта и връщане в експлоатация. Ако превозното средство е спряно в 07:15 и проверката е завършена в 09:40, трябва да знаем това. Система, която не може ясно да покаже последователността на събитията, може да стане неудобна много бързо.

Детайлите на дефекта са друга разделителна линия. Ако всеки проблем се появява като "дефект на светлината" или "проблем с гумата", записът не ни казва много. По-добрите системи позволяват на шофьора да посочи коя лампа, коя позиция на гумата, какво увреждане е видяно и дали дефектът е повлиял на безопасното използване. Свободният текст е важен тук, но също така е важна и структурата. Искаме достатъчно стандартизация, за да докладваме последователно, без да намаляваме всеки реален проблем до неясен етикет.

Снимките са полезни, но само ако са част от веригата на доказателствата. Трябва да проверим дали изображенията са прикрепени към доклада с дата и час, дали остават свързани с дефекта и дали по-късните зрители могат да видят пълния контекст. Снимките трябва да подкрепят писмения доклад, а не да го заменят. Размазан образ на разрез на страничната стена без никаква бележка за позицията на оста или състоянието на протектора не е много полезен.

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

Запазването и извличането са също толкова важни, колкото и записването. По време на посещение на DVSA, може да се наложи да представим модел на доказателства, а не един изолиран запис. Например, записи, показващи повторни доклади за нулеви дефекти на превозно средство, което по-късно е показало очевидни проблеми, може да привлекат по-голямо внимание. Приложението трябва да улеснява търсенето и експортирането на записи по превозно средство, ремарке, шофьор и диапазон от дати.

Тук също е моментът да попитаме дали системата може да поддържа надзор от страна на управлението. Можем ли да идентифицираме пропуснати проверки, закъснели проверки, повторни дефекти или превозни средства, използвани преди затварянето на дефекта? Запис, който съществува, но никога не се повдига в транспортния офис, е само половин решение.

Покриваме оперативната страна на това в повече детайли в нашето ръководство за проверки на шофьорите и докладване на дефекти. Принципът е прост. Ако записът не би ни помогнал да обясним действията си под наблюдение, той не е достатъчно силно доказателство.

Докладване на дефекти, контрол на VOR и последващи ремонти

Истинското изпитание на всяко приложение за проверка започва, когато шофьор открие дефект, който може да повлияе на годността за движение.

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

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

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

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

Последващият ремонт е мястото, където много оператори все още се връщат към хартия или WhatsApp. Това отслабва файла. По-добрият подход е да се запази комуникацията с работилницата и доказателствата за завършване, свързани с оригиналния дефект. Това може да включва бележки от монтьора, детайли за външния ремонт, заменени части и датата и часа, когато ремонтът е завършен. Ако инспекцията за безопасност, PMI или друго събитие в работилницата е уместно, записите трябва да се свързват чисто.

Най-важното е, че трябва да има доказателство, че дефектът е разрешен преди превозното средство да бъде използвано отново, където това е било необходимо. Това може да означава подписване на поддръжка, потвърждение от втори шофьор или освобождаване от мениджър в зависимост от нашия процес. Важно е записът да показва ясна преди и след.

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

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

Удобство за шофьора, работа офлайн и смесени флоти

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

Това означава, че удобството е важно, но не в смисъла на потребителско приложение. Не търсим забавление. Търсим процес, който може да бъде завършен бързо, точно и последователно в 04:30 под дъжда, на споделено устройство, от шофьор, който трябва да започне работа.

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

Работата офлайн не е опция за много оператори. Селските депа, кариери, пристанища, строителни площадки и части от главната мрежа все още имат лош сигнал. Ако приложението работи само с активна връзка, шофьорите или ще пропуснат проверки, или ще ги възпроизведат по-късно, и двете отслабват записа. Правилният офлайн режим трябва да позволява проверката да бъде завършена на устройството и след това да се синхронизира автоматично, след като сигналът се върне, запазвайки оригиналното време на завършване.

Споделените и смесени флоти изискват внимателно обмисляне. Ако управляваме HGV, ванове, ремаркета и PSV, приложението трябва да позволява на всяка операция да използва правилния работен поток, без да създава объркване. Оператор на автобуси или автобуси може да се нуждае от различни подканвания за ежедневна отчетност от обща товарна флота. Флотата на куриерите, използваща по-леки превозни средства, все още се възползва от докладването на дефекти, но контекстът на операторската лицензия и годишния тест не е идентичен.

Агенти и временни шофьори са още един практически тест. Могат ли да бъдат настроени бързо с правилните разрешения и все пак да оставят именувани, подписани записи? Ако редовно разчитаме на агенционен труд, процесът на проверка трябва да работи, без да отслабва контрола на идентичността. Нашето ръководство за използване на агенционни шофьори в съответствие и проверки на шофьорски лицензии за оператори стои до това с причина. Ежедневната проверка е само част от доказването, че правилният човек е шофирал законно и под контрол.

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

Кога приложение за проверка трябва да бъде част от по-широка система за съответствие

Самостоятелно приложение за проверка може да е достатъчно, ако нашата операция е малка, проста и вече е добре контролирана на друго място. Но след като управляваме множество превозни средства, ремаркета, шофьори, интервали на инспекция и крайни срокове за документи, ежедневните проверки трябва да бъдат част от по-широка система за съответствие.

Причината е проста. Докладът за проверка рядко стои самостоятелно. Той е свързан с планирането на поддръжка на превозното средство, дати на MOT или годишен тест, графици за инспекция за безопасност, записи на шофьори, доказателства от тахограф, застраховка и понякога управление на инциденти. Ако тези записи са в отделни инструменти без споделена история на активите, прекарваме твърде много време в съгласуването им, когато възникнат въпроси.

Например, ако превозното средство показва повторни дефекти, свързани с гумите в ежедневните проверки, може да искаме да видим историята на инспекциите и резултатите от работилницата заедно с тези доклади. Ако шофьорът многократно подава проверки с лошо качество на нулеви дефекти, може да искаме да прегледаме записи за обучение, проверки на лицензи с DVLA, статус на Driver CPC, изтичане на DQC и всякакви модели на тахограф, които предполагат бързи стартирания. Това е трудно, ако приложението за проверка е изолирано.

По-широката система също помага с крайни срокове и доказателства за контрол. Операторите трябва да проследяват резервации за MOT, планиране на годишен тест за PSV, честота на инспекциите, проверки на шофьорски лицензи, Driver CPC, DQC, застраховка и други записи на едно място. Където има специфични за Обединеното кралство очаквания за операторска лицензия, този свързан поглед е по-важен, отколкото може да изглежда в общ инструмент за флот в ЕС. Околната среда на прилагане в Обединеното кралство е оформена от практиките на DVSA, режима на операторската лицензия и ролята на Комисаря по транспорта.

Затова изградихме Operator Compliance като част от по-широка платформа за съответствие на операторската лицензия, а не просто приложение за формуляри. Fleeta Limited управлява камиони под операторска лицензия, така че изградихме около записите, които знаем, че операторите са помолени да предоставят. На практика това означава, че ежедневните проверки трябва да се свързват с останалата част от файла, а не да седят в изолация.

Интеграцията също може да е важна. Ако вече използваме други системи, попитайте какво е налично извън експорта на електронна таблица. REST API и уебхуковете могат да бъдат полезни, когато данните за флота трябва да се преместват между работилница, телематика или HR системи. Но интеграцията не трябва да отклонява вниманието от основния въпрос за съответствието. Красиво свързано приложение, което произвежда слаби доказателства, все още е грешен избор.

Същото важи и за добавки и съседни услуги. Връзките с askMID, Бюрото на моторните застрахователи или данните на MIB могат да помогнат в някои работни потоци. Връзките с Fleetalyse или Logivo.AI могат да отговарят на определени оператори. Достъпът до записи на VOL също може да е важен оперативно. Нито едно от това не замества необходимостта от ясни доказателства за ежедневни дефекти, контролирани решения за VOR и извлечими записи.

Така че кога трябва да изберем по-широка система за съответствие, а не самостоятелно приложение? Обикновено, когато някое от следните важи:

• управляваме множество превозни средства или ремаркета
• повече от един човек управлява съответствието
• дефектите изискват последващи действия в работилницата през депата
• нуждаем се от един файл за посещения на DVSA
• искаме видимост на пропуснатите проверки и просрочени действия
• записите на шофьорите, доказателствата от тахографа и крайни срокове за поддръжка в момента са разпръснати на различни места

Накратко, най-доброто приложение за ежедневна проверка на HGV шофьори е това, което ни помага да докажем контрол, а не просто да събираме отметки. Ако то поддържа правилно докладване на дефекти, силни доказателства, ясни решения за VOR и естествено се свързва с останалите ни задължения по операторската лицензия, то ще свърши работата си, когато е необходимо. Ако не може, то е само цифрова версия на хартия, а хартията никога не е била истинският проблем.