Você está na página 1de 16

BUSINESS PROCESS MODELING IN A SOFTWARE FACTORY Prof. Dr.

Marcos Ricardo Rosa Georges Centro de Economia e Administrao Pontifcia Universidade Catlica de Campinas PUC-Campinas /SP-Brasil marcos.georges@puc-campinas.edu.br

Abstract: This article presents the case of a company that develop, implement and maintain ERP systems in small and medium businesses customers, and was used the business processes modeling of their end activities and the quality management system based on the ISO9000 to fit to the software factory management model. The presentation of the concept of the software factory, as well as the models of business processes and the analysis of how this firm can fit the requirements of the software factory management model are shown in detail in this article. Key-words: business process modeling, management model; software factory; quality management system; ISO9000.

MODELAGEM DOS PROCESSOS DE NEGCIO EM UMA FBRICA DE SOFTWARE Resumo: Este artigo apresenta o caso de uma empresa que desenvolve, implementa e mantm sistemas ERP em clientes de pequeno e mdio porte que se utilizou da modelagem de processos de negcios de suas atividades fim e do sistema de gesto da qualidade baseado na norma ISO9000 para se enquadrar no modelo de gesto de fbrica de software. A apresentao do conceito de fbrica de software, bem como os modelos de processos de negcio desta empresa e a anlise de como esta empresa conseguiu se adequar aos requisitos do modelo de gesto de uma fbrica de software so mostrados em detalhes neste artigo. Palavras-chave: modelagem dos processos de negcio; modelo de gesto; fbrica de software; sistema de gesto da qualidade; ISO9000.

1. INTRODUO Desde o incio dos anos 90 o conceito de Processos de Negcio tem ganhado projeo e crescente importncia no mundo acadmico e nas empresas. Seu estudo e aplicao esto, cada vez mais, profundos e diversificados, o que pode ser verificado pela grande quantidade de reas do conhecimento que utilizam este conceito e que contribuem para seu desenvolvimento (Georges, 2007). Dentre as diferentes reas do conhecimento que utilizam o conceito de Processo de Negcio destacam-se a administrao e a cincia da computao. A administrao, por exemplo, recorre aos processos de negcio para analisar e redesenhar processos (reengenharia) e escrever manuais e procedimentos de trabalho (OSM e gesto da qualidade), e a cincia da computao o utiliza para especificar requisitos de software e de workflow. Neste trabalho, o conceito de processos de negcios foi aplicado como ferramenta de anlise e elaborao de procedimentos de trabalho em uma fbrica de software, uma empresa que desenvolve, implementa e mantm sistemas ERP em clientes de pequeno e mdio porte. Os modelos de processos de negcio forneceram descries precisas para a elaborao de procedimentos de trabalhos usados na obteno da certificao ISO9000 e deram subsdios para a medio, anlise e melhoria dos processos, possibilitando o incremento significativo na qualidade da prestao do servio de implementao e manuteno de sistemas ERP e na melhoria da eficincia no processo de desenvolvimento na referida fbrica de software. Mais alm, o uso da modelagem dos processos de negcio permitiu que esta empresa atendesse os requisitos exigidos para se enquadrar no conceito de fbrica de software permitindo, desde a solicitao do cliente at a entrega do produto, o controle de todas as atividades da fbrica de software. Os modelos de processos de negcios desta empresa e a anlise dos requisitos para se enquadrar no conceito de fbrica de software foram os objetos de pesquisa e apresentados em detalhes neste trabalho. 2. METODOLOGIA DA PESQUISA A pesquisa que originou os resultados apresentados neste trabalho de natureza aplicada, pois tinha como objetivo gerar conhecimentos para aplicao prtica dirigidos soluo de problemas especficos e de interesses local. O problema especfico que foi abordado era a dificuldade de se gerenciar os processos internos na empresa de software e desenvolver os atributos para atender os requisitos exigidos para se enquadrar no moderno conceito de fbrica de software. Quanto ao procedimento, esta pesquisa se define como estudo de caso, pois, conforme apresenta Silva e Menezes (2001) o estudo de caso envolve o estudo profundo e exaustivo de um ou poucos objetos de maneira que se permita o seu amplo e detalhado conhecimento. Neste caso, os poucos objetos que foram envolvidos na pesquisa so os processos internos de uma empresa de software. O procedimento metodolgico utilizado neste caso foi, inicialmente, uma comparao do estado atual da empresa em questo com o conceito da fbrica de software, evidenciando os requisitos no atendidos para se enquadrar neste modelo de gesto. Posteriormente foi feita a modelagem dos processos de negcio visando elaborar

procedimentos de trabalho para atender a norma NBR ISO9001:2000 e tais modelos de processos foram posteriormente analisados a luz dos requisitos do modelo de fbrica de software a fim de demonstrar que foram capazes de prover elementos suficientes para atender as exigncias deste modelo de gesto. 3. A FBRICA DE SOFTWARE O termo fbrica de software refere s organizaes especializadas em produzir programas de computador ou componentes de acordo com especificaes externamente definidas pelo usurio final atravs de uma linha de produo. Uma fbrica de software aplica tcnicas da manufatura com princpios de desenvolvimento de software para imitar os benefcios da manufatura tradicional (D.M. Upton & Fuller, V.A., 2005). Fernandes e Teixeira (2004) apresentam a fbrica de software como Um processo estruturado, controlado e melhorado de forma contnua, considerando abordagens de engenharia industrial, orientado para o atendimento a mltiplas demandas de natureza e escopo distintas, visando gerao de produtos de software, conforme os requerimentos documentados dos usurios e/ou clientes, da forma mais produtiva e econmica possvel. Segundo Cesar (2003), o desenvolvimento de sistemas pode ser dividido em cinco fases: anlise do negcio, fbrica lgica (anlise de sistemas), fbrica fsica (que programao propriamente dita), testes e certificao/homologao. Tradicionalmente, considera-se a terceira etapa como sendo a fbrica de software. O termo, alis, surgiu exatamente em analogia com as linhas de produo fabris que montam produtos em srie, todos iguais e com a mesma qualidade. A fbrica faz algo parecido com software. De acordo com Rocha et al. (2004) o conceito de fbrica de software baseia-se em alguns requisitos bsicos que Fernandes e Teixeira (2004) advogam como imprescindveis em qualquer Fbrica de Software. Estes requisitos so: a) Processos definidos e padronizados (desenvolvimento, controle e planejamento); b) Interao controlada com o cliente (entradas e sadas da fbrica); c) Solicitaes de servio fbrica devem ser padronizadas; d) Estimativas de custos e prazos baseadas no conhecimento real da capacidade produtiva com mtodos de obteno baseados em dados histricos; e) Controle rigoroso dos recursos envolvidos em cada demanda da fbrica; f) Controle e armazenamento em bibliotecas de itens de software (documentos, cdigo, mtodos, etc); g) Controle dos status e execuo de todas as demandas; h) Produtos gerados de acordo com os padres estabelecidos pela organizao; i) Equipe treinada e capacitada nos processos organizacionais e produtivos; j) Controle da qualidade do produto; k) Processos de atendimento ao cliente, e l) Mtricas definidas e controle dos acordos de nvel de servio definidos com o cliente. A anlise dos requisitos de uma fbrica de software postada acima leva a concluso que a Fbrica de Software um conceito organizacional e no tecnolgico, pois, estes atributos so os mesmos que esto presentes em quaisquer industrias manufatureiras, desde que seja feita a adequao do produto fsico manufaturado para o produto software.

Ou seja, a fbrica de software um modelo de negcio, que se prope a competir num determinado mercado, oferecendo produtos e servios especficos e que deve ser administrado em todas as dimenses tpicas de uma industria manufatureira. Assim, possvel e desejvel que as fbricas de software tenham sistemas de gesto bem desenvolvidos a fim de controlar e planejar suas atividades, promovendo a melhoria da eficincia operacional e garantindo o estado de competitividade do negcio. Neste contexto, a modelagem dos processos de negcios so instrumentos extremamente teis para desenvolver sistemas de gesto nas fbricas de softwares tal como a ISO9000 contribuindo na conquista de quase todos os requisitos listados acima como imprescindveis a uma fbrica de software. 3.1. CARACTERIZANDO O SUJEITO DA PESQUISA A empresa onde foram modelados os processos de negcio a apresentados neste artigo rene elementos para caracteriz-la como uma fbrica de software. Sua organizao interna se assemelha a uma industria manufatureira, onde, a partir dos diversos pedidos dos clientes so realizadas ordens de produo para desenvolver programas de computador e, sua linha de produo, contm as cinco fases descritas por Cesar (2003). No entanto, esta empresa no atendia a todos os requisitos apresentados por Rocha (2004) e Fernandes e Teixeira (2004). Porm, aps a modelagem dos processos de negcios e obteno da certificao ISO9000, esta empresa passou a atender todos os requisitos para o modelo de fbrica de software, ainda que, o processo de desenvolvimento e implantao do sistema de gesto da qualidade no foi, em nenhum momento, orientado a contemplar tais requisitos. Tal situao constata que o conceito de fbrica de software de natureza organizacional, pois o atendimento aos requisitos na norma ISO9000 uma norma de gesto foi capaz de contemplar os requisitos necessrios a caracterizao de uma fbrica de software. Prosseguindo a caracterizao do sujeito da pesquisa, esta fbrica de software uma empresa de pequeno porte situada na cidade de Campinas-SP, que desenvolve, implementa e mantm sistemas informatizados em clientes de pequeno e mdio porte. A empresa possui diversos sistemas informatizados para diferentes fins especficos, porm, o seu sistema de gesto integrado ERP que representa quase a totalidade de sua demanda e faturamento. Este sistema ERP atualmente est em operao em 52 empresas, na maioria industrias de mdio porte, com faturamento entre dez e cinqenta milhes de reais ao ano. A empresa se caracteriza por fornecer grande capacidade de adaptao do sistema ERP s necessidades especficas de cada cliente, gerando grande volume de pedidos de personalizaes no sistema ERP para atender tais necessidades. Estes pedidos de personalizaes, somadas as ordens de produo para correes de falhas, so as responsveis pela caracterizao da estrutura interna desta empresa em uma fbrica de software, apresentando grande similaridade a uma industria manufatureira, mesmo sendo uma empresa de pequeno porte. A empresa est organizada em trs reas elementares: comercial, relacionamento e desenvolvimento. A rea comercial responsvel em prospectar novos clientes e vender o sistema. A rea de relacionamento responsvel em implementar o sistema no cliente e, aps a implantao, responsvel em prestar o servio de manuteno, em especial o suporte tcnico e treinamento. Tambm so de responsabilidade da rea do relacionamento o teste e homologao dos pedidos de personalizao e correo feitos pela rea do

desenvolvimento. A rea do desenvolvimento responsvel pela programao, seja para o desenvolvimento de sistemas inteiramente novos, para o desenvolvimento de novas aplicaes ou personalizaes nos sistemas j existentes. Tambm de responsabilidade da rea do desenvolvimento a realizao de correes nos sistemas devido a falhas na programao. Os clientes que desejam algum tipo de suporte tcnico, correo ou personalizao em seu sistema, o faz atravs da abertura de um chamado de manuteno num sistema disponvel na internet (chamado de Call Center). Embora a empresa tenha apenas 52 clientes para o sistema ERP, o volume de chamados de manuteno abertos chega a 2.500 chamados ao ano, onde cada chamado interpretado como um pedido e demandando trabalho para a fbrica de software, onde ser gerando uma ordem de servio que desencadear as atividades de especificao funcional, especificao tcnica, programao, teste e homologao. Uma anlise criteriosa na gesto dos processos desta empresa constatou que somente os requisitos f e g eram atendidos plenamente para caracteriz-la com uma fbrica de software, os demais requisitos eram apenas parcialmente atendidos. Isto ocorre porque, embora esta empresa possui um nico produto o sistema ERP com apenas 52 clientes, a gesto dos chamados de manuteno e das ordens de servio extremamente complexa e carecia de metodologia de gesto para a sua padronizao, medio, controle e melhoria. Esta necessidade culminou com a opo pela certificao ISO9000 como alternativa capaz de melhorar a gesto dos processos desta fbrica de software. Durante o processo de desenvolvimento e implantao do sistema de gesto da qualidade, o uso de ferramentas de modelagem de processos de negcio foi amplamente utilizado em quase todos os processos desta fbrica de software. So estes modelos de processos de negcio, especificamente os modelos dos processos de negcio de implantao, desenvolvimento e manuteno que sero apresentados neste artigo. Porm, na prxima seo, uma pequena reviso terica sobre o conceito de processo de negcio feita antes da sua apresentao. 4. PROCESSO DE NEGCIO: CONCEITO E MODELAGEM O conceito de processo de negcio est no centro da abordagem sistmica utilizada para descrever e interpretar as organizaes de modo integrado, observando-a como um todo coeso e no como uma juno de partes isoladas. Este modo de interpretar a organizao como um todo chamado de holstico e fundamental para tornar possvel a integrao em uma empresa via sistemas de informao. A integrao empresarial um conceito que surgiu na dcada de 70 atravs do conceito de Manufatura Integrada por Computador (CIM), mas quando surgiu, esta integrao se dava somente no processo produtivo e no abrangia outras reas da organizao. Somente com o advento da orientao processual que os sistemas de informao passaram a integrar as diversas tarefas de uma organizao, revelando que a integrao no era uma questo puramente tecnolgica, mas sim organizacional. E no centro dos esforos para integrar os sistemas de informao numa perspectiva orientada por processos que reside o conceito de processo de negcio, instrumento indispensvel para reconhecer todos os agentes envolvidos nas atividades realizadas, bem como as informaes e recursos utilizados por eles.

Dessa forma, o conceito de processo de negcio passa a ser difundido como uma abordagem inovadora e necessria para a correta representao dos processos internos e externos de uma organizao de modo a projetar sistemas de informao capazes de integrar toda a empresa numa perspectiva holstica. Processo de Negcio um fenmeno que ocorre dentro das empresas, compreende um conjunto de atividades realizadas, associadas s informaes que manipula, aos recursos que so utilizados e a estrutura organizacional da empresa. Forma uma unidade coesa e deve ser focalizado em um tipo de negcio, que normalmente est direcionado a um determinado mercado/cliente, com fornecedores bem definidos. Scheer e Nttgens (2000) afirmam que o termo Processo de Negcio universalmente definido como um procedimento relevante que agrega valor a organizao. Mais que isso, o conceito de processo de negcio passou a ser usado para designar a menor unidade de uma empresa que ainda preserva um objetivo nos quais os processos e recursos que o compe so organizados para este fim. Ou seja, uma empresa passou a ser reconhecida como a coleo de processos de negcios. A partir desta concepo de que uma empresa constituda, na sua essncia, por uma coleo de processos de negcios, emerge a necessidade de criar linguagens para modelar os processos de negcios e ferramentas para gerenciar a criao destes modelos, surge ento o conceito de Business Process Management. O Gerenciamento do Processo de Negcio (do ingls: Business Process Management - BPM) inclui mtodos, tcnicas e ferramentas que suportam o projeto, a gesto e a anlise da operao do processo de negcio (Wil van der Aalst et al, 2003). Junto com o conceito de BPM surgem os frameworks de modelagem. Tais frameworks de modelagem renem um conjunto de smbolos que representam as diferentes entidades presentes num processo de negcio, bem como regras para garantir a consistncia dos modelos criados e recursos que gerenciam o ciclo de vida na criao dos modelos, desde a sua concepo at a implementao. Estes frameworks foram batizados de Arquiteturas de Referncia, tal como afirma Oliveira (2000) O conjunto destes diversos modelos de representao a ser usados para modelar os dados, as atividades, a estrutura organizacional e os processos de negcios e suas relaes, bem como a metodologia de modelagem e diversos aspectos de implementao e refinamento dos processos modelados so definidos e reunidos nas chamadas Arquiteturas de Referncia. Diversas arquiteturas de referncia foram desenvolvidas nas duas ltimas dcadas, porm, a arquitetura de referncia de maior projeo acadmica foi a CIMOSA e a de maior sucesso empresarial a ARIS. A arquitetura ARIS (Architecture Reference for Information Systems) fornece elementos para representar dados, pessoas e cargos, funes e processos numa perspectiva integrada e os modelos de processos gerados por esta arquitetura so chamados de EPC (Event-driven Process Chain) (Scheer e Nttgens, 2000). Os modelos de processos de negcio apresentados a seguir so adaptaes dos princpios da arquitetura de referncia ARIS, pois seus processos so constitudos de tarefas que pertencem a uma funo, tais tarefas so executadas por pessoas que so representadas pelos cargos e, quando for o caso, cada tarefa gera ou consome uma informao que est relacionada a um registro do sistema de gesto da qualidade.

No h uma preocupao com a verificao da consistncia dos processos no nvel da execuo de uma mquina, pois os processos de negcio foram elaborados para fins de padronizao do processo da fbrica de software e foram utilizados para elaborar os procedimentos de trabalho do sistema de gesto da qualidade e no para especificao de requisitos na elaborao de sistemas de informao. 5. MODELAGEM DOS PROCESSOS DE NEGCIO DA FBRICA DE SOFTWARE Vrios processos de negcio da fbrica de software foram modelados, mas somente alguns sero apresentados aqui, justamente os diretamente relacionados com a atividadefim, so eles: implantao, manuteno e desenvolvimento de sistemas. A interao entre estes processos apresentada, de modo simplificado, na figura 1 a seguir. O processo de negcio comercial (P001) responsvel pela prospeco e desenvolvimento de novos clientes para o sistema ERP. Uma vez comercializado o sistema a um novo cliente, inicia-se o processo de negcio de implantao (P002). Aps a implantao, ou mesmo durante, surgem demandas de personalizaes, correes, suporte tcnico e novas funcionalidades para o sistema ERP. Estas demandas so encaminhadas pelos clientes/usurios atravs de chamados de manuteno. A gesto destes chamados de manuteno compreendida pelo processo de negcio da manuteno (P003). Os chamados de manuteno que requerem atividade de programao, como personalizaes, novas funcionalidades e algumas correes, so encaminhados para a rea do desenvolvimento. A gesto de todo este processo que envolve programao compreendida pelo processo de negcio do desenvolvimento (P006).

Figura 1 - interao entre os processos de negcio da fbrica de software (fonte: o autor)

A figura 2 a seguir apresenta o mapeamento de parte do processo de negcio da implantao, denominado Fase I Planejamento do Projeto. Esta primeira fase do processo de implantao se inicia com uma reunio de preparao onde participam o gerente de relacionamento (GR), o analista suporte (AS), o diretor executivo (DE) e o cliente. Esta reunio de preparao precede a reunio de abertura onde preparado o Termo de Abertura (R 01 02 registro n.01 do processo n.02). Esta atividade de preparao do Termo de Abertura suficientemente complexa a ponto de existir uma Instruo de Trabalho que apoio a elaborao do Termo de Abertura (IT 01 02).

Figura 2 - Modelo do Processo de Negcio de Implantao Fase I (fonte: o autor)

Aps a reunio de abertura feito um levantamento dos processos onde ser implantados o sistema ERP. Esta atividade executada pelo gerente de relacionamento (GR) ou pelo analista suporte (AS) e feita com base num questionrio chamado QIS (R 01 01) que foi preenchido pela rea comercial durante a negociao a fim de se determinar melhor o tempo estimado do projeto de implantao. Aps o levantamento dos processos realizada a atividade de proposta de solues, de verificao de possveis personalizaes e elaborao de um programa de converso de dados existentes e treinamento dos usurios. Todas as informaes geradas nestas atividades so utilizadas para elaborar o PDI Plano Diretor de Implantao que conter uma gama de informaes (com base no PMI) a fim de gerenciar o projeto de implantao do sistema ERP. Observe que o PDI um registro do sistema de gesto da qualidade (R 02 02) e tambm possui uma instruo de trabalho (IT 02 02) para ajudar na sua elaborao. Quando pronto, o PDI submetido aprovao do cliente, definindo o trmino da fase I e incio da fase II, como ilustra a figura 3 a seguir.

Inicio da Fase II (execuo do PDI)

R 03 02 Certificado de Instalao Instalao do GENESIS

GR ou AS ou GD ou AP

R 05 02 Homologao do Processo HOMOLOGAO DO PROCESSO

GR ou AS Cliente

IMPLANTAO DO SISTEMA: - Parametrizao; - Personalizaes; - Criao base de teste; - Simulao

GR ou AS

PARTIDA DO SISTEMA: - Carga de Dados; - Partida do Sistema; - Ajustes Finais.

GR ou AS

NO

Todos os processos foram implantados ? SIM

R 04 02 Certificado de Treinamento

Treinamento dos usurios e aplicao do teste de aptido

GR ou AS Cliente R 06 02 Termo de Encerramento

GR ou AS Reunio de Encerramento do projeto Cliente

FIM da Fase II Inicio da Operao

Figura 3 - Modelo de Processo de Negcio da Implantao - Fase II (fonte: os autores).

A fase II inicia-se com a instalao do sistema ERP e emisso do certificado de instalao (R 03 02). A atividade de implantao do sistema ento iniciada, contendo as tarefas de parametrizao, personalizao, criao da base de testes e simulaes das operaes. Treinamentos e emisso de certificados aos participantes a atividade que sucede a implantao e a homologao do processo antecede a partida do sistema. A partida do sistema a atividade que determina o fim da implantao e, quando todos os processos foram implantados e sua partida realizada, feita a reunio de encerramento do projeto de implantao. De posse do sistema implantado o cliente passa demandar o servio de manuteno que prestado pela fbrica de software. O servio de manuteno feito atravs da abertura do chamado de manuteno feito via internet atravs de um sistema prprio de Call Center. No entanto, nem sempre as demandas so feitas via chamados. Em muitas situaes cotidianas comum que o cliente recorra ao telefone, e-mail e sistemas de mensagens instantneas. Nestes casos, que geralmente so simples, o suporte tcnico prestado ao cliente e o analista suporte faz o apontamento das horas de trabalho dedicadas a este atendimento num sistema chamado de CS. Quando o atendimento no pode ser feito rapidamente por telefone, email ou servios de mensagens instantneas, feito a abertura

de um chamado de manuteno, como ilustra a figura 4 a seguir.

Figura 4 - Modelo de Processo de Negcio de Manuteno - Classificao do Chamado (fonte: o autor)

Quando a um novo chamado de manuteno feito no sistema Call Center, iniciase o processo de negcio de manuteno, como ilustra a figura 4 anterior. A primeira atividade ao se receber um chamado de manuteno analisar o contedo do chamado, o que feito pela gerencia de relacionamento (GR) ou analista suporte (AS). Caso o chamado no contenha detalhes o suficiente para classific-lo nos diferentes tipos de servios a serem prestados solicitado ao cliente que detalhe melhor o chamado. Se o chamado contm informaes suficientes feita a classificao do chamado nos diferentes tipos de servios que o chamado ser encaminhado. A atividade de classificao do chamado relativamente complexa, pois, alm de envolver o conhecimento especfico sobre os possveis tipos de chamado, tambm requer classificaes de urgncia no tempo de atendimento e previso de tempo de atendimento, logo, esta atividade apoiada por uma instruo de trabalho bastante detalhada (IT 02 03). As possveis classificaes de um chamado so: Correo/exigncia legal: quando h falhas no sistema ou necessidade de mudanas por motivos de adequao a novas leis, requer atividade de programao; Personalizao: desenvolvimento de pequenas alteraes no sistema a pedido do cliente e requer atividade de programao; Suporte tcnico: auxlios a dvidas de natureza geral que so prestados ao usurio e no requer atividade de programao; Consultoria: auxlios de natureza geral que so prestados ao usurio, porm, a natureza da dvida j foi dada em treinamento prvio e, a princpio, o usurio

10

saberia faz-lo; no requer atividade de programao. Os chamados de manuteno classificados como suporte tcnico e consultoria no requerem atividade de programao e, portanto, no perfazem o caminho completo da fbrica de software. Por este motivo no sero apresentados aqui. Trata-se de atividades simples que so resolvidas atravs de explicaes dadas ao usurio e que geralmente esto relacionadas a comandos, relatrios e funcionalidades do sistema. Aps a prestao do servio suporte tcnico e consultoria feito o registro do tempo gasto na prestao do servio e encerra-se o chamado de manuteno. Os chamados de manuteno que so classificados como correes/exigncia legal e personalizao requerem atividade de desenvolvimento e, portanto, perfazem as fases citadas por Cesar (2003) de uma fbrica de software: anlise do negcio, fbrica lgica (anlise de sistemas), fbrica fsica (que programao propriamente dita), testes e certificao/homologao. Quando um chamado classificado em correo/exigncia legal, a primeira atividade deste novo processo que se inicia (figura 5) a anlise da possvel soluo para o problema, o que sempre feito envolvendo-se o gerente de relacionamento (GR), o gerente de desenvolvimento (GD), o analista programador (AP) e o diretor executivo (DE). Se a soluo necessitar da aprovao do cliente, esta submetida a sua aprovao e o processo prossegue mediante a sua aprovao. Aprovada soluo, aberta uma Ordem de Servio de Correo (R 03 03) e o chamado transferido para a rea do desenvolvimento que programar a soluo proposta. Trajeto similar acontece quando um chamado classificado em personalizao, porm, neste caso, h um cuidado maior em detalhar o que ser feito pois a personalizao uma demanda exclusiva, requerendo aprovao do cliente se est correto o entendimento do que para ser feito pelo desenvolvimento. Tambm h o agravante da personalizao ser um servio sempre pago a parte pelo cliente, enquanto as correes so sempre gratuitas (na verdade so cobertas pelo custo mensal de manuteno).

11

Chamado Call Center Correo ou Exigncia Legal

Retorno do Cliente

R 02 03 Chamado Call Center

Anlise da sua resoluo

GR, GD, AP ou DE

Necessita Aprovao do Cliente ?

NO

R 03 03 NO SIM Cliente Aprovou ? SIM OS R 02 03 Cliente quer negociar ? SIM DE ou GR Chamado Call Center Negocia com Cliente Abre Ordem de Servio (OS) IT 03 03 Abertura OS GR, DE ou AS

NO R 02 03 Chamado Call Center Especifica o que vai ser feito e submete a aprovao do cliente GR, GD, AP ou DE

R 02 03 NO Cliente Aprovou ? SIM Chamado Call Center

Transfere o chamado para Desenvolvimento

GR, DE ou AS

IT 01 03 Apontamento de Horas no CS R 01 03 Sistema CS

IT 01 03 Apontamento de Horas no CS R 02 03 Aponta Horas no CS Responsvel Chamado Call Center Escreve uma Nota sobre o aceite (se necessrio) DE ou GR R 01 03 Sistema CS Aponta Horas no CS

Responsvel

Encerra Chamado

Enviado para o Cliente Aprovar

Chamado Transferido para Desenvolvimento

Figura 5 - modelo de processo de atendimento a um chamado de correo (fonte: o autor)

O processo de negcio do atendimento de um chamado de personalizao est apresentado na figura 6 a seguir e tambm se inicia com uma atividade de anlise de sua resoluo envolvendo-se o gerente de relacionamento (GR), o gerente de desenvolvimento (GD), o analista programador (AP) e o diretor executivo (DE). Porm, neste caso, h a exigncia de se elaborar uma especificao funcional (R 04 03) que ser submetida ao cliente para aprovao. Somente aps a aprovao da especificao funcional o processo continua com a abertura de uma Ordem de Servio de Personalizao (R 03 03) e o chamado transferido para a rea do desenvolvimento. Quando uma Ordem de Servio aberta e o chamado transferido para a rea do desenvolvimento inicia-se o processo de negcio do desenvolvimento, atividade central da fbrica de software. A rea do desenvolvimento equivalente a Fbrica de Projetos Fsicos apresentada por Fernandes e Teixeira (2004) atravs da figura 7 a seguir. no processo de negcio da rea do desenvolvimento que feita o projeto detalhado (especificao tcnica), a construo da soluo (programao) o teste e a aceitao (homologao).

12

Figura 6 - O processo de negcio do atendimento de um chamado de personalizao

Figura 7 - Escopo da Fbrica de Software (fonte: Fernandes e Teixeira, 2004).

A primeira atividade do processo de negcio do desenvolvimento a elaborao da especificao tcnica (R 05 03), atividade feita pelo gerente de desenvolvimento e dos analistas programadores. De posse da especificao tcnica, o gerente de desenvolvimento preenche a Ordem de Servio detalhando cada atividade a ser feita, especificando quem a far, o tempo necessrio para a sua elaborao e o prazo de entrega, ou seja, feita a programao da produo das ordens de servio, tal como ilustra a figura 8 a seguir. Realiza-se ento as programaes de acordo com a especificao tcnica e, depois de concluda a programao, o resultado submetido a testes realizados pelos analistas suportes. Se a empresa validou o teste, este documentado, publicado e liberado para o

13

cliente que, ento, far a homologao final do produto entregue. Se o cliente validou o produto entregue o chamado e a ordem de servio encerrada.
Chamado Call Center Desenvolvimento

R 04 03 Especificao Funcional R 02 03 Chamado Call Center R 05 03 Especificao Tcnica GD ou GR GD e AP Faz a Especificao Tcnica (ET) se necessrio.
IT 05 03 Preenchimento da Especificao Tcnica

R 03 03 OS Documentao R 07 03 Manual do Genesis DE, AP

R 03 03 OS

Preenche o Roteiro na Ordem de Servio (OS).

R 02 03 R 04 03 Especificao Funcional R 03 03 OS R 05 03 Especificao Tcnica Foi possvel concluir a programao ? R 04 03 Especificao Funcional R 03 03 OS R 05 03 Especificao Tcnica Teste SIM DE ou AS R 02 03 Chamado Call Center Escreve uma Nota sobre o Validao DE ou GR Programa as correes e personalizaes (desenvolvimento) R 04 03 Especificao Funcional R 03 03 OS R 05 03 Especificao Tcnica Corrige, se necessrio, a EF, a ET e a OS, ou refaz a programao
Responsvel

Chamado Call Center


IT 07 03 Instruo Publicao e liberao

Publicao e Liberao

GR e AS

GD ou AP

NO

Cliente Validou ?

NO SIM

IT 06 03 Instruo para Teste

IT 01 03 Apontamento de Horas no CS R 01 03 Aponta Horas no CS

Responsvel

Flexsys Validou o teste ?

NO

Sistema CS

SIM

Encerra Chamado

Figura 8 - modelo de processo de negcio do desenvolvimento (fonte: o autor)

6. CONSIDERAES FINAIS O modelo de negcio da empresa cujo caso foi apresentado neste artigo se assemelhava a uma fabrica de software quando vista de longe, porm, ao observar detalhadamente sua operao verificava-se um distanciamento grande do conceito de fbrica de software, em especial aos requisitos especificados por Fernandes e Teixeira (2004) apresentados no incio deste artigo. Embora nem todos os requisitos estavam sendo descumprida, a maioria o era. Da

14

lista apresentada por Fernandes e Teixeira (2004), apenas os seguintes itens f e g eram atendidos, os demais itens eram parcialmente atendidos, pois o processo produtivo era padronizado mas no definido e formalizado. Os requisitos so: a) Processos definidos e padronizados (desenvolvimento, controle e planejamento); b) Interao controlada com o cliente (entradas e sadas da fbrica); c) Solicitaes de servio fbrica devem ser padronizadas; d) Estimativas de custos e prazos baseadas no conhecimento real da capacidade produtiva com mtodos de obteno baseados em dados histricos; e) Controle rigoroso dos recursos envolvidos em cada demanda da fbrica; f) Controle e armazenamento em bibliotecas de itens de software (documentos, cdigo, mtodos, etc); g) Controle dos status e execuo de todas as demandas; h) Produtos gerados de acordo com os padres estabelecidos pela organizao; i) Equipe treinada e capacitada nos processos organizacionais e produtivos; j) Controle da qualidade do produto; k) Processos de atendimento ao cliente, e l) Mtricas definidas e controle dos acordos de nvel de servio definidos com o cliente. Aps a modelagem dos processos de negcios e obteno da certificao ISO9000 proporcionou a esta empresa o atendimento aos demais requisitos especificados para se enquadrar no conceito de fbrica de software. Mais que isso, proporcionou um sistema de gesto capaz de medir o desempenho do processo de produo de software e realizao da prestao do servio, bem como sua anlise e conseqente melhoria. O atendimento do requisito a e k foram prontamente atendidos quando os modelos de processos de negcio foram usados para elaborar procedimentos de trabalho do sistema de gesto da qualidade. O atendimento do requisito b tambm foi atendido medida que o processo de recebimentos de chamados de manuteno (entradas) e as entregas (sadas) passaram a ser controladas pelo modelo definido pelos processos de negcio. O requisito c foi atendido quando se estabeleceu a exigncia de elaborao da especificao funcional atravs de formulrio prprio (R 04 03) ou no prprio corpo do chamado de manuteno, porm, nenhum servio de programao executado pela fbrica de software sem que tais registros sejam preenchidos. A exigncia de se fazer o apontamento do tempo gasto em cada atividade descrita nos modelos de processos de negcio forneceu a fbrica de software um histrico de tempos e prazos capazes de fazer estimativas confiveis de quanto tempo levar e de qual ser o prazo de entrega de cada servio demandado fabrica de software, atendendo assim ao requisito d. O preenchimento das ordens de servio com o detalhando cada atividade da fbrica de software a um analista torna visvel o uso do principal recurso (o humano) da fbrica de software para atender suas demandas, atendendo o requisito e. As regras estabelecidas para a aprovao nos testes e liberaes das programaes, bem como os critrios bem definidos de competncias e conhecimentos para a admisso de pessoal fornecem elementos para atender os requisitos h e j do modelo de fbrica de software.

15

A exigncia do sistema de gesto da qualidade de se estabelecer um programa de treinamentos sobre os processos implantados e uma cultura da qualidade baseada na busca da excelncia operacional e na satisfao dos clientes suficiente para atender o requisito i da lista de requisitos do modelo de fbrica de software. Tambm como conseqncia da implantao do sistema de gesto da qualidade foi criada indicadores de desempenho que monitoram o tempo mdio de atendimento dos chamados de manuteno, monitorando e controlando o nvel de servio acordado com o cliente e atendo o requisito l. Enfim, o conceito de fbrica de software relativamente novo quando de interpreta o conceito de manufatura para um produto com caractersticas bem distintas de um produto convencional, porm, uma vez interpretada como fbrica, possvel aplicar as metodologias de gesto reconhecidamente til da manufatura tradicional nas fbricas de software. O sistema de gesto da qualidade baseado na ISO9000 e a modelagem dos processos de negcios so exemplos de metodologias de gesto amplamente utilizadas nas fbricas convencionais que se mostram extremamente teis em uma fbrica de software, e o caso apresentado neste artigo pode confirmar esta afirmao. 7. REFERNCIAS BIBLIOGRFICAS
Cesar, Ricardo Fbrica de Software: uma vocao nacional?. Computerworld, junho de 2003. Disponvel em < http://www.siscorp.com.br/imprensa/computerworld02.htm>, acessado em 16 de janeiro de 2010. Fernandes, A.A., Teixeira, D. S. - Fbrica de Software: implantao e gesto de operaes. Editora Atlas, So Paulo, 2004. Georges, M.R.R. Modelagem do Processo de Negcio de uma Aciaria: A viso do Fluxo Produtivo Orientada em Eventos Discretos. In: INTERNATIONAL CONFERENCE ON INFORMATION SYSTEMS AND TECNHOLOGY MANAGEMENT, 4., 2007, So Paulo. Anais... So Paulo:USP, 2007, 1CD. Oliveira, C. M. Prottipo de um Ambiente de Modelagem de Empresa Dissertao de Mestrado, Unicamp, 2000. Rocha, T.A.; Oliveira, S.R.B; Vasconcelos, A.M.L Adequao de Processos para Fbricas de Softwares. VI SIMPSIO INTERNACIONAL DE MELHORIA DE SOFTWARE, 11, 2004, So Paulo. Disponvel em http://www.simpros.com.br/Apresentacoes_PDF/Artigos/Art_12_Simpros2004.pdf > acessado em 16 de janeiro de 2010. Scheer, A.-W.; Nttgens. M.: ARIS Architecture and Reference Models for Business Process Management, in: van der Aalst, W.M.P.; Desel, J.; Oberweis, A.: Business Process Management - Models, Techniques, and Empirical Studies, LNCS 1806, pp. 366-379, Springer-Verlag, Berlin, 2000. Silva, E. L.; Menezes, E. M. Metodologia da pesquisa e elaborao de dissertao. Florianpolis: Universidade Federal de Santa Catarina, Programa de Ps-graduao em Engenharia de Produo, Laboratrio de Ensino a Distncia, 2001. 125 p. Apostila. Disponvel em < http://projetos.inf.ufsc.br/arquivos/Metodologia%20da%20Pesquisa%203a%20edicao.pdf> acessado em 17 de janeiro de 2010. Upton, D.M. & Fuller, V.A. - Wipro Technologies: The Factory Model. In. Harward Business School Review Case Study, 2005. W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske.: Business Process Management: A Survey. In W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske, editors, Business Process Management Models, Techniques, and Empirical Studies, LNCS 2678, pp. 112. Springer-Verlag, Berlin, 2003.

16