All Posts in Process Management and Improvement

|In: Organizational Effectiveness|Last Updated:

A concept repeatedly flogged in this space for more than 15 years is the difference between business processes and business practices.

Optimizing big, formal, core business processes is a form of engineering — it’s often called “re-engineering,” and ain’t it a shame process re-engineering so seldom involves actual engineers?

Optimizing business practices isn’t engineering. To optimize a business practice you have to improve the practitioners.

Most business processes require Big Software to manage them. But business practices don’t. Business practices are akin to crafts, and crafts depend on toolkits. The standard business practices toolkit consists of an office suite, remote collaboration tools, and maybe something specialized like a project management system. These toolkits are non-trivial, but orders-of-magnitude smaller in scope than what business processes require.

But unlike traditional crafts like cabinetry, baking, or jewelry-making, with business practices mastery of the tools of the trade is strangely optional. The impact of that optionality is, to be kind, significant.

Take the common situation of a team collaborating to write documentation. Typically, different team members write different sections, which someone — perhaps a technical writer — assembles into the final document.

That’s where the fun begins, assuming, that is, your version of fun consists of making lots of round pegs look like they belong in all of those square holes.

We’ll leave alone the challenge of multiple writing styles. While insisting everyone take a class in business writing would be helpful … I’ve spent more of my life than I’d care to admit re-writing colleagues’ passive voice into a form where it’s clear who’s going to do what … in the end there’s no substitute for an old-fashioned re-write to make sure the final document has stylistic consistency.

The importance of tools-mastery comes from something far more prosaic: Making the physically assembly faster and less error-prone.

To understand how it should work, let’s take a look at how it usually does work in a “modern” (which is to say, backward) workplace:

  • Jack’s a Unix jockey. He learned to format text writing in Vi and perfected his skills in Eudora. He uses the default font for just about everything, adds spaces to line up columns of numbers, hits <enter> twice to separate paragraphs, and uses a Perl script to convert his personal <number this> tag into actual numbered lists just before handing his section over to the team’s technical writer.
  • Jill likes formatting — she likes to say formatting is the written equivalent of body language. She handcrafts every title, subtitle, and heading. She particularly likes Comic Sans for headings and handwriting fonts to give words particular emphasis. Her bullets are adorable … hearts, hands, stars, each in a color that fits the mood of what she’s writing about, or perhaps her mood when writing it.
  • Jerome is a visual sort of guy. He’s a brilliant Visio jockey. And he’s even smart enough to paste his Visio diagrams into Word as bitmaps instead of OLE objects, knowing this will help him keep control of the diagrams. He’s mastered the art of adding a caption to his diagrams, and stylistically he reliably makes statements in his text along the lines of, “As Figure 3 illustrates …”
  • Jane thinks in terms of bullets. She’s terse and to the point, clicking the Bullets button in Word’s ribbon so often that if it was a physical button she’d have long ago rubbed away the ink of the image that labels it.

What’s wrong with all this is that these habits can add literally days to the job of document assembly. Double-enter paragraph spacing ends up with no space in front of some paragraphs and extra spaces after others after the editor has moved a few paragraphs around. Manually numbered lists end up as mis-numbered lists after the first edit.

“As Figure 3 illustrates” points to the wrong figure when the assembled figure captions in different sections automatically renumber. Or, worse, it points to several figures, because other authors manually number their captions, so the assembled document has several Figure 3s.

Add to all this the nightmare of having to manually construct and periodically revise a table of contents when few headings in the document make use of Heading styles.

And on, and on, and on.

Documents have an architecture just as surely as databases do, and teams of practitioners who violate these rules wreak every bit as much havoc as those who violate Codd and Date’s 13 principles of relational design.

The moral of this tale of woe? To optimize your business practices, insist your practitioners learn the tools of their trade.

Because while learning them isn’t the same thing as mastering the craft, failing to learn them is the same as failing to master it.

Comments

|In: Industry Commentary|Last Updated:

Just because something looks stupid, that doesn’t mean it is stupid.

Take, for example, the process you go through when buying or selling a house. There’s sheet after sheet of paper you have to sign, every one of which has exactly the same information: Yes, all parties want to go through with the transaction.

This being the 21st century and all, shouldn’t there be an easier way?

Yes, and in fact it’s quite easy to envision a much, much easier way:

1. Review all of the documents, or, rather, review the content that’s contained in all of the documents.

2. Sign once using an electronic signature pad.

3. Store all of the results in a central database.

Nothing to it.

Nothing to it, that is, other than persuading an entire industry to adopt the system in question.

Did I say “entire industry”? Were it only that simple. The task is to persuade all of the companies in several different industries — realtors, mortgage underwriters, mortgage servicers, title insurers, every registrar of deeds, and HUD, to name a few.

And it isn’t just a system. They’ll all have to adopt standard information formats, and to modify their processing systems to accept them.

All of which starts with an industry standards committee.

If you think this is easy, you’ve never been involved in an industry standards committee.

Just because something looks stupid, that doesn’t mean the people trapped in the system are stupid. More often than not, the stupid system is the best system possible given the constraints everyone is operating under.

Which leads to one of Lewis’s Laws of Business: Stupidity is more stable than effectiveness.

Look at most stupid systems and you’ll see similarities to the closing process:

  • Blinders: Nobody who works in the system or manages part of it has much influence beyond their narrow purview.
  • Self-interest: Mastering the stupidity provides job security to those who have mastered it.
  • Lack of incentive: No matter how stupid the system is, there’s little obvious business benefit to be had from improving it.

The usual view of these things — in particular among practitioners of Lean and Six Sigma — centers on the importance of dealing with the end-to-end process, along with making sure someone has responsibility for it. Both are lovely sentiments, and there are business situations where it’s possible to achieve both of these preconditions.

In particular, there are business executives who recognize how poisonous persistent organizational siloes are to their competitive success. It’s these executives who are most likely to assign the label “core” to one or a handful or business processes, and to assign an owner to each one, usually on the theory that this gives them “one throat to choke.”

To be fair to all parties, they usually do manage to improve the functioning of their core processes. That’s because improving processes that are truly at the core of the business has a strong and clear connection to increased revenue, decreased operating costs, or better management of important risks to the business. The financial incentive is clear.

It’s also because more often than not the business is already organized around its core processes. Each one constitutes a functional area of responsibility — think sales, manufacturing, and distribution and you’ll understand the point. So the blinders issue isn’t in play, either.

But processes that are real-estate-closing stupid are rarely at the core of the business. They’re processes that have been cobbled together by less-influential managers and staff, with no tools beyond Excel to help with automation and with silo owners doing their best to maintain the blinders that might, if removed, allow the sort of collaboration that would result in a cleaner way of doing things.

The three root causes of real-estate-closing-level stupidity are why the still-popular practice of organizing a business as a marketplace … with shared services providers charging delivery functions and each other for their products and services … is a near-guaranteed cause of long-term competitive decline.

The practice is popular because of a deep-seated misunderstanding of the nature of marketplaces of all kinds. They’re widely thought of as a way to create “efficiency.”

And they are excellent ways to create efficiency, except that the efficiency in question is the balancing of supply, demand, and price.

There’s nothing at all in economic theory to suggest markets self-organize into efficient cross-business processes. Businesses maximize their own profitability. They won’t sacrifice it should that be required to make overall delivery more efficient.

And even if there was such a theory, all theories are subordinate to the “ugly little fact.”

In this case, the ugly little fact is ugly indeed. It’s called “buying a house.”

* * *

Want to buy a townhouse in scenic Eden Prairie, Minnesota?

Comments