Is SPRO dead?

[Former Member]

I was reading Nich Young's blogs about perfect config tables and reflecting a bit on own experiences, security related questions on SDN and what customers end up doing after the consultants leave the building, or are shown during the implementation and then stick to.

Certainly in the security area, SPRO is incomplete by a long way for an implementation and will lead anyone who wants to do just a little change somewhere into PFCG and SU01, or even SU02 and other obsolete transactions...

Yet we still regularly see folks building SPRO roles or SAP_ALL minus SPRO.

Personally in the security area I have my own tool kits and a 24 MB mdb which I use as a reference guide.

What is the story here and strategy for SPRO? What do other gurus do in other modules?

Cheers,

Julius

[Former Member]

I was reading Nich Young's blogs about perfect config tables and reflecting a bit on own experiences, security related questions on SDN and what customers end up doing after the consultants leave the building, or are shown during the implementation and then stick to.

Certainly in the security area, SPRO is incomplete by a long way for an implementation and will lead anyone who wants to do just a little change somewhere into PFCG and SU01, or even SU02 and other obsolete transactions...

Yet we still regularly see folks building SPRO roles or SAP_ALL minus SPRO.

Personally in the security area I have my own tool kits and a 24 MB mdb which I use as a reference guide.

What is the story here and strategy for SPRO? What do other gurus do in other modules?

Cheers,

Julius

[Former Member]

Hi,

Well, I think my Solution Manager evangelist colleagues would certainly say SPRO is dead.

If you use solman (Solution Manager) for your implementation, you would build a configuration structure that would draw the required activities from the IMG for your footprint of processes, as well as any other transactions or activities required to configure the solution.

Each node in the solman configuration structure also holds the documentation relevant to the activity, as well as the link to the task on the required backend system. For example, if Business Partner set up requires config in both an ERP and CRM system the required activities are linked (and documented) from the one node in solman.

The natural conclusion to this is that a configurer need never log on directly to any configuration client (or indeed know which system they are logging into), all config is access using RFC from solman. So, no more direct access to IMG.

Also, "after the consultants leave the building" you've got in solman a structure that reflects the processes of the system, is documented and integrated with the specific configuration activites. And it's one that can be extended as the solution grows.

That said, I've never known anyone actually take direct access to the config client away from the configuration team (I mean, you know the fuss they make if they don't get SAP_ALL). And even in a solman implementation I'm sure large amounts of config gets done direct in the config client.

Regards,

Nick

[Former Member]

Hi Nick,

I suspect this question was too serious for the Coffee Corner.

I will resist the temptation to cross-post to the DDIC, ABAP General, Basis and SolMan forums, not to mention Comments&Suggestions and Japanese BO forums for an outsider's view on the matter...

> The natural conclusion to this is that a configurer need never log on directly to any configuration client (or indeed know which system they are logging into).

Actually they do log on, but they don't realize it or need even to know it. Trust me, I know what I'm doing

I also found a way to cure the "I cannot work without SAP_ALL" symptom, but it would loose it's charm if I posted it here.

Another thing about SPRO which bothers me is all the experimental changes to tables of various delivery class types which recorded a transport request but have never been (or should never be) released. I doubt anyone would be able to reconstruct the sequence or the tables again, except from a backup. Or someone subsequently and innocently makes a change and transports the whole table through.

I once reported such a thing to SAP via a customer message where an "innocent" change could be made without warnings of the consequences. The response was that the user should be sufficiently trained before given access to the function and it's menus! Fair enough

Cheers,

Julius

[Former Member]

I guess there's nothing worse than people wanting to discuss serious work topics during the coffee break

Regards,

Nick

[GauthamV]

LOL.

[markus_doehr2]

> If you use solman (Solution Manager) for your implementation, you would build a configuration structure that would draw the required activities from the IMG for your footprint of processes, as well as any other transactions or activities required to configure the solution.

Gosh!

If I'd even only think about talking about to DARE to remove SPRO from our internal support stuff I'd be killed right away.

> The natural conclusion to this is that a configurer need never log on directly to any configuration client (or indeed know which system they are logging into), all config is access using RFC from solman. So, no more direct access to IMG.

Coming from a more than a decade (R/2 and) R/3 background I think it's a good idea to do this through SolMan but rather theoretical for grown installations. If you come from a 2.1x something release and you know exactly where to change things (and what) it's impossible to revert that to a business process view, especially if you have multi-national differences/translations/configurations in one single ERP system.

> Also, "after the consultants leave the building" you've got in solman a structure that reflects the processes of the system, is documented and integrated with the specific configuration activites. And it's one that can be extended as the solution grows.

In our new SRM projects the (SAP-) consultants asked if we'd like to use SolMan for the implementation or if we'd like to configure directly in SPRO. It was apparent that they were very happy we did not follow that SolMan approach but configured "by hand". This also enabled us to comprehend things that are configured as opposed to a wizard-like based approach where it's fine if it works but in case of a problem you have no clue where to look.

Since ST-ICO exists we didn't have a single project where SolMan implementation was actually requested, neither by SAPs own consultants nor internally.

> That said, I've never known anyone actually take direct access to the config client away from the configuration team (I mean, you know the fuss they make if they don't get SAP_ALL). And even in a solman implementation I'm sure large amounts of config gets done direct in the config client.

Full ack.

Markus

Edited by: Markus Doehr on Feb 10, 2010 12:30 AM

[Former Member]

> If I'd even only think about talking about to DARE to remove SPRO from our internal support stuff I'd be killed right away.

Perhaps you can show them [this|http://www.youtube.com/watch?v=VKkEKMTSyZQ&NR=1] ...

Cheers,

Julius