トップページ

SAP R/3

[Enterprise版Upgrade]
4.6BからEnterpriseのアップグレードに成功しました。インテリグループ社に依頼し、Uptimizer で分析したらスムーズな移行が行なえました。 細かい修正はいろいろあったそうですが、テーブルTVARVがTVARVCに変わる。HRの社会保険関連のバッチインプット項目名称が変わる等のABAP修正がありました。

システム概要

R/3用語

ABAPの例

Dynproの開発

SAPクエリ

R/3の導入方法については既存のシステムをすべてR/3に置き換えるビックバン方式が一般的に推奨されていますが、やはりこれはかなり度胸のいる選択です。うまいインターフェイスで既存システムと連携できるなら、試しに1モジュールだけ導入してみるというのも手です。1社の業者により、ビックバンで一括導入したケースでは、費用面でその業者のいいなりになってしまう危険性があります。やはり多くのモジュールを一気に導入するとそれだけ導入時の混乱が大になりがちです。今のところは、他システムの連携方法としてはバッチインプットとデータダウンロードが主流で、リアルタイム連携は困難ですが、今後はBAPIやRFCを駆使できるレベルの高い業者の出現やEAI技術がすすむと思われるので、段階的な導入でもよいかもしれません。ビッグバン方式でホスト全面移行の場合、すべての帳票の要不要の判断をするだけでもとんでもなく大変です。必要な帳票については、指図書とレポート帳票に分類しましょう。またレポートでも個別データの一覧か、日次、月次、年次集計と分類するのがいいかもしれません。コンサル業者にヒアリングを円滑に行ってもらうために、導入前には既存システムのドキュメント整備を行いましょう。書店で経理や会計、原価計算、生産管理の本を一読することも勧めます。コンサルに自社用語を言ってもわかりません。標準的な業務用語を使いましょう。ERPが何故失敗するのか?何故難しいのかは各モジュールが密接に絡み合っているからです。それゆえ、よっぽど勉強しないと失敗したり、コンサル業者に騙されます(トホホホホ・・・・)。

ABAP開発を委託すると金がかかるので、レポート系の処理ならば、データをダウンロードしてアクセスで集計してます。ダウンロードはクエリをつくるか、簡単なAPAPプログラムを書いてます。単純なテーブルのダウンロードなら、エクセルVBAで自動合成させ、数量などCONCATENATEできないものは、WRITEで文字列型になおしてます(ダウンロードプログラム自動合成VBAの例)。ちなみにACCESSにアップロードするプログラム例もおまけしときます(SQLServerならばDTSが使えますね)。

テーブル名については、ヘルプの技術情報で探しますが、やっぱ構造となっててわからんものが多いです。業者の書いたABAP開発仕様書を参考にしたり、SE11で必死に探してます。SAPスクリプトもダウンロードしてくれっていう要望もあるので、オブジェクトIDを調べ、Read_Textを使ったりします。コンサル業者と契約するならば、オペレーションや業務だけでなく、テーブル構造までよく知っているコンサル、開発経験まであるコンサルに依頼したほうが無難です(SAP認定コンサルといっても単に講習に出ただけで、エンジニアとしてまっとうかどうかは保証できません)。

パフォーマンスについてはST06のディスクレスポンスタイムを参照しています。これが1秒以上になるとやばいです(通常2桁ms)。STATで時間のかなる処理を観察することも結構やってます。db02で容量の大きなテーブルを調べたりします。SM50で読み出しに時間がかかっているテーブルは容量が大きいテーブルの可能性大です。

サーバーにメモリは惜しみなく積んだほうが無難です。レスポンスがどうなるかはとにかく本番で動かしてみないとわかりません。SQLServerなどはEnterprise Edition でないとせっかく積んだメモリも有効活用できないので選定には気をつけたほうがいいです

数ヶ月使うと読み出しが遅くなるテーブルがあるんでインデックスの最適化を行ってます。

バージョンUPのたびに苦労するそうなので困ったもんです。BAPIの仕様もそのたびに変わっているそうです。EAIだと騒いでいますが、システム間連携が容易に可能になるのははるか先だろう。バッチインプットなんて面倒なことはやりたくない!かといってBAPIは仕様がさっぱりわからん!!

すべての企業の業務をパッケージ化するなんて所詮、夢の夢なんで、現実は導入にあたってとんでもない費用に苦しむことになりますよね。SAPの解説書もまだたいしたものが出回ってないんで、EAI関連の拡張はしばらく待ったほうがよさそうみたいです。

 

ERPパッケージに導入に関する苦労は多い。パッケージを製造した会社は、パッケージ本体だけの責任しかとらないので、ADDON開発責任、コンサルティング、パラメータ設定に関しては依頼した業者が持つ。業者サイドとしては、ドイツSAPの開発者ではないので、R/3内部はブラックボックスとして扱っているわけだ。だけど、SAP本体だろうがADDONだろうがトータルとして動かなければ意味がなく、それを最終的にチェックするのはユーザーしかない!

それが真のシステムコンサル、業務コンサルと言えるのか定かではないが、SAPアカデミー講習に出ればコンサルという称号がもらえる。それはモジュールのコンサルであって、企業全体のシステムを把握する能力があるわけではない。導入時はモジュール毎にコンサル、開発者に高い金払って会社に来てもらうけれど、結局はシステム部門がその後めんどうをみることになり、広範囲な知識がないとパフォーマンス障害のようなトラブルに対応できない。

ERPに限らず、企業システムの理解には、ここのオペレーションよりもテーブル構造を理解するのが一番いいと思います。全部をER図で書いたり、DFDで仕様を書いても、カレントな多数のテーブルが存在する大規模システムは何がなんだかさっぱりわからいことになります。この部分はER図的な把握、この部分はDFD的な把握、このテーブルは、ここと、そこと、あそこのモジュールで参照されている・・・のような適切な手段によりシステム把握する能力が必要だと思います。もちろん業務自体の勉強も必要ですがね。

企業にあった最適化を行うにはADDONを組むはめになりますし、ADDONを組むためには結局R/3のテーブル構造を理解していなくちゃならないんです。そんなことをしているうちに、R/3を単なるテーブルのかたまりに思えてきます。そんなことなら最初から企業システムの勉強をして自分でテーブルスキーマを自作したほうが辛そうだけど正解だったかも・・・なんて思えてくる今日この頃です。

inserted by FC2 system