現状 (現在のプロセス) のドキュメント

Cartographer の [発見] ステージと [現状の定義] ステージ。インタビュー構造のカバー、プロセス マップの確認、現状 (AS-IS) ドキュメントの生成を行います。

[ 発見] 段階と [現行のまま定義 ] 段階では、会話によるインタビューを通じてプロセスの現在のステートを把握します。Cartographer は、何を構築しているかを説明し、的を絞ったフォローアップの質問をし、Design to-be を開始する前にロックされたAS-ISプロセスマップを確認します。

Discovery および Define as is の実行時の処理

インタビューは会話形式で、あなたは自分の言葉でプロセスを説明し、 Cartographer は的を絞ったフォローアップの質問をします。入力する空白のフォームを渡されることはありません。

手順	領域	Cartographerが構築しているもの
1	プロセスの枠組み	プロセス名、目的、トリガー、頻度、量、スコープの境界
2	役割とシステム	関係するすべてのチーム、個人、アプリケーション、および各ステップとの関係
3	手順の手順	トリガーから完了までのプロセスのステップバイステップの説明
4	ビジネス ルールと意思決定	条件、しきい値、承認、例外パス
5	ギャップとあいまいさ	ソース資料で回答できない質問、および後で指定するためのフラグが立てられた延期アイテム

注:

これらの領域を厳密な順序でカバーする必要はありません。Cartographer は、プロセスの自然な説明方法に適応します — ステップの前にルールをカバーすると、自動的に再編成されます。

役立つ回答の仕方

トピック	弱い答え	強い答え
トリガー	「請求書を受け取ったときから始まります。」	「請求書の PDF が AP メールボックスに届きました。システムは営業日の 30 分ごとにチェックします。」
システム	「私たちは SAP を使用しています。」	「私たちは SAP S/4HANA を使用しています。関連するトランザクションは、請求書の転記には MIRO、発注書の検索には ME23N です。」
ルール	「高額の請求書には承認が必要です。」	「50,000 ドルを超える請求書は、転記する前に財務マネージャーと財務担当副社長の二重承認が必要です。」
Exception	「時々エラーがあります。」	「請求書番号がない場合、請求書は手動で調査するために AP 係にルーティングされます。目標解像度は48時間です。」

ヒント:

質問に答えられない場合は、明確に答えてください (例: 「わかりません。ギャップとしてマークしてください」など)。地図製作者は それを記録し、次に進みます。推測すると不正確なドキュメントが生成され、後で修正するのが難しくなります。

[現行として定義] が完了したタイミングを知る

[チェックリスト] パネルの [FACTS (AS-IS)] グループで追跡されたキャプチャされたステップのリストと、提案された現状の現状の図を確認します。マップを確認する前に、間違っている部分を修正してください — 確認されると、マップはロックされ、 アーキテクトプロセス ドキュメントの基礎として使用されます。マップは決してプレースホルダーではありません。これは、実際に確認済みのフローチャートであり、プロセス設計ドキュメント (PDD) に埋め込まれています。

現状 (AS-IS) のキャプチャは、次の 3 つの方法で変更できます。

• Cartographer に直接追加または変更を加えるように指示します。たとえば、「ステップ 2 の名前を『Patient match to Employee Sponsor record』に変更してください。"
• 情報を追加する新しいファイルを入力します。たとえば、「遵守する必要があるビジネス ルールを含む州規制当局のページを添付しました。パラグラフ5.6から5.8を参照してください。」
• 基になるナレッジをサイドバーの ナレッジ セクションから直接編集します。

重要:

「良さそう」は確認ではありません。「プロセス マップを確認します」または「マップが正しいです」と明示的に言ってロックし、[現行のまま定義] を完了します。

現行のままのドキュメントを生成する

Design to-be を続行するために、スタンドアロンの現状 (AS-IS) ドキュメントを生成する必要はありません — 確認済みのマップは自動的に転送されます。次の場合に生成します。

• コンプライアンスまたは監査のためのベースライン ドキュメントが必要な場合。
• 現在のステートでの操作のトレーニング ガイドを作成しています。
• TO-BE (将来の設計) 状態を設計する前に、現状 (現在のプロセス) 状態に対する利害関係者の承認が必要です。
• 将来の状態を設計する準備はまだできていません。

PDD は既定の形式で、通常は 30 ページから 50 ページです。他の2つの形式も利用可能です:標準業務手順書(SOP、15〜25ページ)と変革概要(3〜5ページ、エグゼクティブ向け)。完全にカスタマイズされた組織固有のテンプレートがロードマップにあります — PDD の生成のカスタム テンプレートの回避策を参照してください。

現状 (AS-IS) のすべてのドキュメントには以下が含まれます。

• プロセスの概要 — プロセスの機能とその重要性
• 確認済みのプロセス マップ — プレースホルダーではない、実際の埋め込みフローチャート
• ステップバイステップのチュートリアル — 各ステップの詳細な説明
• ビジネス ルール — 条件、しきい値、承認要件
• 役割とシステム — 誰が何をし、どのツールが使用されるか
• 問題点 — 面接で特定された現在の課題とボトルネック
• 既知のギャップ — 解決のために延期される質問
• 出典の帰属 — 各事実の取得元となるドキュメント

ヒント:

ベンチマークの追加 (任意): プロセス アトラス (厳選された組み込みのプロセス ナレッジ ベース) には、ほとんどのプロセスの文書化されたベンチマークが含まれています。エージェントにプロンプトを送信します。「現状 (現在のプロセス) のドキュメントで、このプロセスに関連するプロセス ナレッジからプロセスのベンチマークを検索し、含めてください。各ベンチマークにソースを注釈を付けてください (利用可能な場合)」と指示します。

次のステップ

他のチームメンバーからの入力が必要な場合は、 タスクの委任 に進むか、 TO-BE設計とPDD生成に直接進みます。