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

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

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

Шаг № 1. Понять причины

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

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

Шаг № 2. Всеобщее документирование

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

Шаг № 3. Результаты поддержки в цифрах

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

Шаг № 4. План миграции

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

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

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

Шаг № 5. Определи ожидание

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

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

Шаг № 6. Выполнение плана

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

***

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