Почему после успешного внедрения становится тяжелее, хотя ожидали, что станет легче

Мы ожидали, что работать станет легче

Мы меняли морально устаревшую корпоративную систему на новую ERP. Функциональность прежней системы устраивала пользователей, поэтому исходная задача выглядела понятно: перенести привычные возможности и получить основу для дальнейшего развития. Старую систему масштабировать становилось трудно, в том числе из‑за недостатка данных для новых участков автоматизации.

В ходе проекта мы обнаружили много функциональных разрывов. Прежняя система была доработана под компанию, и воспроизведение всех доработок в новой ERP потребовало бы много работы. Часть старых решений мы сохранили, а в некоторых случаях отстояли использование возможностей новой системы. Приходилось разбираться, как обеспечить нужную работу средствами нового решения.

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

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

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

Почему понадобилось больше данных

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

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

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

За новые возможности компании люди платили дополнительной работой.

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

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

Что компания получила благодаря этим данным

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

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

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

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

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

Почему проект всё‑таки приняли

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

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

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

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

Обсуждать их следует с теми, кто выполняет работу. Руководству доступны преимущества прозрачности и развития системы. Сотрудники, вводящие документы, видят повторяющиеся действия, проверки, требующие внимания ^[1], и места, где теряется время. Для выбора улучшения нужны обе стороны этой картины.

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

Как сократить нагрузку сегодня

Такой работы в описанном проекте мы не проводили. Дальше я говорю о том, как подошёл бы к этой ситуации сегодня.

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

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

Распознавание имеет смысл проверить там, где сведения переносят из изображения документа. Сегодня я включил бы в такую проверку и большие языковые модели, LLM: они могут извлекать сведения из текста и готовить структурированный набор данных ^[2]. Для выбранных документов я проверил бы, смогут ли модели готовить черновик заполнения, который сотрудник проверяет и дополняет при необходимости.

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

Любой вариант нужно сравнить с ручным вводом на сопоставимом наборе реальных документов. В полное время обработки входят проверка, исправления и повторные действия; в затраты — стоимость обработки и сопровождения. Также важно выяснить, не появилась ли дополнительная работа у бухгалтерии или сотрудников, сопровождающих обмен. Если человек тратит прежнее время на сверку предложений системы, экономию ещё предстоит подтвердить.

Отдельно стоит разобрать проверки, добавившиеся при переходе. Какие требуют профессионального суждения, какие выполняются по однозначному правилу, какие повторяют ^[3] уже проведённый контроль? Для каждой нужно определить исполнителя и место в процессе. Сокращение ручной работы должно сохранять обязательные проверки качества данных и правила учёта.

Выбирать способ изменения нужно вместе с пользователями, владельцем процесса и ИТ. Сотрудники показывают реальную работу, владелец процесса определяет допустимые правила и результат, ИТ оценивает реализацию и сопровождение. Для проверки выбранного варианта потребуются ресурсы, согласованные критерии и дата разбора результатов. Их я включил бы в план достижения и проверки выгод.

Как проверить результат после запуска

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

Такого плана в описанном проекте мы не составляли. Ниже — пример того, как я предложил бы организовать проверку сегодня.

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

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

Для сравнения нужны сопоставимые операции. Если до изменения наблюдали сложные документы, а после — только простые, вывод будет зависеть от состава выборки. Нужно учитывать объём работы, опыт ^[4] сотрудников и временную помощь команды внедрения. Эти обстоятельства стоит записывать вместе с результатом.

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

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

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

Когда этой работы достаточно

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

Заканчиваться она должна одним из следующих решений:

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

• Назначить конкретное улучшение. Определены действие, исполнитель, ресурсы и следующая дата проверки.

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

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

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

У решения принять нагрузку тоже есть границы. Существенное изменение объёма документов, стоимости обработки или требований к качеству может стать поводом для пересмотра. Обычная эксплуатация при этом не должна постоянно возвращаться к спору о приёмке.

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

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

Серия начиналась с права ИТ приостановить преждевременную реализацию. После запуска сохраняется обязанность сделать управленческий выбор явным: показать фактический результат, расхождение с ожиданиями и варианты дальнейших действий. Бизнесу предстоит решить, какое изменение оправдывает затраты. ИТ и сотрудники, выполняющие работу, помогают подготовить основания этого решения. Так у компании появляется возможность улучшить работу или сознательно сохранить её, а у пользователей — понятный ответ на вопрос, что произошло с их ожиданием, что новая система поможет работать легче.

И в этот раз без опроса…

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