· 1 минути четене
Избор на софтуер за запис на дефекти на DVSA, който издържа
Практично сравнение на софтуер за записи от инспекции на DVSA и дефекти, включително какво трябва да проверят операторите в Обединеното кралство преди
Ако избирате софтуер за записи на инспекции и дефекти на DVSA, тестът е прост. Може ли да ни помогне да управляваме автопарка правилно всеки ден и може ли да произведе ясен, подписан, времево маркиран запис, когато DVSA или Комисарят по транспорта поиска доказателства? Ако отговорът на която и да е точка е не, това не е правилната система, независимо колко подреден изглежда таблото.
Мениджърите по транспорт не се нуждаят от още едно приложение, което събира формуляри и оставя трудната част на електронни таблици, имейл вериги и памет на депото. Нуждаем се от едно място за контрол на интервалите на инспекциите, докладването на дефекти, корекцията, решенията за изключване на превозното средство, изтичането на документи и одитната следа зад тях. Това е стандартът, за който изграждаме в Operator Compliance, защото Fleeta Limited работи под операторска лицензия и знае какво трябва да издържи истинският файл за съответствие.
Какво е необходимо на мениджърите по транспорт от софтуер за дефекти и инспекции
Минимумът, който системата трябва да съдържа, са записите, които подкрепят управлението на годността за движение съгласно Ръководството на DVSA за поддържане на годността за движение. Това означава планирани инспекции за безопасност, доклади за дефекти от шофьори, записи за корекция, дати на MOT или годишни тестове, доказателства за гуми и спирачки, където е уместно, и история, която свързва всяко събитие с конкретно превозно средство или ремарке.
За повечето оператори основният работен процес изглежда така:
- Определете график за инспекция за всяко превозно средство и ремарке.
- Запишете завършената инспекция за безопасност, с дата, пробег или километри, констатации и подпис.
- Записвайте ежедневни или смени на дефекти от шофьори.
- Решете дали всеки дефект е малък, критичен за безопасността или изисква активът да бъде маркиран като VOR.
- Записвайте работата по корекция, кой я е завършил, кога е завършена и дали активът е върнат в експлоатация.
- Дръжте документите и подписите заедно, така че записът да може да бъде представен по-късно без реконструкция.
Това звучи основно, но много системи не успяват в детайлите. PDF хранилище не е същото като система за записи на инспекции. Приложение за шофьори, което позволява на някого да отметне "няма дефекти", не е достатъчно, ако няма работен процес за ремонт, преглед и закриване. Дневник на работилницата не е достатъчен, ако транспортният офис не може да докаже, че инспекцията е била планирана в правилния интервал и завършена навреме.
Правилната одитна следа е важна, защото проверките на DVSA не спират само на това дали записът съществува. Те разглеждат дали записът е достоверен. Можем ли да покажем кога е била дължима инспекцията, кога е била извършена, кой я е подписал, какви дефекти са били намерени, какво действие е последвало и дали пропуснатите събития са били идентифицирани и адресирани? Ако превозното средство е имало повтарящи се дефекти на гумите или проблеми с осветлението, можем ли да видим модела? Ако ремаркето е сменило депота, можем ли все още да видим пълната история без да питаме трима души да търсят стари папки?
За операторите в Обединеното кралство системата също трябва да отразява реалността на операторската лицензия, а не обща администрация на автопарка. Интервалът за инспекция за безопасност може да бъде основан на седмици, пробег, възраст на превозното средство, условия на работа или документиран план за поддръжка. Някои автопаркове искат графици по календарна дата, други по ISO седмица, особено когато инспекциите са планирани около капацитета на работилницата и рутините на транспортния офис. Софтуерът трябва да поддържа метода, който наистина използваме, и да запази разискванията зад него.
Записите също трябва да различават между инспекции за годност за движение и друга поддръжка. Услугата не е автоматично инспекция за безопасност. Листът PMI, сканиран в папка, е полезен само ако е свързан с правилния актив, дата и подпис, и ако пропуснатите или закъснели събития остават видими, вместо да бъдат скрити от по-късно качване.
Затова предпочитаме системи, изградени около работа с операторска лицензия. В OperatorCompliance структурата на записа започва с превозни средства, ремаркета и шофьори, след което изгражда събитията за съответствие около тях. Това не е общ мениджър на задачи с транспортен етикет.
Кои функции наистина намаляват риска от съответствие?
Функциите, които намаляват риска, рядко са впечатляващите. Те са контролите, които предотвратяват пропускането на работа, правят изключенията видими и принуждават към чист процес на закриване.
Първо, планираните инспекции трябва да бъдат надеждни. Трябва да можем да зададем честотата на инспекция за всяко превозно средство и ремарке, да видим следващата дължима дата и да забележим просрочени елементи веднага. Системата трябва да се справя с различни типове автопаркове, включително HGV, фургони, PSV и смесени операции. Тя също така трябва да уточнява дали следващата дата на инспекция е изчислена от планираната дата или от действителната дата на завършване, тъй като това влияе на контрола на интервалите.
Второ, подписването на дефекти се нуждае от структура. Доклад за дефект не трябва да изчезва след подаване. Той трябва да премине през определен процес, отворен, оценен, назначен, ремонтиран, проверен, затворен, с имена, дати и часове, прикрепени. Ако дефектът е изключил превозното средство от пътя, статусът VOR трябва да бъде видим за офиса, работилницата и планиращия. Ако шофьорът е докладвал, че няма дефекти, този нулев доклад все още трябва да бъде записан, защото отсъствието на доказателства е проблем при одита.
Трето, съхранението на документи трябва да бъде в рамките на работния поток за съответствие. Полезно е да се съхраняват листове от инспекции, доклади за тестове на спирачки, сертификати за MOT или годишни тестове, снимки, фактури и бележки от техници, но само ако са свързани с правилното събитие. Голямо архивно шкафче с PDF файлове не помага, когато трябва да покажем доказателствата за корекция за конкретен дефект, повдигнат преди три месеца на конкретно ремарке.
Четвърто, известията трябва да бъдат оперативни, а не шумни. Нуждаем се от напомняния за предстоящи инспекции, MOT, годишен тест, изтичане на Driver CPC и DQC, проверки на лицензи, дати на застраховки и крайни срокове за тахографи, ако те са в обхвата. Но системата също така трябва да предупреждава за изключенията, които създават реална експозиция, просрочени инспекции, открити дефекти за безопасност, повтарящи се дефекти на същия актив, липсващи подписи и документи, които се очакваха, но не бяха качени.
Пето, отчетите трябва да ни помогнат да интервеним рано. Полезни отчети включват просрочени инспекции, дефекти по активи, дефекти по категории, открити VOR елементи, пропуснати събития от инспекции, статус на инспекция на ремаркета и съответствие на докладите на шофьорите. Отчет за тенденции често е по-ценен от дълъг списък, защото показва дали депото, изпълнителят или типът превозно средство излизат извън контрол.
Тук много купувачи трябва да бъдат скептични. Доставчик може да покаже лъскаво приложение за дефекти, но ако отчетът не може да раздели откритите от затворените дефекти или не може да експортира пълна история на инспекциите, рискът от съответствие остава при нас. Същото важи и за система, която съхранява подписи, но не може да докаже кога са били уловени.
Ако искате по-дълбок поглед върху това, което е важно в ежедневния контрол на дефектите, нашето ръководство за записи за дефекти и поддръжка, които издържат на DVSA обхваща практическите проверки, които предлагаме преди покупка.
Как системата трябва да обработва превозни средства, ремаркета и шофьори?
Системата трябва да третира превозни средства, ремаркета и шофьори като отделни единици за съответствие с свързани истории. Това звучи очевидно, но е мястото, където смесените автопаркове често се провалят.
Превозните средства се нуждаят от собствен график за инспекция, дати на MOT или годишни тестове, данни за данъци и застраховки, където се проследяват, и пълна история на дефектите и поддръжката. За HGV и PSV обикновено искаме ясни връзки с доказателства за тестове на спирачки, записи на инспекции за безопасност и всякакви повтарящи се проблеми с годността за движение. За фургони под по-леки режими същият принцип важи, дори и да е по-просто наборът от записи.
Ремаркетата се нуждаят от равно третиране. Твърде много системи все още третират ремаркетата като второстепенни активи, което причинява пропуски в планирането на инспекции и историята на дефектите. Ремарке може да генерира собствен риск за годност за движение и свои въпроси от DVSA, особено ако се движи между единици, депота или подизпълнители. Софтуерът трябва да ни позволи да задаваме интервали за инспекция, да записваме дефекти на ремаркета, да маркираме статус VOR на ремаркето и да произвеждаме пълна история на ремаркето без да разчитаме на тракторната единица, с която е било свързано в този ден.
Шофьорите се нуждаят от повече от име и телефонен номер. Нуждаем се от данни за лиценз, дати на проверки, категории, одобрения, където са записани, статус на Driver CPC, изтичане на DQC и доказателства за проверки, извършени спрямо данни от DVLA или качени записи. Ако се използват шофьори от агенции, системата все пак трябва да съдържа структуриран запис за това кой е проверил какво, кога и с чия власт.
Докладването на дефекти от шофьори е основна точка за тестване. Приложението или формулярът трябва да бъдат достатъчно лесни за шофьорите да попълнят правилно, но достатъчно контролирани, за да създадат използваеми доказателства. Ще търсим:
- Докладване на нулеви дефекти, както и докладване на дефекти
- Дати и времеви маркировки
- Избор на превозно средство и ремарке
- Категории дефекти с текст и снимки
- Декларация или подпис на шофьора
- Ескалация за критични за безопасността дефекти
- Преглед и закриване от офиса
- Ясен запис, ако същият дефект се пренася в очакване на части или слот в работилницата
За операторите на автобуси и автобуси, както и за таксиметрови и частни наемни фирми, може да има изисквания на местните власти или вътрешни политики, които стоят до очакванията на DVSA. Системата трябва да бъде достатъчно гъвкава, за да съдържа и тези проверки, но не за сметка на основните контролни механизми на операторската лицензия.
Когато правилата в Обединеното кралство се различават от по-широката практика на ЕС, имайте предвид стандарта за доказателства в Обединеното кралство. Файлът за операторска лицензия, проверки на DVSA на пътя и в помещенията, и всяко повикване за публично разследване от Комисаря по транспорта се оценяват спрямо изискванията на Обединеното кралство и записите, които можем да представим тук. Функции, които имат смисъл в по-широк пакет за автопаркове в Европа, не са много полезни, ако не съвпадат с проверките на DVLA, доказателствата за Driver CPC и записите за поддръжка, очаквани в Великобритания.
Ако ремаркетата са голяма част от вашата операция, нашата статия за софтуер за инспекция на ремаркета за записи на DVSA описва точките, които казваме на операторите да проверят преди да се ангажират.
Какви доказателства ще ви трябват, ако DVSA или Комисарят по транспорта попитат?
Когато DVSA посети или когато Комисарят по транспорта иска записи, проблемът рядко е, че не е извършена работа. Проблемът е, че доказателствата са непълни, разпръснати или невъзможни за бързо представяне.
Системата трябва да ни позволи да произведем чист пакет за всяко превозно средство, ремарке или шофьор. Това обикновено означава:
- Подписани записи на инспекции за безопасност
- Планировчик на инспекции, показващ дати на дължими и завършени инспекции
- Пълна история на дефектите, включително нулеви доклади, ако се използват
- Доказателства за корекция, с дати, части, бележки от техници, фактури или работни листове, където са налични
- Записи за пропуснати или закъснели инспекции
- Доказателства за преглед и корективни действия след всяко пропуснато събитие
- История на MOT или годишен тест
- Данни за лиценз на шофьор и доказателства за Driver CPC, където е уместно
- Експортируеми отчети за определен период
Подписаните записи имат значение. Написано име в поле за бележки не е същото като структурирана подписка или декларация, свързана със събитието. Времевите маркировки също имат значение. Ако шофьор е подал дефект в 05:40 и превозното средство е напуснало обекта в 06:00, трябва да покажем какво решение е взето и от кого. Ако инспекцията за безопасност е завършена късно, трябва да покажем, че сме я признали, оценили риска и коригирали проблема с графика.
Пропуснатите събития не трябва да бъдат скрити. Система, която тихо презаписва дължимата дата или показва само последната завършена инспекция, може да ни накара да изглеждаме по-зле, а не по-добре, защото предполага, че одитната следа е била изгладена. По-добрият софтуер запазва изключението и ни позволява да анотираме причината и корективното действие.
Експортът е още един практичен тест. Ако единственият начин да отговорим на искане е да направим скрийншотове, системата не е готова. Трябва да можем да експортираме истории на инспекции, регистри на дефекти и документални пакети в формат, който друг човек може да прегледа без да се нуждае от нашето влизане или обяснение.
Тук също се показва качеството на данните. Регистрации на превозни средства, номера на автопаркове, ID на ремаркета и имена на шофьори трябва да бъдат достатъчно последователни, така че същият актив да не се появява под множество версии. Ако текущите ви записи са неясни, попитайте как доставчикът помага да ги почистите и мигрирате.
За оператори, изграждащи месечни прегледни пакети, също предлагаме да се погледне дали софтуерът може да поддържа рутинни доказателства за управление, а не само извличане в криза. Нашата статия за месечен пакет за автопарка, който издържа на DVSA обяснява какво смятаме, че трябва да бъде видимо, преди проверяващият да поиска това.
Как да сравнявате доставчици, без да купите грешната система
Започнете с операционния модел, а не с демонстрацията. Помолете доставчика да покаже точно как е настроено превозното средство, как се задава интервал за инспекция, как шофьорът докладва дефект, как се записва корекцията и как се експортира пълната история. Ако останат на ниво табло, натиснете по-дълбоко.
Практична рамка за сравнение трябва да обхваща пет области.
Първо, настройка. Може ли системата да импортира превозни средства, ремаркета и шофьори на едро? Може ли да се справи с смесени автопаркове? Може ли да задава различни интервали за инспекция по тип актив или модел на работа? Може ли да съхранява дати на MOT, годишни тестове, застраховки и срокове, свързани с лицензи, на едно място? Ако работите по ISO седмица, може ли да поддържа това без обходи?
Второ, поддръжка. Кой помага с внедряването, структурата на записите и разпространението на персонала? Поддръжката базирана в Обединеното кралство ли е и запозната с съответствието на операторската лицензия или е обща софтуерна поддръжка? Попитайте кой разбира файл за поддръжка на DVSA, а не само кой може да нулира парола.
Трето, миграция на данни. Повечето оператори вече имат записи в електронни таблици, споделени дискове, системи на работилницата или по-стари продукти за автопаркове. Попитайте какво може да бъде импортирано, какво се нуждае от ръчно почистване и как историческите инспекции и дефекти ще изглеждат след миграцията. Ако доставчикът казва, че миграцията е лесна, поискайте да видите пример с исторически данни, свързани с превозни средства и ремаркета правилно.
Четвърто, интеграция. Ако вече използвате софтуер за работилници, HR системи, телематика или инструменти за тахографи, попитайте дали доставчикът предлага REST API или уебхук. Те не са модни термини, ако наистина имате нужда системите да обменят събития или документи. Те имат значение, ако искате статус на дефектите да премине в планирането или ако искате записите на шофьорите да бъдат актуализирани от друг източник. Но ако доставчикът рекламира интеграция и не може да обясни структурата на събитията, удостоверяването или наличните крайни точки, третирайте това внимателно.
Пето, съответствие на продукта. Изграден ли е софтуерът около работа с операторска лицензия или е добавен транспортен контрол към по-широка платформа за автопаркове? Задайте директни въпроси относно инспекциите на DVSA, закриването на дефекти, записите на ремаркета, Driver CPC, DQC и пакетите с доказателства за Комисаря по транспорта. Доставчик, който говори само за ефективността на автопарка, може да не е този, който искате, когато проблемът е правното съответствие.
Също така е полезно да проверите дали системата разчита силно на данни от трети страни за ключови записи. Например, за проверки на застраховки, някои оператори питат за askMID, Бюрото на моторните застрахователи и данни от MIB. Тези услуги могат да бъдат полезни в контекста, но не заменят нашето задължение да поддържаме точни операторски записи. Същото важи и за данни за лицензи и доказателства от работилницата. Външните източници могат да подкрепят файла, но не могат да го заменят.
Накрая, сравнете продукта с работата, която офисът ви всъщност извършва всяка седмица. Може ли да замени бялата дъска, споделената електронна таблица, папката със сканирани PMI и пощенската кутия, пълна с дефектни снимки? Може ли да покаже какво е дължимо следващо, какво е просрочено сега и какви доказателства са завършени? Това е по-добър тест за покупка от дълъг списък с функции.
На пазара има много имена, включително Fleetalyse и Logivo.AI, и някои оператори вече могат да имат по-широки системи на място чрез други доставчици. Правилното решение е това, което ни дава надежден запис за годност за движение, а не това с най-широката брошура.
Ако сравнявате опции една до друга, нашето ръководство за как да сравнявате софтуер за годност за движение за доказателства от DVSA е добро следващо стъпка.
Най-сигурният избор е софтуер, който ни помага да управляваме автопарка правилно, преди някой да зададе въпроси, а след това ясно да го докаже, когато го направят. Това означава записи, които са пълни, графици за инспекции, които са контролирани, дефекти, които са закрити правилно, и доказателства, които могат да бъдат експортирани без бързане. Според нас софтуерът за записи на инспекции и дефекти на DVSA трябва да прави точно това, защото работата по съответствие е толкова силна, колкото записът, който можем да поставим на масата.
Какво трябва да включва софтуерът за записи на инспекции и дефекти на DVSA?
Той трябва да съдържа планирани дати на инспекции, завършени записи на инспекции, доклади за дефекти, бележки за корекция, подпис, съхранение на документи, известия и ясна одитна следа за превозни средства и ремаркета.
Може ли една система да обхване дефекти, дати на MOT и доказателства за тахограф?
Да, много оператори искат една система за дефекти, дати на MOT или годишни тестове, анализ на тахографи и записи на шофьори, така че доказателствата да не са разпределени между електронни таблици и пощенски кутии.
Защо е важно записването на ремаркета при избора на софтуер?
Ремаркетата се нуждаят от собствена история на инспекции, дефекти, дати на дължими и документи. Ако записите на ремаркета са слаби, операторът може да има затруднения да покаже пълна система за поддръжка.
Нуждая ли се от подписани записи за дефекти?
На практика, да. Подписаните или ясно приписани записи помагат да се покаже кой е докладвал, прегледал и коригирал дефект, което е полезно по време на посещения на DVSA и проверка от Комисаря по транспорта.
Трябва ли да питам за интеграции преди покупка?
Да. Попитайте как системата обработва импорти, експорти, достъп до REST API, уебхукове и връзки с други инструменти за автопаркове, за да не създавате повече ръчна администрация по-късно.