Блог Александра Башкирова

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

Статьи

Подписаться на эту рубрику по RSS

Вышла моя статья "С широко закрытыми глазами" (ИТ-Менеджер)

Просмотров: 78Комментарии: 0
Статьи

Вышла моя статья "С широко закрытыми глазами" (http://www.allcio.ru/cionews/want/136676.html)

Она про 5 ошибок проектного и не очень бизнеса. Как говорится, прошу любить и жаловать :)

Про планирование в проектах

Просмотров: 184Комментарии: 0
Статьи

Вышел майский номер журнала ИТ-менеджер, с моей статьей "Про планирование в проектах".

В некотором смысле - "собрал опыт в кучу, систематизировал и поделился".

А вообще давно я не писал про свои статьи (а статьи, что характерно - писал).

Мои статьи или немного похвастаться.

Просмотров: 623Комментарии: 0
Статьи

Не знаю, в курсе уважаемые читатели, или нет - но в общем, я наверное, уже лет так 10 пишу статьи. А последние лет 6 - пишу их не на "технарские" темы (все же "технарь" - это хобби), а на тему отношений ИТ и бизнеса, проектного управления, SLA... Подумал, что вообще-то получается, что я пишу в журнал, как в блог. Да, я пишу в журнал, который называется IT Manager. Более того, являюсь членом экспертного совета этого журнала. В общем, все достаточно серьезно. 

К чему я это пишу? Да к тому, что периодически у меня появляется мысль: а не собрать ли мне статьи все в одном месте? Только лень... А тут внезапно выяснил, что на сайте журнала такая функция есть из коробки. Достаточно перейти по адресу http://www.allcio.ru/authors/59735.html - чтобы увидеть все статьи автора "Александр Башкиров". То есть мои. В общем, прошу любить и жаловать :)

Статья “ITIL: необходимо и достаточно?”

Просмотров: 2868Комментарии: 0
Статьи

Публикую статью "ITIL: необходимо и достаточно", которая была опубликована в журнале "Системный Администратор" (www.samag.ru) от 11.2008 - дело в том, что по соглашению с редакцией, публикация статьи возможна через три месяца после ее издания; кроме того, на публикацию этой статьи получено разрешение от редакции, так что все формальности соблюдены. Итак,

ITIL: необходимо и достаточно?

Ваше предприятие растет, а служба ИТ по прежнему представляет собой «черный ящик»? Вы не понимаете, как и зачем расходуются выделенные на ИТ средства? Вы считаете ИТ бюджет необоснованно высоким, или просто необоснованным? Вы видите выход в увольнении всех ИТ специалистов и найме новых? Не спешите! Возможно, вам поможет внедрение ITIL.

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

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

История возникновения

Сама идея управления ИТ как бизнесом не нова. Уже в 80ых годах прошлого века по заказу британского правительства Центральное агентство по вычислительной технике и телекоммуникациям (Central Computer and Telecommunications Agency, CCTA) разработало принципы управления ИТ, позволяющие, с одной стороны, использовать имеющиеся ИТ ресурсы максимально эффективно, а с другой - эксплуатировать ИТ с минимальными затратами. Результат выполнения заказа представлял собой свод лучших практик в отрасли, и назывался «библиотекой ITIL (Information Technology Infrastructure Library)». Библиотека ITIL называется библиотекой потому, что состоит из ряда книг, содержащих обобщение практического опыта, так называемые best practiks - лучшие практики отрасли. В 2001 году CCTA вошло в состав OGC (Office of Government Commerce), и с тех пор развитие ITIL осуществляется OCG. В том же году вышла вторая версия библиотеки ITIL.

Основы ITIL

По замыслу разработчиков, ITIL представляет собой практическое расширение сервисного подхода на область информационных технологий (ITSM - information technology service management), основная идея которого состоит в том, что ИТ подразделение предоставляет основному бизнесу не нечто абстрактное, а конкретные сервисы конкретному внутреннему заказчику, для которых определены метрики качества, и с потребителями которых  заключено соглашение об уровне сервиса (SLA - Service Level Agreement).

Для того, чтобы понять эту идею, приведём конкретные примеры. Предположим, есть организация, занимающаяся подбором персонала через Интернет. Для менеджеров, которые осуществляют подбор, установлены следующие нормы: поиск кандидата - 20 минут (включая перенос его резюме во внутреннюю базу данных) 10 минут - на прозвонку и приглашение на собеседование (для упрощения будем считать, что собеседуют кандидата другие менеджеры). Менеджер имеет право на один обед продолжительностью в час и два перерыва по 30 минут. Итого, менеджер за день должен найти минимум 14 кандидатов. Соответственно, у данной категории менеджеров, в рабочее время (с 9 до 18 часов), должен быть обеспечен бесперебойный доступ в Интернет (исключая плавающее время обеда и перерывов), бесперебойный режим работы компьютеров (аналогично), и бесперебойный доступ к местной телефонной связи. Для упрощения также предположим, что менеджер не приступает к поиску следующего кандидата, пока не «отработал» текущего. Таким образом, для менеджера по подбору можно выделить, как минимум, следующие сервисы со следующим SLA:

  • Доступ в Интернет - с 9 до 18, с временем простоя не более 10 минут (в это время он может разговаривать по телефону с потенциальным соискателем).;
  • Работоспособность ПК - с 9 до 18, с временем простоя не более 30 минут (в случае наступления времени простоя менеджер может сделать себе перерыв или пойти на обед);
  • Доступ к внешней телефонной связи - с 9 до 18 с временем простоя не более 20 минут (в это время менеджер может производить поиск кандидата);
  • Доступ к внутренней телефонной связи - с 9 до 18 с временем простоя не более 4 часов (внутренняя связь при описанной системе для менеджера нужна как вспомогательная функция, следовательно, ей назначено самое высокое время простоя);

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

  • Доступ в Интернет - с 9 до 18, с временем простоя не более 2 часов (Интернет ему не нужен для решения производственных задач, но, поскольку он занимает руководящий пост, то время восстановления работоспособности вспомогательного сервиса у него выше, чем у рядового менеджера);
  • Работоспособность ПК - с 9 до 18, с временем простоя не более 30 минут (во время простоя координатор может сделать перерыв или пойти на обед);
  • Доступ к внешней телефонной связи - с 9 до 18 с временем простоя не более 1 часа (работоспособность вспомогательного сервиса у него должна быть восстановлена быстрее, чем у рядового сотрудника);
  • Доступ к внутренней телефонной связи - с 9 до 18 с временем простоя не более 10 минут (этот сервис для этого сотрудника является важным, поскольку требуется оперативный обзвон менеджеров для решения производственных вопросов);

Таким образом, для ИТ подразделения, осуществляющего поддержку, появляются вполне определенные сервисы, которые они должны предоставить, и характеристики этих сервисов, которые должны быть выдержаны.

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

В настоящее время официально опубликована библиотека ITIL версии 3, однако до сих пор не выполнено ее перевода на русский язык, поэтому перечень процессов приводится по ITIL версии 2. Подробнее об ITIL можно прочитать на официальном сайте ITIL: http://www.itil-officialsite.com/, сайтах http://www.itil.org.uk/ и http://en.wikipedia.org/wiki/ITIL

  1. Управление инцидентами (скорейшее разрешение сбойных ситуаций, или инцидентов, представляющих собой отклонения от режима нормального функционирования сервиса)
  2. Управление проблемами (предотвращение возникновения инцидентов)
  3. Управление конфигурациями (хранение описания инфраструктуры и связи между ее элементами)
  4. Управление изменениями (реализация изменений максимально безопасным образом)
  5. Управление релизами (сохранение работоспособности инфраструктуры при проведении изменений)
  6. Управление уровнем сервиса (определение параметров сервиса для конечного потребителя)
  7. Управление финансами (обеспечение финансирования и бюджетирования ИТ)
  8. Управление мощностью (обеспечение необходимых вычислительных мощностей для поддержки сервисов)
  9. Управление непрерывностью (обеспечения непрерывности предоставления ИТ услуг)
  10. Управление доступностью (обеспечение доступности сервисов, катастрофоустойчивость)

Принцип «одного окна» подразумевает организацию службы Service Desk - то есть подразделения в рамках ИТ, ответственного за прием, регистрацию и возможно разрешение части поступающих инцидентов. Инциденты могут поступать в Service Desk по телефону, по электронной почте, через корпоративные сайты, систему документооборота и т.д. ITIL говорит о том, что все обращения клиентов (а под клиентом понимается в первую очередь внутренний заказчик, так как ITIL смотрит на мир «глазами ИТ подразделения») должны быть зафиксированы и обработаны так, чтобы как можно быстрее решить возникшую проблему. Если сотрудники подразделения Service Desk не смогли решить возникший инцидент, он передается далее - на вторую линию поддержки (например, группе системных администраторов), и т.д. Если с большими организациями, как правило, не возникает вопроса, для чего нужен ITIL и Service Desk,  то в случае небольшой организации с маленьким ИТ отделом часто можно услышать мнение, что такого рода служба может оказаться излишней, а философия ITIL - бесполезной и неприменимой. Практика показывает, что в этом случае функцию регистрации инцидентов могут проводить непосредственно сотрудники группы, которая занимается обслуживанием пользователей. Собственно говоря, регистрация всех инцидентов не является самоцелью: с её помощью собирается статистическая информация, на основании анализа которой могут быть сделаны те или иные выводы относительно того, где есть потенциальные «узкие места», где необходима модернизация, иногда - для организации системы мотивации и т.д. Также стоит упомянуть, что библиотека ITIL, будучи собранием передового практического опыта, не требует безусловного следования всем положениям, описанным в ней, и декларирует возможность гибкого встраивания своей философии в реалии конкретной организации практически любого размера. Например, большая организация может получить от внедрения рекомендаций ITIL предсказуемость и управляемость ИТ, средняя - возможность контролировать ИТ бюджет и понимание принципов работы ИТ, небольшая - предвосхищение возможных проблем в ИТ инфраструктуре и т.д. Естественно, что эти преимущества могут мигрировать, то есть в рамках большой организации также будет заметен эффект предвосхищения проблем и т.д.

Итоги

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

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

Внедрение ITSM: памятка для начинающего

Просмотров: 2820Комментарии: 0
Статьи

Ответы на наиболее часто задаваемые вопросы о том, как внедрять управление ИТ-услугами на основе рекомендаций ITIL

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

Прежде всего определимся с часто упоминаемыми терминами, вызывающими путаницу. Управление ИТ-услугами (Information Technology Service Management, ITSM) – это сервисный процессный подход к организации работы ИТ-службы. Суть его в том, что вся деятельность ИТ-подразделения рассматривается в разрезе услуг, оказываемых им другим подразделениям в соответствии с соглашениями об уровне услуг. ITSM декларирует, что ИТ-отделом можно управлять, основываясь на тех же принципах, которые применимы к бизнес-подразделениям.

Библиотека ИТ-инфраструктуры (Information Techno-logy Infrastructure Library, ITIL) – это библиотека рекомендаций, обобщающая международный опыт по организации работы ИТ-департаментов и разъясняющая, что надо сделать для реализации подхода ITSM. ITIIL состоит из ряда книг, каждая из которых описывает тот или иной аспект деятельности в виде набора процессов. В настоящее время выпущена вторая версия ITIL, активно ведется работа над созданием третьей. В ITIL описывается, как должна быть организована деятельность ИТ-структур, но не приводятся конкретные шаги по внедрению содержащихся в ITIL рекомендаций. Конкретные методики внедрения ITSM на основе ITIL предлагают компании, которые специализируются на подобных проектах.

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

Сотрудникам же бизнес-подразделений следует объяснить, что внедрение рекомендаций ITIL обеспечит им более качественное обслуживание, сокращение времени возможных простоев и перебоев, а также быстрое рассмотрение и реакцию на все без исключения обращения в ИТ-службу. У них появится уверенность в том, что каждое обращение будет отработано по принятым правилам в установленный срок.

Для получения финансирования проекта по внедрению ITSM часто необходимы убедительные обоснования. В зависимости от конкретного случая это могут быть следующие три основных аргумента.

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

Увеличение эффективности и направление фокуса ИТ-деятельности на решение задач бизнеса.

Внедрение даже ограниченного набора процессов ITIL (службы Service Desk и процессов управления инцидентами и уровнем услуг) позволит организовать работу ИТ-службы таким образом, что в центре ее внимания окажется именно бизнес. ИТ-отдел из «вещи в себе» превратится в ориентированную на потребности бизнеса внутреннюю сервисную структуру.

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

Дополнительным аргументом может служить ответ на вопрос об окупаемости проекта по внедрению ITSM. Стоимость решения заявки на этапе промышленной эксплуатации решения, состоящего из процессной части и настроенной системы автоматизации в случае, когда внедрена часть процессов ITIL, по сравнению с ситуацией, когда не внедрен ни один из процессов, в пересчете на единицу времени оказывается ниже. Таким образом, окупаемость проекта по внедрению рекомендаций ITSM может быть вычислена для каждой конкретной организации. В простейшем случае рассчитываются стоимости единицы рабочего времени специалиста каждой из линий поддержки до и после внедрения. Более сложный расчет учитывает стоимость возможного простоя сотрудников бизнес-подразделений, стоимость аренды помещений и т.д.

Следует ли затраты на ИТ распределять по бизнес-подразделениям и бизнес-пользователям?

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

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

С чего начать внедрение? Какие процессы внедрять?

Проект по внедрению рекомендаций ITIL, как и любой другой, связанный с управлением, следует начать с определения бизнес-требований и анализа состояния дел ИТ-департамента. Для анализа можно применять известные методики (например, Pink Elephant, HP ITSM) или самостоятельно составленные опросные листы. Как правило, дополнительно проводится анализ по бизнес-модели: делается описание того, как работает ИТ-отдел в данный момент, в виде связанной совокупности бизнес-процессов. Следует отметить, что такой анализ полезен даже в случае полной деструктурированности работы ИТ, поскольку помогает выявить внутренние зависимости и связи, опираясь на которые, можно будет спроектировать тот или иной процесс.

Одновременно с построением картины работы «как есть» проводится анализ бизнес-требований к ИТ-отделу на основе сбора и обобщения требований и ожиданий бизнеса от ИТ и возможностей ИТ-службы удовлетворить потребности бизнес-подразделений.

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

Как установить соответствие между услугами, которые бизнес желает (или ожидает) получить от ИТ-подразделения, и ИТ-услугами?

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

Какие фазы внедрения ITSM существуют? Что влияет на его успешное завершение?

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

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

Обязательно ли организовывать Service Desk?

Внедрение службы Service Desk целесообразно по нескольким причинам. Большинство современных средств автоматизации предусматривает возможность регистрации инцидентов самим пользователем (посредством Web-форм, например). Однако пользователь порой не в состоянии квалифицированно определить суть инцидента. Но даже если он может провести самостоятельную классификацию, все равно требуется уточнение (или, как минимум, подтверждение) специалиста. Автоматизированный ввод инцидентов самим пользователем не отменяет механизма ввода и диспетчеризации оператором Service Desk, поскольку в ряде случаев пользователь просто не имеет возможности завести заявку (инцидент) для автоматической обработки (например, при отсутствии технической возможности доступа к интерфейсу Service Desk).

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

При отказе от Service Desk более вероятно возникновение «очередей» заявок у высококвалифицированных ИТ-специалистов, которые будут совершенно неэффективно тратить свои ресурсы. Запуск же квалифицированной службы Service Desk позволяет спустя некоторое время разрешать до 70% заявок на первой линии благодаря накоплению базы знаний и другим преимуществам правильно организованных процессов. Это экономит время высокооплачиваемых специалистов, и они могут направить его для решения более важных задач. Оставшиеся 30% заявок маршрутизируются таким образом, что гарантируется их скорейшее решение.

При отсутствии службы Service Desk ее функции выполняет вся ИТ-служба.

Как оценить численность сотрудников Service Desk?

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

В целом, исходя из накопленного опыта, можно утверждать, что на тысячу пользователей достаточно трех-пяти операторов Service Desk.

Нельзя ли обойтись при внедрении рекомендаций ITIL без автоматизированной системы?

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

Если в компании уже есть система учета заявок, обязательно ли внедрять специализированный продукт для управления ИТ?

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

Может ли ITSM помочь при внедрении ERP (CRM и т.д.)?

Если в организации внедрен один или несколько процессов в соответствии с рекомендациями ITIL, безусловно, может. Служба Service Desk возьмет на себя ответы на запросы пользователей и регистрацию инцидентов, связанных с новой системой. Эти инциденты будут разрешаться в рамках процесса управления инцидентами, анализироваться и использоваться для выявления проблем в рамках процесса управления проблемами. Разрешение инцидентов будет происходить путем проведения изменений в рамках процесса управления изменениями, а информация о конфигурации инфраструктуры будет постоянно актуальной вследствие работы процесса управления конфигурациями. Расчет мощностей, требуемых для внедрения новой системы, будет проведен в рамках процесса управления мощностями, в рамках процесса управления доступностью будут сформированы требования, удовлетворение которых обеспечит требуемый уровень доступности. В рамках процесса управления непрерывностью будет сформирован план обеспечения непрерывности для ERP-системы, финансы на приобретение требуемых серверов и поддержку программно-аппаратного комплекса формируются в рамках процесса управления финансами, мероприятия по обеспечению безопасности конфиденциальных данных в ERP будут обеспечены в рамках процесса управления безопасностью. Далее, имея организованную в соответствии с определенными регламентами службу ИТ, легче проводить планирование внедрения, поскольку при четкой организации деятельности ИТ повышается прозрачность и управляемость ИТ.

Отдельно следует рассмотреть параллельное внедрение ERP и ITSM. В этом случае вероятность успешного завершения каждого из проектов будет ниже, чем при последовательном внедрении. Дело в том, что и тот и другой проект относятся к так называемым «стрессовым» проектам, требующим перестройки как ИТ-службы, так и бизнес-подразделений. Таким образом, на время параллельного внедрения ERP и ITSM повышается нагрузка на сотрудников, возрастает неопределенность и влияние человеческого фактора, в итоге значительно повышаются риски подобного проекта.

Чем ITSM может помочь при организации аутсорсинга?

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

Обязательно ли использовать консалтинг при внедрении ITSM?

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

Что будет, когда закончится проект?

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

Размещено: Директор ИС, №03/2007

Каталог сервисов. Подводные камни.

Просмотров: 1866Комментарии: 0
Статьи

Распространенная задача, решать которую приходится практически во всех ИТ отделах, пытающихся применить принципы сервисного управления – построение, развитие и управление каталогом сервисов. Задача эта на первый взгляд достаточно тривиальная, однако и при ее решении существуют определенные «подводные камни».

Например, при решении задачи «в лоб», каталог сервисов часто заменяют на перечень эксплуатируемых ИТ систем и базового ПО. Подобный подход имеет ярко выраженный недостаток: при инвентаризации в средней компании (то есть, с числом АРМ порядка 500) может быть обнаружено порядка 100..300 систем и приложений, которые могут быть классифицированы как сервис. Таким образом, пользователь, обращаясь в ИТ для решения каких-либо вопросов, вынужден формулировать свой запрос «на языке ИТ», что принципиально противоречит рекомендациям ITIL. Другая крайность – чересчур широкое определение сервиса. Например, сервис «рабочее место пользователя» может включать в себя ПК, базовое ПО, специфическое ПО и периферийные устройства, что приближает количество инцидентов, связанных с данным сервисом, к 100% от общего числа зарегистрированных инцидентов.

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

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

Таким образом, примерный алгоритм построения каталога сервисов будет следующим:

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

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

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

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

Управление каталогом сервисов включает в себя:

  • Мониторинг текущего каталога сервисов
  • Выявление новых сервисов
  • Выявление новых территорий, требующих разворачивания тех или иных ИТ сервисов
  • Выявление утративших актуальность сервисов
  • Актуализация каталога сервисов

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

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

ИТ и бизнес: пение в унисон

Просмотров: 1120Комментарии: 0
Статьи

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

Рассмотрим типичную картину – среднестатистическое предприятие, у которого 300 работников, центральный офис, два филиала и пять точек продаж. В наличии имеется локальная сеть, самостоятельно разработанный комплекс ERP/CRM, реализована система мобильных продаж, интегрированная с ERP, и десяток серверов. ИТ-отдел содержит всю эту инфраструктуру и обеспечивает поддержку пользователей. Знакомая картина?

Типичные проблемы на таком предприятии – слишком "узкий" канал передачи данных до филиалов, необходимость постоянных доработок ERP, нехватка квалифицированных специалистов. Скажем, если ваш единственный системный администратор в отпуске, то все работы по подключению новой точки продаж просто встанут, и никто не сможет его заменить, как обладателя уникальных знаний о когда-то настроенной им системе. Кроме того, ИТ-подразделения и обслуживаемая им инфраструктура постоянно страдают от нехватки финансирования; обычная аргументация при этом: "Зачем тратить деньги, если и так все работает?". А если что-то не работает, от топ-менеджеров тут же следует волевое указание "разобраться, наказать, устранить и доложить в кратчайшие сроки". В результате бизнес стоит, продажи теряются, компания несет убытки: в такой ситуации уже не до финансирования ИТ. Вот и получатся, что начальник отдела ИТ либо мальчик на побегушках, либо груша для битья, а его подразделение сильно напоминает пожарную команду.

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

  • Бизнес не понимает (и не хочет понимать) процессов внутри ИТ. ИТ для бизнеса – "черный ящик";
  • Бизнес позиционирует ИТ как обслуживающий отдел;
  • Бизнес не в состоянии адекватно оценить риски, связанные с теми или иными компонентами ИТ;
  • Бизнес считает вложения в ИТ избыточными.

Законное требование бизнеса - понять, а на что, собственно, расходуются заработанные им деньги? На сервер? Помилуйте, у вас же их целая комната! На Интернет? На какой Интернет? Выделенный? Обойдетесь и обычным модемом – в соседней компании через него работает десять человек, и никто пока не жаловался. На программное обеспечение? Такую сумму?! Когда то же самое можно купить за сто рублей в переходе метро?!

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

Однако в решении данных проблем Россия не является первопроходцем. В этом смысле показательна ситуация, сложившаяся в ИТ службе правительства Великобритании в 80-ых гг. которое дало задание агентству CCTA (ныне OGC) разработать рекомендаций по максимально эффективному использованию ИТ ресурсов. Результатом проделанной работы стала библиотека ITIL (Information Technology Infrastructure Library). Основные ее принципы остались неизменными до сих пор – это сервисная модель работы, измерение и контроль качества услуг, а также построение отношений между бизнесом и ИТ на базе договоров об уровне обслуживания (Service Level Agreement – SLA). Для реализации этих основных принципов ITIL рекомендует использование определенных процессов управления ИТ, такими, как управления инцидентами, изменениями, конфигурациями, уровнем обслуживания, мощностями, доступностью и др.

ITIL рекомендует выстраивание проверенной на опыте цепочки управления ИТ и взаимодействия ИТ и бизнеса: организация единой точки контакта с пользователями (Service Desk), отказ от обращений пользователей напрямую к специалистам ИТ, регистрация всех обращений пользователей, анализ обращений пользователей, выстраивание "линий поддержки пользователей", определение уровней обслуживания, критерии оценки сервиса и т.п.

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

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

Другая область предпочтительного внедрения рекомендаций ITIL – там, где запланировано внедрение крупных ERP-систем. Дело в том, что внедрение на предприятии таких систем, будь то SAP, Oracle или Axapta, особенно если до этого там работала доморощенная управленческая система, подразумевает определенную перестройку сознания и требует другого уровня подготовки пользователей. С первых же шагов перехода на новую систему возникает лавина вопросов к группе внедрения. Именно в этот момент единая служба поддержки может значительно сэкономить нервы и время как пользователям, так и внедренцам.

Без применение рекомендаций ITIL нельзя обойтись при подготовке предприятия к ИТ-аутсорсингу. Действительно, после внедрения процессов ITIL нет разницы, кто поставляет услуги ИТ – внутренний отдел или внешняя компания. Другое дело, что при передаче того или иного сервиса ИТ на аутсорсинг нужно иметь четкое представление – что выигрывает бизнес от такого шага? Возможно, внешняя компания предлагает на более выгодных условиях или лучшего качества, предоставляет уникального и "дорогого" специалиста (которого иначе пришлось бы содержать самим) или реализует услугу, которая не по силам внутреннему отделу ИТ. Естественно, что в любом случае уровень сервиса должен отслеживаться в соответствии с рекомендациями ITIL.

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

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

Опубликовано: Сети и системы связи (газета на выстаку Inerop2007)