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.
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.
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.