Avaliao da Automatizao de Processos de Negcio em Servios Partilhados

8 Congresso Nacional da Administrao Pblica Desafios e Solues 2011 Resumo

Com a implementao de servios partilhados na Administrao Pblica Portuguesa, foi necessrio encontrar formas eficientes responder s necessidades dos Organismos, bem como potenciar estratgias dos prprios servios partilhados. A automatizao de processos assente numa arquitectura SOA, visou dar resposta a estas necessidades. No entanto, para avaliar os efectivos ganhos decorrentes da automatizao, necessrio traduzi-los em benefcios mensurveis. Este artigo centra-se na proposta de um modelo de avaliao de benefcios que visa responder a estas necessidades. Palavras-Chave: Servios Partilhados, Business Process Management, Automatizao de Processos de Negcio, Gesto de Benefcios

1.1 Introduo
Em 2007, foi iniciada uma nova estratgia organizacional na Administrao Pblica Portuguesa que visou a implementao de servios partilhados, com o objectivo de concentrar os Organismos pblicos na sua verdadeira misso, passando os processos de suporte para uma Organizao especializada na prestao de servios partilhados, centralizando bases de dados e, ao mesmo tempo, disseminando o plano oficial de contabilidade pblica. Para a prestao destes servios partilhados, foi desenvolvida uma aplicao financeira assente numa arquitectura SOA, onde so automatizados processos de negcio

disponibilizados aos utilizadores a partir de 2009. Esses processos de negcio so normalizados seguindo uma metodologia Business Process Management (BPM), com o objectivo de melhorar a eficincia, qualidade dos dados, e estabelecer melhores prticas relativamente aos processos actualmente realizados de forma transaccional. A avaliao dos benefcios inerentes automatizao dos processos de negcio relevante para apurar o verdadeiro impacto que estes podem ter na prestao de Servios Partilhados. Pretende-se assim, nesta dissertao, desenvolver um modelo de avaliao de benefcios da automatizao de processos de negcio em Servios Partilhados, seguindo uma abordagem de Gesto de Benefcios, bem como submeter o modelo a uma avaliao atravs de um caso de estudo.

2.1 Reviso da Literatura

Este captulo tem como objectivo expor o estado actual de conhecimento relativamente s temticas abordadas ao longo do artigo: Servios Partilhados; Business Process Management (BPM) Automatizao de Processos de Negcio Service Oriented Architecture (SOA) Gesto de Benefcios

2.1 Servios Partilhados Servios Partilhados (SP) so definidos como uma estratgia colaborativa em que um subconjunto de funes de negcio existentes, so concentradas numa nova unidade de negcio autnoma que possui uma estrutura de gesto desenhada para promover a eficincia, a gerao de valor, reduo de custos e melhorar os servios prestados [Bergeron, 2003] A OCDE, numa ptica governamental, define no seu relatrio de eficincia 2009, servios partilhados como unidades governamentais que prestam servios de suporte a mais do que um ministrio, ou subsector governamental. [OCDE, 2009] Espera-se com o modelo de servios partilhados: Aumento da eficincia: A normalizao de processos e a adopo de tecnologias quando e onde apropriadas, levam ao aumento da qualidade dos servios e a preos comparativamente inferiores; Diminuio da necessidade de pessoal: Focando as pessoas em objectivos especficos, so necessrias menos pessoas para atingir os mesmos resultados; Ganhar economias de escala: Os SP concentram as reas de compras e outras reas de negcio dispersas como a contabilidade. Esta concentrao de recursos especializados permite o aumento de economias de escala, comparativamente estrutura original da empresa; e Foco das Empresas nas suas competncias core: Actividades de suporte so geridas pelo CSP, focando-se a empresa nas suas competncias core.

Tanto a nvel do sector pblico como do sector privado os servios partilhados tm proliferado. No mbito do sector pblico, pases como a Inglaterra, Dinamarca, Finlndia, Sucia e Holanda, atingindo poupanas considerveis. Em 2006, Varney, apontava para que fosse possvel reduzir atravs dos SP, 20% dos custos em servios de recursos humanos e financeiros [OCDE, 2009]. Tambm no sector privado, empresas como a Portugal Telecom, Sonae Sierra e Mota Engil, contam j com esta estratgia colaborativa.

2.2 Business Process Management (BPM) Em 2008, a Gartner, definiu BPM como conjunto de disciplinas que acelera a melhoria efectiva dos processos de negcio misturando mtodos incrementais e transformadores. [BPTGroup, 2009]. Para Jorg Becker [Becker, 2003], um processo de negcio uma sequncia lgica, fechada e temporalmente medida, de actividades que so necessrias para trabalhar num processo orientado a um objecto de negcio. O BPM nasceu com a evoluo da forma de encarar e gerir um processo de negcio. Nos anos 80, com o surgimento do conceito de Total Quality Management (TQM), mais associado aos processos industriais [Dhooke, 2008], e que visava garantir a qualidade dos produtos atravs da melhoria contnua dos processos, estabeleceu as primeiras bases que deram posteriormente origem ao conceito de BPM. No entanto, o conceito de TQM no evoluiu directamente para o conceito de BPM. Anteriormente ao conceito de BPM, surgiu o conceito de Business Process Re-Engneering (BPR) que se distanciava totalmente do conceito de TQM, defendendo que os processos no deveriam ser melhorados continuamente, mas deveriam ser redesenhados [Dhooke, 2008]. O conceito de BPM aproximou-se novamente do TQM, defendendo princpios semelhantes e baseando-se na melhoria dos processos de forma contnua ao longo do seu ciclo de vida. Uma metodologia BPM composta por quatro fases com o objectivo de normalizar o processo, atingindo o mximo de qualidade nos processos de negcio, melhorando seu desempenho. [Wurtzel, 2007]:

Document

Assess

Improve

Manage

Figura I - Fases do BPM [Wurtzel, 2007]

Document: Documentao de todo o processo e de todas as suas actividades; Assess: Avaliar a performance do processo e identificar mtricas usando os resultados como base para a melhoria do processo; Improve: Melhorar o processo com vista a aumentar a qualidade, eficincia e satisfao do cliente; e, Manage: Gerir o processo atravs do fluxo de informao, aces e actividades;

Esta metodologia BPM, que tem uma viso mais Organizacional dos processos, pode ainda ser complementada com outras metodologias de abordagens mais especficas, como o caso do Six Sigma e o Lean Management [Wurtzel, 2008]. A Six Sigma permite uma abordagem centrada num estudo estatstico sobre os indicadores do processo com vista a melhor-lo. J a Lean Management, permitem olhar o processo sob o ponto de vista das actividades core, reduzindo o fluxo ao mnimo possvel [Morris, 2009].

2.3 Automatizao de Processos de Negcio Durante os ltimos quinze a vinte anos, cada vez mais processos de negcio tm sido suportados por softwares transaccionais como Enterprise Resource Planning (ERP), Supply Chain Manager (SCM) ou Customer Relationship Manager (CRM) que permitiram segundo August Scheer [Scheer, et all., 2004], vrias vantagens para as empresas, que vo desde o controlo dos processo at prpria transparncia das suas contas e da adopo de melhores prticas. No entanto, a automatizao de processos de negcio evoluiu para os wokflows que suportam, adequam e normalizam os processos, mantendo os ERPs, SCMs e CRMs apenas como aplicaes onde so guardados os dados pelas ferramentas de workflow. Esta integrao de sistemas designa-se por Enterprise Application Integration (EAI). [Scheer, et all., 2004] A definio, criao e gesto da execuo dos workflows feita atravs dos Business Process Management Systems (BPMS) que tm a capacidade de interpretar os processo e actividades atravs de regras de negcio, interagir com os actores, e quando necessrio, invocar outras ferramentas ou aplicaes. A maioria dos workflows so integrados com outros sistemas, como sistemas de gesto documental, bases de dados, sistemas de e-mail, sistemas de informao geogrfica, aplicaes de produo e sistemas independentes. [Papazoglou, 2008]

Figura II - Nova Gerao de Automatizao de Processos [Scheer, et all., 2004]

Para Hedge [Hedge, 2005], BPMS uma plataforma de software que permite ao utilizador projectar, executar e gerir um processo de negcio completo, utilizando um nico motor. Segundo Katz [Katz, 2005], os BPMS so uma nova soluo tecnolgica projectada para fcil criao, operao e modificao do negcio orientado a processos. Este tipo de software, permite a monitorizao, controlo e alterao dos processos em tempo real, sendo os primeiros a possibilitar process-centric integration, que significa a integrao de pessoas, sistemas e dados, transcendendo os tradicionais workflows que apesar de permitirem a integrao de actores humanos, no tm capacidade de integrao de aplicaes robustas. Podemos encontrar vrias abordagens ao mercado por parte das mais conhecidas empresas de tecnologias. Podem distinguir-se dois tipos de BPMS: os que so completamente integrados (por exemplo PRPC e Lombardi) vendidos como um todo, que no necessitam de

outro tipo de aplicaes para desempenhar as funes de um BPMS, e os BPMS que carecem de integrao com outras aplicaes fundamentais constituio de uma arquitectura que possa prestar um servio completo (por exemplo Sequence, Metastorm).

2.5 Service Oriented Architecture (SOA) A IBM define SOA como uma arquitectura que fornece flexibilidade para satisfazer os processos de negcio e as infrastruturas tecnologias que no so visveis atravs de componentes standard (servios) que podem ser reutilizados e combinados para responder s mudanas do negcio. Uma arquitectura SOA baseia-se nos seguintes princpios [Sweeney, 2010]: Baixo Acoplamento: Princpio no qual os consumidores de servios e os servios so isolados das mudanas ocorridas na tecnologia subjacente e no seu comportamento; Interoperabilidade: Este um princpio que elimina as especificidades e

constrangimentos tecnolgicos. Permite aos consumidores de servios e aos servios que so desenvolvidos em diferentes plataformas e tecnologias, a troca de informao e colaborao. No fundo permite s diferentes aplicaes comunicarem entre si; e, Reutilizao: Numa definio simples, trata-se de usar algo mais do que uma vez. Este princpio tem enfse principalmente numa viso sobre os custos de implementao das arquitecturas de negcio. Quando um consumidor expressa novos requisitos, os servios actualmente existentes podem no ser influenciados, ou seja, no necessitam de sofrer alteraes, pelo que podem ser reutilizados. Isso pode significar a diminuio de custos de desenvolvimento. Uma arquitectura SOA potencia uma estratgia de servios partilhados, uma vez que existem desafios comuns entre ambos:

Figura III - Desafios comuns de SOA e SP [Greer, et all., 2007]

2. Avaliao de Benefcios O conceito de benefcio muito relativo, dependendo de quem considera o prprio benefcio. No entanto, pode-se definir benefcio como uma mudana positiva que pode ser entendida por pelo menos um Stackholder [Bradley, 2006]. Estes podem ainda ser tangveis quando so mensurveis atravs de mtricas objectivas, ou intangveis que podem ser julgados subjectivamente e qualitativamente, como por exemplo as melhorias de satisfao dos clientes [Ward, et all., 2007]. A avaliao de benefcios tradicional centrava-se exclusivamente nos benefcios tangveis, na sua maioria das vezes em clculos financeiros como o Retorno do Investimento (ROI), o Valor Actual Lquido (VAL) ou a Taxa Interna de Retorno (TIR). Este tipo de abordagem confundia-se com o termo business case [Ross, 2002]. No entanto, esta viso dos benefcios apenas se traduzirem em resultados financeiros, uma viso limitativa dos mesmos, uma vez, que a existncia de por exemplo, benefcios intangveis, no contabilizada, o que no traduz os ganhos reais de um determinado projecto. [Lambert, et all., 2003] Assim, foi necessrio partir para uma nova abordagem de gesto de benefcios cujo objectivo permitir que os benefcios potenciais decorrentes da utilizao de tecnologias de informao nas organizaes, sejam alcanados [Ward, et all., 2007] e que permita dar resposta tanto a gestores de negcio como a gestores de IT.

De Foco na Tecnologia. Valor traduz-se monetariamente. Foco nas Despesas Perca de ligao com as necessidades de negcio. Gestores de Negcio so passivos. Funcionalidades desfocadas do negcio. Stakeholders sujeitos a. Auditorias tecnologia e projectos.

Para Foco no Benefcio. Valor pode ser visto de vrias formas. Foco no business case Integrao com as linhas orientadoras do negcio. Gestores de Negcio envolvidos. Investir no que realmente necessrio. Stakeholders envolvidos em. Obter benefcios e rev-los com as lies retiradas alavancagem de benefcios.

Tabela I - Evoluo da Gesto de Benefcios [Ward, et all., 2007]

Desta nova viso de Gesto de Benefcios resultou um modelo de gesto de benefcios desenvolvida entre 2004 e 2007 atravs do Information System Research Center (ISRC) pertencente Cranfield School Management e que se caracteriza essencialmente por cinco fases, como podemos observar na imagem seguinte:

Figura IV - Ciclo das fases da Gesto de Benefcios [Ward, et all., 2007]

(1) Identificar e estruturar os benefcios

Como objectivo alinhar as estratgias do negcio e as TI, nesta fase procura-se uma convergncia de ambas as estratgias, garantido que investimento est associado a factores impulsionadores de mudana. So estabelecidos, todos os potenciais ganhos e por forma a poderem ser medidos, os responsveis pelos benefcios e riscos inerentes ao projecto. (2) Plano de Realizao dos Benefcios

Com esta fase pretende-se elaborar um plano de benefcios e um business case para o investimento. identificada a forma de medir os benefcios e sempre que possvel uma expectativa materializada em valores. ainda realizada uma rede de dependncias de benefcios. (3) Execuo do plano de realizao dos benefcios

O objectivo desta fase garantir que as aces programadas acontecem efectivamente como planeadas com eventuais milestones para um maior controlo do projecto. (4) Reviso e evoluo dos resultados

Por forma a garantir que os benefcios atingidos, deve ser feita uma avaliao comparativamente aos benefcios propostos no incio do projecto e os realmente alcanados, bem como perceber as razes pelas quais no foram atingidos. (5) Benefcios Anteriores

Olhar os resultados de forma crtica e identificar potenciais novos benefcios decorrentes do projecto. O projecto poder ser reiniciado com o objectivo de alcanar novos benefcios.

Tambm baseado nesta abordagem de gesto de benefcios, e para responder aos desafios das organizaes do sector pblico que vem na eficincia dos seus projectos e prestao dos seus servios uma questo fundamental, [OGC, 2009] o governo ingls atravs do Office of Government Commerce (OGC) desenvolveu um framework de gesto de projectos e gesto de benefcios para dar resposta a estas questes.

Esta framework indica dependncias de alto nvel entre um tpico processo de gesto de benefcios e uma metodologia de gesto de projectos, contendo as actividades standard presentes no Managing Successful Programmes (MPS), e no OGC Gateway Reviews, programas que definem as boas prticas de gesto de projectos. Relativamente gesto de benefcio, a framework contm 5 fases como podemos observar na imagem seguinte:

Figura V - Modelo de Gesto de Benefcios [OGC, 2009]

Este modelo, embora com algumas especificidades do mbito em que se insere, segue a mesma abordagem do modelo anteriormente descrito da Cranfield School Management.

3. Modelo de Avaliao de Benefcios Proposto

Tendo em conta o contexto especfico em que est a ser desenvolvida esta dissertao, optouse por desenvolver um modelo prprio, que embora tenha em considerao os dois modelos em cima descritos e partilhe os mesmos objectivos, dever conter algumas especificidades no contempladas nos anteriores. contemplada a fase de especificao do processo negcio e das decises tomadas nesta fase por forma a atingir os benefcios propostos, atravs da arquitectura tecnolgica e ferramentas tecnolgicas existentes. Esta dimenso tecnolgica tambm includa na anlise podendo ter forte impacto no alcance ou no dos benefcios pretendidos e fundamental para a automatizao dos prprios processos, sendo estes condicionados pela arquitectura tecnolgica j existente. Considerou-se tambm importante o acompanhamento do desenvolvimento e testes do processo, pois importante para avaliar no s o tempo despendido at o processo estar apto a entrar em produo, mas tambm o nvel de erros encontrados, e o impacto que estas dimenses tm no plano inicial e o custo de oportunidade que tm para a empresa.

Finalmente, foi includa uma fase em que ser definida a estratgia de pilotagem em produo e a respectiva anlise de resultados. Assim, este captulo tem como objectivo contribuir para um modelo que permita avaliar os benefcios introduzidos pela automatizao de um processo de negcio em servios partilhados, identificando as oportunidades, especificando e acompanhando o desenvolvimento dos processos, e avaliando posteriormente os seus resultados.
1- Contexto do Negcio Necessidades e Oportunidades 6 - Avaliao dos Resultados Alcanados 2- Benefcios a Atingir, Riscos Inerentes e Business Case

7 - Pilotagem em Produo

3- Anlise da Arquitectura Existente

5 -Acompanhamento do Desenvolvimento / Testes

4 - Especificao do Processo de Negcio

Figura VI - Modelo de Avaliao de Benefcios Proposto

3.1 Fase 1 Contexto do Negcio, Necessidades e Oportunidades A primeira fase do modelo consiste em efectuar uma contextualizao do negcio por forma a definir o mbito do projecto e porque o queremos efectuar. Devem ser abordados os dois tpicos principais: (a) Onde estamos inseridos? Enquadrar o projecto com a estratgia da empresa. (b) O que automatizar? Definir o mbito do que queremos automatizar e quem interage nesse mbito. (c) Porqu automatizar? Definir o porqu de querermos fazer o investimento.

Para responder primeira questo (a), deve ser tida em conta a estratgia da empresa, a sua viso e misso, bem como a sua cadeia de valor, por forma a termos conscincia do que somos, o que queremos ser e o que fazemos de melhor. Em resposta segunda questo (b), deve ser definido claramente o mbito em que iremos trabalhar, qual o processo a automatizar, os cenrios contemplados e as excepes que no faro parte. De acordo com esta definio deve ser feito um levantamento de todos os Stakeholders importantes para a efectiva automatizao do processo, com vista definio de estratgia para cada um deles.

Stakeholder Nome Qual o Papel no Processo? Expectativas Potencial Interesses/Conflitos Importncia/Interesse Estratgias/Actividades para Reduzir Obstculos/Obter Apoio
Tabela II - Tabela de Caracterizao de Stackeholder [BPTGroup, 2009]

Alta Influncia Baixa Influncia

Stakeholder Strategy Baixa Importncia Mitigar Impactos, Defender de. Monitorizar;

Alta Importncia Colaborar com; gerir de perto; Envolver; Motivar; Assegurar interesse;

Tabela III - Estratgias para relacionamento com Stakeholders [BPTGroup, 2009]

Por fim, e como resposta terceira questo, devem ser definidos os bussiness drivers, ou seja, as razes pelas quais se pretende automatizar o processo. Estes podem dividir-se em 3 tipos de estratgias propulsoras: [Ward, et all., 2007] o o o Infra-Estrutura: Quando se relacionam com a evoluo das infrastruturas tecnolgicas que podem permitir melhores resultados; Contexto: Quando se relacionam com o contexto do negcio e que condicionam o mesmo, como por exemplo o contexto legal e poltico; e, Orientada a Resultados: Quando os projectos visam atingir determinado fim, como a reduo de custos, disponibilizao de novo servio, melhorar o desempenho, entre outros.

Deve ainda ser tido em conta o tipo de processo que pretendemos automatizar. O processo deve ser caracterizado quanto sua repetibilidade e grau de ocorrncia. Os processos que sejam feitos sempre da mesma forma e que tenham um grau de ocorrncia elevado, sero

partida processos muito vantajosos de automatizar. Deve ser usada a matriz seguinte para expor graficamente esta classificao.

Figura VII - Repetibilidade vs Ocorrncia do Processo de Negcio

Finalmente, em termos de servios partilhados, devem ser tidas em conta algumas mtricas relevantes, em que o processo tem ou pode vir a ter impacto, por forma analisar o processo quanto ao impacto actual e futuro. Algumas das mtricas a ter em conta so: Nmero de pedidos recebidos; Produtividade Na ptica da entidade prestadora de servios; Na ptica da entidade requerente;

Capacidade de resposta aos pedidos recebidos; Impacto nos recursos - custos inerentes ao processo; Qualidade dos dados Probabilidade de erro e percentagem de erros relativamente aos dados existentes; e, Consolidao de Dados

Normalizao de Processos;

3.2 Fase 2 - Benefcios a atingir, Riscos Inerentes e Business Case

a. Benefcios a Atingir Nesta fase pretende-se identificao de um conjunto de mtricas e benefcios relevantes para o negcio, onde o impacto da automatizao se deve fazer sentir. Estas mtricas devem obedecer s caractersticas SMART. Os benefcios no se devem limitar s tecnologias, mas devem tambm ter impacto no negcio [Ward, et all., 2007] e devem ser prioritizados de acordo com a sua importncia e deve ser identificada a forma como sero medidos.

Benefcio

Descrio

Como medir?

Prioridade

Tabela IV - Tabela de Identificao de Benefcios

Aps serem identificados os benefcios, pretende-se saber como vo ser atingidos. Para isso, realizada a rede de benefcios onde so explicitadas as dependncias entre business drivers, os objectivos do investimento, os benefcios para o negcio, as mudanas no negcio, os factores de mudana e a prpria tecnologia.

Figura VIII - Rede de Benefcios [Ward, et all., 2007]

Esta rede de benefcios dever ser seguida ao longo de todo o projecto e ser fundamental para a avaliao do investimento realizado, tendo em conta os benefcios propostos e os atingidos. b. Business Case

Seguindo as abordagens de gesto de benefcios, pretende-se com o business case, no apenas uma anlise puramente financeira, mas sim uma anlise mais completa tendo em conta os aspectos financeiros mensurveis, mas tambm os benefcios quantificveis e observveis. Esta abordagem permite criar uma base no s para definir os benefcios a atingir e comprometer os gestores de topo com o seu cumprimento, mas tambm para construir uma base para posterior avaliao. [Ward., et all, 2007] Para isso, iniciamos o business case com o preenchimento da seguinte tabela, onde poderemos ter uma primeira anlise de diversas componentes do projecto.

Deixar de usar Processo Antigo Benefcios Quantificar um benefcio atravs do custo/preo ou de uma frmula Financeiros financeira. Benefcios Existem elementos que tornam possvel a previso de quanto ser o Quantificveis benefcio atingido atravs das mudanas a realizar. Benefcios O benefcio pode ser medido, mas no possvel quantificar as Mensurveis estimativas a atingir com as melhorias. Necessita de aplicao de um dado critrio acordado entre Benefcios indivduos ou grupos especficos, que posteriormente decidiro, Observveis baseados na sua experincia se o benefcio foi atingido ou no. Business Case Novo Processo Melhoria de Processos
Tabela V - Business Case [Ward., et all, 2007]

Para completar o business case, devem ser ainda analisados vrios aspectos. Tendo em conta o framework do OGC, vamos analisar o projecto mediante dois vectores: Relevncia e Exequibilidade. Devem ser respondidas as seguintes questes: Relevante? o o o o o o o o Qual a contribuio para os objectivos estratgicos? Qual o valor acrescentado? Qual o nvel de buy-in dos Stakeholders? Como so entendidos os factores de sucesso? Quais as dependncias? Qual o nvel de risco? O mbito adequado e preciso? Os recursos so adequados?

Exequvel?

Depois de respondidas as questes, deve ser preenchida a seguinte matriz com a anlise das questes respondidas.

Figura IX - Exequibilidade vs Relevncia do Projecto

c. Riscos Inerentes ao Projecto Para assegurar que os objectivos do projecto so cumpridos, os riscos devem ser identificados numa fase inicial, para que possam ser devidamente planeadas alternativas e o plano do projecto possa ter em conta estes mesmos riscos. Os riscos de um projecto podem ser considerados de trs naturezas [Ward., et all, 2007]: Tcnica: diz respeito s tecnologias escolhidas, capacidade dos fornecedores entregarem funcionalidades, segurana, performance, e cumprimento dos prazos; Financeira: diz respeito previsibilidade dos custos e confiana nos benefcios financeiros; e, Organizacional: diz respeito capacidade da Organizao e seus Stakeholders em conseguir as mudanas de negcio necessrias para atingir os benefcios.

Risco

Causa

Responsvel

Prob. Ocorrncia

Impacto previsto

Natureza

Tabela VI - Ricos Inerentes ao Projecto, adaptado [OGC, 2009]

3.3 Fase 3 Anlise da Arquitectura Existente

a. Arquitectura Tecnolgica

O facto de estarmos a automatizar um processo de negcio numa arquitectura j existente, leva-nos a ter que ter em conta essa mesma arquitectura, as suas potencialidades, as suas limitaes e a sua envolvente tecnolgica. Devemos ter em conta onde vamos automatizar o processo e quais so as especificidades que temos que lidar, para partida, fazer um levantamento de requisitos consciente e assente na sua grande maioria num estudo slido sobre a arquitectura e sobre as diversas possibilidades de dar resposta aos benefcios pretendidos.

b. Restries aos Benefcios Pretendidos De acordo com os benefcios identificados anteriormente, bem como com a rede de dependncias de benefcios, deve ser feito um levantamento das restries que a arquitectura tecnolgica existente nos coloca. Poder ser necessrio voltarmos a este ponto aquando da especificao do processo e das suas regras de negcio, onde podem ser encontradas limitaes mais tcnicas que podem ter impacto neste mbito.

Restrio

Causa

Impacto

Diminuio Impacto

Tabela VII - Restries da Arquitectura Tecnolgica aos Benefcios Propostos

3.4 Fase 4 Especificao do Processo de Negcio

Nesta fase, pretende-se incluir no modelo de avaliao de benefcios a especificao do processo de negcio tendo em conta uma metodologia BPM. A especificao do processo e o modelo de avaliao devem ser complementares e encadeados, uma vez que a especificao contempla uma anlise de processo relativamente a determinadas mtricas consideradas importantes no mbito da avaliao de benefcios, e a prpria especificao deve ser feita tendo em conta os benefcios que se pretendem atingir e as limitaes da arquitectura tecnolgica existente. Uma metodologia BPM composta pelas quatro fases que podemos observar na figura seguinte, sendo que mediante o processo e o projecto poder ser complementada com uma metodologia SixSigma ou Lean Manager, embora estas no substituam a abordagem BPM.

Document

Assess

Improve

Manage

Figura X - Metodologia BPM [Wurtzel, 2007]

Document: Documentao de todo o processo e de todas as suas actividades; Assess: Avaliar a performance do processo e identificar mtricas usando os resultados como base para a melhoria do processo; Improve: Melhorar o processo com vista a aumentar a qualidade, eficincia e satisfao do cliente; e, Manage: Gerir o processo atravs do fluxo de informao, aces e actividades relacionadas.

Considera-se importante no final desta fase responder s seguintes questes: Que workflow foi desenvolvido e porqu? Tendo em conta os benefcios definidos, quais as opes tomadas, para atingir esses benefcios? Que mtricas foram especificadas e de que forma sero medidas? Qual o tempo de especificao? Qual o custo de oportunidade, no caso dos prazos no terem sido cumpridos?

Tempo de Especificao Datas Previstas Inicio Fim Datas Efectivas Inicio Fim Diferena

Tabela VIII - Avaliao do Tempo de Especificao

3.5 Fase 5 Acompanhamento do Desenvolvimento e Testes Para que o processo seja efectivamente alcanado, e para que sejam atingidos os benefcios esperados, necessrio que este seja desenvolvido e colocado em produo em tempo til, e que seja alvo de um controlo de qualidade que garanta a sua implementao de acordo com a sua especificao

a. Desenvolvimento do Processo de Negcio Automatizado Pretende-se avaliar se o tempo de desenvolvimento previsto corresponde ao real e qual o custo de oportunidade caso tenham existido atrasos. Tempo de Desenvolvimento (Dias) Previsto Efectivo Diferena

Estimado vs Real

Datas de Entrega Prevista Efectiva Diferena

Tabela IX - Avaliao do Impacto do Tempo de Desenvolvimento

b. Testes ao processo de negcio automatizado

Com o acompanhamento dos testes efectuados ao processo, pretende-se avaliar o cumprimento dos prazos de testes, bem como o seu respectivo impacto e custo de oportunidade. Testes ID Teste Ambiente Testes Ambiente Datas Previstas Inicio Fim Datas Efectivas Inicio Fim

Tabela X Acompanhamento/Avaliao dos Testes Realizados

Pretende-se ainda avaliar a quantidade de erros encontrados bem como as interaces entre as equipas de testes e de desenvolvimento at o processo ser dado apto a entrar em produo. Este tipo de anlises importante uma vez que permite avaliar o impacto que atrasos tm no alcance dos benefcios, ou perceber a razo de alguns benefcios no serem alcanados devido a alguma limitao durante estas fases.

Testes ID Teste

Processos Testados N

N de Bugs Encontrados No Crticos Crticos

Deciso Subir de Observaes Ambiente?

Tabela XI - Resumo dos Testes Realizados

3.6 Fase 6 Pilotagem em produo

Aps concluso do desenvolvimento do processo e dos respectivos testes, os processos de negcio so colocados em produo, sendo definidos Organismos piloto por forma a ter um primeiro feedback e uma primeira anlise dos resultados alcanados pelo processo automatizado. A extenso do processo a outros Organismos est dependente desta primeira avaliao. Pretende-se com esta fase definir a estratgia de pilotagem que ser seguida bem como fazer o levantamento e estudo dos benefcios alcanados com o processo em produo atravs das mtricas definidas anteriormente.

3.

Fase 7 Avaliao de Resultados

Nesta fase, propem-se fazer uma anlise relativamente a todo o projecto, centrando-se na anlise dos benefcios tendo em conta os benefcios pretendidos e os benefcios alcanados. Para isso sero tidas em conta as mtricas definidas ao longo do projecto bem como a forma de as medir. Devem ser dadas recomendaes para projectos futuros, e devem ser identificados, caso existam, benefcios a alcanar futuramente.

Benefcios

Resultado processo Manual

Objectivo

Mtrica Processo Automtico

Atingido?

Tabela XII - Resultados Previstos vs Resultados Alcanados

4.

Aplicao do Modelo

O presente modelo descrito no captulo anterior, foi submetido a um caso de estudo na empresa de Gesto de Recursos Partilhados da Administrao Pblica. O caso de estudo refere-se ao projecto de automatizao de um processo de criao e modificao de dados mestre de fornecedores. Aps a aplicao do modelo foi possvel retirar as seguintes concluses:

Fase 1 Contextualizao do Negcio

Esta frase procurou fazer a contextualizado do projecto de automatizao de um processo de negcio no mbito do negcio e da estratgia da empresa. Permitiu criar uma viso macro sobre os objectivos que permite envolver todos os colaboradores. Nesta fase, a rede de benefcios permitiu ter uma viso global do projecto e dos seus objectivos, mostrando uma clara ligao entre o negcio e as IT. O business case respeitando uma abordagem de gesto de benefcios permitiu olhar o projecto sobe vrias vertentes, e no apenas sobre uma prespectiva financeira. A anlise da arquitectura existente, possibilitou-nos enquadrar os benefcios ao nvel tecnolgico, tendo uma viso das limitaes com que temos que lidar de acordo com os benefcios que se pretendem. Ou seja, possibilitou-nos fazer a transposio dos objectivos de negcio, para uma viso mais tecnolgica. A incluso desta fase no modelo permitui integrar uma metodologia BPM numa metodologia de gesto de benefcios, explorando os pontos comuns a sua complementariedade. Esta fase permitiu-nos ter uma prespectiva integrada do processo, considerando impactos de atrasos e custos de oportunidade. Com a fase de pilotagem foi possvel realizar uma primeira avaliao do processo automatizado, fazendo uma ligao entre o que se pretende, e o que encontramos efectivamente na realidade do dia-a-dia. A fase de avaliao de resultados permitiu ter uma comparao simples e percetvel dos resultados alcanados.
Tabela XIII - Concluses do Modelo

Fase 2 Benefcios a atingir, Riscos Inerentes e Business Case

Fase 3 Anlise da Arquitectura Existente Fase 4 Especificao do Processo de Negcio Fase 5 Desenvolvimento e Testes Fase 6 Pilotagem Fase 7 Avaliao Resultados

Relativamente ao caso de estudo concluiu-se: A automatizao permite uma reduo do tempo despendido em cada pedido, o que se traduz: o o o o o No aumento da capacidade de resposta ao cliente; e, Na reduo de custos imputados ao processo;

A automatizao permite uma melhoria da qualidade da informao que se traduz: Na reduo da necessidade de modificaes aos dados existentes na base de dados; Na diminuio da percentagem de dados errados na base de dados; e, Na consolidao da informao.

Com base nos resultados alcanados, pode-se concluir que o modelo correspondeu s expectativas permitindo uma ligao entre o negcio e as IT, bem como ter uma prespectiva e avaliao mais realista da automatizao de um processo em vrias vertentes.

5. Concluses

A Gesto de Benefcios permite dar um contributo relativamente definio dos investimentos a efectuar e das estratgias propulsoras que os desencadeiam, bem como dos benefcios a alcanar e do seu valor para o negcio. Permite ainda evidenciar os benefcios que podem ser alcanados, demostrando como foram alcanados, quem beneficia com eles e quais as mudanas e factores de mudana necessrios no negcio. Apesar da metodologia de gesto de benefcios ser aplicada aos investimentos em IT, e decorrer paralelamente a outras metodologias como a Gesto de Projecto, estas so usadas de forma separada, pois o seu foco diferente, e o tempo de durao da metodologia de gesto de benefcios maior. No entanto, existem outras metodologias que enquadradas na gesto de benefcios se podem potenciar. Seguindo a abordagem do modelo de John Ward, procurou-se adaptar e melhorar esta abordagem, recorrendo complementaridade entre a gesto de benefcios e uma metodologia BPM, tendo em conta o mbito especfico em que se desenvolveu este modelo. Se a gesto de benefcios permite acompanhar o projecto desde o incio, fazendo a ligao ao negcio, bem como definindo os benefcios a atingir e as suas dependncias, a metodologia BPM permite por sua vez uma maior objectividade em relao aos indicadores dos processos de negcio, bem como ao seu desenho com base nos benefcios pretendidos. O BPM permite a definio de mtricas e a sua avaliao, o que se torna fundamental para uma rigorosa anlise dos benefcios. Assim, a gesto de benefcios permite uma viso mais abrangente do projecto, enquadrando-o na estratgia e no negcio da Organizao, a qual complementada com uma viso mais especfica do contexto, assente nos processos de negcio e na sua importncia para atingir os benefcios propostos. O modelo proposto tem como objectivo poder ser generalizado a todos os processos de negcio existentes na prestao de servios partilhados. No entanto, pela quantidade de processos que podem ocorrer, podero existir alguns em que o modelo proposto tenha necessidade de aperfeioamento, contemplando algumas especificidades, nomeadamente os processos em que a entidade prestadora dos servios partilhados, no tem interveno directa no processo. Futuramente, ser interessante realizar um aperfeioamento do modelo tendo em considerao as possveis limitaes descritas. Alm disso, os benefcios decorrentes da prpria normalizao de processos, necessitam de um estudo que permita um

acompanhamento do negcio de forma mais alargada, para assim medir os resultados alcanados com a normalizao do processo relativamente a alavancagens de outros processos, consolidao de informao, e novas oportunidades de negcio.

6. Bibliografia

[Bergeron, 2003]

BERGERON, Bryan (2003); ESSENCIALS of Shared Services; New Jersey; John Wiley & Sons, Inc. Business Process Transformation Group, Transforming Business Process Making (2009); BPM Practitioner Programme; England; BPT Group;

[BPTGroup, 2009]

[Becker, 2003]

BECKER, Jorg; KUGELER, Martin; ROSEMANN, Michael (2003); Process Management, A Guide for the Design of Business Processes; New York; Springer.

[Scheer, all., 2004]

et SCHEER, August-Wilhelm; ABOLHASSAN, Ferri; JOST, Wolfram; KIRCHMER, Mathias (2004); Business Process Automation, ARIS in Practice; Springer; New York.

[Papazoglou, PAPAZOGLOU, Michael P. (2008); Web Services: Principles and Technology; 2008] England; Pearson Education.

[Bradley, 2006]

BRADLEY, Gerald (2006); Benefit Realization Management, A Pratical Guide to Achieving Benefits Through Change; England; Gower Publishing Company.

[Ward, all., 2007]

et WARD, John; DANIEL, Elizabeth (2007); Benefits Management; Delivering Value from IS & IT Investments; England; John Wiley & Sons, Ltd.

[Lambert, et LAMBERT, R. e EDWARDS C (2003); A survey of IS/IT project appraisal; all., 2003] England; IS Group Cranfield School of Management.

[OCDE, 2009]

Organisation de Coopration et de Dveloppement conomiques (2009); Working Party of Senior Budget Officials, OECD EFFICIENCY STUDY; OECD Conference Center Paris; GOV/PGC/SBO(2009)4; JT03265009; 28-36. DHOOKE, Vickesh (2008); To Know the Future Know the Past The Evolution of BPM; BPM Institute; 1-15.

[Dhooke, 2008]

[Wurtzel, 2007]

WURTZEL, Marvin (2007) Can Six Sigma and Business Process Management Co-Exist?; BPM Institute.

[Wurtzel, 2008] [Morris, 2009] [Hedge, 2005]

WURTZEL, Marvin (2008); Integrating Lean and Six Sigma; BPM Institute. MORRIS, Dan (2009); BPM, Lean, and Six Sigma Better Together; BPM Institute. HEDGE III, A.J (2005); Business Process Management: Management Tools; AIIM E Doc Magazine, Silver Spring, v.19, n.4, Julho/Agosto; 52-53;

[Katz, 2005]

KATZ, Richard N. (2005); Examining the Future of Business Process Performance; ECAR Research Study 4;

[Sweeney, 2010] [Greer, all., 2007]

SWEENEY, Rick (2010); The Service Oriented Architecture Enterprise Architecture Framewok (SOA~EAF); SOA Institute. et GREER, Melvin; MARTIN, Lockheed (2007); Shared Services Drive Government Service Oriented Architecture; BrainStorms SOA Conference. ROSS, J. W. e BEATH, C. M (2002); Beyond the business case: New approaches to IT investment, MIT Sloan Management Review.

[Ross, 2002]

[OGC, 2009]

OGC (2009); Commerce.

Successful

Delivery

Pocketbook;

Office

of

Government

OGC (2009); Management Benefits: An Overview; Office of Government Commerce.

OGC (2009); Managing Business Benefits: Key Principles; Office of Government Commerce.