I like to cook, and for the most part, I work from recipes. But to me, a recipe is usually a guideline. Some of my recipes are relatively new, while some of them are passed down from my grandparents—transcribed, of course. When it says a cup of this, a cup of that, teaspoon here, teaspoon there… OK, fine. However, do I really want to spend the time leveling off the cup of flour with the knife? I prefer to reach in the bag of flour, scoop it out, shake it, and dump. Recipes are not perfect and certainly not exact; so much of the creativity is in the look, feel, texture, and taste that I do have to cheat—rather adjust—a little as I go. But knowing when it is right comes with experience.
Often, a company’s documentation and data collection system can be like a recipe. Is yours easy to understand or do you have to be experienced to know where you can cheat a little bit? Is it old, out-dated, handwritten, or up-to-date? Does it even exist? Does the documentation reside in “Bob’s” head, and he gets called every time something goes south? Think about the new hire that has just started working for you. Can he call “mom” to see what a “pinch” really means, or does the documentation spell it out?
As with recipes, documentation is built upon the experiences of those who came before and can do things in their sleep. Granted, there is no substitute for experience in any situation, but keeping procedures well-documented—or even as guidelines—eliminates many of the questions on how things should go, what to do if something goes wrong, or how to create something that is of value. And if you can find a way to improve the procedure, all the better, but write it down!
My pizzelles aren’t as good as my mother’s, but they are close. I have her recipe. I had my own pizzelle iron, but it did not feel right— that experience thing. When she passed, I received her coveted pizzelle iron. My pizzelles are definitely closer, but they still aren’t the same. Then again, is anything as good as our mom’s? The point is, I did not have to start from scratch. It would have been blasphemous to look up the recipe online. The pizzelles are good and better than store purchased, but the bar was set way too high.
When it comes to your system documentation, do you know how things interact? Where does data get entered? What types of data get entered? What does the data affect and where does it go? Can you trace the flow of information through your system? Are people clear on what the entered, updated, and displayed data means? How about your reports? What do your reports look like? Do you know what each piece of information means?
Documentation should describe the “cradle-to-grave” action or flow of information of a system. There are usually separate documents for the users and one for systems. The user guides describe the functions, data entry, screens, reports, tasks, and how everything works together from a user’s perspective. System documents go into detail about the flow from data entry, the fields, files, and systems that are affected. In both cases, everything should be spelled out as well as possible to eliminate as many questions as possible. These should also be “living” documents because, as you know, things change rapidly.
It is a good thing that we wrote down the recipes from previous generations. It is always good to have that link with the past, and I would be totally lost without it. Make sure that your systems are documented. If you need help, L-Tron can assist you with the workflow design and documentation. Like my mother, we have been doing that for years. Give us a call, and let us give you a hand. In fact, if you’d like, I’ll even share some recipes with you, too, from classic Italian cookies to “modern” cookies. And, if your mom is still around, give her a big hug.
