鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
BPMを正しく理解するために－要求定義と要件定義 (mark-wada blog)
経営とITの同期を議論していくと、経営の要求をどうITに反映させていくのかとう問題が出てくる。ここの議論での焦点は、「要求定義」と「要件定義」の違いである。 米国ではこの前者の「要求定義」のための「要求工学」というのがしっかりとあるというのは一色教授の話にもあった。「要求工学」というのは要求獲得―要求仕様化―要求検証―要求管理というサイクルを工学的にやろうという動きである。 日本にも要求工学はあることはあるし、要求開発というコンソーシアムもあるのだが、概して、「要件定義」に寄っている。どういうことかと言うと、システム化するための要件、システムとして備える要件に持っていってしまうということである。 そうなると端的にいえば、システム化できる業務だけに限った要求になってしまう。この時点で、経営とITの乖離が起きる。経営戦略の達成は何もIT化できる業務だけでできるわけではなく、手作業やコラボレーシ
業務プロセス設計作法 ～ はじめに ～ (mark-wada blog)
これから何回かに分けて、上流設計にあたる業務プロセス設計について書いてみようと思います。 以前にも「ユーザ目線のBPM」で触れていますが、より具体的な方法を提示していきたいと思っています。これまでは、どちらかというと業務フローができたら、基本的にはノンコーディングでシステム構築ができることを説明してきていますが、その上流のところの話になります。実はここが非常に重要であると同時に難しい領域なのです。 ですから、今までも再三言ってきていますように「シンプルで一貫化されたきれいなプロセス」が書けたらそれでおおかたのシステム構築が終わってしまうということになりますので、そのきれいなプロセスをどう書くかがますます大事になるのです。 そこで、この業務プロセスを書くための作法についてひとつずつエントリーしていくことにします。本技法ではつぎに示すような１６の作法からなっています。この作法に従って業務プロセ
新発想の業務フローチャート作成術（3）業務フローチャートの粒度をそろえるにはどうするか － ＠IT情報マネジメント
業務フローチャート作成で悩ましい問題の1つは、業務の最小単位である作業を描く際に、同じ業務プロセスであっても人によって大きさがまちまちになってしまうことだ。今回は、これをどのように解消できるかを考える。 日本版SOX法の3点セットでは、業務フローチャートが中心的な役割を担うにもかかわらず、その作成方法には公式が少なく、いざ作成を開始するとさまざまな課題に突き当たってしまう。 今回は、代表的な課題の１つである、作業の大きさの問題を取り上げる。同じ業務プロセスにもかかわらず、描く人によって業務の最小単位である作業の大きさ、つまり「粒度」がまちまちになってしまう。これをどのように解消するのかについて考える。 まず、本連載でこれまで述べてきたことをおさらいしてみよう。 業務フローチャートのそもそもの目的は、「業務プロセスの可視化」にある。しかしながら、実際に業務プロセスを可視化していく際には、「多
RailsとABDとCRUDとワークフロー - moroの日記
羽生さんのABD(Activity Based Datamodel)ですが、それを知った感想を自分なりにすごく乱暴にまとめると、DBをイベント系とリソース系にわけた上で、仕事っていうのはリソース間やイベントとリソースの間になんらかの関係を発生させる捉える、という考え方かなぁ、と。 イベントとリソース 売上げが立つ、というイベントはつまりお客さん(リソース)と商品(リソース)との間に購入/入金という関連が発生するというふうに捉えられます、と。 あんまり例えが良くありませんが、ビジネス上のできごと＝イベントに着目し、イベントも関連テーブルのエンティティを素直にcreateすることで表現するという方法論だと読んでいます。 さらにDBを設計するということは、そういったイベント、すなわちビジネス上のアクティビティをどう記録するか、という観点でデータの持ちかたを設計していくということなんじゃないでしょ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Manageability - Open Source Workflow Engines Written in Java
ZDNet Japanにてビデオ公開 - Change! Challenge!