アメリカのサプライチェーン・カウンシル（SCC：現在はAPICS-SCC）がSCOR（supply chain operations reference model）を提唱したのが1996年というから，もう20年近くも前と言うことになる。
その歴史の中で，SCORの姉妹編として，設計チェーンのDCOR，カスタマーチェーンのCCORが順次追加され，昨年は製品ライフサイクルを扱うPLCORのver1.0がリリースされた。これらのプロセス参照モデルを総称してXCORと呼ぶ。
何を持って「XCORは成功した」というかは議論のあるところだが，少なくとも弊社の私の所属する本部では，本部長が「DCOR領域を扱う組織を立ち上げる必要が…」と発言し，各商品グループが年度計画の資料にXCORベースのプロセスマップを織り込み，「Ideateはあのグループの担当だ」とか「Relateプロセスはだいぶ成熟してきた」とか「あの製品はDeliverプロセスの定義が不明瞭だ」などという会話が日常的になされるようになってきた。XCORシリーズのコアプロセスが，普通の技術用語のレベルで浸透してきた，と言ってよいだろう。
弊社の場合は，10年以上何とかの一つ覚えでXCORシリーズのプロセスマッピングを続けてきた私もさることながら，カリスマ性と強力な情報発信力を備えたパワフルな先輩，CCOR領域の新規プロセス開発と導入定着化に成功したスマートな後輩の貢献が大きい。
そういった人的要素もあるが，基本的にはXCORシリーズが「何らかの点で」優れていた事は見逃してはならないと思う。
何が優れていたか？
一つは，XCORシリーズが「構造的」である事を挙げたい。いくらか文学的に言えば「美的」なのだ。
世に「プロセスモデル」を標榜するものはいろいろあるが，プロセスを漫然と列挙した「事例」のようなものも少なくない。それでは構造的な，論理的なプロセスモデリングはできない。
XCORほどシンプルで明快な構造を持ったプロセスモデルはないかも知れない。
例えばSCORはSource, Make, Deliver の3つの実行プロセスからなるが，中心となるのはDeliverである。Deliverの前半が要するに「受注」であり，DeliverがMake（生産）ないしSource（調達）を手配する。その結果を集めて「出荷」するのがDeliverの後半である。従って，SCORのプロセスは大抵Deliverを前後に備え，Source，Makeを挟んだサンドイッチ構造になる。極めてシンプルである。
詳細は省くが，同じ構造はDCORにも引き継がれている。
もう一つ挙げれば，命名が優れていた，と言えるだろう。
サプライチェーンの実行プロセスを「Source」「Make」「Deliver」という3つの，大変初歩的で単純な動詞にバッサリと分解した。このインパクトはなかなかのものである。ごちゃごちゃした複雑な議論を許さない。
例えば，既存のハードウエアに顧客向けにソフトウエアをインストールしたり環境設定したりする「キッティング」という業務があるが，装置自体の製造とキッティングを異質なものとして考える複雑系の思考を排除してくれる。装置の製造もMake，キッティングもMakeなのである。「キッティングはMake！」と単純明快に言い切る割り切りが思考を整理してくれるのだ。
たった3つしかないし，簡単な英語である。日本人にも訳なく覚えられる。誰でも一度聞いただけで覚えられ，専門家でなくても同じように使うことができる。単純な言葉を共有してコミュニケーションができる。
さらになじみのない「新製品立ち上げ」のプロセス領域でも，PLCORで「Ideate」「Develop」「Launch」と単純な言葉で割り切ってくれるので，前提知識のない人でも参入に抵抗感が少なくなる。
XCORも長い間「一体これが何に役立つの？」とか「そりゃモデル化できるのはわかるけど，だから何だって言うの？」と言われてきたが，20年あまりの歳月を経て，ようやくその真価が認められ始めたようだ。
（VCPC理事 橋場記）
Follow me!
