An update to Sparkle

We updated Sparkle and it slowed some things down. We're hoping that it will speed things up moving forward!

Favorited Favorite 0

SparkFun’s Inventory day was Friday, January 15th. (We have a cool video detailing Inventory Day, you should check that out.) We currently have to do inventory day because we don’t have a system of cycle counting in place. Cycle counts allow you to periodically count inventory in conjunction with an audit plan to slowly count your inventory over time.

We are a big enough company now that inventory day is more disruptive than fun. We needed a way to upgrade our internal ERP system, Sparkle, to support cycle counts. Sparkle is built internally by our software development team, so it was on us to build these tools.

We built a new, shelf-based system with a suite of transfer tools that will allow us to move part locations around, based on their actual real world location. The tool even models our carts, whether they are in inventory transfer, receiving or shipping. When you place something on a cart to move it to a different part of the warehouse, the system will reflect that. We now have shelf/cart level knowledge of our inventory across our entire warehouse.

alt text

We knew that successfully deploying the location data would be a challenge. We would first need the data, and we’d have to test all of the functionality of the associated systems. We decided, after much hand wringing, to deploy in conjunction with inventory day. It was a risk, but it is a risk I defended, and still defend.

We started off with a bit of a backlog of orders. We take orders Thursday night and all day Friday, which would put us at a pretty big deficit moving into the weekend on an average inventory day. Our auditors decided to do some extra counting Saturday; we really didn’t get a chance to ship anything until late Saturday afternoon. This was going to be the first real test of our shipping tools. A few software devs and I worked all weekend supporting the shippers ‘gamma’ testing the new release. This was slow work, killing edge case bugs as they came up and stopping shipping so we could deploy, and getting them back to work so they could do more testing.

alt text

The entire process took all weekend and a bit into last Monday. Needless to say at this point, four plus days of orders were backing up the system pretty badly. By Wednesday, we were able to leverage the new tools effectively enough to be moving at the pace we were at before. Orders have started going out at regular intervals, and we’ve started the process of fine-tuning all of the inventory transfer tools.

The effort to improve continues now and may never be done. With every step in the process we are finding efficiencies and ways to capture and model data we hadn’t thought of previously. We are creating new support tools and data access dashboards to empower our floor managers to make real time decisions that will make SparkFun better.

While it has been a rough transition for us and for some of our customers (thanks for your patience!), we are making these changes so we can be better moving forward. We regret any inconvenience these changes are causing our customers. We’re hoping that things will be moving a lot faster this week.


Comments 11 comments

  • Congrats on the cut-over, Double M and SparkFun IT! I definitely have a deep appreciation for the significance of that milestone. Literally years in the making, and talk about hand-wringing... pushing that live in conjunction with Inventory Day with auditors lurking about must have been pretty stressful. Next time I can make it out there for a visit I'm buying you a beer, Double M.

    Also from this comment...

    Building this our selves has lead to a different kind of limitations, mostly ramp up time for new developers and decisions you look back on and wonder why

    That's the official pass-time of SparkFun developers, right there. =) Usually it's looking back on something you wrote yourself where you wonder why the hardest. I sincerely hope the new members of your crew are spinning up fast and you're able to make big strides on some of legaciest of the legacy stuff.

    So seriously, from one of the OG's of Sparkle, a heaping massive congratulations to you all. I hope you're appropriately lauded and celebrated by the rest of the SparkFun crew!

    • This means a lot to me, thanks Frencil

      It has been a journey, you can't change a cornerstone of a major system and not expect some big breaks. We are working through those and learning a lot about our old and new processes. Not the best deploy I've ever been a part of but not the worst.

      The team keeps working hard and they are motivated to see this a success. That means a lot to me, too.

  • Awesome. Goooooo Sparkfun

  • I am envious of your opportunity to have an ERP that fits how you work and not the other way around. There is always something "you can't do" with every ERP i have ever worked with. It's awesome you are willing to make the long term investment to get something that works for you! Of course there is risk, but that should be worth the pain.

    • I think the idea of Sparkle being a long term investment is exactly the way we look at it. The Decision was made before I started, but I'll defend this decision. The cost of implementing and configuring an ERP system is also high and it will come with limitations. Rolling our own forced us to look at our business and truly understand what we need to be successful. Building this our selves has lead to a different kind of limitations, mostly ramp up time for new developers and decisions you look back on and wonder why, but we are still masters of our own destiny.

      We are trying to open source Sparkle, not the easiest feat, but it is a desire to give back to the open source software community that has given us so much. Getting Inventory into SparkLib (https://github.com/sparkfun/SparkLib) isn't on the roadmap at this second, but I'd really like to have it in there.

      • I'm glad that you're trying to put Sparkle out as open source. A lot of managers would look at this and think that it could be a "profit center", and it could dramatically change the face of the company (to where the current business is dramatically overshadowed by the software). The down-side to the OSS approach, though, is that will scare off so many [mis]managers (who believe the FUD about OSS) from trying it, even though (to quote Bill Gates [yes, that BG]) "why would someone pay for something when they can get something better for free?"

        Anyway, when you get to where you really want to acid test Sparkle, have another sale like the Arduino Day sale in 2014! (Hint, hint...)

        • We are a hardware company. We sell hardware and we give those designs away for free. We don't sell software, so it makes sense to give it away.

          There is this incredibly hard balance when it comes to something as integral to your business as an ERP system. We can't just take our source code and hand it off to people. We need to have a frame work that is open and then extend that frame work (the real reason commercial ERP's are so expensive, it isn't just the software, its the configuration and maintenance). We need to push what we can into a framework that is usable in obvious ways to the open source community.

          If we get that balance right, we have great software. We are working on making great software.

          • As a semi-retired [mostly] software guy, I hope you'll have great documentation, too! (I've always been amazed at the incredibly poor quality of documentation on expensive software. I remember 25 or so years ago when I got ahold of the manual for MS-DOS. Clearly, they'd spent more on designing the box the thing came in than they spent on writing the manual. I'd have a lot more [OK, "any" is a lot more than "zero"] respect for M$ had they spent about twice as much on the manual as they actually did. Fortunately, given time, OSS often gets, if not "great", at least "reasonable" documentation.)

            • increasing effort on the X axis, quality on the Y axis. increasing hours gets you asymptotically closer to "perfect" documentation

  • you look back on and wonder why

    This is one of the things that so seldom gets properly documented, because when you're writing it's obvious why. I encourage all who write code to include the reason why more often than what. Sure, you've got some data and you're doing something with it. Those who come after can see what you're doing to it.
    Why?
    So it gets properly formatted according to user preferences? That's the way the example did it, and this is copy+paste code? It's the way Pete said to do it, and nobody argues with Pete? Another department said they need it? Because the right way to do it just wouldn't work? Seemed like a good idea at the time?

    Also, as someone who has worked on an ERP with location based inventory for manufacturing, I'm curious how are you actually handling entering the stock transfers in a timely fashion?

    • One of my professors (nearly 40 years ago) used to say that he documented code "for the complete idiot", because usually the "complete idiot" was himself having to go back six months later trying to figure out what he did and why. He also said that 10 lines of comments for each line of actual code were not excessive. (I usually managed to hit around 8 lines of comments per line of code in the work I turned into him.)

      On a tangent, I've learned to NEVER, EVER use single letter variable names, except on the chalk board. Typing in "x_axis_value" takes a little longer than "x", or "for (idx=3; idx<12; idx++)" does take more typing than "for (i=3; i< 12; i++)", but it makes it a LOT easier to do searches for "idx" than just "i" which would catch every "print", "in", or other "things" (like "this" in a comment).

      There's a lot more to good documentation than just comments in the code, but if you have to maintain the code, good comments can sure help!

Related Posts

Recent Posts

Tags


All Tags