6 ерить наличие товара.

7. Проверить кредит, которым располагает

8. Собрать заказ.

9. Упаковать товар.

10. Подготовить транспортную документацию.

Что можно сказать, бегло просмотрев этот список? Прежде всего, порядок операций записан произвольно. Но это не страшно - ведь вы просто пытаетесь понять, как выполняются те или иные задачи, а сами процессы проанализируете позже. Задачи также различаются по степени детализации, и позднее мы рассмотрим и этот вопрос. А сейчас давайте просто идентифицируем задачи.

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

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

Данные о покупателе используются в п. 3 ( Записать информацию о поставке ) и п. 5 ( Присвоить покупателю порядковый номер ). Следовательно, эти пункты относятся к одной задаче. Действительно, пп. ;. S могут быть объединены в одну задачу - Обработать заказ . Тогда п. 4 Внести сведения о - часть операции по записи информации. И не удивляйтесь, что некоторые операции происходят одновременно. В системах с ручной обработкой данных часто легче заполнить одновременно две формы; то, что эти формы относятся к логически разным не имеет значения.

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

ЧАСТЬ 2 Проектирование ряляцианнь(х систем баз даннь(х

которым располагает а это происходит уже после того,

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

Тем не менее, п. 6 ( Проверить наличие товара ) не относится по

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

складе в требуемом количестве.

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

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

складе, а затем учесть это взаимодействие при создании системы.

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

Если бы мы обнаружили, что заказ не может быть принят, пока на

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

Анализ оставшихся трех пунктов: 8, 9, и 10, - зависит от границ проекта. Если разрабатываемая система должна поддерживать поставку товара, нужно изучить их. Если же функции системы ограничены обработкой заказа и отправкой его в отдел эти пункты можно объединить в одну задачу - Отправить заказ в отдел доставки .

Конечно, может что впоследствии станет известно еще

что-либо, и этой информацией нельзя будет пренебречь. Ясно, что

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

отдельным рабочим процессом. Но эти уже находятся вне

рамок так что мы не будем их рассматривать.

Итак, вот переработанный список задач. Задача 1. Проверить, все ли пункты заявки заполнены,

Задача 2. Обработать заказ.

Этап I. Запросить данные о покупателе.

Этап 2. Записать информацию о поставке.

Этап 3, Внести сведения о заказе.

Этап 4, Присвоить покупателю порядковый номер.

Этап 5. Проверить кредит, которым располагает покупатель.

Задача 3. Проверить наличие товара. Задача 4. Отправить заказ в отдел доставки.

Этап 1. Собрать заказ.

Этап 2. Упаковать товар.

Этап 3. Подготовитьтранспортную документацию.

Создавая список задач и процессов, вы обязательно обнаружите,

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

спросить.

Анализ рабочих процессов

Теперь, когда у вас появилось ясное представление гаодяших в

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

Часто рабочие процессы можно существенно улучшить простой

перегруппировкой операций, устранив необходимость многократно

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

операций.

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