Софтуер за записи за годност на пътя, който издържа на одит

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

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

Какви записи на DVSA ръководството всъщност очаква да контролирате

Ръководството на DVSA за поддържане на годността на пътя е практично. То не иска от операторите да съхраняват записи само заради самите записи. Очаква от нас да контролираме системата за поддръжка зад флота и да можем да докажем този контрол.

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

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

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

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

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

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

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

Какво да сравнявате в софтуера за записи за годност на пътя

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

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

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

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

Записите за ремаркета често разкриват слаби системи. Много платформи се справят разумно добре с моторизирани превозни средства, но третират ремаркетата като следствие. Операторите в Обединеното кралство не могат да си позволят това. Инспекциите на ремаркета, дефектите, годишните тестове, където е уместно, записите за гуми и периодите на VOR изискват същата дисциплина като записите за превозни средства. Обсъдихме това по-подробно в нашето ръководство за избор на софтуер за инспекция на ремаркета за записи на DVSA.

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

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

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

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

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

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

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

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

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

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

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

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

Как Operator Compliance се вписва в файла за операторска лицензия в Обединеното кралство

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

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

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

Нашият опит е важен тук. OperatorCompliance е създаден от Fleeta Limited, и го казваме ясно, защото сами управляваме камиони под операторска лицензия. Това влияе на детайлите. Знаем защо плановиците на инспекции трябва да работят по ISO седмица. Знаем защо транспортните мениджъри трябва да виждат периодите на VOR спрямо дефектите и ремонтите, а не в отделен отчет за наличност. Знаем защо ремаркето не може да се третира като вторичен актив и защо подписаният отчет за нулев дефект може да има значение точно толкова, колкото и докладваният дефект.

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

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

Кой тип оператор се нуждае от какво ниво на система

Не всеки оператор се нуждае от същото ниво на софтуер, но всеки оператор се нуждае от записи, които имат смисъл при проверка.

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

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

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

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

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

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

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

Въпроси, които да зададете, преди да преместите записите си в една система

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

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

Проверете как работи планирането на практика. Може ли системата да планира по ISO седмица? Може ли да се справи с комбинирани интервали и преместени инспекции, като същевременно запази оригиналната одитна следа?

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

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

Накрая, задайте най-простия одитен въпрос от всички. Ако утре DVSA ви посети, колко бързо можете да произведете пълната история на превозно средство или ремарке, включително инспекции, дефекти, ремонти, периоди на VOR, доказателства за MOT или годишен тест и подписани проверки на обиколките? Ако отговорът е измерен в минути, а не в часове, вие разглеждате система, изградена за съответствие на операторите, а не просто за администрация на флота.

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