After the Merger/Acquisition...What Do We Do With All Those GISs?
Identify Constraints of the Evaluation
Technical and business constraints applicable to the future solution must be evaluated. Clear
identification and documentation of these constraints will help frame the evaluation.
Examples of relevant constraints include the following:
-
The financial evaluation must utilize a 5-year horizon.
-
Any geo-spatial solution must be compatible with XXX Customer Information System.
Identify Viable Alternatives
The viable and practical alternatives for resolving the geo-spatial dilemma must be identified.
There may be only three or four options available. For example, migrate to one or the other geospatial
technology, continue with all existing geo-spatial technologies, or implement new
technology. Limit the list of alternatives to those that are truly practical for the new enterprise.
If the list is too long, the effort required to gather and analyze data related to each alternative will
exceed its value to the evaluation process. Focus on those alternatives that will address the key
geo-spatial systems problems facing the new organization.
Typical alternatives may include two or more of the following:
-
Maintain separate geo-spatial data and application in existing platforms “X” and “Y”
-
Migrate all geo-spatial data and applications to existing platform “X”
-
Migrate all geo-spatial data and applications to existing platform “Y”
-
Migrate all geo-spatial data and applications to new platform “Z”
Gather Decision Support Information
A common evaluation standard, such as functionality and performance requirements must be
identified in order to assure “apples to apples” comparison. An example of a common
evaluations standard is “each alternative solution must provide all of the functionality required
across the entire new enterprise”. Other evaluation standards could be used, however it is
important that the evaluation standard be directly related to addressing the geo-spatial systems
problems in the enterprise. Geo-spatial system features, functionality, and performance
requirements must be identified, reviewed, and validated. Base the requirements evaluation on
the confirmed geo-spatial vision, mission, goals, objectives, an constraints.
Build the requirements list into an evaluation matrix to correlate requirements to the alternatives.
Gather information by requirement/function and alternative. Pair and record the data in the
appropriate matrix location. The matrix becomes a tool to gather, store, and evaluate key
information in a compact and accessible format.
Engage staff most familiar with each alternative to find and contribute the needed information.
You may have several teams working in parallel to complete this task, so coordination and
consistency of the information is critical. Use a consultant to provide unbiased information and
to validate the organization’s input. When all gathered information is loaded into the matrix,
strengths and weaknesses present in each alternative will start becoming apparent. Identify the
effort required to create “level” functionality and performance across the identified alternatives.
For each required function in an alternative that is either missing or less robust than the most
capable alternative, identify the effort required to provide an “equivalent” function or capability.
Typical efforts may be to buy an additional software package, develop an interface, code a new
function, modify a database, collect additional data, or write a new application. The cost of the
effort must be quantifiable.
