だれがどこでやるのだ
今まで、Why、What、Howについてみてきましたが、最後に残りのWho、Where、Whenを考えておかないと紙の上の議論となってしまいます。最初の頃にも言いましたが、動いてなんぼ、役に立ってなんぼの世界であるので、具体的にどういう体制で、どういう組織で、どこに適用し、いつやるのだということを提示することも重要であると思う。
体制のことで言えば、業務プロセスのデザインをビジネスプロセスデザイナー、業務プロセスの実装をITアーキテクト（従来のSEの進化形）、プログラミングをスーパープログラマーというのが理想的である。このチームで「セル生産方式」のように一気に作り上げることが望ましい。たとえが悪いが、「必殺仕事人」「黄金の7人」みたいなものだ。ここで作られたコアシステムをベースにカスタマイズしたり、運用したりするのは、一般のひとがやっていくという役割分担になる。
ここで、軽量プログラミング言語を操る技術者をどう巻き込んでいくがポイントだ。たとえば、IPAの未踏ソフトウエアの卒業生を引き込むとか工夫する必要がある。
また、このビジネスプロセスデザイナーという役割をどうするか。前に、企業IS部門や情報子会社について、彼らはどちらかというとベンダー寄りであると書いた。ここでは、期待を込めて、この役回りを企業IS部門あるいは情報子会社が負うことを提案する。
従って、従来に比べ、さらに業務側にシフトしたスタンスとする。これは前にも言ったように、別にユーザと同じレベルで業務を知る必要はなくて、BPMという道具を使い、手持ちのコンポーネントを見せて、必要とする業務プロセスを引き出す能力をもつことでかまわないのだ。
情報子会社が本質的に抱える課題である自立化を実現するヒントになると考える。これは本題ではないのでこれ以上は言及しない。
ただし、こうした開発部隊をどう組織化するかは難しい課題である。次に述べる地方の中小企業に導入する場合など、必ずしも情報子会社でやれるとは限らないケースもあると思われる。全国規模のITベンダーの力を借りることも必要になるかもしれない。
さて、実際にここで論じた方法論や仕組みをどこにどうやって適用するのがいいのだろうか。その答えとして、中小企業への適用を行い、地域ごとのビジネスサポートセンター設置を構想する。なぜそう考えるに至った理由について、昨年「日経ソリューションビジネス」に掲載された記事が参考になるで引用する。この記事は「中堅・中小企業の市場に対する「これまでの常識」と７つの「新常識」」と題したものでベンダーに向けて発信されているが、状況を的確に捉えているのであえてそのまま載せる。
これまでの常識
①中堅・中小企業もまずは経営戦略を立案した上でシステム化すべき
②日本版ＳＯＸ法は、上場企業などに適用され、中堅・中小企業には関係ない
③中堅・中小企業でも基幹業務システムを提案することが最も重要
④中堅・中小企業はシステムを導入しても単価が安く、あまり儲からない
⑤中堅・中小企業は、料金設定を安くしなくてはシステムを導入してくれない
⑥最新システムを入れる中堅・中小企業は、ＩＴ化にも理解があり進めやすい
⑦社内にＩＴ部門をもたない中堅・中小企業が多いため、導入作業が面倒
これからの常識
①まずは効果を出しやすい部分からシステム化して、ＩＴの重要性を示す
②たとえ適用されなくても、上場企業と取引するとき今後、内部統制が必須に
③業務コスト削減の基幹業務システムより、売上に直結するＷｅｂシステムの提案を
④システムより、付随する業務サービスに価値を認め対価を支払ってくれる
⑤短期間にシステムを開発してくれるなら、高い料金設定でも納得してくれる
⑥むしろ遅れている中堅・中小企業の方がスムーズにシステム化が進む
⑦中堅・中小企業の社員は、費用が安くなるなら積極的に導入作業を助けてくれる
これを見たらおわかりのように、「ユーザ目線のBPM」は、中堅・中小企業をターゲットにするのが適していると思いませんか。
また、社内にＩＴ部門をもたない中堅・中小企業が多く、運用を自社で行なうのが困難であり、コア業務に集中するために運用は外部にまかせたいと考えている。従って、センター化してASPサービスとして機能させることが望ましい。
筆者は、全国の信用金庫単位でこのセンター（ビジネスサポートセンターと呼ぶ）を構築したらどうかと提案している。それぞれの信用金庫には多くの中堅・中小企業がぶらさがっています。その企業群が共同で利用できるビジネスシステムを提供することをめざします。全国に２９２の信用金庫がありますが、どこかひとつを選んでそこで実装し、モデル化して全国水平展開するというイメージでいかがでしょうか。
いつやるかは、全体スキームの確立状況をみて決めていくことになります。
日本の強さは中堅・中小企業の力によるところが大きいと考えられます。さらにそこを強化して行こうではありませんか。
今まで、Why、What、Howについてみてきましたが、最後に残りのWho、Where、Whenを考えておかないと紙の上の議論となってしまいます。最初の頃にも言いましたが、動いてなんぼ、役に立ってなんぼの世界であるので、具体的にどういう体制で、どういう組織で、どこに適用し、いつやるのだということを提示することも重要であると思う。
体制のことで言えば、業務プロセスのデザインをビジネスプロセスデザイナー、業務プロセスの実装をITアーキテクト（従来のSEの進化形）、プログラミングをスーパープログラマーというのが理想的である。このチームで「セル生産方式」のように一気に作り上げることが望ましい。たとえが悪いが、「必殺仕事人」「黄金の7人」みたいなものだ。ここで作られたコアシステムをベースにカスタマイズしたり、運用したりするのは、一般のひとがやっていくという役割分担になる。
ここで、軽量プログラミング言語を操る技術者をどう巻き込んでいくがポイントだ。たとえば、IPAの未踏ソフトウエアの卒業生を引き込むとか工夫する必要がある。
また、このビジネスプロセスデザイナーという役割をどうするか。前に、企業IS部門や情報子会社について、彼らはどちらかというとベンダー寄りであると書いた。ここでは、期待を込めて、この役回りを企業IS部門あるいは情報子会社が負うことを提案する。
従って、従来に比べ、さらに業務側にシフトしたスタンスとする。これは前にも言ったように、別にユーザと同じレベルで業務を知る必要はなくて、BPMという道具を使い、手持ちのコンポーネントを見せて、必要とする業務プロセスを引き出す能力をもつことでかまわないのだ。
情報子会社が本質的に抱える課題である自立化を実現するヒントになると考える。これは本題ではないのでこれ以上は言及しない。
ただし、こうした開発部隊をどう組織化するかは難しい課題である。次に述べる地方の中小企業に導入する場合など、必ずしも情報子会社でやれるとは限らないケースもあると思われる。全国規模のITベンダーの力を借りることも必要になるかもしれない。
さて、実際にここで論じた方法論や仕組みをどこにどうやって適用するのがいいのだろうか。その答えとして、中小企業への適用を行い、地域ごとのビジネスサポートセンター設置を構想する。なぜそう考えるに至った理由について、昨年「日経ソリューションビジネス」に掲載された記事が参考になるで引用する。この記事は「中堅・中小企業の市場に対する「これまでの常識」と７つの「新常識」」と題したものでベンダーに向けて発信されているが、状況を的確に捉えているのであえてそのまま載せる。
これまでの常識
これからの常識
これを見たらおわかりのように、「ユーザ目線のBPM」は、中堅・中小企業をターゲットにするのが適していると思いませんか。
また、社内にＩＴ部門をもたない中堅・中小企業が多く、運用を自社で行なうのが困難であり、コア業務に集中するために運用は外部にまかせたいと考えている。従って、センター化してASPサービスとして機能させることが望ましい。
筆者は、全国の信用金庫単位でこのセンター（ビジネスサポートセンターと呼ぶ）を構築したらどうかと提案している。それぞれの信用金庫には多くの中堅・中小企業がぶらさがっています。その企業群が共同で利用できるビジネスシステムを提供することをめざします。全国に２９２の信用金庫がありますが、どこかひとつを選んでそこで実装し、モデル化して全国水平展開するというイメージでいかがでしょうか。
いつやるかは、全体スキームの確立状況をみて決めていくことになります。
日本の強さは中堅・中小企業の力によるところが大きいと考えられます。さらにそこを強化して行こうではありませんか。
