Workflow In the Office of the Registrar UC Berkeley Cathy Taruskin August 2, 2004

What is Workflow? Very popular, overused and abused buzzword (3 million hits on Google) Broad definitions: Means vastly different things to different entities Good selling point: everyone is jumping on the workflow bandwagon – “I’m not sure what it is, but it sounds like I need it!”

Typical Definition “The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant* to another for action, according to a set of procedural rules.” *participant = resource (human or machine) SOURCE:

The Jargon Jungle

Jargon Paralysis I don’t have time to wade thru and master the advanced terminology, especially when I don’t need it. Our business processes are so much simpler than all that!

Sample Business Processes Statement of Legal Residence Evaluation Classroom/Outdoor Reservation User Acceptance Testing of Student System Database Conversion Equipment Tracking System Enhancement Request Tracking System Security Approvals

All we want to know is… Where things stand! – What’s happening now Who’s working on what? What’s left to do? Where’s the bottleneck? – What’s already happened How much have we completed? Are we ‘there’ yet?

The Problem… Many administrative applications are too specialized and small-scale to warrant their own ‘system’ Only a few users, but they do this ALL DAY LONG! These functions have been getting done for years in the traditional ‘paper-shuffling’ way – they aren’t necessarily broken so they can get overlooked Low visibility: they might be ‘below the radar’ when campus processes are reviewed

Observations These business processes are simply requests. Someone is asking someone else to ‘do’ something. – Act (please book a classroom for my student group) – Approve (please grant me resident status) – Check (I’ve coded your bug fix; please test) – Sign off (this request has been completed) – Be aware of (big assembly scheduled for Sproul Plaza)

Nouns vs. Verbs If you analyze a typical ‘paper-shuffling’ business process/request in terms of its nouns and verbs some generalizations can be drawn – Most of the nouns (attributes about the request) are ‘custom’ – specific to the process, although even some of the nouns are are generic – THE VERBS ARE ALL GENERIC

The Generic Workflow Verbs Promote – “I’ve reviewed this and I approve” – “I’m done with my part” Demote – “I don’t approve” – “I have questions/I need additional info” – “Something else has to be done before I can approve” Reassign – “The ball’s in your court now” Comment – “I want to note this for the record” – (Required whenever a request is demoted) Notify – (Automated whenever a request is reassigned) – Additional notifications may be needed depending on the process

Even Some Nouns Are Generic Requester Request Description Details Due Date

The Non-Generic Nouns Attributes about the request typically found on a paper or online form Specific to a business process Require customized validation and security rules – Who can update what when – Optional vs. required info – Info that becomes required later on in the process as it becomes known Require custom programming, or an external form

Disparate Processes Common Verbs All of my business processes share the same verbs: – Promote (approve, signoff, I did my piece) – Demote (need more info, not approved) – Notify (let the requester know what’s going on) – Reassign – Comment Therefore all of my business processes can share the same application!

“Barebones” Workflow Framework Views workflow as a sequential series of handoffs (concurrent activities can be handled as lower-level tasks) A business process with many handoffs is not necessarily complex. Going from step 1 to 2 is no more complex than going from step 23 to 24 Allows a preexisting web request form to be ‘plugged in’ without too much programming Keep it simple: how little can I get away with? Eliminate need for programming wherever possible

Programmer-Free Features Workflow – Administrator can design the workflow to define who can promote or demote, based on workgroup or role – Administrator can easily tweak the process as needed Notifications – Some notifications are built in – Others can be configured by an administrator Reporting – Anyone can create or copy a report – No programming required after initial setup

Programmer-Dependent Needs Database setup for the custom fields on a request form, based on the business process Supporting data elements (dropdown lists, etc.) Validation of these custom fields – Which are optional/required – Restricted update – Unknown at beginning of process but required at some point Reusable code templates enable programming for new processes to be completed in days, or just a few weeks (depending on form complexity)

Demo