Цифровая трансформация и ИТ-инфраструктура: три маркера готовности "технологического фундамента" к поддержке быстрых изменений в бизнесе
Сегодня практически любым организациям жизненно важно стать максимально адаптивными и при этом повышать эффективность, чтобы развиваться несмотря на трудную экономическую ситуацию. А также успевать использовать окна возможностей, возникающие на современном рынке.
Однако традиционные способы управления предприятиями не позволяют организациям меняться быстро, поскольку требуют переучивания, а зачастую и замены персонала, что практически никогда не проходит без сопротивления новшествам. Цифровая трансформация (ЦТ) - альтернативный и гораздо более привлекательный способ осуществления изменений, ведь он не предполагает непопулярных мер, обычно сопровождается повышением прозрачности системы мотивации, а самые важные изменения проводятся в основном с помощью ИТ. В итоге персонал зачастую их не замечает. Или даже приветствует.
При этом цифровая трансформация - это качественное, а не количественное изменение бизнеса. Которое, в свою очередь, должно "стоять" на понятном фундаменте - надежной и отказоустойчивой ИТ-инфраструктуре, полностью готовой к частым разнонаправленным изменениям информационных систем.
Но как определить, что ИТ-инфраструктура конкретного предприятия, действительно, выдержит цифровую трансформацию, если она будет влиять на большинство сотрудников и затрагивать различные аспекты работы предприятия? Сегодня три ключевых "свойства-маркера" сразу показывают CIO крупного или среднего предприятия готовность или неготовность "фундамента" к более высокоуровневым изменениям в сфере ИТ.
Маркер №1: чистота
Этот маркер характеризует отсутствие в информационных системах исторически обусловленных архитектурных ошибок. Например, таких как кластер серверов СУБД, реализованный в неотказоустойчивой конфигурации. Несколько лет назад, когда база данных была еще совсем небольшой, такое решение не мешало организации и могло казаться нормальным. Но позже, когда проект, ради которого был создан кластер, набрал полные обороты и стал активно развивающейся существенной частью бизнеса, кластер нужно было сразу же перестроить, не дожидаясь катастрофы. Сделать его отказоустойчивым, чтобы СУБД могла выдерживать резко возросшую нагрузку, которую создают все новые пользователи соответствующей бизнес-системы (например, системы коммерческого учета). Однако, как правило, кластер перестраивают только после серьезных ИТ-инцидентов и повальных жалоб бухгалтеров и финансистов на то, что система учета стала строить важные отчеты часами или даже сутками. А бизнес в это время вынужденно простаивает, несет убытки и получает штрафы. Что неправильно.
Важный и весьма типичный случай связан с "гигиеной" ActiveDirectory (AD). При развитии информационной системы в AD остаются "хвосты" вышедших из строя, а затем некорректно выведенных из AD старых контроллеров домена и серверов Exchange. Позже накопившиеся "хвосты" приводят к плохо диагностируемым проблемам с авторизацией или отправкой электронных сообщений. А это снова сбои и простои бизнеса, упущенная или недополученная прибыль.
Но хуже всего, что чисткой ИТ-инфраструктуры в процессе эксплуатации мало кто занимается. В случае СУБД причиной становится принцип "работает - не трогай", а в случае с AD - нехватка редких специализированных компетенций.
Маркер №2: масштабируемость
Если у крупного бизнеса вопрос масштабируемости ИТ-инфраструктуры как-то решен (планово закупают новое "железо", живут со старым "запасом" или с тем, что есть), то средние компании постоянно испытывают трудности с новыми мощностями. А в процессе цифровой трансформации они обязательно потребуются, и немалые! Например, при расширении среды для разработчиков. Или тестового стенда, позволяющего экспериментировать с приоритетной частью ИТ-инфраструктуры. И эта часть меняется согласно требованиям бизнеса. Или с ключевым ИТ-сервисом (например, с полной репликой электронной почты). А это десятки процессорных ядер, сотни Гб оперативной памяти, терабайты быстрых (SSD) дисков. И все это вместе - довольно дорого! Дополнительные ресурсы нужны и при внедрении, и при замене бизнес-систем. Например, системы кадрового учета и работы с персоналом. В подобных ситуациях старая и новая HR-системы долгое время (от шести месяцев до полутора-двух лет) сосуществуют параллельно. При этом новой системе нужна и СУБД, и сервер приложений… То есть ресурсов должно хватать для обеих систем. А это двойное внимание, двойной объем компетенций и двойные расходы.
А если это государственная компания и она трансформируется строго определенным образом - в ходе импортозамещения ИТ? Учитывая поэтапный характер этого процесса, точно не получится взять контроллер ActiveDirectory и завтра же полностью заменить его на SambaDC. Долгое время госпредприятию нужны будут полуторные-двойные мощности.
Иными словами, и у средних, и у крупных компаний, особенно внедряющих импортонезависимые решения и продолжающих поддерживать привычные проприетарные продукты и технологии, должен быть простой, понятный и недорогой способ получить двойные мощности, причем не избыточные. Чтобы быстро, просто и за разумные деньги масштабировать свою (надежную!) инфраструктуру, в любой момент попробовать, внедрить или оперативно заменить то или иное ИТ-решение. То есть, действительно, трансформироваться.
Маркер №3: высокая изменчивость
ИТ-инфраструктура должна успевать за растущим темпом изменений, который ей задает бизнес. Например, для крупной коммерческой организации с большим числом филиалов, магазинов и собственных складов важно максимально быстро создать тестовую среду. В ней, в частности, должна быть полностью реплицирована критичная для нее система - например, для ведения складского учета. Причем сегодня такая среда нужна не через месяц-два, а всего через два-четыре рабочих дня! Тогда бизнес может попробовать изменения в системе и тут же внедрить самые успешные из них. Например, изменить порядок поступления товаров на склады в разных городах или частях города и соответствующую логистику. Или оптимизировать объем хранящихся на складах товарных запасов (где-то добавить, где-то сократить ассортимент, согласно выводам по предыдущему периоду и прогнозированию дальнейшего спроса). То есть повлиять на собственные расходы и доходы.
Кроме того, если тестовую среду развертывать месяц, она деактуализируется, так как в основной системе за это время появится масса обновлений. При этом команда, отвечающая за внедрение нового ПО, может и не узнать об этих обновлениях от "эксплутационщиков". Поэтому кроме прописанных технических частей (карты процессов, контрольные точки, отчеты по результатам этапов) для успешной цифровой трансформации, даже самой небольшой, должны быть определены и внедрены четкие схемы взаимодействия команд разработчиков, внедренцев и служб эксплуатации ИТ-решений.
При импортозамещении ИТ-инфраструктура должна поддерживать работу так называемых ИТ-химер (сосуществующих замещаемых и замещающих систем, о которых мы говорили выше). То есть должна создавать управляемую гетерогенную технологическую среду, в которой мирно соседствуют и западные, и новые российские продукты, и Open Source (например, Exchange и SOGо; MSAD и SambaDC). И доля которых постепенно меняется. При этом, скажем, рабочие станции могут без всяких сложностей полноценно взаимодействовать с серверным парком на основе Windows AD, с одной стороны, Linux и SambaDC - с другой. И в обеих средах кипит жизнь: делаются резервные копии критичной для бизнеса информации, устанавливаются обновления ПО, а работа ИС мониторится в онлайн-режиме. Никаких "инородных тел". Вот что означает высокая изменчивость ИТ-инфраструктуры, жизненно важная для реальной цифровой трансформации.
Как ни удивительно, у активного среднего бизнеса, который, например, оказывает услуги по хранению и ведению у себя бухгалтерии заказчиков, при переходе с MSSQL на PostgreSQL, появляется почти та же "ИТ-химера" и та же головная боль! Часть баз данных будут управляться одной СУБД, часть - другой, и довольно долгое время. А ИТ-инфраструктура самой компании, которая решила сэкономить на лицензионных платежах и начать использовать Open Source, должна, во-первых, вместить в себя все данные, во-вторых, сохранить резервные копии, в-третьих, не потерять в быстродействии и вообще никак не пострадать.
Итого
Прежде чем начинать полномасштабную серию цифровых трансформаций, средним и крупным, коммерческим и госкомпаниям нужно проверить "фундамент" - ИТ-инфраструктуру. Чтобы не завязнуть в многоуровневых проверках, начать здесь стоит с самого основного - чистоты от "болезней", а также достаточной масштабируемости и надежности. И конечно, с выявления способности инфраструктуры меняться быстро и без рисков, оперативно отвечая на запросы бизнеса. Существует еще как минимум пять второстепенных "маркеров готовности технофундамента" к поддержке изменений. Но это тема для отдельного материала.
