Методика организации ИТ-службы предприятия

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

Роль ИТ в деятельности компании

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

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

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

Эшелонирование службы поддержки

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

При таком рассмотрении ИТ-поддержки мы имеем очень мощный рычаг по управлению стоимостью этого процесса. Замечу, что аналогичный подход существует, например, в медицине. В Англии получила большое распространение концепция организации медицинской помощи на основе четырех уровней поддержки. Суть ее заключается в том, что вместо непосредственного обращения пациентов к врачам-специалистам перешли к системе врачей общего профиля или семейным врачам, закрепленным за определенной территорией (D. Sloan "The Essentials of Family Medicine"). Первый уровень - грамотная диагностика, ответ на вопрос "Что же заболело?". Второй - оказание квалифицированной доврачебной или первичной врачебной помощи. По сути, это тот же самый help-desk первого уровня. Третий - специализированная помощь, которая требует более высокой квалификации, и последний, четвертый эшелон - это специализированная медицинская помощь в условиях стационара, требующая дорогостоящего оборудования и узко специализированных врачей. На первых двух уровнях стоимость каждой операции по поддержке невелика, затем она существенно возрастает.

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

Функции ИТ-поддержки

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

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

Централизованное администрирование

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

Кто такой системный администратор?

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

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

• архитектор корпоративной информационной системы;
• администратор корпоративной информационной системы;
• администратор по безопасности;
• программисты поддержки корпоративной информационной системы;
• администратор баз данных;
• администратор коммуникаций;
• администратор сети.

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

Организация ИТ-службы

С моей точки зрения, необходимо классифицировать всю деятельность ИТ-службы по трем направлениям (рис. 2). Первое - служба эксплуатации технических средств инфраструктуры и стандартного программного обеспечения. Замечу, что так называемое стандартное программное обеспечение отнюдь не простое (в него, в частности, входит электронная почта). Второе - служба поддержки и развития прикладного программного обеспечения. Я неслучайно поставил на первое место слово "поддержка". Если нормально не эксплуатировать какой-то компонент информационной системы, развивать его будет очень тяжело. Это процесс итерационный.

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

1. Служба эксплуатации технических средств, инфраструктуры и стандартного программного обеспечения взаимодействует с службой эксплуатации здания (АХО, энергетики, связисты, строители) и с внешними подрядчиками по реализации внутри этого этого здания определенной инфраструктуры.

2. Служба поддержки и развития прикладного программного обеспечения взаимодействует, с одной стороны, с бизнес-подразделениями, потому что она их поддерживает, с другой стороны - с разработчиками прикладного программного обеспечения. Здесь возникает вопрос: "Можно ли обойтись в этой службе без своих программистов?". На мой взгляд, совсем обойтись без штатных программистов нельзя, по той причине, что есть еще одна функция, которая требует нахождения программиста внутри ИТ-отдела. Это задача программирования извлечения информации из базы данных. Важно понимать, что эта задача принципиально отличается от разработки информационной системы собственными силами, потому что не связана с вмешательством в логику работы приложений, а просто расширяет стандартные отчеты. Это безопасно, поскольку не влияет на поддержку информационной системой бизнес-процессов (выполнения операций), кроме того, снижает требования к квалификации таких сотрудников.

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

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

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

Точка входа в help-desk

Возникает вопрос: "К какой службе относятся специалисты help-desk общего профиля?". Для того чтобы правильно на него ответить, нужно понять в чем состоит специфика help-desk первого уровня. Как правило, в том, что надо дойти до того места, где возникла проблема, потому что обращение по поводу неработающей программы (а именно она представляет ценность для пользователя) может быть вызвано множеством различных причин. Самым логичным мне кажется организовать точку входа в help-desk в службе поддержки развития прикладного ПО - при достаточном уровне ИТ-подготовки пользователей, как правило, большинство вопросов идет по прикладным системам. Если же проблема классифицирована как техническая, то запрос переадресовывается в службу эксплуатации технических средств и стандартного ПО. Однако help-desk первого уровня может быть организован и в составе службы эксплуатации технических средств и стандартного ПО, если в компании еще нет устоявшихся традиций коллективной работы или уровень автоматизации не очень высок. Кстати, в компании "СОГАЗ" сделано именно так.

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

Системные администраторы в филиалах

Ну и наконец, отдельно стоит обсудить вопрос о системных администраторах филиалов в случае территориально распределенной компании (практика говорит о том, что необходим один администратор на 40-50 пользователей, при условии, что их должно быть не менее двух, на случай отпуска или болезни). Лучшая практика показывает, что необходима максимальная централизация, поэтому, на мой взгляд, системные администраторы филиалов не должны принимать каких-либо решений по конфигурации информационной системы. Ни в коем случае нельзя допускать различия в настройках на уровне филиалов и центрального офиса. Все делается только в центре и затем тиражируется в филиалы.

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

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

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