Organizations go to great lengths to acquire, improve and maintain a culture and infrastructure that gives them a competitive advantage. Organizations that succeed persist; organizations that are not successful at organization building usually fail over time, unless they have a monopoly in a particular market segment.
Suppose you want to go into competition with Microsoft with an “innovative” spreadsheet product called “My_Excel”.
Because spreadsheets are widely used, you would need to offer My_Excel at a low price.
So, your strategy might be to make My_Excel come “out-of-the box” with a range of “standard” workflow templates so that the user can plug the product in and immediately start “using” your product.
In your haste to get to market quickly, you skip over the usually exhaustive design prototyping where you improve the design of your product.
You decide to concentrate on look-and-feel and you sidestep issues of “configuration” by providing a seemingly impressive portfolio of workflows.
Anyone wanting other workflows can call an 800 number and speak to a business analyst who will bend over backwards to “customize” the product to suit your “special” needs. At a fee that can easily exceed the standard license fee for the product.
What is wrong with this scenario?
Well, just about everything and the outcome is predictable – no one will buy your product when they can get, for about the “same” price, a spreadsheet environment where THEY can put in place THEIR workflows. Not to mention avoid consulting fees they usually don’t find out about until they are on your “slippery slope”.
Sadly, prospective buyers of hospital systems, manufacturing systems, to give just two examples, either do not have the evaluation capabilities or perhaps the time to select a system from a herd of 300+ offerings, all of which “… save time and money” according to the “Cheshire cat” smiling salesman.
How can you select a software solution that is capable of addressing your current needs as well as unanticipated future needs?
This brings us to “Your workflows or mine?” – if the system you are looking at has pre-configured notions of what your workflows “should” be, then you do not need to spend more time on that “solution”. If the vendor says the system can be “customized” to suit your needs, move on.
This thinning of the herd will give you a short list of systems that YOU can configure to suit YOUR current and changing needs.
And, the proof of the pudding is easy.
Call as many vendors as you can stand to listen to, tell them you want a GoToMeeting and at the start of the meeting tell the vendor to skip the corporate stuff and skip the canned demo. Tell the vendor YOU would like to build, compile and run a workflow of your choice and would they please hand over the mouse to you so you can proceed to take the lead in giving a demo of the system to your colleagues.
This request will typically be met with silence.
But, if you persist in your evaluation process you will find a product that you can use to build and maintain workflows that focus on YOUR needs.
Clearly, if you can accomplish the demo objective that you set, most of the rest of your colleagues will be able to use the system.
Questions or comments, please call the author at 800 529 5355.
KWKeirstead's Blog 
Karl Walter, I totally agree with you. I often request the same.
Two problems appear. The first one is, that the business believes they must have a special UI because they are ”different” ….
Second, IT says: we already have a BPM system installed and we can’t habe users doing their own processes. Can you migrate the processes from the existing system and can you restrict the users?
We are still along way from the adaptive, continuous learning enterprise …
Regards, Max
LikeLike
Hi, Max . .
Nice to get some feedback.
On restrictions, the Civerex ACM/BPM considers everything to be a task so far as “work” is concerned and since all tasks have a skill attribute, all tasks have restrictions by definition. Of course a specific task can have a skill attribute of “all”.
Tasks used along structured workflows typically have situation/context appropriate data collection and task specific instruction forms as a second attribute.
Tasks you see along such workflows are almost always duplicated out into standalone tasks to allow a user to re-visit a committed task or go to a task that is not yet current along a workflow instance. Calling any such tasks requires referencing a specific instance as there can be multiple workflows at a Case – things become indeterminate if an instance is not indicated.
In order to have compliance checking, certain standalone tasks are the only way to get something done (i.e. there will be only one “Ship deliverable” task across an enterprise) and that task will have a skill code of “shipping department”.
Accordingly, whereas a user who has something to ship can cause task “Ship deliverable” to post to someone’s InTray (i.e. a member of the shipping department), they cannot commit that task because they lack the role/rights.
For pure ad hoc tasks, the degenerate data collection form for these is nothing but a “form” that has one memo field. You can write what you like in it and of course all users have a role/right that lets them commit tasks like these. Another favorite would be an otherwise blank form with a “Done” checkbox.
Many tasks have auto-commit capabilities – on arrival, background checklists evaluate to Go/NoGo and either execute or wait for a cycle timer to cause a re-try. These gatekeeper tasks have a skill attribute of “system” (no individuals can ever access such tasks).
What I find amazing in ACM/BPM is you can have two people working side by side, one following whatever protocols are available, the other flat refusing to follow the protocols – if the ad hoc person is knowledgeable and knows corporate policy, the two arrive at very close to the same outcome.
The only way I have found to get to this state of affairs is to have background auto-checklists that sniff out what is going on and put in place hurdles (warnings or hard stop) if, as and when things get too far out of line.
The usual guidelines we give to end users following an implementation are “we now have “best practices”, use them if you like or do what you like, when you like”.
LikeLike
Karl Walter, I have been applying Lean Six Sigma to solve business process problems. Many of my clients have ERP systems with near real time data. An example ERP would be FabriTrak from MIE Solutions. One of my clients was a custom job shop that set up a router for each part number and FabriTrak supported that need fairly well. The staff setting up the routers were engineering technicians. I’m trying to reconcile this custom router approach with the Civerex ACM product.
LikeLike
Yes to your questions. What I’ve found for many years now, is that customer orders are a mix of ad hoc work plus process fragments. I’m having trouble thinking of a situation that wasn’t at least 10% ad hoc, and usually a lot more than that. I wonder why it took so long for me to recognize that?
LikeLike
Just re-visited some comments and wondering what a “router” is? – is it an address you can push out to get delivery of a part or is it perhaps an RFID facility that lets you know when a part has arrived at a job site?
I suspect the Civerex products are “ERP” products in that they take BPM workflows, compile these and then feed the carved up individual steps to worker Orders InTrays.
The backbone of the process orchestration is of course the logical connectors between tasks, accordingly tasks post as and when they become current.
Since workers can have a focus on multiple “instances” at a time, we use the model “template\instance\step\form” and the nice thing is you can do “pathway\instance\step\form” either going back to already committed steps, or forward to not yet current steps, or you can invent an ad hoc process of one step. The workers micro-schedule their daily work and supervisors level and balance across all workers/projects according to changing priorities.
IMO the key to managing a mix of ad hoc and structured work is to have certain steps that are the only means of getting something done (i.e. shipping a product only gets done by shipping). If your policy and procedure is such that the shipping dept does not ship unless/until they have a release from QA, it then becomes futile to try to skip QA.
In any case, governance takes place a key process points where the performer is “system”. the gives you 100% auditing at key process points. The system links to a checklist (filled in by software, not by people) and at the checklist a rule set reports TRUE/FALSE. True opens a gate, False keeps the gate closed.
So all in all, to me it does not matter which process mapping people use, the critical requirement is to have a compiler and the RT environment you are using has to of course be able to read the output of the compiler to carry out orchestration.
I get the impression people spend an inordinate amount of time building processes using BPMN.
Why they do this is beyond me, the compiler does not need BPMN, the end users do not, and process designers are perfectly capable at any time of compiling their in-progress process maps and seeing how they run.
Much better in my view than staring at paper process maps.
We do all of our process mapping in real time, in front of a small group of stakeholders. We all get instant gratification – any exercise undertaken can be “modeled’ the same day as a process is mapped.
LikeLike
This company uses the term router to refer to the piece of paper that travels with the product as it goes through the workflow process. It sounds like the Civerex products could take the place of or augment the router.
LikeLike
George, thank you for the explanation.
Interesting. . .
I don’t expect any BPMs could provide orchestration/governance without a “router”.
We have traditionally described our RT environment as providing “resource allocation, leveling and balancing” and this operates at three levels 1) system loading of user in-trays based on availability and ability to perform 2) users micro-scheduling tasks assigned to them and 3) supervisors leveling and balancing workload across users.
It’s not uncommon for a structured sequence of steps along a process instance to call and re-call a particular document, a good example being “insurance” forms that have different zones that must be filled out by different departments. In the absence of a structured workflow, a user can initiate processing of a document as an ad hoc intervention and simply “forward” the step to others as a series of ad hoc interventions until the document is complete and is committed. Where e-signatures are required, rule sets will disallow committing a step of the type described until it has the required number of signatures. Yet another way to put a “document” into circulation is to simply attach it to any step along a process – the document can then be referenced as needed downstream from the point of attachment along the process instance.
The main observation that we have made over time is that in any mixed environment (structured processes and ad hoc interventions), it is essential that some activities be set up as unique menu items (i.e. the only to ship anything Is via a “ship” menu item which immediately calls a background rule set that tests for prior passage of the object through, for instance, QA). This forces all objects to go through QA as there is no other way in the environment to get anything shipped.
Governance that has its source in background system-level rule sets goes a long way to accommodating one person following a best practice whilst a person sitting next to them insists on not following that best practice. So long as the two work approaches yield the same result, we don’t much care whether they follow/no not follow best practices.
LikeLike
Very informative blog! Thanks for share.
LikeLike