|
平成10年度 SA午後II 問1 1 システム概要とユーザのシステム開発要求1.1 システムの概要私の参画したプロジェクトは製造・販売業A社のシステムインテグレーションである。この企業A社は、自ら生産した製品を、自社が運営している直営販売店に配送し販売している。このためA社は、生産業務、物流業務、店舗業務、販売業務、購買業務および給与・会計業務を備えている。 1.2 ユーザのシステム開発要求経営者は、システム開発要求のポイントを次の3点として明示した。 (1)リアルタイムな経営情報収集 A社では、各業務システムをバッチ処理で行っていた。このため、経営管理情報が業務終了後1月後でないと収集できなかった。また、業務の完了をチェックする仕組みに欠けていた。これら情報のリアルタイム化が望まれていた。 (2)店舗生産性の向上 店舗ではレジスターを使って販売業務を行っていた。このため、レジ周りに待ち行列が発生し顧客不満足につながっていると考えられた。経営者はPOS導入によるレジ生産性を向上したいと考えていた。 (3)各業務体力の負荷軽減 現状の仕入、購買、販売業務では入力拠点からFAXや手書き伝票が送られてきてそれをオペレータが入力していた。これらの入力体力も削減したかった。 2システム化範囲の策定と工夫2.1 システム化範囲の策定についての検証内容A社のシステム化範囲を策定してゆくためには、システム化するために要する「情報化予算」と「業務要件の重要度」を検討項目とした。 2.1.1 情報化予算の算定すべての業務を一度の投資で新システムに移行できるわけには行かない。そこで、私は経営者と相談し、情報化予算案を立案するベースとしてA社キャッシュフローとする旨の承認を得た。そして、私はキャッシュフローを用いた投資評価方式であるDCF法(Discount Cash Flow)方式を用いてA社の情報化投資体力を測定することにした。 DCF法はキャッシュフローを正味現在価値法で評価する手法である。DCF法を用いた結果、A社の投資可能額は7500万円となった。この結果を情報化投資計画に盛りこみ6年間で償却してゆく回収計画を立案した。 2.1.2 業務要件の重要度 情報化投資予算の関係で、システムの段階的な導入が決定的に成った。そこで、システム化範囲を絞り込むためのガイドラインとして業務要件の重要度について考慮することにした。 (1)ビジネスシステムの品質 ビジネスシステムの品質とは、A社の提供する製品やサービスが顧客を満足させている程度をいう。したがって、情報化範囲の策定に当たっては情報化投資によってサービスシステムの品質向上が望める業務を情報化範囲とすることにした。 (2)基幹システムの強化 本プロジェクトは業務系の基幹システムと情報系システムとに分けることができる。限られた予算のなかでシステムを開発してゆくため、まずは業務間連携にシステム化を基礎とすることにした。 2.2 システム化範囲の策定手順システム化範囲を絞り込んでゆくためには現行の各業務を洗い出し、相互の関係を把握することが必要だと考えた。また、業務のなかには無駄なシステムや矛盾のあるものがある。このような業務排除して、すっきりと見とおしの良いビジネスシステム作りを行う方針を立てた。 2.2.1業務の洗い出し各部署の協力を仰ぎ、それぞれの部署ごとに業務を洗い出してもらい、それぞれをDFD(Data Flow Diagram)に整理していった。 そのことによって、各業務がどのような入出力機能をもっているのか、そして、どの作業がどのファイルや帳票を介して結びついているのかが分かった。 2.2.2無駄な業務の追い出しと新機能の追加現行業務と経営者の要望とを踏まえて、現行業務のな化から陳腐化した業務を追い出していったり、新規機能追加を行った。 (1)無駄な業務の追い出し 例えば、店舗から工場に対する発注は、FAXを本部に送信した後、これを電算部が入力し、生産指示書を出力していた。このような二重入力を改めて一度の入力で仕入依頼が完結するような仕組みを作った。 (2)新機能の追加 逆に購買システムでは納品書と請求書との整合性をチェックする仕組みが情報システムのなかに組みこまれていなかった。そこで、相互の内容をチェックする仕組みを定義していった。 2.3 特に重要な点と工夫 システム化範囲の策定に当たり、次の点を考慮して、IT技術で解決して行く部分と、業務運用レベルで解決してゆく部分とに切り分けていった。 2.3.1 業務手順や手続きの変更で改善できる部分ユーザはPOSに対して過大な期待を抱き「POS導入によってすべての顧客待ち行列が回避できる」と考えていた。そのために、POS画面インターフェースに標準に無い機能追加を要望していた。 2.3.2 業務改善との連携でシステム開発の効果向上納品書と請求書とを照合し、その結果、買掛金を計上することになる。そうすれば、取引先が請求書を出し忘れても買掛金を未計上にまま放置することは無い。このチェック機能を納品段階で持てば、新たに、買掛金の計上チェックの仕組みは作りこむ必要は無い。 2.3.3 システム開発段階で発生する技術課題 購買システムでは、取引先との連携の必要性で、相互のプロトコルをビジネスレベルから標準化しなければならなかった。そこで、購買システムの受発注・検品システムのなかで、流通業の標準プロトコルであるJCA−H手順を採用することにして取引先と合意に達した。 3 評価システム化計画の結果を費用対効果、リスクおよびシステムの効果の観点から整理する。 3.1費用対効果当所ベンダーから見積られた情報化コストは1億1千万円であった。しかし、業務分析をすすめ、一端、業務要件を定義した後、システム化要件を絞り込んだため、第一次投資計画案は6500万円となり、キャッシュフローからみた予算額の枠内で収まった。 3.2開発リスク開発リスクとして以下のものがあった。 (1)ユーザ要求の増大 ユーザ要求が過大になるとシステムコストがかさみ工期も増大する。しかし、業務の重要度の分析によるシステム化業務の決定および運用レベルでのシステム化の回避によって、ユーザ要求の増大を抑制できた。 (2)取引先との相互運用性 事前に業務要件を洗い出し、システム化範囲を明確にしたため得意先との交渉も早期に着手できた。この結果、互いに協調できるプロトコルを用いた開発が可能になった。 3.3システムの効果システム化範囲を業務重要度に応じたものとしたため、ユーザに対する重要度の高いシステム開発を優先できた。その結果、ユーザに対するサービス品質を改善できた。 |