36
A New Perspective on Business Process Design & Automation ... Ian Ramsay
A New Perspective on Business Process Design & Automation ...
Ian Ramsay
Copyright © 2012-2013 Ian Ramsay and ValueFlow Associates Limited.
This short booklet outlines the challenges we have seen during a decade of business process automation assignments & the resultant methods & tools we developed to remove risk, cost & time from any process change or automation initiative … regardless of the business process complexity or your specific BPM technology platform.
8020™ formalises these pragmatic techniques into a concise, business oriented & vendor independent extension to traditional methods & is designed to work in harmony with company governance & vendor software configuration methods.
8020 is the first formal approach based upon the exciting new field of Artefact-Centric BPM, previously the domain of academic research but now accessible to all.
In prior delivery assignments, 8020 has enabled the business & technical teams to converse using a precise, common language. A set of easily understood process constructs that faithfully represent the real world business operations, using simple terminology yet in a form ready for immediate automation.
8020™ most notably reduces; analysis effort, translation errors, rework, operational risk & development costs.
We use this approach in our delivery assignments, in concert with client specific change methods & have seen benefits for our customers in all the following areas;
• Executive Engagement & Education.
• Programme Cost Benefit Analysis.
• Process Change Programme Inception, Scoping, Resourcing & Delivery Approach.
• Evaluation, Selection & On-Boarding of BPMS Platforms & Content Management Systems.
• Rapid Process Analysis & High Level Design.
• Test Design, Development & Execution.
• Business User Engagement & Operational Training Development.
This paper focusses on the 8020 Process Design and Automation Method. Other aspects of the 8020 Approach such as Process Mining and Process Landscaping are covered in separate white papers.
[email protected] +44 789 999 8017
CUSTOMERS SEEK & EXPECT VALUE.
VALUE is a perceived POSITIVE CHANGE in SOMETHING.
PROCESSES CHANGE THINGS, in a POSITIVE way.
THINGS are CHANGED by WORK.
WORK is organised into TASKS & performed by WORKERS.
WORKERS can be PEOPLE or MACHINES.
In a service economy the “thing” that actually realises customer value is simply data. Mainly the customer’s own case data & the myriad of value altering states it assumes.
Value is created by transforming this data, efficiently & predictability, which we do by way of work, often guided by business rules & procedures.
Without a clear understanding of such case data & valid states it is impossible to clearly define the optimal work procedures, some of which can appear very complex. Consequently customer value is often lost or destroyed.
1
Financial Service industries rely almost exclusively upon information to deliver customer value at the right time at the right price point. Today this reality demands extensive & sophisticated process automation, delivered economically & predictably.
To deliver such benefits repeatably, process change & automation programmes need to move beyond the ad-hoc work-centric methods & better define the “things” that add value.
It’s not the work that customers value, it’s the outcome … namely the process data, information & service experience.
2
Whole departments are currently dedicated to “mapping processes”, developing flowcharts of work, analysing “wasted operational effort” & rearranging work to reduce time, cost & defects.
LEAN, 6-Sigma & Systems Thinking certainly offer a framework for process improvement, but by nature tend to address the more tangible, visible & physical aspects of a process. Such techniques are necessary, but not sufficient, for effective process automation projects in financial services.
Additional perspectives on process change are required ...
3
Is the MODEL an accurate
picture of the BUSINESS
ORis the BUSINESS compliant
with the MODEL ?
4
The Current SituationProcesses can be complex things. They appear hard to define or automate. Perceived complexity of process definition & automation often means we fail to automate effectively leaving many people involved in conducting mundane operational work.
People are naturally good at assessing the real context of a case, understanding the overarching business objective then applying various intelligent plans of work to move it towards completion. People can even resolve unforeseen exception cases outside their formal training. Something a computer cannot take the “initiative” to do. Unfortunately, people are also quite expensive to train & sustain plus they are prone to error.
So while computers have taken a predominant role in managing core customer data, they have struggled to economically automate those critical business processes that drive a service business.
Yet it is these core business processes that represent the bulk of operational cost & corporate value creation.
Much of our focus in understanding business processes in financial services has centred around improving the efficiency of staff. To do this we have borrowed techniques & methods from the (mature & efficient) manufacturing industry, such as; flowcharting, run charts, eliminating waste & 6-Sigma conformance models.
Despite massive investments in process improvement & associated technology, the service sector has not enjoyed the productivity gains seen in manufacturing.
Our analysts tend to focus on understanding the physical or more tangible parts of a process, (like obvious flows of work, materials & staff organisation) while trivialising the more abstract aspects (such as
5
customer process data, valid data states, business events & goals).
This simplistic approach is generally OK for manufacturing as the focus of work is tangible, it’s mainly materials. There are limited dimensions to describe.
However, in financial services we see immense energy & intellect deployed only to document & implement changes to a small, visible portion of a real world process, leaving the rest for interpretation by programmers or operations staff, or both! Any benefits from process change are quickly offset by errors & compensating work during operations.
With this imprecise approach, problems with process change programmes are inevitable & now well documented.
6
Common ProblemsAs described before, flowcharts only capture a portion of a process, but they have proven useful & comprehensible in process change. They enable us to share a common process understanding. But only about a subset of the process. The bit about how work flows, or is sequenced.
When processing was predominantly manual & to some extent with basic computerised workflow based operations, people are trained (or take the initiative) to react & conduct the missing aspects of a process. A flowchart & a few specifications are more than adequate.
We often find operational staff & front line managers are unconsciously competent in process knowledge. They perform the job yet struggle to articulate why they apply certain decisions or conduct various actions.
You might say this is excellent news & it is, while we can afford it. However, if we wish to introduce more extensive process automation we need to extract or validate this embedded process knowledge in a much more precise manner. Remember that operations staff are not business analysts, nor should they be.
Be aware ... There exists a large communications gap between unconscious competence & explicitly precise automation!
Common Symptoms …
• The business give us incomplete requirements.
• IT seem to overcomplicate every project.
• There are so many exceptions we are not sure there’s such a thing as a real process flow.
• IT don’t seem to understand what we have to do to get this job done.
• Every time we agree the process rules, the business seem to invent more surprise variations.
• We bought the wrong BPM software.
• We seem to have more staff than when we started this process change.
7
The recurring problem we find in most change programmes is the limited awareness of all process dimensions, by all parties, leading to misunderstandings & costly rework.
So flowcharts are OK for understanding largely manual processes & basic workflow, but fail to capture the real detail of a full service process necessary for automation (BPM), integration (EAI) or straight through processing (STP).
Flowcharts describe the Sequence of Work, the Flow Rules, & Participants who performs the work, but say little about:
• Process Data & Relationships.
• Case Data States & Valid State Changes.
• Business Events, Processing Goals & Supporting Work Plans.
• Business Rules, Validation Rules & Constraints.
• Physical Data Structure, Location & Integration.
This may all sound a bit technical for now, but stay with us, we have refined 8020 & its components upon the observed behaviour of
real world processing & we use simple terminology that accurately reflects exactly what happens in any process.
The problem becomes one of common communication as to exactly what constitutes a given business process.
Most BPM software vendors also provide a method, standard terminology & an approach to configuring their systems. This is good but they tend to be focussed mainly upon how to use the software cleverly & avoid technical design problems.
Vendors often assume the customer has the ability & awareness to clearly articulate their process behaviour & future requirements in terms suitable for their tool set.
No sooner has the project started than negotiations erupt about variations to scope & extra costs.
Gartner’s View …
“Most businesses have a limited, explicit under-standing of end-to-end business processes, & if any understanding exists, it is often tucked away within disparate groups across the organisation. It's rare to find an organisation that has linked its scattered process competencies into a comprehensive strategy.”
Michael Melenovsky & Jim Sinur, Gartner Research
8
Business ImplicationsOutcomes from poor process understanding & change run the full gamut, from at best, career limiting embarrassment to complete corporate collapse.
A failed £30+ million mortgage processing project in 2009 contributed to the collapse of a major Building Society, forcing a UK Government rescue package of £1.6 billion, of taxpayers money & then a forced sale to a major rival.
Business processes go to the very heart of why a business exists. That’s why the potential benefits of process change are so profound & the all too common failures, catastrophic.
The most typical outcomes we see from a failed process change programme seem to be:
Overspend, as without proper context, the elusive automation objective always appears imminent but unreachable. Projects remain just one more change request away from completion & shrinking scope doesn’t always work. Counterintuitively, even reducing the scope of process automation, can increase the development effort by complicating the process boundaries.
Lost Confidence in process change generally. All parties know it didn’t deliver timely benefits as expected, but hardly anybody knows why & few a keen to try again.
Lost Business Opportunity due to fossilised processes. Rather than being able to respond positively to new situations, more process complexity is incrementally layered onto old, raising unit costs & further sedimenting poor practices. Process platforms promote & promise ongoing agility but can easily become another legacy system.
9
Further IT & Business Division as both parties “assumed” the other knew how to describe & redesign a process for automation. In our experience, both parties tend to have a dangerously limited common-view of the true process anatomy & the suitable forms for sharing such models.
Blame the Software Partners is a common & easily promoted response to project problems. After all, they should have known how to do “this” (in “our” business). Such blame is about as logical as getting onto the wrong train then blaming the train company for taking you to the wrong destination. You must have a way to decode where your vendor will take you, as they all have great value to add, in different ways.
Active Resistance to Process Change, both by the business & IT, often leaving management blackmailed into inaction or at best the pursuit of trivial, seemingly low risk benefits.
Excessive & Blanket Governance to avoid similar process change overruns. Devaluing the potential viability & benefits from ALL programmes, not just the elusive, process oriented projects themselves.
However one cares to assess these implications, nobody would consider them positive or tolerable. The true cost of changing processes in an ad-hoc manner has proven to be unacceptable.
10
Whats NeededAs the process change diagram opposite illustrates, there’s plenty of room for errors & misinterpretation in any IT project. There’s many traditional artefacts being exchanged but with little common meaning.
It became vividly clear to us, sometime back, that process change programmes lacked a single, central & common perspective to faithfully describe exactly what’s going on in the business operations in a form that is of value to technical & programme folk.
We sat through countless hours of meetings with people talking at complete cross purposes, using the same ambiguous words, like; process, MI, SLA, rule & so on ...
A New Account process to a senior manager usually means the complete end to end customer on-boarding activity, while to an IT specialist New Business may just mean creating a new customer record in a central database.
A trivial example perhaps, but illustrative of the problem.
Processes are intangible things, you can’t touch one, you only see the “evidence” of process conduct in things like updated data, physical correspondence & happy customers.
Describing business processes is like describing an iceberg, much of the subject matter is hidden.
We therefore need a way to talk about & define the hidden portions & a method to better describe the thing as a whole.
We invested some years watching manual & semi-automated work in action decoding the hidden parts & the strategies people used to resolve cases in this context. We wanted to develop a rigorous yet generally understandable perspective of a process, enabling widespread process improvement & automation. Something unambiguous yet simple.
11
FlowchartsData ModelsUse Case DiagramsDetailed Technical Design
Procedures ManualsTeam BehaviourQuality & SLA’sStaff TrainingTacit KnowledgeEvents, Goals & Plans
FlowchartsDecision TablesEntity ModelFunctional Mock UpsProduct Speci"cationFunctional RequirementsNon-Functional Requirements
Unit Test ScriptsWireframesDeployment ModelTest Data
Test StrategyTest ScriptsTest DataFunctional TestsUsability TestsSolution PerformanceCumulative Defects
Updated IT SystemsRevitalised CultureAutomated ProcessesHigher Efficiency
CompliantNew Operational Policies
Differentiated ServicesAgile ProcessesCompliant OperationsIntegrated, IndustrialisedLow Cost, High Quality
Operational PoliciesWork$ow Paernsthe Core IT Systemsthe CultureProductsHistory Quality
New Procedures ManualsNew Operating Policies
Pilot Process TestingTraining Material
How the STAFF see the
Business operating
How the TEST Team interpret
the ANALYSTS.
How the BUSINESS EVENTUALLY
operates.
How the BUSINESS ACTUALLY behaves &
operates.
How the ANALYSTS interpret the Staff.
How MANAGEMENT see
the business working.
Traditional BPM Process
Change Cycle
How the TRANSITION Team
interpret the STAFF.
How DEVELOPMENT interpret the
Analysts.
12
Form follows functionModels help us describe things. No model is ever 100% correct but some models are more useful than others. Ideally models align well with both reality and the configuration of any potential automation platform.
If we wish to develop a useful and realistic model of any business process we need to be vividly clear as to exactly what constitutes a business process. What is its anatomy?
We have not drawn our process insights from engineering theory or science, but rather how humans go about conducting work.
People are goal oriented. They always endeavour to fill in the gaps between the current state of a case and the desired outcome. Sometimes this journey is quite predictable and can be illustrated in a procedural flow-chart or BPMN format, but not always. We need a more general model.
But this begs the question, what do we mean by the state of a case? Again we look to how people react when performing work.
People constantly react to events. They then apply some rule, in their head, to assess the next best action or task. This pattern repeats incessantly.
Let’s look at an example.
If I was to drop a case folder on your desk and say, “can you process this” what would you do in response to this “new case” Event.
You would open the file and start to assess the state of the case by reading over the contents or case data. You are now applying rules in your head to determine what action to take based upon what you read.
Let’s say the folder contains a standard quotation ready to send to the client but is marked as needing “underwriting approval.” So “underwriting approval” is
13
obviously the next task that now needs to be performed. But there may be some more rules.
If you are an underwriter with approval authority then you might just review and approve it. That’s the “review & approval” task.
If you do not have authority then you will reroute the folder to somebody who can approve it. A “case forwarding” task.
You can see the event-condition-action pattern happening.
Also, if it’s after 5pm you might return the folder to the central pool of work in progress and go home. This is an example of a clock or timer event, it’s after 5pm. Company policy sets a condition that all desks are empty overnight, so the action is to return the file.
You have been reading the data in the folder, applying rules or conditions then taking action. This sort of pattern is not easily represented in a flow-chart so we don’t bother with that.
8020 Process Design models business processes using the same real-world constructs that people use.
The “things” we work on are typically just data. An approved quote is simply a standard quote with an authorised signature. It’s effectively the same thing in a slightly different state. A quote with an approval.
We call these things Process Work Entities or just Entities. Each Entity can have a number of valid States throughout its lifecycle in a process. In our example the quote is now is the APPROVED state.
However, to shift it from the CALCULATED state to the APPROVED state we had to perform the “review & approval” Task. This is a single logical unit of work directed at a single Entity and performed by a single Worker. That’s our definition of a Task.
Since a Task has to be conducted at the right time we introduce the idea of Start Rules. This is our über flexible way of sequencing Tasks without getting tangled in flowcharts. Like a person each task responds to events, checks if its OK to start then performs its action accordingly.
So we now have a process modelling approach based upon simple, proven, real-world constructs: Events, Tasks, Entities, Workers & Start Rules.
14
For business processes 8020™ presents a simple yet rigorous organising principle, assembled from the actual schema humans use to conduct value adding work.
8020 expresses a business process during business design by simply defining: Entities, States, Tasks, Start Rules & Workers. Workers can be people or computers.
In the real world, visible or tangible portions of a process, the People, Tasks & Physical Documents are intertwined with invisible abstract components such as: Computer Applications, Process Data, Valid Data States, Rules & Business Events.
We tend to place great emphasis on the obvious physical components & (to our peril) tend to overlook the more abstract bits.
8020 gives substance & meaning to these abstract process components so they can be modelled, discussed & designed explicitly.
8020 Components
WorkersStart RulesState
TasksProducts
“Everything should be as simple as possible, but no more” Albert Einstein
15
Unlike physical things, data unfortunately exists in many forms & in many formats. A new customer account application could exist as an unstructured paper form, a well structured record in electronic format as collected by a web site, perhaps as a scanned image or even a scan OCR’d to a central database &, it could be all of these at once!
In 8020 an Entity could relate to data in a single physical document, a single logical document (in a variety of formats) or data in a logical group of related documents.
The exact organisation of an Entity, or its Sub-Entities, is less important than surfacing the existence of the data itself. Things can easily be rearranged later, so long as we have exposed the existence of important data.
Our experience shows that people manage the abstract “process data puzzle” using two effective strategies. Proven real-world approaches that are central to 8020™.
First of all staff develop a “mental model” of all the data, or Entities, potentially involved in a process*.
What are all the “things” I need to process & how are they “constructed” ?
People also understand the various relationships among process Entities & Sub-Entities. For example, an investment instruction in one system must match the customer’s application form in another. Or an application form may specify more than one investment.
Finally, people understand or learn the valid States each Entity can assume during it’s lifecycle. An Investment Entity could pass through the lifecycle states of: New, Valid, Rejected, Payment Matched, OK to Trade, Invested & Archived, for example.
The 8020 Entity Model is a central anchoring point that enables rapid & precise elaboration of the process as a whole, since it simply describes all process data, in all forms & formats across all locations.
It is after all the change in Entity Data & States that adds the customer value.
The value-add here in its simplest form is transforming the hand written details on a piece of paper, plus a
16
payment into a legal & operational investment relationship, or a rejection.
Entity State is very interesting. It’s the very “thing” that best describes the customer’s perspective. Our application could exist in any one of a number of states & even regress to a prior state. It is the final State of the final Entity that the customer understands & values.
If we find States that appear to add little value, like Pending states, then during design we try to eliminate the need for that state & all the low value adding Work or Tasks needed to achieve it.
We found that people, unconsciously & constantly assess the state of a process Entity, then pursue a goal to move it to the next viable state. This is work, driven by the data state, not work for the sake of work, simply because it was defined in a flow chart.
There can be various independent or parallel Tasks required to achieve the next valid, value adding state for a process Entity & there may even exist competing alternatives. Whoever sets the state first “wins.”
The countless patterns of work required to optimise a process are easily described in structured English in
8020 without concern for the technical complexity of how to conduct such work during operations. More on this later.
Let’s talk about work or Tasks.
Nothing changes & no value is added till somebody, or some machine, does something. This is work & for want of other terminology in 8020 we refer to the basic unit of work as a Task.
To be more specific, a Task is the smallest logical block of work that can be performed by one person or one service on a single Work Entity. A Task is typically designed to alter the Entity State to a higher value state.
Tasks or Activities are often expressed in a flowchart where their sequence of operation is explicitly defined. This task starts after that task & so on. This modelling approach is OK, up to a point but can degrade into complexity.
Add in the reality that every flowchart is only an approximation, a single variant often called the “happy day” scenario that defines say 80% of cases which leaves a block of work called “exceptions” to be handled some other way. Perhaps another flowchart.
17
18
Even if the business can understand & agrees with the complexity it will surely lose something in technical translation as it is configured into a BPMS software system.
In 8020 we leave the explicit sequencing of work completely out of the design phase & instead talk about Task Start Rules. These rules are evaluated only when the process is operating to determine which Task, or set of Tasks, to initiate for action.
A task in a flowchart only really knows about the previous task (or gateway) & starts only when that completes. In 8020 Task Start Rules have full visibility of all the Tasks, Entities, States & the system Clock. Tasks can be defined to start, often concurrently with other tasks, based upon a wide variety of valid business conditions.
Using this model 8020 eliminates the need for “exceptions”, every case has it’s own “happy day” pathway to completion based upon valid Entity States, valid Business Rules & a Just In Time approach to expediting work case by case.
A Task may define any number of actions. For example, it could instruct a person on how to perform a manual
task, perhaps pop up a data-entry form, switch to a mainframe screen or call a predefined software service. Upon completion the Task will update the related Entity State & broadcast it’s completion, for those other Tasks that may be interested.
Every Task has one or more assigned Workers. A Worker can be a single person, a group of people or a computer service. We could for example, assign a Payment Matching Task to an automated computer service & upon failure the task can be reassigned to a member of the group “Payment Processors” & perhaps an individual such as “the Supervisor”.
During operation Tasks will be linked to real groups or people & appear on one or more Work Lists. Work Lists are simply a personalised query across the whole live population of relevant cases.
Tasks may be either “picked” at will by a Worker or “pushed” to the Worker without choice.
If we anticipate automating a business process then we need to apply a basic level of rigour to the design exercise. This is the 8020 Process Design Workshop & produces adequate detail for immediate automation.
Experience shows that physical presence in the same room with simple tools like 4x4 PostIt notes & a facilitator is a fun & productive approach.
The Process Design Workshop is limited to 3 hours with one or two breaks & works through the topics shown here.
Output includes a ValueTree model and associated attributes suitable for immediate automation.
Scope
1.Entities
2.States
4.Start Rules
3.Tasks
5.Workers
19
1 Develop an Entity Model of logical process entities & their data elements.
Operational Staff maintain a mental picture of all relevant process data & 8020™ does the same, using a logical data model. This can be further divided into sub-entities. During design we build an Entity Breakdown Structure using blue 4” x 4” PostIt Notes. Entities are nouns.
2 Develop State Models for each Entity
What are the important states for a given Entity & what are the valid transitions allowed throughout its lifecycle in the process? If a customer was present would they identify any States that do not appear to add value? Can we remove such waste? States are typically adjectives.
3 Identify the Tasks needed to change Entity States
List out the Tasks that drive each State Transition. An “Approval” Task, for example, will set an Entity as “Approved” or “Rejected”. Tasks typically are named starting with a verb & are associated with the Entity or State.
4 Organise Start Rules.
Start Rules control the sequencing of Tasks. Business Rules perform automated actions or constrain activity. For now we focus upon Task Start Rules & the criteria that will start a Task. An Entity State change will typically trigger most rules, but we can also define more complex rules that consider say, elapsed time, service levels & the status of other Tasks. Use the words “Start When …”
5 Identify Workers, both people & computers.
During design we need to invent logical groups of people or computers to perform a task. During runtime we will bind such participants to real directories & their Work Lists. For now, we just need to sensibly allocate the work.
Process Design Workshop
8020 presents process components as a ValueTreetm to remove the distraction of trying to sequence work at the same time as designing the fundamental process components.
A ValueTree combines the Entity Breakdown Structure (EBS) with the minimum number of value-adding tasks (WBS) needed to shift each Entity to a completed state.
At this stage we can assume any Task can start at any time as might be appropriate for its associated Entity. Our prime focus is reconciling all the data & activity associated with the process. Start Rules will be added later.
21
ValueTree ModelA simple way to account for all the parts of a business process. The Entity structure is shown in blue and the associated Tasks in yellow. When placed into operation only the tasks in an 8020 model perform any work while the entities manage the process case data.
New Business
Create New
Application
FormApplication
Form
Capture
Application
Forms Refer fo
r
Advice
Change
Advisor
Details Setup New
Advisor
InvestmentNew Business
Query Supervisor
Checking Advisor Query Post
Issue NINO
Investment Instruction
Match
Funds with
Instructio
n Contribution Submit
Trade
Amend
Contributio
nTransfer-In
Auto await
Transfer
Payment Update
Transfer
Value Initiate
Transfer-In
Request
Query Non-
Payment DirectDebit
DebitCard
BankDeposit
Chase
Transfer-In
Non Payment Update
Received
Transfer-In
ValueQuery
Transfer
Value Cheques from
Bank
Statement Enter Card
Authorisation
Code
Client Original
Documents Link New
Document Supporting Documents
Cheque Physical
Cheque
Capture Match
Cheque to
Application
Deposit
Cheque
Advisor
Document
Chase
Update Direct
Debit Details
22
Instant WorkflowLarge tracts of process control & efficiency can be achieved by quickly automating the distribution & management of work. This is commonly called workflow but has proven rather rigid in both the style of definition & the resulting business operations.
Workflow solutions assume that most of the work will be performed manually & focus just upon distribution.
8020 takes a new approach & enables any BPMS platform to directly interpret the actual process design to determine the workflow, case by case, customer by customer at runtime. Realtime work sequencing.
A small BPMS process application needs to be configured from our reference design to read the design files (XML) & execute the workflow.
We generally manage an instance of the process design for each active case in the system which also enables alterations to process behaviour during runtime without affecting other live cases.
Moreover the 8020 idea of “Extra Tasks” allows a user to document that they added a new Task fro this case that may not have existed in the standard design.
When invoked, an Extra Task will ask for a basic level of documentation from the user & will log the full state of the case for future design refinements. The Extra Task can now augment the standard design & by default be started whenever the same case state repeats. Processes can learn new tricks by experience.
Operating "Consumer Division End of Period Close Process"
Work Task "Collate Flash Report"
11:48am Tue 7-May-2012 | Pat Participant | Help | Preferences | Log Off
New Flash Report Spreadsheet : Blank
Ready for Reconciliation & Review ...
Work InstructionsThis task starts upon submission of ALL the Divisional Reports and EACH interim report.
For each of the reports you will need to …
1. Append the Divisional Sheet to the master Flash Report document.
2. Lock the DIvision Folder for this reporting period.
3. Select DEFAULT Outcome "Ready for Reconciliation and Review …" OR "Requires Re-Work …"
Click for full Process Notes
"Flash Report" Data
Use this Participant Task bench to reference work instructions, track progress, share notes and report on your work status.
Estimated Duration: 4 hours 30 minutesTime to Deadline: 21m 38s
Notes & Documents
Actions ...Forward this Task ...
Complete & Ready for Approval ...
Delegate this Task ...
Reject & Return to Group Work List ...
In-Progress : Return to my Work List ...
Requires Re-Work ...
Task Outcome ...Quality (list: Red, Amber, Green)
Expires (caseTime: 2 weeks)
Template (file: //OPS/RPTS/Oct-2012.xls)
...
Yesterday 14:17 Returned to my Work List
▶ View SYSTAG Summary Screen ...
Today 10:02 "Ready for Reconciliation & Review …"
++ - -
Search
Yesterday 15:12 ◼ Appended Summary
Mon 5-May 8:15 Amended Mortgage product line to reflect final SYSTAG adjustment of £132,450.
23
Start RulesTask Start Rules constrain Tasks from starting at inappropriate times but also ensure they start as early as possible to ensure timely, compliant completion of work.
Completing co-ordinated work on a single case in parallel is a great way to expedite customer results & balance internal workloads. However, even the simplest BPMN flowchart gateway structure is challenging to construct without invalidating the design.
Start Rules allow any number of Tasks to start at any appropriate time & are exponentially more flexible than trying to specify the same behaviour with flowchart decisions. Start Rules can be written around Entity data & States, other Task behaviours & the system Clock.
Some examples follow:
A customer investment may be held awaiting funds, missing advisor details, Customer ID & perhaps a National Insurance Number. Without having to bother about all the possible combinations these four tasks could exhibit, (there are 24 possible combinations by the way) a “Trade Investment” Task is simply specified to start when “things are in the right state.”
The “Application” is APPROVED & the “Investment” is VALID & the “Contribution” is PAID.
Two tasks that each perform half of a “four-eyes” approval can simply be specified to start when the other starts.
Start Rules can also refer to the clock. For example, an “Escalate to Supervisor” Task may be triggered by any Task that exceeds its Estimated Deadline OR a any case that may have been alive for over 48 hours.
24
Since the 8020 process model is formally structured, yet simple, meaningful plain English documentation can be generated directly from the model.
Documentation New BusinessNew Business product is considered COMPLETE when ANY sub products are COMPLETE.
New Business
Create
New
Applicati
on
Form
Application Form
Client Original Documents
Linkin
g &
Notifica
tion
of New
Documen
t
Supporting Documents
Cheque Physical
Valid Lifecycle States for New Business
Application Complete COMPLETE
Application in Progress
Inbound Call
New Application Received
Not Yet Linked to an Application DEFAULT
Pend: Awaiting NINO
New Business Data
<ProductDataName> TEXT
<ProductDataName> DURATION
“Investment New Business” Process Documentation V3.02
Page: 5 of 45 Printed: Monday, 9 July 2012
ValueTree™
New
Bu
sine
ss
Crea
te N
ew
Appl
icatio
n
Form
Appl
icat
ion
Form
Cap
ture
Appl
icatio
n
Form
s
Ref
er fo
r
Advic
e
Bro
ker
Adm
in
Chan
ge
Advis
or
Deta
ils B
roke
r
Adm
in Ne
w
Advis
or
Inve
stm
ent
New Bu
sines
s
Quer
y
Sup
ervis
or
Chec
king
Advi
sor
Que
ry P
ost
Issue
NIN
O
Inve
stm
ent
Inst
ruct
ion
Mat
ch F
unds
with
Inve
stm
ent
Inst
ruct
ionCo
ntrib
utio
n
Subm
it Tr
ade
Am
end
Cont
ribut
ionTr
ansf
er-In
Auto
await
Tran
sfer
Paym
ent
Upda
te
Tran
sfer
Value
Initia
te
Tran
sfer-I
n
Requ
est Q
uery
Non
-
Paym
ent
Dire
ct D
ebit
Debi
t Car
d
Bank
Dep
osit
Cha
se
Tran
sfer-I
n
Non Paym
ent
Upd
ate
Rece
ived
Tran
sfer-I
n
Value
Quer
y
Tran
sfer
Value
Cheq
ues
from
Ban
k
Stat
emen
t
Ent
er D
ebit
Card
Auth
orisa
tion
Code
Clie
nt
Orig
inal
Do
cum
ents
Linkin
g &
Notifi
catio
n
of N
ew
Docu
men
tSu
ppor
ting
Docu
men
ts
Cheq
ue
Phys
ical
Che
que
Capt
ure
Cheq
ue
Mat
ch to
Appl
icatio
n
Depo
sit
Cheq
ue
Advis
or
Docu
men
t
Chas
e
Upd
ate
Dire
ct D
ebit
Deta
ils
“Investment New Business” Process Documentation V3.02
Page: 4 of 45 Printed: Monday, 9 July 2012
Process Products & TasksValueTree™!4New Business!5Advisor!6Investment!7Bank Deposit!8Debit Card!9Direct Debit!10Contribution!11Transfer-In!12Investment Instruction!13Cheque Physical!14Supporting Documents!15Client Original Documents!16Application Form!17Cheques from Bank Statement!19Match Contribution with Investment Instruction!20Broker Admin Change Advisor Details!21Linking and Notification of New Documents!22Refer for Advice!23Amend Contribution!24Update Transfer Value!25Initiate Transfer-In Request!26Query Non-Payment!27Update Direct Debit Details!28Enter Debit Card Authorisation Code!29Chase Transfer-In Non Payment!30Capture Application Forms!31Query Transfer Value!32New Business Query!33Supervisor Checking!34Broker Admin New Advisor!35Advisor Document Chase!36
“Investment New Business” Process Documentation V3.02
Page: 2 of 45 Printed: Monday, 9 July 2012
“Investment New Business”
Process Documentation
Prepared by: Caroline Turner
eMail: [email protected]
Created: Fri 18-May-2-2012
Modified: Tue 10-Jul-2012
Version: 3.02
Process Description:
Opening of new accounts and policies for our full range of tax
effective products and investment options. Includes Transfers-In but
excludes Transfers-Out and Re-Registrations.
Case starts upon:
Receipt of an Application Form by mail, eMail, fax or web site.
Case completes when:
Application Invested, Rejected or Timed Out.
Deeper AutomationThe 8020 ValueTree model can quickly define quite complex and sophisticated process models, but it is largely focussed upon securing the first benefit of automation, command and control.
This is the necessary workflow, or in our case ThingFlow, that ensures work is scheduled appropriately and balanced across teams
Implementing a highly dynamic & event driven workflow like this delivers significant operational benefits at very low cost & risk.
Deeper automation of individual Tasks extends these benefits yet again by eliminating either human error, manual effort or both.
We take an 8020 design as the framework. Using the ValueTree & associated attributes we now perform some deeper analysis. Each Task remains as an atomic & logical unit of work focussed upon a single Entity
but we can take advantage of contemporary BPMS platforms to further group and enrich Task behaviour.
Typical additional and deeper automation features include:
• Presenting a sequence of data entry or enquiry forms to a participant.
• Directly popping a relevant mainframe screen based upon the current state of the case.
• Calling a SOAP request to further enrich Entity data or initiate remote actions.
• Executing more complex business rules perhaps in a rules engine.
• Generating outbound correspondence based upon case data.
• External messaging to suppliers and customer systems.
… and much more.
26
8020 Training Executive Workshop A thought provoking 90 minute session to expose management to new process
automation perspectives. Groups are typically aligned by level or department to facilitate lively discussion & constructive action.
8020 Introduction A one hour fun session designed to help business teams understand the basic components of an 8020 design & its associated terminology. This is a precursor to attending a 3 hour 8020 Process Design Workshop.
8020 Process Design Workshop Facilitator
A 3 hour course designed to step a new facilitator through the 8020 Process Design Workshop documentation and prepare them to conduct design sessions. The instructor will participate in the first workshop to embed the training and support the facilitator.
8020 Practitioner 8020 work experience is a prerequisite for this one day intensive session for Business Analysts, Process Analysts, Architects & Business Engineers. We present the various 8020™ Methods used to elicit & design highly efficient automated process solutions. A short, open book project is to be submitted within 7 days of the course & is estimated at 2-3 hours work.
27
8020 Method fits here ...C
orpo
rate
& P
rogr
amm
e G
over
nanc
e (M
SP)
Proj
ect M
anag
emen
t (PR
INC
E2)
Integration Method(SOA)
Software Development Methods Rup, Agile, ITIL
BPM Vendor Configuration Method
BPMS Production Platform Integration Bus
Patterns & Tools
Custom Code
Business Stake Holders Technical Team
ManualWork
Manual Procedures
LEAN 6-Sigma
8020 Process Design & Delivery Method
28
for the More TechnicalArtefact-centric BPM is new, but the principles are timeless. Just as computer science evolved from procedural languages like Cobol to more appropriate forms such as object oriented techniques, so too is business process evolving from procedural flowcharts and BPMN to the consideration of artefacts or Process Entities.
An Entity can be conceptually aligned with a class and it’s runtime instances are objects. Sub-Entities can exhibit aggregation and composition relationships with their parent.
Tasks are associated with getting and setting Entity data and therefore appear like methods. Entity State is akin to hidden class data and is usually updated at the conclusion of a Work Task.
Start Rules follow a traditional Event-Condition-Action (ECA) model. An object, a Task or an Entity instance will broadcast an event to signal any change in status
and all other subscribing objects will fire a condition rule and initiate an associated action, such as starting.
We are developing a graphical ValueTree editor, initially for iPad then for any HTML5 browser. We call this the Process Planner Workbench. The Workbench creates, edits and writes an extensible XML property list file that always conforms to at least the base 8020 reference specification. We use the file extension .PROCESS and each file describes a tree of executable Tasks and Sub-Entities related to a single root Entity. *.PROCESS files can be linked or merged to construct composite processes.
Each *.PROCESS file can be transformed by XSL to produce printed documentation (via XSL-FO). Many instances of a *.PROCESS file can also be executed in an Operational Workspace, typically a BPMS platform. This provides an economic environment for design time components to be linked to real-world LDAP directories, security, data integration and work-lists.
29
At runtime an automated business process is guided by its definition [file] and interacts with the following process components.
30
updatechangesthrow
update
ini0ateperform
has
providesfacts
startthrow
displayed6on
push
use
call
updateState
TasksEvents Rules
En..es
WorkersWork2Lists
Forms
Services Systems
update
interac
t6with
interac
t
with
©"Ian"Ramsay"2009-2010
interac
t6with
pick
sub
Group
hasbelong6to
Security
exposes6
author
ises6
populate
8020 has been developed by Ian Ramsay. It is a new way to look at, describe and understand any modern service business process.
Ian studied Engineering, Computer Science and Business Administration but 8020 owes more to his observation of how people conduct complex work and the counterintuitive behaviour of common operational business processes.
These insights have been blended with contemporary process science and systems thinking to produce a rigorous yet simple approach of value to both business and technical people.
The 8020 approach is a response to the problems seen in a wide variety of process improvement and automation projects in the services sector.
Some 20% of the work lends itself readily to traditional process change techniques, methods mostly borrowed from the manufacturing sector, while 80% of the business operations remains devilishly difficult to model, understand or automate. Much of this important work is driven unpredictably by customer demand yet must remain compliant, cost effective & timely.
Hence the need for an enhanced approach to understanding and automating some 80% of our business operations.
Do contact me to learn more or discuss your particular business process automation requirements and how we may be able to expedite your results while reducing risk.
