Date post: | 29-Mar-2015 |
Category: |
Documents |
Upload: | piper-bebb |
View: | 224 times |
Download: | 2 times |
Field Force Management Integration Interface Overview
FFM TC Webinar: November 13, 2012FFM TC chair: Thinh Nguyenphu
Presenters: Israel Beniaminy (ClickSoftware Technologies)
Johannes Lehtinen (Rossum)
Thinh Nguyenphu (NSN)
Juha Tiihonen (Aalto University Foundation)
www.oasis-open.org
FFMII overviewNon-standard track:
Field Force Management Integration
Interface
Requirements Version 1.0 business drivers business use cases, and 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)
WSDL description of the FFMII for Implementation and Manager interfaces
XML Schema type definitions for the associated XML namespaces
2
FFMII Specifications: structure & main contents
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
. . .
FFMII
Enterprise Resources Management
Operational Analytics & Reporting
Supervision Scheduling
Field-Force Management User Profile Mgmt
Field Communication Terminal Mgmt
Field-Force
Material Information
Partner Data
People Data
Higher-order system (optional)
Customer Data
. . .
Map Services
BI
Site Knowledge Database
Design Goals & Characteristics Applicability across domains and use cases Technical scalability Feature scalability Expression accuracy and user guidance Reliable message exchange Deployment adaptability and technology
neutrality
Example Use Case: Field Service installation & maintenance Installation company receives installation jobs from several
telecom operators Work Request structure and reporting requirements vary
Order details, instructions, process flow, products and parts Resolution codes, on-site sales and exception reporting
Single job may involve several locations distribution points, cross-connections, end-user premises
Single installation may be split to several assignees Information sharing among Field Force Field-Initiated Requests
find available work, reserve job to me, initiate new job
5
Example: Data Content and Structure
6
Work Request Data Forms
Overview
Type: ADSL InstallationTarget Time: 07/31/12 12:34
Subscriber Name: John Smith Address: 32 Conection Street, Somecity Phone: 555-0199-777
Products Product Quantity Copper Connect 1 ADSL Installation 1
Instructions
Connection ID: CI333256523Bandwidth: 12/4 MbpsConnection Point A: 1234.13.324.1Connection 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
HeaderYourComm Installation 01234432 Connection Street, Somecity
Example: Activities and Work Flow
7
Work Request Activities
InstallAssignee: Dorothy HayesLocation: 32 Connection StreetAppointment: 10:00 – 12:00
ConnectAssignee: John WilliamsLocation: 17 Apple StreetBegin at: 7/31/12 08:00
New Ongoing Completed
Suspended
Start Ready
Suspend Resume
New Ongoing CompletedStart Ready
Dependent on state
Suspended
Input Form on ReadyDevice Class: [Enumerated code]Resolution: [Enumerated code]SLA Breach [Enabled if current time past SLA target] Breach Reason: [Enumerated code] Explanation: [String, non-empty]
Highlighted Features Multi-tenancy Data-centric design Work Request Management
Dynamically specified data content and structure Multiple Activities with dynamic work flow and dependencies
Field-Initiated Requests Dynamically specified operations and data content
Reference Data Management Unified interface for managing reference information Field Force, Work Types, Field-Initiated Request operations,
shared Work Request data (code sets, attachments, etc)
8
Flexible integration topologies Simple topology: a single Manager and a single Implementation interacting Distributed work realization: A single Manager interacting with several Implementations
for communicating with distinct groups of field personnel Shared Field Force: multiple Managers interacting with a single Implementation Multi-Paradigm: multiple Managers interacting with a single Implementation
9
Manager
Implementation
Manager
Multi-paradigm integration topology (example)
ImplementationImplementation
Shared field force
Distributedwork
realization
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
StateData Form
Dependency
Action
Topical Notification
Topical Inquiry
Work Request Status Change Notification
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.
1
Step 1
Step 2
Step 3 Step 4 Step 5
Step 6
Step 7
State: State A Status Category: <<Open>> Status Indicator: Dispatched
State B <<Active>> OnSite
Action: {push} Obtain-approval
State C <<Inactive>> X-Obtain-approval
Action: {pop} Resume
State E <<Closed>> Completed
Action: Transition to OnSite
Action:Transition toX-Finalize
Action:Transition toX-Finalize
Action: Transition to Completed
Action:Repair
Action:Replace
Use Case: Asset Management Some work performed by crews, with each crew member
having both individual tasks and crew tasks Job safety processes includes strict ordering of steps (for
example, entering work area only after verifying power has been shut down)
While workers are on site, they may notice the need to perform additional work, and initiate the creation of a new work order
Emergencies (such as gas leaks) may require workers to suspend work on one work order and immediately begin the urgent new work order
Work regulations often require documenting each step, including signatures, serial numbers of parts used, measurements and more
12
13
Use Cases: Data Collection Identify used spare parts Scan barcode or enter serial number of installed device Collect failure and maintenance details Collect measurements, e.g. in maintenance inspections
Data Forms & Data Fields, flexible data types Require relevant data - Enable & Updateable Conditions Ensure valid input - Validation Conditions Data Matrix elements enable tabular input Hierarchical selection trees enable fluent selection from a
large number of alternatives
References Field Force Management Integration Interface
Requirements Version 1.0; http://docs.oasis-open.org/ffm/FFMII-REQ/v1.0/cn01/FFMII-REQ-v1.
0-cn01.pdf
Field Force Management Integration Interface Specification Version 1.0;
http://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPEC-v1.0-cs01.pdf
Complete specification package: http
://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPEC-v1.0-cs01.zip
14
List of contributors Israel Beniaminy, ClickSoftware Technologies Ltd. Jiri Hlusi, Nokia Siemens Networks GmbH & Co. KG Johannes Lehtinen, Rossum Oy Thinh Nguyenphu, Nokia Siemens Networks GmbH & Co. KG Ilkka Salminen, Newelo Oy Jose Siles, Nokia Siemens Networks GmbH & Co. KG Juha Tiihonen, Aalto University Foundation Sami Vaskuu, Newelo Oy Liat Zahavi-Barzily, ClickSoftware Technologies Ltd
15
THANK YOU
BACKUP (TECHNICAL)
17
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
StateData Form
Dependency
Action
Topical Notification
Topical Inquiry
Work Request Status Change Notification
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.
1
Manager
Work Request
Activity
Step
1..*
involves
Work Type Specification
Action
Assignee
Schedule
0..*
leads to
1
1
1
0..*
0..*
1
0..1
1
Field Force
Implementation
Field Work
manages 1..*
1
0..*
1
<<interface>> FFMII
Activity Location
0..1
1..*
0..* declares 1
1..*
1..* 1..*
1..*
assigns works to
makes tasks accessible to
1..*
1
0..*
0..1 starts with
Work Request Status Record
Status
Snapshot Record
Activity History Entry
1 0..*
1
1..*
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
StateData Form
Dependency
Action
Topical Notification
Topical Inquiry
Work Request Status Change Notification
Work type Specification structure
21
A Work Type Specification (WTS) describes content and structure of a Work Request
1
Activity Specification
Work Type
Specification Data Form Specification
Header
Work Overview
Work Instructions 0..1
1
1
0..1
Activity
Step
Activity Location Data
1..*
1..*
Action Input Form
Step Instructions
Action
0..1
0..1
State
1..*
1
leads to
0..*
1
1..*
declares
0..*
1
Condition
0..1 +enable
Condition
+enable Condition
0..1
Status Category
Status Indicator
1
0..1
Example: Activity State Model with Dependencies
22 1
Activity 1
Example Activity State Model (with dependencies)
Task
<<Open>> Pending
<<Active>> Ongoing
<<Closed>> Completed
<<Inactive>> Suspended
New Travelling
to Site Resolving
Issue Completed
Suspended
> Start < > On site < > Ready <
> Suspend <
> Resume <
Activity
<<Status Category>>
State
Step
> Action <
Association of Action in context of specific Step
Transition to another Step
Activity 2
<<Open>> Pending
<<Active>> Ongoing
<<Closed>> Completed
Activity 3
<<Open>> Pending
<<Closed>> Completed
Dependency of Activity or Action on State of another Activity
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 won’t be allowed to proceed towards the next Step, “Traveling to Site”, unless Activity 2 is at any Step associated with the State “Ongoing”.
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
StateData Form
Dependency
Action
Topical Notification
Topical Inquiry
Work Request Status Change Notification
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.
1
Data Form data
Data Form structure
1 0..*
Data Form
Data Element
1..*
Data Element Specification
Data Element Reference
1..*
Data Binding
Data Value
0..1
Data Field Spec
Data Attachment Spec
Data Group Spec
Data Matrix Spec
1..*
1
Work Type Spec Field-Initiated Request Spec
Work Request Work Request Status Record
Field-Initiated Request
Field-Initiated Request Response
shared Data Elements
Data Element Specification Data Element Specification is an abstraction that supports a
common set of attributes for all sub-classes of Data Element Specifications
25 1
Concrete sub-classes
Label
<<tags>> Formatting
<<expression>> Enable Condition
<<expression>> Validation Condition
0..1
0..1
0..1
0..1
0..1
<<expression>> Updateable Condition
…
Data Element Specification
Source 0..1
Data Element Types Simple data field: Data Field Specification Matrix of Data: Data Matrix Specification Attachments: Data Attachment Specification Grouping of possibly nested Data Elements: Data Group
Specification
26
Data Matrix Specification
+ Rows Deletable
Data Element Specification
1..* columns
Data Field Specification
Data Matrix Column Specification
+ Value for Added Row
Data Attachment Specification
+ Mime Type Base + Max Size
Data Element Specification
Data Field Specification
+ Type + Unit-label + Alternatives + Alternatives
Repository Id + Primary
Alternatives
Data Element Specification
Data Group Specification
Element Specification
1..*
elements
Data Form Element
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
StateData Form
Dependency
Action
Topical Notification
Topical Inquiry
Work Request Status Change Notification
Work Request Status Record
28 1
1..*
Work Request
Task
Activity
Step
1..*
Action
1
1
0..1
Action Input Form
Task Status
Record
Data Change History Entry
0..*
Task Status
Activity State
1
*
Revision Number
Activity Instantiation Timestamp
*
1
1
Updated Data
Cause 1
1
1
Assignee-Id
0..1
Activity Change History Entry
0..1
Input Data Activity-Id
Step-Id
Action-Id
1
1
1
Assignee-Id 0..1
1 Change History Entry
+ Change Time + Resulting Revision
Work Request Status Record
Revision Timestamp
1
1..*
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
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
StateData Form
Dependency
Action
Topical Notification
Topical Inquiry
Work Request Status Change Notification
Reference Data
30
1
Implementation
0..* Custom
Repository
Reference Data Repository
System Repository
0..*
Reference Data Item
1
1
ID
Value Reference
1
0..*
maintains
<<strongly typed>>
Class Value << type-less>>
Dictionary Value <<strongly typed>>
Primitive Value
Note: Reference may also target items residing in different repository
1 0..1 0..*
Repository Descriptor
+ id
{ system repositories only }
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.
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
StateData Form
Dependency
Action
Topical Notification
Topical Inquiry
Work Request Status Change Notification
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.
1
Work Request
Field-Initiated Request
Topical Notification
Topical Inquiry
1
Request Data 1
0..*
Topic Assignee
1 0..1
Field-Initiated Request
Specification
<< RDM Repository>> Field-Initiated Requests
Repository Data Form Specification
1
Request Form Response Form
0..1
0..*
WR Processing Topics
1
1