UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE

Transcrição

1 UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE AGREGANDO VALOR AO ESCOPO EM PROJETOS DE SOFTWARE COM USO DA GESTÃO DE PROCESSOS DE NEGÓCIO Por: Emerson Jerônimo Oliveira da Silva Orientador Prof. Marcelo Saldanha M. Sc. Rio de Janeiro 2010

2 2 UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE AGREGANDO VALOR AO ESCOPO EM PROJETOS DE SOFTWARE COM USO DA GESTÃO DE PROCESSOS DE NEGÓCIO Apresentação de monografia à Universidade Candido Mendes como requisito parcial para obtenção do grau de especialista em Gestão de Projetos. Por: Emerson Jerônimo Oliveira da Silva

3 3 AGRADECIMENTOS Aos familiares, esposa e amigos, que sempre mesmo com a correria do diaa-dia, apóiam e incentivam meu crescimento em todos os aspectos da minha vida.

4 4 DEDICATÓRIA Dedico este trabalho aos meus pais, esposa, familiares e amigos.

5 5 RESUMO O objetivo deste estudo é apresentar os ganhos promovidos pela integração da Gestão de processos de negócio (BPM), mas precisamente a visão por processos na melhoria da assertividade do escopo de projetos de software. A visão departamental atual do desenvolvimento de software acaba distorcendo o entendimento global do processo da organização trazendo como conseqüência requisitos mal definidos e carregados de percepções individuais dos usuários que muitas vezes não tem entendimento do processo como um todo. Essas percepções individuais refletidas nos requisitos ao longo do tempo geram alterações por conta de trocas dos usuários especificadores que muitas vezes não são os mesmos que vão validar o software final. Alterações em requisitos durante o andamento do projeto influenciam em restrições de qualidade, tempo e custo que comprometem o sucesso do projeto e podem ocasionar até mesmo o cancelamento do mesmo. Desta forma este estudo desenvolveu como fundamento para conclusão dos problemas delimitados nesta pesquisa uma revisão bibliografia sobre os temas abaixo: Gestão de processos de negócio e seus desdobramentos, incluindo quadros conceituais sobre processos de negócio, visão por processos que com apoio da TI é responsável pela disseminação das metas organizacionais; Gerenciamento de escopo em projetos e sua importância para o aumento do percentual em de sucesso nos projetos utilizando como referência o guia PMBOK de boas práticas do PMI.

6 6 METODOLOGIA A presente pesquisa caracteriza-se por ser um trabalho de revisão de literatura, de caráter bibliográfico, desenvolvida com base em livros, revistas e artigos acadêmicos da área, utilizando como referência os principais autores do assunto.

7 7 SUMÁRIO INTRODUÇÃO 08 CAPÍTULO I - Os Principais Conceitos sobre Gestão de 09 Processos de Negócio CAPÍTULO II - A importância do Escopo em Projetos 24 Segundo as Boas Práticas do PMI CAPÍTULO III - O que a Gestão de Processos de Negócio 31 Pode Agregar na Melhoria do Escopo em Projetos de Software CONCLUSÃO 34 BIBLIOGRAFIA CONSULTADA 36 ÍNDICE 38 FOLHA DE AVALIAÇÃO 40

8 8 INTRODUÇÃO Em geral na grande maioria de projetos de software, são voltados para informatização de processos de negócio nas organizações. Estas organizações buscam com estes projetos ganhar melhor desempenho e alinhamento estratégico de suas metas organizacionais. Porém alguns destes projetos esbarram em fronteiras organizacionais que podem causar distorções no entendimento do escopo final, comprometendo os resultados esperados após a implantação do software. Por esta razão torna-se necessário um estudo que identifique o ganho organizacional promovido pela integração da gestão de processos de negócio aos projetos de software. O uso da gestão de processos de negócio pode minimizar as distorções no gerenciamento de escopo de projetos de software por aproximar as soluções ao objetivo real do negócio, deixando de lado das percepções individuais de cada área funcional.

9 9 CAPÍTULO I OS PRINCIPAIS CONCEITOS SOBRE GESTÃO DE PROCESSOS DE NEGÓCIO 1.1 Processos de Negócio Segundo Antunes (2006) apud Paim et al. (2009) um processo é constituído do fluxo do objeto no tempo e no espaço, estes objetos podem ser materiais, idéias, informações e etc. Partindo desta definição Paim (2009) infere sobre o termo processos de negócio quando há material, capital e informação, em fluxo. Rozenfeld (2006) apud Baldam et al. (2007) define um processo de negócio como um fenômeno que ocorre dentro das empresas, manipulando informações através da utilização de seus recursos, focalizado em um tipo de negócio que está direcionado a um mercado/cliente. Smith e Fingar (2003) definem um processo de negócio como um conjunto de atividades colaborativas, completas, dinâmicas e transacionais que entrega valor ao cliente. Os processos de negócio carregam em seu DNA fortes traços ligados à estratégia, são eles que vão ajudar a capilarizar em uma organização orientada por processos as estratégias deliberadas pela alta gestão. Segundo Porter (1989) uma estratégia empresarial é definida como um conjunto de ações abrangentes de metas e políticas necessárias para uma empresa competir no mercado. As organizações que atuam centradas em bases estratégicas necessitam que os colaboradores envolvidos tenham entendimento de que forma sua atividade pode contribuir para o sucesso da estratégia adotada. Considerando os argumentos anteriores e por inferência acredito que seja coerente definir um processo de negócio como sendo o entendimento comum acerca de uma operação de relevância estratégica, realizada dentro de uma organização, que consome recursos de entrada e entrega um produto

10 10 com características pré-definidas na saída. Este entendimento coletivo torna-se a base para a colaboração e é um dos elementos chave para sintonia entre diferentes setores da empresa. Esta sintonia entre diferentes departamentos funcionais norteia um conceito importante para o entendimento da Gestão de Processos que é a Visão por Processos, que será tema do próximo tópico. Existem na literatura muitas outras definições para processos de negócios, mas em resumo, todas descrevem o processo, como uma transformação em recursos de entradas em recursos de saídas, com objetivos previamente estabelecidos, sendo que para isto utiliza uma ou muitas atividades. A figura 1 abaixo de Baldam et al. (2007) consolida e mostra o contexto dos processos de negócio nas organizações. Figura 1: Contexto de Processos Fonte: Baldam et al. (2007)

11 Visão por Processos Em organizações funcionais onde temos silos funcionais especializados, cada área atua em suas metas funcionais. O grande problema dessa abordagem é que restringe a visão das metas organizacionais, onde cada área conhece sua função e busca sempre atingir suas metas de desempenho. As metas locais condizem com os objetivos da função, mas será que algumas dessas não estão impactando em outra área funcional e com isso depreciando a Cadeia de Valor da organização. Segundo Porter (1989), a Cadeia de Valores é o instrumento básico para o exame das atividades executadas por uma empresa, desagregando uma empresa em suas atividades de relevância estratégica para que se tenha compreensão do comportamento dos custos e as fontes existentes e potenciais de diferenciação. Ainda segundo o mesmo autor, uma empresa ganha vantagem competitiva executando suas atividades estratégicas importantes de forma mais barata, ou melhor, que a concorrência. Segundo Paim et al. (2002) a cadeia de valor também incorpora uma visão dinâmica, e se constitui instrumento para ver economicamente como está a operação produtiva da empresa. Figura 2: Visão Funcional X Visão por Processos Fonte: Antunes, Jr., Caulliraux e Neves (1998).

12 12 Analisando a figura 2, vamos imaginar que para cumprir sua meta local o departamento de Vendas (função A) diminui suas restrições para análise de crédito e torna mais flexível a venda. Sua meta funcional será cumprida, mas não seria o ideal para o Departamento de Cobrança (função B) cumprir a sua meta, já que isso pode acarretar um aumento na inadimplência. O problema exemplificado mostra que a visão funcional pode levar a distorções da visão global da organização, os objetivos da visão por processos vem como forma minimizar este gap existente entre as funções da empresa. Na visão por processos as funções e as pessoas continuem a existir, mais uma nova ótica é dada, em que os processos atravessem toda a organização Paim et al. (2002). O grande ganho nessa estrutura é a identificação das interfaces organizacionais e dos processos da organização, fazendo com que além das áreas funcionais continuarem responsáveis pela sua função, torna-se coresponsáveis também pelo desempenho global do processo, melhorando assim a qualidade e definições dos indicadores de desempenho organizacionais e a gestão das gerências. A figura 2 acima apresenta a visão onde os processos atravessam toda a estrutura funcional da organização, o foco agora é acompanhar o processo desde a compra do material até a entrega do produto ao mercado, passando pelas diferentes áreas funcionais da organização. Essa abordagem por processos segundo Salerno (1999) não isenta as organizações funcionais de seus problemas, mas promove um ganho significativo, pois a lógica passa a ser do processo orientado ao mercado (cliente) e não mais as lógicas funcionais. Em termos práticos Baldam et al. (2007) aponta que na prática as empresas não adotam este modelo de gestão exclusiva por processos, o que ocorre é que elas tendem a ser centradas em processos, apontando para um caminho de maturidade em processos, mas com departamentos e a consagrada visão funcional inspirada nas linhas de montagem. Um ponto relevante em relação à questão da visão funcional x visão processual é que a TI mesmo que indiretamente possibilita a quebra desses

13 13 silos funcionais, permitindo um link das atividades ao nível de processos entre as diferentes áreas da organização. Baldam et al. (2007) relaciona três grandes difusores da visão por processos que foram: 1. Implantação de controle da qualidade total: Cujo foco dos programas era a eliminação dos defeitos pela melhoria contínua, defeito zero; 2. Implantação em larga escala de Sistemas integrados de gestão (ERP): Os grandes fabricantes de pacotes de softwares voltados à gestão perceberam a similaridade entre os processos das organizações passando a encarar estes processos como commodities, embutindo as melhores práticas nestes softwares; 3. Difusão da Gestão de Processos de Negócio: Será apresentada no próximo tópico.

14 Gestão de Processos de Negócio A gestão dos processos também tem sido estudada e entendida como uma forma de reduzir o tempo entre a identificação de um problema de desempenho nos processos e a implementação das soluções necessárias PAIM et al. (2009, p.26). A Gestão de Processos aponta para necessidade de adaptação cada vez mais rápida das organizações frente ao mercado, concorrência, clientes e governo (regulamentação). Melhorar processos hoje passa a ser uma necessidade básica de uma organização. Gerir processos com eficácia segundo Paim et al. (2009) promove integração, dinâmica, flexibilidade, inovação o que resulta em vantagem competitiva. Neste ponto é importante salientar que no contexto deste estudo o BPM (Business Process Management) que é traduzido como Gerenciamento de Processos de Negócio é utilizado como sinônimo à Gestão de Processos, pois o seu conceito é apresentado neste estudo em seu sentido mais amplo, e não apenas sua relação com a implantação de tecnologias para gerenciar os processos de negócio. Devemos ter em mente que o BPM é um modelo de gestão, com foco na integração dos processos de ponta-a-ponta. O BPM utiliza como forma de coordenação à visão por processos agregada ao modelo tradicional de gestão centrado em funções. Segundo Jesus (2007) o BPM deve ser fundamentalmente entendido como a aplicação de métodos e técnicas para o projeto, implantação, controle e melhoria contínua dos processos. Baldam et al. (2007) aponta algumas razões de interesse das empresas e que contribuíram para difusão do BPM.

15 15 1. A evolução das estruturas de mercado resultante da globalização: Ligada a hipercompetição gerada pela queda das barreiras alfandegárias. 2. O controle da complexidade em grandes corporações: Em corporações globalizadas as filias são impostas a realizar o trabalho de acordo com as regras da matriz, outro caso são grandes corporações que surgem através de fusões de várias outras empresas. A preocupação é se os processos em uso estão alinhados tanto no caso das filias como nas empresas incorporadas. 3. A racionalização de quarta geração do desenvolvimento de produtos: Motivada pela diminuição do ciclo vida de desenvolvimento e oferta de novos produtos no mercado por causa da concorrência acirrada. 4. Responsabilidade Social e Governança Corporativa: Exigências de transparência em transações financeiras, normas e regulamentações e leis em diversos setores demandam adaptações em seus modelos de processos. 5. Evolução das TI s como fator de difusão do BPM: A evolução acelerada da informática em meados dos anos 90 foi um dos motivos pela busca de estudo e compreensão de processos.

16 16 Em síntese o BPM tem como um dos seus principais fundamentos, a realização dos objetivos de uma organização através da melhoria da gestão e do controle dos seus processos de negocio essenciais Jeston (2006). A teoria do BPM foi desenvolvida para apoiar o desafio de gerir organizações centradas em processos. É relevante entendimento que os sistemas de gestão de processos se apóiam no domínio do conhecimento do negócio da organização, unindo gestão do negócio e ti. O BPM como um modelo de gestão estudado por diferentes autores e profissionais, necessariamente depende da execução de determinadas tarefas para garantir a passagem de bastão processo entre os diferentes de setores da empresa. Estas tarefas são organizadas em modelos de referencia ou ciclos de BPM segundo alguns autores. Abaixo a tabela 1 apresenta de forma sucinta as tarefas que os principais autores consideram necessárias em seus modelos para que o BPM cumpra seu papel: Tabela 1: Lista de Modelos em BPM. Autor(es) Modelo de Harrington, Esseling & Nimwegen (1997) Modelo de Burlton (2001) Modelo de Jost & Scheer (2002) Modelo de Smith & Fingar(2003) Modelo de Khan (2003) Modelo de Muehlen & Ho (2005) Tarefas ou Ciclos de BPM Organização; Documentação; Análise; Design; Implantação; Gerenciamento. Contexto de Negócio; Arquitetura e alinhamento; Visão; Compreensão do processo; Renovação; Desenvolvimento; Implantação; Uso e melhoria continuada. Design; Implantação; Controle. Descoberta; Design; Otimização; Desenvolvimento; Execução; Interação; Monitoramento e controle; Análise. Modelar; Otimizar; Automatizar; Gerenciar; Gerenciar. Especificação de metas, análise do ambiente; Design; Implantação; Execução; Avaliação.

17 17 Modelo de Havey (2006) Modelo de Schurter (2006) Modelo de Kirchmer (2006) Modelo de Jeston & Nelis (2006) Obtenção de requerimentos; Documentação dos casos de uso; Arquitetura e design; Desenvolvimento; Testes; Produção. Estratégia; Design; Otimização; Execução; Controle. Estratégia; Design; Otimização; Execução; Controle. Estratégia da organização; Arquitetura de processos; Lançamento; Compreensão; Inovação; Desenvolvimento; Pessoas; Implantação; Análise de valor realizado; Desempenho sustentável.

18 Modelagem de Processos Em análise aos modelos apresentados na tabela 1 podemos notar que todos apresentam uma etapa de modelagem ou design, esta etapa é entendida pelos autores, como sendo uma tarefa inicial em projetos de BPM, depois de concluída toda análise estratégica e definição do(s) processo(s) que vão compor o projeto de BPM. Por conseqüência esta etapa de modelagem é a que tem maior visibilidade nos ciclos de BPM, é nesta etapa que o processo em questão é capturado juntamente com seus fluxos de informações, materiais e são registrados para que possam ser entendidos e discutidos pelas pessoas interessadas no seu entendimento. A grande maioria dos autores divide esta etapa em duas: a modelagem (As Is) que é a captura atual do processo e a (To Be) que envolve a melhoria do processo. Baldam et al. (2007) define alguns usos específicos para o modelo de processos: a. Discutir e compreender os processos; b. Apoiar a melhoria contínua; c. Simular alternativas; d. Especificar os sistemas de informação que vão suportar o negócio. Existem hoje muitas metodologias de modelagem de processos e representações especificas para documentar um processo de negócio, hoje as de maior destaque são: BPMN (Business Processes Modeling Notation) e A Arquitetura ARIS 1. O importante desta tarefa nos ciclos de BPM é que o seu resultado, o modelo de processos de negócio, formaliza as operações das organizações e com este conhecimento é possível estudar formas de melhorar e informatizar processos com excelência tornando-os mais ágeis e competitivos frente à concorrência. 1 ARIS Arquitetura de Sistemas Integrados

19 BPMN (Business Processes Modeling Notation) Afim do melhor entendimento do modelo de processos tanto pelo analista de processos quanto por gerentes, participantes do processo e analistas de sistemas, têm se visto cada vez mais propostas de padrões para especificação e modelagem de processos. Assim o BPMI (Business Process Management Institute), uma organização sem fins lucrativos, e voltada ao desenvolvimento de especificações abertas para o gerenciamento de processos empresariais, buscou a padronização destas propostas criando, em 2004, o BPMN (Business Process Management Notation). O BPMN é uma especificação para modelagem visual de processos, que tem por objetivo obter uma interface simples e fácil de ser compreendida e utilizada, porém possuidora de recursos que conseguem expressar modelos complexos de processos de negócio. É uma série de padrões de representações gráficas e de lógicas para modelagem e desenho de processos de negócio. O objetivo da notação é expressar os processos de negócio em um único diagrama de processos de negócio (BPD Business Process Diagram) e, para tanto, define um pequeno grupo de categorias, facilitando o entendimento dos diagramas. A figura 3 abaixo representa um exemplo de diagrama utilizando os elementos básicos de notação.

20 20 Figura 3: Representação BPMN Fonte: Autor

21 Arquitetura ARIS de Modelagem Arquitetura ARIS foi criada com o propósito orientar as organizações na busca do alinhamento entre sua arquitetura de sistemas e os requerimentos estratégicos do negócio, através da integração entre Estratégia, Processos e Sistemas, reduzindo custos e aumentando a eficiência. Esta arquitetura está dividida em cinco vistas (Organização, Função, Dados, Processos e Produtos/Serviços) e cada vista se divide em três níveis (Definição de Requisitos, Projeto e especificação e por fim, implementação). Desta forma a complexidade da modelagem fica reduzida, permitindo a análise da organização de diferentes pontos de vista de sua arquitetura de negócio (Negócio, Organização, Tecnologia e Métodos). Cada vista particularmente agrupa categorias de informações específicas sobre os processos, sendo que à vista de processos atua de forma integradora às demais. Figura 4: ARIS House Fonte: IDS Scheer (2007)

22 22 Segundo Valadares (2001) e de acordo com o ARIS Method (2000), a arquitetura possui dois principais objetivos: 1) Permitir a utilização integrada de diferentes métodos de modelagem, concentrando sua utilização em seus pontos de foco; 2) Servir de orientação para a realização de projetos complexos de desenvolvimento através de um processo de desenvolvimento implícito à arquitetura. A arquitetura ARIS apresentada na figura 6 permite a utilização de diferentes metodologias e modelos para construção de soluções integradas, como exemplos podem ser utilizados modelos da BPMN descrita no tópico anterior. Os modelos que ganham destaque são: o VAC Value-add chains utilizado para representar às Cadeias de Valor e o EPC Event-Process Chains (Cadeia de Processos Orientados a Eventos). Normalmente o EPC é utilizado para o detalhamento de cada um dos processos individuais mostrados na cadeia de valor, sendo este modelo responsável pela integração de todas as vistas. O EPC representa um processo de negócio, como uma combinação de atividades e eventos (quando necessários) em relação de seqüência. A Figura 5, abaixo, apresenta um EPC em detalhamento da cadeia de valor.

23 23 Figura 5: EPC detalhando a cadeia de valor processo de vendas Fonte: Autor

24 24 CAPÍTULO II A IMPORTÂNCIA DO ESCOPO EM PROJETOS SEGUNDO AS BOAS PRÁTICAS DO PMI O PMI (Project Management Institute) é a principal associação mundial de gerenciamento de projetos, que durante seus 40 anos de existência é responsável pela disseminação da melhores praticas e experiências em gerenciamento de projetos. O PMI é responsável pela publicação do guia PMBOK (Project Management Body of Knowledge) de boas práticas em gerenciamento de projetos composto por 42 processos distribuídos entre 9 áreas de conhecimento representadas na figura 6 abaixo e gerenciados pela integração dos processos de: Iniciação, planejamento, execução, monitoramento e controle, e encerramento. Figura 6: Áreas de Conhecimento em GP. Fonte: Autor, adaptado PMI (2008)

25 25 Considerando a relevância de entendimento da área de conhecimento Escopo para esta pesquisa, as demais áreas de conhecimento representadas na figura 6 não serão tratadas. A área de conhecimento escopo agrupa os processos de Gerenciamento do Escopo do projeto necessários para garantir que o projeto inclua todo trabalho necessário e apenas este, PMI (2008). Abaixo segue os processos relacionados ao gerenciamento do escopo do projeto. o Coletar requisitos: Define e documenta as necessidades das partes interessadas para alcançar os objetivos do projeto. Existem 2 tipos de requisitos que devem ser considerados, os requisitos de projeto que estão relacionados ao gerenciamento e entregas e os requisitos do produto que são requisitos técnicos, de segurança, de desempenho. A saída deste processo é o documento de requisitos que será insumo para o próximo processo de planejamento do escopo, listado a seguir e especifica o que o produto deve ser capaz de executar. o Definir escopo: Desenvolve uma descrição detalhada do projeto e do produto. O documento gerado por este processo é declaração de escopo que é o detalhamento de outro documento o termo de abertura do projeto junto com as informações que vem do levantamento de requisitos ou do contrato com o cliente. Uma declaração de escopo deve conter: a descrição do escopo do projeto, as entregas relacionadas a cada fase do projeto, exclusão/limites do projeto, premissas e restrições. o Criar EAP (Estrutura Analítica do Projeto): Decompõe o trabalho do projeto em entregas menores de gerenciamento mais fácil. A EAP é a representação gráfica do projeto e de todo trabalho especificado na declaração de escopo. Define em pacotes de

26 26 trabalho o entregável final do projeto, o PMI (2008) recomenda que o desdobramento em pacotes de trabalho ocorra em nível que o trabalho possa ser gerenciado com segurança. Figura 7: Exemplo de EAP Fonte: Autor, adaptado PMI (2008) o Verificar o escopo: formaliza a aceitação das entregas terminadas do projeto, neste processo é obtido o aceite formal do cliente ou patrocinador; o Controlar o escopo: monitora o andamento do escopo do projeto e do produto e gerenciamento das mudanças feitas. Um projeto é realizado com objetivo de entregar um produto/serviço, cuja suas características devem estar em conformidade para uso, conforme requisitos definidos pelo cliente, as atividades de gerenciamento de projetos realizadas para construção deste produto, devem ser entendidas como o escopo do projeto que é verificada confrontando a EAP. Já o escopo do produto refere-se às funções ou características que devem ser incluídas no

27 produto e deve ser verificado confrontando os requisitos do produto. 27

28 28 Figura 8: Escopo do Produto X Projeto. Fonte: Autor, adaptado PMI (2008) Dentre as áreas de conhecimento do PMBOK, a mais importante para determinação do sucesso de um projeto é o gerenciamento do escopo, dar segmento em um projeto sem um planejamento e controle do escopo é um passo em direção ao fracasso. Segundo pesquisa realizada pelo Standish Group, 2006 apenas 35% dos projetos de TI são entregues com sucesso, os outros 65% falham ou excedem restrições de tempo e custo. A mesma pesquisa revela que o maior fator de falha em projetos esta relacionada aos requisitos de usuário incompletos. Outro dado importante é que de 25-40% do gasto em projetos de TI (PM World Today, 2007) estão relacionados a retrabalho em função de requisitos mal definidos. Um projeto é concluído com sucesso quando: Os objetivos iniciais foram alcançados; Foi entregue dentro do escopo, prazo, orçamento e a qualidade planejada; Cliente satisfeito com o produto/serviço final.

29 29 Definir o escopo corretamente é parte inicial do planejamento do projeto, nesta etapa é definido o que vai ser entregue, se não se é capaz de ter clareza da necessidade que deve ser atendida, fica extremamente complexo gerenciar, é fracasso na certa. Apesar da literatura sobre o assunto ser bem extensa e a realidade é diferente, devido aos prazos apertados. Muitos projetos começam com uma vaga idéia do se deseja trazendo conseqüências bem típicas como: retrabalho atrasos em cronogramas, cancelamentos em projetos, custos acima do orçado, insatisfação dos clientes e conflitos entre as equipes. Além dos fatores internos ao projeto existem cenários externos que influenciam no escopo definido, mesmo que este esteja consistente e bem elaborado, mudanças em aspectos do negócio, tecnologias envolvidas e até aspectos econômicos que influenciem os patrocinadores podem gerar mudanças no escopo já elaborado. Estas interferências geram mudanças e que quando mal controladas podem trazer grandes desvios, prejudicando o resultado final do projeto. O PMI (2008, p.92) considera que o gerenciamento está relacionado principalmente com a definição e controle do que está e do que não está incluso no projeto. O gerenciamento de escopo é fundamental para condução do gerenciamento de outras áreas como: Custo, Tempo e Qualidade. Inclusive juntas estas são conhecidas como a restrição tríplice do projeto, a variação de uma delas influência no resultado da outra.

30 30 Figura 9: Restrições em GP. Fonte: Autor, adaptado PMI (2008) Segundo Ângelo (2009) o escopo de um projeto além de ser claramente definido, deve ser formalizado através de um processo. É importante que esteja registrado e validado pelo cliente num documento formal onde fiquem claro suas expectativas e desejos, incluindo inclusive o que não vai ser feito, o PMI (2008) define a declaração de escopo como documento de controle do projeto. Controlar as expectativas e desejos de todas as partes interessadas no projeto esta além de qualquer técnica ou guia, cabe a figura do Gerente de Projetos através de uma boa comunicação para buscar o envolvimento do cliente no processo de gerenciamento de escopo e em todas as fases relacionadas a definições importantes do projeto (custos, prazos), tornando-o co-responsável pelo sucesso do projeto.

31 31 A figura 10 a seguir finaliza e consolida bem a importância do escopo em um projeto, esta figura apresenta os usos da EAP que é representação gráfica de tudo que deve ser realizado para o sucesso do projeto. Figura 10: Usos da EAP. Fonte: Autor, adaptado PMI (2008)

32 32 CAPÍTULO III O QUE A GESTÃO DE PROCESSOS DE NEGÓCIO PODE AGREGAR NA MELHORIA DO ESCOPO EM PROJETOS DE SOFTWARE A colaboração entre o departamento de TI Tecnologia da Informação e de negócio de uma organização é objeto de investigação de muitos autores e profissionais ao longo dos últimos anos e como resultado podemos citar o BPM, que tem o objetivo de viabilizar o gerenciamento das organizações orientadas a processos. Um dos fatores que permitem o sucesso das estratégias centradas no BPM é sem sombra de duvidas o entendimento comum, a primeira vista parece ser fácil, porém integrar a visão do pessoal de TI e os gestores do negócio não é tarefa difícil. Aspectos culturais da organização e fatores pessoais como os diferentes perfis de formação dos profissionais de TI e Gestores geralmente geram uma fronteira que na maioria das vezes se não quebrada, pode fazer com que o produto de TI entregue não atenda os requisitos de qualidade e uso definidos pelo o cliente. Hoje com a grande difusão dos SIGs Sistemas Integrados de Gestão, que é um software cujo objetivo é tornar possível a gestão global das empresas, a visão do negócio, ou seja, os processos da cadeia de valor da organização devem estar alinhados a estratégia da empresa e os requisitos de software devem refletir em seu escopo todo o suporte necessário a este processo. Este alinhamento entre o processo de negócio e o sistema de informação que dará suporte a este processo é importantíssimo, pois o mesmo

33 33 é o objeto tangível que a corporação vai trabalhar e em atividades operacionais vai ser a forma de disseminação dos processos de negócio para empresa. Segundo Paim et al. (2009), o projeto de SI - Sistemas de informação, quando desenvolvidos a partir dos processos de negócio traz a importância de se evitar a produção de sistemas redundantes. A existência de uma gestão sobre o desempenho do processo (BPM) pode minimizar o grande equivoco de especificar em um SI com processos obsoletos que vão cristalizar pela organização os erros do passado. Observando os modelos de referência em BPM citados no tópico 1.3 podemos verificar uma etapa de modelagem ou desenho do processo, que é considerada como fase inicial em qualquer iniciativa em BPM e também serve como insumo para especificação e desenvolvimento de sistemas de informação por intermédio do modelo de processos de negócio gerado. Neste ponto da pesquisa acredito que já tenhamos insumos para alinhavar o objetivo deste estudo que é a identificar o que pode ser agregado com o uso das disciplinas de gestão apresentas quando aplicadas na melhoria da qualidade de projetos de software, que tem ligação direta com o correto planejamento do escopo ou levantamento de requisitos. O PMI difunde amplamente através do seu Guia PMBOK como relevante o gerenciamento do escopo como uma área de conhecimento a ser gerenciada em qualquer projeto. Em projetos de sistemas os requisitos que vão compor o escopo do projeto são levantados pelos analistas de requisitos e quase que em sua totalidade junto a usuários finais, que muitas vezes não tem a visão sistêmica do que sua atividade influência em outras áreas, o problema é levantando de maneira vertical o que gera uma solução que atende somente um departamento em especifico. Este fato é agravado em grandes corporações onde à distância do usuário final e quem dá o direcionamento estratégico do negócio é muito grande, no caso a percepção do escopo deste projeto vai se distanciando cada vez mais da necessidade. O termo requisitos em software está relacionado à solução de determinado problema do negócio exposto por um cliente, porém como no

34 34 caso citado acima nem sempre o cliente tem conhecimento do que realmente o negócio precisa. O BPM tendo como elo à modelagem de processos de negócio vem agregar ao gerenciamento de escopo a melhoria da qualidade do requisito final do projeto, pois entre outros aspectos auxilia: o No entendimento da visão do todo onde o problema se insere e o que esta envolta; o Avaliação dos impactos da solução em outras áreas que possuem sistemas semelhantes; o Formalização de como cada atividade deve feita, não ficando a critério do usuário sua definição, que pode variar de usuário a usuário; o Permite identificar a real necessidade do cliente. É consenso de que o correto mapeamento de requisitos é fundamental para o sucesso de projetos de software e que problemas com este impacta diretamente o custo, o prazo e a qualidade do projeto. A visão por processos e seus desdobramentos auxilia a análise do todo de forma mais assertiva aumentando o percentual de sucesso em projetos de desenvolvimento de software.

35 35 CONCLUSÃO Hoje o uso da TI é muito forte em todas as organizações para a informatização de seus processos de negócio, com isso a TI tornou-se o grande habilitador da disseminação da estratégia organizacional dentro das empresas, ganhando destaque os Sistemas Integrados de Gestão (ERP s) que integram a gestão dos diferentes processos da cadeia produtiva da empresa. Na visão por processos, cujo foco é identificação das interfaces organizacionais entre os diferentes departamentos que vão dar suporte ao processo de negócio, onde os processos sobre esta nova ótica devem atravessar toda a organização para entregar os resultados definidos na estratégia organizacional. A organização passa a ter o foco do processo orientado ao cliente final e não mais as metas funcionais de cada departamento. A Gestão de processos de negócio (BPM) neste contexto vem fomentar o apoio à gestão de empresas orientadas a processos. Um dos ganhos que o BPM promove é o entendimento comum à cerca das operações da empresas, materializado no modelo de processos de negócio gerado em fase inicial de modelagem do ciclo de BPM. Entende-se como ciclo de BPM, as etapas necessárias para o gerenciamento dos processos que em síntese são: O levantamento inicial (As is); Melhoria do processo (To be) implantação; Monitoramento e controle. Em projetos de TI, especialmente em projetos de desenvolvimento de softwares, na pratica, em sua grande maioria começam com prazos apertados e com definições muitas vezes não conclusivas. Isso piora durante o andamento do projeto, que como conseqüência sofre constantes mudanças e quando o escopo é modificado as restrições de qualidade, tempo e custo são terrivelmente afetadas comprometendo o sucesso do projeto.

36 36 O cenário de insucesso em projetos de software tem uma das causas problemas a forma como os requisitos são levantados, devido à cultura das equipes levantamento de requisitos ainda estarem focadas em atividades de usuário e protótipos de tela. Esta abordagem traz vícios e percepções individuais sobre as necessidades/funcionalidades que o software deve apresentar, e que pode trazer durante o processo de validação do produto outras necessidades, pois o cliente que valida o produto final muita das vezes não foi o mesmo que participou do levantamento dos requisitos e definição do escopo do projeto. Para melhor assertividade no sucesso no projeto de desenvolvimento de software que venha a dar suporte a qualquer processo produtivo da organização, é importante que à visão do todo, entendida neste estudo como Visão por Processos, esteja inserida no levantamento dos requisitos deste software. Como beneficio agregados desta abordagem incluem-se: A construção de software reutilizáveis, que a visão de desenvolvimento departamental não proporciona; Software implementando as necessidades do processo na ótica da organização, conforme estratégia definida e não percepções individuais. Em conclusão é esperado que a visão por processos, materializada na etapa de modelagem através do modelo processos de negócio, possa ser agregada as técnicas de modelagem de sistemas atuais com o propósito de elevar o percentual de sucesso em projetos de desenvolvimento de software. É claro que como uma abordagem onde o departamento de TI deve exercer o papel de integrador das diferentes áreas de negócio da organização, implica no surgimento de novos aspectos culturais que devem ser conduzidos pelo gestor do projeto. Estes aspectos não são abordados nesta pesquisa, mas podem ter seu desdobramento em temas para trabalhos futuros.

37 37 BIBLIOGRAFIA CONSULTADA ANGELO, M. A importância do escopo num projeto. Rio de Janeiro: AVM/Candido Mendes, ANTUNES Jr., J. A. Os paradigmas na engenharia de Produção. Rio de Janeiro: COOPE/UFRJ, ANTUNES, JR. J. A. V., CAULLIRAUX, H. E NEVES, M. - A Organização por Processos. São Paulo: Grupo de Produção Integrada/COPPE-EE/UFRJ, SAP Universe, BALDAM, R. et al. Gerenciamento de processo de negócios: BPM Business Process Management. 2ª Ed. São Paulo: Érica, HARMON, P. Business process change: a manager s guide to improving, redesigning, and automating processes. San Francisco: Morgan Kaufmann, IDS SCHEER AG. ARIS Methods. Version 5.0, 2000 JESTON, J.,NELIS, J. Business Process Management: practical guidelines to successful implementations. Oxford: Elsevier, JESUS, L. BPM não é tecnologia, é orientação para gestão.<url: data de acesso:16/07/2010 PAIM, R., CAMEIRA, R., e CLEMENTE, A. e CLEMENTE, R. Engenharia de Processos de negócios: aplicações e metodologias.grupo de Produção Integrada/COPPE-EE/UFRJ, Enegep 2002, Curitiba, PAIM, R., [et al.]. Gestão de processos: pensar, agir e aprender. 1ª ed. Porto Alegre: Bookman, PORTER, M. E., Estratégia competitiva: Técnicas para análise de indústrias e da concorrência. 2.ed. Rio de Janeiro: Campus, 1989.

38 38 SALERNO, M. S., Projeto de Organizações Integradas e Flexíveis: processos, grupos e gestão democrática via espaços de comunicação negociação. 1ª ed. São Paulo, Atlas, SMITH, H., FINGAR, P. Business Process Management: the third wave. 1ª ed. Tampa: Meghan Kiffer Press, PROJECT MANAGEMENT INSTITUTE (PMI). Guia PMBOK: Um guia do conhecimento em gerenciamento de projetos. 4ª ed. PMI Standart Committee, 2008 SILVA, ANDRÉ VALADARES. Modelagem de Processos para Implementação de Workflow: uma avaliação crítica [Rio de Janeiro] 2001 XII, 405 p. 29,7 cm (COPPE/UFRJ. M.Sc., Engenharia de Produção, 2001) Tese - Universidade Federal do Rio de Janeiro, COPPE. VARGAS, R. Gerenciamento de projetos: estabelecendo diferencias competitivos. Rio de Janeiro: Brasport, 2002.

39 39 ÍNDICE FOLHA DE ROSTO 2 AGRADECIMENTO 3 DEDICATÓRIA 4 RESUMO 5 METODOLOGIA 6 SUMÁRIO 7 INTRODUÇÃO 8 CAPÍTULO I OS PRINCIPAIS CONCEITOS SOBRE GESTÃO DE PROCESSOS DE NEGÓCIO Processos de Negócio Visão por Processos Gestão de Processos de Negócio Modelagem de Processos BPMN Arquitetura ARIS de Modelagem 21 CAPÍTULO II A IMPORTANCIA DO ESCOPO EM PROJETOS SEGUNDO AS BOAS PRATICAS DO PMI 24 CAPÍTULO III O QUE A GESTÃO DE PROCESSOS DE NEGÓCIO PODE AGREGAR NA MELHORIA DO ESCOPO EM PROJETOS DE SOFTWARE 31

40 40 CONCLUSÃO 34 BIBLIOGRAFIA CONSULTADA 36 ÍNDICE 38

41 41 FOLHA DE AVALIAÇÃO Nome da Instituição: Título da Monografia: Autor: Data da entrega: Avaliado por: Conceito: