Simple, pragmatic workflow

An overview
Workflow and business processes
• There are many processes and tasks that have the need for some kind of
workflow
– E.g. Insurance claims, New customer processes, Call centres
• We contrast workflow with task management in that:
– workflow always involves more than one person, and
– there are often decisions or rules as to where the work item should next go
– Traditional workflow has previously worked well in industries with well-
defined processes and organisational structures
• Workflow is often represented by Business Process Modelling (BPM) or
Workflow applications
– Most of the major vendors and many specialist vendors have a workflow or BPM offering

Slide 2
Typical workflow design and implementation

• The workflow is usually

modelled in the tool by a
Business Analyst
– Involves identifying steps,
roles, and conditions for
moving between steps
• The IT department deploy the
modelled workflow on to a
server with the workflow
application
• The business users interact
with the workflow

Slide 3
Challenges with traditional workflow
• Traditional workflow is based on the
concept of a person’s role
– This is not a person’s job title but
instead a distillation of the actions
they perform in the process
• These days teams and departments
are often asked to do more with less
– In reality, people will play multiple
roles, sometimes in the same
process
– The use of offshore or nearshore
teams also blurs the role boundaries
• and resolution
Workflow applications that are
bound up with role-based security
do not adapt well to this reality
• Traditional workflow and BPM
applications are not suited to
adapting quickly to change
• They rely on a prescriptive and
deterministic flow
– The flow tells the user what to do
• This is fine at design-time, but seldom
matches reality
– Flows often have exception situations
(e.g. Where a customer’s
documentation might be incomplete)
that require case-by-case analysis
• Modelling these as one-size-fits all
makes it more difficult for staff to do
their jobs
Slide 4
A simple, pragmatic workflow tool

• We believe there is a need for a workflow tool that is

better suited for flexible business processes
• The tool would be of use in where any of the following
hold:
– Business users often need to use their expertise to decide what
happens next in the business process
– The business process is evolving or needs to adapt quickly to
changing circumstances
– Business users need to define simple chains of tasks without the
expense or overhead of an application suite
• We believe that the majority of business processes fit
these criteria and have developed a workflow tool to fit it

Slide 5
OWL: Open Workflow Light
• OWL was developed to meet the gap in a simple workflow tool. Its key principles are
below:
• The user knows best
– The user best knows how and where to route items in the process and they not the workflow
tool should not dictate where the task goes
• Keep a full audit trail
– It’s more important to understand what has happened to a task rather than where it will go.
– Not only might this be needed for regulatory compliance but it can also aid a user in deciding
what to do next
• Fit in with the users’ working methods
– The tool should integrate with the end users’ working methods not the other way around
• The following slides explain how OWL achieves each of these principles

Slide 6
OWL: Keep a full audit trail
• OWL ensures that the audit trail for a task is available to the user a
task is assigned to
• This shows:
– Who has worked on the task
– What they did to the task
– When they worked on the task
– How they categorised the task
– Why they assigned it to another user (through their comments)
• This information is just as important as the task itself in enabling the
user to decide what next to do with the task.
• We store all task information so it is easily and quickly accessible
without burdening the task with its own history
• The audit trail is immediately available to support regulatory
requirements

Slide 7
OWL: Fit in with the users’ working methods
• OWL integrates with common tools familiar to the user
– Email
– Chat / Instant Messenger (IM)
– SMS
– Microblog (e.g. Twitter)
• Users can select how and when they are notified of new tasks
• Users can “watch” flows of interest to ensure that important tasks
are being addressed
• Users can search for tasks, comments, or tags using familiar web-
based search interfaces

Slide 8
OWL: Technical overview

• OWL can be installed alongside your company’s

applications or accessed as a service over the web
• OWL is hosted on scalable architecture provided by
Google
• OWL is written using the mature, stable, and powerful
Java language but can integrate with non-Java systems
• OWL is a “white label product” that can be customised to
your company’s brand making it a seamless experience
for the end user
• More technical details on OWL can be found at
http://truenorth.gb.com/products/owl-technical

Slide 9