Conference netcad::hub_mgnt

1868.0. "Late products = lost business" by CGOS01::DMARLOWE (Have you been HUBbed lately?) Wed Jan 11 1995 01:27

Below is an Email I sent after we suffered a major loss in a hospital.  As 
certain functionality was not in place as per the original schedule, we 
were not able to bid the best solution and the consultant selected 3COM for 
the 10/100 switches and the 10BT repeaters.

I feel 3COM will be more of a threat than Synoptics and Cabletron so it is 
imperative that products come out on time.  We can no longer afford to have 
slips in new functionality.

I would encourage anyone who has suffered a loss to document it and forward 
it as this is the only way to get visability.  With that, maybe NAC can get 
the go ahead to get the resources needed to keep the products rolling out 
on time.

dave

=============================================================================


                    DIGITAL INTERNAL USE ONLY Document

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     19-Dec-1994 14:03 MST
                                        From:     DAVE MARLOWE@CGO
                                                  MARLOWE.DAVE
                                        Dept:     SWS
                                        Tel No:   (403) 295-4403

TO: See Below
 
Subject: Critical hospital loss to 3COM                                         

Bill and Bill,

Here are the details on the loss of a major network opportunity to 
3Com.


In Calgary, we responded to an RFP from (Control Data Systems), the 
consultants for a system and network plan for the Calgary General 
Hospital.  The proposal was for a brand new network design for the 
hospital.


The LAN was designed to handle administration data, client server and 
medical imaging.  With the amount of user data anticipated, the consultants 
decided that multiple FDDI's should be connected to a pair of GIGAswitches, 
one hot and the other standby.  This part of the sale is in tact and 
Digital realized $200K of revenue.


Examination of the data flow created by one application and the 
potential widespread use of medical imaging resulted in a network
design based on FDDI to the 16 SER's (satellite equipment rooms) instead 
of Ethernet.  Each SER has from 24 to 72 users.  The rules of 
connectivity became 12 users per Ethernet segment and 10 segments per 
FDDI link back to the GIGAswitch.

The network design from Digital became:

16  DEChub 900MS
16  DECswitch 900EF
42  DECrepeater 900TM
$440K total list cost

There are 504 users but the rules state that only 12 users per Ethernet 
segment.  For a SER of 24 users the equipment list became:

1  DEChub 900MS
1  DECswitch 900EF
2  DECrepeater 900TM
$23K ($19K with 1 repeater)

A single DECrepeater 900TM can support 32 users but can only connect 
to 1 Ethernet.  As a result we must place 2 repeaters in the hub, 
connect 12 users to each repeater AND LEAVE 20 PORTS OPEN ON EACH 
repeater.  The $23K 2 repeater solution could have been reduced to $19K
and only 1 repeater.


For a SER with 72 users the same problems arise.  With 12 users per 
Ethernet, 6 Ethernets are required to meet the rules.  Again, with 
the DECrepeater 900TM this meant the hub would be configured as follows:

1  DEChub 900MS
1  DECswitch 900EF
6  DECrepeater 900TM
$39K ($27K with 3 repeaters)

Whereas 3 repeaters with per port switching would provide 96 ports to 
the 72 users leaving 24 ports open instead of 120 ports with 6 
repeaters.  The $39K 6 repeater solution could be reduced to $27K and 
3 repeaters.


Using presently available modules the total list cost of the solution 
comes out to $440K.  Had the DECrepeater 900TP (per port switching) 
been available as originally scheduled in September/October FY95, we 
would have quoted them.  This would have reduced the repeater module 
count from 42 to 23, thus saving $75K.  The result would have been a 
total list cost of $365K.


The GIGAswitches are safe as no other competitor has anything quite 
like the FDDI switch.  However, we were planning to use the hospital 
as a reference site for other hospitals with poorly planned LANs.  
Instead, 3COM has a reference site for their new Link Builder series.  
The 3COM solution involved the same 16  FDDI to 6 port Ethernet switches, 
some 7 or 8 FDDI concentrators to connect the switches to the GIGAswitch 
and some 42 12 port Ethernet repeaters.  I believe that all this 
equipment is stackable in nature.


3COM appears to be a much more serious contender than either Synoptics 
or Cabletron.  Next in line, after 3COM, may be Cisco/Crescendo.


The DECrepeater 900TP and 900CP (per port switching modules) were to 
go into volume production in October '94.  Now they appear to be coming 
out in April.  This puts this module 6 MONTHS LATE.  Again this 
assumes no more slippages.  I have another customer, who after hearing 
the DEChub 900 PID in April decided the the DECrepeater 900CP was the 
perfect module to handle the Ethernet segmentation on their thinwire coax 
environment in the geophysical department.  They were willing to 
accept the October time frame.  January was a manageable time also.  
Now they're told it will probably an April delivery.  To say that the 
customer is upset would be an understatement.


Similarly, Hubwatch has gone through its share of slippages.  Hubwatch 
V3.0 for OpenVMS slipped from February to May FY94.  Hubwatch for 
Windows slipped from May FY94 to October/November FY95.


I have heard that we have lost more than just a few engineers to our 
competitors over the last few months.  Does this mean that we will see 
more slippages in our product line?  Last year in my local office, we 
achieved excellent penetration into the network market at the expense 
of our competitors.  However continuing slippages in products will 
start to undermine the efforts in the field.  If we don't have 
products to deliver then our customers will just go elsewhere.  If 
networks are making a profit, then insure that all the pieces are in 
place to start delivering the products on time.  If we are truly 
a competitor in the network market, and we are making a profit, then 
we should pay our engineers just like the Cisco's and Cabletron's.  We 
need to insure that we have the engineers to do the work and that they 
have the tools necessary to keep the field's appetite filled with 
products to sell.  Networks are a critical "core" business and should 
be given the resources to do the right thing so long as they continue to 
be profitable.


Products such as per port switching are now extremely critical to our 
continued network success.  As these products slip, we will start losing 
more $400K opportunities by not being able to deliver the correct 
functionality at a competitive time and price.  Get more people developing 
the products and the field will repay the investment by ensuring that those 
products are aggressively sold.  We proved it with the DEChub 900 last 
year.

Regards,
Dave Marlowe
System Engineer
Western Canada NPBU

Distribution:
 
TO:  Remote Addressee                     ( _DELNI::MARO )
TO:  Remote Addressee                     ( _NAC::MELLO )
 
CC:  Remote Addressee                     ( _DELNI::WALKER )
CC:  MARK GEORGE @TRO                     ( GEORGE.MARK AT A1 AT TROA01 )
CC:  PETER SEREDA @TRO                    ( SEREDA.PETER AT A1 AT TROA01 )
CC:  Remote Addressee                     ( _JUMP4::JOY )
                    DIGITAL INTERNAL USE ONLY Document

    

Dave,

That's a great (and very sad) story.  There really is no excuse for such things.

I (and I'm sure a great number of folks here in Engineering) would be most
interested in seeing any response(s) you get from the addressees of your note. 
Specifically, I would be very interested in seeing responses which contain real
action items to resolve this problem.  Any response containing standard
managerial rhetoric can be filed to NLA0: (or /dev/null if you're an ULTRIX
kinda guy :-)).

...Roger...

    Folks - 
    
    I tend to think that if we'd produced:
      - Better specs so folks could BUY the right stuff
      - Better documentation (to obviate this notes file)
    
    Less engineering time would be in the NOTES files and break/fix mode
    and more on timely engineering.  I tend to think that we need to focus
    and direct x% of engineering effort on documentation/spec quality
    output to help increase the throughput.
    
    i.e. Industrial Engineering
    
    regards,
    j