www.oasis-open.org
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)
FFMII overview
Non-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)


2
WSDL description of the FFMII for
Implementation and Manager interfaces
XML Schema type definitions for the
associated XML namespaces
FFMII Specifications: structure &
main contents
Field Force Management Integration
Interface
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
Higher-order system (optional)
Material
Information
Customer
Data
Partner Data
Enterprise
Resources
Management
Scheduling
Supervision
Operational
Analytics &
Reporting
FFMII
Map Services
Site
Knowledge
Database
BI
People Data
...
Field-Force
Management
Terminal Mgmt
Field Communication
User Profile Mgmt
Field-Force
3
...
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



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

5
Order details, instructions, process flow, products and parts
Resolution codes, on-site sales and exception reporting
find available work, reserve job to me, initiate new job
Example: Data Content and
Structure
Work Request Data Forms
Header
YourComm Installation 012344
32 Connection Street, Somecity
Overview
Instructions
Type: ADSL Installation
Target Time: 07/31/12 12:34
Connection ID: CI333256523
Bandwidth: 12/4 Mbps
Connection Point A: 1234.13.324.1
Connection Point B: 1553.123.23.6
Subscriber
Name: John Smith
Address: 32 Conection Street, Somecity
Phone: 555-0199-777
Products
Product
Copper Connect
ADSL Installation
6
Quantity
1
1
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
Example: Activities and Work Flow
Work Request Activities
Connect
Assignee: John Williams
Location: 17 Apple Street
Begin at: 7/31/12 08:00
Suspended
Suspend
New
Start
Resume
Ongoing
Ready
Completed
Dependent on state
Install
Assignee: Dorothy Hayes
Location: 32 Connection Street
Appointment: 10:00 – 12:00
New
Start
Ongoing
Ready
Completed
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]
7
Highlighted Features



Multi-tenancy
Data-centric design
Work Request Management



Field-Initiated Requests


Dynamically specified operations and data content
Reference Data Management


8
Dynamically specified data content and structure
Multiple Activities with dynamic work flow and dependencies
Unified interface for managing reference information
Field Force, Work Types, Field-Initiated Request operations,
shared Work Request data (code sets, attachments, etc)
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
Multi-paradigm integration topology (example)
Manager
Manager
Shared
field
force
Distributed
work
realization
Implementation
9
Implementation
Implementation
Domain Model (main topics of
FFMII )
FFMII Domain
Model
Task
Work
Request
Work Type
Specification
Activity
Step
Assignee
Schedule
Data Form
State
Action
Work Request Status
Change Notification
Work Request
Status Record
Topical
Notification
Topical
Inquiry
Field Initiated
Request
Dependency
Reference Data
Relationship of Steps, Actions and States
within an Activity
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.
State: State A
Status Category: <<Open>>
Status Indicator: Dispatched
Step 1
State C
<<Inactive>>
X-Obtain-approval
Action: Transition to OnSite
State B
<<Active>>
OnSite
Step 2
Action:
Replace
Action:
Repair
Step 4
Step 3
Action:
Transition to
X-Finalize
Action:
Transition to
X-Finalize
Step 6
Action: {push}
Obtain-approval
Step 5
Action: {pop}
Resume
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.
Action: Transition to Completed
State E
<<Closed>>
Completed
11
Step 7
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.
Use Case: Asset Management





12
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
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
13
References

Field Force Management Integration Interface
Requirements Version 1.0;


Field Force Management Integration Interface
Specification Version 1.0;


http://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPECv1.0-cs01.pdf
Complete specification package:

14
http://docs.oasis-open.org/ffm/FFMII-REQ/v1.0/cn01/FFMII-REQv1.0-cn01.pdf
http://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPECv1.0-cs01.zip
List of contributors









15
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
THANK YOU
BACKUP (TECHNICAL)
17
Domain Model (Work Request)
FFMII Domain
Model
Task
Work
Request
Work Type
Specification
Activity
Step
Assignee
Schedule
Data Form
State
Action
Work Request Status
Change Notification
Work Request
Status Record
Topical
Notification
Topical
Inquiry
Field Initiated
Request
Dependency
Reference Data
Work Request
<<interface>>
FFMII
1..*
1..*
Implementation
Manager
1..*
makes tasks
accessible to
Field Force
1..*
0..*
1
assigns
works to
manages
1..*
Field Work
1
Assignee
1..*
0..1
involves
0..*
1
0..*
Activity Location
1..*
0..1
0..*
1
1..*
1
1
0..*
Action
19
1
Work Type
Specification
starts
with
Step
1
1
declares
1..*
Activity
0..1
Schedule
1
Work Request
0..*
Work Request
Status Record
leads
to
1
Status
Snapshot
Record
1
0..*
Activity
History Entry
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.
Domain Model (Work Type
Specification)
FFMII Domain
Model
Task
Work
Request
Work Type
Specification
Activity
Step
Assignee
Schedule
Data Form
State
Action
Work Request Status
Change Notification
Work Request
Status Record
Topical
Notification
Topical
Inquiry
Field Initiated
Request
Dependency
Reference Data
Work type Specification structure
A Work Type Specification (WTS) describes content and structure of a Work
Request
Work Type
Specification
1
Header
1
Work Overview
0..1
1..*
Data Form
Specification
Work Instructions
0..1
Activity
1
Activity
Location Data
declares
1..*
State
1
Status Category
1
+enable
Condition
Condition
+enable
Condition
1..*
0..1
0..1
1
Step
leads
to
0..*
1..*
Status Indicator
0..1
0..1
0..*
Action
0..1
Step Instructions
Action Input
Form
Activity Specification
1
21
Example: Activity State Model with
Dependencies
Example Activity State Model
(with dependencies)
Task
Activity 1
<<Open>>
Pending
<<Active>>
Ongoing
Travelling
to Site
New
> Start <
<<Closed>>
Completed
Resolving
Issue
> On site <
> Suspend
<
Completed
> Ready <
<<Inactive>>
Suspended
Suspended
> Resume
<
Activity 2
<<Open>>
Pending
<<Active>>
Ongoing
Activity
Step
<<Status
Category>>
State
> Action <
<<Closed>>
Completed
Association of Action in
context of specific Step
Transition to
another Step
Dependency of Activity or Action on State of another Activity
1
22
Activity 1 is not made available to the
Assignee until Activity 3 is in
“Completed” State.
<<Closed>>
Completed
Activity 3
<<Open>>
Pending
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.
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)
FFMII Domain
Model
Task
Work
Request
Work Type
Specification
Activity
Step
Assignee
Schedule
Data Form
State
Action
Work Request Status
Change Notification
Work Request
Status Record
Topical
Notification
Topical
Inquiry
Field Initiated
Request
Dependency
Reference Data
Data forms
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.
Field-Initiated
Request Spec
Work Type Spec
shared
Data Elements
Data Form
1..*
1..*
Data Element
Data Field Spec
Data Matrix Spec
1..*
Data Element
Specification
1
0..*
Data Element
Reference
1
Data Attachment Spec
Data Group Spec
Data Form structure
0..1
Data Binding
Data Value
Data Form data
Work Request
1
24
Work Request
Status Record
Field-Initiated
Request
Field-Initiated
Request Response
Data Element Specification

Data Element Specification is an abstraction that supports a
common set of attributes for all sub-classes of Data Element
Specifications
Data Element
Specification
0..1
Concrete sub-classes
…
Label
0..1
<<tags>>
Formatting
0..1
<<expression>>
Enable Condition
0..1
<<expression>>
Updateable Condition
0..1
<<expression>>
Validation Condition
0..1
Source
1
25
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
Data Element
Specification
Data Element
Specification
Data Field
Specification
+ Type
+ Unit-label
+ Alternatives
+ Alternatives
Repository Id
+ Primary
Alternatives
26
Data Field
Specification
Data Matrix
Specification
Data Form
Element
+ Rows Deletable
1..*
Data Element
Specification
columns
1..*
Data Matrix Column
Specification
+ Value for Added
Row
Data Attachment
Specification
+ Mime Type Base
+ Max Size
Element
Specification
Data Group
Specification
elements
Domain Model (Work Request Status
Record)
FFMII Domain
Model
Task
Work
Request
Work Type
Specification
Activity
Step
Assignee
Schedule
Data Form
State
Action
Work Request Status
Change Notification
Work Request
Status Record
Topical
Notification
Topical
Inquiry
Field Initiated
Request
Dependency
Reference Data
Work Request Status Record
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
Work Request
Status Record
Work Request
1
1
Task Status
Record
Task
1
1..*
1
Task Status
Activity
1
1..*
Activity State *
0..1
Step
Activity
Instantiation
Timestamp
1
Revision
Number
1
Revision
Timestamp
*
1..*
Action Input
Form
Action
Change History Entry
1
+ Change Time
+ Resulting Revision
Data Change
History Entry
Activity Change
History Entry
Assignee-Id
28
1
0..1
Activity-Id
1
Step-Id
1
Action-Id
1
Assignee-Id
0..1
Input Data
Cause
0..1
1
1
Updated Data
0..*
Domain Model (Reference Data)
FFMII Domain
Model
Task
Work
Request
Work Type
Specification
Activity
Step
Assignee
Schedule
Data Form
State
Action
Work Request Status
Change Notification
Work Request
Status Record
Topical
Notification
Topical
Inquiry
Field Initiated
Request
Dependency
Reference Data
Reference Data
Implementation
maintains
Custom
Repository
0..*
Reference Data
Repository
System
Repository
Repository
1
Descriptor
1
1
+ id
0..*
Reference Data
Item
1
ID
0..1
Value
0..*
Reference
0..*
Note: Reference may
also target items
residing in different
repository
<<strongly typed>>
<< type-less>>
<<strongly typed>>
Primitive Value
Dictionary Value
Class Value
{ system repositories only }
1
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.
Domain Model (Field Initiated
Request)
FFMII Domain
Model
Task
Work
Request
Work Type
Specification
Activity
Step
Assignee
Schedule
Data Form
State
Action
Work Request Status
Change Notification
Work Request
Status Record
Topical
Notification
Topical
Inquiry
Field Initiated
Request
Dependency
Reference Data
Field-Initiated Request
Topical Notification
1
Field-Initiated
Request
Topical Inquiry
1
Request Data
0..1
1
Assignee
0..*
Topic
Work Request
1
0..*
1
WR
Processing
Topics
Field-Initiated
Request
Specification
0..1
1
Response Form
Request Form
<< RDM Repository>>
Field-Initiated Requests
Repository
1
32
Data Form
Specification
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.