Антон Тимохин

Руководитель проектов дирекции по развитию НПО «ЭЛСИБ»

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

Начало начал

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Постепенно описывая сначала наиболее проблемные, а потом и все бизнес-процессы, компания формирует и развивает этот актив:

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

Чем ценен этот актив:

  • Он обеспечивает единое понимание всеми терминов, содержания работы, требований и ожиданий, единство критериев оценки. Он становится основой для принятия справедливых управленческих решений. При этом единое понимание содержания работы позволяет предоставить сотрудникам больше инициативы, передать часть управленческих задач и разгрузить директора:
    • У директора отпадает необходимость держать все в голове, пинать и напоминать сотрудникам, чтобы все было сделано.
    • У начальников отделов появляется ясное понимание, что, в каком объеме и как они должны требовать от сотрудников.
    • У рядовых сотрудников возникает определенность, как именно выполнять работу . А при наличии еще и плана работы (целевых показателей) автоматически отпадает «необходимость» и желание ждать постоянных указаний когда и что делать. Пассивность становится невыгодной, а заменяемость сотрудника - более легкой.
  • Описание процесса можно (и нужно) использовать для управления процессами : планирования, мотивации, оценки результатов. Его можно использовать как инструмент оценки качества работы сотрудников и подразделений.
  • Его можно использовать для введения в работу новых сотрудников . Появляется технология быстрого обучения персонала и контроля его работы. Важно, что это обучение проводится так, как нужно компании, а не так, как это случайно произойдет при появлении новичка на работе. В противном случае сотрудник будет долго (и не вполне подконтрольно вам), случайным образом формировать свое видение работы и рабочие навыки.
  • Этот актив снижает требования к набираемому персоналу , поскольку отпадает необходимость искать на рынке труда гениев-телепатов , способных угадать, что вы хотите, и как здесь работают. Также отпадает необходимость искать суперменеджеров , с приходом которых все, наконец-то, заработает.
  • Описания процессов можно изменять: улучшать, исправлять, дополнять, избавлять от устаревшего и заменять это новым. Их можно использовать для устранения проблем в процессах . Когда мы видим проблему, сбой процесса, конфликт, по описанию легко найти место, где эта проблема возникает. После этого можно либо дополнить описание, либо заменить предписанные действия на другие с учетом полученного опыта.
  • Позволяет улавливать «тонкие моменты» бизнес-процессов: когда есть документ-описание, легко найти место, куда вставить ценное примечание, например: «проконтролировать получение выставленного коммерческого предложения по электронной почте», «если происходит то-то, то обратить внимание на (1) и (2)», «если клиент…, то предложить ему …». После определенного срока жизни и использования описания наполняются удивительно ценной и конкретной информацией . Если описания нет, все эти ценные идеи просто теряются за неимением места, куда их «пристроить».
  • Можно масштабировать . Если Вы открываете новый офис или филиал, бизнес-процессы просто переносятся и начинают вас радовать и там.

Из «минусов» отметим:

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

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

Введение

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

Функционально-ориентированные системы

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

Процессно-ориентированные системы

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

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

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

Рано или поздно, но руководство любого предприятия, хозяйственная деятельность которого требует привлечения труда многих десятков, а то и сотен сотрудников, приходит к мысли о необходимости создания комплексной автоматизированной системы. Дальше следует один из трех вариантов:
  • осуществляется поиск "подходящей" программной системы, покупка некоторых модулей такой системы и процесс их внедрения;
  • осуществляется поиск "подходящей" компании, занимающейся разработкой программных систем, заключается с ней договор и начинается процесс разработки и внедрения системы "под заказчика";
  • осуществляется поиск специалистов в области программирования, прием их на работу и создание ими в качестве сотрудников "своей" информационной системы.
Конечно, имеют место прецеденты компоновки таких вариантов. Однако, чаще всего, поставленная задача, все-таки, не решается. Это есть следствие объективно существующих проблем процесса создания комплексной автоматизированной системы, которые мы попытаемся раскрыть и показать пути их решения в данной статье.

Для начала сформулируем простые вопросы и дадим на них ответы.

КОМУ НУЖНА КОМПЛЕКСНАЯ АВТОМАТИЗАЦИЯ УПРАВЛЕНИЕМ ПРЕДПРИЯТИЯ?

Комплексная автоматизация управлением предприятия нужна лицу, заинтересованному в УВЕЛИЧЕНИИ ПРИБЫЛИ предприятия за счет повышения эффективности принимаемых управленческих решений. То есть, этим лицом может быть либо СОВЛАДЕЛЕЦ предприятия, либо МЕНЕДЖЕР ВЫСШЕГО ЗВЕНА УПРАВЛЕНИЯ, заработок которого напрямую зависит от прибыльности предприятия. В дальнейшем будем называть такое лицо Руководителем (не нужно путать с руководителем среднего и нижнего звена управления, заинтересованность которого носит, в основном, морально-этический характер).

ЧТО НУЖНО ПОЛУЧАТЬ ОТ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ РУКОДИТЕЛЮ?

Для повышения эффективности принимаемых управленческих решений Руководитель должен, в самом простом варианте:

  • планировать поступление денег;
  • планировать производственную деятельность;
  • планировать расходы.
То есть, лицо, заинтересованное в увеличении прибыли, ощущает необходимость в автоматизации УПРАВЛЕНЧЕСКОГО УЧЕТА. При этом, чем больше предприятие, тем выше требования к степени автоматизации управленческого учета (бюджетирование по центрам ответственности, прогнозирование и оценка эффективности расходов по направлениям деятельности, построение системы сбалансированных показателей работы предприятия и расчет их количественного выражения и т.д.).

КАКОЕ УСЛОВИЕ ЯВЛЯЕТСЯ НЕОБХОДИМЫМ ДЛЯ АВТОМАТИЗАЦИИ УПРАВЛЕНЧЕСКОГО УЧЕТА?

Система управленческого учета работает на данных, которые поступают с мест выполнения хозяйственных операций или, другими словами, на данных ОПЕРАТИВНОГО УЧЕТА. Для эффективного управленческого учета данные оперативного учета должны, как минимум:

  • поступать своевременно;
  • интерпретироваться в форме, позволяющей проверить их достоверность;
  • храниться в форме, позволяющей составлять аналитические выборки за предыдущие периоды.
То есть, необходимым условием автоматизации управленческого учета является грамотная АВТОМАТИЗАЦИЯ ОПЕРАТИВНОГО УЧЕТА.

КТО ВЛАДЕЕТ ЗНАНИЯМИ ОБ ОПЕРАТИВНОМ УЧЕТЕ НА ПРЕДПРИЯТИИ?

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

МНОГО ЛИ БИЗНЕС-ПРОЦЕССОВ В КОНТУРЕ ОПЕРАТИВНОГО УЧЕТА ПРЕДПРИЯТИЯ?

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

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

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

Для решения указанных проблем необходимо провести ОБСЛЕДОВАНИЕ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ .

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

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

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


Рис.1. Вариант дерева функций

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

Рис.2. Фрагмент структуры бизнес-процессов

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

Рис.3. Фрагмент последовательности бизнес-процессов


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

И, напоследок, еще немного "о грустном" - о рисках. Предположим, что Вы - Руководитель, осознали важность проблемы, нашли консультантов, финансировали проведение обследования, получили отчет, соответствующий поставленной задаче. А где гарантии того, что полученный результат соответствует действительности, то есть, в описании учтены все бизнес-процессы и их описание позволяет однозначно интерпретировать суть деятельности? Даже если это не так, Вы, конечно, можете утвердить полученные должностные инструкции, можете провести оптимизацию полученных бизнес-процессов и обязать работать организацию по новому. Это, скорее всего, приведет к повышению эффективности - ведь, Вы все равно "продвинулись" в налаживании регулярного менеджмента. Люди поймут поставленные задачи, ведь до этого они работали в условиях устных договоренностей о правилах работы.
Однако, при создании автоматизированной системы по такому описанию могут возникнуть сложности. Ведь, компьютер - не человек. Любая "недоговоренность", неточность или слабо формализованное описание будет "растолковано" компьютеру программистом, и качество такого толкования будет контролироваться не Вами.
Кроме этого, есть еще одна проблема - жизнь меняется, меняется и Ваш бизнес. Если Вы получили результат обследования в виде "кипы бумаг", то оно рискует со временем превратиться в фотографию из старого альбома, которую можно показывать только гадалке, а врачу вместо себя не представишь. Конечно, сложность организации предприятия нельзя сравнивать со сложностью устройства человеческого организма, однако и здесь не все так просто. Для примера предположим, что количества бизнес-процессов документов и штатных клеток измеряются десятками. Уже только для такого небольшого числа количество их взаимосвязей может достигать десятков тысяч. То есть, для того чтобы результат формализации бизнес-процессов "поддавался" анализу и модификации все данные обследования должны заноситься при помощи специальной программы в базу данных, а формы анализа и отчетные формы генерироваться этой программой. Такие программы существуют, например, BPWin.

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

  1. Описание деятельности любого подразделения со стороны заказчика должен утверждать его руководитель, который предварительно предупреждается о персональной ответственности за "свою часть проекта".
  2. Со стороны исполнителя нужно потребовать краткое предпроектное обследование, результатом которого должны стать предложения о применении возможных типовых решений автоматизации и определение приблизительной суммы проекта по внедрению программного обеспечения.
  3. Исполнитель должен обладать программной системой, в базе данных которой можно хранить все сложные взаимосвязи между функциями, бизнес-процессами, документами, элементами штатного расписания и т.д. Получив этот инструмент вместе с результатами обследования, Вы будете иметь возможность самостоятельно вести регулярную работу по формализации и анализу изменяющихся бизнес-процессов Вашей хозяйственной деятельности.
Ну, что ж, если Вас убедила наша статься, то пора начинать. Чем больше будет усложняться Ваш бизнес, тем сложнее и дороже будет провести работу по формализации бизнес-процессов Вашего предприятия. Путь труден, но результат того стоит! В последствии, Вы будете не наблюдать за автоматизацией, а управлять ею. Вы будете готовы к посещению "светлого супермаркета комплексной автоматизации", а не мерять "тришкины кафтаны", которые время от времени Вам будут приносить.

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

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

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

Прежде чем начать

Суть идеи формализации процесса по методу SIPOC заключается в том, что мы:

  1. Особое внимание уделяем «масштабу» процесса или, как я еще это называю «высоте точки обзора».
  2. «Разматываем» процесс, как клубок, начиная от потребителей конечного результата процесса, заканчивая его инициатором. Не наоборот!
  3. Особое внимание уделяем «стыкам» этапов процесса.
  4. Особое внимание уделяем читабельности карты процесса.

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

Что такое SIPOC

Итак, SIPOC - это акроним от английских слов Supplier (поставщик), Input (вход), Process (процесс), Output (выход), Customer (заказчик) . Эта модель позволяет описывать процессы с точки зрения последовательности действий, движения информации/товаров/услуг между этапами процесса, а так же взаимоотношений, возникающих в результате процесса между различными участниками. Модель позволяет проследить бизнес-логику процесса, с высоким, но управляемым уровнем абстракции.

Сразу же наглядный пример описания процесса. На нем можно посмотреть основы.

(S) ООО «Рога и копыта» -> (I) Требования к информационной системе -> (P) Формализация требований -> (O) Техническое задание -> (C) 1С:Франчайзи

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

Визуально отображаем:

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

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

I - Input (вход) . В нашем примере это требования к информационной системе. Эти требования могут быть в виде электронного письма, описаны устно на переговорах или запротоколированы в предыдущих интервью. Здесь описывается все, что необходимо для процесса. К этому описанию применяются требования (requirements), поэтому акроним SIPOC можно увидеть в некоторых источниках, как SIRPORC. Эти требования, как видно из акронима применяются как к входу, так и к выходу.

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

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

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

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

O - Output (выход) . Здесь мы описываем то, что должно было получиться из предыдущего этапа. В нашем примере это техническое задание. К техническому заданию как к «выходу» из процесса предъявляются свои требования, которые формулируются заказчиком (customer"ом). Например, 1С:Франчайзи имеет стандарт оформления технического задания. Требование «техническое задание должно соответствовать стандарту» описывается нами в приложении. Но, чтобы закрепить визуально, дорисуем:

С - Customer (заказчик) . В нашем примере это 1С:Франчайзи, которое получает техническое задание в результате проведенной формализации требований.

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

Тонкости

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

Если у нас несколько поставщиков «входящих» объектов или несколько самих «входящих» объектов, то их можно отобразить вот так:

То же самое касается и «исходящих» объектов и заказчиков:

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

У нас уровень детализации находится эмпирическим путем индивидуально с каждым заказчиком.

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

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

А как же цикличные процессы? А как же параллельные процессы? А как же ветвления?

Отвечу на все вопросы по порядку.

Циклические процессы всегда рассматриваются с «высоты», которая позволяет циклический процесс определить, как отдельный единичный этап. Например, в последнем рисунке, мы видим, что протоколы передаются ИТ-директору на согласование. Мы знаем, что согласование может быть затянуто по времени, т.к. кто-то что-то забыл или наоборот вспомнил и протоколы будут ходить туда-сюда пока не будет получен «выход» процесса - подписанные протоколы. Если циклический процесс содержит принципиально важные блоки для автоматизации, то одна итерация такого цикла описывается отдельной картой SIPOC.

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

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

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

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

Есть разные уровни управления и соответствующие им разные уровни масштаба.

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

Нельзя одновременно видеть все и в деталях. Должны быть разные карты для разных точек обзора. Если соблюдать это требование, то практически все процессы, соответствующие детализацией «высоте» обзора, можно описать моделью SIPOC. Из этого я в свое время сделал такой вывод: если процесс описывается методом SIPOC , то «высота» обзора процесса соответствует уровню детализации . Возможно, это покажется спорным утверждением. Надеюсь на то, что если я не прав, то более компетентные товарищи меня поправят в комментариях. Я всегда готов к совершенствованию. Но пока опытным путем не удалось столкнуться с обратным.

Как рисовать карту процесса?

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

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

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

Если процесс мы читаем слева направо сверху вниз, то рисовать процесс мы начинаем справа налево снизу вверх! То есть:

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

Process: Потом мы описываем сам процесс, как последовательность действий и ответственного за исполнение этого этапа.

Input: Описываем, что необходимо для выполнения этого этапа и требования к этому.

Supplier: Описываем, кто будет поставлять процессу необходимые компоненты.

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

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

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

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

Не явные бонусы

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

Сами карты SIPOC легко читаемы и легко воспринимаются ЛПР. Это позволяет создавать «продающие» обследования. Часто встречали на средних и крупных проектах, что ЛПР, не умел читать нотации серии IDEFх. В этом случае мы переводили их на более понятный уровень, если это было возможно, т.к. иногда был откровенный бред. Если мы работаем с ИТ-отделом, то дальнейшее описания в проектных документах мы согласуем с ними, если они не высказываются «против», то мы продолжаем придерживаться нотации SIPOC. Но бывает, что требуют другие нотации, как правило, IDEF0 и/или IDEF1, это бывает очень редко. Пока, что весомого аргумента в пользу этих нотаций, кроме того, что это привычный стандарт, а SIPOC они в глаза не видели, я не услышал. За исключением проекта, где требовалось автоматизировать процесс маршрутизации клиента по отделам в зависимости от того, что он закупает, в каком объеме и пр., там было очень много ветвлений. Фактически это автоматизация сложного оперативного управления, картам SIPOC там не место.

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

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

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

Пока готовил этот материал, решил поискать, что же есть в рунете на эту тему, довольно не много. Но это позволит вам расширить представление по этой теме:

в яндекс.картинках лежит куча примеров карт SIPOC

6 сигм, бережливое производство…

… и пожалуй все.

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

П.С. Как я уже писал, я решил вести рассылку. В данный момент рассылка находится в спящем режиме. В рассылке еще не много, но уже и не мало подписчиков. Сейчас уже 143 человека и еще 9 не подтвердили подписку (проверяйте папку «Спам», иногда письмо подтверждения попадает туда). Это всего за 15 дней существования рассылки, что меня сильно вдохновляет. В ближайшее время я буду проводить небольшой бесплатный онлайн тренинг. Я не профессиональный тренер и это скорее хобби, но думаю, что он будет интересен вольным стрелкам и руководителям организаций, занимающихся автоматизацией на базе 1с. В данный момент готовятся все технические элементы тренинга. Если вам понравился этот материал, то подписаться на рассылку можно . Я и дальше планирую публиковаться на ИС, в рассылку попадут материалы, которые не подходят ИС по формату (например, как тут провести тренинг я так и не придумал).