Что такое формализация бизнес модели – Ликбез для руководителей: моделирование бизнес-процессов на раз-два-три

Содержание

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

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

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

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

Начало начал

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Превращение в гиганта: практика организационного развития ГК «Гулливер»
Нотация BPMN как внутренний стандарт компании для проектирования бизнес-процессов: «за» и «против»
Презентация доклада «Проектирование системы управления предприятием» c форума «Промышленный салон-2005»
Business Studio: разграничение прав через HTML-навигатор

www.businessstudio.ru

формализация бизнес-процессов | Executive.ru

Елена, здравствуйте!
Описывал по-разному.
Про подходы и проблемы можно говорить долго, но постараюсь вкратце.
Чьими силами описывать?
1. Полностью самостоятельно если:
— в компании имеются специалисты по совершенствованию системы управления и бизнес-процессов. Или имеется возможность приёма с рынка труда таких специалистов. Почему я говорю про совершенствование системы управления? Потому что в ходе «описания» бизнес-процессов и последующего внедрения вы невольно сталкиваетесь с вопросами организационных изменений, изменений принципов принятия решений в компании. Могут быть затронуты самые разнообразные функциональные зоны ответственности — управление финансами, персоналом и т.п.
— в компании есть мощная поддержка этих работ, прежде всего со стороны генерального директора и у «описывателей» не будет проблем с полномочиями.
— проект по «описыванию» долговременный, не менее чем на 1,5 года. А ещё лучше, если компания созрела до понимания, что совершенствование бизнес-процессов и системы управления — это постоянная деятельность, необходимая для поддержания компании «в тонусе». — компания не готова тратить большие деньги на привлечение сторонних консультантов.

2. Полностью внешними консультантами.
— своих специалистов нет и привлечь с рынка труда невозможно (специалисты могут отсутствовать на рынке или компания не может предложить достойный уровень з/п)
— в компании не всё хорошо с пониманием необходимости этих работ. Есть риск, что у штатных сотрудников будут проблемы с полномочиями.
— хочется попробовать или проект кратковременный.
— есть много денег на консультантов 🙂
— на примете есть консультанты, которым можно доверять 🙂

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

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

Выбор инструментария и программного обеспечения для описания бизнес-процессов, тоже не маловажный момент. Это существенно влияет на восприятие результата и трудоемкость/стоимость работ.
Как правило, внешние консультанты «заточены» под 1 инструмент. Реже 2 и более.
Поэтому желательно оценить, как производится описание, и что получаете на выходе.
Ещё обратите внимание на потенциал инструментария.
Одно дело, когда он позволяет только формировать текстовые регламенты описания бизнес-процессов.
Совсем другое дело, когда вы, описывая бизнес-процессы создаёте комплексную модель деятельности предприятия в самых разных аспектах: стратегия, орг. структура, описание ИТ инфраструктуры, оборудования и т.п. И далее, используете эту комплексную модель для поиска узких мест процесса через имитационное моделирование, стоимостную оценку, расчета потребности в ресурсах (персонале, прежде всего) именно средствами программного обеспечения, на основе созданных моделей.
Важно как это будет доводиться до потребителя – текстовые регламенты будут храниться в какой-либо централизованной системе документооборота или имеется потребность в доступе к графическим моделям, через централизованный Web портал с распределением прав доступа.
Важна территориальная расположенность участников проектной группы и формат их работы. Если моделировщиков бизнес-процессов много, инструментарий должен позволять вести коллективную одновременную работу в единой базе данных.
К сожалению, на рынке не такой уж и широкий выбор программного обеспечения.
Самые распространенные это ARIS, CaseWise, BusinessStudio (в России), ну и конечно народно-ручной инструментарий типа MS Visio/Word и даже Excel :).

Безусловно важна методология проведения работ. Инструментарий инструментарием, но методики совершенствования – это чисто опыт и подходы лиц их осуществляющих. Поэтому, чем больше опыта у «описывателей», тем лучше. Если говорить о внешних консультантах, то стоит обратить внимание на наличие и широту их просветительской деятельности: курсы, конференции, кафедры в ВУЗах и т.п, а также на характер компании. Лучше, чтобы это была международная компания.

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

Удачи Вам!
P.S. Кажется вкратце не получилось 🙂

www.e-xecutive.ru

17 бизнес‑моделей. Придумать новую или использовать старую? — СКБ Контур

Что такое бизнес-модель?

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

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

Структура бизнес-модели состоит из трех частей:

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

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

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

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

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

7 вопросов для оценки бизнес-модели по Остервальдеру:

1. Стоимость переключения

Насколько сложно потребителям переключиться на товары или услуги другой компании?

2. Регулярный доход

Требует ли каждая продажа новых усилий или она дает определенную гарантию последующих продаж и доходов?

3. Доходы и издержки

Вы получаете доход до или после того, как возникают издержки?

4. Революционная структура издержек

Ваша структура издержек иная и принципиально лучше, чем у конкурентов?

5. Перекладывание работы на другие стороны

Позволяет ли ваша бизнес-модель потребителям и третьим сторонам бесплатно создавать ценность для вашей компании?

6. Масштабируемость

Легко ли вы можете расти, не сталкиваясь с препятствиями, например, связанными с инфраструктурой, поддержкой потребителей, наймом персонала?

7. Защищенность от конкуренции

Хорошо ли бизнес-модель защищает вас от конкурентов?

17 наиболее распространенных бизнес-моделей

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

1. Реклама

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

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

Примеры: The New York Times, YouTube

2. Партнерская программа

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

Например, если вы запустите сайт, посвященный обзору книг, вы cможете вставлять партнерские ссылки на Ozon или другие книжные интернет-магазины в свои обзоры. Если посетитель, перейдя по ссылке, купить книгу, партнер заплатит вам небольшую комиссию за продажу.

Примеры: «Альпина Паблишер», Ozon, Aviasales

3. Комиссия

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

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

Примеры: агентства недвижимости, PR-агентства, event-компании, рекрутинговые агентства

4. Кастомизация

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

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

Примеры: NIKEiD, «Рубашка на заказ», «Велокрафт»

5. Краудсорсинг

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

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

Примеры: ЖЖ, YouTube, P&G Connect and Develop

Откройте счет в Контур.Банке и пользуйтесь встроенной бухгалтерией и отчетностью. Корпоративная карта и электронная подпись — бесплатно. До 5 % на остаток.

Узнать больше

6. Отказ от посредников

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

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

Примеры: Casper, Dell

7. Дробление

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

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

Примеры: Disney Vacation Club, NetJets

8. Франшиза

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

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

Примеры: Domino`s Pizza, McDonald’s, Subway, «Шоколадница»

9. Freemium

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

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

Примеры: MailChimp, Evernote, LinkedIn, Lingualeo

10. Лизинг

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

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

Примеры: «Уралпромлизинг», «ЛИАКОН», «ЗЕСТ»

11. Low-touch

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

Примеры: IKEA, Ryan Air, «Победа»  

12. Маркетплейс

Торговые площадки позволяют продавцам выставлять товары для продажи и предоставлять клиентам простые инструменты для контакта с продавцами.

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

Примеры: eBay, Airbnb, «Ярмарка Мастеров», Ticketland

13. Оплата по факту использования

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

Примеры: HP Instant Ink

14. «Бритва и лезвие»

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

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

Примеры: Gillette, струйные принтеры, Caterpillar, Amazon’s Kindle

15. «Бритва и лезвие наоборот»

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

Примеры: iPod и iTunes, Keynote, Numbers

16. Обратный аукцион

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

Примеры: Priceline.com, LendingTree

17. Подписка

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

Примеры: Netflix, Salesforce, Comcast

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

По материалам Bplan

Все самое интересное о бизнесе — на нашем канале в Telegram. Присоединяйтесь!

kontur.ru

Как мы внедряли бизнес-процессы и зачем оно вообще надо / Мосигра corporate blog / Habr

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

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

Пример постановки процесса из 1900-х

Рабочие на заводе Форда собирают детали на конвейере. Рабочий получает 5 баксов в день и собирает 30 единиц продукции. Генри Форд в течение часа смотрит на рабочего и понимает, что тот делает много лишних действий. Он пробует сам собрать деталь по новой схеме, и понимает, что, по идее, это можно делать быстрее, но нужно чуть изменить конвейер, подвинуть оборудование, и, главное, научить рабочего совершать другие движения. Через «не хочу» он обучает этого человека делать как надо — и, вуаля! — он всё ещё продолжает получать 5 баксов в день, но производит уже 42 единицы продукции.

Привычно? Нет. Интуитивно-понятно? Нет. Выгодно? Да, если затраты на переобустройство и переобучение рабочих меньше, чем предполагаемая прибыль.

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

Хронология борьбы с бардаком

Мы прошли вот такие стадии:
  1. Нас четыре человека, все всё понимают.
  2. Появляется два разных магазина: уже нужны правила приёма почты и правила обязательных ответов на неё.
  3. Появляются представительства в городах. Начинается систематический сбор информации для внутренних инструкций, советов и других штук, призванных помочь в разных ситуациях: по сути, позитивный опыт и наследственные коллекции грабель.
  4. Усложняются взаимодействия по сайту. Разработчики поднимают трекер и систему тикетов.
  5. Нас столько, что одни и те же вопросы задаются больше трёх раз. Заводится закрытый корпоративный блог, чтобы иметь возможность быть в курсе всего, быстро сообщать о проблемах, меняться механиками процессов.
  6. Нанимается команда специалистов, которые планируют бизнес-процессы внутри компании, составляют точные инструкции и оргсхему. По сути, идёт процесс описания уже существующих процессов и их оптимизации там, где это нужно.
  7. Вся эта радость дотачивается под ситуации.

Нужны ли процессы, если команда из 10 человек?

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

Пример 1: простой, но знакомый до боли — фича от клиента.

  1. Встреча клиента и менеджера для постановки задачи.
  2. Согласование критериев приёмки задания.
  3. Руководитель отдела составляет техзадание разработчику.
  4. Техзадание или контрольные точки согласовываются с клиентом.
  5. Ведётся разработка.
  6. Руководитель отдела проводит приёмку.
  7. Менеджер проводит сдачу проекта клиенту.

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

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

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

  1. Обращается к старшему точки и сообщает о проблеме.
  2. Старший точки обращается к региональному координатору и сообщает о проблеме.
  3. Координатор стучит к руководителю отдела АХО и сообщает о проблеме.
  4. Руководитель отдела АХО ставит задачу разнорабочему.
  5. Разнорабочий утверждает бюджет у своего руководителя на новую полку.
  6. Финансовому директору на стол ложится счёт под подпись.
  7. Наступает следующий день.
  8. Рабочий наконец-то ставит новую полку.

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

Теперь та же ситуация выглядит так:

  1. Продавец обращается в АХО и сообщает о проблеме.
  2. Сотрудник АХО принимает решение о целесообразности использования средств.
  3. Рабочий ставит новую полку.

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

Если АХО выставляет счёт, который выходит за план их отдела, генерится алерт для руководства, где есть две кнопки: «дать люлей» и «разрешить». При желании можно нажать обе. Суть механики: путь короче и быстрее, но полный контроль при этом сохраняется. Никаких лишних действий.

Метрики

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

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

Работу закупщика оценивать уже сложнее: но построение бизнес-процесса даёт возможность понимать, что именно дальше стало с товаром, как именно оно стало и насколько эффективно.

Косяки

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

Говорят, у военных есть инструкции на все случаи жизни: даже если прилетит НЛО с плазменными танками, у них есть точный план действий на этот случай. Так и с процессами: в идеале они есть на все случаи жизни сотрудника. Когда у сотрудника нет плана на непредвиденный случай, происходит два события:
  • Он обращается к тому, кто отвечает за этот вопрос (скорее всего, не отвлекая своего руководителя).
  • Если ситуация повторяется, создаётся процесс-правило для обработки таких случаев.

Как это всё внедряется в компанию
  1. Сначала аналитик разговаривает с руководителем и понимает задачу. Бывает так, что процессы внедряются для галочки, чтобы потом выгоднее продать бизнес иностранцем, бывает, что для понтов, а бывает — что для дела. Последний случай наиболее интересный и сложный.
  2. Выставляется счёт, вызывающий оху когнитивный диссонанс. В этот момент нужно договариваться на такие условия, что оплата производится при повышении конкретных показателей. Грубо говоря, стали получать на 20% больше прибыли в результате внедрения — платите.
  3. Затем аналитик обходит всю компанию и задаёт много-много вопросов о том, как оно работает.
  4. Потом каждому сотруднику приходит анкета с просьбой указать свои выполняемые задачи (заполняется полчаса).
  5. Аналитик напряжённо думает и составляет блок-схему взаимодействия, из которой растут процессы и оргсхема компании.
  6. Компания реорганизовывается под новые процессы.
  7. Сотрудникам доносится суть изменений. Если сотрудники в возрасте, они понимают туго, но делают сразу. Если молодые — понимают отлично, но изменяются медленно.
  8. Корректируются баги. Структура меняется по мере изменения компании и её процессов.

Сроки

У нас процесс занял около месяца на сбор данных при аналитике (работающем по программе «Луноход-1») и аналитике в штате, ещё месяц ушел на сбор и проверку анкет, ещё через кучу времени появилась оргсхема и процессы, потом всё это было внедрено. В общей сложности на всё ушло примерно полгода.
Зачем ещё нужно внедрять такие штуки
  • Чтобы контролировать рабочий процесс, не терять задачи и видеть, кто и что конкретно делает.
  • На каждую вещь в компании появляется конкретное ответственное лицо (у каждой проблемы появляется фамилия).
  • Не объяснять каждый раз новому человеку, к примеру, как оформлять выезд и т.п.
  • Эффективнее масштабироваться без объяснения всей сути жизни каждому сотруднику в другом городе.
  • Быстро принимать новых людей.

Резюме: плюсы и минусы

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

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

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

habr.com

Что даёт формализация бизнес-процессов | Статьи iTeam

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

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

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

Суть формализации бизнес-процессов

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

Если этого не сделать, неизбежны следующие проблемы:

  • Не всегда понятно, какой сотрудник за что отвечает.
  • Часто неочевидно, кто отвечает за конкретную задачу.
  • Решение каждой задачи задерживается, так как отсутствует чёткий алгоритм.
  • Задачи (документы, клиенты, заявки) совершают большой «путь» по компании, пока будут решены, при этом задействуются избыточные для данного случая сотрудники.

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

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

Задачи формализации бизнес-процессов

Формализация бизнес-процессов может быть выполнена разными методами, например, с помощью систем BPM, либо «вручную». Однако она всегда предполагает выстраивание чёткого алгоритма:

  • Закупка сырья.
  • Доставка сырья на склад.
  • Хранение на складе.
  • Отправка в цех.
  • Производство продукции.
  • Отправка продукции на склад.
  • Доставка продукции клиенту после покупки.

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

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

  1. Должна быть выстроена чёткая схема для бизнес-процесса.
  2. Каждый сотрудник должен понимать, на каком участке схемы требуются его усилия, где начинается и где заканчивается его ответственность; от кого он получает задачи и куда должен их передать после обработки.
  3. Руководитель должен иметь возможность проконтролировать, где находится задача на данный момент времени (на каком этапе и у какого сотрудника).

Формализация бизнес-процессов путём автоматизации

Начать с того, что формализация бизнес-процессов не предполагает обязательной автоматизации с помощью BPMS, она может быть выполнена и вручную. Самый простой путь – написание регламентов для каждого сотрудника. Благодаря этому удаётся успешно решить часть задач, а именно задачи 1 и 2 приведённого выше списка (составление схемы и понимание каждым сотрудником его роли).

 

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

Если же формализация бизнес-процессов проводится с помощью систем BPM, то появляются дополнительные весьма важные возможности:

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

Последняя возможность особенно важна, потому что она помогает, в том числе:

  • Узнать, кто из сотрудников работает эффективно, а кто не очень.
  • Увидеть реальный объём всей работы, выполненной каждым работником. Может, кто-то лишь делает вид, что чем-то занят?
  • Избавиться от риска самых разнообразных злоупотреблений персонала.

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

Автор: Елена Гайдукова

Источник: материалы сайта comindware.com

blog.iteam.ru

Моделирование бизнеса. Основные подходы / Trinion corporate blog / Habr

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

Я уже писал о моделировании при помощи 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. Языки моделирования помогают максимально качественно передать информацию. Стандартизация повышает простоту восприятия.
  2. Скорость разработки моделей значительно увеличивается. Языки содержат все необходимые инструменты и графические блоки в готовом виде. Вам не придется «рисовать» или придумывать свою терминологию. Инструментарий уже готов, и работа в его рамках значительно ускоряется. Конечно, язык нужно выучить. Но один раз изучить – это намного быстрее, чем каждый раз придумывать и пояснять собственный набор обозначений.
  3. Снижается число возможных ошибок. Сами элементы системы уже будут «подсказывать» перечень возможных и необходимых действий. А в случае создания исполняемых моделей или неисполняемых, но в строгих рамках правил, всегда можно проверить работу бизнес-модели в исполняемой среде и провести отладку, как при программировании.

Применение моделей бизнеса на практике


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

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

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

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

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

habr.com

Бизнес-моделирование — e-xecutive.ru

Что такое моделирование бизнес-процессов

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

  1. Нотации специализированного программного продукта: комбинация графики, таблиц и текста.
  2. Графическое описание: дерево, блок-схема, технологическая карта.
  3. Табличное описание.
  4. Текстовое описание.

В основе бизнес-моделирования лежат бизнес-процессы. Система управления бизнес-процессами (СУБП) является фундаментом, на котором строятся другие системы управления и технологии.

Какие задачи помогает решить моделирование бизнес-процессов

1. Распределение ответственности.
Построение бизнес-модели содействует чёткому распределению ответственности между сотрудниками за каждое выполняемое ими действие в компании, исключая выборочный контроль со стороны руководителей.
2. Независимость от незаменимых сотрудников.
Кадровая текучка больше не влияет на наработанный рабочий ритм, роль и ценность ключевых сотрудников уменьшается, ценная рабочая информация не покидает пределы компании. Процессная модель позволяет формировать собственную базу знаний предприятия и минимизировать значение человеческого фактора.
3. Время адаптации новых сотрудников сокращается.
Наличие схем бизнес-процессов, где описаны последовательность действий и взаимоотношения с другими сотрудниками, поможет новому персоналу быстрее вникнуть в особенности работы и успешно завершить испытательный срок.
4. Возможности для расширения бизнеса.
С готовой процессной моделью привычная схема работы предприятия без усилий распространяется на новые филиалы и представительства.
5. Делегирование обязанностей, независимость от руководителя.
С помощью бизнес-моделирования отпадает необходимость постоянного участия собственника в делах компании.
6. Мотивация персонала.
Бизнес-моделирование – это контроль эффективности выполняемых функций, распределение за них ответственности.
7. Проведение реинжиниринга.
Зная дневную загрузку и рабочие функции каждого сотрудника, можно эффективно провести реструктуризацию предприятия, сократив или перераспределив ответственность за определенные функции и бизнес-процессы между персоналом.
8. Прозрачность, управляемость и контролируемость на всех уровнях деятельности организации.
9. Снижение издержек и времени выполнения операций.
10. Повышение лояльности и удовлетворенности клиентов, и, как следствие, репутации организации.
11. Бизнес-моделирование оказывает существенное влияние на рейтинги организации, которые присваиваются рейтинговыми агентствами, в том числе международными (Fitch, Moody’s, S&P и др.).
12. Более широкие возможности для привлечения инвесторов и улучшение финансовых показателей.
13. Более высокие шансы компании на получение долгосрочных займов.
14. Налаженная технология ведения бизнеса значительно упрощает задачу продажи готового бизнеса в случае необходимости.

Когда в моделировании процессов нет необходимости

1. Когда нечего моделировать – нет бизнес-процессов, компания недавно созданная и нет чётких представлений о её дальнейшей специализации.
2. Небольшой штат компании – до 10 человек, когда нет необходимости в жёсткой регламентации и распределении обязанностей.
3. Когда у руководства нет административных рычагов давления, чтобы внедрить нововведения.

Ссылки

  1. Моделирование бизнес-процессов на раз, два, три: ликбез для руководителей
  2. Моделирование бизнес-процессов: доступно о сложном

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

www.e-xecutive.ru

Отправить ответ

avatar
  Подписаться  
Уведомление о