Column

例外を例外として処理するシステム設計

システム設計において例外は例外として処理すべきであり、標準的なプロセスとすべきではない。

公開 2007年03月26日 05時00分

更新 2012年09月04日 19時49分

著者

Niel Nickolaisen

[TechTarget]

印刷する Googleで優先するソースとして追加

　週に1度の現状報告会議の後、ダイアンが困った顔でわたしのところにやって来て、声を落として言った。

　「二ール、支払い分割のことを忘れてた」

　わたしには意味が分からなかった。「支払い分割？　何のこと？」

　ダイアンの説明によると、わが社ではコールセンターを通じて注文を受ける時、顧客が複数のクレジットカードで買い物をすることを認めている。例えば50ドルの注文のうち30ドルをVISAカードで、20ドルをMasterCardで払うことが可能だ。

　「なぜそんなことを？」とわたし。

　「顧客サービスのためでしょう。今までずっと、新システムの必要条件に入れるのを忘れていた」

　導入から25年たった旧式システムを新しいERPに入れ替えるプロジェクトで、ダイアンは販売注文処理のリード役だった。わたしたちは、目的別に割り振るモデルを用いて会社の「差別化」につながっている活動を3つ挙げていたが、その1つが素晴らしい顧客サービスだった。さらに、差別化にはならないが会社の競争力維持を支えている活動（パリティプロセスと呼ばれる）も挙げていた。これらシステムプロセスの設定において、わたしたちはありふれたアプローチを採っていた。

新規定を作らない例外処理

　差別化を図る手段の1つが素晴らしい顧客サービスであり、支払い分割を認めることは顧客サービスになるからといって、新システムを支払い分割に対応させるためのカスタマイズにリソースを割く必要があるかどうか、わたしは疑問に思った。ダイアンとわたしの関係は良好だったので、この話を持ち出してみた。

　「ダイアン、うちの会社は支払い分割を処理できますと宣伝しているのかな」

　「いいえ」

　「支払い分割が本当に素晴らしい顧客サービスになるというのなら、それができますと宣伝すべきじゃないか」

　「顧客の便宜のために提供しているだけだから」

　「なるほど。支払い分割ができることが差別化につながるなら、新規顧客獲得の助けにもなるだろう。ところで支払いを分割したいという客はどれくらいいるのかな」

　「繁忙期で多分、1日に1～2回くらい」（繁忙期の1日当たり注文件数は約1000件だ）

　「ダイアン、これは素晴らしい顧客サービスを提供するための手段じゃないよ。1000件に1件の例外だ。例外は例外として扱うべきだ」

　「どういう意味？」とダイアンは尋ねた。

　「システムは例外処理のために設計するんじゃないということだ。支払い分割は、あればいいが必須の機能ではないと君も思ってくれるなら、システムをカスタマイズせずに対応するやり方を見つけよう」

　ダイアンは賛成してくれ、わたしたちはごく普通のシステム設計を使って支払い分割に対応するプロセスを考え出した。

　現在、顧客が複数のクレジットカードで代金を支払う場合、オペレーターが1枚のカードで部分払いを適用し、残額の支払いに使ったもう1枚のクレジットカード情報は特記事項欄に記入する。次に残額でクレジットラインを開く。この注文はクレジット受け入れか拒否かの判断のため、ERPシステムで自動的にクレジット管理者に送られる。注文を受けたクレジット管理者はアカウントを開き、特記事項欄のクレジットカード情報を使って残りの金額の支払いを処理する。

　これはソリューションをカスタマイズする優れた方法とは言えないが、例外を例外として処理している。例外はできる限り最善の方法で処理されるべきだが、システムがサポートする標準的なプロセスとして処理すべきではない。

　顧客に満足して欲しいという思いから、例外をもとに設計することはどれくらいあるだろうか。そうすることで、目に見える事業上のメリットがあるのか。わたしの経験ではメリットはない。

本稿筆者のニール・ニコライゼン氏は、エネルギー／建設資材会社ヘッドウォーターズ（本社ユタ州サウスジョーダン）の戦略計画担当副社長。

印刷する

この記事の著者

Niel Nickolaisen

例外を例外として処理するシステム設計

新規定を作らない例外処理

この記事の著者

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓