Комментарии по теме

«Цикл первый. «Це­ле­со­о­бра­зно­е» внедрение ERP системы. Статья первая. «Новый подход»»
Александр Дублин:
1. Увы, Вы поняли нас неправильно. ТОС - это не "развитие тем", а теория (методология), которая даёт инструменты для анализа ситуаций (проблем бизнеса), в том числе таких: -  Почему...
«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Цикл первый. «Це­ле­со­о­бра­зно­е» внедрение ERP системы. Ко­нце­пци­я. Эко­но­ми­че­ская выгода как цель внедрения»
Михаил Исаченко:
Спасибо авторам за материал.   Никоим образом не претендую на абсолютную правоту и "истину в последней инстанции", но все же предположу, что все неудобства кураторов, связанные с ответами на...

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2014-2015) Дата проведения: 9 октября 2014 г. Все мероприятия

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

Предыдущая Следующая

Для скачивания материала, необходимо войти на сайт или зарегистрироваться.

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

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

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

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

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

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

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

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

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

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

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

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

Мы участвовали в очень разных проектах, получали от заказчиков как качественные документы, так и некачественные. Дело в том, что работа менеджера по управлению оргизменениями на чем‑то обязательно базируется — например, на качественном, четко структурированном проектном решении. Что это значит? Была схема бизнес-процессов с ролями, транзакциями и ответственными подразделениями. План коммуникаций меняется, адаптируется в зависимости от ситуации. Аналогично, реестр организационных изменений — живой документ, он также адаптируется к изменениям. Этот документ является важной основой для обучения, потому что в последующем вы не только обучаетесь транзакциям, но и рассказываете людям, что изменилось. Если сотрудники не поймут, что у них поменялось в работе, а просто научатся, это будет малоэффективно.

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

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

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

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

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

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

По поводу управленческого комитета. В проектах, где внедрялось много модулей, были выявлены изменения в штате и подсчитано, сколько их производилось по каждому направлению организационных изменений. Для чего это было сделано? Чтобы эту информацию потом представить управляющему комитету для принятия определенных решений. Например, такие задачи, как новые операционные процессы, приобретение нового ПО, процесс сохранности на складах. На управляющий комитет было выведено следующее решение: пятьдесят новых сотрудников на склад нужно для того, чтобы была поддержка новых видов деятельности по этому новому процессу, а также нанят один дополнительный человек в процесс «Финансы и учетный процесс кредиторской задолженности». Эти решения тоже выносились на управляющий комитет, потому что в компании было очень жестко с штатным расписанием — добавление еще одной единицы требовало согласования очень высоко. В ходе обсуждения было выявлен фактор, тормозивший проект: организационно-распределительные документы не были актуализированы.

Очень важно постоянно работать с персоналом, разъяснять и уточнять информацию. Многие не понимают, зачем актуализировать информацию до начала проекта, если после проекта придется снова это делать, а ресурсов нет, у них основная операционная деятельность. У HR-отдела своя текучка, они такие же, как остальные подразделения, поэтому считать, что управление организационными изменениями может взять на себя HR-отдел — это определенная иллюзия.

Я ни в одном этого проекте не видела. Если внедрение не касается непосредственно HR, поручить эту задачу данному подразделению почти никогда не удается.

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

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

Средняя — воздействие на бизнес-процесс, влияние на 50 % сотрудников. Решение может быть принято на уровне руководителя департамента.

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