Let me clarify for those who aren’t familiar with object-oriented programming principles that “encapsulating” in the title of this blog is a software term, not a suggestion to put your workers into “boxes.” A somewhat obtuse description can be found in its Wikipedia article. A more friendly, illustrated writeup may be found here.
The fragility of a company’s workflow can be easily determined by asking yourself, with each employee in turn, “What if he quit tomorrow?” Envision what kind of chaos would ensue. Think about the knowledge-base that would go with him. What aspects of the workflow and business are known by that person alone? What documentation would teach the next person how to do that job?
An important consideration in evaluating a business’ workflow is in understanding that the creation of information is up to the humans, the storage and manipulation is up to the computers. Understanding how to manipulate the knowledge as it processes through a workflow should not be locked away in anyone’s brain. This is where natural, easy-to-understand software to capture that knowledge comes into play. It is critically important that we separate those tasks that are easy for humans but hard for computers from those things that are easy for computers but hard for humans. I want to be clear here that I’m really talking about internal, custom-built software that facilitates business workflow. Processes that require “the worker must be proficient at Photoshop” is simply identifying a skill that has become commonplace in many industries.
Much like good software design, good workflow design should follow a general principle of separating data from its interface. In the case of bad software injected into a workflow, the interface (i.e. – how to use the software) has become inextricably entwined into the data (i.e. – the knowledge the worker brings to the process). The shakier the software, the more these things are tangled and the more critically important that particular person becomes to the workflow. We all like to think of ourselves as being important, and we are, but things happen. Life happens. Change happens. This kind of scenario is completely inflexible to unexpected life events, and necessarily leads to fragility.
Suppose some obtuse, incomprehensible, held-together-by-duct-tape piece of custom software has become a critical point of failure in a workflow. “Mary uses that software every day, and she knows all of its quirks. Our workflow, while not ideal, continues to chug along,” tends to be the attitude of many businesses. The key consideration here is that the logic behind the attitude of, “If it ain’t broke, don’t fix it.” has a major fallacy. It is broken, but Mary is holding it together like the little boy sticking his finger in the dike and we only have the illusion of being “not broken.” Yes, we’re not leaking water but what happens when a tiger eats that little boy (stranger things have happened)?
Consider also how difficult it is to document what Mary does for the business. I seriously doubt that any company has documented all of the little tweaks and quirks and non-obvious uses of internally built software that Mary has discovered. We can describe the intent of her job, but we cannot ever fully know the minutiae she performs hourly. In other words, we know from her job description what data Mary holds, and if the workflow has any semblance of structure (that’s a big if) we know her public interface, but we don’t know her private interface. The problem here is that the company has forced the data and private interface to become one.
From an object-oriented point of view, we don’t want to know her private interface whatsoever. As Mary is using company-developed software, the company has injected process into the data at a very low level, then abandoned that for Mary to work out. This is exactly the opposite of what we want for a modular, contingency-based workflow. So, what are we to do? How can we separate these concepts such that if Mary wins the lottery and quits tomorrow, someone of equal skill level can step in and take over Mary’s position immediately?
In this case, our worker needs to be able to discover her private interface. A well written piece of software will make it very clear to the new worker which pieces of data are important, how to retrieve that data, and what the software will provide in return. The software should be portable (i.e. – not dependent on a particular computer system, if possible) with a clear interface that makes sense to someone with a particular set of knowledge or skills.
This also means steering away from cutesy or dated names for files, folders, software, or hardware. Don’t call the FileMaker database “General Tracker” or something equally vague, making it a kind of “god class” managing all things FileMaker. Don’t name the printers after the Dharma Initiative stations. At Macy’s West we had printers named after Alvin, Simon and Theodore and after 7 years I still couldn’t remember which printer was in which room. I understand the desire to “personalize” the organization and make things fun and less “corporate.” There are plenty of other ways this can be achieved, with the software icon, desktop wallpaper, the writing style in training manuals, and the general corporate culture. Giving things names that make sense to the workflow is not a suppression of creativity. Rather, it frees the worker from having to constantly remember details that should be self-documenting. “That printer is in room 4-012 because the printer name starts with 4-012,” makes much more efficient use of a valuable worker’s mental energies.
Now we can feel free to hire a sharp employee who possesses the data creation tools (i.e. – the intuition and creativity) we need and provide a piece of software that allows her to slot in, like a Lego block, into the organization. Well-written software helps her encapsulate her knowledge, protecting the organization’s business continuity during change and protecting the new worker from stumbling on the job, despite her excellence at her skills.
Now, let us think about this from the gestalt perspective. Does your company encapsulate your workers at all? Can you define the public interface for any given worker? Can you draw a map that shows, without knowing HOW the work is done or using individual person’s names, what your company does? Going back to the question I posed at the beginning of this blog, think about each employee and consider, “What if she quit tomorrow?”
The implication of this approach, of course, is that the entire workflow must be analyzed and encapsulated. Tools must be developed that allow the business to continue working despite the most dramatic turnover of personnel. Some of those tools will be part of the public interface for the worker (i.e. – all incoming JPG files should be checked in using the company-built software called Deliver_To_Art_Department) and some for her private interface (a drag-and-drop script on her desktop called WidgetCorp_Intranet_JPG_Converter). In fact, sometimes it may be as simple as just renaming an existing application.
As is all-too-often the case, I can hear the cries now, “But we don’t have the time. We’re TOO BUSY. When can we stop what we’re doing to reimplement our entire workflow?” There is no easy answer to this, but the first thing to consider is that you don’t have to do it all in one fell swoop. It is not an all-or-nothing proposition. It is a process that can be evaluated, considered, planned, constructed, tested, and implemented in phases.
What we can immediately understand is what the end result of NOT doing it can be. Continual process improvement is a mantra that has been shouted from the rooftops for many years now, but I can honestly say I don’t think many are listening to the message. It is easy to say and hard to do, but a good development team and a good business analyst can find ways to bring about change in an organic way that minimizes the short-term impact on business continuity while greatly increasing the longevity of the business. It is easy to think that such a thing is impossible until you’ve talked to experts in this realm.
Once implemented, the organization’s structure will be such that the entire process will not need to be re-engineered ever again. Once the business modules are defined and implemented, those modules can be reworked, reprocessed, restructured to our heart’s content without affecting the workflow chain as a whole. There is an implication here that a module may even be identified as redundant and removed entirely. As there is a human being inside that module, this is something to consider; however, there is also a supremely good chance that that employee is doing work that does not leverage her skills and may be able to contribute more meaningfully in other workflow bottleneck areas.