Инвентаризация ИТ и бизнеса: системы, процессы, данные, функции

01.09.2021

Примечание: это проект статьи по инвентаризации ИТ-ландшафта.

Сущность инветаризации расскрыается как для бизнес-компонентов (процессы, подразделения, информация), так и для компонентов ИТ-архитектуры (системы, функции, интеграции). В настоящее время тема учета систем обостряется в связи с планированием деятельности по импортозамещению. Услуга "Марк Аврелий" по инвентаризации описана здесь >>>

Перед прочтением рекомендуется ознакомиться со статьей "Слои корпоративной архитектуры"

Далее по тексту описывается состав данных для сбора в целях инвентаризации ИТ-ландшафта в связке с бизнес-процессами. Привязка к процессам нужна для демонстрации сопряжения бизнес- и ИТ-архитектуры. Если такая демонстрация не нужна, то вы либо крайне далеки от цифровизации или вы уже цифровые на 100% и потому вопрос процессной архитектуры для вас вторичен. Обычно сопряжение бизнес- и ИТ-архитектуры - это ключевой вопрос эффективности ИТ-службы и инвестиций, вложенных в ИТ.

1. Принципы, на которых строится ИТ-архитектура.

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

Ориентация на ПО российского производства.
Интеграции – только через шину.
СУБД: Oracel, MySQL, PostreSQL.
SOA-подход к компонентизации.
Ориентация на микросервисную архитектуру приложений там, где это критически важно.
Использование при автоматизации процессов BPM-движка от вендора ххххх.
Максимальное использование линейки продуктов 1С.
Соблюдение в цикле проектирования методологии водопадного проектирования или итеративной разработки (Agile).
Размещение ПО только в собственных ЦОД.

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

2. Домен ИТ.

В ходе инвентаризации ожидается получить следующую информацию по компонентам ИТ-домена.

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

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

2.2. По каждой системе: Документация.

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

2.3. По каждой системе: Компоненты системы.

Компонент системы – единица самостоятельного развертывания и обновления (и доработки) в составе системы, например, драйвер, библиотека, мобильное приложение, модуль, СУБД, сервис и т.п.

2.4. По каждой системе: «Объекты данных», которыми оперирует прикладная информационная система.

Объект данных (информационная сущность, документ/форма в системе) – устойчивая информационная единица, реализующая в виде своих атрибутов модель одного или группы родственных объектов реальности: договор, клиент, адрес, подстанция, счет, долг, начисление, платеж, помещение, проводка, оборудование, агрегат, вышка, кабель, муфта, сотрудник, отдел, должность… В терминологии 1С (которая сейчас начинает доминировать в ряде компаний) информационные сущности могут называться так: справочники, документы, списки.
По каждой сущности необходимо указать ее ключевые прикладные атрибуты, определяющие суть сущности.
По всем информационным сущностям одной системы нужно предоставить схему их взаимосвязи с краткими подписями смысла (семантики) у связей.

2.5. По каждой системе: «Функции ИС» или операции с информационными сущностями.

Функция ИС - что система делает со своим данными: принимает их с экранов пользователей, вычисляет, преобразовывает, формирует, сохраняет, логирует, передаёт, принимает и т.п. Примеры системных функций см. в нашей статье >>>
Функция в своем наименовании должна содержать имя и имена объектов данных. По каждой функции указывается ее статус: эксплуатируется, разрабатывается, упразднена.
Более удобно функции заменить понятием МЕТОДЫ объектов. В таком случае структурирование функционала может быть существенно улучшено, но для этого следует сначала зафиксировать логическую модель данных.

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

2.6. По каждой системе (паре систем): «Интеграционное взаимодействие».

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

2.7. По каждой системе: «API-методы».

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

2.8. По каждой «Функции» и каждому «Объекту данных» и каждой «Интеграции»: привязка функций, объектов данных, интеграций информационных систем к транзакциям в бизнес-процессе.

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

Примечание: Названия (коды, если есть) процессных транзакций желательно соотносить с названиями из п.3.2

3. Домен БИЗНЕСА.

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

3.1. Перечень бизнес-процессов

Бизнес-процесс - упорядоченная в виде потока цепочка (последовательность) действий. Поток действий структурируется через материальный или информационный поток промежуточных результатов, или поток задаётся цепочкой распоряжений (control flow).
По каждому бизнес-процессу необходимо указать: название, номер или ID, владелец, начальное событие или набор входов, конечные результаты процесса, наличие регламента.

3.2. Перечень действий бизнес-процесса.

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

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

3.3. Для каждого шага необходимо указать:

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

Для структурирования ответов рекомендуется использовать шаблоны, например, созданные в MS Excel или предоставляемые системой СиММА или иной системой класса Enterprise Architect.

Какие еще компоненты доступны для инвентаризации в доменах бизнеса и ИТ? - интеграционные потоки, подразделения, документы, события и прочее ... - см. методичку по Архимейт 2.1 (можно смотреть и Archimate 3.1, но для начала лучше взять версию 2.1). Каждый компонент архитектуры образует в инвентори-системе (например, СиММА) каталог элементов (каталог паспортов), который мы аллегорически называем СЛОЙ. О слоях см. отдельную статью "Сущность архитектурного слоя".

Не имеет значения рассматриваем мы государственную компнию или частную. Основы оранизованности у всех одинаковые. Однако, конечно в гос.компаниях есть своя специфика:

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

4. Прочие разделы по инвентаризации: методы, инструменты, методологии

Прим: раздел 4 находится в разработке.

О чем будет раздел: Сущность процесса инвентаризации: подходы, методы, форматы сбора данных, инструменты (репозитории), например, СиММА.

Список статей