cancel
Showing results for 
Search instead for 
Did you mean: 

How much time used to establish the solution manager env for a new ERP implementation project

Former Member
0 Kudos

Hi,

I'd like to know your number of consulting day used on Solution Manager for the first time.

As a BASIS guy in a consultant firm, we always deliver custom the latest - 1 version bits to customer. That means, we have to have solution manager up and running before installing ERP.

But we found that longer time need to complete our initial installation due to solution manager. We need to

1. Install Solution Manager                         (<1 day)

2. Upgrade Solution Manager using SUM  (>3 days)

3. System Prep and Basic Configure          (2~3 days, there are some "note implement" and sync stuff took much time)

4.  Install ERP DEV. (<0.5 day)

5. Register DEV into SLD and do "Managed System Configure", Solution Configure, Mopz , just for upgrade xml and approval.

    (depends on experience and version of SLM, could be 2 days to 2 weeks)

6. After  installation of PRD, do again Managed System Configure for PRD, and configure EWA. 
    (depends on experience and version of SLM, could be 1~3 days)

OK, we usually took 2~3 weeks (or 10~15 man days) to deal with solution manager. Almost cost 30%~50% of total BASIS MDs for a new implementation project. Some PM even question us why BASIS spent 50 days (20-days overrun) in a new ECC implementation project (including P/Q/D/SLM installation , authorization (PFCG) config and adjustment, and handover) 


I think Solution Manager really need a baby sitter, it's too complex, only for mid-large scale company.

Before convincing our PM and customer, I'd like to know other's number. If you have experience on that, please share your number.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

OK, things getting worse.

Now SAP sales push HANA as the only choice under ERP (new implementation), customers are forced to use SLM with Sybase ASE.... they don't like it, very few know about ASE.

Can they install their own database (MSSQL, Oracle...) for SLM ? without any charge ?

0 Kudos

Hello,

there is a little confusion about these topics: Solution Manager is quite a complex product to install and configure, but you don't technically need it to install SAP products anymore with new release. Furthermore, SAP doesn't really require every single customer to have one installed. The VAR should provide EWA to the customer instead using their own SolMan, this is part of their value added.

Best Regards,

Valerio

PS Solman is free of charge and as far as I know still available with all the rdbms supported by SAP

Matt_Fraser
Active Contributor
0 Kudos

That would be news to me that HANA is the only option for new customers. You can definitely still download the installation media for other DB platforms. Eventually HANA will be the only option, but that day is still many years away. That doesn't mean that SAP sales personnel won't aggressively push HANA, but I think you (or your customer) should be able to push back if you really don't want to go the HANA route (yet).

Solution Manager is definitely complex. It has some nice value-adds, but at the expense of a lot of Basis/SysAdmin time configuring and managing it, and yeah, it can at times be a hard sell to management to justify that time. For an initial implementation, though, I think you could get the basic "manage system configuration" level done without much trouble, just enough to have MOpz functionality for support packs and maybe EWA for vendor support, and the customer can always decide later if they want to enable the other features.

Still, it seems to me that your policy of not installing the latest release is unnecessarily adding days (and complexity and risk) to your implementation strategy. Why install an older release of SolMan if you're only going to immediately upgrade it anyway? For that matter, as of this moment only one version of SolMan, 7.1, is officially supported, so you are going into vendor-non-supported territory by doing new installs of 7.01 (presumably that's your "latest -1" version). In my case, when it came time for us to upgrade our 7.01 system to 7.1 (a system that had variously been upgraded from 4.0 to 7.0 to 7.01 over the years), I decided to cut the ties and install a fresh, new 7.1 system rather than upgrade the old system. It was much cleaner and has since been less troublesome. A lot less troublesome.

Former Member
0 Kudos

Fraser,

  Thanks for your comment.

About the available database type for Solution Manager, I know technically it is possible to use any database (Oracle, MSSQL, SAP MaxDB, SAP ASE, and more). However, restriction applied with your license. For example, we purchased ERP license with Oracle database (db type decides your MA fee %, you can't have it all), so in my service market SLM download page, I can only see SAP MaxDB, SAP ASE, and Oracle as choices. For those customers only purchase ERP on HANA, they won't see Oracle / MSSQL there. That's why I said SAP ASE (forget about SAP MaxDB, I have no idea about it) is the only choice.

In addition, why we tired to use latest version of SLM ? Is it necessary ? Sure, as a implementation consultant, we should deliver customers a brand new ERP with the latest (or latest -1) SP level. To upgrade the ECC to the latest-1 SP level, we surely need solution manager installed and get MOPZ working, and get the god damn stack XML. 

Solution Manager is a changing product, 7.1SP13 (latest) is different from 7.1SP4 in many places. However,  SAP only deliver 7.1 SP4 as the base-line installation source. So you have to update it right after installation. Then you have to use SUM and spend couple days on it.

I really wish SAP can deliver SLM source with up-to-date SP level. We can just install it and use it.

If it is impossible, please don't let your install source lag behind the latest sp level too much.

Matt_Fraser
Active Contributor
0 Kudos

Ok, I misunderstood your "latest -1" idea, then. I thought you mean one release behind latest, but you meant one support pack stack behind latest. I still say that's a bad idea, though. Every support pack introduces bugs. Those bugs are fixed in later support packs. However, those later support packs also fix bugs that were introduced in much earlier support packs, or have been there all along, that aren't fixed in the latest-1 support pack. So why not go with the most bugfixes currently available? Why would you want to install a system with known bugs that have known fixes available and not install those fixes?

You're right that the installation media for SolMan 7.1 Service Release 1 delivers the product at sp4. However, they also deliver the latest sp stack, 13, with a ready-made stack.xml, so it's not that big a deal to quickly update it to sp13 before starting any configuration. I don't understand why this would take you ">3 days." The big change in functionality happened at sp8, and another almost-as-big change at sp10, by the way.

SAP does periodically re-release the installation media with a later sp stack level embedded. They call those service releases. For instance, NetWeaver 7.4 SR2 includes sp8. SolMan 7.1 SR1 is SolMan 7.1 sp4. I haven't seen anything yet on when an SR2 for SolMan 7.1 will be out.

I also misunderstood your "only on HANA" comment. I thought, first, that you were talking about ERP, not SolMan. In any case, yes, you will only see the database/OS platforms that you have licensed your SAP systems for, plus those that SAP delivers "free" to customers. However, if your customer licensed ERP on Oracle, that must mean that they want to use Oracle, and that probably they have Oracle experience in-house. So why, in that case, would they not also want to use Oracle for SolMan? SolMan 7.1 is not HANA-ready, by the way, but the next release, 7.2, due to come out next year, will be. It will be based on a NetWeaver 7.4 platform. So, if you have an ERP on HANA customer, I think you're right, MaxDB or ASE are probably their only options today for SolMan, but that will change next year.

To your original question, though, I have shared your frustration about configuring SolMan and how much Basis time it seems to absorb for little visible business benefit. I do think that with SolMan 7.1 sp10 and later this is significantly improved over how it was in the past. Also, having more experience with things like the managed system configuration and maintenance optimizer make those processes go much quicker and more smoothly than they used to, so that might be part of my growing comfort with the tool these days. These days, I can execute a Managed System Config for a newly installed ABAP or Java system in about 20 or 30 minutes, so I don't see it as a huge burden in relation to the overall installation. Of course, that's for an existing, installed SolMan system. I agree that the initial SolMan config is obviously going to take longer.

Cheers,

Matt

Former Member
0 Kudos

Matt,

Thanks for your comment.

You said  "I don't understand why this would take you >3 days.", regarding update SLM7.1SP04 to latest SPS (now is SPS13)

"3 days" is the best result so far we can reach. "3 days" doesn't mean 72 hours continuous SUM run-time, but the overall period of whole update process/operation. 


Can you share your number ? Did you use SUM ? How much time your SUM spend on DDIC_ACTIVATION and MAIN_IMPORT ?


Thank you very much

Matt_Fraser
Active Contributor
0 Kudos

You know, I have to reverse myself. I have been thinking of other systems. Your question caused me to go digging for the actual SUM logs and statistics from when I did that, and you're right, it did take a very long time.I did use SUM (I don't think there's an option for this), and I ran the update from sps4 to sps12 on a newly installed system. From the log, I see that it took two full days to run SUM (about 50 hours). Teasing out the numbers specifically for DDIC_ACTIVATION and MAIN_IMPORT is now difficult, as all I have left is the XML file that I sent to SAP for the evaluation summary after it was done, and those phases are somewhat split between shadow and downtime main phases.

I did write in the evaluation summary that "Overall runtime was significantly longer than anticipated. Shadow system import procedure takes much longer and uses more resources, especially disk storage volume, than traditional SPAM/JSPM import procedures." I wasn't very happy about SUM at the time.

I suspect the runtimes could be much improved with better tuning of the import parameters. I am still learning how to best tune these things, and today I suspect I would have been more aggressive in choosing bigger numbers for r3load processes, etc.

So, with two days of running SUM, plus the various times spent setting it up and post-processing, I have to stand corrected. You are right, three days to apply the SP stack is probably about right for a SolMan system. Which means that, yes, issuing a new Service Release with the latest SP Stack included would be of high value to customers.

Former Member
0 Kudos

Matt,

Thank you for sharing so much.

Yes, it takes much time to update. I really hate SUM's shadow system concept for Initial Setup Update because we don't care downtime (nobody use it !). 3 days ago, I started to update by separating Java and ABAP Stack (Run SUM as javaonly option to update Java Stack, and then run SAINT to update ABAP Stack)..... It is still running the last step XPRA_EXECUTION now. I guess the total runtime will be 4 days. If I can't tune some parameter for parallel tp, could be faster.

It is a huge SP level update (from SSP04 to SPS13) and the open transaction hold very long, so my logsegment (SAP ASE) blow up twice and lots of troubleshooting needed during the update path.

I wish to have SLM7.1 SR2. Before that happen, I'll export this updated bits for new installation (SystemCopy it!).

Thanks

Answers (1)

Answers (1)

ksiebers
Explorer
0 Kudos

Wei-Shang,

I would like to confirm your estimated efforts to setup an SAP environment.

Honestly - it takes me a bit more time with all the preparation, checking and implementing OSS notes and post-processing.

Yes - during the project lifetime I have a dedicated FTE for SolMan - just to manage SolMan and support the functional consultants.

The benefit for the PM is that everything is proper documented, we have the monitoring, reporting and alerting landscape ready, we use lots of the self services before Go-Live and the transition to BAU runs smoother.

This reduces the risk and _saves_ costs...

cheers

Kay

Matt_Fraser
Active Contributor
0 Kudos

I wish we could do that! Have a dedicated FTE for SolMan, either during our implementation or now, during continuous improvement. Instead I manage it "on the side."

ksiebers
Explorer
0 Kudos

Hi Matt,

yes, most companies underestimate the effort that's necessary to maintain and support all the wonderful functionality - from project maintenance to ChARM ...

cheers

Kay