既存業務をシステム化しよう④
この記事では、業務改善の取り組みとして、ITを導入した事例の実体験を複数回に分けて書いています。この取り組みは現在進行形で進んでいる内容です。私自身の取り組みや振り返り、次に活かしたいことなども含めて書いていきます。今回は、①社内打ち合わせ、②新システムの利用者となるサービスの委託先への伺い、③システム開発ベンダーとの要件定義、についてです。
関連記事
既存業務をシステム化しよう①
既存業務をシステム化しよう②
既存業務をシステム化しよう③
既存業務をシステム化しよう④
既存業務をシステム化しよう⑤
既存業務をシステム化しよう⑥
既存業務をシステム化しよう⑦
（IT用語）既存業務をシステム化しよう
（システムの改修を考える） 既存業務をシステム化しよう
既存業務をシステム化しよう⑧
社内打ち合わせ
社内での打ち合わせはとても重要な時間ですが、毎週一回ベンダー企業と３～４時間話すため、さらに社内打ち合わせの時間を捻出するのも大変でした。
しかし、それでも綿密に話さなければならず、共通認識で大変だとしていた点が、『このIT化プロジェクトは、既存サービスの業務改善であるが、顧客と委託先を巻き込む』ということです。既存サービスなので当然サービス品質は変えられない。委託先もやりなれた方法を変えなければならない。一方でこれまで手作業で何でもできた点は、できなくなることが発生する。そのバランスをどう取って、利用してもらうか。
この点はすでにプレ受入システムが納品された３月現在も、継続されている議論で、顧客・委託先への導入についてはなお話し合いや準備を進めています。
機能要件については、ベンダー企業との打ち合わせで都度宿題として発生しましたが、こちらは逆に既存サービスである点から、方針を決定するだけ、という形になりました。「決める」ことが「やること」みたいなものでしたね。メインユーザーである自社側がシステム化を待ち望んでいたので、ひとつひとつの機能について反対意見などはあっても、全体的に協力的なことは良い点と言えました。
※今、私が当たっている壁でもありますが、業務改善でよく出くわすシーンは、プレイヤーは問題点を把握して改善したくても、ベテラン社員や上司が「これまでのやり方を変えたくない」と思っていること、です。「業務」という内容ゆえに、これまでこのやり方でやってこれたことを理由に「間違いなくこなすこと」を価値観としている場合にはさらにハードルが高まります。「改善」よりも、「間違いなくこなすこと」が人事評価につながってしまうためです。「業務改善のプロ集団になること」が部門の方針になるよう常に働きかけ続けることが必要になります。最近は先輩社員にも働きかけて改善への取り組みを促すようにしています。
利用者となるサービスの委託先との調整
このサービスは一部の工程を委託先に出すため、主要な委託先に事前にIT化の方針を伝えることを行いました。「主要な委託先」ゆえに反対！とは言われないものの、「使いづらくなるのは困る」という意見も出てきました。基本的には発注側ではありますが、人によっては、営業担当には頭を下げ、業務担当には強気、というタイプもおり、良くも悪くも過去の経緯などを含めた委託先とのパワーバランスが見えたりしました。
この時点では「主要な委託先」のみの説明で、全委託先への説明をするタイミングはとれませんでした。一部ではあってもいただいた意見を極力反映させて、最大限使いやすくなるようにしたシステム作りを重視しました。
やはり委託先への導入も慎重に行うという社内方針です。
システム開発ベンダー企業との要件定義
毎週一回、多いときは二回、機能要件を中心に話が進みました。人手で作り上げた業務を長く行っていたために、複雑化されており、議題がなかなか進んでいきません。ただ、ベテランのPMさんだったため、ペースも含めて折り込み済のようでした。頼りになるかたで本当に助けられました。
サーバーの準備や脆弱性診断については、情報システム部にも同席してもらい話を進めました。難しいのは多くの人が関わると責任の所在もばらけてしまい、なかなか決定まで行きつかないということでした。社内体制の弱みが表面化したシーンでもありました。
意外と基幹システムを作ったシステム業者さんとの話はスムーズで、同業者同士で話が早いということはあるのかもしれません。
契約時に話しきれなかった機能で、開発が重いものについての追加費用や納期については双方厳しい商談をすることにもなりました。
個人的にはそうした点も含めて関係性が構築されていくものだと考えています。
ただ・・・要件定義はしんどい笑
時に診断士試験の勉強もピークのころでした。
= to be continued ⇒
この記事が気に入ったらサポートをしてみませんか？