Managing environmental data

• Apr 01, 1999

Environmental professionals have dreamed of the day when all environmental information would be neatly stored in one comprehensive database. Over the years, many companies have tried to develop products to fulfill this dream. Only recently, however, with the development of faster hardware and the second generation of environmental database products, does it finally look like this dream can become reality.

After years of monitoring the environmental software market, our company, Sterling Chemicals, Texas City, Texas, selected Rockville, Md.-based Essential Technologies Inc.'s Plantware32 to be the foundation of our environmental management information system. Plantware32 is a three-tiered product that uses SQL Server or Oracle as the back-end database. Like everything in the software world, developers are continuously improving the product - if you wait a bit longer, the product will be more robust and have more functionality. So why did we choose to implement an environmental management information system now? Four primary reasons drove our decision to purchase and install the new software:

1. To upgrade our systems. We needed to get all of our environmental systems off the mainframe, and we also needed to replace systems that were not Year 2000 compliant.

2. Reduce costs. After the system was installed, we expected to be able to streamline our workflow and reduce our compliance costs.

3. Improve compliance. The amount of data required to demonstrate compliance is becoming overwhelming. New tools are necessary to handle the vast quantities of data.

4. Anticipate the future. We wanted to have a good system in place before permitting began for the Clean Air Act Title V operating permits.

In addition to Plantware32, we also implemented Reston, Va.-based Science Application International Corporation's (SAIC) Performa to provide a consistent user interface and to extend the system's functionality. An intranet site was also developed to provide daily reports to everyone at the facility.

Justification
Although predicting the future can be perilous, in the environmental arena there appear to be several immutable trends:

• Increasing monitoring and record keeping requirements; and
• Increasing complexity.

The unfortunate corollary to this is:

• Increasing opportunities for non-compliance.

Our existing system of custom tools, databases and spreadsheets was obviously inadequate for the future.

However, before implementing a major data management system, we decided it was necessary to develop the justification for moving forward. Justifications for traditional capital projects focus on easily quantifiable costs such as raw materials, utilities or labor. This makes it easy to calculate a financial measure, such as the return on investment. The financial measurement for each project can then be compared against an internal target to determine if a project should be approved to move forward.

Software projects, however, are notoriously difficult to justify this way for two main reasons. First, properly implemented software can streamline the workflow, but the cost savings that result from this change cannot easily be determined. Second, they often provide benefits that are very difficult, if not impossible, to quantify, such as improved quality or improved environmental compliance.

Our list of project justifications appeared to comprise three categories: cost savings justifications, compliance improvement justifications and strategic justifications.

Cost savings
Cost savings justifications are the ones that can be quantified. Three basic cost savings justifications are streamlining workflow, simplifying audits, and making data and information easily accessible.

Streamlining workflow. All facilities are required by law to perform numerous environmental tasks. By using the new system, many of these environmental tasks can be streamlined. Examples include managing drums and wastes, managing the fugitive monitoring program and completing regulatory reports such as the air emissions report and the Superfund Amendments and Reauthorization Act (SARA) 312 and 313 reports. To quantify the savings from streamlining the workflow, you need to map the pre-project and post-project workflow and associate a cost to each step.

Simplifying audits. Facilities also typically perform audits of environmental records to ensure compliance. Because of the reams of data that must be maintained for environmental purposes, auditing is a very expensive and time-consuming activity. By storing the data in an electronic database, we have been able to quickly sort through large amounts of data and to automate the auditing process. These costs can be quantified by evaluating historical audit costs.

Data access. One of the most time-consuming steps of every task is getting information. For a small task, information gathering may actually be the majority of the task. We learned that by putting environmental data in a central database, we could eliminate much of the data-searching process. These costs can be quantified by evaluating the amount of time spent searching for information for various tasks.

Compliance improvement
Compliance improvement is difficult to measure, since it really is a cost avoidance. The savings come from avoiding quantified costs associated with enforcement actions. Commonly, these costs are determined from reviewing the results of enforcement actions across the nation.

Enforcement. The recent environmental enforcement trends clearly are making the cost of non-compliance more expensive. The government enforcement policy that began with the U.S. Sentencing Commission's Environmental Guidelines is continued today with various detailed U.S. Environmental Protection Agency (EPA) and state enforcement guidelines. To back these words with action, EPA also has a number of compliance initiatives, including multimedia audits, sector enforcement and the recent EPA Compliance Initiative Program. Companies are subject to numerous environmental audits by state inspectors each year.

Compliance certification. Companies across the United States have been, or will be required to obtain federal operating permits. These permits compile all of the required monitoring, record keeping and reporting in one document. They also require periodic compliance certifications by a "responsible official." Using these compliance certifications, EPA has placed the accountability for environmental compliance squarely with companies' upper management. When these requirements start, we expect the demand for environmental compliance systems to increase.

Strategic justifications
Some reasons for implementing an environmental data management system are strategic in nature. These can be thought of as proactive responses to anticipated external changes, such as the emergence of the Internet or the Year 2000 issue.

Year 2000 compliance. Many companies have identified the cost of resolving the Year 2000 problem. However, companies must decide if they want to spend this money on fixing their old systems or investing in a new system. Many companies have justified implementing new systems based on this problem alone.

Emergence of the Internet. The federal and state governments are using the Internet to communicate information and provide access to much of the data that they collect and store. Unfortunately, the quality of some of these data sources is not very good. In the future, however, many companies will want to audit the government's data. Good data management will become a necessary competency.

Functional specifications
Once the project is justified, you need to clearly define what you want the software to do. This is generally an iterative process. The first constraint is cost. Software can be developed to do anything, but not at a low cost. Some features may be desired but not required. You don't want to spend a lot of money on unnecessary features.

The second constraint is the barrier to change. Once you select a software platform, it is not cost-effective to change products in the future. Because of this, you should select software based on long-term viability first and functionality second. Functionality typically improves with each release. If there is some functionality that you really need, you may be able to negotiate it into your purchase agreement.

It is beyond the scope of this article to talk about detailed functionality; however, some of the general features we wanted in a system are listed below.

• Streamlined workflow;
• Integrated environmental data (air, fugitives, water, waste, etc.);
• Scheduled electronic transfer of data from the data historian to Plantware32;
• Automated data monitoring and analysis by Performa;
• Standard reports (updated daily);
• Near real-time compliance tracking; and
• Multiple communication pathways (pager, e-mail, etc.).

Project strategy or implementation
There are books completely devoted to the subject of how to properly implement software projects. In general, we advocate the use of many smaller projects to one large project. The problem with large projects is:

• They are usually very expensive;

• They set up high expectations that usually are not met;
• They take a long time. During this time they do not provide any benefits, and are affected by personnel and organization changes; and
• They subject people to a great deal of change and a high learning curve.

If properly planned and coordinated, smaller projects can be executed more quickly and at a lower cost. They provide immediate benefits, and allow users to learn faster and gain confidence in the system. This style of rapid application development is usually much more successful. The main advantage is that once you have completed a small project successfully, people will generate their own ideas of how the system can be used to streamline work or to save money.

What you wish you knew
Even after all of the preparation and planning, sometimes the project still isn't successful. There are many potential pitfalls in these types of projects, all of which can be avoided with the right team of people and a bit of foresight. Local users groups have formed to share their experiences with people beginning the process. In addition, consultants experienced in implementing these systems can be a great resource.

Here are some issues you may want to think about before you begin your implementation.

• Do you have a vision of the complete system?
• How will this tie into your other systems?
• Do you have any bottlenecks on the network?
• Are your server and clients fast (new)?
• There is a tradeoff between data and performance. Determine how much data you really need. Do you need it updated daily, weekly or monthly?
• The average of the sums does not always equal the sum of the averages. This is true for all complex equations. For example, if you calculate z from a and b (say z = a * log (b)), then storing monthly averages of a and b and calculating a z may get you a different answer than calculating a z every minute and averaging all of the z values.
• The nomenclature decisions (naming conventions) are very important. Program names should be consistent, and useful company-wide.
• Where will you do the training? How will you support the training?
• How are you going to support the system infrastructure? This includes the server hardware, SQL Server, database, etc.
• How are you going to provide user support?

The next step
With a good database as your foundation, the possibilities are endless. You can automate your data collection and automatically transfer the data to the database. You can generate what were previously time-consuming reports almost effortlessly. You can run custom queries against the database, or pre-publish standard reports and make them accessible via the Intranet. When you see the results, it makes the months of effort worthwhile.

This article originally appeared in the 04/01/1999 issue of Environmental Protection.