Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Оглавление

• Введение
• 1. Интегрируемые системы и подходы к их интеграции
• 1.1 Интеграция информационных систем
• 1.2 Методы передачи данных между ИС
• 1.2.1 Обмен плоскими файлами
• 1.2.2 Общая БД
• 1.2.3 Прямая связь систем
• 1.2.4 Централизованный брокер сообщений
• 1.2.5 Интеграционная шина
• 1.3 Анализ интегрируемых ИС
• 1.3.1 Информационная среда ПНППК
• 1.3.2 Система SAP R/3
• 1.3.3 Система «База производства ВОГ»
• 1.4 Сравнение методов интеграции ИС
• 1.5 Анализ аналогичных решений
• 1.5.1 SAP PI
• 1.5.2 Использование SAP .NET Connector
• 1.5.3 Сравнение аналогов
• 2. Интеграционное решение в бизнес-процессах ПНППК
• 2.1 Анализ бизнес-процесса планирования и управления производством
• 2.2 Анализ процесса исследования неисправных изделий
• 2.3 Место анализа КУН в процессе планирования и управления производством
• 3. Разработка интеграционного решения
• 3.1 Проектирование интеграционного решения
• 3.1.1 Структура данных в МУННС
• 3.1.2 Структура передаваемых данных
• 3.1.3 Проектирование функционала модуля
• 3.1.4 Архитектура интеграционного решения
• 3.2 Реализация интеграционного решения
• 3.2.1 API в «Базе производства ВОГ»
• 3.2.2 BAPI в SAP R/3
• 3.2.3 Разработка интеграционного модуля
• Заключение
• Основные обозначения и сокращения
• Библиографический список
• Приложения


Введение

информационный файл база connector

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

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

Для ПНППК решение данного вопроса достаточно актуально, так как в ее ERP-системе SAP R/3, которая охватывает большинство бизнес-процессов компании, отсутствует возможность учета неисправных изделий, а разработка полноценного модуля потребует достаточно много трудовых ресурсов. Также компания имеет стороннюю разработку - web-систему “База производства ВОГ”, которая имеет возможность вести учет карточек учета неисправностей (КУН).

Проблема заключается в отсутствие возможности учитывать неисправные изделия в системе SAP R/3 для планирования производства при имеющейся системе «База производства ВОГ» c возможностью их отслеживания.

Объектом исследования является система отслеживания и учета неисправных изделий, а предметом - способы интеграции систем “База производства ВОГ” и SAP R/3.

Целью работы является автоматизация учета неисправных изделий в системе SAP R/3 на основе карточек учета неисправностей в системе “База производства ВОГ” для планирования производства предприятия.

Задачи:

1) проанализировать проблему интеграции корпоративных систем;

2) исследовать возможные методы интеграции систем и выбрать один из них;

3) определить места применения информации о неисправных изделиях в процессах планирования и управления производством;

4) спроектировать и разработать интеграционное решение.

Для выбора подхода к интеграции систем будет использован такой метод исследования, как сравнительный анализ: будут изучены сильные и слабые стороны каждого из подходов. Для рассмотрения интеграции на уровне бизнес-процессов будет использован анализ таких документов, как пособие по планированию и управлению производством в SAP R/3 [5] и стандарт предприятия о “Технологии исследования изделий, отказавших у потребителя и в процессе производства” [2]. На основании результатов анализа будет проведено моделирования процессов планирования производства и исследования неисправных изделий в нотации ARIS. Для определения набора передаваемых в SAP R/3 данных будут проведены интервью с непосредственными пользователями.

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



1. Интегрируемые системы и подходы к их интеграции

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

1.1 Интеграция информационных систем

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

? функциональность отдельных ИС является более выигрышной из-за заданной прикладной области;

? стоимость внедрения отдельных систем намного дешевле;

? отсутствие карты решений службы ИТ.

Если не предпринимать шаги к интеграции этих систем, то они начинают работать изолированно и хранить в себе отдельные и несопоставимые данные.

Системы управления предприятием, призванные решить данную проблему, часто также требуют интеграции с какой-либо другой системой. А.А. Кусов в своей работе [10] проанализировал, почему с современными системами управления, например, ERP, все равно присутствует необходимость иметь на предприятии несколько ИС и интегрировать их. По его мнению, данная проблема исходит и от самих поставщиков корпоративных программных продуктов: “Они утверждают, что продукты класса ERP (ERP II, CSRP и BPM) «автоматически» снимают проблему интеграции”. Действительно, считается, что системы данного класса призваны автоматизировать практически все бизнес-процессы и что приложения системы уже интегрированы между собой, так как они от одного поставщика.

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

В зависимости от того, какие методы связи использованы, выделяют уровни интеграции, перечисленные ниже.

1. Уровень брокеров - автоматическая передача данных и запуск исполняемого кода на выполнение. Для конечного пользователя интегрированные компоненты представляют единую систему.

2. Уровень данных - использование единой или нескольких объединенных БД. Для конечного пользователя данные будут выглядеть целостными.

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

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

Также выделяют три степени интеграции систем в зависимости от количества операций, выполняемых человеком: ручная, автоматизированная и автоматическая. Зависимость степени интеграции от использованного метода можно наблюдать в таблице 1.1, составленной [14].



Таблица 1.1. Зависимость степени интеграции от метода связи

Метод создания связи	Степень автоматизации
	Ручная	Автоматизированная	Автоматическая
Уровень брокеров	Отсутствует	Допускается	Предпочтительная
Уровень данных	Допускается	Допускается	Предпочтительная
Уровень сервисов	Допускается	Предпочтительная	Допускается
Уровень интерпретирования метаинформации	Допускается	Допускается	Предпочтительная

1.2 Методы передачи данных между ИС

На основании работ В.В. Абрамова [3] и А.А. Кусова [10] были выбраны следующие методы интеграции ИС разных уровней для дальнейшего анализа:

1) обмен плоскими файлами;

2) общая база данных;

3) прямая связь систем;

4) централизованный брокер сообщений;

5) интеграционная шина.

1.2.1 Обмен плоскими файлами

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



Рисунок 1.1. Схема обмена плоскими файлами

Самым распространенным форматом данных для данного метода является XML по причине его поддержки многими производителями программного обеспечения: Microsoft, Oracle, SUN и т.д. Но зачастую для сложных структур данных на сегодняшний день используют JSON, в силу его удобочитабельности и лаконичности при меньшем объеме файла, чем у XML.

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

1.2.2 Общая БД

Метод подразумевает создание объединенного хранилища однородных данных, независимого от бизнес-логики приложений (рисунок 1.2). Сегодня данный способ очень популярен, но имеет множество недостатков, самый очевидный из которых это разнородность информации из большого количества систем.

Рисунок 1.2. Схема общей БД

Преимуществом данного подхода является, разумеется, полная актуальность данных, практически в реальном времени. Основным же недостатком является то, что метод сложно реализуем, если уже существуют системы со своими БД. Мало того, что для реализации потребуется объединить неоднородные данные из разных БД, так и требования к новой БД будут очень высоки. Например, многие системы работают только с БД определенного разработчика: MS SQL, Oracle и т.д.

1.2.3 Прямая связь систем

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

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

1.2.4 Централизованный брокер сообщений

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

Рисунок 1.3. Схема использования централизованного брокера



1.2.5 Интеграционная шина

Метод подразумевает передачу сообщений через интеграционную шину, которая берет на себя задачу адаптации и преобразования данных (рисунок 1.4). При данном подходе, доработки в существующих системах сводятся к минимуму.

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

Рисунок 1.4. Схема интеграционной шины

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

1.3 Анализ интегрируемых ИС

1.3.1 Информационная среда ПНППК

ПАО «Пермская Научно-производственная Приборостроительная Компания» (ПНППК) имеет многолетний опыт разработки и производства навигационных систем различного назначения и товаров народного потребления. Важнейшими направлениями ее деятельности являются: авиационное приборостроение, разработка и изготовление изделий морской и наземной техники.

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

Современные информационные технологии в настоящее время обеспечивают управление всеми основными и поддерживающими процессами и основаны на современных программных продуктах ARIS, SAP R/3, Pro/Engineer и прочие.

В ПНППК до 2000 года существовала «лоскутная автоматизация», то есть различные бизнес-процессы были автоматизированы в рамках различных программных средств, слабо или средне интегрированных между собой, и функционировали достаточно автономно друг от друга.

Начиная с 2000 года, Компания ориентирована на разработку и внедрение корпоративных информационных систем, интегрированных между собой.

На сегодняшний день базовыми являются системы:

- ARIS - система бизнес-моделирования, разработчик IDS-Scheer;

- SAP R/3 - ERP-система, разработчик компания SAP;

- Proingener - CAD\CAM\CAE - система автоматизированного проектирования;

- Search - система электронного конструкторско-технологического документооборота Компании;

- LanDocs - система электронного организационно-распорядительного документооборота Компании, разработчик ЗАО «Ланит», г.Москва.

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

1.3.2 Система SAP R/3

SAP R/3 - это система класса ERP, разработанная компанией SAP SE.

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

SAP R/3 состоит из ядра и прикладных модулей (рисунок 1.5), отвечающих за различные бизнес-процессы компании (например, FI - финансы, PP - планирование производством и т.д.) и интегрирующих их в реальном времени. Система предназначена для полной автоматизации крупных и средних компаний и, по оценке экспертов в области информационных технологий, является ведущей на рынке ERP-систем [20].

Рисунок 1.5. Структура SAP R/3

SAP R/3 способен настраиваться под определенные нужды компании. Система содержит внутренний язык программирования (ABAP) и средства разработки и отладки -- то есть, при желании, в рамках системы можно разработать собственный функционал или существенно расширить существующий и компания в последствии сможет работать практически с индивидуальной версией системы, что увеличивает ее продуктивность.

Система имеет трехуровневую архитектуру (цифра 3 из названия R/3), состоящую из презентационного уровня, уровня приложений и уровня данных (рисунок 1.6).

Презентационный уровень отвечает за диалог с пользователем, ввод и вывод данных. Основан на последовательности окон, отражающих выполняемый пользователем процесс (SAP GUI, Graphical User Interface). Может запускаться с персонального компьютера пользователя.

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

Рисунок 1.6. Архитектура SAP R/3

Уровень данных состоит из СУБД, где хранятся все данные системы.

SAP R/3 изначально позиционировала себя как система, имеющая высокие интеграционные способности. Так в системе реализована технология RFC (Remote Function Call), проприетарный интерфейс SAP, который позволяет удалено вызывать функции R/3 через функциональные модули BAPI (Business Application Programming Interface). Коммуникация R/3 может происходить с другой как SAP-системой, так и не-SAP-системой. Основан RFC на TCP/IP.

1.3.3 Система «База производства ВОГ»

«База производства ВОГ (волоконно-оптических гироскопов) - это веб-система, разработанная компанией «Восходящие технологии» для кластера ВОГ ПНППК в 2014 году.

За последние два года «База производства ВОГ» стала основным инструментом хранения, обработки и анализа информации кластера ВОГ. В базу попадают данные со станков, пультов приемо-сдаточных испытание, операторов и технологов. На выходе технологи, инженеры и руководство ПНППК получают отчётность и аналитику, паспорта изделий, контроль процессов.

«База производства ВОГ» разработана на ASP.NET MVC, и она поддерживает технологию REST API (Representational State Transfer) в основном для выгрузки данных в формате JSON (JavaScript Object Notation).

REST является альтернативой SOAP (Simple Object Access Protocol), учитывая тот факт, что он является архитектурным стилем, а не протоколом или стандартом, в отличие от SOAP. Основным преимуществом REST перед SOAP это его простота как в структуре, так и в реализации. Стиль REST заключается в соблюдении следующих принципов:

1) каждый объект имеет идентификатор;

2) объекты ссылаются друг на друга;

3) используются стандартные методы http;

4) возвращаемые данные могут иметь различные форматы.

Благодаря последнему принципу API «Базы производства ВОГ» передают данные в формате JSON, а не в популярном XML.

JSON - это простой формат обмена данными, основанный на подмножестве языка программирования JavaScript [19]. В отличие от XML, он легко читаем не только компьютером, но и человеком, что облегчает ручную обработку данных. JSON - текстовый формат, независимый от языка программирования, но он использует соглашения, знакомые программистам C-подобных языков, таких как C, C++, C#, Java, JavaScript, Perl, Python и многих других.



1.4 Сравнение методов интеграции ИС

Рассмотрев особенности подходов к интеграции и специфику систем, выделим преимущества и недостатки каждого подхода (табл. 1.1).

Таблица 1.2. Достоинства и недостатки методов расчета показателя ПР

Метод интеграции ИС	Достоинства	Недостатки
Плоский файл	1. Низкие трудозатраты на реализацию. 2. Прозрачность процесса. 3. Минимальная доработка систем.	1. Ориентирован на передачу данных с большим интервалом времени. 2. Не позволяет оперативно реагировать на сбои при передаче. 3. Уменьшение эффективности при масштабировании.
Общая БД	1. Полная актуальность данных.	1. Плохо масштабируема. 2. Большие требования к БД (стандарты, производители и т.д.). 3. Объединение уже существующих БД.
Прямая связь систем	1. Простота реализации.	1. Необходимость разработки дополнительного ПО внутри систем.
Централизованный брокер сообщений	1. Доработки в существующих системах сводятся к минимуму. 2. Перенос обработки информации из систем.	1. Необходимость разработки дополнительного ПО
Интеграционная шина	1. Доработки в существующих системах сводятся к минимуму. 2. Обширный набор интерфейсов. 3. Стандартизированность.	1. Дополнительная разработка (только если одна из систем сама не может являться шиной). 2. Носит долгосрочный характер (рассчитан на большие интеграционные проекты). 3. Интегрируемые системы не разработаны для SOA архитектуры.

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

Таким образом было решено разработать централизованного брокера сообщений в виде программного модуля, который, используя API систем принимает от них данные, преобразует и переадресовывает их. В дальнейшем будет рассматриваться именно этот подход.

1.5 Анализ аналогичных решений

1.5.1 SAP PI

В своей работе Д.Ю. Степанов [11] рассматривает готовое решение SAP PI от компании SAP SE как инструмент интеграции корпоративных ИС.

SAP PI (Process Integration) - это интеграционный компонент платформы SAP NetWeaver представленный в 2010 году. Его задачей является обеспечение совместной работы разнородных ИС компании, не только продуктов SAP.

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



Рисунок 1.7. Архитектура SAP PI

Для взаимодействия с внешними системами SAP PI использует адаптеры на базе JCA (Java EE Connector Architecture). Структура адаптеров работает на платформе J2EE (Java 2 Enterprise Edition) сервера приложений SAP NetWeaver Application Server, и имеет собственные сервисы построения очередей и журналов. Механизм адаптеров основан на структуре адаптеров и содержит JCA-совместимый ресурсный адаптер. В инфраструктуру обмена SAP NetWeaver PI входят адаптеры:

- JDBC Adapter;

- JMS Adapter;

- File/FTP Adapter;

- SOAP Adapter;

- HTTP(s) Adapter;

- RFC Adapter;

- IDoc Adapter.



.

Рисунок 1.8. Модель технологии SAP PI

Учитывая, что одна из интегрируемых систем является также продуктом SAP, данное решение выглядит достаточно целесообразно. Однако, как было замечено SAP PI является по сути интеграционной шиной, и очень дорогой интеграционной шиной. Помимо приобретения лицензии SAP NetWeaver, необходимо оплачивать работу компонента PI отдельно, основываясь на объеме передаваемых данных.

1.5.2 Использование SAP .NET Connector

На портале SAP Х. Гупта [16] описывает процесс передачи данных из С# программы в хранилище данных SAP R/3 с помощью SAP .NET Connector 3.0.

SAP .NET Connector - это разработка компании SAP для коммуникации Microsoft .Net платформ и систем SAP, поддерживающая RFC и Web-интерфейсы.

SAP .NET Connector представляет собой библиотеку классов, которая обрабатывает поступающий от программы запрос и преобразует его формат для передачи по RFC протоколу в SAP систему и наоборот (рисунок 1.9).

Рисунок 1.9. Модель технологии SAP .NET Connector

1.5.3 Сравнение аналогов

Данные технологии находятся в разных категориях: SAP PI является крупным продуктом, развертыванием которого занимаются профессионалы, а SAP .Net Connector является инструментом для интеграционного решения. Таким образом, их сравнение по сути является сравнением между приобретением готового решения и собственной разработкой. В таблице 1.3 указаны достоинства и недостатки каждого аналога.



Таблица 1_1.3. Сравнение SAP PI и SAP .Net Connector

	Достоинства	Недостатки
SAP PI (готовое решение)	1. Снижение стоимости разработки и поддержки процессов интеграции; 2. Возможность объединения разнородных систем на базе универсального формата обмена данными; 3. Мощный инструмент для последующих проектов внедрения интеграционных решений (корпоративный портал, управление НСИ, управление знаниями).	1. Представляет собой крупный проект, следовательно, интеграция займет много времени; 2. Необходимость приобретения лицензии; 3. Оплата по факту передачи информации.
SAP .Net Connector (собственная разработка)	1. Имеется в наличии; 2. Позволяет работать с BAPI, RFC-функциями и IDoc из любого .NET-приложения;	1. Необходима разработка; 2. Связь только с .Net приложениями.

Несмотря на то, что SAP PI выглядит предпочтительно в плане функционала и отсутствия разработки, он стоит достаточно крупных финансовых затрат. Таким образом, была выбрана собственная разработка с использованием SAP .Net Connector.

Таким образом, в результате анализа проблемы интеграции КИС и подходов к ее решению, а также анализа интегрируемых систем, был выбран подход централизованного брокера сообщений. При сравнении аналогичных решений было решено использовать в разработке библиотеки SAP для связи .Net приложений с R/3 SAP .Net Connector.



2. Интеграционное решение в бизнес-процессах ПНППК

2.1 Анализ бизнес-процесса планирования и управления производством

Как можно увидеть на карте процессов предприятия (рисунок 2.1), в управлении всеми видами процессов (основными, управляющими и поддерживающими), в их интеграции, создании единого информационного пространства предприятие использует SAP R/3.

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

Рисунок 2.1. Карта процессов ПНППК [1]

На рисунке 2.2 можно увидеть декомпозицию бизнес-процесса “Планирование и управление производством”.

Процесс планирования продаж, или планирования спроса, охватывает будущие потребности без учета запасов и имеющихся мощностей. История продаж часто служит основой для их планирования.

Рисунок 2.2. Декомпозиция процесса «Планирование»

В процессе управления спросом уже корректируется план продаж с учетом требований заказчика в соответствии со стратегией планирования, и таким образом формируется план реализации и производства.

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

Плановый заказ - это количество конкретной детали (узла, изделия), которое планируется изготовить к заданной дате. В основном он имеет силу рекомендации.

Одним из важных этапов ППМ является календарное планирование. Календарное планирование осуществляется на базе операций технологической карты и количества планового заказа. Сроки, как правило, рассчитываются от конечных, начиная с даты потребности, когда этот материал требуется. Таким образом, определяются сроки начала и конца отдельных операций и заказа в целом, а также производится расчет загрузки мощностей. На рисунке 2.4 проиллюстрировано календарное планирование в виде диаграммы Ганта.

Рисунок 2.3. Диаграмма окружения функции планирования потребности в материалах



Рисунок 2.4. Диаграмма Ганта календарного планирования

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

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

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



2.2 Анализ процесса исследования неисправных изделий

Процесс исследования неисправных изделий на предприятии регламентируется стандартом о “Технологии исследования изделий, отказавших у потребителя и в процессе производства” [2].

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

Согласно стандарту, карточки учета неисправностей делятся на несколько типов:

1. КУН на изделие, отказавшее у потребителя - формируется в случае поступления рекламации от компании покупателя изделия и подтверждении дефекта специалистом ПНППК.

2. Производственная КУН - формируется, когда неисправность в изделии обнаружена на любом этапе его производства (первое включение, испытания и т.д.).

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

Процесс исследования, согласно стандарту, можно разделить на следующие этапы:

1. Формирование учетного дела на отказавшее изделие.

2. Анализ сопроводительной документации.

3. Первое включение изделия для подтверждения дефекта.

4. Исследование отказавшего изделия.

5. Разработка мероприятий по устранению и предупреждению причин появления дефектов в изделиях.

6. Оформление и утверждение итогового документа по результатам исследования.

7. Сбор, учет и хранение информации об отказавших изделиях.

8. Анализ статистических данных и формирование отчетных документов по отказам.

Жизненный цикл КУН начинается на этапе формирования учетного дела и заканчивается на утверждении итогового документа исследования.

Существуют отличия в ведении КУН на изделие, отказавшее у потребителя, и производственной КУН в данных этапах. Так, для производственных КУН отсутствуют процессы анализа сопроводительной документации и первого включения, что логично, так как документация отсутствует, а в первом включении нет необходимости. На рисунке 2.5 можно видеть диаграмму окружения функции исследования изделий, отказавших у потребителя и в процессе производства, а в приложении Б ее декомпозицию.

Платформой для исследования неисправных изделий на данный момент является модуль учета неисправностей навигационных систем (МУННС) в системе «База производства ВОГ». Модуль имеет возможность вести электронные КУН, обеспечивая гибким механизмом их согласования с ответственными лицами и формируя по ним отчетность.

Принцип работы с электронными КУН основан на их переходе в различные статусы, отражающие текущее состояние КУН. Статусы и переходы КУН продемонстрированы на рисунках 2.6-7.



Рисунок 2.5. Диаграмма окружения функции "Исследование изделий, отказавших у потребителя или в процессе производства”

Рисунок 2.6. Статусы и переходы производственных КУН и КУН на составные части



Рисунок 2.7. Статусы и переходы КУН на изделия, поступившие от заказчика

Правила перевода между статусами задаются следующим образом:

1. Исходный статус > Конечный статус.

2. Проверка заполнения обязательных полей.

3. Какая роль имеет права на данный перевод.

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

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

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



Таблица 2.1. Стандартные комментарии для типов действия

Тип действия	Комментарий по умолчанию
Согласование	Прошу согласовать
Утверждение	Прошу утвердить
Принять в работу	Прошу принять в работу
На ознакомление	Прошу ознакомиться

Инициатор процесса согласования имеет опцию «Автоматически перевести в конечный статус по окончании согласования».

2.3 Место анализа КУН в процессе планирования и управления производством

Важность процесса исследования отказавших изделий заключается не только в качестве послепродажного обслуживания изделий, что, по словам Захарова А., “катастрофически недооценено в нашей стране” [6], но и в использовании результатов этапа анализа статистических данных для принятия управленческих решений и более точного планирования производства.

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

Так как в случае обнаружения брака изделие может не подлежать ремонту, или на время исследования потребуется списание запаса, данные отчетов по КУН могут быть использованы в планировании производства, конкретно в процессе планирования потребности в материалах для изменения запасов изделий на складе и формирования дополнительных объемов производства. На рисунке 2.8 изображена декомпозиция этого процесса с внедрением использования результатов анализа данных по КУН.

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

Рисунок 2.8. Диаграмма окружения функции планирования потребности в материалах с внедрением интеграционного решения



3. Разработка интеграционного решения

3.1 Проектирование интеграционного решения

3.1.1 Структура данных в МУННС

Центральным объектом в МУННС, как и в исследовании неисправных изделий в принципе, является КУН, точнее таблица «КУН.Карточка». Входящие в нее поля перечислены в приложении В.

В карточке одним из обязательных полей является «№ изделия», которое указывает, в каком изделии была обнаружена неисправность. Данное поле является справочником и берет свои данные из таблицы «Изделия ПНППК». Изделия могут быть произведены разными заводами-изготовителями (цехами), и каждый из них ведет свой перечень изделий по ряду разных причин. Таким образов, таблица «Изделия ПНППК» формируется за счет наполнения данными из таблиц изделий заводов-изготовителей (цехов). В таблице 3.1 можно увидеть структуру таблицы «Изделия ПНППК».

Таблица 3.1. Структура таблицы "Изделия ПНППК"

Поле	Тип поля
ID	Строка
ID_Source	Строка
Тип изделия ПНППК	Справочник
Номер изделия	Строка
Дата выпуска изделия	Дата
Тип производства	Справочник

В перечне полей таблицы «КУН.Карточка» присутствуют два поля с указанным типом - таблица. Это поля «Программа исследования» и «Мероприятия по устранению дефектов», которые являются вложенными таблицами, берущими данные из таблиц «КУН.Программа исследования» и «КУН.Мероприятия по устранению дефектов» соответственно. В таблицах 3.2-3 приведены структуры этих таблиц.

Таблица 3.2. Структура таблицы "КУН.Программа исследования"

Поле	Тип поля
ID строки	Автоинкрементен. Уникальное
№ Карточки	Справочник
№ пункта по порядку	Целое число
Что требуется сделать?	Текст
Срок выполнения	Дата
Ответственный исполнитель	Справочник
Результат	Текст

Таблица «КУН.Программа исследований» состоит из записей действий, которые необходимо сделать в рамках программы исследования дефекта изделия. Это действие записывается в поле «Что требуется сделать?». Каждая такая запись имеет номер КУН, к программе исследований которого она относится.

Таблица 3.3. Структура таблицы "КУН.Мероприятия по устранению дефектов"

Поле	Тип поля
ID строки	Автоинкрементен. Уникальное
№ Карточки	Справочник
Тип мероприятия (для НТЦ)	Справочник
Приоритет	Справочник
Описание мероприятия	Текст
Разработчик мероприятий	Справочник
Подразделение	Справочник
Отв. мастер	Справочник
Отв. контроллер	Справочник
Срок выполнения	Дата
Результат выполнения мероприятий	Справочник
Дата выполнения мероприятий	Дата

Аналогично с записями в таблице «КУН.Мероприятия по устранению дефектов». Каждая запись - это действие, которое необходимо сделать в рамках программы мероприятий по устранению и предотвращению появления дефектов уже после исследования и обнаружения дефекта. Она также содержит номер КУН, к которой относится.

3.1.2 Структура передаваемых данных

Структура данных, которые будут передаваться из системы «База производства ВОГ» в SAP R/3 определяется следующими факторами:

1. Неисправные изделия должны однозначно определяется в SAP R/3.

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

В своей работе SAP R/3 оперирует так называемыми основными данными, включающими в себя основные записи материалов (ОЗМ), технологические карты и спецификации. Для однозначного определения типа изделий, узлов и компонентов (материалов) и предназначена ОЗМ. Таким образом формируется задача соотнесения записей по изделиям из системы «База производства ВОГ» и ОЗМ.

Идентификаторами ОЗМ выступают два атрибута материала: код материала - для системы и децимальный номер - для пользователей, а идентификатором изделий в «Базе производства ВОГ» - поле «Номер изделия». Ни одного из ключевых атрибутов ОЗМ в записи изделий «Базы производства ВОГ» нет. Таблица «Изделия ПНППК» содержит поле «Тип изделия» (приложение В), для которого ОЗМ по сути является справочником. Возможностью соотнесения ОЗМ и типа изделия является сравнение поля «Тип изделия» «Базы производства ВОГ» и поля «Краткое название» ОЗМ.

В этом случае встает проблема сравнения, так как автоматическое сравнение невозможно из-за разных способов ввода, сокращений, регистра и т.д. Было принято решение составления перекодировочной таблицы, которая бы использовалась для преобразования записей изделий при занесении их в SAP R/3.

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

1. Наименование и оригинальный номер изделия.

2. Наименование и оригинальный номер компонента.

3. Дата забракования.

4. Цех обнаружения дефекта.

5. Участок обнаружения дефекта.

6. Номер КУН.

7. Количество забракованных изделий.

8. Стадия отказа изделия.

9. Результаты исследования.

10. Дата возврата изделия.

11. Дата закрытия КУН.

Таблица 3.4. Структура передаваемых данных для SAP R/3

Поле	Тип данных
№ КУН	CHAR
Цех/Плановик	CHAR
ВыпускУчасток	CHAR
Проявление дефекта	NUMC
Дата выписки	CHAR
Стадия отказа	CHAR
Изделие	CHAR
НомИзд	DATS
Компонент	CHAR
НомДет, узла	INT4
Статус	CHAR
Результат исследования	CHAR
Классификация дефекта	CHAR
Дата классификации	CHAR
ДатаЗакрКУН	CHAR
ДатаВозврИзд	CHAR

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

Согласно стандарту о «Технологии исследования изделий, отказавших у потребителя и в процессе производства» [2], датой закрытия КУН можно считать дату его согласования с главным контролером и директором по качеству. Данная процедура согласования происходит в статусе «Утверждение КУН». Таким образом датой закрытия КУН можно считать его переход из статуса «Утверждение КУН» в статус «Выполнение мероприятий».

3.1.3 Проектирование функционала модуля

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

1) получение данных по карточкам учета неисправностей из системы “База производства ВОГ”;

2) отправка данных по карточкам учета неисправностей в систему SAP R/3;

3) обработка данных.

Как уже было сказано, в системе “База производства ВОГ” реализован REST API, который позволяет совершать любые действия с системой не только через интерфейс, но и через программный вызов соответствующих HTTP методов. Работа с API системы происходит по протоколу HTTP в формате JSON. Перечень с имеющимися API системы “База производства ВОГ” можно увидеть в приложении Г. Для функции обмена данными целесообразно использовать эти API, так как не потребуется дополнительная разработка.

Как видно в перечне API системы «База производства ВОГ» (приложения Г), каждый API требует идентифицирующий токен пользователя в заголовке метода. Для определения токена пользователя изначально требуется вызвать API «Login» с указанием своего логина и пароля:

{ "Login": "логин",

"Password": "пароль" }

Процесс получения и отправки данных по карточкам учета неисправностей будет происходить следующим образом (рисунок 3.1):

1) пользователь вводит свои логин и пароль от систем «База производства ВОГ» и SAP R/3;

2) модуль получает идентифицирующий токен в системе «База производства ВОГ» с помощью API «Login»;

3) модуль с помощью токена использует API для получения данных из системы «База производства ВОГ»;

4) модуль получает данные;

5) модуль преобразует данные;

6) модуль устанавливает соединение с BAPI SAP R/3;

7) модуль отправляет данные в систему SAP R/3.



Рисунок 3.1. UML диаграмма последовательности процесса получения и отправки данных по карточкам учета неисправностей

Процесс обработки данных подразумевает под собой сериализацию и десериализацию данных в зависимости от системы, с которой происходит соединение: с “Базой производства ВОГ” это, как уже было сказано, JSON, с SAP R/3 - IDос (Intermediate Document).

Документы IDoc являются контейнерами для обмена данными в предустановленном формате в SAP системе, между SAP системами и между SAP и не-SAP системами. Тип IDoc может передавать несколько типов сообщений. IDoc используются для входящей и исходящей обработки. Адаптер поддерживает простой и расширенный типы IDoc.

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

3.1.4 Архитектура интеграционного решения

На рисунке 3.2 можно увидеть архитектуру разрабатываемого интеграционного решения.

Рисунок 3.2. Архитектура интеграционного решения

3.2 Реализация интеграционного решения

3.2.1 API в «Базе производства ВОГ»

Как уже было сказано, для передачи данных по КУН из системы «База производства ВОГ» в интеграционных модуль будут использоваться API данной системы. Из перечня API (приложение Г) видно, что для просмотра таблиц подойдут «TableDataPage» и «TableStructure», первый возвращает записи таблицы, а второй - метаданные и записи.

Однако, так как некоторые данные отсутствуют в таблице «КУН.Карточка», потребуется сложное тело запроса JSON. Для избегания сложного тела запроса со стороны разработчиков системы «База производства ВОГ» был разработан табличный отчет, формирующийся SQL-запросом и содержащий все согласованные данные. Но для передачи записей данного отчета будет использоваться API «ViewStructure».



3.2.2 BAPI в SAP R/3

Со стороны SAP R/3 был разработан BAPI, задачей которого является прием данных от интеграционного модуля, преобразование этих данных с помощью кодировочной таблицы и сохранение их в таблицу «КУН (Карточка учета неисправности)» в базе данных SAP R/3. Структура таблицы соответствует структуре в таблице №.

BAPI было дано системное имя ZBAPI_INSERT_CUN. Далее задан его дистанционный вид выполнения (рисунок 3.3).

Рисунок 3.3. Задание свойств дистанционного функционального модуля в SAP R/3

Программа модуля оперирует таблицей базы данных R/3 «КУН (Карточка учета неисправности)» (системное имя ZPP_0160) и загружаемыми данными:

tables: zpp_0160.

data: wa_itab like line of itab.

Все данные таблицы ZPP_0160 удаляются и заносятся заново с каждым вызовом модуля. Для связывания данных по материалам (ОЗМ) в SAP R/3 с материалом, указанным в карточке используется кодировочная таблица (wa_itab-nomizd_izd), занесенная в код:

perform convert_nomizd using wa_itab-nomizd_izd changing zpp_0160-nomizd_izd.

3.2.3 Разработка интеграционного модуля

Интеграционным модулем будет являться консольное приложение C#, запускаемое с помощью пакетного файла. Разработка будет вестись в Visual Studio 2013.

После создания проекта консольного приложения подключим используемые библиотеки классов, которые на потребуются в будущем: библиотеки SAP .Net Connector и JSON.Net (рисунки 3.4-5).

Рисунок 3.4. Подключение библиотек SAP .Net Connector

Рисунок 3.5. Подключение библиотек JSON

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

Для начала заведем переменные для хранения логинов и паролей:

private static string lSapLogin = null;

private static string lSapPassword = null;

private static string lCunLogin = null;

private static string lCunPassword = null;

Присвоим переменным значения вводимых параметров:

static void Main(string[] args)

{ lSapLogin = args[0];

lSapPassword = args[1];

lCunLogin = args[2];

lCunPassword = args[3]; }

Для дальнейшего получения пользовательского токена и данных по КУН из системы «База производства ВОГ» необходимо разработать метод, вызывающий API в данной системе. Метод будет универсальным и будет принимать три аргумента: URL, тело запроса и используемый HTTP метод (по умолчанию POST).

public static dynamic SendApiCall<T>(string url, T request, bool isPost = true) {}

В данной методе отправляется запрос по указанному URL и результат десериализуется из формата JSON:

result = Client.PostAsJsonAsync(url, request).Result;

string responseString = result.Content.ReadAsStringAsync().Result;

dynamic response = JsonConvert.DeserializeObject(responseString);

return response;

Теперь необходимо только вызвать API “Login” для получения токена, за тем внести его в заголовок запроса API и вызвать данные по КУН:

dynamic LoginResult = SendApiCall(Cun_Api_Log, new LoginRequest()

{

Login = lCunLogin,

Password = lCunPassword

});

string Token = LoginResult.Account.AccessToken;

Client.DefaultRequestHeaders.Add("AuthToken", Token);

dynamic CunData = SendApiCall(Cun_Api_ViewStructure, reqJson);