http://www.innova-bp.co.jp/ ビジネスプロセスを可視化して、 　企業の明日の成長のために、 　　情報技術の活用を支援する。 ja Copyright 2010 Fri, 04 Dec 2009 23:07:26 +0900 http://www.sixapart.com/movabletype/?v=3.2-ja-2 http://blogs.law.harvard.edu/tech/rss 要旨 　１１月２８日（土）専修大学神田校舎にて５回目となる共同公開講座を「中小企業の成長戦略」をテーマとして開催いたしました。講座は、専修大学商学部の伊藤和憲教授による「戦略の作り方」と題する講演に始まり、続いて、ランスタッド（株）代表取締役社長 小泉明正氏が「経営者の意思決定と成長戦略」と題する講演を行いました。最後は、専修大学大学院商学研究科長・商学博士の上田和勇教授をコーディネーターとし、専修大学商学部 伊藤和憲教授、ランスタッド（株）代表取締役社長 小泉明正氏、（株）イノーバ代表取締役社長 長田邦男氏をパネラーとして、パネルディスカッションを行いました。 日時 　平成２１年１１月２８日（土） １３：００〜１７：００ 会場 　専修大学 神田校舎７Ｆ テーマ 　中小企業の成長戦略 プログラム 　●講演会（第１部）「戦略の作り方」 　　専修大学商学部 教授 伊藤 和憲 　●講演会（第２部）「経営者の意思決定と成長戦略」 　　ランスタッド株式会社 代表取締役社長 小泉 明正氏 　●パネルディスカッション 　　コーディネーター： 　　　専修大学商学研究科 研究科長・教授 上田 和勇 　　パネラー： 　　　専修大学商学部 教授 伊藤 和憲 　　　ランスタッド（株） 代表取締役社長 小泉 明正氏 　　　（株）イノーバ 代表取締役社長 長田 邦男氏 詳細はこちらから]]> http://www.innova-bp.co.jp/2009/12/new.html http://www.innova-bp.co.jp/2009/12/new.html セミナー情報 Fri, 04 Dec 2009 23:07:26 +0900 　ワークフローにはグループウェアや文書管理から発展した電子決裁タイプのものと、ヒューマンプロセスを主体としたBPMがある。前者におけるビジネスプロセスとは決裁を行う人の順番と流れを図示したものである。後者はBPMNに見られるように、フローオブジェクト（アクティビティなど）、接続オブジェクト（シーケンスフローなど）、成果物、そしてスイムレーン（水泳競技ではプールをレーンで区切っていることからそのように呼ばれる）によってモデリングを行う。スイムレーンは会社の組織や人といった役割の異なる者を異なるレーンで表し、それぞれが行うアクティビティをそれぞれのレーンに配置していく。ワークフロー製品がどちらのタイプのものかはビジネスプロセス図（ワークフロー図）を見れば、すぐわかるということでる。 http://www.innova-bp.co.jp/2009/11/post_94.html http://www.innova-bp.co.jp/2009/11/post_94.html プロセスモデラーブログ Sat, 28 Nov 2009 14:52:27 +0900 　ノークリサーチが10月26日に発表した2009年の中堅・中小企業（SMB）でのワークフローアプリケーション市場の調査結果によると、ワークフローのパッケージは製品数が多く、新規参入も盛んであることから、利用予定のシェアは大きく変動することが多いとしている。ワークフローアプリの今後のポイントが業務フロー管理であることから、他社製品との連携が必須だが、「連携性」が市場シェアを左右する要因になってくるだろうとコメントされている。 　ERPなどの既存システムとの連携が重要になってくるということは間違いなさそうであるが、「連携性」というのが連携モジュールのような機能であることもあるが、大半は開発にかかる期間・コストが少ないということを意味する。今やワークフローのパッケージに求められることはワークフローのデザイン環境、ワークフローエンジンとして他システムから利用できる接続性と運用状況や結果をモニタリング・分析できる機能であるといえる。 http://www.innova-bp.co.jp/2009/11/post_93.html http://www.innova-bp.co.jp/2009/11/post_93.html プロセスモデラーブログ Sat, 14 Nov 2009 14:45:36 +0900 趣旨 　企業経営はそのサイズにかかわりなく、変化する外部環境変化のなかで、内部資源を有効活用しながら多様なリスク、チャンスをいかに最適化していくかがポイントとなります。 　この公開シンポジウムでは、まず企業経営に決定的な影響を持つ経営者リスクに焦点を当て、倫理リスクや経営者資質の向上策などについて検討し、今後のリスクマネジメントの方向性を探っていきます。 　次に実務家2人による実践を踏まえた報告が行われます。第1は企業価値を向上させるためのイノベーションについて、その意思決定の実際、リスクマネジメントとの関連性などについて検討し、第2に企業価値に大きな影響を及ぼすM&A問題について、米国他での長年の実務経験などから得られた知見について報告があります。 　最後にパネルディスカッションを通し、フロアーからの質問、報告者間の意見交換他を通し、今後のリスクマネジメントにおける実践的・理論的課題と展望について検討していきます。 開催日程 2009年11月7日（土）13：30〜17：00（参加費　無料） 開催場所 専修大学神田校舎7号館731教室（東京メトロ・九段下または神保町駅、JR水道橋駅） 報告者 １．上田和勇（専修大学教授、大学院商学研究科長） ２．長田邦男（株式会社　イノーバ代表取締役） ３．高野仁一（米国公認会計士、専修大学大学院博士後期課程） パネル・ディスカッション コーディネーター： 　　上田和勇（専修大学教授、大学院商学研究科長） パネラー： 　　長田邦男（株式会社　イノーバ代表取締役社長） 　　高野仁一（米国公認会計士、専修大学大学院博士後期課程） 　　横山裕昭（株式会社モバイルコンピューティングテクノロジーズ代表取締役社長） スケジュール 13:00　　　　　　　開会の挨拶、趣旨説明 13:45〜14：25　第1報告（報告30分、Q＆A10分） 　　　　　　　　　　　　上田和勇（専修大学教授、大学院商学研究科長） 　　　　　　　　　　　　「経営者リスクとリスクマネジメントの方向性」 14：30〜15：10　第2報告 　　　　　　　　　　　　長田邦男（株式会社イノーバ代表取締役） 　　　　　　　　　　　　「イノベーションにおける意思決定とリスクマネジメント」 15：15〜15：55　第3報告 　　　　　　　　　　　　高野仁一（米国公認会計士、専修大学大学院博士後期課程） 　　　　　　　　　　　　「M&Aにおける意思決定とリスクマネジメント」 16:15〜17：00　パネル・ディスカッション、質疑応答 　　　　　　　　　　　　「イノベーションにおける意思決定とリスクマネジメント」 17:00　　　　　　　閉会の挨拶 ]]> http://www.innova-bp.co.jp/2009/11/post_92.html http://www.innova-bp.co.jp/2009/11/post_92.html セミナー情報 Mon, 09 Nov 2009 07:20:34 +0900 　１年前まではワークフローというと勤怠管理や文書管理に見られる電子決裁のシステムという認識がまだ根強かったが、最近では内部統制への対応を含めて、ERPのフロントエンドとしてのワークフロー、複数のシステムを連携するためのワークフローという認識が定着してきた。ERPなどの業務システムには機能が実装されていても業務プロセスが実装されていないために、ERPはそれぞれの製品の中に閉じてワークフローの整備が始まった。しかしながら単一の業務システムだけで企業の業務が動いているわけではなく、複数の業務システムにまたがった業務プロセスを実装できる仕組みが必要となってきた。当初はBPM製品がそうなるのではないかと言われていたが、人間系の業務プロセスが多いことからワークフローがその役割を果たすことになったようである。 　では実際にワークフローとERPパッケージを連携するとはどのように行うのであろうか。業務プロセスはワークフローが持つデザイナーで設計することになる。ワークフローで実行されるものは業務プロセスで定義されている個々の業務（アクティビティ）である。これは大半が画面を伴うプログラムである。ワークフローでアクティビティが順番に進み、ユーザのPCでアクティビティ（例えば売上伝票入力など）が実行される。このプログラムはCSVファイルを生成し、ERPパッケージに送るか、ERPパッケージのデータベースまたは連携用のデータベースにデータを書き込むことになる。それではERPパッケージで実行された処理の後でワークフローに戻ってくる場合にはどのようになるのであろうか。これには複雑な仕掛けが必要になってしまう。さらにワークフローで作成したプログラムの操作画面とERPパッケージの操作画面は全く別物となってしまい、操作性は悪いものとなってしまう。 　このところ、ERPとワークフローを連携するプロジェクトが数多く立ち上がっているが、実は連携のための開発にコストと時間がかかることになってしまっている。ワークフローとERPを連携するためには、外部システムからワークフローを制御する仕組み（新しい業務プロセスを生成する、アクティビティを外部から実行するなど）が必要となってくる。これで始めてERPとワークフローをシームレスに連携できるようになる。INNOVAのワークフローはワークフロー主体でも実行できるが、ワークフローエンジンとして、外部システムからその機能を利用することもできるし、その混在もすることもできる。 http://www.innova-bp.co.jp/2009/11/erp.html http://www.innova-bp.co.jp/2009/11/erp.html プロセスモデラーブログ Sat, 07 Nov 2009 23:07:48 +0900 　ワークフローをベースとしたシステム構築を行っていると、必ずと言っていいほど、既存の業務アプリケーションの画面をワークフローから呼び出せないかとか、業務アプリケーションからワークフローをコントロールできないかという要望が出てくる。ワークフローで定義する業務（ビジネスプロセスの中の一つのアクティビティ）は一般的には業務アプリケーションにおける○○画面の操作ということがよくある。例えば注文書の受理というアクティビティは、業務アプリケーションの注文情報入力画面の操作ということになる。わざわざワークフローで画面を作成してプログラムを作って、業務アプリケーションのデータベースに必要なデータを書き込んでいたのでは、重複開発をしていくことになる。 　なぜ、このようなことが起きてくるのであろうか。ほとんどの業務アプリケーションがきちんとしたＤＯＡで設計されることなく、データを蓄積する容器としてデータベース設計を行っているからである。プログラムは○○情報の入力・更新・参照機能といったデータベースへのアクセスプログラムとして設計されている。注文情報の入力機能ということになってしまう。それでは業務であるところのビジネスプロセスはどのように実装されているかといえば、ユーザがどのプログラム（たいていは画面である）を選択して、どの順番で操作するかを考えて行うことで実装されているのである。つまりビジネスプロセスは実装されていないのである。プログラム（画面）やデータへのアクセス制御をしている程度である。 　大半のＳＥ、設計者は業務流れ図やＤＦＤを書くことができない、というよりも経験がほとんどない。そんなことはないと思いたいのであるが、ＥＡ（Enterprise Architecture）でＢＡ部分の業務を記述できるＳＥが極めて少ないし、内部統制で業務流れ図を書けるＳＥもほぼいない。データベース設計とそのアクセスプログラムしか設計してこなかったのであるから当然と言えば当然である。 　冒頭の話に戻ると、ユーザが求めているものはビジネスプロセスが実装されたシステムである。しかしながら業務アプリケーションに実装されていないので、これをポータルに求めた時もあった。ユーザがログインすると、行うべき画面に導いてくれるというものである。しかしそのようなポータルができることはなかった。そもそもビジネスプロセスを管理できていない業務アプリケーションをコントロールすることはできない。現実解としては、既存の業務アプリケーションはできるだけ手をいれないで、外部にワークフローシステムでビジネスプロセスを実装して、そこから業務アプリケーションの画面を呼び出し、必要なデータの受け渡しを行うことである。 http://www.innova-bp.co.jp/2009/10/post_71.html http://www.innova-bp.co.jp/2009/10/post_71.html プロセスモデラーブログ Sat, 31 Oct 2009 11:40:50 +0900 モデリングしたビジネスプロセスというのは、人が認識している業務である。たとえば、出張申請書の記入、出張申請書の受付、旅費の確認、出張申請書の承認、出張、出張報告書の作成、出張報告書の承認、旅費精算申請、、、などである。ところがシステムでプログラム開発をすると、全ては出張管理情報の登録、更新、削除（もちろん画面にはもう少し業務よりの言葉が使われるが）となってしまう。出張申請書の記入は出張管理情報の登録であるし、出張申請書の承認は出張管理情報の更新である。 実は、ビジネスプロセスからシステムを開発する場合に、簡単にプログラム自動生成というようなわけにはいかない。ビジネスプロセスの各アクティビティに対して、画面（いくつかのアクティビティでは共通の画面が使われる）とロジックまたはルール（これもいくつかのアクティビティでは共通のものが使われることがある）を当てはめていくという作業が設計作業になるわけである。 業務手順書とプログラム設計書が似ても似つかないものに感じるのはここのギャップである。このギャップを開発者が独自にやればやるほど、ビジネスプロセスとプログラムは乖離する。統一的な考え方や制約をつけて標準化することが重要である。 http://www.innova-bp.co.jp/2009/10/post_26.html http://www.innova-bp.co.jp/2009/10/post_26.html プロセスモデラーブログ Fri, 23 Oct 2009 22:42:19 +0900 製造現場などでは、カイゼンのように、プロセスを可視化して改善を継続していくという考え方は定着している。企業の業績の差異は、当たり前のことをちゃんと実行できるかできないかである。 いわゆるホワイトカラーや知識集約型業務でも、ビジネスプロセス（業務手順）を文書化し、改善していくという試みは何度も行われてきたし、今後も行われることになる。ISO9000でも、日本版SOX法対応でも、EAでも本質は同じである。なのになぜ定着できないのであろうか。 企業において、イノベーションは生命線である。そのために社員がクリエイティブな視点を持つことも重要である。しかしながら、全ての業務に当てはまるわけでもないし、全ての社員に当てはまるわけでもない。ライン業務で求められるのは定着した業務プロセスに対する段階的イノベーション（改善活動）であり、マーケティングや設計で求められるのは非連続（交差的）イノベーションである。日本ではよく言われる平等の概念のためなのか、それぞれに求められていることが違うということを明確にはしない。ライン業務に従事している人たちが非連続イノベーションをやってみたいと思うことは企業にとってはマイナスであるだけでなく、ビジネスプロセスの定着を阻むことにつながっていく。自分はクリエイティブだから他の人と同じことをする必要はない。同じことをやることは官僚的だとか、大企業病だとか勝手に考えてしまう。 かつて企業では新しく社員が入社すると、現場の仕事に従事させてライン業務の重要性を体に染みこませていた。だから今はよくないと言っても始まらない。 ビジネスプロセスを文書化するだけでは、定着しにくいという状況では、ビジネスプロセスを情報システムのビジネスロジックとして組み込んでしまうことしか定着の道はない。日本のホワイトカラーの生産性は欧米に比べて低いという現状を冷静に受け止める必要がある。 http://www.innova-bp.co.jp/2009/10/post_23.html http://www.innova-bp.co.jp/2009/10/post_23.html プロセスモデラーブログ Tue, 20 Oct 2009 23:40:24 +0900 　システム開発を行うと操作手順書は作っても、業務手順書を作るケースは多くない。システムの操作ができれば業務が行えるかというとそんなことはない。ＲＤＢが主流のデータベースになって、ソフトウェア開発の仕方は、まずデータベース設計を行い、それからデータベースを操作するプログラムを作成するようになった。プログラム名や画面名を見ればそのことはよくわかる。注文情報管理画面（注文情報の登録、更新、削除）や在庫情報管理画面（在庫情報の登録、更新、削除）などである。業務としては、受注業務、注文内容変更、注文取消し、入庫、出庫などである。 　システムのアクセスログを取ろうとすると、データベースへのアクセスログは簡単に取れるが、それは何の業務に基づくログであるかがわからない。したがってアクセスログはプログラムのそれぞれで意味をもたせて出力をしなければならなくなる。 　これまでＤＯＡやＯＯＡのアプローチでシステム開発をすることが期間を短くしたり、品質の確保に大いに貢献してきたわけであるが、それは業務を行うということをシステムを操作する人に押し付けてきたことにつながっている。日本版ＳＯＸ法への対応で浮かび上がってくるのは、業務もシステムの中に組み込まなければならないということである。注文情報の変更がなぜされたのは、注文内容が変わったのか、入力ミスであったのか、承認されたかということを業務プロセスとして認識しなければならないのである。きちんと業務プロセスをモデリングし、システムに埋め込むためにはどうしてもワークフローが必要になってくる。 　日本版ＳＯＸ法はソフトウェアの開発の仕方を根本的に変えてしまうことになる。 http://www.innova-bp.co.jp/2009/10/post_34.html http://www.innova-bp.co.jp/2009/10/post_34.html プロセスモデラーブログ Sun, 18 Oct 2009 11:44:51 +0900
【導入前の課題】 ・営業担当は訂正対象の伝票から赤伝と新黒伝を起票する。申請はＥｘｃｅｌや紙で行われるため転記ミスが発生しやすい。 ・責任者は申請内容とＥＲＰのデータを照合して確認するため、手間が掛かる。 ・アシスタントによる再入力には｢ミス｣｢漏れ｣｢忘れ｣｢不正｣のリスクがある。
【効果】 ・あらかじめ定義されたプロセスの通りに承認が実行されることを保証する。 ・承認待ちの案件の状況をリアルタイムにモニタリングすることができる。 ・承認者は部門、職位、金額、によって一意にシステム側で決定される。 ・バブルアップ設定によって、異動や入退職の影響を受けない。 ]]> http://www.innova-bp.co.jp/2009/10/post_90.html http://www.innova-bp.co.jp/2009/10/post_90.html 事例 Sat, 17 Oct 2009 15:10:59 +0900
【導入前の課題】 ・営業アシスタントだけが出荷通知書を確認するため、顧客と合意している取引条件が適用されているか、どうかを判断できないケースがあります。 ・顧客からの問合せが営業担当に入るため、内容の照会に時間が掛かります。 ・自動ＦＡＸは混雑による不達が発生するうえ、高い維持コストが発生します。
【効果】 ・出荷内容（請求情報）のチェックによって精度が向上する。 ・自動ＦＡＸから電子メールに送信方法を変更することで、運用コストが低減される。帳票が電子的に添付されるため、顧客側での管理コストも低減される。 ・出荷内容に確認事項がある場合、ボタン操作でアシスタントにＴｏＤｏが通知される。 ・確認依頼ＴｏＤｏは自動で届くが、確認が遅れると警告が出るなど遅延防止が図られる。 ]]> http://www.innova-bp.co.jp/2009/10/post_89.html http://www.innova-bp.co.jp/2009/10/post_89.html 事例 Sat, 17 Oct 2009 15:07:39 +0900
【導入前の課題】 ・現状ＩＴ環境をベースとして監査人指摘事項へ対応することへの限界 ・親会社の内部監査部門からも、現行システムの抜本的な改善指示あり ・内部統制を考慮した業務プロセスの確立が必要不可欠
【効果】 ・物、仕事の流れと、データの流れが一致した業務プロセス ・人、紙によるデータハンドリングを介在させない（入力ミス、改竄防止） ・データのエラーチェック及び修正が迅速、正確、タイムリー ・人的作業が極力少ない　（作業効率性の向上、コストセーブ） ]]> http://www.innova-bp.co.jp/2009/10/post_87.html http://www.innova-bp.co.jp/2009/10/post_87.html 事例 Sat, 17 Oct 2009 14:48:16 +0900 最近のビジネスプロセスモデリングの議論の中でよく言われるのが「経営とＩＴのＸＸ」である。しかしながらこれはＩＴに係る人たちからの見方であって、経営に責任を持つ人からすれば、経営とＩＴが同じレベルにあるということはありえない。経営はファイナンス（資金調達）、マーケティング（事業戦略と実行）そしてエデュケーション（社員の育成）であり、ＩＴが同じレベルで語られるのは一部の業界にすぎない。 ビジネスのモデリングが重要視されてきているのは、終身雇用が姿を消し、団塊の世代が退職していく中で、これまで属人的に行ってきた業務を、定義されたプロセスとして誰でもが実施できるようにしようということである。日本版SOX法の底流にあるのは、企業活動をプロセスの集合体にしようという考えである。 こうした背景の中でモデリングされてくるであろうビジネスプロセスをどのようにITで支援するか（自動化であったり、強制化であったり、高速化であったりする）ということが、これからのビジネスプロセスモデリングの本質である。「経営とIT」でなく、「経営の中のIT」である。 http://www.innova-bp.co.jp/2009/10/it.html http://www.innova-bp.co.jp/2009/10/it.html プロセスモデラーブログ Fri, 16 Oct 2009 22:41:23 +0900 ビジネスプロセスモデリングというのは、現実の業務すなわちビジネスプロセスをシステムで実現するための手段である。現実の業務とシステムとでは完全な対応はできないわけであるし、現実の業務を可視化することは実は難しいということもあり、モデリングの手法は時代とともに改善されてきている。また、対象とする業務に合わせたモデリング手法もある。 全てのモデリング手法に共通していることは、システムを設計・構築する観点から考えられていることである。業務を設計・実施する観点から考えられていないことである。システム側の人間からすればモデリング手法の差異はそれなりの意味を持つが、業務側の人間からすれば何の意味もないということである。業務の引継ぎをする時に使われる引継書は文書で記述されている場合もある。 業務とシステムのギャップのことを議論するよりも、業務側の人間とシステム側の人間との認識のギャップを埋めることのほうが今は重要である。政府で実施されている業務・システム最適化では、業務側の人間が業務をきちんと定義できることを最大の課題として設計されている。使う人間が業務を理解できていないのに、ちゃんとシステムは作れるわけがないからである。 http://www.innova-bp.co.jp/2009/10/post_24.html http://www.innova-bp.co.jp/2009/10/post_24.html プロセスモデラーブログ Thu, 15 Oct 2009 22:40:54 +0900 　ワークフローと呼ばれる製品は多々あるが、そもそもワークフローが備えるべき機能とは何であろうか。J.H.Bairによると、以下が基本機能とされている。 (1)ワークフロー設計・開発機能 　　・ワークフローマップ作成機能 　　・組織、ルール定義機能 　　・タスク、アクティビティ定義機能 (2)ワークフロー実行・監視機能 　　・ワークフロー実行モニタリング機能 　　・実行ステータス表示機能 　　・稼働データ自動収集機能 (3)ワークフロー実績分析・評価機能 　　・稼働実績データの集計、解析機能（時間、コスト） 　　・モデリング、シミュレーション機能 　最近の情報技術への対応として、Webサービスを中心としたシステム連携やEXCELなどのデータの取り込みなど付随的な機能も求められるであろう。しかしながら、業務改善を行うために重要な機能として、稼働データの自動収集や、分析・評価、シミュレーション機能はどうしても必要な機能である。 http://www.innova-bp.co.jp/2009/09/post_86.html http://www.innova-bp.co.jp/2009/09/post_86.html プロセスモデラーブログ Tue, 29 Sep 2009 15:30:35 +0900