Why Micros Simphony’s Reporting Could Be Dangerous As Hell


Above is a YouTube video demonstrating part of the reporting features on the Micros Symphony platform. It’s short – only 83 seconds – and I encourage you to watch it before you read this article because it will give you context to what we say next.

For the uninitiated, Simphony is Micros’s cloud POS product. It’s geared towards large restaurants, hotels and retailers… and it’s not cheap. Micros’ flagship product – the old RES systems – is slowly being phased out, leaving many merchants and their dealers wondering when the system they’ve relied upon for so long will indeed breathe its last breath.

The uncertainty Micros created has led to a smattering of negative reviews, including some below that echo what we’ve unofficially heard: Micros has abandoned support and development efforts on the RES systems as it changes its business model to focus on larger, more profitable Simphony accounts.

  • “My 3700 MICROS is less than a year old. Purchased maintenance contract and was ASSURED it has hardware and software support. Not true. All kinds of programming glitches that I had to live with for months with no help from support.”
  • “Use another platform. The service for their POS products is worse than horrible. Support communicates poorly and failed to communicate with customers. Have NEVER had a positive experience with Oracle since they assumed MICROS POS support.”
  • “I currently have over 300 POS workstations deployed across multiple Micros platforms including Simphony 1x and RES 3700, as well as a number of hotels running Opera PMS. Dealing with Micros since the Oracle takeover is the most painful customer service experience I have ever had to deal with in 20+ years in the hospitality industry.”

With all that said, let’s talk about what we find troubling with the Simphony reporting tools.

“Oracle Hospitality Reporting and Analytics Platform”, a portion of which is shown in the video above, is included gratis with a Simphony subscription. Oracle has somewhat improved its user interface (UI), likely to keep pace with cloud POS companies who offer modern UIs. But reporting has long been a free feature on any POS, so there’s nothing new here; POS companies have loved emphasizing the number of free reports they offer, as if the number of POS reports is somehow related to the value they create.

Our concern lies with the attention Oracle has paid in making the report in the video more useful. In an effort to improve UI it seems that Oracle has committed an egregious miscalculation.

This is a screenshot from the video above.

And here’s the voiceover text that accompanies this part of the video.

For example, you can examine sales generated by each employee in relation to hours worked and determine the store’s most profitable employees and their sales performance per labor hour. With that information you can adjust staff scheduling to best manage peak traffic or offer additional training to help underperforming employees

The screenshot would lead the user of this report to believe at Wanda James, Gordon Kelly and Andrea Pullman are killing it, while Cameron Turner is, well, being killed. How does a user come to this conclusion? Cameron has the lowest Net Sales/Regular Hours value while the other three employees have the highest values and are highlighted in green.

Now let’s use some actual mathematic principles to show how dangerous this is.

We need to be familiar with the concept of normalization to discuss thus further. Normalization just means putting two items you want to compare on common ground. Here’s why normalization is critical to the employee data above.

Those of us familiar with foodservice know there are natural peaks and troughs throughout a day, week, or month of a particular operation. By comparing an employee’s sales on Monday morning (a trough) to an employee’s sales on Friday night (a peak), it will look like the employee working Monday is hopeless, and the employee working Friday is a superstar. Even if we decide to create a metric like Net Sales/Regular Hours, we’d still expect more sales per hour for someone who works during peak hours, where there could be higher priced items and alcohol sales.

The only way one could objectively compare Net Sales/Regular Hours across all employees to determine who is performing well and who is performing poorly would be to normalize the hours the employee works. We would do this by comparing an employee’s hours to like hours of similar shifts that meet certain criteria.

For example, let’s say that the worst performer in the Oracle employee data, Cameron Turner, works Monday morning AND Saturday afternoons. We would first want to compare Cameron’s Net Sales/Regular Hours against Monday morning shifts. Let’s say we do this and find that the average employee who works Monday morning from 8 AM – 12 PM has Net Sales/Regular Hours of $18.00 while Cameron has Net Sales/Regular Hours of $20.00.

So on Monday morning shifts Cameron actually performs better than the average.

Now let’s look at the other shift Cameron works, Saturday afternoon. Using the same method above, we find that the average employee who works Saturday afternoon from 12 PM – 4 PM has Net Sales/Regular Hours of $23.00 while Cameron has Net Sales/Regular Hours of $25.00.

So on Saturday afternoon shifts Cameron again performs better than the average.

But wait.

Even though we’ve normalized the data by comparing Cameron’s performance for the shifts he works to other employees who work similar shifts, we need to be cognizant of the kinds of days we’re including.

To show what we mean, let’s say that last Monday was an outlier (i.e. there were higher sales than most other Mondays) because it was a holiday. (In reality it could be an outlier because there was good weather, school let out, there was a big event, etc..) And last Monday morning, Cameron was the only one working that shift. So should we include last Monday in Cameron’s performance if we’re cognizant of normalization?

You can see how a simple arithmetic mean average for Net Sales/Regular Hours is dangerous for decision making. Not only does it fail to use normalization by data science standards, it gives an output that can lead users to harmful decisions. The user of Oracle’s employee performance report might be inclined to fire Cameron even though he was the highest performer on his Monday morning and Saturday afternoon shifts!

The solution to this confusion is to use a neural network. The neural network can find expected performance for certain shifts based on outlier events and moving averages. It can then objectively determine who is making and losing money. If it’s really good, it will even recommend changes to maximize your business performance by leveraging each employee’s unique behavioral patterns.

For example, if Cameron does well on Monday morning ( a trough) but performs poorly relative to his peers when moved to Saturday night (a peak), the neural network might conclude Cameron struggles with busy periods but significantly outperforms during slower periods. Therefore working Cameron on shifts that meet his behavioral pattern (maybe Tuesday and Wednesday morning shifts are slow as well) would drive new revenues for the business.

While we employ this rigor of data science to render the prescriptive solutions described above, others don’t. Oracle has astronomically deeper pockets than us and could easily afford to hire good product managers and engineers. But as their reviews demonstrate, they might not care.

Apathy yields the worst outcomes for the poor business owners relying on this data for decision making. Putting bad data in front of users is arguably worse than no data for the former gives users false confidence in their decisions.

Woe are the hapless Cameron Turners and woe are the business owners who use outputs from companies that don’t apply data rigor (trust us… Micros is far from the only offender in brick and mortar). Unfortunately for brick and mortar merchants, this has probably been going on since the first “reporting” company thought to prioritize quantity over quality.