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

●愕然

先週から請求トラブルに対応してきました。
まず、請求額が多く計上されていました。
計算しなおした請求額との差額を算出し、次月相殺することになりました。

まず、現在、請求データベースに登録されている請求額と
誤ったマスターデータで商品販売価格を算出し、
請求データベースに登録されている金額と比較

合うはず・・・なんですが、合いません
原因が分からず、経理部門の女の子に聞いたら、
顧客毎に特別商品を販売し、それはシステムを通さずに伝票で行っているので
営業から経理部門に、顧客ごとにプラス計上してくれと連絡があり、その金額が・・・

何それ？

●手作業が好き

システム使ったら、全部自動的に計算できるのに・・・
誰がそんな手作業の連鎖をさせてるの？って聞いたら
〇ゃ〇ょうだって・・・

●知らないということは

まぁ、〇ゃ〇ょうはシステムをあまり使わんから、何が出来て何が出来ないか分からないんだろうけど
でも、分からないんだったら聞いてくれたらいいのに

わざわざ手作業させて・・・
まさか、こんな身近にデグレの温床があったとは・・・

●DXって言葉なんて知らないんだろうなー

世間では DX (Digital Exchange)が叫ばれて久しいのに
DXに乗り遅れたら生き残れないとまで言われているのに
うちの〇ゃ〇ょうはDXなんて言葉も知らないんだろうなぁ！
いやいや、コンピューターを利用するって考えも無いんだろうなぁ

私は、今回の一件で愕然と、不安と焦燥感を募らせました。

●スタート

最小拠点でグループ統合システムがスタートしました。
もう、見切り発車もいいとこでしたが、
なんとか運用できているみたいです。

ただ、業務が停止していないってだけで
顧客にかける迷惑レベルは増大しています。
本来の約束時刻までに納品できていないとか

それだけではなく、受注入力でも
セットでの受注ができない・・・
システム間連携での不具合が発生し
単品での注文しか受けられないとなっています。

●セットがだめ？

顧客にとってセットでの依頼が出来ないとは、どういうことか？
考えてみてください。
私は息子とよくマクドナルドやロッテリアなどのハンバーガーショップに行きます。

頼むときには、まずメインのセットを選び、次いで単品バーガーを注文します。
ところが、店内に張り紙がしてあって、

えっ？
てりやきバーガーセットと、チーズバーガーを頼もうと思っていたのに・・・
えーと、えーと＜
てりやきバーガーとチーズバーガーと、ジンジャエールと、フライドポテトをお願いします。

めんどくせー

そこのショップ、しばらくすると気づくでしょう。
徐々にお客さんが減ってきて、なぜか店の向かい側にあるバーガーショップが繁盛していることに
だって、単品で注文したらセット価格じゃなくて、単品価格の合計で支払わないとならないから

●恐ろしい

そのため、このバーガーショップでは、
システムに頼らず、セット販売を始めました。
セットメニューを用意して、それで注文できるように

もちろん、セット価格も用意して
すると、何が起こるか・・・

私がてりやきバーガーセットを注文すると
店員はシステムにてりやきバーガーとジンジャエールと、フライドポテトを入力しますよね。
そして、表示された販売価からセット表の価格に変更してお客さんに請求し支払ってもらう。

それだけではありません。
電子決済をするために、レジシステムに割引入力を行わなければなりません。
引き算しないと・・・

そして、販売商品の売れ行きなど統計資料を作成する時
システムが出力した情報を手直し・・・

新しいシステムが出来て、どれだけ手間が増えたことか
この比喩は、なかなかいい比喩です。
実際に最小拠点では、セットで依頼された注文を
手作業で単品に分解しているのですから

●あと8か月

私の会社に導入されるのは
8か月ごとなりました。

いろいろ出てくる不具合とそれに対する対策
対策っていっても、
対応できないから、これで行こう

さっきのセット販売は中止となりました。
おいおい、ホントかよー！
電子商取引している顧客はセットでオーダーを投げてきているのに

破綻
の字が頭の中をグルグル回っています。

よく、稼働判定でＯｋが出たもんです。

●リリース

リリースしました
って、プロジェクト管理ツールに掲載されていました。
そのプロジェクト管理ツールに掲載されている不具合

●見切り発車

障害がかなり残っているのに、どうして本稼働に踏み切ったんでしょ？
かなりって１桁じゃないですよ！
数十のオーダーであります。

これらを全て運用でカバーするんでしょうか？
運用でカバーさせられるものにとっちゃ、たまったもんじゃないですよね。
見切り発車もいいとこです。

●満身創痍

スタート時点から満身創痍ですやん
スタート時点から背水の陣みたいな感じ
後がなくて、何か一つ致命的な問題が発生したら

終わり

●慢心装威

これは、ここまでやったから
何とかなるだろうと言う
慢心

そして、何らかの圧力がかかったんでしょうね。
恐らく・・・け〇え〇そ〇から・・・
これこそ装威ですよね。

●判定会議結果

昨日、行われたはずの判定会議（グループ統合システムを最小拠点で稼働させるかどうか判定する会議）の結果が届いていなかった

●届いていたのは

またまた、不具合が見つかったとの報告
しかも、顧客クレームに直結するような
これほど、バグが取り切れていないなら

●これで、リリース？

ないないないないないないないない
こんなんでリリースしたら、
仕事しなくて良くなってしまう・・・

もちろん、給料も無くなってしまうでしょうね

●判定会

さて、ゴールデンウイーク連休も最終日
今まで長きにわたって構築してきたグループ統合システム
明日がリリース予定日

いよいよ本番稼働となります。

しかし、本日、サービスイン判定会議が有ります。
これは、明日から本稼働させるか？　延期するか？
現在のシステムの成熟度合いから判定するものです。

●現状

は、どうかと言うと・・・
私としてはおよそ受け容れられない不具合が昨日も発生しています。
運用でカバーできる代物ではありません。

これで判定会議を予定するって
意味が分かりません・・・
結論の分かっている会議なんて


じゃないですよね〜
小田原城に立てこもる北条家の重臣たちに失礼です。
小田原評定は、豊臣秀吉に攻め込まれ小田原城に立てこもった武士が、どーしようあーしようってだれも責任を持たず、結論の出ない会議を延々と続ける会議の事を言うんですが

今回は、結論が分かっているのに、わざわざ、最小拠点に何時間もかけて集まって会議を開くと言うんですから
このコロナのご時世・・・
移動だけでもリスクがあり、
人数もそこそこで交通費も多額

まぁ、ベンダーさんのシステム開発メニューの一つだから
コース料理を食べて
デザートはお腹いっぱいで入らないけど、出されちゃったからスプーンもたなきゃ！
みたいな感じ？

もう、食べられないよー

●結論はいかに？

はてさて、今日の判定会議で出される結論はどうなるんでしょうね。
経営層の判断は？
我が上司（システム部門）の判断は？
現場の判断は？

●嵐の前の静けさ

あ〜〜〜
何となく
嵐の前の静けさ


みたいな

宇宙を旅してみたい！
日常のいろいろな嫌な事から逃げ出したい！

●五月連休中に

この連休
ゴールデンウィーク
グループ統合システムのリリース準備作業が

●最小拠点で

着々と進行中

でも、先週も
着々と、課題を解決するたびに、さらなる課題が発生して
いかにも、水漏れを塞げば塞ぐほど
別のところから水漏れが〜〜〜

ダムの決壊？
みたいん感じですねー！
もはや、パッチワークでは対応できそうもないぐらい・・・かも

●リリース

私にとっては、到底許容できない仕様が
勝手に決められていて
知らされた時には、仕様は変更できません・・・と

その仕様により影響を受けるのは
可哀想な現場の人たち
力不足でした・・・

欠席裁判
そんな言葉が頭をよぎりました。

さて、話を元に戻して
連休明けからグループ統合システムが稼働し始めます。
どうなることやら

●最終判断

ただ、最終判断日は儲けられています。
いわゆる稼働判定と言うものです。
つまり、新しいシステムを稼働できるように準備したのはいいけれど
本当に、そのまま稼働させて問題ないかどうか判断する
そんな会議です。

当然、超重要事項なので経営者が参加しますが、
経営者が稼働判定できるとは思えません。
経営者はＩＴ分野では素人です。
経営者は現場作業に疎いです。

はてさて、どんな判定がなされるやら！
ゴールデンウィーク明けが、ブラックホールウィークにならなければいいけれど・・・

●石橋をたたいて渡る

日本にあることわざの中でよく知られている句ではないでしょうか。
これは、堅牢に見える石橋、ただ石橋でも老朽化し内部に微細な日々があり、衝撃で崩壊するかも知れないので、叩いてみてそうではないことを確認してから渡ろうという、『用心に用心を重ねる』または『念には念を入れる』という慎重な態度を表す言葉ですね。

●腐った木の橋を叩いて渡る

こないだ、某ＩＴ企業の営業マンと話をしました。
当然ＩＴ企業なので、石橋を渡るのかなって思いました。
しかし、その営業マン

『私は腐った木の橋を叩いて渡る』って言っておられました
営業という仕事では、そんなに慎重論ばかりでは売り上げに繋がらない。
人と人との間の感情的な距離感をつかんで、

ここまでならＯｋ
これ以上はダメ

って言う微妙なところを探りながら
商品やサービスを販売する必要があるからと・・・

なるほど

●綱渡り

ところで、今・・・進めているグループ統合システムはどのレベル？

�@石橋
�A腐った木の橋
�B綱渡り

はてさて、皆さんはどう思われますかー

●私が思うに

�Cです！
今朝の会議に参加していても・・・
どうしても、綱にさえなっていないような気がしました。
つまり・・・糸渡り

●少し除き見

おはようございます。
リリースに向けて日曜日も作業していたはず
と、言う事で、会社のネットワークに接続して、少し確認

●予想通り？見なきゃ良かった・・・

げっ
サーバー障害で緊急リリース・・・とか
なに、これ？

新車を買って、納車されたから早速ドライブーって思った矢先
パンクしてるやーん！
マフラーが外れかけてるやーん！

みたいな

●計画は進む？

それでも、計画は進んでるみたいで
Goに向かって
でもね、嬉しくなーい

●肝試し？

さぁ、新システムでの新運用だー！
喜ばしいかぎりだー！
ってもろ手を挙げて喜べるんだろうか？

私には肝試しにしか思えない・・・
失敗した時は誰が責任を取るんだろうか？
顧客に迷惑をかけないようなセーフティーネットはあるのだろうか？

●休みだけど

今日は、会社自体は営業していますが、私は休暇を取っていました。
ただ、今週発生した請求トラブルで、経理部が私を頼ってきたため
休暇返上で対応しようかと思いました。

ただ、根本原因となったマスタデータの不備は
元部下が土曜日に対応すると言っていたので
彼に任せて、予定通り休むことにしました。

●今週発生したトラブル

しかし、今週発生したトラブルは請求に関連することです。
しかも正規の請求額より多めに請求すると言う過請求トラブルです。
これは、請求書を受け取った顧客にすると、とんでもない事態です。

何故なら、これらの請求書の締め日は15日と20日で、これはそれぞれ
15日締め：2022/3/16〜2022/4/15
20日締め：2022/3/21〜2022/4/20
が請求対象日となっていて、
3月期決算の顧客にとっては、2022年度の経費が確定できないことになっているからです。

年度ごとに決算、予算組みを行っている顧客にとっては、これはゆゆしき問題です。

●確認はしたけど

事は緊急を要する・・・と私は認識しています・・・のに
元部下は・・・認識していないようです。

今まで、教えてきたつもりでしたが
私が居るから何かあったら私に任せておけばいい・・・式で

関連する各々の立場の人たち・・・当社経理部、当社営業部、そして顧客・・・が
どのような形で困るのか？
そこを理解して初めて、どう対応すべきかが肌身に感じる事ができるのに

どうやら、その点までの教育が出来ていなかったようで

●ずっと待機

と言う事で、朝一で経理部に連絡を入れ、
もしシステム部門に催促して、何かこじれそうだったら連絡しておいで
と言っておきました。

そして、ずっと待機していましたが、問題が無かったのか連絡がありませんでした。
ただ、休みの人間に仕事の連絡をするのを遠慮している・・・ってのもあるかも知れませんが

そんな事より、顧客 1st で動かないと・・・
今回は顧客要望ではなくて、明らかに当社の落ち度ですから
可及的速やかに解決して、顧客への迷惑度を出来るだけ下げることが先決

その後、今回の原因を追究するのは一次対策が出来た後で、じっくりと(^_-)-☆

●もう少しで午前様

昨日は、久々に長時間労働をしました。
タイムカードを打刻したのは２３時３９分
もう少しで午前様になるところでした。

でも、ある程度目鼻が立って帰ることにしました。
それは・・・・

●高齢者には堪える

私ももうすぐ還暦を迎えます
年を重ねるごとに徹夜とか長時間労働が出来なくなってきています。
なのに・・・

●事の軽重

昨日は、請求関連のトラブルで
経理部門から『助けて』って泣きついてきたので
覚悟を決めて、問題解決に当たりました。

原因はマスターデータベースの設定不備です。
商品価格を設定しているマスター情報に誤りがありました。
なんで、こんな結果になったのかって言うと

商品価格を決定する営業部から提供された資料に誤りがあったからです。
ただ、その誤りはシステム部門でも容易に見つけられるようなものだったんですが
システム部門ではスルーしてしまっていました。

●最後の砦

言い訳ですが、組織体制が変わって
私の会社のシステムは元部下が責任者となって切り盛りしています。
ですが、私が彼に十分に引き継げていなかったんでしょう。

どうすべきかは元部下も認識していたんですが、
何故そうしていたか・・・は頭に入っていなかったようです。
なので、軽く考えていたんでしょう。

聞くと、営業に確認して、営業がそれでいいと言ったから・・・
そのままで運用していたとのこと
私が上司だったら、ブチ切れていたところでした。

結局、毎月15日締めと、20日締めの顧客、
併せて100件近くで、数百円から数千円の過請求が発生していました。
請求額から考えると１％未満何ですが

過請求は１円たりともしてはなりません。
信用問題になるからです。
それ以前に、詐欺でしょ！　契約に従った請求額以上に請求するとは・・・

話を元に戻して・・・
営業部は経理部に対して、顧客ごとに誤った請求額と正しい請求額の対比表を作れと指示したらしいのです。
経理部はすぐにそんなことが出来ないので、私にヘルプを求めてきたんです。
まあ、当社の現行システムの請求機能については一番良く知っている・・・ので

請求機能は、当初のシステムに営業からの様々な要望に従い
私が改修してきました。
なので、元々の本システムに比べたらかなり高機能になっています。

それゆえにめちゃくちゃ複雑になっています。
IBM Power (AS/400) の性能が無ければ、とんでもないことになっていたでしょう。
どうかって？　処理時間がかかり過ぎて、経理部の請求書作成業務が戦争になる

あまりに複雑なのでマニュアルを作りました。
それでも、私のマニュアル作成能力がザコ過ぎて

マニュアルだけでは分かりにくーいってなっちゃいましたー