Assim como dilatar/delatar, flagrância/fragrância, diferimento e deferimento tratam-se de palavras parônimas, com grafias parecidas mas significados bem distintos.
Na agência de um Banco, o gerente faz o deferimento de uma operação. No mundo de TI, também fazemos deferimentos no nosso dia-a-dia, mas vamos falar de outro assunto importantíssimo: o diferimento.
Nesse contexto, vamos abordar o diferimento de custos de software, um tema crítico, tanto pelos valores envolvidos como pelo reflexo direto no resultado das empresas.
O assunto não é trivial: temos alguns normativos legais sobre o tema, como a Lei 11.638/2007 e a MP 449/08. Esta última, inclusive, extinguiu o lançamento em contas de Ativo Diferido, mas permaneceu com o de Ativos Intangíveis, no qual se enquadram as soluções de TI.
O diferimento de custos de software existe pelo pressuposto de que, ao desenvolvermos um sistema, estamos investindo em algo que trará resultados para a organização em exercícios sociais futuros. Isso permite o artifício legal de “empurrar” a despesa para mais adiante, contabilizando o custo presente em uma conta de ativo da empresa e revertendo esse lançamento (amortização) em módicas prestações, ao longo dos exercícios seguintes.
Há algumas regras para se definir o que é e o que não é diferível no desenvolvimento de software, em dois níveis.
No primeiro, avalia-se a natureza da demanda. O esforço na evolução do sistema, como a inclusão/alteração de novas regras de negócio, é diferível; uma manutenção corretiva ou a extração de informações para órgãos de auditoria, não.
Além disso, devem ser avaliadas as atividades na implementação dessa demanda. Ex: o levantamento de requisitos e a codificação são diferíveis, o esforço de gestão do projeto, não.
Portanto, apenas a combinação desses dois níveis possibilitam a precisão dos valores a serem diferidos.
Alguns exemplos:
- a codificação em uma manutenção corretiva não é passível de diferimento;
- a codificação em uma manutenção evolutiva é passível de diferimento;
- a gestão de um projeto de saneamento (melhoria de performance) em um sistema não é passível de diferimento;
- a gestão de projeto em uma manutenção evolutiva não é passível de diferimento.
O diferimento dos custos de pessoal deve se dar mensalmente, pois deve guardar coerência com o dispêndio da folha de pagamento da empresa.
Já na terceirização, o assunto é um pouco mais complexo. Nos contratos bodyshop (baseados em horas, atualmente desaconselhados pelos órgãos legais) o processo é similar ao do desenvolvimento interno.
Nas fábricas de software, cujo modelo de negócios baseia-se na entrega, a provisão do que será pago e a métrica de cada contrato devem ser avaliadas. Na APF (Pontos de Função), por exemplo, a verificação se dá pelas fases/disciplinas da engenharia de software; na utilização de métricas proprietárias, cada tarefa definida no “cardápio de TI” deve ser avaliada.
Para soluções adquiridas, o lançamento do valor a ser diferido pode, dependendo do contrato, ocorrer de uma única vez. Já no caso dos softwares internos - tanto in-house como via outsourcing - o diferimento se dá num continuum, visto que praticamente todos os meses surgem novos valores a serem contabilizados como ativos e suas correspondentes amortizações, por conta desse dinamismo, variam a cada mês.
Bom, essa é apenas uma primeira abordagem. Futuramente voltaremos a falar sobre o tema.
Na agência de um Banco, o gerente faz o deferimento de uma operação. No mundo de TI, também fazemos deferimentos no nosso dia-a-dia, mas vamos falar de outro assunto importantíssimo: o diferimento.
Nesse contexto, vamos abordar o diferimento de custos de software, um tema crítico, tanto pelos valores envolvidos como pelo reflexo direto no resultado das empresas.
O assunto não é trivial: temos alguns normativos legais sobre o tema, como a Lei 11.638/2007 e a MP 449/08. Esta última, inclusive, extinguiu o lançamento em contas de Ativo Diferido, mas permaneceu com o de Ativos Intangíveis, no qual se enquadram as soluções de TI.
O diferimento de custos de software existe pelo pressuposto de que, ao desenvolvermos um sistema, estamos investindo em algo que trará resultados para a organização em exercícios sociais futuros. Isso permite o artifício legal de “empurrar” a despesa para mais adiante, contabilizando o custo presente em uma conta de ativo da empresa e revertendo esse lançamento (amortização) em módicas prestações, ao longo dos exercícios seguintes.
Há algumas regras para se definir o que é e o que não é diferível no desenvolvimento de software, em dois níveis.
No primeiro, avalia-se a natureza da demanda. O esforço na evolução do sistema, como a inclusão/alteração de novas regras de negócio, é diferível; uma manutenção corretiva ou a extração de informações para órgãos de auditoria, não.
Além disso, devem ser avaliadas as atividades na implementação dessa demanda. Ex: o levantamento de requisitos e a codificação são diferíveis, o esforço de gestão do projeto, não.
Portanto, apenas a combinação desses dois níveis possibilitam a precisão dos valores a serem diferidos.
Alguns exemplos:
- a codificação em uma manutenção corretiva não é passível de diferimento;
- a codificação em uma manutenção evolutiva é passível de diferimento;
- a gestão de um projeto de saneamento (melhoria de performance) em um sistema não é passível de diferimento;
- a gestão de projeto em uma manutenção evolutiva não é passível de diferimento.
O diferimento dos custos de pessoal deve se dar mensalmente, pois deve guardar coerência com o dispêndio da folha de pagamento da empresa.
Já na terceirização, o assunto é um pouco mais complexo. Nos contratos bodyshop (baseados em horas, atualmente desaconselhados pelos órgãos legais) o processo é similar ao do desenvolvimento interno.
Nas fábricas de software, cujo modelo de negócios baseia-se na entrega, a provisão do que será pago e a métrica de cada contrato devem ser avaliadas. Na APF (Pontos de Função), por exemplo, a verificação se dá pelas fases/disciplinas da engenharia de software; na utilização de métricas proprietárias, cada tarefa definida no “cardápio de TI” deve ser avaliada.
Para soluções adquiridas, o lançamento do valor a ser diferido pode, dependendo do contrato, ocorrer de uma única vez. Já no caso dos softwares internos - tanto in-house como via outsourcing - o diferimento se dá num continuum, visto que praticamente todos os meses surgem novos valores a serem contabilizados como ativos e suas correspondentes amortizações, por conta desse dinamismo, variam a cada mês.
Bom, essa é apenas uma primeira abordagem. Futuramente voltaremos a falar sobre o tema.
