We have a love/hate relationship with it. MOPZ initially caused a lot of hate as we knew how to download everything and install it, so it was one more step. SAP also forced everyone to use MOPZ to confirm various downloads, whereas before, you could just build a stack, download the xml and files, all from service marketplace. MOPZ has come a long way in 7.1 and it's benefits mostly out-way the negatives lately.

MOPZ is a lot better than it used to be. Main troubles nowadays are usually when the system itself is actually supplying incorrect data (due to incorrect data in the PRDVERS, SWFEATURE, or SWFEATUREINC tables, or corresponding tables in AS Java), which requires SAP support to tell you what lines are actually consistent with the system identity.

We have been struggling with getting technical monitoring fully setup. We have hundreds of systems and getting the DAAs, saphostagent, SLD configuration, cim updates, CRDelta updates, wily agent, etc all installed, configured, updated, and functioning on so many systems is a major struggle.

I do agree it's a struggle. If you have a fairly homogeneous environment (from an OS/architecture perspective) you can create an unattended answers file to install the SolMan Diagnostic (a.k.a. DAA agent) on multiple systems. Updates of the agent isn't bad as kernel updates are typically not required unless you change operating systems (and the old kernel version isn't supported) and applications are updated by updating LM-SERVICE on SolMan AS Java.

(By the way, never install an LM-SERVICE outside of your support pack of SolMan; e.g. install LM-SERVICE SP13 while running ST 710 SP10. It's unsupported, won't work, and the only way to get consistent is to revert to a backup before you did it).

The Host Agent is easy since it's about 10 seconds to install, requires only one input (./saphostexec -install). Also, there's an automatic update mechanism to have the host agent check a single location and automatically apply updates. That makes ongoing maintenance easier.

CR Content updates aren't so bad once you document how to do them. Initial population of the SLD is slooooow if you start empty though. Wily agents typically aren't bad since they're deployed automagically by SolMan, except for having to plan for the outage, and a known stack issue where the component ISAGENT 8 as shipped on SolMan AS Java ships a non-working wily agent for managed systems running NW releases below than 7.11 (java system components page shows that component as 8.24.0 with a build date of Jan 2012). You have to deploy that patch via SDM since they forgot to increment the patch level in the SCA (correct version will show as 8 SP24 0, built in June 2012).

Plugin strategy regarding ST-PI and ST-A/PI has traditionally been harder than the above in my experience.

Add to that, SAP always recommends that you run on the latest Support Pack, and nearly every new stack that is released, introduces major features and many times, cause you to have to go back to your hundreds of systems and change something here, update a new sap role there, spend hours in managed system configuration, etc.

Most customers I observe that use major functionality are targeting about one support pack a year. Anything more is very high from a maintenance effort. SP12 reduced a lot of maintenance effort with the concept of minimal vs full MSC (less data and setup effort for non-prods) and automatic Managed System configuration so manual changes that used to just pop the updates needed flag (addition/removal of an instance and a bunch of others) will now have solman automatically re-execute the required step for you. There's also a Solution Manager user administration tool in SP10 onwards that allows you to upload new copies of the SAP standard Managed System user roles out and copy to the customer namespace en masse.

Once it's working, you obviously need to figure out what monitors makes the most sense for your team and continually tweak them so you don't get any false positives or negatives. This is less of an SAP issue as it's just a requirement of setting up any new monitoring software.

Of course. Technical monitoring is generally easier as you can correlate it to what you monitored previously in CCMS. The other tools can be great but you need to sit down and define what alerts you really need and why.

This all assumes that everything is actually working correctly. Historically, I've had to install tens to hundreds of sap notes to get basic areas to be functional. The central note in solman_setup has helped with this, but there are still so many bugs to be fixed whenever you attempt to do something new.

There's also notes by area, I do agree tracking all the notes has been challenging but it has been improving at least.

I'd be curious how your company got to the point of hiring you to work solely on Solution Manager? As others have indicated, it seems to be a universal problem to convince management to hire someone full-time to work on it, as it truly does take that kind of commitment.

I work for a certain German company helping companies plan and set up Solution Manager functionalities. That said, I have been to customers where people are dedicated to SolMan (e.g. 80%+ of their time is spent on SolMan and they are called the SolMan team by others at the customer). Usually this happens at larger customers where the landscapes are complex, multiple functionalities are on, there's a lot of plumbing (agents, RFCs, etc.) to keep everything working, and it's something that forms over time. Many of the individuals at companies I visit have expressed frustration regarding that "universal problem".