Concept Soft

ERP’s Big Bang Theory

One of the difficult decisions of an ERP implementation is the implementation strategy: do you take the big bang approach and get it done with quickly, or do you slowly phase in new processes and technology over time?

The answer is that it depends. The appeal of the big bang implementation strategy is that it focuses the organization for an intense and relatively shorter period of time than if the project were phased. This often helps address long-term resource shortages. It also condenses the pain and difficulty of an ERP project into a shorter period of time, although the pain is typically more pronounced using this approach.

The downside of the big bang implementation approach is that the project is often rushed, details are overlooked, and changes to business processes may not be the best ones for the organization. And, as mentioned above, the pain is often more severe due to the hectic nature of this approach. More often than not, my experience has been that projects that implement an overly aggressive big bang approach are more risky and result in less satisfaction with the system’s abilities to meet important business requirements.

The other end of the spectrum is to follow a slower, phased approach. This can either by functional business area or geography. The appeal here is that is allows project teams to take their time in the planning, customization, and testing of the system while continuing with day-to-day jobs.

The downsides are that these types of phased projects often lack the urgency and focus of a big bang project. It can also lead to “change fatigue,” which can cause employees to become burned out on constant change. Instead of getting the project over with in a shorter period of time, these projects involve constant change over longer periods, which can be draining to employees.

So which approach is the best? Both approaches have their clear pros and cons. At the end of the day, it is important to find a balance between both that works best for your organization. Implementation schedules need to be aggressive, but not to the extent that they cause you to overlook important details or make sub-par decisions. It is often helpful to do the project in multiple (but aggressive) phases to help focus the organization and create a sense of urgency.

ERP Software Clash of the Titans: SAP vs. Oracle

As our ERP research has shown, both SAP and Oracle eBusiness Suite (EBS) have strengths, weaknesses, and tradeoffs. Different clients have different needs, ranging from functional requirements, technical maturity, tolerance for risk, budget, and a host of other factors. The vast differences between these two ERP solutions are underscored by the fact that we often recommend different solutions for different clients in the exact same industry.

So what are the differences between these two solutions? Although there are numerous variances in the detailed workflows and functionality of the solutions, there are five key high-level variables to consider when evaluating SAP and Oracle EBS:

1.Best of breed functionality vs. more tightly integrated modules. The software strategy of the two vendors could not be much different. While SAP has built a solution primarily from the ground up, Oracle has grown primarily through acquisition of best-of-breed point solutions. For example, Oracle has acquired Demantra for advanced sales and operations planning, Hyperion for financial reporting, and Siebel for CRM, while SAP has built much of this functionality into its core ECC and All In One ERP solutions.

2.Product roadmap. SAP continues to build upon and enhance its core product offering, while Oracle is moving toward Fusion. While some may suggest that Oracle is more innovative or visionary in its technology direction, it also means that there may be more uncertainty with Oracle’s product lines. This is especially true for clients considering Oracle’s JD Edwards and Peoplesoft solutions.

3.Flexibility. Although very powerful, SAP can be more difficult to change as a business evolves. This is both a strength and a weakness: it is tightly integrated and helps enforce standardized business processes across an enterprise, but it can be more difficult to modify the software to adjust to evolutions to core processes and requirements. Oracle’s best of breed approach, on the other hand, can allow for more flexibility to accommodate changing business needs, but this strength can become a weakness when it becomes harder to enforce standardized processes across a larger organization.

4.Implementation cost, duration, and risk. Although both solutions typically cost more and take longer to implement than most Tier II ERP software, there are distinct differences between the two. Oracle has a slight advantage in average implementation duration and an even larger advantage in average implementation cost, at 20% less than SAP. SAP, on the other hand, has the lowest business risk of the two, measured via the probability of a material operational disruption at the time of go-live.

5.Business benefits and satisfaction. This is perhaps SAP’s greatest strength. Although Oracle has the highest executive satisfaction level of all ERP vendors included in our 2008 ERP Study of 1,300 implementations across the globe, SAP leads the pack in actual business benefits realized. Assuming the #1 reason most companies implement ERP software is to achieve tangible business benefits, this can be enough to justify SAP as a solid solution for many companies.

While the above points highlight some of the key differences, there are a number of similarities between the two. Both are aggressively pursuing Software as a Service (SaaS) and/or on-demand ERP offerings. Both are also more likely to take longer and cost more to implement than other ERP solutions in the marketplace, such as Microsoft Dynamics ERP, Epicor, and Infor, even when normalized to account for larger clients. And both are scalable, able to handle international requirements, and proven among larger organizations.


The key takeaway here is that, as with any ERP solution, SAP and Oracle both have their strengths and weaknesses. One solution may be the best fit for one organization, while not a good fit for others, even within the same industry. The only way to make sense of the pros and cons in a way that is meaningful to your organization is to engage in a robust ERP software selection process that considers your requirements, priorities, and competitive advantages to find the right fit.

Don’t Let a $2M ERP Implementation Tell You How to Run Your $100M Company.

I had an interesting discussion with a prospective client the other day about the pros and cons of customization during an ERP implementation. As we outlined in a recent blog, most companies customize their enterprise software to a certain degree, which can elevate implementation cost, duration, and business risk.

However, this person had an interesting counter-point. Despite the potential risks and downsides of customization, there are upsides as well. Companies with true competitive advantages in their industry are likely to have one or more key business functions that are not addressed by leading ERP software vendors. The added costs may be immaterial compared to the potential upside, especially for a larger high-volume company. Therefore, customization can become somewhat of a necessary evil.

However, there are a few caveats to this perspective. First, as with any indulgence, customization can be acceptable only in moderation. ERP implementation failures often over-customize to accommodate an endless array of user requests, so it is important to have strong project governance and controls in place to ensure you are only customizing functionality that is absolutely necessary.

Second, don’t let customization be an excuse to choose the wrong software. An effective ERP selection process should w**d out the software solutions that are not a good fit for your operational needs, which will minimize your need to customize the software.

Finally, customization should not be a surrogate for leveraging the best-practices embedded in your ERP solution. If the functionality in question is not a core competency or competitive differentiator (think G/L or procurement), then carefully consider the processes that are built into the software. It may be difficult to change your business to fit the software, but it may be the lesser of two evils in such instances.