Tech Talk

Recent posts

If Elon Musk Was A Hotelier
Posted: 09/25/2020

What if a person of Elon Musk’s character and bravado were to enter the hotel industry? How would they shake things up and presage the next ‘game-changers’ to propel hospitality beyond our current challenges?

Things right now are hard to predict. That is a fact. Trends lack patterns. Strategy is a 6-month viewfinder. Leaders are in a tactical storm. We feel overwhelmed by the unknown and the feeling of “what is next.” 

Over the past six months, this column has focused mostly on hospitality technologies and issues that were triggered by COVID-19. Innovation has flourished during that time, from both established industry technology providers and from startups. At last count I had identified nearly 300 startups in the space since the beginning of the year, some of them with very interesting technologies.

As outlined in our previous article, cleanliness is dominating the headlines within the hotel industry, with a number of press releases on new initiatives from all the major chains. The landscape has transformed quickly, to help keep up with the standards this article will summarise the basic principles of cleaning and sanitisation of guest rooms and how that can be achieved quickly, easily and cost-effectively.

Decreasing Stress
Posted: 09/14/2020

Stress does not come without your invitation. It is self-induced by our perspectives of what is occurring in our lives. We all have stress, and the less of it, the more happiness you experience. Life is about living day to day.

want to read more articles like this?

want to read more articles like this?

Sign up to receive our twice-a-month Watercooler and Siegel Sez Newsletters and never miss another article or news story.


The Decline and Fall of Civilized Systems

by Michael Schubach

As I spend time with system users throughout the industry, there is a comment that I hear frequently enough to have it register as a recurring theme. It comes in the form of a sometimes wistful, sometimes angry complaint: “our system used to handle that situation just fine but then something happened and it isn’t working anymore.” 

Early on, I would chuckle quietly at these well intentioned but sadly misinformed people. “Silly rabbits,” I’d think to myself, “software systems don’t just stop doing what they did before.  You made a change of some sort and you’ve screwed something up.” There is a slight possibility that while I was thinking these thoughts I may have rolled my eyes or crashed my head down on the table, but I’m sure I was very subtle and no one noticed. 

Software’s chief asset is its thoroughly repeatable predictability… it always follows its own rules. It may run amok when unanticipated or ill-fitting data is pushed through its electronic maze, but it follows its own instructions – nothing more and nothing less. Although its license may expire, its platform or operating system may no longer be supported or its peripherals become unworkably outdated, the software system will never go berserk and decide that it’s no longer interested in aging your receivables. You are the party at fault – you changed something.

And then it dawned on me.  Software’s chief asset is also its greatest liability. It never changes.  How many businesses live by the mantra that nothing is supposed to change? Listen to successful entrepreneurs and you’ll always hear some variation on the shark imperative: move or die. Businesses must adapt, evolve, respond, change and change again. The very idea that things should remain constant is no one’s plan, unless of course it involves software support. 

I’m sure that application vendors have arrived at this paragraph with their feelings hurt. Of course there is change in their world – it seems to them that it’s all that they deal with. But change and usable change are two different commodities. It’s nice to know that your system will now handle Zimbabwean tax surcharges but that’s of arguable value outside of Zimbabwe.  What does this nuance point out? The simple truth is that you are a member of a user community, and that your vendor has invested – quite wisely – in serving the entire community; large-scale deployment is the only way the economics of software delivery make sense. This means that change, while constant, is not intended to benefit you individually. It also means that your needs are prioritized against the rest of a community that can be vast – and way ahead of you in line. The result: although vendors thoroughly support change, the arrival of relevant change can make an eternity seem fairly brief. In the meantime, you as an operator may be forced to improvise, and guess what? Your software no longer functions as it used to. 

The vendor’s favorite rejoinder to make you feel better about the future prognosis for change is to say that they are adopting “agile methodologies.” The agile method (versus the more traditional programming style referred to as the “waterfall method”) uses analyst-programmer teams that dispense with long, formal technical specs; teams generate code based on user stories (a single, manageable feature or requirement) or “epics” (a collection of user stories that work together in a larger context). Sounds fast, doesn’t it?  Although they may engineer more features more quickly, the lion’s share of the process – testing, reviewing, integrating, documenting and deploying and instructing use of the new code remain largely unchanged.  There’s that, and the annoying little fact that changes don’t drop easily into large complex applications no matter how fast you write them. If they did, the vendors wouldn’t tell you all about their new agile methodologies and then announce that your change will be available in September – it’s always September – but then go vague or silent on the specific year they have in mind. 

Most frustrating of all is that in order to get your vendor to react – agilely or otherwise – you must first define your change requirements. That implies that you’ve already beheld the business transformation, mentally visited the shining city on the hill, and you are ready to begin your journey. Just as you feel yourself awakening, magically reborn in the golden dawn of a glorious new day, you’re instructed to take two aspirin, go back to bed and wait for the symptoms to pass. 

Is there a lesson to be learned here?  Maybe not – the rule of thumb seems to be that the bigger and more widely distributed (read “successful”) an application is, the harder it is to change. Drat the luck that you chose an industry leader to supply your application – there’s a catch to everything, isn’t there? Sometimes it feels like your choices boil down to “small, stupid but trainable” versus “large, competent and immovable.”  Neither choice actually provides the active adaptability that ongoing operations require. 

But really, the most mysterious change is the one that hasn’t been made. Although vendors provide products that anticipate the many moods of hospitality, serving the general public and enabling personalized guest recognition, providing real time pricing updates and offers, and maximizing return for the operator emphasizes the industry’s need for flexibility in every area.  With the emergence of SaaS (Software-as-a-Service) offerings, what the vendors will learn is that software that can’t change easily will be changed out. If the technology doesn’t become more adaptive the to user, the user will adapt to alternative providers.

Asking users to remain still while the world changes in no longer an option.

About The Author
Michael Schubach

Michael Schubach is a regular contributor to Hospitality Upgrade.

Blog post currently doesn't have any comments.
Leave comment

 Security code