Hay una conversación que se repite en empresas medianas peruanas que crecieron con un equipo de sistemas propio: el gerente general tiene un problema operativo que ningún software del mercado resuelve exactamente como él lo necesita. El jefe de sistemas le dice que pueden desarrollarlo internamente. El gerente aprueba. Seis meses y varios cientos de miles de soles después, el sistema existe — pero no genera los reportes que el contador necesita, no cumple con los formatos que SUNAT exige para la facturación electrónica, no tiene la trazabilidad que los auditores pedirían si hubiera una fiscalización, y los datos que almacena no están estructurados de una forma que sirva para tomar decisiones. El área de sistemas hizo exactamente lo que le pidieron. El problema es que nadie con visión de negocio estuvo presente para saber qué pedir.
📊 DATO: Según el Informe CHAOS 2020 de Standish Group, el 66% de los proyectos de software fracasan — ya sea porque se entregan fuera de tiempo, fuera del presupuesto, o sin las funcionalidades requeridas. Y la principal razón de ese fracaso no es la calidad técnica del equipo de desarrollo: es la calidad de los requerimientos con los que ese equipo trabajó. Requerimientos funcionales incompletos, mal documentados o desconectados de la realidad del negocio son la causa de fracaso número uno en proyectos de desarrollo de software empresarial.
El problema que el área de sistemas no puede resolver sola
Por qué el mejor equipo técnico del mundo no puede compensar requerimientos de negocio mal definidos
El área de sistemas de una empresa mediana peruana tiene un perfil de conocimiento específico y valioso: sabe programar, conoce las tecnologías disponibles, puede diseñar bases de datos, puede construir interfaces de usuario y puede desplegar el sistema en los servidores correctos. Ese conocimiento es necesario para desarrollar software — pero no es suficiente.
Lo que el área de sistemas frecuentemente no tiene es el conocimiento profundo de los procesos del negocio que el software debe soportar, las obligaciones tributarias y contables que el sistema debe cumplir en el contexto peruano, los requerimientos de auditabilidad y trazabilidad que una fiscalización de SUNAT o una auditoría interna van a exigir, la estructura de datos que hace que la información sea útil para la toma de decisiones — y no solo almacenada —, y las integraciones con otros sistemas del negocio que definen si el software funciona dentro del ecosistema de información de la empresa o aislado de él.
Esas dimensiones no son técnicas — son de negocio. Y sin alguien que las entienda con profundidad participando en el proceso de definición del software, el área de sistemas va a construir exactamente lo que le pidan — y lo que le piden generalmente no incluye todo lo que el negocio necesita, porque quienes piden no saben con precisión qué pedir.
Los requerimientos de software mal entendidos o interpretados son una documentación obsoleta, inexacta o incompleta que no define claramente las especificaciones tecnológicas y funcionales del software. Esto puede dar lugar a interpretaciones erróneas de la funcionalidad y la arquitectura del software previstas. No solo puede ralentizar el proceso de desarrollo, sino también provocar problemas críticos de funcionalidad o vulnerabilidades de seguridad.
Los 6 riesgos que el desarrollo interno sin asesoría genera en una empresa peruana
Los problemas concretos que aparecen cuando el área de sistemas desarrolla sin visión de negocio
Riesgo #1 — Requerimientos funcionales incompletos: el software que hace lo que se pidió, no lo que se necesitaba
Este es el riesgo más frecuente y el que genera más frustración, porque no hay nadie a quien culpar claramente. El área de sistemas construyó lo que le pidieron. Quien hizo el pedido describió la necesidad desde su perspectiva operativa inmediata. Nadie con visión completa del negocio revisó si esa descripción capturaba todos los escenarios, las excepciones, las integraciones necesarias y los flujos alternativos.
El resultado es un sistema que funciona perfectamente para el caso principal — el flujo que todos tenían en mente cuando lo describieron — y que falla o no tiene solución para los casos secundarios que nadie documentó: la devolución parcial de un pedido, la factura que hay que corregir después de emitida, el usuario que necesita acceso de solo lectura sin permisos de modificación, el reporte que el gerente financiero necesita en un formato diferente al que el gerente operativo había solicitado.
Una documentación obsoleta, inexacta o incompleta puede dar lugar a interpretaciones erróneas de la funcionalidad y la arquitectura del software previstas por parte de los desarrolladores. Los analistas de negocios deben ayudar a los responsables de la toma de decisiones a crear documentación de software fácil de entender, estructurada y completa.
En empresas medianas peruanas, ese rol de analista de negocios que traduce la realidad del negocio a requerimientos completos y precisos frecuentemente no existe dentro del equipo — y tampoco dentro del área de sistemas. Es exactamente el rol que una asesoría especializada cubre en el proceso de desarrollo.
Riesgo #2 — Incumplimiento de requisitos de SUNAT: el sistema que es válido operativamente pero no tributariamente
Este es el riesgo con consecuencias más graves — porque no se manifiesta en el funcionamiento del sistema, sino en una fiscalización de SUNAT que puede ocurrir meses o años después de que el sistema entró en producción.
Un sistema desarrollado internamente para gestionar ventas, inventario, facturación o cualquier función con incidencia tributaria tiene que cumplir con los estándares técnicos y normativos que SUNAT exige. Para la facturación electrónica, esos estándares son específicos: formato XML UBL 2.1, firma digital con certificado vigente, validación a través de OSE autorizado, conservación de documentos electrónicos por al menos cinco años, y actualización ante cada cambio normativo que SUNAT publique.
Un área de sistemas que desarrolla el módulo de facturación sin conocimiento profundo de esos requisitos puede producir un sistema que genera comprobantes — pero que no cumple con el estándar técnico correcto. Los comprobantes se imprimen, el cliente los recibe, el negocio opera con normalidad — hasta que SUNAT hace una verificación cruzada y detecta que los comprobantes no tienen la validez legal requerida.
El mismo riesgo aplica para el registro de transacciones con incidencia tributaria — compras, ventas, retenciones, percepciones —: si el sistema no registra exactamente lo que la normativa exige, en el formato correcto y con el nivel de detalle requerido, la empresa puede tener información contable útil operativamente pero no válida ante SUNAT.
Una asesoría que entiende tanto la normativa tributaria peruana como los requisitos técnicos de los sistemas que la operacionalizan es la que puede garantizar que el software desarrollado internamente cumpla con ambas dimensiones — y que se actualice cuando la normativa cambia, lo cual en Perú ocurre con frecuencia.
Riesgo #3 — Sistemas sin auditabilidad: el software que no puede demostrar qué pasó ni cuándo
La auditabilidad es la capacidad de un sistema de demostrar, ante cualquier consulta interna o externa, qué ocurrió en cada transacción: quién la ejecutó, cuándo, qué datos tenía antes y después del cambio, y si hubo alguna modificación posterior. En el contexto empresarial peruano, esa capacidad es crítica en tres escenarios que cualquier empresa mediana puede enfrentar.
El primero es una fiscalización de SUNAT donde el auditor quiere verificar que las transacciones registradas en el sistema coinciden con los comprobantes emitidos y con las declaraciones tributarias. Si el sistema no tiene un log de auditoría completo y no manipulable, esa verificación puede volverse imposible — o generar sospechas de que algo fue modificado.
El segundo es una auditoría interna o externa donde se necesita rastrear el origen de una diferencia contable o de inventario. Sin auditabilidad en el sistema, la única respuesta que el equipo puede dar es «no sabemos cuándo ocurrió la diferencia ni quién la generó» — lo cual es una respuesta inaceptable para cualquier auditor.
El tercero es un proceso legal o de due diligence donde un comprador potencial, un inversionista o una contraparte contractual necesita verificar la integridad de la información histórica del negocio. Un sistema sin auditabilidad no puede demostrar que los datos no fueron manipulados — lo que puede ser suficiente para que una negociación no avance.
Los líderes del proyecto, los desarrolladores y los diseñadores pueden tener una comprensión diferente de los requisitos de un proyecto. Si el equipo no entiende del todo la visión presentada por el líder del proyecto, la puesta en práctica de esa visión puede dar lugar a un producto acabado que no se ajuste a las instrucciones.
El área de sistemas puede construir un sistema excelente funcionalmente sin incluir auditabilidad — porque nadie le pidió ese requerimiento de forma explícita. La asesoría de negocio es la que identifica ese requisito como no negociable antes de que el desarrollo comience, cuando incluirlo cuesta días de desarrollo — no semanas de rediseño después de que el sistema está en producción.
Riesgo #4 — Datos no estructurados para la toma de decisiones: el sistema que almacena pero no informa
Este es el riesgo que más directamente impacta el valor estratégico del software desarrollado. Un sistema puede funcionar perfectamente como herramienta operativa — registra transacciones, procesa pedidos, gestiona inventario — y al mismo tiempo ser completamente inútil como fuente de información para la toma de decisiones, porque los datos que almacena no están estructurados de una forma que permita extraer insights accionables.
Los síntomas más frecuentes de este problema son los reportes que el gerente necesita y que el sistema no puede generar porque los datos no están en los campos correctos, el análisis de rentabilidad por cliente o por producto que requiere cruzar datos de tres módulos diferentes que nunca se diseñaron para relacionarse entre sí, el dashboard de KPIs que el director quiere y que el área de sistemas dice que «técnicamente es posible pero tomaría meses implementar porque la base de datos no tiene la estructura correcta para eso», y la pregunta de negocio que nadie puede responder con el sistema porque cuando se diseñó nadie pensó que esa pregunta iba a ser importante.
Esas limitaciones no son errores del sistema — son consecuencias de diseños de base de datos que priorizaron la funcionalidad operativa sin considerar las necesidades de análisis. Y esa es exactamente la perspectiva que una asesoría de negocio aporta al proceso de diseño: qué preguntas va a necesitar responder este sistema en los próximos tres años — y cómo debe estructurarse la información desde el inicio para que esas respuestas sean posibles.
💡 EL MOMENTO EN QUE EL COSTO DEL DISEÑO INCORRECTO SE REVELA: No es cuando el sistema entra en producción. Es seis meses después, cuando el gerente general pide el reporte de rentabilidad por cliente que «el sistema debería poder generar» — y el jefe de sistemas responde que requiere entre 3 y 6 semanas de rediseño de la base de datos porque los datos no están estructurados para ese análisis. Rediseñar la estructura de datos de un sistema en producción con meses de historia acumulada es entre 5 y 10 veces más costoso que haberla diseñado correctamente desde el inicio.
Riesgo #5 — Falta de integración con el ecosistema del negocio: el sistema que opera en isla
En una empresa mediana peruana, el software desarrollado internamente rara vez existe en soledad. Necesita intercambiar información con el sistema contable, con el CRM, con el sistema de inventario, con la plataforma de facturación electrónica, con el banco para conciliaciones automáticas. Si el sistema se diseña sin considerar esas integraciones desde el inicio, el resultado es un sistema que funciona bien dentro de sus propias fronteras y genera trabajo manual en cada punto donde necesita interactuar con el mundo exterior.
El contador que tiene que exportar datos del sistema operativo a Excel y luego importarlos manualmente al sistema contable. El área comercial que tiene que copiar pedidos del sistema de ventas al sistema de inventario porque los dos no hablan entre sí. El gerente que tiene que consultar cuatro sistemas diferentes para tener una visión completa de la operación porque nadie diseñó la integración entre ellos.
Los problemas de compatibilidad pueden hacer que un proyecto de software fracase. Si el sistema final no se acopla correctamente con las herramientas existentes en las que confían los usuarios, el proyecto en su conjunto podría ser menos útil o podrías verte en la necesidad de retroceder considerablemente.
Las integraciones técnicas existen — hay APIs disponibles para la mayoría de los sistemas que una empresa mediana usa —, pero requieren ser consideradas desde el diseño inicial del sistema y no como un añadido posterior. Una asesoría que conoce el ecosistema de sistemas del negocio y las necesidades de integración entre ellos es la que puede asegurar que el software desarrollado internamente está diseñado para conectarse — no para operar aislado.
Riesgo #6 — Escalabilidad no planificada: el sistema que funciona hoy pero no en dos años
Una empresa mediana peruana que está en crecimiento puede triplicar su volumen de transacciones en dos o tres años. Si el software desarrollado internamente fue diseñado para el volumen actual sin planificar la escalabilidad, cuando ese crecimiento llegue el sistema puede empezar a mostrar problemas de rendimiento que requieren un rediseño costoso — o directamente reemplazarlo.
Los errores más comunes incluyen: falta de planificación, subestimar recursos, no escuchar al usuario final, mala comunicación entre áreas, y no realizar pruebas continuas. También es un error frecuente no prever escalabilidad ni ciberseguridad desde el diseño del software.
El área de sistemas puede diseñar correctamente para el volumen actual porque eso es lo que tiene en mente cuando desarrolla. La asesoría de negocio es la que pregunta «¿cuánto esperamos que crezca la empresa en los próximos tres años?» y traduce esa respuesta en requerimientos de escalabilidad que el área de sistemas debe incorporar desde el diseño inicial — y que cuestan mucho menos implementar desde el inicio que rediseñar cuando ya son un problema urgente.
⚠️ EL PATRÓN QUE SE REPITE EN EMPRESAS PERUANAS QUE DESARROLLARON SOFTWARE INTERNO SIN ASESORÍA: El sistema se construye, entra en producción y funciona bien durante los primeros 6 a 12 meses. Luego aparecen los primeros problemas: un requerimiento que el sistema no puede atender, un reporte que nadie sabe generar, una integración que falta, un campo que debería haberse registrado desde el inicio y que ahora falta en miles de registros históricos. El área de sistemas propone correcciones que generan nuevos problemas. Los usuarios empiezan a desconfiar del sistema y a mantener sus propias hojas de Excel en paralelo «por las dudas». El software que costó meses de desarrollo y cientos de miles de soles termina siendo una herramienta parcialmente usada que convive con los mismos Excel que pretendía reemplazar.
El rol de la asesoría de negocio en el proceso de desarrollo tecnológico
Lo que un consultor de negocio hace que el área de IT no puede hacer sola
La asesoría de negocio en un proyecto de desarrollo de software interno no reemplaza al área de sistemas — la complementa con la perspectiva que el área técnica no tiene. El consultor de negocio no escribe código ni diseña bases de datos. Hace las preguntas correctas antes de que el código empiece a escribirse — y esas preguntas son las que definen si el sistema que se va a construir es el sistema que la empresa realmente necesita.
Esas preguntas incluyen dimensiones que el área de sistemas no tiene forma de responder sola.
¿Cuáles son todos los flujos del proceso que el sistema debe soportar — incluyendo los casos de excepción? El área operativa describe el flujo principal. El consultor de negocio identifica los flujos alternativos: qué pasa cuando una factura se emite con error, qué pasa cuando un cliente devuelve parcialmente un pedido, qué pasa cuando hay que anular una operación que ya tiene otros movimientos asociados. Esos flujos de excepción son los que más frecuentemente no se documentan en los requerimientos y los que más problemas generan cuando el sistema no los tiene contemplados.
¿Qué obligaciones tributarias y contables debe cumplir el sistema en el contexto peruano? El área de sistemas puede conocer bien la tecnología pero no la normativa tributaria. El consultor que entiende ambas dimensiones puede verificar que los requisitos de SUNAT para la facturación electrónica, los estándares contables del plan de cuentas PCGE y los requerimientos de declaración tributaria están correctamente incorporados en el diseño del sistema.
¿Qué información necesita este sistema generar para que el gerente pueda tomar decisiones con datos? Esta pregunta, hecha antes del diseño, define la estructura de la base de datos. El consultor que entiende qué decisiones toma el gerente y qué información necesita para tomarlas puede traducir esas necesidades en requerimientos de estructura de datos que el área de sistemas implementa — garantizando que los reportes y análisis necesarios sean posibles desde el inicio, no como un rediseño posterior.
¿Con qué otros sistemas del negocio necesita integrarse este software? El consultor que conoce el ecosistema de sistemas de la empresa — contable, ERP, CRM, facturación electrónica — puede mapear todas las integraciones necesarias y asegurarse de que están consideradas en el diseño desde el inicio. No como requerimientos adicionales que se agregan cuando ya el sistema está en producción y cada integración requiere un desarrollo adicional.
Cuándo es más urgente la asesoría — los tres momentos donde su ausencia genera el mayor daño
Los escenarios que más frecuentemente terminan en sistemas problemáticos
Hay tres tipos de proyectos de desarrollo de software interno en los que la ausencia de asesoría de negocio genera el mayor riesgo — porque son los que tienen más interdependencias, más obligaciones normativas y más impacto estratégico en la información del negocio.
El primero es cualquier sistema con incidencia tributaria: facturación, compras, planilla, retenciones. Todo módulo que genere transacciones con impacto en las declaraciones tributarias de la empresa debe cumplir con requisitos técnicos y normativos específicos de SUNAT. Desarrollar esos módulos sin verificar el cumplimiento normativo desde el diseño es el camino más directo hacia el problema tributario que aparece meses después en una fiscalización.
El segundo es cualquier sistema que reemplaza o se integra a un proceso contable: módulos de inventario, control de caja, conciliación bancaria, registro de activos fijos. Esos sistemas generan asientos contables — directamente o como base para que el contador los genere —, y si los datos que producen no tienen la estructura correcta, la contabilidad que se construye sobre ellos tiene inconsistencias que se acumulan silenciosamente.
El tercero es cualquier sistema diseñado para centralizar información para la toma de decisiones: dashboards de gestión, sistemas de reportería, plataformas de análisis de datos. Esos sistemas son tan valiosos como la calidad de los datos que los alimentan y la estructura con que esos datos están organizados. Sin una asesoría que entienda qué decisiones debe soportar el sistema y cómo estructurar la información para eso, el resultado frecuente es un sistema de reportería que genera números pero no genera insights accionables.
| Dimensión del proyecto | Sin asesoría de negocio | Con asesoría de negocio |
|---|---|---|
| Requerimientos funcionales | Descritos por el usuario operativo — incompletos, sin excepciones documentadas | Validados por consultor de negocio — con todos los flujos, excepciones e integraciones |
| Cumplimiento tributario SUNAT | Depende del conocimiento normativo del área de sistemas — riesgo de incumplimiento | Verificado contra normativa vigente antes del diseño |
| Auditabilidad del sistema | Incluida solo si alguien la pidió explícitamente | Requerimiento no negociable incorporado desde el diseño |
| Estructura de datos para análisis | Diseñada para la función operativa — no necesariamente para el análisis | Diseñada para las preguntas de negocio que el gerente va a hacer en los próximos 3 años |
| Integraciones con otros sistemas | Agregadas como desarrollo adicional cuando se detecta la necesidad | Mapeadas y diseñadas desde el inicio del proyecto |
| Escalabilidad | Diseñada para el volumen actual — puede requerir rediseño al crecer | Planificada para el volumen esperado en el horizonte de 3 años |
| Costo de correcciones posteriores | 5 a 10 veces mayor que corregir en diseño | Mínimo — los problemas se detectan antes del desarrollo |
📖 CASO QUE ILUSTRA EL IMPACTO: Una empresa distribuidora en Lima con 45 colaboradores decidió desarrollar internamente un sistema de gestión de pedidos y despacho porque ningún software del mercado tenía exactamente el flujo que necesitaban. El área de sistemas desarrolló el sistema en 4 meses. Funcionaba bien para el flujo principal: el cliente pide, el sistema registra, el almacén despacha. Lo que nadie documentó como requerimiento fue el flujo de devoluciones parciales, la gestión de pedidos con entrega diferida en múltiples fechas, la integración con el sistema de facturación electrónica — que terminó siendo manual —, y los reportes de trazabilidad de despacho que el departamento contable necesitaba para cuadrar con los comprobantes emitidos. Ocho meses después de la puesta en producción, el equipo seguía manteniendo un Excel paralelo para los reportes de despacho porque el sistema no los generaba en el formato correcto. Las devoluciones se procesaban manualmente fuera del sistema. Y el área de sistemas estimó 12 semanas adicionales de desarrollo para resolver los problemas identificados. El costo de la asesoría que hubiera evitado esos problemas desde el diseño habría sido una fracción del costo de los rediseños posteriores.
Para cerrar: el software más caro no es el que se desarrolla mal — es el que se tiene que rediseñar
La inversión que protege todas las demás inversiones en tecnología
La asesoría de negocio en un proyecto de desarrollo de software no es un gasto adicional sobre el costo del desarrollo — es la inversión que protege la inversión en desarrollo. El costo de identificar un requerimiento faltante en la fase de diseño es una reunión de dos horas. El costo de identificarlo cuando el sistema ya lleva seis meses en producción puede ser semanas de rediseño, meses de datos mal estructurados que hay que limpiar y correcciones de impacto tributario que el sistema generó sin que nadie lo detectara a tiempo.
El 66% de los proyectos de software fracasan. Es más probable que las empresas incumplan los plazos y gasten más de la cuenta si no disponen de sistemas eficaces de gestión de proyectos. La diferencia entre el tercio que funciona y los dos tercios que fallan frecuentemente no es la calidad del equipo de desarrollo — es la calidad del proceso de definición que precedió al desarrollo.
En el mercado peruano de 2026, donde la normativa tributaria es cada vez más exigente, donde los requerimientos de trazabilidad y auditabilidad crecen y donde las empresas medianas necesitan información estructurada para tomar decisiones con datos, el software desarrollado internamente sin asesoría de negocio es un riesgo que se acumula en silencio — hasta que aparece en una fiscalización, en una auditoría o en la incapacidad del gerente de obtener la información que necesita para gestionar.
📞 En Adriazola Consulting acompañamos a empresas medianas peruanas en el proceso de definición de requerimientos para el desarrollo de software interno, con análisis de los procesos de negocio que el sistema debe soportar, verificación del cumplimiento normativo tributario y contable, diseño de la estructura de datos correcta para la toma de decisiones, mapeo de integraciones con el ecosistema de sistemas existente y validación de requerimientos de auditabilidad y escalabilidad, para que el software que desarrolla tu área de sistemas sea el sistema que tu empresa realmente necesita, desde el primer día de producción. Agenda tu consultoría hoy antes de que el desarrollo empiece, porque después es significativamente más caro.
⚠️ Nota: Este artículo tiene fines informativos y de orientación empresarial. Las situaciones y estadísticas citadas provienen de fuentes internacionales del sector tecnológico y de experiencias en consultoría empresarial. Para una evaluación personalizada de los riesgos de tu proyecto de desarrollo de software, consulta con un especialista.
