Forest EMS Support Systems

Bridging the Gap Between Shorter-Term Needs and Longer-Term Needs

Let's devote this discussion, for the next while, to exploration of possibilities for both shorter-term and longer-term "content management," "document/records management," and so on.

Shorter-Term
As per our conference call this week, I am delighted to see what you folks from the Tongass and Dan Viglione and CO. have been up to in exploring options as to how to get something going fast to help them and perchance others with their EMS needs—stuff that will ultimately help us bring into better focus needs for the longer-term.

Longer-Term
In the longer-term we all need to do more to interrelate with and/or feed other efforts like Performance Accountability System (PAS), the Monitoring and Evaluation Team (MET) effort and more.

Note that the PAS system uses a vendor-based system from Hyperion to develop what I presume to be some top management "dashboard" systems as part of their effort.

In addition, a few of us have been exploring various policy, program, decision, implementation, document, records management systems. So far we think we need to investigate further:

• EMS WebWare
• Enviance System
• ESP's OPSEnvironmental
• GreenWare Environmental Systems
• Intelex Web Based Management Systems

We are looking into anything that can help us better manage our lives and work by integrating work planning, accomplishment reporting, monitoring and evaluation, learning, (all the adaptive management stuff) and doing so with web-based relational databases, document management software and more that also interface directly with individual and group calendars and email prompts.

In talking with one of these possible vendors this morning, and with only a quick glance at Hyperion they thought that there was a complimentarity between their product and what the PAS folks are up to: PAS systems for top level information, other support systems for mid-level and field level inputs that ultimately could (would?) feed the top management system at least in part.

Finally, I have feelers out (as do the E-Gov (E-NEPA?) folks) to our new Chief Information Officer Vaughn Stokes to see if I can help in any to bring our idea of "needs" into better organizational focus.

EMS File Names and Path Names for Intra- and Internet: Suggestions

Following the lead of the WO (who put "/ems" right after "www.fs.fed.us," we should try to keep both file names and path names as simple and close to the "root" as possible. Some preliminary ideas/recommendations:

Intranet:

Paths:
http://fsweb.r4.fs.fed.us/ems/
http://fsweb.manti-lasal.r4.fs.fed.us/ems/
…/index.html (main display page(s))
…/guide.??? (main reference "document")
…/4.2/, 4.3.1/, etc. (most other subdirectories)
…/links (etc. for other "misc." stuff)

Filing:
J:\fsfiles\ref\infocenter\fsweb\ems\

Internet:

Paths: http://www.fs.fed.us/r4/ems/

Filing: ???

File Name Conventions:

• use only lower case alphanumeric characters – avoid special characters like < > : " /\ | \/ * ?


• use "." only at root, e.g fsweb.r4…, for ISO elements, and to separate files from extensions, e.g. ".doc", ".html" (Note: this is only a recommendation. If we wanted instead to not separate ISO sub-elements by "." we could do so. Alternatively we could use the "." elsewhere beyond the root, the ISO element, and the extension).


• use "_" to separate words (Only a recommendation)


• name documents simply (and compactly) within categories: e.g. since 4.3.3 names "objectives and targets," a document listing a forests objectives and targets might be name "obj_tar.html" or "obj_tar.doc" or "obj_tar.pdf" or ??? (Only a recommendation)


• "dates" are problematic, but if used in file names, say for "records," the format should be yymmdd (or yyyymmdd?) to allow for easy sorting. (Only a recommendation. But if we are going to allow "dates," folks should choose one or the other. We could use dates for "ISO documents" as well as "records," but we want to avoid having to frequently change all our intranet and internet linkages. Right now I recommend against using dates at all in file names.)

EMS Framework Example

Attached below is a simplification of the EMS template used by Greenware. I'm not saying we use Greenware, but I think a quick summary of their theoretic structure (i.e., I'm ignoring IT techno lingo for now and simply focusing on how information is organized). Greenware sells you an "EMS Wizard" that they refer to as web-server technology. Within the "EMS Wizard" there is (1) an EMS manual and (2) options for viewing/printing reports/status. The EMS Manual (i.e., Guide) within the Wizard serves as a roadmap for linking all EMS documents for each of the 17 elements, including dates and signatures. Each ISO element has:

(1) a "Procedures document" (general methods/procedures that the facility (forest unit) will use to satisfy the ISO requirements for each respective element), and (2) "spreadsheet document" where all facility specific information is entered for that element.

An example is the aspect sheet that will have aspects, impacts, significance criteria scores etc, as well as relevant review/approval dates and signatures (I believe). At a minimum, a worksheet for an element will likely have a signature box and a signature date for review, revision, etc.

Important links across spreadsheets include Aspects to Legal requirements to objectives/targets to operational controls to training. Overall, this is not too different from our current EMS guide template, minus the spreadsheet links and references to dates and signatures.

Also included within the EMS manual is the records registry (see last line of ems manual in attached figure) which, from what I could understand, is the worksheet portal/link to all monitoring reports, review reports, etc that support decisions within the EMS (e.g., name, link, signatures, and date of monitoring report that support decisions about compliance/noncompliance in 4.5.2 would be in the registry).

Given all the worksheet links established in the EMS manual, the EMS wizard can then generate reports, calendars, etc that allow facility staff (or interested members of public) to see whats going on, who's responsible for what and when etc. etc. I'm not aware that we've even begun to think about this communication aspect within any given forest unit.

I'm not trying to propose that we develop this same type of system, but it serves as an example of a roadmap to build upon. After we get an idea of what information links and flows we want, then we begin describing the IT technology that would be best. For example, I dont think anyone is worrying about generating user friendly reports at this point, in which case we simplify the diagram by removing part B altogether?? The links between the worksheets would likely need to be flushed out in more detail as well.

Download examplesoftware.xls

About documents

Might be time to clarify what we mean by "documents." The ISO standard calls for required elements of 4.4.4. Documentation; 4.4.5. Control of documents; and 4.5.4. Control of records. They're different but there seems to be the possibility of some overlap. Element 4.5.4. may well be coming from the WO and be based on the current file code system--I heard rumors of that.

Matt, I think what you're talking about are the files that are/generate the documents that are the 17 elements, hence the need for filenaming conventions. Those files would be the files that make up

1. The 17 required ISO elements
2. The EMS Guide (whatever that will be)

Am I on the right track?

File and Path Naming Conventions

To effectively structure web-based and other information systems I believe we need naming conventions for all levels (at least to the Forest level) for EMS files and paths to those files (URL path conventions and/or filing conventions).

I have been trying to dig up some current conventions, to see if any exist in the FS, in the broader ISO community or elsewhere that might help us.

What I have found so far as per file (and path) naming conventions is that we ought to:

• Use only lower case characters


• Have no blank spaces, but rather use the underscore symbol to fill in blanks "_"
  
• Reserve periods "." to precede the type file represented.
  
• As per "dates," I'm still perplexed. I'm guessing that most file management systems somehow embed dates in metadata so that managers don't have to change the date on the file name all the time. But I don't know.

In addition to file naming conventions, path names for filing would be helpful too. That way web managers throughout the agency can know in advance where to look for files. That too can be quite empowering.

I found too that at least in some circles we already have conventions for WO, Regions and Forests:

• "wo" or "00"
• "r01, 2, … 10" or "01, 02, ...,10"
• Beaverhead/Deerlodge NF = "r01_bd," or "r01bd," or simply "0102" for example

Short names, like this, have been developed for for all forests. Are they now standard? What else is standard? Is there a unique or a preferred standard? What other standards might we agree on for things not already standard?

Forest's EMS Template

As a follow-up after last week's phone conference, I'm trying to come up with a list of what a forest's ems template should require.  There would be a central WO website with general information about EMS (which already exists) linked to regional websites, linked to forests.

The Forest-level EMS template should include:

• an index list of 17 elements with hot links
• automatically list the files once they are available
• be easy for forests to update
• appear as one site (with other forests) as seamlessly as possible for the user
• incorporate the EMS Guide
• should provide a structure and organization of documents held to standard naming conventions

Someone had mentioned the USGS -Biological Survey site as an example to follow.  Can someone post a link of the specific site?  There are a few different sites, not sure which one to look at.

-matt

EMS Software: Why re-invent the wheel?

There are several companies that sell software, (mostly to buisnesses) for managing their EMS.  I am aware of two companies:  Greenware and Intelex.  GreenWare is used by the EPA (for facilities), and seems to be the better solution of the two for our purposes.  Intelex also has a program, but it is more focused on chemical companies and such, rather than the broader environmental issues that the FS deals.

We should at least eliminate this as a possible solution before we go on inventing our own methods.

While we are spending lots of employee time and contractor money struggling with building EMSs from scratch, there seems to be a real advantage to taking something that already works. We could be using the industry standard.  We could build it quicker.  We would have a system in place to manage documents, helping us organize better.  It would help with publishing documents online.  It could possibly help with sharing documents with other forests (I need to look into this further).

On the other hand, there are advantages to building our own systems:  more buy-in from the forests, we can customize our EMS to better fit the FS needs, and possibly a better overall understanding of EMS.

GreenWare does a good job pitching their product, with an ability to make it web-based and being customizable. Does it measure up? Not sure yet, but I would like to test the software--if nothing else it might give us some ideas about how we need to organize and maintain documents for our websites.

You can download a copy of their powerpoint presentation from their website: http://www.greenware.com/fsr.asp?surl=%2Fproducts%2Fdownloads%2Easp

Their web-based product is at: http://erp.greenware.com/

-matt

How To Use This Blog

Reading...

Anyone who can find this blog can read it, although it is not advertised in any way, therefore is very much lost among the 17MM+ blogs on the web.  It is not even available to Google and other search engines. If we want, we can probably mask it further so that it can only be viewed by those with an established username and password (which is now required to "post" things up). But I believe such deep masking to be unnecessary. 

To change text size simply adjust with your browser (e.g. "view," "text size", "largest ... smallest").

Comments...

If you are leaving short comments in this or any other blog, you can just type them in the provided window, remembering to leave a name and email address (whether real or fictitious). It’s that simple. If you don't see a window at the bottom of a "post" click on "permalink" or "comments."

Posts: Commentary from those allowed to post-up initial information that comment threads tier from...

Here are some hints for those allowed to "post"

• Once you get through the TypePad entry portal, available from sidebar, simply cut and paste material from a word document, add a title, some categories and you are good to go. If you need more help you can go to the TypePad’s "Posting to your weblog."
• Always compose your "post" in a word processor. Otherwise you risk losing it all during input/edits, etc. I recommend that you develop your post in "rich text format."
• Some editing helps are available on the "post" toolbar, for blockquotes, italics, underlining , strike-through, hyperlink creation, attaching documents or images, etc.

Advanced Posting:

If you want to develop long, complex posts you should develop them with a word processor using "rich text format" or save them as RTF files before attempting to post them.  When you post this way you'll likely have to do some reformatting using the TypePad tool bar, else switch to "edit HTML" and add HTML codes directly.

Alternatively you can reconfigure the post entry window to avoid the hassle of RTF files.  This is a particularly good option is you are familiar with html codes.

Here's how you reconfigure the post entry window: Go to TypePad's post entry area, look to the bottom of the page and click on "Customize the display for this post." Select the "plain text" mode, particularly if you use MS Word with other then RTF. Otherwise MS will load up the resultant TypePad input file with stuff that you don’t see in MS Word documents and at the very least clutter the TypePad system with garbage.

In addition TypePad may, on longer documents, flip you into HTML edit mode and unless you understand HTML codes you’ll be lost. Worse, if you try things to get back to WYSIWYG (What You See Is What You Get, i.e. "rich text" mode), you may lose your input.

While you are in "Customize the display for this post," you may want to scroll down and select "Extended Post" under "Post Screen Configuration"—which will allow you to break longer posts into a "post introduction" that people will see automatically and "post continuation" which is a click away for casual readers.

This is a Test

Help!!!

What are we attempting?  Why?  With Whom? 

Just another foiled attempt at blogging?