Лекции по "Бизнес планирование"

 

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

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

 

  

2.3. Пример показателей  процессов отдела кадров юридической  службы:  

 

1. Текучесть  кадров.

2. Качество набора и обучения: отношение выдержавших испытательный срок к …

3. Срок заполнения  вакансий.

4. Средний возраст  персонала.

5. Средний стаж  работы в организации.

6. Количество  жалоб сотрудников.

7. Суммы штрафных санкций,  выплаченных в отчетный период.

8. Количество конфликтов  с контрагентами …  

 

Параграф 3.

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

 

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

 

Рассмотрим  следующую практическую ситуацию:

 

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

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

 

 

 

 

 

  

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

 

 

 

  

Предлагается  следующее решение:

Определяется  тот срок, в течение которого владелец процесса 2 должен улучшить свой процесс, выход которого должен соответствовать  средним значения показателя на входе процесса 1, при этом на данный период устанавливаются некие границы показателя, которым должен соответствовать выход этого процесса. В этот период времени владелец процесса 2 отчитывается перед руководителями, при этом  отчет входят меры, принятые для улучшения … (wtf?!) (хаха :D, десятипальцевый рулит - прим. Дроздова).

 

 

 

 
   

 

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

 

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

 

Параграф 4.

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

 

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

 

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

 

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

 

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

 

Поэтому для  оценки и анализа процесса важно:

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

 

   

 

Лекция 5 

 

 

Моделирование бизнес-процессов, описание бизнес-процессов

с помощью  различных методик и нотаций.

 

 

  

Общие положения, нотации, IDEF0.

 

Параграф 1.

Описание бизнес-процессов с помощью графических схем.  

 

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

 

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

 

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

 

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

1. Цель проекта (что и для чего, каким образом предполагается менять в организации);
2. Требования к информации, характеризующей бизнес-процесс и необходимой для анализа и принятия решений в рамках конкретного проекта;
3. Возможности методики и соответствующего программного продукта в зависимости от требований к информации (пункт 2);
4. Возможности программных продуктов по документированию процессов.

 

  

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

1) документирование

2) с целью  анализа и реорганизации процесса.  

 

Целью реорганизации  может быть повышение результативности процесса, внедрение информационных системы и подготовки к организации стандартов ISO 9000.  

 

…  

 

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

1. Какие функции необходимо выпонить для получения заданного конечного результата;
2. Кто выполняет функции процесса;
3. Как происходит взаимодействие исполнителей при выполнении этих функций, в какой последовательности;
4. Какие механизмы управления существуют в рамках рассиваемого бизнес-процесса;
5. Какие входящие документы использует каждая функция процесса;
6. Какие исходящие документы генерирует каждая функция процесса;
7. Какие ресурсы необходимы для выполнения каждой функции;
8. Какая документация регламентирует выполнение каждой функции;
9. Какие параметры характеризуют выполнение каждой функции в отдельности и процесса в целом.

 

  

 

Параграф 2.

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

 

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

 

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

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

 

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

 

Второй важнейшей  методологией для описания процессов  является методология IDEF3. Формально эта методология называется методологией описания работ. IDEF3 предназначен для описания бизнес-процессов и очень близка к алгоритмическим методам построения схем процессов. Основа методологии IDEF3 состоит в построении бизнес-процессов по принципу последовательно выполняемых по времени работ. Методология IDEF3 лежит в основе популярной в настоящее время методологии ARIS eEPC. Еще одной группой методологий, активно используемой на практике является нотация DFD. Эта нотация предназначена для описания потоков данных, позволяет отразить последовательность для описания потоков данных, которые используются в процессе выполнения работ в рамках единого процесса. Кроме того, нотация DFD позволяет описывать потоки документов и потоки материальных ресурсов. Методология DFD может эффективно использоваться для описания процессов при внедрении процессного подхода при управлении организацией, т.к. позволяет максимально снизить субъективность описания бизнес-процессов. Схемы процессов DFD позволяет выявить основные потоки данных в организации, что важно для последующего создания моделей структуры данных и разработки требований к информационной системе организаций. Одной из современных методологий описания процессов является методология ARIS. Это было разработано немецкой компанией и основа ее состоит в том, что любая организация рассивается как сложная система, описание которой строится из 4-х основных групп моделей:

1. Модель организационной структуры;
2. Модель функций;
3. Модель данных;
4. Модель бизнес-процессов;

 

  

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

 

Методология IDEF3.

 

Нотация IDEF3 является второй важнейшей нотацией (после IDEF0) и предназначена для описания потоков работ (Work Flow modeling). IDEF3 широко используется для создания моделей бизнес-процессов организации на нижнем уровне (при описании работ, выполняемым в подразделениях и на рабочих местах). Следует отметить, что нотация IDEF3 была взята за основу при создании методики описания процессов ARIS eEPC – «расширенной цепочки процесса, управляемого событиями».

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

Таблица 2.2.1. Виды объектов для  отображения бизнес-процессов в  нотации IDEF3

 

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

На рисунке 2.2.1. приведен пример бизнес-процесса в  нотации IDEF3 под названием «Обработать заявку клиента». Рассматриваемый процесс является частью более общего процесса «Сбыт готовой продукции». Процесс начинается с поступления заявки клиента, которую обрабатывает функция «Выполнить учет заказа в системе». По ходу ее выполнения данные заказа клиента регистрируются в системе автоматизации (например, в файле Excel). Затем менеджер отдела сбыта выполняет проверку на соответствие номенклатуре (функция «Выполнить анализ на соответствие номенклатуре»). Результатом выполнения данной функции могут быть два события: первое – «заказ соответствует номенклатуре изделий, производимых организацией», второе – «заказ не соответствует номенклатуре изделий». Для отражения этих событий в модели процесса используется логический оператор «исключающее или» (кстати, в спецификации IDEF3 логические операторы называются «перекрестками»). После этого логического оператора процесс ветвится. В случае несоответствия заказа номенклатуре выполняется нижняя ветка процесса, а именно функции: «Уведомить клиента о невозможности выполнения заказа» и «Внести заказ клиента в статистику неудовлетворенного спроса».

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