Парадоксы стандартизации.

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

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

Рис. Ответы на вопрос
«Существуют ли в организации корпоративные
стандарты на используемые платформы,
и если нет, то планируется ли ввести таковые?»

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

Рис . Ответы на вопрос
«Существуют ли в организации корпоративные
стандарты на используемые платформы,
и если нет, то планируется ли ввести таковые?»
в зависимисти от оборота компании

По мере уменьшения размера доля компаний, где ИТ-стандарты отсутствуют, растет.

Чьими руками?

Судя по всему, при проведении стандартизации компании в основном опираются на свои ресурсы. «Полный консалтинг по переходу на единые ИТ-стандарты нам заказывают не часто, обычно мы имеем дело с какими-то элементами, этапами: аудитом, разработкой документации, процессным консалтингом по ITIL, организацией работы ИТ-службы заказчика», — говорит Игорь Малышев, руководитель направления программных инфраструктурных решений компании «Крок». Ему вторит технический руководитель направления «Системы управления ИТ-услугами» фирмы «Открытые Технологии» Евгений Евенко: «Заказы на проведение аудита мы получаем постоянно: клиент хочет знать, почему не работает определенное оборудование, проверить сеть, выяснить, какой компонент в сервере перегружен, найти узкое место и т. д. Результатом подобных проверок могут стать рекомендации по формированию стандартов. Вот только за внедрением стандартов обращаются крайне редко». А вот как описывает ситуацию Александр Дубина, директор управления профессионального сервиса компании «АйТи»: «С потребностью заказчиков в выработке стандартов оборудования или ПО мы сталкиваемся около десяти раз в год. Как правило, им нужно провести обследование “ИТ-хозяйства” предприятия, классифицировать его и, следовательно, стандартизировать. Иногда заказчик акцентирует внимание на инвентаризации именно устаревающих активов. При этом независимо от предмета стандартизации документационное обеспечение проектов является необходимым условием. Еще реже встречаются проекты по разработке стандартов деятельности ИТ-службы, когда наши консультанты формируют определенный функционал ее сотрудников, схему взаимоотношений ИТ- и бизнес-подразделений».

Двигатели и препятствия стандартизации

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

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

Другой двигатель стандартизации — переход на централизованные системы автоматизации бизнес-процессов. Как отмечает Игорь Малышев («Крок»), задача внедрения корпоративной бизнес-системы в определенный срок, диктуемый бизнес-подразделениями, может ускорить принятие стандартов на информационные технологии, необходимые для этой системы. Именно внедрение тяжеловесных и требовательных к инфраструктуре бизнес-приложений часто оказывается толчком к стандартизации и оптимизации ИТ, считает Денис Матеев, заместитель директора департамента технического маркетинга и поддержки продаж компании «Микротест».

При этом надо учитывать, что внутренние стандарты действенны не на всех участках корпоративной сети. Евгений Евенко («Открытые Технологии») приводит такой пример: парк рабочих станций обычно обновляется довольно часто, поэтому здесь их внедрение обоснованно. Ведь одна из целей ИТ-стандартов — ускорить процесс развития ИТ, единожды внедрив стандарт и не запуская каждый раз цепочку согласования закупок типовых элементов. С другой стороны, для тех составляющих, которые имеют высокую стоимость и обновляются реже (например, ЦОД или ядро сети передачи данных), понятие стандарта не всегда применимо, поскольку подобные проекты практически всегда приходится утверждать на уровне высшего руководства. Когда же в организации имеется несколько таких крупных объектов, их развитие необходимо координировать, а значит, стандарты нужны. Таким образом, стандартизация должна касаться не уникальных, а типовых и даже массовых элементов.

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

Сложности могут возникать в том случае, если стандарты приводят к существенному увеличению бюрократических процедур и не поддерживаются средствами автоматизации, предупреждает Денис Матеев («Микротест»). Важно изначально продумать «логистику» реализации стандартов, подчеркивает он. Например, раньше достаточно было просто позвонить нужному специалисту ИТ-департамента, чтобы он пришёл и выполнил необходимую работу. После же внедрения стандарта на обращения надо подготовить заявку, подождать ее утверждения, потом снова ждать, когда ИТ-департамент выделит ресурс и пришлет специалиста для решения возникшей проблемы. «Разумеется, сотрудников придется обучить использованию новых инструментов; тем не менее если и стандарт, и поддерживающий его инструментарий работают удобно, то особых проблем обычно не возникает, — говорит Денис Матеев. — Но очень важно осуществить внедрение в соответствии с бизнес-процессами компании. Стандарты должны быть не просто данью моде, спущенной руководством сверху. Они должны помогать в повседневной работе. Для этого необходимо до каждого сотрудника донести цели корпоративных стандартов и их преимущества как для компании в целом, так и для каждого работника в частности, а руководство должно служить примером в их использовании, т. е. сам процесс правильно начинать с руководителей».

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

Тем не менее наибольшая проблема при стандартизации ИТ-активов лежит не в технологической плоскости, а в организационной, считает Александр Дубина («АйТи»). По его мнению, главное препятствие для нормального хода работ — невозможность консолидации интересов разных групп заказчиков внутри компании. С другой стороны, на чаше весов — существенная экономия на эксплуатации систем, новые возможности технологий, более высокий уровень управляемости. «Что именно перевесит в каждом конкретном случае, совсем не очевидно, — говорит Заурбек Алехин. — Только аккуратно учтя все факторы и проведя корректную оценку, можно получить действительно обоснованное решение о переходе к новому стандарту».

Тактика и сроки

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

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

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

Что касается тактики замены, то по словам Александра Дубины для холдинговых структур идея продления жизни устаревающих ИТ-активов за счет их миграции представляется оптимальной. Стоимость переоснащения методом «большого взрыва» высока. Уже использованное оборудование можно перевезти в филиалы, где действуют более «легкие» системы, а в центре — поставить новое. Однако надо учитывать, что на практике возникает большой риск того, что перемещаемые активы частично будут испорчены, частично разукомплектованы, да и организация перевозки может обойтись довольно дорого.

А вот для стандартизации программного обеспечения последовательный принцип лучше не применять. Из-за перебоев в финансировании проект по обновлению приложений может затянуться, так что его цели однажды станут неактуальными, предупреждает Александр Дубина. И еще один его совет: при разработке стандартов оборудования или приложений нужно смотреть на поколение вперед. То есть если в компании в настоящий момент используется Microsoft Windows 98, то стандартом операционной системы не стоит делать Windows 2000, надо сразу «перескочить» на версию ХР.

Стандартизация ИТ-услуг

Отдельный вопрос — стандартизация на уровне ИТ-услуг. Видимо, переход к концепции ИТ-сервисов и соответствующее ему внедрение в практику стандартов находится сейчас в «точке перегиба»: есть предпосылки для движения вперед, но и осложняющих факторов предостаточно. О проектах создания каталога сервисов и других работах, связанных с имплементацией ITIL, приходится слышать все чаще. Например, Роман Марковский, начальник управления информатизации департамента информатизации и связи «Сибур-Холдинга», рассказывает: «На днях у нас проходила защита новой организационной структуры департамента информатизации и связи, а также ИТ-подразделений дочерних и зависимых обществ. В документе четко обозначены цели, задачи и функции ИТ в соответствии с ITIL и ITSM, представлен проект реструктуризации ИТ-подразделений и прописаны условия подчинения и взаимодействия ИТ-отделов головной компании и дочерних и зависимых обществ, а также процедуры управления проектной и операционной деятельностью и её контроля. Новое видение работы ИТ-подразделений полностью основывается на стандартах ITIL и ITSM внутри отдельно взятого юридического лица. Принципы же взаимодействия ИТ-подразделений разных компаний разработаны конкретно под “Сибур-Холдинг”». Отметим, что для «Сибура» это очень серьезный шаг, поскольку активы его разнообразны, уровень развития информационных технологий и ИТ-служб в них различается очень сильно, а эффективного механизма централизованного управления ИТ-службой до сей поры не существовало. Подобных примеров все больше, но...

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

Второе «но» тоже личностное. Заурбек Алехин («Ай-Теко») абсолютно верно замечает, что качественное внедрение всех процессов в соответствии с ITIL ведет к самостоятельности и даже аутсорсингу ИТ-службы. С одной стороны, звучит привлекательно, с другой — что-то пока не видно массы примеров автономного существования таких «экс-ИТ-служб», отправленных в свободное плавание, хотя попыток превратить ИТ-подразделение в отдельное юридическое лицо становится все больше. Если материнская компания имеет какую-то серьезную специфику, где используются уникальные приложения, то выводимая «вовне» ИТ-служба все равно свое монопольное положение сохранит, ибо никто другой в этих самописных и специфичных приложениях не разберется. Но если такой яркой уникальности нет, бывшему ИТ-отделу может прийтись совсем не сладко на свободном рынке ИТ-услуг. Так что стоит ли рубить такой удобный для сидения сук — еще большой вопрос.