Разработка архитектурного описания цифрового предприятия ООО "Гриндата"

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

в процессе создания архитектуры принимают активное участие как ИТ служба, так и бизнес-подразделения;

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

описание текущей архитектуры постоянно обновляется и подлежит уточнению, каждому доступна её актуальная версия, специальные средства обеспечивают управление версиями, новые сотрудники иногда встречаются с описанной архитектурой во время своего обучения;

существует явный контроль за применением стандартов, процесс рассмотрения отклонений формализован;

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

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

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

4

Управляемый

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

руководство принимает участие в обсуждении результатов проекта по построении архитектуры;

все бизнес-подразделения плотно участвуют в разработке архитектуры;

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

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

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

выявленные отклонения от архитектуры способствуют её незамедлительной коррекции, существует явный контроль за всеми инвестициями в ИТ;

руководители организации и ИТ-служба совместно проводят инициацию проекта по построению архитектуры компании, а также определяют его требования. Существует процесс управления вендорами. Одно из основных требований - непрерывное производство при изменении;

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

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

5

Оптимизирующий

требования постоянно измеряются, что ведёт к постоянному улучшению процессов предприятия;

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

бизнес-подразделения дают рекомендации участникам проекта по разработке архитектуры, чтобы улучшить сам процесс;

предполагаемые изменения моделируются и апробируются перед внедрением;

исключительные ситуации используются для улучшения процесса разработки архитектуры, её распространения и контроля;

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

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

полное отсутствие незапланированных закупок ПО.

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

Выводы по первой главе

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



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

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

2.1 Описание компании и платформы «GreenData»

Отечественная компания-разработчик ООО «Гриндата» предоставляет услуги по автоматизации деятельности финансовых организаций посредством собственной разрабатываемой интеллектуальной «low-code» платформы «GreenData» для создания бизнес-приложений. В сферу деятельности помимо автоматизации бизнес-процессов входят:

разработка специализированных инструментов на основе предлагаемой платформы;

поставка лицензий на продукты компании;

управление риском с помощью предоставляемой платформы;

сопровождение и техническая поддержка существующих пользователей;

интеграция платформы.

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

Платформа «GreenData» делится на модули:

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

«Управление заявками» - позволяет оптимизировать нагрузку на специалистов организации, настроить рабочее пространство и структурировать процесс по обработке заявок;

«Кредитный риск» - реализует процесс расчёта кредитного риска клиентов организации с помощью сервисов проверки, оценку рейтинга, анализа клиента и его отчётности, настройку методики, а также проведении расширенной аналитики;

«Коллегиальные органы» - позволяет настраивать рабочие места секретаря и участников коллегиальных органов, подготавливать электронные заседания и управлять ими в интерактивном режиме, формировать договоры с помощью смежного модуля eDoc;

«eDoc» - реализует автоматическое формирование электронных документов, соглашений;

«Мониторинг и раннее предупреждение» - позволяет проводить контроль и интерактивный анализ платёжеспособности клиентов из внешних источников, проверять условия договоров, строить графики мониторинга.

Основные предоставляемые функциональные возможности представлены ниже:

структурирование и хранение данных посредством настраиваемой объектной модели с требуемой иерархией, связями и правилами наследования;

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

автоматизация бизнес-процессов в нотации BPMN 2.0, а также управление задачами, осуществление маршрутизации документов с объектами, контроль исполнения и мониторинг;

настройка собственных бизнес-правил (BRMS) через задание условий видимости элементов экранных форм, формирования подсказок, логических и арифметических проверок, задание условий переходов в бизнес-процессах, нормативных сроков и уведомлений;

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

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

аналитика и отчетность, представляющая из себя настройку параметрических табличных отчётов, конструктор OLAP-отчётов, готовые специализированные виджеты, экспорт аналитических и отчётных данных;

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

Более подробно с платформой «GreenData» можно ознакомиться на сайте компании: www.greendatasoft.ru.



2.2 Основные бизнес-процессы

Компания ООО «Гриндата» имеет множество бизнес-процессов, однако в работе будут описаны и проанализированы только ключевые из них, а именно:

Разработка программного продукта.

Тестирование и интеграция изменений.

Настройка платформы и перенос обновлений.

Для построения обозначенных бизнес-процессов была использована нотация extended Event driven Process Chain (eEPC), входящая в стандарт для описания регламентов и процедур, формирующую бизнес-процессы предприятия.

Процесс разработки платформы «GreenData» в компании представлен на рисунках 2.1-2.2.

Рисунок 2.1. Бизнес-процесс по разработке программного продукта



Старт процессу разработки дают два события - необходимость разработки совершенно нового модуля, либо крупная доработка существующего, поскольку возникла такая потребность для реализации требований Заказчика. Следует отметить, что принцип разработки новых модулей и проведении доработок для Заказчика построен по принципу Agile, то есть Заказчик в любой момент времени может потребовать новый функционал и компания должна его реализовать согласно договору. Процесс работы с Заказчиком не предусматривает всеобъемлющего технического задания, как это принято во многих IT-компаниях. Таким образом, детализация требований может проводиться постоянно, поскольку Заказчик потребует всё большего и большего функционала.

Рисунок 2.2. Продолжение бизнес-процесса по разработке программного продукта

Сам процесс по детализации требований проходит в GitLab-е в репозитории компании, после чего формируется постановка задачи для разработчика. Процесс обсуждения конкретной реализации ведётся между аналитиками и разработчиками в том же GitLab-e, итогом которого становится запланированная задача и присвоенный ей спринт, в котором она должна быть будет выполнена. Приоритеты задач делятся на low, high, normal, critical и blocking. Последний приоритет имеет блокирующую функцию, то есть задача с данным приоритетом должна выполняться в первую очередь. Это связано с важностью доработки для Заказчика и группы аналитики. Чаще всего, подобные задачи блокируют дальнейшую работку аналитиков в системе и связаны с обнаруженными критическими ошибками системы. Приоритеты, не являющиеся критичными и блокирующими могут обрабатываться очень долгое время, поскольку у команды разработчиков накопилось большое количество задач с высшими приоритетами. Часто аналитики пренебрегают другими приоритетами для того, чтобы быстрее выполнить свои задачи, что создаёт очередь из задач с блокирующими и критическими типами. У описываемого бизнес-процесса существует и другие точки входа - БП «Тестирование функционала и интеграция изменений», а также «Настройка платформы и перенос обновлений». Данные бизнес-процессы могут заканчиваться с ошибкой, которая передаётся в работу разработчикам. Итогом данного бизнес-процесса является переход в другой бизнес-процесс «Тестирование функционала и интеграция изменений» (рис. 2.3).

Бизнес-процесс по тестированию и интеграции изменений начинается в результате перевода задачи на тестировщика после разработки программного продукта. Для тестирования изменений в компании предусмотрен тестовый стенд для каждого проекта. Под стендом понимается развёрнутый экземпляр платформы на сервере. Тестировщик собирает актуальную версию платформы «GreenData» и устанавливает её на тестовый стенд с целью проведения тестирования. Если тестирование прошло удачно, задача переводится на системного аналитика, который также должен произвести тестирование доработки (см. рис 2.3-2.4). В случае возникновения системных ошибок задача на разработку переводится на разработчика.

Рисунок 2.3. Тестирование функционала и интеграция изменений, часть 1

Рисунок 2.4. Тестирование функционала и интеграция изменений



После проведения всех фаз тестирования реализованные доработки должные быть внедрены на все стенды (см. рис. 2.5).

Рисунок 2.5. Применение изменений на все рабочие стенды

Применением доработок занимается разработчик, что занимает у него достаточно много времени. При установке системных обновлений на рабочие стенды настройку системы производить нельзя. Очень часто случается, что кто-то из аналитиком не заметил предупреждение в Skype и во время установки обновления занимался настройкой, что привело к потере результата после обновления стенда. Рабочие стенды делятся на внутренние и внешние, к которым нужен специальный доступ, поскольку они установлены у Заказчика локально. Для того, чтобы установить обновления на стенды Заказчика необходимо собрать патч и выслать его в банк, где уже будет производиться установка другим разработчиком. После проведения обновления можно переходить к настройке системы.

Бизнес-процесс «Настройка платформы и перенос обновлений» имеет две точки входа: проведённое тестирование нового или доработанного функционала, а также задача по реализации новой настройки для Заказчика (рис. 2.6).

Рисунок 2.6. Начало бизнес-процесса по настройке и переносу обновлений, часть 1

Все проводимые настройки должны реализовываться только на базовом стенде, после чего подлежат тестированию для дальнейшего переноса на другие стенды. Настройку системы совершает системный аналитик. После проведения тестирования осуществляется процесс переноса сделанных изменений на другие стенды при помощи GUF-файлов (GreenData Update File). Все переносимые объекты сначала вручную «собираются» с базового стенда, а потом устанавливаются на другие. При возникновении ошибок создаются задачи на доработку в GitLab-е (рис. 2.7).

Рисунок 2.7. Продолжение бизнес-процесса по настройке и переносу обновлений, часть 2

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



Рисунок 2.8. Продолжение бизнес-процесса по настройке и переносу обновлений, часть 3

После проведённого регрессионного тестирования производится передача обновлений на стенды Заказчика посредством общих пакетов обновлений, в которые входят GUF-ы из других модулей проекта. Каждому GUF-у присваивается свой уникальный номер обновления, в соответствии с которым он будет устанавливаться на стенды Заказчика (рис. 2.9). Установкой обновления занимается как интегратор, так и системный аналитик. Установка может производиться только в нерабочее время Заказчика, поскольку напрямую затрагивает используемый функционал стендов, что может привести к ошибкам в работе. Следует также отметить, что установка обновлений на стенды Заказчика невозможно без подключения к локальной сети Заказчика с помощью специальных программ удалённого доступа. В настоящий момент времени используется «Рутокен». После установки обновления аналитик или руководитель проекта должны отписаться Заказчику о том, что обновления установлены и можно приступать к тестированию. Основные средства связи, используемые для работы с Заказчиком: телефон, скайп и электронная почта, хотя можно было бы использовать возможности платформы и создать модуль, отвечающий за взаимодействие между Заказчиком и проектной группой, например, можно делиться документациями и настроить процессы тестирования.

Рисунок 2.9. Продолжение бизнес-процесса по настройке и переносу обновлений, часть 4

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

Рисунок 2.10. Продолжение бизнес-процесса по настройке и переносу обновлений, часть 5

Бизнес-процесс по настройке и переносу обновлений заканчивается эксплуатацией Заказчиком платформы и сделанных настроек.

2.3 Существующие проблемы

На основании проведённого интервью с ключевыми лицами компании ООО «Гриндата», а именно: руководителем отдела разработки, главным архитектором и руководителями существующих проектов, а также описанию и анализу ключевых бизнес-процессов организации, были выявлены следующие основные проблемы:

отсутствие понимания ключевых ответственных лиц компании в целом и по проектам в частности штатными сотрудниками компании;

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

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

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

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

трудности процесса переноса сделанных настроек в виде обновлений с одного стенда на другой;

отсутствие системы уведомлений перед установкой обновлений, сбрасыванием кэша или показами результатов настройки заказчику;

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

2.4 Модель архитектуры предприятия «As is» в Archi

Методология TOGAF предполагает использование либо своей компоненты ADM (Architecture Development Method), либо FA (Foundation Architecture). В рамках данной работы была выбрана методика ADM, поскольку она включает в себя фазы, отвечающие за переход к новому состоянию и управлению изменениями, а также подразумевает составление gap-анализа и построение различных видов архитектур, отвечающие за разные точки зрения. Для материализации всех необходимых архитектур требуется использовать предоставляемые TOGAF язык моделирования ArchiMate 3.0.1. в программе Archi.

Создаваемые архитектуры будут описывать текущее состояние предприятия ООО «Гриндата» с различных точек зрения.

2.4.1 Организационная точка зрения

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

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

2.4.2 Точка зрения продукта

Следующая точка зрения «Product viewpoint» фокусируется на ценности, которую продукт будет предлагать клиентам. Она показывает составной продукт с точки зрения составляющих (бизнес, используемые приложения или технологии) услуг. Поскольку главный продукт компании ООО «Гриндата» является собственная платформа «GreenData», то данный вид был построен с учётом её модулей и основным предоставляемым функциям (см. прил. А, рис. 5).

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

2.4.3 Точка зрения мотивации

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



Рисунок 2.11. Структура мотивации архитектора

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

На рисунках 2.12-2.13 представлены мотивационные структуры, касающиеся руководителей отдела разработки и отдела аналитики. Метод построения аналогичен мотивационной структуре системного архитектора. Однако в связи с распространёнными ошибками при разработке новых модулей или доработке текущих было выделено ограничение в виде нехватки компетенций у разработчиков и нехватки специалистов требуемых профилей. В виде требований представляются измеряемые факторы. Основные цели для руководителя отдела разработки являются как сдача проектов и задач в срок, так и минимальное количество ошибок в каждом новом релизе платформы.

Рисунок 2.12. Структура мотивации руководителя отдела разработки



Рисунок 2.13. Структура мотивации руководителя отдела аналитики

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

2.4.4 Точка зрения сотрудничества бизнес-процессов

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

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

На рисунке представлено описание функции «Разработка программного продукта», которая включает в себя бизнес-процессы. На каждый бизнес-процесс назначен исполнитель в виде соответствующей роли. Функцию вызывают 2 события: поступившая задача из GitHub на разработку или задача на доработку модуля платформы или системы в целом. Данные задачи формируют бизнес-объект - «Задачу на разработку», которая включает в себя постановку и требования. Детализация и обсуждение требований осуществляется отделом аналитики и рабочей группой. Спринт и приоритет у задачи определяется руководителем отдела разработки и архитектором системы при необходимости. В процессе разработки используются как локальный репозиторий GitHub, так и различные стенды, на которых располагается та или иная версия платформы. Отдел аналитики и группа разработки вместе с отделом разработки реализуют бизнес-сервисы по настройке и разработке модулей соответственно.

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

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

Функция по настройке и переносу обновлений отвечает за реализацию требований Заказчика и перенос реализованных компонент на стенды Заказчика с помощью GUF-файлов, содержащих произведённые настройки (см. прил. А., рис. 4).

2.4.5 Точка зрения использования приложений

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

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

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

2.4.6 Точка зрения сервисной реализации

Данная точка зрения моделирует, как бизнес-сервисы реализуются базовыми процессами / компонентами приложений. Пример данной точки зрения применительно к описываемым бизнес-процессами и сервисам представлен в приложении к работе (см. прил. А, рис. А.9).

2.4.7 Точка зрения информационной структуры

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

2.4.8 Многоуровневая точка зрения

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

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

2.5 Оценка зрелости архитектуры компании ООО «Гриндата»

Для определения уровня зрелости архитектуры предприятия ООО «Гриндата» была использована описанная в первой главе методика, предложенная META Group - CMM. Результаты анализа представлены в таблице ниже (табл. 2.1).

Критерий	Уровень зрелости	Характеристика предприятия
Связь архитектуры предприятия с миссией организации	Уровень 2 - явная связь с миссией	Миссия компании ООО «Гриндата» заключается в ведении исследовательской деятельности по разработке стратегических компьютерных технологий и программного обеспечения. Компанией находится в постоянном развитии и хаотичном совершенствовании своего продукта - интеллектуальной платформы «GreenData». Несмотря на постоянные изменения в платформе в виде доработок существующих модулей и реализации новых, технологическая архитектура постоянно обновляется главным архитектором компании. Однако формальное описание ключевых бизнес-процессов отсутствует и остальных точек зрения корпоративной архитектуры отсутствует. Несмотря на постоянное обновление имеющейся программной архитектуры, в компании отсутствует чёткое понимание того, какие процессы должны быть формализованы и описаны с помощью моделей. Только некоторые из них структурированы и имеют регламенты, например, процесс по переносу обновлений с одного стенда на другой. Уровень связи архитектуры с миссией не выше третьего, поскольку отсутствует полноценное описание корпоративной архитектуры, а также текущая деятельность не полностью соответствует критерием миссии, главная цель которой - исследовательская деятельность.
Вовлеченность высшего руководства	Уровень 3 - руководство в курсе проекта по построению архитектуры предприятия и поддерживает его	Компанию ООО «Гриндата» возглавляет генеральный директор Архипов Андрей Валерьевич, который осознаёт важность разработки архитектуры предприятия и формализации всех бизнес-процессов, однако на текущий момент главным его приоритетом является построение тесного сотрудничества с клиентами компании. Генеральный директор не принимает непосредственного активного участия в построении архитектуры предприятия, однако поддержка не достаточная.
Участие бизнес-подразделений	Уровень 1 - поддержка проекта по создании архитектуры предприятия до тех пор, пока оно удовлетворяет текущие потребности и решает операционные задачи	На данный момент бизнес-подразделения слабо уведомлены о проекте по созданию архитектуры предприятия, только некоторые участники в курсе существующей структуры компании, а также её технологической архитектуре. Никаких стандартов не предусмотрено.
Описание самого процесса разработки архитектуры	Уровень 2 - процесс по разработки архитектуры предприятия плохо известен ИТ-специалистам и ведётся только главным архитектором и руководителем службы разработки	В компании ООО «Гриндата» не используется ни одна из известных методологий по описанию архитектуры предприятия. На данный момент руководство компании и главный архитектор рассматривают методологию TOGAF в качестве основной, с учетом основных аспектов предприятия. Технологическая архитектура уже описана и поддерживается.
Разработка профилей стандартов	Уровень 2 - стандарты существуют, но не объединены в систему	Компания предпринимает разработку внутренних стандартов, например, в отношении правил по переносу обновлений с помощью GUF-файлов, регламентов по разработке платформы, а также описания технических документов. На веб-портале компании существует формальное описание всех элементов системы, однако часть данных устарела и не обновляется. Освещенность проекта по разработке архитектуры предприятия отсутствует. Частичное моделирование имеющихся бизнес-процессов происходит в нотации BPMN 2.0 на веб-портале компании. Новые сотрудники не проходят предварительное обучение, а сразу идут на проекты, параллельно изучая возможности системы и её технологическую архитектуру.
Распространение описания архитектуры в организации	Уровень 2 - описание архитектуры периодически обновляется, ограниченный доступ	Проект находится в начальный стадии разработки. Среди работников компании о нём знают только руководители проектов, отделов и главный архитектор с генеральный директором.
Контроль за применением стандартов	Уровень 1 - контроль формально не производится	Явные процедуры контроля за соблюдением стандартов отсутствуют.
Управление проектом разработки архитектуры	Уровень 1 - отсутствие стандартов и средств по управлению проектом разработки архитектуры предприятия	Средства и стандарты по управлению проектом разработки архитектуры отсутствуют, однако версия технологической архитектуры постоянно обновляется и проходит проверку главным архитектором. В приоритет ставится решение текущих проблем на проектах, например, срочные доработки модулей или создание новых для удовлетворения требований заказчиков.
Корпоративная архитектура масштаба предприятия	Уровень 2 - большая часть используемых приложений перечислена в реестре приложений, часть моделей основных бизнес-процессов имеет формализованные модели в нотации BPMN 2.0.	В компании существует реестр используемых приложений, где обозначено их позиционирование для бизнеса и актуализировано состояние. Модели некоторых имеющихся бизнес-процессов располагаются на общем веб-портале и создаются с помощью внутреннего редактора, который поддерживает нотацию BPMN 2.0.
Организация закупок в ИТ	Уровень 1 - стратегия закупок ПО отсутствует	В компании происходит хаотичная закупка программных продуктов в зависимости от поступающих требований со стороны заказчика, которые должны быть реализованы. За закупку оборудования на текущий момент отвечают главный архитектор, руководитель отдела разработки, бухгалтер и генеральный директор.

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

Выводы по второй главе

В данной главе была описана компания ООО «Гриндата» и её программный продукт - платформа «GreenData». Основные бизнес-процессы организации были описаны и проанализированы с помощью eEPC диаграмм с использованием инструмента для моделирования бизнес-процессов ArisExpress. Базой для моделирования послужило проведённое интервью с представителями компании, при помощи которого также были выявлены и обозначены существующие проблемы предприятия, после чего был описан процесс формирования текущий архитектуры предприятия - модель «As is», которая послужит базой для совершенствования архитектуры до ожидаемого состояния в соответствии с принципами выбранной методологии TOGAF и Индустрии 4.0, а также проведения анализа несоответствий. Оценка зрелости архитектуры предприятия помогла определить текущее общее состояние корпоративной архитектуры компании.



Глава 3. Построение будущей архитектуры предприятия

В данной главе будет представлено описание состояния «To be» с использованием языка моделирования ArchiMate 3.0. в инструменте Archi, а также проведён анализ между текущим и желаемым состоянием архитектуры предприятия ООО «Гриндата» с целью определения проектов и дальнейшего плана развития его архитектуры.

3.1 Модель архитектуры предприятия «To be» в Archi

Для создания модели «To be» был использован язык моделирования ArchiMate 3.0 в инструменте Archi. В рамках данного подраздела рассматривается модель, описывающая те же точки зрения, что и модель «As is», однако иллюстрирующая будущее желаемое состояние архитектуры предприятия.

3.1.1 Организационная точка зрения

В модели «To be» для организационной точки зрения были выделены новые отделы и роли (покрашены в оранжевый цвет на схеме):

отдел тестирования - поможет снизить нагрузку на разработчиков, которые занимались проведением тестирования своих блоков самостоятельно. В данном отделе были выделены отдельные роли руководителя отдела тестирования, а также роль тестировщика;

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

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

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

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

отдел рекламы - данный отдел должен появиться в Москве, поскольку там проводится основная бизнес-деятельность компании. Для продвижения продукта была выделена роль SMM-специалиста;

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

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

Рисунок 3.1. Организационная точка зрения, часть 1

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

Рисунок 3.2. Организационная точка зрения, часть 3

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

Рисунок 3.3. Организационная точка зрения, часть 2

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

Рисунок 3.4. Организационная точка зрения, часть 4

3.1.2 Точка зрения продукта

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

3.1.3 Точка зрения мотивации

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

Рисунок 3.5. Точка зрения мотивации, часть 1

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

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

Рисунок 3.6. Точка зрения мотивации, часть 2

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

3.1.4 Точка зрения сотрудничества бизнес-процессов

Ранее в модели «As is» компании ООО «Гриндата» были выделены 3 ключевых бизнес-процесса, а именно:

настройка платформы и перенос обновлений;

тестирование и интеграция изменений;

разработка программного продукта.

Таким образом, в модели «To be» данные бизнес-процессы были пересмотрены и перестроены в соответствии с принципами выбранной методологии и Индустрии 4.0.

Первым рассматриваемым бизнес-процессом стал процесс по настройке платформы и переносу обновлений. Данный процесс начинается с события по поступившей задаче на настройку системным аналитикам. В предполагаемой модели для структурирования и дальнейшего анализа работы аналитиков был добавлен процесс по созданию задачи в GitHub и самой системе GreenData, в которой нужно создать модуль работы с заявками/задачами и интеграцию созданных задач из GitHub и обратно, чтобы аналитик, находясь в любой из систем, мог оперативно отслеживать ход выполнения данной задачи. Собираемая статистика из нового модуля в дальнейшем будет подвергаться анализу для выявления ключевых показателей работоспособности. Следует предусмотреть автоматическое создание задачи во второй системе, если в другой она была создана вручную. В процессе по проведению настроек участвует новый бизнес-процесс по согласованию решений, ответственным за который будет отдел по разработке корпоративной архитектуры, поскольку для её развития требуется собирать информацию о частых применяемых решениях для Заказчика. Весь процесс настройки и переносу обновлений обслуживается единым бизнес-интерфейсом GreenData application и бизнес-сервисом GreenData platform (рис. 3.7).

Рисунок 3.7. Точка зрения сотрудничества бизнес-процессов, часть 1

В предполагаемой будущей архитектуре процесс по переносу обновлений будет реализовываться через новый модуль по обновлению стендов, который автоматически будет собирать все сделанные настройки за день и переносить их на другие стенды в требуемом порядке. При переносе обновлений будет также участвовать новый модуль с уведомлениями, который будет сообщать об установке и процедуре обновления стендов, чтобы пользователи, которые ведут работу на стенде, знали, что в данный момент загружаются или собираются обновления. При возникающих ошибках бизнес-процесс должен предусматривать автоматическое уведомление ответственных лиц, которые должны подключиться к процессу обновления для устранения ошибок. Модуль работы с обновлениями должен предусматривать детальную настройку стенда по обновлению для системных аналитиков, чтобы обрабатывать исключительные ситуации, например, когда настройка ещё не готова, но работы по ней уже начались. Процесс по уведомлению заказчика также будет реализовываться с помощью нового бизнес-сервиса, который взаимодействует с единым бизнес-интерфейсом платформы GreenData application. Роль системного аналитика будет нужна только для первичной настройки уведомлений и связи с Заказчиком с помощью обычных средств (Skype, телефон, электронная почта) при необходимости. При возникновении системных ошибок автоматически подключается сервис по их обработке, который автоматически создаёт задачу в системе на портале и в GitHub, куда выкладывает файлы с логом ошибки и её причине по возможности (рис. 3.8).



Рисунок 3.8. Точка зрения сотрудничества бизнес-процессов, часть 2

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



Рисунок 3.9. Точка зрения сотрудничества бизнес-процессов, часть 3

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

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

Рисунок 3.10. Точка зрения сотрудничества бизнес-процессов, часть 4

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



Рисунок 3.11. Точка зрения сотрудничества бизнес-процессов, часть 4

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



Рисунок 3.12. Точка зрения сотрудничества бизнес-процессов, часть 5

3.1.5 Точка зрения использования приложений

...