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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В большинстве современных CASE-систем применяются методологии структурного анализа и проектирования. Большой популярностью пользуется для описания бизнес-процессов две нотаций это семейство IDEF диаграмм, а также нотация ARIS eEPC.

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

Нотация ARIS eEPC расшифровывается следующим образом – extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером.

Сравнительный анализ нотаций ARIS/IDEF и продуктов их поддерживающих (ARIS Toolset/BPWin) [30] показал функциональные возможности инструментальных средств моделирования ARIS Toolset и BPWin можно корректно сравнивать только по отношению к определенному кругу задач. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого.

 Скачать реферат