Внедрение IBP-системы становится необходимостью для российских компаний, которые стремятся повысить уровень операционной эффективности и выстроить системную работу с данными. Однако факт интеграции программного обеспечения в контур предприятия — вовсе не волшебная таблетка. Чтобы система, действительно, работала и приносила бизнес-результаты, заказчику необходимо провести серьезную предпроектную подготовку, которая в некоторых случаях занимает до нескольких лет.
1. Выбор решения: реальный IBP, а не «красивая демонстрация»
На российском рынке представлены несколько десятков решений по интегрированному бизнес-планированию. Однако опрошенные CNews Analytics разработчики IBP-систем указывают, что нередко при позиционировании того или иного продукта может происходить подмена понятий.
«Российский рынок IBP растет, но функциональное содержание IBP в предлагаемых решениях неоднородно. Понятие «продукт» искажено: разработчики часто предлагают либо красивую демонстрацию с примечанием «остальное мы допишем», либо low-code-конструктор, либо форк непрофильной системы с «навешенным» функционалом IBP», — отмечает Игорь Фесенко, партнер консалтинговой практики, операционный директор «ОптиТим Консалтинг».
Чтобы выбрать по-настоящему зрелую IBP-систему, заказчикам необходимо обращать внимание на несколько важных факторов. Ключевой — наличие релевантных кейсов у крупных заказчиков. Подобные проекты внедрения, как отмечают разработчики, обычно длятся больше года, а система эксплуатируется несколько лет, поэтому важно выбрать надежного технологического партнера для длительного сотрудничества.
Если говорить о более конкретных критериях выбора платформы, то Дарья Лавриненко, руководитель группы развития системы «Производственное планирование» компании «Северсталь-инфоком» отмечает, что организации следует не оценивать набор тех или иных функций, а, в первую очередь, смотреть на архитектурную зрелость и способности системы решать поставленные бизнес-задачи.
Топ-10 российских поставщиков
IBP-систем
Агентство CNews Analytics сравнило выручку крупнейших игроков отечественного рынка решений для интегрированного бизнес-планирования
При выборе IBP-системы приоритет должен быть отдан следующим аспектам:
- Гибкость данных. Возможность самостоятельно создавать новые атрибуты, измерения и иерархии без привлечения разработчиков.
- Алгоритмика. Наличие встроенных методов прогнозирования, оптимизации и сценарного анализа.
- Сценарность. Создание сценария (What-if анализ) для сравнения различных вариантов планирования без влияния на основные данные.
- Интеграции. Присутствие открытых API и готовых коннекторов к таким системам, как ERP, WMS, TMS для обеспечения сквозного потока данных.
Четкие требования необходимо предъявлять не только к самому продукту, но и к процессам его создания и поддержки:
- Продуктовый подход. Разработчик должен продемонстрировать наличие дорожной карты развития продукта, основанной на запросах рынка, а не только на требованиях одного крупного заказчика.
- Методологическая поддержка. Наличие в команде не только программистов, но и бизнес-консультантов/методологов по цепочкам поставок.
- Прозрачность обновлений. Регулярный цикл релизов и четкий процесс управления изменениями.
- Гарантии поддержки: SLA по исправлению критических ошибок и наличие документации.
2. Обеспечение ИБ
IBP закрывает критически важные функции, которые напрямую обеспечивают и поддерживают ключевую деятельность бизнеса. Уязвимости, связанные с обеспечением информационной безопасности, могут привести как к недоступности ПО, так и к потере чувствительных данных.
Поэтому все вопросы, касающиеся информационной безопасности, нужно решить еще на этапе выбора платформы. Набор инструментов определяется с учетом особенностей проекта и специфики заказчика. Обычно это довольно стандартный и исчерпывающий набор: изолирование инфраструктуры в формате он-прем, устранение уязвимостей в ПО, доступ к ПО только из внутренней сети, антивирус и шифрование данных, ограничение возможности ручного переноса сведений с промышленного контура на незащищенную инфраструктуру.
Генеральный директор компании Knowledge Space Павел Шингарев настаивает, что стратегия обеспечения информационной безопасности должна строиться на трех уровнях.
- Внутри платформы. Разграничение доступа к данным и операциям, разделение полномочий, контроль изменений моделей, аудит действий, защита учетных данных и интеграционных интерфейсов.
- В инфраструктуре. Сегментация сети, корпоративная аутентификация, защита серверов, централизованный мониторинг, резервное копирование и проверяемое восстановление.
- В организации работы. Управление доступом сотрудников и подрядчиков, выпуск обновлений, устранение уязвимостей, реагирование на инциденты и ответственность за каждый процесс.
«При выборе набора инструментов важно не гнаться за максимальной «тяжестью» защиты, а исходить из реального профиля рисков и целей: где-то критична защита от утечек, где-то — целостность и доступность, а где-то — соответствие формальным требованиям регулятора. И здесь часто оптимальным оказывается вариант, при котором базовая ИБ-функциональность уже встроена в платформу: это снижает сложность интеграции, уменьшает число «стыков» между разнородными средствами защиты и упрощает эксплуатацию. Наложенные СЗИ имеют смысл, скорее, как точечное усиление — когда встроенных механизмов объективно не хватает под конкретные требования или когда нужно закрыть специфические угрозы, не покрываемые платформой», — отмечает Игорь Фесенко, партнер консалтинговой практики, операционный директор «ОптиТим Консалтинг».
3. Работа с данными
Главное «сырье» для любой системы интегрированного бизнес-планирования — данные. До пилотного проекта и, тем более, запуска платформы необходимо провести комплексную работу по подготовке данных и отработать основные сценарии их загрузки. От того, насколько качественно будет разработана методология, описаны потоки движения данных и алгоритмы их корректировки, в очень большой степени зависит успех всего проекта.
Один из ключевых этапов подготовки сведений — стандартизация информации.
- Очистка и нормализация. Удаление дубликатов, приведение справочников (товары, склады, контрагенты) к единому формату наименований.
- Валидация бизнес-ключей. Определение уникальных идентификаторов для каждой сущности и проверка отсутствия пустых значений в ключевых полях.
- Проверка целостности. Устранение «битых» ссылок и заполнение обязательных атрибутов.
«Особое внимание следует уделить контролю качества данных. Огромное преимущество — возможность проводить проверку на консистентность и полноту непосредственно внутри системы уже после интеграции. Такой подход позволяет гибко настраивать правила, оперативно исправлять ошибки, выявлять «пробелы» и автоматизировать мониторинг», — добавляет Дарья Лавриненко, руководитель группы развития системы «Производственное планирование» компании «Северсталь-инфоком».
При этом, как отмечают опрошенные эксперты, получить «идеальные» данные невозможно. Более прагматичный подход — довести их до приемлемого диапазона ошибок и сосредоточиться на том, чтобы знать, где находятся пробелы, и проектировать устойчивость.
«Чтобы добиться такой цели, необходимо провести три класса работ. Первый — определить минимальный набор измерений для выражения прогноза на 12–24 месяца и гибкость в гранулярности. Система должна гибко агрегировать и дезагрегировать. Второй — создать правила, определяющие формат обмена, частоту, описание ошибок и процедуру отката. Третий — определить, кто каким плановым входом владеет. Проблема качества данных — часто проблема ответственности. Нужно письменно зафиксировать первого ответственного за каждый плановый вход, частоту обновления и критерии аномалий», — указывает Игорь Фесенко, партнер консалтинговой практики, операционный директор «ОптиТим Консалтинг».
4. Выстроить ключевые процессы
Внедрение любой, даже самой инновационной IBP-системы, не принесет компании желаемых результатов, если внутри корпоративного контура заказчика не отлажены хотя бы базовые бизнес-процессы. Нередко разработчики отказывают таким предприятиям во внедрении платформ, понимая, что автоматизация хаоса приведет лишь к автоматизированному хаосу.
Если же компания настроена серьезно и не готова отказываться от интеграции IBP-систем, то ей необходимо пройти этап предпроектной подготовки. Пытаться внедрять решение параллельно с наведением порядка в процессах — высокий риск провала.
Этапы подготовки:
- Аудит и описание. Фиксация текущих процессов планирования и выявление «разрывов».
- Нормализация НСИ. Создание единых справочников продуктов, складов, клиентов и ресурсов.
- Регламентация. Разработка правил взаимодействия между тактическим и оперативным уровнями планирования.
- Формирование команды. Назначение бизнес-владельцев процесса, которые будут принимать решения по функционалу системы.
Все эти процессы могут занять от нескольких месяцев до пары лет в зависимости о того, насколько серьезная доработка требуется внутренним корпоративным процессам. Здесь возможны три сценария:
- Оптимистичный сценарий (3–6 месяцев). Бизнес-процессы в компании выстроены, но не описаны. Основной упор в такой ситуации необходимо делать на создание четких регламентов и НСИ.
- Реалистичный сценарий (6–12 месяцев). Требуется серьезная чистка данных, пересмотр организационной структуры и внедрение базовой дисциплины планирования.
- Сложный сценарий (1 год и более). Полное отсутствие культуры планирования, критические ошибки в данных ERP, сопротивление коллектива изменениям.
Если рассматривать последний сценарий, при котором компании необходимо приложить максимальные усилия для выстраивания процессов, то даже после серьезной внутренней реорганизации не стоит внедрять IBP сразу во весь контур. Ведущие разработчики рекомендуют начать с пилотного проекта на одном узком участке цепочки поставок. Это позволит «натренировать» компанию работать по новым правилам перед глобальным развертыванием.
5. Всегда ли нужен пилот
Как только предпроектная подготовка осталась позади, компания подходит к важному этапу — пилотному запуску системы. По мнению опрошенных лидеров отрасли, этот этап не менее сложный, чем старт эксплуатации платформы.
«Пилотирование сложных систем само по себе неочевидное упражнение. Связано это с тем, что сложность пилотирования и полноценного внедрения практически одинаковая. Поэтому мы рекомендуем в рамках пилота первоочередной задачей ставить моделирование бизнес-процессов заказчика на коробочном решении IBP, что существенно упрощает используемую модель данных и ускоряет пилот», — отмечает Дмитрий Мошогло, исполнительный директор компании «Гудфокаст».
Ключевая задача пилотного запуска — митигировать риски масштабного внедрения и подтвердить адекватность целевой методологии на ограниченном организационном масштабе. Обычно для проведения этого этапа выбирают одну компанию внутри группы или же отдельный функциональный блок.
При этом пилотный запуск нужен далеко не всегда, как правило, только в тех случаях, когда речь идет о крупных заказчиках, у которых много дивизионов, заводов, региональных подразделений. Что касается малого и среднего бизнеса, то здесь чаще всего этот этап можно пропустить.
Пилотный запуск считается успешным, если удалось добиться следующих результатов:
- Сокращение трудозатрат. Уменьшение времени на сбор данных и расчет планов.
- Повышение качества. Рост точности планирования или снижение количества конфликтов в цепочке поставок.
- Прозрачность. Возможность быстро увидеть влияние одного ограничения на всю цепочку.
- Принятие пользователями. Готовность сотрудников перейти в систему
6. Внедрение: каких ждать результатов
Как только пилот остался позади, и все вопросы были улажены, IBP-систему запускают в контуре заказчика, что в перспективе позволит перейти от интуитивного планирования к управлению на основе данных. Ключевые метрики, позволяющие оценить результаты интеграции программного обеспечения, можно разделить на три основные группы, отмечают в компании «Северсталь-инфоком».
1. Качество и точность планирования
- Снижение уровня запасов: уменьшение объема неликвидных ресурсов за счет более точного тактического планирования.
- Повышение уровня сервиса: сокращение количества дефицитов и случаев невыполнения заказов.
- Точность прогноза: сокращение разрыва между запланированными и фактическими показателями.
2. Скорость и прозрачность процессов
- Сокращение цикла планирования: уменьшение времени от сбора данных до утверждения финального плана.
- Увеличение скорости реакции на изменения: время, за которое компания может пересчитать план при изменении внешних ограничений.
- Снижение количества итераций: уменьшение числа циклов согласования плана между подразделениями внутри предприятия.
3. Ресурсная эффективность
- Снижение трудозатрат: сокращение времени сотрудников на ручной сбор и обработку данных в Excel.
- Оптимизация использования мощностей: более равномерная загрузка производственных и логистических ресурсов.
«Набор показателей зависит от цели проекта. Для прогнозирования это — точность прогноза. Для управления запасами — объем запасов, оборачиваемость, дефицит и излишки. Для цепей поставок — уровень сервиса и доступность товара. Для финансов — оборотный капитал, маржа, выручка и затраты. Показатели важно оценивать вместе. Например, снижение запасов нельзя считать хорошим результатом, если одновременно падает уровень сервиса. В конечном счете эффект IBP должен быть виден в экономике бизнеса: компания быстрее принимает решения, меньше замораживает денег в запасах, снижает дефицит и излишки и эффективнее использует оборотный капитал», — резюмирует Евгений Непейвода, управляющий партнер Novo BI.
Внедрение российской IBP-системы обеспечивает компании переход от интуитивного планирования к системному управлению процессами на основе данных. Но, чтобы добиться измеримых бизнес-результатов, заказчику необходимо выбрать не только функциональное решение, но и провести комплексную подготовку, начиная от работы с корпоративной информацией, заканчивая выстраиванием операционных процессов внутри компании, так как IBP-система — это инструмент, усиливающий уже выстроенную культуру планирования.
Поделиться
