可用性が確保できないシステム化は、会社全体の停止リスクがあるもの
「可用性」という言葉をお聞きになったことがある社長は少数だと思います。可用性とは、システムが停止することなく稼働し続ける能力のことを指しますが、中小企業の場合大企業よりも、この「可用性」に対する考え方をしっかりと持っておかないといけません。これを無視したり、十分な検討が無いままシステム導入を進めると、大きなビジネスリスクに発展する可能性があるだけでなく、システム化投資規模の肥大化を招く可能性があります。
そもそも「可用性」が低かった・充分な可用性が確保できなかった場合に、どんなことがおきるのか実例を元に解説します。
A社は販売管理システムを導入して数年経過した中堅企業でした。システムを導入する前には、手書きの受注伝票をもとに出荷伝票や発注伝票を起票し、カーボンコピーの複写用紙が多用されている会社でした。そこにシステムを導入することによって、在庫管理や発注管理も含め、統合的にシステムで受発注管理ができるようになりました。それにより、A社は伝票が基本的に存在しない業務への変革ができました。まさにこれこそ中小企業が求めるべきIT化の鏡のような状態になった訳です。これによってA社は営業効率も高まり、受注件数も伸ばすことができましたし、バックヤード業務の合理化にも結びついた結果、売上も利益も伸ばすことができました。
ところがある朝、社員が通常通り業務を開始しようとしてPCを起動したのですが、システムの画面が現れません。他の社員も同じ状態でオフィスには動揺が広がりました。営業開始時間になってもシステムは起動しなかったため、現場はほぼパニック状態です。その知らせはすぐに社長にも届いたので、社長はシステム担当の総務部長に対応を指示しました。総務部長はシステム開発と保守を委託しているB社にすぐに連絡を入れて対応を依頼したのですが、B社からは驚くべき答えが返ってきました。「A社さんのシステムが動いているクラウドサービス全体が停止しているので、当社には何もできません。状況がわかりましたら改めて連絡しますが、クラウド側の問題なので復旧のメドも当社には解りかねます。」
こうなるとA社はなすすべがありません。お客様からの在庫問い合わせには答えられない、納期のお問い合わせに対してもしかり、受注はメモ用紙に書きため、商品の情報についてもカタログを引っ張り出して調べる始末。システム化前の伝票時代の方がもっとスムーズに対応できていたかもしれない、という原始的な対応を強いられました。そうこうしているうちに、昼頃唐突にシステムが動き始め、使える状態になったかと思われたものの、システム保守委託先のB社から電話で「まだ完全復旧したか確認できていないので使わないで下さい。」と言われ、現場の不満が溜まります。じりじりと待っていてようやく昼休み明けにB社から使用OKとの連絡が来て、午前中にメモ書きでためていた受注を登録しはじめ、全部終了したのが夜22:00過ぎ。物流の稼働時間を超えてしまった為、当日出荷予定だった商品の出荷遅れも発生しました。
A社は可用性を全く無視していた訳ではありません。自社内にサーバーを設置するよりもクラウド上の方が事故が発生しにくい、可用性が高い、と聞きクラウド上にシステムを構築していたので、ある一定の判断は下していた訳です。ところが、クラウドそのものがダウンするという「想定外」の障害が発生してしまい、対処方針が何も無い状態に陥った訳です。
通常、「可用性」を高めるためには「冗長構成」と呼ぶ、言わば予備機的なものを用意しておくのが常套手段です。ところが「予備機」を持つとなると、初期投資は2倍またはそれを超えます。更にスピーディーな復旧にはかなりの技術的練度が必要ですし、それなりに投資も必要となるため、中小企業にとってはあまり現実的ではありません。
では、資金的な肥大化を防ぐ可用性確保はどうすれば良いのか?考え方は2つしかありません。
- クラウドは止まっても数時間で復旧することを信じ、停止している間手動で業務を継続できるようにあらかじめ準備しておく
- システムの全機能を1つのシステムで実現するのではなく、2つ、3つ程のブロックに分割して実現し、1つが停止しても被害を最小限に留められるようにする
前者は非常に原始的なものではありますが、システムが停止している間、人間がどのように対応するのかあらかじめ手順を決めておく、という非常に堅実なものです。費用もそれほどかからないため、システムによる可用性向上の為の費用がかけられない中小企業にはベターな戦略です。
一方後者は、本来1つのシステムで組めるものを複数に分割する、という考え方なので一見すると非合理に見えます。しかし、「複雑な機能を1つのシステムに全部実現するためのハードル」を考えると、「単純な機能を複数のシステムに載せて、それぞれを連携させる」ことは、開発規模の肥大化を防止できるだけでなく、「機能の全停止」の防止を実現できる手段でもあります。
どちらを採用するか、それはシステムに載せる機能の重要性や、業務継続性の優先度にも依るため、一概に決めてしまうことはできません。企業それぞれの事情に応じて注意深く検討することが必要です。ただ、いずれにしても・・・
システム化する以上、その可用性を考慮しないという選択肢は無い
ということを理解した上で、その検討を進めるべきなのだ、ということは強くお勧め致します。
システム止まった、即ビジネスが止まった・お客様にご迷惑をおかけした
などといった事態にならぬよう、目立たない地味なことではありますが「可用性」について是非検討してみることをお勧めします。
成長直結型IT導入法 5大改革セミナー(オンライン)を開催します。前回のコラムでもお話した、BPRについても織り交ぜながら、企業のIT化をきちんと成功させる、目に見える効果を出すための改革ポイントを効率よく把握できるチャンスです。詳しくはこちらをご覧ください。
コラムの更新をお知らせします!
コラムはいかがでしたか? 下記よりメールアドレスをご登録いただくと、更新時にご案内をお届けします(解除は随時可能です)。ぜひ、ご登録ください。