第八章

ＳＡＰ 本番稼動に向けて

ＩＴライブラリーより （pdf １００冊）http://itlib1.sakura.ne.jp/

一般社団法人

情報処理学会 正会員

腰山 信一

ftks7856@ybb.ne.jp

2

他の章は下記をクリックして

ＰＤＦ一覧からお入り下さい。

ＩＴライブラリー （pdf １００冊）http://itlib1.sakura.ne.jp/

目次番号 １８０番 ＳＡＰ 基本からＳＡＰ ＨＡＮＡまで

全９冊 ８００ページ

ＳＡＰ 導入プロジェクトの準備

3

導入プロジェクトの準備

導入ブロジェクトは、一度に基幹業務全般に渡る機能を入れてしまう「ビッグバン導入」にするか、今年は会計、来年は物流管理というような「段階的導入」にするのかの決定から始まると言われます。

段階的導入の方が作業負担を分散できますし、コストも人材リソース的にも余裕を持ったプロジェクトになります。

でも、業務統合が不十分だったり、本来の目的である業務改革に踏み込めなかったりします。

多少の機能を積み残すにしても、ここはERPの最大の導入効果を得られる一括導入に絞って計画を立ててみます。

4

対象領域の確認と計画立案

導入プロジェクトの準備は、SAP ERPプロジエクトの初期計画を立てて、準備を行うことが目的です。

導入の初期段階から以下の問題に取り組むことにより、プロジェクトを効率的に進め、かつSAP ERP導入を 成功させるための確実な基盤を作ることができます。

注意点は、対象領域の「ぶれ」を起こさないことです。 分析機能やシステム連携機能などSAP ERPの機能を知るうちに、当初の要件にはなかった対象領域を拡大し、費用の問題から その分ほかの要件を狭めて帳尻を合わせるなどして失敗した事例もあります。

なぜなら単機能として実現できることが増えても、ERPを導入したことによって当初に期待された成果が薄くなるからです。

5

プロジェクトの 目的 と KPI を定義する

次にプロジェクトの検証と 受け入れの基準を決めます。

SAP ERP導入のチームメンバーが通常業務を行いながら、片手間で参画してもプロジエクトは成功しません。

数多い打ち合わせや 資料の作成に時間を割き、担当業務は同じ部のメンバーがこなす、まさに全社一丸となったサポート体制が必要です。

役員、全従業員がSAP ERP導入に対する会社としての意義、プライオリティの高さを認識し、プロジェクトメンバーが導入作業に 集中できる環境を提供できるかが１つの鍵になります。

6

導入戦略の定義

SAP ERPを導入する際の方針を決めます。 SAP ERPパッケージにどこまで合わせるか ということについて、３つの標準化を検討します。

(A)勘定科目、仕入先、得意先、品目等のマスタを標準化

(B) 業務プロセス単位の標準化

(C) 各業務単位の標準化

7

しかし、すべてを標準化することが好ましいとは限りません。 自社の価値観に合う独自のルールや、一見無駄が多いようで顧客ニーズに応えている、有意義な業務が存在するからです。

そのような業務フローは ERP導入者にとって、価値の高いオリジナル・モジュールです。

導入範囲の明確化

SAP ERPの持っている機能、例えば生産、購買,調達、物流、販売、会計といたコンポーネントを、各々の作業レベルでどこまで使用するかを決めます。

8

例えば、物流についてなら入出荷等、荷物の流れは使いますが、入り口のスマートデバイスを使った入荷検品だけ既存のシステムを使うといった判断をします。

ほかにも、SAP ERPに載せ替えてでも続けるべき業務があるかを検討します。

共通部分、例えば受注、購入、出荷、会計などにSAP ＥRPを使用するものと思います。

発生の頻度が少なければ切り捨てるのも一案ですし、アドオン等追加開発の予算との兼ね合いで採択する場合もあります。

9

アドオンを起こす場合は、導入範囲に合致していて、本当に必要かを注意して検討してください。

「対象領域の確定」 「プロジェクトの目的」 を明確にして、社内のコンセンサスを得て、スタートすることが重要です。

10

実現したいことと コスト

SAP ERPの導入の大くくりの予算を 算出するとき、対象となるのは「導入の期間」、 コア要員をサポートするために「新たに雇用する人員(派遣社員など)」、 導入コンサルタントなどの「外注費」、SAP ERPを展開するのに必要な 「ハードウェア」、既存のシステムとSAP ERPとの連携に関わる「開発費用」などです。

これらリソースの配分を誤ると、苦しいプロジェクトになりますし、かと言って制限なく予算を積み上げることもできません。

地道に１つずつ積み上げて、予算を計算します。導入コンサルタントが 引いてきた予算も同様の手順で判断します。

11

プロジエクトの 全体的なスケジュールと導入順序の定義

何気ない作業、細かい業務の ビジネスプロセスやフローをまとめるのは、面倒ですが、何時間あれば、まとめられるか といった工数は予想できます。ポイントは 予測できない作業の工数を見積ることです。

意志決定をしないと、次のステップに進めない (クリティカルパス) ステージがいつ、どれくらい発生するかとか、要件を決定できる人が 何らかの問題で欠如した時のフォローができるか、などを加味できると スケジュールの精度が高まります。

12

不確定な要素ですから、すべての要件を列挙するのは難しいので、導入コンサルタントと相談して、根拠のわからない予備日数は理由を確認しましょう。

プロジエクトの組織、委員会の設置プロジエクトに 参加する総人員の確保も大事ですが、コアになるシステム管理者の人員、意志決定者のスケジュールを確保できるかが重要なポイントです。

システム管理者の人員はSAPコンサルタントが去った後、最後の砦として社内の各部署に対して引き継いだSAP ERPとその周囲のシステムについて、知識を提供するからです。

13

各要件の細かい業務を詰める際、意志決定者に判断を仰ぐ前に、関係者でアイディアや業務の 洗い直しをする場を委員会、あるいは部会として設置します。

限られた時間の中で、すべての業務を思い出すことは難しいので、事前に主要業務に携わる人員で集まり、アイディアや問題点を列挙します。

プロジェクトメンバー以外の人員も加え、現場で思うところを提示してもらいます。 代表者はその意見をもって プロジェクトに参加すれば、社員の一体感も高まります。

14

工数、資源の割り当て

伝票、帳票などの必須アドオンや 非SAPシステムとの連携など、できなければ 業務が回らないモジュール案件から、限られた開発費を充てて行くと良いと思います。

特にSAP ERPと連携する 非SAPシステムと連携する場合は、早く開発が終われば テストもできて、より精度の高いプログラムになります。

15

16

ビジネスの設計

17

ビジネスの設計

要件ワークシップで集められた結果を詳細に記述した、ビジネス設計書を作成します。

関連するビジネスシナリオ、ビジネスプロセス、および プロセスステップが階層構造で 編成されるプロジェクト構造を登録するのです。

またプロジェクト文書を登録して、個々のシナリオ、プロセス、または プロセスステップに割り当てることもできるので、各プロセスステップに トランザクションを割り当て、ビジネスプロセスをSAP ERPで どのように実行するかを指定できます。

会社の業務プロセス要件を 文書化することで、SAP ERPを使って会社の業務をする方法について、共通の理解を得られます。

18

プロジェクトの目標と目的の見直し

ERPパツケージを導入して間もなくすると、できることより、できなくなる事が多いと感じるかもしれません。 これまでは各部が独自のルールを取り入れてシステムを 使えたものが、共通ルールで運営するため、強く制約が入るためです。

新しいシステム、SAP ERPを入れる本当の意味を再度見直します。

ビジネスプロセス要件の分析(フィット＆ギャップ分析)

フィット＆ギャップ分析とは、SAPERPと新しい業務構想と適合するかの分析を行い、新業務プロセスを決めることです。

19

不足、不適合の機能に関しては、BPR かSAP ERPに修正を加えるか、外部システム化するかのどれかを選択します。

外部ツールを含め、最終形のシステム構成図を作成します。

もちろん、業務とSAP ERPの標準機能に大きなギャップがあれば、ほかのERPソリユーションを検討するという 選択肢もあると思います。

ただ、大きなギャップがある業務が 顧客に向いている場合、その判断が正しいかどうかは難しい問題です。

顧客のクレーム対応となると、当初の目的、スコープを忘れ、新しい機能、顧客からの信用を失わない、回復したいと 思うことは少なくありません。

20

ERPで顧客対応を使うことも もちろんですが、その内容によっては別途システムとして、SAP ERPと結果データの連携を 図るといった方針を立てることができます。

ポイントは、例外プロセスをどれだけ提示できるかです。 SAP ERPは日本文化に根付いた「当たり前」を標準と取りません。

特に「返品 (どんな理由でも、品物やサービスが戻ってくることを意味します)」に 関わる対処は様々で、要注意です。

ただ最近の傾向としては、SAPのモジュールが 日本を意識したサービスを提供していますので、日本の常識を前提とした要件の分析も、より精度が上がると思われます。

21

ビジネスシナリオの補正

ビジネス要件を詰めているうちに、業務フローの中に忘れられていたステップ や レポートが見つかる場合があります。 その場合は、このステップで補います。

イレギュラー処理を見つけるコツは、現在運用中の作業を、できあがったビジネスシナリオに 沿って何度か行う方法があります。 また、シナリオのある作業を除いた場合、そのような事態があるかを 確認すると、例外事項を見つけることがあります。

22

例えば、返金処理をする場合、顧客から届いた荷物の 金額をお返しするとします。 ところが、荷物が届く前に 伺っていた内容と実物 とに差があったら、どのような処理を取ればいいでしょうか。

① 荷物の内容とは 関係なく当初立てた額面を 顧客にお支払いする。

②荷物を正とするため、入荷処理の伝票を作成し返品の入荷実績を上げ、その結果を会計に渡して、最初に作った支払伝票は破棄、改めて作成された伝票で支払い業務を行う。

さて、どちらが正しいでしょうか。実はどちらも SAP ERPでは正しく、標準の機能です。

23

新業務プロセスを実現するための 拡張機能の要件定義を行います。

SAP ERPに機能追加する場合も、外部ツールを使う場合も同様です。その際、システム化する必要はなくても イレギユラー処理を思いつくことがあります。

ビジネスシナリオ として 大切なことなので、後々、運用マニュアル等で対応することとして、ここでは処理します。

24

レガシーを生かす

我々が これまで培ってきた技術や知識、自社に蓄積されてきたナレッジを新しいシステムで生かすための作業を行います。

システムを 使いこなすための学習やデータの移行、既存システムを 有効活用しながら、新しいシステムを 使う準備を進めます。

既存システムのレガシーシステムも、すでに安定したプログラムであれば問題はありませんが、たとえばWindows 上で開発され、 Microsoft社が対象以後のバージョンの保守をしないと宣言した場合、新しいプロジエクトが生まれます。

25

プロジェクトチームのトレーニングの実施

チームメンバーがSAP ERPを学びます。 後に エンドユーザートレーニングを行う際、彼らがアドバイザーになります。 システム管理者が受けた教育とは違い、教育の対象とする業務をSAP ERPでどのように行う場合の流れ、手順を学びます。

26

各種要件定疑文書の作成

システムや データ移行方針、各システム・機能の権限の方針、マスターデータや伝票のアーカイブ方針を作成します。 マスターデータや伝票については、項目のマッピングを行い、移行する内容の 検討を行います。

開発システムの構築

暫定の運用設計書の作成、環境構築を行います。 本番稼働環境のシステム技術の設計、運用設計も行います。

27

ビジネス設計書の作成

詳細計画の立案、これまでの まとめをします。

ピジネス設計書を 各部門の主要関係者で共有することで、プロジェクトの全貌が明らかになり、SAP ERP導入に対する モチペーションも上がります。

このフェーズの完了と、次のフェーズの開始の承諾を得ます。

28

29

30

本番稼動に向けて

31

SAP ERP での設定

次に実現したい内容を SAP ERPに限るならば、何をしなければ ならないかをまとめます。 アドオンは含まれますが、外部システム等は含まれません。

ただ、外部システムの設定は 含まれませんが、連携した場合、どのような役割を 果たすかを確認します。

32

パラメータ設定 (プロセステストを含む)

組織構造 や主要コード、処理制御用のパラメータ設定を行い、新しい業務プロセスの機能検証を行います。

業務プロセスが 確定できたら、業務運用マニュアルを作成します。

運用マニュアルに沿って、後は作業を行います。

作業を行いながら、漏れのある業務 や イレギュラーがないかも確認します。

33

顧客固有要件の 実現および統合

拡張した機能のシステム(アドオン)を開発し、機能として品質を確認するため、受け入れテストを行います。

開発した機能の単体だけ ではなく、SAP ERPを含むほかの機能やシステムと連携をし、期待している業務が行えるかどうかを見ます。

ほかのシステムとの 連携は、テスト項目の数が多くなります。特にアドオン要件で多くのユーザーに 関係するのが帳票類の印刷です。

34

時間 リスク

実用的な方法論

実績ある事前設定

包括的な文書

SAPBest Practices

コスト

コンポーネント

SAP Best Practices は、即

座に使用できるビジネスソリューションを パッケージした堅固な基盤です。

SAP Best Practices の実績あるビジネスシナリオによって、

SAP ERP の可能性が引き出されます。

柔軟性の高い Building

Block テクノロジ－を使用して、

ソリューションの導入と調整を非常に柔軟に行うことができます。

包括的な事前設定によって、以下をセットアップ

a) システムランドスケープの全体

b) エンドツーエンドのビジネスシナリオ

設定およびプロセスに関する詳細な文書

わかりやすい方法論: 理解が容易な段階的なアプ

ローチ

SAP Best Practices: コストの削減、時間の短縮、リスクの軽減

35

時間と労力を軽減

完全に文書化された活用性の高い

プロトタイプが短期間で得られ、

スムーズな本稼動ソリューションへの

移行が可能

ソリューションのデモンストレーションにより、以下が容易になります。

ソリューションの確認

導入

個別要件の適用

SAP Business Suite アプリケーションを

迅速かつ容易に導入することができます。

SAP Best Practices 使用

従来のプロジェクト

再利用可能なビジネスプロセスおよび

プロジェクト作業を確認および事前考慮

SAP Best Practices

36

•方法論と内容

•文書

シナリオの説明

エンドユーザ文書

設定およびインストール文書

インストールアシスタントファイル

パーソナライゼーションアシスタント

•事前設定

コンフィグレーション設定

サンプルマスタデータ

インストールアシスタント

印刷フォーム

文書 DVDビジネス文書、技術文書

システムアドオンアドオンには、SAP Best Practices のインストールプロセスに必要なすべてのエレメントが含まれています。

提供 提供

SAPBest Practicesサポート

VSDK システムイメージ

ソリューションコンポーザ

SAP チュートリアル

SAP Solution Manager

デモシステム

パートナサービスの提供

SAP Best Practices: 提供内容

37

140 を超えるバージョンが提供されています。

46 か国、24 業種、9 種の全業種共通、および最新のソフトウェアリリースに対応した Best Practices が世界各国に提供されています。

現在までの出荷件数は 33,770 を超えています。

AFS、自動車、化学、消費財、耐久消費財および家庭電化製品、ディーラー業務管理、ECO、金属製品産業、ハイテク、家庭および個人介護、IMC、ロジスティクスサービスプロバイダ、整備/修理/操作、医療機器、鉱業、小売、製薬、第一次鋼鉄、プロフェッショナルサービス、公共機関、公益産業、水道、卸売流通

業種別の提供製品

BI、BPM、CRM、Portals、HCM、IAS/IFRS、事前定義スマートフォーム、SCM、モバイル資産管理

全業種共通の提供製品

提供されている国

アルゼンチン、オーストリア、オーストラリア、ベルギー、ブラジル、カナダ、チリ、中国、コロンビア、クロアチア、チェコ共和国、デンマーク、フィンランド、フランス、ドイツ、GCC 参加国、ギリシャ、香港、ハンガリー、インド、イタリア、日本、韓国、マレーシア、メキシコ、オランダ、ノルウェー、フィリピン、ポーランド、ポルトガル、ルーマニア、ロシア、セルビアモンテネグロ、シンガポール、スロバキア共和国、スロベニア、南アフリカ、スペイン、スウェーデン、スイス、タイ、トルコ、英国、ウクライナ、米国、ベネズエラ

SAP Best Practices の現状

38

新しい SAP All-in-One ソリューションはSAPBest Practices を強固な基盤として、ただちに使用できるように 事前設定された中堅企業向きのソリューションです。

パーソナライゼーションツールおよびインストールツールが改善されています。

拡張パッケージイノベーションがサポートされています。

地理的および垂直型の対応範囲が拡張されています (例: 電子通信、メディア)。

包括的な SAP Best Practices

39

統合シナリオの事前設定コンテンツBaseline Package* for

<国名> 組織構造

財務会計

販売管理標準原価および

利益センタ会計

人事管理

品質管理生産計画/管理

ロット管理 …在庫/購買管理

US DE CN

KR JP UK

FR NO …

業種別SAP Best Practices for

<業種別> (国名)

かんばん生産管理

保証

見込生産得意先サービス

混合

品質管理製品デザインと設計

プロセス管理 …順序付 JIT

指示

US DE CN

KR JP UK

…

全業種共通

財務会計分析 cProject 従業員セル

フサービス …インタラクションセンタ

SAP Best Practices for <全業種共通>

SAP Best Practices: ソリューション構成

40

統合シナリオの事前設定コンテンツBaseline Package* for

<国名> J02 -組織構造

N70** -

財務会計

J04 -販売管理

B30 - 標準原価および利益センタ

会計

J14 -人事管理

J07 -品質管理

J06 -生産計画/管理

J19 -ロット管理 …J05 - 在庫/

購買管理

US DE CN

KR JP UK

FR NO …

業種別SAP Best Practices for

<業種別> (国名)

A07 - かんばん生産管

理

A20 - 保証

E34 -見込生産

P33 - 得意先サービス

Q25 - 混合

J07 -品質管理

H33 - 製品デザインと設

計

Q29 - プロセス管理 …A03 - 順序

付 JIT 指示

US DE CN

KR JP UK

…

全業種共通

財務会計分析 cProject 従業員セル

フサービス …インタラクションセンタ

SAP Best Practices for <全業種共通>

* 完全名:

SAP Best Practices Baseline Package

Building blocks: カプセル化されたビジネスプロセス

** 財務会計 (ドイツ)J03 –財務会計 MY、UK、SGB29 –財務会計 (その他の国)

SAP Best Practices: ソリューション構成

41

• 時間の節約

• 費用とリスクの軽減

• 権限の強化: 競争量の高いビジネス上の専門知識を利用して、権限を強化します。

• 新しいビジネスプロセスによりビジネスソリューションを拡張し将来の展開への道筋を迅速に開きます。

• すべて再利用可能なプロトタイプが完全に文書化され試験導入が不要で、即座に導入を開始することができます。

• プロジェクトチームメンバーおよびエグゼクティブ間のコミュニケーションの有効性が高まります。

• ビジネスプラットフォーム: パートナ評価、合弁開発独自開発に使用可能なプラットフォームです。

• 一貫性のあるアプローチではエンドツーエンドのビジネスプロセスの統合を重視しています。

• インストールのパーソナライズが可能な柔軟性を備えています。

SAP Best Practices の利点

42

例えば、EDIで受け取った発注データを倉庫に渡す→ピッキングリストを発行する→同時にピッキングリストに対応した専用伝票、専用タグを印刷する、といったフローです。

想定されるイレギュラー処理として、発注データが倉庫に届いているのに専用伝票が印刷できないというのは、ＷＭＳ(倉庫管理システム)の要件なので検討には入りませんが、データが届いている途中で 通信が途切れてしまった場合の対処については、テストを行う方が良いと思います。

43

システム管理

SLA 締結 やシステム管理のプロセスを構築します。 このサービスレペルの要求の程度によって システム管理費が上がります。

年中無休で絶対止まってはならない、盆休みなど期日を決めればアップデートの限られた時間が取れる、システムを止めることができる等で変わります。

システムのアップデートは、高可用性を保つために必要な作業です。

また、プロジエクト終了後に、追加の機能が成される場合も、システムを止めなければならない年間スケジュールに加えます。

44

補足：

SLA 【 Service Level Agreement 】 サービス品質保証

通信サービスの事業者が、利用者にサービスの品質を保証する制度です。

回線の最低通信速度やネットワーク内の平均遅延時間、利用不能時間の上限など、サービス品質の保証項目や、それらを実現できなかった場合の利用料金の減額に関する規定などをサービス契約に含めることを指します。

45

品質保証、運用システムの構築

各システムの検証機サーバー、および本番機サーバーの サイジングと導入を行い、環境構築を行います。

システム運用手順書の作成 や システム運用テストを実施します。

大量のデータを一度に流す負荷テスト、システム障害が 発生した時のことを想定した冗長テストなども含まれます。

46

データ移送および確認 (インターフェイス開発)

入力画面の設定、システムとデータの本番移行計画と、データ移行用のプログラム開発を行います。 移行対象のデータの中身を きれいにして準備します。

データの履歴類は 大きな問題はありませんが、マスターデータのクレンジングは要注意です。 重複や未登録、別システム や 個別のPCにしか存在しないマスター等、すべて洗い出すのは難航を極めます。

47

エンドユーザー・トレーニング準備

エンドユーザート・レーニングの計画の作成と、オペレーションマニュアルの作成を行います。

マニュアルの作成には画面をキャプチャして、作業工程を記録するためのマニュアル作成ソフトを使います。

SAP社から推奨しているものもありますが、どのソフトを使うかは費用の面や使いやすさ、後のマニユアル類の追加時のサポートなどの要件を 踏まえて決定するのがいいです。

48

その他

権限、アーカイブ設計 と設定を行い、次のフェーズの詳細計画の立案とこれまでのまとめをします。

このフェーズの完了と、次のフェーズの開始の承諾 を得ます。

49

最終確認とカットオーバー

50

最終確認 と カットオーバー してからのこと

本稼働は、ゴールというより節目です。 もちろんクリティカルな問題は 外部に尋ねなければなりませんが、SAP ERPに関する些細なことは すべて社内で解決して行かなければなりません。

そのための組織、教育、システム、ルールを用意し、本稼働に備えます。

エンドユーザーに トレーニングを実施

51

プロジェクトメンバー ( コアメンバーとも言います) を中心にエンドユーザーにSAP ERPの使い方を教えます。 不明点は担当部署内で解決できるようにします。

これにより、SAPコンサルタント から引き継ぎを受けた、システム管理者に質問が 殺到しない体制を整えます。 コアメンバに期待することは保守で言う 一次保守です。

画面展開の説明や簡単な操作性の問題など、全体の質問の８割を占める内容です。

また、エスカレーションする質問も彼らがまとめて システム管理者と連携することで、受付窓口になってもらいます。

52

本稼働移行 の チェックリストの作成

本番機のプログラム、パラメータ、権限等の設定内容や、マスタデータやトランザクションデータの 移送内容等の確認の要項、 操作手順をまとめます。その際、チェックリストを作成しておきます。

53

社内サポート体制の構築

システム管理要員へ 引き継ぎを考慮した トレーニングを行います。

システム管理者の人員の増減の対応や、プロジェクトに伴って導入した外部システム、非SAPシステムの操作、理論についてもマニュアル化します。

非SAPシステムで特に関係するのは、総合システム運用管理ツール とマッピングソフトです。

前者は システム連携する際のバッチを、時間や条件に従って自動で実行するためのツールです。

54

後者は、これもシステム連携の際に、SAP ERPから「渡す/あるいは受け取る」 データの項目の順番 と 非SAPシステムが「受け取る/あるいは渡す」項自の順番 とを 自動で並び替える仕組みをもっています。

運用開始してからも 自動化する内容の変更が予想されます。

55

システム管理

テンプレート や 外部システム、外部のツール間の システムテストを実施。もしもの事態のため バックアップ、リカバリ についての手順も確認します。

ついに カットオーバー

既存の基盤システムと、しばらくは 同時並行をしますが、一度カットオーバーしたら、元のシステムに戻ることは 考えるべきではありません。 よって慎重に本稼働の時期は検討します。

スケジュールから遅れる程、余計に費用が掛かりますが、スタートしてから業務に滞りが出る方が、顧客やパートナーに迷惑であり信用を落とすことに繋がります。 ここは慎重に慎重を期しましょう。

56

SAP ERP ゴーイングライブチェック

ツール類、手順書などのドキュメント、マスターデータなどの移行データのクレンジング、外部システムとの連携に 伴う業務運用テストを確認します。

本番移行して すべての業務に支障がないかどうか確認し、もし少しでも不明点がある場合は ゴーイングドライブ、つまり本番移行はできません。

57

本稼働移行の最終承認、カットオーバー

承認されれば システムおよび 各種データの本番移行を実施します。

移行終了後は 事前に用意した 稼働確認テストに行い、一通りのテストを行います。

58

SAP ERPの運用・管理

59

SAP ERPシステムの障害と復旧

SAP ERPのシステム障害には、ダウンタイム (システムが使えなくなる時間)が起こる場合と、不測の事態とがあります。 どういう理由で ダウンタイムが起こるのか、どうしたら早い復旧が期待できるかについて見ていきます。

まず、SAP ERPのシステム障害は、コンポーネント や サービスが適切な時刻に 決められたタスクの実行に失敗した時に発覚します。 障害は、大きく以下の２つに分類されます。

60

一般障害

ハードウェアの破損やOSのウィルス感染、ソフトウェアの プログラムエラー等です。

障善が発覚した場合、ホットスタンバイで用意した予備機に切り替え、ハードウェアの交換やプログラム不良の是正などを進めます。 本番機の復旧が終わり次第、入れ替えます。

単一性障害

単一性障害(SPOF )は、システム上のコンポーネントが異常を来すと、そのシステム全体が障害に 陥ってしまうようなコンポーネントの総称を言います。

61

単一性障害 (SPOF )は ＳAP ERPのデータベース、エンキユー、メッセージサービ

スといった 複数インスタンスを 異なるホストマシンで設定し、冗長化することができないサービスが該当します。

局可用性 のためには、クラスタ環境を使用して、これら脆弱なサービスを保護することが有益です。

もし、障害が出てプロセスが 再実行される場合、ほとんどのSAP ERPサービスは 自動的に再接続できます。 これにより、個別プロセスにしか影響しない問題も自動で回復します。

62

それはプロセスに 障害が発生した後に、ディスパッチャが自動で発動するからです。 すべてのワークプロセス ( ダイヤログ、更新、エンキュー、バックグラウンドスプール ) と ゲートゥエイプロセス が含まれますが、フロントエンド、メッセージ、ディスパッチャサービス は含まれません。

補足：

ホットスタンバイ

同じシステムを２つ用意し、メイン機を作動、サブ機は同じ動作を行いながら待機状態にしておく、信頼性を上げる手法の1つです。

63

SPOF

Single Point of Failure

SPOFとは、システム上のあるコンポーネントが異常を来たすと、そのシステム全体が障害に陥ってしまうような コンポーネントの総称です。

SPOFはシステムのハードウェアや電気的部品が該当することが多いです。

例えば、ハードディスクやネットワークケーブル、ホストアダプタ、あるいは電源などがSPOFに該当します。

システムをクラスタリングすることでコンポーネントを多重化すれば、SPOFに起因するシステム障害をある程度まで抑えることができます。

64

エンキュー

Enqueue

キューにデータを格納すること。キューからデータを取り出す操作は、デキューといいます。

インスタンス

オブジェクト指向の プログラミングで、クラスを基にした実際の値のデータのことです。

クラスを「型」、インスタンスを「実体」と説明することもあります。

65

クラスタ

【 cluster 】

企業の情報システムなどで、複数のコンピュータを連結し、利用者や他のコンピュータに対して全体で１台のコンピュータであるかのように振舞うシステムをクラスタ (コンピュータクラスタ)といいます。

また、そのようにコンピュータを束ねることを「クラスタリング」(clustering、クラスタ化)という。 クラスタ化されたコンピュータ群はまとめて1台のコンピュータを扱うように管理・運用することができ、1台が障害などで停止してもシステム全体が止まることはなく、処理を続行したまま修理や交換が行えます。

66

ディスバッチャ

【 dispatcher 】

OSの持つ重要な機能の一つで、並列に実行されている複数のプロセスやタスクにCPUの実行時間を割り当て、実行の切り替えを行うプログラムをディスパッチャ (プロセスディスパッチャ)といいます。

大規模なネットワークシステムで、クライアントからの接続要求や処理依頼を受け付け、空いているサーバを見つけて処理を振り分けるシステムをディスパッチャといいます。

67

スプール

【 spool 】 スプーリング / spooling

時間のかかる入出力処理などの際に、ハードディスクなどに一時的にすべてのデータを書き込んで少しずつ処理させることで、マイクロプロセッサを効率的に利用することです。

ネットワークを通じた電子メールの配送においても、通信速度はコンピュータの処理速度よりも極めて遅いため、スプールを利用することにより処理効率を上げています。

68

SAP ERP の システムの高可用性の向上について

ダウンタイムの 起きにくいシステムを 構築するためには、外部からの脅威にいち早く対応でき、負荷が軽いことが望ましいです。

以下の処理は、高可用性を向上させます。ただし、メリットだけではないので 注意が必要です。

69

SAP プロセスの自動回復

該当 するプロセスが再実行される場合、ほとんどの SAP サービスは動的に( すなわち自動的に) 再接続することができます。 再接続機能により、個別プロセスに しか影響しない多くの問題から 自動的に回復します。

大部分の SAP プロセスは、プロセスに障害が発生した後に ディスパッチャによって自動的に再実行されます。

これらのプロセスには、すべてのワークプロセス ( ダイアログ、更新、エンキュー、バックグラウンド、スプール) と ゲートウェイプロセスが含まれます。

70

フロントエンド、メッセージ および ディスパッチャサービスは、自動的には再実行されません。 以下の図では、SAP プロセス間の接続で障害が発生した後、 どのように回復するかを示しています。

SAP システムサービス間 接続のリカバリ

71

太線で表示されている接続

これらは、フロントエンドをマニュアルで再起動することによってのみ回復することができます。 ユーザコンテキストは、アプリケーションホストで保存されます。

中線で表示されている接続

これらは、ディスパッチャにより メッセージサービスへ自動再接続され、回復します。 メッセージサービスプロセスで障害が発生した場合、プロセスをマニュアルで 再実行しなければなりません。 このプロセスの自動再実行については、スイッチオーバーソフトウェアを参照してください。

細線で表示されている接続

これらは、障害発生後、ディスパッチャが プロセス ( ダイアログ、更新、エンキュー、バックグラウンド、スプール、ゲートウェイ) のいずれかを再実行した場合、自動的に回復します。

72

SAP ERP システムの アップグレード

既存のSAP ERPを 新規リリースに更新します。 プログラムのコードやデータが更新されたり、新しい機能が導入されたりしますが、更新時には アップグレードプロシージャを使って順番に適応します。

SAPの アップグレードは、必ずデータベーステーブル構造の変更を伴います。場合によっては、テーブルの各行を変換してから、構造を再び完全にする必要があります。

73

74

以前のSAPリリース では、この変換はダウンタイムの間に行われましたが、現在は 差分テーブル変換を実行すると、本稼働オペレーション中に変換を実行することができます。

差分テーブル変換によって、次の３つの利点が生まれました。

① アップグレードによるダウンタイムを短縮できる。

② 修正したテーブルを SAP標準に簡単に変換し直すことができる。

③ 本稼働オペレーション中に 大きいテーブルも変換できる

75

また、アップグレードは その準備段階で、データベース実行できるかどうかを自動でチエックし、該当する場合は、差分変換の利点があるすべてのテーブルを検出します。

次に、どの変更済テーブルの差分を 標準SAPテーブル定義に変換し直すか、どの未変更テーブルの差分を変換するかを決めます。

変換の所要時間も 自動で計算されるため、アップグレードの計画を立てることができます。

同時にデータベースのリソース使用状況も監視し、空きの容不足などの障害を早期に発見します。

76

ほかにも OS や データベース管理システム（ＤＢＭＳ) のアップグレードがありますが、これらすべてに 共通するポイントは実行後、すべての機能が問題なく使 えるかわからない ということです。

万全を期すなら、本番環境をもう１つ作ってテストを 行いたいところですが、すべての業務を リリースの度に行うことは難しく、主要業務だけテストする傾向が強いようです。

新規リリースから、しばらく経って いくつかマイナーバージョンアップが発表されてからか、 セキュリティ上に重大な問題が発覚された場合に 小さく実施するかが好ましいかもしれません。

77

アーカイブの実施

SAP ERPの ビジネス オブジェクト をアーカイブします。

大量のシステム資源を 使用しますが、古いデータをデータベースから削除するので、データベースの再編成、データのバックアップ、データの回復、ソフトウェアの アップグレードの システム負荷を軽減します。

SAPデータアーカイブ は、アーカイブ開発キットを 使うことで、SAPのアプリケーシヨンのデータのアーカイブを実施し、でき上がったデータを見ることができます。

78

79

80

一般に、アーカイブ するときは、オンラインの アプリケーションも普通に使っているので ダウンタイムは必要ありません。

アーカイブプロセスは、以下の流れで実行します。

① オンライン中に、すべてのオブジェクトを データベースから読み込み、アーカイブファイルに書き込みます。

② 次にアーカイブを読み込み、正常に完了したかを確認します。

③ 該当するオブジェクトを データベースから削除します。

81

④ 必要な場合にのみ、データベースの再編成を実行します。

⑤ 再編成は システムダウンタイムを発生させるので、再編成が本当に必要かどうか検討してください。

例えば、1週間に 100,000のビジネスドキュメントが 生成され、週次で アーカイブしていたら、 解放されたディスク領域 は翌週再利用されるため、再編成は意味がありません。

⑥ データベース索引テーブル が激しく断片化されている場合は、再編成することをお勧めします。

82

SAPスプールサービスの保存先設定

主に印刷の完了ができなかった場合に スプールサービスの障害が発生します。 印刷に失敗しても ロールバックはできず、再度データを送り直す必要があります。

スプールサービスでは、出力印刷データを TemSe という一時的に保存する場所に置かれます。

このTemSe を SAPデータベース か ファイルシステムに保存するか設定できます。

83

ファイルシステムの方が高速で良好なパフォーマンスが得られますが、障害が発生した場合、再度 TemSe のデータを使うのは難しいことです。

SAPデータベースは パフォーマンスこそ遅くなりますが、データベースツールによる復元ができるので、何度でも同じ情報を使うことができます。

補足：

TemSe

TemSe は、一時順次データ用のストアです。つまり、TemSe にはシステムに常時保持されている わけではない オブジェクトが 格納されています。

スプールシステムでは、出力データを一時的に保存するために TemSe が使用されます。 TemSe によってスプールデータを SAP データベースに保存するのか、ファイルシステムに 保存するのかを設定することができます。

84

85

86

SAP ERPホットスタンバイの概要図

本番稼働サーバー

ライブラリ

プライマリ

ホットスタンバイサーバー

リードオンリーリードライト

マスターデータ

ビジネスコビー

ログ

ライブラリ

セカンダリログ

ログ

マスターデータ

フェイルオーバー

87

ＳＡＰ セキュリティのポイント

88

セキュリティのポイント

SAP ERPシステムは、もともと社内で使うことを前提としており、外出先でも閲覧できる内容は限られていました。

よってセキュリティと言えば ポータルを監視し、権限による情報閲覧の制限をすればよかったのです。

しかし今や多くのデバイス、つまり携帯電話やスマートフォン、タブレットPC等によって自由にSAP ERPにアクセスすることが求められています。

そこでデータアクセスの権限の設定管理に加えて、モバイルプラットフォームの セキュリティ確保の仕組みもご紹介します。

89

権限の管理

SAP ERPには、ガイドプロシージャ(GP)の管理ツールを使ったセキュリティがあります。 データのアクセス権限を 設けることによって、必要な人に必要な情報を見せるためのものです。

例えば、給与は当事者とそのマネージャは見えますが、他部署のマネージャには閲覧権限を与えないのが普通です。 閲覧権限のレベルを割り当てることで、ユーザーの要件やナレッジに 適合するように調整できます。

90

SAP 権限コンセプトにより、 SAP システム内のトランザクション、プログラム、サービスが、不正なアクセスから保護されます。

権限コンセプトにもとづき、管理者は SAP システムでユーザが システムにログオンし、自身を認証した後に実行できるアクションを決定する権限をユーザに割り当てます。

ビジネス オブジェクト や トランザクションは権限オブジェクトによって保護されているため、 ビジネスオブジェクト へのアクセス、または SAP トランザクション の実行を行う ユーザには、対応する権限が必要です。

権限は、一般権限オブジェクト のインスタンスを表し、従業員のアクティビティ および責任に応じて定義されています。

権限は、ロールに 関連付けられた権限プロファイルに結合されます。ユーザ管理者は次に、ユーザがタスクのために 適切なトランザクションを使用できるように、ユーザマスタレコードを 使用して対応するロールを割り当てます。

91

92

デザインタイム固有 の ロールとして、 SAP Netweaver Portal のユーザー領域で付与される権限には、次の３つがあります。

(A) GP基本ユーザー

(B) GP上級ユーザー

(C) GPエキスパートユーザー

これらの中から必須権限を１つ選び、「閲覧権限のみ」「編集権限あり」 「ブロック指定するもの」「必須の権限指定呼び出しのできるオプジェクト」 や 「実際に操作できるオブジェクト」 といった指定を行います。

93

94

95

これにより各オブジェクトや機能に対して、操作を享受されるレベルを設定できますが、複雑に設定すると組織変更や部署移動といった事態に対応するのが、困難になります。あまり多く設定しない方が運用が楽になります。

モバイルのセキュリティ

企業恬報を モバイルデバイスで持ち出したり、情報の更新ができたりした方が便利ですが、個人情報に 代表される企業情報の漏洩が危惧されます。

かといって、やみくもに保護をかけて、情報にアクセスするまで認証などを多く設定すると、モバイルのいいところである機動性が弱くなり、結局使われなくなってしまいます。

96

そこで、外出先で企業情報が利用でき、かつ安全に運用できると言えば、シンクライアント技術が 挙がります。

シンクライアントは、オンラインアクセスが前提で、基本的に端末にデータを残しませんし、４G や公共Wi-Fiなど既存のシステムインフラを活用できますので、安価に素早く対応できます。

自宅やオフィスなどネットワークが安定していて落ち着いた場所で操作する分には便利ですが、モバイルデバイスのいいところの「少し空いた時間に何かをする」のが難しくなります。

97

例えば、電車で移動中に何かを見るにしても、いちいちユーザーIDやパスワードを入力しなければなりませんし、電波の状況が不安定だと欲しい情報も見られず、効率化どころか逆にイライラしてしまうかもしれません。

そこで利便性を保ちながらセキュリティも高める、以下の4つのポイントをSAPのモバイルプラットフォームは提供しています。

98

企業情報へのアクセス権限の管理

どのユーザーがどのデバイスの何というアプリケーションから、どのデータにアクセスできるかを管理する、モバイル固有のアクセス管理を設定します。

99

企業情報との通信の暗号化

データ通信を暗号化してセキュリティを保ちます。 VPN接続など、あたかもモバイルデバイスを 社内ネットワークと同じ状態にして通信のセキュリティを高める方法があります。

また４GやWi-Fi等の公衆通信でも、セキュアにデータ通信する方法があればより使い勝手がよくなります。 キャリア各社が企業向けに提供しているセキュア通信サービスを使うのも一手です。

100

モバイルアプリケーションとそのデータの保護

Jailbreak は、 OSの保護状態を解除して情報にアクセスします。 またマルウェアはデパイスのアプリケーシヨンに不正にアクセスしてコントロールします。

これら外部の脅威に備えて、Jailbreak 検知機能やデパイスのアプリケーション内のキャツシュや データを暗号化する仕組みが必要です。

101

デバイス自身の保護

デバイスが紛失、盗難にあった場合を想定して、他者が簡単に端末を操作できないようにするため、オートロックまでの時間やパスコードの強制、パスコードルールの設定が大事です。

アプリケーションンを保護していても、OS標準のメールや予定表ならActiveSync で閲覧が可能なため、証明書の管理やデバイスのロック、暗号化は必要です。

またリモートワイプ やメールサーバーへのアクセス権を サーバー側で削除できるようにするためにも、MDM によるデバイス管理やモニタリングは用意しておく方が良いと思います。

102

補足： Jailbreak

ユーザー権限に制限を設けているコンピュータ（携帯電話やゲーム機など）に対して、セキュリティホールを突くなどしてその制限を取り除き、開発者が意図しない方法でソフトウェアを動作できるようにすること。また、その状態のこと。日本語で脱獄（だつごく）とも呼ばれます。

この語は、一般的にはアップル社のiOS機器（iPhoneなど）に対して、アップルの認可を受けていないソフトウェアを動作可能にすることを指します。

103

ActiveSync

Microsoft ActiveSync

マイクロソフトが同社の携帯端末向けオペレーティングシステム (OS) であるWindows Mobile、Windows CEを搭載した携帯情報端末 (PDA) と、Windows 搭載のパソコンを接続して情報のやりとりやソフトウェアのインストールを行うために提供しているソフトウェアです。 パソコン版は2008年現在、無償配布のソフトウェアです。

104

105

106

107

108

ＳＡＰ ＥＲＰ サポートに

つきまして

109

各種サポートサービス

SAPでは、専門知識やシステムの技術的サポートとして、「SAPサービスマーマーケットプレイス」 「リモートサービス」 「オンサイトサービス」 といった各種サービスを提供しています。

SAP ERPのネツトワークサービス

本稼働してから、第一次サポートとして各部のコアメンバー、第二次サポートとしてシステム管理者が ヘルプデスクを行います。 これはSAP ERPを使い続けている限り続きます。

110

しかし、すべての問題は社内でクリアにならず、外部の専門知識やシステムの技術的サポートが 必要になります。

まず問題にぶつかったら、原因の特定からへルプデスクを通じた知識の向上のためSAPの用意したインターネットサイトを探ります。

グローバルで利用されているので、英語で提供されている情報も少なくありませんが、翻訳ソフトを使いながらでも利用する価値はあると思います。

111

SAPサービスマーケットプレイス (SAP SMP)

SAPのすべてのサービスへのナビゲーションに従った、ワンストップのサイトを提供しています。

例えば、「SAPノート」は、SAPのオンラインサービスとサポートシステムから問題と解答について、ノート(コメント類)を検索できます。

また「ホットニュース」は、サポートに関するニュースや既知の問題がわかります。

「カスタマーメッセージ」は、SAPの顧客が登録したメッセージをSAPサポート組織(グローバルサポート)が答えます。

112

SAP ERP のリモートサービス

自力の調査でもわからない困難に出くわした場合、SAPコンサルタントが専任で就いて欲しい時があるかもしれません。

ただ、問題の特定が難しくなく究明に多くの時間を要しない場合、遠隔地からのリモートで助けてもらうこともできます。

113

SAP ゴーイングライブチェック

スムーズな本稼働を始めるための方法で、準備フェーズと導入フェーズとに行われます。 ビジネス設計の実現の可能性や新しいSAP ERPソリユーションの要件など、導入を成功させるための要素を分析し、実際のゴーイングライブの際はより効率的に実行が期待できます。

SAP アーリーウオッチ

予防的なシステム診断用に用意されたサービスです。 システムのパフォーマンスと可用性を高い水準に保つよう、SAPソリューション、ベーシス、コンポーネントの技術的な分析を専門チームが行います。

集中バックグラウンドの処理、よく使われるクエリの最適化などが分析され、ソリューションのチューニングの 推奨事項としてレポートされます。

114

SAP ERPのオンサイトサービス

それでも解決できない場合、多くは根本的な課題を抱えていることが考えられます。

事業分析で軽視していた業務が多様化した場合、事業へのインパクトの高い業務が抜けている場合等があります。 その場合は短期ではなく、SAPコンサルタントの現場指導が必要になるかもしれません。

技術運用コンサルティングサービス、コンサルティングパッケージ

システムのバフォーマンス向上のため、Basisやアプリケーションの専門コンサルタントがシステム構成を分析し、レポートを提示し、必要であればシステムの組み替えを行います。

115

コンサルティングパッケージは、導入時または本稼働捜査時に発覚した中長期スパンの問題に対して、SAPのコンサルタントがコンサルティング手法に則って課題を解決します。 ユーザーの現場に直接お伺いしてサービスを提供します。

116

トレーニング

多くのカリキユラムを用意し、教材、演習、ケーススタディが取り入れられています。 実際の導入プロジェクトチームの活動をシミュレーションしたもので、受講生は ビジネスプロセスやテストケースを通じてSAPを学ぶことができます。

プロジェクトチームトレーニング

SAP ERP導入の成功に必要なスキルをプロジェクトチームに提供することを目的としています。

受講生は上級管理者、ビジネスプロセス責任者、設定チームやパワーユーザー、その他の導入チームメンバーを対象としています。

117

アブリケーションと技術カリキユラムでは、認識、準備、習熟の観点から要望に応えてカリキュラムを組みます。 標準クラスルーム、オンサイトクラス、Webベースクラスなどが用意されています。

SAP ソリューションアカデミー

高度なトレーニングを積むための国際的な教育機関で全SAP製品のための 幅広いトレーニングソリューションです。

SAPの使用経験がない人から経験豊冨なコンサルタントまで、ソリューションアカデミーではユーザーのスキル開発を支援する様々なコースが用意されています。

118

119

他の章は下記をクリックして

ＰＤＦ一覧からお入り下さい。

ＩＴライブラリー （pdf １００冊）http://itlib1.sakura.ne.jp/

目次番号 １８０番 ＳＡＰ 基本からＳＡＰ ＨＡＮＡまで

全９冊 ８００ページ