テックノート

  • ルールベースAI/BRMS
2016.07.05

デジタルトランスフォーメーションのための超高速開発基盤! Vol.2

デジタルトランスフォーメーションのための超高速開発基盤! Vol.2

今やシステムは企業活動と不可分のものとなりました。業務改善といえばシステム開発と言っても過言ではありません。しかし、システム開発のおよそ7割は、「導入したのに使われない」「改善されない」という失敗に陥るとも言われています。「数十億円かけてシステム構築を行ったが、業務プロセスとシステム機能のギャップにより、開発から2年が経過してもカットオーバーの目途がついていない」。そんな話は珍しくありません。システム開発においては、業務上の問題点の可視化と抽出ができていない状態でスタートしてしまうと、できあがるのは「そもそも方向性から違っている」という残念なシステムです。

本稿では業務改善の観点から、システム導入で失敗しないための自立的な業務の可視化分析手法としての「BPEC」、それを利用してシステム要求につなげるための手法「B-NASS」について解説します。(全5回連載)


Vol.2 「システム導入したのに改善しない!」にならないために「BPEC/B-NASS」によるシステム構築

結局、人がいないと業務が止まってしまう


企業の抱える共通の問題点としてよく挙げられるのが、「属人的な業務の多さ」です。特定のスキルを持つ人に業務が集中したり、担当者に休まれると業務が止まってしまうといった問題は、まさに属人的な業務が及ぼす悪影響の代表です。

ここから脱却するためにシステム導入を行うわけですが、それでも解決しなかったという声も少なくありません。例えば、例外的な対応であったり、より細かな対応が求められたりといったプロセスがうまくシステムに反映できず、結局人の判断を仰ぐ工程がかなりの分量を占めたりします。または、本来必要な機能ではない部分ばかりがシステム化され、必要な部分は相変わらず多くの人手を介しているといった悩みです。

ITのプロであるシステム・インテグレータにシステム導入を任せたにも関わらず、なぜこのようなことになってしまうのでしょうか。

業務を正しく抽出・可視化するために


一戸建てを立てる時のことを考えてください。建築会社は顧客要望に応じ、適切な設計、適切な材料、適切な納期をコントロールしながら家を建てます。起点はあくまで顧客要望です。ここで家族全員の「理想の家」に対するイメージは、はたして一致しているでしょうか。システム構築も同様です。起点はあくまでシステムに対する要求ですが、このシステム要求をまとめる要件定義が、各業務の担当者に要求をヒアリングすることから始まっていることが多く、これが失敗の原因になります。さしづめ、家族がバラバラに自分の関心領域に関する理想の機能を言い合っているような状態です。

システム構築のための要求定義、つまりRFI/RFPは、単なる「欲しい機能」のリストになってしまっています。それらの機能は本当に必要なのか、それらには正しい費用対効果があるのか、そもそも業務は改善するのか、すべてを正しく管理していくにはやはり業務の可視化と課題の抽出が必要となります。

「また業務の可視化か」と思われた方もいると思います。数々の業務改善コンサルティング会社がこれまで要件マネジメントのために業務分析を行い、現場ヒアリングを行い、改善点を示した詳細な報告書を提出してきました。これだけ労力をかけた業務分析結果からRFPを提出しているにも関わらず、プロジェクトが始まるとまた要件定義からやり直し、結局使われないシステムができあがる。こういった経験から、日本企業は一種の「コンサルティング・アレルギー」に罹っているのではないでしょうか。

ここで紹介する「BPEC(Business Process Engineering Cycle)」も同様にコンサルティング手法ですが、従来のコンサルティングとは一線を画す以下のような独自性があります。

  • 現場担当者の負荷が少ない
  • 業務を抜け漏れなく抽出
  • 定量分析が容易
  • 本当に改善が必要な業務だけ可視化
  • 業務担当者が見落としがちな業務問題を抽出

BPECはコンサルタントが顧客先で手厚く実施する類のコンサルティング・メソッドではなく、担当者自らが継続的に業務を改善していくための手法です。

B-NASS for BPM/BRMによるシステム化への道程


BPECにより可視化された業務プロセスから見える課題を抽出すると、およそ以下のようなものになります。

  • 業務の連携やコミュニケーションが業務ボトルネックになっている
  • 個人の現在の業務ステータスがわからない
  • 担当者により業務のやり方、判断がばらついている
  • 特殊判断が多く、属人的になっている

これらの課題を解決する上で最も効率的なシステムアーキテクチャが、ビジネス・プロセス管理であり、ビジネス・ルール管理です。

この段階では、すでにBPECにより業務単位での改善すべきシステムや改善すべき周辺機能(ExcelやAccessなどによるエンドユーザ・コンピューティング環境も含む)は漏れなく洗い出されており、これらの定量的なコストもあきらかになっています。あとはこれらの課題とシステム機能のフィット&ギャップ分析を行い、RFI/RFPにまで落とし込んでいきます。このフェーズで使われるのは「B-NASS(BPEC Next Advanced Step Solution) for BPM/BRM」です。

BPEC/B-NASSソリューションの各ポジション

BPEC/B-NASSソリューションの各ポジション

BPEC/B-NASSは、株式会社BPデザイナーズ社の独自コンサルティングノウハウを、コンサルタントの力を借りることなく実行するためのものです。最小限の負荷で取り組むことができ、必要な業務にフォーカスして業務改善計画を作成できる点が、ほかのコンサルティング手法との大きな違いです。

まとめ


BPEC/B-NASS for BPM/BRMにより、改善が必要な業務を低負荷で可視化し、それらのシステム導入計画へと落とし込むことができます。業務改善のPDCAサイクルを回し、システム開発のROIを明確にできることで、システム開発は限りなく成功に近づきます。これまでのような手探りかつ失敗の多い「要件掘り起し」ではなく、明確な道筋を持ったRFI/RFP作成手法としてBPEC/B-NASSを採用することが、システム開発を成功に導き、IT部門の強化につながると信じています。


連載記事

デジタルトランスフォーメーションのための超高速開発基盤! Vol.1
デジタルトランスフォーメーションのための超高速開発基盤! Vol.3
デジタルトランスフォーメーションのための超高速開発基盤! Vol.4
デジタルトランスフォーメーションのための超高速開発基盤! Vol.5


執筆者のご紹介

アシスト佐藤 彰広

佐藤 彰広
DX推進技術本部

2002年入社。Oracle Databaseのエンジニアとして、企画・プロジェクト管理に従事。その後、ビジネス開発部隊として新規ソフトウェアの調査・発掘を経て、ルールベースAI「Progress Corticon」の日本での立ち上げを担う。

本記事をご覧いただいている方へのご案内

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。

関連している記事

  • ルールベースAI/BRMS
2021.02.19

ディシジョンインテリジェンスとは?
目的の異なるAIの融合で実現する判断と意思決定の高度化

本記事では、人の介在を最小化するスマートビジネスを実現するためのキーファクター「ディシジョンインテリジェンス」について解説しています。

  • ルールベースAI/BRMS
2020.04.14

10分で理解する「ルールベースAI」。今求められるAIとは?

様々あるAIのうちで「ルールベースAI」に焦点をあて、「ルールベースAIとは何か」から活用事例、導入における課題までを分かりやすく解説します。

  • ルールベースAI/BRMS
2016.09.21

デジタルトランスフォーメーションのための超高速開発基盤! Vol.5

従来、基幹システムで最も重視されたのは自社のビジネスを止めないための堅牢性であり、そこに多額の投資が行われてきました。しかし、ビジネスの中核を担う基幹システムが変革を阻む枷となってしまっているケースがあります。

ページの先頭へ戻る