お客様との信頼を築くプロジェクト体制

ソルパックでは、SAP Business Oneを導入・運用していくにあたり、初めに貴社とソルパックでの体制を整えさせていただきます。貴社とソルパックでそれぞれの役割を明確化することで、プロジェクトを円滑に推進していきます。

主な役割

• プロジェクト責任者：貴社窓口、プロジェクト全体を統括
• 会計担当者：現状業務の説明(会計)、移行データ準備、データ移行
• ロジ、生産担当者：現状業務の説明(販売、購買、生産など)、移行データ準備、データ移行

• PM(プロジェクトマネージャ)：SOLPAC窓口、進捗管理、スケジュール管理
• CS(コンサルタント)：現状業務の確認、標準機能の使用方法決定、アドオンの必要性の判断と指針、運用設計
• SE(システムエンジニア)：システムフロー作成、SAP Business One環境構築、データ移行支援、ユーザ教育
• PG(プログラマ)：アドオン開発と単体テスト、連携テスト

プロジェクトの進め方

ソルパックでは、以下のスケジュールでSAP Business Oneの導入を行います。
標準機能で対応が難しい場合は、アドオンの追加で、対応します。
業務特化テンプレート、短期間導入メソドロジーにより、短納期・低価格・高品質な導入支援を実現します。

プロジェクトの規模や複雑性により、以下記載の期間から変更する場合がございます。
プロジェクトの進め方について、気になることがありましたら、お問い合わせください。

※こちらはあくまでイメージとなります。お客様の要望に合わせたサービス及び導入期間をご提供いたします。

データ移行シナリオ

ソルパックでは、データ移行を行う際には、お客様に合わせた移行シナリオを準備しております。移行データの種類や移行シナリオは以下のようになっております。 移行シナリオは、6パターン準備しており、移行シナリオ1から6になるにつれ、入金期日・支払期日や現在の受注・出荷・発注・入庫の残数だけでなく、過去のデータまで網羅できるようになります。
お客様に合わせたデータ移行を要件定義フェーズで確定させ、データ移行を円滑に推進していきます。
※データ移行は、基本的にデータの準備・データ移行テスト・データ移行をお客様に実施していただきます。

移行シナリオ

シナリオ1

メリット

• 移行方法が最も簡単で短期間で可能
• 移行に必要なデータの種類と量が少ない
• 初期データ量が少ない(マシンパフォーマンス)

デメリット

• 全ての過去の取引実績が参照できない
  (過去の販売価格、仕入価格も含む)
• 同一品目は在庫価格が全て同じになる
• 受注残、発注残、出荷残、入庫残がないことが前提

シナリオ2

メリット

• 移行方法が比較的簡単で短期間で可能
• 移行に必要なデータの種類と量が比較的少ない
• 初期データ量が比較的少ない(マシンパフォーマンス)
• 取引ごとに債権、債務残高を入力するので入金期日、支払期日が判断しやすい

デメリット

• 債権、債務残高計上取引以外の過去の取引実績が参照できない(過去の販売価格、仕入価格も含む)
• 債権、債務残高計上取引の明細(品目、数量、単価)までは参照できない
• 同一品目は在庫価格が全て同じになる
• 受注残、発注残、出荷残、入庫残がないことが前提
• 売掛請求書(サービスタイプ)による自動仕訳を考慮して初期残高を入力する必要がある
• 購買請求書(サービスタイプ)による自動仕訳を考慮して初期残高を入力する必要がある

シナリオ3

メリット

• 初期データ量が比較的少ない(マシンパフォーマンス)
• 取引ごとに債権、債務残高を入力するので入金期日、支払期日が判断しやすい
• 現在の受注残、出荷残が把握できる
• 現在の発注残、入庫残が把握できる

デメリット

• 債権、債務残高計上、受注残、出荷残、発注残、入庫残以外の過去の取引実績が参照できない(過去の販売価格、仕入価格も含む)
• 債権、債務残高計上取引の明細(品目、数量、単価)までは参照できない
• 同一品目は在庫価格が全て同じになる(購買入庫による入庫在庫は除く)
• 売掛請求書(サービスタイプ)による自動仕訳を考慮して初期残高を入力する必要がある
• 購買請求書(サービスタイプ)による自動仕訳を考慮して初期残高を入力する必要がある
• 出荷/納入による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 購買入庫による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある

シナリオ4

※外注加工などによる債務残高がある場合、購買クレジットメモ(サービスタイプ)の移行も必要

メリット

• 初期データ量が比較的少ない(マシンパフォーマンス)
• 取引ごとに債権、債務残高を入力するので入金期日、支払期日が判断しやすい
• 現在の受注残、出荷残が把握できる
• 現在の発注残、入庫残が把握できる
• 債権、債務残高計上取引の明細(品目、数量、単価)が参照できる

デメリット

• 債権、債務残高計上、受注残、出荷残、発注残、入庫残以外の過去の取引実績が参照できない(過去の販売価格、仕入価格も含む)
• 同一品目は在庫価格が全て同じになる(購買入庫、購買請求書(アイテムタイプ)による入庫在庫は除く)
• 売掛請求書(アイテムタイプ)による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 購買請求書(アイテムタイプ)による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 出荷/納入による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 購買入庫による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある

シナリオ5

※外注加工などによる債務残高がある場合、購買クレジットメモ(サービスタイプ)の移行も必要

メリット

• 取引ごとに債権、債務残高を入力するので入金期日、支払期日が判断しやすい
• 現在の受注残、出荷残が把握できる
• 現在の発注残、入庫残が把握できる
• 債権、債務残高計上取引の明細(品目、数量、単価)が参照できる
• 過去の受注、発注実績が参照できる(受注単価、発注単価を含む)

デメリット

• 債権、債務残高計上、受注残、出荷残、発注残、入庫残、過去の受注、発注実績以外の過去の取引実績が参照できない
• 同一品目は在庫価格が全て同じになる(購買入庫、購買請求書(アイテムタイプ)による入庫在庫は除く)
• 売掛請求書(アイテムタイプ)による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 売掛請求書(アイテムタイプ)による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 出荷/納入による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 購買入庫による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 初期データ量が多い(マシンパフォーマンス)
• 移行に必要なデータの種類と量が多い

シナリオ6

※外注加工などによる債務残高がある場合、購買クレジットメモ(サービスタイプ)の移行も必要

メリット

• 取引ごとに債権、債務残高を入力するので入金期日、支払期日が判断しやすい
• 現在の受注残、出荷残が把握できる
• 現在の発注残、入庫残が把握できる
• 債権、債務残高計上取引の明細(品目、数量、単価)が参照できる
• 過去の受注、発注実績が参照できる(受注単価、発注単価を含む)
• 過去の売掛請求、購買請求実績が参照できる(売掛請求単価、購買請求単価を含む)
• 過去の入金、支払実績が参照できる

デメリット

• 同一品目は在庫価格が全て同じになる(購買入庫、購買請求書(アイテムタイプ)による入庫在庫は除く)
• 過去の実績を含め、売掛請求書(アイテムタイプ)による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 過去の実績を含め、購買請求書(アイテムタイプ)による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 出荷/納入による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 購買入庫による自動仕訳、実在庫数量変動を考慮して初期残高を入力する必要がある
• 初期データ量が多い(マシンパフォーマンス)
• 移行に必要なデータの種類と量が多い