5 декабря 2018 г.
В мире бизнеса все чаще звучит словосочетание «цифровая трансформация». С точки зрения ИТ-директора это словосочетание вовсе не является новым: цифровые вычислительные системы вошли в мир корпораций еще в начале 50-х годов прошлого века. И перенос любого операционного процесса в вычислительный центр мог считаться частью цифровой трансформации корпорации — в то время, когда окружающий потребителей мир был окружен аналоговыми информационными технологиями.
С точки же зрения современного бизнеса, цифровая трансформация последних лет — это, по сути, своеобразный показатель динамики изменения корпоративного взгляда на роль ИТ, связанный с целым рядом технологичных моделей и направлений бизнеса: уберизация, финтехи, глубокая и предсказательная аналитика, персонализация предложений, омниканальность и так далее.
Многолетний опыт проведения рабочих семинаров с заказчиками IBM из России и стран СНГ свидетельствует о том, что цифровая трансформация компаний и предприятий — постоянный процесс. Связан он с пониманием высшим руководством того факта, что ИТ является залогом успешного развития бизнеса и поддержания конкурентоспособности. Однако, степень понимания и, как следствие, темпы цифровой трансформации, часто оказываются ниже ожиданий директоров ИТ-служб.
Это связано с тем, что управленцы всегда оценивают планируемые изменения с точки зрения финансовой отдачи, а в мире ИТ не так легко эти показатели спрогнозировать. Более того, типичной ситуацией является инициатива сверху, когда бизнес-менеджер (например, финансовый директор), восприняв из разных источников идею развития ИТ, дает задание руководителю ИТ-подразделения сделать анализ рынка, инструментов и подготовить доклад о том, как улучшится бизнес при внедрении инновационных инструментов.
Вторым основным замедляющим фактором развития ИТ являются неправильно расставленные приоритеты. То есть получается, что при оценке состояния дел с ИТ в компании неверно определяются области, требующие немедленного внимания или же планомерного совершенствования. Опять же, речь не идет о нехватке компетенций в ИТ-службе. Просто для того, чтобы на управленческом уровне понимать происходящие в доменах ИТ-архитектуры и между ними процессы, надо обладать достаточно глубокими инженерными и техническими познаниями.
Какой руководитель будет в достаточной мере разбираться в вопросах несоответствия форматов данных или сетевых протоколов, проблемах правильной работы драйверов, в том, как передается управление в различных типах кластеров в случае аварии основного и так далее? Он скорее всего скажет ИТ-директору: «Мы только что купили мощные серверы, вы ведь сами говорили, что нужны помощнее. А теперь приходите еще с какой-то виртуализацией систем хранения. Деньги вам дали? Оборудование закупили? Идите, работайте, ожидаем скорой отдачи».
Если такие вещи происходят на примере типовых доменов ИТ-архитектуры, то в случае добавления в нее нового функционала, связанного, например, с цифровой трансформацией поддержки клиентов, ситуация с приоритезацией еще хуже. Как тут быть?
IBM в рамках своей экосистемы работает с десятками тысяч клиентов по всему миру, охватывая практически все индустрии от банков, телекоммуникаций и ритейла до нефтяных производств и крупных горнодобывающих предприятий. Этот опыт тщательно анализируется, выбираются так называемые лучшие методики, результаты обобщаются и на их основании вырабатываются референсные архитектуры.
Такой подход позволяет совместно с заказчиком провести объективное состояние ИТ-инфраструктуры и правильно расставить приоритеты задач его развития. В ходе обследования текущие бизнес-приоритеты (по шкале «низкий», «средний», «высокий») сопоставляются с требуемыми усилиями по аналогичной шкале. Получается матрица размером 3×3 (см. пример реального обследования ниже), в правом верхнем углу которой находятся наиболее приоритетные задачи, требующие значительных усилий. Задачи же, тоже требующие больших усилий, но не имеющие высокого приоритета со стороны бизнеса со временем могу стать неотложными.
Обведенный центральный элемент со средними приоритетами и усилиями очень важен при анализе. Если он пуст, это тревожный признак, означающий недостаточную степень проработки плановых задач, которые должны идти в обозначенных рамках и с заранее выделенными ресурсами.
Такого рода схемы строятся в результате обследования, и, как показала практика, в подавляющем большинстве случаев очень четко отражают ситуацию с проектами. Это как бы рентгенограмма ИТ-архитектуры предприятия. Такое визуальное отображение оказалось довольно полезным, потому что оно понятно как техническим специалистам, так и управленцам, и при этом отражает реальную картину.
Обсуждение вместе с бизнес- и ИТ-персоналом приоритетов и усилий по данной методике позволяет достаточно точно определить самые важные и первоочередные направления развития, но при этом не забыть и общую картину, доводя до бизнес-руководства ситуацию с теми направлениями, которые попадали в слепую зону.
Когда направления и приоритеты определены, остается перевести цифры условных оценок развития по шкале в дорожные карты, которые позволят продвинуться на нужное количество шагов в реальном ИТ-домене. Подобные шкалы оценки развития используется почти консалтинговыми компаниями в более-менее одинаковом формате. Чаще всего на шкале представлены фазы «1 — начальное состояние», «2 — средняя степень развития», «3 — зрелое состояние». Шкала может насчитывать
Итак, мы определили ситуацию «как есть», то есть на настоящий момент по всем доменам, определили разрыв с желаемым состоянием и, наконец, определили приоритеты и усилия (направления, по которым нужна трансформация в первую очередь). На рисунке 2 показано, как это отражается в графическом виде.
Рис. 2. Графическое представление типовой ситуации с ИТ на предприятии. Зеленым показано желаемое состояние, желтым — уровни развития доменов в настоящий момент. Каждая ветвь радара отражает состояние по определенному домену, например, «Service automation» (автоматизация сервисов). В этом случае его уровень в настоящий момент 0,8 по пятибалльной шкале, а желаемое состояние — 2,0. Красным обведены приоритетные направления.
Данный пример взят из проекта прошлого десятилетия, и количество доменов здесь «всего» 14. Понятно, что с изменениями на рынке и в технологиях методика оценок тоже развивалась. В настоящий момент существует 9 крупных разделов (доменов) ИТ-инфраструктуры, в каждом из которых свои подразделы, всего 26 субдоменов. Среди них такие, о которых в начале
- использование внешних социальных сетей;
- применение API;
- полная информация о клиенте;
- предсказательная аналитика.
Тем самым напрашивается вывод, что появление целого набора новых доменов и привело к возникновению понятия цифровой трансформации, причем как органического развития ИТ-архитектуры.
Важно еще понять: как от приоритетов, усилий и желаемой общей картины по направлениям перейти к конкретным проектам и дорожной карте? Упоминаемые в статье оценки по шкале развития отражают факт использования реальных технологий по каждому из доменов. Таким образом, зная конечную точку развития по шкале, можно сказать, какие технологии, какой инструментарий необходимо внедрять. При этом технологии не привязаны к какому-то конкретному вендору, речь идет о классах систем и технологий.
Умение рассматривать ИТ-архитектуру предприятия на самых разных уровнях, не теряя общего понимания и связи элементов между собой и есть секрет успеха применяемой методологии. Популярное и зачастую расплывчатое понятие цифровой трансформации превращается в рабочий процесс, благодаря объективной оценке ситуации и выработки детальных планов развития, которые поймут и технические, и финансовые специалисты.
Источник: Александр Дмитриев, бизнес-консультант Клиентского центра IBM в Москве
