Procedure manual for database data entry
January 4, 2008 8:27 AM Subscribe
I'm trying to create a procedure manual for our school's database software- only, I don't know where to begin!
Due to inconsistent data entry and to help future employees figure out how we do things, I'm trying to create a procedure manual on proper protocol for data entry. I'm not talking an instruction manual per se (I'm assuming people can read instruction manuals), but rather values we use in certain circumstances.
Thus, my goals are two-fold: 1) Have a usable reference guide for when people enter data. For instance, when they enter e-mail addresses in contact fields, what does "e-mail1" and "e-mail2" refer to in other instances? Really, I'm trying to create consistency where four difference secretaries use lightly different protocols of entering data. 2) I'm the only one who knows how to use a decent part of the database. If I get run over by a truck tomorrow, the guide should also allow someone new to come in and have this guide to say, "Ah hah, I see why these classes are set up this way and how you created the schedule with our school's necessary modifications. I also see that abbreviation 'sc' refers to 'science'."
If it makes any difference, this is database software for a school so it contains class, scheduling, parent, student, etc data. Basically, if there's school-related information, it's stored in this program.
I have no idea where or how to even start on something like this. I'm not looking for a solution for my position in particular- rather I'm assuming (hoping?) people have been in similar positions in the past and might have some pointers.
Thanks!
Due to inconsistent data entry and to help future employees figure out how we do things, I'm trying to create a procedure manual on proper protocol for data entry. I'm not talking an instruction manual per se (I'm assuming people can read instruction manuals), but rather values we use in certain circumstances.
Thus, my goals are two-fold: 1) Have a usable reference guide for when people enter data. For instance, when they enter e-mail addresses in contact fields, what does "e-mail1" and "e-mail2" refer to in other instances? Really, I'm trying to create consistency where four difference secretaries use lightly different protocols of entering data. 2) I'm the only one who knows how to use a decent part of the database. If I get run over by a truck tomorrow, the guide should also allow someone new to come in and have this guide to say, "Ah hah, I see why these classes are set up this way and how you created the schedule with our school's necessary modifications. I also see that abbreviation 'sc' refers to 'science'."
If it makes any difference, this is database software for a school so it contains class, scheduling, parent, student, etc data. Basically, if there's school-related information, it's stored in this program.
I have no idea where or how to even start on something like this. I'm not looking for a solution for my position in particular- rather I'm assuming (hoping?) people have been in similar positions in the past and might have some pointers.
Thanks!
I cant answer your question specifically (with regard to writing a procedural manual), However I have been in that exact same situation. 2003 to 2006 I was the IT person for a moderately sized K-12 school district --- and we had that very same problem (secretaries inputting student information in a very haphazard way)
The biggest things that helped us:
1.) Upgraded our database software to a newer version (we were using Chancery SMS) with a single, central database (instead of separate databases at each school - ugh!) which made central management of the database MUCH easier.
2.) We got all the secretaries together (prior to the software upgrade) and got them all to agree on the best way to do it. Examples being: a.) certain fields are REQUIRED. , b.) certain fields are ONLY drop-down boxes (basically trying to minimize "free form fields" because thats where the problems arise.)
3.) Making sure the database tracks WHO modified each individual record. (if you dont know who's doing it wrong, then you cant correct behaviors)
4.) Training. Training. Training. Over the course of the summer before we were due to launch the new version of Chancery SMS, we held many training sessions (especially during that two weeks right before school starts). The more familiar teachers and staff are with the program, and the more they understand WHY the district is doing it---the more comfortable they are and willing to put effort into doing it right.
I'm sorry I dont have more specific examples than the vague strategy above, but it worked out for our district. Sure, there were growing pains adapting to the new software, but one we got our stride, it was really nice to see it working correctly/smoothly.
posted by jmnugent at 8:59 AM on January 4, 2008
The biggest things that helped us:
1.) Upgraded our database software to a newer version (we were using Chancery SMS) with a single, central database (instead of separate databases at each school - ugh!) which made central management of the database MUCH easier.
2.) We got all the secretaries together (prior to the software upgrade) and got them all to agree on the best way to do it. Examples being: a.) certain fields are REQUIRED. , b.) certain fields are ONLY drop-down boxes (basically trying to minimize "free form fields" because thats where the problems arise.)
3.) Making sure the database tracks WHO modified each individual record. (if you dont know who's doing it wrong, then you cant correct behaviors)
4.) Training. Training. Training. Over the course of the summer before we were due to launch the new version of Chancery SMS, we held many training sessions (especially during that two weeks right before school starts). The more familiar teachers and staff are with the program, and the more they understand WHY the district is doing it---the more comfortable they are and willing to put effort into doing it right.
I'm sorry I dont have more specific examples than the vague strategy above, but it worked out for our district. Sure, there were growing pains adapting to the new software, but one we got our stride, it was really nice to see it working correctly/smoothly.
posted by jmnugent at 8:59 AM on January 4, 2008
We got all the secretaries together (prior to the software upgrade) and got them all to agree on the best way to do it.
I second this. Get everyone who will enter the data in a room to hash it out. The only way for this to work is if you get buy-in from everyone, and the best way to do that is to let everyone agree on something together.
posted by burnmp3s at 9:11 AM on January 4, 2008
I second this. Get everyone who will enter the data in a room to hash it out. The only way for this to work is if you get buy-in from everyone, and the best way to do that is to let everyone agree on something together.
posted by burnmp3s at 9:11 AM on January 4, 2008
If your database is provided by a particular company, reach out to the other users at other institutions and ask for copies of their data entry standards documents. Use them as samples to help you write yours. Frequently, users share this kind of document along with tips and tricks specific to the software you're using. Additionally, you may find the software provider encourages this type of discussion among the users.
posted by onhazier at 9:13 AM on January 4, 2008
posted by onhazier at 9:13 AM on January 4, 2008
Forgot to mention that for address data standards, please refer to the postal service standards. Encourage the school to use those standards because they're already defined and because you can save the school money on bulk mailings if you do bulk mailings.
posted by onhazier at 9:15 AM on January 4, 2008
posted by onhazier at 9:15 AM on January 4, 2008
Best answer: I am also a department of one, and write manuals like this for work, for precisely the same reason - the hit by a bus scenario. A few ideas:
1) Start by drafting your table of contents. It'll probably change as you write it, but that would give you a basic outline to start from.
2) If you're using Word, and you use Headers formats properly, the Table of Contents will auto-populate for you. This is essential so you can later just "update field" on the TOC, and it will re-populate and re-paginate the table for you. Test it out first on a pretend doc if you're not already familiar with it.
3) Also in Word, using Styles consistently will help with TOC and with overall cohesiveness and organization of your document. Check out View>Task Pane, then at the top of the Task Pane select from the drop-down "Styles and Formatting".
4) Can you get help from someone else to review it once or twice along the way? Since you work for a school, everyone's probably overworked perhaps someone else you know, outside the workplace, could do you (and your school district) a favor? They might like the idea of helping out a school. But be aware of confidentiality issues, of course.
5) Review similar manuals for a sense of how others have structured such documents.
6) Pay attention to formatting and use it consistently - for example, you might use one format (bold?) for every time you mention a field, and another (italics?) to designate data entered into a field.
7) You might start just by writing text describing just one part of the database. That will get you started.
8) If writing manuals is a challange for you, consider letting your boss know it's hard and asking him/her for help, guidance, a class, or/and advance forgiveness if this isn't as well done as the rest of your work.
9) Think about what is the hardest part for you - once you know what your mental block is, it may be easier to get started.
10) Make a list of how you'll attack the problem. For example, first step is to draft TOC, second step is to flush out each section with rough notes, third is to re-organize TOC, fourth is to convert your rough notes into coherent sections.
11) Sometimes it's easier for me if I start by working on paper. My brain works differently, plus transferring it to the computer later serves as a good editing/review step.
Good luck!
posted by quinoa at 9:19 AM on January 4, 2008 [2 favorites]
1) Start by drafting your table of contents. It'll probably change as you write it, but that would give you a basic outline to start from.
2) If you're using Word, and you use Headers formats properly, the Table of Contents will auto-populate for you. This is essential so you can later just "update field" on the TOC, and it will re-populate and re-paginate the table for you. Test it out first on a pretend doc if you're not already familiar with it.
3) Also in Word, using Styles consistently will help with TOC and with overall cohesiveness and organization of your document. Check out View>Task Pane, then at the top of the Task Pane select from the drop-down "Styles and Formatting".
4) Can you get help from someone else to review it once or twice along the way? Since you work for a school, everyone's probably overworked perhaps someone else you know, outside the workplace, could do you (and your school district) a favor? They might like the idea of helping out a school. But be aware of confidentiality issues, of course.
5) Review similar manuals for a sense of how others have structured such documents.
6) Pay attention to formatting and use it consistently - for example, you might use one format (bold?) for every time you mention a field, and another (italics?) to designate data entered into a field.
7) You might start just by writing text describing just one part of the database. That will get you started.
8) If writing manuals is a challange for you, consider letting your boss know it's hard and asking him/her for help, guidance, a class, or/and advance forgiveness if this isn't as well done as the rest of your work.
9) Think about what is the hardest part for you - once you know what your mental block is, it may be easier to get started.
10) Make a list of how you'll attack the problem. For example, first step is to draft TOC, second step is to flush out each section with rough notes, third is to re-organize TOC, fourth is to convert your rough notes into coherent sections.
11) Sometimes it's easier for me if I start by working on paper. My brain works differently, plus transferring it to the computer later serves as a good editing/review step.
Good luck!
posted by quinoa at 9:19 AM on January 4, 2008 [2 favorites]
Response by poster: We got all the secretaries together (prior to the software upgrade) and got them all to agree on the best way to do it.
This has been done, but it's hard to remember every little detail of what ought to be entered, hence why I want a written version. Maybe I could get everyone together, only this time write everything down at the meeting and create a guide from there. The other part is that I want this for prosperity sake, so people 10 years down the road can keep things consistent when we're gone.
Making sure the database tracks WHO modified each individual record.
The software only tracks the most recent updater. I wish all updates were tracked, but alas.
Thankfully, we have one centralized database where maintenance is relatively easy. The thought of having multiple databases with overlapping data makes me cry.
posted by jmd82 at 9:27 AM on January 4, 2008
This has been done, but it's hard to remember every little detail of what ought to be entered, hence why I want a written version. Maybe I could get everyone together, only this time write everything down at the meeting and create a guide from there. The other part is that I want this for prosperity sake, so people 10 years down the road can keep things consistent when we're gone.
Making sure the database tracks WHO modified each individual record.
The software only tracks the most recent updater. I wish all updates were tracked, but alas.
Thankfully, we have one centralized database where maintenance is relatively easy. The thought of having multiple databases with overlapping data makes me cry.
posted by jmd82 at 9:27 AM on January 4, 2008
It's sad that the database itself doesn't limit entries in relevant fields by drop-down menus and other idiot-proofing input controls. As you are painfully aware, when it comes to storing data, too much choice just leads to inconsistencies.
All of quinoa's advice is good. I would suggest organizing your manual according to typical work flows. So, if there are three screens used in a particular sequence to, say, enter a new student into the system, let that be a logical section. Ditto for "changing grades" or any other logical sequence of steps that accomplish a typical goal. To that end, shadowing your users can be a very effective means of determining the steps in a work flow (as users tend to omit things if you just ask them).
If you do get your group together again, consider doing an audio recording of the meeting, so you can easily capture all of the details you might miss while trying to get all the ideas down on paper. There are lots of pocked mp3 recorders on the market that are handy for this (e.g. Zoom H2, Edirol R-09 )
posted by wheat at 11:47 AM on January 4, 2008
All of quinoa's advice is good. I would suggest organizing your manual according to typical work flows. So, if there are three screens used in a particular sequence to, say, enter a new student into the system, let that be a logical section. Ditto for "changing grades" or any other logical sequence of steps that accomplish a typical goal. To that end, shadowing your users can be a very effective means of determining the steps in a work flow (as users tend to omit things if you just ask them).
If you do get your group together again, consider doing an audio recording of the meeting, so you can easily capture all of the details you might miss while trying to get all the ideas down on paper. There are lots of pocked mp3 recorders on the market that are handy for this (e.g. Zoom H2, Edirol R-09 )
posted by wheat at 11:47 AM on January 4, 2008
Response by poster: Thanks for the advice, quinoa. Time to freshen up on my Word skills.
I agree about the work flow idea, though I think there's still a need to have a section devoted solely to defining what certain fields in a given record mean. Will be a fun project regardless.
posted by jmd82 at 12:33 PM on January 4, 2008
I agree about the work flow idea, though I think there's still a need to have a section devoted solely to defining what certain fields in a given record mean. Will be a fun project regardless.
posted by jmd82 at 12:33 PM on January 4, 2008
Word 2007 supports some XML/XSLT stuff. If your database has anything useful there, you can open those files directly in Word, which might save you some typing and also give you a leg up with the organizing/structure of your document.
Some thought to Word formatting/fields will get you the TOC as already mentioned, but a good index too, which I would find very helpful if I was doing data entry. I might know the name of the field I'm looking at, but not where it falls in the workflow necessarily, so being able to look up that field by name would be useful.
And at my school, any kind of one-sheet list of quick tips, shortcuts or basic info that is sent around gets taped to someone's file cabinet or tacked to one's cubicle wall or bulletin board for quick reference, so consider some summary pages meant for this purpose. Maybe even get them laminated? Anything directly at hand will stand a better chance of actually being used, whereas a manual may get filed and then forgotten in the crunch. (Assuming that every data entry person will get a copy of the manual, which is how I understand the situation here.)
Last point - I'm not sure how it works everywhere, so it may be moot here, but sometimes parent volunteers do some data entry in the office at my daughter's school. If that is a consideration, you may need to really dumb down your manual. (Not that the parents would be dumb, but that they would be totally unfamiliar with school jargon or other things that secretaries or regular employees would know in the regular course of their work.)
posted by SuperSquirrel at 10:02 PM on January 4, 2008
Some thought to Word formatting/fields will get you the TOC as already mentioned, but a good index too, which I would find very helpful if I was doing data entry. I might know the name of the field I'm looking at, but not where it falls in the workflow necessarily, so being able to look up that field by name would be useful.
And at my school, any kind of one-sheet list of quick tips, shortcuts or basic info that is sent around gets taped to someone's file cabinet or tacked to one's cubicle wall or bulletin board for quick reference, so consider some summary pages meant for this purpose. Maybe even get them laminated? Anything directly at hand will stand a better chance of actually being used, whereas a manual may get filed and then forgotten in the crunch. (Assuming that every data entry person will get a copy of the manual, which is how I understand the situation here.)
Last point - I'm not sure how it works everywhere, so it may be moot here, but sometimes parent volunteers do some data entry in the office at my daughter's school. If that is a consideration, you may need to really dumb down your manual. (Not that the parents would be dumb, but that they would be totally unfamiliar with school jargon or other things that secretaries or regular employees would know in the regular course of their work.)
posted by SuperSquirrel at 10:02 PM on January 4, 2008
This thread is closed to new comments.
posted by davcoo at 8:58 AM on January 4, 2008