Почему заявки в мессенджерах не заменяют систему управления спецтехникой

Почему чат кажется удобным на небольшом объёме

Для единичной заявки сообщение действительно является простым способом коммуникации.

Например:

«На объект 12 августа нужен экскаватор с 8:00 до 18:00».

Отправитель передал заявку.

Получатель её увидел.

Если обе стороны хорошо знают условия работы, дополнительная информация может не потребоваться.

При небольшом количестве машин и постоянных участниках значительная часть данных существует в памяти сотрудников:

• адрес объекта известен;
• Подрядчик знаком;
• тариф помнят;
• водитель уже работал;
• договор один;
• изменения обсуждаются в том же чате.

Такая модель работает до тех пор, пока количество связей остаётся небольшим.

Что меняется при росте количества заявок

С ростом операций одна заявка перестаёт быть одним сообщением.

К ней добавляются:

• уточнение времени;
• изменение количества техники;
• выбор Подрядчика;
• согласование тарифа;
• назначение машины;
• замена машины;
• назначение экипажа;
• подтверждение;
• отказ;
• изменение задания;
• данные фактического выполнения.

В результате исходное сообщение становится только первой точкой длинной переписки.

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

Потеря заявки в потоке сообщений

Мессенджер организует информацию хронологически.

В одном чате последовательно появляются:

• заявки;
• фотографии;
• комментарии;
• документы;
• вопросы;
• изменения;
• сообщения по другим объектам.

У заявки нет собственного обязательного жизненного цикла.

Она может остаться без ответа и при этом продолжать существовать в истории чата.

Информационная система использует другой принцип.

Заявка существует как отдельная запись с номером, периодом, участком, ответственным лицом и статусом.

В StillDoc подтверждены статусы от «Новая» и «В работе» до исполнения, частичного исполнения, отмены и неисполнения.

Сообщение не равно статусу

Фраза:

«Экскаватор завтра будет»

не определяет формального состояния операции.

Она может означать:

• Подрядчик увидел заявку;
• Подрядчик предварительно согласился;
• машина назначена;
• водитель назначен;
• заказ окончательно подтверждён.

Для каждого участника смысл может различаться.

В системе статусы разделяются.

StillDoc отдельно ведёт состояние заявки и связанных заказов. Подрядчик подтверждает конкретный заказ после назначения экипажа.

Так подтверждение существует не в тексте сообщения, а в состоянии операции.

Нет единого статуса по нескольким машинам

Одна заявка может включать несколько единиц техники.

Например:

• 2 экскаватора;
• 4 самосвала;
• 1 погрузчик.

В чате ответы могут поступать от нескольких Подрядчиков в разное время.

Часть техники подтверждена.

Часть ещё ищется.

Одна машина заменена.

Один Подрядчик отказался.

В результате общий статус приходится собирать вручную.

В StillDoc заявка объединяет несколько назначений, и для каждого видны статусы от подтверждения до выполнения.

Поэтому частичное исполнение можно отделить от полного подтверждения или полного отказа.

Нет автоматической связи с договором

Сообщение о заявке не проверяет, на основании какого договора будет работать Подрядчик.

Договор приходится искать отдельно.

В нём могут находиться:

• срок действия;
• тариф;
• НДС;
• единица измерения;
• условия оплаты;
• правила оплаты дороги;
• другие коммерческие условия.

В StillDoc подрядная техника связана с договором, а техника и тарифы используются непосредственно при подборе.

Это означает, что назначение машины сохраняет связь с договором.

В чате такая связь существует только если сотрудник самостоятельно её поддерживает.

Нет автоматической связи с тарифом

Тариф может изменяться:

• по договору;
• по типу техники;
• по периоду;
• по единице измерения;
• по условиям конкретного контрагента.

Если заявка оформляется сообщением, значение тарифа приходится брать из другого источника.

Например, из:

• договора;
• таблицы;
• предыдущей переписки;
• внутренней памяти сотрудника.

В StillDoc у подрядной техники тариф связан с договором и конкретной машиной.

Так стоимость заявки рассчитывается на основе структурированных условий.

Изменение тарифа в переписке

Отдельная проблема возникает, если коммерческие условия уточняются в ходе согласования.

Первоначально:

5 000 ₽/час

Позже:

5 500 ₽/час из-за работы в ночную смену

Ещё позже меняется машина.

Для определения фактической стоимости требуется восстановить всю последовательность и понять, какое условие относится к итоговому исполнителю.

В системе тариф фиксируется как параметр конкретного назначения и заказа.

Это уменьшает зависимость от интерпретации переписки задним числом.

Мессенджер не проверяет доступность техники

Сообщение может быть отправлено сразу нескольким исполнителям.

Но мессенджер не знает:

• занята ли машина на другом объекте;
• пересекаются ли интервалы;
• назначен ли экипаж;
• есть ли другой заказ на это же время.

Эти проверки выполняет человек.

Поэтому масштабирование количества заявок увеличивает нагрузку именно на память и внимание сотрудников.

В продуктовой модели StillDoc предусмотрена проверка доступности техники и экипажей на необходимый период.

Одна машина в двух заявках

Типовой конфликт возникает при параллельном планировании.

Первый объект запросил экскаватор на 8:00–14:00.

Второй — на 12:00–18:00.

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

Структурированная система сопоставляет назначения по времени.

Чат самостоятельно такой проверки не выполняет, даже если в нём идеально сохранена вся переписка.

Нет связи с фактическим экипажем

Первоначально в сообщении может быть согласована только машина.

Фактический водитель или машинист назначается позже.

Если экипаж меняется, появляется ещё одно сообщение.

Для документооборота требуется уже фактическая связка:

заявка → назначенная машина → экипаж.

В StillDoc Подрядчик подтверждает назначение после выбора сотрудника экипажа.

Таким образом, человек, который фактически работает на технике, становится частью структуры операции.

История остаётся у конкретного сотрудника

Даже корпоративный чат не всегда создаёт полноценную корпоративную историю процесса.

Информация может быть распределена между:

• личными сообщениями;
• групповым чатом;
• звонками;
• электронной почтой;
• голосовыми сообщениями.

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

Другому сотруднику приходится восстанавливать эту логику по фрагментам.

В системе история сохраняется в карточках заявки и заказа.

Человек может смениться, но запись о процессе остаётся.

Передача дел другому диспетчеру

При смене сотрудника особенно заметна разница между коммуникацией и системой.

В чате новый диспетчер получает архив сообщений.

Но ему всё равно требуется понять:

• какие заявки активны;
• какие машины подтверждены;
• где были отказы;
• какие тарифы действуют;
• где ожидается решение;
• какие документы уже сформированы.

В StillDoc текущий статус существует независимо от того, какой сотрудник открыл систему.

Это превращает историю из личного знания в данные компании.

Мессенджер не знает структуру заявки

В сообщении можно написать любую информацию.

Например:

«Завтра три КамАЗа на карьер».

Но система не может гарантировать наличие обязательных параметров.

Может отсутствовать:

• точный адрес;
• время;
• период;
• ответственный;
• объём;
• маршрут;
• конкретный тип техники;
• Подрядчик;
• тариф.

Структурированная заявка задаёт необходимую модель полей.

В StillDoc позиция заявки связывается с участком или маршрутом, ответственным лицом и конкретной машиной.

Задания остаются в тексте

Дополнительные работы часто согласуются отдельными сообщениями:

«После котлована пусть ещё планировку сделает».

Если информация не переносится в отдельный учёт, задание остаётся частью переписки.

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

В StillDoc задания можно указывать уже при создании заявки и связывать с конкретной техникой.

Так задание существует как часть операции, а не только как текст сообщения.

Изменения сложно отделить от исходных данных

Любая заявка может измениться.

Например:

10:00 — нужна машина на 8 часов.

11:20 — время изменили на 12:00.

13:10 — вместо одной машины нужны две.

15:30 — вторую отменили.

17:00 — поменялся участок.

Переписка сохраняет всю историю.

Но для выполнения требуется не история как таковая, а актуальное состояние.

Структурированная система хранит текущие поля заявки и одновременно фиксирует соответствующие действия.

Документы живут отдельно

Даже если заявка успешно согласована в чате, путевой лист или другой документ обычно создаётся в другом месте.

Тогда сотрудник снова переносит:

• технику;
• дату;
• экипаж;
• маршрут;
• задания;
• Подрядчика;
• фактическое время.

Связь между заявкой и документом приходится поддерживать вручную.

В StillDoc путевой лист связан с конкретным заказом, техникой и экипажем.

Поэтому данные переходят из работы компании в документооборот.

Нет автоматического реестра заявок

Для анализа заявок из мессенджера сначала требуется превратить переписку в таблицу.

Нужно выделить:

• дату;
• объект;
• тип техники;
• Подрядчика;
• статус;
• стоимость;
• результат выполнения.

То есть перед аналитикой выполняется отдельная ручная работа по структурированию сообщений.

Если заявка изначально является структурированной записью, её параметры уже доступны для фильтрации и агрегирования.

Нет нормальной аналитики по отказам

Из чатов сложно автоматически получить ответы на вопросы:

• сколько заказов Подрядчики отклонили;
• сколько отменено Заказчиком;
• сколько не подтверждено;
• сколько выполнено частично;
• какой Подрядчик чаще отказывается;
• по каким объектам возникают проблемы.

В StillDoc причины и типы завершения заказа существуют в структуре статусов.

Это позволяет использовать операционные события как источник аналитики без предварительного разбора переписки.

Мессенджер и файлы

В заявке могут появляться:

• фотографии;
• документы;
• схемы;
• файлы договора;
• дополнительные материалы.

В чате файл связан прежде всего с сообщением и датой отправки.

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

Так принадлежность файла определяется не только соседними сообщениями.

Мессенджер не заменяет диспетчеризацию

Чат может использоваться для общения диспетчеров.

Но он не выполняет функции диспетчерской системы:

• не ведёт список доступной техники;
• не сопоставляет его с договорами;
• не ведёт статусы назначения и выполнения;
• не контролирует подтверждение;
• не связывает машину с экипажем;
• не переводит фактическое выполнение в документы.

Поэтому мессенджер может оставаться дополнительным каналом коммуникации, но не становится системой управления техникой.

Когда чата уже недостаточно

Проблема определяется не конкретным количеством машин.

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

Основные признаки:

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

Чем больше таких операций, тем выше зависимость процесса от конкретных сотрудников.

Как выглядит тот же процесс в StillDoc

1. Создание заявки

Фиксируются участок или маршрут, дата или период, ответственный сотрудник и необходимая техника.

2. Выбор техники

Используется собственная или подрядная машина.

Для Подрядчика учитываются договор и тариф.

3. Назначение техники

Внутри заявки фиксируется конкретное назначение техники.

4. Подтверждение Подрядчиком

Назначается экипаж. Заказ принимается или отклоняется.

5. Контроль статуса

Для заявки и каждой назначенной машины видны отдельные статусы.

6. Фактическое выполнение

Фиксируются время, задания, маршрут, пробег, простои и другие показатели.

7. Документы

Путевой лист связан с конкретным заказом и фактической работой.

В результате одна операция сохраняется как связанная цепочка данных, а не как набор сообщений.

Мессенджер и StillDoc решают разные задачи

Мессенджер остаётся удобным средством коммуникации.

Он подходит для:

• быстрого вопроса;
• уточнения;
• уведомления;
• оперативного обсуждения.

Система управления решает другой класс задач:

• фиксирует данные;
• контролирует статусы;
• связывает договоры;
• проверяет доступность техники;
• хранит фактическое назначение;
• передаёт данные в документы;
• создаёт историю процесса.

Поэтому переход от чатов к системе не означает отказ от коммуникации.

Меняется место, где хранится истина об операции.

Как заявка связывает этапы в StillDoc

В StillDoc заявка не является сообщением и не заканчивается после передачи Подрядчику.

Она запускает последовательность:

Заявка → Подтверждение → Документы → Выполнение.

Для подрядной техники перед назначением присутствует ещё и связь с договором:

Договор → Заявка → Подтверждение → Документы → Выполнение.

За счёт этого данные сохраняют связь на протяжении всего процесса работы со спецтехникой.

Источники

• Текущий интерфейс StillDoc
• Продуктовые сценарии StillDoc