Файл: Проектирование реализации операций бизнес-процесса «Совершенствование существующих продуктов».pdf

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

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

2) кто выполняет функции процесса;

3) как происходит взаимодействие исполнителей при выполнении этих функций, в какой последовательности;

4) какие механизмы управления существуют в рамках рассматриваемого бизнес-процесса;

5) какие входящие документы/информацию использует каждая функция процесса;

6) какие исходящие документы/информацию генерирует каждая функция процесса;

7) какие ресурсы необходимы для выполнения каждой функции процесса;

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

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

Часто ставится задача локального описания некоторых выделенных бизнес-процессов на первом этапе (1-3-й месяц), следующих – на втором (4-6-й месяц) и т.д. При таком подходе приходится выделять часть процессов действующей организации и заниматься их описанием. В этом случае «ускоренному» или, говоря другими словами, «неполному» методу описания бизнес-процессов, по-видимому, нет альтернативы. Сделаем сравнительный анализ (см табл. 1) методологий «полного» и «ускоренного» описания бизнес процессов[7].

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

Таблица 1

Сравнительный анализ методологий «ускоренного» и «полного» описания бизнес-процессов.

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

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

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

На четвертом шаге при «упрощенной» методологии формируется перечень функций, входящих в процесс. Рабочей группе приходится собирать информацию путем интервьюирования или анкетирования сотрудников и руководителей функциональных подразделений организации. Полученные при выполнении шага 4 функции должны быть приписаны к конкретным функциональным подразделениям организации. Эта задача решается на шаге 5. На первый взгляд она кажется простой, но на практике решается достаточно сложно, т.к. возникают противоречия по распределению ответственности и полномочий между руководителями функциональных подразделений. Подчеркнем, что такая ситуация обусловлена субъективностью определения границ бизнес-процессов и распределения функций между ними. Некоторую часть функций, вероятно, затруднительно будет отнести к какому-либо процессу верхнего уровня. При внимательном рассмотрении, такие функции могут оказаться внутренними функциями подразделения. Среди них могут быть и такие, которые не нужны ни подразделению, ни организации в целом и подлежат устранению. Имея формальные перечни процессов, входящих в них функций, входов и выходов можно заняться формированием схем процессов (шаг 6) при помощи выбранной нотации (нотации ARIS, стандарты IDEF, DFD, блок-схемы и т.д). Разработанные модели бизнес-процессов документируются (шаг 7), т.е. создается комплект документов, описывающий процессы. К числу таких документов можно отнести:

1) «регламент выполнения процесса»;

2) положения о подразделениях;

3) должностные инструкции исполнителей;

4) рабочие инструкции исполнителей.

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

К недостаткам данного метода можно отнести:

1) субъективность определения перечня процессов верхнего уровня и привязки к ним внешних входов/выходов;

2) сложность и субъективность определения внутренних входов/выходов для основных и вспомогательных процессов;

3) субъективность определения вспомогательных процессов;

4) сложность и субъективность отнесения функций организации к тем или иным процессам;

5) при детальном описании границы процессов подвержены сильным изменениям;

6) субъективность при детальном описания процессов в части набора включаемых в процесс функций и взаимодействия между ними;

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

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

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

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

Бизнес-процессы организации, представленные в виде плоских процессов, на самом деле являются объемными. Попытка отобразить «объемность» процессов показана на рис.2.

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

Рисунок 2. «Объемные» бизнес-процессы.

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

К недостаткам данного метода можно отнести:

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

2) значительная длительность описания (8-12 месяцев);

3) сложность компоновки бизнес-процессов организации из бизнес-процессов подразделений.

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

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

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