mail call…what’s the scoop on SaaS solutions?

I received an interesting email a while back from Carson Mehl at Lumiere Hotels.

“I am curious to know if you have heard of any robust hotel software being developed that is web-based. Our company has started using a number of web-based software solutions such as Google Docs and Basecamp by 37signals and they have been a huge asset as far as ease-of-use, collaborative ability, and no-need for extensive/expensive hardware. The great thing about web-based software is that it all operates inside the browser so it can be easily accessible from a number of devices.”

Regrettably I was not able to point to any truly web-based solutions that I felt would meet the needs of a boutique hotel group. There are a few out there but none that I have extensive experience with or have been impressed with.

What Carson was really asking is why hasn’t a hospitality technology vendor come up with some true SaaS applications that fulfills the requirements for a boutique hotel or resort location? For those that are not familiar with SaaS it means Software as a Service. Wikipedia defines it as “…a software application delivery model where a software vendor develops a web-native software application and hosts and operates (either independently or through a third-party) the application for use by its customers over the Internet. Customers do not pay for owning the software itself but rather for using it. They use it through an API accessible over the Web and often written using Web Services or REST.”

In our email conversation Carson was good enough to expand to what hoteliers are looking for…

“…The newest evolution of internet browsers and runtimes like Adobe AIR are really opening up the possibilities for rich internet applications. Applications like Google docs, basecamp, ZOHO, buzzword (my fav), even Facebook that are stored in the cloud and accessible from anywhere, offer such an advantage. The ease of collaboration they provide is alone and tremendous improvement on traditional software not to mention the accessibility factor, ease-of-use, elegant design, and simple hardware requirements. I do not have super-deep ranging experience with hotel software, but what I have used is far short of what is possible today.

From an hotelier’s point of view, I see a demand for a well designed software platform that is easy to use and is far reaching ie: pos, pms, booking, web-booking, reporting, etc. What is currently available in this regard is very expensive and complicated from both a hardware and software standpoint. The existing platforms work well for companies with deep pockets, IT experts and central reservation departments…

I guess the dream software would provide seamless connection between web reservations, pms, and the gds. It would allow an administrator to provide different levels of access to employees. It would automatically create and update guest profiles. It would show activity feeds for a property (similar to a facebook newsfeed, but showing reservations made on the web, pms, or gds, and more). It would be dead simple to use. It would look elegant. Training would be obvious and intuitive. It would be a subscription based service or maybe annually licensed. The system would be complete so there wouldn’t be any interfacing problems between disparate types of software. All the data is indexed and searchable. Reports are automatically generated and distributed. Data is backed up securely. The software works in multiple languages. Software updates are seamless, because it is web based. Housekeeping could carry around a tablet pc or iPod touch and update their room list. Guests could check out from their tv or laptop. The list goes on and on. It may seem like a pipe dream, but I think it is a possibility especially as we are reaching the age of ubiquitous internet connectivity.

From a software company stand point I think there is demand for such a service. It might be a long long time before a large hotel company would make the switch but there are so many independent and small hotels for which this service would be a blessing. In addition, if the service was successful the access to data would be invaluable.”

I thought the question was a good one and the desires well stated. So the question stands to why are there not more SaaS applications for hotel/resorts?

In my experience the main reason has been a data access issue. For pure web based applications the data is held (and often owned) by the vendor. Data security standards and PCI regulations make it difficult for vendors to effectively and affordably deliver on the needs of a hotel/resort. PMS, POS, and GDS solutions are generally considered mission critical to the business. If you don’t have immediate access to the data then you cannot run your business successfully which often means inconveniencing the guest. And unless a company like Google with an almost infinite budget for infrastructure redundancy and fail-over brings a solution to the table the costs of effectively delivering a solution like this appears to be too high for a start-up looking at what is really a limited market (unless some of the larger brands like Hyatt, Hilton, and Marriott joined in).

Ultimately I hope I’m wrong because I believe we need this. A corollary could be made to what people thought about CRM solutions until Salesforce.com rocketed to uber-status of success and took over that space as the darling of the market.

If you know of a SaaS POS, PMS, GDS or other hospitality technology solution leave a comment as I’d be interested to find out more about them. Or if you have other thoughts on this topic post a comment and share your wisdom.

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 two

This is the second post in a three part series on enterprise software solutions.
If you have not read part one you can see it here.

build your requirements document.
You’ve made it this far, so now it’s time to dive deep into the viability and validity of your prospective solutions. For venues implementing a standard technology system this could be the normal RFP process that is common (read more below why I do not like RFPs). But if you are implementing a large scale enterprise system, specifically with multiple vendors, it is now time to discover how well you did your leg work and if all your prospective vendors were completely honest with you through the early discussions.

Most venues, with the possible help of a consultant, will build a very long and wordy RFP. That RFP will be sent to all prospective vendors with a timeline for completion. I recommend to avoid this process. The venue or consultant will spend hours and dollars building a thorough RFP. When prospective vendors receive it, they filter it through a process where it first goes to a marketing person that generally has minimal knowledgeable of what the system can and cannot do. This person reviews the questions and pulls answers from previous RFPs or from an RFP Library that has been built over time. Any questions that do not have standard answers will then be delegated out to prospective parties for answers.

When all questions are answered the RFP will be sent through a sales or marketing resource that reviews it to ensure there are no answers that will prevent the vendor from getting further into the sale. For answers that are obvious disqualifiers careful wording will be used to ensure ambiguity. I am not saying this is all vendors, but I have never found one that did not word answers to their benefit.

My recommendation rather is to build a Requirements Document. This is a table of features that compiled based on research of both technical and operational requirements. From the work you have already done it should be simpler (though not quick) to build this. Group features logically, but only you should know at this point which are required, highly desirable, or nice to have (this helps you get an unfiltered response from the vendor). Your goal is to have “Yes” or “No” answers. Avoid wording where “Yes, but…” could be used as a response.

An example of why I like a Requirements Document versus an RFP is outlined below using a common POS function.

An RFP might say, “Please outline how your system handles transferred checks between employees and how revenue is tracked.” This is not a bad question, but allows for all kinds of interpretation. A Requirements Document has a list of features associated with transferring a check:

• A check can be transferred from one employee to another by a manager at the POS terminal with employees present.
• A check can be transferred from one employee to another by a manager at the POS terminal without employee present.
• Ownership of a check can be transferred by the current owner to another employee without manager intervention.
• Ownership of a check can be transferred by the current owner to another employee with manager intervention.
• Ownership of a check can be transferred by the receiving employee pulling it from the current check owner with manager intervention.
• Ownership of a check can be transferred by the receiving employee pulling it from the current check owner without manager intervention.
• Revenue associated with a transferred check is always assigned to the employee that owns the check at tender.
• A check can be transferred from one revenue location to another after items have been added to the check and saved.
• Revenue from a check that is transferred will be associated with the revenue center that the check is closed in.

It should be immediately apparent that this will be time intensive process. But if you compare this upfront time against reading all the vendor responses and figuring out which vendor has what you want based on those responses my experience is this is a better process.

When you get your Requirements Document back from each vendor you can quickly create a single table with all responses and have a simplistic view of which vendor(s) best meet your need. I’m going to end this section here to avoid a detailed post on the system evaluation and selection process. It is more commonly understood, but I may cover the process in a future post. You can email me if you have a specific question on how to build a Requirements Document.

build a lab.
Making the assumption that you have made your vendor selection(s) and are ready for install, it is time to move to implementation phase. But before you jump directly into the deep end and install your enterprise solution(s), you best bet is to build a lab. For clarity, I am referring a test system to prove the viability of your selection(s). Your lab system should mimic your planned production environment as closely as possible, taking into consideration hardware requirements, network setup (i.e. VPN, LAN/WAN/VLAN, dial-up, etc.), and interfaces. The one exception to this is if you selected a hosted solution. When possible have the lab installed at your location. Hosted labs generally come with limitations that will prevent you from having control over testing and timeline.

The lab step is critical to your success and control in the contract process as well. You may be asking, “How does a lab affect the contract?” Your contract at this point should be specifically for the lab. This type of contract is common, but many vendors do not offer this direction because it increases the sales cycle and increases the risk of having to commit to features in a final contract. So your contract at this point needs to be solely for a lab. However, make sure you have wording in this contract to not pay for software licenses twice. Negotiate to pay for software licenses only in the production system. You should however purchase a support contract for both your lab and production environment so you have full technical support of your lab.

An important point not miss is your lab needs to include all the enterprise systems you are installing. This was the reason for diagramming interface points and system architecture early in the process, ensuring interface functionality meets your requirements. During this process document the installation and configuration step of each solution for production implementation. This will save you time and headache when your business is dependent on getting in right he first time. Another benefit to building a lab.

In short there are two main reasons to implement a lab.

1. Ensure the enterprise solutions you are implementing will interface smoothly based on your operations and requirements.
2. Discover any feature gaps that must be resolved before moving into production. Generally you will find these, and you want to find them now versus in production.

From this information you should now be able to make a final decision if you can move forward with the vendors you have selected. Part 3 of this topic will review documenting feature development requirements, contract language, and implementing your enterprise software project.

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.