OASIS Field Force Management (FFM) Technical Committee

The official charter for this Technical Committee is provided below. (For additional information, see the Call for Participation that was issued when this TC was formed.)

  1. Name of the TC:

    OASIS Field Force Management (FFM) Technical Committee

  2. Statement of Purpose:

    Enterprises that deploy large field staffs to deliver services to their customers face a host of data use and integration challenges. As the on-site representatives of the enterprise, their field force serve as remote nodes for the entire organization, offering and delivering services, delivering information, committing the enterprise to future actions, and so on. Each of those "field work" operations may touch multiple central data stores, including:

    • the contact data in a CRM,
    • job ticketing (task tracking and completion) systems,
    • the enterprises's inventory and accounting systems, whether integrated into an ERP system or not,
    • records of completed installations, for purposes of product life cycle service and future customer relationship purposes,
    • sales, management and human resources systems tracking the field agents, and so on.

    In addition to the challenge of connecting and coordinating multiple enterprise data systems, field force management also heavily depends on the ability to carry data across to the field staff, who often are at the other end of loosely-coupled, heterogeneous networks composed of many disparate nodes. The devices expected to work together and share meaningful data include mobile phones (enterprise and personal), smartphones, personal PIMs, laptops, company mainframes, and other special purpose devices, and are used in a highly mobile fashion requiring robust abilities to represent and reuse location data.

    The term "Field Work" in this context refers to a unit of work that is expected to be conducted by an individual (or group of closely co-operating individuals) without need for strong supervisory guidance at each step. Specification of such units of work contains sufficient amount of information necessary for accomplishing expected activity in self-guided way, within the expected time window and resulting in the desired outcome. Such a task may be completely independent of other activities, or be part of a larger project where number of activities are planned for and scheduled in relation to each other.

    In the context of FFM TC effort, field work is not limited to particular industry segment or activity type. For example, field works in telecom, utility, facility maintenance, community services, construction, and others would be valid subject for FFM TC effort, as well as certain types of activities regardless of business segment (e.g. sales or field surveys).

    The FFM TC will develop an integration interface that can be used between systems responsible for work planning and systems responsible for field request communication towards the addressable field force. In such scenario, a standardized, semantically rich and problem-domain-neutral interface is required. In order to enable fast delivery of fully integrated software solutions addressing the needs of both types of system.

    Due to fast-changing business requirements typical for field service value chains that interface should be able to accommodate desired changes in content and interaction patterns without need for extensive customization of already deployed systems. The common data structures must be capable of rapid, flexible revision and extension, without disruption, to maintain the systems' ability to faithfully represent changes in business models, plans, and support structures.

  3. Scope of work of the TC:

    The TC will specify a generic, extensible, vendor-neutral integration interface, based on open standards, for relaying field work requests between one or more work planning and one or more field communication systems. Principal use cases for the interface include:

    • field work request dispatching (including request updates and cancellations), and
    • collection of status and input data from the field in a reliable and scalable manner.

    The TC may identify additional use cases for inclusion.

    The FFM interface shall specify at least one protocol bindings. And the TC may specify bindings (or provide guidance) for use of multiple alternative protocols, such as a variety of messaging systems or formats, or different degrees of information security.

    Out of scope:

    The FFM TC will not address implementation aspects of the systems generating field work requests, nor of the systems accepting and making those available to field personnel. FFM's projects is to provide an interface and data specifications permitting those two classes of black box to interoperate, generally without perturbing the behaviors inside those boxes. However, the protocol bindings, shared data models, and related interface requirements that the FFM Interface provides may impose some requirements on systems that employ it.

    Testing materials are out of scope. This TC shall not develop FFMII conformance test suite materials (other than the conformance clauses as may be required within a specification), nor conformance certification methods for implementations of the issued specifications. For these and similar activities, a parallel Adoption Committee may be considered for creation at a later time, if deemed desirable.

  4. List of deliverables:

    The FFM TC plans to produce several related deliverables within both the OASIS Standards Track and Non-Standards Track.

    Standards Track Deliverables:

    • Field Force Management Integration Interface (FFMII) specification (primary base specification), which may be one or several related specifications as the TC deems desirable. The FFMMI may include one or more formal taxonomies or code lists for the compact and efficient re-use of recurring information. [[9] months from the first meeting.]
    • Such FFMII related technical artifacts (e.g., data models and machine-readable API) as the TC deems desirable.

    Non-Standards Track Deliverables:

    • FFMII non-technical overview. [[9] months from the first meeting]
    • FFMII business drivers and design goals statements. [[9] months from the first meeting.]
    • Use case scenarios and exemplar models. [[9] months from the first meeting.]

    The TC's deliverables shall re-use and leverage existing open data standards and architectures where possible.

  5. IPR Mode under which the TC will operate:

    RF on Limited Terms Mode.

  6. The anticipated audience or users of the work:

    The anticipated audience for TC deliverables produced within the OASIS Standards Track includes independent software vendors (ISVs) active in the area of work planning systems and in field communication systems. Similarly, systems integrators focusing on delivery of integrated and coherent model-driven solutions for respective customers will be candidates for using the standardized technology.

    The anticipated audience for TC deliverables produced within the OASIS Non-Standards Track is business entities conducting field activities and seeking guarantees of interoperability between systems. Such businesses typically need to address different aspects of field operations and to support interaction between disparate systems.

    Industry strategists, independent consultants, and device designers may benefit from the results of the FFM TC's work as well.

  7. Language of the Technical Committee:

    The business of the Technical Committee will be conducted in English.