REQ 309371 Lanemark eSERV Requirements
Lanemark International
Lanemark eSERV Requirements
CALIDUS eSERV
7th June 2013 - 0.1
Reference: REQ 309187
Contents
Introduction
This document is the Lanemark eSERV Requirements.
Objective
The primary purpose of this document is to document the requirements gathered from Lanemark International during the sales process, and to present an overview of the process that will be followed in and the work required to the CALIDUS eSERV system.
This document has been written in a manner such that it can be approved by non-technical representatives of Lanemark International whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.
Scope and Limitations
This document is based on the documentation provided by the OBS Logistics Sales team.
- This document reflects the work that will be required to the CALIDUS eSERV system - no provision is made here to any changes required regarding interfacing to and from the NAV system being used. Additional development may be required and should be specified separately.
- The changes will be made in the latest version of the CALIDUS eSERV system.
- The changes have been specified with the Android PDA client in mind.
Client Requirements
Overview
- Services Module.
- Multiple Product Types, requiring different forms.
- NAV back-end.
Further Requirements:
- Must have multiple service records per service job i.e. multiple items to check.
- Pre-checks are the same and must be completed for all before continuing.
- Cancellation of a Service is allowed, requiring signatures.
- Filter Products based on user-entered Group.
Service PDA Process
All jobs will be assigned to an engineer, providing a Worklist or Load.
When an engineer logs on to a device (using their provided username, password and vehicle), the assigned worklist will be downloaded onto the device, showing all the jobs in sequence on a Job List.
Selecting a job from the Job List will show the user the job report and customer contact details, allowing the user to contact the customer (through text or phone), or navigate to the customer's address.
The engineer can then choose to start the job, and when they arrive at the site, can being entering the details.
Note: All process up to and including the engineer starting and arriving at the job are generic and described in detail in the user guides, as referenced in the appendices.
The PDA will display the following tabs in order to process the service:
- Job Details
- Info
- Products
- Diagnosis
Job Details
This tab displays contact information and a summary of the instructions for the whole job (not the service items).
A Cancel button will be added to the bottom of this screen. If for any reason the user wishes to cancel the service, they can click this button. This will prompt the user to enter the reason why the services are being cancelled (through a Picker) - these reasons are fully configurable, and is expected to contain a reason (Risk Assessment Failure). If cancelled this way, the user will be prompted to obtain a signature of the customer and for themselves.
Info
Info will show (in section 3):
- Make
- Model
- S/No
All may potentially be pre-populated by the office staff, so proper fields against the Service.
The screen also would have navigation buttons left and right of the title (sections 1 and 2), to allow the user to switch between servicable items. A label showing the record being processed (e.g. "1 or 6") would be shown, allowing the user to see how many there are. Switching between the servicable items will change the displayed data on each of the tabs to the next service record. The same affect can be made by swiping left or right on the title label.
A Prework button will be shown in section 4 (for Risk Assessment) - this pops up the pre-work checks pop-up form:
All contents would be configured, entered like Vehicle Checks, through a scrolling frame. Save and Back buttons would be provided.
Warning: Some confirmation as to whether these checks have passed will be required from the user.
When complete and saved, user will be prompted, the Prework button would be updated to show the status (Complete).
Note: These configurable Prework Checks are not searchable, exportable or reportable, but can be displayable in the Admin client or on the Service Report.
Initially, the user will not be able to select any tab except Job Details and Info. Only when all prework checks are complete will the user be able to select any other tabs.
Products
Products will be modified to show the Product Group selection above the Product selection, if configured.
If so, the user selects a product group, then the product list will be filtered to show only products that belong to this group. If none is selected, all products will be shown.
Diagnosis
The Diagnosis tab is used for entry of Report of Visit.
Additional check-boxes will be added for "Revisit", "Follow Up" and "Burner safe for use". These will be prompted for if configured this way from the Admin system.
If Test Results are required, a Post-work Checks button will appear here. This shows a post-work checks pop-up to enter the details, which are configurable ( Warning: different for each product group? What is Product Group used for?), entered like Vehicle Checks, through a scrolling frame.
Note: These configurable Post-Work Checks are not searchable, exportable or reportable, but can be displayable in the Admin client or on the Service Report.
When the user clicks the Done button, once all information entered (validated) on all the tabs, the engineer will be prompted for signature, as will the customer. These signatures would only be prompted once, and used on both the first and second pages of the Service report.
Service Report
At this time, OBS have only one format of the report, and this is old. The customer is taking the opportunity to redesign reports, being more suited (and specific) to the products being serviced. As such, there is now 1 risk assessment form, and 3 Service Report formats.
These formats are not based on configuration against the Job Group (other than to choose Lanemark's format) - they are based on the serviceable product type, which should be entered against the service records.
Once risk assessment form and one service report will be printed per service record on the job, the format of the pages being based on the Product Group or Model ( Warning: unknown yet what will be mapped where).
Note: At this stage, no mapping of data has been done internally to map NAV elements to data on EPOD, or on these layouts.
Page 1:
- Customer name and site address - from the Job
- Customer Order No - Any one of our existing references
- Service Job number - Job code or Service ID.
- Plant details:
- Make
- Model
- S/No: Possibly new information fields, or reuse of existing ones. Not a big issue.
- Report of Visit: Diagnosis. Both would need seriously expanding to cope with the amount of data. I imagine we would have to take this on the chin, as we currently restrict down to 100 characters.
- Test Results: Built from Post-work checks.
- Part No/Material Used/Qty: From Products used
- Date of the visit start and finish: As per our normal Arrival Date/Time, End Actual Date/Time.
• Is system safe for use: New Flags
- Customer and Engineer print and sign: As normal.
Page 2:
ENGINEER SITE RISK ASSESSMENT
The information on this report will be taken directly from the data entered by the user. It will not be manipulated in any other way than to format it for the report. Note that this means that, if the items are not present in the configuration for the report, this could break the layout of the report and make reports not work. This will affect only jobs completed after the configuration is changed.
The signatures on this screen will be taken from the standard Job signatures. If the Risk Assessment passes, only the Engineer signature iwll be populated.
Appendix A: Table of SCRs
SCR# | System | Area | Description | Estimate (Days) | Notes |
1 | eSERV | PDA Client | Significant UDF field modifications | N/A | |
2 | eSERV | PDA Client | Multiple Servicable Items Per Service Job | N/A | |
3 | eSERV | PDA Client | New Info tab fields required | N/A | |
4 | eSERV | PDA Client | Configurable Pre-work Checks (for Risk Assessment) | N/A | |
5 | eSERV | PDA Client | Complete Prework checks before any other data entry | N/A | |
6 | eSERV | PDA Client | User-filterable Products based on Group/Model | N/A | |
7 | eSERV | PDA Client | Configurable Postwork Checks (for Test Results) | N/A | |
8 | eSERV | PDA Client | Display Status of Prework and Postwork checks on form | N/A | |
9 | eSERV | PDA Client | Diagnosis to be modified for additional check fields | N/A | |
10 | eSERV | PDA Client | Diagnosis narrative t become unrestricted field | N/A | |
11 | eSERV | PDA Client | Allow Cancellation of Service Job | N/A |
Notes:
- All ballpark costs in this document are provided as-is, are legally non-binding and subject to raising a formal change request with OBS Logistics.
Appendix B: Document References
B.1 References
Ref No | Document Title & ID | Version | Date |
1 | UG 291094 EPOD Admin User Guide | 2.0 | 4/4/2012 |
2 | UG 291097 EPOD Client User Guide | 3.0 | 23/4/2013 |
B.2 Glossary
Term | Definition |
---|---|
EPOD | Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD. |
CALIDUS eSERV | The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system. |
PDA | The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android. |
DAL | Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it. |
GPS | Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device. |
GPRS, 3G, HSDPA, Data Service | All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet. |
B.3 Authorised By
Jamie Foster | OBS Project Manager | _____________________________ |