Ликбез для руководителей: моделирование бизнес-процессов на раз-два-три
В условиях современной , в целях повышения операционной эффективности все больше и больше компаний принимает решение о реализации проектов по описанию и оптимизации своих . Тем не менее, такие проекты, как и любая другая деятельность по совершенствованию, могут привести как к положительным, так и к отрицательным результатам. Поэтому, надеюсь, данная статья станет подспорьем для руководителей, которые начинают улучшение деятельности своих компаний, в том, как обойти подводные камни возможных ошибок на этапах работ по описанию, оптимизации и дальнейшем внедрении новых версий .
Начало начал
Повторюсь, что результат реализации проекта по описанию, оптимизации и внедрению новых версий может быть как положительным, так и отрицательным, с финансовыми потерями для компании в случае неправильной организации работ. Почему начинаются такие проекты?
Можно выделить ряд первопричин, по которым в результате диагностики руководители компаний принимают решение о старте работ по формализации и оптимизации :
- Выполнение ненужных (не добавляющих ценность) работ, большая вариабельность циклов работ;
- Отсутствие стандартизации и унификации , произвольная структура , отсутствие документации, регламентирующей их выполнение;
- Неэффективная архитектура информационных потоков (сбор, анализ, хранение данных), недостаточный уровень автоматизации;
- Избыточное число подразделений и департаментов, дублирование функций, неэффективное взаимодействие между ними;
- Размытие зон ответственности, отсутствие ответственного за и его результат в целом;
- Концентрация всех полномочий на высшем уровне иерархии, отсутствие практики делегирования полномочий;
- Излишние трудозатраты на деятельность, существенные потери времени на согласованиях;
- Мистема оценки труда не мотивирует сотрудников к снижению затрат и повышению качества, мотивационные показатели подконтрольны мотивируемому.
Список можно продолжить.
Получив по итогам диагностики сигнал о том, что в компании существуют такого рода проблемы, руководитель может сделать вывод — «нам нужно описать и оптимизировать наши процессы, и это поможет нам избавиться от всех проблем:)». При этом четкой задачи и критериев оптимизации не формулируется. Такой подход к постановке задачи на проект сам по себе имеет несколько проблемных зон, которые неизбежно приведут к негативным последствиям, а вероятность получения положительного результата минимальна:
- Слепая вера компании в то, что внедрение новой программной системы (ERP, CRM, MRP и др.), которая (по заверению ее разработчиков) после внедрения и использования лучших практик, заложенных в референтных моделях, совершит чудо и бизнес сам начнет изменяться в положительную сторону…;
- Сложившийся факт, что описание многими рассматривается как универсальный инструмент решения проблем. Но на практике это далеко не так — описание может помочь в устранении проблемных зон, но не само по себе, а в рамках комплексного подхода, одним из компонентов которого может быть как раз формализация компании;
- Отсутствие . Компания работает, приносит некоторую прибыль. Да, при этом есть некоторые сложности в коммуникациях, но не более чем «рабочие моменты». Зачем менять сложившуюся практику выполнения работ, тем более, что описание потребует инвестиций в программное обеспечение, обучение специалистов, отвлечение сотрудников от рабочего процесса? Снижение эффективности компании и увеличение издержек неизбежно, если в цели проекта не входит увеличение .
Несколько слов об оптимизации
Описание в большинстве случаев воспринимается как «лекарство от всех болезней», но мало кто из руководителей задумывается о том, зачем необходимо описывать существующие ? Ведь круг проблем, которые могут быть решены простой формализацией процессов ограничен, а в остальных случаях требуется оптимизация компании.
Как правило, к оптимизации относятся как к некоторому абстрактному понятию, не несущему никакой другой нагрузки, кроме эмоциональной: «теперь мы решим все проблемы», при этом, не уделяя никакого внимания критериям оптимизации — какой процесс, насколько улучшить и в каких допустимых пределах.
Если с определением направлений улучшений обычно затруднений не возникает (например, «необходимо сократить время выполнения процесса согласования заявки заказчика»), то с определением и оцифровкой показателей улучшений возникают проблемы. Во многих компаниях не используются системы сбалансированных показателей, и определить «насколько улучшить» становится невозможным, показатели, характеризующие функционирование конкретного процесса, не определены и не рассчитываются. Таким образом, измерение улучшений зачастую происходит субъективно, «по ощущениям».
Отдельный момент — установление допустимых пределов для изменений. Не секрет, что руководитель или собственник компании на этапе начала работ по совершенствованию устанавливает ряд ограничений и запретов, сводя своими действиями оптимизацию на уровень косметических изменений, неспособных кардинально улучшить в сложившейся ситуации.
Про инструменты и методологии
Как правило, вопросу выбора инструментов и методологий при инициации работ по формализации уделяется минимум внимания. Подразумевается, что нет большой разницы в том, какие системы и какие методологии использовать. Тем не менее, определяющим фактором в вопросе выбора программного обеспечения и методологии должны быть цели, которые планируется достигнуть при реализации проекта по описанию и оптимизации .
В зависимости от поставленных целей, фазы развития организации и состояния системы управления можно выделить два подхода к формированию компании:
- Выделение и описание набора отдельных компании — позволяет в сжатые сроки выявить связи и временную последовательность выполнения действий, формализовать процессы и процедуры с акцентом на определение участников, исполнителей, начальных и конечных событий, последовательность действий, движение потоков объектов;
- Создание комплексной модели — позволяет создать комплексную непротиворечивую компании с акцентом на создание описания системы, выделение и описание объектов управления.
Данные подходы не являются взаимоисключающими, опыт показывает, что возможны ситуации, когда необходимо решение задач как описания системы в целом, так и описания отдельных (локальных) . В данном случае следует двигаться от общего к частному: сначала создавать модель системы в целом и только потом, используя ее как базис, формировать модели отдельных .
Вопрос выбора программного обеспечения обычно относится к узкоспециальным и часто передается для решения специалистам с минимальным участием руководителя компании. Тем не менее, не стоит забывать, что методики и инструменты описания специализированы и не подходят для решения задач, для которых они не предназначены. Попытка использования для формирования комплексной модели выбранной техническими специалистами системы, предназначенной для описания алгоритмов и взаимосвязей операционного уровня, с большой долей вероятности потребует дополнительных финансовых затрат на доработку системы, сделает выполнение задачи сложным, длительным по срокам или просто невозможным.
Что можно получить в итоге
В большинстве случаев руководитель компании, инициируя проект по описанию , не учитывает все то, что было описано выше, а сама идея реализации подобного проекта получена им извне.
В сложившейся ситуации формулировка задачи на проект сводится к «нам необходимо в сжатые сроки описать нашей компании». Если попытаться определить данную необходимость и задать несколько уточняющих вопросов, то ответ скорее будет логически не связанным с поставленной задачей.
Следующим шагом в компании создается структурное подразделение, в штат которого входят аналитики, или принимается решение о привлечении сторонних консультантов для реализации проекта. Возможные варианты дальнейшего развития событий следующие:
- Исполнитель (аналитики компании или внешние консультанты), не задавая лишних вопросов, добросовестно приступают к выполнению работ по проекту. При этом, четких указаний, что описывать, на этапе начала работ не было, описываются либо все процессы подряд, либо те, которые определяет руководитель компании. Дни проходят один за другим, проект, казалось бы, успешно реализуется, вот только полученный результат не оправдывает вложенных средств. описаны так, как это действительно происходит в компании, полученные модели сложные, запутанные и зачастую не пригодны для дальнейшего использования. Несмотря на это исполнитель предпринимает попытку оптимизации процессов, но в силу недостаточного опыта работы в компании, используя мнение узкого круга лиц, не принимая во внимание взаимосвязи между процессами, по факту не улучшает ничего. В результате потрачено значительное количество времени и ресурсов, текущие проблемы бизнеса не решены, а у руководителя появляется негативный опыт, не позволяющий ему вернуться к подобной работе в дальнейшем;
- Исполнитель начинает задавать вопросы, уточняя, зачем необходимо описание , какой результат планируется достигнуть, какие критерии оптимизации установлены. На этом этапе может быть получен серьезный негатив от руководства компании, потому что, , ответов просто нет, а , задача описания процессов формальная, не подкрепленная логической цепочкой выводов и подзадач. Выясняется ряд «особенностей» бизнеса, которые неприятны руководителю компании и на которые раньше он «закрывал глаза»:
- Вдруг выясняется, что описание процессов «как есть» невозможно, просто потому, что их в компании нет — деятельность выполняется на основании опыта сотрудников, решения принимаются по ситуации, и даже регулярные процессы выполняются не так, как закреплено в регламентах, а так, как удобно исполнителям;
- Бизнес подвержен внешним или внутренним рискам, отсутствуют целевые показатели, система мотивации не способствует повышению качества продукции/услуг, учет затрат ведется не в полном объеме или отсутствует;
- При описании процессов выявляется необходимость проведения существенных изменений в модели бизнеса.
Не стоит забывать про то, что если процессы в ходе описания оптимизированы, то после завершения проекта по описанию и оптимизации необходим еще один проект — внедрение новых версий в практику применения персоналом компании. Вот только этот проект потребует гораздо больше усилий для того, чтобы изменить сложившиеся годами устои на новые, необычные, разработанные без участия большинства сотрудников.
Таким образом, описание и оптимизация — задача, требующая, кроме опыта и знаний аналитиков, личной заинтересованности, готовности к изменениям, четкого понимания необходимости проекта, а также способов достижения установленных целей со стороны руководителя компании. В противном случае, столкнувшись с описанными выше проблемами и вопросами, когда будет необходимо внести изменения в действующий бизнес — проект закончится, не успев начаться.
Лучшие практики
Задачи описания сегодня актуальны для многих крупных российских компаний, независимо от отраслевой принадлежности. В большинстве случаев для их решения формируются аналитические подразделения, которые создают модели действующего бизнеса, отражающие особенности функционирования внутренних .
Формирование полноценной компании — высокотрудоемкая задача, требующая внимательной проработки ключевых этапов до начала работ. , сетевой график, отчетность и регламентация, глубина и методология описания — базовые вопросы, которые должны быть решены до начала работ, иначе полученный результат не оправдает ожидания.
Настоящий раздел содержит рекомендации по подготовке и реализации проекта по описанию и оптимизации . Раздел подготовлен на основании личного опыта автора статьи по итогам реализации проекта на предприятии энергетического машиностроения, а также с учетом лучших практик других компаний, примененных в ходе выполнения работ.
Допущения: проект реализован силами внутреннего аналитического подразделения компании, специалисты подразделения имеют опыт реализации проектов в области организационного развития, на момент начала работ в компании функционирует система менеджмента качества, в качестве системы используется система Business Studio.
Этап первый — инициация проекта
Для реализации проекта формируется группа управления проектом, назначается куратор проекта, издается приказ о начале работ по описанию и оптимизации компании.
Куратором проекта рекомендуется назначать должностное лицо из числа заместителей генерального директора, руководителей департаментов, реализующих функции, связанные с развитием компании. Куратор должен быть наделен всеми необходимыми полномочиями для решения вопросов, связанных с выполнением работ по проекту.
Группа управления проектом включает в себя , которые образуют в дальнейшем Центр компетенции по компании. Если в компании внедрена и функционирует система менеджмента качества или интегрированная система менеджмента, специалисты подразделения, реализующего данные функции, также должны быть включены в группу управления проектом. Это позволит использовать накопленную базу знаний по процессам и проблемным зонам, интегрировать функции по описанию, оптимизации и внутреннему аудиту . Также в состав групп включаются технические эксперты по различным направлениям деятельности для получения экспертных мнений и оперативного решения спорных вопросов по функционированию отдельных процессов
Этап второй —
На начальном этапе работ по описанию и оптимизации группой управления проектом должна быть проведена организационная диагностика. Цель — определение недостатков в работе компании, проблемных зон и причин неэффективности ; повышение качества планирования работ по проекту.
Диагностика может проводиться классическим способом (интервьюирование, стратегическая сессия, анализ показателей эффективности) или с применением BIZDIAGNOSTICS. Система BIZDIAGNOSTICS — управленческий инструмент, который позволяет быстро и с минимальными ресурсными затратами провести внутренний аудит компании и получить достоверную и объективную информацию о качестве системы управления компании, идентифицировать проблемные зоны и получить рекомендации по их устранению. Результаты организационной диагностики являются основой для формулирования на проект.
Типовой ошибкой является описание ради самого описания. Подобный подход приведет к негативной реакции бизнеса, который не получит значимых результатов после работы аналитиков, разработанная модель сама по себе значимым результатом не является. Это подрывает веру руководителя и компании в процессный подход в целом и процессное управление в частности, с последующими организационными решениями в части «оптимизации» численности внутренних аналитиков или полной остановки работ в данном направлении.
Для исключения данной ситуации на этапе организации работ необходимо определить потребителя и формализовать его требования к разрабатываемой модели . Лучше, если таких потребителей будет несколько. Например:
- Структурные подразделения компании, заинтересованные в регламентации и оптимизации своих ;
- Подразделения, реализующие функции по поддержанию функционирования и развития систем менеджмента (системы менеджмента качества, интегрированной системы менеджмента), без процессного управления эффективное функционирование систем затруднительно;
- , для которых модель процессов упрощает определение алгоритмов работы и формализацию требований к внедряемым информационным системам.
Требования потребителей также позволяют установить набор документов, которые будут формироваться на основе разработанной компании. Это позволит определить информацию, (например, данные, необходимые для проведения анализа), которая должна быть собрана в рамках проекта.
Формализация требований потребителей в виде технического задания позволит исключить большую часть «лишней» работы в проекте, выбрать программный продукт, наилучшим образом соответствующий поставленной задаче, а также получить значимый для бизнеса результат с меньшими временными, финансовыми и трудовыми затратами.
На основании результатов организационной диагностики и технического задания группой управления проектом после проведения сессии с руководителем и компании сформулирована на проект — определены функциональные области для улучшений, критерии оптимизации (что и насколько улучшить), формализованы требования потребителей разрабатываемой модели компании. Также в должны быть однозначно определены четкие пределы для изменений (какие изменения бизнеса приемлемы, какие недопустимы). После утверждения разрабатывается сетевой график реализации проекта.
Этап третий — программное обеспечение
Следующим важным шагом является выбор программного обеспечения, необходимого для успешной реализации проекта — системы .
Система — программный продукт для создания и анализа компании, проектирования новых , разработки и поддержания в актуальном состоянии пакета регламентирующей документации. Система играет большую роль в проекте по описанию , она обеспечивает единое информационное поле для совместной работы аналитиков, предоставляя им необходимый инструментарий для описания, анализа и оптимизации .
Выбор программного продукта осуществлялся по следующим критериям:
- Возможность выполнения полного комплекса работ по организационному проектированию;
- Автоматизированная система сбора и анализа результатов измерений эффективности компании;
- Автоматическое формирование пакета регламентирующей документации;
- Использование популярных нотаций моделирования , дружелюбный к пользователю интерфейс, не требующий проведения специализированного обучения пользователей;
- Поддержка системы менеджмента качества;
- Возможность гибкой настройки системы «под себя» (возможность ввода пользовательских параметров и справочников).
После анализа рынка систем было принято решение об использовании в нашем проекте системы Business Studio, наиболее полно соответствующей установленным критериям.
Этап четвертый — методология
Проект по описанию в крупной компании приводит к разработке большого количества моделей процессов. Если представить, что все диаграммы нарисованы , то полученный результат не будет представлять никакой практической ценности для компании. Именно поэтому важно определить четкие правила моделирования в компании. Для этого разрабатывается Соглашение о моделировании — документ, определяющий методологию описания , порядок взаимодействия участников процесса описания и оптимизации , а также механизмы ввода в действие формируемого пакета регламентирующей документации, поддержания актуального состояния разработанных моделей .
Соглашение о моделировании определяет используемые нотации моделирования, количество уровней декомпозиции (уровней последовательного разделения на составляющие подпроцессы для получения более детального представления), взаимосвязь моделей процессов между собой, пакеты формируемой документации, устанавливает правила работы с объектами и справочниками в системе , определяет параметры, подлежащие заполнению в системе. После ввода в действие данного документа группа управления проектом обязана контролировать его соблюдение всеми сотрудниками компании, вовлеченными в проект по описанию и оптимизации . Это обеспечит унификацию разрабатываемых моделей, сведет к минимуму временные затраты на устранение возникающих «ошибок», при работе в системе , позволит получить пакет регламентирующей документации, наиболее соответствующей требованиям потребителей описания .
При определении уровней декомпозиции следует акцентировать внимание на требованиях потребителей описания , их обоснованности, необходимости и достаточности детализации при описании. Очень часто модели декомпозируются до уровня отдельных действий сотрудников там, где это нецелесообразно. Это приводит к увеличению количества разрабатываемых моделей, значительному росту трудоемкости без увеличения ценности моделей для развития бизнеса, излишняя детализация не всегда дает информацию для оптимизации процессов.
Практика показывает, что каждый новый уровень декомпозиции увеличивает объем моделей на порядок. Поэтому, если необходимо оптимизировать процессы и определить зоны ответственности между структурными подразделениями компании, следует ограничиться детализацией до уровня подразделений. Выход на уровень элементарных действий применяется, только если модель разрабатывается для целей автоматизации или регламентации деятельности отдельных исполнителей.
Начиная проект, вместе с определением требований его потребителей, необходимо установить, какие элементы окружения необходимо описать. Среди предметных областей, подлежащих формализации, следует выделить:- Организационную структуру;
- Информационные системы, поддерживающие выполнение ;
- Носители информации, используемые в процессах.
В ряде случаев формируемую модель могут дополнять показатели эффективности, требования к информационным системам Таким образом, , кроме собственно описания процессов, интегрирует в себе различные предметные области, что значительно повышает ее практическую ценность для дальнейшего анализа и оптимизации.
Этап пятый — , рабочие группы
Дальнейшая схема выполнения проекта подробно представлена на рисунке 1.
Рисунок 1. Схема выполнения основной фазы проекта по описанию и оптимизации
Итак, следующий шаг — разработка модели верхнего уровня. Она позволяет получить единый взгляд на устройство бизнеса. Формирование модели лучше проводить с акцентом на создание ценности, используя принципы определения и построения цепочек создания ценности. Разработка модели проводится в формате стратегической сессии или деловой игры с участием руководителя и компании. Для разработки модели верхнего уровня наиболее удобно использовать нотацию IDEF0.
При разработке модели рекомендуется использовать информацию по структуре компаний аналогичной отрасли, отраслевые референтные модели. Готовая модель должна системно показать верхнего уровня компании, а также наиболее важные взаимосвязи между ними, необходимые для понимания функционирования бизнеса.
На основании утвержденной происходит назначение владельцев (с ориентацией на действующую организационную структуру компании), а также формирование рабочих групп по описанию и оптимизации по каждому из верхнего уровня. В целях регламентации деятельности владельцев , определения полномочий и разграничения ответственности разрабатывается Должностная инструкция владельца . Цель — установление ответственности за результат процесса, определение должностных обязанностей, а также полномочий для распоряжения ресурсами, необходимыми для выполнения процесса.
В рамках проекта владельцы отвечают за обеспечение выполнения работ по:
- Описанию и оптимизации своих ;
- Выработке предложений по оптимизации ;
- Анализу и согласованию предложений по оптимизации , сформированных участниками рабочих групп.
Группой управления проектом совместно с владельцами проводится формирование рабочих групп по описанию верхнего уровня. В состав групп включаются руководители и специалисты структурных подразделений компании, имеющие, в силу своего опыта работы в компании или состава должностных обязанностей, достаточное представление о , подлежащем описанию и оптимизации. Рабочие группы возглавляет руководитель рабочей группы. Он назначается из числа руководителей структурных подразделений, принимающих участие в выполнении соответствующего . Численность рабочей группы варьируется в зависимости от «объема» и сложности конкретного .
В рамках проекта на участников рабочих групп возлагаются обязанности по разработке модели , подготовке предложений по оптимизации , подготовке и проведению согласования разработанного пакета регламентирующей документации. Для эффективного выполнения работ по проекту рабочее время участников групп распределяется в соотношении 30/70 (проект/должностные обязанности) приказом руководителя компании.
После выполнения всех вышеперечисленных подготовительных мероприятий и установки системы на рабочие станции пользователей проводится обучение участников рабочих групп и, при необходимости, руководителей среднего и высшего звена компании методикам и принципам описания и оптимизации . Обучение рекомендуется разделять на теоретическую (для всех) и практическую (для участников рабочих групп) части. Большее время необходимо уделять практике описания и работе с системой , отрабатывая на простых примерах навыки работы и демонстрируя «классические» ошибки.
Обучение может проводиться как сторонней организацией, так и членами группы управления проектами при наличии достаточных компетенций и опыта работы с используемой системой .
Этап шестой — моделирование, оптимизация
После обучения рабочими группами проводится анализ деятельности структурных подразделений, идентификация и структурирование , которые в них выполняются. Информация вносится в дерево процессов системы с указанием наименования процесса, руководителя, ответственного за его выполнение, участников, инициирующих/завершающих событий и результатов.
После идентификации процессов в формате деловой игры проводится перекрестное согласование процессов, представляющих собой уровень декомпозиции верхнего уровня, при необходимости производится доработка полученной структуры.
Следующим шагом является установление взаимосвязей между подпроцессами уровня декомпозиции через входы и выходы, наполнение модели информационными потоками и потоками объектов. Переход на уровень декомпозиции, введение информации в систему и согласование структуры подпроцессов проводится аналогично.
Чтобы исключить дублирование информации в справочниках системы, на данном этапе в группах по описанию и оптимизации назначаются ответственные. Они осуществляют ввод данных в справочники на основании запросов участников группы.
Также в целях повышения эффективности работы групп, структурирования информации в базе данных системы, минимизации временных затрат на поиск информации в системе при вводе данных в справочники группы «Объекты деятельности» рекомендуется создавать структуру каталогов (например так, как это описано в статье «Организация работы с документами на платформе Business Studio»).После завершения работ на уровне декомпозиции моделей верхнего уровня выполняется согласование границ подпроцессов и верхнего уровня по входам/ выходам, началу и результату процесса. Чтобы минимизировать временные затраты на согласование, рекомендуется проводить его в формате деловых игр, построенных по принципу докладов, в которых рабочие группы «моделируют» свой процесс, проговаривают его от момента начала до получения итогового результата, а остальные участники (владельцы процессов, представители группы управления проектом, куратор проекта, технические эксперты) вносят необходимые корректировки. При необходимости в ходе деловых игр участники игры вырабатывают совместные решения по спорным вопросам, возникающим в ходе описания . Как правило, в результате согласования происходит корректировка структуры процессов в компании.
Полученная первая версия компании подлежит дальнейшей декомпозиции — разрабатываются модели , уровня. Согласование данных моделей проводится в формате деловой игры с привлечением владельца процесса, представителей группы управления проектом, владельцев результатов , технических экспертов. В ходе согласования уточняется движение информационных потоков и потоков объектов, уточняются должности руководителей, ответственных за выполнение процессов, состав участников на уровне структурных подразделений и должностей сотрудников.
После получения второй версии проводится ее финальное согласование, результатом является третья, основная рабочая версия, которая будет являться базисом корпоративной базы знаний по компании. На основе этой базы знаний будут проводиться мероприятия по дальнейшей оптимизации или разработке методик и процедур уровня элементарных действий.
Для бизнеса важно получение быстрого результата от вложенных инвестиций. Проект по описанию и оптимизации — не исключение, тем более что он направлен на повышение эффективности деятельности компании в целом. Для того чтобы показать значимый результат в приемлемые сроки, на этапе описания рекомендуется сформировать предложения по оптимизации с использованием инструментов выявления и устранения потерь, принципов и методов оптимизации . Предложения по оптимизации рассматриваются в ходе деловых игр с участием представителей группы управления проектом, владельцев процессов и всех заинтересованных лиц и, в случае согласования, отражаются в разрабатываемой .
Этап седьмой — внедрение
После согласования финальной версии модели компании деятельность по описанию и оптимизации переводится на постоянную основу — как говорилось ранее, группа управления проектом становится Центром компетенций по компании, участники рабочих групп по описанию и оптимизации продолжают совмещать свою текущую деятельность в структурных подразделениях компании с моделированием, анализом и регламентацией своих .
Разработанные модели и регламентирующая документация вводится в действие приказом руководителя компании. Информация доводится до сотрудников в соответствии с правилами, установленными в компании, а также с использованием , размещенном на корпоративном сетевом ресурсе.
Соблюдение требований введенных в действие регламентов и процедур проверяется в ходе внутренних аудитов, проводимых внутренними аудиторами (если в компании действуют системы менеджмента) или специалистами внутреннего аналитического подразделения. Порядок и сроки проведения аудитов устанавливаются соответствующим регламентирующим документом. Эффективность деятельности компании оценивается по результатам организационной диагностики, а также по данным мониторинга показателей эффективности .
Практика показывает, что на момент начала работ по описанию и оптимизации в компаниях уже имеется большой пакет регламентирующей документации (особенно характерно для компаний, в которых действуют системы менеджмента). Часть документов из данного пакета зачастую нецелесообразно переносить в систему для будущего формирования в автоматическом режиме ввиду больших временных и трудозатрат. Для синхронизации имеющихся документов с новыми версиями процессов компании на этапе описания процессов необходимо проводить их анализ на предмет актуальности. После согласования финальной версии выполняется полная актуализация имевшейся документации с привязкой к новым версиям .
Вместо заключения
Резюмируя вышесказанное, хочется отметить, что, как и в любом сложном деле, при улучшении деятельности компании важно точное понимание причин инициирования проекта и использование в проекте наилучших методик и инструментов. Надеемся, что эта статья снимет множество вопросов, которые возникают у руководителей, и позволит легче решиться на начало изменений. Уверены, что результат не заставит себя ждать!
Моделирование бизнеса. Основные подходы
В этой статье я хочу поговорить об основных принципах моделирования бизнеса, о тех подходах, которые применяются в этой сфере, и на основе которых создаются языки моделирования и нотации.
Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.
С одной стороны, применение схем для наглядности при описании моделей бизнеса в ни у кого не вызывает вопросов. Это действительно очень удобно. С другой стороны, многие бизнесмены и даже мои коллеги недоумевают, зачем нужны специальные нотации и правила для разработки бизнес-процессов, ведь можно в любом графическом редакторе (visio) или при помощи других удобных инструментов просто нарисовать интуитивно понятную схему.
О том, почему так важна стандартизация, а также о том, в каком случае применяется тот или иной подход, я и хочу поговорить.
Основные подходы
Сегодня существует множество различных инструментов для разработки бизнес-моделей, они используют различные языки моделирования, как стандартные, так и какие-то собственные разработки. Но все их можно объединить по принципу работы в три основных подхода:
- Функциональный;
- Процессный;
- Ментальный (с применением ментальных карт).
Функциональное моделирование
Функциональное моделирование рассматривает бизнес как функцию (лат. functio — совершение, исполнение) или иными словами «черный ящик». В функциональной модели функция не имеет временной последовательности, а только точку входа и точку выхода. Функциональное моделирование помогает рассматривать бизнес-модель с с точки зрения результативности, т.е. при моделировании мы исходим из того, что имеем на входе, и того, что желаем получить на выходе.
Например, компания разрабатывает какую-то CRM-систему для своего бизнеса. В случае применения функционального подхода к моделированию уже сама выбранная среда для работы подсказывает, с чего начинать. Точка входа – «входящий интерес клиента или лид», точка выхода – желаемый результат: «покупка и получение лояльного клиента», «получение постоянного клиента», «получение максимум информации о потенциальном клиенте» и т.д.
Таким образом, в функциональной модели изначально известны точка входа и желаемый результат, а последовательность действий и является объектом разработки. При этом использование функциональных моделей как «черных ящиков» позволяет детализировать каждый этап по мере необходимости. А вся работа при моделировании направлена на поиск оптимального решения для достижения цели.
Функциональные модели вы можете также использовать для демонстрации своих идей и вариантов решений. Это также очень удобно, ведь в процессе демонстрации вы можете двигаться от общего к деталя, по мере необходимости разделять и декомпозировать функции. Но декомпозировать вы будете при этом именно функции, и, разделяя одну функцию на несколько, вы не получите описание процесса.
Некоторые путают описание процесса и функциональную модель. Например, в системе Business Studio функцию называют процессом, хоть это и не совсем верно. Все же описание функций и процессный подход – несколько разные вещи. И я лично считаю, что функциональное моделирование оптимально реализовано в нотации IDEFO. Сам я для такого варианта работы использую именно ее, и всем также рекомендую.
Правила работы с IDEFO вы можете подробнее изучить, прочитав мою статью накомство с нотацией IDEF0 и пример использования.
Процессное моделирование (моделирование бизнес процессов)
О процессном моделировании я буду рассказывать с точки зрения нотации BPMN, как одного из наиболее распространенных стандартов процессного моделирования. При этом я полностью согласен, что существует множество языков моделирования и различных систем. И каждый может пользоваться тем, что ему удобнее. Но все же BPMN — это уже сложившийся стандарт процессного моделирования, а потому его я и беру за основу в описании.
Процесс с точки зрения бизнес-модели — это последовательность каких-то событий и действий, которые имеют начало и конец.
В этом кроется основное отличие процессного моделирования от функционального. Функциональное моделирование рассматривает бизнес-модель с точки зрения входа и выхода (имеющихся ресурсов и желаемого результата). А процессное основано на последовательности действий в определенных границах, в случае BPMN это будут начало и конец события.
Все процессы могут разбиваться (детализироваться) на подпроцессы вплоть до детализации на уровне задач, т.е. действий, дальнейшая детализация которых невозможна. Процесс – это некая последовательность действий, которую необходимо выполнить, чтобы получить определенный результат. Необходимо отметить что в модели бизнеса как процесса результат может и не быть явным в отличии от функциональной модели.
Принципиальное отличие процессного моделирования от функционального заключается в том, что при процессном моделировании основное внимание уделяется не тому, что мы хотим получить, а тому, что нужно сделать для получения результата, т.е. не итогам той или иной деятельности, а самой последовательности действий.
Например, в BPWIN или Business Studio в процессе детализации каждой функции происходит переход от функционального подхода к процессному. Т.е. в общем, мы рассматриваем модель с точки зрения – возможностей и желаемого результата, а когда переходим к решениям для каждой функции, здесь уже практикуется явно процессный подход, т.е. пошаговый алгоритм действий для достижения результата.
Представьте себе что в функциональной модели есть «черный ящик» — функция «Принять заказ». А при декомпозировании мы уже рассматриваем ее не как функцию, а как процесс, и последовательность действий при приеме заказа – это уже процессный подход.
Есть и еще одно очень важное отличие. Функциональную модель невозможно использовать при реализации какой-то либо системы, только для проектирования. А процессный подход позволяет создавать исполняемые модели, т.е. описания последовательности действий, которые мы можем в дальнейшем перевести в какую-то среду для создания системы совместной работы предприятия, основанной на процессном подходе.
Ментальный подход (ментальные карты)
При создании ментальных моделей специалист подходит к моделированию не как к процессу или набору функций, а как к некому набору связанных между собой понятий. Для наглядности я приведу пример — ментальная карта понятия “Процедура снабжения” (см. рисунок).
Такой вариант подхода применяется, прежде всего, для себя. Рисование схемы в свободной форме помогает структурировать свои знания, так сказать, “разложить по полочкам” в свободной форме полученную информацию. Также подобные ментальные карты помогают найти решение, которое уже позже, по мере необходимости, будет воплощаться в рамках строгих правил процессного или функционального подхода.
Можно применять ментальные карты и для демонстрации клиентам: и существующей ситуации, и вариантов решения поставленной задачи. Ментальные карты помогут наглядно продемонстрировать, какие методы могут быть использованы, показать в наглядной форме различные идеи.
Плюсы применения таких ментальных карт очевидны:
- Не нужно знать какие-то специальные языки;
- Нет строгих рамок и ограничений при создании схемы;
- Ментальная карта в большинстве случаев интуитивно понятна;
- Создавать такие схемы просто.
В результате для понимания модели и заложенных в ней идей требуется присутствие и комментарии ее разработчика (аналитика).
Конечно, существуют очень простые карты, которые интуитивно читаются и без дополнительных комментариев. Но при отсутствии стандартов всегда есть вероятность, что даже в этом случае автор что-то другое имел в виду или где-то недостаточно детализировал свою схему. Т.е. существует вероятность разного прочтения. А бизнес — это не философия. При всей умозрительности и разнообразии подходов к описанию бизнес-процессов, здесь очень важны однозначные решения.
Методология и языки бизнес-моделирования
Очень часто даже в профессиональной литературе возникает путаница, когда люди смешивают понятия методологии анализа работы бизнеса и описания языков бизнес-моделирования.
Методология — это система принципов и стандартов описания бизнес моделей и их последующего анализа. В то время как язык бизнес-моделирования – это не более чем инструмент для разработки моделей бизнеса.
Здесь напрашивается сравнение с программированием вообще и применением конкретного языка программирования. Программирование включает в себя и построение алгоритма, и выбор подходящего языка программирования, и реализацию алгоритма программы в рамках того или иного языка. А, например, программирование на языке Си++ – это уже заведомо ограничение определенными рамками, так как средствами определенного языка можно решить только четко ограниченный круг задач, и, одновременно, даже если задачу можно решить средствами Си++ совсем не обязательно, что именно этот язык будет в конкретном случае оптимальным. В общем, разницу между понятием «программирование» и «программированием в рамках определенного языка», я думаю, большинство понимают даже без таких пояснений.
Отличие языков разработки бизнес-моделей в от языков проектирования систем
Существует целое семейство языков проектирования систем, которые внешне схожи с языками бизнес-моделирования, например, это Ares Studios, целое семейство языков UML и другие, которые используются для проектирования IT-систем.
Основное различие этих языков от языков разработки бизнес-процессов лежит в их предназначении. Если языки проектирования IT-систем рассматривают бизнес-процессы с точки зрения возможности их автоматизации, воплощении в IT-системах, то языки бизнес-моделирования рассматривают последовательность действий именно с точки зрения бизнеса, включая работу как IT-систем, так и сотрудников, движения товаров и т.д.
Соответственно, в языках проектирования систем нет элементов, которые помогут полноценно описать действия подразделений, сотрудников, взаимодействие между ними, работу с поставщиками, общение с клиентами и так далее. Инструменты этой группы языков помогут именно автоматизировать процессы бизнеса, которые поддаются автоматизации. А все остальное будет оставлено «за кадром», например, как некие «функции» без расшифровки.
В то же время языки разработки бизнес-процессов охватывают максимально именно работу бизнеса как такового, а вот те или иные нюансы автоматизации и алгоритмизации систем в них описать далеко не всегда возможно с достаточной степенью детализации.
Преимущества разработки моделей бизнеса
И все же, зачем применять языки бизнес-моделирования, которые налагают строгие ограничения, требуют придерживаться жестко заданных правил при моделировании? Ведь всегда можно «нарисовать схему» в графическом редакторе или даже на бумаге, используя ментальный подход, при этом изучение языков моделирования вообще не потребуется.
На самом деле, стандарты и правила – это огромный плюс:
- Языки моделирования помогают максимально качественно передать информацию. Стандартизация повышает простоту восприятия.
- Скорость разработки моделей значительно увеличивается. Языки содержат все необходимые инструменты и графические блоки в готовом виде. Вам не придется «рисовать» или придумывать свою терминологию. Инструментарий уже готов, и работа в его рамках значительно ускоряется. Конечно, язык нужно выучить. Но один раз изучить – это намного быстрее, чем каждый раз придумывать и пояснять собственный набор обозначений.
- Снижается число возможных ошибок. Сами элементы системы уже будут «подсказывать» перечень возможных и необходимых действий. А в случае создания исполняемых моделей или неисполняемых, но в строгих рамках правил, всегда можно проверить работу бизнес-модели в исполняемой среде и провести отладку, как при программировании.
Применение моделей бизнеса на практике
Лично я считаю, что бизнес-моделирование стоит применять при решении любых задач, связанных с выявлением проблем и «узких мест», с оптимизацией и модернизацией бизнеса и т.д. Как бизнес-консультант я практически всегда строю модели работы компании или ее подразделений при работе со своими клиентами. Это дает четкое понимание всех этапов работы и позволяет избежать «белых пятен» в этом вопросе.
Кроме того, наглядные схемы бизнес-моделей помогают мне в процессе взаимодействия с клиентами. Проекты у меня часто бывают сложными, и обычного текста или устной речи бывает недостаточно для понимания, в то время как использование наглядных бизнес-моделей снижает затраты времени клиента на чтение и понимание моих предложений, и практически исключает проблемы взаимопонимания в этом вопросе. И если несколько лет назад я еще сталкивался с недоумением со стороны клиентов, то сейчас вариант описания «на словах» без наглядных и удобных схем практикуется крайне редко.
А в случае автоматизации какого-либо этапа работы или создания автоматизированной системы управления бизнесом на основе проектно-ориентированного подхода качественная бизнес-модель, выполненная в том или ином языке моделирования, станет готовым руководством для технических специалистов.
Удобство, универсальность, простота восприятия – это те причины, по которым от словесных описаний в бизнес-сфере все больше переходят к бизнес-моделированию. А применение готовых языков позволяет работать с моделями быстро, избегать ошибок, и также без проблем вносить любые изменения.
Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости ссылке.
Моделирование бизнес-процессов для стартапа: что это такое и для чего нужно
Стартап — проект, который по определению призван быть уникальным. Это поиск нового решения для проблемы пользователя, создание некоего инновационного продукта, которого пока нет на рынке. Наверное, кажется кощунством в этом ключе говорить о таких вещах, как планирование, создание регламентов и написание инструкций, моделировании бизнес-процессов. Тем не менее, без них, а в особенности без последнего, вашему стартапу будет сложно добиться успеха. Рано или поздно вы столкнетесь с тем, что не знаете сферу ответственности каждого из членов команды, потому что все занимаются по чуть-чуть всем; с некоторым хаосом в задачах, снижением эффективности работы и прочими прелестями “творческого процесса”. В этой статье я расскажу, что такое бизнес-процессы, как их моделировать и как это поможет сделать работу стартапа слаженной и продуктивной.
Бизнес-процессы — взаимосвязанные мероприятия, или работы, цель которых — создание продукта или услуги. Все бизнес-процессы подразделяются на три больших вида в зависимости от назначения:
- Управляющие — это корпоративное управление, стратегический менеджмент. Такие процессы двигают ваш проект — это поиск партнеров и заключение с ними контрактов, продажи, выход на новые рынки.
- Операционные бизнес-процессы — снабжение, производство, маркетинг, продажи, взыскание долгов.
- Поддерживающие, или вспомогательные, — процессы, которые обслуживают основной бизнес. Это бухучет, подбор персонала, техподдержка.
К примеру, ваш стартап — это сеть фитнес-центров с консультирующими диетологами и мобильное приложение, которое позволяет клиентам записываться на консультации со специалистами, бронировать и оплачивать занятия с учетом удобного для себя времени, направления, района. В таком случае управляющими процессами здесь будут изучение рынков соседних городов на предмет открытия там спортзалов, переговоры с местными властями о предоставлении помещений на выгодных для вас условиях. Операционные процессы — работа спортзалов по установленному расписанию, организация индивидуальных встреч клиентов с диетологами, создание для них индивидуальных планов диет и физических нагрузок, продвижение бренда. Вспомогательные процессы — поиск диетологов и фитнес-тренеров в команду, ведение бухучета, поддержание работы сайта и мобильного приложения.
Моделирование бизнес-процесса — это построение модели-представления, которая отражает самые важные черты и свойства исходного процесса. Простыми словами, вы прописываете, как все должно выглядеть в идеале.
Чтобы создать модель, необходимо определить:
- результат бизнес-процесса;
- кем и какие действия выполняются;
- каков их порядок;
- каково движение документов в ходе выполняемого процесса;
- надежность процесса;
- возможность расширения/модификации процесса в будущем.
В нашем стартапе результатом бизнес-процесса по привлечению клиентов является запись клиента на очную платную консультацию с диетологом через мобильное приложение. Действия выполняются клиентом, который установил приложение и оставил через него заявку, а также администратором, который обрабатывает все поступающие заявки и уточняет у клиента, придет ли он в указанное время на встречу.
Что касается документов, то с точки зрения бизнес-процессов под ними понимается любая информация на любом носителе. В нашем случае это информация на экранах мобильного приложения с презентацией нашего продукта, опросом клиента с целью выявления его проблемы, календарь и карта, при помощи которых клиент выбирает удобное для него время и место консультации/занятий. Далее, когда заявка поступает администратору, он, созваниваясь с клиентом, пользуется заранее подготовленными скриптами, которые также в данном случае являются документами.
Надежность процесса гарантируется автоматизированной работой приложения, а также работой администратора, который отслеживает все возможные нестыковки и сбои в ПО.
Расширение процесса в будущем у нас также предусмотрено: мобильное приложение дает возможность клиенту после консультации с диетологом самому выбирать время и место занятий, бронировать их и оплачивать через приложение уже без контакта с администратором.
Кейс 1. Идеально отлаженный бизнес-процесс: Википедия
Все мы знаем и регулярно пользуемся продуктом этого проекта — свободной энциклопедией. Это пятый по посещаемости сайт в мире, на котором размещено десятки миллионов статей на 300 языках, писать статьи и вносить правки может любой желающий, т.е. гипотетически “работать” в Википедии может любой житель планеты, у которого есть доступ в интернет.
Парадоксально, но в фонде Викимедиа, который занимается техподдержкой и управлением Википедии, работает около 300 человек. Гигантский проект двигают четко отлаженные бизнес-процессы с максимальной автоматизацией и использованием искусственного интеллекта.
Каким бы скучным это ни казалось, однако в самом начале активной фазы развития стартапа следует уделить несколько дней описанию процессов, которые протекают на вашем, пускай еще совсем маленьком предприятии. Это поможет избежать ряда неудобств и проблем как в настоящее время, так и в более отдаленном будущем, когда проект станет более масштабным. Итак, каких же проблем поможет избежать моделирование бизнес-процессов?
1. Неопределенности, как поступить на том или ином этапе развития компании. К примеру, уволился один из ключевых сотрудников, который был на проекте с самого начала, теперь неясно, как именно строилась его работа, т.к. компания видела результаты, и они были положительными. Руководство не видело необходимости вмешиваться в работу человека. В итоге теперь нет представления, как ввести в курс дела новичка.
Если все процессы на вашем проекте прописаны, то вы избежите вышеперечисленных неудобств: вы заранее будете знать, куда и как будет поставляться ваш продукт и кто будет контролировать это; вы будете знать, как выстроена работа каждого из ваших сотрудников, а все их деловые контакты, связи будут задокументированы.
2. Саботажа со стороны сотрудников, когда компания уже на более поздних этапах решится регламентировать их деятельность. Люди будут считать, что их интересы, свободы грубо ущемлены, т.к. изначально речи об инструкциях, регламентах, описаниях рабочих процессов не было.
3. Хаоса в команде, когда, к примеру, у сотрудников есть должности, но нет полномочий, или когда над одним и тем же процессом параллельно работает несколько человек, в результате работа дублируется, в то время как другие задачи простаивают.
4. Снижения эффективности стартапа и его акционерной ценности (shareholder equity). Моделирование бизнес-процессов позволяет собственникам сконцентрироваться на собственной прибыли предприятия, детально контролировать доходы и расходы. Предприятие за счет привлеченных средств (кредиты, инвестиции, дотации), может казаться какое-то время безубыточным, однако на самом деле его акционерная стоимость в этом случае невелика.
5. Потери клиентов. Хорошо налаженные бизнес-процессы позволяют команде работать эффективно и быстро, а это существенный фактор в наши дни. Если сравнить бизнес-среду с фудкортом, то компании с хорошо отлаженными процессами — это точки, где клиентов обслуживают без промедления, они платят за свой заказ и уходят довольные. А вот компании, у которых бизнес-процессы не отлажены, часто теряют клиентов, т.к. из-за внутренней неразберихи менеджеры не успевают уделить внимание всем заявкам, в итоге многие заказы уходят.
6. Ряда непродуманных/неконтролируемых расходов. Моделирование делает работу каждого человека в компании прозрачной: известно, сколько составляет его зарплата, при каких условиях он получает премию, сколько составляют расходы на командировки, где и по какой цене закупаются канцтовары. Когда все процессы прописаны, практически исключается возможность какого-либо сокрытия денег, их хищения — как мелкого, так и крупного.
7. Конфликтов в команде. Рабочие конфликты возникают чаще всего там, где управление не формализовано и не регламентировано. Благодаря моделированию бизнес-процессов, обязанности и полномочия каждого сотрудника детально прописаны, руководители в курсе, как выстроены все процессы в их сфере ответственности и могут детально объяснить это подчиненным. Каждый менеджер точно знает, что должен делать тот или иной сотрудник.
Источник https://www.businessstudio.ru/articles/article/likbez_dlya_rukovoditeley_modelirovanie_biznes_pro/
Источник https://habr.com/ru/company/trinion/blog/332772/
Источник https://vc.ru/finance/95377-modelirovanie-biznes-processov-dlya-startapa-chto-eto-takoe-i-dlya-chego-nuzhno