Cuando el sistema estándar no cubre tu proceso, lo construimos. Desarrollamos aplicaciones web, extendemos SAP, conectamos sistemas que hoy no se hablan y automatizamos el trabajo repetitivo.
Lo que construimos
El sistema estándar cubre la mayor parte de la operación y después aparece el resto: ese pedazo de proceso que es propio de tu empresa y que nadie contempló. Casi siempre termina viviendo en una planilla compartida, en una cadena de correos y en la cabeza de la persona que lleva años haciéndolo. Funciona, hasta que esa persona sale de vacaciones.
Desde ahí hay dos caminos. Uno es forzar el proceso para que entre en el sistema estándar, lo que suele significar que la gente igual lleva su planilla paralela. El otro es construir la parte que falta y dejarla conectada con lo que ya existe, para que no sea otra isla más. Nos dedicamos a lo segundo.
En la práctica eso toma varias formas: extender SAP cuando el proceso vive ahí, levantar una aplicación web cuando necesita su propia interfaz, montar un módulo sobre SGP, nuestra plataforma, cuando se parece a algo que ya resolvimos antes, conectar sistemas que hoy no se hablan, o automatizar el trabajo repetitivo que hoy hace una persona a mano.
El criterio que aplicamos es simple: no construimos lo que ya existe. Si el estándar lo cubre con configuración, se configura. El desarrollo a medida se justifica donde el proceso es realmente tuyo, y es ahí donde además es una ventaja frente a tu competencia, no un costo de mantención más.
ABAP, Fiori y BTP que respetan tu proceso.
Portales y aplicaciones a medida.
Módulos operativos sobre nuestra plataforma.
Menos doble digitación entre sistemas.
Robots para las tareas repetitivas.
Complica si se modifica el núcleo del estándar, y por eso no es el camino que tomamos cuando se puede evitar. La práctica actual es construir las extensiones al costado, sobre la plataforma de desarrollo de SAP, de modo que la lógica propia quede separada del estándar y las actualizaciones no la pisen. Cuando el desarrollo sí tiene que ir dentro del sistema, se hace en los puntos de extensión previstos para eso y queda documentado.
Es lo que recomendamos. Un módulo acotado, en producción, con usuarios reales, dice más sobre si vamos a trabajar bien juntos que cualquier propuesta. Además deja algo funcionando desde el principio, en vez de un proyecto largo donde el primer resultado visible llega a los seis meses.
SGP es nuestra plataforma de operaciones industriales: mantención, flota, activos y su documentación. Se integra al ERP del cliente, SAP incluido, y no lo reemplaza. Cada empresa habilita solo los módulos que necesita y el acceso se controla por perfil, con permisos por módulo y por acción. Conviene cuando lo que necesitas se parece a algo que ya está en el catálogo, porque partes de una base construida en vez de desde cero. El modelo es licencia de plataforma más el desarrollo del módulo que actives. Si lo que necesitas no se parece a nada de lo que hay, una aplicación propia suele ser el mejor camino, y lo decimos.
Cuando los sistemas tienen una interfaz disponible, integrar es siempre más robusto: el robot que opera una pantalla se rompe el día que esa pantalla cambia. La automatización por robot tiene sentido cuando el sistema de la otra punta no ofrece ninguna forma de conexión, algo frecuente con software antiguo o de terceros. Es una buena solución para ese caso, no un reemplazo general de la integración.
Sí, el desarrollo a medida que pagas es tuyo, y tus datos también. Un módulo hecho a tu medida no se reutiliza con otros clientes. La condición está en la plataforma: los módulos que se construyen sobre SGP funcionan mientras mantengas la suscripción a SGP, porque dependen de ella para operar. Una aplicación web o una extensión SAP, en cambio, no tienen esa dependencia. Lo dejamos escrito en la propuesta antes de empezar, porque es el tipo de cosa que conviene tener clara desde el principio y no cuando ya hay un sistema en producción.
Es un escenario previsto y no un problema. Por eso entregamos documentación y hacemos traspaso. Un sistema que solo puede mantener quien lo escribió es un riesgo para ti y, a la larga, también para nosotros: preferimos seguir trabajando contigo porque el trabajo te sirve, no porque cambiar de proveedor sea inviable.
¿Tienes un proceso que tu sistema actual no cubre? Conversemos.
Conversemos de tu proyecto →