特集◎経営課題としてのIT システム開発 失敗の要因と 成功への処方箋 著者:松本 渉 1 .システム開発はなぜ失敗するのか ? が、ユーザー のニーズに応 えきれず、結局 使 用されない システムとなってしまった システム開発の失敗事例が後を絶たない。実際弊社のクラ − C 社は業 務 の 効 率化を目指し、ERP を導入。しかしシス イアントから見 聞きするシステム開 発 案件を想 起しても、所 テム構 築 途 中及び 構 築 後 に様 々 な 業 務 の 非 効 率 が 判 定の予算内で、当初の期限内に、本来の目的(業務効率向上、 明。再度 業務 改 革を行おうとしたが、当該システムに縛 コントロール強化、コスト削減など)を十分に果たすシステム られ、十分な成果が挙げられなかった 開発を実現した事例はむしろまれといってよい。 具体的には以下のような失敗事例がある。 − D 社は 17 億の 資 金を投じて新システムを構築。しかし、 業 務 の 理 解 が 不十 分 な ま ま ベ ン ダ ー が DB の 設 計 を 行 った ため、極 度 に 複 雑 な DB 構 造となり処 理 速 度 に • 予算超過 − A 社は開発 予算を10 億としてシステム開発を発注。しか 著しい 問 題 が 発 生。結 果として使 用さ れ な いシステム となった し製 造 工程でベンダー 側が当初 予定の 3 倍に及ぶ大 幅 な増員を行い、コスト拡大を要求された。同時期に重要 • 開発遅延 な要件に関するベンダーとの理 解の齟齬が判明し仕様 − E 社は開発期間を14 ヶ月と設定して業務システムの構築 の変更・拡大を行ったこともあり、上記大幅増員に関する を 開 始。しか し ベ ン ダ ー の 成 果 物 に 対 する 社 内 の レ ベンダー側の落ち度を特定できず、コスト交渉に失 敗。 ビュー、及び関係部門間の意見調整が大幅に遅れ、8 ヶ月 結局 7億の予算オーバーとなってしまった の遅延につながった − F 社は大手 ITベンダーにシステム開発を 発注したが、製 • 成果の未達 − B 社は社内ユーザーの声を集めてシステム構築を企画し クボックス化。表 面 上は順 調 な進 捗 を 報 告されていた たが、盛り込むべき要件があれもこれもと増幅し予算内 が、試験工程直前にプロジェクト・マネジャー(PM)から での開発が困難と判明。その 後要件 の 絞 込 み のための 大幅な遅延を突如告知された。ベンダーに依頼し PM を 社内調整に難航し、所定の開発期間を大幅に超過。最終 変更したがその後も同様の問題が発生。結局半年の開発 的にはシステム部門主導で大幅な要件絞 込みを行った 遅 延となった この文書は旧ブーズ・アンド・カンパニーが PwCネットワークのメンバー、Strategy& になった 2014 年 3 月 31 日以前に発行されたものです。詳細は www.strategyand.pwc.com. で ご確認ください。 造後 工程でベンダーの下請け業 者の 作 業内容がブラッ Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 17 松本 渉(まつもと わたる) ([email protected]) ブーズ・アンド・カンパニー 東 京オフィス のシニア・アソシエイト。小売、消 費 財 等 の各種産業において、海外戦略、ブランド 戦 略、業務改革、プロジェクトマネジメン トサポート(システム開発含む)等多様な 案件をリードしている。 図表1 : システム開発失敗の直接的要因(落とし穴)例 要件定義 設計 − システム開発目的と要件の乖離 − 優先順位が不明確なことによる 要件の拡大 − 論理的に不明確で開発不能な 設計文書の作成 製造・試験 − 技術的に不可能な要件の発覚 − ベンダーの下請け業者などの進捗の ブラックボックス化 − 重要な要件の定義漏れ − 成果物のバージョン管理の不徹底 (『先祖がえり』の発生: 古いバージョンをベースに作業が進む) − 他のプロジェクトとの要件の 調整漏れ − ベンダー側の人員大幅増による PMのコントロール機能低下 − テスト計画の抜け漏れ − 論理的に不明確で開発不能な 要件の設定 − ベンダー成果物に対するレビュー工数 不足 − ベンダー成果物に対するレビュー工数 不足 − 顧客企業とベンダー間の要件に関する 意識齟齬 − ベンダーからのコスト増大依頼への 交渉材料不足 − 経営陣及び関係部署による 最終確認の段階での仕様変更依頼 − ベンダー側の人員大幅増によるPMの コントロール機能低下 大企業のシステム開発担当者にとってこれらは周知の失敗要因。 問題はもっと根深いところにあるのではないか? 出所:ブーズ・アンド・カンパニー分析 これらはいずれも社内ユーザーの声を集め、十 分な予算を いるのである。問題はもっと根深いところにありそうである。 確保し、大手といわれるベンダーを使 用しながら失 敗した事 図 表 2 は典 型 的 なシステム 開 発 の 失 敗 要 因を 因 果 関 係で 例である。満を持して取り組んだはずのシステム開発がなぜ 紡いだものである。各工程の随所に見られる失敗の直接的要 失敗に終わってしまうのであろうか? 因(落とし穴)は、実は、システム開 発 以前または川上 工程で の、ごく少数の要因に根源があることがわかる。システムベン 2 .3 つの根本的失敗要因 ダー側の要因が一つ、顧客企業側の問題が二つである。実際、 前述のいずれの失敗事例においても、これらの根本的要因の システム開発を失敗に導く落とし穴ともいうべき直接的要 一つまたは複数があてはまり、結局それが後工程でのトラブ 因は各工程の随 所に存 在 する(図表1参照)。これらは既に多 ルにつながり、システム開発を失敗に至らしめたのである。 くの書籍でも指 摘されていることであり、大 企業のシステム 開発担当者であれば周知の事実であろう。従って多くの企業 ①システムベンダーの「モラルハザード」 のシステム開発責任者はこれらの落とし穴に陥らぬよう入念 システム開発失 敗の根本的な原因の一つは、システム開発 な注 意を払ってシステム開発に当たっているはずである。し という事 業そ の も の の 特 性に起 因して生じるシステムベン かしながら、気がついてみるとこれらの 落とし穴にはまって ダーの「モラルハザード」である。 18 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 特集◎経営課題としてのIT 図表 2 : システム開発失敗の根源的要因とそれがもたらすインパクト(典型例) 根源的要因 インパクト ベンダーによる 非現実的な安値/ 非現実的な短期開発提案 ベンダーの モラルハザード 経営陣・関係部署との 開発目的の すりあわせ不足 経営/ITの橋渡し機能 の欠如/不足 不適切な RFP作成/ベンダー選定 社内体制 (レビュー要員等) の未整備 ベンダーによる 開発不可能な要件の 取り込み ベンダーによる 不当なコスト拡大要求 要件の肥大化 企業側の コスト交渉における混乱 (交渉材料の整理が困難) 要件に関する ベンダーとの意識齟齬 ベンダー成果物に対する レビュー不足 予算超過 成果の未達 仕様の大幅変更 要件定義漏れ プロジェクトマネジメント 機能の欠如/不足 ベンダー成果物に対する レビュー遅延 開発遅延 出所:ブーズ・アンド・カンパニー分析 システム開発事 業の特性の第一は「情 報の非対 称性」であ 「モラルハザード」に陥りが ちである。例 えば、交 渉 力の比 較 る。システム開発は専門的な知識や技 術を活用して行われる 的低い初期 段 階 やコンペ 段 階では、非 現 実 的な短 納 期や 低 ため、顧 客 企 業 側とベ ンダー 側 の 情 報レベ ル にどうしても コストを提案し受注を獲得しておき、交渉力が高まる開発後 ギャップが生じやすい(ベンダーが顧客企業よりも圧倒的に多 工程で何らかの理由を付けてコスト拡 大請求をする、という くの 情 報を抱えることになる)。しかも、そのギャップは開発 インセンティブが働きがちなのである。多くの場合、後工程で が進めば進むほど拡大する。 はシステム開 発 過 程 がブラックボックス化(「情 報の 非 対 称 第二の特性は「代替不可能性」である。システム開発は顧客 性」)しており、真のコスト拡大要因がベンダーの当初の甘い 企業の個別の業務に関わる複雑な要求に応えた「特殊仕様」 見積もりによるものなのか、企業側の落ち度によるものなの となることが多い(特に日本企業においてこの傾向が顕著で か 容 易に判 別しづらくなってしまってい る。 「今 更 他 の ベ ン ある)。このため、開発途中でベンダーの切り替えができない ダーにスイッチできない」という「代 替不可能性」も顧客企業 「代替不可能性」が生じてしまう。 側 を 更 に不 利 な 立 場 に 追 い やる。当 然、コ スト 交 渉 はベ ン 上記二つの特性すなわち「情報の非対称性」と「代替不可能 ダー側に有利に運びやすい。 性」ゆえに、後工程でベンダーは顧客企業に対して圧倒的な交 更 にこの 時 点 で 企 業 側 から の 仕 様 変 更 依 頼 や 企 業 側 に 渉 力を持 つに至ってしまう。このため、ベンダー 側 は一種 の 起 因 する 要 件 漏 れの 発 覚 な どが 生じることも 多く、複 数の Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 19 コスト拡大要因が渾然一 体となると、コスト交渉はベンダー 例えば、ある重要な要件漏れが発覚した場合に、直ちに、当該 側に圧倒的に有利となってしまう。多くのシステム開発が当初 要件を放 棄して開発を続けた場合と当該要件 の 追 加を行っ 予算を超過しがちなのは、このような要因によることが多い。 た場合とで、コスト面はもちろん、本来のシステム開発の目的 実際 上記 A 社の事例は、まさにそのような失 敗の典 型事例 にどのようなインパクトが出るのか、経営陣に分かる言 葉で である。製 造 工程段階でのベンダー側の大幅増員は、そもそ 説 明しなければ ならない。システム開 発 責任者は、経営面で もベンダー側が生産性を甘く見積もっていたことに起因する のスキルが不足し経営陣に十 分にそのインパクトを伝えきれ 部分が大きかったが、既にシステム開発を進めてしまった顧客 ず、問題を先送りにしてしまうことが多い。このような問題は 企業側の立場の弱さを突かれ、ベンダー側の莫大なコスト拡 後 工程になれば なるほど深 刻 度を 増し、そ の 結 末は莫 大 な 大要求に応じる結果となってしまったのである。 出戻りコストとして跳ね返ってくるか、結局本来の目的を達成 前述の F 社の事例もこのような事例の一つといえる。下請け できずに使 用されないシステムとなってしまうケースが多い 業者活用はしばしばトラブルの原因となることが多く、よほど のである。 注意をしてかからないと開発のブラックボックス化を招いて 前述の B 社の事例は、まさにそのような失 敗事例の一つで しまう。ひとたびブラックボックス化が起きると、ベンダーの ある。システム開発目的に関する経営陣との十 分なすり合わ コスト拡大要求に対する交渉材料がなくなってしまい、不利な せがなされなかったために、社内ユーザーとの意 見調整に右 交渉を強いられることになるのである。 往 左 往し、結局システム部門主導で「システムありき」の開発 を行ってしまった。これが「作っても使われないシステム」に ②経営 / 業務とITの橋渡しを行う機能の欠如または不足 繋がってしまったのである。 システム開発失敗のもう一つの重要な根本要因は、顧客企 前述の C 社の 失 敗 事例も同様 の 根 源的要因に根ざしてい 業において経営とITの橋渡しを行う機能が欠如している、また る。企画段階において経営の 視 点が欠 如していたため、業務 は不十分であることにある。専門性が高く、かつ経営へのイン 効率向上という目的に照らしてシステムだけではなしえない パクトも大きいシステム開発においては、この機能が 極めて こと(業務そのものを見直すべきところ)の見極めができず、 重要であり、その欠如または不足は命取りとなりかねない。 業務 そのもの の再 構築という重 要なステップが 抜け落ちて 例えば、システム開 発 の 企 画 段 階では、経営 者がシステム しまった。また開発 段階でそれが発覚しても経営とのコミュ に期 待する真 の目的をきちんと汲み取り社内の関 係部 門と ニケーション が 不足し軌 道 修正に至らな かった。この 結 果、 の意 識あわせを行った上で、それらの 経営上・業務上の要件 「非効率な業務を強力にサポートするシステム」の完成という を ITの要件に落とし込み、社内のシステム部門やベンダーに 皮肉な成果に至ってしまったのである。 伝えることが極めて重要である。これが不十分になると、結局 D 社の事例も同様 の要因が根 源にある。専門 性の高い DB 具体的な「もの」が出てくる試験工程に至って始めて経営陣や 設 計にお いて、どのような 業 務 知 識 が 設 計に 必 要 かを見 極 社 内 関 係部 門から 根 本 的 な 問 題を指 摘され、大 幅 な 出 戻り め、ベンダーに過不足なくそれを伝えるには相当の IT・業務の を生じてしまうことになりかねない。 双 方の知 識が必要である。D 社にはそのような人材が 不足し また、開発開始後の諸工程では、ベンダーの提案やシステム ていたため、実際の業務とはかけ離れた使 用不可能な DB 設 上の問題点、リスクについて経営へのインパクトを早期に察知 計に至ってしまったのである。 して分かりやすく経営陣に伝えることが 極めて重 要である。 20 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 特集◎経営課題としてのIT 図表 3 : PMOのミッションの例 企画 要件定義 − システム開発の目的に関する 経営陣、システム開発責任者、社内関係 部署とのすり合わせ − 定義された要件と本来の開発目的との 照合による、要件漏れや不要な要件の 抽出 − 開発プロジェクトに必要なスキル、 人員規模の見積もりと人員確保に向けた 関係部署との調整 − 定義された要件の技術的実現性 についてのベンダーの計画の検証 − システム開発の目的に沿った ベンダー選定基準の作成および ベンダー選定案の提示 − 現実的かつ合理的な開発規模、 プロジェクト予算、スケジュールの設定、 およびベンダーとすり合わせ 設計・製造・試験 − レビュー工数の見積もりに基づく スケジュールの詳細化/アップデート − 問題が生じた場合のインパクトの 見積もりと経営陣への報告 − 生じた根本原因の究明と打開策の提案 − レビュー工数の見積もりに基づく スケジュールの詳細化/アップデート − ベンダーからコスト拡大要請が生じた 場合のコスト交渉 − 要件定義前後のベンダーの コスト見積もり差異について 妥当性の検証 − 定義された要件の骨子を 一般的用語に「翻訳」し経営陣および 関係部署に伝達 出所:ブーズ・アンド・カンパニー分析 ③プロジェクトマネジメント機能の欠如または不足 品質リスクやレビュー遅延による開発遅延を防止する必要が システム開発失敗のもう一つの重要な根本要因となりうる ある。これらの能力を備えた人材が十分に配置される例は少 のは、顧客企 業側のプロジェクトマネジメント機能の 欠 如ま なく、重要な失敗要因の一つとなっているのである。 たは不足である。失敗している企業の例を見ると、プロジェク 前述の E 社の事例では、これらのプロジェクトマネジメント トマネジメントは「ベンダーの 仕事」と捉 え、全てをベンダー スキル を 備 え た 人材 が い な い こと が 失 敗 の 根 源 的 要 因と 任せとしてしまっているケースが多い。しかしながら、当該機 なった。同スキルの不足により、自社のプロジェクトメンバー 能はベンダー、顧客企 業 双 方に必要であり、両 者のすりあわ のレビュー工 数を見誤り、結果として自社のレビュー 遅 延 が せを 通じてこそ、プロジェクトを期限内で完 遂することが で 開発遅延に繋がってしまったのである。 きるのである。 例えば、企画段階では、顧客企業側も開発規模や難易度を 3.成功への処方箋−三つの要件を備えたPMO の設置 合理的に見 積もった上で、社内のどのようなスキルの人材を どの程 度プロジェクトに配 置するかを決 定し、必要なリソー システム開発を成功に導くには、上記三つの根本的な失敗 スを確保することがきわめて重要になる。多くの 企業ではこ 要因に対処することが不可欠である。具体的には、以下の三つ れ が 行われない、もしくは不十 分であるため、ベンダー の成 の要件を備えた組織 / 機能( PMO=プロジェクトマネジメント 果 物 に 対 するレビュー に十 分な 工 数 が 取 れ なくなり、ベ ン オフィス)をシステム開発プロジェクトの企画・立ち上げ段階 ダーのモラルハザードを助長して開発リスクが増大するだけ から組み込み、ベンダーとの交 渉、ベンダーモニタリング、社 でなく、開発遅延にもつながるケースが見られる。 内関係部署の調整、経営陣とのコミュニケーション等々の任 また、開発開始後の諸工程では、ベンダーのスケジュールの 務に当たらせることが必要である( PMO の具体的な任務は図 現実性・合理性を客観的に吟味し、遅延リスクを事前に除去し 表3 参照)。三つの 要件はいずれも必須 要件であり、いずれか たり、実際にリスクが顕在化した場合に問題の真因をいち早 一つを欠いても成功は望めない。 く掴んで損失を最小限に食い止めることが重要である。更に、 自社のプロジェクトメンバーのレビュー工数などを合理的に PMO が備えるべき要件 1:ベンダーからの独立性・中立性 見積もりスケジュールに組み込むことで、レビュー漏れによる システムベンダー のモラルハザードを防止するには、特 定 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 21 のベンダーと利害関係・依存関係を持たず 独 立的・中立的な とは異なるベンダーを選択する結果となったケースが多い)。 視点から開発ベンダーを選定し、ベンダーの開発進捗をモニ またベンダー 側に必 要な情 報を整 理して提 供しないまま提 タリングする機能が不可欠である。しばしば「 PMO は発注先 案書を書かせ評価するケースも多く、そもそも客観的な評価 のベンダーが設置しているので我々は必要ない」というコメ が困難となっているケースも見受けられる。このような場合、 ントが聞かれるが、発注先ベンダーの PMO だけでは中立性・ 従 来の取引経 験から情 報 量に優る既存 ベンダーが過 大評価 独 立性の 観点で明らかに不十 分であり、ベンダーのモラルハ されるのはいうまでもない。 ザードは防止できない。顧客企業は自らベンダーから独 立し また開発段階でも、 「 信頼ベース」でベンダーの客観的進捗 た PMO を組成する必要があるのである。 管 理を怠り、開 発 がブラックボックス化してしまうケースが 例えば、入札 時点では幅 広く候 補 ベンダーを洗い出し、特 みられる。 定の候 補ベンダーの論理に流されることなく、各ベンダーの 社 内 の人材を PMO に活 用するのであ れば、システム部 門 コスト・開発期間の見 積もり根 拠 の客観性・合理性を 公平に 以 外の人材の活用も視野に入れるなど、中立性を担保するた 吟味する必要がある。入札時点ではベンダーと顧客企業側に めの工夫が必要となるのである。 は情 報ギャップが生じておらず(または顧客企業の方が情 報 優位である)、かつ「代 替可能性」も顧客企業側に確保されて PMO が備えるべき要件 2:経営とITの両方の知見 いるため、ここでしっかりとした 見 積もりの前 提 条 件を双 方 PMO が経営 / 業務とITの橋渡しを行うためには、経営とITの で合意してしまうことがその後のベンダー側のモラルハザー 両方の 知 見を備え、経営者や社内関係部 署とシステム部門、 ドを防止するのに極めて有効である。 ベンダー の それぞ れに的 確にコミュニケーションを 行える また開発過程では、進捗度合いの判定をベンダー任せにせ 人材の配属が不可欠である。 ず、ベンダーと顧客企業側双方が理解しうる客観的な指標を システム開発を成 功に導く強 力な PMO 機能を担保するた 用いて開発の進 捗をモニタリングし、情 報ギャップを最小限 めに、もっともハードルが 高い のがこの 要件である。社 内は に抑えることがモラルハザードの防止につながる。 おろか、社 外においても、そのような人材、組 織は決して多く なお、ここで更に注意しなければならないのは、社内のシス はないからである。 テム部門の人材だけでは必ずしも中立性を担保できない場合 例えば、前述の「ベンダーからの中立性」という要件を満た があるということである。システム部門では、従来から付き合 すためには、開 発 発 注 先 以 外 のシステムベンダーを 起 用し、 いのあるベンダーを過大評価し、かつ依存しがちだからだ。 他のベンダーを中立的に選択させ、その進捗をモニタリング す な わち、ベンダー 選 定の段 階にお いて、ベンダー のコス させれば 事足りるかもしれない。しかしながらシステムベン ト・開発期間の見 積もりの客観性・合理性よりも従 来の付き ダー の 多くは、 「 経 営とITの 両 方 に 知 見 の あ る人材」が 不足 合いやコミュニケーションのし易さなどに偏った評価を行い、 し、経営 者とのコミュニケーションが 不十 分となることが 多 ベンダー選択を誤ることが多い(ブーズ・アンド・カンパニー い。特に経営者がシステムに期待する真の目的を ITの専門的 がサポートしたシステム開発 案件では、システム開発の目的 な要件に落とし込む 能力や、システム上生じた問題 点やリス を 十 分に整 理し ベンダーに 必 要な要 件 をインプットした 上 クを経営へのインパクトに翻訳して分かりやすく伝える能力 で、コスト・開 発 期間の見 積もり根 拠 の詳 細を入手してそ の が 不足しているために結 局 本来 の開 発目的から外 れたシス 客観 性・合 理 性を徹 底的に吟味したところ、従 来 の ベンダー テム開発に至ってしまうケースが見られる。 22 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 特集◎経営課題としてのIT 結局、社 外からそのような希少な人材を探し出して採用す るか、社内において中長 期的な視野を持ってそのような人材 を育成するしかあるまい。しかし、それまでの間システム開発 その根本原因を究明する能 力(「『なぜ』を 5 回繰り返せる」 知的タフネス) − 生じた問題に対 する対処 方法について考えられるオプ を凍結させるわけにはいかないし、そもそも社内の誰もが持 ションを網 羅 的に洗い出し、それぞ れのインパクトを、 ち合わせていない能力を育成するのは難しい。 定 量・定性の両面から客観 的に評価し最 善 の解決 策を このような場合には、特定の開発ベンダーと利害関係がな 導き出す能力 く、経営とITの 知 見に長けた 外部コン サル タントを 活 用し、 一旦 PMO 機 能を担わせ、徐々に社内に知 識 移転を図ること も有効な手段と考えられる。 • コミュニケーション能力 − 社内の 合意 形成に向け最 大 限の効果を得るために、適 切なタイミング で、適切な人物にアプローチし、適切な PMOが備えるべき要件 3:高いプロジェクトマネジメント能力 方法(説得 / 交 渉 / 報告 / 指示)で情 報を伝 達できる能力 プロジェクトを期限内で完遂するためには非常に高いレベ − ベンダーと利害が一致する論点と対立する論点を峻 別 ル のプロジェクトマネジメント能 力が必要である。特に注 意 し、それぞ れに適した 交 渉 方 法とテクニックを 使 い 分 すべきなのは、ここで必 要な 能 力は、一 般にシステム開 発に ける能力 おいて挙げられる狭 義 のプ ロジェクトマネジメント力(スケ ジュール設 計/ 管 理 力、調整 力など)よりも広い範囲をカバー これらの能力も「経営とITの両方の知見」ほどではないが、 する能力であるという点である。それはあらゆるタイプの難易 容 易に見出したり育成したりしうる能 力ではなく、ロール モ 度の高いプロジェクト(システム開発 以 外 のプロジェクトを デルとなりうる人材を核にして実践を通じて中長期的に知識 含む)を推 進していくために共 通して必要となる広範囲かつ 移転を図ることが必 要である。このような 観 点から、一時的 高 度 なマネジメント力であり、例えば以下のようなスキルが に社 外 の人材や 組 織を 活 用して PMO に当たらせ つつ、徐 々 あげられる。 に知識移転を図っていくことも有効であろう。 • 論理力 − システム 開 発にお いて本来 達 成 すべき 経営目的(業 務 効 率 化、コスト削 減、コントロール 強 化、等 々)から、ベ ンダー 選 定のクライテリア、業 務 / システム 要件 などを 論 理 的に過 不足なくブレイクダウンし、プライオリティ 付けできる能力 − 各工程において達 成すべき成果 物から、必要なタスク、 人材、工数を論理的に過不足なく抽出する能力 • 問題解決力 − 生じた問題の表層部の「火消し」に奔走するのではなく、 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 23
© Copyright 2024 Paperzz