ffmii introduction juha tiihonen refer to ffmii specification for details and explanations 1
TRANSCRIPT
FFMII IntroductionJuha Tiihonen
Refer to FFMII Specification for details and explanations
1
Field Work
– Field Work refers to work that is expected to be conducted by individual (or group of closely co-operating individuals) without need for strong supervisory guidance. Field Work is modeled as Tasks composed of Activities and Steps.
Field Force
– Field Force refers to a group of Assignees (=persons to whom tasks are assigned to) to whom Work Requests are delivered using FFMII interface
FFMS
– Field Force Management System (FFMS) refers to one or more software components collectively responsible for efficient communication with the Field Force
ERMS
– Enterprise Resource Management System (ERMS) refers to one or more software components collectively responsible for assignment of Resources into company business operations, including work planning, execution and exception handling phases
• E.g. SAP
Basic FFMII terminology
2
Field Force Management Integration Interface
3
. . .
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
Rossum, NSN, ClickSoftware Technologies, Aalto, Newelo, Pajat Management
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
• 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
Flexible integration topologies
4
Manager
Implementation
Manager
Multi-paradigm integration topology (example)
ImplementationImplementation
Shared field force
Distributedwork
realization
Domain Model (main topics of FFMII )
Work Type SpecificationWork Type
Specification
FFMII Domain Model
Work Request Status RecordWork Request Status Record
Work Request
Work Request
Reference DataReference Data
AssigneeAssignee ScheduleSchedule
Field Initiated Request
Field Initiated Request
Task
Activity
Step
StateData FormData Form
Dependency
Action
Topical Notification
Topical Inquiry
Work Request Status Change Notification
Domain model with more details
6
1
Task
0..*
Manager
Work Request
Activity
Step
1..*
represents
Work Type Specification
Action
Assignee
Schedule
0..*
leads to
1
1 1
1
0..*
0..*
1
0..1
1
Field Force
Implementation
Field Work
manages 1..*
1
0..*
1
<<interface>> FFMII
Location
0..1
1..*
0..*
describes structure
of
1
1..*
1..* 1..*
1..*
assigns works to
makes tasks accessible to
1..*
1
0..*
1 starts with
Work Request Status Record
Task Status Record
Activity History Entry
1 0..*
1
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.
Work type Specification structure
7
1
Activity Specification
Work Type
Specification Data Form Specification
Header
Work Overview
Work Instructions 0..1
1
1
0..1
Activity
Step
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
A Work Type Specification (WTS) describes content and structure of a Work Request
Relationship of Steps, Actions and States within an Activity
8
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
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.
Example: Activity State Model with Dependencies
9
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”.
Data forms
10
1
WR instance data
1 0..*
Data Form Specification
Data Form Element
1..*
Element Specification
Element Specification Reference
1..*
Data Binding
Value
0..1
Data Field Spec
Data Attachment Spec
Data Group Spec
Data Matrix Spec
1..*
Work Request Data
Work History
Work Request
Updated WR Data
0..*
{ xor }
stored in
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.
Work Request Status Record
11
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
Reference Data
12
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.
Field-Initiated Request
13
1
Work Request
Field-Initiated Request
Topical Notification
Topical Inquiry
1
Request Data
Custom Topic
1
Standard Topic
0..*
1
FIR Template
Topic Assignee
1 0..1
FIR Specification
<< RDM Repository>> FIR Template
Repository
Data Form Specification
1
1
1 0..1
Request Form Response Form
0..1
0..*
WR processing Topics
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.
Non-standard track Draft:
FFMII business drivers & use cases, and high level features requirements
Public 30-dat Review Draft. No comments!
Standard track draft:
Development mostly done
+significant cleanup
+machine-readable (SOAP)
+many details
Goal: Public Review Draft, February 2012
Aalto: Review and comment proposals– + provide content
Aalto: Provide (anonymous) business use case for machinery maintenance/repair
– Contributes to requirements for FFMII– A generic use case has been included– Seek for a concrete case to verify&expand
Status of FFMII (2011-12-16)
14
Existing material 12/2011, 8/2011