Что такое сервисная модель

Что такое сервисная модель

О том, почему развитие сервисной модели администрирования ИТ в России отличается от западного рынка, а также о преимуществах сотрудничества с Managed Service Provider для бизнеса рассказала директор по развитию сервисов ГК ITGLOBAL.COM Алина Пархоменко.

Что такое «сервисная модель»?

В ИТ-сфере, конечно, тоже используется сервисная модель. Размещение в ЦОДах, аренда оборудования, IaaS, различные облачные приложения типа 1С, CRM, телефонии и пр. прочно вошли в обиход. Казалось бы, теперь компаниям не нужно нанимать огромный штат инженеров, ведь множество задач, связанных с ИТ, можно передать провайдерам этих услуг. Но ИТ-отделы продолжают заниматься огромным количеством рутинных операций самостоятельно.

В чем отличие сервисной модели ИТ на Западе и в России?

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

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

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

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

Если компании все же решаются воспользоваться аутсорсинговой моделью, какие задачи они чаще всего делегируют провайдерам?

Как устроена работа MSP на примере управления инфраструктурой заказчиков?

— Перед началом работы провайдеру необходимо провести аудит существующей инфраструктуры и процессов, которые уже налажены в компании. Затем MSP предлагает варианты модернизации и оптимизации (roadmap), подбирает подходящие для этих задач локации и облака. После настройки мониторинга и логирования и постановки на бэкап всех ВМ, провайдер должен оперативно реагировать на инциденты 24/7, заниматься обновлением ОС и типовыми сервисами.

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

Какое развитие ждет сервисную модель на российском ИТ-рынке?

Источник

Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

ИСПОЛЬЗОВАНИЕ ITIL 4 ДЛЯ СОЗДАНИЯ СТАНДАРТНОЙ СЕРВИСНОЙ МОДЕЛИ

Для оценки существующего положения дел в вашей организации или любой существующей сервисной модели отличным инструментом является модель непрерывного совершенствования ITIL (см. диаграмму ниже).

В дополнение к использованию модели непрерывного совершенствования в качестве способа анализа и оценки текущего состояния стандартной сервисной модели полезно использовать руководящие принципы ITIL 4. Это может быть чрезвычайно полезно для того, чтобы убедиться, что созданная стандартная сервисная модель отвечает целям её создания.

КАК МОЖНО ИСПОЛЬЗОВАТЬ РУКОВОДЯЩИЕ ПРИНЦИПЫ ITIL 4 ДЛЯ СОЗДАНИЯ СТАНДАРТНОЙ СЕРВИСНОЙ МОДЕЛИ

Применение семи руководящих принципов поможет достичь того, что в ITIL 4 описывается как «совместное создание ценности». А «правильная» стандартная сервисная модель станет ценным сервисным активом.

Источник

Роль технической поддержки в работе облачного провайдера

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

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

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

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

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

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

Основные обязанности специалистов службы технической поддержки:

Рассмотрим подробнее эти обязанности.

Как сотрудники технической поддержки узнают о сбоях в инфраструктуре

Для максимально эффективной работы облачные провайдеры не только ориентируются на стандарты и лучшие мировые практики, но и строят собственную ресурсно-сервисную модель.

Ресурсно-сервисная модель и служба технической поддержки

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

В состав облачных услуг IaaS или VPS входя следующие компоненты:

Услуги IaaS или VPS зависят от работоспособности физических серверов, систем хранения, услуг Интернет-провайдеров и дата-центров, где размещается оборудование провайдера.

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

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

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

Системы мониторинга

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

Система SCOM

Средства мониторинга Zabbix

Эта система распространяется под лицензией GNU, и позволяет наблюдать за сетевыми сервисами, серверами и сетевым оборудованием. Она поддерживает несколько видов мониторинга:

В случае появления инцидента эта система мониторинга также позволяет немедленно информировать администраторов через e-mail или telegramm.

Оповещение клиентов о сбоях

При возникновении сбоя специалист следует своей инструкции. В этих инструкциях прописаны необходимые действия. Они могут быть или линейными, или ветвящимися, в зависимости от особенности проблемы. Можно выделить следующим типы инцидентов:

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

В случае масштабной проблемы, когда требуется высокая срочность принятия решений, ответственный за тот или иной компонент ресурсно-сервисной модели выбирает стратегию решения этой проблемы. Обычно при возникновении такой проблемы в службу поддержки поступает большое количество заявок, и эти заявки объединяются с основной (родительской) проблемой. Поэтому как только основная проблема разрешается, все связанные с этой проблемой заявки (дочерние) тоже автоматически закрываются.

Help Desk и работа с запросами пользователей

Запросы пользователей могут приходить по различным каналам: телефону, e-mail, через форму обратной связи. Каждому обращению, как и в случае с инцидентами, присваивается номер и создается соответствующий тикет в системе Help Desk. Цель Help Desk системы, помимо исключения потери заявок от клиентов, максимально быстро решить возникшую проблему или выполнить запрос пользователя. Это в первую очередь влияет на конечную удовлетворенность клиентов. Если заявки решаются в соответствии с ожиданиями потребителей услуг, то клиенты будут довольны и не будет искать другого провайдера.

Таким образом, Help Desk система напрямую влияет на срок взаимодействия клиента с провайдером. Как показывают различные исследования, это критически важно, потому что:

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

Все системы Help Desk можно разделить на 3 основных класса:

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

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

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

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

Источник

Применение сервисно-ресурсной модели как эффективного инструмента ИТ-службы

В открытых источниках все чаще можно встретить сообщения об ITSM-проектах, одной из задач которых является разработка сервисно-ресурсных моделей

Вадим Голубцов — ITSM-консультант, Computel System Management, VGolubtsov@computel.ru

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

В общем случае методика построения сервисно-ресурсных моделей, по нашему мнению, должна как минимум определять следующие аспекты:

• понятия и термины, используемые при построении СРМ: сервис, ресурс, сервисно-ресурсная модель, качество и т. д.;

• назначение и цели создания СРМ: каковы функции моделей и для каких целей они могут быть использованы;

• определение ключевых принципов и правил построения СРМ: в частности, определение формата построения (в виде документа, схемы или рисунка), правил автоматизации, типов компонентов и их связей и т. д.;

• определение правил использования и поддержки СРМ: какие действия необходимо выполнять, чтобы все построенные модели продолжали исполнять свое назначение с течением времени, кто является участниками данного процесса и каковы их обязанности.

Сформулированные в статье принципы и рекомендации построения СРМ основываются на проектном опыте авторов. Для иллюстрации сформулированных принципов методика описывается на базе одного из проектов, выполненных авторами (см. врезку).

Проект по построению системы управления ИТ

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

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

Михаил Федоренко — руководитель ITSM-практики, Computel System Management, MFedorenko@computel.ru

Терминология СРМ

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

В библиотеке ITIL v3 2011 Edition в книге Service Strategy приведено определение модели сервиса, на наш взгляд, наиболее близкое к СРМ: модель сервиса (service model) — модель, показывающая, как сервисные активы взаимодействуют с активами заказчика для создания ценности. Модели сервиса описывают структуру сервисов (взаимодействие конфигурационных единиц друг с другом) и сервисы в динамике (деятельность, потоки ресурсов, взаимодействия). Модель сервиса может быть использована как шаблон для нескольких сервисов.

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

Сервисно-ресурсная модель (СРМ) — это логическая модель сервиса, описывающая состав и взаимосвязи конфигурационных единиц (ресурсов), которые совместно обеспечивают предоставление сервиса на согласованном уровне.

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

Назначение СРМ

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

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

Как и другие модели, СРМ предназначены для создания упрощенного представления объекта реального мира, его структуры, поведения и взаимодействия с окружающим миром. В каких ситуациях может быть полезно создание представления сервиса в виде сервисно-ресурсной модели?

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

В процессе управления уровнем обслуживания (SLM) СРМ позволит уже на начальных этапах жизненного цикла сервиса при сборе требований и согласовании проекта сервиса выделить его компоненты, их характеристики, а также связи между собой и со смежными сервисами и компонентами, за счет чего может быть оценена стоимость внедрения нового сервиса.

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

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

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

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

В области управления финансами использование СРМ может помочь в учете затрат на предоставление сервисов, а также в определении себестоимости сервиса, которая включает:

• затраты на персонал, обслуживающий компоненты сервиса;

• амортизацию основных средств — компонентов сервиса (серверное оборудование, ПО, оргтехника и т. д.);

• затраты на поддерживающие сервисы (каналы связи, резервное копирование и т. д.);

• затраты на расходные материалы.

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

Применение СРМ возможно не только в процессах эксплуатации сервисов, таких как управление инцидентами, проблемами, доступом, но и в процессах стратегии, проектирования и преобразования сервисов (в терминах ITIL v3).

Однако необходимо четко понимать, что создание СРМ целесообразно далеко не для всех компаний, а также не для всех сервисов. Простые с технологической точки зрения сервисы (сервис формируется на базе единого программно-аппаратного комплекса «коробочного» типа, в котором большинство параметров и взаимосвязей заданы жестко) часто не имеет смысла разбивать на компоненты; легче представлять сервис в виде «черного ящика» с определенными макрохарактеристиками. Например, сервис «Обеспечение функционирования системы Service Desk», имеющий стандартизованные компоненты, определенные вендором, часто имеет смысл учитывать только с точки зрения «работает — не работает», а сервис «Обеспечение функционирования автоматизированной банковской системы» — разбивать на компоненты и оперативно контролировать связи между ними.

Одной из ключевых целей использования СРМ является мониторинг параметров качества ИТ-сервиса, который может выполняться в рамках процесса управления доступностью. Что подразумевается под качеством сервиса? Для начала приведем определение термина «качество» согласно ISO 20000.

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

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

Рисунок

Порядок создания СРМ

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

Мы используем в проектах общую методику построения СРМ, состоящую из следующих пяти шагов:

• формирование каталога ИТ-сервисов, включая выбор бизнес-процесса, разделение его на бизнес-функции и определение ИТ-сервисов;

• определение параметров качества ИТ-сервисов и целесообразности создания СРМ;

• проектирование СРМ и методов расчета показателей качества сервисов;

• контроль параметров качества сервисов.

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

Поделитесь материалом с коллегами и друзьями

Источник