Учебная работа. Обзор решений моделирования бизнес-процессов управления ИT сервисами

Обзор решений моделирования бизнес-процессов управления ИT сервисами

Введение

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

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

объект исследования диссертации: бизнес-процессы в ИT.

Предмет исследования диссертации: организация моделирования бизнес-процессов и управления в ИT предприятии.

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

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

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

Задачи, поставленные для достижения цели:

1)Проведение анализа литературных источников по поставленной проблеме:

·Определение роли концепции управления ИT-услугами в понимании бизнес стратегии;

·Определение этапа развития сервисного подхода к управлению бизнес-процессами в ИТ;

·Проведение обзора и анализа существующих методик, методологий, лучших практик, рекомендаций, которые используются для управления ИT-процессами (ITIL, COBIT, ISO 20000);

2)Проведение исследования основных бизнес-процессов в ИT:

·Описание бизнес-процессов, их назначения, целей, задач и функций.

·Определение окружения и взаимодействия с другими процессами.

·Определение метрик процессов.

·Определение документирования процессов.

3)Разработать практические рекомендации для процессов.

·описать процессы, происходящие внутри каждого бизнес процесса.

·разработать схемы моделирования бизнес процессов в ИT.

4)Построить общую инфраструктуру ИТ-предприятия.

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

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

Магистерская диссертация представлена на ____ стр. текста и состоит из введения, четырех глав, заключения и списка литературы.

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

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

В третьей главе проведено моделирование бизнес-процессов, описаны операции, протекающие на всем цикле работ, разработан каталог рисков, безопасности и метрик.

В четвертой главе описана общая инфраструктура всех процессов.

1. Обзор решений моделирования бизнес-процессов управления ИT сервисами

.1Роль концепции управления ИT-услугами в понимании бизнес стратегии

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

В 2000-х годах в результате мощного прогресса информационных технологий, в том числе и благодаря освоению ресурсов Интернет пространства, всеобщая доступность ИT-услуг привела к повсеместной интеграции во взаимодействии человека с компьютером. Современные средства вычислительной техники являются не только неотъемлемой частью повседневной жизни людей (доступность технических средств, появление различных торговых площадок в сети интернет, онлайн-сервисов, интернет-магазинов, интернет-банкингов, интернета-вещей, развитие интеллектуальных систем и технологий Big Data), но и главным двигателем бизнеса.

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

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

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

1.2Сравнительный анализ существующих подходов к управлению IT-услугами

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

-выполнение заданий, связанных с ИТ обеспечением предприятия (внедрение, сопровождение),

-обеспечение стабильного функционирования ИТ комплекса.

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

Главное преимущество компонентного подхода в том, что руководитель ИT-департамента — это прежний технический специалист, а значит выполнять все организационно-административные обязанности, определять мотивации, ставить целевые показатели, KPI, контролировать их выполнение ему проще, если он общается с бизнес-пользователями на техническом языке. однако главным недостатком при этом является тот факт, что зачастую образовывается недопонимание между бизнесом, в лице организации (функциональный заказчик) и техническим департаментом.

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

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

·повышение качества услуг, предоставляемых конечным пользователям;

·обеспечение непрерывности бизнес-процессов и услуг;

·сокращение затрат на содержание ИТ-инфраструктуры.

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

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

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

1.3Анализ существующих методик, стандартов и подходов к управлению ИT-процессов

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

В основу «лучших практик» («best practice») и методологий различных подходов к управлению ИТ-услугами, разработанных крупными компаниями-вендорами входят следующие группы: методологии управления ИТ-услугами (ITIL, MOF, HP References model), подходы к руководству ИТ (IT Governance, CobiT), а также, частично, методологии управления проектами (IPMA, PMI, PRINCE2) в части управления проектами в области ИТ.

К стандартам относится первый в мире международный стандарт по управлению услугами ISO 20000, стандарты в области управления информационной безопасностью ISO 27001, стандарты в области разработки программного обеспечения ISO 12207, ISO 15288, ISO15504 и другие.

1.3.1Библиотека ITIL

ITIL (IT Infrastructure Library) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Создание проекта началось в 80-е годы Центральным агентством по вычислительной технике и телекоммуникациям (CCTA — Central Computer and Telecommunications Agency). Целью проекта было создание подхода, который бы помог результативно и эффективно использовать IT-ресурсы в министерствах и других государственных учреждениях по заказу британского правительства. Результатом работ стала Библиотека опыта организации IT (IT Infrastructure Library — ITIL), которая собрала лучшие подходы, имеющиеся на тот момент в индустрии IT-услуг.

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

рассмотрим основные принципы, на которых основана модель ITIL:

процессный подход к построению деятель IT-департамента;

услуга как конечный продукт IT-подразделения;

высокое качество предоставляемых услуг;

вектор внимания на потребителя;

ключевые отношения Поставщик-Потребитель;

взаимовыгодные отношения с Поставщиками.

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

Основное внимание уделяется 12-ти практическим управленческим методам, которые применяются в различных областях в зависимости от потребностей организации (рис. 1.1).

рисунок 1.1 — Библиотека ITIL

Библиотека ITIL состоит из подробных сведений, которые отвечают на один из вопросов о том, каким образом возможно предоставление и поддержание ИТ-услуг и сервисов (Service Delivery, Service Support, Application Management). В практике описываются процессы создания, развертывания и поддержания ИТ-инфраструктуры (Infrastructure Management) на качественном уровне, способном соответствовать всем ожиданиям клиента.

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

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

·Повышать эффективность выполнения протекающих процессов, использующих современные информационные технологии, в том числе:

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

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

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

üорганизации сервисно-процессного подхода к организации ИТ-деятель;

üоптимизации используемых ИТ-ресурсов (включая человеческие), эффективного распределения ролей, зон ответственности, обязанностей и полномочий сотрудников ИТ-инфраструктуры корпоративной информационной системы;

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

·Обеспечивать увеличение управляемости протекающими процессами и их развития (в том числе, повышение управляемости и прозрачности), обеспечение принятия своевременных, взвешенных и обоснованных управленческих решений за счет:

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

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

üсоздания системы непрерывного совершенствования и развития ИТ-сервисов и процессов управления ИТ.

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

1.3.2MOF

Ведущие мировые компании-вендоры, занимающиеся производством программного и аппаратного обеспечения на практике разрабатывают на основе ITIL структурированные подходы (frameworks), отображающие точку зрения своей компании на управление ИТ-услугами. одной из самых интересных «надстроек над ITIL» является Microsoft Operations Framework (MOF).представляет собой собрание лучших решений, принципов и моделей для достижения надежности, доступности и управляемости производственных систем, основанных на продуктах и технологиях Microsoft. MOF представляет из себя руководства, оформленные в виде статей с описанием управления службами, средствами контроля и эксплуатации. Описания управлений содержат конкретные решения и инструменты поддержки, охватывающие людей, процессы и технологии для эффективного управления производственными системами в условиях сложных и распределенных ИТ-сред.

Модель процессов MOF поддерживает успешное оказание ИТ-услуг при помощи следующих важнейших принципов:

-структурированная и распределённая ИТ архитектура;

быстрый жизненный цикл, итеративное улучшение;

-управление, основанное на оценке;

-встроенное управление рисками.

Модель процессов MOF делится на 4 взаимосвязанных квадранта операционной активности: изменение, эксплуатация, поддержка и оптимизация. Каждый из квадрантов применяется на определенном этапе жизненного цикла ИТ инфраструктуры. Задача каждого из квадрантов решается путем исполнения соответствующих функций управления услугами (рис. 1.2).

Рисунок 1.2 — Модель процессов MOF

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

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

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

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

1.3.3Стандарт CobiT

Стандарт Control Objectives for Information and related Technology (CobiT) представляет собой набор универсальных задач ИТ управления. Его ценность заключается в том, что он предлагает модель, обеспечивающую взаимосвязь между бизнес-целями и ИТ-процессами.

В основе стандарта CobiT лежит парадигма, гласящая о том, что для предоставления информации, которая необходима организации для достижения ее целей, ресурсы ИТ должны регламентироваться набором естественно сгруппированных процессов. ИТ-ресурсы в CobiT описываются через четыре составляющие: приложения (Applications), данные (Information), инфраструктура (Infrastructure), люди (People).содержит верхнеуровневое описание 34-х ИТ-процессов различных аспектов корпоративного ИТ управления. Все процессы сгруппированы в четыре домена (рис. 1.3):

·Планирование и организация (Plan and organize);

·Приобретение и внедрение (Acquire and implement);

·Предоставление и поддержка (Deliver and support):

üОпределение и управление уровнями сервиса,

üУправление сервисами подрядчиков,

üУправление производительностью и мощностью,

üОбеспечение непрерывности сервисов,

üОбеспечение безопасности систем,

üОпределение и распределение ИТ затрат,

üОбучение пользователей,

üУправление службой поддержки и инцидентами,

üУправление конфигурацией,

üУправление проблемами,

üУправление данными,

üУправление физическим оборудованием,

üУправление эксплуатацией,

·мониторинг и оценка (Monitor and evaluate).

Рисунок 1.3 — стандарт CobiT

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

достоинствами CobiT является четкая структура механизмов контроля процессов и возможности проведения аудита ИТ-процессов на соответствие требованиям.

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

·определить четкие требования к ИТ-службе;

·произвести комплексный взгляд на протекающие внутри организации бизнес-процессы;

·оценить риски и удостовериться в оптимизации затрат на ИТ-сервис;

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

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

Единственное, что не описано в CobiT — это вопросы внедрения процессов, механизмы осуществления деятельности (включая управление) процессов, меры по совершенствованию ИТ процессов и услуг.

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

1.3.4Стандарт ISO 20000

Первый в мире стандарт в области управления услугами официально разработанный британским институтом Стандартизации (British Standard Institute) — BS 15000. стандарт ISO/IEC 20000 «определяет требования к поставщику услуг по предоставлению потребителю управляемых услуг приемлемого качества» и «должен способствовать принятию в повседневной практике процессного комплексного подхода к эффективному предоставлению управляемых услуг»./IEC 20000 состоит из двух частей:

·Information Technology — Specification for Service management (ISO/IEC 20000-1: 2005). Набор формальных требований для организации предоставления ИТ-услуг с требуемым качеством;

·Information Technology — Code of Practice for Service management (ISO/IEC 20000-2:2005). Практическое руководство по управлению ИТ-услугами. В нем в форме рекомендаций подробно раскрываются подходы к достижению формальных требований, изложенных в первой части стандарта.

Рисунок 1.4 — Стандарт ISO/IEC 20000

Стандарт ISO/IEC 20000 вобрал в себя принципы процессного подхода и содержит ряд требований к процессам управления ИТ-услугами. В стандарте описаны процессы управления услугами (рис. 1.4), но не отображены взаимосвязи между процессами.

Согласно стандарту, необходимо обеспечить «систему управления, включающую политики и организацию управления, позволяющую реализовывать внедрение всех услуг ИТ и эффективное управление ими». Планирование и реализация управления услугами реализуется через цикл Деминга «Plan-Do-Check-Act» (PDCA). При этом описание цикла и действий, которые должны быть осуществлены на каждом этапе, практически полностью совпадают с описанием цикла PDCA, приведенного в стандарте ISO/IEC 9000 с учетом специфики ИТ-услуг:

Øпланирование (plan) — установка целей управления услугами и определения процессов управления услугами, необходимых для получения результатов, соответствующих требованиям потребителей и политикам поставщика услуг;

Øреализация (do) — внедрение процессов управления услугами;

Øпроверка (check) — контроль и измерение процессов управления услугами и самих услуг. Предметом контроля и измерения должно быть соответствие этих процессов и услуг политикам поставщика услуг, целям управления услугами и требованиям потребителей услуг;

Øдействие (act) — выполнение действий по постоянному улучшению показателей процессов.

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

1.3.5Управление ИТ-проектами на основе PMBoK

Project Management Body of Knowledge (PMBoK) — свод знаний по управлению проектами и является американским национальным стандартом. В стандарте описывается непосредственно процесс управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат.

По PMBoK управление проектами — это приложение знаний, навыков, инструментов и методов к работам по управлению процесса для удовлетворения требований, предъявляемых к проекту. Управление проектами выполняется с применением интеграции логически сгруппированных процессов управления проектами в количестве 42, распределенных в 5 групп. Эти 5 групп процессов следующие:

·инициация;

·планирование;

·исполнение;

·мониторинг и управление;

·завершение.

Вывод: Знания, которые накоплены в PMBoK по управлению проектами являются одними из наиболее часто используемых и при их правильном применении внедрение проектов в рамках ИТ-инфраструктуры будут приносить Прибыль и обеспечивать эффективные показатели качества.

1.3.6Управление ИТ-проектами на основе PRINCE2

PRINCE2 является методом для управления проектами, разработанным для британского правительства и является обязательным для применения во всех государственных структурах Великобритании. Благодаря открытости, доступности и эффективности этого метода, им активно пользуются уже более чем в 150 странах мира и его популярность растет с каждым днем. Уже более 23 000 организаций по всему миру уже используют этот инновационный и надежный подход в своей практике и многие считают его лучшим методом управления проектами. Во многом это связано с тем, что PRINCE2 является действительно универсальным методом: он может быть применен к проектам в любой сфере деятельности и вне зависимо от различных условностей.состоит из набора принципов, тем управления, процессной модели этапов жизненного цикла проекта и руководства по применению метода в уникальных условиях среды проекта.- основан на четком процессе, разбитом на 8 стадий и 45 подпроцессов. У каждой стадии есть свой набор целей, активностей, а также входных и выходных артефактов. Есть критерии, по которым можно судить о качестве артефактов. Они позволяют контролировать отклонения от качества в течение жизненного цикла проекта.

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

В сравнении с другими лучшими практиками и методами управления проектами, а именно PMBoK, PRINCE2 обеспечивает следующие преимущества:

-универсальность применения по отношению к любому типу проекта;

-единство терминологии и подходов;

-интегрируемость с другими практиками и со специфическими отраслевыми моделями и методологиями;

-фокус управленческих усилий на продукте проекта, в соответствии с согласованными стандартами качества;

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

-непрерывность внимания обеспечения жизнеспособности и целесообразности проекта;

-распределение ролей и зон ответственности участников.

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

1.3.7Capability Maturity Model Integration (CMMI)

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

Потребность в появлении данной методологии возникла в кулуарах Министерства обороны США с целью решения такого вопроса, как повышение качества разрабатываемого по заказу ПО. Разработкой модели, в соответствии с которой оценивались потенциальные исполнители заказов министерства обороны, занималась Фирмаанализ процессов, выполняемых при разработке ПО, с учетом связанных с ними рисков.

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

Уровень зрелости — итоговый показатель оценки по модели CMMI. Всего в модели представлено пять следующих уровня зрелости:

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

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

Третий уровень — определенный уровень. Все процессы описаны на уровне организации (но не на уровне отдельного проекта). Становится видимой внутренняя сторона черных ящиков.

Четвертый уровень — количественно-управляемый. Определенные процессы контролируются с помощью различных средств контроля. Самое главное отличие от третьего уровня — предсказуемая эффективность и управление ею с помощью средств контроля.

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

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

·Менеджмент требований — управление требованиями к продуктам проекта.

·Планирование проекта — разработка и поддержание планов проекта.

·мониторинг и контроль проекта — отслеживание стадий протекания проекта и корректировка в случае отклонения от плана.

·Измерение и анализ — поддержка измеримости услуг.

·Оценка качества товаров и процессов — управление качеством в соответствии с продуктом/товаром.

·Менеджмент договоров с поставщиками — управление внешними поставщиками.

·Конфигурационный Менеджмент — контроль за целостностью продукции при обновлении и изменении.

·Разработка требований — сбор и анализ требований заказчиков к продукции.

·Техническое решение — разработка решений в соответствии с требованиями и их внедрение.

·Интеграция продукта — эксплуатация, проверка интеграции и функционирования введенного продукта.

·Верификация — соответствие продуктов требованиям.

·Валидация — соответствие продуктов использованию.

·Фокусирование на процессах организации — использование и понимание процессов в соответствии с областями деятель.

·Описание процессов организации — установление и поддержание процессов организации.

·Организационный тренинг — повышение уровня знаний и развитие способностей людей для эффективного выполнения своих ролей.

·Менеджмент интеграции проектов — взаимодействие заинтересованных лиц при интеграции процесса.

·Менеджмент рисков — анализ возникновения чрезвычайных ситуаций до их возникновения.

·Интегрированные команды — формирование команд для разработки.

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

·анализ решений и разрешение — анализ альтернативных решений и разработка наиболее подходящего решения на основе структурированного подхода.

·Организационная среда для интеграции — инфраструктура для процессов и интеграции продукта.

·Производительный организационный процесс — поддержание производительности процессов на эффективном уровне.

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

·Организационные инновации и внедрение — анализ и выбор необходимых инноваций для внедрения.

·анализ причин и разрешение — выявление причин дефектов и принятие превентивных мер по предотвращению их в дальнейшем.

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

1.3.8eSourcing Capability Model for Service Providers (eSCM-SP)

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

На рисунке 1.5 представлены основные направления: Sourcing life-cycle (стадии жизненного цикла), Capability levels (уровни способностей), Capability areas (область способностей) и 84 различных процесса, распределенных в соответствии с направлениями.

рисунок 1.5 — Структура eSCM-SP

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

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

Существует пять уровней областей предоставления ИТ-услуг, поддерживающих следующие уровни зрелости организации:

·первый уровень — непосредственное предоставление услуг;

·второй уровень — наличие процедур, предоставляющих возможность соответствовать требованиям клиентов;

·третий уровень — организация полостью управляет своей работой;

·четвертый уровень — организация внедряет различные инновации;

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

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

1.3.9SixSigmaR

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

В основу концепции заложены следующие основы:

·устойчивое и предсказуемое течение бизнес-процессов;

·ключевые показатели эффективности должны быть измеряемыми, контролируемыми и улучшаемыми;

·вовлеченность персонала для совершенствования качества продукции;

·клиентоориентированность;

·управление данными, факторами и показателями;

·постоянное совершенствование бизнес-процессов;

·взаимосвязанное взаимодействие внутри организации.

Для совершенствования процессов в SixSigmaR существует методика DMAIC (define — определение, measure — измерение, analyze — анализ, improve — улучшение, control — контроль), согласно которой процессы компании проходят через 5 этапов уровня зрелости.

Вывод: SixSigmaR позволяет обеспечивать выполнение управления производством на основе используемых стандартов, методик и практик. Использование возможно на определенном уровне зрелости

1.3.10ISO 15504 или SPICE (Software Process Improvement and Capability Determination)

SPICE — эталонная модель, определяющая измерение процесса и измерение возможностей.

Модель разделена на процессы из пяти категорий: поставщик-потребитель, инжиниринг, поддержка, управление, организация.

Для измерения возможностей используется 5 уровней:

ü5 уровень — оптимизированный процесс;

ü4 уровень — предсказуемый процесс;

ü3 уровень — установленный процесс;

ü2 уровень — управляемый процесс;

ü1 уровень — выполняемый процесс;

ü0 уровень — неполный процесс.

Возможности процессов измеряются с помощью следующих атрибутов:

·производительность процесса;

·управление производительностью;

·управление продуктом;

·определение процесса;

·развертывание процесса;

·измерение процесса;

·контроль процесса;

·нововведения в процесс;

·оптимизация процесса.

Каждый атрибут может быть измерен по рейтинговой шкале из четырех пунктов (NPLF):

·Not achieved (0 — 15%) — Не достигнуто.

·Partially achieved (>15% — 50%) — частично достигнуто.

·Largely achieved (>50%- 85%) — В значительной степени достигнуто.

·Fully achieved (>85% — 100%) — полностью достигнуто.

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

В стандарте описаны модель оценок в соответствии со следующими стандартами: ISO/ IEC 12207, ISO/ IEC 15288.

Вывод: стандарт ISO/ IEC 15504 является одним из вспомогательных элементов способных обеспечить качественное предоставление ИТ-услуг.

1.3.11ISO/ IEC 19770-1

Данная методология сосредоточена на оптимизации ИТ-процессов, состоящая из 27 областей процесса, описанных детально, с определенными для каждого процесса целями и результатами: SAM Processes — сосредотачивает внимание на процессах SAM, реализация которых в организации необходима для эффективного управления программными активами.

основа стандарта — четырехуровневый подход к внедрению ПО (рисунок 1.6):

Рисунок 1.6 — Четыре уровня ISO/IEC 19770-1

В стандарте описаны процессы, необходимые для достижения каждого уровня к оптимизации процессов. На рисунке 1.7 показан пример требуемых процессов для достижения необходимых оптимизационных показателей.

рисунок 1.7 — Требуемые процессы для достижения оптимизации бизнес-процессов

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

1.3.12ISO 38500

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

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

Стандарт ISO/IEC 38500 обеспечивает соответствие деятель организации обязательствам (законодательству, нормативным актам и контрактным соглашениям), обеспечивая при этом эффективное использование ИТ.

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

структура стандарта ISO/IEC 38500:2008 содержит три раздела:

·область применения и цели стандарта, его применение;

·фреймворк хорошего корпоративного ИТ-управления;

·руководство по корпоративному ИТ-управлению.

стандарт устанавливает шесть принципов корпоративного ИТ-управления:

·Ответственность (Responsibility). Ответственность сотрудников в организации в отношении потребления и предоставления ИТ-сервисов.

·Стратегия (Strategy). Учет современной и будущей стратегии и их связи с ИТ.

·Приобретение (Acquisition). анализ поставщиков.

·Реализация (Performance). Поддержание и обеспечение качественного уровня услуг.

·Соответствие (Conformance). Соответствие ИТ законодательству и прочим нормативным актам.

·Поведение (Human Behaviour). Учет деятель и нужд людей в ИТ-сфере.

В стандарте устанавленго три задачи управления для руководства организации в отношении ИТ:

·Оценка(evaluate) потребности в использовании информационных технологий.

·Направление (direct) планов и политики в сфере ИТ в соответствии с бизнес-целями.

·Контроль (monitor) соответствия политикам и исполнения планов.

Для повышения эффективности управление ИТ должно происходить логично и последовательно. Модель корпоративного управления ИТ (EDM — Evaluate — Direct — Monitor), отличается от привычного цикла PDCA.

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

1.4анализ методов моделирования диаграмм бизнес-процессов

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

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

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

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

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

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

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

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

Основу многих современных методологий проектирования диаграмм бизнес-процессов составляют:

·методология SADT (Structured Analysis and Design Technique) (IDEF0) — метод функционального моделирования;

·метод моделирования процессов IDEF3;

·моделирование потоков данных DFD;

·метод ARIS;

·метод моделирования, используемый в технологии RUP (Rational Unified Process).

1.4.1Применение SADT (IDEF0)

метод SADT (Structured Analysis and Design Technique) является классическим вариантом процессного подхода к управлению. В основу его принципа заложено структурирование деятель организации в соответствии с ее бизнес-процессами, а не по тому как разработана штатная структура организации. Бизнес-процессы, протекающие внутри корпоративной информационной системы, выделяющиеся методом SADT и несущие в себе определенную Ценность для организации должны оптимизироваться в первую очередь. Так же стоит упомянуть о том, что любой бизнес-процесс несет в себе информацию о том кому он предназначается и от кого он идет.

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

Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между ними.

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

1.4.2Применение IDEF3

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

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

1.4.3Применение DFD

Диаграммы потоков данных DFD (Data Flow Diagrams) представляют из себя иерархию функциональных процессов, связанных между собой потоками данных.

посредством моделирования диаграмм потоков данных DFD задаются требования к проектируемой системе. Построение диаграмм потоков данных базируется на четырех понятиях:

потоки данных;

-процессы преобразования входных потоков данных в выходные;

внешние сущности;

накопители данных (хранилища).

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

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

Моделирование диаграмм бизнес-процессов с потоками данных (DFD) используются для проектирования моделей «AS-IS» и «AS-TO-BE», отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации.

1.4.4Применение ARIS

Разнообразие методов моделирования диаграмм бизнес-процессов настолько велико, что, когда встал вопрос о создании интегрированного средства разработчики создали продукт под названием ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.

Специфика ARIS такова, что она поддерживает четыре типа моделей (и подмножество видов моделей в каждом типе), отражающих различные аспекты построения диаграмм бизнес-процессов для корпоративной информационной системы.

В своем составе ARIS поддерживает следующие типы моделей:

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

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

§информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций корпоративной информационной системы;

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

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

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

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

1.5Выбор и обоснование метода(ов) моделирования ИТ-процессов

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

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

Нотация IDEF0 предназначена для функционального описания процессов. При этом существуют дополнительные нотации: для описания внутренних информационных потоков в системе (IDEF1), для детализации реляционной структуры данных (IDEF1Х), процессов развития систем (IDEF2), для документирования техпроцессов (IDEF3), для объектно-ориентированного проектирования (IDEF4), для описания состава и функционирования систем (IDEF5) и т.д.

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

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

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

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

Заключение по первой главе

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

В рамках работы рассмотрены и проанализированы методы моделирования ИТ-процессов с обоснованием выбранного метода.

Рассмотрены, изучены и проанализированы подходы, методы и стандарты по управлению ИТ-процессами, такие как ITIL, MOF, CobiT, ISO 20000, а также руководства по управлению проектами PMBoK и PRINCE2.

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

Рассмотренные стандарты в первой главе вынесены в таблицу 1.1, с описанием их общих черт, различий и особенностями (в контексте сравнения с ISO 20000). Кроме того, так как в данной работе далее рассматриваются три процесса из ISO 20000, приведено сравнение для данных процессов в ISO 20000 и их аналогов в других стандартах.

Таблица 1.1 — Сравнительная характеристика стандартов

СтандартСуть стандартаОсобенностиСвязь с описываемыми в работе процессами ISO 20000CMMIМодель зрелостиПять уровней зрелости, от первого уровня хаотичных процессов до пятого — постоянно оптимизируемыхПроцессам нельзя напрямую сопоставить аналог их в данной метрике, однако каждый из них можно оценить на зрелость по данной моделиCOBITПодход к управлению ИТ5 ключевых областей: Соответствие стратегии, полезность, управление рисками, управление ресурсами, оценка эффективностиМожно напрямую сопоставить аналог их в данном стандарте: все они находятся в третьем доменеM_o_RМетодология, производящая точную оценку и управление рискамиНесколько этапов для выявления и оценки рисков.Так как данная методология связана с рисками, ее можно применить только для исследования процессов ISO 20000, описываемых в данной работе, а соответствующих аналогов процессам данная методология не имеетeSCM-SPДополнение существующих моделей качестваСостоит из 84 процессов, описывающих уровень организацииНельзя напрямую сопоставить аналогSixSigmaRКонцепция управления производством, суть которой состоит в улучшении качества выходов каждого из процессовСлужит для сведения к минимуму дефектов и статистических отклоненийНельзя напрямую сопоставить аналогISO 15504Модель зрелостиПять уровней измерения возможностей посредством девяти атрибутов.Процессам нельзя напрямую сопоставить аналог их в данной метрике, однако каждый из них можно оценить на зрелость по данной моделиISO / IEC 19770-1Методология оптимизации процессов ИТОснова — четырехуровневый подход к внедрению. Процессы, необходимые для достижения каждого уровня, подробно описаны.Можно сопоставить аналог их в данном стандарте — управление уровнями обслуживания, включающее в себя уровни обслуживания, мощности и непрерывность и доступностьISO 38500Принципы для членов руководящих органов организацийСтруктуризация по задачам руководства, принципам управления ИТ. Модель корпоративного управления, отличная от EDM.Нельзя напрямую сопоставить аналогITIL v3библиотека лучших практикНабор документов, описание процессов. наиболее близкая к ISO 20000.Можно сопоставить процессы (имеются аналогичные, только процессы управления доступностью и непрерывностью в ITIL отделены)

Проанализированный незавершенный стандарт, предназначенный для управления ИT-услугами ISO/IEC 20000, а также официальный перевод его на русский язык — ГОСТ Р ИСО/МЭК 20000, включает в себя эталонную модель процессов управления услугами и используется для практического использования при оценке, а также для сертификации различного типа ИT-служб и организаций на соответствие требованиям библиотеки ITIL. Сравнивая между собой стандарты, можно заметить, что модель процессов стандарта ISO 20000 отличается от моделей ITIL, а также описание базовых понятий управления службами ведется на более простом языке, более ориентированным на общий круг пользователей, чем в ITIL. Рассматриваемый стандарт ГОСТ Р ИСО/МЭК 20000 не включает практических рекомендаций и пожеланий по проведению аудита и сертификации.

2.исследование процессов управления ИT-сервисами и услугами

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

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

Во второй главе более подробно будут рассмотрены процессы ISO/IEC 20000: процессы релиза, процессы предоставления услуг (управление уровнем услуг, управление непрерывностью и доступностью услуг, управление мощностями, формирование и предоставление отчетности, управление информационной безопасностью, бюджетирование и учет затрат), процессы разрешения (управление инцидентами, управление проблемами), процессы контроля (управление конфигурациями, управление изменениями),процессы управления взаимоотношениями (управление подрядчиками, управление отношениями с покупателями).

2.1процесс управления мощностями

Описание процесса

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

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

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

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

Требования

·разработка и сопровождение планов распределения мощностей;

·ориентированность плана мощностей на потребности бизнеса и соответствие запросам клиентов;

·распределение мощностей и прогнозирование производительности;

·проектирование графиков по ограничениям мощностей и оценке затрат по модернизации;

·прогнозирование возможных ожиданий клиента по запросам на изменения;

·планирование возникновения внешних изменений;

·сбор и анализ статистических данных по показателям мощностей и производительности;

·построение системы, поддерживающей процесс мощностей.

Задачи

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

·управление мощностями ИТ-инфраструктуры и для решения вопросов бизнеса;

·управление мощностями ИТ-услуг;

·управление мощностями компонентов, входящих с ИТ-инфраструктуру.

В процессе мощностей выделяются следующие основные задачи:

·рациональное распределение ресурсов для максимизации эффекта от их применения и минимизации затрат;

·мониторинг состояния удовлетворенности со стороны клиента;

·регламентирование протекания процесса по обеспечению мощностями и производительностью;

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

·постоянная диагностика системы и всех ее компонентов на выявление проблем и ошибок по предоставлению ресурсов и обеспечения производительности;

·оценка возникающих изменений в протекании процесса;

·проактивное решение проблем по повышению показателей мощности и производительности.

Функции

·Подготовка отчетов о производительности для всех заинтересованных в в процессе участников;

·эффективное распределение ресурсов;

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

·Содействие в диагностировании проблем и инцидентов;

·Проактивное улучшение услуг и их компонентов там, где это экономически оправдано или требуется бизнесом;

·Составление плана обеспечения мощностей.

Клиенты

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

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

окружение процесса

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

Метрики процесса управления мощностями

МетрикаОписание метрикиЗадача метрикиАудиторияЧисло нарушений sla из-за недостаточно быстрого реагирования {нарушения sla}На основе управления мощностями прогнозируются потенциальные сбои в обслуживании из-за проблем с мощностьюОбеспечить эффективное управление мощностями ресурсовВладелец процесса, руководство ИТ.Число нарушений sla из-за недостаточной производительности компонента {нарушения sla}Сбои компонентов из-за недостаточной производительности и т.п. Проблем, связанных с нагрузкойМинимизация числа сбоев по причине недостаточной мощности.владелец процесса, руководство ИТ.Стоимость разработки плана развития мощностей {расходы}Суммарные расходы на планирование оцениваются отдельно от стандартных текущих издержекПланировать будущие требования бизнеса к развитию мощностейВладелец процесса, руководство ИТ, финансовый отдел.Число незапланированных приобретений аппаратных средств, нужных для повышения производительности {расходы}Сюда могут входить дополнительная оперативная память, диски, процессоры, различные системы и сетевые устройства, приобретаемые для решения проблем производительности и не включенные в план развития мощностейПредоставлять точные прогнозы будущих потребностей в мощностях в соответствии с известными сценариями бизнесаВладелец процесса, руководство ИТПроцент избыточной производительности ИТ {% нагрузки} Для измерения уровней производительности, дисков, памяти, процессоров, пропускной способности сети и т.д. Можно организовать мониторинг и проверку на соответствие критериям, описанным в политике управления мощностями. Все обнаруженные при этом избыточные мощности фиксируются и суммируются для получения данной метрикиСледить за инфраструктурой в области мощностейВладелец процесса, руководство ИТСтепень удовлетворенности клиентовСтепень удовлетворенности клиентовЭффективности результатов процессаВладелец процесса, руководство ИТ, бизнес-клиент.

Документирование процесса

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

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

Рекомендации по применению процесса управления мощностями

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

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

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

·процесс управления мощностями должен содействовать созданию новых и внесению изменений в существующие услуги посредством предоставления сведений об объемах (производительности) услуг и моделирования услуг.

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

2.2Процесс управления уровнем услуг

Описание процесса

Роберт Каплан говорил: «нельзя управлять тем, что нельзя измерить». Данное утверждение можно интерпретировать так, что для предоставления качественных управляемых услуг необходимо выяснить требования и ожидания заказчика, измерить, согласовать и предоставить в измеримом виде. затем останется обеспечить соответствие уровня услуг ожиданиям заказчика.

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

Цель: обеспечение предоставления ИТ-сервисов на согласованном и достижимом уровне. Достигается она при помощи постоянного определения, согласования, регистрации, мониторинга и управления уровнями услуг.

Требования

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

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

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

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

·При необходимости проведения действий по улучшению формируется план улучшения.

задачи

·Организация отношений с бизнесом.

·Обсуждение текущих требований и целей.

·Определение, документация, согласование, мониторинг, отчетность и проведение оценки уровня предоставляемых и планируемых услуг и сервисов.

·Обеспечение и улучшение коммуникации с бизнесом и заказчиком.

·Обеспечение измеримости целей услуг.

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

Функции

На уровне процесса выполняются следующие функции:

·Определение, обсуждение документирование и согласование требований,

·Ведение каталога услуг,

·Учет услуг,

·Определение лиц, ответственных за функционирование услуг,

·Определение ключевых показателей услуг,

·Определение состава услуг,

·мониторинг и измерения производительности услуг,

·Организация оценки услуг и инициация улучшений,

·Документация стандартов и шаблонов,

·Организация и документирование контактов и отношений,

·Регистрация и обработка жалоб и благодарностей,

·Сбор данных, оценка и повышение удовлетворенности,

·Оценка и пересмотр соглашений и контрактов,

·Помощь в сопровождении каталога услуг и поддержка шаблонов.

Клиенты

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

·создание и обновление каталога услуг;

·создание и поддержание эффективного процесса управления уровнем сервисов, включая:

·определение структуры соглашения об уровне сервиса;

·заключение операционных соглашений об уровне услуг с внутренними поставщиками;

·заключение внешних договоров с поставщиками;

·обновление существующей программы улучшения услуг;

·ведение переговоров с заказчиками, заключение и поддержка соглашений об уровне сервиса, операционных соглашений об уровне услуг и внешних договоров;

·анализ качества работы ИТ-организации и улучшение качества по мере необходимости.

Окружение процесса

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

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

Метрики процесса управления уровнем услуг

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

МетрикаОписание метрикиЗадача метрикиАудиторияСтепень удовлетворенности клиентовУдовлетворение клиентаСубъективная оценка качества результатов процесса.Владелец процесса, бизнес-клиент.Число случаев нарушения SLA {инциденты}Учитываются все инциденты, заявки, а также согласованные показатели, которые вышли за пределы SLA.Предоставление оговоренного уровня сервиса.Владелец процесса, руководство ИТ. Число услуг, не охватываемых SLA {услуги}Показатель охвата контроля для процесса SLA.Охватить все услугиВладелец процесса, руководство ИТ, бизнес-клиент.Процент SLA, требующих изменения {% SLA}Незапланированные изменения SLA вне периода пересмотра.отслеживать любые SLA, требующие значительного пересмотра.Владелец процесса, руководство ИТ.Число нарушений SLA по вине внешних подрядчиков, осуществляющих поддержку {инциденты}Предоставляет компании данные, свидетельствующие об эффективности управления внешними договорамиУлучшение условий обслуживания с внешними подрядчикамиВладелец процесса, руководство ИТ.Затраты на предоставление услуг {затраты}Учет затрат является стандартной задачей процесса управления услугамиКонтроль издержек на предоставление затратРуководство ИТ, владелец процесса.

Для повышения уровня удовлетворенности заказчика следует проводить мониторинг этого уровня такими методами, как:

·анкетирование;

·опросы;

·встречи по оценке услуг;

·общение с пользователями услуг;

·анализ благодарностей и жалоб пользователей.

Документирование процесса

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

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

·Все услуги должны быть задокументированы в нем.

·Соглашение должно быть подписано обоими заинтересованными сторонами — со заказчиком и поставщиком услуг.

·процесс управления изменениями должен быть рассмотрен и в соглашении, и в описанных в соглашении услугах.

·Содержании структура соглашения определяется на основе бюджета и потребностей заказчика.

·Целевые показатели уровня услуг определяются с точки зрения заказчика. Следует акцентировать наиболее важные целевые показатели — при большом их количестве возможно возникновение путаницы и увеличение расходов.

Соглашение должно обязательно содержать информацию:

·Краткое описание услуги.

·Срок действия услуги.

·Механизм контроля изменений.

·Мероприятия, связанные с услугой.

·Контактную информацию об ответственных сотрудниках.

·Расписание функционирования услуги (включая необходимые перерывы в предоставлении услуги).

·Обязательства и ответственность со стороны заказчика и поставщика услуги.

·Процедуру подачи жалоб, эскалации и уведомления.

·Целевые показатели услуги, рабочая нагрузка.

·необходимую финансовую информацию.

·Действия, которые принимаются в случае прерывания предоставления услуги.

·Связанные и влияющие услуги.

·Глоссарий терминов услуги.

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

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

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

·Соглашения об уровне услуги, основанные на заказчиках — соглашение покрывает все услуги некоторой группы заказчиков. Например, для финансового отдела — соглашение о работе финансовых систем, систем закупок, систем счетов и других используемых систем. Заказчики предпочитают такую структуру, т.к. все требования собраны водном документе.

·Многоуровневые соглашения — соглашение включает несколько уровней, к примеру: корпоративный уровень для управления услуг заказчиков в организации; уровень заказчиков — для описания предоставления услуг некоторым выделенным группам заказчика; уровень услуг — описывает отдельные услуги для предоставления заказчикам или группе.

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

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

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

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

2.3процесс управления непрерывностью и доступностью услуг

Описание процесса

Управление непрерывностью ИТ-услуг — это процесс, способствующий предотвращению любых серьезных сбоев в предоставлении ИТ-услуг.

Управление доступностью — процесс, отвечающий за определение, анализ, планирование, измерение и улучшение всех аспектов доступности услуги.

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

Цель: гарантировать, что обязательства перед заказчиками о непрерывности и доступности услуг будут осуществлены при любых обстоятельствах.

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

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

Требования

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

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

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

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

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

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

Задачи

·Обеспечение устойчивости ИТ-инфраструктуры к отказам;

·Определение условий доступности для реализации запросов бизнеса в ИТ-инфраструктуре;

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

·Определений границ условий по предоставлению ИТ-услуг бизнесу;

·Условия восстановления ИТ-услуг;

·Ведение архивов для восстановления ИТ-услуг.

Функции

·Инвентаризация и учет;

·мониторинг критических мест по доступности;

·Анализ доступности ИТ-сервисов и услуг в разрезе ИТ-инфраструктуры;

·Определение времени восстановления работы ИТ-услуги;

·Регламентация процесса обработки проблем с процессом доступности;

·Планирование регламентированных работ по проверке соответствия процесса условиям SLA;

·Модернизация и совершенствование процесса доступности и непрерывности доступа к ИТ-услугам.

Клиенты

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

окружение процесса

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

Для лучшего понимания направления деятельности этих процессов ниже приведена таблица — сравнение двух процессов по различным критериям:

ПроцессУправление доступностьюУправление непрерывностьюРиски, на которых фокусируется процессРиски с высокой вероятностьюРиски с высоким ущербомХарактер процессаБольше проактивныйБольше реактивныйНа что влияет процессСнижает вероятность наступления нежелательных событийСнижает ущерб от наступления нежелательных событийНа чем акцентируется процессНа технических решенияхНа организационных мерахМетод процессаОптимизацияСоздание избыточностиПроцесс часто является частью корпоративной функцииНетДаВремя работы процессаBusiness-as-usualФорс-мажор

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

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

Метрики процесса управления непрерывностью и доступностью

Процессы используют разные метрики. В управлении доступностью:

§Среднее время восстановления услуги.

§Среднее время между сбоями (от возобновления работы после сбоя до следующего сбоя).

§Среднее время между инцидентами (от сбоя до следующего сбоя).

Управление непрерывностью вводит показатели:

§Целевое время восстановления. За какое время после сбоя мы должны возобновить предоставление услуги.

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

Более расширенный список метрик приведен ниже.

МетрикаОписание метрикиЗадача метрикиАудиторияЧисло услуг, не охватываемых планами {услуги} количество услуг и SLA, не оговоренных в планах восстановления и непрерывности.Метрика гарантирует контроль ситуации для всех услуг.владелец процесса, руководство ИТ, бизнес-клиент.Число проблем, выявленных при последнем тестировании, которые еще не решены на данный момент времени {проблемы}Метрика представляет собой число возникающих в ходе тестирования планов вопросов, остающихся на данный момент открытыми.Поддержание работоспособности планов.владелец процесса, руководство ИТ.Число выявленных за данный период проблем, которые ставят под угрозу планы {проблемы}Перечень проблем, препятствующих выполнению планов, с перечислением в соответствующих документах с указанием сроков устранения и планируемых мер.Оценить эффективность деятель по отслеживанию проблем и их устранение.владелец процесса, руководство ИТ.Число неверных записей в справочнике группы кризисного контроля {контакты}В случайный момент делается выборка записей о контактах, а их правильность проверяется независимым агентом, например, службой Service Desk.Обеспечение эффективности контроля изменений и снижение риска срыва планов из-за неверных данных.Владелец процесса.Степень удовлетворенности клиентов {удовлетворенность}Оценивается исходя из удовлетворенности бизнес-подразделений планированием и процессом, поддерживающим планы в актуальном состоянии.поддержание удовлетворенности клиентов.Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент.Простой, недоступность обслуживания {минуты}Время, в течение которого услуга недоступна.Обеспечение предоставления услуг пользователям с помощью планирования и построения надежной и устойчивой инфраструктуры, обеспечение управления взаимоотношениями с ключевыми поставщиками и партнерами в соответствии с требованиями сервиса.владелец процессаВремя устранения неполадки {минуты}Время с момента обнаружения неполадки до возобновления сервиса. Складывается из четырех составляющих: времени реагирования на неполадку, времени ремонта, времени восстановления и времени возобновления сервиса.Ограничение времени, требуемого для восстановления нормального функционирования услуги и ее компонентовВладелец процесса, руководство ИТ.Mtbsi (среднее время между системными неполадками) {минуты}Среднее время между возникновением следующих друг за другом системных неполадок.Определение уровня стабильности сервиса.Владелец процесса, руководство ИТ.Mttr (среднее время прекращения простоя, среднее время восстановления) {минуты}Стандартный показатель доступности, измеряющий среднее время с момента возникновением неполадки до ее устранения.Измерение уровня сервисаВладелец процесса, руководство ИТ.Критическое время сбоя {минуты}Метрика измеряет общее время простоя (в минутах) в течение критичного по нагрузке периода. Фактор «критичности» определяется видом сервиса.Выявление более серьезных проблем, чем нарушения SLA.Владелец процесса, руководство ИТ, клиент бизнеса.Время возобновления недоступных услуг {минуты}Время, требуемое для возобновления обслуживания клиентов.Выбор эффективных методов сокращения простоя, связанного с ремонтом.владелец процесса, руководство ИТ, клиент бизнеса.количество повторных сбоев {неполадки}Количество конфигурационных единиц, которые неоднократно выходили из строя.Сокращении многократных сбоевВладелец процесса, руководство ИТ.

Мониторинг и другие виды деятельности по обеспечению доступности и непрерывности услуг:

·мониторинг значений параметров доступности и непрерывности услуг.

·Поддержание актуальности и хранение статистических данных о доступности и непрерывности услуг.

·Поддержание значений параметров доступности и непрерывности в соответствии со SLA.

·Документирование и анализ выявленных несоответствий между реальным и плановым уровнями доступности и непрерывности.

·Прогнозирование рисков, проблем и разработка действий по ликвидации последствий.

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

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

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

Документирование процесса

·Планы по непрерывности и доступности услуг;

·План корректирующих действий;

·Планы антикризисного управления;

·План срочных ответных действий;

·План восстановления после катастрофы;

·Совокупность вспомогательных планов и контрактов с поставщиками услуг по восстановлению.

рекомендации по применению процесса управления непрерывностью и доступностью услуг

·Все показатели и метрики процесса должны соответствовать SLA;

·Для обеспечения согласованного уровня предоставления услуг должны иметься различные планы для обеспечения доступности согласованных уровней услуг при любых условиях (от нормального функционирования услуги до полной её остановки);

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

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

2.4Процесс управления обеспечением информационной безопасности

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

Описание процесса

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

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

Цель: предотвращение или минимизация ущерба различного вида (материального, морального и пр.), непрерывность в работе.

задачи: обеспечение целостности и сохранности информации на всех уровнях управления компанией.

Клиенты

владелец процесса: менеджер по информационной безопасности.

окружение процесса

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

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

·Управление инцидентами

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

·Управление проблемами

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

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

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

·Управление релизами

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

·Управление уровнем сервиса

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

·Управление бесперебойностью предоставления и доступностью услуг

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

·Управление мощностями

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

·Управление непрерывностью

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

Метрики процесса управление обеспечением информационной безопасности

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

МетрикаОписаниеЗадача метрикиАудиторияЧисло инцидентов, связанных с информационной безопасностьюМетрика основывается на записях о количестве закрытых инцидентов и заявок.информация о предыдущих инцидентах должна сократить число происшествий и снизит их вредоносное воздействие.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Число решенных проблем, связанных с информационной безопасностьюКоличество решенных проблем, которые были закрыты с формулировкой, относящейся к информационной безопасности.Данная метрика показывает эффективность управления безопасностью, и решение проблем приведет к сокращению числа инцидентов и повышению доступности ИТ-услуг.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Процент своевременно проведенных проверок и аудитов в сфере ИТ.сколько проверок и аудитов было выполнено в запланированные сроки. Своевременность проведения данных аудитов контролируется данной метрикойВнутренние проверки и аудиты позволяют нам выявить недостатки процесса.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Число выявленных рисков (предостережения и новые угрозы) по проекту ИТ.Необходимо постоянно обновлять базу возможных рисков и угроз. Этот показатель оценивает успешность процесса выявления: даже с учетом различных обстоятельств риски могут быть выявлены всегда.Обнаруживать каждую неделю или месяц новые риски и угрозы. Это позволит предостеречь от старых угроз и не даст развиться новым.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Процент внешних договоров, где явно оговорены вопросы информационной безопасностиВнешние договоры должны быть приведены в соответствие с политикой информационной безопасности компании. Метрика позволяет отслеживать соответствующую деятельность.Уменьшить вероятность появления дополнительных рисков за счет внешних договоров.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Число выявленных проблем релиза, связанных с информационной безопасностью релиза (возвраты к исходному состоянию/вирусы и т.д.)Релизы представляют высокий риск для процедур, относящихся к информационной безопасности. Данная метрика обеспечивает автономное исследование допустимого уровня риска для каждого плана релиза.Снизить количество проблем, связанных с внедрением нового релизаВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Число изменений, которые были по соображениям информационной безопасности отменены (и система возвращена в исходное состояние)Данная метрика отображает количество изменений, которые по причине информационной безопасности были отклонены. Изменения были плохо спланированы.предотвратить возможность преднамеренной атаки.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Скорость установки патчей, связанных с информационной безопасностьюПоказывает время с момента выпуска патча поставщиком до его установки в среде промышленной эксплуатации.показывать способность организации к адаптации системы информационной безопасности путем быстрой установки защитных патчей.владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP

Документирование процесса

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

·Соглашение об уровне услуг (OLA), соглашение об уровне услуг в отличии от предыдущего заключается между поставщиком и каким-либо департаментом, между различными службами внутри компании. Таким образом соглашение об уровне услуг дополняет соглашение об уровне сервиса.

·Политика управления рисками информационной безопасности, информация о том, как вести себя в случае, если появляются проблемы, сбои и прочие риски;

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

2.5Процесс управления бюджетированием и учетом затрат

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

Описание процесса

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

Бюджетирование — разработка и планирование бюджетов на процессы, охватывающие проект. Основная цель бюджетирования — оптимальное распределение ресурсов.

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

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

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

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

окружение процесса

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

·Управление подрядчиками — оплата за выполненные работы приглашенному персоналу.

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

·Управление релизами включает затраты на персонал, создание, поддержку и распространение релизов, а также затраты на программные средства.

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

·Управление мощностями — прямая взаимосвязь мощностей ИТ-сервисов и финансовых ресурсов. Приобретение дополнительных мощностей и увеличение доступности стоит определенных материальных ресурсов.

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

Метрики процесса бюджетирования и учета затрат

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

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

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

управление процесс бизнес моделирование

Владелец процесса: руководитель ИТ.

МетрикаОписаниеЗадача метрикиАудиторияПроцент учитываемых расходов на ИТДоля расходов, которые приходятся на область ИT при распределении бюджета.Управлять затратами на ИТ — проекты и инфраструктуру, обеспечивать стабильную основу для решений, которые касаются ИТ-сферы, путем определения и учета затрат на предоставление услуг, а также обоснованного возмещения издержек, если это возможно.Руководитель ИТПроцент затрат на оплату труда в сфере ИT.доля выплат, приходящихся на сотрудников из ИT структуры.Определение и анализ затрат на сферу ИT, относительно выплат на остальных сотрудников.Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Задержки в создании финансового отчета на ИT проект.Данная метрика показывает, на сколько времени запоздал финансовый отчет.Использование финансового отчета для оценки прогресса.владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Степень достоверности (в процентах) финансового прогноза на предыдущий квартал в сфере ИT.Отношение сделанного ранее прогноза к фактическим данным.Привести достоверность финансового прогноза к идеальному.Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Совокупная стоимость владения проектаМетрика показывает, в какую сумму обходится компании владение информационными технологиями. ТСО включает все финансовые расходы, в том числе заработную плату, затраты на амортизацию, оборудование и инфраструктуру.Снизить совокупную стоимость владения.владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число жалоб, касающихся затрат на ИТЕсли возникают жалобы по затратам, финансовая служба обязана предоставить обоснование или финансовый отчет, где будет указано чем вызваны те или иные затраты, они к тому же могут быть неубедительными и необоснованными. Это означает, что принципы управления финансами требуют пересмотра.Обосновать затраты на выполнение проектаВладелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Стоимость отклонений от плана выполнения проектаВ затратах на проект, важно учитывать сколько компания потеряет, в случае сбоя или приостановки работы.Подсчет затрат, которые понесет компания в связи с непредвиденными обстоятельствамиВладелец процесса, руководство ИТ, бизнес-клиент, члены команды.

Документирование процесса

·бюджет (обычно содержит элементы, затраты на которых описаны в верхних уровнях иерархии и требуют более детального описания. Если масштаб проекта меняется соответственно необходимо пересчитать и бюджет);

·Прогнозные затраты (в любой момент менеджер проекта должен спланировать будущие затраты на проект или оставшуюся часть проекта. И на основе статистических данных можно заранее выявить возможный перерасход материальных ресурсов или денежных средств);

Статьи затрат (процессы и услуги, на которые необходимо производить выплаты);

Отчеты по затратам (месячный, декадный, квартальный отчет о затратах для использования его в последующем);

Смета-заявка — совокупные фактические затраты по проекту, вместе с отчетами по отдельным периодам, чтобы можно было проанализировать, когда произошла задержка (если была);

Сводный реестр участников проекта и внешних сотрудников;

Акты обследования оборудования;

Сметные расчеты (в них указываются статьи затрат и величину затрат);

заключения отделов по возможным рискам и затратам;

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

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

Описание процесса

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

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

Окружение процесса

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

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

·управление релизами

Процесс управление изменениями контролирует деятельность по распространению (тиражированию) релизов. В процессе управления релизами проводится качественное тестирование релизов.

·управление уровнем услуг

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

Метрики процесса управления изменениями

¾Количество изменений;

¾Количество срочных изменений;

¾количество прерываний работы системы, вследствие изменений;

¾Срок выполнения изменения;

¾Количество изменений, обработанных за месяц [штуки];

¾доля изменений, возвращённых на повторное оформление в результате проверки менеджером процесса [%].

Документирование процесса

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

Сводная таблица KPI — Подготовка данных для контроля эффективности внедрения изменений.

Срочный RFC — Срочный запрос может быть исполнен до заведения RFC в случае устного одобрения со стороны менеджера процесса CHG.

Заявка на ИТ-услуги.

2.7Процесс управления инцидентами

Описание процесса

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

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

Цели

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

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

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

Требования

Благодаря процессу управлению инцидентами выполняется следующее:

-своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса;

-повышение производительности работы пользователей;

-клиентоориентированный мониторинг инцидентов;

-доступность собранной информации о соответствии предоставляемых услуг, являющейся объективной и наиболее актуальной;

-согласованным договоренностям (SLA).

Задачи

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

1.выявление и регистрация инцидентов;

2.классификация и начальная поддержка;

.исследование и диагностика;

.решение и восстановление;

.закрытие;

.владение, мониторинг, отслеживание и связь.

Принципы

üКоординация между пользователями и специалистами по решению инцидентов;

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

üУдовлетворенность пользователей, обеспечивающаяся на всех этапах решения инцидентов;

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

üВсе инциденты управляются, а их данные сохраняются в единой базе данных;

üВсе инциденты должны иметь стандартную схему классификации, которая соответствует бизнес-процессам предприятия;

üЗаписи инцидентов регулярно проверяются на предмет правильного ввода и их корректной классификации;

üВсе записи инцидентов по мере возможности должны иметь общие формат и набор информационных полей;

üСогласованный с бизнесом набор критериев для определения приоритетов и эскалации инцидентов.

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

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

центральная процессинговая система — подсистема доступа, центральный , приложение.

сеть — маршрутизаторы, сегменты, концентратор (hub), IP‐адреса.

рабочая станция — монитор, сетевая карта, дисковод, клавиатура.

использование и функциональность — услуга (сервис), возможности системы, доступность, резервное копирование (back‐up), документация.

организация и процедуры — заказ, запрос, поддержка, оповещение (коммуникации).

запрос на обслуживание — запрос пользователя в службу Service Desk на поддержку, предоставление информации, документации или оказание консультации.)Приоритезация, присвоение номера, определяющего срочность и степень воздействия.)Распределение по услугам и сервисам на основании договоренной об уровне услуг SLA.)Распределение на группу поддержки по категории. При правильном распределении инцидента процесс управления инцидентами показывает высокие показатели эффективности (KPI).)Сроки решения.)Статус инцидента.

Функции

üмониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ‐систем с соглашениями в соответствии с уровнями услуг (SLA);

üэффективное руководство и мониторинг выполнения соглашений в соответствии с уровнями услуг (SLA) на основе сбора достоверной и актуальной информации;

üэффективное использование персонала;

üпредотвращение потерь на этапе получения сведений об инцидентах и запросах на обслуживание при их неправильной регистрации;

üповышение точности информации в конфигурационной базе данных (Configuration Management Database — CMDB) за счет ее проверки при регистрации инцидентов в привязке к конфигурационным единицам (Configuration Item — CI);

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

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

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

·специалисты могут постоянно отрываться от работы на телефонные звонки от клиентов, из‐за чего им становится трудно эффективно выполнять свою работу;

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

·недостаток информации о клиентах и предоставляемых услугах, необходимой для принятия руководящих решений;

·увеличенные трудозатраты на решение проблем.

Окружение процесса

ПроцессВзаимосвязьУправление конфигурациямиОпределяет связь между ресурсами, услугами, пользователями и Уровнями Услуг (сервисов). При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item — CI), позволяющая предоставить более подробную информацию об источнике ошибкиУправление проблемамиПозволяет облегчить поиск корневых причин посредством качественной регистрации инцидентаУправление изменениямиПредоставляет информацию о запланированных изменениях и их статусахУправление уровнем услугКонтролирует выполнение договоренностей (соглашений — SLA) с заказчиком о предоставляемой ему поддержкеУправление доступностьюПоказатель доступности предоставляемых услуг и сервисовУправление мощностямиПолучает информацию об инцидентах, связанных с функционированием самих ИТ‐систем

Метрики процесса управления инцидентами

МетрикаОписаниеЗадачаАудиторияПроцент решаемых инцидентов при обработке на первой линии технической поддержкиРасчитывается количество инцидентов, которые не требуют эскалации на вторую линию поддержкиИзмерение параметров, путем сравнения в БД службы Service Desk известных ошибок, поставляемых управлением проблемами, при котором количество инцидентов, устраняемых первой линией поддержки вырастетВладелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)время обработки инцидента до момента эскалацииПоказатель эффективности, позволяющий обеспечивать равновесие с метрикой степени удовлетворенности клиента, поскольку обслуживание заявки должно длиться столько, сколько потребуется для удовлетворения запроса пользователя по решению проблемыСлужба Service Desk должна обеспечивать эффективную обработку заявки, посредством оптимального времени обработки заявкиВладелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Процент инцидентов, некорректно назначенных на сотрудников службы поддержкиИзмеряется путем проверки истории заявок, имеющих путь с перенаправлениемСнижение переназначения заявок, замедляющее решение и снижающее эффективность работы команд путем действенных сценариев обработки обращения, обучения, инструментария и соответствующих процессовВладелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Процент инцидентов, решенных в течение заданного времени согласно приоритетуПри поступлении заявки в службу Service Desk, ей назначается определенное время обработки в зависимости от SLA службы и приоритета заявки, т.е. таким образом показывается показатель частоты достижения результатаОценка показателя эффективности выполнения SLA службой Service DeskВладелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Среднее время ответа второго уровня поддержки (минуты)время между передачей заявки на второй уровень поддержки и ее принятием, т.е. показатель эффективности второго уровня поддержкиПри передаче заявок на второй уровень возникает угроза несоблюдения сроков, оговоренных в SLA. Отслеживается время реагирования и обеспечивается эффективность приема заявокВладелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Среднее время решения инцидентов (минуты)Общая эффективность процесса управления инцидентамиИзмеряется продолжительность решения инцидента с момента открытия заявки до момента ее решения, при этом фиксируются все стадии обработки заявкиВладелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Процент переназначенных инцидентовОценка масштабов проблемы переназначения инцидентов другим командам, помогающим в решении проблемы, позволяющая усовершенствовать процессы и улучшить информационное наполнение базы данных по известным ошибкамИзмеряется число инцидентов, более одного раза назначенных на ресурс второго или третьего уровня (или группу решения)владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Процент неправильно классифицированных инцидентовКоличество инцидентов, которым при первоначальном присвоении категории были неправильно описаны или классифицированы. Правильная классификация позволяет ускорить решение проблем. Показатель характеризует эффективность сценария получения информации у клиентов, уровень подготовки персонала центра обработки вызовов и качество поддерживающей среды (например, CMDB)Обеспечение оценки правильности выявления и регистрации инцидентов. В процессе регистрации каждой заявки назначается категория, облегчающая ее обработку и последующий анализ. Когда заявка закрывается, в соответствующей записи указывается ее настоящая категория. Метрика показывает, сколько раз две категории не совпали Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Процент обращений, поступивших к специалистам службы поддержки «напрямую», минуя первый уровеньЧастота обращений клиентов непосредственно на второй или третий уровень поддержки. Измеряется путем подсчета поступивших заявокЭффективное предоставление ИТ-услуг владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Степень удовлетворенности клиентов Служит противовесом для других метрик. Если заявки закрываются слишком быстро или обслуживаются слишком долго, то независимо от того, что говорят внутрифирменные метрики, степень удовлетворенности клиентов начнет снижаться и данная метрика это покажетОбеспечивает уровень удовлетворенности клиентов посредством проставления оценки от клиентаВладелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Процент звонков, являющихся запросами на оказание услуг Процент звонков, которые представляют собой запросы на обслуживание, а не обращения по поводу инцидентов (или по иным причинам)Показать, сколько в состоянии сделать для решения инцидентов процесс управления инцидентами и какой для этого нужен объем дополнительной работы. Метрика отражает эффективность работы групп решенияВладелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Процент инцидентов, правильно решенных с первого раза (правильное решение с первого раза)Процент инцидентов, решенных с первой попытки. Это значит, что не требуется ни повторное открытие того же инцидента, ни открытие нового инцидента, связанного с тем же событиемПоказать, в какой степени процесс управления инцидентами действует проактивно и какова его эффективность в решении инцидентов владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)Процент инцидентов, решенных проактивно Процент инцидентов, которые были решены до того, как клиенты сообщили об ошибке (нужна тесная связь с мониторингом систем и приложений)Решение инцидентов (обнаруженных по событиям, зафиксированным инструментами мониторинга) до того, как у пользователя возникли проблемыВладелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)

Документирование процесса

В процессе управления инцидентами выделяются следующие документирующие документы:

·Отчеты по инцидентам и запросам на обслуживание,

·Отчеты по разрешенным инцидентам,

·Сбор статистических сведений по инцидентам в аналитических справках,

·Хранилище баз данных по известным инцидентам;

·отчеты по нерешенным инцидентам;

·Статистика по новым инцидентам и проценту влияния на систему или предоставление ИТ-услуги.

Рекомендации по применению процесса управления инцидентами

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

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

Автоматизированная система регистрации, отслеживания и мониторинга инцидентов.

2.8процесс управлениями проблемами

Описание процесса

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

Понятие проблема определяется как неизвестная причина одного или более инцидентов. одна проблема может породить несколько инцидентов.

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

1.неправильная сетевая конфигурация компьютера;

2.Средство мониторинга неверно определяет статус канала в момент занятости маршрутизатора.

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

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

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

Контроль проблем;

Контроль ошибок;

Предотвращение проблем;

Анализ основных проблем;

Контроль проблем.

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

·идентификация и регистрация;

·классификация и определение приоритетов;

·исследование и ·мониторинг ошибок.

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

1.Идентификация и регистрация известных ошибок;

2.Оценка способов устранения и расстановка приоритетов;

.Регистрация по временному обходу ошибки в средствах службы поддержки;

.Закрытие известных ошибок путем осуществления исправлений;

.Мониторинг известных ошибок для определения необходимости в изменении приоритетов.

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

Требования

·существующие и регулярно возникающие ошибки идентифицированы, задокументированы и отслеживаются;

··подаются запросы на изменения с целью модификации инфраструктуры;

·предотвращается возникновение новых инцидентов;

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

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

задачи

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

Выделяются следующие задачи процесса:

üулучшение качества ИТ‐услуг и сервисов, а также управления процессом в результате документирования ошибок и/или их устранения;

üповышение производительности труда пользователей за счет улучшения качества ИТ-услуг;

üповышение производительности труда персонала при наличии документированных решений проблем;

üулучшение репутации ИТ‐услуг в результате улучшения стабильности услуги или сервиса;

üсовершенствование знаний в области управления, эффективное обучение персонала и хранение всех ключевых данных;

üпостоянное архивирование и создание единых источников для хранения всех входящих инцидентов и полных сведений по ним для принятия мер по предотвращению новых инцидентов;

üулучшение регистрации инцидентов, стандартизация на регистрацию и классификацию инцидентов с целью эффективного определения проблем и их симптомов. Это также помогает улучшить составление отчетов об инцидентах;

üвысокая доля разрешенных инцидентов на первой линии технической поддержки.

Функции

·контроль проблем: определение и исследование проблем;

·контроль ошибок: отслеживание известных ошибок и подача запросов на изменения (RFC);

·проактивное управление проблемами: предотвращение инцидентов путем совершенствования ИТ-инфраструктуры;

·предоставление информации: отчеты по серьезным проблемам и достигнутым результатам.

окружение процесса

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

МетрикаОписаниеЗадача метрикиАудиторияЧисло решенных проблемМера активности, а также эффективности.Сбор сведений о решенных проблемах путем оценки реакции на нее и быстроты принятия решенияВладелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число инцидентов, разрешенных при помощи базы данных, где описано решение аналогичных задачУстранение инцидентов с помощью решений, зарегистрированных в соответствующих базах данных, экономия времени и трудозатрат, сохраняя высокий уровень обслуживания клиентов.База данных с описанием разрешения проблем является главным каналом взаимодействия между процессами управления проблемами и инцидентами. Если ее правильно обслуживать и вести так, чтобы ею было легко пользоваться, то решение инцидентов и проблем не только ускорится, но будет возможно их полная локализацияВладелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Общее число инцидентовИнциденты могут быть вызваны проблемами — если устранить проблемы, количество инцидентов уменьшится.Уменьшение данного показателяВладелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Общее время неработоспособности пользователейМетрика непосредственно связана с клиентами и показывает степень негативного влияния нерешенных проблем на бизнес.Фактически показатель доступности, он позволяет оценить и эффективность процесса управления проблемами: если проблемы решаются быстро и эффективно, уровень простоев у пользователей снижаетсяВладелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число RFC, инициированных процессом управления проблемамиКоличество поданных RFC.Оценка результатов процессаВладелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Среднее число открытых проблемНагрузка на техническую поддержкуЧисло открытых проблем отражает текущую нагрузку процесса управления проблемами. Важно отслеживать этот показатель в сравнении с числом решенных проблем. Если он слишком высок, эффективность предоставления услуг на должном уровне бизнесу находится под угрозой.Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Среднее время закрытия проблемыОценка реакции на проблему и загруженность процессаЕсли со временем среднее время решения проблемы снижается, это говорит об улучшении используемого инструментария и функционирования процессов. Рост показателя служит заблаговременным предупреждением о том, что управлению проблемами не хватает ресурсов.владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Процент инцидентов, которые не удалось связать с проблемойИнциденты, которые еще не были исследованы в рамках процесса управления проблемами.Установление причинно-следственная связи, окончательное разрешение ситуации. очень высокий процент инцидентов, не привязанных ни к какой проблеме, указывает на неэффективность процесса управления проблемами и может свидетельствовать также о недостатке ресурсов.владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число проблем, не решенных в течение заданного времениЧисло проблем, которые остались нерешенными к намеченному дню и были эскалированы.Оценка эффективности укладывания процесс управления проблемами в отведенные срокиВладелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Степень удовлетворенности клиентовСтепень удовлетворенности клиентов, определенная по данным процессаОценка степени удовлетворенности клиента на решение проблемыВладелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Пять категорий инцидентов, по которым было больше всего обращений за отчетный периодЧисло записей об инцидентах в каждой категории, поделенное на их общее число за период и умноженное на 100. пять категорий, для которых это значение максимально, отображаются на секторной диаграмме.Частота обработки идентичных запросов на решение проблемВладелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число инцидентов, разрешаемых путем обучения пользователейЧисло заявок, которые относятся к определенной категории инцидентов и для которых в качестве решения указана необходимость обучения пользователей.К инцидентам приводят как ошибки в ИТ-инфраструктуре, так и недостаточные знания пользователей о том, как работать с приложениями. поэтому можно предотвратить значительную часть инцидентов, просто обучая пользователей.Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.затраты на решение проблемыСколько всего стоило решение данной проблемыОцениваются часы работы персонала, материальные издержки и другие статьи расходов, связанные с решением проблемы.Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Документирование процесса

параметры процесса регламентируются следующими внутренними отчетами:

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

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

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

баланс между реактивным и проективным управлением проблемами:

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

статус и план работ по открытым проблемам.

предложения по улучшению процесса управления проблемами.

план обеспечения качества услуг.

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

2.9процесс управления отчетностью по услугам

Описание процесса

Управление отчетностью по услугам — предоставление информации по услуге в формализованном виде.

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

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

окружение процесса

·Управление проблемами

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

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

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

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

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

·Управление информационной безопасностью

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

Метрики процесса подготовки отчетности по услугам

МетрикаОписаниеЗадача метрикиАудиторияПроцент отчетов, не использовавшихся в течение года в области ИТ.Количество отчетов, которыми долго не пользовались или ненужные отчеты.Неиспользуемые документы должны периодически пересматриваться с точки зрения их существенности и возможности удаления.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Число несоответствий между отдельными отчетами и общим отчетом по управлению услугами по проекту ИТ.отчеты должны быть взаимно согласованы и отвечать политике организации. Метрика выявляет любые несоответствия.Если централизованная подготовка всех отчетов не позволяет достичь согласованности, необходима ручная перекрестная проверка.владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Число инцидентов, относящихся к ошибкам в отчетах.Инциденты, которые связаны с ошибками в отчетности.Процесс управления отчетностью должен работать так, чтобы ошибки или неверные сведения не приводили к инцидентам.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Число подготовленных отчетов за год, месяц, квартал.количество отчетов, подготовленных за определенный период.Отчетность по периодам позволяет проводить анализ и улучшать качество выполнения проекта.владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Число обращений в Service Desk.количество проблем, которые возникли у пользователей в течение работы.Число проблем, с которыми клиент обратился в службу необходимо уменьшать, это возможно только при получении информации по всем обращениям.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Процент необработанных обращений в Service Desk.количество проблем, решенных до принятия мер сотрудниками службы поддержки.Примерный процент ложных проблем.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Процент удовлетворенных скоростью реагирования клиентов на обращение в службу поддержки.Примерная удовлетворенность клиентов службой поддержки.Плавающая метрика, которая предоставляет информацию об удовлетворенности сервиса. Плавающая, потому что клиент может ошибиться в оценке либо специально ухудшить показатель удовлетворенности.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.количество реактивных отчетов.Отчеты, которые показывают, что уже произошло.Отображает количество проблем, которые предотвратить не удалось. Показатель со временем должен улучшаться.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.количество проактивных отчетов.отчеты с прогнозами предоставления услуг.Для заблаговременного предупреждения о важных событиях и позволяет заранее предпринять меры.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.количество показателей для отчетности по услугам.Определенный список показателей для различных видов отчетов.Благодаря общему списку показателей можно легче проводить анализ и принимать меры для улучшения качества предоставления услуг.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.Документирование процесса

·отчет об уровне сервиса (информация о реальном уровне предоставления услуг);

·Бухгалтерский отчет — суммарный список статей расходов и доходов по проекту;

·отчет о результатах выполненных работ — успешные и безуспешные работы по проекту;

·Отчет о проблемах — список проблем, выявленные в течение выполнения проекта;

·Отчеты об инцидентах — список инцидентов, выявленные после решения проблем;

·Отчеты о сбоях — список зарегистрированных сбоев в работе;

·Клиентская отчетность — необходимая информация по проекту для заказчика (включает в себя всю информацию, необходимую клиенту: затраты, проблемы, инциденты и пр.);

·отчеты о договорах, подписанных с подрядчиками и потребителями;

·Еженедельный отчет команды проекта (содержит перечень проделанных работ, затраченное время, работы с нарушением сроков, задачи на будущее);

·Статус-отчет (отражает как обстоят дела с проектом в данный момент, какие обстоятельства могут помешать успешному завершению проекта, ключевые метрики, общее количество рисков);

·Реестр рисков (результат идентификации рисков, данных их анализа и планы по реагированию для наиболее важных рисков);

·Реестр неотложных вопросов (как идет работа с рисками и непредвиденными обстоятельствами. К примеру, замена ключевого сотрудника. Реестр заполняется по важности вопросов — от «незначительного» до «критического»);

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

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

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

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

Описание процесса

Под понятием релиз подразумевается набор новых или/и измененных конфигурационных единиц, которые могут вместе испытываться и внедряться в рабочую ИT среду. Релиз определяется RFC (запрос на изменения), для исполнения которого он внедряется в работу.

Управление релизами (Release management) — это процесс, который отвечает за установку, внедрение и контроль качества всех возможных видов аппаратно-программного обеспечения, развернутого в ИT-среде. А также в рамках такого процесса, как управление релизами создаются и принимаются политики внедрения новых версий программно-аппаратных служб.

Релиз — это набор новых и/или измененных конфигурационных единиц, в отношении которых осуществлено тестирование и которые рекомендованы для использования одновременно.

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

Главным предназначением процесса управления релизами является полное обеспечение качества продуктивной среды вследствие использования формальных процедур, тестов и проверок при вводе в эксплуатацию новых релизов и версий. Главным отличием от процесса управления изменениями, который в первую очередь занимается верификацией, процесс управления релизами осуществляет процедуру внедрения. Управление релизами выполняется в сотрудничестве с управлением конфигурациями и управлением изменениями, что обеспечивает своевременное обновление единой базы CMDB (база данных управления конфигурациями) с учетом каждого внедряемого релиза. Управление релизами обеспечивает обновление контентного содержания релиза (программного кода) в DSL — библиотека эталонного программного обеспечения. При помощи базы CMDB еще отслеживается спецификация аппаратных средств, инструкции, руководства по инсталляции, установке, внедрению, также сетевые конфигурации и т.д. Весь запас аппаратной части, в том числе стандартные базовые конфигурации, хранятся на специальном складе эталонного аппаратного обеспечения, который называется DHS. Главным объектом, на который направлена деятельность процесса управления релизами в первую очередь является ПО.

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

üдлинные перерывы в работе вследствие некачественного планирования выпуска релизов ПО;

üвыполнение большого количества одинаковой работы из-за наличия копий программного обеспечения различных версий;

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

üпотеря файлов-дистрибутивов, которая вызывает дополнительную трату средства на повторную закупку программ;

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

Цель: управление, дистрибуция и распространение используемых в продуктивной среде версий (релизов) программно-аппаратного обеспечения, которое находится на поддержке IT-службы для поддержания высокого уровня и качества услуг.

Требования

1.Обсуждение, формирование и согласование с заказчиками и инвесторами планов запуска релизов, сроков эксплуатации и внедрения, а также процессы развертывания;

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

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

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

.Обеспечение гарантии того, что все изменения происходят в соответствии с деятельностью процесса управления релизами;

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

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

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

Задачи

oСоздание планов, обеспечение координации, внедрение аппаратно- программных средств.

oСоздание и внедрение последовательности выполнения операций и процедур для внедрения, распространения и инсталляции любых изменений в ИT-сервисах.

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

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

oОпределение качественного и количественного состава релизов, а также планирование их внедрения при участии процесса Управления изменениями.

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

oНадежность оригинальных копий программ в используемой организацией Библиотеке эталонного программного обеспечения (DSL), а также регулярного обновления базы данных управления конфигурациями CMDB; то же касается аппаратных средств на складе DHS.

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

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

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

Контроль и отслеживание потоков инвестиций в ПО, от которых сильно зависит развитие бизнеса.

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

Уменьшение вероятности возникновения дефектов, инцидентов и ошибок в результате политики тестирования и контроля внедрения.

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

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

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

Обнаружение и изъятие неавторизованных и не лицензионных копий и некорректных версий ПО.

Процесс управление релизами первостепенно отвечает за выпуск новых релизов и их наиболее эффективное и корректное использование заказчиками/бизнес-пользователями.

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

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

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

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

·Рациональное и правильное использование среды тестирования и сборки;

·Взаимодействие с процессом управление конфигурациями;

·четкое использование методик тестирования, принятое в компании;

·Контроль входов и выходов этапа сборки и тестирования;

·Ведение отчетности по тестированию, которая позволяет оценить степень готовности релиза к запуску в продуктивную среду осуществить сборку снова при возникновении необходимости;

·Стандартизация;

·Проверка требований по информационной безопасности и контроль доступа к компонентам ПО;

·Проверка готовности релиза к запуску или передаче его на следующий этап;

·запуск или передача релиза на следующий этап.

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

Функции

-планировать и контролировать успешное развертывание ПО и сопутствующих аппаратных средств;

-разрабатывать и внедрять эффективные процедуры по распространению и инсталляции измененных компонентов ИТ-систем;

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

-узнавать и учитывать ожидания клиента при планировании и развертывании новых релизов;

-согласовывать точное содержание и план выпуска релизов во взаимодействии с процессом управления изменениями;

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

-обеспечивать сохранение мастер-копий всех программ в библиотеке эталонного программного обеспечения (БЭПО) и обновление базы данных управления конфигурациями (CMDB); — обеспечивать безопасность развертывания и изменения всех аппаратных средств, используя услуги управления конфигурациями.

Окружение процесса

В программном обеспечении существуют понятия внедрения и верификации. Верификацией ПО занимается процесс управление изменениями, а процесс управления релизами занимается внедрением. процесс управление релизами тесно взаимодействует с процессами управление конфигурациями и управление изменениями, что обеспечивает гарантию обновления базы CMDB, учитывая каждый новый релиз. Процесс управление релизами обеспечивает обновление контентного наполнения и содержания релизов, т.е. программный код в DSL (библиотека эталонного программного обеспечения). Используя базу CMDB можно отслеживать спецификации с конфигурацией и настройкой аппаратных средств, руководства по установке и инсталляции. Склад эталонного обеспечение DHS содержит запас аппаратных средств, в том числе стандартизованные базовые конфигурации. Но главным объектом процесса управления релизами является ПО.

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

рисунок 2.2 — Окружение процесса

Управление релизами взаимодействует со следующими процессами:)Управление Конфигурациями

процесс управление конфигурациями занимается регистрацией всех доступных версий программно-аппаратного обеспечения в базе данных управления конфигурациями (CMDB), как базисная конфигурация. Программное обеспечение, поставляемое в библиотеку DSL, а также аппаратное обеспечение для DHS обязательно проходит процедуру регистрации в базе данных управления конфигурациями с согласованием обеспечиваемого уровня детализации. Статус каждой конфигурационной единицы при мониторинге может отражать ход выполнения задачи и выглядеть может так: «в разработке», «готов к тестированию», «в тестировании», «обнаружен дефект», «отклонен», «исправлен» и так далее.)Управление Изменениями

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

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

Метрики процесса управления релизами

МетрикаОписаниеЗадача метрикиАудиторияЧисло установленных программных пакетовВ рамках стандартного процесса верификации любое ПО, обнаруженное на любом оборудовании, можно сверить с DSL, установив таким путем, авторизовано ли оно и правильна ли его версия.контролировать релиз ПО в инфраструктуре, чтобы свести к минимуму число вероятных сбоев.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес- клиент, члены команды, владелец процесса SIP.Число срочных релизовСрочные релизы выполняются в рамках соответствующего процесса — когда он активизируется, этот факт может быть зафиксирован и учтен в данной метрике.обеспечить эффективное управление релизами с минимальным ущербом для бизнеса.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число инцидентов, вызванных новым релизомВ записях о закрытии инцидентов в качестве одной из потенциальных причин должно фигурировать управление релизами. Если фиксируется именно она, это учитывается данной метрикой.эффективное управление релизами с целью удовлетворения потребностей бизнеса.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Процент своевременных релизовУправление релизами включает планирование сроков всех релизов в CMDB. Все изменения этих сроков учитываются данной метрикой.обеспечить эффективное управление релизами с целью сокращения возможных сбоев в работе компании.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число непротестированных релизовВсе релизы должны тестироваться и одобряться, причем обязательно человеком, независимым от автора релиза. Если этого не происходит, такой случай учитывается метрикой.Показывает число незавершенной работыВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес- клиент, члены команды, владелец процесса SIP.Средние трудозатраты на релиз (часы)фактические трудозатраты в человеко-часах.постепенному сокращению трудозатрат на один релиз. В более интеллектуальной среде можно использовать вместо данного показателя разность между прогнозируемым (в плане релиза) и реальным числом человеко- часов.владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число неиспользуемых лицензий на ПОЛицензии на ПО, которые не инсталлированы и не подтверждены со стороны процесса управления мощностямиСокращение количества, используемого нелицензионного или неавторизованного ПОВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число приложений/ревизий, выпущенных в Производство {сборки}Одобренные релизыПоказатель реальной обеспечиваемой продуктивности, не обязательно связанный с качеством приложения.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число дефектов, обнаруженных по журналам регистрации {дефекты}Число новых ошибок, выявленных самой службой поддержки приложений. Учитываются все ошибки, обнаруженные как по журналу регистрации, так и по другим источникам.характеризует работу системы решения проблем по выявлению еще не проявившихся ошибок.владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число ошибок, выявленных при разработке или тестировании {ошибки}Дефекты, обнаруженные в ПО собственной разработки.показывает степень дефектизации приложенияВладелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP.Число ошибок, исправленных при тестированииДефекты, зарегистрированные как исправленные и протестированные.Мера производительностиВладелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIPЧисло ошибок, которые были отклоненыДефекты, которые были решены путем наладки тестируемой среды или помечены, как нормальное состояние системыПоказатель качества сборкиВладелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIPЧисло дней, потраченных на развертывание приложенияВремя отсчитывается согласно числу дней, заранее отведенных на поставку протестированного кода в DSLуспешно соблюдается календарный план при разработке приложений.владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP.Число дней, потраченное на тестирование приложенияПолный срок тестирования приложенияВизуализация скорости работы команды тестированияВладелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP.

Документирование процесса

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

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

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

Руководство администратора (или обновление руководства администратора). Здесь описываются все особенности нового релиза, которые могут повлиять на действия администратора приложения, базы данных или системного ПО. Здесь также указываются все изменения в структуре данных и кода, которые могут привести к изменению плана резервного копирования ИТ-системы.Notes — краткое описание изменений в ИТ-системе. Является сокращенным вариантов обновления руководства пользователя и предназначена для рассылки всем пользователям данной ИТ-системы накануне установки нового релиза в продуктивную среду.

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

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

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

2.11Процесс управления конфигурациями

Описание процесса

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

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

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

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

задачи

·Обеспечить управляемость конфигурацией ПО.

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

·Контролировать регистрацию изменений и ошибок.

·Гарантировать соответствие конфигураций требованиям.

·Обеспечить архивирование, сопровождение и восстановление элементов конфигурации.

Функции

·Идентификация конфигураций;

·Аудиты конфигураций;

·Контроль и управление конфигурациями;

·Управление данными;

·Планирование конфигураций.

окружение процесса

·Управление инцидентами (информация о конфигурационных единицах необходима для регистрации инцидентов и определения какая единица связана с данным инцидентом);

·Управление проблемами (управлению проблемами необходима вся информация об инфраструктуре, связях и о взаимоотношениях для того чтобы связать проблемы с конфигурационными единицами и предоставить доступ к конфигурационной базе данных. Это позволит сравнить фактическую конфигурацию с авторизованной конфигурацией, которая находится в базе данных);

·Управление изменениями (регистрирует запросы на изменения и предоставляет входную информацию для обновления конфигурационной базы данных);

·Управление релизами (управление релизами предоставляет информацию о выпусках релизов, версиях, основных и второстепенных релизах. Перед изменениями запрашивается информация из конфигурационной базы данных о единице, к которой относится той или иной релиз, исходный код и прочее);

·Управление уровнем услуг (данные об уровне сервиса сохраняются для определенной конфигурационной единицы);

·Управление финансами (в управление финансами входит распределение конфигурационных единиц по владельцам, а также подсчет общей стоимости ИТ-компонентов);

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

·Управление мощностями (для распределения рабочей нагрузки и составления плана мощностей необходима информация из конфигурационных баз данных).

Метрики процесса управления конфигурациями

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

Документирование процесса

·План управления конфигурациями;

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

·Головные библиотеки: объекты, необходимые для управления хранением документов;

·Программные хранилища или архивы: общая память, в которой хранятся все программы и документы;

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

2.12Процесс управления подрядчиками

Описание процесса

Аутсорсинг в ИT позволяет сократить расходы предприятия, поэтому стремительное развитие рынка ИT-аутсорсинга обусловлено прежде всего тем, что аутсорсинг в сфере ИT позволяет компаниям снизить косвенные затраты (по данным Gartner Group, их сокращение достигает в среднем 30%). Однако не все согласны с этим. По данным различных исследований, в мировой практике не более 75% компаний считают, что использование аутсорсинга позволило им достичь значительной экономии. За последнее время в Европе порядка 40% телекоммуникационных компаний отказались от услуг аутсорсинга информационных технологий по причине несоответствия критерию цена/качество.

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

Чем руководствуются российские компании, стремясь расширить штат ИT-подразделения и возлагая на него все больше функций? Обычно это объясняется следующим:

оперативностью (возможность быстрой реакции на запросы пользователей);

безопасностью (минимизация рисков утечки информации);

качеством (у собственных специалистов больший опыт работы с внутренними бизнес-процессами и выше возможность контроля и влияния на результат работ);

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

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

Принципы

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

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

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

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

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

Задачи

·Управлять взаимоотношениями с подрядчиками и их производительностью;

·обсуждать и согласовывать договоры. Совместно с процессом Управления уровнем услуг (SLM). Обеспечивать согласованность договоров и соглашений с потребностями бизнеса и поддержку SLA;

·Управлять договорами на протяжении их жизненного цикла;

·Поддерживать политику работы с подрядчиками и соответствующую базу данных подрядчиков и договоров (Supplier and Contract Database, SCD). процесс управления подрядчиками позволяет управлять подрядчиками и услугами, которые они оказывают, с целью достижения целевых показателей качества ИТ-услуг и соответствия ожиданиям заказчиков;

·Получение отдачи от вложений в подрядчиков и договоры;

·совместно с SLM обеспечение того, что внешние договоры и соглашения с подрядчиками соответствуют нуждам бизнеса и поддерживают соблюдение целевых показателей качества, приведенных в SLR и SLA;

·Управление взаимоотношениями с подрядчиками;

·Управление производительностью подрядчиков;

·Обсуждение и согласование договоров с подрядчиками, и управление этими договорами на протяжении их жизненного цикла;

·Управление политикой работы с подрядчиками и поддерживающей ее базой данных подрядчиков и договоров (Supplier and Contract Database, SCD).

Функции

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

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

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

Классификация подрядчиков

Для конкретного понимания процесса управления подрядчиками предлагается разделить этот процесс на три группы подрядчиков в ИT. Предлагается разделить подрядчиков на: поставщиков аппаратно-программных средств, провайдеров, проектировщиков.

Виды подрядчиков в IT

Виды подрядчиковПоставщики аппаратно-программных средствПровайдерыПроектировщикиКто?Вендоры, разработчикиИнтернет-провайдеры, телекоммуникационные компанииСистемные интеграторы, IT-консалтинг компанииФормат услугРазработка, внедрение, тестирование, сопровождение ПО и аппаратного комплексаПредоставление телекоммуникационных услуг (телефония, Интернет, сетевое окружение)Проектирование и аудит сетевых коммуникаций, архитектуры, базы данных, системы пользовательских приложений, системы безопасности, системы управления (инжиниринг)

окружение процесса

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

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

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

Управление уровнем сервиса (SLM) — взаимодействие с процессом позволяет достичь улучшения качества продукта, в интеграции осуществляется постоянная оценка выполненной работы, устанавливается KPI и метрики по продуктам, услугам и информационным системам.

Управление конфигурациями (CFG) — для того, чтобы работа с новой системой/продуктом не вызывала в последствии затруднений, вся информация о продукте, конфигурации, параметры и прочие записи должны обновиться в базе данных CMDB. Это гарантирует отлаженную работу и в случае возникновения проблем, связанных с некорректным обращением продуктом или неверной перенастройкой среды, существует всегда эталонный набор конфигураций продукта, возможность осуществления отката и т.д.

Метрики процесса управления подрядчиками

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

МетрикаОписаниеЗадача метрикиАудиторияСредние затраты на предоставление одной услугиДанные о затратах извлекаются из CMDB: Число обращений х Расчетная стоимость обращения + Управление проблемами + постоянные издержки и т.дОценить суммарную стоимость инцидентов, проблем, изменений и операций, посвященных определенной услугеВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число инцидентов, связанных с предоставлением услуг подрядчикамиПроцесс предоставления услуг должен постепенно сокращать число инцидентов. Чтобы избежать влияния сезонных или иных краткосрочных факторовПоказать уровень нарушений обслуживания, выявленного ИТ-подразделениемВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Средние трудозатраты для выполнения услуги командой подрядчиковОбщее число часов/трудовых дней, необходимое для оказания услуги.Оценить эффективный временной показатель для выполнения одной услуги.Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Степень удовлетворенности заказчиковПоказывает реальное отношение общее количество выполненных услуг на количество услуг, получивших приемку от компании заказчикаПовышать качество выполненных услуг подрядной организациейВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Документирование процессаили соглашение об уровне предоставления услуг (англ. Service Level Agreement (SLA)) — формальный договор между заказчиком (заказчик и потребитель) услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги. В таком соглашении может содержаться детальное описание предоставляемого сервиса, в том числе перечень параметров качества, методов и средств их контроля, времени отклика поставщика на запрос от потребителя, а также штрафные санкции за нарушение этого соглашения.

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

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

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

2.13процесс управления отношениями с потребителями

Описание процесса

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

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

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

Функции CRM

Современные CRM решения должны обладать следующими функциями:

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

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

продажи по телефону (телемаркетинг) — опрос и предложение товаров или услуг по телефону. Автоматизированная система хранит в своей базе информацию о клиентах, с помощью выборки можно сортировать или группировать клиентов, предлагать специальные предложения, приглашать на семинары и мероприятия, продавать товары/услуги;

-управление временем (тайм Менеджмент) — настройка, создание, корректировка расписаний, планирование бюджета времени и т.д.;

-поддержка и обслуживание клиентов (линия Help Desk, сервис) помимо качественного выполненного товара или услуги необходим качественный послепродажный сервис, для этой цели создаются горячие линии, где круглосуточно клиент может получить поддержку по продукту;

-отчетность для высшего руководства — системы позволяют быстро собрать аналитические отчеты о любых действиях;

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

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

окружение процесса)Управление отчетностью

До внедрения CRM подхода и после необходимо провести большую работу для просчета экономических и маркетинговых показателей с целью определения эффективности и необходимости внедрения методов. Правильно выполненный расчет позволяет повысить Доход от работы сервиса и улучшить качество предоставляемых услуг. именно процесс управления отчетностью занимается предоставлением и сбора данных и всех показателей.)Управление Конфигурациями

Процесс управления конфигурациями занимается регистрацией всех доступных версий программно-аппаратного обеспечения CRM систем в базе данных управления конфигурациями (CMDB). Программное обеспечение CRM, поставляемое в библиотеку DSL, а также аппаратное обеспечение для DHS обязательно проходит процедуру регистрации в базе данных управления конфигурациями с согласованием обеспечиваемого уровня детализации.

c)Управление уровнем услуг

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

Метрики процесса управления отношениями с потребителями

МетрикаОписаниеЗадача метрикиАудиторияСтепень удовлетворенности клиентовМетрика оценивает качество предоставляемых услугПовысить качество предоставляемых услугВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число инцидентовОбщее число инцидентов является показателем уровня нарушений обслуживания, выявленного ИТ-подразделениемУлучшить показатель неустойчивости обслуживанияВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Средние трудозатраты для планового обучения клиентовОбщее число часов/трудовых дней, необходимое для обучения клиентовОценить эффективный временной показатель для планового обученияВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Степень эффективности от внедренной CRMМетрика показывает эффективность, прибыль компании, профит от новой CRM системыПодсчитывать эффективность от действий, предпринимаемых компанией для улучшения обслуживания клиентовВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Количество привлеченных клиентов за 1 месяцМетрика показывает эффективность работы CRM системыПодсчитывать количество клиентов, которые стали пользоваться услугами компании. 30 календарных дней — срок отсчетаВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Общее число продажСуммарное количество оборота услуг/товаров за месяцОценивать прирост или уменьшение продажВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Увеличение числа повторных продаж для одного клиентаМетрика показывает степень удержания клиентовПодсчитывать количество повторных покупок одним клиентомВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Время от контакта до заключения сделкиМетрика позволяет оценить время средней совершенной сделкиУвеличить скорость процессов в компанииВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.Число отказов от совершения покупкиОбщее число клиентов, которые по тем или иным причинам отказались от сделкиУменьшить число незавершенных сделокВладелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Документирование процесса

руководство по установке — документ для администратора системы, который в пошаговой форме содержит рекомендации для корректной и полной установки схемы CRM в систему, а также настройку доступов.

руководство по работе с CRM системой — документ с описанием всех функций, а также правил работы с CRM системой, возможными проблемами и решением неполадок.

Воронка продаж — это документ для анализа ситуации в отделе продаж. По воронке продаж можно оценить количество и динамику продаж за определённый период времени как у отдела в целом, так и у конкретного сотрудника.

— Организация электронной рассылки <#"justify">Заключение по второй главе

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

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

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

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

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

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

3.Моделирование бизнес процессов

3.1Моделирование процесса управление мощностями

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

рисунок 3.1 — Диаграмма процесса управления мощностями

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

На рисунке 3.2 показана схема управления мощностями.

рисунок 3.2 — Схема процесса управления мощностями

Задачей процесса управления мощностями бизнеса является определение текущих и будущих потребностей заказчика. Данное планирование выполняется исходя из стратегий и планов бизнеса. Схема процесса показана на рисунке 3.3.

рисунок 3.3 — Схема управления мощностями бизнеса

На уровне процесса управления мощностями сервиса требуется понимание необходимого уровня мощностей в рамках конкретных сервисов. Для определения данных показателей необходимо знать требования бизнеса, данные об инцидентах и проблемах, данные о производительности и нагрузке на инфраструктуру. Схема процесса показана на рисунке 3.4.

рисунок 3.4 — Схема управления мощностями сервиса

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

рисунок 3.5 — Схема управления мощностями ресурсов

Каталогизация рисков и их предотвращение

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

3.2Моделирование процессов управление уровнем услуг

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

рисунок 3.6 — Диаграмма процесса управления уровнем услуг

Данный процесс состоит из этапов:

·Обсуждение и согласование требований;

·Оформление соглашения об уровне услуг;

·Мониторинг производительности услуг;

·Отчетность и анализ уровня сервисов.

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

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

·От управления непрерывностью и доступностью услуг требуются имеющиеся уровни обеспечения данных параметров.

·От управления мощностями требуется информация об имеющихся мощностях.

·От процесса управления информационной безопасностью требуются данные о требуемом и имеющемся уровнях безопасности.

·От процесса бюджетирования требуются рамки затрат.

·От процесса управления конфигурациями требуется информация CMDB.

·С процессом изменений нужна связь при внесении модификаций в уже существующие услуги.

·От процессов разрешения требуется информация об инцидентах и проблемах для их разрешения.

·От процессов управления взаимоотношениями с бизнесом нужны требования, стратегии и планы бизнеса.

·От процесса управления поставщиками нужна информация о наиболее выгодных предложениях для передачи услуг на аутсорсинг.

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

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

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

На рисунке 3.7 показана схема этапов процесса управления уровнем услуг.

Рисунок 3.7 — Схема этапов управления уровнем услуг

Следует более подробно рассмотреть этапы обсуждения и согласования требований и оформления соглашения об уровне услуг.

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

рисунок 3.8 — Схема этапа определения и согласования требований процесса управления уровнем услуг

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

На рисунке 3.9 приведена схема процесса формирования соглашения об уровне услуг.

Рисунок 3.9 — Схема этапа формирования соглашения об уровне услуг процесса управления уровнем услуг

после создания соглашения об уровне услуг и проведения изменений, вызванных им, в рамках конкретных процессов происходит мониторинг уровня предоставляемых услуг. При необходимости происходит пересмотр соглашения.

Каталогизация рисков и меры их предотвращения

РискиМеры по предотвращениюФормирование неприемлемых отношений с заказчиком.Изменение корпоративной культуры компании.Недостаток входных данных со стороны бизнесаПереговоры для уточнения и дополнения требованийНизкий уровень заинтересованности со стороны заказчикаУбеждение заказчика в важности процессаНедостаточность инструментария и ресурсов для согласованияКонтакты с руководством компании для привлечения ресурсовНедостаток ресурсов для документирования, проведения мониторинга и составления отчетности для оценки уровня услугКонтакты с руководством компании для привлечения ресурсовНаправленность процесса на формирование документации вместо улучшения уровня услугПересмотр приоритетов процессаОтступление от процедур, определенных процессомКорректировка отступленийСложность измерения и улучшения метрик бизнесаПриведение метрик к измеримому видуВысокие ожидания и низкая удовлетворенность заказчиковЕсли низкая удовлетворенность возникла из-за недостаточного уровня сервиса — пересмотр соглашения. Если низкая удовлетворенность исходит из непомерных ожиданий заказчика — обосновать уровень предоставления услуг соглашением.Некомпетентность заказчика при составлении требований к уровню сервисовДиалог с заказчиком для приведения абстрактных требований заказчика к измеримому видуРуководитель процесса может высказать нереалистичные обещания при обсуждении соглашения до проведения детального анализа требований.Не обещать заказчику предоставления определенного уровня сервисов до детального анализа, включающего методы мониторинга, бюджет и др.Ошибки при формировании плана затрат на мониторинг и оценку уровней сервисовВыделение отдельного персонала для детальной оценки затратНа практике некоторые организации начинают составлять SLA, пропуская некоторые этапы анализа, что приводит к возникновению неуправляемого и не измеряемого процесса.Не пропускать этап анализа требований заказчика, этап дизайна и разработки плана обеспечения качества сервисов.

3.3Моделирование процесса управления непрерывностью и доступностью услуг

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

рисунок 3.10 — Диаграмма процесса управления непрерывностью и доступностью услуг

процесс управления непрерывностью и доступностью услуг состоит из этапов определения требований к стратегии непрерывности и доступности, внедрении инициированных процессом изменений, тестировании планов непрерывности и доступности и анализа, и аудита планов (см. рис. 3.11).

рисунок 3.11 — Схема процесса управления непрерывности и доступности

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

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

На этапе тестирования планов проводится всеобъемлющее тестирование планов и документирование отчетов об их прохождении. после тестирования планов необходимо проанализировать полученные результаты и при необходимости инициировать пересмотр планов процесса.

Следует более подробно рассмотреть этапы определения требований к стратегии непрерывности и доступности и внедрения изменений. На рисунке 3.12 показана схема этапа определения требований к стратегии.

Рисунок 3.12 — Схема этапа определения требований к стратегии непрерывности и доступности

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

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

после данного этапа происходит внедрение изменений. На рисунке 3.13 показана схема этапа.

Рисунок 3.13 — Схема этапа внесения изменений процесса управления непрерывностью и доступностью

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

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

При создании планов следует использовать данные процессов управления инцидентами и проблемами для определения процедур оповещения и эскалации.

Каталогизация рисков и их решение

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

3.4Моделирование процессов обеспечения информационной безопасности

Управлением информационной безопасностью является: федеральный закон, конституция, указы, ГОСТ 15408, устав компании, ГОСТ 18044, а механизмом являются: системы мониторинга, системы криптозащиты, анализаторы протоколов, системы аутентификации, видеонаблюдение, средства контроля доступом (рис. 3.14).

рисунок 3.14 — Диаграмма процесса управления информационной безопасностью

Диаграмма активности

На диаграмме активности (рис. 3.15) начальное и конечное состояние представлено кружками. Овалами отображаются действия. Ромб отображает узел решения, для увеличения вариантов дальнейшего развития событий. Горизонтальная (или вертикальная) линия показывает распараллеливание на несколько потоков или слияние в один поток.

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

Рисунок 3.15 — Диаграмма активности

Каталогизация рисков и их предотвращение

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

3.5Моделирование процесса бюджетирования и учета затрат

основные и вспомогательные бизнес-процессы

Рисунок 3.16 — Function tree ARIS дерево основных функций

·Закупка:

-закупка необходимого оборудования;

-закупка деталей, расходных материалов;

Хранение и поддержка:

— Поддержка бесперебойной работы программ, систем, облачного хранилища данных;

Аренда помещения:

риски;

Обучение:

— обучение сотрудников в случае внедрения новой системы, с которой нужно будет контактировать в ходе проекта;

Оплата труда:

-Заработная плата специалистам;

-Заработная плата дополнительным сотрудникам для производства дополнительных работ (помощники, бухгалтера и пр.);

Внешние заказные работы:

ремонт оборудования;

-установка лицензионных программ;

ведение бухгалтерского учета затрат на проект;

настройка сети, беспроводного интернета и пр.;

Оформление отчетов по планированию бюджета по проекту.

Жирным выделены основные процессы, обычным шрифтом соответственно — вспомогательные (рис. 3.16).

Для того чтобы на проект выделялся бюджет, необходимо произвести расчет затрат. В контекстной диаграмме просчете затрат на проект обычно участвуют — программист, экономист и аналитик. Остальные участники являются второстепенными, поэтому не отображаются на диаграмме. Входом здесь является «заявка на выделение бюджета», а выходом соответственно «выделение бюджета на проект». Бюджет составляется в соответствии с планом затрат, проектом, законодательством и смете (рис. 3.17).

рисунок 3.17 — Контекстная диаграмма планирование и учет затрат на ИТ

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

Рисунок 3.18 — Диаграмма декомпозиции закупки оборудования

Укрупненные модели основных бизнес-процессов бюджетирования (см. рис. 3.19):

рисунок 3.19 — Контекстная диаграмма укрупненной модели

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

рисунок 3.20 — Диаграмма декомпозиции. Закупка оборудования

рисунок 3.21 — Контекстная диаграмма Хранение товара на складе

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

рисунок 3.22 — Поступление и хранение оборудования на складе

Диаграмма прецедентов состоит из Актора (изображение человечка) и прецедентов(овалы). Акторы — это роли которые выполняет лицо при взаимодействии с прецедентом или сущностью. Прецедент — показывает то или иное событие «то, что выполняется» (рис.3.23).

Рисунок 3.23 — Диаграмма использования. Оплата труда за выполненный проект

зарплата рассчитывается под «управлением» ТК РФ и устава компании по данным из трудового договора и по табелю о рабочих днях, которые являются «входами». Заработные платы рассчитывает бухгалтер. В результате получается оплата труда работникам и табель о зарплате (рис. 3.24).

Рисунок 3.24 — Контекстная диаграмма оплата труда за выполненный проект

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

рисунок 3.25 — Диаграмма декомпозиции оплата труда за выполненный проект

Каталогизация рисков и их предотвращение

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

3.6Моделирование процесса управления изменениями

Если изобразить на диаграмме процесс управления изменениями на самом верхнем уровне в нотации IDEF0, то он будет выглядеть, как показано на рисунке 3.26.

Рисунок 3.26 — Контентная диаграмма процесса управления изменениями

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

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

-Проведение срочных изменений;

-Прием и регистрация, первичная проверка и классификация запросов на изменение;

Планирование и согласование изменений;

Утверждение планов внесения изменений;

Мониторинг и координация внесения изменений;

Оценка проведенных изменений;

Отчетность по изменениям.

Диаграмма 2-го уровня декомпозиции процесса управление изменениями изображена на рисунке 3.27.

Рисунок 3.27 — Диаграмма 2-го уровня декомпозиции управления изменениями

Инициаторами процесса управление изменениями являются сотрудники департамента ИТ, в результате возникновения потребности изменения в системе заводится RFC, производится прием, регистрация, первичная проверка и классификация запросов на изменение.

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

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

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

Каталогизация рисков и их предотвращение

РискиМеры по предотвращениюРиск появления ошибочных RFC- Внедрение работ по тестированию и инспекции RFCРиск возникновения неактуальных RFC- Удаление из базы CMDB данных о неиспользуемыхРиск возникновения негативного влияния от изменения- Тщательное планирование изменений — Планирование возможности отката измененийРиск увеличения большого количества неисполненных изменений-Увеличить контроль за соблюдением исполнения изменений

3.7Моделирование процесса управления инцидентами

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

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

Для управления процессом обработки инцидентов зачастую необходимо градировать входные данные, которые делятся на такие группы, как: ошибка, баг, сбой, неисправность. Также необходимо классифицировать вспомогательные элементы, а именно механизмы управления, т.к. в процессе управления инцидентами существуют несколько видов обработки входящих данных: Call Center, Servise Desk, Help Desk, еще способом для поступления могут быть сведения от тестировщиков и аналитиков.

Если изобразить на диаграмме процесс управления инцидентами на самом верхнем уровне в нотации IDEF0, то он будет выглядеть, как показано на рисунке 3.28.

Рисунок 3.28 — Диаграмма процесса управления инцидентами

Целью процесса управления инцидентами является наиболее скорейшее восстановление нормального уровня предоставления услуг, определенного в соглашении об уровне услуг (Service Level Agreement — SLA), с учетом минимальных потерь для бизнес‐деятельности организации и пользователей. Кроме того, процесс управления инцидентами собирает статистические данных по приходящим инцидентам, производит их классификацию и на основе анализа всех инцидентов создает метрики процесса для совершенствования базы по возможным рискам и обеспечению безопасности.

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

рисунок 3.29 — Схема последовательности выполнения процесса управления инцидентами

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

Рисунок 3.30 — Диаграмма взаимодействия процесса управления инцидентами

Все уровни технической поддержки, а их всего три, обеспечивают успешное разрешение каждого инцидента. При этом гарантируется своевременное решение вопросов за счет:

1.Разработки и управления планом действий по решению вопроса;

2.Инициации конкретных назначений заданий для персонала и бизнес-партнеров;

.Эскалации инцидента, если требуется, когда цель не достигается вовремя;

.Обеспечения внутреннего взаимодействия в соответствии с целями обслуживания;

.Защиты интересов вовлеченных бизнес-партнеров.

Первый уровень поддержки использует базу данных управления проблемами для сопоставления инцидентов известным ошибкам и применения ранее найденных способов разрешения инцидентов. Цель заключается в разрешении 80 процентов инцидентов. остальные инциденты передаются (эскалируются) на второй уровень. непрерывно улучшение процесса управления инцидентами. На третий уровень инцидент передается в том случае, если для решения данного инцидента необходимо привлечение сторонних отделов (рис. 3.31). Как владельцы процесса уровни технической поддержки гарантируют, что процесс возможно улучшить посредством выполнения следующих принципов:

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

2.Разработки специфических для подразделений отчетов и процедур;

.Поддержки и совершенствования взаимодействия и списков эскалации;

.участие в процессе анализа проблем.

Рисунок 3.31 — Диаграмма взаимодействия трех уровней технической поддержки

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

§идентифицирует недостающие звенья процесса;

§идентифицирует нарушения исполнения соглашений об уровне услуг (SLA);

§отслеживает ход выполнения процесса предоставления услуг и решение вопроса с инцидентами;

§определяет тенденции развития процесса управления инцидентами для его совершенствования.

Каталогизация рисков и их предотвращение

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

3.8Моделирование процесса управления проблемами

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

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

Рисунок 3.32 — Диаграмма процесса управления проблемами

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

рисунок 3.33 — Схема последовательности выполнения процесса управления проблемами

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

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

рисунок 3.34 — Диаграмма взаимодействия процесса управления проблемами с окружающим процессами

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

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

Рисунок 3.35 — Диаграмма процесса поиска решения проблемы

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

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

рисунок 3.36 — Схема процесса контроля ошибок

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

·Разработка и поддержание высокого уровня контроля проблем и ошибок,

·Оценка эффективности и актуальности предоставляемого контроля проблем и ошибок,

·Сбор, хранение и документирование актуальной информации,

·Совершенствование процессов контроля ошибок и проблем,

·анализ ключевых показателей,

·Повышение реактивности на оказание качественных услуг.

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

oВыявлять и регистрировать проблемы путем их анализа на основании информации об инцидентах,

oИзучать проблемы и ошибки с учетом их приоритетности,

oОбеспечивать процесс подачи заявления на изменения,

oВыполнять мониторинг ИТ-инфраструктуры ошибки и проблемы,

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

oСледить за тенденциями и принимать действия для их устранения,

oПресекать распространение проблем на всю ИТ-инфраструктуру.

Каталогизация рисков и их предотвращение

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

3.9Моделирование процессов по подготовке отчетности по услугам

Как производится запрос об отчетах и как производится его передача руководителю показано на диаграмме последовательности. порядок выполнения действий указан числами: 1,2, 3… От руководителя поступает потребность в отчетах, у аналитика информация анализируется и обобщаются потребности руководителя. У разведчика (это может быть любой сотрудник или сотрудники компании) происходит поиск информации по различным источникам, и собранная информация передается аналитику, где информация приводится к виду, необходимому руководителю. И уже формализованная информация передается руководителю проекта на рассмотрение (рис. 3.37).

рисунок 3.37 — Диаграмма последовательности. Оформление отчетов

Управление отчетностью услуг происходит под управлением устава предприятия, сметы, плана затрат, проекта, законодательства благодаря усилиях аналитика и экономиста (разведчика) (рис. 3.38).

Рисунок 3.38 — Контекстная диаграмма управление отчетностью по услугам

процесс управления отчетностью по предоставлению услуг: разрабатывается и утверждается методология отчетности, собираются и обрабатываются данные, подготавливается отчетность (подбирается единая форма предоставления информации и готовится отчет) (рис. 3.39).

Рисунок 3.39 — Диаграмма декомпозиции управление отчетностью по услугам

Каталогизация рисков и их предотвращение

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

3.10Моделирование процессов управления релизами

Если изобразить на диаграмме процесс управления релизами на самом верхнем уровне в нотации IDEF0, то он будет выглядеть, как показано на рисунке 3.40.

Рисунок 3.40 — Диаграмма верхнего уровня процесса управление релизами

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

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

ØВыработка политики в отношении релизов и планирование. Ответственным за процесс является менеджер проекта;

ØПроектирование и разработка. Ответственный — разработчики;

ØКомпоновка и конфигурирование релизов. Ответственный — релиз МенеджерØТестирование и приемка релиза. Ответственный — тестировщик, инженеры по качеству продуктов;

ØПланирование и развертывание. Ответственный — релиз менеджер;

ØПодготовка, обучение и оповещение. Ответственный — МенеджерØРаспространения релизов и инсталляция. Ответственный — системный администратор.

Диаграмма 2-го уровня декомпозиции процесса управление релизами изображена на рисунке 3.41.

рисунок 3.41 — Декомпозиция процесса управления релизами

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

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

-Информация о дефектах. Данные поступают в совокупности от процессов PRB (процесс управления проблемами), SEC (Процесс управления безопасностью), INC (процесс управления безопасностью).

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

Менеджер проекта на данном этапе также решает на каком уровне релизные единицы (конфигурационные единицы) могут получать распространение отдельно вне зависимости друг от друга. Принятие решений может осуществляться на основании анализа влияния следующих факторов:

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

·Нагрузка персонала (количество человеко-часов и общего времени на сборку и тестирование отдельных изменений).

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

·возможные сложности интеграции между новыми программно-аппаратными компонентами и имеющей ИT-инфраструктурой предприятия.

До процесса планирования релиза рекомендуется подготовить всю необходимую информацию о жизненном цикле (ЖЦ) внедряемого продукта и всех планируемых к запуску в пределах данного релиза продуктах, конкретном описании соответствующих ИT-услуг и всех их уровней, а также данные об обработке и авторизации RFC.

На этапе бизнес процесса выработки политики в отношении релизов и их планирование рассматриваются следующие вопросы:

Составление графика ввода в коммерческую эксплуатацию релиза;

Составление плана-графика тестирования;

Согласование территориальных объектов, тестовых и продуктивных сред, используемых мощностей, на которых произойдет распространение релиза;

Составление плана-оповещений сотрудников и бизнес-пользователей;

Согласование ролей на проекте и распределение ответственностей;

Разработка конкретных планов для отката установки;

Разработка стратегии обеспечения качества релиза;

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

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

Проектирование и разработка

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

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

Компоновка и конфигурирование релиза

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

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

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

Тестирование и приемка релиза

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

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

Результатом деятельности на этапе тестирования и приемки релиза будет являться:

протестированная документация по релизу;

-протестированные процедуры по установке и инсталляции;

-протестированные исправленные дефекты, которые были найдены в предыдущих версиях системы;

-протестированные компоненты релиза и новый функционал;

-перечень систем, которые могут подвергаться воздействию.

Планирование и развертывание

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

процесс планирование и внедрения включает в себя:

-планирование графиков установки релизов;

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

-оповещение пользователей о новых функциональных особенностях устанавливаемых релизов;

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

процесс развертывания новых релизов можно осуществлять несколькими способами:

Одновременная полная установка/развертывание релиза;

медленное поэтапное развертывание/установка релиза, которое делится на следующие виды:

-функциональное равнозначное наращивание, особенность заключается в том, что все пользователи одновременно получают доступ к новому функционалу;

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

-эволюционная инсталляция приложения с поэтапным увеличением функциональности.

Подготовка, обучение и оповещение

Перед установкой должен быть разработан план обучение пользователей, система оповещений, нотификаций об изменениях и новостная рассылка. Часто во время установки может быть не доступен функционал или в новом релизе может выведена из эксплуатации часть функционала и или добавлен новый. Во-первых, пользователь должен быть максимально информационно осведомлен о изменениях и возможных неудобствах, во-вторых, должен заранее получить обновленную инструкцию по использованию. помимо конечных пользователей о всех изменения должны быть оповещены: служба Service Desk и CRM системы — процесс управления взаимоотношениями с заказчиками.

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

Распространение и инсталляция релизов

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

после установке становиться актуально документации по новому релизу. Функционал становится доступным пользователям. Если были дефекты, то информация о закрытом дефекте передается в службы, которые работают с инцидентами (INC), обновляется информация в базе данных CMDB для облегчения процессов поиска и проверки лицензий на ПО и соглашений.

Каталогизация рисков и мер по их предотвращению

РискиМеры по предотвращениюРиск сбоя в работе продуктивной среды после установки нового релизаКачественное проведение работ и контроль на всех этапах тестирования;Риск возникновения задержек установки нового релиза в продуктивную среду из-за увеличения сроков тестированияПереговоры с бизнес заказчиком на предмет понимания важности качественного тестирования и увеличения сроков тестированияРиск появления большого числа не протестированных срочных релизовУвеличение штата тестированияРиск заниженной оценки сроков и бюджета проектаПереговоры с бизнес заказчикомРиск несоответствия результатов релиза заявленным требованиямДоработка функционала, повторные итерации тестирования продуктаРиск невыполнения обязательств по срокам поставки релизов поставщикомУстановка санкций для поставщика релизов, при частом повторе или злоупотреблении полномочий поставщика — поиск нового разработчика

3.11Моделирование процесса управления конфигурациями

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

Контекстная диаграмма процесса предоставлена на рисунке 3.42.

рисунок 3.42 — Диаграмма процесса управления конфигурациями

Данный процесс состоит из этапов для обработки и реализации новых требований:

·Планирование;

·Идентификация;

·Внесение изменений;

·Контроль и мониторинг статуса.

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

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

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

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

У каждой КЕ есть свой жизненный цикл, состоящий из:

·Планирования введения;

·Формирование заказа и получение;

·Тестирование;

·Ввод в эксплуатацию;

·обслуживание;

·Списание/снятие с регламента.

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

Каталогизация рисков и их предотвращение

ПроцессРискиБезопасностьУправление конфигурациямиНеверный уровень детализации БД КЕНа этапе анализа определить нужный объем атрибутов БД, удовлетворяющий всем требованиямНекорректный или медленный ввод информации при ручной обработке БД КЕАвтоматизация этапа идентификацииНедостаток ресурсов для документирования, проведения мониторинга и составления отчетностиКонтакты с руководством компании для привлечения ресурсовОтступление от процедур, определенных процессомКорректировка отступлений, объяснение ответственным негативных последствийПостепенная потеря актуальности данныхКонтроль процесса

3.12Моделирование процесса управления подрядчиками

Если изобразить на диаграмме процесс управления подрядчиками на самом верхнем уровне в нотации IDEF0, то он будет выглядеть, как показано на рисунке 3.3.

Рисунок 3.43 Диаграмма верхнего уровня процесса управление подрядчиками

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

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

·Выработка политики в отношении релизов и планирование. Ответственным за процесс является менеджер проекта.

·Проектирование. Ответственный — аналитик.

·Разработка. Ответственный — ведущий разработчик.

·Конфигурирование. Ответственный — архитектор.

·Тестирование и приемка релиза. Ответственный — архитектор.

·Планирование внедрения. Ответственный — консультант по внедрению, Менеджер·Распространения релизов и инсталляция. Ответственный — консультант по внедрению.

Диаграмма 2-го уровня декомпозиции процесса управление релизами изображена на рисунке 3.44.

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

рисунок 3.44 — декомпозиция второго уровня процесса управление подрядчиками

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

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

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

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

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

Каталогизация рисков и меры их предотвращения

РискиМеры по предотвращениюРиск некачественно выполненной работы подрядчикаТщательный контроль, введение отчетности по работе подрядной организацииРиск отсутствия подрядной организации, готовой взяться за исполнение работ заказчикаВозможно завешены требования, короткие сроки выполнения или слишком низкая оплата работРиск невыполнения работ подрядчиками в срокУстановка более четких метрик по работе организацииРиск заниженной оценки сроков и бюджета проектаПереговоры с подрядчикомРиск несоответствия результатов работы подрядчика заявленным требованиямДоработка продукта, услугиРиск невыполнения обязательств (частично или полностью) подрядчикомУстановка санкций для подрядчика, при частом повторе или злоупотреблении полномочий — поиск нового подрядчика

3.13Моделирование процесса управление отношениями с клиентами

Если изобразить процесс управление отношениями с клиентами на самом верхнем уровне в нотации IDEF0, то он будет выглядеть, как показано на рисунке 3.45.

Рисунок 3.45 — Декомпозиция процесса управление отношениями с потребителями

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

Контролируют процесс общепринятая идеология по работе с клиентами в компании или миссия, а также стандарты, нормативно-правовые акты и так далее.

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

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

·Стратегическое планирование. Ответственным за процесс является аналитики и руководящее звено.

·Анализ взаимодействия с клиентами. Ответственный — ·Реинжиниринг бизнес-процессов. Ответственный — бизнес-архитектор.

·Создание и внедрение CRM. Ответственный — разработчики, менеджер проекта.

·Обучение пользователей и поддержка. Ответственный — менеджер проекта, Help Desk.

·Оценка эффективности CRM-подхода. Ответственный — аналитик.

Декомпозиция второго уровня для процесса управление отношениями с потребителями представлена на рисунке 3.46.

Рисунок 3.46 — Декомпозиция второго уровня процесса управление отношениями с клиентами

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

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

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

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

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

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

Информация о эффективности процесса снова передается руководству и в дальнейшем при анализе данных руководство принимает решение о повторном внедрении, модернизации или отказа от CRM-решения.

Каталогизация рисков и меры их предотвращения

РискиМеры по предотвращениюРиск невозможности внесения/изменения данных о клиентеПоддержка Help DeskРиск недоступности (части) данных о клиентеПоддержка Help DeskРиск потери (части) данных о клиентеПоддержка Help Desk Системный администраторРиск внедрения концепции взаимоотношений с клиентами, не увязанной с общей стратегией компанииТщательная подготовка и планирование концепцииРиск несоответствия реальной практики взаимоотношений с клиентами, разработанной концепции, и разработанной автоматизированной системыДоработка CRMРиск устаревания программных или технических решений за период внедренияТщательное планирование на начальных этапах проектирования CRM

Заключение по третьей главе

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

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

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

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

4.Создание единой инфраструктуры ИТ-предприятия

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

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

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

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

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

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

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

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

К департаменту управления инцидентами и проблемами принадлежат всевозможные Call-центры и Service Desk. Отделы департамента по работе с клиентами тесно взаимодействуют с отделом Service Desk для выявления непредвиденных ситуаций, анализа их возникновения и устранения причин для обеспечения быстрого восстановления работы сервисов. Данный департамент очень важен для связи с клиентами, благодаря ему повышается качество предоставления услуг за счет принятия звонков и сбора информации, которая в дальнейшем анализируется. Service Desk обычно обрабатывает стандартные запросы на поддержку функционирования системы, настройку нового оборудования и программного обеспечения, а также обработка инцидентов, создающих препятствия для функционирования систем. Уровень поддержки прорабатывается в соответствии с количеством обслуживающего департаментом систем. Существует несколько способов формирования отделов: централизованная система сбора заявок с последующим разнесением их по ответственным и локальным отделам, отвечающим только за свою область. Также возможно разнесение служб по признаку квалификации, примером такого разнесения являются несколько линий поддержки, с повышением уровня линии, на которых повышается уровень квалификации сотрудников. При любом типе отделов необходимо определение способа коммуникаций и написание инструкций по обращению.

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

Для успешного выпуска релиза необходимо произвести анализ потребностей пользователей. Это одна из задач департамента планирования и аналитики. Также в ходе работы отдела бизнес-планирования происходит построение одного из наиболее важных документов — соглашения об уровне услуг.

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

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

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

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

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

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

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

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

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

Заключение по четвертой главе

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

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

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

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

Заключение

В рамках магистерской диссертации были выполнены поставленные задачи, а именно:

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

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

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

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

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

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

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

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

Список литературы

1.ИСО/МЭК 15288:2002 — Проектирование систем — Процессы жизненного цикла системы.

2.ИСО/МЭК 20000-1(-2) :2005 Информационные технологии. Управление сервисами.

.ISO 9000:2000 Системы менеджмента качества — Основные положения и словарь.

.ISO 9001:2000 — Системы менеджмента качества — Требования.

.ISO 9004:2000 — Системы менеджмента качества — руководство по улучшению деятельности.

.ГОСТ Р50.1.028-2001 Методология функционального моделирования IDEF/0.

7.Balanced Scorecard Functional Standards™ Release 1.0a, May 5, 2000.

8.DELIVERING RESULTS: EVOLVING BPR FROM ART TO ENGINEERING. Richard J. Mayer, Paula S. deWitte. www.idef.com <#"justify">10.Андерсен Бьерн. бизнес-процессы. Инструменты совершенствования. — Москва, РИА «стандарты и качество», 2003 г.

.А.Н. Бирюков Лекции о процессах управления информационными технологиями, М.: бином, 2010

12.Август-Вильгельм Шеер, Бизнес-процессы: основные понятия, теории, методы, Москва.: Просветитель, 1999.

.А. Шматалюк и др. Моделирование бизнеса. Методология ARIS. Практическое руководство. Москва: «Серебряные нити», 2001 г., 327 с.

14.Брукс П. Метрики для управления ИТ-услугам, М.: Альпина бизнес Бук, 2008

15.Васильев Р. Разработка ИТ-стратегии // Интуит, 2011. Режим доступа: <#"justify">.Гради Буч Объектно-ориентированный анализ и проектирование с примерами приложений, 3 издание, : Пер с англ. М.: ООО «И.Д. Вильямс», 2008 г.

.Грекул В.И. , Денищенко Г.Н. , Коровкина Н.Л. Проектирование информационных систем. СПб: Интернет-университет информационных технологий — ИНТУИТ.ру, 2008.

.Зараменских Е.П. Управление жизненным циклом информационных систем — Новосибирск: Издательство ЦРНС, 2014 — 270 стр.

.Крэг Ларман, Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Вильямс, 2009 г., 736 стр.

20.Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. Москва, 1993 г.

21.Материалы ITIL [электронный ресурс]. — Режим доступа: www.ogc. gov.uk/guidance_itil_4672.asp.

22.М. Робсон, Ф. Уллах. Практическое руководство по реинжинирингу бизнес-процессов. — М.: Аудит, 1997.

.С.В. Маклаков. BPWin и ERWin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2000.256 с.

24.С.В. Черемных, И.О.Семенов, В.С. Ручкин. Структурный анализ систем: IDEF-технологии. Москва: «финансы и статистика», 2001.208 с.

.Сергеева, Ю. С. Защита информации. / Ю. С. Сергеева. — М. : А-Приор, 2012. — 128 с.

26.Скрипник Д. Управление ИТ на основе COBIT 4.1 // Интуит, 2012. Режим доступа: <#"justify">.Скопин И.Н. Модели жизненного цикла программного обеспечения // Виртуальный компьютерный музей, 2004. Режим доступа: <#"justify">28.Янг С. Системное управление организацией. Пер. с англ. под ред. С. П. Никанорова, С. А. Батасова. М., «советское радио», 1972 г.

.«Введение в ИТ-Сервис‐менеджмент» ред. Потоцкий М.Ю., Гл. редактор английской версии: Ян Ван Бон (Jan van Bon) 2003г. — 237с.

.Colin Rudd. An Introductory Overview of ITIL. itSMF Ltd, 2004.

.INTUIT, национальный открытый университет. ITIL/ITSM — концептуальная основа процессов ИС-службы (курс лекций) // Режим доступа: #»justify»>.ISO/IEC 38500 Corporate Governance of Information Technology, International Standard, 2008

.ITIL v.3. 2011 Edition, OGC (Office of Government Commerce) // TSO — GB., 2011.

.Frederick W. Broussard. Quantifying the Return on Investment from Deploying Configuration Management Solutions. IDC, 2006.

.The Risk IT Framework, ISACA, 2009.

36.The Strategy-Focused Organization: How Balanced Scorecard Companies Thrive in the New Business Environment by Robert S. Kaplan <HTTP://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Kaplan%2C%20Robert%20S./002-9176883-2703208>, David P. Norton <HTTP://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Norton%2C%20David%20P./002-9176883-2703208>. Harvard Business School Press.

Учебная работа. Обзор решений моделирования бизнес-процессов управления ИT сервисами