Service 01
基幹システムの段階的刷新
全部を一度に入れ替えない、基幹システム刷新。
受注、出荷、在庫、購買、生産、原価、会計。基幹システムを一括で入れ替えると、一つの変更が別の業務に波及し、プロジェクトは急速に複雑になります。トリコは、周りの業務はそのままに、たとえば「受注入力だけ」を先に新しくし、既存システムとつないで動かします。うまく回ったら、次の業務へ。移行のリスクを抑えながら、貴社の業務に合った基幹システムへ段階的に置き換えていきます。
すでにERPの導入を進めていて、会計や原価計算が合わないといった問題が出ているプロジェクトの立て直しにも対応します。
これまで
すべて既存システム
進行中
「受注」だけを新しくし、残りはそのまま
周りはそのままに、一つずつ。変える範囲を限ることで、影響とリスクを抑えます。
A — New Option
基幹システムに、新しい選択肢を。
基幹システムの刷新を検討するとき、出発点はこれまで「どのパッケージを選ぶか」でした。それは合理的な判断です。業務に合わせて一から作るには費用も期間もかかり、中堅・中小企業にとって現実的な選択肢ではなかったからです。
その前提が、いま変わりつつあります。コードの作成やテストといった工程にAIを活用することで、基幹部分を業務に合わせて作ることが、費用と期間の面で現実的になりました。要件の判断と結果の確認は、これまでどおり専門家が担います。パッケージと並べて、比べていただきたいと考えています。
適材適所という考え方
会計・給与・勤怠
法令で形が決まっており、企業による違いが小さい領域です。
受注・生産・工程・原価
企業ごとに大きく異なり、その違いが競争力の源泉になっている領域です。
すべてを作り直す必要はありません。会計パッケージはそのまま残し、受注から原価までの流れだけを業務に合わせて作る。そうした構成が取れます。
パッケージ導入と、業務に合わせて作る場合の比較
| 観点 | パッケージ導入 | 業務に合わせて作る（AIを活用した開発） |
|---|---|---|
| 適した領域 | 標準化された業務 | 企業固有の業務 |
| 業務適合 | 業務を製品に寄せる | 製品を業務に合わせる |
| 初期費用 | 比較的抑えやすい | 従来は高額。AIの活用で低減 |
| 期間 | 標準機能なら短い。カスタマイズが増えると延びる | 従来は長期。AIの活用で短縮 |
| 実績・安定性 | 多数の導入実績がある | 個別開発のため、実取引での検証で補う |
| 法改正対応 | ベンダーが対応 | 個別対応が必要（会計パッケージは残す構成で回避可） |
| 将来の変更 | アドオン依存だと困難になりやすい | 仕様書が整備され対応しやすい |
| 移行方式 | 一括移行が中心 | 段階移行が可能 |
表のとおり、パッケージには明確な強みがあります。私たちがお伝えしたいのは、基幹部分に限っては、比較する価値が生まれたということです。
ここで生まれる当然の疑問
- 「高くて時間がかかるのでは？」
- 「品質は担保できるのか？」
- 「移行で失敗しないか？」
かつて個別開発が選ばれなかった理由は、この三つに集約されます。順にお答えします。
B — Speed & Cost
専門家が判断し、AIで工程を短くする
トリコの開発では、専門家が要件と判断に責任を持ち、コードの作成やテストといった作業に生成AIを活用します。AIがつくったものが要件どおりに動くかは、専門家が画面と実際の取引で確かめます。AIを使うのは、コードを書かせるためだけではありません。要件の整理からテストまで、実装の前後を含む一連の流れで活用します。
| 工程 | AIを活用する作業 | 専門家が行う判断・確認 |
|---|---|---|
| 要件の整理 | 業務ヒアリングの内容から要件を体系的に整理・文書化 | 会計論点の整理、業務要件の確定、社内の合意形成 |
| 実装計画 | 要件を実装単位に分解し、順序と構成を設計 | システム間の役割分担の決定 |
| 実装 | 計画に基づくコードの生成、API連携 | 実装状況の確認、会計方針との整合の確認 |
| 単体テスト | テストの自動生成・自動実行 | 例外取引（返品・取消・月またぎ等）の観点出し |
| 画面テスト（E2E） | 実際の画面操作による業務フロー単位の検証 | 実取引での受け入れ確認、最終判断 |
- 短期間
人手に頼っていた工程を短くできます。
- 費用の低減
減った工数は、費用の低減につながります。
- 品質の維持
テストを自動で生成し、自動で実行するため、人手では手が回りにくい範囲まで、繰り返し検証できます。
- 仕様書が残る
要件が文書として整備されるため、「作った人にしか分からない」状態になりません。
速さのために品質を犠牲にしているのではありません。テストの自動生成と自動実行、そして専門家による実際の取引での確認と会計面のレビュー。この二つが、速さと品質を同時に成り立たせています。
C — Quality
監査で財務諸表を検証してきた立場から、設計する。
基幹システムが最後に生み出すのは、財務諸表です。私たちは、監査でその財務諸表を検証してきた立場から、システムを設計します。
| 専門性 | 保有資格・経験 | システム設計への反映 |
|---|---|---|
| 会計 | 公認会計士・税理士 | 会計基準に準拠した処理設計 |
| 監査 | 監査法人での実務経験 | 内部統制の組み込み、証跡の確保 |
| IT | システム監査技術者 | 統制が有効に機能するシステム構成 |
内部統制を「後付け」ではなく「組み込み」で
- 職務分掌（申請者と承認者の分離）
- 承認フローと承認証跡の保持
- 変更履歴・操作ログの記録
- 会計基準に準拠した仕訳の自動生成
- 決算・監査対応に必要な資料の出力
適正な財務諸表を作れる基幹システムは、会計・監査・ITのすべてを理解していなければ設計できません。開発会社と会計事務所、それぞれ単独では手が届きにくい領域です。
D — Migration
業務を止めずに、一つずつ置き換える。
基幹システムの刷新でつまずく典型は、ある日を境に全面切り替えする一括移行です。問題が起きれば業務全体が止まり、元に戻す判断も容易ではありません。
トリコは、機能ごとに新しいシステムへ段階的に移し、最後に旧システムを止める方法（ストラングラーフィグ・パターンと呼ばれる移行手法）を前提に設計します。業務に合わせて作るからこそ、移行しやすい単位でシステムを区切ることができます。
段階移行がもたらすもの
- 問題が起きても影響範囲が限定され、業務が止まらない
- 早い段階から効果を実感でき、現場の納得を得ながら進められる
- 実際に使ったうえで次の範囲を検討でき、要件のずれを早期に修正できる
- 初期投資を分散でき、既存の会計パッケージと併存しながら進められる
Menu
主な支援メニュー
For
対象となるお客様
- 基幹システムの老朽化により、刷新を検討している企業
- 独自の業務プロセスを持ち、標準機能との差分に悩んでいる製造業
- 過去にパッケージ導入を検討し、フィット＆ギャップで断念した経験がある企業
- ERP導入中に、会計や原価計算の問題が見えてきた企業
- 内部統制の整備・監査対応の負荷軽減を課題としている企業
小さく始めて、基幹まで。トリコの進め方をご覧ください。
進め方を見るOther Services
他のサービス
何から手をつければよいか分からない、という段階でのご相談を歓迎します。
まずは困りごとを相談する