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

目次 1 概要 2 BPMでのAs-isの利用 3 プロセス改善におけるAs-isモデル 3.1 フローモデルレベルのAs-isモデル 3.1.1 同時並列処理 3.1.2 タスク追加 3.1.3 条件分岐処理 3.1.4 タスク削除 3.2 データモデルレベルのAs-isモデル 3.2.1 データ追加 3.2.2 データ可視性変更 3.3 リソースモデルレベルのAs-isモデル 3.3.1 複数人対応 3.3.2 能力経験による自動割当 3.3.3 組織数の増減 4 関連記事

概要

As-is とは、「今ある姿/状況」を指す言葉であり、改善の対象になる状態のことである。 現状を指す

• As-is

に対して、「あるべき姿」を指すのは、

• To-be

である。As-isとTo-beのギャップを埋める作業が、「改善」である。改善活動では、As-isとTo-beを明確にすることで、さまざまな問題を顕在化させる。ビジネスアーキテクチャや業務プロセスの改善活動においては、現在の構造やプロセスを「As-isモデル」、理想的な構造やプロセスを「To-beモデル」としてモデル化し、両者のギャップを埋めていく。

BPMでのAs-isの利用

PDCAサイクルとは
PDCAサイクルとは、個人や組織のあらゆる活動を 「Plan：計画」 「Do:実行」 「Check:評価」 「Act:改善」 の順に実施し、その4活動全体を繰り返し反復させる手法や考え方を指す。 今日様々な管理活動において導入され、ビジネスプロセスの管理活動においても、中心的な考え方となっている。

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

同時並列処理

• As-is

タスクを「C1→C2→C3」の順に実施する。

• To-be

タスク「C1」終了後、タスク「C2」とタスク「C3」を同時並行に開始することで全体所要時間を短縮させる。

タスク追加

• As-is

タスク「C2」終了後、そのままプロセスが終了。

• To-be

プロセスの最後（もしくは途中）に「レビュータスク」や「評価タスク」を追加する事で、プロセス成果物の品質向上を図る。（ループ化させる事も想定される）

条件分岐処理

• As-is

「処理する案件」(「プロセスインスタンスと言う」)の内容に関らず、処理経路は一定。

• To-be

「処理する案件」の内容によって処理経路を変える事で、業務負荷を削減させたり、あるいは滞留リスクを低減させたりする。より適した処理経路の選択を実現する場合にも使われる。

タスク削除

• As-is

例えば、プロセス内に「押印タスク」、「確認タスク」などが複数存在する。

• To-be

「あまり内容を閲覧しない押印タスク、確認タスク」など、プロセス中にある滞留リスクの高いタスクを削除する事で、業務負荷を削減させたり、あるいは滞留リスクを低減させたりする。

データモデルレベルのAs-isモデル

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

データ追加

• As-is

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

データ名	データ型	データ条件	S1	L1	S2	L2	A1
販売先法人名	文字	必須	入力	表示	表示	表示	表示
販売先担当者名	文字	任意	入力	表示	表示	表示	表示
販売先担当者連絡先	電話番号	任意	入力	表示	表示	表示	表示
販売先担当者連絡先	住所	任意	入力	表示	表示	表示	表示
契約書	ファイル	必須	入力	表示	表示	表示	表示
契約書草稿承認	チェック	必須	-	入力	表示	表示	表示
契約完了報告文	文字	任意	-	-	入力	表示	表示

• To-be

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

データ名	データ型	データ条件	S1	L1	S2	L2	A1
販売先法人名	文字	必須	入力	表示	表示	表示	表示
販売先担当者名	文字	任意	入力	表示	表示	表示	表示
販売先担当者連絡先	電話番号	任意	入力	表示	表示	表示	表示
販売先担当者連絡先	住所	任意	入力	表示	表示	表示	表示
契約書	ファイル	必須	入力	表示	表示	表示	表示
契約金額	数字	必須	入力	表示	表示	表示	表示
契約書草稿承認	チェック	必須	-	入力	表示	表示	表示
契約完了報告文	文字	任意	-	-	入力	表示	表示

データ可視性変更

• To-be

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

データ名	データ型	データ条件	S1	L1	S2	L2	A1
販売先法人名	文字	必須	入力	表示	表示	表示	表示
販売先担当者名	文字	任意	入力	表示	表示	表示	非表示
販売先担当者連絡先	電話番号	任意	入力	表示	表示	表示	非表示
販売先担当者連絡先	住所	任意	入力	表示	表示	表示	表示
契約書	ファイル	必須	入力	表示	表示	表示	表示
契約金額	数字	必須	入力	表示	表示	表示	表示
契約書草稿承認	チェック	必須	-	入力	表示	表示	表示
契約完了報告文	文字	任意	-	-	入力	表示	表示

リソースモデルレベルのAs-isモデル

複数人対応

• As-is

特定の一人が対応している、あるいは上司等により特定の一人が指名されて対応している業務。

• To-be

グループ(複数人)で協調的に対応させる事で、停滞リスクを低減できる。（立候補制）

能力経験による自動割当

• As-is

担当者の能力(翻訳可能言語や資格など)や経験(年数やパターン)に関係なくタスクが割り当てられている。

• To-be

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

組織数の増減

• As-is

例えば各10人10グループから組織が構成されている。

• To-be

各20人5グループに再編するなどグループ数を減らす事で、各タスクで対応できる要員が増え、プロセス停滞を防ぐ事が出来る。

関連記事

• To-be
• プロセス改善