El Eslabón Perdido: Conectando procesos a los sistemas de información

¡ Hola !

¿Has tenido la experiencia alguna vez, de implementar un software?

Probablemente no ha sido fácil, especialmente si el sistema era grande y/o abarcaba varios departamentos en tu organización.

¿Qué condiciones se deben dar para dar el salto a informatizar alguna parte de la operación?

¿Es mejor comprar un producto empaquetado, o encargar un desarrollo a medida?

Exploremos algunas respuestas en esta edición de Oro Puro.

Antes de entrar en materia, quiero contarte sobre la startup norteamericana HIMS, enfocada en tele-salud sexual masculina, la cual ha tenido un importante crecimiento… tanto así que también lanzaron también HERS, el homólogo para el público femenino, y han ampliado su oferta a otros nichos, como por ejemplo salud mental.

Su historia es interesante, tanto en su éxito como en su propósito de eliminar el estigma de algunas condiciones de salud, al mismo tiempo innovando en el formato de entrega de servicios sanitarios, por ejemplo entregando productos con niveles de servicios propios del retail o el entretenimiento.

¡Gracias a HIMS por auspiciar a Oro Puro! Si tienes un minuto, te agradezco a revisar sus servicios a continuación.

Personalized ED treatments, straight to your door.

Hims has helped thousands of men get support for ED, and they’re ready to support you with custom solutions made with clinically proven ingredients.

Take their free assessment to see if a prescription is right for you.

El eslabón perdido

Tanto para desarrollar un software, como para comprar un producto empaquetado, existe un paso en común: Definir los requerimientos.

¿Qué necesito del sistema? ¿Cuál es su objetivo? ¿Quién lo usará? ¿Será operado desde un computador de escritorio o desde un dispositivo móvil? Etc.

Evidentemente hay muchas respuestas posibles, pero la clave no está ahí, sino en decidir quién responderá esas preguntas, ya que el enfoque puede ser radicalmente diferente.

Por ejemplo:

• Si lidera un gerente, buscará que el sistema logre resolver una necesidad táctica o estratégica, muchas veces con la expectativa de una amplia cobertura de proesos punta-a-punta, y con una estructura de supervisión robusta para monitorear el desempeño.

• Si lidera el usuario, el paradigma será más operacional: Que resuelva rápidamente, que sea “usable” o cómodo de operar, y que contenga lógica adaptada perfectamente a las necesidades propias y particulares del proceso en el que opera.

La clave está en el concepto de “funcionalidad”.

La funcionalidad es lo que el sistema hace para apoyar un proceso. Un cálculo, un algoritmo, un registro de datos… las operaciones del sistema son el vínculo con los procesos.

Entonces:

Tomemos parte de un proceso logístico como ejemplo:

• Para fabricar un producto, requerimos de insumos

• Los insumos se guardan en una bodega

• Cuando se alcanza un cierto nivel de stock mínimo, se generan órdenes de compra para reponer los insumos

• Se acepta la recepción de los insumos del proveedor con una guía de despacho asociada a la orden de compra

• Tesorería recibe y paga la factura del proveedor, asociada a la recepción conforme de los insumos.

Si este proceso se ejecuta manualmente o con planillas Excel, está claro que se requiere un nivel de cuidado mayor, y se asumen riesgos como errores involuntarios, o estar más vulnerable ante un fraude.

Entonces, surge la necesidad de implementar un “Software Logístico”.

Luego de analizar el proceso, es claro que se requieren varias funcionalidades, por ejemplo:

• Gestión de bodegas y sus stock

• Gestión de insumos y sus movimientos

• Generación de órdenes de compra

• Gestión de proveedores

• Gestión de Guías de Despacho y recepción de insumos desde proveedores

• Gestión de Facturas de Proveedores y su posterior pago

¿Debe este “Software Logístico” cubrir todas estas funcionalidades?

¿O sólo necesito parte de ellas?

Simplificando un poco, la decisión puede tomar dos caminos:

Entonces, en el ejemplo podríamos plantear que, dependiendo de la industria donde estamos insertos, y del posicionamiento estratégico diferenciador que ostentamos en el mercado, puede ser relevante que la gestión de bodegas e insumos sea especialmente eficiente.

En ese caso, podríamos requerir un software específico, que tenga capacidades más potentes en dichas funcionalidades, y el resto de las funcionalidades simplemente las seguimos ejecutando con planillas.

Inversamente, si el proceso logístico en general no es clave en la industria o posicionamiento competitivo de nuestra organización, podríamos simplemente implementar un sistema que lo “haga todo”.

En definitiva, es similar a la comparación entre una impresora “todo-en-uno” que también fotocopia y escanea, versus una impresora fotográfica profesional.

¿Abrumad@? 😅

Y esto es sólo el principio…

No sólo funcionalidad

Las expectativas de los sistemas exceden ampliamente las definiciones netamente funcionales que vimos en la sección anterior.

Por ejemplo:

• Conviven decenas de sistemas informáticos dentro de un complejo ecosistema digital empresarial, y esperamos que sus elementos se comuniquen y puedan interoperar fluidamente.

• Estamos en un mundo donde la ciberseguridad pasó a ser parte de las noticias, y ya no es raro sufrir disrupciones operacionales por un ciberataque o filtración de datos. El sistema debe ser seguro y resiliente.

• Es esperable que con el tiempo, surjan nuevas ideas y/o se identifiquen fallas en el sistema. Lo ideal entonces, es que el producto permita incorporar mejoras y corregir errores, rápidamente y sin mayores costos.

• A nivel quizá más básico, pero no por eso menos importante, asumimos que el sistema debe ser veloz, estamos poco dispuestos a esperar décimas de segundo a que responda a un click, especialmente en entornos altamente transaccionales. El desempeño debe ser impecable.

Con todo lo anterior, queda claro que la habilidad para definir buenos requerimientos es un súper-poder.

Es tan complejo hacer bien este trabajo, que a menudo las empresas requieren incorporar el rol de arquitecto informático, que habilite la capacidad de:

• Definir una estrategia tecnológica que provea lineamientos y criterios de diseño a las diferentes disciplinas funcionales y técnicas involucradas.

• Analizar a nivel macro, las interacciones, brechas, debilidades y fortalezas de los diferentes sistemas y sus coberturas funcionales.

• Diseñar estructuras robustas sobre cada una de las capas informáticas fundacionales, a nivel de infraestructura tecnológica, redes y comunicaciones, datos, sistemas e interfaces.

¿Desarrollo o adquisición?

Una vez que se hace evidente la necesidad de un software, con cierta cobertura funcional, resta evaluar si es preferible comprarlo o desarrollarlo a medida.

Cabe preguntarse lo siguiente:

• Las funcionalidades involucradas, ¿suponen una ventaja competitiva para la organización?

• ¿Existen en el mercado productos de software que cubran dichas funcionalidades? ¿Cuáles son las brechas respecto a los requerimientos?

• ¿Cuáles son los costos de ambas alternativas?

Como regla general, si la cobertura funcional está incorporada en varios productos empaquetados a nivel nacional, y los procesos involucrados no suponen una ventaja competitiva relevante para mi organización, la mejor alternativa suele ser adquirir un software de mercado.

Por otra parte, si no existen alternativas en el mercado, o bien el proceso es crucial para mi estrategia competitiva, entonces la recomendación sería desarrollo a medida.

Ejemplos:

• Típicamente los procesos de facturación y contabilidad no suelen ser diferenciadores, y existe una amplia oferta en el mercado → Adquirir.

• Si el proceso de entrega de productos a clientes es parte central del negocio mismo → Desarrollar.

• Funcionalidades específicas de una industria (ej: retail, telco, salud) donde existen varios proveedores, pero puede afectar la diferenciación → Evaluar.

Cierre

Las experiencias en implementación de sistemas suele ser intensas y llena de dificultades.

Más allá de que siempre el mayor desafío es alinear el sentido del cambio en las personas, con el propósito del software (Ver la publicación respecto a la Sobre-automatización), el éxito de una iniciativa de digitalización también dependerá de cómo se aborde técnicamente.

En la medida que tengamos el control de los procesos, las funcionalidades informáticas que las soportan, y la cobertura funcional de los sistemas, mitigaremos varios de los riesgos involucrados.

La decisión de desarrollar o adquirir un sistema de información, dependerá de factores como el costo, el potencial diferenciador competitivo de los procesos funcionalidades cubiertos, y la existencia de productos de mercado.

¿Y a ti , cómo te ha ido con la digitalización de tus procesos?

Un abrazo, y hasta pronto.

Si estás leyendo esto y no estás suscrito a Oro Puro, enrólate aquí.