This document describes the Field Force Management
Integration Interface (FFMII) business drivers, business use cases, and high
level features requirements.
[RFC2119] S. Bradner. Key words
for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March
1997. http://www.ietf.org/rfc/rfc2119.txt
[FFMII-SPEC] Field
Force Management Integration Interface Specification Version 1.0. 05
October 2012. OASIS Committee Specification 01. http://docs.oasis-open.org/ffm/FFMII-SPEC/v1.0/cs01/FFMII-SPEC-v1.0-cs01.html.
None.
This specification uses normative text. The keywords
"MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this specification are to be interpreted as described in [RFC2119]:
…they
MUST only be used where it is actually required for interoperation or to limit
behavior which has potential for causing harm (e.g., limiting retransmissions)…
These keywords are thus capitalized when used to
unambiguously specify requirements over protocol and application features and
behavior that affect the interoperability and security of implementations. When
these words are not capitalized, they are meant in their natural-language
sense.
All sections and
appendixes, except “Scope” and “Introduction”, are normative, unless they are
explicitly indicated to be informative.
|
Activity
|
[FFMII-SPEC]
|
|
Assignee
|
[FFMII-SPEC]
|
|
ERMS
|
[FFMII-SPEC]
|
|
Field Force
|
[FFMII-SPEC]
|
|
FFMII
|
[FFMII-SPEC]
|
|
FFMS
|
[FFMII-SPEC]
|
|
Field Work
|
[FFMII-SPEC]
|
|
Implementation
|
[FFMII-SPEC]
|
|
Interface
|
[FFMII-SPEC]
|
|
Manager
|
[FFMII-SPEC]
|
|
Peer
|
[FFMII-SPEC]
|
|
Step
|
[FFMII-SPEC]
|
|
Work Request
|
[FFMII-SPEC]
|
|
Task
|
[FFMII-SPEC]
|
|
BD
|
Business Driver
|
|
BR
|
Business Requirement
|
|
ERMS
|
[FFMII-SPEC]
|
|
FFMII
|
[FFMII-SPEC]
|
|
FFMS
|
[FFMII-SPEC]
|
|
UC
|
Use Case
|
Integration of Field Force Management systems into the
surrounding IT environment tends to be a costly and time consuming undertaking,
although conveying dialog with field force through digital media may appear
straightforward on the surface. A fundamental reason is complexity caused by
variation among work request types, interaction styles, and sheer number of
exceptional cases that need to be handled coherently.
Need for communication with field force is typically not a
standalone concern, but rather it is implied by the nature of business
processes of a particular company or unit. The role of Field force
communication systems is to assist those processes, and therefore they are
expected to closely adapt to constraints of each business. Such systems not
only serve the field personnel in terms of terminals and user interface, but
above all act as an “extended arm” of work planning systems when reaching out
for the addressable field force. The versatility of supported interaction
paradigms and flexibility of conveyable content can be a decisive factor for
success or failure of field force management solutions and related integration
projects.
Traditionally, Field Force Management systems have been
approached by their designers from two distinct starting points:
- Field
communication aspects, or...
- automated
work planning and advanced decision making support
While each of these approaches are fully justified in their
own right, the major issue is to draw a border-line between what is inside and
what is outside the scope of each type of system.
In fast rolling projects, border-lines between functional
domains of systems are often crossed (based on seemingly good intentions), with
the consequence of solution components no longer remaining focused on a
particular area of excellence, but rather trying to address a large set of
concerns at once, with various degree of success. The outcome is often
conceptually insufficient or difficult to comprehend and strongly specific to a
particular project, therefore also hard to evolve or apply in other contexts.
This creates severe challenges both for businesses seeking out-of-box solutions
and for software vendors that spend time developing case-specific solutions
instead of focusing on value-add content.
Ability to construct an IT environment using out-of-box
interoperable components is instrumental for cutting project delivery times and
integration costs. In order to achieve this, each individual building block
must honor its defined scope; support at least a minimal set of expected
features and interaction patterns, while allowing a space for vendors’ own
growth within their respective business domains.
Field-Force Management Technical Committee (FFM TC) concerns
itself with positioning and interoperability aspects related to ERMS and FFMS.
ERMS and FFMS systems must inter-operate as a part of a
larger entity. While both ERMS and FFMS may individually be integrated with
other types of external data sources, their roles create a clear sense of hierarchy.
Figure 1 outlines relative positioning of ERMS and FFMS as promoted by FFM TC:
Figure 1: Field Force
Management Integration Interface
The main normative deliverable of FFM TC, the 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.
FFMII aims to enable an ecosystem of interoperable software
solutions that allows the investing party (such as field service provider) to
construct an IT environment out of well-defined components fitting a particular
purpose, and seamlessly interacting with each other.
From the software vendor point of view, FFMII provides a solid
foundation of field work modeling and request exchange. This translates into
reduced time to market and an ability to devote more time into market creation
and product development activities.
Many business drivers of FFMII are related to minimizing the
time needed to develop, integrate, and deploy field work management solutions
consisting of systems acting in different roles.
Field work modeling of FFMII SHOULD be flexible enough to
support different business use cases. Especially the structure of data content
required to model the field work and the process flow varies not only from one
business sector to another but also between individual businesses. Cutting time
to delivery requires that the same development effort can cover this
variability.
The system topology varies greatly between deployments.
Sometimes there is a single work planning system, in other cases multiple sources
of work share the same field-force. Furthermore, the field force might be
divided into several independently managed units. The interface SHOULD
therefore support different system topologies having one or more sources for
field work and one or more field force management units.
While the interface should be flexible, excessive
flexibility easily leads to increased complexity and time to market. Therefore
it is important to balance flexibility with ease of adoption. Ease of adoption
is facilitated through elegant interface design and utilization of commonly
used and well-supported underlying technologies, such as XML, HTTP, and web
services. It is also important that the interface enables fast prototyping,
e.g. to support early phases of project realization and to enable creation of
prototypes for pre-sales and other purposes.
A large scale field work management deployment may involve
thousands of field workers. Correspondingly high volumes of data are
transferred between the work planning systems and the field communication
system. However, while a high amount of work requests may be deployed in the
field (made visible to field personnel); only a fraction of those is typically
under active realization at any given point of time.
The interface SHOULD therefore support efficient
communication between systems to allow for large scale deployments. The
ability to identify updated work requests is particularly important when
synchronizing work request status information.
FFMII SHOULD have the ability to efficiently address groups
of data objects to ensure technical scalability of remote communication between
interacting systems. Such communication is, by nature, subject to transaction
rate, round-trip, and potentially bandwidth limitations.
While the interface SHOULD be flexible enough to address
demanding use cases and interaction styles, all its features are not
necessarily required in all deployment contexts. In order to avoid risks and
costs of unjustified complexity, the interface SHOULD enable specialized
solutions that implement or use only a sufficient subset of the interface
features to implement an end-2-end use case [Note 1]. This, in-turn, opens
business opportunities for software vendors specializing on particular markets
where the advanced features of FFMII interface would not be of relevance.
Note 1: For example, an ability to exchange work requests
based on mutually agreed fixed structure eliminates the need for dynamic work
structure modeling where it otherwise would not be of relevance. See Use Case
4.
Field operations performance is in proportional relation to
the expression accuracy integration interface provides to the work planning
system. Particularly, a precise balance is to be established in order to
prevent delays and mistakes caused either by missing information or information
overload.
The type of Field Work may range from fairly simple actions
to relatively complex sequences of steps. Therefore, FFMII MUST have the
ability to convey information that guides the Assignee through individual
phases of Field Work. Additionally, whenever information is to be collected
from the field, the work planning system SHOULD have sufficient means to
enforce relevant constraints on individual data elements.
Furthermore, any information provided must be clear and
understandable, and offered to the Assignee in an intuitive, easy-to-access
way. While it is not the intention of the FFMII interface to deal with
low-level data presentation details (e.g. colors, font sizes or item
placement), support for a limited set of information visualization assertions
SHOULD be available. [Note 2]
Note 2: For example, to indicate that certain data element
is phone number, web-link, or text to be displayed as mono-space element
Successful field operations require that correct data is
delivered to and from the field and that any updates are processed correctly.
While correctness of data is always subject to correct operation of involved
systems and their users, FFMII MUST provide reliable data communications
without risk of data loss.
Modern transport protocols already provide necessary
services for ensuring reliable data delivery, such as message integrity verification,
sequencing, and resending. However, additional means of protection are
required on application level for ensuring reliable communication even when
issues such as data update collisions or loss of synchronization appear.
Data related to field work may be updated simultaneously
from the work planning system and by the Assignee. Such simultaneous updates
may be conflicting. For example, an Assignee might report the work as
completed simultaneously with work description being updated in the work planning
system. To detect and correctly handle update conflicts, the interface MUST
have means for conflict indication.
Furthermore, under certain circumstances, such as during
initialization of a system, it SHOULD be possible to ensure that data between
ERMS and FFMS is synchronized. For such purposes, features enabling efficient
data realignment are desirable.
The deployment configurations may vary significantly.
Software vendors’ mode of operation causes further variation. Some software
components of the field force management solution may be provided as a service
(i.e. in SaaS mode) over Internet or it may be that all components are deployed
to the same host platform.
To support deployment configurations with components
communicating over un-trusted networks, such as the Internet, elementary
security features such as message integrity and message authenticity
capabilities are needed. Commonly used transport level security mechanisms
SHOULD be supported where available.
On the other hand, for deployments where all components are
deployed within the same trusted environment, extensive security measures may
unnecessarily slow down implementation and cause extra work. Therefore the
interface SHOULD be flexible for each deployment.
All in all, the interface design SHOULD make minimal
assumptions regarding the deployment environment.
The interface also MUST NOT imply usage of particular
implementation technologies on ERMS or FFMS side, including topics such as choice
of operating systems or programming languages.
This section contains examples of potential business use
cases for the FFMII interface. The use cases are intended for deriving general
requirements for the interface and to verify that the interface design is
sufficiently generic to cover different business sectors involving field work
and field communication. The interface itself will not be limited to the use
cases described herein, but rather be applicable for many business sectors
having similar requirements.
DISCLAIMER: Company or other names used in this document
are intended for illustrational purposes only, and have no relation to any real
entities whether businesses or individuals.
Communal Services Corporation provides waste collection
services for residents. In the case of residents living outside of main urban
areas, organizing regular collection is not cost efficient. Instead, the
company offers Internet based on-demand type of service for ordering waste
collection when needed.
When a new Work Request is created, it contains information
such as customer details for invoicing purposes, location of the work place
(including more details if needed), and naturally indication of the work type.
The person delivering the service (an Assignee) is expected to submit a simple
confirmation to the dispatching center using his mobile device when the Work
Request has been completed.
Service Company Ltd. specializes on expert services for
particular machinery used in furniture manufacturing. Their staff regularly
visits customer premises to perform standard assessments as well as serving
urgent faults as they arise. While the visits are regular in nature, it is not
always the same Assignee to handle all visits, but rather a person who is on
duty and not occupied by other tasks at given moment. Service Company Ltd
utilizes a specialized work scheduling system for making resourcing decisions
per each Task instance, integrated with field communication system for
delivering Work Requests to field technicians.
In handling site assignments, the Assignee is provided with
Work Request consisting of job description, work type, classification of the
issues, priority, bill of materials, specialty tools, and expected resolution.
Additionally, history information about most recent calls to the site is
included, providing even more of relevant background to the technician. Due to
SLA requirements, it is essential that fault correction jobs are followed up
from start to completion. In order to ensure high accuracy of the work
performed, detailed technical drawings of machinery are available for the field
technicians as well.
When on job, the Assignee is expected to keep the Work
Request change log up to date by means of additional text inputs, especially if
the issue in question cannot be solved immediately, and the work needs to be
interrupted. Should part of the machinery need to be replaced, Assignee is
expected to precisely identify both, the part being removed as well as its
replacement. This information is particularly relevant from equipment lifecycle
management point of view.
As part of Work Request closing, Assignee is expected to
supply a “resolution code” providing indication of the issue and its
resolution, of which some codes are more commonly needed than others. The
Assignee also has an opportunity to supply additional information as a
free-form text note.
Depending on maintenance service level agreement, the end
user may be required to accept delivery using digitally captured signature or
request-specific confirmation code supplied through Assignee’s terminal (e.g.
mobile phone or PDA device).
Field Connect Company provides telecom installation services
on behalf of operators in the region. Majority of the ordered works deal with
the land-line network, and generally involve visiting several distribution
points, cross-connect places and end-user premises, depending on the work order
content.
A specific Field Work may be dispatched to a single or
several Assignees. Each Work Request contains all details necessary for
performing the entire installation, even if possibly some parts of it may be
handled by another colleague. An Assignee typically needs to visit several
distinct locations (e.g. cross-connect locations) to perform the work. He or
she may have to switch between locations to create or troubleshoot the required
connections.
Whenever multiple Assignees are involved, names of the
involved colleagues are indicated in the Work Request, and Work Request status
updates will be synchronized to keep each Assignee up-to-date regarding
progress the other colleagues have made. The frequency of the updates depends
on the work type.
In order to avoid unnecessary delays, a Work Request
contains additional location access information for each location, if such is
known to the upper-level system. Such information may include, for example,
indication of the nearest suitable parking place, contact for building
maintenance companies, detailed navigation information, and alike. Should the
location information prove to be incorrect, incomplete, or missing, Assignee
has an opportunity to correct it directly on his device. Updated location
information is propagated to the upper-level system, and cross-distributed with
future field request for the same location.
Field Force Corporation occasionally has more Field Work to
handle than what its Field Force is able to accomplish within standard working
hours. Therefore, during rush periods the company conducts a survey among
their field personnel to find out who would be willing and able to work
overtime so that they can be assigned extra tasks.
As the company operates in a country with several official
languages, plus they also employ some foreigners speaking English language
only, the survey is produced by the work planning system using several language
variations, of which one is displayed to each person depending on his or her
personal preferences set in a user profile. Nevertheless, the answers are
always based on same set of predefined choices (e.g. Yes/No/Can’t Say) so that
the collected responses can still be automatically processed and summarized in
a uniform way for the work planners. [Note 3]
Because the survey is conducted outside of normal business
hours, and the content is rather simple, the field-communication system chooses
to use SMS as an alternative communication channel to reach as large portion of
the company Field Force as possible. The choice of communication channel,
however, is transparent for the work planning system.
Note 3: The ability to use multi-language content is not
limited to this particular use case but is applicable throughout all use cases
where multi-lingual work force may be involved.
ElectricCo provides electricity transmission and
distribution in its region. As such, it is responsible for many assets. Some of
these are "linear assets", that is assets that stretch over some
path, such as power cables and the above-ground pylons or underground pipes
that support them. Other assets are grouped in specific locations such as
stations and substations.
As in UC2 and UC3, Work Requests MAY have a complex
structure composed of Tasks, Activities and Steps. Additionally, due to the
remote location of some assets, there is a need to download some documentation
and other info in advance.
For safety and regulatory reasons, work progress needs to be
recorded and shared by means of timestamps, step transitions and user input.
The same reasons also necessitate explicit statement of dependencies involving
complete Tasks and/or specific Steps within Tasks, so that FFMS can enforce
conformance with these dependencies. Such ordering and sequencing of
Activities, Tasks and Steps are critical, and non-compliance with them may have
severe consequences.
While Assignees are at the site, they may have a reason to
handle another asset that was not included on the original work request. Here
are two possible reasons:
- The Assignee notices some
problem in an asset near the asset related to the work request and decides
to open a new Work Request related to that other asset. Once created, the
Assignee may ask that the new Work Request to be scheduled to him or her
for immediate execution, or leave it to the scheduling system to schedule
the work request to some other time and/or Assignee.
- The Assignee may ask the
scheduling system to look for existing Work Requests that are currently
unscheduled or scheduled for a later date and that relate to other assets
in the same area. Once such Work Requests are found, the scheduling system
may automatically schedule them to the Assignee, or display such work
requests to the assignee and allow him or her to choose one that best fits
the current situation (e.g. remaining time, accessibility, available
tools).
The above workflows imply a more general paradigm of Field-Initiated
Interaction, where FFM is the origin of new Work Requests, Tasks,
Activities etc., or changes in such items that already exist.
5.6 Use Case 6:
Intervention by On-Site Field Force Team Leaders
ElectricCo divides its Assignees into teams that regularly
co-operate in the field. While ElectricCo may have sophisticated automated
scheduling and/or human operators (dispatchers) managing Assignee schedules,
final responsibility for getting the tasks done reliably and safely rests with
team leaders in the field. For that reason, team leaders occasionally need to be
able to query the Work Requests and current status for members of their teams.
In some cases, team leaders also need a way to request
specific interventions to the Work Requests. These include releasing an
Assignee team member from a specific Work Request; changing the assigned team
member for a specified Work Request; and changing estimated times (e.g. start
time or duration) for specified Work Requests. These are requests which the
ERMS may or may not decide to approve.
ERMS makes its scheduling decisions based on information
regarding which Assignees are available at what time periods or intervals.
Occasionally Assignees are forced to deviate from this commitment – e.g. an
Assignee who calls in sick, or an Assignee who is asked to perform some other
task, outside the scope and knowledge of ERMS. The Assignee needs a way to
report the absence (or other reason for not being able to perform the task) to
ERMS, so that ERMS can modify the planned schedule accordingly. This is an active
notification of absence, which is preferable to passive detection of absence
(that is, ERMS deducing non-availability due to the fact that the Assignee does
not respond to messages and Work Requests sent to him; though a typical ERMS
implementation will probably support such passive detection of absence as
well).
As in UC6, team leaders should also be able to report
unplanned absences on behalf of their teams.
CableCo provides cable TV, Internet and wired telephony to
customer homes. During a service visit, Assignees may need to activate a new
set-top box (STB). For that, they read the STB's number (and/or number of card
inserted into the STB) – such numbers may be obtained via RFID, barcode or
other automated means. This number should be recorded and send via FFMII to
ERMS. ERMS may then need to provision the new STB: ask for activation, and
receive indication for activation status. Such requests from the field are
routed through ERMS to the request's designated target. FFMS expects a
response to this request that it has initiated and created.
Note: It is imperative for such requests to be routed
through ERMS in order for it to perform book-keeping of the out-bound messages
sent to external systems (e.g. activation of specific cable services), and the
responses received. Otherwise the record of the performed service, and its
actual status as completed successfully, could not be known to ERMS.
The Assignee may also need to interact with the customer
regarding non-technical issues, such as viewing and explaining the latest cable
invoice or selling additional services. While such issues are outside the FFMII
scope, the Assignee reports the additional interaction with the customer and
any additional service performed to the ERMS via FFMII. Furthermore, based on
this input, the ERMS adds new Activities and Steps to the Work Request, as
necessary, including indication as to whether further payments, signatures,
approvals etc. are required so that FFMS can properly guide the Assignee.
Globally operating Heavy Machinery Manufacturing Ltd (HMM)
is a design, manufactures and services power production systems used mainly in
ships and power plants. A broad range of services is offered, ranging from
basic support such as on-request service calls, installation and commissioning,
to performance optimization, upgrades, agreements focusing on overall equipment
performance, and asset management.
On-call service repair calls are the most important Field
Work type (about 80% of service orders) and are performed by 1-2 Assignees. Preventive
maintenance (e.g. service, inspection) and troubleshooting assignments are also
common. Major overhauls and commissioning require multiple Assignees with a team
leader and may have duration of several months.
Field Service Order Coordinators schedule and assign Field
Work, collect details, and perform travel arrangements. Usually spare parts are
arranged by a separate Spare Parts Coordinator. The customer usually has
technical manuals with service instructions, and makes them available.
A work order includes: Order number, Installation number
& name, product number, customer number & name, and the task(s) to be
completed. Related persons are also specified: Service coordinator, Account
manager, Leading Service engineer (if any). Contact details of all HMM persons,
customer contact and location details are provided. In addition, packing lists,
a Proforma Invoice, delivery claim and cargo documents are made available to
the Assignee. Dependencies between activities exist – some tasks must be
complete before dependent tasks. Some customer locations lack network
connections, and the cost of data roaming in some locations is prohibitive.
Therefore off-line availability of work orders is important.
Sometimes an Assignee carries spare parts personally, but
normally spare part logistics is managed separately due to physical size of
required parts. Usually Field Work at site starts with a step for checking that
all required spare parts have arrived. For this purpose, the Assignee has a
listing of expected materials that can be compared with packing lists of
arrived shipment(s). All spare parts ordered for a work order are assumed to be
used. Exceptions may occur and are reported. The customer may keep the extra
spare parts or they may be sent back for restocking.
Some Work Orders have a fixed price, but are mostly charged
based on used time (preparation, execution, reporting), spares, and travel
costs (time + costs + margin). Sometimes (e.g. off-shore operations) time is
reported and charged by a detailed activity type. Hourly rates vary by field
service person category and market area. Workforce utilization rate is a
primary key performance indicator (KPI). To facilitate calculation, all work
hours (billed or not, overtime), vacations, and idle time are recorded. Other
KPIs are the workforce invoiced utilization rate and time to invoice.
Upon completion of Field Work, customer signature for spent
hours is usually required. Additionally, an Assignee creates a free-form work
order report that must be accepted by the Field Service Coordinator and
subsequently delivered to the customer. Internal comments (not visible to
customer) may be created. About 500 work reports are created each week
globally. Smaller units of Field Work are reported on completion, and larger
cases on weekly basis.
Sometimes an Assignee identifies opportunities for
additional sales of services or equipment. These are reported in context of the
equipment or site so that the corresponding account manager can contact the
customer knowing appropriate details (Sales lead in CRM).
There are about 30 standard technical parameters per engine
type that are measured in inspections and overhauls, and recorded in association
with the product individual. Measurement of wear of cylinder liners provides an
example.
Each product individual has individual compositional
structure that is maintained for recording compatible spare parts. Compatible
spares may change at product individual level, e.g. an engine is modified to
use oversize cylinder liners to compensate for wear. Furthermore, customers or
competing service providers may install third party spare parts or modify
equipment. In such cases part changes may not be recorded in HMM’s system. It
should be possible for an Assignee to report detected changes. Because an
engine consists of about 3000 material numbers, it should be possible to pick
the corresponding location code from a structured list, and then attach a related
note or code.
This section describes the required high level features of
the FFMII interface. These features are derived from the potential FFMII
business drivers and business use cases in the above sections. The “Origin”
heading shows a reference of where each of the requirement. Related features
are grouped into sections and subsections.
The FFMII interface specification SHALL be split into its
transport independent part (the interface concept) and one or more supported
protocol bindings.
Rationale: This distinction is essential as to
allow the interface concept to stabilize despite eventual extensions and
enhancements on message exchange level. Additionally, while the transport
independent part of the interface specification is provided as a text document,
for some protocol bindings the specification MAY be provided as a set of
machine-readable artifacts (e.g. data models in XML) rather than text.
Origin: BR/Future-Proof Design
The FFMII interface SHALL be data-centric, that is,
providing only a limited set of generic calls while being flexible on data
level (payloads).
Rationale: Data-centric interfaces represent a
proven design pattern allowing constructing and verifying message exchange
logic, including an option of forwarding proxies, independently of the actual
business use cases being served and/or containing variations across work
requests.
Origin: BD/Cutting integration costs, BD/Cutting
time to delivery, BR/Adaptability to use cases
The FFMII interface SHALL support dynamic definition of data
elements and structural Work Order definitions.
Rationale: Different business use cases require
different data content and structure. For example, telecommunication
installation work typically has a number of product-specific technical
parameters such as cable pairs or IP addresses while on-site maintenance work
might have machine-specific instructions or documentation.
Origin: BR/Expression accuracy, BR/Adaptability to
use cases
The FFMII interface SHALL NOT mandate any particular
technology or implementation approach, using which the received Work Requests
are communicated to the Field Force.
Rationale: While the FFMII interface is explicit in
work request structure and content, it does not prescribe particular
communication technology used for delivering messages to field personnel. It
therefore opens opportunity for various kinds of solutions using technologies,
such as Web, on-device clients, SMS, and others, or even combinations thereof
upon vendor consideration. This approach not only off-loads the work planning
system of the low-level details of information visualization, but also opens
possibilities for competitive offerings each profiling itself in particular
way.
Origin: BD/Fit for purpose, BD/Ecosystem enabling,
UC4
Whenever applicable, the interface specification SHALL
provide support for bulk operations
Rationale: Operations handling several data objects
in a single call are an efficient way of mitigating impact of network latency
and round-trip delays inherent to remote communication protocols.
Origin: BR/Technical Scalability
Single Implementation of FFMII interface SHOULD be able to
receive Work Requests from one or several distinctly identified Managers
simultaneously, yet maintaining an appropriate level of data isolation between
those.
Rationale: This capability is a pre-requisite for a
single Assignee being able to deliver works requested by different ordering
parties without need for dedicated field communication solution towards each
ordering party individually.
Origin: BR/Shared Field-Force
6.2.1.1 Deliver and update Work Requests in the field
FFMII interface SHALL provide means for dispatching Work
Requests and their updates to the associated Assignees.
Rationale: Ability to formulate and dispatch Work
Requests is a fundamental feature of field communication interface. Planned
Tasks are communicated to field personnel as Work Requests. When work
schedule, instructions or other Field Work related information changes, the
associated Work Request must be updated to notify Assignees of the changes.
Origin: UC-All
6.2.1.2 Receive Work Request status information from
the field
The FFMII interface SHALL provide means for retrieving Work
Request status information from the field.
Rationale: Ability to follow-up progress of requested
Field Work is instrumental from the operational and also business process
points of view. For example, a customer may need to be informed when Field Work
starts or completes, and progress and timely completion of ordered Field Works
may have implications on invoicing and auditing of SLA performance. Work
request status reporting may also be important for other reasons not directly
related to monetary or contractual aspects, such as work safety requirements.
Origin: UC-All
6.2.1.3 Receive Work Request data update from the field
FFMIII interface SHALL provide means for retrieving data
from the field specifically denoted as expected user input in the Work Request
structure.
Rationale: A business process involving Field Work
may expect an Assignee to provide information related to a Work Request, for
example, indication of the work hours or number of kilometers to be billed from
the customer. Such additional information may need to be provided at different
stages of the Field Work, depending on the use case, and its semantics may
depend on the current status of the Work Request. Therefore, the containing
process must be able to receive additional user provided Work Request data with
status information.
Origin: UC-All
6.2.1.4 Receive Work Request status change
notifications from the field
An Implementation SHOULD be able to dispatch notifications
towards the Manager concerning Work Requests status of which has changed.
Rationale: When the number of deployed Work Requests
is high, it is not efficient to poll status of each of them separately (or even
as a bulk operation).
Origin: BR/Efficient messaging
6.2.1.5 Ability to query Work Requests based on overall
status and time of most recent change
FFMII interface SHALL provide means for Manager to query
high-level status information of the deployed Work Requests, in order to
identify Work Requests that have been changed within given period of time.
Rationale: In the event of losing synchronization
between Manager and Implementation, a Manager should have an option to iterate
over high-level status information of already deployed Work Requests without
retrieving all details of each Work Request. Based on query result, Manager
should be able to retrieve complete detail of one or more Work Requests.
Origin: BR/Efficient messaging, BR/Realignment
6.2.1.6 Ability to cancel Work Request
FFMII interface SHALL provide means for Manager to cancel
Work Requests.
Rationale: A Work Request is sometimes cancelled, for
example because the original order is cancelled. It is also possible that a
Work Request or some included activities are withdrawn from a specific
Assignee, and assigned to another person. Therefore, it should be possible to
cancel Work Requests.
Origin: UC3
6.2.1.7 Ability to initiate Work Requests from the field
FFMII interface SHALL provide means for FFMS to initiate new
Work Requests through interaction with ERMS. Optionally, initiating such
requests may lead to an "appointment booking" workflow: ERMS responds
via FFMII by offering several options for the timing of the new WR. FFMS then
allows the person for whom the new WR is requested to select one of the
options. FFMS then reports this choice to ERMS.
Rationale: Sometimes the need for a new Work Request
is discovered by the Assignee of an existing Work Request. In such a case it
shall be possible for the Assignee to use FFMS to initiate creation of a new
Work Request.
Origin: UC6
6.2.1.8 Search, view, and select Work Requests from the field
FFMII interface SHALL provide means for FFMS to search,
view, and select Work Requests matching specific criteria, such as time range,
location etc. When ERMS responds with the search results, the Assignee may
request that one or more of the returned Work Requests should be assigned to
him or her.
Rationale: Sometimes the Assignee has more free time
than expected and needs a way to find additional work that needs to be done in
the near future and the nearby area.
Origin: UC6
6.2.1.9 Request changes in Work Requests across teams
FFMII interface SHALL provide means for the Assignee to
request changes in Work Requests, e.g. change the duration of an activity, or
replace an Assignee with another Assignee on the same team. The request MUST
include the requester's identity, to enable the ERMS implementation to
determine whether the requester has the right authorization for such requests.
Rationale: team leaders often work as Assignees in
the field, but they still require some level of visibility and control over
their team's activities.
Origin: UC6
6.2.1.10 Interaction with other systems
FFMII interface SHALL provide means for carrying messages
that are initiated in the field and targeted at other systems (not the
Manager), and messages flowing in the opposite direction. These messages SHALL
include identification of the Assignee who is the originator or recipient in of
the message, and identification of the Work Request which is the context for
the message. FFMII SHALL enable two ways of sending responses to such messages:
Either synchronously, within the body of response to the message; or
asynchronously, where the reply to the message includes just a standard
acknowledgement and the actual response is sent later. The messages exchanged
in this way may be dynamically specified by ERMS.
Rationale: During a service visit, Assignees may need
to request some remote actions from the service organization's operational
systems and/or other employees. This interaction needs to be placed in the
context of the current Field Work.
Origin: UC8
6.2.2.1 Separation of Work Request structure and
instance data
FFMII interface SHALL allow separation of Work Request
structural definition from instance data.
Rationale: While both work request structural
definition and instance data are both logically part of a Work Request, it
SHOULD be possible to separate these two concepts due to following reasons:
- Ability
to establish work request structural definition as template that is
defined once, and does not need to be included in every request separately
(leading to bandwidth savings).
- Support
separation of roles, whereby work request structural definition and its
instance data do not necessarily arrive from the same source.
- Allow
the Implementation to support certain predefined work types only, without
having to fully implement support for all aspects of dynamic work type definition
(form of mutual agreement).
Still, the FFMII interface SHALL also support inclusion of
complete Work Request structural definition as part of the request itself.
Origin: BD/Adaptability, UC4, BD/Ecosystem enabling
6.2.2.2 Support for multiple parallel Activities within
a Work Request
Work Request SHALL be composed of one or several Activities
possibly taking place at different locations.
Rationale: Different business use cases require an
Assignee to perform different kinds of distinct Activities to complete a Work
Request. For example, a communal waste collection Task MAY include a single
waste collection Activity. Meanwhile, a telecommunication installation work
may involve connection Activities at several different locations and an
equipment installation Activity in yet another location. Therefore, a Work
Request must support multiple, possibly parallel, Activities that may need to
be performed at different locations.
Origin: UC1, UC3
6.2.2.3 Support for dynamically specified workflow on
Activity level
FFMII interface SHALL support definition of dynamically
specified workflow on Activity level.
ERMS specifies the States and Steps of an Activity as well
as the available transitions between the Steps dynamically as part of the
structural definition of a Work Request. A different state model can be
specified for each Activity, typically depending on the type of the Activity or
the containing Work Request. The specified state model also forms the basis for
tracking the status of Activities.
Each dynamically specified State is explicitly associated
with one of the predefined Status Categories, indicating the overall status of
the Activity from Assignee perspective when in the particular State. Status
Category does not affect state model execution but may be used by the
Implementation for, for example, visualization purposes. Status Categories are
described in Section 6.2.4.2.
Rationale: Different business use cases may require
different workflows and different levels of status tracking for associated
activities. Some short duration tasks such as waste collection may only
require reporting of task completion while tasks of longer duration and
specifically tasks with SLA requirements may require reporting both start and
completion times.
Furthermore, even in case of standardized Field Work types,
workflow alterations on individual work request level might be needed,
especially if progress at each step is to be followed by the Manager. In such
case, it SHOULD be possible for a Manager to construct a custom work flow on activity
level.
Origin: BD/Adaptability, UC-All (Note 4), UC5
Note 4: Each defined UC, indeed, relies on somewhat
different workflow (progression of applicable Steps and States).
6.2.2.4 Work Request state constraints
FFMII interface SHALL provide means to assert constraints
for state transitions on Activity level, covering issues such as dependencies
between and within Steps of Activity level workflows and mandatory user data
input.
Rationale: The Field Work process may imply a number
of constraints regarding the way a unit of work (or group of related units of
work) is delivered by Assignees. Such constraints may result into a need to
sequence activities, a need to avoid parallel activities, or specify rules on
access to different parts of work request data at different stages.
For example, in some contexts a particular activity may not
be started until a related activity reaches its final state. Similarly, it
might be desired that an Assignee explicitly closes or suspends an activity
prior to moving onto another task. Furthermore, updating Work Request content
is typically not desired (and should be prevented) after it has reached a
closed state.
Origin: BR/Accuracy of Control, BR/Rich expressive
capabilities
6.2.2.5 Ability to declare data element sets for data
display and user input
FFMII interface SHALL allow declaring data elements that are
intended to be shown to Assignee and that are required as input during Work
Request realization using limited set of reusable primitives (declaration
clauses).
Rationale: Each Work Request MAY include several data
elements (possibly data element sets) that are intended to be shown to the
Assignee to convey details of the work to be performed. Similarly, any
information that is to be collected from the field needs to be formalized in
the Work Request.
As instructions and user-input data are Work Request
specific, FFMII interface SHOULD provide modeling and data binding capabilities
allowing such data to be specified with a moderate set of generic, reusable
primitives.
Origin: BR/Adaptability, UC-All
6.2.2.6 Ability to declare most commonly used input
values for data elements
FFMII interface SHALL allow declaring most common values for
required input data elements.
Rationale: It SHOULD be possible to define
preferred or most commonly used input values for a given input field whenever
user input is required. This helps avoiding user errors and saves time.
Origin: BR/Field Operations Efficiency, BR/Error
Avoidance, BR/User Experience, UC2
6.2.2.7 Documents and multi-media attachments
FFMII interface SHALL provide support for inclusion of
documents and multi-media attachments as part of Work Request and/or user
input.
FFMII SHALL support document attachment metadata. The FFMS
implementation and/or the FFMS user may use this information to better manage
the document access process at their discretion, e.g. download a large file
only when a fast connection is available, or prioritize so that files with high
relevance will be downloaded first, or downloaded even if they use link
attachment instead of explicit attachment.
Rationale: Some necessary information (e.g.
instructions) may not be available as structured data. It shall be possible to
include with a Work Request attachments such as PDF files, vector or raster
graphics, and alike. Attachments may also be valid input provided by an
Assignee, such as photographs taken with the mobile equipment or on-site
uploaded files. Since some work is done at remote location where network
access is not guaranteed, FFMII shall enable making it mandatory to download
some files (by using explicit attachment) and providing "hints" such
as file relevance so that the implementation can decide whether to download
files that use link attachment.
Origin: UC2, UC5
6.2.3.1 Ability to specify schedule for Work Request
FFMII interface SHALL provide means for specifying Work
Request delivery schedule information.
Rationale: Work Request tasks typically have a target
schedule, possibly involving contractual deadlines and agreed appointment
times. For example, a telecommunication installation may have a contractual
deadline and a separate field appointment time window agreed with the
customer. At least the following schedule information may be relevant.
- Contractual
deadline and earliest allowed starting time
- Planned
start and end time (Note 6)
- Estimated
duration (Note 6)
- Agreed
start and end time of field appointment
Note 6: As determined by work planning and scheduling system
Origin: UC1-4
6.2.3.2 Peer work progress awareness
FFMII interface SHALL offer means to declare and indicate
progress of Activities handled by other Assignees (peers) in the context of a
single Work Request.
Rationale: Awareness of Peer work progress is
instrumental in certain contexts. For example, in telecom area, an Activity
assigned to a single person or service provider may be closely related to
Activities assigned to other persons or service providers. It is therefore
essential for an Assignee to be aware of progress of Peers’ related work.
Consequently, the FFMII interface shall offer necessary concepts for Peer
identity and activity status propagation.
Origin: UC3
6.2.3.3 Local Work Request data updates based on input
data or user actions
FFMII SHALL provide means to declare operations that enable
Work Request instance data updates inside of Implementation as a result of
state transitions on activity level without direct involvement of Manager.
Rationale: Support for locally performed data updates
is necessary in certain situations where user experience would otherwise be
impacted by round-trips between Implementation and Manager. For example,
submitting a new comment should update the change log immediately rather than
being “post-updated” by manager later on. Similarly, it might be required that
a specific data element is locked (becomes read-only) immediately upon
particular state transition initiated by the user.
Origin: BR/User Experience, UC2
FFMII interface SHALL support concept of Work Request
history capturing each state transition and user input that occurs during
Work Request implementation. Work Request history SHALL be made available for
retrieval by Manager without any additional post-processing.
Rationale: Activity is a set of Steps and associated
data. As the Assignee proceeds from one Step to another, each transition needs
to be recorded, as well as any submitted input data. It is then up to the
Manager to interpret the transition between each Step. Collection of all
Activity level history data forms Work Request history, which is the ultimate
evidence of how the Assignee has performed the requested unit of work.
Origin: UC-All
6.2.4.2 Work Request Status Evaluation and Reporting
FFMII Interface SHALL includes a concept of overall Work
Request status complementing the detailed Work Request history as discussed in
Section 6.2.4.1.
Work Request status SHALL be derived from the current state
of underlying Activities using a fixed set of rules and can therefore be
consistently evaluated by both Manager and Implementation. The status information
SHALL be exposed to Manager for retrieval and filtering purposes. Same
information may also be leveraged by Implementation for, for example,
visualization purposes.
The overall Work Request status is described using Status
Categories. The same Status Categories are also used on Activity level.
The following Status Categories SHALL be used:
- New (i.e. Assignee has not
started working yet)
- Active (i.e. Assignee is
actively pursuing the work in question)
- Inactive (i.e. Assignee has
started work but is not actively working now)
- Closed (i.e. work is of no
relevance to Assignee anymore)
NOTE: The overall Work Request status on FFMII level does
not necessarily have to be the same as the status value shown to users of the
related systems. For example, the Manager MAY maintain much more fine grained
status based on the work history.
FFMII specification SHALL also define a set of predefined
more detailed Status values, each of which belongs to one Status Category. The
detailed Status values MAY be optionally used in the workflow specification to
give a more detailed generic classification of a particular Activity State or
Work Request closing state.
Rationale:
In some use cases it may be sufficient for the Manager to
act solely based on the high level status of the Work Request. For example,
waste collection task may only involve acknowledgement of completion.
Furthermore, even if full Work Request history is used for reporting purposes,
the high level status may be sufficient to trigger related business process and
tasks flows on ERMS level.
Additionally, it is also important to establish a common,
consistent understanding between Manager and Implementation about the current
overall state of a Work Request and the contained Activities to avoid
misunderstandings between parties responsible for work planning and delivery.
This requires a set of common predefined high level Status Categories, layered
on top of the detailed dynamically specified Activity state model. Predefined
vocabulary is also needed to be able to specify fixed set of rules for
determining overall Work Request status.
Origin: UC1, UC4
6.2.4.3 Work Request update conflict indication
FFMII interface SHALL include means to indicate conflicting
updates of Work Request data by Manager and Implementation.
Rationale: Work Request and its status form a shared
data element jointly managed by the Implementation (Work Request handling
party) through user actions, and Manager (Work Request initiating party). Both
entities may initiate changes to any part of the status data independently of
each other. In order to prevent loss of information, means of conflict
indication are required for making each entity aware of changes made by the
other.
Origin: BR/Conflict indication
FFMII interface SHALL provide means for deploying and remote
maintenance of custom catalogs on Implementation side containing data entities
that Work Requests refer to or may use as source of input data.
Custom Data Repositories feature provides a generic concept
of repositories for storing arbitrary data. Custom Data Repositories are
provided through normalized, content agnostic data exchange interfaces.
Deployed data can be referred to as valid work request input values, or as a
source of display information (e.g. “user manual for device XYZ”). The link
between Work Request and its reference data is managed autonomously by the
Implementation without Manager’s involvement.
Rationale: More complex Work Requests may rely on a
number of common background registries of static data, such as product
catalogs, code sets, and large attachments (e.g. user manual library, site
drawings). While master databases of such information typically reside outside
of the FFMII Implementation, for practical reasons it is beneficial to provide
copies of such data for Implementation use.
This approach, denoted as “Reference Data Management”, has
the following advantages:
- reduction
of work request size by not having to repeatedly in-line entire catalogs
- ability
of the Implementation to forward the data further internally, or handle in
any other way if beneficial from user experience point of view
- ability
to guarantee adequate user experience even in presence of connectivity
issues between Manager and Implementation
- allows
for potential background data repositories to implement data
synchronization independently from Work Request Management
- possibility
for the Implementation provider to supply own value-add content (catalogs
of independently obtained data) for inclusion as part of work request
through managed references
Origin: UC2 (one of implementation options for
“resolution codes”), UC4 (technical drawings of major water distribution
points)
FFMII interface SHALL provide means for the Implementation
and Manager to identify itself and the version of the interface it supports.
The system itself MAY also expose additional information identifying the vendor
and product.
Rationale: Exposure of system identity and interface
version is a pre-requisite for establishing trusted reliable link between
Manager and Implementation.
Furthermore, by indicating the vendor and product
information, the system MAY, at its sole discretion, take into use certain
mutually known features or extensions that are not part of the FFMII interface
specification.
Origin: UC-All, BD/Adaptability
FFMII interface SHALL provide means by which Implementation
and Manager are able to indicate in fine-grained level what features of the
overall FFMII specification they support, including related properties
accompanying such features.
Rationale: All features of the FFMII interface are
not necessarily required in all deployment contexts. A Implementation and
Manager shall be able to verify that the features required in a particular
context are available by examining capability descriptors exposed by the other
system. Capability descriptors also enable an Implementation and Manager to
remain formally compliant with the specification without implementing all
features of the FFMII interface.
Origin: BR/Ease of Adoption, BD/Fit for purpose
FFMII interface SHALL provide means of retrieving and
updating Assignee information on Implementation side to the Manager.
Rationale: Assignee identification data must be
defined and synchronized between Manager and Implementation, in order to
eliminate risk of technical faults due to Assignee data not being consistently
defined on Manager and Implementation side. Optionally, this may involve
additional information about user preferences and device profiles, if managed
outside the Implementation.
Origin: BR/Ease of Adoption, BD/Cutting integration
costs
FFMII interface SHALL provide means for FFMS to report an
unplanned Assignee absence. The absence notification SHALL include at least
date and time of start and end of absence, as well as reasons for the absence.
FFMII SHALL enable canceling or modifying such notifications at a later time.
FFMII SHALL enable appropriately authorized users to add or change absence
notifications on behalf of the absent user.
Rationale: Unplanned absences occur often in any
workforce. The sooner that the absence is reported, the easier it becomes to
rearrange the schedule accordingly
Origin: UC7
FFMII interface SHALL require Manager to authenticate itself
when accessing Implementation, and vice versa.
Rationale: Field Work is a critical part of a
business process and involves confidential data, such as customer details. The
Manager and the Implementation must be able to establish mutual trust.
Furthermore, multiple Managers may be using the same Implementation with
different levels of authorization. Therefore, protocol bindings should offer
mechanisms for mutual identification and authentication, especially when using
un-trusted networks, such as the Internet, for connectivity.
Origin: BR/Security
FFMII interface SHALL provide means to ensure integrity and
confidentiality of the data exchanged between Manager and Implementation.
Rationale: Work Request MAY contain information that,
if modified in a non-authorized way or disclosed, MAY have negative
consequences from business or legal compliancy point of view. To be able to use
un-trusted networks, such as the Internet, the protocol bindings SHOULD support
transports that are able to guarantee data integrity and confidentiality.
Origin: BR/Security
In order to promote inter-working of software systems over
Internet or other types of IP networks, at least one of the protocol bindings
must support HTTP/HTTPS protocols as possible transports.
Rationale: HTTP/HTTPS are proven de-facto standards
for scalable communication in Internet context
Origin: BR/Ease of Adoption
FFMII interface SHALL allow bypassing transport-level
security when the deployment environment is known to be secured by other means,
or the integration does not carry data requiring protection.
Rationale: In case of strongly isolated, protected
networks, an additional layer of transport level security is unnecessary, and
might need to be disabled in order to preserve computational resources on
Manager or Implementation side.
Origin: BR/Fast Prototyping, BR/Minimal assumptions
regarding the deployment environment
The following individuals have participated in the creation
of this specification and are gratefully acknowledged:
Participants:
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.
|
Revision
|
Date
|
Editor
|
Changes Made
|
|
01
|
21 July, 2011
|
Thinh Nguyenphu
|
Initial draft based on --- FFMIIBusinessUseCasesFeatures20110628-D.docx
Use case 5,6, and 7 of
FFMIIBusinessUseCasesFeatures20110627-D - IB comments, 6-Jul-11.docx
|
|
01
|
25 July, 2011
|
Thinh Nguyenphu
|
Resolved comments in section 6.4.3
|
|
01
|
18 August, 2011
|
Thinh Nguyenphu
|
Based on FFMII-BusinessUseCasesFeaturesREQ-v1.0-wd01-07252011
following discussion of 16-Aug-11.docx
|
|
01
|
22 August, 2011
|
Thinh Nguyenphu
|
Input from
http://www.oasis-open.org/apps/org/workgroup/ffm/email/archives/201108/msg00016.html
|
|
01
|
05 September, 2011
|
Thinh Nguyenphu
|
Editorial clean up based on September 05, 2011 conference
call
|
|
01
|
09 September, 2011
|
Thinh Nguyenphu
|
Editorial clean up and updated Appendix A
|
|
01
|
12 September 2011
|
Thinh Nguyenphu
|
Editorial and technical clean up in all sections
|
|
02
|
19 January 2012
|
Thinh Nguyenphu
|
HeavyMachineryServiceUseCase 02-online-edited
|
|
03
|
28 February 2012
|
Thinh Nguyenphu
|
Editorial clean up Section 3.2 and 3.3
|
|
04
|
29 February 2012
|
Thinh Nguyenphu
|
Fix [FFMII-SPEC] reference
|
