[ホーム] > [ノーツドキュメントセンター] > [グループウェアを導入する前に]
Copyright(C) TOOLJP.COM
今日、グループウェアを導入する日本の企業は、近年非常に増えてきました。しかしいれただけで効果があがらず結果として失敗というケースも非常に多くみられます。なぜ失敗するのでしょうか?多くの原因は雑誌などの導入事例であたかも”絶大な効果”とあおられているのを見て「じゃーうちでも導入するか」とただ導入するだけで効果があがると錯覚するためだと思われます。
1.失敗するケース
まず、失敗する理由としてどのようなケースがあるか以下にまとめてみます。
ケース1 なにも考えていない型
「ITツール」をまったく誤解しているケースです。例えばプリンタサーバ導入(LAN上にプリンタサーバを導入し、プリンタを共有する)は、すぐに効果があがるでしょう。このようにグループウェアも導入しただけで効果があがると勘違いするケースです。
ケース2 問題を把握できていない型
仕事のやり方、作業プロセスの問題、及びその解決方法が定義されずに導入したケースです。例えば商談(商談発生から受注まで)をシステム化するとします。ただアプリケーションを構築するだけではうまくいきません。現在の問題点、及び解決方法を定義する必要があります。例えば「管理者が商談を把握できないので、受注できるはずの商談を失注する」という問題の定義、「管理者が商談を常に把握しフォローする」という解決方法を定義してからアプリケーションを構築する必要があります。
ケース3 ユーザがついてこない型
システムを導入しても、ユーザが使用しないケースです。誰でもいままでのやりなれた方法で仕事をするのが楽に感じ、新しいシステムを覚えるのはめんどうに感じるでしょう。このケースではいはば半強制的に使用を義務づける、使用しているか確認方法の運用を定義するなどが必要です。
2.システム導入前の検討事項
グループウェアでシステムを構築しようと考えている方は、以下のチェックシートを利用してみてください。次のチェックシートであてはまると思われるものに○をつけてみてください。導入前に問題点が自然と明らかになります。
| 確認事項 | チェック | |
| 01 | 現状の作業効率を落とす要因を把握している | |
| 02 | 作業効率を落とす要因の解決方法を把握している | |
| 03 | トップダウン的に使用を義務づけることが可能である | |
| 04 | 導入において、グループウェアを理解しているキーマンが存在している | |
| 05 | ユーザは、かな換の使用方法を理解している | |
| 06 | 導入事例の参照やベンダのコンサルティングを受け、自社システムに合うグループウェアを選定している | |
| 07 | 現状の作業プロセスをそのままシステムで実現するのではなく、システムにみあうよう作業プロセスを改良することを検討している | |
| 08 | 市販アプリケーションをそのまま使用するのではなく、カスタマイズ、あるいは新規作成を検討している | |
| 09 | いきなり導入するのではなく、部分的な導入を検討している | |
| 10 | 導入後のユーザの声を反映し、システムを改良するための費用を確保している | |
| 11 | システムを使用するそれぞれの部門にメリットが存在する | |
| 12 | システムを使用すべきユーザが使用しない場合、それを検知することが可能である | |
| 13 | 導入後、効果を定量的に図る仕組みが存在する | |
| 14 | グループウェアとOAソフト(ワープロや表計算)との違いを理解している | |
| 15 | 職制改正に対応可能なシステムである | |
| 16 | 業務の曖昧さがシステムでは排除されている | |
| 17 | システム上で延滞している作業を検知することが可能である | |
| 18 | 操作マニュアル、運用マニュアルが完備されている | |
| 19 | 文書の競合が発生した場合の対策が行われている | |
| 20 | 端末の使用環境が各ユーザにゆきとどいている | |
| 21 | セキュリティ対策は十分である |
どのくらい○がついたでしょうか。次に各項目について説明します。
| 01 | 現状の作業効率を落とす要因を把握している | |
| グループウェアを導入する以上、何かしらの効果を期待しているはずです。効果があるということは、現状の作業効率に問題があるということです。問題を把握してからシステムを決定し導入を行わないと効果が期待できません。 | ||
| 02 | 作業効率を落とす要因の解決方法を把握している | |
| 上記01と同様に解決方法を定義して、それをシステムとして実現する必要があります。 | ||
| 03 | トップダウン的に使用を義務づけることが可能である | |
| ユーザはやりなれた方法を好み、新しいシステムの使用方法を覚えるのを面倒に感じます。トップダウン的に使用を強制ずけることができない場合、システムを使用しないユーザが発生し、さらに使用しないユーザがいるためシステムの情報価値が減り、使用していたユーザも使用しなくなるという悪循環におちいります。 | ||
| 04 | 導入において、グループウェアを理解しているキーマンが存在している | |
| システムの運用の際には、必ずユーザからの質問、クレーム、改良要求が発生します。円滑な運用を図るには、必ずこれらを処理する管理者が必要です。管理者はシステムを理解していることはもちろん、グループウェアを理解している必要があります。 | ||
| 05 | ユーザはかな換の使用方法を理解している | |
| 文書入力のケースがある場合は、ユーザは最低限、かな換の使用方法を知っている必要があります。ただしボタンなどのUIのみで構成される場合は必要ありません。 | ||
| 06 | 導入事例の参照やベンダのコンサルティングを受け、自社システムに合うグループウェアを選定している | |
| グループウェア各ベンダが発表している比較表ほどあてにならないものはありません。ノーツは情報蓄積型アプリケーション、Microsoft Exchange Serverはメールシステムというように各グループウェアには向き、不向きがあります。以前にMicrosoft Exchange Serverで集計を行うアプリケーションを構築した某企業がありますが、アイテムが多くなるにつれビューの表示が異常におそくなり失敗に終わりました。この企業では、結局 アイテムをAccessに変換して集計を行いました。 | ||
| 07 | 現状の作業プロセスをそのままシステムで実現するのではなく、システムにみあうよう作業プロセスを改良することを検討している | |
| 現状でよけいな作業プロセスがないか確認してください。現状の作業プロセスを正確にシステムで実現すると、以外にシステムが複雑になります。特にベンダに開発を委託する場合には、ベンダはどの作業プロセスを省略するのか分からないため、正確にシステムが開発されてしまいます。 | ||
| 08 | 市販アプリケーションをそのまま使用するのではなく、カスタマイズ、あるいは新規作成を検討している | |
| 業務は各社独自のものであり、同一のものはありえません。市販のアプリケーションを導入しても、そのままでは絶対に業務にフィットしないでしょう。 | ||
| 09 | いきなり導入するのではなく、部分的な導入を検討している | |
| いきなりすべての作業をシステム化すると、ユーザの負担がとても大きくなります。例えば、まずはメールのみ導入してユーザに"遊んで"もらい、グループウェアに慣れさせるという方法もあります。 | ||
| 10 | 導入後のユーザの声を反映し、システムを改良するための費用を確保している | |
| どのようなシステムでも必ずユーザの改良要望が発生します。改良要望に対応するための費用と時間を確保しておく必要があります。 | ||
| 11 | システムを使用するそれぞれの部門にメリットが存在する | |
| ほんの一部門のみにメリットがあるシステムは他の部門のユーザの意欲をそそぎます。必ずすべての部門にメリットがあることを十分に計画、説明する必要があります。 | ||
| 12 | システムを使用すべきユーザが使用しない場合、それを検知することが可能である | |
| ほんのひとにぎりのユーザが使用しないために、システムが機能しない可能性があります。また、ほんの少しの情報が欠けているために、データベースそのものの価値がなくなるケースもあります。 | ||
| 13 | 導入後、効果を定量的に図る仕組みが存在する | |
| 上層部に効果を認めさせ、さらに導入、開発費を確保するため効果を定量的に図る仕組みが必要です。 | ||
| 14 | グループウェアとOAソフト(ワープロや表計算)との違いを理解している | |
| 基本的なことですが、グループウェアは導入(インストール)しただけでは効果がありません。 | ||
| 15 | 職制改正に対応可能なシステムである | |
| 職制改正により担当者が変更となる場合は、適切にユーザIDのみを変更可能にするなど対応が必要です。 | ||
| 16 | 業務の曖昧さがシステムでは排除されている | |
| 業務の曖昧さ、例えば"ユーザの忙しさにより作業が短縮する"などがある場合には作業を明確に定義する必要があります。 | ||
| 17 | システム上で延滞している作業を検知することが可能である | |
| 特にワークフローの場合には、延滞している作業を検出できないと埋もれてしまいます。 | ||
| 18 | 操作マニュアル、運用マニュアルが完備されている | |
| 操作マニュアルは、ユーザがシステムの操作方法を覚えるために必ず必要です。この際、管理者コールが発生しないよう一連の手順を漏れなく記述する必要があります。運用マニュアルは、運用に漏れがないかを確認する意味でもとても重要です。 | ||
| 19 | 文書の競合が発生した場合の対策が行われている | |
| ノーツやMicrosoft Exchange Serverでは文書が同時に編集されると "競合文書"として2つの文書として保存されます。これを防ぐために"文書の編集権を常に1ユーザのみにする"、あるいは"管理者による文書のマージ"など規則、運用を決定する必要があります。 | ||
| 20 | 端末の使用環境が各ユーザにゆきとどいている | |
| ワークフローや掲示板など時間が関係するシステムに対してはユーザが好きな時間に自由に使用可能な端末を用意する必要があります。某企業ではワークフローを導入したのですが、端末数が不十分で逆に以前より時間がかかってしまったという失敗例があります。 | ||
| 21 | セキュリティ対策は十分である | |
| なりすましによる文書の改ざんなど、不正に対応するセキュリティが必要です。ノーツの場合には nsfファイルに対するOSレベルのセキュリティも必要です。 |
完璧な導入をめざすならすべて○がつくまで計画を行い、その後に導入を行ってください。一度導入を行った後、システムを変更するには莫大な時間と費用が発生します。