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

Для успешного выполнения проекта все участники должны понимать, что, как и для чего делать. Вопрос «Для чего делать?» разрешается на первом этапе, когда руководство определяет цели проекта.

Рабочей группе необходимо четко понимать всю последовательность шагов по выполнению проекта — ответ на вопрос «Что делать?». Однако знать пере­чень шагов, ведущих к цели, недостаточно. Важно знать, как делать, т.е. иметь в распоряжении методики выполнения соответствующих работ. Для того чтобы дать рабочей группе инструмент для практического выполнения проекта, созда­ется отдельный документ «Методика ведения проекта» (дааее — Методика).

Структура Методики достаточно проста. На рис. 3.28 представлены ее основ­ные составляющие.

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

 

Глава 3 Описание и анализ бизнес-процессов__________________________________ 1 63

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

1. Цели проекта

2. Управление проектом

 

2.1. Структура управления проектом

2.2. Описание процесса выполнения работ (основные этапы)

2.3. Диаграмма Гантта (основные этапы)

2.4. Документы, регламентирующие управление проектом

2.5. Порядок взаимодействия сотрудников в проекте

2.6. Порядок формирования/расформирования рабочих групп

3. Описание этапов выполнения проекта
3.1. Этап 1. Подготовка проекта

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

3.1.2. Диаграмма Гантта (с разбивкой по исполнителям)

3.1.3. Методики выполнения работ по этапу 1

 

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

3.1.3.2. Методика разработки технического задания

3.1.3.3. Методика обучения руководителей и специалистов организации
процессному подходу

 

3.1.4. Требования к результатам работ по этапу 1

3.1.5. Требования к отчетности по этапу 1

164__________________________ В.В. Репин, В.Г, Елиферов. Процессный подход к управ лению

3.2. Этап 2. Формирование моделей бизнес-процессов

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

3.2.2. Диаграмма Гантта (с разбивкой по исполнителям)

3.2.3. Методики выполнения работ по этапу 2

 

3.2.3.1. Методика сбора информации в подразделениях

3.2.3.2. Методика формирования моделей бизнес-процессов верхнего
уровня

3.2.3.3. Методика проверки корректности информации, полученной в под­
разделениях

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

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

3.2.3.6. Методика проверки адекватности моделей процессов (цикл «ав­
тор — читатель»)

3.2.3.7. Методика работы с инструментальной средой моделирования

 

3.2.4. Требования к создаваемым моделям бизнес-процессов

3.2.5. Требования к настройке инструментальной среды моделирования

3.2.6. Требования к результатам работ по этапу 2

3.2.7. Требования к отчетности по этапу 2

3.3. Этап 3. Анализ процессов. Разработка регламентирующих документов

3.3.1. Описание процесса выполнения работ {сетевой график с разбивкой по
исполнителям)

3.3.2. Диаграмма Гантта {с разбивкой по исполнителям)

3.3.3. Методики выполнения работ по этапу 3

 

3.3.3.1. Методика разработки документов по процессам и подразделе­
ниям

3.3.3.2. Методика разработки и измерения: а) показателей эффективнос­
ти процессов; б) показателей продуктов; в) показателей удовлет­
воренности клиентов процесса

 

3.3.4. Требования к документации по процессам и подразделениям

3.3.5. Требования к результатам работ по этапу 3

3.3.6. Требования к отчетности по этапу 3

3.4. Этап 4. Реорганизация бизнес-процессов. Переход к процессной систе­
ме упраапения

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

3.4.2. Диаграмма Гантта (с разбивкой по исполнителям)

3.4.3. Методики выполнения работ по этапу 4

3.4.3.1. Методика организации упра&пения процессами (см. главу 4)

Глава 3 Описание и анализ бизнес-процессов__________________________________________ 1 55

3.4.3.2. Методика технико-экономического обоснования мероприятий по реорганизации бизнес-процессов

3.4.4. Требования к оформлению предложений реорганизации бизнес-про­
цессов

3.4.5. Требования к результату работ по этапу 4

3.4.6. Требования к отчетности по этапу 4

4. Глоссарий проекта

4.1. Термины предметной области

4.2. Термины системы процессного управления

4.3. Сокращения, допустимые в документации

5. Приложение № 1. Формы для сбора и хранения информации

5.1. Ф-И01 «Анкета аналитика»

5.2. Ф-И02 «Анкета сотрудника подразделения»

5.3. Ф-ИОЗ «Подшивка моделей процессов»

5.4. Ф-И04 «Репозиторий документов проекта»

 

6. Приложение № 2. Корпоративный стандарт «Регламент описания биз­
нес-процесса»

7. Приложение № 3. Корпоративные стандарты. Формы документов

 

7.1. Ф-П02 «Положение о подразделении»

7.2. Ф-ПОЗ «Должностная инструкции»

7.3. Ф-П04 «Рабочая инструкция»

8. Приложение № 4. Формы отчетных документов рабочей группы

8.1. Ф-ОД-1 «Протокол совещания рабочей групп»

8.2. Ф-ОД-1 «Отчет рабочей группы за неделю»

8.3. Ф-ОД-2 «Отчет по этапу»

8.4. Ф-ОД-3 «Отчет по анализу бизнес-процесса»

9. Приложение № 5. Положение о рабочей группе

10. Приложение № 6. Положение о мотивации рабочей группы и привлечен­
ных сотрудников подразделений

11. Приложение № 7. Программа обучения руководителей и специалистов
организации.

Описание состава и последовательности работ (процесса) и ответственных может приводиться в различных форматах:

• табличное представление;

• представление в виде сетевого графика:

• представление в виде схемы бизнес-процессов выполнения работ (напри­
мер, в формате IDEF3 или в виде блок-схемы).

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

165__________________________ В.В, Репин. В.Г. Елиферов Процессный подход к управлению

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

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

Одно из приложений Методики называется «Регламент описания бизнес-процесса». Именно этот документ является основой внутрикорпоративного стан­дарта описания. Этот документ служит нескольким целям:

1) содержит определение бизнес-процесса;

2) регламентирует параметры процесса, по которым он идентифицируется
в организации;

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

4) регламентирует порядок управления бизнес-процессом;

5) регламентирует порядок улучшения бизнес-процесса;

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

Подробно структура документа описана в главе 4.

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

При разработке Методики рабочая группа должна определить наиболее под­ходящее средство описания бизнес-процесса в виде схем какого-либо вида. В зависимости от целей проекта используют различные нотации: IDEF, DFD. ARIS. блок-схемы и т.д. Если проект предполагает описания процессов сверку вниз, то целесообразно применять несколько нотаций для разработки схем про­цессов (см. рекомендации в главе 3). Вполне возможен вариант, когда рабочая группа разрабатывает собственную нотацию описания процесса, базируясь на знании существующих мировых стандартов и лучшего практического опыта.

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

Глав а 3 Описание и анализ бизнес-процессов 167

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

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

1. Структура базы данных ARIS;

2. Количество, права, логины и пароли пользователей, включая системного
администратора;

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

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

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

6. Таблица с описанием типов связей между объектами моделей, здесь так­
же приводится графический вид связи, ее текстовое описание;

7. Требования к форматированию моделей (привязка к сетке, выравнива­
ние объектов, цвет и размер объектов, размер и тип шрифтов для объек­
тов моделей и атрибутов) с примерами;

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

9. Описание и тексты скриптов, предназначенных для вывода отчетов в таб­
личной форме.

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

168__________________________ В.В. Репин, В.Г. Епиферов, Процессны й подхо д к управлению

3.3.6. Технические аспекты подготовки проекта

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

• выбор инструментальной среды моделирования бизнес-процессов;

• приобретение и инсталляция программного обеспечения;

• создание инфраструктуры проекта.

В настоящее время на рынке представлено множество различных программ­ных продуктов, поддерживающих работы по моделированию бизнес-процессов. К числу наиболее популярных относится, например, система BPWin. В послед­нее время широко рекламируется инструмент&тьная среда ARIS Toolset. Есть и другие системы, большинство из которых относится к разряду CASE-систем. CASE-системы, в первую очередь, ориентированы на разработку систем авто­матизации организаций, в том числе на создание моделей потоков информации (DFD). моделей структуры данных, настройку СУБД. В меньшей степени они позволяют создавать модели бизнес-процессов.

Выбор программного обеспечения должен основываться на технико-эконо­мическом обосновании использования продукта, при этом необходимо учесть все этапы его жизненного цикла (например, по ГОСТ Р ИСО/МЭК 12207—99) еще на стадии проектирования.

Характерной чертой проекта моделирования бизнес-процессов яааяется одно­временная работа нескольких аналитиков. В крупных проектах создавать модели процессов одновременно могут около 10—12 сотрудников, в небольших — два или три. Когда в описании процессов участвует более одного человека, возни­кают проблемы координации работ, стыковки разрабатываемых частей модели процесса и т.д. Если программный продукт не поддерживает возможность веде­ния единой базы данных моделей процессов и одновременной работы несколь­ких исполнителей, то возникнут значительные сложности по обеспечению связ­ности и качества создаваемых моделей процессов. В какой-то степени влияние указанных проблем можно уменьшить путем создания корпоративного стандар­та на описание процессов, важны также опыт и квалификация руководителя проекта, но полностью они устранены быть не могут. С другой стороны, прак­тика показывает, что наличие программного обеспечения с единой базой дан­ных и многопользовательским режимом (ARIS — характерный пример) не все­гда обеспечивает качество построения комплекта моделей. Вопрос должен ре­шаться комплексно. На наш взгляд, путем четкой регламентации работ по про­екту, координации деятельности аналитиков, грамотного оперативного руко­водства можно успешно решать задачу описания процессов даже простейшими техническими средствами (MS Word, MS Visio).

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

Глава 3 Описание и анализ бизнес-процессов____________________________ 169

копировальный аппарат, цветной и черно-белый принтер, проектор для прове­дения презентаций и т.д.

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

3.3.7. Типовые ошибки при выполнении подготовительного этапа проекта

В заключение проанализируем типовые ошибки выполнения этапа. К их числу следует отнести:

• неадекватное участие руководителей организации и подразделений в про­
екте;

• недостаточно проработанные цели и техническое задание;

• некорректно сформированная рабочая группа;

• плохо проработанная «Методика ведения проекта»;

• некачественное обучение сотрудников;

• недостаточное информирование сотрудников организации о ходе и ре­
зультатах проекта.

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