Presentation is loading. Please wait.

Presentation is loading. Please wait.

Field Force Management Integration Interface Overview FFM TC Webinar: November 13, 2012 FFM TC chair: Thinh Nguyenphu Presenters: Israel Beniaminy (ClickSoftware.

Similar presentations


Presentation on theme: "Field Force Management Integration Interface Overview FFM TC Webinar: November 13, 2012 FFM TC chair: Thinh Nguyenphu Presenters: Israel Beniaminy (ClickSoftware."— Presentation transcript:

1 Field Force Management Integration Interface Overview FFM TC Webinar: November 13, 2012 FFM TC chair: Thinh Nguyenphu Presenters: Israel Beniaminy (ClickSoftware Technologies) Johannes Lehtinen (Rossum) Thinh Nguyenphu (NSN) Juha Tiihonen (Aalto University Foundation) www.oasis-open.org

2 FFMII overview Non-standard track: Field Force Management Integration Interface Requirements Version 1.0 l business drivers l business use cases, and l high level features requirements Standard track: 1) Field Force Management Integration Interface Specifications Version 1.0 2) FFMII Protocol Binding: SOAP over HTTP (Web Service) l WSDL description of the FFMII for Implementation and Manager interfaces l XML Schema type definitions for the associated XML namespaces 2 FFMII Specifications: structure & main contents

3 Field Force Management Integration Interface 3 FFMII provides a flexible interface between ERMS and FFMS for the purpose of work request modeling, exchange, and collection of data from the field. Information carried with work requests, work request structure (work-flow) and data to be collected can all be defined dynamically as data. This data driven architecture makes FFMII very flexible and adaptable to numerous industries

4 Design Goals & Characteristics n Applicability across domains and use cases n Technical scalability n Feature scalability n Expression accuracy and user guidance n Reliable message exchange n Deployment adaptability and technology neutrality

5 Example Use Case: Field Service installation & maintenance n Installation company receives installation jobs from several telecom operators n Work Request structure and reporting requirements vary l Order details, instructions, process flow, products and parts l Resolution codes, on-site sales and exception reporting n Single job may involve several locations l distribution points, cross-connections, end-user premises n Single installation may be split to several assignees n Information sharing among Field Force n Field-Initiated Requests l find available work, reserve job to me, initiate new job 5

6 Example: Data Content and Structure 6 Work Request Data Forms Overview Type: ADSL Installation Target Time: 07/31/12 12:34 Subscriber Name: John Smith Address: 32 Conection Street, Somecity Phone: 555-0199-777 Products ProductQuantity Copper Connect 1 ADSL Installation 1 Instructions Connection ID: CI333256523 Bandwidth: 12/4 Mbps Connection Point A: 1234.13.324.1 Connection Point B: 1553.123.23.6 Route: BSC13650/0 ADSLFR ADSL72_AD_03-7 SOC 0/100 PVC VLAN_12_VLAN SOC/00101/1 - K32/2/51 SOC/27/1 - V68/1/9 C … Network Map: NMSomeCity72.PDF Header YourComm Installation 012344 32 Connection Street, Somecity

7 Example: Activities and Work Flow 7 Work Request Activities Install Assignee: Dorothy Hayes Location: 32 Connection Street Appointment: 10:00 – 12:00 Connect Assignee: John Williams Location: 17 Apple Street Begin at: 7/31/12 08:00 NewOngoingCompleted Suspended StartReady SuspendResume NewOngoingCompleted StartReady Dependent on state Suspended Input Form on Ready Device Class: [Enumerated code] Resolution: [Enumerated code] SLA Breach [Enabled if current time past SLA target] Breach Reason: [Enumerated code] Explanation: [String, non-empty] Input Form on Ready Device Class: [Enumerated code] Resolution: [Enumerated code] SLA Breach [Enabled if current time past SLA target] Breach Reason: [Enumerated code] Explanation: [String, non-empty]

8 Highlighted Features n Multi-tenancy n Data-centric design n Work Request Management l Dynamically specified data content and structure l Multiple Activities with dynamic work flow and dependencies n Field-Initiated Requests l Dynamically specified operations and data content n Reference Data Management l Unified interface for managing reference information l Field Force, Work Types, Field-Initiated Request operations, shared Work Request data (code sets, attachments, etc) 8

9 Flexible integration topologies n Simple topology: a single Manager and a single Implementation interacting n Distributed work realization: A single Manager interacting with several Implementations for communicating with distinct groups of field personnel n Shared Field Force: multiple Managers interacting with a single Implementation n Multi-Paradigm: multiple Managers interacting with a single Implementation 9 Manager Implementation Manager Multi-paradigm integration topology (example) Implementation Shared field force Distributed work realization

10 Domain Model (main topics of FFMII ) Work Type Specification FFMII Domain Model Work Request Status Record Work Request Reference Data Assignee Schedule Field Initiated Request Task Activity Step State Data Form Dependency Action Topical Notification Topical Inquiry Work Request Status Change Notification

11 Relationship of Steps, Actions and States within an Activity 11 A combination of States, Steps and Actions form an Activity State Model. FFMII interface does not prescribe or imply usage of any specific Activity State Model in order to remain neutral with respect to types of Task a Work Request may represent. In this example, the OnSite state requires the Assignee to decide whether the Task may be fulfilled by repairing the customer's equipment, or whether it is necessary to replace the equipment with a new unit. Therefore there are two possible actions leading from Step 2, and both of them are enabled so that the Assignee may select either of them (enabling conditions aren't visualized in this diagram). If the Assignee chooses the Replace action, the action leads to Step 4. In this example, replacement requires approval, so the dashed action transfers the task to an Inactive state, pushing the current State into the State Stack. At that point, the other action leading from Step 4 is not enabled, due to an enabling condition which depends on receiving the approval. Once the approval arrives, the next action pops the State Stack to return to the OnSite state. Note: a more complete scenario would probably also include action that should lead from Step 5, for handling the case when approval is not granted, possibly leading to another State in the Closed category which reflects cancellation of the Work Request. Action: Transition to OnSite Action: Transition to X-Finalize Action: Transition to X-Finalize Action: Transition to Completed Action: Repair Action: Replace

12 Use Case: Asset Management n Some work performed by crews, with each crew member having both individual tasks and crew tasks n Job safety processes includes strict ordering of steps (for example, entering work area only after verifying power has been shut down) n While workers are on site, they may notice the need to perform additional work, and initiate the creation of a new work order n Emergencies (such as gas leaks) may require workers to suspend work on one work order and immediately begin the urgent new work order n Work regulations often require documenting each step, including signatures, serial numbers of parts used, measurements and more 12

13 Use Cases: Data Collection n Identify used spare parts n Scan barcode or enter serial number of installed device n Collect failure and maintenance details n Collect measurements, e.g. in maintenance inspections n Data Forms & Data Fields, flexible data types n Require relevant data - Enable & Updateable Conditions n Ensure valid input - Validation Conditions n Data Matrix elements enable tabular input n Hierarchical selection trees enable fluent selection from a large number of alternatives 13

14 References n Field Force Management Integration Interface Requirements Version 1.0; l http://docs.oasis-open.org/ffm/FFMII-REQ/v1.0/cn01/FFMII-REQ- v1.0-cn01.pdf http://docs.oasis-open.org/ffm/FFMII-REQ/v1.0/cn01/FFMII-REQ- v1.0-cn01.pdf n Field Force Management Integration Interface Specification Version 1.0; l http://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPEC- v1.0-cs01.pdf http://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPEC- v1.0-cs01.pdf n Complete specification package: l http://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPEC- v1.0-cs01.zip http://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPEC- v1.0-cs01.zip 14

15 List of contributors n Israel Beniaminy, ClickSoftware Technologies Ltd. n Jiri Hlusi, Nokia Siemens Networks GmbH & Co. KG n Johannes Lehtinen, Rossum Oy n Thinh Nguyenphu, Nokia Siemens Networks GmbH & Co. KG n Ilkka Salminen, Newelo Oy n Jose Siles, Nokia Siemens Networks GmbH & Co. KG n Juha Tiihonen, Aalto University Foundation n Sami Vaskuu, Newelo Oy n Liat Zahavi-Barzily, ClickSoftware Technologies Ltd 15

16 THANK YOU

17 BACKUP (TECHNICAL) 17

18 Domain Model (Work Request) Work Type Specification FFMII Domain Model Work Request Status Record Work Request Reference Data Assignee Schedule Field Initiated Request Task Activity Step State Data Form Dependency Action Topical Notification Topical Inquiry Work Request Status Change Notification

19 Work Request 19 Manager produces series of self-contained Work Requests representing Tasks related to Field Works. Each Task is to be performed by one or more Assignees belonging to the addressable Field Force. A Manager communicates with one or more Implementations over the FFMII interface to make the planned Tasks accessible to corresponding Assignees.

20 Domain Model (Work Type Specification) Work Type Specification FFMII Domain Model Work Request Status Record Work Request Reference Data Assignee Schedule Field Initiated Request Task Activity Step State Data Form Dependency Action Topical Notification Topical Inquiry Work Request Status Change Notification

21 Work type Specification structure 21 A Work Type Specification (WTS) describes content and structure of a Work Request

22 Example: Activity State Model with Dependencies 22 Activities MAY have dependencies on other Activities being in specific States. Activity-Enabling dependencies and Action-Enabling dependencies are specified as Boolean expressions referred to as Conditions. Activity 1 is not made available to the Assignee until Activity 3 is in Completed State. Additionally, while at the New Step, Activity 1 wont be allowed to proceed towards the next Step, Traveling to Site, unless Activity 2 is at any Step associated with the State Ongoing.

23 Domain Model (Data Form) Work Type Specification FFMII Domain Model Work Request Status Record Work Request Reference Data Assignee Schedule Field Initiated Request Task Activity Step State Data Form Dependency Action Topical Notification Topical Inquiry Work Request Status Change Notification

24 Data forms 24 Data Forms are used to model dynamically specified structured information. Data Forms are used, for example, for the purpose of defining Work Request header, overview and instructions, Step level instructions and user input.

25 Data Element Specification n Data Element Specification is an abstraction that supports a common set of attributes for all sub-classes of Data Element Specifications 25

26 Data Element Types n Simple data field: Data Field Specification n Matrix of Data: Data Matrix Specification n Attachments: Data Attachment Specification n Grouping of possibly nested Data Elements: Data Group Specification 26

27 Domain Model (Work Request Status Record) Work Type Specification FFMII Domain Model Work Request Status Record Work Request Reference Data Assignee Schedule Field Initiated Request Task Activity Step State Data Form Dependency Action Topical Notification Topical Inquiry Work Request Status Change Notification

28 Work Request Status Record 28 Work Request Status Record reflects state changes of Work Request after it has been received by the Implementation. An Implementation MUST maintain one Work Request Status Record per each Work Request

29 Domain Model (Reference Data) Work Type Specification FFMII Domain Model Work Request Status Record Work Request Reference Data Assignee Schedule Field Initiated Request Task Activity Step State Data Form Dependency Action Topical Notification Topical Inquiry Work Request Status Change Notification

30 Reference Data 30 An Implementation MAY provide means for the Manager to establish custom data repositories with arbitrary content Reference Data that MAY be used for input value selection, lookup of display values or content validation in Work Requests. An Implementation MAY also provide access to system repositories providing access to selected data on Implementation side, such as Assignee identities and alike.

31 Domain Model (Field Initiated Request) Work Type Specification FFMII Domain Model Work Request Status Record Work Request Reference Data Assignee Schedule Field Initiated Request Task Activity Step State Data Form Dependency Action Topical Notification Topical Inquiry Work Request Status Change Notification

32 Field-Initiated Request 32 Field-Initiated Request (FIR) is a request initiated by an Assignee and dispatched as a structured message from Implementation to Manager. It is intended for making requests or reporting information outside the usual Activity work flow, such as requesting activation or reset of a specific device, reporting absence of the Assignee, or requesting additional work for the Assignee.


Download ppt "Field Force Management Integration Interface Overview FFM TC Webinar: November 13, 2012 FFM TC chair: Thinh Nguyenphu Presenters: Israel Beniaminy (ClickSoftware."

Similar presentations


Ads by Google