Data collection: Nutech vs Sierra

[Dan Thomas <DThomas@xxxxxxxxxxx>]

I've posted on this topic before, but there are some significant
architectural differences between Sierra and Nutech.  We use Nutech and my
Sierra information is about one year old, but anyway...

Nutech has developed RPG programs to present data collection screens on RF
scanners for most JBA transactions.  They can operate on any scanner
supporting 5250 emulation.  All data is validated during entry and when a
transaction is complete they post the data to JBA.  They use a transaction
manager on the AS/400 that opens virtual screens on JBA and "maps" the data
into standard JBA interactive applications.  The transaction manager job is
shared by all scanner users, so you can have 50 active scanners all sharing
the transaction manager and this would only count as one JBA user.  It
operates in an asynchronous "store and forward" approach meaning the scanner
transactions are put in a queue and may actually occur against JBA a few
seconds later, but the scanner operator doesn't have to wait for them to
complete.  Nutech does, however, track the transactions in their own
database so there aren't any problems with timing.  The advantage to this
screen mapping approach is that you are using tried and true JBA programs to
update your data files (along with all the standard audit trails) and any
modifications you've made will be automatically used.  They do have the
ability for a single scanner transaction to update multiple JBA screens.
For example, in our company a single warehouse putaway transaction does four
things in JBA: 1) Moves the lot from goods inwards to stores in Purchasing
2) Runs the process receipts for putaway job  3) Runs the putaway list job
4) Performs the process putaway task -- with all of this transparent to the
user.  The disadvantages to Nutech's approach are twofold.  First, if you
need "off-line from AS/400" operation it is not supported.  This isn't a
concern of ours.  Secondly, I'm sure there are more processing cycles used
to stuff keystrokes into virtual screens than simply directly updating
files.  Since the transaction manager is shared, it can't make any
assumptions about its "state", so before every transaction it will, for
example, do a 80/WHP change warehouse to be sure the warehouse is correct.
It is very helpful though, to be able to turn on the screen capture mode and
watch all your transactions played back by field by field.

Sierra uses a client / server approach.  They don't typically encourage
using 5250 emulation on the RF scanner.  They have a C program that runs on
the scanner and handles input and output processing.  It is table driven and
allows screen displays and field prompting to be changed without
programming.  It has exit points that instruct it to look to RPG programs on
the AS/400 for "next step" guidance and data validation.  At the time they
made their proposal to us, their client program was only supported on the
Intermec Antares 2425.  This may have changed.  You can run these same
programs from the AS/400 using 5250 emulation, but then you lose the main
benefit they tout, which is the ability to operate off-line from the AS/400.
They update JBA in two ways.  For transactions where standard background
jobs exist (like several of the warehouse confirmation processes) they use
those tasks via dataqueues.  For other transactions (like product receiving)
they have routines that directly update JBA files.  We never achieved a full
comfort level with Sierra doing direct file updates on our system, and even
the background transactions weren't a good solution for us because we don't
use them now and they don't have all our modifications.  I'm not in any way
saying Sierra is unable to do this correctly.  I'm sure they can.

Both companies have a long list of standard transactions they support.  I'm
sure every installation they do has a significant amount of customization.
We felt Nutech's list of transactions was a little more extensive and was in
use at more sites and we liked several of their utilities for managing the
system and viewing transaction audit trails.  

Dan Thomas
Sr. VP Information Systems
MDI
4500 Progress Blvd.
Louisville, KY  40218-5058
Phone (502) 454-9013 ext. 120
www.mdiweb.com


-----Original Message-----
From: tammy shane [mailto:tshane@ardencompanies.com]
Sent: Wednesday, August 30, 2000 11:04 AM
To: JBAUSERS-L@midrange.com
Subject: Re: Sierra Data Collection


We selected Nutech too and are just at the very beginning of that process.
One thing from a technical side to dig into with all of the vendors is how
the data gets from the data collection software into the System 21 files -
screen mapping into the actual System 21 update routines or direct file
updates.  Nutech and Sierra seemed to handle the updates to the System 21
files differently, and you may have a preference for one method over the
other.


----- Original Message -----
From: <Jeff_Klipa/Harvard@harvardind.com>
To: <JBAUSERS-L@midrange.com>
Sent: Wednesday, August 30, 2000 10:09 AM
Subject: Re: Sierra Data Collection


> We are ourselves in the middle of an implementation project for SFDC and
> did consider Sierra as a potential vendor...  I asked our project manager
> what his experience was with them and this is what they said...
>
> "We went there to Sierra and weren't that impressed, they were very
> unorganized, their demo was very poorly planned and displayed,  and they
> seemed only sales oriented.  Plus they were running a pirate version of
> JBA, which made us uneasy.  They claim they're a JBA Business Partner but
> [Our JBA (Geac) project manager] tells us they're not.  Too many shady
> things..."
>
> This is apparently why we're not using Sierra...
>
> The inference I can make from this is that we were not big enough for them
> to pay us the same kind of attention they paid to a giant like Lear...  Or
> perhaps they already had all of their best people assigned to the Lear
> project and that left the second string for us...
>
> I don't know, I wasn't there so I cannot comment from personal
> experience...  I can only share what our implementation team's experience
> was during the vendor selection process and I hope to present a more
> balanced view...  I'm glad Lear had a good experience with them...  As I'm
> sure other customers have had as well...  Unfortunately, sometimes things
> don't always go well in the demo so we'll never know if Sierra would have
> been better then the vendor we eventually chose...  NuTech...
> http://www.nutechsystems.com/
>
> NuTech is having their own share of problems getting our first plant up
and
> running so I'm not prepared to give them a glowing review just yet
> either...
>
> Good luck...
>
>
> +---
> | This is the JBA Software Users Mailing List!
> | To submit a new message send your mail to JBAUSERS-L@midrange.com.
> | To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
JBAUSERS-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: doug333@aol.com.
> +---
>

+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to JBAUSERS-L@midrange.com.
| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: doug333@aol.com.
+---
+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to JBAUSERS-L@midrange.com.
| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: doug333@aol.com.
+---