FAQ

1. What is Field Force Management?

   Field Service Management (FSM), also known as Field Force Automation (FFA), is an attempt to optimize processes and information needed by companies who send technicians or staff "into the field" (or out of the office.) Optimization is difficult, since it involves intelligent scheduling and dispatching of multiple technicians to different locations daily, while minimizing cost and maintaining good customer service. [Wikipedia]

   Field Force Management (FFM) focuses on accurate and reliable communication towards the field force using an appropriate means of communication, such as browser-based Web UIs, on-device client software, SMS/MMS messaging, IVR and other. Managing field force using one or even several of these "channels" includes both, delivery of work requests to field as well as status updates and data reported back from the field. FFM may act as a field-communication subsystem from FSM point of view, however it may be also applicable as a standalone application or in other contexts.

   The term "Field Work" in the context of FFM TC work refers to unit of work that is expected to be conducted by individual (or group of closely co-operating individuals) without need for strong supervisory guidance at each step. Specification of such unit of work contains sufficient amount of information necessary for accomplishing expected activity in self-guided way, within expected time window and resulting into 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.

   Additionally, 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).

   Due to upper level systems having functional dependencies on FFM provided capabilities, flexible FFM implementations should take into account certain concepts of work planning domains (such as the FSM domain). In this respect, FFM implementation should recognize, and to a degree support, concepts such as scheduling, dependency management and work load optimization, although separation of roles and concerns should still be maintained between tools and systems forming the end-2-end chain.

2. What is the goal of the OASIS FFM TC?

   The FFM TC aims to specify a generic, vendor neutral interface (or a set of interfaces) for the relay of field work requests and certain types of bi-directional interactions, between work planning entities and the systems responsible for reliable delivery to the associated field force.

3. What problem does the FFM TC address?

   Integration of Field Force Management system(s) into the surrounding IT environment of users (e.g. field service business) has proven to be a time-consuming, complex issue resulting in long project lead times, unexpected additional costs, and even the loss of momentum in transformation of operation practices.

   There are at least three fundamental reasons for that:

   • Lack of layered approach in overall solution design (systems and their roles)
   • Integration interfaces designed around a limited set of static use cases implying major changes to already deployed systems (in turn causing further delays and costs)
   • Variation in business requirements, typical to field service value chains, especially regarding data content and processes

   The FFM TC addresses these challenges by delivering a generalized view into FFM integration issues, including concept materials as well as interface specifications.

4. What does the OASIS FFM TC do?

   The main deliverable is the Field Force Management Integration Interface (FFMII) as defined in the "normative deliverables section" of the TC charter. The TC will also produce a number of non-normative, supplementary documents designed to ease adoption of the interface.

5. Why is a FFM standard needed?

   Efficient and flexible integration between work planning systems and field force management systems is complex. The challenge is often underestimated. The primary driver for the OASIS FFM standardization effort is the need to broaden awareness as well as support of a more pragmatic approach through concrete interface specifications.

   At the same time, it is of utmost importance to create fair, balanced environment where each party involved is capable of deriving its own strategy for business growth, while cooperating with others in joint projects.

6. Who will benefit from FFM and how?

   Through FFM TC efforts, we envision an ecosystem of interoperable software solutions, whereby the investing party (the user) is able to make choices based on their actual needs and constraints on component and layer level, rather than having to satisfy themselves with tightly integrated vertical solutions with customization efforts applied on top.

   Another group of FFM benefactors are the ISVs, system and software architects, and application service providers who will gain from access to specifications and concepts resulting from industry-wide discussion among experts in the field.

7. How does this work compare with related standards efforts?

   There exists several standards efforts for exchange of order information, such as OASIS UBL and RosettaNet. Delivery processes associated with field work and field service businesses, on the other hand, have more variation than the typical ordering process.

   It is not just differences between business segments (telecom, utility, medical, goods shipping, and others) that pose challenges for software systems, but also variations among businesses within segments, and even individual field request levels as well. The following aspects, not common in cases of ordering type on interfaces, can be identified:

   • need to relay concise yet comprehensive work details for removing any unessential burden from field personnel
   • rich communication patterns between field personnel and their managing authorities (including field-initiated interactions)
   • need to support field requests with possibly significant differences in terms of their structural complexity (from single-click surveys to complex, tightly followed multi-step operations)
   • rich media attachments

   The work of other industry efforts, including other OASIS TCs, may be applicable, for example in the following areas:

   • XML (W3C) as way of data serialization for exchange
   • WebServices (W3C) as one of applicable protocol binding
   • xCal (IETF) for serialization of scheduling information
   • WS-Calendar (OASIS) as guideline for exchange of schedule information
8. Who should be involved in the OASIS FFM TC?

   All interested parties are welcome to participate. The TC especially invites representatives among ISVs, software and system architects, application service providers, and field force management system users to engage in this standardization effort.

9. Where will this technology be used?

   FFMII interface, the main delivery of FFM TC, will represent the contract between work planning and field force management systems. It will enable efficient deployment of complying software solutions to create a Field Force Management solution.

10. Where should vendors be using this technology?

    Interested vendors, particularly those active in work planning and field force communication domain, have an opportunity to introduce FFMII compatible external interfaces as part of their software products.