Разберитесь в матчасти: идентифицируйте изменения в организации и бизнес-процессах

Докладчик: Татьяна Козуб

После того, как вы определили стратегию, сделали оценку затрат и выбрали решение, начинается идентификация основных бизнес-процессов. Это по‑разному визуализировано в разных методологиях, но принцип един: когда процессы идентифицированы и согласованы, начинается работа менеджера по управлению организационными изменениями. С помощью системы очень удобно переложить список бизнес-процессов в реестр организационных изменений. Для нас важно, что здесь есть код процесса, помимо названия. У каждого процесса есть код, субпроцессы или подпроцессы. Есть транзакция. Говорим ли мы про SAP или про другую информационную систему — неважно, кто этот шаг процесса выполняет и где этот процесс находится. Важно, что они зафиксированы.

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

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

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

Когда процессы уже сформированы, необходимо создать реестр организационных изменений и сопоставить роли и конечных пользователей. Это тоже важная и нетривиальная вещь, особенно, когда у вас много конечных пользователей. Часто именно эти работы тормозят проект, потому что бизнес не готов быстро номинировать людей на определенные роли. Если же не определено, кто делает шаг в бизнес-процессе, управлять им становится очень сложно. Приходится встретиться с каждым линейным менеджером (представьте, сколько времени это может занять, если у вас их полторы-две тысячи!), каждому объяснить, что вам нужно, что его роль включает в себя. На практике это почти невозможно, поэтому основой все равно являются бизнес-процессы.

Далее идет выявление необходимых изменений в организационно-распределительной документации. Это изменения положений, должностных инструкций, памяток, технологических схем, которые должны быть зафиксированы. Здесь, опять же, все зависит от культуры компании. У кого‑то должностные инструкции являются типовыми, без учета, что люди выполняют разные функции. А для кого‑то это очень важно для запуска системы в продуктивную эксплуатацию.

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

Распределяя роли, мы указываем департамент, отдел, группу, цех, должность, ФИО. И не просто помечаем, что человеку присвоена новая роль, но указываем новые функциональные обязанности, их расширение либо сохранение. На данном уровне этого достаточно для того, чтобы понять, нужно ли далее нормировать. После этого берем секундомер, хронометраж, и нормируем — действительно ли 72 часа надо на данный процесс либо 15 минут хватит, существенная ли это нагрузка или нет. Здесь помогает матрица ролей и полномочий, в сочетании с уровнями доступа к информации. Крестики — это пересечение. Все это делает линейный руководитель. И, чтобы избежать дублирования, лучше эту работу совместить с определением функциональных обязанностей. Лучше это сделать в одном документе, просто документ идет в два отдела, в два направления. HR отвечает за должностные расширения, за хронометраж. Соответственно, эта работа ложится на сотрудников группы организационных изменений. Это уже бизнес-консалтинг, выявление необходимых изменений в организационно-распределительной документации, актуализация реестра. При этом консультанты — как внешние, так и внутренние консультанты, и те, кто отвечает за оргизменения, не могут, например, внести изменения в учетную политику акционерного общества. Соответственно, мы планируем эти работы и понимаем, что кто‑то должен внести изменения, указать фамилии, согласования, сроки, создать детальный план.

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

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