Inventory Control Experts
Posts Tagged ‘design’
-
Back Office Inventory Features for Version 7
The velocity of new features being shipped in NeXT has really accelerated during the past 3 months. Most of the work has been centered on our Food and Beverage modules, but plenty of features for Retail have shipped as well. Version 7.26.47 was released on Sunday, November 6, 2011. The full scope of Version 7 of DataWorks’ NeXT Back Office Inventory system is massive, but here is the short list of enhancements and features that I wanted to highlight.
Product Form:
- New Wrapper to separately maintain Retail, Food and Supplies Products.
- New Menu to Review Archived Products
- New Lock / Unlock of Cost and Retail Controls
- Standardization of Product Attributes to enable control for Retail, Food, Supplies or Global access.
- Taxable Purchases setup for Supplies
- Catch Weight definition for Food
- Sysco 832 EDI order guide import
- Vendor Product EDI Linking / Unlinking capacity
- Vendor Product to Manufacturer product creation.
-
Talking Points for a Point of Sale Interface to DataWorks
We have been publishing point of sale interface standards for many years. Many POS companies offer a DataWorks interface solution and the initial discussion typically centers around technical details. How will data move around? What hand-shaking mechanism will be used? Most of those technical details are covered here and here.
But what about features that the POS system should have to benefit from DataWorks functionality? That is a question that is a bit prickly because many of our partners are serving the hospitality (restaurant, resort, casino) market, and retail functionality is not what they think, design or dream about.
So beyond the bit and byte facts that DataWorks defines and exports inventory and the POS partner captures and exports sales, here is the list of features that a POS system needs to have to be effective in the mixed venue retail market, where one POS system is used in both the F&B and Retail outlets.
The Bare-Minimum List:
———————
1. Allow for the input of numeric value via a barcode scanner, as an alternative to a touchscreen input or keypad entry.The Basic List:
———————
1. Allow multiple barcodes to be defined for an Item. Typically only two are needed to accommodate the SKU and an optional UPC. In some cases a SKU will have many UPC codes. We have some items that can have more than 50 barcodes – postcards are a great example of this.
2. Allow the same Item to be defined and sold in different outlets.
3. Allow a different Retail Price for the same Item in a different outlet. This needs to handle the geographic borders of currency. DataWorks jumps though the currency hoops. This is important in enterprise systems where one system may be configured to handle multiple outlets.
4. Have a description field that is at least 32 characters long. Allow the description to be individually handled for a preferred language. DataWorks supplies the translated data for the outlet.
5. Provide for a means to define tax rate for each individual item.The Competitive List:
————————
1. Allow a single temporary retail price to be defined separately from the normal retail price with both a start and stop date for the temporary price
2. Allow many temporary retail prices to be defined for a single item. This allows promotions like Halloween, Thanksgiving, Christmas, and After-Christmas to be predefined, rather than waiting for each promotion to finish before the retail manager can define another.
3. Provide a link to a tax look up table per item
4. Provide a quantity discount for an item.
5. Provide a preset discount for a classification of items.
6. Provide a discount for a type of customer.
7. Provide a means to look-up, add, edit and export a customer and attach a customer ID to a sales transaction.
8. Size the POS database to contain an average of 20,000 Items per Outlet, but test for 100,000 active items and 120,000 active barcodes.The Uber Advantage :
————————
Provide the POS system with either: 1) the ability to handle LOTS of data inserts and updates during the course of the operational day or; 2) give the POS the means to share outlet data.Even though we go to great lengths in our above list to define that every outlet needs to be autonomous and capable of individual prices and language, there is the real world need that requires information be available without it being replicated into each outlet. The idea is that similar outlets can share the same information. This is very common in Resort, Casino and Amusement Parks. This is VERY important if you want to be able to accept returned merchandise at any outlet, even though it may not be stocked there.
DataWorks has the ability to replicate data into the individual outlets, but it comes with a burden of having additional processing crunch on the POS application. So this is one of those features that really needs to be designed from the ground up – because it is a data structure issue.
If you already have a POS in the field your best bet is to spend some R&D budget on your inventory import feature – because it needs to be able to process new inventory items very quickly. Don’t think in terms of a total F&B menu of only 1000 items, think in terms of 100-2000 NEW Retail items every day. And then imagine adding those 2000 items during the lunch hour. If your POS system can do that, now you got an Uber-Advantage.
-
SmartSpoke™ Point of Sale Interface
DataWorks has always had interfaces to Point of Sale (POS) systems. Even when we sold our own POS back in the late 1980s and 1990s we had to create a two-way interface to talk to ourselves.
We designed and wrote the mechanics for keeping track of what data changes (deltas) needed to be sent where, we also wrote the communication layer between the back office (HQ) and the POS that delivered the deltas where they needed to be and also engineered the processing of the remote changes into the local data base.
So after 20+ years of writing two-way POS interfaces you would think we would have everything worked out.
Next week (08/09/2010) we ship SmartSpoke™, our fourth-generation point-of-sale interface.
SmartSpoke builds on our tradition of hub and spoke design, but turns the tables on the communication layer. SmartSpoke sits by itself on the POS computer or server. It uses FTPS protocol to pull inventory down from the hub and push sales and customers up to the hub.
Our HQ software — NeXT® — prepares batches of encrypted inventory and price changes that sit behind a secured FTPS server waiting to be picked up by SmartSpoke. NeXT also prowls around its local system seeing if any SmartSpoke system has pushed new sales or customer information up from the field.
By switching the POS communication activity to be active rather than passive we have eliminated the need for any communication listener on the POS side. With PCI compliance issues on many folks’ minds, having an open FTP port on your POS system was a security risk that the CTO or IT director had to allow — which is not good for your mental or physical health when you worry if your POS system is going to be hacked today. The SmartSpoke is fully PCI compliant and removes any security worries.
We are shipping SmartSpoke integrated to the Microsoft Dynamics RMS Point of Sale system first.
We plan to follow the Microsoft work with full integration to the MICROS 9700. After that, who knows where the market will take us…
-
RMS POS System and Customer Tracking
Ask anyone in the POS industry what “RMS” is and they will tell you that “RMS” is Microsoft’s POS and Inventory Control system. But back in 1988, when DataWorks started creating inventory control software for the fashion retail industry, we marketed and shipped our own software called “RMS”.
RMS stood for Retail Management Solutions. One year the “S” was changed to mean “Software”, and for a month or two the “S” stood for System. As I recall the change may have not even been deliberate. A typesetter or a proof-reader may have made the switch without anyone knowing.
When I get a chance I will insert the DataWorks RMS logo here. It was the last logo I created for the company.
Twenty-three years later (2010) we have integrated NeXT®, our enterprise back office inventory software, to Microsoft Dynamics RMS POS software.
-
Retail 101. Fewer Choices equal More Sales
Our local mega-movie-complex figured out many years ago that if they offered too many candy choices, they actually lowered their candy revenue. What they probably learned in a Retail 101 class (or a corporate manual) was that if you have too many choices, the customer takes longer to make a selection, the line moves slower, and because the movie start time is fixed, folks bounce out of line and head for their seats without making a purchase.
I have noticed a similar problem at our local Subway franchise. Folks line up for their 6-inch meals during the lunch rush. Subway newbies struggle with the menu matrix variables. A programing language is spoken under the “Order Here” sign: syntax needs to be in the proper order to get the sub built quickly. Start with size. Follow with sandwich type. Delineate the bread selection. Keep it moving, one side step after another until you belly up to the cash register. Get any of the code out of sequence and you will get an onion operator mismatch or a division by pickle error. If you get too many noobs queued up, forget about the quick turn and burn, you are stuck in the thick of the sub-plot. After a couple of long sessions of staring at the potato chip rack, I now come prepared with a trade magazine (Hospitality Upgrade and Wired are my popular periodicals) or my current novel (large helpings of William Gibson have been consumed in the midst of the Subway sub-culture).
If you are a retail manager, give this some thought: at the cash wrap you can display a lot of snap item choices – but at what point are there too many choices? When are you creating counter clutter and slowing down the point of sale? My aesthetics tell me that your counter should have a maximum of five SKUs to pick from. Odd number of choices have more visual power then even numbers – three is better than two, and five is better than four. But more than five is just noise.
-
That Was Your Retail Idea
I like Microsoft’s Windows 7 TV commercial where users flashback to an inspirational moment about improving Windows. It’s cleverly done where the Windows-7-Was-My-Idea sequence depicts a younger, thinner person – whose teeth are whiter and eyes are brighter.
My — 25 plus years in software development, couch-potato, Monday-morning-marketing, 6 years of art school, thinking about it outside the 30 second TV script — critique spun out of my noggin this way: the earth must have looped around the sun a couple times between the moment of divine inspiration and the feature’s debut. One fellow looks like his moment of bliss was followed by 10 planetary orbits and maybe 10,000 glazed donuts. That’s a lot of donuts. And 10 years is a long time to wait for a software feature. So the complete gulp of the ad went down like this: a light zesty initial splash, followed by a sour after taste.
-
Inventory Control Response Times – DataWorks 3 / 6 Design Axiom
Way back in 2006 we did a major re-factoring of our inventory control application – NeXT®. We took out stop watches and started charting all of our form’s behaviors. We focused on our Daily Maintenance and Transactional forms (read about those here).
DataWorks’ 3/6 Design Axiom:
- Any user action (click of a button, etc) that takes over 3 seconds to complete must be accompanied with a thermometer, hour glass or status message that indicates the system is still working.
- The goal of all forms is that they display usable information to the end user within 3 seconds of a menu click.
- The maximum allowed time that a form can take to display is 6 seconds.
- A form that takes over 6 seconds to display, must be redesigned with less data or fewer controls until it takes 6 or less seconds to load.
-
Inventory Control Software- 10 Second Rule – Part 3
If you have been following this blog and been wondering how DataWorks is planning to compress time and jump over some of the low hurdles lined up along the space-time continuum you can leap over “The Boring Bits”, and race down to the plot-spoiling, “10 Second Solution” finish line below.
The Boring Bits
When we started designing NeXT® back in 1998 our primary thoughts were: get the inventory data model correct. The first line of the ARMS™ system had been written way back in 1984 – two years before DataWorks was even founded (more on that later). It was a very good system for the time, but it had many design limitations that prohibited it from growing into an enterprise system capable of managing all the purchasing and inventory needs for the hospitality and entertainment industry.
NeXT was a total rewrite. We used all of our collective experience to scope out a system that would tackle all the problems with the ARMS system and take DataWorks into the 21st century.
ARMS had a whopping 67 data tables that stored all the information of our inventory control system.
At last count, NeXT has over 520 tables — and it is still growing.
If you put the two systems side by side, entered the same purchase order, then received the same partial packing slip with a 100 products, ARMS would actually beat NeXT in a “save-the-receiver” race. Two reasons:
- We are tracking and storing MORE information with NeXT.
- ARMS was written with an 8 bit 386 processor in mind.
We knew that we had MORE data, but we figured Moore’s Law would take care of the details. We really banked on Gordon E. Moore’s prediction that the number of transistors on a CPU would double every two years. Those additional transistors would translate into faster processing time and what ever programs we wrote would be quickly executed by Intel’s chip du jour.
Moore’s law has held true, (and probably will until the transistors reach the molecular level – 2015 or 2020 depending on your favorite forecaster/futurist) but the speed of the computers have not doubled every two years. Computer speed has plateaued. Back in the late 80′s we purchased a new computer every year. Jumping from a 286 10 MHz to a 386 16 MHz or getting a PC with a red turbo button on it, meant you were going to get some immediate productivity increases. Now, our R&D group only gets a new PC once every three years. The computer I use today to write code with is maybe 20% faster than the work station I used three years ago.
Maybe someone can find a graph that compares transistors density to processing speed and add it as a comment.
The other technology we bet our ERP ambitions on were hard drive space and hard drive access time. Back in 1986 a 20Megabyte hard drive with 65 millisecond access time was standard gear. We had to be very stingy with the data we kept – in fact the first versions of ARMS did not have historical sales because there simply was not hard disk space or time in the day to save it or report on it.
Think about this metric. Hard Drive storage space has kept pace with transistors (I think there is Law for that too, but I don’t know what it’s called. Comment anyone?), but access time – the all important go find the data and present it to the end user benchmark- has been sitting on top of a plateau for a long time. I remember the huge jump in 1988. We went from 65ms to 24ms access time and ARMS tripled in speed over night. I think we actually jumped from our desks and cheered. Today’ s hard drives (circa 2010) typically have 9 millisecond seek times. Now DataWorks does own some really fast gear that is used in our ASP server farm – I understand those drives have 2 millisecond seek times. So what is that in terms of speed improvement? To go from 24ms to 9ms is great – but – it is only 2.6 times faster than 1988. For a 22 year time frame that is really not much of of an increase.
What does that mean? In 2002, when we shipped NeXT, we got the system we designed, but we shipped a slower system then we expected. We wanted a fast turning, quick accelerating, dog-fighting F-16 Falcon, but what we delivered was a big, heavy, F-105 Thud. (This is a shout out to Col. John Boyd – more on him later.)
One trend that appeared in computer design that might have helped us speed up our application was the introduction of dual and quad core computers. That means 2 or 4 or more CPUs are huddled inside one computer. If the first CPU is busy, the second, third or fourth CPU could theoretically pick up the slack and crunch the data we are saving.
All that is well and good, but that is not how inventory transactions work. As I described way back in Part 1, inventory transactions are like a factory assembly line, you step through each process and do each step in sequence until you get the final product. In our factory that final product is recording the event, updating the merchandise value, satisfying the accountants, and generating analysis data.
What this means is that we can not compute on hand values independently from on order values. It would really speed things up if you could assign each CPU within the computer a separate thread of logic: You – CPU #1 – take care of the cost calculations; Hey buddy – that’s right Mr. CPU #2 – you work out the new On Order quantity for the purchase order; you over there sulking in the background – Corporal CPU #3 – front and center, march over to the parade ground and computer the On Hand values; and Charlie CPU #4, step outside to the internet and grab the current exchange rate for the EURO – hurry up, because CPU #1 needs it to calculate the new landed cost. And – oh by the way – while all of you are concurrently working on the same inventory records, play nice and don’t step on each others data.
Thread computing has very limited use in the business world that I live in. If DataWorks was in the weather forecasting business we could use all that CPU muscle to concurrently crunch and test various models to predict the weekend beach forecast, the pollen index, or how many named hurricanes are going to make North American land fall.
DataWorks is first and foremost in the inventory operation’s business. We do some serious forecasting for purchases orders , but our current needs do not require concurrent threads to predict the vendor-lead-time usage for an item, we do that by jumping over one hurdle at a time.
So to wrap up these boring technical bits:
- DataWorks is stuck with this kind of programing: do step 1, do step 2, do step 3, … until we finish with the last N process.
- The whole world is stuck on top of the current computer-silicon-hard drive -hardware summit. The landscape ahead is gentle rising plateau – there are no big productivity jumps on the horizon.
10 Second Solution
First off – lets state the obvious, if you are running NeXT on your desktop in a LAN or TS environment, just start running another copy of NeXT on your desktop. If you got one copy crunching a big receiver, just start another session of NeXT and go work on that second task. We don’t license our software by the seat so have at it. Now if you are using NeXT hosted on the DataWorks ASP Farm you could also start another session if you have subscribed for the additional log on (hey, we got to make money too).
But In version 7 we will adding something to NeXT that will make running multiple copies of the software seem like an 8-Track Tape in a 1975 Pontiac Catalina. In version 7, scheduled for release in the 4th quarter of 2010, we will be shuttling transactional processing off to a silent background program so that your current task can be released from the drudgery of saving data. You will be free to start another task — rather than watch a thermometer bar inch its way across the screen.
The plan is for this work to be picked up by the NeXT Service. Currently, the Service really has a pretty easy job. It hangs out by the CPU’s cooling fan, just looking for something to do. It really only stretches it muscles during the night shift, when it takes care of store polling, processing sales, updating the inventory stock ledger, calculating turns, adjusting vendor times, and preforming inventory analysis.
Since the NeXT Service has so little to do during the day, it will be told that an inventory transaction has just occurred and if it would not mind, and if it is not too terribly busy, would it mind picking up the job and take care of it in the digital back ground?
Here are the current tasks that NeXT Version 6 contends with:
- Run the Sales Imports and Inventory Exports (which can be schedule as often as every 3 minutes)
- Send email about polling problems to DataWorks for review
- Refresh the Inventory Daily Stock Ledger with previous day’s inventory transactions
- Roll up Stock Ledger data for Period Analysis (13 week, 13 month, Q5, Q4, etc) for Time-Series forecasting methods
- Compute Actual Vendor Lead Time and Time to Floor by Vendor, Vendor-Subclass and Vendor-Product
- Compute Stock Turns for Sub-Class and Open to Buy Merchandise Classifications
- Generate Suggested Orders
- Roll up Stock Ledger Data for Open to Buy and Budgeting Modules
In version 7 of NeXT we will be adding these additional tasks to the NeXT Service :
- Query and publish inventory reports to a subscriber of end-users.
- Generate Suggested Transfers
- Handle “large” inventory control transactions for the end user
In Version 8 of NeXT our plans are to open up the Service events to the end user community and allow expert users to configure and define their own procedures to be run by the NeXT Service.
That is when “things” should really get interesting.