page contents

I have decades of experience in computer systems and get surprised when client companies I work with do not understand fundamental data processing basics.  Worse yet, is when software solutions they employ are designed to accommodate this lack of understanding and knowledge.

 

If a client company requires to build a database consisting of item, customer, and supplier masters, what could be easier than assigning to each master file an identifier together with descriptive information?  For supplier we might have corresponding information consisting of; company name, address, telephone and fax number, email address, contact person, and payment terms, etc.

 

I recently experienced the way that one software solution managed the situation where the user entered supplier name.  The user would create, over time, multiple entries for the same supplier as a result of the name having different spellings.  In one situation it may appear as ACE MANUFACTURING, LTD, in another Ace Manufacturing, Ltd, and in a third Ace ltd.  You may well ask why the user would do this.  Sometimes the user forgot that they had already entered the information and did not bother to see if the supplier was already in the system, so entered it a second, or third time.  The software was flexible enough to allocate unique internal identifiers, not visible to the user.  In this case it may have been 12345, 23456, and 34567 respectively.  Three different entries for the same supplier.

 

One of the requirements in our Planvisage solution is to establish a data link relationship between a purchased item and supplier.  What if we have the same item with multiple identifiers, attempting to link to a unique supplier also with multiple identifiers?  You may think that this is no big deal as long as a link is established and who cares about the relationship if ultimately the item is purchased.  But it is not so simple.

 

Suppliers often offer additional discounts if the consolidated orders meet minimum weight, or cube requirements for shipping purposes, or minimum total purchase costs.  It may financially benefit the company to buy ahead to meet these targets.  With disparate codes this becomes a mission impossible.  Is there a solution?  Yes, but it gets messy.  The client company can create a cross reference table where the different items are linked to one, and similarly with suppliers and customers.  In effect creating a Bill of Material to reflect these relationships.  Then too would be the need to establish the relationship between items and supplier using this new identifier.  In my particular situation the company was a make-to-order (MTO) company, so items were uniquely linked to customer.

 

As you will appreciate, the multiple items to a unique item is a “many to one” relationship.  In attempting to “go backwards” from the unique item to its supporting items becomes an impossible challenge when you appreciate the process we need go through.  Often when consolidating purchases by supplier to achieve a weight, cube, or price minimum metric, the user needs to apportion this back to the several items making up the total.  This becomes a mission impossible or a very onerous task.  How should this proration allocation take place?  You never want to ask the user to apply these adjustments manually, especially when there are thousands of items and hundreds of suppliers in the database.

 

Planvisage is a value added solution to ERP (Enterprise Resources Planning) systems.  Planvisage plans in detail at a granular level through its planning and scheduling algorithms.  Under normal circumstances when taking a feed from a well-structured and professionally developed ERP system, Planvisage returns the results back to the ERP system for buyers to release purchase orders, logistics to release in-transit orders between the distribution centers, and for manufacturing companies to release work orders to the shop floor.

 

In working with a more challenged enterprise solution as described earlier, the opportunity to close the feedback loop is impossible.  After consolidating data, and where applicable to reschedule orders, we lose the relationship to the original multiple entries.  The buyers and planners are consequently required to process the purchase, distribution, and manufacturing work orders from Planvisage printouts.  This is an onerous and unnecessary task, but under the circumstances, the only viable option.  After processing orders in the enterprise system, updated information is fed back to Planvisage.

 

The challenges did not end here.  Under normal data processing methodologies, we look for a unique record in the enterprise system that we can use as a “primary key”.  As stated, what we were working with is not a unique key, and in the situation I was confronted with, we were required to work with descriptive fields.  To make matters worse these descriptive fields often contained special characters.  So we find Ace> Mfg* Ltd!.  Data fields with special characters cannot be assigned to a Primary Key.  Again, data processing 101.  Further, in studying the database layout of this particular system, the suppliers included purchases from raw material and packaging companies, which was great news, but also contained payments made to employees, the local newspaper, school board and other community services.  That might have been acceptable, but there was no “key” provided within the solution to determine the type of supplier.  From a user perspective it was not an issue, because when they wanted to identify a supplier they looked at the alphabetic supplier list.  The user then selected the appropriate record and could instinctively determine which one to select.  Not an intuitive option from a programming viewpoint.

 

So what is my point with this experience?  What on the surface should have been a rapid implementation turned out to be an unnecessarily, lengthy, and expensive project nightmare.  My disappointment is that a software company would develop a system that did not require very basic computer principles to be followed.  Then too, make users aware of the basic principles with a stern warning of the operational and data processing cost if these practices are not followed.  One genuine concern here for management, and business owners is to appreciate that some of these inexpensive computer systems to help run your business while you are still small, may be burdensome as you grow and you require more sophisticated planning tools to remain competitive and profitable.

 

As a general rule, when working with client companies, even those using sophisticated enterprise systems, if toxic data is a way of life, the effort to clean up data is enormous, and causes long delays as you migrate to more sophisticated planning and scheduling solutions that Planvisage provides.

 

While on the subject of small business, I needed to see a medical specialist.  I was required to log on their website and fill in my personal details and medical history.  At the end of the exercise I was presented with a page verifying all the detailed entered.  I found that I had an important typo that I wished to correct.  Nowhere did the system allow me to make a correction.  I called the receptionist who said no one in the office had a clue how to make this correction.  Who architects and develops this stuff?  Don’t they test anything?

Comments are closed.