ホーム > イベントセミナー, プロセスモデリング, BPM, BPMN, SOA, 方法論 > IT Initiative Day 2012の講演結果

IT Initiative Day 2012の講演結果

去る4月20日(金)、翔泳社主催のイベント、IT Initiative Day 2012「クラウド時代のビジネス・プロセス変革」で「ビジネス・プロセス改革を見据えたBPM/SOA技術の適用方法」というテーマで講演しました。その講演スライドを公開します。

約120名のITリーダーの来場者があったそうです。BPMの考え方、全体像がよく分かった!との感想を頂きました。

 

2012年4月20日 翔泳社主催 “IT Initiative Day” 講演スライド
広告
  1. 2012年4月25日20:17

    ご無沙汰しております。
    講演のスライド、興味深く拝見させていただきました。
    (出席したかったのですが、立て込んでおり欠席となりました。
    とても残念に思っていましたが、ここで参照することができ、
    大変うれしく思っています)

    内容については、非常に素晴らしく、おおむね同意できるものですが、
    以下、少々、小職の経験からコメント差し上げたく思いました。

    □ビジネス・プロセス・モデリング
     「ひとつのモデルでいろいろな切り口で活用」…とありますが、
     実際の業務プロセス・モデリングにおいて、汎用的な用途で
     モデリングすることが多いのか、疑問に思いました。
     
     小職のこれまでの経験では、汎用的なモデリングは工数を要する
     ため、プロジェクトの目的に合わせて記述する内容を制限して
     モデリングを実施しています。汎用的な方向性を目指すと、
     アイコンをすべて使ったEPCのように、可読性が落ちるリスクも
     発生してしまうと思います。

    □BPMS:ユーザ主導のアジャイル型開発
     開発期間が1週間以内は短すぎるように思いました。
     メールで添付していたExcelの回覧を、BPMSでシステム化するような、
     従来のグループウエア的な使い方をするのであれば、それも可能だと
     思います。しかしながら、業務プロセスの改善を実現するのであれば、
     現状業務(AsIs)から新業務(ToBe)の間に、定型/非定型の改善手法を
     注入することになるので、画面レイアウトや遷移、データモデル、
     トランザクション、…といった従来のITシステム開発の検討/実装も、
     (従来よりは少ないとはいえ)発生し、1週間では収まらないように
     思います。
     
     小職のこれまでの経験ですと、規模にもよりますが、純粋な開発期間は
     最短でも2週間でした(単体テスト含む。それ以上の長さの設計期間、
     テスト期間が前後に付随します)。

    以上、細かい内容となりましたが、講演の内容のように有益な情報が、
    中立的な団体により広く発信されることは、素晴らしいことだと思います。
    これからも日本BPM協会の活動に強く期待しています!

    • 2012年5月9日15:44

      悲喜子さん、多忙につき返事が遅れ申し訳ありません。
      ご指摘ありがとうございます。

      > ビジネス・プロセス・モデリングについて
      ご指摘のように表記図形の活用選択基準を”記述”、”分析”、”実行可能”の3つのステップ毎にプロジェクトで事前設定する必要があります。この基準なしにチーム・モデリングを行うと収拾がつかなくなります。BPMNは、あくまでも表記標準を提供しているだけですから、それを活用するモデリング標準(方法論)は、プロジェクトで別途定める必要があります。

      >BPMS:ユーザ主導のアジャイル型開発の図
      >開発期間が1週間以内は短すぎるように思いました。
      「1プロセスフローあたり、1週間以内のスピード感でプロセスを開発」の私の表現が間違っていました。「1プロセスフローあたり、1週間以内のスピード感でプロセスを実装」が本来の意図です。
      推進フレームワークでは、実装前のプロセス再設計フェーズ(ユーザーと合意できるプロセスを設計する)は、業務プロセスの成熟度、ユーザーの参加・協力度合い、意志決定スピードなど、不確定要素が多く、1プロセスフローあたり、1週間以内では収まりません。また、プロセス設計の単位時間は、プロジェクトが置かれている諸条件は不確定です。したがって、プロセス設計仕様確定後の実装フェーズで「設計プロセスを実装する時間」と読み替えてください。 実装フェーズでは、不確定要素がなくなりますから、おおよその単位時間は、定められると考えています。私の経験から、1プロセスフロー(8のヒューマンタスク、サービスタスクを除く)あたり、1週間以内でが実装可能と考えています。BPMNは、プロセスに定義されたタスクの種類と数で、実装にかかる概算コストが算出可能と考えらています。従来のファンションポイント法に代わって、BPMではタスクポイント法(タスクの種類と数がベース)が、プロセス設計後の「実装と配備」コストおよび期間を決める手立てになるだろうと考えています。なお、タスクポイント法は、私が作った新語ですか。。。

  2. 2012年5月12日02:33

    返信ありがとうございます。
    大変、参考になりました。モデリング標準は、正直に申し上げて失敗してきた経験もあるので、
    今後も向上を目指して頑張っていきたいと思います。

    タスクポイント法についてですが、
    弊社の開発方法論についている見積ツールも、主要な部分はタスクポイント法で見積るようになっていました。公的機関が投資して基準値を定めてくれるような動きがもしあったら、素晴らしいですね。弊社の基準値は、、、大変に素晴らしいものなので!

    最近は、非常にすばらしいお客様に恵まれ、これまでの取り組みを「これぞBPM!!」と呼べるような日本国内での公開事例にまとめるべく、努力しています。そう遠くないうちに、お見せできるかもしれません。その節は、またご連絡させていただきます。

  1. 2012年7月30日20:00

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中