|
| |
| The most frequently asked question during the decision process to license
the ARCLOGIX software, or by existing users has been: |
| |
|
"Will you modify your software to
accommodate my unique business process?"
The answer is always yes with the caveat that the modification must become part of our base software, and
therefore represent a more universal application beyond the company making the request. All modifications to
 are reviewed in-house before a decision is made to change the software. Existing users from like
industries are queried. Trends in TMS functionality are questioned. If all steps indicate "go with
it", the modification is made and incorporated into the base software for the next annual release.
(See Release Cycle and Version Control below.) |
|
"The primary reason
we selected you
was, unlike your
competition, you
were willing to
modify your
software to meet
our requirements."
-- SAKS, Inc.
|
| |
|
| |
| "What is your implementation process and how do you train the end user?" |
| |
| The implementation process has evolved over many years, beginning with the
retailer, T.J.Maxx where "mock" screens were jointly developed and used as the benchmark during
acceptance testing. Today the process is more rigorous. In conjunction with the customer, ARCLOGIX develops a
Systems Design Document (SDD) that details exactly the system's functionality, interfaces and the process
flow in the system's use. The SDD then becomes both the requirements document, guiding implementation for
the customer and ARCLOGIX, and the "bible" for acceptance testing. |
| |
| Almost three years ago ARCLOGIX transitioned from a traditional classroom venue for training
with structured exercises, to a non-traditional, but practical "learn-by-doing" training approach.
We became aware that end-users and non-transportation (e.g. IT) staff either never understood, or forgot most of
the software's functionality and the rational for the TMS' results. |
| |
| In training PETCO's staff, they suggested that training should parallel exactly how they
would use the TMS on a daily basis. That experience drives the way ARCLOGIX trains today. Using the process flow in
the SDD, ARCLOGIX leads key end-users in a detailed, hands-on use of the TMS, explaining each step as they go. These
key end-users then become the trainers for their co-workers. |
| |
| First, training begins at the start of the implementation, with end-users assisting in
setting up the system parameters and loading the address and carrier rate data. Retention of the information and
familiarity with the system far exceeds the classroom-like experience. |
| |
| Second, a mock go-live period occurs where the system is used as if actual TMS planning
events are occurring. ARCLOGIX implementers are on-site acting as TMS planners with the customer's staff. Rather
than the controlled classroom environment where "errors" are absent from the training exercises,
system failures, data anomalies, and the pressure of day-to-day system hiccups are observed, with the ARCLOGIX implementers
acting as mentors throughout the process rather than as mere presenters of prepared classroom exercises. (ARCLOGIX
implementers have lived with the system from day one, and the customer's staff are more likely to know what
aspects of the system's use and which individuals need more of their focus.) |
| |
| Third, ARCLOGIX implementation staff are on-site immediately before and during the actual
go-live event, a period found to represent the highest level of anxiety for the user. |
| |
| Training then, is not really a valid characterization of the process of a client learning how to
best use the software -- rather the process represents a getting one's hands dirty in rolling-out the system;
with ARCLOGIX staff learning how the client wants to conduct their TMS business, and the customers' staff learning how
to push the ARCLOGIX software to its limits. |
| |
|
| |
| "How frequently do you release a new version of your software and how do you
manage version control?" |
| |
| Enhancements to ARCLOGIX's software are continuous throughout the year. New upgrade releases
occur in May / June of each year. (Generally, and particularly for retailers, this time and through the summer represents
a reduced traffic time making updates easier.) |
| |
| Because existing customers may not choose to upgrade to newer versions, version control could represent
an issue. |
| |
| The software uses the object-oriented concept. The base software is developed as individual,
class-based objects (with sub-objects) that define the basic functional operation, down to the screen level functions by
particular data elements. The way the objects are executed, the processing of the data by the objects is the transportation
(TMS) model. Beyond the base software are customer specific functions, defined as objects. These objects include: Interfaces,
optimizing algorithms, cost allocation algorithms, data calculations and additional data elements. The particular objects
making-up a customer's release are pulled together to define that customer's executable. A "catalog"
of objects and their owners is maintained under source code control. |
| |
| Version control is maintained when building a release by specifying it's component objects and
transportation models.
|
| |
| New versions are defined by marrying the predecessor version's objects with the newer versions
of these objects. In many instances customer specific objects may become part of a new base release, making these customers
easier to update. If not, customer specific objects may require modification for compatibility to the new release. |
