なんとなくTwitterで軽く書き捨てとこうと思って書き始めたら、全然収まらなくなってしまい、下書きして連投みたいなのもガラではないので、こっちのブログの方に書いておく事にしました。
ERPもクラウドとかSaaS型のものが増えてきて、標準外で行う、いわゆる「アドオン」も、実装には制約が多くなっているんで、あらためて「できるだけ標準に業務を合わせよう」っていう事が色々なプロジェクトで言われている気がする。いやまあ、昔からスローガン的には、ほぼ同じ事を言っていると思うが、SaaSだどOSやミドルウェアのレベルに追加の仕込みができないので、オンプレミスの時ほど自由度高く気軽にアドオンの実装はできないっていうのが実態だったりして、SaaSのコアはしっかり使いつつアドオンする事のハードルが上がっているという側面もあるかなと思う。
そういう事の代わりになのか、SaaSの中にそれなりのカスタマイズ対応できるツールや仕組みを備えるようになってきていて、実質は専用の開発ツールがバンドルされている、と言えることになる。そうすると、「この要件は、標準でバンドルされたそのツールで作れば対応できる。」→「この要件は標準で対応できる。」みたいな売り方・提案のされ方が観測されたりする。
でまぁ、これも昔から同じような話はあったはずだと思うが、改めて思うのは、ERPの導入で「なるべく標準に合わせるようにした方が全体としてコストが抑えられる」って話のはずが、個々の細々とした要件毎に「標準の範囲で対応できると言えれば追加コスト不要」みたいな理解や取決めに魔変換されがちなんだよね。これは、なんとかならんものかね?
そりゃあ、SaaSベンダーに払うサブスク料金とかライセンス料金は追加されないだろうけれども、SI的には普通に要件増えたら、単純なものであっても、その設定してテストしてって工数はかかるわけで、アドオンを作る程ではないとしても、現場的にはコストはかかるんだよ。そして、それらは一つ一つは小さくても積み重なればそれなりモノになる可能性もある。まして、さっきの「バンドルされた開発ツール」での対応はもちろんの事、色々なケースに対応できるように抽象化された機能の場合、その設定パラメータ群をデフォルト設定とは変えて実際の業務要件に合うようにするには、相当な知見や工夫と検証が必要になる事もままあるんだよね。それでもアドオンで何か作るよりはマシだからやるんだけど、結果としてこれは「標準で対応できた事になるから無料」みたいな感じになってしまうのは、色々詰め込まれている中では、なかなかやるせない気持ちになる事がある。まあ気持ちの問題であれば、そういう知見の積み重ねも単価に込めていると考えておけばいいと思うが、現実に「コスト増加」って話を客側に持ってかざるを得ない時は「標準対応と言ってたのになんで追加コスト?」みたいな感じで理解されない。
まぁ、ファンクションコンサルをミニマムでアサインした場合の固定料金は設定せざるを得ないとして、その上でさらに標準機能の範囲であっても、設定やテスト作業として許容範囲を測る指標を持って、それを超えたらまたなんらかの基準で追加課金(見積)の対象にするとかなのかなぁ?でも、それで精緻な基準を作るのも大変だし、結局は客側に理解してもらえなくて、シンプルに「アドオン/カスタマイズ扱いは追加コスト要」、「1本あたり○○万円」みたいなのがお互いにやりやすいのかねぇ?
そうだとすると、「何をアドオン/カスタマイズ扱いにするのか?」の定義の問題になってくるんで、提案の段階から一貫した基準で扱って、デリバリーのプロジェクトの段階で困らないようにして欲しいものです。提案の段階から関わって、意見が言えるようになれればいいんですけどね。
道は険しい。
ERPもクラウドとかSaaS型のものが増えてきて、標準外で行う、いわゆる「アドオン」も、実装には制約が多くなっているんで、あらためて「できるだけ標準に業務を合わせよう」っていう事が色々なプロジェクトで言われている気がする。いやまあ、昔からスローガン的には、ほぼ同じ事を言っていると思うが、SaaSだどOSやミドルウェアのレベルに追加の仕込みができないので、オンプレミスの時ほど自由度高く気軽にアドオンの実装はできないっていうのが実態だったりして、SaaSのコアはしっかり使いつつアドオンする事のハードルが上がっているという側面もあるかなと思う。
そういう事の代わりになのか、SaaSの中にそれなりのカスタマイズ対応できるツールや仕組みを備えるようになってきていて、実質は専用の開発ツールがバンドルされている、と言えることになる。そうすると、「この要件は、標準でバンドルされたそのツールで作れば対応できる。」→「この要件は標準で対応できる。」みたいな売り方・提案のされ方が観測されたりする。
でまぁ、これも昔から同じような話はあったはずだと思うが、改めて思うのは、ERPの導入で「なるべく標準に合わせるようにした方が全体としてコストが抑えられる」って話のはずが、個々の細々とした要件毎に「標準の範囲で対応できると言えれば追加コスト不要」みたいな理解や取決めに魔変換されがちなんだよね。これは、なんとかならんものかね?
そりゃあ、SaaSベンダーに払うサブスク料金とかライセンス料金は追加されないだろうけれども、SI的には普通に要件増えたら、単純なものであっても、その設定してテストしてって工数はかかるわけで、アドオンを作る程ではないとしても、現場的にはコストはかかるんだよ。そして、それらは一つ一つは小さくても積み重なればそれなりモノになる可能性もある。まして、さっきの「バンドルされた開発ツール」での対応はもちろんの事、色々なケースに対応できるように抽象化された機能の場合、その設定パラメータ群をデフォルト設定とは変えて実際の業務要件に合うようにするには、相当な知見や工夫と検証が必要になる事もままあるんだよね。それでもアドオンで何か作るよりはマシだからやるんだけど、結果としてこれは「標準で対応できた事になるから無料」みたいな感じになってしまうのは、色々詰め込まれている中では、なかなかやるせない気持ちになる事がある。まあ気持ちの問題であれば、そういう知見の積み重ねも単価に込めていると考えておけばいいと思うが、現実に「コスト増加」って話を客側に持ってかざるを得ない時は「標準対応と言ってたのになんで追加コスト?」みたいな感じで理解されない。
まぁ、ファンクションコンサルをミニマムでアサインした場合の固定料金は設定せざるを得ないとして、その上でさらに標準機能の範囲であっても、設定やテスト作業として許容範囲を測る指標を持って、それを超えたらまたなんらかの基準で追加課金(見積)の対象にするとかなのかなぁ?でも、それで精緻な基準を作るのも大変だし、結局は客側に理解してもらえなくて、シンプルに「アドオン/カスタマイズ扱いは追加コスト要」、「1本あたり○○万円」みたいなのがお互いにやりやすいのかねぇ?
そうだとすると、「何をアドオン/カスタマイズ扱いにするのか?」の定義の問題になってくるんで、提案の段階から一貫した基準で扱って、デリバリーのプロジェクトの段階で困らないようにして欲しいものです。提案の段階から関わって、意見が言えるようになれればいいんですけどね。
道は険しい。