COLUMN GUIDE
基幹システム刷新の記事一覧
このページはコラムのカテゴリページです。基幹システム刷新は「レガシー刷新」の中でも、検索者の悩みが具体化している小カテゴリです。導入方法、費用感、比較ポイント、失敗しやすい論点を記事群で確認できます。
自分ごと化
課題が自社に当てはまるかを確認できます。
読む順番
まず代表記事で全体像を押さえ、次に中カテゴリで導入方法を確認します。
商談準備
件数、工数、既存システム、費用対効果を相談前に整理できます。
PROBLEMS
このカテゴリで多い相談
PROCESS
記事の読み進め方
SOLUTION MAP
解決策の選び方
AI・自動化
定型処理、検索、下書き、分類、読取などをAIやRPAで削減します。
システム連携
販売管理、在庫管理、会計、CRMなどの二重入力を減らします。
BPO・運用設計
人が確認すべき例外処理や繁忙期対応を外部化・標準化します。
PoC・投資判断
効果、費用、期間、リスクを小さく検証してから本番化します。
ARTICLES
関連する記事
システム開発
富士通メインフレーム撤退と基幹システム刷新2026｜2030年度終了・COBOL移行の進め方と費用
この記事は、富士通メインフレームやレガシーCOBOL基幹を抱える中堅・大企業の経営層・情シス。本記事は、販売終息2030年度・保守2035年度末という動かせない期限を起点に、移行方式の比較、費用の考え方、進め方、人材手当てを整理し、刷新の意思決定を支援する。
基幹システム刷新
基幹システム刷新ガイド｜販売管理・在庫・会計を止めずに移行する進め方
基幹システム刷新は、販売管理、在庫、会計、受発注など止められない業務を扱うため、現行調査、データ移行、連携、並行稼働、段階移行の設計が重要です。
システム開発
システム保守費用の相場【2026年版】｜高すぎる3つのサイン・内訳分解・値上げ通知への対応と刷新判断
システム保守費用の検算には「初期開発費の15〜25%/年」という経験則が使えるが、これはIPAの公式統計ではない。本稿では経験則の正しい使い方に加え、保守費が高すぎる3つのサイン、内訳の分解方法、値上げ通知への対応手順、ブラックボックス化・ベンダーロックインの構造、保守継続か刷新かの判断フローを、経産省DXレポート・JUAS企業IT動向調査など一次資料に基づいて解説する。
システム開発
オンプレミスからクラウド移行｜TCO比較より運用責任とリスクを先に見る
クラウド移行は、5年TCOが何割下がるかを先に約束するものではない。対象システム、可用性、セキュリティ、バックアップ、運用体制、ネットワーク、ライセンス、レガシー刷新の有無を整理してから判断する必要がある。
業種別DX
卸売業のEDIモダナイゼーション｜INS終了対応より取引先別の移行設計が重要
卸売業のEDIモダナイゼーションは、通信方式を置き換えるだけでは不十分である。取引先ごとの接続方式、流通BMS、Web-EDI、ERP連携、障害時の代替手順、受発注・出荷・請求データの責任分界を整理する必要がある。
業界別DX
DX銘柄・DX認定の準備｜応募テクニックより経営KPIと実装実績を整える
DX銘柄やDX認定は、申請書だけを整える制度対応ではない。経営ビジョン、DX戦略、KPI、ガバナンス、サイバーセキュリティ、データ基盤、レガシー刷新、AI活用の実装実績を継続的に説明できる状態にする必要がある。
システム開発
金融業 基幹システム刷新ロードマップ｜地銀・信金・保険代理店の段階移行
地銀・信金・第二地銀・保険代理店向けに、レガシーCOBOL・メインフレームからの段階的な基幹システム刷新ロードマップを解説。金融庁ガイドライン対応、リスク管理、5年TCOを網羅する。
システム開発
IT運用の外注と内製化｜TCO試算より責任分界と人材設計を先に決める
IT運用は、外注か内製かの二択ではない。経営判断、業務知識、権限、設計、監視、復旧、開発保守を分け、社内に残すべき判断と外部に任せる作業を設計する必要がある。
システム開発
経営者向け：保守費を下げるために保守先を変更する前に見る引き継ぎ条件
保守費が高いから保守先を変える、という判断は自然です。ただし、月額だけで比較すると、引き継ぎ不能な仕様、古い環境、障害履歴、権限、監視、バックアップ、契約終了条件が後から出てきて、削減したはずの保守費が調査費と追加改修費に変わります。この記事では、保守費を下げるために既存ベンダーを変更する前に確認すべき引き継ぎ条件、費用内訳、失敗パターン、90日移管計画を整理します。