Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Taxonomy Governance Through Metrics


Published on

Understand what Governance Is
We start with a definition of governance, its constituent parts, and their purpose

Identify Core Taxonomy Governance Processes
There are certain functions that any governance effort must perform . We show how these apply to taxonomy governance, and why

Identify Standard Processes and Tools
Business and supporting IT organizations already perform tasks that are in many ways similar to those needed for successful taxonomy governance. To minimize new investment in tools and training, it makes sense to use these where possible

Tricks of the Trade
We’ll show some of the detailed considerations that are important when setting up a taxonomy governance effort, and how we’ve handled them

We’ll discuss how taxonomy governance fits in the broader operational context of an organization: specifically, how it connects with an IT organization and with business stakeholders

Published in: Technology, Business
  • Be the first to comment

Taxonomy Governance Through Metrics

  1. 1. Taxonomy Governance Through Metrics, Existing Tools & Process November 09, 2007 @ 10:00am Taxonomy Bootcamp, 2007 Alex Barnes Tom Witczak
  2. 2. Session Objectives • Understand what Governance Is • Understand its Context • Identify Core Taxonomy Governance Processes • Identify Standard Processes and Tools • Tips and Tricks for Governance 2 ©2007 Hitachi Consulting. All Rights Reserved.
  3. 3. Taxonomy Feedback Loop Executive Sponsors form Strategy and Objectives that are driven by metrics and business objectives Feedback and Requests for Change are captured through periodic review, usability testing and feedback Front End: Applications Published Updates Versions Taxonomy Model Taxonomy Back End: Taxonomy Taxonomy Management Control and Publishing Users Taxonomy Change Control Execution is driven by approved change requests 3 ©2007 Hitachi Consulting. All Rights Reserved.
  4. 4. Definitions Governance is the management of a system, usually political or Organizational organizational, involving mutual Structure adjustment, negotiation, and accommodation between the parties Taxonomy involved rather than direct control. — Webster’s Practices, Standards & Processes & Measures Procedures Taxonomy Governance defines: Tools and Solutions • Organizational Structure • Processes and Procedures • Practices, Standards and Goals are to define a repeatable, Measures visible, accountable, process for submission, review, approval and dissemination of taxonomy changes. 4 ©2007 Hitachi Consulting. All Rights Reserved.
  5. 5. Components Processes and Procedures • Steps taken when performing taxonomy governance tasks Processes & Procedures • “How-to” view of taxonomy governance Organizational Structure • Structure, membership, accountabilities, organizations involved • Who in the organization is responsible for each Organizational Structure aspect of taxonomy governance and how delegations and escalations are carried out Practices, Standards & Measures • What will be done Practices, • How it will be controlled and monitored Standards & Measures Tools and Solutions • What existing tools or solutions can be used Tools and Solutions • How can they be integrated and leveraged 5 ©2007 Hitachi Consulting. All Rights Reserved.
  6. 6. Core Operational Processes Request and Track Taxonomy Changes Request Fix & Commun- • Change request and status visibility & Track Assess Control Validate icate • Track changes thorough various lifecycle stages, start to finish Assess the Impact of Change observed defect observed fix • Assess the validity of change requests • Impact of the requested change on Validate Taxonomy Change taxonomy, consuming systems and processes • Continually validate with end users for consistency and usability. • Effort required to implement a change • Can be analysis, scripted tests with Fix and Control the Taxonomy automated tools, or contextual inquiry with Baseline representative user populations. • Consuming systems should know • Must identify the appropriate validation content of the taxonomy, its ownership, method and coordinate verification efforts change history, and any relationships Communicate Taxonomy Change to downstream systems and processes. • Consumers need to know the change, the reason for change, known impacts, related • Implies administrative metadata, changes, and their timing versioning, knowledge of the context in which the taxonomy is used 6 ©2007 Hitachi Consulting. All Rights Reserved.
  7. 7. Organizational Structure R Responsible A Accountable C Consulted I Informed A Executive Sponsors meet quarterly to review summary Executive Sponsors taxonomy metrics and analysis results, and to define and refine strategy Business Unit Leadership Business Unit Leadership team meets monthly to BU Taxonomy Owners Support Team R review/ prioritize requests for taxonomy change; to plan training, communications, and strategy; and to •Control/Approve Changes •Coordinate Changes in approve release and versioning plans •Dependent Systems Day-to-Day Taxonomy Management Coordinates with the Business Unit Taxonomy Owners Taxonomy Librarian Operations R as needed (generally online rather than face-to-face) to assure compliance with processes and to plan the •Administer Taxonomy •Content Admin content and timing of taxonomy releases •Solution Admin Execute processes, receive training, and recommend System Users I taxonomy changes to the Taxonomy Librarian Layered Model Thresholds It is important to define a structure that separates policy and Escalation between layers is controlled by policies that define the strategic direction, operational coordination, and day-to-day thresholds for communication, and what the content of the management and operations. communications should be. This will vary widely from one organization to another. 7 ©2007 Hitachi Consulting. All Rights Reserved.
  8. 8. Governance Responsibilities Define Objectives Strategy • For the taxonomy, its intended use, and how it supports the organization’s strategic goals Change Management Planning Manage Change Requests Manage Manage • Who are responsible parties for change requests, Change Taxonomy Coordinate Changes maintenance and changes of the taxonomy Requests Baseline • Define the tools and processes to manage change Communication • Define and track metrics on the performance of the process Manage the Taxonomy Baseline • Who maintains the current model of the taxonomy Communicate with Stakeholders • Notify Consumers of intended changes and • Processes for reassignment of taxonomy current state of the taxonomy – stakeholders components and whom should reassign them may want to browse or query the taxonomy, Coordinate Change in Related Systems receive notification of planned changes • Other systems and processes can be impacted – Plan and Prioritize coordinate change to the consuming systems and • Define the criteria for prioritizing requested processes changes; who decides on priorities, and escalation processes in case of disputes 8 ©2007 Hitachi Consulting. All Rights Reserved.
  9. 9. Delegated Management Delegate Disposition It’s not feasible for all taxonomy changes to Item Action Member Action Closed No-Action be channeled through a single individual or group. Listing Removal Auction Restart Flag Item Warning Suspension Reinstatement Flag Member Billing Action Investigate Governance bodies should delegate Bid Retraction Bid Retraction Move Item Account Closure Account Linking Member ownership of the representative context of a Suspension taxonomy and how changes to the parts are Warning Policy Warning VeRO Warning Support Warning Safety Alert Adjustment Collection made without compromising the overall Indefinite Suspension Temporary Suspension structure. 30-day 90-Day Suspension Suspension Standards • Ownership and Reassignment Organization A • Structural Norms and Naming Organization B Conventions Organization C Organization D • Versioning Criteria • Validation and Testing • Periodic Review and QA 9 ©2007 Hitachi Consulting. All Rights Reserved.
  10. 10. Practices, Standards and Measures Policies are a plan of action that guides decisions and practices based on stated objectives and Policy strategies. Practices are requirements that establish guidelines for all business Practices units and aligns with defined policies. Standards are specifications that Standards Business Unit Business Unit Business Unit Business Unit Business Unit details how to fulfill the practice; and what is done? how often? Measures Measures are numbers or percentages that illustrate how well a practice is fulfilled. 10 ©2007 Hitachi Consulting. All Rights Reserved.
  11. 11. Metrics Metrics can be gathered at each Real-time metrics stage of the taxonomy life cycle, by the • Usage volumes by: business unit and/or by dedicated –User segment taxonomy support staff. –Channel Metrics can improve: –Geography • Taxonomy and Information Architecture: –Facet – Elimination of ambiguity • Taxonomy usage: – Identification of new taxa –Taxa that are never used – Removal of redundant taxa –“None of the above” responses –Search statistics – Improved controlled vocabularies (labels and synonyms) • Taxonomy change request process Analytics • User experience in both taxonomy • Accuracy of categorization (% of categorizations management tools and the operational that are corrected in a later stage) use • Abandonment rate • Identification of consistent patterns of • Taxonomy change request statistics issue, root cause, and change • Taxonomy defect metrics resolution to enable automated • Usability test results change resolution 11 ©2007 Hitachi Consulting. All Rights Reserved.
  12. 12. Use the Existing Tools Many of the goals and techniques of taxonomy governance are common to other IT and data Source Mgmt. governance methods. It’s better to reuse existing tools rather than build or buy new ones. The learning curve is shorter and the costs are lower. Taxonomy Lifecycle Model Workflow Bug Tracking • A taxonomy’s lifecycle is similar to that of standard software change request processes. Baseline Control • A taxonomy, just like code, should be Capturing Feedback controlled and versioned. • Both “suggest new content” forms, customer- Branching and Forking service ticket-trackers and bug-tracker tools can be used to capture user requests for • Ability to maintain concurrent models in change. different states is common to many source control systems. Release Planning The Draft/Review/Publish Model • Existing project portfolio management systems often include version description • Existing systems already have workflows that and release-planning functions. can be reused to control publication and notification of changes. 12 ©2007 Hitachi Consulting. All Rights Reserved.
  13. 13. Tool Requirements Modeling Essential features: • Web access • Ability to delegate ownership Model Publish • Versioning capability, both coarse and fine- Change grained • Rollback • Flexible taxonomy metadata model (administrative and engineering) • Change history– traceability of changes to Change Request Tracking CR Must have: Publication • Ability for end users to report issues and see resolution status Must have: • Resolution workflow • Integration with model • Integration to model • Integration with change request solution Should have: • Version description/release notes capability • Notification • Flexibility in publication format (DB dump, XML) • Metrics capture and reporting 13 ©2007 Hitachi Consulting. All Rights Reserved.
  14. 14. Summary You now should understand Taxonomy Governance: • Processes and Procedures • Organizational Structure • Practices, Standards & Measures • Tools and Solutions You now should understand its context: • Taxonomy exists to support organizational goals and their supporting business functions. As such, a taxonomy governance model is needed. You should be able to identify core taxonomy governance processes: • Not much is unique to taxonomy governance, as it resembles similar governance processes (data, code, etc.). Identify Standard Processes and Tools: • Many opportunities for reuse with existing solutions; adoption is better with reuse. Tips and Tricks for Governance: • For more info, see appendices. 14 ©2007 Hitachi Consulting. All Rights Reserved.
  15. 15. Questions? Alex Barnes Tom Witczak Senior Architect Senior Consultant Hitachi Consulting Hitachi Consulting Mobile: 415.297.0712 Mobile: 415.412.2915 Inspiring your next success! ® Inspiring your next success! ® 15 ©2007 Hitachi Consulting. All Rights Reserved.
  16. 16. Appendices A. Integrations B. Organizational Change Management C. Taxonomy Defect Types
  17. 17. Integration with Process & Workflow Process Analysis Framework Taxonomy does not exist in isolation. It should be informed by a process analysis framework: a model that is used to understand key business processes. It will serve to interpret as-is processes and to scope subsequent process development iterations. Developing a process framework is an activity outside the scope of taxonomy governance. It requires a coordinated, global effort touching upon several facets of business process management. These components include: formulating a consistent strategic view of processes, mapping current state processes, assessment and prioritization of processes, establishing development and modeling standards, process governance, and finally process management. Supporting the framework are the technologies, such as orchestration, infrastructure and how processes are realized and presented to the user. The process framework, as it is executed, will yield requests for taxonomy change, potentially including the identification of new taxonomic facets. If the process framework includes elements of participatory The taxonomy is exposed within the process framework design, valuable stakeholders will actively contribute their through taxonomic views that are task-specific. By some knowledge to the process models, translating to increased definitions, these taxonomic views are regarded as part of end user adoption of the solution. the information architecture of the solution. 17 ©2007 Hitachi Consulting. All Rights Reserved.
  18. 18. Integration with Consuming Systems Dependencies Taxonomy is seldom exposed directly on a user interface. Instead, task- specific views of the taxonomy are shown to the user. These may have a structure that is significantly different than that of the underlying System A taxonomy: for example, a node may have multiple parents on the UI. Load time But it is important that traceability is maintained between the taxonomic views and the underlying taxonomy, so that changes to the taxonomy lead to changes in the user experience. Taxonomic views may be surfaced in a number of ways: • Navigation Real time • Workflow/routing Taxonomy System B • Filtering Compile time Along with the hierarchical relationships depicted in the taxonomy, user interfaces (and system behavior) may also be responsive to frequency- of-use considerations. This frequency-of-use data must be measured by observation of system usage, and can be tracked as additional metadata on taxonomy nodes. Binding System C Different systems consume taxonomy in different ways: • Realtime: the system looks at, and responds to, the current taxonomy as it is needed, on a case-by-case basis • Load time: the system is initialized with a snapshot of the taxonomy at the time it is started Coordinating Change • Compile time: the system is built in a way that incorporates knowledge • Metadata should exist in the taxonomy model to reflect these of the taxonomy differences in the impact of taxonomy changes on consuming systems While realtime binding is a desirable design goal, most systems are not and processes this adaptable to taxonomy changes. • When a taxonomy update is published, it must be synchronized with changes to systems and processes that are sensitive to that part of the In addition, business processes are also sensitive to taxonomy: taxonomy • Categorization processes • Metrics Like systems, processes respond to taxonomy changes with varying lag times and varying costs of change 18 ©2007 Hitachi Consulting. All Rights Reserved.
  19. 19. Organizational Change Management Approach The key to a successful transition from the legacy state to the new taxonomy governance model is to: • Understand the Organizational Landscape and develop an a change management approach consistent with the organization’s needs • Establish and support Leadership and Stakeholder Commitment to actively lead the initiative • Develop an effective Learning strategy that educates the organization on new processes and functionality from the system and also builds enthusiasm, adoption and skills in stakeholders through exceptional training. • Creation and execution of an effective Communication plan that delivers the right message to the right person at the right time. The goal of OCM is to assist and drive the following key activities to project success: Key Work Products • Methodology adoption by BU, tech team, and SMEs • OCM risk diagnostic • Management Model • Definition of critical success factors • Appropriate analysis of the stakeholder landscape • Stakeholder analysis • Training Approach • Definition and execution of the communication plan to • Champion Framework • Communication plan inform all relevant stakeholders and stakeholder groups • Channel assessment • Leadership Action Plans • Communication with involved groups to make sure SME’s are aware of tasks and complete tasks on time 19 ©2007 Hitachi Consulting. All Rights Reserved.
  20. 20. Taxonomy Defect Types As analysis is performed on Taxonomy Change Requests, they must be categorized. This determines resolution workflow, and provides a basis for ongoing measurement of taxonomy quality. A change request can be tagged with one or more defect types. These codes are based on software engineering and data quality defect codes. Code Definition Completeness/Consistency This category of taxonomy defects is for incomplete (missing child nodes) or inconsistent (conflicts with, duplicates or overlaps with other nodes) nodes. Incomplete Not all of the node’s child nodes are specified. Conflicting The node wholly or partially conflicts with another node. Wrong parent The node is placed incorrectly in the hierarchy. Duplicate The node is the same as all or part of another node (not mutually exclusive). No Longer Required There is no longer a business requirement for the node to exist. Missing A required node is not present. Correctness This category includes defect codes for nodes that are incorrect, unverifiable or cannot be implemented. Incorrect (Not a Node) The requirement for the node is logically flawed, or is not needed to support the business process. Ambiguous The definition is ambiguous. Dimensional Problem The node or nodes are repeated due to dimensional problems with the hierarchy. 20 ©2007 Hitachi Consulting. All Rights Reserved.
  21. 21. Taxonomy Defect Codes, cont’d. Code Definition Presentation/Style This category includes taxonomy defects of an editorial nature. Unclear Wording The wording of the definition or label is difficult to understand. Typo/Grammar The definition or label has spelling, typographical or grammatical errors. External Taxonomy This category includes defect codes for changes introduced by an external change control Change process in response to changing business requirements or project scope. New A new node (or nodes) has been added. Modify An existing node (or nodes) is to be modified. Delete An existing node (or nodes) is to be deleted. Miscellaneous This category includes other taxonomy changes. Changes Synonym A taxonomy node is identified by, or searchable by, more than one name. Not a Node The node should not be in the taxonomy at all. Update Metadata Change administrative metadata (ownership, related systems, etc) for a node. 21 ©2007 Hitachi Consulting. All Rights Reserved.