Как изображать бизнес-процессы на диаграммах (рисунках), какую графическую нотацию выбрать и для чего можно использовать созданные диаграммы.
Юрий Волков
В опубликованной год назад статье “Новый взгляд на описание бизнес-процессов” (см. PC Week/RE, № 34/2005, с. 42), мы рассмотрели описание бизнес-процесса в виде текста (рассказа). Теперь самое время обсудить, как изображать бизнес-процессы на диаграммах (рисунках), какую графическую нотацию выбрать и для чего можно использовать созданные диаграммы.
Для наших последующих рассуждений важно уточнить, что мы говорим об описании не любых процессов, а именно процессов уровня бизнеса, которые:
● знакомы нашему клиенту (конечным пользователям автоматизированной информационной системы, далее называемой Системой);
● оперируют понятиями предметной области клиента (“покупатель”, “заказ”, “оплата” и т. п.).
В разряд бизнес-процессов не попадают, в частности, процессы, реализующие те или иные функции Системы на техническом уровне и включающие взаимодействие её технологических компонентов (серверов, баз данных, классов, объектов и т. д.).
Текстовое и графическое представления не нужно рассматривать как взаимоисключающие альтернативы: они дополняют друг друга.
Хочу сразу сказать, что текстовое и графическое представления не нужно рассматривать как взаимоисключающие альтернативы: они дополняют друг друга. С одной стороны, на диаграмме удаётся разместить существенно меньше информации (в том числе пояснений), чем в текстовом документе. А с другой стороны, графическое представление обладает большей наглядностью, помогает понять сложную логику и увидеть общую картину процесса.
Прежде чем обсуждать различные варианты графических описаний, нужно определиться с целями, которых мы ходим достигнуть, начиная “рисовать” процессы.
Описание бизнес-процессов как один из этапов автоматизации
Хотя описание бизнес-процессов может оказаться полезным и само по себе, в этой статье мы будем считать, что оно рано или поздно, непосредственно или в результате цепочки действий будет отражено (воплощено, реализовано) в автоматизированной системе, а участники бизнес-процесса (люди, организации, другие системы. ) станут пользователями Системы.
Примечательно, что в работе [1], сравнивавшей применяемые для этого диаграммы пять лет назад, “описание бизнес-процессов” и “разработка системы автоматизации” считались различными задачами, для решения которых бизнес-процессы описывались с помощью разных методов и диаграмм. За прошедшие годы индустрия информационных технологий не только разработала новые методы описания бизнес-процессов (и соответствующие диаграммы) и представила их в виде спецификаций, но и реализовала возможность исполнения бизнес-процесов автоматизированными системами. Сегодня имеются не только коммерческие “движки исполнения бизнес-процессов”, но и аналогичные продукты, распространяемые сообществом Open Source. Все это помогает существенно уменьшить расходы на автоматизацию и сократить сроки проектов такого рода. Для нас же в рамках темы данной статьи важно то, что формирование модели (описания) бизнес-процессов — это не конечная цель (проекта, клиента. ), а лишь очередной шаг к построению Системы, исполняющей (полностью или частично) данные бизнес-процессы.
Цели
1. Во-первых, мы хотим получить некие блок-схемы, которые можно использовать в презентациях и обсуждениях. Ими, кроме того, можно дополнять текстовые документы, описывающие процессы: те текстовые документы, которые станут основой для проектирования Системы.
К этим блок-схемам (диаграммам) мы предъявляем следующие требования.
Они должны достаточно подробно и точно описывать логику процесса — настолько, насколько это нужно для решения каждой конкретной задачи. Тем не менее мы хотим использовать одни и те же диаграммы, даже если требования к подробности и точности будут меняться.
Блок-схемы должны одинаково пониматься различными людьми, имеющими с ними дело. Это в первую очередь сотрудники предприятия (клиенты), чью работу мы описываем, а также мы сами — бизнес-аналитики, консультанты и т. п. В идеале любой человек, знакомый с использованным нами способом описания процесса (в частности, с его графической нотацией), но не обязательно знающий нас и наши предпочтения, должен правильно понимать то, что мы изобразили.
2. Во-вторых, мы хотим в результате получить нечто большее, чем просто рисунки: мы хотим построить модель процесса, на основе которой можно сгенерировать не только диаграммы, но и, например, текстовые отчёты о составе модели. Именно поэтому для описания процесса мы уже используем не карандаш и бумагу или их компьютерный аналог — графический редактор типа Adobe Photoshop, а специальные инструментальные средства моделирования. Самые популярные из них — продукты ARIS и BPWin. Не следует, однако, слишком тесно связывать способ описания процессов с конкретным продуктом (если только этот способ не является общепринятым стандартом). Более того, подобная зависимость сегодня уже является недостатком как самого способа описания бизнес-процессов, так и созданной с его помощью модели!
Так какими же качествами должна обладать модель бизнес-процесса?
● Она должна, во первых, позволять автоматически создавать отчёты о её составе (например, для оценки затрат на разработку Системы).
● Во вторых — допускать автоматическую проверку по формальным признакам: в частности, таким как полнота модели, корректность использования ее элементов, логика связей между ними.
● В третьих — обеспечивать возможность электронного обмена моделями и диаграммами (а не только “картинками”) между различными инструментальными средствами, а также передачу их в Систему.
● В четвёртых — быть достаточно полной для автоматизированного исполнения соответствующего бизнес процесса как для целей тестирования (с использованием тестовых исходных данных, внешних событий и т. п.), так и для реальной эксплуатации Системы.
● Наконец, в пятых — иметь обратную связь с Системой: при внесении в Систему изменений (в том числе уточнений), они должны автоматически отражаться в модели. В результате кардинально меняется назначение модели и жизненный цикл её использования: она продолжает “жить” и по завершении разработки Системы.
Без такой обратной связи модель постепенно все меньше соответствует своей реализации в Системе и поэтому становится неактуальной, а следовательно — ненужной. На своевременное “ручное” внесение в модель тех изменений, которым подвергается работающая Система по требованию клиента, у предприятия обычно не хватает ресурсов. И даже если такие корректировки вносятся, они могут быть неполными, содержать ошибки и т. д.
Без обратной связи модель постепенно все меньше соответствует своей реализации в Системе и поэтому становится неактуальной, а следовательно — ненужной.
Достоинство модели бизнес-процессов по сравнению с “моделями компонентов Системы” (к которым нас приучил язык UML) в том, что первая создаётся на другом, более высоком уровне абстракции и позволяет бизнес-аналитикам и клиентам непосредственно участвовать в развитии Системы во время её промышленной эксплуатации. При этом для внесения в Систему существенных с точки зрения логики бизнеса изменений клиенту уже не нужно самому быть программистом или использовать программиста в качестве переводчика его замыслов на язык машины (и наоборот, с языка машины на язык бизнеса).
Начинаем выбирать диаграммы
Наше желание использовать для описания бизнес-процессов диаграммы, одинаково понимаемые различными людьми, заставляет нас выбирать из небольшого числа наиболее популярных их разновидностей, таких как IDEF, EPC (eEPC), диаграммы деятельности UML и диаграммы BPD (Business Process Diagram), определённые спецификацией BPMN [2].
При всём моём уважении к историческому интеллектуальному наследию диаграммы IDEF и EPC (подробнее о них см. в [1]) — это продукты той эпохи, когда ещё не шла речь о непосредственном исполнении описаний бизнес-процессов Системой (аналогично тому, как компьютер исполняет текст программы). Мы полагаем, что от применения этих диаграмм следует отказаться, в первую очередь потому, что они недостаточно выразительны и точны для исполнения в Системе. Дело не в том, что Система — “тупая”, а просто на диаграмме не всё необходимое указано, а то, что указано, допускает неоднозначную трактовку.
Сферы применения BPMN и UML однозначно разделены самим разработчиком обеих спецификаций
Да, прогресс в области автоматизации исполнения бизнес-процессов столь значителен, что сегодня можно “доработать” любой тип диаграмм, добавив или уточнив всё необходимое. Можно написать некие “макросы” для экспорта описания бизнес-процесса в формат, понимаемый машиной. Но всё это будут наши собственные “заплатки”, имеющие узкое применение и низкое качество.
Прошло то время, когда спецификации описания бизнес-процессов создавались вендорами для собственных нужд. Сегодня они разрабатываются и открыто обсуждаются годами. Принятие открытых стандартов — удел международных некоммерческих организаций (консорциумов), в которые входят представители всех заинтересованных сторон. В результате рождаются документы (толстые книжки), которые читают в основном методологи и разработчики инструментальных средств моделирования. Но как раз благодаря этим “толстым книжкам” и достигается однозначность трактовки диаграмм.
Например, как отмечают специалисты (в частности, в [1]), работа по созданию модели eEPC должна регламентироваться “соглашением о моделировании”, предварительно составляемым командой проекта. Без такого соглашения ценность полученной модели будет минимальна. Если у вас возникнет вопрос: “Как правильно изобразить на диаграмме eEPC то-то или то-то”, — то по-настоящему авторитетного ответа вам не найти (если вообще вы найдёте какой-либо ответ). В результате вы строите модель в соответствии со своими представлениями о ее корректности, и без ваших комментариев она будет, мягко говоря, малоценной.
Одно время я сам удивлялся: почему после того, как команда профессионалов описала процессы и создала диаграммы, по ним невозможно реализовать работающую Систему, а необходимо повторно обходить всех “носителей знаний” о бизнес-процессах и готовить другое их описание. Причина проста: таково свойство самой нотации, в данном случае eEPC. Диаграмма eEPC — это не описание того, как работает бизнес-процесс, а декларация о том, что будет происходить, кто участвует в процессе и т. п. Я не говорю, что это не нужно делать. Более того, при описании нетривиальных бизнес-процессов необходимо создавать дополнительные документы. Например, не обойтись без тезауруса (словаря) предметной области; может понадобиться описание (в том числе в виде диаграмм) структуры организаций, участвующих в бизнес-процессах и т. д. В данном случае я просто констатирую факт “недостаточности” диаграмм eEPC.
Верхний уровень в описании процесса разрешения разногласий с помощью голосования по электронной почте в нотации BPMN — реального процесса, использовавшегося при коллективной разработке самой спецификации BPMN
Диаграммы деятельности (activity diagrams) языка UML тоже используются для описания бизнес-процессов. Хотя в самой спецификации UML эти диаграммы не оперируют деловыми понятиями, для описания бизнес-процессов энтузиасты придумали специальные расширения, называемые “профилями”. Профили по сути являются теми же соглашениями о моделировании, о которых мы говорили выше, со всеми их недостатками. (О том, почему для решения данной задачи нецелесообразно использовать диаграммы деятельности UML, см. также далее в разделе “OMG о графической нотации моделирования бизнес-процессов”.
BPMN (Business Process Modeling Notation) [2] — спецификация, содержащая графическую нотацию описания бизнес-процессов, основанную на диаграммах BPD. Она разработана организацией Business Process Management Initiative (BPMI) в 2001—2004 гг. с учётом множества ранее существовавших диаграмм (в том числе всех упомянутых выше). Основной целью данной инициативы было получить нотацию, легко понимаемую всеми пользователями — от бизнес-аналитика, создающего первые наброски описаний процессов, до технических специалистов, отвечающих за реализацию этих процессов в Системе, и менеджеров, управляющих этими процессами и контролирующих их функционирование.
Спецификация BPMN — это книга размером в триста страниц, которая содержит множество графических иллюстраций с подробными комментариями: всего около 130 рисунков! Кроме того, в документе в качестве примера приводится подробное описание реального процесса разрешения разногласий с помощью голосования по электронной почте (см. рисунок). Этот процесс применялся BPMI при создании самого стандарта.
Что касается инструментальных средств для построения BPMN-моделей, то благодаря открытости и проработанности данной спецификации создание соответствующих продуктов (чаще расширение функциональности существующих средств) ведется сегодня очень активно. Среди десятков инструментов такого рода есть и бесплатные версии программ с широким спектром возможностей — от моделирования бизнес-процессов до их исполнения Системой (например, Intalio).
OMG о графической нотации моделирования бизнес-процессов
Некоммерческая международная организация OMG (www.omg.org), являющаяся разработчиком UML, в 2005 г. взяла “под своё крыло” спецификацию BPMN, а в феврале нынешнего опубликовала ее уже как собственную, слегка подкорректировав документ, полученный от BPMI.org, и добавив в него ссылки на OMG [2].
Так вот, BPMN, согласно OMG, применяется на самом верхнем уровне — уровне бизнес-процессов, а UML — на уровне компонентов программного обеспечения (для описания интерфейсов между компонентами ПО и бизнес-сервисами).
В итоге сферы применения BPMN и UML однозначно разделены самим разработчиком обеих спецификаций. Следовательно, в частности, можно уверенно использовать спецификацию BPMN для моделирования бизнес-процессов, не боясь её вытеснения диаграммами деятельности языка UML.
OMG планирует подвести под BPMN метамодель Business Process Definition Metamodel (BPDM), оперирующую понятиями уровня бизнес-процессов, а не программного обеспечения. И только там, где есть пересечения c уже существующей метамоделью UML 2, предполагается использовать элементы этой последней в метамодели BPDM. В этом, пожалуй, и состоит очень существенное отличие диаграмм BPMN от диаграмм деятельности UML: элементы их моделей имеют разную семантику. Вот почему более корректно моделировать бизнес-процессы, используя диаграммы, обладающие соответствующим смыслом (семантикой), т. е. BPMN.
Во избежание недоразумений хотел бы отметить, что диаграммы стандарта BPMN не заменяют полностью аналогичные конструкции UML или ARIS. Они предпочтительны именно для описания бизнес-процессов (а не процессов любого типа). Следует помнить, что в реальном проекте одними диаграммами описания бизнес-процессов вам не обойтись: необходимо использовать также методологии процесса разработки (например, Extreme Programming или Rational Unified Process). Но это уже предмет отдельной статьи.
Литература
Источник: ecm-journal.ru
Как графическое описание бизнес-процессов помогает оптимизировать работу организаций
Как известно, существует несколько основных форматов описания бизнес-процессов. Наиболее распространенным и, на наш взгляд, самым «проблемным» является текстовый формат. Текстовый формат зачастую подразумевает объемный документ со сложной структурой, в котором рядовому сотруднику очень тяжело определить свои обязанности в рамках заданного процесса.
Задача
Большинство руководителей ведущих организаций в наше время старается переходить к графическому формату описания процессов, который решает большинство проблем, возникающих при выборе других форматов и выполняет следующие задачи:
- Визуализировать каждый этап процесса и наглядно обозначить ответственных за него сотрудников и их сферу ответственности (особенно актуально при проведении совещаний в формате ВКС)
- Существенно сократить объем документа, описывающего крупный массив информации
- Упростить поиск звена, ответственного за проблемы, возникающие при осуществлении описываемого процесса — Провести имитационное моделирования процесса
- Осуществлять полноценный контроль бизнес-процесса на всех этапах его выполнения
В поисках отечественного графического редактора, решающего схожие задачи, к нам обратился заказчик, ранее использующий для этого Microsoft Visio.
Решение, которое мы предложили
Графический редактор Автограф, обладающий следующими функциональными возможностями, обеспечивающими выполнение задач клиента:
- Возможность создания и редактирования схем, планов, карт и других графических документов
- Совместимость с форматом MS Visio, ранее применимым в организации у заказчика (важно, т.к. схемы, созданные ранее, можно просматривать и редактировать в предложенном нами новом решении)
- Совместимость с отечественными операционными системами
- Большое количество встроенных шаблонов схем, в том числе шаблонов таких нотаций, как BPMN, IDEF0 и прочих
- Обширный набор библиотек элементов, а также возможность загрузки внешних библиотек и создания собственных библиотек внутри программы
- Широкий графический функционал, в который включено большое количество стилей, эффектов и типовых элементов
- Полноценный текстовый редактор для добавления описаний и названий внутри схем
- Современный адаптивный интерфейс и настраиваемое рабочее пространство
Как применяется редактор после внедрения?
После внедрения в организацию заказчика, редактор нашел свое применение на всех уровнях и не только в задачах по построению бизнес-процессов, поставленных изначально, но и в эксплуатационных задачах компании (рисование схем сети и прочего оборудования). Возвращаясь к бизнес-графике, клиент получил следующие возможности:
- Создавать схемы процессов с нуля, используя шаблоны и библиотеки редактора
- Создавать схемы по бизнес-процессам, описанным ранее в другом формате, используя средства редактора
- Просматривать и редактировать схемы, созданные ранее в MS Visio
- Демонстрировать разработанные схемы на совещаниях, отправлять созданные схемы сотрудникам внутри организации
- Редактировать схемы, полученные от других сотрудников, оставлять комментарии, прикреплять внутри схем необходимые ссылки или файлы
- Сохранять схемы в просмотровые форматы, такие как pdf, png и прочие для отправки внешним источникам
- Добавлять к схемам рамки и штампы официальных документов
- Печатать схемы с настройкой размеров, цвета и прочих параметров печати
Пример использования
Со стороны руководителя
Руководитель, используя текстовый документ с описанием текущего процесса, открывает в разделе «Шаблоны», соответствующий шаблон, к примеру функциональная блоксхема. В окне редактора открывается базовый пример данной схемы, а также библиотеки элементов, необходимые для ее создания. Используя отображенные библиотеки, соединительные линии и текстовые свойства объектов руководитель средствами редактора создает схему. Далее руководитель сохраняет ее в редактируемом формате и отправляет ее менеджеру, ответственному за исполнение процесса, описанного на схеме.
Со стороны менеджера
Менеджер получает от руководителя схему, изучает ее, оставляет комментарии, при необходимости редактирует. Далее менеджер проводит совещание об ее окончательном утверждении, добавляет штамп организации и сохраняет в просмотровый формат для передачи в отделы для исполнения процесса.
Со стороны сотрудников
Исполнители получают схему в готовом виде с подробным описанием всего процесса, где наглядно видны задачи, за которые они ответственны, сроки их исполнения, а также указаны материалы, необходимые для их исполнения.
Источник: info-comp.ru
Моделирование бизнес процессов в Вusiness studio
Моделирование бизнес процессов является одним из методов улучшения качества и эффективности работы организации. В основе этого метода лежит описание процесса через различные элементы (действия, данные, события, материалы и пр.) присущие процессу. Как правило, моделирование бизнес процессов описывает логическую взаимосвязь всех элементов процесса от его начала до завершения в рамках организации. В более сложных ситуациях моделирование может включать в себя внешние по отношению к организации процессы или системы.
Моделирование бизнес процессов позволяет понять работу и провести анализ организации. Это достигается за счет того, что модели могут быть составлены по различным аспектам и уровням управления. В больших организациях моделирование бизнес процессов выполняется более подробно и многограннее, чем в малых, что связано с большим количеством кросс-функциональных связей.
Цели бизнес моделирования:
- За счет моделирования можно проследить, что происходит в процессах от начала, до завершения. Моделирование позволяет получить «внешний» взгляд на процессы и определить улучшения, которые повысят их эффективность.
- Нормирование процессов. Моделирование бизнес процессов задает правила выполнения процессов, т.е. то, каким образом они должны быть выполнены.
- Моделирование бизнес процессов устанавливает четкую связь между процессами и требованиями, которые они должны выполнять.
Моделирование бизнес процессов и реинжиниринг в Business studio можно осуществить по принципу Деминга (PDCA: Plan , Do, Control, Act)
PDCA (англ. «Plan-Do-Check-Act» — планирование-действие-проверка-корректировка) циклически повторяющийся процесс принятия решения, используемый в управлении качеством. Также известен как Deming Cycle, Shewhart cycle, Deming Wheel или Plan-Do-Study-Act. Также известен как принцип Деминга-Шухарта, но Деминг предпочитал PDSA (Plan-Do-Study-Act) у Шухарта (Plan-Do-Сheck-Act).
Организационная структура. Схема, схематически отражающая состав и иерархию подразделений предприятия. Организационная структура устанавливается исходя из целей деятельности и необходимых для достижения этих целей подразделений, выполняющих функции, составляющие бизнес-процессы организации.
Стратегическая карта. Цели, поставленные собственником бизнеса, являются отправной точкой для разработки бизнес-стратегии организации. В стратегии выбираются виды деятельности, рынки и формулируются те ключевые конкурентные преимущества, за счет которых компания должна добиться успеха.
Стратегия может быть успешно реализована только тогда, когда ее понимают сотрудники компании. Описывая стратегию развития бизнеса в более или менее упорядоченной форме, мы повышаем вероятность ее успешной реализации. Разработанная Робертом Капланом и Дейвидом Нортоном система показателей (Balanced ScoreCard, BSC ) является лучшим инструментом представления процесса реализации стратегии в понятной форме. Balanced ScoreCard (Сбалансированная система показателей) – это система стратегического управления компанией на основе измерения и оценки ее эффективности по набору оптимально подобранных показателей, отражающих все аспекты деятельности организации, как финансовые, так и нефинансовые.
Определив и формализовав стратегию, можно перейти к созданию модели бизнес-процессов компании. То есть определить ту деятельность, которую компания должна осуществлять для реализации стратегии и достижения поставленных целей.
Business Studio позволяет построить как комплексную иерархическую модель деятельности компании, так и описать ряд отдельных процессов. Для этого в распоряжение бизнес-аналитика предоставляются наиболее популярные и удобные нотации моделирования: IDEF0, Процедура (Cross Functional Flowchart), BPMN 2.0, Процесс (Basic Flowchart), EPC (Event Driven Process Chain). После описания модели бизнес-процессов «как есть» или проектирования новых бизнес-процессов можно оценить время и стоимость выполнения процессов.
а) Нотацию IDEF0 целесообразно использовать для построения иерархической модели бизнес-процессов верхнего уровня.
IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (поток работ).
Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того есть правило стороны:
стрелка входа приходит всегда в левую кромку активности,
стрелка управления — в верхнюю кромку,
стрелка механизма — нижняя кромка,
стрелка выхода — правая кромка.
Данный стандарт был разработал в 1981 году департаментом Военно-воздушных сил США в рамках программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Набор стандартов IDEF унаследовал своё название от этой программы (IDEF расшифровывается как ICAM Definition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах
б) Нотации процедура, BPMN 2.0, Процесс и EPC можно использовать для моделирования процессов нижнего (операционного) уровня. Business Studio позволяет менять нотацию моделирования при переходе с описания процессов верхнего уровня к описанию процессов нижнего уровня.
Для процесса можно определить: Владельца процесса, Исполнителей процесса, требования к срокам выполнения, используемые документы и ряд других параметров. Сочетание наглядных графических нотаций и параметров процессов обеспечивает необходимую полноту описания бизнес-процессов и позволяет выпустить действительно полезную регламентирующую документацию.
Нотация BPMN описывает условные обозначения для отображения бизнес-процессов в виде диаграмм бизнес-процессов. BPMN ориентирована как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Кроме того, спецификация BPMN определяет, как диаграммы, описывающие бизнес-процесс, могут быть трансформированы в исполняемые модели на языке BPEL. Спецификация BPMN 2.0 также является исполняемой и переносимой (то есть процесс, нарисованный в одном редакторе от одного производителя, может быть исполнен на движке бизнес-процессов совершенно другого производителя, при условии, если они поддерживают BPMN 2.0).
Модель «Расширенная нотация описания цепочки процесса, управляемого событиями» — Extended Event Driven Process Chain (Eepc). Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. Это тип блок-схем, используемых для бизнес-моделирования. EPC может быть использована для настройки системы планирования ресурсов предприятия (ERP), и для улучшений бизнес-процессов. Подробнее про EPC можно почитать тут
Имитацию бизнес процесса «as is» можно произвести с помощью функционально-стоимостного анализа и имитационного моделирования средствами business studio.
- Имитационное моделирование – метод исследования, позволяющий проанализировать систему, не изменяя ее. Это возможно благодаря тому, что изучаемая система заменяется имитирующей. Эксперименты проводятся с имитирующей системой, при этом полученная в результате информация характеризует изучаемую систему. Говоря об анализе деятельности компании, метод позволяет сымитировать выполнение модели бизнес-процессов так, как оно происходило бы в действительности, и получить реальную оценку длительности каждого процесса.
- Функционально-стоимостной анализ – инструмент, предназначенный для оценки себестоимости продукта (услуги). Проведение функционально-стоимостного анализа позволяет получить оценку себестоимости через управление процессами, направленными на производство продукта или оказание услуги. В этом состоит отличие метода функционально-стоимостного анализа бизнес-процессов от традиционных финансовых методов учета затрат, в рамках которых деятельность компании оценивается по функциональным операциям, а не по конкретным продуктам (услугам), предоставляемым заказчику. В основе функционально-стоимостного анализа лежит следующее положение: для производства продукта (услуги) необходимо выполнить ряд процессов, затратив при этом определенные ресурсы. Расходы на выполнение процесса рассчитываются путем переноса стоимости ресурсов на стоимость шагов процесса. Сумма расходов на выполнение всех процессов, с определенными поправками, и составляет себестоимость продукта (услуги). Если традиционные методы вычисляют затраты на некоторый вид деятельности лишь по категориям расходов, то функционально-стоимостной анализ показывает стоимость выполнения всех шагов процесса. Таким образом, методика функционально-стоимостного анализа позволяет наиболее точно определить затраты на производство продуктов (оказание услуг), а также предоставляет информацию для анализа бизнес-процессов и их улучшения.
Этапы выполнения имитации:
- задание временных параметров конечных (недекомпозированных) процессов
- задание параметров ресурсов, необходимых для выполнения этих процессов
Ресурсы подразделяются на временные и материальные. Стоимость временного ресурса переносится на стоимость процесса пропорционально тому времени, которое ресурс затрачивает на выполнение процесса, стоимость материального ресурса – пропорционально количеству повторений процесса. - назначение ресурсов на процессы
- проведение имитации выполнения процессов
Например, у нас получилось имитация бизнес процесса «Тестирование» с функционально-стоимостным анализом
Демо-версия Business Studio предоставляет возможность познакомиться с возможностями продукта, смоделировав свои бизнес-процессы или посмотрев пример описания модели деятельности компании «Интехпроект». Демо-версия не имеет ограничений по сроку использования, а ее возможностей достаточно, чтобы описать и регламентировать деятельность небольшой компании или отдельного подразделения. (В демо-версии нельзя получить текстовый отчет по результатам имитации.
Применение Business Studio переводит процесс создания системы управления компании из разряда эксклюзивного и непредсказуемого творчества в будничное проектирование по логичным законам бизнеса, позволяет получить конкретные результаты в обоснованные сроки и за определенную цену. Кроме того, система не является инструментом разового применения – с ее помощью поддерживается дальнейшее существование и развитие бизнеса в целом.
Именно поэтому со времени своего появления в 2004 году система бизнес-моделирования Business Studio получила широкое распространение среди компаний России и других стран. Группа компаний «Современные технологии управления» не только постоянно совершенствует систему, но и содействует появлению молодых специалистов в области управления. Более 30 высших учебных заведений стали партнерами и используют Business Studio в своих учебных программах.
Источник: businessarchitecture.ru