Gestión de Proyectos: AT&T Wireless

se autodestruye
Jack Lee marcó el 24 de noviembre de 2003 en su calendario porque ese sería
el día en que finalmente podría…

Por Christopher Koch

15 de abril de 2004 - Jack Lee marcó el 24 de noviembre de 2003 en su calendario porque

ese sería el día en que finalmente podría cambiar su proveedor de telefonía celular sin perder
su número de teléfono, gracias a un decreto de la Comisión Federal de Comunicaciones
(FCC) . Pero Lee, presidente de Tangara Technologies, una compañía que desarrolla software
para formularios, decidió esperar un día antes de cambiar a AT&T Wireless para dejar que el
caos de la portabilidad numérica se calmara un poco. Nunca imaginó que el caos recién
comenzaba.

Lee pidió su teléfono nuevo el 25 de noviembre. Cuando al día siguiente entró en el sitio en
Internet de AT&T Wireless para verificar el estado de su pedido, se encontró con un mensaje:
“No hemos podido encontrar una solicitud de migración para este número en el sistema.” Por
favor comuníquese con Atención al Cliente.” Fue el comienzo de una odisea de dos meses en
la que Lee calcula que hizo entre 15 y 20 llamadas a AT&T Wireless, envió casi esa misma
cantidad de correos electrónicos y pasó 60 horas al teléfono lidiando con representantes de
atención al cliente o aguardando en línea hasta que a veces se cortaba la llamada por
sobrecarga de las líneas.

Después de que lo pasearan por toda la compañía, Lee finalmente descubrió qué sucedía. Un
importante sistema CRM se había caído durante una actualización y los representantes de
atención al cliente no podían crear cuentas nuevas ni acceder a ellas. Los colapsos del sistema,
que continuaron hasta febrero de 2004, atiborraron otros sistemas de AT&T, sobrecargaron los
teléfonos de atención al cliente y lograron que los furiosos clientes huyeran en busca de otros
proveedores.

El desastre no podía haber sucedido en peor momento para AT&T Wireless. Le quitó a la
compañía telefónica miles de clientes potenciales, lo que le costó unos US$ 100 millones en
ingresos perdidos. Pero eso no fue todo. La falla dañó tanto la reputación de AT&T Wireless
que muchos analistas piensan que eso fue lo que aceleró la venta realizada en febrero a
Cingular, por US$ 41.000 millones o US$ 15 por acción, que era menos de la mitad del valor
de las acciones de AT&T Wireless cuando se hicieron públicas en abril de 2000. Si bien el
vocero de la compañía sostiene que ésta se hubiera vendido aunque no hubiera sobrevenido el
desastre porque “era lo que había que hacer”, el fiasco y la resultante confusión no deben de
haber ayudado a AT&T en las negociaciones. “Los problemas de sistema hicieron que AT&T
pareciera un proveedor herido y los tiburones olieron la sangre y empezaron a rodearla,” afirma
Roger Entner, un analista de servicios de telefonía inalámbrica y móvil de The Yankee Group,
una compañía de investigación.

Los errores de AT&T Wireless ofrecen lecciones valiosas para los directores de las áreas de
informática (CIOs) de las empresas. En primer lugar, no es prudente recargar grandes
actualizaciones del sistema con complicaciones externas. La actualización del CRM de AT&T
Wireless estuvo salpicada desde el principio por rumores de negocios de tercerización y futuros
despidos. Estos rumores dañaron la moral del equipo de proyectos, lo que repercutió en su
productividad.

En segundo lugar, debería entenderse que los proyectos complejos requieren de límites de
tiempo flexibles. AT&T Wireless emprendió una actualización que afectó aproximadamente a
15 sistemas antes de que se topara con un límite de tiempo inamovible: la fecha de portabilidad
numérica decretada por el gobierno federal, el 12 de noviembre.

En tercer y último lugar, siempre sirve tener un plan B. Sin él, AT&T se vio obligada a avanzar
aun cuando se tornó aparente que la actualización no se terminaría a tiempo.

Recuperar Terreno Perdido

Cuando AT&T Wireless comenzó a actualizar su sistema CRM en 2003, era una compañía que
había pasado de un indiscutido liderazgo del mercado a ser parte del montón. Su porción total
del mercado había pasado de un 25% como líder de la industria a fines de 2001 a un 17% en
2003, ocupando el tercer lugar detrás de Verizon y Cingular.

Peor aún es que AT&T Wireless intentaba recuperar el terreno perdido con su activo
tecnológico más importante, su red telefónica. AT&T Wireless, una de las compañías de
telefonía inalámbrica más antiguas, había hecho una apuesta temprana a una tecnología
llamada TDMA que no podía soportar transferencia de datos por teléfono celular: un avance
importantísimo para clientes corporativos. Aun antes de que AT&T Wireless se separara de su
compañía madre AT&T en 2001, había empezado a construir frenéticamente un sistema
costoso de red global para comunicaciones móviles, o GSM, que no solo podía soportar
transferencia de datos sino que además tenía la ventaja de compatibilidad global con
proveedores en el extranjero. Solamente otro gran proveedor, Cingular, tuvo que lidiar con el
desafío de construir una nueva red GSM al tiempo que seguía brindando servicio a la antigua.
Los otros proveedores habían elegido tecnologías de redes que soportaban transferencia de
datos.

El GSM era una gran oportunidad para AT&T Wireless, pero significaba también un enorme
desafío en cuanto a CRM. La compañía tenía que convencer a sus antiguos clientes que
abandonaran la tecnología TDMA, que funcionaba igual de bien que cualquiera de la
competencia en cuanto a mensajes de voz, y migrara a GSM, que tenía peor calidad de voz,
según Morgan Stanley. También tenía que convencer a los clientes nuevos que GSM era lo
que se venía y que pronto estarían transfiriendo datos por el teléfono en lugar de por las
computadoras portátiles. Pero los clientes no se dejaron convencer. En 2003, el porcentaje de
clientes de AT&T que usaban GSM estaba en un 15% , según los analistas, mientras que
Cingular tenía 35% de sus clientes ya en su sistema nuevo (en parte gracias a la compra de un
proveedor de celulares con red GSM existente). Las cosas no mejoraban. A fines de 2003,
menos de la mitad de los clientes nuevos de AT&T Wireless elegían GSM, mientras que el
75% de los clientes de Cingular usaba la tecnología nueva, según Morgan Stanley.

En AT&T Wireless, todos estuvieron de acuerdo en que la compañía mantendría sus clientes
existentes y agregaría nuevos si los representantes de atención al cliente podían recibir más
volumen de llamadas y poner las nuevas cuentas de clientes en funcionamiento en menos
tiempo. Los representantes de atención al cliente necesitaban un promedio de 20 minutos para
trabajar en seis o siete pantallas que recababan información de unos 15 sistemas pre-
existentes, dejados por empleados anteriores. El acceso lento a los registros de información de
clientes era una de las razones por la que AT&T Wireless tenía el segundo costo más alto por
suscriptor (detrás de Sprint PCS) entre los seis primeros proveedores nacionales en 2003,
según la compañía de servicios financieros UBS.

Por qué AT&T Tenía que Actualizar

AT&T Wireless instaló el sistema de CRM (gestión de relaciones con clientes) de Siebel en
2001 para manejar sus procesos de atención al cliente. Sin embargo, los procesos
administrativos "constituían una mezcla compleja de sistemas," afirman los ex empleados de la
compañía. Los sistemas de facturación de telefonía, por ejemplo, estaban llenos de planes de
distinto valor y procesos de medición arcaicos. Los sistemas que rastreaban llamadas y
creaban números telefónicos nuevos comunicaban con cientos de miles de centrales en el país
y en el mundo. Para funcionar con AT&T Wireless, la versión 6 de Siebel tenía que estar casi
hecha a medida. Si bien el software contaba con herramientas de integración, los consultores
por lo general recurrían a guiones de punto a punto para unir los diferentes sistemas. Controlar
la situación general en una situación como ésta es difícil en el mejor de los casos. De hecho,
un antiguo empleado de AT&T Wireless que trabajó en el proyecto, recuerda que el sistema se
cayó y no funcionó durante seis semanas del verano de 2002 cuando AT&T Wireless comenzó
a preparar la versión 6 de Siebel para lidiar con la portabilidad numérica. Y cuando finalmente
Siebel 6 comenzó a funcionar, seguía sin poder procesar toda la información que necesitaban
los representantes de atención al cliente.
La siguiente versión lanzada por Siebel, la versión 7, era mucho más poderosa. Siebel
desarrolló una versión del software nuevo específica para industrias que tenía muchas más
herramientas y podía captar más información específica de telecomunicaciones. Las nuevas
capacidades de Internet implicaban que AT&T Wireless podía llegar a reducir el número de
pantallas de atención al cliente a una sola, mediante la construcción de un portal en Internet
que colocaba todos los diferentes sistemas y las fuentes de información juntos en un mismo
lugar. “Esa era la razón de la actualización,” dice un antiguo empleado. “Querían poner todo
en una misma pantalla para poder ingresar clientes nuevos más rápido.

Marc Siegel, vocero de AT&T Wireless, concuerda: “Como necesitábamos procesar más
transacciones, más clientes, hacía falta un sistema más robusto. Así que actualizamos. Esto
iba a facilitarle a nuestros representantes el acceso a información y les brindaría información
más amplia sobre el cliente.”

En la primavera de 2003, la compañía decidió actualizar a la versión 7.5 a los

aproximadamente tres millones de clientes del GSM y del paquete general de servicio radial (la
porción de datos de la nueva red). Los clientes con TDMA continuarían recibiendo servicio a
través del sistema anterior de CRM Axys hasta que pudieran migrar a GSM y al nuevo sistema
Siebel. El proyecto se llamó Odyssey (“Odisea”).

La actualización comienza… mal

Si bien la actualización prometía ganar en velocidad y simplicidad, llegar a ella no fue ni veloz
ni simple. El equipo de IT de AT&T Wireless tuvo que romper enlaces previos de los diferentes
sistemas anteriores con el sistema Siebel 6 para clientes y servidores y volverlos a configurar
para trabajar en Internet. Los procesos administrativos de integración de sistemas eran tan
complejos que no era inusual ver a equipos de veinte o más personas asignadas a escribir
conexiones para un sistema único, cuenta un antiguo empleado. La coordinación entre los
equipos y la responsabilidad del integrador principal del proyecto, Deloitte and Touche,
rápidamente se descontroló. (Deloitte and Touche no respondió a repetidos pedidos de
entrevista.)

Todo se distribuía entre los diferentes grupos y todos trabajábamos independientemente unos
de otros, explica un miembro del equipo de proyectos. Los equipos trabajaban revisando su
porción de Odyssey, por ejemplo, pero al terminar las pruebas descubrían que el código se
había cambiado en otra parte del sistema, invalidando la prueba. “En otros proyectos en los
que trabajé los jefes de proyecto congelaban el código mientras los equipos revisaban sus
partes para poder probar todo sobre la misma base de código,” explica. “Esto no sucedía en
este proyecto.”
Mientras tanto, comenzaban a correr rumores de despidos y de tercerización en el extranjero
de servicios relativos a Odyssey. “Los rumores volvían todo más lento,” afirma un antiguo
empleado. “Cuando suceden cosas así, la gente empieza a buscar otro trabajo. Yo, al menos,
dedicaba tiempo a buscar otro trabajo cuando debería haber estado haciendo las pruebas.”

El Nuevo Jefe

El 10 de abril de 2003, Mike Benson, con 15 años de antigüedad en AT&T, envió un memo a
los empleados anunciando que se iba después de tres años como CIO. Siegel, de AT&T
Wireless, alega que Benson, de 48 años, “decidió jubilarse.” Cristopher Corrado, jefe de
soluciones de seguridad de Wipro, una compañía india de tercerización en el extranjero, fue
nombrado vicepresidente ejecutivo y CIO. Antes de pasar a AT &T Wireless, Corrado había
sido CTO de dos divisiones de Merrill Lynch, donde presidía la tercerización en el extranjero
de sectores del área de tecnología informática (IT, por sus siglas en inglés) de Merrill Lynch.
Los empleados especulaban con que era solo una cuestión de tiempo hasta que comenzara la
tercerización en AT&T Wireless.

“Corrado era el verdugo, todos lo sabían,” afirma un antiguo empleado. “ Veíamos a nuestra
gente ir a reuniones con empleados de compañías de la India. Veíamos pizarras con
preguntas como “¿Qué oportunidad tenemos para tercerizar/llevar operaciones al extranjero?”

Antiguos empleados afirman que no ayudó a la moral el hecho de que en la primera

presentación de Corrado al grupo de IT, proclamara “Vengan a trabajar cada día sabiendo que
podrán ser despedidos.” Supuestamente esto debía inspirar a las tropas a esforzarse más,
pero lograba el efecto contrario, alega otro antiguo empleado. “Todos salíamos de allí diciendo,
‘¿Quién es este cretino pedante?’” Corrado no pudo ser localizado para comentar al respecto.

Se Acerca la Fecha Límite

A medida que se acercaba noviembre, AT&T Wireless era uno de los últimos bastiones de la
industria que se oponía a la nueva reglamentación de la Comisión Federal de Comunicaciones
sobre portabilidad numérica, junto con Cingular y Alltel. La industria había logrado demorar el
cambio desde 1998 gracias a tecnicismos legales y AT&T Wireless contaba con otra
postergación, según fuentes de la industria. Pero el día de Halloween (Noche de Brujas, 31 de
octubre), el Tribunal de Apelaciones de los Estados Unidos para el Distrito de Columbia
rechazó la apelación para posponer la fecha límite del 24 de noviembre, establecida por la FCC.
Un vocero de AT&T Wireless dijo a Bloomberg News que la compañía estaba lista para la
migración.

No lo estaba.
Las cosas andaban tan mal con la actualización del CRM de Siebel que se hablaba de intentar
volver al viejo sistema Siebel 6 antes de la fecha de migración. “Dos semanas antes de la
fecha se estaba hablando de volver atrás,” cuenta un antiguo empleado. Pero los gerentes de
proyecto no habían conservado lo suficiente del antiguo sistema como para que esto fuera
factible. No había un plan B. Los miembros del proyecto estimaban que el equipo necesitaba
dos o tres meses más para reparar fallas y verificar que el sistema funcionara en forma
confiable.

El sistema Siebel no era lo único que AT&T Wireless tenía que lograr que funcionara antes de
la fecha límite. La migración de números inalámbricos requería de nuevos sistemas que debían
integrarse con los sistemas CRM de los diferentes proveedores. Cinco de los principales
proveedores tercerizaban la administración de los cambios numéricos a TSI Communications y
utilizaban software desarrollado por Telcordia. Pero en junio de 2002 (antes que los otros
proveedores anunciaran que utilizarían a TSI) AT&T Wireless eligió a NeuStar, su proveedor
habitual de software y administración. Esto le crearía grandes problemas de operaciones
cruzadas.

AT&T Wireless defendió su decisión diciendo que NeuStar era el proveedor más
experimentado del mercado, ya que había trabajado en la portabilidad de líneas terrestres a
comienzos de los años 80. También afirmó que el software que ofrecía NeuStar era más
completo que el de TSI en el momento en que AT&T tomó su decisión.

Noche de Brujas
La noche de Halloween, el equipo a cargo del proyecto trató de hacer funcionar el nuevo
sistema Siebel por primera vez… pero se cayó. “Y no se levantó,” relata un antiguo empleado.
“No había forma de hacerlo funcionar. Se trajeron técnicos que trabajaron en el sistema por
tres días seguidos para tratar de rescatarlo, pero no tuvieron suerte. El sistema no era estable.

A pesar de que los observadores no pudieron establecer las causas específicas del colapso del
sistema, varios factores desempeñaron un papel importante. A medida que se acercaba la
fecha clave -relatan los empleados- los gerentes de proyecto de Deloitte and Touche aflojaban
los requerimientos de prueba de varias piezas del sistema. Antes que congelar el código del
sistema una vez que comenzaran los problemas, los equipos seguían añadiendo nuevas
piezas al proyecto en un intento de hacer que todo funcionara. Pero las piezas nuevas
simplemente agregaban más errores a un sistema ya cargado de fallas, lo que complicaba el
proceso de encontrar los problemas de raíz y corregirlos.

Era mucho más difícil probar la integración por adelantado y también solucionar problemas una
vez que habían aparecido,” reconoció Michael Keith, presidente de Operaciones Móviles de
AT&T Wireless en una llamada en conferencia sobre los resultados del tercer período de la
compañía.

A estas dificultades se sumaba el golpe a la moral que habían recibido los empleados el 16 de
noviembre cuando el presidente y CEO de AT&T Wireless John Zeglis confirmó los rumores de
despidos. Zeglis les dijo a los analistas en una llamada en conferencia durante el tercer período
que la empresa despediría a 1900 trabajadores. No especificó cuándo se producirían los
despidos ni en qué áreas. Pero los gerentes de IT comenzaron a decir a los empleados que
serían a partir de febrero de 2004, relataron antiguos empleados.

Algunos empleados de IT de AT&T Wireless se apoderaron de un informe preparado por Tata

Consulting Services de la India que delineaba planes para tercerizar sectores de la
infraestructura de IT de AT&T Wireless. El informe, obtenido por CIO, también trazaba planes
para tercerizar una parte del soporte y mantenimiento del nuevo sistema Siebel. “Uno se
preguntaba para qué estábamos trabajando tanto si todo eso igual iba a desaparecer,” relata
un antiguo empleado del proyecto.

El 19 de noviembre el diario The Wall Street Journal publicó una nota sobre los inminentes
despidos en AT&T Wireless y los planes de tercerización y el CIO Corrado respondió en un
memo a los empleados. “Estamos en la incómoda posición de que la prensa haya hablado
sobre un contrato con HP antes de que pudiéramos hablar con los empleados que se verán
afectados. Acabamos de firmar una carta de intención con HP para entregarles los servicios
prestados por los siguientes equipos: Servicios de Escritorio, Servicios de Campo Minorista,
Oficina Comercial WAN/Telecom, Empaque MSI, Mesa de Ayuda -llamadas por reconfiguración
de contraseñas y consultas de escritorio. Pero Corrado no enfrentó los rumores relativos a
temas más importantes, como que el soporte y mantenimiento del sistema Siebel se
tercerizaría en el extranjero a Wipro y Tata. En cambio, concluyó: “Tercerizaremos tareas en
toda la compañía, incluyendo Atención al Cliente y TI. Continuaremos evaluando la mejor
combinación de recursos internos e internos para lograr los mejores márgenes.”
De hecho, AT&T Wireless planeaba tercerizar al extranjero más de 3,000 puestos de
operaciones informáticas y atención al cliente.

El Segundo Colapso
El equipo Odyssey seguía luchando para hacer funcionar el sistema Siebel cuando el 24 de
noviembre los clientes comenzaron a tratar de migar sus números entre proveedores. Fue ahí
cuando el software que debía procesar la portabilidad numérica colapsó.

TSI y NeuStar habían llegado a “interpretaciones diferentes” sobre los parámetros de

información de la industria en cuanto a intercambio y verificación de pedidos de portabilidad,
conocidos como WICIS (Wireless Intercarrier Communications Interface Speficiations). Entner,
del Yankee Group, sostiene que TSI modificó su versión del parámetro WICIS sin informar a
NeuStar. “Introdujeron cambios en campos e informes que no impactaron en sus cinco clientes,
pero ya no permitieron la comunicación con NeuStar.” Michael O’Brien, vicepresidente de
marketing de TSI, niega que se hayan hecho cambios sin informar a NeuStar, pero reconoce
que los dos vendedores tenían interpretaciones diferentes de los WICIS. (NeuStar se negó a
dar entrevistas para esta nota.) AT&T Wireless alega que los colapsos de TSI anteriores a la
fecha límite impidieron que NeuStar pudiera probar el proceso adecuadamente y el 24 de
noviembre, el flujo electrónico de solicitudes de migración entre NeuStar y TSI se cayó
inmediatamente.

La industria había estimado que se requerirían 2.5 horas para automatizar los puertos, de
manera que los mensajes sobre puertos se programaron con límites de tiempo y fechas. Si el
sistema del otro proveedor no respondía dentro del tiempo estipulado, el puerto que fallaba
debía caer dentro de una papelera electrónica para su procesamiento manual.

El software de NeuStar no pudo responder a los sistemas de TSI antes de que expirara el
tiempo. Los mensajes de error tampoco llegaban en su totalidad. Cuando el Grupo de
Administración de Portabilidad de AT&T Wireless trató de rastrear y resolver los errores
utilizando una herramienta de gestión de flujo de trabajo, esta se caía o se tildaba. Esto
significaba que los representantes de atención al cliente de AT&T Wireless estaban a oscuras
cuando sus teléfonos se iluminaban. Si sumamos a esto los problemas para acceder a Siebel,
era muy poco lo que podían hacer para ayudar a sus clientes. Según Associated Press, en esa
primera semana de migración, más de la mitad de los reclamos ante la FCC fueron por
problemas con AT&T Wireless. La FCC envió una carta a la compañía el 4 de diciembre,
solicitando una explicación, lo que generó un torrente de publicidad adversa.

“Cincuenta mil clientes de AT&T se quedaban sin servicio semanalmente a causa de este
problema,” explica Phil Cusick, de Bear Stearns, un analista de la industria de
telecomunicaciones. Y muchos de ellos, como el consultor independiente Ian Drake, no se
quedaron para esperar que se solucionara. Después de tres semanas de tratar de poner en
funcionamiento su nuevo teléfono AT&T Wireless, Drake se rindió y se pasó a Verizon.

Liquidación por Cierre

A medida que corrían las noticias sobre las dificultades de AT&T, los clientes comenzaron a
desertar en masa. Los problemas continuaron todo diciembre y según el presidente Y CEO
Zeglis, “Nos llevó casi todo diciembre expandir la capacidad de los sistemas para que los
representantes de atención al cliente pudieran tener todo el acceso necesario para poder tomar
las llamadas de clientes al mismo tiempo en que los de ventas procesaban las nuevas
órdenes,” explicó en una llamada en conferencia con analistas, el 22 de enero. “Francamente,
nuestro servicio de atención al cliente cayó en picada.”
Para los minoristas independientes de telefonía celular, lo que abarca el 60% de las ventas
nuevas de la industria, no había opción. “Los vendedores independientes empezaron a
promover otras marcas cuando oyeron que AT&T tenía problemas,” relata Greg Teets, analista
de telecomunicaciones de A.G Edwards. AT&T Wireless se vio forzada a incrementar las
comisiones de los independientes y bajar los precios para tratar de detener la correntada. No
funcionó. Después de añadir 229.000 clientes en el tercer trimestre de 2003, quinto entre los
seis mejores proveedores, AT&T agregó solamente 128.000 en el cuarto, lo que lo colocó
último entre los proveedores principales, con menos de un décimo de la cifra del líder de la
industria, Verizon, que consiguió 1,5 millones de suscriptores nuevos.

En enero, AT&T Wireless había avanzado mucho en los planes de tercerizar en el extranjero
más de 3.000 puestos de operaciones informáticas y atención al cliente, según el Wall Street
Journal. (Se retractó de este plan solamente después de acceder a ser comprada.) Algunos
empleados pasaron a formar parte del programa “Compañeros de Trabajo” de AT&T en el que
se asignaba consultores de compañías indias de tercerización a los empleados de AT&T para
que les enseñaran su trabajo.

En febrero se les in formó a 220 empleados de IT de AT&T Wireless que dejarían de

pertenecer a la empresa a partir de marzo. Según uno de los empleados despedidos, había
otra ronda de 250 despidos planeados para junio y una tercera para septiembre. “La situación
está muy difícil,” relató un empleado en febrero. Los empleados indios “básicamente siguen a
los empleados todo el día y les hacen un sinfín de preguntas.” Otros antiguos empleados
narran que algunos se negaban a colaborar con los consultores. “Se tomaban decisiones sobre
proyectos cuando los indios no estaban,” explica uno de ellos.

El 17 de febrero, Cingular anunció que compraba AT&T Wireless

Ese mismo día, la casilla de mensajes telefónicos de Deborah Sawyer empezó a llenarse de
mensajes. Sawyer, socia de la empresa de búsqueda de ejecutivos Morgan Howard Worldwide
sostiene que recibió consultas de más de 12 ejecutivos de IT de AT&T Wireless que querían
cambiar de empleo.

Pero para su compañía, la odisea había terminado. © 2008 CXO Media Inc.
Nike Rebota: Cómo (y por qué) Nike se
recuperó del desastre en su Cadena de
Distribución
"Pensé que no íbamos a hablar de i2,” gruñó Rowland Wolfram, el
vicepresidente de operaciones globales y tecnología de Nike…

por Christopher Koch

Junio 15, 2004 –CIO-- “Pensé que no íbamos a hablar de i2,” gruñó Roland Wolfram, el
vicepresidente de operaciones globales y tecnología de Nike, dirigiendo una mirada furibunda a
su gerente de relaciones públicas.

Wolfram, que fue ascendido en abril a vicepresidente y gerente general de la división Asia-
Pacífico, exuda Nike por los poros. Tiene la tez rubicunda, los labios resecos y partidos por
mucho ejercicio o mucho trabajo o ambas cosas. Está vestido con ropa informal, pero se nota
el estilo Nike en la remera de cuello alto y los pantalones; éste también se refleja en su defensa
vehemente de la compañía, un orgullo Nike que resultaría arrogante si la empresa no fuera tan
dominante en la industria.

Wolfram llama el “problema i2” a una falla de software que le costó a Nike más de US$ 100
millones en ventas perdidas, hizo caer las acciones de la compañía en un 20%, desató una
serie de acciones judiciales e hizo que el presidente y CEO, Phil Knight, emitiera su famoso
lamento: “¿Esto es lo que obtienes por US$ 400 millones?” Un lomo de burro. Y vaya qué lomo
de burro. En el negocio del calzado deportivo, sólo Nike, con un 32% del mercado mundial
(casi el doble de Adidas, su rival más cercano) y un mercado de capital de US$ 20.000
millones que es más que la combinación del resto de los fabricantes y vendedores de la
industria, podría permitirse llamar “lomo de burro” a US$ 100 millones.

A Wolfram lo pone fuera de sí que mientras que el resto del mundo conoce a su compañía por
su marketing exitoso y su asociación con los atletas más famosos del mundo, el mundo de las
IT considera a Nike como la compañía que hizo un desastre con su cadena de distribución,
específicamente el motor de planeamiento de demanda, i2, que en el año 2000 escupió
pedidos de muchas más zapatillas Air Garnett de lo que el mercado pedía y muchos menos
pedidos de Air Jordan de lo que necesitaba.

“Para la gente que sigue este tipo de cosas, nos convertimos en un ejemplo de
implementaciones fallidas,” se queja Wolfram.
Pero también había una lección para la gente que realmente sigue “este tipo de cosas,”
específicamente los CIOs. La lección del fracaso de Nike y su recuperación posterior está en el
hecho de que tenía un plan de negocios que era ampliamente comprendido y aceptado en
cada nivel de la compañía. Debido a eso, y a la resistencia que ese plan le daba a la compañía,
en última instancia el fracaso del i2 verdaderamente terminó siendo solamente un “lomo de
burro.”

El fracaso de i2: ¿Táctico o estratégico?

Los problemas que tuvo Nike en Junio de 2000 con su sistema i2 reflejan la combinación
funesta típica de las fallas informáticas de las empresas de alto perfil. Primero, surge un
problema de software ligado estrechamente a un proceso de negocios clave, en este caso, los
pedidos a fábrica. Luego la falla envía círculos concéntricos que llegan a los envíos de
productos y se convierten en una ola que se estrella sobre el balance. La ola es tan grande
que la compañía tiene que revelar las pérdidas en una llamada trimestral en conferencia con
analistas o arriesgarse a provocar la ira de la Comisión de Bolsa y Valores de los Estados
Unidos (SEC) , los accionistas, o ambos. Y es ahí cuando llega a las páginas de The Wall
Street Journal, inspirando artículos y columnas sobre la arrogancia de las TI, sus limitaciones,
valor y costo.

La idea de que algo tan común como una falla informática puede afectar el desempeño de una
empresa gigantesca es todavía tan novedosa que sale en primera plana. Pero lo que no suele
entrar en el análisis es si el problema fue táctico (y reparable) o estratégico (lo que significa que
la compañía nunca debió comprar ese software en primer lugar y también que probablemente
nunca le encontrará utilidad). Esto último es una gran metida de pata; lo primero es apenas un
lomo de burro.

Nike sostiene que los problemas con su software i2 de planeamiento de demanda eran tácticos,
y por lo tanto, solucionables. Era demasiado lento, no se integraba bien, tenía algunas fallas y
no se entrenó lo suficiente a los planificadores en cómo usar el sistema antes de que se
lanzara. Nike afirma que todos estos problemas se solucionaron para el otoño de 2000. La
compañía alega que los negocios no se vieron afectados más allá de ese trimestre. Es más,
Nike anunció a la prensa que los márgenes de ganancia del tercer período de 2003 fueron los
más altos de la historia.

Si hubo una falla estratégica en el proyecto de cadena de proveedores de Nike, fue que Nike
había comprado software diseñado para demanda del tipo de una bola de cristal. Arrojar cifras
de ventas históricas dentro de un programa y esperar que salga un número mágico del
algoritmo –el concepto básico detrás del software para planificación de demanda- no funciona
bien en ningún lado y en este caso ni siquiera soportaba el modelo de negocios de Nike. Nike
depende de un ajustado control de la cadena de provisión de calzado deportivo y de lograr que
los minoristas se comprometan con pedidos por adelantado. No hay mucho lugar para una bola
de cristal en esa situación.

De hecho, Nike confirma que dejó de usar el i2 para sus planeamiento de demanda de
zapatillas a corto y mediano plazo ( todavía se utiliza para el negocio pequeño –pero en
crecimiento- de indumentaria Nike) en la primavera de 2001y cambió esas funciones a su
sistema SAP ERP, que está más basado en pedidos y facturas que en algoritmos de predicción.
“Esto nos permite simplificar algunas de nuestros requisitos de integración,” explica el CIO de
Nike, Gordon Steele.

Según Wolfram, la estrategia de planeamiento de demanda de Nike era y sigue siendo una
mezcla de arte y tecnología. Nike vende demasiados productos (120.000) en demasiados
ciclos (cuatro por año) como para hacer cosas solamente por intuición. “Hemos refinado
nuestro sistema de manera de basarnos en modelos históricos y luego se revisan para
asegurarse de que todo tenga sentido,” explica. Los modelos informáticos resultan más
confiables cuando el producto es de venta estable (por ejemplo, cualquier cosa con el nombre
de Michael Jordan) y la intuición del planificador desempeña un papel más importante en
productos nuevos o más volátiles. En este caso, sigue Wolfram, hablar con los minoristas es
mejor que consultar con el sistema.

“Ha habido un cambio en la tecnología de planeamiento de demanda, “ sostiene el

vicepresidente de AMR Research, Bill Swanton, que no quiso referirse al caso Nike
específicamente. A fines de los 90, las compañías sostenían que lo único que se necesita es la
información y se puede planear todo a la perfección. Hoy las compañías están tratando de
planificar consenso más que planificar demanda.” Eso significa dejar de la do la bola de cristal
y centrarse en compartir información hacia arriba y hacia abajo por a la cadena de distribución
con clientes, minoristas, distribuidores y fabricantes. “Si se comparte la información
rápidamente entre mucha gente, se verán las tendencias mucho antes y es ahí donde radica el
verdadero valor de los proyectos de cadenas de distribución.”

Con un Plan de Juego, Se Puede Atrapar el Rebote

Otra cosa que enfurece a Wolfram (su tez rubicunda enrojece intensamente) es la suposición
generalizada de que Nike apostaba a algoritmos y cambió de rumbo cuando eso falló. Wolfram
sostiene que, por el contrario, nunca hubo intenciones de que el software i2 fuera la estrella del
proyecto de cadena de distribución de Nike, uno de los más ambiciosos que emprendió una
compañía de ese tamaño. Fue (y sigue siendo), afirma Wolfram, parte de una estrategia mayor
para integrar el software de ERP, de planeamiento de cadena de distribución y de CRM en una
única plataforma compartida por las operaciones de Nike en Norteamérica, Europa, Medio
Oriente y África (EMEA). “Francamente,” afirma, “nos mantuvimos en el rumbo.”
Nike hizo una temprana y audaz apuesta a la riesgosa y difícil estrategia de crear una base de
datos única, gigantesca e integrada dentro de su sistema SAP ERP para cada empleado de
Norteamérica y EMEA. (La división Asia-Pacífico de Nike estará en una instancia separada del
software.) Esto significaba que todos se pusieran de acuerdo en prácticas de negocios y
definiciones comunes de información antes de que comenzar a correr el software, lo que
constituía una rareza dentro de la gestión de proyectos de ERP.

La dificultad de integrar información en una compañía con un alto nivel de dispersión

geográfica hizo fracasar muchos proyectos de ERP, como por ejemplo el sistema SAP ERP de
la cadena de farmacias Fox-Meyer’s a fines de los 90 y la mala elección que hizo TriValley
Growers en 1997 con el fatídico paquete ERP para la industria de productos envasados para
consumo. Ninguna de las compañías logró que sus sistemas funcionaran correctamente y eso
contribuyó a que con el tiempo ambas cerraran. Otras compañías abandonaron la visión de
una integración informática total e instalaron varias versiones diferentes de sus sistemas ERP
–tanto como 400 versiones o instancias diferentes del sistema ERP de un solo vendedor en
algunas compañías muy grandes, según AMR.

Pero Nike alega que nunca se apartó de su estrategia de instancia única, ni siquiera cuando los
problemas con la primera pieza de esa estrategia, el sistema i2, ocuparon los titulares el 26 de
febrero de 2001. Los mismos gerentes de proyecto que estaban en funciones al momento de
los problemas (el CIO Steele y la cabeza de negocios, Shelley Dewey, vicepresidente de
cadena de distribución de Nike) siguen a cargo del proyecto en la actualidad. La razón de la
supervivencia de Steele y Dewey fue que cuando su sistema falló, tenían un salvavidas al cual
aferrarse: un claro modelo de negocios para el proyecto total de cadena de distribución. De
lograrlo, sostienen que ahorrará a la compañía mucho más de los US$ 400 de Knight y los
US$ 100 de zapatillas rebeldes.

El proyecto de cadena de distribución de Nike supuestamente acorta el ciclo de fabricación de

una zapatilla de nueve meses a seis. Reducir esos tres meses alinearía el ciclo de fabricación
de Nike con el plan de pedidos de los minoristas, que hacen el pedido del 90% de sus
zapatillas seis meses antes de que se las entreguen. Esto significa que Nike podría comenzar a
fabricar las zapatillas a pedido en lugar de hacerlo con tres meses de anticipación y luego rogar
que se vendan. Pasar de fabricar para vender a fabricar a pedido es el sueño de toda
compañía que desea ganar una ventaja competitiva a través de su cadena de distribución. Dell
lo hizo con las PC y fue famosa por ello. Nike quiere alcanzar la misma fama haciendo lo
mismo con las zapatillas.

Pero Nike no ha llegado a eso aún. Y su caso de negocios se basa en un modelo de casi 30
años que según algunos analistas y minoristas perdió conexión con la realidad del mercado
actual. Pero es un caso de negocios en el que los líderes de Nike confían. Es así como los
CIO mantienen su empleo cuando un proyecto se descarrila y es así como consiguen los
fondos para mantenerlo en funcionamiento.

Al igual que muchas verdades, esta es simple, pero profunda: algunos proyectos sobreviven a
los desastres porque todos los que están involucrados en el negocio, no solamente el sector de
TI, comprenden lo que el sistema puede lograr para la compañía y ven el valor que posee.
Después de su infame exabrupto en la llamada en conferencia en 2001, Knight agregó: “Creo
que a la larga, pasará a ser una ventaja competitiva.”

“Nos encantaría que Phil Knight no hubiera dicho lo que dijo,” afirma Steele, riendo. “Pero la
confianza que le tiene a este proyecto nunca tambaleó. Cuando surgieron los problemas con i2,
nos sentamos a hablar de ello y él dijo “Bien, comprendo, sigan adelante.” (Knight no aceptó
ser entrevistado por CIO)

Cómo Nike Construyó un Robusto Modelo de Negocios

Knight, a quien habitualmente no se lo conoce por su autocontrol, ha demostrado una paciencia
extraordinaria con el proyecto de cadena de distribución de Nike. Y la ha necesitado. “Una vez
que empezamos con esto, enseguida nos dimos cuenta de que lo que habíamos pensado que
sería un esfuerzo de dos o tres años nos llevaría más bien entre cinco y siete,” explica Wolfram.

Ya han pasado más de seis años y la etapa final del proyecto se terminará en algún momento
de 2006 a un costo total que pasó de los proyectados US$ 400 millones a US$ 500 millones,
según Wolfram.

El tema de la cadena de distribución de zapatillas de Nike es la centralización. Todo el diseño,

los contratos de fabricación y las entregas de planean y coordinan desde Beaverton, en el
estado de Oregon. La cadena de distribución está construida alrededor de un ciclo de pedidos
de seis meses, llamado el programa “Futuros” que se desarrolló en 1975, en respuesta al
caótico mercado de aquel entonces de zapatillas para correr. En aquellos días, la cadena de
distribución de las zapatillas en el lejano Oriente estaba en su infancia, las entregas eran
irregulares, la inflación, alta y los corredores compraban cualquier zapatilla que encontraran,
sin fijarse en la marca. Nike ganó ese mercado garantizando la entrega y un descuento a
prueba de inflación a cambio de recibir los pedidos con seis meses de antelación. Los
minoristas aceptaron alegremente porque los corredores no se fijaban demasiado en estilos ni
apariencias. Querían zapatillas técnicamente avanzadas que les quedaran bien y de las cuales
hubiera una provisión constante. Los minoristas sabían que sus zapatillas Nike se venderían
sin importar con cuánto tiempo de anticipación las encargaban.

Pero a medida que Nike se fue convirtiendo en global, la cadena de distribución comenzó a
fragmentarse. En 1998, Nike tenía 27 sistemas de gestión de pedidos por todo el mundo, todos
muy diferentes y con poca conexión con Beaverton. Para ganar control sobre su ciclo de
fabricación de nueve meses, Nike decidió que necesitaba sistemas centralizados como sus
procesos de planeamiento. El software de ERP, específicamente el SAP R/3 sería la piedra
basal de la estrategia de Nike, con aplicaciones de planeamiento i2 de distribución, demanda y
colaboración y el software CRM de Siebel también integrado dentro del sistema general,
mediante la utilización middleware (sistemas intermedios) de STC (ahora SeeBeyond).

La paciencia de Nike resultó una virtud también en este caso. Salteó a AFS (Solución de
Indumentaria y Calzado) la versión inicial del software SAP R/3 desarrollado específicamente
para la industria de indumentaria ay calzado. Su archirival Reebok, que se asoció con VF
(fabricantes de los vaqueros Wrangler y los corpiños Vanity Fair, entre otros productos) en un
esfuerzo beta para desarrollar AFS a comienzos de 1996, luchó durante años para implementar
el inestable software AFS, con sus múltiples fallas. (Reebok no aceptó ser entrevistado para
esta nota.) Y si bien Nike compró AFS en 1998, no intentó instalarlo hasta que SAP comenzó a
trabajar en la segunda –y más estable-versión del programa. “Muchos de los que lo adoptaron
temprano estaban sumamente ocupados instalando AFS en 1999,” relata Steele con sonrisa
satisfecha. “Fue ahí cuando comenzamos a pasar mucho tiempo con SAP y mandamos a
nuestra gente a Alemania para decirles lo que nos gustaría ver en la segunda versión.”

Por Qué Fracasó i2

Por desgracia, Nike no tuvo la misma paciencia con la implementación de la primera parte de
su estrategia de cadena de distribución: las aplicaciones de software i2 para planeamiento de
demanda y distribución. Antes que esperar a desplegar i2 como parte de su proyecto SAP de
ERP, Nike decidió instalar i2 a comienzos de 1999, mientras todavía usaba sus sistemas
anteriores.

Según documentos judiciales presentados por accionistas de Nike e i2 en juicios, muchas

cosas salieron mal antes de junio de 2000. El programa de predicción de demanda de i2 y el de
planeamiento de cadena de distribución (que diagrama la fabricación de productos específicos)
utilizaban diferentes reglas de negocios y almacenaban información de diferentes formas,
dificultando la integración de las dos aplicaciones. El programa i2 necesitaba de tantas
adaptaciones para operar con los sistemas anteriores de Nike que tardaba más de un minuto
en registrar una sola entrada en el programa. Y sobrecargado por los millones de números de
productos que utilizaba Nike, el sistema se caía con mucha frecuencia.

Pero estos problemas hubieran sido solamente inconvenientes leves si no hubieran afectado
los pedidos a fábrica. El sistema ignoraba algunos pedidos y duplicaba otros. El planificador de
demanda también borraba información de pedidos seis a ocho semanas después de que se
hubieran ingresado, imposibilitando que los planificadores recordaran qué le habían pedido a
cada fábrica que produjera. Muy pronto demasiados pedidos de modelos Air Garnett
inundaban las fábricas asiáticas mientras que los pedidos de Air Jordan se perdían o se
borraban.

Cuando se descubrieron los problemas, Nike tuvo que encontrar la forma de resolverlos. La
información de predicciones de demanda de i2 y tuvo que ser descargada y vuelta a cargar
manualmente dentro del planificador por programadores, personal de control de calidad y gente
de negocios cada vez que las aplicaciones tenían que compartir información, lo que sucedía
semanalmente. Se trajeron consultores para construir bases de datos que pasaran por encima
de partes de las aplicaciones i2 y se construyeron puentes para que los compartieran las
aplicaciones de i2 de demanda y planeamiento de distribución.

Nike alega que los problemas se solucionaron para noviembre de 2000, pero el daño ya estaba
hecho y afectaría las ventas y el inventario del siguiente período de la compañía. Cuando llegó
el sistema SAP de la compañía, se quitó el planeamiento de corto y mediano plazo de i2 y se lo
ingresó en SAP. Nike sostiene que el sistema i2 de US$ 10 millones era una pequeña parte del
costo de US$ 500 millones del proyecto total, aunque algunos observadores aseguran que el
costo de i2 era mayor.

¿Por qué salieron mal las cosas? Wolfram asevera que Nike se dejó llevar por una falsa
sensación de seguridad sobre la instalación de i2 debido a que comparado con el plan SAP,
era un proyecto mucho menor. (Nike tiene unos 200 planificadores que utilizan los sistemas de
planeamiento de demanda y suministro.) “Nos parecía que esto sería más fácil ya que no
cambiaba nada más dentro del negocio,” explica. “Pero terminó siendo muy complicado.

“¿Podríamos habernos tomado más tiempo antes de implementarlo? “ se pregunta Steele. “Es
probable. ¿Podríamos haber tenido software de mejor calidad? Seguro. ¿Podrían haber estado
mejor preparados los planificadores para usar el sistema antes de lanzarlo? Desde luego:
nunca se está lo suficientemente capacitado.

Nike Aprende a ser Paciente

Nike aprendió de sus errores. No iba a apresurarse con la instalación de SAP. Y si bien los
ejecutivos de Nike de tanto en tanto cuestionaban la complejidad y el costo del proyecto, Steele
nunca pensó en abandonar la estrategia de única instancia. “Dijimos que la instancia única era
una decisión, no una discusión,” comenta Steele.

Nike quería implementar SAP en etapas y de forma geográfica, pero también deseaba evitar
que cada implementación fuera tan específica de una zona que requiriera de soporte
especializado. Eso significaba construir un diseño para la implementación en Estados Unidos
que contemplara algunas de las peculiaridades de la implementación del EMEA, como soporte
de monedas múltiples y diferentes restricciones legales, aunque eso no era necesario para
hacer negocios con los Estados Unidos. Esto requirió crear un formato global para procesos
SAP; las diferentes regiones se pusieron de acuerdo en las minucias comerciales.
Naturalmente, esto hizo que cada implementación tardara más y fuera más compleja.

Canadá, una pieza relativamente pequeña (aproximadamente US$ 300) de los negocios por
US$ 11.000 de Nike fue la primer en implementar, el fin de semana de Acción de Gracias de
2000 (la temporada tranquila que precede la corrida de primavera) los ERP AFS de SAP junto
con un grupo de aplicaciones i2 y el sistema CRM de Siebel. . Steele y ejecutivos regionales
de Nike, vestidos con delantales, sirvieron la cena de Acción de Gracias a empleados del
proyecto que trabajaban a destajo. Le siguieron otras regiones –Estados Unidos y EMEA- en
sucesivos fines de semana de Acción de Gracias, lo que llevó a poner 6.350 usuarios
mundiales en el sistema para fines de 2002. (Las últimas dos regiones, Asia-Pacífico y América
Latina implementarán el sistema para fines de 2006, según Nike.) Steele afirma que nunca tuvo
que comerse su orgullo junto con el pavo de Acción de Gracias, ya que al día de hoy no ha
habido problemas con estas tres implementaciones.

Esto puede deberse al respeto que adquirió Nike por la capacitación, otra debilidad en la
implementación de i2. Los representantes de atención al cliente de Nike Estados Unidos
recibieron entre 140 y 180 horas de capacitación de colegas de Nike altamente entrenados,
explica Andy Russel, director de la transición global de Nike. Los empleados no acceden al
sistema hasta que completan el curso de capacitación, agrega.

Lo Que Phil Knight Terminó Por Conseguir Por Su Dinero

Entonces, ¿qué lograron seis años y US$ 500 por los negocios de Nike? Wolfram alega que la
mejor colaboración con las fábricas del Lejano Oriente redujeron la “pre-construcción” de
zapatillas de un 30% del total de unidades de fabricación de Nike a aproximadamente un 3%.
El plazo de entrega para zapatillas, afirma, bajó de nueve meses a seis (siete en algunos
períodos de alta demanda). Pero John Shanley, director de Wells Fargo, opina: “Los minoristas
siguen diciendo que el tiempo está más cerca de nueve meses que de seis.” Los márgenes
brutos aumentaron levemente desde 2001 pero no en forma significativa.

Los niveles de inventarios se han reducido, afirma el vicepresidente de Cadena de Distribución,

Dewey, bajando el intervalo entre pedidos a fábrica de un mes a una semana en algunos
casos. Pero aquí también, los efectos pueden no estar llegando a los balances con la velocidad
que querría Nike. Los niveles de inventarios siguen estando a merced del voluble público
adolescente de Nike. La rotación de inventarios de Nike fue de 4.34 por año en 2003 según
Footwear News, una revista para la industria, levemente menor al promedio de 4.39 de la
industria y por detrás de los rivales Reebok (5.07) y K-Swiss (4.47).

Nike también está por detrás de sus competidores en integración de puntos de venta directa
(POS) con minoristas, relata Shanley. Expertos en cadena de distribución concuerdan en que
la información de los comercios, más que algoritmos de software, son lo mejor para predecir la
demanda. Pero el sistema SAP de Nike todavía no puede aceptar información de POS, aunque
la compañía afirma estar trabajando en ello.

Hasta ahora, los beneficios más directos del sistema han sido típicos de un ERP: visibilidad
financiera mejorada, gestión de flujo de caja, predicción de ingresos y capacidad de hacer
malabarismos con el efectivo de Nike en diferentes monedas para aprovechar las ventajas de
tasas de cambio, todos beneficios que se ven mejorados por la base única de datos que
contiene toda la información.

Pro Steele confía en que todavía falta lo mejor. “No hemos modificado demasiado nuestros
procesos todavía,” sostiene, “porque no queríamos complicar las implementaciones.” En su
opinión, con el tiempo Nike bajará ese plazo de entrega de seis meses a tres. Pero, advierte,
eso requerirá cambios significativos por parte de nuestros socios minoristas y proveedores
como también de los procesos de Nike.

Le conviene apresurarse. Shanley afirma que el mercado de zapatillas ha cambiado mucho

desde que Nike creó su programa Futuros en los años 70. A los comerciantes minoristas no
les gusta tener que hacer los pedidos con seis meses de anticipación cuando las modas
cambian en un abrir y cerrar de ojos. Los rivales están dando a los minoristas más libertad para
los pedidos lo que erosiona el liderazgo de mercado de Nike en áreas específicas.

Pero debido a que Nike desarrolló un plan en 1998 y se mantuvo fiel a él, la compañía afirma
que puede hacer un esfuerzo global coordinado para acortar ese plazo de entrega. El sistema
que permitirá que eso suceda ya está en su lugar, lo que si se considera todo lo que ha
sucedido en los últimos siete años, es bastante notable. . © 2008 CXO Media Inc.