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

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

Рубрика Менеджмент и трудовые отношения
Вид дипломная работа
Язык русский
Дата добавления 10.02.2017
Размер файла 4,8 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

С помощью данного метода осуществляется моделирование последовательности выполняемых действий, а также выявляются и фиксируются взаимозависимости между ними в рамках процессов. Модели 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 20000

CMMI

Модель зрелости

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

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

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) предполагает внедрение различных процесс управления ИТ-услугами, использование, которых обеспечивает высокий уровень качества услуг. Из-за несогласованности и отсутствия единой базы данных у имеющихся подходов, методов и стандартов прослеживаются четкие различия в стандартизации базовых определений, понятий и основных принципов процесса управления ИТ-услугами.

Рисунок 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.

Число решенных проблем, связанных с информационной безопасностью

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

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


Подобные документы

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

    контрольная работа [34,8 K], добавлен 20.02.2016

  • Подходы к определению понятия "моделирование бизнес-процессов". Классификация бизнес-процессов. Стандарт функционального моделирования IDEF0. Стандарт динамического моделирования IDEF2. Стандарт моделирования процессов IDEF3–IDEF14 и потоков данных DFD.

    контрольная работа [197,3 K], добавлен 11.06.2010

  • Сущность бизнес-процессов и основные качественные и количественные критерии их оптимизации. Сравнительный анализ методологий моделирования бизнес-процессов, выбор программного средства на примере УУПП "Автоконтакт" ВОС; принцип автоматизации управления.

    дипломная работа [256,9 K], добавлен 18.12.2012

  • Целесообразность внедрения процессного управления на ООО "Мир Алюминия". Разработка рекомендаций и механизма оптимизации основных бизнес-процессов как пути совершенствования системы управления на исследуемом предприятии. Моделирование бизнес-процессов.

    дипломная работа [2,3 M], добавлен 08.01.2012

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

    реферат [519,5 K], добавлен 12.09.2011

  • Исследование методологий описания бизнес-процессов, особенности оценки их эффективности. Информационные технологии моделирования бизнес-процессов. Разработка мероприятий по совершенствованию бизнес-процессов на примере швейной фабрики ООО "Бостон".

    дипломная работа [732,7 K], добавлен 29.06.2015

  • Эффективное внедрение процессного подхода. Основные виды бизнес-процессов. Вопросы управления бизнес-процессами. Проект реинжиниринга бизнес процессов организации. Общая характеристика организации ООО "Мир стекла". Разработка бизнес-процесса организации.

    курсовая работа [1,1 M], добавлен 17.11.2014

  • Понятие бизнес-моделирования. Анализ финансово-хозяйственной деятельности компании ЗАО "Ясень"; разработка бизнес-процессов производства, их оптимизация и повышение эффективности работы предприятия с внедрением программного продукта "1С:Молокозавод".

    дипломная работа [6,0 M], добавлен 15.09.2012

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

    дипломная работа [1,5 M], добавлен 07.07.2012

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

    курсовая работа [49,8 K], добавлен 07.09.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.