Professional Documents
Culture Documents
Ian Ramsay
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
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
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
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.
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
3 4
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
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
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.
Application Form
New Business
Advisor
Bank Deposit
ValueTree Model
Se t Ad up N vis ew or
L Do ink N cu ew me nt
A Do dvi c so Ch ume r as nt e
Q Iss uery ue Po NI st NO
Supporting Documents
C Ca hequ pt e ur e
Cheque Physical
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
4 hours 30 minutes
Time to Deadline:
23
+ -
+ -
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
New Business
New Business product is considered COMPLETE when ANY sub products are COMPLETE.
New Business
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
Application Form
Supporting Documents
Cheque Physical
COMPLETE
DEFAULT
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
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
nNo ery t Qu en ym Pa
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
stment
Inve
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
r rviso g pe Su kin ec Ch
Query Non-Payment!27
Bank Dep
er w ok Br in Ne m Ad visor Ad
osit
New Busines
Amend Contribution! 24
ness
ue eq Ch ure pt Ca
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.
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
Software Development Methods Rup, Agile, ITIL Integration Method(SOA) Patterns & Tools Custom Code
Integration Bus
28
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
Workers
use
Events
changes throw
throw
Rules
update provides facts
start
Tasks
call
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.