Gap Analysis Final Report - Volume 2

Oregon Department of Forestry

Forestry Business Improvement Initiative – FBII

Business Process Modeling Project – Phase 1

Volume 2: Gap Analysis Report

January 15th, 2009

Prepared by:

Sanborn Map Company610 SW Broadway Suite 310Portland, OR 97205

Oregon Department of Forestry – FBII Business Process Modeling Project

Table of Contents

1. Introduction.............................................................................................................1

1.1 Background.....................................................................................................1

1.2 Purpose of the Report.....................................................................................1

1.3 Organization of the Phase 1 Reports...............................................................2Volume 1 – High Level Business Process Modeling....................................................2Volume 2 – Gap Analysis.............................................................................................2Volume 3 – Recommendations....................................................................................3Additional Documents..................................................................................................3

1.4 Definition of Terms..........................................................................................3

2. State Forests Program.........................................................................................6

2.1 General Findings.............................................................................................6

2.2 Achievements..................................................................................................8

2.3 Issues and Challenges....................................................................................9

2.4 Operational Requirements.............................................................................12

3. Private Forests Program....................................................................................13

3.1 General Findings...........................................................................................13

3.2 Achievements................................................................................................15

3.3 Issues and Challenges..................................................................................15


4. Fire Protection Program.....................................................................................18


4.2 Achievements................................................................................................19



5. Financial and Business Management...............................................................26


5.2 Achievements................................................................................................27

5.3 Issues and Challenges..................................................................................27Business Services Program.......................................................................................27Private Forests Program............................................................................................29

i


State Forests Program...............................................................................................29Fire Protection Program.............................................................................................30Equipment Pool Program...........................................................................................30


6. Information Technology Program.....................................................................32


6.2 Achievements................................................................................................33



7. Other Program Areas..........................................................................................36

7.1 Equipment Pool.............................................................................................36General Findings........................................................................................................36Achievements.............................................................................................................36Issues and Challenges...............................................................................................36Operational Requirements.........................................................................................37

7.2 Urban & Community Forestry........................................................................37General Findings........................................................................................................37

7.3 Forest Resources Planning...........................................................................37General Findings........................................................................................................37Issues and Challenges...............................................................................................38

7.4 Agency Affairs...............................................................................................38General Findings........................................................................................................38Issues and Challenges...............................................................................................38Operational Requirements.........................................................................................38

7.5 Human Resources.........................................................................................39General Findings........................................................................................................39Issues and Challenges...............................................................................................39Operational Requirements.........................................................................................39

7.6 Quality Assurance.........................................................................................40General Findings........................................................................................................40

List of Tables & FiguresTable 1. Definition of terms................................................................................................................4

ODF FBII – Phase 1: Gap Analysis Report ii


Revision History

The revision history of this document is described in the following table:

Date Revised By: Description of Revision

11/17/2008 David Buckley

Ross Holloway

Mike Lester

Initial draft copy of final report.

11/17/08 Jim Schriever

Janet Hoyt

Quality review and final edits

12/17/08 David Buckley Revisions based on ODF responses

01/15/09 David Buckley Continued revisions based on ODF responses

ODF FBII – Phase 1: Gap Analysis Report iii


1. Introduction

This document presents the results of the Oregon Department of Forestry’s (ODF) FBII Business Process Modeling project Phase 1 Gap Analysis.

1.1 Background

Volume 1 of the ODF FBII Business Process Reengineering report provided a detailed description of business processes within ODF’s program areas.1 This report provides the basis for analyzing those business processes and identifying issues, challenges, and opportunities for improvement. This report provides a summary of Phase 1 - Task 2.3, Gap Analysis.

1.2 Purpose of the Report

Now that ODF’s current business processes have been documented and are understood, a gap analysis can be conducted that will identify issues and problems within and between program areas and business processes. This task involves analyzing deficiencies in current processes, identifying issues with information flows, opportunities to enhance information product quality, providing information that is not currently available, and systems integration. The gap analysis focuses on identifying opportunities to enhance operational efficiencies.

Task 2.1 and 2.2 has led to the identification of processes where systems are not working as well as they should, or are not meeting the goals of the ODF. Accordingly, this report includes the following:

Identify organizational concerns and issues related to infrastructure support requirements

Identify inefficiencies, organizational and technical issues, and opportunities for improvement

Identify the major systems/applications and resources with a focus on identifying gaps in the IT infrastructure that impact provision of products and services to ODF customers

Identify data integration issues and concerns

Define mismatches between current data and desired data1 ODF FBII Business Process Modeling Project, High Level Business Process Modeling Report. Sanborn Map Company. January 15, 2009.

ODF FBII – Phase 1: Gap Analysis Report Page 1 of 40


The purpose of this report is to summarize the findings of the gap analysis task. This information provides the basis for recommendations that follow in Volume 3 of the project report.

1.3 Organization of the Phase 1 Reports

The final report for the ODF FBII Business Process Modeling project Phase 1 activities incorporates three report components. Each draft report is provided as a separate document. This document is the Volume 2 Report. The Phase 1 reports are:

Volume 1 – High Level Business Process Modeling

This volume contains the primary documentation generated as part of the high level business process mapping task.2 This includes the Enterprise Map from Task 2.1. This map is provided as a separate graphic document due to the size of the document. Process flows and descriptive narratives of process tasks are presented for current As-Is business processes.

Volume 2 – Gap Analysis

This volume presents an analysis of the business process flows that identifies inefficiencies and issues related to process data and information flows. This identifies major systems, applications and databases being utilized and opportunities for improvement.

This report is organized by ODF program area as this reflects the collection and summary of data. The summary of each program area includes:

General Findings

o Description of analysis findings that are common to many processes (and sometimes to several program areas).

Achievementso Descriptions of program area achievements and successes where

processes, information flows and systems are working well

Issues and Challenges

o A review of key issues and challenges. This includes information flows that are not satisfying needs or are redundant; missing systems/technologies that should be present to support processes; workarounds that are being used; missing data that is required but not captured or not ideally stored due to process or technology issues; and, any organizational issues.

2 The task 1.1 report was delivered on November 13, 2008.



Operational Requirementso Describes those items needed to correct the issues and challenges.

Some of the findings described for a particular program area may also exist for another program area. There are common issues related to technology implementation that are identified. These common issues are addressed with recommendations in the Volume 3 report.

Volume 3 – Recommendations

This volume contains the project summary and recommendations.

Additional Documents

Supplemental documentation is also provided to augment this report. It is highly recommended that the Phase 1 report be reviewed prior to reading this report.

Phase 1 High Level Business Process Modeling Report

This report is supplemented with the following documents.

o As-Is process flow diagrams (Visio format) – process flows presented in this report were created using the Microsoft Visio software. Source Visio files are provided to facilitate editing and future use by ODF.

o Enterprise Map (Visio format) – the map is provided as a source Visio file due to the layout and size of the diagram. It is also available as a 300 dpi JPEG image.

1.4 Definition of Terms

A number of technical terms, acronyms and institutional terms are used throughout this document. To aid the reader in interpreting these, and to minimize the use of footnotes, the following table provides definitions for the terms used in this document.



Table 1. Definition of terms

Acronym or Term Definition

ArcView 3 ESRI’s legacy desktop GIS software that has been used within ODF. This software is no longer supported by ESRI and was superseded several years ago with the ArcGIS software line.

ArcGIS ESRI’s core GIS desktop software platform. ArcGIS is the agency standard for GIS although to date there has been minimal applications development or deployment for the operational program areas.

ArcSDE ESRI’s spatial database management software that seamlessly integrates with commercial DBMS, like Oracle and SQL Server. Enterprise systems utilize ArcSDE in combination with SQL Server or Oracle to provide a fully spatially enabled database.

COBOL An outdated programming language used to build mainframe systems in the 1970s and 1980s. COBOL was used prior to the adoption of relational DBMS and legacy systems still using COBOL are challenging to maintain, update or debug.

COTS Commercial Off The Shelf software. Refers to commercial software platforms that are used to build and implement custom software applications. COTS is also used in a standalone mode. For example, Microsoft Access, Excel or SQL Server, ESRI’s ArcGIS, etc.

Database Schema

Refers to the definition of fields (attributes), their relationships, and the overall content of a database structure. Schemas inform and communicate the structure within a data model and are required before data can be loaded into a database.

DBA Database Administrator. Refers to a technical person who is responsible for administering and managing databases. This person also often has database design and development skills.

DBMS Database Management System. Refers to a commercial database software package.

Enterprise GIS Refers to the implementation of GIS technology serving an entire business enterprise so that a centralized database architecture is used, allowing consistent data management, while still providing GIS tools to staff across the organizations (including District offices). This is in comparison to a standalone desktop GIS deployment/implementation where datasets typically reside on individual users’ computers or local networks without a centralized and shared database architecture.

ESRI Environmental Systems Research Institute, Redlands, CA. The leading vendor of the COTS GIS software.

FACTS Forest Activity Tracking System. FACTS is used by the Private Forests Program to input and maintain non-spatial information about forest activities and to generate notifications.



Acronym or Term Definition

FANS FANS is a standalone GIS program used to input and store data about forest activities. It has served as the spatial complement to the FACTS system.

GIS Geographic Information System

IT Information Technology

Legacy software Refers to a software application that is no longer current or latest technology. For example, ESRI’s ArcView 3 software is no longer sold as a GIS product. It has been superseded by the ArcGIS product that has gone through several major releases. Often legacy software is built for a purpose that does not meet current operational requirements.

MapObjects A legacy software product previously sold by ESRI that allows programmers to integrate basic GIS capabilities into standalone desktop applications. MapObjects is an object programming library that has been used by ODF to create FANS and SPOTFIRES. MapObjects is limited in its ability to integrate with other commercial platforms and to incorporate multi-user requirements. It is only intended for standalone, single user applications.

Oracle A leading, full-featured, enterprise relational DBMS software product.

ROOTS Current inventory database system used for maintenance of the Stand Level Inventory (SLI) data, as well as reforestation data.

SFAAR Service Forestry Activity and Accomplishment Reports system. SFAAR is implemented as a MS Access database to store and track landowner assistance efforts so that accomplishments reporting requirements can be met.

SQL Server Microsoft’s full featured enterprise relational DBMS software product.

Spatial Enabled Refers to databases that seamlessly integrate tabular attributes and GIS (spatial boundary) data together. One cannot exist without the other.

TRAS Timber Revenue Accounting System. A legacy mainframe database used to store and track timber sales revenue.

Visio Microsoft’s Visio graphic flowcharting software application used to create all process flow diagrams for this project.



2. State Forests Program

2.1 General Findings

General findings are presented that reflect issues that exist across many functional categories and business processes within the State Forests Program (SFP). Issues and concerns more specific to individual processes are presented in section 2.3 Issues and Challenges.

1. Virtually all of SFP business processes are permeated by the need to store and track activities – planned and actual. Currently, there is no enterprise system to do this. An array of legacy applications, systems and ad hoc databases are used to meet minimal needs (at best).

2. The current software and database technologies in use do not adequately satisfy operational SFP requirements. Most use outdated technology platforms and have no integration between tabular and spatial (GIS) data components. A spatially enabled enterprise system is required.

3. The implementation of GIS databases and applications is inconsistent in SFP and across other program areas. A lot of GIS development has occurred in response to the needs of organizational units, and in this regard has been done in silos. This leads to inconsistency in methods and protocols for GIS data. This status is typical of forestry organizations where GIS has been implemented in operational units and historically evolved.

4. Operational staff expressed a frustration over changing policies, directives and guidelines that guide their responsibilities and processes (“shifting sands”), and the systems currently in place that limit their ability to operate to meet these requirements (i.e. ROOTS/SLI, TRAS, etc.).

5. The majority of data is captured and managed in the Districts, while some data is maintained in Salem. This is typical of a forestry business model, and the lack of a centralized system can resultsin inconsistent data and formats across Districts. This also makes it time consuming and prone to error for rolling up and compiling data from various Districts. Data must be synchronized manually. This also applies to Private Forests' processes. A centralized, enterprise data model is required where data is still owned and maintained in the Districts but located and maintained in a single, consistent database.

6. Most staff have developed and utilize workarounds to meet operational requirements. This is due to the lack of integrated information systems. These workarounds are primarily standalone MS Access databases and MS Excel spreadsheets. Staff have developed these tools to satisfy their individual needs,



however most are solely dependent on the knowledge of a single individual, are designed for a sole purpose, require duplicate data entry (with another task in the business process), and have limited integration capabilities.

7. The demand and mechanics of feeding data and information requirements takes away critical time required to complete work and educate staff. The lack of efficient data management protocols and systems to support these processes significantly impacts staff’s time and ability to do their job.

8. There is an increasing demand on accomplishments reporting and performance measures, however while some applications/databases have been developed as interim solutions to support this need, a comprehensive system is not available at this time. Some ad hoc databases have been developed by staff to meet initial needs but these are not full featured. Currently, reporting is done through several disjointed systems that were not designed or intended for these requirements. For the most part, this issue also exists with other program areas (i.e. SFAAR is an exception, although it is not full featured).

9. Directives and procedures are not consistently stored, distributed or maintained across the agency and program areas. Some are older hardcopy documents while newer directives may be sent out via email. With changing requirements, it is difficult for staff to easily track current directives and procedures. A centralized repository is required (i.e. document management system).

10. The budgeting process is complex and requires extensive use of Excel spreadsheets that are time consuming and prone to error to complete. While staff have refined the budgeting process to meet needs, this results in a labor intensive process that is very manual. In addition, only a few key people understand the process and tools, and hence this leaves ODF very exposed in the future (i.e. single point of failure).

11. Inability of District staff to know on-going status of their budget. Current systems do not provide the capability for Salem or District staff to determine the status of their operating budget at any one time (i.e. budget versus expenditures). It is too difficult to get reports out of the corporate financial systems (refer to the Financial and Business Management section of the report).

12. Over the next few years ODF will continue to lose a large amount of institutional knowledge about their business processes. This issue, common to federal forestry agencies as well, reflects the current demographic profile of the forestry workforce. This issue is complicated by the lack of information systems to store institutional knowledge, particularly as business rules and software processes.

13. The closing of the nursery has impacted the Districts’ need to manage contracts. The nursery used to do this and this requirement has added to the workload of District staff.

14. The SFP internal web pages intended for staff do not provide an organized repository of current guidelines and reference documents. This is generally consistent with all program areas. Management needs to determine what the role



and utility of the intranet is, and develop it accordingly. The current site reflects an ad hoc development approach that has minimal corporate support and resources.

2.2 Achievements

Despite the focus of this project on documenting business processes and identifying opportunities for improvement, there have been several achievements within SFP regarding processes. These are noted in this section.

1. ROOTS component to track completed activities related to reforestation. This is an example of where automation has been successfully implemented to make it easier for staff to satisfy reporting requirements, especially for counties. Albeit in non-enterprise technology, ROOTS does provide a single system for inventory data management and recording reforestation and silvicultural activities. It has integrated some complex functionality successfully, although issues have been noted about ease of use and lack of spatial data integration capabilities by District staff.

2. Recognition of the roads inventory issue and on-going effort to design a comprehensive ODF Roads database schema (Road Inventory Management System). Currently a consistent schema does not exist across the agency but efforts are underway to define agency wide requirements, specifications and a draft database schema (i.e. data model). This effort is led by SFP. While this is a good start, it is important to realize that the roads inventory database must be implemented with data management processes and related software tools in place to support on-going maintenance of the database.

3. Development of workarounds and use of available technology to address data processing needs. While the primary information systems for SFP and ODF do not meet current needs, it is impressive how staff have developed software tools and workarounds to ensure business processes continue to operate, even if meeting minimal requirements. This shows a creative use of Microsoft’s Office platform, particularly with MS Excel and MS Access software.

4. Procedures, guidelines and documentation on the Timber Sale process are well defined. Despite some technical issues with systems supporting the timber sale process (especially TRAS), staff have defined a well documented and understood process for timber sale preparation and administration. The procedural documentation is excellent, especially from the Districts, making it an ideal candidate for automation.

5. Use of the internet for advertising timber sales. This is one example where operational processes have utilized the internet to better communicate with some customers. However, it should be noted that not all purchasers are Internet savy and utilize this approach. This will change over time, however for the interim use of the Internet to post timber sales should also be accompanied by more traditional methods of postcards and mailouts. The availability of purchaser database is required to support either approach.



6. The in-house developed Timber Appraisal System works effectively for District and Salem staff. Although this is a standalone application, it currently meets the needs of both staff and is well integrated into the timber sales process. Ideally this would be a component of an enterprise timber sales system in future.

7. Use of LIDAR data has demonstrated impressive results for capturing detailed data required to support operations. This is especially true for DEM (elevation), canopy datasets. To date this data has been utilized mostly for engineering purposes for specific areas in NW Oregon.

2.3 Issues and Challenges

Most of the issues and challenges in the SFP relate to data management and systems available to support these processes.

1. ROOTS and Stand Level Inventory

a) The ROOTS inventory system is non-spatial and utilizes older technologies that do not facilitate inherent integration of spatial and attribute data elements for stands. ROOTS is not a spatial database and only supports links with ArcView 3 GIS. Previous linkages between ROOTS and GIS were based on the ESRI ArcView 3 software, which is no longer supported by ESRI. In addition, the ArcView 3 software was superseded by the ArcGIS product several years ago. ROOTS functionality needs to be incorporated using newer spatial enabled technologies as part of an enterprise forest management system (i.e. such as SQL Server or Oracle coupled with ESRI’s ArcSDE). What level of ROOTS components can be utilized remains to be determined during a detailed systems specifications effort.

b) Some District staff believe that the Stand Level Inventory system (within ROOTS) does not meet operational needs and is difficult to use. This may be due to the lack of formal specifications to incorporate District input and/or training of District staff. Some Districts feel they were not involved in the design process and as such the system does not really address their business needs and processes. In some cases needs and processes have changed and ROOTS cannot meet the spatial data management and integration requirements. Most believe the inventory data is good, just the system to “get at the data” is not user friendly.

c) District staff have not fully adopted ROOTS and taken advantage of available training. While District staff have identified concerns over using ROOTS, a formal specifications process and formal training has been undertaken. Unfortunately only three of nine Districts have taken the training and the inherent complexity of ROOTS capabilities requires training for it to be effective.

2. Timber Sales



The Timber Sales preparation and administration business processes have several issues, most related to the integration of information systems. They include:

a) Inability to load the timber cruise into a database system for use later. The cruise data is used to generate the sales cruise report, but there is no ability to store this data for future use.

b) Stumpage values are typically three months behind. District staff have concerns that, due to the manual processes in place, the stumpage values are not up to date for the timber appraisal process. A more automated approach is desired to provide more up to date values.

c) No integration between road costs and timber appraisal. Although road engineering costs are calculated using a MS Excel spreadsheet, this data must be keyed in again to the Timber Appraisal System.

d) No ability for District staff to access bidder/contractor information. Salem tracks this information but it is not readily available to District staff. The use of standalone databases/spreadsheets is the cause of this.

e) Lack of integration for timber sale activities and the FACTS notifications system. Currently SFP foresters have limited knowledge about FACTS. Administrative staff typically input activity information using FACTS. Ideally, an enterprise activity tracking system would be used and this would provide access to all program areas on activities and operations.

3. TRAS – Timber Revenue Accounting System

a) All timber sale data is now input and maintained in a legacy, mainframe database system that is outdated and provides very limited capabilities for data integration, user interaction, query and data extraction, and reporting. In addition, the platform that TRAS was developed with (COBOL) provides virtually no opportunities to enhance or modify the system to address some of these limitations.

b) TRAS has numerous technical and functional limitations that restrict staff and ODF as an agency from collecting and utilizing accurate data related to timber sales.

i) The inability to store complete scaling bureau data severely limits ODF’s ability to track log accountability.

ii) The legacy interface of TRAS limits the integration with other systems and the ability to exchange and extract data for reporting, sharing and invoicing. In addition, only a few staff have the knowledge and ability to work effectively with TRAS. There is no ability to query the system.

iii) Lack of integration capabilities results in redundant data entry in TRAS and with Business Services Program to support billing.

iv) Functional inability to store information by weight (i.e. blowdown sales). TRAS can only accommodate board feet (MBF).



v) Inability of District staff to get reports on daily actual log loads. No ability for District staff to view or access the scale data in TRAS.

c) SFP staff have documented in detail the numerous limitations and issues related to TRAS, especially related to log accountability, the key issue. These documents will provide good input during a systems/database redesign task for a future timber sales system.

d) Several small databases and worksheets have been developed as workarounds to address data exchange and integration requirements (i.e. Q&R database, TRAS Stop-Gap database, etc.). Most of these relate to using timber sales data for more accurate billing and reporting.

4. Annual operations plans and related activities are tracked using a variety of independent databases and data sources. There is no single, centralized repository. This often makes it difficult (and labor intensive) for staff to compile activity data, review status, and summarize results for reporting.

5. Generally there are currently few technical mechanisms in place to store or track “planned” activities versus “actuals”, or historical data. This is true of virtually all business processes. A new component of ROOTS, Plans, was recently released to meet this specific need, however few staff have utilized this yet and there appears to be a gap between the availability of such tools and their use and adoption by program staff. In most cases staff have been using ad hoc spreadsheets and databases they have developed themselves to meet the need.

6. Reforestation data is input into ROOTS and GIS data is managed separately. Since ROOTS is not currently a spatially enabled database, it only stores tabular data. While the GIS data is collected and stored in the Districts, there is no inherent integration or synchronization of attribute and spatial data (i.e. two different approaches to store two data elements of the same feature or activity).

7. There is no standard for stocking surveys. This could be an issue in future for data integration especially if there is an increased use of contractors. Use of a consistent, standards survey design will help ensure better utility for the data in the future.

8. Input cruise data collected during YSM growth is not input or stored in ROOTS. Stocking survey data and interim cruise growth data collected during young stand management processes should be input and stored in the inventory or silvicultural system. A custom data collection program named HHSLI can be used for fixed plot stocking surveys and other YSM data collection. However, currently this is not used to load data into ROOTS.

9. No centralized database or system for roads and related transportation data. Data is collected and maintained at the District level resulting in a lack of standard formats and no centralized inventory for the program area or ODF. Roads are a significant asset to the state and are key to the timber sale process. However, given current processes and technologies it is very difficult to maintain data about roads, as well as accurately report on these assets. This also restricts use of the data for GASB34 and other reporting requirements.



10. Inability to store GIS data about easements, related documents, and land surveys. Currently Access databases and District GIS data is used for some of these layers but there is a need and desire to implement a consistent data schema and layer integrated into an enterprise GIS system.

11. No system is in place to collect or store recreation data. This is especially true for trails data which is typically stored in the Districts as standalone GIS layers. A centralized, consistent data schema is required for ODF. A wealth of data exists but currently is stored in separate databases and formats across the Districts. Staff do share information about this data but the lack of a centralized system impacts corporate use and reporting of the data.

12. Inability to store wildlife habitat and survey data beyond current T&E species. T&E survey data is stored in a centralized GIS data layer that is accessible to the Districts. However, there is no database schema or process for incorporating other wildlife data. In addition, SFP and PFP often track their own survey data and there is little integration. This is primarily due to format and technology issues, not desire by staff.

13. Inability to store and track the results of biological assessments that result from the AOP process. This data is typically stored in manual files and this limits the utility of the data, and the ability to track this data related to future activities.

14. Some Districts identify that IT bandwidth and infrastructure is often inadequate to support data management activities.

15. Collaboration on GIS needs and solutions between Salem and District staff is poor. Salem GIS efforts tend to occur in silos due to program area responsibilities and funding. District GIS needs cross program areas and all functional areas. Often there is a disconnect between staff and priorities. A centralized enterprise GIS system will address many of these GIS issues.

2.4 Operational Requirements

The following key operational requirements have been identified.

1. There is a critical need for a new timber sales system.

2. There is a critical need for an enterprise wide activity tracking system that will accommodate a single repository for data input by both Salem and the Districts on operational activities.

a) This system should be comprised of modules that support current business processes for inventory, AOPs, timber sales, roads & trails management, silviculture, and accomplishments reporting. Specific capabilities can be developed to meeting wildlife, recreation and other key data management activities within these key modules.



b) The enterprise system can be a framework for other program areas as many of their technical data management needs are very similar (i.e. Private Forests, Fire Protection, etc.). Discrete modules could be developed to meet unique processes and needs of those program areas.

3. A centralized spatial database is essential for implementation of an enterprise forest management system for SFP.

a) Data should be stored centrally in a single data instance, yet accommodate ownership of data and management of data in the operational Districts. This will provide a single, integrated source for GIS data and facilitate program area and agency reporting requirements.

3. Private Forests Program


General findings are presented that reflect issues that exist across many functional categories and business processes within the Private Forests Program (PFP). Issues and concerns more specific to individual processes are presented in section 3.3 Issues and Challenges.

1. Virtually all PFP business processes are permeated by the need to store and track activities – Forestry Practices and Forestry Assistance. Currently, there is no centralized enterprise system to do this. An array of legacy applications, systems and ad hoc databases are used to meet minimal needs – FACTS, FANS, SFAAR, etc.

2. The current software and database technologies in use do not adequately satisfy operational GIS requirements. Most use outdated technology platforms and have no integration between tabular and spatial (GIS) data components. A good example is FACTS (Paradox DBMS) and FANS (ESRI MapObjects based). A spatially enabled enterprise system is required.

3. The implementation of GIS databases and applications are inconsistent in PFP and across other program areas. A lot of GIS development has occurred in response to the needs of organizational units, and in this regard has been done in silos. This leads to inconsistency in methods and protocols for GIS data. This status is typical of forestry organizations where GIS has been implemented in operational units and historically evolved.

4. The majority of data is captured and managed in the Districts, while some data is maintained in Salem. This is typical of a forestry business model, and the lack of a centralized system results in opportunities for inconsistent data and formats across Districts. This also makes it time consuming, and prone to error for rolling up and



compiling data from various Districts. Data must be synchronized manually. A centralized, enterprise data model is required where data is still owned and maintained in the Districts but located and maintained in a single, consistent database.

5. Most staff have developed and utilized workarounds to meet operational requirements. This is due to the lack of integrated information systems. These workarounds are primarily standalone MS Access databases and MS Excel spreadsheets. Staff have developed these tools out of necessity, however most are solely dependent on the knowledge of a single individual; are designed for a sole purpose; require duplicate data entry (with another task in the business process); and have limited integration capabilities.

6. There is an increasing demand on accomplishments reporting and performance measures to track compliance with the Forest Practices Act. The Oregon legislature has tasked PFP to develop statistical methods for measuring compliance. Given current information systems and processes this is difficult to implement.

a) The key will be the implementation of an enterprise (agency wide) forest activity tracking system. This will provide the platform for capturing data regarding activities and the basis for implementing reporting and compliance tracking.

b) The current activity tracking database, FACTS, is inadequate and should be replaced. Other databases like SFAAR are stop gap measures and should be incorporated as part of the enterprise activity tracking system.

c) FPA administration and landowner assistance business processes are not integrated and cannot be tracked on an enterprise level. Integration would add efficiency and accuracy as information is needed.

7. Directives and procedures are not consistently stored, distributed or maintained across the agency and program area. Some are older hardcopy documents while newer directives may be sent out via email. With changing requirements it is difficult for staff to easily track current directives and procedures. A centralized repository is required (i.e. document management system).

8. The budgeting and tracking processes are complex and requires extensive use of Excel spreadsheets that are time consuming and prone to error to complete. While staff have refined the budgeting process to meet needs, this results in a labor intensive process that is very manual. In addition only a few key people understand the process and tools, and hence this leaves ODF very exposed in future (i.e. single point of failure).

9. Over the next few years ODF will continue to lose a large amount of institutional knowledge about their business processes. This issue, common to federal forestry agencies as well, reflects the current demographic profile of the forestry workforce. This issue is complicated by the lack of information systems to store institutional knowledge, particularly as business rules and software processes.

10. Numerous processes within PFP involve grant administration, however, there is no enterprise level centralized or standard method across processes to track



grants. Different processes use different methods. This is also true across Program Areas, where Fire Protection actively utilizes grants in many of its processes. To date, liberal use of MS Excel spreadsheets are used to satisfy staff needs. While dealing with immediate needs this results in duplicate data entry, and the inability to understand where grant money is being allocated geographically by program area and business process. This limits reporting capabilities.

3.2 Achievements

Despite the focus of this project on documenting business processes and identifying opportunities for improvement, there have been several achievements within PFP regarding processes. These are noted in this section.

1. Despite its architectural limitations, FANS provides PFP staff with basic GIS capabilities at no licensing cost. FANS is used by many PFP staff as a simple GIS providing basic data input and mapping capabilities. For many requirements this basic capability is adequate although issues exist with respect to data integration and synchronization from an agency wide perspective.

2. Efforts to develop a standard streams classification data layer. The primary effort within PFP for GIS data management has been the establishment, standardization and management of a FPA stream classification layer (Streams FP) as well as a portfolio of bird species resource sites data. This data is locally managed in the District offices but Salem staff may compile this data into a program database to support public information, research and analysis.

3. Development of workarounds and use of available technology to address data processing needs. While the primary information systems for PFP and ODF do not meet current needs, it is impressive how staff have developed software tools and workarounds to ensure business processes continue to operate, even if satisfying minimal requirements. This shows a creative use of Microsoft’s Office platform, particularly with MS Excel and MS Access software. A good example is the grant payments database that is used to track cost-share payments from federal cost-share grants such as forest stewardship, bark beetle mitigation, sudden oak death, and the National Fire Plan.


Most of the issues and challenges in the PFP relate to data management and systems available to support these processes.

1. The FACTS (Forest Activity Tracking System) does not adequately satisfy current FPA administration requirements. FACTS is built upon a legacy DBMS



product (Paradox) that is non-spatial and has the following limitations for supporting PFP operations:

a) No ability to integrate with GIS data. FACTS is a non-spatial database and does not store geographic boundary data. A separate system, FANS, is used as a standalone program to provide mapping capabilities. It does not integrate with FACTS.

b) The lack of a proper geographic boundary definition for data in FACTS limits the utility and usefulness of the data.

c) Limited reporting capabilities and difficult for most users to retrieve and extract data from the system. This limits the ability to accurately summarize planned activities and notifications for annual reporting purposes.

d) FACTS stores information about “planned” activities, but it rarely is used to store information about “actual” activities that occurred. For this reason it cannot adequately support accomplishments reporting. Some Districts utilize FANS to store information about “actual” activities that have occurred. This varies across Districts and is not consistent.

e) FACTS does not support the procedural business process associated with FPA administration. It is only used to create notifications.

f) Due to the underlying technology that FACTS is built upon, it is a single user application (i.e. does not support simultaneous multiple users). It is a standalone desktop application that must be installed separately in each District, and utilizes a separate database at each District. This inherently causes issues with data integration and synchronization.

g) FACTS has no capabilities to store information about compliance auditing or landowner assistance. The lack of spatial data limits the usefulness of the data stored in FACTS.

h) It is cumbersome to edit and update data once it is entered into FACTS.

i) There is no current integration between FACTS (planned activities) and civil penalties. Civil penalties information is stored in a separate Access database.

j) Lack of training and support materials, documentation, etc.

k) Because of the difficulty in extracting and using data stored in FACTS, some District staff are hesitant to spend the time inputting data. This is a potential concern since the use and documentation is not consistent throughout the Districts, and FACTS is used to generate annual summary reports to Policy and to Agency Affairs.

l) The Paradox DBMS platform is no longer supported on current Windows Operating Systems. This makes it difficult to maintain and support with no real ability to enhance functional capabilities.



2. The FANS application is used extensively to store GIS data on private lands and support map making. However, due to the core MapObjects platform that FANS was developed on, it has several limitations:

a) No ability to integrate with FACTS.

b) No ability to integrate with other DBMS or ArcGIS.

c) It cannot support multiple users at the same time. It is a single user, desktop application.

d) GIS data for FANS must be located on a local drive. It cannot operate on a centralized database. This inherently requires duplicate databases for all users of FANS and seriously impacts the integration of data created and input into FANS by District users. It inherently proliferates multiple versions of data with no technical synchronization capabilities.

3. While the SFAAR database is used to support annual accomplishments reporting, it lacks basic capabilities to aid Stewardship Foresters in performing their assistance duties. SFAAR has the following limitations:

a) No integration with GIS data for other activity tracking applications, FACTS or FANS. The lack of spatial data makes it difficult to report on where activities or assistance is provided. This impacts reporting capabilities.

b) Does not support a linkage between the recording of the assistance activity and payment tracking. This often results in duplicate data entry to support the payment process.

c) Does not support the landowner assistance programs. It is simply a place to record assistance activities so a summary report can be generated at year end.

4. There is no centralized database for basic landowner information (i.e. address etc). This data is stored in multiple locations to support the specific “siloed” databases. This results in duplicate data entry for basic landowner information.

5. While there is lots of data being captured by District staff and input into current systems (FACTS, FANS, SFAAR), there is a limited ability to generate information to support District operations. This impacts the desire and usefulness of District staff continually inputting data into these systems.

6. There is currently no ability to track and monitor private landowner stewardship plans. ODF chose not to implement the USFS WebDET system due to data confidentiality concerns, and is creating a separate database and approach to do this.

7. No database or system exists to support the Forest Resource Trust business processes. Currently, the program is administered through a series of MS Excel spreadsheets to track funding and related activity information. There is a desire by staff to utilize GIS to identify and track project areas and related information. This would provide base information to aid in cost estimating.





1. There is a critical need for a new forest activity tracking system that will incorporate both forestry practices and landowner assistance processes.

a) This system can be an extension of the same core enterprise activity tracking system used by the SFP. Specific modules could be developed to meet specific requirements of PFP business processes, while utilizing the same core software architecture and infrastructure. The design process for such a system would identify the detailed specifications for “common functionality” across units and program areas to meet different needs, but ensure an enterprise approach facilitates sharing of information and technology.

2. A centralized spatial database is essential for implementation of the enterprise system.

a) Data should be stored centrally in a single data instance, yet accommodate ownership of data and management of data in the operational Districts. This will provide a single, integrated source for GIS data and facilitate program area and agency reporting requirements.

3. A consistent approach for tracking performance measures and accomplishments is required. This will continue to be a key requirement for all programs with ODF moving forward. The establishment of an enterprise wide information system should provide the basis for collecting the data required to support integrated reporting. It is essential that such a system reflect the requirements of business processes and the data involved to support them.

4. Fire Protection Program


General findings are presented that reflect issues that exist across many functional categories and business processes within the Fire Protection Program (FPP). Issues and concerns more specific to individual processes are presented in section 4.3 Issues and Challenges.

1. Directives and procedures are not consistently stored, distributed or maintained in the program. Some are older hardcopy documents while newer directives may be sent out via email. With changing requirements it is difficult for staff to easily track current directives and procedures. A centralized repository is



required (i.e. document management system). This is consistent with other program areas.

2. Many FPP processes are based on a need to store and track spatially based activities – Landowner assessment information, locations of fire operations, etc. Currently, there is no centralized enterprise system to do this. An array of legacy applications, systems and ad hoc databases are used to meet minimal needs – FANS, SPOTFIRES, etc.

3. Software and database technologies are inconsistently applied and do not adequately satisfy operational GIS requirements. District level use of these technologies is largely driven by the skills and aptitude of local employees, with limited program direction or support. Most use outdated technology platforms and have no integration between tabular and spatial (GIS) data components.

4. A variety of stand-alone spreadsheet and database applications have been developed over many years to accomplish specific tasks. Some have been developed to serve a broad set of users (i.e. Smoke Mgt database), and others exist for individual employees to accomplish their assigned duties. Many of these applications require extraction of data from a larger system (SFMA, etc.), and then re-entry of outputs into other systems to meet accounting or reporting needs. The end result is redundant data entry and large amounts of time expended manually manipulating data to meet accounting and reporting needs. It is common to find completely different stand-alone applications in different field offices for accomplishing the same task.

4.2 Achievements

Despite the focus of this project on documenting business processes and identifying opportunities for improvement, there have been several achievements within FPP regarding processes. These are noted in this section.

1. With limited oversight or mandated standardization, ODF Districts and Salem Program staff prepare key “readiness” plans annually that result in a highly effective wildland fire prevention and suppression operations. Mobilization plans, fire prevention plans, district operations plans, and other “pre-season” plans are utilized by agency employees and cooperators as a key source of information to support activities.

2. Incident Qualification System (IQS) – ODF has successfully implemented this system for tracking wildland fire qualifications and experience, and printing Incident Qualification Cards for agency personnel. Data from IQS is used to support a number of key processes and activities, including establishing overhead pool lists for mobilization planning and populating ROSS (Resource Ordering and Status System).



3. Fire Weather/Danger prediction systems and Smoke Management Program systems provide agency staff with a variety of timely products to support decision making and operations at the field level. Field staff have relatively easy access to forecast information, real time weather station information, and localized fire danger indices. Smoke management program administration is well supported by clear processes and standards and by a functional database for registration and tracking of burn units. In future integration with other activity tracking components (through the development of an enterprise activity tracking system) will address integration of this data with other fire protection activities.

4. Fire Protection and Information Technology Program staff have implemented a system to provide consistent GIS and wireless network systems to support Incident Management Teams in the field. This effort has greatly increased IMT ability for rapid information transfer, and enhanced IMT ability to meet financial management standards and reporting requirements from remote locations.

5. Despite limitations, several districts have utilized FANS/SPOTFIRES to provide FPP staff with basic GIS capabilities at no licensing cost. These applications are used by some field personnel as a simple GIS providing basic data input and mapping capabilities during fire operations. For many situations this basic capability is adequate, although issues exist with respect to data integration and synchronization from an agency wide perspective.

6. Individual Districts and Program staff have researched and implemented new technologies to enhance fire protection services. Some recent examples are the work done by the Douglas Fire Protection Association in piloting remote camera detection systems, and the Fire Environment Working Group coordinated by Program staff. The agency has a strong informal network for sharing successes and ideas between districts, and this de-centralized system of developing and testing ideas often results in practical, cost effective solutions that can be applied more broadly.


The issues and challenges in the FPP relate to data management and the systems available to support a wide variety of processes, and to difficulties related to information sharing and reporting with a wide variety of external stakeholders and cooperators.

1. The FIRES program does not meet the variety of fire reporting needs associated with Program activities. Key “real time” reporting of fires to Area and Salem is typically accomplished by phone or by faxing information.

a) The program is not spatially enabled, and does not link directly to other applications that could populate key data fields (SPOTFIRES, FACTS, IQS/ROSS).



b) There are no connections to financial systems or programs, requiring cost information to be generated externally and then entered into the program. Cost collection fires require the use of a separate database, created specifically because FIRES could not accommodate the necessary cost accounting.

2. The process for creating fiscal budgets and determining assessment rates is extremely complex and requires extensive use of Excel spreadsheets.

a) While there have been great efforts to create and manage a consistent set of spreadsheets, it is a very labor intensive process that requires a number of manual extractions and re-entries to produce all the required outputs.

b) A very limited number of people understand the key processes and tools, and hence this leaves ODF very exposed in future (i.e. single point of failure).

c) The fiscal budgeting spreadsheets are not connected to any higher level financial systems, and data transfer between systems must be done manually.

d) There are also no direct links to the various spreadsheets and databases being used to manage the fire patrol assessment process, creating the need for a complex set of stand-alone applications, and a large number of data extraction, data manipulation, and re-entry tasks that are redundant and time-consuming.

3. Existing financial systems and applications are not adequate to efficiently carry out the range of cost accounting necessary to support the Program.

a) The statewide systems (SFMA, OSPS, ORBITS, etc.) do not provide the necessary flexibility or detail to track the variety of specific activities.

b) Programs such as I-Suite, which has evolved as the “industry standard” for fire cost accounting at the regional and national level, does not link directly into the array of agency developed spreadsheets, or to the statewide financial management systems.

4. Forest land classification and fire patrol assessment processes are not consistently implemented across Districts, and are not well supported by existing information systems.

a) There is no standard process, supported by a spatially enabled application, being used in all districts. A District’s ability to carry out these functions with technological support is dependent on the skills of local staff and on the data management systems being used by local Counties.

b) In some districts, these functions are highly automated, with the ability to overlay previous and current tax lot information, and in others they are largely manual exercises with hard copy outputs being reviewed and edited.

5. Early efforts to implement ROSS have been tentative and resulted in inconsistent implementation.



a) Field use of the system is not consistent, with some initiating ROSS data entry at the time of initial attack, and others only utilizing ROSS for resource orders that must go to the Area office or Salem.

b) There are concerns about “losing control” of resources that have been entered into ROSS. Due to these concerns, and lack of complete “buy in” across the agency, numerous other resource availability and tracking spreadsheets are maintained in field offices to manage resource availability and respond to resource requests during fire season.

6. The complexity involved with Federal grant administration tracking on a wide variety of different grant programs, makes it difficult to meet documentation and reporting requirements of federal agencies.

a) Staff currently relies on a variety of spreadsheets and databases created to meet immediate needs, with limited or no linkages to other information systems.

b) Spatial information on past practices exists in local databases (FANS) but is not stored centrally and is difficult to access.

c) State finance systems (SFMA, etc.) do not provide adequate detail to meet federal requirements, creating the need for separate spreadsheets to manage information and produce reports. Problems arise related to providing sufficient documentation to federal agencies.

d) FEMA Fire Management Assistance Grant requests for payment have been denied based on the inadequacy of agency financial systems to provide acceptable documentation.

7. District “Readiness” plans are not created with consistent formatting and content.

a) Information and data that is common to all Districts is not created in a consistent manner that supports “aggregation” across multiple districts.

b) Although Districts utilize a variety of spreadsheets and databases locally to track and generate information for these plans, aggregating such information across districts must be done manually. Final plans are typically made available as .pdf files.

8. Processes associated with fire cause investigation, potential third-party liability and cost collection are largely managed through the use of stand-alone spreadsheets and databases, and hard copy file systems.

a) Case tracking relies on various individual’s knowledge of particular cases, and requires direct phone and/or e-mail communication.

b) There is no system for integrated case tracking that allows all involved parties to access current information on case status.

9. There is no consistent system or application being used for tracking of fire law enforcement actions or violations.



a) Individual districts have tracking systems that range from file folders to locally created spreadsheets and databases.

b) Information in these systems cannot be easily aggregated to area or statewide levels to identify problems or trends.

10. There are compatibility issues between the IQS system and the newly implemented I-Learn system.

a) IQS preceded the I-Learn system and it was hoped that it could more broadly support agency needs for tracking employee training and development information. When this was determined to be unfeasible, the agency moved forward with implementation of the I-Learn system, as part of the DAS mandated Learning Management System for all state agencies. This has resulted in a situation where ICS/Fire related training and qualifications are being tracked in one system (IQS), while other training is being tracked in another system (I-Learn).

11. There is no consistent or centralized system for creating, storing and accessing the variety of cooperative agreements utilized by the Program staff and field personnel.

a) Agreements are typically created in word processing applications, but are stored in hard copy file systems, some filed at local offices and others in Salem. Locating the most current version of a specific agreement can be challenging.

b) The system does not facilitate annual reporting on agreements to DAS, and it is not clear whether this reporting requirement is currently being met.

12. The lack of integration between Smoke Management data and FACTS for activity tracking and notification.

a) While FPP has been successful in the development and deployment of fire danger and smoke management information and tools, the lack of integration into an agency wide activity tracking system is a pending challenge. FACTS is unable to satisfy this requirement and future systems development need to incorporate this cross program need.



1. There is a need for a forest fire protection activity tracking system that can incorporate the range of information required to effectively carry out the sequence of processes from land classification and fire patrol assessment, fire prevention and suppression operations, to the accounting and reporting functions associated with these processes.



a) This system can be an extension of the same core enterprise activity tracking system recommended for the SFP and PFP. Specific modules could be developed to meet specific requirements of FPP business processes, while utilizing the same core software architecture and infrastructure.

b) This system must have the ability to utilize key external data sources such as County tax lot information, and information from forest landowners.

2. There is a need for an integrated fire finance system that can be linked to key existing systems like SFMA and I-Suite to meet the range of accounting and reporting needs in the Program.

a) The system must have links to the enterprise activity tracking system to facilitate data sharing for processes like fiscal budgeting and landowner assessments which rely on the spatial data to determine rates and create assessment billings.

b) The system should link to a new fire reporting system for seamless input of cost data.

c) The system should link to existing systems for resource tracking and ordering to facilitate data sharing.

d) The system should be capable of producing a variety of reports sufficient to meet an array of reporting needs (both State and federal agency requirements).

3. There is a need for a consistent and comprehensive system for tracking federal grant projects from Legislative authorization to final closeout with the granting agencies.

a) The system must have links to the enterprise activity tracking systems for all three operational programs (SFP, FPP and PFP) to facilitate use of data on past and current activities and practices.

b) The system must have links to the integrated fire finance system.

c) The system must enable access and use by both field personnel engaged in project design and administration, and Fire Program and Business Services Program staff responsible for program administration.

4. There is a need for a consistent and comprehensive resource dispatching, ordering and tracking system that can incorporate all aspects of the process, from initial attack to mop-up for each incident.

a) The system needs to provide an initial attack dispatch module, similar to WildCAD, that provides for access to pre-planned resource dispatch information, and ensures consistent initial data entry on all incidents.

b) The system needs to integrate with IQS and ROSS, to utilize information from those systems, and to facilitate a seamless transition to expanded and large fire ordering systems as an incident grows in size and complexity.



c) The system needs to integrate with a new fire reporting system to facilitate data sharing and accurate and timely reporting.

5. There is a need for a fire reporting system that can fully integrate with the necessary spatial data, resource data, financial systems and other information management systems, and provide a variety of reports for different audiences in a timely manner.

a) The system must be able to incorporate the wealth of historical fire data currently available, and support data needs for fire prevention and fire suppression planning.

b) The system needs to integrate with the integrated fire finance system to easily incorporate cost information.

c) The system must have links to the enterprise activity tracking systems for all three operational programs (SFP, FPP and PFP) to facilitate use of data on past and current activities.

d) The system should link to, or create reports that are compatible with the requirements of existing reporting and information sharing systems (i.e. daily reports to NWCC, Incident Status Summary, etc.)

6. There is a need for a centralized system for tracking fire law violations, fire investigations and related cost collection actions.

a) The system must link to the new fire reporting system.

b) The system must link to the integrated fire finance system.

c) The system should link to the enterprise activity tracking systems for all three operational programs.

7. There is a need for a centralized system for cataloging, storing and accessing the range of cooperative agreements with other agencies and organizations. This system needs to incorporate a reporting function that can meet annual reporting requirement for DAS, and other reports.

8. There is a need for consistent standards to govern the creation and distribution of District “Readiness” plans.

a) The standards should address the specific plans required annually and the specific components to be addressed.

b) Data formatting and presentation standards should be incorporated that facilitate aggregation of multiple District plans at the Area or statewide level.

9. There is a need to create a “bridge” or link between the IQS and the new I-Learn application to incorporate key information from IQS into I-Learn.



5. Financial and Business Management

This section includes a review of the Business Services Program as well as financial and business management processes within the three core programs areas (State Forests, Private Forests & Fire Protection).


General findings of the gap analysis are:

ODF business processes use many software packages owned and developed by the State of Oregon. SFMA, PICS, PPDB, OSPS, ORPIN and ORBITS are all examples of software programs over which ODF has little or no control in terms of development. As a result, improvements to ODF’s financial processes must work around these programs. Some larger agencies have been able to develop custom programs to replace the state’s standard programs, but generally agencies the size of ODF cannot afford to do this.

Many of ODF’s internal software programs are outdated. ODF uses a number of legacy programs developed over the last 25 years. These program are built on platforms common at the time of their development, which were not designed to accommodate more modern concepts of graphical interfaces, multi-tasking and data sharing, nor have they been updated to address ODF’s changing needs.

In the past, ODF has lacked sufficient funding to upgrade its business process systems. Due to funding pressures, ODF has not always had the resources available to develop its business systems. Custom programming is quite expensive. The FBII program is an important opportunity to build an integrated solution and capture the technical and monetary resources to bring it to reality.

A significant amount of ODF business data is stored on individual computers and in incompatible formats, not accessible to all ODF staff. Mainly as a result of the previous two issues, there has been a proliferation of stand-alone databases and spreadsheets that have been developed over time to address ODF’s changing needs. Individuals have designed them with relatively little organizational input. As a result, this data is often either not available to other users or incompatible with existing systems and models.

ODF depends on its institutional knowledge base. Because of the above issues, many of the complex, custom linkages between the various databases are only fully understood by individual employees, who execute these processes every month, year,



etc… This knowledge is at risk, and could be lost through turnover, retirement and budget cuts.

Duplication of effort. There is considerable duplication of effort between Salem and District offices, largely due to stand-alone databases containing the same information that must be maintained at the various offices.

5.2 Achievements

Despite a lack of funding for business process improvements, ODF has achieved a sophisticated system of making complex allocations of its costs and revenue among a variety of organizations, both within and outside the agency. The staff shows commitment and purpose in the execution of their work, demonstrating their commitment to accuracy and accountability. The current team culture with BSP promotes an innovative approach to satisfying needs. However, staff realize that there is a significant need to move forward with more automated methods.

1. Forestry Budget Information Tracking System (FORBITS).

a. FORBITS provides the ability to track operational plans at a level of detail greater than what is possible through the state’s ORBITS system.

2. Fiscal Budgeting Process

a. This process provides ODF with increased operational flexibility, given uncertain costs and receipts, than is possible through the biennial budgeting process.


This section describes the issues and concerns identified in the assessment.

Business Services Program

There was general consensus among most program areas and interview respondents on the following items.

1. Purchase Order (PO) and Procurement System

a. The current system is really an invoice approval system, with no ability to track unpaid liabilities. In addition, most employees cannot access information about which invoices have been paid and which have not. Access to this information is not easy to obtain and requires a substantially detailed knowledge of the systems.



b. The PO system does not have an interface to ORPIN to search for existing state contracts to provide needed goods.

c. Procurement in the Districts suffers from inadequate knowledge and training of district employees, which leads to procurement procedures not being followed.

2. Invoicing and Revenue Capture System. Currently, this system is not integrated and overly relies on spreadsheets and is not linked to crucial databases, such as TRAS.

3. Time Recording System. Timesheets are manually entered into OSPS (the state payroll system), rather than automatically through an electronic bridge. Many timesheets are still completed on paper. There is a lack of error checking before the time records are posted. As a result, the system allows incorrect combinations of entry codes when those could be avoided by improved programming and error trapping in the system.

4. Employee Expense Management. Employee expenses are currently reimbursed through a manual system of entry, calculation and approval. Manual entry of this information is required in both SFMA and ORBITS resulting in duplicate data entry and potential for error.

5. Asset and Risk Management System

a. The tracking and reporting on property is prone to human error and subject to non-reporting from District offices.

b. The Access database used for property reporting is not user friendly.

c. There is no single report of property.

d. Last year, 10% of agency did not respond to inventory requests. Agency may be under, or over, insured.

e. Districts are using S&S budgets to fund purchases that should be part of capital assets.

f. Real property is tracked only on hard copy documents.

g. There is no system for accumulating safety reports for statistical analysis.

6. General ledger account corrections. Considerable re-coding of GL entries is required due to a lack of tools for identifying erroneous coding upon original entry.

7. Lack of integrated financial reporting software

a. Agency financial data is stored in a variety of stand-alone databases, which are generally not compatible with the state systems with which they are intended to work.

b. It is difficult to gather data from these sources that can report the overall financial standing of the programs or the agency as a whole, to use in the agency’s decision support system.



c. Many staff are frustrated that BRIO doesn’t, or they don’t have the training to make it, produce data in flexible ways.

8. The current workflow for BSP processes utilizes workarounds and custom processes that are time consuming and often focus on manual reconciliation. This approach does not afford time for documentation of these processes, refining policies, or analysis of data and/or processes. Staff are totally consumed working to satisfy immediate data input needs. To date staff have been able to identify where the highest risk areas are and focus their efforts on developing workarounds to these key areas. However, no time is available for analyzing financial data, or optimizing processes based on these analyses.

9. Current BSP operations are reactive and there is limited flexibility to respond to changing environmental and economic conditions that impact budgeting and financial operations. BSP staff are aware of this but current systems do not afford the flexibility required. Currently BSP is system driven, not process driven, and this is inherently inefficient.

Private Forests Program

1. Budgeting Process. Because the Private Forests Program does not generate fiscal budgets, the Districts often do not know their approved budgets until well into the biennium.

2. Personal Service Expense (PSE) Calculations. Staff is unable to accurately forecast actual PSE due to:

a. current FORBITS does not include any of the 07-09 comp. plan increases or funding reallocations, and

b. employee Service Entry Dates (SED) being random throughout the year.

Currently SED is based on start date to the first of the following month, while Management Services stay on actual date. Even if an attempt is made to reconcile this, access to the portion of OSPS containing SED date info is restricted to Human Resources only.

3. Key Card Program. The annual key card inventory process should be electronic, using system records entered by facilities when key card issued, instead of manually by program each year.

State Forests Program

1. TRAS. While issues with TRAS are more thoroughly explored in the operational section, from the financial side TRAS does not integrate with SFMA. Further, TRAS does not display invoice detail so that when customers call with questions about invoices they have received, staff must find the hard copy of the invoice in the contract file.



2. Fiscal Budgeting Process. This system uses spreadsheets extensively to record budget information. The spreadsheets used by differing budget units are not consistent, which leads to re-work and manual entry. Further, it does not sufficiently integrate with ORBITS and SFMA, and lacks reporting abilities and performance tools. Staff would like FORBITS data to be downloadable to Excel. This option is currently available if specifically requested with the Budget Management Unit staff.

3. Timber Sale Databases not Integrated. There are a variety of database entries created during the timber sale process. These databases generally cannot access each other, greatly increasing the complexity and effort required to keep all of these databases appropriately updated.

4. Systematic Under-Reporting of Timber Sales. Contractor project work is recorded as a credit to timber sale revenue, thereby under-reporting actual timber sale revenue. As cutout information is used for future timber sale projections, this procedure introduces a systematic error.

Fire Protection Program

1. FEMA Documentation. While discussed more fully in the operational areas, ODF has significant issues regarding documentation that meets FEMA requirements, including issues with properly identifying and coding FEMA related costs.

2. Fiscal Budgeting Process. This system uses spreadsheets extensively to record budget information. The spreadsheets used by differing budget units are not consistent, which leads to re-work and manual entry. Further, it does not sufficiently integrate with ORBITS and SFMA, and lacks reporting abilities and performance tools. Staff would like FORBITS data to be downloadable to Excel. This option is currently available if specifically requested with the Budget Management Unit staff.

Equipment Pool Program

1. Accuracy of Motor Pool Calculations.

a. Process for determination of O&R rates and monthly replacement costs needs to be simplified, and automated within FVOL system.

b. Process for vehicle replacement needs to include disclosure to purchasing program for confirmation of accurate charges/credits and coding. Currently, legislative funding approved for new vehicles appears in program budget as “capital outlay” funds.

c. The Equipment Pool generates a PO to the vendor for the vehicle, and processes internal charges to programs. GF is processed as expenditure of “special payment” funds (where there is no authorization), OF is processed as an internal fund transfer.



d. Equipment Pool applies “right-size credit” when applicable. Programs are not provided any documentation associated with this process.


The following requirements were identified.

1. New systems will need to integrate with state systems. No matter what changes ODF determines it needs, any new solutions will have to integrate with the existing state mandated systems, such as SFMA, ORBITS, and ORPIN. This will be difficult given the legacy, mainframe architecture of some of these systems. Note that ORPIN is not considered a legacy system.

2. New systems must not disrupt ODF operations. ODF programs, especially fire protection, are critical state programs that must be maintained during any system conversions. The replacement of legacy systems, or the implementation of new systems, will be difficult and require careful logistical planning so that minimal disruption occurs with state and agency financial deadlines and related processes.

3. ODF staff must be provided sufficient resources to implement new systems. Currently, inefficiencies within the ODF business management processes allow insufficient time to develop and document the existing systems. To successfully implement new systems, ODF staff may need to be expanded, at least temporarily, to accommodate these changes. Contracting of staff also is an option. Training will be key for any new system and must incorporate Salem and District staff.



6. Information Technology Program


General findings are presented that reflect issues that exist across many functional categories and business processes within the Information Technology Program (IT). Issues and concerns more specific to individual systems or processes are presented in section 6.3 Issues and Challenges.

1. Several key agency information systems currently operate on legacy, outdated technologies that have severe operating limitations. Two systems in particular, TRAS and FACTS, utilize outdated COTS platforms that have no spatial database capabilities. These systems support key program area business processes that are inherently spatial, and use of enterprise spatial database is a necessity, but the current lack of integration with GIS severely restricts program area staff’s ability to perform day-to-day functions. Numerous issues exist and are documented in the program area descriptions on Issues and Challenges.

2. Systems currently in place for the program areas have been developed for those program areas only (silos), and do not integrate with other program area needs. Several of the units within the program areas require functionality that is common across program areas. This includes the need to share data about activities. However, to date most systems are silo-ed in nature and do not accommodate these data sharing or common needs.

3. IT staff have an excellent understanding of the role of GIS technology in forestry information systems. The IT GIS group has a good understanding on the needs and opportunity to migrate to enterprise GIS from current legacy desktop usage (i.e. ArcView 3 to ArcGIS; desktop databases to an enterprise database). The documentation available on the on-going transition is excellent and reflects a structured approach that synchronizes well with the current FBII project.

4. Although the IT GIS group is well versed in using ArcGIS and related migration priorities, there has been minimal adoption by program area staff to date. To date most program area staff, especially District staff, have not migrated to using ArcGIS in place of older GIS platforms. Most program area staff still utilize FANS and SPOTFIRES regularly and it appears few have actually begun using ArcGIS at this point. It is understood that the IT GIS group has incorporated plans to migrate databases and applications based on an enterprise GIS architecture over the next two years.

5. IT’s support requirements for legacy systems puts a drain on IT resources impacting the ability to look forward. Support requirements for several legacy



systems, such as TRAS, FACTS drains resources away from migration to other platforms. It is expected that the results of the ODF FBII project will provide the needed structure and justification to address these system issues from a corporate perspective.

6.2 Achievements

Although the focus of this project is on documenting business processes and identifying opportunities for improvement, there have been several achievements within IT regarding their processes and support for program area processes. These are noted in this section.

1. Despite its architectural limitations, FANS and SPOTFIRES provides program staff with basic GIS capabilities. FANS and SPOTFIRES are actively used by many program staff as a simple GIS providing basic data input and mapping capabilities. Since these are based on ESRI’s MapObjects product there is minimal (or no) licensing fees for end users. In addition, for many requirements this basic capability is adequate, although issues exist with respect to data integration and synchronization from an agency wide perspective. IT is well aware of these data integration issues and understands that these MapObjects based applications do not provide the necessary enterprise data management capabilities required. They are interim solutions that need to be replaced with an enterprise systems infrastructure.

2. Ability to develop workarounds for legacy systems has kept them working for the interim. IT has been able to support the development of workarounds (i.e. TRAS Stop Gap, etc.) to address limitations with existing legacy corporate systems. While not ideal, these workarounds are nonetheless helping program staff at least get their job done for the short term.

3. Working with FPP staff, IT has implemented a system to provide consistent GIS and wireless network systems to support Incident Management Teams in the field. This effort has greatly increased IMT ability for rapid information transfer, and enhanced IMT ability to meet financial management standards and reporting requirements from remote locations.

4. ArcGIS Transition planning. IT has spent substantial effort in conducting a technology assessment and developing an ArcGIS transition plan and strategy. These documents are excellent and provide a starting point for future transition into enterprise GIS systems. Transition activities are already underway.

5. Support for the Stream Classification and Fish Presence data project. This project demonstrates how IT has successfully worked with program area staff to address a critical data need while enforcing structure and standards to the process.

6. GIS Operations Manual. The GIS operations manual is a good baseline document for program area staff to understand IT’s structured approach to GIS management and support services within ODF.




1. IT is currently supporting several legacy applications that require significant effort and use of technical workarounds to keep them operational. In particular, TRAS and FACTS are key systems for ODF program areas that do not currently meet business requirements, yet require on-going support particularly for data management. Both operate on outdated operating systems and COTS software platforms that not only drain resources, but impact morale of IT and program staff they are supporting.

2. Legacy systems are non-spatial. As identified earlier, key systems maintained by IT for the program areas do not utilized GIS or spatial database technology, although they inherently manage data that is spatial. This limits the ability of these systems to support business requirements in addition to leading to duplication of effort and data input by program staff. Workarounds and other standalone tools are used by staff in an effort to satisfy data processing and information needs. This is inefficient.

3. The ROOTS inventory database/system is very dependent on the knowledge of a single individual in SFP. The institutional knowledge of ROOTS lies with a single SFP staff who is no longer a full time employee. ROOTS is a key system and knowledge transfer is required so that the maintenance of the system can be transitioned to IT in the near future. ROOTS is written in older technologies with GIS integration that reflects the older GIS technologies that do not adequately support a fully spatially enabled database architecture. ROOTS provides some core inventory data management capabilities that are key to SFP business processes and this needs to be understood.

4. The FANS application is used extensively to store GIS data on private lands and support map making. However, it has several limitations primarily due to the core COTS platform that FANS was developed on.

a) No ability to integrate with FACTS.

b) No ability to integrate with other DBMS or ArcGIS.

c) It cannot support multiple users at the same time. It is a single user, desktop application.

d) GIS data for FANS must be located on a local drive. It cannot operate on a centralized database. This inherently requires duplicate databases for all users of FANS and seriously impacts the integration of data created and input into FANS by District users. It inherently proliferates multiple versions of data with no technical synchronization capabilities.

e) FANS is an interim solution that should be decommissioned as an enterprise GIS system is implemented.

5. There has been minimal use of Internet and web technologies by the IT group to date. This is true for ODF as a whole. There is no formal web development or maintenance group within IT and this is reflected in the level of content available on



the public and internal web sites. The agency web site is currently managed by Agency Affairs. For the most part, the ODF internal web site is disjointed and inconsistent with respect to information content and design. In addition, there has been no real use of web mapping (GIS) technologies within ODF, for program area support or on the public site. To date virtually all applications are desktop based.



1. In order to satisfy program area business processes more effectively, existing legacy systems must be migrated to modern platforms. This will allow IT to provide better operational support and will result in more robust applications that better meet program staff’s needs. IT staff is well positioned with current skills and knowledge for this migration, although additional technical resources may be required.

2. A detailed transition plan for migrating ArcView 3 and MapObjects based applications to ArcGIS based applications (desktop and/or server) needs to be defined. An excellent ArcGIS transition plan has been defined, but as ODF prioritizes business process reengineering and enterprise systems, detailed transition plans will be required for specific processes and related applications, such as TRAS, FACTS, FANS, FIRES, ROOTS, SFAAR. Consideration of desktop versus web technologies will be key.

3. There are opportunities for ODF to migrate to web based solutions to support the program areas. IT will need to become more proficient in these technologies and have adequate resources to support this transition in future. Some of this may occur as part of the preparation and implementation of an enterprise GIS system. The FPA administration and related notifications processes are obvious candidates for web deployment in future.

4. A spatial database administrator will be required. As IT migrates ODF to the use of enterprise wide, spatially enabled databases, there will be a key requirement for a DBA who specializes in ESRI’s ArcSDE platform.

5. A web developer will be required. As IT migrates to the use of web technologies for systems deployment a full time web developer will be required within IT. Currently applications developers within IT are desktop based. To properly make use of new web technologies, such as ArcGIS Server, IT will require these developer skills and capabilities. In addition, ODF should consider migrating development and maintenance of the agency web pages to the IT group.



7. Other Program Areas

Findings and results of the gap analysis for other program areas are provided in this section.

7.1 Equipment Pool

General Findings

1. EPP primarily utilizes ODOT mainframe systems for cost allocation and Fleet Anywhere software for asset tracking. Integration between these two primary systems is a problem.

2. The EPP is characterized by a number of MS Access and Excel databases that have been developed as workarounds to satisfy functional requirements not provided by mainframe systems. Efforts are underway with IT and DAS to try and eliminate these dependencies with ODOT legacy mainframe systems and provide more direct linkages to SFMA and the PO system.

Achievements

1. The EPP has developed detailed flowcharts that describe their business processes and systems used in those activities. This effort was driven by a significant turnover of staff that allowed a realignment of functions and responsibilities to occur. EPP staff have a clear understanding of the specific integration points that are not supported between the key systems they utilize – SFMS, Fleet Anywhere, PO.


Issues related to financial cost calculations can be found in section 5.3 Business Management - Issues and Challenges.

1. The lack of integration with mainframe systems results in significant re-entering of data into multiple systems. This duplicate data entry is time consuming and prone to error.

2. Cost allocation requirements associated with EPP adds a level of complexity beyond typical asset management. Current systems do not adequately support these requirements and this has resulted in the numerous Access and Excel databases in use. Tighter integration is required with finance systems so that



consistency exists for items like charge codes, and other similar items that may be subject to change.

3. Current processes have evolved to respond to state system limitations. Current processes are based on band aids that have been developed to offset current legacy system limitations.

Operational Requirements

1. The cost allocation requirements of the EPP need to be reviewed and documented as part of a business re-engineering effort. Current systems and processes do not effectively address these requirements.

7.2 Urban & Community Forestry

General Findings

1. Currently UCF has minimal demand or use of agency information systems. Some standalone Access databases are used to track grants and accomplishments related to those grants – including the preparation of input data for entry into the national Community Accomplishment Reporting System (CARS). No real integration issues exist.

2. Grant tracking conducted by UCF is similar in scope to grant administration and tracking done by other ODF program areas. However, this is done independently and there is no integration with other grant tracking efforts, although functional requirements are very similar.

7.3 Forest Resources Planning

General Findings

1. FRP is actively involved in integrating data from several agencies, typically at broad scales, to conduct analysis to support planning projects and reports. FRP rarely requires detailed information from ODF agencies. Obtaining data from federal agencies can sometimes be an issue.

2. FRP maintains its own databases and GIS capabilities in order to support their needs for aggregating and compiling data at a variety of scales. Accordingly, they rarely need to integrate data from ODF program areas and are typically not affected by bottlenecks that currently exist for retrieving data from some of ODF’s legacy systems. In addition, they sometimes have to turnaround information requests under very short notice (acting as staff to the Board of Forestry), so they require self sufficiency from a technical perspective.




1. FRP is unable to obtain accurate data from FACTS about landowner activities. The lack of reliability in data stored in FACTS is an issue. FRP often finds that FACTS data does not match summaries from other sources.

2. FRP often utilizes USDA Forest Service Forest Inventory and Analysis Program data, however they find this rarely matches ODF’s Stand Level Inventory (SLI) data. They are able to obtain SLI data without problems typically from ROOTS and SFP.

3. For reasons of costs, reliability and convenience, FRP relies primarily on internal program processes for storage and back-up for a very significant multi-year investment in GIS and other digital data.

7.4 Agency Affairs

General Findings

1. AAP is often dependent on the information it receives from the program areas (Salem & Districts) to satisfy their mission. Much of this information is stored in legacy systems that do not afford easy retrieval and reporting capabilities.


1. The lack of enterprise wide, integrated systems within ODF impacts the ability of the agency to respond to requests for information from legislators, stakeholders, the media, the general public and other audiences. Staff are often challenged to compile and distill information so that they can tell the agency’s story in clear, compelling terms. Current information systems are not storing data in a manner that affords accurate reporting and breakdowns on activities.

2. Currently ODF does not have adequate staff dedicated to web site design, implementation or content development. The agency has a single web communications coordinator, in AAP, to work on content, messaging, design, consistency, training, and technical issues across a large external web site. Other agency staff work on portions of the site, but only as a small portion of their duties. A significant challenge is realizing the full potential of a statewide web platform that is inconsistent in performance, lacking in clear governance, and often difficult for its users to understand..


1. A formalized governance structure, integrating the various disciplines associated with the web (writing, design, IT) is required. This is necessary to effectively develop and maintain the site, clarify roles and responsibilities, ensure consistency in quality, navigation and function, and ensure that the full



range of capabilities that the system provides is supported and available to web authors.

7.5 Human Resources

General Findings

1. Most HR processes are still manual in nature. A large number of the processes undertaken by HR are manual and information is still actively stored in file folders. Corporate systems are used especially related to recruitment and hiring. Some new systems are in development that will automate some processes and provide a central repository for some data.


1. There is some confusion about the role and overlap between LMS (I-Learn) and IQS. IQS is used as a repository for staff’s fire training and qualifications while I-Learn is used for agency employee training plans and development that are non-fire related.

2. Salem Hr and District staff have minimal direct access to Personnel Position DB (PPDB) or Position Inventory Control System (PICS). DAS provides services for data input and retrieval. PICS is a legacy system for budget development only. All PICS data is translated into a usable form in FORBITS, however not all staff are aware of this.

3. Managing and scoring responses to job advertisements is a challenge for HR, due to the sheer volume of responses. HR anticipates this may become more of an issue as the postings of positions becomes more automated. A more automated way of reviewing and tracking responses may be required in future.


1. Clear distinction between IQS and LMS for program staff. Operational staff will need to clearly understand the role and level of integration that exists between these two systems.

7.6 Quality Assurance

General Findings

1. QAP uses ACL software and this does not integrate with current ODF systems. Integration with ODF financial systems will continue to be difficult while legacy



systems, such as TRAS, are still operational. Integration with state systems is not a problem.

2. Currently the lack of integrated information systems (and related databases) limits the ability to obtain information necessary to complete some QAP engagements. A lot of manual effort is involved to acquire the information required to complete audits.


Gap Analysis Final Report - Volume 2

Documents

Transcript of Gap Analysis Final Report - Volume 2