Re: コンサルタントの仕事の範囲

私はパラメーターをいじるだけの人はカスタマイザーと呼びます。
まだまだコンサルタントとは言えませんね。
Junさんのそばにいる人は、ジュニアコンサルかなんちゃってコンサルです。なんちゃってコンサルはもうそろそろ消える運命でしょう。
さて巷で言われているSEとERPコンサルタントの違いとは何か?ですが
先ず、「ERPコンサルタントは、標準機能を理解して、作りこみによる工数を削減すべく客先要件を標準機能で実現できることを説明、デモ(プロトタイピング)できること」でしょう。当然この仕事ができるまでには、何度もさまざまな要件においてIMGをいじくり悩みぬいて、「できる」「できない」が正確に明確にしゃべれる技術を身に付けてなければなりませんしその業務に精通していなければ客先との打ち合わせにもついていけないしょう。ユーザーが何をしたいのかという気持ちも理解しつつ、時にこの会社の全体最適性を考えたり、費用対効果のことを考慮してバランスのとれた実現すべきシステムの提案もできなければなりません。
また、ERPの導入方法の特徴的なものというと、は標準カスタマイズでさくっと動かして「やりたいのはこういうことですよね」といったデモ(プロトタイプ)をユーザーに見せること。です。
スクラッチSEさんも要件定義はいつもの仕事かと思いますが通常ウォーターフォール型導入方法で書類上でいつも業務プロセスフロー、要件定義書、基本設計書で進めていますよね。でもユーザーはそれでは完全に理解できていなく、完成した後で「仕様が違う」「機能が漏れてる」「こんな例外があったんですよ」というのがでてきてカットオーバー直前でごたごたするハメになっている、いつも経験していませんか?
ERP導入ではスパイラルに段階詳細化していき製造工程で「完成系を見せて業務に落とし込む」ことで、より考慮漏れを洗い出すことできるのです。それができるのがERPであってERPコンサルです。当然ユーザーにちゃんと理解してもらえるように説明できるということもスキルです(これ簡単そうで結構難しいですよ)
あと期待したいスキルといえば、当然アドオンはつきものですからSEと同様に業務プロセスフロー、要件定義書、基本設計書は必須ですし拡張機能Exit程度のコーディングくらいはこなしてほしいし、テストは徹底的にバグをつぶす緻密さと根気はあって欲しいし、本稼動まで責任もってユーザーのサポートをし新システムを運用に載せるまでがコンサルの仕事であるべきかと思いますけど。