Caso de Negocio V2 - Davidcuama/via-coinogas GitHub Wiki

Caso de Negocio · V2

Versión 2 — Sprint 2, octubre de 2026. Amplía la versión del Sprint 1 con la misión, la visión y los valores del producto, los insights del solicitante y del analista de Compras, fuentes verificables para cada afirmación sobre la empresa y el entorno, y la descripción del producto actualizada con lo entregado. La V1, escrita por Juan Esteban Villada en el Sprint 1, sigue en su propia página: Caso de Negocio. Esta versión parte de ella, la amplía y precisa con fuentes los datos que podían respaldarse. El historial de cambios está al final.

Las referencias entre corchetes, como [1], remiten a la sección Fuentes.

1. Descripción del negocio

La empresa

Coinogas S.A. E.S.P. es una empresa de ingeniería especializada en el sector de hidrocarburos, fundada el 10 de agosto de 2006 [1]. Acompaña a sus clientes a lo largo de la cadena de valor del gas: transporte de gas natural por gasoductos, compresión de gas (GNC), operación y mantenimiento de infraestructura energética, sistemas metrológicos —medición, calibración y monitoreo de calidad del gas—, procesamiento de gas natural, ingeniería y consultoría, montaje y mantenimiento de válvulas, instrumentación y protección catódica, y obras civiles, mecánicas y geotécnicas [2].

Es una empresa de servicios públicos (de ahí la sigla E.S.P.): es propietaria del gasoducto Floreña–Yopal, cuyos cargos de transporte aprueba la Comisión de Regulación de Energía y Gas (CREG) bajo el régimen de la Ley 142 de 1994 [3][4]. Tiene su sede administrativa en Floridablanca (Santander) y su sede operativa en el parque industrial La Villa, sobre la vía Yopal–Morichal (Casanare) [2].

Cuenta con certificaciones vigentes ISO 9001:2015 (gestión de la calidad), ISO 14001:2015 (gestión ambiental) e ISO 45001:2018 (seguridad y salud en el trabajo), y registra desde 2012 el RUC del Consejo Colombiano de Seguridad, el registro uniforme que se exige a los contratistas del sector [1].

El problema

Como toda empresa de infraestructura crítica, Coinogas compra de forma constante repuestos, insumos y servicios para sostener su operación. Esas compras se solicitan con el formato ADM-F-22 «Manifestación Requerimiento de Compra», revisión 02, vigente desde el 18 de enero de 2021 [11]: el funcionario descarga un Excel, lo diligencia a mano y lo envía por correo al área de compras, que vuelve a transcribirlo a un consolidado al que internamente llaman la sábana [10].

Ese proceso no deja trazabilidad, arrastra errores cuando alguien reutiliza un formato viejo, obliga a digitar dos veces la misma información, y no impide enviar un formato incompleto aunque el propio formato lo pida [10]. El detalle de cada problema, con su evidencia, está en la sección 4. Insights de los usuarios.

La respuesta

VIA Compras reemplaza el Excel por un formulario web conectado a una base de datos central, que conserva la estructura del ADM-F-22 que la gente ya conoce y traslada al software las responsabilidades que hoy dependen de la disciplina de cada persona: que no falten campos, que la información no se transcriba dos veces y que quede constancia de cada paso.

Encaja además con el sistema de gestión de la calidad de la empresa. ISO 9001:2015 trata las compras en su cláusula 8.4, Control de los procesos, productos y servicios suministrados externamente, y pide conservar como información documentada lo que antes llamaba registros (cláusula 7.5) [8][9]. Un requerimiento que vive en una base de datos, con consecutivo y bitácora de estados, es esa información documentada; un Excel que circula por correo, difícilmente.

2. Misión, visión y valores

Son los del producto, no los de la empresa, pero se escribieron a partir de los valores corporativos de Coinogas —trabajo en equipo, lealtad, honestidad y retroalimentación [1]— para que la herramienta los refleje en su forma de funcionar y no solo en el papel.

Misión

Que cada necesidad de compra de Coinogas llegue al área de compras completa, a la primera y con constancia de su recorrido, para que se cotice sin reprocesos, sin correos de ida y vuelta y sin volver a transcribir nada.

Visión

En 2027, VIA Compras será el único canal por el que se radican y se gestionan los requerimientos de compra de Coinogas, y el área de compras medirá con datos propios cuánto tarda en atender una solicitud y cuántas devuelve, para reducir ambas cifras año a año.

La visión es deliberadamente más corta que la de la empresa, que se fija en 2030 [1]: un producto interno tiene que demostrar su valor en meses, no en años.

Valores

Cada valor dice qué significa y, sobre todo, dónde se ve en el producto. Un valor que no se puede señalar en la pantalla no es un valor del producto, es una intención.

Valor	Qué significa	Dónde se ve en el producto	Valor de Coinogas que lo inspira [1]
Trazabilidad	Todo requerimiento deja constancia de quién lo pidió, en qué estado está y quién lo movió.	Consecutivo único (HU-16). Bitácora con quién, cuándo y por qué de cada cambio de estado (HU-23).	Honestidad: transparencia y coherencia.
Completo desde el origen	La información se valida donde se captura, no cuando compras ya la necesita.	Campos obligatorios (HU-15) y aviso de confirmación antes de enviar (HU-34). Adjuntos con su tipo y contenido revisados (HU-11).	Trabajo en equipo: el aporte de cada uno fortalece el resultado.
Retroalimentación oportuna	Si algo falta, se dice en el sistema y a tiempo, no por un correo que se pierde.	Devolución con observación obligatoria y enlace directo para corregir (HU-24). Correos de confirmación y de aviso (HU-19, HU-35).	Feedback: comunicación abierta, honesta y oportuna.
Respeto por el proceso	Se digitaliza el formato que la empresa ya usa; no se obliga a nadie a aprender otro.	Rótulos y secciones del ADM-F-22. Formulario siempre en blanco, por decisión expresa del cliente (acuerdo n.º 4).	Lealtad: compromiso con la organización.
Cada quien ve lo suyo	La información de un requerimiento la ven quien lo radicó y el área de compras. Nadie más.	Ingreso con cuenta y perfiles. Confirmación, corrección y adjuntos protegidos: el consecutivo es adivinable y no basta con tener sesión.	Honestidad. Y es lo que exige la Ley 1581 de 2012 sobre datos personales [5].

3. Análisis del mercado

Mercado objetivo

No es un producto de mercado abierto sino una solución interna (business to employee) para Coinogas S.A. E.S.P. Sus usuarios son los funcionarios de las distintas áreas, proyectos y sedes que necesitan solicitar una compra, y el área de compras que recibe y gestiona esas solicitudes.

Alternativas existentes

Formato ADM-F-22 en Excel. El método actual. No valida datos, no se puede consultar en tiempo real y depende de que el archivo viaje por correo.
Correo electrónico. Se usa de manera informal para enviar el formato o preguntar por él, sin estructura ni trazabilidad.
Hojas de cálculo compartidas. Algunas áreas llevan un control paralelo, con versiones distintas de la misma información.
Plataformas comerciales de compras. SAP Ariba, Odoo Purchase, Zoho Forms y Google Forms se compararon en detalle, con sus costos de referencia consultados en agosto de 2026, en la sección 2.2 de Determinación de Necesidades [12]. Ninguna se ajusta al caso: o cobran por usuario —y en Coinogas cualquier funcionario puede radicar—, o imponen su propio modelo de datos, o no modelan un requerimiento con varios ítems, estados y devoluciones.

Oportunidad

Ninguna de las alternativas actuales valida en el punto de captura, garantiza catálogos cerrados ni deja trazabilidad automática. Y la digitalización de compras es una prioridad creciente en el sector: en la encuesta global de Deloitte a directores de compras de 2025, con más de 250 participantes de 40 países, el cuartil de organizaciones más avanzadas destina hasta el 24 % de su presupuesto de compras a tecnología, casi el doble de lo que reportaba en 2023 [7].

Para una empresa del tamaño de Coinogas el primer paso no es una plataforma corporativa, sino algo más básico: que la información de compras exista como datos y no como archivos sueltos.

Tamaño y alcance

El sistema está pensado para las áreas, proyectos y centros de costo de Coinogas. No compite con un ERP: su alcance es digitalizar y gestionar el requerimiento de compra, no reemplazar el ciclo completo de compras ni el sistema contable. Quedan fuera, por acuerdo con el cliente, un maestro de proveedores, los flujos de aprobación jerárquica y la integración con el ERP [13].

4. Insights de los usuarios

4.1 De dónde salen

Fuente	Qué aportó
Entrevista semiestructurada, 24 de julio de 2026, con Sergio Andrés Quintero Albarracín, Daryi Alejandra Silva López (área de compras) y Gerardo Cuadros Chahín [10].	El proceso actual, los puntos de dolor y las decisiones de alcance, en palabras del cliente.
Análisis del formato ADM-F-22 diligenciado con un caso real: la calibración de un Fluke 725 con módulos de presión y RTD [11].	La estructura exacta de los datos y un ejemplo concreto de dónde falla el proceso.
Reconstrucción del proceso actual (AS-IS) a partir de lo anterior [13].	Dónde se pierde información y dónde se duplica el trabajo.

Limitación conocida. La entrevista fue con el área de compras y con el interlocutor del cliente; no hubo una entrevista directa con solicitantes de campo. Los insights del solicitante salen de lo que contó el cliente y del caso real del formato, y están marcados como inferencia donde corresponde. El protocolo de pruebas de usabilidad del Sprint 2 es el que los va a validar con usuarios reales.

4.2 Solicitante

Funcionario de cualquier área que necesita comprar algo. Es un usuario ocasional: conoce a fondo lo que pide, pero no el vocabulario del área de compras ni el formato de memoria.

Insight	Evidencia	Qué hace el producto
Reutiliza formatos viejos por comodidad, y arrastra información que ya no aplica.	Dicho por el cliente: en el caso del Fluke 725 se usaron especificaciones de un periodo que ya no correspondía [10][11].	Formulario siempre en blanco, como pidió el cliente (HU-01). Solo se propone el nombre de quien está en sesión.
No sabe qué falta hasta que compras se lo dice, días después.	Dicho por el cliente: el formato pide no dejar espacios vacíos, pero nada impide enviarlo incompleto [10].	Validación en el momento de radicar, campo por campo (HU-15), y resumen antes de enviar (HU-34).
Tiene que preguntar para saber en qué va su solicitud.	Inferencia del equipo: no hay ningún registro consultable fuera de los correos [13].	«Mis requerimientos», con búsqueda (HU-25) y el estado de cada uno (HU-23).
Está en campo, frente al equipo dañado, sin un computador a mano.	Inferencia del equipo a partir de la operación del cliente (mantenimiento, instrumentación, gasoductos) [2][13].	Foto tomada con la cámara del celular desde el mismo formulario (HU-12), interfaz que se adapta al móvil.
Cuando le devuelven algo, se entera por un correo informal y sin claridad de qué corregir.	Inferencia del equipo a partir del flujo actual por correo [10][13].	Devolución con observación obligatoria, correo con el enlace directo y corrección sobre el mismo requerimiento (HU-24).

4.3 Analista de Compras

Personal del área de compras. Es un usuario intensivo: trabaja con la herramienta todos los días y depende de ella para iniciar cada cotización.

Insight	Evidencia	Qué hace el producto
Digita dos veces la misma información.	Dicho por el cliente: cada formato que llega por correo se vuelve a transcribir a la sábana [10].	Lo radicado queda directamente en la base de datos; la sábana se alimenta por exportación, no por digitación (HU-29, HU-30).
No puede cotizar con un formato incompleto, y cada uno es un retraso directo.	Dicho por el cliente [10].	Nada se radica incompleto (HU-15). Y si aun así falta algo, se devuelve desde el sistema en vez de por correo (HU-24).
No tiene un registro consultable de lo que se pidió originalmente.	Dicho por el cliente: ausencia de trazabilidad de las especificaciones iniciales [10].	Ficha completa con ítems, especificaciones, proveedores y adjuntos (HU-22, HU-11), y bitácora de cada cambio (HU-23).
Necesita decidir qué atender primero.	Inferencia del equipo a partir del volumen de solicitudes que describe el cliente [13].	Bandeja con filtros por estado, área, prioridad y fechas (HU-21).
El proceso actual lo desgasta.	Dicho por el cliente, que lo calificó como «tedioso y desgastante» [10].	Es el resumen de todo lo anterior: menos correos, menos transcripción, menos ir y venir.

4.4 Lo que todavía no sabemos

El cliente no ha entregado cifras de su operación: cuántos requerimientos se radican al mes, cuánto tarda la transcripción a la sábana ni cuántos formatos se devuelven por estar incompletos. Está registrado como punto abierto en los acuerdos con el cliente.

Este caso de negocio no inventa esas cifras. Lo que sí hace es dejar el sistema listo para producirlas: desde el Sprint 2 cada requerimiento guarda la fecha de cada cambio de estado y cada devolución con su motivo, que es exactamente lo que necesitan los indicadores de tiempo de atención (HU-31) y de tasa de devolución (HU-32). La primera cifra real del proceso la va a dar el propio producto.

5. Producto o servicio

Qué es

VIA Compras es una aplicación web que digitaliza el formato ADM-F-22 de Coinogas. Tiene tres perfiles, cada uno con su pantalla de entrada:

Perfil	Qué hace
Solicitante	Radica requerimientos, adjunta fotos y documentos, consulta el estado de lo suyo y corrige lo que le devuelven.
Analista de Compras	Atiende la bandeja, revisa la ficha completa, cambia estados y devuelve lo que está incompleto.
Administrador	Parametriza áreas, centros de costo, prioridades y cuentas desde el panel de administración.

Lo entregado

Por épica del backlog, con el estado a la fecha de esta versión. «En main» quiere decir integrado y probado por el pipeline; «En revisión» quiere decir que la pull request está abierta esperando la revisión de un compañero.

Épica 1 · Radicación del requerimiento — Sprint 1

Historia	Qué hace	Estado
HU-01	Formulario siempre en blanco, sin precargar requerimientos anteriores.	En `main`
HU-02	Encabezado: solicitante, área y centro de costo de catálogos cerrados; fecha de solicitud automática.	En `main`
HU-03	Justificación con contador de caracteres.	En `main`
HU-04	Prioridad Alta, Media o Baja, con Media por defecto.	En `main`
HU-05	Fecha requerida que no puede ser anterior a la de solicitud.	En `main`

Épica 2 · Detalle de ítems y especificaciones — Sprint 1 y 2

Historia	Qué hace	Estado
HU-06	Varios ítems por requerimiento, que se agregan y quitan sin recargar, numerados en orden.	En `main`
HU-07	Cantidad entera positiva, unidad de medida y descripción por ítem.	En `main`
HU-08	Marcas de «requiere calibración» y «reembolsable».	En `main`
HU-09	Especificaciones técnicas de cada ítem.	En `main`
HU-10	Total por ítem y total del requerimiento, calculados en vivo y en el servidor.	En `main`

Épica 3 · Evidencias y proveedores sugeridos — Sprint 2

Historia	Qué hace	Estado
HU-11	Fotos (JPG, PNG, WEBP, HEIC) y documentos (PDF, Word, Excel), hasta 10 de 10 MB. Se revisa el contenido real del archivo, no solo la extensión. Prioridad del cliente.	En revisión
HU-12	Foto tomada con la cámara trasera del celular desde el formulario.	En revisión
HU-13	Hasta tres proveedores sugeridos con su teléfono.	En `main`
HU-14	Productos o servicios sustitutos.	En `main`

Épica 4 · Validación, envío y trazabilidad — Sprint 1 y 2

Historia	Qué hace	Estado
HU-15	Ningún requerimiento se radica con campos vacíos; se señala cada uno.	En `main`
HU-16	Consecutivo único `REQ-AAAA-NNNN`, seguro aunque dos personas radiquen al tiempo.	En `main`
HU-17	Confirmación en pantalla con el consecutivo y el resumen.	En `main`
HU-18	Borrador que se guarda y se retoma, con encabezado e ítems.	En `main`
HU-19	Correo al área de compras en cada radicación.	En `main`
HU-34	Aviso de confirmación con resumen antes de enviar.	En `main`
HU-35	Correo de confirmación al solicitante.	En `main`

Épica 5 · Gestión del área de compras — Sprint 2

Historia	Qué hace	Estado
HU-20	Bandeja única con todo lo radicado.	En `main`
HU-21	Filtros y ordenamiento de la bandeja.	En `main`
HU-22	Ficha completa del requerimiento.	En `main`
HU-23	Cambio de estado (Radicado, En revisión, En cotización, Cerrado) con bitácora de quién, cuándo y por qué.	En revisión
HU-24	Devolución con observación obligatoria; el solicitante corrige y reenvía con el mismo consecutivo.	En revisión

Épica 6 · Consulta, reportes y administración — Sprint 2

Historia	Qué hace	Estado
HU-25	«Mis requerimientos», con búsqueda; el estado de cada uno llega con HU-23.	En `main`

Épica 7 · Analítica e indicadores — Sprint 1 y 2

Historia	Qué hace	Estado
HU-29	Vistas analíticas de solo lectura y usuario de base de datos restringido.	En `main`
HU-30	Tablero de indicadores en Power BI Desktop, sin licencias pagas.	En `main`

Transversal

Portada pública, ingreso con cuenta y perfiles, con la identidad visual del prototipo de interfaces del Sprint 0.
Calidad del software: integración continua en GitHub Actions con análisis estático y formato (Ruff), auditoría de dependencias (pip-audit) y pruebas automatizadas con cobertura mínima del 90 % [13]. A la fecha de esta versión, la rama principal tiene 261 pruebas y una cobertura del 97 %.

Valor diferencial

A diferencia del Excel, cada regla de negocio queda garantizada por el sistema y no por la persona que diligencia. Y a diferencia de una plataforma comercial, el sistema se ajusta al formato que Coinogas ya usa, en lugar de pedirle a la empresa que se ajuste a él.

El resultado es una base de datos estructurada, con historia completa de cada requerimiento, que hoy alimenta el tablero de indicadores y que mañana permitirá medir lo que el cliente todavía no puede medir.

Tecnología

Python 3.12, Django 6.1, PostgreSQL 15 y Bootstrap 5.3. Arquitectura web cliente-servidor con plantillas del lado del servidor, adjuntos entregados por una vista que revisa permisos y despliegue previsto en contenedores (Docker).

6. Marco legal aplicable

Norma	Por qué aplica
Ley 142 de 1994 [4]	Régimen de los servicios públicos domiciliarios, bajo el cual opera Coinogas como E.S.P. Contexto de la empresa, no requisito del software.
Ley 1581 de 2012 [5]	El sistema guarda datos personales: nombres y correos de quienes radican. Por eso cada usuario ve solo lo suyo y el acceso analítico es de solo lectura.
Ley 527 de 1999 [6]	Reconoce el valor de los mensajes de datos y fija condiciones para conservarlos —que la información sea accesible, se reproduzca fielmente y registre origen, fecha y hora— [6]. Un requerimiento radicado en el sistema, con consecutivo y bitácora, cumple esas condiciones mejor que un archivo que circula por correo.

Este análisis es de orientación para el proyecto y no reemplaza una revisión jurídica.

7. Riesgos y supuestos

Riesgo o supuesto	Cómo se maneja
Adopción. Si los solicitantes siguen enviando el Excel por correo, el sistema convive con el proceso viejo y la trazabilidad vuelve a partirse en dos.	El formulario respeta el formato conocido y no exige capacitación (RNF-01). El protocolo de usabilidad del Sprint 2 mide si se puede diligenciar sin ayuda.
Cifras de la operación. Sin datos del proceso actual no hay línea base para demostrar la mejora.	Se pidieron al cliente (punto abierto). Mientras tanto, el sistema registra lo necesario para producirlas (sección 4.4).
Sin licencias de Power BI. Confirmado por el cliente en octubre de 2026.	El tablero se construye con Power BI Desktop, que es gratuito, y se versiona en el repositorio.
Infraestructura. El despliegue en la red interna de Coinogas depende del área de tecnología del cliente.	La aplicación está preparada para contenedores y su configuración vive en variables de entorno.

8. Fuentes

Fuentes externas, consultadas el 14 de octubre de 2026:

Coinogas S.A. E.S.P. «Nuestra empresa»: misión, visión, valores corporativos, certificaciones y fecha de fundación. https://www.coinogas.com/nuestra-empresa/
Coinogas S.A. E.S.P. Página principal: servicios, sedes y contacto. https://www.coinogas.com/
Comisión de Regulación de Energía y Gas (CREG), Dirección Ejecutiva. Actuación administrativa del 27 de octubre de 2011, expediente 2011-0078: solicitud de COINOGAS S.A. E.S.P. para la aprobación de los cargos de transporte del gasoducto Floreña–Yopal, de su propiedad. https://gestornormativo.creg.gov.co/gestor/entorno/docs/pdf/au_creg_4141_2011.pdf
Congreso de Colombia. Ley 142 de 1994, régimen de los servicios públicos domiciliarios. Gestor Normativo de Función Pública. https://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=2752
Congreso de Colombia. Ley Estatutaria 1581 de 2012, disposiciones generales para la protección de datos personales. Gestor Normativo de Función Pública. https://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=49981
Congreso de Colombia. Ley 527 de 1999, mensajes de datos, comercio electrónico y firmas digitales (artículos 6 y 12). Gestor Normativo de Función Pública. https://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=4276
Deloitte. Procurement at the Tipping Point: Deloitte's 2025 Chief Procurement Officer Survey, nota de prensa, agosto de 2025. https://www.deloitte.com/us/en/about/press-room/2025-chief-procurement-officer-survey.html
ISO. Norma ISO 9001:2015, Sistemas de gestión de la calidad — Requisitos, cláusulas 7.5 (Información documentada) y 8.4 (Control de los procesos, productos y servicios suministrados externamente).
Reyes Tavara, R. Avance de los cambios de la norma ISO 9001:2015, apuntes de clase con base en LRQA, publicados por la OACI. Sobre el reemplazo de «registros» por «información documentada». https://www.icao.int/sites/default/files/sp-files/SAM/Documents/2015-SAMQMSMET/12_Cambios%20ISO%209001.20015_RR.pdf

Fuentes internas del proyecto:

Grabación y notas de la sesión de levantamiento con el cliente, 24 de julio de 2026. Ver Evidencias de las ceremonias, Acuerdos con el cliente y Generalidades del proyecto.
Formato ADM-F-22 «Manifestación Requerimiento de Compra», revisión 02, diligenciado con el caso real de calibración del Fluke 725. Entregado por el cliente.
Determinación de necesidades, sección 2.2: análisis de la competencia, con costos de referencia consultados en agosto de 2026.
Repositorio del proyecto: issues, pull requests y pipeline de integración continua. https://github.com/Davidcuama/via-coinogas. Proceso actual (AS-IS) y alcance en Generalidades del proyecto.

Historial de versiones

Versión	Sprint	Autor	Cambios
V1	Sprint 1	Juan Esteban Villada	Descripción del negocio, análisis del mercado y producto con lo entregado en el Sprint 0.
V2	Sprint 2	Juan Pablo Posso	Misión, visión y valores del producto. Insights del solicitante y del analista de Compras, con su evidencia y su limitación. Fuentes verificables para los datos de la empresa, el mercado y el marco legal. Producto actualizado con lo entregado en los sprints 1 y 2. Certificaciones de la empresa precisadas con su fuente. Nuevas secciones de marco legal y de riesgos y supuestos.