第4回:IT企画人材不足の正体―「いない」のではなく「存在できなかった」 //「IT企画人材が足りない」は常套句になりました。しかし結論から言えば、不足しているのではなく、存在できなかったのです。多くの企業でIT企画は、要件定義の取りまとめやベンダー調整、プロジェクト推進に押し込められ、「何をやるか」を決める仕事として扱われてきませんでした。ERP再定義の文脈では、IT企画の本質は、どんな素活動を記録すべきか/何を企業資源として管理するか/どこまでを基幹にするかを定義することにあります。にもかかわらず、パッケージ前提・提案前提・標準前提の構造の中で「決めてはいけない仕事」にされてきた。だから育たなかった。第4回では、IT企画を“要件定義屋”にしてしまった構造を解き、企画人材が生まれるために経営が設計すべき条件を提示します。
第3回:情シスに必要な人材像の再定義―「ITが分かる人」ではもう足りません //「クラウドに詳しい」「セキュリティに強い」といったスキル要件は重要ですが、それだけではERPは成立しません。ERPを再定義したとき、情シスに求められる中心能力は、IT知識よりも先に、企業活動を“業務として説明できる力”になります。どんな素活動が存在し、何がリソースとして動き、どこで記録されるべきか―これを言語化できなければ、設計も投資判断もブレます。第3回では、情シスの本質が「ITを止めないこと」ではなく「企業活動の記録を途切れさせないこと」にあると整理したうえで、現場・経営・技術の間をつなぐ“翻訳者”としての情シス人材像についてお話しします。
第2回:情シスの役割再定義―「守る仕事」と「変える仕事」を取り違えない //DXが進まないとき、情シスが槍玉に上がることがあります。一方で情シス側にも「無理な要求ばかり」「現場が分かっていない」という不満が溜まります。しかしこの対立は感情論ではなく、役割が定義されていないことが原因です。ERP再定義の立場から見ると、情シスが守るべきものはサーバーでもネットワークでもパッケージでもなく、「企業活動の記録が途切れない状態」そのものだと分かります。止めてはならないのは基幹(記録)であり、情報(利活用)は試して作り替えてよい。第2回では、守る仕事と変える仕事を取り違えないための判断軸を示し、情シスが変革のブレーキではなく、変革を成立させる前提条件になり得ることをお話しします。
第1回:基幹システムとは何か―ERPを再定義すると、情報システムの意味が変わる //ERPを「企業資源計画」として捉え直すと、基幹システムと情報システムの意味は根本から変わります。会計だから基幹、販売管理だから基幹、という“機能名ベース”の理解ではなく、企業活動の最小単位である「素活動」をリアルタイムで記録し続ける仕組みこそが基幹である、という再定義です。第1 回は「止められないシステムが増え続ける」日本企業の構造問題を整理し、役割分離がなぜDXの前提条件になるのかをお話ししていいます。
Weekly:業務改革に「現場精通」は本当に必要なのか― あるワークショップで起きた静かな違和感 //「現場に精通していないと、業務改革はできない」 本当にそうでしょうか。 業務改革を ・現場理解の延長と考えるのか ・経営戦略に基づく“設計行為”と考えるのか この違いが、改革が進む組織と、改善止まりの組織を分けています。 現場は設計者ではない。 設計を検証する存在だ。 あるワークショップで起きた違和感の正体を、言語化しました。
第5回:業務モデリングが根付かない最大の理由は「決めない組織」にある ―「業務モデリング」が日本で活用されない理由⑤(総括) //業務モデリングが根付かない最大の理由は、技術でも手法でもありません。 それは、業務を「決める」覚悟を、組織が持っていないこと。 業務モデリングとは、選び、捨て、固定する行為です。 つまり、意思決定そのもの。 決めないまま、調整だけを続ける組織に、DXも、AI活用も、業務改革も根付きません。 Daily Blog最終回、「業務モデリング」が日本で活用されない本当の理由についてまとめます。
第4回:「何を決めるのか」が曖昧なまま業務モデリングは始められる ―「業務モデリング」が日本で活用されない理由④ //業務モデリングが迷走する理由は、意外と単純です。 それは、「何を決めるためのモデリングなのか」が決まっていないこと。 可視化する。整理する。 ―その先に、どんな意思決定をしたいのでしょうか。 目的なきモデリングは、必ず粒度が揃わず、議論が発散します。 Daily Blog 第4回では、業務モデリングが迷走する構造を整理しました。
第3回:なぜ業務モデリングは「専門家の仕事」になってしまうのか―「業務モデリング」が日本で活用されない理由③ //なぜ業務モデリングは、「専門家の仕事」になってしまうのか。 多くの現場で、業務モデルはEA担当やコンサルが作り、現場は「説明を受ける側」になっています。しかし業務モデリングは、描くことが価値なのではなく合意して決めることが価値です。 現場が関わらないモデルは、どれだけ正しくても、使われません。 Daily Blog 第3回では、業務モデリングが専門家化してしまう構造を整理しました。