Where Is My GPS Now That I’m In A/R?
Software developers have NEVER expended any effort in designing a good . . . .
Software developers have NEVER expended any effort in designing a good Accounts Receivable. Maybe it’s stupidity on their part, or maybe it’s because they’re just plain lazy. I don’t know the reason, but I do know their design results are a load of horse pucky!
Examples:
1. Developers never consider “employee” receivables. There is no capability of passing of data from Payroll to A/R. There is no way to identify a customer as an employee. What you wind up doing is reserving a series customer numbers for employees, and all postings are done by hand from a spreadsheet. Right? Some only allow you identify a customer as “active” or “inactive,” and that’s it.
2. “Customer numbers” are another problem. They’re not an instinctive way to reference a customer. If you have several hundred or thousands of customers it’s a real challenge to find the customer that you’re dealing with. A/R needs better methods to access customer records than the limited methods that now exist. Expanding use of search fields, more effective wildcard searches, filters, and consolidated screens would be a good start.
3. Lastly (at least for this rant), the navigation through the plethora of screens is anything but intuitive! You almost need a GPS to get around. The result is that time is lost, mistakes are made, and training takes much longer. You’ll be doing a lot of training, as terrible software is frustrating and stressful to use. The result of these faults is high staff turnover!
Of all the applications within a financial system A/R is probably the most poorly designed and the most neglected by developers. Why is this? Upper management has no clue as to what is needed by the accounting department, and they are the ones who make the decision as to what system to buy. They are wined and dined by software salesmen and are promised that their problems will be solved. Yeah, right! As long as companies keep buying useless software there is no incentive for developers to spend time and money to make things right.