Веб-приложение для диспетчера спецтехники: календарь занятости

Какая проблема у диспетчера спецтехники на практике

Диспетчер спецтехники каждый день живет в режиме "срочно": пришла новая заявка, где-то сдвинули начало смены, у водителя поломка, заказчик просит перенести подачу, а бухгалтерии нужны данные по отработанным часам. При этом от диспетчера ждут простого результата: техника назначена вовремя, смены закрываются без споров, факты сходятся.

Задачи повторяются почти всегда: принять и уточнить заявку, подобрать машину и экипаж, проверить занятость, поставить в смену, отследить статус ("в пути/на объекте/в работе"), а затем закрыть смену по факту. Параллельно идут звонки, связь с механиком, поправки на погоду и пробки, фиксация договоренностей.

Проблемы начинаются там, где "система" - это таблица плюс несколько чатов. В таблице одно, в чате другое, по телефону третье. Статусы меняются на ходу, история правок теряется. Самое болезненное - конфликты по времени: одну и ту же технику назначили на два объекта или оставили "окно" между сменами, которое на деле съедает переезд.

Поэтому сначала стоит автоматизировать две вещи: календарь занятости техники и подтверждение выполнения. Календарь дает единый источник правды по времени, месту и назначению. Подтверждение защищает от "закрыли на словах": видно, кто подтвердил, когда, что именно выполнено и какие были отклонения.

Успех легко увидеть по простым признакам: меньше накладок и двойных назначений, быстрее согласования по заявкам и переносам, понятное закрытие смен без долгих разборов, прозрачные отчеты по простоям и причинам отклонений.

Когда эти основы стоят крепко, проще подключать шаблоны путевых листов и отчеты. AI здесь полезен, но он работает точнее, когда факты уже собраны в календаре и подтверждениях.

Какие данные нужно хранить: минимум, без лишнего

Частая ошибка на старте - пытаться учесть все сразу: топливо, склад, ремонты, штрафы, бухгалтерию. Для первого релиза веб-приложения для диспетчера спецтехники хватит данных, которые отвечают на три вопроса: какая техника свободна, где она нужна и как честно закрыть выполненную работу.

Начните с коротких справочников, удобных для выбора из списка, а не для "энциклопедии".

По технике обычно достаточно: название/номер, тип, базовая сменная стоимость (если нужно) и признак "в ремонте". По экипажам - ФИО, телефон и привязка к технике (если постоянная). По объектам - адрес и контакт на месте. По контрагентам - название и ответственное лицо. По видам работ - короткие названия, понятные диспетчеру (например, "вывоз грунта", "погрузка", "планировка").

Заявка - ядро. В ней фиксируется минимум, без которого начинается путаница: кто заказал, объект, дата и время, какая техника нужна, ожидаемая длительность, условия (пропуск, режим, точка въезда) и комментарий. Если в заявке нет "когда" и "сколько по времени", календарь занятости техники нормально не заработает.

Дальше нужна сущность "смена/рейс" для плана и факта. В плане храните назначенную технику и ответственных. В факте - реальное время начала/окончания, короткий комментарий и, при необходимости, подтверждение: отметка диспетчера, фото или подпись на объекте.

Чтобы все двигалось по понятным правилам, используйте короткую цепочку статусов: черновик -> согласовано -> назначено -> в работе -> выполнено -> подтверждено. Отмена должна быть отдельным статусом, а не "стерли и забыли". Иначе отчеты и разбор конфликтов превращаются в спор на словах.

Календарь занятости: как сделать его удобным

Календарь должен отвечать на один вопрос за 5 секунд: какая техника свободна прямо сейчас и что будет через пару часов.

Хорошо работает связка из трех режимов: день, неделя, месяц. День нужен для плотных перестановок, неделя - чтобы видеть загрузку бригад и объектов, месяц - для планирования и отпусков операторов. Рядом держите список заявок, чтобы диспетчер не бегал по вкладкам: заявку можно взять из списка и сразу поставить в сетку.

Карточки в календаре делайте простыми: техника, объект, время, ответственное лицо. Цвета лучше привязать к статусу, а не к типу техники - при большом парке иначе все будет пестреть. Например: свободна (серый), забронирована (синий), в работе (зеленый), ожидает подтверждения (желтый), отменена или перенос (красный).

Самое важное - проверка конфликтов. Если один экскаватор поставили на 10:00 в два разных места, система должна подсветить пересечение сразу, еще до сохранения. Полезно показывать причину: пересечение по времени, техника уже закреплена за другим объектом, слишком мало времени на переезд.

Для ежедневной работы важны быстрые действия. Обычно достаточно пяти:

• перетащить заявку на другое время
• быстро сменить технику в заявке
• добавить резервную единицу на подмену
• разделить смену на два интервала
• поставить заметку о риске (погода, пропуск, ожидание)

Фильтры держите под рукой: по типу техники, объекту, диспетчеру, статусу, контрагенту. Типичный пример: утром звонит заказчик и просит фронтальный погрузчик на 14:00. Диспетчер включает фильтр по типу, видит свободные слоты, сдвигает одну заявку на 30 минут и уходит без конфликтов.

Подтверждение выполнения: чтобы закрытие работ было честным

Когда смена закрывается одним нажатием, почти всегда возникают вопросы: техника реально была на объекте, отработала нужные часы, простой согласован, допработы учтены? Поэтому лучше разделять два факта: работа выполнена и работа подтверждена.

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

Подтверждение должно быть однозначным. Выберите 1-2 способа и используйте их везде: подпись (электронная или фото подписи на бумаге), код подтверждения (например, код от прораба), отметка "подтверждаю" + короткий комментарий, прикрепленный файл (фото техники на объекте, акт, путевой лист).

При подтверждении просите минимум данных, иначе шаг начнут пропускать. Обычно хватает: фактических часов, простоя (если был) и короткого комментария. Пробег/моточасы добавляйте только если они реально нужны дальше.

Спорные случаи лучше вести не перепиской, а через понятный возврат. Если заказчик не согласен, заявка уходит "на доработку" с обязательной причиной (например, "не совпали часы" или "не было на объекте"). После исправления идет повторное подтверждение, а в истории остается цепочка: кто и когда менял факты.

Пошаговый процесс: от заявки до закрытия смены

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

Рабочая схема выглядит так:

1. Прием заявки (черновик): адрес, вид работ, контакты, желаемое окно времени. Длительность ставьте примерную, чтобы сразу понимать масштаб.
2. Проверка календаря и подбор техники (план): смотрите доступность по машине и по типу. Если есть пересечение - выбираете альтернативу или предлагаете другое время.
3. Согласование времени и условий (согласовано): фиксируете точное окно и условия. С этого момента изменения должны оставлять след: кто и когда поменял.
4. Назначение экипажа и выдача задания (назначено): привязываете водителя/машиниста, указываете точку старта, контакт на объекте и что считать началом смены.
5. Факт и закрытие (выполнено, подтверждено): вносите факт начала и окончания, простои и причины. Затем получаете подтверждение (код/подпись/фото) и закрываете смену.

Мини-сценарий: клиент просит погрузчик на 4 часа, но в календаре он занят до 14:00. Вы ставите черновик на 15:00-19:00, согласовываете, назначаете экипаж. По факту работа заняла 3 часа и был простой 30 минут из-за ожидания допуска - это попадает в отчет, а закрытие смены происходит только после подтверждения.

Путевые листы: шаблоны и автозаполнение с помощью AI

Путевой лист часто превращается в ручную переписку данных из заявки, смены и табеля. Удобнее, когда документ собирается из уже введенных данных, а человек только проверяет и дополняет то, чего не хватает.

Какие поля действительно нужны

Начните с набора, который подходит большинству компаний: техника (тип, бортовой номер), водитель (ФИО, табельный номер), объект или маршрут (адрес, заказчик), время (выезд, начало, окончание, возврат), задания (что делали, объем), расход (топливо, моточасы или пробег).

Дальше подготовьте 2-3 шаблона под разные сценарии: смена на объекте (например, кран на стройке), рейсы (самосвал с несколькими ходками), аренда с экипажем (когда важны часы и простои).

Как поручить AI подготовить шаблоны и автозаполнение

Чтобы AI сделал шаблон путевого листа корректно, задайте правила, а не общую просьбу. Зафиксируйте обязательные поля, формат дат и времени, правила нумерации, откуда брать значения (из заявки, смены, справочников) и что оставлять пустым для ручного ввода.

Практичный вариант: заявка уже содержит объект, технику и плановое время. После смены водитель добавляет фактическое время и расход. На основе этих данных AI формирует документ и короткий блок "отклонения от плана" (опоздание, переработка, простой).

Сразу предусмотрите печать и выгрузку в PDF, а также историю версий: кто и когда правил документ и что изменилось.

Простои: учет и отчеты, которые реально помогают

Простой начинается там, где техника должна работать, но не работает. Если это не фиксировать, кажется, что "все заняты", а деньги уходят в ожидания и срывы. Простой лучше учитывать так же строго, как смену: с интервалом времени, причиной и подтверждением.

Важно заранее договориться о правилах: что считать простоем. Обычно это ожидание на объекте (нет фронта работ), поломка или обслуживание, нет доступа (пропуск, охрана, перекрытия), нет материалов или людей для разгрузки, погода (если реально остановила работу).

Для записи простоя не нужны длинные тексты. В карточке простоя достаточно:

• интервала времени (с и по, с возможностью продлить)
• причины из списка
• комментария в 1-2 предложения
• ответственного лица (кто подтвердил и от кого зависит устранение)

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

Роли, права доступа и порядок в данных

Когда людей много, а одна и та же техника фигурирует в десятках заявок, хаос появляется не из-за "сложной системы", а из-за размытых ролей и прав. Даже если календарь удобный, без правил данные быстро станут недостоверными.

Роли: кто за что отвечает

Обычно хватает пяти ролей. Диспетчер ведет заявки и календарь занятости техники. Руководитель смотрит картину целиком и решает спорные случаи. Механик отвечает за техсостояние и отметки "в ремонте/готово". Бухгалтерия фиксирует то, что влияет на оплату: смены, часы, простои, подтверждения. Заказчику доступ нужен не всегда, но иногда полезен личный кабинет только для просмотра статуса и подтверждения выполнения.

Права лучше задавать по шагам процесса:

• диспетчер создает заявку и назначает технику/время
• механик блокирует технику на ремонт и снимает блокировку
• заказчик (или руководитель со стороны заказчика) подтверждает выполнение
• руководитель утверждает отмены и правки задним числом
• бухгалтерия закрывает смену для расчета и запрещает дальнейшие правки

Журнал изменений и нормы данных

Журнал изменений обязателен: кто поменял время, технику, статус и почему. Причину отмены или переноса лучше выбирать из справочника, а не писать каждый раз по-разному.

Порядок в данных начинается с обязательных полей: объект, контакт, техника (или класс техники), дата и время, длительность, ответственный, статус. И еще важное - единые названия техники. Не "КамАЗ 43118", "камаз-манипулятор" и "Камаз 43" в трех заявках, а один справочник с инвентарным номером. Тогда отчеты и путевые листы не развалятся на дубликаты.

Частые ошибки при запуске диспетчерского приложения

Главная причина провалов простая: приложение делают "как в теории", а потом люди вынуждены обходить его, чтобы успевать работать. В итоге веб-приложение для диспетчера спецтехники есть, а порядок в заявках и сменах не появился.

Что чаще всего ломает данные

Первая ошибка - слишком сложные статусы. Когда у заявки 10-12 состояний, люди начинают выбирать "примерно подходящее", и статистика превращается в шум.

Вторая боль - календарь без проверки конфликтов. Если система позволяет поставить одну и ту же машину на два объекта в один интервал, накладки просто меняют форму: вместо предупреждения заранее вы получаете срыв в день работ.

Третья ловушка - нет разделения "план" и "факт". Если в календаре записали 8 часов, а по факту отработали 6, это должно жить отдельно. Иначе отчеты выглядят красиво, но им нельзя верить.

Ошибки, которые легко исправить сразу

Путевые листы часто продолжают заполнять вручную, хотя большая часть полей уже есть в заявке и смене. Результат - опечатки, дубли и спорные закрытия.

Простои тоже нередко записывают "текстом в комментариях". Без причины и интервала вы не соберете нормальный отчет и не поймете, что повторяется.

Полезный минимум, который снижает хаос:

• 4-5 статусов на заявку (новая, подтверждена, в работе, выполнена, отменена)
• запрет пересечений по технике в календаре
• отдельные поля для плана и факта (время, объем, адрес)
• простой: причина из списка + интервал времени

Пример: экскаватор "свободен" по плану, но по факту задержался на час из-за поломки. Если план и факт разделены, вы видите реальную занятость и можете честно закрыть смену.

Короткий чеклист перед запуском в работу

Перед тем как отдавать приложение в ежедневное использование, проверьте его на реальных данных за 2-3 смены. Лучше поймать мелочи сейчас, чем потом разбирать споры по оплате и простоям.

Сначала проверьте основу: календарь и заявки. Календарь должен быть один на всю технику и показывать занятость без ручных "склеек" по разным таблицам. Диспетчер должен быстро отфильтровать технику по объекту и увидеть свободные окна.

Минимальный набор "проходит или нет":

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

Затем проверьте отчеты. Откройте одну неделю и убедитесь, что простои видны за пару кликов: не только часы, но и причины (ожидание на объекте, поломка, нет допуска, нет фронта работ). Если причина не обязательна, в отчетах быстро появится "пустота", и выводы станут бесполезными.

Добавьте тестовый сценарий: одна машина, два объекта, одна отмена и один простой. Такой "маленький хаос" лучше всего показывает, готова ли система к реальной смене.

Пример сценария: один день диспетчера без накладок

У диспетчера 6 единиц техники: 2 экскаватора, 2 самосвала, автокран и погрузчик. Работы идут на 3 объектах. В 16:30 прилетает срочная заявка: "Завтра к 8:00 нужен экскаватор и самосвал на объект Б, минимум на 6 часов".

Диспетчер открывает календарь занятости и сразу видит конфликт: экскаватор ЭК-12 уже стоит на объект А с 7:30. Здесь важно, чтобы пересечение было видно сразу, а решение фиксировалось в системе.

Диспетчер делает три быстрых действия: ставит срочной заявке высокий приоритет и пометку "на 8:00, без опозданий"; переносит менее приоритетную работу по объекту А на 10:00, добавляя причину переноса; назначает резервный экскаватор ЭК-09, а ответственным на объектах уходит уведомление с новым планом.

Утром бригадир на объекте Б видит назначение техники и отмечает старт смены. В 11:20 он фиксирует простой 40 минут: "ожидали доступ на площадку, не открыли ворота". Это важно, потому что простой влияет и на оплату, и на разговор с заказчиком, и на планирование.

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

Следующие шаги: как быстро собрать прототип и внедрить

Чтобы прототип появился быстро, начните с короткого списка того, что должно работать каждый день. Выпишите сущности (техника, объект, смена, заявка, путевой лист), статусы (новая, подтверждена, в работе, выполнена, отменена), роли (диспетчер, механик, бухгалтер, руководитель) и 2-3 отчета, без которых вы не можете закрывать смены.

Дальше выбирайте ядро. Для диспетчера спецтехники это почти всегда календарь занятости техники и подтверждение выполнения. Сначала сделайте так, чтобы в календаре было видно: кто занят, где, с какого по какое время, и что можно назначить без конфликтов. Затем добавьте честное закрытие работ: факт начала и окончания, подтверждение ответственным, причина простоя, комментарий.

План на 1-2 недели можно держать простым: 1) макет календаря (день/неделя), карточка заявки, назначение техники; 2) статусы и правила (например, нельзя назначить две смены на одно время); 3) подтверждение выполнения и фиксация факта по смене; 4) путевые листы и простой, затем базовые отчеты.

Если вы собираете прототип на платформе TakProsto (takprosto.ai), можно описать приложение в чате, включить planning mode и быстро собрать рабочий вариант. Для безопасных изменений пригодятся снапшоты и откат, а дальше - экспорт исходников и развертывание с хостингом и своим доменом.