 |  |  |
| Main | |
|
Workflow software should de-emphasize roles
Workflow software helps manage business processes such as budget decision cycles or procurements. The information and tasks are organized and tracked between users according to rules derived from the business goals.
optimizing workflow with computer technology involves identifying what the human and the computer each do best and assigning them tasks accordingly Major Dale Long, USAF
at that stage on a tight IT budget, trying to institute conventional workflow software would have added a rigidity to the system that would have stood in their way. Lessons from the Army Budget Office
One of the first things you consider when designing a workflow system is the roles of different people in the day to day business. You plan to support these different roles with different features, notifications, checklists, allocation and modification privileges, who approves what, that sort of thing.
The key challenge with role-based workflow systems is when roles are constantly in flux. Computer systems cannot follow and adjust to roles the way humans naturally do. When analyst responsibilities can change on an hour by hour basis as the whole team scurries to get something ready for a deadline, you don't want to spend time trying to get the system to let you do things it doesn't think you're supposed to do.
No trust
Let's talk about trust, and why most designs get it wrong the first time. When developers think of what the computer can control, they think of access, the username/password thing, and then they think about privileges, the authority thing. Maybe, just maybe, designers (primarily men?) like to establish a pecking order first as a way of architecting workflow software.
One example of a broken workflow concept is basing priviledges and approval stages on rank (e.g. military rank), the assumption being that the higher rank person would have more system priviledges.
But in the real world, higher ranking people generally touch computers less and you cannot wait for them to sit down at a computer and enter or approve something.
In most cases an administrator does a lot on behalf of many other people who don't have the time to upkeep data in the files, or database repository. This was always the case with secretaries and filing cabinets and the lowest ranking administrative assistant filing confidential materials, and it is the same now that computers are on every desk.
Even if you imagine a workforce where assistants no longer manage the details of workflow, it is a part of the business process that will take more than new software and a memo from the CEO to change.
The revolution
The photocopier brought copying and record keeping to a new level, and the computer raised it to yet another level with the ability to effortlessly store a copy of the state of something at every stage of its development. Rather than trying to make sure no one does anything wrong in a collaborative environment now we can let them do what they feel they need to do and just track what they do in case we need to go back and sort it out.
This is a concept that hit the bigtime with wikipedia. Realizing that getting permission beforehand is a great impediment to productivity, their idea is to let everyone contribute freely while keeping copies of every revision so that malicious or erroneous edits do not harm the good data. You can always get back to it. This concept is even more powerful in private collaborations where bad usages are rare.
But workflow software designers still hesitate to fully embrace this revolution. Take the case where an administrator does things on behalf of others. This person should be able to annotate or justify actions by logging a note such as "approved by so-and-so during 2:30 meeting." This is obviously necessary when the decision maker is not someone who will touch a computer.
Bad workflow design causes security failure
Workflow design that has rigid roles often leads to workarounds such as someone logging in as someone else just to perform a task. The person who is assigned the necessary role in the system might be sick and calling in to have someone else perform the task. Or if the necessary privileges have not been properly assigned, or somebody is in charge of ordering parts just for the day, to get the job done a person might be forced to call a co-worker and use their credentials. In terms of both security and tracking, this is a worst case scenario.
In many cases, to avoid causing a security failure the software should allow anyone with a login account in the office to perform the action. For sensitive or costly actions you can put an additional password on the action itself. The principle being that you can always look at the log to see who performed the action, but you must never ever have someone login as someone else to perform it.
People understand roles intuitively even in flux; computer software is very poor at this. Workflow design should always initially focus on the work and not the roles. To restrict actions, use passwords on the actions. Build a system that can provide business process automation conveniently and with great tracking and the users will reward you by adapting their roles to your software.
Trust
It is unavoidable that when people are brought to work together, they have to be trusted. There are many precedents for putting trust in professionals.
In Department of Defense classification policy the concept of "need to know" means that even if you have a secret clearance you do not look at anything classified unless you are confident of your "need to know."
"Need to know" incorporates trust (that someone will not pick up a classified folder when the other person turns his back) as well as elements of tracking (like sign-in, sign-out and surveillance cameras).
Similarly someone on the doctor's staff is allowed to look into someone's medical records only if they have a professional reason (i.e. authorization) to do so.
In both cases you are placing great trust in people, and that trust can be violated. If a violation is discovered there are consequences, but there is still a risk. It has been established that this risk is worth it because tightening down any more would be counter-productive. Computers cannot change this.
But computers do improve on this by doing an excellent job of preserving, tracking, reporting and notifying. When medical records are accessed via computer, a log is created which can be audited later to check for abuses. In other workflow situations, certain sensitive information can even be protected by the threat that ranking users will be notified, rather than by making it completely inaccessible.
Tracking
When someone is unexpectedly out of the office for a day, what happens to their workload? If a workflow application expects their approval in a chain of events, or only they have the authority to allocate a new resource, can someone else do it for them? If they call into the office would they need to tell someone else to login as them? If the system has a simple checkout paradigm that does not allow others to modify an item while it is checked out and someone leaves a crucial item checked out, what do you do?
Designers aften call these situations "exceptions to the rule." The problem is that these "exceptions" are left to be solved later while a non-versioned data store and rigid role architecture is developed. In the end you have an architecture that does not have the basic building blocks to solve the actual problem which is:
collaboration despite fluctuating roles.
All of these problems are solved when you design a system around flexible version control and extensive tracking, rather than locking and pre-assigned permissions. So rather than focusing on the username/password and authority things, there is an alternative. Focus on the version control and tracking thing.
In most workflow and document management systems, version control should allow for multiple versions, merging, comparing, and especially mock-ups where a user can aggregate and report based on an alternative version of data, generally referred to as a "what if" scenario.
Boss or tool?
We use titles for positions in the workplace in order to give a semblance of structure, and while it is true that a title does help give you some idea of what a person does, the closer you work with them the more you see how the boundaries of those positions vary. While roles are not the same as positions since they are more specific to the software, they have the same issues. I once saw a role classification system with thousands of roles; role maintenance can become an industry in and of itself.
We might dream that if we can capture the essence of the roles underlying the business practices, the computer can guide and help manage the processes like a benevolent boss. But the reality is closer to that notorious Microsoft Office paperclip. Roles are often a phantom you can never satisfactorily capture.
This is why successful workflow systems focus more on preserving versions and tracking what people do (i.e. who did it or approved it and when) rather than controlling what they do. Computers work better as a tool than as a boss.
| Main | |
|
