Workflow Diagrams, Part 2

Many global organizations are working on standardizing the best practices for workflows. One of the most notable practices is the business process modeling notation (BPMN). The BPMN provides a set of symbols and guidelines for charting the flow of a business process. In this second installment of our workflow discussion, we’ll talk about the different elements that comprise a BPMN compliant workflow.

 

Annotations – These are small text paragraphs that are often added by the workflow designer to explain what is being done at that stage of the workflow. Annotations can provide additional information, but they can also take up a lot of additional room on the canvas. Because annotations are not necessarily required in a workflow, there are a few modes of use:  always visible, visible if the mouse is over a particular element or icon (also known as “tool tips”), or toggled on and off as the user requires through a button or similar mode of use.

Annotations

Events –Events, denoted by circles, signal “something happening,” such as an email notification, a scheduled meeting, or the end of a particular process. Icons may be present inside the circle, such as an email icon or a clock picture. Though a user will immediately know the type of an event by the icon or color of the circle, the user will not know exactly what transpired during that event. Annotations may be added for clarity, which will result in a workflow with more elements.

Workflow Events

Activities –Activities, such as meeting requests and task assignments, are sometimes represented as rounded rectangles with small icons. However, these icons only tell the user that “something” is happening at that point; the user will not necessarily know exactly what happened at a meeting, who is involved, what was said in an email, etc. Having more information about the activities can be useful, but it creates additional design elements in the workflow.

workflow activities

Question:  If you are assigning the same task to multiple individuals, should workflow designers use one task element to represent this activity? Or should the designers use multiple elements?

Gateways – These are elements that take transitions from the output(s) of elements and then transition them to the input(s) of others. There are two main types of gateways: combiners (fork/join) and multipliers (inclusive decision/merge). A combiner takes multiple inputs and creates a single output, while a multiplier takes a single input and creates multiple output transitions. These elements are not required in a process. However if the goal is to show as much detail as possible about the events of a workflow, they can be very useful.

Worlfow Gateways

Question:  Should a gateway that has internal logic denote that to the observers of the workflow?

Swimlanes – Represented as horizontal or vertical lanes (often different colors), swimlanes help teams and designers to keep track of what work is done by which department or what category the work falls under. These can add complexity to the layout and design of the workflow.  

workflow swimlanes

There are many more elements within the BPMN standard that can be added to a workflow. Again, however, we must ask the question: which elements are the most important? By utilizing a large variety of geometrical icons, will the workflow become too cluttered, hindering the understanding of the user?


Posted by: Jeff Bishop
Posted on: 3/22/2010 at 11:09 AM
Categories: Issue Management | Issue Tracking | IssueNet | Workflow
Actions: E-mail | Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
Share

Workflow Diagrams, Part 1

The team here at Elsinore has spent quite a bit of time this past week reviewing how workflows should look and feel to users.  We thought it would be great to hear our customers’ and visitors’ opinions on workflow design usages.

For the purpose of this blog we will focus specifically on business processes, though the principles could apply to any type of organization. A typical workflow diagram will have geometrical elements (such as rectangles, diamonds, and triangles), each representing or describing some action, activity, or decision that has to be made during the process. Most of these elements will typically have a one or two word label to help observers keep track of the flow. These elements are however only a few of the possible graphical and text representations available.

The amount of detail provided by a workflow diagram is determined by the workflow designer. Workflows can be designed at a high level, only outlining the general scope of the process and keeping the layout simple. On the other hand, workflows can be very detailed, showing exactly what activities are being performed, to whom the emails are sent, what divisions are doing the work, who is responsible for scheduling a meeting, etc. The information is all available but the key is balance. When we consider these and other elements that could be represented, are they useful or do they add clutter to the workflow canvas? What elements do you think are important?  And should workflow designers err on the side of simplicity, or should they strive to display as much information as possible?

It’s a difficult philosophy to capture in a single blog, so in the next installment we’ll capture a few of the most common design elements of a workflow and discuss some of their pros and cons as graphical representations on a workflow.

Workflow Diagram

Posted by: Jeff Bishop
Posted on: 3/18/2010 at 7:35 AM
Categories: Issue Management | Issue Tracking | IssueNet | Productivity | Workflow
Actions: E-mail | Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
Share

Workflow Best Practices

So in a lot of blog articles the author is creating a story to validate his/her own opinion well this is not one of those blogs.  The team here at Elsinore has spent a good bit of time this past week reviewing workflow best practices and how workflows should look and feel to users.  We thought it would be great to hear from our customers and anyone else visiting our blog on what they thought about workflow design practices.

Sparking from the discussion about swimlanes a new question has arisen.  When do all these possible design elements start making our graphical representation more confusing than helpful?  There are a lot of organizations globally working on standardizing best practices for workflows one of the most notable is business process modeling notation (BPMN).  Workflows can be designed at a high level only outlining the general scope of the process keeping the layout simple.  Or they can be very detailed to the point of showing exactly what activities are being performed; who the emails are going to, what divisions are doing the work, who is responsible for scheduling the meeting, etc.  The information is all available but the key is balance, what elements do you think are important?  And should workflow designers’ error on the side of simplicity or informative?


Posted by: Jeff Bishop
Posted on: 6/22/2009 at 1:00 PM
Categories: IssueNet | Workflow | workout
Actions: E-mail | Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
Share

To swimlane or not to swimlane that is the question

It's been a topic of conversation we have had more than once around the office the last few days as to the merits of swimlanes at different stages of the workflow design process. A popular design element for business process management, workflow, and flow chart graphical design swimlanes are a graphical representation of responsibilities or categories of work typically displayed horizontally across the workspace. For example in a process workflow for a software enhancement request you might have swim lanes for support, product team, development, and quality/testing. Then as an activity, event, or gateway is created in the process flow it can be located in the proper lane to help organize the process. In theory this sounds like an ideal situation it would cleanly segregate elements in the workflow for clear assignment responsibilities, business teams can assess their requirements at a glance, and it should keep elements organized for the process designer.

However in practice swimlanes can also generate their fair share of problems.  First using swimlanes means that elements that typically could be displayed close together on the chart could possibly be moved an un-intuitively long way apart to adhere to this practice. Second elements on the flowchart that involve members or decisions from multiple departments can become pretty tricky requiring the bounding region to span each of those participating department swimlanes.  And if you have conflicting element designs each requiring different swimlanes to be adjacent then you have to start rethinking your layout and process flow.

Swimlanes are an ideal conceptual design tool allowing process flow developers to categorize and organize thoughts however graphical design elements should always be helpful and never hinder productivity. Whether you use swimlanes or not the concept of organizing your design elements by categories is an excellent starting point for any process design.  Those categories could be the stages of the process, the business divisions involved, or by design elements required to complete the process.


Posted by: Jeff Bishop
Posted on: 6/15/2009 at 4:07 PM
Categories: IssueNet | Workflow | workout
Actions: E-mail | Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
Share