DataWorks Ships NeXT Version 8.8

Version 8.8 of our inventory control software for the hospitality and amusement park industries shipped to our customers on May 12, 2013. This is the second 8.X release. The first was 8.2, which made it's debuted on November 11, 2012.

Version 8's main mission is to make Purchase Order input faster and easier.

This was a seven month development project and here are the main highlights of this  release:

• Custom Field Layout on the PO form. This allows expert users to select which columns of descriptive data they would like displayed on the PO Detail section. This tailoring of the form has a default by Vendor that allows Food and Beverage Input to look and feel different than a retail or general supply PO.
• Sort and Re-Number  functionality on the Purchase Order form. With this new feature, a PO template or original PO can be sorted and grouped based on criteria selected by a user. This is helpful for large food orders where grouping items together by category or storage method is helpful for the vendor as well as the receiving crew.
• Save More functionality on the PO form. This feature was the number one request  from our customers. This feature grants increased productivity while creating Purchase Orders on the fly, and allows for faster heads down data input. Everyone in our user population that does purchase order entry will benefit from this feature.
• More Look-up Methods are now available during PO Input. These include look ups by Vendor Description, SKU and Bar-code.
• Faster Inventory Creation. We cut the time needed to create an inventory item in half, plus we added a matrix form that allows you to visually select which outlets or warehouses you want to define the inventory in. This was a feature whose idea came from our support and training staff. Customers will enjoy this feature since it allows much greater control and fewer keystrokes to create inventory in desired outlets.  This feature will be a big benefit to our entire customer base.
• Unit of Measurement equivalents for converting an ingredient from weight to volume or units to weight or volume. This new functionality even allows for unique conversions for preparation methods (i.e. diced, sliced, cubed, etc). This feature is a big benefit to our Food and Beverage customers.
• Currency, currency and more multiple currency features. Reports now automatically select which currency values should be displayed. Based on the the outlets that  are selected, the report system will standardize the data and give consistent revenue, cost and gross profit. In addition, the product and inventory forms now have clearer labels about what currency values are being displayed. This greatly benefits our multinational customers who have revenue centers in more than one country.

Version 8 will be complete when we have added the ability to edit and make substitutions on an approved PO - even one that has been partially received.

In total, 128 new features were added and 177 defects were fixed in this major release of NeXT. To find out more, log into our customer portal and review the complete manifest of Version 8.8.

Budgeting and Open To Buy Webinar Recording

We held our Open-To-Buy Webinar on May 8th, 2012. It covered Budgeting, OTB concepts, configuration and a live demo of the system. For those who could not attend the live event, here  is the recorded presentation: https://www1.gotomeeting.com/register/914658745

You will be asked to register your name, email, etc and then you can watch the presentation. It's a small price to pay... Enjoy!

Not sure what Open-to-Buy is? Open-to-Buy allows you to monitor inventory on a monthly basis, improving margins and cash flow, and ensuring a strong ROI. The clearest and simplest definition is that it is a financial budget for retail merchandise. Like any budget, an Open-to-Buy starts with a plan, then compares actual results to that plan and quantifies any variances.

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

Going The Extra Mile

We are in business to help retailers manage inventory, using whatever POS (Point-of-Sale) system they prefer.  You’ve read a lot here about some of the great ways we help businesses manage inventory, which range from comprehensive inventory management, to sophisticated COG (Cost-of-Goods) calculations (think: multi-currency), to the new stuff we are doing in Analytics.  It all starts, though, with our interface to the POS’s that our customers choose to use (and some use multiple types, which is fine with us).  This is the history of one of those interfaces, and how DataWorks goes the extra mile to make those interfaces happen, and happen reliably.

RMS: Here We Go Again

The story begins with a request for us to interface with Microsoft’s RMS POS product.  We had done work on an interface to POS 2009, the Microsoft product that replaced RMS, but the customer wanted to use RMS because the POS vendor (New West Technologies) has a mobile device made to run on RMS.  Since the capabilities the customer needed were also in RMS, we repurposed the interface to run with RMS.  Since neither RMS nor POS2009 has an API (standard way of interacting with a program) capable of supporting a POS interface (RMS has none, POS 2009 has one that, let us say, exhibits several design insufficiencies).  Anyway, here we were with RMS and no API for us to use: we would have to create both sides of the interface.

Well, we’ve been doing this kind of thing for 20+ years now, so how hard could it be?  And in fact, it was quite easy: the database for RMS (a product which Microsoft bought from another company around 1994) is well designed, and we were able to do so in record time.  The challenge wasn’t in getting sales data, nor in putting inventory data in: it was in communications.

We have done many kinds of interfaces with POS vendors, but we had no model for doing it entirely on our own: we took this as an opportunity to make something that was easy to deploy, would satisfy Enterprise security needs, was reliable, and could easily be re-purposed.  The result was SmartSpoke, which sits on the customer site and uses FTPS (secure FTP) to communicate back to an FTPS server in our co-lo.  So far so good: and then there are the pickles (shorthand in our R&D team for the unexpected that comes after you are sure you are done <s>).

It Would Have Been So Easy

The RMS POS can be deployed in more than one way.  Well, we know that now…  When we designed SmartSpoke, we knew of one way: a SQL Server instance hit by the registers, however many there are in the store or site.   The SmartSpoke would consume very few resources, running as a Windows service, and so could co-exist happily on the same box as the SQL Server, which it would also use for its own configuration and logging data.  We would be able to get on the SQL Server machine in one manner or another while the Registers were running, in order to handle the inevitable issues that arise when doing interfaces.  What issues, you say?  Why can’t they all be known ahead-of-time?  Well, there are these pickles, you see…  We produced a diagram of the system, which we gave to all involved with our first project.

Then we had our first implementation meeting, where we found out a) that each register would have it’s own SQL Server (Express); and that b) the complications of maintaining a server (this was an Enterprise solution), at each location, was not feasible.  With stores scattered everywhere, far from corporate headquarters and the IT staff needed to monitor and maintain servers according to the corporation’s standards, the level of effort would be unacceptable, unless we really, really had to have a separate server.

Did I mention that our business is to help businesses manage inventory?  Well, giving a business another headache to deal with isn’t a great way to help, so we, with the aid of our POS vendor project partner (New West), tested putting the SmartSpoke services on the same machine as the POS, which also had SQL Express running on it.  Would the POS be able to proceed as normal with the SmartSpoke loaded on the same machine?  Lo and behold: it worked!  We were home free!  Except for those darn pickles, wouldn’t you know.

Did I Mention Helping?

The first complication we ran into was the inability to get on the interface when the POS was in use.  We report back home (via email) when sales are missing for a particular date.  Support then looks into what’s going on.  But they couldn’t check the interface when the POS was in use, and so all the checking had to be done after the stores closed or before they opened, which of course was mostly outside our normal business hours.  We had no other option than to do any checking, and fixing, of the interface at night or early in the morning.  No extra charge, we just did it because it needed to be done.  In the meantime, as CTO I began searching for options.  But another pickle popped up before we could test and put a solution in place, and that one needed to be solved quickly.

So Much For Testing

You might have thought we didn’t test any of this, which I assure you is not the case: we tested everything we knew to test, based upon the best possible advice on how the system would function.  For example, it was the understanding of everyone involved that where there was more than one register, one would be the master, and any other “lanes” (as they are known in retail) would be slaves, connected to the same database.  With the assistance of Casey Hansen, VP of Technical Operations at New West, we tested that, and everything worked smoothly.  We forced the slave register to start its own sales batch, on its own SQL Express instance, by taking the Master offline.  When the Master reconnected, the slave created a new batch on the master POS, put its stored-up data in that batch, closed that batch, and opened a new one on the master, which took its sales from that point on.  As a technologist I had a big smile on my face: that’s the way things are supposed to work!

The Pickle, in this case, turned out to be a handheld POS terminal which, unlike the slave registers, created its own batch and kept it open until the user decided to close it.  Why did this matter?  It’s all about duplicate sales: we cannot let them get into our system.  We thought we had the ideal setup, given that the Master Register only held one batch open at a time: if we tracked the last batch number processed, we would know the next one to process.  So we adjusted the interface to work off “last datetime,” instead (which we had avoided due to improbable but possible problems with datetime changes on the host computer), and then returned to the issue of finding a way to check on/adjust the interface while the POS was in use.

We Get Help From Others, Too

While working with the firewall engineer for one of the first stores where we installed the RMS interface, a very helpful engineer from Vendorsafe (they specialize in helping businesses become and stay PCI-Compliant – credit cards over the internet and the like) mentioned that other Vendorsafe clients were using the built-in VNC server in VMWare Server and Workstation to connect, and that combined with a very inexpensive SSL VPN they provide, this would be acceptable in maintaining PCI compliance.  We would still be running on the POS register, but in our own OS instance inside VMWare.  Using VMPlayer, VMWare workstation’s little brother, we would minimize memory utilization (fewer features VMPlayer should translate to less memory used) and minimize cost to our customer.

I quickly put together a test instance and it worked fine.  Using the VMWare SDK (Software Development Kit – tools to do non-standard things with a piece of software) I could get the VMPlayer to boot up in “headless” (not visible to the user of the machine) mode.  Having gotten permission from the customer to go ahead with testing, I made arrangements with Casey at New West to do the testing.  Of course I wanted to get the latest version of VMPlayer installed there, since New West clones the versions on which we test to install at sites.  Only one problem: the new VMPlayer version didn’t work with VNC when I installed it at New West.

A bit of research later, accompanied by some mutterings about the darn pickles, and with help from VMWare employee blogs, among others, I found out that a) VMPlayer has all the same API as VMWorkstation, but b) in the latest version, for reasons that were muddled (that’s what engineers do when a decision with which they disagree is made by Marketing), had set the flag off for VNC to work in VMPlayer, and that c) they might turn it back on in the future.  The version I had initially tested had been the last one with VNC still working.  Given the choices, I did what I usually do in those kinds of situations – more research.  Well, it turns out that flag enabling VNC was at a particular place in the exe, and that with a hex editor … well, you get the idea.  And if there is ever any objection, I could always go back to the earlier version.  In the meantime, this was working great.  We threw everything we could at it, myself inside the VMPlayer instance with the SmartSpoke version pushing inventory and taking in sales, at the same time I had the SmartSpoke Manger running, doing things in the UI that taxed the SQL Server instance, which was still on the host computer.  Meanwhile, Casey pumped sales into the POS as quickly as he could.  The result: no noticeable difference on the POS side.  Boy, we had it made now!  VendorSafe provided the VPN, which works like a charm, VNC connected as fast as it does on my work network, problem solved.  You know what’s coming next…

It Should Have Worked…

Casey from New West put the .bat file starting VMWare in the Startup folder: because the machines were kept on at the various sites over night at the POS login, ready for the next day, VMWare and therefore the SmartSpoke Interface would always be running.  Then we got reports of no sales: what???  We found some instances where the POS was at the OS logon, which would account for VMWare not running.  But we also found instances where the POS was running, and VMWare was not.  Inconceivable! (Another R&D team iconic expression – from The Princess Bride, if it seems familiar <s&ft; .)  Casey thought it might be the DOS window that ran when VMWare started up: perhaps the user saw it, and clicked it shut?  We had no knowledge that was the case, but he put in a shortcut to the .bat file, with a Minimized window setting, to see if that made a difference.  It didn’t.

So, a couple of days ago I spent a few hours creating, testing and installing a service that runs when the OS starts, before logon, and starts VMWare.  I think we’ve got it now … but I’m not proclaiming success.  Rather, I’m proclaiming that we put in place a solution that appears to be working as intended.

This Is The World As It Is

When I was studying psychology, a therapy supervisor told me “don’t be afraid to make a mistake.  You will.  It’s what you do with the mistakes that counts.”  We know at DataWorks that we are no more, nor less, capable of creating foolproof products than any other organization.  Our strength is in the attitude about what we do with our mistakes: we find an answer quickly, and put in place.  It’s our ability to respond in an agile manner that allows us to give our users what they need in Retail Inventory Management.   Moving quickly as we do makes for an exciting place to work.  It also makes for some great feelings at the end of the day, knowing that we’re fulfilling our goal of helping our users do their jobs better and more easily.

Five New POS Interfaces in Development

Over the past 26 years we have authored numerous POS interfaces to our inventory back office software. The previous peak of our output  was in 1999, when we shipped four new POS interfaces. 1999 marked the near zenith of the the dot com bubble. I recall I was regularly talking to investors, venture capitalists, and  piloting a  leased airplane around the country. Times were good.

Y2K issues also peaked in 1999, so we got to ride the need for software that was  2000 savvy and replaced some systems that were stuck in 1999 land.

From 2000 - 2010 we typically had one or two new POS partners join us each year; however, during the last two years (read as "during the recession") we authored only one new interface - the two way integration to the Microsoft Dynamics RMS POS system.

During November 2010 the market moved and new partnership opportunities sprang forward. We currently have  FIVE new POS interfaces in development.

They are in alphabetical order:

1. Book4Time
2. MICROS,  Simphony 1.5
3. Squirrel Systems
4. Transaction Data Systems - Rx30
5. Vivonet - Halo

We welcome our new partnerships and look forward to a long relationship with each company.

As a measurement of economic health, I suggest that you add a new economic indicator  to your existing list that may have previously included such mundane items as: new housing starts, same-store sales, and weekly jobless claims. Add the DataWorks-POS-Work-in-Progress (DWPOSWIP for short) to your important economic metrics.

So,  is the recession over?  From our point of view -  YES!

High Tech Retail meets Low Tech Camping

Every year, our scout troop time travels back to 1830. We camp under white canvas, cook with cast iron, use candles and kerosene lanterns for illumination. We wear period appropriate clothing - includes shoes, socks and the all the rest. On every camp-out we take away the scout's cell phones, but on this particular camp out digital watches, clothes with zippers, butane lighters, nylon - anything pre-1830 is not allowed. The scouts are not suppose to be sending or receiving text messages. The scoutmaster is not blogging.

The idea is this: Learn history by living history.

At this particular camp-out we were encamped with other people from all over the world who are also living history too. That includes musicians, black smiths, and traders -- who peddler everything from buffalo pelts to leather making tools.

One of our scouts decided he needed a leather punch, but because he did not have the $8.00 for the tool, he stole it.

Now our business here at DataWorks, Inc. is inventory control. Loss prevention is part of our product offering. Physical inventory counts, and the tracking of shrinkage is a major part of what we do. We don't relish the fact that our software catches internal thieves, but we do. People have been caught and prosecuted based on our inventory system's controls and features.

So when I sensed that this scout was suddenly endowed with a tool that he should not have had my retail-shoplifting- radar pinged up on full alert.

It took the better part of a day to get the young man to confess to his crime, but he did. Restitution was made by returning to the trader's tent, admitting his crime, returning the slightly-used tool, plus repaying the  trader double his retail price - $16.00.

My logic was that while the item was out of inventory, he lost at least one sale, and he needed to be compensated for the lost revenue plus the loss of stock.

The trader accepted the apology, and then returned the tool and the additional $8.00 to the boy, with the statement, "It took a man to admit you were wrong, thank you for telling me. Here is your tool and the additional $8.00 back. Learn from this and don't ever do it again."

The scout thanked him. I thanked him. The matter was closed.

The value of the experience for me and the young man was that the ability to admit failure is a tough thing to do; but,  the ability to forgive is an even better trait to have in your personal inventory.

If you are interested in the campout regarding the where, the when and the how, that can be explored at this website.

The 3-T's : Taxes, Tenders and Tellers

What is DataWorks process and analysis on point of sale taxation, tender definition and teller configuration? The broad concept that we work under is that "Taxes, Tenders and Tellers" are not created and managed by our Retail Back Office System; instead, we map to the 3-T data that is defined at the individual POS system.

Defining Taxation at an abstract layer - Taxable, Non-Taxable, Luxury Apparel, Food, etc; and communicating that to the POS rather than a specific 6.0%, 7.5% or X.X%, has given DataWorks users the agility to deal with tax holidays like Back-To-School.

Managing the complexities of local taxing authorities is a task we have defined inside our R&D track. Of all the Point of Sale systems we interface to, the Microsoft POS 2009 has a structure that closely mimics our centralized design concepts for Multiple Federal, State, County and City taxes.

Based on market demand for POS 2009, we may implement a global integration and distribution for this in a later version of our Smart-Spoke Interface.

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.

DataWorks wins Horizon Council's 2010 Information Technology Award

On Friday September 17, 2010 DataWorks, Inc  was honored by the Horizon Council.  Being the co-founder of DataWorks I had the huge honor of accepting the award for the company. Not until the event got underway did I realized that close to 1000 business leaders would be introduced to our company by watching a 3 minute clip about our firm. I would have been more much more nervous during the interview if I had know...

In my humble opinion the production is fantastic, plus you get a glimpse into our offices here in Bonita Springs, plus some insight into our future direction.

Enjoy.

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.

Cloud Computing, Data Centers, and the Meat Locker Matrix

Today is Tuesday, May 18th, 2010. During the last two days (Sunday and Monday), two of our employees spent 40+ man hours in our data center. We use Paetec's data center (also known as a Co-Lo site ) in Fort Myers, Florida to house our internal business applications, our R&D infrastructure, our phone system and our Hosted ASP software application. Paetec provides the bunker, the security, the bandwidth, the power,  and the cooling. DataWorks provides the servers and software.

If you are looking for cloud computing  this is where it exists.

Cloud computing is not some vaporous thing that floats magically on the internet. It is racks and racks of noisy, hot, glowing  servers,  stacked one on top of the other in an enclosed silo of steel and cables. Our Co-Lo site is cold -- meat locker cold. You wear a warm coat when you are in the cloud.

99% of the time, the cloud  is an uninhabited space where the steel doors are locked, access is electronically keyed, servers stay hot, hard drives spin,  air conditioners whip away the heat, and the lights are off.  The cloud  is not a place for humans.

William Gibson, the novelist, (who has penned much of our computer slang) calls the walking-talking-awake-world the "meat" world. The meat world is the world we inhabit when we are not jacked into the "matrix" (Gibson penned that term too).

Our typical business activities are 98% matrix based  - very little muscle ("meat") is used in the pursuit of profits. The last two days these two Data-Workers efforts equated to an intense work out.  They are now physically exhausted - having stood on hardened concrete floors, their feet (especially their heels) feel like raw hamburger. Their hands ache. They have cuts and bruises  on their hands and arms from dead lifting 150 pound battery back up units out of service and replacing them with newer (and lighter) units.

By the way, they are in good physical shape, they hit the gym at least twice a week with personal trainers, they hike, they bike, they camp. In the course of two days, they used a host of low tech tools like wrenches, screw drives, pliers, and  pocket knifes  to lift racks, adjust rails, twist electrical leads, and cut cables.

After about an hour of this work their fingers go numb; after about 4 hours,  their minds start to go numb.  That's when the mental mistakes start to kick in.

In a moment of mental meat enlightenment they decided to move, re-rack and re-cable a group of servers - they moved them from one rack into another so they would be "logically" together. Makes sense. Makes sense now. Made sense then.  But in moving the servers, some mistakes were made. 1) Untested patch cables were used to re-cable the servers 2) cables were plugged into unmarked dead switch ports and 3) the primary firewall was re-connected with one cable in the wrong port.

It took  an additional 14 man hours and an additional 23 elapsed hours pass our scheduled down time to totally diagnosis and solve the cabling issues.

The obvious mistakes that were made: they changed more than one thing at a time (no way to trace the diagnosis  by working backwards -  that was working , but now its not working...) and not enough labeling and documentation of the servers, cables and ports. If they had taken an hour or two to label all the cables before moving the servers,  they would not have had the problems that they encountered after the boxes were spooled  back up.

In that perfect vision that is known as hind-sight, I thought about how military officers do not typically carry rifles or heavy packs. In the field, they are lightly equipped with just a side-arm. Why? So they are not physically burden, they do not become physically fatigued,  and their minds can remain fresh and agile. When your "meat" is on the line in combat, you want the pointy end of the kabob to be deadly sharp and accurate, and you most definitely want the thinking end of kabob  to be cool to the touch and ready to think through a crisis.

The cloud is were the matrix world meets the meat world - Bring a coat.

And don't forget the label gun.

Reports - Expanding your Business Intelligence

We have somewhere north of 500 published reports in version 6 of  NeXT. Each report has at least 5 query options, but most have over 50 query options.  The reports are beautifully designed and a buyer or retail manager can really dive into the performance of product lines and SKUs. That's pretty good, but we went two steps further with version 6.

One step was the introduction of  flex reports to our sales analysis sub-system. Flex reports  allow an end user to design a custom report that can summarize or categorize sales data with up to 3 break levels from 21 choices.  Common elements like store or class and uncommon descriptors like season or color can be selected. The flex reports will be expanded into additional analysis sub-system such as the Inventory and Purchase Orders in future versions.

The second step was actually a  huge leap.

We now offer access to our report data dictionary. We use Crystal Reports for our reporting. Underneath the beautiful exterior we have a standard set of  views that can now be exported, saved and used with OLAP  tools, pivot cubes and business intelligence systems.

We have a motto here at DataWorks that our CTO, Hank Fay coined, "We support an application, not a database".  The report data dictionary is a consistent and standard part of our application.  That makes it supportable.  For years we have been asked for the schema or road map to  our back-end database and we have always said "No". Reason? It is going to change and if you write an mini-app on top of it, it will eventually break.

But now with the published data dictionary we offer a playing field that provides a consistent data layer for a designer to extend our inventory control software.  Our database model currently has over 600 entities with over 5000 relationships that tie together a strongly normalized database. Our report dictionary flattens that data out with joins and field name conventions that take the headache out of the select statements. What this offers us is a way for us to support our application rather than support a database.  It also allows for more agile development which allows us to accelerate in a high G turn. (See John Boyd)

The report export module is licensed separately - it comes with documentation on the published data dictionary. We also offer consulting and training on connecting to and using the data dictionary.  The dictionary will be backwardly compatible from version to version. We will add new fields and expressions to the dictionary, but the existing names and data types will remain consistent into  future versions. It gives the report designer a solid foundation to build unique designs and representations of the data filtered down for the needs of a particular organization.

So license up, dive in, and mine your business.  As in :  "Business  Intelligence".

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.

The same odd-versus-even thing works for product facings too.  Better to have a facing of three rather than two.  I would line up a facing of one rather than a facing of just two.  Call me crazy, but that is what going to art school does to your sense of  "what-looks-right".

I was trained as a fine artist during the 1970's - minimalism and conceptual art were among the vanguard.  I admit that I am jaded - I was trained to see, think and believe that "Less is More".  (For those who want to know more about those art movements, here is a sampling of artists who shaped the visual vocabulary of the 1970s: Sol LeWitt,  Christo, John Baldessari, Donald Judd, Carl Andre and Dennis Oppenheim.)

Boiling your presentation down to the iPod-ian essence can result is an elegant, simple, and beautiful end product. Apple certainly has nailed down the clean minimalist style with their recent products.

The challenge we all have is this: in a world of many choices, how do we focus on what is important?   As a kid, the top of  my dresser was always crammed with every toy or object that was important to me:  plastic models,  coin bank, world globe,  jar of BB's,  comics, army men,  photo of Alan Shepard, spent Estes rocket engines, and Lego masterpiece - not a square inch of empty space.  At a certain density the pedestal-ed objects cease to function as a display. Objects break or topple when you go to pick them up, mom complains about the dust,  and the whole presentation looses its luster and appeal.

It is the goal of good design to filter out all the extra objects, features, requests, buttons, knobs, dials and other do-hickeys until you have a  product distilled  down to the fewest - and most important - choices.

What has never been published until now is this - NeXT® back in 1999 was actually much larger in scope. It had  additional sub-systems that dealt with watch-dog alerts, work-flow integration, n-levels of hierarchy and a separate financial ledger that were removed from the design scope because they put too many additional tasks into getting version 1 out the door.  Since I was the designer I can admit that I suffered from the second system syndrome . I knew about the tendency since I had read Fred Brook's masterpiece The  Mythical Man-Month, but figured since I knew about the follies of those who had proceeded me, I would be immune from the disease.

I was still putting too many things on top of the dresser.

About 20 months into the data design we realized that at the rate we were modeling, it might be another 24 months before we finished with the project scope. I think I may have even re-read a chapter or two of Brook's book at the time.  We evaluated the project and started hacking out entire modules and trimmed down the effort. 10 years later those features are now being introduced back into NeXT. All of those removed features will eventually show up in NeXT they just needed to be introduced in a  more managed context.

That decision to cut back was important because we got NeXT installed in 2002 versus 2005.  We are glad we got it out the door.  What is interesting is that many of the forms have now undergone a cleansing and scrubbing process where the number of tabs and controls have been reduced and cleaner, simpler hyperlinks have replaced them. We now make sure there is plenty of free space (negative space) that gives the controls some breathing room and more visual importance.

That's how fewer choices helped in our software design - I hope  you can use it with your own merchandise presentations.

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.

I asked my teen age children, and a number of adults who are NOT in the software business what they thought of the ads and they all thought the ads were excellent. No one had any negative take on it. Everyone saw it as a actor-reenactment spoof that was clever and funny.

So I am wrong, the time between inspiration and delivery was not 5 or 10 years. No one gave any thought to how long it took Microsoft to delivery the software. No one thought it took a long time. Time did not even enter into the advertised mind-set of my sampled audience.

So this is a case of sitting too close to the fire and getting my software marketing antennae scorched.

Probably because DataWorks' strives be to highly agile and capable of accelerating in a high G turn (See John Boyd) I took the Microsoft ad too personal. At DataWorks we have one major release a year. There are usually 4 or so incremental minor releases that address software bugs,  additional reports  or small feature tweaks.

Back  in December of 2008 I sent an email out to our end-users saying, "Hi, we are working on a new version, it's Christmas time,  and in the retail spirit of the season, what do you want gift wrapped into our inventory control software?". We got a lot of great responses. We organized the list, sorted it twice, scored everything with a strategic index (how many other users want this too?),  assigned developers with the tasks, and delivered the features in less than 12 months.

So in the spirit of NeXT-Was-My-Idea, here is a public thank you to a few  of you who asked for features and made NeXT® better:

1. To speed up Purchase Order input, define a Default Ship To Address within an Employee Access Group. From the 2008 DataWorks Users Conference Group Session.
2. Change the name of the PO Input from "Multiple" to "Pick List". Also make it the first choice in the drop down choice since it is the most popular. From the 2008 DataWorks Users Conference Group Session.
3. Search for a SKU that has been counted in a physical inventory.  From L. S.  at  Ripleys Entertainment.
4. Add a  field to the Vendor definition and allow me to define a vendor's federal tax id number. Include the field in an Account Payable export. From L.K.A. at Beaumont Hospital.
5. A report to list inventory items that have margins outside the normal parameters I have set up by category. From J.M. at Grand Casino Hinckley.
6. For Products with many colors and sizes, add an option to the purchase order system to show only the SKUs  that have been re-ordered. From J. McG. at Sea Island Company.
7. Give Sales Reports the ability to be run for a set of vendors. From D.U. at Ripleys Entertainment
8. Expand the Best Worst Reports to rank by product within Department; Product within Sub Department and by Product within Vendor. From D.U. at Ripleys Entertainment
9. Please add a way that we can scan our product's barcodes with a portable data collector and import them directly into a purchase order. From T.K at Via Christi.
10. Create a consolidated Manufacturer by Product by SKU Inventory report that focuses on recent ordering and receiving performance.  From J.W. at Jacksonville Zoo.
11. Best Worst Report with both Quantity Sold and Quantity On Hand Values, plus Percent of Totals. from S.W. at Ritz Carlton.
12. Comparative This Year to Date to Last Year to Date Sales report by Department. From L.S. at Ripleys Entertainment.
13. Create a forecast model that tracks and projects demand based on trailing 15-13  months (Q5) versus trailing 12-10 months (Q4) by Subclass.  R.T. at Pebble Beach.
14. Redesign the Quick Physical system so that is actually quick! From the entire audience at the the 2008 DataWorks Users Conference.
15. Create a faster way to input and cancel ticket batches. From  T.Van A. at LaPlaya Beach & Golf Resort.

Thanks for all of the ideas. These are just a few of the ideas the DataWorks community submitted and turned up in the release.    If you see your suggestion above and would like your name published - just let us know and we will give you proper credit.  You can read about all the enhancements by clicking here:  Version 6's Feature List.  Additionally  you can watch this recorded preview of the software.

If you have an idea for our next version, please feel free to add a comment here.  Keep the ideas coming and we will keep the code rolling. Together we design a better inventory back office system.

Retail Budgeting, First. Open to Buy, Second.

Yesterday on March 2, 2010, I announced the scheduled release of DataWorks top down Budgeting module for NeXT® - our inventory control software for the Hospitality and Entertainment industries. The 55 minute seminar was recorded and can be watched by clicking here.

Here are the facts if  you don't have 55 minutes to spare:

The module will first ship with top down budgeting. That will be followed by a bottom up, open to buy planning add-on in 2011.  Those who purchase now will receive the bottom up plan extension at no additional charge.

We are signing up beta sites now. The beta release is set for April 19, 2010. You software will be updated with the budgeting module on that day.

The module price of  $5,000 USD  is being waived for the beta group.  License agreements, training, professional services,  and maintenance fees will still apply. (We got a make a buck too.)

If you are interested in being in the beta program,  post a comment to this blog entry or send us  an email by using our web site's contact us page . Its a first come first serve program.  Yesterday I said the first three clients. Today my staff talked me into the first ten.

So, the first ten existing clients to sign up for the budgeting module Beta get it at no charge.

The general release of the module is set for June 7, 2010. That is a couple weeks prior to the  HITEC exhibition in Orlando, so it fits nicely into our press release -exhibition-marketing needs. We will be set up for full demos of the module at the show.

Happy budgeting and remember to include us during your capital budget for next year. Speaking of capital - if you are a hosted or SaaS (software as a service) client you can add this module into your monthly subscription after June 7th.  The additional per planner / per month fee will be announced after the beta program ends.

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.

Inventory Control Operations and Transactions

While writing the prior posts about the 10 Second Rule in inventory control, I started thinking about our end-users and the forms they use to operate our software. Imagine that we could gather every inventory control system ever written by DataWorks (and while we are at it let's toss in every AR, AP, GL, Payroll or ERP application ever programed by any software company) into a huge vat of creamy digital goodness. Then using a yet-to-be-invented silicon-spatula, we would pry the user interfaces from these systems into a giant pile of one-dimensional pelts.

Next we would rake these skinned bits into the intake scoop of a yet-to-be-invented silicon-shaking machine. After clicking the OK button, we would adjust the lumbar support of  our Herman Miller Aeron chair (mine's black),  and watch as the mythical machine shakes and sifts the leafy bits though various mesh screens. Eventually all the input will be sorted into five unequal mounds of output. In order of their height and weight the piles would be grouped like this (you may not like the names of the piles, but this is my made-up machine, so these are my made-up names) :

1. Confirm & Comfort - Little crumbs of programing chaff  that ask yes-no questions,  tell the user that something is happening (Hour Glass or Thermometer Bar), or will happen - once they click the  "OK" button.  These forms generate comfort to the end user - they let you know the software is working away on something, they ask a question to make sure you really want to change all the prices of the beanie babies to 19 cents. They add some flavor to the system, but they don't really do much. They are the cranberry laced croutons of a much bigger salad.
2. Configure & Forget- rarely used after initial setup. Super simple to program. If you have seen one you have seen them all. (i.e. System Defaults, Colors, Sizes, Units of Measure, Classes, Departments, Margin Plans, Ticket Type, Currencies, Languages, Addresses).
3. Daily Maintenance - highly specialized forms that handle the heavy daily lifting of inventory. Lots of code.  Speed and flexibility are important.  (i.e Product Input, SKU definition, Cost Updates,  Price Changes.)
4. Show & Tell - retrieves and organizes data for your viewing pleasure. This group includes screens used to select date ranges for running reports  and forms used for looking up a particular data set (i.e.  Product look up, Sales Audit review, Comparative Sales Reports,  Best - Worst Analysis,  In-Transit report,  Inventory shrink, General Ledger Batch)
5. Transactional - an elite group or  highly trained, highly specialized forms,  used to record an inventory control action. These forms are the work horses within any inventory control system.  (i.e. Purchase Order, Receipt, Transfer, Markdown, Inventory Adjustment, Return to Vendor).  Lots of Code.  Lots of business logic.

Transactional forms are the core of any inventory control operations system and the focus of this post.   If an action is being recorded that changes an inventory item's on-hand or on-order value (quantity, cost and/or retail) these are the forms that are used.

A characteristic of a transactional form is that it typically has two sections:  a header section and a detail section.  The header is one row of data that captures at the very least the who and the when of the transaction.  Who = The employee who preformed the action. When = The date and time that the transaction occurred. The Detail section contains the "What". What SKUs are being received. What products are being returned to the vendor. What items are being transferred.

We create and maintain a database application that in at it's genetic core  is an accounting system with a very thick veneer of operational epidermis.   Now this may surprise you but here is is what bounces against our head-bones when we are creating or enhancing our inventory control application:

1. First and foremost is this question: What data do we need?
2. The next question is:  Is this data related to any existing data?
3. Thirdly - and this is where business logic, programing, and all the accounting bits come into focus -  if this data changes will it effect any other data?

In a transactional form, the tricky bit about all this accounting and business logic is that there is not just one piece of data moving from a 0 to a 1, (or from a 1 to a 0) but more likely there are hundreds or thousands of data bits queued up that need do their own debit to a credit dance too -- and if one bit changes then all the bits need to change.  It is an all or nothing process.  If you start the transaction the software needs to be able to finish what you have kicked off.  Even - and this is very-very tricky part - if the computer power supply dies in the middle of all the fun, or if the SQL Server connection drops offline, or some other random act of chaos says, "Hello, nice to met you" to our finely crafted inventory control software - the application needs to be able to pick up where it was unceremoniously dropped off and finished the transaction.

So with that said, the receiving transaction generates a lot of exciting data changes (increment the on-hand, and decrement the on-order), and the transaction has to leave some cookie crumbs along the way so if the process dies, Hansel the handy programmer, can code in a method to find a way back to where chaos stepped in and then finish the march to grandma's house.

This is one of those areas that for those who know a little about this industry, but never actually had to write a application (read "Consultant") would rattle off something like, "Hey why are you complaining? Any SQL Server engine worth it's license fee has transactional  roll back, so that if the transaction does not commit you can just let the SQL Server clean up the mess.

Two things that the consultant may not have real-world experience with:

1. Transactional buffering wins the slow-on-the-go award.  If there are one or two records to update, its not a problem. You got a customer address to update - not a problem.  But take 10,000 inventory items that have just been counted in a physical inventory and they now need to be marched out to the data play ground en masse and updated as one big happy collective body of 0's and 1's -- you got yourself a real programming puzzle.   All the tools that Microsoft, Oracle and Sybase offer us for transactional buffering and saving will have us out playing though recess, and will likely have us out there after school. We know because in version 1 of NeXT®, we used transactional buffering. Time to save a physical with 10,000 updates - more than an hour (sometimes MUCH longer). Now - after rewriting the upload and update routines by adding our own "state-of-the-transaction" bread crumbs and eliminating the use of off-the-shelf  buffering and transactional roll back - less than  3 minutes.
2. If a transaction can launch another transaction (Receiving product into a Warehouse, generates  a cross dock Transfer Out,  and based on options the Transfer Out automatically creates a Transfer In) you have a an ever bigger and tougher transaction mess to code for and handle. Each transaction launches another transaction. What if the last part of the Transfer-In fails? Well then you got to roll back all the other transactions from a completed state to a pending or in process state.

(By the way, I like consultants - they occasionally introduce our products to clients. And who knows, when I grow up,  I may want to be a consultant someday.)

Another characteristic of the transactional  form is that they  are "The Event" or they are "The Record" of a real event.

If they are "The Record",  then these digital events are tied to actual pieces of paper that are the source documents. They in essence mimic a document that was created by hand or generated by another computer system. Think about going to a merchandise mart in  Atlanta, Dallas, LA or (my favorite - because I use to give Open to Buy lectures there) Miami, and placing a hand written PO with a sales rep. That hand written PO is the source document. When you get back to the hotel or back to the office, you pull those hand written docs out of your attache case and hand them to your assistant - Jill or Jack - and they go up the hill and type them into the system.

If the system's transactional form is  "The Event" then the system creates the source documents. Transfers from a warehouse to store, or transfers from store to store are good examples of that. They produce a document that lists what SKUs and how many have been scanned in

Their main purpose is to update the data that is read-by-end-user, write-by-system-only using the business logic that is embedded in the system's source code. We don't want users to just change an item's inventory on hand value without recording what caused the change. (By the way if you do want to change an on-hand value without any business logic, just use a spreadsheet, there is  no need to buy our database application or any other business application for that matter.)

If it was not for the business logic (and the never ending, feature bloating, endless stream of exceptions to the business logic), creating an inventory control application would be a pretty simple matter;  DataWorks  would not have spent 24 years working on it; I probably would not have this job; and there would be no need for me to be typing this blog.

Thanks for the opportunity.