Постановка комплекса задач сервисно-ресурсной модели предоставления ИТ-сервисов

Скачать текст в WORD

1.3.1.Управление конфигурациями

 

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

Рисунок 5 – Структура CMDB

 

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

Реализация данного процесса поможет дать данные о следующем:

  1. Финансовая информация (конфигурационные единицы, применяемые в настоящее время по каждому сервису; первоначальная стоимость КЕ, стоимость на текущий момент и их остаточная стоимость; КЕ, подлежащие модернизации и КЕ, подлежащие выводу из продуктивной среды; стоимость замены и обновления устаревших КЕ; наличие лицензий и их объем применения; условия по контрактам с внешними поставщиками; степень стандартизации ИТ-инфраструктуры).
  2. Выявление неисправностей и оценка результатов (способ подключения оборудования к корпоративной сети; описание программных модулей, которые входят в каждый из комплектов ПО; сервисы, на которые оказывают влияние незакрытые инциденты и проблемы; КЕ, наиболее часто вызывающие инциденты).
  3. Предоставление сервисов и выставление счетов [10].

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

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

  • управления конфигурационными единицами – каждый сервис включает одну либо несколько КЕ, и данный процесс контролирует, что происходит с этими единицами;
  • повышения качества ИТ-сервисов – процесс управления конфигурациями помогает в обработке изменений, обнаружении и устранении проблем, а также технической поддержке пользователей. Это способствует уменьшению числа ошибок, улучшению качества предоставляемых сервисов и сокращению затрат, улучшает процесс управления проблемами;
  • управление конфигурациями помогает в определении КЕ, затронутых проблемой, и контролирует модификацию и замену данных КЕ;
  • контроля лицензий ПО – в CMDB отображается число приобретенных лицензий ПО, их применение в динамике, а также срок истечение лицензий по продуктам, которые используются;
  • более точного планирования расходов — СMDB предоставляет данные о затратах на контракты и сопровождение, лицензии и продукцию с истекшим сроком эксплуатации [12].

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

ITIL рекомендует выделить роль владельца процесса, который будет решает следующие задачи:

  • принятие решения об уровне детализации процесса;
  • разработка системы определения уникальности и присвоении имен;
  • разработка средств автоматизации и взаимодействия с другими процессами;
  • формирование отчетов;
  • обучение персонала и написание инструкций;
  • организация аудиторских проверок [13].

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

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

 

 

1.3.2  Управление изменениями

 

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

Главными точками принятия решения о внедрении изменения являются руководитель процесса управления изменениями и координаторы изменений – лица, ответственные за предварительный просмотр и классификацию запросов на изменения.

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

Цель процесса управления изменениями – это применение стандартных методов и процедур для оперативной обработки изменений с минимальным возможным отрицательным влиянием изменения на качество бизнес-сервисов. Это означает, что в ситуации, когда изменение несет за собой большое количество инцидентов, процесс позволяет оперативно и с высокой точностью дать ответ на вопрос «что изменилось?».

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

Процесс управления изменениями состоит из следующих этапов:

  1. 1. Создание запроса на изменение. На этом этапе регистрируются запросы, полученные от пользователей или от других процессов. Здесь же происходит классификация изменений на стандартные – утвержденные, регламентные изменения, которые проводятся в рабочем порядке и оказывают низкое влияние на качество сервиса и на все остальные.
  2. Прием в обработку – предварительное согласование владельцев сервиса и обработка аналитиками. Запрос на изменение проходит согласование владельцев бизнес-сервиса, после чего попадает к аналитику для проверки на логичность, практичность, полноту информации. Если часть критериев не удовлетворяет требованиям запрос на изменение отклоняется, при этом уведомляется заказчик для возможности повторного обоснования своего запроса.
  3. Классификация – на этом этапе определяется приоритет и категория изменения. Приоритет показывает то, что насколько более важным является текущий запрос по сравнению с другим. Автор предлагает использовать следующую классификацию приоритетов. Обычный приоритет – плановое изменение без высокой срочности и не несущее большого влияния на бизнес. Высокий приоритет – изменение затрагивающее большое количество пользователей, исправляющее серьезную ошибку. Наивысший приоритет – запрос для решения проблемы, затрагивающей критический для бизнеса сервис. Например, исправление серьёзной ошибки в системе расчета заработной платы за несколько дней до выплат [15].
  4. Планирование – написание технического задания, расчет необходимых ресурсов для реализации изменения. На этом этапе анализируются затраты и выгоды. Также подвергается анализу техническая составляющая запроса. Важным пунктом является получение согласование от бизнеса по части соответствия функциональности.
  5. Координация – координирование состава, тестирования и проведения изменений. На этом этапе все согласованные и утвержденные изменения доводятся до разработчиков. Перед внедрением происходит тестирования. В создании, испытании и внедрении утвержденных изменений важную роль играет процесс управления релизами. Необходимо уделять огромное внимание вопросам информирования сотрудников компании для поддержки изменений. Тестирование изменения проводится как представителями от бизнеса, которые проверяют его функциональность, так и теми, кто поддерживает систему, на наличие инструкций и совместимость с зависимыми сервисами [16].
  6. Оценка и закрытие – оценка успешности изменения и закрытие заявки. На этом этапе необходимо оценить привело ли изменение к намеченной цели, возникли ли инциденты, связанные с изменением, был ли превышен лимит по ресурсам.

При внедрении процесса управления изменениями компания получит следующие преимущества при использовании процесса:

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

 

1.3.3 Процесс управления релизами

 

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

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

Задача процесса управления релизами состоит в обеспечении качества рабочей среды за счет применения регламентных процедур и тестирования при вводе в работу новых версий. По сравнению с управлением изменениями, который занимается проверкой и контролем, процесс управления релизами занимается внедрением. Управление релизами реализуется при взаимодействии с управлением конфигурациями и управлением изменениями, что гарантирует своевременную актуализацию базы CMDB с учетом каждого нового релиза. Управление релизами также обеспечивает актуальных версий релизов в библиотеке эталонного программного обеспечения. Программное обеспечение является основным объектом процесса управления релизами [18].

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

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

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

Руководитель процесса управления релизами должен разработать политику в отношении релизов, определяя время и способ выполнения конфигурирования релизов. Существенные релизы могут быть запланированы заблаговременно, одновременно с присвоением номера версии, с тем, чтобы в заданные моменты времени можно было внести изменения [19].

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

Перед установкой на месте необходимо настроить и протестировать все оборудование и ПО в тестовой среде.

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

На рисунке 6 представлена классификация релизов, предложенная автором.

 

 

Рисунок 6 – Классификация релизов

 

Компоновка релиза должна содержать компилирование и связывание программных модулей, или наполнение БД тестовыми данными, а также информацией о пользователях. Полные релизы необходимо отражать в базе CMDB как стандартные конфигурации для облегчения конфигурирования в будущем. Планы тестирования должны содержать тестирование и приемку по качеству технического и программного обеспечения, процедур и сценариев развертывания перед выходом релиза [20].

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

Для распространения и установки программного обеспечения необходимо использовать автоматизированные средства. Благодаря этому можно сократить время, затрачиваемое на распространения ПО, и повысить качество при снижении затрат на ресурсы. Перед началом любой установки нужно проверить, удовлетворяет ли среда, куда планируется внедрить релиз, обязательным требованиям. После установки нужно выполнить обновление информацию в БД CMDB в целях облегчения проверки лицензионных соглашений. Для оптимального внедрения процесса необходимо разбить его на несколько этапов. Сначала стоит выделить самые критичные для бизнеса сервисы. Например, база отдела продаж, портал клиентов и поставщиков, система ERP.

 

 

1.3.4 Процесс управление уровнем сервиса

 

Управление уровнем сервиса – обеспечить понятный заказчику и поставщику механизм обеспечения поддержки и развития ИТ-сервисов, а также мониторинг их качества. Благодаря процессу управления уровнем сервиса можно найти необходимый баланс между предложением и спросом на сервисы необходимого уровня качества, их простоте в применении и стоимостью. Заказчик и поставщик должны точно понимать, что сервисы не только поставляются, но и применяются. Данное понимание реализуется в разработке, согласовании и осуществлении соглашений об уровне сервисов, операционных соглашений об уровне сервисов, внешних договоров и плана обеспечения качества сервисов [21].

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

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

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

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

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

 

 

1.3.5 Управление финансами ИТ

 

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

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

Заблаговременная осведомленность о затратах, связанных с предоставлением сервисов, использование логичной и обоснованной системы выставления счетов ставит предоставление сервисов на прочную основу. Это позволяет заказчикам быть в курсе стоимости ИТ- сервисов, они будут знать, что цена предоставления сервиса разумна, и, как следствие, они будут оптимизировать использование ИТ-ресурсов [23].

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

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

Затраты можно разделить на прямые и косвенные. Для каждого сервиса можно определить затраты, которые прямо или косвенно связаны с ним:

  • прямые затраты – затраты, которые связаны только с определенным сервисом. Например, затраты на картриджи непосредственно связаны с сервисом печати.
  • косвенные затраты – затраты которые являются частью нескольких сервисов. Например, услуги интернета являются частью почтового сервиса, Сервиса ERP и т.д.

Автор предлагает распределять косвенные затраты пропорционально между бизнес-сервисами.

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

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

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

На эффективность внедрения системы выставления счетов влияют следующие критические факторы успеха:

  • пользователи должны знать, за какие сервисы они платят по счетам;
  • пользователи должны иметь представление, каким образом происходит расчет счетов, для того чтобы они могли контролировать свои затраты;
  • система мониторинга затрат должна предоставлять подробные данные о расходах и их обоснование;
  • руководство ИТ должно понимать преимуществах внедрения процесса управления финансами и связанными с этим затратах [25].

Для контроля процесса полезны следующие ключевые показатели эффективности работ:

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

К возможным проблемам можно отнести следующие:

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

Бюджетирование предоставляет руководителю ИТ-сервисов следующие возможности:

  • принимать решения по каждому сервису на основе экономической эффективности;
  • применять коммерческий подход к принятию решений по ИТ- сервисам и инвестициям в них;
  • предоставлять больше данных для обоснования расходов;
  • составлять планы и бюджеты на основе надежных данных [26].

Выставление счетов дает ИТ-руководству следующие возможности:

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

 

 

1.3.6 Управление доступностью

 

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

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

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

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

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

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

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

Главное преимущество процесса управления доступностью, является то, что сервисы, управляемые  ИТ-подразделением, отвечают требованиям заказчика к доступности сервиса.

Также есть ряд иных преимуществ данного процесса:

  • создание единой точки контактов по вопросам доступности бизнес-сервисов и наличие одного ответственного;
  • гарантируется соответствие новых бизнес-сервисов, предъявляемым к ним требованиям и согласованному с заказчиком уровню доступности;
  • затраты поддерживаются на оптимальном уровне;
  • постоянный мониторинг доступности бизнес-сервисов и оптимизация уровня доступности;
  • сокращение числа отказов в доступе бизнес-сервисам и сокращение времени недоступности сервиса;
  • проактивный подход к улучшению сервисов;
  • простота обоснования бюджета для ИТ-организации [29].

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *