カテゴリー: その他

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

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

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

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

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

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

となる。

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

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

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

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

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

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

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

初期費用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の違い(パッチレベルも含む)をチェックしよう。

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

ルーチンワーク以外には実質的な答えはない。
プロジェクトとはそういうものだ。

何が正しいか、何が正しくないか。
結局のところ悩んでも時間の無駄だ。

計画、実行。
まず、実行することが何よりも大切で、
その後、どうなるか?どうなっているか?

計画通り行っているか?
行っていないのか?

上手くいかなかったらやり方を改めればよい。
まあまあでも、もっと良い方法が良いと思えば
その方法を試してみればよい。

結局、改善を繰り返すしかない。
1回で上手くやろうとすると、
悩むことになる。

それを1000回転、改善のプロセスを
繰り返したほうが良い結果になる。
改善スピードこそが重要だ。

伝票の最終変更時間を取得するには
CDHDR:伝票ヘッダ変更 テーブルより

下記の項目をキーにして
・オブジェクトクラス
・対象値
・変更文書番号

下記の項目を取得します。
・変更伝票の登録日付
・変更時刻

-以上-

バッチインプットで受注伝票(VA01)の購買発注データ登録時、ヘッダの得意先発注番号と明細の得意先発注番号が同一の場合、明細の得意先発注番号がVBKDに登録されない。

R/3の標準仕様で、データ領域の節約の為かと思われる。

■禁句
1.期日を曖昧にする言葉
・早い段階で
・近々に
・近日中に
・随時
・現在～中
・月初
・～月中
・上旬
・下旬
・早急に
・できるだけ早く

■問題から目をそらす言葉
・概ね
・特に問題なし
・比較的
・～面では
・基本的には

■アクションを曖昧にする言葉
・～が必要
・検討を要する

■受身になりがちな言葉
・予定
・検討中
・実施中

■判断・行動条件を曖昧にする言葉
・状況によって
・場合によって
・必要に応じて

近年、企業のシステム構成は複数のサーバーで成り立っている。個別の機能ごとに一つのサーバーで構成されていたりする。

それをEAIサーバーでつなぐ。

本番移行の順番でシステムの構成が一時的に変わってしまう。家庭用のコンセントとはわけが違うのでとても面倒くさい。

これからはEAIは切っても切れないので、
誰もがぶち当たる壁だ。「俺には関係ない」とか言っている人がいるかもしれないが、周りのだれかが面倒なことをやっている。

でも、保守を考えると複数のサーバーに分散しているのでリスク軽減にはなっている気がする。

移行リハーサルでは、各サーバーのテスト機が用意できないと、切り替えミスで、大変なことになったりする。

最低でも、各システムのネットワークが、テスト用と本番用で２つ存在していることが望ましい。可能なら開発、テスト、本番の３ネットワーク構成が理想。

維持費は、結構かかりそうだけど。