Ровно два года назад, в конце декабря 2007 года, в Российской Федерации вступил в силу Федеральный закон «О саморегулируемых организациях», где само понятие саморегулирования чуть ли не отождествляется со стандартизацией. Практическое воплощение этого документа может дать импульс развитию ИТ‑стандартов определенной категории.

Разумеется, одна из первых статей закона дает предельно четкую трактовку понятия саморегулирования. По этому поводу в рамках документа сказано следующее: «Под саморегулированием понимается самостоятельная и инициативная деятельность, которая осуществляется субъектами предпринимательской или профессиональной деятельности и содержанием которой являются разработка и установление стандартов и правил указанной деятельности, а также контроль за соблюдением требований указанных стандартов и правил».

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

И, наконец, еще одна статья этого закона гласит: «Саморегулирование в соответствии с настоящим Федеральным законом осуществляется на условиях объединения субъектов предпринимательской или профессиональной деятельности в саморегулируемые организации».

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

Что касается ИТ-отрасли, то, говоря о стандартах, мы обычно либо вспоминаем о пресловутой серии документов ГОСТ34xxx, определяющих требования к ИТ‑системам, стадии их разработки и процессы жизненного цикла, или же имеем в виду чисто технические спецификации, без которых просто невозможно обойтись, строя архитектуру информационных систем и осуществляя ИТ-поддержку бизнеса. К ним можно отнести, например, спецификации языка запросов к реляционным базам данных (SQL), а также многочисленные сетевые или телекоммуникационные протоколы.

Мы же в рамках этого материала хотим в очередной раз напомнить о существовании отраслевых информационных стандартов, которые также могут и, наверное, должны развиваться в России, а под флагом применения закона «О саморегулируемых организациях» (если таковой, конечно, будет иметь более или менее широкое практическое воплощение) — тем более. Пока же стандарты такого рода на российском рынке остаются в тени, если вообще можно серьезно говорить об их практическом распространении.

Три примера из западной жизни

В этом смысле хочется упомянуть несколько типичных отраслевых, а в ряде случаев — скорее даже межотраслевых западных стандартах, упоминание о которых изредка появляется в отечественной прессе, посвященной использованию информационных технологий в бизнесе. В том числе, разумеется, и в нашем журнале. Остановимся на трех спецификациях, охватывающих основные отрасли современного бизнеса — промышленное производство, логистику и розничную торговлю. Речь идет о стандартах ISA-95, SCOR (Supply Chain Operation Reference model), а также CPFR (Collaborative Planning Forecasting and Replenishment). Все эти спецификации роднит то, что в русском языке для них более подходит термин «модели» (а в английском — соответственно понятие framework), так как они содержат в себе не жесткие рекомендации, а скорее базовые принципы. На их основе, в свою очередь, строятся конкретные структуры управления теми или иными организациями, а также архитектура автоматизации.

Начнем с модели ISA-95, разработанной в 2005 году глобальной некоммерческой организацией ISA (International Society for Automation), предоставляющей основные принципы по построению информационного интерфейса между системами уровня Enterprise и MES‑системами. Проблема, как известно, стара как мир, очень часто обсуждаема и весьма непроста как в постановке, так и в решении. Но сейчас речь не об этом. Пятый, высший слой этой модели, по сути, определяет набор и последовательность возможных транзакций, а следовательно, возможные варианты бизнес-процессов, происходящих на границе между разными иерархиями управления на промышленном предприятии.

Есть еще две черты ISA-95, характерные для отраслевых стандартов вообще. Во-первых, оставаясь строго отраслевыми, они тем не менее постоянно расширяют свои наработки в соответствии с нуждами непрерывно ширящейся аудитории членов ISA. И если первоначально модель ISA-95 была ориентирована исключительно на процессное производство (до сих пор 80% его членов представляют именно этот тип производства), то в последние год-два значительные разработки были созданы и для дискретных индустрий. Во-вторых, вслед за концептуальными наработками, определяющими, кроме упомянутых бизнес-процессов, еще и характерные объекты для возможного взаимодействия, стандартную терминологию и прочее, следует появление более осязаемых ИТ‑стандартов в виде отраслевых спецификаций XML. В данном случае речь идет о B2MML (Business to Manufacturing Markup Language), являющем собой XML-имплементацию ISA-95.

Подобный прогресс в развитии ISA-95 дает возможность некоторым компаниям (например, извест­ной на американском рынке компании Apriso) выводить на рынок специализированные BPM-решения, ориентированные исключительно на бизнес-процессы производственного предприятия (холдинга) и способные выстраивать автоматизацию процессов не только по горизонтали, но и по вертикали традиционной иерархии промышленных производств.

Следующая выбранная нами для рассмотрения аббревиатура SCOR представляет собой референсную модель, разработанную (в сотрудничестве с исследовательской компанией AMR Research) опять‑таки независимой организацией Supply Chain Council, занимающейся разработкой стандартов и образовательной деятельностью в области организации цепочек поставок. Модель эта сейчас считается весьма популярной при построении и, что немаловажно, диагностике цепочек поставок в разных отраслях. Снова пропустим содержательную сторону стандарта, а вместо этого обозначим три основополагающих принципа, на которых строится модель SCOR. По заявлениям самих разработчиков данной спецификации, это:

  • наличие модели процесса;
  • численное измерение производительности процесса (performance management);
  • использование лучших практик.

Здесь снова мы имеем отсутствие четких рекомендаций. Ценность SCOR в том, что бизнес-процессы цепочек поставок четко классифицированы, разбиты по иерархии и степени детализации, и связи между ними также хорошо концептуально проработаны. Что касается performance management, то в этом направлении разработано свыше 150 ключевых индикаторов оценки функционирования цепочки поставок. Из всего многообразия моделей и индикаторов, а также опираясь на адекватную их классификацию, пользователи сами строят собственную модель, адекватную их бизнесу. Если подобная практика становится массовой, то из нее логически вытекает третий принцип SCOR — использование лучших практик.

В ракурсе автоматизации все эти тезисы вновь наталкивают нас на мысли о BPM-решениях, и на самом деле они создаются. Так, например, модель SCOR среди прочих других изначально присутствует в системе бизнес-моделирования ARIS и служит в том числе как инструмент развертывания BPM-решений.

И наконец, отметим еще одну спецификацию CPFR, также разработанную некоммерческой межотраслевой организацией VICS (Voluntary Interindustry Commerce Standards Association). О CPFR мы недавно писали отдельно (см. Intelligent Enterprise № 10/2009, стр. 22). Из того, что было сказано, напомним лишь, что CPFR нацелена на устранение проблем взаимодействия производителя и розничного продавца в том, что касается управления цепочками поставок продукции, и только по этой причине CPFR также следует отнести к процессной модели. К сказанному там добавим, что объекты и сообщения CPFR были напрямую положены в информационную спецификацию на основе XML, называемую VICS CPFR XML Messaging Standard.

Российские перспективы

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

Прежде всего еще раз резюмируем общие черты рассмотренных спецификаций. Все они:

  • в значительной мере рассчитаны на процессную модель организации бизнес-процессов;
  • инициируются некоммерческими отраслевыми или межотраслевыми организациями разного масштаба (вплоть до международных);
  • постоянно развиваются на базе непрерывных инициатив членов этих организаций и в этом смысле являются не стандартами в строгом смысле, а скорее базовыми моделями для дальнейшей конкретизации в условиях конкретных производств;
  • в разной степени используют метрики для диагностирования формируемых бизнес-про­цессов;
  • рассчитаны на четкое упорядочение терминологии, описание отраслевых объектов, их атрибутов и методов работы с ними; как следствие, имеют четко ассоциируемые с ними XML‑схемы.

Совершенно ясно, что все подобные модели существенно отличаются от того, что отечественные специалисты привыкли понимать под стандартами. В данном случае не стоит вопрос, будем ли мы придерживаться выбранного стандарта или откажемся от него. Вопрос, или даже целая группа вопросов, в данном случае ставится совершенно по‑другому. Будет ли наша организация разбираться в принципах, заложенных в основу той или иной модели, и на ее основе строить собственный стандарт? Есть ли у организации готовность, наличие материальных, а главное, интеллектуальных ресурсов войти в соответствующую некоммерческую организацию (не важно, давно существующую международную или вновь созданную российскую), чтобы быть активными соучастниками развития информационных спецификаций, лоббируя, если угодно, таким образом, интересы собственного бизнеса? Может ли наша организация в должной мере использовать процессную модель бизнеса, обеспечивать (не на словах, а на деле) должную степень открытости по отношению к бизнес-партнерам? Пока, повторимся, российские индустрии, как нам кажется, слабо интегрированы в международные некоммерческие ассоциации и не создают национальных.

Что касается автоматизации, то, внедряя подобные модели, тоже надо быть готовым несколько трансформировать сложившийся подход. Сейчас это уже касается далеко не всех заказчиков, но, думается, по‑прежнему, многих. Опять‑таки не ставится вопрос о внедрении новой ERP или иной корпоративной системы. Дело даже не столько в наращивании их функциональных возможностей (хотя данный тезис уж точно не лишен оговорок). В гораздо большей степени речь идет об организации процессного подхода и организации дополнительного слоя «процессной» автоматизации на основе функций уже имеющихся бизнес‑систем. Речь также идет об оперативном управлении производительностью на основе показателей, а решение этой задачи редко отождествляется с использованием какой-либо одной корпоративной системы.

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

Также нельзя забывать об управлении корпоративными данными как единым ресурсом, что тоже, как известно, является вполне самостоятельной задачей, совершенно отделенной от задачи внедрения и эксплуатации каких‑либо корпоративных информационных систем. Как мы отметили, представленные модели тесно связаны с разработкой и дальнейшим совершенствованием отраслевых XML‑стандартов, а применение модели CPFR, о которой мы писали в упоминавшейся выше статье, напрямую связано с наведением порядка в мастер-данных. Все это опять‑таки говорит в пользу того, что вопрос управления корпоративными данными может постепенно выделяться во вполне самостоятельное направление автоматизации того или иного предприятия.