2017年9月28日(木)、「ドリーム・アーツ主催 第2回Sm@rtDB勉強会」を、恵比寿ガーデンプレイスSpace6にて開催いたしました。
この勉強会は「お客さまにSm@rtDBをよりご活用いただきたい!」という思いで立ち上げました。勉強会に参加いただくことで、以下のようなメリットを実感いただければと考えています。
- サービス利用に関する不安や疑問を解消し、具体的な解決策を得られる
- サービス利用に関する不安や疑問を解消し、具体的な解決策を得られる
- 他社のリアルな活用事例について情報を得、気になった箇所を集中的に聞くことができる
- 同じような悩みを抱える他のユーザー企業のご担当社さま同士が交流できる
- サービス提供企業(ドリーム・アーツ)と直接会話でき、要望を伝えられる
第2回目の今回は、はじめに2社のユーザーさまから「Sm@rtDB」の活用事例をご紹介いただき、続けてドリーム・アーツから現在進行中の「Sm@rtDB」事例をご紹介。さらに「Sm@rtDB」のプロダクトオーナーから、最新機能を紹介させていただきました。その後は「Sm@rtDB」の課題・お悩みについてグループでディスカッション。最後は場所を変えて懇親会を行いました。大盛況で終了した「Sm@rtDB」勉強会の様子をレポートいたします。
ユーザー事例セッションその1
「部内Sm@rtDB利活用勉強会実施について」
ユーザー企業Aさま(利用CL数:Sm@rtDB 4,600CL、INSUITE 4,600CL)
私どもは持続的な成長を実現していくために、グループ情報基盤の見直しに至り、このたび「INSUITE」と「Sm@rtDB」を組み合わせた新しい情報基盤をグループ全体共通で使い始めることになりました。旧システムからの移行後、「Sm@rtDB」が他にどのような業務に利用できるのか全くわからない状況だったので、自分たちで勉強会を開催しました。今回はその勉強会のなかで作成した「システム化相談シート」を事例としてご紹介します。
ユーザー部門から業務システムの相談を受け付ける際に、今まではエクセルファイルに記入し、印刷・捺印して回覧していましたが、これをシステム化することにしました。その結果、複数あった課題を以下のように改善することができました。
- 承認に時間がかかっていたのを、ワークフロー(電子承認)により時間短縮を実現した
- 同じ案件がエクセルと紙面の二重管理となっていたのを、ひとつのバインダで一括管理が可能になった
- ユーザー部門が作成中の内容を担当者間で共有するために、メールの送受信が発生していたのを、IT推進部にドラフト公開し、作成中でも共有可能とした
- 提出されたシートや過去の情報の検索性が乏しかったのを、バインダのビュー定義を工夫することで、情報の検索性を高めた
- 一覧性に乏しく捺印が確認できず、各案件の進捗状況の把握も困難だったが、ワークフローの進捗状況が一目でわかるよう一覧表示項目を追加し、簡単に把握できるようになった
また、この電子化により得られた効果は以下のとおりです。
- ユーザー部門として
- 自分の部からの申請内容を一覧で確認できるため、部内で担当が異なっても情報共有が可能になった
- IT推進部として
- 一覧性が向上し、どの部からの案件が多いか、だれがどの案件を担当しているかを把握しやすくなった
- ユーザー部内で承認を得なくても概要を把握することが可能となり、サポートしやすくなった
- 管理職が全案件を把握することで、IT推進部内の情報共有が可能になり、チームをまたいでシステム化手段を検討できるようになった
今後は、紙文化に慣れていたユーザー部門に、早く「電子承認」に慣れてもらうことが大事なポイントと感じています。 勉強会を行った若手中心のメンバー6名のうち3名が新入社員でしたが、参加者からは「想像以上に簡単に作成できることがわかった」「新入社員の頑張りと成長がとても大きかった」という声があり、勉強会の開催にはとても大きな効果があったと思います。 とは言え、まだ社内利活用に向けての課題は残っています。「開発者育成」「バインダの属人化防止」「対象業務の基準作成」などは引き続き検討し、取り組んでいこうと思います。
ユーザー事例セッションその2
「Sm@rtDB/INSUITE グループでの使い方」
ユーザー企業Bさま(利用CL数:SDB 3,600CL、ISE 3,600CL)
私どもの「Sm@rtDB」導入の経緯ですが、当初はNotes移行が目的でした。社内の情報も発信できるポータル機能も必須ということで、「INSUITE」と「Sm@rtDB」を採用しました。680個のNotes DBから、約400バインダに断捨離した後に「Sm@rtDB」へ移行し、現在は584の“活きたバインダ”を運用しています。 私どもでは「Sm@rtDB」導入当時から、バインダの開発と運用について一貫した方針をとっています。
開発方針
- 標準機能の範囲で開発(アドオンでの対応は極力行わない)
- 現場業務の改善リクエストや効率化ニーズが多いので、対応は速やかに!
- 用途や範囲をシンプルかつ明確に! 管理業務ではなくフロント業務に特化させる
- バインダは、グループウェアの一機能として位置付け、必要以上に作り込まない
- できるだけ既存の設計を流用/応用する
運用方針
- 開発権限はグループ各社には付与せず、システム子会社にて一括管理⇒効率的(Notesでの失敗を反省)
- 開発・運用は現状2名体制(業務設計:1名/バインダ作成:1名)
- 数パターンの基本・標準テンプレートをシステム子会社で開発し、グループ各社の共通業務部署に展開
- シンプルな基本機能バインダなら、開発期間は努力目標“一週間”⇒格安料金で作れる
- “できません”は禁句!! 極力代替案を提案
この方針により、現場担当者は、アプリ開発やツール操作に習熟する必要がありません。
- “自分の仕事をどうすれば効率化できるか! に集中できる”
- “バインダの制限に従うことで、実は仕事の単一化・標準化につながる”
このように細かく開発方針や運用方針を決めてバインダを提供することで、グループ全体で「INSUITE」 &「 Sm@rtDB」は定着し、満足度が非常に高い状況となりました。
その他、具体的な事例として、「申し送り案件管理簿」についてご紹介いただきました。
グループ全体で「Sm@rtDB」が使われる理由は、現場・業務に入り込んでいるからだと思っています。まず作ってみて、見せてみる。「Sm@rtDB」開発は“アジャイル+UI/UXそのもの”です。
営業事例「商品開発管理の電子化」
アカウントエグゼクティブグループ ゼネラルマネージャー 増本 大介
ドリーム・アーツの営業からは、商品開発管理の電子化にご利用いただいている事例をご紹介いたします。標準機能中心でご利用いただいているので、参考にしやすいかと思います。 このお客さまの抱えている課題は以下のようになっており、紙で申請している工程管理を電子化することとなりました。
課題
- 工程はExcelで管理し、会議で進捗管理を行っているため、進捗が見えない
- 工程完了の申請は紙で行っているため、承認に時間がかかる
- 申請漏れも発生し、マネジメントに苦慮
解決の方向性
- 工程管理と紙での申請を電子化
- 拡張性を担保するためアドオン開発は行わず、製品の標準機能でつくりあげる
ユーザーから業務概要をヒアリングしたあと、画面を見せながらシステム化するという進めかたを理解してもらった。 実際に使った標準機能は以下のとおりです。
- バインダ機能
- フォーム定義・ビュー定義、一括処理、更新履歴、フィルタ定義、通知定義、部品書式、部品制御、連携定義、ジョブ定義、帳票定義、
- プロセス機能
- プロセス定義、イベントハンドラ、スキップ(差し戻し・取り戻し)、コメント依頼、代行者設定
- 使ってない機能
- 子文書、サブプロセス、「知話輪」連携
「Sm@rtDB」によるシステム化の効果を以下にあげます。
- 申請・承認プロセスがWeb上で完結したことにより、紙媒体での持ち回りがなくなり効率化が進んだ
- 申請状況の見える化と進捗サポートにより、未提出書類に対しては自動的にアラームを通知(現状は電話やメールのやりとり)
- 関連資料などを一元管理でき、情報資産としてとして活用
※利用しながら改善・変更が可能な柔軟性の高い基盤を採用
「Sm@rtDB Ver4.0」機能紹介
「Sm@rtDB」 プロダクトオーナー 鳥羽 希
プロダクトオーナーである私からは、「Sm@rtDB」の最新バージョン4.0の機能紹介をさせていただきます。 特にお客さまからご要望いただいた機能を中心にご紹介いたします。
- 自動採番部品を拡張
左の文字列に評価式・条件が保持でき、複数定義ができるように - 添付ファイルの一括ダウンロード
CSVファイル出力時に添付されているファイルも一括でダウンロード可能に - バインダ定義の復元
バインダ定義を元に戻したい場合、画面操作で対応できるように。フォーム更新履歴の確認や障害調査などにも活用可能 - 既読文書を未読に戻さないオプションを追加
更新があれば、既読者のステータスも同時に「未読」になる仕様に対し、バインダの使いかたに合わせ、「未読に戻さない」オプションを追加 - 見出しの更新を可能に
プロセスのタイトルである「見出し」に関して、ワークフローの用途に合わせ、更新可能とするオプションを追加 - 物理削除コマンドの改善
文書の物理削除日時の範囲が指定できるように - ワークフロー滞留の見える化 (本バージョンの目玉機能)
ワークフローの実施履歴・プロセス毎・アクティビティ毎にかかっている時間を見える化し、どこがボトルネックなのかを確認できるように
※プロダクトサイトの「Sm@rtDB」ラーニングにも記事が掲載されておりますので、ぜひご覧ください。
https://hibiki.dreamarts.co.jp/smartdb/learning/le170731/ - 「知話輪」連携の強化→まとめ通知機能の追加
承認依頼の多いエグゼクティブには都度承認依頼を通知せず、決まった時間に通知をすることで承認作業をまとめて行うことができるように
※プロダクトサイトの「Sm@rtDB」ラーニングにも記事が掲載されておりますので、ぜひご覧ください。
https://hibiki.dreamarts.co.jp/smartdb/learning/le170809/
今後の方向性ですが、引き続き「働き方改革」への提案を継続し、また、標準機能としてあるべき柔軟性の拡充も並行して検討していきます。「Sm@rtDB」はお客さまの声を取り入れてどんどん改善していきます。積極的にご意見をお寄せください!
課題ディスカッション
最後に皆さま日々運用されているなかでお悩み、お困りごとがあると思いますので、ディスカッションしていきたいと思います。
-
お悩み1
自分たちでバインダ作成する際と、外注する際の判断ラインはどこに置いていますか? -
お悩み1へのお答え ユーザー企業さま①
あらかじめ基準ルールを設けることが重要。作り込まない。アドオンはやらないと決めています。外注に出さなければならないシステムは作らない。そこで切り分けをしています。お悩み1へのお答え ユーザー企業さま②
「Sm@rtDB」はアジャイルでまずは作ってみてすぐ修正して、というサイクルが回しやすい製品ということもあり、ユーザーに権限を渡しています。ただしプロセスに関しては、しっかりと理解している人にのみ権限を渡しています。
-
お悩み2
作り込むor作り込まないの線引きがスムーズにできません。標準機能でどこまでやるべきでしょうか。 -
お悩み2へのお答え ユーザー企業さま
基準として、アドオンは「導入時」だけと決めています。ユーザーが最初の段階で「どうしても」と言うもののみに絞ります。 その後、「Sm@rtDB」に慣れたあとは、できないものはできないとはっきり言って、納得できないのであれば他の製品を探していただいて結構です、というスタンスにしています。
-
お悩み3
申請書の入り口はどう工夫していますか?(Sm@rtDBログイン後にたくさんある帳票をどう使っていただくのか)目的別や部門別? -
お悩み3へのお答え ユーザー企業さま
申請系のバインダはポータルトップページにボタンを設けています。(実際の画面を見せていただく。)クリックするとスマートページが開き、そのなかに申請書へのリンクボタンと、申請内容の説明や簡易マニュアルなどを置いています。