For whatever reason when revenue is up venues have the tendency to not sweat the small stuff. I guess it's because the small stuff doesn't amount to much when focusing on the big investments. But when revenue is down it's time to look closely at where your staff is spending their valuable time.
The next two posts will be dedicated to the "small stuff". Each has a minimal time and dollar investment with a quick ROI.
automated product/item depletion
Manually entering inventory depletion should only be necessary if you don't have a PC based POS solution (and even then it may not be required). If you do have a PC based POS solution (and who doesn't at this point) then now is the time to link the two system.
A basic overview of this interface is the POS system exports a text file (formats can vary) of product/item depletion. This file is then used by the inventory management system to decrement inventory amounts. A key prerequisite is a "Common Numeric Identifier" for each product/item that is shared; this is generally the SKU number. Chances are good the vendors you use already have a functional interface, and it's highly possible getting it turned on won't cost you anything (except maybe vendor support fees). If your vendors do not have an established interface you have a few options
option one
The first option is to work with one of your vendors to write a utility that meets the specifications of the other vendor. For example, your POS vendor writes an export utility that produces a file matching the import specifications of your inventory control vendor. Or, the inventory control vendor writes an import utility that uses the file format provided by the POS system. Most vendors have vast experience with this option, as it is the most common and generally preferred solution But, the price of this method can vary drastically among vendors.
Pros: vendor supported interface, highly scalable for large volumes of data
Cons: vendor may charge high price for development, any future changes to the interface require vendor time line
option two
The second option is to use a middle-ware utility to convert the standard POS export format to the standard import format for the Inventory Control system. There is a multitude of middle-ware applications available allowing someone with development experience to accomplish this. They range from free-ware applications to highly scalable solutions like Microsoft Biztalk. Be careful however as the price of this option can unexpectedly creep as interface iterations spiral out of control. The advantage is the opportunity to use the middle-ware application for other integration projects. The important point here is data mapping. Incorrect data mapping will lead to incorrect inventory depletion.
Pros: scalable for large volumes of data, use middle-ware software for additional interface engines
Cons: requires development experience, possible high cost of software and development
option three
The third option is to build a conversion utility with scripts, macros, and/or batch files. This process generally involves utilizing MS Excel and Visual Basic for Applications (VBA). I would only recommend this option when working with small volumes of data (no more than few hundred lines of data per executed export file) and when manual validation of the process regularly can be performed. Most IT resources (especially if they are a recent graduate with an computer related degree) have the experience necessary to build these utilities. The important piece here again is data mapping. Incorrect data mapping will lead to problematic inventory depletion errors and generally non-descriptive and unhelpful error messages produced by Microsoft.
Pros: internally owned, can quickly be implemented, low cost investment
Cons: internally owned (yes it can be both), not scalable for large volume of data, high chance of failure
reviewing your ROITo calculate your ROI estimate how much time is spent reviewing sales and product mix reports and how much time is spent entering depletion into the inventory system. For convenience use monthly estimates. Next, calculate the
Estimated Monthly Task Cost of this process using the hourly rate of employee(s) performing the task.
Estimated Monthly Task Cost = (time reviewing reports X hourly rate) + (data entry time X hourly rate)
Based on which of the three options you choose to implement calculate the
Total Project Cost. If your vendor charges a recurring support fee for the interface in Option One, don't forget to include that in the
Total Project Cost. Also, if you choose Option Two and pay for a recurring support fee for a middle-ware application don't forget to include that in the
Total Project Cost. (If you plan on using it for additional projects you may want to only include a fraction of the support fees.)
ROI = Estimated Monthly Task Cost / Total Project Cost
This is how long in months it will take you to recoup the
Total Project Cost, allowing your employee(s) to focus on other revenue generating activities. You may even find your ROI is less than one month!
If you don't have the experience or time to implement this interface give me a ring, I'd be happy to help! ;-) But don't forget to include the cost of the consultant in your
Total Project Cost.
If you are wondering about an integration capability post a comment and I'll cover the details in a future post. Even if you think it is probably not possible, it may be. I've seen a parking garage gate interfaced to the POS cash drawer...so almost anything is possible.
I'm not sure if I can say it's a "goal" to be in the HFTP Hall of Fame but it would be an honor to be recognized among the names in this group.
Posts
