- протестированные процедуры по установке и инсталляции;

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

- протестированные компоненты релиза и новый функционал;

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

Планирование и развертывание

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

Процесс планирование и внедрения включает в себя:

- планирование графиков установки релизов;

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

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

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

Процесс развертывания новых релизов можно осуществлять несколькими способами:

• Одновременная полная установка/развертывание релиза;

• Медленное поэтапное развертывание/установка релиза, которое делится на следующие виды:

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

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

- эволюционная инсталляция приложения с поэтапным увеличением функциональности.

Подготовка, обучение и оповещение

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

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

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

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

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

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

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

Список литературы

1. ИСО/МЭК 15288:2002 - Проектирование систем -- Процессы жизненного цикла системы.

2. ИСО/МЭК 20000-1(-2) :2005 Информационные технологии. Управление сервисами.

3. ISO 9000:2000 Системы менеджмента качества - Основные положения и словарь.

4. ISO 9001:2000 - Системы менеджмента качества - Требования.

5. ISO 9004:2000 - Системы менеджмента качества - Руководство по улучшению деятельности.

6. ГОСТ Р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

9. FIPS 183 США «Integration definition for function modeling (IDEF0)».

10. Андерсен Бьерн. Бизнес-процессы. Инструменты совершенствования. - Москва, РИА «Стандарты и качество», 2003 г.

11. А.Н. Бирюков Лекции о процессах управления информационными технологиями, М.: Бином, 2010

12. Август-Вильгельм Шеер, Бизнес-процессы: основные понятия, теории, методы, Москва.: Просветитель, 1999.

13. А. Шматалюк и др. Моделирование бизнеса. Методология ARIS. Практическое руководство. Москва: «Серебряные нити», 2001 г., 327 с.

14. Брукс П. Метрики для управления ИТ-услугам, М.: Альпина Бизнес Бук, 2008

15. Васильев Р. Разработка ИТ-стратегии // Интуит, 2011. Режим доступа: <http://www.intuit.ru/studies/courses/473/329/lecture/8001>

16. Гради Буч Объектно-ориентированный анализ и проектирование с примерами приложений, 3 издание, : Пер с англ. М.: ООО «И.Д. Вильямс», 2008 г.

17. Грекул В.И. , Денищенко Г.Н. , Коровкина Н.Л. Проектирование информационных систем. СПб: Интернет-университет информационных технологий - ИНТУИТ.ру, 2008.

18. Зараменских Е.П. Управление жизненным циклом информационных систем - Новосибирск: Издательство ЦРНС, 2014 - 270 стр.

19. Крэг Ларман, Применение 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.

23. С.В. Маклаков. BPWin и ERWin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2000.256 с.

24. С.В. Черемных, И.О.Семенов, В.С. Ручкин. Структурный анализ систем: IDEF-технологии. Москва: «Финансы и статистика», 2001.208 с.

25. Сергеева, Ю. С. Защита информации. / Ю. С. Сергеева. -- М. : А-Приор, 2012. -- 128 с.

26. Скрипник Д. Управление ИТ на основе COBIT 4.1 // Интуит, 2012. Режим доступа: <http://www.intuit.ru/studies/courses/3704/946/info>.

27. Скопин И.Н. Модели жизненного цикла программного обеспечения // Виртуальный компьютерный музей, 2004. Режим доступа: <http://www.computer-museum.ru/books/n_collection/models.htm>

28. Янг С. Системное управление организацией. Пер. с англ. под ред. С. П. Никанорова, С. А. Батасова. М., «Советское радио», 1972 г.

29. «Введение в ИТ-Сервис?менеджмент» ред. Потоцкий М.Ю., Гл. редактор английской версии: Ян Ван Бон (Jan van Bon) 2003г. - 237с.

30. Colin Rudd. An Introductory Overview of ITIL. itSMF Ltd, 2004.

31. INTUIT, Национальный открытый университет. ITIL/ITSM - концептуальная основа процессов ИС-службы (курс лекций) // Режим доступа: http://www.intuit.ru/studies/courses/1164/260/lecture/3561.

32. ISO/IEC 38500 Corporate Governance of Information Technology, International Standard, 2008

33. ITIL v.3. 2011 Edition, OGC (Office of Government Commerce) // TSO - GB., 2011.

34. Frederick W. Broussard. Quantifying the Return on Investment from Deploying Configuration Management Solutions. IDC, 2006.

35. 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, David P. Norton. Harvard Business School Press.

Размещено на Allbest.ru