ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.02.2024
Просмотров: 80
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Разрабатывать модели процессов верхнего уровня рекомендуется путем определения и описания схем цепочек создания ценности, в которых участвует организация.
Как правило, при помощи структурной модели процессов верхнего уровня удается получить информацию о возможном перечне процесс- ных категорий и групп, то есть создать основу процессного дерева. Пример. Рассмотрим схему процессов верхнего уровня телекоммуникационной компании, представленную на рис. 3.5.1. На рисунке показана схема цепочки создания ценности по одной из основных ее услуг. При разработке схемы были описаны процессы по пяти основным категориям (на рис. 3.5.1 обведены рамками, которые условно назвали так:
«Продавать услуги. Настраивать сервисы для клиента. Осуществлять текущее обслуживание клиентов.
* Схема выполнена в нотации, разработанной компанией ФИНЭКСПЕРТ.РУ в период с 2007 по 2008 год
Небольшая организация (10–100 человек)
Возможные цели описания процессов (моделирования) в небольшой организации:
Четкое определение зон ответственности руководителей
1. по ключевым направлениям деятельности.
Описание деятельности в формализованном виде для регламентации ключевых процессов организации сбыт, закупки, бюджетирование, управление проектами и т. д. Использование описаний процессов при создании документов инструкции по выполнению процессов, положения о взаимодействии.
Анализ и улучшение деятельности. Подготовка к автоматизации деятельности, в том числе про. цессов.
Первые шаги по созданию культуры процессного управления
5. у сотрудников (обучение процессному ви´дению).
Средняя организация (100–1000 человек)
Возможные цели описания процессов (моделирования) в организации среднего размера:
Четкое определение зон ответственности руководителей
1. на всех уровнях управления.
Оптимизация взаимодействия структурных подразделений
2. за счет стыковки процессов по входам/выходам.
Системное описание процессов в формализованном виде.
3. Централизованное хранение и актуализация моделей процессов. Постоянное использование моделей процессов для регламентации регламенты выполнения процессов, инструкции по выполнению процессов, положения о взаимодействии и т. д
212
Бизнес-процессы. Моделирование, внедрение, управление
Тиражирование стандартов деятельности (например, в фи. лиалы).
Обучение сотрудников. Автоматизация процессов. Анализ и улучшение деятельности. Развитие культуры процессного управления у сотрудников. Крупная организация (> 1000 человек)
Возможные цели описания процессов (моделирования) в крупной организации:
Четкое определение зон ответственности руководителей
1. на всех уровнях.
Оптимизация взаимодействия структурных подразделений
2. за счет стыковки процессов по входам/выходам.
Создание системы процессов организации. Системное описание процессов в формализованном виде на нескольких уровнях (создание так называемой объектной модели организации. Централизованное хранение (в промышленной базе данных) и актуализация моделей процессов.
Автоматизация создания регламентирующих документов (при
4. помощи выгрузки из среды моделирования на основе стандартных шаблонов. Формирование нормативно-методических документов регламенты выполнения процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции. Формирование других отчетов штатное расписание, карточки должности, карта грейдов
*
, цели и показатели для управления процессами и т. д Документ показывает количество должностей в каждом подразделении, номер грейда для каждой должности, количество сотрудников на должности.
214
Бизнес-процессы. Моделирование, внедрение, управление
и споры будут несущественны. Выбор нотации, как и другие частные вопросы, не определяет успех работы по описанию и регламентации процессов организации в целом. Эту задачу можно решить только в случае системного, комплексного подхода, учитывающего множество различных факторов.
Рассмотрим основные аспекты, которые должны знать и учитывать руководители при построении в организации системы работы по описанию (моделированию) бизнес-процессов.
4.2.1. Формулировка целей описания процессов
Прежде всего необходимо четко определить цели описания процессов. Нечеткость или неадекватность целей приведет к некорректному выбору средств их достижения. В результате деньги и время организации будут потрачены впустую.
Пример. В торговой компании среднего размера директор поставил задачу сотруднику затри месяца подробно описать шесть ее основных процессов. При этом конкретные требования к результату (формат описания, степень детализации процессов и т. д) установлены небыли. В итоге удалось описать лишь незначительную часть процессов, а сотрудник перешел работать в другую организацию. Очевидно, что цели описания процессов были поставлены руководителем некорректно.
Цели описания процессов должны быть четко сформулированы в проектном документе. Возможными целями описания могут быть:
анализ и последующая оптимизация процессов;
—
разработка регламентирующих документов;
—
подготовка к автоматизации процессов;
—
прочее.
—
В 2011 году компания BPTrends провела исследования в области моделирования бизнес-процессов. Респондентами стали представители почти 16 000 зарегистрированных участников сообщества
216
Бизнес-процессы. Моделирование, внедрение, управление
На втором месте — пункт Для передачи информации о процессе. Иными словами, это использование описания процессов для последующей регламентации, размещения информации о процессах на портале организации и т. п. Нотация моделирования процессов
Руководителям нужно определиться с требованиями к описанию процессов, в том числе выбрать нотации для создания моделей. Следует выявить внутренних потребителей и понять их запросы. Например, руководителям подразделений нужно будет использовать описания процессов для формирования регламентирующих документов. Департамент по работе с персоналом заинтересован в выгрузке из системы моделирования должностных инструкций. Важно понимать, что описание процесса в среде моделирования содержит гораздо больше информации, чем показано на его графической схеме независимо от нотации. Но именно эта информация необходима при регламентации, формировании отчетов и т. д.
При выборе нотации полезно обратить внимание наследующее. Если описание процессов делается для создания регламентирующих документов, то схемы процессов должны быть просты и интуитивно Как подготовку к внедрению ERP-систем
Как подготовку к внедрению Для удовлетворения требований к документированию бизнес-процессов, включая согласование
Как подготовку к разработке программного обеспечения
Как часть инициатив по преобразованию бизнеса
Для уточнения определенной совокупности деятельности
Для передачи информации о процессе
Вместе с реинжинирингом и совершенствованием процессов 20 40 60 80 Рис. 4.2.1. Как вы используете моделирование бизнес-процессов?
218
Бизнес-процессы. Моделирование, внедрение, управление. Репозиторий и среда моделирования процессов
Представьте, что вам поручили разработать регламент выполнения какого-то процесса компании. Ситуация складывается удачно — у вас стоит MS Visio. Вы создаете новый файл, начинаете рисовать схему процесса, затем сохраняете ее, включаете в регламент, согласуете его с руководителями и т. п. Через два месяца нужно сделать еще один документ по той же процедуре. Кроме вас еще несколько руководителей и специалистов компании время от времени мастерят регламенты процессов. В результате в организации появляется множество схем, описанных в различных форматах и инструментах. Они хаотично хранятся в файлах на компьютерах разных пользователей. Как можно оценить такое положение дел Неужели так работать удобно Скорее всего, нет. Сложившуюся ситуацию можно охарактеризовать так:
процессы моделируют разные сотрудники без всякой коорди-
—
нации;
единого стандарта моделирования процессов нет;
—
единого места для хранения схем процессов нет;
—
внесение изменений в регламентирующие документы требует ручной работы;
доступ сотрудников к информации по процессам затруднен;
—
информация, формализованная в схемах и описаниях процессов, быстро устаревает.
С ростом количества схем процессов ситуация становится угрожающей. Руководство компании понимает полезность описания, анализа и регламентации процессов, ноне готово развивать и поддерживать такую работу, осознавая запутанность существующей практики моделирования и регламентации процессов.
В таких условиях нужен электронный репозиторий бизнес- процессов, ведь нельзя с самой ценной для компании информацией обходиться как с мусором
220
Бизнес-процессы. Моделирование, внедрение, управление
технологические инструкции;
•
положения о подразделениях;
•
должностные инструкции сотрудников;
•
прочее;
•
быстрый и легкий доступ к информации по процессам через
—
интерфейс;
возможность использовать накопленные знания для автома-
—
тизации;
возможность использовать информацию о процессах для обучения новых сотрудников;
прочее.
—
Если у компании несколько филиалов, тов репозитории можно накапливать информацию и обмениваться опытом эффективного выполнения процессов в разных регионах и городах.
Создание электронного репозитория бизнес-процессов — это инвестиция в будущее компании. Почему Судите сами внедряя репо- зиторий, вы:
выполняете описание, анализ и улучшаете бизнес-процессы
—
организации;
приучаете руководителей и специалистов мыслить категориями процессов (другими словами, создаете в компании культуру процессного управления);
делаете систему управления прозрачной;
—
получаете возможность со временем избавиться от незаменимых персонажей (разгерметизировать деятельность отделов и сотрудников).
Особенно интересно связать процессы репозитория с процессами, выполняемыми в различных автоматизированных системах. Вызнаете, например, что ваша система поддерживает определенные
222
Бизнес-процессы. Моделирование, внедрение, управление
в репозиторий процессов. В дальнейшем сотрудники другой смены других филиалов, новые сотрудники и т. д) смогут не только ознакомиться с регламентом выполнения процесса, но и посмотреть рекомендации по наиболее эффективному способу выполнения работы. Со временем этот способ можно будет внести в регламент в качестве обязательного.
Описанная ситуация годится для любого бизнес-процесса независимо от объекта деятельности.
Говоря о практическом использовании репозитория, следует отметить, что:
для поддержания репозитория требуются квалифицированные специалисты;
работать с репозиторием нужно по определенным, четко установленным правилам.
Качество информации в репозитории зависит от квалификации сотрудников, моделирующих процессы. Кроме того, эту информацию нужно постоянно актуализировать.
Руководство компании должно понимать можно купить программу для бизнес-моделирования, потратив некоторую сумму, но купить репозиторий нельзя, его нужно создать и поддерживать силами организации. Приведу аналогии если не делать ремонт, то крыша склада прохудится, а товар испортится. Если не менять изнашивающиеся детали оборудования, то оно встанет. Если не использовать на практике и не актуализировать информацию о бизнес- процессах в репозитории, то он быстро станет ненужным хранилищем мертвого массива данных.
Важно знать основные возможности среды моделирования процессов, которую предполагается использовать для создания репози- тория. Современные программные продукты, предназначенные для описания процессов, как правило, хранят информацию в промышленной базе данных (например, в СУБД MS SQL-Server). Эти системы позволяют создавать сложные, иерархические справочники процессов,
BPMN — система условных обозначений (нотация) и модель для описания и подготовки к автоматизации бизнес-процессов. Разработана она компанией Business Process Management Initiative и поддерживается после слияния организаций в 2005 году. Предыдущая версия BPMN — 1.2, последняя версия — Нотация BPMN появилась относительно недавно. Она ориентирована на описание так называемых исполняемых процессов, то есть процессов, которые поддерживаются системами автоматизации операционных процессов — Рассмотрим пример. В торговой компании есть отдел продаж, деятельность которого заключается в получении и обработке заявок клиентов, выставлении счетов и т. п. Структура процессов отдела следующая:
получение заявок клиентов;
—
обработка заявки и выставление счета (процесс выполняется по одинаковой процедуре несколькими менеджерами отдела Появилась в 2012 году
3) абстрактные имена у стрелок после Решения. Правильно — при слиянии потоков в ситуации, требующей применения исключающего логического ИЛИ, блок Решение не используется
ТКП для клиента согласовано
ТКП для клиента не согласовано. Правильно — в случае возникновения ситуации, требующей применения логического И, блок Решение не используется
Принять решение по премированию персонала
Принято решение выдать премии
Принято решение подарить ценные подарки. Неправильно — не использован блок Решение в случае возникновения ситуации применения исключающего логического «ИЛИ»
Выполнить классификацию запроса клиента
Запрос клиента на оказание услуг
Запрос клиента на поставку оборудования
Бизнес-процессы. Моделирование, внедрение, управление
Схема процесса в нотации ARIS eEPC (построена в Business Studio)
Плюс
Минус
При формировании схемы выдерживается
1. строгая, формальная логика процесса.
Четко определены все события, возникающие
2. походу процесса Сложность восприятия. Трудоемкость формирования схемы. У сотрудников должны быть специальные навыки и опыт интерпретации подобных схем.
Информационная избыточность. Занимает слишком много места, что неудобно
5. для документирования На рис. 4.7.5 изображен тот же процесс в нотации BPMN. Как видим, этот рисунок похож на рис. 4.7.1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.
Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: лишь один вид развилок из пяти имеющихся и один вид задач из восьми. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но и несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, это более строгая нотация в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована и на то, что ее будут читать люди, и на непосредственное исполнение специальным программным обеспечением — движком системы. В тоже время, как показывает данный пример, при использовании ограниченного подмножества BPMN оказывается не сложнее привычной блок-схемы.
При описании процессов на операционном уровне нужно стремиться к простоте и понятности схем для сотрудников. Использование сложных нотаций приводит к:
трудностям при интерпретации схем рядовыми сотрудниками;
—
невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение
276
Бизнес-процессы. Моделирование, внедрение, управление
значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
дополнительным сложностям при документировании схем например, большой объем).
Нотация моделирования должна соответствовать уровню про- цессной культуры организации. Если сотрудники компании делают первые шаги в области описания процессов, то желательно выбрать простую, наглядную и удобную нотацию. Формирование регламентирующих документов на основе описания процессов
После того как процессы описаны в среде моделирования (говоря шире — создана объектная модель организации, можно и нужно использовать эту информацию для регламентации деятельности.
В этом параграфе приведен пример использования среды моделирования для формирования регламентирующих документов. Рассматриваются процессы управления транспортным отделом одной из российских компаний (методика определения процессов управления представлена в главе 6). С технической точки зрения точно также можно описывать любые процессы и другие объекты регламентации (подразделения, должности).
На рис. 4.8.1 показана структура процессов управления транспортным отделом (ТО) крупной торговой компании, разработанная в рамках проекта, в котором я в свое время принимал участие.
Представлен процесс управления транспортным отделом (ТО) торговой компании «Оптима» (г. Ижевск. Описание процессов выполнено в среде моделирования Business Studio. На рисунке слева видно дерево процессов, в котором процессы управления структурированы по соответствующим контурам.
Для описания объекта модели Управление ТО и контуров управления использована нотация Процесс. Это наиболее простая нотация в Business Studio, нов рамках предложенной задачи ее использование вполне адекватно
Как правило, при помощи структурной модели процессов верхнего уровня удается получить информацию о возможном перечне процесс- ных категорий и групп, то есть создать основу процессного дерева. Пример. Рассмотрим схему процессов верхнего уровня телекоммуникационной компании, представленную на рис. 3.5.1. На рисунке показана схема цепочки создания ценности по одной из основных ее услуг. При разработке схемы были описаны процессы по пяти основным категориям (на рис. 3.5.1 обведены рамками, которые условно назвали так:
«Продавать услуги. Настраивать сервисы для клиента. Осуществлять текущее обслуживание клиентов.
* Схема выполнена в нотации, разработанной компанией ФИНЭКСПЕРТ.РУ в период с 2007 по 2008 год
Рис. 3.5.1. Пример схемы процессов верхнего уровня (схема цепочки создания ценности Серой заливкой показаны процессы, выполняемые внешними контрагентами данной организации.
Продавать услуги активная продажа)
Продавать услуги пассивная продажа)
Настраивать сервисы для клиента
Управлять доступ-провайдерами
Приобретать номерную емкость
Обслуживать номерную емкость
Покупать услугу
Самостоятельно настраивать сервисы через Информация об услугах
Потребность в услуге
Потребность в услуге
Потребность в услуге
Конфигурация Конфигурация услуги услуги
Настройки Настройки пользователя пользователя
Управление Управление информацией информацией
Информация Информация о сервисах о сервисах сайта сайта
План по покупке номеров
Номерная емкость
ТУ на услугу
Номерная емкость
Оплаченная номерная емкость
Технические Технические настройки настройки
Информация, Информация, договор, счет договор, счет и прочее и прочее
Информация Информация об оплате, об оплате, договор договор
Клиент
Клиент
Отдел по работе с клиентами
Отдел по работе с операторами
Отдел по работе с операторами
Отдел по работе с операторами, бухгалтерия
Отдел продаж
Отдел продаж. Продавать услуги. Настраивать сервисы для клиента. Обеспечивать каналами связи
Телефонный Телефонный номер номер клиента клиента
Продавать услуги активная продажа)
Продавать услуги пассивная продажа)
Настраивать сервисы для клиента
Управлять доступ-провайдерами
Приобретать номерную емкость
Обслуживать номерную емкость
Покупать услугу
Самостоятельно настраивать сервисы через Информация об услугах
Потребность в услуге
Потребность в услуге
Потребность в услуге
Конфигурация Конфигурация услуги услуги
Настройки Настройки пользователя пользователя
Управление Управление информацией информацией
Информация Информация о сервисах о сервисах сайта сайта
План по покупке номеров
Номерная емкость
ТУ на услугу
Номерная емкость
Оплаченная номерная емкость
Технические Технические настройки настройки
Информация, Информация, договор, счет договор, счет и прочее и прочее
Информация Информация об оплате, об оплате, договор договор
Клиент
Клиент
Отдел по работе с клиентами
Отдел по работе с операторами
Отдел по работе с операторами
Отдел по работе с операторами, бухгалтерия
Отдел продаж
Отдел продаж. Продавать услуги. Настраивать сервисы для клиента. Обеспечивать каналами связи
Телефонный Телефонный номер номер клиента клиента
Выполнять переадре- сацию трафика (тех.)
Конвертировать файлы в tif (тех.)
Выполнять консультирование по проблемам
Выполнять финансовое обслуживание клиентов
Разрешать технические проблемы клиента
Управлять разрешением проблем клиентов
Конвертировать голос в avi (тех.)
Передавать трафик
Передавать трафик
Передавать интернет- трафик
Входящий трафик
Счет от провайдера Входящий Входящий трафик трафик в организации в организации
Голос по Факсы по Телефонный Телефонный трафик в сети трафик в сети
Запросы
Запросы
Заявки Заявки на решение на решение проблем проблем
Заявки на решение проблем
Консультации Консультации по использованию по использованию услуг услуг
Вопросы Вопросы по использованию по использованию услуги услуги
Вопросы Вопросы по использованию по использованию услуги услуги
Финансовые Финансовые документы документы и информация и информация
Информация Информация о решенной о решенной проблеме проблеме
Телефонный Телефонный трафик трафику клиента у клиента
Факсы Факсы и голос и голосу клиента у клиента
Доступ-провайдер
Доступ-провайдер
Коммутатор + сервер БД
Софт на коммутаторе
Интернет- провайдеры
Софт на коммутаторе
Отдел по работе с клиентами
Отдел по работе с клиентами
Инженерный отдел, отдел администрирования сетей. Управлять трафиком. Осуществлять текущее обслуживание клиентов
Отдел расчетов, бухгалтерия, отдел по работе с клиентами
198
Бизнес-процессы. Моделирование, внедрение, управление
«Управлять трафиком. Обеспечивать каналами связи. При разработке схемы сначала пришлось описать процессы на уровне процессных групп, который позволял понять бизнес компании (как создается ценность для клиента по одной из основных видов услуг. Затем эти процессы были разделены по перечисленным категориям. Состав и группировка процессов на рис. 3.5.1 не являются идеальными. Ноне следует забывать, что построение модели верхнего уровня — это только инструмент анализа деятельности организации, используемый для формирования системы процессов.
Как правило, для построения модели процессов верхнего уровня приходится делать несколько итераций. Если начинать моделирование с самого верхнего уровня, то почти для всех компаний сформируется похожая схема закупка — производство сбыт. Но такая упрощенная модель не содержит информации о конкретной организации и поэтому не считается ценной. Модель верхнего уровня полезна для понимания процессов только в том случае, если она отражает особенности бизнеса организации, причем в понятной для топ-менеджеров и собственников форме. Рис. 3.5.2 обобщает пример, представленный на рис. 3.5.1. На нем показано, как используется структурная схема процессов организации на верхнем уровне при построении системы процессов. Категория процессов (процессы верхнего уровня) — это основа для формирования процессного дерева. Далее определяются процессы второго уровня — группы процессов. Причем на модели верхнего уровня следует показывать минимальное количество связей нужны только наиболее важные, системообразующие. Нив коем случае нельзя показывать детальные потоки документов (информации) — это сделает модель нечитаемой. Модель верхнего уровня — эскизная. Она нужна для обоснованного формирования структуры процессных категорий и групп в системе процессов организации. Для формирования третьего уровня используем информацию о деятельности структурных подразделений организации. При этом важно не забыть про сквозные (кросс-функциональные) процессы.
Конвертировать файлы в tif (тех.)
Выполнять консультирование по проблемам
Выполнять финансовое обслуживание клиентов
Разрешать технические проблемы клиента
Управлять разрешением проблем клиентов
Конвертировать голос в avi (тех.)
Передавать трафик
Передавать трафик
Передавать интернет- трафик
Входящий трафик
Счет от провайдера Входящий Входящий трафик трафик в организации в организации
Голос по Факсы по Телефонный Телефонный трафик в сети трафик в сети
Запросы
Запросы
Заявки Заявки на решение на решение проблем проблем
Заявки на решение проблем
Консультации Консультации по использованию по использованию услуг услуг
Вопросы Вопросы по использованию по использованию услуги услуги
Вопросы Вопросы по использованию по использованию услуги услуги
Финансовые Финансовые документы документы и информация и информация
Информация Информация о решенной о решенной проблеме проблеме
Телефонный Телефонный трафик трафику клиента у клиента
Факсы Факсы и голос и голосу клиента у клиента
Доступ-провайдер
Доступ-провайдер
Коммутатор + сервер БД
Софт на коммутаторе
Интернет- провайдеры
Софт на коммутаторе
Отдел по работе с клиентами
Отдел по работе с клиентами
Инженерный отдел, отдел администрирования сетей. Управлять трафиком. Осуществлять текущее обслуживание клиентов
Отдел расчетов, бухгалтерия, отдел по работе с клиентами
198
Бизнес-процессы. Моделирование, внедрение, управление
«Управлять трафиком. Обеспечивать каналами связи. При разработке схемы сначала пришлось описать процессы на уровне процессных групп, который позволял понять бизнес компании (как создается ценность для клиента по одной из основных видов услуг. Затем эти процессы были разделены по перечисленным категориям. Состав и группировка процессов на рис. 3.5.1 не являются идеальными. Ноне следует забывать, что построение модели верхнего уровня — это только инструмент анализа деятельности организации, используемый для формирования системы процессов.
Как правило, для построения модели процессов верхнего уровня приходится делать несколько итераций. Если начинать моделирование с самого верхнего уровня, то почти для всех компаний сформируется похожая схема закупка — производство сбыт. Но такая упрощенная модель не содержит информации о конкретной организации и поэтому не считается ценной. Модель верхнего уровня полезна для понимания процессов только в том случае, если она отражает особенности бизнеса организации, причем в понятной для топ-менеджеров и собственников форме. Рис. 3.5.2 обобщает пример, представленный на рис. 3.5.1. На нем показано, как используется структурная схема процессов организации на верхнем уровне при построении системы процессов. Категория процессов (процессы верхнего уровня) — это основа для формирования процессного дерева. Далее определяются процессы второго уровня — группы процессов. Причем на модели верхнего уровня следует показывать минимальное количество связей нужны только наиболее важные, системообразующие. Нив коем случае нельзя показывать детальные потоки документов (информации) — это сделает модель нечитаемой. Модель верхнего уровня — эскизная. Она нужна для обоснованного формирования структуры процессных категорий и групп в системе процессов организации. Для формирования третьего уровня используем информацию о деятельности структурных подразделений организации. При этом важно не забыть про сквозные (кросс-функциональные) процессы.
Глава 3. Разработка системы процессов организации
199
Итак, основа для формирования системы процессов — процесс- ный взгляд на организацию на уровне бизнеса, а информацию для наполнения системы детальными процессами (начиная с третьего уровня) получаем из матриц процессов структурных подразделений. Отмечу, что при переносе информации из модели верхнего уровняв таблицу процессов организации не всегда возникает однозначное соответствие, поскольку:
часть процессов может отсутствовать на схеме, но должна быть включена в матрицу (например, вспомогательные процессы);
процессы могут быть перегруппированы (для получения более адекватного решения);
некоторые процессы могут быть сгруппированы (то есть изменен уровень);
Рис. 3.5.2. Использование модели процессов верхнего уровня для построения системы процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Процессная категория
Процессная категория
Процессная категория
Процессная категория
Структурная модель процессов организации
Матрица процессов организации
Группа процессов
№
Наименование процесса
Руководитель, ответственный за процесс
Участники процесса
Процессная категория
Группа процессов
200
Бизнес-процессы. Моделирование, внедрение, управление
некоторые процессы могут быть добавлены на основе стратегического видения собственников;
прочее.
—
Работа по формированию матрицы процессов на основе модели верхнего уровня — дело творческое. Как правило, требуется проделать несколько итераций, чтобы матрица процессов соответствовала реальному бизнесу компании.
Построение модели процессов на верхнем уровне — не самоцель, а средство понимания деятельности организации с процессной точки зрения.
3.6. Определение процессов подразделений
Для наполнения системы процессов организации на третьем- четвертом уровнях нужна информация о деятельности структурных подразделений. На рис. 3.6.1 показан алгоритм определения процессов структурного подразделения организации. На шаге 1 определяем входы и выходы, составив их перечень. Для этого нужно проанализировать все взаимодействия подразделения с другими отделами и внешними контрагентами. Стоит учесть не только движение бумажных, но и электронных документов, устных сообщений. На шаге 2 все выявленные входы/выходы нужно сгруппировать так, чтобы получилось не более шести—восьми (максимум десять—двена- дцать) групп. Основной критерий для группировки — принадлежность документов (и других ресурсов) к конкретному продукту/услуге, в создании которого участвует подразделение. Адекватная группировка входов/выходов позволяет предположить состав его процессов. На шаге 3, используя информацию о группах входов/выходов и предположения о структуре процессов, формируем структурную схему процессов. Пример такой схемы представлен на рис. 3.6.2. Цель формирования схемы — выявить возможные процессы подразделения, определить связи между ними, согласовать полученную структуру.
199
Итак, основа для формирования системы процессов — процесс- ный взгляд на организацию на уровне бизнеса, а информацию для наполнения системы детальными процессами (начиная с третьего уровня) получаем из матриц процессов структурных подразделений. Отмечу, что при переносе информации из модели верхнего уровняв таблицу процессов организации не всегда возникает однозначное соответствие, поскольку:
часть процессов может отсутствовать на схеме, но должна быть включена в матрицу (например, вспомогательные процессы);
процессы могут быть перегруппированы (для получения более адекватного решения);
некоторые процессы могут быть сгруппированы (то есть изменен уровень);
Рис. 3.5.2. Использование модели процессов верхнего уровня для построения системы процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Группа процессов
Процессная категория
Процессная категория
Процессная категория
Процессная категория
Структурная модель процессов организации
Матрица процессов организации
Группа процессов
№
Наименование процесса
Руководитель, ответственный за процесс
Участники процесса
Процессная категория
Группа процессов
200
Бизнес-процессы. Моделирование, внедрение, управление
некоторые процессы могут быть добавлены на основе стратегического видения собственников;
прочее.
—
Работа по формированию матрицы процессов на основе модели верхнего уровня — дело творческое. Как правило, требуется проделать несколько итераций, чтобы матрица процессов соответствовала реальному бизнесу компании.
Построение модели процессов на верхнем уровне — не самоцель, а средство понимания деятельности организации с процессной точки зрения.
3.6. Определение процессов подразделений
Для наполнения системы процессов организации на третьем- четвертом уровнях нужна информация о деятельности структурных подразделений. На рис. 3.6.1 показан алгоритм определения процессов структурного подразделения организации. На шаге 1 определяем входы и выходы, составив их перечень. Для этого нужно проанализировать все взаимодействия подразделения с другими отделами и внешними контрагентами. Стоит учесть не только движение бумажных, но и электронных документов, устных сообщений. На шаге 2 все выявленные входы/выходы нужно сгруппировать так, чтобы получилось не более шести—восьми (максимум десять—двена- дцать) групп. Основной критерий для группировки — принадлежность документов (и других ресурсов) к конкретному продукту/услуге, в создании которого участвует подразделение. Адекватная группировка входов/выходов позволяет предположить состав его процессов. На шаге 3, используя информацию о группах входов/выходов и предположения о структуре процессов, формируем структурную схему процессов. Пример такой схемы представлен на рис. 3.6.2. Цель формирования схемы — выявить возможные процессы подразделения, определить связи между ними, согласовать полученную структуру.
Информация о входах/выходах
Информация о входах/выходах
Схема процессов подразделения
Схема процессов подразделения
Матрица процессов подразделения, версия Согласованная матрица процессов подразделения
Перечень операций процессов
Начало
Конец
Определить входы и выходы подразделения
Сгруппировать входы/выходы
Разработать схему процессов подразделения
Определить операции процессов подразделения
Заполнить матрицу процессов подразделения
Согласовать матрицу процессов подразделения 2
3 4
5 Рис. 3.6.1. Алгоритм определения процессов структурного подразделения
202
Бизнес-процессы. Моделирование, внедрение, управление
Адекватную схему процессов подразделения можно получить после двух-трех итераций (разработка схемы — обсуждение — внесение изменений) по обсуждению и согласованию, в которых принимают участие руководитель подразделения и ведущие специалисты, представители подразделения организационного развития. Построение и обсуждение схемы позволяет взглянуть на деятельность подразделения с процессной точки зрения. Еще раз напомню, что при анализе деятельности подразделения важно выявить сквозные процессы. Как правило, руководителям сложно системно взглянуть на деятельность своего подразделения и структурировать его в виде процессов. Поэтому такая работа обязательно должна методически поддерживаться и координироваться бизнес-аналитиками службы организационного развития, а результаты этой работы нужно тщательно проверить, прежде чем включить их в общую систему процессов. Результат выполнения шага 3 — схема и перечень процессов подразделения. Общее количество выделенных процессов не должно превышать восемь—двенадцать. Рекомендуемое количество — шесть—восемь. Процесс Процесс После анализа объединили в один процесс Процесс Процесс Подразделение С, процесс С
Подразделение А, процесс А
Подразделение Д, процесс Д
Подразделение Б, процесс Б
Подразделение Е, процесс Е
Внешний поставщик А
Процесс Процесс Процесс управления подразделением
Подразделение
Рис. 3.6.2. Структурная схема процессов подразделения
Информация о входах/выходах
Схема процессов подразделения
Схема процессов подразделения
Матрица процессов подразделения, версия Согласованная матрица процессов подразделения
Перечень операций процессов
Начало
Конец
Определить входы и выходы подразделения
Сгруппировать входы/выходы
Разработать схему процессов подразделения
Определить операции процессов подразделения
Заполнить матрицу процессов подразделения
Согласовать матрицу процессов подразделения 2
3 4
5 Рис. 3.6.1. Алгоритм определения процессов структурного подразделения
202
Бизнес-процессы. Моделирование, внедрение, управление
Адекватную схему процессов подразделения можно получить после двух-трех итераций (разработка схемы — обсуждение — внесение изменений) по обсуждению и согласованию, в которых принимают участие руководитель подразделения и ведущие специалисты, представители подразделения организационного развития. Построение и обсуждение схемы позволяет взглянуть на деятельность подразделения с процессной точки зрения. Еще раз напомню, что при анализе деятельности подразделения важно выявить сквозные процессы. Как правило, руководителям сложно системно взглянуть на деятельность своего подразделения и структурировать его в виде процессов. Поэтому такая работа обязательно должна методически поддерживаться и координироваться бизнес-аналитиками службы организационного развития, а результаты этой работы нужно тщательно проверить, прежде чем включить их в общую систему процессов. Результат выполнения шага 3 — схема и перечень процессов подразделения. Общее количество выделенных процессов не должно превышать восемь—двенадцать. Рекомендуемое количество — шесть—восемь. Процесс Процесс После анализа объединили в один процесс Процесс Процесс Подразделение С, процесс С
Подразделение А, процесс А
Подразделение Д, процесс Д
Подразделение Б, процесс Б
Подразделение Е, процесс Е
Внешний поставщик А
Процесс Процесс Процесс управления подразделением
Подразделение
Рис. 3.6.2. Структурная схема процессов подразделения
Глава 3. Разработка системы процессов организации
203
На шаге 4 для каждого выделенного процесса подразделения определяются входящие в него операции (подпроцессы
*
). Общее количество операций для каждого процесса не должно превышать На шаге 5 заполняется матрица процессов подразделения, которая включает:
перечень процессов и операций (то есть два уровня процесс-
—
ного представления);
информацию о границах процессов и операций (входы/выхо-
—
ды и события);
информацию об ответственности за выполнение процессов и операций (в форме матрицы ответственности).
Возможная форма матрицы процессов подразделения показана в табл. На шаге 5 осуществляют анализ, уточнение (по входам/выходам) и согласование матрицы процессов подразделения. Акцент здесь делается на согласовании видения процессов подразделения его руководителем и специалистами. Согласование входов/выходов процессов на межфункциональном уровне может производиться позже, на стадии формирования, анализа и согласования системы процессов организации в целом. Пример. Далеевтаблице показан фрагмент матрицы процессов отдела по работе с клиентами телекоммуникационной компании (пример с цепочкой ценностей этой же компании предлагался выше. Обратите внимание, что процессы, выделенные в матрице, отсутствуют на рис. 3.5.1. Дело в том, что в матрице процессов подразделения представлены процессы третьего и четвертого уровней, в то время как на рис. 3.5.1 — первого (категории процессов) и второго уровней (группы процессов.
* В зависимости от уровня структурного подразделения.
203
На шаге 4 для каждого выделенного процесса подразделения определяются входящие в него операции (подпроцессы
*
). Общее количество операций для каждого процесса не должно превышать На шаге 5 заполняется матрица процессов подразделения, которая включает:
перечень процессов и операций (то есть два уровня процесс-
—
ного представления);
информацию о границах процессов и операций (входы/выхо-
—
ды и события);
информацию об ответственности за выполнение процессов и операций (в форме матрицы ответственности).
Возможная форма матрицы процессов подразделения показана в табл. На шаге 5 осуществляют анализ, уточнение (по входам/выходам) и согласование матрицы процессов подразделения. Акцент здесь делается на согласовании видения процессов подразделения его руководителем и специалистами. Согласование входов/выходов процессов на межфункциональном уровне может производиться позже, на стадии формирования, анализа и согласования системы процессов организации в целом. Пример. Далеевтаблице показан фрагмент матрицы процессов отдела по работе с клиентами телекоммуникационной компании (пример с цепочкой ценностей этой же компании предлагался выше. Обратите внимание, что процессы, выделенные в матрице, отсутствуют на рис. 3.5.1. Дело в том, что в матрице процессов подразделения представлены процессы третьего и четвертого уровней, в то время как на рис. 3.5.1 — первого (категории процессов) и второго уровней (группы процессов.
* В зависимости от уровня структурного подразделения.
Таблица 3.6.1. Процессы отдела по работе с клиентами (фрагмент)
№
Наименование процесса
Вход
Поставщик
…
4
Финансовое обслуживание клиентов
4.1
Пополнение клиентских счетов
Входящий звонок, письмо клиента Клиент компании
Копия квитанции или платежного поручения
Выписка из банка
Отдел расчетов
4.2
Выставление счетов на предоплату
Входящий звонок, письмо клиента Клиент компании
Заявка, отправленная клиентом с личной веб-страницы сайтов компании
Сайты компании, базы данных компании
4.3
Предоставление детального отчета о звонках
Входящий звонок, письмо клиента
Клиент компании
…
4.7
Предоставление детального отчета о звонках за длительный период из архива
Письмо клиента
Клиент компании
…
6
Изменение условий предоставления услуг
6.1
Перевод клиентов с одного юридического физического) лица на другое (переименование клиентов)
Заявление от клиента
Клиент компании
Запись в реестре (сетевом файле)
Отдел расчетов
6.2
Смена тарифного плана
Заявление от клиента (бумажный документ)
Клиент компании
Запись в реестре (сетевом файле)
Отдел расчетов
…
7
Включение дополнительных услуг
7.1
Включение услуги Удержание вызова»
Заявление от клиента Клиент компании
Запись в реестре (сетевом файле)
Отдел расчетов
Выход
Клиент
Н
а ча льник подразделения Старший специалист Специалист Спец иа лис т-
2
О
Пополненный счет (в базе данных)
Клиент компании
О
У
У
У
Выставленный счет (в базе данных)
Клиент компании
О
У
У
У
Запись в базах данных компании
Базы данных компании
Детализация, предоставленная клиенту (файл, запись в базе данных, бумажный документ
Клиент компании
О
У
У
У
Запрос информации из архива (файл)
Инженерный отдел
О
У
У
Предоставление информации из архива (файл О
У
Назначение ответственного за перевод в реестре (сетевом файле)
Реестр (сетевой файл)
И
И
О
Выставление счета на предоплату на новом лицевом счете клиента
Базы данных компании
Внесение изменений (перенос настроек с одного лицевого счета на другой) в базе данных Новый договор с клиентом (бумажный документ, запись в базе данных)
Клиент компании
И
И
Назначение ответственного за смену тарифного плана в реестре (сетевом файле. Реестр (сетевой файл.
2. Отдел расчетов
И
И
О
Изменение тарифного плана в базе данных База данных компании
И
И
У
О
Новый тарифный план (бумажный документ, запись в базе данных)
Клиент компании
И
И
У
О
О
У
Активация услуги Удержание вызова в базе данных
База данных компании
И
И
У
О
Запись в реестре (сетевом журнале. Реестр (сетевой файл.
2. Отдел расчетов
206
Бизнес-процессы. Моделирование, внедрение, управление. Согласование границ процессов
Согласование границ процессов (часто говорят стыковка процессов по входам/выходам») — важнейший инструмент, который позволяет превратить набор процессов, выделенных в организации, в комплексную, взаимосвязанную систему. Согласование границ удается адекватно выполнить на том уровне процессов, где возникают реальные потоки ресурсов (документов, продуктов. Для документов можно определить шаблоны, по которым они должны заполняться, сроки передачи из отделав отделит. п. Для материальных ресурсов — спецификации, в которых указана информация о составе изделия, маркировке, технических требованиях, весе, упаковке и т. д. В любом случае требования к ресурсам, пересекающим границы процессов, на этом уровне рассмотрения вполне конкретны. Такие требования можно документировать и согласовывать с представителями заинтересованных подразделений (то есть поставщиков/потребителей). Как я уже говорил, на этапе первичного анализа и выделения процессов создаются матрицы процессов подразделений, которые потом используются при создании общей системы процессов, но:
матрицы могут содержать ошибки (неадекватно выделенные процессы, несуществующие входы/выходы, неточности в названиях документов и т. п.);
границы процессов, представленные в матрицах, могут отражать субъективный взгляд руководителей (в том числе их желание изменить свои или чужие зоны ответственности за счет изменения определения состава процессов и входов/
выходов);
по ходу проекта могут возникнуть изменения организационной структуры и, как следствие, состава процессов подразделений, которые не будут учтены в матрицах и т. п.
Поэтому на этапе согласования границ нужно организовать работу подетальному описанию и согласованию входов/выходов
208
Бизнес-процессы. Моделирование, внедрение, управление
но отличаются подходы к организации работ (создается межфунк- циональная рабочая группа и т. д.).
Обратите внимание, что согласование границ процессов делается на уровне реальных потоков документов (материальных ресурсов. На верхних уровнях процессного дерева согласуются уже не детальные потоки документов, а зоны ответственности менеджеров за управление процессами или, шире, процессными группам. В результате каждый менеджер будет знать, что в конкретной процессной категории/группе, за которую он несет ответственность, все границы процессов четко определены и документально зафиксированы.
3.8. Список литературы
Хаммер М, Хершман Л. Быстрее, лучше, дешевле. Девять методов реин-
1. жиниринга бизнес-процессов. — М. : Альпина Паблишер, Репин В. В. Бизнес-процессы компании построение, анализ, регламентация. М. : Стандарты и качество, 2007.
Харрингтон Дж. Совершенство управления процессами. — М. : Стандарты
3. и качество, 2007.
Бьёрн А. Бизнес-процессы. Инструменты совершенствования. — М. :
4. Стандарты и качество, Де Гиус А. Живая компания. Рост, научение и долгожительство вдело. вой среде. — СПб. : Стокгольмская школа экономики в Санкт-Пе тер- бурге, 2004.
210
Бизнес-процессы. Моделирование, внедрение, управление
данных. У всех этих компаний есть одно общее — их руководители и сотрудники ощутили необходимость и ценность описания и регламентации процессов.
Цели описания процессов зависят от размера организации и сути поставленных задач. Прежде чем сформулировать цели описания процессов, рассмотрим несколько практических ситуаций, представленных в табл. Таблица 4.1.1. Возможные ситуации с описанием процессов
Небольшая компания человек)
Средняя компания человек)
Крупная компания 1000 человек)
Фрагментарные описания отдельных процессов (в основном в виде текста и таблиц) разрабатываются под конкретные документы — положения, инструкции. Единый внутренний стандарт описания процессов отсутствует. Процессы описывают в MS Word, MS Excel реже в специализированных программах, нередко выбранных случайно. Высокие трудозатраты на создание и корректировку описаний процессов, включение их в регламентирующие документы. Нет единого архива моделей описаний) процессов организации. За описание процессов никто не отвечает
Утвержден несложный внутренний стандарт описания процессов. Есть несколько специалистов, которые описывают процессы в более или менее стандартном виде. Описания процессов используются для регламентации. Текст, таблицы и графические схемы процессов включаются в регламентирующие документы вручную. Описания процессов хранятся в виде отдельных файлов (часто в виде файлов MS Visio) на разных компьютерах. Значительные трудозатраты на создание и корректировку описаний процессов. Ответственность за поддержание модели процессов организации размыта Внедрена среда моделирования (описания) процессов. Разработано соглашение по моделированию. Есть специализированное подразделение, отвечающее за описание и регламентацию процессов. Информация о процессах хранится в промышленной базе данных в виде так называемой объектной модели. Регламентирующие документы автоматически выгружаются в готовом для утверждения виде из среды моделирования. Оптимальные трудозатраты на создание и корректировку описаний процессов. Четко определена ответственность за хранение и актуализацию моделей процессов. На внутреннем портале размещена информация о процессах организации Как правило, с увеличением численности сотрудников в организации используются более четкие, формальные методики описания процессов и соответствующие инструменты — средства моделирования. Бывают и исключения, когда в компании из 100 человек методики описания процессов четко сформулированы и используются, а в крупной, солидной организации они находятся в зачаточном состоянии и бессистемно применяются отдельными специалистами например, в департаменте управления рисками
№
Наименование процесса
Вход
Поставщик
…
4
Финансовое обслуживание клиентов
4.1
Пополнение клиентских счетов
Входящий звонок, письмо клиента Клиент компании
Копия квитанции или платежного поручения
Выписка из банка
Отдел расчетов
4.2
Выставление счетов на предоплату
Входящий звонок, письмо клиента Клиент компании
Заявка, отправленная клиентом с личной веб-страницы сайтов компании
Сайты компании, базы данных компании
4.3
Предоставление детального отчета о звонках
Входящий звонок, письмо клиента
Клиент компании
…
4.7
Предоставление детального отчета о звонках за длительный период из архива
Письмо клиента
Клиент компании
…
6
Изменение условий предоставления услуг
6.1
Перевод клиентов с одного юридического физического) лица на другое (переименование клиентов)
Заявление от клиента
Клиент компании
Запись в реестре (сетевом файле)
Отдел расчетов
6.2
Смена тарифного плана
Заявление от клиента (бумажный документ)
Клиент компании
Запись в реестре (сетевом файле)
Отдел расчетов
…
7
Включение дополнительных услуг
7.1
Включение услуги Удержание вызова»
Заявление от клиента Клиент компании
Запись в реестре (сетевом файле)
Отдел расчетов
Выход
Клиент
Н
а ча льник подразделения Старший специалист Специалист Спец иа лис т-
2
О
Пополненный счет (в базе данных)
Клиент компании
О
У
У
У
Выставленный счет (в базе данных)
Клиент компании
О
У
У
У
Запись в базах данных компании
Базы данных компании
Детализация, предоставленная клиенту (файл, запись в базе данных, бумажный документ
Клиент компании
О
У
У
У
Запрос информации из архива (файл)
Инженерный отдел
О
У
У
Предоставление информации из архива (файл О
У
Назначение ответственного за перевод в реестре (сетевом файле)
Реестр (сетевой файл)
И
И
О
Выставление счета на предоплату на новом лицевом счете клиента
Базы данных компании
Внесение изменений (перенос настроек с одного лицевого счета на другой) в базе данных Новый договор с клиентом (бумажный документ, запись в базе данных)
Клиент компании
И
И
Назначение ответственного за смену тарифного плана в реестре (сетевом файле. Реестр (сетевой файл.
2. Отдел расчетов
И
И
О
Изменение тарифного плана в базе данных База данных компании
И
И
У
О
Новый тарифный план (бумажный документ, запись в базе данных)
Клиент компании
И
И
У
О
О
У
Активация услуги Удержание вызова в базе данных
База данных компании
И
И
У
О
Запись в реестре (сетевом журнале. Реестр (сетевой файл.
2. Отдел расчетов
206
Бизнес-процессы. Моделирование, внедрение, управление. Согласование границ процессов
Согласование границ процессов (часто говорят стыковка процессов по входам/выходам») — важнейший инструмент, который позволяет превратить набор процессов, выделенных в организации, в комплексную, взаимосвязанную систему. Согласование границ удается адекватно выполнить на том уровне процессов, где возникают реальные потоки ресурсов (документов, продуктов. Для документов можно определить шаблоны, по которым они должны заполняться, сроки передачи из отделав отделит. п. Для материальных ресурсов — спецификации, в которых указана информация о составе изделия, маркировке, технических требованиях, весе, упаковке и т. д. В любом случае требования к ресурсам, пересекающим границы процессов, на этом уровне рассмотрения вполне конкретны. Такие требования можно документировать и согласовывать с представителями заинтересованных подразделений (то есть поставщиков/потребителей). Как я уже говорил, на этапе первичного анализа и выделения процессов создаются матрицы процессов подразделений, которые потом используются при создании общей системы процессов, но:
матрицы могут содержать ошибки (неадекватно выделенные процессы, несуществующие входы/выходы, неточности в названиях документов и т. п.);
границы процессов, представленные в матрицах, могут отражать субъективный взгляд руководителей (в том числе их желание изменить свои или чужие зоны ответственности за счет изменения определения состава процессов и входов/
выходов);
по ходу проекта могут возникнуть изменения организационной структуры и, как следствие, состава процессов подразделений, которые не будут учтены в матрицах и т. п.
Поэтому на этапе согласования границ нужно организовать работу подетальному описанию и согласованию входов/выходов
Глава 3. Разработка системы процессов организации
207
и инициирующих/завершающих событий процессов на межфунк- циональном уровне. В подразделениях для этого создают временные рабочие группы (или это работу делают сами руководители, которые последовательно рассматривают процессы подразделения и:
фиксируют существующие формы документов, при помощи которых осуществляется взаимодействие;
анализируют, согласованы ли соответствующие формы документов с поставщиками/потребителями, утверждены ли они документально;
при необходимости корректируют формы документов (разрабатывают новые формы);
проводят совещания с поставщиками/потребителями (внутренними и внешними) и согласуют соответствующие формы;
определяют, в какие регламентирующие документы на последующем этапе (регламентация процессов) эти согласованные формы могут быть включены (например, в качестве приложений, кем и когда должны быть утверждены.
По такой же логике осуществляется проработка вопросов по спецификациям на материальные ресурсы, пересекающие границы процессов подразделений. Если организовать рабочие группы невозможно, работу по согласованию входов/выходов выполняют квалифицированные бизнес- аналитики.
По ходу согласования границ рабочими группами может быть получена аналитическая информация, которая потребует пересмотра как границ, так, возможно, и состава процессов подразделения. В свою очередь, это повлечет за собой необходимость корректировки общей системы процессов. Такие итерационные корректировки вполне нормальные рабочие моменты при разработке системы процессов. Отдельная задача — определение и согласование границ по сквозным процессам. В данном случае используется та же методика,
207
и инициирующих/завершающих событий процессов на межфунк- циональном уровне. В подразделениях для этого создают временные рабочие группы (или это работу делают сами руководители, которые последовательно рассматривают процессы подразделения и:
фиксируют существующие формы документов, при помощи которых осуществляется взаимодействие;
анализируют, согласованы ли соответствующие формы документов с поставщиками/потребителями, утверждены ли они документально;
при необходимости корректируют формы документов (разрабатывают новые формы);
проводят совещания с поставщиками/потребителями (внутренними и внешними) и согласуют соответствующие формы;
определяют, в какие регламентирующие документы на последующем этапе (регламентация процессов) эти согласованные формы могут быть включены (например, в качестве приложений, кем и когда должны быть утверждены.
По такой же логике осуществляется проработка вопросов по спецификациям на материальные ресурсы, пересекающие границы процессов подразделений. Если организовать рабочие группы невозможно, работу по согласованию входов/выходов выполняют квалифицированные бизнес- аналитики.
По ходу согласования границ рабочими группами может быть получена аналитическая информация, которая потребует пересмотра как границ, так, возможно, и состава процессов подразделения. В свою очередь, это повлечет за собой необходимость корректировки общей системы процессов. Такие итерационные корректировки вполне нормальные рабочие моменты при разработке системы процессов. Отдельная задача — определение и согласование границ по сквозным процессам. В данном случае используется та же методика,
208
Бизнес-процессы. Моделирование, внедрение, управление
но отличаются подходы к организации работ (создается межфунк- циональная рабочая группа и т. д.).
Обратите внимание, что согласование границ процессов делается на уровне реальных потоков документов (материальных ресурсов. На верхних уровнях процессного дерева согласуются уже не детальные потоки документов, а зоны ответственности менеджеров за управление процессами или, шире, процессными группам. В результате каждый менеджер будет знать, что в конкретной процессной категории/группе, за которую он несет ответственность, все границы процессов четко определены и документально зафиксированы.
3.8. Список литературы
Хаммер М, Хершман Л. Быстрее, лучше, дешевле. Девять методов реин-
1. жиниринга бизнес-процессов. — М. : Альпина Паблишер, Репин В. В. Бизнес-процессы компании построение, анализ, регламентация. М. : Стандарты и качество, 2007.
Харрингтон Дж. Совершенство управления процессами. — М. : Стандарты
3. и качество, 2007.
Бьёрн А. Бизнес-процессы. Инструменты совершенствования. — М. :
4. Стандарты и качество, Де Гиус А. Живая компания. Рост, научение и долгожительство вдело. вой среде. — СПб. : Стокгольмская школа экономики в Санкт-Пе тер- бурге, 2004.
Глава Описание бизнес-процессов организации. Цели описания бизнес-процессов организации
В этой главе я использую термины описание и моделирование процессов в качестве синонимов, а также часто употребляю слово нотация. Как правило, нотация — это система условных обозначений, принятая в какой-либо области знаний или деятельности, в частности при моделировании процессов. Сами по себе условные обозначения не дают возможности корректно построить схему бизнес-процесса. Поэтому нотацию я рассматриваю шире — как методику создания схем бизнес-процессов с использованием принятой системы условных обозначений.
Понятие модель процесса в книге имеет более широкий смысл, чем схема процесса. Схема процесса — это графическое изображение процесса в определенном формате, а модель процесса — это его комплексное описание (в том числе и схема. Под термином среда моделирования процессов я понимаю специализированное программное обеспечение для описания процессов.
В современной организации практически невозможно обойтись без описания процессов. По-разному, с неодинаковой степенью детализации, но это делают все. В одних компаниях деятельность по описанию выполняется бессистемно. Схемы создаются без использования утвержденных внутренних стандартов. Файлы со схемами хранятся у нескольких пользователей на разных компьютерах. В других компаниях установлены современные средства моделирования процессов, утверждены внутренние стандарты описания (моделирования. Информация о процессах хранится в промышленных базах
В этой главе я использую термины описание и моделирование процессов в качестве синонимов, а также часто употребляю слово нотация. Как правило, нотация — это система условных обозначений, принятая в какой-либо области знаний или деятельности, в частности при моделировании процессов. Сами по себе условные обозначения не дают возможности корректно построить схему бизнес-процесса. Поэтому нотацию я рассматриваю шире — как методику создания схем бизнес-процессов с использованием принятой системы условных обозначений.
Понятие модель процесса в книге имеет более широкий смысл, чем схема процесса. Схема процесса — это графическое изображение процесса в определенном формате, а модель процесса — это его комплексное описание (в том числе и схема. Под термином среда моделирования процессов я понимаю специализированное программное обеспечение для описания процессов.
В современной организации практически невозможно обойтись без описания процессов. По-разному, с неодинаковой степенью детализации, но это делают все. В одних компаниях деятельность по описанию выполняется бессистемно. Схемы создаются без использования утвержденных внутренних стандартов. Файлы со схемами хранятся у нескольких пользователей на разных компьютерах. В других компаниях установлены современные средства моделирования процессов, утверждены внутренние стандарты описания (моделирования. Информация о процессах хранится в промышленных базах
210
Бизнес-процессы. Моделирование, внедрение, управление
данных. У всех этих компаний есть одно общее — их руководители и сотрудники ощутили необходимость и ценность описания и регламентации процессов.
Цели описания процессов зависят от размера организации и сути поставленных задач. Прежде чем сформулировать цели описания процессов, рассмотрим несколько практических ситуаций, представленных в табл. Таблица 4.1.1. Возможные ситуации с описанием процессов
Небольшая компания человек)
Средняя компания человек)
Крупная компания 1000 человек)
Фрагментарные описания отдельных процессов (в основном в виде текста и таблиц) разрабатываются под конкретные документы — положения, инструкции. Единый внутренний стандарт описания процессов отсутствует. Процессы описывают в MS Word, MS Excel реже в специализированных программах, нередко выбранных случайно. Высокие трудозатраты на создание и корректировку описаний процессов, включение их в регламентирующие документы. Нет единого архива моделей описаний) процессов организации. За описание процессов никто не отвечает
Утвержден несложный внутренний стандарт описания процессов. Есть несколько специалистов, которые описывают процессы в более или менее стандартном виде. Описания процессов используются для регламентации. Текст, таблицы и графические схемы процессов включаются в регламентирующие документы вручную. Описания процессов хранятся в виде отдельных файлов (часто в виде файлов MS Visio) на разных компьютерах. Значительные трудозатраты на создание и корректировку описаний процессов. Ответственность за поддержание модели процессов организации размыта Внедрена среда моделирования (описания) процессов. Разработано соглашение по моделированию. Есть специализированное подразделение, отвечающее за описание и регламентацию процессов. Информация о процессах хранится в промышленной базе данных в виде так называемой объектной модели. Регламентирующие документы автоматически выгружаются в готовом для утверждения виде из среды моделирования. Оптимальные трудозатраты на создание и корректировку описаний процессов. Четко определена ответственность за хранение и актуализацию моделей процессов. На внутреннем портале размещена информация о процессах организации Как правило, с увеличением численности сотрудников в организации используются более четкие, формальные методики описания процессов и соответствующие инструменты — средства моделирования. Бывают и исключения, когда в компании из 100 человек методики описания процессов четко сформулированы и используются, а в крупной, солидной организации они находятся в зачаточном состоянии и бессистемно применяются отдельными специалистами например, в департаменте управления рисками
Глава 4. Описание бизнес-процессов организации
211
Сформулируем цели описания процессов для организаций разного размера.
211
Сформулируем цели описания процессов для организаций разного размера.
1 ... 7 8 9 10 11 12 13 14 ... 21
Небольшая организация (10–100 человек)
Возможные цели описания процессов (моделирования) в небольшой организации:
Четкое определение зон ответственности руководителей
1. по ключевым направлениям деятельности.
Описание деятельности в формализованном виде для регламентации ключевых процессов организации сбыт, закупки, бюджетирование, управление проектами и т. д. Использование описаний процессов при создании документов инструкции по выполнению процессов, положения о взаимодействии.
Анализ и улучшение деятельности. Подготовка к автоматизации деятельности, в том числе про. цессов.
Первые шаги по созданию культуры процессного управления
5. у сотрудников (обучение процессному ви´дению).
Средняя организация (100–1000 человек)
Возможные цели описания процессов (моделирования) в организации среднего размера:
Четкое определение зон ответственности руководителей
1. на всех уровнях управления.
Оптимизация взаимодействия структурных подразделений
2. за счет стыковки процессов по входам/выходам.
Системное описание процессов в формализованном виде.
3. Централизованное хранение и актуализация моделей процессов. Постоянное использование моделей процессов для регламентации регламенты выполнения процессов, инструкции по выполнению процессов, положения о взаимодействии и т. д
212
Бизнес-процессы. Моделирование, внедрение, управление
Тиражирование стандартов деятельности (например, в фи. лиалы).
Обучение сотрудников. Автоматизация процессов. Анализ и улучшение деятельности. Развитие культуры процессного управления у сотрудников. Крупная организация (> 1000 человек)
Возможные цели описания процессов (моделирования) в крупной организации:
Четкое определение зон ответственности руководителей
1. на всех уровнях.
Оптимизация взаимодействия структурных подразделений
2. за счет стыковки процессов по входам/выходам.
Создание системы процессов организации. Системное описание процессов в формализованном виде на нескольких уровнях (создание так называемой объектной модели организации. Централизованное хранение (в промышленной базе данных) и актуализация моделей процессов.
Автоматизация создания регламентирующих документов (при
4. помощи выгрузки из среды моделирования на основе стандартных шаблонов. Формирование нормативно-методических документов регламенты выполнения процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции. Формирование других отчетов штатное расписание, карточки должности, карта грейдов
*
, цели и показатели для управления процессами и т. д Документ показывает количество должностей в каждом подразделении, номер грейда для каждой должности, количество сотрудников на должности.
Глава 4. Описание бизнес-процессов организации
213
Описание и регламентация процессов управления на всех
5. уровнях.
Анализ возможных изменений (реализация сценариев что
6. если) в модели организации 1) создание нового подразделения с передачей ему операций процессов других подразделений) ликвидация подразделения с передачей его процессов другим подразделениям.
Тиражирование стандартов деятельности (например, в фи. лиалы).
Выполнение внутреннего аудита. Подбор персонала (на основе подробной информации о выполняемых сотрудником процессах).
Обучение сотрудников. Автоматизация процессов. Анализ и улучшение деятельности. Управление знаниями о деятельности организации. Вовлечение руководителей и сотрудников подразделений
14. в работу по описанию и стандартизации деятельности орга- низации.
Развитие культуры процессного управления у сотрудников.
4.2. Что нужно для успешного описания процессов в масштабах организации?
Любой сотрудник вполне способен описать несложный процесс. Однако полученная схема будет лишь в некоторой степени отражать реальность. Можно долго спорить о преимуществах той или иной нотации (методики) для описания данного процесса. Нос точки зрения моделирования процессов в масштабах компании эти вопросы
213
Описание и регламентация процессов управления на всех
5. уровнях.
Анализ возможных изменений (реализация сценариев что
6. если) в модели организации 1) создание нового подразделения с передачей ему операций процессов других подразделений) ликвидация подразделения с передачей его процессов другим подразделениям.
Тиражирование стандартов деятельности (например, в фи. лиалы).
Выполнение внутреннего аудита. Подбор персонала (на основе подробной информации о выполняемых сотрудником процессах).
Обучение сотрудников. Автоматизация процессов. Анализ и улучшение деятельности. Управление знаниями о деятельности организации. Вовлечение руководителей и сотрудников подразделений
14. в работу по описанию и стандартизации деятельности орга- низации.
Развитие культуры процессного управления у сотрудников.
4.2. Что нужно для успешного описания процессов в масштабах организации?
Любой сотрудник вполне способен описать несложный процесс. Однако полученная схема будет лишь в некоторой степени отражать реальность. Можно долго спорить о преимуществах той или иной нотации (методики) для описания данного процесса. Нос точки зрения моделирования процессов в масштабах компании эти вопросы
214
Бизнес-процессы. Моделирование, внедрение, управление
и споры будут несущественны. Выбор нотации, как и другие частные вопросы, не определяет успех работы по описанию и регламентации процессов организации в целом. Эту задачу можно решить только в случае системного, комплексного подхода, учитывающего множество различных факторов.
Рассмотрим основные аспекты, которые должны знать и учитывать руководители при построении в организации системы работы по описанию (моделированию) бизнес-процессов.
4.2.1. Формулировка целей описания процессов
Прежде всего необходимо четко определить цели описания процессов. Нечеткость или неадекватность целей приведет к некорректному выбору средств их достижения. В результате деньги и время организации будут потрачены впустую.
Пример. В торговой компании среднего размера директор поставил задачу сотруднику затри месяца подробно описать шесть ее основных процессов. При этом конкретные требования к результату (формат описания, степень детализации процессов и т. д) установлены небыли. В итоге удалось описать лишь незначительную часть процессов, а сотрудник перешел работать в другую организацию. Очевидно, что цели описания процессов были поставлены руководителем некорректно.
Цели описания процессов должны быть четко сформулированы в проектном документе. Возможными целями описания могут быть:
анализ и последующая оптимизация процессов;
—
разработка регламентирующих документов;
—
подготовка к автоматизации процессов;
—
прочее.
—
В 2011 году компания BPTrends провела исследования в области моделирования бизнес-процессов. Респондентами стали представители почти 16 000 зарегистрированных участников сообщества
Глава 4. Описание бизнес-процессов организации и посетители соответствующего сайта (Северная Америка, Европа — 32% и т. д. Поскольку деятельность BPTrends охватывает весь диапазон вопросов, составляющих часть понятия
«бизнес-процесс», к исследованию были привлечены управленцы и практики, заинтересованные в комплексном подходе к процессно- му управлению Моделирование процессов — актуальный метод, используемый практиками в сфере процессного управления, чтобы получать, систематизировать и передавать информацию о бизнес-процессах. Модели процессов могут быть изображены на рабочей доске, бумаге или представлены в цифровой форме в различных видах программного обеспечения для их моделирования. Они могут быть как абстракциями, определяющими фазы деятельности, таки детализированными изображениями осуществленных шагов и принятых решений входе конкретной операции. Например, менеджер может нарисовать на листе бумаги три прямоугольника для представления трех фаз, через которые обычно проходит его организация входе аудита. Специалист по программному обеспечению может изобразить множество прямоугольников со стрелками и ромбами для точного отражения решений, которые требовались для одобрения нового кредитного счета. И то и другое можно назвать моделями процесса, поэтому в рамках этого исследования термин моделирование процесса использовался очень широко для возможности рассмотрения всех видов моделирования…»
В исследовании BPTrends приводится интересная диаграмма, представленная на рис. 4.2.1. По сути, на ней показаны цели моделирования (описания) бизнес-процессов.
На первом месте (81%) стоит пункт Вместе с реинжинирингом и совершенствованием процессов. Это означает, что около 81% компаний используют моделирование как средство для описания, анализа и оптимизации бизнес-процессов.
«бизнес-процесс», к исследованию были привлечены управленцы и практики, заинтересованные в комплексном подходе к процессно- му управлению Моделирование процессов — актуальный метод, используемый практиками в сфере процессного управления, чтобы получать, систематизировать и передавать информацию о бизнес-процессах. Модели процессов могут быть изображены на рабочей доске, бумаге или представлены в цифровой форме в различных видах программного обеспечения для их моделирования. Они могут быть как абстракциями, определяющими фазы деятельности, таки детализированными изображениями осуществленных шагов и принятых решений входе конкретной операции. Например, менеджер может нарисовать на листе бумаги три прямоугольника для представления трех фаз, через которые обычно проходит его организация входе аудита. Специалист по программному обеспечению может изобразить множество прямоугольников со стрелками и ромбами для точного отражения решений, которые требовались для одобрения нового кредитного счета. И то и другое можно назвать моделями процесса, поэтому в рамках этого исследования термин моделирование процесса использовался очень широко для возможности рассмотрения всех видов моделирования…»
В исследовании BPTrends приводится интересная диаграмма, представленная на рис. 4.2.1. По сути, на ней показаны цели моделирования (описания) бизнес-процессов.
На первом месте (81%) стоит пункт Вместе с реинжинирингом и совершенствованием процессов. Это означает, что около 81% компаний используют моделирование как средство для описания, анализа и оптимизации бизнес-процессов.
216
Бизнес-процессы. Моделирование, внедрение, управление
На втором месте — пункт Для передачи информации о процессе. Иными словами, это использование описания процессов для последующей регламентации, размещения информации о процессах на портале организации и т. п. Нотация моделирования процессов
Руководителям нужно определиться с требованиями к описанию процессов, в том числе выбрать нотации для создания моделей. Следует выявить внутренних потребителей и понять их запросы. Например, руководителям подразделений нужно будет использовать описания процессов для формирования регламентирующих документов. Департамент по работе с персоналом заинтересован в выгрузке из системы моделирования должностных инструкций. Важно понимать, что описание процесса в среде моделирования содержит гораздо больше информации, чем показано на его графической схеме независимо от нотации. Но именно эта информация необходима при регламентации, формировании отчетов и т. д.
При выборе нотации полезно обратить внимание наследующее. Если описание процессов делается для создания регламентирующих документов, то схемы процессов должны быть просты и интуитивно Как подготовку к внедрению ERP-систем
Как подготовку к внедрению Для удовлетворения требований к документированию бизнес-процессов, включая согласование
Как подготовку к разработке программного обеспечения
Как часть инициатив по преобразованию бизнеса
Для уточнения определенной совокупности деятельности
Для передачи информации о процессе
Вместе с реинжинирингом и совершенствованием процессов 20 40 60 80 Рис. 4.2.1. Как вы используете моделирование бизнес-процессов?
Глава 4. Описание бизнес-процессов организации
217
понятны сотрудникам организации, информативны при минимальном наборе используемых графических символов. Нет смысла усложнять графическое представление — полезную информацию вполне можно вывести в нормативно-методические документы в виде таблиц и текста. Выбранная нотация должна быть понятна большинству сотрудников без специального обучения и длительного освоения. Конечно, можно заставить людей описывать процессы в любых нотациях (например, в UML
*
) при помощи совершенно разных средств моделирования, но затраты на внедрение таких нотаций/систем обычно значительны. Чрезмерно сложная нотация и средство моделирования сделают методы процессного управления доступными для узкого круга профессионалов из отдела организационного развития или отдела, а преимущества процессного подхода не будут реализованы в полной мере.
Замечу, что если предполагается описывать процессы исключительно в целях последующей автоматизации, то лучше всего использовать нотацию BPMN
**
Сформулируем простые критерии для выбора нотации моделирования процессов на операционном уровне:
в нотации представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow поток работ);
быстрота и низкая трудоемкость создания графических схем для целей регламентации;
схемы процессов просты и понятны всем сотрудникам даже без специального обучения;
простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны — обучение можно проводить силами сотрудников отдела организационного развития);
схемы процессов являются кросс-функциональными, что удобно для описания сквозных процессов организации * Unify Modeling Language — унифицированный язык моделирования.
** Business Process Modeling Notation — нотация и модель бизнес-процессов.
217
понятны сотрудникам организации, информативны при минимальном наборе используемых графических символов. Нет смысла усложнять графическое представление — полезную информацию вполне можно вывести в нормативно-методические документы в виде таблиц и текста. Выбранная нотация должна быть понятна большинству сотрудников без специального обучения и длительного освоения. Конечно, можно заставить людей описывать процессы в любых нотациях (например, в UML
*
) при помощи совершенно разных средств моделирования, но затраты на внедрение таких нотаций/систем обычно значительны. Чрезмерно сложная нотация и средство моделирования сделают методы процессного управления доступными для узкого круга профессионалов из отдела организационного развития или отдела, а преимущества процессного подхода не будут реализованы в полной мере.
Замечу, что если предполагается описывать процессы исключительно в целях последующей автоматизации, то лучше всего использовать нотацию BPMN
**
Сформулируем простые критерии для выбора нотации моделирования процессов на операционном уровне:
в нотации представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow поток работ);
быстрота и низкая трудоемкость создания графических схем для целей регламентации;
схемы процессов просты и понятны всем сотрудникам даже без специального обучения;
простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны — обучение можно проводить силами сотрудников отдела организационного развития);
схемы процессов являются кросс-функциональными, что удобно для описания сквозных процессов организации * Unify Modeling Language — унифицированный язык моделирования.
** Business Process Modeling Notation — нотация и модель бизнес-процессов.
218
Бизнес-процессы. Моделирование, внедрение, управление. Репозиторий и среда моделирования процессов
Представьте, что вам поручили разработать регламент выполнения какого-то процесса компании. Ситуация складывается удачно — у вас стоит MS Visio. Вы создаете новый файл, начинаете рисовать схему процесса, затем сохраняете ее, включаете в регламент, согласуете его с руководителями и т. п. Через два месяца нужно сделать еще один документ по той же процедуре. Кроме вас еще несколько руководителей и специалистов компании время от времени мастерят регламенты процессов. В результате в организации появляется множество схем, описанных в различных форматах и инструментах. Они хаотично хранятся в файлах на компьютерах разных пользователей. Как можно оценить такое положение дел Неужели так работать удобно Скорее всего, нет. Сложившуюся ситуацию можно охарактеризовать так:
процессы моделируют разные сотрудники без всякой коорди-
—
нации;
единого стандарта моделирования процессов нет;
—
единого места для хранения схем процессов нет;
—
внесение изменений в регламентирующие документы требует ручной работы;
доступ сотрудников к информации по процессам затруднен;
—
информация, формализованная в схемах и описаниях процессов, быстро устаревает.
С ростом количества схем процессов ситуация становится угрожающей. Руководство компании понимает полезность описания, анализа и регламентации процессов, ноне готово развивать и поддерживать такую работу, осознавая запутанность существующей практики моделирования и регламентации процессов.
В таких условиях нужен электронный репозиторий бизнес- процессов, ведь нельзя с самой ценной для компании информацией обходиться как с мусором
Глава 4. Описание бизнес-процессов организации
219
А если в вашей компании полный порядок, означает ли это, что:
создан и используется единый стандарт для описания бизнес-
—
процессов;
все схемы процессов хранятся в специализированной базе
—
данных;
выполняется описание процессов в специализированной системе с последующей автоматической генерацией (выгрузкой) регламентирующих документов вили в базе данных в привязке к процессам можно хранить любую нужную информацию (формы документов, показатели, фотографии, документы с техническими характеристиками в формате и т. д.);
обеспечен легкий и быстрый доступ сотрудников к информации по процессам (например, через внутренний портал)?
Ответы да говорят о том, что в компании создан электронный
репозиторий бизнес-процессов. Он может быть сформирован с использованием среды моделирования бизнес-процессов. Итак, репозиторий — это специализированный программный продукт, позволяющий создавать, хранить, актуализировать и использовать любую информацию о бизнес-процессах компании.
Безусловно, репозиторий бизнес-процессов полезен — это база знаний о деятельности компании. Если она будет полной и актуальной, то обеспечит возможность:
быстро актуализировать модели бизнес-процессов;
—
с минимальными трудозатратами формировать регламентирующие документы:
регламенты выполнения бизнес-процессов;
•
регламенты управления бизнес-процессами;
•
219
А если в вашей компании полный порядок, означает ли это, что:
создан и используется единый стандарт для описания бизнес-
—
процессов;
все схемы процессов хранятся в специализированной базе
—
данных;
выполняется описание процессов в специализированной системе с последующей автоматической генерацией (выгрузкой) регламентирующих документов вили в базе данных в привязке к процессам можно хранить любую нужную информацию (формы документов, показатели, фотографии, документы с техническими характеристиками в формате и т. д.);
обеспечен легкий и быстрый доступ сотрудников к информации по процессам (например, через внутренний портал)?
Ответы да говорят о том, что в компании создан электронный
репозиторий бизнес-процессов. Он может быть сформирован с использованием среды моделирования бизнес-процессов. Итак, репозиторий — это специализированный программный продукт, позволяющий создавать, хранить, актуализировать и использовать любую информацию о бизнес-процессах компании.
Безусловно, репозиторий бизнес-процессов полезен — это база знаний о деятельности компании. Если она будет полной и актуальной, то обеспечит возможность:
быстро актуализировать модели бизнес-процессов;
—
с минимальными трудозатратами формировать регламентирующие документы:
регламенты выполнения бизнес-процессов;
•
регламенты управления бизнес-процессами;
•
220
Бизнес-процессы. Моделирование, внедрение, управление
технологические инструкции;
•
положения о подразделениях;
•
должностные инструкции сотрудников;
•
прочее;
•
быстрый и легкий доступ к информации по процессам через
—
интерфейс;
возможность использовать накопленные знания для автома-
—
тизации;
возможность использовать информацию о процессах для обучения новых сотрудников;
прочее.
—
Если у компании несколько филиалов, тов репозитории можно накапливать информацию и обмениваться опытом эффективного выполнения процессов в разных регионах и городах.
Создание электронного репозитория бизнес-процессов — это инвестиция в будущее компании. Почему Судите сами внедряя репо- зиторий, вы:
выполняете описание, анализ и улучшаете бизнес-процессы
—
организации;
приучаете руководителей и специалистов мыслить категориями процессов (другими словами, создаете в компании культуру процессного управления);
делаете систему управления прозрачной;
—
получаете возможность со временем избавиться от незаменимых персонажей (разгерметизировать деятельность отделов и сотрудников).
Особенно интересно связать процессы репозитория с процессами, выполняемыми в различных автоматизированных системах. Вызнаете, например, что ваша система поддерживает определенные
Глава 4. Описание бизнес-процессов организации
221
функции. Но как, в каких бизнес-процессах, когда, кто и с какой эффективностью их выполняет Модели бизнес-процессов в репозито- рии могут прояснить ситуацию. Сразу станет понятно, какие функции системы в каких бизнес-процессах применяются.
Репозиторий предоставляет широкий спектр возможностей. Но их использование требует упорной работы по внедрению про- цессных технологий. Успех зависит от последовательного и твердого желания собственников и топ-менеджмента компании использовать эти технологии.
При выборе среды моделирования, которая позволит создать ре- позиторий бизнес-процессов организации, важно обратить внимание наследующие ее возможности:
простота и интуитивная понятность интерфейса;
—
легкость моделирования бизнес-процессов;
—
хранение информации о деятельности компании в базе данных (например, в СУБД MS SQL расширение объектной модели для описания различных атрибутов процессов и т. д.;
размещение моделей на портале организации;
—
работа в многопользовательском режиме.
—
Пример. Вы описываете процесс обслуживания оборудования. Для ряда операций нужно вывести в регламент текстовое описание, фотографии агрегатов, список используемых расходных материалов и т. д. Это легко сделать, используя возможности среды моделирования. После внесения информации в систему готовый регламент обслуживания оборудования генерируется в виде файла MS Word засчитанные минуты.
Теперь предположим, что при выполнении технического обслуживания отмечена возможность более быстрого и технологичного выполнения какой-то операции. Мастери механик обсуждают эту ситуацию, формализуют знания и заносят информацию
221
функции. Но как, в каких бизнес-процессах, когда, кто и с какой эффективностью их выполняет Модели бизнес-процессов в репозито- рии могут прояснить ситуацию. Сразу станет понятно, какие функции системы в каких бизнес-процессах применяются.
Репозиторий предоставляет широкий спектр возможностей. Но их использование требует упорной работы по внедрению про- цессных технологий. Успех зависит от последовательного и твердого желания собственников и топ-менеджмента компании использовать эти технологии.
При выборе среды моделирования, которая позволит создать ре- позиторий бизнес-процессов организации, важно обратить внимание наследующие ее возможности:
простота и интуитивная понятность интерфейса;
—
легкость моделирования бизнес-процессов;
—
хранение информации о деятельности компании в базе данных (например, в СУБД MS SQL расширение объектной модели для описания различных атрибутов процессов и т. д.;
размещение моделей на портале организации;
—
работа в многопользовательском режиме.
—
Пример. Вы описываете процесс обслуживания оборудования. Для ряда операций нужно вывести в регламент текстовое описание, фотографии агрегатов, список используемых расходных материалов и т. д. Это легко сделать, используя возможности среды моделирования. После внесения информации в систему готовый регламент обслуживания оборудования генерируется в виде файла MS Word засчитанные минуты.
Теперь предположим, что при выполнении технического обслуживания отмечена возможность более быстрого и технологичного выполнения какой-то операции. Мастери механик обсуждают эту ситуацию, формализуют знания и заносят информацию
222
Бизнес-процессы. Моделирование, внедрение, управление
в репозиторий процессов. В дальнейшем сотрудники другой смены других филиалов, новые сотрудники и т. д) смогут не только ознакомиться с регламентом выполнения процесса, но и посмотреть рекомендации по наиболее эффективному способу выполнения работы. Со временем этот способ можно будет внести в регламент в качестве обязательного.
Описанная ситуация годится для любого бизнес-процесса независимо от объекта деятельности.
Говоря о практическом использовании репозитория, следует отметить, что:
для поддержания репозитория требуются квалифицированные специалисты;
работать с репозиторием нужно по определенным, четко установленным правилам.
Качество информации в репозитории зависит от квалификации сотрудников, моделирующих процессы. Кроме того, эту информацию нужно постоянно актуализировать.
Руководство компании должно понимать можно купить программу для бизнес-моделирования, потратив некоторую сумму, но купить репозиторий нельзя, его нужно создать и поддерживать силами организации. Приведу аналогии если не делать ремонт, то крыша склада прохудится, а товар испортится. Если не менять изнашивающиеся детали оборудования, то оно встанет. Если не использовать на практике и не актуализировать информацию о бизнес- процессах в репозитории, то он быстро станет ненужным хранилищем мертвого массива данных.
Важно знать основные возможности среды моделирования процессов, которую предполагается использовать для создания репози- тория. Современные программные продукты, предназначенные для описания процессов, как правило, хранят информацию в промышленной базе данных (например, в СУБД MS SQL-Server). Эти системы позволяют создавать сложные, иерархические справочники процессов,
Глава 4. Описание бизнес-процессов организации
223
подразделений и должностей, документов. С системой могут одновременно работать несколько пользователей. Информация о внесенных изменениях сохраняется.
При помощи среды моделирования процессов формируется так называемая объектная модель организации. Она должна постоянно поддерживаться в актуальном состоянии. Ценность модели в том, что она позволяет формировать регламентирующие документы разного типа и другие необходимые отчеты, дающие ответ почти на любой вопрос о деятельности организации. Модель деятельности компании становится прозрачной для руководителей. Сотрудникам доступна информация о процессах (графические схемы, описания входов/выходов, требования к сроками т. д.).
Потенциал среды моделирования должен быть адекватен поставленным задачам. У более сложных и дорогих систем больше возможностей, ноне все они востребованы в организации, в том числе из-за отсутствия подходящих специалистов. Даже в самих компаниях, поставляющих системы моделирования, количество профессионалов, глубоко разбирающихся в функционале системы и умеющих его использовать, весьма ограничено. Найти таких специалистов на рынке непросто. Поэтому мощные функциональные возможности среды моделирования могут оказаться ненужными.
Но и покупка слишком простого или морально устаревшего программного обеспечения для моделирования процессов может привести к снижению эффективности деятельности по описанию и регламентации процессов организации.
В исследовании BPTrends приводится любопытная диаграмма см. рис. 4.2.2) по свойствам среды моделирования процессов, наиболее важных для пользователей.
На первом месте — Способность сохранять модели и данные о процессах в репозитории». Речь идет о базе данных, в которой хранится комплексная модель организации. На втором месте упомянута возможность создавать сложные иерархические модели процессов. На третьем — использование стандартной нотации или языка моделирования
Бизнес-процессы. Моделирование, внедрение, управление
В современных компаниях среда моделирования бизнес- процессов — один из базовых инструментов, обеспечивающих развитие и совершенствование системы управления.
Обратите внимание, что только 10% опрошенных считают важной способность легко переходить от модели к коду программного обеспечения. Для остальных важнее оказались другие требования. Например, 36% указали на Способность создавать простые модели процессов, а 56% — на Способность сохранять модели и данные о процессах в репозитории». Эти факты говорят о том, что компаниям, которые используют моделирование процессов для анализа, оптимизации и документирования (регламентации, нужны:
простая, но стандартная нотация моделирования;
—
надежный инструмент, позволяющий создавать сложные, многоуровневые модели процессов и хранить их в репозито- рии (базе данных. Методики описания процессов
Чтобы успешно выполнить проект по созданию системы работы по описанию процессов, нужны нормативно-методические документы (методики, стандарты, среди которых 10 20 40 30 60 50 Способность сохранять модели и данные о процессах в репозитарии
Способность создавать комплексные (вложенные) модели процессов
Поддержка стандартной нотации или языка моделирования
Способность размещать модели на сайте для более широкого использования
Способность создавать простые модели процессов
Способность сохранять информацию о ролях, затратах и другие данные, связанные с деятельностью
Способность выполнять имитацию
Способность распечатывать модели
Способность легко переходить от модели к коду программного обеспечения
Другое, пожалуйста, уточните
Рис. 4.2.2. Какие три свойства средств моделирования процессов высчитаете самыми важными
223
подразделений и должностей, документов. С системой могут одновременно работать несколько пользователей. Информация о внесенных изменениях сохраняется.
При помощи среды моделирования процессов формируется так называемая объектная модель организации. Она должна постоянно поддерживаться в актуальном состоянии. Ценность модели в том, что она позволяет формировать регламентирующие документы разного типа и другие необходимые отчеты, дающие ответ почти на любой вопрос о деятельности организации. Модель деятельности компании становится прозрачной для руководителей. Сотрудникам доступна информация о процессах (графические схемы, описания входов/выходов, требования к сроками т. д.).
Потенциал среды моделирования должен быть адекватен поставленным задачам. У более сложных и дорогих систем больше возможностей, ноне все они востребованы в организации, в том числе из-за отсутствия подходящих специалистов. Даже в самих компаниях, поставляющих системы моделирования, количество профессионалов, глубоко разбирающихся в функционале системы и умеющих его использовать, весьма ограничено. Найти таких специалистов на рынке непросто. Поэтому мощные функциональные возможности среды моделирования могут оказаться ненужными.
Но и покупка слишком простого или морально устаревшего программного обеспечения для моделирования процессов может привести к снижению эффективности деятельности по описанию и регламентации процессов организации.
В исследовании BPTrends приводится любопытная диаграмма см. рис. 4.2.2) по свойствам среды моделирования процессов, наиболее важных для пользователей.
На первом месте — Способность сохранять модели и данные о процессах в репозитории». Речь идет о базе данных, в которой хранится комплексная модель организации. На втором месте упомянута возможность создавать сложные иерархические модели процессов. На третьем — использование стандартной нотации или языка моделирования
Бизнес-процессы. Моделирование, внедрение, управление
В современных компаниях среда моделирования бизнес- процессов — один из базовых инструментов, обеспечивающих развитие и совершенствование системы управления.
Обратите внимание, что только 10% опрошенных считают важной способность легко переходить от модели к коду программного обеспечения. Для остальных важнее оказались другие требования. Например, 36% указали на Способность создавать простые модели процессов, а 56% — на Способность сохранять модели и данные о процессах в репозитории». Эти факты говорят о том, что компаниям, которые используют моделирование процессов для анализа, оптимизации и документирования (регламентации, нужны:
простая, но стандартная нотация моделирования;
—
надежный инструмент, позволяющий создавать сложные, многоуровневые модели процессов и хранить их в репозито- рии (базе данных. Методики описания процессов
Чтобы успешно выполнить проект по созданию системы работы по описанию процессов, нужны нормативно-методические документы (методики, стандарты, среди которых 10 20 40 30 60 50 Способность сохранять модели и данные о процессах в репозитарии
Способность создавать комплексные (вложенные) модели процессов
Поддержка стандартной нотации или языка моделирования
Способность размещать модели на сайте для более широкого использования
Способность создавать простые модели процессов
Способность сохранять информацию о ролях, затратах и другие данные, связанные с деятельностью
Способность выполнять имитацию
Способность распечатывать модели
Способность легко переходить от модели к коду программного обеспечения
Другое, пожалуйста, уточните
Рис. 4.2.2. Какие три свойства средств моделирования процессов высчитаете самыми важными
Глава 4. Описание бизнес-процессов организации
225
стандарт описания бизнес-процессов (Соглашение о моделировании бизнес-процессов»);
стандарт управления изменениями модели организации;
—
инструкция по администрированию среды моделирования;
—
прочее.
—
К сожалению, вопрос методического обеспечения проекта не всегда учитывается руководителями, принимающими решения о приобретении и внедрении среды моделирования процессов. Наличие необходимых специалистов
Важнейший фактор успешного внедрения — наличие в организации нескольких специалистов, которые могут:
разрабатывать и изменять систему процессов организации;
—
согласовывать процессы по входам/выходам;
—
проводить интервью, получать и структурировать информацию по процессам;
описывать процессы в нужных нотациях в среде моделиро-
—
вания;
настраивать среду моделирования, в том числе формировать шаблоны отчетов для выгрузки регламентирующих документов;
управлять изменениями объектной модели организации;
—
обучать сотрудников организации принципами методам описания процессов;
прочее.
—
Разработка и внедрение в организации системы описания процессов довольно сложный и длительный (3–6 месяцев) проект, для успешного выполнения которого руководители организации должны выделить адекватные человеческие и финансовые ресурсы
226
Бизнес-процессы. Моделирование, внедрение, управление
Пример. Вторгово-производственной компании среднего размера приняли решение описывать бизнес-процессы. После проведения формального тендера приобрели среду моделирования процессов. Одному из сотрудников организации было поручено ее использовать. На методическое обеспечение, обучение персонала, настройку системы (справочники, отчеты) денег не выделили. В результате уполномоченный сотрудник в течение нескольких месяцев пытался описывать процессы на свой страхи риск. Полученные модели оказались весьма сомнительного качества. Кроме того, попытка документировать процессы окончилась неудачей, поскольку а) заранее небыли продуманы требования к информации, которую следовало использовать в описаниях процессов б) у сотрудника, работающего со средой моделирования, не хватило квалификации для настройки необходимых шаблонов отчетов. Объектная модель организации
В этом параграфе мы обсудим вопрос создания так называемой объектной модели организации.
Моделирование организации предполагает определение и подробное описание таких объектов, как:
процессы;
—
владельцы/исполнители процессов (подразделения, должности, бизнес-роли);
ресурсы: документы, файлы, ТМЦ
—
*
;
инициирующие и завершающие события;
—
термины;
—
цели и показатели деятельности;
—
физические лица, занимающие соответствующие должности;
—
прочее.
—
* ТМЦ — товарно-материальные ценности
225
стандарт описания бизнес-процессов (Соглашение о моделировании бизнес-процессов»);
стандарт управления изменениями модели организации;
—
инструкция по администрированию среды моделирования;
—
прочее.
—
К сожалению, вопрос методического обеспечения проекта не всегда учитывается руководителями, принимающими решения о приобретении и внедрении среды моделирования процессов. Наличие необходимых специалистов
Важнейший фактор успешного внедрения — наличие в организации нескольких специалистов, которые могут:
разрабатывать и изменять систему процессов организации;
—
согласовывать процессы по входам/выходам;
—
проводить интервью, получать и структурировать информацию по процессам;
описывать процессы в нужных нотациях в среде моделиро-
—
вания;
настраивать среду моделирования, в том числе формировать шаблоны отчетов для выгрузки регламентирующих документов;
управлять изменениями объектной модели организации;
—
обучать сотрудников организации принципами методам описания процессов;
прочее.
—
Разработка и внедрение в организации системы описания процессов довольно сложный и длительный (3–6 месяцев) проект, для успешного выполнения которого руководители организации должны выделить адекватные человеческие и финансовые ресурсы
226
Бизнес-процессы. Моделирование, внедрение, управление
Пример. Вторгово-производственной компании среднего размера приняли решение описывать бизнес-процессы. После проведения формального тендера приобрели среду моделирования процессов. Одному из сотрудников организации было поручено ее использовать. На методическое обеспечение, обучение персонала, настройку системы (справочники, отчеты) денег не выделили. В результате уполномоченный сотрудник в течение нескольких месяцев пытался описывать процессы на свой страхи риск. Полученные модели оказались весьма сомнительного качества. Кроме того, попытка документировать процессы окончилась неудачей, поскольку а) заранее небыли продуманы требования к информации, которую следовало использовать в описаниях процессов б) у сотрудника, работающего со средой моделирования, не хватило квалификации для настройки необходимых шаблонов отчетов. Объектная модель организации
В этом параграфе мы обсудим вопрос создания так называемой объектной модели организации.
Моделирование организации предполагает определение и подробное описание таких объектов, как:
процессы;
—
владельцы/исполнители процессов (подразделения, должности, бизнес-роли);
ресурсы: документы, файлы, ТМЦ
—
*
;
инициирующие и завершающие события;
—
термины;
—
цели и показатели деятельности;
—
физические лица, занимающие соответствующие должности;
—
прочее.
—
* ТМЦ — товарно-материальные ценности
Глава 4. Описание бизнес-процессов организации
227
Каждый из этих объектов обладает рядом атрибутов. Например, для него могут быть определены название, тип, текстовое описание, требования к срокам.
По ходу моделирования объекты контактируют между собой, и эти связи также могут иметь определенный тип и соответствующие атрибуты.
В результате моделирования появляется объектная модель организации упорядоченная совокупность объектов, связанных между собой определенными способами.
Четкая структура этой модели и наличие связей позволяют в дальнейшем получать любые регламентирующие документы (регламенты, инструкции, положения) и необходимые отчеты.
Объектная модель реализуется только в виде соответствующей базы данных. Ее структуру, разработанную для решения задач бизнес- моделирования, можно называть метамоделью
**
организации.
На рис. 4.3.1 показано, как в результате деятельности по моделированию с использованием метамодели получается комплексная объектная модель организации * В некоторых западных подходах модель такого типа называют Enterprise
Architecture.
** В среде моделирования Business Studio используется следующее определение метаданные — описательная информация о структуре и смысле данных.
Деятельность по моделированию
Объектная модель организации
Метамодель организации
Информация о деятельности организации
Таблица
Таблица
Таблица
Рис. 4.3.1. Связь объектной модели и метамодели организации
228
Бизнес-процессы. Моделирование, внедрение, управление
Метамодель организации, по сути, — это совокупность связанных таблиц СУБД (системы управления базы данных, иона может расширяться по мере необходимости. Например, для такого класса объектов, как должность, можно дополнительно определить следующие атрибуты:
наименование должности;
—
номер грейда;
—
лицо, назначающее сотрудника на данную должность;
—
лицо, осуществляющее представление на данную должность;
—
показатели оценки эффективности;
—
прочее.
—
Для успешного внедрения системы описания процессов нужны квалифицированные специалисты, способные грамотного осуществлять изменения (доработки) в метамодели организации.
Замечу, что далеко не в каждой среде моделирования есть средства управления метамоделью. Но, как показывает практика, эта возможность очень ценна и востребована при практическом описании процессов организации. Архитектура типовой среды моделирования процессов
Сейчас на рынке представлено множество программных продуктов для моделирования деятельности организации. Эти продукты относятся к так называемым средствам Business Process Architecture или
Enterprise Architecture, то есть программным инструментам, предназначенным для проектирования бизнес-процессов и бизнес-архитек туры компании. Руководителями специалистам, внедряющим процессный подход, важно понимать общую архитектуру систем такого класса.
Рассмотрим архитектуру типовой среды моделирования процессов, представленную на рис. 4.4.1. Такая среда, как правило, имеет
227
Каждый из этих объектов обладает рядом атрибутов. Например, для него могут быть определены название, тип, текстовое описание, требования к срокам.
По ходу моделирования объекты контактируют между собой, и эти связи также могут иметь определенный тип и соответствующие атрибуты.
В результате моделирования появляется объектная модель организации упорядоченная совокупность объектов, связанных между собой определенными способами.
Четкая структура этой модели и наличие связей позволяют в дальнейшем получать любые регламентирующие документы (регламенты, инструкции, положения) и необходимые отчеты.
Объектная модель реализуется только в виде соответствующей базы данных. Ее структуру, разработанную для решения задач бизнес- моделирования, можно называть метамоделью
**
организации.
На рис. 4.3.1 показано, как в результате деятельности по моделированию с использованием метамодели получается комплексная объектная модель организации * В некоторых западных подходах модель такого типа называют Enterprise
Architecture.
** В среде моделирования Business Studio используется следующее определение метаданные — описательная информация о структуре и смысле данных.
Деятельность по моделированию
Объектная модель организации
Метамодель организации
Информация о деятельности организации
Таблица
Таблица
Таблица
Рис. 4.3.1. Связь объектной модели и метамодели организации
228
Бизнес-процессы. Моделирование, внедрение, управление
Метамодель организации, по сути, — это совокупность связанных таблиц СУБД (системы управления базы данных, иона может расширяться по мере необходимости. Например, для такого класса объектов, как должность, можно дополнительно определить следующие атрибуты:
наименование должности;
—
номер грейда;
—
лицо, назначающее сотрудника на данную должность;
—
лицо, осуществляющее представление на данную должность;
—
показатели оценки эффективности;
—
прочее.
—
Для успешного внедрения системы описания процессов нужны квалифицированные специалисты, способные грамотного осуществлять изменения (доработки) в метамодели организации.
Замечу, что далеко не в каждой среде моделирования есть средства управления метамоделью. Но, как показывает практика, эта возможность очень ценна и востребована при практическом описании процессов организации. Архитектура типовой среды моделирования процессов
Сейчас на рынке представлено множество программных продуктов для моделирования деятельности организации. Эти продукты относятся к так называемым средствам Business Process Architecture или
Enterprise Architecture, то есть программным инструментам, предназначенным для проектирования бизнес-процессов и бизнес-архитек туры компании. Руководителями специалистам, внедряющим процессный подход, важно понимать общую архитектуру систем такого класса.
Рассмотрим архитектуру типовой среды моделирования процессов, представленную на рис. 4.4.1. Такая среда, как правило, имеет
Глава 4. Описание бизнес-процессов организации
229
модульную структуру, которая определяется соответствующими сервисами. В конкретных системах сервисы могут объединяться в рамках единых программных решений, а также существовать и использоваться по отдельности в виде модулей.
Информация о деятельности организации (справочники процессов, подразделений, документов, схемы процессов) хранится в промышленной базе данных, например MS SQL Server. Есть отдельный сервис, который используется для администрирования создания/
изменения/архивирования баз данных, создания новых пользователей, назначения прав доступа и т. д.
Сервис управления метамоделью — важнейший инструмент бизнес-моделирования. Он позволяет расширять метамодель, предлагаемую поставщиком системы, и создавать новые списки, перечисления, атрибуты для существующих классов объектов. В некоторых системах предусмотрена возможность определять новые классы объектов и связей между ними. Фактически в такой системе Сервис формирования отчетов
Сервис администрирования базы данных
Сервис управления метамоделью
Сервис описания процессов
Сервис выгрузки моделей в Сервис администрирования
Сервис анализа бизнес-процессов
База данных SQL Рис. 4.4.1. Архитектура типовой среды моделирования процессов
230
Бизнес-процессы. Моделирование, внедрение, управление
доступно спроектировать любую нотацию, которая может потребоваться в организации.
Возможность расширения метамодели важна для полного и адекватного моделирования, решения практических задач, возникающих у разных групп пользователей внутри организации.
Основной сервис среды моделирования — сервис описания, где можно:
создавать различные справочники:
—
процессов;
•
подразделений;
•
должностей;
•
документов;
•
терминов;
•
прочее;
•
формировать схемы:
—
процессов;
•
организационных структур;
•
прочее
•
**
;
описывать объекты модели:
—
заполнять текстовые поля например, указывать название процесса, его начало, завершение, требования к срокам);
формировать списки например, указывать должностных лиц, которые согласуют требования к выполнению процесса);
выбирать нужные типы например, указывать тип подразделения департамент или «отдел»);
задавать количественные параметры например, номер
грейда, количество ставок на должности или среднее время выполнения процесса);
прочее;
•
* Условное название модуля ** Зависит от функциональных возможностей конкретной среды моделирования
229
модульную структуру, которая определяется соответствующими сервисами. В конкретных системах сервисы могут объединяться в рамках единых программных решений, а также существовать и использоваться по отдельности в виде модулей.
Информация о деятельности организации (справочники процессов, подразделений, документов, схемы процессов) хранится в промышленной базе данных, например MS SQL Server. Есть отдельный сервис, который используется для администрирования создания/
изменения/архивирования баз данных, создания новых пользователей, назначения прав доступа и т. д.
Сервис управления метамоделью — важнейший инструмент бизнес-моделирования. Он позволяет расширять метамодель, предлагаемую поставщиком системы, и создавать новые списки, перечисления, атрибуты для существующих классов объектов. В некоторых системах предусмотрена возможность определять новые классы объектов и связей между ними. Фактически в такой системе Сервис формирования отчетов
Сервис администрирования базы данных
Сервис управления метамоделью
Сервис описания процессов
Сервис выгрузки моделей в Сервис администрирования
Сервис анализа бизнес-процессов
База данных SQL Рис. 4.4.1. Архитектура типовой среды моделирования процессов
230
Бизнес-процессы. Моделирование, внедрение, управление
доступно спроектировать любую нотацию, которая может потребоваться в организации.
Возможность расширения метамодели важна для полного и адекватного моделирования, решения практических задач, возникающих у разных групп пользователей внутри организации.
Основной сервис среды моделирования — сервис описания, где можно:
создавать различные справочники:
—
процессов;
•
подразделений;
•
должностей;
•
документов;
•
терминов;
•
прочее;
•
формировать схемы:
—
процессов;
•
организационных структур;
•
прочее
•
**
;
описывать объекты модели:
—
заполнять текстовые поля например, указывать название процесса, его начало, завершение, требования к срокам);
формировать списки например, указывать должностных лиц, которые согласуют требования к выполнению процесса);
выбирать нужные типы например, указывать тип подразделения департамент или «отдел»);
задавать количественные параметры например, номер
грейда, количество ставок на должности или среднее время выполнения процесса);
прочее;
•
* Условное название модуля ** Зависит от функциональных возможностей конкретной среды моделирования
Глава 4. Описание бизнес-процессов организации
231
формировать отчеты:
—
выгружать регламентирующие документы регламенты процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции);
выгружать другие специализированные отчеты например, отчет по движению документов — где создается, кем согласуется, кем утверждается и т. п.);
осуществлять анализ и изменение объектной модели:
—
создавать/корректировать/удалять процессы, подразделения, документы;
переназначать исполнителей процессов;
•
выявлять процессы без назначенных исполнителей;
•
выявлять документы, которые никто не использует;
•
прочее.
•
Как правило, основные пользователи сервиса описания процессов квалифицированные бизнес-аналитики, которые проводят интервью, структурируют информацию и заносят ее в систему в виде различных моделей. В некоторых случаях руководство организации принимает решение вовлекать в работу сотрудников подразделений, которые также используют часть функциональных возможностей в рамках своих полномочий.
При выборе системы руководителям компаний стоит уделить серьезное внимание анализу функциональных возможностей и удобства использования модуля описания процессов. Этот аспект важнее, чем выбор той или иной нотации моделирования. Рекомендуется попробовать все интересующие системы, описав в них один- два пилотных процесса.
Для управления командной работой служит сервис администрирования, в рамках которого:
выполняются настройки интерфейса системы;
—
выполняются настройки ряда справочников;
—
создаются/редактируются группы пользователей системы
232
Бизнес-процессы. Моделирование, внедрение, управление
определяются права для групп пользователей и отдельных
—
пользователей;
выполняются настройки, необходимые для отслеживания изменений в системе;
прочее.
—
Сервис формирования отчетов служит для разработки шаблонов различных отчетов (генератор отчетов. При помощи определенного функционала (в системах это может быть реализовано по-разному) квалифицированный пользователь проектирует запрос к базе данных и определяет формат вывода информации в документ MS Word или MS Excel. При построении отчета его тестируют на реальной или специально подготовленной для этого объектной модели. Готовые отчеты доступны конечным пользователям системы. Из системы можно выгружать готовые к согласованию и утверждению нормативно-методические документы (регламенты, положения, инструкции) и другие нужные в практической работе документы.
При выборе системы руководитель должен выполнить анализ сервиса формирования отчетов. Лучше выбирать такую систему, генератор отчетов которой легко освоит не только программист специалист по запросам к СУБД и написанию кода, но и обычный бизнес-аналитик.
Очень полезен сервис выгрузки моделей в формат. Он используется для размещения моделей процессов на интранет- или интернет-сервере организации. Все сотрудники (имеющие соответствующие права) могут оперативно просматривать данные на этом сервере, то есть вся регламентирующая информация по процессам становится доступной рядовому персоналу.
Анализ процессов выполняется на сервисе анализа. Как правило, он дает возможность проводить имитационное моделирование процессов, анализировать затраты и т. д.
Современная среда моделирования бизнес-процессов — это сложный пакет программных продуктов, для успешного внедрения которого организации нужны сотрудники с нужной компетенцией и опытом
238
Бизнес-процессы. Моделирование, внедрение, управление
(например, в IDEF
0
) — удел узкого круга бизнес-аналитиков. В лучшем случае руководители используют диаграмму первого уровня, которую размещают на стенде с нормативно-методической документацией. Модели процессов на операционном уровне
В этом параграфе мы рассмотрим модели процессов на операционном уровне. Они отображают последовательность выполнения операций процесса (подпроцессов) во времени. Их обычно называют модели Work Сейчас существует множество нотаций типа Work Flow, при помощи которых можно описывать процессы операционного уровня. Рассмотрим основу формирования моделей и некоторые важные аспекты их применения. Нотации типа Work На рис. 4.6.1 показаны основные элементы, которые используются практически во всех современных нотациях Work Flow. Можно выделить пять основных:
События.
1. Операторы логики (по-другому их называют блоки решения,
2. ветвления/развилки, шлюзы/гейтвеи
**
).
Операции процесса. Стрелки типа Связь предшествования. Стрелки типа Поток объектов. События служат для определения границ процесса. Они могут указывать на его начало и завершение. Кроме того, возможны промежуточные события, возникающие походу выполнения процесса. Примеры именования событий Поступила заявка клиента на отгрузку
* Work flow — поток работ (англ ** Gateway — ворота, шлюз (англ.
240
Бизнес-процессы. Моделирование, внедрение, управление
При использовании логического оператора исключающее ИЛИ (ситуация 2) после операции 1 выполняется одна из двух операций — 2 или При использовании логического оператора неисключающее ИЛИ (ситуация 3) после операции 1 выполняется операция 2, либо операция 3, либо операции 2 и Условные обозначения для операций процесса (задач, действий, функций) выглядят практически одинаково во всех нотациях типа
Work Рис. 4.6.2. Использование операторов логики
Ситуация После выполнения операции 1 выполняются операция 2 и операция Операция Операция Операция Логический оператор «и»
«и»
Ситуация После выполнения операции 1 выполняется либо операция 2, либо операция Операция Операция Операция Логический оператор исключающее «или»
«или»
Ситуация После выполнения операции 1 выполняется либо операция 2, либо операция 3, либо обе операции — 2 и Операция Операция Операция Логический оператор неисключающее «или»
«или»
231
формировать отчеты:
—
выгружать регламентирующие документы регламенты процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции);
выгружать другие специализированные отчеты например, отчет по движению документов — где создается, кем согласуется, кем утверждается и т. п.);
осуществлять анализ и изменение объектной модели:
—
создавать/корректировать/удалять процессы, подразделения, документы;
переназначать исполнителей процессов;
•
выявлять процессы без назначенных исполнителей;
•
выявлять документы, которые никто не использует;
•
прочее.
•
Как правило, основные пользователи сервиса описания процессов квалифицированные бизнес-аналитики, которые проводят интервью, структурируют информацию и заносят ее в систему в виде различных моделей. В некоторых случаях руководство организации принимает решение вовлекать в работу сотрудников подразделений, которые также используют часть функциональных возможностей в рамках своих полномочий.
При выборе системы руководителям компаний стоит уделить серьезное внимание анализу функциональных возможностей и удобства использования модуля описания процессов. Этот аспект важнее, чем выбор той или иной нотации моделирования. Рекомендуется попробовать все интересующие системы, описав в них один- два пилотных процесса.
Для управления командной работой служит сервис администрирования, в рамках которого:
выполняются настройки интерфейса системы;
—
выполняются настройки ряда справочников;
—
создаются/редактируются группы пользователей системы
232
Бизнес-процессы. Моделирование, внедрение, управление
определяются права для групп пользователей и отдельных
—
пользователей;
выполняются настройки, необходимые для отслеживания изменений в системе;
прочее.
—
Сервис формирования отчетов служит для разработки шаблонов различных отчетов (генератор отчетов. При помощи определенного функционала (в системах это может быть реализовано по-разному) квалифицированный пользователь проектирует запрос к базе данных и определяет формат вывода информации в документ MS Word или MS Excel. При построении отчета его тестируют на реальной или специально подготовленной для этого объектной модели. Готовые отчеты доступны конечным пользователям системы. Из системы можно выгружать готовые к согласованию и утверждению нормативно-методические документы (регламенты, положения, инструкции) и другие нужные в практической работе документы.
При выборе системы руководитель должен выполнить анализ сервиса формирования отчетов. Лучше выбирать такую систему, генератор отчетов которой легко освоит не только программист специалист по запросам к СУБД и написанию кода, но и обычный бизнес-аналитик.
Очень полезен сервис выгрузки моделей в формат. Он используется для размещения моделей процессов на интранет- или интернет-сервере организации. Все сотрудники (имеющие соответствующие права) могут оперативно просматривать данные на этом сервере, то есть вся регламентирующая информация по процессам становится доступной рядовому персоналу.
Анализ процессов выполняется на сервисе анализа. Как правило, он дает возможность проводить имитационное моделирование процессов, анализировать затраты и т. д.
Современная среда моделирования бизнес-процессов — это сложный пакет программных продуктов, для успешного внедрения которого организации нужны сотрудники с нужной компетенцией и опытом
Глава 4. Описание бизнес-процессов организации 4.5. Структурные модели процессов организации
В этом параграфе мы рассмотрим особенности использования структурных моделей при описании процессов организации.
Под структурной будем понимать модель, включающую в себя упорядоченный по определенному принципу набор процессов (групп процессов) с указанием основных связей между ними.
Основное назначение структурной модели — показать, как устроен бизнес организации, раскрыть информацию об основных группах процессов и их взаимосвязях. Структурная модель не показывает последовательность выполнения процессов во времени.
Структурные модели можно использовать локально (не в системе процессов организации) для схематичного описания состава процессов, декомпозированных наследующий уровень. Например, такая структурная схема может быть представлена в регламенте двухуровневого процесса.
Для формирования структурных моделей используются соответствующие нотации IDEF
0
, ARIS Value Added Chain, Value
Stream Map (информационные потоки) компании Toyota, модель цепочек создания ценности и др. Информация о них содержится во многих публикациях, поэтому в своей книге я не стану касаться этого вопроса.
Структурные модели процессов, как правило, применяются для:
описания, анализа бизнес-модели организации и определения возможных направлений ее реорганизации;
разработки системы бизнес-процессов организации по принципу сверху вниз»;
системного описания процессов, которые необходимо автоматизировать (например, в ERP-системе);
описания состава процессов, декомпозированных наследующий уровень (несистемное, фрагментарное использование).
Рассмотрим деятельность торговой компании (розничная торговля продуктами питания. На рис. 4.5.1 показан пример структурной
В этом параграфе мы рассмотрим особенности использования структурных моделей при описании процессов организации.
Под структурной будем понимать модель, включающую в себя упорядоченный по определенному принципу набор процессов (групп процессов) с указанием основных связей между ними.
Основное назначение структурной модели — показать, как устроен бизнес организации, раскрыть информацию об основных группах процессов и их взаимосвязях. Структурная модель не показывает последовательность выполнения процессов во времени.
Структурные модели можно использовать локально (не в системе процессов организации) для схематичного описания состава процессов, декомпозированных наследующий уровень. Например, такая структурная схема может быть представлена в регламенте двухуровневого процесса.
Для формирования структурных моделей используются соответствующие нотации IDEF
0
, ARIS Value Added Chain, Value
Stream Map (информационные потоки) компании Toyota, модель цепочек создания ценности и др. Информация о них содержится во многих публикациях, поэтому в своей книге я не стану касаться этого вопроса.
Структурные модели процессов, как правило, применяются для:
описания, анализа бизнес-модели организации и определения возможных направлений ее реорганизации;
разработки системы бизнес-процессов организации по принципу сверху вниз»;
системного описания процессов, которые необходимо автоматизировать (например, в ERP-системе);
описания состава процессов, декомпозированных наследующий уровень (несистемное, фрагментарное использование).
Рассмотрим деятельность торговой компании (розничная торговля продуктами питания. На рис. 4.5.1 показан пример структурной
Управление финансами Управление персоналом АХОИн женерно
-тех ни ческ ое обеспечение Обеспечение деятельности Управление дивизионом Управление направлением Магазин Уп р
ав лени е сетью Розничные продажи продажами в целом, под, по направлениям (к
ус
та
м
),
в отдельном маг
азине
У
п р
а вл е
н и
е товарными категориями потребностей потребителей в товаре (ассортимент цена к
аче
ст
во
)
Ф
и
зи
че
ск
ая
поставка товара в с
ет
ь
Комп
лексное
обеспечение деятельности маг
азинов
М
аг
аз
и
н как п
р
о
ду
кт
От кр ы
ти е новых магазинов Развитие форматов магазинов Развитие Управление развитием Развитие бизнеса
Комп
лексное
развитие форматы магазины С
ТМ
С
тратег и
че ское управление Марке тинг
Р
ек лама и Оперативное управление Управление бизнесом Управление ассортиментом Насыщение сети товаром Зак уп кат ов ара Управление поставкой товара в сеть Тр ан спор тн ая и складская логистика По д
д ерж а
ние форматов магазинов Оформлен ие
Инфр астр ук тура Инженерное обеспечение Работа с поставщиками Уп рав ление товарными запасами Ценообразование Рис. 4
.5
.1.
Пример структурной модели торговой компании Один из возможных вариантов представления Глава 4. Описание бизнес-процессов организации
235
модели процессов, выполненной без использования специализированной нотации на основе анализа цепочек создания ценности, осуществляемых компанией.
На рис. 4.5.1 видно, что в модели выделено семь групп процессов. Цель ее построения — демонстрация возможного варианта определения и группировки процессов торговой компании. Такая модель может быть представлена руководителям верхнего уровня для согласования. В дальнейшем модель используется при построении системы процессов организации.
На рис. 4.5.2 та же модель, что и на рис. 4.5.1, только выполненная в стандарте Анализируя рис. 4.5.2, отмечу, что многочисленные стрелки, которые обычно представлены на схемах IDEF
0
, не так уж важны руководителям бизнеса для понимания и использования модели. Менеджеры крупной торговой компании, проработавшие в бизнесе много лет, хорошо представляют себе основные результаты работы каждого структурного подразделения (ассортиментная матрица, план продажи закупок и т. п. Поэтому загромождение структурной схемы стрелками скорее развлечение, а не деятельность бизнес-аналитика, полезная для управления. Нужно стремиться минимизировать количество стрелок, сохраняя при этом информативность схемы.
Однако в случае проектирования компании с нуля проработка основных связей на структурной схеме очень полезна. Но такие случаи на практике встречаются редко.
Вопрос пользы структурных моделей для решения задач бизнес- моделирования спорный. С моей точки зрения, построение сложной, многоуровневой системы процессов организации водной модели
IDEF
0
(или в другой нотации) излишне. Если соблюдать все формальные правила, тов такой модели может получиться семь-восемь уровней декомпозиции. Реальную же ценность для последующего описания и регламентации имеют один-два нижних уровня, где выполняются конкретные операции и осуществляется реальный документооборот. Именно на этих уровнях процессы можно описать в формате Work
Flow и при помощи этих описаний сформировать регламенты работы сотрудников (регламент процесса, инструкция по выполнению
-тех ни ческ ое обеспечение Обеспечение деятельности Управление дивизионом Управление направлением Магазин Уп р
ав лени е сетью Розничные продажи продажами в целом, под, по направлениям (к
ус
та
м
),
в отдельном маг
азине
У
п р
а вл е
н и
е товарными категориями потребностей потребителей в товаре (ассортимент цена к
аче
ст
во
)
Ф
и
зи
че
ск
ая
поставка товара в с
ет
ь
Комп
лексное
обеспечение деятельности маг
азинов
М
аг
аз
и
н как п
р
о
ду
кт
От кр ы
ти е новых магазинов Развитие форматов магазинов Развитие Управление развитием Развитие бизнеса
Комп
лексное
развитие форматы магазины С
ТМ
С
тратег и
че ское управление Марке тинг
Р
ек лама и Оперативное управление Управление бизнесом Управление ассортиментом Насыщение сети товаром Зак уп кат ов ара Управление поставкой товара в сеть Тр ан спор тн ая и складская логистика По д
д ерж а
ние форматов магазинов Оформлен ие
Инфр астр ук тура Инженерное обеспечение Работа с поставщиками Уп рав ление товарными запасами Ценообразование Рис. 4
.5
.1.
Пример структурной модели торговой компании Один из возможных вариантов представления Глава 4. Описание бизнес-процессов организации
235
модели процессов, выполненной без использования специализированной нотации на основе анализа цепочек создания ценности, осуществляемых компанией.
На рис. 4.5.1 видно, что в модели выделено семь групп процессов. Цель ее построения — демонстрация возможного варианта определения и группировки процессов торговой компании. Такая модель может быть представлена руководителям верхнего уровня для согласования. В дальнейшем модель используется при построении системы процессов организации.
На рис. 4.5.2 та же модель, что и на рис. 4.5.1, только выполненная в стандарте Анализируя рис. 4.5.2, отмечу, что многочисленные стрелки, которые обычно представлены на схемах IDEF
0
, не так уж важны руководителям бизнеса для понимания и использования модели. Менеджеры крупной торговой компании, проработавшие в бизнесе много лет, хорошо представляют себе основные результаты работы каждого структурного подразделения (ассортиментная матрица, план продажи закупок и т. п. Поэтому загромождение структурной схемы стрелками скорее развлечение, а не деятельность бизнес-аналитика, полезная для управления. Нужно стремиться минимизировать количество стрелок, сохраняя при этом информативность схемы.
Однако в случае проектирования компании с нуля проработка основных связей на структурной схеме очень полезна. Но такие случаи на практике встречаются редко.
Вопрос пользы структурных моделей для решения задач бизнес- моделирования спорный. С моей точки зрения, построение сложной, многоуровневой системы процессов организации водной модели
IDEF
0
(или в другой нотации) излишне. Если соблюдать все формальные правила, тов такой модели может получиться семь-восемь уровней декомпозиции. Реальную же ценность для последующего описания и регламентации имеют один-два нижних уровня, где выполняются конкретные операции и осуществляется реальный документооборот. Именно на этих уровнях процессы можно описать в формате Work
Flow и при помощи этих описаний сформировать регламенты работы сотрудников (регламент процесса, инструкция по выполнению
Поддержание форматов магазинов Модель торговой организации 1 9
.0 2
.2 0
1 2
D
R
AF
T
RE
C
O
MME
N
DED
N
O
TE
S
: 1 2 3 4 5 6 7 8 9 1 0
P
U
B
LI
C
AT
IO
N
MODE:
АО
Уп р
а в
л е
н и
е бизнесом А1Уп р
а в
л е
н и
е товарными категориями А2Нас ы
щ е
ни е
сети товаром А3По д
д ерж а
ние форматов магазинов А4Ро зни чные продажи А5Обе спечение деятельности А7Разви тие сети
А6
TITLE
:
Мо дель торговой организации Цели акционеров
Ц
е липла н
ы
О
тч е
тн ость Товар от поставщиков ТМЦ для обеспечения работы магазина Де нежные средства потребителей ТМЦ, ПО и прочее Инф о
р м
ац и
я о рынке Ассортиментная матрица То вар, отгруженный с Р
Ц
Д
е нежные средства в банке Товару потребителей Ин ф. оп рода ж
а х
И
н фра, Т
М
Ц
, ПО, прочее Инфр астр ук тура магазина Отчетность Те б
о ван и я пора зв и
ти ю
форма тов
Рис
. 4
.5
.2.
Пример структурной модели процессов торговой компании. Стандарт Модель учебная. Подразделения исполнители процессов не показаны. Обратные связи тоже Глава 4. Описание бизнес-процессов организации
237
процесса» и т. п. Вопрос в том, как разработать адекватный реальному бизнесу иерархический справочник процессов. Если можно обойтись без сложной (понятной только бизнес-аналитику) структурной модели процессов, то и ненужно ее создавать.
Примечание. В крупной, давно работающей компании построение сложной структурной модели может не принести ожидаемого результата. Дело в том, что топ-менеджмент вряд ли решится перекраивать весь бизнес по модели в IDEF0. Ас точки зрения регламентации на операционном уровне все верхние уровни (й) в модели IDEF0 бесполезны.
Другое дело, если нужно спроектировать новый бизнес. Эта работа выполняется по принципу сверху вниз, так как действующих процессов и самой компании пока нет. Анализ структуры и связей процессов наверх- нем и среднем уровнях полезен для принятия решений о структуре будущей организации и закреплении групп процессов за подразделениями.
Итак, структурная модель процессов нужна:
бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь для корректного перехода к процессам уровня Work
Flow — регламентируемым или автоматически исполняемым в BPMS процессам);
руководителям организации для:
—
уточнения зон ответственности, целей и задач их деятель-
•
ности;
анализа и совершенствования архитектуры бизнеса;
•
руководителям и бизнес-аналитикам при проектировании нового бизнеса.
Замечу, что среди руководителей компаний желающие работать со структурной графической моделью процессов верхнего уровня встречаются редко. Поэтому многоуровневая структурная модель
* Этот вопрос подробно обсуждался в главе 3.
.0 2
.2 0
1 2
D
R
AF
T
RE
C
O
MME
N
DED
N
O
TE
S
: 1 2 3 4 5 6 7 8 9 1 0
P
U
B
LI
C
AT
IO
N
MODE:
АО
Уп р
а в
л е
н и
е бизнесом А1Уп р
а в
л е
н и
е товарными категориями А2Нас ы
щ е
ни е
сети товаром А3По д
д ерж а
ние форматов магазинов А4Ро зни чные продажи А5Обе спечение деятельности А7Разви тие сети
А6
TITLE
:
Мо дель торговой организации Цели акционеров
Ц
е липла н
ы
О
тч е
тн ость Товар от поставщиков ТМЦ для обеспечения работы магазина Де нежные средства потребителей ТМЦ, ПО и прочее Инф о
р м
ац и
я о рынке Ассортиментная матрица То вар, отгруженный с Р
Ц
Д
е нежные средства в банке Товару потребителей Ин ф. оп рода ж
а х
И
н фра, Т
М
Ц
, ПО, прочее Инфр астр ук тура магазина Отчетность Те б
о ван и я пора зв и
ти ю
форма тов
Рис
. 4
.5
.2.
Пример структурной модели процессов торговой компании. Стандарт Модель учебная. Подразделения исполнители процессов не показаны. Обратные связи тоже Глава 4. Описание бизнес-процессов организации
237
процесса» и т. п. Вопрос в том, как разработать адекватный реальному бизнесу иерархический справочник процессов. Если можно обойтись без сложной (понятной только бизнес-аналитику) структурной модели процессов, то и ненужно ее создавать.
Примечание. В крупной, давно работающей компании построение сложной структурной модели может не принести ожидаемого результата. Дело в том, что топ-менеджмент вряд ли решится перекраивать весь бизнес по модели в IDEF0. Ас точки зрения регламентации на операционном уровне все верхние уровни (й) в модели IDEF0 бесполезны.
Другое дело, если нужно спроектировать новый бизнес. Эта работа выполняется по принципу сверху вниз, так как действующих процессов и самой компании пока нет. Анализ структуры и связей процессов наверх- нем и среднем уровнях полезен для принятия решений о структуре будущей организации и закреплении групп процессов за подразделениями.
Итак, структурная модель процессов нужна:
бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь для корректного перехода к процессам уровня Work
Flow — регламентируемым или автоматически исполняемым в BPMS процессам);
руководителям организации для:
—
уточнения зон ответственности, целей и задач их деятель-
•
ности;
анализа и совершенствования архитектуры бизнеса;
•
руководителям и бизнес-аналитикам при проектировании нового бизнеса.
Замечу, что среди руководителей компаний желающие работать со структурной графической моделью процессов верхнего уровня встречаются редко. Поэтому многоуровневая структурная модель
* Этот вопрос подробно обсуждался в главе 3.
238
Бизнес-процессы. Моделирование, внедрение, управление
(например, в IDEF
0
) — удел узкого круга бизнес-аналитиков. В лучшем случае руководители используют диаграмму первого уровня, которую размещают на стенде с нормативно-методической документацией. Модели процессов на операционном уровне
В этом параграфе мы рассмотрим модели процессов на операционном уровне. Они отображают последовательность выполнения операций процесса (подпроцессов) во времени. Их обычно называют модели Work Сейчас существует множество нотаций типа Work Flow, при помощи которых можно описывать процессы операционного уровня. Рассмотрим основу формирования моделей и некоторые важные аспекты их применения. Нотации типа Work На рис. 4.6.1 показаны основные элементы, которые используются практически во всех современных нотациях Work Flow. Можно выделить пять основных:
События.
1. Операторы логики (по-другому их называют блоки решения,
2. ветвления/развилки, шлюзы/гейтвеи
**
).
Операции процесса. Стрелки типа Связь предшествования. Стрелки типа Поток объектов. События служат для определения границ процесса. Они могут указывать на его начало и завершение. Кроме того, возможны промежуточные события, возникающие походу выполнения процесса. Примеры именования событий Поступила заявка клиента на отгрузку
* Work flow — поток работ (англ ** Gateway — ворота, шлюз (англ.
Глава 4. Описание бизнес-процессов организации
239
продукции», Утвержден план проекта, Подписана накладная,
«8.00 понедельника и т. п. Как видно на рис. 4.6.1, в различных нотациях события показаны при помощи разных условных обозначений. Особняком стоит BPMN 2.0
*
(см, например, [9]). В рамках этой нотации внутри графического элемента Событие могут присутствовать различные маркеры таймер, сообщение, триггер и т. д.
Рис. 4.6.1. Основные элементы нотации Work Процедура системы
Business Studio
ARIS eEPC
BPMN
События
Операторы логики
Операции процесса
Стрелки типа Связь предшествования»
Стрелки типа Поток объектов»
Операторы логики служат для описания ситуаций, связанных с ветвлением процесса. Оно может произойти по разным причинам например, принятие решения, проверка условия. Операторы логики бывают трех типов логическое И, логическое исключающее ИЛИ, логическое неисключающее «ИЛИ».
На рис. 4.6.2 приведен пример использования операторов логики при построении схемы типа Work Flow (графические обозначения операторов логики на схеме условные).
При использовании логического оператора И (ситуация 1) после операции 1 выполняются операция 2 и операция 3.
* Business Process Model and Notation.
** За исключением BPMN.
239
продукции», Утвержден план проекта, Подписана накладная,
«8.00 понедельника и т. п. Как видно на рис. 4.6.1, в различных нотациях события показаны при помощи разных условных обозначений. Особняком стоит BPMN 2.0
*
(см, например, [9]). В рамках этой нотации внутри графического элемента Событие могут присутствовать различные маркеры таймер, сообщение, триггер и т. д.
Рис. 4.6.1. Основные элементы нотации Work Процедура системы
Business Studio
ARIS eEPC
BPMN
События
Операторы логики
Операции процесса
Стрелки типа Связь предшествования»
Стрелки типа Поток объектов»
Операторы логики служат для описания ситуаций, связанных с ветвлением процесса. Оно может произойти по разным причинам например, принятие решения, проверка условия. Операторы логики бывают трех типов логическое И, логическое исключающее ИЛИ, логическое неисключающее «ИЛИ».
На рис. 4.6.2 приведен пример использования операторов логики при построении схемы типа Work Flow (графические обозначения операторов логики на схеме условные).
При использовании логического оператора И (ситуация 1) после операции 1 выполняются операция 2 и операция 3.
* Business Process Model and Notation.
** За исключением BPMN.
240
Бизнес-процессы. Моделирование, внедрение, управление
При использовании логического оператора исключающее ИЛИ (ситуация 2) после операции 1 выполняется одна из двух операций — 2 или При использовании логического оператора неисключающее ИЛИ (ситуация 3) после операции 1 выполняется операция 2, либо операция 3, либо операции 2 и Условные обозначения для операций процесса (задач, действий, функций) выглядят практически одинаково во всех нотациях типа
Work Рис. 4.6.2. Использование операторов логики
Ситуация После выполнения операции 1 выполняются операция 2 и операция Операция Операция Операция Логический оператор «и»
«и»
Ситуация После выполнения операции 1 выполняется либо операция 2, либо операция Операция Операция Операция Логический оператор исключающее «или»
«или»
Ситуация После выполнения операции 1 выполняется либо операция 2, либо операция 3, либо обе операции — 2 и Операция Операция Операция Логический оператор неисключающее «или»
«или»
Глава 4. Описание бизнес-процессов организации
241
Важный элемент схемы Work Flow — связи. Они представлены при помощи стрелок определенного вида. Первый тип — стрелки Связь предшествования. Без них построение модели типа Work Flow невозможно. Стрелка Связь предшествования, связывающая две операции, показывает, что вторая операция начинает выполняться только после завершения первой. Можно сказать, что стрелки Связь предшествования демонстрируют развертку процесса во времени.
Стрелки Поток объектов используются на схемах типа Work
Flow для описания потоков документов и информации
*
За счет использования событий, операторов логики и стрелок Связь предшествования на схеме Work Flow можно показать сложную логику выполнения процесса во времени.
В следующих разделах рассмотрим наиболее известные нотации моделирования. Простая блок-схема
Нотация Простая блок-схема» реализована в MS Visio. На рис. 4.6.3 показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме нотация применяется редко.
Вообще в MS Visio представлено несколько сложных нотаций типа
«Блок-схема». Видимо, поэтому они не нашли широкого применения, хотя и были включены в набор нотаций, поставляемых с системой.
Нотация Простая блок-схема» в самом доступном и часто используемом варианте содержит всего несколько элементов:
процесс;
—
решение;
—
ручная операция (реже);
—
документ;
—
данные;
—
стрелка (для отображения связей между объектами схемы При необходимости их можно использовать для описания потоков материальных объектов
242
Бизнес-процессы. Моделирование, внедрение, управление
При помощи этой нотации можно показать потоки данных, если необходимо описывать процессы для автоматизации.
Рассмотрим некоторые особенности применения простой блок- схемы, в частности применение стрелок. Сотрудники компании, формирующие схемы при помощи простой блок-схемы, придерживаются двух подходов:
не именуют стрелки вообще;
—
стараются присваивать стрелкам, связывающим элементы схемы, простые и понятные названия.
На рис. 4.6.4 показан пример применения простой блок-схемы водной из компаний. Применены все пять типов элементов. Тем не менее схема выглядит вполне читаемой и понятной пользователю сотруднику компании.
Рис. 4.6.3. Нотация Простая блок-схема» в MS Visio
241
Важный элемент схемы Work Flow — связи. Они представлены при помощи стрелок определенного вида. Первый тип — стрелки Связь предшествования. Без них построение модели типа Work Flow невозможно. Стрелка Связь предшествования, связывающая две операции, показывает, что вторая операция начинает выполняться только после завершения первой. Можно сказать, что стрелки Связь предшествования демонстрируют развертку процесса во времени.
Стрелки Поток объектов используются на схемах типа Work
Flow для описания потоков документов и информации
*
За счет использования событий, операторов логики и стрелок Связь предшествования на схеме Work Flow можно показать сложную логику выполнения процесса во времени.
В следующих разделах рассмотрим наиболее известные нотации моделирования. Простая блок-схема
Нотация Простая блок-схема» реализована в MS Visio. На рис. 4.6.3 показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме нотация применяется редко.
Вообще в MS Visio представлено несколько сложных нотаций типа
«Блок-схема». Видимо, поэтому они не нашли широкого применения, хотя и были включены в набор нотаций, поставляемых с системой.
Нотация Простая блок-схема» в самом доступном и часто используемом варианте содержит всего несколько элементов:
процесс;
—
решение;
—
ручная операция (реже);
—
документ;
—
данные;
—
стрелка (для отображения связей между объектами схемы При необходимости их можно использовать для описания потоков материальных объектов
242
Бизнес-процессы. Моделирование, внедрение, управление
При помощи этой нотации можно показать потоки данных, если необходимо описывать процессы для автоматизации.
Рассмотрим некоторые особенности применения простой блок- схемы, в частности применение стрелок. Сотрудники компании, формирующие схемы при помощи простой блок-схемы, придерживаются двух подходов:
не именуют стрелки вообще;
—
стараются присваивать стрелкам, связывающим элементы схемы, простые и понятные названия.
На рис. 4.6.4 показан пример применения простой блок-схемы водной из компаний. Применены все пять типов элементов. Тем не менее схема выглядит вполне читаемой и понятной пользователю сотруднику компании.
Рис. 4.6.3. Нотация Простая блок-схема» в MS Visio
Глава 4. Описание бизнес-процессов организации
243
Нотация Простая блок-схема» часто подвергается в организациях различным вариациям:
изменяется смысл элемента Решение (его используют в качестве операции процесса);
по-разному используют стрелки связей (именуют или не именуют и т. п.);
по-разному используют стрелки связей в сочетании с объектом «Документ»;
прочее.
—
Интересно, что нотация Простая блок-схема» в томили ином виде часто используется специалистами по менеджменту качества при описании процессов СМК, так как она самая простая из из- вестных.
Преимущества простой блок-схемы (с сокращенным до минимума количеством элементов):
простота формирования графических схем процессов;
—
интуитивная понятность схем сотрудникам (даже без специального обучения);
минимальная потребность в обучении сотрудников;
—
наличие доступных инструментов для описания процессов
—
(MS Visio, MS Однако, как это часто бывает на практике, если нотация используется без утвержденного внутреннего стандарта и специализированного средства моделирования, компания получает множество нестандартно оформленных схем, которые содержатся в различных файлах. Поддерживать такой массив информации в связном состоянии и отслеживать изменения сложно. Требуется большой объем ручного труда бизнес-аналитиков. Поэтому, выбирая нотацию Простая блок-схема», необходимо заранее разработать
243
Нотация Простая блок-схема» часто подвергается в организациях различным вариациям:
изменяется смысл элемента Решение (его используют в качестве операции процесса);
по-разному используют стрелки связей (именуют или не именуют и т. п.);
по-разному используют стрелки связей в сочетании с объектом «Документ»;
прочее.
—
Интересно, что нотация Простая блок-схема» в томили ином виде часто используется специалистами по менеджменту качества при описании процессов СМК, так как она самая простая из из- вестных.
Преимущества простой блок-схемы (с сокращенным до минимума количеством элементов):
простота формирования графических схем процессов;
—
интуитивная понятность схем сотрудникам (даже без специального обучения);
минимальная потребность в обучении сотрудников;
—
наличие доступных инструментов для описания процессов
—
(MS Visio, MS Однако, как это часто бывает на практике, если нотация используется без утвержденного внутреннего стандарта и специализированного средства моделирования, компания получает множество нестандартно оформленных схем, которые содержатся в различных файлах. Поддерживать такой массив информации в связном состоянии и отслеживать изменения сложно. Требуется большой объем ручного труда бизнес-аналитиков. Поэтому, выбирая нотацию Простая блок-схема», необходимо заранее разработать
Рис. Пример схемы в нотации Простая блок схема На ча ло
Дон ес ти решения до руководителей подразделений Изучить информацию в Б
Д
Кадры По дг от овить требования к персоналу икр уг обязанностей Подготовить распоряжение оп од боре кандидата среди персонала Руково д
и те лис тру к
ту р
ны х подразделений Помощник директора пока драм Директор по общим вопросам Совет директоров (
С
Д
)
Решение
С
Д
по кадровым вопросам Кор рек тиров ки требований и обязанностей Распоряжение и требования к кандидату Согласованные требования к кандидату Предложения пот р еб ов аниям к кандидату и обязанностям Информация о вакансиях Изм ен ен и
я в штатном расписании Реш ен и
е С
Д
о ротации кадров (т ак ти ческ ое решен и
е)
Р
еш ен и
е С
Д
он ов ы
х вакансиях кадровая политика Кадровый резерв есть да да нет нет Ес ть корректировки Запросить предложения наз амеще- ни е вакантных должностей Направи ть предложения По дг от овить распоряжение оп ои ск е кандидата вне компании Направи ть предложения По дг от овить распоряжение опер ев оде на новую должность По дг от овить распоряжение оста жировке За прос
Пре д
ложения руководителей Рас пор яж ен и
е оп ои ск е кандидата вне компании Информация обо тс ут ст вии кандидатов среди персонала Ка ндид ат ур ы для рассмотрения Запрос Ка ндид ат урана утверждение С
Д
Распоряжение на оформление кадровых вопросов (о переводе
)
Распоряжение на оформление кадровых вопросов (о стажировке )Ка ндид ат согласен Ну жн ас тажи ров ка
?
Ут ве р
ди ть кандидатуру Ка ндид ат соответствует Есть новые кандидатуры да да да да да нет нет не т
не т
не т
Ко не ц
246
Бизнес-процессы. Моделирование, внедрение, управление
внутренний стандарт использования этой нотации;
—
внутренний стандарт формирования, хранения и актуализации файлов со схемами процессов.
Масштабное использование в компании нотации Простая блок- схема без современного средства моделирования неэффективно. Нотация ARIS Нотация eEPC является частью общей методологии ARIS, в рамках которой организация рассматривается с четырех позиций организационной, функциональной, структуры данных и бизнес- процессов. При этом каждая из позиций разделяется натри подуровня описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту eEPC — одна из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотациям Work Flow. Особенности нотации — наличие элементов типа Событие и операторов логики И, неисключающее ИЛИ, исключающее «ИЛИ».
В качестве примера рассмотрим процесс, представленный на рис. 4.6.5, который начинается с события Поступил заказ клиента. Оно инициирует операцию Выполнить учет заказав системе, которую проводит менеджер отдела сбыта. Для работы он использует систему учета заказов. Результат операции отображается событием Учет заказа выполнен. После этого менеджер по сбыту осуществляет операцию Выполнить анализ на соответствие номенклатуре. Ее результат — два альтернативных события Заказ соответствует номенклатуре и Заказ не соответствует номенклатуре. Процесс ветвится. Для отображения ветвления процесса используется символ логического исключающего ИЛИ ARIS — архитектура интегрированных информационных систем. ARIS eEPC
(Extended Event-driven Process Chain) — расширенная модель цепочки процесса, управляемого событиями (нотация для описания бизнес-процессов).
Дон ес ти решения до руководителей подразделений Изучить информацию в Б
Д
Кадры По дг от овить требования к персоналу икр уг обязанностей Подготовить распоряжение оп од боре кандидата среди персонала Руково д
и те лис тру к
ту р
ны х подразделений Помощник директора пока драм Директор по общим вопросам Совет директоров (
С
Д
)
Решение
С
Д
по кадровым вопросам Кор рек тиров ки требований и обязанностей Распоряжение и требования к кандидату Согласованные требования к кандидату Предложения пот р еб ов аниям к кандидату и обязанностям Информация о вакансиях Изм ен ен и
я в штатном расписании Реш ен и
е С
Д
о ротации кадров (т ак ти ческ ое решен и
е)
Р
еш ен и
е С
Д
он ов ы
х вакансиях кадровая политика Кадровый резерв есть да да нет нет Ес ть корректировки Запросить предложения наз амеще- ни е вакантных должностей Направи ть предложения По дг от овить распоряжение оп ои ск е кандидата вне компании Направи ть предложения По дг от овить распоряжение опер ев оде на новую должность По дг от овить распоряжение оста жировке За прос
Пре д
ложения руководителей Рас пор яж ен и
е оп ои ск е кандидата вне компании Информация обо тс ут ст вии кандидатов среди персонала Ка ндид ат ур ы для рассмотрения Запрос Ка ндид ат урана утверждение С
Д
Распоряжение на оформление кадровых вопросов (о переводе
)
Распоряжение на оформление кадровых вопросов (о стажировке )Ка ндид ат согласен Ну жн ас тажи ров ка
?
Ут ве р
ди ть кандидатуру Ка ндид ат соответствует Есть новые кандидатуры да да да да да нет нет не т
не т
не т
Ко не ц
246
Бизнес-процессы. Моделирование, внедрение, управление
внутренний стандарт использования этой нотации;
—
внутренний стандарт формирования, хранения и актуализации файлов со схемами процессов.
Масштабное использование в компании нотации Простая блок- схема без современного средства моделирования неэффективно. Нотация ARIS Нотация eEPC является частью общей методологии ARIS, в рамках которой организация рассматривается с четырех позиций организационной, функциональной, структуры данных и бизнес- процессов. При этом каждая из позиций разделяется натри подуровня описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту eEPC — одна из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотациям Work Flow. Особенности нотации — наличие элементов типа Событие и операторов логики И, неисключающее ИЛИ, исключающее «ИЛИ».
В качестве примера рассмотрим процесс, представленный на рис. 4.6.5, который начинается с события Поступил заказ клиента. Оно инициирует операцию Выполнить учет заказав системе, которую проводит менеджер отдела сбыта. Для работы он использует систему учета заказов. Результат операции отображается событием Учет заказа выполнен. После этого менеджер по сбыту осуществляет операцию Выполнить анализ на соответствие номенклатуре. Ее результат — два альтернативных события Заказ соответствует номенклатуре и Заказ не соответствует номенклатуре. Процесс ветвится. Для отображения ветвления процесса используется символ логического исключающего ИЛИ ARIS — архитектура интегрированных информационных систем. ARIS eEPC
(Extended Event-driven Process Chain) — расширенная модель цепочки процесса, управляемого событиями (нотация для описания бизнес-процессов).
Глава 4. Описание бизнес-процессов организации
247
Операция Уведомить клиента о невозможности выполнения заказа может выполняться в двух случаях если заказ не соответствует номенклатуре или если производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ».
Нотация ARIS eEPC содержит большое количество графических элементов. Поэтому при выполнении проектов создаются так называемые методические фильтры (в рамках соглашений по моделированию, которые ограничивают количество типов элементов, доступных пользователям при создании схем процессов. (В некоторых средствах моделирования нотация ARIS eEPC сразу реализована с минимально необходимым набором элементов) Однако даже в этом случае неопытные пользователи создают схемы такой сложности, в которых трудно разобраться. К ним нужен подробный комментарий (либо наличие аналитика, способного объяснить схему).
Почему возникает такой эффект Это результат описания множества возникающих при выполнении процесса ветвлений при помощи формальных логических операторов. Делать это приходится по строгим правилам. В результате появляется формально правильная, но громоздкая, плохо воспринимаемая схема. Впрочем, это проблема почти всех нотаций Work Flow. Для специалиста, который занимается моделированием постоянно, выбор ARIS eEPC в качестве инструмента описания вполне адекватен.
Следует отметить, что типичная схема вне годится для автоматизации в системе класса BPM
—
(Business
Process Management) (нужно применять дополнительный транслятор, переводящий ее в нотацию BPMN, с последующей ручной доработкой);
сложна для восприятия рядовыми сотрудниками (их нужно учить правилам использования логических операторов и корректному чтению схем, которые их содержат
247
Операция Уведомить клиента о невозможности выполнения заказа может выполняться в двух случаях если заказ не соответствует номенклатуре или если производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ».
Нотация ARIS eEPC содержит большое количество графических элементов. Поэтому при выполнении проектов создаются так называемые методические фильтры (в рамках соглашений по моделированию, которые ограничивают количество типов элементов, доступных пользователям при создании схем процессов. (В некоторых средствах моделирования нотация ARIS eEPC сразу реализована с минимально необходимым набором элементов) Однако даже в этом случае неопытные пользователи создают схемы такой сложности, в которых трудно разобраться. К ним нужен подробный комментарий (либо наличие аналитика, способного объяснить схему).
Почему возникает такой эффект Это результат описания множества возникающих при выполнении процесса ветвлений при помощи формальных логических операторов. Делать это приходится по строгим правилам. В результате появляется формально правильная, но громоздкая, плохо воспринимаемая схема. Впрочем, это проблема почти всех нотаций Work Flow. Для специалиста, который занимается моделированием постоянно, выбор ARIS eEPC в качестве инструмента описания вполне адекватен.
Следует отметить, что типичная схема вне годится для автоматизации в системе класса BPM
—
(Business
Process Management) (нужно применять дополнительный транслятор, переводящий ее в нотацию BPMN, с последующей ручной доработкой);
сложна для восприятия рядовыми сотрудниками (их нужно учить правилам использования логических операторов и корректному чтению схем, которые их содержат
Рис. 4.6.5. Схема процесса в нотации ARIS eEPC
* ПЭО — планово-экономический отдел.
Выполнить учет заказав системе
Согласовать заявку с ПЭО
Выполнить анализ на соответствие номенклатуре Поступил заказ клиента
Заказ не соответствует номенклатуре
Заказ соответствует номенклатуре
Производство возможно
Производство невозможно Cистема учета заказов
Менеджер отдела сбыта
Менеджер отдела сбыта
Менеджер отдела сбыта
Экономист ПЭО
*
Номенклатура изделий
Номенклатура изделий
Производствен- ные возможности
Сопроводи- тельное письмо
Заявка клиента
Заявка клиента
Заявка клиента
250
Бизнес-процессы. Моделирование, внедрение, управление
Итак, нотация ARIS eEPC не предназначена для описания автоматически исполняемых процессов и неудобна для восприятия из-за своей сложности. Моделирование вне дает значительных преимуществ ни для автоматизации, ни для регламентации. Это классическая, формально правильная, но неудобная для восприятия нотация.
Несмотря на перечисленные проблемы, применение нотации ARIS eEPC и соответствующего средства моделирования, безусловно, позволяет создать в организации качественную, комплексную процессную модель. Многие крупные и средние российские компании используют для описания и регламентации бизнес-процессов. Могу предположить, что в этих компаниях постепенно произойдет переход от нотации ARIS eEPC к более сложной, но и более выразительной сточки зрения задач бизнес-моделирования) нотации BPMN 2.0.
4.6.4. Нотация BPMN
* ПЭО — планово-экономический отдел.
Выполнить учет заказав системе
Согласовать заявку с ПЭО
Выполнить анализ на соответствие номенклатуре Поступил заказ клиента
Заказ не соответствует номенклатуре
Заказ соответствует номенклатуре
Производство возможно
Производство невозможно Cистема учета заказов
Менеджер отдела сбыта
Менеджер отдела сбыта
Менеджер отдела сбыта
Экономист ПЭО
*
Номенклатура изделий
Номенклатура изделий
Производствен- ные возможности
Сопроводи- тельное письмо
Заявка клиента
Заявка клиента
Заявка клиента
Рассчитать цену, сумму и сроки выполнения заказа
Согласовать условия поставки с клиентом
Внести клиента в статистику неудовлетворенного спроса
Уведомить клиента о невозможности выполнения заказа
Условия выполнения заказа согласованы
Условия выполнения заказа не согласованы
Конец процесса
Менеджер отдела сбыта
Менеджер отдела сбыта
Экономист ПЭО
Cистема учета заказов
Плановая калькуляция на заказ
Заявка клиента
Нормативы
Файл Excel
Согласовать условия поставки с клиентом
Внести клиента в статистику неудовлетворенного спроса
Уведомить клиента о невозможности выполнения заказа
Условия выполнения заказа согласованы
Условия выполнения заказа не согласованы
Конец процесса
Менеджер отдела сбыта
Менеджер отдела сбыта
Экономист ПЭО
Cистема учета заказов
Плановая калькуляция на заказ
Заявка клиента
Нормативы
Файл Excel
250
Бизнес-процессы. Моделирование, внедрение, управление
Итак, нотация ARIS eEPC не предназначена для описания автоматически исполняемых процессов и неудобна для восприятия из-за своей сложности. Моделирование вне дает значительных преимуществ ни для автоматизации, ни для регламентации. Это классическая, формально правильная, но неудобная для восприятия нотация.
Несмотря на перечисленные проблемы, применение нотации ARIS eEPC и соответствующего средства моделирования, безусловно, позволяет создать в организации качественную, комплексную процессную модель. Многие крупные и средние российские компании используют для описания и регламентации бизнес-процессов. Могу предположить, что в этих компаниях постепенно произойдет переход от нотации ARIS eEPC к более сложной, но и более выразительной сточки зрения задач бизнес-моделирования) нотации BPMN 2.0.
4.6.4. Нотация BPMN
1 ... 8 9 10 11 12 13 14 15 ... 21
BPMN — система условных обозначений (нотация) и модель для описания и подготовки к автоматизации бизнес-процессов. Разработана она компанией Business Process Management Initiative и поддерживается после слияния организаций в 2005 году. Предыдущая версия BPMN — 1.2, последняя версия — Нотация BPMN появилась относительно недавно. Она ориентирована на описание так называемых исполняемых процессов, то есть процессов, которые поддерживаются системами автоматизации операционных процессов — Рассмотрим пример. В торговой компании есть отдел продаж, деятельность которого заключается в получении и обработке заявок клиентов, выставлении счетов и т. п. Структура процессов отдела следующая:
получение заявок клиентов;
—
обработка заявки и выставление счета (процесс выполняется по одинаковой процедуре несколькими менеджерами отдела Появилась в 2012 году
Глава 4. Описание бизнес-процессов организации
251
формирование графика доставки;
—
обработка ждущих (отложенных) заявок;
—
контроль остатков, рассылка информационных писем клиентам;
—
изменение статуса товара в базе;
—
обработка отказов.
—
На рис. 4.6.6 показан процесс Обработка заявки и выставление счета клиенту, описанный в нотации BPMN. Схема рис. 4.6.6 содержит три объекта типа Gateway, восемь — типа Event и четыре операции (действия, задачи. Как видим, процесс совсем несложный, но количество условных обозначений, нужных для его описания, значительно.
К нотации BPMN специалисты относятся по-разному. Для профессионалов, описывающих процессы с целью автоматизации, она весьма удобна. Более того, сейчас BPMN, очевидно, нет альтернативы. Но для руководителей и сотрудников организации, не обладающих компетенциями в области бизнес-моделирования, эта нотация слишком сложна. Применение BPMN в масштабах компании требует значительных затратна обучение сотрудников, создание у них навыков моделирования. Это сложнее, чем при использовании более простой и понятной нотации. Поэтому выбирать BPMN можно в случае, если:
руководители готовы тратить деньги на обучение и развитие культуры бизнес-моделирования в организации;
руководители сами готовы активно осваивать нотацию предполагается активно использовать схемы процессов в BPMN для автоматизации операционных процессов.
К сожалению, сейчас на русском языке нет книг по использованию нотации BPMN. Есть только статьи, презентации, материалы вебинаров. Специалисты, заинтересованные в ее изучении, вынуждены обращаться к англоязычным источникам. Надеюсь, что в ближайшей перспективе ситуация изменится к лучшему.
251
формирование графика доставки;
—
обработка ждущих (отложенных) заявок;
—
контроль остатков, рассылка информационных писем клиентам;
—
изменение статуса товара в базе;
—
обработка отказов.
—
На рис. 4.6.6 показан процесс Обработка заявки и выставление счета клиенту, описанный в нотации BPMN. Схема рис. 4.6.6 содержит три объекта типа Gateway, восемь — типа Event и четыре операции (действия, задачи. Как видим, процесс совсем несложный, но количество условных обозначений, нужных для его описания, значительно.
К нотации BPMN специалисты относятся по-разному. Для профессионалов, описывающих процессы с целью автоматизации, она весьма удобна. Более того, сейчас BPMN, очевидно, нет альтернативы. Но для руководителей и сотрудников организации, не обладающих компетенциями в области бизнес-моделирования, эта нотация слишком сложна. Применение BPMN в масштабах компании требует значительных затратна обучение сотрудников, создание у них навыков моделирования. Это сложнее, чем при использовании более простой и понятной нотации. Поэтому выбирать BPMN можно в случае, если:
руководители готовы тратить деньги на обучение и развитие культуры бизнес-моделирования в организации;
руководители сами готовы активно осваивать нотацию предполагается активно использовать схемы процессов в BPMN для автоматизации операционных процессов.
К сожалению, сейчас на русском языке нет книг по использованию нотации BPMN. Есть только статьи, презентации, материалы вебинаров. Специалисты, заинтересованные в ее изучении, вынуждены обращаться к англоязычным источникам. Надеюсь, что в ближайшей перспективе ситуация изменится к лучшему.
Рис. Фрагмент модели процесса в нотации Выписать счет Сформировать новую заявку на отгрузку в Номенклатура товаров Запросить уточненные данные поз аявкеПр ов ер и
ть заявку на корректность Клиент Об работка заявки ивы ста вл ен ие счета Запрос клиенту Есть необработанная заявка Заявка кор рек тн ая?
Пи сь мокли ен ту
Да
Не т дня Отказ клиента Счет на товар для клиента Ответа нет Счет клиенту Ут очненна яз аявк а
От ка з
254
Бизнес-процессы. Моделирование, внедрение, управление
вертикальное представление дорожек. Можно выбирать их горизонтальное расположение, если так принято в организации.
Схема процесса располагается на листе формата А. Какие-либо изменения размера листа, как правило, не допускаются. Это ограничение дает возможность документировать схемы процессов в привычном формате (включать в регламентирующие документы компании. Отмечу, что это важное требование и им не стоит пренебрегать.
Рекомендуемое количество операций на одном листе — от 3 до 12. Если операций более 15, необходимо либо агрегировать их, либо попытаться разбить процесс на несколько подпроцессов.
Рис. 4.6.7. Схема процесса в нотации Процедура среды моделирования
Business Начальник отдела
Менеджер
Пример процесса
Наименование операции 1 процесса
Наименование операции 2 процесса
Наименование операции 3 процесса
Наименование операции 4 процесса
Наименование блока «Решение»
Наименование инициирующего события
Наименование завершающего события
Наименование стрелки Наименование стрелки Наименование стрелки Наименование стрелки. Пример процесса
Блок «Решение»
Стрелка типа Поток объектов»
Операция процесса именуется глаголом или отглагольным существительным
Стрелка типа Связь предшествования».
Стрелки должны быть обязательно именованы
Событие, инициирующее процесс. Может быть несколько событий, инициирующих процесс
Наименование стрелки 4
Междиаграммная ссылка
Наименование стрелки Наименование стрелки Наименование стрелки Наименование стрелки Наименование стрелки 6
ть заявку на корректность Клиент Об работка заявки ивы ста вл ен ие счета Запрос клиенту Есть необработанная заявка Заявка кор рек тн ая?
Пи сь мокли ен ту
Да
Не т дня Отказ клиента Счет на товар для клиента Ответа нет Счет клиенту Ут очненна яз аявк а
От ка з
Глава 4. Описание бизнес-процессов организации 4.6.5. Нотация Процедура среды моделирования
Business Сейчас одним из распространенных инструментов бизнес-мо дели- ро вания стала среда Business Studio
*
. В этой системе реализованы четыре нотации IDEF
0
, Процесс, Процедура, Нотация IDEF
0
используется для построения моделей верхнего уровня, а Процедура и eEPC — для создания моделей типа
Work Рассмотрим подробнее нотацию Процедура (см. рис. 4.6.7), так как она наиболее проста и удобна для описания бизнес-про цес сов организации. Основные элементы нотации — это:
операция (Действие в терминологии Business Studio);
—
событие;
—
блок «Решение»;
—
стрелка типа Связь предшествования»;
—
стрелка типа Поток объектов»;
—
междиаграммная ссылка (МДС);
—
сноска (текстовый комментарий);
—
дорожки.
—
Ниже привожу рекомендации по использованию нотации Процедура в организации.
Размеры используемых шрифтов, визуальный вид объектов, цветовое кодирование могут быть реализованы в типовых настройках
Business Studio. Как правило, данные настройки делаются один разине должны в последующем изменяться пользователями.
Дорожки на схеме процесса предназначены для отображения операций, выполняемых одним сотрудником, находящимся на соответствующей должности, либо одним сотрудником, играющим в процессе соответствующую роль. Рекомендуется использовать
* На начало 2011 года данная система использовалась более чем в 1000 компаний в России и странах СНГ.
Business Сейчас одним из распространенных инструментов бизнес-мо дели- ро вания стала среда Business Studio
*
. В этой системе реализованы четыре нотации IDEF
0
, Процесс, Процедура, Нотация IDEF
0
используется для построения моделей верхнего уровня, а Процедура и eEPC — для создания моделей типа
Work Рассмотрим подробнее нотацию Процедура (см. рис. 4.6.7), так как она наиболее проста и удобна для описания бизнес-про цес сов организации. Основные элементы нотации — это:
операция (Действие в терминологии Business Studio);
—
событие;
—
блок «Решение»;
—
стрелка типа Связь предшествования»;
—
стрелка типа Поток объектов»;
—
междиаграммная ссылка (МДС);
—
сноска (текстовый комментарий);
—
дорожки.
—
Ниже привожу рекомендации по использованию нотации Процедура в организации.
Размеры используемых шрифтов, визуальный вид объектов, цветовое кодирование могут быть реализованы в типовых настройках
Business Studio. Как правило, данные настройки делаются один разине должны в последующем изменяться пользователями.
Дорожки на схеме процесса предназначены для отображения операций, выполняемых одним сотрудником, находящимся на соответствующей должности, либо одним сотрудником, играющим в процессе соответствующую роль. Рекомендуется использовать
* На начало 2011 года данная система использовалась более чем в 1000 компаний в России и странах СНГ.
254
Бизнес-процессы. Моделирование, внедрение, управление
вертикальное представление дорожек. Можно выбирать их горизонтальное расположение, если так принято в организации.
Схема процесса располагается на листе формата А. Какие-либо изменения размера листа, как правило, не допускаются. Это ограничение дает возможность документировать схемы процессов в привычном формате (включать в регламентирующие документы компании. Отмечу, что это важное требование и им не стоит пренебрегать.
Рекомендуемое количество операций на одном листе — от 3 до 12. Если операций более 15, необходимо либо агрегировать их, либо попытаться разбить процесс на несколько подпроцессов.
Рис. 4.6.7. Схема процесса в нотации Процедура среды моделирования
Business Начальник отдела
Менеджер
Пример процесса
Наименование операции 1 процесса
Наименование операции 2 процесса
Наименование операции 3 процесса
Наименование операции 4 процесса
Наименование блока «Решение»
Наименование инициирующего события
Наименование завершающего события
Наименование стрелки Наименование стрелки Наименование стрелки Наименование стрелки. Пример процесса
Блок «Решение»
Стрелка типа Поток объектов»
Операция процесса именуется глаголом или отглагольным существительным
Стрелка типа Связь предшествования».
Стрелки должны быть обязательно именованы
Событие, инициирующее процесс. Может быть несколько событий, инициирующих процесс
Наименование стрелки 4
Междиаграммная ссылка
Наименование стрелки Наименование стрелки Наименование стрелки Наименование стрелки Наименование стрелки 6
Глава 4. Описание бизнес-процессов организации
255
В рамке автоматически указывается название процесса. Использовать номер процесса в рамке нежелательно. Дело в том, что в справочнике процессов удобно применять автоматическую нумерацию. Если в него вносятся новые процессы, то нумерация меняется. При этом в графических схемах, которые уже включены в регламентирующие документы компании, остается старый номер процесса. Это неудобно. Именно поэтому не рекомендуется указывать номер процесса на его графической схеме.
Надписи на стрелках могут располагаться как горизонтально, таки вертикально для обеспечения визуальной наглядности.
Операции процесса должны быть связаны между собой стрелками типа Связь предшествования. Если после выполнения операции необходимо поставить блок Решение, то связи операций с этим блоком также отображаются при помощи стрелок Связь предшествования».
Если между двумя операциями на схеме представлен блок Решение, то для моделирования передачи информации/документов из одной операции в другую используют стрелки типа Поток объектов».
В случае перехода на один уровень вверх относительно схемы под- процесса, разработанной в нотации Процедура, дорожки на схеме устанавливаются по должности или роли владельца подпроцесса.
На рис. 4.6.8 представлены варианты именования операции процесса в формате глагол + существительное. Также показаны ошибки, часто допускаемые при именовании операций.
Выполнить подготовку договора поставки оборудования
Правильно
Подготовить договор на поставку оборудования
Правильно
Выполнить подготовку договора поставки оборудования
Неправильно — тип и размер шрифта
Подготовка договора на поставку оборудования
Неправильно — именование при помощи
существительного
Договор поставки оборудования
Неправильно — вместо термина действия — существительное (договор)
Менеджер по продажам
Неправильно — вместо термина действия — название должности
Подготовить договор поставки оборудования с учетом наличия оборудования на складе, индивидуальных скидок клиенту, фазы Луны и методики расчета опускной цены с учетом коэффициента Неправильно — чрезмерно длинное название
операции
Рис. 4.6.8. Именование операций процесса
256
Бизнес-процессы. Моделирование, внедрение, управление
Стрелки типа Связь предшествования показывают последовательность выполнения операций процесса во времени. Каждая именованная стрелка в Business Studio — объект базы и хранится в справочнике стрелок. К именованным стрелкам типа Связь предшествования можно привязывать объекты из справочника Объекты деятельности (например, бумажные или электронные документы. К неименованным стрелкам привязать объекты невозможно. На рис. 4.6.9 показаны правильные и неправильные варианты применения стрелок на схеме процесса. Стрелки должны быть привязаны к операциям. Наличие стрелок, не привязанных к операциям (либо междиаграммным ссылкам, не допускается. Стрелки необходимо именовать. Нельзя использовать короткие, абстрактные названия да, договор, поступило письмо, информация. Они должны быть подробные, конкретные и отражать контекст того процесса, в рамках которого создаются.
Стрелки типа Связь предшествования желательно именовать, указывая:
название документа в именительном падеже;
—
описание результата выполнения операции в терминах со-
—
бытия.
Стрелки типа Поток объектов показывают движение объектов между операциями процесса. Под объектами понимаются любые объекты из справочника Объекты деятельности системы Business
Studio». В первую очередь это бумажные/электронные документы и информация. Стрелки Поток объектов используются там, где невозможно (нецелесообразно) использовать стрелки Связь предшествования, например при использовании блока Решение при описании межпроцессного взаимодействия при помощи информационного потока с использованием междиаграмм- ных ссылок
258
Бизнес-процессы. Моделирование, внедрение, управление
Каждая именованная стрелка — объект базы и хранится в справочнике стрелок. К именованным стрелкам можно привязывать объекты из справочника Объекты деятельности (например, бумажные или электронные документы. К неименованным стрелкам привязать объекты невозможно.
На рис. 4.6.10 показаны правильные и неправильные варианты применения стрелок на схеме процесса.
Стрелки должны быть привязаны к операциям. Наличие стрелок, не привязанных к операциям (либо междиаграммным ссылкам, на схеме процесса не допускается.
Стрелки необходимо обязательно именовать, но нельзя использовать короткие, абстрактные названия типа Договор, Письмо, Информация. Они должны быть подробными, конкретными и содержать наименование или отражать суть тех документов информации, которые используются в рамках моделируемого процесса.
Стрелки типа Поток объектов можно именовать, указывая название документа (формулировку информационного потока) в именительном падеже.
Объекты типа Событие используются на схеме процесса для отображения событий. События бывают инициирующими процесс одно или более, промежуточными (одно или более, завершающими процесс (одно или более).
Промежуточные события можно использовать, когда временнáя последовательность выполнения операций процесса прерывается на неопределенное время.
Если походу моделирования возникает промежуточное событие, то рекомендуется разделить процесс на несколько подпроцессов.
На рис. 4.6.11 показаны правильные и неправильные варианты применения на схеме объектов типа Событие
255
В рамке автоматически указывается название процесса. Использовать номер процесса в рамке нежелательно. Дело в том, что в справочнике процессов удобно применять автоматическую нумерацию. Если в него вносятся новые процессы, то нумерация меняется. При этом в графических схемах, которые уже включены в регламентирующие документы компании, остается старый номер процесса. Это неудобно. Именно поэтому не рекомендуется указывать номер процесса на его графической схеме.
Надписи на стрелках могут располагаться как горизонтально, таки вертикально для обеспечения визуальной наглядности.
Операции процесса должны быть связаны между собой стрелками типа Связь предшествования. Если после выполнения операции необходимо поставить блок Решение, то связи операций с этим блоком также отображаются при помощи стрелок Связь предшествования».
Если между двумя операциями на схеме представлен блок Решение, то для моделирования передачи информации/документов из одной операции в другую используют стрелки типа Поток объектов».
В случае перехода на один уровень вверх относительно схемы под- процесса, разработанной в нотации Процедура, дорожки на схеме устанавливаются по должности или роли владельца подпроцесса.
На рис. 4.6.8 представлены варианты именования операции процесса в формате глагол + существительное. Также показаны ошибки, часто допускаемые при именовании операций.
Выполнить подготовку договора поставки оборудования
Правильно
Подготовить договор на поставку оборудования
Правильно
Выполнить подготовку договора поставки оборудования
Неправильно — тип и размер шрифта
Подготовка договора на поставку оборудования
Неправильно — именование при помощи
существительного
Договор поставки оборудования
Неправильно — вместо термина действия — существительное (договор)
Менеджер по продажам
Неправильно — вместо термина действия — название должности
Подготовить договор поставки оборудования с учетом наличия оборудования на складе, индивидуальных скидок клиенту, фазы Луны и методики расчета опускной цены с учетом коэффициента Неправильно — чрезмерно длинное название
операции
Рис. 4.6.8. Именование операций процесса
256
Бизнес-процессы. Моделирование, внедрение, управление
Стрелки типа Связь предшествования показывают последовательность выполнения операций процесса во времени. Каждая именованная стрелка в Business Studio — объект базы и хранится в справочнике стрелок. К именованным стрелкам типа Связь предшествования можно привязывать объекты из справочника Объекты деятельности (например, бумажные или электронные документы. К неименованным стрелкам привязать объекты невозможно. На рис. 4.6.9 показаны правильные и неправильные варианты применения стрелок на схеме процесса. Стрелки должны быть привязаны к операциям. Наличие стрелок, не привязанных к операциям (либо междиаграммным ссылкам, не допускается. Стрелки необходимо именовать. Нельзя использовать короткие, абстрактные названия да, договор, поступило письмо, информация. Они должны быть подробные, конкретные и отражать контекст того процесса, в рамках которого создаются.
Стрелки типа Связь предшествования желательно именовать, указывая:
название документа в именительном падеже;
—
описание результата выполнения операции в терминах со-
—
бытия.
Стрелки типа Поток объектов показывают движение объектов между операциями процесса. Под объектами понимаются любые объекты из справочника Объекты деятельности системы Business
Studio». В первую очередь это бумажные/электронные документы и информация. Стрелки Поток объектов используются там, где невозможно (нецелесообразно) использовать стрелки Связь предшествования, например при использовании блока Решение при описании межпроцессного взаимодействия при помощи информационного потока с использованием междиаграмм- ных ссылок
Рис. 4
.6
.9
. Использование стрелок типа Связь предшествования Операция Операция Связь предшествования полнить подготовку договора поставки оборудования Согласовать договор с клиентом Выполнена подготовка проекта договора на поставку оборудования полнить подготовку договора поставки оборудования Выполнить подготовку договора поставки оборудования Согласовать договор с клиентом Согласовать договор с клиентом Договор слишком общее, неконкретное название
стр
ел
ки
Неп
р
а
в
и
л
ьно
слишком общее, неконкретное название
стр
ел
ки
В
ы полнить подготовку договора поставки оборудования Выполнить подготовку договора поставки оборудования Согласовать договор с клиентом Согласовать договор с клиентом Проект договора на поставку оборудования стрелка не поименована
Опера ция
Операция Операция Операция Операция Операция Связь предшествования Связь предшествования Связь предшествования стрелка не прик
реп
лена
к операции Неправильно стрелка не прик
реп
лена
к операции Неправильно стрелка не прик
реп
лена
к о
пе
р
ац
и
ям
Неп
р
а
в
и
л
ьно
—
нача
ло
/к
онец
с
тре
лк
и
не
прикреплены ник о
дному
из
о
бъ
ек
тов
Опера ция
1
.6
.9
. Использование стрелок типа Связь предшествования Операция Операция Связь предшествования полнить подготовку договора поставки оборудования Согласовать договор с клиентом Выполнена подготовка проекта договора на поставку оборудования полнить подготовку договора поставки оборудования Выполнить подготовку договора поставки оборудования Согласовать договор с клиентом Согласовать договор с клиентом Договор слишком общее, неконкретное название
стр
ел
ки
Неп
р
а
в
и
л
ьно
слишком общее, неконкретное название
стр
ел
ки
В
ы полнить подготовку договора поставки оборудования Выполнить подготовку договора поставки оборудования Согласовать договор с клиентом Согласовать договор с клиентом Проект договора на поставку оборудования стрелка не поименована
Опера ция
Операция Операция Операция Операция Операция Связь предшествования Связь предшествования Связь предшествования стрелка не прик
реп
лена
к операции Неправильно стрелка не прик
реп
лена
к операции Неправильно стрелка не прик
реп
лена
к о
пе
р
ац
и
ям
Неп
р
а
в
и
л
ьно
—
нача
ло
/к
онец
с
тре
лк
и
не
прикреплены ник о
дному
из
о
бъ
ек
тов
Опера ция
1
258
Бизнес-процессы. Моделирование, внедрение, управление
Каждая именованная стрелка — объект базы и хранится в справочнике стрелок. К именованным стрелкам можно привязывать объекты из справочника Объекты деятельности (например, бумажные или электронные документы. К неименованным стрелкам привязать объекты невозможно.
На рис. 4.6.10 показаны правильные и неправильные варианты применения стрелок на схеме процесса.
Стрелки должны быть привязаны к операциям. Наличие стрелок, не привязанных к операциям (либо междиаграммным ссылкам, на схеме процесса не допускается.
Стрелки необходимо обязательно именовать, но нельзя использовать короткие, абстрактные названия типа Договор, Письмо, Информация. Они должны быть подробными, конкретными и содержать наименование или отражать суть тех документов информации, которые используются в рамках моделируемого процесса.
Стрелки типа Поток объектов можно именовать, указывая название документа (формулировку информационного потока) в именительном падеже.
Объекты типа Событие используются на схеме процесса для отображения событий. События бывают инициирующими процесс одно или более, промежуточными (одно или более, завершающими процесс (одно или более).
Промежуточные события можно использовать, когда временнáя последовательность выполнения операций процесса прерывается на неопределенное время.
Если походу моделирования возникает промежуточное событие, то рекомендуется разделить процесс на несколько подпроцессов.
На рис. 4.6.11 показаны правильные и неправильные варианты применения на схеме объектов типа Событие
Рис. 4
.6
.1 0
. Использование стрелок типа Поток объектов Операция Операция Поток объектов полнить подготовку договора поставки оборудования Согласовать договор с клиентом Проект договора на поставку оборудования полнить подготовку договора поставки оборудования Согласовать договор с клиентом Договор слишком общее, неконкретное название
стр
ел
ки
В
ы полнить подготовку договора поставки оборудования Выполнить подготовку договора поставки оборудования Согласовать договор с клиентом Согласовать договор с клиентом Выполнена подготовка проекта договора на поставку оборудования стрелка именована в терминах результат дей
ст
вия
»,
но
пос iiмiiыiiслiiу она п
р
ед
ст
ав
ля
ет
со
бо
й поток о
бъ
ек
то
в
Неп
р
а
в
и
л
ьно
стрелка не поименована
Опера ция
Операция Поток объектов стрелка не прик
реп
лена
к операции Неправильно —
нача
ло
/к
онец
с
тре
лк
и
не
прикреплены ник о
дному
из
о
бъ
ек
тов
Опера ция
Операция Операция Поток объектов стрелка не прик
реп
лена
к о
пе
р
ац
и
ям
Опера ция
Операция Поток объектов стрелка не прик
реп
лена
к операции 1
.6
.1 0
. Использование стрелок типа Поток объектов Операция Операция Поток объектов полнить подготовку договора поставки оборудования Согласовать договор с клиентом Проект договора на поставку оборудования полнить подготовку договора поставки оборудования Согласовать договор с клиентом Договор слишком общее, неконкретное название
стр
ел
ки
В
ы полнить подготовку договора поставки оборудования Выполнить подготовку договора поставки оборудования Согласовать договор с клиентом Согласовать договор с клиентом Выполнена подготовка проекта договора на поставку оборудования стрелка именована в терминах результат дей
ст
вия
»,
но
пос iiмiiыiiслiiу она п
р
ед
ст
ав
ля
ет
со
бо
й поток о
бъ
ек
то
в
Неп
р
а
в
и
л
ьно
стрелка не поименована
Опера ция
Операция Поток объектов стрелка не прик
реп
лена
к операции Неправильно —
нача
ло
/к
онец
с
тре
лк
и
не
прикреплены ник о
дному
из
о
бъ
ек
тов
Опера ция
Операция Операция Поток объектов стрелка не прик
реп
лена
к о
пе
р
ац
и
ям
Опера ция
Операция Поток объектов стрелка не прик
реп
лена
к операции 1
Рис. Использование событий Конец процесса подписания договора на поставку оборудования Зарегистрирован запрос клиента на поставку оборудования Потребность в оборудовании Начало процесса Утром За регистрирован запрос клиента на поставку оборудования Конец процесса абстрактная формулировка с
об
ы
ти
я
Н
еп
р
а
в
и
л
ьн
о — абстрактная формулировка события и н
еи
м
ен
ов
ан
на
я с
тр
ел
ка
Прави
л
ьно
Прави
л
ьно
П
рави
л
ьно
В
данном случае неизвестно, через какое время поступит письмо от клиента. Процесс прерывается на неопределенное время и ждет поступления письма
От править технико- коммерческое предложение (ТКП) клиенту Подготовить ответ на вопросы клиента по Т
К
П
ТК
П
отправлено клиенту Поступило письмо от клиента св опросами по Т
К
П
Прави
л
ьно
От править технико- коммерческое предложение (ТКП) клиенту Подготовить ответ на вопросы клиента по Т
К
П
Неп
р
а
в
и
л
ьно
в рамках процесса в
оз
ни
ка
ет
прерывание
, которое в д
анном
ва
р
иа
н
те
схемы визуально не опис
ано
З
ап рос клиента на поставку обо р
удова ни я
П
ос тупил запрос от клиента на поставку оборудования ТКП для клиента Письмо от клиента по Т
К
П
ТК
П для клиента Глава 4. Описание бизнес-процессов организации
261
Блок Решение используется на схемах процессов в качестве логического оператора (gateway). Обратите внимание, что Решение в Business Studio обладает всеми атрибутами класса Процесс, ноне может быть декомпозировано наследующий уровень.
Блок Решение именуется при помощи существительного. При- меры:
«Проверка принятого решения»;
—
«Проверка применимости условий типового предложения»;
—
«Сравнение величины запрашиваемой скидки с возможной»;
—
«Определение соответствия классификатору…».
—
На рис. 4.6.12 показаны правильные и неправильные варианты применения на схеме процесса блока «Решение».
Блок Решение необходимо использовать на схеме процесса при возникновении ситуации, требующей применения оператора исключающего логического ИЛИ (рис. 4.6.12, ситуация 1). В случае применения блока Решение необходимо дополнительно использовать стрелку Поток объектов для описания информационного потока между операциями процесса (если он существует. Ситуация 2 некорректна в части именования блока Решение и стрелок. Ситуация 3 некорректна, так как требовалось применение блока «Решение».
Для упрощения графической схемы в Business Studio
*
блок Решение не используется при возникновении ситуации, требующей применения оператора исключающего логического ИЛИ при объединении двух веток процесса (ситуация 4), а также оператора И ситуация Для моделирования межпроцессного взаимодействия в Business
Studio используют междиаграммные ссылки.
К ним могут быть привязаны как стрелки типа Поток объектов, таки стрелки Связь предшествования».
На рис. 4.6.13 показаны правильные и неправильные варианты применения на схеме процесса междиаграммных ссылок В других нотациях это не так
об
ы
ти
я
Н
еп
р
а
в
и
л
ьн
о — абстрактная формулировка события и н
еи
м
ен
ов
ан
на
я с
тр
ел
ка
Прави
л
ьно
Прави
л
ьно
П
рави
л
ьно
В
данном случае неизвестно, через какое время поступит письмо от клиента. Процесс прерывается на неопределенное время и ждет поступления письма
От править технико- коммерческое предложение (ТКП) клиенту Подготовить ответ на вопросы клиента по Т
К
П
ТК
П
отправлено клиенту Поступило письмо от клиента св опросами по Т
К
П
Прави
л
ьно
От править технико- коммерческое предложение (ТКП) клиенту Подготовить ответ на вопросы клиента по Т
К
П
Неп
р
а
в
и
л
ьно
в рамках процесса в
оз
ни
ка
ет
прерывание
, которое в д
анном
ва
р
иа
н
те
схемы визуально не опис
ано
З
ап рос клиента на поставку обо р
удова ни я
П
ос тупил запрос от клиента на поставку оборудования ТКП для клиента Письмо от клиента по Т
К
П
ТК
П для клиента Глава 4. Описание бизнес-процессов организации
261
Блок Решение используется на схемах процессов в качестве логического оператора (gateway). Обратите внимание, что Решение в Business Studio обладает всеми атрибутами класса Процесс, ноне может быть декомпозировано наследующий уровень.
Блок Решение именуется при помощи существительного. При- меры:
«Проверка принятого решения»;
—
«Проверка применимости условий типового предложения»;
—
«Сравнение величины запрашиваемой скидки с возможной»;
—
«Определение соответствия классификатору…».
—
На рис. 4.6.12 показаны правильные и неправильные варианты применения на схеме процесса блока «Решение».
Блок Решение необходимо использовать на схеме процесса при возникновении ситуации, требующей применения оператора исключающего логического ИЛИ (рис. 4.6.12, ситуация 1). В случае применения блока Решение необходимо дополнительно использовать стрелку Поток объектов для описания информационного потока между операциями процесса (если он существует. Ситуация 2 некорректна в части именования блока Решение и стрелок. Ситуация 3 некорректна, так как требовалось применение блока «Решение».
Для упрощения графической схемы в Business Studio
*
блок Решение не используется при возникновении ситуации, требующей применения оператора исключающего логического ИЛИ при объединении двух веток процесса (ситуация 4), а также оператора И ситуация Для моделирования межпроцессного взаимодействия в Business
Studio используют междиаграммные ссылки.
К ним могут быть привязаны как стрелки типа Поток объектов, таки стрелки Связь предшествования».
На рис. 4.6.13 показаны правильные и неправильные варианты применения на схеме процесса междиаграммных ссылок В других нотациях это не так
Рис. 4.6.12. Использование блока «Решение»
Выполнить классификацию запроса клиента
Информация о типе запроса клиента
Проверка типа запроса клиента
Запрос клиента на оказание услуг
За прос клиента Запрос клиента на поставку оборудования. Правильно
Выполнить классификацию запроса клиента
Запрос на оборудование
Нет
За прос клиента Да. Неправильно — несколько ошибок 1) не именована стрелка до Решения 2) некорректное наименование Решения
Выполнить классификацию запроса клиента
Информация о типе запроса клиента
Проверка типа запроса клиента
Запрос клиента на оказание услуг
За прос клиента Запрос клиента на поставку оборудования. Правильно
Выполнить классификацию запроса клиента
Запрос на оборудование
Нет
За прос клиента Да. Неправильно — несколько ошибок 1) не именована стрелка до Решения 2) некорректное наименование Решения
1 ... 9 10 11 12 13 14 15 16 ... 21
3) абстрактные имена у стрелок после Решения. Правильно — при слиянии потоков в ситуации, требующей применения исключающего логического ИЛИ, блок Решение не используется
ТКП для клиента согласовано
ТКП для клиента не согласовано. Правильно — в случае возникновения ситуации, требующей применения логического И, блок Решение не используется
Принять решение по премированию персонала
Принято решение выдать премии
Принято решение подарить ценные подарки. Неправильно — не использован блок Решение в случае возникновения ситуации применения исключающего логического «ИЛИ»
Выполнить классификацию запроса клиента
Запрос клиента на оказание услуг
Запрос клиента на поставку оборудования
Рис. 4.6.13. Использование междиаграммных ссылок
Правильно
Операция
Процесс...
Правильно
Операция
Процесс...
Договор на поставку оборудования
Неправильно — стрелка типа поток объектов не может быть именована в терминах действия/события
Операция
Процесс...
Заключен договор на...
Неправильно — стрелка не присоединена к операции
Операция
Процесс...
Договор на поставку оборудования
Неправильно — стрелка не присоединена к ссылке
Операция
Процесс...
Договор на поставку оборудования
Неправильно — стрелка типа вязь предшествования не может быть именована в терминах информации/документа
Операция
Процесс...
Договор на поставку оборудования
Неправильно — стрелка не присоединена к ссылке
Неправильно — стрелка не присоединена к операции
Операция
Процесс...
Операция
Процесс...
Заключен договор на...
Заключен договор на...
Заключен договор на
264
Бизнес-процессы. Моделирование, внедрение, управление
Если по смыслу модели нужно указать, что процессы обмениваются информацией/документами, ток междиаграммной ссылке привязывается стрелка типа Поток объектов. Если следует указать, что процессы выполняются последовательно, ток междиаграммной ссылке привязывается стрелка типа Связь предшествования».
Создавая междиаграммную ссылку, важно помнить, что соответствующая ссылка и стрелка появятся на той схеме процесса, на которую указывает ссылка.
Взаимодействие между процессами в рамках одной процессной ветки может быть показано при помощи механизма миграции стрелок с одного уровня модели на другой. Поясню. На схеме верхнего уровня один процесс связан с другим некоторым информационным потоком. При декомпозиции этих процессов на уровень вниз на схеме первого появится исходящая стрелка, а на схеме второго — входящая. В данном случае междиаграммная ссылка не используется. Однако если процессы находятся в разных процессных ветках, то использование междиаграммных ссылок при моделировании целесообразно и удобно.
Схема процесса в нотации Процедура при кажущейся простоте весьма информативна и удобна для описания. Можно сформулировать следующие преимущества этой нотации (в случае ее использования в Business представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);
быстрота создания графических схем для целей регламентации;
—
возможность повышения информативности схем процессов за счет гибкого использования событий и именованных стрелок (одновременно с возможностью привязки документов к стрелками последующей выгрузки информации в регламентирующие документы);
схемы процессов просты и понятны всем сотрудникам даже без специального обучения
Правильно
Операция
Процесс...
Правильно
Операция
Процесс...
Договор на поставку оборудования
Неправильно — стрелка типа поток объектов не может быть именована в терминах действия/события
Операция
Процесс...
Заключен договор на...
Неправильно — стрелка не присоединена к операции
Операция
Процесс...
Договор на поставку оборудования
Неправильно — стрелка не присоединена к ссылке
Операция
Процесс...
Договор на поставку оборудования
Неправильно — стрелка типа вязь предшествования не может быть именована в терминах информации/документа
Операция
Процесс...
Договор на поставку оборудования
Неправильно — стрелка не присоединена к ссылке
Неправильно — стрелка не присоединена к операции
Операция
Процесс...
Операция
Процесс...
Заключен договор на...
Заключен договор на...
Заключен договор на
264
Бизнес-процессы. Моделирование, внедрение, управление
Если по смыслу модели нужно указать, что процессы обмениваются информацией/документами, ток междиаграммной ссылке привязывается стрелка типа Поток объектов. Если следует указать, что процессы выполняются последовательно, ток междиаграммной ссылке привязывается стрелка типа Связь предшествования».
Создавая междиаграммную ссылку, важно помнить, что соответствующая ссылка и стрелка появятся на той схеме процесса, на которую указывает ссылка.
Взаимодействие между процессами в рамках одной процессной ветки может быть показано при помощи механизма миграции стрелок с одного уровня модели на другой. Поясню. На схеме верхнего уровня один процесс связан с другим некоторым информационным потоком. При декомпозиции этих процессов на уровень вниз на схеме первого появится исходящая стрелка, а на схеме второго — входящая. В данном случае междиаграммная ссылка не используется. Однако если процессы находятся в разных процессных ветках, то использование междиаграммных ссылок при моделировании целесообразно и удобно.
Схема процесса в нотации Процедура при кажущейся простоте весьма информативна и удобна для описания. Можно сформулировать следующие преимущества этой нотации (в случае ее использования в Business представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);
быстрота создания графических схем для целей регламентации;
—
возможность повышения информативности схем процессов за счет гибкого использования событий и именованных стрелок (одновременно с возможностью привязки документов к стрелками последующей выгрузки информации в регламентирующие документы);
схемы процессов просты и понятны всем сотрудникам даже без специального обучения
Глава 4. Описание бизнес-процессов организации
265
простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны — обучение можно проводить силами сотрудников отдела организационного развития);
схемы процессов являются кросс-функциональными, что удобно для описания сквозных процессов компании;
можно выгружать и редактировать схемы в MS Visio (при не-
—
обходимости).
Среда моделирования Business Studio позволяет быстро создавать процессную модель компании. Информацию о процессах можно выгружать из системы в виде регламентирующих документов в требуемом формате.
В этом параграфе я привел описание требований к стандартному использованию нотации Процедура Business Studio. Но при создании корпоративного стандарта описания процессов вы можете разработать свои правила применения этой нотации. Хочу подчеркнуть, что не бывает идеальных нотаций и стандартов их применения. Важно сделать свой, понятный всем внутренний стандарт описания, опробовать его на практике, а затем использовать в текущей деятельности. Информативность графических схем процессов
Одна из важнейших целей формирования графических схем процессов их последующее использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, не обученные сложным нотациям, не имеющие навыков системного анализа. Для них очень важны простота и наглядность схем. Сложные, запутанные схемы, содержащие массу условных обозначений, плохо воспринимаются, и это затрудняет их практическое использование. Поэтому очень важен корректный выбор и использование нотации описания процессов. По каким критериям следует выбирать, как сравнивать разные нотации между собой Рассмотрим следующие популярные нотации и попытаемся ответить на эти вопросы
266
Бизнес-процессы. Моделирование, внедрение, управление
«Простая блок-схема» (с отображением движения документов, с использованием блока «решение»);
«Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
«Процедура» системы Business Studio (один из возможных вариантов представления В качестве тестового примера я выбрал простой и понятный процесс. Результаты его описания представлены на рис. На рис. 4.7.1 последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов при помощи тонких пунктирных стрелок. Блоки Решение использованы классическим образом. Они отображают информацию вопросы, от которых зависит последующий ход процесса. Такой подход к использованию ромбиков — весьма распространенное явление. Но вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если вдуматься, то ценность (смысл) рисования этих ромбиков не очевидна. Что это за объекты — операции процесса, события Вроде бы ни тони другое. Это, скорее, операторы принятия решения по какому- либо условию. Но ведьмы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе ромбик был бы полноценной операцией сравнения условий. Нона схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы. Задумайтесь, корректно ли показывать ромбики отдельно от операции процесса на схеме Вместо этого можно:
описать логику принятия решения в виде последовательности операций на схеме рассматриваемого процесса;
описать логику в виде схемы шагов соответствующего под-
—
процесса, переходя на уровень ниже;
описать логику текстом (в текстовых атрибутах операции) ив последующем вывести в регламент выполнения процесса
265
простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны — обучение можно проводить силами сотрудников отдела организационного развития);
схемы процессов являются кросс-функциональными, что удобно для описания сквозных процессов компании;
можно выгружать и редактировать схемы в MS Visio (при не-
—
обходимости).
Среда моделирования Business Studio позволяет быстро создавать процессную модель компании. Информацию о процессах можно выгружать из системы в виде регламентирующих документов в требуемом формате.
В этом параграфе я привел описание требований к стандартному использованию нотации Процедура Business Studio. Но при создании корпоративного стандарта описания процессов вы можете разработать свои правила применения этой нотации. Хочу подчеркнуть, что не бывает идеальных нотаций и стандартов их применения. Важно сделать свой, понятный всем внутренний стандарт описания, опробовать его на практике, а затем использовать в текущей деятельности. Информативность графических схем процессов
Одна из важнейших целей формирования графических схем процессов их последующее использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, не обученные сложным нотациям, не имеющие навыков системного анализа. Для них очень важны простота и наглядность схем. Сложные, запутанные схемы, содержащие массу условных обозначений, плохо воспринимаются, и это затрудняет их практическое использование. Поэтому очень важен корректный выбор и использование нотации описания процессов. По каким критериям следует выбирать, как сравнивать разные нотации между собой Рассмотрим следующие популярные нотации и попытаемся ответить на эти вопросы
266
Бизнес-процессы. Моделирование, внедрение, управление
«Простая блок-схема» (с отображением движения документов, с использованием блока «решение»);
«Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
«Процедура» системы Business Studio (один из возможных вариантов представления В качестве тестового примера я выбрал простой и понятный процесс. Результаты его описания представлены на рис. На рис. 4.7.1 последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов при помощи тонких пунктирных стрелок. Блоки Решение использованы классическим образом. Они отображают информацию вопросы, от которых зависит последующий ход процесса. Такой подход к использованию ромбиков — весьма распространенное явление. Но вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если вдуматься, то ценность (смысл) рисования этих ромбиков не очевидна. Что это за объекты — операции процесса, события Вроде бы ни тони другое. Это, скорее, операторы принятия решения по какому- либо условию. Но ведьмы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе ромбик был бы полноценной операцией сравнения условий. Нона схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы. Задумайтесь, корректно ли показывать ромбики отдельно от операции процесса на схеме Вместо этого можно:
описать логику принятия решения в виде последовательности операций на схеме рассматриваемого процесса;
описать логику в виде схемы шагов соответствующего под-
—
процесса, переходя на уровень ниже;
описать логику текстом (в текстовых атрибутах операции) ив последующем вывести в регламент выполнения процесса
Рис. 4.7.1. Схема процесса в нотации Простая блок-схема» в MS Visio сдвижением документов, с использованием блока «Решение»)
Анализ доставок за предыдущий день. Корректировка графика доставки наследующий день
Диспетчер
Начальник отдела
Менеджер по закупке
График согласован?
Блок «Решение»
Ежедневно вечером с 19.00 до Конец процесса
Событие
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Выполнить анализ отчета
Выполнить корректировку графика доставки
Расформировать заказ
Согласовать график доставки
Операция процесса
Получить информацию о согласовании графика доставки
Сформировать/скоррек- тировать график доставки наследующий день
Отчет по недоставленным товарам в MS Комплект отчетов
Требования по срокам передоставки
Информация по передоставкам
График доставки наследующий день
Информация о согласовании графика доставки
Информация в электронной форме
Информация по расформированию заказов
Стрелка предшествования
Стрелка потока документов/
информации
Нужно ли выносить описание логики принятия решений из операции?
Добавляет ли ценность сточки зрения понятности схемы сотруднику?
Да
Да
Да
Нет
Нет
Нет
Передоставка возможна?
Все заказы доставлены в срок
268
Бизнес-процессы. Моделирование, внедрение, управление
Сформулируем плюсы и минусы рассмотренного (рис. 4.7.1) способа использования ромбиков.
Простая блок-схема в MS Visio (сдвижением документов, с использованием блока «Решение»)
Плюс
Минус
Наглядное отображение логики выбора тех
1. или иных выходов процесса.
Акцентирование внимания исполнителя
2. на точке принятия решения/ветвление процесса в зависимости от условий
Вынос логики принятия решения за пределы
1. операции процесса (некорректно сточки зрения формальной декомпозиции процессов).
Неудобства при документировании процесса
2. приходится дублировать ромбики текстом при формировании текстового описания операции).
Схема процесса перегружена информацией. Ромбики часто используются слишком формально, без реальной необходимости
На рис. 4.7.2 приведен пример того же процесса, только описанного без использования блоков Решение и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на рис. 4.7.1. Схема на рис. 4.7.2 выглядит гораздо проще от графических элементов не рябит в глазах, ас точки зрения информативности она понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению, током- бинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании. (Еще раз замечу не вся информация о процессе должна быть представлена на его графической схеме. При работе с объектной моделью значительная часть сведений хранится в виде атрибутов объектов в базе данных.)
Плюсы и минусы графического изображения процесса в форме, представленной на рис. 4.7.2, показаны ниже.
Простая блок-схема в MS Visio (без движения документов, без использования блока «Решение»)
Плюс
Минус
Простота и наглядность для исполнителя. На лист можно поместить больше информации, чем в случае формата, использованного на рис. Логика принятия решений скрыта внутри операций процесса.
Графическую схему целесообразно сопровождать таблицей с текстовым описанием операций процесса
Диспетчер
Начальник отдела
Менеджер по закупке
Анализ доставок за предыдущий день. Корректировка графика доставки наследующий день
Ежедневно вечером с 19.00 до Конец процесса
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Выполнить анализ отчета
Выполнить корректировку графика доставки
Расформировать заказ
Согласовать график доставки
Получить информацию о согласовании графика доставки
Сформировать/скоррек- тировать график доставки наследующий день
Отчет по недоставленным товарам
График доставки наследующий день
Комплект отчетов
(недоставленные товары, отчет по инкассации)
Информация об отсутствии замечаний по отчету
Информация по расформированию заказов
Информация по передоставкам заказов
Информация по передоставкам
Информация по расформированию заказов
Информация для корректировки графика
Информация о согласовании графика доставки
Рис. 4.7.2. Схема процесса в нотации Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)
Событие
Операция процесса
Универсальная стрелка связи
270
Бизнес-процессы. Моделирование, внедрение, управление
Применение схем в таком же формате, как представленный на рис. 4.7.2, удобно как для разработчиков (бизнес-аналитиков), таки для сотрудников.
На рис. 4.7.3 показана схема процесса, сформированная в нотации Процедура среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки Решение использованы нестандартным образом — не как графический элемент для отображения ветвления (оператор логики, развилка, гейтвей), а как полноценная операция процесса, связанная с принятием решений. Использование ромбика (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты ромбика можно внести любую текстовую информацию описание, начало, завершение, требование к сроками т. п.
Вторая особенность схемы процесса на рис. 4.7.3 — применение стрелок. Для отображения последовательности операций полезно использовать стрелку с одним наконечником — стрелку Связь предшествования. Для отображения движения документов применяют стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок — стрелками Связь предшествования, а к именованным стрелкам привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход позволяет сократить количество графических элементов на схеме процесса и при этом вывести в регламент процесса необходимую информацию о входящих и исходящих документах.
Таким образом, не загромождая схему лишними элементами, мы можем полностью описать процесс и выгрузить в регламент всю необходимую информацию.
Тот факт, что название стрелки вне зависит от документов, которые к ней привязаны, позволяет именовать стрелки понятными удобным для сотрудников образом. Например, к стрелке предшествования Подготовлен комплект отчетов
* В Business Studio ромбик обладает почти всеми атрибутами полноценного процесса, ноне может быть декомпозирован. Это нужно иметь ввиду при описании процессов в этой системе. В параграфе 4.6 я как раз не рекомендую использовать Решение как полноценную операцию.
Анализ доставок за предыдущий день. Корректировка графика доставки наследующий день
Диспетчер
Начальник отдела
Менеджер по закупке
График согласован?
Блок «Решение»
Ежедневно вечером с 19.00 до Конец процесса
Событие
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Выполнить анализ отчета
Выполнить корректировку графика доставки
Расформировать заказ
Согласовать график доставки
Операция процесса
Получить информацию о согласовании графика доставки
Сформировать/скоррек- тировать график доставки наследующий день
Отчет по недоставленным товарам в MS Комплект отчетов
Требования по срокам передоставки
Информация по передоставкам
График доставки наследующий день
Информация о согласовании графика доставки
Информация в электронной форме
Информация по расформированию заказов
Стрелка предшествования
Стрелка потока документов/
информации
Нужно ли выносить описание логики принятия решений из операции?
Добавляет ли ценность сточки зрения понятности схемы сотруднику?
Да
Да
Да
Нет
Нет
Нет
Передоставка возможна?
Все заказы доставлены в срок
268
Бизнес-процессы. Моделирование, внедрение, управление
Сформулируем плюсы и минусы рассмотренного (рис. 4.7.1) способа использования ромбиков.
Простая блок-схема в MS Visio (сдвижением документов, с использованием блока «Решение»)
Плюс
Минус
Наглядное отображение логики выбора тех
1. или иных выходов процесса.
Акцентирование внимания исполнителя
2. на точке принятия решения/ветвление процесса в зависимости от условий
Вынос логики принятия решения за пределы
1. операции процесса (некорректно сточки зрения формальной декомпозиции процессов).
Неудобства при документировании процесса
2. приходится дублировать ромбики текстом при формировании текстового описания операции).
Схема процесса перегружена информацией. Ромбики часто используются слишком формально, без реальной необходимости
На рис. 4.7.2 приведен пример того же процесса, только описанного без использования блоков Решение и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на рис. 4.7.1. Схема на рис. 4.7.2 выглядит гораздо проще от графических элементов не рябит в глазах, ас точки зрения информативности она понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению, током- бинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании. (Еще раз замечу не вся информация о процессе должна быть представлена на его графической схеме. При работе с объектной моделью значительная часть сведений хранится в виде атрибутов объектов в базе данных.)
Плюсы и минусы графического изображения процесса в форме, представленной на рис. 4.7.2, показаны ниже.
Простая блок-схема в MS Visio (без движения документов, без использования блока «Решение»)
Плюс
Минус
Простота и наглядность для исполнителя. На лист можно поместить больше информации, чем в случае формата, использованного на рис. Логика принятия решений скрыта внутри операций процесса.
Графическую схему целесообразно сопровождать таблицей с текстовым описанием операций процесса
Диспетчер
Начальник отдела
Менеджер по закупке
Анализ доставок за предыдущий день. Корректировка графика доставки наследующий день
Ежедневно вечером с 19.00 до Конец процесса
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Выполнить анализ отчета
Выполнить корректировку графика доставки
Расформировать заказ
Согласовать график доставки
Получить информацию о согласовании графика доставки
Сформировать/скоррек- тировать график доставки наследующий день
Отчет по недоставленным товарам
График доставки наследующий день
Комплект отчетов
(недоставленные товары, отчет по инкассации)
Информация об отсутствии замечаний по отчету
Информация по расформированию заказов
Информация по передоставкам заказов
Информация по передоставкам
Информация по расформированию заказов
Информация для корректировки графика
Информация о согласовании графика доставки
Рис. 4.7.2. Схема процесса в нотации Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)
Событие
Операция процесса
Универсальная стрелка связи
270
Бизнес-процессы. Моделирование, внедрение, управление
Применение схем в таком же формате, как представленный на рис. 4.7.2, удобно как для разработчиков (бизнес-аналитиков), таки для сотрудников.
На рис. 4.7.3 показана схема процесса, сформированная в нотации Процедура среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки Решение использованы нестандартным образом — не как графический элемент для отображения ветвления (оператор логики, развилка, гейтвей), а как полноценная операция процесса, связанная с принятием решений. Использование ромбика (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты ромбика можно внести любую текстовую информацию описание, начало, завершение, требование к сроками т. п.
Вторая особенность схемы процесса на рис. 4.7.3 — применение стрелок. Для отображения последовательности операций полезно использовать стрелку с одним наконечником — стрелку Связь предшествования. Для отображения движения документов применяют стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок — стрелками Связь предшествования, а к именованным стрелкам привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход позволяет сократить количество графических элементов на схеме процесса и при этом вывести в регламент процесса необходимую информацию о входящих и исходящих документах.
Таким образом, не загромождая схему лишними элементами, мы можем полностью описать процесс и выгрузить в регламент всю необходимую информацию.
Тот факт, что название стрелки вне зависит от документов, которые к ней привязаны, позволяет именовать стрелки понятными удобным для сотрудников образом. Например, к стрелке предшествования Подготовлен комплект отчетов
* В Business Studio ромбик обладает почти всеми атрибутами полноценного процесса, ноне может быть декомпозирован. Это нужно иметь ввиду при описании процессов в этой системе. В параграфе 4.6 я как раз не рекомендую использовать Решение как полноценную операцию.
Рис. 4.7.3. Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение»)
Диспетчер
Начальник отдела
Менеджер по закупке
Анализ доставок за предыдущий день. Корректировка графика доставки наследующий день
Согласовать график доставки
Ежедневно вечером с 19.00 до Конец процесса
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Выполнить корректировку графика доставки
Расформировать заказ
Получить информацию о согласовании графика доставки
Сформировать/скоррек- тировать график доставки наследующий день
Подготовлен отчет по недоставленным заказам
О
тче т по не доставленным заказам Подготовлен комплект отчетов
Требуется передоставка заказов
Требуется расформирование заказов
Замечаний по отчету и пожеланий нет
График доставки наследующий день
Информация для корректировки графика
Информация о согласовании графика
Инф ор м
ац и
я по пере доставкам Один из возможных вариантов (А) использования блока Решение. Недостаток варианта в том, что блок Решение нельзя декомпозировать
Можно показать поток документов в виде отдельного типа стрелок либо привязать конкретные документы к стрелкам предшествования
Комплект отчетов (недоставленные товары, отчет по инкассации)
Можно по-разному именовать стрелки для повышения информативности схемы
Информация о расформировании заказов
Выполнить анализ отчетов
272
Бизнес-процессы. Моделирование, внедрение, управление
можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию, — Сформировать отчет по инкассации задень. (Замечу, что в методологии компании СТУ
*
стрелка после операции процесса — это сущность, а не событие. После блока Решение можно показывать его возможные результаты.)
Плюсы и минусы графического представления процесса на рис. 4.7.3 показаны ниже.
Процедура системы Business Studio (вариант с нестандартным использованием блоков
«Решение»)
Плюс
Минус
Простота представления. Акцентирование внимания исполнителя
2. на операции, связанной с принятием решения ветвлением процесса.
На листе формата А может располагаться
3. большой объем информации
Блок Решение не декомпозируется.
1. Неоднозначность в именовании стрелок
2. возможны разночтения)
Обратите внимание, что в Business Studio нотация Процедура может использоваться по-разному.
На рис. 4.7.4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Замечу, что в схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий. Человек, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или без помощи квалифицированного бизнес-аналитика.
Замечу, что схема процесса в нотации ARIS eEPC занимает намного больше места, чем схемы на предыдущих рисунках. Трудоемкость ее формирования также гораздо выше СТУ — Современные технологии управления (г. Самара) — разработчик Business
Studio.
Диспетчер
Начальник отдела
Менеджер по закупке
Анализ доставок за предыдущий день. Корректировка графика доставки наследующий день
Согласовать график доставки
Ежедневно вечером с 19.00 до Конец процесса
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Выполнить корректировку графика доставки
Расформировать заказ
Получить информацию о согласовании графика доставки
Сформировать/скоррек- тировать график доставки наследующий день
Подготовлен отчет по недоставленным заказам
О
тче т по не доставленным заказам Подготовлен комплект отчетов
Требуется передоставка заказов
Требуется расформирование заказов
Замечаний по отчету и пожеланий нет
График доставки наследующий день
Информация для корректировки графика
Информация о согласовании графика
Инф ор м
ац и
я по пере доставкам Один из возможных вариантов (А) использования блока Решение. Недостаток варианта в том, что блок Решение нельзя декомпозировать
Можно показать поток документов в виде отдельного типа стрелок либо привязать конкретные документы к стрелкам предшествования
Комплект отчетов (недоставленные товары, отчет по инкассации)
Можно по-разному именовать стрелки для повышения информативности схемы
Информация о расформировании заказов
Выполнить анализ отчетов
272
Бизнес-процессы. Моделирование, внедрение, управление
можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию, — Сформировать отчет по инкассации задень. (Замечу, что в методологии компании СТУ
*
стрелка после операции процесса — это сущность, а не событие. После блока Решение можно показывать его возможные результаты.)
Плюсы и минусы графического представления процесса на рис. 4.7.3 показаны ниже.
Процедура системы Business Studio (вариант с нестандартным использованием блоков
«Решение»)
Плюс
Минус
Простота представления. Акцентирование внимания исполнителя
2. на операции, связанной с принятием решения ветвлением процесса.
На листе формата А может располагаться
3. большой объем информации
Блок Решение не декомпозируется.
1. Неоднозначность в именовании стрелок
2. возможны разночтения)
Обратите внимание, что в Business Studio нотация Процедура может использоваться по-разному.
На рис. 4.7.4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Замечу, что в схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий. Человек, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или без помощи квалифицированного бизнес-аналитика.
Замечу, что схема процесса в нотации ARIS eEPC занимает намного больше места, чем схемы на предыдущих рисунках. Трудоемкость ее формирования также гораздо выше СТУ — Современные технологии управления (г. Самара) — разработчик Business
Studio.
Рис. 4.7.4. Схема процесса в нотации ARIS eEPC (сформирована в Business Studio)
OR — неисключающее логическое ИЛИ
XOR — исключающее логическое «ИЛИ».
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Выполнить анализ отчетов
XOR
XOR
OR
OR
Расформировать заказ
Сформировать/скоррек- тировать график доставки наследующий день
Диспетчер
Диспетчер
Менеджер по закупке выполняет выполняет выполняет выполняет выполняет
Диспетчер
Выполнить корректировку графика доставки выполняет
Диспетчер
Согласовать график доставки выполняет
Начальник отдела
Диспетчер
Комплект отчетов
График доставки на следующи день
Требования по передоставке
Требования по расформированию заказов
Ежедневно вечером с 19.00 до Сформирован комплект отчетов
Необходимо расформировать заказ
Необходима передоставка
Передоставки учтены в графике доставок
Сформирован график доставки наследующий день
Все заказы доставлены в срок
Заказы расформированы
Отчет по недоставленным товарам сформирован
274
OR — неисключающее логическое ИЛИ
XOR — исключающее логическое «ИЛИ».
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Выполнить анализ отчетов
XOR
XOR
OR
OR
Расформировать заказ
Сформировать/скоррек- тировать график доставки наследующий день
Диспетчер
Диспетчер
Менеджер по закупке выполняет выполняет выполняет выполняет выполняет
Диспетчер
Выполнить корректировку графика доставки выполняет
Диспетчер
Согласовать график доставки выполняет
Начальник отдела
Диспетчер
Комплект отчетов
График доставки на следующи день
Требования по передоставке
Требования по расформированию заказов
Ежедневно вечером с 19.00 до Сформирован комплект отчетов
Необходимо расформировать заказ
Необходима передоставка
Передоставки учтены в графике доставок
Сформирован график доставки наследующий день
Все заказы доставлены в срок
Заказы расформированы
Отчет по недоставленным товарам сформирован
274
1 ... 10 11 12 13 14 15 16 17 ... 21
Бизнес-процессы. Моделирование, внедрение, управление
Схема процесса в нотации ARIS eEPC (построена в Business Studio)
Плюс
Минус
При формировании схемы выдерживается
1. строгая, формальная логика процесса.
Четко определены все события, возникающие
2. походу процесса Сложность восприятия. Трудоемкость формирования схемы. У сотрудников должны быть специальные навыки и опыт интерпретации подобных схем.
Информационная избыточность. Занимает слишком много места, что неудобно
5. для документирования На рис. 4.7.5 изображен тот же процесс в нотации BPMN. Как видим, этот рисунок похож на рис. 4.7.1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.
Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: лишь один вид развилок из пяти имеющихся и один вид задач из восьми. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но и несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, это более строгая нотация в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована и на то, что ее будут читать люди, и на непосредственное исполнение специальным программным обеспечением — движком системы. В тоже время, как показывает данный пример, при использовании ограниченного подмножества BPMN оказывается не сложнее привычной блок-схемы.
При описании процессов на операционном уровне нужно стремиться к простоте и понятности схем для сотрудников. Использование сложных нотаций приводит к:
трудностям при интерпретации схем рядовыми сотрудниками;
—
невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение
Планирование доставки
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Скорректировать график доставки
Сформировать график доставки
График согласован
Задача
Согласовать график доставки
Расформировать заказ
Проанализировать отчеты
Диспетчер
Начальник отдела
Менеджер по закупке
Развилка
Данные
Стоп
Старт
Отчет по инкассации задень График доставки
Ежедневно в да нет нет да
Возможна передоставка?
нет да
Отчет по недоставленным товарам
Требования по передоставке
Все заказы доставлены в срок?
Согласован?
Рис. 4.7.5. Схема процесса в нотации BPMN 2.0
Сформировать отчет по недоставленным товарам
Сформировать отчет по инкассации задень Скорректировать график доставки
Сформировать график доставки
График согласован
Задача
Согласовать график доставки
Расформировать заказ
Проанализировать отчеты
Диспетчер
Начальник отдела
Менеджер по закупке
Развилка
Данные
Стоп
Старт
Отчет по инкассации задень График доставки
Ежедневно в да нет нет да
Возможна передоставка?
нет да
Отчет по недоставленным товарам
Требования по передоставке
Все заказы доставлены в срок?
Согласован?
Рис. 4.7.5. Схема процесса в нотации BPMN 2.0
276
Бизнес-процессы. Моделирование, внедрение, управление
значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
дополнительным сложностям при документировании схем например, большой объем).
Нотация моделирования должна соответствовать уровню про- цессной культуры организации. Если сотрудники компании делают первые шаги в области описания процессов, то желательно выбрать простую, наглядную и удобную нотацию. Формирование регламентирующих документов на основе описания процессов
После того как процессы описаны в среде моделирования (говоря шире — создана объектная модель организации, можно и нужно использовать эту информацию для регламентации деятельности.
В этом параграфе приведен пример использования среды моделирования для формирования регламентирующих документов. Рассматриваются процессы управления транспортным отделом одной из российских компаний (методика определения процессов управления представлена в главе 6). С технической точки зрения точно также можно описывать любые процессы и другие объекты регламентации (подразделения, должности).
На рис. 4.8.1 показана структура процессов управления транспортным отделом (ТО) крупной торговой компании, разработанная в рамках проекта, в котором я в свое время принимал участие.
Представлен процесс управления транспортным отделом (ТО) торговой компании «Оптима» (г. Ижевск. Описание процессов выполнено в среде моделирования Business Studio. На рисунке слева видно дерево процессов, в котором процессы управления структурированы по соответствующим контурам.
Для описания объекта модели Управление ТО и контуров управления использована нотация Процесс. Это наиболее простая нотация в Business Studio, нов рамках предложенной задачи ее использование вполне адекватно
Глава 4. Описание бизнес-процессов организации
277
Для описания процессов внутри контуров управления использована нотация Процедура. На рис. 4.8.1 показана кросс-фун кци о наль- ная схема процесса Корректировка потребности в автотранспорте на месяц/квартал». В рамках данной модели все процессы управления описаны в виде подобных схем.
Для каждого процесса управления и для каждой операции процесса были заполнены текстовые атрибуты:
содержание деятельности;
—
начало процесса;
—
результат процесса.
—
Этих атрибутов на первых порах вполне достаточно, но можно использовать и другие (в том числе создавать новые, необходимые бизнес-аналитику).
Для выгрузки описания процессов управления из Business Studio был разработан специальный отчет, который включает информацию о процессах на трех уровнях:
Рис. 4.8.1. Структура процессов управления транспортным отделом
278
Бизнес-процессы. Моделирование, внедрение, управление
описание контура управления) описание процесса в контуре управления) описание операций процесса (в табличной форме) и схему
3) процесса.
На рис. 4.8.2 показана работа мастера отчетов среды моделирования. При помощи системы так называемых привязок была сформирована необходимая структура отчета. Затем создали и отредактировали шаблон отчета — регламент процесса управления на трех уровнях. После этого готовый отчет был сохранен в папке пользовательских отчетов среды моделирования Business Studio и запущенна выполнение для объекта Управление ТО (рис. Отчет, запущенный для объекта модели Управление ТО, сгене- рировал документ в MS Word и вывел всю информацию о контурах и процессах управления в нужном формате. Автоматически было получено содержание документа (рис. Рис. 4.8.2. Мастер отчетов Business Studio. Разработка регламента управления на трех уровнях
280
Бизнес-процессы. Моделирование, внедрение, управление
На рис. 4.8.5 показан формат вывода информации для каждого процесса управления. Он включает в себя таблицу и графическую схему процесса, размещенную на листе формата А. Видно, что описание операций процесса выводится в виде таблицы, содержащей следующие столбцы:
номер операции;
—
наименование операции;
—
исполнитель;
—
инициирующие события;
—
входящие документы;
—
описание операции;
—
завершающие события;
—
исходящие документы.
—
Рис. 4.8.5. Вывод информации о процессе управления в табличной и графической форме
282
Бизнес-процессы. Моделирование, внедрение, управление
процесса, и походу формирования схемы процесс пошел совершенно не так, как надо.
Напомню, что границы целесообразно определять по входам/вы- ходам (то есть движению информационных и материальных ресурсов) и событиям (инициирующими завершающим. Привязка к системе процессов
В предыдущем случае мы говорили о том, что процесс ушел не туда. Еще одна из причин такой ситуации — отсутствие системного видения бизнес-процессов организации. Если иерархического справочника процессов нетто при попытке описать какой-то процесс, скорее всего, возникнет ситуация захвата областей из других процессов и т. п. Затем последуют малопродуктивные споры, как провести границы. Поскольку переделка схем требует времени, появляется искушение согласовать кривые границы процессов и т. д. рис. Рис. 4.9.1. Выход заграницы процессов
Рис. 4.9.2. Конфликты на границах процессов
277
Для описания процессов внутри контуров управления использована нотация Процедура. На рис. 4.8.1 показана кросс-фун кци о наль- ная схема процесса Корректировка потребности в автотранспорте на месяц/квартал». В рамках данной модели все процессы управления описаны в виде подобных схем.
Для каждого процесса управления и для каждой операции процесса были заполнены текстовые атрибуты:
содержание деятельности;
—
начало процесса;
—
результат процесса.
—
Этих атрибутов на первых порах вполне достаточно, но можно использовать и другие (в том числе создавать новые, необходимые бизнес-аналитику).
Для выгрузки описания процессов управления из Business Studio был разработан специальный отчет, который включает информацию о процессах на трех уровнях:
Рис. 4.8.1. Структура процессов управления транспортным отделом
278
Бизнес-процессы. Моделирование, внедрение, управление
описание контура управления) описание процесса в контуре управления) описание операций процесса (в табличной форме) и схему
3) процесса.
На рис. 4.8.2 показана работа мастера отчетов среды моделирования. При помощи системы так называемых привязок была сформирована необходимая структура отчета. Затем создали и отредактировали шаблон отчета — регламент процесса управления на трех уровнях. После этого готовый отчет был сохранен в папке пользовательских отчетов среды моделирования Business Studio и запущенна выполнение для объекта Управление ТО (рис. Отчет, запущенный для объекта модели Управление ТО, сгене- рировал документ в MS Word и вывел всю информацию о контурах и процессах управления в нужном формате. Автоматически было получено содержание документа (рис. Рис. 4.8.2. Мастер отчетов Business Studio. Разработка регламента управления на трех уровнях
Глава 4. Описание бизнес-процессов организации
279
Рис. 4.8.3. Запуск отчета для объекта Управление ТО»
Рис. 4.8.4. Содержание регламента процесса управления, полученное автоматически в результате запуска отчета в среде моделирования Business
Studio
279
Рис. 4.8.3. Запуск отчета для объекта Управление ТО»
Рис. 4.8.4. Содержание регламента процесса управления, полученное автоматически в результате запуска отчета в среде моделирования Business
Studio
280
Бизнес-процессы. Моделирование, внедрение, управление
На рис. 4.8.5 показан формат вывода информации для каждого процесса управления. Он включает в себя таблицу и графическую схему процесса, размещенную на листе формата А. Видно, что описание операций процесса выводится в виде таблицы, содержащей следующие столбцы:
номер операции;
—
наименование операции;
—
исполнитель;
—
инициирующие события;
—
входящие документы;
—
описание операции;
—
завершающие события;
—
исходящие документы.
—
Рис. 4.8.5. Вывод информации о процессе управления в табличной и графической форме
Глава 4. Описание бизнес-процессов организации
281
Графическая схема процесса представлена в кросс-фун к ци ональ- ном виде. Объем регламента процесса управления составил для процесса Управления ТО около 70 страниц в MS Word, что совсем немного для такого значительного количества процессов.
Отмечу, что среда моделирования Business Studio позволяет формировать и выгружать практически любые отчеты, нужные для регламентации деятельности организации, в том числе:
регламенты выполнения процессов;
—
положения о подразделениях;
—
должностные инструкции (на должности и роли. Особенности создания корректных схем процессов
В этом параграфе мы остановимся на особенностях создания корректных схем бизнес-процессов. Неопытные бизнес-аналитики или сотрудники подразделений, привлеченные к работе по описанию процессов, подчас рисуют никуда негодные схемы. Как этого избежать Конечно, только после получения специалистом нужной квалификации и опыта качество графических схем становится более или менее приемлемым. Но есть несколько аспектов, учет которых позволит даже неопытным в этом деле сотрудникам разрабатывать схемы приемлемого качества. Рассмотрим их. Корректное определение границ процесса
Для успешного описания процесса прежде всего необходимо корректно определить его границы. Если пренебречь этим простым правилом, тов результате описания получается совершенно не то, чего ожидали (рис. 4.9.1). При внимательном изучении содержания схемы и сравнении ее с названием оказывается, что для описания выбрали один объект (судя по названию, а рисовали совершенно другой. Почему так вышло Небыли четко определены границы
281
Графическая схема процесса представлена в кросс-фун к ци ональ- ном виде. Объем регламента процесса управления составил для процесса Управления ТО около 70 страниц в MS Word, что совсем немного для такого значительного количества процессов.
Отмечу, что среда моделирования Business Studio позволяет формировать и выгружать практически любые отчеты, нужные для регламентации деятельности организации, в том числе:
регламенты выполнения процессов;
—
положения о подразделениях;
—
должностные инструкции (на должности и роли. Особенности создания корректных схем процессов
В этом параграфе мы остановимся на особенностях создания корректных схем бизнес-процессов. Неопытные бизнес-аналитики или сотрудники подразделений, привлеченные к работе по описанию процессов, подчас рисуют никуда негодные схемы. Как этого избежать Конечно, только после получения специалистом нужной квалификации и опыта качество графических схем становится более или менее приемлемым. Но есть несколько аспектов, учет которых позволит даже неопытным в этом деле сотрудникам разрабатывать схемы приемлемого качества. Рассмотрим их. Корректное определение границ процесса
Для успешного описания процесса прежде всего необходимо корректно определить его границы. Если пренебречь этим простым правилом, тов результате описания получается совершенно не то, чего ожидали (рис. 4.9.1). При внимательном изучении содержания схемы и сравнении ее с названием оказывается, что для описания выбрали один объект (судя по названию, а рисовали совершенно другой. Почему так вышло Небыли четко определены границы
282
Бизнес-процессы. Моделирование, внедрение, управление
процесса, и походу формирования схемы процесс пошел совершенно не так, как надо.
Напомню, что границы целесообразно определять по входам/вы- ходам (то есть движению информационных и материальных ресурсов) и событиям (инициирующими завершающим. Привязка к системе процессов
В предыдущем случае мы говорили о том, что процесс ушел не туда. Еще одна из причин такой ситуации — отсутствие системного видения бизнес-процессов организации. Если иерархического справочника процессов нетто при попытке описать какой-то процесс, скорее всего, возникнет ситуация захвата областей из других процессов и т. п. Затем последуют малопродуктивные споры, как провести границы. Поскольку переделка схем требует времени, появляется искушение согласовать кривые границы процессов и т. д. рис. Рис. 4.9.1. Выход заграницы процессов
Рис. 4.9.2. Конфликты на границах процессов
Глава 4. Описание бизнес-процессов организации 4.9.3. Декомпозиция — слишком длинные процессы
Неопытные бизнес-аналитики часто рисуют слишком длинные схемы процессов. Так бывает, если начать задавать вопросы сотруднику и одновременно пытаться формировать схему. Лучше сначала выслушать описание деятельности, делая пометки в блокноте. Затем обдумать ситуацию, структурировать это описание и снова сделать пометки в блокноте, выделяя процессы и предварительно определяя состав их операций. Только после этого можно приступать к формированию графических схем. Кстати, велика вероятность, что при структурировании полученной информации будет целесообразно выделить и описать не один, а несколько процессов.
Если схема процесса все-таки получилась слишком длинной более 12–15 операций, следует внимательно ее проанализировать. Возможно, что:
на схеме представлено несколько процессов, а не один;
—
операции процесса неоднородны (по длительности выполнения, требуемым ресурсами т. п.);
в процессе появилась грыжа (см. ниже);
—
прочее.
—
В любом случае схему процесса стоит переделать. Исключения составляют ситуации, когда схемы специально рисуют на бумаге формата А, чтобы детально отразить все шаги и взаимодействия. Но увлекаться увеличением формата листов для схем процессов не стоит. А — это максимально допустимый размер. Рисовать и печатать схемы процессов на А или А категорически не рекомендуется (рис. Рис. 4.9.3. Чрезмерно длинные процессы
284
Бизнес-процессы. Моделирование, внедрение, управление. Процесс в процессе, или «Процессная грыжа»
«Процессная грыжа (рис. 4.9.4) часто появляется у неопытных бизнес-аналитиков и специалистов, не обладающих навыками системного мышления. Ситуация заключается в том, что внутри схемы процесса представлено описание деятельности, которая выполняется другим подразделением, в другое время и т. п. Но сотруднику кажется, что без этого описания схема будет неполной. Понятие про- цессный интерфейс (ссылка на другой процесс) или возможность взаимодействия процессов при помощи данных при этом совершенно упускаются из виду. Например, сотрудник описывает процесс работы с клиентом, в рамках которого нужно выяснить его платежеспособность. Для отработки запроса служит специальный процесс, выполняемый бухгалтерией, финансовым отделом и службой безопасности. Проверка платежеспособности может потребоваться еще в десятках ситуаций. Но сотрудник упорно рисует все эти действия на своей схеме, которая становится просто огромной.
Можно предложить следующие решения проблемы:
разделить процесс на несколько частей и описать их в виде отдельных моделей, увязав между собой;
вместо подробного описания поместить на схему ссылку на процесс, описанный в другой части системы процессов организации.
Рис. 4.9.4. «Процессная грыжа
Неопытные бизнес-аналитики часто рисуют слишком длинные схемы процессов. Так бывает, если начать задавать вопросы сотруднику и одновременно пытаться формировать схему. Лучше сначала выслушать описание деятельности, делая пометки в блокноте. Затем обдумать ситуацию, структурировать это описание и снова сделать пометки в блокноте, выделяя процессы и предварительно определяя состав их операций. Только после этого можно приступать к формированию графических схем. Кстати, велика вероятность, что при структурировании полученной информации будет целесообразно выделить и описать не один, а несколько процессов.
Если схема процесса все-таки получилась слишком длинной более 12–15 операций, следует внимательно ее проанализировать. Возможно, что:
на схеме представлено несколько процессов, а не один;
—
операции процесса неоднородны (по длительности выполнения, требуемым ресурсами т. п.);
в процессе появилась грыжа (см. ниже);
—
прочее.
—
В любом случае схему процесса стоит переделать. Исключения составляют ситуации, когда схемы специально рисуют на бумаге формата А, чтобы детально отразить все шаги и взаимодействия. Но увлекаться увеличением формата листов для схем процессов не стоит. А — это максимально допустимый размер. Рисовать и печатать схемы процессов на А или А категорически не рекомендуется (рис. Рис. 4.9.3. Чрезмерно длинные процессы
284
Бизнес-процессы. Моделирование, внедрение, управление. Процесс в процессе, или «Процессная грыжа»
«Процессная грыжа (рис. 4.9.4) часто появляется у неопытных бизнес-аналитиков и специалистов, не обладающих навыками системного мышления. Ситуация заключается в том, что внутри схемы процесса представлено описание деятельности, которая выполняется другим подразделением, в другое время и т. п. Но сотруднику кажется, что без этого описания схема будет неполной. Понятие про- цессный интерфейс (ссылка на другой процесс) или возможность взаимодействия процессов при помощи данных при этом совершенно упускаются из виду. Например, сотрудник описывает процесс работы с клиентом, в рамках которого нужно выяснить его платежеспособность. Для отработки запроса служит специальный процесс, выполняемый бухгалтерией, финансовым отделом и службой безопасности. Проверка платежеспособности может потребоваться еще в десятках ситуаций. Но сотрудник упорно рисует все эти действия на своей схеме, которая становится просто огромной.
Можно предложить следующие решения проблемы:
разделить процесс на несколько частей и описать их в виде отдельных моделей, увязав между собой;
вместо подробного описания поместить на схему ссылку на процесс, описанный в другой части системы процессов организации.
Рис. 4.9.4. «Процессная грыжа
Глава 4. Описание бизнес-процессов организации
285
В первом случае возникает вопрос, как быть со сквозными процессами. Ответ прост. Сквозной процесс, как и любой другой, можно декомпозировать на несколько процессов. Каждый из этих под- процессов, в свою очередь, может быть описан в виде кросс-функ- циональной схемы (см. главу 2). Важно только корректно установить связи между ними (информационные потоки, события. Примитивизация — рисование процесса по «хвостам»
Одна из распространенных ошибок неопытного бизнес-аналитика — попытка описать бизнес-процесс, последовательно характеризуя операции по работе с документом (рис. 4.9.5). Если цель работы — создать маршрут движения документа, то это нормально. Если же надо описать именно бизнес-процесс, то такой подход приводит к ошибкам. Ведь кроме операций по работе с документом в процессе существует еще множество важных действий получение информации, ее анализ, различные согласования, принятие решений. Бизнес- аналитик должен видеть картину целиком, а не только маршрут движения одного документа. Однородность процесса
Однородность процесса — один из тех важных аспектов, на которые стоит обращать внимание при описании. Все определенные в рамках процесса операции должны по возможности соответствовать друг другу по длительности, трудоемкости, количеству потребляемых ресурсов. Так, некорректно отображать на схеме одного процесса две операции, одна из которых заключается лишь в передаче документа Рис. 4.9.5. Схема документооборота вместо схемы процесса
286
Бизнес-процессы. Моделирование, внедрение, управление
исполнителям, а вторая означает работу целого отдела по формированию пакета документов в течение двух недель. В данном случае неоднородность возникает по таким параметрам, как исполнители, состав работ, время их выполнения.
Если при описании процесса выявлена неоднородность, это красноречиво указывает на необходимость его реструктурирования: какие-то операции следует агрегировать (укрупнить, а другие, наоборот, детализировать. В любом случае неоднородность описания говорит о недостаточной проработке как самой схемы, таки всей системы процессов организации (рис. 4.9.6).
4.9.7. Связи между процессами, оборванные входы/выходы
Бизнес-аналитик должен ясно осознавать, что между процессами всегда существует взаимодействие. На схеме его можно показать через обмен данных. Это означает, что из процесса выходят и, наоборот, в процесс входят документы (в бумажном или электронном виде. При этом очень важно понимать, что эти документы не берутся из воздуха, а появляются в каком-то одном процессе, используются другим процессом, передаются третьему и т. д. Если бизнес-аналитик рисует на схеме процесса документы, не отдавая себе отчета в том, откуда они берутся, не уточняя их название и содержание, то схема будет мало соответствовать реальности.
На схеме процесса не допускаются оборванные входы и выходы рис. 4.9.7). Всегда должны стоять ссылки на соответствующие процессы поставщиков и потребителей информации/документов.
Рис. 4.9.6. Различный масштаб процессов
285
В первом случае возникает вопрос, как быть со сквозными процессами. Ответ прост. Сквозной процесс, как и любой другой, можно декомпозировать на несколько процессов. Каждый из этих под- процессов, в свою очередь, может быть описан в виде кросс-функ- циональной схемы (см. главу 2). Важно только корректно установить связи между ними (информационные потоки, события. Примитивизация — рисование процесса по «хвостам»
Одна из распространенных ошибок неопытного бизнес-аналитика — попытка описать бизнес-процесс, последовательно характеризуя операции по работе с документом (рис. 4.9.5). Если цель работы — создать маршрут движения документа, то это нормально. Если же надо описать именно бизнес-процесс, то такой подход приводит к ошибкам. Ведь кроме операций по работе с документом в процессе существует еще множество важных действий получение информации, ее анализ, различные согласования, принятие решений. Бизнес- аналитик должен видеть картину целиком, а не только маршрут движения одного документа. Однородность процесса
Однородность процесса — один из тех важных аспектов, на которые стоит обращать внимание при описании. Все определенные в рамках процесса операции должны по возможности соответствовать друг другу по длительности, трудоемкости, количеству потребляемых ресурсов. Так, некорректно отображать на схеме одного процесса две операции, одна из которых заключается лишь в передаче документа Рис. 4.9.5. Схема документооборота вместо схемы процесса
286
Бизнес-процессы. Моделирование, внедрение, управление
исполнителям, а вторая означает работу целого отдела по формированию пакета документов в течение двух недель. В данном случае неоднородность возникает по таким параметрам, как исполнители, состав работ, время их выполнения.
Если при описании процесса выявлена неоднородность, это красноречиво указывает на необходимость его реструктурирования: какие-то операции следует агрегировать (укрупнить, а другие, наоборот, детализировать. В любом случае неоднородность описания говорит о недостаточной проработке как самой схемы, таки всей системы процессов организации (рис. 4.9.6).
4.9.7. Связи между процессами, оборванные входы/выходы
Бизнес-аналитик должен ясно осознавать, что между процессами всегда существует взаимодействие. На схеме его можно показать через обмен данных. Это означает, что из процесса выходят и, наоборот, в процесс входят документы (в бумажном или электронном виде. При этом очень важно понимать, что эти документы не берутся из воздуха, а появляются в каком-то одном процессе, используются другим процессом, передаются третьему и т. д. Если бизнес-аналитик рисует на схеме процесса документы, не отдавая себе отчета в том, откуда они берутся, не уточняя их название и содержание, то схема будет мало соответствовать реальности.
На схеме процесса не допускаются оборванные входы и выходы рис. 4.9.7). Всегда должны стоять ссылки на соответствующие процессы поставщиков и потребителей информации/документов.
Рис. 4.9.6. Различный масштаб процессов
Глава 4. Описание бизнес-процессов организации 4.9.8. Нарушение нотации моделирования
Нарушение нотации моделирования создает проблемы — схема становится нечитаемой, возникают неоднозначные моменты в ее интерпретации и т. д. Если в организации установлен стандарт моделирования бизнес-процессов, то обязательно нужно его придерживаться. Чем сложнее выбранная нотация, тем больше вероятность, что неопытный бизнес- аналитик нарисует схему, содержащую множество ошибок (рис. Опыт показывает, что сотрудники склонны упрощать любую нотацию до примитивного уровня (это можно назвать профанацией моделирования процессов. К сожалению, при этом качество схем оказывается никуда негодным. В таких компаниях руководство Рис. 4.9.7. Оборванные входы/выходы процессов
Рис. 4.9.8. Чрезмерно сложные схемы процессов
288
Бизнес-процессы. Моделирование, внедрение, управление
утверждает: Мы пытались рисовать графические схемы, но что-то у нас они не получились. Мы решили описывать все текстом. Так появляются довольно увлекательные управленческие новеллы и романы в регламентирующем стиле. Проверка на здравый смысл
Даже самому опытному бизнес-аналитику полезно оценить полученную схему процесса сточки зрения здравого смысла (рис. 4.9.9). Это означает, что нужно, например, проверить процесс на физическую реализуемость мы показываем, что сотрудник делает то-то и то-то, а он в это время давно уже занят чем-то другими т. п.
Целесообразно обратить внимание на:
ненужное повторение операций;
—
перегрузку исполнителей;
—
контрольные операции, от которых можно отказаться;
—
возможность параллельного выполнения операций;
—
возможность упрощения алгоритма выполнения процесса;
—
неоправданное усложнение (лишние, устаревшие операции);
—
узкие места различного характера;
—
недостаточное обеспечение ресурсами;
—
прочее.
—
Рис. 4.9.9. Проверка на здравый смысл
Нарушение нотации моделирования создает проблемы — схема становится нечитаемой, возникают неоднозначные моменты в ее интерпретации и т. д. Если в организации установлен стандарт моделирования бизнес-процессов, то обязательно нужно его придерживаться. Чем сложнее выбранная нотация, тем больше вероятность, что неопытный бизнес- аналитик нарисует схему, содержащую множество ошибок (рис. Опыт показывает, что сотрудники склонны упрощать любую нотацию до примитивного уровня (это можно назвать профанацией моделирования процессов. К сожалению, при этом качество схем оказывается никуда негодным. В таких компаниях руководство Рис. 4.9.7. Оборванные входы/выходы процессов
Рис. 4.9.8. Чрезмерно сложные схемы процессов
288
Бизнес-процессы. Моделирование, внедрение, управление
утверждает: Мы пытались рисовать графические схемы, но что-то у нас они не получились. Мы решили описывать все текстом. Так появляются довольно увлекательные управленческие новеллы и романы в регламентирующем стиле. Проверка на здравый смысл
Даже самому опытному бизнес-аналитику полезно оценить полученную схему процесса сточки зрения здравого смысла (рис. 4.9.9). Это означает, что нужно, например, проверить процесс на физическую реализуемость мы показываем, что сотрудник делает то-то и то-то, а он в это время давно уже занят чем-то другими т. п.
Целесообразно обратить внимание на:
ненужное повторение операций;
—
перегрузку исполнителей;
—
контрольные операции, от которых можно отказаться;
—
возможность параллельного выполнения операций;
—
возможность упрощения алгоритма выполнения процесса;
—
неоправданное усложнение (лишние, устаревшие операции);
—
узкие места различного характера;
—
недостаточное обеспечение ресурсами;
—
прочее.
—
Рис. 4.9.9. Проверка на здравый смысл
Глава 4. Описание бизнес-процессов организации 4.10. Рекомендации по внедрению среды моделирования процессов
Внедрение среды моделирования процессов в масштабах организации важный и сложный проект. Для его успешного выполнения нужно разработать план, адекватный задаче. Предлагаю один извоз- можных вариантов такого плана
*
Для крупной компании внедрение среды моделирования — серьезный проект, который может состоять из трех этапов
**
:
Выбор и тестирование среды моделирования. Опытная эксплуатация среды моделирования. Внедрение среды моделирования в масштабах компании. Этап 1. Выбор и тестирование среды моделирования:
определение потребностей внутренних пользователей;
—
определение и согласование целей и задач проекта;
—
анализ сред моделирования, представленных на рынке (по документации, и выбор системы для тестирования;
установка пробной версии среды моделирования (два-три рабочих места);
создание пилотной модели организации:
—
описание двух-трех процессов на двух уровнях;
•
описание фрагмента организационной структуры;
•
описание некоторых документов, терминов, ТМЦ;
•
формирование пилотных отчетов (регламентов выполнения бизнес-процессов);
тестирование среды моделирования на основе пилотной модели * План внедрения в организации среднего или крупного размера.
** Для небольших компаний план проекта может быть существенно переработан
290
Бизнес-процессы. Моделирование, внедрение, управление
тестирование функциональных возможностей системы;
•
тестирование выгрузки отчетов (регламентирующих до-
•
кументов);
тестирование управления изменениями;
•
анализ результатов тестирования среды моделирования на пилотной модели, принятие решения о выборе системы;
определение конфигурации системы, необходимой для решения задач организации;
принятие решения и закупка среды моделирования;
—
установка системы (три-пять конкурентных лицензий);
—
обучение группы специалистов работе со средой моделирования (включая прохождение теста и получение официальных сертификатов);
разработка детального плана опытной эксплуатации среды
—
моделирования.
Этап 2. Опытная эксплуатация среды моделирования:
администрирование системы:
—
создание групп пользователей и определение прав доступа;
•
настройка функционала контроля внесения изменений в систему;
анализ и внесение необходимых изменений в метамодель:
—
анализ требований внутренних потребителей по выгрузке отчетов из среды моделирования (регламенты, положения, прочие отчеты);
анализ возможностей метамодели сточки зрения хранения информации, необходимой для выгрузки отчетов
Внедрение среды моделирования процессов в масштабах организации важный и сложный проект. Для его успешного выполнения нужно разработать план, адекватный задаче. Предлагаю один извоз- можных вариантов такого плана
*
Для крупной компании внедрение среды моделирования — серьезный проект, который может состоять из трех этапов
**
:
Выбор и тестирование среды моделирования. Опытная эксплуатация среды моделирования. Внедрение среды моделирования в масштабах компании. Этап 1. Выбор и тестирование среды моделирования:
определение потребностей внутренних пользователей;
—
определение и согласование целей и задач проекта;
—
анализ сред моделирования, представленных на рынке (по документации, и выбор системы для тестирования;
установка пробной версии среды моделирования (два-три рабочих места);
создание пилотной модели организации:
—
описание двух-трех процессов на двух уровнях;
•
описание фрагмента организационной структуры;
•
описание некоторых документов, терминов, ТМЦ;
•
формирование пилотных отчетов (регламентов выполнения бизнес-процессов);
тестирование среды моделирования на основе пилотной модели * План внедрения в организации среднего или крупного размера.
** Для небольших компаний план проекта может быть существенно переработан
290
Бизнес-процессы. Моделирование, внедрение, управление
тестирование функциональных возможностей системы;
•
тестирование выгрузки отчетов (регламентирующих до-
•
кументов);
тестирование управления изменениями;
•
анализ результатов тестирования среды моделирования на пилотной модели, принятие решения о выборе системы;
определение конфигурации системы, необходимой для решения задач организации;
принятие решения и закупка среды моделирования;
—
установка системы (три-пять конкурентных лицензий);
—
обучение группы специалистов работе со средой моделирования (включая прохождение теста и получение официальных сертификатов);
разработка детального плана опытной эксплуатации среды
—
моделирования.
Этап 2. Опытная эксплуатация среды моделирования:
администрирование системы:
—
создание групп пользователей и определение прав доступа;
•
настройка функционала контроля внесения изменений в систему;
анализ и внесение необходимых изменений в метамодель:
—
анализ требований внутренних потребителей по выгрузке отчетов из среды моделирования (регламенты, положения, прочие отчеты);
анализ возможностей метамодели сточки зрения хранения информации, необходимой для выгрузки отчетов
Глава 4. Описание бизнес-процессов организации
291
определение и внесение необходимых дополнений в мета-
•
модель (структуру данных);
определение требований по использованию метамодели при моделировании организации;
ввод в систему необходимых справочников:
—
иерархический справочник процессов организации (возможно, путем импорта системы процессов организации из файла MS иерархический справочник подразделений и должностей;
•
справочник бумажных и электронных документов (уровня компании);
справочник терминов;
•
прочее.
•
разработка и тестирование необходимых шаблонов регламентирующих документов и других отчетов;
разработка решений по интеграции с другими системами экспорт — импорт»);
разработка стандарта моделирования (нормативный документ, регламентирующий использование функционала системы и метамодели при описании процессов, подразделений, документов и т. п.);
разработка и тестирование регламента управления изменениями (нормативный документ, регламентирующий взаимодействие сотрудников и порядок внесения изменений в объектную модель организации);
анализ эффективности функционирования среды моделирования внесение необходимых изменений в регламенты работы с системой
292
Бизнес-процессы. Моделирование, внедрение, управление
Этап 3. Внедрение среды моделирования в масштабах компании:
определение количества необходимых лицензий;
—
закупка и установка среды моделирования в структурных подразделениях организации;
обучение руководителей и специалистов подразделений использованию системы (соглашение по моделированию, регламент управления изменениями и т. д.);
разработка плана описания процессов организации;
—
описание приоритетных процессов организации силами специалистов подразделений выгрузка регламентирующих документов анализ эффективности эксплуатации среды моделирования, внесение необходимых изменений в регламенты работы с системой.
В стандарте по моделированию сформулированы требования по использованию системы при описании процессов, подразделений, документов и т. п. Это подробная инструкция, в соответствии с требованиями которой сотрудники организации обязаны работать со средой моделирования заносить информацию в соответствующие атрибуты объектов модели, формировать графические схемы и т. д. Документ может иметь такую структуру (на примере стандарта, разработанного для использования среды Business Studio):
1. Общие положения 1.1. Назначение и область действия 1.2. Используемые сокращения 1.3. Термины и определения 1.4. Нормативные ссылки. Ведение справочников в Business Studio
2.1. Справочник Процессы 2.2. Справочник Субъекты 2.3. Справочник Объекты деятельности 2.4. Справочник Управление
291
определение и внесение необходимых дополнений в мета-
•
модель (структуру данных);
определение требований по использованию метамодели при моделировании организации;
ввод в систему необходимых справочников:
—
иерархический справочник процессов организации (возможно, путем импорта системы процессов организации из файла MS иерархический справочник подразделений и должностей;
•
справочник бумажных и электронных документов (уровня компании);
справочник терминов;
•
прочее.
•
разработка и тестирование необходимых шаблонов регламентирующих документов и других отчетов;
разработка решений по интеграции с другими системами экспорт — импорт»);
разработка стандарта моделирования (нормативный документ, регламентирующий использование функционала системы и метамодели при описании процессов, подразделений, документов и т. п.);
разработка и тестирование регламента управления изменениями (нормативный документ, регламентирующий взаимодействие сотрудников и порядок внесения изменений в объектную модель организации);
анализ эффективности функционирования среды моделирования внесение необходимых изменений в регламенты работы с системой
292
Бизнес-процессы. Моделирование, внедрение, управление
Этап 3. Внедрение среды моделирования в масштабах компании:
определение количества необходимых лицензий;
—
закупка и установка среды моделирования в структурных подразделениях организации;
обучение руководителей и специалистов подразделений использованию системы (соглашение по моделированию, регламент управления изменениями и т. д.);
разработка плана описания процессов организации;
—
описание приоритетных процессов организации силами специалистов подразделений выгрузка регламентирующих документов анализ эффективности эксплуатации среды моделирования, внесение необходимых изменений в регламенты работы с системой.
В стандарте по моделированию сформулированы требования по использованию системы при описании процессов, подразделений, документов и т. п. Это подробная инструкция, в соответствии с требованиями которой сотрудники организации обязаны работать со средой моделирования заносить информацию в соответствующие атрибуты объектов модели, формировать графические схемы и т. д. Документ может иметь такую структуру (на примере стандарта, разработанного для использования среды Business Studio):
1. Общие положения 1.1. Назначение и область действия 1.2. Используемые сокращения 1.3. Термины и определения 1.4. Нормативные ссылки. Ведение справочников в Business Studio
2.1. Справочник Процессы 2.2. Справочник Субъекты 2.3. Справочник Объекты деятельности 2.4. Справочник Управление
Глава 4. Описание бизнес-процессов организации 3. Описание процессов в Business Studio
3.1. Элементы нотации Процедура Business Studio
3.2. Описание операций процесса 3.3. Использование стрелок типа Связь предшествования 3.4. Использование стрелок типа Поток документов 3.5. Использование событий 3.6. Использование блока Решение 3.7. Использование междиаграммных ссылок 3.8. Использование сносок. Схемы организационной структуры в Business Studio
4.1. Используемые графические элементы. Заполнение атрибутов объектов модели 5.1. Заполнение атрибутов процесса 5.2. Заполнение атрибутов операции процесса 5.3. Заполнение атрибутов стрелок 5.4. Заполнение атрибутов субъекта деятельности 5.5. Заполнение атрибутов объекта деятельности 5.6. Заполнение атрибутов целей и показателей. Приложения 6.1. Пример схемы процесса в нотации Процедура Business Регламент управления изменениями — это инструкция по внесению существенных изменений в систему, в том числе изменение модели организационной структуры, изменение справочника процессов на верхнем и среднем уровне, массовое переназначение ответственности за выполнение процессов. Подобные действия могут выполнять только квалифицированные бизнес-аналитики, имеющие соответствующие полномочия. Регламент может выглядеть примерно так. Общие положения 1.1. Назначение 1.2. Термины, определения и сокращения. Общее описание процесса управления изменениями
294
Бизнес-процессы. Моделирование, внедрение, управление. Типы изменений и распределение ролей и ответственности за управление изменениями. Изменения справочников. Организационная структура 4.2. Процессы 4.3. Объекты деятельности (документы, ТМЦ, программные продукты. Цели и показатели 4.5. Прочее. Изменение схем процессов. Изменение шаблонов отчетов. Изменение метамодели
8. Архивирование и восстановление объектной модели. Изменение прав доступа. Изменение версии системы (переход на новые версии. Изменение решений по интеграции с другими системами
В заключение приведу пример графика проекта по созданию ре- позитория бизнес-процессов организации на платформе среды моделирования (рис. После покупки и установки системы Business Studio следует обучить рабочую группу. Несколько специалистов из нее образуют потом центр компетенции по использованию репозитория бизнес- процессов. Остальные будут совмещать текущую деятельность в подразделениях с моделированием, анализом и регламентацией бизнес- процессов. Они станут агентами влияния процессной методологии в структурных подразделениях компании.
Для эффективного использования системы нужно разработать архитектуру (систему) бизнес-процессов компании. Удобно это делать в MS Excel, но можно и сразу в системе. Далее полученная архитектура процессов переносится в Business Studio — создается иерархический справочник процессов. Этот справочник — основа для накопления знаний о процессах в рамках электронного ре- позитория.
296
Бизнес-процессы. Моделирование, внедрение, управление
Кроме этого документа полезно создать стандарт (инструкцию) по администрированию репозитория и стандарт по внесению изменений в модель организации.
После разработки и согласования стандартов проводится обучение руководителей и специалистов подразделений компании работе с электронным репозиторием бизнес-процессов на платформе Busi- ness Studio.
4.11. Список литературы
Репин В. В. Бизнес-процессы компании построение, анализ, регламентация М. : Стандарты и качество, Репин В. В, Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М. : Стандарты и качество, Руководство пользователя Business Studio (2012).
3. Руководство технического специалиста Business Studio (2012).
4. Создание пользовательских отчетов Business Studio. Методика (2012).
5. Маклаков СВ. Моделирование бизнес-процессов с AIIFusion Process Mo-
6. de ler. — М. : Диалог-МИФИ, 2008.
Черемных СВ, Семенов ИО, Ручкин В. С. Структурный анализ систем
7. технологии. — М. : Финансы и статистика, Моделирование бизнеса. Методология ARIS. Практическое руководство /
8. М. Каменнова и др. — М. : Серебряные нити, 2001.
Silver B. BPMN Method and Style: A levels-based methodology for BPM process
9. modeling and improvement using BPMN 2.0. — Cody-Cassidy, 2009.
3.1. Элементы нотации Процедура Business Studio
3.2. Описание операций процесса 3.3. Использование стрелок типа Связь предшествования 3.4. Использование стрелок типа Поток документов 3.5. Использование событий 3.6. Использование блока Решение 3.7. Использование междиаграммных ссылок 3.8. Использование сносок. Схемы организационной структуры в Business Studio
4.1. Используемые графические элементы. Заполнение атрибутов объектов модели 5.1. Заполнение атрибутов процесса 5.2. Заполнение атрибутов операции процесса 5.3. Заполнение атрибутов стрелок 5.4. Заполнение атрибутов субъекта деятельности 5.5. Заполнение атрибутов объекта деятельности 5.6. Заполнение атрибутов целей и показателей. Приложения 6.1. Пример схемы процесса в нотации Процедура Business Регламент управления изменениями — это инструкция по внесению существенных изменений в систему, в том числе изменение модели организационной структуры, изменение справочника процессов на верхнем и среднем уровне, массовое переназначение ответственности за выполнение процессов. Подобные действия могут выполнять только квалифицированные бизнес-аналитики, имеющие соответствующие полномочия. Регламент может выглядеть примерно так. Общие положения 1.1. Назначение 1.2. Термины, определения и сокращения. Общее описание процесса управления изменениями
294
Бизнес-процессы. Моделирование, внедрение, управление. Типы изменений и распределение ролей и ответственности за управление изменениями. Изменения справочников. Организационная структура 4.2. Процессы 4.3. Объекты деятельности (документы, ТМЦ, программные продукты. Цели и показатели 4.5. Прочее. Изменение схем процессов. Изменение шаблонов отчетов. Изменение метамодели
8. Архивирование и восстановление объектной модели. Изменение прав доступа. Изменение версии системы (переход на новые версии. Изменение решений по интеграции с другими системами
В заключение приведу пример графика проекта по созданию ре- позитория бизнес-процессов организации на платформе среды моделирования (рис. После покупки и установки системы Business Studio следует обучить рабочую группу. Несколько специалистов из нее образуют потом центр компетенции по использованию репозитория бизнес- процессов. Остальные будут совмещать текущую деятельность в подразделениях с моделированием, анализом и регламентацией бизнес- процессов. Они станут агентами влияния процессной методологии в структурных подразделениях компании.
Для эффективного использования системы нужно разработать архитектуру (систему) бизнес-процессов компании. Удобно это делать в MS Excel, но можно и сразу в системе. Далее полученная архитектура процессов переносится в Business Studio — создается иерархический справочник процессов. Этот справочник — основа для накопления знаний о процессах в рамках электронного ре- позитория.
Глава 4. Описание бизнес-процессов организации
295
Затем рабочая группа описывает несколько пилотных процессов. Это делается для того, чтобы в полной мере освоить возможности инструмента и сформулировать предварительные требования к стандарту моделирования и шаблонам регламентирующих документов.
Чтобы выгрузить из репозитория информацию о процессах вне- обходимой форме (регламенты, инструкции, положения и т. п, нужно определить требования к этим документам. При проектировании шаблонов отчетов увязываются между собой требования к документами возможности системы. Например, если мы хотим видеть в документе какой-то атрибут бизнес-процесса, надо понимать, какую информацию и как следует заносить в репозиторий. Создание шаблонов для выгрузки сложных регламентирующих документов может потребовать изменений объектной модели Business Studio. Это легко делается при помощи специального инструмента Meta Edit, входящего в комплект поставки системы (в версии Когда станет понятно, как моделировать процессы и какая информация должна заноситься в атрибуты объектов модели, разрабатывается стандарт моделирования (соглашение по моделированию. Название задачи
Длитель- ность
13.02 20.02 27.02 05.03 12.03 19.03 26.03 02.04 09.04 16.04 23.04 30.04 07.05 14.05 Приобретение Business Studio
5 дней
2
Установка Business Studio
2 дня
3
Обучение рабочей группы работе с Business Studio
4 дня
4
Разработка системы процессов компании дней
5
Разработка справочника процессов в Business Studio
3 дня
6
Описание пилотных бизнес-процессов
10 дней
7
Разработка шаблонов отчетов для выгрузки регламентирующих документов дней
8
Разработка шаблонов отчетов для выгрузки навигатора (портал дней
9
Разработка стандарта моделирования в Business Studio
10 дней
10
Разработка стандарта администрирования репозито- рия бизнес-процессов на платформе Business Studio
10 дней
11
Разработка стандарта внесения изменений в модель организации, хранящуюся в репозитории на платформе
Business Studio
10 дней
12
Обучение сотрудников компании работе с Business Studio
4 дня
13
Репозиторий бизнес-процессов готов к эксплуатации дней
Март
Апрель
Май
11.05
Рис. 4.10.1. График Ганта создания репозитория бизнес-процессов на платформе среды моделирования Business Studio
295
Затем рабочая группа описывает несколько пилотных процессов. Это делается для того, чтобы в полной мере освоить возможности инструмента и сформулировать предварительные требования к стандарту моделирования и шаблонам регламентирующих документов.
Чтобы выгрузить из репозитория информацию о процессах вне- обходимой форме (регламенты, инструкции, положения и т. п, нужно определить требования к этим документам. При проектировании шаблонов отчетов увязываются между собой требования к документами возможности системы. Например, если мы хотим видеть в документе какой-то атрибут бизнес-процесса, надо понимать, какую информацию и как следует заносить в репозиторий. Создание шаблонов для выгрузки сложных регламентирующих документов может потребовать изменений объектной модели Business Studio. Это легко делается при помощи специального инструмента Meta Edit, входящего в комплект поставки системы (в версии Когда станет понятно, как моделировать процессы и какая информация должна заноситься в атрибуты объектов модели, разрабатывается стандарт моделирования (соглашение по моделированию. Название задачи
Длитель- ность
13.02 20.02 27.02 05.03 12.03 19.03 26.03 02.04 09.04 16.04 23.04 30.04 07.05 14.05 Приобретение Business Studio
5 дней
2
Установка Business Studio
2 дня
3
Обучение рабочей группы работе с Business Studio
4 дня
4
Разработка системы процессов компании дней
5
Разработка справочника процессов в Business Studio
3 дня
6
Описание пилотных бизнес-процессов
10 дней
7
Разработка шаблонов отчетов для выгрузки регламентирующих документов дней
8
Разработка шаблонов отчетов для выгрузки навигатора (портал дней
9
Разработка стандарта моделирования в Business Studio
10 дней
10
Разработка стандарта администрирования репозито- рия бизнес-процессов на платформе Business Studio
10 дней
11
Разработка стандарта внесения изменений в модель организации, хранящуюся в репозитории на платформе
Business Studio
10 дней
12
Обучение сотрудников компании работе с Business Studio
4 дня
13
Репозиторий бизнес-процессов готов к эксплуатации дней
Март
Апрель
Май
11.05
Рис. 4.10.1. График Ганта создания репозитория бизнес-процессов на платформе среды моделирования Business Studio
296
Бизнес-процессы. Моделирование, внедрение, управление
Кроме этого документа полезно создать стандарт (инструкцию) по администрированию репозитория и стандарт по внесению изменений в модель организации.
После разработки и согласования стандартов проводится обучение руководителей и специалистов подразделений компании работе с электронным репозиторием бизнес-процессов на платформе Busi- ness Studio.
4.11. Список литературы
Репин В. В. Бизнес-процессы компании построение, анализ, регламентация М. : Стандарты и качество, Репин В. В, Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М. : Стандарты и качество, Руководство пользователя Business Studio (2012).
3. Руководство технического специалиста Business Studio (2012).
4. Создание пользовательских отчетов Business Studio. Методика (2012).
5. Маклаков СВ. Моделирование бизнес-процессов с AIIFusion Process Mo-
6. de ler. — М. : Диалог-МИФИ, 2008.
Черемных СВ, Семенов ИО, Ручкин В. С. Структурный анализ систем
7. технологии. — М. : Финансы и статистика, Моделирование бизнеса. Методология ARIS. Практическое руководство /
8. М. Каменнова и др. — М. : Серебряные нити, 2001.
Silver B. BPMN Method and Style: A levels-based methodology for BPM process
9. modeling and improvement using BPMN 2.0. — Cody-Cassidy, 2009.
Глава Регламентация бизнес-процессов организации
В этой главе рассмотрим вопросы, связанные с разработкой, внедрением и контролем исполнения регламентирующих документов по бизнес-процессам. Регламентация процессов — один из важных элементов системы процессного управления. Некорректное, формально-бюрократическое и неэффективное использование регламентирующих документов может существенно дискредитировать процессный подход в глазах руководителей и специалистов компании. В главе 5 содержится информация, которая должна помочь руководителям выстроить эффективно действующую систему регламентации. Культура регламентации в российских компаниях
Крупные и средние российские компании обладают значительными ресурсами, часть которых может быть использована для построения эффективной системы регламентации. Однако этого не происходит. Почему Поделюсь некоторыми соображениями на этот счет:
регламентация деятельности имеет низкий приоритет сточки зрения топ-менеджеров (что вполне понятно, их интересует рост продаж, прибыль, капитализация);
отсутствует культура работы по стандартам (корпоративная культура — вообще больной вопрос);
устаревание нормативной базы при неадекватной и несвоевременной ее актуализации
298
Бизнес-процессы. Моделирование, внедрение, управление
в системе стимулирования нет элемента, направленного на создание у персонала мотивации исполнять регламенты;
отсутствие нормирования труда в привязке к регламентам невозможность исполнения стандартов из-за ресурсных ограничений);
«исотизированные» (слишком общие) регламенты;
—
регламентация процессов производства в ущерб регламентации процессов управления/развития (то есть регламентация в отдельно взятом подразделении. Низкий приоритет регламентации сточки зрения топ-менеджеров
Глядя со стороны на работу топ-менеджеров компаний, можно сделать вывод, что регламентация деятельности интересует их в третью и даже в четвертую очередь (а в ряде случаев вообще не интересует. Правильная расстановка руководящего персонала и система материального стимулирования — и дело сделано Топ-менеджеров интересует рост продаж, прибыль, капитализация, годовые бонусы и т. п. Было бы неправильно обвинять их в нежелании детально вникать в вопросы регламентации отдельных операционных процессов. Но именно в их власти создать систему работы, при которой регламентация действительно повышает эффективность. Однако ситуация чаще всего такова, что для решения этой задачи у топ-менеджеров просто не хватает времени. Задача строительства системы, спущенная на средний и нижний уровень, решается бесконечно и неэффективно. Отсутствие культуры работы по стандартам
Вопрос культуры организации весьма непрост. У меня нет возможности подробно обсуждать его в этой книге. Замечу только, что культура работы по стандартам (регламентам) зависит от общей культуры компании. К сожалению, на многих российских предприятиях корпоративная культура не мотивирует сотрудников исполнять стандарты, в том числе потому, что их формально (и неформально)
В этой главе рассмотрим вопросы, связанные с разработкой, внедрением и контролем исполнения регламентирующих документов по бизнес-процессам. Регламентация процессов — один из важных элементов системы процессного управления. Некорректное, формально-бюрократическое и неэффективное использование регламентирующих документов может существенно дискредитировать процессный подход в глазах руководителей и специалистов компании. В главе 5 содержится информация, которая должна помочь руководителям выстроить эффективно действующую систему регламентации. Культура регламентации в российских компаниях
Крупные и средние российские компании обладают значительными ресурсами, часть которых может быть использована для построения эффективной системы регламентации. Однако этого не происходит. Почему Поделюсь некоторыми соображениями на этот счет:
регламентация деятельности имеет низкий приоритет сточки зрения топ-менеджеров (что вполне понятно, их интересует рост продаж, прибыль, капитализация);
отсутствует культура работы по стандартам (корпоративная культура — вообще больной вопрос);
устаревание нормативной базы при неадекватной и несвоевременной ее актуализации
298
Бизнес-процессы. Моделирование, внедрение, управление
в системе стимулирования нет элемента, направленного на создание у персонала мотивации исполнять регламенты;
отсутствие нормирования труда в привязке к регламентам невозможность исполнения стандартов из-за ресурсных ограничений);
«исотизированные» (слишком общие) регламенты;
—
регламентация процессов производства в ущерб регламентации процессов управления/развития (то есть регламентация в отдельно взятом подразделении. Низкий приоритет регламентации сточки зрения топ-менеджеров
Глядя со стороны на работу топ-менеджеров компаний, можно сделать вывод, что регламентация деятельности интересует их в третью и даже в четвертую очередь (а в ряде случаев вообще не интересует. Правильная расстановка руководящего персонала и система материального стимулирования — и дело сделано Топ-менеджеров интересует рост продаж, прибыль, капитализация, годовые бонусы и т. п. Было бы неправильно обвинять их в нежелании детально вникать в вопросы регламентации отдельных операционных процессов. Но именно в их власти создать систему работы, при которой регламентация действительно повышает эффективность. Однако ситуация чаще всего такова, что для решения этой задачи у топ-менеджеров просто не хватает времени. Задача строительства системы, спущенная на средний и нижний уровень, решается бесконечно и неэффективно. Отсутствие культуры работы по стандартам
Вопрос культуры организации весьма непрост. У меня нет возможности подробно обсуждать его в этой книге. Замечу только, что культура работы по стандартам (регламентам) зависит от общей культуры компании. К сожалению, на многих российских предприятиях корпоративная культура не мотивирует сотрудников исполнять стандарты, в том числе потому, что их формально (и неформально)
Глава 5. Регламентация бизнес-процессов организации поощряют за совершенно другое. Стоит ли менять корпоративную культуру Только в том случае, если топ-менеджмент принимает процессный подход как новую философию управления и реализует ее на практике личным примером. Устаревание нормативной базы при неадекватной и несвоевременной ее актуализации
База внутренних нормативно-методических документов (НМД) крупной компании может включать сотни (если не тысячи) регламентов, положений, инструкций. Как правило, ситуация такова, что их не успевают актуализировать или делают это формально, для галочки. В результате от 30 до 80% всех документов устаревают — безнадежно отстают от реальной деятельности. Руководители и сотрудники это понимают и относятся к регламентирующей документации соответственно — не исполняют ее. Причины неадекватной и несвоевременной актуализации документов:
методически неправильно организованная работа (к актуализации не привлекают руководителей, непосредственно отвечающих за исполнение регламентирующих документов);
недостаточная квалификация сотрудников, привлекаемых для ее выполнения;
недостаток ресурсов;
—
прочее.
—
Часто задачу актуализации регламентов поручают одному подразделению (или даже одному сотруднику. Причем, как правило, у него и без этого много работы. В результате человек не справляется с поставленной задачей. Система стимулирования
В крупных компаниях есть СПП, КПЭ
*
и другие системы показателей, часть которых используется для материального стимулирования
* ССП — система сбалансированных показателей, КПЭ — ключевые показатели эффективности
Бизнес-процессы. Моделирование, внедрение, управление
сотрудников. Чаще всего они ориентированы на достижения показателей результативности (план/факт), реже — на эффективность. Совсем редко в рамках системы стимулирования предусмотрены элементы, мотивирующие персонал на исполнение регламентирующих документов. Почему Выдвину некоторые предположения:
у руководства нет объективной информации об исполнении стандартов деятельности;
регламенты слабо связаны с нормативами (см. ниже);
—
требование по исполнению стандартов имеет низкий приоритет перед исполнением плана (то есть важен только плана нарушать стандарты работы допускается).
Первая причина, вероятно, наиболее существенна. Если мы знаем, что регламенты устарели, неполны и не соответствуют реальности, то имеем ли мы право наказывать персонал за их неисполнение Поэтому предложения некоторых консультантов ввести жесткие меры мотивации (30%-ное лишение премии за неисполнение стандартов) не могут быть популярными. Кроме того, такое нововведение в рамках общей репрессивной системы менеджмента только усугубит ситуацию. При этом подразделение, проводящее аудиты нормативных документов, станет врагом всех сотрудников, а идея совершенствования на базе стандартов будет похоронена. Отсутствие нормирования труда в привязке к регламентам
Какую информацию должен содержать регламент выполнения процесса Есть несколько точек зрения на этот вопрос. Как минимум в него включают:
паспорт документа (назначение, область действия и т. п.);
—
краткое текстовое описание;
—
графическую схему (довольно часто, впрочем, обходятся без нее);
—
подробное пошаговое описание операций процесса (часто в виде таблицы
302
Бизнес-процессы. Моделирование, внедрение, управление
с которыми осуществляется деятельность персонала. Регламентация трудовой деятельности работников неразрывно связана с нормированием труда — процессом исследования, проектирования и установления необходимых затрат и результатов труда, а также оптимальных соотношений между численностью работников различных категорий и групп. Нормы труда в конечном счете устанавливаются в соответствии с достигнутым уровнем техники, технологии, организации производства и труда
*
».
Итак, регламентация деятельности без нормирования вызывает вопросы.
Но и нормирование без проработки бизнес-процесса может иметь негативные последствия.
Пример. На складе есть норматив — тариф оплаты за разгрузку конкретного объема товара. Два грузчика, надрываясь, разгружают товар, чтобы побольше заработать. В это время еще два человека курят в сторонке. Сделать работу вместе в два раза быстрее и качественнее никто из них не стремится — это приведет к сокращению зарплаты. «Исотизированные» (слишком общие) регламенты
Сами по себе стандарты ИСО на систему менеджмента качества
(СМК) — довольно ценные методические документы. Однако их практическая реализация не дает ожидаемого эффекта. Об этом много писали и продолжают писать. Мне хотелось бы обратить внимание читателя на тот факт, что часто регламенты, написанные в рамках СМК, выглядят слишком общими. Когда их читаешь, вроде все правильно, но что конкретно надо делать, непонятно. Для таких регламентирующих документов (формально правильных, но чересчур общих) я подобрал термин «исотизированные». Это необязательно регламенты СМК. В организациях хватает слишком общих документов. Какова ценность регламентов, неизвестно когда, как и кем исполняемых Можно иметь сто стандартов верхнего уровня,
* То есть требуемых бизнес-процессов.
База внутренних нормативно-методических документов (НМД) крупной компании может включать сотни (если не тысячи) регламентов, положений, инструкций. Как правило, ситуация такова, что их не успевают актуализировать или делают это формально, для галочки. В результате от 30 до 80% всех документов устаревают — безнадежно отстают от реальной деятельности. Руководители и сотрудники это понимают и относятся к регламентирующей документации соответственно — не исполняют ее. Причины неадекватной и несвоевременной актуализации документов:
методически неправильно организованная работа (к актуализации не привлекают руководителей, непосредственно отвечающих за исполнение регламентирующих документов);
недостаточная квалификация сотрудников, привлекаемых для ее выполнения;
недостаток ресурсов;
—
прочее.
—
Часто задачу актуализации регламентов поручают одному подразделению (или даже одному сотруднику. Причем, как правило, у него и без этого много работы. В результате человек не справляется с поставленной задачей. Система стимулирования
В крупных компаниях есть СПП, КПЭ
*
и другие системы показателей, часть которых используется для материального стимулирования
* ССП — система сбалансированных показателей, КПЭ — ключевые показатели эффективности
Бизнес-процессы. Моделирование, внедрение, управление
сотрудников. Чаще всего они ориентированы на достижения показателей результативности (план/факт), реже — на эффективность. Совсем редко в рамках системы стимулирования предусмотрены элементы, мотивирующие персонал на исполнение регламентирующих документов. Почему Выдвину некоторые предположения:
у руководства нет объективной информации об исполнении стандартов деятельности;
регламенты слабо связаны с нормативами (см. ниже);
—
требование по исполнению стандартов имеет низкий приоритет перед исполнением плана (то есть важен только плана нарушать стандарты работы допускается).
Первая причина, вероятно, наиболее существенна. Если мы знаем, что регламенты устарели, неполны и не соответствуют реальности, то имеем ли мы право наказывать персонал за их неисполнение Поэтому предложения некоторых консультантов ввести жесткие меры мотивации (30%-ное лишение премии за неисполнение стандартов) не могут быть популярными. Кроме того, такое нововведение в рамках общей репрессивной системы менеджмента только усугубит ситуацию. При этом подразделение, проводящее аудиты нормативных документов, станет врагом всех сотрудников, а идея совершенствования на базе стандартов будет похоронена. Отсутствие нормирования труда в привязке к регламентам
Какую информацию должен содержать регламент выполнения процесса Есть несколько точек зрения на этот вопрос. Как минимум в него включают:
паспорт документа (назначение, область действия и т. п.);
—
краткое текстовое описание;
—
графическую схему (довольно часто, впрочем, обходятся без нее);
—
подробное пошаговое описание операций процесса (часто в виде таблицы
Глава 5. Регламентация бизнес-процессов организации Гораздо реже в регламент вносят описание ресурсов (количество требуемых сотрудников, оборудование и т. п.).
Крайне редко регламенты процессов построены с учетом реальной трудоемкости соответствующих операций и загрузки сотрудников, выполненной с учетом нормативов.
Пример. Выполняется описание процессов отдела. На выходе получается два десятка графических схем и несколько регламентов. Выходит, если следовать регламентам, каждый сотрудник должен участвовать в нескольких процессах. Но его рабочий день ограничен. Какие операции он успеет выполнить Если не успеет, тона какой срок может отложить работу Без нормирования на эти вопросы ответить почти невозможно. При последующем внедрении полученного комплекта документов возникнет ситуация, когда сотрудники не успеют выполнить ключевые требования из-за нехватки времени. Они могут использовать этот аргумент, чтобы объяснить неэффективность своей работы. В любом случае проверить это сложно.
Описание процессов при условии тщательно проработанных нормативов откроет реальную картину загрузки персонала и может указать на необходимость увеличения (или, наоборот, сокращения) штата. Этот вывод не порадует руководство, которое хотело бы обеспечить выполнение регламентов силами имеющегося персонала.
Для выполнения нормирования нужны квалифицированные специалисты, время на замеры и т. п. Для работников, стоящих за станком, без этого не обойтись, а как насчет фронт- или бэк-офиса? Часто задачи и/или ограничения бизнеса приводят к невозможности следовать нормативам. Вероятно, это одна из важных причин появления неработающих регламентов.
Приведу цитату с сайта Национального союза кадровиков:
«…Регламентация труда является основным средством организации трудовых процессов, с помощью которого обеспечивается достижение результатов, поставленных перед коллективом. Регламентация означает установление и строгое соблюдение определенных правил, нормативов и стандартов, в соответствии
Крайне редко регламенты процессов построены с учетом реальной трудоемкости соответствующих операций и загрузки сотрудников, выполненной с учетом нормативов.
Пример. Выполняется описание процессов отдела. На выходе получается два десятка графических схем и несколько регламентов. Выходит, если следовать регламентам, каждый сотрудник должен участвовать в нескольких процессах. Но его рабочий день ограничен. Какие операции он успеет выполнить Если не успеет, тона какой срок может отложить работу Без нормирования на эти вопросы ответить почти невозможно. При последующем внедрении полученного комплекта документов возникнет ситуация, когда сотрудники не успеют выполнить ключевые требования из-за нехватки времени. Они могут использовать этот аргумент, чтобы объяснить неэффективность своей работы. В любом случае проверить это сложно.
Описание процессов при условии тщательно проработанных нормативов откроет реальную картину загрузки персонала и может указать на необходимость увеличения (или, наоборот, сокращения) штата. Этот вывод не порадует руководство, которое хотело бы обеспечить выполнение регламентов силами имеющегося персонала.
Для выполнения нормирования нужны квалифицированные специалисты, время на замеры и т. п. Для работников, стоящих за станком, без этого не обойтись, а как насчет фронт- или бэк-офиса? Часто задачи и/или ограничения бизнеса приводят к невозможности следовать нормативам. Вероятно, это одна из важных причин появления неработающих регламентов.
Приведу цитату с сайта Национального союза кадровиков:
«…Регламентация труда является основным средством организации трудовых процессов, с помощью которого обеспечивается достижение результатов, поставленных перед коллективом. Регламентация означает установление и строгое соблюдение определенных правил, нормативов и стандартов, в соответствии
302
Бизнес-процессы. Моделирование, внедрение, управление
с которыми осуществляется деятельность персонала. Регламентация трудовой деятельности работников неразрывно связана с нормированием труда — процессом исследования, проектирования и установления необходимых затрат и результатов труда, а также оптимальных соотношений между численностью работников различных категорий и групп. Нормы труда в конечном счете устанавливаются в соответствии с достигнутым уровнем техники, технологии, организации производства и труда
*
».
Итак, регламентация деятельности без нормирования вызывает вопросы.
Но и нормирование без проработки бизнес-процесса может иметь негативные последствия.
Пример. На складе есть норматив — тариф оплаты за разгрузку конкретного объема товара. Два грузчика, надрываясь, разгружают товар, чтобы побольше заработать. В это время еще два человека курят в сторонке. Сделать работу вместе в два раза быстрее и качественнее никто из них не стремится — это приведет к сокращению зарплаты. «Исотизированные» (слишком общие) регламенты
Сами по себе стандарты ИСО на систему менеджмента качества
(СМК) — довольно ценные методические документы. Однако их практическая реализация не дает ожидаемого эффекта. Об этом много писали и продолжают писать. Мне хотелось бы обратить внимание читателя на тот факт, что часто регламенты, написанные в рамках СМК, выглядят слишком общими. Когда их читаешь, вроде все правильно, но что конкретно надо делать, непонятно. Для таких регламентирующих документов (формально правильных, но чересчур общих) я подобрал термин «исотизированные». Это необязательно регламенты СМК. В организациях хватает слишком общих документов. Какова ценность регламентов, неизвестно когда, как и кем исполняемых Можно иметь сто стандартов верхнего уровня,
* То есть требуемых бизнес-процессов.
Глава 5. Регламентация бизнес-процессов организации но ни одного внутреннего операционного регламента, полезного при конкретном выполнении работы. Регламентация процессов производства при отсутствии регламентации процессов управления/развития
В ряде компаний регламентация процессов производства достигает
90–100%, то есть регламентирована почти вся деятельность. Внешние требования (ограничения) предопределяют наличие регламентов. Чем жестче проверки внешних контролирующих органов, тем работоспособнее эти документы. Однако они устаревают, могут плохо актуализироваться и т. д.
Хочу обратить внимание читателя и на другой аспект.
Пример. В производственной компании процессы производства регламентированы на 100%, процессы складского хранения — на 80%. Но степень регламентации процессов управления и развития близка к 0%. Например, такие процессы, как Планирование рекламой кампании или Принятие решения об инициации проекта разработки нового вида продукции, не регламентированы и выполняются по понятиям. Это означает, что ключевые решения по распределению бюджета принимают без достаточного обоснования, подчас интуитивно
Отсутствие регламентации процессов маркетинга, сбыта, развития ведет к потерям. Исключение составляют процессы управления финансами (в том числе бюджетирование), которые, как правило, достаточно формализованы.
Особенно подчеркну отсутствие регламентов управления, выполняемых руководством. На верхнем уровне, кроме нескольких общих положений, схемы организационной структуры и должностных инструкций руководителей, может не быть вообще ничего. Деятельность по принятию решений не регламентирована. Каждый разрешения принимаются по разным алгоритмам, они непрозрачны. Такая ситуация, как правило, не радует собственников бизнеса
304
Бизнес-процессы. Моделирование, внедрение, управление. Отсутствие системы работы с регламентами
Зачастую в крупных и средних компаниях отсутствует система стандартизации (регламентации) деятельности. Иными словами, нет системного решения задач регламентации. Присутствуют фрагментарные элементы, неэффективно интегрированные между собой. Отсутствие системности проявляется, например, в следующем:
эффективность работы по утвержденным регламентам никто не проверяет;
регламенты вводят в действие, ноне контролируют, своевременно не актуализируют;
регламенты вводят в действие, но персонал сними не знакомят и не обучают;
одновременно существуют и используются различные версии нормативных документов;
регламенты согласовывают, ноне утверждают (работа впу-
—
стую);
аудиты проводят, проблемы выявляют, но реальную деятельность и соответствующие регламенты не изменяют;
для работы по утвержденным регламентам не хватает ресурсов, но никого это не волнует;
прочее.
—
Подробно система стандартизации бизнес-процессов описана в параграфе 5.4.
5.2. Минусы регламентации бизнес-процессов
Регламентация бизнес-процессов не всегда абсолютно и безусловно нужна организации. Точно также как витамины полезны живому организму лишь до известной степени. В разделах 5.2–5.3 рассмотрим плюсы и минусы регламентации. Их выявление и обсуждение должно помочь уяснить положительные возможности и свести
В ряде компаний регламентация процессов производства достигает
90–100%, то есть регламентирована почти вся деятельность. Внешние требования (ограничения) предопределяют наличие регламентов. Чем жестче проверки внешних контролирующих органов, тем работоспособнее эти документы. Однако они устаревают, могут плохо актуализироваться и т. д.
Хочу обратить внимание читателя и на другой аспект.
Пример. В производственной компании процессы производства регламентированы на 100%, процессы складского хранения — на 80%. Но степень регламентации процессов управления и развития близка к 0%. Например, такие процессы, как Планирование рекламой кампании или Принятие решения об инициации проекта разработки нового вида продукции, не регламентированы и выполняются по понятиям. Это означает, что ключевые решения по распределению бюджета принимают без достаточного обоснования, подчас интуитивно
Отсутствие регламентации процессов маркетинга, сбыта, развития ведет к потерям. Исключение составляют процессы управления финансами (в том числе бюджетирование), которые, как правило, достаточно формализованы.
Особенно подчеркну отсутствие регламентов управления, выполняемых руководством. На верхнем уровне, кроме нескольких общих положений, схемы организационной структуры и должностных инструкций руководителей, может не быть вообще ничего. Деятельность по принятию решений не регламентирована. Каждый разрешения принимаются по разным алгоритмам, они непрозрачны. Такая ситуация, как правило, не радует собственников бизнеса
304
Бизнес-процессы. Моделирование, внедрение, управление. Отсутствие системы работы с регламентами
Зачастую в крупных и средних компаниях отсутствует система стандартизации (регламентации) деятельности. Иными словами, нет системного решения задач регламентации. Присутствуют фрагментарные элементы, неэффективно интегрированные между собой. Отсутствие системности проявляется, например, в следующем:
эффективность работы по утвержденным регламентам никто не проверяет;
регламенты вводят в действие, ноне контролируют, своевременно не актуализируют;
регламенты вводят в действие, но персонал сними не знакомят и не обучают;
одновременно существуют и используются различные версии нормативных документов;
регламенты согласовывают, ноне утверждают (работа впу-
—
стую);
аудиты проводят, проблемы выявляют, но реальную деятельность и соответствующие регламенты не изменяют;
для работы по утвержденным регламентам не хватает ресурсов, но никого это не волнует;
прочее.
—
Подробно система стандартизации бизнес-процессов описана в параграфе 5.4.
5.2. Минусы регламентации бизнес-процессов
Регламентация бизнес-процессов не всегда абсолютно и безусловно нужна организации. Точно также как витамины полезны живому организму лишь до известной степени. В разделах 5.2–5.3 рассмотрим плюсы и минусы регламентации. Их выявление и обсуждение должно помочь уяснить положительные возможности и свести
Глава 5. Регламентация бизнес-процессов организации к минимуму риски построения системы регламентирующих документов в масштабах компании.
Рассмотрим минусы регламентации. Как правило, к их числу от- носят:
значительные затраты на регламентацию;
—
снижение творчества, инициативы сотрудников;
—
разрушение сложившейся команды руководителей и специа-
—
листов;
снижение гибкости в принятии решений, осуществлении изменений и как следствие — уход клиентов;
дополнительную нагрузку на персонал, снижение производи-
—
тельности;
увеличение сроков выполнения процессов из-за необходимости соблюдения регламентов;
появление слишком сложных, забюрократизированных регламентов, что приведет к снижению удовлетворенности клиентов возможность так называемой итальянской забастовки (см. пункт возможную утечку информации о стандартах в другие органи-
—
зации;
прочее.
—
Любой из этих минусов — риск неэффективного внедрения системы регламентации (стандартизации) бизнес-процессов. Рассмотрим последовательно каждый минус. Значительные затраты на регламентацию
Да, затраты на регламентацию могут быть заметными. Но их существенно превышают потери от плохо налаженного взаимодействия и отсутствия четкого порядка выполнения ключевых процессов
306
Бизнес-процессы. Моделирование, внедрение, управление
Наличие нужных методики проработанного плана внедрения системы регламентации, привлечение квалифицированных экспертов, активное вовлечение руководителей и специалистов в проект дают возможность эффективнее использовать средства, выделяемые на регламентацию. Снижение творчества, инициативы сотрудников
Творчество и инициатива нужны не всегда и не везде. Многие процессы должны выполняться только по установленному стандарту. Здесь любая инициатива может обернуться потерями (или более серьезными проблемами. Да, работа будет выполнена, но ее эффективность окажется низкой. Творчество и инициативу, очевидно, надо приветствовать в области анализа и разработки предложений по совершенствованию деятельности изменению технологии, применению новых методов и инструментов и т. п. Поэтому, устанавливая систему жесткого контроля исполнения стандартов, нужно одновременно создавать и использовать систему подачи, анализа, обсуждения и внедрения предложений по улучшению процессов (элементы цикла PDCA Э. Деминга).
Проверьте, сколько предложений по улучшению работы поступило запрошлый год от руководителей отделов и специалистов, сколько из них было одобрено и внедрено. Тогда можно будет оценить реальную степень творчества и инициативности персонала. Если же предложений не было вовсе, как может повлиять регламентация на такое отсутствие творчества Она неспособна навредить реальной инициативности, но радикально снижает возможность покрывать разгильдяйство аргументацией о необходимости творчества в повседневной деятельности сотрудников. Не надо путать героев, личным трудовым подвигом устраняющих проблемы на производстве, и реальное творчество и развитие. Проблема творчества и развития, скорее, заключается в другом. Если руководители, устанавливающие регламенты, консервативны и неготовы менять модель деятельности организации с нужной скоростью, то тормозить развитие будут именно они, а не те, кто работает по стандартам. Безынициативный сотрудник нанесет организации
308
Бизнес-процессы. Моделирование, внедрение, управление
различного масштаба. Например, клиент просит нестандартную скидку. Коммерческий директор гибко и неформально идет ему навстречу. В итоге компания теряет деньги, ау собственников возникают сомнения в искренности этого коммерческого директора. Но если коммерческий директор по формальным критериям откажет и потеряет контракт с крупным клиентом, собственники также будут недовольны и т. п. Как же гибкость связана с регламентацией В 90% ситуаций регламент — очень полезный инструмент. Он дает возможность принимать обоснованные (по определенной методике) управленческие решения, фиксировать их ив последующем оценивать эффективность. Остальные 10% ситуаций должны быть четко обозначены (без детальной регламентации действий сотрудника. При их наступлении управление сразу делегируется на вышестоящий уровень. Таким образом, гибкость не станет синонимом безответственности, а руководители будут четко знать пределы своих полномочий. Дополнительная нагрузка на персонал, снижение производительности
Предполагается, что сотрудники компании потратят часть своего времени на написание регламентов, что снизит производительность труда. Кроме того, походу деятельности придется периодически обращаться к регламентам, проверяя соответствие выполняемой работы установленным требованиям.
Первый аргумент создание и актуализация регламентов действительно занимают немало времени. Только не рядовых сотрудников, а руководителей. Но для них работа по стандартизации — одна из важнейших составляющих деятельности по управлению. Они получают за это зарплату. Руководитель обязан организовать свой рабочий день так, чтобы хватило времени на регламенты. Во многом дефицит времени связан с неупорядоченностью управляемой деятельности, когда правила игры не определены (например, полномочия не делегированы, а сотрудники постоянно отвлекают руководителя, обращаясь с мелкими проблемами
Рассмотрим минусы регламентации. Как правило, к их числу от- носят:
значительные затраты на регламентацию;
—
снижение творчества, инициативы сотрудников;
—
разрушение сложившейся команды руководителей и специа-
—
листов;
снижение гибкости в принятии решений, осуществлении изменений и как следствие — уход клиентов;
дополнительную нагрузку на персонал, снижение производи-
—
тельности;
увеличение сроков выполнения процессов из-за необходимости соблюдения регламентов;
появление слишком сложных, забюрократизированных регламентов, что приведет к снижению удовлетворенности клиентов возможность так называемой итальянской забастовки (см. пункт возможную утечку информации о стандартах в другие органи-
—
зации;
прочее.
—
Любой из этих минусов — риск неэффективного внедрения системы регламентации (стандартизации) бизнес-процессов. Рассмотрим последовательно каждый минус. Значительные затраты на регламентацию
Да, затраты на регламентацию могут быть заметными. Но их существенно превышают потери от плохо налаженного взаимодействия и отсутствия четкого порядка выполнения ключевых процессов
306
Бизнес-процессы. Моделирование, внедрение, управление
Наличие нужных методики проработанного плана внедрения системы регламентации, привлечение квалифицированных экспертов, активное вовлечение руководителей и специалистов в проект дают возможность эффективнее использовать средства, выделяемые на регламентацию. Снижение творчества, инициативы сотрудников
Творчество и инициатива нужны не всегда и не везде. Многие процессы должны выполняться только по установленному стандарту. Здесь любая инициатива может обернуться потерями (или более серьезными проблемами. Да, работа будет выполнена, но ее эффективность окажется низкой. Творчество и инициативу, очевидно, надо приветствовать в области анализа и разработки предложений по совершенствованию деятельности изменению технологии, применению новых методов и инструментов и т. п. Поэтому, устанавливая систему жесткого контроля исполнения стандартов, нужно одновременно создавать и использовать систему подачи, анализа, обсуждения и внедрения предложений по улучшению процессов (элементы цикла PDCA Э. Деминга).
Проверьте, сколько предложений по улучшению работы поступило запрошлый год от руководителей отделов и специалистов, сколько из них было одобрено и внедрено. Тогда можно будет оценить реальную степень творчества и инициативности персонала. Если же предложений не было вовсе, как может повлиять регламентация на такое отсутствие творчества Она неспособна навредить реальной инициативности, но радикально снижает возможность покрывать разгильдяйство аргументацией о необходимости творчества в повседневной деятельности сотрудников. Не надо путать героев, личным трудовым подвигом устраняющих проблемы на производстве, и реальное творчество и развитие. Проблема творчества и развития, скорее, заключается в другом. Если руководители, устанавливающие регламенты, консервативны и неготовы менять модель деятельности организации с нужной скоростью, то тормозить развитие будут именно они, а не те, кто работает по стандартам. Безынициативный сотрудник нанесет организации
Глава 5. Регламентация бизнес-процессов организации гораздо меньше вреда, чем топ-менеджер, настойчиво транслирующий в регламентную базу свои устаревшие взгляды на модель ведения бизнеса. Разрушение сложившейся команды руководителей и специалистов
«Регламентация приведет к формализации отношений между участниками процессов. Начнут разрушаться существующие неформальные, устоявшиеся отношения в коллективе. Возникнут взаимные обвинения и обиды. В результате это негативно скажется на работе примерно такие аргументы обычно высказывают, когда говорят о разрушении команды.
Если команда есть, то она играет по определенным правилам. При отсутствии регламентации правила игры не формализованы и могут трактоваться по-разному. Нет гарантии, что они соответствуют целям собственников и топ-менеджеров организации. Грамотная регламентация может повысить эффективность командной работы за счет того, что правила становятся однозначными, доступными и понятными всем ее участникам. Они не могут быть произвольно изменены отдельными участниками команды, наделенными бóльшими полномочиями или имеющими значительный авторитет. Однако при разработке регламентов нужно быть внимательным, чтобы исключить чрезмерное усложнение механизмов взаимодействия между сотрудниками.
Если же команды менеджеров в компании нетто регламентация тем более не может навредить. Нужно думать о механизмах создания и поддержания возможностей для командной работы, если такой подход устраивает собственников и менеджеров организации. Снижение гибкости в принятии решений, осуществлении изменений и как следствие — уход клиентов
Своевременно принятое, грамотное управленческое решение — это здорово Нона практике неподготовленные, несогласованные, нигде не зафиксированные управленческие решения приводят к проблемам
«Регламентация приведет к формализации отношений между участниками процессов. Начнут разрушаться существующие неформальные, устоявшиеся отношения в коллективе. Возникнут взаимные обвинения и обиды. В результате это негативно скажется на работе примерно такие аргументы обычно высказывают, когда говорят о разрушении команды.
Если команда есть, то она играет по определенным правилам. При отсутствии регламентации правила игры не формализованы и могут трактоваться по-разному. Нет гарантии, что они соответствуют целям собственников и топ-менеджеров организации. Грамотная регламентация может повысить эффективность командной работы за счет того, что правила становятся однозначными, доступными и понятными всем ее участникам. Они не могут быть произвольно изменены отдельными участниками команды, наделенными бóльшими полномочиями или имеющими значительный авторитет. Однако при разработке регламентов нужно быть внимательным, чтобы исключить чрезмерное усложнение механизмов взаимодействия между сотрудниками.
Если же команды менеджеров в компании нетто регламентация тем более не может навредить. Нужно думать о механизмах создания и поддержания возможностей для командной работы, если такой подход устраивает собственников и менеджеров организации. Снижение гибкости в принятии решений, осуществлении изменений и как следствие — уход клиентов
Своевременно принятое, грамотное управленческое решение — это здорово Нона практике неподготовленные, несогласованные, нигде не зафиксированные управленческие решения приводят к проблемам
308
Бизнес-процессы. Моделирование, внедрение, управление
различного масштаба. Например, клиент просит нестандартную скидку. Коммерческий директор гибко и неформально идет ему навстречу. В итоге компания теряет деньги, ау собственников возникают сомнения в искренности этого коммерческого директора. Но если коммерческий директор по формальным критериям откажет и потеряет контракт с крупным клиентом, собственники также будут недовольны и т. п. Как же гибкость связана с регламентацией В 90% ситуаций регламент — очень полезный инструмент. Он дает возможность принимать обоснованные (по определенной методике) управленческие решения, фиксировать их ив последующем оценивать эффективность. Остальные 10% ситуаций должны быть четко обозначены (без детальной регламентации действий сотрудника. При их наступлении управление сразу делегируется на вышестоящий уровень. Таким образом, гибкость не станет синонимом безответственности, а руководители будут четко знать пределы своих полномочий. Дополнительная нагрузка на персонал, снижение производительности
Предполагается, что сотрудники компании потратят часть своего времени на написание регламентов, что снизит производительность труда. Кроме того, походу деятельности придется периодически обращаться к регламентам, проверяя соответствие выполняемой работы установленным требованиям.
Первый аргумент создание и актуализация регламентов действительно занимают немало времени. Только не рядовых сотрудников, а руководителей. Но для них работа по стандартизации — одна из важнейших составляющих деятельности по управлению. Они получают за это зарплату. Руководитель обязан организовать свой рабочий день так, чтобы хватило времени на регламенты. Во многом дефицит времени связан с неупорядоченностью управляемой деятельности, когда правила игры не определены (например, полномочия не делегированы, а сотрудники постоянно отвлекают руководителя, обращаясь с мелкими проблемами
Глава 5. Регламентация бизнес-процессов организации Что касается второго аргумента, то он во многом надуманный. Если действительно сотрудники начнут периодически сверяться с регламентами, то менеджеры должны радоваться этому. Значит, в культуре организации появился новый, важный элемент — работа по стандартам. В реальности, к сожалению, часто наблюдается обратная картина регламенты не работают. Увеличение сроков выполнения процессов из-за необходимости соблюдения регламентов
Этот аргумент аналогичен предыдущему. Предполагается, что после регламентации процессы станет сложнее и дольше выполнять. Если раньше можно было быстро и гибко делать работу, достигая нужного результата, то после регламентации придется действовать по стандарту.
Кроме того, в данном случае не учитываются проблемы и потери, которые всегда сопровождают быструю и гибкую работу. Вообще нужно внимательно оценивать ситуацию с процессами, анализировать степень влияния внешних условий. Если внешняя среда нестабильна и оказывает слишком возмущающее воздействие на процесс, то его нельзя жестко регламентировать. Даже если регламенты актуализируются быстро, можно не успеть внести все необходимые изменения. В этой ситуации могут возникнуть проблемы. Поэтому для некоторых групп процессов в определенных видах бизнеса жесткая регламентация неприемлема. Появление слишком сложных, забюрократизированных регламентов
Такой риск действительно есть. Он связан с несколькими факторами:
слишком формальной постановкой задачи регламентации и формальной, поверхностной оценкой полученных результатов руководителями;
недостаточным методическим обеспечением проекта;
—
плохим управлением проектом
310
Бизнес-процессы. Моделирование, внедрение, управление
неэффективным и забюрократизированным процессом согласования документов;
отсутствием заинтересованности и готовности последовательно заниматься внедрением системы регламентации упер- вых лиц организации;
отсутствием специалистов нужной квалификации;
—
слишком сжатыми сроками;
—
недостаточным бюджетом проекта;
—
прочее.
—
Если регламенты пишут плохо подготовленные специалисты по недостаточно проработанной методике, используя неудобные формы, тратя на это в два-три раза меньше времени, чем положено, то они вполне могу оказаться несоответствующими поставленным целям, сложными, противоречивыми и неудобными в работе. Возможность так называемой итальянской забастовки
Некоторые специалисты предполагают возможность так называемой итальянской забастовки, когда сотрудники организации преднамеренно работают в строгом соответствии с регламентами. Предполагают также, что эта система регламентов чрезмерно сложна, запутанна, противоречива, как и сами регламенты. В результате процессы выполняются слишком долго, клиенты недовольны, прибыль снижается и т. п.
Такая ситуация может сложиться в крупной организации (например, государственной) после проведения ряда проверок и показательного увольнения нескольких руководителей. В этом случае система начинает работу по формальным регламентам. Временно перестают действовать привычные и выгодные определенным субъектам обходные пути, ускоряющие формальный ход процесса. Поскольку регламентов много и они подчас взаимно противоречивы, проблемы решаются очень долго В данном примере в систему входят как сотрудники организации, таки внешние лица, которые пользуются их услугами
312
Бизнес-процессы. Моделирование, внедрение, управление
и анализировать эти минусы, они обращают внимание не на проблемы, связанные с системой регламентации, а на риск внедрить ее не так, как хотелось бы. Это нормально. Более того, такой взгляд поможет руководителям оценить риски проекта и управлять им эффективнее. Плюсы регламентации бизнес-процессов
Мы рассмотрели некоторые возможные минусы регламентации. Обратимся теперь к плюсам. К ним можно отнести:
На стадии внедрения системы регламентации:
формализацию деятельности, обеспечение единого понимания требований сотрудниками;
согласование взаимодействия структурных подразделений
—
организации;
выявление и устранение зон безответственности, пересечения
—
ответственности;
формирование предпосылок для делегирования полномочий и повышения эффективности управления;
поиск и внедрение изменений, повышающих эффективность
—
процессов.
На стадии эксплуатации системы регламентации:
прозрачность бизнеса (для собственников и инвесторов);
—
повышение эффективности управления (за счет возможности объективного контроля требований к деятельности сотруд- ников);
снижение рисков, связанных с уходом руководителей и спе-
—
циалистов;
повышение эффективности процессов подбора и обучения персонала
Этот аргумент аналогичен предыдущему. Предполагается, что после регламентации процессы станет сложнее и дольше выполнять. Если раньше можно было быстро и гибко делать работу, достигая нужного результата, то после регламентации придется действовать по стандарту.
Кроме того, в данном случае не учитываются проблемы и потери, которые всегда сопровождают быструю и гибкую работу. Вообще нужно внимательно оценивать ситуацию с процессами, анализировать степень влияния внешних условий. Если внешняя среда нестабильна и оказывает слишком возмущающее воздействие на процесс, то его нельзя жестко регламентировать. Даже если регламенты актуализируются быстро, можно не успеть внести все необходимые изменения. В этой ситуации могут возникнуть проблемы. Поэтому для некоторых групп процессов в определенных видах бизнеса жесткая регламентация неприемлема. Появление слишком сложных, забюрократизированных регламентов
Такой риск действительно есть. Он связан с несколькими факторами:
слишком формальной постановкой задачи регламентации и формальной, поверхностной оценкой полученных результатов руководителями;
недостаточным методическим обеспечением проекта;
—
плохим управлением проектом
310
Бизнес-процессы. Моделирование, внедрение, управление
неэффективным и забюрократизированным процессом согласования документов;
отсутствием заинтересованности и готовности последовательно заниматься внедрением системы регламентации упер- вых лиц организации;
отсутствием специалистов нужной квалификации;
—
слишком сжатыми сроками;
—
недостаточным бюджетом проекта;
—
прочее.
—
Если регламенты пишут плохо подготовленные специалисты по недостаточно проработанной методике, используя неудобные формы, тратя на это в два-три раза меньше времени, чем положено, то они вполне могу оказаться несоответствующими поставленным целям, сложными, противоречивыми и неудобными в работе. Возможность так называемой итальянской забастовки
Некоторые специалисты предполагают возможность так называемой итальянской забастовки, когда сотрудники организации преднамеренно работают в строгом соответствии с регламентами. Предполагают также, что эта система регламентов чрезмерно сложна, запутанна, противоречива, как и сами регламенты. В результате процессы выполняются слишком долго, клиенты недовольны, прибыль снижается и т. п.
Такая ситуация может сложиться в крупной организации (например, государственной) после проведения ряда проверок и показательного увольнения нескольких руководителей. В этом случае система начинает работу по формальным регламентам. Временно перестают действовать привычные и выгодные определенным субъектам обходные пути, ускоряющие формальный ход процесса. Поскольку регламентов много и они подчас взаимно противоречивы, проблемы решаются очень долго В данном примере в систему входят как сотрудники организации, таки внешние лица, которые пользуются их услугами
Глава 5. Регламентация бизнес-процессов организации В коммерческой организации условия для возникновения итальянской забастовки создаются реже. В небольшой и средней компании вероятность ее возникновения ниже, чем в крупной или очень крупной.
Если собственники и топ-менеджмент постоянно занимаются анализом эффективности системы регламентации и предпринимают шаги по ее улучшению, то предпосылки для возникновения итальянской забастовки, скорее всего, не возникнут. Возможная утечка информации о стандартах работы в другие организации
Утечка информации (передача комплекта регламентирующих документов в другую организацию) вполне возможна. Если речь идет о регламентах процессов или должностных инструкциях, ущерб от такой утечки не будет значительным. Другое дело, если передаются чертежи, технологические документы, рецептуры, управленческая отчетность и т. п. Что касается нормативно-методических документов, то эффективно использовать их в другой компании невозможно, так как организации имеют разные:
организационную структуру и численность персонала;
—
квалификацию и опыт сотрудников;
—
критерии и алгоритмы принятия управленческих решений;
—
культуру организации;
—
прочее.
—
Чтобы скопировать бизнес компании, одного только комплекта нормативно-методических документов недостаточно. (Как нельзя, например, стать спортсменом за один день, просто повторяя систему тренировок чемпиона.)
Сейчас существуют системы информационной безопасности, одна из задач которых — предотвращать утечку информации.
Говоря о минусах регламентации, хочу отметить один интересный момент. Когда специалисты организации начинают формулировать
Если собственники и топ-менеджмент постоянно занимаются анализом эффективности системы регламентации и предпринимают шаги по ее улучшению, то предпосылки для возникновения итальянской забастовки, скорее всего, не возникнут. Возможная утечка информации о стандартах работы в другие организации
Утечка информации (передача комплекта регламентирующих документов в другую организацию) вполне возможна. Если речь идет о регламентах процессов или должностных инструкциях, ущерб от такой утечки не будет значительным. Другое дело, если передаются чертежи, технологические документы, рецептуры, управленческая отчетность и т. п. Что касается нормативно-методических документов, то эффективно использовать их в другой компании невозможно, так как организации имеют разные:
организационную структуру и численность персонала;
—
квалификацию и опыт сотрудников;
—
критерии и алгоритмы принятия управленческих решений;
—
культуру организации;
—
прочее.
—
Чтобы скопировать бизнес компании, одного только комплекта нормативно-методических документов недостаточно. (Как нельзя, например, стать спортсменом за один день, просто повторяя систему тренировок чемпиона.)
Сейчас существуют системы информационной безопасности, одна из задач которых — предотвращать утечку информации.
Говоря о минусах регламентации, хочу отметить один интересный момент. Когда специалисты организации начинают формулировать
312
Бизнес-процессы. Моделирование, внедрение, управление
и анализировать эти минусы, они обращают внимание не на проблемы, связанные с системой регламентации, а на риск внедрить ее не так, как хотелось бы. Это нормально. Более того, такой взгляд поможет руководителям оценить риски проекта и управлять им эффективнее. Плюсы регламентации бизнес-процессов
Мы рассмотрели некоторые возможные минусы регламентации. Обратимся теперь к плюсам. К ним можно отнести:
На стадии внедрения системы регламентации:
формализацию деятельности, обеспечение единого понимания требований сотрудниками;
согласование взаимодействия структурных подразделений
—
организации;
выявление и устранение зон безответственности, пересечения
—
ответственности;
формирование предпосылок для делегирования полномочий и повышения эффективности управления;
поиск и внедрение изменений, повышающих эффективность
—
процессов.
На стадии эксплуатации системы регламентации:
прозрачность бизнеса (для собственников и инвесторов);
—
повышение эффективности управления (за счет возможности объективного контроля требований к деятельности сотруд- ников);
снижение рисков, связанных с уходом руководителей и спе-
—
циалистов;
повышение эффективности процессов подбора и обучения персонала
Глава 5. Регламентация бизнес-процессов организации создание возможностей для аудита бизнес-процессов и запуска системы непрерывного совершенствования (цикла создание предпосылок для последующей эффективной автоматизации бизнес-процессов;
обеспечение возможности развития бизнеса (тиражирование опыта — открытие филиалов в регионах и т. п. Формализация деятельности, обеспечение единого понимания требований сотрудниками
По ходу регламентации процесса устанавливаются общие для всех или некоторых) сотрудников требования к выполнению работы. Субъективные мнения и взгляды на порядок выполнения процесса заменяются формализованными и объективно контролируемыми требованиями. Сотрудникам становится комфортнее работать они знают, что и когда от них может потребовать руководитель. У них есть информация, как в соответствии с требованиями организации выполнять работу. Согласование взаимодействия структурных подразделений организации
При разработке регламентов приходится уточнять формы документов, сроки и условия их передачи между структурными подразделениями. Кроме того, приходится согласовывать требования с руководителями этих подразделений. В результате можно добиться лучшего взаимопонимания на межфункциональном уровне и согласовать взаимодействие, тем самым повышая его эффективность. Выявление и устранение зон безответственности, пересечения ответственности
Описание процесса и последующая регламентация — отличные инструменты выявления и устранения зон безответственности или пересечения ответственности. Формализуя деятельность и назначая ответственных, можно определить те операции, контроль которых не осуществляется или осуществляется недостаточно
314
Бизнес-процессы. Моделирование, внедрение, управление. Формирование предпосылок для делегирования полномочий и повышения эффективности управления
Когда последовательность операций процесса формализована и представлена в виде схемы, исполнителю понятно, чтó нужно делать. Описание наиболее часто возникающих отклонений и порядка действий сотрудников в этих случаях — основа для делегирования полномочий. Руководство определяет, в каких ситуациях сотрудник должен самостоятельно действовать по утвержденной процедуре, а в каких сразу сообщить руководителю о критических отклонениях в процессе. Если деятельность не формализована, то делегирование полномочий затруднено или связано со значительными рисками. Поиски внедрение изменений, повышающих эффективность процессов
Регламентация невозможна без описания процесса. Походу описания, как правило, выявляются определенные проблемы. Анализ их причин, разработка и выполнение мероприятий по их устранению повышают эффективность процессов. Иными словами, задача выполнить регламентацию неизбежно влечет за собой ту или иную реорганизацию процессов.
На стадии эксплуатации система регламентации процессов дает организации следующие плюсы. Прозрачность бизнеса
Наличие системы процессов и базы актуальных регламентирующих документов по ним делает деятельность организации прозрачной для собственников и топ-менеджеров. Они имеют представление о том, чем именно занимается каждое структурное подразделение, с кем взаимодействует, за что конкретно отвечают руководители. Такая ситуация комфортна для руководителей, готовых работать в команде для достижения стратегических целей организации. Для менеджеров, преследующих исключительно личные цели, прозрачная ситуация некомфортна и вынуждает их покидать организацию
316
Бизнес-процессы. Моделирование, внедрение, управление
именно процессах участвует сотрудник, что делает, требования к сроками т. п. Эту информацию можно представить в виде приложения к должностной инструкции (регламент работы сотрудника. Специалисты службы по управлению персоналом будут использовать такие документы для более эффективного подбора и последующего обучения персонала. Создание возможностей для аудита бизнес-процессов и запуска системы непрерывного совершенствования (цикла Один из способов обеспечить актуальность и исполнение требований регламентирующих документов — внутренний аудит. Если регламентов нет либо они устарели, то смысли возможность его проведения теряется. Напротив, регулярно проводимые аудиты помогают руководителями сотрудникам эффективнее использовать регламенты, изменить отношение к работе по стандартам.
Наличие системы регламентации процессов (исполнение — контроль актуализация/улучшение нормативно-методических документов один из факторов успешного внедрения цикла непрерывного совершенствования PDCA.
5.3.11. Создание предпосылок для последующей эффективной автоматизации бизнес-процессов
Если регламенты процессов постоянно контролируют и актуализируют, то их можно использовать при постановке задачи автоматизации. Нет ничего плохого в том, что графические схемы процессов в этих регламентах могут быть описаны простейшими средствами. Главное, что они структурированы и выполняются. Сотрудники понимают, что такое процессы, как они регламентируются икон- тролируются. Так гораздо проще перейти к использованию более сложных инструментов описания процессов с целью автоматизации, в частности начать использовать стандарт BPMN.
318
Бизнес-процессы. Моделирование, внедрение, управление
актуализацию документов. Такую систему нельзя создать за один день, но ее можно целенаправленно строить в течение некоторого времени (один-два года. Определение системы стандартизации бизнес-процессов
Сформулируем определение системы стандартизации (ее можно также называть системой регламентации) бизнес-процессов:
обеспечение возможности развития бизнеса (тиражирование опыта — открытие филиалов в регионах и т. п. Формализация деятельности, обеспечение единого понимания требований сотрудниками
По ходу регламентации процесса устанавливаются общие для всех или некоторых) сотрудников требования к выполнению работы. Субъективные мнения и взгляды на порядок выполнения процесса заменяются формализованными и объективно контролируемыми требованиями. Сотрудникам становится комфортнее работать они знают, что и когда от них может потребовать руководитель. У них есть информация, как в соответствии с требованиями организации выполнять работу. Согласование взаимодействия структурных подразделений организации
При разработке регламентов приходится уточнять формы документов, сроки и условия их передачи между структурными подразделениями. Кроме того, приходится согласовывать требования с руководителями этих подразделений. В результате можно добиться лучшего взаимопонимания на межфункциональном уровне и согласовать взаимодействие, тем самым повышая его эффективность. Выявление и устранение зон безответственности, пересечения ответственности
Описание процесса и последующая регламентация — отличные инструменты выявления и устранения зон безответственности или пересечения ответственности. Формализуя деятельность и назначая ответственных, можно определить те операции, контроль которых не осуществляется или осуществляется недостаточно
314
Бизнес-процессы. Моделирование, внедрение, управление. Формирование предпосылок для делегирования полномочий и повышения эффективности управления
Когда последовательность операций процесса формализована и представлена в виде схемы, исполнителю понятно, чтó нужно делать. Описание наиболее часто возникающих отклонений и порядка действий сотрудников в этих случаях — основа для делегирования полномочий. Руководство определяет, в каких ситуациях сотрудник должен самостоятельно действовать по утвержденной процедуре, а в каких сразу сообщить руководителю о критических отклонениях в процессе. Если деятельность не формализована, то делегирование полномочий затруднено или связано со значительными рисками. Поиски внедрение изменений, повышающих эффективность процессов
Регламентация невозможна без описания процесса. Походу описания, как правило, выявляются определенные проблемы. Анализ их причин, разработка и выполнение мероприятий по их устранению повышают эффективность процессов. Иными словами, задача выполнить регламентацию неизбежно влечет за собой ту или иную реорганизацию процессов.
На стадии эксплуатации система регламентации процессов дает организации следующие плюсы. Прозрачность бизнеса
Наличие системы процессов и базы актуальных регламентирующих документов по ним делает деятельность организации прозрачной для собственников и топ-менеджеров. Они имеют представление о том, чем именно занимается каждое структурное подразделение, с кем взаимодействует, за что конкретно отвечают руководители. Такая ситуация комфортна для руководителей, готовых работать в команде для достижения стратегических целей организации. Для менеджеров, преследующих исключительно личные цели, прозрачная ситуация некомфортна и вынуждает их покидать организацию
Глава 5. Регламентация бизнес-процессов организации
315 5.3.7. Повышение эффективности управления
Регламентирующие документы по процессу дают возможность руководителю выполнять объективный контроль исполнения требований. Он может осуществляться:
ежедневно — выборочный визуальный контроль соблюдения сотрудниками требований нормативно-методических документов по процессам;
еженедельно — анализ показателей по процессам, контроль наличия и правильности заполнения документации по процессу, анализ результатов деятельности за неделю;
ежеквартально (разв полгода) — участие в аудите исполнения требований регламентирующей документации по процессу проводят внутренние аудиторы организации);
прочее.
—
5.3.8. Снижение рисков, связанных с уходом руководителей и специалистов
Во многих компаниях технология выполнения процессов хранится в головах сотрудников — на бумаге она не зафиксирована. Процессы выполняются, их результаты вполне приемлемы сточки зрения руководителей. Но существует риск, что при уходе из организации руководителей или ключевых специалистов процессы перестанут стабильно работать, возникнут проблемы с клиентами, возрастут затраты и т. п. Поэтому наличие комплекта актуальных нормативно-методических документов по процессам существенно снижает риск. Повышение эффективности процессов подбора и обучения персонала
Один из полезных результатов регламентации процессов — возможность получать полное описание деятельности сотрудников. Например, в должностной инструкции можно указывать, в каких
315 5.3.7. Повышение эффективности управления
Регламентирующие документы по процессу дают возможность руководителю выполнять объективный контроль исполнения требований. Он может осуществляться:
ежедневно — выборочный визуальный контроль соблюдения сотрудниками требований нормативно-методических документов по процессам;
еженедельно — анализ показателей по процессам, контроль наличия и правильности заполнения документации по процессу, анализ результатов деятельности за неделю;
ежеквартально (разв полгода) — участие в аудите исполнения требований регламентирующей документации по процессу проводят внутренние аудиторы организации);
прочее.
—
5.3.8. Снижение рисков, связанных с уходом руководителей и специалистов
Во многих компаниях технология выполнения процессов хранится в головах сотрудников — на бумаге она не зафиксирована. Процессы выполняются, их результаты вполне приемлемы сточки зрения руководителей. Но существует риск, что при уходе из организации руководителей или ключевых специалистов процессы перестанут стабильно работать, возникнут проблемы с клиентами, возрастут затраты и т. п. Поэтому наличие комплекта актуальных нормативно-методических документов по процессам существенно снижает риск. Повышение эффективности процессов подбора и обучения персонала
Один из полезных результатов регламентации процессов — возможность получать полное описание деятельности сотрудников. Например, в должностной инструкции можно указывать, в каких
316
Бизнес-процессы. Моделирование, внедрение, управление
именно процессах участвует сотрудник, что делает, требования к сроками т. п. Эту информацию можно представить в виде приложения к должностной инструкции (регламент работы сотрудника. Специалисты службы по управлению персоналом будут использовать такие документы для более эффективного подбора и последующего обучения персонала. Создание возможностей для аудита бизнес-процессов и запуска системы непрерывного совершенствования (цикла Один из способов обеспечить актуальность и исполнение требований регламентирующих документов — внутренний аудит. Если регламентов нет либо они устарели, то смысли возможность его проведения теряется. Напротив, регулярно проводимые аудиты помогают руководителями сотрудникам эффективнее использовать регламенты, изменить отношение к работе по стандартам.
Наличие системы регламентации процессов (исполнение — контроль актуализация/улучшение нормативно-методических документов один из факторов успешного внедрения цикла непрерывного совершенствования PDCA.
5.3.11. Создание предпосылок для последующей эффективной автоматизации бизнес-процессов
Если регламенты процессов постоянно контролируют и актуализируют, то их можно использовать при постановке задачи автоматизации. Нет ничего плохого в том, что графические схемы процессов в этих регламентах могут быть описаны простейшими средствами. Главное, что они структурированы и выполняются. Сотрудники понимают, что такое процессы, как они регламентируются икон- тролируются. Так гораздо проще перейти к использованию более сложных инструментов описания процессов с целью автоматизации, в частности начать использовать стандарт BPMN.
Глава 5. Регламентация бизнес-процессов организации
317 5.3.12. Обеспечение возможности развития бизнеса
Наличие актуальной регламентной базы облегчает тиражирование бизнеса при создании дочерних компаний, открытии новых филиалов в регионах. Конечно, одних регламентов мало, но это серьезное подспорье для руководителей, перед которыми поставлена задача создать новый филиал и т. п. Система стандартизации бизнес-процессов
В компании среднего размера директор издал приказ, содержащий следующую фразу Рабочей группе в срок такой-то разработать порядок описания, регламентации и хранения бизнес-процессов». Регламенты предполагалось хранить как товар — на полке К сожалению, в этой организации таки получилось были разработаны десятки схем бизнес-процессов, затем с использованием утомительного ручного труда на базе этих схем подготовили и согласовали регламенты, а потом сдали в архив на хранение. Как-то раз одного из начальников отдела этой компании спросили, как обстоят дела с про- цессным подходом. На что он ответил Его внедрили еще три года назад, — сделал кислую мину и сослался на комплект регламентов, который пылится на полках. Понятно, что разработанные регламенты фактически не работали.
Как добиться того, чтобы регламенты выполнения бизнес- процессов активно использовались и сотрудники работали по стандартам Достаточно ли, например, заказать внешних консультантов, которые за несколько месяцев опишут бизнес-процессы и разработают соответствующие регламенты Что получит в результате директор компании Вероятнее всего, это будет толстая кипа бумаг, которые вряд ли начнут работать. Дело даже не в том, что регламенты могут оказаться плохими. Проблема в отсутствии системы, которая обеспечила бы не только разработку стандартов по бизнес-процессам, но и обучение персонала, контроль исполнения, своевременную
317 5.3.12. Обеспечение возможности развития бизнеса
Наличие актуальной регламентной базы облегчает тиражирование бизнеса при создании дочерних компаний, открытии новых филиалов в регионах. Конечно, одних регламентов мало, но это серьезное подспорье для руководителей, перед которыми поставлена задача создать новый филиал и т. п. Система стандартизации бизнес-процессов
В компании среднего размера директор издал приказ, содержащий следующую фразу Рабочей группе в срок такой-то разработать порядок описания, регламентации и хранения бизнес-процессов». Регламенты предполагалось хранить как товар — на полке К сожалению, в этой организации таки получилось были разработаны десятки схем бизнес-процессов, затем с использованием утомительного ручного труда на базе этих схем подготовили и согласовали регламенты, а потом сдали в архив на хранение. Как-то раз одного из начальников отдела этой компании спросили, как обстоят дела с про- цессным подходом. На что он ответил Его внедрили еще три года назад, — сделал кислую мину и сослался на комплект регламентов, который пылится на полках. Понятно, что разработанные регламенты фактически не работали.
Как добиться того, чтобы регламенты выполнения бизнес- процессов активно использовались и сотрудники работали по стандартам Достаточно ли, например, заказать внешних консультантов, которые за несколько месяцев опишут бизнес-процессы и разработают соответствующие регламенты Что получит в результате директор компании Вероятнее всего, это будет толстая кипа бумаг, которые вряд ли начнут работать. Дело даже не в том, что регламенты могут оказаться плохими. Проблема в отсутствии системы, которая обеспечила бы не только разработку стандартов по бизнес-процессам, но и обучение персонала, контроль исполнения, своевременную
318
Бизнес-процессы. Моделирование, внедрение, управление
актуализацию документов. Такую систему нельзя создать за один день, но ее можно целенаправленно строить в течение некоторого времени (один-два года. Определение системы стандартизации бизнес-процессов
Сформулируем определение системы стандартизации (ее можно также называть системой регламентации) бизнес-процессов:
1 ... 11 12 13 14 15 16 17 18 ... 21