Это разработка моделей новой организации бизнес процессов

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

Содержание:

• Зачем нужно строить модель бизнес-процессов?
• Построение модели бизнес-процессов фирмы
• Создание структурной модели и разработка моделей бизнеса
• Детальное моделирование бизнес процессов

Зачем нужно строить модель бизнес-процессов?

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

Чаще всего решение построить модель бизнес-процессов принимается по следующим причинам:

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

Построение модели бизнес-процессов фирмы

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

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

Любая модель бизнес-процесса содержит следующие данные:

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

Выделяют два этапа моделирования: структурное и детальное.

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

На первом этапе разработки модели нужно отразить:

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

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

Детальное моделирование бизнес процессов

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

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

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

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

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

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

• обратный инжиниринг;
• прямой инжиниринг.

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

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

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

Реинжиниринговый проект: алгоритм его разработки и реализации

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

Этап 1. Разработка образа будущего бизнеса предприятия и схематичная проработка его будущей конкурентной стратегии

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

Этап 2. Анализ бизнес-процессов в рамках существующей конкурентной стратегии предприятия

Этот этап связан с проведением совокупности аналитических мероприятий в рамках обратного инжиниринга существующей конкурентной стратегии предприятия. На этом этапе выполняется качественная и количественная оценка существующих бизнес-процессов предприятия. Для этого, во-первых, выполняется анализ сильных и слабых сторон предприятия, угроз и возможностей его деятельности. Для проведения такого анализа в стратегическом менеджменте рекомендуется использовать методы SWOT-анализа, PEST-анализа, SNW-анализа и ряд других специальных методов, включая системный анализ деятельности предприятия. Во-вторых, выполняется оценка организационной структуры управления предприятия, включая оценку его инновационного, производственного и интеллектуального потенциала. Для объективной оценки этих параметров необходимо выполнить:

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

Этап 3. Разработка модели новой конкурентной стратегии и моделирование новых бизнес-процессов предприятия

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

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

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

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

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

Этап 4. Реализация разработанной конкурентной стратегии и внедрение на предприятии новых бизнес-процессов

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

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

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

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

Начало начал

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Январь 2013 г.

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

Глоссарий

Проектирование системы управления здоровьем предприятия с использованием процессного подхода в Business Studio

Расчет себестоимости бизнес-процессов на примере проекта «Национального расчетного депозитария»

Конференция «Системная практика управления бизнес-процессами»: вопросы и ответы. Часть 2.

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

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

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

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

Цели

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

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

Условно, моделирование всех бизнес-процессов можно подразделить на 3 основных этапа:

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

В 1990 М. Хаммер и Д. Чампи выпускают “Реинжиниринг корпорации: манифест революции в бизнесе”, которая до сих пор изучается во всех ведущих бизнес-школах мира. Рождается новый подход к моделированию. С этого момента строится две модели: одна описывает существующие процессы, вторая — оптимальные (как должно быть). Продолжаются работы по автоматизации. Основная задача — моделирование нестандартных бизнес-процессов, для чего требуется привлекать программистов и вкладывать средства. Если хотите подробнее узнать о реинжиниринге – читайте эту статью.

2000 гг. ознаменовались появлением работы Г. Смита и П. Фингара “Управление бизнес-процессами: третья волна”. Новый подход предполагает разработку инструментов, которые дадут возможность менеджерам предприятий не только вносить корректировки в схемы бизнес-процессов, но и самим их создавать.

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

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

Работа по моделированию бизнес-процессов включает в себя 5 этапов:

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

Виды

Поскольку анализ схем, состоящих из большого числа элементов, затруднен, принято строить несколько моделей по видам:

• Функциональное моделирование – описывает взаимосвязанные функции.
• Объектное – описывает взаимосвязи и взаимозависимости между собой объектов (персонала, ресурсов и других компонентов).
• Имитационное – описывает варианты развития бизнес-процессов компании в различных условиях.

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

Основных принципов пять:

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

Информационной достаточности. Моделирование реальных бизнес-процессов компании должно базироваться на реальных данных. Эффективность работы зависит от точности и полноты исходной информации.

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

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

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Методы моделирования

Методов построения моделей довольно много, среди них:

IDEF — построенная на основе методологии SADT модель состоит из графических схем, облегчающих анализ системы.

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

Flow Chart Diagram — метод моделирования бизнес-процессов посредством символов. Отличается гибкостью.

Сети Петри – показывают динамику изменения процессов.

Инструменты

• AllFusion Process Modeler. Позволяет строить модели и производить анализ с использованием стандартных инструментов IDEF0, DFD и пр.
• ELMA BPM. Позволяет отслеживать выполнение процессов в реальном времени. Для построения моделей используется нотация BPMN 2.0.
• Draw io. Сервис позволяет строить огромное количество диаграмм и имеет большой набор элементов. Возможно связывать модели через гиперссылки. Кроме того, можно к элементам присоединять файлы из облачных хранилищ данных.

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

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

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

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

Если работа проведена правильно, на выходе компания получит:

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Автор: Марина Ступакова, эксперт компании iTeam

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

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

Что такое моделирование

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

Когда и для чего требуется моделирование

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

Ситуации, когда благодаря моделированию можно решить многие проблемы компании:

1. Нормативные документы, используемые в компании, противоречивы или давно утратили актуальность, взаимодействие между подразделениями и отдельными сотрудниками не регламентированы, из-за чего часто функции дублируются и тратится много времени впустую.
2. Дедлайны по задачам постоянно срываются.
3. Проблемы с клиентами не решаются.
4. При согласовании задействуется слишком много людей, решения принимаются долго, из-за чего растут непроизводственные расходы, страдает дисциплина, а контроль решений по отдельным вопросам плохо налажен.
5. Есть серьезные проблемы с документооборотом — документы теряются, их сложно найти.
6. Отсутствует четкое распределение ответственности и должностных обязанностей между сотрудниками.
7. Руководству сложно получить точные данные по текущим делам, так как информация неактуальная и устаревшая.
8. Для инвесторов деятельность предприятия непрозрачна.

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

Если выстроить бизнес-процессы правильно, вы получите прекрасный результат:

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

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

Этапы моделирования

Для создания эффективной модели необходимо пройти минимум 5 стадий моделирования бизнес-процессов:

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

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

Пример моделирования БП

Рассмотрим наглядно, как можно описать и смоделировать процесс:

1. Задаем точки входа и выхода. Вход — первое событие в бизнес-процессе, выход — полученный результат. Так мы очерчиваем границы, а затем начинаем наполнять процесс действиями.
2. Описываем элементы, входящие в процесс. В каждом файле нужно описать:
   • для чего нужен этот процесс и как он формируется;
   • показатели эффективности или параметры, по которым можно отслеживать результаты;
   • кто выступает исполнителем процессов, какие существуют ограничения по срокам;
   • детали всех процессов.
3. Конкретизируем основные этапы бизнес-процессов. Опираясь на данные, описанные во втором пункте, составляем блок-схему модели.
4. Разбавляем каркас деталями. Указываем основные факты и события по процессу, а также прописываем действия для каждого исполнителя.
5. Назначаем роли. Один процесс может включать несколько ролей. Их выполняет один или несколько специалистов.
6. Указываем в схеме ресурсы. Нужно отметить источники ресурсов, необходимых, чтобы реализовать процесс. Это могут быть документы, которые нужно отправить на определенном этапе. Чтобы описать процесс, нужны схемы и алгоритмы, позволяющие сделать процессы более продуктивными и эффективными для бизнеса. Также, имея на руках готовую модель БП, намного проще перейти к автоматизации процессов.

Принципы моделирования

При моделировании бизнес-процессов советуем ориентироваться на 5 основных принципов:

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

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

Виды моделей БП

Строят бизнес-процессы по одной из следующих моделей:

1. Нормативные документы, используемые в компании, противоречивы или давно утратили актуальность, взаимодействие между подразделениями и отдельными сотрудниками не регламентированы, из-за чего часто функции дублируются и тратится много времени впустую.
2. Объективная. Работы по моделированию сводятся к описанию взаимозависимости между отдельными объектами (ресурсами компаниями, сотрудниками).
3. Функциональная. При моделировании по этой методике проводится описание взаимосвязей между отдельными функциями. Функциональный подход предполагает описание функций, связанных с информационными и материальными объектами, а также используемыми ресурсами.
4. Имитационная. При моделировании описывают возможные варианты развития БП при разных сценариях.

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

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

Для построения моделей бизнес-процессов используют разные методы или инструменты. Среди основных:

• VAD — нотация для создания модели общего вида процессов, которые нужны для получения товара или предоставления услуги.
• BPMN — в этом случае процесс пошагово проектируется от начала и до конца. Отображается в виде схемы. Может использоваться для презентации информационных потоков или последовательности операций.
• Схема работы — нотация презентации процессов в формате логической последовательности действий.
• Схема данных — нотация отображения передачи данных внутри одного или нескольких процессов.
• IDEF — это категория методов по стандарту от IDEF0 до IDEF14. Стандарты создания модели ориентирован на разные задачи.
• EPC — нотация проектирования процессов нижнего уровня, где для каждой функции есть информационные потоки, материальные ресурсы, стартовые/финишные точки.
• Схема ролей — метод проектирования взаимосвязи ролей и их функций.

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

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

Условно такие продукты можно разделить на три категории:

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

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

Кто руководит процессом

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

В качестве примера рассмотрим, кто может руководить моделированием БП в компании:

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

Если вам нужна помощь с моделированием бизнес-процессов, вы можете доверить эту задачу экспертам компании «КСК ТЕХНОЛОГИИ».

Как избежать типичных ошибок

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

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

Чтобы упростить задачу по моделированию бизнес-процессов и не допустить типичных ошибок, используйте проверенный инструмент — готовые решения для автоматизации бизнеса. Одно из таких решений представляет и компания «КСК ТЕХНОЛОГИИ».

Решение от «КСК ТЕХНОЛОГИИ»

Компания «КСК ТЕХНОЛОГИИ» разработала продукт, который поможет в моделировании, исполнении и улучшении бизнес-процессов — «КСК. ИК» на базе low-code платформы класса ВРМ. Мы предлагаем рабочий инструмент для цифровой трансформации с нотациями моделирования бизнес-процессов BPMN — воспользуйтесь готовыми алгоритмами и выведите свой бизнес на новый уровень.

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

Функционал дизайн-студии low-code позволяет проектировать и моделировать бизнес-процессы, настраивать исполнителей, структуру файлов, интерактивные формы и предметную область БП.

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

Используя решение от «КСК ТЕХНОЛОГИИ» при моделировании и автоматизации БП, вы получите следующие результаты:

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

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

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

Этапы
прямого реинжиниринга.

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

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

Реальная
Модель нового бизнеса включает в себя:

• Описание
  внешних процессов предприятия

• Организационную
  модель предприятия (структуру)

• Матрицу
  “Внешние процессы(функции) — структурные
  подразделения” (рис 3)

• Структурно-
  функциональную модель внешних и
  внутренних процессов предприятия в
  идеологии IDEF0

• Матрицы
  “Внутренние процессы(операции,
  функции)-структурные подразделения
  (конкретные исполнители)”

• Описание
  методов стимулирования труда сотрудников

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

Характеристики
модели, которые нас интересуют

Рис.10.
Процесс декомпозиции модели.

1. Разработка
   технического задания на разработку
   информационной системы.

Техническое задание
(далее просто ТЗ) является основным
документом, определяющим требования и
порядок создания автоматизированной
системы. ТЗ на создание автоматизированной
системы (далее АС) описано в ГОСТ 34.602 –
89.

Первый
раздел ГОСТ отведен под общие положения.
В нем описывается предназначение ТЗ, а
общие замечания по разработке и составу
ТЗ.

Во втором разделе
ГОСТ описывается состав и содержание
ТЗ на АС. Здесь рассматривается внутреннее
содержание разделов ГОСТ.

Разделы
ТЗ (примерно по ГОСТ 34.602 – 89 )

«Общие
сведения»

Данный
раздел содержит такие общие сведения
как наименование системы, наименование
предприятия разработчика, плановые
сроки проведения работ, сведения о
порядке их финансирования и т.п.

«Назначение
и цели создания (развития) системы»

Данный
раздел содержит два подраздела:

«Назначение
системы» — здесь указывается вид
автоматизируемой деятельности и перечень
объектов, на которых предполагается
использовать систему.

«Цели
создания системы» – указываются
наименования и требуемые значения
показателей объекта автоматизации,
которые должны быть достигнуты в
результате создания АС.

«Характеристики
объекта автоматизации»

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

«Требования
к системе»

Содержит
подразделы:

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

«Требования
к процессам (функциям) системы»

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

Требования
к процессам взаимодействия пользователей
с СВР в рамках автоматизируемых
процессов(интерфейсы)

Требования
к формам отчетов

Требования
по быстродействию

Требования
по защите информации

Требования
по топологии размещения пользователей

«Требования
к видам обеспечения» – описание
требований (в зависимости от вида
системы) к математическому, информационному,
организационному, программному,
техническому и другим видам обеспечения
системы.

Варианты
аппаратных платформ и ОС, на которых
должна функционировать новая КИС

Требования
к составу и объемам хранимых данных

Требования
по восстановлению системы при возникновении
сбоев и отказов

Требования
к настройкам

Требования
по интерфейсу с существующими смежными
системами

Требования
к автоматическим средствам контроля
за действиями персонала

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

«Состав
и содержание работ по созданию (развитию)
системы»

Данный
раздел должен содержать перечень стадий
и этапов работ в соответствии с ГОСТ
24.601, перечень организаций – исполнителей
работ; ссылки на документы, подтверждающие
согласие данных организаций на проведение
работ.

«Порядок
контроля и приемки системы»

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

«Требования
к составу и содержанию работ по подготовке
объекта автоматизации к вводу системы
в действие»

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

«Требования
к документированию»

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

«Источники
разработки»

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

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

В
последнем разделе ГОСТ описываются
правила оформления ТЗ на АС, требования
к нумерации страниц, к оформлению
титульного листа и дополнений к ТЗ на
АС.

Требования
к технологии обучения, сопровождения
, внедрения и разработки.

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

• Требования
  к квалификации пользователей и
  обслуживающего персонала

• Требования
  к документации и системе поддержки
  обучения персонала

• Требования
  к процессу перехода на новое программное
  обеспечение

• Требования
  к технологии разработки и модификации
  системы.

Стоимость,
очередность, сроки.

• Ограничения
  по стоимости разработки, дополнительно
  приобретаемого ПО и оборудования

• Очередность
  и сроки разработки и внедрения системы

1. Методология
   функционального моделирования IDEF0.

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

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

IDEF1X.
Эта методология поддерживается семейством
средств проектирования базы данных
Logic Works Erwin (в данное время Platinum
ERwin).

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

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

Рис.19.
Функциональный блок стандарта IDEF0.

Взаимодействие
функциональных блоков.

1. Передача
   информации от одной функции к другой
   для дальнейшего преобразования.

2. Выработка
   одним блоком управляющего воздействия
   для других блоков.

3. Выработка
   одним блоком ресурсов и средств для
   других блоков.

1. Система
   BPwin
   поддержки проектирования в стандарте
   IDEF0.

В
системе BPwin
возможно построение модели в стандарте
IDEF0.
В данной системе модель представляет
собой совокупность иерархически
выстроенных диаграмм, каждая из которых
является описанием какого-либо процесса
(activity). Построение модели начинается с
описания функциональности моделируемой
системы в целом (контекстная диаграмма)
– см. рис.20.

Рис.20.
Контекстная диаграмма.

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

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

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

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

Рис.21.Диаграмма
декомпозиции.

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

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

Кроме
методологии IDEF0 BPwinподдерживает методологии DFD и IDEF3 и тесно
интегрируется с другими программными
продуктами:

• с широко известным
  инструментом моделирования данных
  ERwin (Platinum Technology inc.);

• системой
  управления и хранения проектов ModelMart
  (Platinum Technology inc.) ;

• специализированным
  генератором отчетов по модели RPTwin
  (Platinum Technology inc.) ;

• системой
  имитационного
  моделирования
  BPSimulator (System Modeling Corporation) ;

• инструментом
  стоимостного анализа EasyABC (ABC Technologies).

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

Диаграммы
потоков данных (Data flow diagramming, DFD) используются
для описания документооборота и обработки
информации. Подобно IDEF0, DFD представляет
модельную систему как сеть связанных
меж собой работ. Их можно использовать
как дополнение к модели IDEF0 для более
наглядного отображения текущих операций
документооборота в корпоративных
системах обработки информации. DFD
описывают функции обработки информации,
документы, объекты, а также сотрудников
или отделы, которые участвуют в обработке
информации. Синтаксис DFD включает помимо
работ и стрелок дополнительные элементы:
внешнюю сущность, которая служит для
изображения внешних по отношению к
проектируемой системе объектов,
(например, клиент, отдел кадров,
справочники) и хранилище данных — «склад»
информационных объектов. Хранилищем
данных может быть база данных, файл или
архив бумажных документов. Хранилище
данных – это как бы “замороженные”
данные, позволяющие отобразить отсрочку
в передаче объектов и информации от
одной работы к другой.

Рис.22.
Диаграмма потоков данных (DFD).

Наличие в
диаграммах DFD элементов для описания
источников, приемников и хранилищ данных
позволяет более эффективно и наглядно
описать процесс документооборота.
Однако, для описания логики взаимодействия
информационных потоков более подходит
IDEF3, называемая также workflow diagramming, —
методология моделирования, использующая
графическое описание информационных
потоков, взаимоотношений между процессами
обработки информации и объектов,
являющихся частью этих процессов.
Перекресток – специфический для IDEF3
элемент – позволяет описать
последовательность выполнения работ,
очередность их запуска и завершения. С
помощью диаграмм Workflow можно описывать
сценарии действий сотрудников организации,
например, последовательность обработки
заказа или события, которые необходимо
обработать за конечное время. Каждый
сценарий сопровождается описанием
процесса и может быть использован для
документирования каждой функции,
моделируемой в методологии IDEF0. Если в
одной модели необходимо осветить
специфические стороны бизнес-процессов
предприятия, BPwin позволяет переключиться
на любой ветви модели с IDEF0 на нотацию
IDEF3 или DFD и создать смешанную модель.
BPwin имеет мощный инструмент навигации
— Model Explorer, который позволяет представить
смешанную модель в виде дерева диаграмм
и существенно облегчает навигацию по
модели. В версии BPwin 2.5 с помощью Model
Explorer можно методом Drag&Drop переносить
и копировать работы вместе со всеми
соответствующими стрелками как внутри
модели так и между моделями. Работы
IDEF0 показываются в Model Explorer зеленым
цветом, DFD – желтым и IDEF3 – синим.

Рис.23.
Смешанная модель в Model
Explorer.

BPwin позволяет
эффективно манипулировать моделями —
сливать и расщеплять, документировать
посредством генерации отчетов (всего
7 типов отчетов, поддерживаются
запоминаемые определяемые пользователем
стандартные отчеты) и т.д. BPwin в состоянии
поддерживать синтаксис IDEF0, IDEF3 и DFD.
Частично ошибки анализируются на этапе
внесения новых объектов (некоторые
ошибочные элементы просто невозможно
внести в диаграмму), частично –
детектируются в специальном отчете —
Model Consistency Report.

Обычно в целях
реорганизации предприятия сначала
строится функциональная модель
существующей организации работы -“AS-IS”
(как есть). На основе модели “AS-IS”
достигается консенсус между различными
единицами бизнеса по тому, “кто что
сделал”, и что каждая единица бизнеса
добавляет в процесс. Модель “AS-IS”
позволяет выяснить “что мы делаем
сегодня” перед тем, как перепрыгнуть
на то, “что мы будем делать завтра”.
Анализ функциональной модели позволяет
понять, где находятся наиболее слабые
места, в чем будут состоять преимущества
новых бизнес-процессов и насколько
глубоким изменениям подвергнется
существующая структура организации
бизнеса. Детализация бизнес-процессов
позволяет выявить недостатки организации
даже там, где функциональность на первый
взгляд кажется очевидной. Признаком
неэффективной деятельности могут быть
бесполезные, неуправляемые и дублирующиеся
работы, неэффективной документооборот
(нужный документ не оказывается в нужном
месте в нужное время), отсутствие обратных
связей по управлению (на проведение
работы не оказывает влияние ее результат)
и входу (объекты или информация
используются нерационально) и т.д.
Найденные в модели “AS-IS” недостатки
можно исправить при создании модели
“TO-BE” (как будет) — модели новой организации
бизнес-процессов. Модель “TO-BE” нужна
для анализа альтернативных/лучших путей
выполнения работы и документирования
того, как компания будет делать бизнес
в будущем. Как правило, строятся несколько
моделей “TO-BE”, из которых по какому-либо
критерию выбирается наилучшая. Проблема
состоит в том, что таких критериев много
и непросто определить важнейший. Для
того, чтобы определить качество созданной
модели с точки зрения эффективности
бизнес- процессов, необходима система
метрики, то есть качество следует
оценивать количественно.

BPwin
предоставляет аналитику два инструмента
для оценки модели – стоимостной анализ,
основанный на работах (Activity Based Costing,
ABC) и свойства, определяемые пользователем
(User Defined Properties, UDP). ABС является широко
распространенной методикой, используемой
международными корпорациями и
государственными организациями (в том
числе Департаментом обороны США) для
идентификации истинных движителей
затрат в организации.

Рис.24.
Задание стоимости работ в диалоге
Activity Cost.

Стоимостной
анализ представляет собой соглашение
об учете, используемое для сбора затрат,
связанных с работами, с целью определить
общую стоимость процесса. Стоимостной
анализ основан на модели работ, поскольку
количественная оценка невозможна без
детального понимания в функциональности
предприятия. Обычно ABC применяется для
того, чтобы понять происхождение выходных
затрат и облегчить выбор нужной модели
работ при реорганизации деятельности
предприятия (Business Process Re-engineering, BPR). С
помощью стоимостного анализа можно
решить такие задачи как определение
действительной стоимости производства
продукта, определение действительной
стоимости поддержки клиента, идентификация
работ, которые стоят больше всего (те,
которые должны быть улучшены в первую
очередь), обеспечение менеджеров
финансовой мерой предлагаемых изменений
т.д.

ABC может проводиться
только когда модель работы последовательная
(следует синтаксическим правилам IDEF0),
корректная (отражает бизнес), полная
(охватывает всю рассматриваемую область)
и стабильная (проходит цикл экспертизы
без изменений). Эта методика включает
основные понятия, такие как объект
затрат (причина, по которой работа
выполняется, обычно, основной выход
работы, стоимость работ есть стоимость
объектов затрат), движитель затрат
(характеристики входов и управлений
работы, которые влияют на то, как
выполняется и как долго длится работа)
и центры затрат (центры затрат можно
трактовать как статьи расхода). При
проведении стоимостного анализа в BPwin
сначала задаются единицы измерения
времени и денег, затем описываются
центры затрат (cost centers) и, наконец для
каждой работы на диаграмме декомпозиции
назначаются продолжительность (duration),
частота проведения данной работы в
рамках общего процесса (frequency) и суммы
по каждому центру затрат, то есть задается
стоимость каждой работы по каждой статье
расхода (рис.24). Затраты вышестоящей
работы определяется как сумма затрат
дочерних работ по каждому центру затрат
(режим Compute from Decompositions). Это достаточно
упрощенный принцип подсчета справедлив,
если работы выполняются последовательно.
Если схема выполнения более сложная,
можно отказаться от подсчета и задать
итоговые суммы вручную (Override Decompositions)
или воспользоваться специализированным
средством стоимостного анализа EasyABC.
Результаты стоимостного анализа наглядно
представляются на специальном отчете
BPwin — Activity Cost Report.

ABC
позволяет оценить стоимостные и временные
характеристики системы. Если стоимостных
показателей недостаточно, имеется
возможность внесения собственных метрик
— свойств, определенных пользователем
(User Defined Properties, UDP). Имеется возможность
задания 18 различных типов UDP, в том числе
управляющих команд и массивов, объединенных
по категориям. Каждой работе можно
поставить в соответствие набор UDP и
проанализировать результат в специальном
отчете Diagram Object Report.

1. Разработка
   инфологической модели предприятия

ERWIN
— пакет для
проектирования и моделирования БД. С
помощью него описывается инфологическая
модель (ИЛМ), а из нее вырабатывается
уже структура самой БД (в Paradox,
MS
SQL,
Oracle
и т.д.).

С
помощью этой системы можно также сделать
обратное проектирование – из структуры
уже существующей БД получить ее
инфологическую модель. Такая задача
имеет место в случае, когда необходимо
перевести уже существующую БД с одной
программной платформы на другую (например
из FoxPro
в MS
SQL).

Соседние файлы в папке Desktop

• #

  23.02.201527.15 Кб14After.bp1

• #

  23.02.201526.22 Кб14Before.bp1

• #
• #
• #