A practical approach to work-management integration
Approach to Defining An Interface Model
Set Clear Scope Boundaries
Set boundaries first! The scope can be thought of as a cube that expands and contracts in three
dimensions. As you increase one dimension, the other two increase proportionally. Figure 1
illustrates the three dimensions of WMS project scope, with the processes as the width and the
functionality as the height. These first two dimensions must be well thought out before determining
the depth – or how your system interacts or interfaces with other systems.
Setting the boundaries of the processes and functionality is one of the single, most important steps to controlling scope throughout the WMS project. The more processes within scope the more functionality and the more functionality the more interfaces. Pursuing areas cut from scope later in the project
can waste huge amounts of time. Save yourself the headache and make the scope small up front.
Here are some pointers to setting scope.
First determine the processes within the project scope. Figure 2 (below) provides a typical example
where some processes surface as clearly within the scope of the project (on the right) and others are
less clear (on the left).
When evaluating the ‘undetermined’ processes, review those processes that are in scope and define
why they are in scope. Then see if any of the undetermined processes meet those criteria. For
example, the five processes ‘in scope’ in Figure 2 may have the characteristics that distribution crews
(vs. service or trouble crews) perform the work and that no work is done entirely by contractors
(ruling out construction of new facilities). Reviewing the ‘undetermined’ processes shows that the
Street Light Installations and Stakeout of Facilities also have these characteristics and should be
included in the scope.
Once you have a clear understanding of what processes are in and out of scope, determine what
functionality within those processes is in scope (or the height of your scope). This is more complex.
In order to make this determination; you will need to answer a number of detailed questions such as:
- Will service requests be initiated in CIS or WMS?
- Will designs be done in the GIS application?
- Will the WMS provide return on investment and generate customer invoices?
- Will we implement a WMS mobile application?
- Will the WMS have actual dollars or only estimated dollars?
- Will time be entered in payroll or in WMS?
Answering these questions is the challenge to nailing down the scope. There are two key components
to being able to answer these questions:
- are the capabilities of the WMS package or application in these functional areas?
- What are the capabilities of the existing systems in these functional areas?
Answering these questions and defining the scope of functionality requires an understanding of the
existing corporate systems that surround the WMS solution.
Understand the Capabilities of Your Existing Systems.
In order to evaluate the solution holistically, the project team needs to have a basic understanding of
the corporate (and some external) systems they impact and needs to develop a dialog
with the subject-matter expert from each functional area. Begin the dialog with the subject-matter experts as soon
as possible. In the end you will need to work closely with them on designs and project-management issues (including
budget !). Figure 3 provides a view of the vast number of systems that may play a part in an integrated WMS solution. Build an
understanding in key areas of the systems such as:
- The basic functionality of the system as it relates to the processes in your scope, including key
data entities and system events.
- Basic architecture of each system (technical platform, application architecture, existing interfaces,
etc.).
- The type of maintenance and support that occurs – vendor vs. in house.
- Technical limitations that may present risks to integration (system availability, hardware, data
volume, distribution, performance or connectivity tools).
- Ongoing initiatives for enhancement or replacement of the system or its modules.
- The budget and resources for the coming year.
A basic understanding of the capabilities of your existing systems (Figure 3) provides a foundation
for answering the detailed questions concerning WMS functionality posed above and lays the
groundwork for understanding how the WMS solution will integrate with these systems.
A note about technology, middleware and the technical architecture of the integrated solution. You
should have a technical architect as part of your team. They will help the team to make decisions
from a technical aspect and will look for holistic technical solutions wherever possible.
