ITベンダーが提案するDX（デジタルトランスフォーメーション）を見極める為にする事

DX導入が増えるにつれて増える失敗事例の数々から学ぶ

ここ数年、ITに関わるテクノロジーの発達で、AIだのクラウドだのAWSだのと、様々なビジネスソリューションが提供され、導入も増えてきた。

経営者も、取引先や、または、融資を受けている銀行の担当者等から、「お宅のDX推進は進んでいますか？」等と、何度も聞かされ、何となく、周りが進んでいるような印象も受け、周りから遅れてしまい、取引に行き詰まる機会も出て来るのはないか・・・と焦ったりしている事もあるだろう。

実際FAXやら、電話やらで発注、受注で人手が掛かっていた分野でも、WEB-EDIやら、流通BMSやらといったサービスで、ある程度自動化された側面がある物もあるだろう。

賢く導入されたDX（デジタルトランスフォーメーション）での、業務改革は、何人もの人手が必要だったものが、いつの間にか一人、二人で済むレベル業務量に落ち着いている物もある。

しかし、大炎上していたDX案件の改善に関わる事が多い筆者は、DX推進に伴う数々のトラブル解決で関わっていく中で、大きなトラブルに遭遇していた企業には、共通点があると感じた。

ITに関わる分野は物凄く広い為、分からないから担当者に丸投げもあると思うが、中小企業が抱えるエンジニアも一人、二人である場合も多く、少数のエンジニアが、全ての分野を把握しきって、進める事も現実的では無い為、分からないなりにも、エンジニアと対話が可能な共通に行える認識合わせが必要だ。

中小企業では、これをやっていない企業が意外と多く、ベンダーに言われるがまま、便利になりますよと言われて導入したものの、受注は便利になったが、請求業務がFITしておらず、営業部署は楽になったが、経理は複雑になって、オペレーションに時間がかかるようになったというような事が起きては元も子もない。

大企業が導入しているみたいな計画までは必要と考えていなくても、作業単位では、工数算出で（フィット・ギャップ）位は、経営者側でも共有しておく事で、導入後のトラブル防止や、改善に繋がらない意味のないIT化が未然に防止出来る。

この部分は物凄く重要で、ここで見落とした業務は、仕様変更を余儀なくされる案件に繋がり、時間が掛かり煩わしいと省略したくなるが、経営者が各業務の責任者と、システムの責任者も交えた確認を行う事で、ギャップに伴う改善失敗は回避出来る。

経営者主催で開催する事で、業務責任者が、自身の都合で離席が頻発し、確認漏れが多発するといった事も避けられる筈だ。

現場丸投げにしている場合、経営者が見えていない社内の派閥関係等に伴う、きちんと確認する時間が取れなかったといった理由でヒアリング漏れが増えるお事も抑えられるだろう。（みずほ銀行が良い例）

一方で全体主義的にもならないように、注意が必要だ。変化を嫌う担当者がいた場合、計画の段階で頓挫している現場も多い。

仕様に重大な欠陥がある場合を除き、開発着手が進んだ場合の仕様変更は、絶対に行わない事が重要である。

ITベンダーは、開発工数の積算にて見積もりを行う為、見積もり金額の増額を予定していない仕様変更を依頼する事は、その分の工数が何かで端折られる事を覚悟する必要がある。（IT営業担当の表向きの言葉を信用している人はいないと思うが。。）

これを繰り返し行った企業が、EDIの請求システムがまるで機能しないものと成り、請求業務すら止まってしまう事例を取り扱った事もあるが、経営者も担当者に丸投げしており、また、担当者もITベンダーに丸投げしており、責任を免れたい担当者の隠蔽やら、とてつもなくカオスな現場であった。

追加での継続開発を改めて行う事での仕様変更を行う分には良いが、ITベンダー側も、見積もった期間でIT派遣エンジニアを集めている為、オムライスを作っている最中に、とんかつカレーに変更みたいな状態を招く事をすると、トラブルが起きた際の過失割合的にも不利になる為、開発中の仕様変更だけは避けたい所だ。

根回しや忖度を重んじる日本企業の場合、内部の人間だけで進捗管理と評価を行うと、問題を隠蔽されたまま改善されたかのような評価もされてしまう現場も多い。

当たり前だが、導入したシステム自体が、こちらの都合に合わせて忖度はしてくれない為、外部の顧問にも進捗会議や、フィットギャップには立ち会って貰えた方が、信頼性の高いDX推進に繋がるであろう。