Visão geral

Esta entrada descreve um estudo de caso descrevendo um MRO real (Manutenção, Reparação e operações) processo de aprovação de fluxo de trabalho implementado no musgo.

Isto não é uma discussão técnica abertamente, Mas em vez disso precisa serve para fornecer um exemplo do mundo real que demonstra como a plataforma MOSS conheceu um mundo real.

(Esta entrada é Cruz publicado entre http://paulgalvin.spaces.live.com and http://blogs.conchango.com)

Plano de fundo

Processo MRO do cliente tinha sido caracterizado pela seguinte

• Processo de aprovação manual.
• Algum suporte usando planilhas do excel.
• Processo de aprovação irregular. O mesmo processo de aprovação de compra MRO que variam a cada dia, por pessoa.
• Lotes de papel e assinaturas manuscritas — compra requisições necessárias até 3 assinaturas escritas antes da aprovação final.

Os objectivos deste projecto incluído:

• Automatizar totalmente o processo de.
• Cumprimento das normas da empresa para aprovação.
• Fornecer uma visão consolidada de compra de MRO para vários gestores.
• Trilha de auditoria detalhada.

Como um efeito colateral da solução, escrito assinaturas não eram mais necessárias.

Processo de aprovação

O processo de aprovação é composto de quatro "pistas de natação": Originador, Gerente direto, Gerente funcional e o gerente de divisão.

Originador:

Vê a necessidade para a compra e inicia o processo. Note que o remetente pode ou não pode entrar na verdade a requisição de compra, Mas em vez disso direto a outro membro do pessoal para fazê-lo. Algumas vezes, o originador não tem a experiência técnica para preencher a requisição de PO. Por exemplo, um usuário pode querer um novo computador portátil da requisição, Mas não sabe o melhor fornecedor, Padrões, etc. Neste caso, as obras de originador com ele e ele realmente preenche a requisição.

Gerente direto:

Este é o gerente direto da entidade de origem (que pode ser diferente da pessoa que entrou na verdade a requisição de PO em MOSS). Gestores diretos devem aprovar a requisição de PO antes do sistema busca aprovação ainda mais para baixo da linha.

Gerente funcional:

O gerente funcional é o indivíduo responsável por garantir que a proposta de compra de acordo com normas da empresa no âmbito de uma determinada função corporativa. Por exemplo, IT de compras são aprovadas por um gerente funcional.

Gerente de divisão:

Gerentes de divisão aprovam requisições de compra estritamente pela quantidade de dólar. Gerente de divisão aprovar requisições de compra em excesso de uma quantidade de dólar configurável.

A solução

Usamos as seguintes ferramentas e componentes para implementar a solução:

MUSGO: Serve como a plataforma que todo o resto "trava". MOSS fornece serviços de alicerce para a segurança, dados mestre, trilhas de auditoria e outras características.

Serviços de formulários do InfoPath: Um componente de musgo, Isto permite que os usuários preencher requisições de compras através de um navegador da web.

SharePoint Designer (SPD): Usamos o SPD para implementar o processo de fluxo de trabalho automatizado.

Serviço Web: Um serviço de web c# aprimora a experiência do usuário, permitindo que listas de seleções em cascata no formulário do InfoPath e fornece melhor desempenho em relação a filtragem de dados. Consulte here para um mergulho técnico profundo sobre este assunto e nossas razões para usá-lo.

Listas personalizadas: MUSGO de perfis de usuário fornecido gerente direto de um determinado usuário., Mas não forneceu a maioria dos dados que controlava as decisões de fluxo de trabalho (EG. Se o gerente divisional é exigido para aprovar a requisição de PO). Nós usamos listas personalizadas em um "dados da empresa" site para manter dados como "Divisional Manager quantidade de dólar de aprovação", "Gerente de área funcional" e assim por diante. Listas muito bem integrada com o InfoPath e também criar/atualizar/excluir (CRUD) funcionalidade com segurança fora da caixa e auditoria.

Caso de uso

Este caso de uso ilustra como a solução se encaixa:

1. Paul quer um novo laptop. Ele descreve suas necessidades de Vivek, uma pessoa de ti familiarizado com padrões de laptop corporativo, fornecedores preferenciais, etc.
2. Vivek logs em MOSS, acessa o formulário de requisição de PO e entra a requisição em nome de Paul. O formulário solicita uma categoria de compra que usa os serviços da web para preencher uma lista suspensa de fornecedores aprovados empresa Vivek. Vivek também especifica a área funcional corporativa desta compra (EG. "ISSO" ou "Finanças").
3. SPD com base em fluxo de trabalho inicia, determina o gerente direto de Paul e encaminha a requisição para seu empresário, Stacy.
4. Stacy aprova a requisição de compra.
5. Fluxo de trabalho do SPD inspeciona a requisição e determina o que é uma compra IT. Ele direciona o fluxo de trabalho para o gerente funcional, Wonson.
6. Wonson aprova a requisição.
7. Fluxo de trabalho do SPD novamente inspeciona a requisição e determina que o valor da compra excede uma quantidade de dólar maxium e encaminha para o gerente de divisão para aprovação.
8. O gerente de divisão aprova a requisição de compra.

Notas

• O caso de uso demonstra um "limpa" executar sem rejeições ou saltos.
• Cada aprovador tem a capacidade de aprovar ou rejeitar a requisição, bem como fornecer comentários escritos. Estes são registrados na trilha de auditoria.
• Se um Gerente responsável rejeita a requisição de compra em qualquer ponto, a requisição de PO é "morta" e o processo deve ser iniciado desde o início.
• Fluxo de trabalho notifica o remetente em todas as etapas do processo de.
• Não há assinaturas escritas — o cliente de determinada (Depois de algumas recomendações incisivas) que a auditoria trail conforme fornecido através do histórico do fluxo de trabalho, serviu a suas necessidades de auditoria.
• Esforço — Demorou homem aproximadamente três semanas para implementar esta solução.

Conclusão

Essa solução aproveita MOSS como uma plataforma de desenvolvimento e tempo de execução. O cliente foi capaz de aproveitar os recursos de musgo de núcleo para automatizar um processo de negócios rotina que afetou quase todos os funcionários da empresa. Com excepção de um serviço web simples (que se aproveita de musgo), quase nenhuma programação a real"" foi necessário.

A solução também serve como uma vitrine"" para o cliente, demonstrando como diferentes recursos do MOSS pode ser combinado para criar um aplicativo de negócios totalmente caracterizado e gerar novas oportunidades de consultoria no futuro.

Glossário

MRO: Manutenção, reparação e operações. Essas compras normalmente incluem itens como blocos de notas, cadeiras, computadores pessoais, impressoras, telefones celulares e afins.