Особенности внедрения систем планирования

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

Зарубежные, а в современной ситуации трофейные системы, содержат такого рода модули и компоненты, которые требуют локализации и адаптации.

В такой ситуации, встаёт вопрос о внедрении IBP (Integrated Business Planning) решения, которое позволит строить модели и планы учитывая разные разрезы цепочек в компании.

Какого рода вопросы оно может затрагивать:

И подобные вопросы.

А следовательно - это следующие виды планирования:

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

Впрочем, внедрение блока планирования внутри ERP, значительно не отличается от процесса внедрения внешнего решения.

В чём же нюансы такого внедрения и почему его лучше выделять в отдельный проект или рассматривать как отдельный блок внутри проекта внедрения ERP?

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

Как видно, процесс не только ИТ, но скорее затрагивает все процессы планирования и управления в компании или группе.

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

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

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

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

Третье - это правила преобразования данных. Процесс ETL (Extract, Transform, Load) или интеграция с преобразованием данных, если применять другие определения.

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

Четвёртое - это правильность моделей, выбор и наполнение которых лежит в плоскости работы аналитиков с экспертами по планированию.

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

Пятое, как не удивительно, но это удобство пользовательского интерфейса и его доступность на разных устройствах.

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

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

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

Перед стартом, как в любом проекте, необходимо определить цели внедрения системы и его объём (какие планы затрагивает).

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

Лучше всего начать с разработки методологии планирования, если её уже не существует. Она должна определить, какого рода планирование будет затронуто, какие отчёты и результаты необходимо получить.

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

Следующим этапом будет описание сбора и преобразования данных для нужд моделей прогнозирования. На этом этапе важно не забывать про мониторинг и производительность.

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

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

Шаги разработки и тестирования решения похожи на шаги описательной части. Всё начинается со сбора данных в системах - источниках и их преобразовании. После этого наполнение данными моделей и пробные запуски с проверкой на простых отчётах.

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

Можно использовать автоматизированное тестирование, особенно для проверки корректности сбора и преобразования данных для разных тестовых сценариев.

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

Пойдём от обратного.

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

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

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

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

Подписывайтесь на канал: