Para uma Declaração de Dependência de Fornecedor de Software? class=

Para uma Declaração de Dependência do Fornecedor de Software?

Posted on em Tecnologia governamental

De vez em quando, alguém capta o zelador de TI da empresa.  Frank Scavo, presidente da Strativa o fez em um post de blog: Tempo para uma Declaração de Independência dos Fornecedores de Software? (e um Podcast Diginomica com uma entrevista de Dennis Howlett). Frank tem testemunhado um aumento nas empresas que desenvolvem software personalizado a partir do zero. Será que o cálculo construção vs. compra mudou? As organizações deveriam declarar independência de fornecedores independentes de software (ISVs) como o FreeBalance?
Não é tanto assim que as organizações devem declarar a independência dos ISVs, como os ISVs deveriam declarar dependência sobre os clientes.
[encontre abaixo uma Declaração de Dependência do Cliente Fornecedor de Software de dez pontos, pule o conteúdo do governo se não estiver interessado].

Construção do mercado governamental vs. compra

O mercado de TI do governo se distingue do mercado empresarial por maiores proporções de software personalizado e legado. Vemos isso em nosso mercado principal: Planejamento de Recursos Governamentais (GRP), particularmente em nações em desenvolvimento e economias emergentes. Os especialistas em Gerenciamento de Finanças Públicas (PFM) têm considerado que a construção de Sistemas de Informação de Gerenciamento Financeiro (FMIS) personalizados pelo governo é uma opção legítima:

No podcast, Scavo aponta que as organizações "não devem construir um livro razão geral". No entanto, o livro razão geral é o núcleo da gestão financeira do governo. Isto é ainda mais complicado pelo fato de que os governos operam utilizando a contabilidade de compromisso.
Sei como é complicado construir um razão geral com múltiplos níveis de controles agregados de compromisso e relatar o "saldo livre" do orçamento em tempo real. Lembro-me de uma conversa com um consultor de uma bem estabelecida consultoria de desenvolvimento do país quando lhe disse que a FreeBalance apoiava plenamente a contabilidade de compromissos. Ele me perguntou se eu tinha certeza porque a contabilidade de compromissos é muito complicada.
Por que tantos e respeitados especialistas em GFP consideram que os governos deveriam considerar a possibilidade de escrever sistemas de contabilidade de compromisso personalizados?

Como chegou a isto?

  1. Poder assimétrico
    • O Scavo descreve como os ISVs exercem uma enorme potência uma vez instalado o software
    • Os governos podem ser bloqueados nas pilhas de tecnologia de planejamento de recursos empresariais (ERP) de bancos de dados proprietários, middleware e linguagens de programação (sem mencionar o hardware para computação in-memory)
    • O software desenvolvido sob medida limita o poder do fornecedor sobre os governosembora isto possa ser um ilusão de controle
  2. Comportamento ruim do ISV
    • Scavo descreve como alguns ISVs alavancam o poder assimétrico para o mau comportamento, chamado "rachadura da carteira" (cunhado por Brian Sommer), incluindo processar clientes, cobrar pelo acesso indireto, e aumentar os preços de manutenção
    • Os governos têm a responsabilidade de gastar o dinheiro público de forma eficaz, a fim de alcançar uma "relação custo-benefício" onde Procura de aluguel o comportamento dos ISVs não deve ser tolerado
    • O software desenvolvido sob medida reduz as oportunidades para a procura de aluguel de fornecedoresembora os governos não possam evitar totalmente os fornecedores de tecnologia
  3. Falha de alto perfil do ERP no governo
  4. Personalização de código
    • Scavo ressalta que grande parte do Commercial-off-the-Shelf (COTS) disponível é "inflexível", exigindo uma personalização significativa para atender às necessidades (e o O Gartner Group foi tão longe para considerar este software como "legado".)
    • As exigências do governo diferem significativamente das necessidades comerciais, o que significa longos ciclos de personalização do código (ao ponto de muitos especialistas em PFM o chamarem de "Customized-off-the-Shelf"), resultando em problemas de qualidade, com o custo adicional de manter e atualizar o código órfão
    • O software desenvolvido sob medida parece ter a mesma pegada de complexidade para os governos que o ERP (embora, eu argumentei abaixo, o GRP é muito menos complexo)
  5. Previsibilidade de software
  6. Comportamento pobre da SI
    • A Scavo também aponta que os grandes integradores de sistemas estão frequentemente em falta por falhas de implementação, muitas vezes levando a uma personalização desnecessária a fim de aumentar a receita - é um fenômeno que Michael Krigsman chama o "O Triângulo do Diabo“
    • Os governos freqüentemente preferem contratar integradores de sistemas de grande porte como um mecanismo para reduzir os riscos
    • O software desenvolvido sob medida pode tirar integradores de sistemas de grande porte da misturaembora muitos projetos de aplicação desenvolvidos sob medida sejam terceirizados para as IFs.

Será que os governos enfrentam duas alternativas feias?

Não é nem o ERP COTS nem o FMIS desenvolvido sob medida para governos. Existe a alternativa GRP, como nosso FreeBalance Accountability Suite. O Planejamento de Recursos Governamentais é um software projetado exclusivamente para o governo. O FreeBalance é o primeiro GRP global com implementações em cerca de 30 países.
Alguns observadores assumem que o GRP herdou todos os males do COTS. Outros observadores assumem que a GRP ISVs não pode competir com os principais fornecedores de ERP. Eu aprendi algumas lições neste negócio de GRP:

  1. Software de domínio único
    • Um funcionário sênior do ministério das finanças do governo uma vez riu de mim em uma conferência quando lhe disse que o software FreeBalance foi 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 a mudança, algo que chamamos de "ativação progressiva“
    • Alguns observadores vêem muito pouca diferença entre "configuração" e "customização", mas existe uma diferença significativaonde alguns fornecedores chamam incorretamente os scripts de programação como configuração e geradores de código e conjuntos de fluxo de trabalho são freqüentemente apresentados como "configuração".
    • O foco do laser 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 de itens de linha são uma "melhor prática".
  2. Economia de escala
    • O mercado de ERP decolou nos anos 90 impulsionado pelas preocupações com o Y2K combinado com ISVs alavancando a funcionalidade de um mercado para um mercado similar, oferecendo maior qualidade e melhor suporte alcançando economias de escala em comparação com os fornecedores "best-of-breed", ainda hoje o software de mercado múltiplo se tornou inchado
    • As economias de escala diminuem com a entrada de novos mercados - muitos fornecedores foram adquiridos para encher carteiras de produtos, criando o que Ned Lily de xTuple chama o "Túmulo do ERP"onde os principais fornecedores enfrentam uma complexidade espantosa para manter tantas tecnologias adquiridas
    • Grandes fornecedores utilizam bancos de dados proprietários, middleware e linguagens de programação para travar os clientes em pilhas de tecnologia - isso requer investimento significativo em um momento em que os ISVs ágeis utilizam alternativas de código aberto.
  3. Produto e Processo Integral
    • Muitos ISVs procuram escalar através de VARs parceiros e integradores de sistemas até o ponto em que o conhecimento do cliente é perdido e as taxas de sucesso de implementação são diminuídas, colocando os ISVs fora de contato com a realidade do cliente
    • Por outro lado, os ISVs frequentemente buscam contratos de consultoria com clientes estratégicos a fim de direcionar as prioridades dos produtos, e muitas vezes me pergunto como a maioria dos clientes se sente quando considerados não estratégicos
    • Vemos todos os clientes como estratégicos, porque, como nosso Presidente e CEO, Manuel Pietra diz freqüentemente: "temos apenas um cliente por país - o governo, e estamos nele para toda a vida".

Declaração de Dependência do Cliente

Muitos dos pontos foram inspirados pelo Tempo para uma Declaração de Independência dos Fornecedores de Software? post no blog incluindo Web APis, código aberto, código baixo/ sem código.
Os fornecedores independentes de software (ISVs) devem admitir e se comprometer a servir os clientes primeiro para construir negócios financeiramente sustentáveis.

  1. Responsabilidade Social Corporativa: Os códigos de conduta ISV devem reconhecer que os clientes são a principal comunidade para os esforços de responsabilidade social, e devem proibir o comportamento de busca de renda
  2. Acessibilidade executiva: Os executivos ISV devem estar acessíveis aos clientes para melhorar o suporte ao produto, os procedimentos da empresa e a compreensão do cliente
  3. Valor de construção: Os ISVs devem se concentrar no valor do edifício como o principal veículo de retenção do cliente, e reconhecer que o valor pode não vir da adição de características e pode vir de algo fora dos produtos, como serviços ou mudanças de processo
  4. Especialização em Domínios: Os ISVs não devem entrar em novos mercados verticais ou horizontais a menos que construam conhecimentos especializados em desenvolvimento e gerenciamento de produtos.
  5. Implementação Governança: Os ISVs devem fazer parte da estrutura de governança do programa para implementações importantes, em vez de adotar uma abordagem "mãos-livres", a fim de orientar parceiros e clientes
  6. Adaptabilidade flexível: Os ISVs devem reduzir a carga de personalização de código através de configuração sem código e técnicas de baixo código para acelerar implementações, melhorar mudanças futuras e reduzir os custos do cliente
  7. Gestão de recursos: Os ISVs devem se comprometer a reduzir as necessidades de customização do código de implementação com uma estrutura clara de como as características importantes serão adicionadas aos roteiros de produtos
  8. Inovação cooperativa: Os ISVs devem se comprometer com a inovação liderada pelo cliente com uma estrutura clara de como a inovação e o desenvolvimento cooperativo serão viabilizados
  9. Sistemas Abertos: Os ISVs devem se comprometer a apoiar e utilizar sistemas abertos comprovados, incluindo código aberto, para dar aos clientes mais opções tecnológicas e, ao mesmo tempo, reduzir o bloqueio de propriedade
  10. Plataformas de negócios: Os ISVs devem procurar fornecer APIs e reutilização a partir de plataformas de produtos para permitir o desenvolvimento personalizado quando justificado, eliminando ao mesmo tempo a cobrança de clientes por funcionalidades já pagas

Meu pensamento sobre a declaração surgiu de meu blog convidado de 2014 na ZDNet: Falhas de TI, turnos de energia e mídias sociais editado por Michael Krigsman. Os clientes podem se unir alavancando as mídias sociais. Apontei algumas mudanças de comportamento interessantes nas principais empresas de software empresarial daquela época:

Desde aquela época, A SAP mudou seu modelo de "acesso indireto"..

É apenas um mundo construído versus comprado pelos governos?

Scavo ressalta que as plataformas de negócios das suítes de aplicação, como a Plataforma FreeBalance Accountabilitypode ser alavancado para desenvolver software personalizado. Está longe de ser uma escolha de construção vs. compra de binários. Existem alternativas híbridas de construção e compra.
Muitos governos procuram construir software usando um Ambiente de Desenvolvimento Integrado (IDE) padrão, utilizando uma tecnologia. Uma "plataforma de governança" é uma abordagem híbrida ao incluir todos os aspectos de construção de plataformas tecnológicas com reutilização de funções de compra utilizadas pelo GRP COTS. E, o código baixo/não-código pode permitir o que antes era desenvolvimento personalizado no GRP Suites como uma alternativa mais de compra do que de construção.
COTS ou Custom FMIS: Além da Escolha Binária

Como os governos podem tomar a decisão correta de construir versus comprar?

Scavo identifica uma série de fatores que podem ajudar os governos a tomar melhores decisões versus decisões que eu tentei diagramar.
Construir, Opções Híbridas e Comprar

  1. Especificidade-Indústria: Muitas soluções ISV foram escritas para outros mercados - isto tem conseqüências significativas para os governos que têm tantas necessidades únicas
    • Considere comprar quando o software escrito para a função governamental - o projeto do produto é importante
    • Considere construir quando não há software disponível para a função governamental, especialmente quando se trata de uma necessidade estatutária única
  2. Risco do produto: Construir funcionalidades complexas, como um livro razão geral é arriscado, e a flexibilidade para a mudança é importante - isto 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 construir quando as necessidades de pegada do produto são modestas, e poucas mudanças futuras são esperadas
  3. Risco de integração: O software não deve ser considerado silos de caixa preta - isto tem consequências significativas para os governos que carecem de metadados e controla a integração através dos ciclos orçamentários
    • Considere comprar quando as necessidades de integração funcional são altas, tais como aquisição, gestão de ativos e investimentos públicos, onde os desajustes de interface podem ter conseqüências materiais, como atrasos do governo e orçamentos ilegalmente excedidos - ou quando as informações do sistema são críticas para os tomadores de decisão e transparência fiscal
    • Considere construir quando as funções operam isoladamente com necessidade limitada de lançamento em sistemas financeiros centrais

Tópicos

Contato