Какие функции выполняет подразделение, отвечающее за ИT-инфраструктуру?

1. Обеспечение устойчивости бизнеса. ИТ сегодня интегрированы в операционную деятельность большинства организаций. Все прекрасно осведомлены – одни предприятия без ИТ просто встанут, для других сбои чреваты серьезными потерями. Поэтому вопросам обеспечения надежности работы уделяется повышенное внимание. Обеспечение отказоустойчивости мы называем BAU – Business-as-Usual – или, по-русски, просто «Операционная деятельность ИТ».

2. Поддержка планов развития бизнеса. Развитие бизнеса невозможно без развития ИТ. Любая инвестиционная программа включает в себя ИТ составляющую. Эта деятельность, как правило, реализуется через разного рода проекты. Поэтому и называется проектной деятельностью.

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

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

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

С проектами все обстоит еще хуже. Ведь договор поддержки – это действующий контракт, на разрыв которого не каждый вендор готов решиться. Другое дело – новые продажи. Возможность купить ПО и оборудование западного производства практически заблокирована. Да, есть параллельный импорт. Но вот вопрос – кто и как будет выполнять гарантийные обязательства относительно таких продуктов?

Можно с уверенностью сказать, что профессиональная жизнь большинства представителей  ИТ в России разделилась на «До…» и «После 24 февраля». Так что же делать? Очевидно, что на ситуацию надо реагировать. Но вот как?

Что происходит и что с этим делать?

Мы в консалтинге получаем очень много запросов на тему импортозамещения – и очень часто компании испытывают проблемы с тем, чтобы даже просто сформулировать свои запросы – многим кажется, что если начать «импортозамещаться», сразу станет легче. Реальность сложнее.

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

Попробую раскрыть мысль.

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

Выровняем словарь:

Риск — неопределённое событие или условие, которое в случае своего возникновения имеет позитивное или негативное воздействие на репутацию компании, приводит к приобретениям или потерям.

Вероятность риска – вероятность того, что произойдут потери, нежелательный исход.

Влияние риска – величина позитивных или негативных изменений – в случае, если риск реализуется.

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

Перед оценкой рисков...

1. … нужно договориться о границах исследования

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

Например:

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

• Прекращение продаж оборудования или ПО российским компаниям

• Прекращение поддержки и/или ПО западными компаниями

2. …а также о горизонте планирования

Чем дальше горизонт планирования, тем менее точным будет исследование. В нынешних условиях я почти всегда рекомендую период не больше 1 года. С одной стороны, этого будет достаточно для понимания, что делать в следующий бюджетный цикл, а с другой снизит риски того, что какие-то шаги плана станут не актуальны к моменту начала работ. Кстати, важный момент – переоценку этих рисков стоит проводить как можно чаще, потому что в кризисных условиях обстановка меняется очень быстро, и за пару месяцев могут появиться новые угрозы (впрочем, иногда случается и наоборот – какие-то риски теряют актуальность).

Оцениваем риски

0. Переоценка существующего реестра рисков

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

1. Идентификация рисков

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

2. Оценка рисков

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

Если у вас оборудование одной фирмы используется уже 20 лет, вы знаете, что и когда выходит из строя – у вас все получится, и вы с легкостью сформируете бюджет на будущий год, где четко будет расписан план-график закупок необходимого оборудования. Но если у вас СХД, купленная в прошлом году, которую обслуживал вендор, то вам определенно потребуется помощь, чтобы понять, сколько ресурсов она потребует теперь, когда срок поставки ЗИП около полугода, а некоторые запчасти вообще не достать.

Вот пример шкалы для оценки рисков:

Классификация влияния:

• Несущественные (I1): не приносят реальных негативных последствий или не представляют существенной угрозы для организации;

• Малые(I2): имеют небольшой потенциал для негативных последствий. Не более 100 т.р.;

• Умеренные(I3): могут привести к негативным последствиям. Потери – 100-500 т.р.;

• Критические(I4): с существенными негативными последствиями. Потери 500 т.р. – 50 млн р.;

• Катастрофические(I5): с крайне негативными последствиями. Могут вести к банкротству или закрытию компании.

Классификация вероятности:

• Маловероятно (P1): крайне редкие. От нуля до единиц процента;

• Редко (P2): имеют небольшой шанс проявления – не более 10%;

• Вероятно (P3): случаются более одного раза за рассматриваемый период времени. 10-30%;

• Часто (L4): могут произойти с большой вероятностью – 50-80% ;

• Определенно (P5): почти наверняка проявятся и неизбежны – 80-99,9%.

3. Составить матрицу рисков. Наша конечная цель – присвоить каждому риску приоритет. Вероятность и влияние неплохо описывают серьезность каждого риска, но оперировать проще одним значением. Для того, чтобы оценить серьезность риска, используют матрицу рисков. Пример такой матрицы ниже

Что это дает?

Это дает ясное понимание приоритетов. Например, если у вас виртуальная инфраструктура построена в соответствии с лучшими практиками, обновлена недавно, и у вас есть команда, способная эффективно решать 99% задач, то так ли приоритетно ее импортозамещение прямо сейчас?

Обычно на этом этапе ИТ-служба узнает очень много нового. Например, вы можете найти, что вся ваша CRM зависит от работы одного маленького приложения, которое является Единой Точкой Отказа, и которую теперь срочно требуется защищать. Здесь должен признаться, что этот момент исследования – самый любимый.

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

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

• Реестр рисков. Как правило это список рисков и их приоритетов.

• Рекомендации. Это действия, которые необходимо предпринять для того, чтобы снизить вероятность или влияние найденных проблем.

Создаем дорожную карту

К сожалению, реестра рисков с рекомендациями недостаточно для успешной трансформации. Дело в том, что список рекомендаций по снижению рисков формируется без учета существующих зависимостей. Например, очевидно, что нельзя начинать миграцию глобального каталога до тех пор, пока не решен вопрос с MS Exchange, а заменить СУБД часто можно только после того, как будет переписано прикладное ПО. Таких зависимостей и ограничений в большой инфраструктуре десятки.

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

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

Дорожная карта — это план, в котором изложены шаги, которые необходимо предпринять в ответ на те вызовы (риски), которые были найдены на первом этапе. Дорожная карта содержит четкую последовательность действий – какой именно проект нужно реализовать, и в каком порядке. Она является основой для ТЗ, которые потом пойдут в проработку интеграторам для расчета стоимости работ, оборудования и ПО для реализации. Она-то нам и нужна.

Вместо заключения

Да, статья получилась слегка в стиле известного мультяшного философа.

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