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.