simplicity

simplicity

making inventory systems look so simple on the front.

if we go by the practical route, the issue would be going around “receiving” and “issuance” (in and out). plus some additional feature for “damage”, “returns”, “over-deliveries” and “retired” quantities of such, mix it all up and voila! you have your outstanding balance.

but practicality sometimes is foreign to some people that you get to meet. you can talk lengthily about simplicity and systematic considerations and then, “intelligent” resistance can frame you up for a battle of the wits.

a good topic is the item’s unit of measure… its complexity can go as far as defining an item’s measure in all types of “quantifiable units” whereby, an item can be tallied in meter or a foot or per case or per can.

in programming, the fabrication of conversion tables will not require so much effort… that you have one may however suggest the use of it, and therefore the awareness of users on its applicability.

minding an inventory item in all sort of “measurements” can require you to have more responsible users… imagine your user forgetting to convert a roll of item into its equivalent measure in meters that was designed to be measured in foot, or having issued 12 boxes of a cola drink instead of a half case or a dozen bottles… and you have all sorts of mess flying around your inventory positions.

this is by no means a poke on the concepts of “other users” that i do meet up with… but if we have to talk about the sustainability of the usefulness of our desired design for our software, the prevailing factor would always be “simplicity” in its operation. Outside its border is some misconstrued “analytical intelligent behaviour” and moving far out to the extreme is an ”inspired attempt to complexity of a dreamer”.

there is no doubt that anything can be done to address any issues in any systems development… but getting it to work is a question of “ease, sustainability and practicality”. it is best that in any design, you may have to consider that your software works to be suitable for a user of any considerable level of intelligence… modules that is nice to be back into everyday and applicable just as best to what is realistically being done and with not an “extra-step” to accomplish.

if you ever come up with such design, “behind the scene” functions of your software can then work to realize the desired data interactions.

on a perspective, the topic of “unit of measure” is just one of the contentions in an “inventory handling system” but you will have to measure up with your users as to how you can push your idea… because in the end, when you can’t implement your software, it could be that… you failed to simplify.