00 / TITLE

システム化できていない業務領域を、
動かし始める60分

業務変革を始める時、ツール選定から入っていませんか?
今日は「正しい順序」と「その第一歩」の話をします。

00 / 会社紹介

お客様の競争優位を、
今日から実装する。

会社名

株式会社PortX

代表者

石田寛成

資本金

1億円

設立

2019年12月6日

本社

東京都新宿区新宿 2-5-12
FORECAST新宿AVENUE 6F

事業 ①

Formula — エンタープライズ AI 基盤

事業 ②

サプライチェーン SaaS — 業界特化型

00 / 冒頭

問い

システム企画、
最初に何から始めますか?

おそらく — ツール探しから始めた方が多いのではないでしょうか。
今日はそこから一緒に考えます。

00 / イントロ

今日のゴール

この60分で、3つを持ち帰っていただきます

GOAL 01

システム企画の"正しい順序"が腹落ちする

GOAL 02

明日から試せる"最初の一歩"が見つかる

GOAL 03

今の困りごとが"構造的"なものだと分かる

00 / アジェンダ

Agenda

2部構成でお話しします

PART 01

なぜ "進められない" のか典型的な失敗パターンと、その下にある3つの壁

PART 02

どうすれば "動く" のか正しい順序、従来との違い、実例デモ

01 / PART 01

PART 01

なぜ "進められない" のか。

— 詰まる症状の下に、3つの構造的な壁があります。

01 / 症状

こんな経験、ありませんか?

典型的な、4つの失敗パターン

例 A

自社に合うツール探しから始める
→ 完璧に合うツールがない

例 B

機能比較表が長大化
→ どれも似て見える

例 C

ベンダー提案が似てくる
→ 判断基準がない

例 D

評価基準が作れない
→ 何を基準にすべきか分からない

01 / 構造

構造

症状の下には、
3つの構造的な壁があります。

これが分かれば、何で詰まっているかが見える。
そして、何をすれば突破できるかも見える。

01 / 壁①

壁 ① / 3つの壁

AsIsが見えていない

症状

「業務は分かっている」と思っているが、実は 自部門の業務でも自分が担当していない範囲 は、あまり見えていない。

なぜ

業務が部門間でサイロ化しており、隣部門の実態までは把握できていない。"知っている" と感じるほど、死角には気づきにくい。

影響

AsIs が不確か = 業務要件が不確か。業務要件が不確かなら、ToBe も不確か。ToBe が不確かなら、ツール選定も不確か。→ 企画のすべてが "不確かさ" の上に積み上がる。

01 / 壁① · 事例

匿名事例 — ある食品メーカーの受注配車プロセス

当初、関係者は 「3人」 という認識だった。

実際に棚卸ししてみたら — 9人が関わっていた。

しかも最大のボトルネックは、全員が"当たり前"だと思っていた
受け渡しのメール待ちだった。

AsIsは、整理してみないと見えない。

※ この事例は、本日のお土産「AsIs分析キット ①」の記入例として同梱しています

01 / 壁②

壁 ② / 3つの壁

ありたき姿がぼんやりしている

症状

「一元管理」「脱Excel」「見える化」でまとまってしまう。

なぜ

日々の業務が忙しく、"理想"を考える時間がない。システムの絵しか見えず、業務がどう変わり、どのような経済的価値が生まれるかまで降りてこない。

影響

目的が曖昧なので、途中で判断がブレる。評価基準も作れない。結果、現行踏襲を前提にしたツール探しになる。

01 / 壁③

壁 ③ / 3つの壁

ToBe業務フローの作り方がわからない

症状

ToBeを考え始めても、結局 "≒ 現行踏襲" になる。

なぜ ①

そもそもToBeを漏れなく言語化するのが難しい。AsIsが整理されていないと、現時点の業務要件すら不明。だから、何をどう変えるかも決まらない。

なぜ ②

仮に書けても、"動くToBe"がないとイメージできない。絵だけでは現場は動かない・合意しない。

影響

ベンダー選定の土台が曖昧になり、結局ベンダー任せ。自分たちの業務なのに、決定権が外側にある状態に。

01 / 壁② × 壁③ · 事例

匿名事例 — ある大手化学メーカー (壁② × 壁③ の重なり)

物流部と販売部にまたがる業務を改革したくて、
半年かけて 4つのツールを比較検証された。

ツールごとに「ここは合う／ここは合わない」を整理。
検証が進むほど、どのツールも決め手を欠く。

結果 — どれも、自社には完璧には合わなかった。

なぜか。ありたき姿も、ToBe業務フローも描けていなかったから。
だから検証の起点は 「今の業務 (現行) に合うか」 にしかならず、
販売部も巻き込んだ複雑な現行フローを "そのまま" 動かせるツールを探すことになった。

壁② × 壁③ が重なると、現行踏襲前提のツール選定しか選択肢が残らない。

※ この事例は、本日のお土産「AsIs分析キット ②」の記入例として同梱しています

01 / 壁の乗り越え方

この3つの壁、
こう乗り越えます。

ここから、3つの壁に対応する
3つの具体的な道筋をお見せします。

02 / 正しい順序

正しい順序

ツール選定は、"最後"に来ます。

STEP 01

AsIs整理

→

STEP 02

問題プロセス特定

→

STEP 03

ToBe設計

→

STEP 04

ツール検討

各ステップで何をFIXするかが決まっていることが、次のステップに進む条件。
この順序を飛ばすと、必ずどこかで詰まります。

02 / AsIs-ToBe 繋がり

AsIs と ToBe は、繋がっている

ToBe は AsIs の延長線上にある

AsIs 業務プロセス

01P1

!02P2

03P3

!04P4

!05P5

06P6

KEEP

CHANGE

KEEP

CHANGE

KEEP

問題プロセスを "ありたき姿" に照らして変革

問題プロセスの特定 → ありたき姿との照合 → 変革 or 維持の判断

ToBe 業務プロセス

01P1

02P2′

03P3

04P4′

05P5′

06P6

AsIs の各プロセスは、"維持" または "変革" として ToBe に引き継がれる。
ToBe は AsIs と別物ではなく、問題プロセスだけをありたき姿に照らして変えた "業務の進化形"。

02 / STEP 01 · 粒度

STEP 01 · AsIsには、2つの粒度レベルがあります

自分で書ける粒度 / 一緒に書くと見える粒度

LEVEL 1 · 自作できる実用レベル

担当者 × 受渡物 × 所要時間

— 自社で 1〜2 日で書ける深さ

誰が / 何を / いつ(担当・受渡物・タイミング)
所要時間と判断基準まで落とす
"当たり前" の受け渡しも書き出す
→ 問題プロセスは自力で特定できる

LEVEL 2 · 業務設計支援で到達

意思決定 × 暗黙知 × 摩擦

— PortX と数日〜1週間で到達

Level 1 のすべて +
意思決定ポイントと暗黙知を構造化
部門間 / 役割間の摩擦の原因分析
→ "動くToBe" 設計の土台が完成する

Level 1 だけでも価値は十分。Level 2 は、必要に応じて。

先ほどの食品メーカー (9人判明) の事例も、Level 1 の粒度で書き出したから "メール待ち" のボトルネック が見えてきました。

02 / よくある間違い

よくある間違い

この3つ、やっていませんか?

✕

ステップを飛ばす
STEP 04 からいきなり始める

✕

逆順に進める
STEP 04 → 03 → 02 → 01 の順で考える

✕

各ステップを"文書"だけで終わらせる
絵だけでは業務の実態までは伝わらず、現場との合意形成が難しい

02 / 洞察

動くものを見たい — これは、正しい心理です

ツール選定から入るのは、むしろ自然な直感

①

心理
なぜツール選定から入るか

動くものを見ないと、合っている／合っていないが議論できない。この直感自体は、むしろ正しい。

↓

②

でも
タイミングを間違えると

AsIs も問題もありたき姿も曖昧なまま"動くもの"を見始めると、目的不在のPoCや部分導入 に陥る。

↓

③

正解
"動くToBe" はここで使う

AsIs 明確 × 問題が分かる × ありたき姿が決まる が揃った上で、ToBe 業務フローを固める時に "動くToBe" を使う。これなら、圧倒的な解像度で合意形成が進みます。

02 / キーワード整理

ここで、今日のキーワードを整理します

"動くToBe" とは、3つの条件を満たすToBe

条件 ①

業務シナリオが達成可能

実データ・実ユーザー・実業務で、最初から最後まで動く。

欠けると: 絵に描いた餅のまま

条件 ②

事業価値の手触り

KPI やコストの変化が、数字と体感の両方で伝わる。

欠けると: 経済合理性が納得できない

条件 ③

触れて修正できる

使いながら、現場の声を翌日反映できる。

欠けると: 一度作って終わりになる

この3つが揃って初めて、ToBeは "動く" と呼べる。

02 / DEMO

いまから、実例デモ

ある食品メーカーの
受注配車業務を、
数日間でここまで動かしました。

02 / 事例 · 続き

先ほどの大手化学メーカー、続きがあります

ご一緒することになった時、最初にやったのは ツール選定ではありません。

やったのは、この2つ。
① AsIsの業務プロセスのどこに問題意識があるかを調査
② ありたき姿を実現するために、AsIsをどう変えないといけないかを明らかに

ツール選定とは完全に切り離して、これをまずやった。
先方からも 「この進め方が、非常に良かった」 と。

その上で改めて市場を見たが、やはり当てはまるものはなかった。
だから、その"変えるべき業務"を — Formulaで再現しました。

03 / お土産

本日のお土産 — AsIs分析キット一式

本日の話を、明日から実行できる形でお渡しします

①

AsIs整理 1枚テンプレート

自部門の業務プロセスを1枚で可視化　·　記入例を同梱

②

ありたき姿フレームワーク (3 sheet)

問題プロセス整理 / Before→After / 変化点の優先順位　·　記入例を同梱

③

使い方ガイド

3ステップの進め方 + 落とし穴5つの対処　·　迷ったらここに戻る

8割の粒度で始めてOK。記入で迷ったら、PortX にお気軽にご相談ください。

04 / Q&A · 問合せ

Thank you.
ご質問をお寄せください。

Q&Aに入ります。チャットへの書き込みも歓迎です。
個別相談・ワークショップのお申込みは下記から。

AsIs整理ワークショップ・個別相談

https://www.portx.jp/contact

システム化できていない業務領域を、動かし始める60分

システム企画、最初に何から始めますか?

この60分で、3つを持ち帰っていただきます

2部構成でお話しします

なぜ "進められない" のか。

典型的な、4つの失敗パターン

症状の下には、3つの構造的な壁があります。

AsIsが見えていない

ありたき姿がぼんやりしている

ToBe業務フローの作り方がわからない

この3つの壁、こう乗り越えます。

ツール選定は、"最後"に来ます。

ToBe は AsIs の 延長線上 にある

自分で書ける粒度 / 一緒に書くと見える粒度

この3つ、やっていませんか?

ツール選定から入るのは、むしろ自然な直感

"動くToBe" とは、3つの条件を満たすToBe

ある食品メーカーの受注配車業務を、数日間でここまで動かしました。

本日の話を、明日から実行できる形でお渡しします

Thank you.ご質問をお寄せください。

システム化できていない業務領域を、
動かし始める60分

システム企画、
最初に何から始めますか?

症状の下には、
3つの構造的な壁があります。

この3つの壁、
こう乗り越えます。

ToBe は AsIs の延長線上にある

ある食品メーカーの
受注配車業務を、
数日間でここまで動かしました。

Thank you.
ご質問をお寄せください。