社内SEの徒然なる日記

年度変わりの組織変更と業務組織の機能集約の影響

■ 問い合わせ

私は社内SEなので、現場の人間から色々と相談を受けて、基幹システムを修正したり、業務の自動化を行ってきました。もう20年近く会社にいるので、私が作ったツールが多数社内に存在しています。

普段は意識していないのですが、この時期(4月、5月)になると、それに対する問い合わせが頻繁に発生するようになります。

何でかというと、年度変わりで組織変更したり、人事異動をしたりするので、担当者が変わるのです。その時に前任者から引き継ぎは行われるのですが、伝言ゲームのごとく情報に漏れが発生して、結局はこちらに問い合わせがくることになります。

・・・そんな、何年も前に作ったものなんて覚えていないよ。

■ 業務組織

さて、勤め先では、今年は管理系の部門で大きめの組織変更が行われました。

その中で、これまでは営業部門の中にいた業務サポートの人員を、一つの業務部を作って集中させることになりました。ですが、まともに機能していないようです。

基本的には営業をサポートする部署ではあるのですが、明確に部署が別れると仕事って頼みにくいんですよね。その結果、誰にも頼めずに自分で抱えることになってしまいます。

前述の問い合わせですが、取引先から送信される納品データを変換して基幹システムに取り込むというツールに対するものだったのですが、私の記憶では業務サポートの人が処理を行っていたはずです。

なのですが、実際の問い合わせは営業の課長クラス。一体どうしたのかと思ったら、これまで頼んでいた人が人事異動で全員いなくなり、部署も分けられてしまって頼めなくなったので、自分でやっているとのこと。

・・・何だかね。

■ 後書き

各部署に散っていた業務サポートの人員を集めて部署を作るって発想そのものは、理論としては間違っていないのでしょうが、現実的にはなかなか機能しないものです。

勤め先でも、管理系の部門の人間の主導で時々行うのですが、数年後には営業から仕事が廻らないとクレームがついて、元どおりに各部署に人を配置するようになるという流れを何度も繰り返しています。

構想としては、各部署から仕事を請け負う組織としたかったのでしょうが、部署が別れた段階で、仕事を頼むのが大変になるので、結局は自分で抱えてしまうんですよね。

さて、今回作った組織は何年持つかな?

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

絵に描いたようなシステム導入失敗の進み方

■ 失敗事例?

ここ数年、会社に銀行出身の人たちがやってきて、新部署を設立して何やらやっています。勝手にやっていれば良いと思うのですが、火の粉が我が身に降りかかってきたので、人ごとではなくなりました。

奴らは、何やらシステムを導入して業務を効率化するとか言っています。

それが悪いとは言いませんが、現状分析も何もせず、ベンダーや商品の選定もせず、これまで付き合いのなかった会社からシステムを購入して話を進めようとします。

口が上手いのか、経営陣にはうけが良いらしく誰も反対せずに導入決定。なのですが、そこからの進め方が・・・

導入するシステムを使うのは営業系の部門なのですが、その打ち合わせには管理部門の人間しか参加していません。

我々システム部門の人間には、一切相談なくベンダーやシステム構成まで決めてしまって決裁まで進めてから、「基幹システムから連携しろ」とかって上から目線言っています。

・・・何か、システム導入が失敗する典型的な進め方だなぁと思う、今日この頃です。

■ 後書き

他所から来た人間は、短期間に何らかの成果を求めるようで、そのために分かりやすいのがシステム導入による業務の効率化です。

だからこそ、システム導入のノウハウを持つシステム部門の承諾もなく話を進めているのでしょうが、さて、どうなるでしょうかね。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

画面や帳票にやたらと*とか#とか付けたがるの止めて!

■ 理解不能の記号

昔々のシステムは、今のように画面を自由に動かすことが出来ませんでした。また、帳票にしても柔軟な出力ができず、多くの制約がありました。

つまり、1画面、1帳票に表示できる内容に限界がありました。

そこで、ある状態を表すために記号を多用していました。例えば、ある状態を表す時に *(アスタリスク)を表示する、とかです。見る方は、記号を読み取って意味を解釈していました。

ただ、この方法には、不慣れな人には記号の意味が分からないという問題があります。

業界特有の表現方法とかなら兎も角、特定の画面、帳票の中での特有の状態を表す区分とかに使うと、もう何が何やら分かりません。

ってことで、私がシステム開発の主担当になってからは、保守が面倒な記号表記は取りやめて、日本語で表現するようにしました。昔のメインフレームと違って、今はかなり柔軟に作れるので、表題とかレイアウトを工夫すれば、案外何とでもなるものです。

これによって、「この * って何?」っていう問い合わせがなくなりました。

■ 帳票の作成

会社の業務処理の変更とやらで新しい帳票が必要になりました。

使用用途を確認して、社内の業務内容を検討した上でソート順だのレイアウトだの作って提示したのですが、かなりダメ出しをくらいました。

その指摘が納得できるものなら良かったのですが、・・・まぁ、この話の流れで分かる通り、条件を満たす明細に *(アスタリスク)を付けろと言うのです。

何でも、帳票の表示項目を増やすためだとか。

いや、今の帳票って指定サイズに収まるように文字フォントを自動縮小したり、段落とかの区切りも柔軟に設計できるので、そんな無理しないでも良い感じに収まるんで、見た人が分かるように日本語で表現しましょうよって言ってるんですが・・・

何だかね。

■ 後書き

もちろん、こんなことを言うのは年配(55〜70)の方々です。どうも、昔からの感覚が捨てきれないようで、何度話しても一歩も引きません。

正直、そう言う見栄えの部分は若手に任せて貰ったほうが良いものが出来るし、本人たちも私が入社した頃には同じようなことを言っていたはずなのですが、何と言うか、年をとるって嫌なものです。

まぁ、正直もうどうでも良くなりました。これ以上言うと私の人事考課に関わりそうなので、もう放っておきましょう。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

今度の開発案件は在庫の発注サポートシステム No1 構想

■ 状況

勤め先では、在庫品の管理は各部署単位で行っています。管理系の部門としては在庫の集中管理をしたいのですが、同じ商品でも部署が違うと原価が異なるため、現場が在庫統合を嫌がるのです。

それに、在庫の発注担当からすると、自分が管理する在庫を使うのは自分の所属部署(つまり、立ち上がって見渡せる範囲にいる人達)だけなので、管理が楽というのもあります。

なのですが、時代が徐々に変わって行って、部署管理から集中管理に方式が変わりつつあります。

■ 在庫管理

さて、そうなると在庫品の荷動きの予想が難しくなるという問題が発生します。受注時に出荷する日付が決まっているのなら話は早いのですが、在庫を使うのは決まっているが出荷日は未定ということが良くあります。

現状の在庫システムでは、現在の在庫数、引当済み数、未引当数は把握できます。出荷日が未定の場合、未引当数にカウントされるのですが、これがいつ頃に出荷されるのか見当がつかないので、在庫品を発注するタイミングが分かりにくくなったそうです。

ってことで、この問題をなんとかする在庫品の発注サポート機能を作ることになりました。

■ 後書き

単純に考えれば、在庫に下限数を設定しておいて、それを下回ったらアラートを上げるという仕組みで良いのでしょうが、これだと問題が解決しない気がします。

色々と知恵を絞っているのですが、過去の入出荷の実績、在庫回転率、出荷数量の標準偏差、発注から入荷までの平均日数、伝票起票から出荷日が決定するまでの平均日数あたりから、適正在庫数を算出できないかと考えています。

理想としては、在庫管理の経験が少ない人でも困らないようなものにしたいところです。さて、上手く作れるかな?

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

基幹システムの移行!(2017)移行と後始末

■ 基幹システム移行

去年(2016年)からずっと取り組んでいた基幹システムの移行(基幹システムの移行!(2017)基幹システムの移行!(2017)の徹夜でダウン(風邪)DBサーバのディスクをSSDにしたら高速移行が出来た)ですが、ようやく完了しました。

しかし、本稼働後に少し問題は出ました。

Oracleのバージョンが11から12に変わったのですが、その影響か一部の処理(というか、SQL)が異様に遅くなりました。DBサーバの膨大なメモリとSSDの力で何とか業務が止まらない程度の速度は出ているのですが、ちと問題です。

統計情報に問題があるのかとも思ったのですが、取得し直しても結果は変わらず。色々と対応方法は思いつくのですが、素直にヒント句を追加して性能の安定を図りました。

他にもパラパラと出てしまいましたが、大きな目線で問題になることはなかったので一安心です。

■ ラックの移設

本稼動から数週間。今度はラックの移設を行いました。

新しいサーバー(などの機器)は、一時的に借りたラックに置いていたのですが、月を跨ぐと費用が発生してしまいます。今更切り戻しってこともあり得ないので、古い機器を撤去して、その場所に移設することにしました。

言葉にすると簡単ですが、IDCの機器って普段は電源入れっぱなしってのが多いので、移設に合わせて電源の入れ直しをするのは実は結構なリスクがあったりします。

電源の入れる順番を間違えると起動しないとか普通にあるし、電源を入れた後でさらに別のサービスを起動しないと行けなかったりと、きちんとシステム構成を把握していないと大問題に発展します。

ってことで、電源の停止&起動の順番を考えて、稼動後の確認手順を作成して、私がいなくても問題なく作業できるように関係者に周知して、そうそう、移設作業中はシステムが使用できないので現場に連絡して、うん、意外とやることありますね。

・・・・・・・・・・・・いや、基幹システム自体の持分は私ですが、ラックの移設って別の人の担当だったような気が。まぁ、別に良いんですけどね。

■ 後書き

遅くなったSQLを見ると、片方はWITHで作った内部テーブルを抽出条件として使用するSELECT文を UNION ALL でくっ付けています。実行計画を見ると、何故かWITHの結果を見ないで妙な条件で再抽出するような奇妙な動作をしています。もう片方はSQLを引っこ抜いて実行計画を見ると特に変な感じはしません。

前者は結構知恵を絞りました。使用するインデックスの指定だけではダメで、テーブルの結合順番まで細かく指定して、ようやく望みの実行計画になってくれました。Oracleのオプティマイザって徐々に良い感じに動くようになっているとは思いますが、逆に言うと妙な動作をするようになったのなら、チューニングも手間が掛かるようになったとも言えるかも知れません。

問題は後者の方です。Enterprise Managerで実行時のSQLを見るとマスタ系のテーブルをフルテーブルスキャンしたり、明らかに参照していない項目を使ったインデックスを使っていたりと、奇妙な実行計画になっています。

しかし、そのSQLを引っこ抜いてSQL Developerで実行計画を取って見ると、良い感じに実行計画を作っています。こういった特定の条件下で発生する遅延って厄介です。

まぁ、実は原因は想像がついていて、おそらくCOBOLから実行しているのが良くないと思われます。COBOLからOracleを使うには、ソースをPro*COBOLプリコンパイラなるものを通して変換する必要があるのですが、その変換に何やら問題がありそうなのです。

こうなった時の対策は、ヒント句を突っ込むのが手っ取り早いです。

いや、正確には動的SQLにしてやればPro*COBOLによる変換を回避できるようなので、そっちにするって手もあるのですが、埋め込みSQLを動的SQLに書き換えるのは少し手間だし、ヒント句の追加に比べてリスクが高くなるので避けたいところです。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop