核となる業務、核とならない業務

先のエントリにid:kensir0uさんからコメントを頂いた件、返信が長くなったので改めて。

＞業務を業界標準的に近づけて特定システムへの依存を減らすってのもありでしょう。
これは当初自分も考えていたんですが、会社は慈善事業ではないので差別化、もしくは区別化を行う必要があります。
業務効率が悪い会社が良くしようと思って業界標準のシステムを導入したとしてそれはようやく平均的な売り上げの業務体系になっただけです。むずかしいのがそのような会社が業界標準の業務になれるのにどのくらいかかるのかってところですかね。業務を（無理やりも含む）変えてなれるまで何年かかるのでしょう？
業務と実装を分離できる？ - @katzchang.contexts id:kensir0uさんのコメント

その企業の核となる業務であれば、独自システムで差別化を図るのは良いと思います。が、それ以外の業務（例えば財務や人事、文書管理や決済業務など）では、差別化するメリットはほぼないです。標準より効率が良いと本当に確信しているならともかく。標準化のターゲットはその核とならない業務です。

核となる業務では、当然顧客は業務内容について最も詳しいはずで、外部の人間が具体的にアドバイスできることはほぼないはず。逆に核とならない業務では、顧客はアドバイスを求めるでしょう。業務知識が必要になるのは顧客が知識を持っていない業務だと考えると、最近の「業務知識vs構築技術」議論の落し所が見えてくるような気がします。核となる業務までアドバイスしてキンタマを握りに行って囲い込むとかって、それは本当に顧客のためになっているのか…。

どの業務を核として捉えるかは顧客企業の経営判断と考えていいと思います。要件定義は業務担当者と合意するのが一般的でしょうが、このやり方では、業務担当者に対する打合せのみでは答えは出ないと思います。業務担当者にとって、その業務は自分の核となる業務ですからね。

で、いざ変えるとなれば、仰る通り、計画は最低1期を超える中長期計画として捉える必要があると思います。導入したシステムが本当は使いにくかった！となるリスクをどう管理するかも大きな課題です。もっとも、0から開発したとしても使いやすいシステムが出来上がる保証もありませんが…。標準化しても、特定ベンダに依存したらメリットは少ないでしょうし、SI屋（特に大手）には上手く提案できないだろうと思います。

その辺りへの答えはオープンソース化にあるような気がします。…ってのが最近の思い付きなんですけど、どうなんでしょうかねぇ。