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.
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.
Figura 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.