第474話：500万円超は「代理承認」を許さない稟議フロー

そもそも「代理承認」とは何か？

一言で「代理承認」（代理決裁）といっても、プロセス設計の世界では以下の４つの形態がある。（これら以外にも更に「分任」という概念があるが、ここでは触れない）

• A. 副部長は、いつでも、部長の代わりに承認できる
• B1. 副部長は部長が不在の時、代わりに承認できる
• B2. 副部長は部長に事故ある時、代わりに承認できる
• B3. 副部長は部長が欠けた時、代わりに承認できる

もし、サーバシステムに詳しい人であれば「冗長化」という概念と対比させてワークフローを設計するのも良いだろう。すなわち、システム構成機器の一部が故障してもシステム機能が損なわれないという思想で設計するのだ。（部長が故障しても、副部長が承認できる！）

• A.（ホットスタンバイ） 副部長は、いつでも承認できる
• B.（コールドスタンバイ） 部長が承認できない時だけ、代わりに承認できる

以下の稟議フローは、案件の金額によって代理承認ルールが変わる複雑な業務プロセスを表現している。

• a. 100万円以下であれば、A(ホット)の代理承認が許される
• b. 100～500万円以下であれば、B1,B2,B3(コールド)の代理承認が許される
• c. 500万円超の案件は、部長しか承認できない（代理承認が許されない）

[稟議フロー-代理承認]

第473話：今月の成果ポイントは５点！（毎月人事評価）

会社組織にとって「人事評価」は避けて通れない。

しかし「人事評価プロセス」（人事考課プロセス）は会社によって様々だ。たとえば、

• アウトプットに重きを置くのか？
• スキルに重きを置くのか？

などの『評価軸』は、各社それぞれのアイデンティティに関わる問題だ。つまり「他社の例」はほとんど参考にならない。

• [自己成果] 社内ルールに従って、十分な質と量のアウトプットを出している
• [組織効率] より良い社内ルールを提案し、社内ルールの改善に貢献している
• [自己能力] 情報技術や社会システムに関する最新知識を、常に吸収している
• [他者貢献] 情報技術や社会システムに関する最新知識を、社内発信している

更に言えば

• 絶対評価にする
• 相対評価にする
• 一次評価は絶対評価で、二次評価は相対評価にする

といった『基本的な考え方』も企業によってそれぞれ違うだろう。また『評価の実施頻度や報酬反映の仕組み』においても、会社規模や事業内容によって大きく異なる。

• 一年ごとに実施
• 三か月ごとに実施
• 一か月ごとに実施

以下のワークフローは、毎月人事評価を行う例だ。社員は毎月、それぞれの評価軸に対して０～５点の自己評価（相対評価）を行う。それを受けて、部長や役員も同じように、全員分の評価（相対評価）を行う。

[人事評価プロセス]

第472話：業務システムでインフルの兆候をつかむ？

※この記事には「改善編」があります

• 旦那が「水疱瘡」にかかった ！
• 子供が「インフル」にかかった !!

誰だって「職場に感染症が蔓延！」といったリスクは、ゼロに近づけてもらいたい。会社には「適切な感染症対策」を取ってもらいたい。

一言で「感染症」と言っても様々だ。感染力が極めて強い「エボラ出血熱」のような「感染症法」が定める『1類感染症』に該当するような大病(!!!)もあれば、、、「水疱瘡」や「季節性インフルエンザ」など『5類感染症』に分類され、それぞれの組織に対策が委ねられる感染症もある。（さすがに『１類』は国家権力が対策するハズ）

以下のワークフローは「第465話：勤怠管理もクラウド型ワークフローで」の『出退勤報告フロー』をアレンジしたものだ。

何ということはない。日ごろ入力している「出退勤の報告フォーム」の下に、「感染症の兆候アンケート(任意)」という入力フォームが追加されている。

• 季節型インフルエンザ、風疹、水疱瘡などの感染症に、自身が感染したかもしれない （0/1/2/3）
• 季節型インフルエンザ、風疹、水疱瘡などの感染症に、同居家族が感染したかもしれない （0/1/2/3）
• 0: 感染の可能性はほぼ無い
• 1: 症状が出始めた気がする
• 2: 症状が強く出始めたと思う
• 3: 感染症の検査で陽性がでた

[出退勤報告フロー]

第471話：オレの申請に「決裁」は要らぬ！ （by 部長）

部長自身が「稟議書」を書く。。。

そもそも決裁権者なのだから、稟議する（決裁権者に判断を乞う）という行為自体が要らないハズだ。それが部予算内での判断なら、なおさらだ。 しかし、そうであってとしても「稟議書を作成すべし」としている会社は少なくない。つまり、「組織として形成された意思は文書として記録に残す」という視点にたつとともに、監査対応の効率化を想定している。

ただ、、、ワークフローシステムにおいて、「自分で申請して、自分で決裁する」というのは、たしかにメンドウな話だ。

以下のワークフローは、2016年版の基本業務に収録されている「第462話：稟議書を回す」をアレンジしたものだ。「部長ロール」を持つユーザは『2.決裁する』を通らないフローで、稟議書を提出できるようになっている。

[稟議フロー]

第470話：チームリーダーの評価を「無記名投票」で！

上司を評価する「無記名投票」をしたい！

なるほど、オンラインで、簡単に「上司評価」の機会が持てるなら、ソレはソレで便利そうだ。「年次」とは言わず、「四半期おき」や「月次」などで実施すれば、上司自身が日常業務を振り返るための良い機会になる、、、ような気がする？　（「内閣支持率」の調査みたいなものか？）。

しかし、ワークフローシステムとは、そもそも「いつ誰がどんな入力をしたか」を記録する道具だ。普通に考えれば「無記名」とは相性が悪い。


このワークフローは、チームメンバーによる「上司評価フロー（無記名投票）」が定義されている。

具体的には、スケジュールされた日時になると［1.上司評価を記入する］というマイタスクが、メンバー全員に割り当てられる仕組みだ。メンバーは、（手を震わせながら？）、たとえば、[1]信任する、[2]どちらでもない、[3]信任しない、を選んで申請する。

秀逸なのは、入力した「上司評価データ」が自動的に「外部ファイル」に追記され、そして申請データとしては自動的に消去される点だ。つまり［データ閲覧権限］があるユーザでも「誰がどのような投票をしたのか」は確認できない。さらにご丁寧なことに、この例では「外部ファイル」の中身を追記都度にシャッフルする機能まで整っている。つまり、通信ログでも盗聴解析しない限り、投票内容は保護される仕組みになっている。 （投票したかどうか？、いつ投票したか？、については保護対象外としている）

もっとも、、、「投票総数が１人だった！」とか、「投票者全員が信任しないを選択した！！」とか、そういう場合にあっては「誰がどのような投票をしたのかを隠蔽する」が実現できない。。。（怖）

[上司評価の投票（無記名投票）]

第469話：住所変更届（社員マスターの自動更新付）

『社員マスター』をセットしたい！

ただ、人事部のシゴトは「在職者」だけを管理すれば良いという訳ではない。「出向した人」や「退職した人」の情報も管理しなければならない。しかし、業務システム等で使われる「在職者の一覧」（社員マスター）も、きっちりメンテナンスしたい。

そして「Excel ファイル」での社員マスター管理は、すでに限界だ。。。

• 基本情報（社員マスタ－）：社員番号、メールアドレス、通称氏名、入社年月日
• 詳細情報（法定管理項目）：戸籍氏名、生年月日、性別、最終学歴、職歴、緊急連絡先、退職年月日、など

以下は「氏名・住所・電話番号等の新規申請もしくは変更申請」を処理する業務フローだ。

入社時だけでなく、氏名が変わった時、住所が変わった時、電話番号が変わった時に、逐次申請してもらう必要がある。秀逸な点は、必要に応じてワークフロー基盤の『社員マスター』を自動更新できる機能だ。そして自動更新される『社員マスター』は、たとえば「ワークフロー基盤にログインアカウントを持たない社員に通知メールが送られる仕組み」などを作る際に活用される

[社員個人情報の申請受付]

第468話：SLA のサービスクレジットを発行する

SLA （えすえるえー）、、、
Service Level Agreement （サービスレベルアグリーメント）、、、

クラウドサービス事業者や通信サービス事業者が自らの「サービス品質」を宣言し、実際のサービスが基準を下回った際には返金等が行われるという仕組みだ。この「クラウドファースト」な時代（？）、ＩＴ業界の方でなくても見聞きしたことがあるかも知れない。


以下のワークフローは、サービス事業者が「返金等」を行う業務プロセスだ。

一般の方には馴染みのない話だが、実はこの SLA という制度、、、多くの場合は「ユーザ側からの申請」を受けてから返金等のフローが始められる。まぁ「クレームを受けてから返金する制度」みたいな感じにも聞こえるが、、、現実はそうなっている。

（「鉄道輸送サービス」において、延着などの際に特急料金の払い戻しをする仕組みと同じ、とも言える。。。）

もっとも、、、どんなソフトウェアにも必ずバグが含まれている。世界中でセキュアと信じられている仕様にも、必ず弱点がある。それでいて、ユーザ側の利用スタイルも千差万別だ。ハマってしまう人もいれば、ハマらない人も出てくる。そんな状況下において「返金等を行う」のだから、仕方がない方式なのかもしれない。

[SLA申請対応フロー]