Бесплатный фрагмент - ИТ-архитектура

Предисловие

Об авторе

Вадим Алджанов (англ. Vadim Aldzhanov) [Microsoft MCP, MCSA Security, MCSE Security, MCTS, MCITP, MCITP SQL Database Administrator, Cisco CCNA, VMware VCP4, CompTIA A+, Network+, Security+, EC–Council CEH и ECSA, SNIA Certified Storage Professional SCSP, Wireless Technology CWTS, CWNA, CWSP, IT Management ITILv3, Apple Certified Associate — Integration | Management].

В руководстве собраны и обобщены знания и опыт за более чем 17+ лет работы в ИТ. В течении 14 лет проработал в банковской сфере, большую часть времени на позиции руководителя ИТ департамента. На данный момент являюсь ИТ Архитектором в одном из крупных холдингов страны. Имею степень бакалавра по специальности «Радиотехника» и степень магистра по направлению «Компьютерные Информационные Системы (CIS)». Продолжаю образование на получение докторской степени по направлению «Менеджмент Информационных Систем (MIS)». Кроме этого имеется порядка тысячи часов обучения на специализированных курсах по направлениям системное администрирование, компьютерные сети, беспроводные сети, системы хранения, системы виртуализации, информационная безопасность, управление ИТ сервисами, управление проектами, банковское дело, пластиковые карты, стратегическое планирование, проведение аудита и прочие. Профиль в LinkedIn: https://www.linkedin.com/in/vadim-aldzhanov-623a7b44/

Цели книги

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

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

Сферы, охваченные книгой

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

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

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

Книга предназначена для широкого круга читателей и будут полезна:

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

Руководителям ИТ подразделений, ИТ архитекторам, менеджеров среднего звена ИТ департамента, а также менеджерам проектов книга предоставляет теоретические основы управления ИТ сервисами (ITSM) с применением рекомендаций практик ITIL, интеграцию методики Управление Проектами (PMI) в ИТ, вопросы аудита ИТ (CobiT) и Информационной Безопасности. Вся теоретическая база рассматривается на практических примерах реализации ИТ архитектуры и инфраструктуры.

ИТ специалистам помимо теоретических основ внедрения и сопровождения ИТ сервисов предоставляется возможность рассмотрения построения компонентов ИТ инфраструктуры на примере таких продуктов как Windows 2016 Server и Windows 10, комплексного решение Microsoft System Center 2016, корпоративного портала Microsoft SharePoint Server 2016 и Microsoft Project Server 2016, Exchange 2016 и Skype for Business 2015, функции Direct Access, Hyper-V и другие.

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

Благодарность

Выражаю благодарность друзьям, учителям, руководителям и коллегам за помощь в написании книги, а также бесценный опыт и знания полученный от общения с такими людьми как Александр Буслаев («AIG Group»), Иршад Гулиев («SINAM»), Фазиль Маммедов («ROTABANK»), Яна Хмельницкая и Karsten Stellner («LFS Financial Systems GmbH»), Thomas Engelhardt («Microfinance Bank of Azerbaijan»), Andrew Pospielovsky («ACCESSBANK») и Alan Crompton («Baku European Games Operation Committee BEGOC 2015»).

Юридическое уведомление

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

Авторские права

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

Отказ от ответственности

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

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

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

Часть I: Теоретические Основы

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

Глава 1: Концепции построения Архитектуры Предприятия — В данной главе рассматриваются вопросы построения Архитектуры Предприятия, построения ИТ стратегии и т п.

Глава 2: Концепция Управления Проектами — в главе рассматриваются основы Управления Проектами, применяемые методологии, принятые методы и т п.

Глава 3: Концепция Управления Рисками — в главе рассматриваются методики и методы оценки рисков, классификация рисков и типы реагирования на риски.

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

Глава 5: Концепция Управление Бизнес Процессами и Модели Деловой Активности различных сфер бизнеса, Рассмотрены основы построения бизнес процессов, виду организации бизнеса и связь с информационными системами.

Глава 6: Концепция Интеграции Данных и централизация ИТ — В данной главе рассмотрены вопросы по интеграции данных между различными информационными системами, различные архитектурные решения, проблемы и возможности. Рассмотрены уровни централизации Автоматизированных Систем Управления.

Глава 7: Концепция выбора ИТ решений — Рассмотрены проблемы выбора ИТ решений, а также предложены механизмы по выбору и обоснованию того или иного решения.

Глава 8: Концепция Информационной Безопасности — Рассмотрены вопросы информационной безопасности, порядок организации взаимодействия информационной безопасности и ИТ.

Глава 9: Концепция Управления ИТ сервисами — Рассмотрены процессы построения управления ИТ сервисами с применением практики ITIL.

Глава 10: Концепция Контроля и аудита ИТ — рассмотрены общие вопросы по контролю ИТ и проведению аудита

Глава 11: Концепция Определение стоимости и модели финансирования ИТ — Рассмотрены модели финансирования, принципы оценки ИТ проектов, методы и практики расчета стоимости ИТ сервисов и т п.

Концепция Архитектуры Предприятия

Общие Положения

В данной главе описывается общая информация по Архитектуре Предприятия (Enterprise Architecture). Обобщенное определение можно представить, как:

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

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

•TOGAF — Enterprise Architecture

•ISO/IEC 20000 — Quality in IT Service Management

•ISO/IEC 27000 — Best Practice IT Security Standards

•CobiT v5 — Audit and Control Framework

•ITIL v3 — Best practices in IT Service Management

•MOF — Microsoft Operations Framework

•PMI — Project Management Institute

Архитектура призвана ответить на такие вызовы и проблемы организации как:

•Недовольство бизнеса ИТ‐службой. Причины могут быть объективные или субъективные.

•Невозможность оценить эффективность использования информационных технологий в бизнесе.

•Отсутствие порядка в «зоопарке» ИТ решений и систем, внедренных в организации.

•Сложность принятия решений, связанных с информационными технологиями

•Сложность согласование ИТ‐бюджета и запуск ИТ‐проектов.

•Рост ценности «Информации» и связанности бизнеса и ИТ.

•Отсутствие прозрачных и понятных связей бизнеса и ИТ?

•Можно ли решить актуальные задачи бизнеса с использованием ИТ?

•Как заставить ИТ давать компании большую ценность?

•Как нужно менять ИТ при изменениях в бизнесе?

•ИТ системы сложны, не управляемы и дороги в обслуживании

•ИТ системы сдерживают организацию от адекватного реагирования на изменения в бизнесе

•Критичная для бизнеса информация не своевременна и не адекватна

•Отсутствует культура общения бизнеса и ИТ

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

Основные аспекты Архитектуры Предприятия

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

Определение Структуры Предприятия

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

Структура организации — фиксированное упорядоченное множество объектов и связей между ними.

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

Вертикальное разделение — по уровню подчинения

Горизонтальное разделение — по функциям и специфики деятельности

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

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

Иерархическая (бюрократическая) — формирование структуры исходя из структуры организации, разделение труда на функции и ответственности работников.

Линейная — управление по прямой (руководитель — подчинённый), общение между подразделениями только через руководителей подразделений

Функциональная — взаимодействие идет по функциональному признаку

Линейно-функциональная — взаимодействие совмещается по линейному и функциональному типу (наиболее используемая модель)

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

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

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

Проектные — организуется при ведении проектов

Матричные (программно-целевые) — принцип двойного подчинения, непосредственное подчинения руководителю, и проектному менеджеру

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

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

•Специфика и степень разнообразия деятельности

•Географическое размещение

•Уровень централизации в организации

•Стратегия организации

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

Определение роли ИТ в составе организации

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

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

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

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

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

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

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

Выстраивание взаимоотношения между бизнесом и ИТ

Сфокусировать действия ИТ на целях и задачах бизнеса. Бизнес и ИТ стороны по-разному видят задачи, цели и ожидания по отношению друг к другу. Видение ИТ сотрудников «… мы прекрасно разбираемся в технологиях, нам платят деньги за умение программировать, настраивать, устанавливать и решать технические проблемы и т п. Наша работа начинается после получения технического задание…». Видение со стороны бизнеса — «… столько новых ИТ технологий, ИТ должен нам внедрить нам какое-то решение, чтобы увеличить объем продаж. Или что еще хуже, нам нужно решение ХХХ, оно есть у конкурентов и поэтому продажи у них выше… внедряйте мы уже все решили вы ничего не понимаете бизнесе…». Задача ИТ директора, участие на равных в обсуждении стратегии бизнеса. Общие принцип можно определить, как: «бизнес описывает свои требования и ожидания (Бизнес требования), ИТ в свою очередь формирует техническое задание для достижения целей.»

Наладить сотрудничество между бизнесом и ИТ.

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

Получить максимальную ценность от ИТ.

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

ЦЕННОСТЬ = ВЫГОДА — ЗВТРАТЫ

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

С точки зрения ИТ: Соблюдение ИТ ценностей и требований (технологичность, безопасность и управляемость ИТ).

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

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

Управлять изменениями.

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

Навести порядок и управлять развитием ИТ.

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

Базовые принципы построения Архитектуры Предприятия

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

•Какая информация/данные критичны для бизнеса компании и как они организованы;

•Какие приложения будут поддерживать бизнес;

•Смогут ли эти приложения эффективно взаимодействовать между собой и с внешними системами партнеров и поставщиков;

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

•Достаточно ли обеспечена информационная безопасность систем;

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

•Какие стандарты должны использоваться при разработке и закупке компонент системы;

Формирование архитектуры производится с использованием распространенных методологий, рамочных моделей (frameworks) описания архитектуры и инструментальных средств моделирования (например, ARIS IT Architect) — с учетом имеющихся у Заказчика опыта и предпочтений. В ходе проекта формируется набор архитектурных принципов, определяются используемые и перспективные стандарты и разрабатываются модели архитектуры в целом и ее отдельных областей (приложения, данные, интеграция, техническая инфраструктура, безопасность и др.)

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

Обследование предприятия

•Цели и основные задачи:

•Четкое определение задач и целей проекта;

•Формулирование функционально-технических требований к проекту;

•Инфраструктурный аудит ИТ-системы предприятия для проектирования архитектуры решения;

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

•Получение данных для обоснования количества лицензий;

•Оценка ресурсов, которые потребуются для реализации проекта;

•Оценка рисков проекта;

•Разработка предварительного плана проекта, графика работ и спецификации поставок по каждому этапу и проекту в целом.

Результаты обследования:

•Отчет с фиксацией ситуации в виде «Как есть»;

Предложение по созданию информационной системы в виде «Как необходимо»;

•Предложение по «Функционально-техническим требованиям к проекту»;

•План реализации проекта;

•Оценка рисков проекта и предложения по их минимизации;

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

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

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

•Развертывание платформы с базовыми сервисами обработки и хранения документов;

•Опытная эксплуатация решения;

•Интеграция с ERP-системой;

•Ввод системы в промышленную эксплуатацию.

Обучение технического персонала и пользователей.

Обеспечение дополнительного функционала — работы, выделенные на этапе обследования в отдельные этапы.

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

Модель Архитектуры Предприятия можно разделить на несколько ключевых уровней (категорий):

•Архитектура бизнеса — содержит стратегию компании, подход к управлению, организационную структуру и ключевые бизнес процессы.

•Архитектура информационных систем — описывает, как устроены или будут устроены информационные системы компании. Архитектура информационных систем может быть разбита на две подгруппы:

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

•Архитектура данных — содержит описание логической и физической структуры данных компании, а также подход и средства управления данными.

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

Следующим уровнем иерархии может быть по:

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

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

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

Уровни зрелости ИТ

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

Начальный или «локализация»

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

Основные симптомы данного этапа развития:

•Роль ИТ департамента — второстепенная

•Стратегия ИТ департамента — отсутствует

•Бюджет ИТ департамента — отсутствует

•Тип деятельности ИТ департамента — пассивный, только по запросу.

•Задачи менеджмента — максимальная экономия

•Место в организационной структуре компании — служба в составе бизнес департамента (администрация, финансы)

Развития или «стандартизация»

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

•Роль ИТ департамента — не стратегический ресурс

•Стратегия ИТ департамента — отсутствует или на начальном уровне

•Бюджет ИТ департамента — отсутствует или управляемый со стороны

•Тип деятельности ИТ департамента — слабо активный по ИТ инфраструктуре и пассивный, только по запросу для бизнеса

•Задачи менеджмента — минимальные инвестиции

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

Становления или «оптимизация»

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

•Роль ИТ департамента — важная

Стратегия ИТ департамента — частично отвечает бизнес требованиям

•Бюджет ИТ департамента — существует и управляем

•Тип деятельности ИТ департамента — реактивная реакция на бизнес требования,

•Задачи менеджмента — получение бизнес выгоды в краткосрочной перспективе

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

Зрелый

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

•Роль ИТ департамента — стратегический ресурс организации

•Стратегия ИТ департамента — интегрированная в бизнес стратегию компании

•Бюджет ИТ департамента — существует и рассматривается как инвестиции в бизнес

•Тип деятельности ИТ департамента — активная реакция (превентивная) на бизнес требования

•Задачи менеджмента — долгосрочные инвестиции в бизнес

•Место в организационной структуре компании — департамент, ИТ директор в составе совета директоров

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

•Проблемы поддержки роста и изменений бизнеса

•Дублирование бизнес процессов

•Многообразие платформ и систем

•Неудовлетворенность текущем состоянием ИТ

Критерии выбора методологии

Так как методологии сильно отличаются друг от друга, то следует задать критерии для их сравнения.

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

Полнота процесса, определяет, насколько детально представлен процесс создания архитектуры предприятия.

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

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

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

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

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

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

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

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

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

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

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

•«Zahman Framework» — наиболее ранняя и известная методология. Идеально подходит для «классификации» элементов архитектуры.

•«TOGAF (The Open Group Architecture Framework)». Методология получила широкую известность и распространение, во многом за счет открытости. Представляет из себя каркас «построения процессов».

•«Gartner» — методология экспертного анализа с использованием «лучших» практик.

•«FEAF» — методология построения архитектуры, использующая «сервис ориентированный» подход.

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

•Текущее состояние «As-is» или «Baseline Architecture».

•Переходное состояние «Transition Architecture».

•Будущее состояние «To-be» или «Target Architecture».

•План перехода «Enterprise Architecture Management Plan & Roadmap»

В общем случае Архитектура Предприятия представляет из себя план перехода от «Текущего» к «Будущему» состоянию организации. Архитектурный проект длится несколько лет и инициирует множество ИТ проектов. Эти проекты будут разной продолжительности, у них разные даты начала и окончания. Их нужно сгруппировать таким образом, чтобы изменения в бизнесе и ИТ происходили в нужное время, с минимальными рисками и без проблем с совместимостью. То есть архитектура может переходить из одного работоспособного состояния в другое несколько раз за время архитектурного проекта. Промежуточное состояния называют «переходной архитектурой» (Transition Architecture).

Архитектура Предприятия на основе методологии «ZAHMAN FRAMEWORKS»

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

•целостность в отношении предприятия;

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

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

•простота описания

Модель Захмана имеет такие преимущества перед другими моделями:

•Отличается своей простотой понимания как техническими, так и нетехническими специалистами.

•Более детальными описаниями компонентов архитектуры

•Возможность применения для планирования, позволяющего лучше принимать решения.

•Наиболее наглядным представлением компонентов компании.

•Описанием сложной архитектуры небольшим количеством нетехнических понятий.

•Независимостью конкретных инструментов описания.

•Может использоваться как средство для описания архитектур сложных производственных систем любого типа.

Архитектура Предприятия на основе методологии «FEAF»

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

В основе FEAF лежат пять эталонных моделей:

•Исполнительная модель.

•Бизнес-модель.

•Сервисная модель Компонента.

•Техническая эталонная модель.

•Эталонная модель данных.

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

•Анализ Архитектуры

•Архитектурное определение

•Стратегия инвестиций и финансирования

•План управления программой и реализация проекта

Архитектура Предприятия на основе методологии «GARTNER»

Методология Gartner — эту модель можно описать как набор рекомендаций по созданию архитектуры предприятия.

Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:

•Среда бизнес-взаимодействия (Business Relationship Grid);

•Бизнес-процессы и стили бизнес-процессов;

•Шаблоны;

•Технологические строительные блоки (кирпичики — bricks).

Методология Gartner — по сути своей не является методологией, как например структурированная модель Захмана, ни процессом как TOGAF, ни как FEA. Gartner — является набором практических рекомендаций. Данная методология является сборником советов по построению архитектуры предприятия от одной из наиболее известных в мире консалтинговых ИТ-компаний — Gartner.

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

•Горизонтальные слои.

•Вертикальные домены.

•Вертикальные элементы технической архитектуры.

Архитектура Предприятия на основе методологии «TOGAF»

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

•Обзор бизнес — архитектуры

•Описание существующей системы с необходимой степенью детализации

•Выявление и описание элементарных архитектурных блоков — кандидатов на использование в новой архитектуре

•Разработка черновика технического отчета

•Направление черновика отчета на рецензирование

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

•Подход TOGAF позволяет построить весь архитектурный процесс — от запуска практики до результатов.

•TOGAF — это де-факто является стандартом. Имеется программа сертификации по TOGAF.

•TOGAF — абсолютно бесплатен. Множество открытых ресурсов, скачивайте и используйте.

•TOGAF содержит полный набор инструментов для создания и развития архитектурной практики в организации. Есть пошаговый процесс для разработки описания Архитектуры Предприятия и полный набор инструментов, шаблонов и т. д.

•TOGAF совместим с другими Фреймворками, например, с «Zahman Framework». Как архитектурный процесс модель TOGAF дополняет модель Захмана — которая, классифицируется как архитектурная таксономия. Захман показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов.

Методология TOGAF и инфраструктура Захмана хоть и объединены к категории «инфраструктур предприятия», но имеют отличия в своих принципах, структурах и компетенциях. TOGAF- представляет собой функциональную и динамичную инфраструктуру, которая включает руководящие принципы моделей процесса их использования. В то время как фреймворк Захмана представляет собой статичную структуру архитектуры, наиболее эффективна для применения анализа и метаанализа фреймворков инфраструктур. Несмотря на значительные отличия данных фреймворков их можно использовать совместно.

Базовые принципы

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

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

В состав модели TOGAF входят две основные компоненты:

•методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры.

•Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML.

Описание TOGAF включает в себя 7 частей:

•Introduction. Cодержит высокоуровневое описание ключевых концепций Архитектуры в целом и TOGAF в частности.

•Architecture Development Method (ADM). Ключевая часть TOGAF, описывает пошаговую методику разработки Архитектуры Предприятия.

•ADM Guidelines and Techniques. Включает в себя описание правил и техник, которые используются в TOGAF ADM.

•Architecture Content Framework. Описывает подход к описанию Архитектуры Предприятия. Содержит метамодель архитектурных артефактов, структуру и описание типовых архитектурных артефактов.

•Enterprise Continuum & Tools. Описан подход к категоризации и хранению результатов архитектурных активностей.

•TOGAF Reference Models. Описание эталонных моделей, которые вы можете использовать в ваших проектах.

•Architecture Capability Framework. Подход к организации архитектурной практики в компании. Структура, процессы, роли, навыки и полномочия, требуемые для работы архитектурной практики в компании.

В качестве основных процессов построения Архитектуры Предприятия важно внедрить всего четыре ключевых процесса:

•Создания и развития Архитектуры Предприятия.

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

•Контроль реализации архитектурных решений.

•Управления практикой.

Метод Развития Архитектуры (Architecture Development Method ADM) TOGAF

В TOGAF процессы создания и развития, управления изменениями, контроля реализации архитектурных решений интегрированы в единый архитектурный цикл Метод Развития Архитектуры (Architecture Development Method ADM). Данный метод можно и нужно адаптировать под задачи вашей компании на всех уровнях разработки архитектуры. При этом, нет необходимости делать все возможные документы. Не нужно погружаться во все детали. На каждом этапе ADM предлагает готовый набор техник, инструментов, шаблонов и чек листов. Метод Развития Архитектуры (ADM) содержит десять фаз. Каждая фаза, в свою очередь разбивается на под-процессы (этапы), отдельные работы и так далее.

Например, фаза D включает следующие основные под-процессы:

Описание существующей технологической архитектуры.

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

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

•Выявление и описание элементарных архитектурных блоков — кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.

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

•Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.

Формирование целевой технологической архитектуры.

•Описание существующей системы в терминах TOGAF.

•Определение перспектив (представлений) архитектуры.

•Формирование модели целевой архитектуры.

•Определение ИТ-служб (сервисов).

•Подтверждение учета бизнес-требований.

•Определение архитектуры и используемых блоков (шаблонов).

•Проведение анализа расхождений (gap analysis).

Фазы и задачи Метода Развития Архитектуры

Предварительная фаза. Основные задачи:

•Создать архитектурную практику,

•подготовить компанию к запуску архитектурных проектов,

•заручиться поддержкой руководства,

•сформулировать архитектурные принципы,

•адаптировать методологию под цели и задачи компании

Фаза А — Видение архитектуры. Основные задачи:

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

•разработать «Устав проекта» и получить формальное подтверждение старта проекта.

Фаза B — Бизнес Архитектура. Основные задачи:

•Разработать архитектуру с описанием текущей и целевой архитектуры,

•Анализ расхождений

Фаза C — Архитектура Информационных Систем. Задачи:

•Разработать архитектуру с описанием текущей и целевой архитектуры,

•Анализ расхождений

Фаза D — Техническая Архитектура. Основные задачи:

•Разработать архитектуру с описанием текущей и целевой архитектуры,

•Анализ расхождений

Фаза Е — Возможности и решения. Основные задачи:

•Выполнить начальное планирование реализации задач проекта.

•Идентифицировать основные проекты внедрения и сгруппировать их в переходные архитектуры.

Фаза F — Планирование миграции. Основные задачи:

•Анализ затрат и рисков.

•Разработка детального плана внедрения и миграции.

Фаза G — Управление реализацией. Основные задачи:

•Архитектурный надзор за проектами внедрения.

•Подготовить архитектурные контракты.

•Обеспечить соответствие архитектуре результатов проектов внедрения.

Фаза H — Управление изменениями архитектуры. Задачи:

•Подготовится к следующему витку жизненного цикла архитектуры.

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

Управление требованиями. Основные задачи:

•На каждой фазе архитектурного проекта собираете и согласуете бизнес требования.

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

Спецификация TOGAF также позволяет гибко работать с этапами. В самой спецификации говорится следующее:

•Перед применением методики разработки архитектуры необходимо проверить компоненты на применимость, а затем связать их с конкретными обстоятельствами отдельного предприятия. Это позволяет создать методику разработки архитектуры для конкретного предприятия.

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

•Модель TOGAF обладает еще большей гибкостью в отношении созданной архитектуры. Фактически TOGAF, как это ни удивительно, «ничего не знает» об архитектуре. Окончательная архитектура может с одинаковым успехом быть хорошей, плохой или неопределенного качества. В TOGAF описывается, как создать архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит от опыта персонала компании и консультанта по TOGAF. Те, кто внедряет TOGAF в надежде получить чудодейственное средство, будут жестоко разочарованы (впрочем, как и при использовании любой одной методологии).

Базовая Архитектура (Foundation Architecture).

Базовая Архитектура, включает в себя:

•набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model — TRM);

•набор элементарных архитектурных элементов, которые используются как «строительные блоки» при построении конкретных решений;

•база данных стандартов (Standards Information Base).

Концепция использования Базовой архитектуры определяется в соответствии с иерархией архитектур, входящих в общий континуум определений. В TOGAF техническая эталонная модель рекомендуется к использованию, но не являются обязательной. В общем техническая эталонная модель, не лишена недостатков по следующей причине: она направлены на обеспечение переносимости приложений в ущерб их способности к взаимодействию и автономности. Для организаций модель TOGAF в значительной степени сводится к методике разработки архитектуры. В этом смысле компонента Базовой Архитектуры, содержащая набор служб и стандартов, является некоторой абстрактной реализацией ИТ-системы в целом. Архитектура Общих Систем реализуется путем выбора и интеграции определенных служб для формирования выделенных блоков, которые могут (возможно, повторно или в различных комбинациях) использоваться в различных функциональных областях, таких как архитектура безопасности, сетевая архитектура и т. п.

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

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

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

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

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

В состав набора принципов могут входить обоснования для формирования системы требований или критериев оценки тех или иных решений. Например, такой принцип, как «минимизация числа поставщиков программного обеспечения», может быть в дальнейшем конкретизирован в зависимости от особенностей предприятия, как требование «единой СУБД для всех критичных для бизнеса приложений» или же как «использование той же СУБД, что и уже применяемая». Архитектурные принципы могут также использоваться для обоснования значимости самого понятия Архитектуры и необходимости ее разработки для бизнеса предприятия, а также для выбора вариантов реализации этого процесса.

Принципы являются взаимозависимыми и должны применяться в целостном наборе. «Хороший» набор принципов должен удовлетворять таким естественным критериям, как доступность для понимания, точность формулировок, полнота, последовательность и стабильность (не нужно путать с неизменяемостью!) Обычно число принципов не превышает 20, чтобы не ограничивать гибкость архитектуры или чтобы избежать чисто формального определения принципов, которые неработоспособны на практике.

Примеры принципов, используемых при создании архитектуры TOGAF (Название и содержание):

Пример использования — Сформулированные принципы управления ИТ применимы для всех случаев и подразделений организации.

Максимальная польза — Решения в области ИТ принимаются исходя из максимума пользы для организации в целом.

Привлечение всех — Управление информацией есть дело каждого.

Непрерывность бизнеса — Деятельность предприятия должна обеспечиваться, несмотря на возможные помехи в работе ИТ.

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

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

Ответственность ИТ-службы — ИТ-служба является ответственным владельцем ИТ-ресурсов и исполнителем процессов для удовлетворения требований бизнеса.

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

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

Обеспечение качества — Каждый элемент данных должен иметь ответственного за качество.

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

Безопасность данных — Данные должны быть защищены от неавторизованного использования и распространения.

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

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

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

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

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

Процесс Управления Архитектурной Практикой

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

•Люди. Они основа любой деятельности в компании. Если люди не знают, не умеют, не используют, не участвуют, не делают, не хотят, то все остальное бесполезно. Забыли про людей — забудьте про результаты.

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

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

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

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

•залезают в дебри теорий и исследований;

•выполняют бесполезную работу;

•долго готовятся к выполнению работы;

•изобретают велосипед;

•«оптимизируют» свою работу вместо её выполнения;

•излишне теоретизируют;

•ищут ответственных и виноватых;

•считают себя самыми умными;

•избегают неприятной работы.

Подход к управлению архитектурной практикой состоит из шести основных элементов:

Методология — это основной элемент подхода. Он определяет процессы компании для разработки, обновления и реализации Архитектуры Предприятия. Роли и их обязанности.

Артефакты — набор, шаблоны и правила заполнения документов, таблиц, схем, при помощи которых описана Архитектура Предприятия.

Стандарты — это стандарты (законы, правила) ведения бизнеса и ИТ, которые использует компания в своей работе. Это могут быть международные стандарты, российские стандарты, стандарты отрасли, региона, компании.

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

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

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

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

Ключевые документы и шаблоны методологии TOGAF

Для внедрения методологии TOGAF возникает вопрос какой минимальный набор документов необходим для ведения архитектурного проекта? Лишние документы — лишние затраты времени и денег. По исходя из собственного опыта и теории (при подготовке к сертификации), минимальный «джентельменский набор» может состоять из восьми документов:

Основы методологии (Templates, Business Principles, Goals, Drivers). Необходим для понимания миссию, цели, стратегию компании. Зафиксировать бизнес принципы. Шаблон «TOGAF 9 Templates, Business Principles, Goals, Drivers.doc»

Архитектурные принципы (Architecture Principles) — это правила, которыми руководствуются в работе над архитектурой. На их основе принимают архитектурные решения. Принципы нужно сформулировать на основе примеров из TOGAF. Использование принципов при работе над архитектурой доказало свою эффективность. Шаблон — «TOGAF 9 Template Architecture Principles.doc»

Видение архитектуры (Architecture Vision) — это высокоуровневое описание желательного конечного продукта архитектурного проекта. То есть это те результаты, которых нужно достичь. Описание решения тех проблем и задач, ради которых стартуют проект. Этот документ важен для взаимодействия со спонсором проекта и другими заинтересованными лицами. Шаблон — «TOGAF 9 Template Architecture Vision.doc»

Устав проекта (Statement of Architecture Work) — соглашение между спонсором и проектной командой о выполнении работ. В него включают все рамки, ограничения, предположения, сроки, бюджет, правила проекта. В нем конкретно назначают менеджера проекта и прописывают его права и обязанности. Сюда же включают как приложение видение архитектуры как описание рамок проекта. Шаблон — «TOGAF 9 Template Statement of Architecture Work.doc»

Описание архитектуры (Architecture Definition) — это представление текущей и целевой архитектуры. Он охватывает каждый из архитектурных доменов (бизнес, данные, приложения, технологии). А также анализ расхождений между текущим и будущим состоянием. Шаблон — «TOGAF 9 Template Architecture Definition.doc»

Спецификация требований к архитектуре (Architecture Requirements Specification) — документ, в котором собраны все требования, ограничения, предположения, критерии достижения. Шаблон — «TOGAF 9 Template Architecture Requirements Specification.doc»

Переходная архитектура (Transition Architecture) — Реализация целевой архитектуры проходит в несколько этапов. Каждое промежуточное состояние должно быть работоспособно и давать компании большую ценность. В этом документе сгруппированы проекты по каждому из таких этапов. Шаблон — «TOGAF 9 Template Transition Architecture.doc»

План реализации и миграции (Implementation and Migration Plan) — это сводный план реализации проектов, направленных на достижение целевой архитектуры. В него также включают выгоды, рамки, сроки, стоимость, риски, контрольные точки проектов. Шаблон — «TOGAF 9 Template Implementation and Migration Plan.doc»

Такой набор документов можно сделать максимально быстро и без больших затрат. Если предполагается воспользоваться услугами третьих сторон, то рекомендую включить ещё один документ — архитектурный контракт. Это соглашение между архитекторами и исполнителями ИТ проекта. Шаблон — «TOGAF 9 Template — Architecture Contract.doc» При приемке проекта вам будет легче получить нужный результат, если вы о нем заранее договорились.

Подходы к построению ИТ Стратегии

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

Первый шаг — оцениваем текущее состояние Архитектуры Предприятия (Baseline Architecture). Концентрируем внимание на вопросах бизнеса (Business Architecture) и начинаем с общих высокоуровневых вопросов. На данном этапе желательно провести интервью или просто побеседовать с руководством компании, топ менеджерами. Для данной задачи хорошо бы было участие двух специалистов уровня экспертов. Причем один в области управления, консалтинга или аудита, с хорошими аналитическими способностями и пониманием бизнес составляющей (ИТ Директор, Chief Information Officer CIO), а второй, эксперт в области информационных технологий (ИТ Архитектор, Chief Technology Officer CTO). Их главная задача — слушать. Ключевые вопросы, которые помогут удерживать направление беседы в бизнес сфере, сводятся к определению следующих составляющих:

•Основной вид деятельности организации

•Организационная структура

•Особенности ведения бизнеса

•Миссия и видения организации

•Цели и задачи

•Текущие проблемы организации

•Организация и оценка текущего состояние ИТ по мнению руководства

Следующий шаг — формируем видение Целевой Архитектуры Предприятия (Target Architecture). Для этого, задавая наводящие вопросы, пытаемся определить видение руководства, цели бизнеса, ожидания и чаяния. Видение будущего ИТ, его роли, вовлеченность в бизнес и т п. Важный момент данного этапа общения — Не прерывайте их!!! Дайте им высказаться, помечтать. Даже если их фантазии будут время от времени противоречить друг другу, и здравому смыслу. Ваша задача — собрать как можно больше информации. Руководство организации является заказчиком. А как говорится: «… кто музыку заказывает, тот ее и танцует…». Запомните, а затем запишите и проанализируйте всю информацию.

По окончанию первых двух шагов, у нас будет воздушный замок высокоуровневой «Архитектуры Бизнеса» для «Текущей» и «Целевой» Архитектуры Предприятия конкретной организации:

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

Текущая Архитектура

•Архитектура Бизнеса

•Архитектура сегментов

•Информационные Системы

•Техническая Архитектура

План Перехода

•Наброски и идеи

Целевая Архитектура

•Архитектура Бизнеса

•Архитектура сегментов

•Информационные Системы

•Техническая Архитектура

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

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

•корпоративная стратегия (на уровне корпорации, холдинга),

•бизнес-стратегия (на уровне отдельной бизнес-единицы)

•функциональные стратегии (на уровне отдельных функциональных направлений в бизнес-единице).

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

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

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

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

Можно предложить следующие информационные разделы для ИТ-стратегии:

•Цели для ИТ в привязке к бизнес-целям организации.

•Направления развития ИТ для достижения обозначенных целей.

•Проекты, которые должны быть реализованы в рамках каждого направления.

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

•Основные этапы по каждому проекту (краткое описание результатов, сроки, стоимость).

•Набор KPI для мониторинга развития ИТ и достижения соответствующих целей.

•Бюджеты ИТ-проектов, направлений и общий бюджет ИТ.

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

Построении ИТ Архитектуры и ИТ Стратегии в организации можно графически представить в виде диаграммы.

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

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

Для чего необходим департамент ИТ (миссия департамента). Миссия ИТ должна отвечать следующим параметрам:

•Соответствие миссии организации

•Соответствовать внутренним и внешним бизнес требованием организации

•Будет ли актуальна в долгосрочной перспективе

•Стратегия централизации информационных систем (одна для всех задач, различные для разных задач)

•Стратегия централизации данных (функциональный, процессный или приложения)

•Стратегия централизации технологической архитектуры (платформа, резервирование и т п)

Что хотим достигнуть (цели). Основные требования к целям компании:

•Отражать специфику работы ИТ департамента

•Реалистичными

•Измеряемы

Какие пути выбрать для достижения цели (стратегия). Под стратегией можно предполагать «выбор путей для создания конкурентного преимущества и достижения определённых показателей организации на рынке». Можно рассматривать два основных направления ИТ стратегии или их комбинацию:

•Наращивание производства или продаж за счет инноваций в области ИТ

•Сокращение издержек за счет оптимизации и реинжиниринга с привлечением ИТ

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

•Список проектов (операционный план) должен быть утвержден на уровне совета директоров организации

•Выделен необходимый бюджет, ресурсы и возможности

•Для каждого проекта рассчитаны преимущества (финансовые показатели, ROI, выгоды, риски и т п)

•Проводится мониторинг состояния операционного плана (проектов)

Каким образом измерять (ключевые показатели).

Кто реализует (сотрудники или аутсорсинг)

Стратегия Управления

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

Стратегия финансового контроля

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

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

Ориентироваться на использование свободно распространяемого программного обеспечения

Выравнивание по стоимости или функционалу. Например, стоимость аренды каналов связи для разных филиалов банка может отличаться в зависимости от расстояния или географического расположения. Предположим, что стоимость 10 Mbps канала (стандартные и достаточные ИТ требования) для регионального филиала обходится 500 долларов. За туже стоимость городской филиал может получить скорость канала до 100 Mbps. На текущий момент у этого филиала стандартная скорость 10 Mbps, но обходится за 100 долларов в месяц. Средняя стоимость канала связи для всех филиалов порядка 250 долларов. Руководство должно иметь определённую стратегию по данному вопросу: предоставить возможность филиалам наращивать скорость в пределах средней стоимости, максимальной стоимости или выравнивание всех по установленной скорости канала (10 Mbps).

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

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

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

Стратегия Компонентов ИТ Архитектуры

Стратегия выбора платформа решения

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

«On-premises» — ИТ активы физически располагаются на территории организации.

Преимущества:

•ИТ инфраструктура располагается на территории организации и контролируются ИТ сотрудниками организации.

•Относительно низкой стоимостью сопровождения (OPEX) ИТ инфраструктуры.

•Автономность решений и более высокий уровень безопасности

Недостатки:

•Относительно высокие первоначальные вложения (CAPEX) в ИТ инфраструктуру.

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

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

•Косвенные расходы на инженерные системы ИТ инфраструктуры.

«Cloud based» — ИТ активы располагаются в «облаке».

Преимущества:

•Относительно низкие первоначальные вложения (CAPEX) в ИТ инфраструктуру.

•Высокий уровень планирования расходов на сопровождение ИТ инфраструктуры.

•Хорошая связь, линейная зависимость используемых ресурсов и их стоимости.

•Простота внедрения новых решений и расширения имеющихся ИТ сервисов.

•Нет необходимости в дополнительных сотрудниках.

•Нет необходимости в косвенных расходах на системы инженерные.

Недостатки:

•Относительно высокая стоимость сопровождения (OPEX) ИТ инфраструктуры.

•Более высокие требования к каналам связи интернета и наличию резервных каналов.

«Hybrid» — комбинированное решения. Используются преимущества двух первых решений.

Преймущества:

•Использует достоинства обоих решений.

Недостатки:

•Более высокая стоимость внедрения (CAPEX) и сопровождения (OPEX)

Рекомендации по выбору:

Для начальных проектов, небольших организаций, организаций с развитой географией и т п предпочтительно использование «Cloud based» решения. Для крепкой организации, финансовых институтов, организаций где выход в интернет не является требованием бизнеса и т п предпочтительно использование «On-premises» решения. «Hybrid» решения могут как дополнять ИТ инфраструктуру, так и заменять часть компонентов ИТ архитектуры.

Стратегия выбора платформа развертывания

В качестве платформы для развертывания инфраструктуры, при условии, что выбрано «On-premises» решение, могут быть рассмотрены следующие варианты:

«Физические сервера» — ИТ сервисы располагаются на физических серверах.

Преимущества:

•Относительно низкой стоимостью внедрения (CAPEX) ИТ сервисов для малых решений.

•Ресурсы физического сервера полностью выделены по задачи конкретного сервиса.

Недостатки:

•Сложность сопровождения, с ростом инфраструктуры.

•Скорость развёртывания и восстановления.

•Не оптимальное использование вычислительных ресурсов.

«Платформа виртуализации» — ИТ сервисы располагаются на платформе виртуализации в виде виртуальных машин.

Преимущества:

•Относительно низкая стоимость сопровождения (OPEX) в ИТ инфраструктуру.

•Фактически является «де-факто» стандартов развертывания «On-premises» решений.

Недостатки:

•Относительно высокая стоимость внедрения (CAPEX) ИТ инфраструктуры.

Рекомендации по выбору:

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

Стратегия выбора аппаратного и программного обеспечения

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

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

Преимущества:

•Внедрение стандартов ИТ активов упрощает процесс обеспечения сотрудников организации ИТ активами.

•Облегчает внедрение и сопровождение ИТ инфраструктуры

•Повышает уровень информационной безопасности организации.

Недостатки:

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

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

Преимущества:

•Относительно низкая стоимость и быстрота приобретения ИТ активов.

Недостатки:

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

•Усложняет внедрение и сопровождение ИТ инфраструктуры

•Снижает уровень информационной безопасности организации.

Рекомендации по выбору:

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

Стратегия лицензирования

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

Использование лицензионного соглашения уровня «Предприятия» с ежегодным продлением возможности обновления программного обеспечения. Лицензирование является непрерывным процессом в ИТ.

Преимущества:

•Большая степень свободы в вопросах лицензирования.

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

•Обновление систем происходит плавно, без всплесков требований в ИТ ресурсах, людях и времени

Недостатки:

•Относительно высокая стоимость.

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

Преимущества:

•Относительно дешевле по стоимости

Недостатки:

•Меньшая степень свободы в вопросах лицензирования.

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

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

Рекомендации по выбору:

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

Стратегия построения инженерных систем

Для «On premise» и «Hybrid» решений требуется определится с требованиями к инженерным системам.

К требованиям по инженерным системам можно отнести:

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

•Требования к Структурированной Кабельной Системе (избыточность, резервирование и т п)

Стратегия тестирования

Тестирование один из важных элементов при построении ИТ архитектуры. Уже на этапе проектирования ИТ архитектуры требуется определить вопросы по тестированию. Различают следующие площадки:

•«Test или Development» — площадка с развернутыми отдельными ИТ сервисами. Используется для разработки сервисов или отладка элементов ИТ сервиса.

•«Pre-production» — уменьшенная копия «Production» площадки со всеми компонентами ИТ архитектуры. Используется для отработки взаимодействия ИТ сервисов между собой. Так же позволяет эмулировать ситуации при поиске неисправностей, расчет производительности и т п.

•«Production» — площадка с развернутым вычислительными ресурсами предоставляющие ИТ сервисы.

Рекомендации по выбору:

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

Стратегия уровня избыточности

Определение уровня избыточности компонентов ИТ инфраструктуры указывает требования к дублированию компонентов. Может рассматриваться на уровне:

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

•Каналы и кабели связи (два и более проходящие по разным шахтам),

•Избыточное количество рабочих точек (обеспечивает рост организации и резерв на отказ)

Компонентов устройства (сервера, коммутатора и т п). Резервирование (дублирование) на уровне критически важных элементов устройства, таких как:

•Процессоры (два и более процессоров),

•память (две и более «банки» памяти),

•жесткие диски (два диска в RAID1 массиве + один резервный)

•сетевые карты и адаптеры (две карты с одним и более портами)

•блоки питания (N+N или N+1)

Компонентов ИТ сервиса. Резервирование на уровне устройств и типу их включения. Как пример:

•Два сервера в отказоустойчивом кластере

•Два сервера выполняющих одну и туже роль (два контролера домена)

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

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

Географически разнесенные устройства на уровне сайтов. Расположение пары устройств на разных сайтах.

Определение уровня резервирования зависит от критичности бизнеса к отказу или простою. Анализируется в процессе Управления Рисками, формализуется в документах по стандартах оборудования.

Стратегия по системам резервирования и архивирования

К системам резервирования и архивирования ИТ инфраструктуры можно определить следующие требования:

•Компоненты систем должны быть установлены на выделенных физических элементах (серверах, СХД и т п)

•Возможно совмещение систем резервирования и архивирования на одних компонентах.

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

Требования к резервным сайтам

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

•Отказоустойчивость на уровне отдельных компонентов ИТ сервиса

•Отказоустойчивость на уровне дублирования компонентов ИТ сервиса

•Отказоустойчивость в пределах сайта

•Отказоустойчивость с географически распределённым сайтом

Различают следующие категории специализированных резервных площадок:

•«Горячий» — готовность в течении секунд/минут/часов

•«Теплый» — готовность в течении часов/дней (порядка 48 часов)

•«Холодный» — готовность в течении дней/не полное восстановление

Не специализированные площадки — использование имеющуюся площади организации (филиал и т п)

Подходы по внедрению Архитектуры Предприятия

При разработке архитектуры вашей компании необязательно начинать с разработки стратегической архитектуры. Безусловно, подход «Сверху — Вниз» (Стратегическая архитектура — > Архитектура сегмента — > Архитектура решений) самый распространенный и имеет множество преимуществ:

•Будет понятен общий вектор развития организации.

•На уровне сегментов и решений будет меньше разброда и шатаний.

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

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

Основная идея движение от «общего к конкретному» (Generic- to — specific), а также непрерывное совершенствование ИТ архитектуры на основе требований бизнеса. Но вы можете использовать и другие подходы:

«Снизу — Вверх» (Архитектура решений — > Архитектура сегмента — > Стратегическая архитектура). От архитектуры конкретных проектных решений к стратегической архитектуре. Компания начинает с архитектуры решения. До старта проекта решение прорабатывается и описывается. Затем — более высокие уровни Архитектуры Предприятия. Этот метод позволяет быстро получить ценность от методов Архитектуры Предприятия. Но есть вероятность, что без стратегической архитектуры, как основы, архитектуры различных решений «разъедутся». Придется потратить время и ресурсы на приведение их к общему знаменателю.

«От Сегмента» (Архитектура Сегмента — > Архитектура решений и стратегическая архитектура) Когда компании важно решить проблемы в конкретном подразделении, запустить новое направление бизнеса, либо если компания не готова к крупномасштабным внедрениям Архитектуры Предприятия и хочет «потренироваться на кошечках». Обкатать идеи на одном подразделении или направлении бизнеса. В зависимости от целей и сроков их достижения вам нужно выбрать подход для вашей компании.

Информационные системы вашей компании возможно далеки от идеала. Но выбросить их и переделать будет стоить очень дорого и займет много времени. Ценность такой инициативы сильно ниже нуля. Опытный архитектор «полечит» проблемы с интеграцией, информационной безопасностью, инфраструктурой, заплатками, а саму систему заставит давать большую ценность вашей компании. Реализация будет идти небольшими, точно выверенными доработками. Он будет решать конкретные проблемы, а не «делать все по уму». Замена системы — это серьезное изменение для компании, и для него должны быть веские аргументы.

Следующий важный вопрос при внедрении проекта построения Архитектуры Предприятия: Стоит ли привлекать консультантов или делать все самим (MAKE or BUY)? Однозначного ответа на него нет. Все зависит от конкретной организации, целей и возможностей. Для примера, представим ситуацию:

Мы заключаем контракт с уважаемой компанией «СУПЕР ПУПЕР КОНСУЛЬТАНТЫ и Ко». Через несколько месяцев получаем набор документов под названием «Архитектура компании БАНАНАС и Ко», в котором расписана правильная система, множество схем, описаний и т п. Так сказать решение «под ключ». Заманчиво? Да скорее всего дорого, но быстро, профессионально, не один «комар» (читаем «аудитор») носу не подточит. Возможно.

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

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

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

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

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

Я бы рекомендовал привлечение внешних консультантов, но не отдавал бы архитектурную работу внешним исполнителям на 100%. В компании должны оставаться не только результаты проектов, но и люди, знания и опыт. Поэтому большую часть работы должны выполнять сотрудники вашей организации. Но под присмотром эксперта и с его помощью. Обязательно в проект внедрения должны быть включены ресурсы по обучению сотрудников. Как гласит народная мудрость «практика без теории слепа, теория без практики мертва».

Инструменты внедрения Архитектуры Предприятия

Как и какие выбрать инструменты для разработки Архитектуры Предприятия. На рынке представлены десятки инструментов. От бесплатных до дорогих. Внедрение некоторых из них может стоить сотни тысяч долларов. Я рекомендую использовать по возможности бесплатные или дешевые инструменты (если не имеются в наличие) по следующим причинам:

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

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

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

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

Какие минимальные требования к инструментам? Что они должны помогать вам делать?

•Писать и редактировать тексты, составлять схемы, вести таблицы, делать презентации и т. д.

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

Набор инструментов:

•Для составления документов, схем, таблиц и презентаций можно использовать стандартный офисный пакет, например, MS Office. Для него есть готовые шаблоны для документов. Есть расширения для Visio, при помощи которых можно нарисовать все нужные схемы.

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

Рекомендации по внедрению

На основе требований и ограничений, определённых выше, можно суммировать основной подход при построении ИТ архитектуры компании:

•Сервис ориентированный подход к построению ИТ архитектуры

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

•Снижение расходов за счет максимального и оптимального использования текущих ИТ активов и решений

•Снижение сложности и разнородности имеющейся инфраструктуры

•Максимально возможный рациональный подход к консолидации ИТ активов (железо, программное обеспечение), оставляя на периферии уровень поддержки пользователей и/или специализированных систем

•Множественное использование ИТ активов (ИТ персонал) на проектах внутри компании

•Стандартизация ИТ активов (железо, программное обеспечение и решения) для снижения стоимости владения, сложности сопровождения и повышения информационной безопасности

•Введение единых ИТ политик и процедур в компании для снижения стоимости владения, сложности сопровождения и повышения информационной безопасности

•Автоматизация рутинных ИТ процессов для снижения стоимости владения, сложности сопровождения и повышения информационной безопасности

•Формирование единой политики информационной безопасности в организации

•Формирование проектной команды с высоким уровнем компетенции

Совместимость

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

Следование основным принципам

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

Заключение

В заключение можно сказать, что построение Архитектуры Предприятия один из важнейших аспектов построения эффективного механизма корпоративного управления с интеграцией информационных технологий для получения наилучших результатов. Интегрирование механизмов Управления ИТ сервисами (ITSM), систему Управления Проектами (PMM) методов аудита и контроля (COBIT) позволит бизнесу добиться исключительных результатов и максимальной отдачи от ИТ.

Концепция Управления Проектами

Общие Положения

Управление проектом рассматривается как метод и набор процедур, основанных на принятых принципах управления, которые используются для планирования, оценки и контроля рабочих заданий, с целью получить желаемый конечный результат в установленные сроки, в рамках выделенных средств и в соответствии с требованиями к проекту. Данный раздел содержит основные принципы управления проектами, которые должны быть приняты во внимание при построении ИТ Архитектуры Предприятия. Любые проекты, в которые вовлечены ИТ (влияют на ИТ или зависят от ИТ), рассматриваются как ИТ проекты. В процессе планирования, разработки и внедрения различных сервисов ИТ архитектуры необходимо руководствоваться принципами «проектного» подхода.

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

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

Признаки проекта:

•Есть конкретная дата начала. Ключевой признак проекта «временная составляющая», т. е. есть начало и конец проекта.

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

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

•Ресурсы и бюджет — ограничены.

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

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

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

Ключевые аспекты Управления Проектами

Тройственная ограниченность или Треугольник проекта — описывает баланс между содержанием (объем работ или scope), стоимостью (cost) и временем (time, schedule) проекта, что влияет на конечный результат — качество (quality). Качество — это четвертый элемент проектного треугольника, который находится в центре, и любое изменение сторон влияет на него.

Как говорится в популярном слогане «Сделаем хорошо, быстро, дешево. Нужное подчеркните».

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

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

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

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

Идея всех методик и подходов сводится к фокусированию внимания на одном или нескольких факторах с контролем воздействия на оставшиеся.

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

Цель руководителя проекта — достижения критериев успешности проекта.

Основная задача руководителя проекта — соблюдение баланса треугольника проекта.

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

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

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

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

Классификация по приоритету, позволяет определить порядок выполнения проектов:

•Низкий,

•Средний

•Высокий.

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

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

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

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

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

•Бизнес подразделения

•ИТ департамент.

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

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

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

•Задает направление работ по реализации проекта.

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

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

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

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

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

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

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

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

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

Подходы и методы управления проектами

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

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

Процессно-ориентированное проектное управление (Process Based Project Management PBPM)

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

Классическая Методология Управления Проектами «ВОДОПАД» (WATERFLOW)

«ВОДОПАД» (WATERFLOW) — Традиционная, классическая методология управления проектом. Она также носит название «каскадной» или «поточной» модели, вследствие того, что предлагаемая ею последовательность фаз напоминает водопад. Наиболее очевидный способ сделать свой проект более управляемым — это разбить его процессы реализации на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. Данный подход не предполагает возврата к предыдущим этапам по их завершению и принятию, или внесение изменений в требования проекта. Данная методология управления проектами предполагает разбиение проекта на ряд последовательных задач, с четким определением целей и сроков. Члены проекта выполняют задания в установленном порядке, завершая каждое задание перед тем, как преступать к последующему. В «водопадной» модели, в применении к ИТ проектам разработки программного обеспечения, стадии идут в следующем порядке:

•Определение требований

•Проектирование

•Конструирование («реализация» или «кодирование»)

•Интеграция

•Тестирование и отладка («верификация»)

•Инсталляция

•Поддержка

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

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

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

Гибкая Методология Управления Проектами (Agile Project Management Methodology)

AGILE — семейство процессов и методов разработки гибких методов управления и ведения проектов. Сам по себе Agile — скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют — фреймворк (frameworks). Примеры: Scrum, Kanban, Crystal, LeSS, SAFe, Nexus и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам. Гибкие методы предполагают изменения требований к продукту в течении всего времени проекта. Такое проектирование подразумевает совершенно иной подход к управлению проектами. Изначально методология разрабатывалась для проектов, которым требуются высокая гибкость и быстрая реализация. Гибкое управление проектом представляет собой поступательную и итеративную проектную методологию. Ее главной особенностью является то, что в начале выполнения проекта точно неизвестно, каким должен быть конечный продукт и каким будет жизненный цикл проекта. Вместо этого, проектная деятельность разбивается на несколько итеративных фаз — короткие циклы, называемые «спринтами». Каждый спринт состоит из множества задач и имеет свой конечный продукт и результат. Методология Agile позволяет менеджерам проектов постоянно получать обратную связь и улучшать продукт после каждой итерации. В соответствии с данной методологией управления проектами, ответственность за результат делится между тремя ролями:

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

•Scrum мастер — устанавливает приоритеты в выполнении задач командой проекта и устраняет возникающие затруднения, препятствующие этому

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

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

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

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

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

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

Метод SCRUM семейства Гибких Методов Управления Проектами

SCRUM — («схватка») классический метод, с описанием процессов планирования, контроля и анализа на всех этапах ведения проекта, базирующийся на идеях Agile. Методология реализации agile-разработки предполагает использование интерактивного подхода. «Скрам-сессии», или «30-дневные спринты», используются для определения приоритетных задач. Роль менеджера проекта для упрощения передается скрам-мастеру. Для независимого решения конкретных задач формируются небольшие команды. В ходе встреч со скрам-мастером оцениваются достигнутые результаты, после чего определяется приоритетность невыполненных задач. Основная особенность методики:

•Совещания и анализ по определённым отрезкам времени «спринтов» (sprints).

•Небольшая команда

•Ограничение по определенным промежуткам времени (sprint) для выполнения WIPs.

•Определённых «кусок» продукта (Work in Process WIPs)

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов («W» — product backlog). Затем владельцем продукта — представителем заказчика в команде определяются приоритеты этих частей. Самые важные «кусочки» первыми отбираются для выполнения в спринте — так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце спринта заказчику представляется рабочий инкремент продукта — те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему спринту. Длительность у спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям заказчика, которые имеют свойство изменяться со временем, перед началом каждого спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все — команда проекта, лидер команды проекта (Scrum Master) и владелец продукта. И ответственность за этот процесс лежит на всех. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки — выполнены. Основная структура процессов Scrum вращается вокруг 5 основных встреч:

•упорядочивания заделов (backlog),

•планирования Спринта,

•ежедневных летучек

•подведения итогов Спринта

•ретроспективы Спринта.

Встреча по упорядочиванию заделов (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается — что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него зависит, какую ценность получит Заказчик по итогам спринта.

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

Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений — если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.

Подведение итогов Спринта: Цель этапа — обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача — убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.

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

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

Слабые стороны — очень требователен к команде проекта. Она должна быть небольшой (5–9 человек) и кросс-функциональной — то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например, разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга. Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь само-организовываться.

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

Метод KANBAN семейства Гибких Методов Управления Проектами

KANBAN — также представляет из себя гибкий, итеративно-инкрементальный подход к управлению проектами базирующийся на идеях Agile. Является противоположностью «SCRUM» метода. Основные особенности методики:

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

•Работа вносится в карточку (Sticker)

•Количество «незавершённой» работы (WIPs) ограничено для каждой стадии

•Новая работа берется только тогда, когда существующая выполнена или «вытянута» (LEAN).

•Больше внимания к управлению изменениями, визуализация узким мест, незавершенной работы и т п

•Ограничения по количеству WIPs и их статусы

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

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

Для работы с Kanban необходимо определить этапы потока операций (workflow). В Kanban они изображаются как столбцы, а задачи обозначают специальные карточки. Карточка перемещается по этапам, подобно детали на заводе, переходящей от станка к станку, и на каждом этапе процент завершения становится выше. На выходе мы получаем готовый к поставке заказчику элемент продукта. Доска со столбцами и карточками может быть, как настоящей, так и электронной — даже здесь Kanban не накладывает никаких ограничений на пользователей. Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете — ведь во многом Kanban является визуализацией идеи Agile.

Но у Kanban есть четыре столпа, на которых держится вся система:

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

•Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.

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

•Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

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

Слабые стороны — Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких сроков. Для жёстких сроков проекта лучше подходит классический подход или Scrum.

Гибридная Методология Управления Проектами

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

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

Методология Быстрой Разработки Приложений (Rapid Application Development RAD)

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

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

•Планирование

•Пользовательское проектирование

•Быстрое конструирование

•Переключение

Основные преимущества применения различных подходов RAD:

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

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

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

Методология Экстремального Программирование (Extreme Programming XP)

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

Методология моделирования событий Event Chain Methodology (ECM)

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

Метод Адаптивные Рамки Проектов APF (Adaptive Project Framework)

Использование адаптивных/регулируемых рамок проектов APF (Adaptive Project Framework) позволяет улучшать проект на каждом этапе, основываясь на полученном опыте от предыдущих результатов. Определив цели проекта и постоянно контролируя работы проекта, менеджер может обеспечить успех максимально возможной стоимости бизнеса и создать бизнес-ценность для потенциального потребителя.

Метод «Реализация Выгоды» (Benefit Realization BF)

Цель метода «Реализация Выгоды» (Benefit Realization BF) — выгода от реализации проекта Успех определяется как достижение желаемой/ожидаемой выгоды. Если клиенты хотят увеличить продажи CRM (система управления взаимоотношениями с клиентами — customer relationship management software), проект не будет выполнен/реализован до того момента, пока продажи не повысятся на 15% — даже если Вы установили и наладили работу CRM вовремя и с соблюдением/в соответствии с бюджетом.

Методология PRISM (проекты со встроенными устойчивыми/жизнеспособными методами)

Сочетание проектного планирования с экологической устойчивостью мер. Хотите пойти в «зеленом» направлении? В таком случае, PRISM точно для Вас! Сокращение расходования энергии и издержек обращения (распределение затрат), все это при одновременном снижении Вашего воздействия на окружающую среду.

ПРОЧИЕ МЕТОДЫ И СПЕЦИФИЧЕСКИЕ ПОДХОДЫ К УПРАВЛЕНИЮ ПРОЕКТАМИ

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

•функционально-ориентированная разработка (feature driven development, FDD),

•разработка динамических систем (dynamic systems development, DSDM),

•адаптивная разработка программного обеспечения, Rational Unified Process (RUP),

•Концепции Шесть сигм (six sigma) и Бережливого Производства (LEAN). Управление проектом на основе принципов «контроля качества». Будут детально рассмотрены в следующей главе.

Методология Управления Проектами в Контролируемой Среде (PRINCE2)

PRINCE2 (Projects in Controlled Environments PRINCE2) так же является структурированной методологией к проектному управлению. Это одна из самых популярных методологий управления проектами, широко используемая в Великобритании в управлении как в бизнесе, так в органах власти. PRINCE2 — это процессно-ориентированная проектная методология (PBPM), которая фокусируется на процессах верхнего уровня (управление, организация, контроль), а не на низших задачах (декомпозиция работ, разработка графиков).

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

Принципы методологии PRINCE2

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

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

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

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

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

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

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

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

Темы методологии управления проектами PRINCE 2

Обоснование проекта: какую ценность проект принесёт организации?

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

Качество: какие имеются требования и критерии к качеству и каким образом можно их обеспечить

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

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

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

Прогресс: реализуемость проекта, выполнение планов и дальнейшее развитие проекта

Семь процессов управления PRINCE 2

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

•запуск проекта

•руководство проектом

•инициация проекта

•контроль этапов

•управление созданием продукта

•управление границами этапов

•закрытие проекта

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

Сильные стороны PRINCE2:

•Адаптируемость к особенностям организации;

•Наличие чёткого описания ролей и распределения ответственности;

•Акцент на продуктах проекта;

•Определённые уровни управления;

•Фокус на экономической целесообразности;

•Последовательность проектной работы;

•Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2 — Отсутствие или нехватка отраслевых практик и отсутствие конкретных инструментов для работы.

Управление проектами на основе методологии «PROJECT MANAGEMENT INSTITUTE PMI»

Общие положения

Данная методология является представителем Процессно-ориентированное подходом у Управлению Проектами (Process-Based Project Management PBPM) и основывается на методологии традиционного, классического подхода к управлению проектами. Наиболее очевидный способ сделать свой проект более управляемым — это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. Все процессы в руководстве PMBooK разделяются на следующие группы (фазы):

Группа процессов инициации проекта (Initiating)

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

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

•Разработка Устава проекта (Develop Project Charter)

•Определение заинтересованных сторон (Identity Stakeholders)

Группа процессов планирования проекта (Planning)

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

•Задача четко определяет, что должно быть сделано для достижения целей

•Задача является событием, срок окончания которого можно определить.

Метод «SMART» помогает сформулировать цели и задачи проекта как:

•Specific — Быть точным при постановке цели

•Measurable — Установить измеримые показатели состояния

•Assignable — Иметь возможность поручить выполнение задания кому-нибудь

•Realistic — Определить, могут ли быть реально выполнены в срок и в рамках выделенных ресурсов

•Time related — Определить временные рамки, т. е. продолжительность ее выполнения

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

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

•финансовые ресурсы (как прямые необходимые для реализации проекта, так и на управление проектом)

•людские ресурсы (кто, когда, как и на какой срок участвует в проекте)

•материальные ресурсы (имеющиеся в наличие, требуемые и т п)

•административные ресурсы (полномочия, организация)

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

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

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

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

Документ, содержащий обзор проекта, составлен, проанализирован с участием экспертов, а затем подан на рассмотрение высшего руководства организации. Следующий важный аспект управления проектом является процесс разбиения проекта на составные части, результатом которого является схема разбиения на рабочие задания (СРРЗ). СРРЗ — это иерархическое представление проекта. С помощью этой схемы руководитель проекта определяет задания, которые требуется выполнить, чтобы начать и закончить проект. На этом этапе у руководителя есть цель и ряд задач, которые необходимо выразить через задания и работы, подлежащие выполнению. Четко определенное задание имеет следующие характеристики:

•Его состояние и срок завершения легко определить, оно имеет четко определенное начало и конец

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

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

•Как правило, составляет одну непрерывную последовательность работ.

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

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

•использованием различного оборудования

•доступностью материалов

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

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

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

•Рабочая сила

•Материалы

•Другие прямые затраты (командировки, телефон, услуги по контрактам)

•Косвенные затраты (накладные расходы)

Далее необходимо определить последовательность выполнения заданий по проекту. Для простых проектов можно выполнять задания по одному по порядку. Другой путь — провести анализ всех заданий и определить, какие из них необходимо завершить до начала выполнения других. Такой анализ позволяет выявить порядок, в котором можно одновременно выполнять несколько заданий Методом критического пути (МКП) определяет последовательность одновременно выполняемых заданий, который позволяет завершить проект в установленные сроки. Выявление критических заданий, определение критического пути и построение диаграмма приоритетов — представить проект в графическом виде. Для этого необходимо освоить несколько простых правил построения схем проектов. Задание является основной «единицей анализа» в упорядоченной схеме. Задания представляются на схеме в виде прямоугольников, называемых «узлами заданий». Символы, изображенные в прямоугольнике, описывают временные свойства задания. Некоторые из них описывают характеристики самого задания (например, номер задания), тогда как другие представляют собой расчетные величины (ES, EF, LS, LF), связанные с заданием. Время выполнения проекта — это самый длинный временной путь на схеме. Последовательность заданий, составляющая самый длинный путь, называется критическим путем. До тех пор, пока задания, находящиеся на критическом пути, выполняются в срок, проект идет по графику. Определим теперь четыре расчетных параметра (ES, LS, EF, LF), связанные с каждым узлом задания. Следующие расчетные величины будут использованы для определения времени выполнения проекта и критического пути:

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

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

Самое позднее время начала (LS) и самое позднее время окончания (LF) задания — это самые поздние моменты времени, когда можно начать (LS) или закончить (LF) задание, не увеличивая время выполнения проекта в целом.

Чтобы рассчитать эти моменты, будем двигаться по схеме назад. Сначала примем время LF для последнего задания на схеме в качестве времени EF рассматриваемого задания. Время LS для данного задания равно его времени LF минус предполагаемое время выполнения этого задания. Время LF для всех непосредственно предшествующих заданий является минимальным из времен LS для всех заданий, для которых рассматриваемое задание является предшествующим. Необходимо рассчитать еще одну величину, называемую резервом времени для задания.

Резерв времени — это допустимая величина задержки начала или окончания задания, которая не приводит к задержке выполнения проекта в целом. Резерв времени математически представляет собой разность LS — ES (или LF — EF, что-то же самое). По определению, последовательность заданий, имеющая нулевой резерв, является критический путь.

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

•изложение возникшей проблемы, принимаемого общего подхода к ее решению и ожидаемых в результате выгод;

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

•такое подробное описание необходимо администрации, чтобы решить, следует ли перейти к этапам реализации проекта

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

•справочную документацию для административного контроля;

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

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

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

•Название проекта

•Цели проекта

•Руководитель проекта

•Владелец проекта или заинтересованные лица

•Состав рабочей группы

•Задания — Этот раздел состоит из трех подразделов: номер задания, краткое, но смысловое имя, присвоенное заданию и описание задания. В нем должно содержаться в (точных выражениях) конкретное изложение содержания работы, которую необходимо выполнить.

•Оценочные даты начала и завершения работ.

•График выполнения проекта

•Смета проекта — Информация о смете в этом отчете обобщается на уровне задания.

•Метрики и критерии достижения целей

•Дополнительные условия

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

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

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

•Разработка плана управления проектом (Develop Project Management Plan)

•План управления содержанием (Plan Scope Management)

•Сбор требований (Collect Requirements)

•Определение содержания (Define Scope)

•Создание иерархической структуры работ — ИСР (Create Work Breakdown Structure — WBS)

•Разработка плана управления расписанием (Develop Schedule Management Plan)

•Определение операций (Define Activities)

•Определение последовательности операций (Sequence Activities)

•Оценка ресурсов операций (Estimate Activity Resources)

•Оценка длительности операций (Estimate Activity Durations)

•Разработка расписания (Develop Schedule)

•Разработка плана управления стоимостью (Develop Cost Management Plan)

•Оценка стоимости (Estimate Costs)

•Определение бюджета (Determine Budget)

•Планирование качества (Plan Quality)

•Разработка плана управления человеческими ресурсами (Develop Human Resource Plan)

•Планирование коммуникаций (Plan Communications)

•Планирование управления рисками (Plan Risk Management)

•Идентификация рисков (Identify Risks)

•Качественный анализ рисков (Perform Qualitative Risk Analysis)

•Количественный анализ рисков (Perform Quantitative Risk Analysis)

•Планирование реагирования на риски (Plan Risk Responses)

•Планирование закупок (Plan Procurements)

•Разработка плана управления заинтересованными сторонами (Develop Stakeholder Management Plan)

Группа процессов реализации проекта (Executing)

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

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

•Образование и опыт

•Лидерство и стратегическое мышление

•Техническая компетентность

•Умение работать с людьми

•Доказанные способности к управлению

Выбор рабочей группы зависит от ряда факторов:

•от задачи и целей проекта

•от характера работы, которая должна быть сделана

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

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

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

Этап формирования — члены рабочей группы знакомятся друг с другом, «ломается лед» и налаживаются отношения.

Этап привыкания — На этапе привыкания конфликт естественен и неизбежен. Члены рабочей группы проверяют друг друга, появляется чувство границ и устанавливается доверие между ними.

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

Этап выполнения — Рабочая группа готова к реализации проекта.

Этап роспуска — Это этап окончания проекта или задачи, на котором рабочая группа распускается

Ре-интеграция участника проекта — процесс ввода/вывода участника проекта в/из проекта. Руководитель проекта осуществляет подготовку к ре-интеграции сотрудников после завершения проекта (проводит личные собеседования с персоналом и их линейным руководством). Задачи руководитель проекта:

•осуществлять контроль развития членов своей команды,

•обучение участников проекта,

•предоставление проектных инструкций, документацию

•ре-интеграцию новых или вернувшихся членов команды.

•По окончанию проекта, осуществлять возврат участников проекта в свои подразделения или к линейному руководителю.

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

В группу процессов исполнения входят следующие процессы:

•Руководство и управление исполнением проекта (Direct and Manage Project Execution)

•Обеспечение качества (Perform Quality Assurance)

•Набор команды проекта (Acquire Project Team)

•Развитие команды проекта (Develop Project Team)

•Управление командой проекта (Manage Project Team)

•Управление коммуникациями (Manage Communications)

•Осуществление закупок (Conduct Procurements)

•Управление вовлеченностью заинтересованных сторон (Manage Stakeholder Engagement)

Группа процессов мониторинга и управления проектом (Monitoring & Controlling)

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

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

Мониторинг — является неотъемлемой частью и прозрачно участвует на всех этапах управления проектом. Основная задача данной фазы по проекту — проведение мониторинга состояния по выбранным метрикам на соответствие требованиям заказчика и заинтересованных сторон. Выявленные недостатки продукта устраняются на фазе выполнения проекта.

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

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

Подготовка

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

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

•Выбрать время и место проведения совещания, которые удовлетворяют требованиям участников.

•Подготовить повестку дня и довести ее до сведения участников до начала совещания.

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

Проведение:

•Начать вовремя.

•Поручить кому-нибудь вести протокол заседания.

•Рассмотреть повестку дня с каждым из участников до окончания совещания

•Представить участников друг другу.

•Придерживаться повестки дня. Не отклоняться от темы.

•Поблагодарить всех выступавших на совещании.

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

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

•Объем работ, качество — все ли разрабатывается в соответствии с планом работ, не упущено ли что-нибудь.

•Сроки — соблюдаются ли сроки проекта, вез, задач

•Деньги — соблюдается ли запланированный бюджет, отток, приток капитала

Алгоритм работы проектного контроля:

•Установить плановые показатели

•Получить статус проекта, текущие показатели

•Сравнить план с фактом

•Установить отклонение, тенденции и степень влияния на цели проекта

•Изменить план и/или назначить меры для устранения помех ведущих к отставанию по плану.

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

•Отслеживание состояния проекта

•Обнаружение отклонений от плана

•Принятие корректирующих мер

Различают два вида контроля:

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

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

Для любого проекта характерны отклонения от плана. При этом отклонения могут быть двух типов:

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

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

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

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

•Мониторинг и управление работами проекта (Monitor and Control Project Work)

•Общее управление изменениями\Общий контроль изменений (Perform Integrated Change Control)

•Подтверждение содержания (Validate Scope)

•Контроль содержания\Управление содержанием (Control Scope)

•Контроль расписания\Управление расписанием (Control Schedule)

Контроль стоимости\Управление стоимостью (Control Costs)

Процесс контроля качества (Perform Quality Control)

Мониторинг и контроль коммуникаций (Monitor and Control Communications)

•Мониторинг и контроль рисков (Monitor and Control Risks)

•Контроль закупок\контрактов (Control Procurement)

•Контроль вовлеченности заинтересованных сторон (Control Stakeholder Engagement)

Группа завершающих процессов управления проектом (Closing)

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

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

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

•приемка работы по проекту и конечных продуктов заказчиком;

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

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

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

•прекращение всех работ по проекту как внутри организации, так и за ее пределами.

Существуют следующие три типа окончания проекта:

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

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

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

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

•приемка конечного продукта заказчиком,

•документирование проекта,

•проведение проверки после реализации проекта

•выпуск окончательного отчета

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

•Согласуется ли все еще проект с поставленными целями?

•Является ли он практичным? Полезным?

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

•Имеет ли организация достаточно финансовых средств для реализации проекта?

•Является ли поддержка данного проекта достаточной для его успешной реализации?

•Имеет ли организация требуемую квалификацию для реализации проекта?

•Лишился ли проект ключевой фигуры или поддержки?

•Заинтересована ли рабочая группа в успехе проекта?

•Какова вероятность достижения минимума поставленных целей проекта?

•Является ли он все еще прибыльным и своевременным?

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

Группа завершающих процессов содержит следующие процессы:

•Закрытие проекта или фазы (Close Project or Phase)

•Закрытие контрактов (Close Procurement)

Завершение может состоять из:

•Тестов разработанной системы (протокол тестирования)

•Процедура сдачи-приемки, передача рабочей документации

•Аттестация персонала, извлечение уроков (Lesson Learning), обмен опытом

•Финансовый расчет и анализ фактических расходов

•Ликвидация рабочих мест и ре-интеграция персонала

Область знаний по управлению проектами (PMBooK)

Руководство PMBooK (Project Management Body of Knowledge) описывает десять областей знаний, которыми должен обладать руководитель проекта. В стандарте рассматривается каждая область знаний в отдельности, описываются её процессы входов и выходов. Процессы областей знаний представлены в PMBooK в виде дискретных элементов, которые имеют четко определенные границы. Правда на практике эти процессы являются итеративными — могут взаимодействовать между собой и накладываться друг на друга. Стандарт рассматривает следующие области знаний по управлению проектами:

Управление интеграцией проекта (Project Integration Management)

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

Управление содержанием проекта (Project Scope Management)

Под управлением содержанием понимаются процессы, позволяющие производить выборку, фильтрацию и группировку по проекту тех и только тех работ, которые понадобятся руководителю проекта для успешного завершения проекта. Управление содержанием проекта напрямую связано с определением и контролем того (содержания), что будет включено и что не будет включено в проект. Описываются схемы процессов Сбора требований, Определения содержания проекта, создания Иерархической структуры работ — ИСР (Work Breakdown Structure, WBS), Подтверждения содержания и Управления содержанием. При разработках WBS используется правило «8/80» (1 день — 2 рабочие недели). Пакет Работ (Work Breakdown Package WB) должен быть разработан за период от 8 до 80 часов. Каждый Пакет Работ должен быть назначен на конкретное подразделение или сотрудника.

Управление сроками проекта (Project Time Management)

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

Управление стоимостью проекта (Project Cost Management)

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

Оценка — основа планирования. Рассматривая рабочие пакеты, мы оцениваем: время, персонал, издержки. Оценка — это некая величина, которая ставится на основе опыта работы с другими проектами. Для повышения степени надежности оценок можно воспользоваться следующими методами Оценки Затрат: Метод аналогий, Экспертная оценка или Метод показателей.

В качестве механизмов и техник оценки расчета стоимости проекта можно использовать: Экспертное мнение, Аналогичный проект, Параметрический, Ballpark Estimate (Rough Order of Magnitude ROM), Top-down, Three-point Estimate или Button-up метод.

Наиболее точный метод (Button-up), но при этом он требует наличие Структуру Рабочих Пакетов (Work Breakdown Structure WBS).

Управление качеством проекта (Project Quality Management)

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

Управление человеческими ресурсами проекта (Project Human Resource Management)

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

Управление коммуникациями проекта (Project Communications Management)

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

•Определение заинтересованных сторон проекта,

•Планирование коммуникаций,

•Распространение информации,

•Управление ожиданиями заинтересованных сторон проекта (Project Stakeholder Management)

•Отчеты об исполнении.

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

Руководитель проекта — проектная комиссия, руководитель предприятия. Отчеты по проекту, расходы, анализ тренда вех и расходов, причины отклонений.

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

Пользователи, потребители продукта — руководитель проекта. Информация о развитии проекта.

Руководитель проекта — план проекта. Планы постоянно отслеживаются, т. к. это основа проектного контроллинга.

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

Управление рисками проекта (Project Risk Management)

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

•Планирование управления рисками,

•Идентификация рисков,

•Качественный анализ рисков,

•Количественный анализ рисков,

•Планирование реагирования на известные риски,

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

Управление поставками проекта (Project Procurement Management)

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

•Планирование закупок,

•Осуществление закупок,

•Управление закупочной деятельностью,

•Закрытие закупок.

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

Cost plus Fixed Fee (CPFF) — покупатель находится в зоне риска

Firm Fixed Price (FFP) — продавец находится в зоне риска

Cost plus Incentive Fee (CPIF) — покупатель и продавец разделяют риски

Time & Material (T&M) — покупатель находится в зоне риска

Управление заинтересованными сторонами проекта (Project Stakeholder Management)

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

Методы и техники Управления Проектами

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

Анализ дерева решений (Decision Tree Analysis)

Анализ дерева решений (Decision Tree Analysis) — это метод, который описывает процесс принятия решения посредством рассмотрения альтернативных вариантов и последствий их выбора. Этот метод используют в тех случаях, когда прогнозируемые сценарии и результаты действий, имеют вероятностный характер. Отображается в виде диаграммы. В диаграмме анализа дерева решений отражаются вероятности и величины затрат, выгоды каждой логической цепи событий и будущих решений, и используется анализ ожидаемого денежного значения с целью определения относительной стоимости альтернативных действий.

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

•Квадраты — места принятия решений.

•Круги — места появления исходов.

•Пунктирные линии — возможные решения.

•Треугольники или прямые линии — возможные исходы.

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

Анализ сильных и слабых сторон, возможностей и угроз (SWOT Analysis)

SWOT-анализ (Strengths Weakness Opportunities Threats Analysis) — это метод оценки внутренних и внешних факторов, которые влияют на развитие компании. Он поможет вам оценить сильные и слабые стороны вашего дела, найти новые возможности и определить возможные угрозы. SWOT-анализ разделяет факторы влияния на компанию на четыре категории, что помогает оценить её со всех сторон, это:

S-strengths (сильные стороны). Например, продажа товаров непосредственно покупателю, прибыль больше, чем у конкурентов, клиент-сервис — лучший на рынке и т. д.;

W-weaknesses (слабые стороны). Например, недостаточно партнёров, неэффективная реклама, маленькая целевая аудитория;

O-opportunities (возможности). Например, потенциальные клиенты узнают всё, что им нужно о вашем товаре из Интернета, покупки совершаются круглосуточно, не зависимо от того, работаете вы или нет;

T-threats (угрозы). Например, бренд ваших конкурентов более известный на рынке, качество товаров, которые предлагают конкуренты выше.

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

Внутренние факторы — сильные и слабые стороны относятся к внутренним факторам, а значит, вы их легко можете оценить:

•Финансовые ресурсы. Это финансирование, возможности получения дохода;

•Физические ресурсы. Это ваше оборудование, здания, местоположение;

•Человеческие ресурсы. Сотрудники, иногда волонтёры, целевая аудитория;

•Доступ к природным ресурсам, авторские права, патенты;

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

Чтобы найти сильные стороны своего бизнеса ответьте на такие вопросы:

Какие преимущества у вашего бизнеса?

Что вы делаете лучше, чем все остальные?

Какие ваши сильные стороны видят ваши клиенты?

Какое у вас уникальное торговое предложение (УТП)?

Как вы можете увеличить свою прибыль?

Рассмотрите свои сильные стороны, как с внутренней точки зрения, так и с точки зрения ваших клиентов. Оценивайте свои сильные стороны относительно к конкурентам.

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

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

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

•Финансирование. Такие, как пожертвования, государственные влияния, налоги и т. д.;

•Демографические данные. Это возраст, пол, раса, национальность, культурные ценности целевой аудитории;

•Отношения с поставщиками и партнёрами;

•Политическая, экологическая, экономическая ситуация в стране.

Метод оценки и анализа программ (Program Evaluation and Review Technique, PERT)

Метод PERT (Program Evaluation Review Technique PERT), Техника Оценки и Анализа Программ и проектов часто используется при управлении проектами и проведении анализа производственных процессов. Метод PERT является инструментом, который вычисляет ожидаемое значение продолжительности проекта или отдельного процесса. При управлении проектами метод PERT практически всегда используется в сочетании с методом критического пути (англ. CPM, Critical Path Method).

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

O — оптимистичная оценка длительности задачи,

M — наиболее вероятная оценка длительности задачи,

P — пессимистичная оценка длительности задачи.

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

Диаграмма Гантта (Gantt Chart)

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

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

Начало, конец и длина отрезка на шкале времени соответствуют началу, концу и длительности задачи.

Анализ освоенного объема (EVA)

Анализ освоенного объема (EVA) — это расчет показателей эффективности проекта в рамках освоенного объема. EVA основывается на тех же принципах, что и анализ тренда расходов и используется как правило в крупных проектах. За основу берутся цифры: Освоенный объем, плановые и фактические расходы. Рассмотрим на примере:

Задачу (ЗП1) должен выполнить один исполнитель (ИС1). Выделено по плану — два дня (2 х 8 часов = 16 часов) времени, стоимость работ исполнителя $ 10.00 в час (плановый расход = $ 10.00 х 16 часов = $ 160.00).

По факту: исполнитель закончил работу на третий день, дополнительно истратив два часа, сверх запланированных. Показатели: Факт по времени (2 х 8 часов +2 часа = 18 часов), и фактические расходы = $ 10.00 х 18 часов = $ 180.00.

Результат:

На утро третьего дня: результат выполнения задачи ЗП1 = 16/ (16+2) * 100% = 89% и стоимость выполнения ЗП1 = $ 180.00

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

Основные показатели метода:

Плановый объем (Planned Value PV) — объем запланированных работ в базовых ценах. Или другое название — БСЗР (базовая стоимость запланированных работ). В нашем примере PV равен 160$, т. к. базовый объем работ, который должен быть выполнен к среде, равен 16 чел-часам, а базовая цена равна 10$ за час работы.

Освоенный Объем (Earned Value EV) — выполненная часть работ от запланированного объема. Измеряется как % завершения работы, умноженный на базовый бюджет задачи. Ранее этот показатель назывался БСВР (базовая стоимость выполненных работ). В нашем примере EV равен 142$, т. к. % выполнения по задаче равен 89%, а ее базовый бюджет составляет 160$.

Фактическая стоимость (Actual Cost AC) — реальная стоимость выполненных работ. Измеряется количеством денег, которые мы по факту уже должны за выполненную работу. В нашем примере AC равен 160$, т. к. фактически исполнитель затратил 16 часов, а каждый час стоит 10$.

Бюджет по завершению БПЗ (Budget At Completion BAC) фиксируется на старте проекта как сумма утвержденного бюджета на весь проект. В нашем кейсе он равен 160$.

Отклонение по стоимости (Cost Variance CV) — отклонение по стоимости (формула: CV=EV-AC). $ 142.00 — $ 160.00 = — $ 18.00. Отрицательное значение — превысили бюджет, положительное — экономим бюджет. В нашем случае — Мы перерасходовали бюджет.

Отклонение от календарного плана ОКП (Schedule Variance SV) — отклонение по срокам (формула: SV=EV-PV). $ 142.00 — $ 160.00 = — $ 18.00. Отрицательное значение — отстаем от плановых сроков, положительное — опережаем сроки. Мы отстаем от графика.

Индекс отклонения по стоимости ИОС (Cost Performance Index CPI) — индекс выполнения стоимости (формула: CPI=EV/AC). Индекс больше 1 — идем с экономией бюджета, меньше 1 — превышаем бюджет. В нашем случае $ 142.00/$ 160.00 = 0,89. Перерасход бюджета по задаче на 11%

Индекс отклонения от календарного плана ИОКП (Schedule Performance Index SPI) — индекс выполнения сроков

(формула: SPI=EV/PV). Индекс больше 1 — опережаем график работ, меньше 1 — отстаем от базового графика.

В нашем случае: SPI = $ 142.00/$ 160.00 = 0,89. Отстаем по срокам задачи на 11%

Предварительная оценка по завершению ПОПЗ (Estimate At Completion EAC) — Представляет ожидаемую общую стоимость проекта после завершения оставшихся работ (Формула: EAC=BAC/CPI). В нашем случае: $ 160.00/0,89= $ 180.00. На сегодняшний день оценочная стоимость задачи проекта = $ 180.00.

Оценка до завершения ОДЗ (Estimate To Complete ETC) — Сколько еще нужно денег, чтобы завершить проект (Формула: ETC=EAC-AC). В нашем случае: ETC=EAC-AC=$ 180.00 — $ 160.00= $ 20.00 — еще нужно на сегодняшний день, чтобы завершить задачу.

Отклонение бюджета по завершению ОБЗ (Variance At Completion VAC) — Ожидания по перерасходу или экономии бюджета (формула: VAC = BAC-EAC). В нашем случае: VAC = BAC-EAC= $ 160.00 — $ 180.00 = — $ 20.00. На 20$ мы перерасходуем бюджет.

Формулы для расчета состояния проекта: EAC = AC + Button-up ETC, EAC = AC + BAC — EV, EAC = BAC/Cumulative CPI, EAC = AC + [(BAC — EV) / Cumulative CPI x Cumulative SPI], EMV = probability x impact, EV = BAC / % of completion, TCPI = (BAC — EV) / (BAC — AC),

Анализ тренда расходов

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

Постоянно контролируемые значения:

•Плановые расходы — то, что было запланировано изначально на реализацию.

•Фактические расходы — то, что было затрачено по факту на сделанную работу.

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

•Остаток производства — то, что осталось сделать. Вычисляется как разница между запланированным объемом работы и сделанные к определенной точке во времени. Остаток производства = плановые расходы — стоимость сделанных работ.

•Дополнительные расходы — это разница между фактическими расходами и плановыми.

•Дополнительные расходы = фактические расходы — плановые расходы.

V-факт — предварительные фактические расходы. Выступает, как сигнал пере-расходования средств.

V-факт = бюджет + дополнительные расходы + остаток производства.

Анализ тренда этапов проекта (вех проекта)

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

•Что сделано?

•Что нужно еще сделать для завершения вехи?

•Успели ли в срок?

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

По горизонтали: периоды предоставления отчетности, например, каждую неделю. По вертикале: такая же шкала, с отметками вех. Отметка вех при X=0, соответствует запланированным показателям вех на этапе старта проекта.

Биссектриса — обозначает положение достигнутых вех.

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

Идеальное состояние, когда линия четко идет без изменений по оси Y.

Отклонения по вертикале (отклонение прогнозируемого срока от первоначально запланированного):

Вверх: отставание по срокам

Вниз: опережение графика

Анализ с помощью Треугольника целей

Анализ с помощью Треугольника целей — Углы треугольника обозначаются, как:

•Сроки. Время на реализацию проекта.

•Расходы. Деньги, люди, бюджет.

•Объем работ. Цели, задачи, качество.

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

Результаты проекта меряются с определенной периодичностью.

Сроки — измеряется затраченным временем на проект.

Расходы — измеряются фактическими затратами.

Объем работ — измеряется в процентном соотношении запланированных и выполненных работ.

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

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

Анализ допущений (Assumptions Analysis)

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

Анализ ожидаемого денежного значения (Expected Monetary Value Analysis EMV)

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

Анализ отклонений (Variance Analysis)

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

Анализ сети (Schedule Network Analysis или Network Analysis)

Анализ сети расписания (Schedule Network Analysis) — Метод определения ранних и поздних стартов и ранних и поздних финишей для невыполненных плановых операций проекта. См. также метод критического пути, метод критической цепи, анализ возможных сценариев и выравнивание ресурсов.

Анализ тенденций (Trend Analysis)

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

Анализ резервов (Reserve Analysis)

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

Анализ чувствительности (Sensitivity Analysis)

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

Быстрый проход (Fast Tracking)

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

Выравнивание ресурсов (Resources Leveling)

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

Декомпозиция (Decomposition)

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

Метод «операции в узлах» или метод предшествования (Precedence Diagramming Method, PDM)

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

Метод сетевых графиков

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

Метод критического пути (Critical Path Method, CPM)

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

Метод критического пути — довольно часто используется в строительстве и характеризуется наличием четко выраженного пути проекта, этот путь формируют самые длинные работы проекта. Сам критический путь и определяет продолжительность всего проекта. Определяя и идентифицируя наиболее важные задачи, Вы можете оценить даты завершения, зависимости, ключевые вехи и конечные результаты. Любые отставания по датам для тех работ, которые лежат на критическом пути ведут к увеличению длительности последующих работ. При необходимости сократить длительность проекта необходимо сокращать сроки работ на «критике». Методология управления проектами при помощи критического пути позволяет сравнивать плановые и фактические показатели (как ситуация должна развиваться и что происходит на самом деле) каждый день. Четыре этапа планирования по методу:

•цели и ограничения (рассмотрение проекта по нескольким аспектам — длительность, рас, качество и проч.);

•продолжительность работы;

•сетевой график работ;

•построение диаграммы Гантта

Метод критической цепи. Метод критической цепи (Critical Chain Method CCM)

отличается от метода критического пути тем, что он ориентирован на использование ресурсов проекта, а не проектных работ. Для решения потенциальных проблем с ресурсами формируются буферы, гарантирующие своевременную реализацию проектов с соблюдением всех необходимых мер безопасности. Управление проектом по методу критической цепи помогает избегать отставаний и задержек в проекте, определяя критический путь работ, а также резервы ресурсов (запас времени) для этих работ. Поскольку графики строятся, учитывая доступность ресурсов, срок проекта может быть дольше, но вероятность срыва сроков ключевых событий может быть снижена. Основа методологии критических цепочек — формирование основных работ критически важных для проекта и удержание сроков работ, соответственно и финальной даты завершения проекта. Критические работы проекта провязываются логическими связями с учетом ресурсных и административных ограничений; Если в проекте ресурсы не ограничены, расчётные показатели будут схожими с PERT. Если в проекте все же ограничены ресурсы, то необходимо:

•Определить околокритические работы в графике, такие работы очень часто идут параллельно основной «красной»

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

•Определить критическую цепочку проекта при помощи ресурсных связей

Метод Монте Карло (Monte Carlo Analysis)

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

Метод оптимизации выгод (Value Engineering, VE)

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

Метод освоенного объема (Earned Value Technique, EVT)

Особый метод для измерения исполнения работ для элемента иерархической структуры работ, контрольного счета или проекта. Другое название — «метод правил освоения и начисления дохода» (earning rules and crediting method).

Оценка «снизу вверх» (Bottom-up Estimating)

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

Оценка «С вверху вниз» (Top down Estimating)

Метод оценки элемента работ. Обратный методу «снизу-вверх».

Планирование методом набегающей волны (Rolling Wave Planning)

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

Управление освоенным объемом (Earned Value Management, EVM)

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

Иерархическая структура рисков (Risk Breakdown Structure, RBS)

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

Матрица вероятности и последствий (Probability and Impact Matrix)

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

Матрица ответственности (Responsibility Assignment Matrix, RAM)

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

Расписание контрольных событий (Milestone Schedule)

Укрупненное расписание работ, отображающее сроки наступления основных контрольных событий.

Метод аналогий

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

Метод Экспертной Оценки (Expert Judgment)

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

Метод показателей

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

Фаза анализа — 20%

Фаза проекта — 35%

Фаза реализации — 30%

Фаза тестирования — 15%

Оценка «Навскидку» Poker Estimate

Техника предполагает следующие ключевые аспекты действий:

•Собирается рабочая группа (разработчики, аналитики, представители бизнеса и т п).

•Озвучивается задача,

•Каждый участник оценивает сроки проекта основываясь на своем опыте и уровню,

•Каждый участник высказывает свое мнение.

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

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

Оценка времени или часов разработки

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

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

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

Poker Estimate,

Сравнение с аналогом,

Bottom up & Top down

Экспертная оценка.

После проведения анализа по одним из методик, рекомендуется добавить к срокам проекта:

•15—20% процентов времени для покрытия рисков и непредвиденных случаев

•Принимаем в расчетах 80% процентов рабочего времени (а не 100% формальных) разработчика, как основной рабочей единицы занятой на проекте

Ведение документации по проекту

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

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

Правило: «информация — это долг, который одни должны отдать, а другие потребовать».

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

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

•Планы

•Статусы

•Протоколы совещаний

•Документация по дефектам, тестам

•Договоры с поставщиками

•Анализ рисков

Пример информации, которую можно отдать во вне:

•Матрица компетенций

•Журнал распределения обязанностей

•Статусы проекта

•График вех

•Заключительные отчеты

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

Устав проекта

•Описание содержания проекта

•Реестр заинтересованных сторон проекта

План управления проектом

Запрос на изменение в проекте

Лист согласования участия в проекте

Положение об управлении рисками

•План управления рисками

•Реестр рисков

Протокол совещания

Отчеты

•Отчет об исполнении работ по проекту

•Отчет о статусе проекта

•Отчет по завершению проекта

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

•Какие артефакты и документы нужны для вашего проекта?

•Насколько детально нужно их прорабатывать?

•Стоимость времени, потраченное на создание документа по отношению к ценности документа?

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

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

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

•Сначала выбирается минимальный набор документов.

•Заполняете на основании здравого смысла. Если что-то кажется лишним, отбрасывайте.

•Затем оцениваете, сможете ли вы с помощью этой информации достичь нужных результатов.

•Если нет, то включите недостающие разделы или документы.

•Заполните их и снова проведите оценку.

•И так далее до достижения результатов.

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

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

Какие минимальные требования к инструментам? Что они должны помогать вам делать?

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

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

Набор инструментов:

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

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

Профессиональные инструменты по Управлению Проектами такие как:

•Microsoft Project 2016 Server / Professional

•JIRA Project Management

Для развитых организаций или проектных ИТ компаний желательно дополнительно использовать профессиональные системы, если они не входят в составе систем Управления Проектами, такие как:

•Система санкционирования выполнения работ (Work Authorization System).

•Система управления изменениями (Change Control System).

•Система управления конфигурацией (Configuration Management System).

Ключевые факторы успеха проекта

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

Можно выделить следующие ключевые факторы успеха проекта:

•Четкие цели. Для проекта жизненно необходимы четкие и понятные цели. Причем достижение этих целей должно быть

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

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

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

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

постепенных улучшений часто более эффективен.

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

•Обеспечить максимальное повторное использование ИТ активы организации. Все сломать и переделать — это долго и дорого. А ломать то, что действительно работает, глупо. Зачастую информационные системы и оборудование компании используются на 15–30% возможностей. Это отличная возможность для получения быстрых результатов с минимальными затратами.

•Архитекторы и менеджеры проектов должны активно работать с бизнесом и ИТ проектами. А не генерировать гениальные идеи на основе «лучших практик». Работа «в поле» для многих начинающих архитекторов крайне некомфортна. Они боятся показаться некомпетентными. Хотя то, что ИТ специалисты знают глубже конкретные технологии, чем архитекторы, совершенно нормально. Как и то, что бизнес знает лучше, как работает компания. Работа с людьми — единственный способ достичь результатов.

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

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

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

•Начинайте с пилотного проекта. На старте ваша основная цель — показать реальные результаты.

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

•Достаточно знаний и умений для того, чтобы сделать шаг

•Шаг кратковременный по времени

•Шаг имеет низкий уровень риска

•Шаг поведенческий-конкретный

•Понятно, что будет успехом шага

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

•Помните о ценности. Каждое ваше предложение должно быть обосновано с точки зрения ценности для компании. Забудьте фразу: «Это будет более правильно с точки зрения архитектуры». Всегда помните про выгоды, сроки, затраты и риски. Не предлагайте революций без подробного экономического обоснования.

•Не изобретайте велосипедов.

•Громко скажите «спасибо» руководству за поддержку, коллегам за помощь и терпение и т. д.

Основные причины провала проекта

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

•Проект представляет собой решение, приводящее к проблеме

•В конечном результате заинтересована только группа, работающая над проектом

•Никто ни за что не отвечает

•План проекта недостаточно структурирован

•План проекта недостаточно детализирован

•На реализацию проекта выделено недостаточно средств

•Выделенных ресурсов недостаточно для выполнения работ

•Проект не сверяется с планом его реализации

•Отсутствует взаимодействие между членами рабочей группы проекта

•Проект отклоняется от поставленной цели

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

Заключение

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

•Классические методы как «трактор» (если удачное завершение проекта, то как немецкий трактор) — «… сказали пахать — пашем с раннего утра и пока не вспашем…». Ориентирован на результат — выполнить любой ценной (как правило это конечный продукт, а стоимостью и временем как получится). Все делается по порядку и по инструкции.

•Методология «PRINCE2» — тоже самое, но задаются вопросом «… а на кой нам это нужно если дохода нет?…»

•«Вот „бабули“, больше нет — крутись как хочешь, но к завтрашнему утру чтобы было все готово. Что конкретно готово не знаем — но клиент сказал — ВСЕ». Это больше подходит на пример использования гибких методов управления проектами.

•«Пашем как молотилка» — метод «SCRUM»

•«KANBAN» присмотрит за тем, чтобы работники не были перегружены, а то «… сдохнут кони раньше времени…»

•Методологии «LEAN» и «SIX SIGMA» присмотрят за вопросом «… а не много ли косячат?…»

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

Концепция управления рисками

Общие Принципы

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

Данный раздел содержит основные принципы управления рисками при проектировании архитектуры, которые должны быть приняты во внимание. В процессе разработки и внедрения различных сервисов ИТ архитектуры необходимо проводить непрерывный процесс управления рисками. Для управления ИТ рисками можно воспользоваться как общими методиками так м специфичными для ИТ. Данная глава учитывает рекомендации стандарта «Управления и анализа рисков ISO 73: 2009», а также методика CRAMM v5 (CCTA Risk Analysis & Management Method) на основе требований организации CCTA (Central Computer and Telecommunications Agency) которая соответствует стандарту BS7799/ ISO17799.

Классификация рисков

Общую классификацию рисков можно представить, как:

Внутренние риски:

•Проектные,

•Технические,

•Технологические,

•Организационные,

•Финансовые и т п

Внешние риски:

•Природные,

•Политические,

•Социальные,

•Экономические и т п

По типу:

•Предсказуемые

•Не предсказуемые

По характеру:

•Преднамеренные

•Не преднамеренные

По виду:

•Прямые

•Косвенные

По результату:

•Нарушение функционирования,

•Нарушение целостности,

•Нарушение достоверности

•Нарушение конфиденциальности

По механизму воздействия:

•Аварии

•Ошибка персонала

Критерии оценки

К основным критериям оценки ценности ресурсов можно отнести следующие:

•Ущерб для репутации организации

•Безопасность персонала

•Разглашение персональных данных

•Разглашение конфиденциальных данных

•Разглашение коммерческой информации и сведений

•Санкции со стороны надзорных и государственных органов

•Финансовые потери

•Нарушения нормального функционирования организации

Основные шаги и стадии

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

Организация процесса управления рисками (General Risk Management)

•Разработка процесса, политик и процедур по Управлению Рисками

•Классификация ресурсов, рисков, уязвимостей, угроз

•Классификация реакции на риски и методов оценки

•Формирование комитета Управления Рисками

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

Идентификация и оценка ресурсов (Identification and Valuation of Assets)

•Экспертная группа идентифицирует и оценивает ценность ресурсов

•Экспертная группа идентифицирует возможные риски

Оценка угроз и уязвимостей (Threat and Vulnerability Assessment)

•Экспертная группа оценивает уязвимости систем

•Экспертная группа оценивает угрозы систем

Анализ Рисков (Risk Analysis)

•Экспертная группа проводит качественный и количественный анализ рисков. В качестве основных критериев определяются: «вероятность» и «влияние» и классифицируются по значениям: «высокое», «среднее» и «низкое».

•Проводится количественный анализ рисков (при необходимости)

•Экспертная группа группирует риски и формирует матрицу (реестр) рисков

Управление Рисками (Risk Management)

•Концентрируется внимание на рисках со значениями «высокое» и «среднее».

•Определяется реакция на риски (принятие, снижение, передача и т п)

•Определяются возможные контрмеры и стоимость их внедрения

•Формируется ряд сценариев проекта как минимум «негативный», «позитивный» и «реалистичный»

•Проведение корректировки

•Результаты документируются и принимается решение

•Все изменения в планах проекта должны обсуждаться и документироваться

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

•реестр рисков,

•запросы на изменение,

•протоколы обсуждений.

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

Процесс является непрерывным и циклическим.

Анализ рисков

Основные механизмы и элементы анализа с технической стороны:

BIA (Business Impact Analysis) — Анализ ИТ сервиса по уровню воздействия на бизнес

SFA (Service Fault Analysis) — Анализ ИТ сервисов по уровню воздействия на связанные ИТ сервис

CFIA (Component Fault Impact Analysis) — Анализ компонентов по уровню воздействия на ИТ сервис

Участники процесса и их роли

Основные участники процесса управления и анализа рисками:

•Департамент Внутреннего Аудита как владелец процесса управления рисками компании,

•Бизнес подразделения (в случае проектов, связанных с ИТ) портфелей,

•ИТ департамент в составе экспертной группы ИТ специалистов,

•Департамент Безопасности,

•Юридический департамент

•Финансовый департамент

•Возможно участие сторонних консультантов

Методы оценки рисков

В качестве методов оценки рисков можно использовать общеизвестные методы, такие как:

•Анкетирование

•Интервьюирование

•Комиссионный метод

•«Мозговой штурм» (Brainstorm)

•«Дельфи» метод (Delfi)

Наиболее распространённые инструменты, методики и техники оценки риска приводятся в международном стандарте ISO/IEC 31010:2009. В стандарте кратко описывается 31 метод оценки риска: мозговой штурм, анализ «Что если…», FMEA, HAZOP, HACCP, диаграмма «галстук-бабочка», анализ дерева отказов, Байесовы сети, FN-кривые и др.

Метод «Дельфи» или «Дельфийский метод» (Delphi Technique)

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

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

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

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

•Вторая группа — это аналитики, приводящие мнения экспертов к единому знаменателю

Сам же метод Дельфи подразумевает несколько этапов:

•Собирается группа

•Ставится задача

•Согласованность мнений

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

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

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

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

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

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

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

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

Другая модификация метода Дельфи направлена на то, чтобы сократить время, которое будет затрачено на осуществление аналитического этапа — он называется «Экспресс-Дельфи». С учётом того, что традиционный метод со всеми его достоинствами является довольно трудозатраты и требует для своего применения значительного количества времени, экспресс-метод позволяет сохранить все основные элементы методики при том, что всю процедуру можно осуществить в течение нескольких часов, однако требуется специальная техническая база. Каждый член экспертной группы на протяжении отведённого временного периода находится за компьютером. Все компьютеры объединены одной общей сетью, которая замыкается на руководителе мероприятия. После того как эксперты предлагают свои решения в ускоренном режиме, аналитики точно так же должны как можно быстрее произвести оценки. Огромную роль в этом процессе играет оперативность в обработке и систематизации материала.

Достоинства метода:

•Метод Дельфи способствует выработке независимости мышления членов группы.

•Обеспечивает спокойное и объективное изучение проблем, которые требуют оценки.

Недостатки метода Дельфи:

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

•Коллективное мнение далеко не во всех случаях является верным

•Аналитики отбрасывают креативные решения, имеющие наименьшее количество сторонников, а эти решения могут быть самыми эффективными

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

•Эксперты склонны проявлять конформизм, испытывая желание и стремясь присоединиться к мнению большинства

•Организаторы имеют возможность манипулировать экспертной группой

Мозговой штурм (Brainstorming)

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

Этапы подготовки к проведению мозгового штурма:

•Постановка задачи

•Формирование группы участников

•Информирование участников обсуждения

•Составление списков мотивирующих вопросов

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

Составление списка участников мозгового штурма. Наиболее продуктивна группа из 10 или чуть меньше человек. Кто должен входить в состав панели участников:

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

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

•Один «собиратель идей», который фиксирует все предложенные идеи.

Составление и рассылка информационного письма участникам. Письмо должно содержать:

•название сессии,

•решаемую проблему,

•время, дату и место проведения.

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

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

Этапы проведения (работа с идеями):

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

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

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

Основные правила:

•Фокус на количество: это означает, что должно быть выработано как можно большее количество разнообразных идей с прицелом на то, что чем больше их будет, тем больше вероятность найти среди них наилучшее решение. «Количество порождает качество».

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

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

•Объединение и улучшение идей: лучшие идеи могут быть объединены в другую, еще более лучшую, идею (по типу «1+1=3»). Такое правило стимулирует создавать идеи посредством ассоциаций.

Стандартная методология M_o_R (Management of Risks)

Для оценки рисков и управления ими применяется стандартная методология M_o_R (Management of Risks), которая состоит из следующего:

Принципы M_o_R — Базируются на принципах управления организацией и являются необходимыми для эффективного управления рисками;

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

Процессы M_o_R — Выделяют четыре процесса в рамках M_o_R:

•Определение — определение угроз для деятельности, которые могут повлиять на достижение ею намеченного результата;

•Оценка — оценка суммарного влияния всех определенных угроз;

•Планирование — определение набора управленческих действий, которые уменьшат риски;

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

Пересмотр и внедрение M_o_R — Внедрение процессов, политик и подхода M_o_R так, чтобы они непрерывно контролировались и оставались эффективными;

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

Кроме этого могут быть использованы специализированные методики:

Методика CRAMM v5

К специфическим ИТ методам и стандартам можно отнести методику CRAMM v5. Цель метода является создание формализованных процедур, позволяющих:

•Анализ требований, предъявляемых к Информационной системе, полон и документирован

•Идентификация и классификация рисков

•Идентификация и оценка уязвимости ИТ ресурсов

•Идентификация и оценка угроз ИТ системам

•Формирование обоснований для мер противодействия

•Избежать излишних расходов на обеспечение Информационной Безопасности систем

•Сокращение сроков по внедрению и сопровождению информационной безопасности организации

•Оказать помощь по вопросам функционирования ИТ сервисов на всех этапах жизненного цикла

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

•Оценка эффективность контрмер

•Формирование отчетов

Методология CORAS

Сочетание различных техник, таких как Event-Tree-Analysis, цепи Маркова и FMECA. В данном методе используется UML (Unified Modeling Language, язык программирования для визуального отображения объектов моделирования). Метод состоит из следующих действий:

•Поиск и систематизация данных об объекте анализа

•Определение объекта и субъекта, участвующие в анализе

•Полное описание процесса или задачи

•Проверка точности и полноты данных, представленных для анализа

•Осуществление действий по выделению рисков

•Оценка вероятности и последствий возникновения угрозы

•Ликвидация угрозы

Метод OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation)

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

Оценка организационных аспектов

Комплексный анализ информационной инфраструктуры организации

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

•Документирование текущего состояния

•Выбор подходов по сокращению рисков

•Выбор подходов по сокращению расходов

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

•Выявляют перспективные направления работ по обеспечению информационной безопасности

Матричный Метод Анализа

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

Матрица угроз — содержит в себе отношения между уязвимостями и угрозами.

Матрица уязвимостей — содержит связь между активами и уязвимостями.

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

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

1 — низкая,

2 — средняя

3 — высокая.

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

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

Одно из преимуществ данной методики является ее универсальность

Иерархическая структура рисков (Risk Breakdown Structure, RBS)

Иерархическая структура рисков (Risk Breakdown Structure, RBS) — Иерархически организованное представление известных рисков проекта, распределенных по категориям и подкатегориям риска, указывающим различные области и причины возможных рисков. Иерархическая структура рисков часто подгоняется под конкретные типы проектов.

Методы расчета рисков

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

SLE (Single Loss Expectancy) = Asset Value x EF (Exposure Factor)

ALE (Annualized Loss Expectancy) = SLE x ARO (Annualized Rate of Occurrence)

Total Risk = Threats x Vulnerabilities x Asset Value

ACV (Actual Cost Evaluation)

Asset Value (AV) — Стоимость ресурса, отражает ценность ресурса. При качественном анализе можно использовать фиксированные величины (1 — низкая стоимость, 2- средняя и 3 — высокая стоимость). Например, сервер активного каталога будет иметь показатель AV=3, а рабочая станция AV=1.

Exposure Factor (EF) — Степень защищенности ресурса. Демонстрирует насколько данный ресурс подвержен угрозе. При качественном анализе можно использовать фиксированные величины (1 — низкая степень уязвимости или воздействия, 2- средняя степень уязвимости или большая вероятность восстановления ресурса и 3 — высокая степень уязвимости или возникнет необходимость замены ресурса). Например, сервер активного каталога будет иметь показатель EF=2.

Annualized Rate of Occurrence (ARO) — Оценка возможности возникновения угрозы. Указывает вероятность реализации конкретной угрозы за фиксированный промежуток времени (год). При качественном анализе можно использовать фиксированные величины (1 — низкая вероятность, 2- средняя и 3 — высокая вероятность). Например, сервер активного каталога будет иметь показатель ARO=1.

Annual Loss Exposure (ALE) — Оценка ожидаемых потерь вследствие воздействия определённой угрозы за определённый период времени. При качественном анализе можно использовать фиксированные величины (1 — низкая стоимость, 2- средняя и 3 — высокая стоимость). Например, сервер активного каталога будет иметь показатель AV=3, а рабочая станция AV=1.

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

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

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

Реакция на риски

Влияние рисков может быть, как «негативное», так и «позитивное».

Для «позитивного» влияния риска может применятся следующая реакция:

•Использование (Exploit),

•Разделить (Share),

•Расширить (Enhance)

•Принять (Accept)

Для «негативного» влияния риска может применятся следующая реакция:

•Избегание (Avoid),

•Передача (Transfer),

•Снижение (Mitigate)

•Принятие (Accept)

Превентивные меры по реагированию на риски

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

•Учет опыта аналогичных проектов

•Распределение рисков между участниками проекта

•Выделение ресурсов для управления проектами

•Планирование резервов

•Контроль за внесением изменений в план проекта

•Привлечение независимых экспертов

•Страхование рисков

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

Общие Положения

Данный раздел содержит основные принципы управления качеством, которые должны быть приняты во внимание при проектировании архитектуры. При разработке концепции учитывались международные стандарты ISO9000, ISO8402, BS7925—1.

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

•Качество — это неотъемлемый элемент любого проекта

•Качество — это то, что определяет потребитель, а не изготовитель

•Ответственность за качество должна носить адресный характер

•Повышение качества в современном мире зачастую зависит от уровня технологий

•Повышение качества возможно только усилиями всех сотрудников организации

•Контроль процессов более эффективен, чем контроль результатов

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

Основные аспекты качества

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

Качество достигается за счет тщательной разработки проекта и его сопровождения

Соответствие запланированных характеристик проекта или продукта его фактическим характеристикам

Качеством материально-технического обеспечения на всем жизненном цикле продукта или сервиса

Основные процессы управления качеством

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

Quality Control (QC) — контроль качества. Это совокупность действий, проводимых над продуктом или сервисом в процессе разработки, для получения информации о его актуальном состоянии в разрезах:

•готовность продукта к выпуску,

•соответствие зафиксированным требованиям

•соответствие заявленному уровню качества продукта.

Testing — тестирование. Одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis). Условно можно разделить на две категории:

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

•Валидация (Validation) — это определение соответствия, разрабатываемого ПО ожиданиям и бизнес требованиям.

Quality Improvement (QI) — повышение качества. Это совокупность мероприятий, для обеспечения улучшение или повышение уровня качества.

Участники процесса и их роли

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

•Руководство бизнеса

•Департамент Внутреннего Аудита как владелец процесса управления качеством,

•Бизнес подразделения (в случае проектов, связанных с ИТ) портфелей, как заказчики ИТ сервисов

•ИТ департамент в составе экспертной группы ИТ специалистов, управление качеством ИТ сервисов

•Возможно участие сторонних консультантов

Концепция Управления Проектами и Контроля Качества «Шесть сигм» (six sigma)

Концепция «шесть сигм», которую иногда называют методологией, была разработана компанией Motorola для исключения лишних потерь, улучшения процессов и повышения прибыли. Основная цель SIX SIGMA — улучшение процессов и качества продукции за счет снижения дефектов или ошибок. Рейтинг/градация «6 сигма» означает, что 99,99966% от того, что производится — является бездефектным. Проверяя процессы производства в целом, Вы можете найти возможные улучшения и доработки даже перед появлением дефектов. Методология, построенная на основе анализа данных, включает три ключевых компонента:

•DMAIC (define, measure, analyze, improve and control) — определение, измерение, анализ, улучшение и контроль;

•DMADV (define, measure, analyze, design and verify) — определение, измерение, анализ, проектирование и проверка;

•DFSS (Design for Six Sigma) — проектирование для шести сигм. DFSS может включать как предыдущие, так и другие варианты: например, IDOV (identify, design, optimize and verify) — идентификация, проектирование, оптимизация и проверка.

Данная методика ориентирована на получение высокого уровня качества, единичных ошибки на миллион операций (стандартные метод «4 Sigma» порядка шести тысяч ошибок на миллион операций).

Основные базовые принципы:

•Интерес к клиенту

•Управление на основе фактов

•Ориентированность на процесс, управление и улучшение

•Проективное управление

•Прозрачное взаимодействие (внутри организации без административных и иерархических барьеров)

•Стремление к совершенству и принятие неудач

Основы метода»6 Sigma «можно сформулировать цепочкой (замкнутым циклом) действий DMAIC:

Определение (Define):

•Точное определение проблем и целей

•Выявление требований клиентов

Измерение (Measure):

•Сбор исходных данных

•Проведение измерений

•Статистическая оценка

Анализ (Analyze):

•Анализ данных и процесса

•Определение взаимосвязей

•Идентификация и верификация причин

Улучшение (Improve):

•Систематический поиск и выбор оптимального решения

•Реализация оптимального решения

Контроль (Control):

•Последовательное и долговременное определение уровня качества

•Управление процессом

Основные отличительные черты метода:

•Наличие сильного руководителя

•Результаты должны быть измеряемы

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

•Принятие решений только на основе проверенной информации, а не домыслов и предположений

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

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

Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.

Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.

Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.

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

Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача — долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

Методология «Шесть Сигм» более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, а также снижения количества брака и проблем. «Шесть Сигм» очень похожа на Kanban, только с установленными этапами реализации задач — планированием, определением целей и тестированием качества. Вероятнее всего, встреч команды при применении «Шесть Сигм» будет значительно больше, чем при Kanban, но зато процесс реализации проектов более структурирован и команде сложнее сбиться с пути. Как и Kanban, «Шесть Сигм» можно относительно легко адаптировать к нуждам конкретной компании или команды. Жёстким требованием является лишь тщательное измерение и контроль показателей проекта на этапах реализации — без этого невозможно постоянное долгосрочное улучшение процессов реализации проекта. Описывается стандартами:

•«ISO 13053—1:2011 Количественные методы в процессах улучшения. Шесть сигм. Методология DMAIC»

•«ISO 13053—2:2011 Количественные методы в процессах улучшения. Шесть сигм. Инструменты и техники».

В последнее время, метод «6 Sigma» тесно переплетается с философией «LEAN» — бережливое производство.

Сильные стороны Концепция «Шесть Сигм» предоставляет чёткую схему для реализации проектов и постоянного улучшения процессов. Определяя цели, затем тщательно анализируя их и пересматривая вы получаете количественные данные для более глубокого понимания проекта и принятия более качественных решений. И хотя сбор, анализ данных и извлечение уроков могут занять определённое время, это позволит улучшить и оптимизировать процессы реализации проекта и сэкономить таким образом ресурсы в будущем. 6 сигм подходит для трудных проектов, в которых много новых и сложных операций. Данный подход позволяет реализовывать элементы проекта, учиться на ошибках и повышать качество в будущем.

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

Управление Проектами и Концепция Бережливого Производства (LEAN)

LEAN (Бережливого производства/разработки) — концепция, инициатив по непрерывному улучшению процессов. Кроме выше упомянутого можно принять во внимание теорию ограничений «барабан — буфер — веревка». Суть методики в поиске и определении ограничений в процессе производства. При воздействии на ключевые элементы системы, можно добиться больших результатов, чем при одновременном воздействии на все компоненты. Суть элементов:

•Барабан — производство работает по некоторому «ритму»

•Буфер — перед ограничением должен иметься буфер (ресурсов) для предотвращения простоя производства

•Веревка — материалы должны подаваться только когда они достигли своего разрешенного минимума

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

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

Agile говорит нам, что необходимо разбивать на небольшие управляемые пакеты работ, но ничего не говорит о том, как управлять разработкой этого пакета. Scrum предлагает нам свои процессы и процедуры. Lean же, в свою очередь, добавляет к принципам AGILE схему потока операций (workflow) для того, чтобы каждая из итераций выполнялась одинаково качественно. В Lean, так же, как и в Scrum, работа разбивается на небольшие пакеты поставки, которые реализуются отдельно и независимо. Но в Lean для разработки каждого пакета поставки существует поток операций с этапами, подобными тем, которые были созданы для проекта Аполлон. Как и в классическом проектном менеджменте, это могут быть этапы планирования, разработки, производства, тестирования и поставки — или любые другие необходимые для качественной реализации проектов этапы.

Этапы Lean и их гибкость позволяют быть уверенными в том, что каждая часть проекта реализуется так, как требуется. В Lean не прописаны чёткие границы этапов, как в Scrum прописаны ограничения Спринтов. Кроме того, в отличие от классического проектного менеджмента, Lean позволяет параллельно выполнять несколько задач на разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов. Как и Agile, Lean это скорее концепция, образ мышления, нежели нечто высеченное в камне. Используя идеи Lean Вы можете самостоятельно создать систему, удовлетворяющую вашим требованиям в управлении проектами.

Сильные стороны — Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны — Не каждая часть проекта требует одинаково детальной и дотошной проработки и внимания. Но Lean предполагает именно такой подход к каждой задаче и этапу. Это основной минус применения Lean для крупных и неоднородных проектов. А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций — главное помнить об этом.

Основные методы контроля качества

Метод «7 Основных (японских) инструментов контроля качества»

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

•Лист Сбора Данных

•Гистограммы

•Потоковые диаграммы

•Схема Исикавы «Рыбья Кость» (причинно-следственная связь)

•Диаграмма корреляции (рассеивания)

•Контрольная карта Шухарта

Рассмотрим набор инструментов и методов более подробно.

Лист сбора данных

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

Гистограмма

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

Потоковая диаграмма

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

Схема Исикава «Рыбья кость» (причинно-следственная диаграмма)

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

Все возможные причины классифицируются по пяти «5М» возможным категориям:

•Man — причины, связанные с человеческим фактором

•Machines — причины, связанные с машинами, техникой

•Materials — причины, связанные с материалами

•Methods — причины, связанные с методами, технологией и процессами

•Measurements — причины, связанные с методами измерений

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

Диаграмма Парето (Pareto Chart)

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

Данная диаграмма позволяет с помощью минимальных направленных действий эффективно решать проблемы. Следующие 30% процентов причин порождают порядка 15% процентов проблем. И наконец оставшиеся 50% процентов причин создают не более 5% проблем.

Обратный тезис «для устранения оставшихся 20% процентов проблем потребуется порядка 80% процентов ресурсов» также верен.

Диаграмма корреляции (рассеивания)

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

Контрольная карта Шухарта

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

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

качественные показатели (годен не годен, и т п). Существует четыре типа карты для данного признака:

•U — карта (число дефектов на единицу продукции в переменном объеме выборки)

•С — карта (число дефектов в постоянном объеме выборки)

•Р — карта (доля дефектных изделий в переменном объеме выборки)

•NP — карта (число дефектных изделий в постоянном объеме выборки)

и количественные показатели

Кроме этого существую другие методы

Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA)

Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA) — анализ причин и последствий отказов. Метод анализа, применяемый в менеджменте качества для определения потенциальных дефектов (несоответствий) и причин их возникновения в изделии, процессе или услуге. Он применяется для выявления проблем до того, как они проявятся и окажут воздействие на потребителя.

Существует три основных вида FMEA, определяемых по объекту анализа:

•FMEA — анализ технической системы. Направлен на выявление проблем в основных функциях системы;

•FMEA — анализ конструкции. Направлен на выявление проблем в компонентах и подсистемах изделия;

•FMEA — анализ процесса. Направлен на выявление проблем в процессах производства, сборки, монтажа и обслуживания изделия.

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

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

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

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

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

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

•Определяются варианты применения анализа. FMEA может являться частью комплексного анализа, при котором применяются различные методы. В этом случае FMEA должен согласовываться с анализом системы в целом. Основные варианты могут включать:

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

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

анализ компонентов. FMEA выполняют для физических элементов системы.

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

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

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

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

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

•Для каждого элемента, выделенного на шаге 5, составляется список наиболее значимых видов отказов. Эту операцию можно упростить, если применять стандартный список отказов для рассматриваемых элементов. Если проводится анализ критичности отказов, то необходимо определить вероятность появления отказа для каждого из элементов. Когда определены все возможные виды отказов для элемента, тогда суммарная вероятность их возникновения должна составлять 100%.

•Для каждого вида отказа, выявленного на шаге 6, определяются все возможные последствия, которые могут проявиться. Эту операцию можно упростить, если применять стандартный список последствий. Если проводится анализ критичности отказов, то необходимо определить вероятность возникновения каждого последствия. Когда определены все возможные последствия, вероятность их возникновения суммарно должна составлять 100% для каждого элемента.

•Определяется рейтинг тяжести последствий для потребителя (S) — Severity. Рейтинг тяжести последствий обычно определяется по шкале от 1 до 10, где 1 означает незначительные последствия, а 10 катастрофические последствия. Если вид отказа имеет более одного последствия, то в FMEA таблицу вносится только наиболее тяжелое последствие для этого вида отказа.

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

•Для каждой причины определяется рейтинг вероятности ее возникновения (O) — Occurrence. Вероятность возникновения обычно оценивается по шкале от 1 до 10, где 1 означает крайне маловероятное событие, а 10 означает неизбежное событие. Значение рейтинга заносится в таблицу FMEA.

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

•Для каждого метода контроля определяется рейтинг обнаружения (D) — Detection. Рейтинг обнаружения обычно оценивается по шкале от 1 до 10, где 1 означает, что метод контроля абсолютно точно обнаружит проблему, а 10 — не сможет обнаружить проблему (или контроля вообще не существует). Рейтинг обнаружения заносится в таблицу FMEA.

•Рассчитывается приоритетное число риска (риск потребителя — RPN) которое равно произведению S * O * D. Это число позволяет ранжировать потенциальные отказы по значимости.

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

•После выполнения рекомендованных действий значения рейтингов S,O,D оцениваются заново, а приоритетное число риска RPN пересчитывается.

Анализ первопричины (Root Cause Analysis) и Анализ Дерева Отказов (Failure Tree Analysis FTA)

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

Анализ дерева отказов — это методика идентификации и анализа факторов, которые могут способствовать наступлению некоторого нежелательного события (называемого вершинным («top event»)). Факторы-причины определяются дедуктивным способом, логически выстраиваются и представляются графически в виде диаграммы-дерева, которая изображает связь факторов-причин с основным событием. Достоинства метода:

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

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

Вероятность вершинного события

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

Общие Положения

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

Термин BPM можно трактовать как:

•Business Processes Modeling (Моделирование Бизнес Процессов)

•Business Performance Management (Управление Эффективностью Бизнеса).

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

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

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

Система по управлению бизнес-процессами (Business Process Management System — BPMS) — это структура для построения адаптируемых процессов. Система включает язык для моделирования бизнес-процессов (BPML), интерфейс дизайнера процесса, называемый системой счисления для моделирования бизнес-процессов (the business-process modeling notation — BPMN) и симулятор, который может быть использован для «летного» испытания нового дизайна процесса.

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

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

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

•Оптимизация бизнес процессов

•Повышение производительности

•Снижение издержек

•Уменьшение времени

•Повышение качества

•Снижение операционных рисков

•Прозрачность, контролируемость и управляемость бизнесом

•Соответствие организационной структуры организации оптимальным бизнес процессам организации

•Проектирование новых и оптимизация имеющихся бизнес процессов

•Концентрация на основных бизнес процессах (создающих ценность) и оптимизация поддерживающих процессов

•Тиражирование и унификация бизнес деятельности

•Автоматизация деятельности

•Правильный и оптимальный подбор персонала

•Регламентация деятельности и высвобождение времени руководства

•Получение долее точных финансовых показателей

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

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

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

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

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

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

Бизнес-процессы развития — это процессы совершенствования производимого товара или услуги, технологий, модификации оборудования. Например, это проведение научно-исследовательских и опытно-конструкторских работ (НИОКР) в машиностроении, процесс технического перевооружения в электроэнергетике и т. п.

Методики и техники

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

Аналитической дифференциации, разбиение общего процесса на его элементарные составляющие

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

Основные действия над процессами можно разделить на:

•Проектирование — создание новых процессов

•Перепроектирование — улучшение и корректировка имеющихся процессов

•Реинжиниринг — построение качественно новых процессов, на основе уже имеющихся.

Основные прикладные задачи при разработке бизнес процессов

Упорядочивание последовательности проведения операций:

•По принятию решения

•По исполнению решения

•По отражению принятых решений и результатов их исполнению

Создание методических рекомендаций и инструкций на каждой стадии:

•Документирование действий

•Формирование методических материалов

•Формирования материалов для сотрудников

Квалификационное разделение труда:

•Работа по управлению

•Работа основных специалистов

•Работа вспомогательных специалистов

•Создание ролей и формирование должностных инструкций

Видовое разделение труда:

•Обобщение однородных видов деятельности

•Концентрация специалистов на выполнение однородных действий

•Высвобождение высококвалифицированных специалистов от рутинной деятельности

•Автоматизация однородных действий

Изучение скрытых возможностей процесса

Структурирование работы:

•Определение каждого элемента процесса

•Формирование алгоритма действий в рамках каждого элемента

Выявление и исправления проблем и дефектов.

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

Внесения ясности в понимание процессов за счет наглядности.

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

•Business Process Model and Notation BPMN

•Диаграммный подход (Data Flow Diagram)

•IDEF0 и IDEF3

•Сетевой график PERT и диаграмма Gantt

•BAAN Diagram

•ARIS

Методология IDEF (нотации IDEF0 и IDEF3)

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

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

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

Нотация IDEF3 чаще применяется для построения процессов нижнего уровня, могут также использовать при декомпозиции блоков процесса IDEF0. В отличие отIDEF0 данная нотация не поддерживает отображение «механизмов» и «управления», зато отображает очередность выполнения работ персоналом.

В нотации BPMN применяются логические операторы «И», «ИЛИ», а также их разновидности, как и в нотации IDEF3, но при этом существует возможность задание циклических действий, выполняемых по определенному условию. В отличие от нотации серии IDEF, количество элементов на диаграмме неограниченно, а для лучшего визуального восприятия существует возможность сворачивать и разворачивать определенные части под-процесса.

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

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

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

Можно использовать аналог нотации Basic Flowchart c отображением ответственных за выполнение функции слева, а документов, регламентирующих её выполнение справа от функции, разделив функции на 4 типа и введя такие атрибуты как время и стоимость выполнения функции.

Процессы, построенные в нотации Flowchart наиболее наглядны и понятны даже неподготовленным сотрудникам компании.

В качестве инструментов построения бизнес процессов, можно воспользоваться: ARIS, ELMA, Business Studio, Visio, Fox Manager и т п.

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

Алгоритм построения Бизнес Процессов

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

•Описание структуры организации «как есть»

•Анализ модели организации «как есть»

•Разработка структуры организации «как надо»

•Разработка плана перехода от модели «как есть» к модели «как надо»

•Внедрение необходимых изменений и измерений для достижения уровня «как надо»

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

Данный цикл является базовым для непрерывного процесса улучшения. Его более расширенный аналог, можно представить в виде цикла «Исикавы»:

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

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

Технология процесса — порядок выполнения действий для преобразования входов в выходы.

Система показателей (метрик) процесса — показатели качества продукта, эффективности процесса, удовлетворенности потребителей.

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

Ресурсы процесса — материальные средства, которые владелец процесса распределяет в ходе работ по процессу.

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

•Описание бизнес направлений

•Описание функций в бизнес направлениях. Может состоять из «горизонтальной» и «вертикальной» составляющих.

•Описание отделов и их продукты.

•Распределение функции «как есть»

•Распределение функций «как надо»

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

•Определены границы процесса

•Работы ясны и понятны — элементарные однородные действия (функции)

•Имеется понятие конечного результата и метод его достижения

•Действия могут быть измеряемы и управляемы

•Возможно четко определить роли сотрудников

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

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

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

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

Алгоритм построения бизнес процесса на примере процесса «Управления Инцидентами» в упрощённой схеме можно представить в следующей последовательности действий:

•Определение границ процесса

•Основные блоки процесса

•Детализирование блоков, разбивка на под-процессы

•Определение участников процесса и их роли

•Размещение документов, инструментов и действий над ними

•Определить метрики эффективности и механизмы измерений

•Связать схему с другими процессами и схемами (если таковые имеются)

•Проверить полученный бизнес процесс «тест на столе», с привлечением сотрудников ИТ и пользователей

•Утвердить процесс со стороны владельца бизнеса и передать на внедрение

Модели Деловой Активности (Patters of Business Activities PBA)

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

Частота (Frequency) — Как часто используется сервис

Объемы (Volume) — объем активных действий, связанных с сервисом

Продолжительность (Duration) — продолжительность активных действий, связанных с сервисом

Место (Location) — определяет локацию (географическая точка, департамент и т п), где происходит активность,

Модели Деловой Активности также включают в себя профили пользователей (User Profile), который представляет из себя модель поведения пользователей сервиса.

Кроме выше сказанного, в модели деловой активности следует включать:

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

•возможности «обходных» решений при полном отказе ИТ сервисов. Обзор возможности ведения бизнеса при частичном или полном отказе ИТ инфраструктуры на определённые промежутки времени (час, день и т п).

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

Модель деловой активности Банка

Модель деловой активности Банка можно описать следующим образом:

Деятельность банка тесно связана с функционированием ИТ инфраструктуры.

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

Компьютерные системы банка часто централизованы.

Деятельность банка жестко регламентируется со стороны контролирующих органов.

Высокие требования по вопросам физической безопасности.

Высокие требования по вопросам информационной безопасности.

Высокие требования к системам обеспечения ИТ инфраструктуры.

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

Время работы банка регламентируется, обычно пятидневная рабочая неделя, с 09:00 до 18:00. Оставшееся время может использоваться для проведения регламентных ИТ работ (создание резервных копий, архивирования, восстановления, проведение профилактических работ и т п)

Наличие филиальной сети банка, географически распределенной по территории страны.

Наличие сети банкоматов банка и POS терминалов.

Можно выделить основные бизнес приложения банка:

Автоматизированная Банковская Программа (Automated Banking System ABS, Core Banking System SBS) — предназначена для ведения основной операционной деятельности организации. Характеризуется наличием механизма «закрытия дня» (Close of Business CoB) — фиксированием состояния операций. Система может иметь в своем функционале различные дополнительные возможности.

Бухгалтерская программа (Accounting System AS) — система ведения бухгалтерского и налогового учета, и т п. Как правило, операции бухгалтерии отстают по времени от основной операционной деятельности банка. Разделение ABS и AS систем требует настройка «однонаправленной» интеграции данных.

Специализированные платежные системы (такие как SWIFT, SWIFT/AZIPS, HOHKS, APUS и т п) или терминалы платежных систем (Western Union, Contact и т п)

Системы Интернет банкинга и системы онлайн оплат.

Системы управления клиентами (CRM)

Системы управления организацией (ERP)

Наличие веб сайта

Профили пользователей и активности могут представлять из себя:

Разделение по группам с фиксированными правами и доступами

Жесткие ограничения на использование почты, интернета и систем конечных пользователей

Модель деловой активности Страховой компании

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

Деятельность страховой компании тесно связана с функционированием ИТ инфраструктуры.

Значительная часть сотрудников страховой компании работает с различными компьютерными системами (Автоматизированной Страховой Программой и т п).

Компьютерные системы страховой компании часто централизованы.

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

Повышенные требования по вопросам физической безопасности.

Повышенные требования по вопросам информационной безопасности.

Повышенные требования к системам обеспечения ИТ инфраструктуры.

Повышенные требования по вопросам непрерывности предоставления ИТ сервисов.

Время работы страховой компании регламентируется, обычно пятидневная рабочая неделя, с 09:00 до 18:00. Оставшееся время может использоваться для проведения регламентных ИТ работ (создание резервных копий, архивирования, восстановления, проведение профилактических работ и т п)

Наличие филиальной или агентской сети страховой компании, географически распределенной по территории страны.

Можно выделить основные бизнес приложения страховой компании:

Автоматизированная Страховая Программа (Automated Insurance System AIS) — предназначена для ведения основной операционной деятельности организации. Система может иметь в своем функционале различные дополнительные возможности.

Бухгалтерская программа (Accounting System AS) — система ведения бухгалтерского и налогового учета, и т п. Как правило, операции бухгалтерии отстают по времени от основной операционной деятельности банка. Разделение ABS и AS систем требует настройка «однонаправленной» интеграции данных.

Интеграция с системами онлайн оплат.

Системы управления клиентами (CRM)

Системы управления организацией (ERP)

Наличие веб сайта

Профили пользователей и активности могут представлять из себя:

Разделение по группам с фиксированными правами и доступами

Модель деловой активности отелей (Hospitality)

Модель деловой активности отелей можно описать следующим образом:

Деятельность банка связана с функционированием ИТ инфраструктуры.

Часть сотрудников отелей работает с различными компьютерными системами (Система Управления Отелем Property Management System PMS, и т п).

Компьютерные системы отеля частично централизованы.

Базовые требования по вопросам физической безопасности.

Базовые требования по вопросам информационной безопасности.

Базовые требования к системам обеспечения ИТ инфраструктуры.

Базовые требования по вопросам непрерывности предоставления ИТ сервисов.

Время работы отеля, обычно пятидневная рабочая неделя, с 09:00 до 18:00. Оставшееся время может использоваться для проведения регламентных ИТ работ (создание резервных копий, архивирования, восстановления, проведение профилактических работ и т п)

Можно выделить основные бизнес приложения отелей и ресторанов:

Автоматизированная Система Учета Номерного Фонда (Property Management System PMS) — предназначена для ведения основной операционной деятельности организации. Характеризуется наличием механизма прозрачного «закрытия дня» (Close of Business CoB) — фиксированием состояния операций. Система может иметь в своем функционале различные дополнительные возможности.

Бухгалтерская программа (Accounting System AS) — система ведения бухгалтерского и налогового учета, и т п. Как правило, операции бухгалтерии отстают по времени от основной операционной деятельности банка. Разделение ABS и AS систем требует настройка «однонаправленной» интеграции данных.

Специализированные системы, такие как Point of Sales POS и платежные терминалы

Системы Интернет регистрации номеров, системы онлайн оплат и системы резервации.

Системы управления клиентами (CRM)

Системы управления организацией (ERP)

Наличие веб сайта

Соответствие требованиям стандартов и требований франшизы и т п

Профили пользователей и активности могут представлять из себя:

Разделение по группам с фиксированными правами и доступами

Жесткие ограничения на использование почты, интернета и систем конечных пользователей

Предоставление клиентам доступа в интернет свободный или с тарификацией, гарантированная полоса пропускания

Модель деловой активности производственной компании

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

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

Большая часть сотрудников работает без взаимодействия с компьютерными системами

Компьютерные системы частично централизованы или обособленны.

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

Повышенные требования по вопросам физической безопасности.

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

Можно выделить основные бизнес приложения предприятия:

Профили пользователей и активности могут представлять из себя:

Модель деловой активности компании Розничной торговли (Retail)

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

Можно выделить основные бизнес приложения предприятия:

Профили пользователей и активности могут представлять из себя:

Заключение

Суммируем все выше сказанное. С первой страницы главы и после первого определения BPM становится понятно, что ничего не понятно. Терминология и ее значение трактуется по-разному как в течении времени существования самого подхода, так и производителями «чудо» решения. В дополнение к основному термину, время от временя вводятся новые модные словечки: BPA (Business Process Automation или Business Process Analysis), BAM (Business Activity Monitoring), реинкарнация BPM (но уже как Business Process Monitoring) или же BPPM (Business Process Performance Management). Объединение глянцевых, «блестящих» словечек: Business Process Reengineering (BPR), Corporate Performance Management (CPM), Enterprise Performance Management (EPM), Strategic Enterprise Management (SEM) и прочие великое множество. Более детально об этом можно прочитать у Ricardo Passchier в «BPM — Великая Вавилонская путаница». Даже такой корифей в этой области профессор Шеер путается в определениях и назначении ARIS (один из лидеров систем в области управления процессами).

На мой взгляд построение бизнес процессов — это правильно. Подход типа — купим BPM/BPPM/BPMS/BPA/SEM…, наберем студентов отличников и все у нас будет великолепно — ересь. Для описания бизнес процессов компании любой сложности необходимо три инструмента: карандаш, бумага и голова. Если с первые два компонента в компаниях в избытке, то с третьим обычно наблюдается постоянная нехватка. Основной компонент — люди, работающие в данной сфере, имеющий как теоретическую базу, так и практический опыт в той или иной области бизнеса. Наибольший эффект от коллективной работы сотрудников как «вертикальной» (разные уровни иерархии), так и «горизонтальной» (сотрудники различных подразделений) составляющей организации. Первый этап — перенос на бумагу того, что имеем или создаем. Визуальное отображение процесса помогает лучше понять все аспекты его деятельности. Так же это поможет ИТ перенести процессы на язык машин. На начальном этапе можно использовать любое офисное приложение или бесплатное решение, которое позволяет «рисовать квадратики и кружочки». Все. Далее внедряем, непрерывно отслеживаем результат и вносим изменения.

Специфическое программное обеспечение может понадобится в дальнейшем, при росте количества процессов, их повторное использование и т п. Кроме этого ряд информационных систем (ERP) имеет в своем функционале графические редакторы или программные средства, позволяющие моделировать бизнес процессы и выполнять их. Некоторые решения умеют «читать» бизнес процесс (файл определённого формата), и мгновенно использовать его. Так на пример Microsoft System Center 2016 имеет возможность моделировать процессы (в собственном встроенном редакторе) и исполнять его. При этом нет необходимости в разработчиках ПО. Все это упрощает и ускоряет время реакции компании на изменения рынка.

Концепция Информационных Систем Управления (MIS) и интеграции данных

Общие Положения

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

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

Причины появления Автоматизированных Систем Управления (АСУ)

Рассмотрим для примера работу небольшой компании по продаже бананов. Имеется штат офисных сотрудников каждый из которых выполняет свои функциональные обязанности: менеджер по продажам ведет учет покупателей, логистик — учет доставки, бухгалтер — учет и т п. У каждого из есть компьютер с установленным офисным приложением, например, Microsoft Excel — «убийца ERP систем». Подразумевается навыки хорошего владения продуктом, что для бухгалтеров «старой закалки» являлось нормой. У тех, чей уровень знания Excel ниже, локально на компьютере установлена подходящая программа. Ведение учета, построение сложной аналитики, предоставление отчетов руководству. Помощник руководителя, собирает отчеты у менеджеров, формирует консолидированные отчеты и отправляет руководству. Пересчитать себестоимость по FIFO или LIFO, придумать новую формулу расчета скидок, сценарии продаж и т п. — «без проблем»: быстро, не дорого и правильно. Не одна ERP с целым штатом консультантов, на мощных серверах и огромными расходами не сможет быстрее и правильнее. Все идет прекрасно, контора растет, до того момента пока:

•один человек перестает справляется, и требуется совместное редактирование Excel файлов двум и более сотрудникам

•Возможности Excel ограничены

•Потребность в скорости обмена актуальными данными возрастает

Минусы автономной работы стали перевешивать плюсы и тормозить бизнес. Нужно что-то делать?

Потребность в автоматизации управленческих процессов впервые была осознана в конце 60-х — начале 70-х годов, когда стало ясно, что управление крупной корпорацией подчиняется тем же законам, что и любая бюрократическая структура. Один из законов Паркинсона гласит: «штат организации никак не связан с объемом выполняемой ею работы». Иными словами, с ростом численности управленческого персонала КПД его работы падает до нуля.

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

Категории Информационных Систем Управления (Management Information Systems)

Назначение Автоматизированных Систем Управления:

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

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

Основные термины и определения приводятся в Словаре APICS. Именно в этом издании содержится наиболее полное и точное определения систем:

MPS (Master Planning Schedule)

Хорошо известная методология «объемно-календарного планирования». Является базовой практически для всех планово-ориентированных методологий. Применяется в основном в производстве, но также может использоваться и в других отраслях бизнеса, например, дистрибуции.

MRP (Material Requirements Planning) — Автоматизированное планирование потребности сырья и материалов для производства

Методология планирования потребности в материальных ресурсах, заключающаяся в определении конечной потребности в ресурсах по данным объемно-календарного плана производства. Ключевым понятием методологии является понятие «разузлование», т. е. приведение древовидного состава изделия к линейному списку (Bill of Materials), по которому планируется потребность и осуществляется заказ комплектующих. Ее усовершенствованная версия, Closed Loop MRP (планирование потребности в материалах в замкнутом цикле), позволила динамически корректировать планы закупок при возникновении нештатных отклонений от них.

CRP (Capacity Requirements Planning) — Планирование производственных ресурсов

Данная концепция схожа с MRP, но вместо единого понятия состава изделия она оперирует такими понятиями, как «обрабатывающий центр», «машина», «рабочие ресурсы», ввиду чего технически реализация CRP более сложна. Обычно применяется совместно с MRP ввиду тесной логической связи при планировании. Методологии MRP/CRP применяются в АСУП производственных предприятий.

FRP (Finance Requirements Planning) — Планирование финансовых ресурсов

MRPII (Manufacturing Resources Planning)

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

•сырьем,

•материалами,

•оборудованием,

•трудозатратами.

•Планирование производства.

Интегрированная методология, включающая MRP/CRP и, как правило, MPS и FRP. При использовании данной методологии обязательно подразумевается анализ финансовых результатов производственного плана. Устраняет серьезный недостаток MRP: суть которого в том, что, рассчитывая потребность в материалах, не учитываются производственные мощности, их загрузку, стоимость рабочей силы и т. д. Концепция MRP II позволял планировать все производственные ресурсы предприятия (сырье, материалы, оборудование, персонал и т. д.). Впоследствии концепция MRP II развивалась, и к ней постепенно добавлялись возможности по учету остальных затрат предприятия — появилась концепция ERP (Enterprise Resource Planning — Планирование ресурсов предприятия), называемая иногда также планированием ресурсов в масштабе предприятия (Enterprise-wide Resource Planning).

Развитием концепций автоматизированного управления занимается американская некоммерческая организация APICS (American Production and Inventory Control Society). По стандарту APICS, MRP II включает следующие функции:

•Sales and Operation Planning — Планирование продаж и производства

•Demand Management — Управление спросом

•Master Production Scheduling — Составление плана производства

•Material Requirement Planning — Планирование потребностей в сырье и материалах

•Bill of Materials — Спецификации продукции

•Inventory Transaction Subsystem — Складская подсистема

•Scheduled Receipts Subsystem — Отгрузка готовой продукции

•Shop Flow Control — Управление производством на цеховом уровне

•Capacity Requirement Planning — Планирование производственных мощностей

•Input/output control — Контроль входа/выхода

•Purchasing — Материально-техническое снабжение

•Distribution Resource Planning — Планирование запасов сбытовой сети

•Tooling Planning and Control — Планирование и управление инструментальными средствами

•Financial Planning — Финансовое планирование

•Simulation — Моделирование

•Performance Measurement — Оценка результатов деятельности

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

Стандарт MRP II делит сферы отдельных функций (процедур) на два уровня:

•Необходимый

•Опциональный

Для того, чтобы программное обеспечение было отнесено к классу MRP II, оно должно выполнять определенный объем необходимых (основных) функций (процедур). Некоторые поставщики ПО приняли различный диапазон реализаций опциональной части процедур этого стандарта. Результаты использования интегрированных систем стандарта MRP II:

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

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

•решение задач оптимизации производственных и материальных потоков;

•реальное сокращение материальных ресурсов на складах;

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

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

•финансовое отражение деятельности предприятия в целом;

•значительное сокращение непроизводственных затрат;

•защита инвестиций, произведенных в информационные технологии;

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

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

ERP (Enterprise Resources Planning) — Управление ресурсами предприятия

К свойствам MRPII добавилось управление финансовыми ресурсами, маркетинг. ERP концепция — первая направленная на управление бизнесом, а не только производства, как MRP. Концепция бизнес-планирования. Под ERP подразумевается «интегрированная» система, выполняющая функции, предусмотренные концепциями MPS-MRP/CRP-FRP. Важным отличием от методологии MRPII является возможность «динамического анализа» и «динамического изменения плана» по всей цепочке планирования. Конкретные возможности методологии ERP существенно зависят от программной реализации. Концепция ERP более «размыта», чем MRPII. Если MRPII имеет явно выраженную направленность на производственные компании, то методология ERP оказывается применимой и в торговле, и в сфере услуг, и в финансовой сфере. Класс ERP, в отличие от MRP и MRP II, для которых имеются строгие определения и формализованные перечни требований, описан только на уровне концепции. Поэтому утверждения о том, что-такая-то система относится к классу ERP, строго говоря, является рекламным утверждением, или, в лучшем случае, экспертным заключением.

В основе ERP лежит концепция ERP: принцип создания единого хранилища данных (repository), содержащего всю деловую информацию, накопленную организацией в процессе ведения деловых операций, включая финансовую информацию, данные, связанные с производством, управлением персоналом, или любые другие сведения. Это устраняет необходимость в передаче данных от системы к системе. Кроме того, любая часть информации, которой располагает данная организация, становится одновременно доступной для всех работников, обладающих соответствующими полномочиями. Концепция ERP стала очень известной в производственном секторе, поскольку планирование ресурсов позволило сократить время выпуска продукции, снизить уровень товарно-материальных запасов, а также улучшить обратную связь с потребителем при одновременном сокращении административного аппарата. Стандарт ERP позволил объединить все ресурсы предприятия, таким образом, добавляя управление заказами, финансами и т. д. Когда в список учитываемых при планировании ресурсов добавились другие, в частности, финансовые, появился термин ERP (Enterprise Resource Planning) — планирование ресурсов в масштабе предприятия.

Различие между концепциями MRP II и ERP заключается в том, что первая ориентирована на производство, а вторая — на бизнес. Например, такие вещи, как условия кредитования заказчика по отгрузке готовой продукции, попадают в поле зрения ERP, но не MRP II. Инструментарий OLAP, средства поддержки принятия решений — принадлежности ERP, но не MRP/MRP II систем.

В соответствии со Словарем APICS, термин «ERP-система» может употребляться в двух значениях:

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

•Во-вторых, (в более общем контексте), это — методология эффективного планирования и управления всеми ресурсами предприятия, которые необходимы для осуществления продаж, производства, закупок и учета при исполнении заказов клиентов в сферах производства, распостранения и оказания услуг.

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

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

•управление спросом и формирование планов продаж и производства. Эти функции предназначены для прогноза спроса и планирования выпуска продукции;

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

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

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

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

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

ERP не является вершиной эволюции. Фундаментальное ограничение систем ERP: они автоматизируют внутреннюю деятельность предприятия так называемый «back-office».

CSRP (Customer Synchronized Resources Planning) — Управление, ориентированное на взаимодействие с клиентами

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

Концепция CSRP — Customer Synchronized Resource Planning (Планирование ресурсов, синхронизированное с покупателем) — охватывает также и взаимодействие с клиентами: оформление наряд-заказа, тех задание, поддержка заказчика на местах и пр. Таким образом, если MRP, MRP-II, ERP ориентировались на внутреннюю организацию предприятия, то CSRP включил в себя полный цикл от проектирования будущего изделия, с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Основная суть концепции CSRP в том, чтобы интегрировать Заказчика (Клиента, Покупателя и пр.) в систему управления предприятием. То есть не отдел сбыта, а сам покупатель непосредственно размещает заказ на изготовление продукции — соответственно сам несет ответственность за его правильность, сам может отслеживать сроки поставки, производства и пр. При этом предприятие может очень четко отслеживать тенденции спроса и т. д. На расширение функциональности на сферу взаимодействия предприятия с его заказчиками нацелена концепция CSRP. Корпоративные ресурсы, охватываемые CSRP-системой, обслуживают такие этапы производственной деятельности, как проектирование будущего изделия с учетом специфических требований заказчика, гарантийное и сервисное обслуживание.

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

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

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

ERPII (Enterprise Resource & Relationship Processing) — Управление внутренними ресурсами и внешними связями предприятия

Новая ревизия концепции ERP. Можно считать, что, ERPII=ERP+CRM+SCM. Пока что данный класс применяется нечасто. Основная идея ERP II заключается в выходе за рамки задач по оптимизации внутренних процессов организации: кроме интеграции таких традиционных для ERP систем областей деятельности предприятия, как управление финансами, бухгалтерский учет, управление продажами и покупками, отношения с дебиторами и кредиторами, управление персоналом, производство, управление запасами, системы класса ERP II позволяют управлять взаимоотношениями с клиентами, цепочками поставок, вести торговлю через Интернет. По определению, данному Gartner Group ERP II, — это бизнес-стратегия предприятия, принадлежащего к определенной отрасли, и набор ключевых для данной отрасли приложений, помогающих клиентам и акционерам компаний увеличивать стоимость бизнеса за счет эффективной ИТ-поддержки и оптимизации операционных и финансовых процессов как внутри своего предприятия, так и во внешнем мире — в рамках сотрудничества с другими корпорациями. Основная идея ERP II заключается в выходе за рамки задач по оптимизации внутренних процессов организации: кроме интеграции таких традиционных для ERP систем областей деятельности предприятия, как управление финансами, бухгалтерский учет, управление продажами и покупками, отношения с дебиторами и кредиторами, управление персоналом, производство, управление запасами, системы класса ERP II позволяют управлять взаимоотношениями с клиентами, цепочками поставок, вести торговлю через Интернет. Функции и преимущества систем, которые реализованы в ERPII:

•Управление взаимоотношениями с клиентами (CRM).

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

•Электронная коммерция.

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

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

Электронная коммерция. Для продвижения своего бизнеса в Интернет необходимо, прежде всего, выстроить и отработать свои бизнес процессы до открытия Интернет представительства. Отсутствие «надежного тыла» становиться серьезной проблемой для компании. Это обусловлено тем, что при обычной схеме работы задача часто решается следующим образом: создается каталог продукции с описанием товаров и интерактивной формой заказа, клиент заказывает товар и ждет его доставки. Однако зачастую, осуществляя заказ, клиент, да и сами менеджеры, не имеют понятия, есть ли товар на складе и в случае отсутствия, сколько времени понадобится, чтобы доставить товар на склад, а затем переправить его клиенту. Более того, если единожды компания осуществляла специальный заказ для клиента, данные об этом не сохраняются, и при вторичном заказе компания вновь обрабатывает его как новый. Это приводит к простоям, затягивает сроки доставки заказов, что, в конечном счете, влечет за собой полное разочарование клиентов. Функциональность систем ERP II, в свою очередь, позволяют контролировать склад, закупки и поставки и организовывать систему работы оптимальным образом. Помимо оптимизации рабочих процессов, решения ERP II позволяет создать клиентскую базу, хранить и анализировать данные по предпочтениям. Компания также получают возможность прогнозировать сроки последующих заказов постоянных покупателей и предоставлять более персонализированный сервис, что служит выработке приверженности покупателей к сотрудничеству и установлению длительных отношений с клиентами. Таким образом, использование ERP-систем при ведении электронной торговли позволяет компаниям добиться преимущества по отношению к конкурентам. С появлением на рынке систем ERP II, ориентированных на средние предприятия, компании получают возможность развивать торговые площадки в Интернет, которые оптимально будут отвечать их нуждам — обеспечивать электронный документооборот, контролировать движение заказов и т. д. Это позволит компаниям использовать свои Интернет — ресурсы для взаимодействия с поставщиками или дистрибьюторами. Использование систем класса ERP II в данном случае позволяет оптимизировать процессы, как закупок, так и продаж. Информация о заказах, полученных через Интернет, интегрируется с данными склада, отделов доставки, продаж, сервисных центров, что позволяет создать единый профиль клиента, эффективно обрабатывать заказы и быстро отвечать на них, создавать и хранить данные обо всех его обращениях, анализировать их и прогнозировать новые обращения. Клиент, в свою очередь, отправив заказ через Интернет — представительство, получает возможность контролировать процесс обработки заказа: автоматическое уведомление о его принятии и начале работы, данные о подготовке заказа, когда его заявка получена складом, сведения об отгрузке, когда заказ сформирован и отправлен, а также пакет необходимых документов. Аналогично используется система при закупках. Менеджер по закупкам через систему получает доступ к каталогу товаров поставщика, выбирает необходимые товары и отправляет заказ. Возможны варианты, когда система автоматически формирует заказ на покупку, учитывая оптимальные объемы закупок, текущие потребности, необходимые сроки поставки и в стандартном формате пересылает поставщику. Система у поставщика обрабатывает полученный заказ, вычисляет срок поставки и посылает уведомление о ходе выполнения заказа.

SCM (Supply Chain Management) — Управление отношениями с поставщиками

Управление цепочками поставок. Концепция SCM придумана для оптимизации управления логистическими цепями и позволяет существенно снизить транспортные и операционные расходы путем оптимального структурирования логистических схем поставок. Концепция SCM поддерживается в большинстве систем ERP- и MRPII-класса.

CRM (Customer Relationship Management) — Управление отношениями с заказчиками

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

PLM (Product Lifecycle Management) — управление жизненным циклом продукта

CAD/CAM/САЕ/PDM (Computer Aided Design / Computer Aided Manufacturing / Computer Aided Engineering / Project Data Management)

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

MES (Manufacturing Execution System) Система управления производственными процессами

Специализированное прикладное программное обеспечение, предназначенное для решения задач синхронизации, координации, анализа и оптимизации выпуска продукции в рамках какого-либо производства. Существует несколько формулировок определения MES систем. MES — информационная и коммуникационная система производственной среды предприятия (определение APICS). MES — автоматизированная система управления и оптимизации производственной деятельности, которая в режиме реального времени: инициирует, отслеживает, оптимизирует, документирует производственные процессы от начала выполнения заказа до выпуска готовой продукции (определение MESA International). MES — интегрированная информационно-вычислительная система, объединяющая инструменты и методы управления производством в реальном времени. MES-системы относятся к классу систем управления уровня цеха, но могут использоваться и для интегрированного управления производством на предприятии в целом. Функции c-MES:

•RAS (Resource Allocation and Status) — контроль состояния и распределение ресурсов.

•DPU (Dispatching Production Units) — диспетчеризация производства (координация изготовления продукции).

•DCA (Data Collection/Acquisition) — сбор и хранение данных.

•LUM (Labor/User Management) — управление людскими ресурсами.

•QM (Quality Management) — управление качеством.

•PM (Process Management) — управление процессами производства.

•PTG (Product Tracking & Genealogy) — отслеживание и генеалогия продукции.

•PA (Performance Analysis) — анализ эффективности.

•Advanced Planning & Scheduling (APS) — составления производственных расписаний в рамках всего предприятия,

•Enterprise Asset Management (EAM) — отвечает за управление техническим обслуживанием и ремонтами.

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

SCADA (Supervisory Control and Data Acquisition System) — система сбора данных и оперативного диспетчерского управления технологических процессов

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

сбор данных о контролируемом технологическом процессе;

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

B2C (Business to Customer) и B2B (Business to Business)

обозначения широких классов программных продуктов, обслуживающих взаимоотношения предприятий с покупателями (B2C) и между собой (B2B). Пример B2C-системы — онлайновый интернет-магазин. К классу B2B относятся SCM и CSRP-решения. Технологии B2B в настоящее время переживают настоящий бум. Аналитики соревнуются в предсказании астрономических сумм, которые будут потрачены на них в ближайшие годы. Этот бум связан с вступлением развитых стран в постиндустриальный период. Во все больших масштабах крупные корпорации стремятся избавляться от производства, оставляя за собой исследования, проектирование, маркетинг и продажи. Производство же размещается на фабриках, расположенных в странах с дешевой рабочей силой, и являющихся независимыми предприятиями-подрядчиками. Понятно, что такая схема ведения бизнеса невозможна без совершенных B2B-систем.

OLAP (Online Analytical Processing — аналитическая обработка данных в реальном времени)

Представляет собой мощную технологию обработки и исследования данных. Системы, построенные на основе технологии OLAP, предоставляют практически безграничные возможности по составлению отчетов, выполнению сложных аналитических расчетов, построению прогнозов и сценариев, разработке множества вариантов планов. В основе работы OLAP системы лежит обработка многомерных массивов данных. Многомерные массивы устроены так, что каждый элемент массива имеет множество связей с другими элементами. Чтобы сформировать многомерный массив, OLAP система должна получить исходные данные из других систем (например, ERP или CRM системы), или через внешний ввод. Пользователь OLAP системы получает необходимые данные в структурированном виде в соответствии со своим запросом. Исходя из указанного порядка действий, можно представить структуру OLAP системы. В общем виде, структура OLAP системы состоит из следующих элементов:

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

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

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

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

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

•реляционные базы данных. Эти базы данных используются при совместной работе OLAP системы с CRM системой или ERP системой. Данные хранятся на сервере этих систем в виде реляционных баз данных или хранилищ данных. OLAP сервер обращается к этим базам данных для формирования необходимых многомерных структур и проведения анализа.

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

В зависимости от метода хранения и обработки данных, все OLAP системы могут быть разделены на три основных вида:

•ROLAP (Relational OLAP — реляционные OLAP системы) — этот вид OLAP системы работает с реляционными базами данных. Обращение к данным осуществляется напрямую в реляционную базу данных. Данные хранятся в виде реляционных таблиц. Пользователи имеют возможность осуществлять многомерный анализ как в традиционных OLAP системах. Это достигается за счет применения инструментов SQL и специальных запросов. Одним из преимуществ ROLAP является возможность более эффективно осуществлять обработку большого объема данных. Другим преимуществом ROLAP является возможность эффективной обработки как числовых, так и текстовых данных. К недостаткам ROLAP относится низкая производительность (по сравнению с традиционными OLAP системами), т. к. обработку данных осуществляет сервер OLAP. Другим недостатком является ограничение функциональности из-за применения SQL.

•MOLAP (Multidimensional OLAP — многомерные OLAP системы). Этот вид OLAP систем относится к традиционным системам. Отличие традиционной OLAP системы, от других систем, заключается в предварительной подготовке и оптимизации данных. Эти системы, как правило, используют выделенный сервер, на котором осуществляется предварительная обработка данных. Данные формируются в многомерные массивы — OLAP кубы. MOLAP системы являются самыми эффективными при обработке данных, т. к. они позволяют легко реорганизовать и структурировать данные под различные запросы пользователей. Аналитические инструменты MOLAP позволяют выполнять сложные расчеты. Другим преимуществом MOLAP является возможность быстрого формирования запросов и получения результатов. Это обеспечивается за счет предварительного формирования OLAP кубов. К недостаткам MOLAP системы относится ограничение объемов, обрабатываемых данных и избыточность данных, т. к. для формирования многомерных кубов, по различным аспектам, данные приходится дублировать.

•HOLAP (Hybrid OLAP — гибридные OLAP системы). Гибридные OLAP системы представляют собой объединение систем ROLAP и MOLAP. В гибридных системах постарались объединить преимущества двух систем: использование многомерных баз данных и управление реляционными базами данных. HOLAP системы позволяют хранить большое количество данных в реляционных таблицах, а обрабатываемые данные размещаются в предварительно построенных многомерных OLAP кубах. Преимущества этого вида систем заключаются в масштабируемости данных, быстрой обработке данных и гибком доступе к источникам данных.

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

•WOLAP (Web OLAP). Вид OLAP системы с поддержкой web интерфейса. В этих системах OLAP есть возможность обращаться к базам данных через web интерфейс.

•DOLAP (Desktop OLAP). Этот вид OLAP системы дает возможность пользователям загрузить на локальное рабочее место базу данных и работать с ней локально.

•Mobile OLAP. Это функция OLAP систем, которая позволяет работать с базой данных удаленно, с использованием мобильных устройств.

•SOLAP (Spatial OLAP). Этот вид OLAP систем предназначен для обработки пространственных данных. Он появился как результат интеграции географических информационных систем и OLAP системы. Эти системы позволяют обрабатывать данные не только в буквенно-цифровом формате, но и в виде визуальных объектов и векторов.

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

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

•проведение многовариантного анализа. Применение OLAP системы позволяет получить множество сценариев развития событий на основе набора исходных данных. За счет инструментов анализа можно смоделировать ситуации по принципу «что будет, если».

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

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

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

ABS (Automated Banking System, Core Banking System) — Автоматизированная Банковская Программа

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

Классификация Управления Организацией

Функционально Ориентированная Организация Управления

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

•Слабые горизонтальные связи между функциональными структурными единицами,

•Сильные вертикальные линии связи внутри одной функциональной структуры, типа «начальник-подчиненный».

Подчиненный отвечает только за порученные ему функции и, возможно, за деятельность своего подразделения в целом. Функции и результаты работы параллельных структурных единиц его не очень интересуют. Данные структурируются по функциональному назначению структурных подразделений компании. Как пример, для небольшой компании в качестве ИТ решения может быть выбрано решение 1С «Бухгалтерия» для ведения хозяйственной деятельности, бухгалтерского и Управленческого учета. Все остальные функциональные подразделения используют данное решение для автоматизации операционной деятельности исходя из имеющегося функционала. Для крупной компании для финансового департамента может быть выбрано решение, например, Программа 1С конфигурация «Бухгалтерия», а для Отдела Кадров выбрано решение 1С конфигурация «Управление Сотрудниками», отвечающие требованиям подразделений.

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

Процесс Ориентированная Организация Управления

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

•Горизонтальные связи между структурными единицами при таком подходе сильнее

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

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

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

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

Классификация Информационных Систем с точки зрения ИТ

Функционально Ориентированная Информационная Система

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

•Текущая система удовлетворяет требования большинства подразделений компании

•Имеется наработанная практика работы с программой со стороны бизнеса

•Имеется наработанная практика работы с программой со стороны ИТ (баги, ошибки, навыки сопровождения и т п)

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

•Постановка технического задания по имеющимся функциям

•Постановка технического задания по новым функциям

•Реинжиниринг бизнес процессов для адаптации к новой системе

•Наличие ресурсов для внедрения и сопровождения

•Как новое решение вписывается в имеющуюся ИТ инфраструктуру

•План внедрения новой информационной системы без прерывания бизнеса

•План миграции информации из старой системы в новую

•Обучение персонала

•Вопросы по поддержке

•План восстановления бизнеса на случай не удачного внедрения проекта

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

•Расходы на внедрение новой системы (как прямые, так и косвенные расходы времени и денег)

•Не удобство для пользователей (интерфейс другой, формы и процессы могут отличатся значительно)

•Возрастания количества ошибок и проблем во времени эксплуатации системы пользователями (не знают, ошибки и т п)

•Время устранения проблем со стороны ИТ увеличивается (ИТ не имеет навыков по сопровождению системы)

•Вопросы по миграции данных из старой системы в новую

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

Как результат, скорее всего будет принято решение, по приобретению отдельного решения с имеющимся функционалом, удовлетворяющим требования отдела продаж. Например, Microsoft Navision CRM.

Некоторые преимущества данного решения будут:

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

•Расходы по внедрению значительно ниже

•Уровень всех потенциальных проблем снижается по причине уменьшения масштаба влияния

•При провале проекта, отдел продаж продолжит работать с имеющейся системой

•Нет необходимости в миграции данных

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

•Содержит необходимый функционал для обеспечения работы

•Обычно более проста и понятна для внедрения и использования

•Процесс внедрения проще за счет меньшего масштаба внедрения

Недостатки:

•Сопровождение потенциально большего количества информационных систем

•Вопросы по интеграции большего количества информационных систем между собой

•Требует большего распыления ИТ ресурсов

•Требования по знанию различных систем

Процесс Ориентированная Информационная Система

Теперь рассмотрим особенности Процесс ориентированного подхода к управлению организацией, и его влияние на построении ИТ инфраструктуры компании. Информационная система предприятия выбирается исходя из анализа бизнес процессов, происходящих в компании. Как написано в предыдущей главе, компания описывает бизнес процессы как основные, так и вспомогательные. Полнота описания процессов и их точность позволит выбрать наиболее правильное решение. Так для примера, была выбрана система «Microsoft Dynamics Navision» или 1С Конфигурация Управление Предприятием» покрывающая требования всех имеющихся бизнес процессов. Также в процессе роста организации могут возникнуть потребности в новом функционале, и требовании интеграции имеющегося решения с новой системой.

Преимущества выбора Процесс Ориентированной Информационной Системы:

•Содержит необходимый функционал для обеспечения работы компании на протяжении всего жизненного цикла

•Сопровождение меньшего количества информационных систем (потенциально единая система в организации)

•Вопрос по интеграции информационных систем между собой не актуален или не критичный

•Не требует распыления ИТ ресурсов

•Нет требований по знанию большого количества различных систем

Недостатки:

•Более высокая первоначальная стоимость решения за счет большего функционала

•Риски внедрения и сопровождения выше, так как является основной для бизнеса, относительно сложной и т п

«Эталонная» Информационная Система (Management Information System)

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

•Единая Универсальная Информационная Система, построенная по модульному принципу, совмещающая в себе как функциональный, так и процессный подходы.

Преимущества Единой Информационной Системы:

•Все преимущества Процесс Ориентированной Информационной Системы

•За счет модульности, первоначальная стоимость внедрения и последующее сопровождение значительно дешевле

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

•Снижаются риски при внедрении и сопровождении нового функционала

•Единая информационная система от одного производителя более надежна, безопаснее и управляема

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

Модели Интеграции Информационных Систем

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

•«Точка — точка» (Point-to-point) наиболее простая модель, использует прямое соединение систем между собой

•«ХАБ» (Hub & Spoke) представляется в виде центрального элемента, соединенного с различными системами

•«ЛЕС» (Spaghetti) — модель соединения всех систем со всеми

•«Интеграционная Шина Предприятия» (Enterprise Service Bus) общая «шина» данных для интеграции систем между собой, представляет из себя как правило самостоятельную систему.

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

•Периферийные системы (Front-end) — решения специфической операционной деятельности, или требует установку локально для взаимодействия с различными аппаратными решениями на местах (станки, кассовые аппараты и т п)

•Механизм интеграции данных (Integration) — механизмы интеграции данных

•Ключевые системы (Back-end) — конечные системы, решение консолидации и обработки данных

•Системы консолидации (OLAP & BI) — решение консолидированной аналитики и отчетов

Типы направлений интеграции потоков данных:

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

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

Комплексная Интеграции Информационных Систем Предприятия

Принимая во внимание общую концепцию построения Системы Управления Бизнесом (Management Information System), вопросы интеграции различных Информационных Систем между собой является неизбежным «злом». Задача ИТ знать об этом и быть готовым снизить риски и негативное влияние на бизнес и ИТ Архитектуру Предприятия. При построении комплексной интеграции предприятия необходимо принять во внимание структуру организации. Модель интеграции Информационных Систем полностью зависит от структуры организации. Интеграция ИС Предприятия может происходить на различных уровнях:

Интеграция различных информационных систем на организационном уровне:

•в пределах одной компании

•в пределах портфеля

•в пределах холдинга

Интеграция различных информационных систем на уровне бизнеса деятельности:

•По функциям (департаментам),

•По процессам

•По сфере деятельности

Интеграция различных информационных систем на технологическом уровне:

•инфраструктуры,

•платформы

•приложений

•базы данных

•данных

Степень Интеграция различных информационных систем:

•Частичная или Полная

•Ручная или автоматизированная

•Одно направленная или двух направленная

Рассмотрим более детально различные варианты интеграции с применением различных механизмов и типов.

Вариант 1: Интеграция двух информационных систем в масштабе одной компании

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

Все основные бизнес процессы происходят в АБС (создание клиентов, выдача кредита, все виды наличных оплат, в том числе и не банковского назначения, поступления переводов по погашению кредитов и т п). Транзакции из АБС выгружаются один раз при операции закрытии дня (Close of Business).

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

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

Подход к интеграции должен выполнятся ТОЛЬКО С ПРИМЕНЕНИЕМ ПРОЦЕССНОГО ПОДХОДА!!!

Вариант 2: Интеграция двух информационных систем в масштабе одной компании

В качестве периферийной информационной системы выступает Автоматизированная Банковская Система (ABS), в качестве конечной системы программа ведения бухгалтерского учета (ACCOUNTING).

Интеграции «двух направленного» типа с использованием механизма «Точка-точка» на уровне «Приложения» осуществляется между «ABS» и «ACCOUNTING».

Все основные бизнес процессы происходят в АБС (создание клиентов, выдача кредита, все виды наличных оплат, в том числе и не банковского назначения, поступления переводов по погашению кредитов и т п). Транзакции из АБС выгружаются один раз при операции закрытии дня (Close of Business).

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

Как пример пересекающихся процессов: новый поставщик вводится в «Бухгалтерии», там же проводятся кассовые операции и т п. Регистрация товара от поставщика производится там же и т п. Данные по новому клиенту пересылаются в систему АБС.

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

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

Вариант 3: Интеграция информационных систем различных компаний, объединённых в портфель или холдинг

Каждая компания имеет собственное ERP решение. Задача ИТ обеспечить сбор данных с различных систем в холдинг для последующего анализа и формирования отчетов для руководства. Для этого в холдинге развернута система OLAP & BI и система хранения данных (Data Warehouse DWH). Для обеспечения интеграции данных будет использоваться решение ESB «шина».

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

•относительная простота внедрения и сопровождения

•не высокая стоимость решения

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

•внедрение может проходить последовательно, и как следствие не потребует значительных человеческих ресурсов

К недостаткам решения можно отнести следующие:

•Система обладает только возможностями создания отчетов и аналитики.

•Точность и достоверность информации зависит от ввода данных на местах.

•Нет возможности интерактивного влияния на бизнес процессы в компаниях.

Вариант 4: Интеграция информационных систем различных компаний, объединённых в портфель или холдинг

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

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

В первой компании (самая верхняя), текущая система управления не позволяет реализовать требования холдинга. В этом случае, компания использует решение «PRC» у себя в компании. Преимущества — единое решение, простота внедрения. К недостаткам можно отнести то, что данные в системе «PRC» не как не связаны с внутренней системой ERP компании.

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

И третий случай — (компания, расположенная по середине). В компании имеется собственное решение ERP в которой имеется полный набор функций, требующих реализацию политики «Проведения тендера и закупок». Компания продолжает использование собственной программы, полностью интегрировав с решением «PRC».

Интеграции Информационных Систем Предприятия и централизация ИТ

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

Инфраструктура как Сервис (IaaS)

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

Процесс может происходить с минимальными рисками воздействия на информационные системы компаний. Данная модель подходит для начального этапа централизации ИТ или же для уровня холдинга, с различными направления деятельности, когда информационные системы кардинально различаются по своей функциональности (например, Автоматизированная Банковская Система АБС, система Управления Сельскохозяйственным Предприятием УСХП, Система управления отелями и ресторанами и т п). Результаты можно увидеть непосредственно после интеграции.

Платформа как Сервис (PaaS)

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

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

Программа как Сервис (SaaS)

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

Данные каждой компании хранятся в единой информационной системе холдинга. Преимущества данного решения — помимо всех преимуществ IaaS и PaaS предоставляет единую информационную систему холдинга. Каждая компания является частью холдинга. Информация по справочникам, номенклатуре, плану счетов унифицирована имеется возможность формирования консолидированных (суммированных по статьям) отчетов. Возможность интерактивного воздействия в процесс управления (авторизация и т п) со стороны руководства портфеля или холдинга. Данная модель подходит для финального этапа централизации ИТ. Как и для предыдущей модели, крайне важно ответить на два вопроса: первый — в чем цель и конечный результат, и второй — иметь четкую диаграмму всех бизнес процессов организации в целом, и компаний в частности. Для реализации данного плана, необходима заинтересованность руководства холдинга, поддержка руководства на местах, и тесная интеграция специалистов бизнеса и ИТ, хорошо разбирающихся в деталях процессов, происходящих в компании. Переход на унифицированную платформу, может потребовать значительные финансовые инвестиции и временные рамки, как для анализа, так и для поэтапного внедрения. Результаты интеграции будут видны только в долгосрочной перспективе. Данный этап характерен высоким риском в процессе интеграции. Кроме этого, процесс вывода компании из состава организации или холдинга может быть так же достаточно сложным и болезненным. Процесс доработки функционала для каждой компании, общий для всех компаний.

Проблемы выбора ИТ-решения для Бизнеса

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

Так при выборе Информационной Системы сугубо технического направления (защита периметра, системы Антивирусной защиты и т п) или общего назначения (Сервис предоставления файлов в совместное использование, системы почтовых сообщений и т п), выбор решения фактически полностью зависит от технических специалистов в области ИТ или Информационной Безопасности. Они говорят на одном «языке»; разбираются в особенностях решений, требованиям предъявляемых к системам и т п. Взаимодействие с бизнесом минимальное. Бизнес требования со стороны бизнеса могут быть сформулированы одним предложением: «… чтобы можно было посылать и принимать почту…». Как видно из рисунка, «вершина айсберга» — бизнес требования видны сотрудникам организации лишь часть общих требований к системе.

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

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

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

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

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

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

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

Рекомендации по выбору Информационной Системы Управления

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

Критерии выбора ИТ решения

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

Какие цели?

Какие процессы необходимо контролировать?

Размер организации: (Small Business, Medium Business, Large Business)

Заявленные возможности продукта или решения.

Удовлетворяют ли заявленные возможности требованиям бизнеса?

Техническая Архитектура:

•Архитектура решения: (client-server, Client-Application Server-Database Server)

•Серверная платформа: (Cloud based, Windows, Linux, Others)

•Варианты установки: (Cloud based или On-premises)

•Поддержка виртуализации: (Physical only, Hyper-V, VMware, Others)

•Поддерживаемые базы данных: (Microsoft SQL, MySQL, Internal DB)

На стороне клиента:

•Поддерживаемые устройства на клиенте: (Windows, Linux, Android, Mac OS, iPhone/iPad, Web-based)

•Поддерживаемые языки интерфейса: (Single English, Multi-Languages, Customer)

Архитектура отказоустойчивости и доступности

Архитектура восстановления и архивирования

Возможности масштабирование решения

Как данное решение вписывается в общую ИТ архитектуру.

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

Оценка производителей и поставщиков решений (Рейтинг, Наличие локального партнера (продажа / поддержка)

Модель внедрения:

•Стоимость: (Free (Open-Source), One-time payment, Monthly payment, Annual subscription, Perpetual)

•Лицензирование: (Per servers, Per hosts, Per operators/agents, Per modules, Per users, Per CPU/core, Per modules)

•Варианты подписки и версий

Модель сопровождения: (Technical support, Update support)

•Стоимость: (Free, Annual fee, Basic Technical support, Local support, Remote support)

•Лицензирование

•Возможности по обновлению продукта: (Update patches, Upgrade packs, Re-installation)

Возможности интеграции: с имеющимися решениями, с потенциально возможными решениями

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

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

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

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

Этапы выбора ИТ решения

Можно определить следующий порядок действий по ИТ проекту.

На первом этапе:

•Сбор требований со стороны бизнеса — инициатора проекта (бизнес требования)

•Добавление технических требований со стороны департамента Безопасности

•Добавление технических требований со стороны ИТ департамента

На втором этапе:

•Поиск решений, без ограничений по стоимости, архитектуре и т п.

•Сбор заявленных возможностей решения

На третьем этапе:

•Анализ решений (со стороны бизнеса) на соответствие бизнес требованиям

•Анализ решений (со стороны ИТ департамента) на соответствие требованиям, архитектуре и т п

•Формирование «короткого» списка решений удовлетворяющих всем требованиям. При необходимости проводится обращение к департаменту Снабжения для получения предложений

На четвертом этапе:

•Детальный анализ решения, выбор архитектуры, производителя, определение бюджета и т п

•Принятие решения по бюджету, срокам (со стороны бизнеса)

•Формирование технического задания для проведения тендера

•Формирование плана внедрения (частичное, полное и т п)

•Выбор «короткого» списка победителей

•Уточнение последних изменений и дополнений

•Финальный тендер (по необходимости) для «короткого» списка компаний

На пятом этапе:

•Закупка

•Подготовка к внедрению

•Внедрение

•Корректировка

•Сопровождение

•Обновление и улучшение

•Вывод из эксплуатации

Метод Покупки Готового Решение (COST или «OFF-the-SHELF»)

COST или («OFF-the-SHELF» коробочное готовое решение) — Одним из подходов является покупка готовых решений. При покупке такого программного обеспечения организация должна:

•понимать достоинства и недостатки этого подхода;

•формализовать процесс выбора наиболее эффективного готового решения;

•определить процесс для эффективной интеграции и настройки готового решения;

•определить функциональные требования на приемлемом уровне;

•сформировать перечень управленческих и операционных требований;

•определить требования к продукту и поставщику;

•определить требования к интеграции услуги.

При покупке решения остается необходимость в:

•кастомизации (customization) — адаптация продукта под требования клиента, первоначальное конфигурирование, настройка интерфейса, изменение бизнес процессов и т п,

•локализация (localization) — язык интерфейса, перевод печатных форм и т п.

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

К недостаткам можно отнести — менее гибка, чем разработка собственных решений.

Концепция Информационной Безопасности

Общие Положения

Данный раздел содержит основные принципы архитектуры и информационной безопасности которые должны быть приняты во внимание. Раздел основывается на международных стандартах и практиках в области информационной безопасности, таких как PCI DSS, NIST серии 800-хх, Information Security Forum (ISF).

Необходимо определить приоритеты по критериям (Confidentiality, Integrity and Availability CIA):

•Конфиденциальность (Confidentiality)

•Целостность (Integrity)

•Доступность (Availability)

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

Принцип Единого Информационного Пространства

Все ИТ систем являются частью единого информационного пространства (часть леса, дерева, домена, сети и т п).

Хранение информации и ИТ активов

Все критически важная информация должны хранится в дата центре компании. Критически важные ИТ системы и вычислительные ресурсы так же должны быть расположены в дата центре компании.

Классификация информации и ИТ активов

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

Обязательные требования для обеспечения конфиденциальности:

•Классификация данных.

•Наличие политики определяющий уровни доступа.

•Наличие процедур по работе с данными каждого класса.

Классификации данных может быть построена на основе следующих условий:

•Требования устанавливаются регулирующими органами.

•Требования определяются внутри компании.

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

•Доступ к данным предоставляется по принципу «минимальных привилегий»

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

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

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

Тип данных — Бизнес информация или же техническая.

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

Классификация данных по ИБ — (коммерческая тайна, внутреннего пользования и т п). Данные по клиентам, которые могут быть переданы компаниям компании или нет. (контактные данные клиентов отелей могут быть интегрированы в единую систему управления клиентами (CRM) и в дальнейшем использоваться в маркетинговых целях для поиска потенциальных клиентов и т п)

Происхождение данных — Данные являются первичными, извлечены из бизнеса системы или же являются производными после проведения аналитических вычислений. Как пример имена, и контактная информация клиентов (Hospitality) может рассматриваться как первичные данные, а список потенциальных клиентов для Retail Group проанализированный в системе (Hospitality) по ряду показателей (платежеспособность, количество потраченных средств, поведения клиента и т п) может рассматриваться как производные данные.

Источник данных — Веденный вручную оператором и наименование системы.

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

Определение потоков данных

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

Идентификация пользователя

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

Классификация по группам доступа и ролям

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

Процесс предоставления прав доступов и членства в группах

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

Принцип Минимальных Привилегий

При предоставлении права и доступов всем пользователям ИТ систем и сотрудникам ИТ необходимо руководствоваться правилами «минимальных привилегий».

Использование лицензионного программного обеспечения

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

Организация процесса Информационной Безопасности

Ключевые компоненты

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

•Должны участвовать как минимум Бизнес департаменты компании, департамент Внутренний Аудит, департамент Безопасности, Финансовый департамент, департамент Управления Рисками, департамент Отдел Кадров и ИТ департамент или подразделения исполняющие их функции.

•Организационная структура компании должна должным образом управлять «конфликтом интересов» департаментов

•Бизнес департаменты определяют классификацию информации в соответствии с бизнес процессами

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

•Департамент Безопасности предоставляет рекомендации по вопросам Информационной Безопасности

•Департамент Управления Кадрами обеспечить обучение и ознакомление работников с информацией касательно Информационной Безопасности

•Департамент Внутреннего Аудита проводит анализ на соответствие нормам и процедурам, а также необходимый мониторинг

•Департамент Безопасности обеспечивает физическую защиту ИТ активов

•Департамент Безопасности ведет мониторинг активности, связанной с ИБ

•ИТ департамент обеспечивает защиту и управление ИТ активами

•ИТ департамент разрабатывает необходимую документацию

Разделения Обязанностей в рамках организации

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

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

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

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

Преимущества данного подхода:

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

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

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

Модели Информационной Безопасности и защиты данных

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

В качестве основных моделей можно выделить следующие:

•Bell La Padula — модель (многоуровневой) защиты конфиденциальности. Построенная на модели «информационных потоков». Модель конечных автоматов, которая реализует аспекты защиты конфиденциальности на основе матрицы «Субъект-объект» с применением трех основных правил:

Simple Security Rule: Субъект НЕ МОЖЕТ ЧИТАТЬ данные на более высоком уровне.

Star Property Rule: Субъект НЕ МОЖЕТ ЗАПИСАТЬ данные на более низком уровне.

Strong Property Rule: Субъект МОЖЕТ ЧИТАТЬ и ЗАПИСАТЬ данные только на своем уровне.

•Biba — модель защиты целостности. Построенная на модели «информационных потоков». Модель использует сетку целостности. Основные принципы модели:

Integrity Axiom: Субъект НЕ МОЖЕТ ЗАПИСЫВАТЬ на верх

Simple Integrity Axiom: Субъект НЕ МОЖЕТ ЧИТАТЬ данные находящиеся на нижнем уровне

Invocation property: Субъект НЕ МОЖЕТ ЗАПРАШИВАТЬ обслуживание (call) у другого субъекта, находящегося на более высоком уровне.

•State Machine Model — модель защиты безопасности, основанной на состояниях (state).

•Information Flow Model — модель защиты

•Clark Wilson — модель защиты целостностью. Выполняет три основные цели:

Предотвращает изменения не авторизованного пользователя

Предотвращает выполнение не корректных изменений

Обеспечивает согласованность «правильные транзакции»

Вводит понятия:

«пользователь»,

«Transformation Procedure TP»

«Constrained Data Item CDI», UDI, IVP etc

Access Triple: «Субъект — программа TIP — объект CDI»

Внесение изменений только через TIP. IVP поддерживает внутреннюю и внешнюю согласованность и разделение обязанностей.

•Модель «не влияния» — модель управления целостностью. Действия, происходящие на верхнем уровне, не влияют на сущность внизу. Обеспечивает защиту от «Interference Attack» атак.

•Модель сетки «Lattice» — модель защиты, построенная на основе групп.

•Brewer & Nash «Китайская стена» — модель управления доступом и защиты конфликтов интересов. Построенная на модели «информационных потоков». Основной принцип:

Если пользователь имеет доступ к данным «А», то автоматически запрет на доступ к данным «Б»

•Модель Graham — Denning — модель управления целостностью. Опирается на набор прав (8 команд), которые субъект может выполнить над объектом. Список команд:

Create object

Create subject

Delete

Read rights

Provide & delete rights

•Модель Harrison Ruzzo Ulman — модель управления правами доступов субъектов.

•Дискретное Управление Доступом (Discretionally Access Control DAC) — управление доступом на основе списков управления доступом (ACL). Обычно является задачами администратора. Относительно простое в плане администрирования. Требует высокий уровень формализации организации.

•Мандатное Управление Доступом (Mandatory Access Control MAC) — управление доступом на основе меток доступа. К таким меткам могут относится метки «секретно», «конфиденциально», принадлежность к проекту или функции и т п. Обычно управляется владельцем. Относительно простое в плане реализации и безопасности. Сложно управлять в централизованной модели и требует высокий уровень осведомленности владельцев ресурсов. Основаны на модели защиты конфиденциальности «Bell La Padula».

•Ролевое Управление Доступом (Role Based Access Control RBAC) — управление доступом на основе ролей и членства в группах. Обычно управляется администратором. Является наиболее распространённым в различных современных системах корпоративного управления. Гибкая (гранулярная) система предоставления доступов. Один из недостатков, наличие супер-администратора, с полным доступом к ресурсам и необходимости детальной проработки ролей.

•Атрибутное Управление Доступом (Attribute based Access Control ABAC) — Представляет из себя предоставление доступов, на основе статических или динамических правил, связанных с атрибутами (времени суток, расположения, членства в группе и т п) объекта и субъекта доступа. Основной недостаток — сложность реализации и контроль за состоянием доступа. Наиболее передовая с точки зрения обеспечения информационной безопасности.

Уровни доступа и управления ИТ активами

Используется преимущественно модель на основе предоставления контроля по Ролям (Role Based Access Control (RBAC). Такой подход реализован практически во всех ИТ системах.

Уровни доступа к Информации

Используется комбинированная модель на основе предоставления контроля по Ролям (Role Based Access Control (RBAC)) с Дискретным Распределением прав (Discrete Access Control (DAC)) к файловым ресурсам. Такие возможности реализованы практически во всех современных ИТ системах.

Уровни доступа к Информации (дополнительный)

Для обеспечения более избирательного и доступа к информации и контроля может понадобится дополнительный специфические ИТ решения с использованием модели (MAC), метки уровня доступа и категорий, а также правил ABAC.

Матрица Контроля Доступов (Access Control Matrix)

Матрица контроля доступов, а также классификация и категоризация объектов (информации) является ключевыми элементами обеспечения Информационной Безопасности.

Требование к процессу управления данных

Различают три основных состояния данных:

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

Данные в перемещении (Data in motion) — должны быть должным образом зашифрованы при передаче на конечные системы

Данные в использование (Data in use) — должны использоваться только на соответственно подготовленных устройствах и авторизированными пользователями или системами.

Основные концепции движения информации

Движение информации можно разделить по следующим типам:

Вертикальная (North-South) — Данные перемещаются между уровнями, к примеру, от компании в портфель, из портфеля в компания.

Горизонтальная (West-East) — Данные перемещаются в пределах одного уровня, к примеру, между одной компанией в другую в одном портфеле.

С низу в верх (Button-Up) — Направление движения данных с низу в верх, к примеру, от компании в портфель, от портфеля в компания.

С верху в низ (Top-Down) — Направление движения данных с верха в низ, к примеру, от портфеля в компанию, от компании в портфель.

Зоны доверия (Trust Zone) — формируются как логические зоны в пределах одной компании (доверительная зона компании), в пределах одного портфеля (доверительная зона портфеля) или компании (доверительная зона компании) или же внешняя (за пределы компании) зона. Зоны доверия могут быть как «горизонтальные» (несколько филиалов одной компании), так и «вертикальные» (несколько компаний одного портфеля).

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

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

•Данные «Внутреннего использования» могут передаваться от компании в портфель, как горизонтально, так и вертикально в обоих направлениях в пределах информационного пространства компании (корпоративная почта, информационная система и т п).

•Данные «Конфиденциальные» могут передаваться:

горизонтально — внутри компании в обоих направлениях (работник — руководитель при наличии у обоих соответствующего уровня доступа «Конфиденциальные»)

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

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

Данные «Конфиденциальные» не могут передаваться:

горизонтально — между компаниями одного портфеля (доверительная зона портфеля) даже при наличие соответствующего уровня доступа «Конфиденциальные» у обоих)

Вертикально — внутри компании в направлении с верху в низ (руководитель — работник при отсутствии у последнего соответствующего уровня доступа «Конфиденциальные»)

вертикально — в направлении с верху вниз, в пределах одной зоны доверия (доверительная зона портфеля) при отсутствии соответствующего уровня доступа «Конфиденциальные» у пользователя в компании.

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

Порядок развертывания ИТ инфраструктуры с позиции ИБ

При проектировании, внедрении и сопровождении ИТ сервисов можно рассмотреть следующую модель поведения:

«базовый сценарий» — внедрение решения и его конфигурация в соответствии с практиками. Основная мысль — соблюдение принципов «Парето» (20 процентов усилий решают 80 процентов задач). Рассматривается как основной при внедрении ИТ сервисов.

«оптимальный сценарий» — в процессе внедрения и сопровождения, можно оптимизировать решение как с точки зрения информационной безопасности, так и с точки зрения оптимизации стоимости.

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

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

«дуракам везет» — сценарий, при котором, по каким-либо причинам явно нарушены основные принципы информационной безопасности.

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

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

•Мотив (Motive — WHY). Мотивация для совершения преступления. В качестве мотиваций может служить недовольство сотрудников, получение финансовой прибыли и т п. Как пример можно предположить недовольство системного администратора условиями работы, оплаты и т п.

•Условия (Means — HOW). Наличие необходимых условий, для совершения преступления. Подразумевается наличие технических возможностей для совершения действий. Так, например, системный администратор имеет возможность по смене пароля пользователя и затем просмотр его почты. Наличие мотива и условий, не достаточны для совершения преступления.

•Возможности (Opportunity — WHEN+WHERE). Совпадение благоприятных условий для совершения преступления. Так для нашего примера, отсутствие политик по смене пароля, профилактика, отсутствие систем сбора и обработки логов и т п.

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

Контроли управления по защите информации

Общие положения

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

Административные (Administrative) — административные меры по обеспечению информационной безопасности

•Наличие формальных документов в области информационной безопасности

•Соблюдение формальных требования информационной безопасности

•Проведение обучения и семинаров для сотрудников организации

Физические (Physical) — физические элементы по обеспечению информационной безопасности

•Физическая безопасность помещений дата центра и серверных комнат

•Физическая безопасность серверов

•Физическая безопасность рабочих компьютеров

Технические (Technical/Logical) — технические аспекты по обеспечению информационной безопасности

•Контроль за физическими носителями информации (шифрование носителей),

•Включение персонального фаервола

•Установка средств антивирусной защиты

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

Директивный (Directive) — команды и информирование по предотвращение появления угроз (плакаты, предупреждения).

Превентивные (Preventative) — обеспечивают предотвращение появления угроз.

Сдерживающие (Deterrent) — создают сдерживающие факторы, предотвращающие появление угрозы

Детективные (Detective) — определяю угрозу, имеющуюся в вашей системе

Корректирующие (Corrective) — обеспечивают снижение воздействия угрозы

Восстановительные (Recovery) — обеспечивают восстановление элементов безопасности. Как пример наличие отказоустойчивости и т п

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

На приведенной таблице показаны основные четыре фазы и какие меры и технические решения можно отнести к какой из них:

Кроме этого необходимо оценивать контроли по следующим атрибутам:

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

Доступ (Access) — Какие доступы необходимо получить для обхода контроля

Привилегии (Privilege) — какие привилегии (возможности) получит преступник, при обходе контроля.

Методы проведения теста на проникновение

Проведение теста на проникновение позволяет оценить состояние информационной безопасности организации, как с технической точки зрения, так и с точки зрения готовности сотрудников и процессов организации. Тестирование может проводится для проверки как конкретного решения (интернет банкинга, сайта и т п), готовность сотрудников департаментов ИТ и Безопасности (Red Team Testing), или всей организации. Обычно проводится с привлечением компаний, имеющих опыт по проведению данных тестов, классифицированный персонал, методику и технические средства. В качестве методик проведения теста на проникновение могут быть использованы:

•OISSG

•OSSTMM

•NIST Guideline on Network Security Testing

•ISACA Testing IT Systems Security

•Cybersecurity VAMs

•OWASP Testing Guide

•Собственные методики

Основные десять видов угроз по спецификации OWAST top 10:

•Injections

•Broken Authentication & Session Management

•CSS / XSS

•Insecure Direct Object References

•Security Misconfiguration

•Sensitive Data Exposure

•Missing Function Level Access Control

•CSRF / XSRF — Подделка межсайтового запроса

•Using components with known vulnerabilities

•Invalidated Redirects & Forwarding

Резервное копирование и архивирование данных

Политики резервного копирования и архивирования одни из важнейших элементов защиты данных в организации.

Классическое правило резервного копирования и архивирования данных известное как «3-2-1» подразумевает:

•Наличие трех (3) копий данных расположенных в разных местах

•Наличие двух (2) форматов / состояний данных

•Как минимум одна (1) копия данных располагается за пределами офиса

Следующее важное правило, которое необходимо соблюдать:

•Тестирование целостности файла резервного копирования или архива

•Тестирование возможности восстановления на целевой системе

Для грубого расчета объема для резервного хранилища можно принимать соотношение «Дата — Бэкап» 1:3.

Существуют следующие стратегии ротации резервных носителей при создания резервных или архивных копий:

Пользовательский (Customer)

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

«Дед — отец-сын» («Grandfather — Father — Son» GFS)

«Дед — отец — сын» («Grandfather — Father — Son» GFS) стратегия резервное копирование — выполняемая автоматически или полуавтоматически. Используется обычно по расписанию.

«Сын» — Ежедневная полная резервная копия данных на один носитель (файл, контейнер). Период защиты данных — дата последней резервной копии. Требует один носитель (контейнер) информации.

«Отец» — Предполагает наличие недельной полной резервной копия данных и ежедневных дифференциальных или добавочных копий данных. В качестве периода защиты выбирается двух недельный период. Требует наличие минимум шести (6) носителей (контейнер) информации. Позволяет восстановить данные каждой недели (2) и ежедневные данные последней недели (4).

Стратегия может быть рассчитана на месячный цикл. Для этого понадобится восемь (8) носителей информации: Позволяет восстановить данные конца месяца (1), еженедельные данные месяца (3) ежедневные данные последней недели (4).

«Дед» — Предполагает наличие месячной и недельной полной резервной копия данных и ежедневных дифференциальных или добавочных копий данных. В качестве периода защиты выбирается годовой период. Требует наличие минимум девятнадцати (19) носителей (контейнер) информации. Позволяет восстановить данные каждого месяца (12), еженедельные данные последнего месяца (3) ежедневные данные последней недели (4).

Ежедневный полный (Daily Full Backup) стратегия ежедневного полного резервного копирование данных с последующим сохранением. Требует наличие порядка (365) носителей (контейнер) информации или по количеству рабочих дней. Обычно применяется в финансовых организациях.

«Ханойская башня» («Tower of Hanoi»)

«Ханойская башня» («Tower of Hanoi») стратегия резервное копирование — выполняемая автоматически или полуавтоматически. Используется обычно по расписанию. Требует наличие нескольких наборов носителей данных. Количество наборов не регламентируется, но принимается обычно пять шесть комплектов.

«Стратегия 10 наборов»

«Стратегия 10 наборов» — стратегия резервное копирование — выполняемая автоматически или полуавтоматически. Используется обычно по расписанию. Требует наличие десяти наборов носителей данных из расчета сорока (40) недельного периода обращения. За каждым набором закрепляется один день недели. С каждым циклом происходит сдвиг наборов (например, если набор N1 закреплен за понедельником, набор N2 за вторником, то при смене цикла набор N1 сдвигается на вторник и т п).

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

Еще одним из важных моментов политики резервирования и архивирования является совместное использование политик резервного копирования и архивирования. Возможные варианты комплексного подхода:

•Каскадная — соблюдается последовательность: «Рабочий каталог — Резервная копия — Архивная копия»

•Независимая — рабочий каталог может являться одновременно источником для резервного копирования, так и архивирования.

Независимая модель позволяет соблюдать правило «3-2-1». Данные одновременно хранятся в двух разных местах и в различных форматах. Например, резервная копия хранится жестких дисках системы резервного хранения данных, а архивная копия на ленточных носителях. К недостаткам данной модели можно отнести необходимость более длительного окна для создания сначала резервной, а затем архивной копии.

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

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

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

Продумать отказоустойчивость самих систем резервирования и архивирования.

Политика резервного копирования и восстановления данных (Backup & Recovery Policy)

Политика резервного копирования одна из важнейших элементов защиты данных в организации.

Для формирования грамотной политики резервного копирования необходимо определить ряд входных параметров:

Источник данных

Тип данных

Состояние системы, сервиса или сервера

Конфигурация

Данные

Логи событий или аудита

Объем данных — максимальный объем данных

Утилизация данных

используемый объем данных,

характер поведения

прирост данных за определённый период

Объем изменений — характер изменений данных и предполагаемый объем измененных данных

Окно для проведения резервного копирования — отрезок времени для выполнения резервного копирования

Требуемые характеристики:

Объект Восстановления (Recovery Point Objective RPO) — целевая точка восстановления, определяющая объем данных или времени допустимый для потери (дневные изменения и т п)

Время Восстановления (Recovery Time Objective RTO) — целевое время восстановления, определяющее время, необходимое для восстановления данных или сервиса.

Уровень Восстановления (Recovery Level Objective RLO) — целевой уровень восстановления, определяющий на каком уровне необходимо восстановить данные или систему (например, восстановление состояния сервера или сервиса, восстановление данных СУБД или файлов, частичное или полное восстановление).

Триггер срабатывания — механизмы включения резервного копирования: по расписанию, по изменениям.

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

Полное (Full Backup) резервное копирование — обеспечивает резервное копирование всей информации. Характеризуется долгим временем создания и восстановления. Требуется одна операция (создание или восстановление).

Резервное копирование накопленных изменений (Differential Backup) — обеспечивает резервное копирование информации изменившейся с момента создания полной резервной копии. Характеризуется относительно коротким временем создания и восстановления. Требуется две операция для восстановления (восстановление полной версии и изменений).

Резервное копирование добавочных или дневных данных (Incremental or Daily Backup) — обеспечивает резервное копирование информации изменившейся с момента создания последней резервной копии изменений. Характеризуется коротким временем создания и восстановления. Требуется 1 + N операций для восстановления (восстановление полной версии и последовательное восстановления всех изменений до необходимого момента).

Полная копия (Full Copy Backup) резервное копирование — обеспечивает резервное копирование всей информации, без изменения атрибута архивирования файлов. Характеризуется долгим временем создания и восстановления, но требуется одна операция (создание или восстановление). Производится в любой момент времени и не влияет на организацию процесса резервного копирования.

Композитное (Composite Backup) резервное копирование — обеспечивает резервное копирование изменений с возможностью создания полной резервной копии на любой момент времени. Характеризуется быстрым временем создания и восстановления. Обычно является функциональной возможностью специализированных программно-аппаратных решений по резервному копированию.

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

•Тип и частота резервного копирования зависит от бизнеса требований и функциональных особенностей сервиса

•Тип и скорость восстановления зависит от бизнеса требований и функциональных особенностей сервиса

•Ежедневное резервное копирование данных сервиса. Может включать в себя различные уровни такие как резервное копирование целиком виртуальных машин, так и/или данных.

Политика восстановления данных (Recovery Policy)

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

Пример расчета объема резервной копии данных

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

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

Рабочий объем характеризует коэффициент заполнения диска на 60%.

Резервная копия виртуальной машины по умолчанию выполняется по схеме:

5 Last Days (Differential) +1 Last Week (Full) + one Current Month (Full)

Дневной (D) — Различный (Differential Backup) 5 дней (понедельник-пятница): 5 х 1MB = 5MB один сервер.

Еженедельный (W) — Полный (Full Backup) 1 день (суббота): 1 х 60 GB = 60 GB один сервер.

Ежемесячный (M) — Полный (Full Backup) 1 день (конец месяца): 1 х 60 GB = 60 GB один сервер.

Полный объем резервной копии сервера за месяц: 25D +5W +1M = 75MB+300GB+60GB = 435GB

Полный Рабочий объем резервной копии с коэффициентом заполнения диска 60%: 435GB х 0.6 = 261GB

Полезный объем резервной копии сервера: 5D +1W +1M = 5MB+60GB+60GB = 125GB

Полезный Рабочий объем резервной копии с коэффициентом заполнения диска 60%: 125GB х 0.6 = 75GB

Резервная копия данных по умолчанию выполняется по схеме:

5 Last Days (Incremental) +1 Last Week (Full) + one Current Month (Full)

Для расчета на каждые 100GB данных при 10% изменениях (10GB) и 60% заполнением диска:

Дневной (I) — Различный (Incremental) 5 дней (понедельник-пятница): 5 х 10GB = 50GB один сервер.

Еженедельный (W) — Полный (Full Backup) 1 день (суббота): 1 х 100 GB = 100 GB один сервер.

Ежемесячный (M) — Полный (Full Backup) 1 день (конец месяца): 1 х 100 GB = 100 GB один сервер.

Полный объем резервной копии сервера за месяц: 25I +5W +1M = 250GB+500GB+100GB = 850GB

Полный Рабочий объем резервной копии с коэффициентом заполнения диска 60%: 850GB х 0.6 = 510GB

Полезный объем резервной копии сервера: 5I +1W +1M = 50GB+100GB+100GB = 250GB

Полезный Рабочий объем резервной копии с коэффициентом заполнения диска 60%: 250GB х 0.6 = 150GB

Для восстановления данных необходимо 390GB, для хранения резервных копий данных необходимо 590GB.

Общий полный рабочий объем пространства для хранения резервной копии сервера и данных 261GB+510GB = 771GB

Общий полезный рабочий объем пространства для хранения резервной копии сервера и данных 75GB+150GB= 225GB

Политика архивирования данных (Data Archiving Policy)

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

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

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

Архивные копии данных должны быть зашифрованы.

Безапелляционно доказывать неизменность данных с момента создания

Обеспечивать долгосрочное хранение информации

Обеспечивать возможность хранения вне организации, и вне ИТ инфраструктуре (внешние носители)

Пример расчета объема архивирования данных

Архивирование резервных копий серверов в течении 3 месяцев. Архивирование по умолчанию выполняется по схеме:

2 Months (previous months Full Backups)

Полный Рабочий объем пространства для хранения архивной копии виртуальной машины 2 х 72GB+261GB = 405GB

Полный Рабочий объем пространства для хранения архивной копии данных 2 х 60GB+510GB = 630GB

Полезный Рабочий объем пространства для хранения архивной виртуальной машины 75GB +2 х 36GB = 147GB

Полезный Рабочий объем пространства для хранения архивной копии данных 150GB +2 х 60GB = 270GB

Общий полный рабочий объем пространства для хранения архивной копии сервера и данных 405GB+630GB = 1035GB

Общий полезный рабочий объем пространства для хранения архивной копии сервера и данных 147GB+270GB= 417GB

Политика устаревания активов (Retention Policy)

Политика устаревая активов описывает организацию процесса удаления данных и списания ИТ активов. Основные цели политики:

•высвобождение мощностей хранилищ данных

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

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

•высвобождение вычислительных мощностей для новых технологий и сервисов

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

Технические аспекты Информационной Безопасности

Требование к физической безопасности

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

Требование к корпоративной сети

Требования к пропускной способности (минимальная, максимальная, ожидаемая)

управления адресами сети

Контроль трафика

Шифрование трафика критически важных приложений и систем

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

Корпоративная сеть отделена от публичной сети (интернета) по средствам Демилитаризованной зоны (DMZ)

Корпоративная сеть защищена по периметру техническими средствами и решениями, такими как фаервол (Next Generation Firewall (NGFW))

При необходимости фаервол защиты веб приложений (Web Application Firewall (WAF))

Системы Обнаружения и Предотвращения Вторжения (Intrusion Detection and Intrusion Prevention Systems (IPS/IDS)) должны быть соответственно настроены

Ресурсы публикуемые наружу должны быть размещены в Демилитаризованной зоне (DMZ)

Корпоративная сеть должна быть правильно сегментирована с учетом уровня портфелей и компаний

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

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

Трафика между клиентом и сервером должен шифроваться

Все сетевые устройства должны быть своевременно обновляться

При необходимости развернут комплекс мер по Защите от Утечки Данных (Data Leakage / Loss Prevention (DLP))

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

Требование к серверам и инфраструктуре виртуализации и систем хранения

Все сервера должны быть своевременно обновлены (обновления, прошивки)

На всех серверах должны быть включены и настроены локальные фаерволы

На все сервера должны быть установлены средства антивирусной защиты

Корпоративная сеть должна быть правильно сегментирована с учетом уровня портфелей и компаний

Серверный сегмент отделен от сегмента клиентов

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

Трафика между клиентом и сервером должен шифроваться

При необходимости развернут комплекс мер по Защите от Утечки Данных (Data Leakage / Loss Prevention (DLP))

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

Требование к системам конечных пользователей

Все системы конечных пользователей должны быть частью леса

На все системы конечных пользователей должны входить с учетными данными леса

Локальные диски всех систем конечных пользователей должны быть зашифрованы

Порты ввода / вывода (DVD, USB etc.) всех систем конечных пользователей должны быть под контролем или же деактивированы

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

На всех системах конечных пользователей должны быть включены и настроены локальные фаерволы

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

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

Пользователи не должны знать или использовать учетные записи с повышенными привилегиями

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

Трафика между клиентом и сервером должен шифроваться

При необходимости развернут комплекс мер по Защите от Утечки Данных (Data Leakage / Loss Prevention (DLP))

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

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

Средства и инструменты атак

KerbSniff & KerbCrack

Cain & Abel

Dsniff

Arp-sk

ARP Spoof

Nemesis

WireShark

Таблица угроз и видов атак

Denial of Service DoS

Dynamic Denial of Service DDoS

Flood — «Затопление». Различаются SYN Flood, ICMP Flood, DNS Flood

Bonk, Teadrop, Pong — Фрагментированные пакеты больших размеров приводящие к переполнению буфера и отказу систем.

SMURF — Ошибки реализации стека протокола TCP/IP.

Ping of DEATH (Jolt, SSPing)

UDP Storm — Шторм пакетов, настраивается как пересылка пакетов между двумя открытыми портами.

UDP Bomb — Некорректный UDP пакет.

LAND — Отправка пакета на определённый порт, но отправитель указывается тот же самый.

Mail Bombing

Sniffing — Прослушивание сети.

IP Hijack — Физическое или логическое «врезание» в канал связи.

Dummy DNS Server — Ложный DNS сервер.

Fuzzy — Подделка пакетов.

Puke — Фабрикует пакеты ответа ICMP unreachable на клиенте.

Fake unreachable — Тоже самое, что и Puke, но направлен на сервер.

Host spoofing — Подмена хоста

Password crack — Атаки направленные на взлом или перебор пароля.

Back connect / Pipes /Reverse

Software Vulnerabilities

Buffer Overflow — Использование ошибки переполнения буфера.

Shatter

Nuke — Атака на протокол NetBIOS (TCP, UDP 137, 138, 139).

Cross User Attack

CGI Attack

SQL Injection — Инжекция в SQL запросы

HTTP Resource Splitting (HRS)

Cross User Defacement

Web Cache Poisoning / Browser Cache Poisoning

Hijacking Pages

Cross Site Scripting / Exchange Site Scripting (CSS / XSS)

SQL Injection CSS (CIXSS)

SQL Injection HTTP Resource Splitting (SiHRS)

NULL Bute (Perl) — Специфика атак с использованием Perl

Include bute, PHP Include bute — Специфика атак на PHP

Hidden Fields

Man in the Middle Attack (MITM) — Атака через посредника.

Man in the Browser Attack (MITB) — Атака на Интернет банкинг

Заключение

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

•жесткая дисциплина

•непрерывное обучение и периодическое тестирование всех сотрудников организации без исключения

•контроль за изменениями

Концепция управления ИТ сервисами

Основные определения

Данный раздел содержит основные принципы управления ИТ сервиса на всем жизненном цикле сервиса. Концепция основывается на стандартах COSO, ITAF, Balanced Score Card, COBIT, ITIL, ISO 20000, ISO27000, ISO 17799, ISO9000, MOF. За основу взята «сервис ориентированный» подход к управлению ИТ. Процессный подход предполагает представление основных деятельностей ИТ в виде процессов, состоящих из действий.

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

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

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

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

•Процессы состоят из действий. Действие (Activity) — основные виды деятельности, предпринимаемые в рамках процесса.

Провайдеры сервиса — организационная единица, предоставляющая тот или иной сервис. Различают:

•Внутренний сервис провайдер — предоставляет сервис и включен в состав бизнеса

•Совместный сервис провайдер — предоставляет сервисы различным бизнес юнитам

•Внешний сервис провайдер — предоставляет сервисы различным клиентам

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

Требования бизнеса

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

Бизнес сервисы, имеющие непосредственное влияние на бизнес должны обладать первичным приоритетом.

Технические сервисы (Корневые и Первичные) нацелены на поддержание бизнес сервисов и приложений на надлежащем уровне.

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

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

Бизнес сервисы имеют первичный приоритет.

Технические сервисы (корневые и первичные) имеют первичный приоритет, и рекомендуется рассматривать в контексте максимальной доступности и надежности.

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

Фазы жизненного цикла ИТ сервиса

Согласно ITIL v3 определены следующие этапы (5) управления ИТ сервисами с использованием (26) процессов, (6) функций, а также (2) направления.

Модели ИТ архитектуры

ИТ архитектура организации может строится по нескольким моделям:

•«Децентрализованная» — Вычислительные мощности расположены по портфелям или компаниям организации.

•«Централизованная» — Вычислительные мощности расположены в дата центре холдинга, на периферии остаются «front-end» решения и службы поддержки пользователей.

•«Облачная» — Вычислительные мощности переносятся в «облако».

•«Смешанная» — Вычислительные мощности расположены как в дата центре холдинга, так и в облаке.

Модели предоставления ИТ сервисов

ИТ департамент компании ориентирован на предоставление различного уровня услуг. Определены следующие модели:

•Совместное размещение (Co-location IT assets) — ИТ ресурсы компаний размещены в дата центре. ИТ службы компаний самостоятельно управляют данными ИТ ресурсами.

•Инфраструктура как Сервис (Infrastructure as Service (IaaS)) — ИТ департамент предоставляет вычислительные ресурсы и инфраструктуру, которая включает в себя, но не ограничивается сеть, виртуализация, доступ в интернет, хостинг и т п. ИТ службы компании самостоятельно управляют ИТ ресурсами, расположенными на данных инфраструктурах.

•Платформа как Сервис (Platform as Service (PaaS)) — ИТ департамент предоставляет вычислительные ресурсы, инфраструктуру и платформу, которая включает в себя, но не ограничивается, хостинг, ERP платформа и т п. ИТ службы компаний самостоятельно управляют ИТ ресурсами, расположенными на данных платформах.

•Программы как Сервис (Software as Service (SaaS)) — ИТ департамент предоставляет вычислительные ресурсы, инфраструктуру, платформу и сами сервисы, которая включает в себя, но не ограничивается, корпоративная почта, Интрасети и т п. Компании являются пользователями данных услуг.

Типы предоставления сервисов

Типы предоставления сервисов определяются как на стратегическом этапе для ИТ стратегии в целом, так и для каждого сервиса в отдельности. Так в частности, при проектировании бизнес систем необходимо определиться с вопросом «купить» или «разрабатывать». Основные типы предоставления сервисов (Service Delivery Models) можно определить, как:

Insourcing

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

Преимущества:

•Прямой контроль

•Свобода выбора

•Быстрое создание прототипа и передовое обслуживание

•Удобные процессы и процедуры

•Применение специфики организации

Недостатки:

•Ограниченные ресурсы

•Может быть затратная в плане стоимости и времени выведения продукта на рынок

•Зависит от возможностей и уровня компетенции ресурсов организации

Outsourcing

Outsourcing — использование внешних ресурсов организаций, как полностью, так и частично на этапах жизненного цикла сервиса

Преимущества:

•Экономия масштаба

•Приобретение опыта и знаний

•Помогает организации сфокусироваться на основной деятельности

•Удобна при выполнении не системных задач

•Более формальный процесс тестирования новых продуктов

Недостатки:

•Меньший уровень непосредственного контроля

•Ограничения по выходу из проекта или изменению задач

•Риски, связанные с поставщиком продукта (платежеспособность, готовность продукта и т п)

•Неизвестность об уровне компетенции поставщика

•Более сложная модель организации

•Увеличивает долю проверки и соответствия продукта

Co-sourcing

Co-sourcing — комбинированное использование первых двух моделей

Преимущества:

•Снижает время выхода продукта на рынок

•Уверенность в уровне компетенции за счет выбора поставщика

•Высокий уровень контроля

Недостатки:

•Возможная сложность проекта

•Вопросы по защите интеллектуальной собственности

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

Partnership or Multi-sourcing

Partnership or Multi-sourcing — Формальное соглашение между организациями для совместной работы. Фокусируется на стратегическом партнерстве.

Преимущества:

•Снижает время выхода продукта на рынок

•Расширение рынка и выхода на него

•Взаимное получение выгоды

Недостатки:

•Сложность проекта

•Вопросы по защите интеллектуальной собственности

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

Business Process Outsourcing (BPO)

Business Process Outsourcing (BPO) — Формальное соглашение между организациями по частичному или полному переносу части бизнес функций.

Преимущества:

•Единая точка ответственности

•Передача риска

•Низкая стоимость передачи функций

Недостатки:

•Вопросы по защите интеллектуальной собственности

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

•Потеря бизнес знаний и связи с бизнесом по данному направлению

Application Service Provision (АРО)

Application Service Provision — Формальное соглашение между организациями по использованию вычислительных ресурсов.

Преимущества:

•Доступ к производительным ресурсам

•Относительно низкая стоимость

•Использование по требованию

Недостатки:

•Вопросы по защите интеллектуальной собственности

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

•Потеря знаний по данному направлению

Knowledge Process Outsourcing (KPO)

Knowledge Process Outsourcing (KPO) — Формальное соглашение между организациями по полному переносу процессов и функций в аутсорсинг. Наблюдается при необходимости иметь высокий уровень качества, сервиса и экспертизы по данному направлению деятельности, а также снижение или перенос рисков.

Преимущества:

•Доступ к специализированным специалистам, знаниям и опыту

•Относительно низкая стоимость

Недостатки:

•Вопросы по защите интеллектуальной собственности

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

•Потеря знаний по данному направлению

Направления деятельности по управлению ИТ сервисами

Различают следующие два направления деятельности по управлению ИТ сервисами:

Предоставление сервиса (Service Delivery). Формирование ИТ сервиса и передача его к использованию.

Сопровождение сервиса (Service Support). Сопровождение ИТ сервиса в процессе эксплуатации.

Предоставления Сервиса (Service Delivery)

Основные цели Предоставления Сервиса (Service Delivery):

•Удовлетворение бизнес целей (Satisfy Business Objects)

•Эффективная разработка по стоимости и в срок (Be efficiently development in time scale & cost)

•Определение и управление рисками (Identity & Manage Risks)

•Дизайн методов и метрик (Design methods & metrics)

•Уменьшение Стоимости Владения (Total Cost of Ownership)

•Улучшение качества предоставления ИТ сервисов

•Улучшение ИТ сервисов

•Упрощение внедрения новых ИТ сервисов и изменения имеющихся

•Более эффективная работа ИТ сервисов

•Улучшение управления ИТ и соответствия бизнесу

Деятельность по Предоставлению Сервиса включает в себя следующие процессы:

•Управление Финансами

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

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

•Управление Доступностью

•Управление Уровнем Обслуживания

Основные аспекты по Предоставлению сервисов:

•Новые сервисы и изменение в существующих

•Инструменты и системы управление сервисами, портфель сервисов и сервисный каталог

•Технологическая архитектура и системы управления

•Следование процессам

•Методики и метрики измерений

Сфера ответственности направления предоставления сервисов — это цепочка: Люди — Процессы — Продукты — Поставщики.

Поддержка сервиса (Service Support)

Основные цели Поддержки Сервиса (Service Support):

•Поддержание заявленного уровня сервиса

•Восстановление нормального состояния сервиса после сбоя

Основные линии Поддержки Сервиса:

•L0 — регистрация инцидентов или самостоятельное устранение

•L1 — начальный уровень поддержки пользователей

•L2 — технические специалисты по сервису

•L3 — технические эксперты по сервису

•L4 — поддержка производителя или профессионального сервиса

Деятельность по Поддержке Сервиса включает в себя следующие процессы:

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

•Управление Релизами

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

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

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

Основные аспекты по Поддержке Сервисов:

•Формирование функции Поддержки Пользователей (Service Desk).

•Принцип организации «Единой точки контакта» (Single Point of Contact SPOC)

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

Процесс Управления Непрерывностью ИТ Сервисов является ключевым процессом по предоставлению ИТ услуг компаниям.

Управление непрерывностью ИТ сервисов управляет способностью услуг и их компонентов к восстановлению.

Стратегия обеспечения непрерывности должна включать в себя все рассмотренные ниже способы восстановления. Различные услуги, используемые организацией, требуют различных подходов к восстановлению и уменьшению рисков сбоя. Какая бы опция ни выбиралась, она должна быть экономически эффективной. Главное правило — чем дольше бизнес может обходиться без услуги, тем дешевле должно быть решение по обеспечению ее непрерывности. Показатели RPO, RTO, RLO, SDO напрямую связаны со стоимостью решений восстановления. Управление непрерывностью сервиса должно отображать реальные требования и возможности бизнеса. Управление непрерывностью ИТ сервисов (Pass 77: 2006) включает в себя процессы:

•BCM (Business Continuity Management)

•BCP (Business Continuity Planning)

•BCP (Business Contingency Planning)

•DRP (Disaster Recovery Planning)

•CEM (Crisis & Emergency Management)

•RA & RM (Risk Analysis & Risk Management)

•BEA (Business Environment Analysis)

Затрагивает ИБ: ISO/IEC 27001, ISO 22301:2012

Определение Уровня Непрерывности Бизнеса (LBC Level of Business Continuity).

Кроме выше сказанного, необходимо наличие процесса Антикризисного управление.

Антикризисное управление (Crisis Management)

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

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

Управление непрерывностью фокусируется на значимых негативных событиях, которые ITIL называет «катастрофами» для бизнеса. Менее значимые события рассматриваются в рамках процесса Управления инцидентами. То, является ли какое-то конкретное событие катастрофой, зависит от организации, в которой оно произошло. Размер и значимость негативного влияния события на бизнес, например, финансовые потери или потеря репутации, измеряется в рамках Анализа влияния на бизнес. Анализ влияния на бизнес определяет минимальные требования к критичности, конкретные требования к технологиям и услугам определяются в рамках Управления непрерывностью.

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

Плана Сопровождения Бизнеса (Business Contingency Plan)

План определяет порядок реагирования на непредвиденные обстоятельства для обеспечения непрерывности бизнеса, и его корреляция с действиями ИТ. Фокусируется на текущем состоянии сервисов и не катастрофических воздействий. В данный план входят требования по доступности сервиса, управление мощностями и т п. Ключевые процессы при планировании непрерывности бизнеса являются Управление инцидентами (IM), управление проблемами (PM), управление изменениями и релизами (CM).

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

•Определение Точки Восстановления (Recovery Point Objective RPO)

•Определение Времени Восстановления (Recovery Time Objective RTO)

•Определение Уровня Восстановления (Recovery Level Objective RLO)

•Уровень Состояния Сервиса (Service Delivery Objective SDO)

•Определение Среднего Времени Работы до Отказа (MTBF)

•Определение Среднего Времени Работы на Отказ (MTTF)

•Наработка на отказ (OTF)

•Определение Среднего Времени между Отказами (OTBF)

•Определение Среднего времени на восстановление сервиса (MTTR partly) до уровня «as usual»

•Определение Среднего времени на полное восстановление сервиса (MTTR full)

•MTPoD (Maximum Tolerable Period of Disruption)

•Maximum Acceptable Outage (MAO)

•Maximum Allowable Downtime (MAD)

•Maximum Tolerable Downtime (MTD)

•Mean Time to Detect (MTTD) проблемы, нарушения

Определение Плана Восстановления после катастроф (Disaster Recovery Plan)

План определяет порядок действий по восстановлению работоспособности бизнеса и его корреляция с действиями ИТ. Ключевые процессы при планировании плана восстановления являются управление инцидентами (IM), управление чрезвычайными ситуациями (CEM),

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

•Определение Точки Восстановления (RPO), Времени Восстановления (RTO) и Уровня Восстановления (RLO)

•Уровень Состояния Сервиса (SDO)

•Определение Среднего времени на восстановление сервиса (MTTR partly) до уровня «as usual»

•Определение Среднего времени на полное восстановление сервиса (MTTR full)

Плана Непрерывности Бизнеса (Business Continuity Plan)

Тоже самое что и План Реагирования на непредвиденные обстоятельства (Business Contingency Plan), но фокусируется на непрерывности и восстановлении работы после катастроф. Данный план определяет восстановление бизнеса после значительного ущерба в следствии воздействия катастроф. В отличие от План Реагирования Бизнеса на непредвиденные обстоятельства, план может включать в себя стратегические изменения в каталог ИТ сервисов.

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

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

План обеспечения непрерывности бизнеса (Business Continuity Plan BCP) — план определяет шаги, необходимые для восстановления бизнес-процессов в случае нарушения их функционирования. План также должен содержать информацию о событиях, которые являются основанием для его инициирования; людях, которые должны быть задействованы в реализации плана; средствах коммуникаций и т. п.

Основные аспекты:

•Проведение BIA

•Определение превентивных мер

•Определение стратегии восстановление

•Определение плана Реагирования на воздействия

•Формирование команды по оценки ущерба

•Оценка ущерба

•Формирование команды по восстановление

•Выполнение плана восстановления

Для формирования и выполнения плана может понадобится наличие следующих команд:

•Команда по восстановлению (Restoration Team)

•Команда по оценке ущерба (Damage Assessment Team)

•Команда по спасению активов (Salvage Team)

Анализ сервисов и их влияние на бизнес (Business Impact Analysis BIA)

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

Анализ влияния на бизнес определяет:

форму, которую может приобретать разрушение или потеря:

•потерянный доход;

•дополнительные затраты;

•вред репутации;

•потеря благосклонности клиентов;

•потеря конкурентного преимущества;

•повреждение и нарушение здоровья, законности и безопасности;

•риск безопасности персонала;

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

•потеря операционных возможностей, например, контроля.

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

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

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

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

приоритеты восстановления для услуг.

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

•Уровень влияния на целевую систему

•Уровень Состояния Сервиса (SDO)

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

•Частичный отказ — Сервис продолжает работать благодаря 100% резервированию.

•Полный отказ — Полный отказ всей инфраструктуры.

Анализ сервисов и их влияние друг на друга (Service Failure Analysis SFA)

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

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

•Уровень влияния на целевую систему

•Уровень Состояния Сервиса (SDO)

Анализ может быть визуально отображается в виде двух таблиц:

SFA (P) — зависимость работы сервиса от других сервисов и служб

SFA (D) — зависимость других сервисов от отказа данного сервиса

В качестве оценки может применятся качественный метод с указанием «веса» влияния (от 1 — полный отказ до 0 — не влияет)

Анализ отказа компонентов сервиса (Components Failure Impact Analysis CFIA)

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

•Уровень отказа компонента системы

•Определение Среднего Времени Работы до Отказа (MTBF)

•Определение Среднего Времени Работы на Отказ (MTTF)

•Наработка на отказ (OTF)

•Определение Среднего Времени между Отказами (OTBF)

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

Механизмы обеспечения информационной безопасности

•Превентивные (Preventive) — механизмы, призванные предотвратить инциденты ИБ

•Восстановительные (Reductive) — механизмы, принятые заранее, что может минимизировать риски

•Детективные (Detective) — механизмы, призванные как можно скорее определить, что инцидент имел место

•Репрессивные (Repressive) — механизмы, применяемые в ответ на повторяющиеся или продолжающееся инциденты

•Корректирующие (Corrective) — механизмы восстановления и т п

При формировании политики Business Continuity & Disaster Recovery следует использовать дерево решений по следующим вопросам:

•Защита приложения

•Приоритет восстановления

•Выбор резервной площадки

•Связь между площадками

•Архитектура резервного копирования

•Архитектура хранения

•Архитектура репликации

•Архитектура инженерных систем

•Мониторинг производительности при переключении

•Тестирование DRP

•Утверждение факта катастрофы

Опции и методы восстановления

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

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

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

постепенное восстановление (Gradual Recovery) — способ восстановления, также известный как «холодное резервирование». Предусматривается восстановление услуги в течение более чем 72 часов. При постепенном восстановлении обычно задействован мобильный или стационарный резервный центр, оснащенный элементами жизнеобеспечения и сетевой разводкой, без компьютерных систем. Эта опция восстановления рекомендована для некритичных услуг, предоставление которых может быть задержано на дни и недели без значительного влияния на бизнес;

промежуточное восстановление (Intermediate Recovery) — способ восстановления, также известный как «теплое резервирование». Предусматривается восстановление услуги в течение 24–72 часов. При промежуточном восстановлении обычно используется общий мобильный или стационарный резервный центр, оснащенный компьютерными системами и сетевыми компонентами. Конфигурирование аппаратного и программного обеспечения, а также восстановление данных выполняются в рамках Плана обеспечения непрерывности услуг. Данная опция восстановления обычно предлагается третьими сторонами, которые имеют для этого все необходимое оборудование и квалифицированный персонал. Стоимость этой опции восстановления зависит от ресурсов третьей стороны, которые должны быть задействованы для восстановления, а также от времени, в течение которого требуется восстановить услугу. Преимуществом данного метода является его прозрачность для пользователей. Недостатком — то, что информация (в том числе конфиденциальная) будет храниться у сторонней организации. Последнее делает неприемлемым данный способ восстановления для многих организаций.

быстрое восстановление (Fast Recovery) — способ восстановления. Предусматривается восстановление услуги за короткий промежуток времени, обычно менее 24 часов. При быстром восстановлении обычно используется выделенный стационарный резервный центр с компьютерными системами и ПО, сконфигурированными для работы услуг. Немедленное восстановление может занимать до 24 часов, если требуется восстановление данных резервного копирования.

немедленное восстановление (Immediate recovery) — способ восстановления, также известный как «горячее резервирование». Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования. Этот способ чаще всего предусматривает «двойную локацию» компонентов системы, то есть полное дублирование. Он является самым дорогим и применяется только для критичных бизнес-процессов, простой которых может оказать значительное негативное влияние на бизнес. Копии должны быть расположены на максимальном удалении от оригиналов, чтобы не быть задетыми разрушающим событием.

Более детальная информация указана по ссылке Управление Непрерывностью ИТ Сервисов (IT Service Continuity Management SCO)

Перечень вопросов, регламентирующих ИТ процессы

Перечень вопросов, регламентирующих ИТ процессы и их описание.

Назначение процесса — Определение процесса, отвечает на вопрос WHAT

Цели процесса — Определяет цели и задачи процесса, отвечает на вопрос WHY

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

Зона ответственности — Определяет зоны ответственности для позиции или группы, отвечает на вопрос WHO.

Процедуры- Процедуры, связанные с процессом, отвечает на вопрос HOW

Критические Факторы Успеха (Critical Success Factors CSF) — Определяют, что должно произойти если процесс, сервис или проект будет успешным. Формируются критериями результативности (KGI).

Критерии результативности (KGI) — Определяют критерии результативности достижения целей, не имеют явно выраженных измеряемых показателей. Формируются из показателей KPI и субъективных наблюдений контролирующего органа.

Критерии эффективности (KPI) — Определяют критерии эффективности процессов, используемых для достижения целей. Формируются из метрик и показателей, которые можно измерить.

Карта процесса — Описывает пошаговую цепочку действий.

Матрица ролей и ответственностей (RACI Matrix)

Матрица ролей и ответственностей используется для определения ролей и ответственностей в процессе управления сервисами. Для каждой активности должна быть определена как минимум одна роль исполнителя и владельца. Базовая «стандартная» модель предполагает следующие роли:

RACI — стандартная модель

•Responsible (R) — Исполнитель, может быть несколько на одну активность, может совмещается

•Accountable (A) — Несет ответственность, владелец. Может быть только один для задачи или действия.

•Consulted (C) — Консультирует до исполнения

•Informed (I) — Оповещается после исполнения

RASIC (RASCI) — модель

•Responsible (R) — Исполнитель, может быть несколько на одну активность, может совмещается

•Accountable (A) — Несет ответственность, владелец. Может быть только один для задачи или действия.

•Consulted (C) — Консультирует до исполнения

•Informed (I) — Оповещается после исполнения

•Supported (S) — Оказывает поддержку

RACI–VS (VARISC) — модель

•Responsible (R) — Исполнитель, может быть несколько на одну активность, может совмещается

•Accountable (A) — Несет ответственность, владелец. Может быть только один для задачи или действия.

•Consulted (C) — Консультирует до исполнения

•Informed (I) — Оповещается после исполнения

•Verifier (V) — Тот кто проверяет результаты

•Signatory (S) — Тот кто подтверждает результаты проверки

RSI — модель

•Responsible (R) — Исполнитель, может быть несколько на одну активность, может совмещается

•Sponsor (S) — Владелец, спонсор активности

•Informed (I) — Оповещается после исполнения

DACI — модель

•Driver (D) — Драйвер, принимает решения, может быть одна роль на проект.

•Approver (A) — Подтверждает разрешает выполнение проекта или работ.

•Contributor (С) — Специалисты, непосредственные исполнители (аналитики, разработчики и т п)

•Informed (I) — Оповещается после исполнения

СТРАТЕГИЧЕСКИЙ ЭТАП (Strategy State)

Введение

Стратегический этап в управлении ИТ сервисами является по своей сути прикладным уровнем при построении ИТ Архитектуры Предприятия. Цели и задачи данного этапа:

•Показать организации как трансформировать Управление Сервисами в стратегические активы

•Внести ясность в связи между разными ИТ сервисами, системами или процессами и бизнес моделями и задачами

•Формирование стратегии сервиса, его цели и задачи.

•Определение ценность предоставляемых услуг и сервисов

•Определение возможностей ИТ по предоставлению сервисов

•Создание модели оказания услуг, охватывающие вопросы финансирования и внутреннею организацию

Данный этап, по рекомендациям ITIL v3 определяется пятью процессами к которым я бы добавил еще два:

•Управление связями с бизнесом (Business Relationship Management)

•Управление требованиями (Demand management)

•Управление сотрудниками (HR Management) *

•Управление финансами (Financial management)

•Формирование Стратегии (Strategy Generation)

•Управление портфелем сервисов (Service Portfolio management)

•Управление Деятельностью ИТ (IT Governance) *

Процесс создания ценности для организации

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

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

Дополнительно, завершение стратегического этапа является решением к началу проекта, по методологии Управления Проектами соответствует фазе «инициализации» проекта. Как говорится «… ввяжемся в бой, а там посмотрим…».

Процессы стратегического этапа являются прикладными процессами при формировании ИТ Архитектуры Предприятия. Уже на данном этапе можно принять решения по тем или иным ИТ проектам. Например, бизнес сформулировал требования, по выполнению которых ИТ сможет предоставить решения, которые позволят бизнесу взлететь до небес (например, выращивать кукурузу на марсе, открыть филиал на луне или выпустить страховой продукт по страхованию летающих тарелок). Если данные предложения прошли на этапе анализа бизнес плана, что вполне возможно при достаточном уровне «компетенции» бизнеса. ИТ поможет «приземлить» бизнес, оценив приблизительную стоимость решения. Может получится так, что требования бизнеса достаточно приземленные и достижимы, но руководство организации сформулировало «… денег нет, но вы держитесь…». Тогда двигателем станет ИТ департамент, который имеющимися или минимальными ресурсами сможет покрыть лишь часть запроса. Бизнес должен будет выбрать подходит ли данный минимум или нет, и попробует адаптироваться, изменить бизнес процессы, организацию и т п.

Управление Отношениями с Бизнесом (Business Relationship Management BR)

Процесс Управление Отношениями с Бизнесом предназначен для организации взаимодействия ИТ и бизнеса, и отвечает на такие вопросы как:

•Организация процесса взаимодействия ИТ с бизнесом

•Фокусирования внимания на бизнесе, их запросах и требованиях

•Анализ бизнес процессов, происходящих в бизнесе

•Оценка потенциала, по потребностям в услугах того или иного рода

Деятельность по процессу:

•Организация взаимодействия с бизнесом

•Разрешение конфликтов интересов

Входы процесса:

•Организационная структура компании

•Определение владельца сервиса

Выходы процесса:

•Определение сервиса

•Определение представителя бизнеса

•Определение управляющего ИТ сервисом

•Определение порядка информирования

•Протокол собрания

Участники процесса:

•Представители ИТ

•Представители бизнеса

Ключевые моменты процесса:

•Запросы со стороны бизнеса к ИТ могут носить неформальный характер на начальном этапе.

•Назначение представителей со стороны бизнеса и ИТ также может происходить в рамках рабочих процессов

•В качестве средств коммуникации может использоваться корпоративная почта, портал и т п.

Процесс: Управление Взаимодействием с бизнесом (Business Relationship Management BR)

Управление Требованиями (Demand Management DM)

Управление Требованиями один из основных процессов в функционировании ИТ любой организации и является ключевым для Стратегического этапа. Данный процесс отвечает на такие вопросы как:

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

Гарантирование определённого уровня предоставления сервиса в соответствии с требованиями

Гарантирования, что возможности и реализация (Utility & Warranty) сервиса удовлетворяют требованиям бизнеса.

Сбор и обработка информации по работе ИТ сервиса

Сбор и обработка запросов бизнеса

Написание бизнес требований (BR)

Контроль за соблюдением и выполнением требований

Деятельность по процессу:

Формирование требований к ИТ сервисам

Определение требований на основе активности (Activity-Based Demand Management)

Определение Образцов и шаблона Бизнес Активности (Pattern of Business Activity PBA)

Карта процессов

Различия в бизнес циклах (день, неделя, месяц, квартал или год)

Определение требований на основе бизнес ролей (User Profiles Demand Management)

На основе ролей и ответственностей сотрудников

Функции и операции пользователей по процессам и приложениям

Связывание роли с одним или более Образцами Бизнес Активности (PBA)

Формирование Core Services Packages и Supporting Services

Формирование Service Level Packages

Объединение SLP и CSP для формирования Каталога Сервиса

Разработка пакетов предоставления сервисов

При определении бизнес требований можно использовать MoSCoW анализ:

M — Должно быть (Must have this)

S — Следует иметь если это возможно (Should have its if possible)

C — Можем иметь, но без воздействия на что-то другое (Could have this, but does not affect anything else)

W — Не нужно сейчас, но может понадобится в будущем (Won’t none has this now, but would like it in the future)

Входы процесса:

Стратегический и оперативные планы организации

Требования со стороны бизнеса

Требования со стороны бизнеса

Шаблоны Активности Бизнеса (Patterns of Business Activity)

Пользовательские активы

Ожидания бизнеса

Ограничения

Выходы процесса:

Пакет Сформулированных Требований к ИТ сервису (Core Service Packages) включая технические и бизнес сервисы

Пакет Сформулированных Требований к уровню оказания услуг по сервису (Service Level Packages)

Соглашение об Уровне Услуг

Требования к ресурсам

Требования к финансам

Участники процесса:

•Представители бизнеса

•Представители ИТ

Ключевые моменты процесса:

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

Уровень подтверждения зависит от требований организации (руководитель бизнес подразделения, руководство организации и т п)

ИТ департамент является владельцем процесса.

Процесс: Управление Требованиями (Demand Management DM)

Управление Сотрудниками (HR Management HR)

Процесс Управление Сотрудниками, отвечает на такие вопросы как:

Стратегическое и тактическое планирование ИТ ресурсов (сотрудников)

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

Создание работникам условий, для применения и развития своих способностей для целей организации

Набор сотрудников в ИТ департамент

Продвижение и повышение сотрудников

Определение должностных инструкций

Деятельность по процессу:

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

Формирование процесса непрерывного обучения и роста сотрудников

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

Формирование благоприятного климата в организации

Определение процедуры регистрации нового сотрудника

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

Определение процедуры регистрации ухода сотрудника

Входы процесса:

Политики и процедуры со стороны Департамента Отдела Кадров

Организационная структура ИТ департамента

ИТ стратегия и планы организации

ИТ стратегия

ИТ проекты

Процесс Управления Знаниями

Участники процесса:

ИТ комитет

Отдел Кадров

Выходы процесса:

Протокол решения ИТ комитета

Организация ИТ департамента

Планирование человеческих ресурсов

Ключевые моменты процесса:

Департамент Управления Кадрами является владельцем и управляющим процессом

ИТ департамент выполняет требования владельца процесса

Процесс: Управление Персоналом (Human Resource Management HR)

Назначение процесса (WHAT) и цели процесса (WHY):

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

Управление сотрудниками

Формирование должностных инструкций сотрудников ИТ

Формирование позиций и градаций в ИТ департаменте

Набор сотрудников в ИТ департамент

Тестирование и собеседования

Обучение сотрудников организации

Обучение сотрудников ИТ департамента

Оценка и аттестация сотрудников ИТ департамента

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

Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):

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

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

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

Регистрация нового сотрудника

Организация рабочего места сотрудника

Предоставление доступа сотруднику

Регистрация изменений по сотруднику

Изменений рабочего места сотрудника

Изменений доступов сотруднику

Убытие сотрудника

Сворачивание рабочего места сотрудника

Закрытие доступа сотруднику

Разработка должностных инструкций сотрудника

Согласование должностных инструкций сотрудника

Утверждение должностных инструкций сотрудника

Внесение изменений в должностные инструкции сотрудника

Разработка позиций и градаций сотрудника

Согласование позиций и градаций сотрудника

Утверждение позиций и градаций сотрудника

Внесение изменений в позиции и градации сотрудника

Планирование кадровых ресурсов

Формирование требований к сотрудникам

Подготовка ИТ тестов

Проведение собеседования

Самостоятельное обучение сотрудника

Проведение обучения внутри компании (общие вопросы)

Проведение обучения внутри компании (технические вопросы)

Проведение обучения на курсах

Самостоятельное обучение сотрудника

Проведение обучения внутри компании (общие вопросы)

Проведение обучения внутри компании (технические вопросы)

Проведение обучения на курсах

Оценка и аттестация сотрудников ИТ департамента

Подготовка тестов для аттестации ИТ сотрудника

Проведение тестирования ИТ сотрудника

Проведение аттестации ИТ сотрудника

Оценка результатов ИТ сотрудника

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

Премирование ИТ сотрудника

Продвижение ИТ сотрудника

Повышение ИТ сотрудника

Количество часов обучения для сотрудников

Количество часов внутреннего обучения

Количество часов обучения по сотрудникам

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

Средний бал набранный при тестировании или аттестации

Стоимость обучения по сотрудникам

Среднее время между обучением и получения достаточного уровня компетенции

Знания сотрудника по отношению к имеющимся сервисам

Стоимость внешнего обучения сотрудника

Стоимость внутреннего обучения сотрудника

Соответствие фактических задач сотрудника и должностных инструкций

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

Управление Финансами (Finance Management FM)

Управление Финансами является ключевым процессов в функционировании ИТ любой компании. Управление финансами отвечает на такие вопросы как:

Финансовая прозрачность и возможность учета

Контроль за финансовой активностью

Управление стратегическими инвестиции

Понимание стоимости предоставляемых услуг (Total Cost of Ownership ТСО)

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

Улучшает процесс принятия решений на всем жизненном цикле сервиса.

Предоставление финансовой отчетности

Деятельность по процессу:

Разработка и утверждение Стратегического Бюджета ИТ

Разработка и утверждение Оперативного Бюджета ИТ

Контроль за финансами (закупки)

Контроль за финансами (текущие и плановые расходы)

Контроль за зарплатой, премиями и т п

Оценка стоимости сервиса

Оценка потерь из-за простоя сервиса

Оптимизация стоимости сервисов

Моделирование переменных затрат

Разработка модели финансирования

Разработка модели анализа и анализ ROI, IRR, бизнес кейсов

Разработка модели инвестиций в ИТ

Формирование и согласование с финансовым департаментом центров расходов

Разработка модели рефинансирования

Входы процесса:

Стратегические и оперативные планы ИТ

Требования бизнеса

Портфель сервисов

Каталог сервисов

Выходы процесса:

Подписанный протокол решения ИТ комитета

Подписанный Стратегического Бюджета ИТ

Подписанный Оперативного Бюджета ИТ

Предоставление финансовой отчетности

Участники процесса:

ИТ Комитет.

Финансовый директор

ИТ директор

Ключевые моменты процесса:

Комитет ИТ собирается не реже чем один раз в квартал

Условия проведения ИТ комитета (Наличие кворума)

Порядок распределения «веса» голосов при голосовании («А» роль)

Порядок принятия решения (простое большинство, кворум, полное согласие или «последнее слово» владельца)

ИТ директор не имеет права «голосовать», а выполняет рекомендательную функцию («С» роль)

Возможность совмещение проведения комитетов по SG и FM

Финансовый департамент является владельцем процесса

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

Требования по Управлению Финансами определяется со стороны департамента Финансов и бухгалтерии

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

Процесс: Управление Финансами (Finance Management FM)

Назначение процесса (WHAT) и цели процесса (WHY):

формирования стратегического ИТ

формирования оперативного ИТ бюджета

Внесение изменений в ИТ бюджет

Контроль ИТ бюджета контроль стратегического и оперативного ИТ бюджета

Контроль расходов ИТ контроль оперативных расходов

Контроль расходов по ИТ проектам контроль бюджета по ИТ проектам

Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):

Предоставление ИТ стратегии

Формирование стратегического ИТ бюджета

Обсуждение стратегического ИТ бюджета

Принятие стратегического ИТ бюджета

Ознакомление со стратегическим ИТ бюджетом

Контроль за исполнением стратегического ИТ бюджета

Предоставление ИТ стратегии

Формирование оперативного ИТ бюджета

Обсуждение оперативного ИТ бюджета

Принятие оперативного ИТ бюджета

Ознакомление с оперативным ИТ бюджетом

Контроль за исполнением оперативного ИТ бюджета

Предоставление изменений

Анализ изменений

Обсуждение изменений ИТ бюджета

Принятие изменений

Ознакомление с изменениями

Внесение изменений в ИТ бюджет

Формирование ежемесячного отчета

Предоставление ежемесячного отчета

Сверка ежемесячного отчета

Подтверждение ежемесячного отчета

Счет предоставляется в ИТ департамент

Регистрация передачи документа

Подтверждается факт выполнения работ

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

Регистрация передачи документа

Передача документа в финансовый департамент

Регистрация передачи документа

Предоставление ИТ стратегии

Формирование стратегического ИТ бюджета До 1 сентября

Ознакомление и обсуждение стратегического ИТ бюджета +5 дней

Принятие стратегического ИТ бюджета +1 день

Ознакомление со стратегическим ИТ бюджетом +5 дней

Контроль за исполнением стратегического ИТ бюджета в течении отчетного года

Предоставление ИТ стратегии

Формирование оперативного ИТ бюджета До 1 сентября

Обсуждение оперативного ИТ бюджета +5 дней

Принятие оперативного ИТ бюджета +1 день

Ознакомление со оперативного ИТ бюджетом +5 дней

Контроль за исполнением оперативного ИТ бюджета в течении отчетного года

Предоставление изменений

Анализ изменений До 1 сентября

Обсуждение изменений ИТ бюджета +5 дней

Принятие изменений +1 день

Ознакомление с изменениями +5 дней

Внесение изменений в ИТ бюджет К очередному ИТ комитету

Формирование ежемесячного отчета +4 дней после отчетного периода

Предоставление ежемесячного отчета +1 день

Сверка ежемесячного отчета +5 дней после получения отчета

Подтверждение ежемесячного отчета +5 дней

Счет предоставляется в ИТ департамент Ежедневно

Регистрация передачи документа Ежедневно

Подтверждается факт выполнения работ В течении дня

Документ визируется на оплату В течении дня

Регистрация передачи документа В течении дня

Передача документа в финансовый департамент В течении дня

Регистрация передачи документа В течении дня

Критерии результативности — (KGI):

Соответствие ИТ бюджета ИТ стратегии

Удовлетворённость владельцев бизнеса

Критерии эффективности — (KPI)

01 Соответствие ИТ бюджета> 70% <70%

02 Соответствие расходов утвержденному ИТ бюджету> 70% <70% дИТП ПРВП

03 Количество изменений, внесенных в ИТ бюджет 0> 3 дИТП ПРВП

04 Стоимость процесса управления ИТ

05 Стоимость сопровождения ИТ инфраструктур

06 Полная стоимость владения ИТ инфраструктурой

07 Стоимость резервной площадки

08 Стоимость ИТ сервисов и ИТ активов

09 Стоимость ИТ сервисов на пользователя

10 Стоимость «операционной» ИТ среды (Production)

11 Стоимость «тестовой» ИТ среды (Test)

12 Стоимость «эталонной» ИТ среды (Pre-production)

13 Соотношение стоимости Бизнес и Технических ИТ сервисов

14 Соотношение стоимости основной и резервной площадки

15 Стоимость ИТ проектов

16 Административные расходы ИТ департамента

17 Стоимость персонала ИТ департамента

18 Соотношение основного и вспомогательного персонала ИТ

Разработка Стратегии (Strategy Generation SG)

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

Стратегия ИТ департамента

Соответствие ИТ стратегии и стратегии бизнеса

Какие сервисы и кому необходимо предоставлять

Как создавать ценность для клиента или бизнеса

Как разрешать конфликты требований к разделяемым ИТ ресурсам

Разработка стратегических активов

Оценка сильных и слабых сторон, приоритеты и риски

Как распределять ресурсы и мощности между сервисами портфеля

Понимание рынка и идентификация возможностей по созданию сервисов

Разработка outcome-based service, которые предоставляют функциональность заказчикам

Подготовка и удачная реализация стратегии

Деятельность по процессу:

Разработка и утверждение Плана Стратегического Развития ИТ

Разработка и утверждение Оперативного Плана Развития ИТ

Контроль за исполнением планов ИТ

Разработка и утверждение руководящей документации

Разработка системы контроля (Develop closed-loop control system)

Разработка стратегических активов и сервисов

Анализ мощностей и ресурсов

Анализ стратегии и сервисов

Понимание нужд заказчика

Понимание возможностей

Классификация и визуализация сервисов как образцов создания ценности

Определение outcome-based service

Разработка портфеля сервисов

Оценка стратегии

Постановка целей и задач

Соответствие активов и нужд заказчиков

Определение критических факторов успеха

Определение приоритетов инвестиций

Исследование бизнес потенциала

Asset-based services

Utility-based services

Планы и Patterns

Создание ценности

Определение сильных и слабых сторон

Определение возможностей и угроз

Необходимые компетенция

Входы процесса:

План стратегического развития организации

Организационная структура компании

Бизнес требования

Портфель сервисов

Каталог сервисов

Оценка рисков

Стоимость сервисов

Определение Стратегии Обслуживания (Lines of Service)

Шаблоны бизнес процессов и активности

Оценка мощностей

Оценка ресурсов

Оценка ограничений

Оценка конфликтов

Стратегический анализ

Определения рынка

Ограничения заказчика

Выгоды

Бизнес задачи

Выходы процесса:

Подписанный протокол решения ИТ комитета

Утвержденная ИТ Стратегия

Подписанный Плана Стратегического Развития ИТ

Подписанный Плана Оперативного Развития ИТ

Подписанные Проекты

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

Решения по инвестициям

Участники процесса:

ИТ Комитет

Менеджер по взаимодействию с бизнесом

Директор ИТ департамента

Представители бизнеса

Ключевые моменты процесса:

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

ИТ комитет является высшим органом по принятию решений в области ИТ

ИТ Комитет собирается не реже чем один раз в квартал.

Наличие кворума для принятия решения (рекомендации со стороны Юридического департамента)

Порядок распределения «веса» голосов при голосовании («А» роль)

Порядок принятия решения (простое большинство, кворум, полное согласие или «последнее слово» владельца)

ИТ директор не имеет права «голосовать», а выполняет рекомендательную функцию («С» роль)

Процесс: Разработка Стратегии (Strategy Generation GS)

Назначение процесса (WHAT) и цели процесса (WHY):

Формирования процесса управления ИТ стратегии

Внесение изменений в ИТ стратегию

Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):

Предоставление бизнес стратегии

Формирование ИТ стратегии

Обсуждение ИТ стратегии

Принятие ИТ стратегии

Ознакомление с ИТ стратегией

Исполнение ИТ стратегии

Контроль выполнения ИТ стратегии

Предоставление изменений

Анализ изменений

Обсуждение изменений ИТ стратегии

Принятие изменений

Ознакомление с изменениями

Внесение изменений в ИТ стратегию

Предоставление бизнес стратегии

Формирование ИТ стратегии До 1 сентября

Обсуждение ИТ стратегии +5 дней

Принятие ИТ стратегии +1 день

Ознакомление с ИТ стратегией +5 дней

Исполнение ИТ стратегии в течении отчетного года

Контроль выполнения ИТ стратегии в течении отчетного года

Предоставление изменений

Анализ изменений До 1 сентября

Обсуждение изменений ИТ стратегии +5 дней

Принятие изменений +1 день

Ознакомление с изменениями +5 дней

Внесение изменений в ИТ стратегию К очередному ИТ комитету

Критерии результативности — (KGI)

Соответствие ИТ стратегии бизнес стратегии

Удовлетворённость владельцев бизнеса

Критерии эффективности — (KPI)

01 Исполнимость стратегических планов в срок> 70% <70%

02 Исполнимость оперативных планов в срок> 70% <70%

03 Количество изменений, внесенных в ИТ стратегию 0> 3

Управление Портфелем Сервисов (Service Portfolio Management PM)

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

Цели процесса:

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

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

Почему клиент использует данный сервис

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

Почему именно у нас клиент покупает данный сервис

Какова модель финансирования сервиса

Каковы сильные и слабые стороны, приоритеты и риски

Как распределять ресурсы и мощности между сервисами портфеля

Деятельность по процессу:

Формирование портфеля сервисов

Разработка мощностей и ресурсов

Входы процесса:

Выходные данные Стратегии

Выходы процесса:

Inventories

Business Cases

Service Portfolio

Authorization

Value Proposition

Prioritization

Communication

Resource Allocation

Участники процесса:

ИТ комитет

Contract Manager

Business Relationship Manager

Product Manager

Ключевые моменты процесса:

Владелец процесса является ИТ

Определены следующие статусы сервисов:

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

Установленные (Defined) — набор требований, которые были определены, оценены и задокументированы и Уровень Требований к Сервису (SLR) сгенерированы

Проанализированы (Analyzed) — набор требований, который был проанализирован и установлены приоритеты

Одобренные (Approved) — набор требований, которые были утверждены и задокументированы

Заказанные (Chartered) — сервисы, для которых выделены ресурсы и бюджет

Проектированы (Designed) — сервис или его компоненты, спроектированы и при необходимости закуплены

Разработаны (Developed) — сервис или его компоненты, разработаны

Собранные (Built) — сервис или его компоненты, собраны

Протестированные (Tested) — сервис или его компоненты, прошедшие тестирование

Выпущенные (Released) — сервис или его компоненты, сборка которого готова

Сопровождается (Operational) — сервис или его компоненты, предоставленные клиентам и сопровождаются

Устаревшие (Retired) — сервис или его компоненты, выведенные из «производственной» среды

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

Имя услуги

Описание услуги

Статус услуги

Классификацию услуги и ее критичность

Используемые приложения

Используемые данные или/и схемы данных

Бизнес-процессы, поддерживаемые услугой

Владельцы бизнеса

Пользователи бизнеса

Владельцы IT

Уровень гарантии качества услуги, ссылки на SLA и SLR

Поддерживающие услуги

Поддерживающие ресурсы

Услуги, которые зависят от рассматриваемой услуги

OLA, контракты и соглашения

Затраты на услугу

Издержки на услугу (если это применимо в данном случае)

Доход от услуги (если это применимо в данном случае)

Метрики для услуги

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

Процесс: Управление Портфелем Сервисов (Service Portfolio Management PM)

Назначение процесса (WHAT) и цели процесса (WHY):

Порядок внесения сервиса в портфель Организация процесса внесения изменений

Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):

Добавление сервиса

Изменение статуса сервиса

Внесение изменений в портфель сервисов

Автоматически после утверждения (DM) По событию

Автоматически после утверждения (DM) По событию

Изменение статуса и атрибутов сервиса +14 дней

Критерии результативности — (KGI)

Полнота и достоверность портфеля

Быстрота внедрения в каталог сервисов

Критерии эффективности — (KPI)

Количество сервисов в портфеле

Количество сервисов по статусам

Количество сервисов по типам (Б/Т)

Количество сервисов по бизнес подразделениям

Время перехода в каталог сервисов

Время перехода из каталога сервисов

Своевременность и полнота информации

Несвоевременная регистрация

Отношение сервисов каталога к сервисам портфеля

Управление деятельностью ИТ департамента (IT Governance DG)

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

Регламентирование административных мероприятий по управлению ИТ

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

Деятельность по процессу:

Разработка и утверждение процессов управления и взаимодействия ИТ

Разработка и утверждение руководящих ИТ документов

Разрешение конфликта интересов

Входы процесса:

Требования бизнеса

Рекомендации мировых практик в области управления ИТ, Управления Проектами, Аудита, Корпоративного Управления

Выходы процесса: Протокол решений ИТ комитета и Руководящие ИТ документы

Участники процесса:

ИТ Комитет

Ключевые моменты процесса:

Комитет ИТ собирается не реже чем один раз в квартал

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

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

Процесс: Управление ИТ (IT Governance DG)

Назначение процесса (WHAT) и цели процесса (WHY):

Организация процесса управления ИТ формирования стратегического ИТ бюджета

Организация деятельности ИТ формирования оперативного ИТ бюджета

Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):

Формирование руководящих документов ИТ

Обсуждение руководящих документов ИТ

Принятие руководящих документов ИТ

Регистрация решения ИТ комитета

Сбор подписей по решения ИТ комитета

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

Ознакомление с руководящими документами ИТ

Контроль за исполнением руководящих документов ИТ

Внесение изменений в руководящие документы ИТ

Разрешение конфликтов интересов

Формирование руководящих документов ИТ

Обсуждение руководящих документов ИТ До 1 сентября

Принятие руководящих документов ИТ +5 дней

Регистрация решения ИТ комитета +1 день

Сбор подписей по решения ИТ комитета +5 дней

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

Ознакомление с руководящими документами ИТ в течении отчетного года

Контроль за исполнением руководящих документов ИТ

Внесение изменений в руководящие документы ИТ

Разрешение конфликтов интересов

Критерии результативности — (KGI)

Удовлетворённость владельцев бизнеса

Критерии эффективности — (KPI)

Количество утвержденных руководящих ИТ документов N/A N/A

Количество внесенных изменений в руководящие ИТ документы N/A N/A

Количество и сроки проведения ИТ комитетов 4 3 <,> 8

Нарушения по количеству или срокам проведения ИТ комитетов 0> 1

ЭТАП ДИЗАЙНА (Design Stage)

Введение

Этап Дизайна является не менее важным и наиболее объемным этапом управления ИТ сервисами. На данном этапе производится планирование сервиса, детализация всех аспектов функционирования сервиса, закладывается основа плана внедрения и сопровождения сервиса. По сути происходит основная «мозговая» деятельность. Для Управления Проектами соответствует фазе планирования проекта.

Цели и задачи:

Проектирование новых и изменение имеющихся сервисов для организации

Сервис дизайн вовлекается только для «важных» стратегических изменений в ИТ архитектуре.

Формирование дизайна и планирование сервиса и процессов.

Данный этап определяется следующими процессами (7):

Координация дизайна и планирования (Design Coordination) *

Управление рисками (Risk Management) *

Управление архитектурой (Architecture Management) *

Управление соответствия требованиям (Compliance Management) *

Управление Каталогом Сервисов (Service Catalog Management)

Управление Уровнем Услуг (Service Level Management)

Управление доступностью (Availability Management)

Управление мощностями (Capacity Management)

Управление непрерывностью сервисов (It service Continuity Management)

Управление Информационной Безопасностью (Information Security Management)

Управление поставщиками (Supplier Management)

Деятельность процессов дизайна концентрирует свое внимание на двух ключевых аспектах:

Ресурсы (Resources) — прямые активы которые можно измерить

Возможности (Capability) — способности организации координировать, контролировать и распределять ресурсы для создания ценности.

Помимо этого, вводятся два важных атрибута сервиса:

Возможности сервиса (Utility), что он делает. Соответствие функциональным требованиям «fit to purpose».

Качество сервиса (Warranty) — насколько хорошо он это делает, «fit for use».

Этап Дизайна сервисов оперирует четырьмя основными понятиями:

Люди (People)

Продукты (Products)

Процессы (Processes)

Партнеры (Partners)

Основные измерения этапа Дизайна сервисов:

Функциональность (возможности сервиса)

Ресурсы (люди, финансы, технологии)

Время

Баланс этих трех показателей позволяет достичь максимальной эффективности этапа планирования сервиса — Качества сервиса.

При разработке программного обеспечения можно использовать следующие механизмы:

Структурированная Система Разработки (Structured System Development)

Традиционная линейная (Traditional Linear)

«Водопад» (Waterfall)

«V-Модель» (V-Model)

Быстрая Разработка (Rapid Application Development)

Быстрая разработка за счет повторного использования готовых и разработанных компонентов

Коробочные Коммерческие Решения (Commercial Off-the-shell Solutions COTS)

Использование и адаптация коммерческих продуктов (COTS)

Выделяется пять ключевых аспектов Проектирования услуг

проектирование решений, в том числе всех требуемых и согласованных функциональных требований, ресурсов и возможностей;

проектирование поддерживающих управленческих систем и инструментов, в частности Портфеля услуг для управления и контроля услуг в рамках их жизненного цикла;

проектирование технологий, систем и инструментов управления, необходимых для предоставления услуг;

проектирование процессов, необходимых для построения дизайна, внедрения, эксплуатации и улучшения услуг;

проектирование методов и метрик для измерения качества, эффективности и производительности услуг, архитектур и процессов.

Прежде чем передать спроектированное решение на этап Внедрения, необходимо выполнить ряд дополнительных действий:

Оценка альтернативных решений. Эта деятельность необходима, если к предоставлению услуг привлечены внешние поставщики услуг и решений. Состоит из следующего:

формирование набора поставщиков и организация тендера;

обзор и оценка всех решений, предлагаемых поставщиками. Отбор наиболее подходящих для конкретной задачи поставщиков;

оценка и расчет стоимости альтернатив, с последующим выборов наилучших.

Снабжение выбранного решения

Хотя существует возможность, что для разработанного решения не потребуется участие третьих сторон (то есть поставщиков), тем не менее, на практике чаще всего они участвуют, а, следовательно, необходимо выполнить следующее:

завершение всех необходимых проверок выбранного поставщика;

заключение контрактов с поставщиком;

снабжение выбранного решения.

Разработка решения. Сюда относится деятельность по трансляции проекта услуги в план по ее разработке. Каждый план будет ответственен за разработку одного или более компонентов услуги и должен включать следующее:

потребности бизнеса;

стратегия, применяемая для разработки и/или приобретения решения;

временные рамки;

требуемые ресурсы, в том числе возможности и инфраструктуры IT, квалифицированный персонал и т. п.;

разработка услуги и ее компонентов, в том числе механизмов управления, формирования отчетности, измерения и т. п.

план тестирования услуги и ее компонентов.

На выходе Сервис Дизайна формируется Пакет Сервис Дизайна (Service Design Package SDP), который включает в себя:

Процессы данного этапа формируют три основных документа: Пакет Дизайна Сервиса,

Пакет Дизайна Уровня предоставления услуг

Детальную Архитектуру Предприятия.

На выходе, возможна корректировка стратегических планов и бюджетов. Пакеты решений передаются далее на этап Внедрения. В плане Управления Проектами принимается окончательное решение по началу проекта и выделение ресурсов, определения сроков ИТ проекта.

Координирование процесса Дизайна сервиса (Design Coordination DC)

Процесс Координирования Дизайна сервиса является главным на этапе Дизайна». Процесс должен соответствовать Концепция ИТ архитектуры, Концепция управления проектами и Концепция управления ИТ сервисами. Фактически процесс является аналогом процесса «Управления Изменениями» и отвечает на такие вопросы как:

Формирование процесса дизайна сервиса.

Координация деятельности различных процессов управления ИТ сервисами

Интеграция фаз и процессов Управления Проектами

Деятельность по процессу:

Утверждение процесса дизайна сервисов

Координация деятельности по проектированию ИТ сервисов

Входы процесса:

Выходы процессов Стратегического этапа

Фаза инициализации Управление Проектами

Выходы процесса:

Детальная ИТ Архитектура Предприятия

Пакет Дизайна Сервиса

Пакет Дизайна Предоставления Услуг

Протокол решения ИТ комитета

Необходимые данные для фазы планирования Управления Проектами

Участники процесса:

ИТ комитет

ИТ архитектор

Руководитель ИТ Проектов

Менеджер ИТ проектов

Экспертная группа, в составе которой эксперты и инженеры ИТ, представители бизнеса

Ключевые моменты процесса:

ИТ департамент является владельцем процесса

Процесс: Координация процесса дизайна сервиса (Design Coordination DC)

Назначение процесса (WHAT) и цели процесса (WHY):

Организация процесса дизайна сервиса

Организация дизайна сервиса

Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):

Координация процессов дизайна ИТ сервисов

Координация требований Управления Проектами

Подготовка Пакетов Дизайна Сервиса и Предоставления Услуг

Утверждение Пакетов Дизайна Сервиса и Предоставления Услуг

Утверждение ИТ Архитектуры Предприятия

Критерии результативности — (KGI)

Критерии эффективности — (KPI)

01% требований спецификаций Сервис Дизайна предоставленных в срок и в соответствии с бюджетом

02% Планов Сервис Дизайна предоставленных в срок и в соответствии с бюджетом

03% Пакетов Сервис Дизайна законченных в срок

04% соответствия бизнес требований и решений, сформированных в Пакетов Сервис Дизайна

05% точности при оценке стоимости сервиса или проекта на этапе Сервис Дизайна

Управление Рисками (Risk Management RM)

Управление Рисками процесс этапа «Дизайна». Является ключевым процессом для организации. Процесс должен соответствовать Концепция управления рисками. Данный процесс отвечает на такие вопросы как:

Формирование процесса управления рисками в рамках организации.

Формирование и утверждение реестра рисков

Расчет стоимости рисков

Анализ рисков и механизмов противодействия или снижения рисков

Формирование и утверждение реакции на риски

Порядок взаимодействия ИТ департамента с бизнесом по вопросам управления рисками

Порядок взаимодействия подразделений внутри ИТ департамента по вопросам управления рисками

Деятельность по процессу:

Формирование и утверждение процесса управления рисками

Формирование и утверждение реестра рисков

Формирование и утверждение реакции на риски

Выявление рисков

Определение владельцев рисков

Оценка рисков

Формирование реакции на риски

Внедрение реакции на риски

Gain assurances of effectiveness and efficiency

Embed and Review

Разработка и согласование процесса управления рисками

Исполнение требований комитета по управлению рисками

Определение рисков на всех этапах жизненного цикла сервиса

Решение Комитета по Управлению Рисками

Рекомендации по Информационной Безопасности

Входы процесса:

Процесс Управление Отношениями с Бизнесом

Процесс Управления Требованиями

ИТ архитектура

Contract Risks

Service Provider Risks

Design Risks

Transition Risks

Operational Risks

Market Risks

Выходы процесса:

Подписанный протокол решения ИТ комитета

Подписанный протокол решения Комитета по управлению Рисками

Risks responses

Участники процесса:

ИТ комитет

Комитет по управлению рисками

ИТ директор

ИТ архитектор

Руководители ИТ подразделений

Экспертная группа

Представители бизнеса

Представители комитета управления рисками

Представители департамента Безопасности

Ключевые моменты процесса:

Департамент Внутреннего ИТ Аудита (Комитет по Управлению Рисками) является владельцем процесса

Департамент ИТ является исполнителем (управляющим) по вопросам связанных с информационными технологиями.

Департамент Информационной Безопасности является консультантом в процессе

Процесс: Управление Рисками (Risk Management RM)

Назначение процесса (WHAT) и цели процесса (WHY):

Организация процесса управления рисками

Организация управления рисками

Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):

Организация процесса управления рисками

Согласование процесса управления рисками

Утверждение процесса управления рисками

Внесение изменений в процесс управления рисками

Проведение деятельности по обнаружению рисков

Проведение деятельности по анализу рисков

Формирование реестра рисков

Проведение деятельности по оценке рисков

Выработка мер противодействия рискам

Оценка мер противодействия рискам

Разрешение конфликта интересов по управления рисками

Критерии результативности — (KGI)

Критерии эффективности — (KPI)

01 Количество рисков

02 Количество критических рисков

03 Количество рисков по категориям

Управление ИТ Архитектурой (Architecture Management AM)

Управление ИТ архитектурой процесс этапа «дизайна». Является ключевым процессом для организации и ИТ департамента в частности. Процесс должен соответствовать Концепция ИТ архитектуры. Данный процесс отвечает на такие вопросы как:

Организация процесса Управления Архитектурой

Разработка ИТ Архитектуры Предприятия

Разработка Архитектуры ИТ сервисов

Архитектура предприятия должна включать в себя следующие основные архитектуры:

Архитектура услуг — транслирует приложения, инфраструктуры, организацию и поддержку деятельностей в набор услуг. Архитектура услуг предоставляет независимый, интегрированный в бизнес подход для предоставления услуг бизнесу. Она предлагает модель для разделения между Архитектурой услуг, Архитектурой приложений, Архитектурой инфраструктуры и Архитектуры данных. В рамках Архитектуры услуг также рассматриваются вопросы обеспечения стойкости к сбоям, дальнейшей корректировки и обеспечения безопасности.

Архитектура приложений — предлагает детальный план по развитию и доставке индивидуальных приложений, отображает функциональные требования бизнеса к приложениям и показывает взаимозависимости между приложениями. Использование подхода, основанного на компонентах, максимизирует повторное использование и помогает приложениям быть гибкими в условиях изменяющихся политик снабжения.

Архитектура данных/информации — описывает логические и физические информационные активы организации, и ресурсы управления ими. Она показывает, как распределены информационные ресурсы и управление ими для достижения корпоративной цели.

Архитектура инфраструктуры — описывает структуру, функциональность и географическое распределение программного и аппаратного обеспечения, компонентов коммуникации, а также относящиеся к ним стандарты.

Архитектура окружения — описывает аспекты, уровни и типы контроля окружения, а также их управления.

Деятельность по процессу:

Организация процесса управления Архитектурой

Входы процесса:

Входы процессов стратегического этапа

Выходы процесса:

ИТ Архитектура Предприятия

Архитектура ИТ сервиса

Участники процесса:

ИТ комитет

ИТ архитектор

Главы подразделений ИТ департамента