Прежде чем приступить к этому решению, ИТ-директорам было бы полезно сравнить принятие решений технологических компаний и традиционных (обычных) корпораций.
Как технологические компании подходят к изменениям в своей системной среде? Технологические компании ценят скорость, гибкость и масштаб в деле создания ценности бизнеса. А именно, принимаются технологические решения, которые максимизируют свободу и независимость разработчиков за счет уменьшения сложности и устранения системных зависимостей. Для этого цифровые компании организуют технологии вокруг модульных продуктов и платформ, которые работают как услуга, чем обеспечивается независимость Это позволяет командам принимать оптимальные решения и управлять продуктами и платформами. Другой подход у компаний, которые работают в рамках общекорпоративных систем. Здесь сложные зависимости делают независимое принятие решений практически невозможным.
Поэтому модульное обновление ERP, а не системы в целом, и поняв, что важно для повышения ценности бизнеса, ИТ-директора могут сократить зависимости, тратить меньше, получать больше, снижать риски и делать все быстрее.
Первый урок, который следует усвоить цифровым аборигенам, заключается в том, что они сначала определяют стратегию, а уже потом проектируют архитектуру платформы. Имея четкую стратегию (например, увеличение количества новых клиентов и сокращение оттока клиентов), они следуют неумолимой логике в определении «продуктов», таких как клиентский опыт (как купить продукт, как найти магазин, как получить информацию о продукте).
Поэтому модульное обновление ERP, а не системы в целом, и поняв, что важно для повышения ценности бизнеса, ИТ-директора могут сократить зависимости, тратить меньше, получать больше, снижать риски и делать все быстрее.
От мышления, ориентированного на ERP, к современной платформенной организации
Первый урок, который следует усвоить цифровым аборигенам, заключается в том, что они сначала определяют стратегию, а уже потом проектируют архитектуру платформы. Имея четкую стратегию (например, увеличение количества новых клиентов и сокращение оттока клиентов), они следуют неумолимой логике в определении «продуктов», таких как клиентский опыт (как купить продукт, как найти магазин, как получить информацию о продукте).
После этого определяются платформы (такие как аутентификация пользователей и сравнение продуктов), необходимые для доставки продуктов клиентам. Затем для каждой из этих платформ компании создают группу, отвечающую за результаты и производительность платформы, и в конечном итоге также решают, использует ли функциональность, существующую в системе ERP, либо разрабатывают новую функциональность.
Этот продуктово-платформенный подход подчеркивает два четких принципа: во-первых, рассматривать ERP-систему как сумму возможностей, а не монолитный стек, и, во-вторых, продукт определяет решение о том, какие части ERP-системы использовать, а не наоборот. .
Переход к операционной модели продукта и платформы имеет большое значение и требует изменения мышления для большинства ИТ-организаций. Традиционно компании были сосредоточены на покупке ERP-решений и управлении поставщиком и системным интегратором для выполнения настроек. Хотя этого все еще достаточно для областей, где в основном полагаются на стандартные процессы, этого недостаточно для областей, где компаниям требуется что-то адаптированное к их потребностям. Большинство поставщиков ERP понимают это и сами начали настаивать на большей модульности и ядре. В то же время устаревшие ИТ обычно решали эту проблему, надстраивая ERP-систему, что приводило к значительной сложности управления любыми изменениями.
Следствием этого изменения является то, что ИТ-специалистам нужно будет более активно управлять ERP-системами. Это означает развитие глубоких инженерных навыков, активное управление системными сложностями и зависимостями и тесное сотрудничество с бизнесом, чтобы изменения приносили пользу для бизнеса.
После обретения ясности со стратегией и фокусированием на операционной модели продукта и платформы следующим важным шагом будет определение того, какие элементы ERP-системы непосредственно поддерживают бизнес-стратегию. На высоком уровне этот анализ стоимости делит функции и возможности в системе ERP на две группы:
Хорошо продуманная карта возможностей также поможет определить, какой кластер модулей исходя из ценности для бизнеса необходимо обновить.
Этот продуктово-платформенный подход подчеркивает два четких принципа: во-первых, рассматривать ERP-систему как сумму возможностей, а не монолитный стек, и, во-вторых, продукт определяет решение о том, какие части ERP-системы использовать, а не наоборот. .
Переход к операционной модели продукта и платформы имеет большое значение и требует изменения мышления для большинства ИТ-организаций. Традиционно компании были сосредоточены на покупке ERP-решений и управлении поставщиком и системным интегратором для выполнения настроек. Хотя этого все еще достаточно для областей, где в основном полагаются на стандартные процессы, этого недостаточно для областей, где компаниям требуется что-то адаптированное к их потребностям. Большинство поставщиков ERP понимают это и сами начали настаивать на большей модульности и ядре. В то же время устаревшие ИТ обычно решали эту проблему, надстраивая ERP-систему, что приводило к значительной сложности управления любыми изменениями.
Следствием этого изменения является то, что ИТ-специалистам нужно будет более активно управлять ERP-системами. Это означает развитие глубоких инженерных навыков, активное управление системными сложностями и зависимостями и тесное сотрудничество с бизнесом, чтобы изменения приносили пользу для бизнеса.
Определите, какие части ERP-системы добавляют ценность
После обретения ясности со стратегией и фокусированием на операционной модели продукта и платформы следующим важным шагом будет определение того, какие элементы ERP-системы непосредственно поддерживают бизнес-стратегию. На высоком уровне этот анализ стоимости делит функции и возможности в системе ERP на две группы:
- В одном сегменте находятся дифференцирующие элементы, создающие ценность бизнеса. Например, для розничного продавца, который хочет обеспечить самую быструю доставку, это будет означать приоритетность возможностей выполнения и логистики. Во многих случаях эти возможности предоставляются через микросервисы и полностью независимы от ERP-системы.
- В другом сегменте находятся товарные функции, которые не являются ключевыми для достижения конкурентного преимущества. Во многих случаях эти функции включают юридическое управление или управление имуществом. И здесь достаточно ERP для обеспечения стабильности и управления. Если применяются отраслевые стандарты, компания часто извлекает выгоду из инноваций поставщика и создает ценность без отклонениий от стандарта. Любые настройки, созданные ИТ-специалистами, должны приносить достаточную ценность, чтобы компенсировать работу, необходимую для их проведения и обслуживания ERP.
Результат этого упражнения - карта возможностей дифференцирующих и недифференцируемых возможностей ERP и того, как они организованы. Хотя большинство классификаций высокоуровневы, но области, требующие детализации. Например, управление ассортиментом считается товарной функцией, но прогнозирование спроса — это то, чем эта компания хочет отличаться от своих конкурентов.
Хорошо продуманная карта возможностей также поможет определить, какой кластер модулей исходя из ценности для бизнеса необходимо обновить.
Эта точка зрения сильно отличается от ситуации, когда вендоры, а не бизнес, определяют границы функциональности и потребности в модернизации. А ведь пока во многих действующих компаниях даже заинтересованные стороны, не связанные с ИТ, говорят о проекте как о модернизации решений вендора ERP, а не как о проекте модернизации «финансов» или о модернизации «цепочки поставок».
Сосредоточьтесь на снижении затрат и рисков при обновлении малоценных частей системы
ИТ-директора должны настаивать на немедленном обновлении решений сегмента дифференцируемых элементов ERP. Для недифференцирующих элементов ERP нужно тщательно выбирать последовательность обновлений, управляя затратами и рисками. Таким образом, обновление превращается из одного многолетнего проекта в серию небольших программных проектов, каждый из которых длится пару месяцев. Это сокращение масштаба снижает риск (небольшой проект = небольшой риск) и определяет программы трансформации, быстро повышающие ценность.
Три шага по упрощению монолитной установки ERP.
1. Отключение ненужных связей
Замена основных систем может оказаться непростой задачей из-за множества подключений к другим приложениям. Некоторые из этих подключений помогают выполнять стандартные функции (например, расчеты с кредиторами), соответствуют всем архитектурным рекомендациям вендора и просты в обслуживании. Эти соединения выполняют нужную работу и их нельзя трогать. Однако часто существует множество связей, которые являются либо обходными путями, либо специальными решениями. Огромный объем и уникальность этих соединений делают любые усилия по модернизации сложными и трудоемкими.
Первым шагом является создание нового уровня между базовой системой и приложениями, к которым она подключается. Его часто называют фасадом. Все новые соединения будут поступать на этот фасадный уровень через API, которые получают доступ к данным из системы ERP. Таким образом, множество соединений отделяются от базовой системы. Это дает большое преимущество, заключающееся в возможности вносить изменения в систему, например, реализовывать аспекты модульной архитектуры, не затрагивая все подключаемые приложения. Фасад можно разработать менее чем за год. Он должен быть на 100 процентов идеальным; он просто должен быть функциональным.
Но разработчики не будут использовать даже хороший фасад, если не будет эффективного управления, обеспечивающего его использование. Один из способов сделать это - предоставить командам разработчиков доступ к основным функциям, не прибегая к длительным механизмам утверждения и не ожидая, пока кто-то из основной команды создаст индивидуальный интерфейс. Помимо таких «пряников», могут понадобиться и «кнуты» — например, штрафы для тех, кто не следует новым протоколам.
2. Миграция настроек
Каждую настройку необходимо перенести — и часто каким-то образом подправить — в новую среду, что может быть рискованно из-за соответствующей сложности настроек. Чтобы решить эту проблему, компаниям необходимо создать цифровую платформу (как правило, в облаке), к которой можно получить доступ через микросервисы. Количество и функции цифровых платформ могут варьироваться; некоторые компании, например, создадут одну платформу для работы с клиентами, одну для цепочки поставок и одну для самой ERP-системы. Платформа становится местом, куда можно переместить настраиваемые функции и где разрабатывается новый код.
Важно оценить, какие настройки наиболее важны. Этот процесс неизбежно раскрывает многие настройки, которые больше не нужны и могут быть удалены, что упрощает обновление.
3. Уменьшения ядра
После того, как настройки будутудалены из ядра, необходимо начать сжимать само ядро до необходимых функций.
По сути, это процесс дезагрегации, который удаляет множество сложных соединений, которые часто встроены в большие системы. Таким образом, разработчики и инженеры могут затем заменить или улучшить определенную функциональность, не затрагивая другие части системы. Этот процесс обычно также включает в себя очистку базы кода, что упрощает его понимание и, следовательно, исправление или замену.
Как отмечалось ранее, этот процесс дезагрегации не должен затрагивать такие функциональные области, как бухгалтерский учет или контроль, которые выполняют стандартные операции в системе ERP. Только те функции, которые часто являются частью тесно связанного ядра без каких-либо функциональных причин, такие как управление складом, прогнозирование спроса или транспортировка, могут находиться за пределами основной системы ERP.
Заключение
Модернизация ERP масштабна, сложна и необходима, особенно по мере того, как возрастает давление на бизнес, а поставщики облачных услуг и ERP внедряют новое программное обеспечение и услуги. Однако, применяя подход, основанный на продуктах (услугах) и платформах, компании могут расставлять приоритеты в отношении обновлений, которые создают ценность, и снижать риски обновлений, которые не создают ценности. Так компании могут лучше управлять затратами и улучшать результаты.
Источник.
https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-erp-platform-play-cheaper-faster-better
The ERP platform play: Cheaper, faster, better. February 9, 2023 Article
Комментариев нет:
Отправить комментарий