hospitality technology made simple

April 17, 2008

the negative value of negotiated services

Filed under: evaluation,hospitality technology,selection,system replacement — kevinsturm @ 11:27 pm

Normally I spend Thursday writing a post for htms, but today I spent it speaking at Santa Barbara Culinary School. I got to speak for a short while to the next group of leaders in the hospitality industry, which is always really rewarding. It was a great event hosted by the HFTP CA Central Coast Chapter, AND we had a great luncheon speaker in Bob Hazard (former CEO of Choice Hotels). I hadn’t even looked at who the lunch speaker was so I was stoked to have such a huge name in hospitality. I also found out he is now the CEO of Birnam Wood Country Club just down the way. So COOL…

Anyway, since I was not able to spend much time writing I thought I’d shoot a quickie out about negative negotiation. If you’re in the middle of purchasing a technology solution, or planning on it, it is likely that you have spent some time negotiating price with your vendor. If you are not, or have not planned to negotiate price you will probably pay more than you need to. Vendors expect price negotiation to occur and for that reason generally have decided on what pre-valued discount they will offer before they even meet with you. So negotiate away. But, there are areas of your purchase you should negotiate price and those you should not.

DO negotiate on hardware costs
Your prospective vendor has a price point for their hardware product(s). If a customer buys it at full price then they make great margin. But they expect that you will negotiate the price, and you should. Hardware is a fixed deliverable. You get the same hardware whether you get 0% discount or 50% discount. So negotiate and get a great deal. As a side note, end of quarter and end of year are great times to negotiate price with your vendor because they are pushing to meet quarter or year-end revenue goals.DO negotiate on software licensing
In the same vein your vendor has a price point for software licenses. Regardless of how much you pay for that software you get the same thing. If you negotiate a great price then you get a great price but the same product…great for you. The quarter and year-end purchase applies here as well.

DO NOT negotiate on services
I see this time and time again with customers where the quantity of services or total dollar value of services was negotiated down. DO NOT negotiate on services, because the old adage “You get what you pay for.” applies here. Your sales person may try to make services the first place they negotiate on your order, and ultimately you don’t think you care…but you should and you do. Often a sales person tries to cut services first because they are commissioned less or not at all on services revenue. Discounting hardware and software lowers their personal income, so discounting on services means they might not take an income hit. But discounting services will have a huge affect on your project!

The concept is simple really. In my experience almost every vendor quotes services accurately to what they believe it will take to do the project successfully. Services numbers are usually made up by the services group. Discounting or lowering this number may get you a lower price point, but it also means that the services group is doing the project for less than they think it will take. So you get one of two outcomes. One, you get a Change Order Request from the project manager after work has begun and pay the higher amount anyway. Or two, you get less or often poor service leading to struggles in the implementation and support of your technology solution.

Comment if you have a story on how discounting services hurt your project. I would love to hear from you. I’d also like to hear from you if you think I’m wrong. And as always, if you’d like to find out more about kevin sturm Consulting please visit my website or email me.

December 20, 2007

enterprise software, hoax or holy grail – part one

This is the first post in a three part series on enterprise software solutions.

“It’s an enterprise software solution.” This has become a loose and liberally used term by hospitality technology vendors and hospitality venues. It is for many technology vendors the everything feature, used to answer questions about consolidated ad-hoc reporting, multi-layer configuration, shared data elements, and next generation architecture and interface support. “Yes we can do that, it’s an Enterprise solution.” But the reality for most hospitality venues seeking the Holy Grail of enterprise systems is very different. Implementing a single enterprise solution is a complex task. Implementing multiple enterprise systems is difficult at best and may be impossible for some if not carefully planned and executed.

I consulted with a client who a few years back purchased a number of Enterprise software solutions with promises of decreased food cost, better financial reporting, improved menu analysis, and lower system support costs. They chose well established vendors with proven track records, working with each vendor to implement the system to take advantage of it’s enterprise features. But like many other venues with similar initiatives, they found the project to be highly complex with problems the vendors had not prepared them for. The current outcome of their initiative was to remove one solution all together, delay the implementation of other solutions, and focus on retrofitting a single Enterprise system to meet business needs.

For some venues installing multiple enterprise solutions is not currently a reality, but for others it can be accomplished with a well planned project and diligent management of the the individual sites and vendors. Venues currently planning on migrating or replacing disparate technology solutions with one or more Enterprise solutions must consider these items before selecting a vendor(s).

research and document technical and functional operations.

Before choosing an Enterprise solution it is important to ensure that you can feasibly implement an Enterprise solution. This will be different for each type of venue, but four important requirements are network architecture, security permissions, site operations, and financial reporting needs.

Most enterprise solutions require some form of network solution that connects all sites, and many vendors them will request a dedicated or isolated network. In this day and age it would seem simple to get Internet access with all the options, but time and again venues (especially remote venues) find that Internet access is difficult if not impossible to get. For many a T1 or Fractional T1 is the only option, which can break the budget of many technology projects. To add complexity to the situation, your security team is waiting to tell you all the reasons the desired solution will not meet security standards. If it is not documented already, request Information Technology (IT) to document permission and access protocol for your network, and involve IT in the process of selecting your system.

If you are contemplating an Enterprise system it often means you have multiple locations spread out over a geographic area. And unless you are McDonald’s each of these locations have defined their operations and are reticent to change. It is vitally important you understand and document these operations, from the front end user to the detailed reporting procedures used by finance. Be diligent in asking for any “customizations” that individual sites have made to their existing solutions. Pay special attention to finance since most established finance teams have custom spreadsheets or macros that have been created to work with their existing system. Interrupting this process without a replacement plan will not only create project delays but unhappy employees.

evaluate and change your operations.
When you have documented your operations it is time to make some hard decisions. One of the most difficult projects to undertake is deciding on your corporate standards. It is actually easy at corporate, but difficult at the site level. Management at individual locations are never excited about operational changes, and are often not willing participants. The success of your project(s) weighs heavily in the hands of local site management, and their participation is vital. Decisions need to be made in advance of your technology decision so that data requirements are understood and planned changes to operational processes documented.

Once these decisions are made, it is important to mandate the planned changes. Customizations at the site level will kill your enterprise project with poor transactional data. A top initiative of your Enterprise project should be to ensure quality data is being stored. Lots of operational procedures will ensure lots of disparate and duplicate data in your system.

understand hierarchy of data elements.

Now that you have your general operations down, you can begin to document the important data elements. These data elements are important for two reasons. First, they are the back bone of your reporting. It’s the old adage of garbage-in-garbage-out. If you don’t understand the data going it, the data coming out won’t make sense either.

Secondly, data elements will be the measure to understand Enterprise hierarchy of your technology solutions. Pay attention, because this is important. Enterprise solutions are based on a hierarchy of data elements. For example, at the most basic level they will have a hierarchy of the business.

Corporation – Ownership Entity
Business – The actual business
Region – Sub definition of Business
Site – Physical place of business

Not all technology solutions will have all of these data elements, but most will have some subset. This however is the most basic hierarchy of an enterprise system. Each data element will then be associated with one or more of the above data elements. Some examples of sub-data elements are employees, revenue types, revenue centers, inventory items (whether food, rooms, tables, or people), and point of service (POS) devices.

When reviewing your technology options request a detailed data hierarchy from all prospective vendors. If they do not have this information, demand it. It is too important to your success to overlook. If they cannot provide it, then they are not worth evaluating.

diagram interface points.
If you have completed all the above successfully, you have done the easy part. You understand the operational requirements, documented important data elements, and have information on how your prospective vendors define those data elements. As great as it would be if technology vendors designed their architecture with other vendors in mind, they did not. They designed them with release dates, internal initiatives, and other customers in mind. Each data element from each vendor is a puzzle piece and the puzzle pieces must fit in order see a holistic picture of your data.

Careful attention to this step will make or break the success of your enterprise solution project. It is also important that someone with a strong technical understanding be involved in this step. Enterprise projects succeed or fail on how well the data elements fit together. I recommend putting together a simple table that creates a single view of how these data elements fit together. Having this information in a single view defines how each vendor’s hierarchal structures complements and contradicts each other.

For example, if your Point of Sale (POS) solution defines revenue centers at the lowest level and your Property Management System (PMS) defines them at the highest level an interface architecture needs to be implemented to ensure maximum benefit is achieved from each system.
You’ve now made it to the vendor selection process. For tips on Enterprise Software implementations read Part 2 of this post.

For more information about kevin sturm Consulting please visit my website.

November 27, 2007

review before you replace

Filed under: system replacement,training — kevinsturm @ 6:46 pm

The technology system you bought a couple years ago has never really met your needs, nor has your vendor ever delivered on the commitments they made during the sale. Sound familiar?

This experience often seems to be the majority for hospitality venues, and like many others you are contemplating investing in a new system. Your vendor does not seem to want to fix the problems and you are not sure they can. But before you go down the road of new requirements, RFPs, budget allocation, and the infrastructure investment of buying a new system it is worth your time and money to “Review Before You Replace”.

After almost a decade of replacing technology systems, working with venues to fulfill sales commitments, and minimizing the interruption of a new installation my experience is 65% of venues ended up having the same problems with the new vendor. The reasons for this are generally not the fault of the vendor. Usually it is a number of steps were not and have not been done by the venue in ensuring the software they purchased meets their needs. The reality is 80% of the features in competitive technology systems are the same, and the unique 20% are a very specific set of features you probably do not need (the exception to this may be in system architecture). It is highly possible that replacing your system is just a really expensive way of buying the same problems.

Before you replace your system go through the following exercises as a due diligence effort. If after these steps you find that your current system does not meet your needs, you will already have most of what you need to begin the replacement process.

  1. Define your needs versus wants.
    Define exactly what you need from your technology solution and then define what you want. You will most likely find that many of your needs end up in the wants column and some of your wants end up as needs. Prioritize the needs and wants separately as high, medium, or low. The exercise of prioritizing them will also help you organize the needs versus the wants.

    This process should include multiple users of the technology system with input from different functional areas (i.e. finance, f&b, information technology). If this process is accomplished by a single group (read information technology) it is a worthless exercise.

  2. Review the list with your internal expert.
    Have your internal system expert review this list and recommend system changes to meet these requirements. If no one in your company can do this then you will never be happy with any system you have. Like it or not, someone in your company needs to be a ‘super user’. If you believe the system you bought does not require someone in your organization to know how to use it intimately then I believe you will never have a solution that meets your needs. (Step 5 is part of the solution this problem.)

  3. Review the list with your vendor.
    Meet with your vendor to review the list together and request they respond to each need and want. You should have filtered out the items you already know can be met at this point to save time for everyone. Most likely you can work with Customer Care or Technical Support and go through this process without paying for a billable service. You are not actually installing anything new, but optimizing the use of your existing system. If your vendor responds that this is a billable service then you may be better off going with a different vendor. The vendor has to want the system to work for you.

    For this step to be successful the vendor must provide a resource that is an expert in your vertical and on the software. Demand this as part of the process and do not settle for a resource that has to escalate to another person to answer every question. A first level (or even second level) support resource is most likely going to be a waste of time for you. For this to work in a timely fashion you need a resource with two years of experience.

  4. Require your vendor to outline how to make changes.
    After getting a response for every item on your list from the vendor request detail on how to implement the changes for your system. Recognize that these changes may require you to change operational procedures. No off the shelf system is going to match exactly how you run your operation. If you want a system that does you will need to build it from scratch, and that is way more expensive and troublesome than changing operations.

    Review the notes from your vendor in detail with your internal system expert (super user) and ensure they understand how to implement both the system changes and operational changes. At this point you will probably find a new system is not required, but if you do the requirements have already been defined.

  5. Invest in training.
    If your ‘super user’ cannot implement the changes without assistance invest in training. My experience is one of the biggest reason venues are unhappy with their investment is they skimped on training. If you are looking to cut costs in your project do not cut training. Your entire operation will run smoother when everyone knows what to do. The analogy I use here is learning to drive a golf cart and then assuming that you can drive that golf cart in rush hour traffic on the freeway. You will probably cause an accident. If you do not you will succeed in causing road rage.

    The training should be catered towards implementing the changes to meet your needs. Do not let your vendor waste your money by delivering a canned curriculum that only covers half of what you need to know. Demand a custom curriculum be delivered in advance of the training so you can review it, and demand the trainer have expertise in your market and on every feature you are going to implement.

  6. Build a plan to implement the changes.
    When training is complete your super user should know how to implement changes to the system and to your operations. Build a plan on how to implement these changes. Chances are some changes will be dependent on others, and some may need to be planned around other existing events. For example, if a change will alter how your reports look you may want to wait for the end of the fiscal period. This will make running historical period reports simpler.

  7. Create a feedback mechanism for system users.
    When you have made the necessary changes to your system implement a feedback process for your users to request system or operational changes to improve efficiency. The people using the system everyday have great ideas on how to make it better. Take advantage of this and earn some good will in the process. Acknowledge employees if their recommendation is implemented and has a positive effect. This will increase the satisfaction of your employees which in turn will increase the satisfaction of your guests. And that really is the point of all this work.

By Step 4 of this process you will know if the right decision is to keep your existing system or replace it. However, vendor deception is the exception to this. If you vendor has not been honest in this process you should discover this in Step 5. This is the primary reason for a custom training curriculum versus canned content. And if your vendor lied you have a pretty valid argument for denying payment for training. This process may seem like a lot of work, but it will be less expensive than buying a new system.

If you found this article helpful, have questions about this post, or want to add insight into avoiding the high cost of system replacement please submit a comment. We can all learn from each other.

For more information about kevin sturm Consulting please visit my website.

Theme: Rubric. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.