What we do for a living

If you are an adult and live in the United States you have been asked this question countless times :  "What do you do for a living?"

My proud response is:  "I work at DataWorks. We create inventory control software for the leisure and entertainment industry. We are known as experts in Retail.  World Famous Amusement Parks, Casinos, Hospitals, Resorts and Zoos use our Software."

What  I get back  is usually,  "Oh,  does that mean you print bar-codes?"

"Yes,  we print bar-codes for merchandise that does not have UPC codes, but that is just a small part of what we do."

Sometimes I get a follow-up about employment opportunities, but rarely do I get asked about what else we do at DataWorks.

And this got me thinking. Do our customers know about everything we do? Do they know all the features we have built into our software and do they have a full grasp of all the things we can do besides printing bar-code price tags?

We have designed and created a lot of great software over the past twenty- seven years and some of our modules and features really stretch the boundaries of what we are famous for.

So first is my list of modules that go way beyond the retail tag:

• Supplies and Maintenance Module. This module allows departments to requisition products for internal use. The system also handles taxable purchases and the cost accounting for sales tax liabilities. Its perfect for your engineering department as well as housekeeping supplies.

• Food and Beverage Module. The Kitchen's ordering and fulfillment  needs and the front-of-the-house POS Menu Item management can be individually or mutually implemented. Features including Catch Weights and Recipes are supported in the F&B module.

Those two bullets are a mouth-full.  That means that almost everything that is purchased by a property can be maintained by DataWorks software. (The "almost" exception is to acknowledge that we are still completing a Fixed Assets and Capital Projects module.)

And then there is a list of features that really go a long way to saying how mature our system is. Here are some of the features that I think get lost because they might not be used in day-to-day operations, but are important in filling out the full description of what we do.

• Electronic Data Interchange (EDI) integration to your Vendors' catalogs, purchase orders and invoices.  This module will eliminate much of the tedious data input and automatically manage vendor price changes. For food vendors, this is a big plus, but for vendors like Callaway Golf,  Nike or Ralph Lauren, this can reduce the paper and work-flow needed to analyze products and place purchase orders.

• Suggested Orders module will  Analyze, Automate and Accelerate Re-Orders. The system examines sales trends, determines vendor lead- time, looks at seasonal and weekly trends by classification and suggests orders for products based on a number of variables including safety stock, order frequency and stock plans.

• Cancel Purchase Order Wizard. This feature is seldom used but it manages all old and past-due Purchase Orders from one screen. All orders are reviewed to determine if they should be cancelled, using  the business rules defined for each vendor. This feature can also be used to analyze orders that may  potentially slip past their completion date  and should be reviewed for delivery.

• Retail Markdown Engine. The feature has a query tool in it that allows you to identify product based on 30+ data points, such as price,  age and sell-through.  A review screen will allow you to find  slow-movers and mark them down permanently or temporarily.

• Purchases Order Email to Vendors. Send emails of orders directly from inside DataWorks. The software will email your vendor rep with the approved PO. It will cut down on your trips to the printer and fax machine.

•  Open-to-Buy for Budgeting. This is really two systems in one. It can act as an Executive Dash Board with its ability to show big-picture information very quickly. This module's beta users stopped running our sales reports and would use the Budgeting system to determine where they were for Year-to-Date, Period-to-Date information by Outlet, Department and Classification. Add the fact that the OTB module also tracks and budgets Begin-of-Period On-Hand, Markdowns, Shrink, On-Orders, Pending Orders and Open-to-Buy and you have a great product to manage your buying plans.

•  If you have a Warehouse or a Stockroom, you can use DataWorks to print warehouse aisle, shelf and bin labels. The system allows you to print Whole Warehouse, Entire Aisle, or Single Locations on large- format labels.

• Vendor Delivery Date Wizard. Purchase Orders  are automatically filled in with the dates that apply for this vendor. Holidays and Weekend rules are set and used to compute the suggested date.

• The Bar-code Validation feature is available in both Transfers and Receiving,where it helps validate UPC codes as they are scanned. This tool helps isolate new UPC codes immediately as they are scanned with portable data collectors.

• Customer Profiling Reports were created to track your best customers by Profitability and Revenue. We have clients use this system as the foundation of their customer loyalty programs.

• An entire General Ledger and Accounts Payable interface that can connect to any accounting system, capable of accepting map data. The capabilities are very deep with support for Cross Company Transfers with dual general journal entry support.

As I was proof-reading that last feature, my head started to numb up a bit, "What are cross company transfers anyway?" That may explain why I seldom get asked the follow-up question to "What do you do for a living?" I know I speak for everyone at DataWorks when I say "We are proud of what we do." It's easy to be proud because we have a fantastic family of  products that leverage the inventory control needs of your company in multiple ways. Wether it is supply-side logistics, sophisticated analytics  or accounting interfaces ,we have been there and are doing that. And after close to 28 years we know a thing or two about printing bar-codes too.

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.

Purchase Orders:

• Reusable Templates for Shopping List and Common Reorders grouped by employee access
• The Ship To Facility was freed from Employee Access rights.
• Added Search for Outlets allocated on a purchase order(s)
• Suppress need for Retail Input for Food and Supply vendors
• Ability to define Catch Weights for One-Step PO's
• New Internal and External Documents that specify Order, Pack and Weight units
• Search Option for Input Method (i.e. Manual, Suggested, Requisition, or EDI Import)
• Email PO to Vendor option

Receiving

• Catch Weight Input
• Automatic and Manual Tax Calculation
• Addition Landed Cost Calculation
• Suppress Need of Retail Input for Food and Supply Vendors
• Posting to Accounts payable distribution enhanced to smoothly round to two decimals

Physical Inventory

• Initialization of Physical Counts HUGE speed increase. Example: 30 minutes now 5 minutes.

Markdowns

• Enhanced Selection Ability
• Added Previewer with multiple selector
• Added Hand held interface for uploads

Requisitions and Fulfillment

• Default "Work For" Facility by Employee
• Reusable Templates by Employee Access Group
• Support for Hand Held Uploads
• Sort Options for details
• Debugged Store Specific Requisition Option when From Facility is a Warehouse
•  Date Needed Always Calculated - not just for Events
• Allow Fulfillment options to be re-evaluated by Warehouse staff's Employee Access rights
• Start Fulfillment form with a Find form
• Loosen  Requisition rules to allow more liberal submitting
• Changed Transfer Specific Option for Transfer From Facility to be free from Employee Access

Reports

• Warehouse Location Reports (D013 and D014)
• Consolidation Report C001,002, and 003 dynamically display number of decimals for fractional food and supplies
• Detail Sales reports DCOG01-09 compare base, landed and theoretical cost of goods.
• Barcode label printing  for Warehouse locations

Interfaces

• Base, Net, Landed, Center of Plate and Theoretical Cost of Goods now saved for historical reporting.
• MICROS Symophony POS  support
• Added Zip file options for packaging multiple export files into a fix or unique file name
• RX30 POS support
• Book4Time POS Support
• Version 3.0 of AP and GL exports support single flatten csv file format.
• Version 3.1 of AP export supports all optional PO User Defined Attributes

General

• Input for Product No and Description are now "Contains " rather than "Begins With"
• Verify Barcode export to hand helds for Receiving and  Transfer Ins
• Sped up access routines associated with adding a new facility

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.

Lately there have been a lot of internal conversations between DataWorks staff about the "RMS POS System." As you can imagine, this has caused some confusion among the long-toothed, senior DataWorks staff.

"Are we talking about OUR "RMS" or THEIR "RMS"?  The pronoun THEIR referring to a little software outfit called Microsoft.

As the fickle winds of marketing blew through our corporate doorway, we changed our software's product name again to ARMS around 1992.  ARMS first stood for Apparel Retail Management System. Circa 1994 the acronym was once again changed to mean Advanced Retail Management System. We went Advanced when we started working with Resorts and Casinos.

So DataWorks has this long tradition of keeping the acronym but changing the words. This was in the early days of DataWorks; we were young, unfocused, trying to figure out how to make a buck,  product names were not registered,  and trademarks were a thing of our future.

Our agility (youthfullness?) is  probably why there never was any trademark infringement law suits.

Around the time we started marketing ARMS, DataWorks began integrating with third-party Point of Sale hospitality systems (MICROS® and Par-Springer Miller being our major partners).  What is unique about the Microsoft RMS system is that it  is a SPECIALTY RETAIL system - not a Hospitality System.

What's even more interesting is that the current Microsoft RMS  feature set is very similar to DataWorks' old RMS system from the late 1980's and early 1990's.

Customer relationship and purchase profiles were a key foundation in the DataWorks RMS system. Our marketing brochures from that time featured an equilateral  triangle. The apex angle was labeled "Sales." The left-base angle was tagged as "Inventory," and the right-base was identified as "Customers."  We often said that RMS was built on this foundation. From Sales you could learn "who" bought "what." From Inventory you could drill down to  "when" items sold and "who" bought them. From Customers you could research "what" and "when" they purchased items.

There were some cool drill-down links that would allow an end-user to dig into those relationships. Our end-users really liked that ability and many NeXT users still talk about it today.

Those early 1990's days predated email and "www" marketing.  The DataWorks RMS Customer module had features for generating call lists for trunk shows and printing mailing labels for bulk mail rates. As I often said, if you wanted to know who bought red socks at full retail for Valentines Day, RMS could do it.

The hospitality market has been our focus for the past 15 years, and we have not seen a demand for our customer tracking ability until now.  We are involved in a new rollout of 150 stores using the MicroSoft RMS system as the POS system. We  dusted off our existing customer module's intellectual property and inserted many of the features we had back into NeXT.

NeXT always had a customer database in it, but no one ever used it since the hospitality POS system did not track sales or share customer data that way.  For hospitality it's more about the room # and customer portfolio than the individual customer information - most hospitality systems don't even have a customer database in their POS (Springer Miller being the exception) - all that is back in their reservation or property management system (PMS) - so there was no way for us to extract customer data for any micro-market mining.

All that changes with RMS; it's all about the customers.

Customer profiling, customer import and export features, customer marketing, accounts receivable interfaces and customer loyalty triggers are features needed by specialty retailers.

Guess what we are building into NeXT?

You guessed it: Customer profiling, customer import and export features, customer marketing, accounts receivable interfaces and customer loyalty triggers.

With an enterprise headquarters system like ours, inventory is created in NeXT and  sales are created in the POS system. Inventory goes down to the POS.  Sales come up to NeXT. It's a two-way interface, but each type of data only goes one direction: up or down.

With customers it's a round-trip ticket. Edits at the POS come up to HQ. Edits at HQ go down to POS.

Think through this: Customer X walks into Store A, makes a purchase, and the Cashier updates the customer record with a new phone number.  The same day,  the same customer (this time the husband), drops into Store B and buys his wife a birthday present. He mentions that he has a new phone number and a new vacation address. The cashier at Store B enters all that information too.

What happens to those edits? And how do they get updated into the headquarters system?

And what about sharing customers between stores; how can that be easily managed?  And what about customer duplicates and record merging; how should that be controlled?

We built it all in. It was a huge advantage  that we had a 20-year head start. Doing it the second time, this time with FTPS communication rather than 1200 baud dial-up modems, made the communication layer much  easier.

(Anyone out there remember Blast software?)

If you have two (2) or more retail stores and are using the Microsoft RMS or Microsoft POS 2009 systems, consider using DataWorks as your Headquarters system for Purchasing, Inventory Operations and Customer Management.

Contact us and we will be happy to give you a demo.

Ask for Mark.

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.

It was while penning our newest amendment to our  design constitution - "The 10 Second Rule" that I remembered we had established this rule of 3's and 6's as an internal SOP within our R&D group. This axiom was adopted during the re-tooling of version 3 of NeXT. I think any application designer can use these as benchmarks to judge the  usability of their software.  Obviously, it would be better if everything was instantaneous - but in 2010 we sit upon a  hardware plateau that is unlikely to see any dynamic swing in productivity.

The outcome of our axiom was that slow, data-fat forms where refitted with hyperlinks to allow  loading and displaying of data on request rather than loading and displaying everything immediately. It made us think about the relevance of information. What was primary? What was secondary? I think it resulted in a cleaner look that allows for more intuitive data input and data mining.

The best example of this visual and data weight lost is NeXT''s general product form. Here are the  before and after photos.  The biggest difference is that the before image has 6 child views strung along the bottom of the form. By reducing it down to one grid with just SKU information we lost 10 seconds on the load of the form.

The speed up was not just from the data connection and query. It was also the reduction of the additional interface controls. Each control (page, grid, command button) has it's own load, initialization, and refresh events that eat up CPU cycles faster than my children eat Cinnamon Toast Crunch cereal. Every child page and grid we turned into a hyperlink shaved another half second from the form's fat load time.

The data is still available, but we added hyperlinks to get to that data. Green links lead you to  add, edit and delete record land. Blue links indicate there is read-only information ahead.

Retail Inventory Control Operations - The 10 Second Rule - Part 2

Our retail inventory control operations happen in the back office -  typically far away from the public eye.  The general public never sees our software in operation.  Our enterprise clients typically have buyers huddled as a corporate team and receivers staffed in one or more warehouses around the country. In single property operations, the store manager usually has their workstation in the midst of  the store's back stock where they do both the buying and the stocking for their outlet. DataWorks end-users  are behind the scenes,  making the decisions and preforming the prep work that enable all of the front of the house operations to work.  They decide on the right mix of merchandise, the proper merchandise presentation, the target margin, and when product needs to be marked down and moved out.

They also have a sense of how long something should take to accomplish.  In our last post I talked about how the receiving function is the most heavily used feature of our software. I said that we strive to live within a  10 second rule for our inventory transactions;  yet, I admitted that this function typically takes much longer than 10 seconds to process.

In our home we use to live by the "5 Second Rule".  If you drop something on the kitchen floor, and it has been there for less than 5 seconds you can plop it back on your plate, splash it into your bowl, or drop it into you mouth. More than 5 seconds? Meet Mr. Garbage Can.

We now have three reasons that make this rule obsolete:

1. Our 3 year old son is not fond of washing his hands.
2. Our maid is a Roomba robot who is long on determination, but short on suction.
3. We have Ringo - the pet ferret - who was last seen headed behind the dishwasher with a naked barbie doll clenched in his jaws.

So, if ANYTHING touches the kitchen floor in our home it is walking down the long dark hallway for an interview with the garbage can.

On the opposite side of this plate is my culinary rule when camping. If  dinner drops to the dirt, I give it a brush, blow on it once, then eat it up,  grime, grit and a grin - regardless of  elapsed contact time with terra firma.

A person's sense of cleanliness or sense of urgency depends a great deal about where they are.  The context of "where" determines our expectations on how long is too long.

Put another way: walking down a dark alley is not the same as a stroll in the park.

Now that I have wandered off  topic and stumbled over my metaphors, it is time to loop back and pick up the post where I dropped my chain of thought...

Our inventory control operations happen in the back office, far away from the glare of the public.  But our point of sale partners are right out there in the public's line of fire.  When one of our bar-codes is scanned, the price is expected to "instantly" appear.  When the sale is totaled we  expect the tax  to "instantly" appear.

Besides being done in front of the public, the point of sale transactions has some other special distinctions about the end of the transaction that separate it from the completion of other inventory control operations. The point of sale transaction has one or more connections to mechanical devices that can mask the time it takes to save the transaction.

1. Printing of the sales receipt can mask the time to save the transaction to the database back-end.
2. Popping the cash drawer will absorb a second or two of transaction time.
3. Rolling coins down an automatic change dispenser chute will amuse patrons,  keep the cashiers hands clean, and certainly hide any digital needs with analog springs.
4. The prompting of a signature or the requirement of a PIN input by the customer puts a great deal of slack time into the transaction.
5. Verification of ID, with the inspection of a Driver License Number or Phone Number eat up enormous amounts of CPU clock cycles
6. The Credit Card authorization can absorb any residual transactional latency.

The credit card authorization really is a separate financial subroutine event that happens outside the inventory control transaction, but it holds the final keys to locking the transaction down.  When the credit card is swiped we expect the approval to occur in -- what?  Two seconds?  Five seconds? Ten Seconds?

My experience is that when any sales transaction takes over five seconds (credit card or no credit card) the clerk will utter the universal face saving, "the system has been slow all day" disclaimer. (The exception to this is the patient staff manning AT&T cell phone stores, their transactions always take somewhere north of  30 seconds - and they never blink until the 45 second mark is passed)

When the credit card authorization subroutine takes more than 10 seconds, I start fanning my wallet,  looking for cash or alternate slices of plastic because I figure that the credit card processing company is about to bingo my card - a big blue banner of  broadcasted unhappiness is about to scroll across the Verifone's display.

Exception to the anxiety index?  Black Friday or Christmas Eve - I expect to wait for the authorization subroutine to complete and the delay will always be the result of the extra demand being pushed into the system - it is never my problem on those days.

Consider this - our retail inventory control operations typically occur as solo events --  no one is around to share the moment with, no one else can hear the  "this takes too long" statement. Additionally,  there are no mechanical contraptions to print, pop, roll, amuse or distract us from the event. All we offer are thermometer bars that mark time to the rhythm of the saving records. With the lack of distraction,  I believe our inventory control transactions seem to take longer than point of sales transactions even when they take the same amount of time. Of course how many 100 line item POS transactions have you ever heard of?

Having just said that, I remember that back in the late 1980s and throughout the 1990's our SCO Xenix and MS-DOS applications were designed to begin a print job  immediately on the save of a transaction. As soon as the receiving event was told to process we would start printing out a "report" that would document the event for accounting and paper back up. The first step of our transaction would be to dump the contents of the transaction out to a Dot Matrix Printer.  The print command would take a half a second or two to push, and once completed we could continue with the work of quantity, cost, retail and accounting updates. The printer would take a good 30 -60 seconds to weave fan fold paper under its 32 character per second print head and when the printer ejected the paper up to the rip line, the transactional data was safely saved and waiting for the next transaction to begin.

We now design our back office inventory control operations to only print on demand. A document that can be printed to the screen, or emailed to a department, or published as a PDF file has taken away our ability to hide the transaction's save in the shadow of the printer. Plus we feel pretty good about our green policy and the fact that we are saving acres of pine forests from being bound into journals full of DataWorks documents.

Having just pulled those two decade memories up to my frontal lobe, it might be possible to design the receiving transaction to spool up the bar-code ticket printer at the beginning of the transaction with the need for hang tags or adhesive sticker stock.

I have done a fair bit of political back peddling on this post.  I declare that we have a 10 Second Rule and then do a great deal of mental pondering on modifiers to the rule. The 10 Second Rule is a design goal.  Whenever I hear there is a "Rule" in computer programming,  I start toward the fire exit,  looking to protect myself with a new software vendor. Rules are created by programmers, designers or companies who have either a mental block, a framework restriction or a language weakness that is preventing them from doing something better.

Hopefully,  I have painted a picture that our inventory processing time is indeed relative to the where and when it occurs. Both the "where" and the "when" have something to do with our sense of urgency and our expectations on system performance. The next post will be "when" you will not have to wait any longer on how DataWorks will deal with transactions that do take over 10 seconds.