четверг, 6 октября 2011 г.

Подход к разработке показателей эффективности работы ИТ подразделения

Ключевые показатели эффективности работы ИТ подразделения компании являются важным элементом взаимодействия ИТ подразделения и бизнес-подразделений, для который ИТ подразделение предоставляет услуги.
Поскольку ИТ подразделение часто является центром затрат а не прибыли, то применять походы к оценке работы подразделений, которые применяются к центрам прибыли, к подразделению ИТ невозможно. Например, отдел продаж мы можем оценить по количеству заключенных контрактов, средней стоимости контракта и т.д., но для ИТ подразделения это применить невозможно. Однако, при этом необходимо оценивать работу всего подразделения в целом и руководителя ИТ подразделения в частности. Тут к нам на помощь приходят показатели эффективности работы, которые необходимо разработать учитывая следующие факторы:
1. Отрасль экономики, в которой работает компания.
2. Организационную структуру.
3. Культуру компании.
4. Уровень зрелости бизнес-процессов.
5. Численность персонала.
6. Сложность ИТ архитектуры.
Ключевые показатели эффективности работы являются методом оценки "полезности ИТ подразделения для бизнес-подразделений". Такая оценка должна выполнятся исходя из приоритетов, которые ставит перед собой бизнес-подразделение. Соответственно бизнес должен решить, что для него важнее и выбрать соответствующие показатели эффективности. ИТ подразделение является сервисным подразделением и, как и в любой сервисной организации, его работа может быть оптимизирована исходя из следующих направлений: стоимость, качество, время. Одновременно оптимизировать все три направления невозможно.
В каждом из направлений можно выбрать несколько ключевых показателей эффективности. Примеры таких показателей:
Стоимость

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

Качество

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

Время

  • Время (среднее, минимальное и максимальное) обработки заявок пользователей
  • Количество заявок, выполненных не в срок
  • Общее время простоя рабочих мест на протяжении периода времени
  • Общее время простоя серверного оборудования на протяжении периода времени
  • Частота предоставления отчетов руководству

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

среда, 5 октября 2011 г.

Причины внедрения ИТ контролей в организациях

Компании в процессе своего развития проходят через несколько стадий. Начинается развитие компании из стартапа или покупки франшизы. Если владелец бизнеса покупает его в виде франшизы, то вместе с разработанной бизнес-моделью ведения бизнеса, который покупается внедряются и необходимые внутренние контроли, включая и ИТ контроли.
Если же компания начиналась со старпата и развивается, то рано или поздно в процессе развития перед собственниками компании или перед наемными менеджерами возникает вопрос о внедрении ИТ контролей.
Для чего нужно внедрять ИТ контроли в компаниях? Вроде бы и без ИТ контролей хорошо.
Рассмотрим возможные причины внедрения ИТ контролей:
Причина1. Для соответствия требованиями.
В процессе развития компании она сталкивается с необходимостью привлечения дополнительных финансовых ресурсов для обеспечения роста, выхода на новые рынки, расширения бизнеса. Использовать только собственные ресурсы в этом случае означает упущенную возможность захвата открывшейся ниши на рынке. Если компания привлекает заемные средства в виде кредитов, выпущенных облигаций, эмиссии акций, то тут возникает ряд требований по аудиту финансовой отчетности и контролируемости бизнес-среды. Эти требования выдвигаются либо сторонами, предоставляющими заемные средства (например условия кредитования, предлагаемые банками) либо посредниками и операторами рынка (например, фондовыми биржами). Если компания работает в определенном секторе экономики (например, банковский или телекоммуникационный), то требования по контролям, в том числе и ИТ контролям могут выдвигаться регуляторами рынка (государства, ассоциации платежных систем).
Если компания не соответствует требованиям, то это ей может грозить штрафом или лишением лицензии.
Причина2. Для уменьшения ущерба от сбоев систем.
Сколько стоит для небольшой компании простой в течение 4 часов системы бухгалтерского учета или потеря данных за 1 месяц? А сколько стоит для телекоммуникационного оператора простой биллинговой системы и системы авторизации в течении 2 часов и потеря информации за 4 суток? Эти два события показывают, что ущерб от простоя системы и потери данных может сильно зависит от размера компании и специфики бизнеса. В процессе роста компании руководство понимает, что частые инциденты приводят к все большим ущербам и желательно от этих инцидентов избавиться. А инциденты происходят либо по причине технического характера (выход из строя компонент системы) либо по причине человеческого фактора (случайно выполнил не ту операцию, решил в системе исправить неправильную проводку, решил выполнить недозволенную операцию). Минимизацию частоты этих инцидентов и их последствий можно достичь внедряя систему внутренних контролей.
Причина3. Для повышения эффективности бизнеса.
Часто ли возникает в компании ситуация, при которой данные, которые несколько сотрудников старательно вводили в течение недели, были утеряны из-за сбоя системы и есть необходимость эти данные вводить повторно? Сколько времени необходимо потратить на повторную подготовку отчета или проектного документа, который был утерян за день до сдачи заказчику из-за сбоя в системе?
Часто инциденты с ИТ системами приводят к неэффективному использованию времени сотрудников компании. Если это время стоит дорого, то ущерб от таких сбоев очевиден. Если мы минимизируем последствии инцидентов, то мы в целом повысим эффективность ведения бизнеса.
Причина4. Для повышения прозрачности бизнеса и эффективного управления.
Задавался ли руководитель вопросом, кто из отдела продаж предоставил большую скидку клиенту и кто дал добро на это? Как быстро он сможет получить ответ на этот вопрос? Если компания небольшая и «все на виду», то руководитель знает, что происходит в компании и какие операции выполняются сотрудниками. Он также знает, выполнятся ли эти операции в интересах компании. А если компания насчитывает до 1000 сотрудников и офисы компании расположены в разных городах?
Решить эту задачу позволит внедрения ИТ контролей в систему учета и авторизации продаж.
Как видно есть несколько причин внедрения ИТ контролей. Представленный перечень причин является далеко не полным, однако он позволяет руководителям и собственникам компаний задуматься о такой вещи, как ИТ контроли.

четверг, 23 июня 2011 г.

Подходы к разработке политик и процедур в области ИТ и информационной безопасности

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

Как разрабатывать эти документы, какие существуют подходы? Существуют два принципиально различающих подхода: формалистический и практический.

Первый подход, формалистический, заключается в том, что мы разрабатываем ряд документов, в них описываем то, что должно быть (исходя из требований международных стандартов, исходя из требований регуляторов и т.д.). В этих документах излагается то, что "хорошо чтобы так было". При этом мы можем показать, что компания соответствует ряду требований в части разработанных политик и процедур (например, требования PCI DSS, которые введены недавно или требования SOX 404, которые были введены несколько лет тому назад). Не факт, что требования документов выполняются и не факт, что информационные системы и процессы соответствуют стандартам, но на бумаге выглядит все очень хорошо. Такие документы могут содержать требования, которые не всегда соответствуют здравому смыслу или общепринятым практикам. Для разработки таких документов в компании могут использоваться различные источники. Есть целый ряд готовых заготовок и шаблонов для разработки таких документов (например, Information Security Policy Templates от SANS.org или ресурс networkdoc.ru). Мы меняем шапку, немного изменяем формулировки и вот уже документ готов. Я на практике видел, как в целом ряде коммерческих банков Украины были разработаны формалистические документы для соответствия стандарту PCI DSS. На практике требования документов не выполнялись, да их и нельзя было выполнить. Например, PCI DSS требует наличия в компании плана обеспечения непрерывности деятельности - и вот он в компании есть. Другое дело, что документ содержит всего 8 страниц, из них 5 страниц - это шапка, ссылки, список авторов и т.д.
Но какая же польза от таких формалистичных документов для компании? Главная цель таких документов - показать соответствие чему-то. Но, согласитесь, для компании это не главное. Главная цель политик и процедур - донести до сотрудников компании основные принципы, по которым необходимо работать в компании. Это как законы, которые позволяют индивидуумам гармонично сосуществовать в рамках общества. Политики и процедуры должны помогать компании достигать своих целей. Это могут быть цели, направленные на получение прибыли собственниками, цели выполнения важных проектов для общества. Безусловно, может быть цель соответствия требованиям. Тут как раз формалистические документы помогут, но это только одна из целей компании.
Формалистический подход в нормативной документации аналогичен некоторым требованиям ПДД, которые либо устарели, либо рассчитаны на другие категории дорог и транспортных средств, но формально установлены и дают возможность сотрудникам автоинспекции применять штрафы. Но польза таких требований для безопасности движения сомнительна.

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

Один из примеров из другой области, который иллюстрирует эти два подхода - составление банковской гарантии. Во время проведения одного из тендеров необходимо было, чтобы участники, которые подают свои коммерческие предложения для участия в тендере, подкрепили "серьезность намерений" банковской гарантией. Если они не могут оказать услуги, описанные в коммерческом предложении, после выбора их победителем, то залоговая сумма через банковскую гарантию переходит от компании, которая объявляет тендер. В тендере участвовали два системных интегратора. Один из них работал на территории Украины, другой работал по всему миру. Украинский системный интегратор предоставил гарантию, выпущенную украинским банком. Это был солидный документ с множеством пунктов и условий, с мокрой печатью и подписью первых лиц банка. Другой интегратор предоставил гарантию, выпущенную ведущим международным банком. Это была факс-копия печатного документа на 8-10 пунктов уместившихся на одной странице формата А4 крупным печатным шрифтом. Мокрой печати и подписей на документе не было. Но, тем не менее, этот документ тоже был гарантией и не менее весомой. Поскольку компания дорожит своей бизнес репутацией (в данном случае банк), то этот документ это также меморандум, отражающий обязательства сторон. Вопрос юридической силы тут другой, поскольку одно дело - существующие законы, другое дело - их выполнение. Лично я доверял бы второй гарантии больше, поскольку репутация у второго банка намного лучше репутации первого банка. Законы в Украине, к сожалению, не всегда выполняются. И, имея на руках формальную юридическую гарантию от Украинского банка, мы на самом деле обладаем меньшей гарантией (прошу прощения за вынужденную тавтологию) того, что залоговая сумма будет передана при наступлении событий, указанных в условиях.

Формалистический подход был распространен в СССР. Были некие стандарты, на бумаге они выполнялись, но на практике это не всегда выполнялось. В то же время детализированные стандарты были. Практический подход больше распространен в западных компаниях, в которых все больше базируется на меморандумах, а не на формальных документах.

Компании в Украине могут выбирать, каким подходом им руководствоваться. "Выбирай, но осторожно, но выбирай" © Роман Карцев.