Skip to Content

Some Background first

As per usual, the project hit the ground running, wanting a full development suite up and running and patched yesterday. So we booked some consultants (not enough as per usual, “Thank you salesman“), got some virtual servers and started installing. (This is a Greenfield implementation)

Now the installations all went well (except BusinessObjects on Linux, which is a different story), as did the installation of Solution Manager 7.1.

Now as you all know the SAP installs are delivered at certain Support Stack levels and you will need to apply further support stacks afterward (unless you have the correct stack.xml file, which you can only generate with the maintenance optimizer).

So the fun starts with manual downloads and logging calls with SAP for approval. You can get add-ons such as FINBASIS605 with this method, download yes, but Stack.xml no. MOPZ (maintainance optimizer) is needed.

In a perfect world our functional consultants would have been able to wait for Basis to complete the Solution Manager config and get maintenance optimizer up and running. (Assuming of course the network team gets cracking on getting the VPN link working in time).

 So what about Solution Manager 7.1

Why don’t I listen to myself? New product, just released, there will be pain!

Forget everything you used to know about getting solution manager running smoothly. Don’t touch transactions SMSY, SPRO, etc, the way you used to do it, you have to use the guided procedures otherwise you will end up in a mess.
Also make sure you finish every single task with a green light (that does not mean you manually set them to “implemented”).

The second you start solman_setup, you are asked to implement a note. This one note has about 100 predecessors that need applying (and remember we don’t have our SAP service  connection in yet). Many of these have long winded manual tasks that need to be performed, so you need to register yourself as a developer, etc, etc.

So you think you have finished applying SAP notes? Well you go home come back the next day, run solman_setup and the note has been superseded and the exercise starts again.

So all in all with dedicated time, it would take somebody about 2/3 weeks of long days to get the system up and running (with constant interruptions from Project Management of course, and your other day job).

In parallel to you getting Solman up and running, your team has started to build the rest of the landscape. And obviously you need to register these systems into an SLD (system landscape directory). I suggest at this point you don’t use Solman as your SLD as you’re still working on it and you may have to bring it up and down a few times.

Only once you have completed solman_setup (both guided procedures), should you attempt to link the LMDB (Landscape managment Database) to the central SLD (yes you have to go back into Solman_setup to do this and yes the note will have been superseded, so back to your ABAP skills)

In the meantime the S&A (security and Authorization) guys have started to use CUA (central user administration). So when you start adding all of the systems into your landscape (again a guided procedure) and get to the bit where you have to create all of the RFC destinations, you can’t do it as CUA gets in the way. DOH! So disable CUA temporarily for each system (and get in in the neck from said S&A guys).

By now you’ve managed to get the maintenance optimizer working (Networks has finally established the connection). Only now can you get yourself up to the required support stack and any relevant add-ons that are required (of course your functional team have come up with a whole host of new add-on requirements in the mean time).

But oh no! The functional consultants have already started config/development. You can’t take the system(s) down and nobody has time for adjusting modifications with transactions SPAU/SPDD. And of course you get complaints that the systems have been installed without the required add-ons and patches

So what are the lessons learned?

A) Solman 7.1 still has some way to go in terms of quality
B) SAPs insistence on using MOPZ is a pain in the *** for new installations (although I can see the benefits later)
C) As MOPZ relies on the service connection (as does the efficient configuration and fixing of Solman), the service connection to SAP has to be the first thing that is done on a project.
D) Any project plan that requires an Environment to be available and patched (even as a sandpit) in the first two months of project start up should be challenged.
E) Don’t let salesmen/Management get away with only allocating one Snr Basis resource for the first two months of a project. The config of Solman will slip even further with all the usual project stuff that goes on taking up your time. For a full system (with all the components), to be ready in 20 days, needs 3 people minimum and a dedicated Solman expert.
F) Don’t switch CUA on until you are good and ready.

Other stuff

OK Solution Manager completed, all systems have been registered. Now the fun begins.
Setting up Monitoring/EWA, etc is fairly easy as Basis terminology is still being used. However many of the areas of Solution Manager (Charm/helpdesk, etc) are very very CRM orientated.
Of course it is up to Basis to second guess what the requirements are going to be and configure the damn thing. BUT us Basis guys/gals don’t understand functional speak. What the hell are Business Partners, can’t you just call them “People who log calls” and “People/teams who look at issues”.
And when it asks you to copy transaction types? How the hell is a Basis consultant to know what transaction types you need to copy.
The documentation really does need to be made much clearer and should not rely on a training course to get the config up and running. (Remember we are in a recession, I can’t remember the last time I saw a training budget).
And don’t get me started on help.sap.com. I remember the brilliant 2.1 and 2.2. Documentation CDs and the even better blue books.

In conclusion.

Plan well ahead and double your estimates in terms of time and people. Do not let project management get away with thinking that installing a working environment is just A:\install.
Kick and scream at the network teams to get the VPN connection up and running ASAP.

Solution Manager is no longer just a tool that SAP mandates, where you can get away with the bare minimum.
Sales guys and solution architects need to factor Solution Manager in as a strategic tool and allocate the required resources.
Proper blueprint workshops will need the be scheduled in just the same as all the functional workshops.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Matt Harding
    Hi Fenton,
    I must admit I liked the style of your blog, and while I don’t have much in the way of practical experience to add in this space; I will definitely keep those learnings in mind. For something that is becoming a mandated part of customer landscapes, Sol Manager gets very little attention from project teams including SCN not really tackling the non-basis consultants out there IMO.
    Cheers,
    Matt
    (0) 
  2. Kevin Grove
    Fenton
    Thank you for taking the time to document the reality of SAP implementation projects, especially the startup phase. I also completely agree with the CRM-centric aspects requiring Business Partners and the like. I will admit that solman_setup works fairly well, but it is frustrating for those who started with the older versions of Solution Manager.
    For those of us facing upgrades in the near future, this type of information is appreciated.

    Regards,

    Kevin Grove

    (0) 
  3. Patrick O'Leary
    Fenton,
    Many thanks for not sugar coating the truth on SAP Solution Manager.  It is a powerful tool that businesses should be using, but it is demanding and painful to install.  Of course, it is worth the effort, but it does take some significant effort to get right.  However, I can not understate the high value of using Solution Manager to stay current, spot and prevent significant risks, and give your team skills for continuous improvements.  Fenton, I think you would agree, Solman is a huge effort to implement but a very positive, powerful, valuable tool that everyone should be using.  Many thanks for your blog.  Patrick O’Leary   patrick.w.oleary@accenture.com
    (0) 
    1. Fenton Morris-Winmill Post author
      I’ve been an advocate of Solution Manager since version 3.1. Initially just as a basis tool.
      It has the potential to be very powerfull. However SAP made the mistake of giving it away for free. If it had been a licensable product I think adoption may well have been higher and with the assiciated funds quality much much higher.
      But it should be far easier to use. Please SAP take a bite out of the Apple philosophy. “It just works out of the box”.
      Also ownership of Solution Manager should no longer be with the Basis teams. Projects now need a full time ALM expert, to look at the whole support structure. Proper ALM workshops need to be held as part of project methodologies.
      Unfortunatly the holder of the purse strings often do not see the value
      (0) 
  4. Tom Cenens

    Hello Fenton

    Entertaining blog post I must say. Technical consulting is sometimes perceived as clicking “next” or “install” and that’s basically an insult. Things aren’t as simple as it seems.

    Solution Manager is one of the more interesting area’s for basis administrators and/or technical consultants to gather knowledge on.

    The wizards in SOLMAN_SETUP in Solution Manager 7.1 are very nice but once the automatic configuration fails and an error is thrown it also shows weakness. The errors displayed on screen are not always meaningful and often require deeper investigation to discover the root cause and fix that root cause.

    If some think you can throw away the necessary basic know-how on Solution Manager, the base, the core, forget about it. You will need it to get things right.

    Kind regards

    Tom

    (0) 

Leave a Reply