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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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