Управление организацией на основе бизнес-процессов

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

2. документирование взаимоотношений между процессами приводит к «перетягиванию одеяла (ресурсов)» друг у друга или к «перекладыванию ответственности» друг на друга и как следствие этого, к конфликтам;

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

Размещено на http://www.allbest.ru/

Рис.7. Шаг 2.Регламентация процессов

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

Шаг 3. Оптимизация процессов

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

Размещено на http://www.allbest.ru/

Рис.8 Оптимизация процессов и делегирование полномочий вниз

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

Тема 3. Описание бизнес-процессов

Уровни описания процессов (декомпозиция). Цели описания бизнес-процессов. Способы описания бизнес-процессов. Вертикальное и горизонтальное описание бизнес-процессов. Этапы описания бизнес-процессов. Стандарты описания бизнес-процессов. Правила, применяемые при описании бизнес-процессов. Форматы и средства описания бизнес-процессов.

Уровни описания процессов (декомпозиция).

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

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

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

Каждая из методик моделирования имеет право на существование, а также свои достоинства и недостатки.

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

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

Что же представляет собой многоуровневое моделирование бизнес-процессов? Функция (одно действие) процесса может представлять собой отдельный процесс и раскрываться уровнем ниже в виде отдельного процесса состоящего из нескольких операций.

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

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

Цели описания бизнес-процессов.

Описание бизнес-процессов производится для следующих целей:

· Документирование и оптимизация построения бизнеса.

· Разработка новых схем ведения бизнеса.

· Разработка IT системы.

· Разработка регламентирующих документов.

Способы описания бизнес-процессов.

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

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

Недостатком текстового описания являются:

· Трудность восприятия информации

· Невозможность структурированного описания сложных процессов

· Непригодность к применению ”продвинутых” методов анализа и оптимизации.

Наиболее приемлемым является комбинированный способ описания, когда графическая информация сопровождается текстовыми комментариями.

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

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

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

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

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

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

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

6. Детализация бизнес-процессов должна происходить до разумных пределов: первые 20% усилий приносят 80% результата, поэтому дальнейшее детализирования не будет столь эффективным.

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

Вертикальное и горизонтальное описание бизнес-процессов.

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

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

Рис 9. Вертикальное и горизонтальное описание бизнес-процессов

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

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

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

Рис 10. Схема окружения бизнес-процесса

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

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

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

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

Стандарты описания бизнес-процессов.

Стандарт DFD

Для описания процессов верхнего уровня используется стандарт описания бизнес-процессов DFD - Data Flow Diagram, что переводится как диаграмма потоков данных.

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

Рис 11. Диаграмма потоков данных

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

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

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

Стандарт WFD

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

Рис 12. Диаграмма потоков работ

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

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

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

Другие стандарты описания.

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

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

Правило 1. Названия работы нужно формулировать согласно следующей формуле

Название работы = Действие + Объект, над которым действие осуществляется

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

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

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

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

Название потока = Объект, предоставляющий поток + Статус объекта

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

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

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

У каждого формата есть свои преимущества и недостатки.

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

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

Из этого следует и основной недостаток - слабая формализация описаний.

Для описания процесса в таблицах можно использовать следующий формат

№	Наименование функции	Исполнитель	Ресурсы (в т.ч. документы, программы)
Входящие	Исходящие

Графа «№» - показывает порядковый номер функции. Для описания декомпозиции процесса можно использовать разряды номера функции. Например, у функции №7 есть три подфункции, их номера начинаются с номера декомпозируемой функции: 7.1; 7.2; 7.3.

Графа «Наименование функции» - включает название работы/ операции.

Графа «Исполнитель» обозначает сотрудника (должность) выполняющего соответствующую работу.

Графы «Ресурсы» включают всю совокупность используемых в процессе предметов и средств труда, а также документов.

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

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

IDEF (Integration Definition for Function Modeling - методология функционального моделирования) - семейство совместно используемых методов для процесса моделирования. Первоначально разработаны в военных ведомствах США. На сегодня эта техника описания бизнес-процессов получила наибольшее распространение в мире и принята как стандарт во многих странах. В России па момент написания Методики это зафиксировано в Р50.1.028-2001 "Информационные технологии поддержки жизненного цикла изделия. Методология функционального моделирования", а также в проекте стандарта: ГОСТ Р ИСО 10303-203 "Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен данными. Протокол применения 203 - Проектирование изделия управляемой конфигурации". Концепция реализована во многих программных продуктах, наиболее популярным из которых на сегодняшний день является пакет BPW1N/HRWIN.

UML (Unified Modeling Language - унифицированный язык моделирования) - наиболее систематизированный подход к описанию любых систем, в т.ч. и бизнес-процессов. Позволяет перейти от описаний системы непосредственно к написанию компьютерных программ и - в значительной степени - сформировать основу будущего средства автоматизации. UML принят как стандарт для проектирования информационных систем более чем 60-ю ведущими разработчиками программного обеспечения, в т.ч. и Microsoft. Разработчик языка - некоммерческий консорциум Object Management Group (0MG). Наиболее популярным инструментом, поддерживающими язык UML, является Rational Rose.

ARIS (ARchitecture of Integrated Information Systems - проектирование интегрированных информационных систем) - германская технология описания предприятий. Разработана профессором Августом Вильгельмом Шеером (компания IDS Scheer AG). Используется как встроенное средство в одну из крупнейших на сегодняшний день систем автоматизации предприятий - SAP R/3. Пока имеет меньшее распространение, чем вышеперечисленные системы. При этом единственная методология, где фирма - разработчик является и производителем одноименного программного продукта, поддерживающего данную методологию. Этим обеспечивается практически единовременное совершенствование методологии и программной поддержки.

IDEF

Начнем рассмотрение с концепции IDEF как более простой и доступной в виде большого числа программных продуктов, поддерживающих эту концепцию (BPWIN, БИТ-Мастер, MS Visio и др.).

IDEF технология используется, начиная с конца 1980-х годов. Department of Defense USA (Министерство обороны.

США) является основным пользователем данной технологии. Ею пользуются также некоторые крупные корпорации в США.

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

UML как средство описания бизнес-процессов.

UML - объектно-ориентированный язык моделирования для описания сложных систем. Также весьма распространен, существуют многочисленные инструменты для проектирования систем на данном языке, например: Rational Rose, Paradigm Plus, 4Keeps, MS Visio 2002 XP и др.

Данный язык описания содержит 8 различных типов диаграмм:

Диаграмма вариантов использования - показывает статический вид системы с точки зрения конечного пользователя.

Диаграмма классов - отражает статичные отношения между элементами модели.

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

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

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

Диаграмма компонентов - статическое отображение организации совокупности компонентов и существующих между ними зависимостей.

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

Диаграмма деятельности состоит из следующих элементов:

* Точка инициации - начало процесса.

* Точка завершения - окончание процесса. 29

* Действие - функция, работа или операция.

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

* Исполнитель (роль, персона, должность, оргзвено).

* Решение - условие перехода при разветвлениях процесса.

* Объект - используемый в процессе ресурс.

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

еЕРС - событийно-функциональные диаграммы

Событийно-функциональные диаграммы (сокращенно еЕРС - extended event-process chain),

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

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

* отправка заказа

* доставка товара

* разработка рекламного макета. Примеры событий:

* получена заявка от клиента

* товар доставлен

* проверка качества проведена

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

* и--®

* или -®

* исключающее или - ®

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

Тема 4. Управление организацией на основе бизнес-процессов

Сегментирование деятельности организации на систему процессов. Функции системы менеджмента процесса. Наложение требований разделов стандартов МС ИСО 9001:2000 на схему управления процессом. Распределение функций между процессами. Процесс управления организацией. Управление бизнес-процессами. Система показателей для управления процессам. Регламентация бизнес-процессов в организации. Система документации процесса. Распределение ответственности за работы в процессе. Согласование входов и выходов между процессами.

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

Процесс, бизнес - процесс, процессное управление, менеджмент качества - вот те понятия, которые многократно употребляются в последнее время как руководителями компании, так и консультантами. Но, к сожалению, ни бизнес процесс, ни процессный подход применительно к бизнес - целям компании не определены в каких- либо нормативных документах: стандартах, рекомендациях министерств и т.п. Исключение составляют, пожалуй, стандарты ИСО серии 9000:2000[1,2,3]. В главе вводится новое понятие СИГМЕТИРОВАННОГО УПРАВЛЕНИЯ БИЗНЕС ПРОЦЕССАМИ (ПРОЦЕССАМИ) компании.

Базовым понятием рассматриваемой концепции управления является понятие процесса - деятельности, преобразующей входы в выходы, представляющие ценность для потребителя .Такое определение процесса соответствует пониманию, сформулированному в стандартах ИСО серии 9000:2000 [1,2].

Что значит выделить процессы? Это значит разграничить, или СЕГМЕНТИРОВАТЬ, деятельность путём определения входов/выходов и функций, составляющих процесс.

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

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

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

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

Функции системы менеджмента процесса.

Функции системы менеджмента процесса формулировались неоднократно. Например, пять основных функций менеджмента, определённые А.Файолем.

· Планирование;

· Организация;

· Контроль;

· Координация;

· Мотивация;

С позиции системы менеджмента процессного управления, все эти пять функций необходимы для управления процессом. Единственное уточнение, которое можно сделать: функция «мотивация» входит в состав деятельности менеджера (владельца процесса)как часть управления ресурсами. С точки зрения авторов, персонал является одним из ресурсов процесса, а мотивация персонала - одним из основных способов управления персоналом как ресурсом процесса. Стандарты МС ИСО серии 9000 версии 2000 г. так же рассматривают персонал, как один из ресурсов процесса.

Менеджмент процесса заключается в том, что владелец процесса или с установленной периодичностью контролирует ход процесса и принимает управленческие решения в случаях отклонения параметров процесса от критериев, установлены для нормального хода процесса. Владелец процесса в ходе управления планирует (Plan) распределение ресурсов для достижения поставленных целей процесса с максимальной эффективностью. Ход выполнения (Do) процесса исполнителями, владелец проверяет (Check) по информации, которая поступает с контрольных точек. Владелец процесса ведёт оперативное управление процессом, управляя (активно вмешиваясь в ход процесса-Act), изменяя запланированное распределение ресурсов, меняя планы, сроки и требования к результатам процесса в соответствии с изменившейся ситуацией. Деятельность владельца процесса носит плановый характер при нормальном ходе процесса или неплановый - в случаях возникновения проблемных ситуаций, требующих немедленного вмешательства.

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

А) контроль результатов процесса, в том числе:

· Контроль продукта на выходе и сбор информации о показателях продукта;

· Контроль за использованием ресурсов процесса и сбор информации о показателях эффективности процесса;

· Получение своевременной, объективной и адекватной информации об удовлетворенности клиентов процесса;

Б) регламентированную схему анализа результатов процесса и принятия корректирующих и предупреждающих действий;

В) введение принятых изменений в документацию процесса;

Наложение требований разделов стандартов МС ИСО 9001:2000 на схему управления процессом.

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

Требования разделов:

1. Ответственность руководства

В соответствиями с требованиями пунктов и разделов стандарта ИСО 9001:2000, организация ( вышестоящий руководитель) должна:

а) планировать и устанавливать цели в области качества ;

б) устанавливать ответственность, полномочия и взаимосвязи ;

в) вести регулярный анализ результатов процессов и принимать управленческие решения, в том числе:

· организовывать получение входных данных для анализа;

· приятые решения оформлять как результаты анализа.

2. Управление ресурсами

В стандарте МС ИСО 9001:2000 установлены требования по управлению:

а) человеческими ресурсами;

б) инфраструктурой ;

в)производственной средой.

3. Выпуск продукции

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

4. Измерения, анализ и улучшения

Этот раздел посвящён организации оперативного управления процессом, направленной на непрерывное улучшение его показателей.

Владелец процесса в ходе управления должен:

а) разработать и внедрить систему получения информации об удовлетворённости потребителя;

б) получать информацию о результатах внутренних проверок

в) вести мониторинг и измерение процесса;

г) вести мониторинг и измерение продукции;

д) получать информацию от поставщиков процесса;

е) вести анализ хода процесса;

ж) принимать управленческие решения для непрерывного повышения результативности;

з) разрабатывать корректирующие действия по зафиксированным отклонениям;

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

Распределение функций между процессами.

Виды деятельности, которые составляют процесс, делятся на две основные части:

· технология выполнения процесса или преобразования входов в выходы (способ выполнения деятельности - обычно хорошо регламентированная часть процесса);

· система менеджмента процесса (способ управления деятельностью - обычно наименее регламентированный вид деятельности).

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

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

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

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

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



План реализации Отдел снабжения

Производство План Отдел снабжения Бюджет

Производства закупок

Расчёт плана Расчет плана и

Производства бюджета закупок

Складские

остатки

Бюро материального

Нормарования Нормы Склад

Расхода

Расчёт норм расхода Снятие остатков

Рис. 13 Функцию определения плана закупок и потребности в финансах выполняет отдел снабжения

Вариант 2 (рис. 14) Производство выполняет функцию расчёта планов производства и закупок, исходя из норм расхода, складских остатков и планов производства (продаж). Отдел снабжения выполняет функцию расчёта бюджета закупок, на основании плана закупок.

План реализации Отдел снабжения

Производство План Расчёт бюджета Бюджет

Производства закупок закупок

Расчёт плана

Производства и закупок

Нормы Складские

расхода остатки

Бюро материального

нормирования Склад

Расчёт норм расхода Снятие остатков

Рис. 14 Другое распределение функций при проведении закупок в организации

Процесс управления организацией.

Управление бизнес-процессами.

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

-собственники (инвесторы);

-клиенты организации;

-поставщики;

-сотрудники;

-общество.

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

-отдел стратегического развития;

-административный аппарат;

-частично службы маркетинга;

-рекламы и PR.

Для процесса управления организацией должны выполняться следующие функции:

· сбор и анализ данных управленческого учёта (финансовая информация, данные о производительности труда, данные о распределении ресурсов, данные о компетенции персонала);

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

Проведение PEST-анализа внешней информации;

· подготовка проектов управленческих решений на основе проведённых анализов данных;

· контроль исполнения решений, принятых топ - менеджментом .

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

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

· кто является основным потребителем результатов деятельности?

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

Цель управления процессом заключается в непрерывном улучшении его показателей.

Система показателей для управления процессам.

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

а) информация о качестве продукции или услуги, степени её соответствия, установленным и прогнозируемым требованиям клиента, стабильности и воспроизводимости параметров продукта («Что мы произвели?» или «Какой результат мы получили?»);

б) информация о качестве процесса, его эффективности и ресурсоёмкости, стабильности и воспроизводимости параметров процесса («Какой ценой мы достигли этого результата?»);

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

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

· однозначная связь со стратегическими показателями организации (увязка с верхним уровнем);

· «прозрачность» для руководителей организации;

· удобство для владельцев процессов, управляющих своими процессами на основе этих показателей;

· понятность персоналу, выполняющему процесс;

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

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

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

а) достаточно полной, чтобы адекватно оценивать результаты процессов и процедур;

б) её стоимость должна быть адекватна ценности информации;

в) достаточно наглядной и простой для анализа и сопоставления информации.

Регламентация бизнес-процессов в организации.

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

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

· ресурсы, необходимые для выполнения подразделением своих функций;

· систему мониторинга показателей подразделения;

· систему и регламент управления подразделением (процессом);

· требования по отчётности о ходе работ перед вышестоящим руководителем;

· требования к входам и выходам (взаимодействие с потребителями, поставщиками и субподрядчиками).

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

Система документации процесса.

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

«Утверждаю» (руководитель сотрудника)

Должностная инструкция.

1. Общие положения (назначается, освобождается, подчиняется).

2. Должностные обязанности (из матрицы ответственности подразделения):

2.1.Отвечает за ______ «О»,

2.2.Участвует в _____ «У»,

2.3.Информируется о ______ «И».

3.Требования к квалификации (стаж, квалификация, опыт работы, профиль требований).

4. Права (решение вопросов, получение информации, социальный пакет).

5. Ответственость (материальная, административная, уголовная).

6. Взаимодействие (с кем, по каким вопросам, кому и что передаёт, от кого и что получает).

Подписи: (Сотрудник, лицо его замещающее, юрист)

Положение: Регламент периодических работ (ежедневных, еженедельных, ежемесячных……..)

До 05 числа подать ______ отчёт за предыдущий месяц

До 07 числа подать _______заявку _____на следующий месяц

Рис.15 Упрощённая структура должностной инструкции

Дополнительное отличие предложенной формы должностной инструкции

От типовых инструкций, списанных из справочников, заключается в том, что:

· необходимо внести взаимодействие сотрудников между собой;

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

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

Распределение ответственности за работы в процессе.

Система управления процессом, как и любая функция процесса, подлежит документированию.

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

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

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

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

Матрица ответственности

Функция/Сотрудник	Владелец	Исполнитель 1	Исполнитель 2	Исполнитель 3
Планирование	О	У	И	И
Функция 1	У	И		О
Функция 2	И	У	О
Функция 3	И	О		У
Функция 4	У	О	У
Контроль выполнения	О	У		И
Управление процессом	О	У	И
Отчётность о ходе процесса	О	У

О - ответственный, У - участвует в работе, И - получает информацию о результате

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

Правило 1. В каждой строке матрицы может стоять только одна буква «О» (ответственный ). То есть за каждую функцию может отвечать только один сотрудник. Букв «У» и «И» может быть несколько, так как участвовать и получать информацию о работах могут несколько сотрудников.

Правило 2. В столбце владельца не должно быть пустых клеток. То есть руководитель или отвечает за функцию, или участвует в её выполнении, или получает информацию о результате.

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

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

· как, когда и на основании чего производится им планирование работ по процессу;

· по каким показателям и критериям, в какие сроки владелец процесса контролирует ход выполнения процесса;

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

· по какой форме и показателям, в какие сроки владелец отчитывается перед вышестоящим руководством о ходе процесса.

Согласование входов и выходов между процессами.

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

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

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

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

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

Тема 5. Моделирование бизнес-процессов

Полная бизнес-модель компании

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

Рис. 16 Обобщенная схема организационного бизнес - моделирования

Определение миссии, на наш взгляд, наиболее полно представлено в нормативном акте, определенном ISO [ISO-15704]. Под миссией понимается как деятельность организации, так и механизмы, использование которых позволяет достичь поставленных целей.

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

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

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

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

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

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

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

На этом этапе бизнес - моделирования формируется общепризнанный набор основополагающих внутрифирменных регламентов: