アフィリエイト広告を利用しています
G-QVESCNWRVH

2022年02月23日

デグレ祭り・・・・(デグレ=デグレード≒グレードダウン)

デグレに悩む.jpg

●グループ統合システムの開始

現在、私の会社の所属するグループでは、
グループの運用を統合するためのシステムを構築しています。
これは、元々は親会社のシステムが古すぎて破綻しかけているからですが

どんな破綻かと言うと、
・納期が守れないことが常態化
・処理容量不足

これでは、企業として立ち行かないことが明らかです。
そこで、この問題を解決するために、ITコンサルに運用見直しを依頼
出来てきた提案を検討し、承認した

これがグループ統合システムではなく・・・
親会社の問題解決システムだったのです。
それを・・・

どうせ費用支出をするのなら、グループの運用を統合するためのシステムとして構築
グループ内全企業に展開しよう
と、いう事になりました。
●ひとつの問題

私の会社は、1999年に資本提携という形で買収されました。
その際、親会社の副社長で私の会社の社長になられた方は
私の会社のシステムの素晴らしさを理解してくれました。

現在の親会社の問題解決策を、当時の私の会社では解決していたからです。
つまり20年の開きがあったわけです。

よって、通常なら親会社は自システムを子会社に導入し、運用統合を図るわけですが
当時の社長となられた方は、当社のシステムをそのまま残し、進化させ
ノウハウを親会社に逆輸入しようと考えられたわけです。

ただ、親会社のシステム部門の責任者は
ある理由によって、当社のシステムのノウハウを導入することが出来ませんでした。
その後、親会社は独自にシステム改革をしようとしましたが、2回とも失敗しました。

損失額は1回当たり10億円はくだらないでしょう。
●導入できない理由

親会社では、システム全体がつぎはぎだらけでした。
当社のシステムはシステムは一個で、その一個で全ての機能が有機的に結合しています。
なので、導入しようとすると全てを入れ替える必要があります。

また、全てを入れ替えようとすると、当社のシステムのすべてについて理解する必要があります。
業態は同じでも運用上異なる部分も多くありますので。
当然10年以上開きのあるシステムを導入したとしても、現場の人が付いていけないこともあります。
その時にシステムの人間が完全理解していないとダメですが、それも不可能でした。

なぜ?
親会社の人間はよくある事で、子会社のシステムを低レベルなものと見下していたからです。
理解しようともしませんでした。

また、百歩譲って、それが出来ていたとしても、
親会社のシステム部門は親会社のシステムの各部分(サブシステム)の仕様を完全に理解していませんでした。
彼を知り己を知れば百戦危うからず・・・中国の偉大な孫氏の言葉です。

でも、当時の親会社システム部門は
彼を知らず己も知らず、よって百戦全敗
みたいな状況でした。
結果として、二度の大失敗を喫することになったのです。
●温故知新

出来てません。
過去の失敗から学んでいる形跡がありません。

過去の失敗は、既に故人となった声の大きかったワンマンさんが主導してきました。
現在のシステム責任者は、当時は見ざる聞かざる言わざるさんでした。
失敗から学んでくれていたらよかったんですが、それもありません。

今回のグループ統合システムも構築段階から
木を見て森を見ず・・・でした。
家を建てる時、ドアと玄関を決めて、それに合うように全体を設計する方式です

まず、受注部分のみを変更しようとし、
その後、製造部門も変更しなければならないことに気が付き(あほ)
そして、納品部門・請求部門も変更しなければと気が付き(言いようもない)

結局つぎはぎだらけ
そして、最大の悪行は
システム部門が要件を決めず、ベンダーさんにお任せ
現場の意見を聞くと意見がまとまらないからと、現場に意見を聞かない

運用のノウハウが蓄積されている現場に意見を聞かず、どんな運用ができるシステムを作る?
成功する材料が見つからない・・・
こんなシステムを当社に・・・10年以上進んだシステムを開発してきた当社に・・・導入?
●デグレを数えよう

と、いうことで、当社にグループ統合システムが導入された場合のデグレを列挙してみましょう。
(1)半分を占めるカテゴリーの顧客に対して商品準備工程が無くなった。
(2)受注用紙が大幅に変更となる。グループ標準の用紙以外は使用しない。
   顧客専用様式の受注用紙は廃止。←顧客ロストの可能性はいかほどか?
   同業他社が出来ている事を新システムでは対応できない。
(3)顧客側に工程の一部を移管
(4)営業部に工程の一部を移管・・・ただ営業部にその分の時間は移管されない
(5)前工程のアウトプットが次工程のインプットとなる
   ただし、前工程のアウトプットに誤りは含まれないという想定
   作業要員は間違いを犯さないと言う想定でシステムづくり
(6)商品チェック工程の削除
(7)納品工程の統一
   と言うと聞こえがいいが、顧客専用様式での報告書・請求書は基本的に廃止
   受注用紙の場合と同様に顧客ロストの可能性大
   ↑受注用紙より報告用紙の方が顧客は嫌がる
(8)全ての工程において、コンピュータ処理時間の増加
(9)商品コードが採番されていないものは、全工程で紙運用
   デジタル運用から紙運用に・・・これはショック
  (我が上司によると、全ての商品にコードを振り、マスター登録せよと)

もう、疲れました・・・
当社の現場の方々の幸運を祈ります・・・

この記事へのコメント
コメントを書く

お名前:

メールアドレス:


ホームページアドレス:

コメント: 必須項目

この記事へのトラックバックURL
https://fanblogs.jp/tb/11274820

この記事へのトラックバック
ファン
検索
<< 2024年11月 >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
最新記事
写真ギャラリー
最新コメント
タグクラウド
カテゴリーアーカイブ
プロフィール
Y.Taki@AS400さんの画像
Y.Taki@AS400
IBM AS/400で稼働するシステムの開発・追加を担当して30年以上になります。使えば使うほどこの AS/400 が好きになりました。 こんなSEがいろいろな視点から様々な業務などについて語ります。
プロフィール