Potential clients looking at QuickBooks Enterprise Solution often ask questions like, “Does it support serial numbers?” No. “Does it do multiple warehouses?” Yes, with the advanced inventory feature (extra). “Does it do workflow?” No. “Will the fixed assets do everything that FAS will do?” No.
Finally, I tell them, “Here’s the bottom line: it’s $3K or less for 5 users! Other products in the mid range start at about $2K per user.”
“Does it do…?”
Well, you get the idea.
In software, there are trade-offs: functionality vs. cost. I think the saying goes, “You can’t have your cake and eat it too.”
I don’t know what it is lately, but I seem to keep getting assigned to client employees that want to share their qualifications with me.
“I used to work in BlahBlah for BigCorporation, Inc. on SAP,” they say.
Is it years of interviewing employees that make me want to say, “Oh, that’s great. Why DID you leave such a wonderful position?” Needless to say, though, I control myself better than that.
The interesting thing is that having worked with SAP seems to qualify as the one piece of experience that makes one a complete expert on anything else ERP. I should say here that I’ve never worked with SAP, and have no desire to. My expertise (and my client base) is in the mid-market, and I don’t play with the big boys.
What I do know is that there is significant difference between the Tier 1 packages (SAP, Oracle, JD Edwards, PeopleSoft in its day, etc.) and the mid-range. Those differences apply in both directions: Tier 1 folk generally don’t understand what they are buying in the mid-range, and mid-range folk who think they have Tier 1 in hand are often wrong. But I digress.
Here’s the thing: employees who know one software package don’t often automatically absorb the information for another software package. People–in general–like to live in their comfort zone. So if you take an employee that’s been working with SAP and give them Sage MAS 90/200, they’re going to hate it. It is missing too many features.
Never mind that SAP implementations have an extra zero or two in the cost.
The last client that shared her qualifications with me proceeded to rant about the reporting problems she had with their current mid-range solution. Finally, I asked for a specific example.
“Well,” she said, “I just spent two weeks re-keying 1,300 plus vendors because I needed them in Excel. There wasn’t a report to do it in the software.”
And she was right. There wasn’t a report. There was a little feature called “Export to Excel.” It was right there on the customer screen –> File –> Export. Five clicks later and a few keystrokes, I pulled the spreadsheet with the customers up in Excel.
“Is this what you wanted?” I asked as humbly and softly as I could.
“That’s more information than I wanted,” she snapped. I guess she didn’t know how to delete Excel columns. She–after all–knew SAP and Oracle…
Oh, by the way, I mentioned this to a colleague. She pulled up the Help text. Right there under “Export” were the detailed instructions.
A couple of weeks ago, I was showing a new module to a client that had purchased their software from another company. Several months earlier, we had done an upgrade. We offered the client support and training, but they declined.
Throughout the discussion, they insisted that the reporting was terrible in the current product. I ignored the comments for a while. Finally, I asked, “Can you give me an example?”
The Purchasing Manager said, “I wanted a list of vendors in Excel. The best technical support could come up with was a label report. We had to key them manually.”
“Hmmm,” I answered, “Let me show you something and see if this is what you wanted.” I clicked File –> Export, selected a few options, typed a file name, and hit Ok. Then I opened Excel and the file I had just created.
“Was that what you wanted?” I asked.
The Purchasing Manager answered, “That’s more information than I wanted.” (She was serious, and sounded angry.)
I turned to the controller, and asked, “Was there a reason you didn’t give us a ring about this?”
“You would have charged us,” she answered.
The Purchasing Manager hit the nail on the head. “Let’s see,” she said, “a couple of hundred dollars (at most) vs. two weeks of my time…”
Penny wise and pound foolish…
Harry Potter commented on my blog. Atlanta mls did as well. And SEO professionals.
Come on guys? I guess you were hoping that someone would allow all comments to post without vetting them. Not here. Give it up.
The real problem is that if someone actually commented on the blog, they’d probably think I just deleted their post. They’d get lost in the sea of posts selling porn, enlargement of various body parts, better marital relations of various kinds, and all kinds of illicit drugs.
I still try to read through the names and recognize names that actually might be real. But Harry Potter? Come on, guys. Even a spammer can do better than that. Or maybe not.
There was a Gartner Group report some months back that contained a statement that (roughly) said, “It’s easier to train a business person in IT than to train an IT person in business.”
In many ways, I agree. The thinking processes are different. The objectives are different. True IT people are analytical and technical. Many business people are intuitive and relationship oriented. Not that each couldn’t learn from the other.
However, the more I work with IT professionals, the more I see that there is a central problem that I’m beginning to call the IT Effectiveness CHASM. It’s produced by a simple fact: IT objectives are often different from business objectives. In many cases, they aren’t even on the same page, and they can’t be easily translated to one another.
I’m working on ways that will work for both the IT side and the business side to bridge the gap.
I’m sure you know already–so excuse me if I’m repeating–that ROI is intended as a tool to compare different investments. The way ROI is often used in the IT industry is a bit different. Here’s an example.
Suppose that we’re looking at a new order entry system with warehouse management capability. The system costs (say $100,000). Now we analyze our ROI:
We have 4 warehouse employees, based on history, we believe that we can eliminate 1 of the 4. Salary plus benefits are $25,000.
We are also being charged by large customers when we do partial shipments or make errors in orders. Based on history, we think that warehouse management can save us 75% of these charges, or another $25,000.
Next, we’ve observed that salespeople often wander the warehouse to check stock levels. This is necessary because inventory quantities in the current system are not accurate. Salespeople estimate that they spend about 2 hours per day or 25% of their time doing this. We will eliminiate all of this for 10 salespeople, and estimate that with only a 10% increase in their daily number of orders, we will increase sales by $250,000 per year.
We could go on and list several other items. Some of them like “One-time inventory reduction,” we could actually assign a dollar value to. Others, like “Increase customer satisfaction,” will be hard or impossible to assign dollars to. All of these should be listed.
As you can see from above, we expect $300,000 return from a $100,000 investment. Most people would say this is a good project from a monetary standpoint. This is as far as most ROI analysis goes.
The system is implemented. Some of the ROI is realized (hopefully). Much of it is forgotten.
Bluntly, we’re using ROI wrong. It’s fine to do this analysis–in fact, I recommend it. The important thing here is not the amount of the return (as most people think). This might be a good project if we could only identify $90,000 in ROI, or even $50,000.
In reality, most of the benefit from a new system may be hard to quantify. Intangible benefits like customer service increase, sales management effectiveness increase, better inventory investment, increased correct order fills, reduced stockouts, etc. are difficult to assign hard numbers to (although some try).
The important things about this analysis are (a) there is ROI (tangible and intangible), (b) it provides a focus for implementation of the system, and (c) it gives a basis for measuring the effectiveness of the project.
For more on implementation with ROI, see Rule # 3.
Last week, I taught a class titled, “How to Cut Your IT Cost and Increase Effectiveness.”
At the beginning of the class, I thought it would be interesting to learn what the attendees thought “Effectiveness” was. I didn’t realize that I had both IT professionals and non-IT business professionals in the class, but I did.
The fascinating thing was that the IT professionals thougth that effectiveness equalled uptime, bandwidth, reliability, and other system performance metrics. The business people thought that effectiveness meant profit, productivity, and efficiency.
Their couldn’t have been a wider gap between the opinions. It made me realize that this is not just a gap, it’s a chasm. The cultures of business and the culture of IT are completely different. The values and objectives are different. Moreover, they are potentially in conflict.
Suppose that you could trade 1 random hour per day of system down time for $1 million more profit on the bottom line. Would you?
That’s a bit extreme. Suppose you could trade a new copy of the latest version of Office for a half-day of training on how to use your order entry system better? Would you?
Focusing on the IT objectives the attendees in my class gave certainly isn’t bad. Neither is a new copy of Office. But they are not directly related to the most important goal of the business, either: to make a profit.
That’s the chasm: IT effectiveness is not defined in terms of business effectiveness.