jul 01 2015

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

Published by under BPM,Comportamento,Processos

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

Tags: ,

No responses yet

jun 30 2015

A Engenharia de Software com BPMS Par. 3

Published by under Sem categoria

Parte 3 Sistemas de informação concebidos com ferramentas BPMS

Antes de continuar, vamos definir o que é um BPMS. BPMS (Business Process Management Suite) é um conjunto de ferramentas automatizadas que proveem suporte a BPM. Possibilita a modelagem, execução, controle e monitoramento dos processos de forma automatizada. Define a arquitetura e infraestrutura tecnológica necessária para a modelagem do negócio, a execução em produção dos fluxos de trabalho, a aplicação de regras de negócio, utilização de dados corporativos, a simulação de cenários e operação de outras aplicações do ambiente BPMS. (ABPMP – Association of Business Process Professionals, 2013)

Como as capacidades de BPMS mudam constantemente na medida em que fornecedores adicionam novas funcionalidades em um esforço competitivo, algumas versões do conjunto de funcionalidades podem incluir:

  • Modelagem de processos
  • Simulação de novos desenhos
  • Definição e gerenciamento de regras
  • Reportes de desempenho
  • Geração de aplicações
  • SOA /EAI
  • ESB

bpms-3

Figura 3 Ferramentas BPMS

BPMS cobre o ciclo de vida completo de gerenciamento de processos: modelagem e desenho de processos, implementação e execução, monitoramento e controle, análise e avaliação de desempenho de processos. Ele pode incluir capacidades de tecnologias previamente concebidas para necessidades específicas, tais como imagens, gerenciamento de documentos e conteúdo, colaboração, fluxo de trabalho, roteamento e atribuição de trabalho, gerenciamento e execução de regras, gerenciamento de metadados, Data Warehousing – DW, BI, integração de aplicação e gerenciamento de comunicação.

A automação de processos com o uso de BPMS cria um tipo diferente de solução se comparada às tradicionais linguagens de programação. Na automação, cada atividade do processo se transforma em uma pequena aplicação que é disponibilizada ao ator responsável pela sua execução. O ator recebe um contexto de trabalho com as informações que necessita para realizar a sua atividade e com as respectivas regras de negócio implementadas. A sequência do processo é controlada pelo fluxo desenhado no BPMS. O controle sobre a interação humana é definido por meio de formulários que informam ao BPMS como construir a tela de cada atividade e através de regras que determinam como os dados devem ser tratados e quais as opções que o ator possui para concluir a atividade. (ABPMP – Association of Business Process Professionals, 2013)

Modelos de processos e modelos de regras juntamente com a definição de telas e formulários no BPMS fornecem as especificações necessárias para gerar aplicações. As formas como eles são executadas pelos BPMS permitem uma abordagem diferente de negócio e da área de Tecnologia da Informação. Usando ferramentas de banco de dados externo, a geração de aplicação em BPMS também pode prover suporte a alto volume de uso e armazenamento de dados. (ABPMP – Association of Business Process Professionals, 2013)

O uso de um BPMS também representa um paradigma para o desenvolvimento e geração tradicional de aplicações dentro das áreas de Tecnologia da Informação. Historicamente, a criação de aplicações usando métodos e ferramentas tradicionais tem seu desenvolvimento iniciado pela análise e modelagem de dados, geralmente vinculado ao modo como os dados serão armazenados em um banco de dados. Com o BPMS, o desenvolvimento ocorre em um novo paradigma chamado de modelagem de sistemas orientada a processos, que considera a definição de requisitos de software a partir do levantamento das necessidades de processos. (ABPMP – Association of Business Process Professionals, 2013)

BPMS fornece um novo tipo de ambiente de negócio que integra negócio e tecnologia da informação. O termo “ambiente” é empregado para descrever a operação resultante da utilização de BPMS, pois gera aplicações e fornecem o suporte às operações de negócio na sua execução. Por meio de modelos de negócio, o contexto para a operação em BPMS é definido como uma estrutura passo a passo. A partir desses modelos são definidos requisitos para utilização de dados e sistemas legados. Interfaces fornecem pontos de integração e requisitos de dados a serem utilizados. Regras definidas e adicionadas ao desenho fornecem a lógica ou “a inteligência” para execução das operações. O BPMS pode, então, simular cenários possíveis e avaliar resultados com base em testes que espelham a situação real na qual a aplicação será usada.

Um BPMS permite considerar aplicações transacionais e também trabalhar aplicações de gerenciamento, aplicações que controlam o fluxo de trabalho e como esse trabalho é feito ou deveria ser feito. Isso inclui a atribuição, acompanhamento, balanceamento da carga de trabalho, identificação de erros, gerenciamento de desempenho, reportes, entre outros.

Interfaces dos modelos de processos para sistemas legados podem ser introduzidas para “chamar” outras aplicações e formar uma série de tarefas automatizadas. Embora um tipo de interface seja necessário, o uso de arquitetura orientada a serviço (SOA) com adaptadores e aceleradores de integração corporativa de aplicação (EAI) torna a interface nesse ambiente mais fácil e, consequentemente, reduzem tempo e risco. Controles especiais de gerenciamento também podem ser adicionados aos modelos para controlar o volume do fluxo de trabalho, roteamento de trabalho e aviso de atraso. Esses devem ser baseados em padrões, mas o BPMS pode prover suporte aos diversos padrões da organização.

Arquitetura Orientada a Serviços (SOA – Service Oriented Architecture) é um conjunto flexível de princípios de desenho de infraestrutura usados no desenvolvimento de aplicações e integração de sistemas. Ela é uma abordagem de arquitetura corporativa para vincular recursos sob demanda, permitindo a criação de serviços de negócio interoperáveis que podem ser reutilizados e compartilhados entre aplicativos.

Por meio do uso de serviços, funcionalidades próprias de cada aplicação legada são disponibilizadas para uso por outras aplicações, processos ou serviços. “Chamadas” SOA para dados em sistemas legados ou outros aplicativos são passadas para adaptadores EAI (Enterprise Application Integration) e traduzidas para chamada ou atualização de dados em linguagens de programação mais tradicionais que operam dentro do ambiente técnico dos aplicativos.

bpms-4

Figura 4 SOA e o processo de negócio

Isso permite que as chamadas e atualizações de dados sejam construídas seguindo um formato único e depois entregues (muitas vezes usando um ESB – Enterprise Service Bus – que fornece uma camada de abstração ou “barramento” entre diferentes padrões) para uma aplicação em um formato padrão, o que facilita a conexão entre as aplicações. Entretanto, esse não é um processo simples e embora o uso de SOA, EAI e ESB simplifiquem a necessidade de obter, mover, entregar e formatar dados, ainda demanda um trabalho especializado. Isso fornece um grupo integrado de módulos com baixo acoplamento que são disponibilizados em um repositório de serviços para serem utilizados. Além de criar esse tipo de objeto e serviço de biblioteca, SOA fornece um formato e fundação para notificar clientes desses serviços sobre sua disponibilidade.

Para implementar SOA é necessário definir seus objetivos, uso e padrões internos. Ao criar estratégias SOA é importante identificar os benefícios que são necessários e adotar padrões, técnicas, métodos e conceitos necessários para oferecer esses benefícios. É também necessário se certificar que a área de Tecnologia da Informação e o negócio possuem um roteiro claro de como a estratégia SOA será implementada e qual o papel de cada um dos participantes. No entanto, mesmo com uma visão clara, uma estratégia e um plano, o gerenciamento da implementação irá demandar financiamento e supervisão constante para assegurar que a nova abordagem está no caminho certo.

SOA requer que a organização considere e explicitamente documente quais recursos serão acionados por demanda, por exemplo, processos, mensagens, entidades e visões de dados, armazenamento de dados, regras e eventos. O maior desafio da governança para SOA é gerenciar o ciclo de vida de serviços, incluindo concepção, especificação, desenvolvimento, testes, implementação, direito de uso e alteração, controle de acesso, operação e, finalmente, desativação do serviço.

Embora BPMS possa produzir vantagens, também existem riscos associados a qualquer esforço de automação. O risco mais significativo é que se pode desenvolver um falso sentimento de segurança ao supor que só porque se está automatizando um processo, ele é melhor. Como em qualquer adoção de sistemas, automatizar processos mal feitos não resultará em melhores práticas de negócio. A forma como a ferramenta ou conjunto de ferramentas será utilizada será impulsionada pela visão de negócio e a capacidade de mudança da organização. (ABPMP – Association of Business Process Professionals, 2013)

 

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.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

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

Tags: ,

No responses yet

jun 26 2015

A Engenharia de Software com BPMS Par. 2

Published by under BPM,Processos,TI

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.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

No responses yet

jun 25 2015

Big Ideas: How Big is Big Data? (Portuguese)

Published by under TI

Tags:

No responses yet

« Prev - Next »