sweating the small stuff – part one (automated inventory depletion)

For whatever reason when revenue is up venues have the tendency to not sweat the small stuff.  I guess it’s because the small stuff doesn’t amount to much when focusing on the big investments.  But when revenue is down it’s time to look closely at where your staff is spending their valuable time.

The next few posts will be dedicated to the “small stuff”.  Each has a minimal time and dollar investment with a quick ROI.

automated product/item depletion

Manually entering inventory depletion should only be necessary if you don’t have a PC based POS solution (and even then it may not be required).  If you do have a PC based POS solution (and who doesn’t at this point) then now is the time to link the two system.

A basic overview of this interface is the POS system exports a text file (formats can vary) of product/item depletion.  This file is then used by the inventory management system to decrement inventory amounts.  A key prerequisite is a “Common Numeric Identifier” for each product/item that is shared; this is generally the SKU number.  Chances are good the vendors you use already have a functional interface, and it’s highly possible getting it turned on won’t cost you anything (except maybe vendor support fees).  If your vendors do not have an established interface you have a few options

option one
The first option is to work with one of your vendors to write a utility that meets the specifications of the other vendor.  For example, your POS vendor writes an export utility that produces a file matching the import specifications of your inventory control vendor.  Or, the inventory control vendor writes an import utility that uses the file format provided by the POS system.  Most vendors have vast experience with this option, as it is the most common and generally preferred solution  But, the price of this method can vary drastically among vendors.

Pros:  vendor supported interface, highly scalable for large volumes of data
Cons:  vendor may charge high price for development, any future changes to the interface require vendor time line

option two
The second option is to use a middle-ware utility to convert the standard POS export format to the standard import format for the Inventory Control system.  There is a multitude of middle-ware applications available allowing someone with development experience to accomplish this.  They range from free-ware applications to highly scalable solutions like Microsoft Biztalk.  Be careful however as the price of this option can unexpectedly creep as interface iterations spiral out of control.  The advantage is the opportunity to use the middle-ware application for other integration projects.  The important point here is data mapping.  Incorrect data mapping will lead to incorrect inventory depletion.

Pros:  scalable for large volumes of data, use middle-ware software for additional interface engines
Cons:  requires development experience, possible high cost of software and development

option three
The third option is to build a conversion utility with scripts, macros, and/or batch files. This process generally involves utilizing MS Excel and Visual Basic for Applications (VBA).  I would only recommend this option when working with small volumes of data (no more than few hundred lines of data per executed export file) and when manual validation of the process regularly can be performed.  Most IT resources (especially if they are a recent graduate with an computer related degree) have the experience necessary to build these utilities.  The important piece here again is data mapping.  Incorrect data mapping will lead to problematic inventory depletion errors and generally non-descriptive and unhelpful error messages produced by Microsoft.

Pros: internally owned, can quickly be implemented, low cost investment
Cons:  internally owned (yes it can be both), not scalable for large volume of data, high chance of failure

reviewing your ROI
To calculate your ROI estimate how much time is spent reviewing sales and product mix reports and how much time is spent entering depletion into the inventory system.  For convenience use monthly estimates.   Next, calculate the Estimated Monthly Task Cost of this process using the hourly rate of employee(s) performing the task.

Estimated Monthly Task Cost = (time reviewing reports  X  hourly rate) + (data entry time  X  hourly rate)

Based on which of the three options you choose to implement calculate the Total Project Cost.  If your vendor charges a recurring support fee for the interface in Option One, don’t forget to include that in the Total Project Cost.  Also, if you choose Option Two and pay for a recurring support fee for a middle-ware application don’t forget to include that in the Total Project Cost. (If you plan on using it for additional projects you may want to only include a fraction of the support fees.)

ROI = Estimated Monthly Task Cost / Total Project Cost

This is how long in months it will take you to recoup the Total Project Cost, allowing your employee(s) to focus on other revenue generating activities. You may even find your ROI is less than one month!

If you don’t have the experience or time to implement this interface give me a ring, I’d be happy to help!   But don’t forget to include the cost of the consultant in your Total Project Cost.

If you are wondering about an integration capability post a comment and I’ll cover the details in a future post.  Even if you think it is probably not possible, it may be.  I’ve seen a parking garage gate interfaced to the POS cash drawer…so almost anything is possible.

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

the attractive but un-sexy side of BI

I had a wonderful opportunity recently to join some very smart colleagues on a BI (Business Intelligence) panel presentation. I first need to thank Jon Inge for inviting me to be on the panel and for being an advocate for the un-sexy side of BI. Second I need to thank Rick Heuer, Geert Mol, and Clive Perry-Core who were on the panel with me. I learned a ton about CRM BI from Rick and Geert, and Clive has more hands-on experience to the nuts and bolts of BI than anyone I’ve ever met. It ended up as more of a round-table discussion than a panel really, but it was great for my own learning opportunities that way.

In his opening Jon referenced a great article from the Wall Street Journal on “Knowledge Management” which is largely what BI is all about. (Which I was bummed to not find on the web and provide as a link to all of you. If you find it give me the link in a comment.) The opportunity benefit of BI is to effectively act on meaningful information about your business…or more briefly put knowledge management.

During the introduction of the panel each panelists described how they worked in BI. During this brief introduction I came to the sad realization that I specialize in “un-sexy” BI. The “sexy” side of BI is in CRM and marketing. Their personal introductions were exciting and I’m sure led to everyone dreaming about a hotel knowing you when you walk in the door, welcome you by name, hand you your favorite margarita, quickly tele-port you to your room with pre-set temperature and lighting preferences, and have music playing based on your perceived mood and core body temperature. It is what you read about in press releases from the big brands in the industry where they know everything about what the customer prefers. The summation is Know your guest and achieve total patron value! Increase revenue through understanding your guest’s preferences and market directly to them! Sexy No? (to be said in a French accent)

For the record I totally agree it is way more fun to talk and dream about the benefits of BI with CRM. But the reality is the ROI and TCO for BI with CRM is harder to quantify (I tried hard to get a fifth acronym in that sentence but I couldn’t find one that made sense. Though I digress). It is not impossible to quantify, just harder. Before I jump into the “attractive but un-sexy” side of BI I think it is important to lay some foundation. First let’s take a shot at defining TCO. Total Cost of Ownership (TCO) is the total investment capitol put into the technology solution over a specified period of time. Return on Investment (ROI) is the duration it takes for decrease in costs and/or increase in revenues to surpass the overall investment (or TCO). To put simply, save or make more money than what you spent within a specific time period. The measure of any good technology solution should be create cheaper, faster, and better operations than what you do now. The general problem with proving the ROI of BI with CRM is the generalizations that take place into why certain customer preferences exist and under what specific set of circumstances. It is the accurate capture of circumstances that really creates the challenge. It is difficult (not impossible) to tie a decrease in cost or more likely and increase in revenue to a specific preference or area of guest behavior being influenced by an almost infinite number of inputs (aka circumstances) that lead to a specific action (for more thoughts on this see when CRM will achieve its potential).

So if BI with CRM and market data is “sexy” then the operational analysis side is really the “un-sexy”. Note that both are attractive, but the former is far more attractive than the latter.

The un-sexy side is the analysis of your operational systems data in order to decrease costs and increase revenues (yawn). I’ll define operational systems as Property Management System (PMS), Point of Sale (POS), inventory management, time and attendance, service optimization, and other solutions implemented to manage the operations of a venue. See, I’m only two sentences into the “un-sexy” and you’re mind is already wandering…hmmm..what should I have for lunch today…

But, when this data is captured in a meaningful way and linked to other external data elements (i.e. weather, currency exchange rate, website click through, etc.) the value proposition of BI becomes very attractive. I’m going to say “becomes” attractive because generally the first thing that a BI system shows you is how poorly your systems are currently setup to capture meaningful data. You will need to spend at least three to six months cleaning up configuration elements of your existing system(s) before BI will begin to have analytical payoff. The correlation can be made that it’s like exercise for your technology solutions. You may hate the process but you’ll like the results. I’ll cover some thoughts on the steps to a successful BI installation in a future post. But for those in need of immediate gratification Jon Inge wrote a great article in this months Hospitality Upgrade (it’s free by the way…so subscribe) entitled Demystifying Business Intelligence. You can download the article here from Jon’s website.

As an exercise in brain storming here are a few examples of how to both define and achieve ROI for your BI solution. I am making a HUGE assumption here that you already have some meaningful KPI’s identified for your business and that you can apply them accordingly. If you have not, first go read Jon’s article.

the pms story
A key metric for any hotel/resort is RevPAR (revenue per available room). The value of this KPI becomes more valuable over time as you compare it against historical data. It is one of the measures used for how to price a room and it’s amenities. Some PMS systems will give you this number over a specified date range and may let you compare it to one other range. Or you can run multiple ranges and do the comparison yourself by entering the information into a spreadsheet. But, what if rather than just looking at previous RevPAR numbers you were able to review historical RevPAR numbers with the corresponding temperature/weather and current exchange rates with selected currencies over multiple selected date ranges. Then what if that information could be plotted graphically for you giving you some solid predictive analytics on what room rate would give you the best RevPAR based on matching factors from a historical period. The ROI benefit in this example is actually achieved in more than just the revenue opportunities. It can also be achieved in the “improved costs” column by spending fewer hours entering information into spreadsheets.

the pos story
The POS story I think is one often left behind, but it is one near-and-dear to my heart. Your POS (and PMS) system holds real data about customers that they pay you to keep so you can know more about them. How wonderful is that?! Grocery stores have the POS BI story down…it’s a science of revenue for them. Hotels, resorts, and other venues should be watching and learning from their successes and their mistakes. As a quick story lets meander into a world where all your POS data means something (meaning versus what you have now). It means what do your customers like, what do they not like, and what should they like but just are not finding and buying. By “should they like” I’m referring to placement, description of the item, presentation on the plate, verbal marketing, and price. BI with POS allows a manager or chef to aggregate and compare data for items that are selling well to items that are not selling well, and possibly against the day of the week, time of the day, and temperature outside.

the inventory management story
You get an even better story if you tie POS to Inventory Management and look at actual cost versus selling price data. A manager can run pricing strategies and get concrete data back on how well or poorly it worked. For example, take your top 10 selling entree items and increase the price of each of them by 5%. If you have historical price and cost for those items for the previous three months you should have food costs, theoretical and actual yields, margin, and profit for those items. Track on a weekly basis for three months how the 5% price increase affects each of those performance monitors and you begin to understand exactly how much items should be priced for in order to achieve minimum food costs, maximum margins, and maximum profits. You may tell me you can do this now, but I’m going to tell you only with a small troop of analysts and well massaged data.

the employee performance story
Wouldn’t it be great to have a better understanding of what made great employees great, good employees good, and poor employees…well…suck? I’m sure you can tell me about personal drive and character and customer relation skills and I’ll agree with you. But what if you could see metrics about employees like how many more transactions they perform, or how efficient they are in certain work areas, or why they are always able to predict what needs to be done before it needs to be done (okay…that one may be harder to figure out). Again, manufacturing plants have been dong this for years…we just have to catch up and figure out how to make it work for hospitality A BI solution should have all the data points where an employee enters information into your technology solutions, and that transaction is tied to an employee ID. Employee ID is often the ONLY common thread among disparate technology solutions so this specific area can be one of the easiest to achieve. The benefit of seeing performance information on your performance range of employees is to spot operational efficiencies that great employees implement and then work to train those into the rest of the staff.

If you are shaking your head at me saying, “Employees won’t do it even if I show them how to be better”, then I’m going to tell you that you have bigger problems. Employees suck either because of lack of education or apathy. BI can help you fix the education part and then you can help yourself and fire the apathy part.

the staff management story
The last story we’ll weave is the magic tricks around staff management. I never ceased to be amazed at the creative processes that I find managers and client venues using to estimate staffing requirements and build employee schedules. It is an artful guessing game made more accurate after years of experience and some trial and error. But if you have employees entering information for time and attendance (if you pay people you have this I think), and you have historical revenue information (for a specific day of the year possibly for multiple years), and you have employee performance detail (for example revenue per hour) for a “good” employee then you could have the best staff management procedures on the planet based on BI data and predictive modeling. Bringing this information together into a BI solution gives you forecasted revenue expectations with forecasted costs for which you can then effectively manage your schedule and get maximum revenue potential at minimum cost from your staff. I have a dream….

See, you find it attractive…admit it. But (yawn) sooo un-sexy. Who wants to talk about boring operational efficiency metrics to executive management so you can purchase a BI solution? I hope you.

I would love to hear from you if you have other great examples of ways you achieved the ROI of your BI solution. I’d also like to hear from you if you think mine are ridiculous. And as always, if you’d like to find out more about kevin sturm Consulting please visit my website or email me.

apathy = a problem technology cannot solve

I am a big believer that technology can solve many business and operational problems. There is POS for tracking product mix, streamlining order flow, and revenue reporting; Inventory Management for getting accurate food costs, purchasing cycles, and inventory control; Reservations for managing guest reservations, table turn, and wait times; and a slew of other systems depending on the venue. But for hospitality venues there is a problem that technology solutions cannot solve – mainly apathy or the trait of “learned helplessness.”

Last night my family and some friends went out to dinner at El Paseo restaurant in Santa Barbara. We were doing an early dinner (we had two toddlers in tow) and were glad to see the restaurant was not too busy. We really like El Paseo because of the atmosphere (retractable roof) and good food (our opinion). We LOVE the table-side made guacamole and fresh made warm tortillas, and they usually have a pretty solid margarita. We go enough we know what is good and what is not, so we stick to what is good (like the fajitas). Also an important point is I go there because they are a former customer and I am a firm believer in supporting your customers.

But our experience last night ranks in my top 5 worst at any hospitality venue. I point the cause to apathy on the part of the manager and service staff. I will set the stage as it was immediately apparent El Paseo was understaffed for the night. We were all sensitive to this as my wife and friend both waited tables for years and I have spent hours on end helping restaurant staff work through system technology issues (I bused tables in a suit once at a customer site because that was where I could help ensure the guest’s experience stayed positive). From the moment we walked in the door at El Paseo we were an annoyance versus a guest. I had to find someone to seat us, and once we were seated had to flag down the manager after 15 minutes. We asked the manager if he could bring us water and napkins (napkins came half way through the meal…recall we had two toddlers with us) and requested a waiter to come over. He declined to get us water and replied, “I will find someone to get your drink order.” No apology for the wait or a comment that things might be a little slow.

When our waiter arrived (visibly annoyed we had him summoned) we ordered our drinks, our food (with a one special request), and asked for silverware and napkins. We got three deep sighs and at least four eye rolls. We had been given a kids menu and ordered two kids meals with a lemonade. When our drinks arrived the waiter set a foot-tall-cone-shaped-three-pound-bar-glass filled to top with lemonade in front of our friends 2 year old (no exaggeration!) We asked for kids cup to which he responded they have none (kids menu, kids meals, no kids cup?). We asked if they had a smaller cup, and he came back to the table with a plastic Budweiser cup and no lid (a Bud cup for a toddler?).

We arrived at the restaurant before 6:00 pm and received our food at about 7:00 pm. In that one hour we saw our server once to place our order and once to receive our drinks. We called the manager over twice to ask for more water and napkins, and never once got an apology or a comment on better service. I helped implement El Paseo’s technology solutions so I know their systems cannot be to blame for what we experienced last night. I also know the ownership group and have eaten at their other restaurants in Santa Barbara, so I do not believe it is part of the ownership group. Our experience last night was 100% caused by apathetic management and wait staff. But our experience could have been 100% different with the same staff and same poor service. Here’s how…

roll out the welcome mat
Greet your customer with a smile and welcome them to your venue. Even if the service is going to be below standard you should still make your customer want to be there.

when required set a low expectation
When as a manager or server you know you cannot deliver the best service, be up front with customers and set that expectation. Offer that you will check in as often as possible, but that service may be slower than normal. That way if it is slow the guest expected it, but if it is not you over achieved. Most customers will be accepting of this.

Image credit to Julianfoto

cater to your customer
If you offer a separate kids menu families will come to your restaurant. Parents expect kid cups to be available if you have a kids menu. Not having kids cups is saying you don’t want kids in the restaurant.

apologize when you know you should
You know when you need to apologize for crummy service, even when it’s not your fault. An apology can go a long long way. Everybody has bad days at the office. Apologizing when you flat out do not deliver means you care enough to want to deliver.

If only I could invent a technology solution that solved the apathetic employee problem…

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

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.