1. Модель COBIT

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

CobiT характеризуется: ориентация на бизнес требования, процессным подходом к управлению ИТ, целями контроля управлению ИТ процессами, оценка эффективности ИТ.

CobiT — это сокращение от Control Objectives for Information and Related Technology («Задачи информационных и смежных технологий»). CobiT представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления IT, аудита и IT-безопасности. Задача CobiT заключается в ликвидации разрыва между руководством компании с их видением бизнес-целей и IT-департаментом, осуществляющим поддержку информационной инфраструктуры, которая должна способствовать достижению этих целей. Нередко руководство компании не понимает IT-специалистов. Те, в свою очередь, не понимают бизнес-терминов, на основании которых строятся распоряжения руководства. Это все приводит к росту издержек эффективности деятельности.

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

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

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

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

-Политики (методы достижения целей в рамках стратегий, например: «длина пароля регламентируется»; ответственные: руководство IT-подразделений).

-Стандарты (метрики для политик-методов, например: «длина пароля должна составлять не менее 8 символов»; ответственные: руководство IT-подразделений).

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

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

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

Трехуровневая модель определения компонент стратегии включает в себя:

-описание конечного состояния (видение, цель);

-описание ограниченного набора способов достижения цели (основная стратегия);

-шаги к достижению цели (тактика или конкретные проекты).

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

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

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

3. Зарождение информационного менеджмента

В истории развития цивилизации произошло несколько информационных революций. Первая изобретение письменности.

Вторая (середина XVI в.) изобретение книгопечатания. Третья (конец XIX в.) изобретение электричества(телеграф, телефон).

Четвертая (70-е гг. XX в.) изобретение микропроцессорной технологии и появление персонального компьютера. Для создания более целостного представления о периоде четвертой информационной революции необходимо назвать исторические этапы смены поколений (ЭВМ):.1-е поколение (начало 50-х гг.). Элементная база – электронные лампы. 2-е поколение (с конца 50-х гг.). Элементная база – полупроводниковые элементы. Для программирования используются алгоритмические языки.

3-е поколение (начало 60-х гг.). Элементная база – интегральные схемы, снижение габаритов ЭВМ. Доступ с удаленных терминалов. 4-е поколение (с середины 70-х гг.). Элементная база – микропроцессоры, большие интегральные схемы. Массовый выпуск персональных компьютеров. 5-е поколение (с середины 80-х гг.). Началась разработка интеллектуальных компьютеров. Внедрение во все сферы компьютерных сетей и их объединение, повсеместное применение компьютерных информационных технологий. Бурное развитие компьютерной техники и информационных технологий послужило толчком к развитию информационного общества. Понятие «информационный менеджмент» появилось в конце 70-х годов. Возникновение ИМ связано, с необходимостью принимать эффективные решения в сфере информатизации, так и требованиями к управлению информацией в деятельности предприятия. Расходы на проектирование и внедрение ИС обычно существенно превышали запланированные суммы, качество оказывалось неудовлетворительным т.д. Практика создания и эксплуатации информационных систем выявила проблемы и противоречия, которые могли быть разрешены только введением все специализированного информационного менеджмента.

Исторической точкой возникновения ИМ как можно назвать 1957 г. В этом году в США число работников отрасли обработки информации сравнялось по численности с числом работников материального производства. Далее в США работники области обработки информации стали доминировать по численности. В этот же период (50-е , 60-е годы) появились первые стратегические информационные системы. Классическим примером является создание и развитие автоматизированной системы бронирования и продажи авиабилетов SABRE. Система бронирования SABRE была создана авиакомпанией American Airlines в 1964 г. Информационные системы за короткий срок стали необходимым средством успешного Менеджмента.

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

4. Бизнес- и ИТ-стратегия

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

> миссия (зачем нужен отдел ИТ, какова роль ИТ в компании);

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

> операционные принципы (как мы будем работать).

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

> видение, каким будет подразделение через несколько лет;

> текущая ситуация;

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

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

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

5. Стратегия в области ИТ-персонала и сорсинга

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

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

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

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

Существуют следующие моделей стратегий сорсинга:

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

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

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

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

6. Категории потребности бизнеса, учитываемые при разработке ИТ-стратегии

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

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

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

-Существующие (унаследованные) бизнес-процессы и системы. -Виртуализация бизнеса. Интеграция с системами клиентов, партнеров, поставщиков и т.п. Это влияет на принятие решений о том, какие прикладные системы останутся внутренними для организации, а какие будут переданы на аутсорсинг.

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

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

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

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

Пять элементов, определяющих ИТ-стратегию:

-ИТ-инфраструктура. (аппаратное и программное обеспечение и комплектующие, сети),

-ИТ-сервисы (эксплуатация). Как департамент ИТ обеспечит доступность ИТ-среды.

-Портфель приложений. Как будет меняться имеющийся набор прикладных систем?

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

-Сорсинг. Обеспечение выполнения стратегии внутренними и внешними для департамента ИТ ресурсами.

7. Пять элементов, определяющих ИТ-стратегию

Независимо от того, есть ли в организации явно сформулированная бизнес-стратегия или нет, для понимания сути влияния бизнес-стратегии на стратегию ИТ важно дать ответ на два вопроса:

-Каковы главные компоненты, составляющие суть стратегии ИТ?

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

Пять элементов, определяющих ИТ-стратегию:

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

-ИТ-сервисы (эксплуатация). Как департамент ИТ обеспечит доступность ИТ-среды, какие услуги бизнес-подразделения получают от департамента ИТ на ежедневной основе. Наиболее общим определением ИТ-услуг для бизнес-подразделений является Соглашение об уровне обслуживания (SLA – Service-Level Agreement).

-Портфель приложений. Как будет меняться имеющийся набор прикладных систем?

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

-Сорсинг. Обеспечение выполнения стратегии внутренними и внешними для департамента ИТ ресурсами.

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

8. Проблемы, связанные с процессом разработки ИТ-стратегии

Перечислим некоторые из них, связанные с разработкой стратегии ИТ:

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

Стратегический план является статическим документом. Процесс обновления стратегии ИТ, не всегда легко реализуется на практике. Характерный "период полураспада" большинства стратегических планов в области ИТ составляет около 6 месяцев, т.е. за полгода половина положений стратегии может потерять свою актуальность в результате действия таких факторов, как изменения в бизнес-среде, слияния и реорганизации, изменения в технологиях, новые приоритеты бизнеса. Кроме того, важно помнить, что стратегические планы связаны с конкретными людьми, а как показывает статистика, скорость обновления в рядах высшего руководства компаний составляет 20-25% в год. Поэтому нужно задумываться об обновлении стратегии ИТ.

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

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

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

9. Типичная структура ИТ-департамента

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

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

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

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

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

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

10. Компетенции ИТ-персонала

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

Важно понимать, каким портфелем собственных навыков и знаний обладает департамент ИТ предприятия, чтобы определить, в каких областях, скорее всего, потребуется привлечение внешних поставщиков. Можно выделить три основных группы подобных "умений":- знание конкретных продуктов и технологий: например, серверы Windows, администрирование БД Oracle, XML, .NET, Java, CRM-системы, проектирование web-систем и т.д.; -знания в области управления технологиями: например, моделирование бизнес-требований к системам, интеграция технологий, управление портфелем технологий, управление проектами, архитектура; -навыки в области управления бизнесом: например, консультирование, умение обосновывать проекты (business-case development), финансовый анализ, оценка рисков, коммуникации, управление набором поставщиков, конкурентный анализ.

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

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

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

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

11. Роль ИТ-стратегии для развития ИТ-службы

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

Стадии доверия к ИТ-службе

Название Характеристика ИТ-службы со стороны бизнес-подразделений Ключевые задачи ИТ-службы

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

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

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

Доверие Эффективность как в оказании услуг, так и в планировании, стратегии, успешная совместная работа Укрепление связи с бизнесом, организация процессов финансирования, развитие конкурентоспособности

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

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

-обеспечение соответствия ИТ- и бизнес-стратегии;

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

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

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

-развитие бизнеса за счет возможностей информационных технологий.

12. Назначение ITSM

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

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

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

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

Концепция ITSM находит своё отражение во многих подходах и методологиях, включая:

1 ITIL (The Information Technology Infrastructure Library) - библиотеку передового опыта в области управления ИТ;

2 CobiT (Control Objectives for Information and Related Technology) – стандарт в области контроля за информационными технологиями;

13. Основные процессы, рассматриваемые в ITIL

ITIL - это библиотека лучших практических способов организации предоставления ИТ-услуг для работы подразделений или компаний. Данная аббривиатура образована от английского IT Infrastructure Library, что в переводе означает "библиотека инфраструктуры информационных технологий".

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

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

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

Главный акцент ITIL делается прежде всего на описании сервисов и поддержки. Основные процессы, рассматриваемые в ITIL:

-управление инцидентами (Incident management);

-управление проблемами (Problem management);

-управление конфигурациями (Configuration management);

-управление изменениями (Change management);

-управление версиями (Release management);

-управление мощностями (Capacity management);

-управление доступностью (Availability management);

-управление уровнями обслуживания (Service-level management).

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

14. IDEF0. ICOM-соды

ICOM (аббревиатура от Input, Control, Output и Mechanism) — коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер.

несвязанными стрелками,

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

Связь по входу(output-input), когда стрелка выхода вышестоящей работы (далее — просто выход) направляется на вход нижестоящей

Связь по управлению(output-control), когда выход вышестоящей работы направляется на управление нижестоящей.

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

Обратная связь по управлению(output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей

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

Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

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

15. DEF0. Контекстная диаграмма

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. 32. DEF0. Дуги, "помещенные в тоннель".

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

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

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

16. DEF0. Разветвление и слияние дуг

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

Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей тоже именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления

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

17 DEF0. Дополнения к моделям: текст, глоссарий, FEO-диаграммы

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

Диаграммы "только для экспозиции" (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку по сути являются просто картинками. Новая диаграмма получает номер, который генерируется автоматически (номер родительской диаграммы по узлу + постфикс F, например A1F).

18. DEF0. Узловые номер

Нумерация работ и диаграмм. Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы i декомпозиции А0 имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию — нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы — номер А0, остальные диаграммы декомпозиции — номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.). В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер — C-number, который должен присваиваться автором модели вручную. C-number — это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021.

19. Методологии SADT и IDEF0

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

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником

верхняя сторона имеет значение "Управление" (Control);

левая сторона имеет значение "Вход" (Input);

правая сторона имеет значение "Выход" (Output);

нижняя сторона имеет значение "Механизм" (Mechanism).

20. Концепция IDEF0-моделей

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником

верхняя сторона имеет значение "Управление" (Control);

левая сторона имеет значение "Вход" (Input);

правая сторона имеет значение "Выход" (Output);

нижняя сторона имеет значение "Механизм" (Mechanism).

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

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

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

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

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

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

21. DEF0. Цель моделирования, границы системы и точка зрения модели

Цель моделирования

Цель моделирования определяется из ответов на следующие вопросы:

Почему этот процесс должен быть смоделирован?

Что должна показывать модель?

Что может получить клиент?

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

Модель может содержать четыре типа диаграмм:

контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

диаграммы декомпозиции;

диаграммы дерева узлов;

диаграммы только для экспозиции (FEO).

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

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

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

Стрелки(Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными.(Например, "Звонки клиентов", "Правила и процедуры", "Бухгалтерская система".)

22. Моделирование потоков данных (DFD)

Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD (как было сказано выше) – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища).

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

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

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

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

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

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

В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта — это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.