Estoy trabajando para un cliente (importante y muy conocida empresa) que utiliza un sistema de información hecho a medida sobre un sistema propietario. El sistema de marras, va de fábula: rápido, usable, estable, nunca casca, barato (con una persona se mantiene para varios cientos de usuarios), fiable, etc...Sólo tiene un problema y es que es un sistema con interfaz de usuario no gráfica, o dicho menos fino, es de pantalla verde. Por ahora han resistido las presiones para cambiarlo por un ERP estándar ... de esos que has de cambiar de versión cada dos años y aplicar 5 parches cada año ... será un gran negocio para cualquier consultora hacer ese cambio pero espero que por su bien sigan aguantando. ¿Por qué cambiar si va tan bien? ... ¿Es el cambiar por cambiar?, ¿puro consumismo, como quien cambia de móvil dos veces al año?
11 comentarios:
Se me ocurren dos buenas razones para cambiarlo, una de ellas muy vinculada a la política de RRHH de la empresa.
La primera razón es: ¿qué pasa si el que mantiene todo se jubila, se va de la empresa, tiene una baja de larga duración...? ¿Se para la empresa? ¿Dónde encuentras a alguien que se capaz de seguir manteniendo el sistema? ¿Quién da soporte de esa herramienta? ¿Se simula 3270 en los PCs con SNA? ¿Cuánta gente sabe lo que es eso?
La segunda razón es: ¿cuánto se tarda en emprender a manejarse con soltura en esa aplicación con comandos de teclado? Seguro que mucho más que pinchando con el ratón. La curva de aprendizaje será muy lenta. A favor tiene que una vez dominada la herramienta la productividad será altísima. ¿Cuándo es malo esto? Cuando hay rotación de personal. Si la empresa tiene pensado prejubilar gente y sustituirla por perfiles más baratos, esa herramienta es un freno.
Bueno, con la hora que es bastante he pensado ya... ;)
Por cierto, hubo una interesante discusión sobre ERPs en el blog de Julen.
En mi opnión jaizki tiene parte de razón. Depender de una tecnología obsoleta compromete el futuro. Por ello se tiene un problema y es conveniente cambiar para poder seguir ganando dinero mañana.
Pero, ¿a que cambiar?. Adquirir un ERP estándar también tiene muchos problemas y elegir uno es un decisión muy crítica (que por otro lado tampoco es la única, se puede desarrollar el software internamente o se puede comenzar a usar software libre por ejemplo).
Si el que mantiene todo se jubila tienes un problema, pero si la empresa que mantiene el ERP cierra o es comprada por otra el problema es aún mucho mayor.
En el caso de desarrollo interno al menos la situación está bajo nuestro control. Externalizar el problema nos puede dar una falsa sensación de seguridad, porque como los problemas se salen de nuestro ámbito ya no los vemos, es como cerrar los ojos para no sufrir. En realidad los mismos problemas siguen existiendo, sólo que entonces no tenemos ningún control sobre la situación.
Completamente de acuerdo Telémaco, una ERP estándar no es necesariamente la mejor opción.
En mi comentario sólo quería hacer ver los problemas que plantea el software actual, no opinar sobre el software más adecuado para sustituirlo, pero seguramente no quedó claro.
La decisión de comprar algo estándar o desarrollar en casa depende de muchos factores, y cada caso es diferente. Algunas veces será más barato y rentable desarrollar dentro de la empresa, y otras veces no.
Si a alguien le interesa, mis amigos de Redline , tienen un servicio de consultoría para determinar el ERP que mejor se ajusta a las necesidades concretas de una empresa.
Buenas objeciones.
La tecnología no es obsoleta aunque no esté de moda (iSeries o antes conocido por AS/400) pues IBM está invirtiendo en ella y abriéndola a sistemas estándares tipo J2EE (seguro que "Informático Impasible" me lo corrobora)
La usabilidad es muy buena, se navega por menús muy bien estructurados y se aprende rapidísimo (yo mismo cuando me la enseñaron era capaz de localizar donde ir en cada momento). Mi experiencia al respecto es bien al contrario: que cuando se sustituye un sistema "teclado" por un sistena "ratón" se pierde mucha usabilidad sobre todo si el sistema es muy transaccional.
En realidad el único problema es la concentración del riesgo en una persona, pero eso se debería poder mitigar con la documentación y teniendo a otra persona más (en este caso particular sería relativamente fácil ya que la empresa pertenece a un grupo que tiene técnicos en otras empresas del grupo). Además es un problema relativo porque el sistema está bien diseñado, es superestable y no se modifica significativamente.
Como dijo Bill Joy (cofundador de SUN): "What if the reality is that people have already bought most of the systems they want to own or need?"
Estoy de acuerdo con Luis. Esta tecnología no es tan mala como aparenta por la interfaz de usuario, ni siquiera la usabilidad es mala (yo la he probado en otro tipo de aplicaciones similares hace tiempo). También se podría solucionar el mantenimiento con otras personas a las que transferirles el conocimiento.
Yo le veo el problema en querer evolucionar a una entrada por otros canales. Veo que se trata de una aplicación de una escuela, que lo más normal es que quiera dar facilidades a sus estudiantes por Internet.
Lo que sí veo la evolución natural de este software es modularizarlo para independizar la capa de presentación de la de negocio, y así poder hacer entradas desde diferentes canales a cada una de estas aplicaciones. De esta forma se podría redefinir una capa de presentación para los usuarios, que podría ser hasta con un cliente web, o java o .NET o lo que sea, y las "tripas" de la aplicación podrían ser básicamente las mismas que ahora.
De todas formas eso depende mucho de cómo esté codificada la aplicación actualmente: si la capa de presentación está muy embebida con la de negocio, esto que estoy diciendo será un trabajo de chinos, que a lo mejor no compensa.
Por supuesto que otra salida será cambiar todo por una ERP estándar.
Carmen, es una herramienta de uso interno por lo que los canales de entrada no van a cambiar. Aún así creo que tu enfoque es el correcto desde el punto de vista de arquitectura. Hay que independizar capas siempre.
Y en cualquier caso queda el recurso de añadir una capa más encima de todo a través de una herramienta BPM - pero ese es un post que tengo pendiente de hacer.
Hola ,
un comentario rápido en una aparición fugaz..
Si el sistema es el que has puesto en la imagen, no lo cambio ni en broma. Respecto al mantenimiento, te puedo presentar a más de cinco o seis técnicos de RPG, capaces de mantenerlo (incluso en remoto). La mayoría con menos de 35 años. Con eso tienen para muuuuuuuchos años.
Jaizki, te aseguro que hay bastante gente en el mercado capacitada para hacerlo. Y no hace falta 3270 con SNA. En un día de técnico de IBM tienes instalado TCP/IP y a tirar con 5250 sobre IP (iSeries Access, Mocha, etc...). Respecto a la usabilidad, desde luego es clave la curva de aprendizaje. En eso estoy de acuerdo contigo.
Respecto a las capas intermedias hay varias posibilidades. Desde crear una web totalmente externa e "interfasar" (vaya palabro) con el AS400, hasta crear capas de emulación sobre los terminales 5250. Vamos, variedad hay.
Pero si quieren pasarse (que ya sé que no quieren, pero...) a un ERP estándar, también hay opciones muy llamativas. Sin ir más lejos, ayer hablaba con un compañero (con bastante experiencia) sobre nuevas implantaciones de un ERP estándar. Los dos coincidimos que mejor la opción sobre iSeries, con pantalla verde. ¡Y los dos trabajamos instalando la versión web del mismo ERP!!
Pues eso, que como he dicho que iba a ser breve, corto ya. Que sobre este tema tengo para largar varias horas...
¡Un saludo a todos!
Joder, joder, joder... Me despisto un poco y ya estáis dando la vara con el AS/400. ;)
A ver, IBM iSeries no deja de ser la versión preliminar de lo que hoy es Oracle; es decir, una base de datos con un lenguaje propio de programación... Pero en el entorno de los años 80. Ahí es ná. De ahí su potencia, estabilidad, fiabilidad y demás gaitas.
Hoy en día, un AS/400 "no puede" ofrecer más que robustez y potencia de cálculo, nada desdeñable, sin lugar a dudas, pero frente a lo de los menúes, y con todos mis respetos, andesté una buena página web de una mediana aplicación de gestión...
Y, sí... Hay soluciones simples y cómodas (que sí, que las hay) para seguir usando el 400 como una poderosísima base de datos y de procesos de negocio y dejar a la "lógica web" la parte de presentación con algo de chicha de "negocio web". En ello ando Yo mismo metido, pero... ¿qué cliente se atreve?
i2, de acuerdo contigo aunque en determinados tipos de transacciones como la entrada intensiva de datos, una interfaz gráfica es menos efectiva que una interfaz de "pantalla verde" (he recibido tantas quejas de usuarios por eso que creo que he perdido nivel de audición).
Comparto tu opinión de que el iSeries (AS/400 para los viejos del lugar) fue un sistema adelantado a su tiempo en cuanto a integración de componentes y robustez. Además es genial para los administradores de sistemas.
Pues eso, que es difícil adaptarlo a las nuevas tecnologías; básicamente por dos cosas: a) es textual, no gráfico, y b) ya está en las nuevas tecnologías. ;)
Aún así, es posible "mezclar" el 400 con "lo nuevo" si separamos correctamente las funcionalidades de cada componente... ¿no? ¡Anda, calla, que eso es labor de los consultores! Jejeje...
Yo comence mi vida de programador con el AS/400 (llamamé romantico pero), luego estuve integrando aplicaciones con entorno grafico (windows y web) con dicho AS/400 y actualmente olvide el AS/400 y me centre en web... que frustración, el entorno web es un entorno de comunicación con escaso control y fiablidad y no hablemos de velocidad... Usabilidad... mi definición es permitir al usuario acceder a lo que quiere lo mas rapido posible y lo mas eficientemente posible... ¿es usable la web?
Publicar un comentario