FileMakerで簡易ワークフロー

チームワークに必要なワークフロー。オンプレもOKなFileMakerで。

仕事の効率化

  10月 23, 2021    

 Reception for FileMaker (レセプション・アドオン,レセプション・ポータル) を使うとどのような効果が期待できるか考えてみました。

ユーザ視点

  • ワンストップサービス効果
    • 申請先の窓口が別々でもポータルから全様式を提出できるので、窓口はどこか気にする必要がないし、問い合わせでたらい回しにされることもない。
  • ワークフロー効果
    • 進行状況がリアルタイムでわかり、今どのような状況なのかという問い合わせが減る。
  • ペーパーレス&ファイルレス効果
    • 申請用ワークシートをダウンロードして入力し、添付資料として提出するというようなファイルの取り扱いがなくなる。　　

スタッフ＆管理者視点

  • ワークフロー効果
    • メールでのやり取りと異なり、申請状況の管理がしやすい。
    • 審査承認待ちのものはないかなど一括管理がしやすい。
  • 分散管理効果
    • データベースが様式別に分離しているので、様式変更作業などデータベースの一時停止といった保守作業が楽。
  • ペーパーレス&ファイルレス効果
    • 資産管理の面で個人情報や要配慮情報の特定がしやすく、管理策や管理策の実施状況のチェック、リスクアセスメントがやりやすい。

開発者視点

  • 分散開発効果
    • 様式の設計・製造とワークフローを完全に分離でき、並行して開発が可能。
    • 様式の追加によるカスタマイズがしやすい。取りあえず1様式から始めて、様式ができたらサービスに追加する。ものによってはノンカスタマイズで、画面からサービスを追加設定するだけで運用可能。スモールスタートアップ
  • ローコード開発効果
    • 様式の設計・製造にあたるメンバーは、スキル・経験が浅くとも可能。内製化が進めやすい。

しかし、本当の業務改善はこれからです。今までと同じ様式、業務フローで、手間が少なくなるだけでは抱えている問題は解決されないかもしれません。
そのことについての私の呟きはこちら。



   / /

  No Comments

サンプル導入手順

  10月 22, 2021    

Reception for FileMaker サンプルカスタムAPPの導入手順です。
ここを修正しなければ動かないという箇所だけ説明します。

1. 環境

  • FileMakerServer 19~
  • FileMakerPro 19~

2. 用意するファイル

  • portal.fmp12
  • 介護休業申請書.fm12

3. 導入手順

3.1 サインイン

  1. ファイルをホストサーバにアップロードします。
  2. portal.fmp12 を開くと、サインイン画面が表示されます。
  3. "サインイン"を選択し、アカウントID：fm1、パスワード：fm1 でサインインします。
  4. 個人情報の取り扱いについての画面が表示されます。
  5. 説明を読んで同意する場合は、スクロールして"同意する"を選択し、閉じます。
2.サインイン


3.個人情報の取り扱いについて

4.同意する


3.2 環境設定

  1. 画面左上の歯車アイコンを選択すると、環境設定画面が表示されます。
  2. REST APIの設定をします。
    • url_domain 
      • 現在のドメインのURLを設定します。（例：https://byictnet.local）
      • 他の項目は設定済みです。

3.REST APIの設定

3.3 サービス設定

  1. "サービスリスト"を選択し、サービス名＞介護休業申請書＞設定 を選択します。
  2. 外部連携のための設定をします。
    • fmnet
      • FileMakerネットワークで連携する場合に選択します。
  3. 開く
    • FileMaker Server domain
      • カスタムAppが共有されているホスト名を設定します。（例：byictnet.local）
      • 他の項目は設定済みです。
  4. アドオン
    • "アドオンの設定"ボタンでカスタムAppが開きます。
  5. カスタムAppの設定に続きます。
1.サービスリストでサービス設定

2.外部連携のための設定

6.アドオンの設定


3.4 カスタムAppの設定

「3.3 サービス設定」より続く
  1. サンプルカスタムApp・介護休業申請書 が開き、仮レコードを作成して良いかダイヤログが表示されるので、"OK"で続行する。
  2. 設定値の一部を自動で設定したことがダイヤログで通知される。"OK"で続行する。
  3. "件名"にどのフィールドを設定するか決める。例えば介護休業申請書の"名前"フィールドを設定したい場合は、"[氏名]"&介護休業申請書::氏名 を選択する。
  4. "状況"の初期値を選択する。
  5. "詳細"にどのフィールドを設定するか決める。例えば介護休業申請書の全てのフィールドを設定したい場合は、全ての値を選択する。
  6. 設定画面を閉じる。
  7. 介護休業申請書のカスタムAppを閉じる。
  8. 「3.3 サービス設定」の画面に戻るので閉じて設定終了です。
1.仮レコード作成ダイヤログ
2.設定値の一部を自動で設定
3.件名フィールドの設定

4.状況の初期値を選択



5.詳細の設定

6.設定画面を閉じる

7.介護休業申請書を閉じる

8.アドオンの設定画面へ戻る

以上がサンプルの導入手順です。

プリセットされているアカウントは以下となります。
  • fm1 （[Full Access]）
  • user01（一般ユーザ）
  • user02（アカウント管理者）
  • user03（サービス管理者）
  • user04（一般ユーザ）
  • user05（ログ管理者）
アカウントIDのパスワードは、アカウントIDと同じものが設定されています。（例：アカウントuser01のパスワードは、user01）

   / /

  No Comments

業務フロー例

  10月 13, 2021    

 業務フローを２つスイムレーンで書きました。

ケース【申請・稟議】

登場人物
  • Aさん　従業員
  • Bさん　担当者，審査者
  • Cさん　責任者，承認者
概要
  • 従業員が申請し、担当者が審査し、責任者が承認するというシンプルな業務フローです。
  • 申請をアドオンが貼り付けられたカスタムAPPで操作し、審査・承認をポータルサイト（またはカスタムAPP）で操作します。
ケース【申請・稟議】


ケース【不特定多数からの受付】

登場人物
  • ゲスト　申請者
  • スタッフ　担当者，審査者，承認者
概要
  • 不特定の人（アカウントを持たないゲスト）が申請し、スタッフが受付・審査・承認する一般的な受付のフローです。
  • 申請をアドオンが貼り付けられたカスタムAppで操作し、審査・承認をポータルサイト（またはカスタムAPP）で操作します。
  • 申請者は、全員ゲストアカウントでサインインするので、他の人の申請内容を見れないようにするため、ログの一覧画面はスタッフにしか表示されません。
  • また、アドオンが貼り付けられたカスタムAppをダウンロードしてもらい、FileMakerGoでゲストアカウントとして起動し、申請してもらうことも可能です。
  • 本人への連絡は、別の手段（メールなど）を想定しています。
    ケース【不特定多数からの受付】

   / /

  No Comments

こんな機能もあります

  10月 12, 2021    

 Reception for FileMaker の隠れた機能です。

レセプション・ポータル

ゲストによる受付

アカウント登録しなくともゲストでサインインし、サービス＞追加　から申請することができます。申請された内容は、審査・承認するスタッフだけが閲覧可能です。申請者とのやり取りはメールなど別の手段を想定しています。

個人情報保護の管理策

個人情報を扱う場合、個人情報保護法の遵守が必要なので、以下の機能を標準で持たせました。
  • 個人情報の取り扱いについての通知
    • 組織名、個人情報保護管理者
    • 個人情報の利用目的とお預かりする項目
    • 個人情報の第三者への提供について
    • 取得した個人情報の開示等およびお問い合わせ窓口について
  • 同意いただけなかった場合の機能制限
    • サービスが非表示となりデータ登録できなくなる
    • データが非表示となり閲覧できなくなる

レセプション・アドオン

ステルス更新

標準では、アドオンのボタンを押さないとデータを送信しませんが、他のスクリプトやトリガーからステルス更新するスクリプトを呼ぶことで、自動でデータ送信するようにカスタマイズすることが可能です。

言語切り替え

レセプション・アドオンだけの機能ですが、外国人のユーザ向けに、表示する言語を切り替える機能があります。現在は、日本語、英語の２ヶ国語に対応しています。実験的に実装してみました。需要があればレセプション・ポータルにも実装してみようと思います。

言語切り替え・日本語

言語切り替え・英語
 

分散データの紐付け

カスタムApp側から見て、RESTで送信した先の（レセプション・ポータルの）データを更新するにはどうするか考えました。答えは、「レセプション・ポータル側で追加したレコードの主キーをレスポンスで受け取る」でした。
DataAPIのscript.presortパラメータ仕様（Claris）を参照してください。
データを送信したあとレセプション・ポータル側で実行するスクリプトにより主キーを返してもらうという実装をしています。
これによって、分散した複数のカスタムAppでデータを持っていたとしても、レセプション・ポータル側の主キーを付けて送るため更新時にキー重複が起こりません。


   / /

  No Comments

登録: 投稿 (Atom)