サービス申請プロセスを構築

従業員に何を提供するかを定義し、その実現に必要な情報、承認、提供タスク、受領確認を設計します。

サンプルデータで試せます。フィールド、ビュー、ワークフローをチームに合わせて調整してください。

提供するサービスを文書化

例:従業員のノートPCとデスクのセットアップ
判断事項方針の例よくある誤り
成果従業員がノートPCとデスク環境を使える状態発注が承認されただけで、申請を完了にしないでください。
必要な情報業務上の必要性、場所、日付、機器の要件資産のあらゆるフィールドを集めるのではなく、提供の判断に関わる情報を収集します。
承認指定された機器の確認者審査による承認は提供を許可するもので、実物の納品を証明するものではありません。
提供タスクノートPCの準備・ドックの納品各タスクに担当者と完了内容が必要です。
受領確認従業員が両方の提供物を確認未完了や作業不能のタスクがある間は、最終的な受領を確定できません。

必要な判断を中心にプロセスを構築

  1. サービス申請と予期しない問題を区別

    「職務変更に伴うノートPCの支給」は定義されたサービスで、「使用中のノートPCが充電できない」はサポート上の問題です。担当者が共通でも、入力情報、判断、完了条件は異なります。

  2. 成果に責任を持つ人を明確に

    チーム間の不明点を調整できるサービス責任者を割り当てます。各タスクの担当者が自分の作業を行い、サービス責任者は申請全体と約束した成果に責任を持ちます。

  3. 判断が必要な場面に承認を限定

    支出、アクセス権、例外には人による審査が必要な場合がありますが、リスクの低い日常的な提供には不要かもしれません。実質的な統制につながらず、作業を遅らせるだけの形式的な承認は避けてください。

  4. 不足情報を修正して再開できる仕組み

    確認者には、申請を差し戻し、不足情報を説明し、修正版を受け取る手段が必要です。元の判断を消したり、却下を無断のフィールド編集に置き換えたりしないでください。

  5. 提供完了の条件を定義

    必須タスクと各担当者が残す確認資料を列挙します。従業員が何を受領確認するのか分かるようにします。一部の完了によって、関連する未完了作業が隠れないようにしてください。

依頼の種類に合わせて対応を変える

業務システムのアクセス権

システム、希望するロール、業務上の理由、必要に応じた有効期限を収集します。確認者がアクセス権を承認し、権限を持つ管理者が実際のシステムで付与して、申請者向けに結果を記録します。申請アプリのステータス変更だけでは、アカウントは設定されません。

会議室ディスプレイの故障

サービスカタログからの購入ではなく、予期しない問題です。部屋と影響を確認し、担当者を割り当て、診断と待機を記録して、再び使えることを確認します。この対応の流れには、社内ヘルプデスクのサンプルを使ってください。

まず1つのサービスを最後まで運用

  1. 1つのサービスと実務に近いケースから開始

    通常の申請、承認が必要な申請、一部のみ提供済み、差し戻し、提供完了のケースを試します。それぞれ正しい次の対応につながるか、実際のサービス責任者に確認してください。

  2. ダッシュボードを追加する前に停滞原因を確認

    情報不足、担当者不在のタスク、作業を妨げる要因、受領確認の遅れを調べます。件数だけでは次の対応が分からないため、担当者が問題を解消できるビューを作成してください。

  3. 適用範囲を明確にして拡張

    入力情報と提供内容を明確にできたら、次のサービスを追加します。機密性の高い申請、技術的な設定作業、専門的なインシデント対応は、それぞれに適したシステムと権限で管理してください。

サービス申請プロセス設計のよくある質問

サービス申請管理の責任者は誰にすべきですか?

約束した成果を理解し、チーム間の引き継ぎを調整できるサービス責任者を指定します。個別の提供タスクにもそれぞれ担当者が必要です。ダッシュボードの管理担当であることと、サービスに責任を持つことは別です。

ソフトウェアを選ぶ前に運用方針を設計すべきですか?

まず、最低限サービスの成果、必要な情報、必要に応じた承認者、タスク担当者、受領の条件を定義します。そのうえで、アプリがそれらの判断と例外処理を実務で使える形にできるか確認してください。

不備のある申請はどう扱うべきですか?

具体的な質問を添えて差し戻し、履歴を残します。誰が情報を修正し、いつ先に進めるのかを明確にしてください。対応中のキューから外すためだけに却下しないでください。

小規模チームはどの指標から始めるべきですか?

まず、担当者のいない申請、進められないタスク、受領確認待ちの提供はどれか、という判断から始めます。提供時間の指標は、開始、終了、営業カレンダー、待機方針を定義してから追加してください。

サービス提供とヘルプデスクのサンプルは、同期する1つのアプリですか?

いいえ。定義済みサービスの提供と、従業員の予期しない問題に対応する別々のサンプルです。相互の引き継ぎが必要なら、自動同期を前提とせず、関連付けと担当範囲を設計してください。

文書にした1つのサービス方針を、動くプロセスへ

サンプルの申請と提供タスクで自社の引き継ぎを試してから、ほかのサービスに広げてください。

サービス申請アプリを見る