Tópico 5.4 — Planejamento de recursos empresariais (ERP)

Em uma frase: O planejamento de recursos empresariais é o sistema integrado de retaguarda — finanças, recursos humanos, folha de pagamento, aquisições e cadeia de suprimentos — que atua como sistema de registro da organização para dinheiro, pessoas e estoque e sustenta em silêncio quase todos os modos de trabalho deste livro.

Por que isso importa na saúde e nos cuidados#

A transformação digital na saúde e nos cuidados atrai a atenção para os sistemas clínicos — o prontuário eletrônico do paciente, o prontuário de cuidados compartilhado, o aplicativo do paciente. Mas nenhum deles funciona sem a retaguarda pouco glamorosa que há por baixo. A equipe precisa ser recrutada, escalada e paga; os fornecedores precisam ser contratados e quitados; medicamentos, dispositivos e insumos precisam ser pedidos e rastreados; e cada libra precisa ser contabilizada frente a orçamentos públicos rigidamente limitados. O ERP é onde isso acontece e, quando ele falha, as consequências são imediatas: equipe sem pagamento, aquisições paralisadas, contas sem conciliação e uma função financeira voando às cegas.

A escala é enorme. A NHS Shared Business Services (NHS SBS), uma joint venture criada em 2004, opera uma plataforma nacional de finanças e aquisições baseada em Oracle, que processa milhões de faturas e movimenta uma parcela muito grande do gasto total do NHS para mais de uma centena de organizações do NHS (ver Fontes-chave). As decisões de ERP não são, portanto, uma preocupação financeira de nicho — moldam a gestão da força de trabalho, o controle do dinheiro público e a qualidade de dados de que toda análise a jusante depende. Para um diretor, o ERP é, ao mesmo tempo, um habilitador fundamental e um dos programas de maior risco que uma organização jamais tentará.

Conceitos centrais#

O que é o ERP. Uma suíte única e integrada de planejamento de recursos empresariais, de módulos que compartilham um só banco de dados e um só conjunto de dados mestres, cobrindo os processos administrativos centrais da empresa: razão geral e contabilidade financeira, contas a pagar e a receber, RH e administração da força de trabalho, folha de pagamento, aquisições (comprar-para-pagar), estoque e cadeia de suprimentos e, cada vez mais, planejamento e análises (FP&A — planejamento e análise financeira). O sentido da "integração" é que um pedido de compra, um recebimento de mercadorias e uma fatura se reconciliam automaticamente porque são os mesmos dados, e não três cópias.

Sistema de registro. O ERP é a fonte autoritativa dos dados financeiros e de recursos — o razão em que os auditores confiam e a folha pela qual a equipe é paga. Outros sistemas podem guardar cópias operacionais, mas o ERP é a versão da verdade para o dinheiro e, muitas vezes, para o registro de RH substantivo.

Dados mestres. Os dados de referência compartilhados de que tudo o mais depende: o plano de contas, os centros de custo, os cadastros de fornecedores, o catálogo de itens e os cadastros de empregados. Os dados mestres são o determinante silencioso do sucesso do ERP — dados mestres sujos, duplicados ou inconsistentes corrompem os relatórios, quebram a conciliação e minam todo processo construído sobre eles.

Plataformas comuns na saúde e no setor público. No NHS e no setor público britânico em geral, as principais plataformas de ERP são Oracle (dominante, em grande parte por meio da NHS SBS e de consórcios como o NEP), SAP, Unit4 (amplamente escolhida por hospitais, universidades e autoridades locais) e Microsoft Dynamics 365. As autoridades locais que prestam cuidados sociais para adultos operam a mesma classe de sistemas para suas finanças e aquisições. A direção moderna é o ERP em nuvem (software como serviço) em vez de instalações locais.

Serviços compartilhados. Em vez de cada organização operar o seu próprio ERP, muitas compartilham uma plataforma comum e uma operação de retaguarda comum — o modelo da NHS SBS e os consórcios do NHS que operam instâncias padronizadas de Oracle Cloud. Os serviços compartilhados trocam parte da flexibilidade local por padronização, economias de escala e um fardo coletivo menor de implantação e suporte.

Boas práticas#

1. Trate os dados mestres como alicerce, e não como reflexão tardia. Limpem e eliminem as duplicatas do plano de contas, dos cadastros de fornecedores, do catálogo de itens e dos dados de empregados antes da migração e estabeleçam uma responsabilidade contínua de governança de dados. As falhas de ERP mais danosas remontam a dados mestres ruins que nenhum bom software consegue corrigir; um fluxo de trabalho de qualidade de dados não é opcional.

2. Adote o padrão; minimize a customização. Configurem o ERP no modelo padrão do fornecedor ou do consórcio sempre que o processo for genuinamente comum e reservem a mudança sob medida para o raro verdadeiro diferencial. A customização pesada infla o custo, destrói a capacidade de atualização e reimporta a bagunça local de que vocês queriam escapar — o ERP em nuvem, em particular, pune o instinto de "fazer com que se pareça com o nosso sistema antigo".

3. Projete as integrações deliberadamente. O ERP não existe isolado: precisa trocar dados com sistemas de força de trabalho e de escalas eletrônicas, sistemas clínicos e de farmácia (para estoque e apuração de custos), bancos e análises. Mapeiem cada interface, sejam donos dos contratos de dados e testem de ponta a ponta — uma folha alimentada por um feed de escalas quebrado paga errado às pessoas, e isso é uma falha que destrói a confiança.

4. Conduza a substituição do ERP como um grande programa, com a gestão de mudanças no centro. Uma implantação de ERP é um programa de mudança de negócio que por acaso envolve software, e não um projeto de TI. Dotem-na de recursos com disciplina de programa (ver Tópico 5.2 — Trabalho conduzido por programa) e de um esforço genuíno de gestão de mudanças (ver Tópico 8.1 — Gestão de mudanças), porque a maior parte da dor do ERP é de pessoas e processos, e não de tecnologia.

5. Seja honesto sobre o risco do programa de ERP. As grandes implantações de ERP têm uma reputação merecida de estourar prazo e custo e de entregar menos benefício do que o prometido; a literatura sobre falhas é extensa e intersetorial. Incluam contingência, evitem uma entrada em produção em "big bang" onde uma abordagem faseada for viável e jamais deixem um cronograma otimista se sobrepor à prontidão — uma data adiada é recuperável, uma virada malfeita da folha ou do razão não é.

6. Proteja a entrada em produção e o período depois dela. Planejem em detalhe a virada de dados, a operação em paralelo, a conciliação e o suporte reforçado (hypercare) e resistam à pressão para encurtá-los. As semanas em torno da entrada em produção são quando fornecedores ficam sem pagamento e o fechamento do mês quebra; um período de estabilização bem dotado de pessoal é a diferença entre um começo difícil e uma crise pública.

7. Use o ERP como sistema de registro da gestão de recursos — e projete os modos de trabalho em torno dele. Deixem o ERP ser a fonte única para centros de custo, orçamentos, aprovações de aquisições e quadro de pessoal e alinhem os processos operacionais a ele, em vez de manter planilhas paralelas. Os sistemas paralelos reintroduzem a fragmentação que o ERP existe para remover e apodrecem em silêncio a qualidade dos dados.

8. Pesem os serviços compartilhados e o ERP em nuvem por suas concessões reais. As plataformas compartilhadas (NHS SBS, consórcios no estilo NEP) e o ERP em nuvem oferecem padronização, escala, atualizações contínuas e um fardo local mais leve, ao custo de alguma flexibilidade local e de uma dependência do provedor. Escolham deliberadamente: para a maioria das organizações, o ganho de padronização supera a flexibilidade perdida, mas a decisão deve ser tomada de olhos abertos, e não por omissão.

Perguntas para discutir com a sua equipe#

1. Quão confiantes estamos — com evidências, e não com garantias — quanto à qualidade dos dados mestres que levaríamos a um novo ERP, e quem é dono deles depois da entrada em produção? Os dados mestres são o determinante silencioso do sucesso do ERP, mas são rotineiramente tratados como tarefa de arrumação da migração e não como o alicerce que são; assim, esta pergunta testa se a equipe olhou com rigor para o plano de contas, os cadastros de fornecedores, o catálogo de itens e o cadastro de empregados, ou apenas espera que estejam limpos. Num ambiente de saúde e cuidados, o que está em jogo é concreto: cadastros duplicados de fornecedores quebram a conciliação do comprar-para-pagar, um cadastro de empregados que discorda do ESR paga errado às pessoas e um plano de contas inconsistente corrompe todo relatório financeiro a jusante em que o conselho e os auditores se apoiam. A tensão que vale debater é a atração por migrar tudo de uma vez para cumprir uma data versus os meses de limpeza e eliminação de duplicatas, pouco glamorosos, que a boa prática exige, e se alguém sênior está disposto a financiar um fluxo de qualidade de dados que não mostra produto visível. Uma resposta forte cita contagens reais — quantos fornecedores duplicados, quantos registros de empregados sem conciliação — em vez de uma sensação geral de que "os dados estão mais ou menos bem". Deve também nomear a pessoa e o mecanismo de governança responsáveis pela qualidade dos dados mestres depois da entrada em produção, porque dados limpos uma vez e depois deixados sem governança simplesmente voltam à desordem.

2. Onde somos genuinamente tentados a customizar o ERP para preservar um processo familiar, e essa diferença é um verdadeiro diferencial ou apenas a velha bagunça de que tentamos escapar? A customização pesada é a armadilha clássica do ERP corporativo: infla o custo, destrói a capacidade de atualização e reimporta a própria fragmentação local que o programa deveria remover, e o ERP em nuvem, em particular, pune o instinto de "fazer com que se pareça com o nosso sistema antigo". Esta pergunta pede à equipe que seja específica sobre quais processos insistirá em dobrar o software para encaixar e que justifique cada um frente a um teste duro: é um verdadeiro diferencial ou apenas um hábito confortável? O debate importa porque, na saúde e nos cuidados, quase todo processo de retaguarda — razão geral, aprovações de aquisição, administração da folha — é genuinamente comum, de modo que o padrão honesto deve ser adotar o modelo padrão do fornecedor ou do consórcio e mudar o processo, e não o software. Ângulos concretos incluem listar cada customização solicitada e perguntar quem se beneficia, que custo de atualização ela trava e se um hospital vizinho no mesmo modelo se arranja sem ela. Uma boa resposta distingue a rara exceção legítima dos muitos pedidos movidos por aversão à mudança e reconhece que adotar o padrão é um problema de gestão de mudanças e de liderança, e não técnico. Deve também enfrentar o custo de longo prazo: cada mudança sob medida é um imposto pago a cada futura versão da nuvem.

3. Dotamos honestamente de recursos o lado humano e de processos desta mudança de ERP — virada, operação em paralelo, suporte reforçado, treinamento e testes de integração — ou a estamos conduzindo em silêncio como um projeto de TI? A literatura sobre falhas é inequívoca de que a maior parte da dor do ERP é de pessoas e processos, e não de tecnologia; esta pergunta expõe, portanto, se o programa é genuinamente um esforço de mudança de negócio ou uma troca de TI vestida de programa. O período em torno da entrada em produção é quando fornecedores ficam sem pagamento, o fechamento do mês quebra e a equipe é paga com atraso, e cada um desses eventos, num órgão público de saúde, não é um começo difícil, mas uma falha que destrói a confiança e pode virar notícia. A tensão a debater é a pressão constante para encurtar a operação em paralelo, enxugar a equipe de suporte reforçado e comprimir o cronograma para cumprir uma data imposta, contra a realidade de que uma data adiada é recuperável, enquanto uma virada malfeita da folha ou do razão não é. Ângulos úteis incluem percorrer cada integração — escalas eletrônicas, ESR, estoque da farmácia, banco, análises — e perguntar quais foram testadas de ponta a ponta e quais foram apenas presumidas e se os donos de processo em finanças, aquisições e RH foram de fato cedidos para redesenhar seus fluxos de trabalho. Uma resposta honesta mostra no plano recursos nomeados de gestão de mudanças, treinamento e conciliação, e não uma linha que diz "a TI cuidará disso", e está disposta a faseiar a entrada em produção onde uma virada em big bang acrescenta risco evitável. Deve também reconhecer que a prontidão, e não o calendário, deve governar a decisão de prosseguir.

4. Na questão dos serviços compartilhados e do ERP em nuvem, pesamos a padronização que ganharíamos frente à flexibilidade local que abriríamos mão — e tomamos essa decisão deliberadamente e não por omissão? Plataformas compartilhadas como a NHS SBS e as instâncias Oracle Cloud de consórcio, e o ERP em nuvem de modo mais amplo, oferecem prêmios reais — economias de escala, atualizações contínuas, um fardo local mais leve de implantação e suporte —, mas os compram com uma perda genuína de controle local e uma dependência rígida do roteiro e do ritmo de versões do provedor. Esta pergunta força a equipe a nomear que flexibilidade de fato importa para ela e a testar se vale o custo de operar, atualizar e dar suporte separado à própria retaguarda. A tensão num ambiente de saúde e cuidados é agravada pelo fato de que a maioria dos processos de retaguarda é comum, de modo que o ganho de padronização geralmente supera a flexibilidade perdida — mas "geralmente" não é "sempre", e deslizar para uma plataforma compartilhada sem examinar a concessão é como as organizações acabam ressentidas com um modelo que nunca escolheram conscientemente. Ângulos concretos incluem perguntar que processos locais a equipe lutaria para manter e por quê, o que acontece quando o consórcio muda o modelo por baixo deles e se os termos de saída e de portabilidade de dados são compreendidos antes de assinar. Uma resposta forte trata isto como uma escolha estratégica tomada de olhos abertos, pesando a dependência do provedor e o risco do roteiro frente à escala e ao alívio das atualizações, em vez de adotar a opção compartilhada por omissão porque está na moda ou de se agarrar a uma plataforma sob medida por hábito.

5. Qual é o nosso plano honesto para impedir que planilhas paralelas e gambiarras locais ressurjam depois da entrada em produção, para que o ERP continue sendo o único sistema de registro e não uma fonte entre muitas? O sentido de um ERP integrado é remover a fragmentação que os sistemas paralelos criam, mas as planilhas locais têm um jeito de sobreviver a uma entrada em produção e re-fragmentar em silêncio os dados que o programa deveria unificar. Esta pergunta testa se a equipe pensou além da virada, na disciplina operacional duradoura que mantém centros de custo, orçamentos, aprovações de aquisição e quadro de pessoal vivendo no ERP e não na pasta de trabalho privada de alguém. Importa na saúde e nos cuidados porque uma planilha paralela de quadro de pessoal que discorda da folha, ou um controle de aquisições fora do sistema, apodrece em silêncio a qualidade dos dados de que os relatórios do conselho e a auditoria dependem, e o faz precisamente porque é conveniente para quem a mantém. A tensão que vale trazer à tona é que os sistemas paralelos normalmente existem por uma razão — o processo do ERP pareceu mais lento ou uma lacuna genuína nunca foi fechada —, de modo que simplesmente proibi-los falha se a necessidade subjacente não for atendida. Ângulos úteis incluem perguntar quais planilhas atuais teriam de morrer na entrada em produção, por que cada uma existe e que capacidade no sistema ou mudança de processo removeria a tentação de reconstruí-la. Uma resposta honesta combina a expectativa clara de que o ERP é autoritativo com um plano para corrigir as lacunas que levam as pessoas para fora do sistema e nomeia quem notará e contestará um sistema paralelo quando ele reaparecer.

6. Estamos sendo genuinamente honestos sobre o risco do programa de ERP — o histórico do setor de estouros e de entrega abaixo do prometido — e construímos o nosso cronograma, a contingência e a abordagem de entrada em produção em torno dessa realidade, e não de um plano otimista? As grandes implantações de ERP têm uma reputação merecida e intersetorial de estourar prazo e custo e de entregar menos benefício do que o prometido, e esta pergunta indaga se a equipe internalizou essa literatura de falhas ou está supondo em silêncio que será a exceção. O que está em jogo num órgão público de saúde é implacável: uma data adiada é recuperável, mas uma virada malfeita da folha ou do razão é um evento noticiável e destruidor de confiança, com consequências parlamentares e na imprensa; assim, o otimismo que se sobrepõe à prontidão não é coragem, mas imprudência. A tensão a debater é a pressão constante — de datas impostas, do custo afundado e do desejo de mostrar progresso — para comprimir o cronograma, enxugar a contingência e preferir uma entrada em produção em big bang a uma faseada, que seria mais segura, porém mais lenta. Ângulos concretos incluem perguntar o que o plano supõe que dará certo, onde a contingência de fato está, se uma virada faseada é viável e quais são os critérios explícitos para adiar a entrada em produção se a prontidão não estiver lá. Uma boa resposta nomeia os riscos específicos que este programa carrega, em vez de gesticular sobre o risco do ERP em geral, incorpora contingência real e uma decisão defensável de faseamento e trata um "ainda não" baseado em dados como um resultado legítimo e esperado, e não como falta de coragem.

Na prática: um exemplo de saúde e cuidados#

Um hospital de agudos do NHS opera um sistema local de finanças e aquisições de quinze anos, que o fornecedor logo deixará de suportar. Os relatórios levam dias, o comprar-para-pagar é pesadamente manual e o quadro de pessoal vive num emaranhado de planilhas que nunca chega a concordar com a folha. O hospital decide migrar para um ERP em nuvem entregue por meio da instância padronizada de Oracle Cloud de um consórcio regional do NHS, ao lado de prestadores vizinhos.

O diretor financeiro resiste à tentação de tratar isso como uma troca de TI. Monta-se um programa com um patrocinador executivo, um gerente de programa em tempo integral e — de forma decisiva — um fluxo de trabalho de qualidade de dados que passa meses limpando o plano de contas, eliminando as duplicatas de doze mil cadastros de fornecedores e conciliando o cadastro de empregados com o ESR (o prontuário eletrônico de pessoal do NHS) antes de qualquer migração. Os donos de processo em finanças, aquisições e RH são cedidos para redesenhar seus fluxos de trabalho conforme o modelo do consórcio, em vez de replicar o sistema antigo.

O hospital escolhe uma entrada em produção faseada: finanças e aquisições primeiro, força de trabalho e relatórios numa onda posterior, com operação em paralelo por dois fechamentos de mês e uma equipe de suporte reforçado bem dotada de pessoal de prontidão. As integrações com as escalas eletrônicas, o banco e o data warehouse de análises são mapeadas e testadas de ponta a ponta. A entrada em produção não é indolor — um acúmulo de pagamentos a fornecedores se forma na primeira semana e leva uma quinzena para ser liquidado —, mas, como a conciliação e o suporte reforçado foram devidamente dotados de recursos, nenhum funcionário é pago com atraso e o fechamento do mês ocorre no prazo.

Um ano depois, o hospital fecha seus livros em dias e não em semanas, as aprovações de aquisição são impostas no sistema e o quadro de pessoal finalmente concilia com a folha. A plataforma compartilhada do consórcio também significa que a próxima atualização chega como uma versão rotineira da nuvem, e não como outro projeto de vários anos.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital raramente opera um ERP completo; costura ferramentas SaaS em nuvem — um pacote contábil leve, um aplicativo de RH e folha, algumas planilhas —, porque uma suíte integrada pesada é desproporcional a uma equipe de trinta pessoas. A disciplina do sistema de registro ainda importa, porém: mesmo na fase semente, um plano de contas limpo e uma fonte autoritativa única de folha evitam o caos de conciliação que assusta os investidores na auditoria prévia (due diligence). O movimento certo é manter a pilha simples, integrável e bem governada e adiar um ERP "de verdade" até que a escala o exija. O risco da startup é a imagem espelhada do da grande organização — não a customização excessiva, mas a proliferação: uma dúzia de aplicativos desconectados, sem dono de dados mestres e sem ninguém responsável pelos números.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso, uma agência de cuidados domiciliares ou uma clínica de unidade única — carrega todo o peso dos deveres financeiros, de folha e de aquisições com quase nenhuma capacidade dedicada de finanças ou de TI; assim, um ERP pesado está fora de alcance, mas a disciplina do sistema de registro não é opcional. A resposta prática é um conjunto pequeno e bem integrado de pacotes em nuvem — contabilidade, folha e estoque —, escolhidos de modo que um plano de contas e uma fonte autoritativa de folha se sustentem, porque uma casa de repouso que paga a equipe com atraso ou uma farmácia cujo estoque e razão discordam enfrentam as mesmas consequências regulatórias e de caixa que um grande hospital, mas sem equipe de retaguarda para absorvê-las. A tentação de tocar o negócio na planilha do fundador é mais forte aqui e a mais perigosa, já que raramente há alguém para notar quando os números derivam. Onde uma entidade profissional, franquia ou rede local oferece uma plataforma financeira compartilhada ou padronizada, adotá-la costuma ser o movimento astuto: compra a padronização e o suporte que a organização não consegue prover sozinha. A disciplina é manter a pilha simples e governada por quem é dono do dinheiro e resistir a gambiarras sob medida que só aquela pessoa entende.

Grande organização#

Um grande hospital ou empresa de tecnologia em saúde opera um ERP integrado completo como sistema de registro crítico para a missão, e substituí-lo é um dos programas de maior risco que jamais tentará. A tentação da grande organização é a customização pesada para preservar processos legados familiares; a disciplina é adotar o modelo padrão, dotar de recursos um fluxo sério de qualidade de dados e conduzir a entrada em produção com operação em paralelo e um período de suporte reforçado bem dotado de pessoal. As integrações se multiplicam — escalas eletrônicas, ESR, estoque da farmácia, banco, análises — e cada uma é uma falha destruidora de confiança se quebrar em silêncio a folha ou a conciliação do fechamento do mês. Como a maior parte da dor é de pessoas e processos, e não de tecnologia, a gestão de mudanças (ver Tópico 8.1 — Gestão de mudanças) é onde o programa da grande organização é ganho ou perdido. A responsabilização perante um conselho e auditores faz de uma virada malfeita do razão ou da folha um incidente de governança, e não apenas um revés de TI.

Governo#

Em escala nacional e de serviços compartilhados, o ERP é um instrumento de padronização: a NHS Shared Business Services e as instâncias Oracle Cloud de consórcio existem para dar a muitas organizações uma plataforma única e padronizada, trocando flexibilidade local por economias de escala e atualizações contínuas. A responsabilização governamental acrescenta o escrutínio das contratações públicas (estruturas competitivas, garantia de custo-benefício) a toda grande decisão de ERP, e uma falha nacional de virada tem consequências parlamentares e na imprensa. A alavancagem real do centro é a convocação — tornar obrigatórias ou incentivar plataformas compartilhadas para que dezenas de hospitais e autoridades locais não operem, atualizem e falhem, cada um, separadamente, a própria retaguarda. A tensão definidora está entre a padronização nacional e a autonomia local: empurrar demais o modelo faz a adesão emperrar em ressentimento; de menos, a fragmentação que o ERP existe para remover persiste em silêncio.

Modos de falha comuns#

• Dados mestres sujos migrados em bloco. Velhas duplicatas e inconsistências são levadas ao novo sistema, corrompendo os relatórios desde o primeiro dia. Correção: limpem e governem os dados mestres antes da migração e sejam donos deles depois.
• Customizar para replicar o sistema antigo. Mudanças sob medida feitas para evitar a mudança de processo inflam o custo e destroem a capacidade de atualização. Correção: adotem o modelo padrão; mudem o processo, e não o software.
• ERP conduzido como projeto de TI. Tratá-lo como troca de tecnologia sufoca o esforço de mudança, treinamento e redesenho de processos. Correção: conduzam-no como programa de mudança de negócio, com gestão de mudanças real (Tópico 8.1).
• Entrada em produção em big bang otimista. Cronogramas comprimidos e uma única virada transformam problemas comuns em crises públicas. Correção: faseiem onde viável e jamais troquem prontidão por uma data.
• Integrações quebradas. Um feed não testado de escalas para folha ou de aquisições para razão paga errado às pessoas ou quebra a conciliação. Correção: mapeiem, sejam donos e testem de ponta a ponta cada interface.
• Planilhas paralelas sobrevivem. Gambiarras locais persistem ao lado do ERP, re-fragmentando os dados. Correção: façam do ERP o único sistema de registro e aposentem as paralelas.

Modelo de maturidade#

Lista de verificação#

• Os dados mestres do plano de contas, dos fornecedores, dos itens e dos empregados são limpos e livres de duplicatas antes da migração.
• A propriedade e a governança contínuas dos dados mestres estão atribuídas e financiadas.
• A implantação é delimitada e dotada de recursos como programa de mudança de negócio, e não como projeto de TI.
• A customização é minimizada; o modelo padrão do fornecedor ou do consórcio é adotado para os processos comuns.
• Toda integração (escalas, folha/ESR, clínico/farmácia, banco, análises) é mapeada, tem dono e é testada de ponta a ponta.
• A abordagem de entrada em produção (faseada versus big bang) é escolhida pela prontidão, e não por uma data imposta.
• A virada de dados, a operação em paralelo, a conciliação e um período de suporte reforçado são planejados e dotados de pessoal.
• A gestão de mudanças, o treinamento e o redesenho de processos têm recursos explícitos (ver Tópico 8.1).
• As opções de serviços compartilhados e de ERP em nuvem são avaliadas por suas concessões reais entre padronização e flexibilidade.
• O ERP é estabelecido como único sistema de registro, e as planilhas paralelas são aposentadas.

Fontes-chave#

• NHS Shared Business Services (NHS SBS) — o serviço compartilhado nacional de finanças e aquisições, baseado em Oracle, para organizações do NHS. https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — escala da plataforma financeira nacional do NHS. https://www.oracle.com/uk/
• NHS North of England Commissioning / consórcio NEP — ERP Oracle Cloud padronizado para membros do NHS. https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — ERP para hospitais do NHS, autoridades locais e universidades. https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — processos financeiros que o ERP sustenta. https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — o sistema de força de trabalho e folha do NHS com o qual o ERP precisa se integrar. https://www.electronicstaffrecord.nhs.uk/
• Ver também Tópico 5.2 — Trabalho conduzido por programa, Tópico 5.3 — Gestão de portfólio corporativo de projetos (EPPM) e Tópico 8.1 — Gestão de mudanças.

Referências#

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/