Как упростить проектирование сложных рабочих процессов

Эндрю Нидлмен

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

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

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

Начнем с обзора диаграмм, основанных на графах. В такой диаграмме каждая точка представляет конкретное состояние процесса, а каждая линия соответствует операции, которая может быть выполнена в конкретной точке. Точки и линии отмечаются метками, которые по мере создания рабочего процесса описываются в таблице условных обозначений. Точки отмечаются буквами, начиная с A, а линии — цифрами (отсчет от 1). Это исключает путаницу между точками и линиями.

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

Правила

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

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

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

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

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

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

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

Состояния могут быть отделены от основной части диаграммы. Так как просмотр диаграммы всегда идет в одном направлении, вы можете изолировать фрагменты диаграммы, не беспокоясь о том, как они связаны с предыдущими состояниями рабочего процесса. Например, элемент A связан с элементом B и мы хотим изолировать B в отдельную диаграмму, потому что у него слишком много дочерних элементов, которые не помещаются на текущей диаграмме. Нам не нужно волноваться насчет того, связана ли с элементом B операция, ведущая к C, и есть ли у C операция, возвращающая состояние обратно в A. Отметив состояние буквой A, мы можем связать их, не проводя линию к первоначальному состоянию A. Диаграмма просматривается только вперед, но не назад, поэтому соединять элемент с первоначальной точкой A не нужно. Это правило обеспечивает высокую гибкость при недостатке места для изображения диаграммы.

Операции и состояния рабочих процессов

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

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

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

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

Допустим, вы заходите в «книжный отдел» и щелкаете ссылку, указывающую на главную страницу сайта. Привело ли это к изменению вашего состояния в плане приобретения товара?

Нет. Если вы попробуете, скажем, найти на сайте «книги по .NET», то получите большой список таких книг и вернетесь на главную страницу; процесс покупки при этом тоже останется на прежнем этапе.

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

Роли в процессе приобретения товаров

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

Полный граф этого процесса изображен на рис. 1, а обозначения элементов расшифрованы в табл. 1.

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

Таблица 1. Обозначения элементов на диаграмме заказа товаров через систему электронной коммерции

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

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

Например, состояния E–G можно было бы сгруппировать для администратора в вариант «обработка не завершена». Вряд ли администратору понадобится знать что-то помимо статистики, которая предоставляется ему в отчетах.

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

Начиная проектировать рабочий процесс приобретения товаров, мы проигнорируем этапы, не изменяющие состояние транзакции приобретения товаров

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

И последняя рекомендация по поводу диаграмм: рисуйте их на очень большом листе бумаги, на другом листе пишите названия состояний, а на третьем — названия операций. Это позволяет легко получить общее представление обо всем процессе, не разделенном на фрагменты.

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

Об авторе

Эндрю Нидлмен (Andrew Needleman) — партнер с правами на управление компании Claricode (www.claricode.com), разрабатывающей специализированные решения в области здравоохранения. Автор целого ряда статей, опубликованных в отраслевых журналах, посвященных информационным технологиям и здравоохранению. Участвовал в создании основанного на рабочих процессах приложения, имеющего сотни состояний (каждое из которых охватывает несколько операций) и обслуживающего пользователей девяти категорий. Данное приложение было признано эталонным решением Intel (Intel Solution Blueprint) для здравоохранения, разработанным с применением технологий Microsoft.

Оригиналстатьи: The Archtecture Journal