ラベル 基幹 の投稿を表示しています。 すべての投稿を表示
ラベル 基幹 の投稿を表示しています。 すべての投稿を表示

2021年6月26日土曜日

寿命30年の自社開発システム!

(システムの費用対効果〈 システムの寿命 〉を改題)

30年動いてきたオフコンがありました!すごいですね。開発の費用対効果もさることながら、バージョンアップやデータ移行などの無駄もなくシステムの鑑です。パッケージ、ERPの方が楽だというのは本当でしょうか?大企業でなければERPのバージョンアップコストとても払えません。

30年前の設計書も残っていました。手書きで感動しますね。設計書を見ると、30年の間にシステムの使われ方が変わってきたことがわかります。現在は販売管理業務がメインなので使用帳票とヒアリングから、業務フロー、データ定義、画面プロトタイプも起こしました。ただ30年前のデータ仕様書は参考にしました。業務システムの根幹はデータ設計です。今回のシステムはマスタ以外のデータ移行はないので、テーブル構造、データ定義の制約はないので、データ設計をさらにシンプルにしましたが、イレギュラーケースの想定など念のためデータ仕様書を確認しました。

リレーショナルデータベース(MariaDBです)のビューやトリガのおかけで性能を維持しプログラム数も減らすことができました。フロントエンドがアクセスなのでクエリにデータフローを記述できるので手書きのプロシージャも最小限です。その分、便利機能を盛り込むことができました。

過去、私の関わった比較的大規模なシステムで、アパレル全社基幹システム、医薬品卸営業支援システム(SFA)、配送トラック動態管理サービス* があるのですが、どれもシステム稼働から10年を越えて安定稼働を続けている・続けた* ものです。ハードウェア交換は行っていますが開発されたプログラムは動き続けています。どれもスクラッチ開発です。

一方、パッケージ導入は稼働延長したものでも8年が限界でした。意外なのですが、パッケージの方が寿命が短いです。古い環境に特別対応できないからですかね?メジャーバージョンアップにぶつかって、実質的に再導入というケースもありました。もう別の製品ですね。

パッケージといっても大体アドオンするのでそんなに安くないし、アドオンプログラムのバージョンアップ対応でお金が出ていきます。製品保守費の15-20%が毎年自動的にかかっているのに、さらに上乗せされるお金です。会社の中で、金食い虫と情報システム部が白い目で見られる訳です。でも自社システムを開発する要員もいないし、中途半端にベンダーに頼らざるを得ないのが現状ですね。問題は業務別のシステム、パッケージという名のブラックボックスの乱立で、今度は運用管理やデータ連携に苦労することです。そこまでは外部に頼れず、結局、運用管理にシステム部の人手がとられてしまう。悪循環です。

パッケージソフトって、それ一つだけだとメリットが感じられるのですが、複数の組み合わせとか、連携とかになると途端に出来ないことが出てきて運用しづらくなります。
ユーザサイドも苦労して導入したソフト、せっかくなので長く使い続けたいですね。費用対効果のメリットも出てきますから。運用まで考えてパッケージ選定、システム設計したいです。

パッケージ導入、コツがあります。システムフローの尾っぽ部分はセーフです。頭部分は要注意、胴体部分は・・・
SAP 困っていませんか? 国産ソフト、クラウドベースやオープンソースですっきりさせるのも一案です。
永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

追記 2020年1月6日
ワークフローソフトをパッケージ導入頂いたお客様を久しぶりにご訪問させて頂きました。無事、運用されているとのこと。安心いたしました。
お客様が大変協力的で(システムは賢くはないことをご理解いただき)アドオンなしで導入頂いております。末永くご利用いただきたいと思います。

2021年6月5日土曜日

大企業よりも難しい?中小企業のシステム導入

大企業のシステムプロジェクト、バリューエンジニアリングのお手本になることはまずありません。何故でしょう?
  1. 30%の保険コスト
  2. 10%以上の事務局コスト
  3. 10%前後の承認待ちコスト
  4. 30%のエンジニア・マージン
  5. さらに機器、ソフトウェアなどの調達品のマージン

    どれもこれも、ユーザ、発注者からすると腹が立つコストですよね。トータルで2倍前後になります。機能、性能、品質は変わりません。納期も短くなりません。システムの寿命が長くなるということもありません。まったく最低です。

    でも大企業側が自分で責任を持つから、安くしてくれという話は聞いたことがありません。システムプロジェクトの失敗が怖いからです。

    しかし中小企業の社長さんが、こんなバカげたコストを認めるでしょうか?システムインテグレータが中小企業を避ける理由の1つがこれです。

    ホームページくらいなら目をつぶるにしても、気になるのは販売管理、在庫管理システムです。IT業界も20代で辞めてしまうことが多く業務知識まで頭に入っているエンジニアは大手でも多くはありません。業務要件は大企業でも中小企業でも変わりません。あたりまえですが勘が働かないと要件定義は出来ません。出来ていないことすら気付けません。

    冒頭のバカけたコスト、要はシステムインテグレータの教育代です。大企業は払えても中小企業は払えません。実は中小企業のシステム導入は経験者にしかできません。中くらいのエンジニアでは出来ません。しかし規模の小さい案件に限られた経験者をアサインすることはシステムインテグレータの商売の理屈として成り立ちません。これが理由の2つ目です。

    売上高100億円から1000億円の事業だと、オフコン現役というところも珍しくはありません。IBMだと AS/400、NECだと A-VX、他富士通など。そろそろ寿命も尽きます。そこで新システム構築なのですが、パッケージソフトがはまりません。大企業では逆にパッケージソフトやERPからの移行という案件も聞きます。だいたい無理にパッケージ、ERPをはめ込んだシステムは寿命が短くなります。パッケージの方が費用対効果が高いとは限りません。

    お医者さんや、大工さん程ではありませんが、システムエンジニアにもヤブと腕利きがいます。腕利きにあたれば同じコストで、タフで使いやすく、長期にわたり安心、安全に使えるシステムが出来上がります。大手に依頼しても運が悪ければ、そもそもプロジェクトが進みません。疑問があればご相談ください。

    永島志津夫
    オフィスエヌ ショートレビュー5万円から
    全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。


    2020年2月7日金曜日

    失敗しない要件定義 その3 〈要注意な言葉 アカウント〉

    アカウント(Account)という言葉、あまりに意味が多過ぎて困ることありませんか?ただでさえ、業界、会社ごとの業務用語 “方言” があって、システム泣かせなのに、基本的な言葉の指す意味が複数あるのってどうなんでしょうか?


    クイズです。それぞれアカウントはどういう意味で使われているでしょうか?

    シーンその1 
    システム屋:「現状のアカウントの一覧ご用意頂けますか」 
    ユーザ部門:「分かりました。財務でいいですよね?」

    シーンその2 
    システム屋:「現状のアカウントの一覧ご用意頂けますか」 
    ユーザ部門:「全支店分ですか?何のためですか、許可は取ってますか?」

    シーンその3 
    システム屋:「現状のアカウントの一覧ご用意頂けますか」 
    ユーザ部門:「国内なら今週用意できると思います。海外現法はちょっと聞いてみないと・・」

    シーン1では勘定(科目)の意味です。財務会計の勘定科目ならあっという間に出せますよね。項目数でも1000ないくらいで意味のブレもそうそうありません。業種により多少違いはあっても経理さんに聞けば大丈夫です。(ただし補助勘定はローカル運用なのでご注意を)

    シーン2は銀行口座の意味ですね。ペイオフ制度のため名寄せが進んだとはいえ、口座は支店別管理です。定期預金口座は普通預金口座と別になっています。なので振替で資金移動をします。同一名義の別支店口座も振替であり、振込ではありません。振替とか、繰越とか会計と同じニュアンスで使われていますね。(あまり遭遇しないと思いますが、医療機関も施設別患者管理です。患者情報の施設外持出は原則不可です)。

    シーン3は得意先の意味で、銀行以外の業種でも得意先のことを口座といったりします。業務システムでは一般的な使われ方です。販売管理のキーとなるマスターですから、要件も盛りだくさんです。すぐ思いつくだけでも
    ・請求先か、届け先か、関連付けはどうしているか?
    ・与信(枠)管理はどの範囲で行っているか?
    ・仕入先は別管理か?
    ・グループ会社取引はどうフラグ付けしているか?
    ・国・地域、通貨、関税などとの関連付け・・・

    新しく導入したシステムでは減ってきていると思いますが、コードが8から始まるものとか、必ず確認していました(ニヤッとされる方もいると思います)。

    英語のミーティングでは Accounts of BS,PL, Bank account, Cusomer account と確認すれば良いかと思います。届け先は Address になります。

    アカウントの話、ITっぽくありません。システムと全然関係ないようで、知らないと要件定義1回目からアウトです。コンシューマとビジネスで考え方が丸っきり違います。アカウント=ユーザーではありません。以前、顧客コードを電話番号にしようとしていた人がいました。今なら E-mail でしょうか。絶対だめです。
    永島志津夫

    全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
    オフィスエヌ ショートレビュー5万円から。
    連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します