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

Организационные вызовы

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

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

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

Так как же подобрать или вырастить хорошего IT-менеджера, способного транслировать бизнес-задачи в IT и к тому же умеющего говорить языком "денег"? Ответ не настолько прост, как может показаться на первый взгляд. С советских времен большинство из нас привыкло к мысли, что "...кадры решают все" (с) И.В. Сталин. Но в современных условиях постоянно меняющегося бизнеса, и, в особенности, в преломлении к еще более быстрому изменению технологического обеспечения работы бизнеса, эта старая модель дает сбои. В основе классической модели, описанной в библиотеке ITIL, лежит принцип трех "Р": People, Process, Program (технологическое обеспечение). И, как показывает практика, наиболее жизнеспособной, и с точки зрения бизнеса, и с точки зрения инфраструктуры, является модель, в которой Process, формализация деятельности и активностей, стоит на первом месте. Ни для кого не секрет, что человеческий фактор в управлении представляет собой решающий риск. Если посмотреть мировую статистику, около 90% возникающих проблем так или иначе связаны с человеческим фактором. Поэтому единственным решением для существующих вызовов является жесткая формализация как взаимоотношений между IT и бизнес-заказчиком (договора на обслуживание), так и формализация активностей сотрудников по поддержке и изменению существующей инфраструктуры.

Возвращаясь к вопросам

Сколько мы тратим? Почему мы столько тратим? Как посчитать расходы? К расходам на IT-инфраструктуру можно отнести следующие: расходы на поддержку существующих сервисов и расходы на их изменение.

Есть несколько процессов, описанных в библиотеке ITIL, которые позволяют провести анализ затрат и, соответственно, спланировать экономически оправданный бюджет. Во-первых, это наиболее распространенный в настоящее время процесс управления инцидентами. Если процесс формализован, в таком случае из журнала инцидентов и запросов на обслуживание мы можем посчитать, сколько времени и ресурсов было затрачено на поддержку сервисов в рабочем состоянии. Из чего можно сделать вывод, что если количество сервисов и бизнес-сотрудников не изменится в течение следующего периода времени, затраты на поддержку, скорее всего, останутся прежними. Мы пока не говорим о возможности оптимизации данных затрат. Рассматриваем ситуацию как она есть "на сейчас". Мировая и моя собственная практика как консультанта по внедрению ITSM-процессов показывает, что соотношение сотрудников первой линии поддержки (специалистов Сервис деск, их порой называют "эникейщиками от английского any key") к бизнес-сотрудникам составляет приблизительно 1Х50. Опять же, хотелось бы подчеркнуть, что такое соотношение позволяет сохранить высокое качество предоставляемых сервисов только при наличии жесткой формализации процессов поддержки. Аналогичный расчет можно произвести и в привязке к обслуживанию элементов инфраструктуры, с которыми непосредственного общения конечных пользователей не происходит (каналов связи, сетевого и серверного оборудования и ПО). Итак, первая цифра уже появилась. Кстати, здесь хотелось бы отметить еще и косвенные данные по уровню компетентности сотрудников бизнес-подразделений, что позволит проводить анализ руководству бизнеса на соответствие последних заявленным профессиональным компетенциям.

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

Можем ли мы оптимизировать расходы, не сокращая количество сервисов? Безусловно. Возвращаемся к лучшим мировым практикам. Статистика - наука твердолобая. Есть факт, значит от него не уйти. Я уже отмечал, что в основе около 90% инцидентов лежит человеческий фактор. То есть либо низкая компетенция бизнес-сотрудников, либо изменения, внедрённые впопыхах. Так вот, есть еще одна цифра. Из общего количества инцидентов порядка 80% повторяющиеся и не требующие вовлечения в разрешение высококвалифицированных сотрудников. На поверхности лежит потребность в сокращении времени и ресурсного вовлечения как раз в плоскости этих 80%. Это может быть достигнуто за счет формирования базы знаний по инцидентам на основании выработки и анализа типовых решений. В моем опыте была практика внедрения процесса управления инцидентами в одном из ведущих банков Украины. Так вот, за счет формирования базы знаний количество инцидентов, разрешаемых первой линией поддержки (оговорюсь, это операторы, не имеющие IT-опыта, соответственно, более "дешевые"), за первые два месяца эксплуатации поднялось, в среднем, до 90%. Это значит, что сократилось время специалистов более высокого уровня, затраченное на решение часто раздражающих и демотивирующих задач. То есть пропорционально увеличилось время, которое может быть выделено на проработку и внедрение изменений. Что само по себе повышает качество и, опять же, сокращает время простоя, повышая доступность (читай: уровень предоставляемого сервиса) и удовлетворенность конечных пользователей без дополнительных затрат. Также выработка базы знаний по типичным инцидентам позволяет вывести первую линию поддержки на аутсорс. Что может еще и сократить непрямые операционные затраты. И это закладывает хороший базис в укрепление отношений между бизнесом и IT и переводит их с рельсов административного давления на более конструктивные, позволяя полноценно сотрудничать и повышать качество работы бизнес-подразделений.

Андрей КОЧУКОВ,
www.iss-advance.com,
ank@iss-advance.com