Разработка сложной схемы рабочего процесса

Question

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

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

Answer 1

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

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

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

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

Переход может быть «Seint to customer for review», «пометить как контент-полный», «контент изменен» и т. Д.

Это то, что вы имеете в виду?

Answer 2

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

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

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

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

Вывод - это результат задачи: информация, документ, сигнал ...

Достаточно определений?

Затем просто преобразуйте ваш рабочий процесс в LADDER LOGIC и вы получите свои состояния!
См. Определение Ladder Logic в Википедии

Отображаются только активные состояния:

• Активные задачи для модуля
• Необходимые входы / подтвержденные входные данные
• Требуется вывод / реализован вывод
• Условия для продолжения

Кажется абстрактным?

Вот небольшой пример ...

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

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

• Задача: отправить заказ на покупку
• Входные данные: прогнозный отчет отдела маркетинга
• Выходы: ПО, поставщик, изделие, количество
• Условие для завершения: заказ отправлен и подтверждение заказа получено от поставщика

Приоритет 2 : Вы должны ввести в финансовую систему количество резинок, отклоненных при производстве

• Задача: Ввод данных
• Входные данные: количество брака от производства
• Выходы: количество бракованных
• Условие для завершения: данные введены и подтверждены

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

Удачи!

Answer 3

Вы можете использовать Prezi для ясного представления этой информации пользователям.

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

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

Чтобы избежать этого, вы можете разбить весь рабочий процесс в хронологическом порядке на 3-5 этапов.Фазы должны быть логически разделены.Конечная цель заключается в том, чтобы не перегружать пользователей полным рабочим процессом.Лично я бы постарался избежать задачи, связанной с этим рабочим процессом, если бы он был представлен так, как вы показали.Без обид.Бьюсь об заклад, вы также чувствуете то же самое.

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

Answer 4

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

Вам может потребоваться более одного документа более высокого уровня.

Answer 5

Звучит как приложение, для которого подходит BPEL .

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

На странице Википедии перечислены несколько доступных реализаций .Кроме того, Oracle JDeveloper IDE включает в себя BPEL Diagrammer как часть своего набора SOA;к сожалению, он больше не является частью стандартной установки, но все еще доступен. Узнайте больше .

Answer 6

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

Answer 7

Я бы порекомендовал где-то документировать весь поток, но с точки зрения того, что распределяется среди пользователей, как насчет того, чтобы сосредоточиться на потоках, ориентированных на задачи? Ни один пользователь не будет нести ответственность за весь процесс, который я себе представляю.
Например, скажем, у меня есть 2 роли, A и B, и 6 задач, с 1 по 6, выполняемых по порядку. Каждая задача может иметь несколько этапов, но она автономна (например, загрузить файл, просмотреть, запустить процесс, просмотреть снова, загрузить). A выполняет четные задачи, а B выполняет нечетные.
А должен был бы знать о тех подробных шагах, которые включают в себя задачи 2, 4 и 6, но не о том, что происходит в 1, 3 и 5. Итак, рука А - подробный набор потоков для задач, за которые он отвечает, наряду с диаграмма, которая рассматривает каждую задачу как черный ящик. Если поток не может быть сделан модульным таким образом, вы можете просмотреть сам процесс, чтобы понять, почему он такой сложный.