Source
メモ
2.1 基幹系システムのハイレベル構造はどのようなものか
基幹系システム = 活動のシステム(Systems of Activities: SoA), 経営管理のシステム(Systems of Management: SoM)
※ SoA, SoM は本書固有の用語
SoA と SoM では、システムが変化する要因も異なる：
- SoA は現場でやるべきことが変わらなければさほど変わらない。
- SoM はマネジメントについての考え方次第で変わる。事業形態にも影響される。
よって、SoA と SoM は基本的に分離して考えるのが基幹系システム設計として適切な場合が多い。
読んだ所感
理解はできる。が、これ作る立場で考えるとかなり難しい気がする。システムのイベント、つまり活動のタイミングで必要な情報も多いはず。だから、システム作る側としては一定混ぜて考えないときついのでは？後から追加したり、サイドシステム的に SoM を構築したりとかはできるものだろうか？チーム構成にもよるかも。
→ これは 2.3 に出てくる「ビジネス・ルール」のところにも関連する。
2.2 活動のシステム(SoA)は現場活動を支える
SoA は 2 階層からなる：
- 上位層：業務プロセス
- 下位層：業務機能
業務機能
企業内の業務をその目的やスキルの同種性に基づいて分割した単位。営業機能、製造機能、etc.
業務機能自体も多段的になっている。営業機能の下位には受注機能などがある、など。
業務機能は、役割分担の基本でもあるため、組織設計の基礎にもなる。業務機能に基づいて分割された組織を「機能別組織」と呼ぶ。
業務プロセス
取引処理の流れに沿って業務をくくった概念。業務フローと同様。
例：「販売管理」業務：受注から出荷〜請求〜回収までの一連の業務の流れ
ゆえに、業務プロセスは業務機能を横断する。
業務機能の分割は「残」に基づく
現場活動は「残」を解消する方向に実施される。「残」を核として業務機能を分割することができる。
例：受注管理 ⇒ 受注残、在庫管理 ⇒ 在庫残、etc.
逆に言えば、「残」に基づいて業務機能が分割されない場合、「残」に対する業務担当が存在しないか曖昧である危うい状態といえる。
所感
「残」の考え方、すごいしっくりきた。ステートフルにしなきゃいけない場合って、未処理のもの＝ステートフルにしなきゃいけないものって多くある。で、未処理をいつのタイミングで実施するかによってイベントドリブンなのかバッチにするのかなど、システム責任の受け渡しについて考えたことがあるから、システムのデータって「できていないこと・やらなきゃいけないこと」の集合体だなって思ったことが多々ある。全てがこれってわけじゃないけど。
2.3 経営管理のシステム(SoM)は3層構造でPDCAを回す
SoM も層構造になっている：
- 上位層：財務的な計画管理
- 中位層：業務分野別の計画管理
- 下位層：現場に近い経営管理
下位層：SoAとSoMを接合する
「残」視点で分割された SoA 業務の多くには、それぞれに付随した SoM 的機能がある。
SoM 的機能の要件はマネジメントの考え方によって変わりうるため、業務要件を形作る SoA に比べて不安定といえる。よって、情報システム設計において仕様は切り離すべきであり、ソフトウェア設計においても切り離せるようにすべき。
SoA 業務の遂行のリアルタイミングを要しながら、SoM 的機能で必要な設定・判定を担う「ビジネス・ルール」が存在する。これはSoA的処理のなかにプラグインできることが望ましい。詳細は7章、10章参照とのこと。
中位層：業務を計画し活動を調整する
計画と実際が乖離した場合の調整や結果評価を行う。業務領域ごとのPDCA。
上位層：ビジネス全体の資源配分を担う
財務的な観点に軸足を置き、ビジネス全体の活動の総合的な調整を行う。
所感
ここでいう「情報システム」「ソフトウェア」の違いはなんだろう？
ぺーぺーの自分にとって、中位層と上位層はいまいちわからんのが正直なところ。
コラム：SoA と SoM - どちらが重要か
こうしたビジネスでは、基幹系システムはフロントエンドのWebシステムの延長として開発され、従来の基幹系システムでの帳簿デザインの知見が十分生かされていない面もあります。ノーマルケースは自動的に対応できるものの、ちょっとイレギュラーがあれば手でデータを直している、といった事象があれば、その疑いは濃厚です。今後、大いに改善の余地があるでしょう。
すごく耳が痛い気がするなぁ。
2.4 SoR はビジネスのためにあり、SoE はユーザーのためにある
基幹系システムは、事業組織のためのシステムであって、個々のユーザーを支援しているわけではない。
所感
基幹系システム畑じゃない、どちらかというと SoE畑の自分からすると、本書を SoE のアナロジーで読んでしまう。
2.5 伝統的な基幹系システムとの比較 / 2.6 本書が提起する枠組みの意義
これらについては、そもそも基幹系システムについて詳しくないので比較されてもよくわからんかった。インサイトは特になし。