«Когда приезжаешь на новое место, у тебя появляется шанс начать всё сначала.»

Фрэнк Липтон, сериал “Пять”

«Жуткая вещь — переезд. Не знаешь, где найдешь, где потеряешь.»

Скотт Вестерфельд, книга “Тайный час”

Всем привет, меня зовут Сергей и я технический директор в “ОСМ Групп”.

В прошлый раз мы говорили про Process Mining и как с его помощью оптимизировать процессы в организации и при этом не наступить на некоторые грабли (Для тех, кто не читал - рекомендую ознакомиться с предыдущей статьей). Но что делать, если нам эти процессы надо перенести в новую систему? Как взять только нужное, а все лишнее оставить и забыть, как страшный сон? В сегодняшней статье мы разберем методологию перехода с SAP на любую другую систему, будь то новая версия SAP S4/HANA, 1С и т. д.

Нельзя просто так взять и переехать

Мало кто задумывается, сколько действительно ненужного / лишнего / неиспользуемого находится рядом с нами. Это могут быть какие-то разработки, которыми уже никто не пользуется, это могут быть не оптимально построенные бизнес-процессы, или даже скажу так - для текущей системы они кажутся оптимальными, т. к. по-другому шаги для этих процессов не выполнить, но, они требуют 5–6 действий, а в новой системе то же самое можно сделать всего за пару действий. Да, и не стоит забывать о пользователях - кадры в компании находятся в постоянном движении, кто-то уходит, кто-то приходит, кто-то меняет свою позицию. И при всем при этом роли и полномочия у таких пользователей могут разрастаться. Иными словами, остаются старые полномочия и добавляются новые. И это только некоторые примеры “беспорядка”, о котором необходимо позаботиться в исторической системе перед миграцией на новую систему.

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

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

Именно по этой причине, в процессах миграции часто все переезжает как есть, а потом никто не понимает, почему не получили возврата инвестиций от новой современной «модной и молодежной» системы.

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

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

 А еще он поможет:

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

Так что же такого особенного кроется за кулисами нашего подхода?

Как это делаем мы

Все начинается с проектирования новой системы и часто этим занимаются так называемые ключевые эксперты - пользователи, которые досконально знают процесс. Но так как они уже привычны к работе в старой системе (назовем это проф. деформацией), то они не всегда могут сказать, что улучшить в новой системе, и часто просят сделать “тоже самое”. Но далеко не всегда “тоже самое” это то, что нам надо.

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

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

В общем, если двигаться по порядку, то

• Мы анализируем бизнес-процессы as-is, то есть не то, как они изображены на бумаге или в ARIS, а то, как они работают на самом деле. Для этого мы используем доработанную нами методологию Process Mining. Собственно, на этом этапе мы определяем узкие места, аномалии процесса, потери и точки оптимизации и автоматизации. Далее формируем рекомендации и план трансформации процессов.
• Мы смотрим на разработки, точнее даже на их качество, - не просто сколько их используются в компании, а зачем они используются (например, зачем нам эта разработка, если она запускается всего парой сотрудников пару раз в год). Не стоит забывать, что разработки еще необходимо поддерживать, ведь, как мы все знаем, они периодически могут что-то сломать в системе.
  Продолжая разговор, стоит сказать, что про них часто забывают и стараются перенести все, что лежит в реестре разработок для старой системы, не задумываясь, а надо ли оно вообще. Конечно, каждая компания уникальная, но мы встречали в своей практике и удивительные случаи, например, около 80% разработок становятся неактуальными для компании, а некоторые из них в принципе делаются, а потом не используются, или используются крайне редко каким-то одним специалистом. А ведь все это надо поддерживать, а это не очень положительно сказывается на бюджете команды поддержки.
• Мы детально анализируем цифровой след каждого пользователя в старой системе. Опять же, это помогает нам понять, как в действительности выполняются процессы в системе, а также найти, например, малоактивных пользователей, которых не обязательно тянуть за собой в новую систему (чем меньше народа, тем больше кислорода - то есть тут мы уже можем сэкономить на лицензионном объеме). А еще часто встречается такое, что в распределении ролей и полномочий такой бардак, что разобраться в нем руками практически невозможно. Так что тут мы активно применяем машинное обучение, с помощью которого определяем отклонения в орг. структуре, находим нарушения в балансе между должностным уровнем пользователя и функционалом, который он выполняет в системе и многое другое. В дальнейшем это позволяет выровнять эту самую орг. структуру, актуализировать и оптимизировать матрицу ролей и полномочий, должностные инструкции, а также их привязку к должностям и к людям.
• Ну и не стоит забывать про обучение, последующую адаптацию и поддержку пользователей. Результаты предыдущего этапа помогают нам выявить потребность в обучении тех или иных пользователей (мы же не хотим обучать людей, которых не будет в новой системе). Так же наши алгоритмы помогают составить рекомендации - кого и чему нужно обучать в первую очередь, а также сформировать базу знаний и каталог курсов. А имея как минимум эти данные работа службы поддержки становится намного качественней.

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

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

В заключение

В 90% случаев компании не знают, как верно подступиться к процессам перехода на новую систему. Иногда это нехватка опыта, иногда слишком сложные процессы в самой организации, но чаще всего это отсутствие необходимых инструментов. Все эти факторы влекут за собой множество проблем, начиная от выхода за рамки бюджета и заканчивая беспорядком в новой системе. Я же надеюсь, наша методология и уникальные инструменты позволят избежать большинства негативных последствий и изменить мир в лучшую сторону. А подробнее об этом можно будет узнать на предстоящем вебинаре 18 апреля.

Сергей Воронов

Об авторе: более 5-ти лет является архитектором сквозных бизнес-процессов. Обладает глубоким знанием процессов P2P и смежных с ними.  Реализовал более чем 5 проектов по глубокой аналитике пользователей, бизнес-процессов и ролевых моделей. Является владельцем продукта и архитектором ОСМ Аналитика.