Use o IBM FileNet P8 para impulsionar o desenvolvimento de novos produtos

Uma implementação simples mostra como empresas de mercadorias de produtos ao consumidor podem usar o IBM FileNet P8 para acelerar a introdução de novos produtos

O New Product Development (NPDI) é uma arte estratégica da estratégia de crescimento para empresas de mercadorias de produtos ao consumidor. É um processo bastante focado em conteúdo e controlado por prazos finais. Este artigo descreve como o IBM® FileNet® P8 pode ser usado para implementar um subprocesso do NPDI denominado gerenciamento de mudanças de ilustrações. O artigo descreve como as seguintes partes da implementação de exemplo foram implementadas: criação de um fluxo do processo, uso do eForm para lançar o fluxo do processo e a construção de uma interface da Web usando Enterprise Content Management (ECM) Widgets. Além disso, descreve duas outras tarefas necessárias para esta solução: oferecer uma visão geral das solicitações pendentes, e implementar um processo de revisão ad hoc. O objetivo é fornecer alguns insights sobre como juntar elementos do portfólio do ECM para implementar suas próprias soluções.

Jeff Douglas, Industry Solutions, Enterprise Content Management, IBM

Jeff Douglas photoJeff Douglas é um membro da equipe de soluções de segmento de mercado dentro da organização IBM Enterprise Content Management. O foco de Jeff está na integração do portfólio ECM em soluções estratégicas dentro de vários segmentos de mercado. Jeff está com a IBM há cinco anos e trabalha no espaço de gerenciamento de informações há 17 anos.



31/Mar/2010

Introdução

A chave para o crescimento de empresas de produtos ao consumidor é a capacidade de introduzir novos produtos no mercado. A capacidade de passar eficientemente da avaliação de uma ideia de produto para a fabricação e distribuição de um produto real é crítica para o sucesso. A implementação desse processo requer a integração de uma quantidade significativa de diversas informações e a automação de um processo colaborativo complexo e dinâmico.

Através da sua combinação de capacidades de gerenciamento de conteúdo e gerenciamento de processos, o IBM FileNet P8 pode servir como a fundação para uma implementação eficiente do processo de New Product Development (NPDI). O FileNet P8 também pode ativar outras funcionalidades importantes, como a conformidade e o insight analítico das operações do processo de negócios.

Este artigo descreve como implementar uma parte do processo NPDI: o gerenciamento de mudanças de ilustrações. O objetivo é fornecer um insight sobre como é possível aproveitar as diferentes partes do IBM FileNet P8 para produzir soluções semelhantes. O artigo foca especificamente a criação de um fluxo do processo, o uso do eForm para lançar o fluxo do processo e a construção de uma interface da Web usando ECM Widgets. Ele também descreve duas tarefas adicionais que são necessárias para esta solução: oferecer uma visão geral das solicitações pendentes, e implementar um processo de revisão ad hoc. A seção Recursos no final do artigo fornece links para recursos com mais detalhes sobre o processo geral de NPDI e o valor fornecido pelo ECM.


Gerenciamento de mudanças de ilustrações

Dentro do processo de NPDI, o gerenciamento de mudança de ilustrações é onde as ilustrações são alteradas ou criadas para suportar uma nova oferta de produtos. A Figura 1 fornece uma visão geral das etapas, participantes e conteúdo que compõem o processo.

Figura 1. Visão geral do gerenciamento de mudança de ilustrações
Visão geral do gerenciamento de mudança de ilustrações

O processo tipicamente é de propriedade de um líder de marketing, que colabora com vários outros grupos, incluindo engenharia, pesquisa, ilustrações, jurídico e manufatura. É gerada uma quantidade significativa de conteúdo, incluindo documentos de projeto, etiquetas nutricionais, ilustrações, documentos jurídicos e feedback de revisões.

As próximas seções deste artigo descrevem como a implementação de exemplo foi desenvolvida usando capacidades "prontas para uso" do IBM FileNet P8. Este artigo assume a familiaridade com os componentes do produto FileNet P8.

Produtos usados no desenvolvimento da implementação de exemplo

Todo este exemplo foi desenvolvido usando apenas componentes de software existentes na suíte do IBM FileNet P8:

  • O repositório de conteúdo é o P8 Content Engine 4.5.1.
  • O processo de negócios usa o P8 Business Process Manager 4.5.1.
  • O formulário eletrônico foi construído usando o FileNet P8 eForms 4.0.2.4.
  • As páginas de interface de usuário personalizadas foram construídas usando os ECM Widgets 4.5.1.
  • As capacidades de pesquisa foram implementadas usando o Workplace XT 1.1.4.

Criando a infraestrutura do gerenciamento de mudanças de ilustrações

A Figura 2 mostra o fluxo do processo para o gerenciamento de mudanças de ilustrações, os proprietários de determinadas etapas e os documentos críticos que são produzidos.

Figura 2. O fluxo do processo de gerenciamento de mudanças de ilustrações
O fluxo do processo de gerenciamento de mudanças de ilustrações

Em um cenário típico de gerenciamento de mudanças de ilustrações, o líder de marketing inicia uma solicitação de mudança para apoiar o desenvolvimento de uma nova linha de sorvetes. Em seguida, as ilustrações devem ser criadas de acordo com a embalagem recentemente projetada e atender a todos os requisitos de marketing, jurídicos e corporativos.

A solicitação inicialmente vai para os grupos de engenharia e pesquisa, em paralelo. Cada grupo é responsável por criar ou aprovar um documento que é enviado ao líder de ilustrações, para que ele possa produzir as ilustrações necessárias. Quando as ilustrações forem concluídas, passam por um processo de revisão e aprovação que pode envolver vários grupos. Finalmente, as ilustrações e o conteúdo de apoio são fornecidos de volta ao sistema de gerenciamento de ciclo de vida de produtos operacionais.

Definindo as classes de documento

Nesta implementação de exemplo, usamos o Content Engine Enterprise Manager para definir quatro classes de documentos. Os primeiros três são críticos para o gerenciamento de mudança de ilustrações:

  • A Etiqueta Nutricional (NLI) é gerada pelo líder de pesquisa.
  • O Marcador Gráfico descreve o projeto da embalagem do produto e é produzido pela engenharia.
  • As Ilustrações são criadas pelo departamento de ilustrações.

Cada uma das classes acima utiliza propriedades do sistema, tais como proprietário e data de criação. Propriedades adicionais tais como ID do caso, ID do material e ID do produto também foram adicionadas. Essas propriedades possibilitam uma pesquisa flexível de documentos, que é um importante requisito esta solução. O ID do caso é também importante porque possibilita o agrupamento de todos os documentos associados com uma determinada solicitação de mudança. Isso oferece um contexto consistente e completo à medida que o processo se move entre os participantes e entra e sai de vários sistemas.

Cada documento que pertence a uma dessas classes tem uma propriedade que indica o seu estado (rascunho, revisão ou aprovado) bem como a pessoa designada (a pessoa que trabalha no documento no momento). Finalmente, cada uma dessas classes de documento utiliza as anotações adequadamente para possibilitar que os participantes do processo efetuem comentários. A ativação da colaboração através de comentários é outro requisito importante do gerenciamento de mudanças de ilustrações.

A quarta classe de documento é uma classe de documento mais básica para suportar documentos como planos de projeto e feedback de revisões. Essa classe tem três propriedades: proprietário, título do documento e ID do caso.

Implementando o processo de negócios

A Figura 3 mostra o fluxo de processo de negócios do gerenciamento de mudanças de ilustrações para a implementação de exemplo. Ele foi criado usando a ferramenta Process Designer.

Figura 3 O processo de gerenciamento de mudança de ilustrações
Figura 3 O processo de gerenciamento de mudança de ilustrações

Este processo é simples. A seguir, algumas notas sobre o projeto:

  • As rotas de saída para a etapa Case Setup são marcadas como "todas as condições verdadeiras" para reforçar o requisito de que o líder de engenharia e o líder de pesquisa trabalhem em paralelo.
  • O líder de ilustrações tem uma dependência da conclusão do trabalho dos líderes de engenharia e pesquisa. Para reforçar isso, a etapa Develop Artwork está identificada como uma etapa coletora na guia de roteamento. A etapa Corporate and Legal também é identificada como coletora, para garantir que todos os documentos estejam em sua versão final antes que ocorram as aprovações finais.
  • É possível que as etiquetas nutricionais e os documentos do projeto mudem ao longo do processo. Como resultado, foram adicionadas etapas específicas ao fluxo do processo para confirmar que as versões finais estejam implementadas.
  • Para esta implementação de exemplo, páginas da Web de interface com o usuário foram construídas usando ECM Widgets para possibilitar que os participantes concluam etapas no fluxo do processo. A criação dessas páginas será descrita em mais detalhes posteriormente neste artigo. Após a criação dessas páginas, elas são vinculadas à etapa apropriada através da definição de uma etapa processadora para essa etapa e da designação da URL da página de IU a ela.

Existem várias maneiras de designar determinadas etapas do processo para uma função ou indivíduo. Funções ou indivíduos podem ser designados a grupos de fluxo de trabalho. Caixas de entrada pessoais também podem ser criadas. Para esta implementação simples, filas de trabalhador são criadas para cada etapa do processo e designadas a determinadas funções. Em seguida, essas filas de trabalhador alimentam as caixas postais da função à qual foram designadas.

Existem vários campos de dados definidos para o processo. Matrizes de anexos são definidas para manter documentos de ilustrações, e campos de anexos são definidos para manter a etiqueta nutricional e o marcador gráfico. Embora anexos individuais sejam usados para estes, também poderiam ter sido incluídos em um único array de anexos. A colocação deles em seu próprio campo de anexo facilita o seu destaque na interface de usuário.

Como parte da definição deste processo, os designers podem construir notificações de e-mail, marcos e pontos de escalação para assegurar que o processo progrida de acordo com o planejado. Também poderiam existir vários pontos no processo onde os dados fossem recuperados de um sistema operacional, tal como SAP ou IBM InfoSphere Master Data Management. Por exemplo, é bem provável que as informações sejam recuperadas de um sistema operacional para inicializar a etiqueta nutricional para o líder de pesquisa e desenvolvimento. Além disso, no final do processo, os dados seriam alimentados de volta ao sistema operacional antes de concluir o processo. Como este exemplo foi construído como uma implementação independente, essa integração com sistemas operacionais não foi implementada. No entanto, seria feita de forma simples usando uma etapa de componente e alguns módulos de código personalizados.

Iniciando a solicitação de mudança de ilustrações com um eForm

O líder de marketing inicia a solicitação de mudança preenchendo um formulário eletrônico. Esse formulário é mostrado na Figura 4 abaixo.

Figura 4. Lançando o processo com um formulário eletrônico
Lançando o processo com um formulário eletrônico

O líder de marketing fornece o símbolo UPC para o produto. O símbolo UPC é usado em seguida para preencher a maioria dos outros campos do formulário, incluindo o número do material, tipo de embalagem, código da marca e número do projeto. Além disso, são fornecidos participantes padrão para o processo. Eles podem ser alterados pelo líder de marketing através da seleção em uma lista de participantes.

Os valores padrão no campo seriam provavelmente recuperados de um banco de dados ou sistema operacional usando o símbolo UPC como o valor da chave. Dentro do eForm, configurações simples do tipo apontar e clicar possibilitam que conectores (como uma conexão JDBC connection ou uma chamada para serviços da Web) recuperem esses valores.

Uma política de formulários é usada para associar o eForm com o processo de mudança de ilustrações. As políticas de formulário são criadas usando o Workplace XT. Ao cria a política de formulário, o modelo do formulário e o fluxo do processo podem ser escolhidos no repositório. Em seguida, os campos do eForm são mapeados a campos de dados no fluxo de processo. A maneira mais fácil de fazê-lo é designando um nome de campo do eForm igual ao nome do campo de dados correspondente (os nomes de campo distinguem entre maiúsculas e minúsculas). Isso possibilita que o assistente de política de formulário mapeie automaticamente os campos juntos.

Dentro do assistente, é possível também configurar a segurança para controlar quem pode lançar o eForm. Para a implementação de exemplo, essa autoridade é concedida aos membros do departamento de marketing.

Fornecendo uma visualização das solicitações de mudança pendentes

A qualquer momento, o líder de marketing pode desejar visualizar todas as solicitações de mudança pendentes no sistema. A visualização de ver essas solicitações de mudança, suas datas planejadas e o seu estado atual ajudam a assegurar que cada solicitação de mudança esteja progredindo conforme esperado e a tomar medidas, se necessário.

Para implementar essa funcionalidade, cada solicitação de mudança é representada por um documento especial no repositório. Os documentos pertencem a uma classe de documentos com as propriedades de proprietário, estado do caso e ID do caso. Embora existam vária maneiras de representar uma solicitação de mudança, há várias vantagens em usar um documento para fazê-lo:

  • O documento persiste no repositório mesmo depois que a instância do processo que executa a solicitação de mudança seja concluída.
  • As propriedades do documento podem armazenar informações sobre a solicitação de mudança, como o seu estado.
  • O documento pode servir como um contêiner para um diário sobre a própria solicitação de mudança — um lugar onde anotações e comentários sobre o caso possam ser armazenados. O diário da solicitação de mudança é importante porque pode ser usado para analisar a eficácia do processo. As anotações no diário da solicitação de mudança podem ser importantes para finalidades de auditoria ou conformidade. Diários de solicitações de mudança diferentes podem ser reunidos para fornecer análises interessantes sobre o processo de solicitação de mudança.

O documento de solicitação de mudança é adicionado e mantido usando as etapas do fluxo do processo. O diagrama na Figura 5 mostra o fluxo modificado.

Figura 5. Rastreando o status de uma solicitação de mudança
Rastreando o status de uma solicitação de mudança

Dois tipos de etapas foram adicionados. Primeiramente, imediatamente após a conclusão do lançamento, um processador de etapa de componente é adicionado para criar o documento de solicitação de mudança (identificado como "Create request document" no diagrama). A parte inferior da captura de tela mostra a configuração do novo processador de etapas. No lado direito estão os parâmetros para a função createDocument Content Engine (CE) usada para criar o documento de solicitação de mudança. O nome do novo documento de solicitação de mudança é configurado para processar o campo de dados de fluxo denominado CaseID, que foi configurado quando a solicitação foi lançada. Além disso, uma referência para o novo documento de solicitação de mudança é armazenada no campo de dados do anexo denominado CaseTracker, de modo que possa ser acessado durante todo o fluxo do processo. Todos os documentos do caso são armazenados na pasta do repositório referenciada no campo de dados do anexo denominado CaseFolder. O tipo de documento pode ser simples ou XML.

O parâmetro propArray é usado para definir as propriedades do novo documento do caso. O formato do array é uma série de tuplas no seguinte formato:

<nome, tipo e valor da propriedade>

Então, por exemplo, para definir o estado inicial da solicitação de mudança, defina o parâmetro propArray para:

"{'CaseState', 'STRING', CaseState}"

Onde o terceiro argumento no exemplo acima é o campo de dados do fluxo do processo denominado CaseState.

Após a criação do documento de solicitação de mudança, etapas adicionais podem ser inseridas no fluxo do processo para atualizar o documento da solicitação. Duas dessas etapas são mostradas na Figura 5: uma após Generate NLI e outra após Load Die Line. Dentro dessas etapas (identificadas como Update Case State), funções setProperty podem ser usadas para atualizar as propriedades de um documento de solicitação de mudança, como o estado ou o designado.

Após a implementação da infraestrutura, o líder de marketing poderá usar uma página da Web personalizada como a mostrada na Figura 6 para visualizar as solicitações de mudança.

Figura 6. Interface do usuário para a visualização de solicitações de mudança pendentes
Interface do usuário para a visualização de solicitações de mudança pendentes

(Consulte uma versão maior da Figura 6.)

A interface do usuário mostrada acima é implementada usando IBM FileNet ECM Widgets, que são uma coleção de componentes de interface de usuário da Web que podem ser vinculados para fornecer uma interface de usuário da Web personalizada. Existem quatro widgets nesta página:

  • Na parte superior da página há um widget de barra de ferramentas. É possível usar um widget de barra de ferramentas para criar um menu suspenso de ações personalizadas. A partir da barra de ferramentas desta página, o líder de marketing pode iniciar uma nova solicitação de mudança, que exibirá o formulário eletrônico descrito anteriormente e mostrado na Figura 4.
  • O próximo widget da página é o de lista de conteúdo. Os widgets de lista de conteúdo mostram os resultados das pesquisas no repositório. Eles são configurados pelo fornecimento da URL de uma pesquisa armazenada criada através do Search Designer no Workplace XT. O widget de lista de conteúdo desta página mostra as solicitações de mudança pendentes designadas para este líder, juntamente com informações importantes sobre cada uma, como o estado atual e o designado.
  • Na parte inferior esquerda da página há outro widget de lista de conteúdo. Quando o líder de marketing selecionar uma determinada solicitação de mudança na lista na parte superior da página, será executada uma pesquisa e todos os documentos associados com essa solicitação de mudança serão exibidos no widget na parte inferior esquerda da página. Usando este widget, o líder de marketing poderá revisar e editar cada documento.
  • O widget na parte inferior direita da página é um widget de visualizador. Um widget de visualizador toma um determinado documento e exibe seu conteúdo. Para este aplicativo, o widget toma o documento de solicitação de mudança da seleção na parte superior da página e exibe seu conteúdo, que é o diário da solicitação de mudança. No momento, esta visualização é somente leitura. No entanto, um widget personalizado poderia ser criado para possibilitar que o líder de marketing possa adicionar mais comentários ao diário.

Os widgets na implementação simples são vinculados juntos de modo que quando uma solicitação de mudança for selecionada na lista de conteúdo superior, o caseID da solicitação seja passado para o widget na parte inferior esquerda como a chave para a pesquisa e o documento de solicitação de mudança seja passado para o widget na arte inferior direita. Essa vinculação é realizada através da conexão dos widgets. Os widgets têm um comportamento de visualização padrão que na maioria dos casos facilita a sua vinculação.

A conexão do widget visualizador de documentos ao widget de lista de conteúdo superior é um exemplo do uso do comportamento padrão. Na lista de opções de configuração do widget para o widget visualizador de documentos, a opção de conexão do widget seria selecionada e o widget de lista de conteúdo seria conectado ao widget visualizador no diálogo correspondente. Depois disso, o comportamento padrão do widget de lista de conteúdo é passar o documento referenciado da linha selecionada para o visualizador para exibição, que é exatamente a ação necessária.

Para requisitos de conexão personalizados, é possível usar o widget adaptador de JavaScript, um widget não visual que possibilita escrever código JavaScript para implementar funcionalidades personalizadas. Na mesma implementação, esse widget é usado para vincular a lista de conteúdo superior com a lista de conteúdo inferior à direita. O JavaScript é usado para passar o CaseID da linha selecionada do widget superior para o widget inferior, onde é usada como a chave para pesquisa. Para fazer isso, um widget adaptador de JavaScript seria adicionado à página e preenchido com o seguinte código JavaScript:

return [{'name':'CaseID', 'value':payload.name}]

Neste exemplo, payload é um objeto que representa o que está sendo passado a partir da lista de conteúdo. O valor para a propriedade denominada name é designado ao parâmetro CaseID, onde será usado na pesquisa de documentos.

Em seguida, seria necessário conectar os widgets de lista de conteúdo, de adaptador de JavaScript e o visualizador entre si, conforme mostrado abaixo na Figura 7, e ocultar o widget de adaptador de JavaScript de modo que não seja exibido na interface do usuário.

Figura 7. Conectando dois widgets entre si
Conectando dois widgets entre si

Criando um ambiente de trabalho personalizado usando widgets

Na implementação de exemplo, cada participante tem responsabilidades únicas. Embora haja alguma sobreposição, as atividades executadas por cada participante são diferentes. Como resultado, cada participante precisa de um ambiente personalizado para concluir o seu trabalho da forma mais eficiente possível. Esta seção do artigo demonstra como é possível usar os Widgets do IBM FileNet ECM para criar ambientes de trabalho personalizados baseados na Web.

A Figura 8 mostra uma captura de telada página de ambiente de trabalho para o líder de engenharia.

Figura 8. Ambiente de trabalho baseado na Web para o líder de engenharia
Ambiente de trabalho baseado na Web para o líder de engenharia

(Consulte uma versão maior da Figura 8.)

Existem cinco ECM widgets nesta página:

  • Na parte superior da página há um widget de caixa de entrada, que mostra todas as tarefas designadas para esse engenheiro.
  • A seguir há um widget de barra de ferramentas. Para o engenheiro, o widget de barra de ferramentas contém três opções: criar um novo teamroom, conduzir uma pesquisa de documentos e iniciar um processo de revisão. Novos itens podem ser adicionados à barra de ferramentas configurando o widget de barra de ferramentas e adicionando novos itens de menu. Itens de menu podem ser de diferentes tipos; neste exemplo, todas as ações são controladas por URL, portanto, cada opção de menu está configurada com o URL a ser invocado quando a opção for selecionada.
  • Abaixo do widget de barra de ferramentas, há um widget de dados de trabalho que mostra todas as propriedades de uma tarefa selecionada.
  • À direita, há um widget de anexo com o rótulo Change Request Documents, que mostra todos os anexos associados com esta tarefa em particular. Na captura de tela há um anexo para o marcador gráfico (o engenheiro preencherá esse anexo quando estiver pronto) e um anexo para o plano de projeto desta solicitação de mudança.
  • Na parte inferior direita há um widget de conclusão de etapa com o rótulo Task Actions. Esse widget é usado para salvar qualquer trabalho feito em uma determinada tarefa, bem como para marcar uma tarefa como concluída. Quando a tarefa for marcada como concluída, será removida da lista de tarefas do engenheiro.

Para associar esta página com o líder de engenharia e configurar a lista de tarefas para exibir sua caixa de entrada, as etapas a seguir devem ser seguidas:

  1. A partir do Process Configuration Console, crie um Application Space para fornecer o contexto de todos os ECM widgets que são parte da solução.
  2. Usando o Process Configuration Console, defina o Engineering Role dentro do Application Space e especifique essa página como sendo a página inicial para o Engineering Role.
  3. Ao configurar esta página para representar o processador de tarefas bem como a página inicial, configura o widget de caixa de entrada para não abrir a tarefa em uma janela separada. Este URI já deve ter sido especificado para o processador de tarefas quando o fluxo do processo foi construído usando o Process Designer.
  4. Usando o Process Configuration Console, defina o widget de caixa de entrada do Engineering Role como mapeado com a Engineering Work Queue, que foi definida ao construir o fluxo do processo. Para esta solução de exemplo, somente é necessária uma caixa de entrada ECM para cada uma das Work Queues criadas e usadas quando o fluxo do processo foi implementado.

Essas etapas devem ser executadas para todas as páginas que estão associadas a etapas particulares do fluxo do processo.

Ativando revisões dinâmicas

Um requisito importante do gerenciamento de mudanças de ilustrações é o suporte a revisões dinâmicas. Os líderes de engenharia, pesquisa, ilustrações e marketing podem todos precisar iniciar um processo de revisão à medida que concluem seu trabalho. Por exemplo, à medida que o líder de engenharia trabalha no processo de criar o marcador gráfico, provavelmente iniciará uma revisão interna ad hoc. Nesse ponto, o engenheiro deve identificar uma lista de pessoas que participarão da revisão, os documentos a serem revisados e a data de conclusão pretendida. Quando nenhuma dessas informações for conhecida antecipadamente, a modelagem do fluxo do processo para o processo geral pode ser um desafio.

Para esta implementação de exemplo, o Process Designer foi usado para criar um processo de revisão simples, e em seguida um item de ação foi adicionado à barra de ferramentas do líder de engenharia. O item de ação possibilita que o líder de engenharia invoque o processo de revisão, o que resulta na tela mostrada abaixo na Figura 9.

Figura 9. Lançando um processo de revisão interna
Lançando um processo de revisão interna

A tela mostrada na Figura 9 é a tela inicial padrão do WorkplaceXT para um fluxo do processo. Ela exibe os campos de dados do fluxo do processo e possibilita que o usuário inicialize os valores antes do lançamento.

A partir dessa tela, o líder de engenharia pode selecionar os membros da equipe que participarão da revisão, anexar os documentos necessários, e fornecer instruções e comentários para orientar os revisores enquanto verificam os documentos. Quando o fluxo do processo for lançado, os membros da equipe são adicionados ao grupo de trabalho do processo de revisão e os documentos são encaminhados a eles para revisão. O líder de engenharia será notificado quando a revisão for concluída, e poderá então enviar seu documento de projeto para a solicitação de mudança.

O uso de um fluxo do processo para modelar o processo de revisão possibilita que o ECM forneça automação a esse processo. Isso ajuda a impulsionar eficientemente um processo que é tipicamente conduzido manualmente e muitas vezes é uma fonte de ineficiência. Além disso, como o processo está sendo controlado pelo ECM, informações podem ser adicionadas ao diário da solicitação na conclusão, indicando quem revisou o documento. Essas informações podem ser importantes por motivos históricos ou de conformidade.


Resumo

Este artigo passa pelos elementos de uma implementação de exemplo que demonstra como o IBM FileNet P8 pode servir como fundação para construir um processo de negócios para gerenciar as mudanças de ilustrações. Esse processo é uma parte importante do desenvolvimento de novos produtos nos segmento de mercado de produtos ao consumidor, bem como em outros segmentos de mercado que constroem e enviam produtos. O artigo fornece detalhes técnicos sobre como criar o fluxo do processo, usar um formulário eletrônico para lançar o processo e criar páginas da Web personalizadas usando widgets. Além disso, aborda dois requisitos específicos da solução: fornecer uma visão geral das solicitações de mudança pendentes e implementar processos dinâmicos, como revisões internas. Além de serem elementos críticos do processo de gerenciamento de mudança de ilustrações, esses detalhes de implementação podem também ser úteis ao construir outros tipos de soluções baseadas em caso.

Recursos

Aprender

  • Saiba mais sobre a consultoria de negócios IBM para o segmento de mercado de produtos ao consumidor; entre em contato com o seu representante de vendas ou de suporte ao cliente da IBM FileNet para obter mais informações sobre a implementação de exemplo descrita neste artigo ou para agendar uma demonstração completa.
  • Na Zona ECM no developerWorks, obtenha os recursos que você precisa para aprimorar suas qualificações nos produtos IBM Enterprise Content Management.
  • Saiba mais sobre o FileNet P8 na página da Web do Enterprise Content Management.
  • Encontre detalhes sobre a plataforma IBM FileNet P8 e seus componentes relacionados no centro de informações do IBM FileNet P8.

Obter produtos e tecnologias

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=471991
ArticleTitle=Use o IBM FileNet P8 para impulsionar o desenvolvimento de novos produtos
publish-date=03312010