Рис. 2. Пример переноса корректной модели из ARIS в DIRECTUM. На схеме типового маршрута пришлось лишь немного подкорректировать вручную координаты блоков
Рис. 3. Пример переноса оргструктуры из ARIS Toolset в DIRECTUM
Цикл управления бизнес-процессами (Business Process Management, BPM) состоит из ряда последовательных шагов, управляемых разными сотрудниками организации и поддерживаемых разными приложениями. В данной статье мы попробуем рассказать о том, как выполняется этот цикл, на примере популярных инструментов, предлагаемых компаниями DIRECTUM и IDS Scheer (см. рис. 1).
На этапе стратегического определения бизнес-процессов вырабатываются самые общие цели организации и очерчивается круг направлений ее деятельности. Руководители предприятия формулируют ключевые задачи, определяют процессы верхнего уровня; они же распределяют области ответственности за процессы. Этот этап поддерживается системами проектирования бизнес-процессов. В частности, в семействе ARIS компании IDS Scheer для решения подобных задач имеются продукты ARIS BSC Solution, ARIS Business Optimizer и ARIS Toolset. В последнем обеспечивается моделирование стратегических целей компании, цепочек создания ценностей и процессов верхнего уровня.
Построение модели деятельности компании на основе принципов системной инженерии
Стадия проектирования процессов предусматривает создание моделей “как есть” и “как должно быть”. Бизнес-аналитик (консультант, “моделировщик”) на этом этапе описывает процессы с полной их детализацией. В семействе продуктов ARIS к средствам проектирования относятся ARIS Business Architect, ARIS Business Designer и ARIS Toolset (или его облегченная версия ARIS Easy Designer).
Затем созданные описания согласовываются с владельцами процессов, с их непосредственными или потенциальными участниками и руководителями подразделений. На этом этапе среда управления контентом DIRECTUM играет роль системы, где согласуются описания и впоследствии публикуется информация о процессах.
Теперь, когда бизнес-процессы спроектированы, их следует внедрить. Здесь от поддерживающих программных средств требуется не только планирование процесса внедрения, но и фактический перенос моделей и связанных с ними словарей (например, лежащих в основе организационных диаграмм) в те или иные информационные системы, призванные в дальнейшем управлять исполнением бизнес-процессов. Семейство ARIS содержит средства для переноса моделей, специализированные инструменты для управления внедрением процессов с помощью различных BPM-систем, модулей и SOA-шин, а также утилиты, предназначенные для отображения моделей в еще только разрабатываемых программных продуктах (ARIS for SAP NetWeaver, ARIS UML Designer). В свою очередь, DIRECTUM поддерживает различные варианты импорта и генерации схем и словарей, а также обеспечивает документационное сопровождение бизнес-процессов.
Спроектированные процессы исполняются различными людьми и с помощью разных информационных систем. Роль “дирижера”, организатора здесь играет либо отдельный BPM-инструмент, либо SOA-шина (в зависимости от свойств процесса, его назначения и степени автоматизации), либо какие-то программные средства, например BPM/workflow-модули систем управления корпоративным контентом (Enterprise Content management, ECM). В частности, в ECM-системе DIRECTUM это модуль “Управление деловыми процессами”.
Финансовые показатели верхнего уровня
Исполнение бизнес-процессов в автоматизированных системах упрощает сбор относящихся к ним данных и позволяет проводить анализ процессов и их дальнейшую оптимизацию. Анализ и оптимизация — ключевые задачи этапа контроллинга. Корпоративные ИС (ERP, CRM, ECM) предоставляют статистическую информацию о протекании процессов, об их отдельных этапах, о прохождении тех или иных контрольных точек. Модуль контроллинга (в ARIS это Process Performance Manager) обрабатывает данную информацию, сопоставляя ее с моделью процесса. В результате бизнес-аналитик или руководитель получает уведомления о нарушении нормального хода процесса, выявляет узкие места, находит наиболее загруженных исполнителей и оценивает иные показатели.
Кроме того, на всех этапах цикла управления бизнес-процессами время от времени приходится решать задачу управления изменениями: необходимо поддерживать в актуальном состоянии модели и их отображение в BPM-системе, BPM/workflow-модулях и других элементах ИС.
Интеграция средств описания и исполнения бизнес-процессов
При внедрении процессов возникают две ключевые задачи. Во-первых, для того чтобы ускорить описание процессов, сократить объем рутинной работы, унифицировать эталонные процессы и их исполнение, нужна автоматическая синхронизация спроектированных моделей с системами, автоматизирующими исполнение бизнес-процессов. Во многих случаях в роли таких систем выступают ECM-решения и входящие в их состав BPM/workflow-модули. Во-вторых, часто бывает необходимо синхронизировать с бизнес-приложениями информацию о таких статических сущностях, как оргструктура предприятия, диаграмма технических ресурсов, диаграмма целей и функций верхнего уровня, топология сети и т. д. Эта информация иногда носит вспомогательный характер, но часто сама по себе является значимой и может активно использоваться в различных информационных системах.
Перенос диаграмм процессов возможен как из среды описания (ARIS) в среду исполнения (DIRECTUM), так и в обратную сторону (см. рис. 2). В ARIS процессы описываются в виде так называемых eEPC-диаграмм, а в DIRECTUM в модуле “Управление деловыми процессами” для этого используются свободные и жесткие типовые маршруты. При переносе блоков типовых маршрутов применяются определенные правила их сопоставления с элементами eEPC-диаграмм. Важно понимать, что перенос eEPC-диаграмм невозможен без хотя бы минимального семантического разбора модели; переносить просто отдельные блоки и связи недостаточно.
При переносе схем из ARIS в DIRECTUM необходимо также учитывать несколько ограничений. Во-первых, в большинстве случаев в ARIS проектируются сквозные процессы, пронизывающие не только ECM-систему, но и другие корпоративные приложения (ERP, CRM и т. д). Иными словами, DIRECTUM скорее всего будет автоматизировать лишь часть процесса.
Это ограничение можно обойти, зафиксировав в модели (например, с помощью атрибутов) те функции процесса, которые должны быть отражены в типовых маршрутах DIRECTUM. Во-вторых, процесс, перенесенный в DIRECTUM, не может быть запущен сразу же. В любом случае необходима его доработка: выделение и задание параметров маршрута, точное сопоставление ролей, задание ограничений на исполнение блоков (например, необходимость присутствия вложенного в задание документа) или простая подгонка координат блоков для более наглядного визуального представления маршрута. Тем не менее автоматизированная синхронизация модели позволяет значительно снизить долю рутинного труда.
Третье ограничение связано с тем, что в реальной жизни моделировщики не всегда досконально соблюдают требования нотации (языка описания процессов). Нередко в созданных ими моделях отсутствуют необходимые связи, применяются объекты, схожие по внешнему виду, но различающиеся по смыслу, используются разные экземпляры одного и того же объекта вместо экземпляров разных объектов, отсутствует обязательная информация (например, не указывается исполнитель) и т. д.
Обратный перенос моделей из DIRECTUM в ARIS менее подвержен ошибкам, он проще, так как, будучи процессом автоматизированным, изначально описан более строго. Такой перенос бывает необходим в том случае, когда ARIS внедряется позже, чем DIRECTUM. Он позволяет зафиксировать в системе моделирования те наработки в области регламентации бизнес-процессов, которые уже сделаны к моменту внедрения ARIS. Тем не менее более типична ситуация, когда ARIS содержит эталонные модели, которые находят свое отражение в DIRECTUM. При переносе eEPC-диаграмм из ARIS в DIRECTUM и обратно используется AML (ARIS Modeling Language) — основанный на XML язык описания моделей ARIS.
Кроме диаграмм процессов могут быть перенесены и статические схемы, разработанные в ARIS. Примером может служить организационная диаграмма, данные из которой попадают в справочники подразделений и работников, поддерживаемые в DIRECTUM и в дальнейшем используемые в типовых маршрутах.
Перенос организационной диаграммы, как и перенос диаграмм процессов, подчиняется определенным правилам. Сценарий переноса “понимает”, к какому виду принадлежит тот или иной блок и каковы отношения между блоками. Так, объект “организационная единица” на диаграмме ARIS преобразуется в запись справочника подразделений, информация связанного с ним объекта “должность” попадает в поле “должность руководителя” соответствующего подразделения, а сведения о персоне, занимающей должность, переносятся в справочник работников и связываются с записью справочника подразделений (см. рис. 3).
Возможна и обратная генерация организационной схемы по содержимому справочника подразделений DIRECTUM.
Результатом проектирования в ARIS Toolset являются не только схемы процессов. Как и большинство аналогичных систем проектирования и поддержки процессов, ARIS Toolset позволяет генерировать различные отчеты и документы. Это могут быть документы, нужные как ограниченному кругу людей — консультантам, аналитикам и руководителям предприятия (например, матрицы ответственных по процессам, список процессов и их диаграммы, штатное расписание), так и широкому кругу сотрудников (рабочие инструкции, списки сотрудников разных подразделений и т. д.). DIRECTUM может хранить сгенерированные таким образом документы, помогать согласовывать их и доносить до всех заинтересованных работников организации.
Суть контроллинга — в регулярной оценке степени достижения заданных целей, постоянном улучшении и оптимизации процессов. Говоря о качестве построения системы бизнес-процессов, имеют в виду достижение максимально возможной скорости их выполнения, простоту и прозрачность, т. е. отсутствие в процессах лишних шагов и узких мест. Поэтому задачами контроллинга являются, в частности, постоянный сбор статистической информации об исполнении бизнес-процессов и проверка соответствия фактических параметров заранее заданным нормативам.
В семействе продуктов ARIS эти функции выполняет ARIS Process Performance Manager (ARIS PPM). Он формирует базу статистики, в нем задаются контрольные показатели, и с его помощью заинтересованные лица оповещаются о тех или иных выявленных проблемах фактического исполнения процессов.
ARIS PPM ориентирован на анализ сквозных бизнес-процессов, в которых задействованы различные корпоративные бизнес-приложения — финансовые и производственные, системы бюджетирования, управления взаимоотношениями с клиентами и, конечно, системы ECM. Каждая из них может либо иметь свой модуль workflow/BPM, либо неким специальным образом реализовывать выполнение процесса внутри себя. Поэтому в основе концепции системы контроллинга лежит анализ того, как процесс проходит через контрольные точки. Информация о факте прохождения такой точки должна генерироваться задействованными в исполнении процесса бизнес-приложениями и доставляться в систему контроллинга.
Задачей продукта DIRECTUM, работающего в связке с ARIS PPM, является предоставление сведений о запуске и завершении задания, о прохождении его через определенный этап типового маршрута, о составе параметров маршрута, а также — при необходимости — информирование о выполнении определенных сценариев, обращении к документам и справочникам.
Однажды синхронизированный процесс и перенесенные данные словаря впоследствии будут меняться — и поэтому перенос модели необходимо повторять. Модель и ее отражение должны быть идентичны: в этом состоит суть задачи управления изменениями. Как и в рассмотренном выше случае с синхронизацией модели, здесь можно выделить два направления: поиск объектов ECM-системы, затронутых в процессе модификации модели, и поиск моделей, которые могли устареть в результате изменения их реализации в DIRECTUM. В случае DIRECTUM и ARIS итогом такого поиска становится отчет о расхождениях. Сгенерированные вручную или по расписанию, эти отчеты дают возможность сравнить структуры и процессы среды исполнения DIRECTUM с моделями ARIS.
Описанная выше интеграция инструментов DIRECTUM и ARIS позволяет ускорить внедрение системы BPM, своевременно актуализировать процессы и структуры в среде DIRECTUM и упростить контроллинг бизнес-процессов.
Источник: www.itweek.ru
Структура АСУ ТП
Современная система атоматического управления технологическим процессом представляет собой сложный комплекс оборудования и программного обеспечения. Как правило, различают два уровня АСУ ТП: верхний и нижний.
Нижний уровень состоит из системы контроллеров, которые собирают информацию о всех технологических процессах, которые происходят на производстве, и передают на верхний уровень.
Верхний уровень АСУ ТП реализован на рабочих станциях и серверах. По сути, верхний уровень АСУ ТП представлен специализированным программным обеспечением, которое обеспечивает обратную связь между диспетчером или оператором и элементами нижнего уровня АСУ ТП.
Иногда в рамках нижнего уровня АСУ ТП различают непосредственно нижний уровень (реализованный на микроконтроллерах) и средний (реализованный на контроллерах). Тем не менее, чаще всего такого различия не делают.
АСУ ТП: нижний уровень
Нижний уровень АСУ ТП обеспечивает контроль параметров технологических процессов и непосредственное управление оборудованием.
Кроме этого, именно на нижнем уровне реализуются такие возможности современных АСУ ТП, как автоматический пуск и остановка оборудования с целью предотвращения аварийных ситуаций.
Контроллеры нижнего уровня АСУ ТП обеспечивают первичную обработку информации, которая поступает с оборудования, и отслеживают нарушение параметров технологических процессов или их соответствие заданным величинам.
Непосредственный контроль производственных процессов и их параметров (вес компонентов смеси, их расход, давление, частота вращения и другие) осуществляется системой датчиков. Сигналы от датчиков поступают в соответствующие контроллеры, в которых происходит сравнение параметров сигнала датчика с запрограммированными параметрами.
Большинство контроллеров не имеют собственных средств визуализации. Принцип их работы базируется на релейно-контактных схемах. Различия между контроллерами в первую очередь основаны на встроенном языке программирования и дополнительных функциях аппаратной части.
В зависимости от показателя датчика, и его соответствия заданным параметрам, контроллер передает сигнал на другие компоненты системы для выполнения необходимых действий. Последовательность прохождения сигнала основана на программном обеспечении нижнего уровня АСУ ТП. Одновременно информация поступает на верхний уровень АСУ ТП для дальнейшего анализа, визуализации и, при необходимости, вмешательства диспетчера или оператора в технологический процесс.
Программирование контроллера Fatek для подключения 16 входящих и 16 исходящих сигналов
Программирование контроллера Siemens для подключения 16 входящих и 16 исходящих сигналов
АСУ ТП: верхний уровень 
Верхний уровень автоматической системы управления обеспечивает широкие возможности визуализации и взаимодействия системы АСУ ТП с человеком (диспетчером или оператором).
В первую очередь программное обеспечение и оборудование верхнего уровня реализует информационные функции (сбор, обработку, хранение и выдачу информации по требованию оператора). При этом в систему поступает не только информация о параметрах технологических процессов, и моментах срабатывания автоматики безопасности, но также информация о внешнем вмешательстве персонала в работу установки.
Кроме этого, с помощью программного обеспечения верхнего уровня осуществляется дистанционное управление оборудованием БСУ и настройка параметров системы управления.
Субстратом визуализации технологических процессов, которые происходят на предприятии, является система компьютеров и специализированных мониторов. На мониторах отображаются изменения параметров и этапы срабатывания оборудования.
Количество параметров, которые выводятся на мониторы, частота изменения данных на мониторах и другие параметры программируются индивидуально, в зависимости от потребностей конкретного производства.
Типовое ПО для визуализации процессов котельной
Типовое ПО для визуализации процессов БСУ
АСУ ТП: разработка программного обеспечения
Разработка программного обеспечения верхнего и нижнего уровней АСУ ТП представляет собой комплексный процесс, который начинается на этапе изучения объекта автоматизации.
Специалисты определяют объективное текущее состояние производства, и на основе полученных данных составляют и согласовывают с заказчиком техническое задание по автоматизации и предварительную смету работ.
После утверждения предварительного технического задания происходит подбор необходимых технических средств, необходимых для автоматизации. Подбор оборудования основан на принципе оптимального соотношения цены и качества и максимального соответствия задачам, поставленным в техническом задании, и совместимости с программным обеспечением.
На этапе разработки проектной документации составляются схемы электрических цепей и соединений, описание базы данных и алгоритмов управления системой.
Непосредственно разработка программ проводится по отдельности для нижнего и верхнего уровня АСУ ТП. Для нижнего уровня составляются алгоритмы управления технологическим оборудованием. Для верхнего разрабатываются алгоритмы сбора и обработки информации.
В процессе разработки учитываются все необходимые параметры, возможные величины их изменения и структура логических цепочек технологических процессов. Затем происходит сложный процесс комплексной интеграции программного обеспечения верхнего и нижнего уровня АСУ ТП, в результате чего обе системы функционируют как единое целое.
Преимущества АСУ ТП от компании ИЦ Промсервис
Система автоматического управления от компании ИЦ Промсервис и ее программное обеспечение выгодно отличается повышенной функциональностью, надежностью и оптимальной стоимостью.
На нижнем уровне АСУ ТП программное обеспечение от ИЦ Промсервис позволяет эффективно выполнять в автоматическом режиме технологические блокировки, необходимые для исключения аварийных ситуаций на оборудовании. Управление весовым оборудованием осуществляется наиболее оптимальным способом, с точным учетом дозирования компонентов смесей.
Коррекция количества химических добавок производится автоматически в зависимости от сезона и температуры наружного воздуха. Коррекция водно-цементного соотношения также происходит автоматически и зависит от показателей датчиков, определяющих влажность элементов смеси.
Программное обеспечение верхнего уровня автоматической системы управления разработки компании ИЦ Промсервис характеризуется широким спектром уникальных функций по сбору, хранению и выдаче информации.
АСУ ТП, которую предлагает ИЦ Промсервис, обеспечивает автоматическую печать накладных и паспортов качества, а также автоматическую рассылку наиболее важной информации в виде SMS сообщений ответственным лицам.
Неограниченная по количеству возможных рецептов база данных и гибкие возможности программирования каждого рецепта обеспечивают высочайшее качество готовых смесей.
Разработка программного обеспечения АСУ ТП проводится опытными специалистами. Высокая квалификация сотрудников ИЦ Промсервис подтверждается не только сертификатами ведущих профильных семинаров России и Западной Европы, но и реальным опытом более 100 успешных автоматизаций на предприятиях России и стран СНГ.
Элементы программного обеспечения АСУ ТП от ИЦ Промсервис идеально взаимодействуют между собой, создавая эффективную целостную современную систему автоматического управления. Оптимальная стоимость позволяет утверждать, что АСУ ТП от компании ИЦ Промсервис – это наиболее удачный выбор на рынке программного обеспечения в странах СНГ.
* — указаны начальные цены, для каждого объекта стоимость меняется в зависимости от сложности
Наши услуги
- Модернизация и реконструкция БСУ
- Автоматизация складов цемента
- Производство весовых дозаторов
- Перевод дозаторов на тензометрическую систему взвешивания (без остановки производства)
- Разработка и создание автоматизированных систем управления заводами по производству бетона, асфальта, сухих строительных смесей
- Диспетчеризация инженерных обьектов
- Пуско-наладочные работы и адаптация систем управления БСУ импортного производства
- Разработка программного обеспечения верхнего и нижнего уровня АСУ ТП
- Информация
- Новости
- Чем мы занимаемся
- Документы
- Глоссарий
Источник: www.promserv.ru
Управление в А95
Методология «полного» описания бизнес-процессов рассчитана на организации, поставившие своей целью реальное улучшение деятельности в разумные сроки. Данная методология помогает в первую очередь навести элементарный порядок в управлении, а затем переходить к внедрению элементов процессного управления.
«Полным» метод назван вследствие того, что он основан на детальном анализе информационных и материальных потоков организации и четком определении пересечений этими потоками границ функциональных подразделений. Типичный срок анализа и улучшения ситуации с процессами для данного метода – 1-1,5 года. Основной целью работ в данном случае является построение системы управления процессами организации или, более обще, системы менеджмента, ориентированный на процессы. Методология «полного» описания процессов реже используется на практике в чистом виде. Как показывает практический опыт, подходы рассматриваемой методологии применяются в той или иной степени во многих организациях.
Шаг 1. Определить внешних клиентов организации (окружения) и входы/выходы для организации в целом.
Рис.1 Шаг 1. Определение окружения организации и внешних входов/выходов.
При выполнении первого шага рассматривается организация в целом и ее окружение так же, как и в методологии 1. Определяются внешние входы и выходы. Результатом работ является спецификация входов/выходов и окружения организации. Важно отметить, что входы/выходы должны быть указаны в спецификации на верхнем уровне. Например, было бы неправильно включать в спецификацию такие позиции, как «накладная», «готовое изделие» и т.п. Нужно включать агрегированные позиции: «документы на отгрузку», «готовые изделия» и т.п.
Шаг 2. Привязать полученные входы/выходы к подразделениям организации.
Рис.2 Шаг 2. Привязка полученных входов/выходов к подразделениям организации.
Второй шаг существенно отличается от методологии 1, а именно выделяются не основные процессы, а структурные подразделения организации. Сделать это можно довольно легко, т.к. границы функциональных подразделений достаточно четко очерчены.
Рабочая группа может использовать положение об организационно-штатной структуре организации и другие необходимые документы. Далее все внешние входы и выходы связываются со структурными подразделениями, как показано на рис.2.
Шаг 3. Определить внутренние входы/выходы для каждого подразделения организации.
Рис.3. Шаг 3. Определение внутренних входов/выходов для каждого подразделения.
Помимо внешних входов/выходов существуют и внутренние входы/выходы, обусловленные информационными и материальными потоками между подразделениями организации. Эти внутренние потоки так же достаточно легко могут быть идентифицированы. При этом важно не допускать слишком детального описания потоков. Такое описание на данном этапе работ не целесообразно. В то же время, важно определить все типы внутренних потоков между подразделениями.
Шаг 4. Определить перечень функций, выполняемых в каждом подразделении.
На четвертом шаге рассматривается деятельность каждого подразделения в отдельности. Более четко определяются границы подразделений. Для каждого подразделения формируется перечень выполняемых в нем функций. Именно на этом этапе начинает сказываться элемент субъективности. Как правило, реально выполняемые в подразделениях функции отражены в формальных документах лишь на 30-40%.
Дело в том, что положения о подразделениях, инструкции и другие документы редко пересматриваются и не являются актуальными. Такое положение обусловлено в первую очередь отношением руководства компании к регламентирующей документации и отсутствием системы работы с документацией.
Выделение функций подразделений осуществляется рабочей группой с использованием существующей документации, но основным средством сбора информации является интервьюирование руководителей и сотрудников подразделений.
Напомним, что методики интервьюирования являются так же базовыми и для методологии 1. Результатом работ на шаге 4 является перечень выполняемых в подразделении функций.
Шаг 5. Для каждого подразделения сгруппировать функции по процессам, формирующим выходы. Привязать к этим процессам входы.
Рис.5. Шаг 5. Группирование функций подразделения по процессам.
При выполнении шага 5, функции каждого подразделения группируются по бизнес-процессам, формирующим выходы подразделения. Каждая функция подразделения должна быть отнесена хотя бы к одному такому бизнес-процессу.
При разделении часть функций войдет в «сквозные» бизнес-процессы организации, т.е. процессы, проходящие через границы функциональных подразделений, как показано на рис.5. Другая часть функций может войти во вспомогательные процессы. Некоторую часть функций, вероятно, затруднительно будет отнести к какому-либо процессу верхнего уровня. При внимательном рассмотрении, такие функции могут оказаться внутренними функциями подразделения. Среди них могут быть и такие, которые не нужны ни подразделению, ни организации в целом и подлежат устранению.
Рис.5.1 Объединение процессов подразделений в процессы организации в целом.
Как давать наименования бизнес-процессам, по которым распределены функции подразделения? Делать это можно по-разному:
- на основе состава выполняемых работ и полученных результатов;
- на основе классификации процессов (см. выше);
- на основе наименования процессов схемы жизненного цикла продукции
При использовании первого подхода названия бизнес-процессов подразделения определяются на основе состава выполняемых работ и полученных результатов (пример: «процесс формирования плана отгрузки на квартал» или «процесс бюджетирования деятельности подразделения»).
На практике, многие полученные цепочки процессов подразделения могут принадлежать одному более крупному процессу уровня организации в целом. Так например, несколько бизнес-процессов уровня отдела сбыта будут являться составляющими процесса «сбыт» для организации в целом.
При втором способе, выделенные цепочки процессов включаются в модель как часть процессов верхнего уровня, названия которых взяты из классификации процессов.
При третьем способе, выделенные цепочки процессов получают свои названия на основе наименований процессов верхнего уровня, показанных на рис.5.2
Рис.5.2 Жизненный цикл продукции.
Нежелательно давать выделенным цепочкам процессов подразделения произвольные названия, т.к. это будет препятствовать определению сквозных бизнес-процессов организации в целом на следующем этапе. Нельзя так же рассматривать процессы подразделения «плоскими», т.е. состоящими только из работ, выполняемых исполнителями на местах, без руководителей. Следует помнить, что любая цепочка процесса нуждается в планировании, учете, анализе, управлении. Выделенные процессы подразделений должны быть объемными (т.е. отражать деятельность руководителей), а не просто отражать плоскую последовательность выполнения функций.
Результатом работы на шаге 5 является четкое понимание деятельности подразделений за счет ее структуризации по бизнес-процессам. Обратим внимание, что субъективность выделения бизнес-процессов уровня подразделения на основе его выходов и выполняемых функций является минимальной.
Шаг 6. Используя входы/выходы между подразделениями сгруппировать бизнес-процессы подразделений в бизнес-процессы организации.
Рис.6. Шаг 6. Формирование бизнес-процессов организации из бизнес-процессов подразделений.
На шаге 6 осуществляется интеграция бизнес-процессов уровня подразделений в сквозные бизнес-процессы уровня организации в целом. Существующие между подразделениями информационные и материальные потоки являются при этом указателями связи между процессами подразделений.
Таким образом, все функции подразделений оказываются отнесенными к определенным бизнес-процессам. Еще раз подчеркнем, что бизнес-процессы организации, представленные на рис.6 в виде плоских процессов, на самом деле являются объемными. Попытка отобразить «объемность» процессов показана на рис.6.1
Рис.6.1«Объемные» бизнес-процессы.
Шаг 7. Сформировать матрицы ответственности по каждому подразделению. На основе этих матриц составить матрицы ответственности бизнес-процессов организации.
Рис.7 Шаг 7. Формирование матриц ответственности по бизнес-процессам.
После того, как процессы подразделений распределены по бизнес-процессам организации в целом, можно приступать к разработке Матриц ответственности бизнес-процессов. Для этого формируются матрицы ответственности функциональных подразделений. Затем, осуществляя выборку их этих документов, формируют матрицы ответственности по процессам. На начальном этапе внедрения процессного управления можно обойтись только матрицами ответственности подразделений, т.к. не формировать матрицу ответственности по бизнес-процессам.
Итак, «полная» методология позволяет детально описать деятельность организации, корректно выделяя бизнес-процессы на основе информационных и материальных потоков и однозначно связывая функции подразделений с процессами.
При использовании этой методологии не должно быть «потерянных» функций, т.е. функций не вошедших ни в один бизнес-процесс.
Таким образом, все функции организации оказываются привязанными к конкретным бизнес-процессам. Бизнес-процессы формируются не субъективным образом, а на основе реальных потоков информации и материальных ресурсов между подразделениями.
К недостаткам данного метода можно отнести:
- высокая трудоемкость применения метода для средних и крупных организаций;
- значительная длительность описания (8-12 месяцев);
- сложность компоновки бизнес-процессов организации из бизнес-процессов подразделений.
Источник: apteka95-management.blogspot.com
