Evan Schuman's StorefrontBacktalk

Managing new requirements with POS vendors is not a new problem for retailers. I have attended many sessions where I put in my “votes” about which features and functionality I want added to the system. The success of getting my needs to the top of the list largely depends on how many drinks I bought at the bar the night before. (Maybe I should have started a POS Super PAC?) Even if my requirements make the top of “the list,” that doesn’t mean they are going to get done in a timely manner.

I’ve also been in situations where a business need has arisen to change the POS or back office and I have pulled out my checkbook and said, “I want to buy some priority, how fast can you get it done?” only to be told nicely that it will be six to nine months before something is generally available.

But with many cloud-based POS approaches, the problem is made worse, because all customers share the exact same code. A change for one means a change for all. Most traditional POS providers have dozens, if not hundreds, of versions of their code out in the marketplace. They branch out the code to address bugs or customer-specific needs, only to bring it back to the main code base in major releases. It’s a pain-in-the-butt way to manage code, but it is a reality that the big POS companies must deal with.

Although I do believe there are advantages to cloud-based POS, it is important that you understand what flexibilities you will have once you go live. Here are some of the questions you should ask your potential cloud provider:

• What is your change management process? When are changes implemented, and how am I notified? Do I have any say in the matter for certain changes? Who can request changes?
• What is your release schedule? Who determines (and by what process) what changes are made to the system?
• What is your roadmap for the product? How can I formally affect changes to that product roadmap
• What is allowed for data access from your system? What is the process for requesting and implementing data access?
• What are the costs for making changes to the system?

Although it’s really not going to do you any good (they will skewer you anyway), you need to present the answers to these questions to your business partners, with a frank dialogue about how this approach will work once you go live. They will likely skim over it as they look at the mouth-watering numbers and still look for your head later. But at least you will be able to sleep better knowing that you tried.

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.