Tech Talk

Recent posts

Enterprise System Pitfalls: Summary
Today I’m wrapping up a series of posts on the broad topic of Enterprise System Pitfalls. In this series, my hope was to help shed light on the primary problems that cause us to miss budgets, fall short on capabilities, or completely fail when implementing an enterprise system. 

The Year in Review
As 2019 comes to a close, it’s time to count our blessings. One of mine has been the privilege (and fun!) of being able to reach out to so many interesting companies and get them to tell me what they’re doing that’s different, disruptive, and game-changing. The list of things I have to write about in future columns has only gotten longer in the nine months since I started writing this column.

Sustainable Innovation
Sustainability can yield multiple benefits to hotels. Saving energy and water yields direct cost savings. Revenue can be generated by guests who prefer to deal with businesses that minimize their environmental impact. And many would argue that conserving scarce resources is simply the right thing to do.

Meetings Innovation
The sale and delivery of groups and meetings is perhaps the most significant and under-automated functions for many hotels. Even though groups often account for 30% to 60% of revenue, most group bookings are still handled manually for most if not all of steps, as they move from a meeting planner’s research to a confirmed booking.

The biggest enemy to any system is complexity. In a system of inputs and outputs, such as an enterprise system, more complexity means more parts are used in interaction with inputs to create the outputs. Every part that must be built and maintained costs time and money

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