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