Чтобы не отстать в XXI веке

При создании ИС предприятия даже текущие практические решения целесообразно принимать, учитывая перспективы развития ИТ и наук об управлении, причем не только ближайшие и среднесрочные, но и более дальние.

Леонид Отоцкий

При создании ИС предприятия даже текущие практические решения целесообразно принимать, учитывая перспективы развития ИТ и наук об управлении, причем не только ближайшие и среднесрочные, но и более дальние

Для принятия дальновидных и корректных текущих решений в процессе создания ИС предприятия очень важно учесть перспективы развития ИТ, а также современных наук, изучающих управление. При этом полезно рассматривать развитие ИТ на трех уровнях перспективы: ближайшей, среднесрочной и дальней, границы которых можно определить скорее не временными рамками, а «событийными». Так, для ближайшей перспективы базовые технические решения уже реализованы или реализуются (а соответствующие базовые понятия уже стали если не общепринятыми, то хотя бы привычными), и основная задача состоит в их освоении (это потребует, по грубой оценке, пять - десять лет).

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

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

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

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

Несмотря на такую разницу, есть общая путеводная нить направления развития ИТ — все большая унификация и стандартизация компонентов. Если для ближайшей перспективы это техническая и программная «отверточная» технология (аналог plug-and-play), для среднесрочной перспективы это уже семантическая технология plug-and-play (здесь имеется в виду прежде всего стандартизация и унификация «смысловых элементов», позволяющая организовать новый уровень технологии В2В и В2С), то для далекой перспективы — это plug-and-play общебиологического и социального уровня. Очевидно, что это будут не обычные, регламентированные распоряжением сверху и достаточно произвольно связанные с практикой стандарты, а результаты обобщения многих проб и ошибок, с одной стороны, и с другой — все большее приближение к тем «естественным» информационным объектам и процессам, которые являются универсальными для любых жизнеспособных систем [1].

Следуя критерию «стандартных элементов» и была, в частности, выбрана стратегия развития ИС предприятия на Магнитогорском металлургическом комбинате (ММК) [2], [3]. Одним из важных критериев выбора был также учет скорости развития ИТ. За много лет в системах MRP/ERP уже сменилось несколько поколений средств ИТ, при том что набор базовой функциональности остается стандартным [4]. Следовательно, ИТ и в части способов реализации ERP-пакетов не только продолжают развиваться, но и далеки от стабилизации.

Все это привело нас к практическому выводу, что конкретные решения в области ИТ лучше принимать с точки зрения перспективы их развития, а не с точки зрения сложившейся на данный момент конъюнктуры.

Ближайшие перспективы

Что касается базовых типовых понятий и бизнес-процессов ИС предприятия, то они давно сложились в рамках MRP/ERP [4], и нужно просто побыстрее к ним переходить. Особенно это становится актуальным в связи со все большей ориентацией России на международные стандарты. Практический опыт внедрения на ММК модуля Oracle HR показал, что управление персоналом достаточно спокойно перешло на используемые в этом пакете стандартные понятия и бизнес-функции, так как они строгие и более точно соответствуют реальным особенностям управления персоналом по сравнению c «неинтегрированной» технологией (например, Oracle HR обеспечивает строгое централизованное ведение всех организационных структур и штатных позиций и принципиальное выделение всех назначений персонала как «объектов во времени» (используется специальный механизм date tracked objects), позволяя отслеживать историю назначений и производить «множественное» назначение одного и того же лица).

Сейчас началась работа по освоению типовых понятий и бизнес-функций по управлению финансами и производством в рамках внедрения других модулей системы Oracle Applications. Нужно отметить, что такой переход — далеко не простой процесс, в особенности в области финансового управления (известно, что практика отечественного бухучета находится дальше, чем многие другие области учета и планирования от мировых стандартов, а также от общих требований жизнеспособных систем). Это, кстати, является одной из основных причин плохой приживаемости модулей типа General Ledger («Главная книга») западных ERP-пакетов, а если они и внедряются, то в режиме разделения управленческого и бухгалтерского учета, что противоречит самой сути ERP-интеграции.

Что касается «технических» средств описания стандартных компонентов, то уже сейчас ведущие поставщики программного обеспечения ведут активные работы по совершенствованию, стандартизации и интеграции средств описания моделей данных и моделей процессов своих продуктов. При этом базовыми стандартами являются UML (Unified Modelling Language), XML, XMI (XML Metadata Interchange), CWM (Common Warehouse Metamodel) и MOF (MetaObject Facility) в сочетании с технологией Java. В UML и CWM уже заложен новый уровень обобщения семантики предметных областей (use_case, actor, role, association, responcible_party, schedule_entity, contact и т. п.), который используется для «наполнения» содержания моделей.

Так, компания Unisys активно развивает свою технологию UREP (Unified REPository), в основу которой положено применение подхода OMG (Object Management Group) к унификации обмена данными посредством XMI между MOF, UML и XML. Это позволяет организовать новый уровень интеграции бизнеса, так как унифицируется взаимодействие через DTD (Data Type Definition) для разработанных в UML моделей, DTD для метамодели в MOF (которая, в свою очередь использует UML) и DTD для метамодели «хранилища данных» (CWM). На следующем этапе развития технологии UREP компания Unisys предполагает использовать новые версии стандартов OMG (UML 2 и MOF 2).

Корпорация Oracle расширяет процесс стандартизации элементов своих бизнес-моделей для обеспечения более совершенной «отверточной» технологии создания бизнес-приложений и так же, как Unisys (и, кстати, IBM), участвует в разработке XMI.

Уже в некоторых новых модулях Oracle Applications (Self-Service, CRM) начали использоваться «Бизнес-компоненты для Java», основанные на Java и XML (BC4J — http://technet.oracle.com/ tech/java/jroadmap/bc4j/listing.htm).

BC4J являются надстройкой над JDeveloper и предназначаются для создания масштабируемых, многоуровневых приложений на основе типовых, многократно используемых (reusable) компонентов. В рамках СУБД Oracle9i [5] применяется уже (так же, как и у Unisys) новый стандарт OMG — «Общая метамодель хранилищ» (CWM), используемый для замены OLAP-технологии Oracle Express.

Кроме того, Oracle и Parametric Technology Corporation (PTC) в октябре 2000 года образовали стратегический альянс по интеграции инженерных приложений Oracle с PDM-системой Windchill PTC, так как обе фирмы используют одни и те же стандарты — Oracle8i, XML и Java.

Так же, как и Unysys, Oracle ведет работу по созданию более семантически глубокой метамодели (на основе UML, XML и XMI) как надстройки над JDeveloper для модернизации действующей метамодели Oracle Applications — Applications Object Library.

Что касается самих базовых стандартов OMG, то сейчас идут активные работы над новой версией UML 2 (которая должна интегрироваться с базовым языком EXPRESS стандартов ISO 10303), а также над новой версией MOF 2. Кроме того, уже вышла новая версия базовой модели документов XML (DOM 2 — Document Object Model), которая включает стандартный API-интерфейс для работы с данными и документами с использованием языков программирования.

На ММК уже сейчас применяются принципиально Web- и Java-ориентированные технологии Oracle Applications и Windchill. При этом все активнее идет переход на использование «сверхтонких» удаленных клиентов (для удаленных рабочих мест), когда даже Web-браузер «крутится» на терминальном сервере (Citrix), а клиенты связываются с сервером либо через корпоративную сеть, либо через модемы. Ведутся также работы с нашим бизнес-партнером «Борлас Ай-Би-Си» по использованию технологии сетевых компьютеров Sun (Sun Ray).

Учитывая вышеуказанные тенденции по стандартам OMG, на ММК намечается провести обучение по UML, XML, CWM и JDeveloper, а также основанным на них средствам CASE (Ratonal Rose и новой версии Oracle Designer).

Руководителям служб ИТ на этапе ближайшей перспективы можно дать рекомендацию осваивать и еще раз осваивать новые стандартные компоненты. Что касается среднесрочной и долгосрочной перспектив, то их детальное описание требует отдельной статьи. Ниже приведены лишь краткие тезисы.

Среднесрочные перспективы

1. Ожидается переход на новые модели предприятия по сравнению с MRP/ERP, основанные на широком использовании системного подхода (например, ISO 184/SC5/WG1 — http://www.mel.nist.gov/sc5wg1) и общей теории жизнеспособных систем Бира (например, TOC — теория ограничений, www.goldratt.com). Нужно отметить, что методология ТОС начала использоваться и в России. Так, компания «Магинфоцентр» уже провела семинары по ТОС с руководством нескольких предприятий и сделала средствами ТОС анализ причин снижения рентабельности на одном из них [7].

18.03.2001г