Enter search term:

“A Study In SAP” – What Is Greenfield Implementation?

When it comes to moving your core data into an SAP environment, it’s not possible to work manually in this regard at all. You must have a plan, and know how to execute it.

Fortunately, there’s already more than one option available out there to complete an S/4HANA migration. And greenfield implementation is the most prominent aspect amongst them. Keep reading this article till the end to learn more about it.


What is the Greenfield Implementation Approach?

The greenfield approach, in essence, is all about beginning your journey from a clean slate. It, in turn, can enable you to perform process simplification, reduce data footprint, or enable the newest SAP innovations.

With the same, your organization can also predefine migration objectives and put down proper data governance practices. This can decrease the TCO and time-to-value of your company and facilitate much quicker adoption of innovation, if done correctly.

Unfortunately, the greenfield implementation isn’t all flowers and butterflies. It has a few issues that might affect the working procedure of a larger enterprise.

For example, as a legacy organization, you probably have been using SAP for a long time. In the same sense, you probably have a lot of valuable data available there.

When opting for a greenfield approach, you are essentially scrapping your ERP investment and starting anew. So, the loss of historical and transactional data will need to be considered.

Let’s be honest, SAP Best Practices is a great model to follow, but you’ll still need to consider new configuration and developments as well. This doesn’t begin to cover the organizational change management or business disruption that comes with these many changes.


So… What Are the Benefits?

In essence, the greenfield implementation is ideal for someone who wants to begin a new SAP journey. This is usually the case for small and medium-sized enterprises. Thus, in this section, we’ll look at the core benefits that this approach can bring to you.

Don’t worry. We have a “cons of greenfield implementation” section ready for you as well. It can be found toward the end of the article.


Getting Some Space for Brand New Innovation.

Although a little tricky, integrating S/4HANA can do a lot of good for your organization. And amongst them, the most prominent one is getting introduced to various innovations.

For example, with it, you can implement the following in your organizational infrastructure –

  •       In-memory HANA Database (can be used to store the required data and information).
  •       Advance ATP (can help with product planning and fulfilling orders).
  •       Fiori (can improve the user interface and experience of your database altogether).

Now, all of these things can be implemented on an already-existing SAP infrastructure. But, in that case, the process of doing so will be much lengthier than usual.

Contrarily, if you follow the greenfield approach, you can start everything from a new slate, including implementing these few new capabilities alongside.


Scope Of Optimization or Re-designing.

In greenfield implementation, you essentially are getting a playground where everything from processes to functionality and hardware can be reimagined. Therefore, it becomes a bit easier for you to optimize your organizational structure and re-design processes.

This also allows organizations to revert back to SAP standard wherever possible, reducing the number of custom developments, making it easier to upgrade your system in the future.


Implement Industry Best Practices.

As you’re starting your journey from the beginning, it’ll be easier for you to implement industry best practices. And that’s not all.

Thanks to SAP S/4HANA’s flexible system, you can still make developments like in ECC. This way, your organization can continue to innovate within SAP, molding the software to fit the company’s needs.


The Drawbacks of Greenfield Implementation

We’ve covered how and why a greenfield implementation can be quite beneficial for your organization. However, there are some major implications that should be accounted for.

Here’s what you need to know about it.


Change Management.

Changing how you used to work before can be quite difficult for people across the organization. Roles will change, business and IT will need to be heavily involved in the project. This will have an impact on the day-to-day operations. There will be pushback, so communication becomes key here.

Understanding this from the top down, will ensure the project team will receive all the support needed to ensure success. There may be some bumps on the road, and it will take a long time. Make sure you don’t let change management be what holds back your success.


Prolonged Timelines.

Usually, in a greenfield implementation, your project timeline will be longer and of higher effort than either a brownfield or selective data transition. It is good to take a 30,000-foot view of your IT roadmap and ensure there are no other projects running simultaneously as it could become a big headache.

Also, the greenfield implementation tends to be much costlier than the others. Think about it. You’re starting with a fresh new system that needs to be configured from the ground up. You have to look at processes, 3rd party applications, EDI, customer interfaces, etc. It is a huge undertaking.


How Does It Differ from The Brownfield Implementation?

Like greenfield, a brownfield system conversion is the other original approach to moving into SAP S/4HANA. However, it works a little differently.


Well, unlike a greenfield re-implementation, the brownfield approach is an upgrade of your existing SAP ECC system. Meaning all your data, configuration, and developments are converted into the new SAP S/4HANA tables.

So, for a legacy enterprise, it becomes much easier to keep hold of their existing data while moving. However, there are some restrictions and things to consider.


Difference – 1: The Core Implementation Approach.

The greenfield implementation approach is synonymous with innovation and transformation. And, why wouldn’t it be?

After all, it’s helping you fix some of the mistakes from the past and start with a fresh new system. You can replace 3rd party software with SAP standard functionality.

On the other hand, the brownfield approach is all about deferring innovation into the future. Besides, you’ll also need to be sure that it is all working properly altogether.

This approach can essentially extend the older capabilities of a business and will mildly depend on the refactoring, workarounds, & middleware.

Example: An excellent example of a brownfield approach can be schema extensions. You can easily extend them by integrating anything, like a lookup or a master-detail relationship. It is ideal for collaborating with customers.


Difference – 2: Change to Project Development.

In a greenfield approach, there is typically a longer timeline, giving a sense that things are moving at a slightly slower pace.

You have to look at every aspect of the system, and this requires time. Development work should ideally stay low if you’re planning on sticking with SAP Best Practices.

On the other hand, brownfield is more technically complex, but overall, the timeline should be much shorter. Since we’re converting the source system with minimal functional changes, the overall project timeline time will get significantly reduced.

However, this situation can change drastically if you’re thinking about harmonizing or cleaning up the system prior to conversion. Besides, you might also need a little more time in case you want to integrate new technologies.


Difference – 3: Limitation Regarding Customization.

A greenfield implementation approach offers quite a lot of scopes for customizing as well as configuring to achieve the result you desire.

Since you’re starting from the beginning, there’s no need to worry about the limitation of the former architecture. You can tailor it however you want.

However, with a brownfield approach, you can’t really work as flexibly as you want. You have to consider current architecture, database size, system downtime, etc.

Making organizational structure changes can be difficult to execute, cleaning up data requires a lot of effort, and you have no option but big-bang go-live. This last one, particularly for large organizations, can be a huge risk factor.


Difference – 4: The Overall Expense of Development.

A greenfield implementation tends to be the most expensive approach. You’re setting up a new system, so there is a lot of conceptual work and analyses that need to be conducted in order to understand your current and future landscapes. You have to do fit-gap workshops to see how and where to adjust your processes. This can take years to execute, over multiple waves, and with a hefty price tag.

Contrarily, with a brownfield system conversion you are reusing most of your configuration and developments in SAP S/4HANA. Just making sure to account for some of the restrictions listed above, this tends to be a cheaper and quicker option, albeit without much innovation. The mindset here being, “let’s get to S/4HANA now, and we can worry about innovation in later phases once we’re comfortable with the new system.” This significantly reduces risk of disruption by introducing small changes incrementally.


Difference – 5: The Aspect of Code Reusability.

This is a big decision point. Have you maintained a clean, stable SAP system, with just the necessary developments? Are you happy with the data quality? If so, the answer is clear. Brownfield is the way to go.

On the other hand, say you have multiple ERP systems (including non-SAP), all with different processes, landscapes and system configuration. Trying to salvage something from this Frankenstein monster may be a bit too much. So greenfield will be your best option.

Ultimately, with brownfield you reuse and with greenfield you renew.


Difference – 6: The Risk Related to Your Project.

There is always risk in IT projects. That is a fact. It comes down to how you identify and manage those risks that make the difference.

When you look at it from a greenfield perspective, two main points come to mind: organizational change management and data. The introduction of new processes, new user interfaces and new systems can be a big change for an organization, not managing this properly is a huge risk. They also keep saying data is the new oil. Well, with greenfield, you’re leaving all that data behind, so you need to look at other options for leveraging your historical data.

Brownfield is not out of the woods here either. Depending on the database size, the technical downtime through the standard SUM-DMO conversion approach can be extensive. This is unacceptable for most large organizations operating 24/7. The other big risk comes with the big-bang go-live. There is no way to avoid this as it is a technical requirement of SAP standard migration routines.


Difference – 7: The Overall Scalability of The Platform.

The scalability of a greenfield solution is much wider simply because it allows more flexibility. The possibility of scaling and building the system of the future is there. Therefore, if your business is fast growing, somehow, it’ll be easier for you to –

  •       Increase the speed of the usual business proceedings.
  •       Meet the extensive and excessive demands of your consumer base.

With brownfield, the scenario would be a little different. For example, it’ll be harder for you to improve overall scalability. Why?

Because you’re essentially working on the same platform you used to operate on before. You have less flexibility to make structural changes to your system. As business models change in the next 10-15 years, a simple technical upgrade now may mean a more complex implementation in the future. It’s always a guessing game.


When Should You Go for The Greenfield Implementation?

In essence, both greenfield and brownfield implementations can come with measurable results for your business. Nonetheless, they do have some specific limitations as well. If you’re thinking about opting for the greenfield technique, you should only do it when –

  •       You want to rebuild the data infrastructure of your business.
  •       You feel like changing the existing platform’s core essence.
  •       You wish to bring new innovations to the table.

The biggest risk, as mentioned earlier, is change management. Know it, expect it, and plan for it. Know that if you can brave through it, we’re pretty sure you’ll succeed in the venture you’re working on.