ITプロマネのブログ

IT業界、プロジェクトマネージャーのブログ

システム開発とBPR

システム開発案件の説明会に出席した。

こんなシステム開発があり、こんな技術者を必要としているという説明を聞く。
私どもは手持ちの技術者リストを見ながら適合する案件があるかを判断する。
システム開発に必要な技術者のスキル、技術者を必要とする時期、単価などが噛み合えば、契約に向かって動き出す。

案件を紹介していただいたユーザの営業と話をした。

f:id:one_piece_of_leaf:20170315151327j:plain


BPR経験の豊富な技術者を必要としているのですが、該当する人材はいるか聞かれた。
「BPR」とは、「ビジネスプロセス・リエンジニアリング」(Business Process Re-engineering)の略で、企業などで既存の業務の構造を抜本的に見直し、業務の流れ(ビジネスプロセス)を最適化する観点から再構築することだ。
いわゆる業務改革と同義と思うが、より抜本的な改革の場合にBPRという言葉を使うようである。

私は基幹業務システムの構築経験があるが、そもそも基幹業務を構築する前提にBPRがあると思っている。ただ、現行のビジネスフローに合わせたシステムを構築することは全く意味がないと思う。日々の業務は常に変化し続ける。すなわち、ある時点で整理したビジネスフローは、日増しに崩れていくことになる。そして、これでは効率が悪すぎると判断できる時点が来る。その時に、ビジネスフローの再構築をすることになる。つまり、ビジネスフローは再構築し続けるものだ。再構築した後にシステム構築をする。ぐちゃぐちゃに崩れたビジネスフローを元にシステムを構築すれば、システム自体もぐちゃぐちゃになる。整理し再構築したビジネスフローをもとにシステム構築すればすっきりしたシステムになる。

もちろんすっきりしたシステムの方が安くできる。システム構築には大変なお金がかかる。数億から数百億ものお金がかかることは日常茶飯事だ。こんなに多くのお金をかけるのだから、まずはすっきりとビジネスフローを再構築するべきだ。
ところが、日本の開発ベンダーは儲けることばかり考えていて、再開発することしかユーザに勧めない。それも少しでも開発費用が高くなるように。そもそもBPRの概念自体持っていない営業が多いこと、これが根本的な問題なのだろう。
システムエンジニアも同様だ。システムの設計手法云々の前に、BPRに対する考えをしっかり持つ必要がある。基幹業務システムを担うSEは技術マニアな技術者では勤まらない。

そこまで考えている技術者が必要なのだと、持っていた技術者リストを見直してみたが、いなかった。とくとくとユーザの営業にあるべき論を語って聞かせ、墓穴を掘った。恥ずかしかった。
社長失格、これから社員教育しますと、心に誓って会場を後にした。