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.