● パッケージ商品の現状
|
【ページ構成】 ■ パッケージ商品に必要な業務要件とシステム要件
■ ベンダの見分け方とユーザ対応
事業基盤の強化なり業務改善の実現をアプリケーションパッケージ商品に求めるユーザにとって、現状のパッケージ商品は必ずしも満足が得られる内容になっていない側面があります。
ユーザが情報システムに期待する「システム機能の進化・応用性」とパッケージ商品のギャップにその原因の多くがあります。一言で表現すると、中堅・中小企業の事業環境の変化とユーザ要求についていけないアプリケーションパッケージ商品の現状です。ユーザの業務改善・改革の要求に満足に応えられないパッケージベンダの商品力の姿があります。
● カスタマイズが多く、カスタマイズ費用が高い
|
(理由) |
・パッケージとして、保有しているシステム機能が少ない
・業務改善を実現するためのシステム機能を保有していない
・パッケージの業務対応フレームワークが弱い
→業務処理・方式の選択の幅が狭い
→データベースの構造・構成が柔軟性に欠ける
→帳票をベースにした出力系が主力になっている
・ユーザ固有の付加価値と取引条件の複雑性への対応が未熟 |
● 導入事例の積上げによるシステム機能の狭さ
|
(原因) |
・パッケージのコンセプト(ニーズ変化への読みと対応、方向性、先進性)の曖昧さと弱さ
・パッケージの構築技術(オブジェクト化、フレームワーク、アルゴリズム)の未熟さと限界
|
● 保有システム機能からの問題解決による限界
|
(影響) |
・ユーザの目的/目標/期待効果を達成しない可能性有り
・システム利用者の満足感が得にくい
・投資効果が期待できない |
|
● パッケージ商品に必要な業務要件とシステム要件
|
アプリケーションパッケージ商品のあり方が転換期にあると考えます。いままでのパッケージ商品はゼロからシステムを開発する手間とリスクへの解決策であり、ユーザ事例の積み重ねによるシステム機能の実装傾向が強いです。その結果、パッケージ商品のあるべき姿への発想なりシステム利用者の要求への対応が遅れているのも事実です。
ユーザサイドに立った「業務効率とマネジメント」支援、「ユーザによるカスタマイズ」機能、「業務処理・管理基準の処理方式」選択がこれからのパッケージ商品の必需品と考えます。また、これに加えて真の問題解決を行えるソリューション技術がベンダに求められます。これからのパッケージ商品は次のような業務要件とシステム要件を具備することと考えます。
■ 業務効率支援機能
|
① 事務作業の支援
・ 1画面を主体にした必要情報の即入手(画面遷移の活用)
・ 作業に必要な情報のPUSH型提供(納期、顧客サービス・・・)
・ PC処理との密な連携(情報分析、発注業務・・・)
・ 取引条件、業務マニュアル、操作マニュアルの即明示
② 営業活動への支援
・ 営業担当と事務担当の情報連携(モバイル発注/受注・・・)
・ 営業担当の必要情報の即時提供(在庫、価格、見積事例・・・)
③ 作業進捗の見える化
・ 作業(情報・文書・判断・・・)の進捗状況の把握と連絡・通知
・ 作業進捗の問題発見と関係者への通知
・ 生産/修理/貿易などのシステムとの作業情報の連携
|
■ マネジメント支援機能
|
① 問題発見
・ 管理基準、サービスレベル、計画に対する自動的な問題発見
・ 問題発見情報の自動通知(携帯、社内メール、使用メニュー・・・)
・ 利用者による「問題発見・通知機能」設定の容易化
② 顧客サービス、社内管理
・ 販売機会損失データの自動収集と分析(欠品、分納、納期遅れ・・・)
・ 情報活用の容易化(CSV出力、照会画面、分析ツール連携・・・)
・ 業務プロセス/作業の構成コントロール(変更、追加・・・)
③ データベース項目の確認
・ 企業活動において、情報分析も進化することを前提
・ トランザクションDB/マスタDBの項目までの理解と確認
(参考) 「企業活動を支える情報活用の見方」ページ
|
■ ユーザカスタマイズ機能
ベンダなりSEの手助けがなく、ユーザ自身が必要なニーズに応じて利用できる情報処理の仕組み構築をユーザカスタマイズと定義します。
|
① 照会画面
・ 画面レイアウト、検索キー項目、照会項目の設定
・ 利用データ、データベースとの紐付け
・ 利用データの利用権限とのチェック
② PC連携
・ 連携データ項目(CSV)の選択と追加
・ 作業画面からの画面遷移、双方向のデータ流通
・ 利用データの利用権限とのチェック、利用履歴の把握
・ PUSH型、PULL型の選択(定期運用、随時運用も考慮)
・ 分析ツールとの連携
③ 処理の組立て
・ 業務プロセス、処理ロジック(アルゴリズム)の組み立て
・ 選択、計算、判断などの情報処理を含めた簡易開発
④ 帳表作成
|
■ 処理方式の選択
|
① 業種別対応、販売管理
・ 標準的な処理方式の選択(複数選択もあり)の実装
例: 受注方式(EDI、画面、Web、見積連携・・・)
発注方式(.発注点、任意、受注発注・・・)
・ 管理基準の選択(複数選択もあり)の実装
例: 原価計算、利益計算、在庫体質
・ 業務プロセスの選択と必要な作業進捗管理
例: 受注→出荷予定→貿易書類→出荷→船済み
② 生産、修理、貿易などとの連携
・ 販売管理の業務プロセスに応じた情報連携(正常、変更)
例: 受注→生産依頼、生産完了→在庫→出荷
・ 作業進捗状況の見える化、変更情報の連携
③ 業務効率支援機能、マネジメント支援機能との一体化
|
|
● ベンダの見分け方とユーザ対応
|
ベンダは自社のパッケージ商品を売り込むために、パッケージ商品の特徴なり良さを当然ながらアピールします。これらのアピール・提案・デモなどを通して、ベンダ評価をする際に注意することをまとめました。業務改善、事業基盤の強化をパッケージ商品の導入に求めるユーザにとっては重要なチェックポイントと考えます。
● 注意点(ベンダの見分け方)
|
・ ERP、シームレス連携、オールインワン、テンプレート型などの言葉を使ってアピー
ルしていますが、この言葉の指すところの多くはデータ処理を意味しています。その
まま、鵜呑みにして業務処理・管理内容に適用することはリスクを伴います。ベンダ
が「買い手」の立場からの発想と対応をしているかの見極めは大事です。
・ユーザは問題解決を図り目的達成のためにパッケージ導入を検討します が、ベン
ダの問題解決の基準はパッケージのもつシステム機能と範囲にあります。そのた
め、ユーザの問題解決を実現させるために「カスタスタマイズ・運用での対応」が増
える可能性があります。パッケージの商品価値の評価を厳しく行うことです。
・ユーザの業務改善なり事業基盤の強化には、上記「パッケージ商品に必要な業務
要件とシステム要件」が避けて通れません。これらの要件がパッケージ商品の中に
どこまで組み込まれているかのチェックは大事な行為です。
|
● ユーザの対応
|
・ あせらず、じっくりと関係するベンダとの接触時間を多くして、自社の問題解決の
立場からパッケージ商品の内容を吟味することです。経営方針、事業環境の変化、
業務改善、管理基準の向上などの視点からパッケージ商品を検討することです。
・ 自社として「譲れない業務・管理要件」を明確にして、安易な妥協をしないことです。
ベンダの言う運用での対応があとあと新たな問題を生むことがあります。
「売り手」の言い方に惑わされないことです。
・パッケージ商品の検討作業を通して、ベンダの担当PM/SEの業務理解、問題
解決能力を把握することです。この能力がパッケージ導入の成果を左右する面
があります
(参考) 「パッケージ商品の選択方法」ページ
「信頼できるベンダ評価と選択」ページ
|
|
● 情報システムを活用した業務/管理の改善・改革の方法・手順・条件などに関心
のある方は次ページを!
(参考) 「業務改善への情報システムの活用」ページ
● 事業の中枢を担う企業情報システムの構成・主要機能・構築条件に関心のある方
は次ページを!
(参考) 「企業情報システムのあり方」ページ
● 企業活動における情報・データを日常的に活用させる仕組み・基盤創り、又は業務
効率に関心のある方は次ページを!
(参考) 「企業活動を支える情報活用の見方」ページ