Panoramica

Questo articolo descrive un caso di studio che descrive un'effettiva MRO (Manutenzione, Riparazione e operazioni) processo di flusso di lavoro approvazione attuato in MOSS.

Questa non è una discussione tecnica apertamente, ma invece serve per fornire un esempio reale che dimostra come la piattaforma MOSS ha incontrato un reale bisogno.

(Questa voce è croce pubblicato tra http://paulgalvin.spaces.live.com e http://blogs.conchango.com)

Sfondo

Processo MRO del client era stata caratterizzata dal seguente

• Processo di approvazione manuale.
• Qualche supporto utilizzando fogli di calcolo di excel.
• Processo di approvazione irregolare. Lo stesso processo di approvazione di acquisto MRO varierebbe giorno per giorno, persona di persona.
• Sacco di carta e firme scritte a mano — richieste fino a richieste di acquisto 3 firme scritte prima dell'approvazione finale.

Obiettivi di questo progetto incluso:

• Automatizzare completamente il processo di.
• Applicare standard di impresa per l'approvazione.
• Vista consolidata di MRO acquisto ai vari responsabili di fornire.
• Audit trail dettagliato.

Come effetto collaterale della soluzione, firme scritte non erano più richiesti.

Processo di approvazione

Il processo di approvazione è costituito da quattro "nuotata corsie": Ordinante, Gestore diretto, Manager funzionali e Direttore Divisione.

Ordinante:

Vede la necessità per l'acquisto e avvia il processo di. Si noti che il mittente può o non può entrare in realtà la richiesta di acquisto, ma al contrario indirizzare un altro membro del personale di farlo. Alcune volte, il mittente non ha le competenze tecniche di compilare la richiesta di PO. Per esempio, un utente potrebbe voler requisire un nuovo computer portatile, ma non conosce il migliore fornitore, Standard IT, ecc. In questo caso, le opere del creatore con esso ed è effettivamente compila la richiesta.

Gestore diretto:

Questo è il gestore diretto del creatore della (che può essere diverso dalla persona che effettivamente stipulato la requisizione PO MOSS). I responsabili diretti devono approvare la richiesta di PO prima che il sistema cerca l'approvazione più ulteriormente giù la linea.

Manager funzionali:

Il manager funzionale è l'individuo responsabile di assicurare che la proposta di acquisto è conforme alle norme di impresa nell'ambito di una determinata funzione azienda. Per esempio, IT acquisti sono approvati da un responsabile funzionale IT.

Direttore Divisione:

Manager Divisione approva le richieste di acquisto rigorosamente con l'importo in dollari. Manager divisione approvare le richieste di acquisto superiori a un importo in dollari configurabile.

La soluzione

Abbiamo utilizzato i seguenti strumenti e componenti per implementare la soluzione:

MUSCHIO: Funge da piattaforma off che tutto il resto "si blocca". MOSS fornisce servizi di substrato roccioso per la sicurezza, dati master, audit trail e altre caratteristiche.

Servizi di moduli di InfoPath: Un componente MOSS, Ciò consente agli utenti di compilare le richieste di acquisto tramite un browser web.

SharePoint Designer (SPD): Abbiamo usato SPD per implementare il processo di workflow automatizzato.

Servizio Web: Un servizio web c# migliora l'esperienza utente abilitando CSS elenchi di selezioni nel modulo di InfoPath e fornisce prestazioni migliori rispetto al filtro dei dati. Vedere qui per un'immersione profonda tecnica su questo argomento e i nostri motivi per usarlo.

Elenchi personalizzati: Profili di utente di muschio forniti responsabile diretto di un determinato utente, ma non ha fornito la maggior parte dei dati che controllava le decisioni del flusso di lavoro (e. g. Se il manager divisionale è necessaria per approvare la richiesta di PO). Abbiamo usato gli elenchi personalizzati nella "banca dati dei" sito per mantenere dati quali "Divisional Manager approvazione importo in dollari", "Funzionale Area Manager" e così via. Elenchi molto ben integrato con InfoPath e forniscono anche creare/aggiornamento/eliminazione (CRUD) funzionalità di controllo e di protezione, fuori dalla scatola.

Caso d'uso

Questo caso uso illustra come la soluzione adatta insieme:

1. Paul vuole un nuovo computer portatile. Egli descrive i suoi bisogni di Vivek, una persona IT familiarità con gli standard aziendali portatile, fornitori preferiti, ecc.
2. Vivek registri in MOSS, accede il modulo di richiesta di PO ed entra la richiesta a nome di Paul. Il modulo richiede Vivek per una categoria di acquisto che utilizza i servizi web per compilare un elenco a discesa di fornitori di società-approvato. Vivek specifica anche l'area funzionale azienda di questo acquisto (e. g. "ESSO" o "Finance").
3. SPD basata del flusso di lavoro inizia, determina la gestione diretta di Paul e indirizza la richiesta al suo manager, Stacy.
4. Stacy approva la richiesta di acquisto.
5. Flusso di lavoro SPD esamina la richiesta e determina che è un acquisto IT. Indirizza il flusso di lavoro per l'IT manager funzionali, Wonson.
6. Wonson approva la richiesta.
7. SPD workflow nuovamente esamina la richiesta e determina che l'importo dell'acquisto supera un importo in dollari o massima e si indirizza al responsabile della divisione approvazione.
8. Il manager della divisione approva la richiesta di acquisto.

Note

• Dimostra il caso di usare un "ambiente pulito" eseguire senza rifiuti o salti.
• Ogni revisore ha la possibilità di approvare o rifiutare la richiesta, nonché a fornire commenti scritti. Questi vengono registrati nell'audit trail.
• Se un manager responsabile respinge la richiesta di acquisto in qualsiasi punto, la richiesta di PO è "morta" e il processo deve essere avviato dall'inizio.
• Flusso di lavoro notifica al mittente ad ogni passo del processo di.
• Nessuna scritte firme — il cliente determinato (Dopo alcune raccomandazioni forti) che l'audit trail come previsto attraverso la storia del flusso di lavoro, servite la loro necessità di revisione.
• Sforzo — Ci sono voluti uomo circa tre settimane per implementare questa soluzione.

Conclusione

Questa soluzione si avvale di MOSS come sviluppo e piattaforma runtime. Il client è stato in grado di sfruttare funzionalità di MOSS base per automatizzare un processo aziendale ordinaria che ha colpito quasi ogni dipendente della società. Con l'eccezione di un semplice servizio web (che a sua volta sfrutta MOSS), quasi nessun effettivo "programmazione" è stato richiesto.

La soluzione serve anche come una vetrina"" per il cliente, dimostrando come le diverse caratteristiche di muschio possa essere combinato per creare un'applicazione aziendale completamente descritto e generare nuove opportunità di consulenza in futuro.

Glossario

MRO: Manutenzione, riparazione e operazioni. Questi acquisti in genere comprendono elementi quali blocchetti per appunti, sedie, Personal computer, stampanti, telefoni cellulari e simili.