|
中小企業のIT戦略(9)－IT導入の進め方（その3） |
|
～いい会社を作るためのIT導入のポイント～
中小企業において、いい会社を作るためにどういう風にITを活用していくか。
何回かに分けて考えていきたい。
前回から3回にわけて、実際にIT導入を進めていく手順を紹介している。
(その１)では経営戦略の立て方を 、(その２)ではIT戦略の立てた方を取り上げた。今回(その３)はIT導入の進め方のポイントを取り上げる。
IT導入を図るにはITやプロジェクトマネージメント、業務改革などについて知識や経験が必要であり、外部専門家を活用することをお勧めしたい。
IT戦略が定まったとしよう。
例えば、
生産管理システムを導入する。受注EDIは受注量が多い３社のシステムを接続することにし、その他は手作業で入力する。材料手配は自動化しない。在庫管理、差立、仕掛進捗管理はITを活用する。生産計画は人間が担当する。逆プロセスはすべて人間が管理する。発送はピッキングリスト、納品書などの印刷物の出力は自動化するがそれ以外は人間が管理する。
材料の入荷、差立は紙を廃止し、ネットワーク接続したディスプレイで行い、仕掛進捗もバーコード入力して管理する。
発送は営業が指示していたのを、納品日を指定しておき発送係りが担当することにし、結果を報告するように業務を変更する。
といった形で、どこまでをITが受け持ち、どこから先を人間が担当するのかを明確にする。
また従来業務の改善点も押さえておく。
決定事項は書類の形で残して置くことが望ましい。
書類は意思決定の証左となる。
次のステップはIT調達、導入である。
1 IT調達方法
IT調達はモノの調達と違って、所望のサービスを得るためのハードルが高い。
それにはいくつかの理由がある。
(1)仕様を表す仕組みがない
形のあるモノを作るときは図面と仕様書が依頼主と作り手の間の意思の疎通をはかる共通言語となる。これを使えば間違ったものが出来上がるということは少ない。
仕様が決まった商品では製品名やJANコードのような製品コードを使って調達することも出来る。
一方ITは形のないサービスとして提供されるものであり、多くの場合一品生産で同じものを調達することはない。
モノ作りにおける図面のような意思疎通手段がないのである。
開発においてもコミュニケーションが重要になる。
(2)発注方法がわからない
中小企業ではIT調達は日常的に行う作業ではない。
IT導入は5年に一度とか、10年に一度といった頻度である。
このため、発注者がどのように発注書を書けばいいのか、誰に引合を出せばいいのか、見積もり回答をどう評価すればいいのかなど分からないことが多い。
仕様書をうまく書けないために、ベンダーに口頭説明したり、現在の業務や使っている帳票を見せたりすることでベンダーに理解を求めることもよく行われる。
ITベンダーはITシステム開発のプロであるが、発注者の課題や、やりたいこと、業務内容などについて熟知しているわけではない。
この部分でITベンダーを過信すると、期待したものと大幅に違うものが出来上がることになる。自分で分からないものを他人が理解するということはありえない。
発注者とITベンダーは別の世界に住んでいるのである。
(3)ITは一品生産・手作りである
会社によって業務内容は異なるし、IT利活用能力も異なっている。要求されるITシステムは似てはいたとしても、他社で作ってシステムをそのまま適用できることなどほとんどない。
ITベンダーは生産性をあげるためシステムをパッケージ化したり、ERPといった標準的な仕組みを提供したりしているが、従来業務をすべて放棄して導入システムに合わせるようなことをしない限り、なんの変更なしにパッケージソフトを使うことは不可能である。
どうしても手作りの部分が発生する。使いやすいシステムにしようとすればするほど、手作り部分は増大する。
したがって、どのようなITシステムを欲しているかをITベンダー（＝ITシステムの開発者）に正確に伝える事が出来るかがカギになる。
2 提案依頼書（RFP=Request for Proposal）
調達方式に何種類かの方法がある。
仕様を確定的に決めた発注仕様書による入札方式や、ITベンダーが仕様を打ち合わせながら工数を積み上げていき、実際にかかった費用を請求する準委任方式などが従来行われてきた。
前者はIT調達にはなじまない方式であり、後者は開発費用が開発スタート後でないと確定できないという問題があった。
最近は、調達要件を記述したRFPをITベンダーに提示し、ITベンダーから見積仕様書に相当する提案回答書をもらい、それを様々な観点から評価してITベンダーを決めるプロポーザル方式が増えている。
この作業は専門的な作業になるのでITコーディネータのような専門家に依頼するのが得策である。
2.1 提案依頼書記述事項
RFPで記述すべき内容は導入するITシステムの内容や予算などによって異なるが、おおむね以下のような事項を記述する。
項目
|
内容
|
現状開示
|
ITベンダーになぜシステム開発に至ったのか、どういう会社にしたいのかといった想いを伝える
記述事項：会社の状況、経営戦略、現状業務プロセス、組織構成、現状システムなど
|
要求事項
|
どういうことをどの程度したいのかを伝える
記述事項：システム導入後の業務フロー、データ構成、画面・帳票イメージ、システムに対する要求事項、運用についての要求事項など
|
条件提示
|
提案依頼に当たっての前提条件を明示する
記述事項：予算(提示しないこともある)、スケジュール、発注者側の体制、検収方法、権利関係など
|
提案依頼事項
|
ITベンダー評価に必要な事項は提案・回答してもらう
記述事項：退出書類、提案依頼事項、発注方法、支払い条件など
|
特記事項
|
その他事項として、評価方法、提案事務、機密保持など
|
RFP記述の要諦は大まかでもいいから必要なことは漏らさず書くことである。
ITベンダーは要件定義前段階で開発費が確定する請負を嫌うことが多いが、仕様が明確なRFPを発行することで不確定要素が少なくなり、請負で見積もりをすることが出来るようになる。また。開発時の仕様齟齬も少なくなり円滑に開発プロジェクトを進めることが可能となる。
2.2 提案評価
ITベンダーからの提案書を受領し、プレゼンや仕様説明などで提案内容を評価して、ITベンダーを決定する。
評価項目は以下のようなものが考えられる。
|
評価項目
|
内容
|
ベンダー
|
財務、社内基準、成熟度、認証など
|
提案内容
|
実績、提案内容(RFP整合性、機能充足度など)など
|
見積価格
|
絶対額、バランス、積算根拠
|
開発体制
|
体制、コミュニケーション、スケジュール、契約条件など
|
ITベンダーはITシステムを共に開発していくパートナーであるので、相性や信頼が出来るといった定性的な評価も重要である。
3 IT導入
ITベンダーを決定すると契約を経てIT導入プロジェクトが始まる。
システム開発はいろいろな方法があるが、大枠を決めて次第に詳細化、出入り口の取り合いを決めて内部を開発というのが基本である。
各ステップの呼称や中身はITベンダーによって異なるが、概ね下図に示したような手順で遂行される。
短くても数ヶ月、大規模システムでは１年を超えるプロジェクトになるので、担当する従業員に過大な負荷がかからないように、経営者はプロジェクトオーナーとして進捗具合を把握するように努めたい。
プロジェクトを円滑に進めるためには業務知識に精通した人、ITの知識がある人、プロジェクトマネージメントが出来る人をメンバーに揃える必要がある。
適切な人材が自社やITベンダーにいない場合は外部専門家を招請することが望ましい。
IT導入は単にシステムを開発して従業員に使えと命令するだけではうまく動かない。
IT導入に伴って発生する業務プロセス改革や部署間の?閑の解消、意思決定部署の変更など業務面の改善変更も同時に進める必要がある。
中小企業においては、導入開発フェーズはITベンダー主導でおこわなれることが多く、発注をしてしまえば一件落着と考えやすい。このためシステムテストを十分行わなかったり、マスターデータの作成が不十分であったりすることがあり、こうした要因でシステムの立ち上げが円滑に行えなかったり、完成したシステムをうまく使いこなせない事例が多々あるので注意したい。
また出来上がったものを見なければ評価できないとして、要件定義や外部設計で十分な意見表明をせず、システム完成まで放置し、完成後にクレームを付け、費用の増大や開発期間の超過、あるいは不満足な仕上がりのシステムの受忍を招くケースもある。システム開発途上でも途中経過をチェックし、仕様どおりのものが出来上がっているかどうか十分チェックする必要がる。
次回はシリーズのまとめとして全体を振り返りポイントを解説する。
NPO法人ITC横浜副理事・未来計画代表 ITコーディネータ 齋藤順一
|
