| « 2007年7月26日 | 2007年7月27日の投稿 |
2007年7月28日 » |
業務改善のプロジェクトでは、多くの場合ITの有効活用が主軸に据えられます。確かに、自動化、効率化、可視化など、様々な業務改善の側面でITは役に立ちます。しかし、その一方で、業務改善プロジェクトで失敗に終わっているケースにおいても、その大きな原因の一つとしてITの適用が指摘されることが多くあることも事実です。
おかれている環境、アプローチ、はたまた人的な理由など、失敗の原因をたどっていくと千差万別のものにいきつくと思います。しかし、ITの効率活用ができずに業務改善が頓挫した多くのケースにおける失敗の原因は、システムとしてできること、やりやすい方法を中心にして業務やプロセスを設計してしまったことが上げられると思います。特にパッケージ製品などの場合には、業務との適合性とは言いますが、実質的にはパッケージ機能に合わせて業務改善等が行われた結果、組織的、プロセス的に破綻をきたしているケースが多いと思います。
個人的に経験した仕事をベースとして考えると、まず業務改善は誰がやる、何を使ってやる、どのようにやる、と言った実装方法は後回しにして、改善のポイントを明確にすべきです。そして次に、組織や環境に合わせて具体的な方法を定義し、その後にITの適用方法を検討すべきだと思います。つまり、ITを道具として明確に理解したうえで、企業として考える最適化された業務実施の方法に対して、ITが活用可能な部分、活用する必要の無い部分という分類を行うべきなのです。活用可能な部分に対してパッケージが有利であれば活用すべきでしょうし、そうでなければ、開発するべきだと思います。
上記のアプローチを行う場合には、客観的でかつ高度な要件定義作業、そして業務設計作業が必要になります。この作業にかかる工数を削減するために、初めからITありき、パッケージありきのアプローチを行った結果、業務改善が頓挫してしまうケースも多いと思います。
業務改善だけでなく、すべてのプロジェクトにいえることですが、やはり肝は、要件と業務設計であり、システムありきでは本来あるべきもの、効果の高いものは構築できないと思います。
| « 2007年7月26日 | 2007年7月27日の投稿 |
2007年7月28日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命