[c22]

My first job was doing restock for a small independent retailer. The only report we could print showing inventory was inclusive of all the items we had ever carried, regardless of current status. The software was very limited and there was not much in the way of filtering. The best you could do was break the report up into ranges by vendor.

So my job was to go through the alphabet printing reports (e.g. "every item from a vendor that starts with 'A'"). I'd take this report, which for some letters was over a hundred pages long (about 20 items per page) then, using a highlighter and a ballpoint pen I'd go through the report highlighting the items that had stock available in the "backstock" column and had stock in the "sales floor" column that was lesser than the "restock level". I also had to compute the restock amount by subtracting the items on the floor from the restock level and taking the max of that number or the available backstock. I'd write this number in the margin of the report, then I'd travel to the backstock area, pick the highlighted items, and restock them onto the sales floor. After this was done I'd move on to the next letter. The goal was to cycle through the alphabet at least once a week and during the off-peak season this worked fine, but during the busy season, even with extra help, this system was showing signs of stress.

The first thing I did was to write a small perl script which I placed at the path the POS software was expecting to find a line printer. My script took the print-formatted report as input and simply stripped out the lines with no available backstock before forwarding the remaining lines to the printer. This alone reduced the number of pages printed out by an order of magnitude in most cases (from ~100 pages to ~10). At first I would copy this script to the printer path, run the report, then re-link the printer, but later I modified the script to recognize that specific report and pass-through other print jobs unmolested.

Over the next three years or so I added onto the script a lot. First I made it compute the restock amount for me, then I had it start skipping lines where the restock was trivial (e.g. restock amount was 1 and there were still >10 on the floor). Eventually the script was maintaining its own parallel inventory database, tracking rate of sale for each item and only suggesting restock for things that had very low inventory on the floor or were selling very quickly. I got to the point where I could restock the entire alphabet every morning and have time leftover in the afternoons to help with receiving. By the time I left I had a dedicated terminal set up in the back during the busy season that ran my scripts every 10 minutes and displayed in near real-time items that required critical restock throughout the day.

I heard a few years after I left they had switched back to the old methodology because they couldn't get their POS vendor to support my setup.

[kwijibob]

Fascinating that they switched to a worse manual methodology.

I wonder if there is a big difference between: a) an automation system that only the coder understands b) an automation system that is transparent and accessible to managers

Many coders get to point (a) but the system can't actually be trusted or relied on if the original coder moves on.

[c22]

I think they (management) viewed the job as a mostly grunt brute-force sort of problem. By automating parts of it I managed to save myself some time and hassle, but it's not like they told me to start taking half the day off or tried to leverage my talents elsewhere. Other than saving a lot of paper my system didn't really impact their bottom line in a way they could easily see. Even though I trained my successor on using my system neither they nor anyone else in the company was interested enough in computers to take on the ongoing maintenance of the system, despite being just a few hundred lines of perl that an amateur programmer could probably figure out (I was definitely an amateur programmer when I wrote it). When it came time to upgrade their POS software and the vendor refused to copy and reinstall my scripts they had no choice but to return to the vendor-approved process because they had no one technical who could own the system.

At the time I thought they were fools for abandoning such an improved process, but older-me sees the difficulty of the position I left them in. From their perspective they get roughly the same result from having some other cog do the grunt work and hiring a real-deal computer specialist at $$$/hour to be on call to fix problems has the potential to cost much more.

They may have been foolish after all, they ended up going out of business. I think their biggest mistake was allowing their POS vendor to basically lock them in (by being unable to export any of their data in any convenient way) and not demanding/being willing to pay for the sorts of changes I was hacking together to just be incorporated into the official system.