Rumo a uma declaração de dependência do fornecedor de software? class=

Rumo a uma declaração de dependência do fornecedor de software?

Posted on em Tecnologia Governamental

De vez em quando, alguém capta o zeitgeist das TI empresariais.  Frank Scavo, presidente da Strativa fê-lo numa publicação no seu blogue: Está na altura de fazer uma declaração de independência dos fornecedores de software? (e um Podcast da Diginomica com uma entrevista de Dennis Howlett). Frank assistiu a um aumento do número de empresas que desenvolvem software personalizado de raiz. Será que o cálculo de construir vs. comprar mudou? As organizações devem declarar independência em relação aos fornecedores independentes de software (ISV), como a FreeBalance?
Não é tanto que as organizações devam declarar a independência dos ISVs, uma vez que os ISVs devem declarar dependência nos clientes.
[encontre uma declaração de dependência de dez pontos do cliente do fornecedor de software abaixo, passe por cima do conteúdo governamental se não estiver interessado].

Mercado público construir vs. comprar

O mercado das TI para a administração pública distingue-se do mercado das empresas pela maior proporção de software antigo e personalizado. É o que se verifica no nosso mercado principal: Planeamento de Recursos Governamentais (GRP), especialmente nos países em desenvolvimento e nas economias emergentes. Os especialistas em gestão das finanças públicas (GFP) consideram que a criação de sistemas de informação de gestão financeira (FMIS) personalizados para a administração pública é uma opção legítima:

No podcast, Scavo refere que as organizações "não devem construir um livro-razão". No entanto, o livro-razão é fundamental para a gestão financeira das administrações públicas. Esta situação é ainda mais complicada pelo facto de as administrações públicas utilizarem a contabilidade das autorizações.
Eu sei como é complicado construir um livro-razão com vários níveis de controlos de autorizações agregados e reportar o "saldo livre" do orçamento em tempo real. Lembro-me de uma conversa com um consultor de uma empresa de consultoria de desenvolvimento nacional bem estabelecida quando lhe disse que o FreeBalance suportava totalmente a contabilidade das autorizações. Ele perguntou-me se eu tinha a certeza, porque a contabilidade das autorizações é muito complicada.
Porque é que tantos especialistas respeitados em GFP consideram que os governos devem considerar a possibilidade de criar sistemas de contabilidade de autorizações personalizados?

Como é que isto chegou a este ponto?

  1. Poder assimétrico
    • A Scavo descreve como os ISVs exercem um enorme poder depois de o software ter sido instalado
    • As administrações públicas podem ficar presas a conjuntos de tecnologias de Planeamento de Recursos Empresariais (ERP) de bases de dados, middleware e linguagens de programação exclusivas (para não falar do hardware para computação em memória)
    • O software desenvolvido à medida limita o poder dos fornecedores sobre as administrações públicas, embora este possa ser um ilusão de controlo
  2. Mau comportamento do ISV
    • A Scavo descreve a forma como alguns ISVs tiram partido do poder assimétrico para adoptar um mau comportamento, designado por "wallet cracking" (cunhado por Brian Sommer), incluindo a instauração de processos contra os clientes, a cobrança de acesso indirecto e o aumento dos preços de manutenção
    • Os governos têm a responsabilidade de gastar os dinheiros públicos de forma eficaz, de modo a obter uma "boa relação qualidade/preço" quando procura de rendimentos o comportamento dos ISVs não deve ser tolerado
    • O software desenvolvido à medida reduz as oportunidades de procura de rendas por parte dos fornecedoresEmbora os governos não possam evitar completamente os fornecedores de tecnologia
  3. Falha de ERP de alto perfil na Administração Pública
  4. Personalização do código
    • A Scavo salienta que grande parte dos produtos comerciais prontos a utilizar (COTS) disponíveis é "inflexível", exigindo uma personalização significativa para satisfazer as necessidades (e os O Gartner Group chegou ao ponto de considerar este software como "antigo")
    • Os requisitos da administração pública diferem significativamente das necessidades da empresa, o que implica longos ciclos de personalização do código (ao ponto de muitos especialistas em GFP lhe chamarem "Customizado de prateleira"), resultando em problemas de qualidade, com o custo adicional de manter e actualizar o código órfão
    • O software desenvolvido à medida parece ter a mesma pegada de complexidade para as administrações públicas que o ERP (embora, como argumentarei mais adiante, a GRP seja muito menos complexa)
  5. Previsibilidade do software
  6. Mau comportamento dos SI
    • A Scavo também salienta que os grandes integradores de sistemas são muitas vezes responsáveis por falhas na implementação, conduzindo frequentemente a uma personalização desnecessária para aumentar as receitas - é um fenómeno que Michael Krigsman chama o "Triângulo do Diabo“
    • Os governos preferem frequentemente celebrar contratos com grandes integradores de sistemas como mecanismo de redução dos riscos
    • O software desenvolvido à medida pode tirar os grandes integradores de sistemas da misturaembora muitos projectos de aplicações desenvolvidas por medida sejam externalizados para as ID

Será que os governos se deparam com duas alternativas terríveis?

Não se trata de um ERP COTS ou de um FMIS desenvolvido à medida para as administrações públicas. Existe a alternativa GRP, como o nosso FreeBalance Accountability Suite. O Planeamento de Recursos Governamentais é um software concebido exclusivamente para a administração pública. O FreeBalance é o primeiro GRP global com implementações em cerca de 30 países.
Alguns observadores partem do princípio de que o GRP herdou todos os males do COTS. Outros observadores assumem que os ISVs da GRP não podem competir com os principais fornecedores de ERP. Aprendi algumas lições neste negócio de GRP:

  1. Software de domínio único
    • Um alto funcionário do ministério das finanças do governo riu-se de mim numa conferência quando lhe disse que o software FreeBalance estava, na sua maioria, configurado para satisfazer os requisitos - é esta configuração que acelera as implementações, reduz os custos dos projectos (especialmente em comparação com as soluções ERP), e permite uma flexibilidade futura para a mudança, algo a que chamamos "activação progressiva“
    • Alguns observadores vêem muito pouca diferença entre "configuração" e "personalização", mas existe uma diferença significativa, em que alguns fornecedores chamam incorrectamente os scripts de programação de configuração e os geradores de código e os conjuntos de fluxo de trabalho são frequentemente apresentados como "configuração"
    • O foco no governo dá-nos uma visão do domínio que falta em muitas grandes empresas, como o grande fornecedor de ERP que diz aos clientes do sector público que os controlos orçamentais por rubrica são uma "melhor prática"
  2. Economias de escala
    • O mercado de ERP arrancou na década de 90, impulsionado pelas preocupações com o Y2K, combinadas com o facto de os ISVs aproveitarem a funcionalidade de um mercado para outro semelhante, oferecendo maior qualidade e melhor apoio, conseguindo economias de escala em comparação com os fornecedores "best-of-breed". o software multimercado tornou-se excessivo
    • As economias de escala diminuem à medida que se entra em novos mercados - muitos fornecedores foram adquiridos para preencher carteiras de produtos, criando o que Ned Lily de xTupla chama o "Cemitério ERP" em que os principais fornecedores se vêem confrontados com uma complexidade impressionante para manter tantas tecnologias adquiridas
    • Os grandes fornecedores utilizam bases de dados, middleware e linguagens de programação proprietários para prender os clientes a pilhas de tecnologia - isto exige um investimento significativo numa altura em que os ISVs ágeis utilizam alternativas de código aberto
  3. Produto e processo integrais
    • Muitos ISVs procuram expandir-se através de parceiros VARs e integradores de sistemas até ao ponto em que o conhecimento do cliente se perde e as taxas de sucesso da implementação diminuem, colocando os ISVs fora de contacto com a realidade do cliente
    • Por outro lado, os ISVs procuram muitas vezes contratos de consultoria com clientes estratégicos, a fim de orientar as prioridades dos produtos, e pergunto-me muitas vezes como é que a maioria dos clientes se sente quando não é considerada estratégica
    • Encaramos todos os clientes como estratégicos, porque como nossos Presidente e Director Executivo, Manuel Pietra frequentemente diz: "temos apenas um cliente por país - o governo, e estamos nessa situação para toda a vida"

Declaração de dependência do cliente

Muitos dos pontos foram inspirados no Está na altura de fazer uma declaração de independência dos fornecedores de software? publicação no blogue incluindo Web APis, código aberto, low-code/no-code.
Os Fornecedores Independentes de Software (ISV) devem admitir e comprometer-se a servir os clientes em primeiro lugar para criar empresas financeiramente sustentáveis.

  1. Responsabilidade Social das Empresas: 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 procura de rendimentos
  2. Acessibilidade Executiva: Os executivos da ISV devem estar acessíveis aos clientes para melhorar o suporte ao produto, os procedimentos da empresa e a compreensão do cliente
  3. Criar valor: Os ISVs devem concentrar-se 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 funcionalidades e pode vir de algo fora dos produtos, como serviços ou alterações de processos
  4. Domínio de especialização: Os ISVs não devem entrar em novos mercados verticais ou horizontais, a menos que tenham adquirido conhecimentos especializados no domínio do desenvolvimento e da gestão de produtos
  5. Implementação Governação: Os ISVs devem fazer parte da estrutura de governação do programa para implementações importantes, em vez de adoptarem uma abordagem "sem intervenção", a fim de orientar os parceiros e os clientes
  6. Adaptabilidade flexível: Os ISVs devem reduzir o peso da personalização do código através da configuração sem código e de técnicas de baixo código para acelerar as implementações, melhorar as alterações futuras e reduzir os custos do cliente
  7. Gestão de recursos: Os ISVs devem comprometer-se a reduzir as necessidades de personalização do código de implementação com um quadro claro de como as características importantes serão adicionadas aos roteiros dos produtos
  8. Inovação cooperativa: Os ISVs devem comprometer-se com a inovação orientada para o cliente, com um quadro claro de como a inovação e o desenvolvimento cooperativos serão possibilitados
  9. Sistemas abertos: Os ISVs devem comprometer-se a apoiar e utilizar sistemas abertos comprovados, incluindo o código-fonte aberto, para dar aos clientes mais opções tecnológicas e, ao mesmo tempo, reduzir o confinamento proprietário
  10. Plataformas empresariais: Os ISVs devem procurar fornecer APIs e reutilizar as plataformas de produtos para permitir o desenvolvimento personalizado quando tal se justificar, eliminando simultaneamente a cobrança aos clientes de funcionalidades já pagas

O meu pensamento sobre a declaração surgiu do meu blogue convidado de 2014 na ZDNet: Falhas informáticas, mudanças de energia e redes sociais editado por Michael Krigsman. Os clientes podem unir-se através das redes sociais. Nessa altura, chamei a atenção para algumas mudanças de comportamento interessantes nas principais empresas de software empresarial:

Desde essa altura, A SAP alterou o seu modelo de "acesso indirecto.

Será que, para os governos, é apenas um mundo de construção versus compra?

A Scavo salienta que as plataformas empresariais de conjuntos de aplicações, como o Plataforma FreeBalance Accountabilitypode 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.
Muitas administrações públicas procuram criar software utilizando um ambiente de desenvolvimento integrado (IDE) normalizado que utilize uma tecnologia. Uma "plataforma de governação" é uma abordagem híbrida que inclui todos os aspectos de construção de plataformas tecnológicas com reutilização de funções de compra utilizadas pelo GRP COTS. Além disso, o low-code/no-code pode permitir o que antes era desenvolvimento personalizado em GRP Suites como uma alternativa mais de compra do que de construção.
COTS ou FMIS personalizado: para além da escolha binária

Como é que os governos podem tomar a decisão correcta de construir ou comprar?

A Scavo identifica uma série de factores que podem ajudar os governos a tomar melhores decisões de construção versus decisões que eu tentei esquematizar.
Construir, opções híbridas e comprar

  1. Especificidade do sector: Muitas soluções ISV foram escritas para outros mercados - isto tem consequências significativas para os governos que têm tantas necessidades específicas
    • Considerar comprar quando o software é concebido para a função pública - a concepção do produto é importante
    • Considerar a construção quando não existe software disponível para a função pública, especialmente quando se trata de uma necessidade legal única
  2. Risco do produto: A construção de funcionalidades complexas, como um registo geral, é arriscada e a flexibilidade para a mudança é importante. este facto tem consequências significativas para os governos que esperam uma futura modernização e reforma
    • Considerar comprar quando as necessidades de pegada do produto são complicadas e se prevêem alterações futuras
    • Considerar a construção quando as necessidades de pegada do produto são modestas e se prevêem poucas alterações futuras
  3. Risco de integração: O software não deve ser considerado como uma caixa negra - silos esta situação tem consequências significativas para as administrações públicas que não dispõem de metadados e de integração dos controlos ao longo dos ciclos orçamentais
    • Considerar comprar quando as necessidades de integração funcional são elevadas, como a gestão de aquisições, de activos e de investimentos públicos, em que as incompatibilidades entre interfaces podem ter consequências materiais, como pagamentos em atraso do Estado e orçamentos ilegalmente excedidos, ou quando as informações do sistema são críticas para os decisores e para a transparência orçamental
    • Considerar a construção quando as funções funcionam de forma autónoma, com necessidade limitada de lançamento nos sistemas financeiros centrais

Tópicos

Contacto