BPM-BPMS Tadeu Cruz.pdf

2a edição Tadeu Cruz

Copyright© 2010 por Brasport Livros e Multimídia Ltda. Todos os direitos reservados. Nenhuma parte deste livro poderá ser reproduzida, sob qualquer meio, especialmente em fotocópia (xerox), sem a permissão, por escrito, da Editora. 1a edição: 2008 2a edição: 2010 Editor: Sergio Martins de Oliveira Diretora Editorial: Rosa Maria Oliveira de Queiroz Assistente de Produção: dos Anjos Martins de Oliveira Revisão: Maria Helena A.Marina M. Oliveira Editoração Eletrônica: Abreu’s System Ltda. Capa: Trama Criações Técnica e muita atenção foram empregadas na produção deste livro. Porém, erros deitação dig e/ou impressão podem ocorrer. Qualquer dúvida, inclusive de conceito, solicitamos enviar mensagem para [email protected], para que nossa equipe, juntamen te com o autor, possa esclarecer. A Brasport e o(s) autor(es) não assumem qualquer responsabilidade por eventuais danos ouperdas a pessoas ou bens, srcinados do uso destelivro. Marcas Registradas – Todos os nomes, todas as marcas registradas e todos osdireitos de uso, de produtos ede serviços, citados nestelivro pertencem aos seus respectivos proprietários. Todos os Direitos Autorais foram citados, todas as fontes de dados e informações foram referenciadas e todos os créditos foram dados. Se houver alguma omissão ela não terá sido intencional.

Dados Internacionais de Catalogação na Publicação (CIP) (Câmara Brasileira do Livro, SP, Brasil) Cruz, Tadeu BPM & BPMS : Business Process Management & Business Process Management Systems / Tadeu Cruz. -- 2. ed. -- Rio de Janeiro : Brasport, 2010. Bibliograa. ISBN 978-85-7452-439-9 1. Administração - Avaliação 2. Controle de processos - Processamento de dados Administração 3. Mudança organizacional - Estudo de casos 4. Negócios - Processamento de dados 5. Reengenharia (Administração) 6. Tecnologia de informação 7. Workow - Administração I. Título. 10-02363

CDD-658.4063 Índices para catálogo sistemático: 1. BPM & BPMS : Processos de produção : Reengenharia : Administração de empresas 658.4063

BRASPORT Livros e Multimídia Ltda. Rua Pardal Mallet, 23 – Tijuca 20270-280 Rio de Janeiro-RJ Tels. Fax: (21) 2568.1415/2568.1507 e-mails: [email protected] [email protected] [email protected] site: www.brasport.com.br Filial Av. Paulista, 807 – conj. 915 01311-100 – São Paulo-SP Tel. Fax (11): 3287.1752 e-mail: [email protected]

Para Wanda, eterna companheira! Aonde quer que vá e para sempre, muito amada!

O Autor

Tadeu Cruz, Prof. M.Sc, é Administrador de Empresas e Filósofo. Especialista em Engenharia de Sistemas e em Análise e Melhoria de Processos de Negócio. Mestre em Engenharia de Produção COPPE-UFRJ. Auditor certicado pelo IRCA (International Register of Certicated Auditors), Inglaterra, para implantação de sistemas da qualidade baseados nas normas ISO 9000. Participou de mais de 100 cursos de extensão e especialização na Itália, França, Estados Unidos, Alemanha, Inglaterra, Argentina e México. Possui 34 anos de experiência em Tecnologia da Informação e 22 anos em Qualidade e Desenvolvimento Organizacional. Trabalhou em empresas nacionais e multinacionais e como consultor de Tecnologia de Informação e de Gerência de Processos e Projetos no Uruguai, Chile, Argentina, Alemanha e Estados Unidos. Autor de 16 livros. Professor de cursos de pós-graduação de diversas universidades, entre elas: SOCIESC de Joinville, Santa Catarina; SENAC São Paulo; PUC-Minas; UNIVEM - Marília e Academia de Polícia do Estado de São Paulo - ACADEPOL. É consultor de análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos negócio eIndustriais, ministra osMapeamento seguintes cursos: Gestão deModelagem Processos, Gestão de de Processos de Processos, de Processo, Simulação de Processos, Gestão de Negócios, Gestão Estratégica de Processos de Negócio, Desenvolvimento Organizacional, Estatística para Processos de Negócio, Logística, Business Process Outsourcing, Knowledge Process Outsourcing e Gerência do Conhecimento. É membropesquisador do Grupo de Estudo dos Aspectos Culturais, Tecnológicos e

VIII BPM & BPMS

Estruturais das Organizações para Implantação da Gestão por Processos FEA-USP e do Laboratório de Sistemas Avançados de Gestão da Produção (SAGE) COPPE-UFRJ. É coautor do Workow Handbook 2006, editado por Layna Fischer - Workow Management Coalition (WfMC - USA). Currículo completo em http://lattes.cnpq.br/0266993615909643 Contatos: www.trcr.com.br - [email protected]

Prefácio da 1a edição

Provocante, proveitoso, delicioso: assim é o novo livro de Tadeu Cruz. Com a segurança de quem tem muita experiência no tema e já publicou várias outras obras, o autor não perde tempo com concessões a formalismos de estilo: vai direto ao ponto. Anal, quantos livros arriscam-se a assumir uma postura crítica diante das inovações em TI aplicada às organizações? Pouquíssimos. Tadeu não hesita em enumerar restrições e diculdades que levam a fracassos, mas ainda assim demonstra sua conança na contribuição doBPMS para as organizações. Começa, acertadamente, pelo essencial: o que importa não é esta ou aquela técnica, mas a mudança organizacional. Leia-se: a mudança organizacional favorável! Pois, como o autor acentua, inúmeras vezes ela vem, mas numa direção inteiramente indesejável... É o que o Tadeu chama de Desorganização Informacional. Outro aspecto notável do livro: os conceitos mais técnico s de TI aparecem apenas na medida do necessário. Isto permite que o livro seja apreciado mesmo por prossionais ou pesquisadores que não possuem formação em software. De fato, o importante é entender que o Business Process Management é uma novidade e não o é. Sem dúvida, dá continuidade a tendências que surgiram já há mais de 20 anos, como o modelo japonês ou, depois dele, a reengenharia. Mas ao mesmo tempo renova a visão de processos, aprofundando

X BPM & BPMS

a maneabilidade dos sistemas de gestão e usando de forma mais sensata as TI. É neste ponto que o livro de Tadeu pode contribuir fortemente. O leitor terá uma abordagem da gestão de processos que a literatura de divulgação, acrítica, não pode oferecer, mas que, com toda certeza, é a que melhor convém à obtenção de bons resultados práticos. Quando a isto se soma uma leitura leve e agradável, não há mais o que pedir.

Rogerio Valle Coordenador SAGE (COPPE/UFRJ)

Apresentação à 2a edição

Durante esses quase 18 meses em que o livro esgotou sua 1 a. edição recebi muitos e-mails. Foram de consultas, tanto de prossionais quanto de estudantes dos mais diversos cursos e disciplinas, de congratulações, de críticas positivas, que me ajudaram a aprimorar minhas ideias e a resolver minhas dúvidas, e nenhum de reclamações, embora tenham existido algumas num grupo de relacionamento na Internet sobre a abordagem generalista do livro. Quero agradecer a todas e todos. Tanto aos leitores que me escreveram do Amazonas, ao Rio Grande do Sul, como às criticas. Foram e serão sempre bem-vindas! Eu concluí que o livro cumpriu seu principal objetivo: o de desmisticar BPM & BPMS. Quis que ele fosse uma visão geral sobre esses dois ambientes, BPM & BPMS, sem ser supéruo. Quis que ele tratasse de mapeamento, análise, modelagem e gerenciamento de processos como única forma de controle da desorganização informacional e que enfatizasse que nenhuma tecnologia, por melhor e mais avançada que seja, tem capacidade de organizar o caos informacional em que todos nós nos encontramos. Confesso que esperava de fabricantes e fornecedores que leram o livro (eu sei que sim), uma postura mais atual e preocupada com a desorganização informacional, mas infelizmente todos sem (ou quase) exceção continuam

XII BPM & BPMS

vendendo TI com falsas promessas de melhoria de produtividade (eciência + ecácia) sem a devida preocupação com processos de negócio. Confesso, também, que as organizações, aqui sim, salvo raras exceções, continuam se preocupando muito pouco com o tema desorganização informacional e acreditando que TI as redimirá de todos os males da desorganização informacional, que para falar a verdade elas nem sabem que desta enfermidade padecem. Por m, pelas inúmeras notícias que me chegam, constato que há ainda muito fracasso e dinheiro sendo jogado fora em projetos de análise, modelagem e gerenciamento de processos realizados com base EXCLUSIVAMENTE em uxogramas. E todos que me conhecem sabem que uxograma não documenta processos. Fazer o quê? Por tudo isso, aqui está a 2ª. edição, e a minha renovada crença de que é possível trabalharmos sem estresse, com qualidade e alta produtividade, basta querermos enfrentar a desorganização informacional sem pirotecnia e sem acreditarmos em falsas promessas. Muito obrigado!

Tadeu Cruz

Sumário

Introdução ............................................................................................................. 1 Algumas Palavras sobre Cada Capítulo ........................................................... 8

1. As (R)Evoluções de TI ................................................................................. 11 As “Ondas” Chamadas Tecnologias da Informação ........................................ 11 História Resumida dos Computadores ................................................... 11 O Vai-e-vem das Ondas de TI ................................................................. 15 A Evolução do Hardware ................................................................................. 22 Como as Ondas de TI se Formam .......................................................... 22 A Segunda Fase da Segunda Geração .................................................. 29 A Terceira Geração ................................................................................. 31 Resumo das Duas Fases da Computação Comercial ............................ 32 A Computação Distribuída............................................................................... 33 O Mito Chamado Ofce Automation ................................................................ 37 Os Pacotes Ofce Automation ................................................................ 40 O Papel dos Editores de Textos na DoI .................................................. 41 O Papel das Planilhas Eletrônicas na DoI .............................................. 44 O Papel de Outras Tecnologias na DoI ................................................... 46

2. A Desorganização Informacional .............................................................. 50 A Doença e seus Sintomas ............................................................................. 51 Exemplos de Desorganização Informacional .......................................... 52 Efeitos da DoI .................................................................................................. 54 Evolução da Desorganização Informacional ................................................... 60

XIV BPM & BPMS

3. O Contexto Histórico CSCW ...................................................................... 63 CSCW ou BPM?.............................................................................................. 64 Trabalho Cooperativo por Meio dos Processos de Negócio? ......................... 65 O Que É BPM?................................................................................................ 66 O Modelo Ainda Inexistente ............................................................................ 70 Modelo Genérico do BPMS..................................................................... 73 Algumas Palavras sobre Estes Modelos................................................. 83 BPMS, Um Novo Nome para Workow?.............................. ........................... 84 Facilitadores do Modelo BPMS ............................................................... 86 Para Escrever Este Livro................................................................................. 87 Softwares ................................................................................................ 87 Livros....................................................................................................... 88

4. BPMS ................................................................................................................ 90 BPMS e os Processos de Manufatura ............................................................ 92 Processos de Manufatura Contínua........................................................ 93 Processos de Manufatura Discreta ......................................................... 93 Integrando BPMS (Workow) a um ERP......................................................... 96 Workow Embutido ou Autônomo?.............................. ........................... 97 Exemplo 1 ............................................................................................. 103 Exemplo 2 ............................................................................................. Integrando Workow à Manufatura Discreta....................... ..........................103 103 Preocupações Essenciais ..................................................................... 106 Exemplo Detalhado ............................................................................... 107 A Descrição do Processo ...................................................................... 109 Explicação Importante........................................................................... 112 Softwares para Processos de Negócio ......................................................... 113 Computer-Supported Cooperative Work ............................................... 116 O Surgimento do BPMS ................................................................................ 117 Tecnologias Envolvidas com BPMS .............................................................. 121 Ferramentas para Modelagem de Organizações.................................. 123 Ferramentas para Modelagem de Processos ....................................... 126 Ferramentas para Estatística ................................................................ 126 Ferramentas para Simulação ................................................................ 129 Ferramentas Gerenciamento de Regras de Negócio ................... 131 Aplicações de BPMpara ....................................................................................... 132 Ferramentas para Monitoração de Processos ...................................... 134 Ferramentas para Desenvolvimento de Software ...... ........................... 134 Ferramentas EAI (Enterprise Application Integration) ........................... 135 Ferramentas SOA (Service-Oriented Architecture) ............................... 140 Background & Foreground Processes .......................................................... 147 Foreground Processes .......................................................................... 149

Sumário XV

Background Processes ......................................................................... 151 Ferramentas para Gerenciamento do Ambiente Workow........................... 153 Servidores de Aplicações .............................................................................. 154 Linguagens BPMS......................................................................................... 154 1o Grupo. Linguagens generalistas ...................................................... 154 2o Grupo. Linguagens especialistas ..................................................... 154 ERP, CRM e Outros Softwares e Aplicações................................................ 155 Data Warehouse e BI .................................................................................... 155 Conclusão .....................................................................................................

5. AMOP é uma Saída? ................................................................................... 156 O Caso da Empresa de Manutenção Aeronáutica ........................................ 158 Níveis de Documentação de Processos ....................................................... 160 Modelos de Processos de Negócio ............................................................... 165 O Modelo DOMP ................................................................................... 165 The MIT Process handbook .................................................................. 167 The Supply-Chain Operations Reference Model (SCOR)..................... 168 Modelo de Processo de Negócio do NP2TEC-UNIRIO ........................ 170 Modelo Genérico de Processo de Negócio........................................... 171 Metodologias para Processos de Negócio .................................................... 172 Metodologias para AMOP ..................................................................... 174 DOMP ................................................................................................... 178 Sobre BPO e KPO......................................................................................... 183 Business Process Outsourcing - BPO .................................................. 185 Knowledge Process Outsourcing - KPO ............................................... 186 Sobre a SOx e Governança Corporativa....................................................... 188 Principais Desaos da Lei Sarbanes-Oxley .......................................... 189 Governança Corporativa ....................................................................... 190

6. Ciclos de Vida BPM e BPMS .................................................................... 192 Ciclo de Vida do BPM ................................................................................... 192 Fases da Metodologia ................................................................................... 194 Ciclo de Vida do BPMS ................................................................................. 199

7. Mudança é Tudo que Existe ..................................................................... 205 Gerenciando a Mudança ............................................................................... 207 Pontos de Atenção ........................................................................................ 209 Rejeição ................................................................................................ 209 Boicote .................................................................................................. 212 Aceitação .............................................................................................. 213 Cooperação........................................................................................... 213

XVI BPM & BPMS

8. Analistas ........................................................................................................ 215 Os Três Níveis de Detalhamento da Documentação do Processo ............... 216 1o Nível .................................................................................................. 216 2o Nível .................................................................................................. 217 3o Nível .................................................................................................. 217 Exemplos de Níveis de Documentação de Processos.................................. 218 O Analista de Processos ............................................................................... 219 O Analista de Workow ................................................................................. 222 O Analista de BPMS ...................................................................................... 223 O Arquiteto de SOA (SOA Architect) ............................................................. 223 Conhecimentos e Competências .................................................................. 225

Palavras Finais ................................................................................................. 229 Anexo I – Principais Fabricantes de BPMS .............................................. 231 Anexo II – BPMS .............................................................................................. 235 Anexo III – Relação dos Vendedores de BPMS........................................ 249 Anexo IV – Linguagens Generalistas BPMS................... .......................... 251 Elementos Business Process Diagram ......................................................... 253 Referências Bibliográcas ............................................................................ 259

Índice Remissivo ............................................................................................. 265

Introdução

Os problemas provocados pelas constantes e aceleradas (r)evoluções nas e das Tecnologias da Informação e as provocadas por estas na sociedade, parecem (eu disse parecem) ser maiores do que os benefícios que estas mesmas (r)evoluções nos trazem e trazem às organizações e à sociedade como um todo. Obviamente, para qual dos lados vão pender (para o lado do problema ou para o lado da solução) cada uma destas (r)evoluções dependerá da escolha e do uso que cada um de nós zer das tecnologias advindas com estas (r)evoluções. Ou seja, a princípio não existe tecnologia boa, nem tecnologia má, mas uma ou outra pelo uso que zermos delas. O certo é que as (r)evoluções de TI sempre desencadeiam uma série de fenômenos que afetam tanto nossa vida prossional quanto a particular. Alguns destes fenômenos são causas, outros são efeitos, e há também aqueles que são causa e efeito ao mesmo tempo. Cada um destes tipos de fenômenos ligados às (r)evoluções das Tecnologias da Informação serão tratados por mim neste livro por meio de exemplos, casos, ideias, conceitos e conclusões com o precípuo objetivo de discutir o papel das tecnologias Groupware e, em especial, a mais “nova” delas: o software chamado BPMS (Business Process Management System). Em decorrência das (r)evoluções de TI fomos e, a cada nova (r)evolução, somos acometidos de uma doença ainda pouco conhecida como enfermidade, ainda mal explorada e à qual dei o nome de Desorganização Informacional, cuja abreviatura é DoI. Seus sintomas vão da insegurança que provoca

2 BPM & BPMS

em nós por lidarmos com tantas e tão novas e diferentes tecnologias ao estresse físico-emocional (psicossomático) causado pela superexposição a elas. Vão da perda de controle sobre a capacidade de discernir o que é bom para nossa organização e para nós mesmos ao desenvolvimento da infobia (medo da informação), talvez o mais (in)visível e perigoso de todos os sintomas denunciadores desta enfermidade. Os efeitos da Desorganização Informacional podem ser visíveis, invisíveis e até mesmo podem estar mascarados, resultantes de outras enfermidades organizacionais, mas são, a cada dia, mais devastadores. A Desorganização Informacional teve uma acentuada evolução ao longo das últimas quatro décadas ou, para ser mais preciso, a partir do início da computação comercial, entre os anos 50 e 60. Embora afete principalmente nossa vida prossional, seus “tentáculos” também alcançam nossa vida particular, pois, salvo raras exceções, da hora que acordamos à hora que dormimos estamos em permanente contato com as Tecnologias da Informação e, por conseguinte, sendo afetados por elas. Alguns podem dizer que a globalização que vivemos hoje é a causa da SDoI1; ou seja, que ela é a causa desta descontrolada quantidade de dados e informações existentes hoje. Entretanto, para mim, a globalização não o é. No máximo a globalização, de forma tautológica, pode ser acusada de globalizar a Desorganização Informacional, numa espiral viciosa. Muitas empresas fabricantes de Tecnologias da Informação já reconhecem e até parecem estar preocupadas em criar produtos que possam, em tese, minorar os efeitos da DoI. Também muitos especialistas já se preocupam ou começam a se preocupar com os efeitos nocivos que toda esta “overdose” de TI, causadora de uma overdose de dados e informações, tem provocado nas pessoas e por extensão nas organizações nas quais as pessoas trabalham. Por exemplo, a IBM, depois de lançar e-business e a estratégia On Demand, rendeu-se evidências e anunciouem produtos controlar o que ela mesma chama,às nas suas propagandas jornais para e revistas do mundo todo, de Information Anarchy!

1. SDoI, Síndrome da Desorganização Informacional.

Introdução 3

Ainda que não soubéssemos (você e eu) ser a DoI uma realidade, apenas por meio de propagandas como esta seria possível imaginar o grau de Desorganização Informacional a que chegamos ao vermos por parte de uma das maiores fabricantes de Tecnologias da Informação tão explícito reconhecimento desta descontrolada situação. Absurdamente paradoxal, não é? Eu penso que sim. As (r)evoluções das Tecnologias da Informação contribuíram para a Desorganização Informacional porque, como nenhuma outra tecnologia criada pelo homem até então, ela consegue operacionalizar uma espiral ascendente e autorregenerativa cujo propósito, inconfessável, é o de criar mais e mais Desorganização Informacional; num movimento onde mais tecnologia gera mais Desorganização Informacional e mais Desorganização Informacional gera (a necessidade de) mais tecnologia (e vendas crescentes), que pretensamente foram criadas para ajudar a organizar a Desorganização Informacional. As (r)evoluções de TI são boas ou são ruins? Depende... Alguns vão dizer que são boas, maravilhosas, porque propiciaram e propiciam cada vez mais a disseminação do conhecimento e “popularizam” as Tecnologias da Informação, possibilitando a milhões de pessoas terem seu próprio computador e acesso instantâneo ao conhecimento gerado no mundo todo. Outros, entretanto, dirão que as (r)evoluções de TI são péssimas porque desorganizaram e desorganizam os meios produtivos tradicionais (descendentes diretos da Revolução Industrial) criando um novo tipo de trabalhador: o do conhecimento2 em detrimento do trabalhador do chão de fábrica, além de ter possibilitado o surgimento de crimes antes inimagináveis até mesmo por grandes romancistas do gênero. Como em todas as questões colocadas à humanidade, há os que vão defender as (r)evoluções de TI e há os que vão condená-las; o lado bom e o lado ruim; e há os que são e serão contra ( unabombers) e os que são e serão

2. Trabalhador do Conhecimento, termo criado por Peter Drucker para diferenciar os prossionais que atuavam, ou ainda atuam, nas manufaturas tradicionais (produtos tangíveis) dos que trabalham nas novas indústrias da informação (produtos intangíveis) da Era do Conhecimento.

4 BPM & BPMS

a favor, sem querer ser maniqueísta, ou reconhecendo que a matéria seja intrinsecamente má. Não me cabe emitir juízo de valor, até porque, atuando há trinta (e muitos) anos na área, eu estaria “cuspindo no prato que comi, como e, penso, comerei”. A notícia a seguir exemplica meu ponto de vista, especialmente quando, hoje, o Negroponte do MIT tenta vender para o mundo todo seu notebook de US$ 100. São Paulo, domingo, 06 de maio de 2007

Escolas questionam ecácia de laptops. Entidades de ensino norte-americanas desistem de programas que implementam uso de computadores em sala de aula. Sem benefícios pedagógicos comprovados e com custo alto, uso de informática é freado por instituições. WINNIE HU DO “NEW YORK TIMES”, EM LIVERPOOL Os estudantes da Liverpool High, uma escola de segundo grau no interior do Estado de Nova York, usaram os laptops fornecidos a eles pela escola para divulgar gabaritos de provas, baixar pornograa e invadir computadores de empresas. Quando os dirigentes escolares adotaram medidas de segurança mais rígidas para a rede do colégio, um aluno da 10ª série não só encontrou maneira de superar essas barreiras como também postou instruções na Web explicando aos colegas como fazer a mesma coisa. Dezenas dos laptops arrendados pelos alunos quebram a cada mês, e de dois em dois dias, nos períodos reservados a estudo assistido por professores, a rede da Liverpool High termina caindo, devido ao alto número de alunos que preferem navegar pela internet a dirimir suas dúvidas escolares. Assim, o distrito escolar de Liverpool, uma cidade localizada perto de Syracuse, decidiu que, a partir do quarto trimestre, os laptops devem ser devolvidos, o que aumenta o número de escolas em

Introdução 5

todo o país que adotaram programas de computação individual e, mais tarde, optaram por cancelá-los, por terem sido considerados inúteis ou, pior, nocivos. O objetivo de muitas dessas escolas era remover a disparidade digital entre os alunos que tinham e os que não tinham computadores em casa. “Depois de sete anos, não há literalmente prova alguma de impacto positivo sobre as realizações acadêmicas dos estudantes”, disse Mark Lawson, presidente do conselho de educação de Liverpool - um dos primeiros distritos do Estado de Nova York a testar o sistema de oferecer aos alunos contato direto com a tecnologia. “Os professores nos informaram que, quando os alunos desenvolvem forte vínculo com seu laptop, o computador passa a representar uma distração no processo educacional”, disse. A postura adotada em Liverpool surge no momento em que mais e mais distritos escolares em todo o país optam por levar laptops às suas salas de aula. Um estudo conduzido por duas consultorias educacionais nos 2.500 maiores distritos escolares norte-americanos, no ano passado, mostrou que um quarto dos respondentes já havia adotado um computador por aluno, e que metade do grupo esperava fazê-lo até 2011. Na cidade de Nova York, cerca de seis mil alunos de quinta a oitava série receberam laptops em 2005 como parte de um programa trienal de US$ 45 milhões, nanciado com verba municipal, estadual e federal. No entanto, funcionários de diversas escolas armam que os estudantes cometeram abusos usando seus laptops, e que as máquinas não se enquadram nos planos de aula e demonstram pouco ou nenhum efeito mensurável sobre as notas e exames. Há distritos que abandonaram seus programas de distribuição de laptops devido à resistência de parte dos professores, problemas técnicos e logísticos e custos elevados de manutenção.

6 BPM & BPMS

Esse tipo de decepção é só o mais recente exemplo de como a tecnologia, muitas vezes alardeada por lantropos e líderes políticos como meio de solucionar problemas de forma instantânea, deixa os professores perplexos quanto ao que fazer para integrar os novos aparelhos aos seus currículos. No mês passado, o Departamento da Educação norte-americano publicou um estudo que demonstrava haver diferença em termos de realizações acadêmicas entrenão alunos que usam software educacional para aprender matemática e desenvolver a capacidade de leitura e alunos que não utilizam esse recurso. Por outro lado, muitos dirigentes escolares e professores dizem que o uso de laptops motivou até os mais relutantes dos alunos a aprender, resultando em frequência mais elevada, índices menores de punições e abandono de estudos. Em um dos maiores estudos em curso, o Centro de Pesquisa Educacional do Texas até agora não constatou diferença nos resultados de testes estaduais entre 21 escolas de quinta a oitava série, nas Mas quaisalguns os alunos receberam 21 que nãomais receberam. dados sugeremlaptops, que os eestudantes aptos podem se sair melhor em matemática quando equipados com laptops. tradução de PAULO MIGLIACCI Vinda da maior e mais poderosa economia do planeta a notícia é, no mínimo, sintomática de uma situação que em muitos casos já está fora de controle! Mas repito, não sou nem contra, de forma irracional, nem a favor, cego de paixão pelas Tecnologias da Informação. Estou aqui apenas colocando os dois lados da situação. Inútil esperar consenso, pois no cerne da discussão estará cada nova tecnologia criada; seus benefícios, malefícios, vantagens e desvantagens. Haverá organizações que irão defender as novas Tecnologias da Informação, mais por quererem acreditar nelas do que por terem efetivamente se beneciado delas. Outras organizações, contudo, irão atacá-las sem, muitas vezes, terem a mínima base para fazê-lo.

Introdução 7

É normal. É próprio do ser humano. Entretanto, sempre haverá aqueles, entre os quais me incluo, que procurarão estudar cada nova Tecnologia da Informação de forma a descobrir em cada uma sua essencialidade; por que e para quê fora criada, como deveria ser corretamente usada, como efetivamente está sendo usada, quais deveriam ser os resultados esperados do seu uso e quais estão sendo obtidos com a sua utilização. No que diz respeito à TI também existirão “várias verdades”, principalmente as adotadas pelos sostas modernos (chamados de “gurus”) que criam falsos argumentos para defendê-las (ou mesmo paraatacá-las), convincentes para todos que necessitam acreditar, sem se darem ao trabalho (gurus e crentes) de uma análise mais aprofundada e desapaixonada de todas elas. Para a quase esmagadora maioria destes “gurus” tudo que a indústria de TI produzé maravilhoso e cada nova invenção é realmente uma nova invenção! Na crista desta onda de paradoxos, BPM (Business Process Management) e seu software BPMS são as bolas da vez! Mas o que é mesmo BPM e BPMS? Para que servem? É um conceito? Um software? Ambos? Qual é Management Syso “parentesco” existente BPMS (Business tems ) e Workow? Onde,entre nesta história, entramProcess os princípios do Trabalho Cooperativo Suportado por Computador (CSCW3)? E como as tecnologias Groupware se encaixam nesta confusão? Estas e outras questões me levaram a escrever este livro.

Workow foi a ideia que deu srcem a este livro. Não porque este software seja uma ideia xa para mim (será que eu estou negando uma verdade?), mas, sim, pela necessidade de entender o porquê das organizações não conseguirem sair da Desorganização Informacional em que se afundam mais e mais todos os dias, mesmo existindo ferramentas que podem contribuir para reduzir suas causas e minimizar seus efeitos. Para entender por que as organizações são atropeladas pelo marketing da indústria de TI, que tenta de todas as existentes formas fazê-las acreditar outras ferramentas melhores” que as até então foramque criadas para resolver os“muito mesmos problemas existentes antes, e mais os novos problemas criados pelas últimas invenções que, por algum motivo, não deram certo, exacerbados pe-

3. Computer-Supported Cooperative Work.

8 BPM & BPMS

las tecnologias da geração anterior, que foram introduzidas para resolverem problemas criados pelas tecnologias anteriores, etc., etc., etc. Não tenho a veleidade de pensar ser possuidor de qualquer verdade absoluta sobre os temas abordados aqui. O livro é apenas a minha verdade, construída ao longo destes trinta e muitos anos de prossão. Cada um dos capítulos possui intrinsecamente uma vastidão imensurável de desdobramentos, que eu jamais mesmo se escrevesse um livroespetodo mês. Entretanto, el ao poderia princípioabarcar da busca constante do conhecimento ro ter começado um caminho que poderá me render muitos outros livros.

Algumas Palavras sobre Cada Capítulo No primeiro capítulo decidi contextualizar a Desorganização Informacional, explicando, sob o meu ponto de vista, suas srcens, causas e os efeitos mais próximos em todos nós. Há, também, um pouco da história dos computadores. Coloquei-a aqui para poder explicar como, do meu ponto de vista, se srcinou a situação que vivemos hoje. Nestes trinta e muitos anos convivendo e aprendendo no meio deste ambiente tive a oportunidade de vivenciar praticamente todas as mudanças tecnológicas que nos trouxeram aos dias de hoje, até porque tive a sorte de nos anos 70, 80 e 90 ter trabalhado em grandes fabricantes de Tecnologias da Informação como, por exemplo, a Compagnie Internationale pour le Informátique Honeywell Bull (CiiHB), uma das três grandes fabricantes de mainframes à época, o que me permitiu acompanhar, muito de perto, a evolução de TI com constantes viagens de estudo e trabalho ao exterior, uma vez que para nós brasileiros tudo era proibido por conta da lei de informática, vigente até meados da década de 90. No segundo capítulo analiso como surgiu a Desorganização Informacional, DoI, e as causas e os efeitos da doença que só faz crescer e alastrar-se nas organizações. No terceiro capítulo descrevo os conceitos que procuraram e procuram dar ordenamento à Desorganização Informacional, desde o surgimento do CSCW e das ferramentas que foram desenvolvidas com alguma aderência a este conceito. Deno também o que é Business Process Management e o que é Business Process Management System. Descrevo as diferenças e as igualdades com o software de Workow.

Introdução 9

No quarto capítulo descrevo e analiso o software Business Process Management System. No quinto capítulo introduzo a discussão sobre se a análise, o desenho, o redesenho, a modelagem, a organização, a implantação, o gerenciamento e a melhoria de processos de negócio podem ser, ou não, uma saída viável para a Desorganização Informacional. No sexto capítulo discuto os ciclos de vida do BPM e do BPMS. No sétimo capítulo falo sobre gerenciamento de mudanças. No oitavo capítulo apresento novos papéis funcionais, surgidos devido às mais recentes (r)evoluções de TI, o analista de processos, o analista de Workow, o analista de BPMS e o arquiteto de SOA. Creio ter conseguido abarcar todos os aspectos envolvidos com BPM e BPMS. Caso queira entrar em contato comigo, escreva para: [email protected]

Tadeu Cruz

1 As (R)Evoluções de TI

As “Ondas” Chamadas Tecnologias da Informação História Resumida dos Computadores Computadores4 podem ter sido criados por volta de 3.000 AC, pois algumas pesquisas indicam que o Ábaco5 já existia na Babilônia por volta deste ano, antes dele ter sido adotado pelos chineses com o nome de suan pan, em português algo como “máquina para cálculo” ou “máquina para fazer conta.” A se conrmar, esta informação coloca o Ábaco como a mais antiga tecnologia, a mais longeva e de vida útil mais longa existente entre nós, pois ele é usado até os dias de hoje. Os gregos também desenvolveram máquinas “sosticadas”, como a que foi encontrada na ilha de Antikythera em 1901 e que, quando reconstruída, revelou aos pesquisadores ser uma máquina que servia para calcular os movimentos dos planetas e das estrelas.

4. Segundo o Houaiss eletrônico, substantivo masculino para designar “o que computa; calculador, calculista”. Em informática, “dispositivo capaz de obedecer a instruções que visam produzir certas transformações nos dados, com o objetivo de alcançar um m determinado.” 5.O Ábaco é, seguramente, a primeira Tecnologia da Informação de que se tem notícia e existe até os nossos dias com o mesmo hardware e software, que somos nós.

12 BPM & BPMS

A Renascença trouxe novos desdobramentos para a história dos computadores, pois a Idade Média, período anterior, havia mergulhado a humanidade em preocupações e necessidades extremamente (e exclusivamente) religiosas; por isso não há registros sobre invenções tecnológicas entre os séculos V e X, chamada de alta Idade Média, e entre os séculos XI e XV, denominada de baixa Idade Média. Entretanto, houve outras “Idades Médias” além da que experimentou nossa civilização ocidental. A Idade Média árabe e a Idade Média asiática desenvolveram-se com características próprias e de forma independente da Idade Média europeia; o que, em tese, ainda pode vir a surpreender-nos com algum artefato “tecnológico”, bastando, para isto, que algum arqueólogo descubra alguma invenção criada neste período no Oriente Médio ou na Ásia. A partir da Renascença, a chamada época “das luzes”, também conhecida como a Idade Moderna, temos os seguintes inventores ligados ao mundo dos computadores: 

John Napier (1550-1617), inventor dos logaritmos e da máquina conhecida como “Varas de Napier”, criada para simplicar o trabalho de multiplicação;



Wilhelm Schickard (1592-1635), que criou uma máquina mecânica para realizar as quatro operações: adição, subtração, multiplicação e divisão;



Blaise Pascal (1623-1662), criador de uma máquina para adição aritmética;



Gottfried Wilhelm Leibniz (1646-1716), que inventou uma máquina capaz de realizar as quatro operações aritméticas.

Todos os inventos até aqui necessitavam da presença de um operador, o que signica dizer: as máquinas ainda não eram “automatizadas”, não podiam fazer o trabalho sozinhas. No século IX, Joseph-Marie Jacquard (1752-1834) inventou o tear programado com cartões perfurados. Praticamente foi esta invenção que marcou o início da automatização da indústria têxtil e o aparecimento das tecnologias “automáticas”; pois o “equipamento” dispensava o trabalho manual do tecelão, uma vez que as padronagens eram programadas nos cartões perfurados que depois, inseridos nos teares, os faziam “funcionar sozinhos”. Cremos que a partir daqui estava criado o desemprego gerado pela tecnologia.

As (R)Evoluções de TI 13

Também deste século são os inventos de: 

Charles Babbage (1791-1871), que criou duas máquinas, a de diferença e a analítica, uma para calcular e a outra para analisar; e



William Stranley Jevons (1835-1882), que inventou em 1869 uma máquina para resolver problemas de lógica.

A partir do século XX temos os seguintes inventores ligados às tecnologias da informação: 

Herman Hollerith (1860-1929), que criou os famosos cartões perfurados e a correspondente máquina para lê-los, o que possibilitou ao governo americano tabular os dados do censo de 1890 em tempo recorde para a época;



Howard H. Aiken (1900-1973), que desenvolveu em 1944 o Mark 1, primeiro computador eletrônico digital;



John Vincent Atanasoff (1904-1995), que desenhou e construiu um computador eletrônico para resolver sistemas deequação lineares.





John William Mauchly (1907-1980), e J. Presper Eckert (1919-o 1995), que desenvolveram na Universidade da Pensilvânia computador ENIAC e, junto com John Von Neumann (1903-1957), criaram o primeiro computador que podia “carregar” um programa, chamado de EDVAC, que continha, como invenção, ideias ainda hoje encontradas nos modernos computadores. Também foram os mesmos Eckert e Mauchly que construíram o UNIVAC, que viria a dar srcem à fabricante de mainframes UNIVAC que na década de 70 foi vendida para a Burroughs, outro fabricante de mainframes.

Depois vieram o EDSAC, computador baseado no EDVAC, construído em 1948 por Maurice Wilkes, e o Manchester Mark 1, construído pelos pesquisadores da Universidade de Manchester. Entretanto, foi a partir da invenção do transistor em 1947, pelos cientistas Bardeen, Brattain e Shockley, que oscomputadores ganharam o perl que conhecemos até os dias de hoje. Os transistores permitiram que o microprocessador fosse nalmente criado. Estes três cientistas ganharam o Nobel de Física de 1956 por essa descoberta.

14 BPM & BPMS

Em 1949 John Forrester inventou a memória de núcleo magnético. A título de curiosidade, o termo “ciência da computação” (computer science) foi criado pelo americano George Forsythe; o primeiro curso desta área foi criado em 1962 na Universidade Purdue, Estados Unidos. Esta breve viagem pela história das tecnologias da informação resume-se somente aos acontecimentos do hardware dossoftware, computadores. Propositalmente deixei de foraea invenções parte da história ligada ao por ser este bem mais recente e volátil que o hardware, haja vista que, no comparativamente curto período de existência, o software, salvo raríssimas exceções, tem bem menos tradição e longevidade que o hardware, além de ser instável, imprevisível e possuidor de características, como veremos mais adiante, que desorganizaram e desorganizam o universo informacional das empresas, embora sempre tenha sido apresentado com o propósito de fazer o inverso. Um exemplo do que digo? O Ábaco que conhecemos hoje, utilizado normalmente por milhões de pessoas ainda, é o mesmo Ábaco, presume-se, criado há cinco mil anos. Puro hardware! Isto quer dizer que o hardware é mais perene que o software? No meu entender, sem dúvida! Qual software teve vida tão longa como o Ábaco? Quantos computadores “antigos” nós ainda temos ou vemos trabalhando por aí? Eu mesmo troco meu notebook a cada três anos (a menos que o roubem de mim, como aconteceu em janeiro de 2007). Entretanto, cabe-me aqui fazer uma ressalva importante. O software poderia ter uma vida muito mais longa que o hardware, não fosse, por um lado, a necessidade que a indústria de TI tem de vender constantemente mais hardware e, consequentemente, mais software, premida pelo instinto de sobrevivência, e, por outro lado, a nossa ânsia consumista, forçando-nos a ter, ter, ter sempre a última versão de qualquer coisa.


O Vai-e-vem das Ondas de TI Desde o início da sua vida nas organizações, período que chamo de computação comercial, as Tecnologias da Informação chegam até nós em ondas, da mesma forma como as do mar! As Tecnologias da Informação chegam às nossas vidas, e às das organizações, em movimentos cíclicos e, na maioria das vezes, regulares. Basta que cada onda de TI se espraie sobre a “nossa praia” para que logo haja um movimento de reuxo formando outra onda que continuará a nos atingir de forma continuada, sem nos dar tempo de absorver e utilizar corretamente cada tecnologia. Exatamente como as ondas do mar! As ondas de TI têm nomes variados, vão de Mainframes a Grid Computing, de Ofce Automation a SOHO 6, de Groupware a Business Process Management Systems , mas seus movimentos são sempre iguais, pois surgem, suposta e pretensamente, para resolverem problemas, muitos dos quais criados por outras ondas de TI além de outros que nem sequer imaginávamos serem problemas. As ondas de TI arrebentam sobre nós (muitas vezes literalmente), na praia e nas organizações (quando não arrebentam as próprias organizações), para logo em seguida reuírem a m de formar novas ondas. Assim como os surstas das ondas do mar, a maioria dos prossionais da área de TI adora pegar estas ondas; adoram surfar nas buzzwords7 que batizam cada uma delas, da mesma forma como são batizados os furacões. Outros, mais desconados, preferem assistir da areia aos movimentos de altos e baixos que estas (r)evoluções provocam nas organizações antes de se decidirem se vão ou não surfá-las. No meu livro Sistemas, Organização & Métodos, de 1998 8, classiquei as ondas de TI como ciclos, e as reproduzo aqui na gura 1.1 a seguir para poder explicar o desenvolvimento dos movimentos das ondas de TI até os dias

6. SOHO, Small Ofce - Home Ofce. Respectivamente pequeno escritório – escritório em casa. 7. Buzzword, palavra sonora, jargão, geralmente sem qualquer signicado. 8. Sistemas, Organização & Métodos. Editora Atlas, atualmente na terceira reimpressão da terceira edição.

16 BPM & BPMS

atuais e, consequentemente, explicar o pretendido papel com que foi criado o conceito que embasou o desenvolvimento das tecnologias Groupware. Preferi classicar as ondas de TI começando na década de 60 porque foi a partir deste momento que TI efetivamente começou a ser usada pelas empresas. Antes dos anos 60 somente os laboratórios de pesquisas, as instituições militares e as universidades (poucas) tinham acesso a computadores.

Figura 1.1 – Ciclos evolutivos de TI.

A gura 1.1 mostra que entre os anos 60 e 70 a ligação dos usuários com as Tecnologias da Informação dava-se apenas por meio de suporte de papel. Os usuários levavam pilhas de formulários preenchidos até um local chamado de CPD, que eram digitados por um setor chamado digitação, e tempos depois voltavam para pegar os resultados, que invariavelmente eram pilhas de listagens impressas em formulário contínuo. A partir dos anos 70 começaram a surgir os primeiros terminais de computador. Na aparência eram semelhantes aos microcomputadores de hoje mas não tinham capacidade de processamento local e por isso eram ligados a um mainframe central (nós os chamávamos de terminais burros). Na década de 80 surgiram os microcomputadores que, embora fossem limitados, transferiram dos mainframes para o usuário nal o poder de processamento dos seus dados, ainda que


elementar. A partir da década de 90 a globalização, baseada no avanço dos meios de comunicação e nas novas Tecnologias da Informação, transformou completamente os usuários e eles passaram de passivos a ativos rapidamente; o que viria a exacerbar-se com a liberação da Internet para a sociedade em geral a partir do início dos anos 90. Dertouzos (2001) divide as Eras de TI da seguinte forma: A Revolução da Informação começou de maneira inocente nos anos 50 com um punhado de curiosidades de laboratório dedicadas a cálculos matemáticos. Os anos 60 trouxeram os computadores de tempo compartilhado, usados sequencialmente por dezenas de pessoas para distribuir o alto custo da máquina. As universidades e outras organizações logo descobriram que o verdadeiro benefício não era o dinheiro economizado, mas as informações compartilhadas por meio do correio eletrônico e das transferências de documentos dentro de cada grupo que dividia a máquina. Os anos 70 trouxeram a Arpanet, que interligou dezenas de máquinas de tempo compartilhado, principalmente em universidades; novamente, isso foi feito para dispersar os custos de computação e, outra vez, o benefício real mostrou ser a expansão da comunidade que compartilhava informações, dessa vez alguns milhares de pessoas. A chegada do computador pessoal na década de 80 tornou o poder da informática acessível a milhões de pessoas, que usavam suas máquinas para trabalho de escritório e para brincar em casa. A Ethernet, que chegou na mesma época, possibilitou a interconexão de centenas de PCs em redes locais, principalmente dentro de organizações. A Internet, já desenvolvida como um método de interconexão de redes de computadores, voltou-se para a demanda crescente de interligação dessas milhares de redes locais. Tais mudanças aumentaram a comunidade de pessoas que podiam partilhar informações por meio do correio eletrônico e da transferência de arquivos para alguns milhões de pessoas. Então, nos anos 90, quando os avanços da interligação em rede estavam se estabilizando e não parecia possível nada muito grande acontecer, houve a maior mudança de todas: chegou a World Wide Web como uma aplicação de softwares para computadores ligados pela Internet. Ela atingiu

18 BPM & BPMS

a comunidade sempre crescente de usuários interconectados com um salto quantitativo e qualitativo. A criação e a navegação de Web sites cativou o mundo de tal maneira que o número de usuários interconectados subiu rapidamente até 300 milhões no m do século XX, conforme eles e o restante do

mundo começaram a experimentar o impressionante potencial socioeconômico do mercado de informações.

Muitas Tecnologias da Informação fracassaram ou fracassam antes de completar um ano de vida. Algumas fracassam mais, outras menos, principalmente em se tratando de softwares. Cada tecnologia criada e colocada à disposição do mercado, em cada um dos ciclos evolutivos de TI, tem uma curva de vida como a que apresento na gura 1.2. Ou seja, cada um dos ciclos representados na gura 1.1 carrega dentro de si centenas, milhares, de curvas iguais à da gura 1.2. As tecnologias compradas pelas organizações são representadas pela “curva das tecnologias que foram “adotadas” pelo mercado”; e as que não foram compradas ou tiveram vida muito curta são representadas pela outra curva, a “curva das tecnologias que não foram “adotadas” pelo mercado”. A porcentagem de tecnologias “hardware” aceita pelo mercado é, pelas nossas pesquisas, dois terços maior do que a porcentagem das tecnologias “software” aceitas. Entre outras causas, a explicação pode estar na palavra “amigável”. Inúmeras foram as tecnologias “hardware” que permaneceram iguais desde seu nascimento, enquanto os softwares, que as fazem funcionar, mudaram, às vezes radicalmente, a cada nova versão colocada no mercado. Exemplos? Quantos programas você usa para gravar CDs? Ao passo que os gravadores de CDs permaneceram os mesmos com pequenas melhorias, como o aumento da velocidade de gravação e leitura. Aliás, CD é uma mídia que está rapidamente caindo em desuso, o que vamos usar de agora em diante é o DVD, pelo menos enquanto as novas mídias não ganham espaço no mercado.


Figura 1.2 - Curvas de introdução e aceitação de inovações tecnológicas.

Nestes mais de trinta anos, como assíduo frequentador destas praias, por vezes sofrendo os efeitos da arrebentação das ondas de TI, noutras participando diretamente das suas causas e efeitos, acostumei-me às marés tecnológicas assumindo-as como inevitáveis. Entretanto, mesmo considerando-as inevitáveis, também aprendi a defender-me das arrebentações das suas ondas e aprendi também, sempre que possível, a defender os que,de alguma forma, dependiam ou dependem das minhas atitudes frente a (r)evoluções de TI. Embora a metáfora das ondas já tenha sido usada por outros autores, uso-a por adequar-se perfeitamente à nossa área de atuação, pois, como as do mar, as ondas de Tecnologia da Informação também são recorrentes. O efeito deste movimento é análogo ao das ondas do mar, que leva embora o que encontra pela frente para tempos depois trazer tudo de volta, depositando na areia tanto coisas novas como refugo que o mar rejeita de outras ondas, das quais, na maioria das vezes, nem nos lembramos mais. Há um grande número de tecnologias que “as ondas de TI trouxeram e levaram embora” e que, de uma hora para outra, foram ou estão sendo trazidas de volta até nossas praias. São tecnologias da informação que não deram certo no passado por diversos motivos, ou porque não cumpriram com o prometido ou porque prometeram, por elas, mais do que elas poderiam fazer. Aqui estão algumas:

20 BPM & BPMS 

EIS, Executive Information System. Este software, que nos pri-

mórdios dos microcomputadores, por volta dos anos 80 e 90, prometia aos executivos possibilitar a criação de relatórios gerenciais que lhes permitissem tomar rápidas decisões, não deu certo. Como a organização informacional (bancos de dados, integração de sistemas etc.) não era ainda sucientemente madura para permitir a geração das bases de dados necessárias ao seu perfeito funcionamento, o EIS não “vingou”. Hoje o EIS ressurgiu das cinzas e transformou-se. Agora ele atende pelo nome de BIS, Business Intelligence System, mais popularmente conhecido como BI. 

DW, Data Warehouse. É outra tecnologia que veio, foi e voltou.

Foi e voltou inúmeras vezes. Hoje ainda mantém o mesmo nome de Data Warehouse e trabalha em conjunto com o Business Intelligence System. Enquanto os módulos de DW organizam e executam a estraticação e a extração dos dados existentes nos bancos de dados corporativos, o BI trabalha sobre os dados extraídos resultantes destas rotinas, isto é, sobre os bancos de dados estraticados, para gerar os relatórios gerenciais. 

MRP, Material Requirement Plan, já foi e voltou inúmeras vezes

até os dias atuais, transformado no “fantástico” ERP, Enterprise Resource Planning, que, agora travestido de repositório das melhores práticas organizacionais e administrativas do universo, impinge às organizações sofrimentos até então inimagináveis por nós. 

CRM, Customer Relationship Management, cuja onda foi, li-

teralmente, devastadora para algumas organizações, com projetos que devoraram milhões de Dólares e Reais por terem sido implantados sem análise, desenho, redesenho, modelagem e melhoria dos processos de negócio que capturam informações de clientes e que volta agora com cuidados das organizações que pretendem utilizá-la. redobrados por parte 

A “Armageddon” da virada do século XX. Todas as soluções prometidas para enfrentar a “Armageddon” que ameaçava as organizações na data de 1º de janeiro de 2000 e que atendia pelo nome de BUG do milênio. Este “fatídico” dia prometia as trevas para todas as organizações que não se preparassem correta-


mente para a virada do século XX para o século XXI. Claro que corretamente deve-se entender por comprar mais tecnologias da informação e muita, muita consultoria. Mas os fracassos não cam restritos ao software. O hardware também participa ativamente destes movimentos de uxo e reuxo das ondas de TI. Aqui estão alguns exemplos: 

Tecnologias da Informação que substituirão o papel vão e voltam na crista das suas próprias ondas e algumas vezes são surfadas por gurus que não se cansam de decretar a morte da pasta, mistura de celulose, pinus ou eucalipto, que chamamos de PAPEL. A mais recente promessa vem da Amazon, a ex-maior livraria eletrônica do planeta, agora a maior vendedora eletrônica de bugigangas (gadgets), que acaba de lançar um dispositivo chamado de Kindle: The Amazon’s New Wireless Reading Device, que entre outras funcionalidades permite que se comprem livros e jornais eletrônicos pela Internet e que se possam baixálos e lê-los no Kindle. O aparelhinho custa mais de US$ 400.00 e detalhe: NÃO LÊ ARQUIVOS PDF, ou seja: compre e você se casará, para sempre, com a Amazon, sua única fornecedora de conteúdo.



Grid Computing. Promete o compartilhamento da capacidade de processamento ociosa da rede mundial de computadores, a Internet, mas que ainda não realizou suas promessas por questões como segurança e, paradoxalmente, direitos de uso de compartilhamento desta mesma capacidade ociosa.



Network Computer. Este é o nome da promessa! Um PC de baixa capacidade de processamento, pouca memória e quase que exclusivamente dedicado à Internet e muito barato, a m de permitir, entre outras coisas, a tão falada inclusão digital. Bom, a promessa jamais se concretizou, embora hoje o Nicholas Negroponte esteja “reinventando a roda” com seu notebook de US$ 100.00.

A mais nova destas ondas chama-se Business Process Management System. Este é o novo nome que deram para os sistemas de Workow. A rigor, esta é a onda que me motivou a escrever este livro.

22 BPM & BPMS

Algumas destas tecnologias são tão novas quanto, por exemplo, um sandwich9, mas os fabricantes, (alguns) usuários, analistas de mercado, institutos de pesquisa, formadores de opinião e “expertos” em geral esforçam-se para nos fazerem acreditar que são realmente novas, embora muitas sejam apenas tecnologias recicladas. Muitas vezes as ondas de TI aparecem trazendo não somente tecnologias, mas o modus operandi destas. É o caso do antigo bureau (lê-se birô) de processamento de dados, desconhecido pelos que não viveram as ondas de TI dos anos 60 e 70. Os birôs eram centros de processamento de dados terceirizados, que trabalhavam para vários clientes sem recursos para comprar ou alugar um computador. Eles praticamente sumiram quando as máquinas baixaram de preço e se popularizaram, permitindo que um número cada vez maior de empresas pudesse adquirir seus próprios computadores. Pois bem, os birôs estão de volta e são chamados agora de centrais de operação, centrais de outsourcing e de data centers. Mesmo o outsourcing (terceirização) já passou por várias idas e vindas; foi operacionalizado “fora de casa”, “dentro de casa”, completo, seletivo, quarteirizado, em movimentos de uxo e reuxo característicos do mundo de(BPO) TI até chegar aos dias atuaisOutsourcing com o nome(KPO). de Busines Process Outsourcing e Knowledge Process

A Evolução do Hardware Como as Ondas de TI se Formam Existem diversos fatores que contribuem para criar as ondas de TI, mas indubitavelmente um dos mais importantes é a própria indústria de TI, embora deva reconhecer que pesquisadores ligados ou não à Academia também têm sua parcela de responsabilidade pela formação de alguns tsunamis. Em 1996, Nicholas Negroponte, do MIT, numa entrevista à revista Isto É, nos mostrou um destes fatores e de como as ondas de TI são formadas por sua própria indústria10.

9. Grafado assim mesmo, como o nome do seu criador, Lord Sandwich, para reforçar a ideia de tempo de existência. 10. Reprodução de parte domeu livro Manual deSobrevivência Empresarial, de 1996,esgotado.


Isto É – É preciso microcomputadores cada vez mais rápidos como o Pentium Pro? NN – Não. Mas a coisa funciona assim. Andy Grove (à época), o dono da Intel, lança um processador mais rápido. Em seguida Bill Gates, o da Microsoft, faz programas que precisam de mais capacidade. Então, Grove faz um chip mais potente, aí Bill Gates usa toda a se velocidade disponível e pede mais. E assim por diante. O que ganha com esses PCs e softwares cada vez mais poderosos? Quase nada! Cada atualização de um programa traz dezenas de aplicativos que ninguém usa, nem precisa. Isto É – Por que as empresas continuam lançando estes produtos e não micros mais baratos? NN – Os micros, mesmos os de última geração, poderiam custar US$ 20011. Mas seus preços são mantidos articialmente em US$ 1,500, que é um preço acessível ao consumidor americano. Assim os fabricantes vendem dez milhões de micros por ano nos Estados Unidos lucro.deCom aumento da produção do 386, seu com preçoenorme caiu abaixo US$o 1,500 ea indústria lançou o 486. Quando a produção deste explodiu veio o Pentium. E agora é a vez do Pentium Pro, como daqui a três anos acontecerá o mesmo com o Pentium 4, 5, 6, 7...

É necessário entendermos a evolução do hardware e de como esta (r)evolução inuenciou e continua inuenciando a formação das ondas de TI. Por ordem cronológica o hardware é o primeiro a ser criado para só então o software ser desenvolvido. Resumidamente podemos dividir a história da vida doscomputadores dentro das organizações, que chamo de Computação Comercial, em duas fases distintas, representadas pela capacidade deprocessamento dos computadores:  máquinas monoprocessamento, cuja capacidade de tratamento da informação era compartilhada de forma cronológica e se-

11. Recentemente (2005) Negroponte, que continua no Media Lab do MIT, veio ao Brasil apresentar ao governo seu projeto de computador de US$ 100.

24 BPM & BPMS

quencial por dezenas de usuários para distribuir o alto custo do equipamento. Estes computadores eram centralizados num local chamado Centro de Processamento de Dados (CPD), para onde todos os usuários enviavam ou levavam seus dados por meio de formulários e planilhas preenchidas à mão para serem digitados e gravados em uma mídia (cartão perfurado, disquetes etc.) que pudesse ser lida pelos computadores para serem processados; 

máquinas multiprocessamento, cuja capacidade de tratamento da informação passou a ser compartilhada em tempo real por centenas de usuários e cujos primeiros modelos ainda cavam centralizados no CPD. Com o surgimento da computação distribuída no nal dos anos 80, estas máquinas passaram a não mais estar centralizadas no CPD, e cada usuário pôde enm se libertar, até certo ponto, do domínio do pessoal da área de informática.

Embora existam inúmeras outras classicações, pois cada autor faz a classicação que melhor se ajuste aos seus propósitos de escritor, eu prero dividir as máquinas em mono e multiprocessamento porque foi esta característica que, a meu ver, mudou o comportamento dos usuários de TI, as organizações e a interessa própria computação disto, para o propósito deste livro, nos caracterizarcomercial. a história Além dos computadores pelo uso que as organizações zeram e fazem deles.

Figura 1.3 - As duas fases da história dos computadores nas organizações.


As máquinas monoprocessamento foram os computadores que existiam nos primórdios da computação comercial. Aqueles computadores executavam sistemas operacionais monotask e com pipeline (execução da sequência de instruções básicas do sistema operacional) horizontalizado e sem sobreposição ou recorrência. Nestas máquinas cada sistema tinha que ser processado em ordem estritamente cronológica, o que obrigava os analistas de sistemas a criá-los de forma lógica e cronológica, uns após outros. Quem dominava o mercado naquela época eram os assim chamados quatro grandes fabricantes de mainframes (décadas de 60 e 70): a IBM, a Burroughs, a UNIVAC, todas americanas, e aCII Honeywell Bull, francesa, mas que tinha participação do grupo americano Honeywell Information Systems (HIS). Hoje a Honeywell Controllers, remanescente do grupo Honeywell, é a única empresa, das duas que existiam naquela época no grupo Honeywell, que se manteve e virou líder do mercado de automação. Por serem computadores tipo monoprocessamento eles eram, também, monousuários. Estas máquinas tinham sistemas de arquivamento de dados simples; eram sequenciais ou, tempos depois, no máximo com indexação direta através do endereçamento físico dos arquivos nos discos magnéticos (por meio da referência espacial cilindro e trilha de cada disco). Estas máquinas, embora monoprocessassem os trabalhos a elas submetidos, podiam ser e eram usadas sequencialmente por vários usuários. As máquinas multiprocessamento foram os computadores que vieram nas “ondas de TI” posteriores. Máquinas com sistema operacionalmultitask, pipeline múltiplo; além de processarem separadamente supervisores de redes de comunicação de dados, possibilitando que centenas, em alguns casos milhares, de terminais fossem conectados a elas, permitiram com isto que incontáveis usuários usassem os sistemas de informações ao mesmo tempo. Os sistemas de informações, por sua vez, chamavam-se sistemas transacionais; isto é: processavam transações e tinham por base sistemas de arquivamento de dados bem mais sosticados, como os bancos de dados que a princípio foram estruturais, hierarquizados, e depois evoluíram para os bancos de dados relacionais. Por serem multiprocessamento os computadores eram também máquinas multiusuários, concomitantes. Algumas das máquinas que iniciaram esta geração foram, entre outros, os sistemas 370 da IBM; a série 60/64 e 60/66 da

26 BPM & BPMS

Honeywell Bull; e a série B6000 da Burroughs (não incluí aqui os sistemas da UNIVAC por ter sido ela comprada pela Burroughs nos anos 70). Na computação comercial a transição de uma fase para outra se deu de forma abrupta, pois as máquinas da fase monousuário foram substituídas pelas máquinas multiusuários quando a vida útil das primeiras expirou-se. Foi esta (r)evolução do hardware que a meu ver deu srcem à situação em que nos encontramos hoje – que eu chamo de Desorganização Informacional! Primeiro vieram os computadores construídos com milhares de válvulas, que faziam as vezes dos atuais circuitos impressos na função de computar dados. Desta geração os mais famosos representantes foram o ENIAC e o EDVAC. Não era uma computação disseminada por grande número de organizações, pois eram máquinas muito caras e apenas os organismos militares e os institutos de pesquisa universitários e governamentais as utilizavam. Embora tenha sido uma geração de computadores de importância fundamental para os nossos dias, não provocou nenhuma revolução na administração e na operação das organizações simplesmente porque não foram usadas pelas organizações. Consequentemente, também não contribuíram para a Desorganização Informacional dos nossos dias. A segunda geração de computadores trouxe algumas (r)evoluções tecnológicas, pois passaram a possuir memória de núcleo magnético em vez de válvulas. Esta geração foi a primeira a ser usada por organizações, independentemente do tipo deles, embora a quantidade de computadores existente nas organizações fosse muito reduzida, uma vez que as máquinas eram caras, complexas e de operação e manutenção extremamente delicadas. Logo que surgiram, algumas destas máquinas eram “programadas” na própria placa12 da CPU13, por meio de pinos que ao serem “espetados” conectavam ou desconectavam os “circuitos” que processavam os dados contidos nas massas de cartões com as quais as máquinas eram “alimentadas” para o trabalho. Eram máquinas que “engoliam” conjuntos de instruções e dados para batch) deecartões processamento num mesmo (processament e o dados, máximo que faziam eram cálculoslote básicos, além de ointercalar classicar para depois imprimirem grandes listagens resultantes destas operações.

12. Como o GAMA 10 da GE Bull. 13. Central Processor Unit.


No início da vida dos computadores dentro das organizações eles eram chamados pelos usuários de “cérebros eletrônicos.” O local onde os tais “cérebros” cavam era construído com especicações rigorosas de temperatura e umidade. A temperatura só podia variar entre 18ºC e 22ºC e a umidade relativa do ar devia ser de no máximo 60%. Este tipo de máquina fazia muito pouco em comparação com os equipamentos atuais, mas foi responsável por uma das primeiras (r)evoluções que as organizações viriam a sofrer na forma de operacionalizar alguns “processos” administrativos. Por exemplo, antes destes “cérebros eletrônicos” a folha de pagamento de qualquer organização era feita à mão! Assim como esta, algumas outras tarefas foram paulatinamente sendo assumidas por tais máquinas. A entrada de dados nestes computadores dava-se por meio de um dispositivo chamado leitora de cartões perfurados, que eram de dois tipos: os de 96 colunas (usados pela IBM) e os de 80 colunas usados pelos outros fabricantes de mainframes. Lembro-me que no início os cartões perfurados não tinham tradução literal dos furos contidos neles e que uma das incríveis novidades daqueles tempos foi o aparecimento de uma máquina, apelidada por nós de “sorveteira”, pela característica do seu tamanho e formato, que tinha a função de ler a massa de cartões e imprimir na borda superior de cada um a tradução literal dos furos contidos neles. Ah! Você não imagine que avanço, e que alívio, para nós analistas e programadores daquela época o que signicou ter todos os cartões traduzidos, pois quando uma massa de cartões (que podia chegar a centenas) caía no chão e embaralhava-se era um suplício colocar tudo na ordem novamente sem a impressão do signicado dos furos em cada cartão. Se bem que existia um dispositivo, chamado de intercaladora-classicadora, que fazia este trabalho, mas tais máquinas eram caras e só se justicavam economicamente em clientes com grandes volumes de cartões e de processamento. Computadores desta época também monoprocessavam os “sistemas de informações” (que a rigor eram coleções de programas que apenas encadeavam cálculos simples e operações lógicas; além de classicação e intercalação dos dados neles contidos) que neles eram introduzidos por meio das massas de cartões. Além disso, todo o processamento era centralizado no CPD, que, também, era o responsável pelo correto sequenciamento dos programas que faziam parte dos sistemas. A gura 1.4 mostra a computação centralizada (monoprocessamento).

28 BPM & BPMS

Figura 1.4 – Computação centralizada monoprocessamento.

Com o surgimento deste tipo de computador foram plantadas as primeiras sementes do caos informacional que vivemos hoje. Os usuários começaram a abrir mão de uma parte do seu conhecimento, e do domínio sobre ele, em favor do processamento dos dados que realimentava este mesmo conhecimento após os dados terem sido processados. Assim, aqueles usuários que “processavam” dados enclausurad os em suas escrivaninhas pouco a pouco passaram a prepará-los para serem processados pelos Centros de Processamento de Dados (CPD) da organização. Como consequência houve o surgimento de dois tipos de dados e informações: os que cavam na posse dos seus “donos” e os que eram enviados para processamento no CPD; isto é: dados que a partir daí caíam em domínio público nas organizações. O problema é que muitas vezes o usuário sonegava informações, com medo de “perder o emprego” e com isto criava


várias situações de estresse. Aliás, nada muito diferente do que vemos existir ainda hoje na maioria das organizações. Muitas pessoas ainda não entenderam que tem poder quem sabe usar o conhecimento, não quem o esconde.

A Segunda Fase da Segunda Geração A segunda fase da segunda geração de computadores, na computação comercial, foi construída em cima de ideias avançadas, uma das quais possibilitou o processamento transacional dentro das organizações; disponibilizou alguns periféricos que facilitaram a vida dos programadores e operadores de computadores, como consoles centrais interativas e os discos magnéticos xos e removíveis de grande capacidade para aquela época. A memória principal aumentou de tamanho e começaram a aparecer máquinas com arquiteturas sosticadas, com CPU’ s14 modularizadas, o que possibilitava que fossem expandidas sem a necessidade de trocar todo o computador. Os principais módulos daqueles computadores eram a própriaUnit Unidade Processor Central de Processamento, chamada de Central (daí o termo CPU usado até hoje), a Unidade de Processamento Aritmético e Lógico ( Arithmetic and Logic Unit (ALU)), a Unidade de Tratamento de Entradas e Saídas ( I/O Unit ) e em pouco tempo apareceram as memórias cache, que agilizaram o processamento dos dados por permitir que eles fossem carregados dos discos para esta área de acesso muito mais rapidamente e daí fossem transferidos para a memória central ( CMU 15) para serem processados pelas instruções dos programas carregados na CPU. A partir desta arquitetura sosticada apareceram também os códigos chamados Firmware , que são instruções gravadas em memórias não-voláteis de acesso rapidíssimo cuja nalidade é processar outras instruções como, por exemplo, as de supervisão e integração dos diversos periféricos do

14. CPU, Central Processor Unit, ou Unidade de Processamento Central. Embora o termo CPU seja usado para designar genericamente o móvel central de qualquer computador, agora popularizado com o advento dos micros, esta unidade é a responsável por executar as instruções de software que devem processar os dados de qualquer programa. 15. CMU, Central Memory Unit, ou Unidade Central de Memória.

30 BPM & BPMS

computador. O rmware , ainda hoje utilizado, é um tipo de memória prégravada com instruções que se encarregam de ordenar o ambiente geral do computador. Por exemplo, controlar as entradas e saídas de dados e instruções de programas de/e para os periféricos de entrada e saída, para a memória central e a unidade central de processamento. A gura 1.5 mos tra a computação centralizada (multiprocessamento). Estes computadores introduziram sistemas operacionais recorrentes (processamento repetitivo de instruções) que permitiam o multiprocessamento de sistemas de informações de forma paralela, possibilitando que vários usuários usassem ao mesmo tempo a capacidade de processamento da máquina. A partir da introdução destes computadores a Desorganização Informacional acentuou-se progressivamente, pois foram eles que possibilitaram a criação das networks, as redes de terminais “burros16” que, como tentáculos, estendiam-se por toda a organização. Então, o universo informacional existente nas empresas, que era “naturalmente organizado”, uma vez que os dados eram preparados pelos funcionários para serem digitados e processados pelo CPD (Centro de Processamento de Dados), foi gradativamente se desorganizando na mesma velocidade e proporção com que os dados passaram a ser introduzidos (isto é: preparados, digitados) e processados sob a supervisão direta dos próprios usuários, isto é, sem qualquer controle da organização, a não ser as programadas nos sistemas de informações. Entretanto, por serem centralizadores, isto é, porque os dados cavam em discos compartilhados por todos os sistemas, tais computadores ainda possibilitavam alguma coerência informacional entre todos os usuários de um mesmo sistema, e até mesmo entre usuários e sistemas diferentes, mas mutuamente complementares.

16. Os processadores destes terminais, conhecidos como z80 e z8080, só processavam instruções pertinentes às suas próprias funcionalidades. No Brasil estes terminais eram fabricados pela Scopus e depois também pela TDA.


Figura 1.5 – Computação centralizada multiprocessamento.

A Terceira Geração Esta geração de computadores introduziu dois novos tipos de máquinas: os computadores superminis e os microcomputadores. Os computadores chamados superminis introduziram duas variáveis até então inexistentes no mundo de TI: a possibilidade concreta de mais e mais 17

general purpose que empresas um pela computador e o cou processamento distribuído,possuírem possibilitado arquitetura de software conhecida como cliente-servidor (client-server). O surgimento deste tipo de arquitetura aliado à popularização dos microcomputadores expandiu as fronteiras da

17. Assim chamados porque podiam ser usados para qualquer propósito.

32 BPM & BPMS

indústria de software, que antes era restrita aos produtos dos fabricantes de mainframes e/ou aos produtos desenvolvidos sob estrito controle destes para serem executados nos mainframes, uma vez que os sistemas operacionais (SO) das grandes máquinas eram proprietários, ou seja, eram exclusivamente feitos por cada fabricante, para cada tipo de máquina, diferentemente do que é o Windows hoje, que pode ser executado em máquinas de qualquer fabricante, até porque a arquitetura básica destas máquinas, os microcomputadores, é a mesma (salvo raríssimas exceções) para todos os fabricantes de micros.

Resumo das Duas Fases da Computação Comercial Fase monoprocessamento: 

baixa capacidade de processamento;



sistemas construídos com módulos encadeados por dependência lógica;



baixa utilização de meios magnéticos para arquivamento de dados;



usuários ligados indiretamente aos computadores;



entrada e saída de dados e informações por meio dos centros de processamento de dados (CPDs);



baixo volume de dados e informações processadas.

Fase multiprocessamento: 

alta capacidade de processamento;



sistemas construídos com módulos encadeados por dependência lógica, cronológica e funcional;



alta utilização de meios magnéticos para arquivamento de dados;



usuários ligados diretamente aos computadores;



centros de processamento de dados passaram a ser responsáveis apenas pela operação e manutenção dos recursos computacionais;



alto volume de dados e informações processadas.


A Computação Distribuída Esta foi uma das causas que mais contribuíram para o agravamento da Desorganização Informacional (DoI) tanto nas organizações como na nossa vida particular. Sem outras análises é possível atribuir à computação distribuída a exacerbada proliferação de dados einformações que nos aige nos dias de hoje (sem falarmos na Internet, que criou novos paradigmas para a DoI). É fácil entender o porquê desta minha armação. Pense, de forma análoga, no que acontece com qualquer um de nós, dentro de nossas casas, quando não somos organizados o bastante ou como deveríamos ser para colocarmos tudo em ordem. O que é que acontece? Nunca sabemos onde está a chave do carro simplesmente porque há muitos lugares onde podemos colocá-la. E as gavetas então? Quantas temos e quantas usamos para espalhar tudo que queremos, ou necessitamos guardar? E todos aqueles documentos importantes, como as certidões, os diplomas, as cópias reprográcas do CPF, do RG, o título de eleitor etc? Onde estão eles quando os necessitamos? Pois é. No mundo das organizações acontece a mesma coisa, mas com um agravante: não conseguimos procurar a olho nu tudo que queremos ou necessitamos encontrar nos computadores, e isto torna a nossa busca extremamente difícil, muitas vezes complexa, demorada e por isso cara. A computação distribuída, gura 1.6, foi desenvolvida por fabricantes como a Hewlett Packard, HP, a Digital Equipment Corporation, DEC (que foi comprada pela Compaq; que depois foi comprada pela HP) para fazer frente, entre outros objetivos, à hegemonia da IBM, praticamente a última dos grandes fabricantes de mainframes que existiram no passado18. Foi a computação distribuída que proporcionou aos usuários nais deTI o “completo domínio” (?) sobre seus dados, informações econhecimentos funcionais (e pessoais), mas, em contrapartida, acelerou a Desorganização Informacional, provocando o maior caos documental de que a raça humana tem notícia até hoje. Entretanto, além de possibilitar aos usuários odomínio sobre

18. Sem nos esquecermos dos fabricantes japoneses que continuaram a construir máquinas deste porte, mas que não tinham presença signicativa junto ao mercado de computação comercial.

34 BPM & BPMS

seus dados e informações, a computação distribuída, por descentralizar os recursos computacionais, foi uma das responsáveis por revelar à própria organização seu modus operandi, ou seja, foi a partir dela que os processos de negócio passaram a ser vistos, reconhecidos, entendidos e gerenciados. Não foi por acaso que Michael Hammer lançou em 1990 o libelo em favor da reengenharia e, pouco tempo depois, junto com James Champy, escreveu o famoso livro E nem foi pormelhoria acaso que na pregação emsobre favor odatema. organização e da dosDavenport processosembarcou de negócio. Todos são oriundos da área de TI e se basearam na computação distribuída para reforçarem as ideias que já haviam sido defendidas por outros; principalmente por Deming com o ciclo PDCA e Juran com a espiral da qualidade. Convém relembrar que na computação centralizada todos os usuários estavam ligados a um computador central; dependiam dos analistas de sistemas e dos programadores para desenvolverem e para programarem “seus” sistemas de informações, mesmo os mais simples; e o CPD tinha total domínio sobre os recursos computacionais disponíveis na organização. Este modus operandi impedia que as organizações enxergassem a si mesmas como um todo, pois cada funcionário em cada área enxergava somente o seu pedaço. Salvo, é claro, raras exceções, como a área de produção nas manufaturas e de transformação, que desde a Revolução Industrial já havia entendido que sem processos, mesmo que informalmente organizados, não há como produzir nenhum produto. Entre as décadas de 60 e 70 surge uma ideia que podia ter dado certo e até mesmo ter contribuído para organizar os processos, primários e secundários, e ter, quem sabe, evitado o descontrole que se seguiu a partir da computação comercial, mas aquela ideia não conseguiu, por inúmeros motivos, cumprir corretamente sua nalidade. Seu nome: O&M. Então, enquanto os processos fabris se organizavam mais e mais a cada dia, os processos administrativos se desorganizavam, muitas vezes, numa proporção maior. No início da computação distribuída não havia softwares que permitissem às organizações colocarem os conceitos de ofce automation em prática. Se por um lado este fato retardou a proliferação de um tipo de ocorrência que hoje se encontra espalhada por toda a organização e é uma das piores manifestações da Desorganização Informacional, os chamados “arquivos-


do-usuário”, por outro fez com que o conceito cliente-servidor demorasse a ser adotado pelas organizações. Entretanto, a partir do surgimento dos aplicativos que permitiram a criação dos “arquivos-do-usuário”, manifestação importante da DoI, vários estudiosos e pesquisadores começaram a tratar de um tema bastante atual: as informações desestruturadas, aliás estudos ligados ao surgimento do BPM. A computação centralizada multiprocessamento introduziu contato direto dos usuários com com máquinas os mainframes por meio de terminais cha-o mados de “burros” porque não tinham capacidade de processamento; mas foi somente com o surgimento da computação distribuída que os usuários passaram a ter maior liberdade em relação ao domínio do CPD para assumirem de vez o controle sobre os recursos computacionais que as organizações passaram a possuir.

Figura 1.6 – Computação distribuída.

36 BPM & BPMS

Claro, os grandes fabricantes de Tecnologias da Informação não somente fomentaram e incrementaram como pressionaram as organizações para que elas adotassem o modelo computacional computação distribuída – arquitetura cliente-servidor, pois isto possibilitou à indústria de TI a venda de milhões de computadores em todo o mundo. Para tanto, os grandesfabricantes de tecnologias “criaram”, “desenvolveram” e encorajaram osurgimento de formadores de opinião que pregavam que a computação distribuída era “A” revolução, “A” solução que possibilitaria às organizações quebrarem paradigmas, estarem à frente dos seus concorrentes, serem inovadoras. E todos nós sabemos que não é nada disso; que nenhuma tecnologia servirá para alguma coisa se não tivermos, além de uma ideia na cabeça e um computador na mão19, planejamento e soubermos nos organizar para implantar e utilizar atecnologia. Também não foi por acaso que empresas como a HP investiram em especialistas que escreveram livros nos quais pregavam as maravilhas deste novo (à época) tipo de computação e chamavam a atenção das organizações para a quebra de paradigma que a computação distribuída – arquitetura cliente-servidor iria proporcionar. Lembro-me, pois ainda trabalhava na HP, quando a computação distribuída foi lançada em escala comercial, na década de 80, e começaram a surgir também diversos softwares que exploravam o conceito de cliente-servidor, ou computação em três camadas (three tier computing). Esta divisão na utilização dos computadores por tipos diferentes de processamento exigia novos e constantes investimentos em hardware e em software, o que por algum tempo salvou muitos resultados nanceiros e operacionais dos fabricantes de tecnologias da informação, além de ter alavancado a carreira de muito executivo da área. Nós no Brasil, na década de 80, ainda sofríamos os efeitos de uma política de informática que premiava uns poucos em detrimento da maioria e principalmente do desenvolvimento do país. Por isso entramos muito lentamente na era da computação distribuída; o que de certa forma deixou vários e importantes segmentos industriais defasados em relação aos concorrentes estrangeiros. Este tipo de “proteção” que o Brasil deu à indústria nacional de computadores foi determinante para a falência de muitas empresas, em

19. Parafraseando o cineasta Glauber Rocha, expoente do cinema novo, que dizia que fazer cinema era fácil, bastava ter uma ideia na cabeça e uma câmera na mão!


vários segmentos industriais, e perdurou até no início de 1990, quando Fernando Collor de Melo decidiu abrir os portos às importações. Voltando aos efeitos que a computação distribuída provocou nas organizações, chegamos à era da automação de escritórios (Ofce Automation) e do surgimento dos pacotes genericamente chamados de Ofce.

O Mito Chamado Office Automation O primeiro livro publicado sobre Ofce Automation (OA) foi The Ofce of the Future, escrito por P. Ronald Uhlig, David Farber e James H. Bair em 1979. Assim sendo, este mito surgiu muito antes que outros até mais importantes como, por exemplo, os mitos ligados ao Computer-Supported Cooperative Work. O conceito de Ofce Automation foi criado buscando fazer as pessoas acreditarem que seria possível transferir as funções antes existentes nos grandes sistemas de informações para softwares ditos “amigáveis” por estarem ao alcance das mãos de qualquer funcionário dentro das organizações, além de prometer um mundo no qual o aumento da produtividade diminuiria o número de horas efetivamente trabalhadas. Nenhuma das duas promessas se cumpriram! Nem foi possível transferir funções antes existentes nos grandes sistemas de informações para softwares ditos “amigáveis” e nem, muito menos, o aumento da produtividade diminuiu o número de horas efetivamente trabalhadas, a não ser, é claro, para o De Masi, com a sua teoria sobre o ócio criativo. Muito pelo contrário, as pessoas que ainda têm emprego hoje, tanto o formal quanto o informal, trabalham em média 20% de tempo a mais do que trabalhavam duas décadas atrás. O Ofce Automation foi a primeira tentativa da indústria de TI de cumprir as promessas que a introdução dos minicomputadores e dos microcomputadores haviam feito: novas e sosticadas formas de interação entre as pessoas de um mesmo departamento, ou de departamentos diferentes, em contraposição às formas de interação existentes até então via sistemas de informação grandes e complexos, que rodavam nos mainframes e que, por estas características, cavam longe do alcance dos usuários. Embora, com a computação distribuída, os usuários já não precisassem da intermediação do CPD para inserir seus dados nos computa dores, pro-

38 BPM & BPMS

cessá-los e acessá-los, pois o faziam por meio dos terminais “burros”, eles continuavam dependendo dos analistas de sistemas e do próprio CPD para integrá-los a outros sistemas, por meio de vários artifícios, entre os quais os bancos de dados, estruturais e relaciona is, e os programas chamados interface . Muitos consideram a Automação de Escritório como a primeira tentativa que os pesquisadores paraem desenvolver tecnologias que pudessem tivamente suportarzeram o trabalho grupo de forma harmoniosa, embora efefossem pacotes compostos por programas individuais. Mas o Ofce Automation falhou nas suas intenções porque as empresas que criaram os programas baseados neste conceito não entenderam, e por isso não souberam traduzir para os softwares, as reais necessidades dos usuários. Embora cada autor tenha sua própria denição para Ofce Automation, reproduzo a que mais se aproxima do cerne do conceito OA. Ofce Automation is the use of computers in ofces to sup port knowledge workers who are not computer specialists. Bair and Mancuso, 198520.

É interessante notar que a explícita preocupação com os “trabalhadores do conhecimento21”, em contraposição (e até mesmo em detrimento) aos trabalhadores operários (chão de fábrica) sempre foi uma característica defendida fortemente pelos que apregoavam as virtudes do Ofce Automation como forma de disseminar o uso da computação distribuída num ambiente que ainda não trabalhava de forma cooperativa e nem baseado em processos, enquanto que o chão de fábrica sempre teve seus processos ordenados, por pior que fossem a organização e as condições de operacionalidade de cada um deles. Os objetivos da Automação de Escritório foram assim descritos:

20. “A automação de escritório (ofce automation) é o uso de computadores nos escritórios para dar suporte aos trabalhadores do conhecimento, que não são especialistas em computação. ” 21. Também é interessante atentarmos para o detalhe do ano, 1985, em que os dois especialistas de Ofce Automation falam em trabalhadores do conhecimento; pois só recentemente (outra moda?), por volta do nal dos anos 90, apareceram os teóricos da gerência do conhecimento.

As (R)Evoluções de TI 39 

diminuir os custos indiretos nas organizações;



incrementar os negócios sem aumentar as contratações;



aumentar as receitas e diminuir os custos diretos;



diminuir os custos de viagens de negócio intra-organização;



diminuir o tempo usado para a geração de relatórios;



diminuir o tempo gasto e, consequentemente, as despesas com telefonemas e com reuniões;



diminuir o volume de papel sistematicamente gerado nas organizações.

Estes objetivos foram traduzidos de uma das “bíblias” do Ofce Automation: The Ofce Systems Cycle, editado e publicado pela Hewlett Packard Co., em 1985; que, aliás, tinha grande interesse em disseminar as “vantagens” do Ofce Automation para poder vender mais e mais computadores. Em outras palavras, estes objetivos de OA não foram criados ou inventados por mim, mesmo eu tendo vivido de perto os acontecimentos daquela época. Voltando aos objetivos citados, eu gostaria que você zesse um exercício simples, mesmo que não saiba ao certo o que é Ofce Automation, e respondesse às seguintes questões: 

Quantos daqueles objetivos foram concretizados?



Quais deles você nunca ouviu a indústria de TI prometer?



Quais promessas você já viu a indústria de TI cumprir?



A organização onde você trabalha, ou se não trabalha conhece, pode ser considerada um modelo a ser seguido por ter atingido os objetivos anteriormente listados?

Há uma só resposta. Não! Não somente TI não conseguiu cumprir várias promessas - e os mais radicais vão dizer nenhuma delas - como a Desorganização Informacional sempre aumentou a partir das novas! Por quê? Porque a solução não está, nunca esteve e nem nunca estará em qualquer Tecnologia da Informação.

40 BPM & BPMS

A solução chama-se organização ; ou mais precisamente, análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio; para só então as Tecnologias da Informação serem usadas com sucesso. Pode ser, ou parecer, simplória tal armação; mas espero que ao chegar ao nal do livro você possa me dar razão.

Os Pacotes Office Automation Editores de texto, planilhas eletrônicas e editores de apresentações foram os primeiros programas baseados no conceito de Ofce Automation que apareceram no mercado para “facilitar” a vida dos usuários. Por isto são vistos por mim como o início efetivo da confusão que viria a se propagar rapidamente no mundo todo e a qual estou denominando Desorganização Informacional, DoI. É desta época o surgimento de algumas promessas feitas por TI que, ainda hoje, perduram não cumpridas entre nós, como, por exemplo: 

só as Tecnologias da Informação podem organizar as empresas;



TI aumenta a produtividade das organizações;



o aumento da produtividade proporcionada por TI diminuirá o número de horas efetivamente trabalhadas;



as Tecnologias da Informação não vieram para desempregar, mas para mudar as características dos empregos existentes;



a automação de escritório (ofce automation) vai humanizar o trabalho nas organizações;



o trabalho cooperativo será possível por meio de novas Tecnologias da Informação.

Mais recentemente promessas vieram a se juntar às existentes:  a Internet incluirá digitalmente todos os povos e nações; 

Workow é o único software que pode transformar as organizações de function oriented para process oriented.


E a mais recente: 

BPMS é o software que vai integrar, lógica e cronologicamente, clientes, fornecedores, parceiros, inuenciadores, empregados, acionistas e todo e qualquer elemento que com eles possam, queiram ou tenham que interagir.

Na verdade a falha não é das Tecnologias da Informação. Tecnologias não são levianas! A falha é de quem as vende, por prometer o que elas não podem cumprir; e de quem as compra, por acreditar em poderes que estão além da atual capacidade funcional de qualquer Tecnologia da Informação. Uns e outros esperando resolver por meio das tecnologias problemas culturais, organizacionais, estratégicos e operacionais dentro do círculo vicioso de “comprartecnologias-para-resolver-problemas-e-resolver-problemas-por-ter-comprado-tecnologias”.

O Papel dos Editores de Textos na DoI Antesdedoescrever aparecimento dos editores deos textos as pessoas máquinas ou escreviam à mão documentos, queusavam necessitavam ou queriam produzir, tanto nas organizações quanto na vida particular. Os arquivos eram centralizados em pastas ou em armários e isto possibilitava a todos o acesso (nem sempre ordenado), na maioria das vezes rápido, a qualquer documento que fosse necessário. Quando um determinado documento não estava nos arquivos onde deveria estar, buscava-se o mesmo, no máximo, na mesa ou na gaveta de quem o havia gerado ou recebido, ou com as pessoas que trabalhassem no local. Nós os perdíamos? Sim, nós os perdíamos, mas muito dicilmente. A não ser deliberadamente (quando queríamos, ou precisávamos, que algum documento desaparecesse). Todas as organizações tinham uma área, conhecida como ARQUIVO MOR22 TO , onde cavam os documentos históricos utilização ou utilidade paraguardados as operações do dia a dia e, tambémou ali,de ospouca documentos eram, via de regra, achados com facilidade, pois estes espaços contavam com funcionários dedicados exclusivamente a administrá-los. Hoje, estes

22. Hoje chamamos esta área de arquivo inativo.

42 BPM & BPMS

espaços ainda existem, mas principalmente para guardarem documentos contábeis, scais ou outros obrigatórios por força de lei. As diculdades então existentes para criarmos, mantermos, arquivarmos e recuperarmos documentos eram as barreiras naturais que impediam as organizações de criar documentos desnecessários e perder o controle sobre a memória das operações. A não ser, claro, para organizações governamentais, área propensa a exacerbar negativodedadispositivos burocratização por, entre outros motivos, se ver obrigada oa lado isto através legais. Por exemplo, não havia nem a necessidade, nem a possibilidade de serem criadas versões para um mesmo documento. Cópias existiam, mas eram caras e controladas. A rigor os arquivos só desapareciam quando pegavam fogo; jamais por obra de um crash de disco magnético, ou porque o sistema operacional resolveu “abortar” no m da criação de um documento e antes que ele tivesse sido gravado no disco rígido. Não estou aqui assumindo o papelde luddita23, mas apenas constatando e falando sobre uma realidade. Além disto, penso que sejanecessário comparar as duas realidades (antes e depois dos editores de texto), para que eu possa explicar comoinúteis; chegamos aos diasaqueles de hoje gerando documentos ou perdendo que não quantidades poderiam serabsurdas perdidos.de Eu mesmo, algumas vezes, já fui surpreendido por uma das catastrócas eventualidades da Desorganização Informacional. Em 1986 estava terminando o livro Manual de Sobrevivência Empresarial quando numa madrugada a fonte do microcomputador pegou fogo. Sorte que eu estava trabalhando e rapidamente pude controlar o incêndio. Entretanto, quei com o livro inacessível por meios normais. Mudei o disco rígido de computador e...nada. Para resumir, gastei, àquela época, algo como dois mil dólares (a paridade era mais ou menos de 1 para 1), para poder ter o livro, que já estava praticamente pronto, acessível de novo. Se eu tivesse

23. Pessoa que é simpatizante ou militante do Luddismo, movimento coletivo que se estendeu pela Inglaterra no início do século XIX. O Luddismo era contrário à mecanização do trabalho, visava a destruição das máquinas, responsabilizando-as pelo desemprego e pela miséria social nos meios de produção. O operário Ned Ludd é apontado como criador deste movimento, embora existam historiadores que armem que ele nunca existiu; mas o movimento existiu sim.


salvado o arquivo do livro em outra mídia toda vez que eu encerrava o trabalho, quem sabe, eu não teria gasto tempo e dinheiro para recuperá-lo. Bem mais recentemente comprei um notebook e, com apenas seis meses de uso, o disco rígido “morreu”. Desta vez, por estar bem mais esperto e ter aprendido com as experiências passadas, perdi apenas 20% do conteúdo do HD. Coisa sem importância, mas perdi, pois não dá para fazer backup de 80 GB toda hora! Contudo, tenho ainda muitos trabalhos de faculdade guardados em pastas; alguns manuscritos, com os quais nunca enfrentei problema de versão do software quando quero reler algum deles. No nosso dia a dia, trabalhando como analistas de processos, nos deparamos com as mais variadas manifestações de Desorganização Informacional e algumas beiram o absurdo. Por exemplo, as pessoas geram grandes quantidades de documentos em editores de textos (popularizados pela marca Word da Microsoft, embora, como sempre, não tenha sido o primeiro editor de texto do mercado) sem qualquer controle ou organização gravação recuperação. raro há muito documento que a rigorpara nemsua deveria existir.e Existe porque éNão fácil e rápido criá-lo e a organização (empresa, instituição etc.) nem sabe que ele existe; o que nos deixa impunes como principais agentes causadores da Desorganização Informacional. Os editores de texto existentes hoje estão, em tecnologias e funcionalidades, muito além das nossas necessidades mais comuns, o que signica dizer que eles embutem funcionalidades que na maioria das vezes não serão usadas pela maioria dos usuários. Esta característica não é exclusiva de softwares, programas e ferramentas, mas de tudo que a indústria de TI produz. Há deliberadamente a intenção de fazer com que tudo que esta indústria produz seja maior, não necessariamente melhor, para forçar nas pessoas o desejo do “ter pelo ter” e, obviamente, possa custar mais para ser vendido por um preço maior. Por exemplo, quem é que usa as funcionalidades do Word para gerar e trabalhar documentos em grupo, controlando as diversas versões de um mesmo documento dentro do próprio editor de textos? Quem é que usa as funcionalidades de indexação de documentos? E a funcionalidade de ge-

44 BPM & BPMS

ração do índice remissivo, quantos de nós a utiliza? Quase desnecessário dizer que para muitos (e muitas) de nós o computador é apenas uma máquina de escrever mais sosticada; o que não reduz sua importância na nossa sociedade (a máquina fará o que dela quisermos, pudermos ou necessitarmos que ela faça) até que se invente uma que possa assumir as rédeas do seu próprio destino. A criação de que textos sem que osarquivamento dados que eles contêm recuperação tenham qualquer organização possibilite seu e posterior produz todos os dias um número absurdo de documentos cuja guarda se dá de forma completamente desestruturada, pois na verdade os próprios documentos contêm informações desestruturadas, prática desastrosa tanto para as organizações como para as pessoas que nelas trabalham. Todos nós perdemos muito tempo procurando em dezenas, centenas de arquivos eletrônicos pelo texto que precisamos encontrar.

O Papel das Planilhas Eletrônicas na DoI De forma recorrente temos que voltar às srcens do Ofce Automation (OA) para entendermos por que as planilhas eletrônicas se proliferaram e se transformaram no que hoje eu considero ser uma praga fora de controle, um dos piores sintomas da DoI. No início da sua utilização por parte das organizações as planilhas eletrônicas foram usadas como máquinas calculadoras mais sosticadas que suas irmãs de “carne e osso”, as máquinas existentes, à época, à base de manivelas (como as da marca Facit) e as primeiras “maquininhas eletrônicas” de cálculo, que tanto sucesso zeram nos nossos anos de faculdade. Houve planilhas eletrônicas famosas como a Quattro Pro, precursora neste segmento que também foi atropelado pela Microsoft com a planilha Excel. Planilhas eletrônicas como a Quattro Pro invadiram os microcomputadores dos departamentos nanceiro e contábil das organizações no início da proliferação dos microcomputadores e da computação distribuída e reinaram absolutas por quase dez anos, até que (de novo) a Microsoft colocou um m à pluralidade e à possibilidade de escolha que os usuários tinham e, lançando a Excel, monopolizou o segmento. Mas não me interessa estar aqui escrevendo contra a Microsoft e sim explicar como as planilhas eletrônicas, mais que qualquer outro programaOfce


Automation, contribuíram e continuam contribuído de forma signicativa (e ainda mais absurda) para a exacerbação da Desorganização Informacional.

Aqui está um exemplo vivido por mim: em 1991, quando da implantação de um novo sistema de informações numa empresa onde eu era diretor de informática, descobrimos um funcionário, na contabilidade, que para fazer o fechamento do mês tinha construído sete planilhas (o número é este mesmo), para cada grupo de contas e uma aoitava sete euma nalmente gerar a planilha denitiva, nona!para consolidar todas as Acabamos com todas as planilhas, não sem termos que convencer “fortemente” o funcionário de que com o novo sistema ele não precisaria mais de tantas planilhas (cou só com uma). De forma jocosa as pessoas diziam que a quantidade de planilhas existentes era necessária porque elas não conavam nos sistemas de informações e as usavam para conferir se os sistemas haviam processado os dados corretamente! Absurdo? Já vivi e tive conhecimento de casos bem mais graves de descontrole e consequente Desorganização Informacional. Mais recentemente, em um cliente onde desenvolvíamos um projeto de análise, mapeamento e modelagem de processos negócio, descobrimos o sistema que a diretoria nanceira usava nãode atendia nem a 30% das que ne cessidades gerenciais – embora operacionalmente o sistema também não fosse lá grande coisa – e isto havia provocado uma proliferação descomunal de planilhas eletrônicas. Tudo, absolutamente tudo, que eles necessitavam fazer, de gerar dados a relatórios gerenciais, eles faziam por meio de planilhas eletrônicas e usavam o sistema apenas para gravar nos bancos de dados corporativos os resultados obtidos nestas planilhas. Todos os funcionários do departamento se compraziam em falar sobre como eles tinham criado as planilhas e as respectivas rotinas de carga, descarga e integração dos dados com os bancos de dados do sistema. Cada um deles queria nos mostrar seu conjunto de planilhas e o faziam chamando nossa atenção para a sosticação com que elas tinham sido construídas. Pense na Desorganização Informacional que este tipo de atitude gera e alimenta dentro da organização. Isto sim são situações absurdamente perigosas tanto do ponto de vista organizacional quanto operacional. Inacreditável! Cada funcionário criando e mantendo dezenas de planilhas eletrônicas, raramente compartilhadas com outros funcionários do mesmo grupo e menos ainda com quem não faz parte do departamento.

46 BPM & BPMS

E a organização, a empresa, a instituição, então? Completamente às cegas. Numa eventualidade qualquer, as planilhas podem sumir de uma hora para outra sem deixarem rastros e sem que ninguém que sabendo. A situação de Desorganização Informacional que todas as organizações enfrentam hoje, sem exceções, tem nos softwares de planilhas eletrônicas uma das principais causas e nas próprias planilhas seus efeitos mais “visíveis.” Esta importância reside no fato delas servirem para dar suporte tanto a decisões operacionais quanto a decisões gerenciais, o que também signica dizer que tanto o planejamento quanto a execução das operações estão igualmente em perigo.

O Papel de Outras Tecnologias na DoI Mais recentemente a Desorganização Informacional ganhou novos, importantes e fortíssimos aliados. Um destes é a própria Internet e todas as suas manifestações, como e-mails, conteúdos dos mais variados tipos e novas tecnologias web, como a que atende pelo nome deService-Oriented Architecture (SOA) e sobre a qual falarei detalhadamente mais adiante neste livro. Particularmente, acho que já perdemos o controle sobre as Tecnologias da Informação ou, no mínimo, estamos bem próximos disso. Parece a todos nós que os dados, as informações e o conhecimento geram a si mesmos (paterno gênese ou autopoesi? Você escolhe) quase que espontaneamente, numa espiral ascendente e cuja boca superior só faz aumentar (análoga às bocas das espirais dos tornados e furacões). Além dos casos relatados aqui, você mesmo pode fazer um levantamento no seu local de trabalho e constatar, sem muito esforço, o que estou dizendo. Recentemente num cliente, também quando conduzia um projeto de análise, mapeamento e modelagem de processos de negócio, tomeiconhecimento do seguinte drama: um umasistema determinada organização, com quase funcionários, 24 decidiu comprar de discos para centralizar todos mil os HD que proliferaram e continuavam a proliferar por meio das dezenas de servidores. O equipamento, de última geração e caríssimo, com a capacidade de dezenas

24. Hard Disk.


de terabytes, chegou, foi instalado e a área de operações migrou, um a um, todos os bancos de dados dos servidores corporativos para dentro do disc“ array.” Tudo correu dentro do previsto e planejado, até porque o pessoal de operações era (e é) muito bom tecnicamente, até que chegou a horade migrar o servidor que continha os arquivos “pessoais” de todos os funcionários da organização, aqueles arquivos que chamamos de “arquivos dos usuários”. Pronto! Estava caos! Perguntas, as listadas adiante, foram feitas semestabelecido que ninguémo se arriscasse a darcomo qualquer resposta: Quais arquivos migrar? Quais arquivos eram válidos? Quais arquivos eram “lixo”? Migrar (tudo) ou não migrar? Eis a questão! Neste ponto o gerente da área de TI mandou suspender a migração. Os tais “arquivos dos usuários” já ocupavam mais de dois terabytes (!) e o gerente de TI queria que o supervisor da área de operações migrasse somente aqueles arquivos que fossem importantes (?) ou os que tivessem sido atualizados nos últimos seis meses ou, em última hipótese, os que não fossem lixo (?). Resultado: a migração parou e travou25. A ideia do gerente de TI era boa e cheia de racionalidade; entretanto, a organização não possuía nenhuma política ser de ocupação e aos uso usuários dos recursos computacionais e de backup que pudesse usada junto para justicar tal decisão, fosse qual fosse a que viesse a ser tomada. E mais, ele queria que o supervisor da área de operações assumisse o ônus do desgaste junto aos usuários por “forçá-los” a se desfazerem das suas “inutilidades”. Óbvio que o chefe da área de operações disse não, pois não tinha como fazer uma migração seletiva, uma vez que não havia política de uso dos recursos e muito menos a organização possuía um software adequado para executá-la e consequentemente não havia como ele justicar junto aos usuários a não migração dos seus arquivos. Sem falar que junto também estavam os arquivos de usuários como o presidente, os diretores... O gerente da área, por sua vez, não quis assumir uma postura “ditatorial” frente à organização e obrigar os usuáriosdos (entre eles osinúteis. diretores e o próprio presidente da instituição) a se desfazerem arquivos O custo político de tal decisão é sempre altíssimo e pode até mesmo derrubar um gerente. E assim os dias foram passando, passando, até que por uma destas “coinci25. Lembra da fábula dos ratos que queriam pendurar um guizo no rabo do gato, mas nenhum se dispunha a fazê-lo? Pois é, aqui também ninguém queria assumir a responsabilidade.

48 BPM & BPMS

dências” típicas da Desorganização Informacional o tal servidor que continha os arquivos pessoais de todos os funcionários da organização pifou. Conclusão: a área operacional teve que apagar um tremendo incêndio, recuperando todos os backups de todos os terabytes que estavam no antigo servidor para migrá-los, ipsis litteris, “a toque de caixa” para o novo equipamento (o caríssimo disk-array) depois de quase três meses de desgaste interno na área de TI. Seis meses depois dos acontecimentos, conversando com o supervisor da área de operações, soube que a tal política de uso e backup dos recursos computacionais da organização sequer tinha sido escrita para poder ser discutida com todos e posteriormente implantada. Ou seja, a situação continuava a ser uma bomba, armada e pronta a explodir a qualquer momento! A proliferação de todas as “facilidades” que as Tecnologias da Informação nos trouxeram e continuam a nos trazer em ondas sucessivas requer que sejam utilizadas depois de decisões cuidadosamente analisadas e rmemente tomadas, que se convertam em ações determinadas por uma vontade férrea de consertarmos a parte que nos cabe na Desorganização Informacional. Creio que há várias soluções para minorarmos (acabar é impossível) a proliferação das causas e consequentes efeitos da DoI. Por exemplo, as organizações precisam: 

parar de dar ouvidos a “gurus” que (muitos pagos para isto, veja nota no rodapé26) juram sempre que a última tecnologia é muito

26. Especialistas em tecnologia cobram para elogiar produtos, diz jornal. (Folha Online de 20/04/2005 - 11h10). O editor de tecnologia e apresentador do programa “Today”, da rede NBC, conrmou ter recebido dinheiro da Apple, Sony, Hewlett-Packard, Seiko Epson, Creative Technology e Energizer Holdings para falar bem de produtos dessas empresas. De acordo com o apresentador Corey Greenberg, cobrava US$ 15 mil para fazer comentários positivos relacionados a esses eletrônicos. Emele julho do ano passado, por exemplo, ele falou durante o “Today” que o iPod é um ótimo produto e tem o visual mais moderno entre todos os tocadores. A denúncia, feita em primeira mão pelo “The Wall Street Journal”, ganhou destaque na edição de hoje do “The Washington Post”. Funcionários da NBC armaram desconhecer a realização desse tipo de pagamento e armam que tornaram sua política em relação ao assunto mais rígida. Greenberg nega que isso seja verdade. “Desde que passei a contribuir com o ‘Today’, em 2000, comuniquei a NBC sobre esse meu trabalho extraocial. Fui muito sincero com eles”, disse ao “The Washington Post”.


melhor que a penúltima, que era muito melhor que a antepenúltima, que era muito melhor que27...; 

identicar e eliminar as causas endógenas da DoI, por meio de projetos que visem conscientizar e alertar a todos os funcionários e parceiros sobre a severidade dos malefícios decorrentes desta doença;



escrever suas políticas, normas e outros documentos que têm por objetivo orientar a conduta de todos na organização antes que qualquer tecnologia seja comprada e implantada e



fazer análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria dos processos de negócio antes de virem a pensar em adotar qualquer Tecnologia da Informação.

Evidentemente são providências, salvo a última, relativamente simples, embora requeiram determinação para serem tomadas e implantadas. Entretanto, muito mais graves e críticas são as decisões que temos que tomar quando acontecem situações como a da migração de dados descrita antes. A Desorganização Informacional atinge a todas as organizações de qualquer tipo e tamanho. Nenhuma empresa, instituição, organismo, nem mesmo os organismos militares, estão a salvo.

27. O presidente de uma empresa desenvolvedora de software me confessou certa vez que havia pago dez mil dólares para que seu produto fosse “muito bem avaliado” e “muito bem classicado” frente aos concorrentes e que tal classicação não havia sido melhor porque sua empresa ainda tinha um faturamento muito pequeno.

2 A Desorganização Informacional Novas “patologias”, como ser dependente do e-mail, passar longas horas conversando nos programas de mensagens on-line em detrimento do contato físico pessoal, participar de centenas de comunidades (e receber toda a correspondência eletrônica gerada por elas), provocam nas pessoas comatédoentão de difícil consultem tratamento.seu Emcorreio particular, aportamentos dependência e-maildesconhecidos faz com que ase pessoas eletrônico de minuto em minuto ou o programem para de minuto a minuto haver uma atualização automática da correspondência na caixa de entrada. Um dos objetivos deste livro é o de discutir um mal que eu batizei de Desorganização Informacional (DoI). Os outros objetivos são apresentar o conceito e algumas metodologias do BPM (Business Process Management) e o software batizado de BPMS (Business Process Management System), que a indústria de TI insiste em nos fazer crer ser radicalmente novo e aderente a todos os elementos presentes no ambiente de negócios, quando na verdade, como mostrarei neste livro, novo ele não é. No meu capítulo especíco sobre de esta software vou explicardapor que no entender a indústria TI classe apelou de para uma revitalização marca Workow, batizando-o de BPMS, embora reconheça que neste último tenha havido aumento de funcionalidades por meio da adição de componentes que no Workow eram vendidos separadamente. Mas antes vamos entender o que é a Desorganização Informacional (DoI). Eu a deno como:

A Desorganização Informacional 51

Doença causada pelo uso incorreto e/ou inadequado ou, ainda, ocasionada pelo mau funcionamento das Tecnologias da Informação.

A Doença e seus Sintomas A Desorganização Informacional (DoI) pode ser descrita como a perda de controle, da nossa parte, quer como indivíduos quer como coletividade (organizações), sobre os meios de geração, captura, guarda, recuperação e difusão de dados, informações e conhecimentos. Por isso a DoI se manifesta tanto na nossa vida prossional quanto na nossa vida particular. A Desorganização Informacional tem vários graus, pois ela acomete diferentemente pessoas e organizações. Além disso, dependendo do remédio que pessoas e organizações venham a tomar (e dependendo da posologia) poderá haver evolução da doença para a fase terminal; ou a regressão a níveis de convivência aceitáveis (se é que é aceitável ser desorganizado). DoI é incurável, mas existe a possibilidade de controle da doença. Embora a Desorganização Informacional seja por demais perturbadora, é preciso reconhecer que as Tecnologias da Informação têm papel fundamental na nossa sociedade. TI tem seu lado “bom” e seu lado “ruim”. Entretanto, tanto um quanto o outro aoram e se conrmam pelo uso que dela fazemos. Por que discutir a Desorganização Informacional em um livro sobre Business Process Management? Primeiro porque, como estudioso dos meios e condições de usabilidade das Tecnologias da Informação, tenho vivido situações que, desde minha iniciação no mundo de TI nos idos de 1960, muito me preocupam. O descontrole sobre a produção, a guarda e a recuperação de dados, informações e conhecimentos gerados a partir do contato com estes dados e informações, embora tenha criado problemas signicativos, também possibilitou o desenvolvimento (de certa parcela) da população mundial. O que parece ser contraditório é na verdade apenas mais uma das características das Tecnologias da Informação.

52 BPM & BPMS

Também precisava criar uma gura que me permitisse contextualizar e explicar o software BPMS, e o conceito e metodologias BPM, expressão em moda neste início de século; e que, segundo a indústria de TI, além de novas formas de administrar, introduziu, também, novas Tecnologias da Informação – com o que não concordo, pois Business Process Management não é um novo conceito e nem BPMS é uma nova tecnologia, como a indústria de TI quer nos fazer acreditar. Discutir a Desorganização Informacional pode nos ajudar a entender a situação em que todos nós nos encontramos hoje em face da quantidade e principalmente da forma e da utilização de dados, informações e conhecimentos disponíveis em todos os cantos do planeta. Esta situação é alimentada por uma sucessão de acontecimentos, entre estes as (r)evoluções de TI, que vêm aumentando a confusão na qual nos afundamos ao utilizarmos erroneamente e tautologicamente a mesma TI. A DoI afeta-nos como pessoas e, muito mais, às organizações onde nós trabalhamos, por serem aglomerados de pessoas que necessitam interagir com outras pessoas (atores de todos os tipos) para realizar suas obrigações. Finalmente, precisava explicar por que processos de negócio estão diretamente relacionados com este tipo de doença. Não que eles sejam causa ou parte dela, pelo contrário, são parte do receituário que, se bem administrado, pode minorar o sofrimento causado pela DoI. Entretanto, como terei oportunidade de discutir, processos não têm sido adequadamente tratados, o que agrava a Desorganização Informacional, colocando-nos num círculo vicioso sem m.

Exemplos de Desorganização Informacional Existem aos milhares, mas vou listar apenas alguns. 1. Segundo alguns institutos de pesquisas da área de TI, atualmente mais de 80% dos negócios são conduzidos com informações não estruturadas. Isto faz com que seja extremante difícil guardar e, principalmente, recuperar informações no momento em que delas temos necessidade. 2. 85% de todos os dados armazenados estão em formato não estruturado, segundo o Butler Group. Em outras palavras isto quer dizer que na hora em que precisarmos destes dados iremos,


provavelmente, perder um enorme tempo até encontrá-los, se e quando os encontrarmos, pois na maioria das vezes não sabemos sequer por onde devemos começar a procurá-los. 3. Os especialistas calculam que a quantidade de dados não estruturados duplica a cada três meses (e vem aumentando sem parar), o que signica dizer que a situação de Desorganização Informacional tende a se agravar. 4. A quantidade de documentos, de todos os tipos e formatos, não para de crescer em nossos computadores, assim como aumenta a quantidade dos que perdemos todos os dias quer eles estejam em computadores pessoais, quer estejam em computadores corporativos na empresa onde trabalhamos. 5. A quantidade crescente de senhas (e contrassenhas) para acessar contas correntes, cartões de crédito, cadastros de lojas eletrônicas, sites e mais sites causa estresse contínuo e progressivo àqueles que tentam guardar todas elas na memória e grandes riscos aos que as transcrevem em qualquer suporte. 6. A cada dia mais e mais fazer aparelhos e equipamentos são criados e vendidos prometendo (e realmente fazem) mais do que sua função srcinal exigiu um dia. Esta tendência aumenta a Desorganização Informacional. Por exemplo: os telefones celulares atuais tiram fotos, enviam e recebem documentos de todos os tipos, compram e pagam contas, armazenam centenas de músicas em formato mp3 ou wav, permitem que sejamos localizados em qualquer lugar do mundo por meio do Global Positioning System (GPS), navegam na Internet, fazem videoligações (3G) e...além de tudo isto, nos possibilitam fazer e receber ligações, como seus antepassados permitiam! 7. Outro exemplo: a tecnologia de transmissão de dados WiFi28 possibilita estarmos conectados a qualquer lugar do mundo, de qualquer lugar onde estejamos, e o absurdo chega ao ponto de já haver tido prisão de ladrão de WiFi por estar “roubando” sinal emitido por redes da vizinhança.

28. WiFi, Wireless Fidelity, ou comunicação sem os.

54 BPM & BPMS

Também não quero me alongar neste momento analisando as inúmeras propagandas que têm sido veiculadas por empresas de todos os segmentos de TI alertando para a DoI, mormente as que têm soluções de ou para integração de tecnologias. Repare que todas as empresas de TI vão começar a falar da Desorganização Informacional. Até porque se a Big Blue está explicitamente armando que a anarquia informacional é real, as outras não poderiam car para trás.

Efeitos da DoI Que efeitos a Desorganização Informacional ocasiona em nosso cotidiano prossional e particular? É possível reverter este estado de coisas? Como será nossa vida prossional dentro desta situação caótica? Michael Dertouzos, que foi um dos criadores da Internet e Diretor do Laboratório de Ciência da Computação do MIT, escreveu, pouco antes de falecer em 2001, um livro chamado A Revolução Inacabada, no qual faz uma crítica contundente ao atual estado de servilismo e de confusão do Homem frente às tecnologias e apregoa uma nova postura. ...uma direção radicalmente nova para a tecnologia da informação e como será possível usá-la para fazer os sistemas de computação servirem às pessoas...em vez do contrário.

E nos alerta que: À medida que pessoas e organizações, em todos os lugares, lutam para tirar vantagens da Web, da Internet e de miríades de novos dispositivos eletrônicos, elas querem saber o que devem fazer. A mídia, os fornecedores e as autoridades no assunto respondem com milhares de conselhos, tendências, possibilidades e opiniões.

E, deixando transparecer um sentimento de frustração, conclui o parágrafo da seguinte forma: Ainda assim, o resultado opressivo desse frenesi é um sentimento de profunda confusão não só para os usuários comuns, mas também para os especialistas.


Os estragos que a DoI nos causa são de dois tipos: o prossional e o particular. Enganam-se os que pensam que a Desorganização Informacional só nos afeta prossionalmente. Na vida pessoal, aqui estão alguns exemplos: 

Fotograa digital. Antes do advento das câmeras digitais nós

tirávamos fotograas que eram “feitas” e processadas por meio de processos químicos. Todas as fotos tiradas e reveladas eram guardadas álbunsdedeonde fotograas que sempre estiveram nase estantes e em armários elas podiam ser “recuperadas” acessadas quando quiséssemos. Com o advento da fotograa digital a prática de “escrever com luz” popularizou-se, tornou-se muito mais barata e permitiu que milhões de fotos fossem tiradas a todo o momento, mas criou a necessidade de procedimentos antes inimagináveis para que possamos ver as fotograas que tiramos e guardamos. Se quisermos nos assegurar de que teremos as fotos “para sempre” será necessário criar dispositivos de guarda que as dupliquem e até mesmo as tripliquem, a m de garantirmos sua acessibilidade no presente e no futuro. Assim sendo, se guardarmos nossas fotos apenas em um dispositivo corremos o risco de perdê-las para sempre. No mínimo teremos





que fazer cópias em um CD, ou melhor, pela capacidade, em um DVD. Logo teremos dezenas e dezenas de CDs ou DVDs sem qualquer controle sobre seus conteúdos. E quando precisarmos acessar, ou rever uma foto, teremos que perder um tempo precioso para descobrir onde ela está guardada. Mesmo os mais organizados precisarão criar um sistema de indexação que permita a guarda e o acesso às fotos, coisa que ainda está longe do alcance do usuário dito normal, desorganizado ou não especializado. Música (gravada em formato) digital. Todas as observações e preocupações listadas com a fotograa digital se aplicam a este tipo de informação. Documentos digitais. Textos diversos, e-mails, apresentações, planilhas eletrônicas etc. também correm os mesmos perigos listados com as fotos e as músicas digitais.

Para corroborar com tudo que escrevi neste livro, recentemente aconteceume algo sintomático do mal que chamo de Desorganização Informacional. Para começar roubaram o meu notebook e como estou vacinado perdi pouquíssima informação. Tudo de mais importante que havia dentro dele estava

56 BPM & BPMS

guardado em cópias de segurança. Muito bem, decidi comprar outro computador. Só que desta vez decidi voltar a comprar um desktop (me cansei de notebooks). Escolhi uma máquina top de linha, daquelas que a gente compra para usar por uns bons quatro ou cinco anos. Como costumamos chamar tais equipamentos: maquinão! Reproduzo aqui as especicações da máquina para você comprovar o que digo. Descrição Computador com processador Intel® Core 2 Duo (alta performance), 1GB de memória RAM e gravador de DVD. Conta ainda com o Windows Vista Home Premium™! Principais características: – Processador: Intel® Core 2 Duo E4300 1,8 – Cache: 1024KB – Velocidade de barramento: 800MHz – Memória RAM: 1GB DDR 400MHz (expansível até 2GB) – HD de 250GB SATA II – Drive óptico: DVD-RW (leitor e gravador de CD e DVD) – Leitor de cartões de memória (vários tipos) – Placa de vídeo: on board – Placa de som: on board – Placa de rede: 10/100/1000Mbps – Placa mãe: Gigabyte - Chipset Intel 865 – Gabinete: Super Slim (prata) – Sistema Operacional: Windows® Vista® Home Premium Original – Monitor 15” SAMSUNG LCD 540N Prata c/Preto Conexões: – Entradas USB (2 frontais e 4 traseiras) Acessórios inclusos: – Manual – Teclado PS2 Preto – Mouse óptico – Caixas de Som USB Preto

Maravilha, não é mesmo? Pois bem, com uma semana de uso eu precisei salvar um arquivo pequeno, em Power Point, para dar uma aula num curso de pós-graduação e por isso peguei um disquete de três polegadas e meia e...


Pois é, procurei por alguns minutos onde estava o leitor de disquete naquele maquinão e... nada! Você precisava ver a minha cara de decepção. Eu pensava: e agora, o que é que eu vou fazer com os quase mil disquetes que tenho guardados? Simplesmente não havia leitor de disquete na máquina. Esta situação poderia até mesmo ser engraçada, não fossem as consequências: 1. Tive que usar um CD com capacidade de 700 MB para gravar um arquivo de 1.2 MB. Tudo bem que um CD hoje custe R$ 0,80 e um DVD R$ 1,00, mas já pensaram na proliferação de CDs e DVDs que nós vamos ter, em pouquíssimo tempo, praticamente vazios? 2. Tive que comprar um dispositivo removível, um gabinete externo, com um leitor de disquetes para poder ler todos os meus mil disquetes. 3. Perdi um tempo muito grande para descobrir quais disquetes deveriam ser copiados num DVD e quais deveriam ser descartados. 4. Tive que investir quase R$ 300,00 num dispositivo para depois, literalmente, jogá-lo no lixo. A rigor eu não precisaria ter investido nada neste dispositivo, bastava que eu jogasse fora todos os mil disquetes sem nem sequer saber o que cada um deles continha. Agora eu pergunto: dá para fazer algo assim tão radical? Pois bem, podemos imputar às tecnologias a culpa pela Desorganização Informacional? A resposta, como sempre, depende do ponto de vista de cada pesquisador. Todos que me conhecem pessoalmente ou por meio dos meus livros sabem que sou muito crítico quanto ao papel que as Tecnologias da Informação desempenham nas nossas vidas, até porque meus mais de trinta anos de convivência com elas me permitem sê-lo. Contudo, e por isso mesmo, as eximo de culpas que elas não poderiam jamais assumir. Para mim, e para muitos que as estudam com seriedade, elas não são nem as culpadas nem as responsáveis pelos fracassos e pelos sucessos dos nossos empreendi-

58 BPM & BPMS

mentos. Nós mesmos os somos. Em outras palavras, as tecnologias não são nem boas nem más, apenas contribuem para o resultado do uso que viermos a fazer delas. Entretanto, devo lembrar aqui que outros estudiosos não concordam que as tecnologias sejam essencialmente neutras. Para Pierre Lévy, por exemplo, não existe a “técnica neutra”. Ele, como outros que adotam esta linha de raciocínio, consideram as tecnologias parte indissolúvel do contexto social, sendo ao mesmo tempo causa e efeito da evolução deste mesmo contexto, porque inuenciam e são inuenciadas por ele. Objetam, também, que aqueles que, como eu, consideram toda tecnologia como neutra estão na verdade discutindo e analisando uma “pretensa” oposição (belicosa) entre homem e máquina; quando, na verdade, estamos apenas estudando como as tecnologias assumem o caráter que viermos a lhes impingir por meio da utilização que zermos delas. Talvez, quando as tecnologias puderem gerar, de forma plena e potenciária outras tecnologias, elas possam ser essencialmente boas ou más. Enquanto isto não ocorre, penso ser esta uma discussão para outro livro, mais losóco. O que me interessa expor tecnologias (tudo hoje tem um chip embutido, portanto para mimaqui tudoé écomo Tecnologia da Informação) podem servir tanto para ajudar quanto para atrapalhar. Podem ser copartícipes do nosso sucesso ou do nosso fracasso. Existe uma verdadeira mania, alimentada pela indústria de TI, de atribuir às Tecnologias da Informação poderes mágicos e/ou milagrosos. É uma característica desenvolvida a partir da década de 90, quando os mainframes perderam o poder absoluto que tinham até então para a computação distribuída e para os microcomputadores e, em decorrência disso, os fabricantes de tecnologias tiveram que investir mais e mais, todo santo dia, em propaganda cujo objetivo, um entre tantos, era o de criar necessidades para que eles pudessem vender facilidades que gerariam diculdades a serem “pretensamente” resolvidas por outras tecnologias, num círculo vicioso difícil de quebrar. Hoje muitos gurus (mormente os estrangeiros) aderem a esta perspectiva insustentável em termos losócos, mas que encontra calorosa acolhida na maioria das organizações, através dos seus gestores, que gostam de acreditar ser esta perspectiva verdadeira.


Peter Drucker (1995), falecido em 11 de novembro de 2005, resumiu no parágrafo transcrito a seguir a inversão de valores que praticamos quando atribuímos às Tecnologias da Informação capacidades que elas (ainda) não têm: Desde que surgiram as novas ferramentas de processamento de dados, há trinta ou quarenta anos, os homens de negócio têm exagerado e também subestimado a importância das informações na organização. Nós – eu inclusive – exageramos as possibilidades a ponto de falar em “modelos de negócio”, gerados em computador, que poderiam tomar decisões e até mesmo dirigir grande parte da empresa. Mas também subestimamos grosseiramente as novas ferramentas, vimos nelas os meios para fazer melhor aquilo que os executivos já estavam fazendo para administrar suas organizações.

A DoI deverá fazer estragos muito maiores do que os que já causou até agora. Eu penso que não é preciso ser adivinho para fazer uma armação como esta, basta que estejamos atentos às (r)evoluções de TI para sentirmos que nossas preocupações têm fundamentos. Como bem nos alertou Drucker, em 1995, “exageramos as possibilidades ao ponto de falar em “modelos de negócio”, gerados em computador, que poderiam tomar decisões e até mesmo dirigir grande parte da empresa”. A capacidade do ser humano não deve ser relegada nem subestimada em função de todas as tecnologias que já estão ao nosso alcance e das que ainda vão aparecer. O ser humano é ainda, a despeito de tudo que a ciência já avançou em conhecimento sobre nós, uma tecnologia desconhecida!

60 BPM & BPMS

Evolução da Desorganização Informacional Recentemente dois eventos ocorridos nos Estados Unidos me chamaram a atenção para o recrudescimento da Desorganização Informacional. A seguir, antes de discutir ambas as ocorrências, reproduzo as notícias da forma como foram veiculadas em diversos órgãos de imprensa, tanto eletrônicos como tradicionais. 1a notícia: Computador de mão deixa 5 milhões na mão. Pane que durou várias horas em serviço dos aparelhos Blackberry mudou a rotina de executivos nos Estados Unidos, o que revela grande dependência de usuários em relação ao aparelho .

2a notícia: FBI oferece recompensa de cem mil dólares por informações que levem ao paradeiro dos autores do roubo de notebook.

Na primeira notícia temos um caso clássico de mau funcionamento de uma nova Tecnologia da Informação. Antes nós tínhamos agendas de papel para guardarmos nossos compromissos, telefones, contatos e uma série de outras informações importantes para nossa vida prossional e pessoal. Nossos e-mails cavam guardados ou no servidor de e-mails da empresa ou no servidor de e-mails dos serviços como Google, MSN Live e o Yahoo, entre outros. Entretanto, em nome da mobilidade, e esta é a palavra-chave deste início de século, foi criada a tecnologia Blackberry, entre inúmeras outras iguais ou similares, que tiveram vendas explosivas justamente por prometerem a tão sonhada mobilidade. Em função deste maravilhoso modo de ser, o “ser móvel”, mas conectado ao seu meio, que agora é todo o planeta Terra, tanto nossa vida pessoal como nossa vida prossional vão sofrer impactos inimagináveis até então. Para começar teremos que responder a uma série de perguntas, ainda que na maioria das vezes de forma intuitiva, sobre como seremos e queremos ser daqui por diante. Por exemplo:

A Desorganização Informacional 61 

Até que ponto é bom ser achado a qualquer hora e em qualquer lugar, mesmo não sendo um prossional da área de saúde ou envolvido em atividades críticas?



Como iremos tratar a questão da privacidade?



Será que todas as profecias feitas por George Orwell estão se concretizando?



Os dados pessoais serão únicos para todos os usos que viermos a ter, ou que outros vierem a fazer deles?



De que forma e com quais meios faremos cópias dos dados e informações “móveis” sem afetarmos a própria mobilidade que os novos dispositivos propiciam?



Estaremos preparados para sermos monitorados 24h por dia, 7 dias por semana?



No futuro teremos controle sobre onde, quando e como desejamos ser encontrados?

Outro aspecto importante derivado da Desorganização Informacional é o do erro verdadeiro ou induzido, sob quaisquer circunstâncias ou eventualidades. Explico. Como saberemos ser verdadeiro ou falso um determinado dado, uma certa informação? O termo em inglês que dene tudo que é enganação, mentira, é hoax29 e é justamente o que mais existe hoje na Internet. As falsas informações, as falsas notícias, têm pegado a todos nós, fazendo com que acreditemos em histórias que são pura cção, pura invencionice, muitas tão absurdas que são inverossímeis. Quem não se lembra do turista no topo de uma das torres gêmeas com um dos aviões que a derrubaram no exato momento do impacto? Falso. Quando a brincadeira restringe-se aspectos que não vezes causam econômicos, nanceiros ou sociais,aainda que algumas deprejuízos extremo mau gosto, ela apenas nos faz de bobos.

29. n 1 peça, brincadeira. 2 embuste, engano, logro. // vt 1 pregar uma peça. 2 enganar, fraudar. Segundo o Dicionário Multimídia Michaelis

62 BPM & BPMS

Entretanto, quando estas brincadeiras avançam no terreno perigosíssimo do roubo, das fraudes e dos golpes eletrônicos, perpetrados pelos crackers, a situação pode ser grave e gerar efeitos malécos irreversíveis. O que deve nos deixar extremamente preocupados é o fato de dezenas de novos aparelhos eletrônicos surgirem todos os dias sem as proteções necessárias para o uso seguro e livre de interferências e das invasões indesejáveis. Sem sombra de dúvida a Desorganização Informacional tende ao descontrole nos próximos anos quer estejamos falando de ambiente prossional, quer de ambiente pessoal. Nada do que está sendo feito me faz acreditar que a DoI possa regredir ou ser controlada de forma segura e efetiva. Em se tratando de ambiente pessoal, particular, não há mesmo muito que se possa fazer. Anal, cada um organiza ou desorganiza a própria vida como bem lhe aprouver. No ambiente prossional, o das organizações, sempre surgem produtos oriundos de tentativas de ordenamento do caos. Os apresentados neste livro foram srcinalmente desenvolvidos para ajudar as pessoas a controlar a Desorganização Informacional, mas a forma e a maneira como são, na maioria das vezes, implantados não somente não contribuem para a melhoria da desorganização como também na maioria das vezes potencializam as causas de tais enfermidades.

3 O Contexto Histórico CSCW

Preocupados com o contexto que descrevi anteriormente, o da Desorganização Informacional, ainda que não tenham empregado o termo, alguns estudiosos passaram a discutir formas de ordenar o caos que começava a se formar nas organizações já no início da década de 80. Muitas teorias foram discutidas. Várias evoluíram e outras tantas foram abandonadas. Entretanto, algumas ganharam força e sobreviveram até os dias atuais. Uma das sobreviventes mais importantes é a que trata do trabalho cooperativo suportado por tecnologias da informação. Segundo Jonathan Grudin, University of California at Irvine: CSCW e Groupware emergiram nos anos 80 oriundos de interesses compartilhados entre desenvolvedores de produtos de TI e pesquisadores em diversos campos

Em 1984 Iran Greif, do Massachusetts Institute of Technology (MIT), e Paul Cashman, da Digital Equipment Corporation (DEC), organizaram um seminário do qual participaram vários estudiosos de diferentes áreas do conhecimento interessados no tema “como as pessoas trabalham ( how people work)”. O objetivo principal do seminário era o de estudar o papel das tecnologias como suporte ao ambiente de trabalho. Deste interesse surgiu o conceito CSCW. O grupo criou o termo Computer-Supported Cooperative Work, que rapidamente despertou interesse na Europa e na Ásia (no Brasil

64 BPM & BPMS

tais discussões chegaram com atraso de pelo menos dez anos devido à lei de informática). Em decorrência do desenvolvimento do conceito CSCW por vários pesquisadores, foram criadas diversas ferramentas e componentes de software cuja nalidade era dar suporte tecnológico ao trabalho cooperativo (Computer-Supported Cooperative Work). Assim surgiram as tecnologias que fazem parte do grande guarda-chuva chamado groupware.

CSCW ou BPM? São tantos os conceitos, ideias, siglas e abreviaturas existentes na nossa área de atuação (Information Technology) que muitas pessoas podem achar que várias são iguais e/ou incluem-se umas nas outras e/ou excluem-se mutuamente. Glossários dos termos de TI são sempre calhamaços que não param de crescer, o que diculta sua absorção e compreensão por parte de quem não esteja familiarizado com os ciclos evolutivos de TI. Por outro lado, muitos prossionais e empresas sem escrúpulos aproveitam-se deste imenso conjunto de conceitos, ideias, siglas e abreviaturas para continuar a sobreviver num mundo onde as organizações se mostram ávidas por adotar novas tecnologias que possam diferenciá-las de outras organizações do mesmo ramo de atuação – por mais que prossionais sérios digam que Tecnologias da Informação já não garantem nem a diferenciação e nem (quando a diferenciação existe) a durabilidade. Por conta deste conjunto de interesses, convergentes às vezes, divergentes outras tantas, alguns especialistas mundiais continuam armando que Tecnologias da Informação impulsionam organizações na direção de constantes movimentos inovadores, com o que tenho certas ressalvas. Em outras palavras, seria o mesmo que perguntar: Steve Jobs é criativo por causa das tecnologias da informação ou as tecnologias da informação são criativas por causa de Steve Jobs? Eu co com a segunda opção!

O Contexto Histórico CSCW 65

Trabalho Cooperativo por Meio dos Processos de Negócio? A forma como trabalhávamos nas áreas administrativas e na indústria de serviços até quase o nal do século XX impedia-nos de ver a organização como um todo, isto é, enxergávamos apenas nossa própria atividade e, salvo raras exceções, outras poucas que estivessem ao alcance das nossas mãos e dos nossos olhos, ainda que muitas atividades não se relacionassem com a nossa. Salvo as indústrias de manufaturas, discreta e contínua, que desde cedo aprenderam o que são processos, todos os outros setores econômicos só vieram a descobri-los no nal da década de 90. Aliás, embora hoje muito se escreva, fale e discuta sobre processos de negócio ( business processes), raras são as organizações que efetivamente os gerenciam e são gerenciadas por meio deles. No início do século XXI há muito ainda por fazer, pois o tema processo de negócio, mesmo sofrendo de uma “overdose” de exposição, ainda é mal entendido por grande parte das organizações. Não raro, no decorrer de análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio, ouço de diretores e até mesmo de gerentes a seguinte armação: – Eu não sabia que era assim que nós funcionávamos! Embora possa haver nas organizações trabalho cooperativo suportado por computador sem processos de negócio formalmente conhecidos, não raro este trabalho teria baixa produtividade e sofrível qualidade. Logo, os dois conceitos, trabalho cooperativo suportado por computador e trabalho por meio de processos de negócio, são naturalmente simbiônticos; mutuamente complementam-se para possibilitar um ambiente organizacional mais humano, mais produtivo e consequentemente mais feliz. A ideia principal, por trás do conceito CSCW, é a de que as pessoas passem do trabalho individualizado, onde todos trabalham sem conhecerem os processos nos quais suas atividades estão inseridas, para o trabalho em grupo, um trabalho efetivamente cooperativo, por meio do qual as pessoas possam desempenhar suas responsabilidades sabendo “por que” fazem o que fazem, “para quê” serve o produto que fazem e “para quem” irá o produto das

66 BPM & BPMS

suas atividades. É bem diferente de como as coisas se desenrolam hoje na maioria das organizações, onde todos fazem o melhor que podem, na maioria das vezes com muito estresse e aborrecimento, simplesmente porque, não havendo padrões de operação, não há como garantir a qualidade do processo e nem a qualidade do produto. As pessoas raramente sabem “por que” fazem, raramente sabem “para quê” serve o produto quefazem. fazem e, raríssimo, sabem “para quem” irá o produto que suas atividades Por trás desta quase completa desinformação está, em primeiro lugar, a falta de conhecimento sobre o produto do processo. Em outras palavras, quase todos ignoram qual seja o produto que o processo no qual suas atividades estão inseridas produz. Principalmente quando estão inseridas em processos primários industriais de serviços e em processos secundários administrativos. Estas constatações também serviram para embasar o Business Process Management e vários desdobramentos oriundos deste modo de administração de processos, todos perseguindo a ideia do trabalho cooperativo por meio dos processos de negócio, suportados corretamente por Tecnologias da Informação.

O Que É BPM30? Business Process Management, BPM, não é “uma coisa” só, mas um conjunto de múltiplos elementos, conceitos e metodologias que existem há algum tempo com a nalidade de tratar de forma holística processos de negócio. Aliás, nunca é demais ressaltar que processo de negócio é um termo traduzido diretamente do Inglês Business Process. Entre nós este termo evita que façamos confusão com processos judiciais.

BPM tem duas linhas de pesquisa e concepção distintas, mas complementares entre si: a ORGANIZACIONAL e a FERRAMENTAL. Eu deno BPM como:

30. Business Process Modeling, Business Performance Management e Business Process Management são três signicados para uma mesma sigla: BPM.


Business Process Management é conjunto formado por metodologias e tecnologias cujo objetivo é possibilitar que processos de negócio integrem, lógica e cronologicamente, clientes, fornecedores, parceiros, inuenciadores, funcionários e todo e qualquer elemento que com eles possam, queiram ou tenham que interagir, dando à organização visão completa e essencialmente integrada do ambiente interno e externo das suas operações e das atuações de cada participante em todos os processos de negócio.

Outras denições de Business Process Management: Gartner Group: BPM dene, torna possível e gerencia a troca de informa ções nas organizações através da visão semântica de um processo de negócio, envolvendo empregados, clientes, parceiros, aplicações e bancos de dados.

Computerworld: BPM permite que clientes mapeiem gracamente processos

de negócio, como o de emissão e retirada de faturas, transformem este mapa visual numa aplicação ou conjunto de aplica-

ções e gerenciem as mudanças no uxo de trabalho (Workow)

até que suas solicitações estejam concluídas.

The American Productivity & Quality Center (APQC): Business Process Management é a abordagem gerencial que governa o uxo de trabalho (Workow) numa organização.

CRMguru.com: BPM é o gerenciamento de itens de trabalho num processo multietapas. Os itens são identicados e acompanhados à me -

dida que eles passam de atividade em atividade e são processados quer por pessoas, quer por Tecnologias da Informação.

Business Process Trends: BPM é o alinhamento de processos com os objetivos estratégicos da organização. Projeto e implantação de arquiteturas

68 BPM & BPMS

de processos, estabelecimento de sistemas de mensuração que estejam alinhados com os objetivos da organização e a educação dos gerentes para que eles efetivamente gerenciem os processos

Temos nestas denições atribuições deBPM bastante abrangentes; entretanto, qualquer que seja a denição que escolhermos para entendermos BPM caque evidente todassido elasatribuídos que a sigla lhesaatribui responsabilidades e poderes jamaisem tinham antes qualquer outra ideia, conceito ou metodologia, o que faz com que a vertente tecnológica do BPM, o Business Process Management System, seja apresentado às organizações como totalmente abrangente, quase mágico ou milagroso, aliás, como é praxe do marketing da indústria de TI para vender novas tecnologias. Business Process Management, literalmente Gerenciamento do Processo de Negócio, é um conceito já sobejamente difundido e do qual fazem parte dois grandes subconjuntos de conhecimentos: o organizacional e o ferramental. Entretanto, a necessidade contínua de aprimoramento das organizações, na busca por serem mais produtivas e lucrativas, faz com que o conceito seja revigorado continuamente por estudiosos e pesquisadores

que lhes proporcionam atualizações constantes, o que pode vir a confundir aqueles que desconhecem a história do Business Process Management, fazendo-os acreditar que seja algo totalmente novo, quando não é. Dois grandes subconjuntos de conhecimentos sustentam o conceito BPM: o organizacional e o ferramental, como caracterizado na gura 3.1. O grupo dos conhecimentos intitulado por mim de organizacional engloba teorias, normas, políticas e metodologias pertinentes a análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio. O outro grupo é o do ferramental necessário para operacionalizar o primeiro grupo, o do conceito BPM e todos os seus elementos. Neste segundo grupo, o das Tecnologias da Informação, encontra-se osoftware BPMS. Mas, como Busiveremos mais adiante, os softwares que estão sendo vendidos como ness Process Management Systemsnão se parecem uns com os outros a não ser por certas características obrigatórias como, por exemplo, os motores de Workow que cada um possui. Istoocorre porque, diferentemente doWorkow, software que deu srcem ao BPMS, este não tem parâmetros estabelecidos e aceitos universalmente, que possam ser usados para comparações.


Figura 3.1. Dois grupos de conhecimentos sustentam o conceito BPM.

Isto signica dizer que todo e qualquer software, oriundo ou não de uma matriz ou do modelo conceitual Workow, pode se autointitular um software BPMS, o que vai tornar a vida dos usuários que necessitarem escolher entre vários produtos algo desgastante. Software, de maneira geral, se transformou numa commodity, principalmente os “de prateleira”, aqueles comprados prontos e que os americanos chamam de “out-of-box”. O fato dos softwares terem se transformado em commodities (salvo algumas exceções) de certa forma nos fez voltar ao passado, quando os fabricantes de computadores “davam de graça” o sistema operacional e os aplicativos que seriam utilizados para quem comprava ou alugava o mainframe. O hardware era tão caro que o preço do software invariavelmente vinha embutido. Por isso eram “dados de graça”. O da microeletrônica, a invasão microcomputadores e adesenvolvimento introdução de servidores mais potentes e mais dos econômicos baratearam demasiadamente o hardware, o que levou os softwares a serem vendidos. Hoje há um novo paradigma. Nem o hardware, nem o software conseguiriam sozinhos hoje manter saudáveis empresas de TI. Então a solução foi ganhar dinheiro (muito dinheiro) com a venda de serviços, embora nem o hardware nem o software tenham voltado a ser “dados de graça” como no

70 BPM & BPMS

passado, pois as empresas esperam ganhar dinheiro com os serviços que serão executados para que eles sejam implantados (hardware e software) e utilizados. A ideia de ganhar dinheiro com serviços é tão forte hoje que já há empresas de software oferecendo de graça, sem cobrar nada mesmo, o software produzido por elas somente para fazer o usuário adotá-lo e com isso ter que obrigatoriamente vir a comprar os serviços de implantação e assistência. Esta situação tem um lado extremamente perverso. Se quem está comprando um software não souber com certeza e segurança o que dele quer obter e o que é necessário fazer para vir a usá-lo, vai, fatalmente, estar “amarrado” à “idoneidade” do fabricante e/ou vendedor do produto. Em se tratando de determinados softwares, como Workow,BPMS, Efcient Consumer Response, Supply-Chain Management e Data Warehouse entre outros, a situação é extremamente perigosa pela necessidade da análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio que tais softwares têm. Por isso BPMS pode vir a ser uma grande dor de cabeça para aquelas empresas pretendem comprá-lo sem com o conhecimento fazê-lo comque segurança. Como aconteceu Workow. necessário para

O Modelo Ainda Inexistente Business Process Management Systems vem ganhando popularidade junto a fornecedores de softwares interessados em vender seus produtos, principalmente os que foram desenvolvidos com o nome de Workow e que não tiveram vendas no volume esperado para o retorno dos investimentos feitos no seu desenvolvimento, e a muitos usuários interessados em novidades, mesmo sabendo que as últimas adquiridas ainda nem sequer foram exaustivamente implantadas e utilizadas. Business Process Management Systems faz parte do conceito que cou conhecido pela sigla BPM31, que engloba teorias, metodologias e tecnologias

31. BPM é também a sigla para Business Performance Management, que trata do suporte proporcionado por Tecnologias da Informação às operações, especialmente as que são dotadas de grande mobilidade e em ambientes distribuídos.


da informação, dentro do mesmo pacote; e tanto BPM como BPMS vêm ganhando cada vez mais espaço nos meios especializados. Por isso, mais cedo ou mais tarde, todas as organizações terão que entender do que se trata até para não correrem o risco de investir em algo desconhecido. Os fabricantes de softwares de Workow foram os primeiros a se apoderarem das ideias e conceitos do BPM, até como forma de revitalizarem seus produtos, vez quenunca quem se é da área sabe queDaí asporque estimativas deste tipo uma de software concretizaram. para de taisvendas “fabricantes” esta nova abordagem foi muito bem-vinda, pois pode ajudá-los a recuperarem os investimentos feitos em pesquisa e desenvolvimento dos seus softwares de Workow. Nestes quase vinte anos de estudos sobre Groupware já vi muitas empresas falirem vendendo softwares para processos, como Workow, e outras tantas serem vendidas e incorporadas por empresas maiores, por não aguentarem o peso dos investimentos feitos sem retorno. Também não devemos nos esquecer de que o grande impulsionador do desenvolvimento e da aceitação do software de Workow foi o seu modelo conceitual, eaceito por toda a comunidade de estudiosos, pesquisadores, fabricantes usuários. Este modelo está fazendo quinze anos que foi criado, mas continua evoluindo. Além do modelo conceitual ou de referência do Workow, o WfMC (Workow Management Coalition), organismo que congrega todos os interessados no software Workow, cuida também de estabelecer e manter padrões para vários componentes de software ligados ao Workow. O modelo conceitual (ou referencial) Workow, reproduzido na gura 3.2, permite que: 1. Todos que queiram desenvolver softwares desta classe o façam com aderência a princípios estabelecidos universalmente. 2. Todos que queiram comprar um software desta classe o façam com base num modelo aceito universalmente, o que facilitará o processo de compra por meio da comparação entre várias “marcas.”

72 BPM & BPMS

Figura 3.2 - Modelo conceitual (ou referencial) do software Workow

Um modelo de referência tem por objetivo permitir que o princípio estabelecido para determinado objeto seja entendido da mesma forma por todos aqueles que algum interesse tenham pelo objeto. Infelizmente ainda não há um modelo referência para BPMS, a despeito de diversas tentativas, surgidas muito mais com propósitos comerciais do que com o objetivo de criar o “princípio da coisa”. Todos os fabricantes de softwares têm seu próprio modelo conceitual de Business Process Management System, como veremos adiante pelas guras colocadas aqui, o quecom torna trabalho de comparação extremamente perigoso e de resultados altaocarga de incerteza. A despeito da seriedade do WfMC, muitos de seus membros embarcaram na onda do Business Process Management System, preocupados talvez em demonstrar à comunidade da qual todos nós fazemos parte que a instituição está antenada (plugada, para usar um termo tão do nosso meio) com o mercado e que o WfMC evolui constantemente.


Em 2006, quando estive participando da conferência anual do WfMC na Filadéla, na qual foi lançado o Workow handbook de 2006 (do qual participo com um artigo), tive a oportunidade de conversar reservadamente com alguns membros dos comitês permanentes do WfMC. Vários deles concordaram com as minhas colocações, mas, evidentemente, não irão assumir tais posições publicamente uma vez que (sempre o pragmatismo americano) existem outros interesses a serem preservados. Todos os pesquisadores com quem tive contato naquela conferência entenderam minhas colocações: qualquer coisa não pode passar a ser nova apenas porque lhes foram agregadas funcionalidades que antes só existiam se fossem integradas intencionalmente, como acontecido com Workow e EAI, entre tantos outros exemplos. Não é que eu esteja contra o BPMS, pelo contrário, acho-o imprescindível (até porque o acredito como sendo uma evolução do Workow), mas não gosto de ser iludido!

Modelo Genérico do BPMS O Business Process Trends, um dos vários organismos que gerenciam as iniciativas sobre BPM e BPMS hoje no mundo, embora não chegue a ser uma coalizão como o WfMC, criou um modelo genérico de BPMS, reproduzido na gura 3.3.

74 BPM & BPMS

Figura 3.3 – Modelo genérico do software BPMS. Fonte (adaptado de): BPTrends (www.bptrends.com), acessada em 10/10/2006.

É interessante reproduzir aqui a observação do BPTrends explicando, de certa forma, o modelo Business Process Management System. O que devemos ter em mente quando olhamos a gura 3.3

é que uma organização deve implantar um produto ou suíte BPMS por meio do desenvolvimento das suas próprias ferramentas, utilitários e motores; ou fazê-lo agregando produtos que foram desenvolvidos por outros fabricantes, incorporandoos à sua suíte ou aplicações BPMS.

Interessantíssima a observação transcrita. Primeiro porque coloca a questão do tamanho e da complexidade deum software BPMS ao armar que devemos pensar em montar uma solução a partir de módulos de vários fabricantes, algo best of breed, melhor da que no passado cou conhecido no nosso meio como raça, numa analogia que exprime a opção pela escolha da melhor parte dos diversos softwares conhecidos da classe de software que estamos implantan do para carmos como que há de melhor entre os melhores. Segundo porque reconhece, explicitamente, que comosuíte composta desta forma o BPMS não é ainda umsoftware, mas vários e diferentes, inclusive Workow rebatizado.


Eu decidi reproduzir aqui, começando pelo modelo do BPTrends, alguns modelos grácos de softwares que estudei de uma lista contendo mais de 30 fabricantes de BPMS com o intuito de mostrar que não será tarefa fácil, para quem quiser comprar um Business Process Management System, compará-lo a outros produtos da mesma classe de software. Business Process Trends Web: www.bptrends.com

Figura 3.4 – Modelo de uma possível arquitetura de BPMS. Fonte: BPTrends (www.bptrends.com) acessado em 10/10/2006.

76 BPM & BPMS

TIBCO iProcess SuiteVersion: 10.5 TIBCO Software Inc. 3307 Hillview Avenue, Palo Alto, CA 94304 Tel: (650) 846-5637 Fax: (650) 846-1005 Web: www.tibco.com Email: [email protected]

Figura 3.5 – Representação lógica do TIBCO iProcess Suite.


IBM FileNet Business Process Manager Version: 4.0 IBM Corporation 3565 Harbor Blvd, Costa Mesa, CA 92626-1420 Tel: 714-327-3400 or 1-800 FILENET Web: www.ibm.com

Figura 3.6 - IBM FileNet P8 ECM.

Oracle BPEL Process Manager Version 10.1.2 Oracle Corporation Oracle Parkway, Redwood Shores, CA 94065, USA Tel: 1.800.ORACLE1 or +1.650.506.7000 Web: www.oracle.com

Figura 3.7 – Oracle BPEL Process Manager.

78 BPM & BPMS

Singularity Process Platform Version: 3.4 Singularity 11 Penn Plaza, 5th Floor, New York, NY 10001 Tel: +1 (212) 946 2685 Fax: +1 (212) 946 2808 Web: www.singularity.us.com Email: [email protected]

Figura 3.8 – Os quatro componentes do Singularity Process Platform.


Pegasystems SmartBPM Suite Version: 4.2 Pegasystems, Inc. 101 Main St Cambridge MA, 02142-1590 Tel: 617-374-9600 Fax: 617-374-9620 Web: www.pega.com Email: [email protected]

Figura 3.9 – Arquitetura central do motor do PRPC.

80 BPM & BPMS

Business Convergence Suite Version: 2.2 M1 Global Solutions, Inc. 5775 Glenridge Drive NE, Building E, Suite 400, Atlanta, GA 30326 Tel: 770-250-0349 Web: www.m1global.com Email: [email protected]

Figura 3.10 – Visão lógica do motor do M1 Convergence.

BizFlow Version: 10 HandySoft Global Corporation 1952 Gallows Road, Suite 100, Vienna, VA 22182 Tel: (703) 442-5600 Fax: (703) 442-5650 Web: www.handysoft.com Email: [email protected]

Figura 3.11 – Arquitetura do BizFlow Process Server.


Global 360 Enterprise BPM Suite Version: 9.4 Global 360, Inc. 2911 Turtle Creek Blvd., Dallas, TX 75219 Tel: 214 445-4100 Fax: 214 219-0476 Web: www.global360.com Email: [email protected]

Figura 3.12 – Arquitetura do Global 360 Enterprise BPM.

82 BPM & BPMS

XicoBPM Version 3.0 B2Binternet, Inc. 9, Il-dong B/D, #968, Daechi3-dong, Kangnam-gu, Seoul, Korea (135-736) Tel: +82 2 550 7209 Web: www.xicobpm.com

Figura 3.13 – Modelo conceitual of XicoBPM 3.


Metastorm BPM Version: 7.5 Metastorm, Inc. 500 E. Pratt Street, Suite 1250 Baltimore, MD 21202 Tel: +1 443-874-1300 Web: www.metastorm.com Email: [email protected]

Figura 3.14 – Arquitetura do Metastorm BPM suite.

Algumas Palavras sobre Estes Modelos Haja vista, cada “fabricante” tem seu próprio modelo de BPMS. E cada um, também, batizou não somente o modelo, como os componentes, com nomes que na maioria das vezes não seguem qualquer padrão (re)conhecido pelo mercado, salvo raras exceções. Num passado recente também os fabricantes tinham seus próprios modelos de Workow com nomes próprios dados por eles, mas a diferença é que era possível reconhecer cada componente do produto por meio da sua aderência ao modelo conceitual Workow Management Coalition , WfMC. Em todos os produtos apresentados pelas guras anteriores poucos módulos têm nomes que nos permitem compará-los aos de outros modelos de outros “fabricantes”. Um dos poucos é o motor (engine) do módulo Workow existente em todos os BPMS, sem o qual o mesmo não conseguiria cumprir sua mais importante promessa: automatizar processos por meio da exe-

84 BPM & BPMS

cução de regras de negócio. Embora todo motor Workow deva executar denições oriundas de um módulo Designer, nada nos garante que este princípio WfMC seja seguido em todos os produtos, como aliás aconteceu com muitos softwares de Workow no passado. Em outras palavras, há muitos produtos BPMS que fazem uso de linguagens de programação em larga escala e por isso são demorados e caros de serem programados, implantados e atualizados.

BPMS, Um Novo Nome para Workflow? As promessas feitas em nome desta nova classe de software são cada vez maiores. Entretanto, os que as fazem em nome do BPMS se esquecem que promessas não se realizam apenas por terem sido feitas. Entre a promessa e a realidade existe um conjunto imenso de variáveis que tanto podem inviabilizá-las como torná-las verdade. Entre estas variáveis estão a análise, o desenho, o redesenho, a modelagem, a organização, a implantação, o gerenciamento, a melhoria de processos de negócio e a mudança de cultura da organização, talvez a mais importante de todas as variáveis. Sendo o software BPMS apontado como uma evolução do Workow, pois pelo menos é assim que o denem todos aqueles que têm algum interesse em enquadrar seus produtos dentro desta nova classe de software, as mesmas preocupações que existiam para que a implantação do Workow tivesse sucesso ainda existem, e maiores agora. Porque, em síntese, a diferença ou a evolução, como quer nos fazer ver a indústria de software, reside no fato de o Workow ter como principal responsabilidade automatizar processos enquanto que a do BPMS é automatizar a organização como um todo. Esta conceituação é discutível, uma vez que a nosso ver JÁ ERA possível automatizar totalmente qualquer tipo de organização, integrando clientes, fornecedores, parceiros, inuenciadores, empregados e todo e qualquer elemento por meio dos processos de negócio usando qualquer software de Workow, ainda que o mesmo tivesse sido construído em casa. Além disto, todos os softwares de BPMS que conhecemos são, na verdade, essencial mente softwares de Workow com novas funcionalidadesagregadas, a maioria delas (ouso dizer) não essenciais para os propósitos de automatizar os processos de negócio, uma vez que isto (insisto erepito) o Workow já fazia. Por isso, para os especialistas preocupados com a verdade dosfatos, os softwares de BPMS continuam sendo essencialmente softwares de Workow.


Entretanto, se quisermos aceitar que BPM (não estou falando do software) é antes de tudo um conceito que, a exemplo de outro, o de Groupware, serve como um grande guarda-chuva dentro do qual estão várias tecnologias, a ideia de aceitar o BPMS como uma nova tecnologia ca mais “palatável”. Mas é sintomático o fato de que ninguém mais fala de Groupware. Talvez porque o conceito tenha cado “velho” e todos falem de BPM, porque o conceito é mais novo. A pergunta é: até quando ele o será? Business Process Management está diretamente associado a processos de negócio. A ideia que vem ao longo dos tempos embasando o desenvolvimento de uma série de softwares que atendem pela sigla BPMS (conjunto de metodologias e ferramental) é a de automatizar e controlar processos por meio da execução de regras de negócio, visando retirar do trabalhador a responsabilidade por tarefas repetitivas, desmotivantes e estressantes, transferindo-as para várias Tecnologias da Informação. Business Process Management tem sido difundido como a nova ideia que deu srcem a um novo software, o BPMS, principalmente pelos fabricantes das denominadas tecnologias emergentes, embora, a nosso ver, muitas destas ideias não possam a rigor ser chamadas de novas, mas sim de ideias

que foram reaproveitadas de outras tecnologias, como, por exemplo, as que compõem o conjunto EAI (Enterprise Application Integration) e o conjunto SOA (Service-Oriented Architecture). A razão de armarmos que o software BPMS é o mesmo software Workow com outro nome é que constatamos que já era possível fazer com Workow a integração prometida agora pelos “vendedores” do BPMS, inclusive entre usuários e plataformas diferentes, integrando mainframes com plataforma baixa, rodando diversos tipos de sistemas operacionais. Para o Workow só existe um organismo internacional, chamado WfMC32, que cuida da padronização e do desenvolvimento do modelo conceitual do softwa re. Entretanto, hoje, com a disseminação do BPMS, foram criados vários ou33 tros organismos (todos americanos ) com a nalidade de desenvolver e cuidar 34 de um modelo de BPMS que a rigor ainda não foi aceito universalmente. 32. WfMC, Workow Management Coalition. 33. BPMI, Business Process Management Institute; e-Workow; WARIA, entre muitos outros. 34. O Workow Management Coalition também trabalha na criação de um modelo referencial de BPM, tendo em 2004 publicado um documento intitulado BPM Reference Model.

86 BPM & BPMS

Ainda não existe um modelo conceitual de BPMS aceito por toda a comunidade porque muitas das funcionalidades do software já existiam no modelo Workow e suas diferenças não seriam essenciais e estariam mais na ênfase dada à atuação de cada uma delas do que na forma de representá-las dentro da suíte. Alguns estudiosos, e mais ainda os fabricantes de Workow, insistem em caracterizar BPMS tecnologia com poderes para automatizar a organização ocomo umcomo todo, “A” diferentemente, dizem alguns, do Workow, que se preocuparia somente com a estrutura organizacional, papéis e regras de negócio, fazendo alusão direta aos três elementos que deram srcem ao modelo Workow: Roles, Rules e Routes.

Facilitadores do Modelo BPMS O que vem acontecendo neste segmento de software é sintomático. Devido às vendas insignicantes e consequentemente pouca utilização do Workow por parte das organizações, conclusão corroborada pelos resultados na minha pesquisa, apresentada no livro Uso e Desuso de Sistemas de Workow, foi preciso fazernoo que especialistas marketingTemos chamam de revitalização do produto, casoosaqui, do modelodeWorkow. que reconhecer, entretanto, que alguns fatos inuenciaram de certa forma as transformações (ainda que pequenas do ponto de vista essencial) do Workow em BPMS. Um dos mais importantes inuenciadores do BPMS foi a criação da lei americana conhecida por Sarbanes-Oxley (SOx), aprovada pelo congresso dos Estados Unidos para garantir que os fatos e os problemas ocorridos com e em empresas como a Xerox, a Enron, a WorldCom, a Vivendi e a Royal Ahold, que maquiaram seus balanços causando prejuízos aos investidores, não viessem a se repetir. A SOx, como é popularmente conhecida, foi criada para restabelecer a conança dos investidores na contabilidade, e nos registros gerados por ela, das empresas com as quais eles mantêm relações de investimento. Basicamente a SOx é um conjunto de regras muito rígidas, cuja operacionalização se dá por meio de alguns elementos organizacionais e tecnológicos, entre eles o Record Management (RM), Gerenciamento de Registros, que serve para o gerenciamento dos registros de transações e para a documentação dos processos de negócio de empresas que tenham ações ne-


gociadas em bolsa, como forma de garantir que os investidores não sejam surpreendidos com falcatruas cometidas pelos executivos que “governam” tais empresas. Embora muitas das determinações da SOx digam respeito a empresas de capital aberto, as de capital “fechado” também passam a ser obrigadas a respeitá-las por determinadas circunstâncias. Por exemplo: empresas de capital fechado que negociem com empresas de capital abertoforma se acham igualmente obrigadas àsdos regras de governança corporativa, como de garantir a transparência e nos negócios realizados entre elas. Daí os fabricantes deWorkow, como mostram várias peças de marketing destes fabricantes anunciando as novas funcionalidades dosseus produtos, terem se apressado em vender o BPMS como “A” solução para integrar os processos, as tecnologias e os atores existentes nesse universo, mantendo os registros que servirão para arastreabilidade e consequente auditoria dos negócios realizados por elas, organizações, e entre eles, atores. A rigor, nada que o Workow já não conseguisse fazer.

Para Escrever Este Livro Existem várias “bíblias” sobre softwares de Business Process Management System (BPMS), todas publicadas por institutos que foram criados após o surgimento das ideias que deram srcem ao software. Salvo o WfMC, que continua a ser o “guardião do modelo de referência do Workow”, todos os outros organismos falam de Workow de forma secundária, pois, dizem eles, este software é agora um subconjunto da Suíte BPMS. Além destas “bíblias” existem os sites dos próprios fabricantes de BPMS, que mantêm farto material de marketing e alguns documentos técnicos que serviram aos meus propósitos neste livro, como mostram as guras 3.3 a 3.14.

Softwares A metodologia empregada por mim para analisar os diversos softwares de BPMS: 1. Análise: a.

Do marketing do “fabricante” do software, pois sem divulgação não haveria como descobri-los sendo BPMS.

88 BPM & BPMS b.

A representatividade do software junto ao mercado, através da repetida divulgação da marca por institutos de análise de mercado, formadores de opinião, imprensa especializada e mailing list.

c.

Entrevistas com pessoal de TI de empresas que já usam Workow e/ou BPMS.

2. Análise comparativa das características do software de Workow com as características do software BPM. 3. Análise das características encontradas nos softwares de BPM que foram escolhidos para análise.

Livros Fiz também uma exaustiva pesquisa bibliográca sobre o tema, tanto concernente ao conceito BPM propriamente dito quanto ao software BPMS, e dividi os livros que li em dois grupos: 

Ligados ao conceito BPM.



Ligados ao software BPMS.

Encontrei um número signicativo de livros sobre o conceito Business Process Management, que foram listados na bibliograa. Invariavelmente estes livros se ativeram à análise e à modelagem de processos de negócio de forma genérica, sem trazerem contribuições concretas sobre “como fazer” ou “com o que fazer”, uma metodologia para realizar AMOP. Claro, todos os livros sobre BPM estão em inglês e foram majoritariamente editados nos Estados Unidos, salvo o escrito pelos meus colegas do SAGE-COPPE-UFRJ, Laboratório de Sistemas Avançados de Gestão da Produção. Aproveito para relembrar à leitora e ao leitor que meu livro Sistemas, Métodos e Processos tem a descrição da minha metodologia (DOMP35) para a realização de projetos de análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio.

35. DOMP, Documentação, Organização e Melhoria de Processos.


Lembre-se, você que está lendo este livro, de que análise, mapeamento e modelagem de processos de negócio não se fazem de forma desorganizada, sem metodologia, sem embasamento teórico – o que aliás tem sido causa de fracassos e consequentes prejuízos de vários projetos com esta nalidade. Os livros sobre Business Process Management Systems são raros e o único que encontrei, também em inglês, escrito pelo presidente de umasoftware empresa desenvolvedora de software defoiWorkow, agora autointitulado BPMS, e que justamente por isso se parece muito mais com o Reference Guide Manual do produto do que com um livro sobre BPMS. Resumindo, o tema BPM e seu componente tecnológico BPMS ainda sofrem de certa confusão de conceitos e denições, mas para quem gosta do tema e quer se aprofundar nele há muito a ser explorado, mesmo porque tanto BPM quanto a tecnologia BPMS fazem parte do vastíssimo universo chamado Processo de Negócio.

4 BPMS

36

Antes de apresentar o software conhecido genericamente como Business Process Management System, BPMS, ou Sistema para Gerenciamento de Processos de Negócio, acho conveniente recordar aqui a denição de Business Process Management, BPM: Business Process Management é o conjunto formado por metodologias e tecnologias cujo objetivo é possibilitar que processos de negócio integrem, lógica e cronologicamente, clientes, fornecedores, parceiros, inuenciadores, funcionários e todo e qualquer elemento que com eles possam, queiram ou tenham que interagir, dando à organização visão completa e essencialmente integrada do ambiente interno e externo das suas operações e das atuações de cada participante em todos os processos de negócio.

Agora posso colocar a denição de Business Process Management System com a certeza de que as duas denições serão corretamente entendidas. Denição de BPMS: Conjunto de softwares, aplicações e ferramentas de tecnologia da informação cujo objetivo é o de possibilitar a implantação

36. Business Process Management System.


do modus operandi Business Process Management, integrando em tempo real clientes, fornecedores, parceiros, inuenciadores, empregados e todo e qualquer elemento que com eles possam, queiram ou tenham que interagir por meio da automatização dos processos de negócio. Outras denições de BPMS. Ten3 Business e-Coach: BPMS é uma nova categoria de software de gerenciamento que abre uma nova era para a infraestrutura de negócios suportados por tecnologias da informação. BPMS permite que as organizações modelem, implantem e gerenciem processos de negócio considerados críticos por integrarem múltiplas aplicações, departamentos e parceiros de negócio, atrás do rewall

e sobre a Internet.

Business Process Management Initiative: Business Process Management Systems são softwares que

contêm três partes principais: um motor que executa modelos de processos de negócio, um conjunto de ferramentas que suportam totalmente o ciclo de vida do processo de negócio na sua totalidade e conectores que permitem que o BPMS interaja com outros softwares e programas necessários à execução do processo pelo motor do BPMS. Todas estas denições são unânimes em armar que softwares BPMS são conjuntos de ferramentas que servem para executar (automatizar) processos de negócio. A palavra automatizar está entre parênteses porque entendo que todo software que executa processos de negócio o faz assumindo o controle operacional das regras de negócio denidas, implícita ou explicitamente, nas tarefas existentes nos procedimentos que orientam a execução das atividades que compõem o processo. E isto é para mim automatização de processos. Uma pergunta me tem sido feita com frequência: – BPMS serve para automatizar qualquer tipo de processo?

92 BPM & BPMS

A resposta é: sim. Serve para automatizar tanto processos primários quanto processos secundários. – E serve para automatizar processos de qualquer natureza? Sim e não. Explico.

BPMS e os Processos de Manufatura Os processos industriais de manufatura sempre foram, de uma forma ou de outra, os mais organizados. Embora essa organização fosse muitas vezes empírica, os prossionais envolvidos diretamente com o chão de fábrica cedo descobriram que sem processos (ainda que conhecidos informalmente) dicilmente alguma coisa poderia ser produzida. Mesmo no início da revolução industrial podemos ver a preocupação da área de produção com a forma e com o conteúdo do processo fabril. Outro exemplo é o de Henry Ford e sua linha de produção de automóveis, os famosos Ford T. Sem organização não haveria como tê-los exatamente iguais ao nal da linha de montagem. Aliás, tão iguais que a célebre frase “todo americano pode ter o carro na cor que quiser contanto que seja preto” permanece até hoje como símbolo dessa igualdade. A pergunta então é: – Com tanta organização é possível obter algum benefício com a implantação de BPMS (Workow) em tais processos? E a resposta é: – Sim, para processos de manufatura discreta e – Não, para processos de manufatura contínua. Por quê? Primeiro vou explicar por que o software de BPMS, a exemplo do seu antecessor, o Workow, não agrega nenhum valor para os processos industriais de manufatura contínua ou de transformação ou, pelo menos, para não ser tão radical, não tanto quanto agrega a processos industriais de serviços ou aos processos secundários administrativos.


Processos de Manufatura Contínua Os processos de manufatura contínua, também chamados de transformação, são os únicos que já incorporam uma inteligência de Workow própria ao seu processamento. Por isso a adição de uma ferramenta de Workow externa não acrescentaria nenhum benefício a esses processos industriais e, a rigor, isto nem seria possível, pela característica dos equipamentos que suportam tais processos. Deixe-me dar um exemplo. Todos nós já passamos na estrada ou na cidade por instalações industriais com milhares de tubos e silos de todos os tamanhos; são plantas petroquímicas, instalações de indústrias químicas, fábricas de papel e celulose etc. Quem não está familiarizado com tais processos já se perguntou o que são todos aqueles tubos, dutos, torres, cilindros, silos e tanques. Pois bem, além de fazerem parte dos processos de produção, todos aqueles equipamentos são em síntese um Workow físico gerenciado por um Workow lógico. Em tais plantas tudo tem um estrito motivo de ser. Cada reta, cada curva, cada válvula, cada processador lógico de controle (PLC) neste tipo de indústria cumpre funções especícas (e importantes) para que o conjunto funcione sempre corretamente. O trabalho destes pois, conjuntos muito se cada assemelha à execução de um software de Workow, por exemplo, mistura deve ser feita no tempo certo, sem atrasos e nas quantidades exatas. Cada parte deve ser controlada quanto ao momento e à quantidade com que devem se misturar às outras. As “regras de negócio” são rígidas quanto a tempos, movimentos e quantidades, e quando não são respeitadas por qualquer motivo, acarretam consequências gravíssimas. Neste tipo de indústria softwares de BPMS, softwares de Workow, só poderão beneciar os processos administrativos dessas empresas, que a rigor têm a mesma essência que os processos administrativos de qualquer outro tipo de organização.

Processos de Manufatura Discreta O principal conceito embutido num software de BPMS, por meio do módulo de Workow, é o de automatizar processos e, com isso, assumir a realização de tarefas repetitivas, sem criatividade, que requerem repetição constante e segura e que causam alto nível de estresse nas pessoas. Isto signica que o Business Process Management System, por meio do módulo de Workow,

94 BPM & BPMS

procura dar aos processos, principalmente aos secundários (administrativos), a mesma automaticidade existente nos processos primários de ambos os tipos de manufatura. Anal, é possível dar às ações inerentes aos processos administrativos o mesmo caráter de produção dos processos de manufatura discreta e até mesmo, em certas circunstâncias, o mesmo caráter dos da manufatura contínua. Por conseguinte, nada mais lógico do que esperarse que tais ferramentas possam ser usadas para aumentar a produtividade dos processos primários da manufatura discreta. A rigor, uma ocorrência dentro de um processo de manufatura discreta em nada difere de uma ocorrência dentro de um processo administrativo em ambas as manufaturas. Todas elas devem percorrer rotas, segundo regras preestabelecidas, dentro de um determinado tempo de ciclo para serem feitas dentro de um tempo de processamento preestabelecido e sob condições especícas em função do conjunto de dados que particulariza cada ocorrência, fazendo com que cada uma seja igual ou diferente das demais ocorrências de um mesmo processo. Alguns dos fatores que fazem com que ocorrências se pareçam em ambos os processos (primários e secundários) são: 

A pressão que as modernas organizações enfrentam por melhores tempos de respostas para clientes internos e externos.



Redução do tempo de ciclo de cada atividade e consequentemente de cada processo existente na organização.



Redução dos custos de produção.



Eliminação dos gargalos e das restrições que aumentam os custos de produção.



Aumento de produtividade para que os resultados sejam consistentemente melhores e maiores utilizando-se os mesmos recursos.



A complexidade e, paradoxalmente, a imperiosa necessidade de adaptabilidade dos processos de manufatura, que procuram atender a cada cliente de forma diferenciada e singular. A exemplo do que já acontece com a indústria automobilística e de computadores, para citar apenas duas.



A adoção das políticas de qualidade e em particular das normas ISO, que zeram com que as empresas trabalhassem segundo

BPMS 95

procedimentos e tarefas preestabelecidas, como forma de evitar o desperdício e a perda de tempo. 

A globalização e a internacionalização da economia através da rede mundial de computadores.



O e-business, o B2B, o B2C e todas as suas consequências, tanto boas quanto más.

Por tudo isso, e por inúmeras outras razões, uma ferramenta de BPMS (Workow) pode vir a ser muito útil para processos de manufatura discreta, desde que se saiba usá-la corretamente. Anal, qualquer processo só poderá ser melhorado e ter sua produtividade continuamente aumentada se puder ser gerenciado. Controlar, para BPMS (Workow), signica não só ajudar as pessoas a trabalhar melhor e – por que não? – mais felizes, assumindolhes o trabalho repetitivo e burocrático sempre da mesma forma, como usar os dados provenientes desse controle para medir e melhorar os processos automatizados pela ferramenta. Como já disse uma vez Ishikawa: O que não pode ser medido não pode ser controlado.

Um processo de manufatura discreta só poderá ser melhorado se for gerenciado e controlado. Para gerenciá-lo e controlá-lo é necessário monitorá-lo, medi-lo e avaliar o seu desempenho continuamente. Isso qualquer software de BPMS deve fazer por meio do seu módulo de Workow, desde que, é claro, tenhamos feito o “dever de casa” corretamente, ou seja, desde que tenhamos feito a análise, o desenho, o redesenho e a modelagem (quando cada um destes verbos for aplicável) dos processos de negócio da organização. Processos de manufatura discreta produzem bens em lotes ou individualmente. Lotes compartilham de uma série de especicações comuns que têm por nalidade agregar valor ao que está sendo fabricado. Em termos simples podemos dizer que qualquer processo de fabricação tem início com uma ocorrência chamada de “ordem de fabricação” que, por sua vez, tem sua srcem programação da produção feita com base nos de clientes. Sena a empresa tem um ERP implantado, o BPMS podepedidos ser usado para automatizar qualquer ocorrência, independentemente do processamento que o sistema de gestão empresarial fará de cada pedido de cada cliente colocado no sistema.

96 BPM & BPMS

Integrando BPMS (Workflow) a um ERP Nenhum ERP tem a inteligência que uma ferramenta de BPMS (Workow) possui. São ótimos produtos, mas carecem de tecnologia que lhes permitam automatizar processos, mesmo porque a nalidade deles é outra: a gestão dos recursos empresariais (enterprise resource planning) e não a automatização dos processos de negócio. A junção do BPMS (Workow) com um software de ERP, ou outro software qualquer, pode ser feita de duas maneiras.

Figura 4.1 - Integração entre Workow e Sistemas ERP.

A primeira é feita por meio de agentes que se encarregarão da execução de transferências de dados do BPMS (Workow) para o sistema ERP e do sistema ERP para o BPMS (Workow). Estes agentes podem ser simples e complexos. São simples se forem genéricos, como as stored procedures do SQL, e complexos como os do SAP, por exemplo. Eles podem ser programados para transferência, nos dois sentidos de direção, de strings (con-

BPMS 97

juntos) de dados; e de forma mais elaborada compostos de instructions set (conjunto de instruções) com o objetivo de executar o tratamento dos dados “carregados” nos dois sentidos das tecnologias envolvidas. Para mim, a exemplo de outras tecnologias já conhecidas, o famoso ERP37 como ideia tecnológica já faz parte do passado, embora não queira dizer com isso que seja menos importante. Entretanto, qualquer ERP pode se beneciar de uma ferramenta BPMS (Workow) para aumentar e melhorar suas funcionalidades. O ERP é descendente direto dos MRP38 e MRP II, que já foram populares e úteis, principalmente no ambiente de manufatura, e como tal se beneciou do conhecimento e da experiência acumuladas pelos diversos sistemas (des)integrados que vieram antes dele, ERP, e dos sistemasMaterial Requirements Planning I e II durante quase três décadas de utilização por parte das organizações. Pois bem, mesmo assim qualquer ERP por melhor que seja não tem a inteligência que um BPMS (Workow) possui (the engine) e por isso não tem como automatizar os processos que estiver suportando. Mas quando aliamos as funcionalidades das duas tecnologias podemos aumentar os benefícios auferidos pela organização. O conceito é tão verdadeiro que quando os fabricantes de sistemas de gestão de recursos empresariais (ERP) perceberam que esse potencial existia, passaram a “incorporar” aos seus produtos funcionalidades de “Workow”, o que, na maioria das vezes, mostrou-se ser outra armadilha perigosa e cara para as organizações que acreditaram em tais promessas.

Workflow Embutido ou Autônomo? Para que qualquer software seja considerado Workow há que existir um componente fundamental, chamado de motor (engine), que se encarregará de automatizar e administrar todos os processos que forem publicados ou instalados sob sua responsabilidade. Esse princípio exclui da categoria todos os “Workows” de todos os ERP que dizem ter tais funcionalidades por não possuírem um motor.

37. ERP, Enterprise Resource Planning,Gestão de Recursos Empresariais. 38. MRP e MRP II, Material Requirements Planning.

98 BPM & BPMS

O que na verdade os fabricantes zeram foi incluir em seus produtos determinadas características do modelo WfMC39 – o que não os torna completamente Workow, embora pareçam Workow. Essa solução pode até mesmo ser considerada uma evolução dos sistemas de gestão empresarial, mas daí a dizer que o ERP tem Workow embutido vai uma diferença muito grande. BPMS, assim como seu módulo Workow, nasceu para ser uma ferramenta independente e comsoftwares isso poder ser integrada, sem exceções, a todas as outras ferramentas, e sistemas quer sejam emergentes ou não. Esse tipo de atuação, entre outras vantagens, nos permite atualizar o processo que estiver sob o BPMS sem a necessidade de fazê-lo na outra ferramenta que estiver sendo usada de forma integrada e vice-versa. Alguns ERPs são muito complexos, e a utilização de funcionalidades de Workow existentes neles torna-se cara e demorada pelo volume de programação necessária para denir cada um dos elementos de cada processo que se queira automatizar por meio destes produtos. Esse é outro importante ponto a se considerar. Existem alguns parâmetros pelos quais se pode analisar melhor a questão da independência versus integração a m de decidir qual dos dois modelos devemos adotar, se o embutido ou o autônomo. Esses parâmetros, entre outras funções, denem o grau de interação do software com outras Tecnologias da Informação. Por exemplo: disparar rotinas não caracteriza um ERP como Workow, mesmo que este ERP possa ser programado com outras funcionalidades inerentes a softwares de Workow. As classes por meio das quais podemos analisar ferramentas (funções) de Workow embutidas em outros softwares são: 

Soluções proprietárias. São ferramentas com tamanho grau de integração que é impossível fazer-se uso independente e genérico das do suas funcionalidades, sendo obrigatória a sua utilização através sistema que as hospeda.



Soluções semiabertas. São ferramentas que possibilitam integração com outros sistemas que não aquele que as hospeda.

39. WfMC, Workow Management Coalition.

BPMS 99

Por exemplo: com aplicações client ou de automação de escritório (Ofce Automation). 

Soluções abertas. Essas soluções podem ser integradas a qualquer sistema externo. Soluções abertas podem ser acessadas tanto no sentido “in” (entrada), como no sentido “out” (saída). São as ferramentas que mais se assemelham ao modelo WfMC, justamente por manterem a essência da expressão integraçãoindependente.

Convém salientar que a incompatibilidade entre estas três classes exclui a possibilidade de existirem softwares que possam ter ao mesmo tempo características de cada uma delas combinadas entre si, por isso elas são mutuamente exclusivas. A tabela 4.1 lista e explica cada um dos parâmetros que podem ser usados para comparação entre os dois tipos de Workow, autônomo e embutido. Parâmetro

Workow Autônomo

Workow Embutido

Cada ferramenta tem

A visualização é a mes-

uma interface com visualização diferente.

ma um para todo.o sistema como

Graphical User Interface (GUI)

Diferentes para cada marca de Workow.

Única dentro da mesma marca.

Integração com ODBCs

Limitado pela disponibilidade de interface da ferramenta.

Integração completa.

Modelagem

Diferente de ferramenta para ferramenta.

Diferente de ferramenta para ferramenta.

Aderência ao modelo WfMC

Ferramentas mais aderentes por serem independentes.

Ferramentas de difícil aderência.

Integração com outras ferramentas

Integração manual.

Integração automática.

Integração com padrões CORBA, OLE, DDE, etc.

De difícil utilização por Padronizado pelo modeserem sistemas proprilo WfMC. etários.

Uma única interface com o usuário

100 BPM & BPMS

Parâmetro

Workow Autônomo

Workow Embutido

Instalação e manutenção

Adicional.

Adicional.

Escalabilidade

Dependendo da ferramenta, muito simples.

Quase impossível.

Aplicabilidade Aprendizagem

Completa e ilimitada. Mais uma ferramenta para aprender.

Limitada. Mesma ferramenta já aprendida.

Tabela 4.1 - Comparação entre Workow Autônomo e Workow Embutido

Embora alguns autores e pesquisadores possam enxergar benefícios num Workow embutido, eu sou mais purista, isto é: para mim Workow embutido tem mais desvantagens que vantagens, e as desvantagens superam qualquer vantagem que possa vir a existir com a utilização de um Workow embutido.

Figura 4.2 – Workow Autônomo.

BPMS 101

A gura 4.2 mostra como um software de BPMS, por meio do módulo de Workow, deve ser utilizado levando-se em conta o princípio da IntegraçãoIndependente. Note que a camada de Workow está completamente separada dos outros softwares. É preciso car claro que o que estamos discutindo aqui é a característica de Integração-Independente que um software de BPMS (Workow) deve ter para sertrabalha usado em conjunto comsoftware outras tecnologias. Quando o BPMS (Workow) junto com outro qualquer a automatização ea supervisão dos processos estarão garantidas quanto a tempos, regras de negócio, rotas, alçadas, gerenciamento das exceções, sem risco de solução de continuidade e com ambos mantendo suas características srcinais. A gura 4.3 mostra a utilização do Workow embutido. Note que o Workow está dentro de cada software, impossibilitando, entre outras coisas, que ele seja utilizado para integrar outros softwares.

Figura 4.3 – Workow Embutido.

102 BPM & BPMS

Além de todos os argumentos apresentados, que poderíamos chamar de técnicos, há outro denitivo: o custo de um “client” de ERP é em média dez vezes maior do que o de um “client” de Workow puro. Geralmente a integração de uma ferramenta de Workow com um ERP se dará através dos bancos de dados utilizados pelo segundo; entretanto, como regra de segurança, sempre que perguntado a respeito, explico que existem dois momentos numa integração desse tipo:  O momento da leitura dos bancos de dados; 

O momento da gravação ou atualização dos bancos de dados.

Quando houver a necessidade do Workow ler algum dado de qualquer base de dados, pertencente ao ERP ou a qualquer outro sistema corporativo, acho seguro que isso seja feito diretamente sobre o banco de dados que o sistema precisa acessar e desde que respeitadas as regras de segurança do banco de dados. Em outras palavras, “ler não tira pedaços”. Mas quando o tipo de interação é a gravação ou atualização, invariavelmente, sou contrário a que essa interação seja feita diretamente sobre o banco de dados. É preciso ter muito cuidado e total controle do que o sistema deverá fazer. Em se tratando de ERPs sugiro que as gravações e atualizações sejam feitas num DB intermediário e que posteriormente as próprias rotinas do ERP se incumbam de gravar ou atualizar seus bancos de dados ou que se usem os próprios agentes ou APIs do ERP que estivermos integrando ao Workow. Entretanto, quando se tratar de qualquer outro sistema corporativo, do tipo que chamamos de “feitos em casa”, o Workow pode interagir diretamente com seus bancos de dados, desde que sejam tomados todos os cuidados com as regras de segurança de acesso ao banco de dados. Preocupa-me o fato de os sistemas ERP terem sido construídos com milhares de tabelas internas (anal é justamente por isso que eles servem para qualquer tipo de empresa), alguns chegando a ter 65.000 tabelas e, normalizadas em alguns e sem qualquer estrutura lógicagravar em outros, o queum exige do “programador” conhecime ntos exatos sobre onde ou atualizar dado – tarefa que não é das mais simples dentro de um ambiente como esse. Apagar qualquer informação está fora de cogitação, tanto em sistemas ERP como nos demais sistemas corporativos. Embora possa, o Workow não deve assumir essa responsabilidade.

BPMS 103

Exemplo 1 O primeiro exemplo de integração entre um Workow e um ERP diz respeito à colocação e ao tratamento de pedidos de clientes. Essa é uma ocorrência extremamente crítica, pois cada vez mais o que conta nessa relação são características como acessibilidade, tempo e conabilidade. Além, é claro, do tratamento de cada pedido com qualidade 100% na primeira vez. Em qualquer sistema, as ordens de clientes só começam a ser processadas quando o funcionário encarregado de fazê-lo entra no sistema ERP e aceita a ordem conferindo-a e, se for o caso, corrigindo-a para em seguida passá-la à próxima atividade. Ocorre que se o tal funcionário não entrar no sistema e/ou não tratar a ordem, ela permanecerá ali, à espera de que alguém o faça. Isso causa inúmeros problemas para a organização. Quando, entretanto, colocamos uma camada de Workow sobre o ERP, o pedido do cliente passa a se beneciar da automatização da ferramenta. Se o pedido do cliente não for tratado dentro das regras de negócio e do tempo estipulado para seu processamento, o Workow tomará as providências de acordo com as regras de negócio que tenham sido parametrizadas no software.

Exemplo 2 Quando o setor de compras tem que fazer cotações utilizando um ERP, geralmente o faz via papel ou, no máximo, via e-mails. A utilização de uma ferramenta Workow pode automatizar o processo de compras a ponto de enviar ocorrências de Workow para cada fornecedor cadastrado no sistema. Isso faz com que todos trabalhem sob as mesmas regras de negócio e com o tratamento do tempo para a resposta controlado pela ferramenta.

Integrando Workflow à Manufatura Discreta Para a melhor forma de integrar um Workow a uma sistema ERP éescolhermos necessário que antes revisemos alguns conceitos inerentes processos industriais de manufatura. Os processos industriais são subdivididos em processos de manufatura e de serviço.

104 BPM & BPMS

Manufatura. O termo é herança da revolução industrial, século XVIII, quando quase tudo que se produzia era feito à mão, ou tinha uma parcela considerável de intervenção manual humana para tanto. Hoje, embora o grau de utilização de tecnologias seja altíssimo, o termo manufatura40 continua a ser usado para designar produção de coisas tangíveis. Dentro desse tipo de produção há basicamente duas formas de se produzirem coisas tangíveis e isso deu srcem aos dois tipos de processos a seguir: 

Manufatura discreta. Este tipo de manufatura tem diversos subtipos e estão classicados por ordem crescente de volume e decrescente de variedade; basicamente, dizemos que os processos de manufatura discreta “são aqueles que produzem coisas que é possível contar.” Essa classicação41 é usada pela maioria dos especialistas em processos. São eles: 

Processos de Jobbing. A principal diferença entre esse tipo de processo e todos os outros aqui listados é que tudo o que é produzido neles é produto único, diferenciado dos demais produtos pela adição de características exigidas pelo cliente. Entretanto, diferentemente dos processos de projetos cujos recursos sãonoalocados exclusivamente para produzirsão umcomúnico produto, de jobbing os recursos de produção partilhados com diversos outros produtos igualmente customizados, ou feitos sob encomenda. Vamos pegar o exemplo de um ferramenteiro que produz ferramentas diversas; embora cada ferramenta seja única, sua produção compartilha recursos que produzem outras ferramentas. Outros exemplos de jobbing são processos de restauração de móveis, confecção de roupas sob medida, montagem de automóveis de alto luxo e até construção de aeronaves.



Processos de produção em lotes.Também conhecidos como processos de produção em batelada, produzem com níveis de variedade e quantidades os grau diferenciam dos processos de jobbing,que, pois de nãocerta têm forma, o mesmo de va-

40. Trabalho executado à mão. Obra feita à mão. Estabelecimento industrial que fabrica seus produtos em grande quantidade. 41. Nigel Slack et al (1997).

BPMS 105



riedade que aqueles, uma vez que serializam a fabricação do produto enquanto um mesmo lote estiver sendo processado. Isso signica dizer que para aquele lote não variam as especicações nem as características do produto que estiver sendo processado e todos os recursos empregados para tal m estarão repetindo as operações e utilizando os mesmos recursos. Alguns processos de fabricação em lote são: produção de vestuário e produção de alguns tipos de motores.  Processos de produção em massa. Fabricação de grandes volumes e baixa variedade de produtos caracteriza o tipo de operação desse processo. A diferença básica entre ele e os outros listados anteriormente é que os volumes processados pelos recursos alocados para tal nalidade não sofrem qualquer tipo de variação, nem de quantidade nem de especicidade. Por exemplo, automóveis comuns são montados dentro de processos de produção em massa, diferentemente dos processos que montam automóveis de alto luxo, como Ferraris e Rolls-Royces. Produtos fabricados por processos de fabricação em massa são: televisores, geladeiras, (processamento de) carne de frango, de boi, entre outros. Manufatura contínua. A manufatura contínua, genericamente, produz coisas que pesamos e/ou medimos. São processos que estão na base das indústrias petroquímicas, químicas, siderúrgicas, fábricas de papel e celulose, usinas de energia. Processos desta natureza produzem continuamente, geralmente por longos períodos de tempo, e são basicamente “gerenciados” por tecnologias de processos, diferentemente dos processos de natureza discreta e de serviços que são gerenciados por pessoas.

O evento que inicia o ciclo de manufatura pode ser de dois tipos: 

Individual



Lote

Tanto individualmente como em lote eles compartilham de especicações que podem ser tratadas de forma igual. Essas especicações são mais consistentes em se tratando de produção em lotes, pois individualmente as diferenças podem chegar a ser maioria, o que inviabilizaria a adoção de especicações comuns pertinentes a vários “produtos.”

106 BPM & BPMS

Para os dois tipos de produção o primeiro evento chama-se Ordem de Produção, que é disparado por um Plano de Produção, que por sua vez teve srcem no que chamamos de Pedido de Cliente. Uma vez iniciado o ciclo de produção, segue um uxo de trabalho que levará a ordem de produção para ser executada em cada atividade dentro de uma sequência lógica e cronológica (processo). De atividade em atividade a ordem de produção segue sendo trabalhada até o nal quando o produto é inspecionado e liberado para embarque. Em cada atividade onde uma ocorrência tiver que ser executada o formulário eletrônico poderá trazer informações tais como: 

Especicações de manufatura.



Características do produto.



Números das peças que serão produzidas.



Lista de tarefas.



Número do cliente.



Número do inventário. Instruções especiais de fabricação (se for o caso).



Além destas, há a possibilidade de anexarmos documentos ao formulário eletrônico que complementariam as orientações da Ordem de Fabricação. Estes documentos podem ser plantas, esquemas grácos, mapas e serviriam para orientar os operários na linha de produção. Esta funcionalidade pode ser facilmente utilizada numa ferramenta de BPMS (Workow), possibilitando maior automaticidade e agilidade tanto em processos executados inteiramente dentro da mesma “planta”, via Intranet, como em processos executados em vários e distintos locais, por meio de uma Extranet e até mesmo, pura e simplesmente, utilizando a Internet.

Preocupações Essenciais Existem vários elementos que precisam ser cuidadosamente conhecidos e analisados para que um processo de manufatura discreta possa ser automatizado por meio de um software BPMS (Workow). Entre os mais importantes estão:

BPMS 107 





As rotas e as regras de negócio para o correto gerenciamento da sequência de fabricação no chão de fábrica. Quem irá rastrear as ordens de fabricação, desde a primeira até a última atividade do uxo. Como serão rastreadas as ordens de fabricação, desde a primeira até a última atividade do uxo.



A cronologia das operações críticas do processo, para que elas sejam realizadas na sequência e nos tempos certos.



As especicações que serão programadas para tratar qualquer ordem de fabricação atrasada. A carga de trabalho em todas as atividades a m de evitar, sempre que possível, a ocorrência de gargalos, folgas e restrições. Os documentos que devem fazer parte da ordem de fabricação e assegurar que estejam presentes em cada estação de trabalho, a m de garantir a correta execução da atividade. Os tempos de ciclo e processamento e as probabilidades de ocorrerem retardos causados por gargalos, restrições e inadequação entre carga e capacidade instalada de produção. Os custos de produção do processo por meio do controle dos custos de cada atividade presente nele.









Por m, mas não menos importante, 

O hardware que servirá como ambiente para “rodar” osistema BPMS (Workow). Incluir o hardware aqui pode parecer sem sentido, anal ele não faz parte do processo. Entretanto, todos os elementos e suas funcionalidades citadas só poderão ser programadas e utilizadas se a capacidade instalada, tanto de servidores quanto de estações de trabalho, for cuidadosamente planejada. Quanto maior for o detalhamento das características dos elementos listados, mais poderoso necessitará ser o hardware utilizado.

Exemplo Detalhado Esse hipotético exemplo de integração entre um processo de manufatura discreta e uma ferramenta de BPMS (Workow) se baseia na produção de três produtos, que passaremos a chamar de produto “A”, produto “B” e produto

108 BPM & BPMS

“C”. Cada um desses produtos percorrerá umuxo de trabalho distinto para que possam ser manufaturados nas diferentes células de produção. Algumas dessas atividades serão compartilhadas para fabricar alguns produtos, enquanto outras não poderão ser compartilhadas devido à natureza de outros produtos. Outra característica importante desse processo é que nele existem células de trabalho que, embora estejam em rotas diferentes, executam a mesma função, o que torna o processo passível de implantação de uma metodologia para balancear a distribuição da carga de trabalho entre elas. Como na totalidade dos processos de manufatura, esse que estamos exemplicando inicia-se com o pedido do cliente e termina com a embalagem, a expedição e o faturamento. A gura 4.4 mostra como o uxo do processo seria desenhado num software qualquer de BPMS (Workow). Cada uma das atividades contidas nesse uxo representa uma atividade existente no processo de manufatura discreta, executada no posto de trabalho.

Figura 4.4 – Processo genérico de manufatura.

BPMS 109

A Descrição do Processo 1o Evento: Pedido do Cliente. O pedido do cliente dispara a ordem de fabricação. Aqui temos já uma grande diferença com relação a processos não automatizados por BPMS (Workow). Esse pedido de cliente pode ser colocado no sistema de processamento de ordens de duas formas:  diretamente via BPMS (Workow), integrado com o módulo de processamento de ordens ou 

indiretamente por meio de um funcionário da administração de vendas, para a qual chegam todos os pedidos de clientes e que, posteriormente, se encarrega de colocá-los dentro do uxo de trabalho usando uma ferramenta BPMS (Workow).

Deve estar claro que a primeira forma seria mais produtiva e muito mais aderente ao modelo B2C42, mas muitas empresas ainda relutam em abrir suas operações para clientes via WEB e muitas das que o fazem apenas simulam essa ligação direta. Em resumo, essa atividade terá um formulário eletrônico que será usado para introduzir no sistema informações como: 

tipo de produto,



quantidade,



datas,



recomendações especiais e



especicações de manufatura.

2o Evento: 1a atividade – Programação da Produção. A ordem de fabricação vai para um programador de produção que tem por função assegurar que todas as partes e matérias-primas envolvidas na fabricação do produto sejam selecionadas conforme a lista de materiais do produto (bill of material) e nas quantidades corretas, e de que elas existam

42. B2C, jargão da área para a abreviatura da expressão Business to Consumer.

110 BPM & BPMS

no estoque. Se alguma não existir, o programador de produção irá disparar uma ordem de compra para garantir a sua disponibilidade no momento em que ela for exigida para a fabricação do produto. Além disso, o programador de produção, dependendo da empresa e da excelência do processo, tem também a responsabilidade por montar a composição, ou receita de fabricação, do produto especicado pelo cliente. Essa quando automatizada por que umaterão ferramenta BPMS (Workow), atividade, pode disparar vários subprocessos por incumbência disparar ordens de fabricação dos subconjuntos necessários à montagem do produto nal. O BPMS (Workow) pode vericar o BOM43 automaticamente, emitir a lista de materiais requeridos para a produção dos subconjuntos e encaminhá-la, juntamente com a ordem de fabricação, para a produção. 3o Evento: 2a atividade – Fabricação. A ordem de fabricação segue para a 2ª atividade do uxo de trabalho baseada no tipo de produto a ser fabricado, “A”, “B” ou “C”. Como mostrado na gura 4.4, existem três diferentes células de trabalho para essa 2ª atividade, e a ordem fabricação segue automaticamente para (regras a célulade apropriada através dasdecaracterísticas de roteamento condicional negócio) denidas no BPMS (Workow). Tanto por células quanto por atividades den tro de cada uma delas, é possível fazer o roteamento baseado na carga de trabalho de forma predenida ou dinâmica, o que confere ao processo de fabricação total automatismo e ganhos de produtividade consideráveis. 4o Evento: 3a atividade – Fabricação. Tão logo o trabalho na 2a atividade esteja concluído, a ordem de fabricação é enviada à 3a atividade. Todas as considerações expostas no parágrafo referente à 2a atividade são igualmente aplicáveis para esse ponto do uxo de trabalho. Convém salientar que, nesse processo, existem diferentes atividades dentro de diferentes células de trabalho especializadas por produto. 5o Evento: 4a atividade – Fabricação. Nessa célula, os produtos “A” e “B” compartilham a mesma atividade enquanto o produto “C” é trabalhado por outra atividade, dentro de outra célula. 43. BOM, Bill of Material, ou Lista de Materiais.

BPMS 111

Isso se dá por questões de especialização do trabalho, pois nesse processo o produto “C” tem características especiais e por isso deve ser processado por essa atividade especializada. 6o Evento: 5a atividade - Testes. Tanto o produto “B” quanto o produto “C” são enviados para testes na mesma atividade, mas o produto “A”, por causa de características especiais, deverá ser testado em outra atividade. Através da parametrização das regras de negócio e das “regras” para o tratamento das exceções, o uxo a ser percorrido por qualquer produto pode mudar sem intervenção humana e garantir que sob as mesmas condições todas as igualdades e diferenças serão tratadas conforme o planejado. 7o Evento: 6a atividade - Embalagem. Todos os produtos são enviados para a mesma atividade para serem embalados e posteriormente embarcados para o cliente. Podem existir diversas atividades dentro dessa célula para realizarem esse trabalho e como todos os tipos não requerem nenhum tipo especial de embalagem o BPMS (Workow) pode ser programado para enviar as ocorrências a uma la. Todas as atividades de embalagem vão até essa la, retiram uma ocorrência e a tratam. Entretanto, a qualquer momento esse uxo de distribuição pode ser alterado manualmente pelo supervisor da célula para tratar uma emergência ou qualquer outra eventualidade, redistribuindo dinamicamente a carga de trabalho. 8o Evento: 7a atividade – Expedição. Nesta atividade os produtos são preparados para serem despachados para os clientes. Geralmente aqui é feita uma relação dos produtos que serão embarcados para que o faturamento possa emitir as notas scais correspondentes. 9o Evento: 8a atividade - Faturamento. Finalmente são emitidas as notas scais para o envio dos produtos aos clientes. 10o Evento: Este evento encerra o processo de manufatura.

112 BPM & BPMS

Explicação Importante Você provavelmente estará pensando: “Não vi nenhuma diferença entre esse exemplo e qualquer processo de manufatura gerenciado por umsoftware de ERP.” Se eu o estou subestimando, peço desculpas. O fato é que à primeira vista pode mesmo parecer que não existem diferenças signicativas entre um e outro. Entretanto, a principal delas está na palavra que dene a ação de cada um desses softwares. Enquanto um ERP gerencia recursos, o BPMS (Workow) automatiza o gerenciamento tanto dos recursos quanto dos processos que os utilizam! O exemplo anterior se limitou a mostrar o básico. Em um processo real várias outras atividades estariam presentes. Por exemplo, a gura 4.5 mostra que, após o programador de produção ter feito seu trabalho e por meio dele ter detectado que certos materiais não constam do estoque, uma ocorrência seria automaticamente encaminhada ao comprador daquele tipo de material para que este pudesse ser adquirido.

Figura 4.5 – Pedidos automatizados por BPMS (Workow).

BPMS 113

A gura 4.6 mostra a ligação entre os processos de manufatura, primário, o de compras e o de recebimento, ambos secundários. O vendedor dispararia ocorrências para os fornecedores já cadastrados que, também via BPMS (Workow), enviariam suas propostas de fornecimento. Os vendedores enviariam as mercadorias compradas que seriam recebidas pelo processo de recebimento.

Figura 4.6 – Integração entre os diversos processos.

Além destas ligações entre processos primários e secundários por meio de ocorrências automaticamente geradas pelo BPMS (Workow), há a funcionalidade que permite anexar qualquer tipo de documento a um formulário eletrônico, o que garante o envio de plantas, esquemas ou instruções de manufatura atualizadas a qualquer atividade de qualquer processo.

Softwares para Processos de Negócio

Divido os softwares para processos de negócio em três classes distintas entre si pelo tipo de abrangência, interação e automatização que têm sobre qualquer processo de negócio. As classes são: 

Softwares para documentação, desenho, redesenho e modelagem de processos de negócio.

114 BPM & BPMS 

Softwares para documentação, desenho, redesenho, modelagem e simulação de processos de negócio.



Softwares para documentação, desenho, redesenho, modelagem, simulação e automatização de processos de negócio.

Todos os principais softwares (pelo menos os mais conhecidos) para documentação, desenho, redesenho, modelagem, simulação e automatização de processos de negócio estão listados no Anexo I. No Anexo III está a relação dos vendedores de Business Process Management Systems, que engloba softwares das três classes denidas por mim aqui, o que signica dizer que há produtos muito caros por serem completamente BPMS, com diversas ferramentas de TI embutidas no conjunto, e há, na extremidade oposta, produtos extremamente baratos por serem simples, sem ferramentas e softwares agregados na suíte. Hoje já há até mesmo softwares BPMS gratuitos. Inteiramente gratuitos, eles são tão complexos e plenos quanto os “melhores” e mais conhecidos Business Process Management Systems existentes. Os “fabricantes” de tais softwares ganham dinheiro ensinando uso seu solving)o e, produto (how-to-use ), resolvendo problemas (problem atédomeson-line mo, vendendo consultoria para análise, desenho, redesenho e modelagem de processos de negócio. Não vou detalhar estes softwares como z no passado com alguns sistemas de Workow porque depois torna-se impossível manter este livro atualizado à medida que estes produtos evoluem e agregam novas funcionalidades a cada nova versão lançada. No passado, começando pelos livros de Workow que escrevi, eu detalhei cada software referenciado neles porque a Internet ainda não tinha todas as ferramentas de busca que existem hoje, e que possibilitam a quem estiver interessado aprofundar-se no conhecimento de cada software aqui listado. A começar pelo Visio, da suíte Microsoft Ofce, que é um dos mais simples existentes, até chegar a um IBM’s WebSphere Business Modeler, dos mais completos e complexos, todos podem ser usados para documentar processos como tarefa primordial. Entretanto, não tente aprender processo de negócio por meio de qualquer um destes softwares, pois nenhum deles pode conter todos os elementos que o processo de negócio tem.

BPMS 115

Quando pensamos poder adquirir conhecimento sobre processo de negócio por meio de qualquer um destes softwares listados, para análise, desenho, redesenho e modelagem de processo de negócio, estamos repetindo a fábula da caverna, de Platão. Platão, por meio desta fábula, nos ensina que a realidade é muito diferente daquela que na maioria das vezes quem tem poder quer nos fazer acreditar, ou seja,software quem adquire conhecimento processos de negócio através de um para análise, desenho,sobre redesenho e modelagem de processo de negócio, qualquer que seja este, estará conhecendo apenas “uma ou alguma realidade” sobre processos de negócio, aliás, uma parte ínma da realidade – e algumas vezes até mesmo, além de mínima, será uma realidade distorcida. Esta realidade incompleta e por vezes falsa induzirá e conduzirá projetos de análise, desenho, redesenho e modelagem de processos de negócio ao fracasso.

Figura 4.7 - Conjunto de tecnologias existentes no software BPMS. Fonte: (gura criada com base no modelo) BPTrends (http://www.bptrends.com/).

Em resumo, softwares para análise, desenho, redesenho e modelagem de processos de negócio são muito úteis, mas não encerram todas as verdades existentes no universo do processo de negócio. Isto signica dizer que pri-

116 BPM & BPMS

meiro é preciso aprender sobre processo de negócio para só então, depois de analisarmos quanto do universo do processo de negócio cada software consegue representar, comprarmos o produto que melhor atenda às nossas necessidades e ao nosso bolso. Embora esta possa parecer uma discussão sem propósito, posso garantir que até mesmo alguns amigos meus, professores doutores, já estiveram prestes a incorrer neste se erro quando um brasileiropara de um software ricano tentou aproveitar do representante nome da universidade a qual estesame professores trabalham dando à instituição o direito de uso do software em troca do nome da universidade nas suas peças promocionais. O maior problema era que estes professores pensavam poder aprender e ensinar processo de negócio por meio do software que seria “doado” à universidade, até que eu lhes coloquei meu ponto de vista. Felizmente o acordo não chegou a ser feito nas bases que o representante havia proposto. O absurdo maior é que um curso sobre processo de negócio seria criado e ministrado com o suporte do tal software, o que iria formar “conhecedores de processo de negócio” com a visão do software em questão e não com a visão completa do universo do processo de negócio.

Computer-Supported Cooperative Work Foi devido ao contexto descrito nos capítulos 1, 2 e 3 que surgiram os produtos aderentes ao conceito Computer-Supported Cooperative Work (CSCW). Produtos aderentes ao conceito CSCW empregam tecnologias Groupware44. Diferentemente de outros softwares, os da família Groupware empregam componentes cujo principal objetivo é o de possibilitar que as pessoas trabalhem naturalmente em grupo. Assim, qualquer software que empregue separadamente ou em conjunto alguns dos componentes listados a seguir são, em princípio, softwares Groupware. Categorias das aplicações Groupware: 

aplicações baseadas em documentos e formulários;



aplicações baseadas em grandes volumes de dadose transações;

44. São sistemas computadorizados que permitem a grupos de usuários trabalharem de forma cooperativa em algum propósito ou objetivo comum.

BPMS 117 

aplicações baseadas em comunicação organizacional.

Nos dois primeiros grupos estão: 

mecanismos e facilidades de comunicação;



gerenciadores de documentos;

 

controladores de uxo de formulários; controladores de uxos de trabalho (Workow);



Object Oriented Data Base Management Systems;



gerenciamento de imagem;



recuperação de dados e informações.

No grupo de aplicações baseadas em comunicação organizacional estão: 

calendário;



agenda eletrônica;

 

mecanismos de colaboração; videoconferência;



Workow.

O Surgimento do BPMS Do ponto de vista dos interessados no tema BPMS e principalmente dos “fabricantes”, o precursor deste software, o Workow, ainda não vendeu o quanto poderia ou deveria ter vendido no mercado estimado em nível mundial para este tipo de Tecnologia da Informação, ou seja, Workow ainda não foi comprado pelas organizações (no mundo todo) com a mesma intensidade e nas mesmas quantidades que outros softwares o foram, como os ERPs por exemplo. Por que será? Por que as empresas não compram Workow como compram outros softwares, já que este tem uma proposta tentadora? Automatizarprocessos de negócio, garantir a execução das regras de negócio, controlar o tempo programado para que as tarefas sejam executadas, são necessidades que toda organização tem. Então por que tão pouco Workow vendido até hoje?

118 BPM & BPMS

As principais razões que a meu ver justicam as baixas vendas (e compras) mundiais de Workow são45: a. Os possíveis compradores acham o software Workow caro por não conseguirem entender quais são os reais benefícios que ele traria à organização. b. Também do ponto de vista dos compradores, há a imperiosa necessidade de contratarem e manterem prossionais especializados no produto para a implantação e atualização do mesmo. c. Mais que qualquer outro software, Workow necessita que a análise,o desenho e redesenho & a modelagem de processos de negócio seja realizada com detalhamento maior para poder ser implantado; e isso acarreta ao projeto custos que muitas vezes são ignorados (e cortados) quando da implantação de outros softwares como o ERP, por exemplo. d. A necessária mudança cultural que o software de Workow obrigará as organizações a encetarem se quiserem operar dentro do espírito Computer-Supported Cooperative Work. Talvez esta seja a parte mais difícil da implantação do software. Não vou me estender procurando justicar aqui o porquê das vendas de Workow terem cado aquém do esperado, embora possa garantir que a lista chegaria facilmente à casa dos cinquenta motivos. A meu ver, o que interessa é saber que efetivamente Workow ainda não vendeu o potencial estimado. Por conta disto é que os “fabricantes” de softwares dessa classe de software decidiram que era chegada a hora de “incrementar” a ideia original na busca por aumentarem suas vendas – fazer o que os prossionais de marketing chamam de revitalizar a marca. Daí surgiu o software BPMS. Outros autores têm outras versões para o surgimento do BPMS. popularizados mesmodos tempo, do workow, emAo meados anos os 90,sistemas amadureceram e são usados agora extensamente. Essencialmente, quando falamos de sistemas

45. Para saber mais sobre este tema leia Uso e Desuso de Sistemas de Workow, Tadeu Cruz, Editora E-Papers.

BPMS 119

de workow, falamos de sistemas que controlam a interação entre empregados e dados. No início os sistemas de workow foram projetados para gerenciar o processamento de documentos. Os formulários eram digitalizados e armazenados em bancos de dados. Depois surgiram as versões eletrônicas dos formulários que passaram a ser distribuídas às estações de trabalho dos empregados de modo que podiam ser processados. Assim que um empregado terminasse de processar um formulário, ele era distribuído automaticamente ao empregado seguinte dentro do uxo de trabalho. No nal dos anos 90, os sistemas de workow tinham sido integrados nos sistemas

de Planejamento de Recursos Empresarias para facilitar a interação dos empregados com aplicações de ERP. Entretanto, logo cou evidente que a gerência de múltiplos “motores” de workow – um para cada aplicação de ERP – era uma tare -

fa demasiadamente complexa. Ficou claro que o melhor seria ter um único motor de workow que poderia controlar todos os

empregados e todas as aplicações usadas em um processo de negócio completo. Esta necessidade – combinada com a necessidade de integração do Enterprise Application Integration (EAI) – levou os vendedores de ERP a adicionar elementos de workow a seus produtos e a uma movimentação similar por parte dos vendedores de workow para adicionar elementos

de EAI a seus produtos – nascendo daí o software de BPM (MIERS e HARMON, 2005).

Há alguns pontos da citação transcrita que merecem algumas observações. Primeiro, não é de todo verdadeira a armação de que os primeiros sistemas de Workow foram criados para gerenciar o processamento de documentos (manage document processing). Todos que se interessam pelo tema sabem que Workow foi criado para automatizar Regras de Negócios (Rules) inerentes a tarefas sob responsabilidade dos Papéis Funcionais (Roles) existentes em processos (Routes). Facilidades como denição de formulários eletrônicos e anexação de documentos dentro do software surgiram muito tempo (e várias versões) depois que o Workow já existia. Também é fala ciosa a armação de que nos anos 90 os sistemas Workow foram integrados aos sistemas ERP, embora alguns fabricantes tenham tentado fazer as organizações acreditarem que seus produtos embutiam sistemas “puros” de

120 BPM & BPMS

Workow. Muitas das organizações que tentaram usar algumas funcionalidades do modelo Workow embutidas em ERPs desistiram de fazê-lo após constatarem o seu elevado custo de programação, implantação e atualização46. Outra armação sem qualquer fundamento técnico (a não ser para justicar o injusticável: o software BPMS) é a de que gerenciar vários “motores” de Workow transformou-se em algo extremamente complexo (that the management of multiple workow engines was too complex) uma vez que não há tecnologia ainda para fazer um único “motor” de BPM processar um número innito de transações. O principal documento do Workow Management Coalition traz o seguinte texto sobre este assunto: Workow encarrega-se de automatizar procedimentos onde

documentos, informações e tarefas são passadas entre participantes de acordo com um conjunto de regras denidas a m de contribuir com, ou atingir, os objetivos do negócio . Fonte: WfMC. TC00-1003 Issue 1.1 Workow Reference Model Prin ted 19/11/98, acessado em 27/01/2006.

A versão nal do documento citado é de 1998, mas tanto ele como as denições nele contidas continuam atualíssimas. Vários produtos Workow que conheço já tinham, em 1999, capacidade para gerenciar vários motores de Workow, fazendo-os trabalhar de forma integrada e harmônica. Mesmo porque todos ossoftwares de BPMS que conheço não diferem em nada neste particular dos softwares de Workow já existen tes. Também em termos de capacidade de processamento de transações já existiam antes do surgimento dos BPMS softwares de Workow com grande capacidade diária para processá-las. Alguns softwares já processavam num único motor algo em torno de cem mil transações/dia, e a capacidade do sistema operacional Microsoft XP atendia a um milhão de transações/dia. A capacidade total de processamento de alguns excelentes softwares de Workow ser multiplicada pela adoção deque vários motores trabalhando de formapodia concatenada pelos bancos de dados os suportavam.

46. Não vou nomear as organizações que tentaram implantar Workow utilizando os módulos existentes nos ERPs, mas posso assegurar que duas delas são usuárias da SAP.

BPMS 121

Tecnologias Envolvidas com BPMS Existem várias e diferentes abordagens sobre este tema, assim como diversas classicações para as tecnologias que compõem o conjunto (suíte) Business Process Management System. Todas estas abordagens têm sempre algum ponto em comum entre si e meu intuito aqui é o de elucidar, na medida do possível,secomo todas as abordagens, classicações e Tecnologias da Informação intercalam, integram e interagem para formar e fazer funcionar um BPMS. Para organizar melhor as ideias, e, consequentemente, manter uma linha de raciocínio que me permita explicar, e a você entender, o que está por trás do Business Process Management System dividi as tecnologias envolvidas em três grandes grupos: 

1o Grupo: o dos padrões de conformação.



2o Grupo: o das linguagens de programação.



3o Grupo: o dos componentes de integração.

Business Process Management Systema consTodos os especialistas emtecnologias falam dele como um conjunto de cuja nalidade é a de facilitar trução de sistemas que integrem completamente o ambiente de negócio de qualquer organização. É por isso que a arquitetura ( framework) BPMS foi construída com tecnologias emprestadas de outros ambientes pois, salvo as linguagens que citarei a seguir, nenhuma foi inventada especicamente para o Business Process Management System. Esta estrutura, conhecida no nosso meio como BPMS Suíte, é mais uma tentativa de explicar por que BPMS pode fazer mais que qualquer software de Workow existente até então. A gura 4.8 foi livremente redesenhada por mim para servir de base às próximas colocações.

Cada uma das tecnologias listadas a seguir, no meu modo de entender, ou já estavam no modelodeWorkow WfMC, ouatépoderiam ser integradas aos presentes melhores softwares Workowdoexistentes então, com algum esforço de programação. Por isso dicilmente algum CIO conseguirá justicar o investimento necessário para adquirir as novas BPM suítes se já possuir algum bom software de Workow, excluindo-se, claro, aqueles que estão sempre em busca de novidades como forma de garantir e justicar seus empregos e salários.

122 BPM & BPMS

Figura 4.8 - Conjunto de tecnologias existentes no software BPMS. Fonte: (gura criada com base no modelo) BPTrends (http://www.bptrends.com/).

As tecnologias apontadas por todos como sendo as novas tecnologias integradas ao BPMS são:      

Ferramentas para Modelagem de Organizações. Ferramentas para Modelagem de Processos. Ferramentas para Estatística. Ferramentas para Simulação. Ferramentas para Gerenciamento de Regras de Negócio. Aplicações de BPM.



Ferramentas para Monitoração de Processos. Ferramentas para Desenvolvimento de Software. Ferramentas EAI (Enterprise Application Integration). Ferramentas SOA (Service-Oriented Architecture)



Ferramentas para gerenciamento do ambiente Workow.

  

BPMS 123 

Servidores de Aplicações.



Linguagens BPMS.



ERP, CRM e outros softwares e aplicações.



Data Warehouse e BI.

Outros especialistas preferem classicar as tecnologias envolvidas com o Business Process Management System da seguinte forma: 

ECMS, Enterprise Content Management Systems47.



EDMS, Electronic Document Management Systems48,49.



Workow50.



EAI, Enterprise Application Integration.



RM, Records Management.



API, Application Program Interface.



SOA, Service-Oriented Architecture.

Basicamente qualquer uma das classicações serve para explicar o software BPMS. Vou usar a classicação mais extensa por considerá-la de melhor aderência ao conceito Business Process Management System.

Ferramentas para Modelagem de Organizações Não existe nenhuma descrição sobre os objetivos, como são ou de quais tecnologias são compostas tais ferramentas para modelagem de organiza-

47. Descrita em português no livro Gerência do Conhecimento. Editora E-papers, 2ª edição. 48. No Brasil chamamos de GED, Gerenciamento Eletrônico de Documentos, e foi descrita em português no livro GED – Gerenciamento Eletrônico de Documentos (Baldan, Cavalcante e Valle, 2002). 49. EDMS em Inglês signica apenas Sistema de Gerenciamento Eletrônico de Documentos. Entretanto, no Brasil é utilizado também como Gerenciamento Eletrônico de Documentos Técnicos e de Engenharia, Engineering Document Management Systems. 50. Descrita em português nos livros Workow, a tecnologia que vai revolucionar processos (Cruz, 1999) e e-Workow, como implantar e aumentar a produtividade de qualquer processo (Cruz, 2001), objeto de detalhamento nesse trabalho.

124 BPM & BPMS

ções, em qualquer literatura BPM ou BPMS. Mas podemos inferir, a partir do enunciado de vários documentos consultados, que tais ferramentas serviriam para o planejamento estratégico da organização. Sendo assim, são perfeitamente dispensáveis em um software de BPMS, no strictu sensu das suas responsabilidades e funcionalidades. A modelagem de organizações não raro é confundida com a modelagem do negócio, pois aambas são realizadas por meio de metodologias e tecnologias que auxiliam organização na formação e formalização do seu negócio e dos seus objetivos (plano estratégico), oferecendo uma representação consistente e única. Uma destas metodologias é o planejamento estratégico, que não pode ser menos importante que o BPM ou o BPMS, pois realizado corretamente e precedendo a criação do plano operacional, que é de onde serão criados os processos de negócio da organização, permitirá a qualquer uma existir corretamente. Sabemos que processos de negócio só devem existir (mesmo que informalmente) se, e somente se, estiverem direta ou indiretamente (tanto processos primários quanto processos secundários) alinhados ao plano estratégico da organização. Em outras palavras, qualquer processo de negócio só deve existir se estiver alinhado com os objetivos da organização. Não pode existir nenhum processo de negócio, produzindo o que quer que seja sem estar alinhado aos objetivos estratégicos da organização. Quando nos deparamos com ferramentas para modelagem de organizações numa estrutura de Business Process Management System, o melhor será entendermos sua presença em tais softwares como indicação da imperiosa necessidade, condição sine qua non, de que todos os processos existentes em qualquer organização sejam corretamente criados, isto é, tenham sido alinhados ao planejamento estratégico de onde, aliás, em última instância, são gerados os planos operacionais. Poucas organizações têm praticado corretamente este tipo de desenvolvimento e poucasde têm executado a cadeia de4.9. ações necessária paraorganizacional criação de processos negócio, como na gura Poucas têm condições de comprovar que seus processos foram criados em função da estratégia planejada para a organização porque o plano estratégico sequer existe informalmente. Muitas empresas, principalmente as pequenas e médias, relevam o planejamento estratégico por ignorarem sua importância, por economia ou absoluta falta de dinheiro para realizá-lo.

BPMS 125

Assim, processos de negócio ainda nos dias atuais seguem sendo criados à imagem e semelhança da Desorganização Informacional (DoI) existente em maior ou menor grau em todas as organizações. Na maioria das vezes os processos são completamente dissociados da estratégia organizacional, seja esta formal ou informal, justamente por causa da Desorganização Informacional. Existem metodologias criação do plano estratégico e, embora este livromuitas não seja sobre estepara tipo ade planejamento, por causa da citação no BPMS, convém ressaltar que há uma metodologia que consegue alinhar com perfeição o planejamento estratégico ao planejamento operacional e, consequentemente, garantir a correta criação dos processos de negócio. Este método chama-se Hoshin Kanri.

Figura 4.9 – Cadeia de ações necessária para criação de processos de negócio.

126 BPM & BPMS

Ferramentas para Modelagem de Processos Dez entre dez softwares de BPMS (Workow) que conheço têm ferramentas para organização, desenho, redesenho, análise e modelagem de processos de negócio (AMOP). Mesmo porque sem o módulo conhecido pelo nome genérico de Designer o BPMS não permitiria aos especialistas sua implantação de forma parametrizável. Em outras palavras, o princípio da parametrização existente no modelo Workow Management Coalition, WfMC, continua válido para o Business Process Management System. Quanto maior for o esforço de programação necessário para projetar e desenvolver um BPMS, menos parametrizável, dinâmico e aderente à realidade organizacional será o software e os processos automatizados. Entretanto, existem Designers com diversos níveis de interatividade com o software BPMS. Há os integrados, isto é, que fazem parte indissolúvel da suíte; há os integradosindependentes, que podem ser usados para modelar processos sem que necessariamente todas as especicações sejam aproveitadas, ou utilizadas, pelo software BPM e há os completamente independentes, “fabricados” por empresas especializadas em ferramentas para modelagem de processos, que podem gerar saídas utilizadas por softwares BPMS (Workow) de outros fabricantes.

Ferramentas para Estatística Aqui está um ponto importantíssimo do software BPMS, assim como para softwares de Workow: as ferramentas para controle estatístico do processo automatizado pelo software. Levando em consideração a essência de qualquer processo de negócio, concluímos que, no mínimo, o software BPMS deve estar preparado para gerenciar e fornecer os seguintes tempos para cada ocorrência que tiver sido processada: 

Tempo de Ciclo. No jargão internacional você ouvirá falar em Cycle Time. Tempo de ciclo é o tempo decorrido desde o momento em que uma ocorrência dá entrada numa atividade, ou no processo, até o momento em que esta mesma ocorrência sai da atividade, ou do processo.

BPMS 127 



Tempo de Processamento. Depois que uma ocorrência dá entrada numa atividade, e no processo, ela precisa ser processada, trabalhada. Este é o que chamamos de tempo de processamento. Você vai ouvir falar em Process Time, mas não confunda com o elemento processo de negócio (pense da seguinte forma: processos processam algo). O tempo de processamento é o efetivamente gasto por uma pessoa trabalhando, processando, a ocorrência que entrou na atividade dela. Tempo de Atraso ou, como também é conhecido, Tempo de Retardamento. Eu prero chamá-lo de Tempo de Espera. A diferença entre o tempo de processamento e o tempo de ciclo de uma ocorrência dentro de uma atividade e do processo chamase tempo de espera. Em inglês: Lag Time. Além de não ser um tempo produtivo, ele é um dos grandes vilões que comprometem a eciência de um processo.

Esses três tipos de tempos estão sempre presentes em qualquer processo e quanto menor for a diferença entre o tempo de processamento e o tempo de ciclo melhor será o processo em termos de eciência, ecácia e adaptabilidade. Além dos três tipos de tempos, que eu chamo de primários, existem os tempos derivados de cada um deles, relacionados a cada ocorrência que tenha entrado e saído do processo de negócio. Esses tempos, que vão nos ajudar a analisar de forma mais precisa o comportamento do processo, são: 

O Tempo Máximo. Este tipo de tempo permite medir o comportamento de cada uma das ocorrências desde que ela é introduzida na atividade e no processo até que ela é concluída. Perguntas como: 







Qual o tempo máximo de processamento de uma ocorrência pela atividade? Qual o tempo máximo de processamento de uma ocorrência pelo processo? Qual o tempo máximo que uma ocorrência qualquer levou desde que entrou na atividade e no processo até a sua saída? Qual o tempo máximo de espera de uma ocorrência qualquer na atividade e no processo?

128 BPM & BPMS 

O Tempo Médio. O cálculo do tempo médio de permanência de uma ocorrência qualquer dentro de uma atividade e do processo pode responder a perguntas como: 









Qual o tempo médio de processamento de uma ocorrência pela atividade? Qual o tempo médio de processamento de uma ocorrência pelo processo? Qual o tempo médio que uma ocorrência qualquer levou desde que entrou na atividade e no processo até a sua saída? Qual o tempo médio de espera de uma ocorrência qualquer na atividade e no processo?

O Tempo Mínimo. Através dele podemos descobrir onde estão as folgas, por exemplo, ou os funcionários mais ecientes e produtivos. A análise do tempo mínimo permite responder às perguntas: 







Qual o menor tempo de processamento de uma ocorrência pela atividade? Qual o menor tempo de processamento de uma ocorrência pelo processo? Qual o menor tempo que uma ocorrência qualquer levou desde que entrou na atividade e no processo até a sua saída? Qual o menor tempo de espera de uma ocorrência qualquer na atividade e no processo?

Claro, existem muitos outros tipos de tempos em processos primários e secundários. Entretanto, estes tempos são os existentes em processos de qualquer tipo e natureza e são passíveis de serem controlados por um software de BPMS. Junto com o controle de tempos será também possível controlar os custos de cada atividade existente no processo, mas esta funcionalidade varia de BPMS para BPMS.

BPMS 129

Ferramentas para Simulação Nem todos os softwares para desenho, redesenho, análise e modelagem de processos de negócio têm ferramentas que nos permitem simular os processos neles desenhados, redesenhados ou modelados, embora esta funcionalidade seja cada vez mais comum nesta classe de software. Os softwares mais simples não simulam as especicações dos processos criadas neles, como é o caso do Visio da Microsoft, exceto quando usado com o Arena da Rockwell. A maioria realiza simulações por meio de cenários construídos a partir das denições do próprio processo de negócio. As simulações mais simples eu chamo de automáticas-estáticas, por termos que trocar manualmente os cenários construídos a m de rodarmos cada nova simulação. Os softwares de simulação de processos mais sosticados e caros realizam simulações que chamo de automáticas-dinâmicas, pois executam ao mesmo tempo vários cenários construídos com base em modelos matemáticos, o que dispensa a intervenção do analista para trocar manualmente os cenários na execução das simulações. Por que a simulação de um processo é importante? Porque ela serve para:  

Treinar todos os funcionários que vão executar o processo. Analisar qual será a melhor forma de implantar o processo.



Descobrir (antes que seja tarde demais) quais os pontos fracos e fortes do processo a ser implantado.



Conhecer e analisar os gargalos, as restrições e as folgas existentes no processo.



Garantir os resultados esperados do processo.



Testar a capacidade instalada de produção.



Testar os tempos de ciclo, processamento e retardo, se houver.



Analisar a adaptabilidade, a eciência e a ecácia do processo.

130 BPM & BPMS

Figura 4.10 – Ciclo de simulação.

Simulação é uma parte extremamente importante no ciclo de vida doBusiness Process Managemen Systeme todo software de processos deveria tê-la como funcionalidade básica. Entretanto, não basta o software ter a funciona lidade que permite a simulação de cenários, pois para realizá-la é necessário que uma série de elementos tenham sido cuidadosamente construídos com base, claro, no desenho, redesenho ou modelagem do processo que queremos simular. Ao conjunto destes elementos damos o nome de cenários. Análogos aos do teatro essencial, os cenários do teatro organizacional51 são modelos que representam as possíveis realidades que o processo vai encontrar (ou não) na vida real, quando passar a ser executado. Assim, no mínimo, o Business Process Management System deve permitir a construção dos seguintes elementos para que possamos criar e usar cenários durante as simulações. 

Denição das Propriedades da Atividade: 

Nome do recurso.



Quantidade de recursos.



Custo por hora.



Tempo estimado de ciclo.



Tempo estimado de processamento.



Tempo total estimado.

51. Leia O Teatro Organizacional. Editora E-Papers.

BPMS 131 

Denição das Propriedades do Cenário: 





Distribuição das ocorrências: 

Normal.



Uniforme.

Unidade de tempo: 

Dias.



Horas.



Minutos.

Prioridade de processamento: 

FIFO.



Por prioridade.

A simulação pode ser automática-estática, com troca manual de vários cenários, e automática-dinâmica, com o uso conjunto de vários cenários, funcionalidade que permite construir modelos complexos da realidade. Os softwares BPMS podem executar simulações simples, pois permitem apenas a simulação automática com troca manual de cenários, até porque não são softwares feitos para terem nesta funcionalidade sua maior vantagem.

Ferramentas para Gerenciamento de Regras de Negócio Somente para recordarmos quão importantes são as regras de negócio para um software BPMS, o modelo conceitual do Workow foi construído em cima de 3Rs: Roles (papéis), Rules (regras) e Routes (rotas). Logo, as regras de negócio jamais podem ser opcionais em qualquer software BPMS ou podem estar dissociadas deste, no mínimo porque o Workow é um subconjunto do Business Process Management System. Para que serviria um software que está sendo vendido como “A” solução denitiva para integrar processos, tecnologias e atores, fazendo com que seus relacionamentos não sofram solução de continuidade, mantendo registros que servirão para a rastreabilidade e consequentemente criando condições para auditoria dos negócios realizados, sem que houvesse no BPMS funcionalidades para o gerenciamento de regras de negócio?

132 BPM & BPMS

Uma das maiores contribuições do modelo Workow, senão a mais importante, foi a criação do elemento regras de negócio e a de tê-lo denido como direcionador de uxo no software Workow, possibilitando-nos criar processos nos quais as pessoas trabalham, e o resultado deste trabalho ui baseado no que tenha sido denido no elemento regras de negócio. Embora outros softwares possibilitem criarmos denições que se assemelham a regras de negócio, nenhum tem o mesmo poder de um software de Workow ou BPMS. É este elemento que dá ao processo automatizado a característica única de ser controlado por uma Tecnologia da Informação. Regras de negócio possibilitam a execução correta das tarefas que, por qualquer motivo, sejam críticas num procedimento. É necessário analisar cada tarefa e descobrir os detalhes que possam fazer a criação de regras de negócio imprescindível para a correta execução da tarefa. São as regras de negócio que dizem quando fazer e como fazer uma tarefa. Existem regras de negócio extremamente simples, mas de grande importância, enquanto outras são, além de complexas, condições sine qua non para a execução de determinadas tarefas. Por exemplo, uma regra de negócio simples, mas importante: não desligar o projetor multimídia antes que o ventilado r tenha parado de funcionar. Isto diminui a vida útil da lâmpada do projetor, sempre muito cara. Uma regra de negócio como condiçãosine qua non para a execução de uma determinada tarefa no procedimento do “Contas a Receber”: títulos vencidos em D+1, cobrar multa de R$ 2,99 por atraso, mais juros de mora de R$ 0,04 por dia de atraso. Em ambas as tarefas a inexistência da regra de negócio colocaria em risco não somente a execução da tarefa como o resultado de tal operação e, às vezes, a própria organização em si.

Aplicações de BPM Este enunciado também é vago. O que seriam aplicações BPM? Ajulgar pelo que alguns especialistas já escreveram sobre isso, aplicações BPM seriam sistemas de informações construídos inteiramente com características BPMS, ou melhor, comcaracterísticas já existentes, no passado, no modelo Workow. Características que têm em comum a dinamicidade e a automaticidade no tratamento das ocorrências processadas por qualquer processo denegócio.

BPMS 133

Hoje já podemos construir sistemas baseados nas características 3Rs (os mesmos 3Rs srcinais do modelo Workow) sem que estejamos utilizando um software de Workow ouBPMS. Basta, por exemplo, que a organização tenha adquirido o núcleo de algum software (um motor) de Workow ou de BPMS (o que dá no mesmo) e construa sistemas embutindo-o no seu núcleo a m de dar a eles características de sistemas Workow, isto é: criando neles funcionalidades que processarão cada transação com o mesmo automatismo com que elas são tratadas em softwares BPMS (Workow). Entretanto, este tipo de utilização de motores Workow atenta contra um dos princípios fundamentais do modelo WfMC: o da independência do software Workow com relação a todas as outras aplicações e sistemas existentes na organização. Sei, por experiência própria, que quanto maior for a independência de um sistema Workow e BPMS com relação a qualquer outro sistema ou aplicação melhor, mais aderente e atualizada será a representação do ambiente de negócio automatizado. O mesmo princípio deve valer para o software BPMS, pois deduzo que os princípios do modelo Workow estejam contidos nele, uma vez que o software incorpora o motor de transações tão necessário à automatização dos processos. Muitas empresas “fabricantes” de softwares Workow e BPMS desenvolveram sistemas genéricos, como são os ERPs, tendo como núcleo o “motor” do seu software produto. Por quê e para quê? Porque estas empresas pensam que, oferecendo soluções prontas para serem usadas por qualquer empresa (sistemas genéricos), facilitam a aquisição e a implantação do Workow e do BPMS por parte daquelas organizações que não podem, não querem ou não têm como gastar dinheiro com a programação e a parametrização do software adquirido. Ao adotarem uma solução pronta, tais empresas se sujeitam a funcionar sob os princípios que nortearam a criação destes produtos. Mais ou menos como funciona a adoção de um software de ERP, que por ser genérico obriga às empresas a adotarem, em menor ou maior grau, o padrão que estes carregam. Desta forma, existem aplicaçõeseprontas para: vendas, administração de carteiraa de clientes, telemarketing contabilidade, entre outras. Cito, por exemplo, Xnear do Chile (www.xnear.cl), que no seu site vende vários sistemas prontos, mas não está sozinha neste tipo de abordagem mercadológica. As empresas donas de produtos Workow e BPMS pensam que se chegarem na frente do futuro cliente com algo pronto, para ser imediatamente usado pela organização, a venda de um destes softwares será mais fácil.

134 BPM & BPMS

Esquecem-se elas que, por mais semelhantes que sejam os processos de negócio existentes no mundo (de vendas, administração de carteira de clientes, telemarketing e contabilidade, contas a pagar, contas a receber etc.) cada organização tem suas particularidades e peculiaridades, características que são passadas para cada processo de negócio em particular, o que muitas vezes inviabiliza a adoção destes sistemas genéricos por causa da obrigatória adaptação da organização a eles e não, como deveria ser, a adaptação deles aos processos de negócio da organização.

Ferramentas para Monitoração de Processos Todos os softwares de Workow que conhecemos têm ferramentas para monitorização de processos. Estas ferramentas, entre outras, são: 

Ferramentas para redirecionamento de ocorrências.



Ferramentas para rearranjo de lista de atores.



Ferramentas para a mudança de destinatários.



Ferramentas para controle da carga de trabalho.

A importância de cada uma destas ferramentas está diretamente ligada ao nível de monitorização que podemos ter sobre cada processo de negócio automatizado pelo software de Workow e BPMS.

Ferramentas para Desenvolvimento de Software Ferramentas para desenvolvimento de sistemas, no nosso jargão, SDK (Software Development Kit), possibilitam a criação de sistemas com características especiais. Não devemos confundir com as aplicações de BPM, embora este conjunto de ferramentas também sirva para desenvolvê-los. Entretanto, o SDK vai além, pois permite que a organização tenha o domínio “quase” total sobre a engenharia do software que ela está adquirindo. Por isso estes módulos são caros e de utilização extremamente perigosa e sensível, pois uma vez tendo adquirido o poder sobre o “coração e o cérebro” do sistema a organização assume total responsabilidade por tudo que de bom e/ou de ruim venha a acontecer com o ambiente BPMS (Workow). Obviamente, ferramentas para desenvolvimento de software não são exclusividade dos sistemas de Workow ou dos sistemas BPM. Ao disponibilizarem seus Software Development Kits, os fabricantes de softwares estão na

BPMS 135

verdade “entregando”, para aqueles que compram seus produtos, o conhecimento com o qual os softwares foram desenvolvidos. Geralmente o Software Development Kit, conjunto para desenvolvimento de software, vendido pelos fabricantes de Workow ou BPMS, é compostos de dois componente: o módulo, ou programa objeto, que com capacidade ilimitada de processamento pode ser usado dentro de tantos quantos forem os construídos pela organização que olevam comprou e umdados conjunto de programas comandos que corretamente parametrizados e trazem de e para o “motor” do software embutido no programa. Também costumam conter especicações sobre todos os dataset records dos bancos de dados usados pelo motor do BPMS (Workow), imprescindíveis para a geração de relatórios e para o acesso correto a todo e qualquer tipo de dado existente do “coração” do software BPMS (Workow). É usual que o Software Development Kit custe muito caro e não seja de interesse dos fabricantes dos softwares vendê-lo separadamente, a não ser com muitas garantias e por um preço muito alto. Quando o fazem, exigem em contrato que o Software Development Kit seja usado somente em sistemas internos, isto é: da própria organização que o está adquirindo, pois para serem usados em sistemas que serão vendidos no mercado podem vir a concorrer com o próprio fabricante do Software Development Kit e por isso tais produtos custarão muito mais se forem vendidos.

Ferramentas EAI (Enterprise Application Integration) Este módulo é, seguramente, o que mais diferencia os softwares BPMS dos softwares Workow. Não que qualquer software de Workow não possa trabalhar em conjunto com ferramentas Enterprise Application Integration, mas porque os fabricantes de software Business Process Management System estão apregoando que embutiram em seus produtos todas as funcionalidades de integração dos sistemas EAI como forma de diferenciá-los dos “antigos” sistemas Workow.

136 BPM & BPMS

Figura 4.11 – Integração-Independente entre Workow e outros softwares com EAI.

Na verdade, o Enterprise Application Integration já existia antes do BPMS e vai continuar existindo desenvolvido por diversas empresas mundo afora. O EAI é classicado como sistema middleware52 e conhecido entre nós como “sistema da camada do meio”, o que signica dizer que o papel fundamental do Enterprise Application Integration é, e sempre será, o de integrar várias plataformas de software, vários tipos de sistemas, para que possamos criar os portais, entre outras possibilidades. Os fabricantes de softwares BPMS apregoam que a grande diferença entre eles e o já existente Workow é a integração, na suite BPMS, do EAI. Esta diferença pode ser explicada, de forma gráca, pelas guras 4.11 e 4.12. Na gura 4.11 o EAI está separado do Workow enquanto que na gura 4.12 os dois estão integrados numa única suíte. Mas seria somente esta a “grande” diferença existente entre Workow e BPMS? E como caria o princípio da Integração-Independente?

52. Middleware, personalização de software; software de sistema que foi personalizado por um vendedor para um usuário particular. Dicionário Multimidia Michaelis.

BPMS 137

Figura 4.12 – Software BPMS é composto de ferramentas de Workow e EAI.

Todo software de Workow deve poder se integrar a outros softwares por meio do conceito de integração-independente. Isto na prática signica que podemos fazer o Workow (e agora o BPMS) trabalhar em conjunto com qualquer software sem a necessidade de construirmos integrações difíceis e demoradas entre eles. Também signica dizer que quando o Workow se integra a outros softwares qualquer modicação realizada em qualquer software ou no Workow não deve afetar um ou outro. Creio que o mesmo princípio deveria valer para o BPMS (em cuja suíte há o módulo Workow), mas não é o que está parecendo pelo que apregoam seus fabricantes. Por exemplo, se umWorkow estiver embutido num ERP , ao modicarmos um o outro terá que obrigatoriamente ser modicado também. Mas se a integ ração for independente esta obrigatoriedade não existirá, pois reetirá no outro -so mente e quando a modicação disser respeito ao outro software. Este princípio, na prática, faz com que cada software tenha suas necessidades de atualização satisfeitas mais rapidamente. Workow embutidos emERPs são, em 99% dos casos, difíceis e custosos de ser programados. Claro, este princípio continua válido para softwares BPMS, embora isso não esteja explicitamente referen ciado ou assumido em nenhuma literatura per tinente ao assunto. A gura 4.13 mostra como Workow (ouBPMS) deve ser integrado a um ERP.

138 BPM & BPMS

Figura 4.13 – Integração-Independente Workow (BPMS) – ERP.

Pelo exposto, Workow embutido em outros softwares não consegue reetir a dinamicidade das organizações com a mesma rapidez com que esta dinamicidade provoca mudanças no ambiente de negócios. É sabido por todos nós, especialistas em TI, que toda programação além de lenta e cara tem uma carga enorme de incertezas causadas por elementos extremamente imponderáveis tais como mão de obra (programadores são prossionais muito sensíveis), escopo do sistema mal denido, descontrole do projeto, entre muito outros. Estes elementos dicultam, atrasam e complicam o desenvolvimento e a programação de sistemas de informações, o que signicaria colocar softwares como Workow e BPMS, que exigem alta dinamicidade, no mesmo nívelprocedurais de complexidade programática devez sistemas desenvolvidos com linguagens ou mesmo visuais, em de ferramentas parametrizáveis que Workow e BPMS devem ser. Dessa forma, produtos como ERPs que têm embutidos softwares de Workow não são uma boa solução, pois na maioria das vezes não admitem a “programação” do software principal sem que também se tenha que “programar” o Workow e vice-versa. Workow deve ser independente para, entre outras vantagens, poder ser usado com qualquer software.

BPMS 139

De uma vez por todas nós precisamos entender que quanto maior for o esforço de programação que um software BPMS (ou Workow) necessitar maiores serão os custos e o tempo para implantá-lo. Também é verdade que quanto maior tiver sido o esforço de programação, maior será o esforço de atualização do software BPMS (ou Workow). No passado o Enterprise Application Integration (EAI) era usado para integrar osem software de Workowoua não. todosVendido os softwares organização, eles emergentes comoexistentes o principalna componente defos um portal corporativo, o EAI era uma solução externa ao Workow. Se a organi zação que estava implantando o software não queria (ou não podia comprar) um software de EAI, a integração do Workow era feita por meio de Agentes (Agents) e APIs, Application Program Interface, do próprio fabricante do software de Workow ou por meio de Agentes e APIs como os encontrados nas linguagens SQL (Structured Query Language) dos bancos de dados ou, ainda, por meio dos Agentes e APIs do fabricante do software ao qual queríamos integrar o Workow, como, por exemplo, os do ERP R/3 da SAP53. Denições de EAI: EAIinformações (Enterprise Application o compartilhamento de de negócioIntegration) através daérede de aplicativos em uma ou mais aplicações de forma organizada. Antigamente os softwares eram especicados (ou desenhados) a trabalha rem de uma forma independente, não havia integração entre os sistemas. Fonte: www.datasul.com.br acessada em 27 de setembro de 2005. EAI é o compartilhamento irrestrito de dados e processos de negócio através de aplicações em rede ou fontes de dados em uma organização. Fonte: www.webopedia.com, acessada em 28 de fevereiro de 2006. EAI é um termo usado pela computação comercialconsolidar para planos, métodos e ferramentas dedicadas a modernizar,

53. SAP, Systeme, Anwendungen und Produkte in der Datenverarbeitung . Em in-

glês: Systems, Applications and Products in Data Processing, em português: Sistemas, Aplicativos e Produtos para Processamento de Dados.

140 BPM & BPMS

e coordenar as aplicações de computador em uma empresa. Fonte: www.whatis.com acessada em 28 de fevereiro de 2006.

Note que as denições dão ênfase aocaráter organizacional doEAI, isto é: falam de processos de negócio e da preocupação dosoftware em integrá-los. Basicamente existem quatro tipos de Enterprise Application Integration: 1. (de) Bancos de dados, que compartilham informações quando necessárias. 2. (de) Aplicações. A organização compartilha processos de negócio, dados e informações sempre que necessário. 3. (de) Data Warehouse. Os dados são extraídos de uma grande variedade de fontes e direcionados por meio de um extrator para um banco de dados especíco. 4. (de) Sistemas Web. O EAI organiza todos os programas em camadas, unicando-os e dando-lhes consistência. A despeito do que possa parecer, o surgimento do SOA não acabou com o mercado de softwares Enterprise Application Integration. O EAI, por ser solução proprietária, tem vantagens importantes sobre a tecnologia SOA, e uma delas, se não a mais importante de todas, diz respeito ao quesito segurança, pois o SOA é extremamente vulnerável em termos de segurança e exige investimentos maiores em dispositivos de proteção aoambiente informacional. Líderes mundiais em EAI são a Vitria Technology, a Evolutionary Technologies International (ETI), a IBM e a TIBCO, entre algumas outras.

Ferramentas SOA (Service-Oriented Architecture) O surgimento do SOA deu-se pela introdução das tecnologias Web nas organizações. Em outras palavras, tecnologias que antes eram usadas apenas na Internet passaram a serasusadas em sistemas de informações e em outras aplicações internas das organizações. KEEN et al (2004) dene SOA como: Estruturas-modelo para desenvolvimento de aplicações Web, particularmente voltadas ao e-business.

BPMS 141

A minha denição de SOA: Ferramentas, baseadas em padrões abertos (não proprietários), que permitem integrar, de forma rápida e dinâmica, softwares, sistemas e aplicações rodando em plataformas iguais e/ou diferentes, e estes aos processos de negócio da organização. A principal do SOA faz suasua utilização ser extremamente vantajosa, mas écaracterística também, paradoxalmente, maior desvantagem. SOA é uma solução aberta, isto é, não existem códigos proprietários, como nos softwares EAI, para programar e utilizar soluções em SOA. Entretanto, várias empresas vendem soluções SOA, que vão do desenvolvimento da estrutura SOA à implantação dosWeb Services desenvolvidos e à administração do ambiente integrado. Aliás, se qualquer organização decidir comprar uma solução SOA “proprietária” estará, além de fazendo um péssimo negócio, ignorando os princípios que zeram da tecnologia SOA o atual paradigma em integração-independente de aplicações. SOA surgiu em função das necessidades existentes de integração entre diferentes plataformas de hardware e software, demonstradas na gura 4.14. Estas necessidades e consequentes diculdades começaram quando da introdução da computação distribuída, pois embora os mainframes de fabricantes diferentes não conversassem entre si (IBM-HoneywellBullUNIVAC-Burroughs) pelo menos conversavam em família, coisa, aliás, difícil até mesmo com membros de uma mesma família quando do surgimento da computação distribuída, no caso de máquinas client-server (tanto IBM quanto HP).

142 BPM & BPMS

Figura 4.14 – As diculdades de integração de diferentes plataformas para compartilhamento de dados e procedimentos.

Para contornar as diculdades oriundas da inexistência de plataformas “poliglotas” fabricantes de todos os segmentos de tecnologias da informação desenvolveram as famosas interfaces. As interfaces foram durante muito tempo as únicas possibilidades existentes para permitir o diálogo entre sistemas de diferentes plataformas, mas como eram soluções proprietárias, além de caras – na programação e na operação – não eram exíveis – na programação e na operação – como as necessidades das organizações passaram a ser a cada dia. No ano 2000 o World Wide Web Consortium, W3C, padronizou web services emergentes e o resultado foi o estabelecimento de um conjunto de especicações para serem usadas pelo XML, eXtended Markup Language, e por protocolos de comunicação visando a interoperabilidade universal entre computadores de diferentes plataformas. A própria XML foi adaptada pelo W3C a partir da linguagem Standard Generalized Markup Language, padronizada pelo ISO.

BPMS 143

O que é XML? Segundo o W3C: XML é um conjunto de padrões de linguagem que especicam como estruturar um documento baseado em texto (text-

based) para comunicação entre dois computadores, para qualquer propósito.

Figura 4.15 – A computação distribuída e o surgimento das interfaces para integração de diferentes plataformas.

Uma mensagem SOAP é formatada exatamente como se fosse um envelope com código XML, denindo o início e o m da mensagem. O header da mensagem dene de onde ela está vindo (srcem) e para onde ela está se dirigindo (destino) e especica, também, como ela alcançará seu destino path).a O (para corpo deda uma mensagem contém os dados ou forma, as instruções execução solicitação doSOAP “envelope” SOAP. Desta o SOA, utilizando o Simple Object Access Protocol, pode ser executado em qualquer sistema ou para qualquer sistema, em qualquer plataforma existente hoje, com total transparência e entendimento tanto por parte do emissor como por parte do receptor da mensagem.

144 BPM & BPMS

Figura 4.16 – Integração-independente com padrão XML – SOA.

Formato genérico da mensagem SOAP.
destino caminho o conteúdo da mensagem o que faz o conteúdo da mensagem o que solicita o conteúdo da mensagem Entre vários outros benefícios, a adoção de SOA propicia às organizações:  



Identicação da interação entre usuários, negócios e dados. Criação em camadas, possibilitando a integração de múltiplos sistemas sempre que a solução não puder ser desenvolvida num único modelo. Composição de padrões que representam as combinações de múltiplos sistemas diferentes.

BPMS 145 

Modelagem, da solução, que provê um layout conceitual, descrevendo como os componentes de aplicações e dados interagem com os negócios.

As Fundações do SOA 

Web Service (WS). Agente programado para interagir com, e in-

tegrar, sistemas construídos em uma mesma linguagem, ou não, executados num mesmo ambiente ou em ambientes diferentes. 

Simple Object Access Protocol (SOAP). Conjunto de instru-

ções para construção dos documentos texto (mensagens). 

Universal Description Discovery and Integration (UDDI). Do-

cumento que descreve, com exatidão, o QUÊ um serviço Web faz e COMO ele deverá ser “chamado” (ativado) por um documento texto (mensagem). 

Web Services Description Language(WSDL). Diretório de todos

os serviços Web disponíveis para uso dentro de uma organização.

Figura 4.17 – Ambiente BPMS, ferramentas Workow, funcionalidadesService-Oriented Architecture e integração-independente com todos os outros softwares e sistemas.

146 BPM & BPMS

Cuidados com a Adoção do SOA Existem elementos extremamente sensíveis que devem ser considerados e cuidadosamente analisados e projetados para que um ambiente ServiceOriented Architecture possa ser utilizado corretamente. 

Segurança. Sendo um ambiente “aberto”, SOA necessita de investimentos signicativos para prover e manter a segurança dos sistemas integrados por ele. Em princípio, qualquer um (incluindo aqui hackers e crackers) que venha a ter acesso ao WSDL, e consequentemente ao UDDI, pode executar um serviço Web com qualquer propósito (legal ou criminoso).



Lentidão. Também por serem baseados em padrão aberto, os serviços SOA serão mais lentos que serviços proprietários. Esta pode ser uma situação particularmente perigosa para organizações que necessitam de rapidez nos serviços disponibilizados nos seus sites.



Desorganização informacional. A DoI pode se tornar muito grave por ser um dos males advindos do uso desorganizado e sem controle do SOA, devido à proliferação dos serviços Web criados numa organização. Com a adoção do padrão XML as organizações tenderão a desenvolver mais e mais serviços SOA e a experiência nos mostra que a perda de controle sobre o conteúdo dos repositórios existentes nas áreas de informática é algo que já acontece com datasets em bancos de dados, pedaços de códigos que deveriam ser reutilizados, entre outros elementos de TI.



Análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio. Como integradora dos ambientes onde são executados processos em primeiro e segundo planos (foreground & background processes) a arquitetura orientada a serviços (SOA) obrigatoriamente deve reetir os processos de negócio da organização. Devem ser aderentes ao negócio! Caso contrário, corremos o risco de, no mínimo, continuarmos a ter sistemas não aderentes à organização – como o são muitas das aplicações hoje existentes em grande parte das organizações.

BPMS 147

Background & Foreground Processes54 Para entendermos melhor tanto EAI como SOA vou falar sobre a topologia de operação ou execução dos processos de negócio. Nos primeiros capítulos deste livro mostrei como as ondas de Tecnologias da Informação se sucederam na nossa sociedade e como provocaram nas organizações o que chamei de Desorganização Informacional (DoI). Na medida em que mais e mais tecnologias apareceram (e aparecem), mais e mais a Desorganização Informacional exacerba-se, realimentando-se e alimentando um círculo vicioso que faz com que as organizações comprem-tecnologiaspara-resolverem-problemas-causados-pelas-compras-de-tecnologias. A eterna “maldição” (parece coisa de deuses e semideuses gregos) de termos que resolver problemas causados pelas tecnologias que foram compradas para resolver problemas. O ambiente de processamento de informações encontrado hoje, praticamente sem exceções, em todas as organizações levou os especialistas em TI a pensarem em meios de organizar este caos tecnológico, daí terem surgido diversas ideias, conceitos, metodologias ferramentas ao tratamento da Desorganização Informacional dae qual padecemvoltadas organizações em todos os países. Diferentemente das máquinas que monoprocessavam os sistemas de informações, as máquinas multiprocessamento introduziram uma nova necessidade, um novo componente, no ambiente computacional das organizações: a integração sistêmica; ou dos sistemas que passaram a ser executados concomitantemente. Antes do advento dos bancos de dados estruturais esta integração era feita por meio da execução de dezenas de pequenas rotinas55 processadas depois que os grandes sistemas terminavam. Somente quem viveu aqueles tempos sabe o caos que o não processamento de uma destas rotinas provocava nas organizações: dados desalinhados, arquivos incon-

54. Já escrevi sobre Background & Foreground Processes no meu livro O Teatro Organizacional, mas considero o tema extremante importante, além de necessário neste livro para contextualizar Enterprise Application Integration. 55. Estas rotinas eram chamadas por nós de bacalhaus (não me pergunte por quê). Penso que seja porque elas não tinham “nem pé nem cabeça”, assim como o bacalhau que a gente compra no mercado.

148 BPM & BPMS

sistentes, informações desatualizadas, sistemas “abortados”. Um verdadeiro caos informacional, a ponto de, muitas vezes, todo o ambiente car “fora do ar”, durante boa parte do dia, até que tais rotinas fossem enm processadas e, consequentemente, os dados fossem consistentemente atualizados. Claro, esta situação não poderia continuar. Depois do advento dos bancos de dados estruturais, e muito tempo depois, quando os bancos de dados relacionais foram introduzidos, a situação parecia ter chegado um ponto razoavelmente seguro de convivência entre sistemas; anal osabancos de dados tinham a precípua responsabilidade de integrá-los. Mas foi aí que surgiram os microcomputadores, os minicomputadores, as máquinas chamadas de superminis (plataforma baixa); e o processamento descentralizado de sistemas e utilitários, voltando a exacerbar a desintegração sistêmica nas organizações. Com o advento de novas tecnologias da informação e de novas metodologias e tecnologias orientadas a processos dois termos em inglês têm sido usados com frequência em conversas entre especialistas, em cursos, palestras e seminários: foreground & background processes. É bom entendermos corretamente o signicado deles com respeito a processos e às tecnologias que os apoiam. A gura 4.18 representa a topologia dos processos, com as pessoas interagindo com os processos executados em primeiro plano e com as Tecnologias da Informação executando processos em segundo plano.

Figura 4.18 – Topologia dos processos.

BPMS 149

Foreground Processes Em português, processos em primeiro plano. O termo foreground refere-se a processos que são executados na camada externa do ambiente operacional ao qual estão ligados, ou seja, são processos executados na parte mais visível das estruturas que dão forma às organizações. Embora não sejam processos que interajam exclusivamente com pessoas, eles são, na maioria das vezes, processos com interação máquina-homem intensiva, o que requer dos analistas de processos cuidados especiais quanto ao que chamamos de ergonomia, a m de que as pessoas sintam-se confortáveis ao trabalharem e não venham a sofrer de doenças genericamente chamadas “do trabalho” como a síndrome LER (Lesão por Esforço Repetitivo). Todo processo que requeira, por exemplo, que o ser humano abra um formulário eletrônico, se relacione com tecnologias da informação, com máquinas, equipamentos, dispositivos e instrumentos de forma direta é um processo que está sendo, ou será, executado em primeiro plano. São tecnologias nesta categoria: programas de computador, softwares diversos, microcomputadores, máquinas industriais etc. Para processos cuja operacionalidade está diretamente ligada à ação do ser humano existem dois tipos de tecnologias: elas podem desde suportar supercialmente os processos ou, no extremo oposto, automatizá-los completamente. Para fazer isso dispõem de funcionalidades que nos permitem realizar as tarefas sob nossa responsabilidade. Estas tecnologias são o BPMS e o seu módulo Workow. 

Tecnologia da informação. São sistemas especialistas ou de propósitos gerais que realizam operações básicas nas organizações. Exemplos: os sistemas de gerenciamento de recursos empresariais (Enterprise Resource Planning), uma parte dos sistemas de gerenciamento do relacionamento com clientes (Customer Relationship Management), Workow, gerenciamento de conhecimento (KM) entre outros. Todos estes sistemas são direta e intensivamente usados pelos seres humanos, mas é bom ressaltar que os mesmos sistemas podem ter módulos com funcionalidades que não são acessadas pelas pessoas e desta forma parte deles “rodariam” em background (em segundo plano).

150 BPM & BPMS 

Tecnologia de processo. São hoje, também, tecnologias da informação, pois máquinas, equipamentos, dispositivos e instrumentos que processam e transformam entradas em saídas nos processos de indústrias de manufatura, e até mesmo em alguns processos de serviços, são, em grande número, tecnologias com processadores embutidos56. É com este tipo de tecnologia de processo que as pessoas interagem, de forma direta ou indireta, ao representarem papéis funcionais. Algumas destas tecnologias podem ter camadas que rodam em foreground processes e outras camadas que rodam em background processes.

A diferença fundamental entre os dois tipos de tecnologias citados e suas homônimas existentes nos processos em segundo plano é o grau de interação delas com os seres humanos, pois, via de regra, enquanto nos processos em primeiro plano tanto as tecnologias da informação quanto as de processos são diretamente usadas pelos funcionários, as dos processos em segundo plano são indiretamente usadas pelos seres humanos através de tecnologias ligadas a processos em primeiro plano e na maioria das vezes estas tecnologias nem sequer são visíveis a nós. A gura 4.18 mostra as camadas dentro daplano organização onde executados processos em primeiro e em segundo suportados porsão tecnologias da informação. Entre a camada que tem interação direta com os funcionários (primeiro plano) e a camada que corre sem contato com os funcionários (segundo plano) existem duas novas classes de tecnologia, a EAI, Enterprise Application Integration, e a SOA, Service-Oriented Architecture, que

56. Tecnologia da informação está, literalmente, presente em tudo. Cientistas do Fraunhofer Institute, na Alemanha, desenvolveram um sistema de localização que promete facilitar imensamente a tarefa dos árbitros de futebol. Com um chip implantado na caneleira de cada jogador, além de outro dentro da bola de futebol, será possível saber a posição exata de cada elemento em uma partida, além acabar com as dúvidas de impedimento e gols discutíveis. Segundo a tecnologia a leitura da posiçãoem davolta bolado atégramado duas milevezes por segundo. oOsInstituto, dados são coletadospermite por antenas posicionadas enviados para um computador central, que processa toda a informação estatística. O primeiro teste com a bola de futebol equipada com chips foi realizado pela alemã Adidas, no dia 26 de fevereiro de 2006. Outros esportes, de acordo com os cientistas do Fraunhofer, também serão beneciados pelos chips. Há uso da tecnologia para o vôlei, basquete, beisebol, handebol e até mesmo skysurf. Fora dos esportes, a polícia demonstrou interesse na tecnologia, que pode ajudar muito na busca de desaparecidos, vigilância em prisões e também na segurança de edifícios.

BPMS 151

são conjuntos de ferramentas que possibilitam à organização integrar as dimensões foreground & background por meio da integração de todas as aplicações, softwares, módulos e ferramentas lógicas das duas dimensões num único ambiente: os processos de negócio. A integração das aplicações da organização pode ser feita por meio de softwares chamados EAI Suíte e SOA, vendidos por dezenas de fabricantes de softwares ou desenvolvida “in house ”. Entretanto, o mais importante é decidir de qual fabricante comprar este ou aquele software, mas comonão os processos em foreground & background serão desenhados, integrados e operacionalizados.

Background Processes Em português, processos em segundo plano. O termo background refere-se aos processos que são executados na camada interna do ambiente organizacional ou, mais precisamente, na camada cujo contato com o ser humano é ou indireto ou inexistente. Nesta camada, também conhecida como infraestrutura, as tecnologias podem desde suportar supercialmente os processos até automatizá-los completamente. Toda e qualquer infraestrutura tecnológica necessita ter processos que as façam existir dentro de padrões, muitas vezes, extremamente rígidos. Consequentemente, para automatizá-los e mantê-los operacionais existem dois tipos de tecnologias: 

da informação. São sistemas especialistas ou de propósitos gerais que realizam operações de base nas organizações. Exemplos: os sistemas de gerenciamento de recursos empresariais (Enterprise Resource Planning), uma parte dos sistemas de gerenciamento do relacionamento com clientes (Customer Relationship Management), assim como os sistemas de gerenciamento da cadeia de suprimentos ( Supply-Chain Management), resposta eciente ao consumo (Efcient Consumer Response) e Data Warehouse (DW).



de processo. São máquinas, equipamentos, dispositivos e instrumentos que processam e transformam entradas em saídas nos processos de indústrias de manufatura e de serviços. Por exemplo, nas fábricas de papel, a máquina que transforma pasta

152 BPM & BPMS

em papel chama-se máquina de papel. Na saída dela, depois que o papel é formado pela tela formadora e seco pelas calandras, existe um sensor longitudinal que varre permanentemente o resultado do processo de transformação para medir a gramatura, a densidade e a umidade do papel que acabou de ser fabricado. Este sensor é uma das tecnologias de um processo que roda em segundo plano, mas os sinais que ele coleta e envia a um computador de controle permite que outras tecnologias da informação acionem controladores lógicos programáveis, que regulam a passagem de mais ou menos pasta para manter a gramatura, a densidade e a umidade constantes no papel que está sendo produzido. Além disto, os dados coletados pelo sensor são enviados a computadores de controle de processos que são supervisionados por operadores que podem atuar, sempre que se zer necessária a intervenção humana, para controlar a qualidade do produto. Estes últimos, os CLPs (Controladores Lógicos Programáveis) e SDCDs (Sistemas Digitais de Controle Distribuído), também são tecnologias da informação para processos que rodam em background, embora interajam com seres 57

humanos. Por exemplo, os PDVs são tecnologias processos em primeiro plano, mas toda a infraestrutura que osde interconecta aos computadores centrais são tecnologias de processos de segundo plano. Para que os conceitos de foreground e background quem claros dou outro exemplo: a nossa casa. Os processos executados em primeiro plano, quanto à energia elétrica, teriam como interface com os seres humanos: os interruptores, as lâmpadas, as tomadas, os lustres; os processos executados em segundo plano: as caixas de passagem embutidas nas paredes, os os e cabos elétricos que passam dentro dos tubos de PVC. Processos em primeiro plano, do ambiente hidráulico, teriam como interface com os seres humanos: as torneiras, os registros, os ralos; os processos executados em segundo plano são: os canos de PVC. Tanto no exemplo da energia elétrica como no da água, o

57. PDVs é a sigla com a qual caram conhecidos os terminais Ponto De Vendas hoje exis tentes até nas menores mercearias de bairro de qualquer cidade.

BPMS 153

ambiente no qual são executados processos em primeiro e segundo planos são nossas casas e os prédios residenciais ou comerciais. Os processos foreground e background são compostos de atividades e estas, por sua vez, são compostas de eventos 58. A rigor, o que muda é que nos processos que são executados em primeiro plano as atividades são executadas pelos seres humanos; enquanto que nos processos que são executados segundoeletromecânicos plano as atividades são executadas por softwares, dispositivos em mecânicos, e eletrônicos. Tanto o EIA quanto o SOA são, de certa forma, a evolução das sub-rotinas que serviam para integrar os sistemas existentes nos mainframes nas décadas de 70 e 80. Hoje, estas rotinas evoluíram e de forma mais avançada interligam não somente sistemas de informações como processos executados em primeiro e segundo planos.

Ferramentas para Gerenciamento do Ambiente Workflow Neste conjunto estão asProcess ferramentas adstritasSystem à função do monitoração administradore Management do Workow (Business ) para administração deste ambiente. Geralmente são utilitários do próprio fabricante do software que possibilitam que o administrador do ambiente Workow (BPMS) gerencie bancos de dados; abra e feche processos, redirecione las e destinatários, administre telecomunicações e controle vários tipos de eventos, como deadlocks (travamento de diversos tipos de elementos). O administrador do ambiente de Workow pode tudo, enquanto usuários como gerentes, supervisores etc. têm poderes apenas sobre os processos pelos quais eles são responsáveis, isto quando têm estes poderes. Embora não exista uma denição clara do que venham a ser ferramentas de Workow, resumiro motor como do sendo ferramentas cérebro de umpodemos sistema BPMS: módulo Workow!que controlam o

58. Sobre eventos, base da metodologia DOMP, leia o capítulo especíco nO Teatro Organizacional.

154 BPM & BPMS

Servidores de Aplicações Os servidores de aplicações BPMS são repositórios dos sistemas construídos com observância dos princípios que embasam o software Workow, tenham sido estes comprados de terceiros ou “construídos em casa”. Um servidor de aplicações pode ser integrado ao ambiente BPMS tanto Processpor meio dos motores stentes módulo Workow do Business Management System exi quanto porno meio do uso que zermos de integrado res como o EAI e o SOA. Entretanto, a utilização destas novas tecnologias não invalida a adoção, sempre que necessária, de Agentes e APIs, próprios ou genéricos.

Linguagens BPMS Linguagens BPMS são conjuntos de instruções que possibilitam a programação de funcionalidades Workow, tais como regras de negócio, papéis funcionais, uxos e seus direcionamentos, dentro de uma estrutura (framework) de software BPMS. Para melhor explicá-las eu divido as linguagens BPMS em dois grupos, usando fatores inerentes a cada uma delas para poder categorizá-las como tal.

1º Grupo. Linguagens generalistas Neste grupo estão linguagens caracterizadas por fatores como: nalidades estruturais, essência open software (código aberto) e larga abrangência. Neste grupo estão as principais linguagens do BPMS: Business Process Modeling Notation (BPMN) e Business Process Execution Language (BPML), entre outras. O Anexo IV traz mais informações sobre linguagens generalistas.

2º Grupo. Linguagens especialistas Neste grupo estão linguagens caracterizadas por fatores como: propriedade, alta especicidade e particularidade (estreita abrangência). São em geral linguagens desenvolvidas por fabricantes, muitas das quais derivadas de outras linguagens.

BPMS 155

ERP, CRM e Outros Softwares e Aplicações Óbvio que nem Enterprise Resource Planning, nem Customer Relationship Management ou softwares como Efcient Consumer Response, SupplyChain Management ou outro qualquer faz parte, ou deveria fazer, de um software BPMS. Estes softwares estão listados aqui não como parte da Suíte BPMS, mas como produtos que terão suas funcionalidades potencializadas quando integrados a um software BPMS.

Data Warehouse e BI Data Warehouse, DW, e Business Intelligence, BI, são dois softwares que também não fazem nem deveriam fazer parte de uma Suíte BPMS, mas corretamente integrados ao BPMS beneciam-se desta integração por terem automatizadas suas rotinas de estraticação e extração de dados, DW, e suas rotinas de geração de relatórios gerenciais, BI.

Conclusão Pelo exposto, por tudo que eu escrevi neste capítulo, é possível perceber que suítes Business Process Management System são complexas, caras e de implantação demorada e com alto grau de incertezas, talvez muito maiores que as que nós conhecíamos do bom e velho Workow. Mas há uma saída, e não estou falando de não usarmos o BPMS, mas sim de implantá-lo por partes, tanto quanto à utilização dos seus módulos e funcionalidades quanto ao número de processos implantados.

5 AMOP é uma Saída? 59

Para podermos considerar a análise, o desenho, o redesenho e a modelagem de processos de negócio (AMOP) como uma das terapias possíveis para tratamento da Desorganização Informacional (DoI) é necessário que antes saibamos exatamente de onde a organização pretende sair, uma vez que a confusão na qual afundamos, junto com as organizaçõesquer ondechegar. trabalhamos, tem diversas representações, e aonde a organização É necessário sabermos antes qual é o problema que queremos resolver para podermos escolher a solução mais adequada para tratá-lo. Caso contrário “qualquer” saída poderá levar a organização a entrar numa situação pior do que aquela da qual ela queria sair, na qual ela se encontrava antes e tentava resolver. Se considerarmos a quase total falta de organização existente hoje na grande maioria das instituições de todos os tipos e segmentos econômicos, esta é uma tarefa das mais difíceis. Talvez não seja tanto desesperadora nas manufaturas, discreta e de transformação, mas na área de serviços não há sequer o que chamamos de projeto do produto a ser produzido, salvo as exceções compostas pelas empresas dos ramos nanceiros e de seguros. Em outras palavras, na sua grande maioria, as empresas de serviços produzem seus produtos sem antes projetá-los. Isto é algo que não poderia jamais acontecer.

59. AMOP é uma sigla criada por mim entre 2000 e 2001 para divulgar os cursos de análise & modelagem de processos de negócio desenvolvidos e ministrados por meio da minha empresa.

AMOP é uma Saída? 157

Quando uma organização compra uma determinada tecnologia, quer seja porque o vendedor garantiu que esta poderá resolver seus problemas, quer seja porque os meios de comunicação, especializados ou não, apregoam que tal tecnologia está sendo usada por empresas de “sucesso”, ou ainda quando uma organização acredita em tudo que osinstitutos de pesquisas (majoritariamente americanos) dizem, ela está na verdade comprando mais problemas, entrando em novas situações de risco – sem falar no desperdício de recursos (recursos = tempo, dinheiro, mão de obra, paciência, talentos, competências etc.) que serão jogados na lata de lixo quando mais um projeto fracassar. Exemplos de projetos fracassados na implantação de Customer Relationship Management, Executive Information Systems, Workow, Data Warehouse e, até mesmo, de Enterprise Resource Planning (ERPs) existem às dezenas. Especicamente com Workow, o grande causador de fracassos é que as pessoas não se contentam em reconhecer que a tecnologia foi criada para automatizar processos e sempre esperam muito mais do que a tecnologia pode fazer, levadas talvez pelas promessas de quem a vende. A impressão que tenho é que as pessoas esperam que o software faça coisas mirabolantes, muito além do essencial: controlar e automatizar Regras de Negócio, Papéis Funcionais e Rotas (3Rs). “Só” isso! Análise, desenho, redesenho, modelagem, organização de processos de negócio, podem ser uma solução para a Desorganização Informacional? Talvez possam ser. E o advérbio “talvez” é usado aqui por uma questão de princípio, isto é, AMOP60 só terá sucesso se a principal abordagem dada ao projeto for a de fazer a organização conhecer a si mesma por meio dos seus processos. Qualquer outra abordagem levará o projeto ao fracasso. Por exemplo, se a análise, o desenho, o redesenho, a modelagem, a organização de processos de negócio for exclusivamente para garantir um selo de reconhecimento esqueça. Se a organização estiver mais interessadade emqualquer obter asorganismo, certicações ISO, qualquer que seja, não somente as causas da DoI não estarão sendo conhecidas, discutidas e resol-

60. AMOP, análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio.

158 BPM & BPMS

vidas como o resultado nal do projeto, processos de negócio formalmente conhecidos, não será alcançado.

O Caso da Empresa de Manutenção Aeronáutica Recentemente tive uma experiência que mais uma vez veio corroborar minhas colocações e preocupações com o uso que fazemos das normas de programas da qualidade. Uma empresa do setor de manutenção aeronáutica me chamou para um projeto de análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio porque necessitava de uma certicação especíca na área da qualidade aeronáutica. Um dos sócios me contou o seguinte. Tudo na indústria aeronáutica é extremamente normatizado, bens e serviços são feitos sob especicações extremamente rígidas. Na indústria aeronáutica não há espaço sequer para meio-erro. Há uma grande profusão de normas, políticas, instruções técnicas e manuais para tudo que se fabrica e, posteriormente, para tudo que sofre manutenções. Os limites probabilísticos para falhas, erros e defeitos em bens e serviços aeronáuticos são estreitíssimos. A preocupação com a segurança e com o “erro zero” é tanta que existem dezenas de órgãos que emitem instruções para tudo que se precisa fazer neste tipo de indústria. Até dos manuais dos próprios fabricantes. Pois bem, esta empresa em particular tem dez anos de existência, é muito bem conceituada no meio em que atua, pois reconhecidamente presta serviços de engenharia e manutenção com alto nível técnico e de qualidade. Por isso os donos contrataram uma certicadora para que a empresa pudesse obter a certicação na NBR 15100. O que é a norma NBR 15100? Sistema da qualidade – Aeroespacial – Modelo para garantia da qualidade em projeto, desenvolvimento, produção, instalação e serviços associados.

Os auditores da certicadora contratada passaram dois dias analisando todos os documentos da qualidade que a empresa possuía. O gerente da qualidade acompanhou os auditores externos durante dois dias e ao nal estes auditores emitiram o relatório com vários itens que necessitavam ser


trabalhados e corrigidos. Entretanto, o que de mais importante cou da auditoria foi o que os auditores disseram a viva voz: – A empresa não pode ser certicada, embora siga todas as normas técnicas e todas as políticas de todos os organismos que de alguma forma regulam esta indústria. Embora, também, a empresa seja reconhecidamente prestadora de serviços de engenharia de manutenção aeronáutica com excelente padrão de qualidade. O sócio então perguntou: por que não podemos ser certicados? – Porque vocês não têm os processos formalmente documentados, como exige a NBR 15100. O que vocês têm é uma coleção de normas e políticas, mas sem que elas estejam dentro de uma ordem lógica e cronológica, ou seja, elas não fazem parte de processos de negócio. E os processos não estão formalmente denidos, documentados, organizados, racionalizados e convenientemente gerenciados. Como aliás descreve a NBR 15100 nos itens 0.01 e 0.02. Foi deste ponto em diante que a empresa me chamou e decidiu fazer a análise, o desenho, o redesenho e a modelagem de todos os seus processos. A partir daí ela pode novamente solicitar uma pré-auditoria visando à certicação na NBR 15100. Lições? Várias! A começar pela mais óbvia delas: nenhuma norma “diz” como fazer alguma coisa. Todas dizem “o que” precisa ser feito. A partir daí cada um deve se “virar” como puder para “fazer o que a norma pede que seja feito.” Ou seja, a norma, qualquer que seja ela, dene cuidadosamente pontos que devem ser atingidos, mas não se preocupa em dizer como percorrer o longo caminho até atingir os objetivos preconizados por ela. Então, querer usar uma norma, seja ela qual for, para obter uma certicação é uma ideia ao mesmo tempo irresponsável e tola. Infelizmente, exemplos como o desta empresa que relatei são raros! Os sócios estão realmente interessados em organizar os processos de negócio da empresa para melhor gerenciá-la e somente depois obterem a certicação na NBR 15100.

160 BPM & BPMS

Níveis de Documentação de Processos Existem vários níveis de análise, desenho, redesenho e modelagem de processos de negócio, cada um focado num determinado produto nal. Cada tipo subdivide-se em outros tipos, como subconjuntos de uma mesma metodologia e ferramenta, adequadas a cada objetivo. Resumidamente, os níveis de AMOP são o básico, o intermediário e o avançado.  Nível Básico. Realizada neste nível, a análise, o desenho, o redesenho e a modelagem de processos de negócio servem para: 







fazer a organização conhecer a si mesma por meio dos seus processos e negócio; desenvolver Sistemas de Informações com aderência aos processos, e não às particularidades (e às idiossincrasias) das pessoas que executam as atividades existentes em cada processo; implantar o custeio baseado em atividades, visando controlar estrategicamente os custos de operação;



implantar a gerência de e por processos;



implantar políticas de melhoria contínua da qualidade.

Nível Intermediário. Quando a análise, o desenho, o redesenho, a modelagem e a organização dos processos de negócio, AMOP, desce a este nível de detalhamento podemos obter dados e informações para atender a diversas normas da qualidade; como as normas ISO, a CMM-I, a COBIT e a ITIL entre outras. A certicação em CMM-I é um excelente exemplo de como o nível intermediário de documentação de processos leva-nos ao detalhamento destes de forma particularmente precisa a m de atendermos às especicações da norma. CMM-I tem cinco níveis de certicação, como mostra a tabela 5.1, o que obriga a empresa certicada a mantê-la e evoluir na melhoria dos processos a m de conseguir certicar-se nos outros níveis.


N í vei s

Características

Foconamelhoria •

O processo é administrado por meio de crises (caótico e ad hoc ).

Inicial

• • • • •

• •

O processo ainda é dependente dos indivíduos (intuitivo).

Repetível

• • • • •

Processo denido e institucionalizado (melhoria do processo por meio de avaliações qualitativas).

Denido

Gerenciado

Processo medido (melhoria do processo por meio de avaliações quantitativas).

• • •

• • •

•

Otimização

Melhoria contínua

•

Planejamento do projeto. Rastreamento do projeto. Gerenciamento dos subcontratados. Garantia da qualidade. Gerenciamento da conguração. Gerenciamento das solicitações. Foco na organização do processo. Denição da organização do processo. Revisões aos pares. Programas de treinamento. Coordenação intergrupos. Engenharia de software. Gerenciamento da integração de software. Medição do processo. Análise do processo. Planos da qualidade quantitativa. Prevenção de defeitos. Inovação tecnológica. Gerenciamento das mudanças sofridas pelo processo. Ainda um processo intensivamente humano. Mantém a organização num nível de permanente otimização.

Tabela 5.1 – Níveis de certicação CMM-I. 

Nível Avançado. Se tivermos que implantar determinadas tecnologias da informação como as emergentes, teremos que descer a detalhes que são particulares a cada uma delas. Por exemplo, se vamos implantar GED, será imperioso detalharmos as tabelas de temporalidade, a estrutura de índices com os quais os documentos serão arquivados e recuperados e os direitos de acesso aos

162 BPM & BPMS

documentos, aliás, os três pilares fundamentais do GED – coisas que não fazem qualquer sentido paraWorkow puro. Se, por outro lado, o objetivo é implantar Enterprise Content Management, vamos necessitar especicar as pessoas e os tempos de verbos como identicar, capturar, integrar, guardar, recuperar e compartilhar dados, informações e conhecimento, a m de automatizá-los por meio do software que tivermos escolhido. Se o objetivo for implantar Workow será necessário documentar e analisar, mesmo que minimamente, regras de negócio, tempos, custos e papéis funcionais, os três pilares do Workow:Roles, Rules, Routes. Pelo exposto, mesmo sem maiores detalhes, qualquer estudioso do assunto pode concluir que a análise, o desenho, o redesenho e a modelagem de processos de negócio não podem ser realizados de forma genérica (como o tamanho das roupas fabricadas na China: one size ts all). Cada metodologia e os seus subconjuntos devem ter elementos que auxiliem os analistas de processos a encontrar, documentar, analisar e organizar de forma particular cada elemento existente em cada tipo de processo e aderente à natureza de cada um deles61. Aliás, vale aqui uma importante ressalva: os subconjuntos das metodologias existem para que possamos cobrir a ampla gama de elementos existentes em qualquer processo. Todo processo é essencialmente igual, ou seja, todo processo contém os mesmos elementos básicos, independentemente do que cada um deles produza. A partir deste conjunto básico de elementos cada processo diferencia-se pelo produto nal que deva produzir. O resultando da análise de cada um é que será particularizado pela metodologia. Por exemplo, um mesmo processo quando analisado com vistas à implantação de GED terá como resultado do trabalho a documentação das tabelas de temporalidade, a estrutura de índices de arquivamento e recuperação e os direitos de acesso aos documentos pois são elementos pertinentes a esta tecnologia que, por outro lado, não serão objeto de estudo caso o objetivo seja implantar Workow.

61. Para uma descrição completa e detalhada sobre tipos de processos e suas naturezas leia O Teatro Organizacional – Construindo e Implantando Processos de Negócio. Editora E-papers.


Outro ponto de atenção, quando uma organização escolhe implantar um programa da qualidade, é o de saber dosar o quanto de indução e de dedução este mesmo programa exigirá dos seus participantes. Para que esta colocação possa ser mais bem entendida vou conceituar o signicado destes dois substantivos. Os dicionários denem dedução62 como ato ou efeito de deduzir, signicando “inferência lógica de um raciocínio”, isto é, chegar a uma conclusão, “concluir que.” Já o substantivo feminino indução, embora pareça ter o mesmo signicado, revela um “caráter autoritário” no processo de aprendizagem (sem ajuizar como boa ou má tal característica). Os dicionários têm uma derivação de signicado: “estímulo para a (realização de algo), sugestão, instigação, incentivo”, que contrapõe dedução e indução de forma antagônica. Ou seja: se a organização quer um programa da qualidade que estimule os participantes a continuamente melhorarem a si mesmos e aos processos dos quais participam, esta deve buscar incentivar, antes de tudo, a participação consciente dos funcionários. Por outro lado, se o programa tiver caráter meramente indutivo, pouco estímulo as pessoas terão para participarem da análise e criação das melhorias, isto é, todos farão um excelente trabalho, mesmo sem saberem o “quê” e o “porquê” de estarem fazendo o que fazem. Como sempre, o segredo estaria no equilíbrio entre dedução e indução. Para exemplicar, Jeff Immelt, substituto de Jack Welch na presidência da General Electric, recentemente reconheceu que o Programa Six Sigma trouxe resultados excelentes para a GE, mas que era chegada a hora das pessoas começarem a pensar (sic): Temos uma geração de pessoas que sabem como processar tabelas de uxos de produção, que sabem obter qualidade

superior. Mas essas pessoas não sabem por que fazem isso, ou seja, “o quê” e “onde” fazem. Jeff Immelt. Entrevista conce-

dida à Fast Company, traduzida e publicada no Brasil pela HSM Management.

62. Rubrica: losoa. Processo de raciocínio através do qual é possível, partindo de uma ou mais premissas aceitas como verdadeiras (p.ex., A é igual a B e B é igual a C), a obtenção de uma conclusão necessária e evidente (no ex. anterior, A é igual a C ) Dicionário Houaiss.

164 BPM & BPMS

O que Immelt disse é que é preciso fazer as pessoas fazerem melhor sabendo por que fazem e por que devem fazer o que estão fazendo. A falta desta percepção por parte dos gestores de programas da qualidade leva estes mesmos programas a serem apenas conjuntos de manuais, em papel ou eletrônicos, que raramente servem para fazer as pessoas aprenderem alguma coisa, mas servem para fazê-las decorar o que devem fazer no dia a dia. Denitivamente, a Desorganização Informacional não será solucionada a se conrmarem as tendências atuais. Contudo, se a análise, o desenho, o redesenho e a modelagem de processos de negócio forem corretamente realizados há chances de podermos controlar a DoI em diferentes graus. O difícil é fazer as pessoas desistirem dos modismos, das pirotecnias tão ao gosto dos gurus, dos vendedores e das empresas que vendem TI e de alguns usuários, e se concentrarem no trabalho árduo, e muitas vezes sem qualquer glamour, da documentação e da análise dos dados e informações que formam e informam qualquer processo de negócio. Há também os prossionais que são muitas vezes obrigados a economizar tempo e consequentemente recursos nanceiros quando da realização da análise, mapeamento e modelagem de processos de negócio, levando os projetos ao fracasso por queimarem etapas importantes. Não devemos esquecer que projetos de AMOP, além da complexidade natural que possuem, ainda exigem paciência e tato porque tratam o tempo todo com pessoas. Só para podermos recordar, pois este assunto está exaustivamente abordado em outros livros meus63, um processo de negócio só estará correta e devidamente documentado se, no mínimo, os elementos da gura 5.1 tiverem sido adequadamente documentados.

63. O Teatro Organizacional – Construindo e Implantando Processos de Negócio, Uso e Desuso de Sistemas de Workow, ambos da Editora E-papers, e Sistemas, Métodos & Processos, da Editora Atlas.


Figura 5.1 – Elementos que compõem o processo de negócio.

Modelos de Processos de Negócio Existem modelos de processos de negócio em grande profusão e cada autor procura encerrar nos seus respectivos modelos a mais srcinal abordagem possível para sintetizar e transmitir por meio destes a essência de qualquer processo de negócio. Alguns modelos confundem-se com a metodologia desenvolvida para operacionalizá-los. Outros, entretanto, buscam distinguir os dois momentuns, o da conceituação e o da operacionalização do modelo.

O Modelo DOMP No modelo DOMP64, desenvolvido por mim, busquei sintetizar a complexidade que todo e qualquer processo de negócio tem, por mais simples que ele 64. DOMP é o modelo referencial e a metodologia criados por mim ao longo de mais de vinte anos de prática em projetos de análise, desenho, redesenho, modelagem, melhoria, organização, documentação, otimização e gerenciamento de processos de negócio.

166 BPM & BPMS

possa parecer. A gura 5.2 mostra todos os elementos que SEMPRE estão presentes em qualquer processo de negócio que seja executado em primeiro plano (foreground process).

Figura 5.2 - Modelo referencial de processo de negócio DOMP.

Embora todos estes elementos estejam num modelo referencial de processo de negócio executado em primeiro plano (foreground process), eles também estão presentes em processos de negócio executados em segundo plano (background processes), com algumas variações e diferenças por se tratarem de processos tecnológicos. O ponto central da metodologia DOMP é a análise de três princípios fundamentais, existentes em qualquer processo de negócio. Batizados de even65

66

tOgrama , infOgrama e funcionOgrama , eles permitem a análise da menor

65. Para conhecer mais sobre eventos e microeventos leia o meu livro O Teatro Organizacional, editora E-Papers. 66. eventOgrama, infOgrama e funcionOgrama estão descritos no livro Sistemas, Métodos & Processos. Editora Atlas.


parte de qualquer processo de negócio: o evento e o microevento. Eles, e não as atividades, são as menores partes de um processo de negócio. Sejam simples ou complexos, os processos têm que ter (são) pelo menos uma cadeia de eventos, porque têm que ter (são) pelo menos uma cadeia de atividades. Na vida real os processos em geral têm muitas cadeias de eventos também porque têm muitas cadeias de atividades. Atividades estão sempre ligadas a eventos e estes estão, às vezes, ligados a microeventos. Por isso, a rigor, Todo processo é um conjunto de eventos inter-relacionados, dispostos numa sequência lógica e cronológica para produzir um bem ou um serviço. Este princípio aplica-se até mesmo a processos que executamos na nossa vida pessoal, embora estes não nos chamem a atenção por já estarem naturalmente incorporados ao nosso dia a dia. Alguns dos mais conhecidos modelos de processos de negócio:

The MIT Process handbook O MIT Process handbook é um projeto do Massachusetts Institute of Technology iniciado em 1991 e pode ser conhecido tanto por meio do seu site http://ccs.mit.edu/ph/ quanto por meio do livro homônimo: Organizing Business Knowledge: The MIT Process handbook , escrito por W. Thomas e Kevin Malone. Em 1996, entretanto, o projeto foi retirado de dentro do MIT’s Sloan School of Management, dando lugar a uma empresa particular chamada Phios Corporation, que hoje detém os direitos exclusivos de comercialização da propriedade intelectual resultante do The MIT Process handbook project. Vale ressaltar que os mesmos pesquisadores que deram srcem ao The MIT Process handbook são os cofundadores e donos da Phios. Na verdade o handbook é uma coleção de documentos, artigos e ferramentas que giram em torno do tema Business Process.

168 BPM & BPMS

O modelo conceitual do The MIT Process handbook é o apresentado na gura 5.3 e, embora o livro de onde eu o tenha extraído, Organizing Business Knowledge: The MIT Process handbook, tenha mais de 600 páginas, esta é a única representação gráca de tal modelo.

Figura 5.3 – Modelo referencial do The MIT Process handbook project. Fonte: Organizing Business Knowledge: The MIT Process handbook.

The Supply-Chain Operations Reference Model (SCOR) Este outro modelo referencial tem por particularidade ser adstrito às operações de logística e da cadeia de fornecimento (supply-chain). O SCOR é um modelo desenvolvido e gerenciado por The Supply-Chain Council (www. supply-chain.org) e está representado na gura 5.4.


Figura 5.4 – The Supply-Chain Operations Reference Model (SCOR). Fonte: SCOR Version 6.0, 2003.

170 BPM & BPMS

Modelo de Processo de Negócio do NP2TEC-UNIRIO Embora não seja um modelo de processo de negócio strictu sensu, a abordagem desenvolvida pelas(os) pesquisadoras(es) do NP2TEC da Universidade Federal da Cidade do Rio de Janeiro (UNIRIO) para desenho, redesenho e modelagem de processos tem o mérito de integrar as fases desenvolvidas em tempos variáveis com a fase de gerenciamento, permitindo uma visão global de todo o ciclo de vida de qualquer processo de negócio.

Figura 5.5 - Abordagem NP2TEC para Modelagem de Processos. Fonte: NP2Tec-UNIRIO. Reprodução permitida pelas autoras.

A abordagem NP2TEC é baseada em iterações sucessivas nas quais os diversos modelos que representam o negócio são construídos de forma incremental. A situação atual (As Is) dos


processos é modelada e avaliada, e melhorias são propostas e reetidas no modelo desejado (To Be ou Will Be ou What If). Assim, o ciclo evolutivo dos modelos parte da estratégia do projeto e segue até a implementação da situação desejada.

O modelo do NP2Tec-UNIRIO para Gestão Integrada de Processos mostra que a construção de sistemas de informações deve estar totalmente aderente processo de criada negócio meio deauma arquitetura tecnolódos gica processos, corporativa,ao desenvolvida, e por implantada partir da modelagem dando srcem a um círculo virtuoso extremamente benéco à organização.

Modelo Genérico de Processo de Negócio Seja qual for o modelo consultado e empregado para as discussões iniciais sobre processos de negócio a preocupação deve ser sempre a de entendermos o modelo à luz das nossas necessidades e assim nos servirmos dele para encontrar soluções para os problemas de produção que viermos a ter nas organizações. Mesmo com as características próprias de cada modelo, nós enxergamos em cada um os princípios básicos de um processo de negócio. A gura princípios são: 5.6 mostra o modelo genérico do processo de negócio, cujos

Figura 5.6 – Modelo genérico de processo de negócio (business process).

Todos os modelos de processos de negócio apresentados aqui têm como preocupação principal mostrar clara e objetivamente a dependência da produção de bens e serviços com uma ordem “processual 67” das tarefas que teremos que executar para produzi-los. Nada que tenhamos que produzir

67. Embora este seja um termo jurídico, decidi usá-lo aqui por ser a expressão mais exata da ideia que quero transmitir.

172 BPM & BPMS

o poderá ser sem que as sequências lógica e cronológica, a que damos o nome de processo de negócio, tenham sido criadas e implantadas. Este trabalho de criar e implantar um processo de negócio necessariamente será realizado por meio de uma metodologia, que genericamente eu batizei de AMOP em 2000. AMOP é um “quase” acrônimo que engloba análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio.

Metodologias para Processos de Negócio Qualquer coisa perto de mil ainda seria um número subestimado de metodologias e softwares cuja nalidade é trabalhar com processos de negócio. Existem produtos de inúmeras marcas, procedências e funcionalidades que, não raro, provocam nos usuários sentimentos contraditórios, confusos e angustiantes. As perguntas que todos se fazem, sempre, são: – Qual software comprar? – Qual metodologia usar? Mesmo empresas grandes, ricas e poderosas sofrem do mal da ignorância, e seus prossionais não raro se deparam com questões simplórias como a que um grupo de analistas me colocou após uma conferência: – Professor, o senhor acha que é necessário termos uma metodologia com formulários para levantar junto aos usuários dados e informações dos processos? – Por quê? Perguntei. Vocês levantam dados e informações como? – Cada analista levanta dados e informações livremente, anotando tudo num caderno. – Isto é muito ruim, eu disse ao grupo de analistas. Sem formulários que minimamente guiem a todos dentro de um padrão de documentação cada analista vai acabar documentando os elementos do processo da forma que melhor lhe aprouver, souber ou, pior, quiser. Isto causará esforço redobrado na hora de transcrever estes dados e informações para o software que a organização estiver usando para documentar processos.


Especicamente neste caso, estes analistas, funcionários de uma grande empresa brasileira, descobriram que sem um conjunto de formulários que oriente a todos ca difícil fazer documentação de processos de negócio. O software que esta empresa usa é um dos mais caros e renomados programas para documentação de processos existente hoje no mercado, entretanto ele não dispõe de instrumentos que possibilitem aos prossionais que dele se utilizam para trabalhar com processos de negócio manter um padrão uniforme de atuação junto aos usuários. Desta forma, cada analista faz sua própria metodologia de captura e documentação dos dados e informações quando os usuários são entrevistados. A empresa gasta milhares de reais na aquisição da licença de uso de um software e seus prossionais carecem de orientação metodológica para realizarem a parte mais importante do trabalho com processos de negócio: entrevistar pessoas. Embora pareça ser exceção, posso garantir que esta situação se repete com todos os softwares de documentação e simulação de processos. Tal vez porque, mundialmente, ainda haja resquícios da trajetória malfadada do antigo departamento de O&M existente nas empresas até a década de 80 do século passado. O departamento de O&M, Organização & Métodos, existia nas empresas para desempenhar as funções, entre outras, de documentador e organizador dos uxos de trabalho, principalmente da área administrativa; mas, a despeito do poder que teve na maioria das organizações, esta área falhou na sua missão por diversos motivos. Falhou porque não conseguiu integrarse à engenharia de produção e por conta disto ter cado de fora do chãode-fábrica na manufatura discreta e de transformação. Com isto seu raio de atuação limitava-se à parte administrativa das organizações, onde seus prossionais buscavam rotinizar os uxos de trabalho para posteriormente serem sistematizados e mecanizados por meio de sistemas de informações. O&M naquela época limitava-se a desenhar pequenas rotinas de trabalho, porque não tinha uma visão holística da organização. Ninguém falava em processos de negócio, e processos eram apenas os “industriais”, ou seja, eram apenas os que o chão-de-fábrica possuía para fabricar o produto material. A indústria de serviço era ignorada e muitos dos seus produtos intangíveis nem existiam. Desta forma havia uma dicotomia muito grande e, às vezes total, entre a área de O&M e a engenharia de produção.

174 BPM & BPMS

Lembro-me de várias situações de estresse quando eu trabalhava na Scania do Brasil na década de 80, entre a área de O&M, o chão-de-fábrica e a engenharia de produção. Por ser “metalúrgico” e ter tido contato com inúmeras outras empresas de manufatura na época, sabia que tais situações não eram nem privilégio nem deciência da nossa empresa. Eram situações generalizadas. Além de uma visão extremamente limitada, O&M era composta de prossionais, via de regra, despreparados para exercer as funções que a organização esperava que exercessem. Eram frequentemente prossionais escolhidos dentro das próprias empresas com a ideia de que quanto mais antigos “de casa” eles fossem mais as conheceriam e portanto poderiam identicar, entender e documentar o modus operandi de cada área objeto dos trabalhos de rotinização muito melhor que qualquer prossional contratado fora. O trabalho de O&M deveria servir de base para o desenvolvimento dos sistemas de informações, mas isto era também frequentemente motivo de controvérsias e tensões. O princípio da “coisa” (a ideia de processos até podia existir de forma latente) era que O&M fornecesse para a área de sistemas o uxo e as rotinas de trabalho e com base nestas informações os analistas de sistemas conceberiam, desenvolveriam e orientariam os programadores sob sua responsabilidade na programação dos sistemas de informações.

Metodologias para AMOP Assim como softwares, existem milhares de metodologias voltadas a análise, desenho, redesenho, modelagem, melhoria, organização, documentação, otimização e gerenciamento de processos de negócio. Portanto não será por falta de metodologia que as organizações deixarão de trabalhar processos corretamente. Pelo contrário, esta profusão de metodologias talvez atrapalhe a quem não tenha ainda experiência para escolher, dentre tantas, aquela que melhor poderá atender aos objetivos do projeto. Os cuidados devem começar já pelo entendimento do objetivo do processo, ou seja, os cuidados devem começar pelo entendimento “do por que o processo foi criado”. As organizações necessitam ter cuidado com o “princípio da igualdade” entre organizações, apregoado por aqueles que insistem em tirar proveito de falsas premissas, como das “melhores práticas que devem ser seguidas por


todos”. É preciso tomar cuidado com a ideia de que podemos usar um modelo de processo em vez de criarmos um processo particular para a nossa organização. A exemplo do que ocorre com os famosos ERPs68, que são oferecidos como tendo sido criados com base em modelos de excelência de práticas de gerenciamento empresariais e vendidos pelos fabricantes como paradigmas que devem ser “obrigatoriamente” seguidos por todas as empresas. O resultado todos nós conhecemos sobejamente. Implantações caras, demoradas e em muitos casos frustrantes por partirem de falsas premissas, como a de que a organização deve se enquadrar ao (excelente) ERP e não (como seria o correto) que o ERP ajuste-se aos processos de negócio da organização. Uma das falácias apregoadas pelos que defendem o BPMS como novo, softwares é a de que estes geralmente têm grande quantidade deprocessos modelados tanto em outras organizações, o que daria a eles ostatus de paradigmas, quanto como modelos teóricos o( ne size ts all) para serem implantados em qualquer organização em qualquer parte do mundo, obrigando-as a se amoldarem aos modelos. Ao que parece, os que defendem este tipo de utilização têm pouca ou nenhuma experiência com projetos de análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio, pois éjustamente este tipo de abordagem que nós, analistas de processos, tanto combatemos nas implantações dos ERPs. Seria incongruência da nossa parte defender uma prática como esta e fazer a organização se ajustar aos processos existentes nos BPMS. Se não aceitamos isto com implantações de ERPs, jamais deveríamos aceitar para análise, desenho, redesenho, modelagem, melhoria, organização, documentação, otimização e gerenciamento de processos de negócio. Assim, por favor, não caia em mais este “canto de sereias”. Não aceite como verdadeira a armação de que os processos de negócio existentes nos BPMS são paradigmas de excelência que qualquer organização deveria seguir, implantar e operar! Assim como os seres humanos, processos de negócio são iguais nas suas essências e diferentes nas suas individualidades. Aliás, antes de continuar, chamo a sua atenção para três verbos: desenhar, redesenhar e modelar, usados indiscriminadamente em projetos envolvendo

68. ERP, Enterprise Resource Planning ou softwares de gerenciamento de recursos empresariais.

176 BPM & BPMS

processos de negócio como se os três signicassem a mesma coisa, embora requeiram de nós ações que resultarão em produtos diferentes, ainda que parecidos. 

Desenhar processos signica capturar, documentar e organizar processos que já existem e que nunca tinham sido formalmente documentados.



Redesenhar processos signica recriar, redesenhar, “reengenheirar”, reinventar processos que já existem e que já foram desenhados, documentados.



Modelar processos signica criar um processo inteiramente novo, que nunca tenha existido antes na organização.

Embora pareça uma discussão apenas semântica (e ainda que o fosse), vale a pena sabermos exatamente o que queremos e o que estamos comprando para garantirmos não sermos enganados ao nal de qualquer projeto envolvendo processos de negócio. Por exemplo, se a organização compra um projeto de desenho de processos ela deve esperar como produto nal o mapeamento documental dos processos já existentes na operação dela. Os processos documentados, desenhados, todos oscompra que tenham sido objeto da proposta aceita e comprada. Se aserão organização um projeto de redesenho de processos ela deve esperar como produto nal o mapeamento documental atualizado dos processos já existentes na operação e consequentemente a melhoria, incremental ou disruptiva, de todos eles. Mas se a organização compra um projeto de modelagem de processos ela deve esperar como produto nal a criação dos processos de negócio que tenham sido objetos da compra. Metodologias também podem ser modelos de referência para processos de negócio, uma vez que possibilitam trabalhar processos com base embenchmarks realizados em organizações que se tornaram paradigmas por serem excelentes. Note que paradigmas de excelência podem ser modelos, mas não podem ser usadosque sem adaptações e ajustes organizar, pela organização. muitas as metodologias objetivam documentar, analisar São & modelar processos de negócio, a ponto de confundirem até mesmo quem se dedica ao tema com assiduidade. A seguir estão algumas destas metodologias. 

CIM-OSA – Computer-Integrated Manufacturing – Open System Architecture.

AMOP é uma Saída? 177 

SOM – Semantic Object Model.



OOIE – Object-Oriented Information Engineering.



ARIIS – Architecture of Integrated Information System .



UML – Unied Modeling Language69.



CMM-I – Capability Maturity Model – Integrated.

 

RUP – Rational Unied Process. The MIT Process Handbook.



SCOR – Supply-Chain Council.



DOMP70 – Documentação, Organização e Melhoria de Processos.

Algumas destas metodologias foram criadas e desenvolvidas em função dos respectivos softwares para processos de negócio. São metodologias que só podem ser usadas se, e somente se, o software homônimo também o for. Por isto, são metodologias limitadas pelas funcionalidades que os softwares têm. Outras metodologias, como a CMM-I, que nasceu para garantir padrões de qualidade para indústrias de software, foram criadas para fases especícas da análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio e depois ampliadas para englobar outros aspectos do ambiente organizacional. De qualquer modo, e qualquer que seja a metodologia que a organização queira e venha a usar, o importante é que o faça, pois nenhum projeto de análise & modelagem de processos de negócio pode prescindir de uma, sob pena de não ser concluído com sucesso. Ou seja, para fazer análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio é necessária a utilização de uma metodologia que consistentemente sirva de base, teórica e prática, que tais projetos requerem. 69. UML é uma notação, uma linguagem gráca, e nãoexatamente uma metodologia, mas justamente pela utilização que muitos fazem desta linguagem para documentar processos é que eu a classico como metodologia. Entretanto, podemos exprimir qualquer metodologia com os elementos da UML e representar processos com seusdiagramas de Estado e Atividades. 70. DOMP é a metodologia criada por mim ao longo de mais de vinte anos de prática em projetos de análise, desenho, redesenho, modelagem, melhoria, organização, documentação, otimização e gerenciamento de processos de negócio.

178 BPM & BPMS

DOMP A metodologia DOMP (Documentação, Organização e Melhoria de Processos) vem sendo criada por mim, beneciando-me e a ela da experiência adquirida com cada projeto AMOP71. Hoje esta metodologia tem perto de cento e cinquenta formulários que atendem às necessidades de análise, desenho, redesenho, modelagem, implantação, gerenciamento e melhoria de qualquer processoorganização, de negócio existente, quer sejam eles processos executados em primeiro plano (foreground processes) quer sejam eles processos executados em segundo plano (background processes). A metodologia DOMP72 tem como mínima estrutura a mostrada a seguir e cobre todos os elementos mostrados no modelo de referência da gura 5.2. 1. FINALIDADE 2. ÁREA DE APLICAÇÃO 3. PROCESSO 3.1. NOME DO PROCESSO 3.2. funcionOgrama 3.3. FLUXO DO PROCESSO. 3.4. eventOgrama 3.5. ATIVIDADES DO PROCESSO. 3.5.1. NOME DA ATIVIDADE DO PROCESSO 3.5.1.1. eventOgrama 3.5.1.2. PROCEDIMENTO E TAREFAS 3.5.1.3. infOgrama 3.5.2. NOME DA ATIVIDADE DO PROCESSO 3.5.2.1. eventOgrama 3.5.2.2. PROCEDIMENTO 3.5.2.3. infOgrama 3.5.3. ...

71. AMOP, outra sigla criada por mim em 1997 para divulgar os cursos de análise & modelagem de processos de negócio ministrados pela minha empresa, a TRCR KNOWLEDGE. 72. A descrição completa da metodologia DOMP está no livro Sistemas, Métodos & Processos. Editora Atlas, 2ª edição, 3ª reimpressão em 2008.


4. SUBPROCESSOS 4.1. NOME DO SUBPROCESSO 4.2. funcionOgrama 4.3. FLUXO DO SUBPROCESSO 4.4. eventOgrama 4.5. ATIVIDADES DO SUBPROCESSO 4.5.1. NOME DA ATIVIDADE DO SUBPROCESSO 4.5.1.1. eventOgrama 4.5.1.2. PROCEDIMENTO E TAREFAS 4.5.1.3. infOgrama 4.5.2. NOME DA ATIVIDADE DO SUBPROCESSO 4.5.2.1. eventOgrama 3.5.2.2. PROCEDIMENTO E TAREFAS 3.5.2.3. infOgrama 4.5.3. ... 5. ROTINAS 5.1. NOME DA ROTINA 5.2. funcionOgrama 5.3. FLUXO DA ROTINA 5.4. eventOgrama 5.5. ATIVIDADES DA ROTINA 5.5.1. NOME DA ATIVIDADE DA ROTINA 5.5.1.1. eventOgrama 5.5.1.2. PROCEDIMENTO E TAREFAS 5.5.1.3. infOgrama 5.5.2. NOME DA ATIVIDADE DA ROTINA 5.5.2.1. eventOgrama 5.5.2.2. PROCEDIMENTO E TAREFAS 5.5.2.3. infOgrama 5.5.3. ... Em geral os autores que tratam de processos de negócio ou, mais recentemente, de Business Process Management e Business Process Management Systems contentam-se em apresentar uma profusão de teorias, modelos e ideias, mas abstêm-se de apresentar soluções próprias, talvez porque, a exemplo do The MIT handbook project, creiam ser mais lucrativo vendê-las em projetos de AMOP.

180 BPM & BPMS

É sem dúvida importante que nesta nossa sociedade ultramercantilista, onde o conhecimento custa cada vez mais caro, cada qual proteja (ou tente proteger) da melhor forma possível o conhecimento, vendendo-o em variadas formas e oportunidades. Isto acontece com livros estrangeiros e nacionais. Entretanto, talvez haja outro motivo bem mais plausível para tanto “mistério”: a absoluta falta de uma metodologia para análise, desenho, redesenho, modelagem, melhoria, organização, documentação, otimização e gerenciamento de processos de negócio. A ausência de metodologias para AMOP nos livros que tratam de processos de negócio, além de privar o leitor de ideias que certamente iriam ajudá-lo a começar um projeto, serve para perpetuar a imagem negativa que estes mesmos projetos têm junto ao empresariado, mormente aquele mais imediatista. Explico: não é fácil vender projetos que visem analisar, desenhar, redesenhar, modelar, melhorar, organizar, documentar, otimizar e gerenciar processos de negócio. Qualquer projeto AMOP é algo extremamente abstrato para ser vendido e, principalmente, comprado. O dono de empresa, o presidente, o gerente geral, na grande maioria, não consegue enxergar além do hardware. Não consegue enxergar além do físico (computadores, mesas, cadeiras, tijolos). A grande maioria tem diculdade em pensar, abstrair. A grande maioria gosta de pegar naquilo que está comprando e, convenhamos, conhecimento (mesmo o da própria organização) é algo que jamais poderá ser tocado. Desta forma é mais simples e fácil vender/comprar um prédio (tijolos), um microcomputador, uma máquina, uma mesa, uma cadeira e até mesmo um software que pode ser instalado e visto “rodando” dentro de um computador ou servidor qualquer, do que um projeto para analisar, desenhar, redesenhar, modelar, melhorar, organizar, documentar, otimizar e gerenciar processos de negócio. Como sempre, tenho um exemplo acontecido comigo que, além de sintomático, chega a ser desgastante e irritante! Durante mais de um ano um empresário, dono de uma empresa que fatura em torno de 100 milhões de reais por ano, sistematicamente pediu-me propostas para realizar análise, desenho, redesenho, modelagem, melhoria, organização, documentação, otimização e gerenciamento dos processos da empresa dele. Ora ele pedia uma proposta geral, para realizar o trabalho em toda a empresa, ora ele pedia uma proposta para um processo especíco.


A última foi para análise, desenho, redesenho, organização, documentação, otimização do processo de faturamento que, diga-se de passagem, é extremamente complexo por ser esta empresa fornecedora (terceirizadora) de serviços de impressão e gerenciamento eletrônico de documentos. E ao acabar de escrever este livro ele ainda não tinha se decidido pela contratação do serviço. Você atélúdica ter achado engraçada a situação, Mas posso garantir pode que de não tem nada. Enquanto estehilariante! empresário não se decide por analisar, desenhar, redesenhar, modelar, melhorar, organizar, documentar, otimizar e gerenciar os processos de negócio da sua empresa, o descontrole operacional (admitido por ele numa das primeira reuniões) vai corroendo a eciência e a lucratividade da empresa. Pior, desgastando as relações com os clientes e, principalmente, com os usuários nais dos serviços prestados (dentro destes clientes). Este empresário, assim como centenas iguais a ele, tem uma típica relação de “amor e ódio” com o tema “processos de negócio”. Ele sabe que é importante e, mais que isso, que é imprescindível a análise, o desenho, o redesenho, a modelagem, a melhoria, a organização, a documentação, a otimização e o gerenciamento dos processos da empresa dele, mas tem MEDO. É isso mesmo, MEDO. Ele tem medo de comprar algo abstrato. Em resumo: ele tem medo de ser enganado. E muitos já o foram73. Todo processo de negócio é um ente abstrato, que só começa a aparecer, a car visível, a se tornar concreto, quando documentamos as atividades que o compõem, pois é nesta hora que conseguimos enxergar as pessoas que trabalham, operam, o processo de negócio e, por conseguinte, ele deixa de ser abstrato e passa a ser visto. As perguntas que todo empresário se faz ao negociar um projeto deste tipo são: – O que é que eu vou receber ao nal dos trabalhos? – No que isto melhorará minha empresa? – Será que vale mesmo a pena fazer análise, desenho, redesenho, modelagem, melhoria, organização, documentação dos processos?

73. Leia meu livro Uso e Desuso de Sistemas de Workow. Editora E-papers.

182 BPM & BPMS

– Será que este “cara” está me enrolando? – Será este consultor mais um espertinho querendo ganhar dinheiro fácil comigo? Por conta de algum projeto mal-sucedido74, próprio ou de terceiros, a desconança é muito grande. Aliás, para alguns empresários esta desconança éque quase uma de que estão sendo “enrolados”. Por isso é importante todos os certeza envolvidos, comprador, vendedor, usuários, analistas de processos, saibam o que estão vendendo e comprando para que ao nal dos trabalhos não reste uma sensação estranha de ter “entregue mais do que o vendido e recebido” por parte do vendedor e de ter “recebido menos do que o comprado e pago” por parte do comprador. Entre outras causas, a Desorganização Informacional (DoI) contribui sobremaneira para que este tipo de empresário prolifere, mais e mais a cada dia. Aliás, a DoI talvez seja a principal causa, pois tal comportamento tem como explicação mais plausível e verdadeira justamente a exacerbada quantidade de documentos, físicos e eletrônicos, dados, informações, conhecimento, com os quais todos nós lidamos (imperiosamente) hoje e para sempre. Dado ao curtíssimo tempo que temos todos para tomar decisões, das mais simples às mais complexas, estamos sempre operando em dois extremos ou muito próximos deles. Um extremo é o que nos obriga a decidirmos já, mesmo sem termos convicção absoluta de que estamos tomando a decisão correta ou a que envolve o menor risco de fracasso, muitas vezes por falta de elementos que nos permitam uma análise mais cuidadosa das possibilidades e probabilidades. O outro extremo é o que nos impele a não decidirmos nunca, dada a quantidade de incertezas presentes na nossa análise. Justamente o que acontece com o empresário do exemplo citado. Business Process Management e o BPMS podem nos ajudar na hora da

decisão,oumesmo premidos pela exiguidade de tempo, ou nem tanto; cheios, não, deque incertezas.

74. Leia meu livro Uso e Desuso de Sistemas de Workow. Editora E-papers.


Sobre BPO e KPO Terceirização há muito deixou de ser algo excepcional, como o fora na década de 90. Naqueles tempos terceirizar era algo estranho, incompreendido tanto para quem terceirizava quanto para quem assumia a terceirização. A confusão era generalizada e a maioria dos prossionais terceirizados pensava que,(oalém de não ter de também trabalhar passaria tanto quanto o fazia até aquele momento da terceirização), a ganhar mais, muito mais. Como sempre ocorre nestas ocasiões, muitos erros foram cometidos e muitos “acertos de contas” foram feitos sob aparente necessidade de cortar gastos. Mas a terceirização evoluiu muito. Deixou de ser desculpa para demitir pessoas, mandar embora os desafetos, para se transformar em um importante instrumento de gerência. Hoje, a decisão de terceirizar ou não uma operação qualquer se baseia em princípios objetivos, além de ser muito bem pensada, ponderada e analisada, para que, ao ser tomada, satisfaça plena e satisfatoriamente (produtividade e lucratividade) a quem terceirizou e a quem assumiu a terceirização da operação. A despeito de todas as justicativas que possam ser dadas por uma organização para terceirizar ou maisque operações, o que conta mesmo na hora de tomar tal decisãouma é a análise os responsáveis pela organização fazem sobre: 

Conhecimento da operação.



Complexidade da operação.



Custo da operação.



Propriedade da operação.

Que os ajudarão na escolha das seguintes alternativas, entre várias outras: 

Fazer em casa com recursos internos?



Fazer em casa com recursos externos?



Fazer fora de casa?



Terceirizar somente a operação?



Terceirizar o conhecimento da operação?

A evolução do conceito de Outsourcing, causada pelas novas técnicas de gerenciamento e administração, aliadas às atuais Tecnologias da Informa-

184 BPM & BPMS

ção, fez com que as organizações olhassem para a terceirização com outros olhos, diferentemente dos primeiros momentos quando somente a redução de custos (a qualquer preço) importava para que fosse tomada a decisão de terceirizar. No passado existiram vários tipos de outsourcing, entre eles o completo e o seletivo, mas todos preocupavam-se somente com a operação dos recursos envolvidos na produção do bem e do serviço. Por exemplo, lembro-me de quando construí (literalmente) e implantei central de operações da Hewlett Packard do Brasil na década de 90 e doa nosso primeiro cliente, um grande frigoríco brasileiro, que terceirizou a operação da sua rede de dados conosco. À época, a HP mundial tinha criado uma divisão de outsourcing seletivo, selective outsourcing, cujo objetivo era assumir a administração de determinados recursos do cliente. Não estávamos preocupados com os processos em si, nem com os do cliente nem com os nossos, apenas deveríamos manter funcionando o que quer que tivesse sido terceirizado conosco. E o fazíamos bem! Por meio de um software de gerenciamento de redes, o HP OpenView, tínhamos condições de enxergar e gerenciar todos os recursos da imensa rede de dados do cliente. Outsourcing, seletivo ou total, era isso. Entretanto, nos últimos anos, dois tipos de terceirização e gerenciamento de processos, e consequentemente dois tipos de processos, têm cada vez mais interessado às organizações e frequentado a mídia especializada. São eles: 

Business Process Outsourcing - BPO.



Knowledge Process Outsourcing - KPO.

Ambas as terceirizações podem ser soluções para a Desorganização Informacional, desde que a organização dos processos que serão terceirizados seja objeto de cuidadosa análise, especialmente no caso do BPO, pois neste tipo de outsourcing a inteligência da operação continuará com a empresa que quer terceirizar uma dada operação. Tanto BPO quanto KPO estão intimamente ligadas à gerência do conhecimento, quer o conhecimento permaneça na organização, BPO, quer o conhecimento seja da empresa que fornecerá o serviço, KPO. As necessidades de cada uma destas terceirizações só serão atendidas e gerenciadas com Business Process Management e com as tecnologias existentes no Business Process Management System. Se bem que qualquer software de Workow existente também possa fazê-lo.


Alguns países têm se destacado em Business Process Outsourcing (BPO) e em Knowledge Process Outsourcing (KPO). Os principais são Índia e Paquistão. O Brasil começa a dar os primeiros passos neste promissor segmento de negócio, mas a legislação trabalhista existente, a alta carga de impostos e a precária situação educacional impedem que ele concorra de igual para igual com outros países, especialmente com a Índia.

Business Process Outsourcing - BPO Eu deno BPO como: Contratação de terceiros para a operação de um ou de vários processos de negócio sem a transferência do conhecimento dos procedimentos e do produto produzidos para e por estes processos. A terceirização de processo de negócio, Business Process Outsourcing – BPO, signica contratar de terceiros a operacionalização, a execução, do processo de negócio para, consequentemente, receber o produto que o mesmo deve “produzir”, obrigando o provedor do serviço de terceirização ao cumprimento dos respectivos SLA75 e SLM76, extremamente rígidos. Os principais fornecedores deste tipo de outsourcing são: 

Índia – engenharia e desenvolvimento de software.

75. O acordo de nível de serviço (SLA) é o documento que deve preceder a assinatura do contrato de outsourcing. Nele estão compromissos de ambas as partes, contratante e contratada, especicados de forma detalhada para permitir sua execução. Todos os deveres, obrigações, responsabilidades e benefícios que de alguma forma carem subentendidos, que não forem correta e convenientemente explicados, converter-se-ão em pontos de tensão e atrito durante a execução do contrato de terceirização. Para que tais situações não venham a ocorrer é necessário que o processo de negócio que vai ser terceirizado seja corretamente documentado. Em outras palavras, só podemos saber exatamente como é o processo se especicarmos todos os elementos que estiverem contidos nele. Por isso, entregar somente um uxograma para a empresa contratada é o mesmo que entregar nada! 76. Todo acordo de serviço contratado de terceiros, Service Level Agreement (SLA), tem que ser gerenciado por um conjunto de atividades que fazem parte de um processo especíco para este tipo de serviço. Chamamos esses processos de Service Level Management (SLM). Os processos SLM têm, entre outras, as seguintes responsabilidades: gerenciar os acordos dos níveis de serviços; medir o desempenho do Service Level Agreement por meio de métricas e indicadores que foram denidos quando da contratação dos serviços.

186 BPM & BPMS 

Paquistão – desenvolvimento de software.



Cingapura – manufatura de eletroeletrônicos.



China – manufatura em geral.



México – manufatura de montagem.

Deve estar claro que por trás do BPO está a imperiosa necessidade de cortar custos, transferindo para terceiros tudo que não for essencialmente core business, ou seja, tudo que não for o núcleo do negócio. Desta forma: 

Bancos podem transferir para terceiros uma série de processos sem perderem as características fundamentais que os fazem ser instituições nanceiras. Por exemplo, terceirizam o processo de SAC, Serviço de Atendimento ao Cliente; o processo de HD, Hekp Desk; os processos de serviços de impressão de qualquer tipo dentre inúmeros outros processos.



Confecções, como a Levi’s, terceirizam a fabricação das roupas com a sua marca.



Fabricantes de calçados, como a Nike, terceirizam a fabricação dos seus produtos.

Todas estas organizaçõestêm em comum a guarda do conhecimento dos seus produtos e dos seus negócios quando da terceirização dos processos. Isto é, estas empresas terceirizam operação, mas não terceirizam conhecimento.

Knowledge Process Outsourcing - KPO Eu deno KPO como: Contratação de terceiros para a criação do conhecimento de um negócio, produto ou processo e dos recursos necessários para operacionalizá-los. A terceirização do conhecimento do processo e/ou do negócio, Knowledge Process Outsourcing – KPO, signica contratar de terceiros não somente a operacionalização, a execução dos processos de negócio e, consequentemente, a “fabricação” do produto que estes devem “produzir”, mas contratar o desenvolvimento da inteligência do negócio e/ou do produto. KPO não


obriga a organização que o contratou a terceirizar todo o ciclo de vida do produto, ou seja, KPO pode ser somente o desenvolvimento do negócio ou produto e não necessariamente envolver sua produção, que pode ser feita pela organização que contratou o KPO ou até mesmo por uma terceira empresa, embora este tipo de terceirização seja raro. Assim, eu estou contratando BPO se disser: Quero que a empresa X opere o serviço de atendimento ao cliente (SAC) dentro dos padrões de atendimento da minha empresa, com o roteiro (script) fornecido pela minha empresa e com auditorias permanentemente feitas pela minha empresa. Mas eu estou contratando KPO se disser: Quero da empresa X o serviço de atendimento ao cliente (SAC). Business Process Management System, como qualquer software de Workow bem projetado e implantado, pode ser a ferramenta por excelência para operar e gerenciar tanto BPO como KPO. Nenhum outro software ou sistema tem as mesmas condições e funcionalidades para manter coesos, sob controle e gerenciados, em tempo real, tanto processos quanto conhecimentos terceirizados.

Seja por causa da terceirização dos processos de negócio, seja por causa da terceirização do conhecimento – ou mesmo que não haja terceirização alguma –, as organizações vão necessitar de instrumentos ágeis e exíveis para organização, controle e gerência. Esta necessidade remete todos nós às atuais tecnologias da informação, que chamo de emergentes. Estas tecnologias são iguais entre si pela concepção e preocupações que as fazem voltadas ao conhecimento e não somente a dados ou informações, como as existentes até quase o nal do século XX. Institutos internacionais de pesquisas estimam que mercado,entre o de US$ serProcess Outsourcing viços de Knowledge (KPO), vaieste movimentar 10 bilhões e US$ 17 bilhões até 2010. No setor nanceiro, a maior utilização do KPO se dará em processos para scoring de crédito, cálculo de proteção de perdas e análise de fraudes. Processos analíticos empresariais, como os de compra de ações, também serão pontos fortes no crescimento do setor.

188 BPM & BPMS

Sobre a SOx e Governança Corporativa Os dois temas estão intimamente ligados a Business Process Management, sendo inclusive um dos mais fortes argumentos de venda que os “fabricantes” de BPMS utilizam para apregoar as “maravilhas” que tais softwares têm a oferecer às organizações. Acho conveniente recordar aqui a denição de BPM: Conjunto formado por metodologias e tecnologias para possibilitar que processos de negócio integrem, lógica e cronologicamente, clientes, fornecedores, parceiros, inuenciadores, empregados e todo e qualquer elemento que com eles possam, queiram ou tenham que interagir, dando ao ambiente interno e externo da organização uma visão completa e essencialmente integrada das operações e atuações de cada participante de todos os processos de negócio. E a denição de BPMS: de softwares, aplicações ferramentas de tecnologiaConjunto da informação cujo objetivo é o de epossibilitar a implantação do modus operandi Business Process Management, integrando em tempo real clientes, fornecedores, parceiros, inuenciadores, empregados e todo e qualquer elemento que com eles possam, queiram ou tenham que interagir por meio da automatização dos processos de negócio. Um dos aceleradores das pretensas transformações que o Workow vem sofrendo para se transformar em BPMS foi a criação da lei americana conhecida por Sarbanes-Oxley (SOx), aprovada pelo Congresso dos Estados Unidos para garantir que os fatos e os problemas ocorridos entre 1990 e 2000 com empresas como a Xerox, a Enron, a WorldCom, a Vivendi e a Royal Ahold, entre outras, não voltassem a se repetir. A SOx, como é popularmente conhecida, foi criada para restabelecer a conança do investidor na contabilidade e nos registros contábeis das empresas com as quais ele, investidor, mantém relações de investimento. Basicamente, a SOx é um conjunto de regras muito rígidas para o gerenciamento dos registros de transações, Record Management, e para a docu-


mentação dos processos de negócio de empresas que tenham ações negociadas em Bolsa, como forma de garantir que os investidores não sejam surpreendidos com falcatruas cometidas pelos executivos que dirigem tais empresas. Embora muitas das determinações da SOx digam respeito a empresas de capital aberto, as de capital “fechado” também passam a ser obrigadas a respeitá-las se tiverem negócios com as negociadas em Bolsa. Por exemplo: de capital fechado queàs negociem empresascorde capital aberto empresas se acham igualmente obrigadas regras decom governança porativa, como forma de garantir a transparência nos negócios realizados entre elas. Daí os fabricantes de Workow terem se apressado em “vender” o conceito de BPMS como “A” solução para integrar os processos, as tecnologias e os atores existentes nestes relacionamentos, mantendo registros que servirão para a rastreabilidade e consequente auditoria dos negócios realizados por elas e entre eles. A rigor, nada que o “bom e velho” Workow já não conseguisse fazer.

Principais Desafios da Lei Sarbanes-Oxley SOx, abreviatura pela a lei é mais conhecida, é um conjunto de regras eA normas que devem serqual obrigatoriamente cumpridas pelos executivos das empresas de capital negociado em Bolsa, ou de empresas que negociem com aquelas. Algumas obrigatoriedades são: 

Visibilidade dos processos. Todos os procedimentos que operacionalizam as transações da organização devem ser claros, documentados e abertos à auditagem. Os controles criados para garantir a execução de tais procedimentos e a consequente geração de relatórios nanceiros devem ser certicados. Todas as operações devem ser documentadas, assim como devem estar claramente denidas as responsabilidades funcionais de todos os envolvidos na operação dos processos.



Visibilidade dos relatórios. A saúde nanceira da organização deve poder, obrigatoriamente, ser comprovada a qualquer momento, imediatamente, através de relatórios que tenham credibilidade. Os CEOs (Chief Executive Ofcer) e os CFOs (Chief Fi-

190 BPM & BPMS

nancial Ofcer)77 devem garantir pessoalmente, como obrigação

inalienável dos seus papéis funcionais, tanto a visibilidade como a verdade de tais relatórios. 

Responsabilidade com datas. Os prazos para a geração dos relatórios nanceiros devem ser curtos e rigidamente cumpridos.

O META Group, empresa americana de análise de mercado, estima que, até 2010, 85% das organizações americanas desenvolverão projetos de BPM para implantação de BPMS a m de garantir a conformidade com a Sarbanes-Oxley Act das suas operações. Com isto, há uma previsão de gastos para a implantação deste ambiente envolvendo hardware, software e análise & modelagem de processos de negócio da ordem de dois e meio bilhões de dólares. Agora ca mais claro o fato de os fabricantes de softwares, os criadores de metodologias e os “especialistas de plantão” terem rapidamente agregado as siglas BPM e BPMS aos seus produtos.

Governança Corporativa O que é Governança Corporativa? Por que BPM e BPMS estão ligadas a Governança Corporativa? Strictu sensu, governança corporativa signica: Procedimentos e regras que estabelecem papéis e responsabilidades para orientar a quem governa as modernas organizações por meio dos objetivos da governança. Assim sendo, e a exemplo do que ocorre hoje em todas as organizações que não têm seus processos documentados e formalmente conhecidos, torna-se quase impossível a prática da Governança Corporativa, que exige que processos sejam do conhecimento explícito de todos que convivem sob uma mesma governança, sem análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio e um software, BPMS ou simplesmente Workow, para automatizar tudo que puder dar à Governança Corporativa segurança operacional.

77. Ou em português: diretor executivo, ou diretor presidente, e diretor nanceiro, respectivamente.


Figura 5.7 – Esquema genérico da organização e ligações com BPMS.

A gura 5.7 mostra como são complexas as relações das modernas organizações. Há uma profusão de atores e jogadores envolvidos num jogo de negócio cujos interesses são por vezes antagônicos, por vezes complementares, mas que sempre obrigam a organização a buscar conciliar os interesses de todos em prol dos seus próprios interesses. Business Process Management Systems têm a capacidade de transformar uma Governança Corporativa reativa em práticas ágeis, proativas e seguras, com as quais todos os players (interessados) concordarão por se sentirem confortáveis e com seus interesses protegidos.

6 Ciclos de Vida BPM e BPMS Ciclo de Vida do BPM Dentro do Business Process Management há um grande ciclo de vida que se subdivide em vários outros ciclos, cada um deles ligado a um aspecto do conjunto BPM. A gura 6.1 mostra o ciclo de vida genérico do BPM.

Figura 6.1 – Ciclo de vida geral do Business Process Management.

Ciclos de Vida BPM e BPMS 193

O ciclo de vida genérico do BPM começa quando a organização decide mapear seus processos, conhecendo-os por meio da documentação detalhada de cada um dos elementos que deles fazem parte. Para fazer isto a organização tem duas possibilidades: faz o trabalho de documentação com recursos próprios (analistas de processos internos); ou contrata de terceiros os recursos necessários para levar adiante o projeto. Qualquer que seja a decisão, fazer ou contratar, é necessário que tanto o escopo do projeto quanto os meios pelos quais ele será implantado sejam claramente denidos, entendidos e equacionados em termos de custo-benefício. Para tanto, uma das primeiras preocupações da organização deve ser a de ter uma metodologia para fazer o trabalho de análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio. Pode ser qualquer metodologia, qualquer uma serve, desde que haja uma. O que não se pode admitir é que qualquer trabalho com processos de negócio seja iniciado sem uma metodologia, por mais simples que sejam o trabalho e a metodologia utilizada. A gura 6.2 mostra uma estrutura metodológica genérica para trabalhar processos de negócio.

Figura 6.2 – Estrutura metodológica genérica para projetos BPM.

194 BPM & BPMS

Fases da Metodologia Tempo variável. 

Análise inicial das necessidades (ou do problema). Quando tomamos contato com a realidade do projeto, sua extensão, duração, custo e objetivo. É nesta fase do projeto, ou mais precisamente pré-projeto, que todas as dúvidas e expectativas do cliente devem ser entendidas e equacionadas. Fazer esta fase sem os cuidados necessários pode signicar o fracasso do projeto, com diferentes graus de prejuízo. Entre outras questões, será necessário saber com certeza: o que o cliente espera receber ao nal dos trabalhos; expectativas e desejos da organização; quantas pessoas estão (e estarão durante o desenrolar dos trabalhos) envolvidas com o processo que será desenhado, redesenhado ou modelado; por quantas áreas funcionais estão distribuídas as pessoas; localização geográca destas áreas e quantas informações forem úteis para que façamos uma proposta com o menor grau possível de incerteza.

Figura 6.3 – Ciclo de vida “análise inicial das necessidades (ou do(s) problema(s))”.

Ciclos de Vida BPM e BPMS 195 

Documentação, desenho e análise do processo atual. Quando documentamos o processo que já existe a m de melhorarmos suas condições de execução e operação. Processos sem controle são todos os que existem, produzem bens ou serviços, mas não são formalmente conhecidos porque não são documentados. Todas as pessoas que executam operações nestes processos não sabem muito além do que fazem. O trabalho de documentar e desenhar o processo existente serve para que o mesmo seja formalmente conhecido, analisado e entendido por todos que têm responsabilidades com o produto produzido por ele. Esta fase só é feita se o processo existe, se não existe passamos da análise inicial das necessidades (ou do problema) para a fase seguinte.

Figura 6.4 – Ciclo de vida “documentação, desenho e análise do processo atual”.

196 BPM & BPMS 

Análise, redesenho ou modelagem do novo processo. Quando desenhamos o novo processo, quer com melhorias sobre os já existentes na organização, quer o processo seja totalmente novo.

Figura 6.5 – Ciclo de vida “análise, redesenho ou modelagem e criação do novo processo”.

Ciclos de Vida BPM e BPMS 197 

Implantação do novo processo. Quando implantamos o novo processo, treinando e acompanhando as pessoas para garantir que o que foi projetado e criado seja efetivamente executado e operacionalizado.

Figura 6.6 – Ciclo de vida “implantação do novo processo”.

198 BPM & BPMS

Tempo cíclico. 

Gerenciamento do processo - PDCA. Quando todos os funcionários buscarão melhorar continuamente o que fazem por meio da implantação da melhoria contínua da qualidade do processo de negócio.

Figura 6.7 – Ciclo de vida “gerenciamento do processo – PDCA”.


Ciclo de Vida do BPMS Depois da análise ou do desenho, redesenho, modelagem, organização e melhoria do processo de negócio que estiver sendo mapeado é necessário programá-lo num software BPMS para que possamos implantá-lo egerenciá-lo.

Figura 6.8 – Ciclo de vida do Business Process Management System.

Programar ou diagramar o BPMS é o primeiro grande conjunto dentro do ciclo de vida do software. A “matéria-prima” para este trabalho é a análise, o desenho, o redesenho, a modelagem e a organização dos processos de negócio mapeados nos ciclos Business Process Management. Mais especicamente, a documentação que viermos a produzir de qualquer processo poderá ser utilizada para a implantação do software BPMS ou Workow, desde que o nível de detalhamento possibilite seu uso para programar e/ou diagramar um Business Process Management System. A ressalva faz-se necessária porque softwares deste tipo requerem um grau de detalhamento da documentação dos processos de negócio muito maior do que quando gerada para outras utilizações, como para simplesmente conhecê-los. Como, aliás, já acontecia com o predecessor do BPMS, o Workow.

200 BPM & BPMS

Por exemplo, se quisermos atribuir ao software BPMS (usando o módulo Workow) o controle dos tempos de processamento, de espera e total das atividades existentes de cada processo, precisamos já ter denido tanto o SLA, Service Level Agreement, quanto o SLM, Service Level Management. A criação do Service Level Agreement, ou, em Português, acordo do nível de serviço, só pode ser feita corretamente se o processo tiver sido sucientemente detalhado e documentado, caso contrário será quase impossível fazer com que o BPMS execute o controle dos tempos. Mesmo que tenha sido sucientemente detalhado, ainda será preciso que cada processo seja cuidadosamente analisado quanto aos tipos de controle de tempos possíveis para cada evento existente dentro de cada atividade que dele faça parte. Aqui está um dos mais importantes pontos de análise de processos de negócio: evento e microevento. Cada atividade é composta de pelo menos um evento, e existem eventos simples e eventos compostos. Os eventos simples são unos, indivisíveis, enquanto os eventos compostos são compostos de microeventos. Diferentemente do PERT e do CPM, a metodologia desenvolvida por mim (DOMP) trabalha com o princípio do consumo de recursos e tempos por arte de cada evento e microevento existentes em cada atividade. Por isso precisamos saber em que ponto do processamento do evento, ou microevento, podemos programar o módulo Workow do BPMS para ele “abortar” uma ocorrência ou transferi-la a outro ator dentro do processo sem causarmos com isso transtornos ou prejuízos ao produto nal, ao processo e, em última instância, à própria organização. O microevento é a menor parte de qualquer processo. É por meio dos microeventos que tudo que entra (inputs) nas atividades é processado (process) e se transforma em saídas (outputs). Atividades são compostas de eventos e na maioria das vezes os eventos são compostos de microeventos. Entendêlos e controlá-los assegura o cumprimento das responsabilidades de cada atividade existente no processo. Entretanto, o trabalho de um analista de processos não é simples, pois para entender corretamente o funcionamento de atividade, para entender o correto funcionamento das engrenagens doscada eventos e microeventos existentes nelas, faz-se necessário um trabalho paciente, cuidadoso e muitas vezes redobrado de busca, coleta e organização de dados e informações sobre o processo de negócio. Não podemos controlar o todo pelo todo, como aliás propõe a metodologia BAM. Temos que controlar o todo pelas suas partes, como proponho na metodologia DOMP.


O Business Activity Management (BAM) foi criado por David McCoy e Jim Sinur, do Gartner Group, os quais descreveram as responsabilidades do BAM através de um amplo espectro que vai da supervisão em tempo real das operações do dia a dia da organização ao monitoramento do desempenho da cada atividade de cada processo, a m de alertar de forma proativa os responsáveis sobre as falhas que possam ocorrer na execução das atividades existentes. BAM foi criado como metodologia para permitir um controle mais preciso de tudo que todos fazem dentro da organização e em tempo real, de forma imediata ao acontecimento, o que signicaria transformar o gerenciamento existente hoje na maioria das organizações, passando-o de reativo para uma administração com “ação em tempo real”. Precisamos controlar o todo por meio das suas partes. No caso da metodologia DOMP, por meio dos eventos e microeventos.

Figura 6.9 – Estrutura de processo, subprocessos, atividades, eventos, microeventos.

202 BPM & BPMS

Em síntese, programar ou diagramar um software de BPMS será sempre necessariamente tão preciso, detalhado e simplicado (e não pense que há aqui uma incongruência por ser detalhado e simplicado ao mesmo tempo) quanto tenha sido o trabalho de análise, desenho, redesenho, modelagem e organização dos processos de negócio a serem automatizados. Testar e Simular o BPMS tem dois pontos de preocupação importantes. Business Process Management System sãoe complexos Softwares por envolverem sempre grande quantidade de componentes por serem, depois, usados num grande número de hardwares diferentes. Assim sendo, testar o sistema deve ser a primeira preocupação dos que desenvolvem soluções neste tipo de software. Testar signica vericar se todos os componentes estão denidos corretamente, se todos os hardwares estão endereçados e programados corretamente e, enm, se todas as ligações entre os diver sos componentes de software e entre estes e o hardware estão certas e operando. Só a partir destes testes iremos passar à segunda preocupação importante: a simulação.

Testar signica vericar se tudo está funcionando, mas simular, a rigor mais importante que testar, signica vericar se tudo está funcionando como deveria funcionar ou se tudo está funcionando como exige o processo automatizado. A simulação deve ser realizada em duas fases: 



A equipe de programação e/ou diagramação do BPMS deve testar e simular todo o processo programado ou diagramado no software sem envolver os usuários nais. A equipe de programação e diagramação do BPMS deve envolver os usuários nais na simulação, pois são eles que vão atestar o correto funcionamento do sistema e do processo e, consequentemente, aprová-los ou rejeitá-los.

Note que na segunda fase não há testes, mas apenas simulação. Não devemos nada lógica quando envolvemosdo o usuário apenas simular testar a estrutura e cronológica processonal, paradevemos provarmos seus resultados aos usuários nais. Treinar os usuários tão logo os resultados dos testes e as simulações tenham sido satisfatórios. Não há necessidade de treinarmos os usuários antes das simulações, pois eles não necessariamente irão operar o BPMS, mas apenas acompanhar as sessões de simulação feitas pelo pessoal técnico.


Este é o momento de fazermos as pessoas assumirem as responsabilidades inerentes a cada papel funcional criado para cada atividade do processo de negócio automatizado pelo Business Process Management System, seja em um processo novo ou em um que tenha sido redesenhado. Ensinar e treinar cada funcionário deve ser um trabalho realizado pelos analistas de processos, ou pelo grupo de implantação do BPMS. É um momento importante e deve ocorrer imediatamente antes da implantação do processo para que cadaator (cada funcionário) possa entender suas responsabilidades perante a organização, possa saber exatamente o que seus clientes, internos eexternos, esperam como produto da sua atividade e como osoftware BPMS irá funcionar para ajudá-lo nas suas responsabilidades no diaa dia da organização. Implantar o BPMS dando por encerrado o ciclo inicial da implantação do software dentro da organização. Convém salientar que na falta de alguma outra “invenção” implantaremos também um plano PDCA, para que possamos melhorar continuamente tanto a aplicação BPMS quanto o próprio processo automatizado por ele. Processos podem ser implantados de quatro maneiras, ou por meio de uma quinta que é a mistura das quatro formas básicas. A escolha da melhor maneira para implantar um processo depende das análises sobre o tipo de processo, a natureza do processo, onde o processo será executado, se em primeiro plano, em segundo plano, ou em ambos, se é um processo terceirizado. Estas análises vão poder nos dar informações para escolhermos qual será o tipo de implantação que devemos usar para o processo. Entretanto, convém ressaltar que, além da implantação poder ser feita com um mix das quatro formas básicas, há, também, a possibilidade de um mesmo processo necessitar de várias formas para ser implantado. Nestes casos o processo deverá ser subdividido em subprocessos que serão implantados de acordo com o mesmo tipo de análise descrita no parágrafo anterior. Os quatro tipos básicos para implantação de processos são: 

Com descontinuidade total do processo em operação. Se esse for o tipo de implantação escolhido, os dois processos não poderão existir ao mesmo tempo, pois no momento que o novo for implantado o antigo terá que ser retirado de operação e todos os testes têm que ser feitos.



Com descontinuidade parcial do processo em operação. Alguns processos podem ter sua implantação desmembrada em

204 BPM & BPMS

subprocessos (partes) e por suas características podem ser implantados com a descontinuidade parcial do processo que estiver sendo executado. Geralmente, mas não é uma regra, os processos são subdivididos em subprocessos para poderem ser implantados desta forma. 

Com sobreposição ao processo em operação. Geralmente, mas sem assumir regra, a sobreposição é praticada também para a implantação de como pequenas melhorias resultantes dos programas da qualidade. Este tipo de implantação é mais utilizada para melhoria incremental do processo existente.



Em paralelo com o processo em operação. Esse é o tipo mais trabalhoso de implantação do ponto de vista dos atores do processo, pois eles terão que “atuar” em dois processos ao mesmo tempo e isto certamente vai gerar uma dupla carga de trabalho. Muito comum na área de TI, onde programas, sistemas e até mesmo certos dispositivos necessitam ser “certicados” antes que os antigos sejam desativados.

Estas quatro formas de implantação de um processo não são mutuamente exclusivas e dependem do tipo de processo que temos que implantar para que cada uma seja a escolhida ou várias delas em conjunto. Ao encerrar este capítulo quero chamar a atenção para uma última observação não menos importante. O ciclo de vida do Business Process Management System tem complexidade maior do que a maioria dos softwares emergentes conhecidos, incluindo-se aqui o Workow. A razão para isto é tanto simples como prosaica e está diretamente ligada a uma característica básica do BMPS: o grande número de componentes que tais softwares possuem integrados numa única suíte. Por isso, o ciclo completo de vida de um BPMS não somente pode ter uma duração extremamente variável em função do tamanho e da complexidade do processo decomplexo negócio que automatizado comoque, podeembora ser simples ou extremamente por será envolver componentes integrados, mantêm suas características srcinais e individuais, independentemente da integração que venham a sofrer no BPMS, o que, por vezes, diculta a própria integração e o funcionamento harmônico de todos os componentes envolvidos no Business Process Management System.

7 Mudança é Tudo que Existe Embora tenha já escrito vários capítulos sobre mudanças e gerência de mudanças nas organizações78 acho conveniente voltar ao tema, mesmo que brevemente, para reforçar alguns pontos que considero importantes por conta das experiências vividas em projetos de análise, desenho, redesenho, modelagem, organização, gerenciamento melhoria de processos de negócio nos quaisimplantação, atuei. Não que haja algo dee especialíssimo no gerenciamento das mudanças que serão causadas pelo BPM e pelo software BPMS, pois, anal, cuidados com mudanças deveriam ser objetos de preocupação até mesmo nas mais simples implantações de ERPs. Entretanto, o que mais tem chamado a minha atenção durante todos estes anos trabalhando processos de negócio é a carga de estresse de tais projetos à qual as pessoas são submetidas sem qualquer necessidade. Não vou aqui embasar minhas considerações nas inúmeras teorias existentes nas ciências sociais, psicológicas ou nas teses losócas de nomes como Nicolau Maquiavel, Karl Popper, Karl Marx, Adam Smith, Freud e Jung entre centenas de outros estudiosos. Quero apenas passar minha vivência, algumas experiências, que me zeram reetir sobre como envolver as pessoas para que as mudanças se deem da forma mais suave possível. Se é que se pode esperar alguma suavidade em mudanças organizacionais.

78. Veja Workow II e O Teatro Organizacional, ambos pela Editora E-Papers.

206 BPM & BPMS

A coisa mais importante a fazer num projeto de processos de negócio é tratar com respeito, desde o início, todos os envolvidos no projeto. Isto signica dizer: devemos nos comunicar com todos na organização e, desde o início, esclarecer tudo que estiver sendo feito ou vier a ser feito pela equipe do projeto. Além disto, é importante que desde o início o objetivo do projeto seja informado a todos na organização. Mudanças sempre traumáticas, queain estejamos mudando para melhor, poissão no momento da mudançamesmo “o melhor” da é (sempre é e muitas vezes sempre será) uma incógnita. Só saberemos se a mudança foi realmente para melhor depois que ela estiver consolidada, aí pode ser tarde demais para voltarmos atrás e é isto que nos assusta em qualquer mudança. A primeira coisa a fazer é envolver RH, quer comunicando-lhe o que está para acontecer, quer transferindo para ele tarefas de comunicação e organização de pessoal. Aliás, na ISO 9000, uma das principais preocupações que devemos ter quando da sua implantação é com a comunicação sobre a norma e o objetivo da certicação. Envolver o RH desde o início dos trabalhos dará respaldo legal e organizacional ao nosso projeto, além de evitar situações constrangedoras ou conituosas. Eu costumo envolver o RH desde o início dos trabalhos. Quando começo um projeto sempre busco envolver, direta ou indiretamente, o maior número possível de pessoas para lhes passar informações objetivas sobre o projeto ou fazê-las participarem de uma palestra sobre o que são processos de negócio, a importância da documentação e do seu gerenciamento e de como as pessoas se beneciarão da formalização dos processos existentes na organização. Chamo sua atenção para o que pode parecer perda de tempo: o fato de envolvermos pessoas com diferentes responsabilidades funcionais numa palestra que aos olhos de muitos pode parecer demasiadamente complexa para o nível de instrução de alguns prossionais. Não pense assim. Não subestime as pessoas. Não faça pouco caso do faxineiro, da copeira, do mensageiro, do motorista! Primeiro, porque todos dentro de uma organização devem ser tratados com igual respeito desde o início do projeto, mormente um projeto de Business Process Management, resulte ele ou não na implantação de um BPMS. Segundo, porque processos de negócio perpassam todos os níveis de responsabilidades e da es-

Mudança é Tudo que Existe 207

trutura funcional, o que signica dizer que ninguém cará de fora de todos os processos que vierem a ser trabalhados, ou, em outras palavras, todos os funcionários estarão presentes em pelo menos um processo existente na organização. Por m, muitas soluções para problemas “insolúveis” vêm de pessoas “acima de qualquer suspeita”, justamente por estarem fora do problema, mas dentro da organização como um todo. boss”,di-o Depois de envolver RH, envolva no projeto o “big presidente, o gerenteo geral, o donoformalmente enm. Envolva aquele que poderá rimir dúvidas sobre estratégias e operações, resolver conitos, abrir todas as portas da organização, além de dar respaldo ao projeto. Peça que parta dele um comunicado sobre o que vai acontecer, pois isto “convencerá” a todos da importância do projeto e os incentivará a colaborar com a equipe do mesmo.

Muitas vezes a equipe do projeto precisa ter acesso a dados e informações condenciais e nestes casos haverá a necessidade de alguém com poder de mando suciente para autorizar o acesso da equipe aos dados.

Gerenciando a Mudança Lembre-se de que a parcela dos que gostam de mudanças é ínma se comparada a dos que não gostam de mudanças. Por isso é bom reconhecer os diversos tipos de pessoas com as quais iremos interagir sempre que uma mudança vier a ocorrer em projetos envolvendo processos de negócio para sabermos como transformá-las em aliadas do projeto. Os tipos de pessoas mais comumente encontrados são: 

A indiferente.



A que rejeita passivamente.



A que rejeita ativamente.



O sabotador.



O colaborador.



O entusiasta não comprometido.



O entusiasta comprometido.

208 BPM & BPMS

Todas elas passam pelas diversas etapas de uma curva de transição, assumindo todos esses papéis nas diversas etapas do projeto, mas é raro. A gura 7.1 mostra os papéis que uma pessoa pode assumir dentro do ciclo de mudanças que ocorrem nas organizações.

Figura 7.1 – Pessoas e comportamentos no ciclo de mudanças.

Engana-se, também, quem acha que criar um programa de comunicação das mudanças seja algo proibitivo ou que possa desvirtuar o projeto. O que as pessoas mais querem quando ocorre uma mudança na organização em que trabalham, grande ou pequena, é serem comunicadas do que está acontecendo. As pessoas querem se sentir respeitadas. Muitas vezes basta um pequeno seminário, no qual se coloque o que irá acontecer na organização, aonde se pretende chegar, quais mudanças e qual papel esperamos que cada funcionário assuma nelas.


É claro que não se conseguirá cem por cento de adesão ao projeto, nem tampouco deve-se supor que as diversas fases pelas quais uma pessoa pode passar numa mudança deixem de existir somente porque a estamos tratando com respeito desde o início dos trabalhos, mas, por experiência própria, digo que muitos problemas serão evitados se agirmos com cautela e transparência.

Pontos de Atenção A gura 7.1 deve ser lida no sentido dos ponteiros dos relógios, começando no quadrante rejeição até chegarmos ao último quadrante, cooperação. A gura mostra, também, a interação existente entre as fases de aprendizado e os estágios que ocorrem em qualquer mudança. Desde os primeiros contatos no início da mudança até o domínio pleno do novo estado derivado da mudança, quando então chega-se à fase de cooperação, há uma natural interação do modelo com a gerência de mudanças. Ao longo desta leitura existem inúmeras manifestações (benignas e malignas) que devem ser tratadas com muita atenção. Estas manifestações podem ocorrer tanto com as pessoas que executam o projeto quanto com aquelas que serão atingidas, direta ou indiretamente. A culpa pelo fracasso ou a responsabilidade pelo sucesso do projeto tanto pode ser do analista de processos, do analista de BPMS, do SOAArchitect quanto do usuário nal. Se alguma coisa der errado, todos deverão repartir a culpa pelo fracasso. Se tudo der certo, todos deverão ser parabenizados. Vamos analisar cada estágio e suas implicações em projetos de análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio.

Rejeição Toda mudança é, por princípio, indesejada porque todamudança é, por menor que seja, uma ruptura com ostatus quo. Rupturas causam muito desconforto. As pessoas não gostam de ter nenhum componente do seu ambiente de trabalho modicado. Embora digam que anseiam pelas mudanças e até colaborem no desenvolvimento delas, elas usam de uma série de artifícios para retardar esses acontecimentos.

210 BPM & BPMS

Na fase de rejeição é comum ouvir frases do tipo: – Está bom do jeito que está. – Isso sempre foi feito dessa forma. – Eu sempre z assim e sempre deu certo. – Por que mexer em time que está ganhando? Essas frases, entre muitas outras do mesmo estilo, denotam a clara rejeição de qualquer ideia que implique em mudança e da própria mudança em si. Elas são claras, diretas, objetivas e mostram, sobretudo, uma total rejeição pelo novo. Entretanto existe outro tipo de rejeição com o qual os analistas devem se preocupar. São indivíduos que querem sempre mais e maiores mudanças justamente para que as coisas permaneçam como estão. Os usuários desta tática costumam dizer frases como: – Eu acho que deveríamos fazer muito mais... – Por que não incluirmos também... – Já que vamos mudar poderíamos mudar tudo! – Ou se faz tudo ou não se faz nada. Neste segundo tipo de rejeição o usuário age com a certeza de que, se forem sugeridas e aceitas mais e maiores mudanças, nada se fará pela absoluta falta do senso de limites de tempo, custo e escopo. Com ambos os extremos há que se tomar cuidado, pois qualquer mudança deve estar alinhada ao momento, às oportunidades e aos recursos disponíveis. O que é que deve ser feito para que as pessoas passem a colaborar com o desenvolvimento e a implantação das mudanças?

Primeira Regra: Não Assuste as Pessoas Não diga o que você vai fazer acontecer, pergunte o que ele (o usuário) sugere ou acha que a empresa necessita que seja feito, embora ao nal seja feita-so mente a vontade da organização. Faça parecer que tudo que está sendo mudado foi solicitado pelos próprios usuários, mas não minta. Procure fazer com


que todas as mudanças necessárias sejam requeridas pelos usuários. Para isto existem inúmeras técnicas, comobrainstorm, JAD79 etc., que podem ser usadas com sucesso para descobrir as reais necessidades da organização. Faça as pessoas comprarem as ideias desde o nascimento delas!

Segunda Regra: Alie-se a Quem for Favorável às Mudanças Um dos graves problemas de qualquer mudança é a diculdade de saber por que as pessoas são contrárias às mudanças. Por exemplo, eu conheci uma empresa na qual um dos principais executivos era contrário à implantação de um sistema de controle de estoque porque ele roubava. É isso mesmo. Ele roubava. O sistema colocaria um ponto nal naquele estado de bagunça reinante no estoque de produto acabado. Como o principal executivo não sabia da real situação, e ainda por cima gostava muito do tal que era contra, foi muito difícil convencê-lo da necessidade de implantar o sistema. A estratégia empregada foi nos aliarmos a outro executivo, também muito inuente, para que o projeto pudesse ser aprovado. Em toda empresa sempre vão existir aqueles que são a favor e aqueles que são contra qualquer mudança. Cabe aos responsáveis pelos projetos descobrirem os pontos de apoio a m de fazer as mudanças uírem mais facilmente. Aliás, uma regra de ouro é obter o apoio do principal responsável pela operação da empresa ou da área que será mudada. Pode ser o dono, o presidente, o diretor, o gerente, ou qualquer outro executivo que tenha poder para apadrinhar mudanças, por menores que elas sejam.

Terceira Regr a: Ressalte as Vantagens do Novo Deliberadamente esqueça a antiga realidade e faça com que todos, aos poucos, falem das novas possibilidades como se elas já fossem realidade. Não procure denegrir o status quo, não fale mal do estado atual das coisas, não radasuscetibilidades desnecessariamente. venda nova realidade trazida pela mudança. Em vez disso, trabalhe na A preocupação aqui é não criar resistências desnecessárias, o que invariavelmente ocorre quando se fala mal do que vinha sendo feito e bem do que 79. JAD, Joint Application Design.

212 BPM & BPMS

está por vir. Na fase de rejeição às mudanças as pessoas procuram, por todos os meios, impedir que elas ocorram, mas não costumam ser nada além de um empecilho. Já quando passam a boicotar as mudanças, a preocupação deve aumentar signicativamente.

Boicote Quando as pessoas assumem uma postura de boicote às mudanças elas passam de uma atitude passiva (estágio de rejeição) para uma atitude ativa contra toda e qualquer modicação do status quo. Essa a meu ver é a mais perigosa de todas as fases, pois boicotar signica ir além de uma resistência muito maior do que simplesmente rejeitar, signica trabalhar contra. Ao boicotar as mudanças, as pessoas agem com o propósito de fazer com que tudo venha a dar errado. Elas transformam cada ponto que precisa ser trabalhado e melhorado em deciências exacerbadamente intransponíveis. A gura 7.2 mostra gracamente como ocorrem as oportunidades, os boicotes e os pontos de ruptura a cada mudança dentro de qualquer organização, como parte da dinâmica do Ciclo Pessoas, do Modelo de Relacionamento Cíclico. Qualquer ação a ser tomada contra qualquer tipo de boicote deve explicitar o ponto de inexão, do qual não há como voltar atrás. Em outras palavras, é preciso que o passado seja explicitamente enterrado.

Figura 7.2 – Oportunidades, boicotes e pontos de ruptura no ciclo mudança.


Aceitação Depois do ponto de inexão, ou de ruptura com o passado, o usuário começa a aceitar a mudança. Essa aceitação pode se dar tanto através da política de fato consumado como pela constatação da necessidade e da oportunidade da mudança. Entretanto, a aceitação das mudanças, por parte do usuário, não signica que esteja tudo bem. A rigor, o simples fato das pessoas aceitarem as mudanças não proporciona a alavancagem necessária para que o que zermos tenha sucesso. Aceitar não signica outra coisa a não ser aceitar, e isso ainda é muito pouco para fazer dar certo qualquer mudança. Aceitar signica simplesmente que o estágio de boicote foi ultrapassado, só isso. Quando tivermos os usuários no estágio de aceitação precisamos começar a trabalhar para que essa aceitação seja ativa e não passiva, como ocorre muitas vezes. A aceitação passiva é tão prejudicial quanto o boicote, pois não trabalha a favor das mudanças, já que as pessoas deixam de, explicitamente, ser do contra. É muito fácil descobrir quem está realmente a favor das mudanças e quem as está aceitando passivamente. Os usuários ativos procuram demonstrar que estão aceitando não só as mudanças das suas próprias atividades como ainda ajudam os outros a aceitarem as deles, criando com isso uma sinergia extremamente benéca ao ambiente. São, também, estes usuários que primeiro passam ao último estágio do processo de mudança, a cooperação. Também precisamos controlar a aceitação das pessoas canalizando as energias despendidas por todos em prol das mudanças. Se assim não o zermos podemos estar gastando tempo e recursos desnecessariamente.

Cooperação Este é o estágio nal e o O mais desejado quem mudanças em qualquer organização. ideal seria quepor todos os empreende usuários fossem direto para esse estágio toda vez que alguma mudança se zesse necessária. Infelizmente sabemos isso ser impossível! O estágio de cooperação coloca toda e qualquer mudança num patamar de novas descobertas, pois se benecia da força criativa de cada usuário no processo de melhoria do que fora implantado. Isto signica dizer que é atra-

214 BPM & BPMS

vés da cooperação e da exploração das potencialidades das novas práticas que outros patamares quantitativos e qualitativos serão atingidos. Com tudo que de bom este estágio possa ser e ter, ainda assim é necessário que quem esteja gerenciando as mudanças permaneça ao lado dos usuários até que elas estejam concluídas e consolidadas. É preciso que o usuário seja estimulado, a todo momento, a prosseguir com as mudanças e que quemcom as esteja patrocinando presente até que elas não mais se pareçam mudanças mas comseo faça cotidiano. Ai estará na hora de uma nova mudança! Em 1957, Leon Festinger, psicólogo da Universidade de Stanford, Califórnia, publicou a teoria da Dissonância Cognitiva, segundo a qual as pessoas passam por grande aição mental quando descobrem que suas crenças estão em desacordo com seus atos. Festinger observou por meio de exaustivas pesquisas e experimentos que as pessoas nestas condições, no estado de Dissonância Cognitiva, tentam de todas as maneiras resolver o estresse, quer mudando suas crenças, quer alterando suas ações. A teoria da Dissonância Cognitiva aplicada às organizações nos possibilita entender que se as pessoas acreditam na organização, nos objetivos e nas metas estabelecidas para a organização, carão felizes em mudar seu comportamento para agirem de acordo com o que a organização necessitar. As pessoas sofrerão de Dissonância Cognitiva se não acreditarem na organização ou na sua condução, por exemplo. São situações que frequentemente vamos encontrar e para as quais devemos estar preparados quando executamos um projeto de análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio. Diminua o estresse que projetos de análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio causam nas pessoas dando a elas tantas informações quantas forem possíveis ou necessárias. O medo da mudança é o medo do desconhecido, do imponderável, da incógnita, não da mudança em si mesma!

8 Analistas

Novas categorias de analistas surgiram com o advento das tecnologias emergentes. Novos treinamentos, novas formações que permitirão aos prossionais que irãopara trabalhar como estas novas tecnologias prepararem convenientemente fazerem melhor uso possível de se cada uma delas e, obviamente, permitirem às suas organizações que também o façam. Entre as novas categorias de prossionais estão três imprescindíveis para Business Process Management e Business Process Management Systems. Uma é a que eu denominei de Analista de Workow (nunca esqueça que Workow é um módulo do BPMS). A outra é a que acabo de batizar (pelo menos com perl que especiquei) de Analista de BPMS e a terceira é a que o mercado chama de Arquiteto de SOA (SOA Architect). – O que são estas novas categorias de analistas? – Quais são os conhecimentos, as competências e as habilidades que os prossionais que querem trabalhar com estas tecnologias devem possuir, desenvolver e aprimorar? Antes de responder a estas perguntas eu preciso explicar o motivo que me levou a denir as duas novas categorias de analistas: a de Workow e de BPMS. Este motivo está diretamente ligado aos níveis de detalhamento do

216 BPM & BPMS

processo sobre o qual se está trabalhando em termos de levantamento, documentação, análise, melhoria e gerenciamento.

Os Três Níveis de Detalhamento da Documentação do Processo A documentação de qualquer processo pode ser feita em três níveis distintos, mas complementares, representados na gura 8.1. O motivo para o qual se está realizando o trabalho de levantamento e documentação do processo vai ditar o nível de profundidade requerida para o trabalho. Assim temos:

Figura 8.1 – Os três níveis de detalhamento da documentação do processo.

1º Nível O primeiro nível de detalhamento da documentação de um processo serve especicamente para que possamos conhecê-lo por meio do mapeamento das suas atividades (eventos e microeventos), papéis funcionais e padrões de medição e controle de desempenho. Neste nível, o trabalho de documentação não necessita descer a detalhes exigidos pelos outros dois níveis.

Analistas 217

Por exemplo: se não formos implantar alguma tecnologia de controle de processos, ou mesmo uma norma da família ISO, podemos obter como benefício deste nível de documentação a adequação dos sistemas de informações tradicionais (legacy systems) aos processos de negócio da organização. Desta forma, os antigos sistemas e os novos a serem desenvolvidos estariam reetindo melhor a realidade dos processos primários e secundários da organização.

2º Nível O segundo nível de detalhamento da documentação de um processo está intimamente ligado à adoção de alguma norma, como as da família ISO. Para implantar essas normas e, consequentemente, obter o certicado da qualidade, uma organização necessita descer a um nível maior de detalhamento no mapeamento e consequente documentação de qualquer processo a m de que o Manual da Qualidade possa reetir exatamente a maneira como um bem ou serviço deve ser produzido. Tanto a norma ISO 9000 quanto a 15100, para citar apenas duas, são rigorosas nas suas especicações, exigindo que o modus operandi, os termos usados nos manuais da qualidade, os padrões de aferição de desempenho do processo e as rotinas de auditoria sigam o roteiro estabelecido por estas normas.

3º Nível O terceiro nível de detalhamento da documentação de um processo é o nível exigido para a implantação de softwares como Workow, BPMS, SCM80, ECR81, GED82 etc. Aqui começa o trabalho do analista de Workow, de BPMS e de todas as outras tecnologias emergentes. Para implantar tecnologias como estas é imprescindível conhecermos certos aspectos que os outros dois níveis de detalhamento da documentação não exigem, simplesmente porque para eles não há nenhuma necessidade de tamanha minúcia.

80. SCM, Supply Chain Management. 81. ECR, Efcient Consumer Response. 82. GED, Gerenciamento Eletrônico de Documentos.

218 BPM & BPMS

Exemplos de Níveis de Documentação de Processos Alguns exemplos para que esse conceito possa car caracterizado com mais clareza. 1o Exemplo: Para a implantação de Workow é imprescindível que o analista de Workow detalhe papéis, regras de negócio e rotas, nesta ordem, a m de poder programar o software com a inteligência necessária ao seu funcionamento. Quanto mais detalhadas e precisas forem as informações obtidas desses três elementos fundamentais, maiores serão as incumbências assumidas pelo Workow. É a partir deste detalhamento que se estará tirando maior, ou menor, proveito da inteligência existente nesta classe de software. 2o Exemplo: O analista de Workow precisa tomar cuidado redobrado na hora de programar o processo que será automatizado, justamente para não correr o risco de estar simplesmente automatizando um processo “doente”, pois isso impediria o máximo aproveitamento da tecnologia utilizada. 3o Exemplo: Custos e tempo de execução para cada ocorrência são duas outras categorias de informação que não são exigidas para os dois primeiros níveis de detalhamento do processo, mas o são para implantação de Workow. Alguns softwares já têm, como parte do produto, módulos que permitem a confecção de relatórios estatísticos de custo e tempo. Desta forma é possível, a qualquer momento, saber quanto custa e quanto tempo está levando o processo para produzir o seu objeto de custo, isto é: o bem ou serviço produzido por ele. Através desses módulos é possível saber o tempo que levou cada ocorrência para ser tratada e consequentemente quanto custou cada uma delas. Se uma empresadedesejar implantar Workow terá,donecessariamente, que fazer o trabalho levantamento e documentação processo a ser automatizado. O esforço requerido para isto vai variar em função dos níveis de detalhamento do processo já existente. O analista de Workow será, daqui por diante, um prossional imprescindível a toda organização que quiser se beneciar desta incrível tecnologia, pois é este prossional que deve entender de processos e do software.

Analistas 219

O Analista de Processos O analista de processos é o prossional que, de certa forma, substituiu com vantagens o antigo analista de O&M. O analista de processos tem uma visão holística da organização, conhece tanto as áreasque sustentam os processos primários quanto as que sustentam os processos secundários. No passado o analista de O&M deveria ter tido esta competência, mas devido a uma série de percalços e deciências ele jamais chegou a ser o prossional de que as organizações necessitavam para organizar os processos existentes nelas. Para ter sucesso, o analista de processos pode e deve conhecer as diversas fontes das especialidades que possam auxiliá-lo no tratamento dos diversos temas envolvidos com o trabalho que hoje é uma das principais preocupações de organizações de todos os tipos: conhecer e gerenciar adequadamente seus processos. É por meio dos instrumentos metodológicos de pesquisa que o analista de processos constrói o resultado do seu trabalho, e é a partir da pesquisa que adquirimos e geramos conhecimento sobre cada um dos elementos que compõem os processos de negócio. Todo analista de processos deve sempre se lembrar de que pesquisar que não não é a mesma coisa que juntar dados ou adivinhar e construir suposições correspondem à realidade do objeto da pesquisa. Também não é juntar desordenadamente um monte de papéis com anotações imprecisas ou inúteis e cuja coleta desgasta as relações entre os usuários e os analistas de processos. Por isto, precisamos escolher uma metodologia com a qual a pesquisa será executada. Os métodos de pesquisa nos ajudarão a ordenar a coleta e a análise dos dados obtidos para posterior processamento. A falta de uma metodologia para suportar nosso trabalho de analistas de processos é outro ponto falho nas normas da qualidade. Nenhuma delas nos orienta sobre como abordar os usuários, como coletar os dados, que tratamento devemos ou podemos dar a estes, deixando à própria sorte alguns prossionais bem intencionados realizar um trabalho de qualidade, embora existam aqueles que, até porem ignorância, estão sempre “juntando papel” sem saber por que nem para quê o fazem. O analista de processos deve estar atento às ferramentas que ele precisa ter em mãos para coletar o conhecimento sobre processos existentes, quer estejam documentados formal ou sejam informalmente conhecidos. Entre estas ferramentas estão:

220 BPM & BPMS 

Folha de coleta, ou caderno de anotações, para registrar tudo que for observado, coletado, ouvido, visto, lido. Jamais um analista de processos deve se apresentar a uma fonte mostrando-se despreparado para receber o que ela irá lhe transmitir durante o contato entre os dois.



Formulários previamente criados que, além de serem objetivos, ajudem o analista de processos a abordar corretamente a problemática pesquisada.



Roteiro com perguntas criadas previamente e que, de preferência, tenham sido discutidas com o grupo de trabalho.

Muitos prossionais que trabalham em consultorias de processos sequer têm uma metodologia para fazer o trabalho de documentação e análise dos processos; outras consultorias usam pseudo ou protometodologias, que não têm sequer as quatro fases imprescindíveis para a condução de projetos deste tipo. Conclusão: não havendo metodologia para análise, desenho, redesenho, modelagem, organização, implantação, gerenciamento e melhoria de processos de negócio, menos ainda haverá uma que oriente o prossional sobre o modus operandi dela. A falta de uma metodologia de pesquisa nos leva à perda de oportunidades e do foco na condução dos nossos projetos de análise & modelagem de processos de negócio. Para começar “com o pé direito” um projeto de AMOP, o analista de processos precisa: 

saber exatamente qual é o produto do processo, caso ele já esteja produzindo algo. Se for um processo novo, é preciso saber com precisão qual será o produto a ser produzido;



conhecer os objetivos do processo em termos de tempos, atendimento a clientes, qualidade prometida;



quem são os clientes externos e onde eles estão;



quem são os clientes internos e onde eles estão; descobrir se a qualidade está sendo cumprida, isto é, quais “promessas foram feitas” versus “que produto está sendo entregue”;





ouvir, sempre que possível, os clientes internos e externos do processo.

Analistas 221

Outro fator decisivo para trabalhar processos, tanto os existentes quanto os novos, é sabermos separar duas grandes fases do nosso trabalho: a fase de criação e a fase de produção. Elas estão inseridas num contexto que chamo de diagrama dos dois quadrantes, ou “Q²”. Ambos os quadrantes devem “produzir” alguma coisa. Nenhum analista de processos deve nutrir a veleidade de pensar que vai encontrar a solução para algum problema sozinho. Esse é um trabalho que deve ser feito em conjunto com os funcionários da organização. Quanto mais cedo e melhor for o envolvimento de todos com o projeto, mais rápidas e maiores serão as chances de sucesso. Por isso, o analista de processos deve: 1. Discutir com cada ator as especicações do papel que ele terá que representar. 2. Ouvir com atenção o que cada ator tem a dizer. 3. Criar ou utilizar exercícios que privilegiem a prática da criação coletiva. 4. Distribuir, de preferência eletronicamente, todos os documentos que compõem o processo, compartilhando e gerando conhecimento. 5. Explicar a todos os atores do que se trata cada documento e qual o signicado das informações contidas nele. 6. Pedir que cada ator leia com atenção a máxima quantidade possível de informações sobre o processo. 7. Pedir que cada ator leia com atenção seu papel funcional. 8. Fazer uma leitura pública do processo m de permitir que todos o entendam da mesma forma e com o amesmo signicado. 9. Repassar com cada ator o papel que lhe foi atribuído. 10. Não deixar nenhuma pergunta car sem resposta. 11. Não deixar que nenhuma dúvida persista.

222 BPM & BPMS

12. Deixar claro que, assim como todos decoraram os procedimentos executados antes, assim também eles irão decorar os novos procedimentos com a prática do dia a dia. 13. Esclarecer que a documentação do processo, quer seja física ou eletrônica, estará à disposição de todos para dirimir qualquer dúvida. 14. Deixar claro que os padrões de operação são os que estão na documentação do processo e não os que forem eventualmente passados pela “rádio peão”. 15. Acompanhar cada ator nos primeiros dias da “estreia do processo”, pois isso vai lhes transmitir segurança para representar os novos papéis. 16. Não permitir que as discussões sobre o que funcionará e o que não funcionará, ou sobre o que necessita ser modicado ou não, se deem de forma particular. 17. Pedir que as questões sejam discutidas nas reuniões públicas para a “leitura do processo”. A principal preocupação com a abordagem listada antes é a de envolver corretamente os atores organizacionais, a m de que eles participem o tempo todo comprometidos com seus papéis, evitando-se que se sintam sem saber como e por que estão participando do projeto.

O Analista de Workflow O perl do analista de Workow a rigor não envolve a formação detalhada nem especializada em processos, levantamento, documentação, melhoria e reengenharia de processos de negócio, mas uma formação voltada à parametrização e à programação dessa classe de ferramenta. Em outras palavras, o analista de Workow precisa ser especializado numa ferramenta de Workow. Ele deverá, também, conhecer os princípios do modelo WfMC, que servirão de subsídios ao seu trabalho de automatizar processos por meio desta classe de software. Entretanto, o analista de Workow deverá ter uma sólida formação matemática e em lógicas, uma vez que tanto parametrizar quanto programar sof-

Analistas 223

twares desta classe exige do analista de Workow uma visão extremamente lógica do trabalho que ele, analista, está fazendo dentro da ferramenta. A lógica nem sempre será a clássica, mas uma mistura de várias lógicas, dependendo da utilização que o prossional vier a necessitar para representar os processos de negócio no software de Workow. O nível necessário de detalhamento da documentação que será usada pelo analista o terceiro nível, mas o mapeamento será objeto do trabalho de do Workow analista deé processos.

O Analista de BPMS Este papel funcional é composto de conhecimentos, competências e habilidades encontrados nos seguintes papéis funcionais: analista de processos de negócio e analista de Workow. Enquanto o papel funcional de analista de processos de negócio está mais voltado à organização, ao desenho, ao redesenho, à análise e à modelagem dos processos, o papel de analista de Workow está diretamente ligado ao conhecimento sobre tecnologias da informação, principalmente as emergentes, seus componentes e de como programá-las, parametrizá-las e implantá-las corretamente.

O Arquiteto de SOA (SOA Architect) Muito provavelmente você ainda não ouviu falar, nem leu nada, sobre SOA e muito menos sobre o arquiteto do ambiente Service-Oriented Architecture. Não se preocupe – e se você não é da área de TI preocupe-se menos ainda, pois muitos prossionais da nossa área sequer estão preocupados com a adoção do SOA por parte das suas organizações e, por isso, ainda nem pensam em criar o papel funcional já existente em muitas organizações nos Estados Unidos. O crescimento da importância de TI nas organizações fez surgir a preocupação por uma disciplina que os americanos chamam de Enterprise Architecture Planning. O EAP é basicamente o projeto, o planejamento e a implantação das Tecnologias da Informação, principalmente as de novíssima geração, como a BPMS e seus componentes. Para atender à demanda oriunda deste processo, no qual a tecnologia SOA é uma das mais impor-

224 BPM & BPMS

tantes e porque para implantarmos uma arquitetura como SOA precisamos estar atentos para a dinamicidade imposta às organizações pela economia mundial, é que surgiu um novo prossional: o arquiteto de SOA. O arquiteto de SOA tem por função principal criar o mapa do caminho (road map), o projeto que irá permitir à organização interligar com segurança e exibilidade processos executados em segundo plano com processos executados em primeiro plano, e estes aonecessitando negócio da organização. Por isso, otenha perl do arquiteto de SOA é complexo, que este prossional ou desenvolva sólidos conhecimentos organizacionais e tecnológicos. O SOA Architect antes de qualquer outra tarefa necessita resolver conitos oriundos das necessidades organizacionais que provocam mudanças na infraestrutura de TI e nas aplicações, não raro chegando a mudar a própria arquitetura SOA, para permitir à organização acompanhar o dinamismo dos mercados onde ela atua. Como a arquitetura SOA se encarrega cada vez mais de processos de missão crítica, o arquiteto de SOA precisa conhecer entre outros os seguintes padrões:

Segurança.

ITENS

PADRÕES SSL, WS-Security, XML Encryption, XML Signature.

Roteamento de mensagens.

WS-Addressing.

Conabilidade.

WS-ReliableMessaging.

Integridade das Transações.

WS-Transaction.

Monitoramento e gerenciamento do ambiente SOA.

SNMP, WS-DistributedManagement.

Balanceamento de carga. Provisionamento.

WS-Addressing, SPML. WS-Provisioning.

Tabela 8.1 – Itens e padrões SOA.

Analistas 225

O arquiteto de SOA terá por responsabilidade ser o gestor da governança dos serviços Web, cuidando para que estes estejam alinhados ao negócio e ajustados às necessidades da organização.

Conhecimentos e Competências Muito lido e ouvido sobre conhecimento, gerência do temos conhecimento, sobre competências, suasespecialmente duas escolas, sobre a americana e a europeia, e sobre habilidades. Embora não seja um livro sobre esta tríade, achei interessante colocar aqui esta contribuição sobre a formação destes novos papéis. O que são competências? Rogério Valle et al (2003) dene competências como: A capacidade do trabalhador de ativar a cultura técnica de sua comunidade de trabalho para interpretar as inúmeras informações provenientes do contexto físico, social e subjetivo, sob a forma de sinais e signos, verbais (p.ex., frases, durante diálogos sobre questões técnicas ou gerenciais) ou não (p.ex., sinais provenientes de uma máquina).

Para Zarian, um dos maiores estudiosos do tema: Por competência, compreendemos a inteligência individual e coletiva das situações trazidas pelos eventos, consideradas no conjunto de sua complexidade.

Sendo Analista de Processos, Analista de Workow, Analista de BPMS, Arquiteto de SOA novos papéis funcionais, nascidos das novas metodologias e tecnologias da informação ligadas a processos de negócio, é imperioso encontrarmos ou formarmos corretamente prossionais para exercerem estes novos papéis. O quadro sinóptico apresentado logo a seguir é apenas uma ideia, passível e necessariamente aberto a mudanças. Está aqui para ensejar uma discussão e não para ser dado como denitivo.

226 BPM & BPMS

Papéis Funcionais Analista / Arquiteto PROC

WKFL

BPMS

SOA

CONHECIMENTOS Planilhas eletrônicas Editores de textos

I

I

I

I

I

Técnicasdeorçamentação

I

I

I

I

D

I

D

Gerência de processos

I

I

I

I

Gerência de projetos

I

N

I

D

Lógica formal

D

Lógica booleana

D

Lógicas multivaloradas

I

I I

N

Língua pátria

I I

I

I

I I

I

I

I

I

Inglês

I

I

I

I

Espanhol

D

D

D

D

Bancos Dados de

N

I

Telecomunicações

I

N

Riscos laborais

I

D

D

D

N

I

D N

LER

I

N

I

N

Qualidade

I

N

I

N

5S

N

N

I

N

Noçõesdelegislaçãoambiental Noçõesdelegislaçãotrabalhista Noçõesdesistemasdaqualidade Gestão econômica

I

I

N

I

N N I

Gestão nanceira Linguagensdeprogramação

N I

N

I

I

N

I

N N I

N I

N I

I

N I

Analistas 227


WKFL

BPMS

SOA

CONHECIMENTOS Linguagens BPMS

N

I

I

I

Tecnologia WEB

N

I

I

I

I

I

I

I

COMPETÊNCIAS Visão Sistêmica Orientação para o Desenvolvimento Pessoal

I

DisposiçãoparaNegociação

N

I

I

N

N

I

N

Visão Multifuncional

I

N

I

N

Raciocínio Lógico

I

I

I

I

Relações interpessoais

I

Trabalho em grupo

N

I

I

D

Capacidade analítica

N

I

I

D

I

I

I

Capacidade de síntese

I

N

I

N

Capacidade de planejar

I

I

I

I

Capacidade de organizar

I

I

I

I

Gestão crise de

I

N

I

N

Gestão tempo de

I

I

I

I

Capacidade de abstrair

I

I

I

I

Promover mudanças

I

N

I

D

Gerenciar mudanças

I

N

I

D

Comunicação oral

D

D

D

D

Comunicação escrita

I

D

I

D

228 BPM & BPMS


WKFL

BPMS

SOA

I

D

I

D

HABILIDADES Proatividade Controle emocional

I

I

I

I

Controle de crises

I

N

I

D

Controle de tempo

I

D

I

D

Adequação técnica

D

I

I

I

Aprendizagem

I

I

I

I

Melhoria contínua Orientado resultados a

I

I

I

I

D

I

I

D

Assumir compromissos

I

I

I

I

Assumir responsabilidades

I

I

I

I

Autocontrole

I

I

I

I

I = imprescindível / D = desejável / N = não aplicável Quadro sinóptico Conhecimentos – Competências – Habilidades.

Palavras Finais

Seja qual for a necessidade que tivermos por qualquer tecnologia, tanto na vida prossional como na vida pessoal, devemos nos lembrar antes, e sempre, de que nenhuma poderá fazer por nós algo que, competência básica, nós mesmos teremos que desenvolver: organização. Não é algo fácil! Requer de nós um esforço muito grande, pois teremos que conviver sempre com a Desorganização Informacional (DoI) sem qualquer possibilidade desta “enfermidade” ser curada. No máximo ela poderá ser controlada, assim como tantas outras enfermidades organizacionais. Portanto, novas ou velhas Tecnologias da Informação apenas podem ser boas ou más coadjuvantes dependendo do uso que viermos a fazer delas. Neste livro tratei de várias das mais novas tecnologias: Business Process Management System, Workow, EAI, SOA entre outras, mas nenhuma delas fará milagres, embora a indústria de TI queira nos fazer acreditar que isto é possível. Para fundamentar minhas ideias sobre tecnologias escrevi uma breve história de TI, como forma de contextualizar as novas tecnologias apresentadas neste livro. Volto a armar que tecnologias não são nem boas nem más. Não há e nem deve haver maniqueísmo quando discutimos algo que nasce para ser bom ou ruim, dependendo do uso que nós viermos dar a isto. Assim é com TI.

230 BPM & BPMS

Um exemplo de tecnologia que nasce para ser boa ou ruim é a energia nuclear, antes tão temida (e ainda continua sendo) e tão combatida (agora o é somente pelos ambientalistas preocupados com o lixo atômico), que reaparece como uma das armas para combater o aquecimento global, defendida por cientistas sérios, como Lovelock 83 (não confundir com o escritor americano HP Lovecraft) e, entretanto, a humanidade jamais esquecerá Hiroshima e Nagasaki. Estou certo de ter conseguido apresentar minhas ideias sobre as novas tecnologias sem paixões ou ideias preconcebidas. Gostaria que este livro servisse de base a quem precisa, defende, ataca ou simplesmente quer conhecer Business Process Management e Business Process Management Systems e que as discussões continuassem, fundamentalmente, como forma de termos várias verdades sobre tecnologias emergentes como as apresentadas aqui.

83. James Lovelock: cientista independente, ambientalista, autor e pesquisador, Doutor Honoris Causa de várias universidades no se mundo ele éna considerado décadas como um dos principais ideólogos e líderes, não ointeiro, principal, história dohá desenvolvimento da consciência ambiental. James Lovelock é o autor da “Teoria da Gaia”, que considera o planeta Terra como um ser vivo capaz de se automanter, assim como “As Idades de Gaia” e sua “Homenagem a Gaia”, uma autobiograa publicada em setembro de 2001. Mais recentemente, o professor Lovelock publicou seu novo livro, “A Vingança de Gaia”. James Lovelock é a favor do uso da energia nuclear limpa que respeita o meio ambiente: leia a introdução por James Lovelock ao livro “Ambientalistas a favor da Energia Nuclear”. Ele apoia a Associação de Ambientalistas A Favor da Energia Nuclear (EFN).

Anexo I

Principais Fabricantes de BPMS

A seguir são apresentados os principais “fabricantes” de Business Process Management System existentes no início de 2008. Adobe Systems’ Adobe LiveCycle Workow

Adobe Systems, 345 Park Avenue,Inc. San Jose, CA 95110 Tel: 408 536-6596 Web: www.adobe.com; Email: [email protected]; Appian Corp.’s Appian Enterprise Appian Corporation 8000 Towers Crescent Drive, 16th Floor, Vienna, Virginia 22182 Tel: (703) 442 8844 Fax: (703) 442 8919 Web: www.appiancorp.com; Email: [email protected]; Ascentn Corp.’s AgilePoint Ascentn Corporation 1674 N. Shoreline Blvd, Suite 136, Mountain View, CA 94043 Tel: 650-968-6789 Fax: 650-968-6785 Web: www.ascentn.com; Email: [email protected]

232 BPM & BPMS

BEA Systems Inc.’s BEA AquaLogic BPM Suite BEA Systems, Inc. 2315 North First Street San Jose, CA 95131 Tel: 408 670-8901 Web: www.bea.com; Email: [email protected] B2Binternet’s XicoBPM B2Binternet, Inc. 9, Il-dong B/D, #968, Daechi3-dong, Kangnam-gu, Seoul, Korea (135-736) Tel: +82 2 550 7209 Web: www.xicobpm.com Chordiant Software, Inc.’s Chordiant Enterprise Platform 3 Chordiant Software, Inc. 20400 Stevens Creek Blvd., Cupertino, CA 95014 Tel: Tel: 408-517-6168 Fax: 408-517-5032 Web: www.chordiant.com; Email: [email protected] Clear Technology’s Tranzax Case Handler Clear Technology Inc. 11030 Circle Point Road, Westminster, CO 80020 Tel: (303) 583 4100 Fax: (303) 449 1548 Web: www.clear-technology.com; Email: [email protected] eg Solutions Ltd.’s eg work manager eg Solutions Limited The Roller Mill, Teddesley Road, Penkridge, Staffs, ST19 5BD, UK Tel: +44 (1785) 715772 Fax: +44 (1785) 712541 Web: www.eguk.co.uk; Email: [email protected] Global 360, 360’sInc. Global 360 Enterprise BPM Suite Global 2911 Turtle Creek Blvd., Dallas, TX 75219 Tel: 214 445-4100 Fax: 214 219-0476 Web: www.global360.com; Email: [email protected]

Anexo I – Principais Fabricantes de BPMS 233

Graham Technology’s GT Product Sui te Graham Technology India of Inchinnan, Renfrewshire, Scotland, PA4 9LH, UK Tel: +44 (141) 533 4000 Fax: +44 (141) 533 4199 Web: www.grahamtechnology.com; Email: [email protected] HandySoft Global Corp.’s BizFlow HandySoft Global Corporation 1952 Gallows Road, Suite 100, Vienna, VA 22182 Tel: (703) 442-5600 Fax: (703) 442-5650 Web: www.handysoft.com; Email: [email protected] IBM’s FileNet Business Process Manager IBM Corporation 3565 Harbor Blvd, Costa Mesa, CA 92626-1420 Tel: 714-327-3400 or 1-800 FILENET Web: www.ibm.com IBM’s WebSphere Business Process Management IBM Corporation Route 100, Somers, New York 10589 Check IBM site for phone and fax numbers in your area. Web: www.ibm.com/contact/us/ Metastorm Inc.’s Metastorm BPM Metastorm, Inc. 500 E. Pratt Street, Suite 1250 Baltimore, MD 21202 Tel: +1 443-874-1300 Web: www.metastorm.com Email:[email protected]; M1 Global Solutions, Inc.’s Business Convergence M1 Global Solutions, Inc. 5775 Glenridge Drive NE, Building E, Suite 400, Atlanta, GA 30326 Tel: 770-250-0349 Web: www.m1global.com; Email: [email protected];

234 BPM & BPMS

Oracle Corp.’s Oracle BPEL Process Manager Oracle Corporation Oracle Parkway, Redwood Shores, CA 94065, USA Tel: 1.800.ORACLE1 or +1.650.506.7000 Web: www.oracle.com PegaSystems, Inc.’s Pegasystems SmartBPM Suite Pegasystems, Inc. 101 Main St Cambridge MA, 02142-1590 Tel: 617-374-9600 Fax: 617-374-9620 Web: www.pega.com; Email: [email protected]; Singularity’s Singularity Process Platform Singularity th 11 Penn Plaza, 5 Floor, New York, NY 10001 Tel: +1 (212) 946 2685 Fax: +1 (212) 946 2808 Web: www.singularity.us.com; Email: [email protected]; TIBCO Software Inc.’s TIBCO iProcess Suite TIBCO Software Inc. 3307 Hillview Avenue, Palo Alto, CA 94304 Tel: (650) 846-5637 Fax: (650) 846-1005 Web: www.tibco.com Email: [email protected] webMethod Inc.’s webMethods Fabric webMethods, Inc. 3877 Fairfax Ridge Road, South Tower Fairfax, VA 22030 Tel: 703-460-2500; Fax: 703-460-2599 Web: www.webmethods.com; Email:[email protected] WorkpointLLC LLC’s Workpoint, Version 3.4 (formerly ACI Worldwide) Workpoint 407 N. 117, Omaha, NE 68154 Tel: 402 964-1996 Fax: 402 964-1966 Web: www.workpoint.com; Email: [email protected]

Anexo II

BPMS

Em junho de 2005 the Business Process Management Initiative (BPMI.org) e the Object Management Group™ (OMG™) anunciaram a fusão das suas respectivas atividades de desenvolvimento de padrões do Business Process Management. Esta junção foi batizada de Business Modeling & Integration (BMI) Domain Task Force (DTF). Business Modeling Specications, transcrito a seguir, foi extraído do site do

Business Process Management Initiative (BPMI.org) em fevereiro de 2008. Os documentos aqui referenciados ou foram publicados denitivamente como referências ou estão em fase de validação para posterior publicação denitiva.

Cabe aqui uma explicação sobre o porquê da publicação deste documento. Decidi colocá-lo aqui para facilitar a vida dos leitores que não têm acesso à Internet via cabo. Desta forma eles poderão escolher previamente os endereços que vão querer consultar, evitando perda de tempo quando conectados via linha telefônica discada. A coluna “acronym” serve para localizar a estrutura de diretório no servidor de documentação do The Object Management Group (OMG).

236 BPM & BPMS

Business Modeling Specications SPECIFICATION

Acronym

Topical area / domain

Version

Document #

Business Motivation Model

BMM

business process design

1.0 Beta 3

dtc/2007-08-03 n/a

Business Process BPDM Denition Metamodel


1.0 Beta 1

dtc/2007-07-01 n/a

Business Process Maturity Model

BPMM


1.0 Beta 1

dtc/2007-07-02 n/a

Business Process Modeling Notation

BPMN


1.1 Beta 3

dtc/2007-06-03 1.0

Production Rule Representation

PRR


submission adopted

TBA

SBVR

business process semantics

1.0 Beta 3

dtc/2007-09-10 n/a

WfMF

crossdomain

1.2

formal/ 2000-05-02

n/a

Semantics of Business Vocabulary and Business Rules Workow Management Facility

Past versions

n/a

Middleware Specications CORBA/IIOP Specications SPECIFICATION

Acronym


Version

Document #

Past versions

Common Object Request Broker Architecture (CORBA/IIOP)

CORBA

middleware

3.1

formal/ 2008-01-04

3.0.3

CORBA/e

CORBAe

Specialized CORBA

Anexo II – BMS 237

SPECIFICATION

Acronym


Version

Document #

Past versions

Common Secure Interoperability

CSIv2

security, middleware

3.0.3

Chapter 24 of CORBA/IIOP 3.0.3

Chapter 26 of CORBA/ IIOP 2.6

CORBA Component

CCM

Model

middleware,

4.0

components

formal/ 2006-04-01 formal/ 2006-05-03

3.0

CORBA Reection

RFLEC

middleware

1.0

CORBA-FTAM/FTP Interworking

FTAM

middleware

1.0

formal/ 2002-03-13

n/a

CORBA / TC Interworking and SCCPInter ORB Protocol

SCCP

middleware

1.0

formal/ 2001-01-01

n/a

CORBA-WSDL/ SOAP Interworking

C2WSDL

middleware

1.2

formal/ 2006-04-01

1.1

DEPL

middleware

4.0

formal/ 2006-04-02

n/a

FT

middleware

3.0.3

Chapter 23 of CORBA/IIOP 3.0.3

Chapter 25 of CORBA/ IIOP 2.5 n/a

Deployment and Conguration of Component-based

n/a

Distributed Applications Fault Tolerance

Interworking between CORBA and TMN TMN Systems

middleware, telecommuni- 1.0 cations

formal/ 2000-08-01

Online Upgrades

ONUP

middleware

1.0 Beta 2

ptc/2003-08-07 n/a

Quality of Service for CCM

QOSCCM

middleware, components

1.0 Beta 2

ptc/2007-08-14 n/a

Streams for CORBA Components

STRM

middleware, components

1.0 Beta 2

ptc/2005-07-01 n/a

UML Prole for CORBA

CORP

UML Proles

UML Prole for CCM

CCMP

UML Proles

UML Prole for CORBA and CCM

CCCMP

UML Proles

238 BPM & BPMS

SPECIFICATION

Acronym


Wireless Access and Terminal Mobility in CORBA

WATM

middleware, telecommuni- 1.2 cations

WSDL2C

middleware

Version

WSDL/SOAPCORBA Interworking

1.0

Document #

Past versions

formal/ 2005-05-02

1.1

formal/200404-01

n/a

Data Distribution Service (DDS) Specications SPECIFICATION

Acronym


Version

Document #

Past versions

Data Distribution Services

DDS

real-time, middleware

1.2

formal/ 2007-01-01

1.1

DDS Interoperability Protocol

DDSI


2.0 Beta 2

ptc/2007-06-04 n/a

Specialized CORBA Specications SPECIFICATION

Acronym


Version

Document #

Past versions

CORBA/e (aka Minimum CORBA)

CORBAe


1.0 Beta 1

ptc/2006-08-03 n/a

Data Parallel Processing

DPP


1.0

formal/ 2006-01-03

n/a

Lightweight CCM (CORBA Component Model)

LtCCM

(incorporated in CCM Specication)

Lightweight Load Balancing

LtLOAD


1.0 Beta 1

ptc/2007-08-11

n/a

Lightweight Logging Service

LtLOG


1.1

formal/ 2005-05-02

1.0

Lightweight Services

LtSVCS

CORBAservices

OnlineUpgrades

ONUP

CORBA/IIOP


SPECIFICATION

Acronym


Version

Document #

Past versions

Real-time CORBA

RT


1.2

formal/ 2005-01-04

1.1

1.0 Beta 1

ptc/ 2003-01-11

n/a

UML Prole for Modeling and Analysis of Real-time and MARTE

UML Proles

Embedded Systems UML Prole for QoS and Fault Tolerance

QFTP

UML Proles

UML Prole for Schedulability, Performance and Time

SPTP

UML Proles

UML™ Prole for UML Prole for System on a Chip

SoCP

UML Proles

Unreliable Multicast

UMUL


Language Mapping Specications IDL / Language Mapping Specications SPECIFICATION

Acronym


Version

Document #

Past versions

Ada

ADA

software development

1.2

formal/ 2001-10-42

1.1

C

C


1.0

formal/ 99-07-35

n/a

C++

CPP


1.1

formal/ 2003-06-03

1.0

COBOL

COBOL

CORBA Scripting Language

SCRPT

software development software development

1.0 1.1

formal/ 99-07-47 formal/ 2003-02-01

n/a 1.0

IDLtoJava

I2JAV


1.2

formal/ 2002-08-05

1.1

JavatoIDL

JAV2I


1.3

formal/ 2003-09-04

1.2

240 BPM & BPMS

SPECIFICATION

Acronym


Version

Document #

Past versions

Lisp

LISP


1.0

formal/ 2000-06-02

n/a

MOF2I


2.0

formal/ 2006-01-02

1.4

PL/1

PL1


1.0

formal/ 2002-09-05

n/a

Python

PYTH


1.2

formal/ 2002-11-05

1.0

Smalltalk

ST


1.0

formal/ 99-07-65

n/a

XML

XML


1.1

formal/ 2003-04-01

1.0

Past versions

MOF2toIDL

Other Language Mapping Specications SPECIFICATION

WSDLtoC++

acronym

WS2CPP


Version

Document #


1.0 Finalization Report plus 1.0 Beta 1

ptc/200706-01and n/a ptc/2006-08-01

Modeling and Metadata Specications UML, MOF, CWM and XMI Specications SPECIFICATION

Acronym


Version

Document #

Past versions

Common Warehouse CWM Metamodel

data warehousing, 1.1 modeling

formal/ 2003-03-02

1.0

CWM Metadata InterMIPS change Patterns

data warehousing, 1.0 modeling

formal/ 2004-03-25

n/a

Meta-Object Facility Core

modeling

formal/ 2006-01-01

1.4

MOF

2.0


SPECIFICATION

Acronym


Version

Model-level Testing and Debugging

MLTD

modeling

1.0Beta1

MOF Model to Text Transformation Language

MOFM2T

modeling

1.0

MOF Query / Views / Transformations

QVT

modeling

1.0Beta2

MOF 2 Facility and Object Lifecycle

MOFFOL

modeling

submission adopted

TBA

MOF 2 Versioning and Development Lifecycle

MOFVD

modeling

1.0 Finalization Report

ptc/2006-06-05 n/a

Object Constraint Language

OCL

modeling

2.0

formal/ 2006-05-01

OMG Systems Modeling Language

SysML

domain, modeling

Ontology Denition Metamodel

ODM

modeling

1.0Beta2

Reusable Asset Specication

RAS

modeling

2.2

formal/ 2005-11-02

n/a

Software Process Engineering Metamodel

SPEM

modeling

1.1

formal/ 2005-01-06

1.0

Document #

Past versions

ptc/2007-05-14 n/a formal/ 2008-01-16

n/a

ptc/2007-07-07 n/a n/a

n/a

ptc/2007-09-09 n/a

Unied Modeling Language -Infrastructure

UML

modeling

2.1.1

formal/ 2007-02-06

2.0

-Superstructure

UML

modeling

2.1.1

formal/ 2007-02-05

2.0

UML Diagram Interchange UML Human-Usable Textual Notation XML Metadata Interchange

UMLDI

modeling

1.0

HUTN

modeling

1.0

XMI

modeling

2.1.1

formal/ 2006-04-04 formal/ 2004-08-01 formal/ 2007-12-01

n/a n/a 2.1

242 BPM & BPMS

UML Prole Specications SPECIFICATION

acronym

OMG Systems ModeSysML ling Language

topical area / domain

Version

Document #

Past versions

domain, modeling middleware,

UML Prole for CCM

CCMP

components, modeling

1.0

formal/ 2005-07-06

UML Prole for CORBA and CCM

CCCMP

middleware, components, modeling

1.0 Beta 3

ptc/2007-05-03 n/a

UML Prole for DoDAF and MODAF

UPDM

domain, modeling

1.0 Beta 1

dtc/2007-08-02 n/a

UML Prole for Enterprise Application Integration

EAI

domain, modeling

1.0

formal/ 2004-03-26

n/a

UML Prole for Enterprise Distributed Object Computing

EDOC

domain, modeling

1.0

formal/ 2004-02-01

n/a

UML Prole for Modeling and Analysis of MARTE Real-time and Embedded Systems


1.0 Beta 1

ptc/2007-08-04 n/a

UML Prole for QoS and Fault Tolerance

QFTP

real-time, middleware, modeling

1.0

formal/ 2006-05-02

n/a

UML Prole for Schedulability, Performance and Time

SPTP


1.1

formal/ 2005-01-02

1.0

UML Prole for System on a Chip

SoCP


1.0.1

formal/ 2006-08-01

1.0

UML Prole for Software Radio

softwareSDRP

based communications

1.0

formal/ 2007-03-01

n/a

n/a

UML Prole for Voice VOICP

telecommuni1.0 Beta 2 cations

ptc/2007-07-03 n/a

UML Testing Prole

modeling

formal/ 2005-05-07

TESTP

1.0

n/a


Modernization Specications SPECIFICATION

Acronym


Version

Document #

Past versions

Knowledge Discovery Metamodel (KDM)

KDM

modeling

1.0

formal/ 2008-01-01

n/a

Platform Independent Model (Pim), Platform Specic Model (Psm) and Interface Specications CORBAservices Specications Topical are a / domain

Version

Document #

Past versions

Additional Structuring Mechanisms for the OTS OTS

transaction mgmnt, middleware

1.1

formal/ 2005-01-01

1.0

Collection Service

COLL

collection mgmnt, middleware

1.0.1

formal/ 2002-08-03

1.0

Concurrency Service

CONC

object consistency, middle- 1.0 ware

formal/ 2000-06-14

n/a

Enhanced View of Time

EVoT

time mgmnt, middleware

1.2

formal/ 2004-10-04

1.1

EventService

EVNT

event mgmnt, 1.2 middleware

formal/ 2004-10-02

1.1

Externalization Service

EXT

object state mgmnt, middleware

1.0

formal/ 2000-06-16

n/a

Licensing Service

LIC

software licensing, middleware

1.0

formal/ 2000-06-17

n/a

Life Cycle Service

LFCYC

SPECIFICATION

Acronym

Lightweight Services

LtSVC

Management of Event Domains

MED

object life cycle mgmnt, middleware resources constraints

1.2 1.0


formal/ 2002-09-01 formal/ 2004-10-01 formal/ 2001-06-03

1.1 n/a n/a

244 BPM & BPMS

SPECIFICATION

Acronym

Topical are a / domain

Version

Document #

Past versions

Naming Service

NAM

object location mgmnt, middleware

1.3

formal/ 2004-10-03

1.1

Notication Service

NOT


formal/ 2004-10-11

1.0.1

Notication / JMS Interworking

NOTJMS


formal/ 2004-10-09

n/a

Persistent State Service

PSS

object persistence, middleware

2.0

formal/ 2002-09-06

replaces Persistent Object Service

Property Service

PROP

object properties, middle1.0 ware

formal/ 2000-06-22

n/a

QueryService

QUER

collection mgmnt, middleware

1.0

formal/ 2000-06-23

n/a

Relationship Service

REL

object relationships, middleware

1.0

formal/ 2000-06-24

n/a

Security Service

SEC


1.8

formal/ 2002-03-11

1.7

Telecoms Log Service

TLOG

event mgmnt, 1.1.2 middleware

formal/ 2003-07-01

n/a

time mgmnt, middleware

1.1

formal/ 2002-05-06

1.0

TimeService

TIME

Trading Object Service

TRADE

object location mgmnt, middleware

1.0

formal/ 2000-06-27

n/a

Transaction Service

TRANS

transaction mgmnt, middleware

1.4

formal/ 2003-09-02

1.2.1

CORBAfacilities Specications SPECIFICATION

Acronym


Version

Document #

Past versions

Internationalization and Time

ITFAC


1.0

formal/ 2000-01-01

n/a

Mobile Agent Facility

MOBFAC


1.0

formal/ 2000-01-02

n/a


OMG Domain Specications SPECIFICATION

acronym


Version

Document #

Past versions

Air Trafc Control

ATC

transportation

1.0

formal/ 2000-05-01

n/a

AMSM

C4I

1.0 Beta 2

dtc/2007-05-02 n/a

Audio / Visual Streams

AVSTR

telecommuni1.0 cations

formal/ 2000-01-03

n/a

Bibliographic Query Service

BQS

life sciences research

1.0

formal/ 2002-05-03

n/a

Biomolecular Sequence Analysis

BSA


1.0

formal/ 2001-06-08

n/a

Business Motivation Model

BMM

Business Process Modeling

Application Management and System Monitoring for CMS Systems

Business Process BPDM Denition Metamodel


Business Process Maturity Model

BPMM


Business Process Modeling Notation

BPMN


Chemical Structure and Access Representation

CSAR


1.0

formal/200701-02

n/a

Clinical Observations Access Service

COAS

healthcare

1.0

formal/ 2001-04-06

n/a

Computer Aided Design Services

CAD

manufacturing

1.2

formal/ 2005-01-07

1.0

Conversion for Payment Models Message Standards

CM4PM

nance

submission adopted

TBA

n/a

Currency

CURR

nance

1.0

formal/ 2000-06-29

n/a

Data Acquisition from Industrial Systems

DAIS

manufacturing

1.1

formal/ 2005-06-01

1.0

246 BPM & BPMS

SPECIFICATION

acronym


Version

Document #

Past versions

Distributed Simulation Systems

DSIM

simulation

2.0

formal/ 2002-11-11

1.1

Gene Expression

GENE


1.1

formal/ 2003-10-01

1.0

General Ledger

LEDG

nance

1.0

formal/ 2001-02-67 formal/ 2002-02-01

n/a

GMAPS


1.0

Historical Data Acquisition from Industrial HDAIS Systems

manufacturing

1.0

IT Portfolio Management Facility

ITPMF

cross-domain 1.0 Beta 2

Laboratory Equipment Control Interface Specication

LECIS


1.0

formal/ 2003-03-19

n/a

Lexicon Query Service

LQS

healthcare

1.0

formal/ 2000-06-31

n/a

LSAE


1.0

GenomicMaps

Life Sciences Analysis Engine Life Sciences Identiers

LSI


Macromolecular Structure

MACSTR


Management of Event Domains

MED

CORBAservices

Metamodel for the Federal Transition Framework

FTF

Negotiation Facility

NEG

OMG Systems Modeling Language Party Management Facility Person Identication Service

SysML

formal/ 2005-06-02 dtc/2004-11-03

formal/ 2005-12-02

n/a n/a n/a

n/a

1.0

formal/ 2004-12-01

n/a

1.0

formal/ 2002-05-01

n/a

government

submission adopted

TBA

n/a

electronic commerce

1.0

formal/ 2002-03-14

n/a

domain,

PARTY

modeling nance

PIDS

healthcare

1.0

formal/

n/a

1.0

2007-09-01 formal/ 2001-02-68

n/a

1.1

formal/ 2001-04-04

1.0


SPECIFICATION

acronym


Platform Independent Model and Platform Specic Model for SDO Super Distributed Object

Embedded Intelligence

Product Data Management Enablers

manufacturing

PDME

Version

Document #

1.3

formal/ 2000-11-11

Past versions

1.2

Product Lifecycle Management Services

PLM

manufacturing

1.0.1

formal/ 2006-04-03

n/a

Public Key Infrastructure

PKI

electronic commerce, security

1.0

formal/ 2002-09-04

n/a

Resource Access Decision

RAD

healthcare, security

1.0

formal/ 2001-04-01

n/a

Robotic Technology Component

RTC

robotics software development

1.0 Beta 2

ptc/2007-08-18 n/a

1.0

formal/ 2005-11-01

n/a

1.0

formal/ 2003-03-62

n/a

formal/ 2000-05-03

n/a

formal/ 2002-12-01

n/a

Semantics of Business Vocabulary and Business Rules Single Nucleotide Polymorphisms

SBVR SNP

Business Process Modeling life sciences research

Surveillance User Interface

SURV

Systems Modeling Language

see OMG Systems Modeling Language

Task and Session

TSKSES

transportation

cross-domain 1.0

Telecoms Log Service

TLOG

CORBAservices

Telecom Service & Access Subscription

TSAS

telecommuni1.0 cations

UML Prole for DoDAF and MODAF

UPDM

UML Proles

UML Prole for Enterprise Application Integration

EAI

UML Proles

UML Prole for Enterprise Distributed Object Computing

EDOC

UML Proles

248 BPM & BPMS

SPECIFICATION

acronym


UML Prole for Software Radio

SDRP

UML Proles

UML Prole for Voice VOICP

UML Proles

Utility Management Systems Data Ac-

UMS

utility management

WfMF


Version

Document #

Past versions

2.0.1

formal/ 2005-06-03

1.0

1.0

formal/ 2005-08-01

n/a

Document #

Past versions

cess Facility Workow Management Facility

XML Telemetric and XTCE Command Exchange

space

Corba Embedded Intelligence Specications Topical area / domain

Version

Platform Independent Model and Platform Specic Model for SDO Super Distributed Object

real-time, embedded systems

1.0

Smart Transducers

real-time, embedded systems

1.0

SPECIFICATION

Acronym

SMART

formal/2004-

n/a

11-01 formal/200301-01

n/a

CORBA Security Specications SPECIFICATION Authorization Token Layer Acquisition Service Common Secure Interoperability Security Service Public Key Infrastructure Resource Access Decision Facility

Acronym

Topical area / Version domain

Document #

Past versions

ATLAS


formal/200210-01

n/a

CSIv2

CORBA/IIOP

SEC

CORBAservices

PKI

Domain

RAD

Domain

1.0

Anexo III

Relação dos Vendedores de BPMS Acessada em Business Process Trends em 06 de fevereiro de 2008.

Abstracted, Inc.

Business Integration Technology, FEAC Institute

Ackinas ActivePoint Adaptive - OMG Member (C) Adeptia, Inc. Advanced Concepts Center (ACC) - OMG Member (I) Advent Global Solutions Agilium SA ALTAIR Appropriate Technology Transfer I Appian - OMG Member (I) Armstrong Process Group, Inc.OMG Member (I) Ascentn Ashan System AuraPortal Avolution

Inc. BusinessPort Business Rule Solutions, LLC - OMG Member (D)

Axway - OMG Member (D) BEA Systems -OMG Member(P) BISIL NA Inc. BizAgi Ltd Bluespring Software - OMG Member (D) Blueprint Software Systems Inc. Borland Software Corporation - OMG Member (C)

Data Access Technologies Inc - OMG Member (P) dotNet Framework Solutions DST Technologies, Inc. Dymond and Associates, LLC e-Serve AG ETL Solutions Ltd Evidant Corporation Excel Partner, Ltd.

CA - OMG Member (C) Captaris Cardiff Casewise - OMG Member (I) Castle Ventures LLC Cephas Consulting Corp. OMG Member (I) Clearview Software International Colabra Computronix Cornerstone Communications Cyberconn Software

FileNet Corporation Fillmore Technology Group, Inc. Fisher Electronics Pvt Ltd Fujitsu Computer SystemsOMG Member (P) FlowCentric Solutions USA Inc FrontRange Solutions Future Tech Systems, Inc. Graham Technology -OMG Member (I) Global 360 - OMG Member (I) Groiss Informatics GmbH Handysoft Global Corporation Harvard Computing Group Hendryx & Associates Holocentric - OMG Member (I) IBM - OMG Member (C) iCMG iDatix IDS Scheer - OMG Member (D) iGrafx - OMG Member (D) IKV++ Technologies AG ImageSource IMAGE Technology

250 BPM & BPMS INRIA - OMG Member (U) Intalio Interfacing - OMG Member (I) ITP Commerce ltd. inubit AG Kanbay Kaytek Computer Services Pvt Ltd Keen Computer KnowGravity Inc Solutions . - OMG Member (I) Liantis GmbH & Co. KG Lombardi - OMG Member (C) Maxite Network Co., Ltd. M1 Global - OMG Member (I) MEGA International -OMG Member (C) Meghan-Kiffer Press Merit Systems Private Limited Metastorm Method Maker Ltd Mi3 Incorporated microTOOL MID Enterprise Software Solutions GmbH - OMG Member (I) Mono-sys Co., Ltd. Netways Newgen Software New Vision Systems LLC No Magic, Inc. - OMG Member (C) Nobilis Software oose Innovative Informatik - OMG Member (I)Optimus

OMG Membership Level: C – Contributing D – Domain P – Platform I – Inuencing G – Government U – University T – Trial A - Analyst

Solutions Oriel Incorporated Patni Computer Systems PECTRA Technology, Inc. Pegasystems - OMG Member (I) PeopleForce Perr&Knight Pinnacle Group Worldwide PNMsoft Polymorph Technologies Pte. Ltd Portellus ProcessMind Polymita Technologies Prolify pulinco engineering ag QualiWare Red Rabbit Software Relativity Technologies -OMG Member (I) Risk Reward Limited Role Modellers Ltd RuleSphere International, Inc. Rummler-Brache Group Sankhya Technologies Private Limited - OMG Member (I) Santéon, Inc. Savvion - OMG Member (I) Select Business SolutionsOMG Member (I) ShareDynamics, Inc. SilverRoad Solutions Singularity Skelta Software SoftwareMining Soyatec

Sparx Systems - OMG Member (C) Starthis, Inc. Stelex Stradasoft Stratagenom Ltd. SystemicLogic Telelogic AB - OMG Member (C) TenFold Corporation The Salamander Organization Limited The Software Revolution, Inc. (TSRI) - OMG Member (P) The Spitre Group The Voyant Group- OMG Member (I) TIBCO Software, Inc. TietoEnator - OMG Member (T) TMI Solutions, Inc Visible Systems Corporation Visual Paradigm International Ltd. Web and Flo Pty Ltd Workpoint Workplains PVT. Limited

Xactium Limited -OMG Member (I) Xeeda Xpdian Zero Delta Center for Enterprise Alignment Zynium Corporation -OMG Member (T)

Anexo IV

Linguagens Generalistas BPMS Em agosto de 2001 foi criado o Notation Working Group (NWG) para desenvolver a notação que viria a ser conhecida como Business Process Modeling Notation (BPMN). Em novembro de 2002 é lançada a BPMN 0.9, ainda Draft84. Em agosto de 2003 o NWG lançou a primeira versão do BPMN (BPMN Draft). Working Em maioGroup de 2004 foi lançada versãopor denitiva Atualmente, o1.0 Notation (NWG) é composto mais de1.0. 60 membros que repsentam diversas empresas. Business Process Modeling Notation (BPMN), até 2008, já foi implantada em produtos de mais 30 empresas de software. Em junho de 2005 o Notation Working Group (NWG) e o Object Management Group (OMG) fundiram-se num unico organismo e a partir de então este grupo se encarrega de desenvolver a Business Process Modeling Notation ( BPMN). Também em 2005 o BPMI, Business Process Management Initiative (BPMI), um organismo sem ns lucrativos que se encarrega de desenvolver padrões para Business Process Management e Business Process Management System, juntou-se ao The Object Management Group (OMG) e anunciou que a partir de então trabalhariam juntas com o nome de Business Modeling & Integration (BMI) Domain Task Force (DTF). Business Process Modeling Notation (BPMN) é o novo padrão de indústria para modelar processos de negócio, uxos e web services (SOA).

Draft: rascunho, esboço, minuta; draft proposal = minuta de proposta de padronização = minuta de um projeto de proposta para padronização internacional em alguma área da ciência sugerida por uma organização nacional de padronização. Dicionário Eletrônico Michaelis. 84

252 BPM & BPMS

Na verdade Business Modeling & Integration (BMI) Domain Task Force (DTF) criou (ou continua criando) três linguagens para facilitar a adoção e o uso da Business Process Modeling Notation: •

•

•

(a) Business Process Modeling Notation (BPMN para desenho, redesenho, modelagem de processos de negócio. (a) Business Process Execution Language (BPML) para a execução de processos de negócio. (a) Business Process Query Language (BPQL) para execução e gerenciamento de processos e-Business.

O objetivo principal da Business Process Modeling Notation é o de prover uma notação clara e eciente para modelagem de processos a todos que de alguma forma venham a se envolver com o tema, quer sejam analistas de processos, quer sejam analistas de negócio, quer sejam arquitetos de SOA ou outros prossionais. Outra preocupação que os criadores da BPMN tiveram foi a de assegurar que linguagens XML, como a Business Process Execution Language for Web Services (BPEL4WS) e a Business Process Modeling Language (BPML) criadas para a execução de processos de negócio, fossem usadas e visualizadas por meio de uma notação única. Com estes objetivos nasceu a BPMN, com a incumbência de unicar várias iniciativas individuais antes existentes para desenho, redesenho, modelagem, simulação e automatização de processos para uso e integração de componentes Enterprise Application Integration, componentes Business to Business (B2B), Business to Customer (B2C) e para componentes ServiceOriented Architecture (SOA) em um único padrão. O maior diferencial dos padrões Business Modeling & Integration (BMI) Domain Task Force (DTF) com relação a quaisquer outros padrões é que eles foram desenvolvidos com sólida base matemática, o que os torna análogos à fundamentação matemática dos bancos de dados relacionais. Isto que os processos negócio criados, redesenhados esignica modelados com o padrãodeBPMN podem ser desenhados, imediatamente executados. Esta funcionalidade também faz da BPMN uma linguagem com o mesmo dinamismo da linguagem SQL/DDL85.

85

SQL/DDL Structured Query Language/Data Description Language.

Anexo IV – Linguagens Generalistas BPMS 253

Outro ponto importante a favor destes novos padrões é que tanto a BPML (BPMI.org) quanto a BPEL4WS (Microsoft, IBM, Oracle) foram submetidos à OASIS.org, que criou um comitê técnico para desenvolver a BPML com base nestas duas linguagens, comuns pela mesma raiz: a XML. Desta iniciativa surgiu o padrão WS-BPEL (Web Services – Business Process Execution Language). A OASIS.org (www.oasis-open.or é um consórcio global,desem ns lucrativos, que coordena as iniciativas g) para o desenvolvimento padrões para uso no e-Business, produzindo com isso Standards mundiais para segurança eletrônica, web services, XML, transações eletrônicas e interoperabilidade entre sistemas. Para que modelos web services possam ser criados com a Business Process Modeling Notation (BPMN) são necessários quatro estágios: 1. Desenhar o processo de negócio usando a BPMN. 2. Simular o processo desenhado a m de melhorá-lo antes da sua implantação. 3. Publicar o novo processo por meio da Business Process Execution Language (BPEL). 4. Criar e gerenciar os Web Services dentro dos uxos automatizados por meio do módulo Workow do Business Process Management System (BPMS). BPMN cria um diagrama do processo modelado, chamado Business Process Diagram (BPD). O BPD tem dois objetivos: a. Permitir que processos simples e complexos sejam naturalmente mapeados, para serem depois executados pela BPEL. b. Fazer o processo ser entendido por todos.

Elementos Business Process Diagram O conjunto básico da Business Process Modeling Notation(BPMN) para modelar um processo, além de simples, éfamiliar a qualquer analista de processos de negócio, pois é composto basicamente de elementos de uxograma.

254 BPM & BPMS

A gura A.1 mostra os elementos básicos para modelagem de processos na BPMN.

Figura A.1 - Elementos básicos para modelagem de processos na BPMN.

Para criar qualquer processo de negócio com a Business Process Modeling Notation (BPMN) é preciso modelar o evento que inicia a execução do uxo, o processamento que resulta deste evento e os resultados produzidos pelo processo. As regras de negócio e os desvios no uxo são modelados por

meio de gateways. Um gateway é similar ao símbolo de decisão usado em uxogramas com padrão ECMA86. Um processo pode conter subprocessos, que são mostrados no uxo principal por meio de outro Business Process

86

ECMA, European Computer Manufacturers Association.


Diagram (BPD) conectado ao uxo principal por meio de um hyperlink. Se um processo não contém, ou se decompõe em, subprocessos ele é considerado uma tarefa (task). A task é o mais baixo nível de qualquer processo na notação BPMN.

Para a Business Process Modeling Notation (BPMN) “um evento é algo que ocorre durante o desenrolar-se de um processo de negócio. Os eventos afetam o uxo do processo,

seus direcionamentos e resultantes e geralmente se transformam ou num disparador ou num resultado. Os eventos podem iniciar, interromper ou nalizar um processo”.

Figura A.2 – Notações BPMN para eventos simples.

A modelagem dos eventos na Business Process Modeling Notation (BPMN) é realizada por meio de três símbolos distintos, mostrados na gura A.2. a. Evento de início. b. Evento intermediário. c. Evento nal. Para representar eventos complexos, como Web Services e relações B2B, B2C, existem símbolos mais elaborados que representam processamentos mais complexos como, por exemplo, envio e recepção de mensagens, controle denatempos, regras de negócio, desvios e condições de erros, especicados gura A.3.

256 BPM & BPMS

Figura A.3 – Notações BPMN para eventos complexos.


Para a Business Process Modeling Notation (BPMN): “uma atividade é o trabalho realizado num processo de negócio. As atividades podem ser “atomic” (únicas) ou “non-atomic” (compostas). Os tipos de atividades que fazem parte do modelo de processo BPMN são: processo (process), subprocesso (sub-process) e tarefa (task)”.

Figura A.4 – Notações para atividades em BPMN.

BPMN e UML (Unied Modeling Language) podem, ambas, ser usadas para mapear processos de negócio que serão executados por um software BPMS (módulo Workow). Entretanto, a grande diferença entre as duas linguagens é que a UML não tem base matemática e, portanto, não dene um metamodelo do processo desenhado com o seu uso, como faz a BPMN. Para que qualquer metamodelo desenhado na UML possa ser testado é necessário deni-lo no Modelo MDA, Model Driven Architecture. BPMN é atende ao padrão BPML metamodelo de execução direta e, por isso, os processos denidos nesta linguagem não necessitam de qualquer passo adicional para serem testados.

Referências Bibliográficas APPLEGATE, L., CASH, J. e MILLS D.Q. Revolution in Real Time, Managing Information Technology in the 1990s. Boston: HBS Press, 1988. ARAÚJO, R., BAIÃO, F., CAPPELLI, C., IENDRIKEL, H., MAGALHÃES, A., NUNES, V., SANTORO, F. - Uma Estratégia Para Gestão Integrada de Processos e Tecnologia da Informação Através da Modelagem de Processos de Negócio em Organizações. NP2Tec – Núcleo de Pesquisa e Prática em Tecnologia e Departamento de Informática Aplicada – UNIRIO. Acessado em 02 de fevereiro de 2008. www.frb.br/ciente/BSI/BSI.UNIRIO.MAGALH%C3%83ES%20et%20al. F2%20.pdf ARGYRIS, C. Good Communication that Blocks Learning. Boston: Harvard Business Review, July-August 1994. ARTHUR, W. B. Increasing Returns and the New World of Business. Boston: HBS, 1996. BANNISTER, D. e FRANSELLA, F. Inquiring Man, The Theory of Personal Constructs. New York: Penguin, 1971. BARTLETT, C.A. e GHOSHAL, S. Changing the Role of the Top Management, Beyond Systems to People. Boston: HBS, 1995. BENNIS, W. e NANUS, B. Leaders: The Strategies for Taking Charge. New York: Harper & Row, 1985.

260 BPM & BPMS

BETTIS, R. e PRAHALAD, C.K. The Dominant Logic, Retrospective and Extension. Strategic Management Journal, 16, January 1995. BOITEUX, C. D. PERT / CPM / ROY e outras técnicas de programação e controle. São Paulo: Livros Técnicos e Cientícos Editora S.A., 1985. BOLAND, R.J., TENKASI, R.V. e TE’ENI, D. Designing Information Technology to Support Distributed Cognition. Organization Science, 5(3), August 1994. BROWN, S. L e EISENHARDT, K. M. The Art of Continuous Change, Linking Complexity Theory and Time-Paced Evolution in Relentlessly Shifting Organizations. Administrative Science Quarterly, 42(1), Mar 1997. BRUNER, J. Acts of Meaning, Boston: HBS Press, 1990. CAPRA, F. As conexões ocultas. São Paulo: Cultrix, 2002. CHAFFEY, D. Groupware, Workow and Intranets. Reengineering the Enterprise with Collaborative Software. Boston: Digital Press, 1998. CRUZ, Tadeu. Gerência do Conhecimento – Enterprise Content Management, 2ª edição. Rio de Janeiro: Editora E-Papers, 2007. CRUZ, Tadeu. Sistemas, Métodos & Processos, 2ª edição, 3ª reimpressão. São Paulo: Editora Atlas, 2003. CRUZ, Tadeu. Workow II, a tecnologia que revolucionou processos, 3ª edição. Rio de Janeiro: Editora E-Papers, 2005. CRUZ, Tadeu. Uso e Desuso de Sistemas de Workow: Por que as organizações não conseguem obter retorno, nem sucesso, com investimentos em projetos de Workow. Rio de Janeiro: Editora E-Papers, 2006. CRUZ, Tadeu. O Teatro Organizacional – construindo e implantando processos de negócio. Rio de Janeiro: Editora E-Papers, 2006. DAVENPORT, T. H, PRUSAK, L. Conhecimento Empresarial: Como as Organizações Gerenciam o seu Capital Intelectual. Rio de Janeiro: Campus, 1998. DAVENPORT, T. H, PRUSAK, L. They Know. Boston: HBS Press, 1998. DAVENPORT, T. H. Process Innovation. Boston: HBS Press, 1993. DAVIDOW, W.H. e MALONE. M.S. The Virtual Corporation. New York: Harper Collins, 1992.

Referências Bibliogracas 261

DERTOUZOS, M. A Revolução Inacabada. São Paulo:Editora Futura, 2002. DRUCKER, P.F. The Theory of Business. Boston: HBR, 1994. DRUCKER, P. F. Administrando em Tempos de Grandes Mudanças. São Paulo: Pioneira, 1995. FISCHER, L. Excellence in Practice. Lighthouse Point: Future Strategies, 1997. FISCHER, L. Workow Handbook 2006. Lighthouse Point: Future Strategies, 2006. FORD, N. From Information to Knowledge Management. Journal of Information Science Principles & Practice, 15(4,5), 1989. FREIBERGER, P., McNEILL, D. Fuzzy Logic - The Discovery of a Revolutionary Computer Technology and How It Is Changing Our World. New York: Touch stone, 1993. Fu-Ren L., Meng-Chyn Y. e Yu-Hua P.A generic structure for business process modeling. Business Process Management Journal; 2002, 8, 1; ABI/INFORM Global p19. GHOSHAL, S. e BARTLETT, C.A. Rebuilding Behavioral Context: A Blueprint for Corporate Renewal. Sloan Management Review, Winter 1996. HARMON, P. Business Process Change: A Manager’s Guide to Improving, Redesigning, and Automating Processes. Tampa: Morgan Kaufmann, 2002. HICKS, D. T. Activity-Based Costing for Small and Mid-Sized Businesses. New York: John Wiley & Sons, Inc. 1992. HOUAISS, A. Dicionário Houaiss da Língua Portuguesa. Rio de Janeiro: Editora Objetiva, 2001. HOUAISS, A. Dicionário Eletrônico Houaiss da Língua Portuguesa. Rio de Janeiro: Objetiva, 2001. KHAN, R. Business Process management: A practical guide. Tampa: Morgan Kaufmann, 2003. KHOSHAFIAN, S., BUCKIEWICZ, M. Introduction to Groupware, Workow and Workgroup Computing. New York: John Wiley & Sons, Inc. 1995. KOBIELUS, J. G. Workow Strategies. Foster City: IDG Books. 1997.

262 BPM & BPMS

LÉVY, P. As Tecnologias da Inteligência. São Paulo: Editora 34, 1993. MAY, M. Business Process Management: Integration in a web-enabled environment. London: Prentice Hall, 2003. MIERS, D. e HARMON, P. The 2005 BPM Suites Report. USA: Business Process Trends, 2005. MIERS, D. e 2005. HARMON, P. The 2006 BPM Suites Report. USA: Business Process Trends, MIERS, D. e HARMON, P. The 2007 BPM Suites Report. USA: Business Process Trends, 2005. MIERS, D. e HARMON, P. The 2008 BPM Suites Report. USA: Business Process Trends, 2005. MORGAN, G. Imagens da organização. São Paulo: Atlas, 1996. MORRIS, C.W. Foundations of the Theory of Signs. Chicago: University of Chicago Press, 1938. NADLER, D.A., SHAW, R.B. e WALTON, A.E. Discontinuous Change: Leading Organizational Transformation. San Francisco: Jossey-Bass, 1995. OULD, M. A. Business Process Management: A Rigorous Approach. Tampa: Morgan Kaufmann, 2005. RIEMP, G. Wide Area Workow Management. Creating Partnership for the 21st Century. London: Springer-Verlag, 1998. SCHÖN, D.A. The Reective Practitioner: How Professionals Think in Action. New York: Basic Books, 1983. STERNBERG, R. J. Successful Inteligence. New York: Simon & Schuster, 1996. STEWART, T.A., 1994. Intellectual Capital: The New Wealth of Organizations, New York: Doubleday, Boston: HBR, 1994. THOMAS W. MALONE, K. Organizing Business Knowledge: The MIT Process Handbook. Boston: The MIT Press, 2003. TICOLL, D. et al. Blueprint for the Digital Economy. New York: McGrow-Hill, 1998.

Referências Bibliogracas 263

VALLE, R. et al. O Conhecimento em Ação: novas competências para o trabalho no contexto da reestruturação produtiva. Rio de Janeiro: Relume Dumará, 2003. VALLE, R., BALDAN, R. et al. Gerenciamento de Processos de Negócio. São Paulo: Editora Érica, 2007. WfMC. TC-1002. Winchester: WfMC, 1999. WfMC. TC-1003 Workow Reference Model. Version 1.1. Whinchester: WfMC, 1995. WfMC. TC-1009 Workow Client Application APIs (WAPI), Whinchester: WfMC, 1999. WfMC. TC-1011 Terminology & Glossary. Whinchester: WfMC, 1999. WfMC. TC-1012 Workow Interoperability Specications. Whinchester: WfMC, 2000. WfMC. TC-1013 WAPI - Naming Conventions. Whinchester: WfMC, 1999. WfMC. TC-1015 Workow Audit Data Specications. Whinchester: WfMC, 1999. WfMC. TC-1016 Workow Process Denition Interchange. Whinchester: WfMC, 1999. WfMC. TC-1020 Workow Security Considerations - White Paper. Whinchester: WfMC, 2002. WfMC. TC-1022 A Common Object Model - Discussion Paper. Whinchester: WfMC, 2003. WfMC. Interoperability Wf-XML. Whinchester: WfMC, 2000. WfMC. Conformance to Interface Standards. Acessado em 08 de maio de 2005, no endereço www.wfmc.org/standards/conformance.htm. WfMC. InterWorkowApplication Model: The Designof Cross-Organizational Work ow Processes and Distributed OperationsManagement. Acessado em 08 de maio de 2005, no endereçowww.wfmc.org/standards/docs/Jsa2102.pd f. WHITE, T. et al. The Workow Paradigm. Alameda: Future Strategies,1994.

264 BPM & BPMS

WILLIAMSON, O.E. Markets and Hierarchies. New York: Free Press, 1975. WILLIAMSON, O.E. The Economic Institutions of Capitalism: Firms, Markets and Relational Contracting. New York: Free Press, 1985. YOON, K.P. AND NAADIMUTHU, G. “A make-or-buy decision analysis involving imprecise data”, International Journal of Operations & Production Management, Vol. 14 No. 2, pp. 62-9, 1994. Fontes eletrônicas de informações sobre Business Process Management e Business Process Management System

• Java 2 Platform, Enterprise Edition Connector Specication, 2000, Sun Microsystems, Inc. http://java.sun.com/j2ee/docs.html • Java Message Service API, 2000, Sun Microsystems, Inc. http://java.sun.com/ j2ee/docs.html. • Java™ 2 Standard Edition Platform (J2SE™), 2000, Sun Microsystems, Inc. http://java.sun.com/products. •2000, Java™ Service (JAAS ) 1.0 Specication, SunAuthentication Microsystems,and Inc. Authorization http://java.sun.com/security/jaas/doc. • Enterprise JavaBeans™ 2.0 Specication, Copyright 2001, Sun Microsystems, Inc. http://java.sun.com/j2ee/docs.html. • JDBC™ 2.0 API Specication, 1999, Sun Microsystems, Inc. http://java.sun. com/products/jdbc. • JDBC 2.0 Standard Extension API Specication, 1999, Sun Microsystems, Inc. http://java.sun.com/products/jdbc. • Phios - Business Process Management company. http://www.phios.com/ • RMI over IIOP 1.0.1 Specication, 2000, Sun Microsystems, Inc. http://java. sun.com/products/rmi-iiop. • The MIT Process handbook. http://ccs.mit.edu/ph/

Índice Remissivo

Símbolos & 173 (r)evolução 1, 23, 26 (r)evoluções 1, 3, 9, 15, 26, 27 (r)evoluções 3Rs 133, 157de TI 19, 59

A Ábaco 11, 14 administrativas 20 Aiken 13 Ambiente 153 ambiente 122 AMOP 88, 126, 156, 157, 160, 164, 172, 174, 178, 179, 180, 220 analisar 127, 180, 181 Análise 157 análise 9, 20, 40, 45, 46, 49, 65, 68, 69, 70, 84, 89,164, 115,174, 118,177, 126,178, 129,180, 156,193, 158, 160,88, 162, 205 Analista 222, 223 analista 218, 219, 220, 221, 222, 223 Analista de BPMS 225 analista de BPMS 9 Analista de Processos 225 analista de processos 9

Analista de Workow 225 analista de Workow 9 Analistas 215 analistas 27, 38, 215 analistas de processos 43 analistas de sistemas 25, 34 aparelhos 6 API 123 Aplicações 122, 123, 132, 140 aplicações 132, 154, 155 APQC 67 Architecture (SOA) 46 ARIIS 177 Arpanet 17 Arquiteto 223, 225 arquiteto 9, 223, 224 arquitetura SOA 224 ARQUIVO 41 arquivos 17, 41, 42, 44, 47 Atanasoff 13 Atividade 130 atividade 107, 108, 110, 111, 126, 127, 200 Atividades 200 atividades 108, 111, 112, 153, 167, 201, 216 automáticas 12 automatização 12, 114 automatizadas 12

266 BPM & BPMS

B

C

Babbage 13 Babilônia 11 background 149, 151, 152, 153, 166 Background & Foreground Processes 147 background processes 150 BAM 200

calcular 11 cálculo 11 Cashman 63 Champy 34 Ciclo 192, 198 ciclo 192, 208

bancos de dados 67 Bardeen 13 BI 20, 123, 155 Blackberry 60 BMPS 204 BPM 7, 9, 35, 50, 52, 64, 66, 67, 68, 70, 71, 73, 81, 83, 85, 88, 89, 90, 119, 120, 121, 122, 124, 126, 132, 134, 188, 190, 192, 193, 205 BPM (Business Process Management) 7 BPMI 85 BPML 154 BPMS 7, 9, 41, 50, 52, 68, 69, 70, 71, 72, 73, 74, 83, 84, 85, 86, 87, 88, 89, 90, 91,

ciência da computação 14 CII Honeywell Bull 25 CMM 177 Competências 225 Computação 23 computação 2, 5, 17, 24, 25, 26, 44, 58 computação comercial 15 computação distribuída 24 Computador 56, 60 computador 3, 5, 13, 16, 22, 23, 28, 29, 30, 31, 34, 42, 65 computador eletrônico 13 computador eletrônico digital 13 computador ENIAC 13

92, 95,110, 96, 97, 101, 106,114, 107,115, 108,93, 109, 111,98, 112, 113, 117, 118, 120, 121, 122, 123, 124, 125, 126, 128, 131, 132, 133, 134, 135, 136, 137, 138, 139, 145, 149, 153, 154, 155, 175, 182, 188, 189, 190, 191, 192, 199, 200, 202, 203, 205, 206, 209, 215, 217, 223 BPMS (Business Process Management System) 1 BPMS (Business Process Management Systems) 7 BPO 22, 183, 184, 185, 186, 187 Brattain 13 BUG 20 Bull 8, 26 Burroughs 13, 25, 26 Business 167 Business Process Management 8 Business Process Management System 8, 9, 21 Business Process Management Systems 15 buzzwords 15

Computadores computadores 4,115, 12, 13, 14, 16, 17, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31, 32, 33, 36, 37, 69 Computer 21 Computer-Supported Cooperative 37 Computerworld 67 Conhecimento 3 conhecimento 3, 8, 46, 59, 66, 114, 115, 180, 225 Conhecimentos 225 conhecimentos 33, 51, 69 consultoria 21 Cooperativo 65 cooperativo 64, 65 Corporativa 190, 191 CPD 16, 24, 27, 28, 30, 34, 35, 37, 38 CPDs 32 CPM 200 CRM 20, 123, 155 CSCW 7, 8, 63, 64, 65, 116 custo 4 custos 5

Índice Remissivo 267

D

E

dado 61 dados 2, 13, 20, 24, 25, 26, 27, 28, 29, 30, 32, 33, 34, 37, 38, 44, 45, 51, 52, 53, 59, 61, 102, 119, 120, 140, 144, 148, 184 Dados (CPD) 24 Davenport 34 dedução 163 Deming 34 Dertouzos 54 desenhado 194 desenhados 129 Desenhar 176 desenhar 175, 180, 181 desenho 9, 20, 40, 49, 65, 68, 69, 70, 84, 113, 114, 115, 118, 126, 129, 130, 156, 157, 158, 160, 162, 164, 174, 177, 178, 180, 193, 205 Desenvolvimento 122 Desorganização 2 desorganização 62 Desorganização Informacional 1, 2, 3, 7, 8, 9, 26, 30, 33, 34, 39, 40, 42, 43, 45, 46, 48, 49, 50, 51, 52, 53, 54, 55, 57, 60, 62, 63, 125, 147, 156, 157, 164, 182, 184, 229 digitação 16 digital 5, 21, 55 disco 43 Dissonância Cognitiva 214 Documentação 160 documentação 113, 114, 174, 180, 216 documentar 114, 180, 181 documento 42, 43, 120 documentos 17, 41, 42, 43, 44, 119, 120 Doença 51 doença 52 DoI 1, 2, 3, 8, 33, 35, 40, 41, 44, 46, 48, 49, 50, 51, 52, 55, 59, 62, 125, 146, 147, 156, 157, 182 DOMP 88, 165, 166, 177, 178, 200 Drucker 59 DW 20, 151, 155

e-business 2 EAI 73, 85, 119, 122, 123, 135, 136, 139, 140, 141, 147, 150, 151, 154, 229 EAP 223 Eckert 13 ECMS 123 ECR editor 217 43 Editores 40 editores 41, 42, 43 EDMS 123 EDSAC 13 EDVAC 13, 26 EIA 153 EIS 20 Elementos 165 eletrônica 21 eletrônico 17 empresa 43, 45, 46, 133 empresas 16, 22, 30, 31, 36, 38, 71, 124 equipamento 12, 46 Era Conhecimento ERPdo20, 95, 96, 97, 98,3 102, 103, 112, 119, 123, 133, 138, 155, 175 ERPs 98, 102, 117, 120, 138, 175, 205 Estatística 122, 126 Ethernet 17 evento 167, 200 eventOgrama 166 eventos 200, 201, 216 Extranet 106

F fábrica 3 Fases 194 ferramenta Ferramentas160 122, 126, 129, 131, 134, 135, 153 ferramentas 7, 8, 43, 114, 124, 126, 129, 135 Festinger 214 uxo 107, 108, 109, 110, 111, 119, 132, 174 uxos 173 foreground 149, 152, 153, 166

268 BPM & BPMS foreground & background 151 foreground & background processes 148 Foreground Processes 149 foreground processes 150 formulários 16, 178 fornecedores 185 Forrester 14 Forsythe 14 Funcionais 119, 157 funcionOgrama 166

G Gartner 67 GE 163 GED 162, 217 gerência 225 Gerenciamento 122, 153 gerenciamento 9, 40, 49, 65, 68, 69, 70, 84, 122, 158, 174, 177, 178, 180, 193, 205 gerenciamento de mudanças 9 gerenciar 180, 181 globalização 2, 17 Google 60 Governança 188, 190, 191 Greif 63 Grid 21 Grid Computing 15 Groupware 1, 7, 15, 63, 71, 85, 116 groupware 64 Grudin 63

indução 163 indústria 7, 12, 22, 43 indústria de TI 14 infobia 2 infOgrama 166 Informação 1, 2, 3, 6, 7, 8 informação 3, 11, 21, 23, 24, 61 informacional 14, 20 informações 17,51, 27,60, 28,109, 30, 120, 32, 33, 35, 37, 44,2,46, 14734, informática 4, 17, 24, 45 Information Anarchy 2 Information Technology 64 inovações tecnológicas 19 Internet 17, 21, 33, 40, 46, 54, 61, 106, 114 Intranet 106 invenção 12, 13 invenções do hardware 14 inventores 12, 13 inventos 12, 13 iProcess 76 Ishikawa 95

J

Jacquard 12 Jevons 13 Jobs 64 Juran 34

H

K

habilidades 225 Hammer 34 hardware 14, 18, 21, 23, 26, 36, 69, 70, 107, 141, 180 História 11 história dos computadores 8

Kanri 125 Kindle 21 KM 149 KPO 22, 183, 184, 185, 186

Hollerith 13184 HP 33, 36,

laptop 5 laptops 4, 5, 6 Leibniz 12 lei de informática 8 Lévy 58 Linguagens 123, 154 lógica 13 logísticos 5

I IBM 2, 25, 27, 33, 114 Immelt 163, 164 implantação 9, 40, 49, 65, 68, 70, 84, 158, 177, 178, 193, 203, 204, 205

L

Índice Remissivo 269 Lovecraft 230 Lovelock 230

M M 174, 219 magnético 14 mainframe 16, 69 Mainframes 15 mainframes 13, 25, 27, 32, 33, 35, 37 manutenção 5 mapeamento 45, 46, 89 máquina 11, 12, 13, 17, 27, 30, 44, 58 máquinas 5, 11, 12, 13, 17, 22, 23, 24, 25, 26, 27, 29, 31, 32, 33, 41, 42, 44, 147, 148 Mark 1 13 Mauchly 13 McCoy 201 melhorar 180, 181 melhoria 9, 20, 40, 49, 65, 68, 69, 70, 84, 158, 174, 177, 178, 180, 193, 205 memória 14, 21 Metodologia 194 metodologia 88, 108, 125, 160, 165, 166, 178 Metodologias 172, 174 metodologias 90, 124, 125, 174 microcomputador 42 microcomputadores 16, 20, 23, 31, 32, 44, 58, 69 microevento 167, 200 microeventos 201, 216 microprocessador 13 micros 23, 32 MIT 4, 167, 168, 179 modelado 194 modelados 129 Modelagem 122, 123, 126 modelagem 9, 20, 40, 45, 46, 49, 65, 68, 69, 70, 84, 88, 89, 113, 114, 115, 118, 123, 124, 126, 129, 130, 156, 157, 158, 160, 162, 164, 174, 176, 177, 178, 180, 193, 205 Modelar 176 modelar 175, 180, 181 Modelo 166, 171

modelo 166 modelos 165 Monitoração 122, 134 MRP 20, 97 MSN 60 Mudança 205, 207 mudança 209, 211, 213, 214 Mudanças 206 mudanças tecnológicas 208, 212, 2148 mudanças

N Napier 12 Negócio 65, 122, 131, 157, 165, 171, 172 negócio 9, 20, 34, 40, 45, 46, 49, 52, 65, 66, 67, 68, 69, 70, 84, 85, 88, 90, 91, 93, 95, 96, 107, 110, 111, 113, 114, 115, 116, 117, 118, 120, 121, 124, 125, 126, 127, 129, 131, 132, 134, 140, 156, 157, 158, 159, 160, 162, 164, 165, 166, 167, 172, 174, 175, 176, 177, 178, 180, 181, 186, 193, 198, 199, 200, 205, 223 Negócios 138, 119 144 negócios Negroponte 4, 21, 22 networks 30 Neumann 13 notebook 14, 21, 43, 60 NP2TEC 170

O O&M 34 Ofce 37, 38, 39, 40, 44, 99, 114 Ofce Automation 15 onda 15, 20, 21 Ondas 11 ondas 15, 19, 21 Ondas de TI 15 ondas de TI 15, 19, 21, 22, 25 On Demand 2 OOIE 177 operação 22 operacionalização 69 organiza 62 organização 9, 27, 28, 30, 34, 38, 39, 40,

270 BPM & BPMS 43, 44, 45, 46, 47, 48, 49, 59, 65, 67, 68, 70, 84, 92, 93, 94, 95, 117, 118, 121, 124, 126, 133, 134, 135, 156, 157, 158, 163, 174, 175, 177, 178, 180, 193, 205, 206, 224, 229 organizacionais 20 organizacional 124 Organizações 122, 123 organizações 2, 6, 7, 8, 15, 17, 18, 20, 23, 24, 26, 27, 28, 29, 33, 34, 35, 36, 37, 39, 40, 41, 42, 44, 46, 51, 54, 58, 59, 62, 63, 65, 66, 68, 71, 86, 94, 117, 119, 120, 123, 124, 125, 147, 175, 191 organizado 30 organizar 3, 180, 181 Organizing Business Knowledge 168 Orwell 61 OSA 176 otimização 174, 180 otimizar 180, 181 Outsourcing 184 outsourcing 22, 184, 185 outsourcing seletivo 184

processamento dos computadores 23 processes 166 Processo 68, 109, 171 processo 5, 66, 67, 91, 95, 107, 108, 110, 111, 112, 113, 115, 116, 119, 124, 126, 127, 130, 149, 150, 162, 164, 165, 166, 167, 171, 172, 178, 194, 195, 196, 197, 198, 200, 201, 202, 203, 204, 217

P Papéis

programa 5, 13, programadas 12 23 programadores 27, 34 programas 5, 18, 23, 27, 43, 50

119, 157 papéis funcionais 9 Pascal 12 PC 21 PCs 17, 23 PDCA 203 PERT 200 Peter Drucker 3 planejamento 124 Planilhas 44 planilhas 44, 45, 46 PLC 93 Process 50, 51, 52, 66, 67, 68, 69, 70, 72, 74, 75, 77, 78,123, 80, 124, 85, 87, 88,127, 89, 130, 90, 91, 93, 114, 121, 126, 131, 135, 153, 167, 179, 182, 184, 188, 191, 192, 199, 202, 203, 204, 206, 229, 230 process 166 processados 24 processamento 16, 21, 119 processamento de dados 22

Processo Negócio Processosde65, 88, 93, 89 105, 122, 126, 134, 160, 165, 172, 225 processos 9, 20, 27, 34, 38, 40, 45, 46, 49, 52, 65, 66, 67, 68, 69, 70, 71, 84, 85, 88, 90, 91, 92, 94, 95, 96, 103, 104, 108, 109, 112, 113, 114, 117, 118, 119, 124, 125, 126, 128, 129, 130, 132, 133, 134, 140, 149, 151, 155, 156, 157, 158, 159, 160, 162, 164, 165, 174, 175, 176, 177, 180, 181, 186, 189, 193, 199, 200, 205, 218, 219, 220, 221, 223 Processos de Negócio 90 produtividade 40 produtos 114

R Record Management 188 rede 4, 17, 21 redes 17, 30 redesenhado 194 redesenhados 129 Redesenhar 176 redesenhar 175, 180, 181 redesenho 9, 20, 40, 49, 65, 68, 69, 70, 84, 113, 114, 160, 115, 162, 118, 164, 126, 174, 129, 176, 130, 177, 156, 157, 158, 178, 180, 193, 205 reengenharia 34 Regras 119, 122, 131, 157 regras 85, 93, 107, 110, 111, 117, 120, 131, 132 Revolução da Informação 17 Revolução Industrial 3

Índice Remissivo 271 RM 86, 123 Roles 86, 162 Rotas 157 Routes 86, 162 Rules 86, 162 RUP 177

S Schickard 12 SCM 217 SCOR 168, 169, 177 SDK 134 SDoI 2 selective outsourcing 184 Servidores 123 servidores 154 Shockley 13 Simulação 122, 129 simulação 114, 129, 130, 131 simulações 129, 131 simular 129 Sintomas 51 Sinur 201 sistema 5, 25, 42, 45, 69, 95, 98, 102, 103, 107, 109 sistema de informações 45 Sistemas 96 sistemas 13, 25, 27, 30, 32, 37, 38, 68, 98, 102, 118, 119, 121, 133, 134, 148, 149 Sistemas, Organização & Métodos 15 sistemas de informações 25, 34, 45, 132, 173 SLA 185 Slack 104 SLM 185, 200 SOA 9, 85, 122, 123, 140, 141, 143, 144, 145, 146, 147, 151, 153, 154, 209, 215, 224, 225, SOA223, Architect 224229 SOAP 143, 144, 145 Software 122 software 6, 7, 8, 9, 14, 18, 20, 21, 23, 31, 32, 36, 40, 43, 47, 50, 64, 68, 69, 70, 71, 74, 84, 85, 86, 88, 89, 90, 91, 92, 96, 98, 101, 103, 108, 112, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 126, 129,

130, 132, 133, 134, 135, 137, 139, 140, 141, 154, 157, 162, 173, 175, 184, 218 Softwares 114 softwares 17, 23, 34, 36, 37, 38, 43, 46, 69, 71, 72, 87, 91, 93, 98, 99, 113, 114, 115, 116, 117, 118, 120, 124, 126, 129, 131, 132, 134, 135, 136, 137, 149, 155, 174 SOHO 15 SOM 86, 17787, 188, 189 SOx subprocessos 110, 201 superminis 31 System 20, 68, 90, 121, 123, 124, 126, 130, 131, 135, 153, 154, 184, 199, 202, 203, 204, 229 Systems 25, 70, 114, 117, 179, 191, 230

T tarefas 132 técnicos 5 Tecnologia 7, 150 tecnologia 1, 3, 5, 6, 11, 12, 18, 20, 36, 48, 53, 59, 85, 86, 141, 157, 218 Tecnologia da Informação 19, 39, 49, 58, 60, 117 tecnologia da informação 54, 90 Tecnologias 1, 2, 3, 6, 8, 41, 46, 121 tecnologias 1, 2, 7, 8, 18, 19, 21, 22, 36, 38, 41, 43, 57, 58, 63, 64, 85, 90, 97, 101, 104, 115, 116, 121, 122, 123, 149, 189 Tecnologias da Informação 11, 15, 16, 17, 18, 21, 36, 40, 41, 46, 48, 51, 57, 59, 64, 66, 67, 68, 69, 70, 85, 98, 121, 147, 148, 223, 229 tecnologias da informação 13, 14, 19, 36, 63, 64, 142, 148, 150, 225 tecnologias Groupware 16 tecnológicas 12, 19 tecnológico 12 Tempo 127, 128 tempo 127, 128 tempos 129 Terceirização 183 terceirização 184, 185, 186 The MIT 177 TI 1, 2, 3, 7, 8, 9, 15, 16, 17, 18, 22, 24, 31,

272 BPM & BPMS 33, 34, 36, 37, 39, 40, 43, 47, 48, 50, 51, 52, 58, 63, 64, 69, 88, 114, 138, 146, 147, 223, 224, 229 trabalho 17 Trabalho Cooperativo Suportado por Computador 7 trabalho manual 12 transistor 13

WfMC 72, 83, 84, 85, 87, 98, 99, 120, 121, 126, 133 Wilkes 13 Work 63, 64, 116, 118 Workow 7, 8, 40, 50, 67, 68, 69, 70, 71, 72, 73, 74, 83, 84, 85, 86, 87, 88, 89, 92, 93, 95, 96, 97, 98, 99, 100, 101, 102, 103, 106, 107, 108, 109, 110, 111, 112,

transistores 13

113, 126, 114, 131, 117, 132, 118, 133, 119, 134, 120, 135, 121, 136, 122, 123, 137, 138, 139, 145, 149, 153, 154, 155, 157, 162, 184, 187, 188, 189, 190, 199, 200, 204, 215, 217, 218, 222, 223, 225, 229 workow 118, 119 World Wide Web 17 WS 145 WSDL 145, 146

U UDDI 145, 146 UML 177 UNIVAC 13, 25

V Vida 192, 199

W W3C 142, 143 WARIA 85 Web 4, 18, 140, 141, 146 web 142 Welch 163

X XML 143, 144, 146

Y Yahoo

60

Últimos Lançamentos XNA 3.0 para desenvolvimento de jogos no Windows, Zune e Xbox 360 Alexandre Santos Lobão / Bruno Pereira Evangelista / José Antonio Leal de Farias / Patryck Pabllo Borges de Oliveira 460pp. – R$ 89,00 O objetivo do livro é apresentar ao leitor a visão geral da arquitetura XNA e o processo de desenvolvimento de um jogo completo. São apresentadas técnicas de programação de jogos, desde o planejamento do projeto ao desenvolvimento de jogos 2D, inserindo funcionalidades de som e rede e, por último, o desenvolvimento de um jogo 3D em primeira pessoa do início ao fim, implementando um framework básico que poderá ser utilizado em seus jogos.

Desenvolvendo Aplicações Web com Ruby on Rails 2.3 e PostgreSQL Ricardo Roberto Leme

216 pp. – R$ 53,00

Ruby é uma linguagem de script interpretada para a programação orientada a objetos. Ruby on Rails é um metaframework de código aberto escrito em Ruby.

Este livro é direcionado a entusiastas de novas tecnologias ou programadores profissionais que nunca tiveram contato com o Ruby on Rails e desejam aprender a construir uma aplicação web utilizando o Ruby on Rails na plataforma Windows.

Datacenter – Componente Central da Infraestrutura de TI Manoel Veras

376 pp. – R$ 89,00 Formato: 21 x 28

Este livro apresenta uma visão integrada e inovadora do DATACENTER, componente crítico da infraestrutura de TI. O livro é modular e detalha os diversos aspectos envolvidos na construção e no projeto de um DATACENTER tanto do ponto de vista lógico como do ponto de vista físico. Temas como virtualização, processamento, armazenamento e redes são amplamente tratados sob a ótica do DATACENTER.

AutoCAD Map 3D Kátia Góes

488 pp. - R$ 103,00

AutoCAD Map 3D é uma ferramenta poderosa que atende a construção da base de dados, correção de erros da base cartográfica, análises espaciais, produção de mapas temáticos, atlas e integração com outras plataformas de SIG sem mistérios. Este livro é voltado para os profissionais das áreas de Geociências, Engenharia, Geomática e Tecnologia da Informação que utilizam Sistemas de Informação Geográficas.

Oracle DBA Essencial Vol. 1 – SQL Eduardo Morelli

360 pp. - R$ 75,00

Este livro segue o estilo didático presente nos livros do autor. Aborda a linguagem de manipulação de dados SQL, desde seus tópicos mais elementares até assuntos bastante complexos, tais como consultas hierárquicas, funções analíticas e tuning. O livro também pode ser utilizado como material de preparação para o Exame IZO-051, o primeiro na linha de certificação Oracle 11g.

www.brasport.com.br

[email protected]

Linux Performance & Monitoramento Maicon Melo Alves

224 pp. - R$ 51,00

Este livro tem o objetivo de despertar no profissional o desejo por entender o sistema e seu funcionamento de um modo mais profundo, buscando demonstrar e apresentar conceitos fundamentais, técnicas, ferramentas, parâmetros e métricas, para que o leitor possa analisar e identificar quais ajustes podem ser feitos para que o sistema tenha o melhor desempenho possível.

Flex 3 + Flash Media Ser ver 3.5 – Desenvolvimento de Aplicações Ricas para a Web Carlos Eduardo G. Franco

292 pp. - R$ 63,00

Com este livro, você poderá fazer parte desta mudança criando, desenvolvendo e fornecendo aplicações web ricas em recursos multimídia usando Adobe Flex + Flash Media Server. No livro essas duas tecnologias estão integradas para que você possa criar ambientes a serem usados em Web Seminários, WebTV, videoconferências, soluções em streaming sob demanda e muito mais.

Transformando Imagens de Moda com Corel PHOTO-PAINT Daniella Romanato

148 pp. – R$ 68,00 Formato: 21 x 28

Primeiro livro específico de Corel PHOTO-PAINT para moda! Ensina, passo a passo, a utilização de todas as ferramentas do programa direcionadas ao público de moda. O Corel PHOTO-PAINT faz parte do pacote CorelDRAW e sua principal função é a edição de imagens. Com sua utilização, simples fotografias podem se tornar verdadeiras obras de arte. É um programa de edição gráfica e retoque fotográfico de grande importância para o setor da moda e imagem pessoal.

Montagem e Manutenção de Computadores Wagner Cantalice

292 pp. – R$ 59,00 Formato: 17 x 24

Através de didática clara, objetiva e com inúmeras ilustrações passo a passo o leitor conhecerá a história e tipos de computadores, bem como aprenderá a escolher o tipo de computador certo para a atividade que deseja. Entre os assuntos abordados destacam-se: as peças do computador; como montar um computador on-board e off-board; configuração do SETUP; instalação do Windows XP, do Windows Vista, do Office e de antivírus; lista dos principais defeitos e suas soluções e muito mais.

Gerenciando projetos de sof tware usando Visual Studio Team System Ramon Durães

416 pp. – R$ 81,00 Formato: 17 x 24

Ao iniciar a leitura deste livro, você terá uma apresentação de todo o ciclo de Application Lifecycle Management oferecido pelo Visual Studio Team System e os componentes que fazem parte da solução. O Team Foundation Server é um dos grandes pilares da solução, coletando as informações do ciclo de desenvolvimento e integrando todos os participantes do projeto. Serão discutidas sua instalação e configuração, além dos serviços relacionados como Sharepoint e Report Services. www.brasport.com.br

[email protected]

Cloud Computing - Computação em Nuvem Cezar Taurion

228 pp. – R$ 59,00

A proposta deste livro é explorar e debater os principais aspectos de uso da Computação em Nuvem, suas potencialidades e restrições, suas tecnologias e aplicabilidades. O livro vai concentrar sua atenção nas aplicações e no uso prático no contexto dos usuários corporativos e seus desafios frente a este novo modelo computacional. A Computação em Nuvem ainda tem muito a evoluir. Estamos todos aprendendo e este é o momento de conhecer um pouco mais seu conceito, suas tecnologias e suas formas de uso.

Android para Desenvolvedores Lúcio Camilo Oliva Pereira / Michel Lourenço da Silva

240pp. – R$ 61,00

Formato: 17 x 24 Este livro apresenta exemplos práticos, passo a passo e teóricos com a implementação disponível no CD-ROM que acompanha o livro. O objetivo principal deste livro é fornecer ao leitor os recursos disponíveis, focando de forma ilustrada e detalhada as informações indispensáveis no domínio da plataforma, além de muitas dicas e visões gerais sobre os itens de mais fácil entendimento. A informação é vista de forma gradual e crescente, possibilitando que ao final do livro você possa desenvolver suas próprias aplicações dos conceitos aprendidos.

Java Dicas & Truques Daniel Gouveia Costa

364 pp. – R$ 69,00

Se você já programa em Java, este é o seu livro! Diversos truques e dicas são apresentados para muitas situações práticas de programação, além de novas características da linguagem. Sente e aproveite a leitura. Agora, se você já é um programador experiente, não desanime. Além das inúmeras irá encontrarEste muitos estruturaque da linguagem Java que são cobrados emdicas, provasvocê de certificação. é o detalhes livro parasobre todosaaqueles querem aprimorar suas habilidades na programação em Java.

Planejamento Estratégico Digital Felipe Morais

288 pp. – R$ 61,00

Este livro visa abordar esse tema de forma simples, clara e objetiva, ensinando como pensar estrategicamente um projeto digital, obser vando e analisando mercados, consumidores, concorrência, tendências e, com isso, elaborando estratégias eficazes, sempre usando como exemplo uma empresa fictícia criada apenas para este livro, chamada Canetas Legais.

Certificação Java 6 – Volume 1 – Teoria Roberto Rubinstein Serson

628 pp. – R$ 149,00

Esta série inédita está dividida em dois volumes: teoria e prática. Ambos os textos são complementares, você compreende a teoria por meio do estudo de todos os tópicos do exame e, posteriormente, realiza exercícios-simulados similares aos da prova. Trata-se de um guia passo a passo em que cada capítulo abrange um assunto específico.

Certificação Java 6 – Volume 2 – Prática Roberto Rubinstein Serson

476 pp. – R$ 119,00

Dando prosseguimento ao primeiro livro da série, a proposta deste segundo volume é prepará-lo para o exame SCJP – 310-065 – Java 6, através de questões resolvidas e explicadas de forma detalhada. Assim, por meio de exercícios, todos os assuntos da prova são abrangidos. As perguntas estão divididas em capítulos e os capítulos estão segmentados por nível de dificuldade.

www.brasport.com.br

[email protected]

Design de Jogos: Fundamentos Antonio Marcelo / Julio Cesar Pescuíte

188 pp. – R$ 49,00

Este livro tem como objetivo mostrar como os jogos mudaram nos últimos dez anos e como podemos projetar jogos com mecanismos modernos reais e virtuais. São abordados tópicos como Prototipação, Design, Playteste e Ferramentas de desenvolvimento. Os autores esperam que este livro sirva para ajudar a todos aqueles que querem ter uma visão prática sobre o assunto.

Montagem de Computadores e Hardware (6a edição) Rodrigo Amorim Bittencourt

336 pp. – R$ 69,00

Material didático em potencial para alunos de cursos de formação profissional das áreas de hardware e montagem de computadores, nesta sexta edição foi realizada uma atualização dos conceitos abordados nas edições anteriores, assim como novos conteúdos foram incluídos em decorrência da evolução tecnológica, tais como processadores com núcleo duplo e quádruplo, dezenas de novas fotografias tanto na parte de hardware como na montagem.

Desvendando o Delphi for PHP João Paulo Moura

244 pp. – R$ 58,00

Obra inédita no mercado! Este é o primeiro livro a apresentar como utilizar todas as ferramentas da nova IDE da Borland, o Delphi for PHP. É indicado tanto para iniciantes em programação como para os programadores que já trabalham com desenvolvimento de sites e sistemas para Internet. Contém exemplo prático de pequeno sistema feito com essa poderosa ferramenta.

Terminais sem Hard Disk André Guedes Ruschel

224 pp. – R$ 75,00

Neste livro temos uma solução de como reutilizar todos aqueles computadores obsoletos que você possui, e ainda com um bom desempenho. Acreditem, isso é possível! Tenha a certeza de que com este livro você conseguirá realmente executar todas as tarefas descritas e que ele será o seu manual por muito tempo. O CD-ROM inclui vídeo-aula com configuração e arquivo para os terminais e servidor.

Acessando Bancos de Dados com ferramentas RAD: Aplicações em Delphi Mário Leite

400 pp. – R$ 80,00

Este livro ensina como acessar as principais bases de dados utilizadas nos sistemas de informação de maneira prática e objetiva, através de exemplos em Delphi 7 e Delphi 2007. São acessadas, pela ordem: dBase, Paradox, Access, Interbase, Firebird, MySQL, Oracle, PostgreSQL e SQL Server, nas suas versões mais atualizadas e através de diferentes provedores. São mostradas técnicas de conexão e acessos às bases de dados através de aplicações práticas e bem didáticas, abrangendo as tecnologias ADO, ODBC e dbExpress. BRASPORT LIVROS E MULTIMÍDIA LTDA. RUA PARDAL MALLET, 23 - TIJUCA – RIO DE JANEIRO – RJ – 20270-280 Tel. Fax: (21) 2568.1415/2568-15 07 – Vendas: [email protected]

BPM-BPMS Tadeu Cruz.pdf

Recommend Documents