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

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

Отсюда первая беда: ошибки, которые не видно. В документе, собранном из чужого, остаётся чужое: реквизит, срок, формулировка условия. Такая ошибка не подсвечивается красным, она просто уезжает клиенту и обнаруживается тогда, когда обнаруживается.

Вторая беда это согласование. Документ уходил в почту и в мессенджеры, правки возвращались вразнобой: кто-то присылал файл, кто-то абзац текстом, кто-то отвечал «ок» на письмо недельной давности. Собрать из этого одну версию было отдельной работой, и делал её автор документа по памяти.

Третья вытекала из второй: вопрос «какая версия последняя» не имел технического ответа. На дисках лежали файлы с именами вроде «итоговый», «итоговый_2», «финал_правки»; в почте лежали вложения разной свежести. Ответ узнавали у человека, а человек мог быть в отпуске.

И четвёртая, самая неприятная при разборе: восстановить, как документ пришёл к нынешнему виду, было нельзя. Кто настоял на формулировке, когда поменяли условие, почему в итоге согласовали именно это: всё это существовало в переписке, разбросанной по личным ящикам участников.

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

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

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

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

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

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

Почта в этой работе не канал уведомлений, а место, где документ на самом деле обсуждается. Поэтому интеграция с корпоративной почтой компании на Яндекс 360 делалась в обе стороны, а не как рассылка писем из системы.

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

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

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

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

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

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

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

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

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

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

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