Locking/Stopping Z-Developments in SAP System

[Former Member]

Hi All,

I have a requirement where I have to stop all Z-developments in my DEV system. Any development new/modifications first needs to be authorized/opened by a particular user id then only development team should be able to work upon same.

Please guide me if anyone has worked on this type of requirement.

Regards,

NJ

[ThomasZloch]

You could limit the authorisation to create transport requests and tasks to that user ID.

This would still allow creation of $TMP objects, which might not be an issue for you.

Thomas

[former_member538259]

You can use the ATC (ABAP Test Cockpit). Where you can manage projects with a team

Check this ABAP Test Cockpit - ABAP Development - SCN Wiki

Regards,

Alberto Montes.

[Jelena]

But why do you have to do that? If someone doesn't trust the "development team" to do their job right then why were those people hired in the first place?

[JL23]

The people are there, and the company cannot just get rid of them

We are actually in the same situation.

It is a mix of cost reduction and compliance requirements.

Nobody shall be able to develop programs just on a call. It has to be checked if the requirement makes sense from a global point of view and is not just the golden egg for one person  while other BUs eventually are negative affected or may have to pay for something what they do not need.

And of course the paranoid compliance officers suspect a potential virus developer behind each IT person (who spent their life time and passion to implement SAP around the world and lead the company through the Y2K and other crisis)

SAPs Solman has a so-called CHARM process, which means you create a change request in Solman, you defined several roles for approval, per workflow this change request is routed through the company and collects the approvals and documents (business blueprint, function design, technical blueprint...) then you can continue to create the transport request from Solman. It is no more possible to create it automatically in the development system. If I am not mistaken the even the $TMP is no more possible in our system.

[Jelena]

Hmm, we also have an issue with people trying to sneak in their "pet tickets" despite the true cost but for that we have a change review process outside of SAP. SAP virus - what's preventing me from adding it to a transport that someone else created for a change that was approved? You'd need to add some triple peer review on top of that for somewhat decent security. (I hope the compliance officers don't read this. )

posted a blog on CHARM just today, by the way, could be a good option. Thanks for mentioning this!

[matt]

One of the systems I work on is validated and so has tight controls. I can't create transports or tasks - it has to be done by one of the analysts. So I cannot make changes or create new objects without a transport already in place.

When I release my task, a user exit triggers that creates a new "review" task for one of the nominated reviewers. When they've completed their review (for which there a few tools, as well as the usual manual code review), they release their task and the transport.

The upside of this process is that when there are issues in production, no-one comes to me asking me questions related to why the program does what it does or what it is intended to do. Hey, I'm just a programmer - I follow the spec. (Written on the back of a restaurant napkin).

[Former Member]

CHARM is an interesting tool.   I think it can be set up any way you would like, but I am not a BASIS person.  I am a developer. 

So here's our setup:

• We can create $TMP objects on development
• CHARM controls the transport requests - we as a developer can not create the requests until the CHARM "ticket" (we call it that) is released for development.   And then only certain developers can create the transport requests.
• All developers can create transport tasks.   However, if they added a task to my request - I better know what it is.

We control what should be worked on by two different systems outside of CHARM.   A product called JIRA keeps track of our projects.   A different ticketing system keeps track of our production problems.   If I (or any other developer) end up adding to our transport request, we are not working on our tasks.   We will not hit our dates, and people are not happy with us.   So when I get my review from my manager, it's not going to be good.  Even prior to the review, my manager is not going to be happy with me, and will tell me to make my deadlines.   Now if I want to work 24 hours a day and add the extra requirements, my boss doesn't care.   However, my testers will not be happy, and it will get back to me.   So really we stop the extra development by ourselves.

"Just a programmer" - does that really work for anyone?    LOL  You go to love the specs you get.