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

●新請求サブシステム

月曜日は新請求（サブ）システムの仕様検討会議の日
４月３日にももちろんありました
そして、私は途中から参加しましたが

参加したところからさかのぼって決定していることを見ると
愕然としました

●請求起算日

親会社の請求ロジックそのままで、
当社の請求ロジックなんてつゆほども考慮されていない
そして、我が上司は、全顧客、この請求条件にあわさせる

すっごーい
そんな事ができるんだー！
我が上司が直接顧客に行って交渉するんだー

って訳ないから、交渉するのは営業の方々
でも・・・
請求条件の変更ってなかなか難しいはず

●請求額計算方法

請求は、一か月単位で行います
まぁ、良くあるのはその月一か月分の請求を
末日で締めて、翌月支払いとかですね

ただ、そのまとめる対象は何かと言うと
請求日が１日〜末日までのものを末日で締めて計算

すると、問題になるのが
請求起算日の決定方法です

これが、当社とグループ他社の大きな違いです

でも、上司は請求起算日の設定を全部統一し
当社の顧客については、それに合わさせる・・・そうです

●こりゃ・・・

まぁ、言うのは簡単ですがね・・・
言うに安く行うに難しって言葉通りの展開です
しかも、言ってるのはシステム部門の責任者

やらせようとしているのは営業の方々
こりゃ・・・営業の方々には過酷な試練が待ち受けてるでしょう
もしかしたら心が病んでしまうかもしれません

いままで、稼働している新サブシステムのおかげで
営業さんは謝罪行脚をしています
これにさらに・・・

●以前、問い合わせ

今、複数のサブシステムの構築が進行している
そのうちの一つは、当社や他社の製造工程でも特殊な方
なので、新システムでは、その特殊なシステムを発注した

ところが、当社では単独システムの一機能として構築
１９９４年から運用している
当然、１９９４年からそのままではなく

何度となく改定を繰り返している

しかし、そんなことは親会社のシステムはどこ吹く風
全て自分たちの作っているのが正しいという考え
まぁ、それはそれでいいんだけど・・・

その特殊機能についてまぁまぁ知っているのが一人
親会社のシステム部門にいる数人の中でただ一人

この特殊機能についてその実装方法は
親会社のものと、当社のものでは全然異なる

現場担当者通しが２０１０年ごろから運用と逸しようとして
まだ出来ていない

それほどまでに特殊

だが、親会社は自分のとこの運用を提示し発注
当然、当社システムと互換性がほとんどない

けれど、我が上司はインターフェースを取れと言う
出来るわけない

ただ、しなければならない
とりあえず、その業者に確認しようと
当社の名前と私の名前で、その業者のＨＰから問い合わせメール

●返答無し

けれど、１か月経っても返事もなし

普通、私の質問について、時間がかかるか
それとも、システムで公開していない部分（秘密部分）で
とかで、公開できないなら

何らかのレスポンスがあるやろー！
それもなく無しの礫・・

●多分

多分、無視した？　気付いてない？
まさか、めんどくさかったんだろうか？

いずれにせよ、ビジネスの最低ラインも守れていないやつら

●顧客対応がずさん

当然、私は顧客側の立場
先日、オンライン会議で当社の名前と私の名前を表示しつつ
その担当者と会話した

しかし、私が問い合わせた件については全く認識がないようだ
つまり、私の問い合わせメールは
問い合わせ担当が適当に処理した

そんないい加減な顧客対応をするところを
信用できない

ということで、この

●まだ生きながらえている

４月１日・・・２０２３年度となりました
怖れていた「４月から来なくていいよ」って通告は
まだ無いみたいです・・・

頑張ってますね・・・
システムがしょぼい分、現場の人たちが＿|￣|○
とりあえず、契約を解除される事は無かったみたいで良かった良かった

●契約は年度ごと・・・

契約は基本的に年度ごとに行われるので
年度が替わって契約が継続していれば
とりあえずは来年３月末までは・・・

●重大なミスが無ければ

ただ、大きなトラブルがあれば
年度途中でも契約解除される事があるので
まだ安心はできません。

しかし、今年初めに新システムの一部が稼働し
私の耳に入って来るだけでも結構な頻度でミスが

昨年まではほとんど耳にしたことがないような
初歩的なミスとか・・・

●どちらが早いか

これは、退職者が続出し、
特にベテランがスピンアウト
そのため、残された人たちは

人手不足と経験不足のダブルパンチで
当然、ミスも起こりやすくなり
このような結果に・・・

はてさて、
ミスにより顧客からの取引契約解除が多くて・・・
退職者が続出し、業務継続が出来なくて・・・

どちらが早いかな〜？

●新システムで対応できない

当社のシステムには
色々な機能があり
それらの内でいくつかは新システムで対応不可

●しかし、受託入力は

全て新システムで賄うこととなっていて
そのような指示を上司から受けている
なので、やらざるを得ない

しかし、お相撲さんのご飯は
小児用茶碗に入れるのがとても難しい

それ以上に難しいことを
やれって言われている
それでも、出来なければ現場が困る

●そのためのインターフェース

先週は、その機能の内の一つを
先週中に開発しなければならなかった

それは、今週火曜日（４月４日）に
完全稼働させなければならないからだ

なので、本来なら２〜３か月はかかるところを
１週間足らずで仕上げろと言う
無茶な要求に応えるしかなかった

それが出来なかったら、現場の人が
全て手作業をしなければならなかったから

●緊急に

ほんと、緊急対応と言うべき開発だった
なんとか、完了直前まで持ってこれた

４月３日（月曜日）に
最終確認を行う予定
上手く行ってくれると確信している

上手く行くまで徹夜してでも仕上げるから・・・(;O;)

●既に通知済み

これまで長きにわたって取引していた
日本有数の大企業グループ
今日は、Ｚｏｏｍで会議

責任者から参加要請があり参加
もしかしたらのシステム関連質問対応の為

●最終会議

しかし、話を聞いていると
どうやら、取引のための契約解除を既に申し入れており
先方より、４月末での解除は急すぎる

そりゃそうでしょうね。
業務内容は継続して行われているので
あと、一か月でって言っても先方では対応がとりにくい

いや現実的に対応できないと言われました
そこで、１か月延期してほしいと
5月末での契約解除にしてほしいと頼まれました

ところが、当方の現場責任者が
退職者が続出するため
５月末まで業務を継続することは非常に困難だと

●メインを当社が

その業務に関するシステム
その大企業グループの品質管理部門の部長が
当社を含む同業他社を集めて、したい事を提案

各業者は、そんなことが出来るのかと否定意見ばかり
そんな中、私だけが、『なぜ出来ないの？』と肯定意見を出した
それが気に入られて、当社がその業務の半分を担当することに

そして、システムも私が開発し
各業者に管理システムを提供し
また、日本各地の主拠点にそのシステムをインストールする名目で
その部長と行脚

当然、沖縄にも拠点があり、そこを訪問
人生初の沖縄だった
その部長、気の毒がって、スケジュールの合間

今は消失してしまった首里城に連れて行ってくれた
私の苦手なゴーヤチャンプルーを進めてくれて
（後で聞いたけど、その部長はゴーヤチャンプルーが嫌いだって）

●悲しい

稼働し始めて数年後、個人情報保護法の制定に伴い
データ授受のために作成するファイルを暗号化してほしいと要求され
Blowfishと言う1024bit 秘密鍵による暗号モジュールを組み込んだ

当時としては最強部類の暗号であったが
秘密鍵の為、結構管理がめんどくさかったはずだが
それを簡単に素人でも管理できるように組んだので

またまた喜ばれた

その後も、何度か改定を繰り返して来た
でも、グループ統合の走りから
当社の対応が悪くなり、疎遠になってきてしまい

とうとう、二十数年の幕を閉じることに
悲しいです

●週一回の定例

今日は木曜日なので
毎週一回、周辺システム定例会があります

何をするかと言うと、新システム構築に絡んで
いろいろいろいろいろいろいろいろいろいろいろ
周辺システムと連携しないといけないのです

ほんと、周辺システムがいっぱいあってね

●周辺システム開発ベンダー調整会議

単一のシステムなら、調整なんて必要ないのに
複数のシステムが混在しているから
一か所直すと関連する部分を芋づる式に直さなければなりません

その数や人間の能力の限界に挑戦！
いや、既に負けてると思いますが
それらをち密に間違いなく直していく

これって神業に近い(笑)

昨日は、それとは別に
運用調整会議がありましたが
その中で現場の人が

かくかくしかじかで、これこれどれどれって質問した時に

開発担当ベンダーのメインのＦ社のリーダーが―
その部分については（当社の名前）で改修してもらわないとダメです
って言いきりました！

●なぜか

私はその時すごく違和感を感じました
なぜなら、当社は開発を委託する側
すなわち開発ベンダーからしたらお客様の立場

つまり、言い方ってもんがあるやろ

●微妙な立場

親会社の我が上司が、
ベンダーで開発するか当社で開発するかの二択となる場合
決まって、当社に開発するよう指示します

まぁ、そりゃ当社でやればタダですから！
でも、その言い方をＦ社がするのはお門違い！

普通ならば、Ｆ社のリーダーは
でしょう？
Ｆ社のリーダー、分かってるんでしょうかね？

まぁ、開発出来るか出来ないかという観点から見れば
当社は開発ベンダーの一員ですから
開発できないのは、親会社のシステム部門ですから

はーーーっ！　困ったもんだ！

●ＩＳＭＳ

現在、新システムの導入中なんで
システム室の中には機器が散在しています
廃棄する機器やむき出しのハードディスクが・・・

●新システム移行中

ＩＳＭＳの審査員が見に来られて
どっひゃーって感じになりました
私が対応するわけではないので、見物人の立場ではいたんですが

●ログ機能について

審査員の質問に聞き耳を立てていると
ログ機能についても聞かれていました
対応者は当社の現行システムのログ機能を説明

審査員は感心しておられました
でも・・・・

●次回は・・・

次回は、新システムがメインで稼働しているかも
その場合は、ログ機能を説明するのが大変です
だって、ログは取っているもののそれを見る方法が・・・

システム要員でもログファイルにアクセスすることが大変
そして、その中から必要な情報を見つけ出すのって
どのくらい時間がかかるんでしょうね

もう、次回のＩＳＭＳ審査を受けるのが
めっちゃビビるー

●グループ各社の仕様

現在、新しい請求システムの構築が始まっています
それは、受注部分、製造部分を統一したサブシステムが出来た（つもりみたい）からです
そして、納品処理部分は今年５月にリリースされる（つもり）予定です

●統合新請求サブシステムの仕様

その新請求サブシステムの仕様を検討しているところですが
グループ各社を例えば
Ａ社（グループ本社）
Ｂ社（グループ子会社）
Ｃ社（　　　〃　　　）
Ｄ社（　　　〃　　　）
Ｔ社（　　　〃　　　：当社）
とします。

請求処理の方法で分類すると
Ａ，Ｂ，Ｃ：Ａタイプ
Ｄ：Ａ＋αタイプ
Ｔ：Ｔタイプ
と大きく分けて２種類になります

そこで、かれらは最初やりやすい方から仕様を決定していきました
Ａ及びＡ＋α　⇒　Ａ’　に
これは簡単でしょうね

そして、私の方にＴ社の請求ついてどのような処理をしているか教えてほしいと
彼らは、Ｔ　＝　Ａ＋α’　ぐらいに思っているんでしょう
でも、実は全然違うんですよね

Ｔ仕様は実は全く異なるんです
さらに機能的には（転換後Ａ）＋αβγδη　ぐらいでしょうかね。
これらの　Ａタイプにない仕様をどのように実装するんでしょう

先週の月曜日でしたか
この件のプロジェクトリーダーが言った言葉
『（当社のＵ名前）の仕様で、新システムで対応できないものは、取り入れない』

えっ？
当社では、自社開発の強みを生かして
顧客要望の変化（当然、環境が変わると顧客の収益も変わり、値下げ要求が発生する）
世情動向の変化（客層、客筋の変化、経済要因の変化、行政の対応の変化、法令の変化）
に対応すべき、何度となく仕様変更（概ね機能追加）を行ってきました

このため、かなり複雑な請求処理になっています
しかし、複雑になってはいますが、私のポリシーにより
現場の作業工程は極力増加しないようにしています

下手したら作業工程が簡素化され、減少しているとも言えます
（この目的は［人的作業によるミス発生の低減］［作業時間の低減］があります）

当然、現場の方には喜ばれ、かつミスも少なくなったので
営業の方、顧客にも喜ばれることはないでしょうが、怒られることは無くなっています

●細工は全然、仕上げはダメだろうなぁ

そのような複雑な機能のほとんどはカットされると思います
すると、１０年以上前の仕様に戻ってしまい
暗黒時代が到来するわけです

経理部門・営業部門ともに人員が減少している中
新請求サブシステムの稼働により更に人員が必要となり

しかし、人員補充はなかなかできず、常時人手不足状態

新請求サブシステムについて細工は流々仕上げを御覧じろ・・・ではなく
細工はボチボチ仕上げは見ない方が良い・・・みたいな

●同じような請求額に？

請求と言うものは、お客様にお支払いいただく金額を提示するものです
提示した金額がお客様に納得して頂けるならば、引き続き取引をしていただけるでしょう
逆に言えば、納得して頂けない（たとえば同様のサービスを他社から安く提供されるとか）場合

お客様は当社から離れていくでしょう

なので、先も言った通り
●顧客が納得できる金額の計算
●当社が泣き寝入りしないで済む金額の計算

もう、この辺は企業秘密ともいうべきノウハウの部分です

単純に示すことが出来る点としたら
Ａ社もＴ社も顧客が１０００社　その顧客の代理店が各１００００社とします。

Ａ社では、顧客ごとに割引率が設定されています
まぁ、これは当社もです

請求額（ここで請求額は整数、割引率は千分率となります）計算は
Ａ社：代理店ごとに請求額を計算し顧客ごとの割引率で計算、小数点第二位を切り捨て
　　　顧客ごとに代理店の総計を算出し、請求書額面額とします。
Ｔ社：代理店ごとに請求額を計算します
　　　顧客ごとに代理店の総計を算出し、総計に顧客ごと割引率で計算し、請求書額面額を算出します
この両者の違いによって、１０００社請求額面額合計は理論値で、￥４９０，５００になります

これは、経理をされていた方なら簡単に理解できると思います。
Ａ社の請求額計算方法とＴ社のそれの違いは、割引率をどこでかけるか？です

ちなみに、我々と代理店の間には契約関係は全く存在しません。
なので、代理店の請求に対して割引率を乗じて計算する義務はないし
義理も人情もありません

でも、Ａ社ではそれを行い、損失を発生させています

●請求について

昨日も、新しいサブシステム
新請求システム・・・新請求サブシステムの構築のため
オンライン会議に産機しました

その中で、グループ各社、各々の請求処理方法を持ち寄り
新しい請求システムを構築しようとするわけですが
その会議中、我が上司から驚きの言葉が出ました

●簡単なんです

請求額の計算なんて簡単なんです
らしいです。
一体全体、我が上司はどれほどすごいスーパー脳の持ち主なんでしょうか？
それとも・・・・スーパーＢａ？ａでしょうか

なぜ簡単なのか？
それは計算するだけだからだそうです

●今まで何だったんだろう

これまで、初期の請求額計算は確かに今に比べたら単純でした
初期って言うと５０年ぐらいまえですね
その時は今よりは簡単ですが、それでも他業種に比べれば・・・

そして、５０年経過した現在
その全貌を熟知している人間は数えるほどしか・・・

それを、簡単って言いきる上司は
とてつもなくスーパー超人脳をもってるはず(笑)
昨日の、会議の内容を別の角度から記したブログ
新（笑）請求システムの設計が始まったけど

●敏腕経営者と・・・

先代のグループ経営者は、営業上がりでしかも人情に熱い方
従業員一人一人の家族構成や悩みなども知りつつ優しい言葉をかけてくれる方
しかし、請求計算については厳しい方・・・と言うよりは論理的

聞いた話ですが、２０年ほど前に請求システムを更改した際
システム部門が仕様策定し開発した請求システムを作り直させました

それは、請求額計算結果を整数にして、小数点以下切り捨てとしていました。
当時のグループ経営者は、それを小数第一位まで算出するようにと再作成を指示
でも、それによって、単純計算で、毎月４５万円ほど売り上げが向上するんです

パートさん４人分ぐらいですね
小数点桁数を一桁増やしただけで

このような端数誤差とかを考えると請求額計算ってそんなに単純なものではない

●請求額計算何て簡単

それを簡単なものと言い切る我が上司
あまりにも請求を舐めすぎてるとしか思えない

今回は、グループ経営者が変わっているので
出来上がったのがどうなるのか？
見ものですね

●ゆうちょインターネットバンキング

私は、キリスト教会の会計担当執事でもあります
２００５年、教会のＩＴ化が叫ばれて
それまでアナログ的処理だらけの会計処理について
１から会計処理を作ることになりました

今では随分と楽になっています
アナログ時代は、１日分の処理をするのに５時間以上かかっていました
今では・・・僅か２０分程度

ただ、今の時期、年度末
会計年度中に（つまり３月３１日までに）
今年度中の支払いを済ませておかなければなりません。

と、言う事でインターネットバンキングで
サービスプロバイダーにお支払いをしなけれはなりません。

●不親切なインターフェース

振込元口座はゆうちょ銀行なので、
ゆうちょ銀行のインターネットバンキングで振り込みます
いつもやり慣れているのですが、今回は自宅にて

なので、ログインユーザー・パスワードなど、
1つ1つしっかり確認して処理しています

２件の振込があり、２面目で・・・

2軒のうち１軒は同じゆうちょ銀行のため
１００文字までの文章を送る事ができます
こんな内容です


でも、これで送信しようとしても、使用できない文字があるってエラーが出ました
実は、これは３回修正した４回目バージョンです

みなさん、どこに使用できない文字がありますか？
最初、私はゆうちょ銀行のアプリのバグではないかと

何度読み返しても見つけられません
皆さんは見つけられますか？

●人と言うものは

ほんと、何回見直したことか？
これだけの文字数の文章を見直してもなかなか見つけられませんでした

気を取り尚し、修正したのがこちらです

●改善点

どこが悪かったらお判りになりますか？
きっと次のような表示にして貰えれば、すぐに見つけられたかもしれません