Skip to Content
Author's profile photo Waldemar Falinski

Change management, transition, transformation and level of disruption in SAP projects

Following my previous entry:, I have tried to structure more what change management, transition, transformation and disruption in SAP projects mean and what is the real value, cost and risk behind them. To help myself understand it better and more adequate handle them in my work and maybe you could find it useful in yours:

I have found very good definition of “transformation” here:

Let me cite: “Transformation is another animal altogether. Unlike change management, it doesn’t focus on a few discrete, well-defined shifts, but rather on a portfolio of initiatives, which are interdependent or intersecting. More importantly, the overall goal of transformation is not just to execute a defined change — but to reinvent the organization and discover a new or revised business model based on a vision for the future. It’s much more unpredictable, iterative, and experimental. It entails much higher risk. “

I slightly disagree with above as change management is covering reinvention and also iterative self-corrective changes, but OK for this purpose it is very good as reflects in short simple words the nature of transformation we can use in SAP projects.

But what is “transition” then? In context of SAP project, I would formulate following definition:

Transition means a shift (migration) of SAP solution to new technology stack or platform. Transition is thus a quite complex technical change or set of technical changes and may bring also functional changes consequently leading to some organizational changes. Example of this last case may be a roll-in of local distributed SAP installations into one central SAP instance. In this case we can even talk about transformation if leading to massive standardization requiring / triggering redesign of entire business model.

Transition is always a precondition for business transformation but there are two variants:

  1. Transition that opens the possibility to transform after transition is done – it is more soft and agile.
  2. Transition that triggers the transformation in the same time – riskier and needs business redesign at once.

Definitely implementation of new real-time solution with green or even brown field scenario is the second of the variants. We know it very well after many years of R/3, then ECC implementations.

Look forward to hearing from you about it!



Will talk about on:

PS. I cannot find any option to attach the file here so if U see it may help you just give me shout and your email

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.