更新出来ないシステム...逆転の発想で挑め(2)

  • 投稿日:
  • by
  • カテゴリ:

 前の記事の続きです。長いので分けました。

 

 

 システムを業務に合わせるのではなく、システムに業務を合わせることによるコストダウン。

 

 実はこれもまた最近では割とポピュラーになりつつある方法で、既存の汎用パッケージやASPサービスを組み合わせて代用出来る部分は代用し、顧客データに関わる部分やどうてしも代替出来ない部分だけを新規開発・構築し、それを運用する側や業務の流れなどをその新たなシステムに合わせるというやりかたです。

 

 これがまた、結構悪くない。専用システムの利点と汎用システムの利点をうまくハイブリッド化しているわけです。(ただし言うほど汎用性はなかったりも)

 どんな会社のどんな業務であろうと、ある程度共通の部分があるものです(総務・財務等のシステムもそうですね)。そこを安価なASPサービス等で置き換え、コストを削減する。汎用パッケージで業務を運用し、どうしても対応出来ない部分だけ小さく新規に起こす。

 今の業務システムに合わせて構築させているであろう業務の流れ。けれど、システムリニューアルを期にその流れ自体も見直す。

 ある意味いいチャンスなわけです。ただ、実際にやるとなるとものすごい労力とパワーが必要です。

 今まで出来ていたことが同じやり方では出来ない。

 「前の方がいい!」

 様々な叫び声が社内にたくさん。

 経営者が力ある言葉で「なぜそのシステムをいれるのか。なぜ今までのままではいけないのか」を発することが出来ないと、実際には難しい話です。

なんのためにリニューアルするのか。ただ老朽化したシステムの置き換えを安価にしたいだけなのか。それとも、この機会に会社全体の効率を上げる方法をとりたい、だからこその大規模変更なのか。

 コーディネートする人。導入・運用担当の人。経営側の理解。全てが揃わないと、なかなか出来ないのが難点です。

 

 応用すると、比較的小規模でIT化なんてされてない会社にも使える手段だったりします。

  

 まぁ話を戻すと、システムをどうせリニューアルするのであれば、そのコストを最小限のものにしてむしろ業務のリニューアルを行い、今までの流れを見直し、ある程度モダンな...古い言い方をすれば「今風の」流れへと変更する。(どっちも古い言い方だ...)

 ベテランしかわからない処理の仕方などをなくし、全員がスタートラインから始める。もう一度業務を構築する。 

 

 業務の効率化は「慣れ」を主体に考えがちですが「平易に。そして平等に」することもまた効率化だと思います。異論はたくさんあるでしょうけれど、あくまで私の主観で、です。


 ところでなんでこんな話を書いているかというと、実際にやった会社を見たからで(笑)


 導入時の社内の悲鳴はそりゃもうすごいもので。調達システムから何から何まで既存インフラをそれこそ「ぽいっ」と捨ててまったく新しいものに変えたわけですから。相当に強いリーダーが指揮していないと、なかなか出来ないのも実感しました。けれど、結果としてはかなりの効率化がされ、最初は文句を言っていた社員たちも慣れるにしたがって「ああ、こっちの方がいいな」と実感し、この不況の中でも立て直しに成功。現在の売上でなお余力がある。そんな会社へと変貌していました。

 もちろん、これは最初の計画がきちんと出来ていて、アプリケーションの組み合わせ等をしっかりとコーディネートし、実際の業務運用まで踏み込んだシステム運用構築をしていたからこそですが...弊害として、旧システムのデータを取り出していつでも見られるようにビュアーだけは新規に起こさざるを得なかったのが。監査等を考慮すると、今までのデータも見れないといけないので、その備えにややコストを追加せざるを得なかったという。それ以外の部分は業務部分まで含めて、市販の汎用パッケージでほぼ構成しきったという。

 私はたまにその様子を見せてもらいながら「すげぇ...」とため息をつくばかり。

 何がすごいって、喧嘩腰で乗り込んできた取締役を眼光ひとつで抑えきったシステムリーダーがすごかった。残念なのは、最後まで仕事を終わらせた後、この人は別の企業にヘッドハンティングされてしまい、今はその会社にいないことですか...あんなに頑張ったのに社内の評価が低かったのかもしれませんね。結果は出したけれど、その後の幸せな社内に...その風景や空気の中に、あの人の姿はもうなかったのです。

 1年と半年(準備期間含む)でこの全てを終わらせた力量は、まさにお見事でした。ただ、強引に進めざるを得なかったため、確かに反感を買うことも多かったのでしょう。外資からの誘いにうなずいて、彼は海を渡ることを決意しました。いずれまた、その仕事の進め方やテクニックを教えてもらいたいものです。お疲れ様でした。ものすごく勉強になりました。参考になるから土日だけでも見に来るといいよ!気さくにそう言ってもらえて本当にうれしかったです。

(※2/22 追記。プロジェクト進行中、彼とそのスタッフはほぼ土日も休みなしで計画を推進していました。通常業務のない日こそ、システムのデータの流れ等を洗い出すチャンスだし、うるさい人たちがいなくて集中出来るから...と。ある意味で会社にとって都合のいい話になってしまってますが、そうでもしないと短期間で仕上げることは出来なかったのでしょう。私は休日にそのやり方を教えてもらえに行けたので、ついつい甘えてしまいましたが)

 

 ただ、言葉では簡単そうですが、しがらみや力関係。古参と新人。慣例によって作られたおざなりなルール...様々な障害があったのは事実で、それこそ殴り合いにいつなってもおかしくない会議なんかもあり、なんというか「プロジェクトXじゃないんだからあんた達は」という気分だったり。頭の中ではあのオープニングがたまに聞こえていた気がしたような(苦笑)

 転職を前にリーダーがいったん実家に帰るというので、彼を東京駅まで見送りに行った時は頭の中でエンディングの曲が聞こえそうなぐらい。...ほんと、成功してよかったですよね...途中を知ってるだけに(^^;

 

 もしこういったリニューアルに興味があるのでしたら、出入りしている様々な商社の営業に相談してみましょう。確かに導入費用は高く見えるかもしれませんが、トータルで考えた時どちらがいいか。経営者の力量と判断が問われる場面です。

 ...もちろん、専用システムを構築した方が圧倒的に安い場合もあるんで、全ての会社に当てはまるものではないんですが。汎用ソフトによる業務の汎用化は、それこそ今あちこちで行われているホットな方法だったりします。...失敗例もあるんですけれどね(^^; 目も当てられない失敗...経営側の協力がなくては担当者だけで出来るものではなかったり。

 あと、本当に汎用化出来る業務か見極め失敗してると、もう(笑) 最初からだめじゃん!って話は結構ごろごろと。

  汎用って魅力的な言葉ですが、汎用であるからこそ足りない部分というのはあるので、そこをどう飲み込むのか。どう運用するのか。ちゃんと理解しないと勧めてくる営業達の言うがままに結局高い買い物になってしまいました...では意味がないので。

 

 

 ※なお、この話は実話ですが、守秘義務契約に基づき社名・導入パッケージ名等は記載しません。当該会社の法務・監査よりチェックを受けることを了承しています。指摘があった場合は削除・変更になる場合がありますのでご了承ください。

 

 

 

余談

 そういえばはてなブックマークやtwitterで私のブログを扱ってるページを見ていたら、Solarisのバージョンアップに言及してる人がいましたが、あれも相当面倒だと聞いてます。私は扱ったことがないのですが、知人にその手のシステム専門の人間がいるので聞いたら...やはり面倒だそうで。昔はソラリスとオラクルで万全とか言ってた先輩がいたんですが、どう万全だったんだろう(笑)

 後は...銀行系なんかではまだまだCOBOLが現役なので、JCLなんかもそうですがそのシステム自体を新ハードで...となるとやはりVMなりシュミレートなりで対処してるようです。まぁ、出来るだけましですが、それもやはり専用ハードがまじると...きびしい。

 いろいろ手段が構築されてる分野ですが、一部は新規に開発してリレーションしたり...コスト削減のためパチッワークみたいなシステムになったりも。代替の利かない部分だけ新規に起こして、後はVMで。これもポピュラーなやり方のひとつです。

 そういえば、銀行の合併の時もリレーション部分だけ新規に起こして...なんてやってみしたね。相当難しいことをやってるなぁ...と思います。あれこそ汎用化したくても出来なかった業務のひとつかも。


さらに余談

 私が社会に出てすぐ取り組んだプログラムの環境は「OS/2」というシロモノで、今考えると時代のあだ花となって壮絶に散ったOSなんですが...実は、15年近く立とうというのに、このシステム現役で動いています。どこかのタイミングで「OS/2 warp」へのリニューアルをしたのは、昔の同僚に聞いていたのですが...もはや開発した技術者もおらず、環境も環境ですからセキュリティ的にも問題ありあり。


 まぁ、このシステムを運用している会社については完全新規でのリニューアル(業務システムどころか、財務や営繕も含む)が決定され、入札にするかはともかくさまざまな会社がプレゼンに来ていると聞きました。この時期に積極的な投資も出来ないので、既存システムを安価に導入して、運用側がそれに対応する形になるとは思うのですが(今回扱った方法ですね)...スクラッチで起こしたシステムに比べれば「今まで出来たことが出来ない!」等の不満は頻出するでしょうし、難しい判断になると思います。

 成功するといいのですが...もう私の知ってる人もいなくなってしまっています。そんな会社の話ですから遠くから見守るしかないんですけれど...寂しい話です。しかし、まだあのクライアント使ってたのか(^^; 驚きだ...