jan 28 2020

Matriz de ferramentas BPMN

Segue abaixo uma matriz traduzida e adaptada que avalia ferramentas BPMN

Sistema operacional Tipos de Licenciamento
NomeCriadorCross-PlataformaWindowsLinuxUnixMacPlataforma / Sistema operacionalVersão BPMNPrimeiro lançamentoÚltimo lançamentofreeproprietárioUsar com limitaçõesOpen Source
ActiveVOSInformatica xx  Windows, LinuxBPMN 2.020052014 x  
Activiti ModelerAlfresco and the Activiti communityx    Cross-platformBPMN 2.017/05/201018/12/2014x  x
ARPOKLUG SOLUTIONS – Desenvolvedora do Software ARPO x   WindowsBPMN 2.1   xx 
ADONIS (software)BOC Information Technologies Consulting AG x   WindowsBPMN 2.019952012xx  
AeneisIntellior AGxxxxxCross-platformBPMN 2.0 19/09/2016 x  
Agiles BPMS & ECMIMAGE Technology S.A. xx xWindows, Linux,MacBPMN 2.02003-102013-09 x  
Altova UModelAltova x   WindowsBPMN 1.1, 2.0200512/06/2013 x  
ARCWAY CockpitARCWAY AG xx xWindows, Mac (Linux unofficially)BPMN 2.020052014xx  
ARIS ExpressSoftware AG xx xWindows (and Linux, Mac unofficially)BPMN 2.028/07/200919/12/2012x   
AuraPortalAuraPortal x   WindowsBPMN 2.020012016xx  
BIC CloudGBTEC Software + Consulting AGxxxx Cross-platformBPMN 2.02006March 2019 x  
Bizagi BPM SuiteBizagi x   WindowsBPMN 2.0   x  
Bizagi Process ModelerBizagi x   WindowsBPMN 2.0  x   
BiZZdesign ArchitectBiZZdesign x   WindowsBPMN 2.020122014 x  
Bonita BPMBonitasoft xx xCloud, Windows, Linux, MacBPMN 2.0200101/07/2019x  x
Borland TogetherBorland xx xWindows, Linux,Mac, Solaris  04/07/2009 xx 
BPMN Sketch MinerCesare Pautassox    BrowserBPMN 2.020192019x   
BPMN Visio ModelerTrisotech x   WindowsBPMN 2.02010Bi-yearly xx 
BPMN Web ModelerTrisotechx    CloudBPMN 2.02012Bi-monthly xx 
bpmn.ioCamunda Services GmbHxxxxxCloudBPMN 2.02014-0229/07/2016xx x
BPMN Modeler (for Atlassian Confluence)viadee IT-Unternehmensberatung GmbHxxxxxCross-platformBPMN 2.02016-012017-07x   
Camunda ModelerCamundax    Cross-platformBPMN 2.0201330/11/2016xx x
CardanitESTECO SpAxxxxxCross-platform (browser based)BPMN 2.001/02/201605/12/2019xx  
Cubettosemture GmbH     iOS, AndroidBPMN 2.02012-052013-08 x  
Cubetto Toolsetsemture GmbH xx xWindows, Mac,LinuxBPMN 2.020032013-08x   
Digital Business Transformation SuiteInterfacingxxxxxWindows, Cross-platform (browser based), Linux, Unix, MacBPMN 2.019932018 x  
Eclipse BPMN2 ModelerEclipse.org. Eclipse SOA project.x    Cross-platformBPMN 2.020112014x  x
Enterprise ArchitectSparx Systems xx xWindows, Linux,MacBPMN 2.020002015-01 x  
Flowable CoreFlowable xxxxWindows, Linux, MacBPMN 2.0201205/04/2018x  x
Genexus WorkFlowArtech x   WindowsBPMN 2.0 2012-03 x  
GenMyModelAxelliencex    Cross-platform(browser based)BPMN 2.02015March 2015xx  
HEFLOVenki Tecnologiax    Cloud (browser based)BPMN 2.015/10/201525/07/2016xx  
HP Process AutomationHP x   Java / WindowsBPMN 2.020002013 x  
IBM BlueWorks LiveIBMx    Cloud (browser based)BPMN 2.0   x  
IBM Process DesignerIBM x   eclipse based tool for creating executable processesBPMN 2.0+   x  
IBM Rational System ArchitectIBM     Enterprise Architecture toolBPMN 2.0+ 2014-09 x  
iGrafx Flowcharter, iGrafx ProcessiGrafxxx   Windows andCross-platform (via iGrafx Cloud)BPMN 2.019882012 x  
Imixs-WorkflowImixsxxxxxCross-platformBPMN 2.020062017x  x
INNOVATOR for Business AnalystsMID GmbH x   WindowsBPMN 2.020102012xx  
Intellileap SolutionsIntelliPROBPMS x   Windows Cloud & On-premiseBPMN 2.020132013-14 x  
jBPMRedhatx    Cross-platformBPMN 2.0 02/08/2014x   
jBPMNNetBeans Community project.x    Cross-platformBPMN 2.020132014x   
LogizianVisual Paradigm xx  Windows, Linux, OS X, SolarisBPMN 2.016/12/201303/04/2014 x  
LucidChartLucid Software Incx    Cross-platform(browser based)BPMN 2.02011twice a monthxx  
MagicDrawNo MagicxxxxxWindows, Linux,MacBPMN 2.024/09/200702/06/2014 xx 
Microsoft Visio2013Microsoft x   Windows  2013 x  
ModelFoundryModelFoundry Pty. Ltd.     iOSBPMN 2.01.1.01.1.3 x  
ModelioModeliosoft xx xWindows, Linux,Mac OSBPMN 2.0200901/10/2014   x
OmniGraffleOmni Group    xMac  2010 x  
OMNITRACKEROMNINETxx   Windows, Cross-platform (browser based)BPMN 2.0 2018 x  
Pega 7Pegasystems Inc. x   WindowsBPMN 2.019912014 x  
PragmaDev ProcessPragmaDev xx xWindows, Linux, macOSBPMN 2.020192019xx  
Process Modeler for Microsoft Visioitp commerce ag x   WindowsBPMN 2.0200318/09/2014 x  
process4.biz BPMprocess4.biz Softwareentwicklungs- und Vertriebs GmbH x   WindowsBPMN 2.0, 1.220032015-03 x  
ProcessCraftTabtou Ltd xx  iOS, Android,Windows, Linux, OS XBPMN 2.0 10/05/2012 x  
QPR ProcessDesignerQPR Software Plc. x   WindowsBPMN 2.02002-012014-01 x  
QUAMLINTRA Solutions GmbH x   MicrosoftSharePointBPMN 2.020072013 x  
RunaWFERuna Consulting Groupx    Cross-platformBPMN 2.0200401/08/2014x  x
SemTalkSemtation GmbH x   Windows, SharePoint, MS VisioBPMN 2.020012014-05 x  
Signavio Process EditorSignavio x   Cloud or On-premise (Windows, Linux) server), Client-side browserBPMN 2.02009updated monthly x  
simpl4transparent solutions GmbHxxxxxJava, Cloud-Platform PaaS/SaaSBPMN 2.02014-092016-05x  x
Software Ideas ModelerDusan Rodina xx  Windows, LinuxBPMN 2.02009-082014-02 x  
StagesMethod Parkx    Cross-Platform, Cloud and On-Premise 20022014-03 x  
SYDLE SEED CommunitySYDLE Systemsx    Cloud (browser based) 2012-072012-07x   
TIBCO ActiveMatrixTIBCO Software Inc. xx  Linux, AIX, HP-UX,Solaris, WindowsBPMN 2.02010-052013-02 x  
TriasterTriaster x   Windows  2014-09 x  
Visible AnalystVisible Systems x   Windows, CitrixBPMN20072013 x  
Visual ParadigmVisual Paradigm International x   Windows Cloud & On-premiseBPMN 2.0   x  
W4 BPMN+W4 Software xxxxWindows, Mac,Linux/UnixBPMN2.02014-012014-01 x  
Yaoqiang BPMN Editor史耀强 (Blenta) (Sourceforge ID) xx xJava / Windows,Linux, Mac, SolarisBPMN 2.027/05/201024/12/2016xx x
yEdyWorks xxxxWindows, Mac,Linux/UnixBPMN 2.0 15/07/2016x   
yEd LiveyWorksx    Windows, Mac,Linux/UnixBPMN 2.025/07/201625/07/2016x   
Comindware Business Application PlatformComindwarexxxxxCloudBPMN 2.020162018 x  

No responses yet

jul 07 2015

A Engenharia de Software com BPMS Par. 4

Parte 4 Mudanças culturais e tecnológicas necessárias para adoção de BPMS

 

Embora um desenho de processo possa ser feito usando ferramentas simples ou até papel, não será tão abrangente quanto poderia ser, pois é difícil manter a consistência de dados coletados em uma transformação quando alterações ocorrem o tempo todo. Sem automação é difícil simular uma operação e controlar suas iterações. O negócio simplesmente muda muito rápido para que qualquer desenvolvimento tradicional de sistemas ou projeto de melhoria de sistemas possa acompanhar. O principal motivo para usar BPMS é a capacidade de gerar rapidamente aplicações para aprimorar tanto o modo que a operação é controlada e monitorada, quanto fornecer automação de tarefas. Isso reduz a carga sobre a área de Tecnologia da Informação e habilita mudanças rápidas por meio de desenhos e testes iterativos dos processos.

O desenho do processo de negócio da organização irá executar dentro do BPMS, portanto utilizar um BPMS em um esforço de transformação é um compromisso estratégico com a ferramenta e com as mudanças que ela suporta. A transformação implica uma mudança ampla e qualquer tecnologia usada afetará parte significativa das operações de negócio e da infraestrutura de tecnologia da informação. Um BPMS oferece vantagens em comparação a tecnologias tradicionais e é um divisor de águas na geração de aplicações. Seja o desenho simplesmente incrementado com resultados provenientes do monitoramento de desempenho ou iterado utilizando simulação, o fato é que com um BPMS dando suporte à nova operação é possível promover mudanças mais rapidamente com menor risco e custo. Contudo, a área de Tecnologia da Informação deverá construir planos, padrões, métodos para a utilização do BPMS para que estes sejam alinhado com as mudanças culturais e organizacionais necessárias. É necessário que a organização tenha a cultura BPM disseminada para a sua adoção em plenitude. Caso ela não tem a mudança cultural deverá ser previamente iniciada.

A preocupação com a maneira como as pessoas vão lidar com o nível de mudança nesta transformação deve ser foco de um plano de gerenciamento de mudança que deve abranger toda a organização. Organizações são sistemas sociais complexos que sem o esforço, a contribuição e dedicação de sua força de trabalho não podem sobreviver. O conhecimento, a habilidade e a criatividade das pessoas representam um alto valor para a organização e levam tempo para serem adquiridos, desenvolvidos e estarem disponíveis. Quando as pessoas saem da organização, o conhecimento da história, compreensão de regras, familiaridade com infraestrutura e conhecimento para lidar com os constantes problemas são levados junto com elas. Portanto, é essencial entender os tipos de conhecimento que as pessoas possuem e que não podem ser encontrados em outros lugares na organização. O fato é que, em muitos casos, a única fonte confiável de conhecimento são as pessoas que fazem o trabalho.

Pessoas odeiam e amam mudanças. Odeiam porque as obrigam a aprender, amam porque as permitem aprender. O ponto central da questão está na crença das pessoas. Significa que as pessoas primeiramente têm de mudar suas crenças para destrancar a porta e avançar para o futuro. E não se muda de crença instantaneamente, principalmente quando se manteve apoiado nelas ao longo de toda uma vida. Quando crenças são mudadas, cria-se um novo conjunto de valores, que levará a novas atitudes, permitindo a incorporação de novas habilidades e, finalmente, a formação de um novo arcabouço de conhecimentos.

O sucesso da implantação e ferramental BPMS em uma organização está diretamente relacionado com a capacidade cultural da organização de conduzir iniciativas de transformação de processos. Vamos exemplificar em um cenário. Uma organização conduziu um esforço de transformação de processos. O pessoal da equipe de transformação foi treinado e os gestores se comprometeram com o esforço. O esforço atingiu os objetivos e excedeu às expectativas. Os membros da equipe de transformação foram promovidos e passaram a gerenciar ou assessorar a gerência nas áreas transformadas. As coisas foram bem por vários anos. Melhorias foram identificadas e incorporadas às operações. Contudo, à medida que os membros originais da equipe de transformação receberam trabalhos distintos ou deixaram a organização, o compromisso com a melhoria contínua caiu mais e mais. Finalmente, à marca de alguns anos, as operações de negócio estavam operando em um nível bem abaixo do esperado e a organização estava novamente em apuros.

As transformações e melhorias contínuas dos processos devem fazer parte da cultura organizacional para que as ferramentas BPMS sejam utilizadas em sua plenitude. Ela representa uma mudança de paradigma para todos os colaboradores da organização incluindo as áreas de tecnologia da informação que devem-se preparar antes definido e redesenhado seus padrões e métodos para suportar o ferramental BPMS. Isto se torna essencial ser feito previamente pois BPMS é uma ferramenta ou conjunto de ferramentas, geralmente com custos elevados, que necessitam de cultura organizacional estabelecida para a sua utilização, caso contrário, pode conseguir somente alguns benefícios a curto prazo e perda do investimento a longo prazo.

Os padrões e métodos que a organização deve adotar não são necessariamente uma mudança radical na forma de se conceber os sistemas de informação da organização. Tanto a área responsável pela TI, quando o Escritório de Processos ou equivalente na instituição devem adaptar suas formas de trabalhar para a adoção de um BPMS. Um Escritório de Processos que antes só desenhava processos com a finalidade de documentar o negócio da instituição, deverá se aprofundar nas suas diagramações para a criação de mapas e modelos de processos com vistas a automação dos mesmos. Se as fronteiras entre a Equipe de Negócios e TI não forem definidas previamente, diversos problemas para entender onde uma começa e a outra acaba ocorrerão.

A equipe responsável pelo Escritório de Processos deve planejar a profundidade do mapeamento juntamente com a área de TI. Um canal aberto entre estas duas áreas deve fornecer informações de feedback constantes tais como: informações que são necessárias ao usuário que estão no processo e quais estão faltando; Se algum campo do formulário está faltando na descrição das atividades; Todas as atividades que o usuário deve executar no sistema foram identificadas no processo; Se foram identificadas todas as ações automáticas que o sistema deve realizar; etc.

Note que a descrição para automação de um processo é muito mais detalhada e despende um esforço maior da equipe do Escritório de Processo para o levantamento das informações. Por esta razão, é aconselhável o planejamento de que processos vão ou não ser automatizados e para que público o processo servirá, para definir a melhor forma de diagramação e descrição do processo. Na maioria das vezes, somente alguns os processos vão para automação e devem ter este nível de detalhamento.

Diferenca-descricao

Figura 5 Diferença da descrição de atividades para negócio e para automação

Uma outra abordagem que pode ser definida, dentre as várias possíveis, entre a equipe do Escritório de Processos e a TI da organização, é o acompanhamento do um analista de requisitos e fazes específicas do mapeamento dos processos. Esta abordagem pode ser útil para desonera o Analista de Processos para que o mesmo possa trabalhar de forma mais focada na transformação do processo e sua implantação sem se preocupar com o detalhamento do processo para automação. Nesta abordagem, o analista de requisito participa das reuniões junto com o analista de processo. e já levanta todas as informações necessárias para a automação do processo. Esta forma de trabalho é especialmente recomendada quando a automação dos processos se dará por meio do desenvolvimento tradicional utilizando processos de software comumente adotados no mercado. Para a automação utilizando ferramentas BPMS, esta abordagem, pode gerar retrabalho, uma vez que os processos diagramados terão um desenho mais focado para as áreas de negócio da organização e posteriormente deverão ser refinados e redesenhados para automação contendo mais informações e detalhamentos.

Independentemente do tipo de abordagem adotada, o importante é que fique clara quais são as responsabilidades de entrega do Escritório de Processos e da área de TI da organização. A área de TI da organização deverá planejar, construir ou adaptar os processos de software tradicionalmente adotados para uma visão mista com o Escritório de Processos da organização. O Escritório de Processos deverá atualizar sua metodologia e forma de diagramação e descrição dos processos para auxiliar a área de TI. Um modo para realizar a transição de forma mais clara para a área de TI seria fazer uma comparação com as fases do desenvolvimento tradicional com possíveis fazes para o desenvolvimento com uma ferramenta BPMS.

Desenvolvimento tradicional x BPMSFigura 6 desenvolvimento tradicional e com o BPMS

São inúmeras as formas, mas é extremamente importante planejar, mapear os processos e a interação entre o Escritório de Processos e a TI antes da adoção de ferramentas BPMS pela organização. Nos próximos artigos, para exemplificar uma das possíveis formas de integras as duas árias e automatizar com ferramentas BPMS, vamos mostrar uma automação de processos enfatizando as informações devem ser levantadas pelo Analista de Negócio e o papel da TI.

Referências

ABPMP – Association of Business Process Professionals. (2013). BPM CBOK Guia para o Gerenciamento de Processos de Negócio Corpo comum de Conhecimento . Brasil: © 2013 Association of Business Process Management Professionals.

Junior, K. O., & Aresta, P. A. (2015). Como SOA pode influenciar em iniciativas de BPM. Como SOA pode influenciar em iniciativas de BPM. Brasília, Brasíl.

Kniberg, H. (2007). Scrum e XP direto das Trincheiras. Estados Unidos: C4Media Inc.

Neponuceno, B. G. (12 de Fevereiro de 2014). Ferramentas para Escritório de Processos – Business Process Analysis – BPA. Fonte: Gerenciamento de Processos de Negócio, Business Process Management – BPM: http://bpm.bgnweb.com.br/2014/02/12/ferramentas-para-escritorio-de-processos-business-process-analysis-bpa/

Rezende, D. A. (2005). Engenharia de Software e sistemas de informação (3ª edição ed.). Rio de Janeiro: Brasport.

Sganderla, K. (09 de Julho de 2014). IProcess soluções em tecnologia. Fonte: O que BPM tem a ver com requisitos de software? Tudo!: http://blog.iprocess.com.br/2014/07/o-que-bpm-tem-a-ver-com-requisitos-de-software-tudo/

The Project Cartoon Beta. (27 de 03 de 2015). How Projects Really Work (Brazilian Portuguese Version). Fonte: The Project Cartoon .com Beta: http://projectcartoon.com/cartoon/611

Wikipédia, a enciclopédia livre. (27 de Março de 2015). IBM Rational Unified Process. Fonte: Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process

 


Assine nossa Newsletter para receber por e-avisos sobre novas publicações na página e aguarde os outros artigo e compartilhe nas redes sociais para divulgação da página.

No responses yet

jul 03 2015

O maior problema não é o maior problema

Published by under BPM

O maior problema não é o maior problema

Mudança é difícil porque as pessoas se cansam e o que pode parecer resistência muitas vezes é exaustão. Psicólogos descobriram que o autocontrole exaure o estado emocional assim como os músculos se exaurem quando submetidos a esforços contínuos. As pessoas vivenciam situações de autocontrole a todo o momento – gerenciando a impressão que produzem em outras pessoas, lidando com temores, controlando gastos, tentando se concentrar em algo. Soma-se a isso a exaustão resultante do trabalho do dia a dia, da vida cotidiana, de processar um volume crescente informação e de fazer escolhas entre um número crescente de opções. Falta de clareza sobre o que se pretende fazer e onde se quer chegar é outro fator que gera resistência, assim como traumas vividos em situações anteriores de mudança influenciando a percepção sobre a mudança atual. Não adianta simplesmente dizer às pessoas “precisamos reinventar o negócio”, é necessário mostrar o que fazer, motivar e moldar o caminho. Se o escopo da mudança em andamento for maior do que do passado, as expectativas podem ficar ainda piores. Então, exaustão, falta de clareza e traumas são elementos-chave na composição da resistência à mudança. Muitas vezes, é necessário ocorrer uma crise para convencer as pessoas que elas estão de frente a uma catástrofe e não têm escolha, a não ser se mover.

Um problema difícil pode facilmente se tornar um enorme impedimento levando à procrastinação e paralisia. A melhor forma de endereçá-lo é reconhecer que ele não é o problema principal. Colocando-o de lado em vez de buscar sua solução permite à mente liberdade de ação para descobrir novas possibilidades. Eis alguns exemplos: toda vez que são discutidas soluções para o trânsito, acaba-se invariavelmente propondo alargamento de ruas, construção de pontes e túneis para comportar mais veículos. De tão focados em encontrar soluções, os técnicos esquecem que o problema principal não é mais ter por onde andar, mas o tamanho exagerado dos veículos. Qual é a necessidade de um automóvel com capacidade para transportar cinco passageiros se 75% a 100% do tempo transporta somente o motorista? Quando se diz que o problema é ter mais hospitais, por que não fazer com que menos pessoas precisem de um hospital? Quando se diz que é preciso limpar os rios, por que não deixar de poluí-los? Rios se limpam por conta própria. Se está difícil vender, por que não locar – montadoras locando carros em vez de vendê-los? Se está difícil manter um restaurante fixo, por que não torná-lo móvel –food trucks? Se idosos de um asilo estão apáticos, por que não instalar uma pré-escola que funcione no mesmo lugar? Ao mudar de perspectiva, expandem-se as possibilidades para que se veja aquilo que antes não era possível levando a novas ideias e soluções.

Business Transformation não se limita a melhorar eficiência, eliminar erros, fazer a mesma coisa um pouco melhor ou solucionar crises imediatas. É sobre como ter uma nova visão, repensar o negócio e redefinir o mercado. Em geral, os negócios tendem a evoluir para a perda de desempenho ao longo do tempo se nada importante for feito. Pequenas mudanças constantes com foco funcional têm conduzido as organizações à perda de eficácia. Como ponto de partida para iniciativas de transformação é necessário se colocar na posição de clientes, colaboradores, sociedade, meio ambiente e ecossistemas de negócio, e não somente na posição de gestores e acionistas, para entender a transformação sob novos pontos de vista. Sem isso, não se estará praticando transformação na intensidade requerida.

© José Davi Furlan

No responses yet

jul 01 2015

Razão e emoção na transformação

Razão e emoção na transformação

Com base no trabalho de Jonathan Haidt, os irmãos Dan e Chip Heath utilizam a narrativa do condutor, do elefante e do caminho para estabelecer uma estrutura de entendimento do processo de mudança. De acordo com os Heath, cada indivíduo possui um lado emocional, o elefante, e um lado racional, o condutor. Assim também vale para a organização como uma comunidade de pessoas. Para ser bem-sucedido na mudança, é preciso primeiramente direcionar o condutor, investigando e clonando aquilo que funciona, propondo ações que moldem comportamentos específicos e apontando o destino. Em seguida, motivar o elefante, fazendo as pessoas sentirem que são parte de algo maior, subdividindo o tamanho da mudança para que seja mais fácil de alcançar e cultivando um senso de propósito e entendimento do objetivo. Por fim, moldar o caminho, ajustando o ambiente, construindo hábitos e reunindo pessoas. Essa abordagem é consistente com a visão de Bertrand Russell em que o homem é racional na proporção que sua inteligência orienta e controla seus desejos.

Em um plano individual ou organizacional, algumas mudanças são abraçadas com entusiasmo enquanto outras repelidas. Somente conhecimento não é suficiente, exemplos disso são médicos que sofrem doenças em decorrência de seu estilo de vida e psicólogos com filhos desajustados. Para que a mudança ocorra, condutores necessitam mostrar para onde ir e como ir – o problema normalmente surge quando a razão discorda da emoção. Howard Gardner demonstrou por meio de pesquisa que somente se as emoções estiverem engajadas as pessoas serão capazes de efetivar mudanças reais. Embora a razão pareça liderar a emoção, tal como faz o condutor com o elefante, essa liderança é precária – o condutor é relativamente pequeno quando comparado ao elefante. Quando discordam sobre a direção a seguir, vence o mais forte. Quanto maior o número de escolhas possíveis e mais difíceis forem as mudanças, mais debilitada estará a relação.

A habilidade para mudança é baseada em prontidão e compreender pela razão não é o mesmo que estar preparado emocionalmente. As pessoas concordam racionalmente que devem prover melhores experiências para clientes, evitar desperdícios, não produzir com defeitos e não impactar o meio ambiente, mas não estão emocionalmente preparadas para fazer isso todos os dias. Condutores são ávidos por contemplar análise de problemas e identificar o que não funciona e dão menos importância aos elementos que funcionam e que poderiam ser replicados. Os aspectos negativos tendem a receber mais atenção que os positivos, pois é da natureza humana focar o que não funciona em vez de propagar o que funciona. O ruim frequentemente recebe análises detalhadas e pode levar à paralisia por análise, mas o que bom é tratado com superficialidade. Assim, o condutor tem de estar comprometido em suportar frustrações de curto prazo para obter compensações de médio e longo prazo. Quando esforços de mudanças são malsucedidos, normalmente é por culpa do elefante, que prefere obter compensações de curto prazo e conviver com frustrações de médio e longo prazo.

Transformação é resultado do acúmulo e intensidade de mudanças que se consegue empreender e, para serem bem-sucedidas, essas mudanças requerem que razão e emoção estejam em sintonia. Razão provendo direção e emoção provendo energia. Se a liderança está convencida da mudança, mas a equipe não, então haverá condução, mas sem energia. Se a equipe está convencida da mudança, mas a liderança não, então haverá energia, mas sem direção.

© José Davi Furlan

No responses yet

jun 29 2015

Resistir à mudança é perda de tempo

Published by under BPM

Resistir à mudança é perda de tempo

Todas despertam pela manhã no presente, mas muitas pessoas passam o dia no passado condicionadas a um modo de vida que não faz mais sentido. Quando vão ao trabalho, à escola ou às compras não se deslocam apenas no espaço, mas também no tempo. Atravessam o “túnel do tempo” e passam a revisitar crenças e hábitos de décadas passadas. Não significa que vivam no passado, mas que o passado vive nelas.

Em geral, as pessoas querem manter a mesma vida de sempre e a palavra “sempre” parece ser um par perfeito para a felicidade: “e viveram felizes para sempre”. É como a manifestação do princípio da inércia que todo corpo tende a continuar em seu estado de repouso ou movimento a menos que seja forçado a mudar. Não é diferente nas organizações como reflexo da psique humana individual em um plano coletivo. Apesar de o desejo humano oculto pelo congelamento do tempo, o fluxo de transformação da sociedade avança ininterruptamente e em velocidade crescente.

Se os momentos se vão, o que é inevitável, as pessoas ficam na esperança de um dia revivê-los e voltar ao que era. Freud explica que é da natureza humana o impulso inconsciente de repetir situações e comportamentos que foram positivos na história da vida, em particular quando se está em momentos de dificuldade. Os principais problemas diante de qualquer mudança significativa são as barreiras humanas, inércia e interesses ocultos, o ser humano não é previsível e a sociedade é um sistema vivo, mutável e instável. A resistência à mudança normalmente está conectada ao sentimento de risco de diminuição de importância e privilégios, e embora seja certo que a maioria tende a preferir uma vida rotineira e sem riscos, resistir à mudança é perda de tempo. As pessoas geralmente acreditam que as situações que vivem são inéditas e não se dão conta que a história é uma sequência de eventos que se repetem de outras formas. É o caso de novas tecnologias que sucessivamente causam algum grau de impacto quando são lançadas. Seneca no século I a. C. dizia que a luta do homem contra as mudanças e o fluxo da natureza, como resultado de ignorância e uma vida mal vivida, somente acaba por diminuir o tempo de sua existência. A cada instante o universo se transforma em algo diferente, não há como deter o fluxo.

Nas organizações, o pensamento corrente é primeiro planejar e depois executar, sem geralmente considerar uma etapa de aprendizado, prática e consolidação. Raramente uma transformação ocorre de maneira suave do início ao fim, mesmo contando com equipes otimistas, preparadas e motivadas. Em iniciativas de Business Transformation, surgem obstáculos, a motivação diminui e o otimismo cede espaço à depressão. Em muitas situações as mudanças têm desapontado, desperdiçando recursos e frustrando pessoas. Para criar um novo mundo o melhor a fazer não é lutar contra a realidade existente, mas construir uma nova realidade que torne a existente obsoleta. O obsoleto desaparece por conta própria. Não faz sentido gastar tempo e energia em mudar uma realidade repleta de entraves e obstáculos se ela foi criada para ser assim. O segredo do sucesso é focar toda a energia na construção do novo e não na luta contra o antigo.

© José Davi Furlan

25/06/2015

No responses yet

jun 26 2015

A Engenharia de Software com BPMS Par. 2

Parte 2 Modelos de Processos de Softwares

Antes de falar e entender o que é Processos de Softwares, devemos entender o que é a Engenharia de Softwares. Ela pode ser definida com a aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software. O estudo de abordagens e princípios a fim de obter economicamente softwares confiáveis e que executem de forma eficiente nas máquinas e ambientes reais.

Desta definição podemos elencar um conjunto de três elementos básicos fundamentais: métodos, ferramentas e procedimentos. Os métodos proporcionam os detalhes de “como fazer” para construir o software. As ferramentas dão suporte automatizado aos métodos. Os procedimentos constituem o elo entre os métodos e ferramentas fornecendo a sequência em que os métodos serão aplicados. O conjunto de etapas que envolve métodos, ferramentas e procedimentos são conhecidas como componentes do Ciclo de Vida de Software ou Processo de Software.

O Processo de Software pode ser definido como um conjunto de atividades necessárias para transformar os requisitos dos usuários em um sistema de software. Existem vários processos de software, contudo podemos citar um conjunto de atividades genéricas de todo processo de software: especificação, o que o sistema deve fazer e suas restrições; desenvolvimento, produção do sistema de software; validação, verifica se o software é o que o cliente deseja; evolução, mudanças no software e respostas as novas solicitações.

Um dos objetivos do Processo de Software é oferecer orientação quanto à ordem das atividades de uma equipe de desenvolvimento de software. Uma definição de quem faz o que e como. Desta forma cada pessoa envolvida na equipe de desenvolvimento entende o que precisa fazer para desenvolver o sistema e membros da equipe passam a conhecer as atividades de todos os outros membros. Os Processos de Softwares possuem diferentes abordagens e, com o tempo, constituiu-se modelos teóricos para estas abordagens.  Estes modelos são uma representação abstrata de um processo de software, que explica diferentes abordagens do desenvolvimento do software. Aqui citamos: Cascata; Prototipação; Evolutivo; Orientado a Reuso; Híbridos; Iterativo e Incremental (RUP); Espiral.

O RUP, abreviação de Rational Unified Process (ou Processo Unificado Rational), é um processo proprietário de Engenharia de software Iterativo e Incremental que fornece técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento. Ela usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente, contudo é um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala (Wikipédia, a enciclopédia livre, 2015, p. com adaptações). Algumas vertentes, ao utiliza-se de tais modelos, achavam sua formalização excessiva ou o consideram um processo moroso, mesmo depois de adaptações. Sugiram então outros modelos Interativos e Incrementais com o objetivo de tornar o desenvolvimento mais ágil e diminuir a documentação e controles que os modelos até então existentes utilizavam. Apareceram então as Metodologias ágeis como Scrum e Extreme Programming (XP).

Ambos Scrum e Extreme Programming (XP) pregam que a equipe complete alguma parte palpável de trabalho que seja entregável ao fim de cada iteração. Eles não perseguem o desenho do diagrama UML – (Unified Modeling Language – linguagem de modelagem que permite representar um sistema de forma padronizada) perfeito em ferramentas case, a escrita do documento de requisitos perfeito, ou a escrita do código que poderá acomodar todas as mudanças futuras imagináveis. Ao invés disso, equipes Scrum e XP focam em ter as coisas prontas. (Kniberg, 2007)

The Project Cartoon Beta

Figura 2 Project Carton .com (The Project Cartoon Beta, 2015)

Este problema se dá porque colaboradores não têm uma visão sistêmica da organização. A analogia seria a entrega de uma peça de um quebra cabeça, onde quem o está entregando não sabe qual é a imagem que deve formar ao final. Os colaboradores sabem descrever como é uma peça do quebra-cabeças, mas por não ter a visão da imagem que o quebra-cabeças tem que formar, não sabe descrever bem as “curvas” para que a peça se encaixe com outras e forme a imagem final, que seria o sistema de informação da organização ponta a ponta. O problema então não está restrito ao Modelo de Processo de Software e sim a cultura organizacional. Para mitigar este e outros problemas, abordagens sistêmicas foram propostas para a cultura organizacional. Todos os modelos têm suas vantagens e desvantagens, contudo o equilíbrio entre os modelos e a adaptabilidade para cada realidade organizacional passou a ser chave para resolver problemas que se apresentaram e ainda persistiam deis de a “Crise do Software”. Mesmo conseguindo o “equilíbrio” e “adaptabilidade” de algum modelo a realidade organizacional, a mesma, ao final, poderia ainda ter sistemas que não atendem todas as suas necessidades, e, muitas vezes, passa a desenvolver sistemas a altos cursos com poucos retornos reais.

Este problema se dá porque colaboradores não têm uma visão sistêmica da organização. A analogia seria a entrega de uma peça de um quebra cabeça, onde quem o está entregando não sabe qual é a imagem que deve formar ao final. Os colaboradores sabem descrever como é uma peça do quebra-cabeças, mas por não ter a visão da imagem que o quebra-cabeças tem que formar, não sabe descrever bem as “curvas” para que a peça se encaixe com outras e forme a imagem final, que seria o sistema de informação da organização ponta a ponta. O problema então não está restrito ao Modelo de Processo de Software e sim a cultura organizacional. Para mitigar este e outros problemas, abordagens sistêmicas foram propostas para a cultura organizacional.


Assine nossa Newsletter para receber por e-avisos sobre novas publicações na página e aguarde as outras duas partes deste artigo e compartilhe nas redes sociais para divulgação da página.

No responses yet

jun 23 2015

A Engenharia de Software com BPMS Par. 1

Published by under BPM

 Parte 1 Introdução

A Engenharia de Software visa sistematizar a produção, manutenção e evolução de Softwares para que os mesmos ocorram dentro dos prazos, custos e processos definidos. Por meio de princípios, métodos, tecnologias e processos continuamente aprimorados tenta apoiar as tarefas dos processos de softwares e mitigar os problemas enfrentados com a “Crise do Software”. Ao longo dos anos vários modelos para estes processos de software foram propostos.  A definição de Modelos de Processos de Softwares resolveu grande parte dos problemas que levaram a “Crise do Software”. Mesmo tendo uma forma de mensurar, controlar, especificar, etc. o produto final, software, não atendia as necessidades da organização. O problema geralmente se dava por que os próprios clientes não sabem bem o que pedir e o que queriam ao final. A analogia seria a entrega de uma peça de um quebra cabeça, onde quem o está entregando não sabe qual é a imagem que deve formar no final. O cliente sabe descrever como é a peça por alto, mas não tem uma visão geral e sistêmica da organização, o quebra cabeça. Mesmo entregando tudo conforme especificado, com custos e tempos acordados com os clientes, muitas vezes os mesmos não atendiam, ao final, as reais necessidades da organização.

Dilbert by Scott Adams, 2006 (Sganderla, 2014)



Figura 1 Dilbert by Scott Adams, 2006 (Sganderla, 2014)

As organizações, tendo em vista sua complexidade, processos, pessoas e informações geradas, em seus contextos por si só já são sistemas em consequência sistemas de informação utilizando-se ou não de ferramentas tecnológicas. Os produtos de softwares destinados a apoiar estes sistemas de informação devem estar construídos de forma a subsidiar os objetivos da organização. Ter uma visão clara destes objetivos, de seus processos e eliminar o que não é necessário ajuda a determinar de forma mais assertiva, os reais requisitos de software que o sistema de informação precisa ter para que as pessoas façam o que precisa ser feito e como deve ser feito.

Em paralelo a crise e após ela, as organizações, com o passar dos anos se tornam mais complexas e extensas. Para se aprimorar elas aplicavam técnicas para melhorar sua eficiência, eficácia e efetividade, posteriormente evoluindo para outros conceitos mais amplos para atender a seu aumento de complexidade e tamanho. Começou-se a pensar a organização de forma mais holística e com foco em seus processos de negócio ponta a ponta. Um pensar sobre a organização de forma ampla, e o contexto de sua inserção em um ecossistema. Começou-se a pensar em BPM (Business Process Management). O CBOK V3 defini BPM como “Disciplina gerencial que integra estratégias e objetivos de uma organização com expectativas e necessidades de clientes, por meio do foco em processos ponta a ponta. BPM engloba estratégias, objetivos, cultura, estruturas organizacionais, papéis, políticas, métodos e tecnologias para analisar, desenhar, implementar, gerenciar desempenho, transformar e estabelecer a governança de processos.” (ABPMP – Association of Business Process Professionals, 2013).

Com a adoção da cultura BPM, podemos ter a imagem geral do “quebra-cabeças”. Esta imagem é fundamental para o desenvolvimento, manutenção e evolução de sistemas de informação que atendem as reais necessidades da organização, diminuindo custos com manutenções, evoluções e desenvolvimentos desnecessários ou não significativos para a organização. Para apoiar o BPM, surgiram no mercado várias ferramentas e termos produzindo quase uma sopa de letrinhas. Dentre as existentes, destacamos aqui Business Process Analysis – BPA, cujas as características não vamos tratar aqui, mas tem algumas das suas funções descritas no artigo “Ferramentas para Escritório de Processos – Business Process Analysis – BPA” (Neponuceno, 2014) e o principal para este artigo, o  Business Process Management Suite ou System – BPMS que é um conjunto de sistemas que apoiam a automatização de partes da gestão de processos de negócio (modelagem, execução, controle e monitoração).

Neste ponto temos então a problemática que várias organizações enfrentam, de como fazer uso de ferramentas BPMS nas suas organizações, fazendo adaptação de seus Modelos de Processos de Software. Para isto vamos começar descrevendo os senários e Modelos de Processos de Softwares, das características de sistemas de informação concebidos com ferramentas BPMS e como conseguir adotá-las de forma adequada, levando em consideração as mudanças na cultura, tecnologia e nos paradigmas para que se consiga atender as reais necessidades da organização.


Assine nossa Newsletter para receber por e-avisos sobre novas publicações na página e aguarde as outras três partes deste artigo e compartilhe nas redes sociais para divulgação da página.

No responses yet

jun 22 2015

Amplitudes de transformação

Published by under BPM

Amplitudes de transformação

As organizações devem ser capazes de se reinventarem não apenas uma vez a cada década em meio a crises de substituição de seus dirigentes ou diminuição de desempenho, mas de forma permanente. No passado, as empresas buscavam defender e proteger o que tinham, mas hoje quanto mais defendem e protegem o que possuem, mais prisioneiras estarão de um modelo em obsolescência acelerada. Não são apenas os ciclos de vida de produtos e serviços que estão encolhendo, os ciclos de vida dos negócios também.

Transformações podem ocorrer em diferentes amplitudes. Na amplitude de menor impacto e risco, está a melhoria contínua que parte do modelo de estado atual para tratar mudanças incrementais utilizando normalmente abordagens disciplinadas (e.g. Lean Sigma, controle estatístico de processo, modelos de referência) em funções específicas do negócio. O objetivo é manter constância em mudanças pontuais para elevar continuamente o nível de desempenho das operações. O próximo nível de amplitude é o redesenho, que toma a perspectiva interfuncional e conduz a um repensar ponta a ponta das operações de negócio. Embora possa levar a mudanças significativas, as operações redesenhadas continuam baseadas nos mesmos conceitos da prática existente. Com maior impacto e risco, a amplitude de reengenharia toma a perspectiva de começar a partir do zero para promover uma mudança radical da operação existente. O objetivo é aplicar novas abordagens de negócio, modelos de gestão, técnicas e tecnologias, mas ainda sem romper com paradigmas existentes. Na extremidade mais ousada da amplitude de transformação, está a mudança de paradigma que desafia verdades e pilares e não se limita a redefinir o negócio, mas redefinir o mercado.

Mudanças de paradigma são caracterizadas por giros de 180º: em vez de o cliente ir à organização, a organização vai ao cliente; em vez de cobrar pelo serviço, oferece de graça; em vez de vender, loca; em vez de materializar, torna digital, em vez de operar em regime de escassez, torna abundante; em vez de elitizar, democratiza; em vez de padronizar, customiza; em vez de aumentar controle, provê autonomia; em vez de hierarquizar, opera em rede. Rompe com hábitos, costumes e tradições provocando desconforto e constrangimento com o estado anterior. Pedir para enviar um fax, utilizar um guia impresso de ruas ou mesmo fumar tornou-se um constrangimento porque o paradigma mudou. Os dias estão contados e não levará muito tempo para que o mesmo ocorra com veículos movidos a explosão e fumaça, agências bancárias, dinheiro em espécie e cartões de crédito em plástico.

Tabela – Características das amplitudes de transformação

Mudar paradigmas é um empreendimento audacioso e revolucionário e requer compromisso. É a amplitude mais intensa e disruptiva da transformação. Então, dado o risco de se avançar por terrenos inexplorados por que seguir adiante? Porque cada vez mais está se tornando uma questão de vida ou morte. Como o século 21 será marcado por mudanças sucessivas de paradigma em períodos de tempo cada vez menores, prolongar o tempo de vida do que já se tornou obsoleto é inútil. A exploração bem-sucedida de um ciclo de mudança de paradigma pode dar suporte a novos ciclos e perenizar a organização.

Aumentar receitas e reduzir custos, a fórmula clássica para maximizar rentabilidade não é mais suficiente no confronto com alternativas que quebram convenções e ortodoxias. Quando a Starbucks passou por dificuldades em 2007 e 2008, Howard Schultz, CEO, disse que estava claro para a companhia que redução de custos e melhorias operacionais em eficiência não seriam suficientes; a verdadeira transformação que necessitavam iria requerer uma nova forma de propiciar experiência aos clientes.

No responses yet

jun 18 2015

Ser o rolo compressor, fugir dele ou fazer parte da estrada

Published by under BPM

Ser o rolo compressor, fugir dele ou fazer parte da estrada

Transformações de negócio podem ser motivadas pela necessidade de adaptação ao meio ou pelo anseio de liderar e construir novas formas de geração de valor. O problema reside na velocidade das mudanças e capacidade de absorvê-las no ritmo necessário o que pode gerar desconforto e resistência. O custo de oportunidades perdidas no prazo de desenvolvimento de novos produtos e serviços, o tempo que esses terão de vida útil após o lançamento e a obsolescência que estarão sujeitos por ingresso de substitutos fazem encolher o ciclo de negócio e reduzir a possibilidade de retorno de investimento.

A cultura de Business Transformation inspira e alimenta a criação de práticas organizacionais que buscam causar mudanças para estabelecer novos patamares. Nesse ambiente de mudança, as organizações precisam aprimorar suas capacidades como resultado de um processo de transformação do negócio com novas estruturas e padrões de comportamento. Significa definir um propósito, engajar múltiplas perspectivas, enquadrar as questões, estabelecer o cenário e criar experiências. Enquanto as capacidades essenciais estabelecidas permitem atendimento às necessidades atuais, capacidades adicionais precisam ser criadas em resposta às novas oportunidades. As primeiras estão relacionadas ao pensamento linear e as últimas ao pensamento exponencial.

Transformações têm ocorrido com base em táticas incrementais ou radicais. Em termos de táticas incrementais, busca-se a realização progressiva de melhorias em partes da organização e em suas relações externas sem romper com as formas pelas quais transaciona com o ambiente – a mudança é vista como um processo evolucionário e progressista que possibilite a continuidade do negócio. Por definição, melhoria é tornar melhor o que já existe. Não é repensar, é apenas, melhorar. Quando se procura maneiras de fazer as mesmas coisas de forma mais rápida, com menor custo e maior eficiência, isso é melhoria. As novas soluções funcionam, não são caras e não causam ruptura porque alavancam o que já existe adicionando algo mais. Mas depois de algum tempo, o acúmulo de soluções incrementais alcançará um limite e uma transformação mais abrangente será inevitável. O fato é que melhoria, embora importante e necessária, está direcionada a tornar a organização mais eficiente naquilo que já faz, mas melhorias de 5% ao ano perdem relevância quando o mundo se reinventa e muda 100%. Quando chegar o momento de uma mudança mais profunda será preciso ter um desprezo saudável pelo impossível e tentar coisas que a maioria das pessoas não tentaria.

É importante ter em mente nas iniciativas de melhoria que não adianta melhorar aquilo que nem deveria mais existir.

A tática radical busca promover mudanças por meio de rupturas das práticas organizacionais tradicionais e passa a ser a única alternativa dependendo do tempo que o negócio estiver em vigor, de sua capacidade em fornecer resultados de forma eficaz, em executar de maneira rápida e a custos razoáveis, de sua capacidade de entrega e alcance, de sua competitividade e da própria estratégia de negócio. Em algum ponto o mundo terá evoluído e tecnologias e modelos mentais terão se movido para além da capacidade de solução com melhoria do que já existe. A concorrência ou alternativas de mercado estarão melhores ou maiores e o mercado irá demandar novas abordagens e soluções – concorrência não virá somente de grandes multinacionais, mas da quantidade infinita de novos empreendedores e tecnologias exponenciais que surgem todos os dias.

Na era da abundância as pistas estão superlotadas e o futuro pertence àqueles que agarrarem a oportunidade de criá-lo. Riqueza não advém somente de se aperfeiçoar coisas existentes e continuar fazendo as mesmas coisas. O século 20 experimentou longos períodos de exploração de paradigmas existentes, mas o século 21 irá experimentar mudanças sucessivas de paradigma com curtos períodos de exploração. “Quem não pensa daqui para frente não vai existir daqui para frente” diz Larry Page, “o que faz as organizações desaparecerem é a falta de foco no futuro”.

Figura – Século 20: foco em melhoria, século 21: foco em mudança de paradigma

Rupturas de modelo de negócio impõem riscos, mas capital de risco é uma das formas de geração de riqueza e objetivos de transformação radical devem ser seriamente considerados para assegurar sobrevivência de longo prazo. A única constante é a mudança e a taxa está acelerando: ou a organização causa uma ruptura em si mesma ou alguém no mercado o fará. Permanecer parado é sentença de morte.

A mudança de paradigma tem de ser vista como um movimento estratégico, um compromisso com o futuro do negócio e sua capacidade de sobreviver e prosperar. Em 2001, Tom DeMarco em seu livro Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency já dizia que “uma organização que pode acelerar, mas não mudar de direção terá o mesmo destino de um veículo nessas condições”. As consequências podem ser desastrosas.

No responses yet

jun 11 2015

O mundo em 2025 e além

Published by under BPM

O mundo em 2025 e além

Peter Diamandis em sessão plenária no The Government Summit em 2014 em Dubai foi categórico ao dizer que 40% das empresas Fortune 500 atuais não irão mais existir até 2025 pela inabilidade de se adaptarem às mudanças. A inteligência artificial poderá fazer mais e melhor do que seres humanos e a robótica autônoma e inteligente não é um futuro distante. Avanços na impressão 3D poderão tornar a manufatura independente de localização geográfica e o custo de mão de obra humana tenderá a zero. Criptomoedas (cryptocurrencies) terão o potencial de transformar a economia permitindo transferência de recursos financeiros entre duas partes sem a necessidade de aprovação ou envolvimento de uma terceira parte (bancos ou governo). O futuro também promete melhorias radicais na tecnologia de realidade aumentada com a introdução de interfaces gestuais e feedbacks sensoriais que fundem o mundo físico com informação digital.

O deslocamento do pensamento local e linear para o global e exponencial estende as possibilidades. Em um mundo local e linear as mudanças são graduais com efeitos razoavelmente absorvíveis, mas em um mundo global e exponencial as mudanças alcançam níveis inimagináveis com efeitos desnorteadores. Pode gerar tanto oportunidades quanto estresse e isso vale para qualquer segmento. Francis Maude, Ministro de Comércio e Investimento do Reino Unido diz que nenhum país tem o mesmo nível de despesas, mas todos enfrentam o mesmo desafio de orçamentos mais enxutos e diminuição de despesas. Somente com novas tecnologias será possível cortar custos e melhorar os serviços aos cidadãos. Estado não é lugar, mas presença – o cidadão não tem de enxergar órgãos públicos, mas serviços públicos. Maude enumera cinco princípios que podem ajudar a melhorar os serviços com redução de custos:

  • Transparência. Abrir acesso aos dados para que cidadãos possam fiscalizar as contas públicas e trazer melhorias nos níveis de austeridade
  • Controle rígido a partir do centro. Compartilhar atividades comuns para reduzir custo e estimular colaboração (criação de centros de serviços compartilhados)
  • Flexibilização. Quebrar o monopólio sobre os serviços públicos
  • Digitalização. Digitalizar os serviços públicos na maior extensão possível
  • Fortalecimento da cultura do serviço público. Prover flexibilidade aos servidores públicos para tentar coisas novas. Governos precisam estimular uma cultura que apoie inovação e tolerância ao erro

A longa busca por desenvolver máquinas com inteligência semelhante à humana se aproxima da realidade. Em um mundo em que robôs operados por Inteligência Artificial podem executar ações complexas e aprender como seres humanos, carros autônomos que podem tomar as ruas processando imagens de tudo que acontece e impressoras 3D que podem fabricar produtos funcionais com vários materiais, muitos empregos acabarão sendo substituídos por tecnologia e esse será um grande problema a ser resolvido. Como os governos irão enfrentar o desafio da perda de postos de trabalho humano ainda é uma questão em aberto.

Computação mais rápida, mais barata e mais poderosa está habilitando uma gama de tecnologias e convergências que levará a resultados sem precedentes. O mundo está testemunhando uma nova revolução industrial pela impressão 3D que permite fabricar motocicletas, próteses e até alimentos. No campo da medicina, avanços tecnológicos permitem prolongar a expectativa de vida e transformar a saúde – hoje, 100 anos de idade é o novo 60. De enxames de microrrobôs para automontagem de robôs modulares até exoesqueletos robóticos para aumento de força em seres humanos, aplicações utilizando robótica permeiam a indústria transformando a maneira como o trabalho é realizado. E várias outras frentes em expansão nos campos da energia, água, transporte e produção de alimentos que podem levar o mundo a uma era de abundância.

Mas o caminho até a criação de um admirável mundo novo possui muitas curvas e pistas escorregadias. David Wood et at. em Anticipating 2025: A guide to the radical changes that may lie ahead, whether or not we’re ready diz que a trajetória até 2025 não estará livre de riscos e crises:

  • Escassez de água, alimentos, energia e minerais raros (o que pode parecer paradoxal pelo potencial das novas fontes renováveis, mas refletindo a falta de maturidade dessas fontes)
  • Estresse ambiental com aumento do caos climático e disputas sobre responsabilidades e ações corretivas
  • Estresse do sistema financeiro que compartilha com o meio ambiente as mesmas características de alta complexidade, má compreensão, fraca regulamentação e sujeito a pontos de inflexão e mudanças abruptas
  • Aumento da marginalização de pessoas que serão incapazes de compartilhar a magnitude da riqueza propiciada pela evolução tecnológica pela perda de empregos
  • Risco de ataques cibernéticos que podem paralisar a infraestrutura tecnológica

Pelo lado otimista a confiança vence o medo, o aberto vence o fechado, a abundância vence a escassez e o vencedor leva tudo. Pelo lado pessimista existem muitas incertezas e obstáculos em rota para um futuro promissor. Tecnologias exponenciais terão um impacto transformacional de longo alcance representando oportunidades sem precedentes e ameaças existenciais. Esse impacto é indiscutível e ninguém mais pode ficar em estado de alienação ou negação.

© José Davi Furlan

11/06/2015

No responses yet

Next »