2009 makes 36 years I’ve been working on software. For over 30 of those years, it’s been with MANMAN. In 1978 I was at Thermon as MIS Manager when we bought MANMAN on an HP3000 Series II to manage our inventory, purchasing, customer orders, and accounting. By 1988 I had worked for ASK, left, and started my own company doing MANMAN modifications programming.

In 1998, MANMAN was “Alive and Well” according to the banner we hung in our booth at the CAMUS Annual Conference (see www.camus.org). Another banner proclaimed “It’s Not Time Yet”, a reference to the FUD surrounding the “impending demise” of MANMAN. Large companies were leaving MANMAN for Oracle and SAP and small companies were worried about Y2K. But MANMAN was actually as good for discrete manufacturers as any of the replacement systems at that time.

It was a great year for us, and now a decade later, we still support many of the same manufacturing companies running MANMAN. Almost a thousand companies survived Y2K on MANMAN, with a lot of work from 4 or 5 different competing teams of programmers and a few lone cowboys. MANMAN had a problem with FISCAL Periods, not dates. Dates worked great up through 2050 and beyond.

The ideal format to store FISCAL Period is CCYYMM (Century, Year, and Month). The FISCAL Period in MANMAN is stored in the less optimal format MMYY (Month and Year); i.e. 0198 was the first fiscal period of 1998. Too bad it wasn’t YYMM which would have sorted nicely, but that’s another story. There were several practical approaches to fixing this problem, but the differences were mainly in implementation and deployment considerations such as how easily the changes could be re-created in case of future modifications and where the source code was stored.

Most of the solutions used the same approach. It’s called split-century method and makes do with only 2 digits for YY (year) by assuming that any year greater than or equal to 00 must be the 21st Century (CC=20). Any Year (YY) greater than 49 is in the 20th Century (CC=19). Works great as long as no dates span a century, which is the case with all companies with MANMAN data. At this point in its life, we can say that MANMAN only has 43 years of usefulness left.

MANMAN was at its peak of use in 1998. We had been without enhancements for the decade. As for our customers (mostly on Release 9 or before), now it’s more like two decades. We’ve all managed to do what needed to be done to run large, mid-sized and small manufacturing enterprises with MANMAN for two decades with a minimum amount of resources and money. Two decades without upgrades! It’s been a great two decades.

HP stopped selling hp3000s in 2002, but over six years later there are still no clear reasons to migrate. Some package does some things better than other packages; they’re all different. Will there be real reasons to migrate ten years from now? In 2018? Probably, and I’ll believe it when I see it…

The best hope I see for the future is Open-Source ERP Software. There’s just no other way for small, lean manufacturing companies to afford ERP. The main reason that Oracle and SAP will be doomed in the mid-market is the cost of their annual “maintenance”. Large companies may be able to negotiate their “support” contracts down to 18%, but those who pay 25% (and more as time goes on, just wait and see), will eventually rebel. For the kind of money it costs to “completely repurchase” the application every 4 or 5 years, lots of in-house expertise can be acquired. And those resources will be working on what you need, not on what will sell the next copy of Bloated Apps’ to their next prospect.