What is "documentation?"
To me, documentation is a CAUSE, an idea worth working for. Documentation is the beginning, the foundation, and the bedrock of worthy undertakings.
"Without a doubt my commitment to writing things down and having a system in place to remind me of my action items has been a major reason I've been able to achieve all that I have." -- Dr. Mercola, "Learn the Secrets of How To Get Things Done Quickly & Easily."
But recently someone asked me, "What do you mean by documentation?"
Maybe people don't think about "documentation" often, but nearly everyone uses it. Have you read or used any of the following lately?
Advertising, API documentation, banking records, brochures, bus schedules, business cards, cave art, computer files, Constitution and Bill of Rights, contracts, Declaration of Independence, diaries, divorce papers, email, graffiti, legal papers, licenses, manufacturing instructions, meeting agendas, mystery novels, newspapers, notes on the back of cocktail napkins, operations manuals, paper money, paper trails, pictographs, promissory notes, receipts, recipe books, Sanskrit writings, scripts for movies and plays, tax codes, technical manuals, threatening letters, etc.Today, in addition to printed documents, a lot of documentation takes the form of websites, data on disks, CDs, etc. But, in any format documentation must be organized and encoded in a language that someone (or a machine) can understand.
Is computer documentation similar to company documentation?
Let's see. A computer system is an organization of functional components that operate to produce predictable result(s).
Similarly, a company is an organization of functional components that operate to produce predictable result(s).
Yet, they seem different. Is their documentation similar? In the following few paragraphs, I will compare a certain type of technical computer documentation with business documentation.
Have you ever heard the term "API"? In computer jargon, "API" means Application Programming Interface. (I don't know when the term "API" became popular, but technical manuals for programmers have been around for decades.)
API documentation tells programmers how to use (interface with) pre-programmed Application Programs. The API document tells the programmer the precise language and message format expected by an Application Program. The Application Program itself can be any computer function such as an operating system, a database management system, a communications protocol, a formatting program, a math function, whatever.
To implement an API, the programmer must write a PRECISE function-call for the Application. If the call is not precise and accurate, the computer may deliver unexpected results, or an undecipherable error message, or maybe the "blue screen of death!"
Below is a piece of API documentation, showing code for how to set up request variables for an application called DISPATCH.
[...]Of course, the above instructions are written for a computer. I will spare you the rest of the API documentation that explains what all that means.
<*dispatch transport='test-email'*> <*map*> <*varpair name='body'*><*map*> <*varpair name='content'*>You have successfully received a test message.<*/varpair*> <*varpair name='characterencoding'*>Cp1252<*/varpair*> <*/map*><*/varpair*> <*varpair name='email'*><*map*> <*varpair name='address'*><*list*> <*param*>email@example.com<*/param*> <*param*>firstname.lastname@example.org <*/param*> <*/list*><*/varpair*>
Programmers may need to spend a lot of time trying to understand API documentation, especially if it's poorly written. API documentation must be readable by programmers. Still, it can be intimidating, especially for calls to display or print information. Operating systems like Windows may have thousands of APIs.
The point is this: Using APIs, programmers must write precise code to communicate with the operating system and other software.
NOTE: Many software developers are slow to write their Application Program Interface (API) documentation. That means the development team relies on "tribal knowledge" and rumors!
Analogous to the above...
In business jargon, "BPI" means Business Process Interface. Never heard of BPI? I just made it up!
BPI documentation tells employees exactly how to interface with (use) predetermined Business Processes. The BPI documentation tells employees what input a given Business Process expects.
A Business Process can be any company function such as buying office supplies, booking a sale, developing a brochure, manufacturing a widget, whatever.
To use a Business Process Interface (BPI), the employee must provide information to the Business Process. If the information is not precise and accurate, the employee may get unexpected results, or an unintelligible memo, or maybe a "pink slip of termination!"
Here are a few steps I wrote for a Business Process called "Quick-Turn:"
The main steps for having the Quick-Turn item(s) shipped are as follows, listed in sequence of activities:Of course, the above work instructions are written for human employees. Employees may need to spend a lot of time trying to understand BPI documentation, especially if it's poorly written.
Requester: Prepare the Quick-Turn Shipping Request Form and obtain approvals as follows:
___ Fill out a Quick-Turn Shipping Request Form (see QTSR Form and Quick-Turn Form Fields on Fields pages 17 and 18).NOTE: An incomplete QTSR delays the 2-hour turnaround.___ Obtain Manager's approval of the by signature.
Ship Direct, Do Not Consolidate.
For international shipments see INTERNATIONAL SHIPMENTS, page 21 and INTERNATIONAL CARRIER SELECTION, page 21.NOTE: Approval limits are the same as current signature delegation approval limits for department expenses. (See Signature Delegation, page 23 and Signature Delegation Limits, page 24.)___ Obtain Finance approval, if QTSR is for more $1,000.
___ Take approved QTSR to PVD Order Administration.
But, many companies have not written their Business Process Interface (BPI) documentation. That means the company relies on "tribal knowledge" and rumors!
1. API (Application Programming Interface) documentation tells a programmer how to interface with an application program.
2. And, BPI (Business Process Interface) documentation tells an employee how to interface with a business process.
The general process of writing either is the same, while the contents are quite different. Both take the ability to thoroughly research, organize, write and checkout the interface process.
"In every case, enterprises are trying to break down the walls between applications, lines of business, departments and individuals. They are looking to create more continuous business processes that transcend these artificial boundaries. This is of huge importance [...]Don’t let the lack of good documentation stunt the growth of your business! Click here to get help!
"[...] By some accounts you could call 2004 the year of business process, or at least a noble waypoint on a journey."
-- Line56 - The e-Business Executive Daily
Exercise for the Serious Organization Builder.
Download an updated (FREE) version of the Business Builder Outline (PDF file).
"Hi Mike ... thanks for your Business Builder outline ... good overview of what to plan for! I am about to launch my business ... and want to make it 'franchisable' ... a 'timely' download ... Thanks again, Ash"============================================================
HELP Profitable Venture Tactics help your colleagues.
This Blogrelies on subscriber's participation. So, it stands to reason, the more subscribers, the more participation. You can expand the circulation by telling your colleagues about Profitable Venture Tactics.
Your business and management colleagues will thank you for being so thoughtful.
What did you learn today that you found most beneficial?Please email your comments
How will you apply what you have learned at work?
Mike Hayden, Principal/Consultant
Your partner in streamlining business.
PS. If you're not on our P V T Roster, click here PVT sign up (FREE)
PPS. Click here to sign up for the PVT Forum (FREE).
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
(c) 2006 Mike Hayden, All rights reserved. You may use
material from the Profitable Venture Tactics eZine in
whole or in part, as long as you include complete
attribution, including live website links and email link.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *