1 / 15

FFMII Introduction Juha Tiihonen

FFMII Introduction Juha Tiihonen. Refer to FFMII Specification for details and explanations. Basic FFMII terminology. Field Work

arella
Download Presentation

FFMII Introduction Juha Tiihonen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FFMII IntroductionJuha Tiihonen Refer to FFMII Specification for details and explanations

  2. Basic FFMII terminology 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

  3. 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. 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 Rossum, NSN, ClickSoftware Technologies, Aalto, Newelo, Pajat Management

  4. Multi-paradigm integration topology (example) Flexible integration topologies Manager Manager Shared field force Distributedwork realization • 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 Implementation Implementation Implementation

  5. Domain Model (main topics of FFMII ) FFMII Domain Model Task Work Request Work Type Specification Activity Step State Data Form Assignee Schedule Action Dependency Work Request Status Change Notification Topical Notification Topical Inquiry Work Request Status Record Field Initiated Request Reference Data

  6. Domain model with more details 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.

  7. Work type Specification structure A Work Type Specification (WTS) describes content and structure of a Work Request

  8. Relationship of Steps, Actions and States within an Activity 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. Action: Transition to OnSite Action: Replace Action: Repair Action: Transition to X-Finalize Action: Transition to X-Finalize Action: Transition to Completed

  9. Example: Activity State Model with Dependencies 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”.

  10. Data forms 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.

  11. Data Element Specification • Data Element Specification is an abstraction that supports a common set of attributes for all sub-classes of Data Element Specifications

  12. 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

  13. Work Request Status Record 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

  14. 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. Reference Data

  15. 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. Field-Initiated Request

More Related