Статьи консультантов Cleverics

В статье использованы термины и ссылки на определения из ряда современных сводов знаний и стандартов в области управления ИТ: ITIL®, COBIT, ISO/IEC 20000:2011. Дополнительную информацию об этих материалах можно найти соответствующих официальных сайтах¹. Все упомянутые торговые марки являются собственностью правообладателей. Статья адресована профессионалам управления ИТ: ИТ-руководителям, консультантам. Мнения и оценки, высказанные в статье, отражают точку зрения автора и не должны никак ассоциироваться с какими-либо общественными организациями, профессиональными сообществами или учебными заведениями.

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

Почему не приживается сервисный подход

Как известно, оказание услуги – это всегда деятельность поставщика услуг и иногда предоставляемые заказчику ресурсы. Иногда заказчик отождествляет услугу с ресурсами, иногда – с деятельностью поставщика, иногда (редко) осознает это разделение составляющих услуги. Происходит это оттого, что заказчик уделяет внимание в первую очередь тем элементам услуги, которые непосредственно формируют то, что ITIL® называет «полезностью» (utility), и гораздо реже – тем, которые должны обеспечивать так называемую «гарантию» (warranty), то есть уверенность в том, что полезность действительно будет ему предоставлена в оговоренных условиях. Из довольно внушительного списка параметров качества, применимых к любым услугам, заказчики обычно обращают внимание на три: функциональность, доступность и цену.

Основным мотивом, побудившим меня поразмышлять на данную тему, явилось выполнение проектов в необычном для меня формате – а именно сопровождение ITSM-проектов, которые заказчик выполнял самостоятельно.

На сегодняшний день существует множество источников информации об организации процессов управления ИТ-услугами – стандарт ISO/IEC 20000 и библиотека ITIL®, авторизованные и авторские учебные курсы, большое количество публикаций и статей, открытые и закрытые методики от производителей программного обеспечения для автоматизации процессов и так далее. Доступность информации помогает профессионально расти специалистам в области ITSM, что, в свою очередь, неизбежно ведет к соблазну попробовать внедрить процессы в своей организации собственными силами. Насколько это реально, и с какими сложностями может столкнуться организация, выбравшая такой путь?

Стандарт ISO/IEC 20000 «Information technology – Service management» был впервые принят в 2005 году. С тех пор по данной редакции стандарта было сертифицировано более пятисот компаний по всему миру, в России – по разным оценкам от 25 до 30. Наконец, в 2011 году вышло долгожданное обновление стандарта. Насколько он отличается от предшественника и стал ли лучше?

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

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

В данной статье приводится общее описание методики нагрузочного тестирования, делается анализ реалистичности её применения и даётся практический пример проведения нагрузочного тестирования в одном из проектов.

Последнее время мне доводилось много раз слышать вопрос: «Какой программный продукт вы рекомендуете для автоматизации наших процессов?» Будучи человеком честным, я всегда отвечал, что это зависит от множества факторов, и необходимо проделать определённую работу по определению требований, сравнению имеющихся на рынке продуктов, и только тогда, взвесив все за и против, можно будет говорить о выборе продукта. Несколько раз авторы вопроса просили помочь с выполнением этой работы, и тогда начинался проект, в результате которого выявлялись продукты, наиболее подходящие заказчику, причём каждый из них имел свои сильные и слабые стороны, и оставалось только выбрать. При этом выбор осуществлялся уже не в терминах продуктов, а в таких терминах, как «гибкость», «совокупная стоимость владения в перспективе трёх лет», «соответствие текущим требованиям», «соответствие стратегии развития» и так далее.

То есть задача выбора уходила от технических деталей программного продукта к определению стратегии автоматизации процессов.