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

Comments

[Elaine]

First: I'll sing my usual song: Who's going to code this and who's going to maintain all of this?

Second: I was not aware that we were designing the EMS Manual. I thought we'd agreed to come up with a few templates for Web pages for the Forests' EMS page.

NOTE: Posted by Dave, since Chris thought these points very-well taken. Hope you don't mind, Elaine.

[Elaine]

I don't mind, Dave. I won't be around much today--real bad headcold. I think we're all saying pretty much the same thing but in different covers. My guess is that it's safe to assume, for now, that everything will go on the Web site (background and supporting materials, ISO stuff). Whether it's in the cloak of an EMS manual or not doesn't make much diff right now, given that we don't yet know what the EMS manuals will look like (I'm still trying to talk to our contractor about that). What I've heard so far is that it will likely be a document with links in it (as we've been assuming). It's tricky, IMO, bec we don't know what the EMS docs themselves will look like, and each Forest may well be doing something a bit different. Or maybe not.

So, let's figure out what this thing might look like--so far the common ground seems to be a list of the 17 required ISO elements. For each element there could be two links/buttons: 1 for the procedure, 1 for the supporting materials.

Here's a not-so-bad example of a basic manual: http://www.p2pays.org/ref/08/07378/0737829.pdf

Click the link to the Elgin AFB EMS Manual--it's better: http://p2library.nfesc.navy.mil/ems/basics/manuals.html

And I do encourage user-friendly reports and docs. ;-)

As for how the actual files will be managed and named, it sounds like Dave has good ideas. But where will the files live?

[Dave Iverson]

Elaine,

As I see it the files (that we need to agree on namimng conventions for) will live in various places, on Districts, Forests, ROs, and the WO.

If these files are stored in places (or ways) so that they can be that can be hyperlinked to both intranet and internet sites we will be ahead of the game in two ways.

First, people will be able to update them easily and maintain them locally.

Second, any closer-to-the-organizational-center "needs" can be satisfied as needed by drawing from file systems owned by folks in various places. And the process works just as well when folks closer-to-the-field need to draw from files maintained closer to the center.

[Dave]

The more I look into The GreenWare stuff, the more I like it. Stay tuned as I try to elevate the conversation.