Today, I was discussing the data dictionary for a new system that I am designing. The person was a self made entrepreneur who had scaled her business and now wanted to put systems and processes in place. I had sent her a template to let us know what information she currently stores, so we can start work on the design.
Half an hour into the conversation, we spoke about why systems fail at SMBs and what we can do to ensure the same thing doesn't happen with her. She has run incredibly lean operations and did not want this systems initiative to generate a need to increase her workforce.
At this point, we shared what I believe are the 2 most important truths in data dictionary definition for any system. Before you add an element to your database, ask yourself these 2 questions, and you will NEVER drown in data.
1. Where are you going to use it?
"I need it just because" is not a good enough answer. Unless you, as the client, are able to pinpoint why that data is required, you should not put it there. Every element is additional maintenance and operational cost. If you don't know now, in your operations, where you use that data element, you don't really need it.
2. Who is going to maintain it?
If you don't know just now, wait until you do. A "Data Entry Operator" is not a good enough answer. Go right back to your business process and see at what point this element enters your business. Then check if you have someone to enter it into the system at that point or shortly thereafter. If you don't , this element will not give you the right information. Data, when not entered at source, will get corrupt. It's only a matter of time. If its crucial, find a way to enter it at source, and then add it to your database.
PS: If you have worked with me in the past, you already know both these rules. :)
Half an hour into the conversation, we spoke about why systems fail at SMBs and what we can do to ensure the same thing doesn't happen with her. She has run incredibly lean operations and did not want this systems initiative to generate a need to increase her workforce.
At this point, we shared what I believe are the 2 most important truths in data dictionary definition for any system. Before you add an element to your database, ask yourself these 2 questions, and you will NEVER drown in data.
1. Where are you going to use it?
"I need it just because" is not a good enough answer. Unless you, as the client, are able to pinpoint why that data is required, you should not put it there. Every element is additional maintenance and operational cost. If you don't know now, in your operations, where you use that data element, you don't really need it.
2. Who is going to maintain it?
If you don't know just now, wait until you do. A "Data Entry Operator" is not a good enough answer. Go right back to your business process and see at what point this element enters your business. Then check if you have someone to enter it into the system at that point or shortly thereafter. If you don't , this element will not give you the right information. Data, when not entered at source, will get corrupt. It's only a matter of time. If its crucial, find a way to enter it at source, and then add it to your database.
PS: If you have worked with me in the past, you already know both these rules. :)
No comments:
Post a Comment