一から作る業務システム

2013/09/07

第７回勉強会

Vol.1 マスタ、ワークフロー編

自己紹介

喜田 光昭 （Mitsuaki Kida）

Twitter @kidatti3 Facebook https://www.facebook.com/mitsuaki.kida.7

主に、ネットワーク・セキュリティ・サーバ系の 基盤を中心にお仕事しています

業務アプリケーションの自社開発

自社開発は下降気味

一から作る業務システム

でも？

自社で作ったほうが融通が利く。。。 かも

あえて

一から業務システムを作ることにチャレンジ

する前提で

ではなく

一から作る業務システム

一から業務システムを作る前提で

システムに求められる機能要件を中心に

洗い出してみます

各種マスタ

ユーザマスタ、役職マスタ、組織マスタ

ワークフロー、承認ワークフロー

権限

各種IDのアサイン方法

システムとしては何でもいいけれど

743948

513738

813847

542637

413736

911845

０が抜けた！！

何のコード？？

これ と これ

適当に決めると人に優しくない

ナンバリングルール

頭に０はつけない

⇒ Excelの０抜け回避

頭文字はアルファベットとする （A1111, B2222 etc...）

⇒ 何のコードなのかわかりやすくする

数字の桁数増加に対応できるようにする

A1, A2, … , A999, A1000, … , A100000

A00001, A00002, … , A00999, A01000, … , A100000

人が目にするコードは見て分かりやすい方が便利

ユーザマスタ

ユーザマスタ（社員マスタ）では、個人情報を管理します

固定的な情報 （社員ID、氏名、生年月日 etc..）

変動する情報 （電話番号、住所、組織 etc...）

社員IDについて

人数が増えたことを見越した桁数とする

社員IDに意味を持たせない

社員マスタの考慮点

同じ人は一生同じ番号を持つことを推奨 （人事的にも）

２回以上入社することがある （入社日は１つとは限らない）

ユーザマスタ 兼務の場合

開始日 終了日 部門 部門コード 役職 主務

A 2012/04/01 2014/03/31 販売推進部 SU9000 部長 ○

B 2013/01/01 第一営業部 SU1000 副部長

C 2014/04/01 販売企画部 SU8000 部長 ○

１人の社員が、複数の部門・役職を兼務する場合がある。

期間が重複し、配属によって期間が異なる場合がある。

2012 2013 2014

A

B

C

役職マスタ

役職コード 開始日 終了日 部門 Priority 役員

POS1001 2013/04/01 社長 1 Yes

POS1002 2013/04/01 専務 2 Yes

POS1003 2013/04/01 常務 3 Yes

POS1004 2013/04/01 本部長 10 No

POS1005 2013/04/01 部長 20 No

POS1006 2013/04/01 副部長 21 No

POS1007 2013/04/01 課長 30 No

役職のリスト

「副部長」と「課長」どっちが偉いの？

「部長以上」といえば、Priorityが20以下となります

部門マスタ

部門・組織のマスタ

□□株式会社

第一○○部

第一○○課 第二○○課

第一○○係

上位組織

組織属性

階層違い

部門コード

部門名

期間

部門マスタ

旧部門から、新部門へのデータ移行を意識する必要があります

SU1000 第一○○部 SU1000 第一△△部

SU1000 第一○○部 SU2000 第一△△部

1月～ 3月～

4月～

A部長 B部長

1月～ 2月～

部門名が変わる

部門コードが変わる

部門長が変わる

期間不一致

社員マスタ

各種業務プロセスのデータ

承認ワークフロー

部門マスタの期間とオペレーション期間

部門マスタの期間属性が、4月30日までだったとしても

4月分の処理を5月にも実施するため、考慮する必要があります

何の日付をキーとするか

4月分は、4月の承認ルートを取る必要があります

４月 ５月

☆締日 組織の期間

部門マスタの期間と、実際のオペレーションの期間に

ズレが発生します

ワークフローとは

企業における業務の流れ。それを図式にしたもの。

ワークフローシステムとは

ワークフローをシステム化したもの

承認ワークフロー

申請などを決められた手順で承認を行う機能

経費申請

交通費

出張旅費

接待交際費

仮払い

日当

IT系

ソフトウェア利用

機器貸出

勤怠申請

勤怠

時間外勤務

休暇

代休・振休

入社・退社

実際は、システムそれぞれで承認を行っていることが多い

会社・役所によっては、10階層以上の承認が発生する場合もある

承認ワークフローの機能

申請 （新規、再申請）

承認 （AND承認、OR承認、直列・並行ルート）

差し戻し （申請者差し戻し、承認者差し戻し）

取消 （申請キャンセル、承認後キャンセル）

承認ルート決定

あらかじめ決められた内容を元に承認ルートを決定します

申請ごと

申請ごとにあらかじめ決められた承認ルートを設定

数値

特定の項目で一定の数値を超えた際に承認者の追加

10万円以上⇒部長、100万円以上⇒社長

項目分岐

特定の項目に該当する場合に承認者の追加

承認者 - Approver

事前に全ルートを作成するわけにはいかないので

各承認ルートに役職などを割り当てます

部門長

所属している部門の長。申請者が部門長の場合は自身。

上長

申請者の上司。

役職 （課長、部長、社長 etc..）

グループ （社内ITサポート、総務、経理 etc..）

個人 （○○さん）

代行 - Delegation

承認者がいない場合に、代行者が承認する機能

個人代行

Aさん⇒Bさん

役職代行

経理部長 ⇒ 経理副部長 （下位代行）

C部部長 ⇒ D部部長 （同一役職）

上位代行

E課長 ⇒ F部長

その他

途中で承認者（Approver）・閲覧者（Viewer）を追加したい

ファイルを添付したい

コメントをつけたい

問い合わせをしたい

権限マトリックス

Role （職務的）

組織 役職

（人事的）

社員 派遣社員 業務委託

パート アルバイト

社長 部長

副部長 課長

○○営業部 経理部 購買部

○○承認者 × ×

× 「営業部」の「社員」だけ

実際は、複合的な権限付与が多い

権限マトリックス

編集権限 閲覧権限 ＞

社員 課長以上

「編集権限」と「閲覧権限」があったとします。

社員には「閲覧権限」、課長以上には「編集権限」を与えました

では、≪社員であり、課長である場合は？≫

⇒ そのままでは、どちらの権限も付いてしまいます

権限マトリックス

編集権限 閲覧権限 ＞

社員 課長以上

① ②

関連権限がある場合は、グルーピング化して優先順位を与え

１つの権限のみ付与されるようにします。

営業情報

「課長以上」に「編集権限」が与えられます

権限マトリックス

編集権限 閲覧権限 ＞

社員 課長以上

②

Aさん ⇒ 「課長」だけど「閲覧権限のみ」としたい場合

営業情報

Role （職務的）

役職 （人事的） ＞

× ×

個別Roleは他の条件よりも優先度が高くなります。

Aさんには、「営業情報 – 閲覧権限」のRoleを付与します

①

承認ワークフローシステム

（汎用） 入力フォーム 表示フォーム

（汎用） チケッティング

承認ワークフロー ロジック ＋ ＋

承認依頼メール送信 タスク管理

入力フォームの汎用化 登録データの表示

承認者の決定

おわり