Reporting On Support


Published on

Despite IT automation and the richness of social knowledge, classifying support requests remains one of the most vexing information management problems for support organizations. Solving the problem requires a commitment to logic and to picking the right job for the tool to do, not picking the right tool to do the job.

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

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Reporting On Support

  1. 1. Narrating User Support: Tracking What Matters vs. What Counts An archestra notebook. © 2013 Malcolm Ryder / archestra
  2. 2. Support the known, study the unknown ASSUMPTIONS: • Users are involved in Production. Production is the essence of their work and why they need things. • Things that are designed well and made well usually work well when used as directed. • “Support” should always be seen as reinforcement of an intended design and behavior. • This allows intentions and designs to change, however those changes do not alter the purpose of Support. • Support presupposes that the intended design and behavior are described in authoritative references. • Unintended conditions are variances that need to be detectable and comparable against the reference. • Defects, omissions and errors are the basic intended variances within directed use. • Mis-use and ab-use are special cases that can create or exacerbate defects, omissions and errors. • Many things can be observed, tracked, and counted… but not everything that is countable matters. What matters, primarily, is the things that fit the design or that affect the fit. OBSERVATIONS: • The user effort of production also has an intended design and behavior. • As described above, user support involves infrastructure, but it is not the same as infrastructure support.
  3. 3. Rational user support systems start with respect for the expectations of IT usagethat are most consistently in the foreground. The expectations originate from varied points: engineers, operators, and IT users customers each have reasons for emphasizing some things more than others. Those parties maintain relationships with each other including expectations that need to be managed. These include plans, promotions, and presumptions that express and explain their range of activities. But sometimes they compete or conflict. © 2013 Malcolm Ryder / archestra
  4. 4. The Business view of support Value, motivations and responsibilities are built into expectations about support of IT usage. Users are aiming for certain production outcomes; providers are aiming for relevant deliveries; and supporters aim to be responsive. These aims can be logically associated to each other. User Requirements - define types of outcomes of user functions drawn from capabilities • User Functions are task-enabling abilities, such as permissions, resourcing, controls, and tracking Service Definitions - define access and activation of capabilities providing user functions • Capabilities are operational resources such as tools, apps, solutions Support Categories - define responses to demand for user function or service capability • Demands are requests for instructions, supplies, configurations, execution, repairs, and changes Actual support efforts then consistently make sense to managers in a user-centric context.
  5. 5. Itemizing the logical design of Users’ Production The proper ability for Users to leverage IT is not opportunistic, but instead is based on a design for that usage. In turn, supportability of the usage is itself based on the state of compliance to the design. Describing… Relating to… Defined as… Such as… User Requirements Outcomes User Functions Task-enabling abilities permissions, resourcing, controls, tracking Service Definitions Access and Activation Capabilities Operational resources tools, applications, solutions Support Categories Responses Demand Requests instructions, supplies, configurations, execution, changes © 2013 Malcolm Ryder / archestra Concept
  6. 6. Issue reports are not the same as Support requests. For example: an issue can go unsupported; and a request can be a desire without an issue. But requests allow anyone to “place an order” for relevant items or actions (fulfillments) that are pertinent to requirements, terms of service, or issues. Defined as… Such as… User Requirements Task-enabling abilities permissions, resourcing, controls, tracking Service Definitions Operational resources tools, applications, solutions Requests instructions, supplies, configurations, execution, changes Issues with Omissions Issues with Errors (Examples) (Examples) (Examples) (Examples) (Examples) (Examples) responses Support Categories Issues with Defects responses responses (provide or improve via fulfillment techniques) (provide or improve via fulfillment techniques) (provide or improve via fulfillment techniques) © 2013 Malcolm Ryder / archestra Concept
  7. 7. Deployment is obviously the prerequisite to the availability of IT resources. But actual deployments may not be readily apparent. Bad deployment leads to user issues. The issues reflect variations from the intended design of production. The variations are numerous, but generic. Example: Defined as… Such as… Issues with Defects User Requirements Task-enabling abilities permissions Correct setting is No setting exists not working Incorrect setting exists resourcing Correct item has a flaw Needed item is missing Incorrect item is in use controls Item is nonresponsive Control is unavailable Aftereffects are inappropriate applications Feature failure Deactivated Wrong version Service Definitions Operational resources Issues with Omissions Issues with Errors © 2013 Malcolm Ryder / archestra Concept
  8. 8. The support organization, in its responsibility to users, wants to understand its performance. Supporting a service involves matching a fulfillment technique (response) to a type of issue. Example: Defined as… Such as… Issues with Defects Issues with Omissions Issues with Errors Service Definitions Operational resources applications Feature failure Deactivated Wrong version responses responses responses supplies repair refresh upgrade configurations rebuild reset replace Support Categories Requests In providing assistance, Support organizations also need a way to associate the current experience of using infrastructure with the requirements for making infrastructure beneficial. Users may have no significant awareness of the underpinnings of infrastructure, or even if they do there may be nothing they can act on themselves. As a result, the user support organization is the user’s agent for making requests to validate or conduct infrastructure support. That is, the matchup of request fulfillments with service issues begins to correlate the user experience with the infrastructure state. A common mistake in reporting “support” is a failure to recognize that the type of association being observed and reported is correlation. The proper information system for reporting on user support should capture the users’ effort and experience, separately from infrastructure conditions, but concurrently with them. “Solving” issues with support responses may involve unknowns: trying to discover the infrastructure conditions and to determine if the correlation is a causal relationship or not. © 2013 Malcolm Ryder / archestra Concept
  9. 9. Reporting the Support The support tracking model recognizes numerous independent variables that are associated with each other within support efforts. The narrative explaining any support effort has a baseline plot. Support tracking collects and records three main events in the plot. • <User Effort> involving <desire or issue> instigated <Support Request>. • When <User Effort> was addressed with <Support Response> during <Infrastructure State>, then <Result> occurred. • <Support Response> included <Infrastructure Support> conducted to validate or adjust <Infrastructure State>. In the narrative, each variable may be rendered in more or less detail. But, compared to each other, their generic distinctions always remain the same within the narrative. They do not substitute for each other. Their independent variability means that the support information system should associate the variables as multiple dimensions of the event. Statistical insights are readily drawn from this tracking.