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

Компания: IT Premium

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

С кем проводилась работа: Максим Прокопов, CEO и со-учредитель.

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

Изначальная информация

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

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

Карта основных бизнес процессов компании IT Premium

Как видите, изменения колоссальны. Но что самое важное – мне удалось донести свое видение и методику подготовки карты процессов, до директора компании. Вот что говорит на эту тему сам Максим:

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

В процессе работы с Романом неясные места становились все более ясными, и, в результате “домашней работы” у меня получилось построить карту процессов самостоятельно от начала и до конца!

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

Спасибо за проведенный эксперимент.

Со своей стороны хочу сказать спасибо Максиму! Было здорово поработать вместе. Мы получили хорошую, рабочую карту процессов.

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

Краткое описание основных процессов

Основные процессы:

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

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

То заявка переходит в процесс «Согласование объема услуг и стоимости»

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

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

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

Вспомогательные процессы:

Коммуникации с клиентом – все контакты с клиентом и все что с этим связано. Данный процесс отвечает на следующие вопросы:

• Кто связывается с клиентом?
• С кем связывается клиент?
• Какие каналы коммуникаций используются?
• Какие сообщения доносятся до клиентов?
• В какой форме проходят сообщения?
• И т.д.

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

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

Персонал – все что касается набора, обучения, мотивации и текущей работы с персоналом компании.

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

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

Коммуникации с поставщиками – данный процесс дублирует цели и задачи процесса «Коммуникации с клиентом», но в отношении поставщиков.

Процессы управления:

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

Управление ресурсами – процесс отвечает за распределение и координацию всех ресурсов компании по процессам. Так же данный процесс отвечает за обеспечение ресурсами внутренних процессов и нужд компании.

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

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

Стратегическое планирование и развитие – процесс, результатом которого является стратегия компании. Ее разработка, обеспечение, контроль и т.д. Совместно с процессом «Управление бизнес процессами», отвечает за эффективность и успех компании.

Управление финансами – управление финансовыми потоками.

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

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

Издание: CIO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И про людей

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

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

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

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

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

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

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

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

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

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

Ольга Бурносова,

консультант

Департамент консалтинга компании «Ай-Теко»

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

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

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

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

Формируется следующая цепочка работ (см. рис. 1):

Рис. 1. На схеме четко просматривается последовательность выполнения функций процесса, от начала до конца

1. Пользователь IТ-услуг направляет запрос на предоставление услуги;

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

3. Если потребовалось уточнение информации, IТ-подразделение отправляет Пользователю запрос на получение дополнительной информации;

4. Пользователь предоставляет запрашиваемую информацию;

5. В IТ-подразделении заказ регистрируется и направляется на исполнение, пользователю сообщается номер заказа;

6. Пользователь в ожидании исполнения своего заказа может затребовать у IТ-подразделения информацию о текущем состоянии исполнения заказа;

7. IТ-подразделение предоставляет информацию о текущем состоянии исполнения заказа Пользователя;

8. Как только заказ (услуга) Пользователем получен(а), Пользователь информирует IТ-подразделение об этом;

9. После этого запрос в IТ-подразделении может быть закрыт как Выполненный.

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

Она может быть полной, для нашего примера: работы 1-2-3-4-5-6-7-8-9.

Или неполной, для нашего примера: работы 1-2-5-6-7-8-9, работы 1-2-5-8-9 или работы 1-2-3-4-5-8-9.

Тот же самый процесс опишем с использованием другого подхода (см. рис. 2):

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

Мы - IТ-подразделение, являемся провайдером IТ-услуг для наших Пользователей, исполняем их запросы согласно утвержденному в Соглашении Уровню обслуживания.

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

● либо это первичный запрос от Пользователя на предоставление конкретной услуги;

● либо это ответ Пользователя на наш запрос дополнительной информации;

● либо это запрос Пользователя о состоянии исполнения его заказа;

● либо это сообщение Пользователя о получении им услуги.

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

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

Рассмотрим подробнее оба подхода и покажем их положительные и отрицательные стороны.

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

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

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

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

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

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

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

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

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

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

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

Размещено на 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


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