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

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

Бизнес-процессы организации

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

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

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

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

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

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

1. Цели и задачи бизнес-процесса (прагматические характеристики);

2. Владельца (хозяина) бизнес-процесса;

3. Последовательность выполняемых функций;

4. Поток входной/выходной информации (материалов);

5. Используемые ресурсы;

6. Регламент бизнес-процесса (руководящие, описательные документы, стандарты).

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

Общность процессов

Все бизнес-процессы организаций известны и определены стандартом ISO 9001:2008.

Список бизнес-процессов включает в себя:

1. Производство;

2. Управление;

3. Документирование;

4. Управление закупками;

6. Корректирующие и предупреждающие действия;

7. Управление качеством;

8. Управление жалобами клиентов.

Уникальность программистских организаций

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

Известные программистские организации (Микрософт, Моторола, IBM, ORACLE) уделяют вопросам качества программного кода огромное значение. Как правило, на проверку правильности программ уходит в 5-10 раз больше ресурсов, чем на их производство. В этом как раз и заключается уникальность таких организаций. Трудно себе представить, чтобы измерение детали после токарной обработки занимало в 10 раз больше времени, чем сама обточка этой детали.

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

Уникальность процесса производства

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

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

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

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

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

С чего начать разработку собственной фирменной методики производства ПО?

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

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

1. Уменьшение сроков и стоимости разработки;

2. Корректность кода;

3. Исключение ошибок;

4. Повышение надежности;

5. Повышение эффективности автоматизируемых функций;

Все эти цели (или подцели) полностью соответствуют целям более высокого уровня:

1. Уменьшение издержек производства и технической поддержки;

2. Увеличение прибыли;

3. Увеличение производительности труда;

4. Захват большей доли рынка;

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

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

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

1. Определение требований клиента (клиентом могут быть и внутренние структуры организации);

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

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

4. Разработка системы;

5. Верификация (тестирование, опытная эксплуатация и т.п.);

6. Выпуск системы (релиз, версия);

7. Сопровождение системы.

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

Общие для любого производства:

1. Управление;
2. Управление качеством;
3. Документирование;
4. Управление закупками/продажами;
5. Управление маркетингом;

Специфические для производства ПО:

1. Управление конфигурацией;
2. Управление требованиями;
3. Тестирование (модульное, интегральное, нагрузочное и т.п.).

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

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

Основы процесса Управление конфигурацией определены локализованным в России стандартом: ГОСТ Р ИСО 10007-2007. К сожалению, локализованный стандарт в силу языкового (и процессного) барьера нетривиален в своем применении, поэтому мы попытаемся в упрощенной форме изложить его требования. Благодаря такому изложению любая компания может построить процесс управления конфигурацией в течение 2-3 месяцев.

Начнем с терминологии, причем приведем термин конфигурация в контексте действующих российских компаний, не противореча в то же время стандарту.

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

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

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

1. Планирование;

2. Идентификация конфигурации;

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

4. Аудит конфигурации.

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

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

Управление требованиями

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

Большинство специалистов любого производства скажут, что такое невозможно, ведь требования к продукту могут меняться на противоположные уже по ходу производства, что исключит выполнение таких критериев качества, как стоимость и сроки разработки продукта. Но в том и заключается окончательный результат процесса Управления требованиями – ведь если требования изменились на противоположные относительно начала работ, следовательно, заказчику уже не нужен продукт с начальными характеристиками и требованиями. Какой смысл производить то, что уже не нужно?

В процесс Управления требованиями входят следующие подпроцессы:

1. Планирование;

2. Определение начальных требований;

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

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

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

6. Проверка выполнения требований в продукте (верификация, валидация).

Процесс Управления требованиями подробно описан в стандарте SW CMM, Уровень 2.

Тестирование

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

Процесс тестирование также состоит из подпроцессов:

1. Планирование;

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

3. Управление изменениями тестовых процедур и тестов по мере изменения требований;

4. Тестирование отдельных элементов (требований) системы;

5. Интегральное тестирование, нагрузочное тестирование (если предусмотрено техническим заданием).

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

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

1. Разработчика (программист проверяет собственный код);

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

3. QA (Quality Assurance) – проверку кода осуществляет специальная тестовая группа в соответствии со стандартными правилами;

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

По оценкам специалистов Motorola, ORACLe трудоемкость (затраты) тестирования должны составлять не менее 100% от трудоемкости (затрат) на собственно кодирование.

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

Выводы

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

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

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

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

Размещено на http://www.allbest.ru/

Введение

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

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

Объект исследования диссертации: бизнес-процессы в ИT.

Предмет исследования диссертации: организация моделирования бизнес-процессов и управления в ИT предприятии.

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

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

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

Задачи, поставленные для достижения цели:

1) Проведение анализа литературных источников по поставленной проблеме:

· Определение роли концепции управления ИT-услугами в понимании бизнес стратегии;

· Определение этапа развития сервисного подхода к управлению бизнес-процессами в ИТ;

· Проведение обзора и анализа существующих методик, методологий, лучших практик, рекомендаций, которые используются для управления ИT-процессами (ITIL, COBIT, ISO 20000);

2) Проведение исследования основных бизнес-процессов в ИT:

· Описание бизнес-процессов, их назначения, целей, задач и функций.

· Определение окружения и взаимодействия с другими процессами.

· Определение метрик процессов.

· Определение документирования процессов.

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

· Разработать схемы моделирования бизнес процессов в ИT.

4) Построить общую инфраструктуру ИТ-предприятия.

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

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

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

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

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

В третьей главе проведено моделирование бизнес-процессов, описаны операции, протекающие на всем цикле работ, разработан каталог рисков, безопасности и метрик.

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

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

1.1 Роль концепции управления ИT-услугами в понимании бизнес стратегии

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

В 2000-х годах в результате мощного прогресса информационных технологий, в том числе и благодаря освоению ресурсов интернет пространства, всеобщая доступность ИT-услуг привела к повсеместной интеграции во взаимодействии человека с компьютером. Современные средства вычислительной техники являются не только неотъемлемой частью повседневной жизни людей (доступность технических средств, появление различных торговых площадок в сети интернет, онлайн-сервисов, интернет-магазинов, интернет-банкингов, интернета-вещей, развитие интеллектуальных систем и технологий Big Data), но и главным двигателем бизнеса.

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

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

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

1.2 Сравнительный анализ существующих подходов к управлению IT-услугами

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

Выполнение заданий, связанных с ИТ обеспечением предприятия (внедрение, сопровождение),

Обеспечение стабильного функционирования ИТ комплекса.

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

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

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

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

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

· обеспечение непрерывности бизнес-процессов и услуг;

· сокращение затрат на содержание ИТ-инфраструктуры.

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

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

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

1.3 Анализ существующих методик, стандартов и подходов к управлению ИT-процессов

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

В основу «лучших практик» («best practice») и методологий различных подходов к управлению ИТ-услугами, разработанных крупными компаниями-вендорами входят следующие группы: методологии управления ИТ-услугами (ITIL, MOF, HP References model), подходы к руководству ИТ (IT Governance, CobiT), а также, частично, методологии управления проектами (IPMA, PMI, PRINCE2) в части управления проектами в области ИТ.

К стандартам относится первый в мире международный стандарт по управлению услугами ISO 20000, стандарты в области управления информационной безопасностью ISO 27001, стандарты в области разработки программного обеспечения ISO 12207, ISO 15288, ISO15504 и другие.

1.3.1 Библиотека ITIL

ITIL (IT Infrastructure Library) - библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Создание проекта началось в 80-е годы Центральным агентством по вычислительной технике и телекоммуникациям (CCTA - Central Computer and Telecommunications Agency). Целью проекта было создание подхода, который бы помог результативно и эффективно использовать IT-ресурсы в министерствах и других государственных учреждениях по заказу британского правительства. Результатом работ стала Библиотека опыта организации IT (IT Infrastructure Library -- ITIL), которая собрала лучшие подходы, имеющиеся на тот момент в индустрии IT-услуг.

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

Рассмотрим основные принципы, на которых основана модель ITIL:

Процессный подход к построению деятельности IT-департамента;

Услуга как конечный продукт IT-подразделения;

Высокое качество предоставляемых услуг;

Вектор внимания на Потребителя;

Ключевые отношения Поставщик-Потребитель;

Взаимовыгодные отношения с Поставщиками.

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

Основное внимание уделяется 12-ти практическим управленческим методам, которые применяются в различных областях в зависимости от потребностей организации (рис. 1.1).

Рисунок 1.1 - Библиотека ITIL

Библиотека ITIL состоит из подробных сведений, которые отвечают на один из вопросов о том, каким образом возможно предоставление и поддержание ИТ-услуг и сервисов (Service Delivery, Service Support, Application Management). В практике описываются процессы создания, развертывания и поддержания ИТ-инфраструктуры (Infrastructure Management) на качественном уровне, способном соответствовать всем ожиданиям клиента.

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

Применение ITIL организацией позволяет решать следующие задачи:

· Повышать эффективность выполнения протекающих процессов, использующих современные информационные технологии, в том числе:

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

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

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

ь организации сервисно-процессного подхода к организации ИТ-деятельности;

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

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

· Обеспечивать увеличение управляемости протекающими процессами и их развития (в том числе, повышение управляемости и прозрачности), обеспечение принятия своевременных, взвешенных и обоснованных управленческих решений за счет:

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

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

ь создания системы непрерывного совершенствования и развития ИТ-сервисов и процессов управления ИТ.

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

1.3.2 MOF

Ведущи е мировые компании-вендоры, занимающиеся производством программного и аппаратного обеспечения на практике разрабатывают на основе ITIL структурированные подходы (frameworks), отображающие точку зрения своей компании на управление ИТ-услугами. Одной из самых интересных «надстроек над ITIL» является Microsoft Operations Framework (MOF).

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

Модель процессов MOF поддерживает успешное оказание ИТ-услуг при помощи следующих важнейших принципов:

Структурированная и распределённая ИТ архитектура;

Быстрый жизненный цикл, итеративное улучшение;

Управление, основанное на оценке;

Встроенное управление рисками.

Модель процессов MOF делится на 4 взаимосвязанных квадранта операционной активности: изменение, эксплуатация, поддержка и оптимизация. Каждый из квадрантов применяется на определенном этапе жизненного цикла ИТ инфраструктуры. Задача каждого из квадрантов решается путем исполнения соответствующих функций управления услугами (рис. 1.2).

Рисунок 1.2 - Модель процессов MOF

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

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

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

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

1.3.3 Стандарт CobiT

Стандарт Control Objectives for Information and related Technology (CobiT) представляет собой набор универсальных задач ИТ управления. Его ценность заключается в том, что он предлагает модель, обеспечивающую взаимосвязь между бизнес-целями и ИТ-процессами.

В основе стандарта CobiT лежит парадигма, гласящая о том, что для предоставления информации, которая необходима организации для достижения ее целей, ресурсы ИТ должны регламентироваться набором естественно сгруппированных процессов. ИТ-ресурсы в CobiT описываются через четыре составляющие: приложения (Applications), данные (Information), инфраструктура (Infrastructure), люди (People).

CobiT содержит верхнеуровневое описание 34-х ИТ-процессов различных аспектов корпоративного ИТ управления. Все процессы сгруппированы в четыре домена (рис. 1.3):

· Планирование и организация (Plan and organize);

· Приобретение и внедрение (Acquire and implement);

· Предоставление и поддержка (Deliver and support):

ь Определение и управление уровнями сервиса,

ь Управление сервисами подрядчиков,

ь Управление производительностью и мощностью,

ь Обеспечение непрерывности сервисов,

ь Обеспечение безопасности систем,

ь Определение и распределение ИТ затрат,

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

ь Управление службой поддержки и инцидентами,

ь Управление конфигурацией,

ь Управление проблемами,

ь Управление данными,

ь Управление физическим оборудованием,

ь Управление эксплуатацией,

· Мониторинг и оценка (Monitor and evaluate).

Рисунок 1.3 - Стандарт CobiT

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

Достоинствами CobiT является четкая структура механизмов контроля процессов и возможности проведения аудита ИТ-процессов на соответствие требованиям.

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

· определить четкие требования к ИТ-службе;

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

· оценить риски и удостовериться в оптимизации затрат на ИТ-сервис;

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

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

Единственное, что не описано в CobiT - это вопросы внедрения процессов, механизмы осуществления деятельности (включая управление) процессов, меры по совершенствованию ИТ процессов и услуг.

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

1.3.4 Стандарт ISO 20000

Первый в мире стандарт в области управления услугами официально разрабо танный Британским институтом Стандартизации (British Standard Institute) - BS 15000. Стандарт ISO/IEC 20000 «определяет требования к поставщику услуг по предоставлению потребителю управляемых услуг приемлемого качества» и «должен способствовать принятию в повседневной практике процессного комплексного подхода к эффективному предоставлению управляемых услуг».

ISO/IEC 20000 состоит из двух частей:

· Information Technology - Specification for Service management (ISO/IEC 20000-1: 2005). Набор формальных требований для организации предоставления ИТ-услуг с требуемым качеством;

· Information Technology - Code of Practice for Service management (ISO/IEC 20000-2:2005). Практическое руководство по управлению ИТ-услугами. В нем в форме рекомендаций подробно раскрываются подходы к достижению формальных требований, изложенных в первой части стандарта.

Рисунок 1.4 - Стандарт ISO/IEC 20000

Стандарт ISO/IEC 20000 вобрал в себя принципы процессного подхода и содержит ряд требований к процессам управления ИТ-услугами. В стандарте описаны процессы управления услугами (рис. 1.4), но не отображены взаимосвязи между процессами.

Согласно стандарту, необходимо обеспечить «систему управления, включающую политики и организацию управления, позволяющую реализовывать внедрение всех услуг ИТ и эффективное управление ими». Планирование и реализация управления услугами реализуется через цикл Деминга «Plan-Do-Check-Act» (PDCA). При этом описание цикла и действий, которые должны быть осуществлены на каждом этапе, практически полностью совпадают с описанием цикла PDCA, приведенного в стандарте ISO/IEC 9000 с учетом специфики ИТ-услуг:

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

Ш реализация (do) - внедрение процессов управления услугами;

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

Ш действие (act) - выполнение действий по постоянному улучшению показателей процессов.

Вывод: Стандарт ISO/IEC 20000 можно считать одним из ключевых теоретических руководств по управлению ИТ-услугами, т.к. описанный подход к управлению услугами полностью соответствует запросам бизнеса по отношению к пониманию ИТ-инфраструктуры организации. Благодаря данному стандарту дается крайне исчерпывающее описание процессов, протекающих внутри оганизации.

1.3.5 Управление ИТ-проектами на основе PMBoK

Project Management Body of Knowledge (PMBoK) - свод знаний по управлению проектами и является американским национальным стандартом. В стандарте описывается непосредственно процесс управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат.

По PMBoK управление проектами - это приложение знаний, навыков, инструментов и методов к работам по управлению процесса для удовлетворения требований, предъявляемых к проекту. Управление проектами выполняется с применением интеграции логически сгруппированных процессов управления проектами в количестве 42, распределенных в 5 групп. Эти 5 групп процессов следующие:

· инициация;

· планирование;

· исполнение;

· мониторинг и управление;

· завершение.

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

1.3.6 Управление ИТ-проектами на основе PRINCE2

PRINCE2 является методом для упра вления проектами, разработанным для британского правительства и является обязательным для применения во всех государственных структурах Великобритании. Благодаря открытости, доступности и эффективности этого метода, им активно пользуются уже более чем в 150 странах мира и его популярность растет с каждым днем. Уже более 23 000 организаций по всему миру уже используют этот инновационный и надежный подход в своей практике и многие считают его лучшим методом управления проектами. Во многом это связано с тем, что PRINCE2 является действительно универсальным методом: он может быть применен к проектам в любой сфере деятельности и вне зависимо от различных условностей.

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

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

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

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

Универсальность применения по отношению к любому типу проекта;

Единство терминологии и подходов;

Интегрируемость с другими практиками и со специфическими отраслевыми моделями и методологиями;

Фокус управленческих усилий на продукте проекта, в соответствии с согласованными стандартами качества;

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

Непрерывность внимания обеспечения жизнеспособности и целесообразности проекта;

Распределение ролей и зон ответственности участников.

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

1.3.7 Capability Maturity Model Integration (CMMI)

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

Потребность в появлении данной методологии возникла в кулуарах Министерства обороны США с целью решения такого вопроса, как повышение качества разрабатываемого по заказу ПО. Разработкой модели, в соответствии с которой оценивались потенциальные исполнители заказов министерства обороны, занималась фирма Software Engineering Institute. В основу модели положен анализ процессов, выполняемых при разработке ПО, с учетом связанных с ними рисков.

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

Уровень зрелости - итоговый показатель оценки по модели CMMI. Всего в модели представлено пять следующих уровня зрелости:

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

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

Третий уровень - определенный уровень. Все процессы описаны на уровне организации (но не на уровне отдельного проекта). Становится видимой внутренняя сторона черных ящиков.

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

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

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

· Менеджмент требований - управление требованиями к продуктам проекта.

· Планирование проекта - разработка и поддержание планов проекта.

· Мониторинг и контроль проекта - отслеживание стадий протекания проекта и корректировка в случае отклонения от плана.

· Измерение и анализ - поддержка измеримости услуг.

· Оценка качества товаров и процессов - управление качеством в соответствии с продуктом/товаром.

· Менеджмент договоров с поставщиками - управление внешними поставщиками.

· Конфигурационный менеджмент - контроль за целостностью продукции при обновлении и изменении.

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

· Техническое решение - разработка решений в соответствии с требованиями и их внедрение.

· Интеграция продукта - эксплуатация, проверка интеграции и функционирования введенного продукта.

· Верификация - соответствие продуктов требованиям.

· Валидация - соответствие продуктов использованию.

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

· Описание процессов организации - установление и поддержание процессов организации.

· Организационный тренинг - повышение уровня знаний и развитие способностей людей для эффективного выполнения своих ролей.

· Менеджмент интеграции проектов - взаимодействие заинтересованных лиц при интеграции процесса.

· Менеджмент рисков - анализ возникновения чрезвычайных ситуаций до их возникновения.

· Интегрированные команды - формирование команд для разработки.

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

· Анализ решений и разрешение - анализ альтернативных решений и разработка наиболее подходящего решения на основе структурированного подхода.

· Организационная среда для интеграции - инфраструктура для процессов и интеграции продукта.

· Производительный организационный процесс - поддержание производительности процессов на эффективном уровне.

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

· Организационные инновации и внедрение - анализ и выбор необходимых инноваций для внедрения.

· Анализ причин и разрешение - выявление причин дефектов и принятие превентивных мер по предотвращению их в дальнейшем.

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

1.3.8 eSourcing Capability Model for Service Providers (eSCM-SP)

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

На рисунке 1.5 представлены основные направления: Sourcing life-cycle (стадии жизненного цикла), Capability levels (уровни способностей), Capability areas (область способностей) и 84 различных процесса, распределенных в соответствии с направлениями.

Рисунок 1.5 - Структура eSCM-SP

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

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

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

· первый уровень - непосредственное предоставление услуг;

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

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

· четвертый уровень - организация внедряет различные инновации;

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

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

1.3.9 SixSigmaR

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

В основу концепции заложены следующие основы:

· устойчивое и предсказуемое течение бизнес-процессов;

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

· вовлеченность персонала для совершенствования качества продукции;

· клиентоориентированность;

· управление данными, факторами и показателями;

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

· взаимосвязанное взаимодействие внутри организации.

Для совершенствования процессов в SixSigmaR существует методика DMAIC (define - определение, measure - измерение, analyze - анализ, improve - улучшение, control - контроль), согласно которой процессы компании проходят через 5 этапов уровня зрелости.

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

1.3.10 ISO 15504 или SPICE (Software Process Improvement and Capability Determination)

SPICE - эталонная модель, определяющая измерение процесса и измерение возможностей.

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

Для измерения возможностей используется 5 уровней:

ь 5 уровень - оптимизированный процесс;

ь 4 уровень - предсказуемый процесс;

ь 3 уровень - установленный процесс;

ь 2 уровень - управляемый процесс;

ь 1 уровень - выполняемый процесс;

ь 0 уровень - неполный процесс.

Возможности процессов измеряются с помощью следующих атрибутов:

· производительность процесса;

· управление производительностью;

· управление продуктом;

· определение процесса;

· развертывание процесса;

· измерение процесса;

· контроль процесса;

· нововведения в процесс;

· оптимизация процесса.

· Not achieved (0 - 15%) - Не достигнуто.

· Partially achieved (>15% - 50%) - Частично достигнуто.

· Largely achieved (>50%- 85%) - В значительной степени достигнуто.

· Fully achieved (>85% - 100%) - Полностью достигнуто.

В стандарте описаны модель оценок в соответствии со следующими стандартами: ISO/ IEC 12207, ISO/ IEC 15288.

Вывод: Стандарт ISO/ IEC 15504 является одним из вспомогательных элементов способных обеспечить качественное предоставление ИТ-услуг.

1.3.11 ISO/ IEC 19770-1

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

Основа стандарта - четырехуровневый подход к внедрению ПО (рисунок 1.6):

Рисунок 1.6 - Четыре уровня ISO/IEC 19770-1

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

Рисунок 1.7 - Требуемые процессы для достижения оптимизации бизнес-процессов

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

1.3.12 ISO 38500

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

ISO/ IEC 38500 относится к управлению текущего и будущего использования ИТ организации, включая процессы и решения, связанные с текущим и будущим использованием ИТ-управления. Эти процессы могут контролироваться специалистами ИТ в рамках организации, внешними поставщиками услуг или бизнес-подразделениями в рамках организации.

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

Стандарт ISO/IEC 38500 обеспечивает соответствие деятельности организации обязательствам (законодательству, нормативным актам и контрактным соглашениям), обеспечивая при этом эффективное использование ИТ.

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

Структура стандарта ISO/IEC 38500:2008 содержит три раздела:

· область применения и цели стандарта, его применение;

· фреймворк хорошего корпоративного ИТ-управления;

· руководство по корпоративному ИТ-управлению.

Стандарт устанавливает шесть принципов корпоративного ИТ-управления:

· Ответственность (Responsibility). Ответственность сотрудников в организации в отношении потребления и предоставления ИТ-сервисов.

· Стратегия (Strategy). Учет современной и будущей стратегии и их связи с ИТ.

· Приобретение (Acquisition). Анализ поставщиков.

· Реализация (Performance). Поддержание и обеспечение качественного уровня услуг.

· Соответствие (Conformance). Соответствие ИТ законодательству и прочим нормативным актам.

· Поведение (Human Behaviour). Учет деятельности и нужд людей в ИТ-сфере.

В стандарте устанавленго три задачи управления для руководства организации в отношении ИТ:

· Оценка(evaluate) потребности в использовании информационных технологий.

· Направление (direct) планов и политики в сфере ИТ в соответствии с бизнес-целями.

· Контроль (monitor) соответствия политикам и исполнения планов.

Для повышения эффективности управление ИТ должно происходить логично и последовательно. Модель корпоративного управления ИТ (EDM - Evaluate -- Direct -- Monitor), отличается от привычного цикла PDCA.

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

1.4 Анализ методов моделирования диаграмм бизнес-процессов

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

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

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

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

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

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

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

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

Основу многих современных методологий проектирования диаграмм бизнес-процессов составляют:

· методология SADT (Structured Analysis and Design Technique) (IDEF0) - метод функционального моделирования;

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

· моделирование потоков данных DFD;

· метод ARIS;

· метод моделирования, используемый в технологии RUP (Rational Unified Process).

1.4.1 Применение SADT (IDEF0)

Метод SADT (Structured Analysis and Design Technique) является классическим вариантом процессного подхода к управлению. В основу его принципа заложено структурирование деятельности организации в соответствии с ее бизнес-процессами, а не по тому как разработана штатная структура организации. Бизнес-процессы, протекающие внутри корпоративной информационной системы, выделяющиеся методом SADT и несущие в себе определенную ценность для организации должны оптимизироваться в первую очередь. Так же стоит упомянуть о том, что любой бизнес-процесс несет в себе информацию о том кому он предназначается и от кого он идет.

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

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

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

1.4.2 Применение IDEF3

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

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

контрольная работа , добавлен 20.02.2016


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

контрольная работа , добавлен 11.06.2010


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

дипломная работа , добавлен 18.12.2012


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

дипломная работа , добавлен 08.01.2012


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

реферат , добавлен 12.09.2011


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

дипломная работа , добавлен 29.06.2015


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

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


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

дипломная работа , добавлен 15.09.2012


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

дипломная работа , добавлен 07.07.2012


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

Концепция управления качеством информационных услуг (Information Technology Service Management - ITSM) возникла в результате принципиального изменения сегодняшней роли ИТ-подразделений. Бизнес-процессы настолько тесно увязаны с приложениями, техническими ресурсами и деятельностью персонала отделов автоматизации, что эффективность последних оказывается одним из решающих факторов эффективности компании в целом.

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

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

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

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

Итак, ITSM подразумевает коренную реорганизацию службы эксплуатации информационных технологий. Опираясь на мировой опыт, компания Нewlett-Рackard разработала типовую модель управления качеством информационных услуг, так называемую ITSM Reference Model. Модель детально описывает процессы и взаимосвязи между ними, которые должен поддерживать ИТ-отдел, чтобы предоставлять информационные услуги с гарантированным качеством.

Ключевые элементы ITSM - процессы, персонал, технологии

Идеология ITSM держится на трех китах:

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

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

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

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

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

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

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

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

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

Типовая модель

Два года назад Hewlett-Packard предложила типовую модель информационных технологий HP IT Reference Model, которая позволяет разработать структуру ИТ-процессов в компании и на ее основе реализовать управление качеством информационных услуг. Типовая модель представляет собой методику внедрения лучшего международного опыта в области ИТ, собранного в Библиотеке IT Infrastructure Library. Библиотека ITIL - это сборник из 68 книг по различным областям функционирования ИТ, включая планирование ресурсов, управление проблемами, управление инцидентами, разработку и внедрение новых услуг, снижение расходов, управление пользователями и т.д. Эта информация собиралась и систематизировалась Комитетом по телекоммуникациям при правительстве Великобритании, а сейчас поддерживается, издается и обновляется независимой организацией EXIN .

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

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

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

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

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

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

Процесс управления конфигурациями (configuration management) регистрирует и контролирует данные об ИТ-инфраструктуре. Этот процесс обрабатывает информацию о каждом элементе конфигурации (configuration item - CI): атрибуты CI (системы и сетевые устройства, прикладные программы, персонал, документация и т.д.), статус CI (в наличии, в ремонте, в производственной среде и т.д.) и взаимосвязи между ними (например, «компьютер А находится на рабочем столе пользователя X», «принтеры В, C и D доступны для использования» и т.д.). Процесс управления конфигурацией, который относится только к ресурсам ИТ-инфраструктуры, не следует путать со стандартной процедурой управления ресурсами предприятия. Любые процессы, влияющие на инфраструктуру (а это все процессы модели), будут взаимодействовать с процессом управления конфигурацией.

Привязка ИТ к бизнес-процессам

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

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

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

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

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

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

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

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

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

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

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

Разработка и внедрение услуг

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

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

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

Оперативная поддержка

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

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

Управление инцидентами (incident management) или служба поддержки (Help Desk) - процесс быстрого восстановления готовности услуги с наименьшими потерями в случае возникновения инцидентов в инфраструктуре. Служба поддержки обрабатывает звонки пользователей, регистрирует информацию о сбое, определяет приоритеты разрешения инцидентов. Управление инцидентами предполагает повседневное взаимодействие потребителя и поставщика услуги, являясь ценным источником информации о том, насколько пользователь удовлетворен ИТ-обслуживанием.

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

Реализация ITSM

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

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

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

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

ITSM - новая для ИТ-отделов концепция. Но ее необходимость диктуется жизнью. Слишком велика сегодня роль информационных технологий для бизнеса, особенно для его «е»-компонента. То, что в Hewlett-Packard активно занялась этой проблемой, конечно, не случайно: технологическая основа для автоматизации работы ИТ-отдела - это платформа управления компьютерными системами и сетями HP OpenView ( , «Открытые системы», 2000, №7-8). Входящий в нее компонент IT Service Manager использует концепцию процессов и является обязательным компонентом проектов НР при развертывании ITSM-решений IT Service Manager интегрирован с другими компонентами OpenView, которые обеспечивают управление уровнем услуг, сбоями, проблемами, изменениями, позволяют взглянуть на информационные ресурсы с точки зрения бизнес-процессов и т.д. Внедрение ITSM-решений на основе Типовой модели и платформы OpenView в HP начали с себя, реорганизовав работу собственного ИТ-подразделения в соответствии с концепцией управления качеством информационных услуг.

10.04.2006, Некрасова Елена

Издание: CIO

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

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

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

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

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

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

Статика и динамика

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

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

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

От бизнеса к модели и обратно

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

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

После определения целей проекта начинается процесс бизнес-анализа. В соответствии с критериями, эффективность которых планируется оптимизировать или повысить, выбираются ключевые подразделения и специалисты. Параллельно разрабатывается методология бизнес-моделирования, предназначенная именно для данной организации. На основании этой методологии выдвигаются требования к инструментарию – набору функциональных элементов одной или нескольких систем (Aris, All Fusion, Microsoft Project). Далее консультант, имея картину прохождения бизнес-процессов, начинает создавать реестры ресурсов для достижения обозначенных в рамках проекта бизнес-целей. Реестры содержат описания трудовых, материальных, финансовых ресурсов, набор регламентных и прочих документов, которые необходимы для реализации проекта, набор информационных систем, которые автоматизируют часть деятельности компании, и набор функций и операций компании. "Не стоит пытаться дать формализованные определения функциям, операциям и процессам, – отмечает Борис Носков . – Нередко общепринятые термины и концепции не очень удобны для заказчика. Мы в рамках своих проектов, как правило, формулируем "соглашения о моделировании" и составляем глоссарий, содержащий термины, принятые в компании. Этот документ описывает, что в данном случае будет пониматься под процессом, подпроцессом, функцией, операцией и т. п.". "Соглашение о моделировании" включает в себя также описание концепции моделирования, объекты и методики моделирования, требования к инструментарию.

Далее начинается совместная работа консультантов и заказчика по описанию бизнес-процессов. "Важно отметить, что работа выполняется именно совместными усилиями. Самостоятельно, в отрыве от заказчика, консультант никогда не создаст живую модель бизнеса, – подчеркивает Борис Носков . – Поэтому внедрение системы – результат встречного движения заказчика и исполнителя".

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

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

Индивидуальный подход

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

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

От рядового до генерального

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

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

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

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

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

Результаты и перспективы

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

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

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

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

Наконец, важным моментом является возможность оценки затрат на исполнение определенной процедуры, операции или достижение какой-либо цели. По оценкам некоторых экспертов, проведенная на основе созданных моделей оптимизация процессов на 20-30% снижает затраты на содержание компании.

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

Практически во всех компаниях ведется постоянная борьба подразделений за ресурсы. Если подразделения перестанут обосновывать свои роль и место в компании, постепенно они будут терять выделяемые ресурсы. Бизнес-моделирование является незаменимым средством разрешения таких конфликтов. Можно смоделировать состояние компании с разной долей участия конкретного подразделения в бизнесе и выявить его объективную роль. "Это цивилизованный способ оценки вклада каждого подразделения в общее дело и выявления его скрытого потенциала. Инструмент бизнес-моделирования поддерживает культуру коллективной работы и обеспечивает прозрачность бизнес-процессов, в том числе и с точки зрения вклада подразделений в общее дело", – говорит Борис Носков .

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

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

| 23.05.2018

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

С чего начать?

Как и любое преобразование, оптимизация бизнес-процессов начинается с постановки цели. Чего мы хотим добиться в результате оптимизации? Что должно получиться в итоге и что не должно произойти ни при каких обстоятельствах? Ответы на эти вопросы помогут сформулировать цель оптимизации процессов. Отмечу, что цель может быть общей и для всех процессов, и для каждого. Как правило, можно выделить подцель - с указанием конкретных измеримых параметров того, что должно быть оптимизировано. Например: «Целью проекта оптимизации бизнес-процессов является уменьшение времени выпуска изделия со 100 до 80 часов, при уменьшении процента брака с 7 до 3%». Это конкретная цель. Для каждого процесса можно поставить и свою цель, коррелирующую с общей. Например, одной из подцелей может быть «Снижение срока проектирования нового изделия с 12 до 10 часов путем оптимизации процесса проектирования изделий». Тут, правда, большой отдельный вопрос: за счет чего и как выполнять поставленные цели (скажем, снижение срока проектирования запросто может отразиться на балансе «скорость - качество»).

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

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

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

Как найти точки оптимизации?

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

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

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

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

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

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

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

Карта оптимизации и тестирование

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

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

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

Как внедрять изменение?

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

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

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

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

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

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

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

Ответы на часто задаваемые вопросы (это может быть некоторая онлайн пополняемая база знаний).

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

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

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

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

Внедрение необходимо делать, заручившись поддержкой сотрудников, участвующих в процессе. Можно и «по-жесткому»: без поддержки, но эта схема работает, только если управление в принципе построено на жесткой вертикали.

И про людей

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

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

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

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

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

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

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

Ключевые слова: ,

Горячие темы: Бизнес в цифре

ИТ эксперт. Высшее техническое образование. Публикуется в ИТ-прессе с 2001 года, с IT Manager сотрудничает с 2009 года. Основные интересующие темы: отношения ИТ и бизнеса, облака, технологии ИТ для бизнеса, управление, проекты, консалтинг, СПО.