Материал: Проектирование бизнес-процесса "Прием заказа на оказание услуги"

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

• 3. Моделирование в SADT означает создание диаграмм А0 и А-0. Эти две диаграммы полностью рассказывают все об изучаемой системе с минимальной степенью детализации. Прежде чем начать моделирование необходимо подготовиться к нему, собрать информацию, декомпозировать объект исследования (декомпозиция - диаграмма А0 освещает наиболее важные функции и объекты системы), затем обобщить эту декомпозицию (диаграмма А-0 трактует систему как черный ящик, дает ей название и определяет наиболее важные входы, управления, выходы и механизмы):
• 3.1. Выбор цели и точки зрения.
• 3.2. Составление списка данных. При этом лучше, если данных больше, чем меньше. Данные можно сразу группировать по типам.
• 3.3. Составление списка функций. Функции системы тоже лучше объединить по типу используемых данных. Затем функции объединяются в группы (от трех до шести). Желательно, чтобы эти группы имели один и тот же уровень сложности, содержали примерно одинаковый объем действий и функции в каждой из них имели сходные операции и цели.
• 3.4. Построение и обобщение диаграммы А0 (А0 - А-0). Для любой SADT-диаграммы есть родительская диаграмма, содержащая ее контекст. Контекстом для А0 служит А-0, представляющая обобщение всей модели. Эта диаграмма имеет несколько назначений: она объявляет общую функцию всей системы, дает множество основных типов или наборов данных, которые использует или производит система, указывает взаимоотношения между основными типами данных, производя их разграничение.
• 3.5. Декомпозиция ограниченного объекта. Начало процесса декомпозиции заключается в выборе блока рассматриваемой диаграммы и рассмотрении объекта, определяемого этим блоком и его дугами. При этом надо учесть, что рассматривать следует в первую очередь такой блок, декомпозиция которого выявит многие аспекты диаграммы А0 и будет оказывать большее влияние на будущие декомпозиции других блоков этой системы. При выборе самого содержательного блока нужно учесть и доминирование, и функциональную сложность и понятность. Лучшим блоком для первой декомпозиции будет тот, который позволит наиболее глубоко проникнуть в суть рассматриваемой системы.
• 3.6. Итерационный процесс рецензирования.
• 3.7. Завершение моделирования. Декомпозиция модели или ее части прекращается, если модель достигла уровня детализации, достаточного для достижения цели. Декомпозиция блока может быть прекращена, если окажется, что функции блока очень сходны с другой частью модели, которая уже декомпозирована. Таким образом, достаточность деталей, изменение уровня абстракции, изменение точки зрения и сходная функциональность являются основными критериями для прекращения декомпозиции.
• 3.8. Документирование См.: Калянов, Г. Н. CASE-технологии. Структурный системный анализ (автоматизация и применение) / Г.Н. Калянов. - М:, Лори, 2002. - С.76-80..

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

Этап 3. Оценка оптимальности и оптимизация бизнес-процессов.

Данный этап является ключевым в ходе всего проекта, так как от качества его выполнения зависит оптимальность будущей деятельности организации. При проведении оценки оптимальности, анализу подвергаются следующие параметры бизнес-процесса: обоснованность и достоверность исходных данных ("входы"); полнота и своевременность управляющих воздействий, их наличие; оптимальность действий в рамках выполнения процедур бизнес-процесса; оптимальность сроков выполнения работ; достаточность ресурсов; качество, обоснованность и достоверность конечных результатов ("выходы") и их достаточность для реализации последующих бизнес-процессов.

Проведение оценки оптимальности по перечисленным параметрам приводит к достижению следующих результатов:

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

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

Этап 4. Организация внедрения изменений.

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

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

• - проведение инструктажа сотрудников, ответственных за проведение изменений с целью разъяснения целей и мероприятий, порядка и форм внедрения новых моделей.
• - мониторинг проведения опытной эксплуатации новых стандартов функционирования Компании с целью выявления отклонений разработанных моделей бизнес-процессов от реальной возможности выполнения работ.
• - корректировка моделей бизнес-процессов на основании результатов опытной эксплуатации См.: Техническое задание проекта реорганизации бизнес-процессов предприятия. Режим доступа: http://www.finexpert.ru/content.asp?mID=60&ID=128&mode=w .

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

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

Этап 6. Внедрение регламентирующих документов.

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

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

Методологии обследования организаций. Стандарт IDEF0

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

• - теоретическая база;
• - описание шагов, необходимых для получения заданного результата;
• - рекомендации по использованию как отдельно, так и в составе группы методик См.: Репин, В.В. Процессный подход к управлению. Моделирование бизнес-процессов / В.В. Репин, В. Г. Елиферов. - М.: РИА «Стандарты и качество», 2006.- С.57..

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

Методология IDEF0 предоставляет аналитику прекрасные возможности для описания бизнеса организации на верхнем уровне с акцентом на управление процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа: по информации, по управлению, движение материальных ресурсов. Продуманные механизмы декомпозиции модели процесса в IDEF0 существенно упрощают работу аналитика. Следует отметить, что модели в нотации IDEF0 предназначены для описания бизнеса на верхнем уровне. Их основное преимущество, на наш взгляд, состоит в возможности описывать управление процессами организации См.: Черемных, С.В. Структурный анализ систем: IDEF-технологии / С.В. Черемных, И.О. Семенов, В.С. Ручкин. - М.: Финансы и статистика, 2001. - С.27-38..

Методология IDEF0 имеет ряд преимуществ, среди которых:

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

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

Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, то есть наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель См.: Орлов, С.А. Указ. Соч. С.80-81..

Построение модели IDEF0:

Ни одна модель не должна строиться без ясного осознания цели объекта моделирования. Выбранное определение цели должно отвечать на несколько вопросов: почему моделируются данный процесс? Что выявит данная модель? Как эту модель можно будет применить?;

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

Прояснение границ моделирования (широта охвата предметной области и глубина детализации). Ширина охвата обозначает внешние границы моделируемой системы. Глубина детализации определяет степень подробности, с которой нужно проводить декомпозицию функциональных блоков. Наименование контекстного блока обобщает определение границ моделирования. Существенные затраты на разработку контекстной диаграммы вполне оправданы, поскольку она является «точкой отсчета» для остальных диаграмм модели, и вносимые в нее изменения каскадом отражаются на все лежащие ниже уровни. Когда границы понятны, также становится ясным, какие объекты системы по тем или иным причинам не вошли в модель;

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

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