Lab Pilot Programs

Lab Program

The Lab evaluation is critical to the overall success of the project. As such, it represents the greatest single opportunity to create friction or overall failure. The entire process up until this point is designed to provide the committee sufficient information, from initial interviews of the functional business units, through the actual RFP submission and subsequent product demonstrations, all the way to the selection of the final vendor, to create the “success criteria.” These criteria should be prioritized and transparently evaluated through the Lab phase of the project.

SUCCESS CRITERIA

Mutually agree with selected vendor(s) on the success criteria and sign off. Success criteria should be weighed/prioritized, since no single system/solution will ever accomplish everything for everyone.

LAB ACCURACY

Lab should fully represent the most common environment/ecosystem, representative of the actual live Pilot to follow. This includes an accurate number of POS terminals, printers, KDS, OCBs, payment terminals, etc., all connected to the same network (and appliances) as the Pilot location, with functional integration partners integrated and sharing data.

UNIFORMITY

Arrange a heavily scripted, uniform process for internal demos to judge success against prioritized requirements.

SCORING

After evaluating, apply predetermined weighting to criteria in order to create a scorecard for stakeholders to validate/ choose a final solution to enter Pilot.

NOTE: There is always some portion of the Lab that cannot fully replicate the solution, until the ecosystem is recreated in a full production environment; however, as much testing as possible should be done in this demo/test environment.

Lab & Pilot Programs

Pilot Program

Both the Lab and the Pilot phases will be somewhat fluid, as inevitably some thing(s) will be unearthed that may present as gaps critical to the next stage. These will need to be triaged, scoped, prioritized, and potentially delivered before the next stage of the process can be met. Being a partner to one another is extremely important. The give and take nature of this stage is extremely critical for the long-term relationship and success of the project.

LOCATION

The best practice is to use the exact same physical ecosystem evaluated during the Lab in the Pilot location (whenever possible).

The Pilot location should be relatively easy for stakeholders to visit.

Immediately replace the Lab, as one should always have a fully functioning and storerepresentative Lab of whatever technology being evaluating or used in the field.

Choosing the proper Pilot location(s) is extremely important, as there will inevitably be some growing pains, or outright frustration, experienced with entirely new system implementations.

STAFF

The Pilot should have a very strong, yet malleable, operational staff, and should neither be the busiest, nor least busy location across the chain.

All users at the Pilot location should be made aware of the project and the reasons for the project, success criteria, & process for validation of the Lab.

Whenever possible, train Pilot location staff on the Lab system prior to implementation.

TIMELINE

Typically 4-8 weeks • Consider your business cycles, e.g. payroll (weekly, biweekly, monthly) and accounting/ financial periods (monthly, 4-4-5). • You may want to include multiple payroll cycles and/or period ends in the process, just so all manager and related business unit processes can be completed more than once.

MANAGING COSTS

• Lab and pilot costs should be accounted for, as once the system goes “live” the all-in costs associated with getting the first store live will be a multiple of the next, etc.

HARDWARE

• Develop a sample restaurant configuration for your concept and have the vendor price it out, or pick a specific location. • Make sure to include everything required to run the POS system (terminals, printers, PCs, networking equipment, KDS, scanners, etc).

The vendor can be of significant help here. • If you’re replacing piece-for-piece, costs can be straightforward; if you’re changing the configuration or adding/deleting technologies, it can become significantly more complex. • Does your vendor provide all the required equipment or will there be some third-party components? If so, make sure those costs are considered and factored in.

SOFTWARE

• Obtain a price from the vendor for your sample restaurant configuration and/or specifics using an existing location. • Will software be a one-time purchase or a recurring cost?

SUPPORT

• Are you supporting the product in-house, outsourcing or some mix? • Get costs for support that fit your concept style. (Example: If you’re open 24/7 you may need support that is always available.) • Consider third-party support options. • Consider companies that support specific

POS brands very well, and ask if they provide varying options outside of what the POS vendor offers.

TRAINING AND/OR GO-LIVE SUPPORT

• Think about the implementation/conversion process, and plan for training restaurant staff, managers and above-store support personnel. • Consider a “Training the Trainer” model as a significant cost-saver. If you have someone inside your organization who can learn the process from the vendor, then train your staff.

INTEGRATION

• Often overlooked is what it costs for your existing integrations to work with your new POS. What additional costs are required to reconfigure your credit cards, gift cards, loyalty, online ordering, above-store reporting systems, etc.? • Obtain costs (if any) from all your existing or new vendor partners, and ask yourself if there may be any miscellaneous costs involved.