Методика документирования бизнес процессов

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

Простые шаги для успешного документирования бизнес-процессов

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

Ниже приведены примеры бизнес-процессов, которые часто документируются:

• аттестация персонала
• Процесс разрешения жалоб клиентов
• Методы проверки и обслуживания оборудования
• Предоставление услуг
• Процесс выставления и сбора счетов
• Ориентация новых сотрудников

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

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

Этапы документирования бизнес-процессов

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

Первый шаг: Определение процедуры

Сначала запишите на флипчарте название процедуры и кратко объясните, что она собой представляет.

Второй шаг: Границы документации бизнес-процесса

Определите, где начинается бизнес-процесс и где он заканчивается. Что запускает процесс, чтобы он мог начаться? Когда вы узнаете, что он завершен?

Третий шаг: Выход документации бизнес-процесса

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

Четвертый этап: Вход документации бизнес-процесса

Определите, что требуется для выполнения процедуры, и источник необходимых элементов. Бумага, Excel и Интернет — все это потенциальные источники.

Пятый этап: Деятельность бизнес-процесса

Рассмотрите все задачи (что), которые должны быть выполнены для успешного завершения документирования бизнес-процесса. Дайте пояснения к каждой из них, используя глагольно-объектную структуру. На данном этапе не стоит думать о том, как будут расположены действия; вместо этого нужно просто свободно провести мозговой штурм. Липкие записки могут оказаться весьма полезными на этом этапе. Просто напишите по одному действию на каждой записке.

Шестой шаг: Организуйте документацию по бизнес-процессам

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

Седьмой шаг: Обзор документации бизнес-процесса

В качестве предварительной проверки качества продукта изучите последовательность действий. Создают ли границы, которые вы установили на Шаге 2, впечатление завершенности?

Восьмой шаг: Назначение ролей бизнес-процесса

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

Девятый этап: Расшифровка документации бизнес-процесса

Этапы должны быть введены в программное приложение для составления блок-схем в виде так называемой плавательной дорожки.

Десятый этап: Обзор завершенной документации бизнес-процесса

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

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

• Payroll — это название документации бизнес-процесса.
• Пределы процесса: сотрудники получают компенсацию за свой ежемесячный труд посредством электронного банковского перевода.
• Зарплатные чеки и ежемесячные отчеты о заработной плате являются результатами документации бизнес-процесса.
• Карточки учета рабочего времени сотрудников, данные об отпусках и информация о банковских счетах являются примерами входов документации бизнес-процесса.
• Операции по обработке включают проверку карточек учета рабочего времени сотрудников, поиск заявлений на отпуск, внесение данных на банковские счета, перемещение ежемесячной заработной платы на соответствующие счета и создание отчетов о заработной плате.
• Сотрудники, начальник и отдел кадров играют определенную роль в бизнес-процессе.

Лучшие практики документирования процессов

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

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

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

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

Преимущества документирования процедур и процессов

Содействие в достижении единства взглядов всех сотрудников путем представления единой точки зрения на процессы, задействованные в документации бизнес-процессов. При наличии четкой документации бизнес-процессов можно изменить процессы в любом документе. Помощь в определении оптимальных условий для продуктивного сотрудничества и результативности работы. Помогает обнаружить узкие места и неэффективность процессов (даже в тех «хорошо отработанных» методах), которые не были бы замечены при любых других обстоятельствах. Хорошо документированная процедура сэкономит время и снизит вероятность ошибок, поскольку устраняет любую возможность для двусмысленности и дает четкие указания.

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

Лучшие бизнес-шаблоны для документирования бизнес-процессов

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

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

• Шаблон описывает множество видов данных, которые необходимы.
• Шаблон также Определяет результат произведенного метода.

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

Примером шаблона процесса документирования является:

• Блок-схемы
• Формы
• Картинки
• Учебные пособия
• Диаграммы процессов
• Прикрепленный документ

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

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

Использование автоматизированных бизнес-шаблонов

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

Заключение

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

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

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

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

Что такое документация по процессам?

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

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

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

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

Документация по процессу и составление карты процесса

Несмотря на то, что эти термины похожи, документация по процессу и составление карты процесса обладают рядом ключевых отличий.

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

Как создать документацию по процессу

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

На каждом этапе нам необходимо формально документировать все стадии процесса, чтобы синхронизировать работу команды и обеспечить чёткий обмен информацией. Мы рассмотрим эти восемь действий и выделим ключевые компоненты, которые вам следует включить в свою документацию по процессу.

1. Проанализируйте исходный процесс

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

В процессе анализа следует выделить:

• Основные задачи: определите, каких ключевых показателей эффективности вы хотите достичь или какие бизнес-задачи выполнить.

• Заинтересованные лица: возможно, вы пока ещё не знаете их всех, но подумайте, какие команды будут работать вместе.

• Хронология: оцените объём процесса и хронологию его выполнения по методу критического пути.

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

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

2. Определите границы процесса

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

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

Автоматизировать работу с помощью Asana

3. Определите точки входа и выхода

Третий этап подразумевает определение точек входа и выхода.

• Точки входа — это ресурсы, необходимые для выполнения процесса.

• Точки выхода — это то, чего вы хотите достичь по завершении процесса.

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

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

4. Определите этапы процесса

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

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

После того как вы определили, что запускает и завершает процесс, последовательно перечислите все его этапы. Если необходимо выполнить несколько задач, перечислите их все в рамках одного этапа. Этапы должны быть как можно более простыми, фиксировать следует только основные части процесса.

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

5. Свяжитесь с заинтересованными лицами проекта

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

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

6. Создайте блок-схему процесса

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

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

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

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

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

7. Отметьте исключения для хода процесса

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

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

8. Протестируйте процесс

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

Для определения слабых мест задайте следующие вопросы:

• Решила ли документация по процессу проблему, которую вы хотели устранить?

• Нужно ли внести более существенные изменения, чтобы процесс начал работать оптимально?

Проработав слабые места, определите эффективность процесса. Это ещё одна возможность «отшлифовать» процесс, чтобы он работал как можно более чётко.

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

Преимущества документации по процессам

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

Существует четыре основных преимущества ведения документации по процессам — от устранения ошибок до улучшения распределения ресурсов и повышения эффективности.

Устранение ошибок

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

Заблаговременное документирование процесса позволяет избежать следующих проблем:

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

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

• Нечёткость целей и результатов: если сотрудники не понимают предназначение того или иного процесса, у них может не быть чёткого понимания ожидаемых результатов или приоритетов.

Документирование процессов позволяет анализировать ошибки и позволяет сформировать систему постоянного контроля потенциально слабых мест на протяжении всего жизненного цикла процесса. Это обеспечивает возможность изменить или устранить ненужные шаги.

Сокращение непродуктивной работы

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

В числе распространённых препятствий, которые устраняет документирование процессов:

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

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

• Разрозненность коммуникаций: когда информация хранится в разных источниках, это может привести к сбоям в процессе обмена ею.

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

Оптимизация распределения ресурсов

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

Это гарантирует, что ресурсы:

• Применяются правильно: когда команды знают, какие ресурсы использовать, они могут делать это правильно и эффективно.

• Привязаны к нужным этапам: связав ресурсы с задачами, вы будете чётко осознавать, как и когда их нужно использовать.

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

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

Улучшение обмена информацией

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

Преимущества оптимизированного обмена информацией:

• Работа сразу выполняется правильно: чёткие коммуникации сокращают риск возникновения путаницы и снижения качества работы.

• Создание базы знаний по процессам: обмен информацией помогает командам быть в курсе новых процессов.

• Расширенные карты процессов и стандартные рабочие процедуры: коммуникации позволяют прояснять информацию и обеспечивать соответствие карт процессов и процедур исходным целям проекта.

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

Ускоряйте свой прогресс посредством документирования процессов

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

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

Попробовать ПО для управления рабочими процессами от Asana

Справка по системе Платформа ELMA BPM

× Поиск Поиск Поиск  Предыдущая Следующая

(c) Company name, 2016Copyright © 2006–2021 ELMA

В системе ELMA существует возможность документирования бизнес-процессов (формирования документации по ним).

Документация по процессу – это веб-страница с внутренними гиперссылками, в которой заключена вся техническая информация о процессе: карта процесса, матрица и зоны ответственности, метрики и показатели, контекстные переменные, элементы модели процесса, переходы, сценарии.

В веб-приложении документация по процессам располагается в подразделе Документирование раздела Процессы (рис. 1). Раздел Документирование состоит из двух частей:

• Мои процессы

В подразделе Мои процессы расположена документация по процессам, в которых текущий пользователь является владельцем или куратором.

Рис. 1. Подраздел “Документирование – Мои процессы”

Щелкнув мышью по названию процесса, Вы переместитесь на страницу документации по процессу (рис. 2). На странице расположена таблица со списком опубликованных версий процесса и информацией по ним:

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

Рис. 2. Страница документации по процессу “Заявка на приобретение офисной техники”

В подразделе Вся документация отображается полное дерево процессов как в Дизайнере (рис. 3). Данный подраздел появляется только у тех пользователей, которые обладают правом полного доступа к разделу Документирование. Права назначаются в разделе Администрирование – Пользователи – Настройки доступа – Глобальные настройки доступа – Процессы – Полный доступ к разделу «Документирование» .

Рядом с процессом отображается номер его опубликованной версии.

Рис. 3. Подраздел “Документирование – Вся документация”

Нажав кнопкой мыши по названию процесса, Вы переместитесь на страницу документации по процессу (рис. 2).

Иллюстрация: Andrea Piacquadio / Pexels / Colowgee для Skillbox Media

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

Дипломированный специалист по автоматизации бизнес-процессов. Девять лет опыта в бизнесе и консалтинге. Смоделировал более тысячи процессов для торговых и промышленных предприятий. Основатель OkoCRM.

---

Фото: личный архив Александра Завьялова

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

О базовых терминах и идеях в области бизнес-процессов мы рассказали в большом гайде. В этой статье разберём подробнее:

• что такое моделирование бизнес-процессов и нотации для моделирования;
• какие есть подходы к моделированию и кто этим обычно занимается;
• как изображают бизнес-процессы;
• как самостоятельно описать бизнес-процессы.

---

Бизнес-процессы — любые операции внутри компании, которые помогают решать бизнес-задачи и зарабатывать. Моделирование бизнес-процессов — описание этих операций и документирование требований к ним.

Ответственные за моделирование разбираются в процессах компании и описывают, кто, что и как делает. Изучают каждую операцию и разбивают её на этапы. Сначала описывают всё это текстом, затем превращают описание в схему.

В профессиональном моделировании бизнес-процессов часто используют нотации. Нотация — это набор правил для графического описания бизнес-моделей. Нотации описывают:

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

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

Специалисты придумали много вариантов нотаций. Их делят на две основные категории:

• Структурные. Они показывают элементы процесса и взаимосвязи между ними. Это нотации стандарта IDEF: IDEF0, IDEF1x, IDEF4, IDEF5.
• Динамические. Они показывают логику выполнения процессов, последовательность и варианты их использования. Это нотации DFD, EPC, BPMN.

Ниже, когда мы будем говорить о подходах к моделированию, расскажем о двух вариантах нотаций — IDEF0 и BPMN.

С получившейся моделью бизнес-процесса работают дальше. Двигают элементы так, чтобы корректировать продолжительность цикла, влиять на качество результата или снижать себестоимость. Это называется оптимизацией бизнес-процесса — подробнее о ней говорили в статье. Но прежде чем оптимизировать и улучшать, важно провести качественное моделирование.

В моделировании бизнес-процессов есть три основных подхода: функциональный, процессный и ментальный. В следующих разделах разберём их подробнее.

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

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

У модели есть точки входа и выхода: то, что имеем на старте, и то, что хотим получить. Внутри — промежуточные результаты, ресурсы и факторы, которые влияют на процесс.

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

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

На мой взгляд, функциональный подход понятнее всего реализован в нотации IDEF0. Она рассматривает процесс как совокупность логически связанных между собой работ. Нотация показывает, как объекты подчинены друг другу внутри процесса.

Разберём на примере. Пусть это будет изготовление рекламного ролика.

Процесс изготовления рекламного ролика — основной блок с процессами. Я называю его «чёрный ящик». У него есть три входа и один выход:

1. Сверху — вход для информации о контроле и ограничениях. Это данные, которые определяют условия для реализации процесса. Например, при разработке ролика нас будет ограничивать законодательство и стайлбук заказчика. А ещё мы будем опираться на перечень услуг клиента — чтобы в рекламе были корректные данные.

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

О том, как составить бриф для клиента в рекламе и digital, писали в статье.

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

4. Справа — выходы. Это результаты, которые мы получим: заключим договор, снимем ролик и предложим сотрудничать на постоянной основе.

Вот как функция будет выглядеть в виде диаграммы.

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

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

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

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

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

У процессного подхода есть свои нотации. Стандартом считается BPMN — базовый набор условных обозначений. Его используют для изображения бизнес-процесса в виде блок-схемы.

Нотация BPMN есть в каждом конструкторе для моделирования, но пользоваться ей не обязательно. Гораздо важнее, чтобы схема процесса была читаемой и понятной для руководителя и исполнителей.

Для примера нарисовали блок-схему обработки заявки в учебном центре. Она не соответствует канонам BPMN, но всё равно наглядна и понятна.

Это вариант моделирования «для себя». Его используют, чтобы структурировать общие представления о бизнес-процессе, но не раскладывать его на этапы и не составлять алгоритмов.

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

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

Ниже дан пример ментальной карты процесса снабжения предприятия. На карте собраны понятия, которые связаны между собой внутри процесса. Но по этапам они не распределены.

Обычно моделированием бизнес-процессов занимаются внутренние сотрудники компании или подрядчики. Выбор исполнителя зависит от размеров бизнеса и целей моделирования.

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

Рассмотрим, кто может заниматься моделированием процессов.

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

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

Подрядчики. В среднем и крупном бизнесе моделировать бизнес-процессы внутренними силами точно не получится — количество и объём всех процессов уже не укладываются в голове собственника.

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

Моделирование как отдельную услугу заказывают редко. Чаще это один из этапов внедрения систем автоматизации — CRM, ECM или ERP. Это работает по такой схеме:

• Команда внедрения — подрядчик — приходит на территорию заказчика.
• Она описывает процессы, проводит аудит и составляет аналитический отчёт с вариантами оптимизации.
• Заказчик утверждает отчёт.
• Подрядчик внедряет систему автоматизации с уже оптимизированными процессами.

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

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

В специальных программах. Это способ для профессионалов в моделировании.

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

Вот четыре конструктора, которые я использовал в своей практике для моделирования процессов:

• Microsoft Visio 2010 — векторный графический редактор для создания разных видов схем: блок-схем, схем технологических процессов, моделей бизнес-процессов, планов зданий и этажей, трёхмерных карт и так далее. Платный.
• Bizagi Process Modeler — программа для моделирования процессов по нотации BPMN с возможностью совместной работы. Бесплатная.
• ARIS Express — программа для моделирования бизнес-процессов и оргструктуры с нотациями eEPC или BPMN. Бесплатная.
• Business Studio — система, в которой можно описать, оптимизировать и регламентировать бизнес-процессы предприятия. Платная.

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

В графических редакторах. Этот способ подойдёт для новичков, которые только знакомятся с моделированием бизнес-процессов. Проще всего взять обычный графический редактор — например, Microsoft Paint, Figma или Adobe Photoshop — и самостоятельно нарисовать интуитивно понятную схему процесса.

Также для изображения бизнес-процессов используют сервисы для создания ментальных карт. На мой взгляд, самые удачные из них — XMind, Diagrams и MindManager.

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

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

1. Задаём точки входа и выхода. Вход — первое событие в процессе, выход — результат. Так обозначают границы, чтобы потом наполнить процесс действиями. Нужно определить:

• Когда начинается процесс. В нашем примере это момент получения заявки от клиента. Если компания использует CRM, точкой входа будет попадание заявки в систему.
• Когда процесс закончится. Это момент успешной реализации сделки: клиент оплатил счёт, а продавец и логист организовали доставку.

Можно придумать несколько вариантов точек входа и выхода — для разных вариантов развития события.

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

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

Здесь лежит шаблон текстового описания процесса.

3. Выделяем основные этапы процесса. На основе описанного в предыдущем пункте процесса составляем блок-схему. В графическом редакторе рисуем каркас — основные этапы в пределах границ входа и выхода.

4. Добавляем детали. Наполняем каркас «мясом» — основными событиями по процессу и действиями исполнителя по алгоритму.

5. Задаём роли. В процессе может быть несколько исполнительских ролей. Их может выполнять один или несколько сотрудников. Обычно роли обезличены, без уточнения фамилий, — только должности.

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

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

Блок-схема готова. Если таких схем несколько, их процессы можно связать друг с другом на одной карте.

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

• Бизнес-процессы — любые операции внутри компании, которые помогают решать бизнес-задачи и зарабатывать. Моделирование бизнес-процессов — описание существующих в компании процессов и документирование требований к ним.
• В моделировании бизнес-процессов есть три основных подхода: функциональный, процессный и ментальный. Самый понятный подход для неподготовленного человека — процессный. Он даёт подробный алгоритм действий для сотрудников и глубокую детализацию операций.
• Моделировать процессы можно своими силами — если бизнес небольшой и несложный. Если в дальнейшем нужно оптимизировать процессы, лучше привлечь консультантов.
• Бизнес-процессы обычно описывают графически — в виде карт и интуитивно понятных схем. Так с ними проще работать.
• Смоделировать процесс можно самому: разобрать внутреннюю кухню компании, описать в тексте все алгоритмы и на основе этого построить схему в графическом редакторе.

Другие материалы Skillbox Media для менеджеров

Эффективный руководитель

Вы научитесь разрабатывать стратегию, ставить цели, создавать бизнес‑процессы и комфортный климат в команде. Найдёте точки роста в своей компании, сможете претендовать на повышение или масштабировать бизнес.

Узнать про курс

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

Начало начал

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

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

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

Список можно продолжить.

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

• Слепая вера топ-менеджмента компании в то, что внедрение новой программной системы (ERP, CRM, MRP и др.), которая (по заверению ее разработчиков) после внедрения и использования лучших практик, заложенных в референтных моделях, совершит чудо и бизнес сам начнет изменяться в положительную сторону…;
• Сложившийся факт, что описание бизнес-процессов многими рассматривается как универсальный инструмент решения проблем. Но на практике это далеко не так — описание может помочь в устранении проблемных зон, но не само по себе, а в рамках комплексного подхода, одним из компонентов которого может быть как раз формализация бизнес-процессов компании;
• Отсутствие бизнес-задачи. Компания работает, приносит некоторую прибыль. Да, при этом есть некоторые сложности в коммуникациях, но не более чем «рабочие моменты». Зачем менять сложившуюся практику выполнения работ, тем более, что описание бизнес-процессов потребует инвестиций в программное обеспечение, обучение специалистов, отвлечение сотрудников от рабочего процесса? Снижение эффективности компании и увеличение издержек неизбежно, если в цели проекта не входит увеличение бизнес-показателей.

Несколько слов об оптимизации

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

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

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

Про инструменты и методологии

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

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

• Выделение и описание набора отдельных бизнес-процессов компании — позволяет в сжатые сроки выявить причинно-следственные связи и временную последовательность выполнения действий, формализовать процессы и процедуры с акцентом на определение участников, исполнителей, начальных и конечных событий, последовательность действий, движение потоков объектов;
• Создание комплексной модели бизнес-процессов — позволяет создать комплексную непротиворечивую бизнес-модель компании с акцентом на создание описания системы, выделение и описание объектов управления.

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

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

Что можно получить в итоге

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

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

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

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

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

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

Лучшие практики

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

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

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

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

Этап первый — инициация проекта

Для реализации проекта формируется группа управления проектом, назначается куратор проекта, издается приказ о начале работ по описанию и оптимизации бизнес-процессов компании.

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

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

Этап второй — бизнес-задача

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

Диагностика может проводиться классическим способом (интервьюирование, стратегическая сессия, анализ показателей эффективности) или с применением онлайн-системы BIZDIAGNOSTICS. Система BIZDIAGNOSTICS — управленческий инструмент, который позволяет быстро и с минимальными ресурсными затратами провести внутренний аудит компании и получить достоверную и объективную информацию о качестве системы управления компании, идентифицировать проблемные зоны и получить рекомендации по их устранению. Результаты организационной диагностики являются основой для формулирования бизнес-задачи на проект.

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

Для исключения данной ситуации на этапе организации работ необходимо определить потребителя и формализовать его требования к разрабатываемой модели бизнес-процессов. Лучше, если таких потребителей будет несколько. Например:

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

Требования потребителей также позволяют установить набор документов, которые будут формироваться на основе разработанной бизнес-модели компании. Это позволит определить информацию, (например, данные, необходимые для проведения функционально-стоимостного анализа), которая должна быть собрана в рамках проекта.

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

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

Этап третий — программное обеспечение

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

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

Выбор программного продукта осуществлялся по следующим критериям:

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

После анализа рынка систем бизнес-моделирования было принято решение об использовании в нашем проекте системы Business Studio, наиболее полно соответствующей установленным критериям.

Этап четвертый — методология

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

Соглашение о моделировании бизнес-процессов определяет используемые нотации моделирования, количество уровней декомпозиции (уровней последовательного разделения бизнес-процесса на составляющие подпроцессы для получения более детального представления), взаимосвязь моделей процессов между собой, пакеты формируемой документации, устанавливает правила работы с объектами и справочниками в системе бизнес-моделирования, определяет параметры, подлежащие заполнению в системе. После ввода в действие данного документа группа управления проектом обязана контролировать его соблюдение всеми сотрудниками компании, вовлеченными в проект по описанию и оптимизации бизнес-процессов. Это обеспечит унификацию разрабатываемых моделей, сведет к минимуму временные затраты на устранение возникающих «ошибок», в т. ч. при работе в системе бизнес-моделирования, позволит получить пакет регламентирующей документации, наиболее соответствующей требованиям потребителей описания бизнес-процессов.

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

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

• Организационную структуру;
• Информационные системы, поддерживающие выполнение бизнес-процессов;
• Носители информации, используемые в процессах.

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

Этап пятый — бизнес-модель, рабочие группы

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

Рисунок 1. Схема выполнения основной фазы проекта по описанию и оптимизации бизнес-процессов

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

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

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

В рамках проекта владельцы бизнес-процессов отвечают за обеспечение выполнения работ по:

• Описанию и оптимизации своих бизнес-процессов;
• Выработке предложений по оптимизации бизнес-процессов;
• Анализу и согласованию предложений по оптимизации бизнес-процессов, сформированных участниками рабочих групп.

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

В рамках проекта на участников рабочих групп возлагаются обязанности по разработке модели бизнес-процессов, подготовке предложений по оптимизации бизнес-процессов, подготовке и проведению согласования разработанного пакета регламентирующей документации. Для эффективного выполнения работ по проекту рабочее время участников групп распределяется в соотношении 30/70 (проект/должностные обязанности) приказом руководителя компании.

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

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

Этап шестой — моделирование, оптимизация

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

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

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

Чтобы исключить дублирование информации в справочниках системы, на данном этапе в группах по описанию и оптимизации бизнес-процессов назначаются ответственные. Они осуществляют ввод данных в справочники на основании запросов участников группы.
Также в целях повышения эффективности работы групп, структурирования информации в базе данных системы, минимизации временных затрат на поиск информации в системе при вводе данных в справочники группы «Объекты деятельности» рекомендуется создавать структуру каталогов (например так, как это описано в статье «Организация работы с документами на платформе Business Studio»).

После завершения работ на 2-м уровне декомпозиции моделей бизнес-процессов верхнего уровня выполняется согласование границ подпроцессов и бизнес-процессов верхнего уровня по входам/ выходам, началу и результату процесса. Чтобы минимизировать временные затраты на согласование, рекомендуется проводить его в формате деловых игр, построенных по принципу докладов, в которых рабочие группы «моделируют» свой процесс, проговаривают его от момента начала до получения итогового результата, а остальные участники (владельцы процессов, представители группы управления проектом, куратор проекта, технические эксперты) вносят необходимые корректировки. При необходимости в ходе деловых игр участники игры вырабатывают совместные решения по спорным вопросам, возникающим в ходе описания бизнес-процессов. Как правило, в результате согласования происходит корректировка структуры процессов в бизнес-модели компании.

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

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

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

Этап седьмой — внедрение

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

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

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

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

Вместо заключения

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

Опубликовано по материалам:
Журнал E-xecutive.ru

Январь 2013 г.

Рекомендуемые материалы по тематике

Глоссарий

Проектирование системы управления здоровьем предприятия с использованием процессного подхода в Business Studio

Расчет себестоимости бизнес-процессов на примере проекта «Национального расчетного депозитария»

Конференция «Системная практика управления бизнес-процессами»: вопросы и ответы. Часть 2.

Документирование бизнес-процессов

Невозможно
управлять тем процессом, модель которого
отсутствует

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

• Повышение
  управляемости и прозрачности организации

• Повышение
  эффективности бизнес-процессов и
  сокращение затрат

• Оптимизация
  организационной структуры предприятия

• Внедрение систем
  управления предприятием

• •Сокращение
  операционных рисков и т.д.

При документировании
деятельности компании предлагается
подход к описанию, основанный на
взаимосвязанных графических моделях,
описывающих все аспекты деятельности
компании. Для этого используются
программные продукты семейства ARIS,
разработанные немецкой компанией IDS
Scheer AG.
Проверенная опытом методология описания
позволяет документировать процессы
компании, организационную структуру,
структуру данных, документов и многое
другое. Детальное описание процессов
включает взаимосвязь и последовательность
выполнения операций, исполнителей,
входящие и выходящие документы, время
выполнения операции, знания, полномочия,
контрольные точки и любые другие аспекты,
которые необходимы для анализа и
оптимизации процессов.

Что получают
клиенты в результате проекта по
документированию бизнес-процессов?

• Взаимоувязанное
  описание организационной структуры и
  процессов компании от самого верхнего
  уровня до уровня рабочих мест

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

• Документированные
  знания о процессах в виде понятных и
  наглядных моделей

• Базис для проведения
  других проектов с использованием
  существующих моделей

• Взаимоувязанное
  описание организационной структуры и
  процессов компании от самого верхнего
  уровня до уровня рабочих мест

• Широкие возможности
  для обучения новых сотрудников, а также
  распространения информации при
  изменениях в существующих процессах

10

Соседние файлы в папке Информационный мен

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #