Между гибкостью и деградацией. Как преуспеть в эпоху перемен?

Вызов для ИТ-директора
С наступлением событий 2022 года ИТ-директор столкнулся с двумя ключевыми вызовами, которые не меняются и по сей день: перенос инфраструктуры на новые отечественные платформы и поддержка отказоустойчивости.
При этом внутренняя ИT-служба заказчика обычно фокусируется на эксплуатации уже имеющейся инфраструктуры и обеспечении непрерывности бизнеса. Даная задача сама по себе стала вызовом в условиях нестабильной работы зарубежных решений и слабо прогнозируемых поставок. Но если говорить о внедрении новых информационных систем и модернизации — на это у компаний часто недостаточно штата.
Таким образом, чтобы реализовать проект трансформации, компании вынуждены либо нанимать новых специалистов, либо привлекать партнеров с рынка. Но какие компетенции нужны, кого привлекать к проекту в условиях кадрового голода? Вендоры обычно заняты разработкой продукта и не всегда способны оказать надлежащий уровень пресейла. Главный барьер на пути трансформации не в том, что бизнесу нужно переходить с проверенных годами зрелых западных решений на новые российские, а в том, чтобы оперативно выбрать из сотен новых продуктов.
Проект глазами интегратора
Прежде, чем искать гибкие инструменты, уточним термины.
Для заказчика проект – это комплекс мероприятий, результатом которого является получение услуги или продукта в определенные временные рамки при определенных затратах. Только одна из задач на пути увеличения эффективности ИТ-инфраструктуры и оптимизации затрат. И если говорить о полном переходе на отечественные решения, то это тянет на программу проектов.
Программа проектов – это ряд связанных друг с другом проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности. При таком подходе появляется дорожная карта, координация и приоритизация проектов. Дорожная карта может меняться по мере достижения промежуточных результатов, какие-то проекты могут добавляться, а какие-то закрываться и для программы проектов это нормально.
При формировании программы проектов ключевое значение имеет наличие в команде системных архитекторов. Этот специалист создает общее видение ландшафта целевой ИТ-инфраструктуры и определяет промежуточные точки движения к ней, чтобы циклы последовательных изменений не создавали катастрофического уровня рисков нарушения отказоустойчивости и угрозы сохранности данных. На практике системные архитекторы помогут «увязать» различные IT-решения внутри одного проекта или бизнес-процесса. Специалист этого профиля может быть штатным или привлеченными с рынка, но ввиду высокой востребованности нужно обращать внимание на реальный опыт.
Неопределенность нужно устранять на старте
В текущих условиях большая часть задержек по проекту связаны с тем, что компании долго присматриваются к выбору решений. По сути, это еще предпроектная стадия. Бывают случаи, когда данный этап растягивается на годы. Но не меньше вреда принесет обратная ситуация, когда компания-заказчик решает ускорить процесс и внедрить одно из решений, полагаясь только на маркетинг вендора и не обратившись к мнению третьей стороны. Здесь компетентный интегратор выступает неким фильтром, защищающим от ошибок. В нашем опыте был случай, когда к нам пришел российский производитель программного обеспечения с предложением взять на пресейл его продукт. Мы решение протестировали и честно сказали, что продукт сырой, продвигать его на рынке не готовы. Тогда вендор пришел к заказчику, а это был федеральный орган власти, и смог заключить сделку напрямую. В результате эксплуатации произошел сбой, была полностью уничтожена база данных, а на восстановление работоспособности ушли долгие месяцы. Поэтому не стоит пропускать этапы тестирования и пилотирования — это прямой путь к еще большему увеличению сроков. Сутью и сущностью тестирования сегодня стала практика применения ПАК. Гиперконвергентные решения, объединяющие несколько проверенных в лаборатории ИT-продуктов, позволяют провести сегментное импортозамещение под конкретную бизнес-задачу заказчика.
Классические инструменты для поддержки стабильности
Когда выбрано решение и выделены средства, наступает этап реализации проекта. Для интегратора он сегодня принципиально ничем не отличается от того, как было раньше. Здесь стоит опираться на классические ватерфольные инструменты управления, и самое главное — ориентироваться на план-график. Общаясь с менеджментом заказчиков, я часто вижу, что соблюдение срока реализации проекта воспринимается ими как главный критерий успешности проекта. Но лучше на проект смотреть как на параметрическое уравнение, в котором сроки, ресурсы и качество — переменные. И тогда появляется возможность управлять этими параметрами для получения оптимального результата.
Преодоление рисков
Специфика работы интегратора заключается в умении брать на себя риски и с ними справляться независимо от обстоятельств. Откровенно говоря, это то, чего хотят заказчики — передать проекты, которые сами считают слишком рискованными либо не обладают достаточными компетенциями. Порой нам приходится решать непрофильные, внезапно возникающие задачи. Например, нас приглашают поставить оборудование для ЦОДа — при осмотре здания выясняется, что перекрытия физически не выдержат установки такого количества серверов, СХД и прочего. Надо на ходу решать — меняем здание, укрепляем его, переносим оборудование на другой этаж, меняем конфигурацию дата-центра...
Или в одном промышленном городе заказали типовой проект создание ЦОДа. А выбросы в воздух на предприятии такие, что чиллеры, внешние блоки кондиционеров серверной, не прослужат заявленные производителем сроки эксплуатации. Приходится повышать экспертизу в химии, подбирать специальное полимерное покрытие, которое выдерживает окружающую среду.
Таким образом, какие бы инструменты планирования ни применялись, в конечном итоге проект реализуют люди, готовые брать на себя риски и быстро адаптироваться под меняющиеся ситуацию.
Поэтому основную рекомендацию по управлению проектами трансформации я бы сформулировал сегодня так: постараться обезопасить себя максимально на предпроектной стадии и привлекать команды с богатым опытом, готовые брать на себя риски уже на проектной стадии.
Опубликовано 30.11.2024