例示ユースケース。

これらは独自のソリューション構想であり、顧客事例ではありません。各ユースケースでは、課題、提案するワークフロー、人が判断を担う箇所、測定すべき指標を示します。プラットフォーム、業務部門、必要な支援の種類で絞り込めます。

請求書例外ワークベンチ
発注や検収と一致しない請求書について不一致を説明し、担当者に回付します。すべての計上は財務部門が承認します。
OracleSAP実装自動化
文字起こし
1. 発注や入庫と一致しないサプライヤーの請求書がキューで待っています。誰かが三つのシステムを開いて理由を突き止め、メールで承認を求めます。
2. ワークベンチは請求書の情報を抽出して検証し、発注と入庫のデータと比較し、不一致を説明して、例外を担当者に回します。
3. すべての計上と支払いは財務が承認します。不確かな抽出結果は手作業による確認に回ります。ワークベンチは提案するだけで、計上はしません。
4. 測定するのは例外の滞留期間、抽出エラー、手戻りです。例示ユースケースです。貴社のケースについてご相談ください。
シナリオを見る (1:18)
注文例外の調整
CRMと受注処理の情報から、停滞した注文の共有ビューを作ります。欠けている手順を特定し、権限を持つ担当者が承認するタスクを提案します。
SalesforceSAPOracle実装自動化
文字起こし
1. ある注文がCRMでは出荷済み、ERPでは保留と表示されています。顧客から電話が入り、三つのチームが同じ事実をメールで追いかけ始めます。
2. ワークフローは営業と納品の状況を集め、欠けているステップとその責任者を特定し、調整のためのタスクを提案します。
3. 権限を持つ責任者が注文変更と顧客への約束を承認します。結果は両方のシステムに記録されます。
4. 測定するのは解決時間と例外あたりの手作業の回数です。例示ユースケースです。貴社のケースについてご相談ください。
シナリオを見る (1:14)
決算と照合の支援
照合の根拠を集め、差異を抽出して説明の下書きを作り、例外は会計担当者に回付し、会計担当者が確認と計上を行います。
OracleSAP実装自動化
文字起こし
1. 決算では、補助元帳と総勘定元帳の差異が遅れて見つかり、スプレッドシートで説明され、本来レビューを担うべき会計担当者が追いかけることになります。
2. アシスタントはエビデンスを集め、差異を検出し、説明を下書きし、異常な項目を会計担当者に回します。結論と提案する仕訳はレビューに回されます。
3. 会計担当者がすべての結論をレビューし、すべての計上を承認します。説明はレビュー担当者が承認するまで下書きのままです。
4. 測定するのは未解決の例外とレビュー工数です。例示ユースケースです。貴社のケースについてご相談ください。
サービスケース解決の支援
サービス案件を分類し、承認済みの知識と許可された顧客情報から回答の下書きを作成します。機微な案件や根拠が不十分な案件は人による確認に回します。
SalesforceOracle実装自動化
文字起こし
1. 顧客から問い合わせが届きます。担当者は注文システム、ナレッジベース、過去のケースを探してから回答し、その間顧客は待っています。
2. アシスタントは依頼を分類し、承認済みのナレッジと閲覧が許可された顧客情報を取得して、次のアクションと出典付きの返信を提案します。
3. 機微なケースは人がレビューし、顧客への約束は人が承認します。裏付けのない提案は回答にならず、人に回されます。
4. 測定するのは処理時間、根拠のある回答の品質、再オープン率です。例示ユースケースです。貴社のケースについてご相談ください。
営業の引き継ぎと商談準備
承認済みの顧客情報、不足の指摘、引き継ぎメモの下書きが営業担当者に届き、見込み客に届く前に営業担当者がすべてを確認します。
SalesforceOracle実装自動化
文字起こし
1. リードが見込み客として認定されても、アカウントチームへの引き継ぎは転送メール一通です。最初の電話で、見込み客がすでに答えた質問が繰り返されます。
2. アシスタントは承認済みの顧客情報を集め、不足や古い情報を指摘し、営業担当者がレビューできるよう引き継ぎとフォローアップタスクを下書きします。
3. 営業担当者は、見込み客に情報を送る前に要約をレビューします。タスクの作成と引き継ぎの記録は、そのレビューの後にのみ行われます。
4. 測定するのは準備時間と引き継ぎの完全性です。例示ユースケースです。貴社のケースについてご相談ください。
サプライヤーオンボーディング支援
サプライヤーの書類をチェックリストと照合し、不足する証憑を指摘し、承認を回付します。登録の判断は権限を持つ担当者が行います。
SAPOracle実装自動化アドバイス
文字起こし
1. サプライヤーのオンボーディングには、購買、財務、コンプライアンスにまたがる文書、フォーム、確認が伴います。各ステップは前のステップを待ちます。
2. ワークフローはサプライヤーの文書をチェックリストに照らして確認し、不足や不整合のあるエビデンスを指摘し、承認用の要約を準備して、承認を追跡します。
3. 権限を持つ担当者がオンボーディングを承認し、ベンダーレコードを作成します。銀行口座情報の変更には人による別途の確認が必要です。
4. 測定するのは完全性とオンボーディングのサイクルタイムです。例示ユースケースです。貴社のケースについてご相談ください。
社内ナレッジ支援
従業員は、承認済みのポリシーと手順の内容から、出典付きで権限に沿った回答を得ます。承認済みの情報では回答の根拠が得られない質問は、推測で答えずに人に引き継ぎます。
プラットフォーム不問実装サポート
文字起こし
1. 方針、手順、製品知識が多くの場所に散在しています。人は同僚に尋ねて古い答えを得るか、あきらめて推測します。
2. アシスタントはアクセス権限を確認し、承認済みソースから出典を添えて回答し、ソースで裏付けられない場合はエスカレーションを案内します。
3. 責任者は何をインデックス化するかを承認し、アクセス制御の失敗をレビューし、回答できなかった質問を確認します。ナレッジの更新はサービスの一部です。
4. 測定するのは回答の裏付け、エスカレーション、アクセス制御の失敗です。例示ユースケースです。貴社のケースについてご相談ください。
リリース影響評価と回帰テスト計画
リリースの変更を影響を受ける構成、連携、テストに対応付けます。デリバリー責任者が範囲を決め、本番稼働の可否を判断します。
プラットフォーム不問サポートアドバイス
文字起こし
1. リリースノートは届いても、チームは何をテストすべきか推測したままです。見落とされた変更は本番稼働後にインシデントになります。
2. プランナーはリリースの変更を影響するアプリケーションとテストに対応付け、カバレッジの不足を明示し、何をテストしどう展開するかを提案します。
3. 何をテストし何を後回しにするかはデリバリーリードが決めます。計画はレビューされ、テスト結果が本番稼働の可否を左右します。
4. 測定するのはテストカバレッジと流出欠陥です。例示ユースケースです。貴社のケースについてご相談ください。
AMSインシデントのトリアージ
受け付けたチケットを分類し、安全な診断情報を集め、類似インシデントを検索し、エンジニアが対応する前にランブックを提案します。
プラットフォーム不問サポート自動化
文字起こし
1. チケットは説明不足のまま届き、誤ったキューに入り、たらい回しになります。経験豊富な人が、先月誰かが解決した問題の再診断に一日を費やします。
2. トリアージはチケットを分類し、チームが安全と合意した診断情報を収集し、類似インシデントを検索して、ランブックと適切なグループを提案します。
3. エンジニアは情報が付加されたチケットを受け取り、修正を判断します。トリアージは準備のみを行い、本番環境には一切手を加えません。
4. 測定するのはルーティング精度、解決時間、再発率です。例示ユースケースです。貴社のケースについてご相談ください。
再発インシデントから改善バックログへ
繰り返すインシデントを推定原因ごとにまとめ、チケットのコストと比べて修正規模を見積もり、オーナーが改善バックログで修正の優先順位を決められるようにします。
SalesforceOracleSAPサポート自動化
文字起こし
1. 同じインシデントが毎月戻ってきます。それぞれ個別に解決され、誰もそのパターンに責任を持たず、サポート予算は同じ問題に再び支払われます。
2. 解決済みインシデントを可能性の高い原因ごとに分類します。各グループの修正に必要な作業を見積もり、再発によって生じるチケット数と対応工数に照らして比較します。
3. オーナーが改善バックログに入れる修正を承認します。変更はリリースの確認を経て、インシデントデータが問題の再発の有無を示します。
4. 測定するのは再発率と再発インシデントに費やすサポート工数です。例示ユースケースです。貴社のケースについてご相談ください。
シナリオを見る (1:08)
AMS移行とアプリケーション資産のベースライン
当社が構築していないアプリケーションの引き継ぎです。資産を棚卸しし、範囲と重大度を合意し、知識を移転し、運用を始める前にサービスの基準を定めます。
SalesforceOracleSAPサポートアドバイス
文字起こし
1. アプリケーションは動いていますが、それを理解していた人はもういません。文書は部分的で、カスタマイズは記録されておらず、どの連携が重要か誰も言えません。
2. 当社はアプリケーションを棚卸しし、サポートの範囲と時間を合意し、手順と不足を文書化してから、サービス開始時のベースラインを定めます。
3. 把握の段階では本番環境に何も変更を加えません。オーナーがサービス開始前に定義を承認し、発見事項はオーナーが優先順位を付ける改善バックログに反映されます。
4. 測定するのは資産のカバー率と未知のコンポーネントに起因するインシデントです。例示ユースケースです。貴社のケースについてご相談ください。
エージェント運用の監視
稼働中のエージェントについて、失敗した処理、品質の低下、古くなった知識、異常なコストを監視し、バージョン管理された修正案をロールバック可能な形で提案します。
プラットフォーム不問サポート自動化
文字起こし
1. エージェントが稼働しています。やがて回答がずれ始めます。コストは上がり、失敗はログに埋もれ、最後に正常だったのがいつか誰にも分かりません。
2. 監視は運用上のエビデンスを定期的に集め、合意したベースラインに照らして発生しつつある問題を示し、修正を提案します。
3. 各変更は評価に合格した後、人が承認します。変更はバージョン管理され、前のバージョンに戻す手段があります。
4. 測定するのは失敗率、評価合格率、完了タスクあたりのコストです。例示ユースケースです。貴社のケースについてご相談ください。