インフォシェアはDynamics 365 Customer Engagementを使用しているお客様の“ 困った“にお答えします。

平素インフォシェアをお引き立ていただき誠にありがとうございます。
インフォシェアはこれまでエンタープライズのお客様を中心に マイクロソフトOffice 365、特にSharePointを中心とした活用コンサルティングや各種ワークフローの設計や実装のお手伝いをさせていただいてきました。例えるなら、SharePointは真っ白なキャンパスのようで、アイディアと実装次第で様々な用途に使用することが出来るアプリケーションです。文章ファイルを整理保管する以外にも、SharePointリストを簡易なデータベースとし、会社内の多種多様なデータを保管することもできます。
(※SharePointリストを活用して、どのように業務改善が行えるかは弊社で執筆しました書籍もご参照いただけます。 ひと目でわかるOffice 365ビジネス活用28の事例 – 日経BP社 
 

とはいえ、組織の将来的な成長を考慮すると、データは用途ごとに最も適切なアプリケーションで作成、保持されるべきです。例えば「営業案件」情報の管理。
ある企業様はExcelで営業案件管理を行っていますし、別のところではSharePointリストをカスタマイズし管理しています。一見どのようにでも扱えるように見えるこのデータの取り扱いを真剣に考慮したことはあるでしょうか? 組織の中で、かなりの人員を占める営業担当。そして、適切な利益を上げるために全ての部門が間接的にも営業の役割を担います。

組織の将来にも関わる顧客と営業のデータ。ただ案件管理を行うだけであれば、ExcelでもAccessでも、SharePointのリストでも、大体のアプリケーションは案件情報データを格納することが出来ます。しかしそれで本当に良いのでしょうか? データが格納できればそれで良いわけではなく、「組織の将来」を見越したデータの格納を考慮すべきです。

「なぜ、営業案件を獲得できたのか?」「なぜ、失注してしまったのか?」「お客様の反応はどのように変化していったのか?」「なぜ、A担当者は高い売り上げを上げることが出来ているのか?」
本来、情報はただ蓄積するだけではなく、分析を繰り返しながら ”使って” いくモノです。
 

インフォシェアはOffice 365SharePointのエキスパートとして、もっとお客様のお役に立ちたいと考えています。そしてその答えの一つとして、私たちは取り扱い製品の幅を継続的に広げていけるよう努力しています。
Dynamics 365は以前からご相談ベースで対応させていただいておりましたが、このたび正式にメニュー化し、私どものサービス ラインアップに掲載することとなりました。

2018-04-04 18-08-34

お客様の声を分析した結果、私たちは大きく「3つ」のお客様が抱える ”困った” に対応できるメニューを用意しました。
1.Dynamics 365について気軽に”困った”を質問できるメニュー
Salesforceをはじめとする他社CRM製品は取り扱いベンダーもWebサイトの情報も多いが、Dynamics 365になると非常に情報が限られている。疑問が出たときに、どこにも聞くことが出来ない。

2.Dynamics 365のちょっとした不便を解決したい
しっかり計画・設計してDynamics 365
を導入したものの、実は使い心地が良くない。これは導入に問題があるのではなく、CRMアプリケーションの特徴です。ビジネスは常に変化しており、現場ユーザーのニーズもすぐに陳腐化し変化する。使うディバイスも変化する。では、根本は変えないとしても、”少しのカスタマイズ” で日々変化する現場のニーズに対応できないだろうか?

3.現場にDynamics 365が浸透しない
どんなに素晴らしいDynamics 365を構築しても、利用するのは現場のユーザーです。正しく理解しないままに利用すると、不満が募るかもしれません。使う人に向けたトレーニングを開催したい。


インフォシェアでは、「5時間単位」で契約可能なコンサルティングサービス、そして現場で起きるニーズに素早く対応できる「カフェテリア型メニュー」。そして、常設のトレーニングコースです。現場のユーザーにDynamics 365を理解していただき、気持ちよく使っていただけるよう内容を作成しています。
それぞれの詳細は、別の記事でご紹介させていただきます。

Dynamics 365は将来にわたり、会社の財産となるデータを蓄積するのにふさわしいプラットフォームです。是非、インフォシェアの ”Dynamics 365 サービス メニューを” ご活用ください。
(※Dynamics 365は複数のアプリケーションで構成されており、インフォシェアが今回ご提供するのは、Customer Engagement向けのメニューです。)

 

Nintex Workflow DocuSign連携

皆様こんにちは、インフォシェアの小高です。

Nintex Roadshow Tokyo のおさらいその2ということで、今回はDocuSign連携についてです。 この連携はオンプレでもオンラインでもどちらも使用可能なソリューションとなります。

こちらもNintexの連載記事Season2に追記したいと思います。

連載記事(Season2)の目次はこちらから。
ちなみに連載記事(Season1)の目次はこちらからになります。

———————

DocuSign自体は、SharePointやNintexとは独立したドキュメントに電子署名を行うことができるサービスです。

本来の使い方としては、依頼元のユーザーがDocuSignサイトから、あらかじめ登録してあるテンプレートファイル(docx等)を、署名者に送信するところから始まります。

署名者にはメールが送られてくるので、そのリンクを元に、下記の様なDocuSignのサービスで電子署名を行う形になります。

image

上記の署名ボタンをクリックすると、下記のような手書き可能なUIが表示されますので、ここで署名を行います。(手書きではなく、決まったスタイルの選択も可能です)

image

後は、依頼元のユーザーはDocuSignのサイト、署名者はメールで、署名後のドキュメントをPDFとして入手する形となります。

ではNintex Workflowを使用すると何が嬉しいか、それは、、、依頼元のユーザーは、この一連の流れをSharePointのみで完結できる点にあるんですね。
つまりDocuSignのサイトに行かなくてもいいんです。
またテンプレートファイルにはSharePointのリストに入力した値を差し込んだ形で署名者に送ることが出来るようになります。

例えば、上記の例では、下記の様に住所、会社名、氏名等が差し込まれていました。(変更可能です)

image

実はこれ、下記の様なSharePointのフォームに入力したものでした。
このアイテムの保存でワークフローを実行していたんですね。

image

流れとしては、こんなイメージになります。

image

今回のデモでは、上記を秘密保持契約の締結と言うシナリオでご紹介いたしました。
(もちろん、秘密保持契約のテンプレートファイルはあらかじめDocuSignにアップロードしておく必要があります)

ですので、最終的にPDFとして、依頼元と署名者が入手するPDFは以下のようなものになります。(手書きの署名、、、(汗))

image

実際のワークフロー自体は、いくつかのアクションを組み合わせて実装する形となりますが、もっとも肝心なリストアイテムの内容をDocuSignのテンプレートに差し込むアクションは以下になります。(DocuSignテンプレート事前入力サービス)

image

最後に注意点です。
これまでお客様と電子署名の話になる場合、承認時のハンコを押すイメージで話をお受けする場合が殆どでした。
これは、承認と署名を同一視している話に他なりません。
しかしながら承認時の差し戻しや取戻しのシナリオを考えた場合、この署名のソリューションとは少々相性が悪いと考えられます。(例えば、承認時にコメントを残したい、証跡を取っておきたい等)
SharePointとDocuSignは別のソリューションですので、行ったり来たり、あるいはデータの連携は少なければ少ないほど良いと考えられるからです。

そうした意味で、SharePointとDocuSignの連携ソリューションでは、承認はSharePointで、署名はDocuSignでと、分けて考えることをお勧めします。つまり署名はドキュメントのファイナライズという事ですね。これはDocuSignのライセンス体系においても有利になります。

もしご興味のある方がいらっしゃいましたら、以下のお問い合わせからご連絡いただければと思います。http://www.infoshare.co.jp/contact.php

Nintex Workflowのドキュメント生成

皆様こんにちは、インフォシェアの小高です。

Nintex Roadshow Tokyo ご参加の皆様ありがとうございます。
時間がかなり限られてましたので、駆け足になってしまいました。もう一度おさらいを含めてこちらに記載しておきます。

内容自体はドキュメント生成になりますので、Nintexの連載記事Season2に追記したいと思います。

連載記事(Season2)の目次はこちらから。
ちなみに連載記事(Season1)の目次はこちらからになります。

———————

ドキュメント生成とは、何とも普通の響きですね。
なので、「なぜそんな普通の事を」と思われるかもしれませんが、これは結構大変な変革なのです。

と言うのも、サーバーサイドのOfficeファイル作成は、技術的には(理屈では)出来ることはわかりますが、実際行うとなると結構色々なハードルがあるのが現状なのですね。
特にOfficeファイルを1からプログラムで生成するとなると、ぱっと思い浮かぶのはOfficeオートメーションですが、これをサーバーで実行する開発者は皆無でしょう。となると、その他のライブラリの使用となりますが、どれも一長一短と言ったところ。

なかでも気になるのがサーバーの負荷です。実際SharePointの標準機能でもExcelエクスポート機能は、ファイルの作成自体をクライアントで行っていました。(iqyファイルでしたね。)

ですので、Nintexの実装として、サーバー負荷を均一にできうるSharePointワークフローでの実装は納得できる感じです。

前置きはこのぐらいにして、、、

実際の設定ですが、実装は「ドキュメントの生成」というワークフローアクションとなっていまして、これはオンプレでもオンラインでも使用可能です。

アクションの設定は以下のような感じになっております。最終的に生成したいドキュメントのテンプレートファイルを指定していきます。

image

このテンプレートファイルは、SharePointのライブラリにおいてあるdocx等のファイルで、事前に作っておき(中身はなんでもいいです)、こちらの設定画面で登録を行います。
すると上図にある、ドキュメントのタグ付ボタンが表示されますので、クリックすると、Word等ファイルに関連づいたアプリケーションが起動し、下図のようにNintex Document Taggerペインが表示されます。

image

このペインは、WF内の値をドキュメントがわに差し込む設定ができるようになっていますので、ドキュメントに差し込みの設定を行います。(WF内の変数や列の値の参照が可能です)

後はWFを実行すると、、、例えば、元々の申請フォームはこんな感じだったとしますね。

image

値がテンプレートのdocxファイルに差し込まれて以下のようになります。
このファイルは自動的にリストアイテムの添付ファイル、任意のライブラリに保存が選択できます。

繰り返しますが、このファイルのフォーマットは私がデモとして作成したものですので、いかようにも変更できます。

image

ちなみにこのファイルですが2ページ目があります。テンプレートを2種類用意して、2つ目のテンプレートは画面の条件によって2ページ目になったり、そもそもドキュメントに含まれなかったりを実装しています。今回は2つのファイルをまとめて1つのdocxにしてますね。(PDFにすることも可能です。)

他にも以下のような特徴があります。

image

セッションデモでは、申請承認が終わり承認された後、申請者が扱うdocxファイル(印刷でもなんでもしてください的なものですね)と管理者が保管するPDFファイルを、それぞれ添付ファイルとライブラリに自動的に作成しました。

ちなみにですが、このドキュメント生成は別途ライセンスが必要になりますので、その点はご注意ください。

もしご興味のある方がいらっしゃいましたら、以下のお問い合わせからご連絡いただければと思います。
http://www.infoshare.co.jp/contact.php