Daily Archives: April 17, 2014

How BizSlate is Bringing Sexy Back to ERP! Part II

As per our last post, ERP used to be sexy, but hasn’t been that way in a while. That needs to change, because ERP should be sexy. Fortunately for us, BizSlate has decided to do something about it. They agree that ERP should be appealing, exciting, glamorous, trendy, and just a little risqué and are doing something about it. In our last post, we discussed what they are doing to make it appealing, exciting, and even glamorous. And if that isn’t enough to whet your whistle and take a look at what a modern ERP should be, today we’re going to discuss some of the things they are doing to make it trendy and even risqué!


When it comes to ERP, Icona Pop got it right:

You’re on a different road I’m in the Milky Way
You want me down on Earth, but I am up in space
You’re so damn hard to please, we gotta kill this switch
You’re from the seventies, but I’m a nineties bitch

Fundamentally, ERP hasn’t changed since the nineties, which is two decades behind where it needs to be. When ERP came out in the late 80’s, the World Wide Web didn’t even exist. It was 1992 before the first commercial sales website was put up, and 1995 before the US National Science Foundation lifted its strict prohibition of commercial enterprise on the internet (which, as per our recent history lesson, was almost immediately followed by the release of the first commercial spam — damn you, NSF!). One-click on-line shopping? It wasn’t even a pipe dream! By the time Amazon.com hit the mainstream in the late nineties, the ERP, formally defined by Gartner Group back in 1990, was quite mature and, like an old dog, unable to learn new tricks.

That’s why BizSlate went back to basics and rebuilt its ERP from the ground up. This allowed it to replace old-fashioned OLAP with real-time reporting, offline down-time forecast generation with real-time what-if forecasting, batch-mode accounting/procurement system integration and reporting with real-time integration and query execution, etc. For the first time in over a decade, ERP is trendy again — and it’s not even 2038!*


It’s disruptive — in addition to the appealing, exciting, glamorous, and trendy features discussed above, it’s re-built the ERP from the ground up to follow and support the life-cycle of the product through your supply chain. Additional features that have been included to support this are cross-reference SKUS, which allow you to track, and use, all of the different SKUS used by your suppliers and customers seamlessly and interchangeably; a full-featured web-based API that allow a front end interface to be developed for any web-based browser (so a slimmed down interface can be developed for your smartphone, should you so choose, and their product already supports the iPad, allowing your sales people to check product availability and take orders in real-time on the trade show floor with 100% confidence that all promises made can be kept); support for multiple types of e-Document exchange and the ability to define the type of e-Document exchange (EDI, XML, e-mail PDF attachment) that will be used with each customer or vendor for each type of communication; fine-grained roles and responsibilities and appropriate support for company, agent, supplier, vendor, and licensor representatives; multi-order receiving capability (which isn’t even found in mature products like NetSuite), multi-order shipment update; an API for shopping cart integration (in alpha); etc.

All this is in addition to the unique bulk order functionality, tight GL integration, multi-edit capability, pre-pack/re-pack functionality, and document generation discussed in our first two posts on how BizSlate is ERP for the Small to Mid-Size Distributor that was Released to Mid-Sized Distributors and Retailers to the Masses last year.

BizSlate wants to redefine what it means to be ERP. And bring sexy back to ERP.

* ERP hasn’t been trendy since it was promoted as the cure to the year 2000 problem, brought about by mainframe, mini-computer, and windows programmers that decided to save bytes by representing years using two digits instead of four. The next impending disaster isn’t until 2038, when all Unix-like systems that store the system time as a signed 32-bit integer, reach their maximum value. (Unless, of course, you think the Network Time Protocol will fail when it reaches it’s max value in 2036.)