Defining Processes in an Organization

The world used to be a lot simpler.  In the early Nineties, most organizations were caught up in Business Process Reengineering (BPR) and were focused on defining their major value chains and then reengineering them.  In most cases, once a process was reengineered — turned from a cow path into a superhighway — IT prepared new software to facilitate the new improved process.  That proved tedious and difficult, but luckily a variety of ERP vendors showed up and offered “off the shelf”  process modules that offered “best process” solutions.  In most cases the “best processes” weren't really all that good, but other aspects of ERP, including standard name structures and common databases, ease of interconnections, and software designed to survive the turn of the century (Remember Y2K) proved valuable enough to launch a major transition from home grown software to ERP.

Today, the largest “process” activity in many organizations is process documentation, in support of ISO 90xx, or as preparation for an ERP instillation.  Most of this “process documentation” work is done by body shops that grind out outlines that document processes according to templates.

Unfortunately, the world has moved on since 2000, and most companies aren't really that concerned with defining core processes.  They are more concerned with management processes that monitor, control and dynamically reorder other processes.  Or they are concerned with knowledge-based processes that were largely overlooked in BPR folks analyzed core processes in the 1990s.  Or they are focused on processes that describe how customers interact with your business and that alter frequently as customers as to have things tailored to fit their needs.

ERP vendors have made an effort to update their ERP “processes” of course, but their is a limit to what they can do, given the technology that they started with and largely still use.

My concern isn't with ERP vendors, however, but with the $100 an hour “process documentation” workers who are currently working away trying to document the processes at many large companies.  Most rely on software modeling tools that are over a decade old and unable to handle the kinds of dynamic processes that companies currently use.  Most have no good idea how to handle management processes.  Don't get me wrong, they can make a first cut at managing the control supply chain process or the monitor customer service process, but they are ill prepared to take the next step and model how the control process actually interacts with the process being controlled.  Most don't tie the processes they model to customer processes and are thus unable to model what happens when a customer changes how he or she interacts with your company.  Few can handle situations in which a worldwide team interacts via email and a website to redesign or tailor a product for a major client.

In essence, most companies are using decade-old modeling techniques to model modern processes that are changing rapidly.  Most companies are “capturing” these processes in an inadequate manner, and then plan on using other out-of-date software modules to “freeze” those processes in “best practices” that are two decades out of date.

The world is changing very fast, and Fortune 500 companies continue to disappear at a rapid rate.  Meantime many of them spend money documenting their practices in ways that reduce the changes they will survive the decade.  Meanwhile managers complain that they don't see the value of process work.  Companies that want to survive the decade will need to do a lot better than this.