Posted by: SJC
Business Application Value, Business process automation, Small Business Computing, Software application development
When an independent application software developer first meets with a prospective new client it becomes very much a meeting where each party is evaluating the other. For the developer it becomes questions of “Is this an organization I can work with? Can I provide what they are looking for? Can they pay me? Do I want to do the proposed work for this organization?”. For the prospective client the questions become “Can I get what I want from this developer? Is the talent there to provide the service? Can I afford the service? Can I work with this developer? Do I want to work with this developer?” All good questions - left generally unspoken.
In speaking with a fellow developer today I was reminded of this by a story he told of one such interview where he decided that he was NOT interested in doing work for the prospective organization — and the reason? Basically it came down to the prospect being firmly entrenched in a business practice that was just plain poor. The application in question was an inventory application – the problem to be solved was to have a system that kept inventory straight. The “real” issue, quickly identified for the prospect was their practice of transferring inventory from store to store. They used hand-written packing lists for the transfers.
There were 2 locations, each keeping their own separate inventory system. Each properly received inventory, and inventory was in fact properly relieved by the sales function. The system wasn’t used at all for the transfer of goods from one location to another — no surprise that inventory was off! Since the system for each store was independent of the other, neither system “knew” of the movement of goods to the other location. So, you had a system where goods were received properly, but not properly relieved at the location shipping the goods!
My developer friend thought it best to stay away from this potentially difficult situation, and suggested that the prospect find a developer who was willing to do the work as desired. The moral of this story? Not all business processes deserve to be duplicated. In this case, the issue was not the computer application that was the problem, but rather how it was being used.
The story also illustrates very well one of the situations that I always try to become aware of at a clients site when I’m there – “What are they doing manually that could easily be in an application? Why isn’t it?” The manual packing list is in my book a BIG red flag! It signals stop, look, and be cautious.
P.S. My friend later found out that this company’s “new” inventory system didn’t work any better – at least until the business process was changed.