ABAPの基礎知識 出力系その2

出力系その2は、管理帳票についてなのである。
しかし、またしてもABAPの基礎知識というよりも、
プロジェクトの進め方みたいな話になっていくのである。


まず、この事実を確認することからはじめよう。
「R/3を導入するした際、既存の管理帳票は、ほとんど必要がなくなる」
なぜこう言えるのか?それには2つの側面がある。
1.一般的なものは、そもそも標準で用意されている。
2.現状のシステムと考え方自体が違うため、帳票出力自体の意味がなくなる
しかし、この事実をユーザに確認してもらうのが一苦労である。
特に、2.の側面に対する理解を求めるのは、非常に難しい。


ちょっと例をあげよう。
「たこふじ」シリーズの中で、「月末確定方式」と「都度確定方式」の話をした。
そもそもの考え方が変わってしまう、という例である。
この「考え方」が変わったために、必要とされなくなる非常に一般的な帳票がある。
在庫の受払帳である。


一般に、在庫の受払帳は、前月残高・当月入庫・当月出庫・当月残高を
品目ごとに、在庫数と金額に関して表示するものである。
この帳票の意味は、月次総平均で在庫の評価額を出すための計算表なのである。
したがって「都度確定方式」と採用するR/3において、
理屈では、この在庫の受払帳は、必要のない帳票である。
なので、R/3には、該当の帳票はない。


ところが、この事実を、論理立てて、毎回説明するのだが、
「それでは在庫管理ができない」
という反論を、ユーザから受ける。ほぼ100%である。
在庫が現物とデータとで合わなかった場合、受払帳がないと追跡できない、と、言うわけである。


在庫の追跡は、基本的にある期間の入出庫伝票の明細を調べないとできないことである。
で、R/3には、品目と、FromとToの日付を指定すると、Fromの日の残高、入庫、出庫、
Toの日の残高を表示し、その間の移動明細を表示する機能がある。
つまり、在庫の追跡に関しては、その機能を使えばいいのである。
そのことを示すと・・・
「一覧になっていない」
言ってることがむちゃくちゃである。
在庫が合わない、という状況ならば、合わない品目は特定されているはずだ。
繰り返しになるが、その状況がなぜ起きたのかを調べるには、
その入出庫の明細を追う必要があるのだから、ある期間の残高を品目ごとに出し、
その移動明細を示す機能こそが必要な機能なのだ。
しかし、要するに、「今までと違う」という理由のみで、
「受払帳は絶対必要である」
という主張になってしまうのである。


例として在庫の受払帳をあげたが、管理帳票を作りましょう、と、
ヒアリングをはじめてしまうと、ぜ〜んぶこの調子で、結局今まで通りの帳票を
全部作るハメに陥ることが多々ある。
ユーザに、既存帳票の一覧を出して、
「必要なものに○をしてください」
というやり方も同様である。
んなもん、ほとんど○がついて返ってくるに決まっているのである。


まあ、しかし、ユーザ側にとってみれば、怖くて「いらない」なんて言えるか!!
というのが、本音のところだろう。
いくらプロトタイプを実施する、と、言ったところで、ユーザ側が新しい仕組みでの
業務イメージを構築できるか、というと、苦しい部分はやはりある。
特に、管理帳票というのは、通常業務の流れの中には入ってこないものである。
新プロセスフローにおいては、どのようなチェックが管理者として必要なのか?
そしてそのチェックをするためには、どのような帳票が必要なのか?
イメージしようと思っても、やはり難しい。
勢い、「今までのものがないと困るよね」という思考になり、
一覧表はほとんど○、という事態が起こるのである。


ではどうするか。
しらばっくれるのである。


管理帳票に関しては、クエリで作製できる範囲に押さえておく。
それ以上の要望が出ても、しらばっくれて、ほったらかしにするのである。
これには多少のテクニックが必要だが、
「こっちのほうが優先度は高いでしょう」
と、実行系の仕組みを優先するように仕向けて、ほったらかしにするのである。
いつまでか?
カットオーバーまでである。


で、一回目の月次の締め処理が終わると、ほとんどの場合、ほったらかしておいた
管理帳票要件は、そんなことがあったことすら、皆さん忘れている。
一回目の締め処理が終わって初めて、新プロセスフローにおけるチェックの勘所が
共通認識として現われるのである。
この段階で初めて、おもむろに優先順位をつけ、管理帳票を作成していくのである。
その管理帳票は、ほとんど標準機能でカバーできるだろうし、
そうでないものも、クエリを作れば大抵カバーできるはずである。


まあ、しかし、この段階になっても「受払帳は必要だ!!」と言われることは多い。
もう、仕方がないので、作ってあげるのも一手である。
仕方がないよね、「ユーザ要件」なんだから・・・
ため息の一つをつくのも、許してもらえることだろう。