生産管理システムの権限管理は、立ち上げの忙しさのなかで「とりあえず全員に全部の権限」のまま数年放置されがちな領域です。ところがそれは、監査での指摘、退職者アカウントの残存、受注入力と承認の兼務といった形で、ある日まとめて表面化します。この記事では、タイで操業する日系工場を前提に、役割設計・承認フロー・操作ログ監査という3つの実務を順に整理します。
なぜ今、生産管理システムの権限管理が問われるのか
立ち上げ時の「全員フル権限」がそのまま残る
生産管理システムやMESを新規導入するとき、最優先されるのは当然ながら「生産を止めないこと」です。カットオーバー直前になると、誰の画面で何が出ないという話が毎日出てきます。そこで最も手っ取り早い解決策として選ばれるのが、関係者全員に管理者相当の権限を付与してしまうことです。
これ自体は、立ち上げ期の判断としては必ずしも間違いではありません。問題は、その状態が「暫定」のまま固定化されることです。稼働が安定すると誰も権限の話をしなくなり、ベンダーの標準ロールがそのまま残り、新しく入った人には「前任者と同じ権限で」とコピーが繰り返されます。3年も経つと、誰がなぜその権限を持っているのかを説明できる人が社内にいなくなります。
タイの日系工場では、この構造がさらに強く出ます。情報システム担当が1名しかいない、あるいは総務や経理との兼務であるケースが多く、権限設計のような「止まっていても誰も困らない仕事」は後回しになりがちです。加えてローカルスタッフの異動・転職の頻度が日本国内より高く、アカウントの入れ替わりが多い割に、その処理が属人的な運用になっています。
監査の季節に、まとめて指摘される
この問題が表面化する典型的なタイミングが、監査です。日本本社の内部監査、親会社の統制評価、ISOの審査、そして顧客監査。いずれの場面でも、システムに関して聞かれることはおおむね共通しています。
- 誰がどの権限を持っているかを示す一覧を出せるか
- その権限を付与した根拠(申請と承認の記録)を示せるか
- 退職者・異動者の権限がいつ停止されたかを示せるか
- 特権IDが何個あり、誰が使っているかを説明できるか
- 重要な操作について、いつ誰が実行したかを追跡できるか
これらに一つも答えられないという事態は、実際には珍しくありません。そして厄介なのは、指摘されてから対応するとコストが跳ね上がることです。監査後の是正には期限が付き、その期限内に権限の棚卸しとロール再設計とログ取得の仕組みづくりを同時に走らせることになります。平時に半年かけてやれば済んだ仕事を、3か月で、しかも生産を止めずにやる羽目になります。
最大のリスクは「生きている権限」の悪用
外部からの攻撃よりも先に押さえておくべきなのが、正規に付与された権限が正規のログインを通じて使われるケースです。この記事が扱う失敗モードそのものにあたる事例として、リクルートが2026年3月30日に公表した件があります。
同社の公表によれば、元従業員が業務上付与されていたアクセス権限を用いて、社内のデータを社外の第三者に持ち出していました。2025年12月に外部からの情報提供を受け、2026年2月に社内調査で事実を確認したという経緯です。影響範囲として公表された人数は約20,699人分で、その内訳には役員32名、役員秘書24名、美容領域の営業担当449名、全従業員約19,000人分の記録、クラブ活動の代表者1,194名が含まれます。
この事案が示しているのは、ファイアウォールもEDRも多要素認証も、この種の持ち出しには効かないということです。使われたのは正規のIDと正規の権限であり、システムから見れば通常の業務操作と区別がつきません。区別をつけられるとすれば、それは「この人はこのデータにアクセスする必要があったのか」という権限設計の側と、「いつ誰がどれだけ参照・出力したか」という操作ログの側だけです。
外部からの攻撃も、結局は「どこまで届くか」の問題
もちろん外部攻撃も無視できません。ニチレイは2026年8月14日、同年7月13日に発生したランサムウェア攻撃(攻撃者グループはRansomHouse)により、従業員の氏名・生年月日・会社のメールアドレス・人事関連情報が漏えいした可能性があると公表しました。また同じ2026年8月には、中部電力をはじめ複数の企業で社内システムへの不正アクセス事案が報じられています。
外部攻撃の文脈で権限管理が効いてくるのは、侵入された後です。攻撃者が最初に奪う資格情報は、多くの場合、末端の一般利用者のものです。その資格情報でどこまで到達できるかを決めているのは、まさに権限設計です。全員が全モジュールにアクセスできる状態であれば、末端1アカウントの奪取が全社データの奪取と同義になります。逆に、役割ごとにデータ範囲が絞られていれば、被害はそのアカウントの担当範囲で止まります。
タイで操業する工場には、PDPAという追加の重み
タイに拠点を置く企業には、もう一つの前提があります。個人情報保護法(PDPA)の執行が実際に動いているという事実です。Tilleke and Gibbinsが2025年8月1日に公表した解説によれば、タイのPDPC(個人情報保護委員会)は5件の事案について8件の制裁金を公表し、その合計は約21.5百万バーツにのぼりました。主な原因として挙げられたのは、安全管理措置が不十分または見直されていないこと、漏えい時の通知義務を果たしていないこと、そしてDPO(個人情報保護責任者)を選任していないことです。
「安全管理措置が見直されていない」という指摘は、まさに権限管理の話です。一度設計したロールを何年も見直していない状態、退職者のアカウントが残っている状態は、この指摘に直接当てはまります。工場の生産管理システムには従業員の勤怠・作業実績・スキル情報が入り、取引先の担当者情報も入ります。これらはいずれも個人データです。工場側から見たPDPA対応の全体像は 工場IoTの個人情報保護 で整理していますので、あわせて確認してください。
業務システム アクセス権限を3層で設計する
「役職＝権限」で組むと必ず破綻する
権限設計でよくある出発点が、役職に紐づける方法です。課長はこれ、係長はこれ、一般職はこれ、という具合です。一見わかりやすいのですが、実務では早い段階で破綻します。同じ課長でも、生産管理課長と品質保証課長では必要な権限がまったく違うからです。結局「◯◯課長だけ例外でこの権限を追加」という個別対応が積み上がり、数年後には役職との対応関係が失われます。
破綻しにくい設計にするには、権限を一つの軸で表現しようとせず、独立した3つの層に分解します。ロール(何の仕事か)、スコープ(どのデータまでか)、アクション(何ができるか)の3層です。
第1層 ロール — 職務の型で切る
ロールは「その人が何の仕事をしているか」で定義します。役職でも部署でもなく、業務プロセス上の役割です。生産管理システムであれば、たとえば次のような単位になります。
- 受注・所要量計算の担当
- 生産計画の立案担当
- 現場の実績入力担当
- 在庫・入出庫の管理担当
- 購買・発注の担当
- 品質記録の登録担当
- 原価・実績の分析担当
- マスタ保守の担当
- システム管理者
重要なのは、この一覧が「今いる人」ではなく「必要な仕事」から作られていることです。一人が3つのロールを兼ねること自体は、中小規模の工場では避けられません。ただし兼務は「一人に3つのロールを付与している」という形で見える状態にしておく必要があります。専用の混合ロールを作ってしまうと、その人が異動したときに何が起きるか誰にもわからなくなります。
第2層 スコープ — データの範囲で絞る
ロールが同じでも、見てよいデータの範囲は違います。複数工場・複数ラインを持つ会社では、この層が実質的な情報統制になります。
- 拠点・工場単位(ラヨーンの工場の担当者はチョンブリの実績を見ない)
- ライン・工程単位
- 製品群・顧客単位(特定顧客向けの図面や原価を、他顧客担当が見ない)
- 期間(過去データの参照範囲)
スコープの制御は、システムによって実装力に差が出る部分です。ロール定義はどの製品でもできますが、「同じ受注入力画面で、担当している顧客の受注しか見えない」というレベルの制御ができるかどうかは、製品選定時に必ず確認すべき項目になります。
第3層 アクション — 操作の種類で分ける
3層目が、実際にできることの種類です。ここを「参照」と「更新」の2種類でしか持てないシステムは、権限管理としては弱いと考えてください。実務上は最低でも次の5種類に分かれている必要があります。
| アクション | 内容 | 統制上の意味 |
|---|---|---|
| 参照 | 画面上でデータを見る | 情報の範囲を決める。最も軽い |
| 登録・変更 | 伝票や実績を入力・修正する | 業務データの正しさに直結する |
| 承認 | 他者が入力した内容を確定させる | 職務分掌の要。登録と必ず分ける |
| マスタ変更 | 品目・単価・取引先・BOMを変える | 影響範囲が最も広い。別扱いにする |
| 出力・抽出 | CSV出力、帳票印刷、API経由の取得 | 持ち出しに直結する。参照と分ける |
とくに見落とされやすいのが最後の「出力・抽出」です。参照権限があれば画面では見られるのだから出力も同じ、と扱われがちですが、統制上の意味はまったく違います。画面で1件ずつ見ることと、全件をCSVで落とすことは、リスクの大きさが桁で違います。先に触れた持ち出し事案のような失敗モードを想定するなら、大量出力は参照とは別の権限として切り出し、後述する操作ログの対象にしておくべきです。
職務分掌 — 同一人物に持たせてはいけない組み合わせ
3層モデルを組んだあと、必ず突き合わせるのが職務分掌(SoD)です。ITの内部統制実務では、同一人物に発注データの作成権限と支払承認権限を同時に与えないことが基本原則として挙げられています。作った本人が承認できてしまえば、承認という手続きに意味がなくなるからです。
生産管理システムに置き換えると、少なくとも次の組み合わせは分離を検討する対象になります。
- 購買発注の作成権限と、発注承認権限
- 入出庫実績の登録権限と、棚卸差異の調整権限
- 出荷指示の登録権限と、出荷実績の確定権限
- 品目マスタの単価変更権限と、原価計算結果の承認権限
- 一般業務の実行権限と、操作ログの削除・設定変更権限
最後の一つは特に重要です。ログを消せる人が業務操作もできる状態では、監査証跡そのものが信頼できません。システム管理者であっても、ログの改変ができない構成を取るのが原則です。
なお、人数の少ない工場では完全な分離が物理的に不可能な場合があります。そのときに取るべき対応は「分離できないので諦める」ではなく、「分離できない事実を文書化し、代替統制を置く」ことです。代替統制とは、たとえば当該操作を全件ログ出力して月次で上長がレビューする、といった手当てを指します。監査で問われるのは分離の有無そのものではなく、リスクを認識して手当てしているかどうかです。
承認フロー システム化の設計パターン
紙の決裁をそのまま写さない
承認フローをシステム化するとき、最も失敗しやすいのが、現在の紙の回覧ルートをそのまま画面に置き換えることです。紙の決裁ルートは、押印欄の数が「関係者への周知」と「責任の所在」を兼ねて膨らんでいることが多く、そのまま移すと承認待ちの滞留が発生します。滞留が発生すると現場は必ず抜け道を作ります。承認前に出荷してしまい、後からシステムを合わせる。この状態になると、システム上の承認記録は実態を反映しなくなり、統制としては形骸化します。
システム化するときは、いったん「この押印は何を担保しているのか」を分解してください。多くの場合、押印は次のどれかです。
- 内容が正しいことの検証(検証)
- 実行してよいという意思決定(承認)
- 知っておくべき人への周知(通知)
このうちシステムの承認ステップにすべきは、真ん中の「承認」だけです。周知は通知機能で足り、検証は入力時のバリデーションやチェックリストで代替できることが少なくありません。押印欄が5つあった決裁が、承認1段階と通知3件に整理できる例は珍しくありません。
承認を要求する操作を3つの軸で絞り込む
すべての操作に承認を付けると運用が回らず、何にも付けないと統制になりません。どの操作に承認を置くかは、次の3つの軸で判断するのが実務的です。
| 判断軸 | 見るポイント | 承認を置くべき例 |
|---|---|---|
| 不可逆性 | 実行後に元へ戻せるか | 出荷確定、在庫の除却、締め処理 |
| 影響の広さ | 一件で終わるか、全体に波及するか | マスタの単価変更、BOM変更、ロール定義の変更 |
| 記録の正しさ | 会計・監査の数字に直結するか | 棚卸差異の調整、原価の手修正、実績の遡及修正 |
3軸のいずれにも当てはまらない日常操作、たとえば通常の作業実績入力に承認を置く必要はありません。そこに承認を置くと、承認者は内容を見ずに一括承認するようになり、承認記録の信頼性が全体として下がります。
代理承認と不在時のエスカレーションを最初から設計する
承認フローの運用が破綻する最大の原因は、承認者の不在です。出張、休暇、退職、そして異動。この設計を後回しにすると、現場は「承認者のIDとパスワードを借りる」という最悪の回避策に到達します。この時点で、承認記録も操作ログも意味を失います。
最初から次の3点を仕様に入れてください。
- 代理承認者をあらかじめ登録でき、代理として承認した事実がログに残ること
- 一定期間承認されない案件が上位者に自動エスカレーションされること
- 承認者が退職・異動した際に、そのロールの後任へ一括で引き継げること
3つ目は特に軽視されがちですが、これがないと承認者の異動のたびに未処理案件が宙に浮きます。
ID発行そのものを承認フローに乗せる
見落とされやすいのが、業務データの承認だけでなく、権限そのものの発行にも承認フローが要るという点です。ITの内部統制実務では、IDの発行を「申請書の提出」「所属長の承認」「IT部門の承認」という手順で行うことが標準的な統制として整理されています。ポイントは承認が二段構えになっていることです。所属長は「その業務にその権限が必要か」を判断し、IT部門は「その権限が技術的・統制的に妥当か」を判断します。役割が違うので、どちらか一方では成立しません。
この手続きを口頭やチャットで済ませている会社は非常に多いのですが、監査で求められるのは記録です。専用のワークフロー製品を入れる必要はなく、申請フォームと承認履歴が残る形であれば、まずは既存のグループウェアでも構いません。重要なのは、後から「この権限はいつ誰の承認で付いたのか」を1件ずつ示せる状態にしておくことです。
内部統制 生産管理システムの運用サイクル
四半期ごとの権限棚卸し
権限管理は設計して終わりではなく、定期的な見直しが対になって初めて統制として成立します。ITの内部統制実務では、アクセス権限のレビューとアテステーション(妥当性の確認と承認)を四半期ごとに行うことが標準的な運用として挙げられています。
実務としては、次の手順になります。
- システムから現在の権限一覧を出力する
- 部門長に自部門の一覧を配り、不要な権限に印を付けてもらう
- 退職者・異動者が残っていないかを人事データと突き合わせる
- 特権ID・システム管理者権限を個別に確認する
- 削除・変更の結果を記録し、次回のレビューまで保管する
この作業が現実的に回るかどうかは、ステップ1で「権限一覧をボタン一つで出せるか」に大きく依存します。出力にベンダー依頼が必要なシステムでは、四半期ごとの棚卸しはまず定着しません。製品選定の段階で、権限一覧の自己出力ができるかを必ず確認してください。
入退社・異動をトリガーにする
四半期レビューは網であって、一次防衛線ではありません。退職者のアカウントが最大3か月間生き続けるようでは不十分です。一次防衛線は、人事イベントを起点にした処理になります。
- 退職: 最終出社日にすべてのアカウントを停止する(削除ではなく停止。ログの追跡可能性を残すため)
- 異動: 新しい権限を付与する前に、旧権限を外す(付け足しにしない)
- 長期休職: 一時停止し、復職時に再確認する
- 外部委託先の要員入替: 契約単位ではなく個人単位で管理する
この運用は、そもそも「誰がどのアカウントとどの端末を持っているか」の台帳がないと成立しません。アカウントと端末の棚卸しをどう仕組み化するかは 工場のIT資産管理 にまとめてありますので、権限管理と同時に整えることをおすすめします。
情シスが実質いない工場でどう回すか
ここまでの内容は、専任の情報システム部門があることを前提にしているように見えるかもしれません。しかしタイの日系工場の多くは、情シス機能を1名、あるいは兼務で回しています。その状況で四半期レビューまで実施するのは、正直なところ簡単ではありません。
現実的な選択肢は3つあります。一つは、権限の棚卸しだけを外部に委託し、判断は社内に残す方法です。一覧の出力・突合・報告書化という手間のかかる部分を外に出し、削除の可否だけ部門長が判断します。二つ目は、システムベンダーの保守契約の中に、年次または半期の権限レビュー支援を組み込む方法です。三つ目は、情シス機能そのものを外部化する方法で、これについては 情シスアウトソーシング で判断材料を整理しています。いずれの場合も、最終的な承認判断だけは社内に残してください。ここを外に出すと、統制の主体が不明確になります。
操作ログ 監査 工場のチェックリスト
何を記録すべきか
操作ログは「取っていればよい」ものではなく、監査で使える形になっているかどうかが問われます。1件のログレコードが最低限備えるべき項目は次の5つです。
| 項目 | 内容 | 欠けると起きること |
|---|---|---|
| 誰が | ユーザーID(共有IDではなく個人ID) | 行為者を特定できず、証跡として使えない |
| いつ | 日時(タイムゾーンを明示) | 日本本社との突合で1日ずれる |
| 何を | 対象データの識別子(伝票番号、品目コード) | 「何かを変えた」までしかわからない |
| どうした | 操作種別と、変更前後の値 | 影響を評価できず、復旧の判断ができない |
| どこから | 端末・IPアドレス・接続経路 | 委託先や社外からのアクセスを区別できない |
とくに「変更前後の値」は、多くのシステムで既定では記録されません。ログイン履歴と画面アクセス履歴だけを取っていて、実際のデータ変更内容が残っていないという状態は非常に多く見られます。マスタ変更や実績の遡及修正については、変更前後の値を残す設定になっているかを個別に確認してください。
記録対象を絞る
全操作を記録すると、量が膨大になり、結果として誰も見なくなります。工場の生産管理システムで優先的に記録すべきは、次の範囲です。
- ログイン・ログアウトと認証失敗
- 権限とロールの付与・変更・削除
- マスタデータの変更(品目、単価、取引先、BOM、標準原価)
- 承認・却下の実行
- 締め処理、実績の遡及修正、棚卸差異の調整
- 大量データの出力・抽出とAPI経由のアクセス
最後の項目は、先に述べた持ち出しリスクへの直接的な対策になります。誰が、いつ、どの範囲のデータを何件出力したかが残っていれば、異常な量の抽出を後から発見できます。逆にこれがなければ、持ち出しは発生した事実すら把握できません。
保管期間と改ざん対策
保管期間について一律の正解はありませんが、決め方には型があります。まず自社の監査周期から逆算し、直近の監査対象期間を確実にカバーできる長さを下限とします。そのうえで、親会社の文書保存規程、税務・会計関連書類の保存慣行、契約上求められる期間のうち最も長いものに合わせるのが実務的です。少なくとも「1年で自動削除されるので前回監査の期間が残っていない」という状態は避けてください。
改ざん対策としては、次の3点を押さえます。第一に、業務システムの管理者がログを編集・削除できない構成にすること。第二に、ログを別のストレージへ日次で複製し、複製先の書き込み権限を業務側に持たせないこと。第三に、削除や設定変更の操作自体もログに残すことです。この3点が揃って初めて、ログは監査証跡として機能します。
「見る運用」にしないとログは資産にならない
ログの最大の問題は、取っているのに誰も見ていないことです。先に触れたPDPCの制裁事例でも、漏えい時の通知義務を果たしていないことが原因として挙げられていました。通知するにはまず気づく必要があり、気づくにはログを見る運用が要ります。
現実的な運用は、次のような組み合わせです。月次で権限変更の一覧を確認する。週次で大量出力とAPIアクセスの件数を確認し、平常時の水準から大きく外れたものだけを追う。認証失敗の連続やアカウントロックはリアルタイムで通知する。すべてを毎日見る必要はなく、頻度と対象を分けることで負荷は十分に下げられます。
生産管理システムの選定・設定でどこを見るか
RFPに入れておきたい質問項目
権限管理は、導入後に追加しようとすると製品の設計上できないことが多い領域です。だからこそ選定段階で確認すべきで、具体的には次の項目を提案依頼書に入れておくと、各社の実力差がはっきり出ます。
- ロール定義を自社で自由に作成・変更できるか。ベンダー作業が必要か
- 一つのユーザーに複数ロールを付与できるか
- データ範囲(拠点・ライン・顧客)による絞り込みができるか
- 参照と出力(CSV・帳票・API)を別権限として分けられるか
- 権限一覧を自社の操作で出力できるか。出力形式は何か
- 承認フローの経路・条件を自社で設定できるか。代理承認と自動エスカレーションはあるか
- 操作ログに変更前後の値が残るか。対象操作を選べるか
- ログの保管期間と、外部ストレージへの転送手段
- システム管理者がログを編集・削除できない構成にできるか
こうした項目を漏れなく提案依頼書に落とし込む進め方は 生産管理システムのRFP作成ガイド で全体像を整理していますので、選定を控えている場合は先にそちらを参照してください。
既存システムの権限管理が弱いときの現実的な打ち手
すでに稼働しているシステムの権限機能が不十分な場合、入れ替えが唯一の答えではありません。優先順位を付けた段階的な手当てが可能です。
まず着手すべきは、費用がかからず効果が大きい順に、共有IDの廃止と個人ID化、退職者アカウントの即時停止ルールの明文化、システム管理者権限を持つ人数の削減の3つです。次に、権限一覧の定期出力を手作業でもよいので始めます。そのうえで、システム側で不足している部分、たとえばデータ範囲の絞り込みや変更前後値のログについては、データベース側のトリガーや周辺ツールで補える範囲を見極めます。最終的に補えない部分だけが、次回更新時の要件になります。
重要なのは、「今のシステムでは無理」で止めずに、無理な範囲を特定して文書に残すことです。監査で評価されるのは完璧さではなく、リスクを把握して優先順位を付けているかどうかです。
よくある質問
生産管理システムの権限設計は誰が決めるべき？
情報システム部門が単独で決めるべきものではありません。ロールとスコープの定義は業務側、つまり生産管理・購買・品質・経理の各部門が決め、情報システム部門はそれを技術的に実装可能な形へ翻訳する役割を担うのが基本形です。職務分掌の妥当性については、内部監査部門または管理部門の確認を入れます。実務上は、業務側のキーパーソンを集めた小規模なワーキンググループを作り、ロール一覧のドラフトを2週間ほどで作るところから始めるのが現実的です。
操作ログはどれくらいの期間保管すべき？
一律の年限が決まっているわけではないため、逆算で決めます。下限は自社の監査周期をカバーする長さです。年1回の内部監査を受けているなら、少なくとも直近の監査対象期間全体が残っている必要があります。そのうえで、親会社の文書保存規程、税務・会計関連書類の保存慣行、顧客との契約で求められる期間を確認し、最も長いものに合わせます。容量が問題になる場合は、全項目を長期保管するのではなく、権限変更・マスタ変更・大量出力といった重要度の高いログだけを長く残し、一般的な画面アクセス履歴は短めにするという分け方が有効です。
承認フローのシステム化はどこから着手すべきですか？
不可逆な操作から始めてください。出荷確定、在庫の除却、締め処理、マスタの単価変更といった、実行後に元へ戻せない操作です。ここに承認を置くだけで、統制上の効果の大半が得られます。逆に、日常の作業実績入力のような可逆かつ大量の操作から手を付けると、承認待ちの滞留が起きて運用が定着しません。最初のスコープは3件から5件程度に絞り、半年運用して定着を確認してから広げる進め方が確実です。
兼務が多い小規模工場でも職務分掌は必要ですか？
必要ですが、大企業と同じ形にする必要はありません。人数の制約で分離できない組み合わせがあるのは当然のことで、監査で問われるのは分離の有無ではなく、リスクを認識して手当てしているかどうかです。分離できない組み合わせを一覧化し、それぞれに代替統制を置いてください。代替統制の典型は、当該操作を全件ログに残して月次で上長または日本人管理者がレビューする、金額や数量に閾値を設けて超過分だけ別の承認者に回す、といった手当てです。この一覧と実施記録があれば、兼務そのものが指摘になることはまずありません。
まとめ
生産管理システムの権限管理は、稼働に直接影響しないために後回しにされ続け、監査や事故という形で一度に表面化します。整理すると、押さえるべき点は次のとおりです。
- リスクの本体は外部攻撃ではなく、正規に付与された権限の悪用です。 リクルートが2026年3月30日に公表した事案では、元従業員が業務上のアクセス権限を使って約20,699人分に及ぶ社内データを外部に持ち出していました。正規のIDによる操作は、権限設計と操作ログでしか区別できません
- 権限はロール・スコープ・アクションの3層で設計します。 役職に紐づける方式は必ず破綻します。とくにアクションの層では、参照と出力を別権限として分けることが持ち出し対策に直結します
- 職務分掌は、分離できない場合の代替統制まで含めて文書化します。 作成と承認を同一人物に持たせないことが基本で、人数の制約で分離できない部分は代替統制とセットで記録します
- 承認フローは紙の決裁を写さず、不可逆な操作から絞り込みます。 代理承認とエスカレーションを最初から仕様に入れないと、IDの貸し借りという最悪の回避策に到達します
- 操作ログは5項目を満たし、管理者が消せない構成にします。 誰が・いつ・何を・どうした・どこから。変更前後の値が残っているかは個別に確認が必要です
- 四半期ごとの権限棚卸しと、人事イベントを起点にした即時停止を対で回します。 タイではPDPCが5件の事案で8件、合計約21.5百万バーツの制裁金を公表しており、安全管理措置の見直し不足はすでに現実の指摘事項です
これらはいずれも、大規模な投資を伴わずに着手できる領域です。まずは現在の権限一覧を出力してみることから始めてください。出力できないのであれば、それ自体が最初の課題です。
権限設計の見直しや、生産管理システムの選定にあたっての確認項目の整理でお困りでしたら、TOMAS TECH にお気軽にご相談ください。バンコクを拠点に、タイの日系製造業へ生産管理システムPEGASUSをはじめとする現場DXソリューションを提供しており、ロール一覧の作成支援、承認フローの設計、操作ログの取得範囲の検討といった実務をお手伝いできます。まだ課題を整理している検討段階でもご相談いただけますので、お気軽にお声がけください。
