カテゴリー: その他

出荷の出庫取消をするとき、
取消日が異なると面倒なことになる。

対策としては、
Exit等で出庫日と同じになるようにしておく等をオススメする。

面倒なので使用禁止も良いかもしれない。

一般的なオペレーションとして、 請求伝票取消、出庫取消、出荷伝票削除、受注伝票拒否理由設定で対応する。

テスト方針に必要な項目 タイトル はじめに(下記の概要、前提条件) 目的(主とする目的) 実施内容(確認する大項目、方法、実施するテストレベル) テスト担当実施者(担当する部署、チーム) テスト環境 開始条件 終了条件 テストの進め方 テスト結果対応

さすがに内部統制がうるさいこのご時世に
ドキュメントなしでやっちゃう(ソースコード変更)ことは無いとは思うが、昔は適当だった。

もちろんちゃんとやっているPJもある。

今は、当然そんなことは許されないのだが
過去の遺産というか負債を見る機会があると
よくこんな文書で実装したなと驚く。

間違いなく言えることは
レビューされた文書ではないということ。

本で言えば
編集者のチェックを受けずに
いきなり出版するようなモノ。

当然トラブルが続出する。

おそらく、内部統制で
いろいろな証跡を残さないといけなくなるのだが
取るに取れないといった状況に追い込まれる
システム情報部門がきっとあるはずだ。

決して少なくないと思われる。

どちらかだけに固執すると
意思疎通は難しい。

文章を読むことで理解する人と
言葉を聞くことで理解する人がいる。

読んで聞かせるというのは
上記の二つをあわせているので
それぞれがカバーできる。

さらに、図で説明するともっと理解しやすくなる。

同じ事を、
様々なアプローチで表現することで
いろいろな人が理解しやすくなる。

あいつは何度同じ説明をしても理解しない。
なんて愚痴っている人は
何度も伝わらない説明をレコーダー再生のように
繰り返していることに気がついていない。

自分の言いたいことだけ言って
それでおしまいでは、良いコミュニケーションとはいえない。

どうやったら伝わるか?
伝えようとするプロセスを考えるのもスキルの一つである。

ネット上で拾ったもの。
どこで拾ったかは忘れた。
参考までに。

低品質アドオン機能群が
現状把握を困難にし、
わずかな改修をマイナスのレバレッジで
高コストへと引き上げる。

プロジェクト中のプロセスがしっかりコントロールされていないプロジェクトが完了し運用され始めると、
数々の低品質を盛り込んだ状態になる。

調査しようにもドキュメントが低品質でドキュメントの体をなさない。
すると、より上流のドキュメントを見ることになる。
ココで分かればよいのだが、そうでない場合も多い。

その場合、「何をしたいか」「何の目的か」が不明となる。目的が分からなければ、「何が正しいか」も「どうあるべきか」も不明だ。

お客様はそんな現状を知らなかったりするので、
何でこんな簡単なことが分からないんだ?
とか、たったコレだけのことでこんなに費用がかかるのか?

となる。

最強チームで組織的にコントロールされたプロセスで実践されたプロジェクトならば、少々の時間コストで対応可能になる。

高い人件費を維持し続けることで、
柔軟性と機動力を持つ「システム」とそれを維持する「組織力」が手に入る。

逆に、安い人件費では、
硬直した動かない「システム」しか残らず、
「烏合の衆」となる。

高い人件費 + 組織力 = 使えるシステム
安い人件費 + 数 = 動かないシステム

パフォーマンスを考えたら、
人件費は高くても良いことになる。

作ったら最後、
そうそう捨てるわけには行かない。
数年は使い続けなければならない。

そうなると、動かないシステムは
ランニングコストが高い。

初期費用100万円の電話で通話料が1分1円の電話と、
初期費用0円の電話で通話料が1分1万円の電話があったとする。

この場合、お客様の選択肢はどう考えても前者となる。
システムの品質も同様だ。
お客様から見れば、後者はもはや詐欺に近い。

だが、名だたる日本の大企業の中には
後者のようなことをやっているところも無いとは言えない。

不況の時代には人件費が比較的安く
営業力が無い企業のスタッフがアベる。
そこそこの値段で、高度なシステムを作り、
維持する組織が手に入れることが可能になる。

今、投資できる企業や個人が勝ち残る。

■タイトル
ABAP 実行時エラー
LIST_HASH_BAD_LENGTH

■原因(事例)
NEW-PAGE PRINT ON.とNEW-PAGE PRINT OFF.はネストできない。
ネストした状態でWrite文を実行するとショートダンプすることがある。

■対策
・ネストをしない
・次のNEW-PAGE PRINT ONの前にNEW-PAGE PRINT OFFを行なう
・GET_PRINT_PARAMETERSのOUT_PARAMETERSを使いまわししない

移動タイプ=561で入庫する。品目が標準原価の場合、標準原価で評価され、異なる金額を入力すると差異は、価格差異勘定に転記される。

移動平均原価の場合は、金額を入力するとその金額で品目が評価され、品目マスタの移動平均原価が更新される。

金額を入力しなければ、品目マスタの移動平均原価で評価され、品目マスタの移動平均原価は更新されない。

同じソースコードを、
バージョン違いの環境で動作させようとしたら、
動きがおかしい・・・。

そういう経験はないだろうか?

実は、そこには、
大きな問題が隠れている。

SAP標準の構造、汎用モジュールの違い、その他オブジェクトの違い等がある。

なので、その調査を行わずに、
スケジュールを組んだとき、
予定外のトラブルに巻き込まれる可能性がある。

また、バージョンが同じでも、
サービスパッケージの違いで
同様の現象が起こる場合がある。

テンプレート導入時は、
必ず、調査フェーズを確保して、
その調査結果によっては、導入を見合わせるか、
もしくは、再見積もりが発生するようにしておくことをオススメする。

この、「調査フェーズ」を
用意しなかったために、顧客とトラブルのは
可能な限り避けたい。

是非、バージョンの違い、
サービスパッケージの違いは必ずチェックしよう。

他にも、バージョンで
OSの違い、ブラウザの違い、
SAP-GUIの違い(パッチレベルも含む)をチェックしよう。

計画作成時は、プロジェクト内で
べーシス、コンサル、開発者、保守など、
十分に検討して、営業やプロマネ単独での
ジャッジメントは十分避けることをオススメする。