Chapter 11 Designing Workflow

1
Chapter 11Designing Workflow
2
What is Workflow?

• Workflow is the way tasks flow through a cycle on
  their way to getting a job done
• Workflow is a process that may or may not be
  automated
• When designing workflow, you represent it
  diagrammatically, showing the various tasks
  involved in a project (job)
• The workflow representation not only illustrates
  all the tasks and players, it also shows where
  your process needs to be simplified before they
  are automated
• Design your workflow before selecting a workflow
  system

3
Components of Workflow

• Roles (players)
• The people who do the tasks, identified by their
  role
• Responsibilities (tasks)
• The steps to complete a particular piece of work
  everything that must get done within a process
• The tasks for which the players are responsible
• Processes
• The flow of tasks, as performed by the various
  players, showing the interactions and
  interdependencies among players
• The workflows that connect all the people and
  tasks together and define the path that each task
  must take

4
Benefits of Workflow

• Good workflow design ensures
• Departments that should be creating content or
  that should at least know about it are not left
  out
• Content and all supporting elements (such as
  graphics) are created in the proper order
• Content is reviewed at the right time, by the
  right people, eliminating reviews and approvals
  that have to be redone if additional changes are
  made
• Departments are notified when content is
  published
• Efforts are not duplicated and content is
  consistent
• Work is not held up at any given stage of the
  workflow
• Content is stored in the right place after it is
  written, reviewed, approved, and delivered

5
Improve and Simplify Processes

• Through workflow representation, you can see
  processes as they exist now, then depict them as
  youd like them to be
• Simplification should always be one of your goals
  when depicting the workflow
• It is not only critical to depict everything that
  happens, but also what should happen
• To improve or simplify a process, you analyze and
  change the tasks, then test the process to make
  sure the work will flow properly
• Tasks may be eliminated or combined, the sequence
  and location where the task is performed may be
  changed, as can the person who performs the tasks

6
Depicting Workflow

• The first step in designing workflow is to figure
  out how tasks such as authoring, editing,
  reviewing, approval, publishing, and distribution
  should flow through the organization and what
  should happen if, at any given stage, a task
  cannot be completed as dictated by the workflow
• Depicting workflow by linear flowchart or a
  swimlane diagram

7
Flowcharts

• Linear flowchart depict a process from beginning
  to end, often using flowcharting symbols to
  indicate the types of tasks in the process
• Flowcharting symbols illustrate such things as
  which task is a process, which task is a
  decision, which task is a predefined process,
  which task is a manual operation
• Instead of flowcharting symbols, you can use
  boxes with clear task description written in them
• Useful if you want to show all the tasks within a
  process, with a view to simplify them

8
Swimlane Diagrams

• Swimlane diagram show process in lanes to
• Depict tasks that occur concurrently
• Illustrate who does what, and when
• Also known as process maps, business process
  maps,LOV (line of visibility) charts, and process
  responsibility maps
• Show the interdependencies of tasks
• To design workflow as it will be supported by a
  workflow system, you may want to use a swimlane
  diagram
• Show all roles and all tasks, as they relate to
  each other, which is critical in UCS
• You can still use flowcharts to illustrate where
  you can simplify tasks

9
Opportunistic Reuse Workflow
10
Systematic Reuse Workflow
11
Roles, Responsibilities, and Processes
12
Roles (Players)

• A player is any person or group that handles the
  work between the initial event and the
  achievement of the process's results
• Can be internal staff, external customers, and
  information systems
• The workflow must accommodate all roles
• Common players
• Authors
• Reviewers
• Editors
• Approvers

13
Workflow and Players

• The workflow does not tell the players how to do
  their part
• The workflow tells the players that they have a
  part, what that part is, and when it must be done
• The workflow must allow for alternatives if
  players are not available when they are required

14
Depicting Roles

• In a swimlane diagram, the players are the
  swimmers actually doing the work (tasks) shown in
  the swimlanes
• Your workflow must depict how all the different
  swimmers collaborate on the different aspects of
  your project in a tightly integrated manner,
  without swimming into other swimmers' lanes
• Each player is shown on the left side of the
  diagram, beside the lane which they belong in
• Players are shown by their roles, not by their
  individual names, along with the name of the
  department

15
Responsibilities (Tasks)

• A task is a particular series of actions that
  accomplish a particular goal
• If it must get done, then it is a task and you
  need to show it
• To determine all the tasks within a workflow, you
  need to talk to the various players about their
  responsibilities, keeping the discussion focused
  on the particular process, not all the activities
  of the players in their departments

16
Types of Tasks

• Tasks that add value (work tasks)
• When value is added to a task, the work is
  changed in some way
• Written, approved, revised, returned for
  correction, metadata added
• Tasks that move the work along (transport tasks)
• Moves the work item from task to task in the
  workflow (does not change the work item)
• Transport tasks are critical to include because
  they illustrate important parts of the process,
  such as how a work item gets to the next person
• In a transport task, include information on how
  the work item is transported
• Ex. Route first draft by e-mail to supervisor in
  head office, courier original artwork to ad
  agency, post to intranet

17
Types of Tasks (Cont.)

• Tasks that introduce a delay (wait tasks)
• When a task introduces a delay, the subsequent
  task cannot proceed until the previous one is
  finished
• Wait for content from marketing before completing
  draft (YES)
• While waiting for graphics, an author may still
  be able to proceed (NO)
• A task that introduces a delay may not actually
  do anything to the work item ? instead, pause the
  process temporarily
• While waiting, the author can do other work, but
  not work that moves this process along
• It is important to include these types of delays
  because they give you a more accurate depiction
  of how long a process will take

18
Writing and Depicting Tasks

• Tasks are shown in the swimlane of the player who
  does the task, with description text depicting
  each task
• Write task consistently in a verb-noun format
• Form CP-13 ? Submit graphics request on Form
  CP-13
• Include "how" information (optionally)
• Sort graphics requests ? Sort graphics requests
  by due date
• Use qualifiers to modify the noun
• Sort graphics requests from marketing by their
  due date
• Dont write the task by focusing on the result
• Graphics requests are sorted (NO)

19
Writing and Depicting Tasks (Cont.)

• The system can have tasks as well
• Tasks that are programmed by a system developer
  or integrator and to be included in workflow
• Ex. Publish content to PDF, post content to the
  web site

20
Processes (Flow)

• A process has a start point and an end point
  between which various tasks are performed
• A process comprises the tasks and
  responsibilities, as performed by various players
• Workflow must illustrate the entire process from
  beginning to end
• You need to decide where your process begins,
  where it ends, then start charting everything
  that happens in between

21
Processes (Flow) (Cont.)

• Process may start outside the system, but
  automated workflow starts when the system can
  manage a task
• Include such tasks as "determining project
  requirements" and "holding meetings" (even though
  they are not managed by the system)
• The automated workflow starts when work begins on
  the action items
• At which point the process must be managed
  automatically, workflow begins
• If you include requirement tasks, or tasks that
  are not managed through the system, you should
  indicate where the automated workflow begins
• The automated tasks form your requirements for
  selecting and configuring a workflow system

22
Processes (Flow) (Cont.)

• It may be difficult to determine the end of
  workflow
• EX. A web product page is posted to the Web, but
  it is modified over time to remain current
• Probably make sense to end the workflow when the
  page has been posted. Then create an additional
  workflow that handles the content when it needs
  to be updated, modified, or corrected

23
Processes (Flow) (Cont.)

• Typical workflow for UCS
• New products or services
• Updates to existing products or services
• Discontinued products or services
• Workflow for special situations
• EX. Emergency notification of changes to the
  products
• Overall workflow supporting workflow
• Workflow for writing user documentation, for
  developing collateral and graphics, and for
  creating training materials
• All the processes are part of an overall project
  and are dependent on each other

24
Business Requirements Often Govern Workflow

• Budgets that dictate how much can be spent on any
  given task
• Hours of work in which tasks can be completed
• Union job descriptions that govern who can
  perform a certain task and under which conditions
• Physical location of the company that dictates
  where a task is performed (handoffs and transport
  tasks, translation and localization)
• Suppliers that your company does business with
  and their particular constraints

25
Depicting Processes

• Processes are shown in swimlane diagrams with
  specific start and end points, and with all lanes
  completed with all relevant tasks, including such
  things as handoffs and delays
• Where a task is performed by two players at the
  same time, write the task in each lane, but draw
  a box around them both to show they are performed
  together
• Use arrows to connect the flow of tasks and to
  show when they transfer to another role/lane

26
Review and Approval Workflow
27
Designing Effective Workflow

• Need to analysis of players and their tasks, as
  well as identification of patterns and
  interactions, then a documenting of detailed
  tasks, followed by testing

28
Designing Effective Workflow (Cont.)

• Determine a starting point for your workflow
• Usually a process starts with an incoming event
• New product being made ready for market, or a
  request to update existing documentation
• Can also be a crisis that you need to response
• If you include tasks that are not part of the
  automated workflow, indicate where automated
  workflow begins
• Figure out a logical place for the workflow to
  end
• Typically when the incoming event has been
  handled satisfactorily
• In UCS, content must be stored in the repository
  for the event to be considered complete

29
Designing Effective Workflow (Cont.)

• Identify all players from the beginning to the
  end of the workflow
• Identify players by their roles
• A task should be associated with a role to
  accommodate people moving in and out of jobs

30
Designing Effective Workflow (Cont.)

• Sketch the tasks
• Start by identifying all the tasks that belong to
  each player, including when those tasks are
  waiting for something else to happen, or when
  they are handing off work to someone else
• You may omit notification in your first
  iteration, but notification must be included
  before your workflow can be considered complete
• Look for potential bottlenecks that may slow your
  workflow down, such as one player having too many
  tasks at a certain stage, while other players
  wait for those tasks to be done so they can
  contribute theirs
• Can tasks be delegated to other roles? Can tasks
  be completed concurrently?

31
Designing Effective Workflow (Cont.)

• Identify interaction patterns among players and
  tasks
• When are players working alone and when are they
  working with others?
• Who relies on whom or on what information?
• When there are numerous interactions, there may
  also be bottlenecks
• Look for potential bottlenecks that may slow your
  workflow down
• Can you build a alternative?
• Allocate timeframes for tasks
• When is each task complete and how much time
  should you allow from the time a task is assigned
  until it is complete?
• How much leeway should you build into the
  timeframe?

32
Designing Effective Workflow (Cont.)

• Identify notification patterns
• Who needs to know what at any given stage of the
  workflow
• Identify approval patterns
• Who is responsible for reviewing work items
  throughout the workflow?
• Determine all the "what ifs" that may knock your
  workflow off its path
• What happens if an approver is away?
• Can work be routed to someone else for approval?
• What happens to other tasks if a deadline is
  missed?
• What if a tool breaks or if content is lost
  somewhere along the way?

33
Designing Effective Workflow (Cont.)

• After all roles are identified, tasks are
  sketched, and notification and approval patterns
  are identified, examine your workflow to see
  whether it can be simplified
• Repeat these steps for all the workflow processes
  you need to support your UCS, for example,
  workflow for new projects, workflow for different
  types of new products, or workflow for updates to
  existing content