El coste anual del mainframe en un presupuesto defendible

El coste anual del mainframe no es la cifra de una factura de hardware. Es una suma de contratos, mediciones de capacidad, obligaciones laborales, gastos de instalaciones y provisiones de riesgo que reaccionan de forma distinta cuando cambia la carga. Si lo reduce todo a una tarifa media, construirá un mal caso de migración: el ahorro parecerá milagroso o la máquina parecerá imposible de abandonar.

He visto fracasar análisis porque finanzas pidió un único precio por MIPS e ingeniería se lo dio. Los MIPS describen capacidad relativa de procesador, pero las facturas principales de software no son simplemente MIPS multiplicados por una tarifa pública. El modelo útil empieza en cada factura y contrato, identifica qué impulsa cada partida y pregunta si trasladar una carga cambia realmente ese factor.

No existe una tarifa universal honesta

Un presupuesto anual necesita bloques separados porque cada uno responde a un evento distinto. El software por capacidad puede seguir un pico medido de cuatro horas. El mantenimiento puede quedar fijo hasta retirar la máquina. El personal cambia cuando cambian responsabilidades y guardias. Un reparto del centro de datos puede seguir en los libros aunque el espacio esté vacío.

Separe, como mínimo, estos bloques:

• Software por capacidad, incluidos productos cuyo cargo sigue MSU u otra métrica medida.
• Software fijo o escalonado, con licencias anuales, soporte y productos tarifados por clase de máquina o entorno.
• Compra o alquiler del hardware, mantenimiento, almacenamiento, red y dispositivos conectados.
• Personal, soporte externo, instalaciones, recuperación, operaciones de seguridad y cumplimiento.

No asigne todo con el mismo denominador. La CPU puede servir para un producto y ser absurda para almacenamiento, soporte o un especialista dedicado a coordinar versiones. Elija el factor que explica el coste: aportación al pico, espacio ocupado, tickets resueltos, entornos usados o esfuerzo dedicado. Deje sin asignar un coste compartido si cualquier reparto fingiría una precisión inexistente.

El primer artefacto debe ser un registro contractual, no un total. Anote proveedor, producto, plazo, renovación, métrica, mínimo comprometido, nivel actual, condición de cancelación y fuente de prueba. Asigne un responsable que defienda la interpretación. Una celda llamada «software mainframe» no dice qué cargo baja al mover una carga.

Los MIPS estiman capacidad pero rara vez reproducen la factura

MIPS significa millones de instrucciones por segundo, pero no es una unidad estable de trabajo empresarial ni la moneda general de IBM. Cambian las mezclas de instrucciones y las generaciones nuevas hacen más trabajo útil con una capacidad nominal. Batch con mucha E/S, transacciones, compresión, Java y bases de datos presionan la máquina de forma distinta. Una cifra sin fuente y método es una etiqueta, no una prueba.

Las organizaciones usan MIPS para planificar porque ofrecen una escala conocida. Algunos proveedores también usan bandas MIPS en contratos. La cifra importa, pero no es universal. Pregunte si cada valor es una clasificación de máquina, uso observado, pico, media o banda contractual. No son intercambiables.

El atajo peligroso es este:

annual mainframe cost = total MIPS x assumed price per MIPS

La fórmula oculta mínimos, niveles de software, motores especializados, máquinas de desarrollo, almacenamiento y personal. También supone que el siguiente MIPS cuesta como el primero. Los contratos suelen desmentirlo. Un aumento marginal puede cruzar un nivel; una bajada moderada puede no ahorrar nada hasta cambiar el mínimo o la banda.

Use MIPS como control. Si el inventario atribuye media plataforma a una aplicación y los informes derivados de SMF muestran una cuota mucho menor de procesador general, investigue el límite. La estimación quizá incluya base de datos y middleware cargados en otro sitio, o la medición omita jobs con otro identificador. La discusión revela propiedad. Multiplicar un total incierto por una tarifa incierta solo pone símbolo monetario a la duda.

La facturación MSU sigue medidas y reglas contractuales

Una MSU, o million service unit, mide capacidad usada para precios de software mainframe IBM. Está más cerca de la factura que MIPS, pero no es un precio. El cargo depende de producto, modelo, máquina elegible, contrato, país, nivel comprometido y uso declarado. Desconfíe de una cifra universal por MSU.

En muchos acuerdos de subcapacidad se observa la media móvil de cuatro horas, R4HA. Workload Manager registra consumo y Sub-Capacity Reporting Tool procesa los datos para informar cargos elegibles. La documentación SCRT de IBM exige datos completos y válidos durante el periodo. Un intervalo ausente no demuestra carga gratuita: es un defecto que puede afectar la aceptación o cálculo.

Se suelen confundir tres valores:

• La demanda instantánea dice qué ocurre ahora.
• La media móvil suaviza demanda durante la ventana definida.
• El valor facturado aplica elegibilidad y contrato a la capacidad declarada.

Confundirlos crea ahorro imaginario. Quitar un job fuera del pico reduce CPU y energía sin cambiar software. Incluso dentro del pico puede no ahorrar si otra carga fija el nuevo máximo, hay mínimo o el producto sigue siendo necesario.

Cree una vista de aportación al pico desde los intervalos. Para cada producto y partición, registre hora del máximo mensual, cargas activas, MSU declaradas, mínimo o nivel contractual y siguiente umbral inferior. Pruebe la retirada sobre toda la serie. No reste la media de una aplicación al pico. Los picos se mueven.

Los motores especializados complican el cálculo. El trabajo elegible en zIIP puede cambiar la economía, pero no elimina software, almacenamiento, operaciones ni capacidad de respaldo. Documente qué es elegible, dónde se ejecutó y qué sucede con contención o failover. La elegibilidad es técnica; la factura es contractual. Necesita ambas.

Reconcilie también la cadena de informes. Relacione cada central processor complex y LPAR con los identificadores del informe, y cada producto cobrado con los lugares donde se licencia y usa. Verifique desarrollo, pruebas, recuperación y producción. Una LPAR ausente del inventario puede aportar a la factura; una aplicación listada quizá no use el producto.

Conserve los intervalos brutos de los meses modelados. Un máximo mensual aislado no muestra qué pasa al mover o acortar un job. Para la carga candidata, repita el cálculo quitando solo consumo atribuible, recalcule la media y encuentre el nuevo máximo. Sigue siendo estimación porque contratos y reglas se superponen a los datos, pero supera a restar una media anual de un pico.

La repetición descubre desplazamiento. Si un cierre fija el pico del martes y los extractos de clientes quedan apenas debajo el jueves, quitar el cierre no ahorra toda su contribución. El jueves pasa a ser máximo y solo la diferencia puede cambiar la medición. Si ambos están en la misma banda, la factura inmediata puede quedar igual.

Pida al gestor de activos el derecho y la factura, no solo la lista de productos. Un producto instalado puede no cobrarse, formar parte de una suite, tener mínimo o estar en un acuerdo mayor. Un componente menor del inventario puede tener soporte propio. Compras decide qué puede cancelarse; el descubrimiento técnico decide si es seguro. Ningún equipo completa la línea solo.

Desarrollo y pruebas merecen atención separada. A menudo se reparte lo no productivo por CPU de producción, aunque una aplicación con muchas entregas consuma más pruebas. Registre entornos dedicados, licencias, datos de prueba y derechos activos o de reserva. Una migración puede quitar producción y dejar una imagen para errores históricos, consultas fiscales o una transición posterior.

No use precios de catálogo como facturas. Sirven para entender una métrica, pero acuerdos negociados, paquetes, topes y mínimos fijan el efectivo. Si el contrato está restringido, proteja el modelo igual en vez de sustituirlo por una estimación pública. Una vista redactada muestra categorías y fechas; el anexo controlado conserva proveedores y precios.

Divisas y periodos contables también distorsionan. Normalice moneda con el método de finanzas, asigne soporte prepagado al periodo y separe impuestos si el caso los trata aparte. Reconcilie abonos y ajustes, sin escoger un mes favorable. Doce meses deben explicar diferencias entre valor contractual, efectivo facturado y libro mayor.

Asigne confianza a cada afirmación, no al libro entero. Una cláusula firmada da alta confianza a una cancelación. Una bajada inferida con etiquetas incompletas es débil. Una salida de hardware dependiente de tres migraciones es condicional. Ponga la prueba pendiente y su responsable junto a cada línea. La incertidumbre es soportable cuando se ve su origen y el trabajo para resolverla.

El hardware cuesta más que la orden de compra

Incluye compra o alquiler, mantenimiento, disco y cinta, red, instalaciones, repuestos y segundo sitio. Algunos poseen el procesador y pagan mantenimiento creciente; otros renuevan con financiación. La contabilidad cambia, pero la obligación tiene plazo y condición de salida.

Actualizar el procesador puede elevar la banda de software aunque la carga apenas cambie. Mover carga quizá no ahorre mientras siga el alquiler o una configuración menor rompa la resiliencia. Separe depreciación de efectivo evitable. La primera puede continuar; una renovación de mantenimiento puede evitarse.

Use medidas para instalaciones: energía, espacio contratado, refrigeración, manos remotas y recuperación. Pero no lidere con electricidad. Software y personal escaso suelen dominar. La energía importa cuando abandonar la plataforma permite cerrar o reducir una obligación física.

Registre la primera fecha de retirada de cada coste. Si la máquina sirve doce sistemas y migra uno, chasis, mantenimiento y recuperación quizá no cambien. Por eso el ahorro de aplicación difiere del efectivo del conjunto.

El especialista caro suele cubrir varios trabajos

No modele personal contando desarrolladores COBOL. Las personas difíciles de sustituir cubren producción, JCL, planificador, RACF, CICS o IMS, recuperación Db2, rendimiento, almacenamiento, versiones, incidentes y conocimiento no documentado. Un nombre puede ocultar cinco funciones.

Divida por capacidad. Anote titular, suplente, esfuerzo semanal, guardia, dependencia externa y sistema que aún lo exige. Muestra concentración sin inventar valor para conocimiento tácito y evita contabilizar todo un salario cuando la persona operará el reemplazo, ayudará otra carga o seguirá hasta retirar.

Trate igual a contratistas y anticipos. Quizá solo se cancelen en renovación. Un especialista cubre varias aplicaciones y un proveedor cobra equipo mínimo. Lea alcance y preaviso antes de llamarlo variable.

Estoy en contra de usar el coste de contratación sustituta como coste laboral anual. Es popular porque la jubilación es un riesgo y un reclutador da una cifra grande. Es erróneo: una contratación hipotética no es el gasto actual. Mantenga efectivo recurrente y exposición de transición en columnas separadas. La dirección puede decidir con ambas, no auditar una prima de miedo mezclada.

No suponga que la migración elimina a esas personas. Durante paridad y transición su saber importa más. Después quizá convenga retenerlas como dueñas del dominio y quitar guardias de infraestructura obsoleta. El ahorro puede ser contratos no renovados, menos guardia o vacantes sin cubrir, no despidos.

Cada fila de una factura de carga necesita pruebas

Una factura defendible conecta cada importe con una fuente y etiqueta su comportamiento. Empiece con doce meses para incluir cierres, picos estacionales y soporte anual. Reconcilie con el libro antes de asignar un céntimo.

Use esta forma:

cost_id,annual_cash,billing_driver,contract_floor,renewal_date,workload_share,removal_trigger,evidence
SW001,REDACTED,product_peak_msu,REDACTED,YYYY-MM-DD,measured,lower_tier_at_renewal,SCRT_report
HW004,REDACTED,fixed_lease,full_term,YYYY-MM-DD,shared,lease_end,signed_contract
LAB007,REDACTED,dedicated_effort,none,YYYY-MM-DD,time_study,role_reassigned,staffing_plan

Oculte importes en ejemplos, pero exija cifras reales en el modelo. removal_trigger obliga a nombrar el evento que cambia efectivo: nivel inferior aceptado al renovar, licencia cancelada, alquiler terminado, máquina retirada, soporte reducido o vacante sin cubrir. «Aplicación migrada» rara vez basta.

Clasifique cada fila: evitable con esta carga, evitable con un grupo, fija hasta una fecha o retenida. Ejecute dos modelos. La vista de carga muestra consumo; la de caja muestra facturas y nómina que cambian. Ambas valen, pero solo la segunda financia el caso.

El cálculo revela la diferencia:

run-rate allocation = annual cash x workload share
year-1 cash saving = annual cash x removable share x active fraction of year
net year-1 effect = year-1 cash saving - migration cash cost - overlap cost
steady-state saving = terminated and resized annual obligations

No meta reducción de riesgo en ahorro de caja. Siga exposición a caída, auditoría, recuperación y concentración con dueño y pruebas. Si los monetiza, muestre probabilidad e impacto por separado.

Antes de aprobar, finanzas, operaciones, compras y responsable de aplicación deben firmar sus filas. Compras descubre renovaciones, operaciones dependencias, la aplicación jobs e interfaces y finanzas impide que un reparto parezca gasto eliminado.

La migración elimina contratos cuando salen sus dependencias

Puede eliminar licencias, demanda, crecimiento de almacenamiento, ventanas batch, cobertura especializada y hardware, cada uno en fecha distinta. La previsión segura es una escalera de dependencias, no un porcentaje.

Mapee transacciones, jobs, ficheros, impresión, procedimientos, seguridad, scripts, conciliación y consumidores. Mover un frontal dejando el registro en Db2 no elimina la base. Reescribir batch manteniendo tres jobs JCL no elimina el planificador.

Identifique el umbral de cada coste compartido. Un producto sale al irse su última carga de la LPAR. Las cintas pueden seguir por retención. Recuperación se dimensiona por el mayor servicio restante. Los circuitos sirven otros sistemas. Ordenar una cartera puede valer más que elegir por coste aparente.

Planifique el cierre: archive con regla aprobada, quite identidades y jobs, detenga feeds, pruebe recuperación, actualice procedimientos, notifique contratos y deseche hardware. Una carga sin tráfico aún puede costar y fallar auditoría.

CodeHero reescribe todo el código heredado en Go, Rust y TypeScript y verifica comportamiento con un arnés de paridad frente a tráfico grabado. Puede entregar en menos de 30 días, pero preavisos, retención y dependencias fijan cuándo baja el coste anual.

Varios costes sobreviven en la nueva plataforma

La migración cambia la estructura, no elimina ingeniería de producción. El reemplazo necesita cómputo, bases, almacenamiento, observabilidad, copias, seguridad, soporte, incidentes, recuperación y conocimiento empresarial. Ponerlo a cero es defensa, no análisis.

Aplique disciplina al cloud. Separe base, picos, base gestionada, red, copias, no producción y soporte. No compare mainframe completo con VM desnuda. Incluya paralelo y almacenamiento temporal.

Algunas tareas bajan por mercados y herramientas comunes; otras se trasladan. RACF pasa a identidad, SMF a logs, métricas y trazas, Db2 a copias Postgres. Nombre al nuevo dueño antes de quitar al viejo.

La holgura también permanece. El reemplazo debe cumplir latencia, rendimiento, cierre y recuperación observados bajo demanda real. Dimensione con trazas y pruebas, no líneas de código. La arquitectura puede reducir desperdicio, pero presupueste capacidad demostrada.

Fije la base antes de pedir propuestas: perímetro, doce meses y servicios compartidos. Liste renovaciones, traslados y cambios de personal que ocurrirían sin migración. De otro modo el proyecto reclama ahorros previstos o carga aumentos inevitables.

Muestre tres vistas: comprometida, año de salida con cancelaciones parciales y paralelo, y estado estable tras terminar producción, recuperación, retención y soporte antiguos. Feche cada una. Una cifra anual sin calendario supone que todo ahorro empieza el día uno.

Use puertas de salida, no una fecha optimista. Además del tráfico puede requerir ciclo completo, resultados conciliados, recuperación aceptada, fin de rollback, archivo, accesos retirados, servicio aceptado y aviso recibido. Cada puerta necesita dueño y prueba; si se retrasa, mueva el ahorro.

La paridad necesita presupuesto propio. Ambas plataformas procesan casos mientras se comparan resultados. Incluya cómputo y almacenamiento duplicados, extractos, pruebas, defectos y aprobadores. No lo oculte en contingencia; únalo al plan de verificación.

Defina excepciones residuales. Si los casos raros vuelven al mainframe, la dependencia sigue. Cuente frecuencia, identifique regla y decida implementarla, retirarla con aprobación o usar un proceso manual limitado. Un fallback indefinido mantiene licencias y soporte.

Tras la transición, compare facturas y previsión varios ciclos. Confirme picos, niveles, soporte, almacenamiento, circuitos y contratistas. Cierre pedidos y renovaciones automáticas. Registre desviación por fila para que la próxima migración use comportamiento observado.

La aprobación debe asignar costes varados. Si una aplicación sale y un producto queda, el ahorro no puede contarse ahora y otra vez después. Mantenga un registro de importes reclamados, realizados y varados para evitar duplicidad y agrupar próximas cargas por dependencia.

La decisión depende del efectivo eliminable y una fecha

Muestre gasto anual actual, coste estable del reemplazo y efectivo de transición, junto con obligaciones fechadas. Así aparecen ahorros tardíos y el solapamiento del primer año.

Pruebe pico sin bajar, alquiler no cancelable, producto retenido, más capacidad nueva, retención larga y paralelo adicional. Si el caso solo funciona al desaparecer todo el día de transición, no funciona.

La decisión no es solo financiera. Plazos de cambio, recuperación o concentración pueden justificarla con ahorro modesto el primer año. Dígalo sin esconder razones estratégicas en ahorro inventado.

Abra la aprobación con registro contractual, picos SCRT, mapa de capacidades, límite de carga y tabla de desencadenantes. Con dueño, evento y fecha para cada ahorro, el coste deja de ser folklore de MIPS y se convierte en plan ejecutable.