スプレッドシートを使ってスマートなワークフローを作ろう（２）

先日の記事でスプレッドシートと親子リストを使って、申請者情報を自動表示する方法をご紹介しました。
今回は、同じくスプレッドシートを使って、社員番号から所属部署やユーザー名・メールアドレスを自動的に表示させる方法をご紹介いたします。

◯スプレッドシートを準備する

今回は「親子テキスト」を使います。親子テキストとは親項目がテキストになっており、入力された内容に該当するものがあった場合は、子項目以下を表示するというものです。前回ご紹介したオーダーシートは1列目にメールアドレスが入力されていましたが、今回は親項目が社員番号になります。そこで、オーダーシートのデータを参照して、列を入れ替えたスプレッドシートを別に用意します。

◯IMPORTRANGE関数を使う

オーダーシートのデータはグループキャッシュに使用するため、列の入れ替えはできません。そこで、IMPORTRANGE関数を使います。IMPORTRANGE関数は別のシートの情報を参照し、対象データを表示するものです。
IMPORTRANGE
新規のスプレッドシートを作成します。
シート1のA1にIMPORTRANGE関数を入力します。第一引数にスプレッドシートのURL、第二引数にシート名・列を入力します。

初回のみ、「#REF!」になりますが、メッセージの「アクセスを許可」をクリックするとデータが表示されます。

◯QUERY関数を使う

親子テキストの親項目は社員番号ですので、マスターとして使うにはA列に社員番号が無いといけません。そこで、列の入れ替えのためにQUERY関数を使います。QUERY関数は参照元のデータを条件に見合った形で表示します。
QUERY
上記のシートに新しいシートを追加します。
シート2のA1にQUERY関数を入力します。第一引数に参照元のデータ(シート名・列）、第二引数にクエリ文を入力します。クエリ分は特に条件は無いので、Selectに続いて、表示したい列名を順に入力します。D列＝社員番号が先頭に、他は元の並びで表示してほしいので、「D,A,B,C,E,F」となります。

◯マスターデータは１シート目を参照する

1シート目がIMPORTRANGEでデータ出力されたシート、2シート目がQUERYでデータ出力されたシートになっています。親子テキストのマスターデータは1シート目を参照しますので、QUERYでデータ出力された2シート目を1シート目に移動します。

◯親子テキストのマスターデータにスプレッドシートを使う

タイプが「親子テキスト」の入力フォームを作成します。選択し設定で「スプレッドシートで定義」を選択し、スプレッドシートを選択します。今回は「ログインユーザーでフィルター」のチェックはオフのままです。

これにより社員番号を入力し、一致するものがあれば、社員情報を表示します。参照元のデータはオーダーシートなので、社員番号用のスプレッドシートはメンテナンスが不要です。

※最初の画像は入力フォーム用のドキュメントを作成しています。

いかがでしたでしょうか。このように社員番号等からデータを参照する場合はこの方法を使ってみてください。

8:00:00  Web Marketing  
G Suite, データ連携, ワークフロー

紙やExcel帳票をワークフローシステムへスムーズに移行するためのポイント

最近、稟議書、経費精算書、休暇申請等の様々な帳票を紙やExcelで作成し、社内ワークフローを回しているものの、内部統制、作業効率、テレワーク等を考慮し、ワークフローシステムへの移行を検討され始めている企業が増えてきています。

• 参考：申請・承認業務（ワークフロー）の 実態とワークフロー導入メリット

今回、そのような紙・Excel帳票からワークフローシステムへの移行を検討されている企業様が予め注意しておくべき点についてご説明したいと思います。

ワークフローシステムへ移行する際に陥りがちなケース

紙・Excel帳票をワークフローシステムへ移行する際に焦ってしまうことで陥りがちなケースをご紹介します。

• ワークフローシステムの評価・検証で簡単な帳票レイアウトを利用する
• 良くありがちなのが、簡単そうでシンプルな帳票から取り組もうとするケースです。例えば、項目も少なく承認ルートもシンプルな「休日申請」をベースにワークフローシステムの導入評価を行ったとします。その時点では何も問題なくスムーズに検証も終わり、本導入後に項目が多く複雑な承認ルートがある「稟議申請」を作ろうとしたところ、ワークフローシステムの制限が分かり、実現が困難であることが判明してしまいますが、運用開始後のため戻れません。
• 既存の帳票をそのままシステム上に載せようとする
• 紙やExcel帳票を使ったワークフローでは入力欄の他、申請・承認ルートも自由に変更可能です。特に非常に複雑な申請・承認ルートとなっている場合が多く見受けられます。そのような承認ルートをそのままワークフローシステム上で再現しようとすると、設定が複雑となり、メンテナンス負荷も上がってしまいがちです。
• いきなり全社展開する
• 焦って全社展開に踏み切ってしまうと、社内からの問い合わせや部署間の調整に時間がかかってしまい、その結果、スムーズな社内展開ができなくなります。

上記のような評価・移行の進め方のままでは、何かと障害も多く、すんなり移行できないのではないかと思います。

スムーズに移行作業を進めるためのポイント

数多くのお客様の移行を支援してきた弊社の観点から、以下に移行作業を進めるためのポイントをご説明します。

1. 最もよく使う、または複雑な帳票を検証対象として選定し、評価検証に取り掛かる
できるだけ利用頻度が高いものか、複雑なものをベースに、ワークフローシステムの評価・検証を行うようにします。これにより、ワークフローシステムの制限も早い段階で明確になり、ベンダーからの改善策や回避方法などの情報も得やすく、かつ、対策のための準備時間も確保しやすくなります。

2. 利用中の帳票をそのまま移行しようとせず、項目および承認ルートを整理してからシステムへ導入する
紙・Excel帳票は何かと複雑なレイアウトになりがちですが、その帳票をそのままワークフローシステム上で実現しようとすると大変な労力が掛かってしまうだけでなく、ユーザに不親切な分かりづらい入力画面になってしまう恐れがあります。
そのため、以下の観点で既存の帳票について見直してみましょう。

• 帳票レイアウトを変更して良いか？
• 紙・Excel帳票と全く同じレイアウトでなくても問題ない場合、ワークフローシステムに適したレイアウトに変更することを検討します。
• 1帳票内で異なる入力内容・承認ルートが混じっていないか？
• 別帳票に分割することができないか検討します。
• 記入頻度が低い項目はあるか？
• 廃止するか、入力フォーム項目をフリーテキスト欄に書かせるようにします。
• 申請・承認ルートを整理できないか？
• 複雑な分岐ルート等を見直し、代替可能なルートに置き換えます。

3. 運用フローの検証は少人数のメンバーから開始し、PDCAで改善する
上記1,２で作成したワークフローがきちんと運用に乗るかどうかについては、社内での検証・評価が必要です。そのための少数精鋭チームを編成し、しっかりPDCAサイクルを回して改善していきましょう。

いかがだったでしょうか。ある意味、当たり前のことかもしれませんが、まずは現状の整理から開始するほうが遠回りのようで実は近道だったりします。
なお、弊社が提供しているクラウド型ワークフローGluegent Flowでは帳票デザインをHTMLエディタやGoogleドキュメント(G Suite版）を利用することで紙帳票と同等のレイアウトが再現できます。
また、利用者も1名からご契約できますので、最初は評価検証用ユーザ分で少人数から契約し、評価検証が終わり全社展開の前に全社員分を契約するように柔軟にご利用することができます。
紙やExcel帳票のワークフローから1歩前へ進みたい情報システム部の方はぜひお問い合わせください。

お問合せはこちらからどうぞ

7:00:00  Web Marketing  
クラウドへの移行, ワークフロー

IDaaSとは、何か？ (2) 〜IDの一元的な保存について考える〜

前回の記事では、[IDaaSとは、何か(1)」として、文字通り、どういうものを表すものなのかを探りました。今回からは、IDaaSが備える機能について、より掘り下げて見てみます。前回、IDaaSには、以下の機能があるとご紹介しました。

• 保存：Identityに関する情報を保存・管理する。
• 認証：利用者が誰なのかを管理する。
• 認可：利用者が許可されているサービスやリソースを管理する。
• プロビジョニング: 利用者が許可されているサービスに対して、アカウントを管理する。

今回は「保存」です。

「何を」保存するのか

機能そのものを見る前に、まず、その対象となる「Identityに関する情報」とは、何かをはっきりさせておきます。実例を挙げてみましょう。一般的な情報としては、

• 氏名
• メールアドレス
• 所属部署
• 所属グループ
• 役職

のような情報です。更にIDaaSでは、後に考察する「認証」や「認可」の機能で参照される以下のような情報も持っています。

• あるサービスのアカウントID
• あるサービスでの組織

例えば、G Suiteであれば、アカウントIDは、メールアドレスです。ただし、G Suiteで利用しているドメインのメールアドレスということになります。必ずしもIDaaSが保持するメインのメールアドレスと同一とは限りません。組織は、G Suite側で用意されている組織のどれに所属しているかを示すことになります。
サービスによっては、より付加的な情報を利用できる場合があります。G Suiteであれば、電話番号や予備のメールアドレスなどがあります。
これらが、「Identityに関する情報」と言えるでしょう。ここで挙げた例以外にも多くの情報がありますが、全部を網羅することが目的ではないので割愛します。

「保存」とは何か。一元管理の重要性

では、これらの情報を「保存」するというのはどういうことでしょうか。より分かりやすく表現するならば、保存してあるだけでなく、

Identityに関する情報を一元的に保存、管理し、問い合わせに対して、回答する

ということになります。Identityに関する情報が、一元的に保持されていない場合、情報の参照や更新が非常に煩雑になります。例えば、氏名、所属部署は人事部のDBに保持されていて、氏名、メールアドレスは、情シスが管理してるというようなケースです。結婚により氏名が変わったり、転籍により別ドメインのメールアドレスを追加するということはよくあります。
こういうイベントが発生した時、それぞれの保存場所の更新が必要になります。Identityに関する情報は、すべての情報システムに必須な情報であるため、それぞれで持っていることが往々にしてあります。ただ、情報の更新漏れがあった場合には、思わぬセキュリティリスクとなります。退職した社員のメールアドレスが無効になっていなくて、退職後もMLのメールが送信されていたというような事は起こり得ます。
しかし、一元的に管理されていて、その情報を必要としているサービスの側からの問い合わせに応える仕組みがあれば、一箇所を変えれば良いだけです。更新漏れの心配はありません。情報の更新タイミングも同一ですので、まだこっちのシステムには反映されてないというような不整合も起こりません。Identity情報は、みんなが必要とする情報ですが、分散して保存されているべきではなく、一箇所で管理されているべきです。

今、情報が分散している場合

情報が一元管理されていることの重要性が理解できました。では、今運用中の仕組みで、Identityに関する情報が分散していて、これを取りやめることが出来ない場合は、どうしたら良いのでしょうか。
理想としては、既存の情報も含めて、全ての情報を一箇所に集めて、既存システムはこれを参照するようにするのが良いでしょう。ただ、既存システムの回収が困難な場合も多いです。そのような場合でも、様々な手法で、「一元的に参照できる」ようにすることは可能です。
例えば、弊社が提供するGluegent Gateでは、既存のADを源泉として、情報を同期するオプションを提供しています。あるいは、CSVで毎日出力される情報を同期するような方法もとれます。本当に必要なのは、IDaaSに情報を問い合わせれば、常に正しいIdentity情報が得られるということです。統合できない情報が外部にあったとしても、それと連携が自動化されていれば、IDaaSとしての役割は、十分です。

一元的に保存管理されている情報は何に使われるのか

今回は、どのような情報が、どのように保存されるのかを見てみました。では、保存されている情報は何のために使われるのでしょうか。次回は、その利用のされ方を見てみたいと思います。

 

8:30:00  Web Marketing  
Active Directory, G Suite, IDaaS, IDM, アクセス制御

【GluegentFlow管理者UI更新】7月のまとめ

7月のGluegentシリーズのリリースや、各種情報のまとめです。

Gluegent Flow の管理者画面を更新しました

今年初頭から、お知らせしていたGluegent Flowの管理者画面の刷新を行いました。
一般ユーザ向け画面への大きな変更はありません。

詳細は、以下をご覧ください。マニュアルへのリンクもこちらに。

Gluegent Flowの画面が新しくなります

アイペット損害保険株式会社 様の事例をご紹介しました

Gluegent Flowをご利用いただいている、アイペット損害保険株式会社 様の導入と今後の展望について、ご紹介いただきました。

導入事例:アイペット損害保険株式会社

今後も、導入事例を増やしていきますので、ご期待ください。

8:30:00  Web Marketing  
その他, まとめ, ワークフロー, 事例

スプレッドシートを使ってスマートなワークフローを作ろう

紙で回すワークフローでは、全ての入力項目は手で入力していると思います。ExcelやWordで作ったものも基本的には同様ではないでしょうか。これって、結構面倒ですよね。例えば、自分の所属部署を入力する欄があった場合、入力や選択することになると思います。これを自動化できれば嬉しいですね。
今回は、Gluegent Flowとスプレッドシートを使って、所属部署や申請者にまつわる情報を自動的に表示させ、入力を省略させる方法をご紹介いたします。

スプレッドシートを準備する

自動的に表示させるためには各ユーザーの情報が登録されているものを準備する必要があります。１列目にメールアドレス、２列目に氏名、３列目に所属部署・・・というように入力していきましょう。
実はこのスプレッドシートは「オーダーシート」として既に用意されているのです。

オーダーシート

Gluegent Flowを利用する際に「オーダーシート」というスプレッドシートを使うことができます。このオーダーシートには
・ユーザーやグループの並び順を指定する
・ユーザーやグループの名前を指定する
・プロフィール情報を追加する
という用途があります。
１列目にはメールアドレスを入力します。グループ選択パネルでの並び順はオーダーシートに入力されたメールアドレス順になります。
２列目には名前を入力します。G Suiteでは「山田太郎」と設定されていますが、Gluegent Flowを使うときには「山田部長」と表示したい場合に入力します。G Suiteで設定されたままに表示したい場合は、特に入力は不要です。
３列目以降は好きな情報を入力できます。所属部署や社員番号、内線番号、電話番号などを入力しましょう。

親子リストのマスターデータにオーダーシートを使う

並び順やプロフィール情報の表示のために作成したオーダーシートをモデルでも使いましょう。
タイプが「親子リスト」の入力フォームを作成します。選択設定で「スプレッドシートで定義」を選択し、オーダーシートを選択します。ポイントは「ログインユーザーでフィルター」のチェックをオンにすることです。

このチェックをオンにすることで、親子リストの親項目をログインユーザーのメールアドレスだけにします。オーダーシートにはメールアドレスは１人１件登録されていますので、ドロップダウンにはなりますが、他のユーザーを選択することができません。
これで各種情報を自動的に表示します。

※最初の画像は入力フォーム用のドキュメントを作成しています。

いかがでしたでしょうか。毎回同じ情報を入力させるのはユーザーにとっても負担になります。このように各ユーザーに付帯する情報を申請書に表示したい場合はこの方法を使ってみてください。

8:07:00  Web Marketing  
G Suite, データ連携, ワークフロー