«Процессный подхо I к управлению Моделирование бизнес-процессов Издательство Манн, Иванов и Фербер Москва, 2013 УДК 658.512 ЫЖ 65.291.216 Р41 Репин В. В., Елиферов В. Г. Р41 Процессный подход к управлению. Моделирование ...»

— лидерство, умение управлять людьми, коммуникабельность, инициативность, понимание реального положения вещей в организации, принципов построения функциональной ие­ — наличие четкой личной позиции по вопросу процессного под­ Глава 3. Описание и анализ бизнес-процессов — знание методик финансового менеджмента;

— знание и понимание принципов процессного управления и менеджмента качества (TQM, ISO, BPR);

— владение методиками разработки моделей бизнес-процессов в различных нотациях (обязательно: IDEFO, ARIS еЕРС; жела­ — владение методиками проектного управления;

— представление о возможностях программных продуктов по моделированию бизнес-процессов;

— опыт ведения проектов аналогичного масштаба.

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

собственного.

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

Отметим несколько моментов, важных при управлении рабочей группой:

— оперативный контроль деятельности аналитиков;

— ежедневные совещания (10-15 минут) перед началом рабочего — еженедельные письменные отчеты аналитиков по использо­ ванию рабочего времени и выполненной работе;

— ежемесячные расширенные совещания рабочей группы с под­ ведением итогов работы;

— плановые совещания по обсуждению моделей бизнес-процес­ сов, анализу и разработке рекомендаций.

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

3.3.3. Создание и обучение рабочих групп Рабочая группа (рабочая команда) формируется из сотрудников орга­ низации. Принцип формирования группы иллюстрирует рис. 3.26.

Рис. 3.26. Формирование рабочей группы на основании перечня подразделений, задействованных в выполне­ нии бизнес-процесса, который предстоит описывать. Как правило, из каждого такого подразделения берут по одному сотруднику.

К участникам рабочей группы предъявляются следующие требо­ — желание работать в проекте и улучшать деятельность органи­ — опыт работы в организации не менее трех лет;

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

— инициативность.

Желательно, чтобы привлекаемые сотрудники обладали знания­ ми в области менеджмента, в том числе менеджмента качества.

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

Табл. 3.5. Оценка сотрудников для отбора в рабочую группу и улучшать деятельность своего подразделения и вы­ сокая ценность сотрудника 5 Возможность быстрого обучения, возможность Оценка каждого кандидата производится по 10-балльной шка­ ле руководителем проекта на основе данных, предоставленных 202 Процессный подход к управлению. Моделирование бизнес-процессов руководителем подразделения, и личных собеседований с сотрудни­ ками. Данная таблица поможет при принятии решения, приглашать ли сотрудника в рабочую группу.

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

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

Очевидно, что подбор сотрудников в группу должен осущест­ вляться с учетом мнений и пожеланий руководителей подразделений.

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

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

— принципы и методы управления процессами (идеология про­ — методы измерения эффективности и качества процессов;

— методы описания и регламентации бизнес-процессов;

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

— основы проектного управления.

Обучение по этим темам целесообразно проводить в течение трех семинаров-тренингов: первый — по темам 1-2, второй — по теме 3, третий — по теме 4. Примерная программа обучения приводится Кроме указанной программы обучения, сотрудники должны са­ мостоятельно ознакомиться с рядом работ по теме управления про­ Дальнейшее обучение рабочей группы продолжается при выпол­ нении конкретной работы по проекту, а именно:

— диагностики существующих процессов;

— структуризации дерева целей проекта;

Глава 3. Описание и анализ биз1 iec-процессов — разработки методики выполнения проекта;

— обучения руководителей и сотрудников подразделений.

Табл. 3.6. Типовая программа обучения сотрудников рабочей группы 1 Принципы и методы управ­ 1. Классификация процессов организации.

ления процессами 2. Философия процессного управления (Деминг, Джуран, 2 Методы измерения эффек­ 1. Базовые методы измерения эффективности и качества тивности и качества про­ процессов.

3 Методы описания и регла­ 1. Стандарты моделирования бизнес-процессов (IDEF0, ARIS ментации бизнес-процессов еЕРС, BPMN).

4 Инструментарий модели­ 1. Обзор рынка инструментальных средств моделирования рования бизнес-процессов бизнес-процессов.

(ARIS, Casewise, Business 2. Моделирование процессов в системе ARIS.

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

204 Процессный подход к управлению. Моделирование бизнес-процессов Руководители компании должны учиться не менее 30-40 часов в году Специалисты и рабочие также должны повышать свой уро­ вень. Почему мы настаиваем на необходимости обучения? Дело в том, что внедрение процессного подхода к управлению и системы менеджмента качества даст реальные результаты только в случае активного участия персонала организации в работе по улучшению процессов. Для выполнения такой работы мало одного желания — нужны специальные знания, методики. Обучая персонал, руководи­ тель компании формирует определенную корпоративную культуру.

Без высокой культуры получать высокие экономические резуль­ таты и быть конкурентоспособным в длительной перспективе не­ Как обучать персонал для его подготовки к проекту внедрения процессного управления? В табл. 3.7 показаны темы обучения и при­ мерный объем времени в зависимости от уровня сотрудников.

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

Как видно из табл. 3.7, руководители среднего звена и специали­ сты учатся больше всех остальных. Дело в том, что именно на них приходится основная нагрузка при выполнении проекта.

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

В первую очередь к ним относятся:

— распорядительные документы руководства организации;

— совещания для руководителей подразделений;

— совещания для сотрудников подразделений;

— информирование через стенгазеты и корпоративную сеть — информирование при проведении обучения.

Глава 3. Описание и анализ бизнес-процессов Табл. 3.7. Обучение персонала организации Руководители 1. Философия процессного управления (Деминг, верхнего уровня Джуран, Кросби и др.).

(заместители 2. Принципы управления процессами. Цикл РОСА.

директора, на­ 3. Методика внедрения процессного управления чальники управ­ Руководители 1. Философия процессного управления (Деминг, среднего уровня Джуран, Кросби и др.).

подразделений) 3. Методика внедрения процессного управления (экономисты, 4. Разработка документации, регламентирующей ИТР и т. д.) управление процессами.

На рис. 3.27 представлена возможная последовательность дей­ ствий, необходимых для информирования и обучения персонала.

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

Эти кадры будут обучать, отделы — реорганизовывать, упразднять и т. д. Но это будет происходить плавно, в длительной (полтора-два года) перспективе и поэтому не должно негативно отразиться на ма­ териальном положении сотрудников.

Рис. 3.27. Информирование и обучение персонала Отметим, что обучение руководителей верхнего уровня целе­ сообразно проводить до утверждения целей и ТЗ проекта. Полезно, когда руководители проходят обучение еще до принятия решения о начале проекта. В этом случае у них есть возможность корректнее сформулировать его цели.

Информирование персонала необходимо оперативно осущест­ влять и по ходу проекта. Важно доносить до людей данные о его успе­ хах, причем в конкретной и простой форме. К сожалению, на прак­ тике распространена следующая ситуация. Формально объявляется начало проекта. Рабочая группа приступает к сбору информации в отделах. Большинство сотрудников не представляют себе, для чего все это делается. В организации возникают и распространяются различные слухи негативного характера. Постепенно складывается Глава 3. Описание и анализ бизнес-процессов атмосфера недоверия к проекту. Возникает скрытое сопротивление деятельности рабочей группы. Людям свойственно бояться всего нового, незнакомого, способного повлиять на их более или менее устойчивое положение в организации. В результате формируется оппозиционное отношение большинства сотрудников к проекту, ко­ торое переломить очень трудно. Заметим, что целесообразно среди участников рабочей группы выделить отдельных сотрудников, от­ ветственных за оперативное освещение хода и результатов проекта внутри организации.

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

Рабочей группе необходимо четко понимать всю последователь­ ность шагов по выполнению проекта — ответ на вопрос «что делать?».

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

Структура методики проста. На рис. 3.28 представлены ее основ­ ные компоненты.

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

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

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

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

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

2.3. График Ганта (основные этапы).

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

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

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

3. Описание этапов выполнения проекта.

3.1. Этап 1. Подготовка проекта.

3.1.1. Описание процесса выполнения работ (сетевой гра­ Глава 3. Описание и анализ бизнес-процессов 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.

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

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

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

3.2.3.1. Методика сбора информации в подразделе­ 3.2.3.3. Методика проверки корректности получен­ 3.2.3.4. Методика формирования детальных моделей 3.2.3.6. Методика проверки адекватности моделей 3.2.4. Требования к создаваемым моделям бизнес-про­ 210 Процессный подход к управлению. Моделирование бизнес-процессов 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. Методика организации управления процес­ 3.4.3.2. Методика технико-экономического обосно­ Глава 3. Описание и анализ бизнес-процессов 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. Программа обучения руководителей и спе­ циалистов организации.

212 Процессный подход к управлению. Моделирование бизнес-процессов Описание состава и последовательности работ (процесса) и от­ ветственных может приводиться в различном формате:

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

— представление в виде сетевого графика;

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

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

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

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

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

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

— регламентирует параметры процесса, по которым он иденти­ — регламентирует порядок описания бизнес-процесса (включая требования к графическим схемам процессов, реализован­ лава 3. Описание и анализ бизнес-процесса в — регламентирует порядок управления бизнес-процессом;

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

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

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

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

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

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

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

1. Структура базы данных АЬШ.

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

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

6. Таблица с описанием типов связей между объектами моделей.

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

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

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

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

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

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

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

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

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

Характерная черта проекта моделирования бизнес-процессов — это одновременная работа нескольких аналитиков. В крупных про­ ектах создавать модели процессов могут сразу около 10-12 сотруд­ ников, в небольших проектах — 2-3. Когда в описании процессов участвует более одного человека, возникают проблемы коорди­ нации работ, стыковки разрабатываемых частей модели процесса и т. д. Если программный продукт не поддерживает возможность ведения единой базы данных моделей процессов и одновременной 216 Процессный подход к управлению. Моделирование бизнес-процессов работы нескольких исполнителей, то возникнут значительные слож­ ности по обеспечению связности и качества создаваемых моделей процессов. В какой-то степени влияние указанных проблем можно уменьшить за счет наличия корпоративного стандарта на описание процессов и искусства руководителя проекта, но полностью они устранены быть не могут. В то же время практика показывает, что наличие программного обеспечения с единой базой данных и много­ пользовательским режимом (Business Studio — характерный пример) не всегда обеспечивает построение качественного комплекта моде­ лей. Вопрос должен решаться комплексно.

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

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

— неадекватное участие руководства в проекте;

— плохо проработанные цели и ТЗ;

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

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

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

— неадекватное освещение проекта среди сотрудников органи­ Все указанные выше ошибки приводят к следующей ситуации.

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

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

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

Для чего нужны схемы процессов верхнего уровня? Нельзя ли сразу приступить к описанию детальных бизнес-процессов, исполь­ зуя нотацию типа Work Flow? Ответы на эти вопросы достаточно просты. В рамках комплексного подхода к описанию процессов ор­ ганизация рассматривается как сложная система. Ее устройство про­ ще понять, начиная описание ее процессов сверху, укрупненно. По­ пытки сразу перейти на детальный уровень описания на практике не приводили к успеху. Можно выделить несколько целей описания бизнес-процессов верхнего уровня организации:

— понимание основ деятельности организации;

— увязка результатов деятельности (выходов) и процессов, опре­ деление границ процессов;

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

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

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

Определив перечень входов/выходов, рабочая группа формирует предварительный перечень бизнес-процессов верхнего уровня, при­ чем основных. Основные процессы создают ценность для потребите­ лей, их выходы — это продукция, поставляемая основным клиентам организации. Второй критерий выделения основных процессов — взаимодействие с внешней средой организации. Составив перечень Глава 3. Описание и анализ бизнес-процессов основных бизнес-процессов, рабочая группа формирует следующие таблицы (табл. 3.9-3.10).

Табл. 3.8. Пример выделения входов/выходов организации * Предварительная формулировка процесса.

** Можно отнести эти выходы как к процессу «Сбыт», так и к процессу «Производство».

Табл. 3.9. Перечень основных процессов 220 Процессный подход к управлению. Моделирование бизнес-процессов Табл. 3.10. Входы/выходы основного процесса № Наименование входа/выхода процесса «Производство» ] Вспомогательные материалы (из процесса«Снабжение) Сертификат соответствия на ГП (вход процесса «Сбыт») В табл. 3.10 показаны не только внешние, но и внутренние вхо­ ды и выходы. Внутренние входы/выходы могут возникать из-за на­ личия информационных и материальных потоков между бизнеспроцессами, включенными в перечень основных.

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

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

На рис. 3.30 представлен результат определения процессов верх­ него уровня: показаны основные и вспомогательные процессы и входы/выходы.

Рис. 3.30. Увязка основных и вспомогательных процессов Следующий шаг по разработке моделей процессов верхнего уров­ ня — это определение функций (процессов), из которых они состоят.

Рабочая группа формирует таблицы следующего вида (табл. 3.11).

Табл. 3.11. Состав функций процесса Наименование функций процесса «Производство»

Разрабатывать график ремонтов Формировать производственную программу Осуществлять подготовку производства 222 Процессный подход к управлению. Моделирование бизнес-процессов Где брать названия функций, входящих в процесс? Поскольку но­ воиспеченный бизнес-процесс как объект управления не регламен­ тирован ни в каких документах организации, источниками инфор­ мации о нем могут служить:

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

Таким образом, рабочая группа вынуждена интервьюировать руко­ водителей подразделений с целью получить ответ на вопрос: «Какие функции содержатся в бизнес-процессе верхнего уровня?» Какой ответ может дать руководитель подразделения? Во-первых, для него непонятно, что представляет собой объект «бизнес-процесс верхне­ го уровня». Во-вторых, он привык оперировать категориями струк­ турных подразделений и их границ. Ему сложно ответить на по­ ставленный вопрос. Более правильным будет подход, когда рабочая группа ставит вопрос «Какие функции выполняет ваше подразде­ ление и какие основные выходы оно формирует?». Ответить на него Далее рабочая группа вынуждена самостоятельно интегриро­ вать полученную информацию о функциях и субъективно припи­ сывать их процессам. К чему это может привести? Субъективность распределения функций по процессам выливается в противоречия при дальнейшей работе с моделями: кто отвечает за процесс в целом, кому целесообразно делегировать те или иные функции, как распре­ делена ответственность и т. д. Тем не менее большинство предлагае­ мых на рынке методик предполагает описание процессов верхнего уровня без привязки к подразделениям, что, на наш взгляд, неэф­ Глава 3. Описание и анализ бизнес-процессов Итак, рабочая группа разработала перечень функций, входящих в процесс. Теперь этот процесс нужно представить в виде графиче­ ской схемы. Как это лучше сделать? Есть несколько правил формиро­ вания схем моделей бизнес-процессов верхнего уровня:

— ограниченное количество функций на схеме (не более шести­ — все функции должны быть одного уровня;

— названия функций (групп функций) должны быть по воз­ можности реальными;

— на схеме должны быть отображены основные материальные и информационные потоки;

— должна быть отражена информация по управлению про­ — все функции должны быть привязаны к подразделениям.

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

Рис. 3.31. Пример неправильного описания процесса верхнего уровня Какой из представленных на рис. 3.31 процессов, на ваш взгляд, является наиболее корректным? Первый вариант не устраивает нас 224 Процессный подход к управлению. Моделирование бизнес-процессов по нескольким причинам. Во-первых, функция «Обработка заявки клиента» детальна и не исчерпывает всех работ, связанных с дея­ тельностью по формированию портфеля заказов. Во-вторых, объект «Приход денег» вовсе не является функцией — он отображает собы­ тие. При кажущейся простоте примера он часто встречается на прак­ тике, когда руководители, не обученные методикам описания про­ цессов, пытаются сформулировать и описать реальный ход процесса.

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

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

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

На рис. 3.32 представлена схема процесса верхнего уровня, раз­ работанная руководителями и специалистами одного из предпри­ ятий по ходу проведения семинара-тренинга. Заметим, что приво­ димый далее процесс не лишен недостатков и не может служить шаблоном для разработки аналогичных процессов в других орга­ Iлава 3. Описание и анализ бизнес-процессов Рис. 3.32. Пример процесса верхнего уровня. Процесс «закупки»

Представление типового процесса «закупки» на верхнем уровне приводится на рис. 3.33. Процесс сформирован при помощи нотации ARIS Value-added Chain Diagram. Приведенный на рис. 3.33 процесс описан в нотации VAD ARIS.

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

1. Функции планирования закупок ТМЦ (товарно-материаль­ 2. Функции формирования заказов на ТМЦ.

3. Функции получения, хранения и отпуска ТМЦ в произ­ 4. Функции оплаты ТМЦ и контроля дебиторской задолжен­ 5. Функции бухгалтерского учета операций по закупкам ТМЦ.

226 Процессный подход к управлению. Моделирование бизнес-процесса в Глава 3. Описание и анализ бизнес-процессов Обратные связи показаны на схеме процесса при помощи входя­ щих и исходящих объектов. Например, функция «Получать, хранить и отпускать ТМЦ» имеет выход под названием «Данные по состоя­ нию склада и движению ТМЦ», который является входом функции «Планировать закупки ТМЦ». На приведенной схеме можно найти и другие обратные связи. Информационные и материальные потоки показаны на схеме процесса «Закупка» в укрупненном виде. При по­ следующей декомпозиции на более детальные процессы эти потоки также будут рассматриваться более подробно.

Тот же самый процесс, но разработанный в нотации IDEF0, пред­ ставлен на следующем рис. 3.34. Этот процесс будет подробно рас­ смотрен в главе 4 при описании цикла PDCA. Таким образом, при формировании процесса верхнего уровня очень важно отобразить основные типы потоков и существующие обратные связи. Если схема процесса верхнего уровня сформирована корректно, то существенно облегчается задача последующей декомпозиции процессов.

Какую нотацию использовать для описания процессов верхнего уровня? На наш взгляд, вполне можно обойтись простейшими сред­ ствами рисования блок-схем, такими как MS Word или Visio. Если использовать более серьезные инструменты, то это будет, безуслов­ но, стандарт IDEF0 (см. главу 2).

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

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

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

лава 3. Описание и анализ бизнес-процессов 3.5. Методика проверки адекватности моделей бизнес-процессов После того как рабочая группа подготовит модели бизнес-процессов верхнего уровня, необходимо проверить схемы процессов с точки зрения соответствия реальной ситуации на предприятии. Такая ра­ бота называется проверкой адекватности моделей бизнес-процессов.

Существуют определенные правила проверки, в частности многие из них описаны в документации по ЮЕБО [2; 3]. Простейшая схема проверки адекватности представлена на рис. 3.35.

Рис. 3.35. Цикл «автор - читатель»

Цикла проверки адекватности (цикл «автор — читатель») начи­ нается с подготовки аналитиком рабочей группы подшивки схем моделей бизнес-процессов. Оптимальный объем такой подшивки — не более 10-12 листов формата А4. Комплект моделей большего объ­ ема трудно воспринимать, что приведет к снижению качеству про­ верки. Количество листов в подшивке определяется из следующего расчета: время проверки должно занимать у рецензента не более полутора-двух часов.

После того как аналитик подготовит комплект моделей, он пере­ дает его ответственному за архив. Эту функцию может выполнять 230 Процесса ы й п од ход к у правлены т. Мо Ъепиротпие бизпес-процес со в один из сотрудников рабочей группы, который отвечает, кроме того, за ведение документооборота проекта. Ответственный за архив сни­ мает копию с подшивки моделей и передает ее рецензенту, в роли которого может выступать руководитель или специалист подразде­ ления. Опыт показывает, что целесообразно вместе с комплектом мо­ делей передавать рецензенту сопроводительное письмо, в котором указаны официальные сроки передачи и требуемое время проверки.

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

Рецензент анализирует полученный комплект моделей, отмечая на его листах свои замечания. Для удобства отображения замеча­ ний целесообразно представлять модели процессов в типовой рамке стандарта ШЕЕО. В среднем количество замечаний для тщательно проработанной модели не должно составлять более 8-10. После того как рецензент сделает все замечания, он передает комплект ответ­ ственному за архив.

Ответственный за архив снимает копию с комплекта моделей, содержащих замечания рецензента. Затем подшивка передается ана­ Аналитик просматривает замечания рецензента. В случае согла­ сия он вносит их в модели процессов. После этого формируется но­ вый комплект исправленных моделей, который также передается от­ ветственному за архив. Далее цикл «автор — читатель» повторяется.

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

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

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

— рецензент должен знать основные цели проекта;

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

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

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

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

Табл. 3.12. Реакция руководителей при проверке адекватности Реакция руководителя 1. «Со всем согласен»

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

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

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

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

3.6. Методика детального описания бизнес-процессов В данном разделе будут рассматриваться методики, предназначен­ ные для получения детальных моделей бизнес-процессов органи­ зации. На рис. 3.36 показан общий принцип разработки детальных моделей методом декомпозиции.

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

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

— методику сбора информации в подразделениях;

— методику формирования схем процессов с использованием выбранной нотации;

— методику проверки корректности моделей процессов (про­ верка на соответствие нотации);

— методику проверки адекватности моделей процессов.

Указанные методики будут рассмотрены далее.

3.6.1.Методика сбора информации в подразделениях Цель этой методики — описание этапов выполнения работ по сбору информации в подразделениях и последующей ее обработке с целью использования при формировании моделей бизнес-процессов.

Ключевая задача при проведении сбора информации — опреде­ ление основных источников знаний в организации. Руководитель 234 Процессный подход к управлению. Моделирование бизнес-процессов проекта формирует перечень внутренних экспертов организации, которые должны быть проинтервьюированы. К их числу относятся руководители и специалисты подразделений. При формировании та­ кого перечня полезно предварительно получить основную информа­ цию об этих экспертах. Она может включать: должность, ответствен­ ность и полномочия, количество подчиненных, квалификацию, стаж работы, отношения в коллективе и т. д. Кроме того, должны быть по­ лучены контактные данные: телефон, e-mail. Выбор экспертов для интервьюирования осуществляется в подразделениях, участвующих в выполнении описываемых бизнес-процессов.

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

— положения о подразделениях;

— должностные и рабочие инструкции;

— документы методологического характера;

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

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

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

Глава 3. Описание и анализ бизнес-процессов Табл. 3.13. Перечень работ по сбору информации Наименование этапа Краткое описание этапа Определение целей сбора Руководитель проекта совмест­ ствующих источников аналитик) определяет перечень 3 Планирование работ Руководитель проекта планирует по сбору и обработке ин­ работу по сбору и обработке и анализ информации (ра­ мативных документов в подраз­ бота с документами) делениях (положения об отделах, ректировка вопросов для 5 Подготовка документации, Аналитики подготавливают необходимой для сбора 6 Подготовка к проведению Руководитель проекта (ведущий Выполнен инструктаж ана­ 7 Согласование времени Руководитель проекта согласует Согласовано время про­ проведения интервью время проведения интервью 8 Проведение интервью Ведущие аналитики и аналитики Собранная информация 9 Обработка полученной Ведущие аналитики и аналитики Информация в виде элек­ 10 Проверка полученной ин­ Полученная информация про­ Проверенная и систематизи­ формации на корректность веряется на корректность рованная информация 236 Процессный подход к управлению. Моделирование бизнес-процессов Сотрудники, как правило, подробно рассказывают обо всех дета­ лях процесса. Поэтому им кажется, что они изложили аналитику всю нужную информацию. Аналитик, в свою очередь, считает, что узнал лишь часть интересующих его сведений, и будет настаивать на про­ ведении повторных интервью. После второго-третьего раза сотруд­ ник уже не готов повторять то, что, на его взгляд, было неоднократно сказано. Рассмотренная ситуация показана на рис. 3.37.

Рис. 3.37. Взаимодействие аналитика и сотрудника подразделения Чтобы избежать подобной ситуации, аналитик должен обратить внимание на следующие особенности работы по организации сбора информации:

— необходимо четко представлять цели сбора информации;

— необходимо заранее сформулировать ограниченный перечень — при проведении интервью следует ограничивать ответы со­ трудника и направлять их в нужном аналитику направлении;

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

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

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

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

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

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

Табл. 3.14. Методики проведения интервью 1. Подготовить формы анкет для сбора информации.

2. Провести обучение сотрудников отделов.

3. Раздать анкеты в отделы (сотрудники заполняют анкеты).

4. Собрать и обработать анкеты 2 1. Подготовить анкеты.

2. Провести обучение сотрудников отделов.

4. Заполнить анкеты с использованием полученной информации 3 1. Сформировать модели бизнес-процессов, непосредственно работая на персональном компьютере, со слов сотрудников отдела (формула: 1 сотрудник + 1 аналитик + 1 компьютер) Первая методика предполагает следующие шаги по сбору ин­ формации. Разрабатывается специальная анкета для сотрудников (рис. 3.38). К ней прикладываются инструкция и пример заполнения.

Затем издается распоряжение руководителя организации по про­ ведению анкетирования в подразделениях. Нужное количество ан­ кет раздается в подразделения. За отведенное время (два-три дня) сотрудники подразделений заполняют анкеты. Участники рабочей 238 Процессный подход к управлению. Моделирование бизнес-процессов группы контролируют сроки их заполнения и собирают анкеты. По­ сле этого рабочая группа приступает к их обработке. Как показывает практический опыт, большая часть анкет оказывается заполненной некорректно: они неполны, отсутствует описание многих функций, уровень их описания различается, нет данных о входящих/исходящих документах и т. д. Использовать полученные анкеты достаточ­ но сложно. Большая часть содержащейся в них информации в даль­ нейшем не используется в проекте. В чем причина низкого качества заполнения анкет? В первую очередь это нежелание сотрудников аккуратно и полно отвечать на поставленные вопросы. Работа по за­ полнению анкет является для них дополнительной и неоплачивае­ мой нагрузкой. Вторая причина — непонимание персоналом целей этой работы. Третья причина заключается в том, что сотрудники не обучены методике работы с анкетами.

Рис. 3.38. Форма анкеты для сбора информации в подразделении « » 201_ г.

Наименование бизнес-процесса_ Подразделение ФИО сотрудника Должность Дата_ Время проведения интервью: спо Перечень вопросов интервью:

1. 2. 3. _ 4. 5. * Ответственный руководитель.

** Исполнитель функции.

*** Должностное лицо, получающее информацию.

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

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

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

Какую из трех методик сбора информации выбрать? На наш взгляд, наиболее эффективной является вторая методика. Ее осно­ ва — проведение квалифицированных интервью с сотрудниками подразделений с последующей обработкой информации. Следует от­ метить, однако, что данная методика предъявляет значительные тре­ бования к квалификации и опыту аналитиков, которые выполняют интервьюирование.

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

Например, сотрудник А. К. Куратный предоставил информацию, что результатом его работы является документ 1, который он передает в соседний отдел сотруднице Н. Е. Точной. Но она не назвала в своем интервью какого-либо документа, получаемого от А. К. Куратного. Та­ ким образом, можно уточнить полученную информацию еще на ста­ дии ее обработки, то есть до создания моделей бизнес-процессов.

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

Общие правила проведения интервью:

— малая длительность (от одного до двух часов);

— не перед обедом и не поздно вечером (перед концом рабоче­ — четко представлять цель интервью;

— объяснить свою роль сотруднику подразделения перед нача­ Глава 3. Описание и анализ бизнес-процессов — включать в интервью ограниченное количество вопросов;

— все вопросы должны быть подготовлены и продуманы за­ — перед проведением интервью желательно ознакомиться с до­ кументацией по рассматриваемым вопросам.

Что нужно сказать сотруднику подразделения в начале интервью:

— почему проводится это интервью;

— от кого получено разрешение его проводить;

— кто еще будет проинтервьюирован;

— по какому принципу и кто выбирал интервьюируемых;

— как будет использована полученная информация;

— будет ли интервью анонимным;

— будет ли интервью отражено в отчете;

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

— почему важно получить детальную и точную информацию в процессе интервью.

Некоторые полезные советы по проведению интервью:

— не отвлекаться на пространные комментарии по проблемам, связанным с обсуждаемым предметом;

— не пытаться завязать дружеские отношения;

— не указывать интервьюируемому на его затруднения при опи­ сании предметной области;

— давать интервьюируемому время подумать;

— отделять мнения от фактов;

— не иронизировать;

— концентрироваться на наиболее сложных аспектах предмет­ — не пытаться показывать свои знания, быть скромным (экс­ перт не вы, а интервьюируемый);

— не увеличивать длительность проведения интервью.

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

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

Рассмотрим методику создания моделей детальных процессов на примере работы с системой ARIS Toolset. При ее использовании целесообразно выполнить следующие работы:

— создать ряд вспомогательных моделей:

• модель организационной структуры компании в нотации • модель функций, выполняемых в подразделениях, в нота­ • модели входящих и исходящих документов и материаль­ ных потоков в формате Technical Term Diagram;

• другие вспомогательные модели (создаются в соответ­ ствии с требованиями «Методики по описанию бизнеспроцессов»);

— декомпозировать функции модели процессов верхнего уров­ ня, создавая модели в нотациях Value-added Chain и еЕРС;

— выполнить анализ корректности построенных детальных мо­ делей процессов, включая проверку полноты и увязки деталь­ Глава 3. Описание и анализ бизнес-процессов — выполнить проверку адекватности детальных моделей про­ — при необходимости внести изменения в модели детальных На рис. 3.39 показан принцип использования вспомогательных моделей в АШБ.

Рис. 3.39. Использование вспомогательных моделей в АШБ Возможны два подхода к созданию моделей процессов. В первом случае аналитик берет данные непосредственно из анкет и других документов и сразу формирует графическую схему процесса. Во вто­ ром — сначала формирует вспомогательные модели, а затем созда­ ет модели процессов, используя данные вспомогательных моделей.

Во втором случае объем работ существенно возрастает, но качество создаваемых моделей значительно повышается. При непосредствен­ ном переносе информации из форм в графическую схему модели возможны ошибки, связанные с некорректным наименованием функций, исполнителей, документов и т. д. Есть и вторая проблема, состоящая в том, что при создании новых объектов (функций, ис­ полнителей и т. п.) непосредственно в модели полученная информа­ ция разрозненна и хаотична. Другим аналитикам потребуется искать 244 Процессный подход к управлению. Моделирование бизнес-процессов в базе процессов уже определенные кем-то объекты. Часто вместо этого они определяют новые объекты с отличающимися от уже су­ ществующих именами. Сказанное иллюстрирует рис. 3.40.

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

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

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

Рис. 3.41. Параллельная декомпозиция процессов Рассмотрим пример на рис. 3.41. Рабочая группа декомпозиру­ ет процесс верхнего уровня, состоящий их трех функций. Анали­ тик 1, г-н Н. Е. Радивый, создал модель нижнего уровня, состоящую из двух функций уровня подразделения (на рис. 3.41 не показаны).

На его взгляд, информации, содержащейся в названиях функций мо­ дели, вполне достаточно для понимания реального процесса. Анали­ тик 2, г-н О. Тщательный, расписал функции процесса очень подроб­ но (детальное описание работ на каждом рабочем месте), включив в него 16 функций, и фактически перешел на более низкий уровень декомпозиции, чем это требовалось в проекте. Наконец, аналитик 3, г-н А. Декватный, расписал процесс в соответствии с требованиями методики и заданием руководителя проекта (уровень функций, вы­ полняемых на рабочих местах). При попытке склеить из трех кусков процесса одну общую картину руководитель проекта испытывает 246 Процессный подход к управлению. Моделирование бизнес-процессов большие трудности, так как уровни детальных моделей не совпада­ ют. Чтобы этого не происходило, руководитель проекта должен опе­ ративно контролировать работу аналитиков с точки зрения уровня описания и увязки моделей детальных процессов между собой.

Можно выделить несколько характерных типов несоответствий создаваемых детальных процессов между собой:

— по уровню детальности описания;

— по входам/выходам и событиям при переходе с уровня — по входам/выходам и событиям на одном уровне;

— по выполняемым функциям и исполнителям на одном уровне.

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

На рис. 3.42 показано несколько несоответствий. Во-первых, на модели процесса верхнего уровня функция 1 может завершаться двумя альтернативными событиями 4 и 5, но на декомпозирующей модели одно из завершающих событий (событие 10) не соответству­ ет модели верхнего уровня. Вторая нестыковка — по входам и вы­ ходам. На процессе верхнего уровня входящим является документ 1, а исходящим — документ 2. На схеме процесса нижнего уровня эти документы не указаны, зато есть входящий документ 3 и исходящий документ 4. Третий вид нестыковок, показанный на рис. 3.42, свя­ зан с использованием символов логики: исключающего (на схеме процесса верхнего уровня) и неисключающего (на схеме детального процесса) логического «ИЛИ». Несоответствия по входам/выходам и событиям на схемах моделей одного уровня аналогичны несоот­ ветствиям, показанным на рис. 3.42.

На рис. 3.43 показаны несоответствия, связанные с моделирова­ нием функций. Процесс верхнего уровня, состоящий их двух функ­ ций, декомпозируется на два детальных процесса. Аналитик 1, выпол­ няющий декомпозицию функции А, указывает в модели функцию X, которую, по его мнению, выполняет цех 1. В то же время аналитик 2, лава 3. Описание и анализ бизнес-процессов описывающий функцию Б, считает, что функция X должна быть от­ несена к его процессу и что выполняет ее цех 2. Таким образом, воз­ никает нестыковка на одном уровне детализации.

Рис. 3.42. Несоответствия при переходе с уровня на уровень Кроме указанной нестыковки, на рис. 3.43 можно найти еще две. Первая — это выполнение функции А2 цехом 2, в то время как на верхнем уровне показан один исполнитель функции А. Вторая нестыковка — на верхнем уровне ресурс 1 является входящим для функции 1 и 2, но на нижнем уровне, при декомпозиции функции Б, он не показан.

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

2Л8 Процессный подход к управлению. Моделирование бизнес-процессов Рис. 3.43. Несоответствия по функциям на одном уровне Заметим, что при работе в нотации ШЕИО проблема увязки де­ тальных моделей не так актуальна, поскольку при переходе с уровня на уровень входы/выходы диаграмм взаимоувязаны.

Рис. 3.44 показывает в общем виде проблему пересечения моде­ лей, параллельно создаваемых несколькими аналитиками. Проблема состоит в том, что при декомпозиции процесса детальные описания его функций могут значительно перекрываться. Причиной тако­ го эффекта может быть неадекватно описанный процесс верхнего уровня, в котором допущены ошибки при определении входящих Глава 3. Описание и анализ бизнес-процессов Рис. 3.44. Пересечения детальных процессов Когда становится ясно, что пересечений детальных процессов избежать не удается, необходимо пересмотреть процесс верхнего уровня. Таким образом, работа по созданию моделей является ите­ рационной: создание моделей верхнего уровня -> создание деталь­ ных моделей -> анализ схем детальных моделей -> пересмотр моделей верхнего уровня -> корректировка детальных моделей и т. д. Возмож­ ность итерационного пересмотра моделей необходимо учитывать при планировании проекта.

Говоря об описании детальных процессов, следует упомянуть о времени, необходимом для такой работы. Практический опыт показывает, что для описания детального процесса, состояще­ го из 8-12 функций, квалифицированному аналитику требуется полтора-два рабочих дня. Это минимальное время. На практике реальное время работы следует увеличить на коэффициент 3. Дело в том, что при работе в подразделениях постоянно происходит сдвиг сроков за счет:

— переноса времени интервью и его сокращения;

— превышения времени проверки адекватности моделей со­ — технических проблем при работе с инструментальной средой.

250 Процессный подход к управлению. Моделирование бизнес-процессов На диаграммах 3.2-3.5 приводится пример планового и фактиче­ ского участия сотрудников в проекте.

Диаграмма 3.2. Плановое и фактическое участие в проекте руководителей верхнего уровня Руководители верхнего уровня обязательно должны принимать участие в проекте. Более того, степень их участия должна быть значи­ тельна — до 10-15% рабочего времени, или 4-6 часов в неделю. К со­ жалению, на практике руководители уделяют проекту слишком мало времени, что является одной из важнейших причин неудач проектов моделирования и реорганизации бизнес-процессов.

Диаграмма 3.3. Плановое и фактическое участие в проекте руководителей подразделений Руководители среднего уровня (начальники управлений и подраз­ делений организации) должны уделять проекту не менее 8-10 часов Глава 3. Описание и анализ бизнес-процессов в неделю, или 1,5-2 часа в день. Они участвуют в следующих работах по проекту:

— проведение интервью;

— анализ и проверка адекватности моделей процессов;

— совещания по обсуждению проблем процессов и поиску пу­ тей их устранения;

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

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

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

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

252 Процессный подход к управлению. Моделирование бизнес-процессов Диаграмма 3.5. Плановое и фактическое участие в проекте рабочей группы Участие рабочей группы в проекте, как правило, оставляет желать лучшего. Обычно предполагается, что эти сотрудники будут тратить 95-100% рабочего времени на проект. На практике они 30% времени и более загружены текущими делами в своем подразделении. Руково­ дителю проекта приходится прикладывать значительные усилия для обеспечения 100%-ного отрыва рабочей группы от текущей работы.

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

Г-н М. О. Гучий считал, что на это потребуется не более двух недель.

Руководитель проекта взял за основу следующие показатели:

— количество рабочих мест в отделе сбыта — 15;

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

Общее количество функций, выполняемых в отделе сбыта:

Глава 3. Описание и анализ бизнес-процессов Время описания такого количества функций одним аналитиком:

(120/10) х 2 дня = 24 рабочих дня.

Время описания процессов с учетом наличия трех аналитиков в рабочей группе: 24/3 = 8.

Итоговое время описания процессов с учетом поправочного ко­ эффициента: 8 х 3 = 24 рабочих дня, или 5 недель.

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

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

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

— несоответствия выбранной нотации;

— несоответствия требованиям утвержденной «Методики опи­ сания бизнес-процессов».

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

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

На рис. 3.45 показан пример модели, построенной в А1Ш еЕРС, не со­ ответствующей данной нотации.

254 11ро цесси ы й п од ход к у правлены ю. Мо делироваиие бизиес-пр о цес со в Рис. 3.45. Несоответствия модели нотации АИв еЕРС На рис. 3.45 показано несколько видов несоответствий:

— одно событие запускает выполнение двух функций без ис­ пользования логического символа ветвления процесса;

— в одну функцию входит две стрелки;

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

Еще одним примером несоответствий является некорректное наименование объектов моделей. Каждый аналитик должен соблю­ дать правила наименования объектов. При этом очень важно поль­ зоваться глоссарием проекта. На рис. 3.46 приводится пример некор­ ректного наименования объектов.

В варианте 1 есть несколько несоответствий: 1) нельзя давать событию название функции («получить документ А»); 2) если в ме­ тодике принято именовать объекты типа «Подразделение» при по­ мощи сокращений, то название объекта «Финансовый отдел» явля­ ется несоответствием. В варианте 2 событие названо «документ А», что недопустимо. Приводятся произвольно сокращенные названия функции, второго события и подразделения, что является несоот­ ветствием. В варианте 3 несоответствий нет.

Глава 3. Описание и анализ бизнес-процессов Рис. 3.46. Некорректное наименование объектов Таким образом, все модели должны быть проверены на соблю­ дение правил наименования объектов как принятых в нотации, так и сформулированных в «Методике описания бизнес-процессов».

Следующая группа — несоответствия требованиям методики с точки зрения оформления моделей. На рис. 3.47 представлены два варианта моделей. Первая модель выполнена с нарушением требова­ ния, вторая полностью отвечает им.

Рис. 3.47. Несоответствия в оформлении моделей 256 Процессный подход к управлению. Моделирование бизнес-процессов Очень часто на практике аналитики не придают значения требо­ ваниям по оформлению моделей. В результате получаются модели нестандартного вида, которые не только плохо выглядят (вариант 1), но и значительно затрудняют возможности визуального анализа.

Напротив, модели, подготовленные с учетом требований к оформ­ лению (вариант 2), достаточно легко читаются и могут быть исполь­ зованы для документирования и анализа. При построении модели варианта 2 использовано несколько требований:

— построение модели сверху вниз;

— соблюдение стандартных размеров объектов модели;

— выравнивание объектов модели по вертикали и горизонтали.

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

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

3.6.4.Методика проверки адекватности моделей проце Проверка адекватности моделей детальных бизнес-процессов прово­ дится с использованием цикла «автор-читатель», подробно рассмо­ тренного выше.

Существует несколько особенностей проверки адекватности де­ тальных процессов:

— большой объем работы, много итерационных согласований;

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

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

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

1. Введение.

2. Глоссарий терминов.

3. Схемы моделей организационной структуры.

4. Текстовое описание моделей организационной структуры.

5. Схемы вспомогательных моделей.

6. Описание вспомогательных моделей.

7. Схемы моделей бизнес-процессов.

8. Текстовое описание моделей бизнес-процессов.

9. Приложение. Перечень документов.

10. Приложение. Результаты интервьюирования сотрудников.

Целесообразно представлять схемы моделей процессов в виде листов формата А4 (в исключительных случаях — АЗ), содержащих не более 8-12 объектов. При большем количестве объектов схема мо­ дели становится трудно читаемой. Не рекомендуется создавать так называемые склейки, когда схема процесса представлена в виде со­ единенных между собой нескольких листов формата А4.

Более подробно о документировании процессов в случае внедре­ ния процессного подхода к управлению будет сказано в главе 4.

3.6.6. Типовые ошибки выполнения работ по этапу Типовые ошибки выполнения этапа по созданию детальных моделей бизнес-процессов можно сформулировать следующим образом:

258 Процессный подход к управлению. Моделирование бизнес-процессов — ошибки в сроках планирования работ по сбору и обработке — попытки собрать информацию излишне формализованными средствами (обширные опросные листы, таблицы и т. п.);

— нарушения требований нотации и «Методики описания биз­ — неэффективно организованный процесс проверки адекватно­ — отсутствие оперативного контроля деятельности рабочей — простои рабочей группы;

— неполное описание процессов.

Очень часто на практике происходят ошибки в определении сро­ ков планирования работ по проекту, особенно в части работ по сбо­ ру и обработке информации. Трудоемкость таких работ существенно выше, чем у работ по созданию графических схем моделей с исполь­ зованием программных продуктов. Этот факт необходимо учиты­ вать при планировании работ. Кроме того, следует помнить о по­ правочном коэффициенте 2,5-3, необходимом для прогнозирования реальных сроков выполнения работ.

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

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

лава 3. Описание и анализ бизнес-процессов Неэффективно организованный процесс проверки адекватно­ сти приводит к существенному увеличению длительности проекта.

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

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

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

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

3.7. Методики анализа бизнес-процессов В данном разделе будут рассмотрены методики анализа процессов.

Анализ процессов следует понимать в широком смысле: в него вклю­ чается не только работа с графическими схемами, но и анализ всей 260 Процессный подход к управлению. Моделирование бизнес-процессов доступной информации по процессам, измерения их показателей, сравнительный анализ и т. д.

Классификация видов анализа процессов приводится на рис. 3.48.

Методы анализа процессов можно условно разделить на две катего­ рии: качественный и количественный.

Методики качественного анализа процессов основаны на:

— анализе субъективных оценок процесса сотрудниками орга­ низации и внешними специалистами;

— визуальном анализе графических схем процессов;

— сравнении процесса с некоторыми типовыми требованиями.

Рис. 3.48. Классификация видов анализа бизнес-процессов Можно выделить несколько методик субъективной оценки про­ цессов. Во многом такие методики были разработаны в трудах основоположников и последователей методологии реинжиниринга бизнес-процессов, например у Хаммера и Чампи, Робсона и Уллаха и т. д. Кроме того, для качественного анализа процессов могут быть использованы общеизвестные методы анализа: 8ДУОТ-анализ, ана­ лиз при помощи Бостонской матрицы и другие.

Глава 3. Описание и анализ бизнес-процессов Методы графического анализа процессов менее проработаны.

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

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

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

Методы количественного анализа процессов более подробно раз­ работаны в мировой практике. Большая их часть основана на сборе, обработке и анализе статистической информации о процессах. Фак­ тически методы статистического анализа процессов разрабатыва­ лись как инструменты, используемые при внедрении систем менедж­ мента качества [4].

В настоящее время широкое распространение получили такие методы количественного анализа, как имитационное моделирование процессов и АВС-анализ процессов (операционный анализ затрат).

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

Далее будут подробно рассматриваться виды анализа процессов, представленные на рис. 3.48.

3.7.1. БУШ-анализ процесса БАЛЮТ-анализ процесса предполагает выявление его сильных и сла­ бых сторон, возможностей улучшения и угроз ухудшения. В табл. 3. приводится пример БАЛЮТ-анализа процесса.

262 Процессный подход к управлению. Моделирование бизнес-процессов Табл. 3.15. Пример SWOT-анализа процесса Сильные стороны 2. Высокое качество продукции процесса.

3. Наличие квалифицированных кадров.

4. Высокая степень автоматизации 1. Повышение эффективности за счет внедре­ 2. Снижение накладных расходов.

3. Сокращение сроков выполнения заказов Большая зависимость от личностей исполнител за счет дальнейшей автоматизации Б^ЮТ-анализ процесса можно проводить следующим образом:

— провести анкетирование руководителей и специалистов орга­ — обработать результаты анкетирования, оценивая количество сходных по смыслу ответов и формируя рейтинг ответов;

— построить таблицу Б^ЮТ-анализа процесса.

Б^ЛЮТ-анализ — это инструмент для качественной предвари­ тельной оценки процесса. Полученные на его основе данные могут быть использованы в дальнейшем для выяснения причин низкой эффективности процесса и определения характеризующих его по­ казателей.

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

Для выявления проблемных областей следует сформировать укрупненную схему процесса, отобразив на ней основные группы выполняемых функций и их исполнителей. После этого на схеме Глава 3. Описание и анализ биз}1ес-процессов нужно указать проблемные области и дать их краткую характеристи­ ку. На рис. 3.49 приводится пример такой схемы процесса.

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

На рис. 3.49 показаны четыре проблемные области. Первая из них связана с закупкой оборудования, вторая — с привлечени­ ем подрядчиков, третья — с выполнением ремонтов, четвертая — с осуществлением расчетов за выполненные работы и оборудование.

Приводятся краткие формулировки проблем для каждой проблем­ ной области.

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

3.7.3. Ранжирование процессов на основе субъективной оценки Ранжирование процессов выполняется на подготовительной стадии проекта, когда необходимо дать характеристику каждому крупно­ му процессу организации и принять решение, какие из них следует улучшать в первую очередь. Подробно об этой методике можно про­ Существует несколько подходов к ранжированию процессов. Мы рассмотрим простейшую методику. На первом этапе необходимо со­ ставить перечень основных процессов организации. Затем формиру­ ется таблица следующего вида (табл. 3.16):

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

Для каждой организации табл. 3.16 будет заполнена по-разному.

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

Следует отметить, что ранжирование процессов при помо­ щи такой таблицы весьма субъективно. Долгосрочные проекты по улучшению деятельности организации не могут базироваться Глава 3. Описание и анализ бизнес-процессов на использовании подобных методов анализа. Указанный метод обычно применяется при проведении семинаров-тренингов для руководителей, совещаний, мозговых штурмов и подобных меро­ приятий, цель которых состоит в осуществлении быстрого анали­ за ситуации с процессами предприятия на основе качественных показателей.