Pat Garrehy knows ERP software. The founder, President, and CEO of Rootstock Software, Mr. Garrehy has over 30 years of management, sales and technical experience as a software architect and engineer. Mr. Garrehy recently sat down to share his thoughts on how ERP software has changed over his distinguished career. Here is Part Two of that discussion. You can find part one here.

Part Two – From Client-Server to On-Premise

It seems that everyone uses the word ERP today but the true thread for comparison are those product based companies of today that manufacture, distribute, service and/ or remanufacture. They use ERP software that can manage the supply chain and has the software to  support engineering, procurement, sales, planning, inventory, cost accounting, scheduling and even financials.

The 1990s

In the early 1990’s we had client-server and Windows and that technology came with many moving parts. You had operating systems, windows, database management systems and programming languages. Integrations to other software packages were difficult and problematic because each software package used their own independent versioning control. Because of this, software vendors had no choice but to put all ERP functionality into a single package, and that caused the software to become bloated with functionality that the customer didn’t need or want. Implementations were difficult and time-consuming because the customer was confused about what software switches to turn off and on.

In this era of bloated software, some of the software was bought from other companies and difficult to integrate even though it was packaged and promoted as one-stop software that had all of the functionality.

The hardware (IBM, HP, SUN UNIX-based hardware) and the database management software (Oracle, Informix, Sybase) were reliable when compared to the Windows software of the time, which was constantly experiencing programming bugs. Large companies whose main plants ran on mainframes migrated to this new client-server architecture. By the mid 1990’s, second tier plants were  running on minicomputers such as IBM’s AS400 Series.

On-Premise

Since the late 1990s, SAP and Oracle have dominated on-premise ERP in large Tier-1 manufacturing enterprises, but primarily as the ERP system at the corporate level. They have not been that successful in being implemented in Tier-2 small and medium sized plants. Therefore, most of what is written about Tier-2 ERP understandably discusses different types of solutions being considered for the large enterprises’ next tiers’ plants and divisions, and how they will integrate with these larger, Tier-1 corporate systems. As late as 2009, Gartner reported only on-premise ERP software vendors in their Tier-2 ERP magic quadrant.

But this on-premise pricing model and the old architecture required you to stuff all of the options in the same software, still burdening every customer with many features that they couldn’t use. This old architecture contained complexities in the use and certainly in the implementations as to which switches to set to ‘turn off’ functionality that they didn’t need.

On-Premise vs. the Salesforce Cloud

Today we see a lot of companies that are on AS/400s running older, proprietary IBM-based systems such as BPICS and MAPICS. These companies are now looking at cloud ERP to lower IT costs, improve operational performance, and get faster deployments and easier upgrades. So now these companies are finding Rootstock.

The Salesforce cloud lets us decide what core functionality should be inside the package and how tailoring can be easily done outside the package. For example, Rootstock has a customer that is an industrial, medical and special gases provider who supplies compressed, bulk and pipeline gases, chemicals, engineering solutions and equipment. They had a special project to track the chemicals and gases for one of their customers, who is one of the world’s largest and highest valued semiconductor chip makers. The solution provided was a combination of the standard Rootstock functionality with extensions that were easily developed using Salesforce technology. This solution couldn’t have possibly been developed in the budget and time frame required with an older on-premise software package, regardless of the functionality of that standard ERP legacy package.

Read Part Three Here