Introduction Movilizer for SAP DSD:
Executive Summary

Download PDF description: Summary

Direct Store Delivery (DSD) is normally part of a company’s core business; part of the “order to cash” process. For this reason and due to the high complexity of mobile DSD processes (requiring pricing calculation, signature capture, invoice generation, delivery creation and adjustments, returns handling etc.) using a mobile application is a must. In fact, today most companies running DSD already use some type of mobile device.

In recent years, we have been observing two fundamental market developments that obligate most companies to rethink their current mobile strategies:

Your mobile DSD solution needs to be able to adapt quickly to changing requirements. Because DSD is core business for your company, the order to cash responsible requires flexibility and agility to innovate, especially in days where ubiquitous connectivity of customers and employees open new opportunities for innovative business models; there are many examples of this, but to mention some: Creating mixed roles for drivers who not only deliver presold orders but also refill vending machines, or customers that do “self ordering” via their own smart phones. Monolithically built and rigid applications (“deploy once run forever”) and “offline only” types of mobile DSD applications are definitely not an option in today’s market.
The appearance and rapid penetration of very heterogeneous smart phone platforms (Iphone, Android, Blackberry, Nokia Mobile Phones, Windows Mobile 7.0 etc.) and the improvements on the GPRS/3G connectivity conditions, necessitates one to rethink former mobile strategies that were typically focused on delivering pure offline mobile applications on industrial devices (mostly rugged PDAs). Now, more than ever, customers are asking for lightweight, granular mobile apps capable of running not only on PDAs but also on any mobile devices.

The Movilizer for SAP DSD was designed and created to address precisely these two requirements. It is exactly this, together with the fact that the Movilizer is such a low cost platform that you can even deploy it on your customers and distribution partner’s mobile phones, that opens a whole range of new opportunities for business process innovation.

The Movilizer does not necessarily need to be a replacement for existing mobile DSD or Van Sales solutions. Even as a complement to currently functioning mobile DSD applications, the Movilizer can bring you great value! The Movilizer will run on the same devices as your existing mobile DSD application does today and it will easily integrate with it: on the device (see technical details below).

1 Functional Features

Delivery driver role
Full service vending role
Pre seller role
Van seller role
Mixed roles
Side roles (complementary to existing DSD or PoD applications)

2 Technical Features

Runs on any mobile device
Comprehensive configuration possibilities, marginal programming
Does not require additional hardware
Supports barcode scanning and RFID
GPS geo-coordinates
Multimedia files (download / upload)
Supports printing (ex. for invoice or delivery note printing)
Captures digital signature

3 Unique features

Simplicity and Cost
- It runs on any simple mobile phone
- It is deployed in seconds (device setup can be done by the end user)
- It does not require any end user training
- It takes weeks to implement and you can do it yourself
- No upfront licenses
- Monthly support fees (SaaS)
- You are 100% in control of future changes and enhancements in the app
Flexibility
- It is device agnostic
- Configuration instead of development (Movilizer customising in SPRO)
- It allows changing processes on the fly
- You can create "mash-ups" (interfacing SAP with non-SAP) on the mobile device
Integration
- Multi Backend integration via the Movilizer cloud (with SAP AII, SAP ERP or non SAP)
- "On device background integration" with PM, PoD and WM mobile applications
- Development only in backend (e.g. ABAP/4)

The diagram represents the holistic view of our Movilizer for SAP DSD solution from a logical point of view (click image to enlarge).

Movilizer for SAP DSD - a different approach to mobile DSD

“Tailor make your DSD roles using our standard pool of DSD mobile functions”

We have not developed another mobile application for beverage or vending companies, but instead rethought and redesigned the concept that is behind such applications from the roots. Our innovative approach can be summarised as follows:

Even though most customers have similar high level functional requirements for mobile DSD processes, the exact detailed requirements are never the same. Therefore, with the Movilizer for SAP DSD, each individual customer is able to structure the sequence of processes/process steps individually. We do not provide you with a monolithic application, but instead with a pool of processes, which you can combine and configure to match your very specific and individual requirements.
The Movilizer for SAP DSD has not only been defined as a standalone application; instead, it can be run as a supplementary/complementary application. It is therefore possible to integrate functionalities from other areas (e.g. materials management or financial information) into Movilizer for SAP DSD process flows. (E.g. a global beverage company uses a non Movilizer based van sales application for classic routes but has integrated it on the device with Movilizer for DSD in order to allow the driver executing full service vending routes as well).

1 Functional Features

Flexibility and adaptability are crucial for any mobile track & trace application. However, to minimise the implementation time, the Movilizer comes with some preconfigured roles, which can easily be changed and configured to your individual needs. Any of the functionalities pre-delivered as part of a standard role can be mixed or combined to create customer specific roles.

Title	Function
Delivery driver scenario	The typical delivery driver´s job is to deliver presold products. This means that the delivery already exists on SAP ERP and is downloaded to the Movilizer for its delivery. On occasion, the driver may need to adjust the delivery (change quantities, add or remove line items etc), very frequently re-pricing and ad hoc invoice / delivery note printing are usual requirements. Additionally, because the driver takes materials and cash the check out and corresponding check in processes need to be put in place.
Full service vending scenario	This is a common practice mainly in mature markets. In these markets, beverage or food companies having vending machines (cold or hot vending) normally do full service vending (where your company takes care of the machine maintenance, refilling and cash collection). For this purpose a DSD full service vending (FSV) route is created in the SAP DSD backend. Among other functionalities, the driver needs to be able to maintain, refill and collect the cash from the vending machine via the mobile application. Materials and cash are also with the driver, and so check-out and check-in processes are normally a must.
Pre-seller scenario	Pre-sellers do not work on routes dictated by presold deliveries. They normally work on visit plans. They visit customers and take sales orders on customer side, running some collateral merchandising activities (backroom cleaning, running surveys, planograms etc.). Because they usually do not have any cash or materials in their car (only point of sales - PoS materials if any), no check-out or check-in processes are required. In some situations, pre-sellers even start the day from home and not from the distribution centres.
Van seller scenario	Van sellers are those selling directly out of the van to planned or unplanned customers. They visit some areas or outlets and sell the stock they have on their van (originally allocated to the driver). They create ad-hoc deliveries on the mobile application.
Mixed scenarios	We recognise a trend in the market to mix roles, by allowing for example, a delivery driver to do some basic van selling, or by giving the van seller full service vending capabilities (so that vending machines can be refilled in case stock is still available on the truck before the end of the day). The Movilizer supports any type of mixed roles even with non Movilizer based applications thanks to the concept of “on device” background integration.
Side scenarios	Marketing surveys and merchandising activities are a very good example of this. Increasingly, customers try to leverage existing channels into the customer to run side roles such as marketing surveys or some element of basic merchandising. With the Movilizer, any side role is supported.

By combining the basic functions available from the predefined roles, any upcoming future requirement can easily be built. Thanks to this modular structure, building new or modifying any of the existing functions can be done at a very low cost, and what is even more important: it can be done by your own IT resources (“Movilizer it yourself” principle).

What does it mean that you can do it with your own IT resources? It means that new processes are defined purely in the SAP backend (in ABAP/4 language). This means that any ABAP developer from your IT department, after one week intensive Movilizer training is able to create new functions or processes or to modify existing ones without any external assistance in record time.

Delivery Driver Role

1. Route preparation

1	Deliveries are created in SAP	Deliveries are created based on the sales orders taken by sales reps or by call centre agents.

2	Deliveries are grouped in shipments	Once created, the deliveries are grouped in shipments. They are assigned to a combination of driver/route in the SAP backend during the tour creation.

3	Shipment is assigned to a mobile driver	After shipment completion status is reached, the shipment is assigned to the mobile phone of a selected driver. We can control the shipment status at any time with an especial monitoring screen.

2. Start of day & Check-Out

1	The driver receives the shipment in his mobile device	Deliveries are created based on the sales orders taken by sales reps or by call centre agents.

2	The driver performs the start of day activities	The driver runs the start of day activities on the mobile device. These include: Vehicle confirmation and odometer registration.

3	The driver does the material check-out	The driver does the CO process: Material and money.

4	The driver does the money check-out	The driver does the CO process: Material and money.

3. Route execution

1	The driver starts the visit execution	The driver enters in the first planned visit and checks in the info visit screen the customer and delivery information.

2	The driver performs delivery	Once at the customer site, the driver and the customer check the planned delivery. The driver then adds/decreases materials or modifies quantities (return and non-return) (full and empties) depending on the customer info.

3	The invoicing (online, offline) is calculated	Depending on the customer payment terms, the generated document differs: Invoice or POD. In case of invoice, if the planned quantities are modified a price recalculation is needed. If internet connection is available, an online price calculation is carried out. If not, an offline price calculation is carried out. If the customer agrees with the recalculated price, the driver confirms delivery.

4	The driver generates the printout (invoice, POD)	The printing process is necessary if it is not generated in the backend or if the planned delivery is modified.

5	The driver does a money collection (old and current open items management)	The driver does the money collection process of the new and pending bills. The driver can collect the current visit invoice, downloaded pending open item or collect money without an assigned open item.

6	The driver adds or cancels a planned visit	The driver can add or cancel a planned visit at any time during the visit execution process.

7	The driver checks the inventory status	The driver can check at anytime the inventory material and modify it if necessary, selecting from the main menu screen the inventory option.

8	The driver introduces disruption times	The driver can introduce the breaking times he has encountered during the tour execution (even before the CO process).

9	The driver adds travel expenses	The driver can enter expenses incurred during the tour execution: Parking fees, petrol, motorway tolls etc.

10	The driver performs the end of day process	As soon as the driver finalises the last planned delivery, the end of day process can be executed.

4. Check-In & Settlement

1	The driver does the material check-in	The driver does the material CI process.

2	The driver does the payment check-in	The driver does the payment CI process.

3	The RADB tables are actualised	Sync is done and the RADB tables are actualised with the tour info, so the settlement cockpit process can be run.

4	Settlement process is finalised at the backend	During the final settlement, all the financial and materials postings are generated based on the data collected during the route execution.

5. Others

1	Route monitoring (inventory tracking, post assignments, GPS route tracking, delay tracking) from the backend	At any time, Control staff can trace a shipment status. They can know the truck GPS coordinates, the delay times or the shipment delivered orders, just using SAP R3.

2	New visit creation from the backend	At any time, Control staff can modify the planned delivery order. Drivers will receive the new status of pending orders after every synchronisation.

Full Service Vending Scenario

1. Route preparation

1	Replenishment visits are created in SAP	Replenishment visit lists and plans are created based on the historical info we have from each customer.

2	Replenishment visits are grouped in shipments	Once created, the deliveries are grouped in shipments. They are assigned to a combination of driver/route in the SAP backend during the tour creation.

3	Shipment is assigned to a mobile driver	The shipment is assigned to the mobile phone of a selected driver. We can control the shipment status at any time with an especial monitoring screen.

2. Start of day & Check-Out

1	The driver receives the shipment in his mobile device	The driver synchronises and downloads the first assigned shipment data at the start of his journey.

2	The driver performs the start of day activities	The driver runs the start of day activities on his mobile device. These include: Vehicle confirmation and odometer registration.

3	The driver does the material check-out	The driver does the CO process: Material and money.

4	The driver does the money check-out	The driver does the CO process: Material and money.

3. Route execution

1	The driver selects vending machine (hot, cold, empties, cabinet)	The driver selects the first planned vending machine visit he is going to execute.

2	The driver starts replenishment process	The driver checks replenishment visit information and starts the work (product replenishment, counter reading, handling money, testing vends etc.).

3	The driver adds or cancels a machine replenishment visit	The driver can add or cancel a planned visit at any time during the visit execution process.

4	The driver checks the inventory status	The driver can check the inventory material and modify it if necessary by selecting the inventory option from the main menu screen at any time.

5	The driver introduces disruption and break times	The driver can introduce the disruptions and breaking times he has had during the tour execution (even before the CO process).

6	The driver adds travel expenses	The driver can enter expenses he has incurred during the tour execution: Parking fees, petrol, motorway tolls etc.

7	The driver performs the end of day process	As soon as the driver finalises the last planned delivery, the end of day process can be executed.

4. Check-In & Settlement

1	The driver does the material check-in	The driver does the material CI process.

2	The driver does the tour cash and bags check-in	The driver counts the cash and bags money and tokens.

3	The RADB tables are actualised	Sync is done and the RADB tables are actualised with the tour info, so the settlement cockpit process can be run.

4	Settlement process is finalised at the backend	During the final settlement, all of the financial and materials postings are generated based on the data collected during the route execution.

5. Others

1	Route monitoring (inventory tracking, post assignments, GPS route tracking, delay tracking) from the backend	At any time, Control staff can trace the shipment status. They can know the truck GPS coordinates, the delay times or the vending replenishment orders, just using SAP R3.

2	New visit creation from the backend	At any time, Control staff can modify the planned replenishment order. Drivers will receive the new status of pending orders after every synchronisation.

Pre-seller scenario

1. Route preparation

1	Visit lists are created in SAP	Visit lists and plans are created based on the historical customer info and new customer calls.

2	Deliveries are grouped in shipments	Once created, the visits are grouped in shipments. They are assigned to a combination of user/route in the SAP backend during the tour creation.

3	Shipment is assigned to a mobile user	The shipment is assigned to the mobile phone of a selected mobile user, sales or marketing employee. We can control the visits status at any time with an especial monitoring screen.

2. Start of day

1	The mobile user receives the visit lists in his mobile device	The mobile user synchronises and downloads the first assigned shipment data at the start of his journey with the first assigned visit.

2	The user performs the start of day activities	The mobile user runs the start of day activities on his mobile device. These include: Vehicle confirmation and odometer registration.

3. Route execution

1	The mobile user starts the visit execution	The mobile user enters in the first planned visit and checks in the info visit screen the customer information.

2	The mobile user performs taking order activity	Once at the customer site, the mobile user creates a new taking order activity with the material required by the customer.

3	The driver generates the printout	The printing process is triggered if the customer wants to have a copy of the taking order.

4	The mobile user does a money collection	The mobile user completes the money collection process for the pending bills. The mobile user can collect pending/open items or collect money without an assigned open item.

5	The mobile user adds or cancels a planned visit	The mobile user can add or cancel a planned visit at any time during the visit execution process.

6	The mobile user introduces disruption times	The mobile user can enter expenses he has incurred during the tour execution: Parking fees, petrol, motorway tolls etc.

7	The mobile user adds travel expenses	The mobile user can enter expenses he has incurred during the tour execution: Parking fees, petrol, motorway tolls etc.

8	The mobile user performs the end of day process	As soon as the mobile user finalises the last planned visit, the end of day process can be executed.

4. Settlement

1	The RADB tables are actualised	Sync is done and the RADB tables are actualised with the tour info, so the settlement cockpit process can be run.

2	Settlement process is finalised at the backend	During the final settlement, all of the new taking orders and financial collection accounts are generated based on the data collected during the route execution.

5. Others

1	Route monitoring (visit assignment, taking orders, GPS route tracking, delay tracking) from the backend	At any time, Control staff can trace the shipment status. They can know the truck GPS coordinates, the delay times or the shipment taking orders, just using SAP R3.

2	New visit creation from the backend	At any time, Control staff can modify the planned visits. Mobile users will receive the new status of pending orders after every synchronisation.

Van Seller Scenario

1. Route preparation

1	Deliveries and visit lists are created in SAP	Deliveries are created based on the sales orders taken by Sales reps or by call centre agents and visit lists are created based on historical info and customer calls.

2	Deliveries and visit lists are grouped in shipments	Once created, the deliveries and visit plans are assigned to shipments. A link between them, driver and route is established in the SAP backend during the tour creation.

3	Shipment is assigned to a mobile driver	The shipment is assigned to the mobile phone of a selected driver. We can control the shipment status at any time with an especial monitoring screen.

2. Start of day & Check-Out

1	The driver receives the shipment in his mobile device	The driver synchronises and downloads the first assigned shipment data at the start of his journey.

2	The driver performs the start of day activities	The driver runs the start of day activities on the mobile device. These include: Vehicle confirmation and odometer registration.

3	The driver does the material check-out	The driver does the CO process: Material and money.

4	The driver does the money check-out	The driver does the CO process: Material and money.

3. Route execution

1	The driver starts the visit execution	The driver enters in the first planned visit and checks in the info visit screen the customer and delivery information.

2	The driver performs delivery	Once at the customer site, the driver and the customer check the planned material. The driver then adds/decreases materials or modifies quantities (return and non-return) (full and empties) depending on the customer info.

3	The invoicing (online, offline) is calculated	Depending on the customer payment terms, the generated document differs: Invoice or POD. In case of invoice, if the planned quantities are modified a price recalculation is needed. If internet connection is available, an online price calculation is carried out. If not, an offline price calculation is carried out. If the customer agrees with the re calculated price, the driver confirms delivery.

4	The driver generates the printout (invoice, POD)	The printing process is necessary if it is not generated in the backend or if the planned delivery is modified.

5	The driver does a money collection (old and current open items management)	The driver does the money collection process of the new and pending bills. The driver can collect the current visit invoice, downloaded pending open item or collect money without an assigned open item.

6	The driver adds or cancels a planned visit	The driver can add or cancel a planned visit at any time during the visit execution process.

7	The driver checks the inventory status	The driver can check at anytime the inventory material and modify it if necessary, selecting from the main menu screen the inventory option.

8	The driver introduces disruption times	The driver can introduce the breaking times he has encountered during the tour execution (even before the CO process).

9	The driver adds travel expenses	The driver can enter expenses incurred during the tour execution: Parking fees, petrol, motorway tolls etc.

10	The driver performs the end of day process	As soon as the driver finalises the last planned delivery, the end of day process can be executed.

4. Check-In & Settlement

1	The driver does the material check-in	The driver does the material CI process.

2	The driver does the payment check-in	The driver does the payment CI process.

3	The RADB tables are actualised	Sync is done and the RADB tables are actualised with the tour info, so the settlement cockpit process can be run.

4	Settlement process is finalised at the backend	Sync is done and the RADB tables are actualised with the tour info, so the settlement cockpit process can be run.

5. Others

1	Route monitoring (inventory tracking, post assignments, GPS route tracking, delay tracking) from the backend	At any time, Control staff can trace a shipment status. They can know the truck GPS coordinates, the delay times or the shipment delivered orders, just using SAP R3.

2	New visit creation from the backend	At any time, Control staff can modify the planned delivery order. Drivers will receive the new status of pending orders after every synchronisation.

Side Scenarios

1. Marketing Surveys

1	Marketing surveys are created and assigned to mobile employees	Marketing surveys are created in a SAP/Non-SAP programs (ex: Movilizer App Portal or Microsoft Excel Add-on) and assigned to drivers or sales employees.

2	Surveys are downloaded and completed for each visit	Mobile users download the assigned marketing surveys and can complete them during each customer visit.

3	Surveys are uploaded to the backend	The survey replies are automatically uploaded to the backend in the next synchronisation. This enables marketing people to have a real time customer satisfaction status.

2. Merchandise Deliveries

1	Merchandising orders are created and assigned to mobile employees	Merchandising orders are created in a SAP/Non-SAP programs (ex: Movilizer App Portal or Microsoft Excel Add-on) and assigned to drivers or sales employees.

2	Merchandising orders are downloaded and delivered for each visit	Mobile users download the assigned merchandising orders and can execute them during each customer visit.

3	Merchandising orders are uploaded to the backend	The survey replies are automatically uploaded to the backend in the next synchronisation. This enables marketing people to have a real time merchandising campaign status.

3. New Breakdown Notification Order

1	New breakdown notification orders are created and assigned to mobile employees	New breakdown notification orders are created in a SAP/Non-SAP programs (ex: Movilizer App Portal or Microsoft Excel Add-on) and assigned to drivers or sales employees. With any empty orders, users can inform about any faults discovered or advised by a customer during their visit execution.

2	New breakdown notification orders are downloaded and completed if necessary	Mobile users download the assigned notification orders and can use them if necessary during each customer visit.

3	New breakdown notification orders are uploaded to the backend	The survey replies are automatically uploaded to the backend in the next synchronisation. This enables maintenance workers to have a real time breakdown status .

2 Technical Features

	Feature Description
It runs on any mobile device	The Movilizer Client is a very small piece of software (some few Kilobytes) written in different native languages (depending on the target device) capable of running in offline / on nearly any mobile phone, smart phone, PDA, Tablet PC, Netbook or Notebook. Please refer to http://www.movilizer.com/Supported_Devices/ for a complete list of supported devices. The deployment of the Movilizer Client is done via SMS or simple file transfer and is as easy as downloading a ringtone (average set up time is seconds). The Movilizer client works online—offline. This means that you do not need connectivity to be able to work with it. The synchronisation can be triggered automatically in background, explicitly by the mobile User or based on a process step.
Comprehensive configuration possibilities, marginal programming	The Movilizer for SAP DSD allows you to configure the mobile application and all its functionalities for different Users and User groups. The configuration of the mobile application is done in the SPRO transaction of your SAP ERP system using the standard customising mode for Movilizer.
It does not need additional hardware	The Movilizer for SAP DSD allows you to configure the mobile application and all its functionalities for different Users and User groups. The configuration of the mobile application is done in the SPRO transaction of your SAP ERP system using the standard customising mode for Movilizer.
Supports barcode scanning and RFID	BARCODE Scanning The Movilizer supports barcode scanning in any standard format (2D Datamatrix or lineal barcodes), provided the mobile device has a built-in barcode scanner. Should your mobile device not have a built-in barcode scanner but an autofocus camera, the Movilizer offers the option to use the mobile phone camera as a barcode scanner. In this way any standard mobile phone can become a barcode scanner. (Supported Devices via mobile phone camera: any Nokia series 60s, with exception of the Nokia E90, any BlackBerry device. On request any device can be supported. RFID Reading / Writing The Movilizer supports reading RFID data and writing data to RFID tags in any frequency (NFS, LF, HF or UHF), provided the mobile device has a built-in RFID reader. Should your mobile device not have a built-in RFID reader, the Movilizer offers the option to use the mobile device Bluetooth to connect to external RFID readers. Companies like Microsensys supply low cost Bluetooth enabled RFID readers for different frequencies and in different formats. In this way any standard mobile phone or PDA can become an RFID enabled device.
GPS geo-coordinates	GPS capturing during Order / Notification Execution The Movilizer allows you to link any process (Notification Creation, Work Order Execution) with the background capturing of GPS coordinates. In this way you can always know who created or processed what (Movilizer User), where (Geo-coordinate) and when (Timestamp is automatically captured in background as well).For this feature a GPS or A-GPS enabled mobile device is required. Automatic vehicle / device tracking via GPS You can also configure the Movilizer to do automatic Vehicle / Device Tracking. In this modus, the Technician's mobile phone automatically sends GPS geo-coordinates every X minutes (time interval configurable), so that the Dispatcher is able to follow the Technicians route during the day.
Multimedia files (download / upload)	Taking Pictures (upload) Since the Movilizer release V1.7, you are able to use your mobile device camera to take pictures of any type (e.g. broken equipment) and to link them to any business processes (e.g. linking pictures to the Notification or to the Work Order itself). Downloading pictures (e.g. technical drawings) Since the Movilizer release V1.7, you are able to download to the mobile device any pictures related to the Notifications or Work Orders. Recording and downloading videos and voice files The Movilizer does not support this feature today; however it is in our roadmap for Q4 2011 (release V1.9).
Printing (download / upload)	The Movilizer offers the option to use the mobile device Bluetooth in order to print barcode labels, maintenance / service reports, and any kind of print outs. In general, any Zebra mobile printer is supported. Other mobile printer models can be supported on request.
Capturing Digital Signature	Since the Movilizer release V1.7, you are able to use touch screen mobile devices in order to capture digital signatures.

3 Key Differentiators

Key Diferrentiator	Feature Description
It is simple and very low cost: so that it can even be deployed to external employees.		The Movilizer is the lowest cost option to "movilize" SAP DSD in the market today. Because it is low cost and "usage based" licensing is possible, you are even able to deploy the Movilizer to external employees or final customers. With the Movilizer, you can even think about creating a new communication channel with your end customers. For example, allowing them to use their mobile phones for self service purposes, rather than having to call the service helpdesk. End customers could use the Movilizer to report new orders (sales order creation).
	It runs on any simple mobile phone	A mobile application for DSD should work offline / online and should offer flexibility in the mobile device selection. It should support various different models of ruggedized PDAs but also normal mobile phones. The Movilizer Client is a very small piece of software (some few Kilobytes) written in different native languages (depending on the target device) capable of running in offline / on nearly any mobile phone, smart phone, PDA, Tablet PC, Netbook or Notebook. Please refer to http://www.movilizer.com/Supported_Devices/ for a complete list of supported devices.
	It is deployed in seconds (device setup can be done by the end user)	The Movilizer Client can be installed in less than 1 minute on any mobile device (PDA or mobile phone) it does not require any special technical skills. This will make it possible for any "super User" to be able to set up a device without any intervention from the helpdesk support. The deployment of the Movilizer client for mobile phones is triggered by a technical SMS. Average set up time: between 30 and 60 seconds, mainly depending on the bandwidth of the wireless connection. Technically, the deployment of the Movilizer client for devices not having GSM/GPRS/3G capabilities (e.g. PDAs, TabletPCs or Laptops) is triggered via transmission of an installable file (.cab, .jar etc.) to the device via any channels that allows a simple file transfer (e-mail, ftp, Bluetooth, active sync etc.). Once on the device a double click automatically installs the Movilizer without any User interaction. Average set up time: around 30 seconds or less.
	It does not require any end User training	The Movilizer has been designed to be used not only by internal employees but also by externals (third parties, temporary staff or even the final Customer); in these scenarios training and change management are just not feasible. The application itself needs to be self explanatory. For this reason, the Movilizer is 100% process driven, and not information driven. The Movilizer works like a wizard. This means that the process is built in a sequence of screens. All the User needs to do is to read the information on the screen, eventually to capture data if relevant and to confirm with "OK" or to go back with "BACK". The User never has to decide between more than two options "BACK" or "OK".
	It takes weeks to implement and you can do it yourself	Most importantly: should the standard Movilizer for SAP DSD template not meet 100% of your requirements, you can change or enhance it yourself. The entire mobile app is built in ABAP/4. The Movilizer does not require any client or middleware development. The mobile app business logic is 100% under your control in your SAP system. After 5 days Movilizer training, even a Junior ABAP developer can enhance any Movilizer template or even build completely new apps.
	No Upfront Licenses	You can use the Movilizer without purchasing any upfront licenses.
	Monthly support fees (SaaS)	In order to use the Movilizer all you pay is a monthly support fee for each live User (The monthly fee depends on the number of Users and scenario, but the range is normally between 15€ and 30€ per User per month). Third level support is included in the mentioned fee. First and Second level support can be purchased separately if wished (although this is typically something your IT department can do itself. The Movilizer also offers the possibility to pay per executed transaction (rather than per User/month). This option is especially interesting if the purpose is to give your final Customer access to the Movilizer (E.g. they can create malfunction Notifications whenever an asset is not working rather than calling the service helpdesk). In this scenario the transaction based payment will probably be more competitive.
	You are 100% in control of future changes and enhancements in the app.	Since the entire business logic is in the backend, you are free to change the application whenever you require it. To add new fields, remove or add screens or change the flow of the mobile application you do not need any help from Movilitas. You can do it on your own with your own IT resources (all you need is ABAP/4 skills) without having to contact Movilitas any time you need changes in the mobile application.
The most flexible mobile app		The Movilizer is the most flexible mobile app for SAP DSD in the market today.
	It is device agnostic	A mobile application for DSD should work offline / online and should offer flexibility in the mobile device selection. It should support various different models of ruggedized PDAs but also normal mobile phones. The Movilizer Client is a very small piece of software (some few Kilobytes) written in different native languages (depending on the target device) capable of running in offline / on nearly any mobile phone, smart phone, PDA, Tablet PC, Netbook or Notebook. Please refer to http://www.movilizer.com/Supported_Devices/ for a complete list of supported devices. The deployment of the Movilizer Client is done via SMS or simple file transfer and is exactly as easy as downloading a ringtone (average set up time is seconds). The Movilizer client works online—offline. This means that you don't need connectivity to be able to work with it. The synchronization can be triggered automatically in background, explicitly by the mobile user or based on a process step. The Movilizer leaves you full flexibility in the device choice and in the type of synchronisation mechanism. And this is mainly because the Movilizer is device agnostic and supports multiple synchronisation mechanisms: LAN, Wi-Fi, GPRS / 3G, ActiveSync etc.
	Configuration instead of development (Movilizer customising in SPRO)	The Movilizer for SAP DSD has a set of customising features in SAP ERP transaction "SPRO", which allows you to adapt the template processes to your requirements with marginal developments (if any): Movilizer for SAP DSD is object oriented. We deliver a set of business processes, which you can adapt to the Technician roles within his enterprise. Each business process comprises a set of pre-delivered Business Steps. Each Business Step has its own customising. The Movilizer for SAP DSD also allows you to customise screen elements purely in SAP ERP (e.g. the menu items, its sequence, the corresponding screen icons, any of the labels displayed in the screens). No development on the mobile device is required. The Movilizer for SAP DSD allows you to adapt each process to the flow required for a dedicated role in the enterprise. E.g. an Inspection Technician has a different screen flow than a Maintenance Technician for planned maintenance.
	It allows changing processes on the fly	The Movilizer gives you the agility and flexibility to adapt to any changing requirements. You can add, delete or change any field or screen without any interruption to operations. The final Movilizer Users will not even realise it. The Movilizer combines the advantages of pure online applications (centralised software logistics, instantaneous deployment etc.) with the charm of offline applications.
	You can create "mash-ups" (interfacing SAP with non-SAP) on the mobile device	With the Movilizer you build your app like Lego. Our highly granular building blocks are called "Movelets" and allow you to interface any SAP Module (PM, MM etc.) and any non SAP application on the mobile device. For the mobile User, a single app. For your IT team, simple standardised Lego pieces easy to support and to further develop. A mash up example in the screenshot above. A Microsoft Excel worksheet containing a simple survey can be embedded in the application flow of the normal execution of e.g. SAP orders. The completed survey is transferred from Movilizer back to the Microsoft Excel workbook. For the User, one single application. Technically two totally different apps: The SAP DSD app containing the Work Order and the Microsoft Excel app containing the simple survey.
	Development only in backend (e.g. ABAP/4)	Since the entire business logic is 100% in the backend, you are free to change or enhance the application whenever you require it. To add new fields, remove or add screens or change the flow of the mobile application you don´t need any help from Movilitas. You can do it on your own with your own IT resources (all you need is ABAP/4 skills) without having to contact Movilitas any time you need changes in the mobile application. This guarantees your total independency from Movilitas.

The Movilizer for SAP DSD
Technology & Architectural Components

1 The Movilizer SAP Connector
(for SAP DSD)

The Movilizer SAP Connector uses the web service functionality of SAP. With SAP Basis Rel 7.0 SP14, the SAP web service functionality has been improved and the Movilizer SAP Connector package relies on these adjustments. The required minimum level to implement the delivered package containing the web service proxy is therefore NetWeaver 7.0 with SP 14 or later. Should your backend system not fulfill this requirement, the Movilizer SAP Connector components can be deployed in a distributed manner (one NetWeaver 7.0 system in your landscape is enough to enable the Movilizer to connect to any of your SAP older systems).

Besides this, no specific SAP ERP (DSD Modules) releases are required.

2 The Movilizer Cloud

It is a secured multitenant and hosted middleware with 99.9% guaranteed availability that can connect your SAP DSD system with any mobile device by sending and receiving encrypted business data in both directions. For an IT responsible, the Movilizer Cloud means that you do not need to purchase or install any additional infrastructure (no middleware). For its use in ultra sensitive areas (e.g. maintenance in nuclear plants or in military equipments) the Movilizer supports "End to End encryption" based on military standard encryption algorithms AES or RC4 (from Movilizer version 1.7 onwards). The following components are accessible via secured connection through the Internet:

Monitoring / Admin Portal: You only use the Monitoring/Admin-Portal via the Internet to do technical monitoring of all your mobile Users. Normally you only use this Portal by exception (for trouble shooting purposes); most of the Movilizer Customers barely use it . The access to the Portal is protected via SSL, User/password and if requested also via fixed IP addresses.

Web Service: You use the Web Service to connect the Movilizer to any backend system you may use. The Web Service includes APIs for: Sending and assigning data to your mobile Users / Receiving captured data from the mobile Users / Monitoring and administrating the mobile landscape (e.g. creating Users etc.). The access to the WebService is protected via SSL, User/password and if requested also via fixed IP addresses.

3 The Movilizer Client

It is very small software (some few Kilobytes) written in different native languages (depending on the target device) capable of running on nearly any mobile phone, smart phone, PDA, Tablet PC, Netbook or Notebook. Please refer to http://www.movilizer.com/Supported_Devices/ for a complete list of supported devices.

The Movilizer client works online—offline. This means that you don't need connectivity to be able to work with it. The synchronisation can be triggered automatically in background, explicitly by the mobile User or based on a process step. The Movilizer uses the native User interface of your mobile phone or PDA.

The deployment of the Movilizer Client is done via SMS and is as easy as downloading a ringtone (average set up time is seconds). The Movilizer client works online—offline. This means that you do not need connectivity to be able to work with it. The synchronisation can be triggered automatically in background, explicitly by the mobile User or based on a process step.

Movilizer for SAP DSD (mDSD) – A Mobile App for SAP DSDfor any participant involved in your supply chain

Introduction Movilizer for SAP DSD:Executive Summary

1 Functional Features

2 Technical Features

3 Unique features

Movilizer for SAP DSD - a different approach to mobile DSD

Title

Function

Delivery driver scenario

Full service vending scenario

Pre-seller scenario

Van seller scenario

Mixed scenarios

Side scenarios

1. Route preparation

1

Deliveries are created in SAP

2

Deliveries are grouped in shipments

3

Shipment is assigned to a mobile driver

2. Start of day & Check-Out

1

The driver receives the shipment in his mobile device

2

The driver performs the start of day activities

3

The driver does the material check-out

4

The driver does the money check-out

3. Route execution

1

The driver starts the visit execution

2

The driver performs delivery

3

The invoicing (online, offline) is calculated

4

The driver generates the printout (invoice, POD)

5

The driver does a money collection (old and current open items management)

6

The driver adds or cancels a planned visit

7

The driver checks the inventory status

8

The driver introduces disruption times

9

The driver adds travel expenses

10

The driver performs the end of day process

4. Check-In & Settlement

1

The driver does the material check-in

2

The driver does the payment check-in

3

The RADB tables are actualised

4

Settlement process is finalised at the backend

5. Others

1

Route monitoring (inventory tracking, post assignments, GPS route tracking, delay tracking) from the backend

2

New visit creation from the backend

1. Route preparation

1

Replenishment visits are created in SAP

2

Replenishment visits are grouped in shipments

3

Shipment is assigned to a mobile driver

2. Start of day & Check-Out

1

The driver receives the shipment in his mobile device

2

The driver performs the start of day activities

3

The driver does the material check-out

4

Movilizer for SAP DSD
(mDSD) – A Mobile App for SAP DSD
for any participant involved in your supply chain

Introduction Movilizer for SAP DSD:
Executive Summary