Подготовка проекта описания бизнес-процессов


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

Практический опыт работ по моделированию процессов показывает, что подготовительный этап проекта очень важен. Результаты его выполнения во многом определяют успех проекта в целом.
Основную работу на подготовительном этапе выполняет руководитель проекта и рабочая группа при активном участии руководителей предприятия.
Длительность подготовительного этапа может составлять от 2 недель до 2 месяцев в зависимости от масштабов проекта и численности организации. Состав работ по подготовке проекта
При подготовке проекта моделирования бизнес-процессов должны быть выполнены следующие работы: диагностика проблем предприятия; определение перечня основных бизнес-процессов; определение и ранжирование целей проекта; выбор (разработка) и утверждение методики ведения проекта, включая методику моделирования бизнес-процессов; подготовка программного и аппаратного обеспечения; формирование рабочих групп; методическая подготовка: обучение руководителей и специалистов предприятия; информирование персонала о задачах проекта; детальное планирование работ.
В зависимости от масштабов проекта часть этих работ может не выполняться. В разделе 3.3 мы рассмотрим некоторые работы из указанного списка.
Последовательность выполнения работ на подготовительном этапе показана на рис. 3. 24.
Работа по проекту начинается с постановочного совещания руководства организации, на котором принимается решение об инициации проекта. На этом совещании должен быть назначен руководитель проекта, а также его куратор со стороны высшего руководства.

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



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

Рабочую группу необходимо обучать принципам и методам моделирования бизнес-процессов и методикам внедрения процессной системы управления. На первом этапе рабочая группа должна пройти двух-трехдневное обучение по этим вопросам. В последующем участникам рабочей группы потребуется пройти еще несколько циклов обучения для овладения инструментальным средством моделирования процессов и практического освоения методик моделирования и анализа процессов. Можно отметить, что рабочая группа вынуждена учиться и выполнять проект одновременно.
Одной из распространенных ошибок является следующая. На должность бизнес-аналитиков принимаются люди, которые никогда не занимались этой работой. Часто это недавние выпускники институтов. Описанием и анализом бизнес-процессов должны заниматься опытные и компетентные люди. Если удалось найти одного-двух таких специалистов, то можно взять еще пару молодых сотрудников. Но ни в коем случае нельзя комплектовать отдел из неподготовленных кадров.
При проверке квалификации и опыта бизнес-аналитиков можно использовать следующий список: Управление организацией: Методы структурного и бесструктурного управления системами. Система глубинных знаний доктора Э. Деминга. Методы стратегического управления (в том числе BSC). Методы разработки бизнес-плана компании. Типы и характеристики организационных структур, методы проектирования и оптимизации организационных структур. Методы построения бизнес-модели компании. Процессный подход к управлению: Принципы процессного подхода. Термины и определения. Метод определения границ процесса (ресурсы, события, операционные определения).
Методы разработки показателей (метрик) для управления процессами. Метод разработки системы (сети, архитектуры) бизнес-процессов компании. Методы и формы регламентации процессов (типовые формы нормативно-методических документов, организация документооборота и т. д.). Принципы и методы оперативного управления процессами (в том числе определение контрольных точек, разработка процедур мониторинга процессов, выполнения корректирующих действий). Метод непрерывного совершенствования процессов на основе цикла PDCA Шухарта — Деминга. Метод нормирования операций процессов и расчета требуемого количества персонала. Моделирование бизнес-процессов: Методы построения структурных моделей процессов. Методы построения схем цепочек создания ценности. Метод построения операционных моделей процессов (Work Flow). Метод построения моделей потоков данных. Нотации IDEFO, IDEF3, IDEF1X, ARIS VAD, ARIS еЕРС, BPMN. Метод сбора и обработки первичной информации (в том числе проведения интервью). Метод управления проектом описания бизнес-процессов. Метод разработки процессов to be на основе требований. Регламентация бизнес-процессов: Структура и формы нормативно-методических документов компании. Процедура управления жизненным циклом нормативнометодических документов.
Разработка регламентов выполнения процессов. Разработка положений о подразделении и должностных инструкций. Аналитические методы: Метод проведения мозгового штурма. Методы построения контрольных карт Шухарта. Методы построения диаграммы Парето и Исикавы. Методы выявления и анализа потерь при выполнении процесса. Методы построения графиков, анализа трендов, расчета корреляции и т. д. Метод QFD. Управление проектами: Методы управления проектами организационного развития. Методы управления инвестиционными проектами. Метод внедрения процессного подхода к управлению. Менеджмент качества: Требования стандартов ИСО 9000. Методы и формы разработки документации СМК. Метод построения и анализа функции потерь Тагути. Информационные системы: Системы для моделирования бизнес-процессов (BPWin, ARIS Toolset, CaseWise, Business Studio и т. д.). ВРМ-системы. ERP-системы (архитектура, принципы работы). Системы электронного документооборота. Разработка требований к информационной системе. Финансы и экономика: Микроэкономика (в том числе маржинальный анализ). Метод построения и анализа финансово-экономических моделей.
Метод анализа и контроля затрат по бизнес-процессам. Методы оценки стоимости компании. Аудит бизнес-процессов: Метод организации системы аудита бизнес-процессов. Метод проведения аудита бизнес-процесса и формирования отчета. Взаимодействие с внешними консультантами: Метод постановки задачи консультантам. Метод контроля качества работ/услуг внешних консультантов. Метод выполнения функции единого заказчика по проектам. Методы управления рисками: Метод выявления и оценки рисков. Метод разработки мероприятий по минимизации рисков. Психология межличностного общения.
На основе общих целей проекта, поставленных руководством предприятия, рабочая группа разрабатывает детальные цели проекта, проводит экспресс-диагностику существующего состояния процессов, подготавливает ТЗ на выполнение работ по проекту.
Для разработки структуры целей, как правило, требуется проведение диагностики состояния тех процессов, которые предстоит улучшать в рамках проекта. Эта диагностика может проводиться различными путями, например при помощи двух-трехдневного выездного семинара, когда руководители и сотрудники подразделений проходят обучение основам процессного подхода и анализируют текущую ситуацию по своим процессам. Диагностику проводят с помощью опроса руководителей и сотрудников подразделений. Общая цель диагностики — выявить проблемные зоны в рамках бизнес-процессов, попытаться получить формулировки существующих проблем.
После того как цели проекта утверждены руководством компании, рабочая группа приступает к методической подготовке проекта.

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


Критерий готовности

Значение

1

Структурированная спецификация целей проекта, 3-5 страниц

Есть. Утверждена

2

Детальное техническое задание, 20-50 страниц

Есть. Утверждено

3

Методика ведения проекта, 80-150 страниц

Есть. Утверждена

4

Календарный план работ, 5-10 страниц

Есть. Утвержден

5

Инструментальная среда моделирования

Выбрана

6

Инфраструктура (помещения, аппаратное обеспечение)

Готовность 30-40%






Критерий готовности

Значение j

7

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

Есть. Утверждены

8

Обучение рабочей группы

Первый цикл выполнен

9

Обучение руководителей верхнего уровня

Первый цикл выполнен

10

Обучение руководителей среднего уровня

Первый цикл выполнен

И

Обучение руководителей и специалистов подразделений

Первый цикл выполнен

12

Информирование персонала

Выполнено

К

проекту можно приступать, когда

получены результаты


табл. 3.4. Далее по ходу проекта не полностью выполненные работы будут закончены.
Далее мы более подробно остановимся на ключевых аспектах подготовки проекта моделирования бизнес-процессов организации. Требования по управлению проектом.
Роли сотрудников в проекте
Требования куправлению проектом моделирования бизнес-процессов соответствуют стандартным требованиям проектного управления [1]. Тем не менее следует отметить ряд специальных требований, предъявляемых к проектам именно такой специфики. Б первую очередь это требования к руководству верхнего уровня. Первое лицо организации должно активно участвовать в проекте. Такое участие означает: мотивацию персонала организации, демонстрирование личной заинтересованности в проекте; участие в постановочных совещаниях рабочей группы; оперативный анализ разрабатываемых материалов; оперативный контроль деятельности руководителей подразделений и рабочей группы; поэтапный контроль выполнения проекта; анализ и перераспределение функций подразделений, ответственности и полномочий руководителей, ресурсов на основе результатов проекта; обеспечение рабочей группы необходимыми ресурсами.

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






Руководитель проекта подчиняется непосредственно руководителю организации. Именно поэтому на схеме он вынесен на один уровень с владельцем процесса — руководителем крупного структурного подразделения. В крупных организациях власть и возможности руководителя проекта несопоставимы с возможностями руководителя крупного подразделения. Поэтому в таких проектах целесообразно вводить роль куратора проекта — руководителя уровня заместителя директора или приближенного к нему советника. В этом случае взаимодействие руководителя проекта с руководителями структурных подразделений осуществляется при участии куратора, что в некоторой степени гарантирует возможность плодотворной коммуникации между руководителем проекта и начальником структурного подразделения, а это способствует успешному выполнению работ по проекту.
Следует отметить, что при формулировке требований к структуре управления проектом необходимо учитывать роль управленческой культуры организации. Если в организации низкая культура, идет напряженная «политическая» борьба, то роль первого лица и его представителя-куратора велика. Для организации с высокой корпоративной культурой и сложившейся командой руководителей верхнего уровня целесообразно максимально упростить схему управления проектом.
Руководитель проекта управляет рабочей группой, состоящей из нескольких аналитиков. Для среднего по масштабам проекта численность рабочей группы составляет пять-семь человек. Количество сотрудников в рабочей группе должно быть оправданно. Для его расчета необходимо понимать, какие работы выполняют участники группы.
В процессе выполнения проекта участники рабочей группы могут играть различные роли: заказчик — руководитель предприятия, владелец процесса; руководитель проекта — сотрудник, ответственный за полноту и корректность описания бизнеса при помощи моделей бизнес-процессов; аналитик — эксперт по моделированию бизнес-процессов, разработчик моделей бизнес-процессов предприятия

в рамках проекта (может быть как сотрудником предприятия, входящим во временную рабочую группу, так и привлеченным консультантом); координатор проекта — сотрудник, обеспечивающий взаимодействие (посредничество) между аналитиком и внутренним экспертом (в небольших проектах функции координатора выполняет руководитель проекта); внутренний эксперт — руководитель или специалист предприятия, являющийся источником информации, необходимой для моделирования бизнес-процессов; рецензент — руководитель/специалист организации либо внешний привлеченный эксперт, являющийся специалистом в предметной области, отвечающий за анализ переданных ему на рассмотрение моделей бизнес-процессов; ответственный за формирование архива — участник рабочей группы, ответственный за сбор, обработку и хранение документации по проекту (одна из основных функций — архивирование подшивок моделей бизнес-процессов, используемых при рецензировании/проверке адекватности).
Далее при описании процессов формирования моделей процессов будут подробно освещены указанные выше роли.
Остановимся на требованиях к квалификации руководителя проекта. Сотрудник организации, претендующий на эту роль, должен удовлетворять следующим требованиям: опыт работы в организации не менее двух-трех лет (предполагается хорошее знание процессов деятельности организации, основ технологий производства); лидерство, умение управлять людьми, коммуникабельность, инициативность, понимание реального положения вещей в организации, принципов построения функциональной иерархии; наличие четкой личной позиции по вопросу процессного подхода к управлению;
знание методик финансового менеджмента; знание и понимание принципов процессного управления и менеджмента качества (TQM, ISO, BPR); владение методиками разработки моделей бизнес-процессов в различных нотациях (обязательно: IDEFO, ARIS еЕРС; желательно BPMN); владение методиками проектного управления; представление о возможностях программных продуктов по моделированию бизнес-процессов; опыт ведения проектов аналогичного масштаба.
Анализируя предложенный выше перечень требований, можно заключить, что найти среди сотрудников предприятия человека, удовлетворяющего этим требованиям, достаточно сложно. На практике у руководителя предприятия остаются две возможности: либо перекупать руководителя проекта со стороны, либо «выращивать» собственного.
Руководитель проекта должен иметь четкую личную позицию по вопросу процессного управления и целей описания бизнес- процессов. Он должен понимать основные принципы управления процессами, знать о лучшем мировом опыте по этому вопросу. Он должен быть инициативным, генерирующим идеи, но в то же время уметь четко ставить задачу и контролировать ее выполнение.
Отметим несколько моментов, важных при управлении рабочей группой: оперативный контроль деятельности аналитиков; ежедневные совещания (10-15 минут) перед началом рабочего дня; еженедельные письменные отчеты аналитиков по использованию рабочего времени и выполненной работе; ежемесячные расширенные совещания рабочей группы с подведением итогов работы; плановые совещания по обсуждению моделей бизнес-процессов, анализу и разработке рекомендаций.

Четкий, оперативный контроль деятельности рабочей группы необходим. В противном случае группа может либо заняться второстепенной деятельностью, либо сформировать некачественные, несоответствующие материалы. Создание и обучение рабочих групп
Рабочая группа (рабочая команда) формируется из сотрудников организации. Принцип формирования группы иллюстрирует рис. 3.26.
Рис. 3.26. Формирование рабочей группы
БИЗНЕС-ПРОЦЕСС
lt;)|Лел ? к [ ОгделЗЬ [ Отдел 4              |
•жввяЛ «ийквшаР ЧпнвмааР
-|| Сотрудник |—| Сотрудник


Сотрудник
СДТГруДТТРПх —|              ситрудгттгтг


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


Критерий отбора

Вес

ваиов И. И.

. Петров А. П.

ОидоровВ. А.

1

Желание работать в проекте и улучшать деятельность организации

1

10

5

2
/>2
Опыт работы в организации не менее трехлет

0,6

2

5

10

3

Знание и понимание задач своего подразделения и выполняемых функций

1

6

8

6

4

Авторитет в коллективе, высокая ценность сотрудника для подразделения

1

10

8

9

5

Возможность быстрого обучения, возможность творческой работы

0,5

6

6

5

6

Коммуникабельность

0,5

6

6

6

7

Инициативность

0,4

6

5

2

8

Навыки работы с персональным компьютером

0,2

4

6

0








Итоговая оценка


4,55

4,15

3,66


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

руководителем подразделения, и личных собеседований с сотрудниками. Данная таблица поможет при принятии решения, приглашать ли сотрудника в рабочую группу.
Должен быть совершенно исключен принцип подбора сотрудников по остаточному принципу, то есть когда ценность сотрудника для подразделения незначительна.
Плохим примером подбора кадров является включение в группу молодых специалистов, то есть сотрудников без опыта реальной работы и знания специфики деятельности подразделения.
Очевидно, что подбор сотрудников в группу должен осуществляться с учетом мнений и пожеланий руководителей подразделений.
Если существующая в организации кадровая служба имеет в своих рядах штатного психолога, то следует обратиться к нему за профессиональной помощью при создании рабочей группы.
Сформированная рабочая группа должна получить достаточный набор знаний по следующим темам: принципы и методы управления процессами (идеология процессного управления); методы измерения эффективности и качества процессов; методы описания и регламентации бизнес-процессов; инструментарий моделирования бизнес-процессов; основы проектного управления.
Обучение по этим темам целесообразно проводить в течение трех семинаров-тренингов: первый — по темам 1-2, второй — по теме 3, третий — по теме 4. Примерная программа обучения приводится в табл. 3.6.
Кроме указанной программы обучения, сотрудники должны самостоятельно ознакомиться с рядом работ по теме управления процессами.
Дальнейшее обучение рабочей группы продолжается при выполнении конкретной работы по проекту, а именно:
•— диагностики существующих процессов; структуризации дерева целей проекта;
разработки ТЗ; разработки методики выполнения проекта; обучения руководителей и сотрудников подразделений.
Табл. 3.6. Типовая программа обучения сотрудников рабочей группы


Наименование темы

Состав волрасов |

1

Принципы и методы управления процессами
Классификация процессов организации. Философия процессного управления (Деминг, Джуран, Кросби и др.). Принципы управления процессами. Цикл PDCA. Методика внедрения процессного управления организацией. Разработка документации, регламентирующей управление процессами

2

Методы измерения эффективности и качества процессов
Базовые методы измерения эффективности и качества процессов. Требования стандарта ИСО 9001:2008. Примеры построения систем измерения показателей процессов

3

Методы описания и регламентации бизнес-процессов
Стандарты моделирования бизнес-процессов (IDEF0, ARIS еЕРС, BPMN). Моделирование процессов при помощи среды Business Studio. Комплексная методика ведения проекта моделирования бизнес-процессов. Методики анализа и реорганизации бизнес-процессов. Примеры построения моделей бизнес-процессов. Разработка регламентирующих документов на основе моделей бизнес-процессов. Пример: автоматическая выгрузка регламентов выполнения процессов из Business Studio на основе шаблонов отчетов

4

Инструментарий моделирования бизнес-процессов (ARIS, Casewise, Business Studio и т. д.)
Обзор рынка инструментальных средств моделирования бизнес-процессов. Моделирование процессов в системе ARIS. Моделирование процессов в системе Casew'se. Моделирование процессов в системе Business Studio. Сравнительный анализ эффективности применения различных программных продуктов. Использование инструментальных средств в проекте

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

Руководители компании должны учиться не менее 30-40 часов в году. Специалисты и рабочие также должны повышать свой уровень. Почему мы настаиваем на необходимости обучения? Дело в том, что внедрение процессного подхода к управлению и системы менеджмента качества даст реальные результаты только в случае активного участия персонала организации в работе по улучшению процессов. Для выполнения такой работы мало одного желания — нужны специальные знания, методики. Обучая персонал, руководитель компании формирует определенную корпоративную культуру. Без высокой культуры получать высокие экономические результаты и быть конкурентоспособным в длительной перспективе невозможно.
Как обучать персонал для его подготовки к проекту внедрения процессного управления? В табл. 3.7 показаны темы обучения и примерный объем времени в зависимости от уровня сотрудников.
Указанное в таблице количество часов относится к первой, подготовительной фазе проекта. В дальнейшем потребуется дополнительное обучение в виде тренингов, основанных на фактическом материале организации.
Как видно из табл. 3.7, руководители среднего звена и специалисты учатся больше всех остальных. Дело в том, что именно на них приходится основная нагрузка при выполнении проекта.
Приступать к обучению следует после информирования персонала организации о проекте, его целях, влиянии полученных результатов на деятельность организации, роли каждого ее сотрудника в проекте. Информирование персонала может проводиться различными средствами.
В первую очередь к ним относятся: распорядительные документы руководства организации; совещания для руководителей подразделений; совещания для сотрудников подразделений; информирование через стенгазеты и корпоративную сеть (или интранет); информирование при проведении обучения.

Табл. 3.7. Обучение персонала организации


Уровень

Ti ¦gt; атика обучения

Кол-во i над.часов

1

Руководители верхнего уровня (заместители директора, начальники управлений)
Философия процессного управления (Деминг, Джуран, Кросби и др.). Принципы управления процессами. Цикл PDCA. Методика внедрения процессного управления организацией и системы менеджмента качества. Основы методик моделирования бизнес- процессов. Методика ведения проекта моделирования бизнес-процессов. Обзор рынка инструментальных средств моделирования бизнес-процессов
16

2

Руководители среднего уровня (начальники подразделений) и специалисты (экономисты, ИТР и т. д.)
Философия процессного управления (Деминг, Джуран, Кросби и др.). Принципы управления процессами. Цикл PDCA. Методика внедрения процессного управления организацией и системы менеджмента качества. Разработка документации, регламентирующей управление процессами. Основы методик моделирования бизнес- процессов. Методика ведения проекта моделирования бизнес-процессов. Базовые методы измерения эффективности и качества процессов. Требования стандартов ИСО 9000. Примеры построения систем измерения показателей процессов. Обзор рынка инструментальных средств моделирования бизнес-процессов
24

3

Мастера и рабочие
Методика внедрения процессного управления организацией и системы менеджмента качества. Базовые методы измерения эффективности и качества процессов. Примеры построения систем измерения показателей процессов
8


На рис. 3.27 представлена возможная последовательность действий, необходимых для информирования и обучения персонала.
Основная цель информирования персонала состоит в создании благоприятной внутренней атмосферы в организации. Сотрудники должны быть уверены в том, что результатом проекта станет улучшение деятельности организации в целом и условий труда каждого в частности. У сотрудников не должно создаваться впечатления, что проект ориентирован на сокращение численности персонала и ужесточение условий работы. В действительности в результате проекта будут, конечно, выявлены сотрудники либо не соответствующие
занимаемым должностям, либо не загруженные реальной работой. Эти кадры будут обучать, отделы — реорганизовывать, упразднять и т. д. Но это будет происходить плавно, в длительной (полтора-два года) перспективе и поэтому не должно негативно отразиться на материальном положении сотрудников.
Рис. 3.27. Информирование и обучение персонала




Принято решение о начале реализации проекта



alt="" />Рассылка ->* информации по e-mail



Оперативное информирование о ходе проекта и его результатах
Отметим, что обучение руководителей верхнего уровня целесообразно проводить до утверждения целей и ТЗ проекта. Полезно, когда руководители проходят обучение еще до принятия решения о начале проекта. В этом случае у них есть возможность корректнее сформулировать его цели.
Информирование персонала необходимо оперативно осуществлять и по ходу проекта. Важно доносить до людей данные о его успехах, причем в конкретной и простой форме.
К сожалению, на практике распространена следующая ситуация. Формально объявляется начало проекта. Рабочая группа приступает к сбору информации в отделах. Большинство сотрудников не представляют себе, для чего все это делается. В организации возникают и распространяются различные слухи негативного характера. Постепенно складывается
атмосфера недоверия к проекту. Возникает скрытое сопротивление деятельности рабочей группы. Людям свойственно бояться всего нового, незнакомого, способного повлиять на их более или менее устойчивое положение в организации. В результате формируется оппозиционное отношение большинства сотрудников к проекту, которое переломить очень трудно. Заметим, что целесообразно среди участников рабочей группы выделить отдельных сотрудников, ответственных за оперативное освещение хода и результатов проекта внутри организации. Разработка методики ведения проекта и внутрикорпоративного стандарта моделирования бизнес-процессов
Для успешного выполнения проекта все участники должны понимать, что, как и для чего делать. Вопрос «для чего делать?» разрешается на первом этапе, когда руководство определяет цели проекта.
Рабочей группе необходимо четко понимать всю последовательность шагов по выполнению проекта — ответ на вопрос «что делать?». Однако знать перечень шагов, ведущих к цели, недостаточно. Важно понимать, «как делать», то есть иметь в распоряжении методики выполнения соответствующих работ. Для того чтобы дать рабочей группе инструмент для практического выполнения проекта, создается методика ведения проекта, оформляемая в виде отдельного документа.
Структура методики проста. На рис. 3.28 представлены ее основные компоненты.
Сначала в документе приводится описание целей проекта, затем укрупненное описание состава работ. Далее в методике последовательно описываются все основные этапы работ. Для каждого этапа дается детальное описание состава работ с указанием исполнителей и ответственных. Кроме того, для каждого этапа приводится описание методик выполнения работ. В приложения к методике выносятся формы документов, используемых в проекте.

Рис. 3.28. Структура методики ведения проекта

Описание целей проекта
I
Ў

Укрупнённое; описание состава и по едо ьно работ («что делать»)

Г


Этап-

Описание методик выполнения работ («как делать»)
Приложения ( opr доку е о приказов и т.п.)
Методика может быть оформлена в виде одного или нескольких документов, которые включают в себя следующие разделы: Цели проекта. Управление проектом. Структура управления проектом. Описание процесса выполнения работ (основные этапы). График Ганта (основные этапы). Документы, регламентирующие управление проектом. Порядок взаимодействия сотрудников в проекте. Порядок формирования/расформирования рабочих групп. Описание этапов выполнения проекта. Этап 1. Подготовка проекта. Описание процесса выполнения работ (сетевой график с разбивкой по исполнителям).
График Ганта (с разбивкой по исполнителям). Методики выполнения работ по этапу 1. Методика разработки структурированных целей проекта. Методика разработки технического задания. Методика обучения руководителей и специалистов организации процессному подходу. Требования к результатам работ по этапу 1. Требования к отчетности по этапу 1. Этап 2. Формирование моделей бизнес-процессов. Описание процесса выполнения работ (сетевой график с разбивкой по исполнителям). График Ганта (с разбивкой по исполнителям). Методики выполнения работ по этапу 2. Методика сбора информации в подразделениях. Методика формирования моделей бизнес-процессов верхнего уровня. Методика проверки корректности полученной в подразделениях информации. Методика формирования детальных моделей процессов (декомпозиции) на основе полученной информации. Методика проверки корректности формируемых моделей процессов (с точки зрения нотации). Методика проверки адекватности моделей процессов (цикл «автор — читатель»), Методика работы с инструментальной средой моделирования. Требования к создаваемым моделям бизнес-процессов.
Требования к настройке инструментальной среды моделирования. Требования к результатам работ по этапу 2. Требования к отчетности по этапу 2. Этап 3. Анализ процессов. Разработка регламентирующих
документов. Описание процесса выполнения работ (сетевой график с разбивкой по исполнителям). График Ганта (с разбивкой по исполнителям). Методики выполнения работ по этапу 3. Методика разработки документов по процессам и подразделениям. Методика разработки и измерения: а) показателей эффективности процессов; б) показателей продуктов; в) показателей удовлетворенности клиентов процесса. Требования к документации по процессам и подразделениям. Требования к результатам работ по этапу 3. Требования к отчетности по этапу 3. Этап 4. Реорганизация бизнес-процессов. Переход к процессной системе управления. Описание процесса выполнения работ (сетевой график с разбивкой по исполнителям). График Ганта (с разбивкой по исполнителям). Методики выполнения работ по этапу 4. Методика организации управления процессами (см. главу 4). Методика технико-экономического обоснования мероприятий по реорганизации бизнес-процессов.
Требования к оформлению предложений реорганизации бизнес-процессов. Требования к результатам работ по этапу 4. Требования к отчетности по этапу 4. Глоссарий проекта. Термины предметной области. Термины системы процессного управления. Допустимые в организации сокращения. Приложение № 1. Формы для сбора и хранения информации. Ф-И01 «Анкета аналитика». Ф-И02 «Анкета сотрудника подразделения». Ф-ИОЗ «Подшивка моделей процессов». Ф-И04 «Репозитарий документов проекта». Приложение № 2. Корпоративный стандарт «Регламент описания бизнес-процесса». Приложение № 3. Корпоративные стандарты. Формы документов. Ф-П02 «Положение о подразделении». Ф-ПОЗ «Должностная инструкция». Ф-П04 «Рабочая инструкция». Приложение № 4. Формы отчетных документов рабочей группы. Ф-ОД-1 «Протокол совещания рабочей группы». Ф-ОД-1 «Отчет рабочей группы за неделю». Ф-ОД-2 «Отчет по этапу». Ф-ОД-3 «Отчет по анализу бизнес-процесса». Приложение № 5. Положение о рабочей группе. Приложение № 6. Положение о мотивации рабочей группы и привлеченных сотрудниках подразделений. Приложение № 7. Программа обучения руководителей и специалистов организации.

Описание состава и последовательности работ (процесса) и ответственных может приводиться в различном формате: табличное представление; представление в виде сетевого графика; представление в виде схемы бизнес-процессов выполнения работ (например, в виде блок-схемы).
Дополнительно к описанию состава и последовательности работ используется представление в виде графиков Ганта, поскольку они удобны для детального описания выполняемых работ в заданном масштабе времени (например, неделя).
Приведенная нами структура методики является основой для создания рабочего документа в организации. Отметим, что эта структура меняется в зависимости от целей, состава работ и применяемых методик. Не может быть одной, универсальной методики, подходящей на все случаи жизни. Каждая организация разрабатывает такой документ для себя.
Остановимся подробнее на внутрикорпоративном стандарте описания бизнес-процессов. Для успешного ведения проекта как руководители предприятия, так и участники рабочей группы должны четко представлять себе, что же именно подразумевается в организации под термином «бизнес-процесс», что значит «описать бизнес-процесс» и т. д. Для того чтобы все говорили на одном языке и понимали суть произносимых понятий, в организации должен быть разработан внутрикорпоративный стандарт описания бизнес-процесса.
Одно из приложений «Методики ведения проекта» называется «Регламент описания бизнес-процесса». Именно этот документ является основой внутрикорпоративного стандарта описания и служит для нескольких целей: дает определение бизнес-процесса; регламентирует параметры процесса, по которым он идентифицируется в организации; регламентирует порядок описания бизнес-процесса (включая требования к графическим схемам процессов, реализованным в выбранной нотации);
регламентирует порядок управления бизнес-процессом; регламентирует порядок улучшения бизнес-процесса; дает ссылки на другие документы, необходимые для регламентации работ по процессу (положения, инструкции, методики).
Подробно структура документа будет описана в главе 4 при обсуждении процессного подхода к управлению.
Важно подчеркнуть, что корпоративный стандарт для описания процесса — это не свод правил рисования схем бизнес-процессов, как это часто неправильно понимают. Это не адаптированное описание нотаций моделирования (ARIS, IDEF и т. п.). Корпоративный стандарт описывает бизнес-процесс как объект для управления и совершенствования. Вопрос графического представления процесса включается в стандарт как важная, но не основная часть.
При разработке методики рабочая группа должна определить наиболее подходящее средство описания бизнес-процесса в виде схем какого-либо вида. В зависимости от целей проекта могут использоваться различные нотации: IDEF, DFD, ARIS, блок-схемы и т. д. Если проект предполагает описание процессов сверху вниз, то целесообразно использовать несколько нотаций для разработки схем процессов (см. рекомендации в главе 3). Вполне возможен вариант, когда рабочая группа разрабатывает собственную нотацию описания процесса, базируясь на знании существующих мировых стандартов и лучшего практического опыта.
Когда выбрана конкретная нотация моделирования процессов, должна быть составлена методика описания процессов организации с использованием данной нотации. Этот документ либо включается в корпоративный стандарт «Регламент описания бизнес-процесса», либо существует как отдельное «Методическое руководство по формированию схем процессов», либо включается в раздел «Методики ведения проекта» под названием «Требование к моделям бизнес- процессов». Важно не название этого документа, а его наличие и возможность практического использования сотрудниками организации. На практике случалось, что некоторые методические документы, разработанные рабочими группами (с участием консультантов),
были настолько сложными и запутанными, что совершенно не могли применяться рядовыми сотрудниками в качестве руководства к действию. Документы должны по возможности носить характер простых и понятных инструкций.
Разработанный документ содержит порядок описания процесса и требования к формату представления его графических схем. Кроме того, при разработке порядка описания процессов следует учесть требования инструментальной среды моделирования, которая будет использована в проекте. Например, для системы ARIS простейший перечень требований может выглядеть следующим образом: Структура базы данных ARIS. Количество, права, логины и пароли пользователей, включая системного администратора. Используемые типы моделей, порядок нумерации моделей, в том числе при декомпозиции. Используемые в рамках моделей типы объектов и связей между ними (с примерами), порядок нумерации объектов. Таблица соответствия объектов модели и реальных объектов (документы, файлы, устные распоряжения, звонки, прикладные системы, функции, средства автоматизации, оборудование). В таблице соответствия приводятся графический вид объекта в цвете и его текстовое описание. Таблица с описанием типов связей между объектами моделей. В таблице приводятся графический вид связи, ее текстовое описание. Требования к форматированию моделей (привязка к сетке, выравнивание объектов, цвета и размер объектов, размер и тип шрифтов для объектов моделей и атрибутов) с примерами. Требования к используемым типам атрибутам объектов и порядку их заполнения (используемые атрибуты должны обеспечивать возможность анализа бизнес-процессов по согласованным с заказчиком критериям). Описание и тексты скриптов, предназначенных для вывода отчетов в табличной форме.

В заключение подраздела подчеркнем, что создаваемая в рамках проекта документация не должна дублировать уже существующие в организации документы (например, по системе менеджмента качества). Важно создавать единую систему документации, которая служит нескольким задачам системы управления организацией. Технические аспекты подготовки проекта
К техническим аспектам подготовки проекта относятся следующие: выбор инструментального средства моделирования бизнес- процессов; приобретение и инсталляция программного обеспечения; создание инфраструктуры проекта.
В настоящее время на рынке представлено множество различных программных продуктов, поддерживающих работы по моделированию бизнес-процессов. К числу популярных продуктов относится, например, система Business Studio. Многие компании используют инструментальную среду ARIS Toolset. Есть и другие системы, которые относятся к разряду CASE-систем. CASE-системы в первую очередь ориентированы на разработку систем автоматизации компаний, в том числе на создание моделей потоков информации (DFD), моделей структуры данных, настройку СУБД. Для создания моделей бизнес-процессов они подходят в меньшей степени.
Выбор программного обеспечения должен основываться на технико-экономическом обосновании использования продукта, при этом следует учесть все этапы его жизненного цикла (например, по ГОСТ Р ИСО/МЭК 12207-99) в проекте.
Характерная черта проекта моделирования бизнес-процессов — это одновременная работа нескольких аналитиков. В крупных проектах создавать модели процессов могут сразу около 10-12 сотрудников, в небольших проектах — 2-3. Когда в описании процессов участвует более одного человека, возникают проблемы координации работ, стыковки разрабатываемых частей модели процесса и т. д. Если программный продукт не поддерживает возможность ведения единой базы данных моделей процессов и одновременной
работы нескольких исполнителей, то возникнут значительные сложности по обеспечению связности и качества создаваемых моделей процессов. В какой-то степени влияние указанных проблем можно уменьшить за счет наличия корпоративного стандарта на описание процессов и искусства руководителя проекта, но полностью они устранены быть не могут. В то же время практика показывает, что наличие программного обеспечения с единой базой данных и многопользовательским режимом (Business Studio — характерный пример) не всегда обеспечивает построение качественного комплекта моделей. Вопрос должен решаться комплексно.
Вторым важнейшим аспектом технической подготовки проекта является создание необходимой инфраструктуры. Опыт показывает, что для эффективной деятельности рабочая группа должна иметь отдельное помещение. В нем организуются рабочие места аналитиков, оснащенные персональными компьютерами, подключенными к интранету. Обязательные элементы оснащения — телефон, копировальный аппарат, цветной и черно-белый принтер, проектор для проведения презентаций. Для проведения совещаний рабочая группа должна иметь доступ в конференц-зал или другое подходящее помещение. Ошибки выполнения подготовительного этапа проекта
В заключение раздела, посвященного описанию подготовительного этапа, остановимся на типовых ошибках его выполнения. К их числу следует отнести: неадекватное участие руководства в проекте; плохо проработанные цели и ТЗ; некорректно сформированная рабочая группа; плохо проработанная «Методика ведения проекта»; некачественно проведенное обучение сотрудников; неадекватное освещение проекта среди сотрудников организации.
Все указанные выше ошибки приводят к следующей ситуации. Работу по проекту начнет выполнять рабочая группа, состоящая
из второстепенных, неквалифицированных, имеющих незначительный опыт сотрудников. Эта группа не будет иметь четких целей и понимать, куда двигаться. Руководство компании не будет оказывать поддержку рабочей группе. Отсутствие методик приведет к многократной переделке схем процессов без значительных улучшений. Сотрудники компании начнут оказывать скрытое сопротивление деятельности рабочей группы и т. д. В результате через два-три месяца работы руководство получит комплект моделей, который не сможет прочитать. Попытки анализа информации вызовут у руководства сильное раздражение. Итогом станет прекращение проекта и, возможно, увольнение части сотрудников, входивших в рабочую группу. Чтобы избежать такого печального исхода событий, следует максимально привлекать руководство к участию в проекте, готовить качественные методические материалы, приобщать к проекту лучших людей организации и т. д. Методика формирования моделей процессов верхнего уровня
Создание моделей бизнес-процессов верхнего уровня является важнейшей задачей, которую выполняет рабочая группа на втором этапе проекта.
Для чего нужны схемы процессов верхнего уровня? Нельзя ли сразу приступить к описанию детальных бизнес-процессов, используя нотацию типа Work Flow? Ответы на эти вопросы достаточно просты. В рамках комплексного подхода к описанию процессов организация рассматривается как сложная система. Ее устройство проще понять, начиная описание ее процессов сверху, укрупненно. Попытки сразу перейти на детальный уровень описания на практике не приводили к успеху. Можно выделить несколько целей описания бизнес-процессов верхнего уровня организации: понимание основ деятельности организации; увязка результатов деятельности (выходов) и процессов, определение границ процессов;
определение проблемных областей при выполнении процессов; подготовка фронта работ для детального описания процессов.
Выполнив описание процессов верхнего уровня, рабочая группа получает комплексное представление о деятельности организации, которое составляет основу для дальнейшей детализации моделей процессов. Отметим, что до начала работ с таблицами, приводимыми далее, целесообразно составить простейшие эскизы процессов верхнего уровня, общаясь с руководителями организации. Эти эскизы позволят быстрее и точнее сформировать таблицы, определяющие процессы организации.
Насколько точно можно выделить в организации процессы верхнего уровня? Вообще четкое определение границ процессов возможно только после детального анализа потоков информации и материальных ресурсов, пересекающих границы функциональных подразделений. Вся деятельность организации — это процесс. В каких местах разделить эту деятельность на отдельные бизнес-процессы? Это непростой вопрос. Еще одна проблема, которую нужно рассмотреть, — это определение владельца процесса — руководителя, обладающего ресурсами и имеющего реальную власть.
В начале главы 3 была описана методология ускоренного моделирования бизнес-процессов организации. Согласно ей, первый шаг построения моделей — определение внешних входов и выходов организации, как показано на рис. 3.29. Какие входы и выходы должна выделить рабочая группа? В первую очередь те, которые связаны с основной деятельностью организации. В табл. 3.8 приводится пример выделения входов и выходов организации.
Определив перечень входов/выходов, рабочая группа формирует предварительный перечень бизнес-процессов верхнего уровня, причем основных. Основные процессы создают ценность для потребителей, их выходы — это продукция, поставляемая основным клиентам организации. Второй критерий выделения основных процессов — взаимодействие с внешней средой организации. Составив перечень
основных бизнес-процессов, рабочая группа формирует следующие таблицы (табл. 3.9-3.10).
Рис. 3.29. Определение входов и выходов процесса

Внешние входы              Внешние              выходы


Табл. 3.8. Пример выделения входов/выходов организации

¦ '                             —

Наименование 1 Описание

Процесс*

Входы

1

Основное сырье и материалы


Производство

2

Заявки клиентов


Сбыт





Выходы

1

Готовая продукция А


9**

2

Готовая продукция Б


9**





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


Табл. 3.9. Перечень основных процессов

«в

              . ...
Наименование процесса

1

Сбыт готовой продукции

2

Производство продукции

3

Снабжение




Табл. 3.10. Входы/выходы основного процесса


Наименование входа/выхода процесса «Производство»

Входы процесса

Внешние входы





Внутренние входы

1

Заявка на производство (из процесса «Сбыт»)

2

Основное сырье (из процесса«Снабжение»)

3

Вспомогательные материалы (из процесса«Снабжение)



Выходы процесса

Внешние выходы





Внутренние выходы
/>1
Готовая продукция (на склад ГП, вход процесса «Сбыт»)

2

Сертификат соответствия на ГП (вход процесса «Сбыт»)




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

Следует отметить, что работа по выделению процессов верхнего уровня выполняется рабочей группой итерационно. Иногда требуется два-три раза пересмотреть полученные таблицы, пока не будет получен адекватный результат. Формы таблиц могут быть изменены рабочей группой, с тем чтобы привести их к более удобному виду в условиях конкретного проекта.
На рис. 3.30 представлен результат определения процессов верхнего уровня: показаны основные и вспомогательные процессы и входы/выходы.
Рис. 3.30. Увязка основных и вспомогательных процессов



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

N8

Наименование функций процесса «Производство»


1

Разрабатывать график ремонтов

2

Формировать производственную программу

3

Осуществлять подготовку производства




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

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






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

Рис. 3.32. Пример процесса верхнего уровня. Процесс «закупки»



Представление типового процесса «закупки» на верхнем уровне приводится на рис. 3.33. Процесс сформирован при помощи нотации ARIS Value-added Chain Diagram. Приведенный на рис. 3.33 процесс описан в нотации VAD ARIS.
По сути, это простейшая схема процесса, в которой входящие и исходящие потоки отображаются четырехугольными графическими объектами. Процесс состоит из пяти основных групп функций: Функции планирования закупок ТМЦ (товарно-материальных ценностей). Функции формирования заказов на ТМЦ. Функции получения, хранения и отпуска ТМЦ в производство. Функции оплаты ТМЦ и контроля дебиторской задолженности. Функции бухгалтерского учета операций по закупкам ТМЦ.





Обратные связи показаны на схеме процесса при помощи входящих и исходящих объектов. Например, функция «Получать, хранить и отпускать ТМЦ» имеет выход под названием «Данные по состоянию склада и движению ТМЦ», который является входом функции «Планировать закупки ТМЦ». На приведенной схеме можно найти и другие обратные связи. Информационные и материальные потоки показаны на схеме процесса «Закупка» в укрупненном виде. При последующей декомпозиции на более детальные процессы эти потоки также будут рассматриваться более подробно.
Тот же самый процесс, но разработанный в нотации IDEF0, представлен на следующем рис. 3.34. Этот процесс будет подробно рассмотрен в главе 4 при описании цикла PDCA. Таким образом, при формировании процесса верхнего уровня очень важно отобразить основные типы потоков и существующие обратные связи. Если схема процесса верхнего уровня сформирована корректно, то существенно облегчается задача последующей декомпозиции процессов.
Какую нотацию использовать для описания процессов верхнего уровня? На наш взгляд, вполне можно обойтись простейшими средствами рисования блок-схем, такими как MS Word или Visio. Если использовать более серьезные инструменты, то это будет, безусловно, стандарт IDEF0 (см. главу 2).
В данном разделе внимание в основном уделено формированию именно схем процессов верхнего уровня. Это сделано из-за того, что на многих предприятиях руководители требуют как первый результат проекта именно эти схемы. Подчеркнем еще раз, что в нашем понимании понятие процесса гораздо шире. Определить процесс — не значит нарисовать его графическую схему. Об этом уже говорилось выше. Глава 4 целиком посвящается определению процессов как объектов управления. В данной главе акцент сделан на формировании графических схем бизнес-процессов.
После того как схемы процессов верхнего уровня сформированы, они должны быть проверены на соответствие реальной ситуации. Это мы будем называть проверкой адекватности. Существует методика проверки адекватности бизнес-процессов, которая рассмотрена в следующем разделе.

N3
INJ
00

alt="" />
<< | >>
Источник: Репин В. В., Елиферов В. Г.. Процессный подход к управлению. Моделирование бизнес-процессов. 2013

Еще по теме Подготовка проекта описания бизнес-процессов:

  1. ОПИСАНИЕ БИЗНЕС-ПРОЕКТА 1.1.
  2. Глава 3 Описание и анализ бизнес-процессов
  3. Методологии описания бизнес-процессов
  4. Глава 2 Выбор методологии описания бизнес-процессов
  5. Постановка целей описания бизнес-процессов
  6. Методика детального описания бизнес-процессов
  7. Выбор методологии описания бизнес-процессов организации
  8. Глава 5 Описание бизнес-процессов при внедрении системы менеджмента качества по требованиям ИСО 9001:2000
  9. Причины неудач проектов моделирования и реорганизации бизнес-процессов
  10. Состав этапов типового проекта моделирования и реорганизации бизнес-процессов организации
  11. Фишер Лэйна. . «Совершенство на практике. Лучшие проекты в области управления бизнес-процессами и workflow». Пер с англ. «Весть- Метатехнология». - 432 с., 2000
  12. Образование и подготовка. Что должен знать и уметь бизнес-тренер? Как использовать имеющиеся образование и подготовку?
  13. § 5.2. Подготовка информации для оценки эффективности проекта Подготовка исходной информации
  14. Описание конкретных работ по проекту
  15. Структура описания проекта
  16. Краткое описание проекта
  17. Краткое описание проекта
  18. Статистическое описание характеристик проекта
  19. Описание бизнеса ресселера
- Cвязи с общественностью - PR - Бренд-маркетинг - Деловая коммуникация - Деловое общение и этикет - Делопроизводство - Интернет - маркетинг - Информационные технологии - Консалтинг - Контроллинг - Корпоративное управление - Культура организации - Лидерство - Литература по маркетингу - Логистика - Маркетинг в бизнесе - Маркетинг в отраслях - Маркетинг на предприятии - Маркетинговые коммуникации - Международный маркетинг - Менеджмент - Менеджмент организации - Менеджмент руководителей - Моделирование бизнес-процессов - Мотивация - Организационное поведение - Основы маркетинга - Производственный менеджмент - Реклама - Сбалансированная система показателей - Сетевой маркетинг - Стратегический менеджмент - Тайм-менеджмент - Телекоммуникации - Теория организации - Товароведение и экспертиза товаров - Управление бизнес-процессами - Управление знаниями - Управление инновационными проектами - Управление качеством товара - Управление персоналом - Управление продажами - Управление проектами - Управленческие решения -