views:

205

answers:

7

We've got a surprisingly complex workflow that needs to be monitored by a quasi-technical employees with an in-house webapp. There's about 30 steps, some of which are manual (editing), some are semi-automated stop points (like "the files have been received" or customer approval of certain templates), and some are completely automated (file conversion, search indexing, etc). The flowchart for all of these steps is large and complicated, and three people might be working on three completely different steps at any one time.

How would you present this vast amount of information as usefully as possible to your users? Just showing the whole diagram seems like the brute force solution. But it's big, and it'll likely get bigger as we do more things. Not to mention the complexity necessary to encode this entire diagram in HTML.

alt text

+1  A: 

This sounds like the sort of application for which BPEL is suited.

Of course you don't want to re-architect your system right now. But there are a number of BPEL implmentations out there, some of which include graphical editing tools. One of these might help you in your current situation, because they are good at handling scope and hiding detail. So I think you might derive benefit from drawing your workflow as a BPEL diagram even if you don't do anything else with the language.

The Wikipedia page lists several of the available implementations. In addition, Oracle's JDeveloper IDE includes a BPEL Diagrammer as part of its SOA suite; unfortunately it is no longer part of the standard install but it is still available. Find out more.

APC
All the information out there about BPEL seems to start at an intermediate level. Is there no "so, you're a BPEL newbie" tutorial?
Plutor
+3  A: 

I assume you don't want to show these just for entertainment or mockery, but help the users along the way, automating as much as possible, document the process etc. It would probably help if you clearly define the goals or purpose of your app.

I don't see a point in showing the entire workflow, except for "debugging the business rules" or maybe the clients want to see it.

If your goal is to help users do their job, I would present the state of the "project" (or whatever term fits better) is at, and possible transitions to other states.

The State might be multiple mostly independent variables, e.g. one might describe the progress of content - e.g. "incomplete" / "complete" / "reviewed by 2nd staffer" / "signed off by 2nd staffer", others might contain a schedule that is developed in parallel, e.g. "test print date = not scheduled", "print date = not scheduled", "final delivery = tomorrow, preferredly yesterday".

A transition might be "Seint to customer for review", "mark as content-complete", "content modified", etc.

Is this what you have in mind?

peterchen
+1, sounds a good idea from my reading of Plutor's question. I'd add, show some kind of "How far are you through the entire process" indicator, assuming the process has an end goal / state. It can be frustrating as a user to perform step after step and not know what, if any, progress you're making.
David M
+1 for the "progress" ;) I was thinking of that myself, but wanted to to confirm this *is* what Plutor looks for. Certain nodes might be tagged as "milestone" or have "completion points" assigned to some states.
peterchen
In addition to this, if they do want to see the entire workflow, you can then simply have a flow chart as a PDF or an image that they can download to look at if they wish. Easier that trying to do it in HTML...
Paddy
A: 

I'd recommend having the whole flow documented somewhere, but in terms of what is distributed to users, how about focusing on task-oriented flows? No one user will be responsible for the entire process I would imagine.
For example, let's say I have 2 roles, A and B, and 6 tasks, 1 through 6, executed in order. Each task may have multiple steps but is self-contained (e.g. download the file, review, run process, review again, upload). A does the even tasks and B does the odd tasks.
A would need to know about those detailed steps that comprise tasks 2, 4, and 6 but not about what goes on in 1, 3, and 5. So hand A a detailed set of flows for the tasks he is responsible for, along with a diagram that treats each task as a black box. If the flow can't be made modular in this way, you may want to review the process itself to see why it's so complex.

brokenbeatnik
+1  A: 

Try doing it in layers. You have the most detailed layer done, now add additional docs with the details hidden, grouped into higher-level business processes. Users should be able to safely ignore some of those details, but it's good for them to have visibility of how their part fits in to the whole.

You may need more than one higher-level document.

Beth
+2  A: 

I propose to divide your workflow in modules and represent the active state for each module.

A module is a subset of your main workflow. For example it could be divided by tasks, person, roles, department, etc. This will greatly simplify the representation of the workflow. Let's says someone is responsible for data entry at many critical moments. We can group all his tasks in one module (or sub-workflow) containing the same activities, inputs, outputs and conditions. Modules could be inter-dependants and related.

A state is where we are located in a module. In simple workflows there is only one active task. In real life we are multi-threaded! So maybe in one module many states could be active at the same time. The state also includes active inputs, outputs and memory bits.

An input is something required to perform an activity for evaluation a boolean condition. It could be a document, a piece of data, a signal...

An output is something resulting from a task: an information, a document, a signal...

Enough definitions?

Then simply convert your workflow into a LADDER LOGIC and you have your states!
See Ladder Logic definition on Wikipedia

You display only active states:

  • Active task(s) for the module
  • Inputs required / inputs confirmed
  • Output required / output realized
  • Conditions to continue

Seems abstract?

Here is a small example...

Janet enters data in the system. She manages the green tasks of the diagram. We focus only on her work, not other tasks. She knows how to do 16 tasks in the workflow. We are waiting the following actions from her to continue, and her Intranet dashboard says:

Priority 1: You must send a PO to order enough pencils for the next month based on the sales report.

  • Task: Send a purchase order
  • Inputs: Forecast report from the marketing department
  • Outputs: PO, vendor, item, quantity
  • Condition for completion: PO sent and order confirmation received from supplier

Priority 2: You must enter into the financial system the number of erasers rejected by production

  • Task: Data entry
  • Inputs: Reject count from production
  • Outputs: Number of rejects
  • Condition for completion: data entered and confirmed

We do a lot of troubleshooting on automated production systems having hundreds of thousands ladder steps (the workflow is too complex to be represented in a whole). When the system is blocked we look at each module and determine what inputs are missing to activation task completion.

Good luck!

rjobidon
+2  A: 

You can use Prezi to present this information to users in a lucid manner.

  • Split and present the work flow into phases such that the end user is easily able to identify the phase he is currently in.
  • Display as many number of phases as the number of inputs. The workflow starts with 6 different inputs so display the six different buttons on screen enabling the user to select the input that he wants.
  • On selecting the button zoom into the workflow depicting the next steps. This would also help the user to verify the actions that he has done so far to reach the current states.

This would also help the user to verify the actions that he has done so far to reach the current states. But this way of presenting could become cumbersome for the users as the number of steps that he has completed goes up. Say the user has almost reached the end of the workflow. To check for the next step he should go through all the steps which might frustrate the user.

To avoid this you can split the complete work flow chronologically into 3-5 phases. The phases should be split logically. The ultimate aim would be not to overwhelm the users with the full work flow. Personally i would try to avoid the task involving this workflow if presented the way you have shown. No offense. I bet you also feel the same.

Could give you a better picture if you could re-post the image after replacing the state names with numbers.

Keerthi Ramalingam
A: 

How about showing an example of a workflow scenario, that is, showing the transitions in one possible passing through the workflow? You could cater this to a specific user profile and highlight the pertinent states, dimming the others. This allows them to get a clear idea of the transitions by seeing a real-life example.

Diego