#2.もうひとつのＱ

もうひとつのＱ

ＳＡＰプロジェクトの場合、前回の記事で扱った、
本来のプロジェクトの目的を達成するためのＱ（スコープ）のほかにもうひとつのＱ（スコープ）があります。

それは、
各部門の現行業務をささえる現行システムの機能保証です。

各部門から選ばれた各領域の代表たる有識者は、それぞれの立場から現行システムとＳＡＰの機能との差分を指摘し、アドオン対応を要求します。

これらが、
本来のプロジェクトの目的を達成するためのスコープとは別の、
ＳＡＰプロジェクトのもうひとつのスコープ（Ｑ）になります。

こうして、
本来のプロジェクトのスコープを決めるべき部門不在のまま、ＳＡＰの導入そのものが目的となり、それに加えて各部門のシステムの現行機能保証という、本来とは別のスコープがプロジェクトのスコープになり変わっていきます。

「目的の共有」というマジックワード

こうした状況に対して、
一般的にはＳＡＰ導入の目的を関係部門で共有しましょう。との対策がありますが、残念ながら「目的の共有」だけでは組織は機能しません。

なぜでしょうか。
それは組織はそれぞれの組織に課せられた責任（ＫＰＩ）で動くからです。

ＳＡＰプロジェクトの場合、
各部門は全体的な目的を共有すれば理解は示しますが、
それと引き換えに自部門のデメリットを簡単に受け入れることしません。

なぜならば、
自部門の業績に対する責任（ＫＰＩ）はありますが、
プロジェクトの全体目標に対する責任（ＫＰＩ）はないためです。

それでも、
プロジェクトにおいては関連部門間で「目的を共有」することで、プロジェクトがうまくいくとうお話になりがちです。でも、それは残念ながら、おそらく幻想でしかありません。

各部門の意見は、総論賛成、各論反対。となります。

過剰なスコープ

各部門が要求する現行システムの機能保証について、
大抵の場合、現行システムは何年も、何十年も現場のノウハウを含めて積み上げてきたものであるため、ＳＡＰの標準機能がそれらを充足することはまずありません。

かといって、
すべての不足機能をアドオンでつくり、何度も予算と期間をかけて仕上げてきている現行システム相当の機能をいきなり充足することは、そもそも現実的に不可能です。

ではどうすればよいのでしょうか。

どうやって、
アドオンすべき機能と、そうでない機能（実は無駄な機能）を見分ければよいのでしょうか。

競争優位

ＳＡＰの標準機能の範囲をいわゆる「非競争領域」とすると、ＳＡＰと現行システムのＦiＴ&ＧＡＰで抽出されるＧＡＰには、「競争領域」の機能が含まれています。

ただし、
その中にはたまたま違うだけ、足りないだけの機能も含まれています。

では、
どうすれば、ＧＡＰのうちのどれが競争優位につながる残すべき機能なのかを見極めることができるでしょうか。

実は、
同じ会社の中にずうっといるメンバーにとっては、他社の状況と比べたことがないため、現場の有識者も熟達者も、何が他社に比べての優位性につながる業務なのか、システム機能なのかを識別することは意外に難しいのが実態です。

多くの場合は、
受注（得意先優先引当など）や出荷、納品（特別な荷姿対応など）などの顧客接点に優位性がある可能性が高いですが、見積もりや製造、在庫管理など、さまざまなプロセスにも優位性が潜んでいる可能性があります。

では、
どのようにすれば、自分たちの競争優位性、すなわちアドオンで残すべき機能を特定することができるのでしょうか。