Основы моделирования деятельности организации

Введение

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

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

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

Рис. 1. Структурная диаграмма деятельности организации

На рисунке 1 мы сформировали структурную модель деятельности организации ООО «ВекторПлюс» с использованием программного продукта АСПРА Старт, которая включает в себя все вышеперечисленные домены.

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

Практический пример от нашего партнера ООО Дайнова Консалтинг: «Один из клиентов обратился к нам с просьбой помочь им сформировать модель деятельности сервисной организации, классифицировать в ней перечень услуг и процессов, провести анализ и привязку каждой услуги к бизнес-процессу, ее производящему. Данная компания является мульти-сервисной организацией с большим количеством услуг. Ей необходим инструмент, позволяющий отслеживать какой бизнес-процесс оказывает какую услугу, для своевременного управления жизненным циклом изменения услуг в зависимости от ситуации на рынке. По результатам проекта была сформирована модель деятельности сервисной организации. Проведена работа по анализу модели, по результатам которой около 25% услуг были унифицированы. Также часть бизнес-процессов были пересмотрены. Количество процессов сократилось на 16%. В данном проекте мы работали с доменами деятельности организации: Организация, Услуги, Бизнес-процессы, Функции.»

Организационная структура

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

Организационные структуры обычно изображаются в виде диаграмм, где показываются имеющиеся организационные единицы и их взаимозависимости в соответствии с выбранными критериями структурирования. На рисунке 2 представлена организационная диаграмма предприятия ООО «ВекторПлюс», разработанная в программном продукте АСПРА Старт.

Рис. 2. Организационная структура

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

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

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

Дерево функций

Функции могут быть описаны с различными уровнями детализации. На самом верхнем уровне описываются наиболее сложные функции, представляющие собой функции подразделений или последовательности бизнес-процессов. Затем они разбиваются на функции, которые делятся на подфункции и т. д. до элементарных функций. Обычно, элементарной считается функция, которую выполняет один исполнитель, то есть в ней нет разделения зоны ответственности. Последовательная детализация функций образует иерархическую структуру. Диаграмма дерева функций – это многоуровневое представление функций на основе выбранного способа декомпозиции. Диаграмма дерева функций организации ООО «ВекторПлюс», разработанная в АСПРА Старт, представлена на рисунке 3.

Рис. 3. Дерево функций организации

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

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

Дерево продуктов и услуг

От модели организационной структуры и дерева функций перейдем к дереву продуктов/услуг. Данная диаграмма описывает множество продуктов/услуг для внешнего относительно организации потребителя, то есть клиента. На диаграмме обычно представлен перечень продуктов/услуг, а также, если требуется, их заместители. Диаграмма используются для ранжирования и выделения основных продуктов/услуг предприятия и дальнейшего выстраивания основной деятельности в соответствии с приоритетными продуктами/услугами. Диаграмма дерева продуктов и услуг ООО «ВекторПлюс», разработанная в АСПРА Старт, представлена на рисунке 4.

Рис. 4. Дерево продуктов/услуг

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

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

Процессы верхнего уровня

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

Рис. 5. Диаграмма процессов верхнего уровня

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

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

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

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

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

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

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

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

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

Бизнес-процессы на уровне рабочих мест

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

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

Рис. 6. Диаграмма процесса уровня рабочих мест

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

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

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

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

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

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

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

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

Практический совет от нашего партнера ООО Дайнова Консалтинг: «В проектах по моделированию деятельности организации всегда старайтесь изначально закладывать возможность повторного использования объектов исполнителей в разных бизнес-процессах. Например, если одна информационная система ИСУ «Мотив» выполняет функции в 23 процессах и имеет с ними явную связь, тогда все эти функции можно собрать в одном месте и определить функциональность данной системы. Аналогично, в случае рассмотрения всех функций, выполняемых какой-либо должностью, можно определить ее функциональные обязанности.»

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

Правила ветвления\слияния – логические операторы, которые регулируют бизнес-логику исполнения потока работ. Это, по сути, триггеры, которые в зависимости от условий направляют цепочку исполнения по тому либо иному пути.

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

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

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

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

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

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