Как не оцифровать хаос: почему цифровизация начинается с процесса

Введение и проблематика

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

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

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

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

Ключевые проблемы

Неправильно сформулированная задача

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

В результате пытаются изменить всё сразу: процессы, регламенты, отчётность и инструменты. Это увеличивает стоимость проекта и создает сопротивление сотрудников.

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

Иначе можно автоматизировать процесс, который существует только на бумаге.

Сопротивление сотрудников

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

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

Отсутствие измеримого результата

«Внедрить систему» – не цель проекта. Количество выданных доступов и авторизаций показывает использование продукта, но не отвечает на главный вопрос: стал ли процесс лучше?

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

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

Разрыв между бизнесом и ИТ

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

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

Кроме того, проекту нужен руководитель-спонсор, который может принимать решения, снимать межфункциональные блокеры и обеспечивать ресурсы.

Дублирование старых и новых каналов

На этапе перехода сотрудники неизбежно какое-то время работают по старым и новым правилам. Однако если компания не определяет срок перехода и источник достоверных данных, временное дублирование становится постоянным.

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

Решение

Начинать с целевого процесса

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

Готовое решение редко совпадает с процессом компании на сто процентов. Поэтому придётся либо адаптировать процесс под возможности продукта, либо настраивать и дорабатывать продукт. Главное – не переносить в новую систему неэффективность старого процесса.

Проверять решение на пилоте

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

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

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

Подготовить сотрудников

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

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

Закрепить новые правила

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

Обеспечить поддержку после запуска

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

Выводы и результаты

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

Поэтому до начала проекта стоит ответить на несколько вопросов:

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

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

Программное обеспечение – это инструмент. Результат создаёт не система сама по себе, а организация, которая понимает, какой процесс она меняет, зачем это делает, и кто отвечает за результат. Всё остальное – просто ещё одна иконка на рабочем столе.