さて、次は「ビジネスと業務の構造化」についてです。 業務プロセスを考える場合、企業はそれぞれの事業を行なうためにどんな会社構造になっているのか、事業遂行のプロセスはどんなものがあるのか、そのプロセスにはどんな機能を持たせているのかといったことを探っていくことが必要です。 業務プロセスには必ず目的があります。ときたま、目的が不明あるいはプロセスの終点がない場合があったりします。事業遂行上必要だからこそ目的が存在するわけですから、その必要性をみるためにもこうしたアプローチが大切なのです。 私は長いこと製造系の会社にいましたので、どうしてもサプライチェーン中心に見てしまいます。しかし、非製造業でも実体がないサービスのようなものでも基本的には同じだと考えています。 よく、業種・業態に分けてその事業プロセスの違いを言う人がいますが、少なくとも業務プロセスレベルの話をするときはそれほど重要ではないので

昨日は銀座のルノワールでビジネスプロセスパターン研究の第１回の勉強会を行なった。家を出るときてっきり6時半からだと思い込み、少し早めに出たつもりだったのだが、新橋から銀座に向かう途中で、そうだ6時からだったと気がつきあわてて走って向かう。若干遅れて到着。早めに出てよかったと胸をなでおろす。遅れて来る二人を除いてもう7人が席についていて、はあはあ言いながら始める。 昨日は第１回目なので、趣旨説明や自己紹介を行う。メンバーは主に20～30代（中にひとり気持ち20代の40歳の人がいます）のベンダー系に勤めている人たちで構成されています。ぼくがブログやBPMオフ会で出会った人とうちの社長関係で知り合った人たちです。 議論の第一歩は、「現状の業務システムはビジネスの要求に答えられているか」である。ぼくの方から、ここ15年間業務システムが変わっていないので何とか変革しなくてはいけないという話をする。ビ

Memorandum of Tactical Retreat from IT Buzz / 悲喜子のメモ About BPM or ACM (or SOA).

前回、主に構造的な問題と技術上の問題をとり上げたが、それではそういう課題をどう解決してくのか、そのためにどんな議論をしていったらいいのかを考えてみます。 前の議論を踏まえてみてみると、つぎのようなことが論点になりそうである。 １） ビジネスの要求とＩＴを一貫化させるためにはどうしたらいいのか ２） 変化対応力に優れたシステム構造とはどんなものなのか ３） 開発生産性や保守性を上げるにはどうしたらいいのか こうしたことを解決できれば、前回指摘した業界構造や人材の問題もかなり改善されていくと思われます。ここが、最も重要で基本となるところです。 すなわち、なぜビジネスとＩＴが乖離するのか、どこで乖離がおきているのか、阻害要因は何かといった議論である。ユーザは何を考えているのか、技術の進展がカバーできるのかとかいったことも含めて多角的な視点でみていく必要がありそうです。 システム構造は、SOAやS

前回の主旨で述べたように今の業務システムを変えたいと言っています。ということは、現状に様々は問題があって、その問題を解決していこうということでもあります。その問題あるいは課題とはいったい何なのだろうか。そこをきちっと分析して本質的な課題を抽出しないと方向がずれてしまいます。 個々の領域については細かく見ていくことにしますが、現状の業務システムおよびそれを取り巻く環境を俯瞰してみると、どうも「ビジネスとIT」、「ユーザとベンダー」といった両岸の間に流れる“誤解”の川があるような気がします。そこにかなりの部分の問題が潜んでいるように思えるのです。 何年もの間、「経営とITの融合」、「ビジネスに貢献するIT」、「ビジネスマインドをもったSE」だとか両者をうまくつなぐことの必要性は謳われていながら、現実には乖離があるのは否めないのではないでしょうか。 その誤解について少し見ていくことにします。そし

この年は、工場のある製品の生産管理システムの構築プロジェクトをはじめた。生産管理というと、製造、試験、出荷という３つのジャンルにまたがるシステムである。基幹システムからオーダーをもらって、そのオーダーに従ってユーザ規格にあった製品を出荷していくというごくオーソドックスな生産管理システムである。 世はちょうどメインフレームのホストー端末からクライアントサーバーへ移行しつつあったので、われわれもその方式を採用することにした。しかし、問題があって、そのとき工場システムとしてAS400を使った設備保全などの部門システムが稼動していて、当初UNIXを使おうとしたが、まだ信頼できないと言われて、そのAS400を使えとなったのである。AS400をサーバにしたクライアントサーバーは世界でも珍しかった。CSBuilderというミドルウエアをかましてやったのである。 そして、開発方法をどうするかが非常に頭の痛

ITpro - ヒトもカネもなくともシステム内製はできる http://itpro.nikkeibp.co.jp/article/COLUMN/20081202/320537/ ＜「ヒトもカネもない中小企業でも，やればできる」---菅雄一氏は関西のある企業のたった一人のシステム担当である。従業員約200人の製造業で，ほぼ独力でネットワークを引きサーバーを立て，社内向けのグループウエアや顧客向けのQ＆A情報検索システム，販売システムなどを構築してきた。 ミドルウエアとして使っているのは，すべてオープンソース・ソフトウエア。ハードウエアの代金と回線料を除けば，費用はほぼ菅氏の人件費だけだ＞。 「Linux好き事務員」として一部では有名な菅雄一氏の事例紹介を軸にした面白い記事。 この菅氏のような熱心な人材がいる中小企業はやや例外的だと思うが、システム内製化の動きが進んでいるのは間違いないようだ。

これはBPM（Business Process Management）のことである。昨日、日本BPM協会のコンポーネント部会に行く。これは毎月1回夕方開かれるのだが、もう昨日で16回目になる。 毎回、BPMに関するネタについてLightning talkがあり、それについてディスカッションするのですが、昨日はMさんから、SPQC（American Productivity and Quality Center）とSCOR（Supply-Chain Operations Reference-model）のモデルをマージした例について聞く。 これはトップダウン的なアプローチをとるときに使う業務プロセスのレファレンスモデルで、階層化されたフレームワークであるが、両者で得手不得手のところや、ラフなところや細かいところなど、違いがあるのでそれらの粒度を調整したという話でなるほどと感心させられた。こう