Tema 5.4 — Planificación de recursos empresariales (ERP)

En una frase: La planificación de recursos empresariales es el sistema de oficina trasera integrado —finanzas, recursos humanos, nómina, contratación, y cadena de suministro— que actúa como el sistema de registro de la organización para el dinero, las personas, y las existencias, y silenciosamente sustenta casi cada forma de trabajar en este libro.

Por qué esto importa en la salud y la atención#

La transformación digital en la salud y la atención recibe su atención de los sistemas clínicos —la historia clínica electrónica, el registro de atención compartido, la aplicación del paciente. Pero ninguno de esos opera sin la poco glamorosa oficina trasera debajo de ellos. El personal debe ser reclutado, programado, y pagado; los proveedores deben ser contratados y liquidados; los medicamentos, dispositivos, y consumibles deben pedirse y rastrearse; y cada libra debe contabilizarse contra presupuestos públicos estrictamente restringidos. ERP es donde eso sucede, y cuando falla, las consecuencias son inmediatas: personal sin pagar, contratación estancada, cuentas no conciliadas, y una función de finanzas volando a ciegas.

La escala es enorme. NHS Shared Business Services (NHS SBS), una empresa conjunta creada en 2004, opera una plataforma nacional de finanzas y contratación basada en Oracle que procesa millones de facturas y maneja una porción muy grande del gasto total del NHS para más de cien organizaciones del NHS (véase Fuentes clave). Las decisiones de ERP por tanto no son una preocupación de finanzas de nicho —dan forma a la gestión de la fuerza laboral, el control del dinero público, y la calidad de datos de la que depende cada análisis río abajo. Para un director, ERP es tanto un habilitador fundamental como uno de los programas de mayor riesgo que una organización jamás intentará.

Conceptos clave#

Qué es ERP. Una suite única e integrada de módulos de planificación de recursos empresariales que comparten una base de datos y un conjunto de datos maestros, cubriendo los procesos administrativos centrales de la empresa: libro mayor y contabilidad financiera, cuentas por pagar y por cobrar, administración de RR. HH. y fuerza laboral, nómina, contratación (compra a pago), inventario y cadena de suministro, y cada vez más planificación y analítica (FP&A —planificación y análisis financiero). El punto de la "integración" es que un pedido de compra, una recepción de mercancías, y una factura se concilian automáticamente porque son los mismos datos, no tres copias.

Sistema de registro. ERP es la fuente autoritativa para los datos financieros y de recursos —el libro mayor en el que confían los auditores y la nómina de la que se paga al personal. Otros sistemas pueden tener copias operativas, pero el ERP es la versión de verdad para el dinero y, a menudo, para el registro sustantivo de RR. HH.

Datos maestros. Los datos de referencia compartidos de los que depende todo lo demás: el plan de cuentas, los centros de coste, los registros de proveedores, el catálogo de artículos, y los registros de empleados. Los datos maestros son el determinante silencioso del éxito de ERP —los datos maestros sucios, duplicados, o inconsistentes corrompen el reporte, rompen la conciliación, y socavan cada proceso construido encima.

Plataformas comunes en la salud y el sector público. En el NHS y el sector público más amplio del Reino Unido las principales plataformas ERP son Oracle (dominante, en gran parte a través de NHS SBS y consorcios como NEP), SAP, Unit4 (ampliamente elegido por fideicomisos, universidades, y autoridades locales), y Microsoft Dynamics 365. Las autoridades locales que entregan atención social para adultos operan la misma clase de sistemas para sus finanzas y contratación. La dirección moderna de viaje es el ERP en la nube (software como servicio) en lugar de instalaciones locales.

Servicios compartidos. En lugar de que cada organización opere su propio ERP, muchas comparten una plataforma común y una operación de oficina trasera común —el modelo NHS SBS, y los consorcios del NHS que operan instancias con plantilla de Oracle Cloud. Los servicios compartidos intercambian algo de flexibilidad local por estandarización, economías de escala, y una carga colectiva de implementación y apoyo más pequeña.

Buenas prácticas#

1. Tratar los datos maestros como la base, no una idea de última hora. Limpia y desduplica el plan de cuentas, los registros de proveedores, el catálogo de artículos, y los datos de empleados antes de la migración, y establece la propiedad de gobernanza de datos continua. Los fallos de ERP más dañinos se remontan a malos datos maestros que ninguna cantidad de buen software puede arreglar; un flujo de trabajo de calidad de datos no es opcional.

2. Adoptar el estándar; minimizar la personalización. Configura el ERP según la plantilla estándar del proveedor o consorcio dondequiera que el proceso sea genuinamente una mercancía, y reserva el cambio a medida para el raro diferenciador verdadero. La personalización pesada infla el coste, arruina la capacidad de actualización, y reimporta el desorden local del que intentabas escapar —el ERP en la nube en particular castiga el instinto de "hazlo parecerse a nuestro sistema antiguo".

3. Diseñar las integraciones deliberadamente. ERP no se sostiene solo: debe intercambiar datos con sistemas de fuerza laboral y programación electrónica, sistemas clínicos y de farmacia (para existencias y costeo), banca, y analítica. Mapea cada interfaz, posee los contratos de datos, y pruébalos de extremo a extremo —una nómina alimentada por un feed de programación roto paga mal a la gente, y eso es un fallo que destruye la confianza.

4. Ejecutar el reemplazo de ERP como un programa importante, con la gestión del cambio en su núcleo. Una implementación de ERP es un programa de cambio de negocio que resulta involucrar software, no un proyecto de TI. Dótalo de recursos con disciplina de programa (véase el Tema 5.2 — Gestión de programas) y un esfuerzo genuino de gestión del cambio (véase el Tema 8.1 — Gestión del cambio), porque la mayor parte del dolor de ERP son las personas y el proceso, no la tecnología.

5. Ser honesto sobre el riesgo del programa ERP. Las grandes implementaciones de ERP tienen una reputación bien ganada de exceder el tiempo y coste y de no entregar el beneficio; la literatura de fallo es extensa y transversal a los sectores. Incorpora contingencia, evita una puesta en marcha de big bang donde un enfoque escalonado sea factible, y nunca dejes que un cronograma optimista anule la preparación —una fecha deslizada es recuperable, una nómina o transición de libro mayor chapucera no lo es.

6. Proteger la puesta en marcha y el período posterior a ella. Planifica la transición de datos, la ejecución paralela, la conciliación, y el apoyo de hiperatención en detalle, y resiste la presión de acortarlos. Las semanas alrededor de la puesta en marcha son cuando los proveedores no se pagan y se rompe el cierre de fin de mes; un período de estabilización bien dotado de personal es la diferencia entre un comienzo difícil y una crisis pública.

7. Usar ERP como el sistema de registro de gestión de recursos —y diseñar formas de trabajar alrededor de él. Deja que el ERP sea la fuente única para centros de coste, presupuestos, aprobaciones de contratación, y establecimiento de fuerza laboral, y alinea tus procesos operativos con él en lugar de mantener hojas de cálculo en la sombra. Los sistemas en la sombra reintroducen la fragmentación que ERP existe para eliminar y silenciosamente pudren la calidad de datos.

8. Sopesar los servicios compartidos y el ERP en la nube según sus disyuntivas reales. Las plataformas compartidas (NHS SBS, consorcios estilo NEP) y el ERP en la nube ofrecen estandarización, escala, actualizaciones continuas, y una carga local más ligera, al coste de algo de flexibilidad local y una dependencia del proveedor. Elige deliberadamente: para la mayoría de las organizaciones la ganancia de estandarización supera la flexibilidad perdida, pero la decisión debería tomarse con los ojos abiertos, no por defecto.

Preguntas para debatir con tu equipo#

1. ¿Cuán seguros estamos —con evidencia, no aseguramiento— sobre la calidad de los datos maestros que llevaríamos a un nuevo ERP, y quién los posee después de la puesta en marcha? Los datos maestros son el determinante silencioso del éxito de ERP, sin embargo rutinariamente se tratan como una tarea de limpieza de migración en lugar de la base que son, así que esta pregunta prueba si el equipo ha mirado detenidamente el plan de cuentas, los registros de proveedores, el catálogo de artículos, y el maestro de empleados o simplemente espera que estén limpios. En un entorno de salud y atención lo que está en juego es concreto: los registros de proveedores duplicados rompen la conciliación de compra a pago, un maestro de empleados que no concuerda con ESR paga mal a la gente, y un plan de cuentas inconsistente corrompe cada reporte financiero río abajo del que dependen la junta directiva y los auditores. La tensión que vale la pena debatir es la atracción de migrar al por mayor para cumplir una fecha frente a los meses de limpieza y desduplicación poco glamorosos que exige la buena práctica, y si alguien senior está dispuesto a financiar un flujo de trabajo de calidad de datos que no muestra ningún producto visible. Una respuesta sólida cita conteos reales —cuántos proveedores duplicados, cuántos registros de empleados no conciliados— en lugar de una sensación general de que "los datos están más o menos bien". También debería nombrar a la persona y mecanismo de gobernanza responsable de la calidad de datos maestros después de la puesta en marcha, porque los datos limpiados una vez y luego dejados sin gobernar simplemente derivan de vuelta al desorden.

2. ¿Dónde estamos genuinamente tentados a personalizar el ERP para preservar un proceso familiar, y esa diferencia es un diferenciador real o solo el desorden antiguo del que intentamos escapar? La personalización pesada es la trampa clásica de ERP empresarial: infla el coste, arruina la capacidad de actualización, y reimporta la misma fragmentación local que el programa pretendía eliminar, y el ERP en la nube en particular castiga el instinto de "hazlo parecerse a nuestro sistema antiguo". Esta pregunta pide al equipo ser específico sobre qué procesos insistirán en doblar el software para ajustar, y justificar cada uno contra una prueba dura de si es un verdadero diferenciador o meramente un hábito cómodo. El debate importa porque en la salud y la atención casi cada proceso de oficina trasera —libro mayor, aprobaciones de contratación, administración de nómina— es genuinamente una mercancía, así que el predeterminado honesto debería ser adoptar la plantilla estándar del proveedor o consorcio y cambiar el proceso, no el software. Los ángulos concretos incluyen listar cada personalización solicitada y preguntar quién se beneficia, qué coste de actualización bloquea, y si un fideicomiso vecino en la misma plantilla se maneja sin ella. Una buena respuesta distingue la rara excepción legítima de las muchas solicitudes impulsadas por la aversión al cambio, y reconoce que adoptar el estándar es un problema de gestión de cambio y liderazgo, no técnico. También debería confrontar el coste a largo plazo: cada cambio a medida es un impuesto pagado en cada versión futura de la nube.

3. ¿Hemos dotado de recursos honestamente el lado humano y de proceso de este cambio de ERP —transición, ejecución paralela, hiperatención, formación, y pruebas de integración— o lo estamos operando silenciosamente como un proyecto de TI? La literatura de fallo es inequívoca en que la mayor parte del dolor de ERP son las personas y el proceso en lugar de la tecnología, así que esta pregunta expone si el programa es genuinamente un esfuerzo de cambio de negocio o un intercambio de TI vestido con ropa de programa. El período alrededor de la puesta en marcha es cuando los proveedores no se pagan, se rompe el cierre de fin de mes, y al personal se le paga tarde, y cada uno de estos en un organismo de salud pública no es un comienzo difícil sino un fallo que destruye la confianza y potencialmente hace noticia. La tensión a debatir es la presión constante de acortar la ejecución paralela, adelgazar el equipo de hiperatención, y comprimir el cronograma para cumplir una fecha impuesta, frente a la realidad de que una fecha deslizada es recuperable mientras una nómina o transición de libro mayor chapucera no lo es. Los ángulos útiles incluyen recorrer cada integración —programación electrónica, ESR, existencias de farmacia, banca, analítica— y preguntar cuáles se han probado de extremo a extremo frente a las que se asumen, y si los propietarios de proceso en finanzas, contratación, y RR. HH. realmente han sido asignados para rediseñar sus flujos de trabajo. Una respuesta honesta muestra recursos nombrados de gestión de cambio, formación, y conciliación en el plan en lugar de una línea que dice "TI se encargará", y está dispuesta a escalonar la puesta en marcha donde una transición de big bang añada riesgo evitable. También debería reconocer que la preparación, no el calendario, debe gobernar la decisión de proceder.

4. En la cuestión de servicios compartidos y ERP en la nube, ¿hemos sopesado la estandarización que ganaríamos frente a la flexibilidad local que cederíamos —y hecho esa llamada deliberadamente en lugar de por defecto? Las plataformas compartidas como NHS SBS e instancias de consorcio de Oracle Cloud, y el ERP en la nube más ampliamente, ofrecen premios reales —economías de escala, actualizaciones continuas, una carga local de implementación y apoyo más ligera— pero los compran con una pérdida genuina de control local y una dependencia dura de la hoja de ruta y ritmo de lanzamiento del proveedor. Esta pregunta obliga al equipo a nombrar qué flexibilidad realmente les importa y probar si vale la pena el coste de operar, parchear, y apoyar separadamente su propia oficina trasera. La tensión en un entorno de salud y atención se agudiza por el hecho de que la mayoría del proceso de oficina trasera es una mercancía, así que la ganancia de estandarización generalmente supera la flexibilidad perdida —pero "generalmente" no es "siempre", y derivar hacia una plataforma compartida sin examinar la disyuntiva es cómo las organizaciones terminan resintiendo una plantilla que nunca eligieron conscientemente. Los ángulos concretos incluyen preguntar qué procesos locales el equipo lucharía por mantener y por qué, qué pasa cuando el consorcio cambia la plantilla debajo de ellos, y si los términos de salida y portabilidad de datos se entienden antes de firmar. Una respuesta sólida trata esto como una elección estratégica hecha con los ojos abiertos, sopesando la dependencia del proveedor y el riesgo de hoja de ruta contra la escala y el alivio de actualización, en lugar de por defecto ir a la opción compartida porque está de moda o aferrarse a una plataforma a medida por hábito.

5. ¿Cuál es nuestro plan honesto para detener que las hojas de cálculo en la sombra y las soluciones alternativas locales reemerjan después de la puesta en marcha, para que el ERP siga siendo el único sistema de registro en lugar de una fuente entre muchas? Todo el punto de un ERP integrado es eliminar la fragmentación que crean los sistemas en la sombra, sin embargo las hojas de cálculo locales tienen una forma de sobrevivir a una puesta en marcha y silenciosamente refragmentar los datos que el programa pretendía unificar. Esta pregunta prueba si el equipo ha pensado más allá de la transición hacia la disciplina operativa duradera que mantiene los centros de coste, presupuestos, aprobaciones de contratación, y establecimiento de fuerza laboral viviendo en el ERP en lugar de en el libro de trabajo privado de alguien. Importa en la salud y la atención porque una hoja de cálculo de establecimiento en la sombra que no concuerda con la nómina, o un rastreador de contratación fuera del sistema, silenciosamente pudre la calidad de datos de la que depende el reporte a la junta directiva y la auditoría, y lo hace precisamente porque es conveniente para la persona que lo mantiene. La tensión que vale la pena sacar a la luz es que los sistemas en la sombra generalmente existen por una razón —el proceso ERP se sintió más lento, o una brecha genuina nunca se cerró— así que simplemente prohibirlos falla a menos que se aborde la necesidad subyacente. Los ángulos útiles incluyen preguntar qué hojas de cálculo actuales tendrían que morir en la puesta en marcha, por qué existe cada una, y qué capacidad en el sistema o cambio de proceso eliminaría la tentación de reconstruirla. Una respuesta honesta empareja una expectativa clara de que el ERP es autoritativo con un plan para corregir las brechas que llevan a la gente fuera del sistema, y nombra quién notará y desafiará un sistema en la sombra cuando reaparezca.

6. ¿Estamos siendo genuinamente honestos sobre el riesgo del programa ERP —el historial del sector de exceso y de no entregar— y hemos construido nuestro cronograma, contingencia, y enfoque de puesta en marcha alrededor de esa realidad en lugar de un plan optimista? Las grandes implementaciones de ERP tienen una reputación bien ganada y transversal a los sectores de exceder el tiempo y coste y de no entregar el beneficio, y esta pregunta pregunta si el equipo ha internalizado esa literatura de fallo o silenciosamente asume que será la excepción. Lo que está en juego en un organismo de salud pública no perdona: una fecha deslizada es recuperable, pero una nómina o transición de libro mayor chapucera es un evento que hace noticia y destruye la confianza con consecuencias parlamentarias y de prensa, así que el optimismo que anula la preparación no es coraje sino imprudencia. La tensión a debatir es la presión constante —de fechas impuestas, coste hundido, y el deseo de mostrar progreso— para comprimir el cronograma, adelgazar la contingencia, y preferir una puesta en marcha de big bang sobre una escalonada que sería más segura pero más lenta. Los ángulos concretos incluyen preguntar qué asume el plan que saldrá bien, dónde realmente reside la contingencia, si una transición escalonada es factible, y cuáles son los criterios explícitos para retrasar la puesta en marcha si la preparación no está ahí. Una buena respuesta nombra los riesgos específicos que lleva este programa en lugar de gesticular hacia el riesgo de ERP en general, incorpora contingencia real y una decisión de escalonamiento defendible, y trata un "todavía no" basado en datos como un resultado legítimo y esperado en lugar de un fallo de nervio.

En la práctica: un ejemplo de salud y atención#

Un fideicomiso agudo del NHS está operando un sistema de finanzas y contratación local de quince años de antigüedad que su proveedor pronto dejará de soportar. El reporte toma días, la compra a pago es fuertemente manual, y el establecimiento de fuerza laboral vive en una maraña de hojas de cálculo que nunca concuerda del todo con la nómina. El fideicomiso decide pasar a un ERP en la nube entregado a través de la instancia con plantilla de Oracle Cloud de un consorcio regional del NHS, junto a proveedores vecinos.

El director de finanzas resiste la tentación de tratar esto como un intercambio de TI. Se establece un programa con un patrocinador ejecutivo, un gerente de programa a tiempo completo, y —crucialmente— un flujo de trabajo de calidad de datos que pasa meses limpiando el plan de cuentas, desduplicando doce mil registros de proveedores, y conciliando el maestro de empleados contra ESR (el registro electrónico de personal del NHS) antes de cualquier migración. Los propietarios de proceso en finanzas, contratación, y RR. HH. son asignados para rediseñar sus flujos de trabajo según la plantilla del consorcio en lugar de replicar el sistema antiguo.

El fideicomiso elige una puesta en marcha escalonada: finanzas y contratación primero, fuerza laboral y reporte en una ola posterior, con ejecución paralela a través de dos cierres de fin de mes y un equipo de hiperatención bien dotado de personal en espera. Las integraciones con la programación electrónica, el banco, y el almacén de analítica se mapean y prueban de extremo a extremo. La puesta en marcha no está exenta de dolor —un atraso de pago a proveedores se acumula en la primera semana y toma quince días en despejarse— pero porque la conciliación y la hiperatención se dotaron de recursos apropiadamente, a ningún personal se le paga tarde y el fin de mes cierra a tiempo.

Un año después, el fideicomiso cierra sus libros en días en lugar de semanas, las aprobaciones de contratación se hacen cumplir en el sistema, y el establecimiento finalmente concilia con la nómina. La plataforma de consorcio compartida también significa que la siguiente actualización llega como una versión de nube rutinaria en lugar de otro proyecto de varios años.

Perspectivas sectoriales#

Startup#

Una startup de salud digital raramente opera un ERP completo; une herramientas SaaS en la nube —un paquete de contabilidad ligero, una aplicación de RR. HH. y nómina, un par de hojas de cálculo— porque una suite integrada pesada es desproporcionada para un equipo de treinta personas. La disciplina de sistema de registro todavía importa, sin embargo: incluso en la etapa semilla, un plan de cuentas limpio y una fuente de nómina autoritativa única previenen el caos de conciliación que asusta a los inversores durante la diligencia debida. El movimiento correcto es mantener la pila simple, integrable, y bien gobernada, y aplazar un ERP "real" hasta que la escala genuinamente lo exija. El riesgo de la startup es la imagen especular del de la gran organización —no la sobrepersonalización, sino la dispersión: una docena de aplicaciones desconectadas sin propietario de datos maestros y sin nadie responsable de los números.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, una agencia de atención domiciliaria, o una clínica de un solo emplazamiento— lleva todo el peso de los deberes financieros, de nómina, y de contratación con casi ninguna capacidad dedicada de finanzas o TI, así que un ERP pesado está fuera de alcance pero la disciplina de sistema de registro no es opcional. La respuesta práctica es un conjunto pequeño y bien integrado de paquetes en la nube —contabilidad, nómina, y existencias— elegidos para que un plan de cuentas y una fuente de nómina autoritativa se mantengan, porque una residencia de cuidados que paga tarde al personal o una farmacia cuyas existencias y libro mayor no concuerdan enfrenta las mismas consecuencias regulatorias y de efectivo que un gran fideicomiso pero sin un equipo de oficina trasera para absorberlas. La tentación de operar el negocio en la hoja de cálculo de un fundador es más fuerte aquí y más peligrosa, ya que rara vez hay alguien que note cuando los números derivan. Donde un organismo profesional, franquicia, o red local ofrece una plataforma de finanzas compartida o estandarizada, adoptarla generalmente es el movimiento astuto: compra la estandarización y apoyo que la organización no puede dotar de recursos por sí misma. La disciplina es mantener la pila simple y gobernada por quien posee el dinero, y resistir las soluciones alternativas a medida que solo esa persona entiende.

Gran organización#

Un gran fideicomiso o empresa de tecnología de salud opera un ERP integrado completo como un sistema de registro de misión crítica, y reemplazarlo es uno de los programas de mayor riesgo que jamás intentará. La tentación de la gran organización es la personalización pesada para preservar procesos heredados familiares; la disciplina es adoptar la plantilla estándar, dotar de recursos a un serio flujo de trabajo de calidad de datos, y ejecutar la puesta en marcha con ejecución paralela y un período de hiperatención bien dotado de personal. Las integraciones se multiplican —programación electrónica, ESR, existencias de farmacia, banca, analítica— y cada una es un fallo que destruye la confianza si silenciosamente rompe la nómina o conciliación de fin de mes. Porque la mayor parte del dolor son las personas y el proceso en lugar de la tecnología, la gestión del cambio (véase el Tema 8.1 — Gestión del cambio) es donde se gana o se pierde el programa de la gran organización. La responsabilidad ante una junta directiva y auditores hace de una transición chapucera de libro mayor o nómina un incidente de gobernanza, no solo un contratiempo de TI.

Gobierno#

A escala nacional y de servicio compartido, ERP es un instrumento de estandarización: NHS Shared Business Services y las instancias de consorcio de Oracle Cloud existen para dar a muchas organizaciones una plataforma con plantilla, intercambiando flexibilidad local por economías de escala y actualizaciones continuas. La responsabilidad gubernamental añade escrutinio de contratación pública (marcos competitivos, aseguramiento de valor por dinero) a cada decisión importante de ERP, y un fallo de transición nacional tiene consecuencias parlamentarias y de prensa. La influencia real del centro es convocar —exigir o incentivar plataformas compartidas para que decenas de fideicomisos y autoridades locales no cada uno opere, parchee, y falle separadamente su propia oficina trasera. La tensión definitoria es entre la estandarización nacional y la autonomía local: empuja la plantilla demasiado fuerte y la adopción se estanca en resentimiento; demasiado suave y la fragmentación que ERP existe para eliminar persiste silenciosamente.

Modos de fallo comunes#

• Datos maestros sucios migrados al por mayor. Los duplicados e inconsistencias antiguos se llevan al nuevo sistema, corrompiendo el reporte desde el primer día. Corrección: limpia y gobierna los datos maestros antes de la migración, y posélos después.
• Personalizar para replicar el sistema antiguo. Los cambios a medida hechos para evitar el cambio de proceso inflan el coste y destruyen la capacidad de actualización. Corrección: adopta la plantilla estándar; cambia el proceso, no el software.
• ERP operado como un proyecto de TI. Tratarlo como un intercambio tecnológico hambrea el esfuerzo de cambio, formación, y rediseño de proceso. Corrección: opéralo como un programa de cambio de negocio con gestión del cambio real (Tema 8.1).
• Puesta en marcha de big bang optimista. Los cronogramas comprimidos y una sola transición convierten problemas ordinarios en crisis públicas. Corrección: escalona donde sea factible, y nunca cambies la preparación por una fecha.
• Integraciones rotas. Un feed de programación a nómina o contratación a libro mayor no probado paga mal a la gente o rompe la conciliación. Corrección: mapea, posee, y prueba de extremo a extremo cada interfaz.
• Las hojas de cálculo en la sombra sobreviven. Las soluciones alternativas locales persisten junto al ERP, refragmentando los datos. Corrección: haz del ERP el único sistema de registro y retira las sombras.

Modelo de madurez#

Lista de verificación#

• El plan de cuentas, proveedores, artículos, y datos maestros de empleados se limpian y desduplican antes de la migración.
• La propiedad y gobernanza continua de datos maestros están asignadas y financiadas.
• La implementación está delimitada y dotada de recursos como un programa de cambio de negocio, no un proyecto de TI.
• La personalización se minimiza; se adopta la plantilla estándar del proveedor o consorcio para procesos de mercancía.
• Cada integración (programación, nómina/ESR, clínica/farmacia, banca, analítica) está mapeada, poseída, y probada de extremo a extremo.
• El enfoque de puesta en marcha (escalonado frente a big bang) se elige según la preparación, no una fecha impuesta.
• La transición de datos, ejecución paralela, conciliación, y un período de hiperatención están planificados y dotados de personal.
• La gestión del cambio, formación, y rediseño de proceso están explícitamente dotados de recursos (véase el Tema 8.1).
• Las opciones de servicios compartidos y ERP en la nube se evalúan según sus disyuntivas reales de estandarización frente a flexibilidad.
• El ERP se establece como el único sistema de registro, y las hojas de cálculo en la sombra se retiran.

Fuentes clave#

• NHS Shared Business Services (NHS SBS) — el servicio compartido nacional de finanzas y contratación basado en Oracle para organizaciones del NHS. https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — escala de la plataforma de finanzas nacional del NHS. https://www.oracle.com/uk/
• NHS North of England Commissioning / consorcio NEP — ERP Oracle Cloud con plantilla para miembros del NHS. https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — ERP para fideicomisos del NHS, autoridades locales, y universidades. https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — procesos de finanzas que sustenta ERP. https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — el sistema de fuerza laboral y nómina del NHS con el que ERP debe integrarse. https://www.electronicstaffrecord.nhs.uk/
• Véase también el Tema 5.2 — Gestión de programas, el Tema 5.3 — Gestión de cartera de proyectos empresariales, y el Tema 8.1 — Gestión del cambio.

Referencias#

1. Enterprise resource planning — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_resource_planning
2. System of record — Wikipedia — https://en.wikipedia.org/wiki/System_of_record
3. Master data management — Wikipedia — https://en.wikipedia.org/wiki/Master_data_management
4. Chart of accounts — Wikipedia — https://en.wikipedia.org/wiki/Chart_of_accounts
5. Payroll — Wikipedia — https://en.wikipedia.org/wiki/Payroll
6. Procure-to-pay — Wikipedia — https://en.wikipedia.org/wiki/Procure-to-pay
7. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
8. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Change management — Wikipedia — https://en.wikipedia.org/wiki/Change_management
11. Business process re-engineering — Wikipedia — https://en.wikipedia.org/wiki/Business_process_re-engineering
12. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
13. NHS Shared Business Services — Wikipedia — https://en.wikipedia.org/wiki/NHS_Shared_Business_Services
14. NHS Shared Business Services — the national Oracle-based finance and procurement shared service for NHS organisations — https://www.sbs.nhs.uk/
15. NHS Shared Business Services with Oracle Fusion Cloud Applications — Oracle — https://www.oracle.com/uk/
16. Public sector and healthcare ERP — Unit4 — https://www.unit4.com/industries/public-sector-software
17. Introductory Guide to NHS Finance — HFMA — https://www.hfma.org.uk/
18. NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with — https://www.electronicstaffrecord.nhs.uk/