I was reviewing some CRM software today. I started to put the name in this post, but that would cloud the issue. What I’m thinking about applies to any CRM software. In reality, it applies to all software, but that’s a different issue.
Here’s what I see in the software: it has tremendous capability to automate the process of dealing with prospects and the sales cycle. In fact, I’m not at all sure that it isn’t TOO powerful for most businesses. But it needs a sales cycle to make it work. Someone has to think out the process by which leads are qualified, converted to prospects, discovery done, quotations prepared, and deals closed. The software can then drive just about any combination of communications from email to letters to internal notifications that you would want to send.
It can do it all automatically.
But it can’t think like a salesperson. Emphasis on the PERSON!
Someone has to decide what the software needs to do before the company will get any benefit.
Let’s start off with some terminology. There are two broad types of cash fraud:
Skimming refers to the stealing money before it appears on the books and records of the company or organization. Larceny refers to stealing money that has already been recorded on the books of the company.
The term cash means all types of easily negotiated assets. It includes cash, improper use of credit cards, writing unauthorized checks, kickback schemes, etc. It’s not just about the green stuff with pictures of Presidents.
I’ll keep this post short for emphasis:
At the end of the day, protecting cash is about some simple things:
- Controlling access
- Separation of duties
- Creating a culture that makes it hard to steal
- Vigilance (either actual or implied)
- Internal controls
We’ll talk about these in future posts.
You’ve heard someone say, “Too many cooks spoil the broth.” It has never been more true than in computer projects.
All the projects I’ve seen massively over budget and over deadline have had too many cooks. It’s frustrating to be one of the cooks, too.
I remember a project in which we were providing a link between a modified (by another consultant) POS (point of sale) and some manufacturing equipment. We asked for sample files from the POS vendor, and wrote the code to reformat them in the proper format for the manufacturing equipment. We tested extensively. Everything worked.
Until we went live and the POS vendor mentioned that he had changed the format of the files. So we started rewriting again. Until the POS vendor mentioned that he had some more issues come up and he’d reformatted the files again.
I know, most people reading this will say, “Why would you continue working on a project like that?” Answer: we didn’t. After the second change, we recommended that the POS vendor finish his project, and provide a final form file.
The POS vendor never finished. Project canceled.
So that makes for Rule # 5: Have one project leader that understands the core technologies, and give this person control over all the decisions in the project.
If you were considering not buying that tax table update for 2011, you may need to reconsider. The Social Security rate for EMPLOYEES ONLY has been reduced from 6.2% to 4.2% for 2011. Basically, Congress gave us all a 2% increase in salary.
Note that the Medicare rate will still be 1.45, making the total 5.65 rather than 7.65. Also, we’ve already gotten calls from clients who noticed that they can’t double the employee portion any more!
Call us for more help!
Why am I writing about 1099s in 2013 when you’ve probably not issued your 1099s in 2011 yet? For good reason. The rules you have to follow to decide who gets a 1099 and who doesn’t change for payments made after 12/31/2011. If you made a payment to a corporation in 2010, you didn’t send the corporation a 1099. If you make the same payment in 2012, you will have to send a 1099 (unless the law changes). This probably seems like a long time, but read on before you decide.
The issue here is that a 1099 is based on when PAYMENT is made, not the INVOICE date. To complicate matters, most software requires that you code the INVOICE when you post it in order to generate 1099 data when you pay it. So here’s the rub…you need to have your software set up to track payments for vendors before you POST the first invoice you will pay in 2012.
Suppose, for example, that you’re a construction company. You receive an invoice from Electrical Company, Inc. on 9/30/11 (or 1/1/1965 for that matter), that you pay 90% of and retain 10% until the job is inspected. The job passes inspection on 12/30/11, and you pay the invoice 1/1/12. This amount MUST BE RECORDED for 1099 purposes. This means that your software needed to be set up to code this as a 1099 reporting amount on 9/30/11.
- start sending W-9s (to request taxpayer IDs) to ALL of your vendors NOW. Send them a letter telling them that you are gathering the information required by the new law.
- Keep up with who owes you a W-9 and keep asking until you get most of the W-9s you will need. This isn’t important enough now to bug key vendors, but vendors will get swamped with these requests at year end and they should appreciate the fact that you’re planning ahead
- Figure out what you will need to do to code the 1099 information in your computer software, and how to distinguish the vendors that are corporations in case the law changes. If it isn’t easy in your software to tell which vendors are corporations, hold off setting up the 1099 information for vendors until about 7/1/11. By then–hopefully–Congress will have finished arguing over the health act and the IRS will tell us what the rules are going to be
Do this and you’ll be ahead of the game!