Нормативно-справочная информация производственных предприятий. Ее состав и основные элементы НСИ

Условно-постоянная часть данных которая должна присутствовать в любой ERP системе. Это справочники и классификаторы. Некоторая часть данных которая хранится в системе. Эти данные относительно медленно меняются.

При рассмотрении структуры НСИ принято выделять следующие основные группы справочников.

1. Снабжение (материально-товарное обеспечение): справочник-классификатор ТМЦ (МТР, материалов), справочник контрагентов (поставщиков, производителей).

2. Сбыт: сбытовая номенклатура, тарифы на услуги, справочник клиентов (потребителей), справочники, используемые при подготовке договоров.

3. Финансы, бухгалтерия: справочники и классификаторы, используемые для учета активов и основных средств, бюджетирования, учета и контроля финансовых потоков, бухгалтерского и налогового учета; план счетов.

4. Производство, ТОРО: справочники технических объектов и оборудования, комплектующих изделий, запчастей, агрегатов и узлов, технологические карты и др.

5. Сервисы: справочник-классификатор услуг и работ, тарификаторы.

6. Оргструктура: справочники, описывающие оргструктуру компании, реквизиты подразделений, профили деятельности, взаимоотношения, подчиненность и т. п.

7. Кадры (трудовые ресурсы): нормативно-справочная информация, связанная с трудовыми ресурсами (управление персоналом, зарплата, социальные программы, обеспечение спецодеждой и т. д.).

Рассматривая проблему НСИ в контексте автоматизации бизнеса, важно понять, что вопреки распростаненному заблуждению НСИ не является частью ERP-системы: система НСИ предоставляет необходимый сервис всем бизнес- приложениям. А коль скоро это так, то известная концепция сервисно-ориентированной архитектуры оказывается очень плодотворной, когда речь идет о технологиях доступа к НСИ как со стороны различных бизнес-систем, так и состороны их пользователей.

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

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

· доступ и многофункциональный поиск основных (мастер-) данных;

· запросы в службу ведения НСИ на изменение/добавление данных;

· запросы в службу ведения НСИ на установление ссылок или переходных ключей;

· функции ведения данных НСИ (корректировки и добавления), доступные экспертам — специалистам службы НСИ;

· доставка (репликация) данных НСИ в прикладные системы — потребители мастер-данных по запросу или по событию.

Подчеркнем также: взаимоотношения между ЕС НСИ и локальной системой разумно устанавливать именно по модели предоставления услуг, а это еще раз свидетельствует о том, что НСИ не является частью ERP-системы. При этом важно, что реализация данного механизма предоставления информационных сервисов со стороны НСИ никак не может носить частного, локального характера. В каждой компании необходимо обеспечить использование всеми её службами и подразделениями единой унифицированной системы НСИ, оптимизированной с учетом реальных требований бизнес-процессов.

Требования и принципы построения

Единой системы НСИ

С целью обеспечения использования всеми службами и подразделениями компании унифицированной системы НСИ следует учесть четыре группы требований.

• Методологические — к разработке и внедрению эффективной методологии ведения справочников и классификаторов в рамках единой системы НСИ, к поддержанию данных в актуальном состоянии, обеспечению полноты, устранению ошибок, контролю целостности и непротиворечивости данных.

• Организационные — к единому регламенту использования справочников системы НСИ всеми службами и подразделениями компании и его сопровождения на основе уточненных требований к составу и структуре информации в справочниках.

• Информационные — к составу и структуре информации в системе НСИ, а также к технологии ее ведения (вычистке, пополнению, корректировке).

• Технические — к среде доступа пользователей к НСИ и работы экспертов службы ведения НСИ, к требуемому набору функций и информационных возможностей.

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

Это идентифицируемость и уникальность, которые обеспечивают однозначную и уникальную идентификацию данных, что необходимо для установления ссылок на них из других элементов НСИ и прикладных документов. Унификация позволяет применять единообразные правила написания/описания элементов НСИ, например, наименования материалов в справочнике ТМЦ, пользоваться унифицированным справочником единиц измерения (а не текстовыми полями в том же справочнике ТМЦ), использовать наименования контрагентов в соответствующем справочнике и т. п.

Целесообразно также выделить принципы построения единой системы НСИ.

• Корпоративность предусматривает необходимость использования ЕС НСИ в масштабе всей компании, ее структурных подразделений и предприятий.

• Многоцелевое использование — система НСИ должна удовлетворять информационные потребности каждой функциональной группы пользователей, представляя ей индивидуально ориентированные срезы данных.

• Полнофункциональность — ЕС НСИ должна компенсировать те или иные функциональные недостатки ERP- и других имеющихся в компании прикладных систем, связанные с поиском, обработкой и использованием НСИ.

• Централизация функций хранения эталонного массива данных НСИ, ведения, создания новых и внесения изменений в существующие эталонные данные.

• Адаптивность и масштабируемость системы по мере возникновения новых требований к составу и структуре данных НСИ с учётом организационных изменений в компании, изменений программно-технического ландшафта, увеличения нагрузки на информационную систему и числа пользователей.

• Интегрируемость ЕС НСИ с существующими ERP- и другими корпоративными информационными системами.

• Стандартизация и унификация форматов данных НСИ, способов их формирования и изменения на основе корпоративных организационно-распорядительных документов.

• Преемственность — при первичном наполнении системы НСИ за основу берутся используемые в компании справочники и классификаторы, которые после консолидации и нормализации становятся её частью. Вновь создаваемые «эталонные» данные постепенно замещают старые.

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

15. Основные прикладные компоненты современных КИС (SCADA, MES, ERP,…). Краткая характеристика каждой компоненты.

Из Википедии

SCADA (аббр. от англ. Supervisory Control And Data Acquisition, Диспетчерское управление и сбор данных) — программный пакет, предназначенный для разработки или обеспечения работы в реальном времени систем сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления. SCADA может являться частью АСУ ТП(Автоматизированная система управления технологическим), АСКУЭ (Автоматизированная Система Коммерческого Учёта Электроэнергии), системы экологического мониторинга, научного эксперимента, автоматизации здания и т. д. SCADA-системы используются во всех отраслях хозяйства, где требуется обеспечивать операторский контроль за технологическими процессами в реальном времени. Данное программное обеспечение устанавливается на компьютеры и, для связи с объектом, использует драйверы ввода-вывода или OPC/DDE серверы. Программный код может быть как написан на языке программирования (например на C++), так и сгенерирован в среде проектирования.

SCADA-системы решают следующие задачи:

· Обмен данными с УСО (устройства связи с объектом, то есть с промышленными контроллерами и платами ввода/вывода) в реальном времени через драйверы.

· Обработка информации в реальном времени.

· Логическое управление.

· Отображение информации на экране монитора в удобной и понятной для человека форме.

· Ведение базы данных реального времени с технологической информацией.

· Аварийная сигнализация и управление тревожными сообщениями.

· Подготовка и генерирование отчетов о ходе технологического процесса.

· Осуществление сетевого взаимодействия между SCADA ПК.

· Обеспечение связи с внешними приложениями (СУБД, электронные таблицы, текстовые процессоры и т. д.). В системе управления предприятием такими приложениями чаще всего являются приложения, относимые к уровню MES.

SCADA-системы позволяют разрабатывать АСУ ТП в клиент-серверной или в распределенной архитектуре.

MES (от англ. Manufacturing Execution System, производственная исполнительная система) — специализированное прикладное программное обеспечение, предназначенное для решения задач синхронизации, координации, анализа и оптимизации выпуска продукции в рамках какого-либо производства. С 2004 года термин расшифровывается как англ. Manufacturing Enterprise Solutions — корпоративные системы управления производством[источник не указан 360 дней].

MES-системы относятся к классу систем управления уровня цеха.

· Положения работы MES- включают в себя:

· Активация производственных мощностей на основе детального пооперационного планирования производства

· Отслеживание производственных мощностей

· Сбор информации, связанной с производством от

· Систем автоматизации производственного процесса

· Датчиков

· Оборудования

· Персонала

· Программных систем

· Отслеживание и контроль параметров качества

· Обеспечение персонала и оборудования информацией, необходимой для начала процесса производства

· Установление связей между персоналом и оборудованием в рамках производства

· Установление связей между производством и поставщиками, потребителями, инженерным отделом, отделом продаж и менеджментом

· Реагирование на

o Требования по номенклатуре производства

o Изменение компонентов, сырья и полуфабрикатов, применяемых в процессе производства

o Изменение спецификации продуктов

o Доступность персонала и производственных мощностей

· Гарантирование соответствия применимым юридическим актам, например нормам Food and Drug Administration (FDA) США

· Соответствие вышеперечисленным индустриальным стандартам.

Систе́ма подде́ржки приня́тия реше́ний (СППР) (англ. Decision Support System, DSS) — компьютерная автоматизированная система, целью которой является помощь людям, принимающим решение в сложных условиях для полного и объективного анализа предметной деятельности. СППР возникли в результате слияния управленческих информационных систем и систем управления базами данных.

Для анализа и выработок предложений в СППР используются разные методы. Это могут быть: информационный поиск, интеллектуальный анализ данных, поиск знаний в базах данных, рассуждение на основе прецедентов, имитационное моделирование, эволюционные вычисления и генетические алгоритмы, нейронные сети, ситуационный анализ, когнитивное моделирование и др. Некоторые из этих методов были разработаны в рамках искусственного интеллекта. Если в основе работы СППР лежат методы искусственного интеллекта, то говорят об интеллектуальной СППР, или ИСППР.

Близкие к СППР классы систем — это экспертные системы и автоматизированные системы управления.

16. Новые подходы к проектированию архитектуры информационных систем: сервис - ориентированная архитектура (SOA)

Из википедии

Се́рвис-ориенти́рованная архитекту́ра (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.

Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST).

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

Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать дополнительно механизм файловой системы для обмена данными.

Главное, что отличает SOA, это использование независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.

Элементы сервис-ориентированной архитектуры, по: Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall, 2005

SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабо-связанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.

Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.

Использование компонентной архитектуры (SCA) для реализации SOA — это область текущих исследований.

(Из Инета)

Сервис-ориентированная архитектура

Подготовлено: по материалам зарубежных сайтов

Перевод: Intersoft Lab

Сегодня наблюдается устойчивый рост интереса к концепции сервис-ориентированной архитектуры (service-oriented architecture, сокр. SOA). Свидетельство тому - оценки аналитических компаний и усилия крупных поставщиков программного обеспечения по продвижению этого подхода.

Значение SOA

По словам Клива Финкельштейна (Clive Finkelstein), автора инфотехники (information engineering), до появления концепции SOA при разработке систем в качестве отправного момента для программирования бизнес-логики использовались диаграммы рабочих потоков и блок-схемы систем. Разработанные вручную программы тщательно тестировались, после чего внедрялись. Сегодня ситуация изменилась коренным образом: современные инструменты управления бизнес-процессами позволяют обойтись без ручной разработки и тестировании. Так, с помощью методов моделирования можно проверять корректность исполнения бизнес-логики, представленной в диаграммах, а затем автоматически получать описания этих диаграмм на XML-языках управления бизнес-процессами.

По мнению Клива Финкельштейна, такая технология управления бизнес-процессами является большим шагом вперед с точки зрения повышения эффективности разработки систем; по значимости ее можно сравнить с созданием в конце 50-х годов компиляторов языка высокого уровня. Действительно, данный подход позволяет упростить вызов Web-сервисов из любого местоположения и их выполнение на основе бизнес-правил. Кроме того, при изменении этих правил, корректируется соответствующая логика в диаграммах: диаграммы автоматически генерируются заново. Таким образом, закладываются предпосылки для перехода от медленного ручного кодирования, используемого сейчас при создании систем, к автоматизированному. Благодаря этому компании смогут реализовывать изменение бизнес-правил за минуты или часы, а не за месяцы или годы.

Сервис-ориентированная архитектура: основные понятия

Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок, как это было, например, с концепцией федеративного Хранилища данных. Не миновала "сия чаша" и сервис-ориентированную архитектуру. Так, по крайне мере, считает представитель компании BEA Джерими Уэстерман (Jeremy Westerman). Именно поэтому в одной из своих статей, посвященных SOA, он специально останавливается на "проблемных местах" и приводит подробные пояснения:

SOA не является чем-то новым: IT-отделы компаний успешно создавали и развертывали приложения, поддерживающие сервис-ориентированную архитектуру, уже много лет - задолго до появления XML и Web-сервисов.

SOA - это не технология, а способ проектирования и организации информационной архитектуры и бизнес-функциональности.

Покупка самых новых продуктов, реализующих XML и Web-сервисы, не означает построения приложений в соответствии с принципами SOA.

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

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

Слова Джерими Уэстермана в определенной степени перекликаются с точкой зрения Клива Финкельштейна. "Родоначальник инфотехники" сетует, что до недавних пор термин "сервис-ориентированная архитектура" был синонимом "Web-сервис". Клив Финкельштейн определяет SOA следующим образом - вызов Web-сервисов с помощью средств и языков управления бизнес-процессами. Он считает, что SOA - это термин, который появился для описания исполняемых компонентов - таких как Web-сервисы - которые могут вызываться другими программами, выступающими в качестве клиентов или потребителей этих сервисов. Эти сервисы могут быть полностью современными - или даже устаревшими - прикладными программами, которые можно активизировать как черный ящик. От разработчика не требуется знать, как работает программа, необходимо лишь понимать, какие входные и выходные данных нужны, и как вызываются эти программы для исполнения.

В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 1). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.

Рис. 1. Общая схема SOA

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

Любой разговор о SOA невольно переходит на рассуждение о роли и месте Web-сервисов. Несмотря на то, что основные положения SOA сложились задолго до появления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA (см. рис. 1). Так, Джерими Уэстерман отмечает, что использование XML и Web-сервисов "поднимает SOA на более высокий уровень".

Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость.

Наконец, сегодня Web-сервисы рассматриваются как эффективный инструмент для интеграции, в том числе для взаимодействия процессов, выполняемых в различных компаниях. Особое место среди различных спецификаций, предназначенных для описания систем и приложений на уровне бизнес-процессов, занимает язык BPEL4WS (подробнее см. "Бизнес-процессы и XML").

Преимущества использования SOA

Прежде чем, перечислить преимущества использования SOA, будет уместным напомнить, что преимущества бывают разные: стратегические и тактические. SOA обладает рядом достоинств как стратегических, так и тактических.

· Стратегическая ценность SOA:

· Сокращение времени реализации проектов, или "времени выхода на рынок".

· Повышение производительности.

· Более быстрая и менее дорогая интеграция приложений и интеграция B2B - остановимся более подробно на данном пункте.

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

Тактические преимущества SOA:

· Более простые разработка и внедрение приложений.

· Использование текущих инвестиций.

· Уменьшение риска, связанного с внедрением проектов в области автоматизацией услуг и процессов.

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

· Сокращение числа обращений за технической поддержкой.

· Повышение показателя возврата инвестиций (ROI).

· Перспективы

Совершенно очевидно, что SOA "набирает обороты". По крайней мере, около года назад сотрудники Gartner уверенно заявили о том, что к 2008 году преобладающей практикой проектирования и разработки компьютерных программ станет сервис-ориентированная архитектура (с вероятностью 0,7). Таким образом, SOA положит конец господствовавшей последние 40 лет архитектуре монолитного программного обеспечения.

Аналитики компании ZapThink, специализирующейся на вопросах развития и применения сервис-ориентированно1 архитектуры, выяснили, что в 2004 году компании переходили от пилотных проектов к реальным внедрениям в рамках своих отделов. Так, целый ряд организаций из различных сегментов экономики, включая финансовые услуги, страхование, аэрокосмическую отрасль, здравоохранение, фармацевтику, розничную торговлю, государственный сектор и промышленность, "подняли" Web-сервисы до уровня SOA. В настоящий момент эти организации рассматривают возможность расширения рамок этих проектов - они собираются внедрить их не только на уровне различных отделов и подразделений, но и во всей компаний.

В ZapThink справедливо замечают, что до недавних пор реальную пользу - в денежном эквиваленте - от SOA в основном получали аналитики, журналисты и консультанты. Однако, сегодня появился рынок как для продуктов SOA, так и услуг по внедрению сервис-ориентированной архитектуры. Так, в ZapThink говорят об одной интересной тенденции - некоторым организациям, предоставляющим профессиональные услуги, удалось не только выйти на точку безубыточности, но заключить многомиллионные контракты. В этой связи аналитики полагают, что в 2005 году доходы таких организаций могут превысить - и даже весьма ощутимо - поступления всех поставщиков, предлагающих продукты, реализующие SOA.

Сотрудники ZapThink прогнозируют, что 2005 год станет "годом SOA". Причем количество перейдет в качество: увеличится число внедрений сервис-ориентированной архитектуры и, как следствие, развертывание SOA будет рассматриваться как стратегическая задача, а не как тактическое решение, рамки которого пока ограничиваются одним подразделением. Таким образом, SOA станет обязательным подходом для большинства крупных компаний, а не перспективным направлением для немногих дальновидных организаций.

17. Интеграционные платформы. Их структура и функциональность.

Интеграционная платформа – программно-аппаратная инфраструктура, позволяющая организовать обмен данными между распределёнными приложениями и информационными системами, для поддержки, мониторинга и управления композитными (составными) бизнес-процессами предприятия.

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

Продукты IBM WebSphere DataPower, IBM WebSphere Business Services Fabric, IBM WebSphere Message Broker, IBM WebSphere MQ, Sun Java CAPS, Oracle Service Bus, Microsoft BizTalk, SAP XI, SonicESB, OpenESB, ServiceMix и Mule ESB.