プロジェクト/移行 のバックアップ(No.1)
- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- プロジェクト/移行 へ行く。
- 1 (2014-06-26 (木) 11:03:36)
- 2 (2015-08-07 (金) 16:41:05)
旧システムないしマニュアル管理していた業務情報を、新システムに移すこと。
概要 †
大きくは、マスタ移行とデータ移行の二点となる。 データ移行は、マスタ移行が正しいことが前提となること、正しくないことが判明することは即ちリカバリが必要となること、それらの手順の策定やネゴを取ること含めると、トラブルの質・量および難易度はマスタ移行の比ではない。
- データ移行 勘定残高、未消込明細、受発注残など。 言うまでもないが、作業順序が非常に重要であり、筆者は在庫移行の前に受注残を投入し、全て在庫なしでStopしたという抜群にマヌケなプロジェクトを知っている。
方針の定義 †
各論に行く前に、ひとまず構想フェーズ・予備調査フェーズにて*1、下記の要素を論じておくべきと考える。
- 担当 データ作成・リハーサル・移行の実作業について、ユーザ側なのかベンダ側なのか、主管はどのチームなのかなど。
- 手段 マニュアルなのか、ツール使用なのか、使うのは標準ツールなのか完全Add-onなのかなど。 また、手順書の要否も併せて論ずるべきである。
- 前提 単なる作業順序上の依存関係もあれば、「Aコースの場合必須、Bコース不要」もあるし、ブレるとやばい系なので予防線を張っておくなど。
- 粒度 品目在庫で言えば、システム刷新を機に寄せるケースは少なくないものの、集約前の原価を保持するのか、マージ後の移動平均とするか。 勘定残高で言えば、グロスで入れるか利益センタ別残高とするかなど。
- 期限 マスタ系で言うならば運用テスト前に耳を揃えて準備すべきだが価格条件は運用Start後でも構わないし、AP/ARの未決済明細前ならば支払や入金の前であれば多少の融通は利くなど。
- 採否判定とその理由 移行そのものの対象外とするならば、その理由は何か？ということ。 これは、カウント自体されていない＝論じられていないことと、諸々の経緯の上で却下となったことは全く性質が異なるし、「却下」だけで理由が無ければ何度も蒸し返すことになるためである。 具体的には、CO予算や価格条件などは「無ければ動かない」性質でないため対象外となることはあるし、コンポーネントレベルでスコープアウトとなった結果対象外となったなど。
手段について †
- Add-onする 一般的と言えば、一般的。
- SAP標準の移行ツールを使用する 元々提供されていることもあり、使用するのは然程難しくはない。 但し、相当初期に実装されたこともあり、集中アドレス管理との連携など、ブラックボックス化した場所でトラブルに見舞われることもある。 技術的に言えば、Programを利用した標準B.Iセッション登録を行い、Tr-CD:SM35で流す。
- CATT 本来はテストデータ登録用らしい、古き良きSAP謹製ツール。
- LSMW 最近あまり聞かない。
- 汎用バッチインプット ユアソフト社が販売している、Excelから色々と弄れるバッチインプット系ツール。
- VBAツール ExcelからVBAを利用し、RFC経由でSAPにアクセスする手法。
- ダイレクトインプット 最近あまり聞かない。
- 運用ツールを使用するケース Tr-CD:MM01やXD01はエンドユーザが平常運用で使用するには中々難しく、平易に使用するためにメンテナンスツールを追加開発することは珍しくない。 その運用に使用するAdd-onを移行に使用する、という手法である。 運用で使用する道具を使うため、手順や内容の担保などは仕様に吸収されている部分も多く、移行作業やデータ作成自体は負荷が減ることが多い。 しかしながら、 ・運用で使用するにもかかわらず、移行仕様が介入してしまうリスク ・いち運用プログラムの要件定義〜試験までの工程および品質が、移行スケジュールに干渉し得る などのリスクやデメリットもあることには留意したい。