[14/12/2022] Los vehículos eléctricos son tan distintos de sus primos de gasolina que los fabricantes de automóviles tienen la oportunidad de deshacerse de décadas de sistemas de fabricación heredados. Lo mismo puede decirse de su infraestructura informática. Cuando General Motors nombró a Namo Tiwari director de sistemas de información de su empresa emergente BrightDrop, decidió crear un ERP desde cero en lugar de utilizar el sistema existente de GM.
GM creó BrightDrop en enero del 2021 para modernizar el transporte de primera y última milla con un ecosistema integrado de furgonetas eléctricas y palés motorizados. Cuando Tiwari llegó, seis meses después, el personal de BrightDrop ya estaba hablando con proveedores de piezas y fabricantes, que querían establecer procesos de adquisición.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
"Pudimos gestionar algunos de ellos a través de Excel y Word", comenta. "Era un buen puñado, pero una ventaja que teníamos era que no se trataba de millones o billones de registros".
Sin embargo, había que construir el sistema definitivo antes de que arraigaran esas soluciones ad hoc. "No queríamos construir mucho ecosistema en Excel, Word y SharePoint porque cuando construye los procesos fuera de las herramientas, y luego los trae de vuelta migrando datos históricos, es mucho más difícil", añade.
Una de sus primeras prioridades, por tanto, fue identificar las características clave que la empresa necesitaba en un sistema ERP. Además de las básicas -la incorporación de proveedores, el procesamiento de facturas y la creación de órdenes de compra, que ya se hacían en Excel y Word-, necesitaba algo que pudiera realizar otras funciones importantes de su lista, como la planificación de la demanda en la cadena de suministro y las previsiones financieras.
Pensamiento innovador
Buscábamos algo con lo que pudiéramos aprovechar el 90% o el 100% de la capacidad "lista para usar", porque estábamos creando los procesos empresariales", afirma. "La agilidad y la rapidez son lo más importante para nosotros", afirma, y subraya que tampoco quería pasarse seis meses evaluando opciones. Así que el proceso fue corto, pero no superficial, dice.
El resto de GM funciona con SAP, así que, aunque evaluó ofertas de otros proveedores, ésta se convirtió en la opción natural para Tiwari. Pero no le interesaba utilizar ECC, el ERP heredado de SAP. GM comenzó el largo proceso de actualización de sus sistemas ECC en junio del 2016, y a principios del 2019 había logrado trasladar su libro mayor global a SAP S/4HANA para las finanzas centrales.
Tampoco le interesaba que su pequeño equipo de TI -hoy el equivalente a 19 empleados a tiempo completo que atienden a casi 300 empleados de BrightDrop- gestionara racks de servidores. "En cuanto oye hablar de SAP ERP, es como si dijera: 'Oh, es un elefante gigantesco que requiere toneladas de personas para las operaciones de TI'", afirma.
En su lugar, optó por externalizar estas responsabilidades, recurriendo a la oferta de SAP basada en la nube. "Con S/4HANA Cloud, y especialmente con la nube pública multiusuario, no es necesario desplegar un gran equipo de TI para dar soporte a esta infraestructura", afirma.
Esta elección contrasta con la decisión que GM tomó en el 2012 de subcontratar las operaciones informáticas siempre que fuera posible.
"Cambié toda la dinámica al optar por una solución totalmente en la nube", afirma.
Implementación de procesos
El estatus de BrightDrop como startup también significaba que Tiwari podía darle la vuelta a otras cosas.
"Normalmente, en TI, primero se diseñan todos los procesos empresariales y luego se empieza a implantar la herramienta, para lo que es necesario contar con personas en la empresa que digan: "Así es como funciona mi proceso empresarial". En nuestro caso, estábamos contratando gente y al mismo tiempo implantando".
Elegir la edición pública de S/4HANA Cloud significa que BrightDrop obtiene la misma versión del software que todos los demás, y que la configuración, más que la personalización, es la clave. Eso podría haber dificultado su trabajo, pero, señala, debido a que SAP ya tiene tantos clientes en la industria automotriz, "SAP ya sabía que, en la automoción, así es como ocurre la adquisición", y podría ofrecer una configuración adecuada nada más sacarla de la caja.
A nivel interno, también contaba con la experiencia de propietarios de productos en el equipo con unos 20 años de experiencia en ERP o SAP, personas que conocen la tecnología y el lenguaje que hay que utilizar cuando se habla con el personal de la empresa, y que han visto funcionar SAP en otras tres o cuatro organizaciones antes, lo que les da la confianza necesaria para preparar una demostración sin más y decir a los usuarios que así es como funcionará.
"No fue como una implantación tradicional de ERP, en la que se redacta un montón de documentación o requisitos empresariales, y luego se construye", explica. "Era como ir en paralelo: construir los procesos aprovechando la capacidad lista para usar".
Eso significaba que las cosas podían avanzar rápidamente. "Empezamos el proyecto a mediados del año pasado y lo pusimos en marcha en febrero de este año", explica. En comparación con los 30 meses que tardó la empresa matriz en migrar su libro mayor mundial.
Tener la libertad de moverse a tal velocidad es a la vez liberador y aterrador. En cierto sentido, anota, se sintió fortalecido porque podía avanzar sin mucho equipaje. "Pero lo que me ponía un poco nervioso era que no sabía cómo iban a resultar los procesos empresariales", añade. "La gente viene y dice: 'Esta no es la forma a la que estoy acostumbrado. Quiero hacerlo así', y ahí es donde suele entrar en juego la personalización".
En ese caso, muchos responsables de TI se ven obligados a crear una función a medida, lo que incrementa los costos, pero el planteamiento de Tiwari consistió en buscar otras formas de adaptar los deseos de los trabajadores a las opciones disponibles. Así que hubo muchas idas y venidas en el proceso de creación. "Era muy interactivo", comenta, con demostraciones cada semana más o menos, en lugar de que el equipo de TI entrevistara a los usuarios sobre los requisitos y luego desapareciera para volver tres meses después con una solución que ya no satisfacía sus necesidades.
Sin embargo, Tiwari no lo ha construido todo desde cero. Por ejemplo, BrightDrop sigue dependiendo de los servicios centrales de TI de GM para los sistemas de gestión de RR.HH. que se utilizan para dar de alta al personal y proporcionarle una dirección de correo electrónico gobrightdrop.com.
"Una vez que tengan ese correo electrónico, podrán conectarse a todos mis ecosistemas utilizando esa dirección", explica.
Pero a medida que comienzan las entregas de las van eléctricas de BrightDrop, Tiwari necesita establecer conexiones con la red de concesionarios de la empresa. "Algunos de ellos todavía utilizan mainframes en su lado de la casa, y luego mi lado está como 50 años por delante en la tecnología, así que ese es mi mayor desafío en este momento".
Basado en el artículo de Peter Sayer (CIO) y editado por CIO Perú