Wednesday, February 28, 2007
Accounts Receivable, One Size Does Not Fit All!
I’ve heard controllers say that Accounts Receivable (A/R) is the “Cash register for the company.” Strictly speaking A/R is the final step in the cash register process with Order-Entry (O/E), Inventory (IN), etc. also in the mix. A/R is the only part of this equation that can be a generic application. When you look at the different industry needs for O/E, IN, etc. you’ll find that one design just won’t work. There are so many variables with quantities, shipping, pricing, etc. This is not a great revelation of mine. Software companies have gotten rich selling systems that are an acronym soup. ERP, CRM, JIT, DDS, and the list goes on.
We need these systems, expensive as they are, to do our business. Where we get into trouble is when we try to use the financial packages (G/L, A/P, A/R) that come with these systems. Some of these applications have less sophistication than Quick Books. Don’t get me wrong, Quick Books is a fine product for a small business, but don’t try to run General Motors with it. I know of a sales presentation by a major software house that featured their ERP system. The only thing consistent in their presentation was the statement that they were the industry leader of Enterprise Resource Planning (ERP) systems and that the company should buy their product based on that fact. When asked about such minor things as 1099’s in A/P, their response was, “What’s a 1099?” and when asked about “open-reporting” in the G/L they answered with, “Why would you want to do that?” Their ERP system was as lacking as their financial applications, and they were not selected.
There is another problem. A great number of these software houses don’t develop all of the applications they sell. Instead they buy them and then write interfaces to pass needed data back and forth. This works, sort of, but it’s not seamless, and there is a lack of continuity between the applications. Sometimes this is a real pain in the you-know-what, maintenance wise.
What’s the solution? I don’t know if there is just one solution. If it were up to me (no one in their right mind would leave it up to me) I would take the following approach. Develop a good, strong, generic A/R. One that defines complete customer information, the G/L accounting rules, and A/R terms and conditions. Make interfacing to and from A/R a very simple task. That way, a company could implement any O/E that meets their specific needs.
Next develop a generic O/E and other associated applications to dovetail to the A/R that could be used in a distribution industry, both retail and wholesale. I would not attempt to make the mistake of trying to be all things to all people. Let someone else deal with ERP, CRM, DDS and all of the other TLA’s (three letter acronyms).
This way the A/R could be used no matter what your company’s needs are. What say you?
Posted by S.C.R.A.H. on 02/28 at 02:24 PM
Accounts Receivable •
(1)
Comments •
Permalink
Sunday, February 25, 2007
SEE IT NOW!
This blog started off as an article about the shortcomings of several Payroll systems. I then had an epiphany; the problem applies to almost every financial package!
There are times when you need to research an employee’s pay history, a vendor’s invoice, a customer’s payment, or details behind a journal entry in the G/L. The only way this information can be gathered, in some financial systems, is to run report after report (that’s if your lucky). You go to all the effort to enter data, and then you can’t get to it. How many times has management walked in and wanted to know why the A/P clerk hasn’t paid Dwarski Construction, or how much overtime has Ruthie Fredawitz been paid in the last 6 weeks? Usually management wants that number NOW!
How much effort do you go through with your current system to trace every action performed on a vendor’s invoice? Wouldn’t it be nice to see when the invoice was received, posted, paid (and how), or what discounts were taken? How about a digital image of the invoice and appropriate signatures without running reports or going to 10 different screens? I have seen systems where this information was on 1 screen, but you needed special magnifying goggles to read it!
There has got to be a better way. Give us the ability to research at the screen without having to jump through hoops and definitely not by running reports.
This is a major challenge that must be overcome, and it’s a major rewrite to do it correctly. The omission of this search capability is inexcusable. It’s like software developers have never been in a true business office environment. To be quite frank, a great many of them haven’t.
Agree or disagree?
Posted by S.C.R.A.H. on 02/25 at 01:43 PM
System Design •
(0)
Comments •
Permalink
Wednesday, February 14, 2007
Support? You’ve Got To Be Kidding!
I don’t know about you, but I’m REALLY fed-up with all this outsourcing of software support to in-duh-viduals (sorry Scott Adams), often working in a call-pool located in a foreign country. They often have no knowledge of the software they are supposedly supporting.
Incident #1:
I was on the phone the other night trying to resolve a problem with a support person who was reading from a script. I could barely understand him, and he had no idea what I was talking about. I didn’t dare try to interject a comment, or it would lead him away from scripted instructions and force him to begin again from the top! After an unsuccessful hour and a half I was elevated to the second level of support. At least the second fellow was able to determine that the problem was above his knowledge, and after 15 minutes I was elevated to the next higher level. I lost count of the times I was “elevated,” but eventually I wound up talking to someone who actually worked at the company, not some foreigner! He solved the problem in about 5 minutes.
Incident #2:
Here’s another case of ignorant support people. Recently I bought a new computer. I had only a dial-up line available for Internet and E-mail at the blazing speed of 26kbs. It was nearly impossible to download anything. After 2 weeks the modem would not respond. I called support and was pleased to find at least they’re here in the U.S. The support person asked what release of the operating system (OS) I was using. Their reply was that my OS had problems supporting their proprietary modem, and that I needed to upgrade my OS. I said, “Fine could you send me the new release on a CD?” Their reply was, “Sorry, we don’t do that anymore you’ll have to down-load it from the Internet.”. . . . Hello? Don’t you get it?
Has anyone else out there had these problems?
Posted by S.C.R.A.H. on 02/14 at 11:03 AM
Support/ Documentation •
(0)
Comments •
Permalink