近年、企業のシステム構成は複数のサーバーで成り立っている。個別の機能ごとに一つのサーバーで構成されていたりする。
それをEAIサーバーでつなぐ。
本番移行の順番でシステムの構成が一時的に変わってしまう。家庭用のコンセントとはわけが違うのでとても面倒くさい。
これからはEAIは切っても切れないので、
誰もがぶち当たる壁だ。「俺には関係ない」とか言っている人がいるかもしれないが、周りのだれかが面倒なことをやっている。
でも、保守を考えると複数のサーバーに分散しているのでリスク軽減にはなっている気がする。
移行リハーサルでは、各サーバーのテスト機が用意できないと、切り替えミスで、大変なことになったりする。
最低でも、各システムのネットワークが、テスト用と本番用で２つ存在していることが望ましい。可能なら開発、テスト、本番の３ネットワーク構成が理想。
維持費は、結構かかりそうだけど。
バッチインプットで受注伝票(VA01)の購買発注データ登録時、ヘッダの得意先発注番号と明細の得意先発注番号が同一の場合、明細の得意先発注番号がVBKDに登録されない。
R/3の標準仕様で、データ領域の節約の為かと思われる。
ルーチンワーク以外には実質的な答えはない。
プロジェクトとはそういうものだ。
何が正しいか、何が正しくないか。
結局のところ悩んでも時間の無駄だ。
計画、実行。
まず、実行することが何よりも大切で、
その後、どうなるか?どうなっているか?
計画通り行っているか?
行っていないのか?
上手くいかなかったらやり方を改めればよい。
まあまあでも、もっと良い方法が良いと思えば
その方法を試してみればよい。
結局、改善を繰り返すしかない。
1回で上手くやろうとすると、
悩むことになる。
それを1000回転、改善のプロセスを
繰り返したほうが良い結果になる。
改善スピードこそが重要だ。
移動タイプ=561で入庫する。品目が標準原価の場合、標準原価で評価され、異なる金額を入力すると差異は、価格差異勘定に転記される。
移動平均原価の場合は、金額を入力するとその金額で品目が評価され、品目マスタの移動平均原価が更新される。
金額を入力しなければ、品目マスタの移動平均原価で評価され、品目マスタの移動平均原価は更新されない。
低品質アドオン機能群が
現状把握を困難にし、
わずかな改修をマイナスのレバレッジで
高コストへと引き上げる。
プロジェクト中のプロセスがしっかりコントロールされていないプロジェクトが完了し運用され始めると、
数々の低品質を盛り込んだ状態になる。
調査しようにもドキュメントが低品質でドキュメントの体をなさない。
すると、より上流のドキュメントを見ることになる。
ココで分かればよいのだが、そうでない場合も多い。
その場合、「何をしたいか」「何の目的か」が不明となる。目的が分からなければ、「何が正しいか」も「どうあるべきか」も不明だ。
お客様はそんな現状を知らなかったりするので、
何でこんな簡単なことが分からないんだ?
とか、たったコレだけのことでこんなに費用がかかるのか?
となる。
最強チームで組織的にコントロールされたプロセスで実践されたプロジェクトならば、少々の時間コストで対応可能になる。
高い人件費を維持し続けることで、
柔軟性と機動力を持つ「システム」とそれを維持する「組織力」が手に入る。
逆に、安い人件費では、
硬直した動かない「システム」しか残らず、
「烏合の衆」となる。
高い人件費 + 組織力 = 使えるシステム
安い人件費 + 数 = 動かないシステム
パフォーマンスを考えたら、
人件費は高くても良いことになる。
作ったら最後、
そうそう捨てるわけには行かない。
数年は使い続けなければならない。
そうなると、動かないシステムは
ランニングコストが高い。
初期費用100万円の電話で通話料が1分1円の電話と、
初期費用0円の電話で通話料が1分1万円の電話があったとする。
この場合、お客様の選択肢はどう考えても前者となる。
システムの品質も同様だ。
お客様から見れば、後者はもはや詐欺に近い。
だが、名だたる日本の大企業の中には
後者のようなことをやっているところも無いとは言えない。
不況の時代には人件費が比較的安く
営業力が無い企業のスタッフがアベる。
そこそこの値段で、高度なシステムを作り、
維持する組織が手に入れることが可能になる。
今、投資できる企業や個人が勝ち残る。
どちらかだけに固執すると
意思疎通は難しい。
文章を読むことで理解する人と
言葉を聞くことで理解する人がいる。
読んで聞かせるというのは
上記の二つをあわせているので
それぞれがカバーできる。
さらに、図で説明するともっと理解しやすくなる。
同じ事を、
様々なアプローチで表現することで
いろいろな人が理解しやすくなる。
あいつは何度同じ説明をしても理解しない。
なんて愚痴っている人は
何度も伝わらない説明をレコーダー再生のように
繰り返していることに気がついていない。
自分の言いたいことだけ言って
それでおしまいでは、良いコミュニケーションとはいえない。
どうやったら伝わるか?
伝えようとするプロセスを考えるのもスキルの一つである。
さすがに内部統制がうるさいこのご時世に
ドキュメントなしでやっちゃう(ソースコード変更)ことは無いとは思うが、昔は適当だった。
もちろんちゃんとやっているPJもある。
今は、当然そんなことは許されないのだが
過去の遺産というか負債を見る機会があると
よくこんな文書で実装したなと驚く。
間違いなく言えることは
レビューされた文書ではないということ。
本で言えば
編集者のチェックを受けずに
いきなり出版するようなモノ。
当然トラブルが続出する。
おそらく、内部統制で
いろいろな証跡を残さないといけなくなるのだが
取るに取れないといった状況に追い込まれる
システム情報部門がきっとあるはずだ。
決して少なくないと思われる。
| テスト方針に必要な項目 タイトル はじめに(下記の概要、前提条件) 目的(主とする目的) 実施内容(確認する大項目、方法、実施するテストレベル) テスト担当実施者(担当する部署、チーム) テスト環境 開始条件 終了条件 テストの進め方 テスト結果対応 |
| 一般的なオペレーションとして、 請求伝票取消、出庫取消、出荷伝票削除、受注伝票拒否理由設定で対応する。 |
出荷の出庫取消をするとき、
取消日が異なると面倒なことになる。
対策としては、
Exit等で出庫日と同じになるようにしておく等をオススメする。
面倒なので使用禁止も良いかもしれない。