Подобрать решение
ЗАКАЗАТЬ ОБРАТНЫЙ ЗВОНОК
Внедрение документооборота при сложной оргструктуре и меняющихся требованиях
В проектах автоматизации редко все идет по прямой. Особенно тогда, когда компания пытается решить слишком много задач одновременно, а внутри нет выделенного заказчика, который задает вектор и принимает финальные решения. В таких условиях проект легко уходит в сторону: требования меняются, бюджеты «плавают», а персонал не понимает, зачем нужна новая система.
Этот кейс — о том, как важно управлять ожиданиями, фокусом и вовлеченностью команды заказчика. И о том, что даже в подобных ситуациях бобдей способен довести проект до результата.
Этот кейс — о том, как важно управлять ожиданиями, фокусом и вовлеченностью команды заказчика. И о том, что даже в подобных ситуациях бобдей способен довести проект до результата.
Сроки проекта: Февраль 2025 - Сентябрь 2025
Содержание
-
О заказчике - Контекст: как стартовал проект
- Исходные условия, которые сделали проект нетипично сложным
- Как фрагментарность решений отражалась на проекте: примеры
- Сложные участки проекта
- Почему проект потерял фокус
- Как бобдей удержал управляемость проекта
- Что проект автоматизации дал компании: эффекты
- Что могло бы быть иначе
- Итог
О заказчике
Компания — крупная транспортно-логистическая группа, работающая с мультимодальными перевозками и большим массивом договорной и претензионной деятельности. Внутри много лет функционировала система «управление экспедированием» — фактически единая платформа, в которой велись:
- управление заказами и операционной деятельностью по экспедированию,
- финансовые процессы и элементы казначейства,
- часть документооборота и внутренняя логика согласований.
Со временем система превратилась в сложно поддерживаемый монолит, который десятилетиями переписывался под точечные потребности подразделений. В результате:
- любое изменение стоило дорого,
- часть доработок было невозможно реализовать технически,
- отчетность давала искажения,
- поддержка занимала все больше ресурсов,
- единых процессов внутри компании не было.
Старый «пузырь» лопнул
ИТ-дирекция понимала: продолжать поддерживать созданную много лет назад систему больше нельзя — нужен новый масштабируемый инструмент, который сможет выдерживать рост компании и требования руководства к прозрачности данных.
Контекст: как стартовал проект
Первоначально компания рассматривала внедрение 1С:Управление холдингом. Обсуждения шли в несколько итераций — но в итоге решение о покупке УХ было принято самостоятельно, без участия бобдей. Мы присоединились позже, когда система уже была приобретена.
Когда началось обследование под УХ, стало очевидно, что типовой функционал УХ закрывает финансовый контур, но не покрывает ключевые потребности компании по договорам, доверенностям, претензиям и сложной дивизиональной оргструктуре.
При попытке «дотянуть» 1С: УХ до требуемого уровня стало понятно: объем доработок будет несоразмерным. Поэтому появился отдельный проектный поток по документообороту. Это стало первым признаком того, что фокус проекта начинает распыляться.
Когда началось обследование под УХ, стало очевидно, что типовой функционал УХ закрывает финансовый контур, но не покрывает ключевые потребности компании по договорам, доверенностям, претензиям и сложной дивизиональной оргструктуре.
При попытке «дотянуть» 1С: УХ до требуемого уровня стало понятно: объем доработок будет несоразмерным. Поэтому появился отдельный проектный поток по документообороту. Это стало первым признаком того, что фокус проекта начинает распыляться.
Исходные условия, которые сделали проект нетипично сложным
Старая система работала для пользователей, но не для бизнеса
Для пользователей текущий инструмент оставался удобным и привычным: интерфейс «родной», логика знакомая, обходные пути отлажены. Но руководящий состав не мог получить прозрачный и надежный контур учёта договоров, согласований и претензий. То, что работает сегодня, уже не отвечало стратегическим задачам компании.
Пользователи воспринимали новое решение с негативом. Так как компания не проводила коммуникаций о целях перехода:
Пользователи воспринимали новое решение с негативом. Так как компания не проводила коммуникаций о целях перехода:
- пользователи сравнивали каждую функцию «один в один» со старой системой,
- требовали вернуть скрытые механики,
- воспринимали изменения как ухудшение, а не как улучшение.
Фактически проект шел без поддержки снизу, что критично для внедрения документооборота.
Не было владельца процесса
Ни один руководитель не нес ответственности за то, как должен выглядеть согласованный процесс договоров, доверенностей или претензий.
Решения приходили:
В каждом подразделении был свой взгляд. И каждый новый созвон мог менять направление работ.
Решения приходили:
- от ИТ-директора,
- от бухгалтерии,
- от юристов,
- от делопроизводства,
- от внешних консультантов.
В каждом подразделении был свой взгляд. И каждый новый созвон мог менять направление работ.
Параллельно шли несколько обследований
Одновременно велись работы:
Такой поток разных вводных создавал постоянные точки пересборки и менял работу команды на каждом этапе.
- по централизации финансов,
- по новой логистической системе,
- по документообороту,
- по описанию бизнес-процессов внешним консультантом.
Такой поток разных вводных создавал постоянные точки пересборки и менял работу команды на каждом этапе.
Знакомые проблемы?
Если в вашей компании есть процессы, которые невозможно закрыть стандартными инструментами, оставьте заявку. Мы разберем текущую архитектуру, оценим ограничения и предложим вариант разработки специализированного решения, которое безопасно встроится в ваши системы и не нарушит работу бизнеса.
Как фрагментарность решений отражалась на проекте: примеры
Пример 1. Требования передавались частями
Маршруты согласования менялись от встречи к встрече: появлялись новые роли, новые правила переходов, новые исключения — это ломало архитектуру. Любой собранный процесс приходилось пересобирать.
Пример 2. Переход «как в старой системе»
Пользователи открывали старую систему рядом и требовали повторить:
- названия кнопок,
- последовательность действий,
- устаревшую логику, не соответствующую современным требованиям.
Пример 3. Решения принимались разными людьми
Одни участники соглашались на типовую функциональность, другие — через несколько дней — требовали вернуть предыдущие договорённости. Без владельца процесса итоговые договоренности не закреплялись и теряли силу, из-за чего направление проекта могло меняться от встречи к встрече.
Сложные участки проекта
1
Сложнейшая дивизиональная оргструктура и маршрутизация: филиалы, дивизионы, пересечения ролей, когда сотрудник одновременно принадлежал нескольким единицам.
Маршруты согласования зависели от: типа договора, вида операции, положения сотрудника в нескольких структурах, дополнительных аналитик.
Чтобы маршрутизация корректно работала, требовалось построить алгоритмы, учитывающие сочетание факторов. Это нетривиальная задача для любого проекта документооборота.
Маршруты согласования зависели от: типа договора, вида операции, положения сотрудника в нескольких структурах, дополнительных аналитик.
Чтобы маршрутизация корректно работала, требовалось построить алгоритмы, учитывающие сочетание факторов. Это нетривиальная задача для любого проекта документооборота.
2
Многоязычные документы. Компания использовала: русские, английские и китайские договоры.
Нужно было настроить автозаполнение многоязычных шаблонов. Тестировать корректность китайских документов было невозможно без участия представителя заказчика, поэтому процесс включал дополнительное согласование и проверки.
Нужно было настроить автозаполнение многоязычных шаблонов. Тестировать корректность китайских документов было невозможно без участия представителя заказчика, поэтому процесс включал дополнительное согласование и проверки.
3
Претензионная работа: полный перезапуск
Процесс претензий был настроен один раз — но после демонстрации заказчик понял, что собственная логика противоречива. Маршруты и роли пришлось переработать полностью. Этот блок стал одним из наиболее ресурсоемких.
Процесс претензий был настроен один раз — но после демонстрации заказчик понял, что собственная логика противоречива. Маршруты и роли пришлось переработать полностью. Этот блок стал одним из наиболее ресурсоемких.
Почему проект потерял фокус
Компания хотела автоматизировать сразу все направления, связанные с документооборотом: договоры, доверенности, претензии, интеграции, сложную ролевую модель, автозаполнение многоязычных документов, доработки «как в старой системе».
Но приоритеты не были определены, а границы этапа — зафиксированы. Это неизбежно приводит к трем эффектам:
1. Постоянное расширение требований — каждая демонстрация раскрывала новые детали — и появлялись новые пожелания.
2. Несоответствие между желаемым объемом и бюджетом — оценка трудоемкости наглядно показывала, что многие пожелания требуют десятки часов доработок.
3. Потеря фокуса — проект начинал двигаться туда, где возникало больше активности, а не туда, где это было бизнес-критично.
Но приоритеты не были определены, а границы этапа — зафиксированы. Это неизбежно приводит к трем эффектам:
1. Постоянное расширение требований — каждая демонстрация раскрывала новые детали — и появлялись новые пожелания.
2. Несоответствие между желаемым объемом и бюджетом — оценка трудоемкости наглядно показывала, что многие пожелания требуют десятки часов доработок.
3. Потеря фокуса — проект начинал двигаться туда, где возникало больше активности, а не туда, где это было бизнес-критично.
Как бобдей удержал управляемость проекта
Несмотря на высокую неопределенность, проект был доведен до результата — за счет системного управления и перестройки команды там, где это было необходимо.
Усиление команды
По мере детализации требований стало ясно, что проект выходит за рамки первоначальной сложности. Мы расширили команду дополнительным экспертом по документообороту, чтобы качественно проработать архитектуру процессов и согласования. Это позволило:
- скорректировать модель процесса,
- закрыть методологические пробелы,
- уточнить требования и устранить противоречия.
Введение прозрачной политики изменений
Каждая новая доработка/пожелание оценивалась отдельно. Когда заказчик увидел, что даже «простая просьба» может стоить 40–100 часов, поток изменений значительно сократился. Это вернуло проект в контролируемое состояние.
Реализация ключевых процессов
Несмотря на ограничения, были успешно внедрены:
Настройки были переданы заказчику в полностью протестированном и документированном виде, с архитектурой, рассчитанной на устойчивую работу без «ручных подпорок» и доработок.
- контрагенты,
- договоры,
- доверенности,
- претензионная работа,
- маршруты согласования по дивизиональной структуре,
- автозаполнение документов.
Настройки были переданы заказчику в полностью протестированном и документированном виде, с архитектурой, рассчитанной на устойчивую работу без «ручных подпорок» и доработок.
Корректное завершение проекта
По инициативе заказчика опытно-промышленная эксплуатация проводилась их силами. Первые недели команда задавала вопросы, затем система работала стабильно без участия бобдей.
Что проект автоматизации дал компании: эффекты
Несмотря на сложный контекст, результат проекта имеет системную ценность для бизнеса:
1. Переход с устаревшей, неподдерживаемой системы на современный масштабируемый инструмент
Компания перестала зависеть от хаотически переписанного решения, которое было уже невозможно развивать.
Компания перестала зависеть от хаотически переписанного решения, которое было уже невозможно развивать.
2. Единая логика работы с договорами, доверенностями и претензиями
Теперь процессы собраны в одном решении, согласованы и прозрачны для руководства. Впервые появилась единая, понятная модель: кто согласует, когда, по какой логике, что является исключением. Это повысило управляемость и качество решения.
Теперь процессы собраны в одном решении, согласованы и прозрачны для руководства. Впервые появилась единая, понятная модель: кто согласует, когда, по какой логике, что является исключением. Это повысило управляемость и качество решения.
Реализована памятка по перечню документов, предоставляемых при согласовании контрагента и его направления деятельности
3. Снижение стоимости владения
Новые требования можно реализовывать типовыми средствами, а не через дорогостоящие точечные доработки старой системы.
Новые требования можно реализовывать типовыми средствами, а не через дорогостоящие точечные доработки старой системы.
4. Масштабируемость
Компания получила инструмент, который способен расти вместе с бизнесом — без риска «обрушить» систему от очередного изменения.
Компания получила инструмент, который способен расти вместе с бизнесом — без риска «обрушить» систему от очередного изменения.
5. Переосмысление процессов
В ходе проекта стало ясно, что часть внутренних процедур требует пересмотра. Это важный эффект: автоматизация высветила системные пробелы в процессах.
В ходе проекта стало ясно, что часть внутренних процедур требует пересмотра. Это важный эффект: автоматизация высветила системные пробелы в процессах.
Форма выбора полномочий для автоматического заполнения текста доверенности
Что могло бы быть иначе
Этот кейс показывает, к чему приводит отсутствие системной управленческой рамки:
1. Нет владельца процесса → нет финальных решений.
2. Нет приоритетов → распыление бюджета и ресурсов. Вместо ключевых задач команда погружается в уточнения и «хотелки».
3. Нет коммуникации с пользователями → сопротивление. Люди сравнивают новое со старым, не понимают смысла изменений.
4. Параллельные обследования → меняющиеся вводные. Любой внешний поток корректирует направление проекта.
5. Покупка системы до формирования требований → необходимость переделок. Архитектура решения формируется не от задачи, а от уже совершенного выбора.
1. Нет владельца процесса → нет финальных решений.
2. Нет приоритетов → распыление бюджета и ресурсов. Вместо ключевых задач команда погружается в уточнения и «хотелки».
3. Нет коммуникации с пользователями → сопротивление. Люди сравнивают новое со старым, не понимают смысла изменений.
4. Параллельные обследования → меняющиеся вводные. Любой внешний поток корректирует направление проекта.
5. Покупка системы до формирования требований → необходимость переделок. Архитектура решения формируется не от задачи, а от уже совершенного выбора.
Итог
Проект развивался в условиях высокой неопределенности, тем не менее:
- ключевой функционал был внедрен,
- система передана заказчику,
- компания получила современный инструмент автоматизации, проект завершен корректно.
Подобрать решение автоматизации
Если вам важно, чтобы проект автоматизации был предсказуемым и управляемым, мы готовы подключиться на любом этапе.
Разберём текущую ситуацию, поможем выстроить рамку проекта и предложим реалистичную дорожную карту.
Разберём текущую ситуацию, поможем выстроить рамку проекта и предложим реалистичную дорожную карту.
