Background Consider the scenario:
- 200+ sales reps have been using a (non-SAP) mobile solution on their laptops for a year
- the reps (and laptops!) are distributed throughout the country
- you need to update and populate the CRM 4.0 online system with data AND get it onto the laptops in the shortest space of time (<3 days…)
This is what faced me in my first CRM MSA rollout last year. It was a CRM 4.0 Ramp-Up project on SP3. Prior to the go-live, all reps were due to attend MSA training for a couple of days, at which time the MSA software was to be installed. Our original rollout plans for loading the data they needed were to recall all of the laptops to a central location during the go-live and then load the data per PC using an initial extract and download of each users’ data. Despite fears about the volume of processing this would generate on the online system as well as the time taken per pc to process the data, we had no other viable alternative.
However the final rollout was delayed by 6 months, initially due to a number of application related issues but also in order not to interfere with the busy summer sales activities of the reps. Because of the many problems encountered whilst working with such an early release, it would perhaps have made more sense to use this 6 month period to upgrade to a higher SP release level. However the decision was made to continue to go live with SP3 and not risk any additional delay or problems that an upgrade could cause.
In actual fact, the project delay proved to be a godsend as it gave us some time to look at a tool available with CRM 4.0 called the Rollout Manager. In a previous life (CRM 3.1) it was known as the Recovery Manager and essentially was there to help replace stolen/defective laptops that needed to be re-rolled out quickly.
The new Rollout Manager may well have been updated and improved (I never saw the original) but I could not find anyone who had any experience in using it, so it looked like trial and error was just round the corner….
The Rollout Manager Essentially the Rollout Manager is a way of replicating common data to one or more (preferably 200+) PCs. Although each user has many subscriptions assigned to their individual mobile sales site, a number of those subscriptions contain common data as these subscriptions are assigned to everyone. The trick is that the Rollout Manager itself is setup and linked to CRM online system as a normal Mobile sales client, with its own SQL database. However it only has the common subscriptions assigned to it – no ‘personal’ data is allowed! Once this common set of data has been extracted, downloaded and processed into the local ides, it is available for copying in its entirety to target client sites.
In order to asses its usefulness, we created 2 sites, one as a mobile client with a typical set of subscriptions assigned including all ‘personal’ data related to that sales rep, and one with just the subset of common data subscriptions. A full extract was then done for each site, the data was downloaded (via conntrans) and then all messages were processed on the local PC.
The results showed that for a ‘typical’ user, the final database size was about 1Gb and that the processing of messages locally (after conntrans download) took 3-4 hours. In comparison the common data database was around 750Mb, with processing between 2 and 3 hours.
We then tried to use the Rollout Manager to see what this would translate to in terms of reduced rollout time. The Rollout Manager needs to be set up once only – just with common data subscriptions – and a full extract and local processing is run. Once this one-time action is complete then you can start the Rollout Manager program. This allows you to select the target PC (prerequisite is that the target laptop is defined in SMOEAC and that its list of subscriptions contains ALL of the common subscriptions defined to the Rollout Manager PC).
The Rollout Manager requires access to the CRM online system as well as to the SQL\Data directory and registry on the target client(s) and can then begin the following series of steps:
- check rollout manager site details in CRM online
- check for pending inbound records
- release target site(s) for reuse (if site is already assigned)
- clean outbound queues for target site(s) (if contain any data)
- run conntrans on rollout manager to get latest common data
- start the extract for target sites of all non-common data in CRM online
- take copy/backup of rollout manager ides database
For each target site selected (several sites can be selected at once, although the following processing is sequential):
- restore database onto target client pc
- assign site (‘cleans up’ incorrect SQL and registry site-id entries)
- start conntrans on target client to download user-specific data (optional)
The initial set of steps took just a few minutes and the data backup (for 750Mb) only 2 or 3 minutes. It is from this point on that it became very interesting as each ides copy to a target client took only 2-3 mins (on a normal LAN connection). The triggered download of the additional ‘user’ data via conntrans took only 4 or 5 mins to get onto the target PC and the local processing took less than 45 mins. This translates into a saving of around 3 hours per PC as well as a huge reduction in CRM online processing that would have been necessary to extract and distribute the common data for every single target client.
After ‘playing’ with the Rollout Manager (basically attempting to break it by seeing precisely how many PCs it could cope with at any given time), we settled on rolling out a ‘wave’ of 10 laptops per selection. The limiting factors were the Rollout Manager’s ability to handle and display long lists of target PCs as well as the impact on R&R queues at the time the full extract of local data was done for all selected PCs.
Our final decision was actually to use three rollout managers (3 physical desktops), running 1 selection, extract and copy to 10 target PCs every 20 mins. This way we could process up to 30 laptops per hour (and leave the target clients running the downloaded data from conntrans by themselves).
Pre-Rollout Activities The first problem to overcome was a logistical one – involving each of the sales reps handing over their laptop to the nearest local office and having them sent by courier to a central location. Correct labeling of each laptop (PC name, location, user, etc.) was of paramount importance (as long as it was not separated from its carrying case!).
The steps taken in parallel were the conversion and data loading of the CRM online system as well as defining all of the sites and adding the final subscriptions, etc. Additional configuration steps using AMT and MSY were also carried out at this point.
The final part that was needed was to activate the 3 Rollout Manager sites, run a complete extract and download the data using conntrans to each site. After the local processing was complete, each site was tested to verify that all data that was expected had actually found its way into the database.
The Rollout Day 1: In order to ensure that all the information for the sales reps worked correctly, it was decided to restrict the initial rollout to just 10 target laptops. From start to finish all 10 were ready in under 2 hours (including all local processing) and they were then given to the sales reps to use ‘on the road’. Initial feedback was positive and the go-ahead was given to process the rest of the laptops.
Day 2: This is where the Rollout Manager really came into its own. In a kind of ‘war room’ setting, we rolled out 25-30 laptops per hour (just unpacking the laptop, making the network connection, logging on, preventing screen saver, checking rollout, disconnecting network, shutting down, packing away, etc. was an effort in itself – especially trying to keep track of the status of 30-50 laptops at any given moment!). By the end of the day another 170 laptops were ready for the road (back to the courier and then overnight to the remote offices).
Day 3: This day had been reserved for the ‘heavy users’ – laptops identified with subscriptions that contained hierarchical data (for sales managers, regional managers, etc.) – and so although we only rolled out another 40 or so PCs, the initial extract queues were much larger and consequently the download and especially the local processing each took several hours. Some of these had to run through the night to get the data in its correct form on the local sql db, but by the morning everything was ready. We had done it - 220 PCs in 3 days.
The Future Prior to the go-live, we thought it would be a good idea to keep one active Rollout Manager for just one month after go-live to be able to quickly re-rollout a laptop in case of any problems. Ten months later the Rollout Manager is still there and being used several times a months in its role as ‘Recovery Manager’ – quick re-rollout of defective/stolen laptops. It takes a little longer to run as the common data has also grown in size over the last year, but it means we can turnaround a replacement PC back to a ‘needy’ sales rep much faster than if we would have done a full extract of all of the data.
The Verdict Despite a few quirks, a great tool to use for fast deployment. Probably useful if you need to rollout 20 or more laptops with a reasonable proportion of common data (e.g. 60% +).
Tech Stuff - Q&A How do you install the Rollout Manager? - During the Mobile Sales Client installation, it is an option using the 'custom installation' in 'All Mobile Application Development Components', subset 'All Administration Tools'.
What is the program called and where is it? - LptProvider.exe in the \SAP\Mobile\Bin directory
Why did you choose just to rollout only 10 laptops during any given run of the Rollout Manager? - During testing we found that on the second screen of the Rollout Manager (the point at which you identify the IP addres/name of the target sites), the program's array processing of more than 10 selected sites was a little 'unstable' and sometimes locked the PC. Handling 10 at once was no problem and this also limited the impact on the R&R queues in CRM online.
