В статье разберем, как спроектировать веб-приложение для диспетчера спецтехники: календарь занятости, подтверждение выполнения, путевые листы и простои.
Диспетчер спецтехники каждый день живет в режиме "срочно": пришла новая заявка, где-то сдвинули начало смены, у водителя поломка, заказчик просит перенести подачу, а бухгалтерии нужны данные по отработанным часам. При этом от диспетчера ждут простого результата: техника назначена вовремя, смены закрываются без споров, факты сходятся.
Задачи повторяются почти всегда: принять и уточнить заявку, подобрать машину и экипаж, проверить занятость, поставить в смену, отследить статус ("в пути/на объекте/в работе"), а затем закрыть смену по факту. Параллельно идут звонки, связь с механиком, поправки на погоду и пробки, фиксация договоренностей.
Проблемы начинаются там, где "система" - это таблица плюс несколько чатов. В таблице одно, в чате другое, по телефону третье. Статусы меняются на ходу, история правок теряется. Самое болезненное - конфликты по времени: одну и ту же технику назначили на два объекта или оставили "окно" между сменами, которое на деле съедает переезд.
Поэтому сначала стоит автоматизировать две вещи: календарь занятости техники и подтверждение выполнения. Календарь дает единый источник правды по времени, месту и назначению. Подтверждение защищает от "закрыли на словах": видно, кто подтвердил, когда, что именно выполнено и какие были отклонения.
Успех легко увидеть по простым признакам: меньше накладок и двойных назначений, быстрее согласования по заявкам и переносам, понятное закрытие смен без долгих разборов, прозрачные отчеты по простоям и причинам отклонений.
Когда эти основы стоят крепко, проще подключать шаблоны путевых листов и отчеты. AI здесь полезен, но он работает точнее, когда факты уже собраны в календаре и подтверждениях.
Частая ошибка на старте - пытаться учесть все сразу: топливо, склад, ремонты, штрафы, бухгалтерию. Для первого релиза веб-приложения для диспетчера спецтехники хватит данных, которые отвечают на три вопроса: какая техника свободна, где она нужна и как честно закрыть выполненную работу.
Начните с коротких справочников, удобных для выбора из списка, а не для "энциклопедии".
По технике обычно достаточно: название/номер, тип, базовая сменная стоимость (если нужно) и признак "в ремонте". По экипажам - ФИО, телефон и привязка к технике (если постоянная). По объектам - адрес и контакт на месте. По контрагентам - название и ответственное лицо. По видам работ - короткие названия, понятные диспетчеру (например, "вывоз грунта", "погрузка", "планировка").
Заявка - ядро. В ней фиксируется минимум, без которого начинается путаница: кто заказал, объект, дата и время, какая техника нужна, ожидаемая длительность, условия (пропуск, режим, точка въезда) и комментарий. Если в заявке нет "когда" и "сколько по времени", календарь занятости техники нормально не заработает.
Дальше нужна сущность "смена/рейс" для плана и факта. В плане храните назначенную технику и ответственных. В факте - реальное время начала/окончания, короткий комментарий и, при необходимости, подтверждение: отметка диспетчера, фото или подпись на объекте.
Чтобы все двигалось по понятным правилам, используйте короткую цепочку статусов: черновик -> согласовано -> назначено -> в работе -> выполнено -> подтверждено. Отмена должна быть отдельным статусом, а не "стерли и забыли". Иначе отчеты и разбор конфликтов превращаются в спор на словах.
Календарь должен отвечать на один вопрос за 5 секунд: какая техника свободна прямо сейчас и что будет через пару часов.
Хорошо работает связка из трех режимов: день, неделя, месяц. День нужен для плотных перестановок, неделя - чтобы видеть загрузку бригад и объектов, месяц - для планирования и отпусков операторов. Рядом держите список заявок, чтобы диспетчер не бегал по вкладкам: заявку можно взять из списка и сразу поставить в сетку.
Карточки в календаре делайте простыми: техника, объект, время, ответственное лицо. Цвета лучше привязать к статусу, а не к типу техники - при большом парке иначе все будет пестреть. Например: свободна (серый), забронирована (синий), в работе (зеленый), ожидает подтверждения (желтый), отменена или перенос (красный).
Самое важное - проверка конфликтов. Если один экскаватор поставили на 10:00 в два разных места, система должна подсветить пересечение сразу, еще до сохранения. Полезно показывать причину: пересечение по времени, техника уже закреплена за другим объектом, слишком мало времени на переезд.
Для ежедневной работы важны быстрые действия. Обычно достаточно пяти:
Фильтры держите под рукой: по типу техники, объекту, диспетчеру, статусу, контрагенту. Типичный пример: утром звонит заказчик и просит фронтальный погрузчик на 14:00. Диспетчер включает фильтр по типу, видит свободные слоты, сдвигает одну заявку на 30 минут и уходит без конфликтов.
Когда смена закрывается одним нажатием, почти всегда возникают вопросы: техника реально была на объекте, отработала нужные часы, простой согласован, допработы учтены? Поэтому лучше разделять два факта: работа выполнена и работа подтверждена.
Порядок держит простая логика: "выполнено" и "подтверждено". Статус "выполнено" ставит тот, кто завершил смену по факту (водитель, бригадир, прораб). А "подтверждено" ставит тот, кто принимает результат и берет ответственность за закрытие (заказчик, прораб, старший смены или диспетчер - как принято в компании). Это снимает споры в конце месяца: видно, где работа закончилась, а где еще нет приемки.
Подтверждение должно быть однозначным. Выберите 1-2 способа и используйте их везде: подпись (электронная или фото подписи на бумаге), код подтверждения (например, код от прораба), отметка "подтверждаю" + короткий комментарий, прикрепленный файл (фото техники на объекте, акт, путевой лист).
При подтверждении просите минимум данных, иначе шаг начнут пропускать. Обычно хватает: фактических часов, простоя (если был) и короткого комментария. Пробег/моточасы добавляйте только если они реально нужны дальше.
Спорные случаи лучше вести не перепиской, а через понятный возврат. Если заказчик не согласен, заявка уходит "на доработку" с обязательной причиной (например, "не совпали часы" или "не было на объекте"). После исправления идет повторное подтверждение, а в истории остается цепочка: кто и когда менял факты.
Чтобы веб-приложение для диспетчера спецтехники не превращалось в смесь звонков и сообщений, зафиксируйте единый маршрут заявки. На каждом шаге меняется статус и появляется конкретный набор полей, которые нужно заполнить.
Рабочая схема выглядит так:
Мини-сценарий: клиент просит погрузчик на 4 часа, но в календаре он занят до 14:00. Вы ставите черновик на 15:00-19:00, согласовываете, назначаете экипаж. По факту работа заняла 3 часа и был простой 30 минут из-за ожидания допуска - это попадает в отчет, а закрытие смены происходит только после подтверждения.
Путевой лист часто превращается в ручную переписку данных из заявки, смены и табеля. Удобнее, когда документ собирается из уже введенных данных, а человек только проверяет и дополняет то, чего не хватает.
Начните с набора, который подходит большинству компаний: техника (тип, бортовой номер), водитель (ФИО, табельный номер), объект или маршрут (адрес, заказчик), время (выезд, начало, окончание, возврат), задания (что делали, объем), расход (топливо, моточасы или пробег).
Дальше подготовьте 2-3 шаблона под разные сценарии: смена на объекте (например, кран на стройке), рейсы (самосвал с несколькими ходками), аренда с экипажем (когда важны часы и простои).
Чтобы AI сделал шаблон путевого листа корректно, задайте правила, а не общую просьбу. Зафиксируйте обязательные поля, формат дат и времени, правила нумерации, откуда брать значения (из заявки, смены, справочников) и что оставлять пустым для ручного ввода.
Практичный вариант: заявка уже содержит объект, технику и плановое время. После смены водитель добавляет фактическое время и расход. На основе этих данных AI формирует документ и короткий блок "отклонения от плана" (опоздание, переработка, простой).
Сразу предусмотрите печать и выгрузку в PDF, а также историю версий: кто и когда правил документ и что изменилось.
Простой начинается там, где техника должна работать, но не работает. Если это не фиксировать, кажется, что "все заняты", а деньги уходят в ожидания и срывы. Простой лучше учитывать так же строго, как смену: с интервалом времени, причиной и подтверждением.
Важно заранее договориться о правилах: что считать простоем. Обычно это ожидание на объекте (нет фронта работ), поломка или обслуживание, нет доступа (пропуск, охрана, перекрытия), нет материалов или людей для разгрузки, погода (если реально остановила работу).
Для записи простоя не нужны длинные тексты. В карточке простоя достаточно:
Отчеты, которые помогают в работе, обычно строятся по технике, объектам, причинам и контрагентам. Например, за неделю видно, что один объект дает больше всего ожиданий из-за пропусков, а другой - из-за отсутствия материалов.
Когда людей много, а одна и та же техника фигурирует в десятках заявок, хаос появляется не из-за "сложной системы", а из-за размытых ролей и прав. Даже если календарь удобный, без правил данные быстро станут недостоверными.
Обычно хватает пяти ролей. Диспетчер ведет заявки и календарь занятости техники. Руководитель смотрит картину целиком и решает спорные случаи. Механик отвечает за техсостояние и отметки "в ремонте/готово". Бухгалтерия фиксирует то, что влияет на оплату: смены, часы, простои, подтверждения. Заказчику доступ нужен не всегда, но иногда полезен личный кабинет только для просмотра статуса и подтверждения выполнения.
Права лучше задавать по шагам процесса:
Журнал изменений обязателен: кто поменял время, технику, статус и почему. Причину отмены или переноса лучше выбирать из справочника, а не писать каждый раз по-разному.
Порядок в данных начинается с обязательных полей: объект, контакт, техника (или класс техники), дата и время, длительность, ответственный, статус. И еще важное - единые названия техники. Не "КамАЗ 43118", "камаз-манипулятор" и "Камаз 43" в трех заявках, а один справочник с инвентарным номером. Тогда отчеты и путевые листы не развалятся на дубликаты.
Главная причина провалов простая: приложение делают "как в теории", а потом люди вынуждены обходить его, чтобы успевать работать. В итоге веб-приложение для диспетчера спецтехники есть, а порядок в заявках и сменах не появился.
Первая ошибка - слишком сложные статусы. Когда у заявки 10-12 состояний, люди начинают выбирать "примерно подходящее", и статистика превращается в шум.
Вторая боль - календарь без проверки конфликтов. Если система позволяет поставить одну и ту же машину на два объекта в один интервал, накладки просто меняют форму: вместо предупреждения заранее вы получаете срыв в день работ.
Третья ловушка - нет разделения "план" и "факт". Если в календаре записали 8 часов, а по факту отработали 6, это должно жить отдельно. Иначе отчеты выглядят красиво, но им нельзя верить.
Путевые листы часто продолжают заполнять вручную, хотя большая часть полей уже есть в заявке и смене. Результат - опечатки, дубли и спорные закрытия.
Простои тоже нередко записывают "текстом в комментариях". Без причины и интервала вы не соберете нормальный отчет и не поймете, что повторяется.
Полезный минимум, который снижает хаос:
Пример: экскаватор "свободен" по плану, но по факту задержался на час из-за поломки. Если план и факт разделены, вы видите реальную занятость и можете честно закрыть смену.
Перед тем как отдавать приложение в ежедневное использование, проверьте его на реальных данных за 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 и быстро собрать рабочий вариант. Для безопасных изменений пригодятся снапшоты и откат, а дальше - экспорт исходников и развертывание с хостингом и своим доменом.
Начните с двух модулей: календаря занятости техники и процесса подтверждения выполнения. Календарь дает единый источник правды по времени и назначению, а подтверждение защищает от закрытия «на словах» и упрощает разбор спорных часов.
Минимум — это справочники (техника, экипажи, объекты, контрагенты, виды работ), заявка и смена (план/факт). В заявке обязательно должны быть дата/время и ожидаемая длительность, иначе календарь не сможет нормально проверять занятость.
Держите короткую цепочку: черновик → согласовано → назначено → в работе → выполнено → подтверждено, плюс отдельный статус «отменено». Такой набор обычно покрывает реальную работу и не заставляет людей выбирать «примерно подходящее» состояние.
Проверка должна срабатывать до сохранения: пересечение по времени, занятость техники на другом объекте, недостаток времени на переезд между сменами. Полезно показывать причину конфликта, чтобы диспетчер сразу понимал, что именно нужно изменить.
Карточка должна быть очень короткой: техника, объект, время, ответственный и статус. Цвета лучше привязать к статусу (свободна, забронирована, в работе, ожидает подтверждения), чтобы при большом парке не было «пестроты» и ошибок чтения.
Разделяйте «выполнено» и «подтверждено». «Выполнено» ставит тот, кто фиксирует факт завершения, а «подтверждено» — тот, кто принимает результат и берет ответственность за закрытие, чтобы в конце месяца не было споров по часам.
Выберите 1–2 способа и используйте везде: код подтверждения, фото подписи, отметка «подтверждаю» с коротким комментарием или файл (фото/акт). Просите минимум: фактические часы, простой (если был) и короткий комментарий, иначе шаг начнут пропускать.
Фиксируйте простой отдельной записью с интервалом времени и причиной из списка, а не текстом в комментариях. Тогда отчеты покажут, где повторяются проблемы (допуски, отсутствие фронта работ, поломки), и это можно использовать в переговорах и планировании.
Соберите путевой лист из уже введенных данных: техника, водитель, объект, план/факт времени, задания и расход, а человек пусть только проверит и добавит недостающее. Если подключаете AI, задайте четкие правила: обязательные поля, формат дат, источники данных и что оставлять пустым для ручного ввода.
Сделайте роли и ограничения по шагам процесса: диспетчер планирует и назначает, механик блокирует технику на ремонт, заказчик подтверждает, руководитель утверждает правки задним числом, бухгалтерия финально закрывает для расчета. Обязателен журнал изменений (кто, что, когда и почему), иначе данные быстро перестанут быть надежными.
