Abstract:  Beware of this product.  It may not be a good fit for your logical 
environment, consuming more work than manual entry for similar data-your 
mileage may vary.

Full Disclosure:  We are implementing and fielding ARS7x/ITSM7y/CMDB2.z via an 
architecture previously described at length by Dr. Christopher Strauss.  The 
ITSM Data Management Tool (DMT) was exercised and following observations were 
developed.

-          workstation portion of DMT is a collection of spreadsheets and 
conversion macros-translation: must run on machine with Microsoft Office (not 
on any of my servers, be design!!!).   Text files in *.csv format are then 
transferred to server for usage by batchfile-driven importcmd.exe.
-          Foundation data handling is straightforward for companies, 
locations, organizations, support groups, business times, holidays.  Next, the 
fine print--CAUTION:
-          Conversion macro caused individual data values to be enclosed in 
quotation marks within the csv, with other attendant string-handling issues, 
all inconsistently. Behavior was prevalent whenever "&" and "/" were used 
within data, but data containing those were NOT the only quoted strings, and 
were not always quoted themselves (Excel behavior, not peculiar to DMT)
-          Conversion macros created duplicate records in the csv from a single 
xls row, also inconsistently, and rows with above-mentioned characters were 
generally not the offenders.  Data-and conversion-inconsistencies disappeared 
with renaming of groups/organizations to remove the two offending characters.
-          Support Staff creation pose further cautions.  Designation of a user 
as 'support staff' is only justified by user's efforts in a support group, not 
presence in a particular organization/department, at least in our 
environment-and this tool proved extremely awkward trying to handle our 
particular relationship structure.
-          Candidate support staff records are created by template only (design 
of DMT), with said template overriding any other information keyed to the staff 
record itself
-          Support-staff template must also be unique for 
role-to-privilege-to-org/department combination (note-neither support group nor 
company accesses are even mentioned, and mechanism for granting multiple group 
memberships to one individual is cumbersome) (finally---end of CAUTION, from 
above)

The last two points combine for implication: this DMT topology (for support 
staff) might be useful for large numbers of staff in small number of support 
groups (beware, though-a workstation running Excel must gracefully sort and 
convert that large spreadsheet to multiple csv-files in one operation-and 
fifteen separate pages are involved!!). Our environment is approx 300 support 
staff in 93 support groups, and would require over 200 distinct templates.  
Further, the functions of our support groups are both distinct and disjoint, 
while sharing common members.  Yes, that means many support staffers provide 
more than one support-staff function, not unusual for an educational 
environment. Example:  one particular company employs eleven support staff who 
monitor eight activities; each activity is sufficiently unique to qualify for 
separate 'support group' status; and, each individual asserts a unique 
combination of groups monitored.  Therefore, my support-staff effort would 
require eleven templates just for that one company-one template per person, and 
twenty other operating companies to go.  I cannot see the value of creating 
numerous templates which will be used one time only, versus creating staffers 
directly-the DMT effectively multiplies(not reduces!) workload of CREATING 
support staff. The support staff paradigm herein described *might* make sense 
if template-uniqueness were tied to support-group combinations, not 
departments.  Finally, the DMT may/may not exhibit aforementioned misbehaviors 
in other environments.

Our usage of this DMT will probably be limited to data in first bullet above 
only.   Customer-CTM:People records are created/maintained by a customized 
importation with daily updates, so the DMT People capability is not applicable 
to this University, *except* for support staff, and this DMT will therefore not 
be used for people.  What a shame-support-staff management was our initial 
motivation for examining this product at all!!


Don W. McClure, P.E.
Data Administrator & System Engineer
University of North Texas Computing & IT Center
dwmac_at_unt.edu
940.565.3287

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to