Внедрение ERP на крупных предприятиях и в холдингах. Методология
09.03.2024
Внедрение ERP на крупных предприятиях и в холдингах. Методология
Для крупных компаний и холдингов.
Данная методологи настроена под переходы с SAP, Oracle на 1С. Также методика подходит под переход с устаревших систем 1С на более современные (например, с 1С УПП на 1С ERP).
*Не подходит для госс.сектора и небольших предприятий.
Большинство проектов внедрения проваливаются из-за того, что заказчик не понимает/не готов уделять достаточное количество времени и оперативно работать в проекте. Но к сожалению, невозможно, чтоб пришла команда, всё настроила и ушла. Информацию должен дать клиент, вносить корректировки, тестировать результаты, принимать ключевые решения по ходу проекта и выполненные участки должен клиент. Наша методика дает возможность довести до результата, а клиенту - участвовать и быть в курсе каждого этапа, влиять на процесс, а значит на выходе получить именно то, что хотел.
Для любого проекта важно уложиться в сроки, бюджет и цели.
Цель любого заказчика –
1) перейти на новую систему, уложившись в сроки и бюджет,
2) сохранить ключевые, критические бизнес-процессов и не потерять эффективность,
3) в новой системе сделать минимальное количество доработок, тк это всегда дополнительные затраты на разработку и будущую поддержку.
Внедрение новой системы – это в первую очередь консалтинг. Если раньше проект внедряли разработчики, то сейчас большую часть выполняют аналитики. Чем более качественно проведена аналитика, тем меньше доработок.
Основные задачи проекта:
1 этап Проектный.
- Проанализировать текущие бизнес-процессы компании и перенести их в документацию, чтобы было единое видение всех процессов как у Исполнителя, так и у Заказчика.
- Смоделировать эти процессы в новой системе. Это когда берем живые документы и процессы пытаемся повторить в новой системе. Проводим демонстрацию клиенту и по результатам фиксируем «узкие места» (функциональные разрывы), которые не позволят корректно работать системе.
Когда необходима миграция из старой системы в новую, необходимо согласовать состав мигрируемых данных, разработать инструменты миграции.
2 этап Разработка.
После выявления критических разрывов, разрабатываем пути решения и согласовываем их с клиентом, еженедельно показывая результат проделанной работы, чтобы заказчик понимал, что он получит на выходе и мог тоже управлять результатами разработки.
3 Этап Опытная эксплуатация.
Частая проблема – разработки выполнены, данные загружены, а из-за ошибок в работе она не работает. Поэтому необходимо провести глобальное тестирование.
Проводим 3 вида тестирования:
Внутреннее – полный прогон системы внутри себя под руководством технического и функционального архитектора.
Внешнее тестирование – такой же прогон, но уже с клиентом. В этот момент заказчик может внести корректировки.
Приемочное тестирование, для которого разрабатываем кейсы по шагам, а клиент сам проходит весь путь и проверяет как система работает.
По результатам исправляем возможные ошибки, готовим инструкции, обучаем сотрудников.
4 этап Промышленная эксплуатация.
Обязательно сопровождаем проект 3-6 месяцев после запуска, пока сотрудники привыкают.
Всю информацию по проекту: планы, графики, цели, результаты – лучше предоставлять клиенту в виде презентации. Это первые представления клиента о результате. Обычно заказчик не представляет, что от него тоже потребуется выполнение определенной работы. В презентации это видно наглядно.
Внедрение невозможно ограничить командой исполнителя. Давая представление об объеме совместной работы, мы как бы прописываем правила, от которых зависит успешность проекта. Ниже таблица вовлеченности сотрудников предприятия.
Куратор проекта занимается утверждением финальных решений, выделением бюджета и приемкой всего проекта целиком.
Руководитель – это администратор всего проекта. Например, у провайдера нет полномочий в компании клиента, поэтому требуется руководитель проекта внутри компании, который сможет требовать от подчиненных необходимой дисциплины.
Ключевые пользователи – это владельцы основных блоков, по которым внедряем системы. Обычно это руководители отделов. Например, если мы внедряем финансовый блок, это финансовый директор и т.д.
Эксперт со стороны системы, с которой мигрируем. Это технический специалист, который готовит данные в существующей системе для переноса их в новую.
ИТ- специалисты, которые работают с внешними системами, дают необходимые доступы и обеспечивают внутренние инструменты, проводят необходимые работы с серверами.
В процессе внедрения мы всегда должны укладываться в сроки и бюджет. Однако обычно люди хотят взять старую, годами доработанную систему и полностью перенести в новую, по пути добавив новые потребности, т.е. взять 1С и сделать из него SAP. Но давайте быть реалистами: невозможно за полгода-год сделать то, чего достигали многими годами и огромными бюджетами. В таких случаях доработка превышает бюджет в 3-4 раза.
Как же определить, что сделать, чтоб уложиться в бюджет?
Этот конфликт мы решаем следующим образом.
Предлагаем разделить все бизнес-процессы по уровню критичности.
- Высокий, без которого предприятие «сломается», не сможет осуществлять деятельность.
- Средний, который замедляет работу.
- Низкий, хотелки, помогалки, улучшалки.
Обычно в бюджет попадает высокий и часть среднего приоритета. А низкая критичность уходит на развитие системы в дальнейшем.
Наш опыт показывает, что внедриться в срок и заложенный бюджет, возможно выполнив высокий и средний приоритет. А запустить чаще всего удается только высокую критичность. И лишь после точки запуска дорабатывать год, два, да хоть 10лет.
Если делать всё сразу, проект забуксует. Результата по срокам и бюджету мы не достигнем.
Поэтому в первую очередь
- внедряем высокий приоритет,
- в период промышленной эксплуатации добиваем средние приоритеты,
- далее можно дорабатывать по желанию годами.
Такой поэтапный подход дает наибольшую вероятность в достижении желаемого результата.
Наш десятилетний опыт в ИТ помог выработать методику, которая дает ответ на основные задачи проекта: как внедрить автоматизацию в запланированные сроки и бюджет и, прибегнув к минимальным доработкам, сохранив критические бизнес-процессы и эффективность.