Reconstruir depois do HPCM: stack mais pequeno, respostas mais afiadas.
Em resumo. O Oracle Hyperion Profitability and Cost Management pertence à geração Hyperion on-premises, e os seus utilizadores enfrentam uma transição para as ofertas cloud da Oracle. Essa encruzilhada é um momento justo para fazer uma pergunta maior: reimplementar um motor de alocações, ou passar para um modelo baseado no tempo que custeia as atividades diretamente. Esta página mapeia a segunda opção.
Uma nota sobre o tom: o Oracle HPCM é software capaz e esta página não vai fingir o contrário. O que se segue são factos publicamente conhecidos sobre o ciclo de vida do produto, enunciados com neutralidade, e uma descrição honesta de uma alternativa.
Porque estão os utilizadores do HPCM a reavaliar agora?
Porque a decisão de plataforma lhes foi tirada das mãos, e a decisão de modelação não.
O HPCM faz parte da família Hyperion on-premises. A direção estratégica da Oracle para esta área de produto é o seu portefólio de EPM na cloud, e as organizações que correm o HPCM on-premises enfrentam um projeto de migração de alguma forma: para a oferta de rentabilidade na cloud da Oracle ou para outro lado. CONFIRM: redação precisa e atual do ciclo de vida da Oracle, verificada à data de publicação
Uma migração forçada é disruptiva. É também o momento mais barato que alguma vez terá para reconsiderar o próprio modelo, porque o custo de reimplementação tem de ser pago de qualquer maneira.
A pergunta não é "que fornecedor recebe a licença". É "o modelo novo deve funcionar da mesma maneira que o antigo".
O que fez bem o HPCM, e o que deixou em aberto?
O HPCM é, no fundo, um motor de alocações poderoso: os saldos do razão fluem por regras de alocação em estágios até aos objetos de custo. Para alocação regulatória, débito de serviços partilhados e razão de gestão, essa arquitetura serviu bem.
O que as arquiteturas de alocação deixam em aberto é a causalidade ao nível da transação. As regras distribuem custo em percentagens; não medem o que uma encomenda, uma expedição ou um episódio de paciente realmente consumiu. Quando a pergunta passa de "como repartimos o custo de TI" para "que clientes nos fazem perder dinheiro", a alocação por regras fica sem resolução.
Essa segunda pergunta é aquela para que o custeio baseado em atividades e no tempo foi construído.
Como é um stack TDABC moderno?
Quatro camadas, todas mais leves do que a geração anterior.
Dados de entrada
Extrações que os seus sistemas já produzem: saldos do razão, salários, registos transacionais. Um dos nossos modelos atuais corre sobre um conjunto de 525,000 linhas de expedição atualizado a partir do sistema operacional do cliente. Sem projeto de data warehouse.
Um modelo de capacidade
Recursos agrupados em pools de custos, cada um com uma taxa de custo da capacidade: custo da capacidade disponibilizada a dividir pela capacidade prática. Isto substitui a alocação em múltiplos estágios por uma única afirmação económica explicável por pool de recursos.
Equações de tempo
O custo de cada transação é uma fórmula das suas características: minutos em função das linhas da encomenda, das paragens de entrega, do tipo de manuseamento, da complexidade. Uma mão-cheia de equações custeia milhões de transações, e é por isso que a manutenção não incha como as bibliotecas de regras incham.
Superfícies de decisão
Curvas da baleia, custo de servir por cliente e por produto, utilização da capacidade, cenários. No nosso stack, esta camada é o CostCtrl, e é a equipa financeira do cliente, não uma consultora, que a opera.
MOTOR DE ALOCAÇÕES VS MODELO BASEADO NO TEMPO
Como decorre a migração?
Quatro passos, deliberadamente aborrecidos.
Inventariar as decisões, não as regras
Listar que outputs do HPCM são realmente usados, por quem, para que decisões. A maioria dos modelos legados carrega regras que ninguém lê há anos; o inventário de decisões é sempre mais curto do que o inventário de regras.
Reconstruir a economia como capacidade e tempo
Mapear pools de custos, fixar capacidades práticas, esboçar equações de tempo para as transações que importam. Isto é trabalho de modelação, medido em semanas. CONFIRM: intervalo típico de duração assumido publicamente
Correr em paralelo um período
Os mesmos dados de origem pelos dois modelos, o antigo e o novo. As diferenças são examinadas, explicadas e documentadas. Este passo converte ceticismo em aprovação, e é onde os pressupostos escondidos do modelo antigo vêm à superfície.
Fazer o corte e entregar
O modelo passa para a equipa do cliente com o processo de atualização documentado. Quaisquer outputs de alocação regulatória que a organização tenha de continuar a produzir são reconciliados a partir dos resultados do novo modelo.
MIGRAÇÃO EM QUATRO PASSOS
Como se comparam as abordagens?
| Suite de alocação legada (geração HPCM) | Stack TDABC moderno (CostCtrl) | |
|---|---|---|
| Abordagem de modelação | Regras de alocação em estágios sobre saldos do razão | Taxas de custo da capacidade e equações de tempo sobre transações |
| Equações de tempo | Não nativas; lógica temporal aproximada por drivers | Nativas; mecanismo central de custeio |
| Volume de dados | Tabelas agregadas de razão e de drivers | Nível de transação; modelos correm sobre centenas de milhares de linhas |
| Tempo de implementação | Projeto de EPM empresarial, tipicamente trimestres | Primeiro modelo funcional em semanas CONFIRM: intervalo assumido |
| Modelo de preço | Licença empresarial e infraestrutura ou subscrição cloud (conforme os termos do fornecedor) | Subscrição mais construção especializada; a equipa do cliente opera o modelo CONFIRM: redação comercial atual |
Perguntas justas.
- A Oracle vai descontinuar o HPCM?
- A direção da Oracle para esta família de produtos é o seu portefólio de EPM na cloud; os clientes Hyperion on-premises enfrentam decisões de ciclo de vida e de suporte conforme as políticas publicadas pela Oracle. Verifique o estado atual diretamente com a Oracle. CONFIRM: frase de resumo do ciclo de vida verificada à data de publicação O nosso argumento não depende de nenhum prazo: a reimplementação é necessária de qualquer forma, logo a questão da modelação está aberta de qualquer forma.
- Um modelo TDABC consegue reproduzir as nossas alocações regulatórias?
- Normalmente, os outputs exigidos podem ser reconciliados a partir de um modelo TDABC, e a corrida paralela do passo 3 prova-o caso a caso. Onde um regulador exige uma forma de alocação específica, o modelo produ-la como relatório e não como lógica central.
- Temos anos de regras do HPCM. Está tudo perdido?
- Não. As regras codificam conhecimento institucional sobre relações de custo. O inventário de decisões do passo 1 colhe esse conhecimento; o que se reforma é a maquinaria, não o entendimento.
- Quem opera o novo modelo depois do corte?
- A sua equipa financeira, no CostCtrl. Esse é o objetivo de desenho, não uma reflexão tardia: todos os projetos terminam com a entrega, e os estudos de caso neste site descrevem clientes a operar os seus modelos anos depois.
- E se escolhermos a opção cloud da Oracle?
- Então escolha-a com um inventário de decisões na mão e olhos limpos sobre o que a alocação por regras consegue e não consegue responder. Se o custo de servir e a rentabilidade por cliente estão na agenda do seu conselho, teste qualquer candidato contra essas perguntas antes de se comprometer.
Perante a decisão do HPCM?
Uma chamada de 30 minutos com um sócio sénior: mapeamos o inventário de decisões do seu modelo atual e dizemos com honestidade se o TDABC se adequa. Sem discurso de venda, sem ataques a fornecedores.