Musings on inventory tracking behind the scenes after another annual SparkFun Inventory Day is in the books.
Here at SparkFun we have a big warehouse filled with stuff. A lot of that stuff you see here on SparkFun.com for sale. Most things we only have a few of or a few hundred of. The most of one thing we ever had in stock that was for sale was our 6 Pin Arduino Stackable Header. While today we have just under 10,000 in stock, back in June of 2010 we had over 78,000 readily available. That’s a lot of headers!
We don’t sell everything we stock. Many of the widgets available on SparkFun.com are built on our production floor and many of them use parts that we don’t sell. Here the parts get smaller and the numbers get bigger. The champion for most-used product here is the original 0.1μF 25V capacitor. While today we have about 200,000 of these in the building we once had almost half a million (again back in 2010 - an interesting year for our stock numbers). It’s a versatile little cap that appears on over 200 of our different products in various quantities including 22 on every Quadstepper Motor Driver Board. We also sell them in strips of 50 but that doesn’t really count.
All told, there are about six million things in our warehouse spread across about 4,000 SKUs (stock keeping units, or distinct items). We have a big database for keeping track of these things and we rely on the database and reality agreeing. If they don’t then we can’t build things or ship orders the way we would expect to. So, every so often, we shut down everything and count all the things.
Some of you may already be familiar with these Inventory Days. We typically close up shop for the day so orders don’t ship and widgets don’t get built and the stock generally sits still so it can be counted. We do inventory days once a year and last Friday was our most recent. While some you were patiently waiting for us to finish up so we could ship orders once more we were busy as beavers as evidenced in this time lapse video:
It’s a lot of work but it gets easier every time as we learn and adapt. Some of the first inventory days, when our warehouse did not contain the millions of dollars worth of hardware it does now, were comparatively disastrous. Among the worst I can recall was uploading a CSV file with manually typed (read: error-laden) stock values into a script that crunched over the live database to update the numbers. Jordan, our now Director of Inventory, would probably cite the time we hired a third party company to come count things for us as among the worst blunders. Turns out they hadn’t much experience counting small electronic bits and bobs and made some very bad assumptions.
But why put ourselves through all this pain? Well, we want our database to remain close to reality for obvious reasons. After all, any database is a model of supposed reality, not the other way around. If the two disagree it’s the database that needs to change. There’s also an auditing component - we have an emergency line of credit based on the value of our inventory. It’s the kind of thing we can tap when a comet vaporizes the top floor of the building and the bank doesn’t just take our word that we have as much in the building as we say we have.
Is there a better way of counting everything besides shutting down business for a day? Sure! It’s called cycle counting and involves counting everything continuously throughout the year a few SKUs at a time. With limited resources, though, one must be smart about what gets counted when and how often. Cycle counting is a supply chain art form about which many books have been painstakingly written. To do it effectively one needs to know where everything is. And that gets us to one of SparkFun’s biggest challenges ever: Inventory Location.
Right now we have a pretty extensively built back-end to SparkFun.com called Sparkle. Sparkle knows that we have 200,000 0.1 μF 25V capacitors in the building. But that’s as far as it goes. If half the stock is on a shelf in production and the other half in a separate back stock area, well... Sparkle doesn’t know that. Fortunately we have people that do but it makes counting all locations take a lot longer than it should. And regardless, Sparkle only knowing stock numbers at the in-the-building level means a human must:
a) know all the locations of a thing, b) count all the locations of said thing at the same time, and c) enter the total of all locations into Sparkle before any one location changes.
This is near impossible for many products because they are found in several places for good reasons. Some places fluctuate stock faster than others and stock moves around. If (instead of freezing the entire works) we could freeze a single location, count it, book it, and unfreeze it... well then we’d be getting somewhere. This is why inventory location is so important and far more than just knowing where stuff is.
One of the things I do at SparkFun is oversee the group that builds and expands Sparkle. When it comes to nuts that are tough to crack, inventory location is a strong front-runner. Sparkle has its fair share of technical debt. In the plainest of terms: the way Sparkle keeps track of stock, a way that has worked for us since SparkFun was a wee fraction of its current size, does not transmogrify to location-based inventory very willingly.
I think of it like trying to get a dirty cat into a bath tub. If you’re so determined you will get that cat in and clean and back out again, but those claws will embed themselves in every soft surface (including and especially human skin) while attempting to impede the process, if you’re not careful. Bathing the creature while sustaining minimal injury (to both cat and bathers) is of paramount importance. The cat may get away from you and hide on your first few tries forcing you to repeatedly start over. Having a few skilled cat-cleaners on your team is a must. Determination and time are your best allies. Also catnip.
Fortunately by now the cat is in the tub (to continue the metaphor). He’s coming clean despite much wailing and flailing but nobody’s yet been painfully scratched and we aim to keep it that way. Completing the task with minimal pain to our production and inventory teams is of paramount importance but is secondary even to our customers never needing to realize such a shift is happening behind the scenes.
At this point we have a pretty clear road map that details the winding path from Sparkle’s old-school inventory tracking system to the high-granularity hotness of inventory location. It meanders to evade the very disruptions that would undermine the efficacy of the effort. This map came after much probing of the problem space by generating experimental branches of code and abandoning them. If there's one thing I've learned battling technical debt over the years it's this: Action without direction roughs out the shape of the problem but it cannot solve it. It is, however, among the best ways to define the map that will see you ultimately through to the end.
With any luck, last Friday’s inventory day will in fact have been our last. Then, as we look forward to moving into our new headquarters in roughly a year, we’ll be able to shelve all of our gear, know where it is, know how much we have, and keep it up to date.
It’s far from the sexiest project to work on but it’s what makes business go.
Yeah, cycle counting was actually pretty straightforward when I was working for a meter manufacturing company. I'd come in to work to an inbox full of kits to pick and fulfill and assorted random parts bins to go and inventory. I miss the counting scale the most - weigh out 30 or 40 of a small part, then dump the rest on the scale and let it tell you how many you had. The worst part was when the computer asked me to inventory a part that was in a location that had been moved several times over the years, so I would end up killing a half day looking for that one bulky item that everybody kept tripping over.
I worked at Mushkin (RAM company) in the past, and we did inventory counts monthly. We usually did it to make sure we could fulfill orders for about 3 weeks (we got about 1,000 units of RAM in a day). It got to the point sometimes that myself (Production Design Engineer) and the test labs would have to come in on a Saturday to do our testing because we were about 2 days behind order fulfillment.
Over the course of my tenure there, we had a persistent anonomoly of 5 RAM sticks not being in the inventory. We had no idea where they came from, or where they should go. The manufacturers we bought RAM from couldn't take them (not on their books). It was a persistent joke that we'd give those to people who were fired.
So I commend you guys for taking an ENTIRE DAY to count all your parts. It's a thankless task, but it has to be done.
I am glad that I never worked at a company small enough to not have a cycle count team as part of the inventory control group. Been through several MRP systems that manage inventory in multiple ways that make basic parts management a walk in the park. At my current employer, we recently implemented a module that tracks our SMT parts down to the feeder, reel, and location on the machines. The machines communicate in real time as they are consuming parts and update the inventory. Each feeder has an RFID tag so when a reel is associated by barcode to the feeder, we know where that part is when it is on any machine.
Now that's some sophistication. Was implementing that module carried out by internal staff of a contractor? What MRP are you using there, and which in your experience seems like the best piece of software?
The implementation was driven by the company's field tech(s), but a lot of leg work was done by our internal staff as well. The system runs on a foundation of Cogiscan's hardware/software...(cogiscan.com). As for MRP, we are using Infor LN (http://www.infor.com/product_summary/erp/ln/) and with the right set of skilled people, it works well. It is really not designed for a CM like us, but should be much better for a small OEM like Sparkfun. Much cheaper than SAP (which I loved at my last employer, Jabil). I don't recall the system we had at HP when I was there in the early 90s.
So what you're saying is we can count on SparkFun?
thank you for this.
You've mentioned Sparkle a few times already in the news posts. Do think you could ever show us more of the system? It seems pretty interesting.
See brennen's comment about open sourcing Sparkle, a long-stated goal that remains but is tricky to execute in a useful way.
One issue we've always faced with Sparkle internally is training. One of my big projects for 2013 is producing a series of training videos for underlying concepts and stable interfaces (Sparkle changes fast - both an asset and a liability). Maybe I could cut together some of the more interesting overview bits for a brief video for everyone to see. It's nothing close to being able to use Sparkle, but it's a start.
I remember hearing Nate earlier last year allude to making portions or all of Sparkle available for other open hardware maker companies. Not sure if this was going to be an open-source license, an agreement between just a few companies and SparkFun, or if the idea's been dropped altogether.
For what it's worth, this stuff is hard to do for the small and aspiring open hardware companies out there. It would be super awesome to have something like this available to help.
Regardless, I love that you guys write about your trials and what you learn. It's great.
Not sure if this was going to be an open-source license, an agreement between just a few companies and SparkFun, or if the idea’s been dropped altogether.
If we can pull it off, I expect that we'll publish a subset of Sparkle under the GPL (some of it's so specific to the business that it's basically useless outside these walls, some of it's so crufty that we'd hate to inflict it on an innocent third party). It's a tricky undertaking, but it's still very much something we'd like to make happen.
You might keep an eye on this repo if you're at all interested in the libraries and such we've written in-house. I'm looking to release our web app framework and some related things early this year. Lightweight MVCish PHP frameworks are a dime a dozen these days, but I suppose it's a start.
Excellent, thanks for the reply! Looking forward to it.
I see Nate has been learning from the Pros ! He personally buys the land and (maybe) builds the building, and then rents back to Sparkfun at more than the going rate. An almost tax free of extracting money out of the company !
Ah, I remember my retail management days doing yearly inventory. The owner always hired a 3rd party to come in and count everything. They'd trash the place. It would take days the straighten the store out afterwards.
I don't miss retail one bit.
(Yeah, and Richard Parker does look a lot like Steve Jobs from the late 90s: http://bestmacs.com/home/wp-content/uploads/2011/08/imac_introduced_jobs.jpg)
Might that by RGIS? I worked for them for a while. They do OK work, but their counters (auditors) get paid on how fast they count not how nice your store looked when they were done. (Personal Confession) I accidently demolished a shampoo display at a store once. Every bottle fell down and all of the signage with them.
Using an outside firm is what many companies do is this situation. They can come in off hours or over the weekend so that you never have to stop production. That said, for the kind of things Sparkfun carries, that need to be handled with some care and are best counted with math and a scale you are FAR better off doing it yourselves.
Great post! Thanks for giving us some insight to the behind the scenes that makes SparkFun run.
Of course I assume there will be a dedicated AVC track at the new place. :P
Well, "dedicated track" might be a stretch, but it's being taken into consideration.
Does that mean no more GPS canyon from heck?
Possibly, we'll have to wait to see. But hey! This year's change of venue should be free of any pesky GPS dead zones!
What are you using to rotate your timelapses? I am going on an international trip next month and want to build a rotating-time lapse platform for either a Panasonic FZ-100 or an iPod touch... any ideas? I only have this month, so ASAP is greatly appreciated!
The rig is an eMotimo TB3. It's basically an Arduino Uno, two stepper motors, and a Wii nunchuck for setting control points and parameters. Many of the parts are sourced right here from SparkFun! It's a terrific rig and quite easy to use. If you have the means I highly recommend picking one up.
:O $730?! Definitely dont have the means yet.... Looks like a really sweet right though...
I was just thinking a small stepper connected to the internals of a cheap walmart timer, and just take off the spring loaded stuff.. Make a nice case for it, hook up and LCD and I would be good to go. However if I could find a pre built gearbox that would be better I would probably get it... Hmm...
what if you had an RFID tag on every tray and box of components, along with an rfid reader/terminal in each room that stores parts (for immediate use or storage)
walk into the store-room, punch in '0.1μF 25V capacitor' and it tells you which shelf its on, you fetch it, and check it out like a book on the scanner as you leave the room
then check it in at another room (production)
when done, check it out of production, go to storage, check in, and it tells you which shelf to put it back on, so the next guy can find it
that can solve the question of where each container is, so you just need to track what is in the container
you would also record parts used, when you do the checkout at the production room, before taking it back to storage
the computer system can then know how many times a container has been handled, and issue a count at set intervals
We do something very similar to that using laser-scanned bar codes. This gives us strategic day-to-day part flow data; the manual counts, whether they're on everything or one part, are there to find and remedy all the little mistakes that happen from humans being in the loop.
yeah, thats where it would be useful to track how many times a container has been handled
after being handled 20 times for example, there is a decent chance that somebody messed up, count it again!
but if a box is only handled twice, you know the chances of a mistake are much lower
barcodes work just as well, cheaper to tag the items
Which works well, except for situations where someone grabbed something out of the wrong box, or a box has an item with a low vapor pressure (e.g. AA batteries). There is a lot of experience and wisdom out there we're drawing on, and we have our top people working on the problem.
that poor cat D:
I forget. Does "high granularity" mean bigger grains or smaller grains? Wouldn't "more granular" mean bigger chunks? I know a lot of hacking/engineering writing has used the granularity low-information-gambit the last couple decades. But really, how about "finer" or "courser" or greater or lesser resolution? Anyone with a high granularity vocabulary have more precise words?
I think the thought experiment here is to imagine something that isn't granular, then something that is, then place them on a continuum with the "more granular" direction pointing toward the granular thing and the "less granular" direction pointing to the not granular thing.
If I recall, there was once a post around Sparkfun switching to SAP. The one thing about SAP that I love is the Functional Location concept, and its versatility in allowing you to break down the number of levels. That along with SAP's close ties to Document Management system makes inventory management a breeze.
Imagine being able to quickly navigate by either location or item type, and then pulling up all comments, notes, datasheets, drawings, etc associated to the product. Great for every department in the organization, from inventory control to engineering.
Full disclosure - I'm a Enterprise Content Management consultant, with experience in SAP tie-ins for engineering documents.
SparkFun did go through a grand "should we drop Sparkle and move to a third-party ERP system" conversation that took about all of 2011 to unfold and resolve. During that time there were a couple of posts that alluded to what was happening behind the scenes including this one and this one.
SAP was considered for all of a few seconds. It was painfully clear that SAP's scale, scope, cost, and reach were all way too much for SparkFun. Even if we grew by an order of magnitude SAP would exert a toxic influence over our internal operations and culture. It was never in contention.
Now that's not to say we can't learn anything from SAP as we build out our own back end. But we take those lessons with a massive grain of salt and then simmer them down to the kernel of wisdom underlying the cruft before working it into a solution with much lighter footprint that's maintainable in-house. What we come up with may not be a one-size-fits-all, but it will always fit SparkFun.
I am surprised you guys don't come up with some form of RF tag to help identify where things are located and how many of part 'X'.
A barcode works way better for marking locations. It's cheaper to implement, can be read by a cheap scanner or pda/phone, and can be printed by any printer.
As a former inventory manager at a Walmart store, I feel your pain. They have developed a pretty robust system of every physical location in the store having an ID number in the inventory control system. If something is removed from inventory in the back of the store, it is scanned and it's new location is inputed. If something was returned to the back room, the reverse was done. It was a pain getting used to, but probably the best way to handle things.
Just out of curiosity, do you actually count all of those small bits, or do you count them by weight?
It varies by item. Each item is marked in our database as having a distinct "count type" and four types are available:
Nothing like lifting the box of 50 pounds of Chicken and feeling you are missing 3 five pounds bags light. Cant do that with a box of 1000 resistors and missing 200.
You guys should have a fire sale on your overstock. Throw those headers in a 10-pack for a buck. You'll get rid of them in no time!
Is that Richard Parker or Steve Jobs in video? O_o
Now that you mention it, we've never seen both of them in the same room at the same time...
It probably isn't Steve Jobs. Through-out the entire span of time both he was alive and You-Tube existed he could afford to pay several people to wash an arbitrarily high amount of different cats per day, each and every day of the year!:p
Can we assume, Cat=>Catnip, People=>BEER?