Figuring out what users are using and how they're using what they're using is a critical first principle for effective BPM. However, doing so is both straightforward and complex, and both obvious and subtle. This apparently self-contradictory state is possible because...well, because humans are involved.
When you run into a friend or acquaintance, greet one another, and exchange pleasantries, it's typically a brief, simple conversation. However, dozens if not hundreds of conscious and subconscious verbal and non-verbal internal and external communications support each such apparently simple exchange. (Simple examples include the ability of each participant to recognize one another, to determine and use the right verbiage for the exchange, and to understand multifaceted constructs such as “go to lunch” and/or “have a drink.”)
When someone decides to create a new report at work, sits down, opens a new document, and starts scouring the enterprise's intellectual property (IP) for source data, a similar situation ensues. Yet at many if not most enterprises, there is no documentation guiding that worker, nor any formal, proven, repeatable processes for that person to use as a starting point. Oftentimes, there isn't even an accurate, complete catalog of reports that have been generated previously. The result is much frustrating wheel-spinning and unnecessary, potentially conflict- and confusion-producing wheel reinvention.
However, it is unwise, if not impossible, to impose processes intended to capture every piece of information about every task performed by every user. Such processes, unless very cleverly crafted and implemented, will almost always come across and odious and intrusive, and evidence that the company has little to no trust and/or confidence in its workers. This situation typically leads to workers ignoring or “working around” such processes, and not being very happy with their jobs or bosses. Since retention is easier and cheaper than acquisition and assimilation, and higher worker productivity and satisfaction cheaper than the alternatives, the impetus to avoid such disgruntlement is great.
Instead, IT decision-makers must collaborate with line-of-business decision-makers and, where practical, directly with workers. The goal of such collaboration is to convince those constituents that greater knowledge about what they do and how they do it will help IT to help them better. Then, IT must demonstrate willingness and commitment to include input from users in decisions that affect those users, and to take that input seriously. A good start is to work with users and their leaders to determine how best to collect such input in the first place. Combinations of online and in-person interviews and surveys, both anonymous and personal, are all options worth considering. Final choices must be made based on the specific information needed and desired, and the preferences of the subjects. But all such discussions must begin with and be framed by processes that focus on the shared goals of greater IT efficiency and user productivity and satisfaction.
At many enterprises, a first useful step toward these goals is the formation of a team that includes IT and business decision-makers, as well as users or user representatives chosen by users. (IT sometimes attempts to select or provide these representatives. When this happens, the information they gather from users is almost always filtered and interpreted in ways that create mismatch between what users actually want and need and what IT delivers.)
If you've got ideas for processes that can help IT decision-makers gather useful information about real-life human workflows, or questions about such things, do let me know. Meanwhile, thoughts on relevant tools to come...