Для успешного выполнения проекта все участники должны понимать, что, как и для чего делать. Вопрос «Для чего делать?» разрешается на первом этапе, когда руководство определяет цели проекта.
Рабочей группе необходимо четко понимать всю последовательность шагов по выполнению проекта — ответ на вопрос «Что делать?». Однако знать перечень шагов, ведущих к цели, недостаточно. Важно знать, как делать, т.е. иметь в распоряжении методики выполнения соответствующих работ. Для того чтобы дать рабочей группе инструмент для практического выполнения проекта, создается отдельный документ «Методика ведения проекта» (дааее — Методика).
Структура Методики достаточно проста. На рис. 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. Типовые ошибки при выполнении подготовительного этапа проекта
В заключение проанализируем типовые ошибки выполнения этапа. К их числу следует отнести:
• неадекватное участие руководителей организации и подразделений в про
екте;
• недостаточно проработанные цели и техническое задание;
• некорректно сформированная рабочая группа;
• плохо проработанная «Методика ведения проекта»;
• некачественное обучение сотрудников;
• недостаточное информирование сотрудников организации о ходе и ре
зультатах проекта.
Все указанные выше ошибки приводят к следующей ситуации. Работа по проекту поручена рабочей группе, состоящей из неквалифицированных сотрудников, имеющих небольшой практический опыт. Перед ней не поставлены четкие цели, поскольку руководство организации не проявило должной заинтересованности в данном проекте и не оказало поддержки рабочей группе. Отсутствие грамотно разработанной методики приведет к многократной переделке схем процессов без значительных улучшений. Сотрудники организации будут оказывать скрытое сопротивление деятельности рабочей группы и т.д. В результате, через два-три месяца работы руководство получит комплект моделей, который не сможет прочитать. Попытки анализа информации вызовут у руководства сильное раздражение, и в итоге проект будет прекращен, а часть сотрудников, входивших в рабочую группу, возможно будет уволена. Чтобы избежать такого печального хода событий, следует максимально привлекать руководство к участию в проекте, готовить качественные методические материшш, привлекать к проекту лучших специалистов организация и т.л.