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

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

консультант

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

Статья предназначена для 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-услуг.

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

Компания: IT Premium

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Издание: CIO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мария Каменнова , генеральный директор,
Андрей Коптелов , директор по ИТ-консалтингу,
"IDS Scheer/Логика бизнеса"

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

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

Стратегическое управление ИТ-подразделением

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

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

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

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

Преимущество внедрения BSC/ССП состоит в том, что ИТ-подразделение получает некую систему координат для организации действий в соответствии со стратегией и возможность последующего ее мониторинга при помощи ключевых показателей результативности - КПР (Key Performance Indicators, KPI).

При построении единой комплексной системы стратегического управления ИТ-подразделением следует учитывать накопленный опыт в области управления ИТ, творчески применяя его к каждой конкретной ситуации. Данный опыт сосредоточен в Библиотеке передового опыта организации ИТ (IT Infrastructure Library, ITIL).

Формирование целей ИТ-подразделения

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

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

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

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

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

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

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

Стратегическая карта ИТ-директора

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

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

Перспектива "Финансы" показывает ожидания бизнеса от ИТ-подразделения (как деятельность ИТ-подразделения повлияет на финансовое состояние всей организации).

Перспектива "Клиенты" отражает ожидания клиентов ИТ-подразделения (как деятельность ИТ-подразделения должна выглядеть перед его клиентами).

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

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

Рис. 3. Стратегическая карта ИТ-директора.

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

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

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

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

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

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

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

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

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

Например, достижение цели "Обеспечивать оптимальный уровень надежности и доступности ИТ-сервисов" (рис. 5) можно отслеживать с помощью следующих КПР, источником которых выступает информационная система:

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

Достижение данной цели зависит от выполнения проекта по разработке "Плана доступности" и от эффективности следующих процессов: "Управление инцидентами" и "Управление проблемами".

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

В результате внедрения системы стратегического управления с использованием BSC ИТ-подразделение получает следующие преимущества:

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

Совершенствование бизнес-процессов ИТ-подразделения

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

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

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

Описание процессов ИТ-подразделения происходит "сверху вниз": сначала определяются процессы верхнего уровня, т. е. деятельность подразделения описывается "крупными мазками", а далее они детализируются до уровня рабочих мест. Пример процессов верхнего уровня ИТ-подразделения приведен на рис. 6. Для выделения процессов верхнего уровня ИТ-подразделения могут использоваться так называемые референтные модели, а именно ITSM HP Reference Model (Hewlett-Packard), Microsoft Operations Framework (Microsoft), IT Process Model (IBM), ARIS ITIL Reference Model (IDS Scheer).

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

• управление ИТ-стратегией;
• планирование и бюджетирование;
• контроллинг;
• предоставление сервисов;
• поддержка сервисов;
• управление проектами (проектирование и внедрение);
• обеспечение информационной безопасности;
• управление инфраструктурой;
• управление персоналом.

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

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

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

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

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

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

В рамках совершенствования для каждого из рассматриваемых процессов определяют следующие параметры:

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

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

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

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

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

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

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

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

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

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

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

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

Вместо заключения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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