best-of-breed or one-stop-shop…what’s best for me

For many this debate is a philosophical versus empirical one, but it is worth a discussion I think. It is almost impossible to set aside the philosophical side of the debate (i.e. those that hate strongly dislike big business), but I’m going to do my best based on my experiential side of the debate. In starting this post off lets take a moment and clarify what we are talking about.

best-of-breed
“Best-of-breed” vendors generally provide one or two technology solutions. They are 100% focused on these products and are thus considered to have more expertise in the needs of their customer (a debatable concept). Generally they are also considered to be more agile because of this focus (or so they say), allowing them to respond to development requests in a shorter time frame or at least with a more predictable software release schedule.

one-stop-shop (aka integrated systems)
(Pretty self explanatory I think) The Wal-Mart of technology vendors. They can fulfill most of your major technology needs and some of your minor ones as well (or so they claim). Generally they are very large organizations that offer products to a wide range of vertical markets. For this reason they are considered to have less knowledge of your specific operation (a debatable concept). Their release schedules tend to be further apart, but they also tend to perform custom work more willingly (possibly because of a larger resource pool) (also a debatable concept).Now that we are all on the same page lets talk about how to sort through the question, “What’s best for me?” First, for the purposes of your time and my own sanity I’m not going to attempt to categorize all the vendors for every technology solution. It’s almost impossible given the new companies that pop up semi-regularly and more importantly with the disappearing act by many of the formerly named best-of-breeds recently gobbled up by the one-stop-shops. And that quickly then brings me to the point…best-of-breed or one-stop-shop labels are a useless and very stupid business requirement when selecting your technology solution. It might have been a semi-meaningful requirement five years ago (of even two years ago), but not anymore.

Now, I’d like to just end here and have you believe me because I say so…but the probability is some of you reading this are staunch believers that best-of-breed or one-stop-shop is an important requirement when selecting a technology vendor. The rest of this post is dedicated to you. If you agree with me I’d love you to post a comment on what experience led you to the same conclusion. Below are some of points based on my experience, and why they are pointless when made as general statements.

ease of integration
This is one of the biggest points in the debate, and is often touted by the one-stop-shop as a major reason to chose them. But before you buy look closer, talk to existing customers, and make sure that this is really true. As with anything in technology your plug-and-play solution may leave you hanging. At face value it seems logical.

A single company can get their products to interface and integrate easier/better than different companies.

But changes in technology, the ever shifting product road map, and the acquisition engine proves in reality they most likely are not so integrated.

Most one-stop-shops did not start development of their products at the same time, which can mean the technology platform between the solutions is different (sometimes drastically). This can lead to some interface challenges that are often only overcome with limitations (and you end up with multiple technology platforms). The number of products gained through acquisition and the time frame of those acquisitions is also a good identifier for how seamlessly integrated a one-stop-shop is. My experience has led to the conclusion that the integration capabilities post acquisition is about the same as when they were different companies. Existing customers have lived with the limitations before the acquisition for years, so it is easy for a vendor to rationalize not making it a priority to enhance integration.

The willingness of one-stop-shops to work with other vendors is also a point to consider here. Where generally best-of-breed vendors thrive off partnerships with other vendors, the one-stop-shop may create integration road blocks. After all, it is in their best interest for you to purchase all of their products.

Now in fairness to the one-stop-shop I suppose I also need to point out that best-of-breed vendors also make this claim by touting their agility to enhance the product quickly. In some cases this is probably true. But do not be easily mislead. As a customer you want to be wary of this promise, because if it is being made to you it is also being made to someone else. You want a vendor that has a well established software development life cycle (SDLC) so they already (or at least should) have the next two to three versions of the product planned out. First, this means that new development probably cannot make it into the next scheduled version. Second, it means that your requested enhancement can easily be trumped by promises to the next customer. The temptation for best-of-breeds to “follow the money” is often too tempting and promises become easy to break.

Rather than basing your decision on claims to ease of integration do your research to document your requirements with order of priority. Select a technology solution based on your clearly defined and documented integration requirements versus claims to ease of integration.

small size = better relationship
I’m going to pick on best-of-breed vendors here. One of the claims made by best-of-breed vendors is their smaller size lends to a better vendor-client relationship. They claim to support their product(s) better and establish better relationships with their customers because of their size. Who made the rule that to be nice to work with you have to be small? In my experience a good vendor relationship is grounded in the type of people versus the size of the company.

As a side note it is too easy when choosing a technology solution to let your sales person do all the selling. And that seems logical…but your sales person is not who you will be talking to on a daily basis. You should be meeting with the group of people you will be working with regularly. If you will be assigned an account manager then meet that person. You should also speak with installation, support, and the person that handles billing disputes. Interview them because how they respond will give you a very good idea of what it will be like to be a customer. This group will often not have the skill or desire to “sell you”, so they will act just how they act every day.

Nice dinners and golf outings are great, but I bet you would give that up for a support team that is knowledgeable on the product and a finance team that is pleasant to work with. Select a vendor based on their reputation in the industry and the people that you meet, not on the assumption because they are smaller they will be better to work with.

single support entity (aka one person to yell at)
The “one person to yell at” claim is generally made by one-stop-shops and it has some validity. It can be very useful to have a single point of contact for resolving problems with your technology solutions. But this is only a reasonable point if the vendor is responsive and helpful when you yell. If you already read the comments under ease of integration and small size – better relationship you should foresee the coming point.

Having multiple vendors that are very helpful and nice to do business with will always be better than a single vendor that is difficult to do business with. Base your technology decision on who you believe will offer the better support not based on the number of 800 numbers you have to tape by the phone.

in your back yard
This is one of those funny requirements that venues seem to think is a great benefit when choosing a technology vendor, and that technology vendors tout as a major benefit to the venue.

If the vendor’s corporate office is close they will be more helpful and technical support staff will be available to swing by your property on a regular basis!

Unfortunately this is usually not accurate whether your vendor is a best-of-breed or one-stop-shop. If you yell loud enough and long enough they will send someone, but that is true if you are around the corner or across the country.

The vendor is not staffed to be at your beacon call and you will often get the freest resource (read least experienced) when you do need someone. If there is a big enough problem they will send someone regardless of where you are. In my experience your vendor’s proximity to your physical location has very little to do with the quality of support you will receive.

Additionally, as a venue be wary of the in my backyard vendor. You have expectations but so will your vendor. You’re site will become a frequent stop for sales calls, sales meetings, prospective customers, prospective partners, and bleeding edge technology solutions.

In summary if you choose to do business with a technology vendor because they refer to themselves as best-of-breed or one-stop-shop you will stand to be disappointed at some point in the future. It is naive to assume that your best-of-breed company is not looking to expand their product suite through “build it’ or “buy it” plans. Even more likely your best-of-breed company is continuously being courted by one-stop-shops and will eventually marry for money (a poor relationship foundation by the way…in life and business). But for many that is goal. Build a company so that it is attractive enough to a potential suitor to sell and retire in the Caymans? Can you really blame the owner(s) for doing what almost every entrepreneur dreams of doing? I think not, so stop treating your vendors as if they were different than any other company with a different goal than your company. And for the one-stop-shop vendor the reality is they are generally not quite as seamlessly integrated as they proclaim.

The bottom line is hospitality venues did not coin the terms best-of-breed or one-stop-shop. They are terms creating by the vendor’s marketing departments and ultimately should have little bearing on your technology decision.

Comment if you agree or disagree, I would love to hear from you. And as always, if you’d like to find out more about kevin sturm Consulting please visit my website or email me.

Pictures courtesy of DWQ, Crawfishpie, Dzwjedziak, Extra Medium, katiebate

the negative value of negotiated services

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.

enterprise software, hoax or holy grail – part three

This is the third post in a three part series on enterprise software solutions.
Read part one here and part two here.

Document features under development.Okay, you have your lab in place and it is setup to mimic what you want for your live enterprise system. All the vendors you want are interfacing to the fullest capabilities of their individual solutions. The reality is that through this process you have found features that do not exist or do not work as you expected. These features are either currently under development, scheduled for a future release, or no plan exists to develop these features.

Do not leave your vendor(s) responsible for documenting these features, and do not expect they truly understand your business requirements. When you have the complete list of required features that are not working or missing, document both the requirements and use case of how these features will be used. This is an important point, as generally the requirements for these features are loosely worded. The vendor will interpret them and develop something that may not be what you want or need. You want to avoid this by getting a very detailed use case documented for each feature. Recognize if you get something you do not want, it is both your fault and the vendors as neither party did due diligence.

The other big reason you want all of these features documented in detail is for contract negotiation and success criteria.

Get beta feature requirements and dates in the contract.
If you have required features that do not yet exist (and you will, specifically with interfaces from vendor to vendor), these features need to be outlined in your vendor contract(s) with commitment to dates and software versions. Many vendors will attempt to avoid this completely, and some may simple refuse. It will be a negotiation and some of your required features will get negotiated off the table. Set your expectations low so you are pleasantly surprised when you get more than you expected.

It is important that the contract point to the use cases that you created in the previous step. You want no ambiguity on what is delivered by the vendor. Now, you may be saying to yourself this is all great but you have vendors who defaulted on their contractual commitments in the past. If you are concerned about this, the best option is to create payment stipulations in your contract tied to each feature. But this must be a win-win situation. Generally vendors invoice you at the end of the project and you pay them upon project completion You can create incentives to complete contractual features by tying delivery of features to progress payments for services and/or software provided. Adding these stipulations to the contract means you may be paying your vendor earlier than normal (win for them), but it also adds the stipulation that you will not pay them some portion at all if they do not deliver (win for you). I may do a separate post on this subject at a future date, as it warrants a more detailed discussion.

Prioritize order of software implementation.
The timeline of your contract negotiation may have some affect on the order of software implementation, but this is a topic that needs careful consideration. This is an easy decision if you are only implementing one enterprise solution. But if your enterprise project has multiple solutions the order they are installed is important. In my experience there is always a right order, and there will be dependencies. You should have a good idea of the order based on your lab setup experience as well as the interface diagrams that you created. But if not my rule for implementation order is based on a single question.

Is the solution primarily used for finance, operations, or reporting?

This is an important question as finance solutions generally should be installed first. A solution may be used in all three areas, but it’s primary purpose is the point. The reason finance software should be installed first is the setup will trickle down to the setup of operational systems. Defining financial standards in operational systems may lead to limited functionality of your financial systems. Also, reconfiguring your operational systems creates a mess of problems you want to avoid.

Here are some examples of how I categorize some standard hospitality technology solutions.

• Banquet & Catering – Operational
• Business Intelligence – Reporting
• In Room Services – Operational
• Loyalty & CRM – Operational
• MRP& ERP – Financial
• Point of Sale – Operational
• Property Management System – Financial
• Purchasing & Inventory Control – Financial
• Reservations – Operational
• Security & Surveillance – Operational

Prioritize order of site implementation.
Again, this may be an easy decision if you have only a few sites. But for companies with many locations this decision can either positively impact or kill your project. The tendency is to have the first site either closest to corporate or the site with the most experienced/tenured staff. In reality these are poor qualifications for the site that will define your initial success. Very experienced/tenured staff can be very reticent to change, which you want to avoid. Venues in close proximity to the corporate office generally have extra pressure because of consistent visits and tours, and creating additional pressure with a new technology system is not fair to the staff. My experience is any problem at a site already under the microscope of corporate is just exemplified. With a new technology system you will have problems that need time to resolve. Install sites close to corporate once you know things work. It will be easier on everyone.

Really it is only the early phase of the project where the order of implementation is important. Look for locations that meet these qualifications.

• You want a site where employees are accepting of technology and proficient at it. Generally this means you need to look at a location that is within close proximity to a major university. But you do not want a transient staff. Continuous training at your pilot location is especially troublesome when trying to define operations.
• Chose a site that is easy and affordable to get to. Your staff and vendors need to be able to reach the location quickly without breaking your budget.
• It is important to have as staff that experienced with your current operations. But as previously mentioned the most tenured staff is not necessarily best.
• Choose a site where the infrastructure can be updated if required. Older properties can make getting a new cable run almost impossible. Newer locations have been designed to accommodate newer technology.
• The property should be low season during implementations. A really busy property will mean the staff is really busy with other things, which means your technology solution implementation is not the most important thing. For much of the staff in needs to be the most important thing.

The most important order of implementation decision is which location will be your pilot site. This site will define the process for future implementations and ideally be the standard for implementations moving forward. It should meet each of the above qualifications.

Install pilot location.
Now that you have your pilot site chosen it is time to move into implementation phase. However, my advice is to have your lab installation setup with the software versions and features that you are going to install at the pilot location. The lab should be used as the template for installing the pilot location. Implementing a handful of new features during the pilot is a dangerous gamble that can create major problems. Management from locations communicate with each other, and any significant problems encountered at the pilot site will be passed around the management community. From a momentum standpoint you need the pilot to have minimal problems.

Your pilot site should have three major goals. First is a technical proof of concept in the production environment. This means that you should not move past the pilot project until all software solutions are installed successfully. Second is documenting installation standards and procedures, and third is confirming operational corporate standards that were documented in the first step of this process.

Document standard installation procedures.
Documenting standard installation procedures is worth a more in depth conversation because it will save you time, money, headaches, and heartache. Whether you, a contractor, or your vendor completes this is up to you, but it is vital to your project success. It will cost time and money to do, but is worth doing. The main reason is that resources on your project will change. Knowledge transfer is simple when it is written down. You will most likely have standards document for each technology solution that you install.

This document should read like a manual for someone that knows nothing about you business or your technology decisions (this is probably not possible but a good goal). Here is what the table of contents would look like to give you a head start.

• Project Overview
• Business Case and ROI (if exists)
• Project Stakeholder Contact List
• Project Team Contact List
• Project Communication and Escalation Procedures
• Architecture Diagram (including interfaces)
• Planned Installation Timeline
• Installation Prerequisites and Milestones
• Configuration Standards (may reference a template database)
• Standard System Files
• FAQ (list of commonly found problems with resolution)

If you have additional questions that were not addressed in this series feel free to send me an email or post a comment. Good luck with your technology decisions!

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

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.