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

Содержание

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

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

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

Для начала нужно разобраться с основными понятиями.

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

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

Моделирование бизнес-процесса — это процедура создания модели или ее анализ, если процесс уже описан.

Нотация (метод, методология) моделирования бизнес-процессов — это совокупность принципов и стандартов описания: как именно мы будем описывать процесс, какие условные обозначения для элементов будем применять, правила чтения моделей и их элементов. Нотаций придумали много: VAD, TPC, BPMN, IDEF и другие, но мы не будем их рассматривать в рамках этой статьи 🙂

Подходы к моделированию бизнес-процессов

Существует множество методологий моделирования и по принципам работы их все можно «уложить» в три подхода:

  1. Функциональный. Когда бизнес-процесс описывается, как некая функция, имеющая входные данные и конечный результат. Например, процесс доставки начинается, когда заказ сформирован и готов к отправке по адресу (это входные данные) и заканчивается вручением заказа клиенту или сбором обратной связи по качеству обслуживания (конечный результат). То есть функциональное моделирование обращает внимание на то, что мы хотим получить в результате — без погружения во внутренние процедуры.
  2. Процессный. Когда бизнес-процесс рассматривается как совокупность действий, приводящих к результату. То есть в отличие от функционального подхода здесь мы обращаем внимание на то, как именно мы будем добиваться желаемого результата. Если взять тот же пример с доставкой, то процесс начинается с готовности заказа, далее в мелочах описываются промежуточные операции (формирование маршрутных листов, созвон с заказчиком, вручение пакета и т.д.), участники (водитель, диспетчер), документация (накладная, чек и т.д.) и конечный результат (сбор обратной связи по качеству обслуживания).
  3. Ментальный. Когда бизнес-процесс представляется как совокупность связанных между собой понятий и характеристик. Описание происходит в свободной форме и оформляется в виде ментальной карты. Ментальное моделирование часто используют, чтобы «на пальцах» показать сущность процесса человеку, далекому от методов моделирования, или для себя, чтобы «разложить по полочкам» информацию, увидеть недостатки, найти решение.

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

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

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

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

  1. Текстовый. Когда процесс описывают словами на бумаге или в текстовом редакторе. Часто это произвольное неструктурированное изложение мыслей, которое может занимать десятки страниц. Удобно тем, что не нужно особых знаний, навыков и подготовки. Но результат — громоздкий текст, в котором сложно разобраться другому человеку.
  2. Табличный. Данные заносятся в таблицу (рукописную или электронную). Здесь уже информация выглядит более структурировано. Но и здесь нет наглядности: объемные таблицы невозможно увидеть целиком, нельзя отразить ответвления.
  3. Графический. Когда процесс представлен в виде блок-схемы, на которой видны мельчайшие вариации действий, есть текстовые пояснения к элементам, отражен порядок операций. Схему можно нарисовать от руки на бумаге или любом графическом редакторе.

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

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

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

Visual Paradigm

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

Здесь можно:

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

Есть версии под Windows и Mac OS.

Недостатки: программа платная.

BizAgi Modeler

Бесплатная программа, которую легко освоить новичкам и удобно использовать уже опытным проектировщикам. Можно использоваться как самостоятельное приложение, а можно — в составе комплекса BizAgi Suite, в котором реализованы просто безграничные возможности моделирования вплоть до создания готового приложения, чтобы сотрудники могли управлять процессом.

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

Здесь можно:

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

Недостатки: при большом количестве элементов блоки и стрелки могут смещаться и «наползать» друг на друга.

ARIS Express

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

Здесь можно:

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

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

Gliffy

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

Здесь можно:

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

Недостатки: программа платная, в бесплатной версии функционал ограничен.

BPsimulator

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

Здесь можно:

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

Недостатки: программа платная, в бесплатной версии есть реклама.

Draw io

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

Здесь можно:

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

Недостатки: нельзя работать коллективно.

Рекомендация в заключение

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

Хочешь получать еще больше полезных материалов, информацию о бесплатных вебинарах, скидках и новых курсах Like Центра?
Оставь свой email 😉

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

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

В блоге в свободном доступе находится информация, которая помогает:

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

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

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

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

Вам будет интересно  Что такое CRM интеграторы

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

Like Centre blog — это база знаний, позволяющая рассмотреть проблемы комплексно, оперативно их выявить и решить. А для тех, кто готов продвинуться дальше, Лайк Центр готов оказать помощь в ведении бизнеса в Москве и любом другом регионе России.

В блоге мы много рассказываем об этом, но лучше один раз попробовать самостоятельно. За 3 дня мы дадим все инструменты, чтобы начать. Четко, структурировано. Ничего лишнего.

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

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

Начало начал

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Этап второй —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Этап пятый — , рабочие группы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Проектирование бизнес-процессов

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

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

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

    С чего начать проектирование бизнес-процессов

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

    Обследование и сбор данных во внешних источниках.

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

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

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

    Модель структуры бизнес-процессов

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

    Процессы реализации (жизненного цикла) продукции:

    Разработка миссии и стратегии организации.

    Разработка и производство продукции и услуг.

    Организация продаж (сбыта) продукции и услуг.

    Поставка продукции и услуг потребителям.

    Управление обслуживанием потребителей.

    Управленческие и обеспечивающие процессы:

    Планирование и управление человеческими ресурсами.

    Управление информационными технологиями.

    Управление финансовыми ресурсами.

    Приобретение, сооружение и управление собственностью.

    Управление охраной окружающей среды, безопасностью и охраной труда (EHS Management).

    Управление внешними связями (PR).

    Управление знаниями, улучшениями и изменениями (Knowledge and Innovation Management).

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

    При этом для каждого бизнес-процесса должны быть определены:

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

    Входы процесса. Перечень необходимых исходных материальных ресурсов и иных исходных данных и источников их поставки.

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

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

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

    Критерии результативности бизнес-процесса.

    Запомнить

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

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

    Инструменты моделирования и управления бизнес процессамиАвтор: Игорь Алешин Эксперт по управлению бизнес-процессами, преподаватель РШУ

    Источник https://blog.likecentre.ru/razvitie-biznesa/instrumenty-modelirovaniya-i-upravleniya-biznes-processami/

    Источник https://www.businessstudio.ru/articles/article/likbez_dlya_rukovoditeley_modelirovanie_biznes_pro/

    Источник https://uprav.ru/blog/proektirovanie-biznes-protsessov/

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Предыдущая статья В каком банке выгоднее всего брать ипотеку
Следующая статья Как начать участвовать в закупках?