Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Tekh_komp_pr_-_kons_lek_1.doc
Скачиваний:
279
Добавлен:
10.02.2016
Размер:
9.36 Mб
Скачать

11.5. Декомпозиция бизнес-процессов

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

Детальность и доступность одновременно достигаются декомпозицией бизнес-процесса. Так, действие "Оформление заказа" с рис.11.1 раскрывается в отдельную диаграмму, представленную на рис.11.2.

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

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

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

Рис. 11.2.  Описание действия "Оформление заказа"

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]