Evan Schuman's StorefrontBacktalk

I think it is time that POS vendors take a simpler, 37signals approach to software development: Keep it simple. 37signals, which builds project/collaboration software, revels in the fact that it often tells customers no on their enhancement requests. Basecamp, which competes with Microsoft Project, is sold on the fact that it is simple and easy to use. But if Basecamp added all the functionality its customers have asked for over the years, it would no longer be simple and easy to use anymore. So most of the time, Basecamp doesn’t do it.

There are three main components to any POS replacement project:

• New functionality not available with the existing vendor or system.
• Better, faster or cheaper options than the existing vendor or system.
• Future functionality will not be available in the existing system.

When it comes to rolling out new functionality, rolling out a new inventory and labor management tool is a recipe for disaster. Rolling out new inventory and labor management processes, supported with a new tool, is the way to go. Although the differences may seem subtle, they are profound. You should never lead a business process change with a technology deployment. Focus on how you are changing the process and how the new tool can help. I’ve seen millions of dollars wasted and careers trashed trying to go the other way.

If the new POS is not part of a business process change, then it should be better, faster or cheaper than the existing system (or, if you are super lucky, all of the above). If you can’t win at the basics (what you do today), you are not going to win at the advanced (what you want to do tomorrow).

When it comes to future projects, you need to make sure you have the ability to grow with your POS solution but not purchase one only for its future capabilities, because many of them will never materialize as business projects.

POS companies, if you are reading this, you should be focusing on how to “modularize” your software. I have worked with a POS solution that had “thousands of configuration variables.” That’s stupid. Instead, how about you let me buy and implement just the features I want and avoid the headaches of everything I don’t.

And I’m not talking about a POS module versus back-office versus loyalty versus loss prevention; I’m talking about features within POS.

If POS companies want their retailers to be successful, identify the retailers’ top 5 key performance indicators (KPI) and help them build a solution that focuses on just those items and removes all the other noise. Like I’ve said before: Make it simpler.

I’m going to speculate that the pressures on hardware being driven by the Android and Apple tablets, coupled with the overly complex and bloated software market, in conjunction with an industry going through consolidation, is why IBM chose to get out of this space. It needed to either invest or divest, and I think that IBM decided to let the market go through this “transformation” on Toshiba’s dime.

What do you think? If you disagree (or even, heaven forbid, agree), please comment below or send me a private message. Or check out the Twitter discussion on @todd_michaud.