Семь критериев выбора ERP-систем для России

Данная статья посвящена вопросам внедрения на российских предприятиях современных интегрированных систем управления (ИСУ) . Конкретно, речь пойдет о критериях выбора систем класса ERP, которые могут быть полезны как для потенциальных потребителей таких систем, так и для поставщиков.

В зависимости от степени использования стандартных понятий, методов и средств можно провести следующую классификацию поколений автоматизированных систем управления [1].

1-e поколение:

а.использование индивидуальных моделей бизнес-процессов для отдельных предприятий или их типов;

б.использование плоских файлов (или иерархических СУБД) и 3GL, в стиле IBM 360/370.

Примеры: уникальные системы металлургических компаний USX и British Steel, работающие только на конкретном предприятии.

2-е поколение:

а. использование типовой модели бизнес-процессов MRP/MRP II для любого типа предприятий;

б. см. пункт 1.б плюс использование собственных средств разработки класса 4GL.

Примеры: базовые системы компаний Computer Associates, SAP и Baan.

3-e поколение:

а. развитие модели ERP (п. 2а). Применение реляционных СУБД ведущих производителей (Oracle, Sybase, Informix, Ingres и т.п.), основанных на международных стандартах SQL;

б. отказ от использования индивидуальных средств разработки (применение унифицированных средств, основанных на SQL, включая типовые экранные формы, отчеты и т.д.);

в. переход от идеологии мэйнфреймов к идеологии «клиент/сервер» и распределенным базам данных.

Примеры: базовые системы от Oracle, ESI/Technology, IFS; адаптации новых версий систем 2-го поколения в части использования некоторых возможностей типовых реляционных СУБД с сохранением собственных средств разработки и поддержки.

4-е поколение:

а. перенос типовых функций, процедур, триггеров с уровня приложений на уровень СУБД (использование возможностей нового поколения реляционных СУБД ведущих производителей);

б. использование средств автоматизации проектирования и программирования (CASE) для поддержки «электронного проекта» на всех этапах его жизненного цикла;

в. дальнейшая стандартизация и специализация бизнес-функций с выделением в самостоятельные прикладные модули средств поддержки хранилищ данных, OLAP и систем поддержки принятия решений;

г. использование GUI, включая Web интерфейс.

Примеры: новые разработки фирм Decade Financials и Alcie, полностью построенные на Designer/2000 и Developer/2000; новые версии ERP систем от Oracle, ESI/Technology, IFS. Важно отметить, что начали появляться отечественные разработки,ориентированные на технологию 4-го поколения - это системы К*3[7] и БОСС КОРПОРАЦИЯ [8].

5-е поколение:

а. дальнейшая типизация метаданных, логических структур баз данных и описаний бизнес-функций на основе стандартов STEP и CORBA (включая UML);

б. выделение независимых объектно-ориентированных подсистем управления данными о продукции, а также технологий, основанных на стандартах STEP и CORBA (PDM системы 2-го поколения) [10];

в. создание репозитария стандартных компонентов бизнес-объектов и функций для «сборки» прикладных систем и их «перекомпоновки» (для «реинжиниринга бизнес-процессов» при внедрении ERP системы);

г. выделение независимых объектно-ориентированных подсистем сервисного обслуживания и администрирования, основанных на идеологии ORB и DCOM.

д. использование корпоративных и глобальных сетей для создания «виртуальных» производств и предприятий.

Развитие систем 5-го поколения только начинается:

• организован альянс Oracle с Metaphase и Sherpa с целью интеграции ERP системы Oracle c PDM системами Metaphase и Sherpa;
• компания Siemens Nixdorf разрабатывает интерфейс между ERP R/3 от SAP и PDM системой фирмы Metaphase;
• выделение самостоятельного PDM модуля из ERP системы фирмы IFS;
• приобретение Baan компании ВА Intellegence - одного из производителей PDM систем;

Более подробное описание эволюции Интегрированных Систем Управления приведено в работе [1].

Критерии выбора

Критерий 1. Место базового программного продукта среди пяти поколений интегрированных систем управления.

Чем больше номер поколения, тем проще установить, настроить и эксплуатировать систему, тем меньше требуется личного участия фирмы-разработчика и/или ее партнеров в пусконаладочных работах и особенно при эксплуатации. Например, компания Oracle специально подчеркивает возможность самостоятельного развития приложений клиентом с помощью стандартных средств разработки Designer/2000 и Developer/2000.

Понятия «степень модульности» и «степень масштабируемости» также тесно связаны с поколением базового продукта ERP системы. Так, например, средства взаимодействия с дополнительными модулями ALE и XMA компаний SAP и Baan [3,5] , a также средства, обеспечивающие интерфейс с внешними системами BAPI и BPC, были специально разработаны совсем недавно как отдельные продукты. В то же время средства обмена сообщениями от IFS (MHS) или средства Открытого интерфейса Oracle изначально представляли собой единый универсальный механизм синхронизации как собственных модулей, так и средств обмена сообщениями с «чужими» модулями.

В качестве примера модульности и масштабируемости можно привести использование системы IFS на мебельной фабрике, бизнес-процессы которой предусматривают ограниченный набор функций, охватываемых «логистикой» (движение материалов, закупки, продажи, автоматические бухгалтерские проводки, баланcы, отчеты), и около 40 терминалов, эксплуатацию системы поддерживают четыре работника АСУ, причем они знают «только» стандартные средства DOS, SCO UNIX и Oracle. C другой стороны, система также эксплуатируется на гиганте Volvo c разбросанными по всему миру заводами, где кроме «стандартного» набора ERP модулей используется мощная подсистема Управления Ремонтами (Мaintenance), которую сегодня начинают внедрять и на ММК. И в том, и в другом случае используется одно и то же программное обеспечение, поддерживающее интеграцию управления, соответствующее уровню ERP.

На российских предприятиях имеет смысл более активно внедрять новые технологии - в них отсутствует «давление груза» MRP систем 2-го поколения.

В дополнение к описанию эволюции ИСУ с точки зрения развития инструментальных средств [1] полезно обсудить новые тенденции стандартизации, специализации и кооперации в ИСУ, которые уже выходят за рамки систем 5-го поколения:

• укрупняются типовые «общесистемные» функциональные блоки (Workflow, Web, DataWarehouse, EDI и др.) [3], задействованные (например, Oracle) во всех «традиционных» ERP модулях ;
• началась разработка единых стандартов организации взаимодействия между разными поставщиками ERP систем (например, поддержка десятью ведущими производителями Единых Спецификаций Open Application Group - OAGIS, http://www.oag.org);
• началось расширение функциональности до cоответствия 3 и 4 уровням пятиуровневой модели управления предприятием С.Бира [4], например, декларация Baan об MRP-III (Money Resource Planning), предполагающая включение методологии Теории Ограничений (TOC) Голдрата (http://www.goldratt.com).

Критерий 2. Количество автоматизируемых бизнес-функций.

Очень часто этот критерий используется с некоторым мифологическим оттенком (больше - значит лучше). Поэтому имеет смысл рассмотреть разные его аспекты более подробно.

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

• большинство интегрированных систем, основанных на стандартах MRP/ERP, имеют типовой базовый набор автоматизируемых бизнес-функций [1];
• основная задача рассийских менеджеров - почувствовать новую технологию интегрированного управления - решается практически любой MRP системой (правда, за разную цену);
• изучение всех бизнес-функций, предлагаемых ведущими зарубежными производителями (SAP, Oracle, PeopleSoft, Baan), невозможно без освоения их базового набора и требует длительного времени (5 лет и более).

Можно даже сказать, что богатство функций в сочетании с устаревшим инструментарием, «плохой» логической структурой данных, отсутствием общепринятых «стандартных элементов» просто вредно для неофитов от ИСУ. Так, внешнее богатство функций [6] эмоционально заслоняет реальную оценку последствий использования собственных нестандартных средств поставщика.

С другой стороны, нужно как можно раньше начинать внедрять новые аналитические возможности таких выделяемых в отдельные подсистемы функций, как работа с хранилищами данных, OLAP, системами поддержки принятия решений (DSS) и аналитическими функциями более высокого уровня (например, типовой модуль «Автоматическое предупреждение» Oracle (Alert).

Критерий 3. «МОНО» и «МУЛЬТИ» - ориентированность на поставщика СУБД .

Декларация независимости MRP/ERP системы от конкретной СУБД - необходима прежде всего разработчикам, а не клиентам, которые хотят внедрять систему [1]. Такая независимость во многом связана с пережитками MRP систем 2-го поколения, когда разработчики использовали только свои собственные и инструменты средства администрирования баз данных.

В общем процессе эволюции ИТ такие поставщики не смогут широко использовать возможности новых поколений СУБД и современных средств разработки. Перейти к MRP/ERP системам 4-го поколения для поставщиков, ориентированных на несколько СУБД (имеющих свои собственные средства администрирования и разработки), будет сложнее, чем для «МОНО» поставщиков [1]. Для «МУЛЬТИ» поставщиков также будет сложно переключиться на объектно-ориентированную основу MRP/ERP систем 5-го поколения.

С точки зрения «провайдеров» ERP систем между МОНО и МУЛЬТИ имеется обратная зависимость. Так, при ориентации на МУЛЬТИ будет более жесткой привязка к «хозяину», чем при ориентации на МОНО поставщика, так как требуется освоить не только стандартные «коммерческие» средства разработки, но и средства, специфичные для данного ERP провайдера.

Критерий 4. Легкость русификации системы при внедрении и сопровождении.

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

17.04.1998г