Attach_1_IROC_Story_Board_Personas_and_BPM.pdf

Interagency Resource Ordering Capability (IROC)

0 | P a g e

Interagency Resource Ordering Capability

(IROC)

Story Boards (Personas) and Business Process Models (BPM)

1 | P a g e

Revision History

Date

Version / Description

Approved By

Comments

February 7, 2015 V 0.1: Initial Annette Box and

Tina Vorbeck, US Forest Service

March 13, 2015 V 0.2:

Revised

Annette Box and

April 2, 2015 V 0.3:

Revised

Annette Box and

April 23, 2015 V 1.0:

Final

2 | P a g e

Table of Contents Revision History

Vision and Approach

Scope

Introduction

Story Boards (Personas)

Story Boards by Personas

Story Board (Personas) Overview

Oscar Orderer Persona

Oscar Orderer Story Board

Debbie Decision Maker Persona

Debbie Decision Maker Story Board

Ralph Responder Persona

Ralph Responder Story Board

Annie Analyst Persona

Annie Analyst Story Board

Sam Support Persona

Sam Support Story Board

Business Process Models (BPM)

BPM Narratives

Create Order:

Assign Resources:

Arrive:

Deal With the Incident:

Replenish (optional):

Release Resource:

Depart:

BPM Diagrams

Overview Future Resource Order Management

Other Scenarios

Appendix A: Summary of ROSS 3.0 Documentation Evaluation

Appendix B: List of Acronyms

Appendix C: Revision 0.1 Detailed Response

3 | P a g e

Vision and Approach

The Interagency Resource Ordering Capability (IROC) will provide updated, reliable, and automated capabilities to reduce duplication, increase efficiency, and effectively order, manage, track, analyze and report on resources associated with interagency wildland fire and all hazard incidents throughout their complete lifecycle.

The management of resources is vital to this community’s ability to expedite and efficiently manage the execution of ordering for fire and all hazard incidents. The ordering of resources to supply an incident is just a variation of a supply chain management model. All supply chain models share a set of common characteristics to reduce costs, decrease risks, and increase efficiency through technological innovation.

Digital technology can be used to enhance an existing business process, model or methodology, while allowing an opportunity to wholly reimagine the way to think about and operate your supply chain. There are four distinct advantages associated with virtually every digital supply network: connected, intelligent, rapid, and scalable.

A digital supply network represents much more than the widespread application of technology. The difference lies in the changing nature of supply chain management. Simply put, the supply chain is evolving from a function concerned with the expedient movement of materials to a discipline whose mission is the concurrent optimization of resources, overhead, information and finances. Thus the key is re-inventing the supply chain itself, thinking differently about how to concurrently move and optimize people, information and finances, as well as equipment, supplies, and contracted resources.

Supply chain business process integration involves collaborative work between dispatchers and resources, common systems, and shared information. Supply Chain Management ensures the right product assortment and quantity are delivered in a timely fashion. Envision a process that connects all supply chain functions, including resource sourcing, order management, receiving, and payables to optimize productivity with workflow-enabled automation and self-service capabilities.

Gathering and agreeing on requirements is fundamental and critical to a successful software development project. Also critical to successful software development is that the Business Requirements focus on the “What” of vision:

What does this application do?

What are the workflows?

What are the Personas (Use Cases and Roles)?

What are the major features?

It is helpful in building Requirements to use the 80/20 rule. Specifically, by targeting the major use cases and functionality that will be used 80% or more of the time, provides priority guidelines and ensures the highest volume use cases are addressed. The exceptions will be recognized and included in the next phase of the software development project.

4 | P a g e

The approach taken to gather business requirements and identify user specific needs included:

Interviews conducted with over 150 Stakeholders including, but not limited to, Executives, GACC Coordinators, Dispatchers, Cache Personnel, Subject Matter Experts, Buyers, Data Warehouse Personnel, and State Compact Representatives.

Online request for feedback was sent to over 14,000 ROSS users with excellent response rate over the 4 week period:

o Overall more than 20% response rate.

o Of the 2,732 responses, 58% were Active users.

Conducted review on the existing 3.0 documentation with priority given to areas where there were gaps.

5 | P a g e

Scope

The purpose of the Interagency Resource Ordering Capability (IROC) is to enable effective management of an incident and the ordering of resources needed for managing the incident. Throughout the life of an incident, including after it is over, real time reporting is needed to produce a complete and accurate view of events associated with an incident.

The goal of IROC is very simple: to expedite and manage the execution of incident ordering.

In Scope for the IROC deliverables (Personas, Story boards, Business Process Models, Solutions Requirements Specification, and Logical Data Model):

Define Personas and Story Boards (high-level uses cases).

Document the highest priority (80%+ usage) workflows and functionality that include, but are not limited to:

o Identification of steps that are truly required to create, fulfill and track an order.

Incident Ordering and Fulfillment Management includes; Entry, Editing, Output, Historical, Search, and Security.

Incident Resource Management includes; Entry, Editing, Statusing, Historical, Search, and Security.

o Auto-logging of events with date/timestamps, username, etc.

o Auto-notification of events.

o Providing the capability to capture actual date/timestamps for specific events such as resource arrival at incident.

Providing the capability to pull reports, both canned and custom.

Document the Non-Functional requirements in support of:

o “Supporting Processes” o Documentation, Training o Ease of Use, Web-based

6 | P a g e

Introduction

Implementing the Interagency Resource Ordering Capability (IROC) will achieve increased operational effectiveness and efficiencies in business processes via an updated supply chain solution. The new system will support current business needs and allow for long-term future growth.

Interagency Resource Ordering Capability (IROC) will provide the interagency wildland fire community with a modern incident resource management system that will benefit users in the following ways:

Provide the community with the ability to expedite and efficiently manage the execution of incident ordering.

Provide a single user interface regardless of organizational membership or computer system used.

Provide the ability to enter resource orders and general messages across the business including dispatch centers and fire camps where the data originates.

Provide "real-time" availability of resource throughout the nation.

Provide system intelligence to aid in mobilizing resources (e.g., calculations and recommendations on the most cost effective assets to mobilize).

Provide a complete view of an incident throughout its complete lifecycle; initial attack through disposition of final resources.

Provide a complete view of a resource throughout its complete lifecycle; set-up, pre-positioning through returning “home”.

Provide timely and accurate information to the interagency wildland fire management community.

Eliminate the need to manually enter initial attack (CAD) information.

IROC is intended to increase access to accurate, reliable, and timely data for enhanced decision-making and planning capabilities. Investigate and improve all processes affected by the IROC project resulting in fewer errors, reduced business risk and cost savings. Provide executives, users, and resources with direct access to appropriate information to meet state and federal reporting requirements.

The vision for IROC is a technical environment that is always available, secure, highly responsive, flexible in configuration, easy to maintain, enhance, and upgrade, and, above all, one that provides the information and analysis tools to support the user in fulfilling the mission and goals of the agencies.

Multiple entities support Wildland fire management, suppression, information dissemination, and planning for future fires. Stakeholders interviewed from these entities expressed that both the Future Resource Management Tool and Reference Data Management Tool must provide an integrated solution to the many information systems currently used to support the collection and reporting, decision support, planning, and financial management of Wildland fire incident information.

7 | P a g e

Story Boards (Personas)

Story Boards are an important tool to graphically represent use cases or workflows. Story Boards are helpful in many ways, including, but not limited to:

Graphically documenting high-level use cases / workflows.

Getting agreement / corrections from end-users on the steps of a use case.

Providing a non-technical view of what can be expected in a new application.

The Story Boards provided in this deliverable are intended to provide a high-level, “Happy Path” view of what is needed in a new Future Resource Management Tool.

An overview of the full Story Boards is provided on the next page, followed by breakdown by Personas. For the six major process areas, a description of each persona and whether they have an active or passive role in the process is included.

8 | P a g e

Story Boards by Personas

Story Board (Personas) Overview

Oscar Orderer

These Story Boards can be read/viewed:

Left-to-Right for Persona workflow

Vertically to show each Persona’s activity during a major step in the process

Identifying Active/Passive Roles:

Personas that have an Active Role in a step are shown on the Left side of the panel and the text boxes have a light green background.

Personas that have a Passive Role in a step are shown on the Right side of the panel and do not have a light green background on the text boxes.

9 | P a g e

Oscar Orderer Persona

GOALS:

Order, assign, mobilize, replenish, release and demobilize resources to incidents.

Provide resources (aircraft, crew, equipment, overhead, and supplies) in the most timely and cost effective manner.

TASKS / MOTIVATION:

Provide timely delivery of resources to incidents.

Adhere to established policies for ordering, use and release of resources.

Receive and process orders for all area command functions.

Process resource orders for inventoried and non-inventoried resources.

REQUESTED FEATURES:

Visibility to reassigned resources.

Real-time visibility to all resources available or committed to an incident.

Oscar Orderer (person and/or system)

Tier 3

Tier 2

Buyer

Cache

Oscar Orderer represents multiple roles that can be filled by a person (i.e. dispatcher, buyer, cache personnel) or by automated system logic.

10 | P a g e

Oscar Orderer: Tier 3

Profile

Been a local dispatcher for 5 years.

I was apprehensive using legacy ROSS since I only used it for expanded incidents.

In the new system, I have visibility to resources reassigned at the Tier 2/GACC level but report to this area dispatch.

Scenario

Our dispatch center only used ROSS for expanded incidents that are escalated to the Tier 2/GACC. The new system resource recommendations make placing orders much quicker. I no longer have to ask for help when I need to place orders or run reports.

Oscar Orderer: Tier 2

Currently at the GACC for about a year, but have worked in local dispatch for 8 years.

I was comfortable using legacy ROSS but it took a long time to learn.

In the new system, I have the ability to view the order(s) with status and resources for all of the tier 3 agencies under our region.

Scenario

Prior to the new system, we had to call local dispatch(s) to get a list of all available resources daily. Now with real-time status and notification, I no longer need to call the agency(s) to see if they received orders or if the resources are still available.

11 | P a g e

Oscar Orderer: Buyer

Working as a buyer for the last 3 years with the Forest Service.

I never worked in legacy ROSS since I received faxed resource orders created by expanded dispatch.

In the new system, I get the orders directly without the delay of dispatchers processing the requests.

Scenario

Prior to the new system, we recorded all daily purchases in a spreadsheet then had to send it to the incident management team to track the full cost of the fire, and dispatch to close ROSS orders. In the new system, all orders are closed once received at the incident and now a simple system report can pull all costs associated with an incident.

Oscar Orderer: Cache

Currently at the Cache for about 2 years, but worked in a retail distribution center previously.

I only used legacy ROSS to verify that orders for my cache are correct in the ICBSR system.

In the new system, we no longer have problems with incorrect orders since the catalog with pack size is now visible to the person placing the order.

Scenario

Previously, we faxed shipment information to dispatch to track and close ROSS orders which did not always happen during fire season. In the new system, shipment and tracking notifications are sent to the incident and all orders are automatically closed once received at the incident.

12 | P a g e

Oscar Orderer Story Board

Oscar Orderer Create Order

Active Role in Create Order.

It is possible for this to be an automated process or through a buyer or dispatch type role.

A Resource Order is in support of a specific incident. Therefore, an incident must be created prior to the Resource Order being created. Creating an Incident is an automated process based on the assumption that incident information is coming from an external system (i.e. integrated CAD).

13 | P a g e

Oscar Orderer Assign/Mobilize

Active Role in Assign/Mobilize.

It is possible for this to be an automated process or through a cache fulfillment or dispatch type role.

14 | P a g e

Oscar Orderer In Process/Arrive

Passive Role for In Process/Arrive.

It is possible for this to be an automated process or through a buyer or dispatch type role.

15 | P a g e

Oscar Orderer Incident/Replenish

Passive Role in Incident/Replenish.

If need to create a replenishment or new order, process goes back to Create Order step.

16 | P a g e

Oscar Orderer Release/Demobilize

Active Role in Release/Demobilize.

17 | P a g e

Oscar Orderer Reporting

Active Role in Reporting.

18 | P a g e

Debbie Decision Maker Persona

Develop and identify strategy and tactics to commensurate with resources, incident objectives, and safety considerations.

Provide tactical and strategic leadership.

TASKS / MOTIVATION:

Review real-time and historical reporting on all incidents for predictive modeling and future planning for coming season.

Create and disseminate policy to ensure the most efficient and safe way to handle incidents.

Validate kind, type, and number of resources required to achieve incident objectives to provide guidance for exceptions and issues.

REQUESTED FEATURES:

Real-time visibility of all resource availability and qualifications.

Easy and consistent access to full high-level view to all incidents from birth to death of an incident.

Debbie Decision Maker (person and/or logic)

Strategic

Tactical

Debbie Decision Maker represents multiple roles that can be filled by a person (i.e. incident supervisor, director, or stakeholder) or by automated system logic.

19 | P a g e

Debbie Decision Maker: Strategic

Director at the NICC for 3 years. Worked in dispatch, and in various leadership roles for about 20 years previously.

I do not log into legacy ROSS because I find it difficult to navigate. Mostly, I use reports requested from the Intel group.

In the new system, I have the ability to quickly run the reports needed for strategic planning without having to ask.

Scenario

Previously, there was no single system that could give me all the information associated with an incident.

In the new system, I have the ability to view current and historical “global pictures” that account for all the resources from start to end of an incident.

Debbie Decision Maker: Tactical

Assistant Director at the GACC for about 5 years. Worked in dispatch (local and GACC) for about 10 years previously.

I rarely log into legacy ROSS because it does not give me all the information I need. Mostly, I request reports from the Intel group.

In the new system, I have the ability to view real-time status of resources and incidents giving me the ability to make better tactical decisions.

Scenario

Prior to the new system, I was unable to review recommendations for allocation, reassignment and/or demobilization of resources based on availability, status, location, and condition using reference guides to validate resource capabilities, limitations, or governing regulations to quickly identify and respond to exceptions or problems.

20 | P a g e

Debbie Decision Maker Story Board

Debbie Decision Maker Create Order

A Resource Order is in support of a specific incident. Therefore, an incident must be created prior to the Resource Order being created. Creating an Incident is an automated process based on the assumption that

21 | P a g e

Debbie Decision Maker Assign/Mobilize

It is possible for this to be an automated process by following business rules for approvals.

22 | P a g e

Debbie Decision Maker In Process/Arrive

Becomes Active Role if triggered.

23 | P a g e

Debbie Decision Maker Incident/Replenish

Passive Role for Incident/Replenish.

24 | P a g e

Debbie Decision Maker Release/Demobilize

Passive Role for Release/Demobilize.

25 | P a g e

Debbie Decision Maker Reporting

Active Role for Reporting.

26 | P a g e

Ralph Responder Persona

Respond quickly to all assigned incidents.

Quick self-check-in/out to report actual times worked.

TASKS / MOTIVATION:

Inform dispatch of resource status, arrival and departure time.

Provide up to date resource information.

Ensure time is recorded and other relevant documents are completed for resource for payroll or contracted resources.

Close out resource orders and records with appropriate units and times.

REQUESTED FEATURES:

Quick and easy way to self-status from anywhere.

Real time and historic visibility to all activity tied to resource.

Notification of changes to assignment, orders, or travel.

Ralph Responder (person, equipment and/or supply)

Overhead

Equipment

Ralph Responder represents people (i.e.

crews, overhead) and things (i.e. aircraft, equipment, supplies).

27 | P a g e

Ralph Responder: Overhead

Worked on a hot shot crew for 6 years.

I only used legacy ROSS to self-status availability prior to mobilization.

In the new system, the actual time that I arrive or leave an incident is recorded. I also can see my status and incident history.

Scenario

Prior to the new system I would receive calls to get mobilized to an incident sometimes even if I was already at an incident. With the new system I get notified via text or email of my orders including travel and any changes including demobilization orders are sent automatically.

Ralph Responder: Equipment (Bus)

Bus used to carry a crew to incident.

My local dispatcher was notified of my availability and would update it in legacy ROSS.

In the new system, the point of contact for the bus is notified of all orders including travel and any changes including demobilization orders.

Scenario

With the new system the owner can easily status the availability of the bus and check in/out of the incident with his mobile device. If the bus breaks down at an incident it is easy to report that a mechanic is needed or a replacement bus needs to be sent to the incident.

28 | P a g e

Ralph Responder Story Board

Ralph Responder Create Order

Passive Role in Create Order.

29 | P a g e

Ralph Responder Assign/Mobilize

If Overhead or Crews, travels to incident. If Equipment or Supply, is transported to incident.

30 | P a g e

Ralph Responder In Process/Arrive

Active Role for In Process/Arrive.

This could be an automated notification and check-in process.

31 | P a g e

Ralph Responder Incident/Replenish

Active Role for Incident/Replenish. Resource arrival/departure times and how long permitted to be at incident will be tracked in an external system then delivered to new system.

Replenish is optional and based on triggers / clock from the incident, the resources, and inventory, catalog and contract, analysis determines what resources require to be replenished at the incident.

32 | P a g e

Ralph Responder Release/Demobilize

Active Role in Release/Demobilize.

This could be an automated notification and check-out process.

33 | P a g e

Ralph Responder Reporting

34 | P a g e

Annie Analyst Persona

Analyze existing incident data and business rules to make logical resource recommendations for consideration in strategic and tactical decisions.

Anticipate future situations and identify appropriate resource(s) and make recommendations on kind, type, and number of resources required to achieve incident objectives.

TASKS / MOTIVATION:

Determine availability, status and condition of committed and uncommitted resources.

Monitor work constraints for each resource to maximize safe and efficient assignments and demobilization.

Prepare recommendations for allocation, reassignment and/or demobilization of resources.

REQUESTED FEATURES:

Real time and historic visibility to all activity tied to all incidents.

Clearly defined business rules to help logically recommend resources.

Annie Analyst represents multiple roles that can be filled by a person (i.e.

Intel Team Member) or by automated system logic.

35 | P a g e

Annie Analyst

Intel Team Member at the GACC for about 2 years. Worked in dispatch (local and GACC) for about 5 years previously.

I am currently the go to person for legacy ROSS and I run the majority of reports for leadership.

In the new system, I have the ability to view real-time status of resources giving me the ability to quickly identify and respond to exceptions or problems.

Scenario

Prior to the new system, I spent more of my time assembling and formatting reports than analyzing the data to provide to leadership. In the new system, I can subscribe to the data and easily set up the reports I need to view quickly and frequently.

36 | P a g e

Annie Analyst Story Board

Annie Analyst Create Order

This could be an automated process that sets defaults/recommendations based on metrics from past incidents.

A Resource Order is in support of a specific incident. Therefore, an incident must be created prior to the Resource Order being created. Creating an Incident is an automated process based on the assumption that

37 | P a g e

Annie Analyst Assign/Mobilize

Passive Role in Assign/Mobilize.

38 | P a g e

Annie Analyst In Process/Arrive

39 | P a g e

Annie Analyst Incident/Replenish

Active Role for Incident/Replenish.

This could be automated process based on information from past and current incidents.

40 | P a g e

Annie Analyst Release/Demobilize

Passive Role in Release/Demobilize.

41 | P a g e

Annie Analyst Reporting

42 | P a g e

Sam Support Persona

Connectivity to other systems to provide the consistent and timely information from the source of record.

Data management of travel, inventory, catalog, and contract information.

TASKS / MOTIVATION:

Manage flow of data between systems for accurate reporting.

Maintain a data dictionary and source of record for all fields.

Collect and process incident reports and daily fiscal information per agency standard.

Provide reliable and quick access to all data needed.

REQUESTED FEATURES:

Connectivity to partner systems to pull accurate data from the source of record.

Quick retrieval of data for accurate reporting.

Sam Support represents multiple roles at the data and system level.

These are a combination of people (i.e. data stewards) and automated roles.

43 | P a g e

Sam Support

I am a patchwork of data. As new data sources / processes have been identified I have grown to support them.

As more incidents need to be supported performance suffers in legacy ROSS.

With the new system, I no longer have to hold the data I just have to know where to find all the data.

Scenario

Previously, data was entered separately into multiple systems in potentially different formats making it difficult to ensure accuracy. In the new system, I know where the correct data is and there is no duplication of data entry.

44 | P a g e

Sam Support Story Board

Sam Support Create Order

This can be an automated process. Incident/Order tracking starts.

A Resource Order is in support of a specific incident. Therefore, an incident must be created prior to the Resource Order being created. Creating an Incident is an automated process based on the assumption that

45 | P a g e

Sam Support Assign/Mobilize

This can be an automated process. Resource tracking starts.

46 | P a g e

Sam Support In Process/Arrive

Active Role for In Process/Arrive.

This can be an automated process. Clock starts for tracking resource(s) with time limits based on actual arrival time.

47 | P a g e

Sam Support Incident/Replenish

Active Role for Incident/Replenish.

This can be an automated process. Resource tracking continues with automated logging and notifications on-going throughout the incident.

48 | P a g e

Sam Support Release/Demobilize

Active Role for Release/Demobilize.

This can be an automated process. Notifications and tracking of estimated and actual demobilization times.

49 | P a g e

Sam Support Reporting

Active Role for Reporting.

50 | P a g e

Business Process Models (BPM)

BPM Narratives These narratives are written in support of the Interagency Resource Ordering Capability (IROC) Business Process Models (BPM) documented in IROC BPM V2.pdf.

Assumptions:

The documented Resource Order Management BPM is the Happy Path.

o Minimal to no Exceptions called out.

o Minimal to no Alternate Paths called out.

The Happy Path is for Initial Attack.

o Replenish is optional and based on resources needed for an incident over X number of days.

Deviated from modelling standards by identifying major data sources that are being modified and/or added to support the future ordering management process.

o Not all data to support the future ordering management process is being called out explicitly.

o Additional data will be described in the Logical Data Model and more data fields will be uncovered during the design and development phase as other paths are expanded.

Create Order:

A Resource Order is in support of a specific incident. Therefore, an incident must be created prior to the Resource Order being created. Creating an Incident is an automated process based on the assumption that incident information is coming from an external system (i.e. integrated CAD).

The Resource Item recommendations in this process are based on the policy-driven business rules established for what resources are needed. The recommendation is supported by Inventory, Catalog and Contract data, and the specific incident data such as the type of fire, the area, and additional elements.

Resource availability is not evaluated at this time. For example, the recommended resource for this order is 12 cases of Gatorade, at this time what flavor is not an option, once moved to assign resource then we find that a certain flavor is not available to send so we need to choose an alternate.

Final review of the resource order for exceptions can be approved or rejected. Once validated, a pending resource order is created.

51 | P a g e

1. START (Create Order)

2. Create Incident o Actor: Debbie Decision Maker o Assumption: Automated process with incident information coming from integrated CAD.

3. Determine Incident Resource Requirements o Actor: Annie Analyst o Assumption: Resource recommendations by type and area are predetermined by committee pre-season.

o Assumption: Automated suggestion of resources using predictive business rules logic.

4A. Create an Order for a Resource Item o Actor: Oscar Orderer o Assumption: Automated process / system creates order based on the incident resource requirement recommendations.

4B. Check “Supporting Data” i.e. Inventory, Catalog, Contracts o Actor: Sam Support o Assumptions: Automated process / system checks for available resource items by qualifications and/or contracts.

5. Validate Order o Assumption: Automated validation on resource exception/override.

6. Resource Order (Report) o Assumption: Automated creation of resource order.

1-6. Notifications and Logging o Actor: Sam Support o Assumption: Resources automatically notified of orders (i.e. new, changed or cancelled).

o Assumption: Any exceptions / overrides to resource order recommendations are logged.

o Assumption: Automated transaction logging of all add, changes, and deletes to an incident and/or order by user, date and time.

7. END (Create Order)

52 | P a g e

Assign Resources:

The resource order is supported by incident data.

Assigning resources to the incident is based on what was ordered and what is available. Availability is now the main factor as requirements for resources will not change based on what is available. If resources are not available multiple orders requests will be issued to different agencies to fill the needed resource requirements.

Once all available resources are identified for the incident, they will need to be mobilized with travel plans and/or shipment information. Since the resources are now committed to an incident, the inventory, catalog and/or contract availability will be updated in the resource order.

53 | P a g e

1. START (Assign Resource)

2A. Resource Order (Report) o Actor: Annie Analyst o Assumption: Resource order report created from order creation.

2B. Incident Data o Assumption: Tracks any/all incident data including updates.

3A. Assign Resource Item(s) to Incident o Actor: Oscar Orderer o Assumption: A complete order is presented for review/submittal.

3B. Resource Availability o Actor: Ralph Responder o Assumption: Resource has the appropriate qualifications, and is statused as available.

4A. Mobilize Resource Item(s) o Assumption: The notification of mobilization including travel and/or shipment information is automated.

4B. Travel, Inventory, Catalog or Contract o Actor: Sam Support o Assumption: Automatic tracking of updates to

Travel, Inventory, Catalog and Contract data to support the assigned resource item(s).

5. Resource Order (Report) o Assumption: Automated update of resource order.

1-5. Notifications and Logging o Actor: Sam Support o Assumption: Resources automatically notified of orders (i.e. new, changed or cancelled).

o Assumption: Any exceptions / overrides to resource order recommendations are logged.

o Assumption: Automated transaction logging of all

6. END (Assign Resource)

54 | P a g e

Arrive:

The resource order is electronically sent and needs acknowledgement.

Once the resource has arrived at the incident, connectivity is needed to enable check in so the actual time of arrival is recorded on the resource order and update the availability supported by the inventory, catalog and contract.

55 | P a g e

1. START (Arrive)

2A. Acknowledge Order o Actor: Ralph Responder o Assumption: An automated notification of the resource order was electronically delivered.

o Assumption: Ralph has the capability to respond electronically.

2C. Resource Order (Report) o Assumption: Automated update of resource order.

3. Resource at Incident o Assumption: Will notify electronically if delay in original travel estimated time of arrival.

4. Check-In Resource Item o Assumption: Connectivity at incident site.

o Assumption: Capability to check-in electronically.

5A. Resource Availability o Assumption: Automatically updates availability once checked in.

5B. Inventory, Catalog or Contract o Actor: Sam Support o Assumption: Automatic tracking of updates to

Inventory, Catalog and Contract data to support the assigned resource item(s).

1-5. Notifications and Logging o Assumption: Resources automatically notified of orders (i.e. new, changed or cancelled).

o Assumption: Any exceptions / overrides to resource order recommendations are logged.

o Assumption: Automated transaction logging of all

6. END (Arrive)

56 | P a g e

Deal With the Incident:

During the incident both incident and resource are tracked for triggers/ clocks because deal with the incident is an external event in the narrative.

1. START (Deal With the Incident)

2. Clock o Assumption: Connectivity at incident site.

3A. Works at Incident o Assumption: Capability to update timecard electronically.

3B. Incident o Assumption: Tracks any/all incident data including updates.

3C. Incident, Resource (Report) o Assumption: Automated update of incident and resource data.

1-3. Notifications and Logging o Assumption: Resources automatically notified of orders (i.e. new, changed or cancelled).

o Assumption: Any exceptions / overrides to resource order recommendations are logged.

o Assumption: Automated transaction logging of all add, changes, and deletes to an incident and/or order by user, date and time.

4. END (Deal With the Incident)

Replenish (optional):

Replenish is optional but included because research indicates that 80% of the incidents within IROC will need some sort of replenishment of resources before they are closed out. Based on triggers / clock from the incident, the resources, and inventory, catalog and contract, analysis determines what resources require to be replenished at the incident.

The replenish Resource Item recommendations in this process are based on the policy-driven business rules established for what resources are needed. The recommendation is supported by Inventory, Catalog and Contract data, and the specific incident data such as the type of fire, the area, and additional elements.

Resource availability is not evaluated at this time.

Final review of the resource order for exceptions can be approved or rejected. Once validated, a pending resource order is created.

57 | P a g e

1. START (Replenish)

2A. Determine Incident Resource Requirements o Actor: Annie Analyst o Assumption: Resource recommendations by incident and resource availability are predetermined by committee pre-season.

o Assumption: Automated suggestion of resources using predictive business rules logic.

2B. Incident o Actor: Debbie Decision Maker o Assumption: Automated process with updated incident information.

2C. Resource Availability o Actor: Ralph Responder o Assumption: Availability status is timely and accurate.

2D. Check “Supporting Data” i.e. Inventory, Catalog, Contracts o Actor: Sam Support o Assumptions: Automated check for available resource items by qualifications and/or contracts.

3. Create an Order for a Resource Item o Actor: Oscar Orderer o Assumption: Automated order creation based on the incident resource requirement recommendations.

4. Validate Order o Assumption: Automated validation on resource exception/override.

o Assumption: Automated creation of resource order tied to existing incident.

1-5. Notifications and Logging o Actor: Sam Support o Assumption: Resources automatically notified of orders (i.e. new, changed or cancelled).

o Assumption: Any exceptions / overrides to resource order recommendations are logged.

o Assumption: Automated transaction logging of all

6. END (Replenish)

58 | P a g e

Release Resource:

The recommendation to release resource item(s) is supported by updated incident data.

Once the appropriate resources are identified an updated resource order to demobilize the resource with travel plans and/or shipment information. Since the resources are now released from an incident, the inventory, catalog and/or contract availability will be updated in the resource order.

59 | P a g e

1. START (Release

Resource)

2A. Determine Incident Resource Requirements o Actor: Annie Analyst o Assumption: Automated suggestion of resources using predictive business rules logic.

3A. Un-Assign Resource Item(s) to Incident o Assumption: A release order is presented for review/submittal.

3B. Resource Availability o Assumption: Availability status is timely and accurate.

4A. De-Mobilize Resource Item(s) o Assumption: The notification of demobilization including travel and/or shipment information is automated.

4B. Travel, Inventory, Catalog or Contract o Assumption: Automatic tracking of updates to

Travel, Inventory, Catalog and Contract data to support the released resource item(s).

o Assumption: Automated update of resource order.

1-5. Notifications and Logging o Actor: Sam Support o Assumption: Resources automatically notified of orders (i.e. new, changed or cancelled).

o Assumption: Any exceptions / overrides to resource order recommendations are logged.

o Assumption: Automated transaction logging of all

6. END (Release Resource)

60 | P a g e

Depart:

The resource order to depart is electronically sent and needs acknowledgement.

Once the resource has departed from the incident, connectivity is needed to enable check out so the actual time of departure is recorded on the resource order and update the availability supported by the inventory, catalog and contract.

1. START (Depart)

2A. Acknowledge Order o Actor: Ralph Responder o Assumption: An automated notification of the resource order was electronically delivered.

o Assumption: Ralph has the capability to respond electronically.

o Assumption: Tracks any/all incident data including updates.

2C. Resource Order (Report) o Assumption: Automated update of resource order.

3. Check-Out Resource Item o Assumption: Connectivity at incident site.

o Assumption: Capability to check-out electronically.

4A. Resource Availability o Assumption: Automatically updates availability once checked in.

4B. Inventory, Catalog or Contract o Assumption: Automatic tracking of updates to Inventory, Catalog and Contract data to support the departed resource item(s).

1-4. Notifications and Logging o Assumption: Resources automatically notified of orders (i.e. new, changed or cancelled).

o Assumption: Any exceptions / overrides to resource order recommendations are logged.

o Assumption: Automated transaction logging of all add, changes, and deletes to an incident and/or order by user, date and time.

5. END (Depart)

61 | P a g e

BPM Diagrams

Overview Resource Order Management (FUTURE)

Overview Resource Order Management Legend

62 | P a g e

Overview Resource Order Management – “Happy Path”

Resource Order Management – “Happy Path”, Most straight-forward (without integrated CAD)

P er cy P ro cu re m en t

R al p h

R es p o n d er

A n n ie

A n al ys t Sa m S u p p o rt D eb b ie D ec is io n

M ak er

Future State

Create Incident

Create Order for a Resource Item

Assign Resource Item to Incident

Mobilize Resource Item

Resource Order

Un-Assign Resource Item from Incident

Demobilize Resource

End

Clock Resource Order

Check-in Resource Item

Determine Incident Resource

Requirements

Auto-Notification (Add, Change Delete)

Auto-Logging (Add, Change, Delete)

Check-Out Resource Item

Acknowledge Order

Resource at incident

Start

Determine Incident Resource

Requirements

Validate Order

Resource Order

Acknowledge Order

63 | P a g e

Overview Resource Order Management (FUTURE) – “Global View”

Resource Order Management - “Global View” from the Tier 3 perspective, with integrated (Altaris) CAD, with “exhausted” Resources

Ti er

Lo ca

l) A lt ar is C

A D

P er cy P ro cu re m en t

Ti er

G A

C C

P er cy P ro cu re m en t

(O th er

Ti er

O R

T ie r

N

IC

C

P er cy P ro cu re m en t

Ti er

Lo ca

l) “F

R M

T”

R al p h

R es p o n d er

A n n ie

A n al ys t Sa m S u p p o rt D eb b ie D ec is io n

M ak er

Future State

Automated With PUSH

Start Create Incident

Report Call Arrives

Review Incident Report

Incident Type Dispatch Resources Push to “FRMT”

W ild la nd Fi re

Release Resource

Create Incident Create Order for a

Resource Item Assign Resource Item to Incident

Mobilize Resource Item

Create Order for a Resource Item

Place Order

Receive Order

Place Order

Receive Order

UTF

EndClock Clock

Clock Resource Order

UTF

Assign Resource Mobilize Resource

Resource Order

Un-Assign Resource Item from Incident

Demobilize Resource

End

Clock Resource Order

Check-in Resource Item

Check-in Resource Item

Determine Incident Resource

Requirements

Determine Incident Resource

Requirements

Auto-Notification (Add, Change Delete)

Auto-Logging (Add, Change, Delete)

Validate Order

Check-Out Resource Item

Acknowledge Order Acknowledge Order Resource at incident

Resource at

Incident

64 | P a g e

Resource Order Management (FUTURE)

65 | P a g e

Create Order

66 | P a g e

Assign Resource

67 | P a g e

Arrive

68 | P a g e

Deal with the Incident (External Event)

69 | P a g e

Replenish

70 | P a g e

Release Resource

71 | P a g e

Depart

72 | P a g e

Create Incident, Other Major Functionality

73 | P a g e

Create Order, Other Major Functionality

74 | P a g e

Assign Resource, Other Major Functionality

75 | P a g e

Arrive, Other Major Functionality

76 | P a g e

Replenish, Other Major Functionality

77 | P a g e

Release Resource, Other Major Functionality

78 | P a g e

Depart, Other Major Functionality

79 | P a g e

Other Scenarios

Oscar Orderer – Cache and Buyer Scenario

80 | P a g e

Debbie Decision Maker – Alternate Happy Path, Update Incident

81 | P a g e

Ralph Responder – Self-Status Scenario

82 | P a g e

Ralph Responder – at Incident Scenario

83 | P a g e

Ralph Responder – at Incident Scenario

84 | P a g e

Appendix A: Summary of ROSS 3.0 Documentation Evaluation

Listed below is existing 3.0 reference documentation which contain relevant information to support the future ordering management process as noted in the GAP Analysis. Further vetting of the documents will be required in the design phase to ensure these documents capture the use cases and functionality to identify any exceptions.

ROSS 3.0 Functional Area Document Contains

Dispatch Organization Management High level overview of managing dispatching organizational hierarchy and support information

Contract Management High level overview of contract management including vendors, compacts, and agreements

Catalog Item Management High level overview of catalog management including contracts, compacts, complexes, and inventory

Resource Item High level overview of resource item (inventory) management including management of items from external systems

Locations and Airports High level overview of location and airport reference data management

Ordering Authorizations High level overview of ordering authorization management

Pre-Order Management High level overview of pre-order management including create, edit and delete

Resource Status High level overview of resource status including availability, relationships and reference data

Incident Management High level overview of incident management including create, order, manage, track, and report

Dispatch Scenarios Full decision tree of current dispatching workflow

Dispatch Functionality A - Incident Ordering High level overview of incident ordering including create and manage orders

Dispatch Functionality A - Incident Resource Management

High level overview of incident resource management including manage, release and travel

Dispatch Functionality A - Order Fulfillment High level overview of incident order fulfillment including determine, assign, and fill

Dispatch Functionality A - ROSS 3.0 Overall High level overview of business process including dispatch functionality & supporting processes

ROSS 3.0 Application & Security Framework High level overview of notifications, alerts and user account management

85 | P a g e

Appendix B: List of Acronyms

The table below provides a list of acronyms that may be referenced in this document.

Acronym Definition

AAR Advanced Acquisition Request

BIA Bureau of Indian Affairs

BLM Bureau of Land Management

CAD Computer Aided Dispatch

CO Contracting Officer

COR Contracting Officer’s Representative

COTS Commercial Off-The-Shelf

CPIC Capital Planning Investment Control

DOI Department of Interior

FAM Fire and Aviation Management

FAM-IT Fire and Aviation Management Information Technology

IROC Future Resource Management Tool

FS Forest Service

GIS Geographic Information System

GOTS Government Off-The-Shelf

GSS General Support System

IPT Integrated Project Team

IRB Investment Review Board

IRDB Information Resources Direction Board

IT Information Technology

NASF National Association of State Foresters

NESS National Enterprise Support System

NIST National Institute of Standards and Technology

NPS National Park Service

NWCG National Wildfire Coordinating Group

OMB Office of Management and Budget

PII Personal Identification Information

PM Project Manager

RDMT Reference Data Management Tool

RIM Resource Information Manager

RMP Risk Management Plan

ROSS Resource Ordering and Status System

SoR Source of Records

US United States

USDA United States Department of Agriculture

USFWS US Fish and Wildlife Service

WFIT Wildland Fire Information Technology

86 | P a g e

Appendix C: Revision 0.1 Detailed Response

Story Board Comments:

1 Page 3, Summary of ROSS 3.0 Documentation Evaluation Table:

Completed. Moved to the end of the document as an appendix.

a. Please just use these as reference documentation.

State something like relevant information was taken from the following:

Completed.

b. The Dispatch Organization management; catalog item management, resource item; locations and airports; these would make more sense to cover in major task 008 business process designs for a data standards and major task 009 reference administration tool develop user story boards for data standards and reference administration tool.

Completed.

c. Part of the Gap Analysis, major task 12? Also, I do not know if we want to distribute these if they are no longer accurate compared to the information you've gleamed from interviews.

Noted.

1 General: Auto-mated is "Automated" There are 5 incidents of Auto-mated and they are corrected.

2 On Page 17, should it be "create order" or "create incident"?

There is a storyboard for each persona that is represented in the 6 major business processes.

Debbie Decision Maker's role in "Create Order" is the automated process of create incident.

Consider adding the text from the BPM below on page 48:

"A Resource Order is in support of a specific incident. Therefore, an incident must be created prior to the Resource Order being created. Creating an Incident is an automated process based on the assumption that incident information is coming from an external system (i.e. integrated CAD)"

Completed. This was added to all personas represented in the "Create Order" process.

It is confusing to see Annie Analyst creating an incident.

Annie Analyst is not creating an order, she has an active role supporting the "Create Order" process with order recommendations.

Note: For ease of readability, we moved the "How to Read the Storyboards" instructions to after the overview diagram on page 6.

3 Page 22, Nicely done. Thank you.

4 Page 25: Delete "I" before "my" Completed.

In the new system, I my actual time that I arrive or leave an incident is recorded. I also can see my status and incident history.

87 | P a g e

5 Page 24 buses: Please make a note to include ordering of inspectors for buses, and requiring a VIN number for buses in the SRS

Noted.

6 Page 27 Ralph arrives: Please make a note to address travel in the SRS

Noted.

7 Page 28, "Active Role for Incident/Replenish - most likely tracked in external system." I am not sure what this means. Wouldn't the replenish be an order in the new system, not an external system? I may not understand Incident/Replenish. The note in BPMs below, task 5, may help to clarify if included in the story board. "Replenish is optional and based on resources needed for an incident over X number of days."

Completed.

8 Page 31, Please add "Ordering Manager" as a decision maker or Annie analyst; they reside at the incident and order resources for the incident/camp usually at the direction of operations; today, they must go through expanded.

Completed. The change is reflected with Debbie Decision Maker (page 16).

9 Page 43, Please make a note for the SRS that the "Portal to Portal" (Calfire) will use this complete amount of time to bill a fire. Another rule, Federal will not pay travel for States.

Noted.

10 Page 41, 44, 45, etc “This can be automated process.” Please change to "This can be an automated process."

Completed.

Business Process Models (BPM) Comments:

1 Page 48, "Not all data to support the future ordering management process is being called out explicitly."

Please add: "Additional data will be described in the Logical Data Model, and more data fields will be uncovered during design and development phase as other paths are expanded."

Completed.

2 Page 48: "The Resource Item recommendations in this process are based on the policy-driven business rules established for what resources are needed.

The recommendation is supported by Inventory, Catalog and Contract data, and the specific incident data such as the type of fire, the area, and additional elements. Resource availability is not evaluated at this time."

Completed. Added clarifying documentation.

I probably do not understand the terminology. Isn't inventory what is available? It seems contradictory to say "Resource availability is not evaluated at this time."

88 | P a g e

3 Pages 55 and 58: There are two legends; I cannot read pages 56 and 57, but will locate a plotter.

Page 58 and that legend are deleted.

4 Page 75: It seems like the flow is not correct.

Wouldn't the UTF trigger the order going to another source (cache) to fill?

For clarification: Caches do not UTF an order to push to another cache. They forward it within ICBSR.