field force management integration interface overview

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 Tihonen ( 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 InterfaceSpecifications 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

Use Cases: Data Collection (Juha)

13

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

http://docs.oasis-open.org/ffm/FFMII-REQ/v1.0/cn01/FFMII-REQ-v1.0-cn01.pdf







http://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPEC-v1.0-cs01.zip



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)


FFMII Domain Model


Work Request

Reference Data

Assignee Schedule


Task

Activity

Step

StateData Form

Dependency

Action


Topical Inquiry


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


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


Status

Snapshot Record

Activity History Entry

1 0..*

1

1..*

Domain Model (Work Type Specification)


FFMII Domain Model


Work Request

Reference Data

Assignee Schedule


Task

Activity

Step

StateData Form

Dependency

Action


Topical Inquiry


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)


FFMII Domain Model


Work Request

Reference Data

Assignee Schedule


Task

Activity

Step

StateData Form

Dependency

Action


Topical Inquiry


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

…


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


1..* columns

Data Field Specification

Data Matrix Column Specification

+ Value for Added Row

Data Attachment Specification

+ Mime Type Base + Max Size


Data Field Specification

+ Type + Unit-label + Alternatives + Alternatives

Repository Id + Primary

Alternatives


Data Group Specification

Element Specification

1..*

elements

Data Form Element

Domain Model (Work Request Status Record)


FFMII Domain Model


Work Request

Reference Data

Assignee Schedule


Task

Activity

Step

StateData Form

Dependency

Action


Topical Inquiry



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


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)


FFMII Domain Model


Work Request

Reference Data

Assignee Schedule


Task

Activity

Step

StateData Form

Dependency

Action


Topical Inquiry


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)


FFMII Domain Model


Work Request

Reference Data

Assignee Schedule


Task

Activity

Step

StateData Form

Dependency

Action


Topical Inquiry


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



Topical Inquiry

1

Request Data 1

0..*

Topic Assignee

1 0..1


Specification

<< RDM Repository>> Field-Initiated Requests

Repository Data Form Specification

1

Request Form Response Form

0..1

0..*

WR Processing Topics

1

1

field force management integration interface overview

Documents

field force ffmii ffmii

work request management

field forcefield force

flexible interface

reference data management

work requests

work planning

archive ffmiiwsdl