Modernization of the Large Enterprise Finance Organization

The following article provides an overview of the ERP market over the last 25 years for large enterprises (LEs). While historically the market overall has been stagnant due to a high barrier of entry for additional players, the adoption of cloud or Software as a Service has created a disruptive event that provides consumers with viable alternative choices.

There are many ERP products that focus on certain niches (e.g. government, insurance) or industry size (e.g. small business or emerging business) that proliferate the market, but for billion dollar entities the choices have been traditionally few and far between. In this context, the options have been PeopleSoft, SAP and Oracle eBusiness Suite. This article will focus on five distinct periods of product evolution for large enterprise ERP and the new modern options available to large enterprises today.

Phase 1: Early Adoption (1988 - 1996)

During the 1980s, large enterprises struggled to run their business effectively. They had disparate systems running on various technologies such as AS400s and mainframe systems. The systems rarely talked to each other and users had to re-key data from one system to another. Files were passed via floppy disk or worse via the "swivel chair interface”. This led to numerous key punch errors, inaccurate data, increased headcount, and non-existent analytical capabilities. The systems that were available typically served only one or two purposes - there may have been one system for general ledger and financial reporting and other systems that managed billing and accounts receivable.

To make matters worse, users kept systems in spreadsheets, documents, custom built applications, and manual ledgers. During this time, Oracle, PeopleSoft and SAP introduced their business applications. The applications brought together many aspects of finance into one system. Each vendor went “deep” with functionality in their core modules (GL, AP, AR) and also added breadth to their applications by incorporating additional business processes like supply chain, manufacturing, and asset management. The solutions solved 1980’s problems, including disparate systems and older technology (e.g. mainframes). Each added market share in selling one solution to their customers to meet a vast number of business needs in one integrated environment. Large enterprises rapidly moved to ERP and each vendor established itself as a leader on the product life cycle chart. This was a growth phase for each product and all three vendors as they pushed their product up-hill to gain market share. From

Phase 2: The Y2K Market Force Boost (1997 - 2001)

Although many LEs had adopted one of these three solutions by the mid-1990s, the products were still in their growth phase and needed an outside event to boost them up over the product development hill into their maturity phase. The Year 2000 (Y2K) scare was just the boost that the vendors needed to increase the overall adoption rate of their technology.

For organizations that had not yet implemented a comprehensive ERP system, sales teams had the final enabler they needed to get them to sign and adopt. Organizations had a choice – continue to “patch and fix” their old applications to make them Y2K compliant OR buy a new solution that had already 100% addressed this problem. The issue with the patch and fix approach was that it was expensive, time consuming and left organizations with an old system whose useful life was questionable at best. Therefore, many organizations chose instead to implement a new solution to meet their needs. The Y2K event was a critical outside market force that enabled change. After the Y2K adopters implemented, SAP, Oracle and PeopleSoft were firmly entrenched as market leaders in the maturity phase.

Phase 3: Stagnation (2002-2008)

After Y2K, the three main vendors competed for market share. Occasionally, a customer would switch from one big vendor’s solution to another; however, that was rare. Organizations focused on expanding the use of the product by implementing new modules and functionality. Organizations also experienced forced upgrades. Every few years, CFOs had to plan for a large disruptive project to upgrade their core financial system. The upgrades were typically measured in months (or years), cost hundreds of thousands of dollars (or millions), and became the #1 project for Finance and IT that year. The article An On-Premise ERP Upgrade Horror Story shares a tale that may sound very familiar to you. In addition, CFOs had to staff a small army of employees or contractors to keep the system up and running in non-upgrade years. All of a sudden, CFOs needed to become experts in their vendor’s products and were required to keep servers, databases and networks up and running so they could enter journal entries.

The “price” for implementing large ERP was now evident and CFOs were asking questions about what it really cost them – “What was my Total Cost of Ownership?” The vendors themselves spent money on product development by introducing new modules and new functionality to existing modules; however, their ability to innovate lessened each year as their products had become too big. For every change they wanted to implement they had to make sure it worked:

  • For all of their customers
  • For all of the different infrastructures their customers ran the application on, and
  • For all of the customizations and configuration the customer had done to the off the shelf system.

The weight of this burden slowed innovation to a crawl. Worse yet, it took longer and longer for new versions to come out. This meant that when customers did upgrade, they were upgrading to functionality and technology that was conceived years ago by the vendor. Technology was moving much faster than the vendor’s ability to integrate it into the application. Users who were accustomed to mobile applications and Amazon-like interfaces were stuck with new features that looked like they were three to four years old (because they were). However, organizations were stuck. They needed to upgrade to stay compliant, and switching to another vendor’s solution that had the same inherent problems was really not viable. Customers would have to wait for a new disruptive technology to enter the market and force change.

Note: Another interesting thing happened during this phase. Oracle bought PeopleSoft, consolidating the vendors from three to two. Oracle now had two competing products for large enterprises. They had to assess where the market was going next and determine what to do with two products both at the same maturity level phase. Oracle decided that customers would eventually move to a vendor that offered a complete technology stack from database to application that they could buy, deploy and maintain just like their existing products. With this new fused application and technology stack, customers could solve the issue of having to piece together technology to meet their needs. The new fusion applications would bring the best of Oracle’s technology together in a new on-premise solution that customers would adopt. Unfortunately, Oracle misread the market as there was another more disruptive technology break through that would drive the next sales cycle.

Phase 4: Introduction of Disruptive Technologies (2009-2012)

During this long period of stagnation, organizations generally concluded that their financial system mostly worked; however:

  • They accepted its shortcomings as the new normal. Over the years, large enterprises built work-arounds to address common challenges of the system (e.g. data warehouses, consolidation tools, additional point solutions, numerous customizations, extra staff to process transactions).
  • They lived with the fact that the systems were expensive to maintain and offered no new competitive advantages.
  • They tolerated that the systems were slow to evolve.
  • They realized that there were not many good alternatives.

Organizations needed something to happen to give them a path out of the status quo cycle in which they found themselves. In the early 2000s cloud technologies emerged in commercial applications. Users began to leverage the cloud to do many day to day functions that used to require companies to maintain hardware and software (e.g. e-mail). As the decade wore on, new applications began to emerge that solved a specific solution using cloud or software as a service technologies. These tended to be point solutions such as talent management and recruiting. Large enterprises also adopted for their Customer Relationship Management needs. Interestingly, many people during this time surmised that financials would never make it to the cloud because of the sensitivity of the data; however, organizations willingly put their customers, prospects, contacts, and opportunities in the cloud with SalesForce. What could be more sensitive than that? It was an interesting dichotomy.

Large enterprises were able to test cloud viability in many different parts of the company. Now all they needed was a cloud application that was a viable alternative to their decades old ERP system to push their existing platform into the decline phase. The good news is that one was being adopted as part of its introductory phase in the product life cycle.

Phase 5: A New Hope and Viable Options (2012 - Present)

During this phase, large enterprises began adopting cloud based technologies for their financial applications. The early adopters worked closely with vendors to test the product and create a viable solution that could compete functionality wise with the on-premise product. Cloud technologies have several major advantages over on-premise based technologies. The article 9 Things CFOs Love About the Cloud (or Should) describes in detail the advantages of the cloud. Some of the advantages include:

  • No more costly upgrade projects
  • No costly infrastructure to build and maintain
  • Unified solutions that combine HR, finance and analytics all in one application to enable better reporting
  • Continuous opportunity to improve your process with multiple release cycles per year (where the vendor does the upgrade heavy lifting)
  • Limited ability (temptation) to customize your system
  • All users on one version of the software (and technology stack) making it easier for everyone to support and optimize
  • Less training required since the applications are built like applications people use in daily life

In 2015, large enterprises now have a choice. Instead of upgrading to the next version of the on-premise software, they can look to cloud based solutions. If a large enterprise is wondering what they should do, they should look to their existing vendors to see how they are reacting to this disruptive technology.

Traditional on-premise ERP vendors are generally doing two (contradictory) things in Phase 5:

  • They are propping up their existing on-premise solutions to prevent the slide down the hill. They are adding “cloud-like” features to their decades old software to make it stay relevant. Unfortunately, what they are doing is putting a band-aid on top of existing band-aids. Large enterprises could upgrade and stay on on-premise; however, they will be behind the curve as the industry is moving to the cloud. They will be at a distinct disadvantage. And their vendor knows this because . . .
  • They are building their own cloud based solutions to “catch up” to the revolutionary companies that recognized this market shift in Phase 4 and already began developing their solutions. The forward thinking companies started building enterprise cloud solutions for finance years ago. Their solutions are already rising the product life cycle maturity hill and hitting their growth phase.


Just like in Y2K, large enterprises have a choice. They can upgrade and “patch and fix” their legacy ERP system or they can look to evolve to solutions that will carry them for the next two decades. Our article titled, Thinking about Upgrading PeopleSoft? Read this First!, is a cookbook on how to calculate the real cost of upgrading and staying on your existing technology versus implementing a new finance system that is built for today’s challenges (not Y2Ks!).

Implementing Finance & Accounting Systems
Performance Improvement on a System Implementation
Related Posts
Equal Pay for Equal Work Compliance in Workday
Equal Pay for Equal Work Compliance in Workday
Deploying Workday: Too Many Applications Result in Too Much Risk and Inefficiency
Deploying Workday: Too Many Applications Result in Too Much Risk and Inefficiency
Easy Integrations: Prebuilt Connectors Speed Deployment Times
Easy Integrations: Prebuilt Connectors Speed Deployment Times