第3回BPMオフ会 ユーザ目線の実践的BPM

1. 第 3 回 BPM オフ会 2008 年 4 月 12 日 Wadit Inc. 和田正則 ユーザ目線の実践的 BPM ～ エロ親父でもできる業務システム構築 ～

2. Wadit のことを少し ■ 2006 年 9 月創業の親子だけの会社です！ 社長は、 Erogeek こと Yusukebe ■ 2 つの主要商品 ・ BPM メソドロジー（ Kailas) ・ Web ・サービス（ MushUp) 提供 ・・・思ったより儲かりませんよ！ ・ ListPod ( NEW! ) - YouTube 動画のマイリストを作って Podcast で見よう！好評 ・ YouTubeMP4 ( NEW! ) ・札コラメーカー - 「遊べる○○ ( なんとか ) メーカー 100 選」（幻冬舎コミックス）に掲載 ・これ☆ほしい - みんなの物欲 ・くえ☆すた - はて☆すたで質問に答えよう ・ RimoChanMaker - Rimo ちゃんメーカー ・ CarTube - カーセンサー＋ YouTube ネトラン掲載 ・ ZonTube - Amazone ＋ YouTube ネトラン掲載 ・ CDTube - CDTV+YouTube ネトランの「ベスト・オブ・超凄サービス」の大賞受賞 ・ YourAVHost （ 18 禁） - ネトラン掲載 ・ ERO Pla(18 禁 ) - ネトラン掲載 他 親子の会話から生まれた

3. そして自分のことを少し 元々は、ケミカルエンジニア（プラントオペレーション、プロセス設計・管理） 次に、 FA （ Factory Automation) 、技術企画、事業企画、ライセンシングなど その後、工場システム部門で生産管理、設備管理、プラント情報管理システム等の開発プロジェクト 最後は、本社情報システム部と情報子会社でアウトソーシング、分社化、グループ経営情報システム、子会社の情報化、 SAP 導入基本計画などを主導 ただし、システム設計もしたことがない、コードを書いたことがない！ 2002 年頃から、「企業情報システムの構造化」を推進 自前で、 EA 、 SOA 、 BPM 、 ASP を始める（当時はこうした言葉もなかった） これが当時の考え方 ちょっと自慢 私がなぜＢＰＭに興味を持ったのか？ ビジネスプロセスはケミカルプロセスと同じである！ Input( 原料）->単位操作の組み合わせ-> output( 製品） 単位操作＝業務処理（情報処理）

4. なぜ BPM が登場してきたのか？ ユーザは、いまの企業情報システムに満足していない 役に立たないシステムを作り続けているとユーザは思っている BPM に行く前に そこには構造的な問題や開発のやりかたの問題がありそうだ 従来型のやり方を見直す構造改革が必要になってくる その解決策として「 BPM on SOA by SaaS 」がよさそうだ

5. こちらの要求を実現してくれているかわからない、動かしてからこんなはずではなかった 業務を知らないＳＥが来るので仕様がちゃんと伝わらない Ｑｕａｌｉｔｙ 出来上がった品質に関係なくかかった費用を請求される（あいかわらずの人月商売） 結局はプログラミングの力仕事に持っていくので日本の労務費では割高 ERP などのパッケージを入れてもアドオンが多くなって逆に費用高になる 開発期間を長くとっていても、仕様変更や手戻り発生が多く、納期遅れになる ビジネスはしょっちゅう変化するのでもっと変更を容易にできるようにしてくれ Ｃｏｓｔ Ｄｅｌｉｖｅｒｙ Ｆｌｅｘｉｂｉｌｉｔｙ 変わらないユーザの不満 役に立たない正しいシステムを作り続けてきたのでは！

6. 構造的問題とか開発の問題って？ （１）アプリケーション仕様のほとんどが、結局、ユーザの恣意でしか決まらないこと 仕様を決定付ける科学的、工学的なモデルが存在しない （２）情報システムと人間の境界が、元来不安定であること 実業務の様々な例外をコンピュータ上に乗せるか否か （１）企業情報システムの構造上の問題 硬直的で密結合構造のため変化対応力弱い （２）ユーザとベンダーの関係 ベンダー主導のためユーザニーズとのずれ、ベンダーとユーザの利益相反 （３）ユーザ企業の体制や人材の問題 SE 志向でビジネスより技術に向かう （４） IT 業界の構造 多重下請け構造で、専門化、分業化ができてていない ２．開発技術的な問題（ ２つの大きなジレンマ） １．構造的な問題 情報の非対称性による インセンティブのゆがみ

7. 課題解決の方向性 ここにきて、ユーザの不満の解消や多くの問題点の解決ができる可能性が出てきた なぜ、できるようになったのか ■ Ｆｌｅｘｉｂｌｅ＆Ａｄａｐｔｉｖｅな構造、疎結合と可視化 ⇒ システムの構造化 SOA の概念の採用（思想として） ■ プロセスと機能の分離 ⇒ 業務の構造化 コンポーネントベースの業務プロセス設計・開発 BPM と CMS の MashUp ■ 業務のタイプによるプラットフォーム分割 ⇒ アプリケーションプラットフォームの構造化 3 層プラットフォーム ■ 開発者の役割明確化 ⇒ 開発体制の構造化 プロフェッショナル開発体制 新しいアーキテクチャ、テクノロジーの登場、情報リテラシーの向上等 SOA 、 BPMS 、 SaaS 、 Web2.0 など、やっと使えるものになった より進んだ構造化が可能に ユーザ目線の実践的 BPM メソドロジー「 Kailas 」 「 BPM on SOA by SaaS 」が 構造化するための基盤

8. では BPM って何？ ・・・ いくつかのアプローチ 大きくは次のようなアプローチ １． 企業の業務を分類・定義し、 モデル化・体系化を行なう。 ２．企業の業務をフロー図などに 書き出し可視化する。 ３．機能を BPM で組み合わせて 業務プロセスを開発する。 ４． BPM を使って SOA の仕組み を構築する。 もう少し掘り下げてみると そこで作られた業務モデルをテンプレート化し、 ベストプラクティスとして利用する。 フローを書き出したら、さらにその業務フロー を標準化・最適化する。 事業からの変更要求に柔軟かつ迅速に対応 できるようにする。 事業部門というよりシステム部門の役に立つ ことかもしれない。 BPM の最終ゴールはどこなんだ 「事業に役立つ業務プロセスをつくること」 経営者、事業部長の掌にあなたのプロセスを乗せてあげる そう考えると このアプローチが 最も現実的

9. コンテンツ＆ プロセステンプレート ライブラリー プロジェクト体制 アプリケーション 構築技法 アプリケーション プラットフォーム Kailas CMS ー BPM 連携による ノンコーディングシステム構築 少数精鋭ドリームチーム アジャイル的開発 開発したコンテンツとプロセスをライブラリー化し再利用 カード・シート・ブックの使い回し ミクロワークフロー マクロワークフロー エンタープライズＤＢ の三層構造 この体系を 「 Kailas 」と呼びます “ ＤＡＹ” Ｄ ｏ A pplication Y ourself “ SAAP” S tructured A daptive A pplication P latform “ U-Plus” User’s Process Library by UserSelf “ F2F” F ace to F ace Development 本日は、ここの開発技法とプラットフォームのお話です さて、 BPM メソドロジーとは？

10. ノンコーディングでできること ■ ポリシー ユーザ主導（できればユーザ自身で開発できること） とにかくシンプルでわかりやすいこと 業務機能をコンポーネント化する コードを書かないようにフレームワークを活用する ■ コンセプト コンポーネントを BPMS で組み合わせてプロセスを作る 開発技法の考え方 ＊ BPMS ： Business Process Management Suite

11. 業務機能（レベル２） 業務プロセス（レベル１） 業務プロセス（レベル２） 業務機能（レベル１） 業務プロセス 業務サービス アクティビティ アクション 受注～出荷 受注 受注受付 受付メモを作成 リソース DB イベント DB データ プロセス 機能 どうもこのあたりをコンポーネント化するのがよさそうだ 業務機能のコンポーネント化と粒度

12. さてコンポーネントと言うけれど ある ERP パケージの業務機能を BPMN で書き出したものから、アクティビティを分類してみた エロ親父は考えた ところがちょっとおかしいぞ！ ・プロセスの始点、終点が不明確 ・サービス、アクティビティ、アクションが一緒くたにアクティビティとなっている ・異音同義の言葉が多い。しかもあいまい ・プロセス数 70 （内訳 販売管理系： 43 、生産管理系： 14 、会計・決算系： 13 ） ・アクティビティ数 605 従来のパッケージ機能をそのまま BPM にしても意味がない ・・・ 手組みの延長 BPM に落とすなら、コンポーネント化が必須なのだ

13. アクティビティを眺めて整理してみる 同類を括る 粒度が違いすぎる コンポーネントは分類されて、定義されて、整理されなくてはいけない 分類学 定義力 整理術

14. 業務機能コンポーネントのパターン （１）依頼受付型 （コールセンター） プロセスの始点になるもので、外部からの内部からがあります （３）デシジョンサポート型（スケジュール、作業割付、計算、シミュレーション等） 意思決定をする場合に参考にする情報を提供します （２）書類ライフ型（コラボレーション、ミクロワークフロー） 依頼受付 - 書類作成 - 確認 - 連絡 - 承認 - 書類発行 - 依頼といった業務処理機能です （４）シングルアクション型 （ DB 更新、サイト登録、報告等） 次に続くアクションがない場合でプロセスの終点とすることができます （１）外部サービス型（ SaaS ） 外部にあるサービスを利用してその結果を利用します （２）アプリケーションパッケージ型 既にある業務パッケージをブラックボックス化してサービスとして取り合います 業務サービスコンポーネントのパターン 粒度 大 小 業務コンポーネントのパターン 一番多いパターン

15. “ 書類のライフ”というコンポーネント １．書類単位でコンポーネント化 例えば、仕様書、見積依頼書、出荷依頼書、発注書、作業指示書 ２．書類のライフという考え方 ライフとは、作成－編集－確定－承認－発行という“状態遷移”を指します ３．書類のライフは、情報共有作業で達成されます 各書類のライフに関係するメンバーのロールを決め、状態遷移に応じた書き換えと 承認権限の付与を行ないます 作成 編集 確定 発行 非公開、公開ドラフト、保留、公開 メンバー 審査員 管理者 タスクサイト 書類 情報共有 Status 管理 アクセス管理 情報が業務を誘導 承認 CMS （ Contents Management System) がこうした機能を保有している 書類をコンテンツとして管理 書類というオブジェクトを状態遷移させることは仕事そのものである

16. 業務コンポーネントを組み合わせてプロセス化 受付・依頼で取り合う ・書類の作成が終わると、作業完了の情報が BPM に行く（依頼） ・ BPM は決められたルートに従って、次の書類作成を指示（受付） 書類のライフ 作成（作業開始）->編集->確定 ->承認 ->発行（作業完了） 業務コンポーネント 業務プロセス（業務サービス） マクロワークフロー （フロー制御） ミクロワークフロー （ステータス制御） ＊ SAVVION ではこれをアクティビティと呼ぶ BPM 依頼 書類 受付 作成～発行 依頼 書類 受付 作成～発行 依頼 書類 受付 作成～発行 依頼 書類 受付 作成～発行

17. プロセスコントロールということ BPM には段階がある プロセスを作る プロセスを制御する プロセスを監視する プロセスを維持する プロセスを改善する ここを忘れがちになるので気をつけよう 何をコントロールするのか？ 意思決定の質と時間だ！ プロセスを動かす

18. ここで BPMS のことを BPM はここでは道具という捉え方だから、 BPMS （ Business Process Management Suite) が重要。 そこで必要な機能は何なの？ １）必須 ２）代替可能 ３）将来必要となる いきなりＢＰＭＳの機能を全部使ってＢＰＭというのは無理 まずはプロセスを動かして ①実行エンジン ②コンポーネント（サービス）ハブ ③ユーザインタフェース ④プロセスモデラー（シミュレーション機能付き） ⑤モニタリング 必ずしもＢＰＭＳのＵＩを使う必要はない プロセスを把握し、制御できたら、 To Be モデル化や BAM （ Business Activity Monitoring) を使う

19. アプリケーションプラットフォームの基本構造 DB Adapter 外部サービス 他システム Adapter 、 EAI 汎用ＣＭＳ、Ｂｌｏｇ、ＳＮＳ、ＥＣサイト、Ｗｉｋｉ、簡易Ｗｅｂアプリ etc （数値データ、文書、図面、画像、動画 etc ） ＲＤＢＭＳ、ＭＳＯｆｆｉｃｅ、各種ファイル BPM CMS ＳａａＳ、商用ＤＢサービス、ＥＲＰ、レガシーシステム etc MashUp ■ 基本単位 Ajax 活用 ■ Web2.0 のサービス・技術と BPM の融合 Web2.0 のアーキテクチャをビジネスシステムにも適用 （集合知、参加型アーキテクチャ、 Ajax 、 MashUp など） ＳＯＡ

20. ３層アプリケーションプラットフォーム ■ 階層構造 第 1 層 ：コーポレートシステムで、主に決算につながるエンタープライズデータの更新を行う 第 2 層 ：業務プロセスをまわす仕組み、ユーザインターフェースとエンタープライズＤＢとの橋渡しを行う 第 3 層 ：アクティビティやアクションの機能をもった情報共有型のユーザインターフェース State Transition （ミクロワークフロー） Enterprise Data Base （コーポレートシステム） State Transition （ミクロワークフロー） State Transition （ミクロワークフロー） State Transition （ミクロワークフロー） Business Process （マクロワークフロー） Business Process （マクロワークフロー） 書類ライフ 業務プロセス 決算システム 第 1 層 第 2 層 第 3 層

21. なぜ、プラットフォームを分けるのか ～ 業務処理のタイプが違う三層構造 ・・・ 適材適所という考え方 ～ 決算システム マクロワークフロー 業務プロセスフロー ミクロワークフロー 書類の状態遷移 ワークフロー形態 中 システム主体 逐次フロー型 シーケンス的処理 確定後処理 ミドルエンド 安定、定型 BPM 業務フロー、業務サービス 大 小 堅牢性 システム主体 人間主体 処理の担い手 DB 更新型 集計的処理 情報共有型 コラボレーション的処理 仕事のやり方 最終確定処理 バックエンド 定型、大量 確定前処理 フロントエンド 不安定、不定型 対象プロセスと特徴 ERP コーポレートシステム、 エンタープライズ DB CMS アクティビティ、アクション

22. （１） 業務を機能とプロセスに分離し、機能をコンポーネント化したこと （２） その業務コンポーネント を BPMS で組み合わせて業務プロセスを作ったこと （３）業務コンポーネントをミクロワークフロー、業務プロセスをマクロワークフロー とし、プラットフォームを分けたこと （４）ミクロワークフローは書類というコンテンツの状態遷移であるとし、 CMS を適用 したこと （５）マクロワークフローは BPM を使うが、プロセスを構築するための道具と捉え、 BPMS の色合いを濃くみていること （６） BPM と CMS の接続に Web2.0 の技術（ Ajax) を活用したこと ポイントを整理しましょう “ ここには、 BPMN や BPEL 、 XPDL も出てきません”

23. 結局 “ 複雑で難しいことは、 CMS 、 BPM のプロダクトに隠蔽” 難しいものはギークにつくってもらう それを使ってスーツは業務システムを簡単に構築する “ 組織的に対応すべきところは BPM でかたく、 人間で対応すべきところは CMS でゆるく” 何でも硬くすりゃいいってもんじゃない、ゆるいのが悪いわけでもない 人と IT 、ビジネスとＩＴが融合したシステム これが というんじゃないの Geek どもよ！ コードを書かないで済むようにコードを書いてくれ！ フレームワーク、部品、インターフェースをつくるソフトウエア 開発 と ビジネスを表現する業務システム 構築 を 一緒にするな！ 業務システム構築段階ではコードは書かない

24. １． BPM のプロセスが非常にシンプルになり、「 見える化と コントロール 」が可能となります ２．従来システム化が困難だった不定形プロセスを「 情報 共有 」の場でシステム化できます ３．業務システム構築ではコードを書かないので「 高品質、 低コスト、短納期 」が実現します ４．コンポーネントは入れ替えが容易ですのでビジネスに 対する「 変化対応力 」がつきます いままでとどこが違うのか

25. 例えば業務フロー図を比較すると 非常にシンプルでわかりやすくなった 従来の描き方 本技法で描くと 施工会社

26. 適用業務 基本的には、プロセスがある業務であればどこにでも適用可能であるが、まずは、「 顧客あるいは取引先との接点 」業務に適用したらいかがでしょうか。例えば、 ERP のフロントエンドでもある 修理サービス 見積依頼 オーダーエントリー 購買・調達 ITIL （サービスデスク） クレーム処理 その他

27. さて実際にどうやって開発するのか ある工事が発生し、それに対して工事の仕様を確定し、見積を取るまでのプロセスを例にみていきます。

28. 現状ビジネスプロセス書き出し プロセスの適正化 CMS の設定 書類の抽出および書類化 AsIs プロセスモデル 適正化プロセスモデル （きれいなプロセス） BPM の設定 業務コンポーネント 業務コンポーネント候補 業務プロセス（サービス） 主として既存画面・帳票から洗い出し、不足はヒアリング 書類がなくても仮想の書類を設定 ルールに従ってアクティビティやアクションの追加・修正を行なう 業務フローの作成、ルールの設定 プロセスのコントロール 書類をコンテンツとして作成。 参加部署メンバーを特定し、ロールと権限を決める。 開発の大きな流れ @2007 wadit Inc. All Rights Reserved 業務プロセス設計 ミクロワークフロー開発 マクロワークフロー開発 プロセスの差別化 （魅力あるプロセス） トップダウンアプローチ

29. 業務プロセス設計 ＊ここは非常に重要な工程であるが、時間がないので本日は詳しく説明しません。 ポイントは、“ シンプルで一貫化されたプロセス ”にすることです。 そのためには、最終書類から遡って書類を並べていくイメージとなります。 イメージ的には えーい「マジカ」をそのまま実装じゃ！・・・書類一枚がマジカの４コマ漫画

30. 業務プロセスを特定する 「業務プロセス・機能表」を作成する。 （データリスト作成、書類化も） 「業務プロセス概要表（適正化後）」を 作成する 「業務プロセス概要表」を作成する STEP1 STEP3 STEP5 STEP2 プロセスの始点と終点を定義する。「○○から○○までのプロセス」と規定。 Step1 で決めた業務プロセスのなかの業務サービスとアクティビティおよび担当部署を表に書き出す。 業務プロセスを適正化する STEP4 適正化チェックにより、アクティビティの追加、削除、修正が行なわれ新しい業務プロセスができあがる。 Step2 であるがままの姿が抽出され、 Step3 の作業で少し整理した形でプロセスが描き出された。つぎにそのプロセスが適正な形になっているかのチェックをおこなう。 業務プロセス設計概略手順（原則法） 業務プロセス 概要表に従って、プロセス・機能表を作成する。書類化を意識し、受付－依頼の状態遷移を書類とみなし記入する 「確定データリスト」を作成する 「業務フロー図」を作成する STEP6 STEP7 書類ごとで確定していくデータのリストを作成する。データは追記していくと、最終確定データになる。 新しい業務プロセスをフロー図に書き出す。参照データ等の関係も図示しておく。

31. 業務プロセス概要表

32. 業務フロー図 工事依頼受付書 工事仕様書 予算金額 500 万円 以上 見積依頼受付メモ （本社購買） 見積依頼受付メモ （工場購買） 工事予算管理 DB 工事図面ファイル 協力会社リスト 予算 No 、金額 添付図面 見積希望業者 見積依頼業者 見積依頼業者 Email Yes No 見積依頼書（購買向け） 見積依頼書（業者向け） 協力会社

33. ● ：確定データ ○ ：参照データ 確定データリスト １）最終書類に記載されるべきデータ（ 必須データのみ ）を設定 ２）中間書類は、最終書類のデータになるよう 追記していく イメージとなる。 ３）条件分岐の条件データを設定する。 遡る 分岐／格納 DB 見積先 納期 数量 予算 工事名 データ項目 見積サイト登録 ● ○ ○ ○ ○ 見積依頼受付メモ 500 万円以上は本社、以下は工場購買 ● ○ ○ ○ 見積依頼書 ● ○ ○ 仕様書 ● ● 見積依頼受付 文字列 日付 数値 数値 文字列 データ型

34. BPM によるマクロワークフロー開発手順 （ BPMS に SAVVION を使用）

35. プロセス概要表を作成する アクティビティ別のプロパティを設定する プロセス図を描く １） STEP1 STEP3 STEP5 STEP2 プロセス概要表に書類名をアクティビティにしてその処理概要を記入する アクティビティを置いていきメール送信などの管理アダプタ、分岐や合流などのコンポーネントを記入し、始点、終点の記号とラインを挿入する データスロットの設定情報を記入する STEP4 業務上で扱っている項目、帳票、その他情報の名前を各ワークステップに設定する BPM （マクロワークフロー）開発概略手順 各アイコン（ユーザ、アダプタ、条件分岐）のプロパティに詳細情報を設定する 条件分岐部分に条件を指定する アダプタの設定を行なう デプロイ（インストール） STEP6 STEP7 条件分岐部分はデータスロットを参照した論理式を記述する アダプタには、カスタムアダプタと管理アダプタがある。それぞれのパラメータ設定を行なう SAVVION サーバーにデプロイする １） ProcessModeler で描いてエクスポートしてもいいし、直接 BPMStudio に描き出してもかまわない

36. Step1 プロセス概要表を作成する アクティビティ名 処理概要 １ 工事仕様書 工事部門で仕様書を作成、添付書類は図面 DB から取得 現場部門とともに確定し、工事部門長の承認を得る 《参照データ》予算 No 、工事名称、予算金額 ２ 見積依頼書 工事部門で見積依頼書を作成、見積条件、見積希望先、工期等を追記 購買部門とともに確定し、工事部門長の承認を得る 《参照データ》協力会社データ ３ ５００万円より大きいか判定 予算金額が５００万円以上は本社購買から見積 予算金額が５００万円以下は工場購買から見積 ４ 見積依頼受付メモ（本社購買） 本社購買部門が見積依頼を受付、見積依頼先や特記事項等を追記 工事部門とともに確定し、本社購買部門長の承認を得る 電子メールにて依頼業者にサイトにアクセスするように連絡 《参照データ》協力会社リスト ５ 見積依頼受付メモ（工場購買） 工場購買部門が見積依頼を受付、見積依頼先や特記事項等を追記 工事部門とともに確定し、工場購買部門長の承認を得る 電子メールにて依頼業者にサイトにアクセスするように連絡 《参照データ》協力会社リスト ６ メール送信 協力会社へ見積依頼が行く旨をメールにて連絡する ７ 見積サイト登録 見積サイトにて、見積提出のための情報を流す

37. STEP ２ プロセス図を描く

38. STEP ３ アクティビティ別のプロパティを設定する 図番 アクティビティ名 タイプ 名前 ラベル 説明 ① 工事仕様書 ユーザ siyousho 工事仕様書 工事仕様書作成・承認 ② 見積依頼書 ユーザ mitumoriiraisho 見積依頼書 見積依頼書作成・承認 ③ ５００万円判定 条件分岐 デフォルト ５００万円判定 金額で依頼先変わる ④ 見積依頼受付メモ （本社購買） ユーザ Uketuke_hon 見積依頼受付メモ ５００万円以上 ⑤ 見積依頼受付メモ（工場購買） ユーザ Uketuke_kou 見積依頼受付メモ ５００万円以下 ⑥ メール送信 アダプタ Sys_001 メール送信 協力会社へ見積依頼がいく旨 ⑦ 見積サイト登録 アダプタ Sys_002 見積サイト登録 見積サイトに登録

40. STEP ４ データスロットの設定情報を記入する @2007 wadit Inc. All Rights Reserved データ項目 データスロットの名前 データ型 説明＆ラベル 備考 予算 No Budget_no 文字列 予算 No 工事名 Kouji_name 文字列 工事名 予算工事金額 Budget 数値 予算工事金額 仕様書承認結果 Spec_Shounin 文字列 仕様書承認結果 見積依頼書承認結果 Esti_Req_Shounin 文字列 見積依頼書承認結果 見積依頼受付部署１ Honsha_Koubai 文字列 見積依頼受付部署１ 見積依頼受付部署２ Koujou_Koubai 文字列 見積依頼受付部署２ 見積依頼先 Partner 文字列 見積依頼先

42. STEP ５ 条件分岐部分に条件を指定する

43. STEP ６ アダプタの設定を行なう

44. STEP ７ デプロイ（インストール） クリック

45. Portal 画面

46. CMS によるミクロワークフロー開発手順 （ CMS に Plone を使用）

47. サイトマップ設計 ページ（ドキュメント）の作成 グループ・メンバーの設定 基本画面設定 STEP1 STEP3 STEP5 STEP2 ページやフォルダーの階層構造やリンク構造を決める ページに必要となるコンテンツを入力する ここで書類が作成される ファイル等に参照情報を登録 STEP4 ロゴや表示位置など、好きなようなデザインに変更する。 CMS （ミクロワークフロー）開発概略手順 サイトに参加するグループとそのメンバーを決め登録する。またそれぞれのロールも決める。 ファイル等に文章、図面、画像などの情報を登録する。必要に応じてリンクを張ったりする。 ワークフローの設定 STEP6 アイテムに「手続きの流れ」を設定し、ワークフローの状態に応じた権限の設定を行なう。 デザインカスタマイズ STEP7 ポータル画面などの基本的な画面を設定する

48. ＳＴＥＰ１ サイトマップ設計 アイテム（コンテンツ）の種類と機能 ・フォルダー ：ファイルやページなどのコンテンツを整理するための入れ物。階層化が可能。 ・ページ ：一番重要で利用頻度の高いもの。ドキュメントを作成する。エディターを使えば、 （ドキュメント） HTML の知識がなくても、ワープロ感覚で入力できる。 また、関連コンテンツの設定ができ、参照情報などを登録しておきます。 ・イベント ：期日があるお知らせに利用する。例えば会議の設定や催し物など ・ニュースアイテム ：お知らせやニュースを作成する。 ・画像 ： GIF 、 JPEG 、 PNG などの画像データを配置するとき使う。 ・ファイル ： PDF や EXCEL シートなどのファイルをサイトへアップロードする。 ・リンク ：サイトのリンクを作成する。 ・スマートフォルダー ：知りたいキーワードやコンテンツの種類などの情報を指定し、サイト内のアイテムを表 示する。 入れ子に配置することでアイテムの絞込み検索が可能になる。 標準的なアイテムは上記ですが、 Plone では Archetypes といって好きなように新しいアイテムを作成するフレームワークが用意されているので、それを使って新しいアイテムの追加が可能です。

49. サイトマップ例 Ａ工場機械工事 工業用水配管取替え工事 機械室塗装工事 フォルダー ページ （ドキュメント） ファイル スマートフォルダー 仕様書 見積依頼書 見積受付メモ 加熱炉保温工事 リンク 工事種別一覧 業者別工事一覧 BPM 進捗状況表 詳細仕様書、機器図 画像 現場写真 F15 保温工事 ファイル 工事予算表

50. Plone を立ち上げると雛形が表示される（ページの雛形） これは、雛形の文章を変え、かつ日本語にしたもの ＳＴＥＰ２ Plone 基本画面の設定

51. 書類名 このエディターを使い、ここに書類の中味を記載 直接書き込むのではなく、別ファイルにある書類にリンクを張っても可 ＳＴＥＰ３ Plone サイトで書類作成（１） ・・・今回はあらかじめ作成した新アイテムを使う JavaScript で入力フォーム埋め込み

52. Plone サイトで書類作成（２） 書類の作成に必要な参照情報をここに登録（ URL 指定） 外部情報も URL 分かれば可 この書類をベースに議論していく 内外へのリンクも可能

53. ＳＴＥＰ４ ファイル等に参照情報を登録 例えば ファイル ：「 2007 年度工事予算一覧表」、「機器構成図」、「取引業者リスト」など リンク ：「 BPM 進捗状況表」（ BPM でのプロセスの進行を閲覧する） 画像 ：「工事現場写真」、「資材カタログ」など ここからダウンロード

54. ＳＴＥＰ５ グループ・メンバーの設定 設定手順 ① ユーザ登録 ② グループの追加 ③ ロールの割り当て ④ グループにユーザ追加 ⑤ Web ワークフローの設定 グループに対する「ロール」について （１）「メンバー」 ：一般ログインユーザの権限、自身のフォルダーにコンテンツを入力できる （２）「審査員」 ： Web ワークフローの審査員として、チェックの権限を持つ （３）「管理者」 ：メンバーの削除も含めて、全ての操作ができる ユーザ登録 ：氏名、ユーザ名、 E メール、パスワード グループ登録 ：名前、タイトル、説明、 E メール

55. ＳＴＥＰ６ ワークフローの設定 ワークフローの状態 「非公開」 ：作成者だけが閲覧・編集ができる状態 「公開ドラフト」 ：公開前の状態。新規アイテムを追加したときはこの状態。 「公開」 ：誰でもアイテムの閲覧ができる状態。編集の権限は「管理者」のみ。 Plone での手続きの流れ チェック 公開 ページ作製 上司 作成者／担当者 公開操作 却下 提出 制作過程 メンバーのみ閲覧が可能 承認でもよい

56. ＳＴＥＰ７ デザインカスタマイズ Plone のデザインを変更する方法 ① 「 CSS 」 ② 「 base_properties 」 ③ 「ページテンプレート」 を加筆・修正すること ロゴの設定、スロット（ナビゲーション、カレンダー、アクセスなど）の設定、サイトの表示位置の調整、メニュー（ポータルタブ）の変更、パーソナルバーの変更などを必要に応じて行ないます。

57. １．システム構成 BPM CMS CMSConnector ソフトウエア SBM(SAVVION ） Plone ／ JavaScript Perl プログラム アプリケーションサーバー Pramati Zope Apache OS Windows2003Server Windows Linux DB Oracle9i 内蔵 SQLLite ＊ＶＭｗａｒｅ上で作動 ２．サンプルプロセス 「工事見積依頼プロセス」 ３．デモシナリオ １．業務プロセス設計手順に従って、適正化プロセスを作成する。（業務フロー図、データリスト） ２． BPMS を使ったマクロワークフロー作成からデプロイまでの流れを見る。 ３． CMS のサイト作成からフォルダー構成や書類のイメージをつかんでもらい、ミクロワークフローが どんなものかを知る。 ４．実際に書類を起して、ＣＭＳとＢＰＭ間のデータの授受やプロセスがまわることを確認する。 では実際に動かして見ましょう あえて原初的な仕掛けをお見せしています。 これからいろいろ妄想を働かせてください

58. ＣＭＳ （ Plone) ＣＭＳ Connector Ｐｅｒｌ／Ａｐａｃｈｅ ＢＰＭ S （ SAVVION) SOAP SOAP->JSONP 変換 Work Item Name を取得 ステータスを表示 Get,Post でパラメータを渡す 投稿されたら プロセス動かす WSDL で定義された SOAP のメソッドをたたく BPM パネル ＣＭＳに埋め込まれたＪａｖａＳｃｒｉｐｔがリクエストを発行 CMS － BPMS 連携の仕組み API JSONP プロダクト JavaScript でやりとり とりあえずの仕組み いろいろな選択肢がある Ajax

59. 基本的にＢＰＭＳとＣＭＳのフレームワーク上の設定だけでアプリケーションができることを実感できましたでしょうか。 プロセスが浮かんだら、すぐに実装のイメージが湧いてくるはずです。 フローが描けたらあとは楽です。 ということは、 いかに“きれいなプロセス”、“魅力的なプロセス”を描くことができるか、そしてそのプロセスをコントロールできるかがこれからのキーポイントです。 これが BPM の本質です いかがでしたか？ 業務システム開発の重心が移動すると思いませんか？

60. ご清聴ありがとうございました （株）ワディット 和田正則 http://wadit.jp [email_address]