Documento de comité · no es un presupuesto ni un contrato de software
2026.09.14
Confidencial interno
El core es implementar, remodelar y, cuando toque, mantener tiendas para cadenas de retail. Pocos proyectos propios. Cada proyecto es distinto y puede mezclar restricciones (tienda abierta, techos, mall). El ERP nace de eso y se adapta sobre la marcha: no parte de tres tipos preseteados ni de un edificio de 5 pisos.
Pedido al comité. 1) Etapa 1 = estimación → vigente de ese proyecto y el viaje del código hasta pedido/tareo/kardex, con el reloj de valorización que OT confirme. 2) Mandar cuestionarios OT (11 etapas + tres campos libres, incluido un prompt para la IA) y gerencia (9 preguntas, mismo prompt). 3) No implantar S10, OCERP ni ConstrucSoft. 4) ConstrucSoft, si aparece el código, es diccionario de campos. 5) El Excel de Metro Piura es referencia de oferta, no el piloto todavía.
Centro de costo. La regla: un proyecto = una tienda. Excepción (no es la regla): un cambio menor que cubre varias tiendas — hay que declararlo, no esconderlo en el mismo Excel.
Plazo. No hay duración tipo. Cada proyecto se estima con lo que pida el cliente y con las restricciones de esa tienda / mall / gerencia de local. Un “3 a 5 meses” que se mencionó es solo un ejemplo, no el modelo.
Remodelación, implementación y techos son restricciones, no tres productos. Un mismo proyecto puede mezclarlas. La interfaz nace simple (proyecto + archivos) y se abre si hace falta.
¿Itemizado? Se importa. ¿Sin PU? Metrados y carta. ¿GG detallado? Líneas. ¿Valoriza por hito? Aparecen hitos. Nada de combo que cambie todo el ERP.
Metro Piura (oferta con PU) y Patio Trujillo (licitación sin PU) son dos estados del mismo flujo de OT. El cobro vive en el flujo macro.
Obra propia inmobiliaria, si hay, es excepción: otro árbol, otro GG, otro cliente interno.
No es “días a apertura”. El reloj lo pone el cliente y el proyecto:
El número de una partida vive en el Excel de la cadena, en un Excel interno y en un pedido sin código. Se valoriza un periodo y el adicional de la etapa anterior sigue abierto. La gerencia de tienda mueve el calendario y el techo no se entera. Techos mezclado con fit-out. Gerencia no ve margen de ese proyecto a mitad de obra.
Encargo de esa cadena → estimación en su formato + mapeo Inssitu → vigente de ese proyecto (hitos incluidos) → pedidos / tareo / kardex → valorizar al mandante en su periodo y costear adentro → liquidar → tesorería, planilla y SUNAT.
Regla: un movimiento = un proyecto + una partida + un documento. Fuera de etapa 1: CRM inmobiliario, BIM, portal de proveedores, SUNAT, Maestro de OCs (sigue vivo aparte).
En Perú el presupuesto interno (APU cotizado) no es el precio oferta. Entre los dos hay un factor. Ese factor no es el gasto general ni la utilidad.
Paquete de tercero. HVAC, IIEE, ACI… se cotizan completos, entran al interno como un monto, y después se reconstruye el APU con criterio estándar, sin afectar precios de mercado trabados.
Plantilla del cliente. Tres modos: rígida (Cencosud: no agregar ni eliminar), modificable, o no hay itemizado y se construye con memoria + EETT + planos. El archivo no es un estándar eterno del cliente: a veces lo manda la supervisión o la dirección técnica (terceros). El importador abre, detecta cabeceras, sugiere el enlace por el nombre y lo muestra para que OT lo cambie. El mapeo anterior es pista, no candado. Excel y PDF.
Documento de referencia. Oferta Metro PDS Piura 19.02.26. Solo precios oferta, no internos. CD S/ 6,15 M · 8 especialidades · neto sin IGV S/ 7,10 M. Equipos VRF en S/ 0. Itemizado rígido. El factor no se ve: OT debe decir cómo se aplicó.
ConstrucSoft (Ing. Gilberto León Ruiz): diccionario peruano de APU, GG, cuadrillas, valorización. Desktop restrictivo. Un maestro rígido duele con cinco cadenas. No se implanta. Si hay código, se extraen campos.
S10: idioma de partida y valorización. No open source. Pensado para obra gruesa. Se copia el oficio, no el producto.
OpenConstructionERP: BIM/estimación, AGPL, pack Latam ≠ Perú retail. No se copia el código.
OT — 11 etapas con pista. Tipo de obra, CC, plazo, cómo valoriza esa cadena, paquetes de tercero, factor, GG detallado. Tres campos al final: qué mejorar hoy, qué espera del software, y un párrafo libre (prompt) para la IA. Tres ejemplos: remodelación abierta, implementación, y el Excel real de Metro Piura. Techos: marcar el tipo y decir qué no aplica.
Gerencia — 9 preguntas. Techo, reloj, tipos, reporte, qué no tocar, qué espera del software, y el mismo párrafo libre para la IA. Cada persona graba el suyo.
PDFs y formularios en Comité. El mail de descubrimiento no invita a curiosear Estimación rota: apunta a cuestionarios y PDFs. El ERP operativo ya tiene importador, factor, GG y GO.
| Tema | Recomendación |
|---|---|
| Unidad | 1 proyecto = 1 tienda. Excepción: cambio menor en varias, declarada |
| Tipos | Restricciones, no un combo. Un proyecto puede mezclar tienda abierta, techos, mall. Se declara sobre la marcha |
| Plazo | Se estima en cada proyecto. Lo pide el cliente; lo mueven sus restricciones. No hay duración tipo |
| Reloj | Hitos + valorización (periodo por cadena) + curva S + liquidación. Apertura = un hito |
| Precio | Interno × factor = oferta. GG detallado y utilidad aparte. No se mezclan |
| Factor | Global, luego familia / partida / tipo de gasto. Reaplicar el global pregunta si pisa |
| Itemizado | Del cliente (rígido o no) o se arma de memoria + EETT + planos. Cambia si lo manda la supervisión / DT |
| Importador | Abrir → cabeceras → sugerir por nombre → tabla visual. Cada archivo. OT corrige |
| Etapa 1 | Estimación + vigente + código hasta pedido/tareo/kardex + dato de valorización |
| Piloto | Una remodelación real + una implementación real. Techos no es el piloto |
| Usuarios | Ingeniero y arquitecto de proyecto, OT, compras, gerencia. No capataz |
| Siguiente paso | OT, gerencia y logística llenan. Buzón erp@inssitu.com.pe. Envío con GO aparte |