属性表示名の変更

概要

Change Attribute Display Name エンリッチメントは、属性の基礎となる技術的な名前やデータを変更することなく、ユーザーインターフェース上での属性の表示方法を変更します。この強力なクリーンアップオペレーターは、技術的な属性名と業務上分かりやすいラベルとの間に重要な抽象化レイヤーを提供し、基礎データ構造の整合性を保ちながら、ビジネスユーザーにとって意味のある表現でデータを提示できるようにします。このエンリッチメントはメタデータレベルで動作し、選択した属性列の表示プロパティのみを更新します。

このエンリッチメントは、技術的またはシステム生成の属性名を、関係者が即座に理解できる明確な業務指向の用語に変換するために不可欠です。たとえば、「PO_AMT_USD」や「CUST_ID_001」のような技術的名称の属性を「Purchase Order Amount」や「Customer ID」として表現し、可読性を向上させる必要がある場合です。Change Attribute Display Name エンリッチメントはこの変換をシームレスに行い、基礎データモデルを変更したり、元の属性名を参照しているフィルターや計算式、他のエンリッチメントを壊したりすることなく、プロセスマイニング解析の使いやすさを向上させます。

主な用途

  • 技術的なデータベースの列名をレポートやダッシュボード向けに業務に適したラベルに変換する
  • 結合データセット内の異なるデータソース間で属性命名規則を標準化する
  • 国際化を実施し、グローバルチーム向けに表示名を異なる言語に変更する
  • 同じ属性が異なるプロセスで異なる意味を持つ場合に、文脈に応じたラベルを付ける
  • 他のエンリッチメントや計算式で自動生成された属性の可読性を向上させる
  • 企業の用語基準やビジネス用語集と属性名を整合させる
  • システム生成の難解なフィールド名を非技術ユーザーにも理解可能にする

設定

Attribute Name: 表示名を変更したい属性を選択します。ドロップダウンリストには、計算フィールドや非表示属性を除いた、データセット内の利用可能なすべてのケース属性が表示されます。これにより、実際にデータに保存されている属性のみが変更の対象となります。ここで選択した属性の表示プロパティが更新されます。

New Attribute Display Name: 選択した属性の新しい表示名を入力します。これはmindzieStudioのすべてのユーザーインターフェース、レポート、ビジュアライゼーションに表示される名前です。新しい名前は明確で説明的であり、組織の命名規則に従うべきです。使用可能な文字には制限がなく、スペースや特殊文字、国際化のためのユニコード文字も含めることができます。表示名は属性の意味を十分に表現できる長さに設定できます。

例 1: 購買注文システム連携

シナリオ: ERP システムからデータをインポートした後、「PO_HDR_CRDT」「VNDR_CODE」「APPR_STATUS」のような技術的データベース名の属性が、調達プロセスを確認するビジネスアナリストにとって理解しやすい形にする必要がある。

設定:

  • Attribute Name: PO_HDR_CRDT
  • New Attribute Display Name: Purchase Order Creation Date

結果: 「PO_HDR_CRDT」属性は、すべてのビュー、フィルター、レポートで「Purchase Order Creation Date」と表示されます。基礎のデータや技術名は変更されず、既存の設定との互換性が維持されます。

効果: 業務ユーザーは専門的な略語を理解することなく作成日フィールドを簡単に識別でき、トレーニング時間の短縮とセルフサービス分析の促進が期待できます。

例 2: グローバルチーム向け多言語サポート

シナリオ: 多国籍企業が、同一プロセスデータを各国のチームに提示するため、基礎データセットは1つのままローカル言語での属性名表示を求めている。

設定:

  • Attribute Name: Customer_Region
  • New Attribute Display Name: Region Cliente (Spanish)

結果: スペイン語版の解析では、「Region Cliente」と表示され、スペイン語を話すメンバーにとって即座に理解可能になる。技術名「Customer_Region」はシステム操作上変更されません。

効果: 各地域別チームがそれぞれ慣れ親しんだ用語で同一データセットを扱えるようになり、コラボレーションの向上と誤解の低減に貢献します。

例 3: 医療請求処理

シナリオ: 医療請求プロセスで、「ICD10_PRIM」「DRG_CODE」「CPT_MOD」のような医療コード属性が、医療コードの略語に不慣れな請求アナリストに分かりやすい名前で表示される必要がある。

設定:

  • Attribute Name: ICD10_PRIM
  • New Attribute Display Name: Primary Diagnosis Code (ICD-10)

結果: 難解な「ICD10_PRIM」フィールドは「Primary Diagnosis Code (ICD-10)」と表示され、その属性の目的と使用されるコーディングシステムの説明を提供する。

効果: 請求アナリストは技術的な略語を覚えることなく診断情報をすばやく識別でき、請求審査の迅速化とデータ解釈ミスの減少につながります。

例 4: 財務照合プロセス

シナリオ: 複数の財務システムからデータを統合した後、「AMT_USD」や「TransactionAmount」のように異なる命名規則の類似属性を一貫した表示に統一する必要がある。

設定:

  • Attribute Name: AMT_USD
  • New Attribute Display Name: Transaction Amount (USD)

結果: 「AMT_USD」と「TransactionAmount」の表示名変更により、すべての金銭的フィールドが通貨を明示した一貫した命名パターンとなり、データ解釈の精度が向上。

効果: 統合データセットでの標準化した表示名により混乱が減り、特に多通貨取引の正確な財務分析が可能になります。

例 5: 製造品質管理

シナリオ: 品質管理プロセスで、「TEMP_S1_AVG」「PRES_S2_MAX」「VISC_S3_STD」のようなセンサー生成属性が、生産データをレビューする品質エンジニアに分かりやすい名前で表示される必要がある。

設定:

  • Attribute Name: TEMP_S1_AVG
  • New Attribute Display Name: Average Temperature - Sensor 1

結果: 技術的なセンサー読み取りコード「TEMP_S1_AVG」が「Average Temperature - Sensor 1」と明確に表示され、品質レポートで直感的に理解可能に。

効果: 品質エンジニアはどのセンサーの読み取り値かを素早く特定でき、センサーのドキュメントを参照する手間なく品質問題の根本原因分析を効率化できます。

出力

Change Attribute Display Name エンリッチメントは、新しい属性を作成したり基礎データを変更したりせず、選択された属性の表示メタデータのみを変更します。元の属性の技術名は変更されず、既存の設定、フィルター、計算式で引き続き機能します。新しい表示名は以下のユーザーインターフェース要素に即座に反映されます。

  • フィルターや計算式の属性選択ドロップダウン
  • データビューやケースエクスプローラーの列ヘッダー
  • チャートやビジュアライゼーションの軸ラベル
  • エクスポートされたレポートのフィールド名
  • エンリッチメント構成内の属性リスト

この変更は永続的に有効で、今後の全解析セッションにわたり維持されます。ただし、数式、スクリプト、API呼び出し内の属性参照は元の技術名を使い続ける必要があります。表示名と技術名の分離により、後方互換性を保ちつつ使いやすさを向上させています。

関連項目

  • Rename Activity - イベントログ内のアクティビティ名を変更する
  • Replace Text in Attribute - 表示名ではなく実際の属性値を変更する
  • Trim Text - 属性値の前後のスペースを除去してクリーンアップする
  • Upper Case Attribute - テキスト属性値を大文字に統一する
  • Hide Attribute - 属性を削除せず表示から非表示にする

このドキュメントはmindzie Studio プロセスマイニングプラットフォームの一部です。