Choosing Itasca
What was the biggest hesitancy for your customers to implement Magic?
Once it's decided there is indeed a problem that the system can solve, it's often the resources they currently have to deploy or the other projects they have in queue. Once all the important features and benefits of the system are understood, it's rarely any particular item on the Itasca side that is of concern.
We don’t have an OOS problem. How else can Magic benefit us?
There are many, many ways a Magic implementation can benefit retailers.
Reduction of overall inventory - Many of you are over-stocked, and for good reason: You don't want to EVER lose a sale do to an out-of-stock condition. The easiest way to avoid that phenomena is to make sure there is plenty of stock on the shelves, and often in the back-room. However, the ONLY inventory needed is that which will satisfy demand between now and the next time that product is due to be delivered to the store - plus a certain amount to cover for error and for a desired presentation look-and-feel. Anything else is unnecessary and profit-draining. True excess inventory (as defined above) also causes additional touches by store personnel which increases cost and introduces potential damage to the situation. Further, product stored in back-rooms is subject to heat, cold, and other damage possibilities from just being "in-the-way." This certainly applies to DSD vendors who often stock-pile sold inventory in back-rooms to benefit their monthly sales.
Eliminating inventory cost on your books - Magic™ realized goal is to have most inventory go directly from the delivery truck/dock to the shelf, meaning that it's only touched once by an in-store associate before the customer removes it for purchase. Significant cost is eliminated when just this happens. Consider, though, based upon how long you as the retailer take possession of the product from the vendor/supplier, BEFORE you've paid for it on your terms, through to selling it and getting paid almost immediately from the shopper, that you might not actually have an inventory figure on your balance sheet. We casually refer to this as "not having to pay for inventory - again." Several of our retailers have been able to achieve this with little to no adjustment of their current terms to the supplier community. Imagine the impact to profitability you might experience in this environment.
Sending orders directly to suppliers - Itasca's system produces what's called a "forecasted order" which is an actual order for a day in the future. It's used at its most elementary level for back-up purposes in the event connectivity from any store drops and an order is due. If that, the order for that day (given that some things because it's a future order were estimated) had already been produced and stored in our Central Data Server module and can be sent to the supplier as-is. An even more creative use of these orders us to send them directly to the supplier and have the supplier fulfill them as their current order. This can be taken even further to have the supplier pack the items by-store (as the orders originate by-store and can be transmitted that way) and ship to a distribution-center for cross-docking to the stores. One Itasca customer implemented this and added 5 shelf days to bagged salad SKU's.
Contact us for more examples. While the space here is unlimited, having a live conversation with you about this particular facet of our extended capabilities is warranted.
We have competitive solution today. Can we leverage off of the integrations & extractions we currently have in-place?
As a 2nd generation CGO application, retailers have been able to leverage off experience with other 1st generation solutions - whether they were developed internally or sourced from a solution vendor. Almost 50% of our new customers have had legacy systems and, together with them, have utilized the work/integration that they already have in place. If that's you, we'll likely have a good amount of previously implemented structure to work with and we'll figure that out early on in the project.
Is pricing a subscription or perpetual license?
In order to experience the lowest total cost of ownership, Itasca believes that you should be able to completely own the software application(s) you purchase from us. Therefore, the solution you get from us is procured via a traditional, perpetual software license. With that, you'll pay only a small percentage yearly of the total software license fee each year in "maintenance" which covers all upgrades, support, and fixes that everyone receives (special projects or requests are performed with specific Statements of Work priced accordingly). This pricing structure gives you the most impactful ROI for the entire project.
Is the system cloud-based or on-site?
Both.
Here's what we mean:
Magic™ requires a separate database for EACH STORE. Why? Because each store is, by definition, different. While there are many similarities, the differences have such an impact that "rolling-up" individual store data would work to cloud-over things that need to be considered from an ordering perspective. To wit, Store 1 has a two-case pack out for Del Monte™ Green Beans, but because of a pillar in this area in Store 2, only one case will fit on the shelf. Since shelf capacity is an important order quantity consideration, having one "central" record for this item would serve to have either too much (Store 2) or not enough (Store 1) inventory…perpetually. These databases can exist ANYWHERE; they could be on a PC (yes, PC…not server) in each store, contained on servers in a server farm and accessed virtually (given subsecond hand-held response time over network connectivity), and other deployment formats.
Another reason to say "both" points to a hybrid architecture comprised of the store-level databases COMBINED with our Central Data Server (CDS) module (included in price) which is a central location for storage of chosen store-level data. One of the main functions is to centralize orders as appropriate (usually called an Order Well) before sending to suppliers. Another is to send appropriate information from stores to financial systems. The data sent to CDS is configurable both by element and by timing. These important decisions are made as part of the Implementation Process.
Who are your biggest competitors?
Itasca's unique approach to solving the inventory management problems makes this a more difficult answer than might be perceived. While there are others in the industry who have solutions that are similar, it's difficult to put us all in the same bucket.
For example, some organizations that might be mentioned (maybe because they have forecasting capability), are better classified as "planning" systems. Just because one can generate a forecast, doesn't necessarily mean it can be used in an operational area for "execution." Itasca is an execution system which means that all the science can be used in the actual activity the system is designed to assist with.
We have been heard to say often that if one of our competitors is trying to get the same customer as we are, one of us is in the wrong place because the customer hasn't articulated their requirement very well.
How did the DSD vendor community accept the orders from the stores? Did any pushback exist?
As it is with any change in the current process or status quo, there can always be some that resist the changes, often because it takes away a level of control of the process that was once had. In this case, in talking to our customers who have implemented DSD ordering, there was an element of this, but once the vendors saw that the orders were truly accurate and that the demand signals were driving the orders, they truly understood the benefits.
- We had several DSD vendors at our bi-annual User Conference this year and they told our attendees that after the first few speedbumps and push-backs, their driver community had embraced it completely.
- Customers who have implemented ordering in DSD categories utilize a common best practice when vendors disagree with the order quantity. Since arbitrary order adjustment often causes other problems, they want vendors to trust the orders as they are. So, unless there's a blatant error in the Perpetual Inventory (one of the main reasons order quantities are "off"), the order stands. In order to verify, and to possibly prove to the store that it needs additional supply, they are given a handheld device to go and check the counts. If there is a discrepancy, they do a count update and re-run the order.
How long does it take to implement Magic?
Very often, this is an "it depends" question, and we're not trying to be evasive. The areas of "it depends" that can shorten or lengthen the time-frame are things like knowledge of locations of required data by client IT/data teams (this is a big one), IT resource availability, executive buy-in and prioritization, prior experience with a CGO application, other pertinent and competing activities (i.e. new store opening(s), other IT projects). This is certainly not an all-encompassing list.
Implementation
What programs do you offer to help us train our staff?
We have a robust training program developed by a highly experienced instructional designer with MS, SPHR certifications who will be easily engaged during the implementation. Our training media (documents, videos, system-spoken help, on-line help, etc.) have been designed by industry training design professionals. These items are deployed via our Training and Project Managers to the training team members designated by the retailer and are customized to that retailer's specifications. There are some things that are usable at all retailers, but for those that aren't, we customize each training object so trainees can take the information directly from the classroom to their daily job.
Who does the project management? We want to get started, but we don't have any IT resources free right now. Can you help?
This is determined up-front as Itasca offers fee-based Program and Project Management resources to anyone for any reason. While it's preferable to engage our resources to an existing PM Office at the retailer, we can certainly apply our resources to a project. There are still tasks that Itasca (or even third parties brought on) isn't able to perform due to security or knowledge concerns (i.e. data gathering), and there our experience and counsel often suffices.
Who does the integration work?
It's a collaborative process. However, for the most part, the integration tasks are best done by you, the retailer, as you know your systems best, but we are deeply involved in the process throughout and can often assist in some of the work itself. Also, depending upon the system(s) involved on your end, we can likely work with you directly to build what's appropriate. In addition, we have access and relationships with third-party organizations and individuals who have expertise engineering these interfaces and can easily bring them to the project.
What POS systems have you worked with?
The system is designed to work with all of the major and minor POS systems currently deployed in the grocery industry, and with our current customer-base, we've been able to verify and certify those POS systems with our application. Where we haven't worked directly with the retailer's specific system, a short certification process takes place and includes the expertise of the Itasca development team who, as of yet, has not been able to secure direct integration with any POS system currently in-place. In short, this question has not delayed or stopped any implementation.
How long does it take to implement Magic?
Very often, this is an "it depends" question, and we're not trying to be evasive. The areas of "it depends" that can shorten or lengthen the time-frame are things like knowledge of locations of required data by client IT/data teams (this is a big one), IT resource availability, executive buy-in and prioritization, prior experience with a CGO application, other pertinent and competing activities (i.e. new store opening(s), other IT projects). This is certainly not an all-encompassing list.
Current Customers
Can we talk to any of your customers?
We can arrange a formal call or visit with any of our customers. We have found that it's beneficial to align the customer visited as best as possible with your business model and go-to-market strategy so questions and methodologies employed have the most impact with each entity. Of course, relationships exist in our industry and if you have one or more, feel free to reach out to those with whom you maintain contact.
What other things/projects has Magic spawned or solved within any of your current customers?
There are many, probably too many to adequately cover them all here. But, often one of the first things that becomes obvious to the retailer is that the fundamental data their business runs on could use a deep "spring-cleaning." This certainly helps our systems function at their best, but it also tends to make the retailer much more efficient in other areas of their business.
One specific example is in the area of upstream supply chain activity. Itasca customers have been able to provide store-based orders to suppliers who have agreed to pack and ship those orders by-store which doesn't then require a stop inside of the retailer's DC but instead can cross-dock or drop-ship directly to store. We've seen shelf-day savings of up to 5 days!
Additionally, one of the most easily connected additional applications or projects is that of DSD Receiving. Most retailers have current functionality in this area, but often it's in a disconnected application. Our class-leading application is used in many Top 100 grocery retailers today as it arose from the Softechnics company in the early 2000's. That application was written by our development team, and that same team built the current form that we bundle with CGO often. Since this is an optional module, it can be licensed separately. However, when this module is deployed with Magic ™ CGO, there are multiple synergies. One that makes it simple to install is that it utilizes the same database as Magic ™, so the data will always be in-sync.
Which of your customers has been with you the longest?
Price Chopper/Market 32, stores owned by Golub Corporation, first became an Itasca customer in 2003. The continue to be an excellent reference for our capabilities and utilize the system for all of their ordering needs, including DSD and production departments.
Do you have a User Group community?
Yes!
It even has a name: "Experts Learn From Experts". We get together bi-annually in iconic locations in the US. Our first was in September, 2016 in Phoenix at the Camby Hotel in Central Phoenix. In 2018, we met at the beautiful Belmond Hotel in historic downtown Charleston, SC. We'll get-together again in the Fall of 2020. In between, we host multiple electronic sessions where Itasca team members present a topic customers have raised to benefit the rest of our clients.
As the name suggests, the time of the conference is set-up so that there are some presentations from Itasca and our partners, but much of the time is reserved for clients to speak on things within their Magic™ projects that they've been successful with or that they learned. We've found that hearing from peers, and being able to ask questions of them, serves as one of the best ways to learn new things in the Magic™ world. We also bring in outside partners or industry experts to speak on topics pertinent to the audience.
Forecasting – Data
Can Magic data/orders be used with manufacturers?
Yes. Magic™ produces "Forecasted Orders" which are actual orders (see above on Forecast vs. Order) with the difference being they are in the future. So, a Forecasted Order uses current information combined with predicted information to derive the most accurate future order possible. These "orders" are automatically stored in our Central Data Server location, usually in a HQ-based server, and can be used if store connectivity goes down. They can also be sent directly to suppliers as advanced notice of store-level demand. We have a customer using them for the packing of store-level orders for fresh product directly at the product origin - this saved 5 shelf days in the products' logistics.
How accurate is your forecast? To what statistical level?
This is an interesting question, and once all the particulars are internalized well, this question becomes almost moot for several reasons. Forecasts are, by definition, always INNACURATE, because even the best, most accurate forecasts aren't 100% correct, 100% of the time. So the question becomes: How can we minimize the error rate considering all factors? We are afforded a bit of a reprieve here in that our forecast (and really the order itself) only have to be as accurate as a case-pack: the smaller the case-pack, the closer to the actual unit forecast the better. But in the case of the 12 unit case-pack, if the order is "off" by one or two, it's still within the quantity of the case-pack, and we likely would have ordered another case anyway.
What’s the difference between a “forecast” and an “order?”
A forecast is simply the anticipated number of units that will be sold, during a very specific period of time. It is input to the algorithm and actual order that is sent to the vendor.
An order is the amount of product, rounded to the case pack for the product in question, that will be requested from the appropriate supplier. It considers such important factors as Consumer Demand (the Forecast described above), Current On-Hand, Current On-Order, Anticipated OOS (if applicable), Propensity of creating an OOS by NOT ordering compared to the propensity of creating back-stock by ordering.
How do you consider seasonality in your predictions?
Yes. Seasonality must be considered, but it might not be how you think it would be. Too much leveraging of the previous year's data to predict this years can be fraught with error.
Said a different way, "Last year's data is so, well, 'last year.'"
This is because so many things differ from one year to another: some Holiday dates change; multiple products exit, enter and change packaging; prices change; trends begin and end; etc. So, Itasca employs a fast-reacting algorithm to understand the true demand impact of new and changed items as quickly as possible which reflects the most current activity and enables the CURRENT seasonality to be appropriately considered. In addition, we derive from history and ask merchants to verify a list of items that have unique behavior in relation to a particular Holiday. Great examples of these types of items are whole fresh turkeys, cranberry sauce, pumpkin pie filling and stuffing at Thanksgiving time. These items have uncommon sales levels (compared to regular day-to-day sales) leading up to the date, and then drop to almost nothing from then on. The challenge then for an inventory system is to have enough stock to meet demand in the lead-up, but then be back to normal levels so that multiple cases or pallets aren't left in the stock-room, potentially there until the next Holiday. With this list and the historical information, we can accurately predict demand and stock-levels pre-Holiday, and know when to slow-down and then stop further ordering to meet the "normal" day-to-day needs post-Holiday.
Infrastructure
What handheld gear do you support?
All legacy Windows CE devices from the major manufacturers and Android devices from Version 5 forward of Android OS.
We will certify and support all Android OS's going-forward. And, with the recent introduction of iOS support, you don't have to worry that you can't use any of your current gear with Magic™. Further, you can "mix" device manufacturers and OS's in a store. Test a new manufacturer, device or OS without issue at any time.
| Windows Mobile 5 - 6.5 | |
| Zebra | MC9000, 9100, 9200 |
| Honeywell | 7000, 9000 |
| Datalogic | Falcon X3 |
| Win CE 4.2, 5 | |
| Motorola | MC9000 Series |
| Android 5 (Lollipop) and up | |
| Zebra | TC51/56, 52/56, 72/77; MC3200, MC3300, MC9200 |
| Honeywell | CT50, CT60, CN80 |
| Datalogic | Joya Touch A6 |
| CipherLab | RK25 |
| Apple iOS | iPad Mini. iPad, iPad Pro, iPhone |