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

Intelligent Enterprise: Какие основные принципы вы закладываете в методику оценки результатов деятельности ИТ-подразделения?

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

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

Для нас, например, очень большую роль играют программные разработки, все сто процентов которых для РОСНО в режиме аутсорсинга ведут сторонние компании. Следовательно, здесь должны выстраиваться объективные критерии оценки их деятельности на сей раз со стороны ИТ‑департамента РОСНО, но это уже совсем другая тема (более подробно об этом см. IE, № 12/2008, стр. 6. — Прим. ред.).

Давайте тогда начнем с проектного направления, которое, как вы сказали, с точки зрения оценки эффективности рассматривается как отдельное. Коль скоро это так, какие отличительные особенности вы могли бы здесь назвать?

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

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

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

Выполняя проекты, необходимо также учитывать, что за соответствие ра­боты ИТ-отдела бизнес‑стратегии компании, а значит, и реализацию ключевых для бизнеса ИТ-проектов должен отвечать CIO и никто другой. К нему нетрудно «прикрепить» некоторые ключевые показатели, которые будут призваны служить индикаторами его достижений в этом направлении. Но подобным образом сложно поступить с кем‑либо из его подчиненных, в том числе и самых близких. Их обязанности уже в значительной мере связаны с операционной деятельностью, и если проектные KPI, ассоциированные с CIO, невозможно транслировать на уровень ниже (CIO же не в одиночку ведет проекты), то он рискует остаться, образно говоря, генералом без армии.

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

А как оцениваются результаты операционной деятельности вашего подразделения?

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

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

Характеристики, связанные с разработкой ПО, основаны на балльной оценке с последующим ее усреднением по всем выполненным к определённому моменту работам в этой области. Каждый из возможных десяти баллов оценки жестко и однозначно привязан к конкретным показателям сроков или качества. Надо отметить, что некоторые доработки программного обеспечения по сути могут являться продолжением выполненных когда‑то проектов, но теперь подпадающих под категорию операционной деятельности.

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

В двух последних случаях (оценка со стороны пользователей и заказчиков) мы задействуем опросные листы, и результаты балльной оценки, которую нам выставляют, опять‑таки усредняются. В итоге мы неизменно приходим к количественной оценке, которую вполне можно считать объективной. Достигается эта объективность, правда, по‑разному: либо прямым подсчетом событий, либо тесной ассоциацией количественной оценки и качества результата, либо за счет набранной статистики и усреднения.

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

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

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

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

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

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

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

Эффективность — это не только показатели ROI и TCO

Барт Сталенц
Директор по стратегическому маркетингу Orange Business Services в России и СНГ

Эффективность ИТ‑системы начинается тогда, когда заказчик получает то решение, которое ему действительно нужно. Поставщик должен понимать бизнес-задачи компании и то, каким образом предлагаемые им услуги и продукты помогут их решить. Важную роль здесь играет умение говорить с заказчиком на одном языке, но при этом оно не может заменить факты и такие показатели, как ROI и TCO. Например, управляемая корпоративная IP VPN-сеть позволяет заказчикам не вкладывать средства в оборудование и технических специалистов, а сосредоточиться на стратегических для ключевого бизнеса проектах. Решения Orange по анализу производительности сети позволяют на величину до 80% сократить объемы передаваемого трафика и создают альтернативу экстенсивному пути развития корпоративной сети. А услуга конвергенции фиксированной и мобильной связи в числе прочего позволяет оптимизировать расходы на дальнюю связь как для мобильных, так и для фиксированных абонентов.

Принять во внимание культуру работы заказчика

Руслан Заединов
Заместитель директора департамента вычислительных систем компании КРОК

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