ＩＢＭ　ＡＳ４００とパソコンを愛するＳＥのブログ

●本来の目的

このブログの本来の目的は
私の大好きな・・・いや愛しているといっていい
ＩＢＭ　ＡＳ／４００の良さを伝えていくこと

なのに、最近は、親会社の作ったグループ統合システムに
翻弄されて、よたよたしちゃってる事ばかり話してますね

でも、今年から新システム（グループ統合システムのこと）が稼働して
当社はせっかく可能な限り自動化して
必要な人員とか手間を削減してきたのに

新システムは人員と手間がめっちゃ必要になって・・・・
今まで、削減した人員・・・ではなくて
他のとこに比べて半分程度で済んでたのが

他のとこと同じだけ・・・必要になります
すると・・・・当然仕事量が半分になるわけは無いので
殆ど全員アップアップ

しかも、人員補充も何もされないので
力尽きて退職していくものがぽつぽつぽつぽつ

さらに、人員不足に陥って

●簡単に考えていた

新システムがここまで持ちこたえる・・・とは
いろいろと問題が噴出しているのに
ある程度で、仕切り直し・・・・

仕様を再設定してやり直す・・・って思っていたのに
当社システムの７割程度の性能で
稼働し続けさせているとは・・・・考えが甘かった

早晩諦めて、当社システムに全面的に戻す・・・
そして、再度要件定義し直して
そのあとは・・・と思っていたけど

なにせ、ＩＢＭ　ＡＳ／４００の性能の高さは
折り紙付き！
可用性、秘密性、完全性のどれをとっても天下一品

●審査員の折り紙付き

このＡＳ／４００
ＩＢＭが汎用コンピュータのＺシリーズとは別に、オフコンから初めて
今や汎用コンピューターを凌駕するスケーラビリティーを持っています

小さいのでは卓上
大きいのではとってもでっかい(笑)　表現下手でごめんなさい

しかも、ＣＰＵは驚速のIBM Power CPU
名前負けしてませんよー

●当社のシステム

当社のシステムは、このＩＢＭ　ＡＳ／４００で構築されているので
一つ一つの動作がきびきびしています
いや、きびきびしすぎて、実行を指示しても一瞬で画面が戻ってくるので

あれ？　指示し忘れたかな？って思って
もう一度指示して、
それを２〜３回繰り返して

プリンターから指示した回数だけ同じ資料が印刷されたりして(笑)
よくある話です。
まぁ、それほど早いって事です

●デグレシステム稼働

今年の11月に、新たなサブシステムが稼働する予定です
それに向けて、いろいろな設定を行い
運用テストを開始しています

その中で、お客様に提供するあるファイルについて
現行システムで作成したものと
新システム（テスト版）で作成したものが

全く同じであることを確認する・・・事をしています
そこで、ふと・・・

●運用はどうなる？

従来は・・・って言うよりかまだ当社現行システムで稼働している機能は
全自動
文字通り、全く人の手は不要です

ただ、新システムになると・・・
人手がかかります

しかも、朝７時までに顧客にファイルを送信しなければなりません。
すると・・・

●早朝出勤必須

新システムでは提供用ファイルを作成するシステムと
それを送信するシステムが別々なので
誰かが手作業でファイルを移さないといけないんですよね

しかも朝7時までに・・・これはお客様との約束です

新しいシステムになって、
要員が早朝出勤するのはかなわないから
朝9時までで良いかって聞くこともできますが

恐らく

激怒されて、しかも今まで通り７時までって念押しされる
出来なければ取引停止を通告されるでしょう

●新システムって手間暇かかる

今まで全自動だったのに
だれもしなくても、システムが勝手にお客様に報告してくれていたのに

新システムになったら
ファイルを移して送信開始指示をするためにだけ
早朝出勤をしなければならないって

素晴らしき新システム

●ビジネスの根幹

基幹システムを構築してきたシステムエンジニアにとって
一番重要視しているのは・・・請求？
商品やサービスを提供して、その代価を頂く

その代価がいくらであるか、契約情報に基づいて計算します
この計算に誤りがあれば、とんでもないことになります
なので、必死こいて作りこみました

当然、自前で開発しているので
全ての運用・仕様は保持しています
ただ、自社開発のデメリットは

仕様が最新状態に維持されているわけではない

と言うことです。
顧客から急に要請や要望を受け、
それに緊急に対応しなければならないとき・・・など

●仕様作成

なので、既存の仕様書を確認し、
現在の運用・仕様と異なるところを抜き出して
最新の状態としています

しかし、私もシステムへの新規機能追加や変更を停止して早４年
なかなかに忘れていますねー(笑)

なので、データベース記述書やプログラムソースを読んで
記憶のリフレッシュ中です

当然のことながら、私は親会社の請求ロジックもある程度知っているため
今回、当社の請求の仕組みを思い出しながら

こんなこと、新システムで出来るんかいな―？
だって、いろいろな情報にアクセスしなければならないのに
新システムでは、それぞれの工程が独立したサブシステム

新請求システム（今から作ろうとするグループ統合請求システム）は
もらった情報を取り込んでため込んで請求処理をするから
全情報をもらっているわけではなく・・・

●考え方が根本的に異なる

しかも、請求額の決定方法については考え方が異なっています

当社のは、一か月ごとに確実な請求額を計算して請求書を出す
親会社のは、一か月ごとに請求額を計算して請求書を出す・・・けど
過不足があれば次月相殺する・・・んです

なので、当社では、請求締め日前後の請求対象が変更されれば
即座に反映するようにシステムを構築していますが
親会社のは、どうせ次月相殺できるだろって感じなんです

どっちがいいのか？
どっちも正解だと思います
ただ、処理方法は異なります

そこをどうやって合わせていくのか・・・
これは見ものです

●一から作り直し

で、当社の請求システムの仕様書を見直してみると
それはまぁまぁ９０点ぐらいの状態で維持されていました

でも・・・それを１００点にするだけではだめって事に気付きました

それは・・・

語句
同じ単語でも意味が違うことがあるんです。

たとえば
受付日
当社では、受注し、依頼をホストシステムに入力した日を指します。
でも、親会社では受注した日を依頼日、入力した日を受付日として運用しています

よって、このことに言及せずに仕様書を親会社に提示すると
必ず誤解します
誤解されれば一巻の終わりです

なので、この辺を注意して、変更（と、言うより翻訳）する必要がありますね

これって結構骨が折れます・・・
しかも今週中に仕上げなければ・・・大丈夫かな？