Nota de clase consolidada

Incorporación de tecnologías de información en las organizaciones

1. Tema central de la clase

La clase aborda la incorporación de tecnologías de información en las organizaciones, especialmente cuando se implementan sistemas de gestión, sistemas integrados o soluciones tecnológicas de alcance internacional. El foco no está puesto únicamente en la herramienta informática, sino en la relación entre tecnología, procesos administrativos, regulación, industria, costos, riesgos, infraestructura, capital humano y toma de decisiones de gestión.

La idea principal es que incorporar tecnología no significa simplemente “instalar un sistema”. Implica analizar si esa tecnología se adapta a la organización, si mejora sus procesos, si responde al marco regulatorio aplicable, si puede soportar la operatoria real y si su implementación se realiza en el momento adecuado. Las transcripciones trabajan especialmente la lógica de los sistemas internacionales, las capas de adaptación, las customizaciones, la estacionalidad del negocio, los ambientes de trabajo y las pruebas necesarias antes de pasar a producción.

2. Sistemas internacionales y lógica de capas

Cuando una organización incorpora un sistema desarrollado localmente para operar únicamente en un país, muchos problemas de adaptación pueden ser menores. Por ejemplo, una PyME argentina que utiliza un sistema argentino para operar sólo en Argentina probablemente no enfrente grandes diferencias regulatorias, idiomáticas o sectoriales.

La situación cambia cuando se incorporan sistemas internacionales, o cuando una empresa desarrolladora pretende vender una misma solución tecnológica en distintos países o industrias. En esos casos, el sistema debe organizarse en capas para poder mantener una base común y, al mismo tiempo, permitir adaptaciones.

La lógica general es la siguiente:

2.1. Capa núcleo o core

El core o núcleo del sistema reúne las funcionalidades comunes a la mayoría de las organizaciones, más allá del país o la industria. Se trata de funciones que suelen existir en cualquier empresa: gestión de clientes, gestión de proveedores, cuentas corrientes, inventarios, compras, ventas, artículos, movimientos de stock y recursos humanos.

Estas funcionalidades forman parte del estándar global del sistema. No significa que todos los datos sean idénticos en todos los países, sino que la necesidad funcional existe en casi cualquier organización. Por ejemplo, toda empresa que vende productos o servicios necesita registrar clientes, emitir comprobantes, controlar saldos y administrar pagos.

2.2. Localizaciones por país

La segunda capa corresponde a las localizaciones por país. Estas adaptaciones permiten que el sistema cumpla con las exigencias legales, fiscales, contables, laborales o administrativas propias de cada jurisdicción.

Un ejemplo claro es la identificación fiscal. En Argentina se utiliza el CUIT; en otros países puede utilizarse RUC, RUT, NIT u otra denominación. Aunque todos los países requieren algún identificador tributario, la forma, la cantidad de dígitos, la validación y la denominación pueden variar. Por eso, un sistema internacional debe permitir que una misma funcionalidad se adapte al marco legal de cada país.

Estas localizaciones son necesarias para cumplir con normas fiscales, regímenes de facturación, obligaciones laborales, reportes regulatorios, estructuras tributarias, condiciones fiscales y demás exigencias propias del país donde se implementa la solución.

2.3. Localizaciones por industria

La tercera capa corresponde a las localizaciones por industria. No se refieren al país, sino al sector económico en el que opera la organización. Cada industria tiene requerimientos específicos que pueden repetirse internacionalmente.

Por ejemplo, la industria petrolera requiere trazabilidad del proceso extractivo y de conversión del petróleo en distintos derivados. Allí aparecen conceptos como upstream, vinculado con exploración y extracción, y downstream, relacionado con refinación, distribución y productos derivados. Esa lógica no es igual a la industria láctea, la vitivinícola, la bancaria, la aseguradora o la sanitaria.

La industria bancaria, por ejemplo, suele trabajar con productos relativamente similares a nivel internacional: cuentas corrientes, cajas de ahorro, préstamos, inversiones, fondos, seguros, tarjetas y operaciones financieras. Sin embargo, cada país puede imponer regulaciones particulares. Por eso, un sistema puede tener una base común bancaria y, además, localizaciones por país.

3. Customizaciones o adaptaciones a medida

La cuarta capa corresponde a las customizaciones o desarrollos a medida. Una customización es una adaptación específica solicitada por una organización para resolver una necesidad particular que no queda cubierta por el core, por la localización del país ni por la localización de la industria.

En términos prácticos, una customización implica que el proveedor, el partner tecnológico o el equipo de desarrollo realiza una modificación especial para un cliente concreto. Esa modificación puede consistir en cambiar código, crear una extensión, desarrollar un reporte, integrar un sistema externo, automatizar una tarea, alterar una pantalla, conectar una API o adaptar un flujo de trabajo.

3.1. Cuándo puede justificarse una customización

Una customización puede ser adecuada cuando:

El proceso de la organización es realmente diferencial.
Existe una exigencia regulatoria no cubierta por el estándar.
Se necesita integrar el sistema con plataformas externas.
Se requiere automatizar procesos críticos.
La organización posee una ventaja competitiva basada en una forma particular de operar.
El sistema debe interactuar con tecnologías heredadas o sistemas legacy.

Por ejemplo, si una empresa necesita que su sistema de gestión se conecte automáticamente con facturación electrónica, plataformas fiscales, billeteras virtuales, sistemas contables externos, plataformas de comercio electrónico o reportes regulatorios, puede ser necesario desarrollar una integración específica.

3.2. Cuándo una customización puede ser inconveniente

No toda customización es conveniente. En muchos casos, la organización pide customizar porque no desea modificar procesos internos que podrían estar atrasados, mal diseñados o ser menos eficientes que los procesos estándar del sistema.

En esos casos, la pregunta de gestión no debería ser solamente: “¿Cómo se adapta el sistema a lo que ya se hace?”, sino también: “¿Conviene mantener el proceso actual o corresponde hacer una reingeniería de procesos?”.

Customizar para mantener prácticas ineficientes puede generar costos innecesarios, dependencia tecnológica, complejidad operativa y deuda técnica. La incorporación de tecnología debería servir para mejorar la organización, no para reproducir digitalmente procesos antiguos sin revisarlos.

4. Fit-gap y decisión tecnológica

El análisis fit-gap permite comparar lo que ofrece el sistema con lo que necesita la organización.

Fit: existe ajuste entre la funcionalidad estándar del sistema y la necesidad de la organización.
Gap: existe una brecha entre lo que el sistema ofrece y lo que la organización requiere.

La lógica esperable es que la mayor parte de las necesidades quede cubierta por el core, las localizaciones por país y las localizaciones por industria. Si aparecen gaps muy importantes en funcionalidades básicas, debería revisarse si la tecnología elegida es realmente adecuada.

Un sistema no debería seleccionarse con la expectativa de customizarlo completamente. Si el núcleo de la tecnología no responde a las necesidades centrales de la organización, puede que la decisión de compra sea incorrecta. En cambio, si el sistema cubre la mayor parte de los requerimientos y sólo quedan necesidades puntuales no cubiertas, la customización puede ser razonable.

5. Contratos, vendor, partner y garantía de customizaciones

En la implementación de sistemas suelen intervenir distintos actores:

Vendor: proveedor o fabricante principal del software.
Partner: socio tecnológico o consultora que implementa, adapta o desarrolla sobre la solución.
Organización cliente: empresa que incorpora la tecnología.

El contrato principal suele cubrir la funcionalidad estándar del sistema, sus módulos, actualizaciones, mantenimiento y garantías dentro del período contractual. En cambio, las customizaciones suelen contratarse por separado, se pagan aparte y tienen una garantía distinta.

Según lo trabajado en clase, el estándar de mercado mencionado para la garantía de customizaciones es de aproximadamente 90 días, aunque puede variar según el poder de negociación de las partes y las condiciones contractuales. Esto significa que una customización no necesariamente queda garantizada por todo el plazo del contrato principal del sistema.

Este punto es central para la gestión. Una organización puede contratar un sistema por 36 o 60 meses, pero una adaptación específica puede quedar garantizada sólo por un período breve. Además, si luego cambia la versión del sistema, el sistema operativo, la plataforma o la arquitectura, la customización puede dejar de funcionar y requerir un nuevo desarrollo.

6. Costos, mantenimiento y deuda tecnológica

Las customizaciones incrementan el costo total de la tecnología. No sólo se paga el desarrollo inicial, sino también pruebas, documentación técnica, documentación funcional, mantenimiento, soporte, adaptación a nuevas versiones y eventuales correcciones.

Además, las customizaciones pueden generar:

Mayor complejidad técnica.
Dependencia de determinados proveedores.
Necesidad de recursos humanos especializados.
Dificultades de auditoría.
Problemas de compatibilidad con nuevas versiones.
Mayor costo total de propiedad.
Mayor deuda tecnológica.

La deuda tecnológica aparece cuando las decisiones de implementación generan complejidad futura. Puede ocurrir cuando se desarrollan soluciones a medida sin suficiente documentación, cuando se modifican módulos estándar innecesariamente, cuando se depende de conocimiento no transferido o cuando se acumulan adaptaciones que luego dificultan la evolución del sistema.

7. Incompatibilidad de versiones y lock-in

Uno de los riesgos de las customizaciones es la incompatibilidad con nuevas versiones. Una adaptación desarrollada para una versión específica del sistema puede no funcionar en una versión posterior. Lo mismo puede ocurrir si se cambia de sistema operativo, infraestructura, base de datos o plataforma.

Este fenómeno se vincula con el lock-in o dependencia tecnológica. La organización queda condicionada por una versión, por un proveedor, por una arquitectura o por un conjunto de desarrollos particulares. En la práctica, cambiar puede ser posible, pero requiere nuevos costos, nuevas pruebas, nuevos contratos y nuevos desarrollos.

Por eso, las decisiones tecnológicas no deberían tomarse sólo pensando en el estado actual de la organización. También debe evaluarse el corto, mediano y largo plazo: evolución del sistema, escalabilidad, mantenimiento, compatibilidad, disponibilidad de especialistas y posibilidad de migración futura.

8. Capital humano, conocimiento especializado y gobernanza

La implementación de tecnología no depende únicamente de software. También requiere capital humano especializado. Algunas tecnologías son ampliamente conocidas y tienen muchos profesionales disponibles; otras requieren perfiles técnicos escasos, costosos o difíciles de reemplazar.

Además, el conocimiento sobre customizaciones suele quedar concentrado en personas específicas: desarrolladores, consultores, administradores de base de datos, analistas funcionales o responsables internos del sistema. Si ese conocimiento no se documenta ni se transfiere, la organización puede quedar expuesta.

Desde la gobernanza, auditar un sistema estándar no es lo mismo que auditar un sistema fuertemente customizado. Cuanto más particular sea la solución, más importante será contar con documentación, controles, responsables definidos, pruebas, trazabilidad de cambios y procedimientos de mantenimiento.

9. Reingeniería de procesos versus customización

Una cuestión central de la clase es la comparación entre customizar el sistema o modificar los procesos internos.

La organización debería preguntarse si conviene adaptar el software a los procesos actuales o rediseñar los procesos para aprovechar la lógica del sistema. Muchas veces, los procesos existentes no son necesariamente obsoletos, pero tampoco son óptimos. Funcionan, pero podrían funcionar mejor.

La incorporación de tecnología implica cambio cultural, nuevas formas de control, nuevas responsabilidades y nuevas rutinas de trabajo. Por eso, resistirse al cambio puede llevar a pedir customizaciones innecesarias. En esos casos, se paga para que el sistema nuevo se parezca al sistema viejo, perdiendo parte del valor de la inversión tecnológica.

10. Estacionalidad y planificación de la implementación

La estacionalidad se refiere a los períodos en los que una organización enfrenta picos de demanda, mayor volumen operativo, incremento de transacciones o mayor necesidad de recursos. Esta estacionalidad impacta directamente en la planificación tecnológica.

Por ejemplo, en retail pueden existir picos en diciembre, enero, vacaciones, campañas comerciales o fechas especiales. En organismos fiscales, puede haber picos en períodos de vencimientos impositivos. En el sector agropecuario, la estacionalidad puede depender de cosecha fina o cosecha gruesa. En servicios públicos, la demanda energética puede variar según invierno o verano.

Si una organización tiene estacionalidad operativa, también tendrá estacionalidad tecnológica. Es decir, sus sistemas deberán soportar mayor carga, mayor cantidad de usuarios, más transacciones, más consultas y más procesos simultáneos.

10.1. Elección del momento de implementación

Implementar tecnología “en cualquier momento” es técnicamente posible, pero puede ser riesgoso. La gestión debe definir cuándo conviene pasar a producción.

En general, se recomienda evitar implementaciones durante:

Picos de demanda.
Cierres contables o fiscales críticos.
Fechas de alta transaccionalidad.
Períodos comerciales sensibles.
Momentos de gran exposición operativa.

Idealmente, una implementación importante debería realizarse en períodos de menor actividad, fines de semana, cambios de mes, cambios de trimestre o momentos en los que sea posible distinguir claramente qué operaciones pertenecen al sistema anterior y cuáles al sistema nuevo.

11. Riesgos de una mala implementación

Una mala decisión de implementación puede generar problemas graves. Por ejemplo, migrar únicamente saldos sin migrar el historial completo puede permitir que ciertos importes coincidan, pero impedir luego obtener información de gestión confiable.

Si sólo se migra el saldo de proveedores, clientes o cuentas corrientes, pero no se migra la historia de movimientos, pagos, créditos, débitos, facturas, remitos y ajustes, el sistema nuevo puede parecer operativo, pero carecer de información suficiente para analizar la evolución del negocio.

Este punto muestra que implementar no es sólo “hacer que el sistema arranque”. También implica asegurar continuidad histórica, integridad de datos, trazabilidad, conciliación, reportes de gestión y consistencia entre módulos.

12. Infraestructura, nube y costos recurrentes

La tecnología también exige analizar infraestructura. Puede requerirse mayor ancho de banda, nuevos equipos, más capacidad de procesamiento, almacenamiento adicional, servicios en la nube o contratación de proveedores externos.

El uso de servicios en la nube no elimina los costos ni las decisiones de gestión. Al contrario, puede convertir muchos gastos en costos recurrentes. En países como Argentina, además, muchas soluciones cloud se pagan en dólares o están atadas a precios internacionales.

Por lo tanto, debe evaluarse el costo total de propiedad, incluyendo licencias, abonos, almacenamiento, procesamiento, conectividad, soporte, mantenimiento, capacitación, actualizaciones y posibles incrementos de capacidad en períodos de estacionalidad.

13. Ambientes o entornos de implementación

La clase también aborda la importancia de trabajar con distintos ambientes tecnológicos. No se debería modificar directamente el ambiente de producción sin antes diseñar, construir, probar y capacitar.

Los ambientes habituales son:

13.1. Ambiente de diseño y análisis

Se definen los requerimientos, procesos, necesidades funcionales, reglas de negocio y criterios de implementación.

13.2. Ambiente de desarrollo o construcción

Se configuran módulos, se desarrollan funcionalidades, se realizan ajustes y se preparan las soluciones técnicas.

13.3. Ambiente de prueba o test

Se verifica si lo desarrollado funciona como se esperaba. Allí se prueban componentes, módulos, integraciones y funcionalidades.

13.4. Ambiente de pruebas integrales

Se evalúa el funcionamiento conjunto del sistema. No se prueba una parte aislada, sino el circuito completo.

13.5. Ambiente de capacitación

Se utiliza para entrenar usuarios sin afectar datos reales ni operaciones productivas.

13.6. Ambiente de producción

Es el entorno real donde opera la organización. Allí se encuentran los datos efectivos, las transacciones reales y los procesos que impactan en la gestión. Por eso, debe ser el ambiente más protegido.

Un punto especialmente importante es que los datos de producción son el activo más difícil de reemplazar. Se pueden reemplazar equipos, proveedores, conectividad o incluso personal, pero los datos propios de la organización no pueden reconstruirse fácilmente si se pierden o dañan.

14. Pruebas de sistemas

La implementación tecnológica exige pruebas. No debería incorporarse una tecnología sin verificar que funciona conforme a lo previsto. Las pruebas permiten comprobar que el sistema responde a los requerimientos técnicos y funcionales antes de pasar a producción.

14.1. Pruebas unitarias

Las pruebas unitarias verifican componentes individuales. Por ejemplo, en un módulo de clientes se puede probar el alta, modificación, baja, consulta, validación de campos, filtros, historial de cambios o comportamiento ante datos incorrectos.

Estas pruebas suelen ser realizadas por desarrolladores o equipos técnicos.

14.2. Pruebas de integración

Las pruebas de integración verifican cómo interactúan distintos componentes del sistema. Por ejemplo, si se emite una factura, debería impactar en la cuenta corriente del cliente. Si luego el cliente paga, el pago debería registrarse correctamente y cancelar o reducir el saldo.

La integración es fundamental porque un sistema de gestión no está compuesto por pantallas aisladas, sino por circuitos administrativos completos.

14.3. Pruebas funcionales

Las pruebas funcionales verifican si el sistema cumple con lo que fue solicitado por el área usuaria o por la organización. Aquí intervienen quienes conocen el proceso administrativo, comercial, contable, logístico o financiero.

Por ejemplo, se debe comprobar si el IVA se calcula correctamente, si el reporte filtra por fechas, si el botón exporta en PDF, si el listado muestra los datos requeridos o si un circuito refleja adecuadamente la realidad operativa.

14.4. Pruebas de performance

Las pruebas de performance evalúan si el sistema responde con velocidad, estabilidad y capacidad suficiente para la operación esperada. No alcanza con que una función “ande”; también debe hacerlo en tiempos aceptables y bajo condiciones razonables de uso.

14.5. Pruebas de estrés o carga pico

Las pruebas de estrés buscan identificar el límite operativo del sistema. El objetivo no es sólo comprobar que funciona, sino saber en qué punto empieza a fallar, demorarse, bloquearse o degradar su rendimiento.

Por ejemplo, si un sistema no soporta más de determinada cantidad de transacciones simultáneas, la organización debe conocer ese límite para prevenirlo. Esto puede llevar a distribuir horarios, ampliar infraestructura, establecer colas de espera, limitar accesos concurrentes o evitar que todos los usuarios operen al mismo tiempo.

14.6. Pruebas de caja negra y caja blanca

Las pruebas de caja negra verifican el resultado externo sin analizar el funcionamiento interno. Por ejemplo, pagar con una billetera virtual y comprobar que el pago se registró.

Las pruebas de caja blanca analizan también el funcionamiento interno del sistema: procesos, reglas, validaciones, integraciones, tablas, cálculos y secuencias lógicas.

En sistemas de gestión, suele ser necesario combinar ambos enfoques: comprobar que el usuario obtiene el resultado esperado y, al mismo tiempo, verificar que internamente el sistema registra, calcula e integra correctamente.

Conceptos clave

Sistema de información: conjunto organizado de tecnología, datos, procesos, personas y controles que permite gestionar información para la operación y la toma de decisiones.
Core o núcleo: funcionalidades estándar del sistema, comunes a muchas organizaciones, países e industrias.
Localización por país: adaptación del sistema a normas, datos, impuestos, identificadores, reportes y regulaciones propias de una jurisdicción.
Localización por industria: adaptación del sistema a requerimientos específicos de un sector económico, como banca, seguros, petróleo, salud, retail o industria láctea.
Customización: desarrollo a medida solicitado por una organización para cubrir necesidades no resueltas por el estándar.
Fit-gap: análisis entre lo que el sistema ofrece y lo que la organización necesita. El fit indica coincidencia; el gap indica brecha.
Vendor: proveedor o fabricante principal del software.
Partner: socio tecnológico o consultora que implementa, adapta o desarrolla sobre la solución.
Garantía de customización: período durante el cual el desarrollo a medida queda cubierto ante errores. En la clase se menciona como estándar habitual un plazo de 90 días.
Costo total de propiedad: conjunto de costos asociados a la tecnología durante todo su ciclo de vida, no sólo la compra inicial.
Deuda tecnológica: complejidad acumulada por decisiones técnicas que generan costos o dificultades futuras.
Lock-in: dependencia de un proveedor, versión, plataforma o tecnología que dificulta cambios posteriores.
Estacionalidad: variación cíclica de la demanda o de la carga operativa de una organización.
Ambiente de producción: entorno real donde operan los usuarios y se procesan datos efectivos.
Prueba unitaria: verificación de un componente individual.
Prueba de integración: verificación del funcionamiento conjunto de varios módulos o componentes.
Prueba funcional: validación de que el sistema cumple con lo solicitado por el negocio.
Prueba de performance: evaluación de rendimiento, velocidad y capacidad de respuesta.
Prueba de estrés: evaluación del límite operativo del sistema ante carga elevada.
Caja negra: prueba basada en entradas y salidas, sin analizar el funcionamiento interno.
Caja blanca: prueba que analiza también la lógica interna del sistema.

Preguntas de repaso

¿Por qué un sistema internacional necesita organizarse en capas?
¿Cuál es la diferencia entre el core del sistema, la localización por país y la localización por industria?
¿Por qué el CUIT, el RUC, el RUT o el NIT son ejemplos útiles para explicar las localizaciones por país?
¿En qué casos una customización puede estar justificada dentro de una implementación tecnológica?
¿Por qué una organización debería evaluar si conviene customizar un sistema o realizar una reingeniería de procesos?
¿Qué riesgos económicos y técnicos pueden generar las customizaciones?
¿Cuál es la diferencia entre el rol del vendor y el rol del partner en una implementación tecnológica?
¿Por qué la estacionalidad del negocio debe ser considerada antes de definir la fecha de implementación de un sistema?
¿Qué diferencia existe entre pruebas unitarias, pruebas de integración, pruebas funcionales y pruebas de estrés?
¿Por qué el ambiente de producción debe ser especialmente protegido y por qué los datos son el activo más crítico del sistema?