Please enable JavaScript.
Coggle requires JavaScript to display documents.
結局移行チームどこまでやんの (移行チームのサービスレベル) 【理想形】【まずマスタ】 - Coggle Diagram
結局移行チームどこまでやんの
(移行チームのサービスレベル)
【理想形】【まずマスタ】
ツール作成
登録ツール
移行チーム担当となっているマスタデータにおける登録ツールは基本すべて作成する
コンサルが作成するマスタ定義書において使用が想定される項目に関してはすべて登録できるツールを作成する
変更ツール
SAP標準で変更できない項目(品目マスタの品目タイプ等)以外の一般的に登録後に変更が可能な項目に関しては一括ツールを作成する
マスタ定義が変更になったな場合はその都度ツールを改修してテストを実施し、お客様に連絡する
削除ツール
PJに応じた削除運用に応じた一括マスタ削除ツールを作成する
(削除フラグなのか物理削除なのか、削除フラグはどこなのか)
【依頼事項】PJ毎に各マスタの削除運用を明確にお客様と合意してほしい
標準の考えがあればそれに合わせて削除ツールも製品として用意できる
パフォーマンステストの実施
負荷テストは移行チームでは実施しない
PJ全体の負荷テストにおいてデータを準備してほしい等の要望があれば都度対応する
【確認事項】
移行の立場から負荷テストを実施したことある?
実施するのってどんな場合?
作成した登録・変更・削除の一括更新ツールがお客様の各サーバーにてどの程度にパフォーマンスを発揮できるか計測する
(〇〇件〇分で登録できるなど)
パフォーマンスが悪いと言われるとそこの手当をできるのが石川さんだけ?なので少し困る
移行計画立案
移行タスクの説明(スケジュールの作成)
一般的なマスタ移行に必要なタスクの一覧と前後関係の説明
過去事例に基づいて各タスクの一般的な工数を説明
その後のスケジュールの変更に関してはお客様にて管理して頂きたい
(タスクの増減や所要時間・期限)
移行チームとしてはその変更を都度連絡いただき
各タスクが予定通りにこなされているかを監視する
監視の結果問題がある場合はPMに報告する
移行手順の確立
登録・変更・削除手順
汎用バッチを使用するデータ
汎用バッチの使用手順の説明
(操作手順書も渡す)
エラーリストの作成と説明
今まで標準化作業で洗い出せているエラー+PJ固有要件に対してエラーメッセージ・原因が記載されている
発生しうるすべてのエラーを記載できるわけではないので
エラーリストに記載されていないエラーが発生した場合は問い合わせを頂ければ回答する
汎用バッチ使用時にシステムが落ちたときの対処方法の説明
(ログファイルの見方)
マニュアル(SAPの画面)で登録するデータ
SAP標準のマスタ
トレーニング(PU教育)が始まる前に関しては移行チームより操作手順を説明する
(マスタ定義等は反映させないが一般的な画面の操作手順を記載した操作手順書も渡す)
アドオンマスタ
アドオン画面の使用方法に関して開発?コンサル?より移行データを登録する方に説明頂きたい
(問い合わせ等も開発にお願いしたい)
基本的には移行チームは画面の操作方法を把握はしなくてよいと考えている
アドオンテーブル更新ツールを使用するもの(アドオンマスタ等)
アドオンテーブル一括更新ツールの操作手順を移行チームより説明
(操作手順書も渡す)
その他何かあるか
外部システムからのIF等で登録するパターン????
データ作成手順
整備シートの説明
お客様がデータ作成のイメージがつくようにサンプルデータを整備シートの中に記載する
どのレベルで記載するかまで具体的に定義するか?????
クレンジング
基本的にお客様タスクでありIPSから提供できるサービスはない
現行システムに関しては移行チームとしては確認、分析等しない(ノータッチ)
IPSにてクレンジング方針の検討が必要な場合はコンサルタントにて実施頂きたい
現行の各項目とのマッピング
基本的にお客様タスクでありIPSから提供できるサービスはない
現行システムに関しては移行チームとしては確認、分析等しない(ノータッチ)
IPSにて現行システムとのマッピングが必要な場合はコンサルタントにて実施頂きたい
データ抽出手順
基本的にお客様タスクでありIPSから提供できるサービスはない
現行システムに関しては移行チームとしては確認、分析等しない(ノータッチ)
チェック手順
投入前のチェック
(整備シート上でのチェック)
投入後のチェック
整備シート通りのデータが登録されているかのチェック
登録したデータを使用して後続の処置(業務)が問題なく実施できるか(原価等数値項目の妥当性も含めて)
チェックが必要な観点とチェック手順の過去事例をお伝えしてテスト時等にチェックを実施してもらう
2021年においてはスキルとノウハウが不足しているため当内容はコンサルにお願いしたい
移行体制の確立
IPSにて推奨しているお客様側の移行体制を説明する
全体管理者、データ毎の管理者、データ毎の実作業者の3つに分類
各分類の移行担当者に求めるスキルの儀容についてご説明する
推奨する移行体制においてIPSとの問い合わせルートやスキームについても合意する
スケジュール作成の一環でもあるが、各担当者ごとに必要となる工数のサンプルも説明する
過去の成功事例失敗事例などもご説明する
IPSより推奨している体制とは異なる体制で合っても移行を水Sんする担当者がお客様側で確立できたことを確認する
現状の移行チームでは政治的な内容(スキームを考えたり)というのは難しいものがある?
移行範囲の確立
移行範囲を確立する意義を説明する
本番移行時のスケジュールを作成するために想定される件数の情報が必要
(作成・登録・チェック時間を算出するために使用する)
移行データに過不足がないかをお客様内で確認できるようにする
ゴミデータが多い場合などは一般的な手法の一つとして過去〇年間の入出庫がある品目等の一時的な絞り方をして、その後に在庫があるものや使用が想定されるなどを追加する手法があることも説明する
進め方の全体像やお客様に持ってい頂きたいマインドセットを伝える
問い合わせ対応
マスタ
マスタの項目の意味・マスタ定義
別資料に記載している4分類に準じてハンドリング
移行チームが聞きまわって回答するのではなく、質問先を教えるスタイル
(回答担当がIPS移行ではないものに関しレは基本はお客様にて該当担当者に問い合わせ)
トランザクション
マスタが終わってかっら記載
移行計画に関する内容
スケジュール
体制
手順
会議への参加
以下に記載している移行チームのサービスレベルに関連する会議には基本参加する
ただし、移行チームメンバーは1人で複数のPJを担当していることが基本になるので、時間的制約があるため会議に出れないor時間的制約がある場合があることをご了承いただきたい
移行状況の監視
遅延リスクがある場合はPMにエスカレーションする
監視する観点
お客様の移行に関する習熟度
データ作成・登録に着手できるだけSAPや移行ツールを理解しているか
スケジュール
無理のあるスケジュールになっていないか
無理のある場合はリスクがあると同義である
スケジュール通りにIPS(移行チームだけでなく他チームも)やお客様が動けているか
【残課題】監視するタスクにおいての判断基準
(習熟度が足りないなどと判断する基準をどこに置くか)
ここに書いているのは理想形であるが、その通りに行かない場合(お客様がこの役割分担を拒んだ場合)に関しては移行チームでどこまで譲歩できるか