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 specic 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 conguration methods. 8020 is the rst formal approach based upon the exciting new eld 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 eort, translation errors, rework, operational risk & development costs. We use this approach in our delivery assignments, in concert with client specic change methods & have seen benets for our customers in all the following areas;

Executive Engagement & Education. Programme Cost Benet 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. ian.ramsay@me.com +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 customers own case data & the myriad of value altering states it assumes. Value is created by transforming this data, eciently & 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 dene 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 benets repeatably, process change & automation programmes need to move beyond the ad-hoc work-centric methods & better dene the things that add value. Its not the work that customers value, its the outcome namely the process data, information & service experience.
2

Whole departments are currently dedicated to mapping processes, developing owcharts of work, analysing wasted operational eort & rearranging work to reduce time, cost & defects. LEAN, 6-Sigma & Systems Thinking certainly oer 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 sucient, for eective process automation projects in nancial services. Additional perspectives on process change are required ...
3

Is the MODEL an accurate picture of the BUSINESS OR is the BUSINESS compliant with the MODEL ?
4

The Current Situation

Processes can be complex things. They appear hard to dene or automate. Perceived complexity of process denition & automation often means we fail to automate eectively 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 nancial services has centred around improving the eciency of sta. To do this we have borrowed techniques & methods from the (mature & ecient) manufacturing industry, such as; owcharting, 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 ows of work, materials & sta organisation) while trivialising the more abstract aspects (such as

customer process data, valid data states, business events & goals). This simplistic approach is generally OK for manufacturing as the focus of work is tangible, its mainly materials. There are limited dimensions to describe. However, in nancial 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 sta, or both! Any benets from process change are quickly oset by errors & compensating work during operations. With this imprecise approach, problems with process change programmes are inevitable & well documented. now

Common Problems
Common Symptoms

The business give us incomplete requirements. IT seem to overcomplicate every project. There are so many exceptions we are not sure theres such a thing as a real process ow. IT dont 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.

As described before, owcharts 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 ows, or is sequenced. When processing was predominantly manual & to some extent with basic computerised workow based operations, people are trained (or take the initiative) to react & conduct the missing aspects of a process. A owchart & a few specications are more than adequate. We often nd operational sta & 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 aord 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 sta are not business analysts, nor should they be. Be aware ... There exists a large communications gap between unconscious competence & explicitly precise automation!

The recurring problem we nd in most change programmes is the limited awareness of all process dimensions, by all parties, leading to misunderstandings & costly rework. So owcharts are OK for understanding largely manual processes & basic workow, 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:

real world processing & we use simple terminology that accurately reects 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 conguring their systems. This is good but they tend to be focussed mainly upon how to use the Gartners View Most businesses have a limited, software cleverly & avoid explicit under-standing of endtechnical 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.
to-end business processes, & if any understanding exists, it is often tucked away within disparate groups across the organisation. It's rare to nd an organisation that has linked its scattered process competencies into a comprehensive strategy. Michael Melenovsky & Jim Sinur, Gartner Research

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 rened 8020 & its components upon the observed behaviour of

Business Implications
Outcomes 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. Thats why the potential benets 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 doesnt always work. Counterintuitively, even reducing the scope of process automation, can increase the development eort by complicating the process boundaries. Lost Condence in process change generally. All parties know it didnt deliver timely benets 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.

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 commonview 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 dierent 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 benets. Excessive & Blanket Governance to avoid similar process change overruns. Devaluing the potential viability & benets 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 Needed
As the process change diagram opposite illustrates, theres plenty of room for errors & misinterpretation in any IT project. Theres 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 whats 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 onboarding 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 cant 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 & dene the hidden portions & a method to better describe the thing as a whole. We invested some years watching manual & semiautomated 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

Dierentiated Services Agile Processes Compliant Operations Integrated, Industrialised Low Cost, High Quality Operational Policies Work ow Paerns the Core IT Systems the Culture Products History How the BUSINESS Quality ACTUALLY behaves & operates. How MANAGEMENT see the business working. How the BUSINESS EVENTUALLY operates. Updated IT Systems Revitalised Culture Automated Processes Higher Eciency Compliant New Operational Policies

Procedures Manuals Team Behaviour Quality & SLAs Sta Training Tacit Knowledge Events, Goals & Plans

How the STAFF see the Business operating

Traditional BPM Process Change Cycle

How the TRANSITION Team interpret the STAFF.

New Procedures Manuals New Operating Policies Pilot Process Testing Training Material

How the Flowcharts How the ANALYSTS TEST Team interpret Decision Tables interpret the Sta. the ANALYSTS. Entity Model Functional Mock Ups How DEVELOPMENT Product Speci cation interpret the Functional Requirements Analysts. Non-Functional Requirements Flowcharts Unit Test Scripts Data Models Wireframes Use Case Diagrams Deployment Model Detailed Technical Design Test Data

Test Strategy Test Scripts Test Data Functional Tests Usability Tests Solution Performance Cumulative Defects

12

Form follows function

Models 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 conguration 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 ll 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 ow-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. Lets 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 le 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. Lets 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. Thats 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 its 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, its after 5pm. Company policy sets a condition that all desks are empty overnight, so the action is to return the le. 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 ow-chart so we dont 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. Its eectively the same thing in a slightly dierent 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. Thats our denition 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 exible way of sequencing Tasks without getting tangled in owcharts. 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

8020 Components
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 dening: 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.

Everything should be as simple as possible, but no more Albert Einstein

Products

Tasks

State

Start Rules

Workers

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 OCRd 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 eective strategies. Proven real-world approaches that are central to 8020. First of all sta 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 customers 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 its 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. Its the very thing that best describes the customers perspective. Our application could exist in any one of a number of states & even regress to a prior state. It is the nal State of the nal Entity that the customer understands & values. If we nd 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 dened in a ow 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 rst 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. Lets 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 specic, 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 owchart where their sequence of operation is explicitly dened. 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 owchart is only an approximation, a single variant often called the happy day scenario that denes say 80% of cases which leaves a block of work called exceptions to be handled some other way. Perhaps another owchart.

17

Even if the business can understand & agrees with the complexity it will surely lose something in technical translation as it is congured 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 owchart 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 dened 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 its 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 dene 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 predened software service. Upon completion the Task will update the related Entity State & broadcast its 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.

18

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.

e p o c S

s e t a t 2.S es l u R rt a t S . 4
s

s e i t i .Ent sk a T . 3

rs e k r o 5.W

19

Process Design Workshop

1
Develop an Entity Model of logical process entities & their data elements. Develop State Models for each Entity Identify the Tasks needed to change Entity States Organise Start Rules. Operational Sta maintain a mental picture of all relevant process data & 8020 does the same, using a logical data model. This can be further divided into subentities. During design we build an Entity Breakdown Structure using blue 4 x 4 PostIt Notes. Entities are nouns. 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. 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. 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 dene more complex rules that consider say, elapsed time, service levels & the status of other Tasks. Use the words Start When 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.

3 4

Identify Workers, both people & computers.

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

Au t Tr o a Pa ans wait ym fer en t Co A m nt en rib d ut ion

U Tra pda t Va nsfe e lue r

Ap Cap pl tu Fo icati re rm on s

Investment Instruction

Tra Initi a Re nsfe te qu r-I est n Qu Pa ery N ym o en nt Fu Ma Ins nds tch tru wi cti th on Re Ad fer f vic or e

Transfer-In Investment Direct Debit

Cr Ap eate pl N Fo icati ew rm on

Up De dat bit e D De ire ta ct ils

Contribution
Ne w B Qu usin ery es s

Debit Card

A 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.

Au Ente th r C o a Co risat rd de ion Su Tra bmit de

Application Form

T C No ran hase n P sfe ay r-In me nt

Ch Ad ang De viso e ta r ils

Su Ch perv eck iso ing r

Client Original Documents

New Business

Advisor

Bank Deposit

ValueTree Model

U R pd Tra ece ate ns ived f e Va rlue In

Se t Ad up N vis ew or

L Do ink N cu ew me nt

Q Tra uer y Va nsfe lue r

A Do dvi c so Ch ume r as nt e

Q Iss uery ue Po NI st NO

Supporting Documents

Ch eq ue Sta Ban s fro tem k m en t

C Ca hequ pt e ur e

Cheque Physical

C Ma Ap heq tch pli ue ca to tio n

De Ch pos eq it ue

22

Instant Workflow
Large tracts of process control & eciency can be achieved by quickly automating the distribution & management of work. This is commonly called workow but has proven rather rigid in both the style of denition & the resulting business operations. Workow 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 workow, case by case, customer by customer at runtime. Realtime work sequencing. A small BPMS process application needs to be congured from our reference design to read the design les (XML) & execute the workow. 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 aecting 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 renements. 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 Use this Participant Task bench to reference work instructions, track progress, share notes and report on your work status.

Estimated Duration:

Work Instructions
This 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

Notes & Documents

Search Mon 5-May 8:15 Amended Mortgage product line to reect nal SYSTAG adjustment of 132,450. Yesterday 14:17 Returned to my Work List Yesterday 15:12 Appended Summary Today 10:02 "Ready for Reconciliation & Review "

4 hours 30 minutes
Time to Deadline:

21m 38s Actions ...

Forward this Task ... Delegate this Task ... Reject & Return to Group Work List ... In-Progress : Return to my Work List ... View SYSTAG Summary Screen ...

"Flash Report" Data

Expires (caseTime: 2 weeks) Quality (list: Red, Amber, Green) Template (le: //OPS/RPTS/Oct-2012.xls) ...

Task Outcome ...

New Flash Report Spreadsheet : Blank Ready for Reconciliation & Review ... Complete & Ready for Approval ...

23

+ -

+ -

Requires Re-Work ...

Start Rules
Task 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 owchart 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 exible than trying to specify the same behaviour with owchart 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 specied 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 specied 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

Documentation
Since the 8020 process model is formally structured, yet simple, meaningful plain English documentation can be generated directly from the model.
Investment New Business Process Documentation V3.02

Investment New Business Process Documentation V3.02

New Business
New Business product is considered COMPLETE when ANY sub products are COMPLETE.
New Business

C A rea Fo pp te rm lica Ne tio w n

Valid Lifecycle States for New Business Application Complete Application in Progress Inbound Call New Application Received Not Yet Linked to an Application Pend: Awaiting NINO New Business Data <ProductDataName>
Inves tmen

L N ink o oti ing D f N ca & oc ew ti on um en t

Application Form

Client Original Documents

Supporting Documents

Cheque Physical

COMPLETE

DEFAULT

Process Products & Tasks

ValueTree!4 New Business!5 Advisor! 6 Investment! 7 Bank Deposit!8 Debit Card !9 Direct Debit! 10 Contribution! 11 Transfer-In!12 Cheque Physical! 14
sit po De eque Ch

TEXT DURATION

<ProductDataName>
t New Busin ess Proce

Valu e

ss D ocum

enta

Tree

tion V

3.02

Investment Instruction!13 Supporting Documents!15 Application Form!17 Cheques from Bank Statement!19 Match Contribution with Investment Instruction! 20 Linking and Notication of New Documents!22 Refer for Advice !23
Advisor Suppor ting Doc ument s Cheque Physica l

Inve stm Instruc ent tion

Tran sfer-In

f tax ut ge o -In b ll ran sfers our fu es Tran s for ud olicie ns. Incl p : n d n tio a ptio nt op trations. escri accounts stme ss D gis w . Proce g of ne s and inve d Re-Re b site n r we nin ct Ope rodu rs-Out a fax o e ive p Mail, effect es Transf ail, e d by m rm : o exclu n F o s up ation start ut. pplic ed O Case t of an A ip or Tim en: Rece cted s wh plete ed, Reje com st ve se In Ca ation Applic

s w Ne sines Bu ery Qu

bm

Capture Application Forms!31 Query Transfer Value !32 New Business Query !33 Supervisor Checking!34 Broker Admin New Advisor! 35 Advisor Document Chase!36
for fer e Re vic Ad w Ne te ion ea Cr plicat Ap rm Fo

ad it Tr

Deb it Car d

Su

Con tributio

Direct

Deb

it

s nd Fu ch t Mat en th wi stm ion Inve ruct Inst

e ptur ion Ca icat pl Ap rms Fo

nNo ery t Qu en ym Pa

Page: 2 of 45 Printed: Monday, 9 July 2012

4 of

45 P rinte

d: M

onday , 9 Ju

ly 20

12

aw to Au sfer t Tranymen Pa

Page:

n d en utio Am rib nt Co

ait

te da Up sfer Tranlue Va

ate -In Initi sfer t Tranques Re

te bit da Up ct De Dire tails De

bit De ter n En tio rd Ca thorisa Au de Co

stment

Inve

e as -In Ch sfer Trann t No ymen Pa

Chase Transfer-In Non Payment!30

App lica Form tion

Enter Debit Card Authorisation Code!29

er ok Br in m Ad ange Ch visor Ad tails De

e Tu com e. arolin by: C turner@m 012 ared Prep caroline. -May-2-2 12 l: 8 0 eMai ed: Fri 1 0-Jul-2 1 Creat ed: Tue i Mod n: 3.02 o Versi

Update Direct Debit Details!28

te da d Up ive -In ce Re sfer Tranlue Va

r rviso g pe Su kin ec Ch

Query Non-Payment!27

Client Orig inal Doc ument

Bank Dep

Initiate Transfer-In Request! 26

er w ok Br in Ne m Ad visor Ad

osit

ery Qu sfer Tranlue Va

Update Transfer Value !25

New Busines

Amend Contribution! 24

& ing tion Link tica No New ent of cum Do

si w Bu t Ne ntation n e me estm Inv ss Docu e c o Pr rner

ness

Client Original Documents!16

ue eq to Ch ch ion Mat plicat Ap

Page: 5 of 45 Printed: Monday, 9 July 2012

Broker Admin Change Advisor Details!21

ue eq Ch ure pt Ca

or vis en Ad cum Do ase Ch

s ue nk eq Ch m Ba ent fro em Stat

st Po ery NO Qu e NI Issu

Deeper Automation
The 8020 ValueTree model can quickly dene quite complex and sophisticated process models, but it is largely focussed upon securing the rst benet of automation, command and control. This is the necessary workow, or in our case ThingFlow, that ensures work is scheduled appropriately and balanced across teams Implementing a highly dynamic & event driven workow like this delivers signicant operational benets at very low cost & risk. Deeper automation of individual Tasks extends these benets yet again by eliminating either human error, manual eort 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. 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. 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 rst workshop to embed the training and support the facilitator. 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 ecient 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. 8020 Introduction 8020 Process Design Workshop Facilitator

8020 Practitioner

27

8020 Method fits here ...

Corporate & Programme Governance (MSP) Project Management (PRINCE2) Business Stake Holders Technical Team LEAN 6-Sigma Manual Procedures Manual Work

8020 Process Design & Delivery Method

BPM Vendor Conguration Method

Software Development Methods Rup, Agile, ITIL Integration Method(SOA) Patterns & Tools Custom Code

BPMS Production Platform

Integration Bus

28

for the More Technical

Artefact-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 owcharts and BPMN to the consideration of artefacts or Process Entities. An Entity can be conceptually aligned with a class and its 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 re 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 le that always conforms to at least the base 8020 reference specication. We use the le extension .PROCESS and each le describes a tree of executable Tasks and Sub-Entities related to a single root Entity. *.PROCESS les can be linked or merged to construct composite processes. Each *.PROCESS le can be transformed by XSL to produce printed documentation (via XSL-FO). Many instances of a *.PROCESS le 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 denition [le] and interacts with the following process components.

Security
exposes6

tho au

ris

es6

Group
has

belong6to

Work2Lists
displayed6on ini0ate

pick push perform

Workers
use

Events
changes throw

throw

Rules
update provides facts

start

Tasks
call

ct era int ith w t6w ac r e int t6w rac e t in ith

Forms
update populate

update

State

has

En..es
sub

update

Services

ith

Systems

"Ian"Ramsay"2009-2010

30

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 dicult to model, understand or automate. Much of this important work is driven unpredictably by customer demand yet must remain compliant, cost eective & 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.