Inventory Control Experts
Blog
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.
Posted: 2010.03.03
It’s the morning after the super bowl, and I just looped through the company canteen, where our football fans were talking about yesterday’s game. Our take away: Great coaching and leadership. The Saint’s coaches took some bold intelligent risks – and in our Monday-Morning analysis, the leadership made the difference. Congratulations New Orleans Saints. And congratulations NFL – it was a great BOLD football game.
Two other events that are important for Monday, February 08, 2010:
- The Boy Scouts of America celebrate their 100th birthday today.
- NASA launched the Space Shuttle for the last time at night. It’s payload: the last major piece of the international space station.
Living in South-West Florida, I had not witnessed a night-time launch, so I set my alarm to 3:45am. Upon waking I logged onto the internet and checked the weather for visibility and NASA for launch progress. Everything looked AOK, so I hopped into my car and drove east towards the Everglades.
Monitoring a radio station that was covering the launch, I drove until T-minus 60 seconds, pulled over, oriented my compass to a heading of 20 degrees, and waited.
The announcer called the lift off, and 45 seconds into the flight, I saw a red beacon burning on the horizon. The tight bright ball stretched into a road-flare flame that arced up into the morning sky.
Standing along the roadside, I watch the booster’s blaze for 6 minutes. When the engines glow became the same intensity as the stars, I slid back into the car, and with a deep melancholy I drove back home.
Posted: 2010.02.08
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.
Posted: 2010.01.26
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) :
- 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.
- 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).
- 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.)
- 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)
- 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.
Posted: 2010.01.14
If you have been following this blog and been wondering how DataWorks is planning to compress time and jump over some of the low hurdles lined up along the space-time continuum you can leap over “The Boring Bits”, and race down to the plot-spoiling, “10 Second Solution” finish line below.
The Boring Bits
When we started designing NeXT® back in 1998 our primary thoughts were: get the inventory data model correct. The first line of the ARMS™ system had been written way back in 1984 – two years before DataWorks was even founded (more on that later). It was a very good system for the time, but it had many design limitations that prohibited it from growing into an enterprise system capable of managing all the purchasing and inventory needs for the hospitality and entertainment industry.
NeXT was a total rewrite. We used all of our collective experience to scope out a system that would tackle all the problems with the ARMS system and take DataWorks into the 21st century.
ARMS had a whopping 67 data tables that stored all the information of our inventory control system.
At last count, NeXT has over 520 tables — and it is still growing.
If you put the two systems side by side, entered the same purchase order, then received the same partial packing slip with a 100 products, ARMS would actually beat NeXT in a “save-the-receiver” race. Two reasons:
- We are tracking and storing MORE information with NeXT.
- ARMS was written with an 8 bit 386 processor in mind.
We knew that we had MORE data, but we figured Moore’s Law would take care of the details. We really banked on Gordon E. Moore’s prediction that the number of transistors on a CPU would double every two years. Those additional transistors would translate into faster processing time and what ever programs we wrote would be quickly executed by Intel’s chip du jour.
Moore’s law has held true, (and probably will until the transistors reach the molecular level – 2015 or 2020 depending on your favorite forecaster/futurist) but the speed of the computers have not doubled every two years. Computer speed has plateaued. Back in the late 80’s we purchased a new computer every year. Jumping from a 286 10 MHz to a 386 16 MHz or getting a PC with a red turbo button on it, meant you were going to get some immediate productivity increases. Now, our R&D group only gets a new PC once every three years. The computer I use today to write code with is maybe 20% faster than the work station I used three years ago.
Maybe someone can find a graph that compares transistors density to processing speed and add it as a comment.
The other technology we bet our ERP ambitions on were hard drive space and hard drive access time. Back in 1986 a 20Megabyte hard drive with 65 millisecond access time was standard gear. We had to be very stingy with the data we kept – in fact the first versions of ARMS did not have historical sales because there simply was not hard disk space or time in the day to save it or report on it.
Think about this metric. Hard Drive storage space has kept pace with transistors (I think there is Law for that too, but I don’t know what it’s called. Comment anyone?), but access time – the all important go find the data and present it to the end user benchmark- has been sitting on top of a plateau for a long time. I remember the huge jump in 1988. We went from 65ms to 24ms access time and ARMS tripled in speed over night. I think we actually jumped from our desks and cheered. Today’ s hard drives (circa 2010) typically have 9 millisecond seek times. Now DataWorks does own some really fast gear that is used in our ASP server farm – I understand those drives have 2 millisecond seek times. So what is that in terms of speed improvement? To go from 24ms to 9ms is great – but – it is only 2.6 times faster than 1988. For a 22 year time frame that is really not much of of an increase.
What does that mean? In 2002, when we shipped NeXT, we got the system we designed, but we shipped a slower system then we expected. We wanted a fast turning, quick accelerating, dog-fighting F-16 Falcon, but what we delivered was a big, heavy, F-105 Thud. (This is a shout out to Col. John Boyd – more on him later.)
One trend that appeared in computer design that might have helped us speed up our application was the introduction of dual and quad core computers. That means 2 or 4 or more CPUs are huddled inside one computer. If the first CPU is busy, the second, third or fourth CPU could theoretically pick up the slack and crunch the data we are saving.
All that is well and good, but that is not how inventory transactions work. As I described way back in Part 1, inventory transactions are like a factory assembly line, you step through each process and do each step in sequence until you get the final product. In our factory that final product is recording the event, updating the merchandise value, satisfying the accountants, and generating analysis data.
What this means is that we can not compute on hand values independently from on order values. It would really speed things up if you could assign each CPU within the computer a separate thread of logic: You – CPU #1 – take care of the cost calculations; Hey buddy – that’s right Mr. CPU #2 – you work out the new On Order quantity for the purchase order; you over there sulking in the background – Corporal CPU #3 – front and center, march over to the parade ground and computer the On Hand values; and Charlie CPU #4, step outside to the internet and grab the current exchange rate for the EURO – hurry up, because CPU #1 needs it to calculate the new landed cost. And – oh by the way – while all of you are concurrently working on the same inventory records, play nice and don’t step on each others data.
Thread computing has very limited use in the business world that I live in. If DataWorks was in the weather forecasting business we could use all that CPU muscle to concurrently crunch and test various models to predict the weekend beach forecast, the pollen index, or how many named hurricanes are going to make North American land fall.
DataWorks is first and foremost in the inventory operation’s business. We do some serious forecasting for purchases orders , but our current needs do not require concurrent threads to predict the vendor-lead-time usage for an item, we do that by jumping over one hurdle at a time.
So to wrap up these boring technical bits:
- DataWorks is stuck with this kind of programing: do step 1, do step 2, do step 3, … until we finish with the last N process.
- The whole world is stuck on top of the current computer-silicon-hard drive -hardware summit. The landscape ahead is gentle rising plateau – there are no big productivity jumps on the horizon.
10 Second Solution
First off – lets state the obvious, if you are running NeXT on your desktop in a LAN or TS environment, just start running another copy of NeXT on your desktop. If you got one copy crunching a big receiver, just start another session of NeXT and go work on that second task. We don’t license our software by the seat so have at it. Now if you are using NeXT hosted on the DataWorks ASP Farm you could also start another session if you have subscribed for the additional log on (hey, we got to make money too).
But In version 7 we will adding something to NeXT that will make running multiple copies of the software seem like an 8-Track Tape in a 1975 Pontiac Catalina. In version 7, scheduled for release in the 4th quarter of 2010, we will be shuttling transactional processing off to a silent background program so that your current task can be released from the drudgery of saving data. You will be free to start another task — rather than watch a thermometer bar inch its way across the screen.
The plan is for this work to be picked up by the NeXT Service. Currently, the Service really has a pretty easy job. It hangs out by the CPU’s cooling fan, just looking for something to do. It really only stretches it muscles during the night shift, when it takes care of store polling, processing sales, updating the inventory stock ledger, calculating turns, adjusting vendor times, and preforming inventory analysis.
Since the NeXT Service has so little to do during the day, it will be told that an inventory transaction has just occurred and if it would not mind, and if it is not too terribly busy, would it mind picking up the job and take care of it in the digital back ground?
Here are the current tasks that NeXT Version 6 contends with:
- Run the Sales Imports and Inventory Exports (which can be schedule as often as every 3 minutes)
- Send email about polling problems to DataWorks for review
- Refresh the Inventory Daily Stock Ledger with previous day’s inventory transactions
- Roll up Stock Ledger data for Period Analysis (13 week, 13 month, Q5, Q4, etc) for Time-Series forecasting methods
- Compute Actual Vendor Lead Time and Time to Floor by Vendor, Vendor-Subclass and Vendor-Product
- Compute Stock Turns for Sub-Class and Open to Buy Merchandise Classifications
- Generate Suggested Orders
- Roll up Stock Ledger Data for Open to Buy and Budgeting Modules
In version 7 of NeXT we will be adding these additional tasks to the NeXT Service :
- Query and publish inventory reports to a subscriber of end-users.
- Generate Suggested Transfers
- Handle “large” inventory control transactions for the end user
In Version 8 of NeXT our plans are to open up the Service events to the end user community and allow expert users to configure and define their own procedures to be run by the NeXT Service.
That is when “things” should really get interesting.
Posted: 2010.01.12
My name is Mark Cecil. I am the co-founder and CEO of DataWorks, Inc. I started DataWorks in 1986 as a custom software house. When we opened our doors our motto was “Write code, be creative, have fun, make money”.
There was no business plan to become the best-of-breed leader in retail inventory control for the hospitality and entertainment industry. How DataWorks got here will be the subject of another blog post (or two).
My background? Born in 1958, I grew up on a family cattle and tobacco farm in Cecilia, KY. I moved to Naples, FL in 1969 two weeks after Neil Armstrong walked on the moon. My dad – Bill Cecil – was a high school math teacher. He and another math teacher (Roger Otten) wrote a grant to the Digital Equipment Corp where they asked for and were awarded a massive room-filling, card-reading, paper-tape punching, two terminal computer for Naples High School in 1972-3. I think it was a DEC PDP-8. I remember this “serious” row of orange and yellow toggle switches that you used to boot the computer with. Click here to see what the room kinda looked like.
My first line of computer code was written in 1974 when I was 15 years old. My dad was looking over my shoulder as I punched in my first statement. I owe a great deal to his vision. That opportunity was pretty special. And if you were going to find the spark that lit this company’s fire, it could be traced back to that moment of combustion. Based on that, I am now going to bestow the title of “DataWorks Digital Daddy” to William H. Cecil. Business cards are now being printed…
I set off for college to be a Botanist. In my junior year, with a 3.8 GPA I switched my major to Studio Art. I received a BFA in Painting from FSU in 1980. I followed that with a MFA in sculpture from the University of Cincinnati.
As a professional fine artist working in Ohio, I got my hands on a series of personal computers (Atari 400/800, Apple IIe, Kaypro 10) that re-kindled my original digital ember. I taught myself assembly language for the Motorola 6502. Using Byte magazine’s monthly feature, Circuit Cellar by Steve Ciarcia, I learned a great deal about hardware and interfaces.
I spent my spare time loitering around Radio Shacks, raking though their discount bins looking for inexpensive TTL and CMOS integrated circuits. The three chips that still come immediately to mind are the : 7402 (nor gate), 555 (timer) and the 4017 (decade counter) . With an artist’s salary, I built rather than bought technology. I bread-boarded and wire-wrapped computers based on the Z80 chip. I etched my own circuit boards, built an EPROM burner, hacked together a frequency counter, and wrote a primitive OS for my sculpture’s behaviors.
My most ambitious project was coding a CAD-3D modeling tool in Basic with machine code calls to handle the rendering. My plan was to exhibit my sculptural models in a gallery full of monitors with my digital wire-frame drawings. I was becoming more of an engineer than an artist.
As I was designing and building robotic sculptures, I had an opportunity to write a mail list management program for a community arts center where I was employed as a curator. I wrote the program in dBase II. The year was 1984.
I have been writing business applications in dialects of the dBase language every since.
My retail background is also seeded back in the 1970’s. My part-time after-school job was at a contemporary apparel store called Jamis. The store is still owned and operated by a husband and wife team (Ed and Fredi Verdesca). I started the job as a janitor. When I left for college, I was still the janitor, but I was also the accounts receivable and accounts payable clerk.
Later on in the late 1980’s and early 1990’s Ed Verdesca would be an important business mentor for me. Ed had worked for IBM in the 1960’s and with his savvy for fashion apparel, I learned the operational side of the retail trade from a system’s analyst point of view. Without Ed Verdesca’s early input and guidance, DataWorks would not have ended up focusing on inventory control.
There are a lot of other important events and people in the history of DataWorks. I have seen ups and downs, success and failure, and learned more than I have taught. I have made lots of mistakes. And – I have been lucky. It has been — and still is — a very enjoyable journey.
The purpose of this blog is to document the journey, share the vision, and build marketing presence for DataWorks. I will probably write the first dozen or so entries, but I plan to share the writing with other talented DataWorks’ team members. The topics will be shelved somewhere on these library stacks: art & design, computer business applications, or inventory control operations.
If I wander into topics that touch on aviation, scouting, marriage or being the father to seven children it is because these are the other passions that make up my life.
I hope you enjoy the effort.
Posted: 2010.01.10
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:
- Our 3 year old son is not fond of washing his hands.
- Our maid is a Roomba robot who is long on determination, but short on suction.
- 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.
As I stated earlier, 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.
- Printing of the sales receipt can mask the time to save the transaction to the database back-end.
- Popping the cash drawer will absorb a second or two of transaction time.
- 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.
- 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.
- Verification of ID, with the inspection of a Driver License Number or Phone Number eat up enormous amounts of CPU clock cycles
- 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.
Posted: 2009.12.05
Retail Inventory control operations have been DataWorks’ focus for the past 24 years.
We design systems to assist buyers in creating purchase orders; receivers to process packing slips, auditors to review costs, and controllers to generate accounts payable invoices and credit memos.
One of our design tenets is that user input time on heavily-used-forms is very expensive – so we try to spend our CPU coin wisely. If we can shave a half a second off a process, that half second gets multiplied by all our end-users doing the same process every single day. A billion here, a billion there, pretty soon it adds up to whole lot of time for running reports, re-ordering fast movers, or dialing in a pizza.
Notice that our tenet has a condition – “Heavily-Used-Forms”. If a form is used to launch a one time process or it is a rarely used configuration option, we don’t spend our R&D budget on making the form into a high performance, code-injected hot rod.
Speed to save and process a transaction is of extreme importance. If a transaction takes over 10 seconds to save then the end-user’s cranium shifts into idle and the neurons start filling their synaptic gaps with sudoku puzzles and we fail in our efforts to get more data for the price of one transaction.
The receiving transaction is the core of our inventory control operations - It has a lots of moving parts and it generates a lot of transactional heat. When the receiver clicks on the process button, he or she is kicking off a big assembly line of linear processes:
- Accommodate Units of Measure, Currency Rates, Terms Discounts, Freight Charges, Cost Changes and Vendor Allowances
- Consider the employee’s access rights and privileges
- Update Inventory Quantity On Hand, Quantity Received, and Status
- Flag an Item for the need to update the Stock Ledger *
- Update a Purchase Orders’ Quantity On Order and Back Order Status
- Calculate Base Cost, Net Cost, and Landed Cost
- Update a log for any shifts in cost or retail
- If merchandise price tags are needed, generate a Ticket Batch
- If a Packing Slip, generate a General Ledger journal entry to book the Asset and PO-Clearing accounts
- If an Invoice, generate an Accounts payable Invoice with the appropriate distributions.
- If allocating to more than one outlet, generate one or more Transfer-Outs.
- If Transfers are set to process in one step versus two, process one or more Transfer-Ins.
The bad news is this gymnastic routine takes much longer than 10 seconds to stick. With large receipts of over a 100 SKUs just the calculation of new costs take longer than 10 seconds to execute.
By the way, the one thing that does not occur here is a posting to our Daily Inventory Summary system. Notice the special * above. We set a flag but we don’t do any actual work. The summary table is a daily stock ledger that is used to track various pieces of information such as beginning on hand, net sales, discounts, receipts, returns, markdowns and shrink. We decided it would take too long to update the core of our analytical system. And since the stock ledger is not a requirement for daily operations we reasoned that it could wait and run at a later time.
This is actually a clue to our design thinking. Operational events are linear and need to occur in the users’ time frame; analysis and data crunching are not time sensitive. Analysis can run a minute, a hour, a day or even be regenerated a year from now.
So how can we speed up operations but deal will the need for real time information?
That will be the subject of our next post.
Posted: 2009.11.30
|
Green Statement | Contact Us | Home
DataWorks, Inc. – NeXT® Inventory Control and Purchasing System - © 2010