Trying to achieve 0 technical debt in your S/4HANA transformation is a bad idea. Let’s face it - organisations running on SAP have been accumulating their custom code for years and years. Some of it is ok, other might be terrible. But often times we hear that moving to S/4HANA is THE TIME to get rid of ALL OF THE TECHNICAL DEBT and start fresh. I disagree with it and here is why: - Companies that want to make the transformation PERFECT will delay it until they are really ready, but will they ever be? - Reducing the TD down to 0 might end up never really paying off - Trying to make everything perfect might multiply your TCT - Total Cost of Transformation (I’ve just made this acronym up!) - Some TD will NEVER affect your upgrades, system stability, security or even TCO I was initially onboard of this train too but now I no longer am. It’s time to start being realistic. So what to do instead? Categorise and prioritise TD and focus on the one that really does make things worse and not the one that only fancy theories and shiny slides tell you to clean up. The clock is ticking. The longer you wait the less time you’ll have for the move. It’ll never be the perfect time to start and aiming for perfection might end up disastrous. What is your #1 tip for refactoring custom developments to S/4HANA? #SAP #SAPCommunity #S4HANA #BTP
1. Document Each Development - Maintain detailed documentation for each custom object, including its purpose and usage. 2. Preserve Team Knowledge - Ensure that team members understand the reasons for using each custom object. 3. Review Existing Custom Objects - List all custom Function Modules, BAPIs, User Exits, Custom Transactions, Reports and identify which were used in the last 12 months. 4. Evaluate Usage and Importance - Create a table to track the frequency of use and business importance of each custom object. 5. Build a migration plan. - Confront project costs with benefits.
I'm sorry, but it is a good idea. It all depends on your starting point. Many organisations are starting again with S/4HANA - i.e. a real business transformation underpinned by S/4HANA - in which case it is a great opportunity to remove technical debt - ideally getting to the point of a clean core, plus other things like smoothly running interfaces etc. It is also the time when there is the budget - as very rarely can you get the budget to clean up technical debt - but often you can do it as part of a transformation. If your starting point is doing Brownfield or Bluefield then it is much harder and your article is correct. However, Brownfield isn't a transformation and often Bluefield isn't either - so there is less of a chance to transform your technical debt.
This works only when you can transfer the technical debt from one upgrade to another. I think the problem with your PoV here is that SAP’s platform used to be more flexible with TD and has now become much more rigid. There’s a ton of of classic ABAP thats simply incompatible with Steampunk. It could meet the business requirement perfectly - but become a longer term blocker for upgrades later. On BTP - some tech debt and breaking changes always needs to be resolved basically as soon as it emerges for security and compatibility reasons. Be pragmatic to hit project milestones - sure. But always try to reduce the technical debt.
Mateusz Skrzyniarz, your perspective on managing technical debt in S/4HANA transformation is both insightful and refreshing. Categorizing and prioritizing technical debt is a practical approach that resonates with the challenges many organizations face. Your experience in this area is valuable and I appreciate your candid insights.
TBH for S4 scrap what you have and just reimplement from scratch at least you know what is coming your way to triple the budget and double the time it will take :). A green fields approach.
I don't think its possible to have 0 technical debt. A good goal is to eliminate 70% of technical debt. This can lead to a good outcome while not overcomitting. The main contenders for technical debt elimination are usually obvious and worth pursuing.
SAP Tech Lead @ Aurobay
10 个月In many cases the requirement can actually be built without modifying SAP. #cleanercore