Инструменты методики АЦТ, часть 41: управление бизнес-системами (Business System Management), low-code-платформы (Low-code Platform), решения с открытым исходным кодом (Open-source) и дополненная реальность (Augmented Reality)

Это сорок первая статья цикла по инструментам методики «Аккордная цифровая трансформация». Завершаем группу G «Цифровые технологии трансформации» подгруппой G3 и открываем G4 «Разработка и инновации» — инструменты G3-05, G4-01, G4-02 и G4-03.

Четыре инструмента этой статьи завершают группу G двумя разными путями создания программных решений. Управление бизнес-системами (G3-05) наводит порядок в уже существующем ландшафте корпоративных систем. Low-code-платформы (G4-01) позволяют создавать новые приложения силами самих бизнес-подразделений, минуя традиционную разработку. Решения с открытым исходным кодом (G4-02) используют и дорабатывают программное обеспечение, созданное внешним сообществом. Дополненная реальность (G4-03) выносит цифровые данные непосредственно на физическое оборудование. Трудоемкость составляет 40 часов у управления бизнес-системами и 30 у дополненной реальности — оба отнесены методикой к сложным инструментам, — и по 24 и 26 часов у low-code-платформ и открытого кода, отнесенных к средним. В сумме 120 часов.

G3-05 — Управление бизнес-системами (Business System Management, BSM)

Откуда появился инструмент. Дисциплина выросла из управления IT-услугами, сложившегося в Великобритании на основе библиотеки передового опыта ITIL, которую с 1989 года развивало правительственное агентство CCTA. Первоначальная задача состояла в том, чтобы упорядочить работу IT-подразделений самих по себе, безотносительно к тому, как эта работа связана с результатами бизнеса. По мере роста числа корпоративных систем и усложнения связей между ними обозначилась нехватка более широкого взгляда: нужен был подход, увязывающий состояние IT-ландшафта не с внутренними показателями подразделения, а с целями и конкурентоспособностью предприятия в целом. Международный стандарт ISO/IEC 20000, принятый в 2005 году, закрепил на уровне отраслевого стандарта требование такой увязки. Единого автора у дисциплины, как и у большинства практик управления, нет: она формировалась параллельно в консультационных компаниях и корпоративных IT-службах на протяжении 1990-х и 2000-х годов.

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

Масштаб проблемы, которую вскрывает системный анализ ландшафта, виден на исследовании, охватившем сотни организаций.

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

Границы применимости. Инструмент применим на предприятиях, где IT-ландшафт складывался постепенно, без единой архитектуры, и число систем выросло настолько, что взаимосвязи между ними перестали быть очевидными: в холдингах, на предприятиях после слияний, при длительной истории точечных внедрений. По методике это сложный инструмент. Первое ограничение носит организационный характер: подразделения, годами использовавшие собственные системы, воспринимают попытку их упорядочить как посягательство на самостоятельность. Второе — непрерывность цикла: анализ, планирование и внедрение дают эффект только при регулярном повторении, а однократный проект быстро теряет актуальность по мере появления новых систем. Третье — риск избыточной централизации: попытка свести весь ландшафт к единому решению без учета специфики отдельных подразделений создает новые неудобства взамен прежних. Управление бизнес-системами опирается на управление данными (H1-01) в части наведения порядка в данных и связано с системами для управления производственными процессами (G1-03) как с одним из типов систем, требующих упорядочивания.

Чек-лист перед внедрением управления бизнес-системами:

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

Типовые ошибки:

• Отсутствие полной инвентаризации. Анализ ведется по системам, известным IT-службе, а внедренные подразделениями самостоятельно остаются вне поля зрения. → Проводить инвентаризацию с участием всех подразделений, а не только IT-службы.
• Разовый проект вместо цикла. Анализ и оптимизацию проводят один раз и не возвращаются к ним. → Встраивать регулярный пересмотр ландшафта в постоянную практику.
• Централизация без учета специфики. Все подразделения переводят на единое решение без учета их различающихся потребностей. → Сохранять оправданные различия там, где они действительно нужны.
• Изменения без оценки результата. Внедрение проводится, но эффект впоследствии не измеряется. → Замыкать цикл мониторингом и оценкой достигнутых результатов.

G4-01 — Low-code-платформа (Low-code Platform)

Откуда появился инструмент. Термин предложили в 2014 году аналитики компании Forrester Research Клэй Ричардсон и Джон Раймер в отчете «New Development Platforms Emerge For Customer-Facing Applications»; сама технология к этому моменту существовала уже десятилетиями. Ее предшественниками были инструменты быстрой разработки приложений, вошедшие в обиход в 1980–1990-е годы, и язык программирования четвертого поколения, упрощавший описание того, что должна делать программа, в отличие от подробного описания того, как именно это делать. Оформление подхода быстрой разработки приписывают Джеймсу Мартину, изложившему методологию в 1991 году. Отличие low-code от более ранних инструментов быстрой разработки в том, что платформы этого класса рассчитаны не только на профессиональных программистов, но и на сотрудников бизнес-подразделений без специальной подготовки.

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

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

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

Границы применимости. Инструмент применим для создания приложений, автоматизирующих задачи конкретного подразделения, не требующих экстремальной производительности и не критичных для безопасности предприятия в целом: учет, согласования, внутренние рабочие процессы. По методике это инструмент средней сложности. Первое ограничение связано с зависимостью от поставщика платформы: приложения, созданные на low-code-платформе, обычно непереносимы на другую платформу без существенной переработки. Второе — предел сложности: платформа хорошо справляется с типовыми задачами и теряет эффективность там, где логика становится нетиповой и объемной. Третье — управляемость: рост числа приложений, созданных сотрудниками без технической подготовки, требует отдельного контроля, чтобы такие приложения не превратились в бесконтрольную теневую IT-инфраструктуру. Low-code-платформы опираются на облачные вычисления (G3-01) как на инфраструктурную основу и служат одним из способов реализации решений, спланированных при управлении бизнес-системами (G3-05).

Чек-лист перед внедрением low-code-платформы:

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

Типовые ошибки:

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

G4-02 — Решения с открытым исходным кодом (Open-source)

Откуда появился инструмент. Термин предложила Кристин Петерсон, президент исследовательского института Foresight, на стратегическом совещании 3 февраля 1998 года в Калифорнии, вскоре после того как компания Netscape объявила о раскрытии исходного кода своего браузера. Участники совещания искали замену прежнему обозначению «свободное программное обеспечение», которое постоянно вызывало путаницу: слово «свободное» новички понимали как указание на бесплатность, тогда как речь шла о свободе доступа к исходному коду. В том же месяце была основана организация Open Source Initiative, взявшая на себя распространение нового термина и определение критериев, которым должна соответствовать открытая лицензия. Сама практика совместной разработки программ существовала намного раньше термина, однако именно 1998 год закрепил за ней единое, понятное бизнесу название.

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

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

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

Границы применимости. Инструмент применим там, где предприятие готово взять на себя часть работы по интеграции и поддержке взамен экономии на лицензиях: в разработке программного обеспечения, серверной инфраструктуре, аналитических платформах. По методике это инструмент средней сложности. Первое ограничение затрагивает совместимость с окружением: переход на открытые решения оправдан только тогда, когда партнеры, клиенты и смежные системы способны работать в том же формате. Второе — стоимость поддержки: открытое программное обеспечение бесплатно по лицензии, но не бесплатно по эксплуатации, и экономия на лицензиях может обернуться ростом затрат на собственных специалистов или подрядчиков. Третье — устойчивость проекта сообщества: развитие открытого решения зависит от активности его сообщества, и не каждый такой проект сохраняет эту активность на протяжении многих лет. Решения с открытым исходным кодом опираются на облачные вычисления (G3-01) как на инфраструктуру размещения и служат материалом для доработки при построении low-code-платформ (G4-01) собственными силами.

Чек-лист перед внедрением решений с открытым исходным кодом:

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

Типовые ошибки:

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

G4-03 — Дополненная реальность (Augmented Reality, AR)

Откуда появился инструмент. Первое устройство, совмещавшее изображение реального мира с компьютерной графикой, создал в 1968 году Айвен Сазерленд: громоздкий шлем, подвешенный к потолку из-за собственного веса, за что получил прозвище «Дамоклов меч». Сам термин «дополненная реальность» предложили в 1990 году сотрудники Boeing Том Кодел и Дэвид Мизелл, работавшие над заменой громоздких фанерных стендов со схемами электропроводки, по которым рабочие вручную собирали жгуты проводов для самолетов. Они предложили шлем с полупрозрачным дисплеем, проецирующим схему прокладки проводов прямо на многоразовую доску-основу, вместо того чтобы использовать отдельный размеченный стенд для каждой модели самолета. Свою разработку авторы формально описали в статье 1992 года.

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

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

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

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

Чек-лист перед внедрением дополненной реальности:

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

Типовые ошибки:

• Применение к редким операциям. Контент разрабатывают для задач, которые выполняются слишком редко, чтобы окупить затраты. → Отбирать операции по частоте повторения и цене возможной ошибки.
• Неточная привязка к объекту. Цифровое изображение не совпадает с реальным положением деталей. → Проверять точность привязки в реальных условиях применения.
• Игнорирование эргономики. Оборудование выбирают без учета условий длительного использования. → Оценивать эргономику применительно к условиям конкретного рабочего места.
• Устаревший контент. Схемы не обновляются при изменении конструкции изделия. → Устанавливать процесс регулярного обновления данных.

Резюме

Четыре инструмента этой статьи завершают группу G двумя разными подходами к тому, как в организации появляется новое программное решение. Управление бизнес-системами наводит порядок в уже существующем ландшафте. Low-code-платформы и решения с открытым исходным кодом предлагают два разных пути создания нового: разработку силами тех, кто ближе всего к задаче, и заимствование готового кода вместо разработки с нуля. Дополненная реальность выносит цифровые данные за пределы экрана, прямо на физический объект. Общее условие для всех четырех состоит в том, что техническая состоятельность решения не гарантирует его судьбу внутри организации. Переход Мюнхена на открытое программное обеспечение работал технически безупречно годами, но был отменен по организационным причинам, а управление бизнес-системами регулярно обнаруживает системы, о существовании которых руководство даже не подозревало. Дополненная реальность, в свою очередь, показывает и обратный случай: одна и та же задача, для которой тридцать лет назад появился сам термин, современными средствами решается с измеримым и повторяемым результатом. Суммарная трудоемкость в 120 часов ниже, чем у ядра искусственного интеллекта из тридцать девятой статьи, что отражает характер группы: здесь предметом служат способы организации разработки, а не сами технологии распознавания и прогноза. Для промышленного предприятия отсюда следует практический вывод: выбор между разработкой, покупкой готового решения и заимствованием открытого кода определяется не только техническими характеристиками, но и тем, впишется ли решение в привычки и связи организации, а не только в ее вычислительную инфраструктуру.

В следующей статье цикла продолжим группу H подгруппой H2 «Аналитика и визуализация»: разберем инструменты визуализации данных, бизнес-аналитику и прогнозную аналитику.