As-is

frame|right| As-is To-be イメージ As-is とは、現状のこと. 特に課題発見のための調査結果を指すケースが多い. To-be と対比して使用される.

概要
As-is とは、「今ある姿/状況」を指す言葉であり、改善の対象になる状態のことである. 現状を指す に対して、「あるべき姿」を指すのは、 である. As-isとTo-beのギャップを埋める作業が、「改善」である. 改善活動では、As-isとTo-beを明確にすることで、さまざまな問題を顕在化させる. ビジネスアーキテクチャや業務プロセスの改善活動においては、現在の構造やプロセスを「As-isモデル」、理想的な構造やプロセスを「To-beモデル」としてモデル化し、両者のギャップを埋めていく.
 * As-is
 * To-be

BPMでのAs-isの利用
BPMではPDCAサイクルを導入すると、各ステップにおいて、「現在の業務の進め方」としてのAs-isモデル、「理想的な業務の進め方」としてのTo-beモデルが利用されることになる.

この一連のサイクルを繰り返し実施する.
 * 1) 現行の業務の進め方をAs-isモデルとしてモデル化する. As-isとして出来上がったプロセスモデルはプロセス改善の対象となる.
 * 2) As-isモデルのビジネスプロセスに修正を加え、To-beモデルのビジネスプロセスを構築する.
 * 3) その時点でのTo-beモデルを実施する.
 * 4) モニタリングの結果から、To-beモデルの問題点を抽出する. 実行されたTo-beは、次の段階のAs-isモデルになる.

As-isモデル、To-beモデルとしてのビジネスプロセス図の作成に関しては、 などが考量される. フェアプロセスの実施という観点からも、誰にでも分かるように「図」として業務の進め方を記述することの重要性は高い.
 * どのようなタスクからプロセスが構成されるのか
 * どのようにタスクがつながっているのか
 * 誰がどのタスクを担当するのか
 * それぞれのタスクでは、どのような情報が入出力されるのか
 * 情報に誰がどの時点でアクセスできるか

フローモデルレベルのAs-isモデル
ワークフローモデルのレベルでAs-isモデルを作成し、問題を発見する. フローモデルレベルのAs-isからTo-beへの変更が多い場合に、プロセス担当者（「パーティシパント」と言う）全員が現状フローを把握し続ける事が困難になる. そのような場合には「ワークフローエンジン」による支援が望まれる.

同時並列処理
タスクを「C1→C2→C3」の順に実施する. タスク「C1」終了後、タスク「C2」とタスク「C3」を同時並行に開始することで全体所要時間を短縮させる.
 * As-is
 * To-be

タスク追加
タスク「C2」終了後、そのままプロセスが終了. プロセスの最後（もしくは途中）に「レビュータスク」や「評価タスク」を追加する事で、プロセス成果物の品質向上を図る. （ループ化させる事も想定される）
 * As-is
 * To-be

条件分岐処理
「処理する案件」(「プロセスインスタンスと言う」)の内容に関らず、処理経路は一定. 「処理する案件」の内容によって処理経路を変える事で、業務負荷を削減させたり、あるいは滞留リスクを低減させたりする. より適した処理経路の選択を実現する場合にも使われる.
 * As-is
 * To-be

タスク削除
例えば、プロセス内に「押印タスク」、「確認タスク」などが複数存在する. 「あまり内容を閲覧しない押印タスク、確認タスク」など、プロセス中にある滞留リスクの高いタスクを削除する事で、業務負荷を削減させたり、あるいは滞留リスクを低減させたりする.
 * As-is
 * To-be

データモデルレベルのAs-isモデル
プロセス中の各タスクを実行する時にインプットされる各データと、各タスク実行の成果としての各アウトプットデータは、プロセス全体を通じて設計される（「プロセスデータ」と呼ばれる）. データフォーマット（データモデル）レベルでのAs-isからTo-beへの移行は、データ集計時に、フォーマット間の差分を埋めるためのコストが生じる可能性がある.

データ追加
右図「契約報告プロセス」を想定した場合、プロセスを通じてアウトプットされる基本データのAs-isモデルは、以下の様なものが想定される. 例えば「L1:草稿確認」タスクにおいては、上流タスク「S1:草稿作成」で入力された情報がすべて表示され、そのインプットデータ(太字表記)をもとにアウトプットデータとしての「契約書草稿承認チェック」が入力される.
 * As-is

データ追加例として「契約金額」を追加する事で、「L1:草稿確認」以下のタスクで、契約書の重要度把握が素早く出来る様になる. 加えて契約金額の容易な集計や、契約金額による経路分岐追加(フローモデルレベルでのプロセス改善)が出来る様になる.
 * To-be

データ可視性変更
上述「契約報告プロセス」の「A1:請求書発行」タスクで、販売先担当者に関する個人情報が閲覧できる意味はさほどない. この例にはないが、販売部門でのみ共有されればよい情報が管理されている場合もある. 「可視性」を下げる事で、情報漏えいリスクを低減させる事が出来る.
 * To-be

複数人対応
特定の一人が対応している、あるいは上司等により特定の一人が指名されて対応している業務. グループ(複数人)で協調的に対応させる事で、停滞リスクを低減できる. （立候補制）
 * As-is
 * To-be

能力経験による自動割当
担当者の能力(翻訳可能言語や資格など)や経験(年数やパターン)に関係なくタスクが割り当てられている. 担当者の能力(翻訳可能言語や資格など)や経験(年数やパターン)を管理し、その能力経験を参照し自動的に割り当てる. 例えば「問い合わせ回答」のタスクで、10年前の製品に関する問い合わせは、キャリア10年以上の担当者に担当させる. もって停滞を防ぐ事が出来る.
 * As-is
 * To-be

組織数の増減
例えば各10人10グループから組織が構成されている. 各20人5グループに再編するなどグループ数を減らす事で、各タスクで対応できる要員が増え、プロセス停滞を防ぐ事が出来る.
 * As-is
 * To-be

関連記事

 * To-be
 * プロセス改善