User Experience Insights
Ownership Battle – Functional – Technical teams
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.
Long response coming up. I hope this becomes a lot of people commenting. It is an interesting topic.
I've worked internally for ever. I've also done consulting work in between jobs. I've held both a functional role and a technical role - for ever. So this job I combined the two to functechnical or something like that. It is nice since it let's me do both and confuses the heck out of consultants brought in.
So you've missed a few crazy roles. Security, Basis, Business... The list can go on and on.
Security - Needs the technical side to help determine what is needed, the functional side to tell them what each role should be. Security to set the roles up and develop some sort of schema and hierarchy
Basis - These fun guys have to deal with our end result. Bring down the system, pesky thing like that. They are the gatekeepers.
Project Manager - take all the pieces, parts, and set up meetings, develop a time line, have the really fun job of communicating with upper management.
Well you get it. It can get messy. I believe the technical and functional side should be working on both side. They should work together to create the perfect (close to perfect, doable project). HA! That is my opinion and not shared well at all. Why? Because it makes resource allocation a lot harder. And overlaps harder.
Also when something goes "wrong" who should be the one who causes the issue? Let's start another debate. The program fails to deliver what is expected by the business users. It's technical right? Well the specs didn't call it out. It's functional, right? That piece was cut out because it would take too long. It's the PM right? HA! The lines are gray. It does roll down and it's always the technical teams fault. Don't ask me why, because I don't know.
We live in a crazy world. Even when you talk about defining the role. Sometime my fun functional people determine they know the best way to program something and it is in their functional specs. You know the one get this field from this table. The real world no longer works that way. For SAP fields I rarely pull them from a table. My functional person tends to get mad that I've changed their design. Ahhhhh Here's my hair going gray again. Or I suggest that configuration would be a better alternative then I watch them get really defensive. Or a functional person would dare to suggest a different way of developing a project. Now watch the technical person get defensive.
Let's not get me started on a internal person vs. a consultant. The consultant almost always "wins". Those are the days I want to throw in my hat, and just give up and be a consultant again. <Sigh> I do have huge benefits working inside of my firm and I remind myself about them.
It would be so much better to just lose the titles. However, that's not feasible either. We each have our job to play. But everyone needs to respect and be open to things that are outside of their neat little definition. The lines are grey with little open spots in them. In other words - Play well with others.
BTW - as far as low code/no code, there are limitations to everything. And it won't be widely used for awhile.
Dear Michelle first of all a big thank you, long response in-deed... 🙂
I didn't touch base those teams topics intentionally. As that's another separate discussion on its own related to cloud mode, compliance changes around the world security audits etc.
BTW - as far as low code/no code, there are limitations to everything. And it won't be widely used for awhile. - Agreed this will take time. But definitely a good start.
One intention of article was to hear from colleagues like yourself and others as well. Just one thing we all have to remember the difference between developer/functional/basis/security is going to get smaller and smaller that's the new world we live in.