概要

このエントリには実際の MRO を記述する事例について説明します (メンテナンス, 修理および操作) モスで実装されるワークフロー承認プロセス.

これは、あからさまに技術的な議論ではないです。, しかしコケ プラットフォームが現実世界を満たす方法を示す実例を提供するために役立つ必要があります代わりに.

(このエントリは、クロスの間に掲示 http://paulgalvin.spaces.live.com と http://blogs.conchango.com)

背景

クライアントの MRO のプロセスは、次によって特徴付けされていた

• 手動の承認プロセス.
• スプレッドシートを excel を使用して、いくつかのサポート.
• 不規則な承認プロセス. 同じ MRO 購買承認プロセス変化日, 人による人.
• 多くの紙と手書きの署名 — 購買依頼に必要な 3 最終承認前に書かれた署名.

含まれているこのプロジェクトの目標:

• 完全に自動化します。.
• エンタープライズ標準承認を適用します。.
• MRO 購入様々 なマネージャーの統合ビューを提供します。.
• 詳細な監査証跡.

ソリューションの副作用として, 書かれた署名は不要.

承認プロセス

承認プロセスから成っている 4「レーン」: 創始者, 直属の上司, 機能マネージャーや部門マネージャー.

創始者:

購入の必要性を見ているし、プロセスを開始します。. 創始者が可能性がありますまたは購買依頼を実際には入らない場合があることに注意してください。, しかし、代わりにこれを行う別のスタッフ メンバーを直接. いくつかの回, 創始者は PO 要求書に記入する技術的専門知識を持たない. たとえば, ユーザーが新しいノート パソコンを注文することができます。, しかし、最高のベンダーを知っていません。, IT の基準, など. このケースでは, それと発信者の作品は実際に要求書にいっぱい.

直属の上司:

これは、発信者の直属の上司です。 (MOSS に PO 要求に実際に入った人から異なるであるかもしれない). 直営は、システムはさらにラインの下の承認を求めている前に PO 注文要求の承認が必要.

機能マネージャー:

機能マネージャーは、個々 の購入の提案が特定企業の機能の範囲内での企業の標準に従っていることを保証する責任. たとえば, IT 購入が IT 機能マネージャーによって承認され.

本部長:

部長は、金額によって厳密に購買依頼を承認します。. 部長承認設定可能金額を超える購買依頼.

ソリューション

ソリューションの実装に以下のツールとコンポーネントを用いてください。:

MOSS: オフ他のすべて「ハング」プラットフォームとして提供しています. モスがセキュリティの基盤サービスを提供します, マスター データ, 監査証跡やその他の機能.

InfoPath フォーム サービス: MOSS コンポーネント, これにより、ユーザーが web ブラウザー経由での購買依頼を入力するには.

SharePoint デザイナー (SPD): 自動化されたワークフロー プロセスを実装する SPD を用いてください。.

Web サービス: C# web サービス InfoPath フォームにカスケード選択リストを有効にしてユーザー エクスペリエンスを拡張し、パフォーマンス データのフィルター処理について. 参照してください。 ここで この主題とそれを使用するための理由技術的な深いダイビングのため.

カスタム リスト: 特定のユーザーの直属の上司を提供されている MOSS ユーザー プロファイル, ワークフローの決定を制御するデータのほとんどを提供していないが、 (例えば. PO の注文要求を承認する部門のマネージャーが必要かどうか). 我々 は"エンタープライズ データのカスタム リストを使用" サイト「部門マネージャー承認金額」などのデータを保持するには, 「機能エリア ・ マネージャー" など、. リストは、InfoPath と非常にうまく統合し、作成/更新/削除 (CRUD) 監査と箱から出してセキュリティ機能.

ユース ケース

この使用例は、ソリューションがどのように一緒を示しています:

1. Paul は、新しいラップトップを望んでいます。. 彼はヴィヴェックに彼のニーズについて説明します, 会社のラップトップを基準に精通している IT 担当者, プリファードベンダー, など.
2. MOSS にヴィヴェック ログ, PO 注文フォームにアクセスし、Paul に代わって催告に入る. フォームを求める会社により承認されたベンダーのドロップ ダウン リストを作成する web サービスを使用して購入カテゴリ ヴィヴェック. ヴィヴェックもこの購入の企業機能領域を指定します (例えば. "これは" 「金融」または).
3. 基づく SPD ワークフローが開始されます。, Paul の直属の上司を決定し、彼のマネージャーに要求をルーティング, ステイシー.
4. ステイシーは、購買依頼を承認します。.
5. SPD ワークフロー要求を検査し、それは、それを購入を決定します. ワークフローを IT 機能マネージャーにルーティングします。, Wonson.
6. Wonson は、注文要求を承認します。.
7. SPD ワークフロー再度注文要求を検査し、購入金額 maxium ドルの額を超えるし、承認の部長にルートを決定します.
8. 部門マネージャー、購買依頼を承認します。.

メモ

• ユース ケースを示します"きれい" 拒絶やジャンプなしに実行します。.
• すべての承認者が承認または注文要求を拒否すると同様に書かれたコメントを提供する能力を持っています。. これらが監査証跡に記録されます。.
• 担当課長、任意の時点で購買依頼が拒否された場合, PO 要求は"死んでいます。" 最初からプロセスを開始する必要があります。.
• ワークフローは、プロセスのあらゆる段階で発信者に通知します.
• ない書面による署名 — 決定されるクライアント (説得力があるいくつかの勧告後) 監査トレイル ワークフロー履歴を介して提供されます。, 監査のニーズを提供しています.
• 努力 — このソリューションを実装する約 3 週間をかかった.

結論

このソリューションは、開発およびランタイム ・ プラットフォームとしてコケを活用してください。. ほぼすべての従業員に影響を受けて経常的業務プロセスを自動化する主要なコケ機能を活用することができました. 単純な web サービスを除いて (それ自体が MOSS を活用します。), ほとんどない実際のプログラミング"" 必要でした。.

ソリューションとしても使用"ショーケース" クライアントの, どのように異なる MOSS 機能を示すは完全に主要なビジネス アプリケーションを作成し、将来的に新しいコンサルティングの機会を生成する結合できます。.

用語集

MRO: メンテナンス, 修理および操作. これらの購入は、通常メモ帳などの項目を含める, 椅子, パーソナル コンピューター, プリンター, 携帯電話など.