- ベストアンサー
ERPのデメリット
会社でERPを入れようとか話題になっています。 ただ昔開発部隊にいたのでソースも開示されないし 維持費などを考えると社内で設計して(仕様変更が発生しないように) 外注でPGを借りてきて作ってしまった方が後々のため・・・ と感じるのですがどうでしょうか? グループウェア機能も持ちたいためいっそのこと余計な機能もなく 0から作ってしまった方がいいような気もするのですが・・・ DB設計さえしっかりしておけば音で簡単な物なら自分で付け加えることもできますし。 やや特殊な専門分野もあるのでERPをカスタマイズして費用がかさむより いいかと思うのですが。 あとはブラウザで動く物,javaであればあまり心配いりませんが windowsで動く物(VBなどでできている)場合OSのバージョンが上がると 動作保証せず、不具合発生などが気になります。 ERP経験がないのでこのように感じます、変でしょうか?
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
「ゼロから作れる」とはすごいですね。 ERPは、既製品ならでは導入の難しさがありますが、それは様々な方からアドバイスがあるでしょう。 そこで、手作りした場合との比較観点で注意点をご紹介しましょう。 *案外、基幹業務の仕組みは複雑では? ERPパッケージの会計モジュールだけで、150万step相当の規模があります。これを手作りするだけで開発規模:2年半は覚悟する必要があるのでは? ERPパッケージ開発だと、長くても1年半程度です。複雑かつプロジェクト失敗ともなると3年になってしまうこともままありますが。これはご自身の会社のユーザー参加検討率が高いかどうかで決まります。(派遣社員を入れてでも、ユーザー検討参加時間を確保することが必要ですが。) こんな大規模な機能は必要はないという考え方もありますが、結局「安物買いの銭失い。」とならないでしょうか? *モジュールをサービス機能で実装するSOA手法で開発する? いま旬な方法です。でも将来性をお考えというようには、文面からは読みとれませんでした。開発方法論をオブジェクト指向で開発するにしても、十分なアプローチ方法論を吟味していただきたいです。これさえできれば、手作りでもそこそこ対応できる気がします。ただ、現状の無理無駄な業務プロセスを見直す契機にはないれないので、無駄なシステムを設計してしまう可能性は覚悟してください。さもなくば、あるべきビジネスプロセス設計だけ、外部コンサルに依頼してもよいも知れません。コンサルの当たり外れはありますが。
その他の回答 (2)
- process9
- ベストアンサー率29% (81/271)
process9です。 >元々ITアレルギー であれば、ERPは時期尚早では。ERP事例では、この場合の失敗事例が 結構あるので。ちなみにERPもバージョンアップの弊害がありますよ。 内部で開発するにしても、簡単で効率かが計れるところから 少しづつやっていかないと、社内の士気が落ちるような気がします。 (特にベテラン層。使える若年層との年代間のギャップがひどくなり、 業務そのものがギクシャクするような。。。) また、現場のITリテラシーが低いため業務要件が決まらない。というか決められないと思われます。現場がIT使ったらどうなる?と想像がつかないだろうし、その状態でやろうとすると、作ったあとで仕様変更がガンガンかかるので、コストが高くつくような気がしますよ。 なので 情報共有のため、簡単なグループウェアとメールとExcelやWordを(強制的にでも使うような運用にして)使ってもらってITリテラシーを上げることに1年くらいは専念したほうがよいのではないでしょうか(これだけでも結構難しいかと。)
お礼
遅れて申し訳ありれません。 一部だけでもITするだけでもかなり違うのですが 江戸時代のような社風でこれをまず改善しようと思っています。 仕様変更はなるべくさせません。 私も受ける立場でとても嫌な思いをしたので。
- Hiro-N
- ベストアンサー率32% (56/175)
元経営コンサルです。やや一般論的で恐縮ですがご参考まで ERPに限らずパッケージソフトは、「業務をパッケージに合わせる」ことが肝要です。ERP導入失敗事例の大半は、業務に合わせてパッケージをカスタマイズしたことによる、コスト肥大です。 かといって内製(直接開発)なら安心、とばかりいえないのが困りモノで。 上手に仕様を作りこめばそれはよろしいでしょうが、ナカナカ上手くいかないものです。中長期的なな維持メンテ要員の保持育成、あるいは技術キャッチアップと更改まで含めて、トータルでコストメリットを出せるか。 結構大変です。 まずは何を行うべきか、を明確に整理すべきです。パッケージか内製かは、その後で検討すべきでしょう。
お礼
> ERPに限らずパッケージソフトは、「業務をパッケージに合わせる」ことが肝要です。 ここが問題なんですよね。 やや特殊な分野もあるのでカスタマイズしていくと結局作り直し・・・ というのもあります。 また社内のITアレルギーがひどく未だメールすら使わない人もたくさんいます。 このような状況下ではパッケージだと ・それにあせて業務の変更。 ・元々ITアレルギー のダブルパンチで致命的なんですよね。
お礼
> ERPに限らずパッケージソフトは、「業務をパッケージに合わせる」ことが肝要です。 ここが問題なんですよね。 やや特殊な分野もあるのでカスタマイズしていくと結局作り直し・・・ というのもあります。 また社内のITアレルギーがひどく未だメールすら使わない人もたくさんいます。 このような状況下ではパッケージだと ・それにあせて業務の変更。 ・元々ITアレルギー のダブルパンチで致命的なんですよね。
補足
> *案外、基幹業務の仕組みは複雑では? まとめてしまうと意外とさっぱりします。 とても簡単にいってしまうと 注文->在庫チェック、なければ生産->出す なので あとは経理などの部分はパッケージに任せる それこそオービックとか・・・(体験版を昔入れたことありますが使いにくい) 今だEXCELすらろくに使わず電卓をたたいたりも紙データで処理しています。 10年20年は遅れているから困りものです。 > モジュールをサービス機能で実装するSOA手法で開発する? そんなのがあるんですか。 ちょっと調べてみます。 基本的にはDBさえしっかりしていれば簡単な物なら一人でもできてしまいます。 パッケージとかを頼むとDB部分は非公開になってしまい。 最悪select ・・・などのクエリを直接たたいて調べるということができません。 すみません1さんへのお礼と間違えました