Ownership Battle - Functional - Technical teams

[former_member706122]

The premise of this discussion started for me decades ago when I was implementing the first ever ERP SAP box for one of our customers. To my surprise this is a battle that never ended and continues today.

The SAP world is divided into different compartmentalized skills. Most of you know the basic divisions -

Functional Consultant - A process expert who can review real business process, identify the need, and capture / configure the required process in a virtual instance of SAP.

Technical Consultant - A technology expert such as Basis (Admins), App Dev Team (Primarily consists of developers), Security (Compliance and User Provisioning).

 

In my personal experience battle is fought between the two teams over ownership of designing the system. Most of the time the SAP functional consultant will be declared as a winner, as the business processes are much more critical than technical problems such as performance problems or system technical debt, code security etc.

 

Take Away:

Hopefully at the end of this short article you will be able to have a better understanding of the team dynamics today and what has changed in the last two decades. This article should also help you to set up a new implementation team and define goals for them.

 

Get Set Go:

SAP ERP is a business facing suite of products which has several dynamic applications and components. This is an extremely complex environment to navigate both Functionally and technically. Now that was the story so far - Three recent shift around the SAP world that challenges the age-old design principles are

 

• Introduction of new tools / IDE related to Low Code environments.

• This is a welcome move for many. As you would read through the below problems non-technical teams faced in the past. The low code approach certainly helps reduce the gap.

 

• 
  
  
  
  • In the past one of the major problems for functional teams were not everyone can learn 4-5 different programming language and keep up along with different changes in the technical world of programming. - Low code environment reduces this problem significantly. Also decimates the effort needed to learn programming skills.
  
  
  
  


• 
  
  
  
  • Programming is a painfully slow process (when you start a fresh ) sometime especially when you don’t have access to reusable libraries or graphical IDE's. - Low code environments are certainly faster with new IDE's with GUI enabled drag and drop design features.
  
  
  
  


• 
  
  
  
  • Balance time between understanding business processes, attending workshops, configuring creation of test cases, writing functional specifications etc. - With faster technical development with low code environment and automated test scripts this might not be a big problem anymore.
  
  
  
  

 

• Enablement of SAP best practices via tools like Solution Manager/ Signavio and other process mining tools.

• This move will enable any customer business teams and can arguably reduce dependency on solution architect i.e. functional teams.

 

• 
  
  
  
  • The major problem for business teams were not able to identify configuration items in SAP. - SAP Best practices load basic out of box configuration and can be tweaked from business process documentation directly.
  
  
  
  


• 
  
  
  
  • With time - business team members understand SAP systems and configuration better and can be less reliant on functional teams.
  
  
  
  

 

 

• Clean Core and BTP approach.

 

• 
  
  
  
  • Reduction / decoupling customer code from on-premises systems onto BTP. - BTP ABAP Environment is a very powerful tool to reduce custom code from on-premises system and also use reusable bespoke customer library.
  
  
  
  

 

• 
  
  
  
  • New tools for developers with extension (Fiori, CDS, Screen persona) capability. - Reducing development time taken to build application from scratch.
  
  
  
  

 

• 
  
  
  
  • Pre-packaged content in integration suite (CPI) will certainly reduce development time by a lot.- Reducing time and Complexity for integrating with different systems.
  
  
  
  

 

• 
  
  
  
  • Introduction of UX, GITHUB integration etc. - Ease of use for front end and backend developers 
  
  
  
  

 

But wait what about the design?

Till this point what we discussed doesn't settle the ownership battle. But our discussion was more about technology shifts and technology enablers. This shift simply allows any SAP team to get better at what they do.

With that in mind an argument can be made that we don’t have different IT teams such as functional, technical (Basis, Security, Developer), and that would be correct to some extent.

The traditional approach of compartmentalize the teams in their silos never worked out and repeatedly the teams were instructed to work together to solve the problem/ reduce the conflict.

This model has one very visible flaw i.e. lack of guidance on how the two separate teams can bridge the gap.

As a result, this creates a rift between different competencies.

 

Definition of Software development teams (specially teams that practise agile ways of working are known as product teams.)

A product team always work as a unit, there are people with different skills but with same responsibility (To deliver a final product as per the vision of the product owner / customer).

 

The difference is visible between the above two approach

• A classic SAP based organization working in SILO's.


• A small product development team focused team working together.

 

Findings:

Let’s first review our findings so far-

• The world around SAP has changed. Making it easier for anyone with or without special skills to understand the system setup.

 

• The overall implementation and operations process is simplified by SAP for its customers.

 

• The ownership battle is not a problem in a product team because each person has a different skill and need to contribute in their own way to solve a bigger problem.

 

• Another visible difference between product teams and SAP teams are product team gather business requirement as a unit but not done via an individual (Reducing the need to repeat telecasts/ Reducing risk of misunderstanding).

 

Conclusion:

Finally, the battle between functional and technical teams over a last two decades shouldn't exist in the first place as they both are equally responsible to deliver solution to a problem to the end business customer. With technology advances in last few years (In terms of SAP) the ways of working needs to change and more microservice / product-based IT/Business teams are needed today.

 

The developers in SAP world is empowered more and more to do better under the systems and processes more from business point of view, at the same time the functional teams are enabled with new self-service technologies.

 

So a new battle has begun which is no longer between different IT competency but rather how to make the business implementation faster, easier, simpler.

 

Disclaimer - I have worked as an SAP Developer for many years, and as a Functional Consultant for few others.