Избор на софтуер за записи за дефекти и поддръжка за DVSA

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

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

Какво е необходимо на операторите в Обединеното кралство от записи за дефекти и поддръжка

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

Минимумът, който операторите обикновено трябва да поддържат, е записи за превозни средства и ремаркета, обхващащи:

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

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

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

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

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

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

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

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

При сравняване на системи, следата от одит е толкова важна, колкото и самата форма. Чист PDF не е достатъчен, ако никой не може да покаже кога е създаден, кой го е променил и дали дефектът е затворен правилно.

Предлагаме да проверите тези точки в всяка кратка листа:

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

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

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

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

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

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

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

Може ли да управлява инспекции, MOT и срокове за годишен тест?

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

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

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

Търсете:

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

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

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

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

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

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

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

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

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

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

Този свързан запис помага по три начина.

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

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

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

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

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

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

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

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

Това обикновено е моментът, в който по-широката платформа е по-доброто решение.

По-широка система за съответствие трябва да ни позволи да управляваме, на едно място:

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

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

Има и практическо интеграционно питане. Ако вече използвате други системи, попитайте дали софтуерът предлага REST API или уебхукове и какво може наистина да се обменя. Платформа за съответствие не трябва да твърди, че е интегрирана просто защото може да експортира CSV файлове. Ако се нуждаете от данни от askMID, Бюрото на моторните застрахователи, MIB, DVLA или други работни потоци от трети страни, бъдете ясни относно това, което е нативно, какво е ръчно и какво зависи от външни услуги.

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

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

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

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