Разбираем, как спроектировать веб-приложение для управления строительной техникой: модель данных, учет ТО и простоев, запчасти и AI-отчеты по TCO.
В строительной технике деньги часто «уезжают» тихо: плановое ТО забыли, простой не зафиксировали, запчасть списали без привязки к причине, а расходы разошлись по разным таблицам. Техника вроде бы работает, но быстро понять, где и почему теряются время и бюджет, не получается.
Обычно болят четыре зоны: обслуживание и графики ТО, простои и ремонты, запчасти и склад, расходы по конкретным объектам. Когда учет живет в Excel, чатах и бумажных актах, данные перестают совпадать: один и тот же ремонт может одновременно существовать в переписке у механика, в накладной у бухгалтерии и в таблице у прораба. Целостной картины нет, а значит нет и точных управленческих решений.
Руководителю важно видеть, какая техника приносит пользу, а какая «съедает» бюджет, и где она фактически работает. Механику нужно быстро фиксировать события (ТО, поломки, причины простоя, замену узлов), чтобы не держать все в голове. Бухгалтерии нужна понятная связка «событие -> документы -> расходы», чтобы списания и затраты не превращались в расследование.
Успех здесь простой: в любой день вы отвечаете на базовые вопросы без поиска по чатам и ручных сводок. Где сейчас каждая единица техники и в каком она состоянии? Сколько стоил месяц владения каждой машиной (ремонты, ТО, запчасти, простои)? На каких объектах возникли основные потери и почему? Какие поломки повторяются и что выгоднее: ремонтировать или менять подход?
Такое веб-приложение для управления строительной техникой дает не «еще одну форму ввода», а видимость: техника, события и деньги складываются в одну линию, по которой проще принимать решения.
Основа учета простая: есть единица техники, с ней происходят события, а у каждого события есть расходы. Если держать эту цепочку чистой, приложение остается понятным даже через год, когда данных станет много.
Единица техники должна быть уникальной и неизменной. Лучше сразу выбрать главный идентификатор (обычно инвентарный номер), а остальные хранить как дополнительные: VIN (если есть), госномер, серийный номер, номер двигателя. Ключевое правило: при смене госномера техника не превращается в «новую».
Событие - это запись в журнале, привязанная к конкретной технике и дате (часто еще к смене или моточасам). Не пытайтесь с первого дня заводить десятки типов. Обычно достаточно набора: ТО (плановое), ремонт (внеплановый), простой, перемещение (объект/база/аренда), заправка, осмотр (предсменный, приемка после ремонта).
Расходы лучше хранить не в карточке техники, а внутри события отдельными строками. Тогда не теряется детализация: в одном ремонте могут быть запчасти, работы подрядчика, эвакуация и аренда подменной техники. В строке расхода фиксируйте сумму, категорию, контрагента и документ (счет, акт), а также признак «план/факт».
Чтобы связь не ломалась, держите правило: расход относится к одному событию, а событие - к одной единице техники. Для сквозной аналитики добавьте минимальные справочники (типы событий, причины простоя, контрагенты, статьи затрат) - этого достаточно, чтобы аккуратно считать стоимость владения техникой.
Ошибки в полях обычно проявляются не сразу, а через месяц, когда нужно быстро ответить на вопрос «почему стояли» и «сколько это стоило». Поэтому лучше сразу заложить минимум, который дает поиск, отчеты и связь «техника -> событие -> расходы».
Карточка нужна не для красоты, а чтобы в один клик понять: где техника, в каком она состоянии и кто за нее отвечает. Обычно хватает:
Событие - это любая запись, к которой потом «прилипают» деньги и документы: ТО, ремонт, выезд механика, поломка, осмотр. У события держите дату/время, тип, короткий комментарий, исполнителя и вложения (акт, фото, счет). Важно, чтобы событие всегда было привязано к конкретной технике и, по возможности, к объекту.
Простой можно вести отдельным журналом или типом события, но добавьте причину, длительность и подтверждающего. Если для вас важны сроки проекта, полезна отметка, влияет ли простой на SLA/график.
По запчастям с самого начала заведите артикул, совместимость (с какими моделями), единицы измерения, цену и остаток. В расходах фиксируйте сумму, статью, способ оплаты и обязательную привязку к событию и объекту. Пример, который потом экономит часы: «экскаватор E-12, объект Север, событие Ремонт гидролинии, запчасть рукав, расход 18 500 RUB».
Даже удобная система быстро превращается в хаос, если у всех одинаковые права. Для старта обычно достаточно 4-5 ролей и простых статусов.
Разделите работу по принципу: кто фиксирует факт, кто подтверждает, кто отвечает за деньги. Механик создает события и описывает работы, диспетчер фиксирует простой и время, кладовщик списывает запчасти и подтверждает выдачу, руководитель утверждает спорные причины и дорогие работы, бухгалтер проверяет документы и закрывает период.
Финансы лучше показывать не всем. Механику и диспетчеру чаще достаточно трудозатрат, часов и списка работ. Цены, суммы, контрагенты и документы оставьте руководителю и бухгалтерии. При этом всем полезно видеть итоговый статус события, чтобы не дергать друг друга.
Согласования удобно держать на короткой схеме:
Для спорных случаев нужен журнал изменений: кто изменил, когда, что именно (поле и старое/новое значение), причина правки и связанные файлы. Это особенно помогает, когда уточняют длительность простоев или суммы по актам.
Если вы делаете прототип в TakProsto, роли и статусы логично заложить сразу в модель данных: тогда процесс держится в системе, а не в переписке.
Чтобы учет работал каждый день, опирайтесь на три повторяющихся сценария: регламентное ТО, ремонт по заявке и простой. Если запись занимает 1-2 минуты, данные будут полными. Если требует десяток полей и длинных комментариев, люди начнут пропускать события.
Регламентное ТО обычно планируют двумя способами: по моточасам (например, каждые 250 м/ч) и по календарю (раз в месяц или сезон). В карточке техники храните текущие моточасы и дату последнего ТО, а в журнале событий фиксируйте факт выполнения. Напоминания держите простыми: «подходит срок», «просрочено», «выполнено».
Ремонт по заявке удобнее вести короткими шагами: симптом -> диагностика -> решение -> результат. Важно разделять «что сломалось» и «что сделали», иначе статистика по причинам поломок превращается в шум. Итоговая стоимость складывается из работ, запчастей и внешних услуг, а не одной суммой в конце.
Простой учитывайте как время плюс причина. Привязка к объекту и смене помогает понять, где теряется производительность: на конкретной площадке, у конкретной бригады или из-за логистики. Например: «экскаватор простоял 6 часов в ночную смену на объекте N из-за ожидания гидрошланга».
Чтобы ввод занимал минуты, используйте шаблоны типовых работ (ТО-250: масло/фильтры/осмотр; замена шланга; диагностика гидравлики; выезд механика; приемка после ремонта). И сразу задайте правила корректировок: правка через «исправление», обязательная причина изменения, автоматический пересчет итогов и журнал, кто и когда менял данные.
Склад в учете техники нужен не ради «красивых остатков», а чтобы каждая трата была привязана к конкретному событию. Тогда ремонт перестает быть абстрактной суммой из чеков и становится понятной стоимостью по технике, объекту и периоду.
Начните с простого: карточка номенклатуры (фильтр, шланг, гидронасос) и журнал движений. Каждое движение отвечает на три вопроса: что, сколько, куда.
Типов операций обычно хватает пяти: приход, выдача в ремонт (списание на событие), возврат, перемещение между складами, инвентаризация (корректировка). Ключевое правило для аналитики: выдачу делайте не «в никуда», а строго на событие ремонта или обслуживания. В движении храните ссылку на событие, технику, исполнителя и документ-основание.
Заранее выберите понятные ограничения. Самый безопасный вариант - списывать только из наличия, а «минус» разрешать только отдельной ролью. Определите точку контроля: кто подтверждает выдачу со склада (кладовщик) и кто принимает расход в событие (механик/мастер).
С ценами не усложняйте, но зафиксируйте метод: последняя закупочная цена для быстрых расчетов или средняя цена, если поставки часто меняются. Для разовых позиций допустима ручная цена, но с обязательным комментарием.
В рабочем сценарии это выглядит так: мастер создал событие «ремонт гидролинии» для конкретного экскаватора, кладовщик выдал 2 шланга и фитинг, и позиции автоматически попали в расходы события. В отчете видно, из-за каких групп запчастей выросли ремонты и простои.
Чтобы веб-приложение для управления строительной техникой не превратилось в «табличку на все случаи», начните с короткого плана на 2-3 недели: договориться о терминах, собрать минимальные экраны, запустить пилот и только потом усложнять.
Сначала зафиксируйте модель и правила: словарь (единица техники, событие, простой, ремонт, ТО, заявка, заказ-наряд), обязательные поля (дата/время, объект, моточасы/пробег, причина, исполнитель, стоимость) и принцип, где живут расходы (внутри события: работы + запчасти) и как они подтверждаются.
Дальше соберите минимальный набор экранов. Лучше четыре работающих, чем двенадцать «на будущее»: список техники с поиском и фильтрами, карточка техники с текущим статусом и последними событиями, журнал событий со статусами, склад и списание в конкретное событие.
После этого добавьте базовые проверки (обязательные поля, запрет «закрыть ремонт без суммы», единые причины простоев) и 3-4 отчета для руководителя: простои по причинам, затраты по технике, ТО «скоро просрочится», расход запчастей.
Финальный шаг - роли и пилот на 1-2 объектах: механик вводит события, кладовщик списывает, руководитель утверждает. Если нужен отдельный периметр, заранее продумайте, как будете разворачивать решение и нужен ли экспорт исходников.
В TakProsto это обычно ускоряет запуск: платформу можно использовать для прототипа через чат, а затем при необходимости выгрузить исходный код и развернуть в своем контуре.
AI полезен не для самого учета, а для объяснения цифр. База должна считать и хранить события и суммы, а AI - собирать их в понятный отчет: где деньги уходят и почему.
Чаще всего хватает четырех срезов: TCO по единице техники, TCO по типу техники, TCO по объекту, TCO по месяцу.
Чтобы посчитать стоимость владения, сложите прямые расходы (ТО, ремонт, запчасти, расходники, услуги подрядчиков) и добавьте стоимость простоев. Методика простая: выбираете ставку простоя (например, аренда аналога в день или маржинальный вклад техники в смену) и умножаете на часы или дни простоя. Главное - закрепить одну методику и не менять ее от отчета к отчету.
Самая частая причина «красивого, но бесполезного» отчета - размытый запрос. Рабочий шаблон:
Отчет должен быть проверяемым: у каждой крупной цифры должна быть опора на первичные события. Практичный подход: AI пишет суммы и рядом выводит список ID событий (или номера заказ-нарядов) и правила расчета простоев.
Пример: «Экскаватор ЭК-12, декабрь: 420 000 руб прямых + 96 000 руб простои. Основание: ремонт гидролинии (события 1842, 1849), ожидание запчасти 2 дня по объекту Склад-3 (событие 1851)». Это легко сверить и поправить, если событие забыли закрыть или сумму внесли без документа.
Представим небольшую компанию: 5 единиц техники (2 экскаватора, погрузчик, каток, самосвал), 2 объекта (А и Б), 1 склад запчастей и 1 подрядчик по ремонту. Мы ведем учет в логике «единица техники -> события -> расходы» и смотрим стоимость владения за неделю.
Экскаватор ЭК-12 работает на объекте А. За неделю было четыре события: ТО-250 (масло, фильтры, 4 часа работы механика), ТО-500 (дополнительная диагностика, 1 день простоя), ремонт гидрошланга (подрядчик + расходники), простой из-за ожидания запчасти (шланг на складе закончился, ждали поставку 2 дня).
Дальше каждое событие превращается в расходы. По ЭК-12 получилось так (условные цифры): ТО-250 - 18 000 руб (материалы 10 000 + труд 8 000). ТО-500 - 42 000 руб (материалы 25 000 + труд 17 000) и дополнительно простой 1 день. Ремонт - 35 000 руб (подрядчик 25 000 + расходники 10 000). Простой из-за ожидания запчасти - 2 дня.
Если считать упрощенный TCO за неделю, складываем прямые расходы (95 000 руб) и стоимость простоя. Например, экскаватор приносит 60 000 руб выручки в день, тогда 3 дня простоя = 180 000 руб упущенной выручки. Итого по ЭК-12: 275 000 руб за неделю.
Выводы появляются сразу. Узкое место - склад: отсутствие одной позиции дало 2 дня простоя, а это дороже самого ремонта. Второй сигнал - повторяемость: если по двум экскаваторам за месяц дважды рвет шланги, проблема может быть в режиме работы, качестве расходников или в плановом осмотре.
После первого месяца обычно меняют процессы: вводят минимальные остатки по критичным запчастям, фиксируют причину поломки и фото, задают правило «ТО без закрытого чек-листа не закрывается», отдельно считают KPI по простоям (склад, подрядчик, отсутствие механика). Это дает не «красивые отчеты», а конкретные решения, где теряются деньги.
Самая частая причина, почему учет «не взлетает»: людям непонятно, что и где фиксировать, а потом никто не верит цифрам. Держите логику «единица техники -> событие -> расходы» и не ломайте ее в мелочах.
Ошибка 1 - разрыв между событием и деньгами. «Ремонт» записали как факт, но без привязанных работ и запчастей. Или наоборот: списали расходы на «ремонт», но не указали инцидент и длительность простоя. Итог один: TCO считается нечестно.
Ошибка 2 - отсутствие единого идентификатора техники. Если сегодня это «CAT 320», завтра «экскаватор 320», а в бухгалтерии «Инв-00417», история распадается. Один постоянный ID решает большую часть проблем с поиском и отчетами.
Ошибка 3 - простой ведут как текстовую заметку. Простой должен быть событием со временем начала и конца (или хотя бы длительностью), причиной и ответственным. Иначе вы увидите только «сломался», но не поймете, что именно съедает смены.
Ошибка 4 - слишком много статусов и согласований. Если на одно событие нужно пройти длинную цепочку подтверждений, люди начнут обходить систему. Оставьте минимум, который реально соблюдают.
Быстрая самопроверка:
Перед стартом важна не «красота интерфейса», а то, что данные будут сходиться. Если в первые две недели люди начнут вести учет по-разному, потом это сложно исправить.
Проверьте карточки техники: у каждой единицы должен быть уникальный номер и текущий статус (в работе, на обслуживании, в ремонте, в простое, списана). Статус меняется только через событие, иначе появятся «серые зоны».
Проверьте журналы событий и расходов: любые деньги (работы, аренда подменной техники, эвакуатор, расходники) должны быть привязаны к конкретному событию и периоду. Иначе отчеты по стоимости владения начнут спорить сами с собой.
Короткая проверка перед запуском:
Заранее закрепите роли: кто создает событие, кто подтверждает, кто закрывает итогами и документами. Если это не определить, события будут висеть открытыми, а деньги окажутся «вне периода».
Если собираете решение в TakProsto, полезно вынести этот чек-лист в отдельный экран администратора, чтобы правила были рядом с системой, а не в чате.
Чтобы веб-приложение для управления строительной техникой прижилось, начните с пилота, а не с «идеального учета». Выберите один объект и ограничьте состав: 10-20 единиц техники, один механик, один кладовщик, один руководитель. Цель пилота: проверить, что данные вводятся быстро, а отчеты помогают принимать решения.
Определите 2-3 отчета, ради которых все затевается: стоимость владения техникой по единице за период, простои по причинам, расходы на запчасти по типам работ. Если эти отчеты сходятся с реальностью, остальное можно докрутить позже.
Рабочая последовательность на 2-4 недели:
Если нужно быстро собрать прототип и посмотреть, как он ведет себя в реальной работе, можно использовать TakProsto (takprosto.ai): описать сущности и экраны в формате чата, а затем уточнять формы по замечаниям команды.
Когда пилот стабильно работает, планируйте масштабирование: роли и доступы, отдельный домен, деплой и регламент обновлений. Если есть требования ИБ или внутренняя разработка, заранее решите, нужна ли выгрузка исходного кода и как вы будете вести изменения после расширения на другие объекты.
Начните с одной понятной цепочки: единица техники → событие → расходы. Так вы всегда сможете объяснить, почему возникла трата и к какой машине и объекту она относится.
Выберите один неизменный идентификатор, чаще всего это инвентарный номер. Остальные номера (госномер, VIN, серийный) храните как дополнительные, чтобы смена госномера не «создавала» новую технику.
Достаточно базового набора: ТО (плановое), ремонт, простой, перемещение, заправка, осмотр. Расширяйте типы только когда упираетесь в невозможность сделать отчет или фильтр, а не «на всякий случай».
Фиксируйте простой как событие со временем начала и конца (или длительностью), причиной и подтверждающим. Если простой записан текстом без часов и причины, вы не поймете, что именно съедает смены и деньги.
Держите расходы внутри события отдельными строками: запчасти, работы, подрядчик, эвакуатор, аренда подменной техники. Тогда стоимость ремонта не превращается в одну «магическую сумму», и ее можно проверить по документам.
Списывайте со склада не «в никуда», а строго на конкретное событие. Тогда каждая выданная позиция автоматически становится частью расходов этого ремонта или ТО и попадает в аналитику по технике и объекту.
Дайте минимум ролей: механик создает и ведет события, кладовщик подтверждает выдачу запчастей, руководитель утверждает спорные причины и дорогие работы, бухгалтер закрывает документальную часть. Финансовые суммы лучше показывать ограниченному кругу, чтобы не мешать ежедневной работе.
Сделайте 3–4 статуса: черновик, на согласовании, закрыто, отменено. Добавьте журнал изменений, чтобы было видно, кто и почему менял длительность простоя или сумму, иначе доверие к цифрам быстро пропадет.
Обычно хватает четырех: затраты по технике за период, простои по причинам, ТО «подходит/просрочено», расход запчастей по типам работ или объектов. Важно, чтобы любой итог можно было расшифровать до конкретных событий и документов.
AI лучше использовать для объяснения и резюме, а не для «придумывания» данных: он должен брать закрытые события и суммы из системы и собирать выводы. Просите вывод с опорой на идентификаторы событий и правила расчета простоев, чтобы отчет можно было быстро сверить и исправить.
