Вы находитесь на странице: 1из 98

Тема:

«Управление информационными
системами»

Конспект видеолекции
1/98
Оглавление
ВВЕДЕНИЕ ................................................................................................................................5
Раздел 1. ИТ-СТРАТЕГИЯ И БИЗНЕС-СТРАТЕГИЯ: СООТНОШЕНИЕ И ВЗАИМОСВЯЗЬ .6
Корпоративная архитектура .....................................................................................................6
ИТ-стратегия ............................................................................................................................. 7
Интеграция бизнеса и ИТ-стратегии ........................................................................................9
Связь ИТ-стратегии и развития бизнеса................................................................................10
Пример ИТ-стратегии на базе системы сбалансированных показателей ...........................11
Этапы разработки ИТ-стратегии ............................................................................................12
Оценки стратегического развития ИТ и отношений ИТ с бизнесом .....................................14
Раздел 2. ОБЗОР МЕТОДОЛОГИЙ И СТАНДАРТОВ. ПОДХОДЫ К ЖИЗНЕННОМУ ЦИКЛУ
КИС ..........................................................................................................................................15
Метамодели ИТ-стратегии .....................................................................................................15
Понятия проекта, качества, сервиса, стандарта и методологии ..........................................16
Стандарты, используемые в проектном и сервисном подходах ..........................................18
Иерархия управления ИТ в компании и уровень ее зрелости ..............................................19
Раздел 3. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ.........................................................21
Проектно-сервисные методологии бизнес-моделирования .................................................21
Основные понятия IDEF0. ......................................................................................................23
Функциональный блок.............................................................................................................23
Интерфейсная дуга .................................................................................................................23
Декомпозиция.......................................................................................................................... 25
Глоссарий ................................................................................................................................27
Ограничения по детализации декомпозиции. Возможности IDEF0 и ARIS..........................27
Пример моделирования бизнес-процесса «Прием специалиста в штат» ...........................28
Пример моделирования бизнес-процесса «Увольнение сотрудника».................................31
Раздел 4. ИТ-БЕЗОПАСНОСТЬ ДЛЯ МЕНЕДЖЕРА .............................................................35
Политика безопасности и программное обеспечение ..........................................................35
Стандарты защиты информации ...........................................................................................36
Место ИТ-безопасности в структуре информационной безопасности .................................37
Рынок информационной безопасности..................................................................................38
Защита на файловом уровне .................................................................................................38
Средства авторизации и разграничения доступа, защита от несанкционированного
доступа ....................................................................................................................................40

2/98
Защита от внешних угроз. Сигнатурная и морфологическая фильтрация ..........................41
Комплексы антивирусной профилактики ...............................................................................43
Средства обеспечения конфиденциальности, целостности, доступности и подлинности
информации, передаваемой по открытым каналам связи ...................................................44
Общие тенденции в ИТ-безопасности ...................................................................................46
Раздел 5. ИТ-АУДИТ ДЛЯ БИЗНЕСА .....................................................................................46
Понятие и план работ по ИТ-аудиту ......................................................................................46
Понятие эффективности/результативности ..........................................................................48
Оценка эффекта от внедрения ИТ: финансовые методы ....................................................50
Приведенные показатели ROI, их достоинства и недостатки ..............................................52
Шаблон расчетов ROI в области модернизации ИТ (упрощенный) .....................................53
Оценка эффекта от внедрения ИТ: качественные методы ..................................................55
Оценка эффекта от внедрения ИТ: вероятностные методы ................................................56
Вопросы для ИТ-аудита..........................................................................................................57
Раздел 6. СЕРВИСНЫЙ ПОДХОД НА ОСНОВЕ МЕТОДОЛОГИИ ITIL ................................58
История развития ITIL .............................................................................................................58
Версии ITIL ..............................................................................................................................58
Жизненный цикл ITIL...............................................................................................................59
Управление уровнем сервиса ................................................................................................60
Каталог услуг (SLA) .................................................................................................................61
Варианты построения службы Service Desk ..........................................................................63
Разделы каталога услуг. Показатели деятельности .............................................................63
Управление инцидентами.......................................................................................................66
Управление проблемами ........................................................................................................69
Управление конфигурациями .................................................................................................70
Управление изменениями ......................................................................................................72
Управление релизами.............................................................................................................73
Последовательность внедрения, типовые роли и показатели .............................................74
Управление мощностями и непрерывностью ........................................................................75
Управление доступностью ......................................................................................................76
Управление ИТ-Финансами и информационной безопасностью .........................................77
Заключение .............................................................................................................................78
ПРИЛОЖЕНИЕ ........................................................................................................................ 79
Рекомендуемый порядок внедрения процессов для существующих ИТ-сервисов .............79

3/98
Рекомендуемый порядок внедрения процессов для новых ИТ-сервисов ...........................79
Взаимосвязь между типичными проблемами в работе ИТ-подразделения и процессами
ITIL ...........................................................................................................................................80
Возможные KPI-метрики .........................................................................................................80
Вопросник для пошаговой методики внедрения ITIL-процессов ..........................................81
Глоссарий ................................................................................................................................84
Список литературы и Интернет-ресурсов..............................................................................97

4/98
ВВЕДЕНИЕ
Мы с вами уже знакомы с основными подходами к проблемам информации,
информационных технологий и систем (ИТ и ИС) со стороны гуманитарных наук и наук,
изучающих информацию, которые впервые определили, что такое информационная
технология и информационная система. Теперь проанализируем подходы к ИТ и ИС со
стороны наук о бизнесе, то есть будем рассматривать информационные технологии как
обычный бизнес-процесс.
Напомним метафору, которой мы определяли шкалу роста ценности информации.
Знания, компетенции и лучшие практики, выраженные и оформленные в концепциях,
теориях, методиках и других формах теоретического знания, составляют «вершину
айсберга», за которую можно «зацепиться», чтобы не утонуть в «океане информации»,
предоставленном расширяющейся цифровой вселенной.
Что же делать менеджеру, находящемуся на вершине пирамиды? Разумеется,
воспользоваться знаниями, полученными в других модулях программы «МВА-старт»
(например, из модуля, посвященного стратегическому менеджменту) и применить свои
бизнес-знания к задачам управления ИТ.
Напомним, что управленческой вершиной любого бизнеса являются стратегия и миссия –
как цель, выражающая философию и смысл существования бизнеса. На вершине
пирамиды находится стратегия бизнеса, далее – ее организационная структура, ситема
управления, сами бизнес-процессы и, наконец, их ресурсная база в виде ИТ. Если
рассмотреть «траекторию исторического развития» любого бизнеса, то ее можно
представить в виде чередования прямых пологих отрезков линии с крутыми поворотами и
изломами, которые отражают перемены в бизнесе, вызванные как внешними, так и
внутренними причинами, например кризисными явлениями, «болезнями роста» и пр.
Именно в переломные периоды компания резко меняет свою стратегию, например,
принимая решение о выходе на новые рынки, отказе от каких-либо видов деятельности,
разделении компании или слиянии ее с другими. Каждый такой поворот связан со
стратегическими решениями, которые руководители и владельцы принимают в кризисных
условиях.

Рис. 1. Структура системы управления компанией.

5/98
Цель изучения курса «Управление информационными системами» – познакомить
слушателей с основами управления информационными системами современной
компании, аудита и безопасности ИТ, с особенностями различных методологий,
подготовить к принятию взвешенных решений по выбору и внедрению тех из них, которые
наиболее полно отвечают интересам его бизнеса.

Раздел 1. ИТ-СТРАТЕГИЯ И БИЗНЕС-СТРАТЕГИЯ: СООТНОШЕНИЕ


И ВЗАИМОСВЯЗЬ

Корпоративная архитектура
Согласно постулатам стратегического менеджмента, цикл стратегического управления
состоит из 6 основных этапов:
1 – стратегический анализ;
2 – формулирование стратегии;
3 – передача стратегии в подразделения;
4 – реализация стратегии;
5 – мониторинг деятельности;
6 – принятие корректирующих мер.
Процесс стратегического управления непрерывен и представляет собой замкнутый
цикл. Анализ, оценка результатов деятельности и внесение корректив –
одновременно конец и начало цикла стратегического управления.
Для построения цикла стратегического управления используются хорошо
зарекомендовавшие себя концепции, например концепция системы сбалансированных
показателей (Balanced Scorecard, BSC), концепция целеполагания SMART, концепция
ключевых показателей деятельности KPI, концепция STEP, на основании которой
происходит изучение внешнего окружения; концепция SWOT-анализа как инструмента
разработки и оценки альтернативных вариантов стратегии и другие.
Эти и другие концепции помогают создать эффективную стратегию, которая должна
основываться на правильно выбранных долгосрочных целях, глубоком понимании
потребностей рынка и конкурентного окружения и реальной оценке собственных ресурсов
и возможностей.
Несмотря на то, что детализация разработки стратегии бизнеса зависит от его объема,
само формулирование стратегии обеспечивает координацию и баланс развития
различных направлений бизнеса, создает основу для оптимизации бизнес-процессов и
оперативных планов. Для малых и средних компаний такая формулировка может быть
выражена в неявном виде, то есть содержаться в голове владельца бизнеса. У крупных
компаний хорошо проработанная, непротиворечивая и принятая большинством
сотрудников стратегия может со временем позволить создать из разнообразных бизнесов
единый организм, работающий на достижение корпоративных целей под единой

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

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

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

Вместе с тем, разработке ИТ-стратегии присущи некоторые особенности, связанные с


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

Рис. 2. Роль ИТ в деятельности компании.

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

Рис. 3. Возможные факторы успеха (или провала) реализации ИТ-стратегии.


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

8/98
Рис. 4. Структура управления бизнесом и ИТ компании.

Интеграция бизнеса и ИТ-стратегии


Существует несколько признаков ситуаций, когда ИТ «не дружат» с бизнес-процессами,
которые они должны обеспечивать информационным обслуживанием. Исходя из
практики, этот список можно расширить.
1. Стабильно низкая надежность корпоративной информационной системы (КИС) в
целом.
2. Небольшие изменения функциональности КИС сопровождаются лавиной
доработок в решениях, связанных с нею.
3. Текущая работа менеджеров требует постоянного участия программиста.
4. Поддержка КИС в режиме эксплуатации превращается в бесконечный проект,
пожирающий рабочее время сотрудников и материальные средства компании.
В зависимости от силы подобного конфликта выделяют три варианта стыковки бизнес-
подразделений с ИТ-подразделениями.
· Реагирование: ИТ-стратегия формируется, когда бизнес-стратегия уже
разработана и готова; тогда деятельность «айтишников» подстраивается нужды
бизнеса;
· Выравнивание: адаптацию ИТ-стратегии к нуждам организации руководители
бизнес- и ИТ-подразделений выполняют по возможности совместно;
· Интеграция: бизнес-стратегию и ИТ-стратегию разрабатывают совместно,
учитывая взаимные нужды и возможности.

Самый эффективный, конечно, третий путь

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


ИТ-стратегия должна основываться на:

· результатах анализа бизнес-процессов предприятия;

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

· глубоком анализе нескольких вариантов ИТ-стратегии с оценкой факторов риска


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

· оценке стоимости, сроков и ресурсов для внедрения соответствующих


информационных технологий;

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

· этапности, то есть она должна предусматривать возможность изменений,


эволюции;

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


конкретному поставщику оборудования или программного обеспечения.
Наличие (или отсутствие) у компании/предприятия сформулированной ИТ-стратегии
влияет на:

· количество закрытых или «замороженных» ИТ-проектов;

· объем и структуру затрат на ИТ;

· структуру и численность ИТ-службы;

· долгосрочные финансовые показатели деятельности предприятия.


Оценки стоимости разработки ИТ-стратегии, которые приводят эксперты (в основном
зарубежные), достаточно сильно разнятся. С одной точки зрения, проекты по разработке
ИТ-стратегии стоят от 800 тыс. до 2 млн. долл., а продолжаются 3–6 месяцев. По другим
экспертным оценкам, такие проекты оцениваются в 10–50% стоимости проекта по
внедрению управленческой системы, то есть в сумму до 500 тыс. долл.

Связь ИТ-стратегии и развития бизнеса


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

Рис. 5. Взаимосвязь развития бизнеса и ИТ-стратегии.

10/98
Согласно схеме А, сначала должна быть формализована бизнес-стратегия,
усовершенствована оргструктура компании и бизнес-процессы, а затем можно приступать
к ИТ-стратегии. Эта схема укладывается в известную шутку «айтишников» о том, что
нельзя автоматизировать хаос. Если же информация или информационные сервисы
представляют собой ключевой продукт (схема Б), за счет которого бизнес получает
прибыль, то ИТ-стратегия может выступать инициатором трансформации оргструктуры и
даже выступать в качестве стратегии бизнеса. И, наконец, в том случае, когда
информация не является основным продуктом, но уже развитая ИТ-стратегия может и
должна служить ключевым инструментом повышения конкурентоспособности, она также
может стать инициатором перемен (схема В).

Пример ИТ-стратегии на базе системы сбалансированных показателей


В качестве примера рассмотрим планирование и развитие ИТ в компании на базе
концепции системы сбалансированных показателей – Balanced Scorecard (BSC),
разработанной профессорами Гарвардской школы бизнеса (Harvard Business School,
HBS) Робертом Капланом и Дэвидом Нортоном в их фундаментальных трудах Balanced
Scorecard и Strategic-Focused Organization. Эта система используется многими
консалтинговыми компаниями на российском рынке. Сама методология BSC довольно
проста и понятна, причем она взята за основу ведения систем управленческого учета на
российских предприятиях, реализацию которого патронирует Экспертно-консультативный
совет по вопросам управленческого учета при Министерстве экономического развития и
торговли Российской Федерации, созданный в мае 2002 года.
Традиционная концепция BSC предполагает формирование так называемых
стратегических карт, группирующих цели и показатели по четырем категориям
(перспективам):
1) финансы (финансовые цели развития и результаты работы компании –
оборот, прибыль, рентабельность и т.д.);
2) клиенты и рынки (цели присутствия на рынке и показатели качества
обслуживания клиентов – освоение рынков и территорий продаж, время
выполнения заказа, «идеальный заказ» и т.д.);
3) процессы (требования к эффективности процессов – стоимость, время,
количество ошибок, рискованность и т.д.);
4) развитие (цели поиска новых технологий и повышения квалификации
персонала).
Системы для измерения производительности и эффективности бизнеса, основанные на
финансовых метриках, используются на протяжении нескольких десятилетий, но в 1992
году Каплан и Нортон описали несколько моделей использования сбалансированных
оценочных карт в качестве системы управления эффективностью предприятия. Это
позволило не только менеджерам, но и всем служащим оценивать свою ежедневную
работу по отношению к стратегическим целям компании благодаря так называемым
причинно-следственным влияниям показателей друг на друга. В самом общем виде
логика такова: чем лучше у нас с квалификацией персонала и технологиями, тем проще
нам поддерживать эффективность бизнес-процессов, что, в свою очередь, способствует
качественному обслуживанию клиентов и реализации конкурентных преимуществ, а

11/98
последнее помогает достичь запланированных финансовых показателей.
Для измерения количественных показателей по индивидуальным стратегическим целям
используются ключевые показатели деятельности (Key Performance Indicators, KPIs). Эти
показатели, так или иначе, предоставляют информацию о достижении компанией
поставленных целей; в результате обеспечивается управление стратегией. Например,
среднеотраслевые KPIs также могут служить целями. Анализ отклонений дает
возможность реализовать непрерывные процессы повышения квалификации на
предприятии, как на оперативном, так и на стратегическом уровне.
Применительно к развитию ИТ методология BSC позволяет обеспечить их соответствие
целям бизнеса. На рис. 6 демонстрируется пример соответствия стандартных перспектив
BSC некоторому набору целей для планирования развития ИТ-направления.

Таблица 1. Перспективы и цели при планировании ИТ на основе BSC.

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

Этапы разработки ИТ-стратегии


Если в компании принято решение о разработке ИТ-стратегии, то всю
последовательность действий можно разбить на 9 этапов.
1. Решение о разработке ИТ-стратегии.
2. Постановка задачи перед внешними и внутренними рабочими группами, которые
участвуют в проекте, по методологии BSC, определение ключевых показателей
эффективности (KPIs).
3. Анализ условий и возможностей, возможно применение STEP-анализа.
4. Аудит ресурсов и компетенций по методологии BSC.

12/98
5. SWOT-анализ и разработка альтернатив развития.
6. Верификация целей по методологии CobiT. Цель верификации – анализ
соответствия ИТ-стратегии ожидаемым бизнес-эффектам.
7. Разработка ИТ-стратегии в виде формализованного документа.
8. Реализация ИТ-стратегии в виде долгосрочных бюджетов, планов, политик,
процедур и регламентов, то есть включение в должностные обязанности сотрудников
необходимого ИТ-функционала.
9. Измерения и контроль над реализацией ИТ-стратегии по методологии BSC.
Необходимо отметить наличие на рынке инструментов автоматизации применения
методологии BSC. Так, компания SAP AG (www.sap.com) разработала инструментарий
стратегического управления компанией SAP SEM, в основе которого лежит концепция
BSC. Используя карты решений (SAP Solution Map), инструментарий объединяет
реализацию коммуникаций «сверху вниз» в процессе развертывания стратегии на местах
с процессами мониторинга деятельности компании «снизу вверх».
Формулировка стратегии с помощью методологии Balanced Scorecard имеет три уровня
абстракции: корпорация, бизнес-единицы, производства. На корпоративном уровне
формулируется миссия компании, которая ориентирована на решение трех главных
вопросов.
1. Кто наши основные конкуренты?
2. Какие продукты/услуги должна продавать компания, основываясь на ее
способностях/компетенциях?
3. Какие рынки приоритетны для продуктов и услуг, предоставляемых компанией?
Руководство заинтересовано не только в мощной технологии стратегического
управления, но и в создании сильной и эффективной команды стратегического
управления. Каждый работник компании обязан знать, что он должен делать для
поддержки общей стратегии, а также свои персональные задачи. Чтобы достичь этого,
нужно следовать ряду принципов. Так, каждый работник компании должен точно знать,
каковы стратегические цели компании и его подразделения, отраженные в карте вкладов
подразделения (Scorecard). Кроме того, все сотрудники подразделения вместе с
менеджерами должны определить свои персональные задачи в рамках задач
подразделения. Эти персональные цели и задачи должны быть облечены в форму
электронного документа (персональная карта вкладов). Информация о выполнении
персональных задач и задач подразделений автоматически помещается в карты вкладов.
И, наконец, если происходят существенные отклонения от заданных целей, сотрудники
должны немедленно получать «тревожный сигнал» через электронные каналы.
Используя электронную почту или видеоконференцию, каждый сотрудник может
контактировать с коллегами независимо от своего местонахождения, для того чтобы
совместно найти выход и принять соответствующее решение по корректировке. Такой
подход не только служит мощным инструментом, который гарантирует согласованность
всех действий со стратегией, но и создает среду, которая стимулирует кооперацию,
обмен знаниями и коммуникацию между сотрудниками, заинтересованными в достижении
общего успеха.

13/98
Аналогичный продукт под названием Microsoft Balanced Scorecard Framework (BSCF)
создан компанией Microsoft (www.microsoft.com). Основной идеей успеха внедрения
сбалансированных оценочных карт (Balanced Scorecards), которые по природе своей
довольно изменчивы и, следовательно, подчас опасны, является условие их быстрой
разработки и развертывания на всех организационных уровнях. Для этого Microsoft
предлагает использовать уже имеющиеся на многих предприятиях многочисленные
приложения Microsoft – например, пакет Office, средства Analysis Services сервера SQL
Server, портал SharePoint и пр.

Оценки стратегического развития ИТ и отношений ИТ с бизнесом

Приведем некоторые экспертные оценки будущего стратегического развития ИТ и их


взаимоотношений с бизнесом, полученные от нескольких консалтинговых фирм, которые
занимались исследованиями стратегического управления ИТ для целей бизнеса. Прежде
всего, это компания Gartner http://www.gartner.com/. Согласно Gartner, сейчас
катастрофически не хватает «айтишников» с широким и глубоким пониманием бизнес-
задач, что не способствует успешному развитию бизнеса. Дисбаланс в ИТ-отделах между
техническими специалистами и сотрудниками с бизнес-ориентированными и
коммерческими знаниями и опытом будет устраняться постепенно. Так, доля людей,
имеющих опыт в бизнесе и принимающих стратегические решения в области ИТ,
увеличится с 40% в 2006 году до 75% к 2012 году, а к 2010 году значительный опыт в
бизнесе и сферах, не относящихся к ИТ, будут иметь 40% «айтишников». Кроме того,
эксперты из Gartner отмечают устойчивую тенденцию разделения ИТ-подразделений
компаний на две части. Одна из них будет заниматься развитием и поддержкой ИТ-
инфраструктуры, а другая – разработкой архитектуры корпоративных информационных
систем (КИС), а также изменением их функционала.
Аналогичные реалии взаимоотношений ИТ и бизнеса описывают и российские
исследователи рынков. Например, по результатам исследований «Практика
использования ИТ на российских предприятиях», проведенного журналом Intelligent
Enterprise в 2005 и 2007 годах (http://www.iemag.ru/), и «Стратегические цели предприятий
и ИТ», проведенного РА «Эксперт» (первым в России независимым рейтинговым
агентством, созданным в 1997 году журналом «Эксперт» http://www.raexpert.ru/), можно
выделить следующие тенденции развития и соотношения между ИТ и бизнесом:

· у 50% компаний соотношение расходов на ИТ и оборота компании не превышает


1% и имеет устойчивую тенденцию к снижению;
· почти 70% компаний более 50% ИТ-бюджета тратят на поддержку и эксплуатацию
(обычно о таком планировании финансов ИТ-директора узнают в последнюю
очередь), что свидетельствует о низкой доле инновационного бизнеса в России;
· ИТ-стратегия есть у 30% предприятий, и еще 50% хотят ее иметь;
· ИТ-стратегия нужна предприятиям, работающим на высококонкурентных рынках,
на розничных рынках, компаниям, специализирующимся на логистике, страховым
фирмам, банкам, предприятиям авиапрома, а также публичным и территориально
распределенным компаниям различных отраслей;

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

Раздел 2. ОБЗОР МЕТОДОЛОГИЙ И СТАНДАРТОВ. ПОДХОДЫ К


ЖИЗНЕННОМУ ЦИКЛУ КИС

Метамодели ИТ-стратегии
Как мы уже упоминали, существует множество методологий проектирования и внедрения
ИТ и ИС, которые устанавливают стандарт и технологию формирования бизнес-
требований, а также способы их эксплуатации в рамках бизнес-приложений. Каждой
конкретной организации, в идеале, требуется собственная оригинальная модель
взаимодействия ИТ и бизнеса, однако у подобных моделей можно выделить общие
черты, которые выражаются в метамодели ИТ-стратегии – наборе организационных
шаблонов, настраиваемых на реальные ситуации, и правилах их применения.
Созданием подобных метамоделей обычно занимаются консультанты. Однако практика
по выявлению общих черт и типовых узких мест в бизнес-процессах не слишком сложна и
полезна для любой компании. Не вдаваясь в подробности, которые можно узнать на
соответствующих сайтах, отметим следующие наработки в этой сфере.
· IEEE 1471 – метамодель корпоративной архитектуры, ориентированная на гибкие
подходы и множественность точек зрения на архитектуру.
· Business Motivation Model – метамодель выработки стратегии, миссии, целей,
критериев успешности, тесно связанная с корпоративной архитектурой.
· Software Process Engineering Metamodel (SPEM) – метамодель, предложенная в
2002 г. группой по объектному управлению OMG и первоначально нацеленная на
процессы разработки ПО. Но она хорошо подходит для любой деятельности по
оптимизации рабочих процессов.
· The Open Group Architecture Framework (TOGAF) – оболочка для
проектирования и управления по разделам «бизнес», «приложение», «данные» и

15/98
«технология». Более точно, но менее красиво она называется моделью
инфраструктуры архитектуры предприятия.
· стандарт Control Objectives for Information and related Technology (CobiT),
созданный Ассоциацией по аудиту и управлению информационными системами
ISACA и институтом ИТ-управления ITGI в 1992 г. В CobiT (последняя версия – 4.1)
включены рекомендации, индикаторы и лучшие способы, нацеленные на
согласование стратегий бизнеса и ИТ.

· Упомянем также модель общей ценности владения (Total Value of Ownership),


рекомендованную Gartner Group. Она подразумевает оценку отдачи от ИТ по пяти
направлениям: степень влияния ИТ на рабочие процессы; степень
согласованности стратегий ИТ и бизнеса; надежность, гибкость и
масштабируемость ИТ-архитектуры; измеряемая экономическая отдача; влияние
на бизнес-риски.
Эти методологии показывают, как правильно проектировать, внедрять и эксплуатировать
корпоративные ИС (КИС), но НИКОГДА не гарантируют получения реально значимых
результатов. И все они, при огромном разнообразии постоянно меняющихся бизнес-
требований и реализующих их бизнес-приложений, с точки зрения процессного подхода
сводятся к двум наиболее устойчивым типам корпоративной деятельности – проектному
и сервисному.

Понятия проекта, качества, сервиса, стандарта и методологии


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

Проект – это уникальная деятельность, имеющая начало и конец во времени,


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

Термин проект происходит от латинского слова projectus, что в переводе означает


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

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


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

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

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


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

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

В чем разница между методологией и стандартом?


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

17/98
осуществлять осознанный выбор.

Стандарты, используемые в проектном и сервисном подходах

Необходимо отметить, что научные схемы управления ИТ-процессами, которые


происходят из различных наук о бизнесе, не только помогают обеспечивать
согласованность выполнения операций, но и позволяют оценивать эффективность и
внедрять научный подход в области ИТ, в той области знаний, которая раньше
называлась «наукой о компьютерах», а воспринималась скорее как искусство.
Дополним метамодели, которые мы уже упоминали при разработке ИТ-стратегии, еще
несколькими наиболее популярными структурными схемами (методологиями и
стандартами), которые используются в проектных и сервисных подходах по управлению
бизнес-процессами на основе информационных технологий.
· ГОСТ Р ИСО 9000–2001, который определяет положения и словарь системы
менеджмента качества.
· Разрабатываемый в России фирмой «Ай-Теко» (www.i-teco.ru) национальный
стандарт под названием «Информационные технологии. Управление услугами»,
который будет состоять из двух частей: «Основные положения и словарь» (аналог
ISO/IES 20000-1:2005 «Information technology — Service Management. Part 1:
Specification», разработанного Британским институтом стандартизации) и
«Практическое руководство» (аналог ISO/IES 20000-2:2005 «Information technology —
Service Management. Part 2: Code of Practice»).
· Six Sigma – программа управления качеством на основе данных и фактов. Она
позволяет осуществлять контроль над изменениями и достигать очень высоких
уровней качества. В основу методологии Six Sigma (http://www.six-sigma.ru/) положена
статистическая зависимость, в соответствии с которой отказы происходят лишь в 3–4
случаях из миллиона, если верхняя и нижняя граница допустимых значений
контрольных параметров находятся на расстоянии шести среднеквадратических
отклонений от математического ожидания.
· Библиотека инфраструктуры информационных технологий (IT Infrastructure Library,
ITIL) – настраиваемая структурная схема, обобщающая передовой опыт и
позволяющая организовать предоставление высококачественных услуг в секторе
информационных технологий. Методология ITIL (http://www.itil-
officialsite.com/home/home.asp) построена на основе моделирования процессов,
используемых при выполнении операций управления и контроля. Наличие в
библиотеке исчерпывающего набора процедур управления позволяет
сформулировать требования к структуре ИТ-службы и квалификации ее
специалистов. В первоначальном виде ITIL была разработана 20 лет тому назад
правительственным агентством Великобритании. Отличительной чертой ITIL была
четкая ориентация на ИТ-операции. При правильном подходе ITIL помогает улучшить
качество обслуживания, снизить продолжительность простоев, ускорить разрешение
возникающих проблем и обеспечить более высокий уровень безопасности.
· Управление проектами (англ. project management) – область деятельности, в
ходе которой определяются и достигаются определенные цели, а также

18/98
оптимизируется использование ресурсов (таких как время, деньги, труд, материалы,
энергия, пространство и др.) в рамках некоторого проекта (определяющего конечный
результат и ограничение по времени и/или другим ресурсам). Управление проектом –
применение знаний, навыков, инструментов и методов для планирования и
реализации действий, направленных на достижение поставленной цели в рамках
проектных требований. Разработчиком этой методологии первоначально был
Институт по управлению проектами (Project Management Institute, PMI), разработавший
систему сертификации специалистов в области управления проектами, требования
которой изложены в «A Guide to the Project Management Body of Knowledge (PMBOK
Guide)», http://www.pmi.org.
Еще одним важным отличием между применением методологий и стандартов является
аспект сертификации. Если следование методологии, например, ITIL носит
рекомендательный характер, то внедрение стандарта, например, ISO/IES 20000-1:2005
требует тщательной сертификации ИТ-услуг, то есть оценки их соответствия стандарту.
Причем согласно международным соглашениям сертифицировать российскую компанию
имеют право только иностранные уполномоченные компании Британского института
стандартизации (BSI). Такая сертификация позволяет владельцу компании заявить о себе
на мировом рынке.

Иерархия управления ИТ в компании и уровень ее зрелости


Общая иерархия управления ИТ в компании отражает уровни зрелости развития ИТ.

Рис. 6. Иерархия управления ИТ в компании и уровень ее зрелости.

19/98
На нижнем, первом уровне находятся компании, которые определили свои ИТ-процессы
и описали их «как есть».
Второй уровень составляют организации, которые внедрили процессы в соответствии с
рекомендациями ITIL, но оставили открытым вопрос, когда и при каких условиях фирма
может считать себя более или менее полно внедрившей ITIL.
К третьему уровню относятся предприятия, которые строят управление ИТ-процессами
в соответствии с рекомендациями документа BSI BIP 0005 (руководства по управлению
сервисом).
На четвертом уровне зрелости находятся организации, которые создали систему
управления сервисом в соответствии с рекомендациями стандарта ISO 20000-2.
К пятому уровню относят компании, подтвердившие соответствие действующей
системы управления ИТ-услугами требованиям стандарта ISO 20000-1 – путем
сертификации аккредитованным органом.
В данном курсе мы не будем рассматривать ИТ с точки зрения проектного подхода, так
как в программе «МВА-старт» существует отдельный модуль «Управление проектами».
Основной акцент мы сделаем на сервисной модели функционирования ИТ в компании. В
частности, отдельный раздел будет посвящен рекомендациям методологии ITIL.
Сервисная модель ИТ реализуется через систему управления сервисом. В свою очередь,
она должна быть неразрывно связана с системой управления компанией. Это приводит к
концепции интегрированной системы управления или системы бизнес-менеджмента. Она
подразумевает, что разные компоненты управления объединяются в целое не
механически, а как система взаимосвязанных частей. К компонентам управления относят
организацию, ресурсы и процессы, поэтому персонал, оборудование и производственная
культура являются такими же неотъемлемыми частями системы, как документированные
политики и процедуры.
Итак, все, что влияет на бизнес-процессы, становится элементом системы бизнес-
менеджмента, а потому необходимы интеграция, формализация, стандартизация и
сертификация всех бизнес-процессов, в том числе и ИТ-процессов (ИТ-сервисов). Так как
основой любой системы бизнес-менеджмента является обеспечение качества бизнеса
согласно модели Деминга (Plan, Do, Check, Act), то для ИТ-сервиса это означает
подтверждение соответствия его качества, уровня и эффективности бизнес-целям
компании, ее стратегии и миссии. Поэтому для предоставления качественных ИТ-услуг в
компании должна быть создана соответствующая система ИТ-бизнес-менеджмента,
которая определяет организационную структуру, области ответственности, политики,
процедуры, стандарты и ресурсы.

20/98
Раздел 3. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ

Проектно-сервисные методологии бизнес-моделирования


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

Под «бизнес-моделированием» понимается как собственно моделирование бизнес-


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

Эти методологии можно представить в виде своего рода промежуточного слоя между
бизнесом и ИТ. «Гибридность» их заключается в том, что в условиях, например,
диверсификации бизнеса перед ИТ встают новые задачи по ИТ-поддержке бизнеса, то
есть развивать ИТ в компаниях нужно в том же темпе, в котором развивается бизнес.
Таким образом, в этих методологиях представлено одновременное сочетание сервисного
подхода с проектным. Рассмотрим кратко две наиболее популярные методологии: IDEF0
и ARIS.
IDEF0 – методология и графическая нотация, предназначенные для
формализации и описания бизнес-процессов.
Методологию IDEF0 можно считать следующим этапом развития хорошо известного
графического языка описания функциональных систем SADT (Structured Analysis and
Design Teqnique).
Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной
программы автоматизации промышленных предприятий, которая носила обозначение
ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом
Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало
свое обозначение от названия этой программы (IDEF=ICAM DEFinition). Последняя его
редакция была выпущена в декабре 1993 года Национальным институтом по
стандартам и технологиям США (NIST). После опубликования стандарт был успешно
применен в самых различных областях бизнеса, показав себя эффективным средством
анализа, конструирования и отображения бизнес-процессов (например, его активно
применяет Государственная налоговая инспекция). Более того, благодаря широкому
применению IDEF и предшествующей методологии – SADT – стало возможным
появление популярных понятий, связанных с бизнес-процессом реинжиниринга (BPR).
ARIS (сокр. от англ. Architecture of Integrated Information Systems) – методология и
программный продукт для моделирования бизнес-процессов, выпущенный
компанией IDS Sheer.
Методология ARIS рассматривает предприятие как совокупность четырех взглядов
(views):
– взгляд на организационную структуру,
– взгляд на структуру функций,

21/98
– взгляд на структуру данных,
– взгляд на структуру процессов.
При этом каждый из этих взглядов разделяется еще на три подуровня:
– описание требований,
– описание спецификации,
– описание внедрения.
Таким образом, ARIS предлагает рассматривать организацию с позиции 12 аспектов,
отображающих разные взгляды на предприятие, а также разную глубину этих взглядов.
Для описания бизнес-процессов предлагается использовать 85 типов моделей, каждая из
которых принадлежит тому или иному аспекту.
При описании бизнес-процессов с помощью одного из 85 типов моделей возможно
использование до 90 типов объектов (например, «функция», «класс», «организационная
единица»). Между различными типами объектов возможны различные типы связей
(например, «выполняет», «является входящим», «занимает позицию»). При этом у
каждого типа модели, объекта, связи имеется список типов атрибутов (например, «имя»,
«затраты», «время выполнения», «адрес»), значения которых задают пользователи и
система.
Важными качествами рассматриваемого семейства методологий являются, во-первых,
уникальная способность «задавать вопросы» в процессе моделирования, а во-вторых,
неразрывная связь графических средств (нотации), методологии и технологии.
Рассмотрим на примере методологии IDEF0, как они работают, а методологию ARIS
упомянем лишь в свете некоторых ее отличительных особенностей. Выбор обусловлен
тем фактом, что методология IDEF лежит в основе наших ГОСТов 34-й серии, которые мы
рассмотрели ранее, в то время как методология ARIS более сложна для понимания и
требует некоторых знаний по бизнес-аналитике, которые мы получим позже.
Итак, одной из самых важных возможностей, которая реализуется на базе методологии
IDEF0, является помощь менеджеру в подсчете «количества бизнесов» в рамках
определенного структурного подразделения компании или даже всего предприятия, а
также возможность определить их взаимодействие, то есть создать оптимальную
организационно-штатную структуру компании. Для достижения этой цели необходимо
исследовать все происходящие финансово-хозяйственные процессы и соответствующие
им потоки информации на предприятии. Далее нужно попытаться графически изобразить
взаимосвязи между различными элементами ранее определенной структуры. Как
правило, в «доинформационную эпоху» для этого использовались украшавшие стены
кабинетов менеджеров графические средства в виде схем, в которых отражались
«организационно-штатная структура», «диаграммы потоков данных» (ДПД),
документооборот компании. Эти «телодвижения» менеджеров стали прообразом методик
ДМД-моделирования, входящих в семейство CASE-технологий (Computer Aided Software
Engineering – компьютерное проектирование программных систем).

22/98
Основные понятия IDEF0.

В основе графического языка методологии IDEF0 (http://www.idefinfo.ru) лежат четыре


основных понятия

Функциональный блок

Понятие функционального блока (Activity Box).


Функциональный блок графически изображается в виде прямоугольника и
олицетворяет собой некоторую конкретную функцию в рамках рассматриваемого
бизнеса.
По требованиям стандарта, название каждого функционального блока должно быть
сформулировано в глагольной форме (например, «производить услуги», а не
«производство услуг»). Каждая из четырех сторон функционального блока имеет свое
определенное значение (роль), при этом:
· верхняя сторона имеет значение «Управление» (Control);
· левая сторона имеет значение «Вход» (Input);

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


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

Рис. 7. Модель функционального блока IDEF0.


Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь
свой уникальный идентификационный номер.

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

23/98
функциональным блоком или оказывает иное влияние на функцию, изображенную
данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка.
Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label).
По требованию стандарта, наименование должно быть формой существительного. С
помощью интерфейсных дуг отображают различные объекты, в той или иной степени
определяющие бизнес-процессы. Такими объектами могут быть элементы реального
мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы,
данные, инструкции и т.д.). В зависимости от того, к какой из сторон подходит данная
интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».
Кроме того, «источником» (началом) и «приемником» (концом) каждой функциональной
дуги могут быть только функциональные блоки, при этом «источником» может быть
только выходная сторона блока, а «приемником» – любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по требованиям IDEF0 должен
иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и
понятно – каждый процесс должен происходить по каким-то правилам (отображаемым
управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе
его рассмотрение не имеет никакого смысла. Существуют трудности в различии между
входящими и управляющими интерфейсными дугами, которые имеют внешне схожую
природу. Однако для преодоления этих трудностей, а также для проведения более
определенного разграничения, экосистему бизнеса классифицируют на пять основных
видов объектов:
· материальные потоки (детали, товары, сырье и т.д.);

· финансовые потоки (наличные и безналичные, инвестиции и т.д.);


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

· ресурсы (сотрудники, компьютеры, машины и т.д.).


При этом в различных случаях входящими и исходящими интерфейсными дугами могут
отображаться все виды объектов, управляющими – только относящиеся к потокам
документов и информации, а дугами-механизмами – только ресурсы. Поэтому при
создании IDEF-диаграммы деятельности своего функционального подразделения
менеджеру нужно ответить на следующие вопросы.
· Что поступает в подразделение «на входе»?

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


подразделения?
· Кто является ответственным за выполнение каждой из функций?
· Чем руководствуется исполнитель при выполнении каждой из функций?

· Что является результатом работы подразделения «на выходе»?

24/98
Декомпозиция
Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition).
Принцип декомпозиции применяется при разбиении сложного бизнес-процесса на
составляющие его функции. При этом уровень детализации процесса определяется
непосредственно разработчиком модели. Декомпозиция позволяет постепенно и
структурированно представлять модель бизнеса в виде иерархической структуры
отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Модель
IDEF0 всегда начинается с представления бизнеса как единого целого – одного
функционального блока с интерфейсными дугами, простирающимися за пределы
рассматриваемой области. Такая диаграмма с одним функциональным блоком
называется контекстной диаграммой и обозначается идентификатором «А-0». В
пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose)
построения диаграммы в виде краткого описания и зафиксирована точка зрения
(Viewpoint). Определение и формализация цели разработки IDEF0-модели являются
крайне важными моментами.
Различные цели моделирования предполагают разработку различных моделей бизнес-
процессов, то есть, например, цель «оптимизируем финансовые потоки» приводит к
другой модели, нежели цель «оптимизируем логистические цепочки». Точка зрения
определяет основное направление развития модели и уровень необходимой
детализации. Четкое фиксирование точки зрения позволяет разгрузить модель,
отказавшись от детализации и исследования отдельных элементов, не являющихся
необходимыми с выбранной точки зрения на моделирование бизнеса. Это и понятно, так
как точка зрения, допустим, финансового директора предприятия может существенно
отличаться от точки зрения главного технолога на те же бизнес-процессы. Правильный
выбор точки зрения существенно сокращает временные затраты на построение конечной
модели.
В процессе декомпозиции функциональный блок, который в контекстной диаграмме
отображает систему как единое целое, подвергается детализации на другой диаграмме.
Получившаяся диаграмма второго уровня содержит функциональные блоки,
отображающие главные подфункции функционального блока контекстной диаграммы и
называется дочерней (Child diagram) по отношению к нему (каждый из функциональных
блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним
блоком – Child Box). В свою очередь, функциональный блок-предок называется
родительским блоком (Parent Box) по отношению к дочерней диаграмме, а диаграмма, к
которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из
подфункций дочерней диаграммы может быть далее детализирована путем аналогичной
декомпозиции соответствующего ей функционального блока.
Важно отметить, что в каждом случае декомпозиции функционального блока все
интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на
дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели. Следует
обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм:
каждый блок имеет свой уникальный порядковый номер на диаграмме (цифру в правом
нижнем углу прямоугольника), а обозначение под правым углом указывает на номер
дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что
декомпозиции для данного блока не существует.

25/98
Рис. 8. Декомпозиция функциональных блоков.
Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать
рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии,
или наоборот: отдельные дуги не имеют практического смысла выше какого-то уровня –
это будет только перегружать диаграммы и делать их сложными для восприятия. С
другой стороны, случается необходимость избавиться от отдельных «концептуальных»
интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения
подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования.
Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала
интерфейсной дуги говорит о том, что эта дуга не была унаследована от
функционального родительского блока и появилась (из «туннеля») только на этой
диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной
дуги в непосредственной близи от блока-приемника означает, что в дочерней по
отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет.
Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги
не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае
они сначала «погружаются в туннель», а затем при необходимости «возвращаются из

26/98
туннеля».

Глоссарий
Последним из ключевых понятий IDEF0 является глоссарий (Glossary). Для каждого из
элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных дуг) существует
набор соответствующих определений, ключевых слов, повествовательных изложений и
т.д., которые характеризуют объект, отображенный данным элементом. Этот набор
называется глоссарием и является описанием сущности данного элемента.
Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий
может содержать перечень полей соответствующего дуге документа, необходимый
набор виз и т.д.
Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы
необходимой текстовой информацией.

Ограничения по детализации декомпозиции. Возможности IDEF0 и ARIS

Обычно IDEF0-модели несут в себе сложную и концентрированную информацию.


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

Итак, сформулируем основные возможности информационных средств бизнес-


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

1. Анализ бизнес-среды.
2. Разработка стратегии предприятия.
3. Формирование общего видения компании (глобальный уровень).

27/98
4. Формирование детального описания процессов компании «как есть» и «как будет».
5. Создание системы целей и показателей для оценки эффективности деятельности
компании и отдельных сотрудников.
6. Формирование организационной и функциональной структуры, распределение
полномочий и ответственности между подразделениями, функций между
исполнителями.
7. Описание требований к информационным системам поддержки деятельности.
8. Проектирование интегрированных информационных систем.
9. Проведение документирования результатов проекта.
10. Проведение анализа разработанных моделей (количественного и сравнительного
анализа, анализа семантики, анализа стоимостных и временных характеристик).
11. Интеграция моделей с функционирующими информационными системами
(актуализация организационной структуры, номенклатуры, показателей).

Таким образом, инструментарий IDEF0 и модули ARIS совместно с дополнительными


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

Пример моделирования бизнес-процесса «Прием специалиста в штат»

Рассмотрим опыт применения систем бизнес-моделирования для потребностей


менеджера по управлению персоналом по рекомендациям консалтинговой компании
«Бизнес-инжиниринговые технологии» - www.betec.ru. Примеры моделирования бизнес-
процессов: «Прием специалиста в штат», «Увольнение сотрудника».

Итак, первый бизнес-процесс «Приём специалиста в штат компании» имеет:

· Точку зрения на бизнес-процесс от генерального директора компании.


· Цели бизнес-процесса в виде «Формирование штата».
· Назначение бизнес-процесса – «Обеспечение компании необходимыми
специалистами».
· Выходы - «Заполненное рабочее место», «Приказ, трудовая книжка, личное дело,
карточка учета Т-12», «Информация об отказе», и «Объявления».
· Клиенты бизнес-процесса – «Профильное подразделение», куда поступает на
работу сотрудник, «Кадровый архив», «Соискатель должности» и «Средства
массовой информации – СМИ».
· Кроме того, поставщиками данного бизнес-процесса, являются два других бизнес-
процесса – «Сбор данных по специалистам» и «Формирование кадрового
резерва».
· Входы и поставщиков бизнес-процесса – «Запрос», «Соискатель», «Резюме»,
«Информация о кадровом резерве», «Профильное подразделение», «Рынок
труда», «Кадровые агентства», «Сотрудники компании».

28/98
· Основные стадии бизнес-процесса – «Первичный отбор», «Проведение встречи»,
«Вторичный отбор», «Стандартное согласование кандидатур», Оформление
трудовых отношений».
· Начало бизнес-процесса - «Запрос от профильного подразделения».
· Окончание бизнес-процесса – «Специалист принят в штат и занял рабочее место».

Рис. 9. Диаграмма окружения бизнес-процесса.


Диаграмма окружения бизнес-процесса приведена на Рис. 9. Структура действий на
каждой стадии бизнес-процесса отражена в таблице 2. Структура информационных
потоков в зависимости от типа носителя изображена в таблице 3. Диаграмма потоков
бизнес-процесса в нотации DFD с указанием исполнителей приведена на Рис. 10

29/98
Таблица 2. Структура действий по стадиям бизнес-процесса.

Таблица 3. Структура потоков объектов информации.

Совмещая «Структуру действий бизнес-процесса по его этапам с организационной


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

30/98
Таблица 4. Матрица ответственности бизнес-процесса «Прием специалиста в штат».

Пример моделирования бизнес-процесса «Увольнение сотрудника»

Второй бизнес-процесс, бизнес-моделирование которого мы рассмотрим – это


«Увольнение сотрудника», выполненный в нотациях DFD и IDEF0. Первичная
Диаграмма А-0 приведена на рис. 10.

Рис.10. Диаграмма А-0 самого верхнего уровня бизнес-процесса «Увольнение


сотрудника».

31/98
Рис. 11. Диаграмма А0. Бизнес-процесс «Увольнение сотрудника».

Рис. 12. Диаграмма А1 «Визировать заявление у непосредственного руководителя и


оформить обходной лист».

32/98
Рис. 13. Этапы потоков объектов бизнес-процесса «Заполнить обходной лист».

Рис. 14. Декомпозиция блока «Издать приказ об увольнении». Диаграмма А2.

33/98
Рис. 15. Декомпозиция блока «Произвести расчеты с бухгалтерией». Диаграмма А3.

Рис. 16. Декомпозиция блока «оформить и выдать трудовую книжку сотруднику».


Диаграмма А5.

34/98
Раздел 4. ИТ-БЕЗОПАСНОСТЬ ДЛЯ МЕНЕДЖЕРА

Политика безопасности и программное обеспечение


Ранее в программе «МВА-старт» вопросы информационной безопасности уже
рассматривались – в свете защиты корпоративных интересов и осуществления
безопасного предпринимательства в России. В этом курсе мы рассмотрим
информационную безопасность (ИБ) с позиций применения информационных технологий
(ИТ-безопасность), которые помогают осуществлять бизнес. Понятно, что ИБ и ИТ-
безопасность – это не одно и то же. За безопасность бумажных документов отвечает ИБ,
но не ИТ. Чтобы понять место ИТ-безопасности в структуре ИБ, а также процессы их
конвергенции, которые происходят на современном этапе развития ИТ, напомним общее
определение политики безопасности и те стандарты, по которым она осуществляется.
Политика безопасности для любой компании, как правило, рассматривается в
виде набора внешних и корпоративных стандартов, правил и норм поведения,
отвечающих законодательным актам страны и регламентирующих сбор,
обработку, распространение и защиту информации.
Такая деятельность регламентируется законодательством, примерами которого служат
«Доктрина информационной безопасности Российской Федерации» № Пр-1895 от
09.09.2000 г., Федеральные законы №149-ФЗ от 27 июля 2006 г. «Об информации,
информационных технологиях и о защите информации», № 152-ФЗ от 27 июля 2006 г. «О
персональных данных», № 16-ФЗ от 9 февраля 2007 г. «О транспортной безопасности»,
№ 98-ФЗ от 29 июля 2004 г. «О коммерческой тайне» и др. Эти документы определяют
стандарты и правила того, в каких случаях и каким образом пользователь имеет право
оперировать конкретными наборами данных.
Так, чтобы защитить свои информационные ресурсы в соответствии с действующим
законодательством, необходимо осуществить комплекс организационных и технических
мероприятий по защите информации, важной составляющей которого и является
применение сертифицированного в системе ФСТЭК России программного
обеспечения.
Например, операционная система Microsoft Windows XP Professional Service Pack 1a
соответствует заданию по безопасности MS.Win_XP_SP1a.ЗБ и имеет оценочный
уровень доверия ОУД 1 (усиленный) по руководящему документу «Безопасность
информационных технологий. Критерии оценки безопасности информационных
технологий» (ФСТЭК России). В то же время новое поколение операционных систем
Microsoft – Windows Vista – не прошло пока сертификацию, что делает
проблематичным применение данного ПО в государственных учреждениях и
компаниях, в той или иной мере связанных с государственной тайной.
В целом, политика безопасности – это активный компонент защиты, включающий в
себя анализ возможных угроз и рисков, выбор мер противодействия и
методологию их применения.

35/98
Стандарты защиты информации

На международном уровне правила и политика ИБ регламентируются международным


стандартом BS 7799, который был разработан и обновлялся Британским институтом
стандартов (BSI). В России стандарт ISO/IEC 17799 начал применяться на практике с
2002 года. В 2002 году стандарт BS был усовершенствован и вышла его новая редакция –
BS 7799-2:2002. На ее основе 14 октября 2005 года был принят стандарт ISO/IEC
27001:2005. Важно указать, что, в отличие от ISO/IEC 17799:2005, содержавшего
описание «лучших практик» и лишь рекомендовавшего их к внедрению, стандарт ISO/IEC
27001:2005 выдвигает жесткие требования к разработке, внедрению и
совершенствованию систем управления информационной безопасностью (СУИБ), что
позволяет проводить сертификацию на соответствие его требованиям. Развитие серий
стандартов BS 7799 и ISO/IEC 27000 продолжается: ожидается принятие стандарта
ISO/IEC 27002, который сменит ISO/IEC 17799:2005, и ISO/IEC 27005, который определит
требования к методике оценки рисков и будет основываться на недавно принятом
стандарте BS 7799-3:2006.
Суть стандартизации ИБ состоит в выборе адекватных мер по защите активов компании
от идентифицированных угроз в соответствии с их критичностью для бизнеса. В них
обобщены правила по управлению ИБ, которые могут быть использованы в качестве
критериев оценки механизмов безопасности организационного уровня, включая
административные, процедурные и физические меры защиты.
Практические правила разбиты на десять разделов.
1. Политика безопасности.
2. Организация защиты.
3. Классификация ресурсов и их контроль.
4. Безопасность персонала.
5. Физическая безопасность.
6. Администрирование компьютерных систем и сетей.
7. Управление доступом.
8. Разработка и сопровождение информационных систем.
9. Планирование бесперебойной работы организации.
10. Контроль выполнения требований политики безопасности.

36/98
Место ИТ-безопасности в структуре информационной безопасности
Место ИТ-безопасности в структуре ИБ легко понять при структурировании деятельности
по уровням обработки информации.

Рис. 17. Уровни управления в отношении ИТ-безопасности.


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

37/98
Рынок информационной безопасности

Рис. 18. Рынок информационной безопасности.

Из всего разнообразия средств ИБ (ИТ), которое предлагает рынок, мы остановимся


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

Защита на файловом уровне

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


информации, которые будут полезны всем владельцам бизнес-процессов.
Средства обеспечения надежного хранения информации с использованием
технологии защиты на файловом уровне (File Encryption System, FES)
Технологии защиты информации на файловом уровне позволяют скрыть
конфиденциальную информацию пользователя на разнообразных носителях (жестком
диске компьютера или сетевых дисках) путем кодирования содержимого файлов,
каталогов и дисков. Доступ к данной информации осуществляется по предъявлению
ключа, который может вводиться с клавиатуры, храниться и предоставляться со смарт-
карты, HASP-ключей или USB-ключей. Помимо этого, данные средства позволяют
мгновенно «уничтожить» информацию при подаче сигнала «тревога» или при «входе под
принуждением», а также блокировать компьютер в перерывах между сеансами работы.

38/98
Пример решения защиты отдельных документов
Достаточно часто перед людьми возникает задача защиты различных документов от
несанкционированного доступа. Допустим, информационное или аналитическое агентство
обязалось предоставлять своим подписчикам различные документы. Но ведь нет никакой гарантии
того, что кто-нибудь из клиентов по неосторожности или намеренно не выложит полученную
информацию, например, в Интернет. Таким образом, данные, за которые люди должны платить
деньги, окажутся в свободном доступе. Как можно решить эту проблему? Специалисты Aladdin
Software Security предлагают следующий вариант решения: документ переводится в формат
HTML, а затем зашифровывается с помощью ключа HASP (Hardware Against Software Piracy – это
мультиплатформенная аппаратно-программная система защиты данных от нелегального
использования и несанкционированного распространения, разработанная компанией Aladdin). Для
последующего чтения используется специальная утилита HASP DocSeal. Фактически она
представляет собой программу-браузер для просмотра защищенных HTML-файлов. Правда, от
обычных браузеров ее отличают две вещи. Во-первых, она позволяет расшифровывать
документы, только если соответствующий ключ HASP подключен к компьютеру или серверу
локальной сети. А, во-вторых, в HASP DocSeal полностью отсутствуют возможности импорта
содержимого защищенного HTML-файла. Это позволяет надежно защитить документ от
копирования. Конечно, пользователь может открыть текст и перепечатать его вручную. Однако это,
во-первых, требует больших трудозатрат, а во-вторых, от такого способа обмана защиты пока не
существует.

Актуальность проблемы защиты данных на серверах и в резервных копиях


подтверждается большим количеством инцидентов, происходящих с этими носителями в
последнее время. Основными предпосылками этого многие аналитики называют
повышение степени централизации данных, увеличение их объемов, а также рост
емкости и миниатюризацию носителей. Кроме этого, в последнее время, в связи с
ориентацией бизнеса на клиента, стали бурно развиваться системы типа CRM, где
накапливаются персональные данные (адреса, номера паспорта/водительского
удостоверения, номера счетов и т.д.), которые могут быть использованы для того, что
сейчас называют «кражей личности» (Identity Theft). Наиболее приемлемой технологией
защиты, известной сегодня, является шифрование. Если данные на носителе
зашифрованы, то можно не беспокоиться об их обнародовании – вне зависимости от того,
где этот носитель физически находится, какими путями перевозится, к кому в руки
попадает и т.д. Естественно, это так лишь при условии, что ключ шифрования хранится и
передается отдельно от носителя. По оценкам большинства экспертов, для решения
такой задачи вполне подходят современные симметричные криптоалгоритмы (например,
AES) с длиной ключа от 128 бит. Шифрование должно быть «прозрачным», то есть
данные должны автоматически зашифровываться при записи на носитель и
расшифровываться при чтении. Наиболее популярными решениями в этой области
являются решения российских компаний: StrongDisk Server компании «Физтехсофт»,
SecretDisk Server NG компании Aladdin и Zserver Suite компании SecurIT. Первые две
системы обеспечивают защиту только на жестких дисках, а Zserver Suite – на жестких
дисках, магнитных лентах и CD/DVD. Из зарубежных производителей следует упомянуть
таких разработчиков, как Pointsec, Safeboot, PGP, Decru Datafort, Neoscale Cryptostor и
DISUK Paranoia.
Необходимо отметить, что компетенции, знания и навыки в криптографии становятся все
более востребованными в быстро меняющемся современном мире и уже
рассматриваются экспертами в качестве третьего уровня грамотности (компьютерная

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

Средства авторизации и разграничения доступа, защита от


несанкционированного доступа
Информационные технологии находятся сегодня в противоречивой ситуации: с одной
стороны, от ИТ требуют максимальной гибкости и открытости в пользовании
информацией, c другой стороны, они находятся под сильным давлением требований к
конфиденциальности корпоративных данных. Отсюда и требования по применению
средств ИТ-безопасности:
· предотвращение несанкционированного доступа к базам данных или
злоупотреблений содержащейся в них информацией;
· предотвращение утечки информации из организации через общие каналы связи;
· обеспечение информационной безопасности ноутбуков и съемных носителей
данных.
Необходимо признать, что системы ИТ-безопасности пока не имеют «защиты от дурака»,
т.е. ничто не помешает инсайдеру брать конфиденциальные данные домой на своем
ноутбуке или копировать их на съемный носитель. Но обнаружить утечку информации и
потом найти и наказать виновного они могут. По данным CNews Analytics, 33% и 20%
инцидентов, связанных с утечкой информации из компании и использованием ее в
корыстных целях, вызваны нынешними и бывшими сотрудниками, соответственно, 11%
приходятся на долю клиентов компании, 8% происходят по вине партнеров, 7% вызваны
временными служащими (контрактниками, консультантами и т.д.). Таким образом, за 60%
всех инцидентов несут ответственность нынешние, бывшие и временные сотрудники
компании, что поднимает проблему утечек конфиденциальной информации на первое
место в списке приоритетов руководства компании.
Существует ряд специализированных решений мировых разработчиков ПО
разграничения доступа и идентификации клиентов. Например, Hewlett-Packard
разработала комплекс программных продуктов Identity Manager, компания Oracle –
COREid Access & Identity, компания Sun – Java System Identity Manager, и Novell – свой
Identity Manager. Все эти решения предназначены для централизованного управления
идентификацией и доступом к различным информационным ресурсам предприятия, в
том числе через веб-интерфейсы. Все производители позиционируют эти решения в
первую очередь как инструмент повышения надежности и безопасности бизнеса в
целом.
Довольно быстрыми темпами развивается индустрия биометрического сканирования и
распознавания при авторизации и доступе. Главный стимул развитию отрасли придает
синергетический эффект от сочетания многих тенденций и факторов. В число наиболее

40/98
значимых из них входят:
– наращивание спектра применений биометрии в государственных системах;
– осознание бизнес-структурами потребности и необходимости в распознавании людей (а
не жетонов или карт) при доступе в здания и к корпоративным информационным
ресурсам;
– рост мобильности населения и децентрализация управления человеческими
ресурсами, требующие надежной идентификации;
– расширение числа сервисов «электронного правительства», при котором государство
заинтересовано в адресном предоставлении соответствующих информационных услуг, то
есть в идентификации граждан. Ключевые российские производители биометрических
средств ИБ перечислены в таблице.
Таблица 5 . Ключевые российские производители биометрических средств ИБ.
Компания Город Продукция

BioLink Москва Биометрические считыватели, серверы аутентификации,


пакет разработчика BioLink SDK

«Биометрические Москва Сканеры отпечатков пальцев, пакет разработчика SmartID


технологии» SDK

ЗАО «Биопаспорт» Санкт-Петербург Фирма организована специально под всероссийский проект


«Биометрический паспорт»

«Папилон» Челябинск Системы АДИС

«Сонда» Челябинск Системы АДИС, биометрические считыватели, пакет


разработчика Sonda SDK

«ЦентрИнвестСофт» Москва Решения на основе биометрических технологий:


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

«Элвис» Москва СКУД, биометрические считыватели, системы контроля


рабочего времени
«Элсис» Санкт-Петербург Сканеры отпечатков пальцев, биометрические считыватели

Защита от внешних угроз. Сигнатурная и морфологическая фильтрация


Рассмотрим средства защиты от внешних угроз при подключении к общедоступным сетям
связи (Интернету), а также средства управления доступом из Интернета с
использованием технологии межсетевых экранов (FireWall) и содержательной
фильтрации (Content Inspection).
Использование технологии межсетевых экранов предлагается для решения таких задач,
как:
· безопасное взаимодействие пользователей и информационных ресурсов,
расположенных в интернет- и интранет-сетях, с внешними сетями;

41/98
· создание технологически единого комплекса мер защиты для распределенных и
сегментированных локальных сетей подразделений предприятия;
· построение иерархической системы защиты, предоставляющей адекватные
средства обеспечения безопасности для различных по степени закрытости сегментов
корпоративной сети.
Вместе с тем, сегодня технология межсетевого экрана уже не гарантирует, что ваш
компьютер или ваша сеть не станут своего рода «зомби» какой-нибудь бот-сети.
Бот-сеть (bot network – сеть роботов) – множество компьютерных систем,
находящихся под единым управлением без ведома владельцев компьютеров.
Обычно используются для нелегальной или неодобряемой деятельности –
рассылки спама, перебора паролей на удаленной системе, атак на отказ в
обслуживании.
Сегодня на рынке становятся востребованными системы предотвращения вторжений
(Intrusion Prevention System, IPS), примерами которых являются:
· Proventia GX6116 фирмы IBM;
· устройство IntruShield 10 Gb фирмы McAfee.
Принципиальное назначение этих систем предотвращения вторжения – в том, чтобы
обеспечить безопасность защищаемых объектов от воздействия, которое признано
вторжением или нарушением безопасности. При этом времена, когда для обнаружения
факта атаки считалось достаточным найти некий характерный шаблон трафика
(сигнатуру), уже прошли. Сегодня считается, что для успешного обнаружения атак IPS
должна обладать свойствами и функциями обучения и самообучения.
Для борьбы со спамом, вирусами и утечками информации широко используются системы
фильтрации контента (Content Inspection).
Существуют два концептуально разных подхода к фильтрации – сигнатурный и
морфологический.
· Обнаружение, основанное на сигнатурах – метод работы антивирусов и систем
обнаружения вторжений, при котором программа, просматривая файл или пакет,
обращается к базе с известными атаками, составленной авторами программы. В случае
соответствия какого-либо участка кода просматриваемой программы известному коду
(сигнатуре) вируса в базе, программа-антивирус может заняться выполнением одного из
следующих действий:
– удалить инфицированный файл;
– отправить файл в «карантин» (то есть сделать его недоступным для выполнения с
целью недопущения дальнейшего распространения вируса);
– попытаться восстановить файл, удалив сам вирус из тела файла.
Примером решения является продукт компании Clearswift MIMEsweeper.
· В состав решения для морфологической фильтрации входит сервер контентной
фильтрации, с помощью которого определяется, какая информация является
конфиденциальной, а какая – публичной. За фильтрацию контента отвечает движок,

42/98
который использует не сигнатурные методы, а морфологические технологии. Это
означает, что при внедрении решения создается специальная база контентной
фильтрации, в которую заносятся все конфиденциальные документы организации.
Обработав все эти документы, движок в состоянии выявлять чувствительную
информацию, специфичную для данной конкретной компании. Преимуществами данной
технологии, в отличие от сигнатурного поиска, являются возможность полноценной
фильтрации русскоязычных текстов во всех кодировках, а также учет абсолютно всех
словоформ корневых морфем, огромное количество которых специфично именно для
славянских языков. Сигнатурный фильтр просто не в состоянии учесть все возможные
словоформы, так как администратору необходимо самому задавать ключевые слова
(сигнатуры), являющиеся конфиденциальными для данной организации. Более того,
точность морфологических технологий позволяет блокировать утечку даже малых
фрагментов конфиденциальных документов, и при этом вовсе не требуется совпадение
проверяемых данных с образцами из базы контентной фильтрации. Даже если
инсайдер перефразирует текст, воспользовавшись синонимами и по-другому построив
предложения, фильтр все равно предотвратит утечку.
Примером решения является InfoWatch Enterprise Solution.

Комплексы антивирусной профилактики


Лавинообразное распространением вирусов («червей», «троянских коней», шпионских
программ) действительно стало большой проблемой для большинства компаний и
государственных учреждений.
Так, в марте 2006 года сканеру Norton Antivirus было известно около 72 тысяч вирусов, а
база программы содержала порядка 400 тысяч сигнатур. Каждый месяц появляется более
300 новых разновидностей вредоносных программ. При этом считается, что основной
путь «заражения» компьютеров – через Интернет. Поэтому в настоящее время стало
недостаточно технологической реактивности антивирусной защиты, когда компьютер уже
заражен и начинает свою работу антивирус. Отсюда важнейшей тенденцией развития
антивирусного ПО стало применение проактивных технологий эффективной защиты в
период «окна уязвимости», пока угрозы еще не классифицированы антивирусными
разработчиками. Речь идет о системах предотвращения атак уровня хоста и контроля
сетевого доступа. Примером может служить решение фирмы McAfee Total Protection. Мы
не будем подробно останавливаться на примерах антивирусных программ. Приведем
лишь результаты тестирования, на основании которых можно выбрать ту или иную
защиту от вирусов. Данный тест проводился под операционной системой Windows XP
SP2 по следующим группам атак:
– изменение разрешений на доступ к файлам и ключам реестра,
– модификация/удаление модулей, удаление антивирусных баз,
– модификация/удаление значимых ключей реестра,
– завершение процессов,
– модификация процессов/кода

43/98
– выгрузка драйверов.
Всего проводилась проверка по 33 параметрам, отсюда и максимальный балл – 33.
Результаты теста представлены в таблице (источник: http://www.anti-malware.ru, 2007).
Таблица 6. Итоговые результаты теста самозащиты антивирусов.

Доля от
Всего баллов
Тестируемый продукт максимально
(максимум 33)
возможного

Kaspersky Internet Security 7.0 32 97%

VBA32 Antivirus 3.11 23,5 71%

Symantec Internet Security 2007 23,5 71%

F-Secure Internet Security 2007 20 61%

ZoneAlarm Internet Security 7.0 19 58%

Panda Internet Security 2007 16 48%

McAfee Internet Security 2007 15,5 47%

Eset Smart Security 3.0 14,5 44%

Trend Micro PC-Cillin 2007 14 42%

Avast! Professional Edition 4.7 11 33%

Avira Premium Security Suite 7.0 11 33%

Sophos Anti-Virus 6.5 11 33%

DrWeb 4.44 Beta 10,5 32%

Microsoft Windows Live OneCare 1.6 10,5 32%

BitDefender Internet Security 10 10 30%

Средства обеспечения конфиденциальности, целостности, доступности и


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

44/98
Классификация не должна быть избыточной, иначе это приведет к большим расходам.
Разумеется, защищать нужно прежде всего конфиденциальную информацию.
Таблица 7. Классификация ценности данных.

Общедоступная (public) Открытая информация при работе с которой нет никаких ограничений
Чувствительная
Информация ограниченного доступа
(sensetive)
Персональные данные. Например зарплатная ведомость,
Персональная (private)
медицинские карточки, адресные книги сотрудников
Конфиденциальная информация. При работе с ней вводятся
Конфиденциальная
ограничения в зависимости от уровня допуска пользователя.
(confidential)
Например бухгалтерская, производственная.

Пример инвентаризации информационных ресурсов

Вид информации Содержание Расположение Гриф


Планы производства,
интеллектуальная
Файловые сервера,
Производственная собственность, описание Конфиденциальные
СУБД
технологий, внутренние
разработки
Карты ИТ-инфраструктуры, ИТ-
Инфраструктурная локально Чувствительная
системы, логины, пароли
Любая бухгалтерская
Финансовая информация, финпланы, Среда финдепа Конфиденциальная
отчёты, балансы.
Локально, файловый
Кадровая Личные карточки персонала Чувствительная
сервер
Расшаренные папки
Файлы и документы для
Рабочая или выделенный Персональная
внутреннего обмена
файловый сервер
Отчёты собраний, приказы,
Внутрикорпоративная Файловый сервер Общедоступная
распоряжения, статьи
Расшаренные папки
Фотографии, видеоролики,
Развлекательная или выделенный Общедоступная
фильмы, аудиокниги
файловый сервер

Для защиты информации, передаваемой по открытым каналам связи, и построения VPN


на основе международных стандартов IPSec существует ряд программных продуктов.
Виртуальные сети создаются чаще всего на базе арендуемых и коммутируемых каналов
связи в сетях общего пользования (Интернете). Для применения Интернета в бизнесе
должны функционировать системы, имеющие такие характеристики, как надежность и
безопасность. Без современных технологий защиты электронный бизнес основного
сектора В2В (Business-to-Business) не переживал бы такого бурного развития, которое в
значительной степени зависит от фактора доверия. Доверие связано с безопасностью –
чем более прозрачна и надежна защита, тем выше степень доверия и шире область
использования решений.

А для этого необходимо решить такие задачи, как:


· защита (конфиденциальность, подлинность и целостность) передаваемой по сетям
информации;

45/98
· контроль доступа в защищаемый периметр сети;
· идентификация и аутентификация пользователей сетевых объектов;

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


Одним из современных способов решения является внедрение электронной цифровой
подписи (ЭЦП) – одного из сервисов безопасности, который помогает решать задачи
целостности, доступности и невозможности отказаться от авторства. Для полноценного
функционирования электронной цифровой подписи требуется создание развитой
инфраструктуры, которая известна в России как инфраструктура открытых ключей
(Public Key Infrastructure, PKI – в международной терминологии). Под этим термином
понимается полный комплекс программно-аппаратных средств, а также организационно-
технических мероприятий, необходимых для использования технологии с открытыми
ключами. Основным компонентом PKI является собственно система управления
цифровыми ключами и сертификатами. Все развитые страны мира, в том числе и Россия,
формируют подобные национальные инфраструктуры.

Общие тенденции в ИТ-безопасности

Итак, мы рассмотрели лишь некоторые аспекты конвергенции ИБ и ИТ. Помимо


технологической конвергенции, существуют также конвергенция организационная и
архитектурная, основанные на сервисном подходе методологии ITIL, которая, по
прогнозам Gartner, достигнет своего пика лет через 5–10. Сервисный подход одинаково
распространяется и на область ИТ, и на область ИБ. В данном случае применение
сервисов – это аналог модульного принципа в инженерии и многих других сегментах и
отраслях. Не надо строить единую и неповторимую систему защиты – она должна быть
модульной, гибкой и удобной. Каждый модуль, сервис или процесс должен иметь
понятный вход и понятный выход. Это позволит при необходимости менять отдельные
модули не в ущерб остальным. Монолитность сегодня уже не приветствуется, так как не
отвечает задачам гибкости и адаптивности ИТ- и ИБ-инфраструктур. Такой подход
позволяет реализовывать проект создания системы информационной безопасности
поэтапно – сервис за сервисом, процесс за процессом. В качестве таких сервисов,
применимых как к ИТ, так и к ИБ, можно назвать управление инцидентами, управление
изменениями, управление доступностью, управление конфигурацией и т.д.

Раздел 5. ИТ-АУДИТ ДЛЯ БИЗНЕСА

Понятие и план работ по ИТ-аудиту

Под термином «аудит информационной системы» понимают процесс получения и оценки


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

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


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

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

1. Инвентаризация имеющейся техники.


2. Осмотр локальной сети и сетевого оборудования.
3. Составление плана работ по ИТ-аудиту и схемы взаимодействия сетевых
компонентов.
4. Выявление ключевых проблемных моментов в работе сетевого и компьютерного
оборудования.
5. Сбор информации, жалоб и пожеланий конечных пользователей по работе
компьютеров, сети, оргтехники и программного обеспечения.
6. Подготовка заключения о работе компьютерной техники, программного
обеспечения, сетевых компонентов и оргтехники.
7. Разработка предложений по оптимизации работоспособности всей
инфраструктуры.
8. Составление плана оптимизации работы имеющегося компьютерного
оборудования и программного обеспечения на рабочих станциях и серверах.
9. Составление календарного плана работ по дальнейшему обслуживанию
компьютерной техники, оргтехники, сетевых компонентов и программного
обеспечения.
По данным опроса агентства CNews Analytics, самой распространенной проблемой ИТ-
инфраструктуры в российских компаниях считается сбой серверного оборудования и
нарушение удаленного доступа к сети (40%). Нa втором и третьем местах по
«популярности» – повреждение данных (35%) и неслаженная работа информационной
системы в целом (30%). В плане бизнес-проблем главные причины беспокойства –
несовершенная техническая база (40%), а также трудности, связанные с организационной
структурой (35%).
Одним из наиболее известных международных стандартов ИТ-аудита является
методология CobiT (контрольные объекты информационной технологии), о которой мы
уже упоминали. В основу CobiT положена процессная модель ИТ, базирующаяся на
контроле достижения установленных целевых показателей. Данный стандарт – это
инструмент, позволяющий руководству предприятия обеспечить переход от постановки
бизнес-задач к вопросам управления ИТ, установить должный уровень понимания рисков
и преимуществ, связанных с использованием ИТ, а также реализовать эффективную
систему управления ИТ. Таким образом, CobiT служит связующим звеном между бизнес-
рисками, задачами управления и технической инфраструктурой.
Как показывает опыт, целесообразно разбивать процесс аудита на этапы длительностью
примерно по 10 дней. На начальном этапе лучше провести первичное обследование,

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

Понятие эффективности/результативности
Ключевой вопрос ИТ-аудита – критерии эффективности ИТ для компании. В
каком случае применение ИТ в организации может считаться эффективным? Какой набор
ИТ-систем будет наиболее эффективным сегодня и какой – завтра? Будет ли выбранная
ИТ-система более эффективной, чем альтернативные? Ответы на такие вопросы
осложняются тем, что эффект от применения ИТ-системы чаще всего весьма непросто
выделить «в чистом виде». Поэтому менеджеры и «айтишники» нередко не сходятся во
мнениях по поводу того, что такое эффективность ИТ, есть ли она вообще и как может
быть выражена.
Здесь мы опять должны вернуться к терминологии эффективности, которую
рассматривали ранее, на шкале ценности информации. По определению стандарта ISO
9000, «эффективность – это связь между достигнутым результатом и использованными
ресурсами». В оригинале стандарта переведенный термин обозначается словом
efficiency, но там есть также термин effectiveness, который в ГОСТ Р ИСО 9000 переведен
как «результативность». В то же время смысл этого слова и его определение в ISO 9000
скорее относятся к понятию рroductivity – продуктивность.
Чтобы уйти от «переводных» споров, сошлемся на модель
эффективности/результативности ИТ для государственных органов США, которую
называют Performance Model (PRM). В PRM для оценки параметров деловых процессов и
другой деятельности вводится категория показателей, названная рroductivity&еfficiency:
«объем работы, выполненной в единицу времени и отнесенный к использованным
ресурсам». Тогда еfficiency определяется как «результативность/эффективность системы
или приложения в терминах времени отклика, интероперабельности, доступности для
пользователя и совершенствования технических возможностей или характеристик»; а
еffectiveness – «степень, до которой пользователи удовлетворены соответствующей
системой или приложением или в которой они отвечают требованиям пользователей, а
также их итоговое влияние на результативность/эффективность процесса(ов), которую
они обеспечивают, и на результаты клиентов или реализацию миссии (организации), в
которую они вносят свой вклад».
Следовательно, русскоязычный аналог определения будет звучать так: эффективность
системы в широком смысле – это комплексная характеристика системы, отражающая
степень ее соответствия потребностям и интересам ее заказчиков, пользователей, других
заинтересованных лиц. Такое определение позволяет единообразно, с единым набором
принципов и общих критериев, подходить как к эффективности конкретной ИТ-системы,
так и к эффективности применения ИТ на предприятии в целом, а также в тех случаях,
когда наиболее существенными являются социальные или иные неэкономические
показатели.

48/98
Итак, чтобы оценить эффективность ИТ, надо, как минимум:

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


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

· обозначить финансовые, кадровые и другие ограничения, такие как время, за


которое эффект должны быть достигнут;

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


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

· выбрать вариант ИТ-системы (или набор систем), который позволит наиболее


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

Эффективность ИТ для предприятия


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

Рис. 19. Крест информационных технологий.


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

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

Рис. 20. Критерии оценки ИТ.

Оценка эффекта от внедрения ИТ: финансовые методы


В целом можно выделить три основные группы методов, позволяющих определить
эффект от внедрения ИТ: финансовые (они же количественные), качественные и
вероятностные. У каждого метода есть свои минусы. Так как все они в основном
связаны с технико-экономическим обоснованием и оцениванием ИТ-проектов (то есть
относятся к «проективному подходу» в ИТ), то мы лишь упомянем их, оставляя более
детальное рассмотрение для других модулей программы «МВА-старт».
Финансовые, или количественные методы так или иначе связаны с понятием ROI.
ROI – это возврат на инвестицию, а не «возврат инвестиций», и ЭТО ОЧЕНЬ ВАЖНО
ПОНИМАТЬ! То есть ROI, по определению, отношение – а именно отношение чистой
прибыли к вложенным средствам. ROI = Net Benefits/Costs.
Понятно, что любой инвестор или собственник хочет, чтобы это отношение превратилось
в зависимость размера прибыли от инвестиций. Однако ROI зависит только от двух
показателей – активности оборота капиталов и прибыли на каждый оборот. А так
как вложение средств – это, по определению, приобретение собственности:
оборудования, недвижимости, доли в бизнесе и пр., то, вкладывая средства в ИТ
(технику, программное обеспечение и услуги), инвестор/собственник получает право
пользования ПО и результатами оказания услуг. Как он сможет распорядиться этим
правом – вопрос менеджмента, в частности ИТ-менеджмента. Выступая в качестве
количественного показателя производительности, ROI дает в руки менеджменту
компаний очень простой и наглядный инструмент отчетности и планирования. ROI

50/98
предлагает способ сведения субъективных оценок прибыльности предприятия к
математически точным показателям, что необходимо при оценке инвестиций и сравнении
текущей оправданности вложений, а также для оценки альтернативных путей
использования капиталов. ROI исходит из того, что инвесторам совершенно неважно, что
было сделано компанией для получения прибыли. Инвесторам важно, что можно будет
получить, в конце концов, от инвестиций.
Например, ROI позволяет быстро найти ответы на вопрос: надо ли увеличивать
вложения в технику, инвентарь или лучше выплатить задолженности?
Вместе с тем, ROI имеет некоторые недостатки, которые необходимо учитывать в
расчетах.
Допустим, компания инвестирует 100 тыс. долл. в новое программное приложение,
которое требует 25 тыс. долл. в год на поддержку и техническое обслуживание.
Предполагается, что это вложение денег позволит сохранить 200 тыс. в год.
Показатель ROI, рассчитанный по общей формуле, даст ROI 200% – это означает,
что доходы от проекта в два раза превышают расходы на него, и каждый вложенный
доллар дает два доллара чистой прибыли. Такой подсчет имеет массу недостатков.
Например, ROI показывает чистый возврат от инвестиций, но никак не учитывает
время, в течение которого эта прибыль была получена. В реальности придется
иметь дело с общей суммой инвестиций в течение некоего периода времени и
принимать во внимание все доходы и затраты за этот период.
Для «правильного» применения ROI нужно учитывать, по крайней мере, два финансовых
феномена, а именно Time value (ценность времени) и Hurdle rate (норму помех).
Первый феномен связан с тем, что с течением времени деньги меняют свою
ценность. Будущие затраты и сбережения, выраженные в деньгах сегодня, на самом
деле окажутся меньше, чем те же затраты, выраженные в «завтрашних» деньгах. Завтра
те же самые вещи будут стоить чуть больше: это связано с тем, что покупательная
способность денег сегодня выше, чем в будущем.
Второй феномен связан с учетом рисков инвестиций, оправданностью или
неоправданностью тех или иных вложений. Когда деньги кладутся, например, на
сберегательный счет, возврат их гарантирован, однако прибыль редко превышает 5–6%.
По государственным ценным бумагам процентные ставки выше (в типичном случае они
приносят 7–9% прибыли), и они относительно стабильны, хотя возврат и не гарантирован
на 100%. Покупка акций каких-либо компаний – дело более рискованное, но в среднем
дает около от 10% прибыли. При вложении в акции через ПИФы (паевые инвестиционные
фонды – Mutual Funds) очень хорошим считается уровень прибыли 17%. Естественно, в
связи с тем, что покупка акций – дело рискованное, и эти деньги могут просто «сгореть»,
она обязана приносить больше потенциальной прибыли, чтобы как-то оправдать риск
вложений. Понятно, что, если бы вложения в акции компании приносило всего 5–6%,
деньги уходили бы на относительно гарантированные государственные бонды, а не в
компании. На языке финансов говорят, что 5–6% прибыли «не покрывают риск
вложения».

51/98
Приведенные показатели ROI, их достоинства и недостатки
Для анализа вложений в ИТ и оценки их эффективности чаще всего применяются три
основных приведенных показателя ROI:
1. NPV (Net Present Value) – чистый приведенный доход, или чистая приведенная
стоимость;
2. IRR (Internal Rate of Return) – внутренняя норма доходности (рентабельности);
3. Payback Period – срок окупаемости инвестиций.
У каждого из них есть свои достоинства и недостатки.
Чистый приведенный доход (NPV) учитывает стоимость денег, однако не учитывает
рисков ИТ-проекта. Кроме того, это абсолютный показатель (деньги), что не позволяет
сравнивать с его помощью проекты с разным уровнем финансирования.
Внутренняя норма рентабельности (IRR) устраняет указанные недостатки. Однако
IRR не учитывает стоимости капитала и, к сожалению, не имеет простого экономического
определения (такого, например, как NVP). Этот показатель немного сложнее.
Наконец, Payback Period не учитывает временную стоимость средств. Нетрудно
заметить, что показатели NPV и IRR дополняют друг друга, и поэтому большинство
компаний использует их только вместе. Показатель Payback Period используется гораздо
реже, и основной причиной здесь являются трудности в идентификации будущего
денежного потока от ИТ-проекта.
Как же определяется будущий денежный поток? Это зависит от области, в которой
применяется ИТ-система. Например, при автоматизации логистических операций это
просчитывается достаточно легко: увеличение производительности работы склада или
же выигрыш по количеству сэкономленной площади переводятся в деньги достаточно
просто. Если в ходе реализации ИТ-проекта происходит оптимизация бизнес-процессов,
которые влияют на управление активами предприятий, активами, связанными с балансом
предприятия, принципиальных проблем тоже не возникает, хотя есть трудоемкая и
кропотливая работа. В целом, как показывает практика, примерно от 60 до 75%
функционального объема проекта можно перевести в будущий денежный поток. И от 25
до 40% остается на качественную и вероятностную оценку эффекта.
В любом случае, можно назвать четыре категории потенциальной прибыли,
которые компания может получить в результате внедрения ИТ-проекта и последующей
эксплуатации ИТ-системы:
1) сокращение стоимости труда;
2) снижение капитальных затрат (сокращение стоимости материалов,
канцелярских принадлежностей, стоимости печати, затрат на электроэнергию и т.п.);
3) увеличение производительности труда (обычно достигается за счет внедрения
решений, приводящих к снижению времени вынужденного простоя системы или
увеличению эффективности выполнения определенных задач);

52/98
4) бизнес-прибыль (как правило, это увеличение реальной прибыли компании,
которое может быть достигнуто за счет увеличения уровня продаж, увеличения
прибыли от одного покупателя и т.д.).

Шаблон расчетов ROI в области модернизации ИТ (упрощенный)

Допустим, ставится задача привлечения новых клиентов и увеличения отдачи от


существующих за счет совершенствования системы продаж услуг (например, банковских
или страховых) VIP-клиентам. Считается, что данная инициатива способна приносить
бизнесу порядка 500 тыс. долл. дополнительной прибыли (Pt (profit)) в год.
Задача для «айтишников» формулируется так: необходимо, чтобы менеджеры по
продажам в количестве N человек могли иметь оперативный доступ к корпоративной БД и
почте со своих ноутбуков/КПК. Им нужно обеспечить предоставление аналитических
выборок данных, касающихся истории клиентов, объемов закупленных ранее услуг и их
конфигурации. Необходим и доступ к агрегированным данным, характеризующим общую
активность клиентов определенной категории в определенный период времени.
Решение, предлагаемое ИТ-отделом, может выглядеть так.
Требуемые скоростные параметры доступа к данным и их предоставления
пользователям диктуют необходимость использования технологии аналитических
запросов. Для этого целесообразно:
· средствами, встроенными в SQL Server, создать аналитическую БД и наполнить ее
необходимыми корпоративными данными;
· приобрести серверное ПО, позволяющее осуществлять анализ данных и
построение отчетов через Сеть средствами браузера;
· для обеспечения мобильного доступа к корпоративной почте провести миграцию с
существующего на более современный почтовый сервер;
· в качестве средств доступа к данным для менеджеров использовать мобильные
телефоны/КПК с поддержкой современных стандартов связи CDMA/Wi-
Fi/GPRS/Bluetooth.
С учетом темпов технического прогресса в области ИТ по закону Мура временной
горизонт для расчета ROI составляет три года. Ставка дисконтирования (r) принимается
на уровне r = 12%. Примерные статьи затрат по первоначальным инвестициям и по
поддержанию работы нового функционала на каждый год приведены в таблицах.

53/98
Таблица 8. Первоначальные вложения в проект

Величина
Статьи
Тип затрат/описание затрат, тыс.
расходов
у.е.

Аппаратное обеспечение
1. Четырехпроцессорный сервер
1

2. Количество КПК/мобильных телефонов с поддержкой


2
мобильного Интернета
Программное обеспечение
1. ПО для анализа и построения отчетов (серверные
3
лицензии для четырехпроцессорного сервера) +
модернизация почтового сервера
2. Лицензии для системы разработки
4

3. Итого стоимость ежегодной поддержки ПО (ст. 3 + ст.


5
4)х15% = I
Персонал
1. Установка ПО для анализа и построения отчетов.
6
Обучение персонала.
2. Разработка структуры OLAP базы данных средствами SQL
7
Server
Итого первоначальные инвестиции: W = (ст. 1 + ст. 2 + ст. 5 +
8
ст. 6 + ст. 7)

Таблица 9. Ресурсы для поддержания работы нового функционала в течение года.

Требуемое
Среднегодовая
Статьи рабочее
Позиция Число зарплата (тыс.
расходов время (в % от
у.е.)
полного)

Специалист-аналитик 1 2 100

Администратор БД 2 1 5

Программист 3 1 2

Специалист по обучению 4 1 25

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


требуемого рабочего времени в год, получаем средние затраты на персонал (Р).
P = (зарплата аналитика) х 2 х 1% рабочего времени + (зарплата администратора БД) х 1

54/98
х 0,05 + …
Итого ежегодные затраты на персонал (P) и на ПО (I) составят общие ежегодные
затраты (F).
F=P+I
Для трех лет эксплуатации, для которых ведется расчет, величина денежного потока
(V) одинакова и рассчитывается как выгода от реализации проекта за вычетом
суммарных ежегодных затрат.
V= Pt – F = 500000 – F
Величина чистой приведенной стоимости вычисляется по формуле за три года как
сумма:
ТЗМ = ТЗМ (1-й год) + ТЗМ (2-й год) + ТЗМ (3-й год)
Для общей формулы это выглядит так: NPV = ∑ V/(1 – r)i,
где i – годы (в нашем случае имеют значения 1, 2, 3);
V – чистый денежный поток i-го года;
r – ставка дисконтирования.
В нашем случае показатель NPV = V/(1 – 0,12) + V/(1 – 0,12)2 + V/(1 – 0,12)3
Внутренняя норма рентабельности (IRR) вычисляется по аналогичной формуле,
только в правую часть уравнения NPV подставляется величина первоначально
сделанных инвестиций W.
Затем уравнение W/(1 – r) + W/(1 – r)2 + W/(1 – r)3 решается относительно величины
процентной ставки r.
Величина IRR определяет максимальную стоимость привлекаемого капитала, при
котором проект остается выгодным.
Далее по определению:
срок окупаемости (Payback Period) = W/(NPV/3),
где W – сумма первоначальных инвестиций;
цифра 3 – это временной расчет (3 года).
И, наконец, возврат инвестиций ROI = NPV/W x 100%

Оценка эффекта от внедрения ИТ: качественные методы


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

55/98
соответствие этим критериям. Ожидаемый качественный эффект от ИТ-проекта
сравнивается с желаемыми эффектами.
Еще один качественный метод, получивший название IT Scorecard, состоит в том, чтобы
адаптировать подход BSC для ИТ-отдела. Как и в традиционном BSC, в IT Scorecard
выбираются четыре более-менее сбалансированных направления (перспективы в
терминологии BSC) влияния ИТ на бизнес компании. В классическом и в «айтишном»
случае эти направления следующие: помощь в развитии бизнеса компании, повышение
качества продукции (причем здесь имеется в виду качество как для внутренних, так и для
внешних пользователей), повышение качества принятия решений и повышение
производительности труда. Затем, как и в BSC, по каждому направлению (перспективе)
определяются цели, другими словами – ориентиры, характеризующие желаемое место
ИТ в бизнесе компании в будущем. Именно эти цели составляют стратегию развития ИТ-
отдела (именно так можно трактовать перспективы) и будут трансформированы на
операционный уровень, то есть в конкретные ИТ-проекты. По сути, это те же приоритеты
проектных критериев, что и в методе информационной экономики, только
сгруппированные по направлениям. И наконец, как в классическом BSC, из целей
вытекают инициативы, то есть цели ИТ-отдела определяют, будет ли ИТ-проект
эффективен в разрезе приближения к одной или нескольким целям. Единственное
отличие от BSC, которое здесь есть, – это несколько иные показатели приближения к
цели. Метод информационной экономики страдает субъективизмом, особенно в части
анализа рисков проекта; с другой стороны, IT Scorecard, как и BSC, требует наличия
формализованной бизнес-стратегии. Для качественной оценки эффекта от инвестиций в
ИТ компании применяют либо метод информационной экономики, либо IT Scorecard. И
опыт показывает, что для качественной оценки этого, как правило, достаточно.

Оценка эффекта от внедрения ИТ: вероятностные методы


Вероятностные методы оценки экономического эффекта от ИТ-проекта – это
прикладная информационная экономика (Applied Information Economics) и справедливая
цена опционов (Real Options Valuation, ROV).
Метод прикладной информационной экономики – это немного модифицированный
качественный метод информационной экономики. Его идея в том, чтобы для каждой из
заявленных целей ИТ-проекта определить вероятность ее достижения и далее вывести
из нее вероятность улучшений в бизнес-процессах компании. Например, позволяет ли
проект по созданию корпоративного портала улучшить доступ к информации и принимать
решения быстрее? Насколько увеличится скорость принятия решений? В какой степени
это ускорит заключение сделки? Отсюда делается вывод об увеличении вероятности
заключения сделки.
Метод справедливой цены опциона сам по себе достаточно труден, поэтому за его
разработку недавно была вручена Нобелевская премия. В любом проекте выделяются
пять параметров: выручка от проекта, расходы на проект, сложность проекта, стоимость
поддержки получившегося решения и жизненный цикл внедряемой ИТ-системы. Затем
следует оценить, насколько мы можем влиять на эти параметры по ходу проекта. Чем
сильнее мы можем влиять на эти параметры, то есть понижать расходы или сложность
проекта, тем выше оценка этого проекта по данному методу. Соответственно, чем более

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

Вопросы для ИТ-аудита


Итак, сформулируем несколько «правильных вопросов», связанных с эффективностью
ИТ, а также с инвестициями в ИТ, на которые ИТ-менеджер любой компании должен
получить ответы.
1. Получает ли компания адекватный возврат инвестиций, вкладываемых в
информационные ресурсы?
2. Достаточна ли информационная инфраструктура, соответствует ли она
потребностям сотрудников, управляющих?
3. Исключает ли сложившаяся практика ИТ-менеджмента моральное старение всех
видов ИТ-ресурсов (в том числе программных, аппаратных и человеческих)?
4. Обеспечена ли достаточная безопасность информационных активов предприятия?
5. Гарантирована ли защита от хакерских атак, от атак, прерывающих обслуживание?
6. Обеспечено ли непрерывное функционирование системы, созданы ли резервные
центры обработки данных и резервные копии?
7. Обеспечены ли все условия для использования тех преимуществ, которые дают
ИТ?
8. Предприняты ли все меры, исключающие риски, связанные с ИТ?
9. Обеспечены ли методы оценки ИТ-инфраструктуры на предмет конкурентных
преимуществ?
10. Обеспечены ли все юридические требования, включая соблюдение авторских прав
на используемое программное обеспечение, патенты и лицензии?
На большинство этих вопросов дает адекватные ответы методология ITIL.

57/98
Раздел 6. СЕРВИСНЫЙ ПОДХОД НА ОСНОВЕ МЕТОДОЛОГИИ ITIL

История развития ITIL


Методология ITIL была впервые разработана в конце 1980-х годов Центральным
компьютерным и телекоммуникационным агентством (Central Computer and
Telecommunications Agency) – уже не существующим ныне структурным подразделением
правительства Великобритании – в качестве каталога, в котором обобщался передовой
опыт правительственных ИТ-служб. Вскоре она получила распространение в частном
секторе Великобритании, а затем в других европейских компаниях и в США. В 1988 году
вышла первая редакция документа Government Infrastructure Management Method
(«Государственный метод управления инфраструктурой»), переименованного в 1991 году
в IT Infrastructure Library (ITIL). Тогда же была образована группа пользователей ITIL
User Group с участием представителей Великобритании и Голландии; с тех пор эти две
страны стали лидерами ITIL-сообщества. В том же 1991 году группа была преобразована
в IT Infrastructure Management Forum (ITIMF). Последующие годы были отмечены бурной
активностью форума, которая в конечном итоге и привела к созданию в конце 90-х годов
ITILv2, а теперь – и ITILv3.

Версии ITIL

В состав второй версии ITIL включено семь книг, каждая из которых имеет объем около
200 страниц и стоит 115 долларов. Каждый из томов посвящен конкретной области:
поддержке услуг, предоставлению услуг, планированию внедрения системы управления
услугами, управлению безопасностью, управлению инфраструктурой информационных и
телекоммуникационных технологий, управлению приложениями и перспективам развития
с точки зрения бизнеса.
В третьей версии знания собраны в пяти книгах.
1. «Стратегия сервисов» (Service Strategy). Издание предназначено для практиков,
принимающих решения, в нем описаны роль ИТ и требования, предъявляемые к ИТ.
2. «Проектирование сервисов» (Service Design). Содержащийся в этой книге материал
позволяет оценивать сервисы – по функциональности, производительности и на
соответствие требованиям бизнеса.
3. «Внедрение сервисов» (Service Transition). Здесь дается возможность оценить риски
и обеспечить качество сервисов. Внедрение должно гарантировать более быстрое
реагирование ИТ на изменения в собственной среде и в бизнесе.
4. «Работа с сервисами» (Service Operation). В этой книге описывается практика работы
с сервисами.
5. «Постоянное совершенствование сервисов» (Continual Service Improvement). Здесь
предлагаются методы мониторинга и методика совершенствования сервисов.

58/98
Существует и шестая книга, «Введение в практику управления сервисами ITIL»
(Introduction to ITIL Service Management Practice), где описаны основы внедрения ITIL в
бизнес.
В чем секрет роста популярности методологии ITIL?
Вспомним материалы первого раздела курса, где мы рассматривали взрывной рост
сферы услуг по сравнению с материальным производством – примерно с 70-х годов
прошлого столетия. Этот феномен многими расценивался как признак зарождения
информационного общества. Однако можно также предположить, что феномен «бума
услуг» нашел отклик в науках о бизнесе, а именно в менеджменте, в котором
традиционно сильны британцы. Последующее развитие ITIL показало, что ее авторы
пристально следят за тенденциями в развитии ИТ и бизнеса. Именно посредническая
роль методологии ITIL между ИТ-технологиями и бизнесом делает ее востребованной на
рынке!

Жизненный цикл ITIL


Природа любых сервисных моделей предоставляет возможность эволюционного
развития – в этом их основное преимущество. Для представления эволюции в жизненном
цикле ITIL Service Lifecycle используется модель типа hub-and-spoke (в ней можно найти
сходство с велосипедным колесом со ступицей (hub) и спицами (spoke)).

Рис. 21. Эволюция жизненного цикла ITIL.


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

59/98
усовершенствование сервисов; наконец, на внешней стороне находятся еще два
источника знаний – дополнительные источники и источники, расположенные в Сети. В
наличии двух типов источников знаний – основных и внешних – и заключается специфика
модели жизненного цикла сервисов по методологии ITIL.

Модель ITIL
Основные сведения о «лучшей практике» – классика ITIL – содержатся в «ядре» (Core).
Дополнительные сведения, относящиеся к определенному сегменту рынка или к какой-то
частной технологии, содержатся в секции «дополнения» (Complementary). Кроме того,
через Web распространяются дополнительные продукты, руководства, исследования и
шаблоны.

Рис.22. Модель ITIL.

Реализация стратегии адаптивности на основе интеграции бизнеса и ИТ, а также


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

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

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


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

60/98
Такое определение сервиса дает команда «Итилиума». Применительно к ИТ-сфере это
наиболее «продвинутое» определение, помогающее осознать роли основных «игроков»
сервис-процесса: заказчиков, клиентов, менеджеров, владельцев бизнес-процессов и
«айтишников», поставщиков услуг. Действительно, многие объясняют, например,
появление аутсорсинг-бизнеса разделением труда, идущим еще от Адама Смита –
прародителя экономической науки. Но это слишком тривиальный способ объяснения.
Цепочки прироста ценности бизнеса, в которых отдельные звенья не являются
собственностью владельцев бизнеса, но которые могут ими управляться с помощью
соглашений и договоров, позволили строить скорее конвергенция бизнесов, то есть их
слияние, а также информатизация и виртуализация сервисов.

Рис. 23. Современная цепочка бизнес-процессов.

Каталог услуг (SLA)

Целью процесса управления уровнем сервиса (SLM – Service Level Management)


является формирование перечня услуг и соглашений об уровне обслуживания (Service
Level Agreement, SLA) на базе понятного владельцу бизнес-процесса и поставщику услуг
(«айтишнику») механизма поддержки и развития ИТ-услуг и мониторинга их качества.

Рис. 24. Этапы SLA.


Перечень или каталог услуг – это главный инструмент работы с заказчиком. Каталог

61/98
содержит подробное описание действующих услуг на понятном заказчику языке, а также
описание уровней сервисов, которые могут быть ему предложены. Каждая услуга,
описанная в Каталоге услуг, должна иметь четкие измеримые параметры.
Совокупность измеримых параметров и называется уровнем сервиса
(обслуживания).
Этапы разработки и мониторинга выполнения SLA следующие.
1. На первом этапе создания SLA составляются требования к уровню услуг
(Service Level Requirements, SLR). SLR – это прототип будущей услуги, который
представляет собой детальное описание потребностей заказчика; эти требования
используются при разработке, модификации и инициировании услуг.
2. На втором этапе на основе SLR разрабатываются таблицы спецификации услуг
(Service Specification Sheets). Таблицы помогают преобразовать требования к уровню
услуг в технические определения и параметры, необходимые для предоставления
услуги.
3. На третьем этапе рассчитывается стоимость услуги для всех уровней сервиса.
4. На четвертом этапе «айтишник» совместно с менеджментом компании выбирает
тот или иной уровень обслуживания, исходя из потребностей бизнеса и затрат,
неоходимых для выбранного уровня услуги, и оформляют (подписывают) SLA. Если
поставщик услуги является внутренним подразделением компании, то рекомендуется
не юридическая, а внутренняя форма договора – «операционное соглашение об
уровне обслуживания» (OLA).
Пример каталога услуг

А. Базовые сервисы С. Специализированные сервисы

1. Обслуживание рабочих мест 1. Обеспечение работы 1С:Бухгалтерии


2. Предоставление электронной почты 2. Обеспечение работы 1С:Зарплата и
3. Доступ в Интернет кадры
4. Услуга печати 3. Обеспечение работы системы "Бюджет"
5. Предоставление дискового пространства

В. Услуги связи D. Разовые услуги

1. Телефонная связь 1. Обеспечение переездов


2. Видеоконференцсвязь 2. Обеспечение выездных мероприятий

Описание услуг

Параметр «Золотой» «Серебряный» «Бронзовый»

62/98
уровень уровень уровень
Время предоставления С 9-00 до 20-00 С 9-00 до 19-00 С 9-30 до 18-30
Допустимый нормативный простой, часов в
1 4 16
месяц
Время реакции (часов) 0,2 1 2
Время устранения неисправностей (часов) 0,5 2 8
Число консультаций (обращений в месяц) 10 5 1
Консультации предоставляются по запросу,
0,5 3 8
не позднее, чем через ... (часов)
«Золотой» «Серебряный» «Бронзовый»
Параметр
уровень уровень уровень

Варианты построения службы Service Desk

Обычно процесс управления уровнем услуг после составления каталога и подписания


SLA формируется в собственно услугу, для мониторинга которой в компании выделяется
специальный сервис-менеджер или организуется служба сервиса (Service Desk).
Service Desk играет важную роль в поддержке пользователей. Современная
полномасштабная служба Service Desk выполняет функции «фронт-офиса» для всей ИТ-
организации и сама может обработать большую часть обращений и запросов
пользователей, не прибегая к помощи специалистов. Существует несколько вариантов
построения службы Service Desk, их называют линиями поддержки или единой точкой
входа.
1. Центр обработки звонков (1-я линия поддержки, точка входа) – производятся
только запись и регистрация обращений и передача их специалистам.
2. Неквалифицированная служба Service Desk или служба регистрации звонков
– происходит регистрация и описание в общих чертах обращений, которые затем
сразу маршрутизируются.
3. Квалифицированная служба Service Desk – этот тип предполагает наличие у
персонала высокого уровня профессиональной подготовки и большого опыта.
Сотрудники Service Desk в этом случае, используя документированные решения,
могут обработать большую часть поступающих обращений, хотя некоторые из них все
же перенаправляются в группы поддержки.
4. Экспертная служба Service Desk – персонал данной службы знает всю ИТ-
инфраструктуру и располагает экспертными знаниями, позволяющими
самостоятельно обрабатывать все обращения.

Разделы каталога услуг. Показатели деятельности


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

63/98
уровне, например, с руководством бизнес-подразделения или владельцем бизнес-
процесса.
Грамотно составленный договор об уровне обслуживания (SLA) является неотъемлемым
и основополагающим элементом в организации сервисной поддержки. В общем случае
SLA должен содержать следующие взаимоувязанные разделы.
· Общую часть (предмет соглашения, стоимость и порядок взаиморасчетов,
ответственность сторон, порядок разрешения споров, форс-мажор и т.д.).

· Перечень оборудования и ПО, передаваемого на сервисную поддержку (включая


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

№ Составляющая услуги Обязательная часть Опция

1 Обеспечение работы компьютера и Установка рабочего места и


ПО ПО

2 Консультирование пользователей по Администрирование прав Обучение работе


системному ПО доступа в локальную сеть с Windows – 1
день

3 Обучение пользователей Устранение неполадок Обучение работе


с MS Word, Excel
– 1 день

4 Консультирование пользователей по Обновление версий


офисному ПО

5 Организация нового рабочего места Меры по информационной


безопасности

6 Перемещение рабочих мест

Уровни предоставления услуги

64/98
Параметры/уровень
«Золотой» «Серебряный» «Бронзовый»
обслуживания

Время предоставления услуги

Время реакции на инцидент

Доступность объекта обслуживания

Консультация (от момента подачи


запроса, часов)

Организация нового рабочего места (не


более ... часов)

Перемещение рабочих мест (часов)

Время исполнения заявок на обучение


(дней с момента запроса)

Отчетность по услуге

Параметры отчётности Описание параметра

Доступность Фактический % времени доступности

Число сбоев Число сбоев за период

Сумма времени по заявкам, превышающим


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

Превышение планового времени устранения Сумма времени по заявкам, превышающим


сбоев установленные

Число консультаций пользователей Количество обращений

Число нарушений по запросам на консультации

Обучение пользователей Количество обученных

Число нарушений по запросам на обучение Сумма дней, превышающих нормы обучения

Число создание рабочих мест Число новых мест за рабочий период

Число перемещённых рабочих мест Число перемещённых рабочих мест

Объем и стоимость услуги

65/98
№ Составляющая услуги Объём Стоимость

1 Обеспечение работы компьютера и ПО По числу рабочих мест

Консультирование пользователей по
2 Количество запросов
системному ПО

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


3 Число групп обучения
офисному ПО

4 Консультирование по офисному ПО Количество запросов

5 Организация новых рабочих мест Количество рабочих мест

Количество перемещённых рабочих


6 Перемещение рабочих мест
мест

Показатели процесса управления уровнем услуг (KPI), а также информация, которая


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

· Параметры SLA, по которым ведется мониторинг и о недостатках которых


составляются отчеты.
· Параметры SLA, которые анализируются.
· Выявленные недостатки, включенные в план улучшений.

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


· Изменения (повышение, снижение) согласованного уровня сервиса и т.д.

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

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

66/98
сократилось на 50%!
На этом примере можно понять силу ITIL. Если в компании, например, построена
замечательная сеть или объединение мэйнфреймов, но каждая группа ориентирована на
оптимизацию только своей области, то ценность отдельных мероприятий для
организации в целом может оказаться маленькой. Методология ITIL описывает языки и
процедуры, направленные на координацию усилий всех подразделений ИТ-службы и
обеспечивающие слаженность их функционирования «на уровне оркестра».
Если управление уровнем сервиса работает в основном с запросами на обслуживание, то
управление инцидентами и проблемами предназначено для всякого рода неполадок в
работе ИТ-службы. Здесь основными понятиями являются:
· инцидент – любое событие, не являющееся частью стандартных операций по
предоставлению услуги, которое привело или может привести к сбою в работе или
снижению качества этой услуги;
· проблема – неизвестная причина возникновения инцидентов;

· известная ошибка – это проблема, причина которой установлена.

Целью процесса управления инцидентами и проблемами является уменьшение или


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

Примерами инцидентов могут служить такие события: «не работает программа»,


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

67/98
Таблица 10. Процесс управления инцидентами.

Этап Действие

Прием заявки и Оператором Service Desk принимается сообщение и создается запись об


регистрация инциденте.
инцидента

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


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

Привязка Происходит проверка, не является ли инцидент рецидивом или известной


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

Расследование и При отсутствии известного решения производится исследование инцидента,


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

Решение, Если решение найдено, то работа может быть восстановлена.


восстановление
работы

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


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

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

Таблица 11. Выходы процесса управления инцидентами.

Результат Комментарий

Запрос на изменение Рекомендуется регистрировать в Service Desk все запросы на


(RFC) изменение, поступающие от пользователей

Запись об инциденте Регистрация, информация о работе, проведенной в рамках


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

Отчеты Отчеты установленной формы, в том числе для других процессов


(число инцидентов, время разрешения, по категориям и др.)

68/98
Управление проблемами

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


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

· категория (программное или аппаратное обеспечение и т.д.);


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

· приоритет (агрегатный показатель, объединяющий срочность, степень


воздействия, риски, ресурсы).
Управление проблемами включает в себя проактивные и реактивные виды
деятельности.
Задачей реактивных составляющих процесса управления проблемами является
выяснение корневой причины прошлых инцидентов и подготовка предложений по ее
ликвидации.
Проактивное управление проблемами помогает предотвратить инциденты путем
определения слабых мест в инфраструктуре и подготовки предложений по ее
усовершенствованию.
Процесс реактивного управления проблемами, как правило, состоит из следующей
последовательности работ.
1. Выявление и идентификация проблем.
2. Анализ проблем.
3. Предложение объяснения проблемы (меняем статус – проблема становится
известной ошибкой).
4. Предложение решения.
5. Передача решения в процесс управления изменениями.
6. Устранение ошибки в процессе управления релизами.
7. Анализ – решена ли задача?
8. Закрытие проблемы (ошибки).
Проактивное управление проблемами включает в себя выявление потенциальных
проблем на основе информации из внешних источников: от поставщиков,
производителей, коллег. Потенциальные проблемы могут устраняться установкой патчей,
новых релизов, ликвидацией ошибок, выявленных другими.
Показателями процесса управления инцидентами и проблемами и видами информации,
отражаемой в отчетах, могут быть:

69/98
· общее количество инцидентов и выявленных проблем;
· среднее время разрешения инцидентов и проблем;

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


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

· число инцидентов, разрешенных на одно рабочее место или на одного сотрудника


службы Service Desk;
· процент инцидентов, разрешенных первой линией поддержки («фронт-офисом»);
· число инцидентов, разрешенных без посещения пользователя (удаленно);

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


зарегистрированных службой;
· количество замечаний по эскалации инцидента от менеджеров функциональных
подразделений и сотрудников 2 и 3 линии;
· количество верно (с первой попытки) классифицированных оператором
обращений;

· количество зарегистрированных ошибок;


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

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

Если службу Service Desk называют «фронт-офисом» методологии ITIL, то


конфигурационную базу данных (Configuration Management Database, СMDB) – «бэк-
офисом», так как ее главное предназначение – хранить актуальную информацию об ИТ-
инфраструктуре и предоставлять данные, необходимые другим процессам. Важнейшим
моментом является то, что процесс хранит информацию не только об элементах ИТ-
инфраструктуры, о так называемых конфигурационных элементах или учетных
элементах, но и информацию о связях этих элементов между собой.
CMDB – это ядро ITIL, которое позволяет осуществлять контроль над ресурсами и
содержит историю всех выполненных операций. CMDB представляет собой фактическое
отражение всех имеющихся у компании технологий – КИС, маршрутизаторов, серверов,
ПК и т.д., а также каталог изменений всех ресурсов, перечень инцидентов, связанных с
работой этих ресурсов, и описание места ресурсов в ИТ-инфраструктуре. Поэтому целью
процесса управления конфигурациями является хранение информации об ИТ-
инфраструктуре компании и предоставление данных другим процессам.
Для описания конфигурационных элементов необходимо определить границы процесса
и уровни детализации всей хранимой в CMDB информации, так как это влияет на
количество хранимой информации и затраты на поддержку актуального состояния CMDB.

70/98
Рис. 25. Структура CMDB.
Реализация процесса управления конфигурациями на практике выглядит
следующим образом:

· определяются конфигурационные единицы (компьютеры, ПО, лицензии и т.д.);

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


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

Пример набора атрибутов для CI

Атрибут Пример заполнения

Инвентарный номер 123456789

Серийный номер 00012203034550

Тип Телефонный аппарат

Производитель Sony

Принадлежит пользователю Иванову С.А.

Дата покупки 11.11.2007

Дата окончания гарантийного срока 11.11.2008

71/98
Для отчетов, как правило, используются следующие показатели:

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


атрибутов;

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


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

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


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

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

Изменения являются неотъемлемой частью любой деятельности. Они вносятся,


рассматриваются, одобряются или отклоняются. Накопленные изменения реализуются на
практике в виде измененных процедур и стандартов деятельности. Поэтому
совокупность одобренных изменений называется релизом. В этих двух процессах –
управлении изменениями и управлении релизами – больше проектного подхода, чем
сервисного, так как именно эти процессы адаптируют взаимодействие ИТ и бизнеса к
окружающей бизнес-среде.
Различают следующие типы изменений.
Простые – изменения, которые согласовываются по умолчанию.
Например, поступил запрос на смену пароля, установку офисного ПО и т.д.
Средние – требуют согласования с ИТ-директором (например, из-за необходимости
утверждения бюджета: покупка новой рабочей станции и т.д.).
Большие – требуют согласования в Комитете по изменениям (Change Advisory Board,
САВ) – специальном органе компании, утвержденном приказом, куда, помимо директора
по ИТ, входят представитель финансовой службы и представители основных
подразделений. Комитет может принимать решения в очной или заочной форме.
Какие операции сопутствуют процессу управления изменениями?
· Направление запроса на изменение (Request for Change, RFC) – хотя это
прерогатива процесса управления инцидентами и проблемами, но эта процедура
поддерживается и процессом управления изменениями, так как он отвечает за
правильную регистрацию всех изменений.
· Прием в обработку – предварительный просмотр запросов на изменение и прием
их к дальнейшему рассмотрению.
· Классификация-сортировка запросов на изменение по категориям и приоритету.
· Планирование-объединение изменений, планирование их проведения и
необходимых ресурсов.
· Координирование компоновки, испытаний и проведения изменений.
· Оценка успешности каждого изменения, составление заключения для будущей
деятельности (накопление знаний) и закрытие процесса.

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

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

Накопленные и одобренные изменения – релизы – разделяют на большие (значимые)


релизы и срочные релизы. Также выделяют следующие типы релизов:
· «дельта»-релиз – включает только измененные аппаратные и программные
средства;
· полный релиз – распространение полного комплекта ПО, включая неизмененные
модули;
· пакетный релиз – группа релизов, проводимых одновременно.
Операции процесса управления релизами сосредоточены в трех бизнес-средах –
разработки, тестирования и эксплуатации.
Таблица 12. Операции в бизнес-средах.

Операция/активность Среда выполнения

– Политика выпуска релизов, планирование релизов Среда разработки


– Проектирование и разработка системы
– Тестирование Тестовая среда
– Подготовка плана развертывания
– Приемка-сдача системы
– Обучение персонала

– Установка и инсталляция Эксплуатационная среда

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


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

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


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

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

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

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


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

· определение политики (охват процесса, основные участники и процедуры),


согласование политики с заказчиками;
· создание библиотеки эталонного ПО – хранилища актуальных версий
программного обеспечения;
· определение процедуры для выделенных типов релизов (стандартных, простых,
сложных); определение процедуры по связи с процессами управления
конфигурациями и управления изменениями;
· назначение ответственных и ознакомление их с правилами;
· проведение «пилотного проекта» по процедурам;
· проведение процедуры «Запуск процесса».
Типовые роли в процессе:
Менеджер процесса. Отвечает за весь процесс. Должен понимать основы «железа» и
«программного обеспечения», но не обязан быть «большим техником». Часть его
действий может быть делегирована другим специалистам, например учет операций
может выполнить диспетчер.
Разработчик релизов. Создает описания стандартных и типовых релизов, участвует в
планировании релизов других типов. Отвечает за актуальность библиотеки эталонного
ПО, документации. Участвует в тестировании релизов. Это должен быть сотрудник с
технической подготовкой. Часть его работы может быть поручена внешним поставщикам.
Тестировщик релизов. Участвует в тестировании; не обязательно технический
специалист – это может быть и кто-то из конечных пользователей, имеющих достаточно
времени на выполнение тестирования.
Установщик релизов. Участвует в установке релизов. Это обязательно технический
специалист. Для этой работы подойдет персонал, например, задействованный в процессе

74/98
управления инцидентами.
Возможные показатели процессов и виды отчетной информации для принятия
решений:

· количество завершенных изменений и проведенных релизов за определенный


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

· количество отклоненных изменений;


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

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


· количество срочных и внеплановых изменений и релизов;
· ТОП 3 (5, 10 и т.п.) пользователей, подающих больше всего запросов на
изменение.

Управление мощностями и непрерывностью

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


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

Рис. 26. Схема процесса управления мощностями.


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

75/98
Service Desk, могут быть восстановлены за заданный период времени после
возникновения чрезвычайной ситуации.
Одним из важных результатов этого процесса является план аварийного
восстановления (Disaste Recovery plan, DRP).
У данного процесса может быть и ряд других целей. Поскольку он является составной
частью процесса управления непрерывностью бизнеса, сфера действия процесса
управления непрерывностью ИТ-сервисов должна определяться с учетом из целей
бизнеса. В результате при оценке рисков потом можно определить, попадают ли они в
сферу действия данного процесса.

Управление доступностью

Целью процесса управления доступностью является обеспечение рентабельности и


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

Рис 27. Доступность сервиса.


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

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


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

76/98
· документирование и анализ нарушения доступности;
· прогнозирование будущей доступности;

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


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

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

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

Управление ИТ-финансами группируется по трем процессам:

· бюджетирование (планирование затрат, мониторинг расходов);


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

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


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

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


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

77/98
что разработка плана действий на случай непредвиденных обстоятельств является
неотъемлемой частью любой политики безопасности. Для базового уровня безопасности
достаточно проведения следующих мероприятий:

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


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

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

78/98
ПРИЛОЖЕНИЕ

Рекомендуемый порядок внедрения процессов для существующих ИТ-


сервисов

Стратегии внедрения ITIL-процессов в компании могут быть разными – в зависимости от


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

Группа Рекомендации по
Процессы
процессов очередности внедрения
Реактивные Управление инцидентами, Внедрять в первую очередь.
процессы Service Desk , Полученные улучшения
управление уровнем сервиса позволят освободить время для
проактивных процессов.
Изменения Управление изменениями, Рекомендуется внедрять
управление конфигурациями, совместно – из-за большой
управление релизами взаимозависимости.
Проактивные Управление проблемами, Внедрять совместно – из-за
процессы управление доступностью, большой взаимозависимости.
управление мощностями
Стратегические Управление уровнем сервиса, Внедрять в любое время –
управление финансами, ввиду независимости от других
управление непрерывностью процессов.

Рекомендуемый порядок внедрения процессов для новых ИТ-сервисов

Группа Рекомендации по
Процессы
процессов очередности внедрения
Стратегические Управление уровнем сервиса, Внедрять в первую очередь.
управление финансами,
управление непрерывностью
Изменения Управление изменениями, Внедрять одновременно.
управление конфигурациями,
управление релизами
Реактивные Управление инцидентами, Service Внедрять реактивные процессы
процессы Desk желательно после внедрения
управления изменениями для
фиксации результатов данных
процессов.
Проактивные Управление проблемами, Внедрять в последнюю
процессы управление доступностью, очередь. Это способствует
управление мощностью росту качества услуг.

79/98
Взаимосвязь между типичными проблемами в работе ИТ-подразделения и
процессами ITIL

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

Возможные KPI-метрики

Метрики показывают, насколько адекватно ИТ-служба поддерживает важные для бизнеса


параметры сервиса. Примерами таких показателей могут быть:

· общее количество инцидентов;


· среднее время разрешения инцидентов;
· среднее время разрешения инцидентов по приоритетам;
· среднее число инцидентов, разрешенных в рамках соглашений (SLA);
· средняя стоимость поддержки на инцидент;
· число разрешенных инцидентов на одно рабочее место или на одного сотрудника
службы Service Desk;
· процент инцидентов, разрешенных первой линией поддержки;
· число инцидентов, разрешенных без посещения пользователя (удаленно);
· количество пропущенных звонков, оценка числа инцидентов , не
зарегистрированных службой;
· количество замечаний по эскалации инцидента от менеджеров функциональных
подразделений и сотрудников 2 и 3 линии;
· количество верно (с первой попытки) классифицированных оператором
обращений и др.

80/98
Вопросник для пошаговой методики внедрения ITIL-процессов

Вопросы для менеджера и «айтишника » Ответ, комментарий

Стадия: Подготовка технического задания

Кто заказчики проекта (перечислить всех)?


Кто ключевые пользователи?
Будет ли в системе один уровень обслуживания (например, одно время
устранения сбоев) для всех пользователей? Какой уровень обслуживания
необходим?
Каковы требования по доступности системы ?
Какой будет скорость прироста информации?
За какой период необходимо восстановление информации?
Можно ли проектируемую систему заменить на покупку услуги (не покупая
ПО , оборудование)? Если нет, то почему?
Какие ИТ-сервисы и как изменит внедрение новой системы?
Знаком ли проектный персонал с требованиями организации по управлению
ИТ-сервисом ( управлению изменениями , релизами, инцидентами и
проблемами ?)

Есть ли требования по поставщикам услуг


(можно ли передать обслуживание другой организации или делать все
своими силами )?

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


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

Стадия: Разработка и внедрение системы

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


Какие затраты на ИТ-сервис предусмотрены , с кем согласованы и
чем объясняются?
Какая запланирована схема управления релизами? Где тестовая
зона? Каков порядок нумерации релизов и их установки?
Есть ли инструкция по установке нового релиза?
Когда будет обучаться персонал ИТ-поддержки?
Пользователи?
Кем и по какой процедуре будут согласовываться запросы на
изменение функций системы?
Если планируется установка ПО на удаленные рабочие места, какая
процедура обслуживания там предполагается?
Знаем ли мы ИТ-технологии, используемые новой системой?

81/98
Стадия: Передача в промышленную эксплуатацию

Принимал ли тестировщик компании


участие в приемке системы (процесс управления релизами)?
Установка проводилась с учетом требований процесса управления
релизами?
Получена ли в полном объеме эксплуатационная документация?
Есть ли описание сервиса системы с требуемой детализацией?
Есть ли рекомендации по типовым инцидентам для службы Service
Desk ? Есть ли список ошибок системы и описание обходных путей
решения?
Есть ли обоснование стоимости затрат на ИТ-сервис ?
Включены ли затраты на ИТ-сервис в бюджет предприятия?
Каков плановый срок работы системы?
Все ли документы на систему оформлены в бухгалтерии и как будут
отражаться в бюджете работы по изменению системы?

Пример формирования каталога услуг на основе методологии ITIL

Рассмотрим пример формирования каталога услуг на основе методологии ITIL на


примере ИТ-отдела холдинга «Аконит » (IEMAG №2 (178), 11.02.08).

Существуют внешние и внутренние по отношению к деятельности холдинга предпосылки,


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

Процесс создания КУ включал интервьюирование бизнес-пользователей и


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

При создании каталога можно выделить три этапа.

Первый – создание каталога как внутреннего документа, «для себя ». Составление


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

Второй этап – создание каталога «для бизнеса ». Цель – не составить SLA, а


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

82/98
Наконец, третий этап – создание каталога «для пользователей ».

Кроме короткого описания сервиса и его характеристик, в КУ для пользователей


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

Итак, каталог – это не просто дерево сервисов, а набор определенной документации,


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

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


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

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

· предназначение и краткое описание услуги;


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

Необходимо помнить, что время предоставления услуги может отличаться от времени ее


сопровождения. Еще важнее выделять гарантированное время восстановления услуги
после сбоя.

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

Глоссарий

АРМ (автоматизированное рабочее место)

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


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

Аудит информационной системы

процесс получения и оценки объективных данных о текущем состоянии системы,


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

Архитектура информационной системы

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


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

Архитектура предприятия Enterprise Architecture (EA)

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


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

Аудит

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


их объективного оценивания для определения степени соответствия критериям аудита.

84/98
Аудитор

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

Аудит (Audit)

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


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

Безопасность системы System Security

– защищенность системы от несанкционированного использования ее функциональных


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

Бизнес-моделирование

это как собственно моделирование бизнес-процессов, так и создание с помощью прикладных


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

Бизнес-процесс (деловой процесс)

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

Бот-нет (bot network — сеть роботов)

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


владельца компьютера.

Владелец бизнес-процесса

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


результат его выполнения

Внутренний аудит

аудит, проводимый самой организацией

Внешняя среда

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

Внутренняя среда

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


объекты

Вход

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

Выход

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

Действие

неделимая операция над документом (создание, изменение, передача и т.п.), информационным


объектом и/или потоками в рамках описываемой процедуры

Декомпозиция

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

Делопроизводство

комплекс мероприятий по организации документооборота предприятия или организации

Дерево целей

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

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

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


до нижестоящих управленческих структур.

Диспетчерская служба (Service Desk)

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

Жизненный цикл предприятия (Enterprise Life Cycle)

динамический, итерационный процесс изменения предприятия в течение определенного времени,

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

Жизненный цикл системы

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

Защита информации (Information Security)

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

Защита информационной инфраструктуры Information Infrastructure Protection

функция организации, направленная на обеспечение: а) гарантий эффективного и безопасного


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

Защищенность информационной системы

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


информации, ее искажению или разрушению. Различают два аспекта защищенности: техническую
защиту (свойство недоступности) и социальную защищенность (свойство конфиденциальности).

Инцидент

это любое событие, не являющееся частью стандартных операций по предоставлению услуги,


которое привело или может привести к нарушению или снижению качества этой услуги.

ИТ-инфраструктура

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


организации.

87/98
ИТ-архитектура “как будет”

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

ИТ-архитектура “как должна быть”

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

ИТ-архитектура “как есть”

- базовая архитектура, существующая архитектура, Baseline Architecture. 1. Совокупность


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

ИТ-менеджмент - IT Management

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


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

ИТ-проект - IT Project

Организационная инициатива, обеспечивающая или продуцирующая ИТ либо связанные с ИТ


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

ИТ-процесс - IT Process

Один из центральных субъектов спецификации стандарта CobiT. В стандарте идентифицируется и


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

ИТ-ресурс - IT Resource

ресурс, используемый в ИТ-процессе. Ресурсы, рассматриваемые в стандарте CobiT, включают:


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

ИТ-стратегия

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

88/98
К

Качество

продукта или услуги по определению международных стандартов – это совокупность


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

Ключевые индикаторы эффективности - КРI (Кеу Performance indicators)

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


действий, процессов и функций управления.

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

– диаграмма, отображающая информационные потоки между системой и внешними сущностями, с


которыми она должна быть связана.

Контроллинг

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


планирования, мониторинга, составления отчетов, совещательной функции, информирования.

Конфиденциальность - Confidentiality

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


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

Конфигурационная база данных (СMDB - Configuration Management Database)

«бэк-офис», хранилище актуальной информации об ИТ инфраструктуре, необходимые другим


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

Корпоративная архитектура

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


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

Косвенные затраты

затраты, которые нельзя непосредственно отнести на конечный продукт

Линейная структура управления

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

Линейно-функциональная структура управления

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


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

Лицензионное соглашение (лицензия)

договор между производителем программного продукта и пользователем программного


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

Метамодель ИТ-стратегии

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


применения. Созданием подобных метамоделей обычно занимаются консультанты.

Методология

система принципов и способов построения организации теоретической и практической


деятельности людей.

Модель бизнес-процессов (бизнес-модель)

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


условных обозначений)

Нотация

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

Объекты контроля для информационных и смежных технологий - Control Objectives


for Information and Related Technologies (COBIT)

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

90/98
безопасности, контроля и аудита.

Отчет

бумажный носитель информации или часть информационной системы (программы), посредством


которой осуществляется вывод данных

Ошибка (Error)

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


устранения.

Платформа

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


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

Показатель - Indicator

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

Поток (в экономике)

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

Проблема

неизвестная причина возникновения инцидентов.

Проект

это уникальная деятельность, имеющая начало и конец во времени, направленная на достижение


определённого результата, создание определённого, уникального продукта или услуги. Термин
проект происходит от латинского слова projectus, что в переводе означает "брошенный вперед"

Проектирование и разработка

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


технические условия на продукцию, процесс или систему.

91/98
Процедура

установленный способ осуществления деятельности или процесса.

Процесс ( Process 1)

связанная последовательность действий , активностей, изменений, осуществляемая для


достижений поставленных целей или удовлетворения потребностей.

Процесс (Process 2)

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

Разработчик (Developer )

организация, выполняющая работы по разработке (включая анализ требований, проектирование,


приемочные испытания) в процессе жизненного цикла программных средств.

Регламент

правила, описывающие выполнение выделенного процесса деятельности.

Результативность (Effectiveness)

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


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

Результат бизнес-процесса

объект управления (деятельности) в заданном состоянии на выходе бизнес-процесса.

Реинжиниринг бизнес-процессов

это создание новых и более эффективных бизнес-процессов без учета предшествующего


развития.

Риск, связанный с ИТ - IT-Related Risk

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


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

92/98
Сервис

ассоциируется с понятием услуга, то есть с совершёнными одним (человеком) в интересах другого


(человека) действиями или деятельностью.

Сигнатура

метод работы антивирусов и систем обнаружения вторжений, при котором программа,


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

ССП (система сбалансированных показателей, BSC — balanced scorecard)

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


деятельности организации и их «проекцию» на деятельность сотрудников и подразделений.

Стандарт

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

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

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


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

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

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


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

Стратегический план

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

Стратегия

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


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

93/98
Стратегия корпоративная

стратегия, определяющая общие принципы развития организации.

Стратегия функциональная

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

Стандарт качества

описание основных положений системы менеджмента качества.

СУБД (Система Управления Базами Данных)

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


хранение и обработку больших объемов информации (баз данных).

Субъект управления

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


управления.

Туннелирование

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

Управление проектами (англ. project management)

область деятельности, в ходе которой определяются и достигаются определённые цели, а также


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

Управление процессом (Process Control)

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


правильным и эффективным способом.

Управленческий учет

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


управленческих решений.

Управление производительностью (Performance Management)

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

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

Управление по результатам

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


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

Управление рисками - Risk Management

подход, который позволяет иметь дело с рисками, связанными с инвестированием. Управление


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

Управление рисками, связанными с ИТ - Management of IT Related Risks

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


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

Услуга ИТ (ИТ сервис) (Service IT)

действия ИТ специалистов, с использованием ИТ средств в интересах потребителей.

Целостность (в информационных технологиях) (Integrity)

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

Целостность информации - Information Integrity

обеспечение точности и полноты информации, а также ее достоверности в соответствии с


ценностями и ожиданиями бизнеса

Цикл Деминга

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


отслеживания и улучшения качества в организации.

95/98
Эффективность - Effectiveness

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


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

Эффективность (Efficiency)

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


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

CALS (Continuous Acquisition and Life Cycle Support)

"непрерывность поставок продукции и поддержки ее жизненного цикла". Целью применения CALS-


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

Cross-functional FlowChart

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


ходе выполнения одной процедуры.

DFD (Data Flow Diagram)

диаграмма потоков данных. Описывает движения информационных объектов.

IDEF0/ARIS

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


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

ITIL (Information Technology Infrastructure Library)

96/98
это тщательное описание модели жизненного цикла ИТ — организации, примеров реализации и
комментариев специалистов — предложенное Британским агентством правительственной связи
(CCTA), которое вело работы по формализации и стандартизации методов внедрения и
эксплуатации множества ИТ — систем в различных правительственных ведомствах в рамках
некоммерческой программы. Подход ITIL заключается в разделении процесса управления ИТ на
несколько дисциплин. Каждая дисциплина направлена на решение определённых функций, но во
взаимодействии с остальными. Они включают в себя такие области, как управление изменениями,
управление проблемами, управление конфигурацией, управление уровнем сервиса, управление
планированием, управление стоимостью и др. Ключевой концепцией является понятие управления
сервисом, на котором сфокусирована вся методология, и которое объединяет остальные
компоненты для достижения цели выполнения сервисных соглашений с пользователями.
Управление сервисом включает множество процедур, позволяющих быстро и эффективно
формулировать, изменять и контролировать определённые для каждого пользователя уровни
сервиса по заранее определённым критериям и параметрам функционирования системы.

ROI (Return On Investment)

"возврат инвестиций" - один из основных экономических показателей, влияющий на


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

SLA (Service Level Agreements)

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

SWOT-анализ

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

Список литературы и Интернет-ресурсов


Список рекомендуемой литературы

1. Данилин А. Архитектура и стратегия: «Инь» и «Янь» информационных технологий


предприятия. – М.: 2005.
2. Каплан Р.С. Нортон Д.П. Сбалансированная система показателей. От стратегии к
действию. – М.: 2003.
3. Методология функционального моделирования IDEFO. Госстандарт России. – М.:
2000.
4. Метрики для управления ИТ-услугами – М.: 2008
5. Тронин Ю.Н. Информационные системы и технологии в бизнесе. – М.: 2005.
6. IDEF0 госстандарт России – М.: 2000.

97/98
Список рекомедуемых Интернет-ресурсов

www.iemag.ru
«Intelligent Enterprise/Корпоративные системы» – деловой ИТ-журнал, ориентированный
на CIO (Chief Information Officer), ИТ-директоров и высший ИТ-менеджмент компаний.
www.raexpert.ru
Рейтинговое Агентство «Эксперт». Стратегическая цель Агентства – оказание
всесторонней информационно-аналитической поддержки компаниям, работающим на
российском рынке.
www.businessrulesgroup.org
некоммерческая организация ИТ-профессионалов.
www.opengroup.org/architecture
Международный консорциум по ИТ-технологиям с открытой архитектурой. На сайте
представлены статьи и аналитические отчеты.
www.isaca.org
Ассоциация аудита и контроля информационных систем (ISACA), представляющая
международный стандарт управления ИТ-процессами Control Objectives for IT and related
Technology (CobiT).
www.itgi.org
Американский государственный институт по ИТ.
www.i-teco.ru/articles.html
подборка статей по ИТ-тематике.
www.itil-officialsite.com
официальный сайт библиотеки ITIL.
www.itilium.ru
компания, разработавшая «Итилиум»: программу, созданную на основе ITIL (Information
Technology Infrastructure Library) – тщательного описания модели жизненного цикла ИТ.

98/98