СД.ДС.Ф.1 .Управление процессами. Учебнометодический комплекс дисциплины Управление процессами Специальность подготовки 080507. 65 Менеджмент организации
 Скачать 2.03 Mb.
|
КОНСПЕКТЫ ЛЕКЦИЙпо дисциплине «Управление процессами» Специальность подготовки 080507. 65 «Менеджмент организации» г. Спасск-Дальний 2012 Лекция 1. Понятие и сущность управления процессами. (2 часа)Разработка и внедрение стандартизированных систем качества нацеливает на необходимость применения новой организационной формы управления предприятием, охватывающей все действия, касающиеся единой политики в области качества, на основе которой формируются новые цели и задачи, стоящие перед отдельными структурными единицами, и их реализацию посредством планирования и организация обеспечения качества производственных процессов и качества их результатов. Для осуществления организационных изменений необходимо опираться с одной стороны на принцип интеграции, с учетом рыночного механизма, в котором главную роль играет заказчик, а с другой стороны, на повышение активности и эффективности действий всех работников, участвующих в различных процессах и видах деятельности предприятия. Выделенные изменения напрямую связаны с внедрением так называемого процессного подхода к организации производства и управлению деятельностью предприятия, который является одним из восьми базовых принципов, положенных в основу стандартов ИСО серии 9000. Первоначально идея использования процессного подхода к описанию деятельности предприятия рассматривалась в теории административного управления А. Файоля. Дальнейшее распространение данный подход получил лишь в конце ХХ в., когда применяемый функциональный подход к организации производства и управлению предприятием перестал быть прогрессивным. В подтверждение этому можно привести высказывание Т. Конти на Международной конференции по проблемам качества: «Введение процессного подхода означает отказ от подхода к менеджменту качества на основе бюрократических процедур в пользу более гибкого, интегрированного менеджмента компании, как «цепи ценностей», нацеленных на оптимизацию результативности и гибкости ее работы». В методологии TQM «процессным» называется, любая деятельность, представленная в форме процесса, раскрывающаяся во взаимосвязи главных компонентов: выходов, входов, ресурсов. Процесс – это устойчивая взаимосвязанная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя. Входы процесса – ресурсы, преобразующиеся в ходе процесса в выходы процесса. Входами к процессу обычно являются выходы других процессов. Выходы процесса – результаты (продукт, услуга) процесса. Желаемый результат (цель) достигается эффективнее, когда деятельностью и соответствующими ресурсами управляют как процессом. В процессах описывается не вся деятельность организации, а только та, которая влияет на получение продукции. Границы процесса должны быть четко определены (по функциям и ответственности руководителей). Выделяют основные и вспомогательные процессы. Основные процессы лежат на пути следования продукции: сначала в виде маркетинговой информации, проекта, затем в виде материального объекта (детали, товара, программного продукта, услуги и т. д.). Для обеспечения нормального функционирования основных процессов выделяют вспомогательные процессы. Каждой организации необходимо непрерывное совершенствование, для того, чтобы сохранять имеющиеся и достигать все более новые преимущества перед организациями-конкурентами. Одним из методов непрерывного совершенствования является управление деятельностью организации согласно известному циклу Деминга «PDCA» – планирование (Plan), выполнение (Do), проверка (Check), действия (Act). Методология PDCA представляет собой простейший алгоритм действий руководителя по управлению процессом и достижению его целей. Цикл управления начинается с планирования.  Рисунок – Цикл Деминга PDCA Планирование (Plan) – установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворенности потребителя, планирование выделения и распределения необходимых ресурсов. Выполнение (Do) – осуществление запланированных работ. Проверка (Check) – сбор информации и контроль результата, получившегося в ходе выполнения процесса, выявление и анализ отклонений, установление причин отклонений. Действия (управление, корректировка) (Act) – принятие мер по устранению причин отклонений от запланированного результата, изменения в планировании и распределении ресурсов. После окончания «Действия» цикл начинается заново. При прохождении через цикл PDCA организация (в отличие от организации со стандартными методами управления) имеет продукцию более высокого качества и, следовательно, более высокие требованиями к технологии ее изготовления. Цикл PDCA применим как к процессу в целом, так и к отдельным видам деятельности, входящим в состав процесса. История моделирования бизнес-процессов насчитывает уже почти столетие, хотя вплоть до начала 1990-х гг., когда термин «бизнес-процесс» вошел в широкое употребление, говорили об описании того, каким образом организация осуществляет свои функции и выполняет те или иные задачи. Развитие методов моделирования и автоматизации бизнес-процессов принято разделять на три этапа, или три «волны». Началом каждой из них явился очередной всплеск интереса к повышению эффективности деятельности предприятий и процессному управлению, происходивший каждый раз на новом качественном уровне. Основные характеристики этих этапов приведены в табл. в сравнении с соответствующими стадиями развития информационных технологий и подходов к совершенствованию деятельности компании. Начало первого этапа относят к 1920-м гг. XX в. и связывают с именем Фредерика Тейлора и его книгой «Принципы научного управления». В этот период впервые была осознана необходимость исследовать бизнес-процессы, описывать их в различных документах и действовать в соответствии с этими описаниями. Описание бизнес-процессов производится в текстовом, табличном и графическом виде, причем последний все более формализуется. В период «первой волны» для моделирования бизнес-процессов используются блок-схемы, ориентированные графы, сети Петри, методологии SADT, IDEF, DFD. Блок-схемы на основе определенной в ГОСТ 19.701-90 нотации схем алгоритмов, программ, данных и систем (в англ. литературе — ANSI flowcharts) остаются и сегодня простейшим, но практически важным формальным графическим языком моделирования бизнес-процессов. Пример описания процесса с помощью блок-схемы приведен на рис. Блок-схемы позволяют быстро и наглядно показать шаги бизнес-процесса в понятной каждому форме, однако их нотация не предусматривает формализованного описания многих деталей процесса, в частности исполнителей бизнес-функций.  О методологиях SADT и IDEF мы подробно поговорим в следующей главе. Что же касается сетей Петри, то использование этого аппарата непосредственно для описания бизнес-процессов хотя и имеет своих сторонников, но не завоевало широкой популярности, так как его графическая нотация не является интуитивно понятной (с ней сложно работать бизнес-аналитикам и менеджерам). Кроме того, есть процессы, которые невозможно описать с его помощью. Однако, забегая вперед, отметим, что сети Петри лягут в основу ряда языков, специально разработанных для моделирования бизнес-процессов в рамках «третьей волны». В 1980-х гг. предпринимаются первые попытки автоматизации бизнес-процессов (уточним: не отдельных шагов, а хода процесса в целом) путем реализации в программном обеспечении для управления документами — системах электронного документооборота — функций по отслеживанию последовательности выполняемых действий для автоматизации процедур утверждения и выпуска документов. Успех таких систем вдохновляет разработчиков ПО на распространение аналогичного подхода на автоматизацию других функциональных областей бизнеса. Бизнес-моделирование выделяется в самостоятельное научно-прикладное направление только к началу 1990-х гг. Большинство созданных и применяемых до этого момента методологий не предназначались специально для описания бизнес-процессов, а разрабатывались для моделирования сложных систем и проектирования ПО. Они зачастую лишены строго определенной семантики. Модели, полученные с помощью таких методологий, как правило, воспринимаются интуитивно, и их интерпретация может меняться в зависимости от пользователя или области приложений модели. Эти модели хорошо подходят для обсуждения бизнес-процессов между сотрудниками компании и руководством, для чего они, собственно, и применялись, но не могут быть основой для работы информационной системы, так как неполны и допускают различные интерпретации. Начало второго этапа ознаменовал выход книги М. Хаммера и Д. Чампи -Реинжиниринг корпорации: манифест революции в бизнесе», которая возродила в управленческой среде интерес к описанию и анализу бизнес-процессов с целью их радикальной перестройки — реинжиниринга. Реинжиниринг бизнес-процессов предполагает построение двух моделей бизнес-процесса: как есть (англ. as is) и как должно быть (англ. to be), а затем внедрение последней на предприятии. Как следующий шаг в автоматизации бизнес-процессов в 1990-х гг. появляются системы управления потоками работ WfMS (Workflow Management System) второго поколения, предназначенные для маршрутизации потоков работ любого типа в рамках бизнес-процессов компании. Эти системы снабжены средой разработчика, которая теоретически может использоваться для моделирования различных нестандартных бизнес-процессов, однако на практике в большинстве случаев внедрение нового или изменение имеющегося процесса требовало привлечения труда программистов. Еще более ограниченные возможности по настройке и изменению процессов предоставляли поддерживающие управление потоками работ системы планирования ресурсов предприятия ERP (Enterprise Resource Planning). Внесение любых существенных изменений в бизнес-процесс превращалось в весьма дорогостоящий и долгосрочный проект по проектированию и разработке программного обеспечения, а модели бизнес-процессов, построенные аналитиками, использовались для более четкой формулировки требований, которые затем передавались программистам. В качестве примера методологии и средства автоматизации бизнес-процессов второго поколения можно назвать соответственно ARIS и распространенную ERP-систему SAP R/3. Негибкость моделей и средств автоматизации, их неспособность обеспечить оперативное реагирование на постоянные изменения в бизнес-среде стали основными недостатками систем «второй волны», стимулировавшими разработку в начале 2000-х гг. методологий следующего — третьего — поколения. Манифестом «третьей волны» в моделировании бизнес-процессов можно по праву назвать книгу Г. Смита и П. Фингара «Управление бизнес-процессами: третья волна»1. На смену радикальному реинжинирингу приходит системное и «плавное» управление. Изменчивость бизнес-процессов, возможность их корректировки в ответ на изменения в бизнесе становятся главным критерием использования информационных технологий как средства, позволяющего получить преимущества на рынке. Идея методологий и инструментов моделирования третьего поколения состоит в том, чтобы позволить руководству и сотрудникам компании создавать и самим внедрять новые процессы «на лету». Автоматизация процессов производится посредством так называемых систем управления бизнес-процессами BPMS (Business Process Management System), которые дают возможность непосредственно реализовывать бизнес-процессы в соответствии с построенной формальной моделью и не требуют разработки дополнительного программного обеспечения. Для разработки понятных машине «исполняемых» моделей требуются более точные методы моделирования. К таким методам относятся языки моделирования на базе XML: BPML, BPEL, XPDL. Однако построение моделей непосредственно на этих языках неудобно для бизнес-пользователей. В этой связи большое внимание разработчики программного обеспечения уделяют средствам конвертирования графических моделей бизнес-процессов в исполняемые. Это позволяет бизнес-аналитику или менеджеру строить модели бизнес-процессов с использованием графической нотации, а затем преобразовывать построенную модель (пока нередко с помощью технического специалиста) в исполняемый вид. Следует понимать, что графические модели, предназначенные для преобразования в исполняемые, должны быть гораздо более строгими и формальными по сравнению с моделями, создаваемыми в аналитических целях. Например, графическую модель, построенную в виде блок-схемы с обширными текстовыми комментариями, автоматически конвертировать в исполняемый формат не удастся. В качестве языка, позволяющего построить наглядную, понятную неподготовленному пользователю модель, которую затем можно однозначно преобразовать в исполняемый язык (изначально это был 3PML), выступила нотация BPMN. Она поддерживает описание таких «программистских» функций, как обработка событий и ошибок, откат транзакций и т. п. «Третья волна» принесла в моделирование бизнес-процессов стремление к стандартизации. Методологии построения исполняемых моделей разрабатываются и выпускаются организациями по стандартизации и международными консорциумами: OASIS (Organization for the Advancement of Structured Information Standards, осн. в 1993 г.) выпускает спецификации ebXML и BPEL, а также различные стандарты для электронного бизнеса на базе XML и веб-сервисов; OMG (Object Management Group, осн. в 1989 г.) выпускает стандарты BPMN и UML, а также MDA и CORBA; W3C (World Wide Web Consortium, осн. в 1994 г.) выпускает стандарты WS-CDL, WSCI, а также спецификации XML, технологии веб-сервисов и многие другие; WfMC (Workflow Management Coalition, осн. в 1993 г.) выпускает стандарты Wf-XML и XPDL. На современном этапе в круг задач моделирования и автоматизации бизнес-процессов все чаще включают автоматизацию взаимодействия предприятия с внешней средой. В модели бизнес-процесса отражают взаимодействие компании с различными внешними сущностями: клиентами, коммерческими партнерами, поставщиками, административными органами. При автоматизации процесса данные взаимодействия также стараются по возможности автоматизировать. Особенно активно развиваются технологии автоматизации межкорпоративного взаимодействия — бизнес-бизнес (англ. Business-to-Business, B2B). Потребности в автоматизации бизнес-процессов взаимодействия между предприятиями возникли еще в 60-х гг. прошлого века. Первое поколение электронных систем В2В-взаимодействия описывает стандарт UN/EDIFACT, или ЭДИФАКТ ООН (Правила ООН Электронного Обмена Данными в Управлении, Торговле и на Транспорте, ISO 9735), который, несмотря на высокую конкуренцию со стороны XML-систем в последние годы, до сих пор довольно широко применяется в Европе во многих секторах экономики. Развитие сети Интернет послужило толчком к созданию новых методов и технологий в области электронного обмена данными. Одним из наиболее удачных методов электронного обмена является появившаяся в 1998 г. методология консорциума RosettaNet. Данная технология описывает открытую платформу электронного взаимодействия, основанного на стандарте XML, и позволяет сторонам, участвующим во взаимодействии, обмениваться бизнес-информацией через Интернет. Первоначально стандарт был разработан для индустрии высоких технологий (информационные технологии и электроника), однако предложенный подход послужил основой механизмов взаимодействия предприятий и других отраслей. В рамках методологии RosettaNet разработаны стандарты более сотни процессов бизнес-взаимодействия между различными компаниями или подразделениями внутри одного предприятия. Эти стандартизованные процессы получили название процессов интерфейса взаимодействия с партнером (Partner Interface Process, PIP) и специфицируют транзакции между двумя бизнес-системами в форме диалога на основе стандарта XML. Еще одной современной технологией автоматизации межкорпоративного взаимодействия является ebXML (Electronic Business using extensible Markup Language, ИСО 15000). Работа над технологией ebXML началась в 1999 г. по инициативе СЕФАКТ ООН (Центр ООН по поддержке процедур и практики управления, коммерции и транспорта) и консорциума OASIS, накопившего большой опыт в сфере организации ведения бизнеса в Интернете на базе XML. Целью данного проекта является разработка инфраструктуры электронного бизнеса — полного набора спецификаций, позволяющего осуществлять бизнес-взаимодействия через единообразную XML-среду. С появлением ebXML компании получили стандартизованный де-факто метод обмена данными и бизнес-сообщениями, а также единые условия информационной поддержки торговых отношений. Архитектура ebXML объединяет спецификации формата сообщений, модели бизнес-процессов, пакет синтаксически нейтральных базовых компонентов и распределенные хранилища данных (репозитории). Стандарт ebXML получает все более широкое распространение с внедрением технологии веб-сервисов (Web Services). Выявление (выделение) основных процессов Основные процессы – это те процессы, которые непосредственно направлены на создание продукции; т.е. процессы, добавляющие ценность продукции. Результатом таких процессов является продукция или полуфабрикат для ее изготовления. Для выделения основных процессов может быть применена схема жизненного цикла продукции (рисунок). Жизненный цикл продукции (ЖЦП) представляет собой совокупность взаимосвязанных процессов изменения состояния продукции при ее использовании. Существует понятие этапа жизненного цикла продукции – условно выделяемой его части, которая характеризуется спецификой производимых на этом этапе работ и конечными результатами.  Рисунок – Этапы жизненного цикла продукции При выделении основных процессов рекомендуется соблюдать следующие правила. Правило 1. Перечень приведенных на рисунке процессов не является обязательным и полным, названия процессов в конкретных организациях могут не совпадать с данным перечнем, процессы можно объединять и исключать в зависимости от целей и особенностей конкретной организации. Здесь важна суть дела: через основные процессы проходят выпускаемая продукция и ее компоненты. Основные процессы, преобразовывая продукцию, повышают ее ценность. Правило 2. Основных процессов должно быть не более 7±2. Эта цифра определена исходя из того, что руководитель, как любой человек, не может эффективно руководить и воспринимать информацию, если количество основных направлений деятельности или источников информации больше девяти. Выявление (выделение) вспомогательных процессов К вспомогательным (обеспечивающим) процессам, как правило, относят такие, которые напрямую не преобразовывают основную продукцию организации, т.е. не добавляют ценности, но являются необходимыми для обеспечения деятельности основных процессов. Результатами таких процессов являются ресурсы для основных процессов. К вспомогательным процессам могут относиться: 1. Управление и обучение персонала; 2. Управление информацией; 3. Управление энергоресурсами; 4. Управление финансами; 5. Управление природными ресурсами и экологией; 6. Административно-хозяйственная деятельность и др. Процессы из данного перечня можно объединять в группы в случае их централизованного выполнения или, наоборот, вводить их в виде функций (работ), выполняемых в составе основных процессов. При выделении вспомогательных процессов целесообразно соблюдать следующие правила. Правило 3. Вспомогательные процессы, в отличие от основных, не добавляют ценности продукции, но повышают ее себестоимость. Правило 4. Количество вспомогательных процессов не должно быть более чем 5±2. В ином случае руководитель теряет управление организацией (см. Правило 2) [3]. Вспомогательные процессы могут быть одинаковыми для нескольких бизнес-процессов. Как основные, так и вспомогательные процессы, в свою очередь, состоят из совокупности подпроцессов (операций, функций). Описание и документирование процессов организации После того, как определены основные и вспомогательные процессы ОУ, составляется реестр (табличное описание) процессов ОУ. Таблица 1 – Пример реестра типовых процессов и видов деятельности ОУ
Идентификационный номер процесса (вида деятельности), приводимый в последнем столбце таблицы , является уникальным именем этого процесса в СК ОУ, на которое можно ссылаться в соответствующих спецификациях процесса, документированных процедурах (ДП), Положениях, Регламентах, рабочих инструкциях и других документах СК, связанных с этим процессом. Какую информацию должен отражать идентификационный номер процесса, каждая организация решает сама. Так, например, для ТГУ идентификационный номер процесса (рисунок 3) будет содержать номер структурного подразделения, которое отвечает за осуществление процесса (в зависимости от владельца процесса), и номер процесса, назначаемый в соответствии с месторасположением в иерархии процессов (в зависимости от метода их схематического описания).  Рисунок – Идентификационный номер процесса (в ТГУ) Идентификация процессов осуществляется централизовано Отделом менеджмента качества при разработке документации процесса. Также любой процесс организации может быть описан графически.  Рисунок – Графическое описание процесса. Процесс представляется в виде блока. Входящая стрелка, присоединенная к блоку слева, обозначает входы процесса. С ее помощью описывают ресурсы (что перерабатывается в рамках процесса). Соответственно, выходящая стрелка, присоединенная к блоку справа, обозначает выходы процесса. С помощью этой стрелки обозначается продукция, производимая в рамках процесса. Входы и выходы процесса могут быть как материальными, так и нематериальными (например, информационными) объектами. Примерами входов и выходов являются: материалы, компоненты, комплектующие изделия, информация и т.п.  Рисунок – Пример графического описания процесса Входящая стрелка, присоединенная к верхней грани блока, представляет процедуру, регламентирующую условия выполнения процесса (как следует выполнять процесс). Этот вид стрелки также называют «управлением». Входящая стрелка, присоединенная к нижней грани блока, представляет механизмы, т.е. те ресурсы, за счет которых (или чем) входы будут преобразовываться в выходы. Так, например, механизмами могут быть оборудование, финансовые средства, персонал, производственное помещение и др. Подробнее об описании процессов см. пункт 5. Спецификация процессов Под спецификацией процесса понимается документ верхнего уровня, в котором зарегистрированы все результаты планирования процесса: цель процесса, входы и выходы процесса, управляющие документы, ресурсы, измерения и анализ, взаимодействия процесса (поставщики/потребители). Для отражения спецификации процессов используется таблица. Определение цели процесса По определению процесс предназначен для преобразования входов в выходы. Первоначально необходимо определить назначение процесса, т.е. главную цель, на достижение которой он направлен. Цель – 1) предмет стремления, то, что надо, желательно осуществить; 2) ожидаемый результат. Цели процессов определяются на основе стратегических целей организации. Стратегические цели организации и установленные цели процессов не должны вступать в противоречие друг с другом. При определении цели процесса необходимо, чтобы эта цель была и измерима и достижима. Достижимость цели определяется оценкой реальности и возможностей выполнения этой цели в заданные промежутки времени. Цель измеряется через характеристики и показатели процесса. Показатели процессов – количественные и/или качественные параметры, характеризующие процесс и его результат. Установление измеримых характеристик и показателей процессов необходимо для обеспечения количественной оценки достижения целей. Определение владельца процесса При выделении процессов необходимо назначать лиц, ответственных за их результативность и эффективность (владельцев процессов). Каждый процесс может иметь только одного владельца. Владелец процесса - должностное лицо, которое имеет в своем распоряжении персонал, инфраструктуру, программное и аппаратное обеспечение, информацию о процессе, управляет ходом процесса и несет ответственность за результаты и эффективность процесса. Владелец процесса в ходе управления планирует (Plan) распределение ресурсов для достижения поставленных целей процесса с максимальной эффективностью. В ходе выполнения (Do) процесса владелец проверяет (контролирует) (Check) ход процесса и ведет оперативное управление процессом, корректируя (активно вмешиваясь в ход процесса (Act)), изменяя запланированное распределение ресурсов, меняя планы, сроки и результаты процесса в соответствии с изменившейся ситуацией. Владелец процесса: Отвечает за управление процессом; Понимает особенности выполнения процесса; Координирует создание инструкций для управления процессом; Ведет отчетность по процессу. Таблица – Спецификация процесса
Выходы процесса После того, как определена цель и владелец процесса, необходимо установить, что является выходами процесса, а также определить их потребителей. Как правило, у процесса бывает несколько выходов. У каждого из этих выходов должен быть один или несколько потребителей. Выход процесса не может существовать сам по себе, кто-то должен потреблять продукт процесса, а иначе он будет работать вхолостую, затрачивая ресурсы и не создавая никакой ценности. Выходы процесса могут быть как материальные – в виде продукта и нематериальные – в виде информации (отчетов, журналов регистрации, справок и др.). В любом случае каждый выход должен представлять для потребителя определенную ценность. Внутри организации каждый процесс имеет свой выход и потребителей. Потребителей выходов разделяют на внутренних и внешних. Например, процесс «Управление кадровым обеспечением» поставляет всем подразделениям организации (т.е. внутренним потребителям) квалифицированный и аттестованный персонал. Выходом процесса является также промежуточный продукт, который не предназначен для клиента или смежника. Например, в соседнее подразделение направляется на согласование разработанный документ. В этом случае называть его выходом не всегда целесообразно. Но если согласующее подразделение предъявляет требования к срокам и форме, то он должен быть зафиксирован как выход. Выходы процесса также могут носить информационный характер, например, отчеты о ходе процесса и его эффективности. Входы процесса П  олучение выходов процесса происходит при преобразовании входов в данный процесс. Входы в процесс – это то, что приходит от других процессов и подвергается преобразованию в выходы. У каждого входа имеется свой поставщик (внутренний и внешний). Процесс также может выступать в роли поставщика входов. Например, для процесса «Маркетинговые исследования» одним из входов является информация о рынке товаров и услуг, которая в ходе процесса преобразуется в выходы: требования и ожидания потребителей, информация о новых видах услуг в образовательной сфере и др., которые, в свою очередь, являются входами в процесс «Планирование образовательной деятельности».Рисунок 6 – Пример выделения входов Управление процесса Управление (управляющая документация) - условия выполнения процесса (документация, на основании которой осуществляется выполнение процесса). В общем случае всю документацию организации можно разделить на два класса: документация внешнего происхождения и документация внутреннего происхождения. Документация внешнего происхождения – все те документы, которые создаются вне организации и поступают в организацию из внешних источников (например, законы РФ, постановления правительства, государственные и международные стандарты, нормативные документы, справочники, правила эксплуатации установок повышенной опасности и др.). Регламентирующая (управляющая) документация внутреннего происхождения – это все документы, создаваемые внутри организации для ее функционирования (например, инструкции, положения, регламенты, планы, программы, приказы, распоряжения и др.). Механизмы процесса Механизмы процесса - ресурсы, обеспечивающие выполнение процесса. То есть это то, что изначально есть у владельца процесса: персонал, оборудование, технологии, помещение и т.д.; в ходе осуществления процесса они используются для того, чтобы преобразовать входы в выходы. Так, например, для того, чтобы провести обучение студентов работе на компьютере, необходимы: оргтехника, специализированный персонал, аудитория и др. Определение показателей процесса Результат процесса может быть как положительным, так и отрицательным. Все, что получилось на выходе процесса, должно быть проверено, прежде чем этот выход использует потребитель. Продукт на выходе может пройти процедуру проверки успешно, а может быть отклонен и направлен на доработку или утилизацию. Чтобы владелец мог управлять процессом (влиять на ход процесса и его результат), должны быть установлены показатели процесса (таблица 4), адекватно отражающие его ход и на основании которых производятся другие измерения (делаются прогнозы). Показатели процессов – количественные и/или качественные параметры, характеризующие процесс и его результат. По этим показателям (в том числе экономическим) владелец процесса обязан регулярно отчитываться перед высшим руководством о результатах своей деятельности. Для каждого показателя устанавливается норматив, который позволяет определять, достигнут ли результат процесса. Показатели процесса способствуют принятию решений руководством, позволяют представить, где именно они находятся, оценить прогресс проекта (продукта, процесса) и служат основой для улучшения и совершенствования деятельности предприятия (процесса, продукции). При определении показателей процессов рекомендуется ответить на вопросы, представленные в таблице. Таблица – Перечень вопросов, задаваемых при определении показателей
В качестве примеров показателей можно привести следующие: кол-во клиентов; удовлетворенность клиентов; количество жалоб клиентов; количество новых клиентов; процент дохода от новых клиентов; затраты на обслуживание клиента; средние затраты на процесс; время ответа на вопрос клиента; процент брака; затраты на НИОКР; время необходимое для выхода на рынок новых продуктов/услуг и др. Построение матрицы ответственности Для совокупности выделенных процессов (основных и вспомогательных) составляется Матрица ответственности. При построении матрицы распределения ответственности необходимо соблюдать основное правило – за каждый процесс должен быть назначен один ответственный. Таблица – Матрица ответственности
К – контролирующий выполнение процесса. О – ответственный за проведение и результат данного процесса (работы, функции). У – участвует в проведении данного процесса (работы, функции). И – получает информацию о результатах и/или ходе данного процесса (работы, функции). Правило. В каждом столбце Матрицы может быть только одна буква О. То есть, за каждую работу может быть назначен только один ответственный. Букв У и И может быть несколько, или не быть вообще, но, как правило, Владелец бизнес-процесса должен участвовать или получать информацию обо всех процессах. Ответственность, закрепленная в Матрице, должна быть внесена в Должностную инструкцию данного сотрудника. Матрица ответственности строится также и для подпроцессов по такому же принципу. Метод описания процессов Существует множество методов описания процессов. Например один из таких методов: Шаг 1. Определить виды деятельности, осуществляемые каждым подразделением. На первом шаге рассматривается деятельность каждого подразделения в отдельности. Более четко определяются границы подразделений. Для каждого подразделения выделяются выполняемые им виды деятельности.  Рисунок - Определение перечня видов деятельности, выполняемых в подразделении Результатом работ на шаге 1 является перечень выполняемых в подразделении видов деятельности. Шаг 2. Для каждого подразделения сгруппировать виды деятельности по процессам. При выполнении шага 2, виды деятельности каждого подразделения группируются по процессам. Каждый вид деятельности подразделения должен быть отнесен хотя бы к одному процессу. При разделении часть видов деятельности может войти в основные процессы организации. Другая часть видов деятельности - во вспомогательные процессы. В каждом подразделении может быть выделен один или несколько процессов. Результатом работы на шаге 2 является четкое понимание деятельности подразделений за счет ее структуризации по основным и вспомогательным процессам (т.е. процессам 1-го уровня).  Рисунок - Группировка видов деятельности подразделения по процессам Шаг 3. Определить спецификацию для каждого процесса Для каждого выделенного в подразделении процесса (основного, вспомогательного) определяется его спецификация. Шаг 4. Определить подпроцессы (процессы 2 уровня) основных и вспомогательных процессов, выделенных на шаге 2, а также процессов 3-го уровня Если при шаге 2 в один процесс были объединены несколько видов деятельности, то они принимаются в качестве подпроцессов этого процесса (2-ой уровень). Тогда, в качестве процессов 3 уровня, для рассматриваемых видов деятельности, выступает последовательность выполняемых функций. Если же в процесс выделен только один вид деятельности, то при определении процессов 2-го уровня рассматривается последовательность функций. Процессы 3-го уровня в данном случае не определяют. Названия подпроцессов должны быть краткими, отражающими суть выполняемых функций.  Рисунок 9 – Процесс, состоящий из нескольких видов деятельности  Рисунок 10 – Процесс, состоящий из одного вида деятельности Шаг 5. Определить спецификацию для процессов 2 и 3-ого уровней. Спецификация на процессы 2 и 3-его уровня составляется аналогично шагу 3. Шаг 6.Составить реестр процессов и подпроцессов Процессы и входящие в них подпроцессы (процессы 2 и 3-го уровня) заносятся в реестр процессов. Шаг 7. Составить матрицу ответственности на каждый процесс (1, 2 и 3 уровня). После того, как определены и описаны процессы и подпроцессы, можно приступать к разработке Матриц ответственности. Алгоритм описания процессов  Рисунок – Алгоритм описания процессов | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||