システムのパッケージ導入②

パッケージ導入には導入したギャップ分析のために経験者が必要になります。
業法上のギャップ分析がきちんとできるかだけでなく、既存の事務処理とのギャップ分析既存の事務処理が作りだしている文化とのギャップ分析も必要になります。
パッケージ導入にはギャップ分析がどこまでできるかが勝負になります。
パッケジ導入作業をスキー場にたとえますと、平らな白いスキー場に見えていますが、実際は走ってみたらこぶだらけで、転んでばかりという事になります。
そのようにならない為、パッケージ導入の経験を持った優秀なコンサルティングが必要になります。

もうひとつ、パッケージ導入で問題になることがあります。
パッケージのバーションアップの問題です。
日本独特の修正を入れたり、その会社独特の修正を入れたりしますとバーションアップの時に再度その修正を入れなおさなければなりません。
どのようにこの点が解決されているか、導入時に調べなければなりません。
当初A社はパッケージの全面採用で開発していたのですが、今は一部採用になり既存のシステムが生き残った事になります。
既存システムは25年の時を生きて30年ぐらい生き残ることになりそうです。

システムのパッケージ導入①

各マトリックスのロジックはデシジョンツリーで書かれています。今だったらBRMSを使って構築するでしょう。

業務担当者が、デシジョンツリーを管理、システムの主要な部分を構築していくことになるでしょう。

業務担当者が構築できれば、ドキュメントも大幅に減らすことができ、開発工数も費用も削減できることになります。

ただ心配な事は処理件数です。2,000万件の処理に耐えれるかどうか。

さてA社のシステムですが現在は自社開発を断念して保険パッケージを導入したと聞いています。保険パッケージの導入を決定する時には文化というものに注意しなければなりません。パッケージ導入には、全部採用するか、一部採用するか。

既存のシステムがある場合は、一部採用であり、新会社を設立するのであれば全部採用にするのが原則だと思います。これは、既存のシステムがあると事務処理上文化が形成されており、この文化にパッケージを合わせるとなると大変な事になります。事務処理上文化が形勢されている場合は、パッケージは商品導入の部分にとどめ、既存のシステムと連携する方法を取ります。

その後統一性を求めるのであれば、パッケージのノウハウを吸収しそれを土台に自社で文化に合わせたシステムを開発することになります。

新会社を設立する場合は、パッケージに事務処理を合わすことができ、比較的抵抗なく導入されているようです。

システムの部品化（SOA)④

生保の保険金システムですが、ＢＰＭを使ってシステムを組めばよいのにと思っていましたが、三井きらめき生命では、イメージワークフローを使って構築をしたと聞いてこれから、やっと日本でもＢＰＭが採用されていくとおもいました。

さて、BRMSの方ですが保険金の査定処理の中では未だ使われておりません。
生命保険会社の中でロジックがはっきりしているのは査定のロジックであるとおもいます。
そのロジックの集大成が査定標準です。
査定標準のロジック数はそんなに多くなく300ロジックぐらいででしょう。ＢＲＭSで組めば3か月程度でできるとおもいます。
査定標準は査定業務に携わる人の中では当たり前のことで、そのロジックがシステム化されても何ら効果はないと思われるかも知れません。

しかし、1次査定者と上位査定者の査定結果が異なった場合、その原因の解析に力を発揮します。
査定ロジックはシステム上同じであるので、ロジックの取り違い（レセプト上は、同一の病気でも異なる病名で記述されているので）。あるいは、病気の程度判定で異なっている場合があります。異なった査定が発生したことも、その原因になったものが、
ロジックの取り違いなのか病気の程度判断ミスなのかすぐにわかるようになります。１次査定者に対する教育あるいはそれが全体的に起こっているのであれば、マニュアルの訂正・追加などの改善にもなります。

査定業務の品質を上げていくためにはＢＲＭSは必要になるでしょう。
ＢＰＭに関しては、査定のプロセスを標準化し、その通りに運用させる為にも。プロセスログを取り全体的な仕事量のバランスを監視し改善する為にも必要とされるものだと思います。

システムの部品化（SOA)③

システムが稼働した途端残業する人が一人もいなくなったという、まさに劇的な効果が表れたシステムでした。

Ａ社の入金処理は、外資系のため4半期決算を行っており入金日に関しては正確に反映されなければなりません。そのころのＡ社は法人の入金が８０％以上となっており月末に入金が集中しておりました。入金日を厳格に守るため、入金が判明してから法人の入金を個人別に割り振る作業を始めていました。月末に法人より入金があり、月初にどの法人より入金があったのかを確認し、法人の入金を個人の入金に割り振る作業をおこないます。月初の5日から12日までの営業日としては5日間に集中していました。この間には有給休暇を取ることは許されず連日の残業という有様です。

ある時に料金の担当者が、払込案内で処理をしてくれればいいのにという事を提案してきたのです。日本社のように1年に1回、入金日を厳格に処理するのと異なり、毎月入金日を厳格に反映させるという事を行っているので経理部門より難しという断りがありました。
しかしながら、どうにかならないかというということで独自に調査を行いました。
 

人事部は、25日の給与控除を行うために15日には払込案内の確定を行って経理部に回していたのです。遅くとも20日までに、Ａ社に振込金額と個人に振り分ける情報（脱退、加入などの異動情報）を郵送していたのでした。
払込案内に記載された金額とＡ社に振り込まれる金額は振込手数料を考慮しますと９９％あっていました。人事部が指示した金額を経理部が変える事はないのですから当然です。

この調査の結果から、払込案内で処理をすることに決めました。情報と現金の分離です。
情報で先に処理を行い、現金は確認に使用するというコンセプトです。情報は現金より早く流れてきます。実際には、お金の到着を待って処理を行うという手順から、先に情報（払込案内）により法人の入金額を個人に割り振るという作業を行いました。現金が到着した後、払込案内の入金額と実際の入金額をチェックするようにシステムをかえました。

そのマッチ率は９９％マッチするのですからほとんどやり直しという事はありませんでした。
作業時間は、前月20日から12日までの14日間の作業時間に延びました。約3倍に作業期間がのびたのですから、残業する人はいなくなるのは当然でした。

損害保険会社においては法人のお金を個人に割り振る作業は代理店が行います。そしてその結果を代理店勘定の清算ということで保険会社に報告をします。代理店の中にその作業をする人を雇います。能力に関して一定ではなく保険会社に報告される代理店勘定の品質もバラバラです。損保保険会社は代理店システムを改善して対応していますが、全国各地の代理店の事務処理を一律に上げるのは難しい状況です。

損害保険会社においても払込案内を基に情報で中央で処理をし、現金の照合のみを代理店に任せるというシステムを作りました。
その会社は一応損害保険会社に分類されていますが、親会社（外資）は生命保険会社です。払込案内を使う事からして、日本の損害保険会社からきた人からはありえないとといわれ、法人のお金を保険会社で分解することは、代理店に対する利益供与だと言われました。

代理店が代理店勘定をミスるたびに、営業の社員が飛んでいくことや、代理店がこの業務から解放されたことなどを総合的に考えますと、やってよかったと思います。このような代理店に対するサービスはこの会社だけのサービスとなっています。

システムの部品化（SOA)②

２０００万件の契約の請求処理を行っているシステムが２５年前のシステムだとしたら驚きますか。
Ａ生命では現在も生き残っており今後も使い続け３０年はこのシステムが生き残ることになります。
このシステムが生き残れた理由は、作る時に一つのコンセプトがありました。
それは、「成長するシステム」というコンセプトです。
その当時、Ａ社では提携業務が多く請求収納系は、新しい提携先ができるごとに修正を加えておりました。システムが、いわゆるスパゲティ状態になっており対応ができなくなっておりました。
ビジネス要件を早く柔軟に対応するシステムが望まれておりました。
ビジネスの要件をそのように早く柔軟に対応するシステムは、去年より今年の方がビジネス要件を吸収してより良いシステムとなっていくことになります。
それが「成長するシステム」という事になります。
その為には、どうすればよいのか考えました。

１　請求経路別、各処理別に部品化すること
行に請求経路（振込、日本信販、ＪＣＢ、ＪＡＣＣＳなど）。列に処理プロセス（失効、正常請求、併徴、再請求などのプロセス）となるマトリックスを作り、そのマトリックス単位に処理ロジックを組み立てました。

２　ロジックはデシジョンツリー
ロジックはデシジョンツリーで表現しました。デシジョンツリーは最初に一般的な口座振替代行会社、団体、振込に関して作成しました。次に同じものを利用できるものは利用し、ロジックに変更点があるものは別のロジックとして登録をしました。

この方法では、請求経路は各々独立したロジックを持つので、修正を加えた場合決して他の請求経路に影響を与えません。
また、新しい請求経路が発生した時は、以前のロジックを再利用するか、少しの変更を加えて新しいロジックとして登録するかにより新しい経路を作成します。

３　デシジョンツリーの管理は業務担当者
個々の処理ロジックをデシジョンツリーに落とすのは、業務担当者2名に加わってもらい徹底して夜遅くまで、３か月間行いました。
出来上がったデシジョンツリーの管理は業務担当者に任せました。
既存の請求経路の変更を行う場合も、新しい請求経路を作る場合もデシジョンツリーを基に業務担当者が修正を加えシステムに提示するという工程を作りました。業務担当者とシステム担当者の双方が理解できるドキュメントとしてデシジョンツリーが使われました。

４　デバックモード
デシションツリーの場合結果を示すデシション番号と、通ってきたロジックが一意に対応します。各ロジックのデシション番号を求めれば通ってきたロジックがすべてわかります。デバックモードにすると各ロジックのデシション番号が吐き出される仕組みをつくりました。テストの際、トラブルの際にデバッグモードをＯＮにすることにより、トラブルの原因が判明することにより効率化がはかられました。

今でいえば、「見える化」と「部品化」を25年前にＣＯＢＯＬで行った事になります。
処理ロジックは、マトリックスの単位ごとに部品化されています。経路ごとに独立した構造となっていますので、ある経路のロジックが変更されても、他の経路には何ら影響を与えません。
スパゲッティ状況のときはある経路に変更を加えると、予想もできないようなところに影響を与えていました。
修正を加えると、関係のない経路に関してもテストをしなければならない状況でしたが、このような構造を取ってから関連のない経路へのテストは必要がなくなりました。