Fracaso de software

1. ESCUELA DE POSTGRADO
MAESTRÍA EN INGENIERÍA DE SISTEMAS
Mención: Tecnologías de información y comunicación
ACTIVIDAD N° 3: FRACASO DE SOFTWARE
Docente: Ing. SÉFORA ROMÁN SÁNCHEZ
Integrante: ANGULO QUINTASI, Lear
HUÁNUCO – MAYO 2017

2. I. FRACASO DE SOFTWARE
Para empezar,todo proyectotiene trescaras:clientes,vendedores e integradores.
 Fallas del cliente
La falta de adaptación a menudocomienzacon problemasen lavariable “cliente” de laecuación.En su forma más
común, consiste en la falta de planificación adecuada.DavidBergen,ex CIO de Levi Strauss & Co., quien llevó a
cabo varios proyectos SAP en la fábrica de prendas de vestir, dice que la mayoría de las empresas no están
preparadas para un proyectodeERP, porquelos pasosbásicos no se han realizadoadecuadamente. "Lasempresas
no suelen ser buenas para el cambio. Además, muchas empresas tienen problemas en definir sus procesos de
negocio.Los queluchan con el rediseñode procesos tendrán dificultadesparaalcanzar el éxito y la realización de
los beneficios".
 Fallas del integrador del sistema
Debidoa que losintegradoreshacen eltrabajodeimplementación,con frecuenciason unaparteintegral de todas
las fallas del proyecto. Sus principales ofensas tienden a consistir en el uso de consultores que no están
suficientemente capacitados en los paquetes queestán instalando -a veces inclusoen aspectosbásicos de ERP-
y tienden a ser pobres en regularse a ellosmismos.Ambos factoresderivan directamenteen cómolos integradores
cargan:por hora. (Pocos contratos son buenasofertas.) Comoresultado,el personalmás barato quepuede hacer
el trabajoresulta el mayorbeneficiado,mientras que implementandotareasadicionales produceun compromiso
más rentable.
El conflictode interesesinherente entreel integrador y el clientees unafuentefrecuentede controversia,nosolo
entre los dospartes,sino que con el proveedorde software también.En el 2009, por ejemplo,Léo Apo theker,el
entonces director general de SAP (y ahora consejero delegado de Hewlett-Packard), condenó en términos muy
contundentes como el interéspropiode los integradores (en este caso,Accenturee IBM),llevóa proyectosfallidos
que se reflejaban negativamente en el software, en lugar de hacerlo en los integradores.
 Fallas de los vendedores de software
Los proveedores de software,como SAP y Oracle,tienden a ser culpados por los pecados de sus vendedores -es
decir, prometiendocaracterísticas o software que noexisten o no se pueden entregar.En muchos casos,estoes
simplemente unaverdadextendidao unarepresentación excesivamenteambiciosade losbeneficios,pero devez
en cuando, los proveedores pueden bajar el acantilado por completo.
Consideremos el caso del gigante de procesamiento de basura Waste Management, que demandó a SAP por
fraudeen un fracasado proyectodeERP en el 2008. En su demandaafirmabaqueSAP había mostradoun software
que era una solución "fuera de la caja" para las necesidades de la empresa. En cambio, el software, según la
compañía, fue "una versión maqueta de aquel software con la intención de engañar a Waste Management". El
"software falso" fue utilizadoen varias ocasiones en demostraciones paralos ejecutivos de la empresa. El pleito
de Waste Management se liquidóa principios de este año, con SAP pagando una liquidación en efectivo. 1
II. CASOS DE SOBRECOSTO, RETRASO Y CANCELACIÓN
 Sobrecosto y retraso en sistema de Allstate Insurance (1982). En 1982, Allstate Insurance comenzó a construir
un sistema paraautomatizar su negocio por $8 millones. El supuesto esfuerzo de 5 añoscontinuó hasta al menos
1993 cuando terminó costando cerca de $100 millones.
 Sobrecosto, retraso y cancelación en sistema de London Stock Exchange (1983-1988). El proyecto Taurus de
la Bolsa de Valores de Londresestabaoriginalmente cotizado en 6 millones de libras.Variosaños más tardey más
de 100 veces (13,200%) sobrepresupuesto elproyectofue cancelado,costandoa la ciudadde Londresal momento
de ser abandonado, 800 millones de libras.
 Sobrecosto y retraso en sistema del bombardero B-1 (1985). El bombarderoB-1 en serviciodesde 1985requirió
US $1 billón adicional para mejorar su software dedefensa aéreaque erainefectivo, aunque problemas de software
imposibilitaron alcanzar los objetivos originales.
 Sobrecosto, retraso y cancelación en sistema de Bank of America (1988). En 1988, Bank of America gastó US
$23 millones en un plan inicial de 5 años paradesarrollar MasterNet,un sistemacomputarizadopara contabilidad
y reportes de "trust". Luego de abandonar el sistema viejo, gastaron $60 millones adicionales para lograr que el
nuevo sistemafuncionara y finalmenteterminaron desistiendo.Las cuentas delosclientesperdidos pudieron haber
excedido los billones de dólares.
1
Andrew Binstock, InfoWorld (US)

3.  Sobrecosto y retraso en sistema de control de rastreo porsatélite (1989). El softwarepara la modernización de
la Facilidad de Control de Rastreo por Satélite tomó 7 años más de lo previsto y costó $300 millones adicionales
ofreciendo menor capacidad de la requerida.
 Sobrecosto y retraso en sistema Airborne Self-Protection Jammer (1989). El sistema ASJP (Airborne Self-
Protection Jammer),un sistemaelectrónico de defensa aérea instalado en alrededor de 2,000 avionesde combate
y ataque de la Marina Americana, costó US $1 billón adicional, tomó 4 años adicionales, y sólo fue "efectivo
operacionalmente marginalmente y apropiado operacionalmente marginalmente".
 Sobrecosto en sistema del avión de carga C-17 (1989). El avión de carga C-17 construido por Douglas Aircraft
costó $500 millones adicionales por problemas del software aeronáutico. Un reporte de GAO notó que existieron
19 computadoras a bordo, 80 microprocesadores, y 6 lenguajes diferentes de programación.
III. CASO DE UNA MALA PLANIFICACIÓN
 Mala planificación del nuevo sistema de una administradora de servicios de salud (1997). Según reportóel
Wall StreetJournalel 11 de diciembre de1997, OxfordHealth Plans Inc.,administradorade servicios de salud en
USA, de gran crecimientoen losúltimos tiempos,anunció queregistraríaunapérdidade US$120 milloneso más
durante esetrimestre, además de unapérdidaadicional de US$78,2 millones,su primerapérdidadesdequesalió
a la bolsa en 1991.La razón principalfuela largalistade problemas ocurridos con un sistema informáticoquese
puso en línea en 1996; desde eldiseñodel sistema y su instalación hasta cómo fueadministrado porlosejecutivos
del grupoOxford.Los problemas ocasionaron que Oxford nopudieraenviar facturas mensualesa miles de cuentas
de clientes además de incapacitarla para rastrear los pagos a cientos de médicos y hospitales. En menos de un
año, los pagos nocobrados de sus clientes se triplicaron a más de US$400 millones, mientrasque el montoque
Oxford debíaa losproveedores deservicios médicos aumentóen más del 50%,a unasumasuperior a los US$650
millones. La administradora de servicios médicos comenzó a planear su nuevo sistema informático en 1993,
cuandosólo tenía217,000 miembros. El sistema, desarrolladopor Oracle,no comenzóa utilizarse hastaOctubre
de 1996, cuando el número de abonados a su seguro médico había llegado a 1,5 millones. En ese momento el
sistema ya era obsoleto.En lugar de tomar 6 segundoinscribir a un nuevo miembro, tomaba 15 minutos.A pesar
de esto y que la infraestructura administrativa de Oxford no daba abasto, los ejecutivos seguían inscribiendo
nuevos clientes, en el último añose incorporómediomillón adicional.A finales de 1993,Oxfordtrató de ajustar
el sistema, además de convertir de una sola vez la mayoría de su base de datos para facturación: unas 43,000
cuentas cubriendo a 1,9 millones de miembros. Esto significó la catástrofe final, ya que la transformación entre
base de datos no funcionó, y mientras tanto se suspendió por unos meses la facturación ya que no se contaba
con un sistema de seguridad,ni siquieramanual. A pesar de todoesto, Oxfordsiguió sus prácticashabitualesde
contabilidad, registrandoaquellas facturas quenose habían cobradocomofacturación trimestral.Los problemas
finales surgieron cuando Oxford comenzó a poner al día las cuentas vencidas contactando a los clientes por
primera vez en varios meses. Muchos se negaron a pagar y otros dijeron que hacíamuchoquehabían cancelado
su cuenta. Por consiguiente, Oxford tuvo que registrar US$111 millones como deudas incobrables y reconoció
que tenía30,000afiliadosmenos de lo que habíacalculado.El presidente reconoció que debía haber contratado
un ejércitodetrabajadorestemporales paraqueescribieran a máquinalasfacturas. Porotrolado,loprimero que
perdieron fueron losclientes pequeños, pero comoluegonoresolvieron ningún problema comenzaron a perder
a los clientes grandes.2
2
Weitzenfeld, A.

4. IV. BIBLIOGRAFÍA
 Andrew Binstock, InfoWorld, 2010, El ERP salió mal: Lecciones de fracasos, CIO PERU
http://cioperu.pe/articulo/5798/el-erp-salio-mal-lecciones-de-fracasos/
 Alfredo Weitzenfeld, 2004, Ingeniería de Software Orientada a Objetos, ROBOLAT,
http://weitzenfeld.robolat.org/wp-content/uploads/2016/06/Cap1-Intro.pdf