Best Practices for Selecting an EMIS
While many organizations invest significant time and money in these systems, some are a lot more successful than others. Success means full global user acceptance and achievement of corporate objectives on time and on budget. Failure ranges from user dissatisfaction and more investment to make the system work, to full replacement. So how do you maximize your chances of getting it right the first time?
Perhaps the most important factor in the long-term success of a new enterprise EMIS is the selection of the software package. This seems obvious, but with a growing number of options, it takes more internal analysis to identify the best solution for your organization.
Fortunately, by following some oft- overlooked but common sense best practices, you can ensure the system your company ultimately selects is the best long-term fit. This approach will ultimately decrease implementation, training and support costs, increase user satisfaction, and allow your organization to meet or exceed its goals. No system is a perfect fit for all companies, but by following these principles, you can ensure your system comes close:
Pack a compass
Carefully define the business objectives and value of the system.
All too often, the hunt begins with a single individual or small group that has a notion of what advantages an EMIS might bring. They start inviting software providers to demonstrate their products and then make a selection after reviewing the functionality of a few options.
The problem with this approach is that it tends to focus on software features rather than business solutions. This can lead to a great deal of backtracking and frustration down the road as others become involved, offering their own perspectives on what is important.
Defining a set of clear business objectives at the outset is the single-most important step of the process. Cut corners here and soon your team will be wandering around in the fog without a compass - in both your selection process and your subsequent implementation project. Before making that first phone call to potential vendors, your team should discuss some basic questions:
- Why are we investing the money?
- What business problems are we trying to solve?
- Why is what we are doing now inadequate?
- Who else will be affected by the decision?
Examples of common business objectives include:
- The ability to manage an energy-intensity reduction program
- Support for mandatory greenhouse gas (GHG) reporting
- Reduction in corporate-wide incident rates
Less specific objectives may include the replacement of multiple applications with a single system or a reduction in paperwork or system management time. However, these are just examples. It is critical that your organization identifies and carefully defines the critical objectives by which all stakeholders will measure the success of the project.
Once your objectives are set and you begin the selection process, share these with your prospective EMIS providers. If a provider comes in and immediately launches into a feature-packed demo without first inquiring as to what your objectives are, it should send up red flags.
Open your arms
Engage a broad array of stakeholder representatives.
It often happens that an individual or a small group within a company assumes they understand what other departments and members of the company need in an EMIS. Even if objectives are established upfront, those objectives may be too narrowly focused or outright deficient. When it comes time to requisition funds, those holding the purse strings are apt to ask whether or not this person or that department was consulted on their needs. Or, even worse, weeks or months into the process another department sees the solution for the first time and expresses grave concerns. Suddenly you have to hit the brakes.
It is critical to have the right stakeholders involved from the beginning. Identify everyone who will be impacted by the system and be sure they are represented on the EMIS selection committee. Anyone who inputs or extracts data is a potential stakeholder. Stakeholders should encompass personnel both at the corporate and facility/operations levels and may include representatives from the following functions: Health & Safety, Environmental, IT, Executive-level Sustainability, Operations, Corporate Auditing, Security, Quality and Human Resources, as well as end-user representatives.
Having a broad array of perspectives will also help you avoid arbitrary decisions based on personal preferences. Good software solutions are designed to achieve the business objectives of a diverse group of users. Bad solutions are designed to meet the specific needs of a few. This is one of the least understood but most common problems with highly customized systems. Making it a perfect fit for a small group of users often means that it will be a bad fit in the future when other users enter the picture.
Carry a big stick
Enlist a senior-level executive sponsor with cross-departmental authority and a strategic perspective.
Any new enterprise software system represents a significant investment and typically impacts multiple parts of the company. EMIS solutions are no exception. Without the support of someone with the appropriate authority, you may have difficulty getting buy-in for the new system, if you even get to that stage.
Make sure that you engage an executive-level sponsor, who not only has the authority to push things forward, but who also has that big picture perspective that can keep everyone focused on the company’s strategic business goals. The sponsor also should help define the initial business objectives to ensure they align with these strategic business goals. The sponsor will be an ally who can help you avoid getting bogged down in insignificant details that cost time and money, and distract from the true strategic benefits.
Basics Before Bling
Identify what you need to fulfill your business objectives before evaluating software.
The next step is to define user and other functional requirements that will help you meet your business objectives and achieve a successful implementation. If you embark on software evaluations without having first defined your requirements, it is easy to be wooed by the many features and "eye candy” you see in most software demonstrations. As a result, it can be difficult to identify specific areas where a system falls short.
Examples of common functional requirements include:
- The ability to enter energy usage data and convert to greenhouse gas
- The ability to perform root cause analysis for incidents
- The ability to compare participation in a Behavioral Based Safety program across locations.
Once you have identified your set of functional requirements, rank them. The ranking scale should be simple enough to be easily interpreted but granular enough to ensure you can spot important distinctions. At a minimum, make sure you clearly identify "must have” requirements and that these requirements are actually a pre-requisite to effectively meeting your business objectives.
Go Deep
Carefully evaluate potential software packages and the companies that sell them.
Start by identifying potential vendors. This can be done through trade groups, peers, Web searches or all of the above. Once identified, provide the vendors with your business objectives and ranked requirements, and ask them to self-assess their fit. This does not have to be a formal RFP (Request for Proposals); it can be a very informal vetting process. A collaborative approach with potential suppliers will ensure they understand your requirements and you understand their self-assessment answers.
Once you’ve compiled a list of solutions that meets your critical requirements, ask these companies to demonstrate their software following a script that is based on your requirements. Unscripted demonstrations are easily steered toward a software package’s strengths and away from its weaknesses. Unfortunately, these strengths and weaknesses may not line up with your critical (versus ‘nice-to-have’) requirements.
If you are sure that critical requirements are met, request unstructured, unsupervised access to the system. Ask as many stakeholders as possible to play with the software with little or no prior training. It is critical to have real- world users gauge the usability of the system for common tasks such as navigation, completing forms and running or creating reports. Just because a salesperson made a system look simple to use during a demo does not mean your end users will agree. (And if it looked complicated when the salesperson showed it, watch out!)
Finally, check references and if possible, speak to users that are not listed as references. This not only validates the functional effectiveness of the proposed solution; it is also your only opportunity to assess the past performance, commitment, flexibility and integrity of the company with whom you hope to have a long-term, high value partnership. This is your opportunity to develop an accurate picture of life after signing the contract. Important questions to ask include:
- Why did you choose this solution over other options you evaluated?
- What does your user community like about the software?
- Were you able to meet all of your business objectives? If not, which ones and why?
- Did the vendor meet their proposed budget and timeline?
- How did they handle change requests and resolve problems?
- Do you consider the vendor a partner in your EHS program?
Free Your Mind
Try not to place restrictions on EMIS features based on how things have always been done.
Resistance to change is a natural human tendency. And as a general principle, you should expect an enterprise software system to adapt to your needs rather than you adapting to the software. Implementing an EMIS, however, is a great opportunity to improve your processes. Making a decision to work the same way as before may be important, but it also may be a lost opportunity. Many business reports and workflow processes were developed as compromises based on existing systems, or to accommodate the personal habits and preferences of a small set of individuals. When you’re dreaming of a new system, do not be afraid to envision new solutions to old problems too. This will require more buy-in, but the end result could be twice as good.
Don’t Count Your Chickens
Don’t make assumptions about the availability, compatibility and quality of existing data for integration.
One of the most common mistakes is assuming how a company’s data is tallied and organized. For example, one of your goals may be for your EMIS software to easily tap into your company’s human resources data when a recordable incident occurs. Features that utilize this data may become important criteria in your software selection process. But what if you don’t have the data to utilize those features as you intend?
It is typical to assume that employee data is organized by where they are stationed. This is often not the case, and can present issues when you try to pull personnel information into something like an OSHA log. Data may exist in multiple places with conflicting information, in different units, in systems incompatible with your EMIS software, or may not exist at all. Or, there may be IT security policies that restrict certain types of data from being shared across systems.
IT surprises are easily avoided by taking the right steps early on. Involve competent IT personnel with defining the requirements selecting the systems so you avoid solutions your own company cannot realistically support.
Keep it Simple
Create an easy-to-use solution, but understand its limitations.
While we all hope to find the perfect system, the reality is that out-of-the-box solutions will have some limitations. The trick is to find something that meets your needs and then understand what it does not do. Often you will find that the "imperfection” is inconsequential to your ultimate business objectives, or you will find an acceptable work around. Resist the urge to fill nonstrategic gaps with customization.
It is uncommon for a specific feature to be essential to a successful system but user acceptance always is. The best way to ensure acceptance is to keep it simple. Keep this in mind throughout the process as you define requirements, analyze software packages and, ultimately, during implementation. Simplicity vastly improves the day-to-day end user experience, reduces upfront setup and ongoing support costs, and typically increases the life of any enterprise software system.
The EMIS selection process can be a very rewarding experience for personnel and organizations that plan and execute strategically. The time invested in the selection process will pay major time and cost dividends during the implementation project. Selecting the system that is the best fit for your organization’s business objectives and functional requirements will reduce configuration time and expense, potentially eliminate the need for expensive customization, and most importantly, maximize the long-term value your organization realizes from its investment. So pull together the best team you can find, take all the good advice you can get, and after your new EMIS is a smashing success, pay it forward by sharing your best practices and lessons learned with your peers who are just getting started!
Related
Sponsored Content
About the Author
