В продолжение цикла.
В первой части мы определились, требуется ли вам построение службы service desk.
На втором этапе вам необходимо понять, какие же именно услуги оказывает ваша служба технической поддержки. Это часть процесса управления портфелем услуг (Service Portfolio Management). Вам необходимо понят что ваша служба технической поддержки должна делать и, что не менее важно, что она не должна делать.
Для этого формируется портфель услуг. Согласно классической методологии в портфель входят все услуги, предоставляемые, разрабатываемые и уже выведенные из эксплуатации услуги.
Услуги делятся на основные, вспомогательные и дополняющие. Услуги внешние и внутренние.
Мы рассматриваем ситуацию, когда ИТ отдел предоставляет услуги внутри компании (т.е. все услуги внутренние) и уже имеется некоторый опыт работы отдела, на основании которого можно формировать портфель услуг.
Согласно методологии ITIL это отдельный процесс — процесс управления взаимоотношением с бизнесом (BRM). Цель данного процесса — наладить взаимодействие между ИТ отделом и бизнесом. Следить, что ИТ понимает потребности бизнеса, а бизнес понимает возможности ИТ. Именно человек, отвечающий за взаимоотношения с бизнесом, должен выстраивать диалог. Как правило, это — ИТ-директор либо руководитель ИТ-службы.
При составлении портфеля основных услуг важно оперировать не техническими, а бизнес-терминами. Бизнесу не нужны сервера, бизнесу не нужны файловые хранилища. Бизнес хочет получать прибыль.
Поэтому услуги должны звучать как: торговля, хранение файлов, система подсчета посетителей, система учета рабочего времени и т.д.
Это значит, что ИТ служба берет на себя обязательство по предоставлению данной услуги. Если данная услуга не предоставляется, то бизнес не интересует почему именно она не предоставляется. Его интересует только, когда будет восстановлено и как избежать рецидива?
В портфель так же необходимо включать вспомогательные (технические) услуги, на которых базируются бизнес услуги. Они мало интересны бизнесу, но их необходимость и значимость придется отстаивать при формировании портфеля. Они служат основой для функционирования бизнес-услуг.
На мой взгляд, при первичном формировании портфеля услуг необходимо сделать список услуг, описание услуг, указать время доступности услуги, технологические окна и выяснять критичность услуги для бизнеса. Задавать SLA на этом этапе, по моему мнению, еще не следует. Исходя из критичности услуг можно записать пожелания бизнеса к уровню сервиса. И только спустя некоторое время при реальной эксплуатации данной услуги можно делать какие-либо выводы и начинать писать соглашения об уровне сервиса, который ИТ служба сможет реально гарантировать.
Наверняка в вашей компании уже есть какой-то опыт оказания технической поддержки пользователям. Исходя из этого опыта и профиля работы компании можно начать формирование списка оказываемых услуг. Это будет первый шаг.
Второй шаг — стоит определиться с требованиями бизнеса к услугам и составить описание услуг. Что бизнес считает приемлемым уровнем предоставления услуги, а что нет.
Для примера рассмотрим бизнес услугу “хранение данных”. В описании услуги можно прописать, что ИТ отдел гарантирует каждому сотруднику компании выделенное место в размере 1 Гб на корпоративном сетевом хранилище с возможностью совместного доступа. Время доступности услуги с 9:00 до 21:00. При этом данная услуга основывается на таких технических услугах как “поддержка серверов и кластеров”, “локальная вычислительная сеть”, “СХД и сетевые хранилища”, “резервное копирование данных”.
После этого необходимо определить ценность данной услуги для бизнеса. Если это просто файловое хранилище с фотографиями с корпоратива, то ценность данной услуги не очень велика и бизнес не сильно пострадает в случае ее простоя. Если же это один из основных инструментов при взаимодействии с клиентами, то даже минимальный простой данной услуги обернется большими денежными потерями.
После определения ценности услуги можно определяться с пожеланиями к уровню сервиса и финансами. Исходя из критичности услуги можно определить какой приоритет выставлять инцидентам, связанным с этой услугой, какие средства нужны для ее предоставления на заявленном уровне. Исходя из дальнейшей практики эксплуатации услуги можно будет корректировать либо финансовое обеспечение, либо пожелания к уровню сервиса.
После того как вы определились с каталогом услуг вы можете переходить к следующему этапу — созданию единого окна, точки входа. По сути — формирование процесса инцидент менеджмента.
Об этом более подробно буду рассказывать в следующей статье.
В первой части мы определились, требуется ли вам построение службы service desk.
На втором этапе вам необходимо понять, какие же именно услуги оказывает ваша служба технической поддержки. Это часть процесса управления портфелем услуг (Service Portfolio Management). Вам необходимо понят что ваша служба технической поддержки должна делать и, что не менее важно, что она не должна делать.
Для этого формируется портфель услуг. Согласно классической методологии в портфель входят все услуги, предоставляемые, разрабатываемые и уже выведенные из эксплуатации услуги.
Услуги делятся на основные, вспомогательные и дополняющие. Услуги внешние и внутренние.
Мы рассматриваем ситуацию, когда ИТ отдел предоставляет услуги внутри компании (т.е. все услуги внутренние) и уже имеется некоторый опыт работы отдела, на основании которого можно формировать портфель услуг.
Согласно методологии ITIL это отдельный процесс — процесс управления взаимоотношением с бизнесом (BRM). Цель данного процесса — наладить взаимодействие между ИТ отделом и бизнесом. Следить, что ИТ понимает потребности бизнеса, а бизнес понимает возможности ИТ. Именно человек, отвечающий за взаимоотношения с бизнесом, должен выстраивать диалог. Как правило, это — ИТ-директор либо руководитель ИТ-службы.
При составлении портфеля основных услуг важно оперировать не техническими, а бизнес-терминами. Бизнесу не нужны сервера, бизнесу не нужны файловые хранилища. Бизнес хочет получать прибыль.
Поэтому услуги должны звучать как: торговля, хранение файлов, система подсчета посетителей, система учета рабочего времени и т.д.
Это значит, что ИТ служба берет на себя обязательство по предоставлению данной услуги. Если данная услуга не предоставляется, то бизнес не интересует почему именно она не предоставляется. Его интересует только, когда будет восстановлено и как избежать рецидива?
В портфель так же необходимо включать вспомогательные (технические) услуги, на которых базируются бизнес услуги. Они мало интересны бизнесу, но их необходимость и значимость придется отстаивать при формировании портфеля. Они служат основой для функционирования бизнес-услуг.
На мой взгляд, при первичном формировании портфеля услуг необходимо сделать список услуг, описание услуг, указать время доступности услуги, технологические окна и выяснять критичность услуги для бизнеса. Задавать SLA на этом этапе, по моему мнению, еще не следует. Исходя из критичности услуг можно записать пожелания бизнеса к уровню сервиса. И только спустя некоторое время при реальной эксплуатации данной услуги можно делать какие-либо выводы и начинать писать соглашения об уровне сервиса, который ИТ служба сможет реально гарантировать.
Наверняка в вашей компании уже есть какой-то опыт оказания технической поддержки пользователям. Исходя из этого опыта и профиля работы компании можно начать формирование списка оказываемых услуг. Это будет первый шаг.
Второй шаг — стоит определиться с требованиями бизнеса к услугам и составить описание услуг. Что бизнес считает приемлемым уровнем предоставления услуги, а что нет.
Для примера рассмотрим бизнес услугу “хранение данных”. В описании услуги можно прописать, что ИТ отдел гарантирует каждому сотруднику компании выделенное место в размере 1 Гб на корпоративном сетевом хранилище с возможностью совместного доступа. Время доступности услуги с 9:00 до 21:00. При этом данная услуга основывается на таких технических услугах как “поддержка серверов и кластеров”, “локальная вычислительная сеть”, “СХД и сетевые хранилища”, “резервное копирование данных”.
После этого необходимо определить ценность данной услуги для бизнеса. Если это просто файловое хранилище с фотографиями с корпоратива, то ценность данной услуги не очень велика и бизнес не сильно пострадает в случае ее простоя. Если же это один из основных инструментов при взаимодействии с клиентами, то даже минимальный простой данной услуги обернется большими денежными потерями.
После определения ценности услуги можно определяться с пожеланиями к уровню сервиса и финансами. Исходя из критичности услуги можно определить какой приоритет выставлять инцидентам, связанным с этой услугой, какие средства нужны для ее предоставления на заявленном уровне. Исходя из дальнейшей практики эксплуатации услуги можно будет корректировать либо финансовое обеспечение, либо пожелания к уровню сервиса.
После того как вы определились с каталогом услуг вы можете переходить к следующему этапу — созданию единого окна, точки входа. По сути — формирование процесса инцидент менеджмента.
Об этом более подробно буду рассказывать в следующей статье.
SinTeZoiD
А вот это уже надо решать с представителями бизнеса. И вытягивать эту информацию непосредственно из них. Ситуации они разные бывают. Понятно, что можно прикинуть на глаз, но финальное решение должно быть за представителем бизнеса.
victor_2004
И не просто вытягивать, а вытягивать, фиксировать на бумаге и заставлять понять под чем они подписались.
Чтобы потом не было жалоб — «мы тут целого одного специалиста наняли на полставки на парк в 700 машин и 20 серверов. а он негодник, второй день динамит заявку. что у Марь Ивановны на ресепшене обои на рабочем столе надо поменять. Ну и что что мы подписались. что сервера и отдел продаж чинятся в первую очередь? Марьивановна недовольна, ИТ плохо работают. „
Ибо даже подписав соглашения бизнес не всегда понимает под чем он подписался.
SinTeZoiD
А вот как заставить понять? Тыкать лицом в соглашение в случае таких проблем? Отдельно проговорить перед подписанием? Я просто плохо представляю как можно заставить понять кого-то в принципе)