1. The Top 10 things to
consider when selecting
an EMIS!
By Jason Brezski and Joanne Schroeder, PE
5000 E. Spring Street Suite 720
Long Beach, California 90815
www.E2ManageTech.com
866-609-3374

2. Sellecttiing an EMIIS::
Se ec ng an EM S
Top 10 Consiiderattiions
Top 10 Cons dera ons
E2 ManageTech, Inc. (E2) is the definition can be a somewhat arduous process when
leader in designing and starting from scratch. Nevertheless, taking the time
implementing Environmental to specify functional requirements is a useful
Health & Safety Management exercise that will help to minimize the chance of
Information Systems (EMISs). buying something that cannot solve your long-term
As a software-neutral company, information management needs. EMIS consultants
we are often asked what are the have extensive experience in requirements
most important things to consider when selecting an definition and can lend a hand to guide you through
EMIS. Based on 12 years of experience assessing the process quickly and efficiently.
and using environmental, health and safety (EHS) It is essential to involve
software, we have compiled our very own “top ten” 2. Involve your IT your Information
list. department early Technology (IT)
EHS professionals seeking a department early in the software selection process.
1. Requirements new EMIS often start the They have important information that must be
Definition process by perusing vendor considered in choosing a software solution. They
websites, attending webinars etc. and, before long, may have a preference or even requirement for
find themselves receiving calls from software vendor software to either be hosted externally or installed
sales representatives. In many cases, the process internally behind your company’s firewall. The
continues on to sales demonstrations and ultimately nature of the installation alone can limit the choice
a vendor selection. The unfortunate reality in this of vendors. In the instance that your IT department
common scenario is that the EHS professionals may prefers software to be hosted, they will likely have
have never actually documented exactly what they standards that the vendors must adhere to
want the software to do. This important step is regarding security, reporting, single sign-on,
called “functional requirements definition.” Some integration with other company data sources and
basic examples of requirements would be: data recoverability. Likewise, if they prefer that
software be installed internally behind the firewall,
• The system must produce Occupational
your IT department will need to know what type of
Safety and Health Administration (OSHA)
hardware is required of the software and will have
300 log;
preferences or rules about which backend databases
• The system must provide escalating email (e.g. Oracle vs. SQL Server) are supported internally,
notifications for overdue tasks” which may further limit the prospective vendor pool.
• The system must provide for waste These preferences and requirements are called
container tracking and aggregation prior to technical requirements and, similarly to functional
offsite shipment requirements, must be
considered when
Software demonstrations given without selecting software. After
consideration of functional requirements will tend to all, your IT department
focus primarily on the strengths of that particular will be responsible for
software package, and will also make it very difficult many aspects of the
to do an “apples to apples” evaluation of various technical support of the
solutions. In the end, the client may unwittingly end system, from system
up selecting software primarily on the presentation availability, network
skills of the vendor sales team. Requirements access, desktop support
page 1

3. Sellecttiing an EMIIS::
Se ec ng an EM S
Top 10 Consiiderattiions
Top 10 Cons dera ons
and, potentially, integrations with existing internal business processes and
systems such as your email application, HR database, 4. Configurability vs. reporting requirements,
work order system etc. Also, IT departments’ Out-Of-The-Box as this will have an
services are typically in high demand; therefore, it is impact on the level of configurability that is
best to alert them early in the process that you are necessary in the solution you select. In the EMIS
considering purchasing software. marketplace, there tends to be a natural divide
between systems that are designed to be very
The number one killer to
3. Avoid “not configurable versus those that are less readily
successful software
invented here” configurable yet designed to efficiently perform
implementations is end-
certain functions such as complex emissions
user revolt! If you are evaluating software that will
calculations, discharge monitoring reports etc. out of
be used by many people in various roles across your
the box. For example, there are many software
organization, you need to identify all appropriate
solutions on the market that can be configured to
stakeholders and get them involved early to ensure
match your unique business process and workflow
their needs are properly considered. Otherwise you
for incident management and corrective action/task
may find that important stakeholders that were left
tracking. Generally, tools with extensive workflow
out of the design process may develop a “not
configurability tend to be more challenged by
invented here” mindset, meaning that the system
information management needs such as data
cannot work for them since they did not have input
collection and reporting to support emissions
into the design. At this point you have a significant
inventory calculations. On the other hand, some
uphill battle to overcome before you even deploy
tools may be adept at integrating with data
the solution. For example, two sites doing the same
historians, crunching data and producing complex
operations in two different geographical locations,
reports, but tend to be more rigid in terms of
reporting to two different site managers, may have
workflow configurability and, therefore, may not be
vastly different reporting needs and, therefore,
the perfect match for your unique incident
vastly different data collection needs. Facilities
management and correction action/task tracking
often have their own methods to track and report
workflows.
information and it can be difficult to sell them on the
benefits of using a central system that may These are certainly tendencies more than rules and
compromise the interface, workflow, and reporting the two sides continue to converge as the EMIS
to which they are accustomed. When their needs software market matures and evolves.
are not properly considered, they may be forced to Nevertheless, it is important for EMIS shoppers to
continue to use their own legacy systems in tandem understand the balance between adjusting current
with new systems and the new system will be business processes to the workflow that is built into
perceived as an unnecessary redundancy. User the software while at the same time ensuring that
acceptance is an important issue that needs to be complex data management and reporting can be
considered early on. The first steps are to identify all readily accomplished by software tools that are
stakeholders, get them involved early to ensure their inherently designed to be tremendously
needs are considered, and do your best to ensure configurable.
that end users have the proper incentives to utilize
the new system.
As you search for a software solution, it is important
to understand how much flexibility there is in your
page 2

4. Sellecttiing an EMIIS::
Se ec ng an EM S
Top 10 Consiiderattiions
Top 10 Cons dera ons
When we engage able to readily produce meaningful output reports
5. Consider the benefit
with clients for a from all that data. This occurs primarily because of
of imbedded best
software design and our sense as EHS professionals that we should
practices
selection process, one record data that appears to meaningful in some way.
of the first items we need to uncover is the current Yet we tend not to envision the analytics that can be
state of the business processes we are seeking to produced from that data at the time it’s being
automate through software. Some clients have very collected. Consequentially, the data is not being
rigid and successful business processes that are not collected in a way that it can be readily rolled up,
subject to tinkering, whereas others recognize that normalized, parsed, etc. and the result is that there’s
there may be opportunities for improvement. For a monthly or quarterly scramble to pull together lots
the latter, it is quite common for clients to expect of data from many disparate sources. It is difficult to
some level of business process improvement to go escape this pattern, even if you are purchasing the
along with the move towards increased data latest and greatest software solution, unless you
automation. This is where we typically get into a make the effort to understand your reporting needs
conversation as to whether or not you need to find a up front. This will inherently define the information
solution that fits your business process like a glove – you need to collect in the system and how the
perfect fit, or like a mitten – it’s got you covered but system needs to be configured to produce the
there’s room to move around. reports you need.
If you have some flexibility in your approach to Equally important is understanding how much can
optimizing your business processes, it is worth be accomplished with standard reports offered by
understanding that most mature EMIS solutions the solution vs. reports that will need to be
benefit from years of tweaking of business processes developed. A software solution that offers great
through input gleaned from scores of EHS dashboarding capabilities out-of-the-box will still
professionals from many different industry require some forethought, some configuration
backgrounds. A typical software upgrade release effort, and organized data. Also, in order to support
schedule is a major release annually and minor ad hoc reporting and/or more
releases and/or patches every few months. Major complex calculations, you’ll need to
releases typically contain fairly significant know if the system has a built-in
functionality enhancements. This is necessary to calculation engine and ad hoc
keep the software perpetually current and querying capabilities and what their
marketable. This constant process of improving an limits are. If not, you’ll want to
already mature and successful product inherently know if the system can integrate
benefits customers with industry best practices that with your company’s standard
are built into the solution. reporting tools.
What is the point of collecting Once you have narrowed
6. Reporting 7. Evaluate the
data if you are not going to do down the software
Vendor, not just
something with it? It is very common for our new market to a smaller
the software
clients to collect all sorts of data in all sorts of ways, number of solutions that
whether manually via paper-based forms and can potentially meet both
spreadsheets, or via numerous freestanding silo your functional and technical requirements, it is time
databases, or even via centrally located widely to get to know the vendor a little better. If your
deployed systems, yet are limited in terms of being purchasing department gets involved, they will likely
page 3

5. Sellecttiing an EMIIS::
Se ec ng an EM S
Top 10 Consiiderattiions
Top 10 Cons dera ons
want to know the financial backing of the company, “Does the system perform as you expected it to
annual revenue, and growth rates etc. All of this is based on vendor demonstrations?” Record the
for good reason. You would hate to be at the hip responses and consider them as you make your final
with the latest and greatest software vendor when decision. Your IT department will likely interrogate
suddenly their venture the vendor from a technical standpoint. It is your
capital pulls out! There are job to make sure they are going to meet your
also other important business needs and have the experience and
considerations that EHS solutions that you are expecting from them.
professionals will want to be Proper phasing is crucial to
aware of, such as, 9. How will software implementation
understanding the module phasing success. It’s very rare that
development roadmap of be prioritized? clients choose to go for the
the vendor. Ideally, the vendor is progressing the “big bang” implementation, meaning purchase all
software in directions that benefit your business and applicable modules and deploy all at once. Although
line up with future phases of deployment that you this approach can be somewhat cost effective when
envision could be useful or even necessary. Also, it considering the economies of scale to be gained in
is good to know if the vendor supports organized negotiating licensing fees for purchasing many
user groups or communities that you can participate modules simultaneously, most clients simply don’t
in and potentially influence their software have the personnel resources and/or funding
development roadmap. available to dedicate to doing a full-scale
The proof is in the pudding. deployment of all modules. Instead, most of our
8. Talk to client
Software vendors can dazzle clients choose to phase the system deployment over
references
with demonstrations tailored time.
to your functional requirements, examples of Some clients do indeed choose to purchase licensing
numerous regulatory reporting outputs and formats, for modules intended to be deployed in future
and dashboards that match the style of your phases in addition to first phase modules in order to
website. But how do you know that everything you take advantage of potential discounts for licensing
have been shown is actually available today in the numerous modules. But even in this scenario, some
product? How do you know exactly how much effort level of phasing for actual deployment is typically
goes into making the examples you were sold on the norm. More commonly, the question is not “big
actually work for you in the system? It is vitally bang” versus phasing, but
important to ask for client references and talk to rather when choosing to
those references about their experiences. People Softtware dep o yments
Sofftwarre depllloymentts
So wa e dep oymen s
phase the modules in, may enttaiiill changes fforr
may enta l changes fo r
tend to focus more on client references that are may en a changes o
how to prioritize the how end users do th e rr
how end userrs do ttheiiir
specific to their industry, but it is arguably more how end use s do he
order of module jjjobs;; ttherrefforre,,, culllturralll
o bs; th ere fo re cu ttura
obs he e o e cu u a
important to make sure you are getting references deployment. It is accepttance off tthe
accepta nce of th e
accep ance o he
for customers who are using the same functional important to recognize softtware s cru c a to
sofftwarre iiis crruciiialll tto
so wa e s c uc a o
modules or components that you are planning to that software tthe success off tthe
th e success of th e
he success o he
purchase, regardless of their industry. It is helpful to deployments may entail a pro e ct.
prrojjjectt..
p o ec
create a questionnaire for discussions with client significant change to the
references, such as, “How long have you been using way end users do their jobs; therefore, it is crucial
the system,” “Was implementation easier or more for the software to become culturally accepted. The
difficult than expected or promised by the vendor,”
page 4

6. Sellecttiing an EMIIS::
Se ec ng an EM S
Top 10 Consiiderattiions
Top 10 Cons dera ons
larger the group of initial end users, the more first line of support when end users have “how to”
important this becomes. questions or need something changed within the
application. This person also typically maintains the
When our clients are deploying modules that will
business relationship with the vendor and
impact a large number of end users, we typically
implementation consultants throughout the lifecycle
advise them to start with modules that will require
of the software solution.
minimal training, yet be frequently used. The idea is
to provide a simple introduction to the system and The percentage of time this person needs to
get the system culturally accepted prior to moving to dedicate to this role varies significantly based on
complex workflows. For example, if a client has their specific implementation but, generally, the role
incident management and auditing/assessments as a will require fairly significant effort during the early
highest priority from a business standpoint, it may months of entering the support role. We typically
be advantageous to start with task tracking since advise our clients to have at least one super user for
both incident management and audits will generate the system but, in order to help spread out the
tasks. Start by rolling out task management to a workload, it may be helpful to assign additional
large group of users and assign simple, yet people to be subject matter experts for each module
meaningful routine tasks. Once you have achieved that are able to help with decision making regarding
success there, you are ready to move on to more configuration changes, conducting training, etc.
challenging workflows. Your IT department will also have a role going
forward, particularly if the solution is hosted behind
Once you move
10. Long-term internal your firewall. They will be responsible for the
beyond your initial
resources for system technical side of things, such as, database
implementation and
administration administration, system uptime, application of
declare it a success,
patches and upgrades etc.
you will move from the implementation phase to the
support phase. Logically, it would seem that at this It is important to recognize early in your planning
point the hard work is over. Realistically though, in phases of the EMIS selection
all likelihood there are far fewer resources available process that there will be long-
to help support and sustain the project than were term internal resources
available during implementation. Therefore, you will required to help maintain the
need someone to be the system administrator. system and keep it current and
useful to your business long
Although you can potentially outsource this role,
after the initial deployment.
most organizations assign someone internally to
own and manage the system. The system Joanne Schroeder, PE, is a Principal at E2 ManageTech and has an
administrator, generally speaking, is not someone extensive background in selecting and designing EMIS’ spanning the
full breadth of EHS topics and in virtually every industry. She has been
from your IT department. The system administrator on the forefront of this industry for the last 15 years. Ms. Schroeder
is usually someone within the EHS organization who can be contacted at jschroeder@e2managetech.com.
was intimately involved with the implementation. Jason Brezski is a project manager at E2 ManageTech and is
The system administrator is basically a super-user responsible for EMIS solution design and implementation. He has led
who understands the business side of the cross-functional teams in the design and implementation of systems
ranging from fully custom solutions to enterprise off-the-shelf
application but can also perform some level of applications. His clients have spanned numerous industries including
technical work on the system such as security pharmaceutical/biotech, chemical, aerospace, pipeline, general
configuration, organizational hierarchy changes, manufacturing, utilities, and public agencies. Mr. Brezski can be
advanced reporting etc. This person is typically the contacted at jbrezski@e2managetech.com.
page 5