“You can’t manage what you can’t measure” is an old business adage. I’ve seen some attribution to the late Peter Drucker, who said, “If you can’t measure it, you can’t manage it.” Drucker’s comment is intended to mean that absent an objective view of truth, it’s hard to determine what actions will change an outcome. And since business is about changing outcomes – higher revenues, higher profits, lower costs, etc. – it can be a company’s death knell.
In the world of legacy point of sale (POS), this neglect for accurate measurement comes in more than one flavor.
The first is the absence of any data. POS systems capture sales, discounts, promotions, voids, labor expenses: most everything juicy. Sadly, the overwhelming majority of legacy systems have no way to communicate this information outside of the local environment without an extra chunk of cash coming from the hapless owner’s pocket. A restaurant owner must go on-site and spend hours pulling this data into reports, putting it into a consolidated view, and taking a stab at corrective actions. Staggeringly there are well-known POS systems that even dump information. What if I told you that you could spend $20K on a Micros 3700 only to have your data wiped every 14 days. Does that sound like it’s going to help with objective business measurements?
The second is convoluted data that may even crease worse outcomes. The problem is that many merchants will use fields in the POS database and assume the fields are accurate. In reality there are all sorts of adjustments and modifications being made to the data (with no published explanation) by the legacy POS software, leading the poor business owner into a false sense of assurance. Imagine the frustrations shared by accounting firms trying to reconcile business sales when the “sales” field in a POS database doesn’t match the tender, credit card and check payments.
There’s a very easy explanation for all of this: legacy POS software is hardly ever developed by software engineers or data scientists. Here’s the honest, typical progression of a POS company that nobody talks about.
A person owns a restaurant. The restaurant fails. Then they work as a POS reseller. They perform poorly. But they get the idea that the POS company is making all the money. And the POS sucks: that’s why their performance stalled. So they build a POS. New cycle begins.
Let’s take a view at NCR’s Aloha POS to prove this point. Aloha is rivaled only by Micros in hospitality market share. Here’s a page from their “documentation” about the data Aloha captures.
Visiting any number of the DBF files will make it instantly clear that the Aloha software is capturing the same data in a number of disparate formats and timestamps. This adds confusion and duplication for no justifiable reason.
Worse, the introductory paragraph misleads the reader into thinking that the publication of a grind DBF file is final, and “third party program can safely assume that the data is ready and represents the complete day.”
Wrong.
You can edit data in the grind files retroactively. Further, if Aloha updates its version and if a file folder needs to accessed for audit or reprinting, the DBF files will be overwritten from the Trans.log. In other words, any changes made would be replaced with the original information!
Legacy POS companies make it hard on themselves by refusing to publish documentation that helps their customers, or third parties service said customers. We conjecture the reason is two-fold.
First, legacy POS companies love their walled gardens. Sharing any information makes it “easier” for third parties to build solutions the POS company would rather screw up themselves. It’s no secret that companies maniacally focused on one thing do it better than companies with multiple distractions. POS is no different.
Second, many legacy POS companies are not technical in nature; don’t let the fact that they build software confuse you. They wrongfully believe that documentation is “secret sauce” and creates competitive disadvantages. If legacy POS companies weren’t so insecure about their technical abilities this wouldn’t happen.
Contrast this with cloud POS companies that openly publish documentation and make integration easier for third parties. Cloud companies know that third party integrations only make their product stronger, and stickier. And by spending a little time publishing APIs and documentation you have no justifiable reason to ask third parties to pay $50,000. Further, if integration becomes easy, the cost of supporting “hacked” integrations goes away – an oft-cited reason for legacy POS integrations being closed.
Here’s the developer page for Revel.
Nearly every cloud POS company has such a page.
Perhaps the real boon in the API is that operators are able to get an updated version of the truth: a constant measurement that can then be managed. If a field is updated or changed, it’s reflected in the API. Armed with the API documentation, anyone who accesses the API will know what each field means, how it’s being calculated and why it’s being changed.
Without such published documentation it’s as if you’re given a map, see a big red X, and drive eagerly towards it… except X marks a land mine, not buried treasure. That’s the importance of context, consistency and clean data: it gives you measurements you can manage.
Yet for some reason legacy POS companies are in no hurry to give their operators more of it. Maybe they don’t want their customers managing their businesses better; maybe the customer might discover why their legacy POS provider was keeping them in the dark all along…
Add comment