・パッケージのコンセプト（ニーズ変化への読みと対応、方向性、先進性）の曖昧さと弱さ

 ・パッケージの構築技術（オブジェクト化、フレームワーク、アルゴリズム）の未熟さと限界

・ １画面を主体にした必要情報の即入手（画面遷移の活用）
・ 作業に必要な情報のＰＵＳH型提供（納期、顧客サービス・・・）
・ PC処理との密な連携（情報分析、発注業務・・・）
・ 取引条件、業務マニュアル、操作マニュアルの即明示

② 営業活動への支援

・ 営業担当と事務担当の情報連携（モバイル発注／受注・・・）
・ 営業担当の必要情報の即時提供（在庫、価格、見積事例・・・）

③ 作業進捗の見える化

・ 作業（情報・文書・判断・・・）の進捗状況の把握と連絡・通知
・ 作業進捗の問題発見と関係者への通知
・ 生産／修理／貿易などのシステムとの作業情報の連携

① 問題発見

・ 管理基準、サービスレベル、計画に対する自動的な問題発見
・ 問題発見情報の自動通知（携帯、社内メール、使用メニュー・・・）
・ 利用者による「問題発見・通知機能」設定の容易化

② 顧客サービス、社内管理

・ 販売機会損失データの自動収集と分析（欠品、分納、納期遅れ・・・）
・ 情報活用の容易化（ＣＳＶ出力、照会画面、分析ツール連携・・・）
・ 業務プロセス／作業の構成コントロール（変更、追加・・・）

③ データベース項目の確認

・ 企業活動において、情報分析も進化することを前提
・ トランザクションDB/マスタDBの項目までの理解と確認
（参考） 「企業活動を支える情報活用の見方」ページ

① 照会画面

・ 画面レイアウト、検索キー項目、照会項目の設定
・ 利用データ、データベースとの紐付け
・ 利用データの利用権限とのチェック

② ＰＣ連携

・ 連携データ項目（ＣＳＶ）の選択と追加
・ 作業画面からの画面遷移、双方向のデータ流通
・ 利用データの利用権限とのチェック、利用履歴の把握
・ ＰＵＳＨ型、ＰＵＬＬ型の選択（定期運用、随時運用も考慮）
・ 分析ツールとの連携

③ 処理の組立て

・ 業務プロセス、処理ロジック（アルゴリズム）の組み立て
・ 選択、計算、判断などの情報処理を含めた簡易開発

④ 帳表作成

① 業種別対応、販売管理

・ 標準的な処理方式の選択（複数選択もあり）の実装
      例：　受注方式（ＥＤＩ、画面、Ｗｅｂ、見積連携・・・）
発注方式(.発注点、任意、受注発注・・・）
・ 管理基準の選択（複数選択もあり）の実装
     例：　原価計算、利益計算、在庫体質
・ 業務プロセスの選択と必要な作業進捗管理
     例：　受注→出荷予定→貿易書類→出荷→船済み

② 生産、修理、貿易などとの連携

・ 販売管理の業務プロセスに応じた情報連携（正常、変更）
     例：　受注→生産依頼、生産完了→在庫→出荷　
・ 作業進捗状況の見える化、変更情報の連携

③ 業務効率支援機能、マネジメント支援機能との一体化

 ・ユーザは問題解決を図り目的達成のためにパッケージ導入を検討します が、ベン
  ダの問題解決の基準はパッケージのもつシステム機能と範囲にあります。そのた
  め、ユーザの問題解決を実現させるために「カスタスタマイズ・運用での対応」が増
  える可能性があります。パッケージの商品価値の評価を厳しく行うことです。

 ・ユーザの業務改善なり事業基盤の強化には、上記「パッケージ商品に必要な業務
  要件とシステム要件」が避けて通れません。これらの要件がパッケージ商品の中に
  どこまで組み込まれているかのチェックは大事な行為です。
 

・ あせらず、じっくりと関係するベンダとの接触時間を多くして、自社の問題解決の
  立場からパッケージ商品の内容を吟味することです。経営方針、事業環境の変化、
  業務改善、管理基準の向上などの視点からパッケージ商品を検討することです。
・ 自社として「譲れない業務・管理要件」を明確にして、安易な妥協をしないことです。
  ベンダの言う運用での対応があとあと新たな問題を生むことがあります。
  「売り手」の言い方に惑わされないことです。
・パッケージ商品の検討作業を通して、ベンダの担当ＰＭ／ＳＥの業務理解、問題
  解決能力を把握することです。この能力がパッケージ導入の成果を左右する面
  があります
                   （参考）　「パッケージ商品の選択方法」ページ
　　　　　　　　　　　　　　「信頼できるベンダ評価と選択」ページ