Лоскутная цифровизация, или почему проекты не двигаются

Меня зовут Дмитрий Исаев, я корпоративный архитектор компании Инфостарт.

В ИТ я уже более 30 лет, и с решениями 1С я работал еще со времен, когда они были под DOS, с синим интерфейсом на черном фоне. Имею опыт как собственного бизнеса, так и работы в найме. Причем после руководства собственной компанией я переехал в Новосибирск и устроился там в местный франчайзи сервис-инженером, где со временем вырос до директора. Ну а во франчайзи приходится заниматься всем – я был и аналитиком, и разработчиком, и РП, и тимлидом продуктовой разработки, приводил в порядок локальные сети и бизнес-процессы. Соответственно, есть и проектный, и продуктовый опыт.

Последний год я работаю корпоративным архитектором в Инфостарте, и именно этот опыт во многом стал отправной точкой для моего доклада. Я поделюсь своим видением в роли корпоративного архитектора – почему цифровизация получается «лоскутной», а проекты буксуют.

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

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

Это и подтолкнуло меня разобраться, почему так происходит.

В первую очередь я собрал теорию о том, какие процессы изменений вообще существуют и какой смысл сейчас вкладывается в понятия «автоматизация», «цифровизация» и «цифровая трансформация»:

• Автоматизация – это замена ручных операций системой

• Цифровизация – улучшение процессов с помощью технологий

• Цифровая трансформация – изменение самой бизнес-модели, когда она становится больше цифровой, чем физической.

Дальше я углубился в тему и расширил эту базовую «тройку» дополнительной детализацией.

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

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

Если разложить все это по уровням, получается следующая картина:

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

• цифровизация – процессов,

• а цифровая трансформация затрагивает уже бизнес-модель в целом.

Поэтому цифровая трансформация несет наибольшие риски – она влияет на всю компанию.

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

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

Следующий вопрос, который меня заинтересовал: во сколько компании может обойтись «лоскутность», и что именно увеличивает расходы? Я пришел к следующим выводам:

• Фрагментированные изменения резко увеличивают затраты на поддержку информационных систем и интеграций между ними. В итоге ресурсов на развитие практически не остается, и компании вынуждены обращаться к интеграторам. За последний год у меня было множество встреч с заказчиками – от среднего до крупного бизнеса. И картина повторяется: у них есть собственные ИТ-департаменты, иногда это сотни специалистов, но при этом они все равно приходят к внешним подрядчикам. На вопрос «зачем?» отвечают просто: внутренние команды в основном заняты поддержкой и лишь частично развитием, а бизнес хочет меняться быстрее.

• При этом скорость внедрения практически любых продуктов низкая, и это не зависит от используемых технологий – будь то 1С или что-то другое, везде примерно одинаково медленно.

• Еще одна серьезная проблема – это данные. Даже если они собираются автоматически, наличие множества источников дает большую вероятность, что единой «правды» не получится.

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

На тему разнородности данных есть интересный кейс. На одной из отраслевых конференций ИТ-директор группы «Самолет» рассказывала, как они подошли к цифровизации. Они начали собирать данные из разных источников, настроили ETL-процессы, подключили нейросети и сделали чат-бота, которому можно задавать бизнес-вопросы.

Но когда они задали боту вопрос: «Какая себестоимость бетона на конкретном объекте», тот ответил: «Вам какую цену сказать?» – «А у тебя что, их несколько?» – «Да, несколько» – «Сколько?» – «Восемнадцать».

С одной стороны, это смешно, с другой – очень точно отражает реальность: данных много, но единой истины нет.

В целом ситуация на проектах часто напоминает басню Крылова про лебедя, рака и щуку.

У бизнеса, ИТ и производства разные цели:

• Бизнесу важно быстро выводить новые продукты и сервисы, ему критичен time-to-market.

• ИТ стремится к стабильности, часто живет в рамках SLA.

• А производству нужно, чтобы все просто работало без сбоев.

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

Все по-своему правы. Но векторы развития, куда двигать ИТ-системы и ИТ-инфраструктуру для бизнеса – разные.

Все это тормозит движение вперед.

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

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

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

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

По моим наблюдениям, основанным на общении с ИТ-директорами:

• даже у малого бизнеса может быть от 5 до 40 информационных систем;

• у среднего – от 50 до 100;

• а у очень крупных корпораций и банков – до нескольких сотен, например, у Газпрома – не меньше 500.

Причем рост идет в двух направлениях:

• с одной стороны, в компаниях внедряются новые глобальные системы – ERP, CRM, BI и т.д.;

• с другой – углубляется функциональность уже существующих, к которым добавляются отраслевые модули.

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

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

Кризис становится моментом истины.

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

Сложность информационных систем и процессов начинает тормозить бизнес, а ему нужно работать быстрее

Причем проблема сложности уже не касается конкретных систем или проектов – сложность стала системной.

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

Причины лоскутной цифровизации

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

Я выделил для себя пять основных причин.

Первая – нет единой архитектурной политики. Решения принимаются локально в подразделениях без учета их влияния на общий процесс и общий ландшафт.

В результате получаем фрагментацию и сложности с интеграциями.

Для примера, частая история: в подразделении закупают для собственных нужд локальный Битрикс24. Изначально используют его для учета задач, но потом вдруг решают, что там же будут еще и все документы согласовывать. Это приводит к появлению в контуре предприятия еще одной системы, с которой требуется большое количество дополнительных интеграций – айтишники в шоке.

Второе – стратегии не связаны с портфелем.

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

Я считаю, что это «красный флаг» о том, что ИТ вообще не занимается развитием, а выполняет исключительно функции поддержки.

Третья проблема – конкурирующие продуктовые инициативы.

Иногда бывает, что в компании внедрено несколько CRM: сотрудники отдела продаж работают в Битрикс24, он с сайтом интегрирован, маркетологи делают рассылки через свою систему, еще одно подразделение вообще amoCRM использует. Иногда наличие такого зоопарка оправдано, но чаще приводит к избыточной сложности, а с последствиями приходится разбираться ИТ.

Четвертая причина – наследие старых систем. Такие решения несут серьезные риски: часто неизвестно, у кого находится ключевая экспертиза, и нередко это один человек. Если этот человек недоступен – компания оказывается в уязвимом положении.

Я знаю одно крупное учебное заведение, у которого более 25 лет весь внутренний учет велся в собственной легаси-системе. Эту систему поддерживал один человек – пожилой уже пенсионер старше 70 лет. А потом он умер.

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

Пятая причина – отсутствие платформенной модели.

Если в построении контура автоматизации нет целостного подхода, это приводит к росту совокупной стоимости владения (TCO) и усложняет интеграции. Поэтому во многих компаниях уже понимают, что все потоки данных нужно систематизировать и структурировать. Средний и даже крупный бизнес выбирает как платформу «1С».

Как диагностировать все эти проблемы?

Попробуйте проверить свою ситуацию по приведенному на слайде списку – поставьте оценку, насколько сильно у вас проявляются перечисленные проблемы. Чем больше – тем хуже.

Почему компании не могут разобраться сами

Казалось бы, все эти проблемы вполне решаемы, но тогда почему компании не могут справиться с ними сами?

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

• Бизнес понимает процессы.

• ИТ отвечает за системы и инфраструктуру.

• Аналитики работают с данными.

• Добавляется зависимость от подрядчиков – и ситуация еще больше усложняется.

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

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

Как появляется потребность в диагностике

Когда ИТ-ландшафт компании становится слишком сложным, начинает казаться, что чинить информационные системы дальше бессмысленно.

Возникает тупик. Становится вообще непонятно, куда двигаться дальше, и ответа на вопрос, чем ИТ может помочь бизнесу, у компании нет.

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

• Мы собираем целостную картину, восстанавливая недостающую информацию.

• Выявляем противоречия.

• Убираем искажения, помня, что у каждого «своя правда», и в системе может быть 18 вариантов ответов на один и тот же вопрос. В том числе, из-за саботажа.

• Снижаем риски, разбираясь в реальных зависимостях между системами, проектами и данными.

• И только после этого принимаем дальнейшее решение о развитии.

Главная цель такой диагностики – восстановить управляемость ИТ. И компании сами со временем приходят к пониманию этой проблемы.

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

Пусть вас не смущает слово «аудит»:

• задача не в поиске виноватых;

• мы не проверяем работу подрядчиков – а если и делаем это, то аккуратно и адекватно, все-таки кодекс этики франчайзи был написан не зря;

• выступаем в роли «врача» – ставим диагноз и даем рекомендации.

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

Что помогает вернуть управляемость

В результате аудита мы обязательно вырабатываем так называемые quick wins – решения, которые могут дать быстрый эффект при минимальных затратах.

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

• Первое, что мы рекомендуем – это сформировать карту всех цифровых продуктов и проектов, чтобы понимать, что вообще в компании происходит

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

• Третье – это перейти к платформенной архитектуре, чтобы новые решения не увеличивали хаос. У нас должен быть приоритет относительно основной системы, вокруг которой строится ИТ-ландшафт – понятно, что в нашем случае это чаще всего 1С.

• Четвертое – нужны механизмы согласования решений. Хорошая практика – наличие в компании архитектурного и стратегического комитетов, когда за стратегию отвечает бизнес, а за архитектуру – ИТ. Это несложно запустить, и это работает.

• И не забываем внимательно оценивать новые инициативы – не нарушат ли они существующие процессы в системе.

Если обобщить, то главный вывод этой истории такой:

• Лоскутная цифровизация – это не чья-то ошибка, а естественный результат усложнения цифровой среды.

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

• Вроде все нужные компетенции внутри компании есть, но они распределены между разными людьми, и целостной картины мы не видим.

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

Только в этом случае ваши «лебедь, рак и щука» начнут тянуть в одну сторону.

И напоследок… немного рекламы

Архитектурный аудит – это регулярная услуга в рамках нашего направления «Инфостарт.Консалтинг», где мы наравне с технологическими проектами теперь предлагаем еще и наши продукты и сервисы.

Архитектурный аудит ИТ-ландшафта

Наводим порядок в системах и возвращаем управляемость.

Подробнее

Вопросы и ответы

Как понять, какие задачи стоит выносить на проектно-архитектурный комитет, а какие – нет?

Для отбора таких задач нужен определенный фильтр. В идеале все инициативы должны попадать в единое «окно» – неважно, через какую систему (Service Desk или что-то другое).

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

Вы сказали, что многие проблемы возникают, поскольку ИТ проще внести изменения в код, чем изменить поведение сотрудников. Можете раскрыть эту мысль подробнее?

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

А что делать, если ИТ-директора в компании нет, и все ИТ-инициативы приходится «продавливать» через генерального, у которого один вопрос: сколько прибыли это принесет?

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

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

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

По сути, они сами себе делают хуже, и когда-нибудь им это аукнется – разве что не сразу.

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

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.