さて、GUTSY-4開発へのきっかけ、ビジネスアナリシスを「エンジニアリング」にせねばならない!という強い思いについては、すでに述べました。では具体的に、ビジネスアナリシスをどうエンジニアリングするか、実際に誰でも一定の成果を出せるような方法論にできるのか、以下の3つのことに悩み悩んで、GUTSY-4と業務参照モデルを開発しました。

 1. プロセス階層レベルに沿って、「トップダウンとボトムアップの融合」を実現させる

  長年、ERP導入の現場を見てきましたが、 ERP導入が成功するのはきわめて難しい。その理由は、経営層と現場の間がつながっていないからです。ある大手製造業では、ERPを導入する時も、経営トップ層は「決断したのだから細かいことはうまくやってくれ」、一方現場のボトム層は「ERP導入によって会社がどのように良くなるのか教えて欲しい」、その間が大きく途切れていました。

  現場のボトム層は「上記のことを明示してくれれば、残業が増えても文句は言わない」と意識が高いのにも、誰もそれを提示しない提示できないので、現場は抵抗せざるを得なくなる。最初から抵抗する気はないのにです。その結果、日本企業のERP導入ではアドオン開発が非常に多くなってしまいました。たとえば、日本国内の売上はグローバル全社の1/3しかないのに、日本でのERP導入費用は全社の2/3を要するという企業もありました。

  経営トップ層の曖昧な指示を現場のボトム層からの提案によって具体化できるようにするためには、社長、事業部長、部長、課長、係長、担当者という企業の組織階層、すなわちプロセス階層レベルごとに、「トップダウンとボトムアップを融合させていく」ことしかないと思いました。また、逆に、これが日本企業の強みになれると信じました。

  ⇒ブログ記事:GUTSY-4によるトップダウンとボトムアップの融合

  そして、日本人が苦手な階層性を理解するためには、SCORなどのグローバルスタンダードなプロセス参照モデルに頼ればよいと考えました。

2.業務スキルについては、業務参照モデルによってカバーする

  ビジネスアナリシスを行うためには、対象領域の業務スキルが不可欠となります。しかし、経験によって業務スキルを養成するためには、相当の年数を要してしまいます。そして、自社の業務スキルに関しては、日本の現場のボトム層はある程度、高いレベルにあります。したがってビジネスアナリストには、その現場とコミュニケーションできる一般的な業務スキルがあれば良い。したがって、充実した「業務参照モデル」を備えて、これによって業務スキルをカバーして、ファシリテーションすれば良いと考えました。

  そして、「トップダウンとボトムアップを融合させていく」ためのプロセス階層レベル、これは業務参照モデルにおいてプロセス階層レベルを明確に規定して、ビジネスアナリストはそれを抵抗せず受け入れれば良いとも考えました。現場の実務経験を長く踏めば踏むほど階層性とかプロセス階層レベルは受け入れ難くなってしまうので、抵抗せずそのまま受け入れるのです。

  と、ここまでは良かったのですが、SCORはレベル3までしかないことを知りました。レベル4は現場の係長クラスの仕事で、日本はこの現場での改善に強みがあるのに、その重要なレベル4の参照モデルがない! ではどうするかを悩み悩んで、「無いんだったら私が開発しよう」と決意しました。この経緯については、別のところで述べますが、8年間かけてプロセス参照モデルを拡張した「業務参照モデル」を開発しました。 

  ⇒ブログ記事:業務参照モデルの概要 

 

3.厳密で完成度の高いWBS/アクティビティを持つ方法論にする

  私自身は数学を専攻したSE出身のコンサルタントなので、方法論を厳密にすれば、ビジネスアナリシスはエンジニアリングにできると信じました。したがって、GUTSY-4のWBS/アクィビティは、インプットとアウトプットを明確にして、そのレイアウトも厳密に規定しました。当然、自分のビジネスアナリシス経験を反映させて、何回もバージョンアップして完成度を高めたものです。

  WBSの基本的構造は、以下の4つの部分のアクティビティの4つの部分から構成されます。

①「インプット」に対するメッセージ受信と情報処理による処理

②抽象化、階層性の評価、構造化、フレームワーク利用と図形化による前段取処理

③論理思考/システム思考、レビューによる「アウトプット」作成処理

④アウトプットを情報処理してメッセージ送信する処理

  各々のアクティビティに説明・技法・ツール・リファレンス・事例を搭載して、経験が少なくとも初めてでも、ファシリテーションを含めて実行できるようにしました。これはPMBOKの膨大な「ツールと技法」からヒントを受けたものです。

  ⇒ブログ記事:WBS/アクティビティの構造例(補足)

  ここで一番大変だったのは、米国ならばCIOやシニアマネジャーが頭の中で行っている「構造化」、これを技法・ツールとしてどうエンジニアリングするかでした。これは、東京海上日動システムズ社の25歳の若者たちが実施できるレベルにまで達することができました。

  ⇒ブログ記事:構造化とは何か、戦略をビジネスプロセスに構造化する方法は? 

 

カテゴリ