Enterprise Blue Ocean ◮

神谷町RPAブログ

  • Blue Prism の 製品概要 がよくわかるWebページ動画取材記事
  • Blue Prism の Blue Prism 事始め!オンボーディングの記事はこちら
  • Blue Prism を 無料で利用する 方法はこちら
  • Blue Prism で Excelを操作 する記事はこちら
  • Blue Prism の ベストプラクティス 記事はこちら
  • Blue Prism の 逆引きナレッジ wiki こちら。ご活用ください☆

業務システムの歴史から考える RPA の未来①(1960年代~1990年代)

たまにはこういう記事もイイよNE!

(息抜きです。。)

(完全に個人の見解ですが、異論、反論、指摘は大歓迎☆)

 

 

はじめに

先日、こんな Tweet をしたんですけど、、

業務システムの観点での RPA 活用って、

寡聞にして。あまり見ないように感じてます。

 

世間ではサーバ型 RPA と呼ばれたりもしてる

ようですが、これって要するに H/W のサーバ機

(こういうやつ☟。画像は HPE Synergy )

f:id:EnterpriseBlueOcean:20191002152200p:plain

のイメージで、H/W としてのサーバ機で動かす

のがサーバ型 RPA と理解されている節があります。

まるで意味がない定義ですね。

 

かつてこんな記事も書いたんですが、

www.ebocean.work

もう少し広い視点で、かみ砕いた記事を書けないか

・・・というチャレンジが今回の試みです。

誰もが知ってる(?)業務システムの歴史から入って、

RPA の何が革新的なのか・・・を紐解いていきたい。

・・・が ん ば る ぞ い ☆

 

業務システムの歴史: 1960~1990年代の簡単な振り返り

1960~1980年代: 伝票処理の自動化

コンピューター活用のはじまり

1960年頃から、日本企業において業務システム、つまり

業務でのコンピューターの利用が始まったようです。

一部の金融機関では1950年代の終わりから導入したり、

また日本のメーカーが業務用のコンピューターを開発

していたようですが、一般的に普及が始まったのは

当時の売上推移を見ても 1960年代と見て良いと考えて

います*1

 

伝票処理の自動化 

当時のコンピューターは、いわゆる伝票の処理を

自動化するものでした。例えば何かモノを売るとき

には注文伝票を受け付けて、売り上がったら売上伝票

に転記して、請求書を作り、入金があれば入金伝票を

作って、・・・といった形で、伝票作成項目値の

転記計算処理といった膨大な定型作業を自動化

する仕組みです。 

f:id:EnterpriseBlueOcean:20191002161022p:plain

 

技術としての「算盤」が陳腐化 

1960年代以前は、すべて人手でやっていたので、

たくさんの紙があったし、算盤が社会人の重要スキル

として認められていたと聞きます。

私の母も算盤が得意ですが、算盤もある程度、習得

すると、頭の中で算盤をはじけるようになるそうです。

こういった暗算を駆使して進められていた伝票処理は、

業務システム導入によって置き換えられていきました。

 

業務システムの基本要素が出そろう 

最初はバッチ処理から始まった業務システムは、オン

ラインという名称でユーザーインターフェース

つまり画面が導入され、より使いやすくなっていきます。

業務システムの根幹を支えるデータベースもリレーショナル

型が大きなシェアを占めるようになり、ワークフロー

メッセージキューなど、現在の業務システム

基本的な要素が揃うようになりました。

 

十分に時間をかけることができた時代 

聞いた話ですが、このころの業務システムというのは

3~5年くらいの納期があったそうです。また、

私が新卒で入社した会社では、会社に入ってから

3年はひたすら勉強するだけで、仕事をするのは

それから・・・という時代だった、という話です。

うーん、想像つかん。。

 

主な出来事
  • System/360 を皮切りにメインフレーム時代が築かれる
  • 勘定系システムの構築(第一次~第三次)
  • ワークフロー、メッセージングキューなどミドルウエアの骨格が作られる
  • SQL、Oracle Database などが登場する
  • H/W や N/W は独自規格、専用機で占められる 

 

1990年代: ERPパッケージの台頭とEUCのはじまり

「ERP」「パッケージ」で全社最適システムを安価に導入

1990年代に入ると、SAP 社の SAP R/3(1992)に

代表される ERP(Enterprise Resource Planning)

パッケージが台頭します。

ERP パッケージには二つの意味合いがあったと思います。

  • ERP: 人事、経理、販売、在庫・・・といった業務にまつわる企業リソースを一元管理し、シームレスに業務を進められるようにする
  • パッケージ: 前提となる業務フローとそれに応じた業務システムが事前に定義され、出来合い(out of the box)のものとして提供される

ひとつのメインフレーム/ホストコンピューターで

すべての業務を賄えていれば別ですが、部門別に

システムがあると業務がシームレスにつながって

いきません。そういう観点での対策が ERP

 似たような会社の似たような業務を、毎回、

1から作っていくのは無駄が多い。そういう

観点でのパッケージ・・・という理解です。

 

ERP パッケージ導入の実際

ただ、この頃の ERPパッケージが、その理想(Vision)

を実現できたかというと、なかなか容易では無かった

ようです。

最近、JSUG(Japan SAP User's Group)から出た

書籍を読まれた方も多いと思います。

www.jsug.org

こちらの書評も参考になります。

www.sapsumikko.jp

www.orangeitems.com

結局のところ、ERPではなく、会計だけ、人事だけ

・・・と部分的な導入が進み、ひとつの会社に複数

の業務システムが存在する時代が到来したように

思います。

 また、パッケージという部分も、結局は既存の業務

をパッケージの標準に合わせることはできず大量

のアドオンを産む結果になったように思います。

このアドオンの問題は、現代にいたるまで様々な

影響を及ぼしています。

 

ダウンサイジングとオープン化

インフラ(基盤)の世界では、メインフレーム、

ホストコンピュータという専用機から、より

オープンで、安価な基盤への移行が進みました。

 Linux の登場もこの頃です(1991)。メインフレーム

やホストコンピューターでないと難しいとされた

ミッションクリティカルな業務処理が、オープン

ソースのOSと安価な H/W で実現できるように

なり、業務システムの調達コストは低下

ますます、様々な業務システムが乱立するように

なります。

f:id:EnterpriseBlueOcean:20191003123159p:plain

 

EUC が活発化

EUC(End User Computing)も、 1990年代

からより活発になっていきました。

何と言っても、この時代に、既に低コード(Low Code)

開発が可能な EUC 基盤が存在した事実が、

極めて重要です。

 Lotus Notes の最初のリリースは1989年*2

Notes DB という仕組みは、ユーザーでもあまりコード

を書かずに出欠や進捗などの管理表マニュアルや辞書

簡単なワークフローなどのアプリを作ることができ

最低限の権限制御が行える画期的な仕組みです。

 Lotus Notes は表計算ソフトや文書作成などの、

いわゆる Office 製品として進化したもので、

ライバルの Microsoft Office も 1994年には Excel に

VBAが搭載され、より容易な EUC 環境の実現が

加速していきます。

 

EUC は業務システムの救世主になったか

1960~1980年代で述べたように、この頃の業務

システムは伝票を処理するだけの仕組みです。

1990年代で急速に広まった ERP パッケージも、

伝票処理という主題は変わっていません。

 ただ、実際の業務は伝票を処理するだけで

まわるものではありません。一枚の伝票を作成

するまでに様々な業務が発生し、作成された

伝票を処理するにも、様々なやりとりが発生します。

伝票に乗っかる情報というのは、確定した数字と、

必要最低限の項目値だけです。

 そういった状況をサポートするために、

EUC ツールは大活躍しました。いくつかの

日本企業は、EUC を積極的に推進し、

Notes を最大限に活用してきたと聴いています。

そして、その結果はどうなったでしょうか。

èå»ããé½å¸ã®ã¤ã©ã¹ã 

 

EUC は効果の継続が難しい 

効果はあったのだと思います。しかし、予想

以上に長続きしなかったのではないか、とも

思います。

 そもそも、EUC が検討されるような領域は

変化が激しい、ということもあると思いますが、

重要なのは EUC で作ったアプリも業務システム

の一部である、ということです。

 業務システムの一部である以上、しっかりとした

ライフサイクル管理、つまり変更管理修正し

やすい設計、そして技術の改廃への追従などが

必要になります。そこから逸脱していくにつれて、

EUC の寿命は短くなります。

 EUC でも、いやむしろ EUC こそ、しっかりと

した管理が必要とされるのに、EUC は作りやすく

増殖させやすい

EUC はこのように深刻な自己矛盾を抱えており、

この自己矛盾のコントロールを誤ることで、寿命

が短くメンテナンス不能な遺産を作ってしまった

・・・そういった声を聴くことが、少なくない

ように思います。

 

主な出来事
  • SAP R/3 1.0 がリリース(1992)
  • Linux の登場(1991)
  • Lotus Notes の普及、Excel VBA のリリース(1994)

 

まとめ

  • 1960~1980年代: 1960年代に業務でのコンピューター利用が本格化(業務システムの誕生)。しかしカバー範囲は基本的に伝票処理
  • 1960~1980年代: 技術としての算盤が陳腐化した
  • 1960~1980年代: この頃は、業務システムを作ったり、技術の習得に十分な時間をかけられた
  • 1990年代: ERPパッケージが台頭。シームレスに業務を行える統合された業務システムと、車輪の再発明を防ぐパッケージが組み合わさり最強に見える
  • 1990年代: しかしERPパッケージの夢は、部分導入アドオンの急増でとん挫する
  • 1990年代: インフラ(基盤)ダウンサイジングとオープン化で安価になり、業務システムの部分導入は加速ひとつの企業に複数の業務システムがあるのが普通になる
  • 1990年代: 伝票処理しかできない業務システムによって発生した空白を埋めるために、EUC が大活躍する
  • 1990年代: しかし EUC の管理は難しく、やがて少なくない企業が EUC の負の遺産に悩まされることにある

 

・・・長くなってきちゃったので、

ちょっとここで一回、締めます。

 

次回はこちら。2000年代です。

www.ebocean.work

 

RPA が出てくるのは 2010年代なんだけど、

いろいろ伏線があるんだZE☆彡