Article body
Full article
Summary: Metrics, dashboards, and data-Q&A scenarios grow with the business. What is difficult to govern is usually not their count, but differences in definitions behind identically named metrics, applications left without an owner after an employee departs, dashboards changed but not republished, and low-frequency assets that still serve seasonal operations or compliance audits. Teams need to operate them as a portfolio that can be inventoried, verified, and dispositioned.
An inventory needs to answer five questions: who owns the asset, what its definition and purpose are, which data and downstream objects it depends on, who uses it and in what scope, and who will make the next decision to retain, revise, consolidate, transfer, or retire it. HENGSHI product capabilities can provide part of the facts and operating entry points; trade-offs, retention periods, and benefit accounting still need to be jointly owned by business and data teams.
1. Treat BI as an asset portfolio, not an object list
Many teams begin by “cleaning up low-traffic dashboards,” which can easily harm low-frequency use cases such as quarterly operating reviews, holiday staffing, and audit evidence. Visit counts can be a signal for review, but cannot alone justify deletion. A metric that is not opened directly may still be referenced by downstream charts, data integrations, or applications; a dashboard no one viewed this month may be needed in the next settlement cycle.
During inventory, put atomic metrics, business metrics, charts and dashboards, applications published to the app marketplace, and data-Q&A scenarios serving fixed questions into the same register. For every item, record at least the owner, business subject, definition, upstream source, downstream references, visibility scope, most recent business confirmation, and next review date. The register combines object facts available in the product with business-side purpose, accountability, and disposition records, and is maintained by the team.
Gartner’s data-quality topic page cites 2020 research stating that poor data quality costs organizations an average of at least USD 12.9 million per year. This is research context, not a loss rate for any individual enterprise, and it cannot be used to infer a benefit forecast for a HENGSHI project. The value of asset operations should be calculated from the same business cycle, the same scope, and reviewable records within the enterprise itself.
2. Use one register to separate identical names from duplication
Consider an asset inventory for a chain service company. Customer operations, membership, and finance teams all use the term “repeat-purchase rate,” but they may calculate it respectively by paying customers, renewing members, and invoiced customers, with different time windows. Combining the three under one name may look simple, but it hides differences that need explanation. First separate the business definitions, then decide whether true duplicate assets exist.
| Inventory item | Evidence to check | Example disposition |
|---|---|---|
| Repeat-purchase rate: proportion of customers who pay again within 90 days | Customer entity, 90-day window, payment-time field, refund treatment, and charts that reference it | Retain; state the definition in its aliases and description, and place it in the “Customer Operations” group |
| Repeat-purchase rate: proportion of members who renew after expiry | Membership-expiry scope, renewal determination, observation period, and owner confirmation | Retain as an independent metric; do not force consolidation because of the identical name |
| Quarterly membership-operations dashboard | Which of the above metrics it uses, published version, viewing scope, and records of quarterly meetings or audits using it | If the definition has changed in the authoring area, republish after review; retain low-frequency use and mark its review date |
| Old monthly dashboard | Whether it has no downstream references, whether a replacement version exists, and whether the owner agrees to retire it | Record the disposition recommendation first; if it is published and the owner agrees, unpublish it, then decide on deletion after the retention period ends |
The register does not need to complete every historical object at once. Start with high-frequency business subjects, metrics with frequent definition disputes, and owners about to hand over responsibility. Processing a small group of clearly bounded assets each time makes it easier for owners to give actionable confirmation.
3. Let product capabilities provide facts and team processes make disposition decisions
In metric management, teams can maintain metric aliases, descriptions, groups, and definitions. Before deleting a metric, the system checks whether other metrics or charts reference it and shows related resources when references exist; a metric with no references cannot be recovered after deletion. These capabilities are appropriate for first confirming what an asset is and who uses it. They must not be read as the system automatically deciding whether a metric should be retired.
The metric marketplace can show metric definitions, lineage, and display information, and can be filtered by dataset, creator, and group. Using a metric requires permission for its business subject. Recording the business-subject administrator, metric owner, and access scope in the register lets a handover identify whom to ask for confirmation and prevents “cannot find it” from being mistaken for “nobody uses it.”
Managers or editors with the appropriate permissions can use data lineage to inspect upstream datasets, downstream datasets, and affected charts, data integrations, and data models. This view is not available to application viewers or tenant users, so ordinary viewers cannot be expected to perform impact checks. Lineage does not replace business confirmation either: it shows technical reference relationships, while the owner still needs to decide whether seasonal or compliance use should be retained.
After a dashboard enters the app marketplace, it becomes a published snapshot. Later changes in the authoring area do not automatically change the published application; it must be republished to update it. Update plans can also be set separately for the published area and the authoring area, and a default publication does not overwrite an existing marketplace plan. Every inventory cycle should check four items: “authoring version, published version, update plan, and visibility scope.” This avoids users continuing to see an old definition or treating two plans as one.
| Review stage | Facts or operations HENGSHI can provide | Judgment the team must make |
|---|---|---|
| Identification | Metric descriptions, groups, definitions, and business subjects; application publication information | Complete records for owner, business purpose, retention period, and visibility scope |
| Impact check | Reference checks when deleting metrics; lineage and affected objects visible to authorized users | Confirm downstream dependencies and seasonal or compliance uses; consult the owner |
| Change | Edit the metric; modify the authoring area and republish the application | Confirm whether the definition changed, who accepts it, and when users are notified |
| Closeout | Unpublishing removes an application from the app marketplace; system administrators can transfer resource ownership or delete resources | Record the replacement asset, retention arrangement, and deletion approval; do not use low traffic as the sole condition |
4. An executable quarterly operating cadence
Data-Q&A scenarios also require inventory. For example, for “Which stores have a 90-day repeat-purchase rate below target?”, the scenario owner should record the approved metric, related dataset, permitted store scope, comparison baseline, update time, and who confirms the answer. If multiple departments ask differently but use the same definition, they can reuse the same metric and knowledge description; if customer scope or observation window differs, retain separate scenarios. HENGSHI Data Agent supports documenting business rules and terminology in dataset knowledge, where teams can capture confirmed explanations. Saving a few successful conversations cannot replace maintaining the underlying definitions and usage scope.
In the first week, the data owner sets the scope for this inventory cycle and prepares the register, flagging objects missing an owner, description, group, or review date. In the second week, business owners confirm definitions, use cases, and retention requirements. In the third week, authorized managers check references and lineage, and verify the published snapshot and update plans on both sides of the app marketplace. Only in the final week does disposition begin: retain, add documentation, establish a replacement relationship, transfer ownership, or unpublish.
For metrics that are truly duplicates, compare their calculation definitions, datasets, time fields, filters, display formats, and downstream use item by item. Only when these conditions and their business semantics are all the same may the team designate one as the retained version, after first moving users to that version. Identically named metrics with different definitions should receive distinguishable aliases and descriptions. If an owner leaves, a system administrator can transfer ownership of supported resources through resource management; the new owner must still reconfirm business accountability after transfer.
For assets that temporarily no longer serve daily operations, consider “archived” as a management state in the register: record the reason, replacement, owner, restoration conditions, and next review date. The team must maintain this management state. Suspending a service, unpublishing, and deleting have different effects and should be selected for the intended disposition. Before deletion, still check references, consult the owner, and follow the enterprise’s audit and retention policies.
5. Measure inputs and outputs with the same definition
Operating effectiveness can be evaluated with three types of evidence: whether frequent questions have shifted to reuse defined metrics; how many published applications complete review and republication within the agreed time after a definition change; and how many assets complete owner and dependency confirmation before handover or retirement. To estimate return on investment, compare governance effort, migration labor, and maintenance cost with attributable savings or avoided rework from the same period and business scope.
The same benefit must not be counted simultaneously in metric governance, dashboard revision, and data-Q&A rollout; benefits that have not happened must not be recorded early at their forecast value. Visit volume, favorite counts, or publication counts can show adoption, but cannot alone prove business return. Teams should write the calculation scope, source records, and exclusions into the retrospective so seasonal variation, parallel projects, and duplicate counting are not attributed to BI asset operations.
The point of continuously operating BI assets is to give every metric, dashboard, and data-Q&A scenario a clear definition, owner, dependency relationship, and basis for disposition. Establish its purpose and impact before discussing retention, consolidation, transfer, or retirement. This reduces definition confusion while preserving low-frequency business and compliance capabilities that are still necessary.