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.