7 - 2010

Новое слово в управлении основными данными: повышение эффективности работы машиностроительных предприятий

Вячеслав Александров (Ведущий консультант по приложениям для автоматизации бизнеса Oracle Russia.)

«Как есть» — текущая ситуация с управлением данными в большинстве компаний

Master Data, или Основные данные, — в чем особенности?

Машиностроение и управление основными данными

Ответ рынка на возникающие задачи

В будущее — с оптимизмом

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

«Как есть» — текущая ситуация с управлением данными в большинстве компаний

От слаженности и эффективности работы различных подразделений машиностроительного предприятия (холдинга) напрямую зависит прибыльность бизнеса в целом. Для успешного выполнения задачи непрерывного повышения прибыльности все — от рядового сотрудника до высшего руководства машиностроительного предприятия — должны (в идеале) иметь доступ к той информации и данным, которые им необходимы для выполнения их должностных обязанностей наилучшим образом и в нужное время. Производственная концепция JIT (Just­In­Time) может быть применена и для иллюстрации наиболее эффективного подхода по работе с данными на предприятии. Только актуальные, релевантные и точные данные, предоставленные точно и вовремя, действительно могут повысить скорость выполнения бизнес­процессов, сэкономить массу времени и средств. Информационная концепция трактует понятие потребителя данных еще более широко: данные могут быть необходимы как сотрудникам, так и бизнес­процессам, модулям и приложениям или информационной системе предприятия в целом.

Каждая система владеет собственным источником данных. Системы интегрированы 
по принципу «точка-точка»

Каждая система владеет собственным источником данных. Системы интегрированы по принципу «точка-точка»

Каждое подразделение (отдел, линия бизнеса, канал продаж) выполняет на предприятии свою задачу. Иными словами, каждый должен делать свое дело, причем наилучшим образом. Например, данные по продукту: узлу, агрегату, двигателю — необходимы в различном объеме и разном представлении в контексте каждого подразделения. Когда изделие находится в процессе разработки, оно «живет» в системах инженерного проектирования изделий, и здесь главным является управление инженерными данными и жизненным циклом изделия. Однако после того, как продукт выпущен в серийное производство, работа с данными по продукту не заканчивается. Представление данных по продукту в компании существенно расширяется: теперь с продуктом должны работать не только инженеры­конструкторы и производственные подразделения, но также сбыт и маркетинг, бухгалтерия и финансы, ремонтно­сервисные и другие подразделения предприятия. Предположим, сотруднику отдела продаж понадобилась информация по продуктам. Целесообразно ли предоставлять доступ к системе инженерного проектирования сотрудникам из отдела продаж, маркетинга или бухгалтерии? Безусловно, нет. Однако сотрудникам отдела продаж также важно знать определенные технические параметры по продуктам, например варианты их комплектации. Данные по продуктам и их отдельные технические характеристики могут использоваться для разработки ценообразования на продукцию компании. Таким образом, появляются данные по продуктам в контексте коммерческих каналов сбыта, данные о ремонте и обслуживании продуктов, взаимозаменяемых компонентах, запчастях и многое другое. Целесообразно ли хранить эти данные в системах инженерного проектирования, таких как PLM, PDM, CAD, САПР? Скорее всего, эти данные в подобных системах не нужны.

Закономерно возникает вопрос: каким образом возможно взаимоувязать продукт как единую логическую сущность в рамках множества корпоративных информационных систем (PLM, PDM, ERP, CRM и др.) производственной компании? До последнего времени данная задача, как правило, решалась (и решается) предприятиями по интуиции, что выражается в появлении множества дублирующих друг друга по составу и информационному наполнению каталогов и справочников продуктов, товаров, услуг, поставщиков и других типов данных в различных информационных системах. Причиной для появления такого разнообразия, казалось бы, выступает очевидный факт: то, что нужно инженерам, конструкторам и производству, не нужно бухгалтерам, маркетологам и сотрудникам других подразделений — вот и пусть каждое подразделение ведет свои, необходимые только ему справочники. Удобно ли это? Эффективно ли это? Практика ведения бизнеса показывает: при подобном подходе с течением времени справочники разрастаются, ответственных за качество данных невозможно определить, а выверка данных между приложениями и системами в ручном режиме превращается в каторжный труд, отнимая драгоценные время и ресурсы у компании.

Распространенные причины возникновения проблем с управлением основными данными

Распространенные причины возникновения проблем с управлением основными данными

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

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

В результате описанных, а также и других причин (список можно было бы продолжить) качество данных в системах компании с течением времени начинает стремительно ухудшаться. Предприятия наращивают аппаратные вычислительные мощности, выделяют ресурсы на выверку и «чистку» справочников — но всё же по­прежнему не видят основной корневой причины своих проблем…

В начало В начало

Master Data, или Основные данные, — в чем особенности?

Что же необходимо для того, чтобы начать правильно управлять собственными корпоративными данными? Что нужно сделать, чтобы данные работали на вас, а не наоборот? Прежде всего необходимо осознать, что управление данными — это важно. Далее нужно увидеть врага в лицо, то есть выделить и идентифицировать определенное, ключевое для компании подмножество общекорпоративных данных, от качества которых зависит большинство бизнес­процессов и систем в компании. Обычно эти данные занимают 15­25% от всех данных в компании. Есть общепринятое (в России и за рубежом) название для важнейших данных компании — основные данные. Термин «основные» происходит от англоязычного термина Master Data, или мастер­данные. Мастер­данные в первую очередь представлены справочниками, каталогами, классификаторами, или, проще говоря, нормативно­справочной информацией (НСИ). Мастер­данные (основные данные), как правило, включают в свой состав НСИ.

Отсутствие единого приложения для централизованного управления данными ведет 
к появлению проблем и дополнительных затрат для компании

Отсутствие единого приложения для централизованного управления данными ведет к появлению проблем и дополнительных затрат для компании

Разнообразие использования основных данных и специфические функции по работе с ними позволяют употребить следующее сравнение: «Основные данные — это “язык” бизнеса современной компании». Почему именно так и почему роль мастер­данных столь важна? Во­первых, от качества основных данных зависит и качество бизнес­процессов компании. Если компания ранее специально не задавалась целью построения продуманной стратегии по управлению основными данными, то чаще всего обнаруживаются дублирующиеся справочники и другие массивы данных, изолированно живущие своей жизнью в нескольких информационных системах одновременно. Логические сущности, или домены данных, при этом, как правило, совпадают. На практике это могут быть справочники и классификаторы продуктов, услуг, материально­технических ресурсов, клиентов, поставщиков и др. Управление этими справочниками, в особенности синхронизация данных между ними, как правило, бессистемна и неавтоматизирована. Если данные были изменены в одном из справочников в одной из систем, в ряде случаев необходимо об этом известить другие подразделения и, возможно, администраторов других систем. Чаще всего в этом случае сами сотрудники выгружают что­то в форматы табличных редакторов (MS Excel) и другие форматы, что­то передают между подразделениями, импортируют, пишут письма, звонят друг другу по телефону и таким образом согласовывают данные.

То есть на деле просто­напросто не существует продуманной и автоматизированной системы управления данными и изменениями в них, контроля — что, каким именно образом и кто порождает, изменяет или удаляет в той или иной информационной системе. Безусловно, общепринятые нормы обеспечения информационной безопасности, такие как имена пользователей и пароли, регламентируют доступ сотрудников к системам, однако этого недостаточно, поскольку отсутствует некий единый «надсистемный» механизм контроля за управлением данными и качество данных со временем, будучи, казалось бы, в норме в отдельно взятой системе, на общекорпоративном уровне начинает деградировать. Не стоит списывать со счетов и так называемый человеческий фактор: сотрудники могут случайно или умышленно вносить неточности в данные. В результате руководство получает неправдоподобные отчеты, аналитические выводы из разных систем и подразделений разнятся, на одни и те же вопросы руководства разные подразделения дают различные ответы и никто не в состоянии разобраться или взять на себя ответственность за причины возникающих отклонений или неточностей. Простейший пример: складская позиция, которая должна закупаться централизованно и иметь единый код и/или наименование в рамках всего предприятия, имеет различную кодировку и наименования в разных системах. Следовательно, складские запасы, вероятнее всего, неоптимальны, поэтому закупщики не смогут корректно идентифицировать потребность, а значит, невозможно будет закупить данную позицию одной большой партией и получить скидки у поставщиков. Становится сложно управлять складскими остатками, сборочные конвейеры могут простаивать часами и даже неделями, потому что данный компонент или запчасть хранится на соседней полке в достаточном количестве, но кодируется или называется по­другому, а значит, никто не знает о ее пригодности для использования на сборочной линии.

Специфика основных данных состоит в том, что они должны быть едины для множества информационных систем в компании и, как правило, использоваться в сквозных бизнес­процессах компании, охватывающих несколько систем, модулей или приложений. Таким образом, представление основных данных выходит за рамки одной системы (PLM или ERP) и представляет собой обобщенное типовое или эталонное, представление объекта (продукта, услуги, позиции) в корпоративной информационной системе в целом. Поэтому мастер­данные могут эффективно использоваться в различных подразделениях, системах и процессах компании, обеспечивая целостность для бизнеса и систем. Следует обратить внимание на передовой международный опыт и рынок, где довольно давно (уже около 8­10 лет назад) начали появляться специальные системы и решения для эффективного управления основными данными. Те области данных (или «домены» данных), по которым необходимо управлять централизованно, также насчитывают очень разнообразный перечень: продукты, услуги, клиенты, поставщики, другие контрагенты, географические расположения и др. В контексте отрасли и бизнеса конкретной компании может быть более или менее актуально управление основными данными в определенных «доменах».

В начало В начало

Машиностроение и управление основными данными

Для производственной компании, такой как машиностроительный холдинг, несомненно, наиболее важным является управление основными данными по продуктам.

Для преодоления вышеописанных недостатков управления данными были изобретены специализированные системы для управления мастер­данными — MDM­системы.

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

Корпоративная информационная архитектура с MDM-подсистемой

Корпоративная информационная архитектура с MDM-подсистемой

Какую роль выполняет MDM в корпоративной архитектуре современного машиностроительного предприятия? В чем отличие MDM­решения от PLM­ и PDM­систем? Почему системы автоматизированного проектирования не пересекаются, а, напротив, взаимно дополняют MDM­систему, создавая вместе законченную и всестороннюю информационную архитектуру в компании?

Рассмотрим эти вопросы подробнее. Концепция и технология PLM (Product Lifecycle Management) предполагает всестороннее управление продуктом (изделием) на всех этапах его жизненного цикла, начиная от проектирования и разработки и вплоть до состояния готовой продукции. Специфика PLM­систем предполагает необходимость отслеживания конфигураций продуктов, их версий, ведения массивной конструкторской документации, средств для обеспечения совместной работы с продуктом для групп инженеров и проектировщиков и другие необходимые функции. Примером основных данных для PLM­ или PDM­систем могут служить перечни проектируемых изделий, технические спецификации и атрибуты, справочники единиц измерения и др. Но если взглянуть на структуру основных данных производственного предприятия в целом, то становится отчетливо видно, что PLM­ и PDM­системы — это всего лишь одни из информационных систем. Да, несомненно, это одни из ключевых систем, но есть и другие системы, с которыми необходимо увязать основные данные и процессы, в которых используются эти данные: ERP, CRM и др. Поэтому ведение основных данных в рамках только PLM­системы не может претендовать на роль общекорпоративного MDM центра данных, поскольку решает локальные задачи управления данными только для целей инженерного проектирования и производства. Возьмем для примера продукт — газотурбинный двигатель. Данный тип двигателя представляет собой сложнейший механизм, состоящий из большого количества различных узлов и деталей. На этапе проектирования двигателя иногда необходимо создать буквально тонны документации. При этом количество версий и структура вложенности структур данных по компонентам и спецификациям двигателя может насчитывать сотни и даже тысячи позиций. Но вот двигатель запущен в промышленное производство. Теперь уже не только отделы инженерного проектирования и производство работают с данным продуктом. Отделам продаж, маркетинга, бэк­офису, сервисному обслуживанию компании нужны данные по продукту. Но это уже несколько иные данные по сравнению с теми, что были необходимы на этапе проектирования. Теперь двигатель — это готовая продукция, товар. Необходимо наладить его эффективное продвижение на рынок, сбыт, маркетинг, обслуживание. При этом отделы сбыта или маркетинга не интересует, какое количество версий имел агрегат при проектировании или тестировании, сотрудникам этих подразделений будут интересны варианты комплектации, ценообразование и другие вопросы, которые ближе к коммерческой стороне бизнеса. Отдел сервисного обслуживания интересуют данные по запчастям и оборудованию: какие компоненты можно закупить у внешних поставщиков, какие узлы уникальны и незаменимы (производятся только данным предприятием).

PLM- и PIM-системы — взаимодополняющие компоненты

PLM- и PIM-системы — взаимодополняющие компоненты информационной архитектуры предприятия

Наконец, в бэк­офисных системах учитываются финансовые данные, продукт обрастает финансовыми транзакциями: закупки, продажи, сделки, договора, контракты. В этих системах двигатель также присутствует в качестве продукта, но здесь его представление в корне отличается от представления в PDM­ или САПР­системах.

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

Руководство компании использует аналитические системы поддержки принятия решений для управления компанией, где также основные данные по продуктам должны служить основой для аналитических исследований и принятия управленческих решений.

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

В начало В начало

Ответ рынка на возникающие задачи

Специализированные решения для управления основными данными выделились в самостоятельный сегмент на международном рынке сравнительно недавно (около 7­9 лет тому назад). Неудивительно, что ведущие на международном рынке компании — производители систем класса управления ресурсами предприятия (ERP), такие как корпорация Oracle, одними из первых осознали необходимость в решениях для управления основными данными. ERP­система редко когда является единственной системой на предприятии, что приводит к появлению множества в той или иной степени изолированных друг от друга информационных silo (с легкой руки западных аналитиков по аналогии с силосными башнями так стали называть независимые друг от друга приложения и системы, управляющие собственными источниками данных). Исходя из индивидуальных потребностей предприятия, можно предполагать наличие того или иного варианта задачи по управлению основными данными. В ряде случаев предприятию нужно интегрировать данные из ERP­системы и ряда так называемых Best­of­Breed (то есть лучших в своем классе) систем. Иногда это задача интеграции «самописных» систем и стандартных готовых решений. В ряде случаев проблема управления основными данными возникает в результате слияний и поглощений компаний. Поэтому все крупнейшие поставщики ERP­систем имеют в составе своих предложений специальные компоненты для управления основными данными.

  • Oracle, являясь лидирующим на глобальном рынке производителем программного обеспечения для автоматизации предприятий, уделяет большое внимание развитию технологии MDM. В линейке решений для управления основными данными корпорации Oracle есть целый набор продуктов, охватывающий практически все наиболее часто встречающиеся задачи по управлению данными:
  • Oracle Customer Hub — решение предназначено для создания и поддержания единого MDM­источника уникальных, полных, качественных и достоверных данных по клиентам и другим контрагентам в рамках всей инфрастуктуры предприятия, а также отвечает за распространение этой информации всем системам — подписчикам в организации.
    Лицензия на решение Customer Hub позволяет использовать следующие продукты: Oracle Siebel Universal Customer Master и Oracle Customer Data Hub;
  • Oracle Site Hub — обеспечивает комплексный репозитарий для всей связанной с сайтами информации на протяжении всего их жизненного цикла. Site (Сайт) — объект на карте, имеющий географическую привязку и наделенный определенным атрибутивным составом. В качестве сайтов могут выступать: объекты недвижимости, офисы, здания и сооружения, складские, торговые, иные помещения, площади и т.п. Технологически Site Hub использует возможности веб­сервисов и интеграцию с комплексом для автоматизации бизнеса Oracle E­Business Suite для построения целостного концентратора (хаба данных) для данных по сайтам;
  • Oracle Hyperion Data Relationship Management — MDM­приложение, входящее в состав системы Oracle Hyperion. Обеспечивает эффективные механизмы управления финансово­аналитическими данными. Корневой объект — иерархия (план счетов, справочник центров затрат, оргструктура и т.п.);
  • Oracle Supplier Hub — обеспечивает создание и управление целостными данными по поставщикам в рамках самостоятельного MDM­приложения. Гибкая модель данных с возможностью неограниченного расширения атрибутивного состава объектов, средства интеллектуальной синхронизации данных между системами и приложениями и другие возможности;

Product Data Quality Cleansing and Matching Server (PDQMS) — решение представляет собой специализированный сервер для управления качеством данных по продуктам. Оно построено на основе лидирующей на рынке технологии семантического распознавания данных DataLens. Возможности данной технологии позволяют заменить ручной труд и автоматизировать выполнение таких задач, как стандартизация, согласование и выверка, дополнение и обогащение, а также корректировка разнородных данных по продуктам (позициям, товарам, услугам) из различных систем, приложений и источников. Технология DataLens Technology использует запатентованную семантическую технологию интеллектуального распознавания больших массивов продуктовых данных, отличающихся большой вариабельностью (разнообразием);

MDM-решение Oracle PIM для управления основными данными по продуктам

MDM-решение Oracle PIM для управления основными данными по продуктам

Oracle Product Information Management Data Hub (Oracle PIM) — решение класса Master Data Management (специализированное решение для управления основными данными, НСИ). Позволяет создать единый централизованный источник точных, чистых, консолидированных данных на корпоративном уровне. Обеспечивает синхронизацию данных между системами и приложениями. Содержит гибкую модель данных, готовый пользовательский интерфейс для бизнес­пользователей и администраторов данных. Поддерживает ключевые бизнес­процессы по управлению данными, соответствующие лучшим мировым практикам.

Последнее решение, Oracle PIM, безусловно, представляет наибольший интерес для машиностроительных предприятий, поскольку предназначено для управления данными по продуктам. Oracle PIM ориентирован на обеспечение наиблее современного и высокотехнологичного подхода к управлению основными данными — возможности сбора записей из различных систем в единое централизованное приложение, поэтому может быть причислен к MDM­приложению по интеграционному типу. Также приложение может хранить и отслеживать ссылки и идентификаторы записей данных в различных системах (MDM по федеративному типу). Это означает, что при необходимости MDM­приложение может быть использовано для обеспечения взаимной согласованности данных в неограниченном количестве систем и приложений. Именно MDM­приложение способно отслеживать перекрестную ссылочность данных во множестве различных информационных системами одновременно. Поэтому с точки зрения бизнеса MDM­решение Oracle PIM обеспечивает целостность и упорядоченность данных во всей компании (холдинге) на корпоративном уровне.

Выступая в роли платформенно­независимого централизованного хранилища (и источника) основных данных, приложение Oracle PIM позволяет собирать основные данные из ERP, PLM, PDM, CRM и других систем и приложений. При помощи специализированной функциональности MDM­решения по обработке данных производятся следующие операции: стандартизация и классификация данных, распределение их в справочниках и каталогах, выверка и устранение дубликатов в записях, описание технических и прочих спецификаций (дополнение и обогащение атрибутивного состава), устанавливается необходимая полнота перекрестной ссылочности между записями и объектами в данных и внешними системами (системами­источниками и системами­получателями данных) и другие функции. В результате предприятие получает единое и комплексное представление всех наиболее критически значимых данных в рамках единой централизованной MDM­системы, независимой от других приложений и налагающей единые правила и порядок по управлению данными в рамках всего предприятия (холдинга). Приложение Oracle PIM имеет готовый стандартный пользовательский интерфейс как для пользователей, так и для администраторов данных. На практике это означает, что MDM­приложение теперь может взять на себя если не все, то гораздо большую часть функций по управлению данными в любом внешнем по отношению к нему приложении или информационной системе. Новые записи, описывающие номенклатурно­складские позиции и продукты, теперь могут вводиться через единое централизованное приложение — Oracle PIM, после чего система практически самостоятельно и интеллектуально (согласно настроенным правилам и политикам синхронизации, при минимально необходимой ручной интервенции со стороны пользователей и администраторов) производит распространение данных в нужном объеме и порядке между системами — получателями данных. Конечно, всё происходит под контролем администраторов данных, которые в любой момент могут вмешаться в процесс: приостановить, перенастроить логику синхронизации, взять или перевести часть задач и/или функций системы в «ручной» пользовательский режим. Одна и та же система в определенных сценариях может выступать в роли как источника, так и получателя данных.

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

Особенно очевидны преимущества MDM­подхода, когда речь идет о подходе на основе SOA (севисно­ориентированных архитектур). Сервисно­ориентированный подход предполагает, что сквозные бизнес­процессы на основе веб­сервисов передают данные между системами и приложениями в рамках определенной бизнес­логики. Для обеспечения SOA­процессов необходим централизованный источник основных данных, в противном случае SOA­проекты рискуют обернуться убытками.

Современная архитектура корпоративной информационной системы производственного предприятия с использованием MDM для управления основными данными

Современная архитектура корпоративной информационной системы производственного предприятия с использованием MDM для управления основными данными

Приложение Oracle PIM поддерживает и более традиционные интеграционные средства и механизмы, такие как открытые API, обмен данными через интерфейсные таблицы базы данных, через плоские файлы и др. Это гарантирует возможность подсоединения к любой, даже самой архаичной или устаревшей системе или приложению с целью импорта и синхронизации данных.

При использовании интеграционного стека Oracle Fusion Middleware и новой интеграционной архитектуры приложений Oracle AIA становится возможным перевести даже самые трудоемкие интеграционные задачи на рельсы упорядоченного современного подхода, гарантирующего оптимальность затрат на интеграцию, и учесть стратегические потребности расширения информационной архитектуры компании на будущее.

В начало В начало

В будущее — с оптимизмом

Создав единый источник достоверных данных, машиностроительное предприятие создает
серьезный задел конкурентного преимущества в долгосрочной перспективе. Действительно, если компания внедрила SOA, то подключение новой системы или приложения в общую информационную архитектуру превращается в штатную задачу для ИТ­подразделения и обходится на порядок дешевле и экономичнее, чем отдельный интеграционный проект. Однако если предприятие реализует сервисно­ориентированный подход, но при этом не заботится о качестве данных, то эти инвестиции могут оказаться неоправданными. Только разумная и продуманная стратегия, заключающаяся в построении единого MDM­источника точных данных в совокупности с SOA­подходом, представляется оптимальным вариантом, гарантирующим успешную стратегическую перспективу.

Однако реализация комплексного проекта — развертывание MDM центра данных и интеграция множества систем на основе SOA — может в ряде случаев представляться слишком дорогостоящей и/или трудоемкой задачей. В этом случае может быть рекомендован поэтапный подход, который в любом случае будет более стратегически выгодным, чем жизнь по­старому. Предприятие может развернуть MDM­решение и связать на его основе две­три наиболее критически значимые информационные системы, например ERP и CRM. Сделать это можно при помощи простейших интеграционных компонентов класса ETL (Extract, Transformation and Load), а в качестве формата обмена данными выбрать, например, XML или плоские файлы. Если вы сторонник минимализма (самый экономичный вариант) — сделайте пилотный проект с интеграцией по принципу «точка­точка». Когда руководство предприятия в полной мере убедится в преимуществах заключенных в едином MDM­источнике основных данных на корпоративном уровне, можно смело переходить ко второй фазе проекта, то есть переводу интеграционной архитектуры предприятия на сервисно­ориентированный подход. SOA­подход является наиболее перспективным и рекомендуется ведущими мировыми аналитиками (Gartner, Forrester, IDC и др.). Ведущие вендоры ERP­систем имеют, как правило, в своем портфеле решений как прикладное программное обеспечение, необходимое для построения MDM­системы, так и необходимые интеграционные компоненты, самые современные из которых представлены программным обеспечением промежуточного слоя и поддерживают сервисно­ориентированные архитектуру и подход.

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

В начало В начало

САПР и графика 7`2010