All right stop! Collaborate and listen (Sharing Points)

A good friend of mine has told me that this post is not English so I will re-write it.

Something that has been appearing more and more, unfortunately, is the rise of almost random and adhoc work processes. This is not the structured or traditional step A must be done then step B etc but more of an on demand or “if and when I feel like it” process.

There is no clear structure of either task or role based steps, they want to be able to allow anybody in the team at any stage the ability to review the data.

The tendency in these cases has been for the developers to say there is no workflow, it is one page that just allows the data to be viewed or modified then passed on to another person of the users choice, “we can easily do that in .NET without a workflow engine”.

I have decided in my infinite wisdom that this is not true, in this case it is impossible to predefine any flow of data. The flow of data is defined by the preceding user, and a workflow engine can allow for this.

The engine allows all the logging, auditing and task reallocation as per normal so the developers need not worry about designing these issues all they do is design the form with the facility to choose the next person and allow them to change any data.

The engines role is simple. There are two tasks, one review task and one end task. The review task can call itself or the  complete task. The circular action of the review task to allow the current task to be complete and and then re-start itself. This will enable the tracking of multiple random reviewers, who did the task and when.

The crappy picture above shows what it may look like.

This way you get all the auditing from the engine and still meeting the requirements of the users.

Im not saying I like this randomness, it is wrong but there is way to deploy a workable solution.

It has been sometime since my last post, but I have been busy getting several Captaris based workflows running in a large Australian Government Agency.

It has been largely helped by very proactive Project Managers. I would like to write up some things I stumbled over and things that worked, and didnt.

First point – requirements gathering

Gathering requirements for workflow is very very different to getting requirements for a normal system I have found. It is often tricky to get people to rationalize what they do when they receive a bit of information or document.

There are so many processes that go through peoples heads when they review some information, and all of that needs to be captured. What I did notice is, in the end a lot of it can be very simply broken down to small, concise steps.

I tried the approach of only giving people access to the data they required for them to action their task. I was (and so were the users) keen to eliminate information overload and unnecessary and potentially confusing clutter.

People seem to be reluctant to give away, and to, I dont want to use the word trivialize,(simplify perhaps) their work. But I found that this evaporated as they could see many current roadblocks and frustrations they have with the current process could be eliminated. There would be a greater sense of empowerment and freedom as they knew that certain steps must be done before them and all work that has been done is now audited so they have security and proof of what has happened.

Drawing lots of pictures really helped, after the meeting I developed what was discussed and went back to show and create a pictorial reference what was agreed upon (easy to do in Captaris). I think this was a good step as they could see the results of their inputs and see some good structure developed.

Once the structure and flow had been agreed on my next job was to focus on each individual task with the responsible person or group. This is where the real documentation kicked in. It was a matter of describing the UI and what was expected and where the data was sourced from.

A long process but it was worth it in the end. It allowed me to cover as many bases as possible, involve the users so they felt part of the process and the ‘magic’ of the technology is explained, which I think helps the users feel more comfortable in using the technology if they can at least understand some of it. Without the users willing and accepting of technology it will be hard to achieve successful outcomes. They are a massive component in a system and can not be overlooked.

Anyway I will post the rest of this story later.

Here is a trick with the Captaris Install for 5.2. 

It seems when the Captaris  SQL Installation is run the database is created ad DBO but the Stored Procedures are created under the user of the person who ran the install. So it might be worth changing this afterwards.

Thanks to Nyssa on this. Yet another good Volante worker.