МАТЕРИАЛ | 03.10.02 |
© Материал был опубликован в издании "Profi-Club"
В зависимости от степени использования стандартных понятий, методов и средств можно провести следующую классификацию поколений автоматизированных систем управления.
1-e поколение:
а) использование индивидуальных моделей бизнес-процессов для отдельных предприятий или их типов;
б) использование плоских файлов (или иерархических СУБД) и 3GL, в стиле IBM 360/370.
Примеры: уникальные системы металлургических компаний USX и British Steel, работающие только на конкретном предприятии.
2-е поколение:
а) использование типовой модели бизнес-процессов MRP/MRP II для любого типа предприятий; Примеры: базовые системы компаний Computer Associates, SAP и Baan.
3-e поколение:
а) развитие модели ERP (п. 2а). Применение реляционных СУБД ведущих производителей (Oracle, Sybase, Informix, Ingres и т.п.), основанных на международных стандартах SQL; Примеры: базовые системы от Oracle, ESI/Technology, IFS; адаптации новых версий систем 2-го поколения в части использования некоторых возможностей типовых реляционных СУБД с сохранением собственных средств разработки и поддержки.
4-е поколение:
а) перенос типовых функций, процедур, триггеров с уровня приложений на уровень СУБД (использование возможностей нового поколения реляционных СУБД ведущих производителей); 5-е поколение:
а) дальнейшая типизация метаданных, логических структур баз данных и описаний бизнес-функций на основе стандартов STEP и CORBA (включая UML); Развитие систем 5-го поколения только начинается: Критерии выбора
Критерий 1. Место базового программного продукта среди пяти поколений интегрированных систем управления.
Чем больше номер поколения, тем проще установить, настроить и эксплуатировать систему, тем меньше требуется личного участия фирмы-разработчика и/или ее партнеров в пусконаладочных работах и особенно при эксплуатации. Например, компания Oracle специально подчеркивает возможность самостоятельного развития приложений клиентом с помощью стандартных средств разработки Designer/2000 и Developer/2000.
Понятия «степень модульности» и «степень масштабируемости» также тесно связаны с поколением базового продукта ERP системы. Так, например, средства взаимодействия с дополнительными модулями ALE и XMA компаний SAP и Baan, a также средства, обеспечивающие интерфейс с внешними системами BAPI и BPC, были специально разработаны совсем недавно как отдельные продукты. В то же время средства обмена сообщениями от IFS (MHS) или средства Открытого интерфейса Oracle изначально представляли собой единый универсальный механизм синхронизации как собственных модулей, так и средств обмена сообщениями с «чужими» модулями.
В качестве примера модульности и масштабируемости можно привести использование системы IFS на мебельной фабрике, бизнес-процессы которой предусматривают ограниченный набор функций, охватываемых «логистикой» (движение материалов, закупки, продажи, автоматические бухгалтерские проводки, баланcы, отчеты), и около 40 терминалов, эксплуатацию системы поддерживают четыре работника АСУ, причем они знают «только» стандартные средства DOS, SCO UNIX и Oracle. C другой стороны, система также эксплуатируется на гиганте Volvo c разбросанными по всему миру заводами, где кроме «стандартного» набора ERP модулей используется мощная подсистема Управления Ремонтами (Мaintenance), которую сегодня начинают внедрять и на ММК. И в том, и в другом случае используется одно и то же программное обеспечение, поддерживающее интеграцию управления, соответствующее уровню ERP.
На российских предприятиях имеет смысл более активно внедрять новые технологии – в них отсутствует «давление груза» MRP систем 2-го поколения.
В дополнение к описанию эволюции ИСУ с точки зрения развития инструментальных средств полезно обсудить новые тенденции стандартизации, специализации и кооперации в ИСУ, которые уже выходят за рамки систем 5-го поколения: Критерий 2. Количество автоматизируемых бизнес-функций.
Очень часто этот критерий используется с некоторым мифологическим оттенком (больше – значит лучше). Поэтому имеет смысл рассмотреть разные его аспекты более подробно.
С одной стороны, количество автоматизируемых бизнес-функций не может быть определяющим критерием по следующим причинам: Можно даже сказать, что богатство функций в сочетании с устаревшим инструментарием, «плохой» логической структурой данных, отсутствием общепринятых «стандартных элементов» просто вредно для неофитов от ИСУ. Так, внешнее богатство функций эмоционально заслоняет реальную оценку последствий использования собственных нестандартных средств поставщика.
С другой стороны, нужно как можно раньше начинать внедрять новые аналитические возможности таких выделяемых в отдельные подсистемы функций, как работа с хранилищами данных, OLAP, системами поддержки принятия решений (DSS) и аналитическими функциями более высокого уровня (например, типовой модуль «Автоматическое предупреждение» Oracle (Alert).
Критерий 3. «МОНО» и «МУЛЬТИ» – ориентированность на поставщика СУБД.
Декларация независимости MRP/ERP системы от конкретной СУБД – необходима прежде всего разработчикам, а не клиентам, которые хотят внедрять систему . Такая независимость во многом связана с пережитками MRP систем 2-го поколения, когда разработчики использовали только свои собственные и инструменты средства администрирования баз данных.
В общем процессе эволюции ИТ такие поставщики не смогут широко использовать возможности новых поколений СУБД и современных средств разработки. Перейти к MRP/ERP системам 4-го поколения для поставщиков, ориентированных на несколько СУБД (имеющих свои собственные средства администрирования и разработки), будет сложнее, чем для «МОНО» поставщиков. Для «МУЛЬТИ» поставщиков также будет сложно переключиться на объектно-ориентированную основу MRP/ERP систем 5-го поколения. Критерий 4. Легкость русификации системы при внедрении и сопровождении.
Этот критерий, требует отдавать предпочтение системам, имеющим средства табличного задания переводимых понятий с автоматической перегенерацией экранных форм, меню и т.д. на другой язык. Даже если ERP система уже локализована, нужно учитывать трудозатраты на развитие системы и адаптацию ее новых версий.
Критерий 5. Опыт команды разработчиков/провайдеров в практическом внедрении «больших» систем управления на предприятиях СНГ.
Наличие у команды методик адаптации идеологии MRP/ERP к российским условиям часто оказывается решающим фактором успешного внедрения – мало купить систему, надо еще и грамотно ее настроить, а самое главное, довести до самостоятельного жизнеспособного существования, требующего минимальной поддержки со стороны производителя.
Опыта многих российских компаний, специализирующихся на внедрении систем типа «Low End PC» и «Middle PC» для ERP систем оказывается недостаточно. Мы согласны с выводами, изложенными в работе. Действительно, новаторские российские разработки (с точки зрения функциональности) могут быть сделаны «никак не в области финансово-экономических систем». В лучшем случае нам всегда придется догонять, а в худшем – будут появляться «пророки в своем отечестве» которые станут выдавать свои доморощенные поделки за откровения. Наш собственный опыт показывает, что сам факт практической адаптации ERP-системы уже существенно повышает уровень понимания процессов управления на предприятии. При этом преимущество имеют компании, использующие стандартный коммерческий инструментарий 4-го поколения ИСУ, например Ост-Ин или Ай-Ти
Критерий 6. Уровень компьютеризации предприятия на момент установки интегрированной системы управления.
Чем более однородна вычислительная среда на предприятии и чем она ближе к поколениям 3 – 4 интегрированных систем (критерий 1), тем легче внедрить MRP систему (в металлургической отрасли СНГ такой средой сегодня оказался Oracle). И наоборот, когда эксплуатируются разнородные системы, внедрять интегрированную систему очень сложно, если вообще возможно, без принципиальной переделки уже эксплуатируемых систем (legacy systems). Причем независимо от того, продукт какой компании был выбран и какие ресурсы она готова выделить на внедрение своего продукта.
Критерий 7. Гибкость ценовой политики фирмы-поставщика.
Учет этого критерия позволяет снизить прямые затраты на систему. Гибкость цен поставщика во многом зависит от степени модульности системы и ее масштабируемости (см. критерий 1).
В целом мы рекомендуем – ориентироваться на типовые стандартные решения в широком смысле. Это позволит, c одной стороны, без особого труда освоить современные технологии управления, а с другой – выйти на новый уровень стандартизации и интеграции, к которому сегодня подошло мировое сообщество. Можно привести несколько примеров нового уровня интеграции: Дополнительная информация
Данная статья посвящена вопросам внедрения на отечественных предприятиях современных интегрированных систем управления (ИСУ). Конкретно, речь пойдет о критериях выбора систем класса ERP, которые могут быть полезны как для потенциальных потребителей таких систем, так и для поставщиков.
б) см. пункт 1. б плюс использование собственных средств разработки класса 4GL.
б) отказ от использования индивидуальных средств разработки (применение унифицированных средств, основанных на SQL, включая типовые экранные формы, отчеты и т.д.);
в) переход от идеологии мэйнфреймов к идеологии «клиент/сервер» и распределенным базам данных.
б) использование средств автоматизации проектирования и программирования (CASE) для поддержки «электронного проекта» на всех этапах его жизненного цикла;
в) дальнейшая стандартизация и специализация бизнес-функций с выделением в самостоятельные прикладные модули средств поддержки хранилищ данных, OLAP и систем поддержки принятия решений;
г) использование GUI, включая Web интерфейс.
Примеры: новые разработки фирм Decade Financials и Alcie, полностью построенные на Designer/2000 и Developer/2000; новые версии ERP систем от Oracle, ESI/Technology, IFS. Важно отметить, что начали появляться отечественные разработки, ориентированные на технологию 4-го поколения – это системы К*3 и БОСС КОРПОРАЦИЯ.
б) выделение независимых объектно-ориентированных подсистем управления данными о продукции, а также технологий, основанных на стандартах STEP и CORBA (PDM системы 2-го поколения);
в) создание репозитария стандартных компонентов бизнес-объектов и функций для «сборки» прикладных систем и их «перекомпоновки» (для «реинжиниринга бизнес-процессов» при внедрении ERP системы);
г) выделение независимых объектно-ориентированных подсистем сервисного обслуживания и администрирования, основанных на идеологии ORB и DCOM.
д) использование корпоративных и глобальных сетей для создания «виртуальных» производств и предприятий.
С точки зрения «провайдеров» ERP систем между МОНО и МУЛЬТИ имеется обратная зависимость. Так, при ориентации на МУЛЬТИ будет более жесткой привязка к «хозяину», чем при ориентации на МОНО поставщика, так как требуется освоить не только стандартные «коммерческие» средства разработки, но и средства, специфичные для данного ERP провайдера.
Отправить ссылку на страницу по e-mail
Обсудить на форуме
Interface Ltd. Отправить E-Mail http://www.interface.ru |
|
Ваши замечания и предложения отправляйте автору По техническим вопросам обращайтесь к вебмастеру Документ опубликован: 03.10.02 |