De vez em quando, alguém capta o zeitgeist da TI empresarial. FrAnk Scavo, presidente da Strativa fez isso em uma postagem de blog: Está na hora de fazer uma declaração de independência dos fornecedores de software? (e um Podcast da Diginomica com uma entrevista de Dennis Howlett). Frank testemunhou um aumento no número de empresas que desenvolvem software personalizado do zero. O cálculo de construir versus comprar mudou? As organizações devem declarar independência dos ISVs (Independent Software Vendors, fornecedores independentes de software), como a FreeBalance?
Não se trata tanto de que as organizações devam declarar independência dos ISVs, já que os ISVs devem declarar dependência nos clientes.
[encontre uma Declaração de Dependência do Cliente do Fornecedor de Software de dez pontos abaixo, ignore o conteúdo governamental se não estiver interessado].
Mercado governamental construir vs. comprar
O mercado de TI governamental se distingue do mercado empresarial pela maior proporção de software legado e personalizado. Vemos isso em nosso mercado principal: Planejamento de Recursos Governamentais (GRP), especialmente em países em desenvolvimento e economias emergentes. Os especialistas em Gestão Financeira Pública (PFM) consideram que a criação de Sistemas de Informações de Gestão Financeira (FMIS) personalizados para o governo é uma opção legítima:
- Como projetar um sistema de informações de gerenciamento financeiro: Uma abordagem modular de Gerardo Uña, Richard I Allen e Nicolas M Botton publicado pela Fundo Monetário Internacional em maio de 2019
- Oportunidades tecnológicas e recomendações para a modernização dos sistemas integrados de informações sobre gestão financeira na América Latina e no Caribe de Carlos Pimenta e Antonio Seco publicado pela Banco Interamericano de Desenvolvimento em janeiro de 2019
- Sistemas de informação de gestão financeira: 25 anos de experiência do Banco Mundial sobre o que funciona e o que não funciona por Cem Dener, Joanna Alexandra Watkins e
No podcast, Scavo ressalta que as organizações "não devem criar um livro-razão". No entanto, o razão geral é essencial para a gestão financeira do governo. Isso é ainda mais complicado pelo fato de que os governos operam usando a contabilidade de compromissos.
Sei como é complicado criar um livro-razão com vários níveis de controles de compromissos agregados e informar o "saldo livre" do orçamento em tempo real. Lembro-me de uma conversa com um consultor de uma renomada empresa de consultoria em desenvolvimento de países, quando eu lhe disse que o FreeBalance suportava totalmente a contabilidade de compromissos. Ele me perguntou se eu tinha certeza, pois a contabilidade de compromissos é muito complicada.
Por que tantos especialistas respeitados em PFM consideram que os governos devem pensar em criar sistemas de contabilidade de compromissos personalizados?
Como chegamos a esse ponto?
- Poder assimétrico
- A Scavo descreve como os ISVs exercem um enorme poder após a instalação do software
- Os governos podem ficar presos a pilhas de tecnologia de ERP (Enterprise Resource Planning) de bancos de dados, middleware e linguagens de programação proprietários (sem mencionar o hardware para computação em memória)
- O software desenvolvido sob medida limita o poder do fornecedor sobre os governosEmbora isso possa ser uma ilusão de controle
- Comportamento ruim de ISVs
- A Scavo descreve como alguns ISVs aproveitam o poder assimétrico para ter um comportamento ruim, chamado de "cracking de carteira" (cunhado por Brian Sommer), inclusive processando clientes, cobrando por acesso indireto e aumentando os preços de manutenção
- Os governos têm a responsabilidade de gastar o dinheiro público de forma eficaz, para obter uma "boa relação custo-benefício" quando busca de renda o comportamento dos ISVs não deve ser tolerado
- O software desenvolvido sob medida reduz as oportunidades de busca de aluguel por parte do fornecedorEmbora os governos não possam evitar completamente os fornecedores de tecnologia
- Falha de ERP de alto perfil no governo
- As falhas de ERP no governo variam de pequenos projetos de milhões de dólares a grandes projetos de bilhões de dólares como a Sistema de pagamento Phoenix no Canadá e muitos da Departamento de Defesa dos Estados Unidos
- Os governos estão sob escrutínio político para grandes projetos de TI - uma coisa é quando uma empresa desperdiça dinheiro, outra coisa completamente diferente é quando os governos fazem isso (A culpa pelo Sistema de Pagamento Phoenix é uma batata quente política lançada entre os partidos Liberal e Conservador)
- O software desenvolvido sob medida permite que os governos implementem o software em pequenos módulos para evitar grandes falhasNo entanto, há um número significativo de falhas desenvolvidas sob medida no governo, como healthcare.govE já vimos muitos governos fazerem licitações para substituir softwares personalizados malsucedidos por novos softwares personalizados (consulte também os pontos 1 e 5)
- Personalização do código
- A Scavo ressalta que grande parte do COTS (Commercial-off-the-Shelf) disponível é "inflexível", exigindo uma personalização significativa para atender às necessidades (e o O Gartner Group chegou ao ponto de considerar esse software como "legado")
- Os requisitos do governo diferem significativamente das necessidades comerciais, o que significa longos ciclos de personalização do código (a ponto de muitos especialistas em PFM o chamarem de "Customizado de prateleira"), resultando em problemas de qualidade, com o custo adicional de manutenção e atualização do código órfão
- O software desenvolvido sob medida parece ter a mesma pegada de complexidade para os governos que o ERP (embora eu argumente abaixo que o GRP é muito menos complexo)
- Previsibilidade de software
- Requisitos detalhados são descritos em documentos de licitação do governo para sistemas FMIS principais e periféricos
- Os processos governamentais geralmente são únicos devido a requisitos legais e processos complexos que são bem compreendidos pelos funcionários públicos
- O software desenvolvido sob encomenda parece ter alta previsibilidade quando o conhecimento especializado está nos governos, embora, na prática, esses projetos raramente sejam previsíveis e o o conceito de cascata de projetos totalmente planejados é, muitas vezes, a fonte do fracasso
- Comportamento ruim do SI
- A Scavo também ressalta que os grandes integradores de sistemas costumam ser culpados pelas falhas de implementação, muitas vezes promovendo personalizações desnecessárias para aumentar a receita - esse é um fenômeno que Michael Krigsman chama o "Triângulo do Diabo“
- Os governos geralmente preferem contratar grandes integradores de sistemas como uma mecanismo para reduzir o risco
- O software desenvolvido sob medida pode tirar os grandes integradores de sistemas da misturaEmbora muitos projetos de aplicativos desenvolvidos sob medida sejam terceirizados para SIs
Os governos estão diante de duas alternativas desagradáveis?
Não se trata de um ERP COTS ou de um FMIS desenvolvido sob medida para governos. Existe a alternativa GRP, como o nosso FreeBalance Accountability Suite. O Government Resource Planning é um software desenvolvido exclusivamente para o governo. O FreeBalance é o primeiro GRP global com implementações em cerca de 30 países.
Alguns observadores supõem que o GRP herdou todos os males do COTS. Outros observadores presumem que os ISVs da GRP não podem competir com os principais fornecedores de ERP. Aprendi algumas lições nesse negócio de GRP:
- Software de domínio único
- Certa vez, um funcionário sênior do Ministério das Finanças do governo riu de mim em uma conferência quando eu lhe disse que o software FreeBalance era configurado principalmente para atender aos requisitos - é essa configuração que acelera as implementações, reduz os custos do projeto (especialmente em comparação com as soluções ERP) e permite flexibilidade futura para mudanças, algo que chamamos de "ativação progressiva“
- Alguns observadores veem muito pouca diferença entre "configuração" e "personalização", mas há uma diferença significativa, onde Alguns fornecedores chamam incorretamente os scripts de programação de configuração e geradores de código e conjuntos de fluxo de trabalho são frequentemente apresentados como "configuração"
- O foco exclusivo no governo nos dá uma visão do domínio que falta em muitas grandes empresas, como o grande fornecedor de ERP que diz aos clientes do setor público que os controles de orçamento por item de linha são uma "prática recomendada"
- Economias de escala
- O mercado de ERP decolou nos anos 90, impulsionado pelas preocupações com o Y2K, combinadas com ISVs que aproveitavam a funcionalidade de um mercado para outro semelhante, oferecendo maior qualidade e melhor suporte, obtendo economias de escala em comparação com os fornecedores "melhores da categoria". o software para vários mercados ficou inchado
- As economias de escala diminuem à medida que se entra em novos mercados - muitos fornecedores foram adquiridos para preencher portfólios de produtos, criando o que Ned Lily de xTupla chama o "Cemitério de ERP", onde os principais fornecedores enfrentam uma complexidade impressionante para manter tantas tecnologias adquiridas
- Os grandes fornecedores utilizam bancos de dados, middleware e linguagens de programação proprietários para prender os clientes a pilhas de tecnologia - isso exige um investimento significativo em um momento em que os ISVs ágeis utilizam alternativas de código aberto
- Produto e processo integrais
- Muitos ISVs buscam escalar por meio de VARs e integradores de sistemas parceiros até o ponto em que o conhecimento do cliente é perdido e as taxas de sucesso de implementação são reduzidas, colocando os ISVs fora de contato com a realidade do cliente
- Por outro lado, os ISVs costumam buscar contratos de consultoria com clientes estratégicos para impulsionar as prioridades do produto, e eu sempre me pergunto como a maioria dos clientes se sente quando não é considerada estratégica
- Vemos todos os clientes como estratégicos, pois como nossos Presidente e CEO, Manuel Pietra frequentemente diz: "temos apenas um cliente por país - o governo, e estamos nele para sempre"
Declaração de dependência do cliente
Muitos dos pontos foram inspirados no Está na hora de fazer uma declaração de independência dos fornecedores de software? postagem de blog incluindo Web APis, código aberto, low-code/no-code.
Os fornecedores independentes de software (ISVs) devem admitir e se comprometer a atender os clientes em primeiro lugar para criar negócios financeiramente sustentáveis.
- Responsabilidade Social Corporativa: Os códigos de conduta dos ISVs devem reconhecer que os clientes são a principal comunidade para os esforços de responsabilidade social e devem proibir comportamentos flagrantes de busca de renda
- Acessibilidade executiva: Os executivos de ISVs devem estar acessíveis aos clientes para melhorar o suporte ao produto, os procedimentos da empresa e o entendimento do cliente
- Criar valor: Os ISVs devem se concentrar na criação de valor como o principal veículo para a retenção de clientes e reconhecer que o valor pode não vir da adição de recursos e pode vir de algo fora dos produtos, como serviços ou mudanças no processo
- Conhecimento do domínio: Os ISVs não devem entrar em novos mercados verticais ou horizontais, a menos que desenvolvam conhecimento especializado em desenvolvimento e gerenciamento de produtos
- Governança da implementação: Os ISVs devem fazer parte da estrutura de governança do programa para implementações importantes, em vez de adotar uma abordagem "sem intervenção", a fim de orientar parceiros e clientes
- Adaptabilidade flexível: Os ISVs devem reduzir a carga de personalização do código por meio de técnicas de configuração sem código e de baixo código para acelerar as implementações, melhorar as mudanças futuras e reduzir os custos do cliente
- Gerenciamento de recursos: Os ISVs devem se comprometer a reduzir as necessidades de personalização do código de implementação com uma estrutura clara de como os recursos importantes serão adicionados aos roteiros de produtos
- Inovação cooperativa: Os ISVs devem se comprometer com a inovação orientada pelo cliente, com uma estrutura clara de como a inovação e o desenvolvimento cooperativos serão viabilizados
- Sistemas abertos: Os ISVs devem se comprometer com o suporte e o uso de sistemas abertos comprovados, inclusive de código aberto, para oferecer aos clientes mais opções de tecnologia e, ao mesmo tempo, reduzir o aprisionamento a tecnologias proprietárias
- Plataformas de negócios: Os ISVs devem procurar fornecer APIs e reutilizar plataformas de produtos para permitir o desenvolvimento personalizado quando isso se justificar, eliminando a cobrança de clientes por funcionalidades já pagas
Meu pensamento sobre a declaração surgiu do meu blog convidado de 2014 na ZDNet: Falhas de TI, mudanças de energia e mídia social editado por Michael Krigsman. Os clientes podem se unir aproveitando a mídia social. Naquela época, apontei algumas mudanças comportamentais interessantes nas principais empresas de software corporativo:
- SAP e Infor adotaram pensamento em design para se tornar mais centrada no cliente
- A Microsoft adicionou um opção de licenciamento para a linha de produtos Dynamics.
- As reações negativas dos clientes forçaram a SAP a alterar as políticas de preços em suporte premium e a interface de usuário Fiori atualização.
- A Salesforce.com foi rejeitado em suas tentativas de registrar o termo "empresa social"
Desde aquela época, A SAP mudou seu modelo de "acesso indireto".
É apenas um mundo de construção versus compra para os governos?
A Scavo ressalta que as plataformas de negócios de pacotes de aplicativos, como o Plataforma FreeBalance AccountabilityO software de desenvolvimento de software pode ser aproveitado para desenvolver software personalizado. Está longe de ser uma escolha binária entre construir e comprar. Existem alternativas híbridas de construção e compra.
Muitos governos buscam criar software usando um ambiente de desenvolvimento integrado (IDE) padrão usando uma tecnologia. Uma "plataforma de governança" é uma abordagem híbrida que inclui todos os aspectos de criação de plataformas de tecnologia com reutilização de funções de compra usadas pelo GRP COTS. Além disso, o low-code/no-code pode permitir o que antes era desenvolvimento personalizado no GRP Suites como uma alternativa mais de compra do que de construção.
Como os governos podem tomar a decisão correta de construir ou comprar?
A Scavo identifica uma série de fatores que podem ajudar os governos a tomar melhores decisões de construção versus decisões que eu tentei diagramar.
- Especificidade do setor: Muitas soluções de ISV foram criadas para outros mercados. isso tem consequências significativas para os governos que têm tantas necessidades específicas
- Considere comprar Quando o software é escrito para a função governamental, o design do produto é importante
- Considere a construção quando não há software disponível para a função governamental, especialmente quando se trata de uma necessidade estatutária exclusiva
- Risco do produto: A criação de funcionalidades complexas, como um livro-razão, é arriscada, e a flexibilidade para mudanças é importante. Isso tem consequências significativas para os governos que esperam uma futura modernização e reforma
- Considere comprar quando as necessidades de pegada do produto são complicadas e são esperadas mudanças futuras
- Considere a construção quando as necessidades de pegada do produto são modestas e poucas mudanças futuras são esperadas
- Risco de integração: O software não deve ser considerado uma caixa preta - silos Isso tem consequências significativas para os governos que não têm integração de metadados e controles nos ciclos orçamentários
- Considere comprar Quando as necessidades de integração funcional são altas, como compras, ativos e gerenciamento de investimentos públicos, em que as incompatibilidades de interface podem ter consequências materiais, como atrasos do governo e orçamentos ilegalmente excedidos, ou quando as informações do sistema são essenciais para os tomadores de decisão e para a transparência fiscal
- Considere a construção quando as funções operam de forma autônoma, com necessidade limitada de lançamento nos principais sistemas financeiros