Don’t Tell Me What We CAN’T Do In SAP!
I think now is a good time to bring up my biggest workplace pet peeve. It is when people tell me about what we can’t do in SAP. When I say SAP, I’m talking about the SAP ERP product and the capabilities of the NetWeaver platform. Even though my examples are focused on this platform, I have noticed similar attitudes about other technologies as well. People telling me what we can’t do have been around me my entire career and I have noticed that some people find it easier to blame the technology instead of admitting their own shortfalls.
The first project I was involved in with my first job out of college was a large implementation project, where I had a non-developer role mainly focused on testing and working with business users. We had a custom interface built to connect to another system and it was having major issues. I was not familiar with ABAP, but I noticed that issue could be resolved with a semaphore (used in C++), so I made the suggestion only to be told that “there is no semaphore in ABAP”. Which is technically true, except what I was suggesting is part of the SAP locking system and is just not called a semaphore. The same person told me that there “is no boolean in ABAP”, which made me wonder how anything worked at all. That was my first experience of “experts” telling me what we can’t do in SAP. I think that was the most extreme case and now that I am an ABAP developer, it is a lot easier for me to separate the bull from reality because I can prove that we can do it.
I think that a lot of my experience with this issue comes as a result of people getting used to doing things a certain way and thinking that way is the only way. Soon, the shortcomings of doing things that particular way become shortcomings of the technology. As someone who works in IT, it seems like the only thing that is truly constant is change. However, people will continue to fight change. Even taking advantage of the modern ABAP programming can be controversial to some.
Have you ever had similar experiences where someone has said that something can’t be done in SAP or even some other technology, when you knew it could? How have you handled these situations?
I can't begin to tell you how many times I've heard 'You can't do that' usually coupled with 'Because we've always done it this way'.
This could be a really deep philosophical discussion, or we could go off on 'users' or business analysts, or programmers. But instead of that, we (whoever 'we' are) should just listen.
If the person you said 'semaphore' to had listened, maybe said 'I'm sorry, what's a semaphore' and listened again, then you both would have arrived at a common understanding.
I'm interested to see what other types of responses you get 🙂 . Should be fun.
Good discussion topic - I hear a lot that SAP can't do this or that. The times when I've had to say we can't do "X" are purely due to time, budget or resource constraints. If you remove these constraints then I firmly believe you can do anything. Sometimes it just takes some lateral thinking, sometimes it takes a lot of customization. But in the end it is generally achievable.
Recently I was tasked with building an application in SAP that I thought may have been impossible. After trying and failing with a number of different solutions involving NWBC tagging, chip pages, workflow events and shared memory classes, the final solution was a simple FPM with some long-polling capability. I admit by the end I was panicking a bit that it wasn't doable but in the end we have a nice solution.
Good call - On numerous occasions I have had to prove it, with the good part being that at least I get hands on for a bit! This is generally why I suggest that customers need to govern system integrators/outsourcers; as integrators/outsourcers can usually be too commercially driven, and don't necessarily invest in their people; hence fall back to age old approaches they are used to (not just talking SAP here).
The hardest space even today in SAP I think is around UI and Object based custom development. Why we still have procedural developers out there is beyond me...
Probably worth highlighting that in some cases, it has been great, as they've taken the proof of the new approach, run with it and ended up teaching me more than a thing or two! So it's not all bad if you're given the chance to prove it.
It got to the stage in my last posting when one of the business analysts would ask one of the "normal" programmers if something could be done, they would tell him it was impossible, and then he would come to me behind their backs saying my colleagues said it could not be done.
Naturally I made a point of getting whatever it was to work the same day. I suppose you would call this 'divide and conquer".
I think you can probably imagine how unpopular that made me with the "that cannot be done" brigade. in the end I was banned from any contact with the end users at all, in case I made their "impossible" requests come true.
Anyway, all's well that ends well, in my IT department in Australia the users have been getting exactly what they ask for over the last 13 years 9no matter how stupid, but that's another story) no matter how 'impossible" it was.
Thank you for the comments everyone!
It sounds like a lot of the issues are around training and project management. IT teams (on site and system integrators ) need good training programs so that they know what can be done and what the options are on how to do it. This seems like management 101, but I'm pretty sure some managers don't get it.
Project Management is also important so that we focus on what needs to be done and not over customize or spend too much resources on something that is a "nice to have".
we face the same issue day in and day out working in a media company , developing softwares for VJ and RJ for program scheduling , Where UI should be flashy and we have to convince the clients again and again that it can be done in ABAP rather that .Net.
Thanks for bringing the topic up.
I also hear the same comments time to time, where people say its not possible. But it not like its not possible, rather they chose not to invent efforts in that direction.
I recently faced similar issue where I need to replace small SAP GUI buttons with bigger buttons so they are "touch-screen" friendly. Operators can easily choose the desired button instead of choosing the incorrect one. The solution would be Bigger Buttons using HTML Control.
This reminds - Where there is a will, there is a way!