Стратегия цифровой трансформации написать, чтобы выполнить
 Скачать 7.32 Mb.
|
|
— это тщательно выверенный архитектурный язык, имеющий целью формальное описание различных аспектов сложных социотехнических систем, включая организации и группы организаций, холдинги, министерства и их подведомственные организации, логистические цепочки и экосистемы. В дальнейшем изложении и примерах используется расширенный состав компонентов (слоев) архитектуры, заимствованный из ArchiMate. Архитектурная практика использует более 60 слоев — своего рода строительных блоков, с помощью которых можно описать текущее или будущее состояние организации. К каждому слою относится набор элементов, например: • Слой Драйверы Может включать такие элементы, как «Импортозамещение», «Цифровизация», Противодействие эпидемии Слой Системы. Его образуют такие элементы, как С, «ЭДО», «Exchange», Кадры, Склад, «Портал». • Слой «ИТ-сервисы». В нем расположены, к примеру, Предоставление списка неоплаченных штрафов, Предоставление данных по адресу регистрации. Слой Подразделения. Слой организационных единиц, попадающих в охват стратегии трансформации. Включает, например, профильные подразделения ОИВ и подведомственные организации. Основные домены и входящие в них слои, которые используются при проектировании архитектуры организации наиболее часто, схематически показаны на рисунке 5.3. 96 TOGAF (The Open Group Architecture Framework) — методология описания архитектуры ИТ и предприятия, в том числе метод ее трансформации, разработанные консорциумом Open Group. Основной акцент в методологии делается на представлении в виде компонентов всех технологий и аспектов жизнедеятельности предприятия. Подробнее см. TOGAF // The Open Group. URL: https://publications.opengroup.org/standards/togaf 97 Термин framework можно перевести как рамочная модель или каркас этологическая структура для классификации и организации информации о сложном явлении или системе ArchiMate — еще один технический стандарт от консорциума Open Group, который поддерживается различными вендорами и консалтинговыми фирмами. ArchiMate Standards // The Open Group. URL: https://publications.opengroup.org/standards/archimate 99 Подробнее о слоях и доменах см. Рудь В. Слои корпоративной архитектуры / Блог Архитектура Digital». URL: Рисунок 5.2. Базовые компоненты (слои) архитектуры в методологии Реализация архитектуры Возможности, решения и планирование миграции Руководство реализацией Возможности Пакеты работ Архитектурные контракты Стандарты Руководства Спецификации Предварительная фаза Видение архитектуры Архитектурные принципы Архитектурные требования Требования Ограничения Предположения Расхождения Стратегия бизнеса Технологиче- ская стратегия Принципы, цели и мотивы бизнеса Видение архитектуры Заинтересо- ванные лица (стейкхолдеры) Организация Организационные единицы Местонахождение Акторы, роли Функции и процессы Бизнес-сервисы, контракты, качество сервиса Процессы, события, контроли, продукты Функции Бизнес-архитектура Мотивация Мотиви- рующие факторы Цели Задачи Метрики, показатели Архитектура информационных систем Данные Приложения Объекты данных Сервисы информационных систем Логические компоненты данных Логические компоненты приложений Физические компоненты данных Физические компоненты приложений Технологическая архитектура Платформенные сервисы Логические технологические компоненты Физические технологические компоненты • элементы мотивации и целеполагания цели действий, принципы деятельности, правовые нормы, драйверы рынка и интересы отдельных стейкхолдеров. РА ЗД ЕЛ 5 | СТРАТЕГИЯ И АРХИТЕКТУРА О РГ АН И ЗАЦ И И РА ЗД ЕЛ 5 | СТРАТЕГИЯ И АРХИТЕКТУРА ОРГАНИЗАЦИИ Таким образом, слой — это архитектурный класса элемент — конкретный представитель или экземпляр класса. 60+ слоев для удобства объединяют в шесть доменов домен стратегии и мотивации домен бизнес-деятельности; 3) домен данных домен ИТ-приложений; 5) домен ИТ-инфраструктуры; 6) домен физической инфраструктуры. В каждый слой войдут десятки, возможно, сотни элементов. Благодаря выделению слоев, их наполнению и связыванию появляется возможность управлять сложностью организации, ее элементами и их отношениями. Осознание архитектуры организации, ее коррекция и развитие не могут происходить автоматически и должны быть чьей-то обязанностью. В организациях уже существуют подразделения, которые управляют отдельными компонентами архитектуры, например службы нормативно-справочной информации, группы ИТ-архитекторов. Цифровая трансформация требует консолидации усилий этих, нередко разрозненных, групп в выделенную группу управления архитектурой в команде ЦТ. Управляемость достигается за счет выполнения группой управления архитектурой следующих обязанностей поддержки целостности каждого слоя назначения владельца слоя создания паспорта для каждого элемента слоя создания паспорта для каждой связи внутри слоя и с элементами других слоев. Откуда аналитики и архитекторы берут элементы для каждого слоя Во- первых, это стандартный результат работы профессионального аналитика. Во-вторых, используются (особенно на стадии зарождения архитектурной практики) референсные модели (например, APQC 100 , TM_FORUM 101 ). В-третьих, зрелая организация, функционирующая на протяжении многих лет, уже, как правило, имеет набор элементов для управления и развития. Однако при трансформации описать существующие слои и их элементы недостаточно, нужно определить их взаимосвязи и направления развития. Чтобы лучше понимать, почему мы используем идею архитектурных слоев в организации, важно помнить, что мы говорим о цифровизации и цифровой трансформации, а значит, опираемся на подходы, работающие в сфере ИТ. Слои архитектуры можно воспринимать по аналогии 100 Process Classification Framework // APQC. URL: https://www.apqc.org/process-performance-management/process-frameworks 101 В ассоциации TM Forum разработан ряд стандартов и рекомендаций. См. TM Forum. URL: https://www.tmforum.org/ Домены Слои • Заинтересованные лица и стороны • Драйверы бизнеса • Цели • Требования и ограничения • Показатели Стратегия и мотивация 1 • Процессы • Подразделения • Функции подразделений • Продукты Бизнес-деятельность 2 • Данные физические • Данные логические • Цифровые двойники Данные 3 • Функции систем • Сервисы и микросервисы • API • Интеграции и потоки данных ИТ-приложения 4 • Оборудование • Производственные линии • Площадки и сооружения • Материалы Физическая инфраструктура 6 • Сервера • ЦОДы • Технологические сервисы • Шины, СУБД ИТ-инфраструктура Рисунок 5.3. Основные домены и наиболее часто используемые слои архитектуры РА ЗД ЕЛ 5 | СТРАТЕГИЯ И АРХИТЕКТУРА О РГ АН И ЗАЦ И И РА ЗД ЕЛ 5 | СТРАТЕГИЯ И АРХИТЕКТУРА ОРГАНИЗАЦИИ с модулями информационной системы модуль данных, бухгалтерский, модуль управления данными, модуль управления кадрами и т. д. Из них, как из элементов конструктора LEGO (которые далее будем называть условно кубиками, мы будем собирать нужную нам систему или организацию. Тот, кто занимается стратегией, должен заранее описать эти кубики и их взаимосвязи. Но это не значит, что он обязан учесть абсолютно все виды кубиков и всевозможные отношения между ними. В зависимости от типа организации, уровня цифровой зрелости и задач, которые должна решить стратегия, можно для начала ограничиться более узким набором строительных элементов. Например, для начала можно: • выбрать и описать один слой (например, составить реестр ИТ- систем с рядом атрибутов, таких как производитель, ответственный, количество лицензий); • построить карту процессов, описать их и провести оптимизацию некоторых из них (например, уменьшить количество шагов согласования отпуска или командировки); • связать слой процессов со слоем систем, определив тем самым наиболее критичные для автоматизации области процессов. Оптимальным вариантом будет выбор для трансформации только некоторых элементов и первого пилотного слоя. Речь не идет обязательно о масштабных технологических изменениях. Первые шаги трансформации в рамках одного-двух слоев можно реализовать быстро и без больших затрат за счет анализа и оптимизации некоторых процессов. В свете цифровой трансформации большинство кубиков будет принимать все более цифровой вид, будь то действие по расчету стоимости услуги или принятие решения о размере страховой суммы. Владельцы процесса или продукта в дальнейшем будут управлять не бизнес-процессами, а функциями систем, интеграциями и, например, правилами в настройках искусственного интеллекта. Рассмотрим, как изменяются несколько слоев архитектуры при ЦТ одной конкретной муниципальной услуги — выдачи муниципальным органом власти разрешения на строительство. В традиционном бумажном формате конкретное структурное подразделение работает на основании столь же традиционного регламента предоставления услуги. При этому него есть полномочия запрашивать информацию как у заявителя, таки у смежных подразделений либо у органов государственной власти (также в бумажном, не цифровом виде. В таблице 5.1 показано, что происходит с элементами слоев архитектуры при переводе этой услуги в цифровой вид. Списки изменений и затронутых слоев и элементов неполны, содержание изменений дано в упрощенном виде. В частности, не учитываются уровни органов государственной власти (федеральный, региональный, муниципальный) и соответствующие им уровни информационных систем. В приведенном примере цифровой Таблица 5.1. Изменение слоев архитектуры при цифровой трансформации муниципальной услуги по выдаче разрешений на строительство Слои и элементы Содержание изменений Подразделения Структурное подразделение органа власти теперь предоставляет и принимает информацию в цифровом виде через веб-формы и API с фокусом на ценность сервиса для его потребителя и анализом поступающей обратной связи в целях непрерывного совершенствования (на клиентоцентричной основе). Процессы • Процесс приема заявлений по нецифровым каналам (письма, личные обращения) переходит в преимущественно онлайн- формат Процесс контроля заявления по форме (полнота представленных данных) переходит от сотрудников к форматно-логическому контролю Процесс принятия решений переходит в алгоритмический автоматический вид и основывается на данных. Функции подразделений Рутинная работа от приема заявлений до вынесения решения переходит от сотрудников к алгоритмам. Вмешательство человека происходит только при обработке отклонений. Это влияет на численность сотрудников, которая необходима для выдачи разрешений. Функциональные границы устраняются кросс-функциональным (межведомственным) взаимодействием, совершенствуется обмен информацией Для пользователей цифрового сервиса запущен чат-бот, поддержка и актуализация базы знаний внесена в число функций подразделения, ранее занятого ручной обработкой заявлений на получение разрешения на строительство. Логические данные Полностью пересматривается логическая структура данных под потребности работы алгоритмов. Создаются ведомственные дата-сеты; они становятся, по сути дела, библиотеками, которые остальные министерства и ведомства могут использовать как конструктор. Компоненты, функции, доступ к реестрам можно масштабировать не только на уровне министерств, но ив субъекты Федерации. Технологическая ИТ-архитектура: ЦОДы Рассчитываются инфраструктурные мощности, необходимые для функционирования сервиса предоставления разрешений с целевыми параметрами доступность (24/7) по всем необходимым средствам всем заинтересованным сторонам мощность (способность обслужить поток заявлений конкретного муниципального образования непрерывность (возможность продолжения предоставления сервиса в ситуации сбоев и высоких нагрузок). Интеграции Запрос информации из смежных ОИВ осуществляется через трансформации очевиден рефакторинг, то есть радикальная переработка слоя деятельности и архитектуры в целом бумажный регламент как единица контроля и управления уходит в прошлое и заменяется набором параметров работы сервиса. Итак, архитектурный подход дает нам набор строительных элементов, с помощью которых может быть описано текущее или будущее состояние организации. Строительные элементы одного типа образуют слой. Таких типов более 60, а значит, более 60 слоев возможно выделить и описать с целью анализа текущего состояния или проектирования будущего. РАЗДЕЛ 5 | СТРАТЕГИЯ И АРХИТЕКТУРА О РГ АН И ЗАЦ И И РА ЗД ЕЛ 5 | СТРАТЕГИЯ И АРХИТЕКТУРА ОРГАНИЗАЦИИ может мгновенно передавать сообщения и файлы на любые расстояния, но будучи соединенным в систему под названием интернет, демонстрирует эмерджентные свойства — способность поддерживать коммуникации между тысячами пользователей сети. Сточки зрения менеджмента хорошая архитектура — это набор архитектурных решений, воплощенных в жизнь в виде реально работающих компонентов предприятия (систем, сервисов, микросервисов, интеграций, ролей, процессов, функций, оборудования, причем эти компоненты выстроены и связаны так, чтобы обеспечить предприятию как работоспособность, таки адаптивность. Классический пример из этой области — строительство дома. Будущий дом — это набор моделей • модель (чертежи и решения) несущих конструкций дома модель (чертежи и решения) электрификации дома модель (чертежи и решения) отопления дома модель (чертежи и решения) водоснабжения и водоотвода дома. Любое изменение одной из моделей приводит к необходимости перепроектирования других моделей. За этим следит главный конструктор здания, выполняющий роль архитектора. Адаптивность дома достигается за счет типизации оборудования и поэтажных планов, за счет повышенного объема закладных каналов для коммуникаций, несущих конструкций, допускающих свободную планировку, расширенных коридоров. Важным аспектом хорошей архитектуры является баланс между детальностью и простотой архитектурной модели, что критично и для стратегии, которая пишется на основании данной архитектуры. С одной стороны, верхнеуровневая (или абстрактная) архитектура легче для понимания и изложения, она быстро передает замысел архитектора. С другой стороны, такая архитектура не позволяет точно предсказать все свойства ириски будущей конструкции организации (или группы организаций) и, как следствие, не подсвечивает трудности в реализации. Детальная архитектура учитывает больше нюансов и фактически может выступать в качестве технического задания на проработку реализации, но она сложна для изучения и понимания, ее тяжело обсуждать широким кругом вовлеченных лиц. При выборе уровня детальности все зависит от рисков и стоимости ошибки. Чем выше цена ошибки, тем более тщательными дорогим будет проектирование, тем более точными и детальными должны быть архитектурные модели. Как правило, вначале проектирования архитектурные модели носят верхнеуровневый характер. Но по мере 5.1.2 Архитектурные решения Еще одним важнейшим компонентом проектирования и создания архитектуры является собственно архитектурное решение — это управленческое решение, согласно которому на предприятии появляется тот или иной элемент (цель, подразделение, функция, процесс, система, объект данных или инфопоток и т. д) с определенным набором свойств и взаимосвязей. Сточки зрения архитектурного подхода управление развитием организации становится последовательностью архитектурных решений. Это могут быть не только решения типа добавить новый элемент, но и решения типа исключить ненужное или модифицировать устаревшее. Например, архитектурным решением может стать появление новой функции госоргана, что повлияет на оргструктуру и должно быть отражено в нормативных документах кроме того, новая функция госоргана повлечет появление новых функций ИТ-систем, новых данных, изменение существующих процессов. Все эти изменения должны быть предметом внимания архитектора. Набор решений предопределяет всю архитектуру организации и связывает цели с фактической реализацией. Таким образом, архитектура — это не только ответ на вопрос что будет меняться, но также и обоснование этого изменения, или ответ на вопрос зачем. Поскольку в архитектуре отражены не только структурные и поведенческие элементы, но и элементы мотивации и целеполагания, проектирование архитектуры позволит получить осознанные ответы на вопросы, что менять, как менять и зачем (для достижения каких именно целей). В каждом решении можно выделить несколько ключевых моментов структуру решения, включая причины принятия решения (указание вышестоящего органа, влияние внешней среды, устаревание объекта и необходимость создания нового заинтересованных в решении лиц объекты решения (элементы предприятия, к которым решение будет относиться само решение его последствия и т. д. Таким образом, набор решений — это набор обоснований, которые проясняют достижимость целей (замысел руководства и архитекторов, спецификации на реализацию и описание реализации (так как любое решение корректируется по факту его реализации). Понятие архитектуры близко к понятию системности. Что делает некую систему системой Инженерный подход утверждает, что система состоит из элементов и их связей, причем подбор элементов и связей обеспечивает системе эмерджентность — свойства и поведение, нехарактерные для составляющих систему элементов. Например, сеть связи состоит из кабелей, коммутаторов, колодцев, розеток, терминалов, инженеров, комнат, компьютеров. Все это по отдельности не 102 Не следует путать управленческое решение с платформенным, описанным в разделе РАЗДЕЛ 5 | СТРАТЕГИЯ И АРХИТЕКТУРА О РГ АН И ЗАЦ И И РА ЗД ЕЛ 5 | СТРАТЕГИЯ И АРХИТЕКТУРА ОРГАНИЗАЦИИ Ключевая интегральная способность всех ИТ-доменов — это реализация концепции DevOps 103 как технологии частой и безопасной поставки предприятию новых функций ее прикладного ИТ-слоя. С одной стороны, частая поставка требует новой культуры разработки, с другой стороны, возникает новый класс программного обеспечения — платформы подробнее см. раздел 6). Разработчики развивают и наращивают функционал платформы постоянно, не прерывая обслуживание пользователей платформы. При этом сервисы платформы могут развивать как штатные разработчики, таки третьи лица, желающие расширять границы бизнес-экосистемы, формирующейся вокруг платформы АРХИТЕКТУРА ПРЕДПРИЯТИЯ КАК ОСНОВА ДЛЯ РАЗРАБОТКИ СТРАТЕГИИ Для каждого из компонентов стратегии, описанных выше в разделе 3.2, можно найти и описать ряд соответствующих слоев неотъемлемой частью написания стратегии является построение архитектуры организации путем описания и проектирования нужных слоев (см. рисунок 5.4). 103 DevOps (DEVelopment OPeration) — повышение эффективности процессов разработки (Development) и эксплуатации (Operation) программного обеспечения за счет их непрерывной интеграции и активного взаимодействия профильных специалистов с помощью инструментов автоматизации. См. Вечугова А. DevOps // Школа Больших Данных. URL: https://www.bigdataschool.ru/wiki/devops работы они обрастают подробностями уточнениями, вариантами решений, предположениями, ограничениями — и это приводит к усложнению моделей. |