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.

first check!

I got my first check for kevin sturm Consulting in the mail on Friday. The first of what I hope will be many...Yeah!

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.

how promotable/marketable are you?

The other morning I was having coffee with my sister-in-law, Cara, discussing her current job opportunities. She is an up and coming tornado at Anthropologie and is now ready for the next big thing. In our conversation we talked about what employees that quickly get promoted do. Obviously there are the qualities of hard work, enthusiasm, knowledge of the business, years of experience, leadership, and such. But in most companies that is not enough, or at least not what is going to get you moving quickly to the next big thing.

In my experience there are a three lesser discussed things that can have a huge impact on your promotability. There are more than three even, but for brevity I'll focus on three.

stop asking what qualities and experience is needed for a promotion
As a manager I had an endless number of conversations with employees who would ask me, "What are the traits you look for in a <fill in the title>?" This is a bad way to approach it. The question worded this way tells the manager you don't believe you are ready for the promotion but would like to be considered at some point in the future.

Instead of asking this question do some research to understand the position that you want and then meet with the manager to inform them that you want the promotion. Point out all the areas that you have the experience, qualifications, and successes to be great at the job. Outline how you specifically could add value to the organization in this new position. Then, if need be discuss what specific areas you need experience in before being qualified for the promotion, and ask the manager what opportunities exist in the near future for you to get the experience needed.
leave your personal finance choices out of the discussion
Most employees seek out a promotion or pay increase because their personal financial situation has changed and they need to make more money. Probably 80% of employees that asked me for a promotion or raise had this as a major point in the discussion. This is about the worst way to go about getting a promotion. It tells your manager you are spending money you don't have! That is a big red flag because it means you may not be as responsible as you should be. Additionally, don't make the focus of your discussion what Salary.com says you should make. Unless you are working for a Fortune 500 company that pays at the top 10% it is not a realistic comparison.

A conversation about compensation and promotion needs to be focused on what you specifically do or will be doing to increase current revenue production for the business. If you don't know how you are doing this, you have no business asking for a promotion.

I once had an employee ask me for a salary increase and promotion with a breakdown of what affect his current salary had on the percentage of gross margin for the department, how his specific performance was increasing company revenue by tracking his revenue performance for 6 months, and that his requested increase would affect less than .1% of current gross margin for the department. He then outlined how he would further increase his revenue production, and how the increase would make him feel more valued for his hard work and his job would be more enjoyable. I gave him the promotion affective immediately, without even getting approval from our CFO. I knew that with that level of detail the CFO couldn't even say no.
stop waiting to get recognized
When I left my last company they asked me to complete an Employee Exit interview. One of the questions was about how often I got feedback from my manager.

How frequently did you get feedback on your performance? What were your feelings about them?
I received feedback almost every year during my normal performance review. I generally found they were informative and provided good feedback and opportunities for improvement.
How frequently did you have discussions with your manager about your career goals? What are your feelings regarding these discussions?
As often as I initiated and felt it was needed. However, I think employees who receive the best feedback seek it out versus wait for it. Generally those who wait patiently for recognition and guidance end up feeling slighted, abused, and unappreciated. I am a firm believer that opportunities are created and taken not given, and corporate recognition is directly related to how well you market yourself.

Recognition in the work place is like dating. If you're a wall flower it's tough to get recognized. If you are waiting for someone to give you pat on the back and a promotion for a job well done, you most likely feel like you work for a company that doesn't reward hard work, you often feel abused by the company, and that the company always says great job to other people but never you (there are companies out there that reward hard work all the time, I worked for one for a while). If this is you, stop waiting to get recognized and point out the value you bring the organization. Most likely the employees that always get recognized are self promoting while you are waiting for someone to notice you.

the freedom to fellowship

One of my favorite things about being self employed is getting to fellowship with friends in the morning over coffee. This morning I got hang with DJ at his SWEET pad in Santa Barbara. This place is seriously amazing because it has a view that is unique even in Santa Barbara. You can see Ventura and north Goleta practically. DJ and I were going to meet at Whales Tail downtown but we decided to have breakfast at the Freedom House instead. Crystal (his personal assistant) made us an amazing breakfast of French toast coated with corn flakes and almonds. It was 5-star style eating, plus we ate on the patio (which DJ had never done!) and had an amazing view to go with the amazing meal. Thanks Crystal! We also had mimosas with Dom Perignon that was left over from a get together the previous night...livin' the high life!DJ and I talked about how much fun it was to be able to just hang out in the morning to do what we felt was important (which may be to work, read, or fellowship) versus rush to be at work at 8:00 am. I really feel so blessed to have the freedom to do this and have friends like DJ to hang with and enjoy time together.

The view from DJ's patio as displayed by my iPhone!

my new experience phone

It was my birthday this past Friday. I turned 32 but I still feel 28. 28 is a good age I think.

My wonderful wife Chrystal (and my parents) surprised me with an iPhone. This is my 3rd PDA phone and it is by far the best. I'm a recent mac convert (switched when they went dual core processor) and I love the experience. Apple knows how to deliver an unparalleled experience.
Thanks sweetie for the best phone ever made!

the challenges for hotels in web 2.0

As a frequent traveler this video makes me want to throw-up. I've stayed at each of these brands multiple times and drank from hotel drinking glasses bunches of times. I'm always a little wary of the bedding and check to ensure it appears clean (I once found dirty underwear in my hotel bed!), but I've never found the glasses to appear dirty.

In the world of Web 2.0 everyone needs to be more diligent regarding the level of service they are providing to their customers. I doubt this news story was some random idea. I'm betting they got tipped off which means management at some level knew it was happening. Web 2.0 technology will continue to be a benefit to hospitality venues when used advantageously, but the true value is yet to be seen.


Never Use the Glasses in your Hotel Room