Меню

Создание гибкого и адаптируемого ERP решения

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

адаптируемость ERP решения.

Автор: Бретт Бобауф (Brett Beaubouef)

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

Знать ограничения

С технической точки зрения существует два метода, позволяющие сделать коробочное программное обеспечение, такое, как ERP, гибким и адаптируемым:

1.       Программирование (касается гибкости или возможности изменения)

2.       Конфигурирование (касается адаптируемости или возможности легкого изменения)

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

Программирование предоставляет точную инструкцию для реакции на заданные бизнес-события,  условия или действия.   Существуют методы программирования и дополнительные утилиты, которые обеспечивают некоторый уровень технической гибкости (примеры: объектно-ориентированное программирование, сервис-ориентированная архитектура), однако гибкость бизнеса чрезвычайно ограничена в лучшем случае (если только поставщик ERP не может разработать практические средства применения искусственного интеллекта — нечеткой логики к своему программному обеспечению).    Степень гибкости и адаптируемости, которую Вы можете создать с помощью программного обеспечения ограничена.    Важно помнить, что есть и иные компоненты бизнес решения, которые больше подходят для решения вопросов гибкости и адаптируемости.

Знать потенциал

Давайте еще раз рассмотрим компоненты бизнес решения вместе с присущим им потенциалом.

Потенциал бизнес решения

Слишком часто мы неэффективно используем имеющийся у нас потенциал ключевых компонентов бизнес решений.   Программное обеспечение ERP хорошо автоматизирует последовательные, повторяющиеся действия, основанные на установленной логике (бизнес правилах).   Программное обеспечение ERP не является устойчивым, рентабельным вариантом

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев3

Комментарий от  

Олег Точенюк

  |  17 июля 2011, 11:35

Из практики на скольких проектах топ-менеджмент озвучивал следующую фразу, типа система не гибкая, причем в их понимании гибкость, это когда чуть ли не каждый месяц меняется оргструктура компании, а система должна за этим всем успевать и ответы, что ну нельзя менять коды БЕ/Заводов/Пароходов раз в месяц и т.д., их подчиненность между собой натыкаются на один ответ: "Ваша система не гибкая". Причем объяснение, что это даже не система, а принципы построения и функционирования реляционных баз данных, не проходит. В общем я так понимаю, многие продолжают путать гибкость с флюгером.

Комментарий от  

Юрий Нечитайлов

  |  01 августа 2011, 17:06

Олег, спасибо за комментарий!
Возможно, для отражения подобных требований следует ввести еще один критерий - "мягкость" системы. Мягкость - как способность системы удовлетворять еще не сформировавшиеся потребности пользователей, т.е. система мягкая, если пользователь не знает что он хочет, и из какой области он может захотеть, а система уже может.
А для того, чтобы пресечь излишние запросы, в концепте, как известно, желательно прописывать не только то, что будет делать система, но и что она делать не будет.

Комментарий от  

Олег Точенюк

  |  02 августа 2011, 12:37

Мягкость? Ну в такой концепции как "пособность системы удовлетворять еще не сформировавшиеся потребности пользователей" вряд ли можно как это формализовать? Например SAP, хорошо если пользователи используют его на 10-20% от возможностей, тогда можно ли считать его "мягким"? Или нужно заранее определить направления развития и если основное направление развития изменение оргструктуры, то не "мягкий", а вот если расширение оргструктуры, тогда уже  "мягкий" :-)