Desenvolvimento de sistemas integrados de gestão empresarial para micro e pequenas empresas

Desenvolvimento de sistemas integrados de gestão empresarial para micro e pequenas empresas utilizando metodologias de processos ágeis

Com o crescente aumento do fluxo das informações nas empresas se faz necessária a busca por tecnologias que auxiliem na tomada de decisões, nas atividades realizadas e na produtividade. Com essa finalidade uma das tecnologias que se destaca é a do Sistema Integrado de Gestão Empresarial. No entanto para tais sistemas há um alto custo tanto de implementação quanto de implantação, o que resulta na sua utilização somente em grandes organizações. Sob essa perspectiva apresenta-se neste trabalho a proposta de uma metodologia para implementação de sistemas integrados para micro e pequenas empresas, baseada na adaptação de três modelos de processos ágeis. São eles: scrum, programação extrema (XP) e desenvolvimento voltado à funcionalidade (FDD). O processo proposto é apresentado juntamente com um estudo de caso de um ERP desenvolvido para micro e pequenas empresas da indústria de vestuário.

1. INTRODUÇÃO

No cenário do mundo atual, observa-se, cada vez mais, que para sobreviver na arena dos negócios globais e dos profissionais altamente competitivos, elementos como tecnologia, organização e visão estratégia são recursos indispensáveis para as organizações. Para orquestrar o conjunto destes elementos de forma afinada e automática as empresas estão se valendo dos recursos da tecnologia que se baseiam nos sistemas integrados de gestão empresarial (doravante ERP).

Segundo Schmidt et al (2002, p. 214), “os sistemas de informação são o produto de quarenta anos de tentativas e erros”, porém, como a cada dia novos conceitos e modelos de gestão vêm sendo criados e experimentados por empresas de sucesso, torna-se imperativo a realização de novos estudos sobre as transformações que afetam os gestores das organizações e a maneira como os ERP estão sendo desenvolvidos de forma a adaptarem-se a essas. Do ponto de vista de Alves, Zambalde e Figueiredo (2004, p. 25) Enterprise Resource Planning (ERP) ou sistema integrado de gestão empresarial “é a tentativa de integrar todos os departamentos e funções de uma organização num único sistema informatizado, que consiga servi-los de forma eficaz”. Com outras palavras, os sistemas ERP são sistemas integrados com uma base de dados única não redundante, de forma que todo processo fique centralizado e possa ser acessado por toda empresa.

A adoção de um ERP afeta a empresa em todas suas dimensões, culturais, organizacionais ou tecnológicas. Esses sistemas controlam toda a empresa, da produção às finanças, registrando e processando cada fato novo na engrenagem corporativa e distribuindo a informação de maneira clara e segura, em tempo real. Ao adotar um ERP o objetivo básico não é colocar o software em produção, mas melhorar os processos de negócios usando tecnologia da informação. Mais do que uma mudança de tecnologia, a adoção desses sistemas implicam em um processo de mudança organizacional (MENDES; FILHO, 2002).

As vantagens providas pelos ERP são valiosas tanto para as empresas quanto para as pessoas envolvidas no processo, sejam elas, diretores, funcionários ou clientes. Algumas dessas vantagens são (MONK; WAGNER, 2006): suporte a tomada de decisão profícua (benéfica); valor agregado ao produto (bens e serviços); produtos de melhor qualidade; oportunidade de negócios e aumento da rentabilidade; mais segurança nas informações, menos erros, mais efetividade e produtividade; carga de trabalho reduzida; redução de custos e desperdícios.

Apesar dos benefícios do ERP para empresas de grande, médio ou pequeno porte, existe ainda grande resistência para sua implantação, sendo a justificativa mais utilizada o alto custo, principalmente nas micro e pequenas empresas. O alto custo é ocasionado pela complexidade da implementação e pela implantação dos diversos módulos de sistemas ERP, uma vez que eles se encontram de maneira imbricada.

À luz do contexto apresentado, o objetivo deste artigo é apresentar outra forma de implementação, implantação e customização de sistemas ERP voltados para micro e pequenas empresas, através do uso de processos de desenvolvimento ágeis, detalhados no decorrer do artigo. Espera-se assim, diminuir a complexidade retratada, consequentemente reduzindo custos. Esta pesquisa corresponde também a um estudo de caso, onde se investiga o desenvolvimento de um sistema ERP para micros e pequenas indústrias de vestuário da cidade de Formiga-MG.

Este trabalho está organizado da seguinte forma: a seção 2 apresenta uma caracterização dos sistemas ERP, a seção 3 apresenta uma fundamentação das metodologias ágeis, além de abranger de forma geral os processos XP, SCRUM e FDD, já na seção 4 é apresentado o processo AgileAdapt, utilizado para o desenvolvimento do ERP. Na seção 5 o estudo de caso é apresentado, mostrando-se que metodologia ágil é uma solução viável para esse tipo de sistema e, por último, uma conclusão.

2. REFERENCIAL TEÓRICO

Neste tópico, busca-se elucidar os principais conceitos fundamentais que objetivam este estudo, caracterização dos sistemas ERP, Metodologias ágeis: uma abordagem geral, Programação Extrema, Scrum e Desenvolvimento Voltado a Funcionalidade (FDD – Feature Driven Development).

Caracterização dos sistemas ERP

Os Sistemas ERP são compostos basicamente pelos módulos apresentados na Figura 1. Possuem uma base de dados central que recebe e fornece dados para os diversos módulos, apoiando as atividades dos processos de negócio das organizações. Quando um novo dado é inserido na base através de um módulo, a mesma é organizada e disponibilizada imediatamente, garantindo-se desta forma a integração entre todo o sistema.

FIGURA 1 – Estrutura modular de Sistemas ERP. Fonte: Adaptado de DAVENPORT, 1998.

A integração de tais módulos, utilizando arquitetura cliente-servidor, ocasiona um grau de complexidade nesses sistemas devido aos lançamentos contábeis automáticos. Esses lançamentos são rotinas disparadas a partir das telas de entrada dos vários módulos e de qualquer outra rotina cujos cálculos afetem alguma rotina contábil. As contas a serem movimentadas, bem como o histórico e os valores, são parametrizados em uma tabela mestre (HABERKORN, 1999).

Visando uma integração mais amena, robusta e produtiva, sugere-se o uso de novas tecnologias como a arquitetura orientada a serviços (Service Oriented Architecture – SOA) e os Web Services.

A utilização de SOA servirá para união dos diferentes módulos, possibilitando a homogeneização, flexibilidade, divisão de tarefas e uma maior escalabilidade ao sistema.

Essa arquitetura SOA não pode ser comprada ou instalada, ela deve ser estudada juntamente com o sistema ao qual deverá adaptar-se. Para que se tenha sucesso na implantação de SOA e, consequentemente, se possa usufruir de seus benefícios, cada caso deve ser estudado de maneira isolada, assim, deve-se definir os serviços e dados que esses serviços irão trabalhar (CARTER, 2007). Já a tecnologia Web Services (CHAPPELL; JEWELL, 2002), caracteriza-se por ser um meio de comunicação que permite que diferentes aplicações troquem informações entre si. Essa comunicação torna-se possível devido à utilização do padrão de formatação de dados, o XML (Extensible Language Markup – Linguagem de Descrição Extensível).

Para a implantação de um ERP, de acordo com Haberkorn (1999), o primeiro passo para a implantação é o chamado levantamento das necessidades do cliente, que determina as necessidades e as prioridades das empresas, avaliando e selecionando todos os processos e regras de negócio que serão desenvolvidos pela metodologia. Caso necessário, é nesta etapa que são definidas customizações e/ou definições de projetos especiais. O próximo passo é o planejamento para determinar as prioridades, através de um plano de ação, onde possam ser revistos os pontos de conflito e detalhadas as atividades a serem compridas. Neste estágio, é fundamental que seja alcançada a unificação dos objetivos da empresa, em todas suas áreas de negócio (FILHO, 2001).

Com o levantamento das necessidades e o planejamento concluído, e em paralelo o processo de conscientização sendo efetivado com todos envolvidos, chega o momento de iniciar o Treinamento dos usuários em todas as regras de negócio pertinentes ao seu trabalho.

A fase do Treinamento acontece de três formas: envolvendo o Corpo Gerencial (tópicos do que o produto oferece e que tipo de informação extrair dele), Corpo Operacional (Funcionalidades dos produtos de software) e Especifico do Corpo Operacional (funcionalidades dos produtos de software em ambientes simulados de produção).

Ainda no tópico Treinamento, é importante considerar o processo de reciclagem que pode ocorrer por mudanças na estrutura organizacional, implementações nos produtos de software ou nos objetivos previamente estipulados.

O Desenvolvimento de customização e/ou soluções específicas acontece quando um grau de aderência alcançado pelos produtos de software contratados não é satisfatório, ou quando determinadas atividades da empresa são tão específicas que requerem desenvolvimentos especiais.

O acompanhamento acontece desde o primeiro instante da aplicação da metodologia, transmitindo segurança aos usuários, assistindo todas as operações e processos contidos na implantação, buscando sempre a melhoria contínua. A etapa final é a validação, que consiste na determinação do grau de excelência na implantação dos produtos de software. Em síntese, nesta etapa cumpre-se o comparativo entre o executado e o planejado (HABERKORN, 1999).

Neste trabalho através da utilização de processos ágeis, os módulos do ERP de vestuários estão sendo desenvolvidos e implantados independentemente de outros módulos estarem prontos, tornando o sistema flexível, adaptável e principalmente gerenciável (possibilitando customizações de acordo com as necessidades de determinada empresa). Para a contextualização das metodologias ágeis, a próxima seção discorre sobre tal assunto.

Metodologias ágeis: uma abordagem geral

A “indústria de software” sempre contou com métodos cujos processos de desenvolvimento eram baseados em conjuntos de atividades predefinidas, descritas como processos prescritos (AMBLER, 2004), nas quais, muitas vezes, o trabalho começava com o levantamento completo de um conjunto de requisitos, seguido de um projeto de alto-nível, de implementação, de validação e, por fim de manutenção. Entretanto, segundo Fowler (2001), estes métodos são considerados muito burocráticos para projetos grandes e que não sofram muitas mudanças em seus requisitos.

A partir de 90, começam a surgir novos métodos sugerindo uma abordagem de desenvolvimento ágil no qual os processos adotados sejam adaptados às mudanças, apoiando a equipe de desenvolvimento no trabalho (BECK, 2001).

Em fevereiro de 2001, um grupo inicial de 17 metodologistas, entre eles, Robert C. Martins, Jim Highsmith, Kent Beck, Mike Beedle, Alistair Cockburn, Martin Fowler, Steve Mellor, Ken Schwaber, Jeff Sutherland formou a Aliança para o Desenvolvimento Ágil de Software, também conhecida como Aliança Ágil, que formulou um manifesto, contendo um conjunto de princípios que definem critérios para os processos de desenvolvimento ágil de software (AMBLER, 2004); (FAGUNDES, 2005).

Basicamente os processos ágeis se diferem dos processos tradicionais em dois aspectos (FOWLER, 2001): são adaptáveis ao invés de prescritivos; são orientados a pessoas ao invés de processos. Os métodos ágeis propõem uma alternativa que busca a melhoria do processo de desenvolvimento, tornando-o mais ágil e menos burocrático. Por sua característica adaptável, mudanças são mais fáceis de serem realizadas não ultrapassando tanto o orçamento. No aspecto orientado a pessoas, esses processos têm o cliente como membro da equipe, ou seja, o sistema vai sendo desenvolvido, testado e implantado continuamente.

Atualmente existem vários processos ágeis, dentre os quais tem se destacado no mercado a programação extrema (XP) e o Scrum. A seguir tais metodologias são apresentadas.

Programação Extrema

O XP é um método eficiente, flexível e de baixo risco para equipes pequenas e médias que desenvolvem software com requisitos dinâmicos ou em constantes mudanças (BECK, 2000). Segundo Teles (2006), o Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para: – projetos cujos requisitos são vagos e mudam com frequência; – desenvolvimento de sistemas orientados a objeto; – projetos que trabalhem com equipes pequenas (preferencialmente até 12 desenvolvedores); – desenvolvimento iterativo/incremental.

O XP é um processo de desenvolvimento organizado em torno de um conjunto de valores (Feedback, Comunicação, Simplicidade e Coragem) e práticas (cliente presente, programação em pares, reunião em pé, refactoring, entre outras) que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software (TELES, 2006).

As fases do processo de desenvolvimento do XP – vide Figura 2, consistem em: exploração, planejamento, iterações para entrega, produção, manutenção e fim do projeto.

FIGURA 2 – Fases do Processo do XP. Fonte: BECK, 2000.

O objetivo da fase de Exploração é entender o real escopo do sistema. Este entendimento deve ser suficiente para que ele possa ser estimado (BECK, 2000). Todas as funcionalidades do sistema são levantadas através de histórias (User Stories) que são registradas em pequenos cartões. Estas histórias devem ser escritas sempre pelo próprio cliente, com suas próprias palavras (TELES, 2006).

A fase de planejamento é usada em XP para assegurar que a equipe esteja sempre trabalhando no mais importante, a cada momento do projeto. O objetivo é definir a menor data e o maior conjunto de user stories que serão realizadas na primeira entrega. Esta definição é feita com estimativas entre clientes e programadores (BECK, 2000).

Segundo Beck (2000), os compromissos são divididos para serem executados em iterações que duram de 1 a 4 semanas. Para cada user stories executada que faz parte da iteração é escrito um ou mais teste(s) de aceitação pelo cliente. E antes de implementar os programadores escrevem os testes de unidades.

Também conhecida como implementação, à fase de produção começa no final da primeira iteração e, segundo Ambler (2004): entrar em produção significa lançar o sistema no ambiente real de trabalho do cliente. Deve-se implementar novos testes para provar se o sistema está estável o suficiente para entrar em produção.

A fase de manutenção é o estado normal de um projeto em XP, e compreendem as fases de planejamento, iteração para entrega (a partir da segunda iteração) e produção até a entrega final do sistema. Como consequência, esta fase inclui atividades, como a operação de suporte ao sistema através de um help desk, por exemplo, (AMBLER, 2004).

Quando não mais existir novas histórias é o momento de finalizar o projeto. É o momento de escrever algumas páginas sobre a funcionalidade do sistema, o resultado será um documento para auxiliar os desenvolvedores na realização de alguma alteração futura no sistema, se for o caso.

Scrum 

O Scrum é um método ágil que possui como objetivo a entrega de um software de qualidade dentro de iterações, formadas por pequenos intervalos de tempo definidos, chamadas Sprints, possuem aproximadamente um mês de duração (BEEBLE, 1998).

Esta metodologia é um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer trabalho, não só de software, sendo uma abordagem para desenvolvimento de sistemas e produtos nos quais os requisitos sofrem constantes mudanças. O Scrum é escalável para pequenos projetos e grandes corporações.

O Scrum não requer ou fornece qualquer método específico para desenvolvimento de software, apenas estabelece conjuntos de regras e práticas gerenciais que devem ser adotadas para o sucesso de um projeto. São exemplos de práticas adotadas pelo Scrum: Produc Backlog, Sprint, Sprint Backlog, Reunião de planejamento da Sprint, Reunião diária do Scrum. As fases do processo Scrum, segundo Schwaber e Beeble (2002) são: PreGame, Desenvolvimento, PosGame, como apresenta a Figura 3.

A fase de PreGame possui duas subfases: Planejamento e Arquitetura. A subfase de Planejamento inclui a definição do sistema que está sendo desenvolvido. Os requisitos são descritos e priorizados em um documento chamado tarefas do produto (Product Backlog). O planejamento inclui também a estimativa de esforço para cada requisito, definição da equipe de desenvolvimento, as ferramentas a serem usadas, os possíveis riscos do projeto, as necessidades de treinamento e uma proposta de arquitetura de desenvolvimento baseada na lista de tarefas. Na subfase de Arquitetura, é feito um projeto do sistema baseado nos itens atuais do Product Backlog.

Nesta fase de desenvolvimento (game phase), o sistema é dividido em Sprints (semelhantes as iterações do XP), ou seja, o software é desenvolvido em ciclos, que levam de 1 a 4 semanas, no qual cada equipe recebe uma parte do product backlog para desenvolvimento e ao final de cada sprint sempre apresenta um produto executável ao final.

FIGURA 3 – Fases do Processo Scrum. Fonte: BEEBLE, 2002.

É na fase de Pós-planejamento (post-game phase) que acontece a entrega final do produto, iniciada quando todos os tópicos são satisfatórios (tempo, competitividade, requisitos, qualidade, custo). Atividades: testes de integração, testes de sistema, documentação do usuário, preparação de material de treinamento, preparação de material de marketing.

Desenvolvimento Voltado a Funcionalidade (FDD – Feature Driven Development)

O FDD é um método iterativo que enfatiza tópicos de qualidade e inclui entregas frequentes de artefatos para monitorar o progresso do projeto. O desenvolvimento é voltado a Feature, ou funcionalidade, que representa um requisito funcional do sistema. Segundo Palmer (2003), o FDD apresenta as seguintes práticas: Modelagem dos Objetos de Domínio (Diagramas de classe UML), Desenvolvimento através de características, Propriedade individual da classe, Equipes de Características, Inspeções, Relatórios de resultados, entre outras.

Para Highsmith (2002), o FDD possui o foco no projeto e construção e é composto por cinco fases, como apresentado na Figura 5: três delas (desenvolver um modelo, construir uma lista de características e planejar cada uma delas) são realizadas no início do desenvolvimento do sistema e as duas últimas (projeto e construção de cada característica) são completadas dentro de cada iteração.

Desenvolver um modelo geral é a primeira parte da etapa do processo no FDD, quando são definidos o contexto e os requisitos do software para a construção, assim como uma documentação em forma de casos de usos ou uma especificação das funcionalidades. A tarefa requerida nesta etapa é a modelagem do domínio da aplicação, quando são construídos os diagramas de classe UML, o(s) diagrama(s) de sequência UML e uma lista formal das características.

O objetivo da segunda fase, ainda de acordo com Highsmith (2002), é construir uma lista completa de todas as caraterísticas do produto a ser desenvolvido. Na lista, a equipe de desenvolvedores apresenta cada função esperada pelo cliente, baseada nas características gerada na etapa anterior. A lista é revisada pelos usuários e patrocinadores do sistema para sua aprovação.

FIGURA 4 – Fase do processo FDD. Fonte: FAGUNDES, 2005.

Na fase de planejamento e construção, é criado um plano de alto nível, no qual as funções são sequenciadas de acordo com a prioridade e a dependência de cada uma, e então, designadas ao líder de programadores.

Na fase para projetar cada característica, são executadas as seguintes tarefas:     Estudar a documentação existente; Desenvolver o diagrama de seqüência para o conjunto de característica; Refinar o modelo do objeto; Rescrever as classes e os métodos; Inspecionar o projeto. Construir cada característica é a última etapa de cada iteração do processo FDD. A seguir, algumas tarefas requeridas nessa etapa que são executadas: Implementação das classes e métodos; Inspeção de código; Teste de unidade; Integração; Teste de integração; Entrega do incremento.

3. METODOLOGIA

Este artigo busca em caráter qualitativo, através de um estudo conceitual e com base na teoria estudada, elucidar a importância da utilização e/ou adequação das metodologias ágeis que podem auxiliar a equipe no desenvolvimento de softwares para pequenas, medias e grandes empresas.

Diante disso, serão utilizados como instrumento de coleta de dados pesquisas do tipo estruturada e semi estruturada de modo investigativo na busca das informações (levantamento de requisitos) necessárias para desenvolvimento do sistema.

4. DESENVOLVIMENTO E DEMONSTRAÇÃO DOS RESULTADOS

Escolheu-se, por conveniência, três indústrias de vestuários do Centro-Oeste de Minas Gerais. As organizações contam hoje com cerca de 60 funcionários. As indústrias atendem toda região e alguns estados como São Paulo, Rio de Janeiro. Atualmente tem feito exportação mesmo que ainda em pequena escala para países da América latina. A escolha pelas indústrias se deu pelo fato de seus processos não estarem bem definidos e nem tão pouco automatizado e por estar passando por diversas dificuldades tais como: atrasos no período de fechamento do balanço, entregas, grande rotatividade de funcionários e o aumento do número de concorrentes tais como país como a China, a falta de monitoramento e documentação.

Inicialmente, foi feita uma reunião com o Gestor de TI e os Stakeholders para a demonstração do projeto e levantamento da missão, visão, objetivos, cadeia de valores e dos principais envolvidos no processo. Para levantamento dos requisitos forma feitas reuniões tanto com a parte de planejamento quanto a parte operacional.

AgileAdapt: Adaptação dos processos XP, SCRUM e FDD

Conforme apresentado, fica claro a semelhança entre as práticas e fases dos processos ágeis XP, Scrum e FDD, cada qual com suas particularidades. Após o cauteloso estudo dos processos citados, a adoção por completo de um desses processos não seria o bastante para o desenvolvimento de um sistema mais complexo, por exemplo, um ERP. Assim, definiu-se unir as práticas mais viáveis dos processos analisados, originando o AgileAdapt, um processo de desenvolvimento adaptado dos processos XP, Scrum e FDD.

O processo AgileAdapt, assim como o XP, Scrum e FDD, requer uma participação integral do cliente junto à equipe de desenvolvimento, também é um processo iterativo/incremental, voltado para equipes pequenas de desenvolvimento (3 a 10 pessoas), focado em entregas contínuas, sendo flexível e adaptável. Dividido em três grandes fases: planejamento, desenvolvimento das iterações e entrega final, conforme apresenta a Figura 5.

A fase de planejamento tem o objetivo de definir o escopo, estimativas, riscos e arquitetura do sistema, através de encontros com clientes (funcionários chaves das empresas) e análises da equipe de desenvolvimento. Essa etapa é dividida em duas subfases denominadas product backlog e estabelecimento de módulos.

O product backlog, inspirado no processo Scrum, possui o objetivo de coletar as funcionalidades e suas respectivas prioridades (de acordo com o cliente), realizar estimativas e cálculos de riscos, tudo em alto nível. Ainda nessa subfase, inspirado pelo FDD, e para dar maior visibilidade ao cliente e equipe de desenvolvimento, diagramas de casos de uso são construídos.

A etapa seguinte, estabelecimento dos módulos, as funcionalidades do product backlog são agrupadas em grandes módulos (vistos como subsistemas independentes), contendo várias funcionalidades com características semelhantes. Ressalta-se que a ideia dos módulos é importante para visualizar a arquitetura do sistema, entretanto funcionalidades podem ser agregadas a qualquer momento. Cada módulo, uma vez que contém várias funcionalidades, podem ser dividido em “minimódulos” que serão desenvolvidos dentro das iterações na segunda fase. Em outras palavras, os módulos são compostos por minimódulos, conjunto mínimo de funcionalidades, que são desenvolvidos em iterações, semelhantes às do XP e Sprints do Scrum, visando menor complexidade.

FIGURA 5 – Fases do AgileAdapt: uma adaptação dos processos XP, Scrum e FDD.

Fonte: Autor

As fases de desenvolvimento das iterações podem ser vista como um ciclo contínuo e evolutivo, que objetiva inicialmente a modelagem de cada módulo, seguido de iterações (2 a 4 semanas) para implementação, testes e integração dos minimódulos prioritários. Na etapa de modelagem do módulo, totalmente inspirada no processo FDD, os diagramas de classes, sequência e o modelo de entidade-relacionamento (DER) são projetados. O cliente participa de todo esse processo, detalhando e aprovando a diagramação. É interessante a modelagem de um módulo completo, para a visualização das interações entre os minimódulos e também estimar o número de iterações que o módulo conterá, mesmo se o módulo não seja completamente desenvolvido em tal momento.

Após o módulo projetado, inicia-se o “processo de produção”, dos minimódulos prioritários, passando pela implementação convencional, testes de unidade (equipe) e aceitação (cliente) e integração. Quando o conjunto essencial de minimódulos for concluído, o mesmo vai para a implantação parcial, ou seja, um subsistema executável é implantado no cliente para mais testes e início de trabalho. Dito de outra forma, o cliente recebe um módulo executável assim que o conjunto mínimo de funcionalidades do módulo corrente esteja completado, geralmente de dois em dois meses, dependendo do tamanho da equipe.

O conjunto mínimo de funcionalidades foi definido inspirado na prática de entrega contínua dos processos ágeis. Esse conjunto são as características marcadas como prioridade máxima pelo cliente dentro de cada módulo. Quando as mesmas são atingidas, o conjunto é implantado no cliente. Isso se torna interessante, quando se tem uma equipe pequena de desenvolvedores, então torna se mais eficaz ter vários módulos, mesmo que incompletos, em operação no cliente para testes num pequeno intervalo de tempo, a se ter um ou outro módulo totalmente completo.

Na implantação parcial, os clientes detectam erros, tanto de funcionalidades, como bugs e falta de usabilidade. Essas falhas são reportadas à equipe, que os corrige e entrega uma nova versão juntamente com a próxima entrega. Quando todos os módulos estiverem totalmente concluídos e não houver mais queixas por parte do cliente é realizada a entrega final.

Essa fase ocorre quando todos os módulos estiverem sido implantados no cliente e o mesmo não apresente mais “queixas”. Nessa fase os manuais do sistema são entregues para os usuários, bem como são realizados treinamentos específicos para o uso do sistema. Inicia-se o processo de manutenção do sistema.

5. Estudo de Caso: desenvolvimento de um ERP para indústrias de vestuário de micro e pequeno porte utilizando o processo AgileAdapt

Atualmente existem várias empresas que oferecem sistemas ERP especializado para indústrias de vestuário, dentre esses, três sistemas foram analisados, no qual dois deles atendem totalmente a uma indústria de vestuário, um deles não cobre os módulos básicos de um ERP, como o processo de produção completo (MRPII), em questão de usabilidade de interface gráfica (IG), dois deles deixam a desejar, possuem IG pouco intuitiva, dificultando o uso do sistema. Um fato que chama a atenção é o oneroso custo para uma empresa de micro e pequeno porte de implantar um sistema desse tipo. Analisando a região do centro-oeste de Minas Gerais, mais precisamente a cidade de Formiga-MG, o suporte para tais sistemas encontra-se a um raio de 200 km, o que pode tornar o processo lento, podendo causar prejuízos e atrasos para as organizações da região.

Nesse cenário e financiado parcialmente pela FAPEMIG, surge à motivação para o desenvolvimento do ERP para vestuário, visando empresas de micro e pequeno porte. O sistema será um software livre e independente de plataforma, denominado provisoriamente de SisVest. O ERP em construção abrangerá todos os setores de uma indústria de vestuário, composto por sete módulos, conforme apresenta a Figura 6.

FIGURA 6 – Interação entre os módulos do sistema ERP SisVest.

Fonte: Autor

A Figura 6 compreende, em síntese, o fluxograma de integração do ERP e o seus módulos terão basicamente as seguintes funções: O estoque irá controlar as compras e os estoques de materiais e de produtos acabados. A produção é responsável pelo processo produtivo, planejamento e controle da produção. O módulo de vendas irá controlar as vendas, prazos de entrega, marketing, pedidos e faturamento. O financeiro controlará as contas a receber, contas a pagar, bancos e caixa, fluxo de caixa, capital de giro e empréstimos de curto e longo prazo. O módulo de recursos humanos será responsável pela folha de pagamento, admissão e demissão de empregados, controle de férias, política de cargos e salários, controle de ponto e frequência e segurança e medicina do trabalho. O planejamento cuidará do controle orçamentário para períodos futuros de curto, médio e longo prazo, compreendendo o orçamento de produção, de custos, de vendas, de caixa, de investimentos e de resultado. Já a contabilidade será responsável pela integração das informações geradas por todos os demais módulos, tendo como base a contabilização de todas as operações da empresa, o controle fiscal e tributário, o controle dos custos de produção, a emissão de relatórios e livros obrigatórios, bem como a emissão de informações de natureza gerencial.

Todos os módulos são integrados e se comunicam, pois as informações geradas por cada um deles são importantes para os demais módulos, tendo como centro de comunicação e integração à contabilidade. Um exemplo é o módulo estoque, que comunica diretamente com o módulo de produção quando repassa insumos para a fabricação de um produto e quando esse produto retorna para o estoque como produto acabado. O mesmo módulo também se comunica com a contabilidade, pois as matérias primas consumidas no processo produtivo saem do estoque de materiais e passam para o estoque de produtos em elaboração e ao final do processo são contabilizadas como produtos acabados.

O fato de a contabilidade permear no centro da integração é que todas as operações realizadas pelas indústrias de confecções geram registros contábeis, que alteram o patrimônio da entidade. Através do processamento desses registros é possível gerar informações úteis de natureza econômica e financeira para o processo gerencial e de decisões.

Ressalta-se que cada módulo do sistema pode ser visto como um conjunto de minimódulos (não apresentados na Figura 6). Essa divisão foi necessária para o eficaz desenvolvimento ágil (fase de planejamento do AgileAdapt).

Em se tratando do tamanho da equipe, atualmente com 6 pessoas, dentre elas 1 gerente de projeto, 2 especialistas de domínio (pesquisadores da área de produção e contábeis –clientes), 2 programadores e 1 profissional para realizar testas, ressalta-se que a equipe faz reuniões duas vezes por semana para acompanhar o andamento dos processos.

O SisVest vem sendo implantado em 3 empresas da cidade de FORMIGA-MG. Cada empresa possui características de processos de produção diferenciada, possibilitando testes de aceitação diversificados sob os vários módulos do sistema.

O processo de desenvolvimento deu início com visitas da equipe de desenvolvimento em indústrias de vestuário da região para conhecer o processo de produção e administração das mesmas. Inicialmente, inspirada pela fase inicial do Scrum, foi realizada a confecção do product backlog (lista de funcionalidades e prioridades do sistema em alto nível), sob o ponto de vista dos proprietários, funcionários-chaves e pesquisadores da área de contabilidade, engenharia de produção e computação. A seguir, os módulos foram definidos (Figura 6) e as funcionalidades foram divididas em minimódulos.

Atualmente o módulo de Recursos Humanos (RH) foi parcialmente implantado nos três clientes, que estão utilizando e reportando ativamente as falhas. Estão em “produção” os módulos de estoque e produção, ambos sendo desenvolvidos concomitantemente. A Figura 7 apresenta uma tela do módulo de RH, no qual já foi implantado no cliente.

FIGURA 7 – Interface Gráfica do módulo de RH do SisVest.

Fonte: Autor

O sistema vem evoluindo gradativamente, o cliente pode ver a construção e ir testando o sistema. A documentação (fase de modelagem) se torna importante por ser um sistema bastante complexo e para posterior manutenção do ERP.

6. CONCLUSÕES

O método AgileAdapt é baseado em princípios semelhantes ao do XP, Scrum e FDD: requisitos estáveis ou desconhecidos, e iterações curtas para promover visibilidade ao desenvolvimento, resultados em flexibilidade, receptividade e confiabilidade.

Conforme já observado na prática, os clientes acompanham passo-a-passo a criação e implantação do produto. Os erros, tão logo descobertos são reportados, corrigidos e integrados juntamente com o próximo minimódulo a ser entregue. Percebe-se que a integração contínua torna o sistema totalmente flexível e adaptável. Logo, se conclui que os métodos ágeis são eficazes para sistemas ERP, sendo desenvolvidos por equipes pequenas e dividindo o mesmo em módulos/minimódulos a serem desenvolvidos em um intervalo de tempo médio de 45 dias.

Outro fato muito importante é a questão da documentação e a motivação dos stakeholders, pois como o sistema é desenvolvido em módulos com entregas em intervalos pequenos, os mesmos são capazes de avaliar o que esta sendo feito e se esta fora do escopo, diferente de muitos métodos tradicionais onde os interessados só veem os produtos ao final de todo o desenvolvimento.

Recomendações

O trabalho ainda está em desenvolvimento e os resultados futuros também serão publicados, tais como: casos de implantação do sistema final, após ter sido totalmente desenvolvido e experiências da fase de manutenção e treinamento.

Após implantação será feito um benchmarking para avaliação do produto com o objetivo de identificar oportunidades de melhorias.

Também se propõem a criação de um BI (Business Intelligence), pois os sistemas analisados possuem apenas relatórios gerenciáveis e como a utilização de técnicas de BI tem sido cada vez mais utilizada como diferencial competitivo por ser capaz de gerar informação para tomada de decisão em nível estratégico.

7. Referências Bibliográficas

• AMBLER, S. W. Modelagem ágil: práticas eficazes para a Programação Extrema e o Processo Unificado.  Trad. Acauan Fernandes. Porto Alegre: Bookman, 2004.
• ALVES, R. M; ZAMBALDE, A. L; FIGUEIREDO, C. F. Sistemas de informação. Lavras: UFLA/FAEPE, 2004.
• BECK, K. Extreme Programning Explained: Embrace change. Reading, Massachusttes. Ed. Addison-Wesley, 2000.
• BECK, K; COCKBURN, A.; JEFFRIES, R.; HIGHSMITH, J. Agile Manifesto. Ano 2001. Disponível em <http://www.agilemanifesto.org>, Ano 2001. Acesso em Maio de 2008.
• BEEBLE, M.; DEVOS, M.; SHARON, Y.; SCHWABER, K.; SUTHERLAND, J. SCRUM: An extension pattern language for hyperprodutive software development. Pattern Languages or Programs’98 Conference, 1998.
• BOOCH G; RUMBAUGH J. JACOBSON, I. UML – Guia do Usuário, Campus, 2000.
• CARTER, S. The New Language of Business, The: SOA & Web 2.0. IBM Press, 2007.
• CHAPPELL, D. A., JEWELL, T. Java Web Services. O’Reilly”, 2002.
• FAGUNDES, P.B. Framework para Comparação e Análise de Métodos Ágeis. 109f. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de Santa Catarina – UFSC, Florianópolis, 2005.
• FILHO, L.C. Implantação de Sistemas ERP (Enterprise Resources Planning): Um enfoque de Longo Prazo. São Paulo: Atlas, 2001.
• FOWLER, M. The New Methodology. Ano 2001. Disponível em: <http://www.martinfowler.com/articles/newMethodology.html>. Acesso em abr. 2008.
• HABERKORN, E. Teoria do ERP: Enterprise Resource Planning. São Paulo: Markron Books, 1999.
• MENDES, J. V; FILHO, E. E. Sistemas integrados de gestão ERP em pequenas empresas: um confronto entre o referencial teórico e a prática empresarial. Gest. Prod. vol.9 no.3. São Carlos, 2002.
• MONK, E.; WAGNER, B. Concepts Enterprise Resource Planning. Canada: Thomson, 2006.
• PALMER, S. Feature Driven Development – Integrating Best Practices. Ano 2003: Disponível em <http://www.step10.com/process/IntegratingBestPractices.html> acesso em abril de 2008.
• SCHWABER, K. Agile Process and Self-Organizattion. Ano: 2002. Disponível em http://www.agile.org.br
• TELES, V.M. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade Teles . São Paulo: Novatec, 2006.
• ZANCUL, E; ROZENFELD, H. Sistemas ERP. Disponível em: http://www.numa.org.br/conhecimentos/conhecimentosport/pagconhec/ERPv2.html. Acesso em 21 Maio 2008.

APÊNDICE – Agradecimento:

Os autores agradecem a FAPEMIG (Fundação de Amparo à Pesquisa do Estado de Minas Gerais) pelo apoio no desenvolvimento deste trabalho desenvolvido pelo Grupo de Pesquisa e Desenvolvimento em Gestão Empresarial (GPDEGE).

Sobre os Autores:

Marcos Antônio da Silva tem a formação: Bacharel em Ciência da Computação pelo Centro Universitário de Formiga (2008). Pós Graduado em MBA em BPM – Gestão de Processo de Negócio. Faculdades Pitágoras – Belo Horizonte (2011). Pós Graduado em Gestão de Projetos – UNIS-MG (2014). Área de Atuação: Analista de Sistema Sênior – Centro Universitário de Formiga – MG. E-mail de contato: custonho@gmail.com.

Paloma Maira Oliveira, Doutoranda em Ciência da Computação pelo DCC/UFMG. Concluiu o mestrado em Modelagem Matemática e Computacional pelo Centro Federal de Educação Tecnológica de Minas Gerais (CEFET-MG, 2006), bacharel em Ciência da Computação pelo UNIFOR-MG (2003). Atualmente é professora assistente efetiva do IFMG Campus Formiga/MG. Tem experiência na área de docência em Computação desde 2005. Atua principalmente nas seguintes áreas: Engenharia de Software, Educação a Distância, Informática na Educação (Softwares Educativo). E-mail de contato: pa_maira@yahoo.com.br.

 Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.