業務改善とkintoneSIGNPOST 第2回～改善の目的と方向性を決める～
以前にも書いた受注～出荷までを管理する業務フローの業務改善事例の中に SIGNPOSTの要素がどう盛り込まれているかを振り返っています。
前回はkintone化の前に、業務と向き合う意識をSIGNPOSTと見てきました。
前回は下記のような問題と原因を洗い出しました。
今回は業務改善がスタートするところから考えていきます。
問題
・注文書からアプリへの入力ミスや入力漏れ
・出荷指図の出し忘れ
・間違った在庫の引き当て原因
・業務の引継による業務歴の浅さと他業務との兼務により、メイン業務が別にあることで責任感の欠如や確認作業の怠りなどがあった
・複数のアプリで運用していることにより、情報が分散してしまい在庫などの最新情報が反映できていないことがあった
業務の付加価値
業務改善を開始しようと決めたからと言って「さぁアプリを作ろうか」というわけにもいきません。
例えばアプリが複数に分かれていることが原因で情報が分散しているからと言って、じゃあ一つにまとめてしまえばいいかというとそうとも限りません。
もともと複数のアプリにしていた理由やそれを一つにまとめることで新たに生じる問題なども想定した上で今回の改善目的に合わせてアプリ化を考えていきます。
業務の目的そして改善の目的をはっきりと見極めておくことが「アプリ作成が目的」のような、手段と目的を混同しないためにも重要なポイントです。
システム化のコンセプト
洗い出した原因から改善を考えると、本来であれば組織を再編成しメインとして出荷指図業務を行う担当者を選任すべきなのですが、零細企業にとってはなかなかそれはうまくいきません。
組織の再編成ができないので、ミスの防止や早期発見のため「システムでカバーできることはシステムに頼る」、ただし最終的な突合など「人の目が必要なことは人の目で責任をもってやる」
これらを一つのキーポイントとして組み立てていこうと考えました。
このアプリを作成する上でフィールドの構成や他アプリとの連携といったことよりも以下の2点で非常に悩みました。
ワークフローの中で生じうる問題やミスをkintoneでどうカバーするか
kintoneの利点を活かすためどういったワークフローを構築するか
そのために、「ワークフローにkintoneをどう位置付けていくか」ということを考えながらアプリ化の構想を立てていきました。
kintoneはkintone
一般的によく言われる、
「業務をシステムに合わせるのか」
「システムを業務に合わせるのか」
kintoneはこのどちらからも改善アプローチできるのがの強みである一方で、
どちらからアプローチするのが最適かいつも悩みます。
kintoneを効果的に活用するためには、業務改善の目的とkintoneの特性を理解することが最重要です。
kintoneでできることできないことを理解し、ツールや機能の選択をしていきます。
業務のkintone化
最近ようやく「デジタル元年」を迎えた当社では、システム慣れできていない人も多くいる。さらに今回は他部署が絡む業務なので、アプリありきのワークフローを構築するには不安や反対が出る可能性も高く、業務改善がスムーズに進まないかもしれません。
しかし現行のワークフローに合わせてアプリを作成しては根本の改善につながりにくいので、ある程度kintoneに合わせたフローに変えていくことも必要だと考えました。
そこで、「現在行っているワークフローはなるべく維持しながらも、それぞれのプロセスをkintone化することで情報を一元化し、ヒューマンエラーや抜け漏れを防ぐ」
ということを落としどころに、これからアプリを作成していくことを決めました。
今回のkintoneSIGNPOST
今回は
1-05 業務の付加価値
1-07 システム化のコンセプト
0-00 kintoneはkintone
1-06 業務のkintone化
をあげてみました。
kintoneを使って業務改善をしていくと決めたときに大切なポイントだと思います。
業務と改善の目的、ツールの機能と特徴を理解すること。
それらを踏まえて次のステップとしてどうkintone化していくかにつながっていきます。
これまで取り上げた SIGNPOST
つづく・・・
