Павел Потеев, Ruukki Rus LLC branch in Saint Petersburg: «Катти Сарк» или «Титаник»

Известно, что довольно просто управлять яликом недалеко от берега и в штиль. Задача усложняется, если надо управлять многометровой шхуной в условиях, когда берегов не видно, а море штормит.

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

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

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

Сформулируем некоторые практические рекомендации ИТ-менеджеру по сохранению управляемости и построению плана развития инфраструктуры компании в условиях ее гиперроста.

Пока гиперрост не наблюдается 

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

Гиперрост как возмутитель спокойствия

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

Сохранение прежних подходов к управлению инфраструктурой компании может привести к потере контроля над ней. Это может произойти, например, так:

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

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

Что делать, когда гиперрост еще только приближается?

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

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

Условия рационального планирования с учетом возможного наступления гиперроста

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

• возможность быстрого расширения/сжатия масштаба инфраструктуры;
  
• систематический контроль (по возможности, автоматизированный) прав доступа, их выдачи, изменений, блокировок;
  
•  максимально полная информированность о составе технического обеспечения инфраструктуры (серверах, рабочих станциях, печатающих устройствах) в привязке к стадиям их жизненного цикла (установка, использование, складирование, утилизация);
  
•  учет задач, решаемых специалистами поддержки (или организаций, оказывающих поддержку).
  

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

Начинать надо с пользователей

Как ни странно, начинать надо не с технической инфраструктуры. Все оборудование, права доступа, запросы и проблемы завязаны на пользователей. Следовательно, в автоматизированной системе управления инфраструктурой должна присутствовать актуальная информация по персоналу компании. Она должна содержать сведения о наймах, увольнениях, переводах на другие площадки и т.п. Это можно сделать через интеграцию систем управления персоналом и ИТ-операциями. Для последующих этапов (когда будет внедряться функция Service Desk распределенной компании) пригодится контактная информация (телефоны, адреса электронной почты).

Серверы: централизация и контроль

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

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

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

Особая забота о процессах

Для внедрения процессов управления ИТ-активами, поддержания базы данных конфигураций (CMDB), управления жизненным циклом компьютерной техники, Service Desk понадобится система поддержания базы данных конфигураций, интегрированная или общая с системой управления Service Desk. Мы исходим из того, что эта система (или системы) интегрированы с приложением управления персоналом, как было рекомендовано ранее.

Выполнение этого этапа развития инфраструктуры открывает новый диапазон возможностей, например:

• автоматизация ряда служебных процессов (например, блокировка авторизаций уволенных сотрудников);
  
•  оперативная выдача информации типа: где, сколько и какой имеется техники; в чьем распоряжении она находится; с какими проблемами сталкивались в недавнем прошлом пользователи этой техники; кем и как они решались;
  
•  учет работы, выполняемой специалистами из группы поддержки, прозрачность информации о количестве решаемых службой поддержки задач и уровне загруженности этой службы.
  

Do’s and don’t’s («туда не ходи, сюда ходи»)

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

Во-первых, с самого первого шага трансформации ИТ-инфраструктуры ориентируйтесь на то, что система в целом и ее подсистемы будут интегрированы и будут обмениваться информацией. «Замкнутые» решения типа отдельной Service Desk обеспечат быстрое внедрение сегодня, но станут  тормозом развития завтра.

Во-вторых, если вы трансформируете инфраструктуру для группы предприятий, то система не должна зависеть от структуры юридических лиц. Этим вы застрахуете систему от возможных изменений оргструктуры в будущем, в том числе слияний и поглощений. Создавайте единый домен, единую HR-систему, единые базы оборудования и запросов Service Desk.
В-третьих, стройте архитектуру системы так, чтобы обеспечить возможность аутсорсинга и мультисорсинга. Например, выносите серверы инфраструктуры к внешнему провайдеру, используйте для оказания услуг Service Desk и/или управления приложениями внешние компании.

Что дальше?

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

Убедимся, что вашей системе присутствуют:

• регистририруемые в системе Service Desk задачи, решаемые группой поддержки, и возможность их анализировать в различных аспектах (по загрузке ИТ-специалистов, территориям, типам задач, по срокам и своевременности исполнения и т. п.);
  
• подключение к поддержке инфраструктуры и пользователей внешних партнеров, с возможностью выноса как собственно работы Service Desk, так и поддержки конкретных приложений;
  
• «порталы самообслуживания», в которых пользователи могут размещать заявки на оборудование и через которые имеют доступ к сервисам, приложениям, каталогам, иным ИТ-ресурсам;
  
• единая авторизация, открывающая доступ к группе приложений, доступных для соответствующего профиля пользователя.
   
  
 

Подобные возможности присущи «большим» предприятиям с современными процессно-ориентированными ИТ-операциями, и при правильно спланированном развитии инфраструктуры они становятся доступны и вам. Так что, join the club, Добро пожаловать!