Full Text

Введение Организационные реформы, затронувшие стратегические отрасли промышленности Российской Федерации, привели к значительным изменениям в хозяйственной деятельности каждой организации военно-промышленного комплекса [1-4]. Круг вызовов, с которыми столкнулись участники вновь образовавшихся коопераций, расширяется, особенно в контексте цифровой экономики [5-9]. Одним из таких вызовов стала информационная поддержка процесса интеграции ранее независимых организаций. Основной ценностью, создаваемой в рамках жизнедеятельности предприятий оборонно-промышленного комплекса, выступает создание высокотехнологичных надежных решений, производимых с применением комплектующих, поставляемых в рамках кооперации. Как следствие, качество организации интеграционного взаимодействия [10-12] оказывает прямое воздействие как на качество и объемы выпускаемой продукции, так и на финансовую и организационную устойчивость бизнес-процессов, создающих ключевую ценность. Отсутствие налаженного интеграционного взаимодействия приводит к таким проявлениям неэффективности, как дублирование процессов и зон ответственности, отсутствие прозрачности процессов, отсутствие возможности регулярной и качественной оценки эффективности участников и кооперации в целом, как следствие, низкое качество стратегического планирования. Таким образом, ключевым фактором в повышении эффективности процессов управления оборонно-промышленным комплексом является их информатизация [13-21], в том числе автоматизированное обеспечение устойчивости внутриотраслевой кооперации, требующее разработки новых ИТ-решений, обеспечивающих интеграцию информационных систем кооперантов. При проектировании информационной системы в организациях кооперативного типа учитывается ряд особенностей: сложность структуры, гетерогенность, рассредоточенность, динамика, многофункциональность, защищенность. С учетом потребности в проектировании на базе уже существующих систем (монолитов), потребности в минимизации и фиксировании бюджета проекта, отсутствии возможности создания гибкой проектной команды, крайней защищенности информации, а также необходимости контроля качества и управления рисками была выбрана методология архитектурного проектирования. На базе выбранной методологии проектирования предлагается проект ИТ-решения, базируемого на технологическом стеке микросервисной архитектуры. Микросервисная архитектура наиболее релевантна указанным особенностям информационных систем участников кооперации. Проектирование контракта взаимодействия Проектируемое ИТ-решение сталкивается с задачей по согласованию такого контракта взаимодействия, при котором вызов программных интерфейсов приложений проектируемой микросервисной архитектуры будет происходить с минимальным количеством сбоев. При этом значительное отличие проектируемого решения заключается в том, что актор (пользователь) передает исходные данные в информационной системе отдельно взятого кооперанта, тогда как далее информационные потоки проходят множество программных интерфейсов микросервисной архитектуры. Более распространено решение, при котором пользователь непосредственно вызывает методы с помощью графического пользовательского интерфейса. В проектируемом ИТ-решении пользователь использует графический интерфейс отдельного модуля монолитной информационной системы, после чего система самостоятельно передает данные в проектируемую микросервисную архитектуру. В связи с этим проектирование сервисов на базе контракта взаимодействия выступает единственным возможным решением. Выходные атрибуты контракта взаимодействия содержат ряд крупных блоков, часть из которых формируется на программном уровне (информационная система самостоятельно передает данные на основании актуальной информации в системе), часть вводится экспертами через дополнительно проектируемый графический интерфейс. В рамках контракта взаимодействия на программном уровне формируются и передаются следующие данные: • данные организации: информация о руководящем лице, наименование, платежные реквизиты организации, контакты для связи с организацией; • отчетные показатели о ходе закупочной деятельности, детализированные как в части закупочных документов, так и в части состава товарного обмена (объем и стоимость закупаемой материальной части), также передается информация о купленной материальной части, временно находящейся на ответственном хранении у поставщиков; • отчетные показатели о ходе производственной деятельности, детализированные в части характера производства (серийное производство, НИОКР, ремонт или запасные части), планируемого и фактического объема выпуска продукции; • отчетные показатели складского учета, включающие информацию о перечне складов в управленческой информационной системе участника кооперации и их номенклатурном составе с указанием актуального объема; • отчетные финансовые показатели, передаваемые по форме, аналогичной форме отчета о финансовых результатах российского стандарта бухгалтерской отчетности. Также дополнительно передается информация о лице, ответственном за подготовку отчетности - главном бухгалтере организации либо главном аудиторе организации, если такой предусмотрен штатным расписанием; • предустановленный порядок, схема передачи вышеуказанных атрибутов - состав единого шаблона проектирования Data Transfer Object. На уровне вспомогательного графического интерфейса передаются экспертные значения каждого из коэффициентов, которые рассчитываются в рамках проектируемой микросервисной архитектуры. Контракт взаимодействия проектируемого решения предусматривает передачу данных из информационных систем участников кооперации через брокера очередей Kafka, таким образом, дополнительно исходящее сообщение приобретает обязательные заголовки, необходимые для возможности чтения сообщения брокером очередей. Бизнес-логика создания микросервисной коллаборации Оценка эффективности предприятий, объединенных кооперационными связями, но не объединившимися юридически, является сложной задачей, решаемой широким спектром уже имеющихся методов: методы экспертных оценок, методы многокритериальной оптимизации, матрицы попарных сравнений, институциональный подход. В рамках оценки эффективности внутриотраслевой кооперации существует ряд субъективных факторов, требующих качественной оценки, тогда как для расчета требуются количественные. Метод иерархий Саати является наиболее релевантным поставленной задаче и используется в рамках исследований как основной. Ниже приведена схема осуществления интегральной оценки эффективности деятельности кооперации как единого интегрированного механизма, в расчетах результирующего показателя которой используются методы экспертных оценок и метод анализа иерархий Саати. Первым этапом является расчет показателей эффективности по каждому кооперанту (1), где - коэффициент обновления ассортимент выпускаемой продукции, - план-фактная оценка выполнения плана производства, - коэффициент качества, основанный на проценте выбраковки, - коэффициент независимости выполнения производственного плана от поставок в связи с наличием страхового запаса, - коэффициент финансовой независимости, - коэффициент независимости выполнения производственного плана от поставок конкретного поставщика, - коэффициент, оценивающий институциональное взаимодействие участников, - коэффициент подменного фонда, - коэффициент страхового запаса на складах поставщиков. (1) Далее микросервис осуществляет пересчет коэффициентов с учетом экспертных оценочных значений веса каждого коэффициента на основании данных, переданных в объекте Metrics_Info_List от информационных систем кооперантов. В рамках спроектированного контракта взаимодействия экспертные данные транслируются в ходе всего интеграционного процесса от поступления через графический интерфейс информационной системы участника кооперации к сервису осуществления расчетов без изменений. Взвешенные оценки значений коэффициентов эффективности по каждому участнику кооперации используются в расчете интегрального показателя оценки эффективности каждого участника кооперации. Далее микросервис осуществляет окончательный расчет оценки эффективности кооперации с учетом веса каждого участника кооперации в соответствии с весами, программно заложенными в стратегии микросервиса. (2) Триггером межкомпонентного взаимодействия может выступать как запрос от лица, принимающего решение через графический пользовательский интерфейс, так и передача обновленных данных от информационных систем участников кооперации, например, при выгрузке актуальной финансовой отчетности. При успешной валидации входящего сообщения сервис запускает осуществление стратегии расчетов. По итогам осуществления расчетов микросервис формирует JSON-сообщение для передачи итогов расчетов для обработки в графическом пользовательском интерфейсе. Ответ на исходный запрос также проходит без изменений через шлюз аутентификации UI-auth-service и подготавливается к отображению в графическом интерфейсе пользователя. С точки зрения логики всего процесса окончательным событием будет вывод на экран пользователя дашборда с результатами расчетов. Проектирование архитектуры ИТ-решения Системная архитектура - фундаментальная организация системы, реализованная в ее компонентах, их взаимосвязях друг с другом и с окружающей средой, и руководящие правила проектирования и развития системы [22]. К прикладной архитектуре в рамках проектируемого ИТ-решения относятся сервисы, обеспечивающие прием, маршрутизацию и передачу данных, такие как брокер связи и адаптер; интерфейсы, обеспечивающие REST-взаимодействие внутри сервисной коллаборации, микросервисы сервисной коллаборации и UI-интерфейс. К архитектуре данных относятся сервисы, осуществляющие актунтификацию, сервис-хореограф, осуществляющий управление обменом данными в рамках коллаборации, и локальные хранилища данных микросервисов. Рассмотренные выше уровни сложно графически интерпретировать отдельно друг от друга, в связи с чем речь идет о проектировании целостной системной архитектуры. На рис. 1 изображена предлагаемая в иссследовании системная архитектура проектируемого ИТ-решения на примере трех участников отраслевой кооперации. Графическая интерпретация системной архитектуры разработана на базе архитектурного языка ArchiMate и с применением соответствующего программного обеспечения ArchiMateModellingTool. Приложения, включенные в состав единой информационной системы каждого кооперанта, могут быть представлены большим количеством тематических модулей. В рамках системной архитектуры представлены те модули, которые являются необходимыми и достаточными для организации релевантного задаче интеграционного взаимодействия. В рамках проектируемого решения предлагается следующий технологический процесс информационного обмена: 1. Брокер принимает сообщения от сервиса участника кооперации в заданный топик Kafka. 2. Брокер дробит сообщение и задает Data Transfer Object с соответствующей тематикой (закупки, склад и т.д.). 3. Адаптер принимает сообщения из заданного топика и с помощью REST API подготавливает JSON-сообщения в соответствии с контрактом взаимодействия для аутентификации в контуре и обращения в каждый из микросервисов (storage-service, finance-service, manufactuting-service, purchase-service). 4. Передача сообщения от сервиса аутентификации в микросервисы. 5. Микросервисы передают необходимую информацию в сервис-хореограф. Рис. 1. Возможный вариант поддержки архитектуры ИТ-решения на программном уровне 1. Сервис-хореограф формирует Data Transfer Object для сбора данных с сервисов и передачи в систему осуществления расчетов. 2. Сервис-хореограф аккумулирует данные и передает с помощью REST API в сервис осуществления расчетов. 3. Сервис осуществления расчетов в соответствие с заданными моделями принятия решений производит подсчет, сохраняет в локальном хранилище данных. 4. Сервис аутентификации предоставляет доступ UI для использования данных, полученных в ходе применения модели в сервисе осуществления расчетов. 5. UI-сервис на базе Grafana предоставляет лицам, принимающим решение, доступ к аналитической информации, предварительно визуализированной. Важным фактором выбора и обоснования продуктов с открытым исходным кодом и непосредственно микросервисной архитектуры выступает возможность реализовать эффективное решение, не создавая препятствий для следования федеральному законодательству об импортозамещении. С технической точки зрения сервисная коллаборация, создаваемая в рамках ИТ-решения, не относится непосредственно ни к одному из участников внутриотраслевой кооперации с точки зрения континуума организации. Микросервисная коллаборация - внешняя надстройка, работающая на лицо, принимающее решение. Оценка структурной устойчивости проектируемой архитектуры Для проведения оценки структурной сложности в данной работе предложено моделирование проектируемого решения в виде графа (рис. 2) с последующим расчетом матрицы контуров и метрик системной устойчивости. На рис. 2 представлен смешанный граф G = (14,22), где 14 - порядок графа, 22 - мощность множества дуг графа. Граф G является смешанным, так как содержит в себе и ориентированные дуги, и ребра. На рис. 2 дуги g, h, i, j обозначают односторонний поток сообщений, остальные дуги указывают на двусторонний характер взаимодействия и заменяют пары разнонаправленных стрелок. Смысловая интерпретация вершин графа представлена в табл. 1. Для сохранения достоверности расчетов брокер очередей на базе Kafka был исключен из графа как дублер адаптера по своему назначению. С целью оценки взаимной зависимости компонент проектируемой архитектуры построим матрицу смежности на основании графа G. Матрица смежности графа позволяет оценить количество вершин, связанных общей дугой с другими вершинами. Матрица смежности графа G представлена в табл. 2. Представленная матрица смежности позволяет сделать вывод, что наиболее сильно связанной компонентой выступает монолитная архитектура из четырех модулей, представленная вершинами 1-4. Микросервисная коллаборация, напротив, состоит из взаимонезависимых компонент (вершины 7-10) и компонент-связей, которые обеспечивают взаимосвязь бикомпонент, выделенных различными цветами в табл. 2. Более достоверно о наличии сильносвязанных бикомпонент говорит матрица достижимости, отражающая возможности достижения вершин в графе по путям, слагаемым из смежных дуг. Далее будут приведены результирующие расчеты. Рис. 2. Граф G представления проектируемого ИТ-решения Таблица 1 Расшифровка вершин графа № вершины Наименование компоненты проектируемого ИТ-решения 1 Модуль «Закупки» ИС Кооперанта 2 Модуль «Складкой учет» ИС Кооперанта 3 Модуль «Финансы» ИС Кооперанта 4 Модуль «Производство» ИС Кооперанта 5 Адаптер (score-collab-adapter) 6 Сервис аутентификации (collaboration-auth-service) Окончание табл. 1 № вершины Наименование компоненты проектируемого ИТ-решения 7 Микросервис «Закупки» 8 Микросервис «Склады» 9 Микросервис «Финансы» 10 Микросервис «Производство» 11 Хореограф 12 Сервис осуществления расчетов (score-account-service) 13 Сервис аутентификации (UI-auth-service) 14 Графический пользовательский интерфейс (UI) Комплексная оценка структурной сложности возможна при применении следующего алгоритма [23]: матрица смежности умножается на матрицу инцидентности, полученный массив в свою очередь умножается на транспонированную матрицу контуров. Полученный расчетный массив представлен в табл. 3. Таблица 2 Матрица смежности графа G 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 2 1 0 1 1 1 0 0 0 0 0 0 0 0 0 3 1 1 0 1 1 0 0 0 0 0 0 0 0 0 4 1 1 1 0 1 0 0 0 0 0 0 0 0 0 5 1 1 1 1 0 1 0 0 0 0 0 0 0 0 6 0 0 0 0 1 0 1 1 1 1 0 0 0 0 7 0 0 0 0 0 1 0 0 0 0 1 0 0 0 8 0 0 0 0 0 1 0 0 0 0 1 0 0 0 9 0 0 0 0 0 1 0 0 0 0 1 0 0 0 10 0 0 0 0 0 1 0 0 0 0 1 0 0 0 11 0 0 0 0 0 1 1 1 1 1 0 1 0 0 12 0 0 0 0 0 0 0 0 0 0 1 0 1 0 13 0 0 0 0 0 0 0 0 0 0 0 1 0 1 14 0 0 0 0 0 0 0 0 0 0 0 0 1 0 Таблица 3 Расчетный массив комплексной оценки структурной сложности графа I II III IV 1 1 1 1 1 2 1 1 1 1 3 1 1 1 1 4 1 1 1 1 5 2 2 2 2 6 3 3 3 3 7 4 3 3 3 8 4 3 3 3 9 4 3 3 3 10 4 3 3 3 11 6 4 4 4 12 4 1 1 1 13 3 0 0 0 14 2 0 0 0 Полученный расчетный массив указывает на повышенную нагрузку на компоненту, соответствующую вершине 11 графа G - микросервису хореографии процессов. Такой перевес в сторону сервиса, оркестрирующего процесс, распространен на практике и не является аномалией. Также повышенную нагрузку можно отметить на тематических микросервисах (вершины 7-10), при потенциальном увеличении нагрузки на соответствующие микросервисы потребуется их последовательный рефакторинг. Остальные компоненты проектируемого решения являются умеренно и равномерно нагруженными. Компоненты, входящие в монолитные архитектуры участников кооперации, испытывают минимальную нагрузку, что соответствует обозначенным ранее бизнес-потребностям. 1. Проектируемое решение удобно и эффективно с точки зрения тестирования. 2. В проектируемом решении присутствует лишь одна высоконагруженная компонента - хореограф процессов. 3. Компоненты решения, соответствующие информационным системам участников кооперации, - мало нагружены. 4. Проектируемое решение не имеет изолированных или труднодостижимых компонент, что положительно характеризует его устойчивость. Заключение Основным результатом исследования является построенная модель интегральной оценки эффективности внутриотраслевой кооперации на базе экспертных оценок и метода анализа иерархий Саати. Описана бизнес-логика интеграционного процесса и процесса осуществления расчетов, приведено концептуальное и логическое проектирование, сформирован состав исходных данных для проектирования контракта взаимодействия. Также в рамках статьи осуществлено архитектурное проектирование на физическом уровне, предложено решение по программной поддержке интеграционного процесса с учетом особенностей организаций кооперативного типа. Проведена оценка устойчивости ИТ-решения на основании смешанного графа и комплексной матричной оценки ИТ-решения. Предложенное решение по организации интеграционного процесса позволяет осуществлять интегральную оценку эффективности кооперации в режиме real-time-enterprise, а также удовлетворяет потенциалу масштабирования коопераций и в разы сокращает объем задублированных функций. Таким образом, предложенное в статье ИТ-решение обеспечивает потенциал роста финансовой и организационной эффективности, а также рост качества управленческих решений в части развития коопераций в оборонно-промышленном комплексе.

About the authors

I. Yu Kotsyuba

ITMO University

E. O Volodikova

ITMO University

References

Statistics

Views

Abstract - 88

PDF (Russian) - 89

Refbacks

• There are currently no refbacks.