Для чего нужны такие системы?
Внедрение ERP подразумевает из своего названия, что планирование будет основой системы, однако, на деле, ERP больше играет роль собирателя информации и выстраивания процессов, нежели планирования. По крайней мере, отечественные решения не предоставляют широкого спектра вариантов планирования и методологию из коробки.
Зарубежные, а в современной ситуации трофейные системы, содержат такого рода модули и компоненты, которые требуют локализации и адаптации.
В такой ситуации, встаёт вопрос о внедрении IBP (Integrated Business Planning) решения, которое позволит строить модели и планы учитывая разные разрезы цепочек в компании.
Какого рода вопросы оно может затрагивать:
Как организовать продажи с обеспечением должного уровня сервиса с избеганием излишков, просрочек, потерь?
Как спланировать закупки и поставки с учётом сложных и длительных циклов производства?
Как наиболее эффективно построить поддержку продаж без потери маржинальности?
Какое будет распределение инвестиционной нагрузки в будущих периодах и каков цикл окупаемости?
Как спланировать производственные и логистические мощности в условиях сезонного спроса?
И подобные вопросы.
А следовательно - это следующие виды планирования:
проектирование сети цепочек поставок
прогнозирование спроса
оптимизация запасов
планирование операций и продаж
объемно-календарное планирование производства, поставок и дистрибуции
оперативное планирование производства, отгрузок, поставок
управление заказами.
Да, конечно, в ERP решениях есть план продаж, производства, загрузки склада, бюджет, но зачастую они живут сами по себе и не имеют единой, связанной картины, не говоря уже о гибкости самой модели планирования и применяемых алгоритмов.
Впрочем, внедрение блока планирования внутри ERP, значительно не отличается от процесса внедрения внешнего решения.
Какие особенности внедрения существуют?
В чём же нюансы такого внедрения и почему его лучше выделять в отдельный проект или рассматривать как отдельный блок внутри проекта внедрения ERP?
Основа такого рода решений - это однозначность и достоверность данных предоставляемых выделенным экспертам с возможностью их анализа и выстраивания единого процесса обработки и преобразования.
Как видно, процесс не только ИТ, но скорее затрагивает все процессы планирования и управления в компании или группе.
Первое, что лежит на поверхности - это большая вовлечённость всех отделов компании или группы, даже, если функция планирования вынесена в отдельные подразделения.
Да, конечно, проект вовлекает экспертов и работает с ними, но планирование не может существовать без данных, которые вводят операторы на местах. Именно поэтому, проект затрагивает множество сотрудников и зависит от их вовлечённости и добросовестности.
Второе - это достоверность данных, особенно исторических, на которых базируется множество моделей прогнозирования.
И здась мы говорим о данных из систем - источников, которые снабжают модели. Тут очень важно не на уровне ИТ подразделений и специалистов, а на уровне экспертов получить подтверждение, что загружаемые в модель данные верны.
Третье - это правила преобразования данных. Процесс ETL (Extract, Transform, Load) или интеграция с преобразованием данных, если применять другие определения.
Этот процесс всецело зависит от ИТ и корректности тех алгоритмов, которые заложены в преобразования. Даже при достоверных данных, если их преобразование носит ошибочный характер, прогнозная модель даст не корректный результат.
Четвёртое - это правильность моделей, выбор и наполнение которых лежит в плоскости работы аналитиков с экспертами по планированию.
Самая простая проверка - это проверка на исторических данных, т.е., например, берём продажи в начале прошлого года и пытаемся построить цепочку поставок на конец прошлого года. Результат сравниваем с тем, что было в реальности.
Пятое, как не удивительно, но это удобство пользовательского интерфейса и его доступность на разных устройствах.
Хотя, конечно, это зависит от того, кто является целевыми пользователями системы, если это только эксперты по планированию, то это малый круг, а если включает в себя руководителей и других сотрудников, то данный вопрос не может оставаться на заднем плане.
Не выделяя в отдельный блок, но важно соблюсти мониторинг действий и промежуточных результатов на каждом из этапов, начиная с получения и проверки данных на достоверность, заканчивая получением результатов прогнозной модели.
Другой темой, которая должна пройти красной нитью сквозь проект - это производительность и скорость обработки данных в системе. Если на просчёт одного варианта модели будет тратиться более 8 часов, то такие скорости значительно повлияют на принятие решений, основанных на такой модели.
Какие этапы внедрения можно выделить в проекте?
Перед стартом, как в любом проекте, необходимо определить цели внедрения системы и его объём (какие планы затрагивает).
Само внедрение можно вести и по Agile, и по каскадной, и по гибридным моделям, здесь большой разницы нет. Если брать Agile, то шаги ниже можно разбить на кейсы не дискретные участки по видам планов.
Лучше всего начать с разработки методологии планирования, если её уже не существует. Она должна определить, какого рода планирование будет затронуто, какие отчёты и результаты необходимо получить.
После этого, определить наборы данных, которые используются в моделях. Здесь важно определить механизмы подтверждения достоверности данных и их проверки. Кто и что вводит, кто отвечает и подтверждает данные. Определить регламенты работы с данными.
Следующим этапом будет описание сбора и преобразования данных для нужд моделей прогнозирования. На этом этапе важно не забывать про мониторинг и производительность.
После сбора и преобразования данных можно приступать к описанию самих моделей, итераций, поиска наилучшего результата и прочие алгоритмы.
Завершить описательную часть можно более подробным раскрытием содержаний отчётов, нежели в методологии и затронуть сценарии пользовательского взаимодействия с системой.
Шаги разработки и тестирования решения похожи на шаги описательной части. Всё начинается со сбора данных в системах - источниках и их преобразовании. После этого наполнение данными моделей и пробные запуски с проверкой на простых отчётах.
В дальнейшем, усовершенствование отчётов до целевых с проверкой результатов, совместно с экспертами и отработка их взаимодействия с системами.
Можно использовать автоматизированное тестирование, особенно для проверки корректности сбора и преобразования данных для разных тестовых сценариев.
На этапе тестирования важно проверить функционал версионности планирования и наборов данных. Это необходимо для сравнения результатов разных запусков моделей и наборов между собой.
С чего начать внедрение IBP?
Пойдём от обратного.
Не начинайте проект, если достоверность данных слабая, а ответственность за их корректность размытая.
Не начинайте проект, если планирование не внедрено даже на уровня Excel или доработок ERP, лучше начать с простого. Внедрение IBP решений само по себе требует инвестиций, а если нет чётких требований на входе, то инвестиции значительно вырастут.
Не начинайте проект, если нет точных целей и понимание, где необходимо улучшить качество планирования.
Не начинайте проект, если нет поддержки внедрения у ключевых экспертов и руководства.
Подписывайтесь на канал: