Performance Management of IT Service Processes Using a Mashup-based Approach - Thesis presentation
Hypothesis: The employment of mashups enhances the performance of human-centered ITSM processes
Performance Management of IT Service Processes Using a Mashup-based Approach
1. PERFORMANCE MANAGEMENT OF IT
SERVICE PROCESSES USING A
MASHUP-BASED APPROACH
Carlos Raniery Paula dos Santos
Supervisor: Lisandro Zambenedetti Granville
Thesis defense – June13rd, 2013
4. • The increasing complexity and importance of IT
environments have been leading researchers to pay
more attention to the ITSM area
• Several management frameworks have then been
conceived to help IT service providers towards a
coherent service management experience
1
4
INTRODUCTION
CONTEXTUALIZATION
5. • In a service management operation the presence of
humans in the critical path for performing work
degrades performance and quality of services
• Due to its unpredictable nature, enforcing and
obtaining tight performance bounds in a human-
staffed organization is burdensome task
5
1INTRODUCTION
PROBLEM STATEMENT
6. • Automation of IT operations has been of attention
for the last two decades
– Ideally, a system should be self-managed without any
human intervention
• May not be feasible in some cases because of
additional effort to deploy and maintain the
automation infrastructure
– Specially when processes are constantly changing, are
too complex to be automated, or have a limited lifetime
6
1INTRODUCTION
CURRENT SOLUTIONS
7. • Mashups are Web applications composed from pre-
existing Web resources (e.g., interactive maps, Web
services, traditional HTML pages)
• Mashups can be composed by users with limited or
no programming skills, to create their own Web
applications
– Basic operators are employed to hide, from mashup end-
users, technical details from the composition
7
1INTRODUCTION
MASHUPS
9. 9
Q I. What are the major causes for a poor performance in the execution of IT Service
Management processes?
Hypothesis: The employment of mashups enhances the performance of
human-centered ITSM processes
1INTRODUCTION
HYPOTHESIS AND FUNDAMENTAL QUESTIONS
Q II. What methods could be employed in the development of mashups aiming at
performance enhancement?
Q III. How models available in the literature can be used to assess performance
improvements obtained with mashups?
10. 10
Q I. What are the major causes for a poor performance in the execution of IT Service
Management processes?
Hypothesis: The employment of mashups enhances the performance of
human-centered ITSM processes
1INTRODUCTION
HYPOTHESIS AND FUNDAMENTAL QUESTIONS
Q II. What methods could be employed in the development of mashups aiming at
performance enhancement?
Q III. How models available in the literature can be used to assess performance
improvements obtained with mashups?
11. 11
Hypothesis: The employment of mashups enhances the performance of
human-centered ITSM processes
1INTRODUCTION
HYPOTHESIS AND FUNDAMENTAL QUESTIONS
Q I. What are the major causes for a poor performance in the execution of IT Service
Management processes?
Q II. What methods could be employed in the development of mashups aiming at
performance enhancement?
Q III. How models available in the literature can be used to assess performance
improvements obtained with mashups?
12. 12
Hypothesis: The employment of mashups enhances the performance of
human-centered ITSM processes
1INTRODUCTION
HYPOTHESIS AND FUNDAMENTAL QUESTIONS
Q III. How models available in the literature can be used to assess performance
improvements obtained with mashups?
Q II. What methods could be employed in the development of mashups aiming at
performance enhancement?
Q I. What are the major causes for a poor performance in the execution of IT Service
Management processes?
14. A service is a means of delivering value to customers
by facilitating outcomes customers want to achieve
without the ownership of specific costs and risks
Boundaries of the Investigation
ITSM Scenario
2
14
Supplier CustomerService
Definition
15. Boundaries of the Investigation
ITSM Scenario
2
15
Supplier CustomerService
Service
Strategy
Service
Design
Service
Transition
Service
Operation
16. Boundaries of the Investigation
Investigated ITSM Process
2
16
Supplier CustomerService
Service
Strategy
Service
Design
Service
Transition
Service
Operation
Functions
• IT Operations
Management
• Application Management
• Technical management
• Service Desk
Processes
• Event Management
• Access Management
• Problem Management
• Incident Management
• Request Fulfillment
17. Boundaries of the Investigation
Investigated ITSM Process
2
17
Supplier CustomerService
Service
Strategy
Service
Design
Service
Transition
Service
Operation
Functions
• IT Operations
Management
• Application Management
• Technical management
• Service Desk
Processes
• Event Management
• Access Management
• Problem Management
• Incident Management
• Request Fulfillment
18. Boundaries of the Investigation
Investigated ITSM Process
2
18
Supplier CustomerService
Service
Strategy
Service
Design
Service
Transition
Service
Operation
Request Fulfillment
Dispatcher System Administrators
Requests
19. Boundaries of the Investigation
Investigated ITSM Process
2
19
Supplier CustomerService
Service
Strategy
Service
Design
Service
Transition
Service
Operation
Request Fulfillment
Dispatcher System Administrators
Requests
20. • Human behavior and performance are difficult to
model, and consequently, to optimize
• Even if the nature of work is exactly the same, a
human may execute it in a different way each time
– Interrupted by external factors
– Usually employ different systems
– Execute multiple and complex tasks
– May be overloaded
Boundaries of the Investigation
Performance
2
20
21. • When the natural limits are reached or exceeded,
human operators can become:
– A bottleneck, slowing down the process execution
– Even more error-prone
Boundaries of the Investigation
Performance
2
21
Units of work performed per unit of time
Productivity
Non-defective units at the output of the process
Reliability
22. • When the natural limits are reached or exceeded,
human operators can become:
– A bottleneck, slowing down the process execution
– Even more error-prone
Boundaries of the Investigation
Performance
2
22
Units of work performed per unit of time
Productivity
Non-defective units at the output of the process
Reliability
23. • When the natural limits are reached or exceeded,
human operators can become:
– A bottleneck, slowing down the process execution
– Even more error-prone
Boundaries of the Investigation
Performance
2
23
Units of work performed per unit of time
Productivity
Non-defective units at the output of the process
Reliability
24. • The focus is on steps that can be measured through
instrumentation or observation, and can be
improved through redesign and partial automation
• The performance analysis covers the steps that a
human follows to execute ITSM processes
• The unpredictable nature of external events that
affect human behavior is not addressed
Boundaries of the Investigation
Performance
2
24
26. • Inefficiencies are portions of a service management
process characterized by suboptimal execution of
activities
• They can appear at different levels of analysis
– Lower level: inefficiencies due to the mechanical
execution involved in performing the activity
– Higher level: inefficiencies due to the complexity of the
activity itself
PRODUCTIVITY
INEFFICIENCIES
3
27. • We collected descriptions of the tasks performed by
a group of operators involved in a common activity
and analyzed both levels of inefficiencies
– Basic: context-switching, locating data, entering data
– Information Management: copy/paste, consistency
checks, information lookups
– Skill-dependent: retaining information, combining
information, data transformation
– Synchronization: contacting a person, becoming aware
PRODUCTIVITY
INEFFICIENCIES
3
28. • These inefficiencies can be tackled by the adoption
of mashups and, more specifically, by using
Mashup Patterns
• Mashup Patterns are general reusable solutions to
a commonly occurring problem, which:
– Provide tested and proven development improvements
– Allow mashups to be developed quickly
PRODUCTIVITY
MASHUPS
3
30. PRODUCTIVITY
MASHUPS
3• Candidate mashup patterns:
– Alerter: periodically monitors a system of interest on
behalf of the user and sends notifications
– Importer: abstracts the different methods used to access
the external data
– Transform: enables the processing of certain types of
data
– Displayer: presents information from multiple sources as
independent widgets
31. • The Keystroke-Level Model (KLM) is used to
measure lower level inefficiencies
– Predicts the time an expert user takes to perform a task
on a computer system
– It is based on the sequence of keystroke-level actions the
user performs
PRODUCTIVITY
QUANTITATIVE MODELING
3
32. • The Complexity Model is employed to account for
the higher level inefficiencies
– Evolved from a methodology for quantitative
benchmarking of configuration complexity to a model of
configuration activity based on goals, procedures, and
actions
– Provides a set of metrics, e.g., execution, parameter, and
memory
PRODUCTIVITY
QUANTITATIVE MODELING
3
35. • A planned sequence of physical or mental activities
that fails to obtain a result
• May be of two types:
– Involuntary actions (i.e., slips and lapses): are those that
deviate from planned intentions and, thus, do not reach
their goals
– Intentional actions (i.e., mistakes and violations): are
performed consciously but the desired result is not
achieved
35
RELIABILITY
HUMAN ERROR
4
36. • We identified a set of common error-prone activities
in ITSM:
– Action: are actions that change the state of the system
– Retrieval: are failures to retrieve correct information, to
be used in a further step
– Checking: occur when the operator fails to check some
information
– Decision: occur when the operator has to make an
explicit choice between multiple alternatives
– Communication: occur when the operator fails to pass
information to another person
36
RELIABILITY
HUMAN ERROR
4
37. • Mashup patterns, can be used to cope with human
errors by providing a set of proven and reusable
solutions
• We introduce a new type of mashup basic operator,
(i.e., Error Prevention modules):
– Buffer: allows developers to specify for how long time a
specific action should be delayed before being executed
– Forcing: allows developers to introduce confirmation
points in the process workflow
37
RELIABILITY
MASHUPS
4
38. • HEART is a technique used to quantify human
reliability of specific tasks
– It is considered the most comprehensive method in the
field of Human Reliability Assessment
– Specifies the factors that can affect human performance,
thus making it less reliable (e.g., distractions, overload)
– We employed Linguistic Variables to represent the
Assessed Proportion of Affect
• Event Tree Analysis is used to determine the
probability of failure in a sequence of events
38
RELIABILITY
QUANTITATIVE MODELING
4
43. 43
EVALUATION
DISPATCH PROCESS
5
1) Open Ticket
(ETS)
2) Analyses if the
Ticket was misrouted
(ETS)
4) Forwards to other
team (ETS)
5) Analyses the skill
level to solve the ticket
(ETS)
7) Request for more
resources
(e-mail)
8) Import the ticket
(ETS, ITS)
9) Searches for the SA
With the right skills and
Availability (ITS)
10) Talk with the SA
(in person)
11) Makes the
assignment
(ETS, ITS)
3) Is the
ticket
correct?
6) Have
enough
resources?
• Name
• Description
• Severity
• Workload
• Skills
44. 44
EVALUATION
MASHUP-BASED DISPATCH SYSTEM
5
1) Open Ticket
(ETS)
2) Analyses if the
Ticket was misrouted
(ETS)
4) Forwards to other
team (ETS)
5) Analyses the skill
level to solve the ticket
(ETS)
7) Request for more
resources
(e-mail)
8) Import the ticket
(ETS, ITS)
9) Searches for the SA
With the right skills and
Availability (ITS)
10) Talk with the SA
(in person)
11) Makes the
assignment
(ETS, ITS)
3) Is the
ticket
correct?
6) Have
enough
resources?
• Name
• Description
• Severity
• Workload
• Skills
Alerter Pattern
{New Ticket}
Displayer Pattern
{name, description}
Displayer Pattern
{severity}
Displayer Pattern
{workload, skills}
Importer
Pattern
Transformer
Pattern
Input operator
{System Admin}
45. 45
EVALUATION
MASHUP-BASED DISPATCH SYSTEM
5
1) Open Ticket
(ETS)
2) Analyses if the
Ticket was misrouted
(ETS)
4) Forwards to other
team (ETS)
5) Analyses the skill
level to solve the ticket
(ETS)
7) Request for more
resources
(e-mail)
8) Import the ticket
(ETS, ITS)
9) Searches for the SA
With the right skills and
Availability (ITS)
10) Talk with the SA
(in person)
11) Makes the
assignment
(ETS, ITS)
3) Is the
ticket
correct?
6) Have
enough
resources?
• Name
• Description
• Severity
• Workload
• Skills
Alerter Pattern
{New Ticket}
Displayer Pattern
{name, description}
Displayer Pattern
{severity}
Input operator
{System Admin}
Displayer Pattern
{workload, skills}
Importer
Pattern
Transformer
PatternBuffer
Operator
Forcing
Operator
47. • We performed a series of time measurements
among five dispatchers in a service delivery center
– Using a stopwatch, we took 10 time measurements for
each assignment process and its individual tasks
47
EVALUATION
PRODUCTIVITY ASSESSMENT
5
0
30
60
90
120
150
180
210
240
2 3 5 6 8 9 11
Timeavg.(seconds)
Task #
48. • The KLM model was determined through
observation of user interactions
48
5EVALUATION
PRODUCTIVITY ASSESSMENT
Copy and Paste Operation Time (sec)
Decide to do the task M 1.35 sec
Change Window (mouse) P + K 1.3 sec
Copy text P + B + P + B 2.4 sec
Paste text P + K + H + K + K 1.9
Ttask8 = M + Fields * CopyPaste
= M + Fields * (M + Change Window + CopyText + ChangeWindow + PasteText )
= 1.35 + 10 * (1.35 + 1.3 + 2.4 + 1.3 + 1.9)
= 83.85 sec
49. 49
5EVALUATION
PRODUCTIVITY ASSESSMENT
• The complexity time can be obtained by subtracting
the time predicted by the KLM model
0
20
40
60
80
100
120
140
160
1 2 3 5 6 8 9 11
Time(Seconds)
Task #
Complexity
KLM
50. • By interviewing dispatchers, it was possible to
determine values for all the memory and decision
metrics
50
EVALUATION
PRODUCTIVITY ASSESSMENT
5
0
2
4
6
8
10
12
1 2 3 5 6 8 9 11
Complexuty
Task #
Decision
Memory Size
Memory Latency
Memory Depth
51. 51
5EVALUATION
PRODUCTIVITY ASSESSMENT
• It’s required to evaluate how the model’s quality
changes as new metrics are included in the
evaluation
Step Added Metric R2 RMSE
1 Decision 0.01 39.09
2 Memory size 0.94 24.78
3 Memory latency 0.96 4
4 Memory depth 0.84 5.04
52. 52
5EVALUATION
PRODUCTIVITY ASSESSMENT
Step Added Metric R2 RMSE
1 Decision 0.01 39.09
2 Memory size 0.94 24.78
3 Memory latency 0.96 4
4 Memory depth 0.84 5.04
• It’s required to evaluate how the model’s quality
changes as new metrics are included in the
evaluation
53. 53
5EVALUATION
PRODUCTIVITY ASSESSMENT
• It was possible to predict the time (spend at each
task) associated with the complexity encountered in
carrying out the tasks of the assignment process
• The model can
explain 96% of
the time
variability
0
10
20
30
40
50
60
70
1 2 3 5 6 8 9 11
Time(seconds)
Task #
Complexity
Real
54. 54
• Once the time measures are estimated, it’s possible
to evaluate productivity enhancement by using the
mashup’s technology
5EVALUATION
PRODUCTIVITY ASSESSMENT
0
20
40
60
80
100
120
140
160
1 2 3 5 6 8 9 11
Time(Seconds)
Task #
Real measurements
(without mashups)
Predicted by model
(without mashups)
Predicted by model
(with mashhups)
55. 55
• It was possible to
identify the most
common failures in
dispatch
• The number of human
errors accounted is 10
for each 150 executions
(~6.6%)
5EVALUATION
RELIABILITY ASSESSMENT
56. 56
5EVALUATION
RELIABILITY ASSESSMENT
EPCs
HEART
effect
Assessed proportion
of effect
Assessed
effect
Channel overload x 6 Medium 3.51
Suppressing information x 9 Medium 5.02
No veracity checks x 2 Low 1.18
No means of conveying info x 8 Low 2.28
• Once the process workflow and root causes of
problems are determined, the next step is the
determination of Human Error Probability (HEP) of
each activity in the workflow
Task 5: Analyses the skill level to solve the ticket
58. 58
• The new interaction elements and mashup patterns
are feasible mechanisms to reduce the occurrence
of human errors
5EVALUATION
RELIABILITY ASSESSMENT
EPCs
HEART
effect
Assessed proportion
of effect
Assessed
effect
Suppressing information x 9 Low 2.46
No veracity checks x 2 High 1.18
No means of conveying info x 8 Low 2.28
Task 5: Analyses the skill level to solve the ticket (after mashup usage)
60. 60
• The results show the reduction from 6.4% to 1.1% in
the probability of human error
5EVALUATION
RELIABILITY ASSESSMENT
0
0.005
0.01
0.015
0.02
0.025
1 2 3 4 5
HEPvalues
Failure #
Without mashups With mashups
61. • The Pearson product-moment correlation r indicate
a fair and positive relationship among the variables
61
5EVALUATION
CORRELATION ANALYSIS
0.00%
1.00%
2.00%
3.00%
4.00%
5.00%
6.00%
7.00%
0 50 100 150 200 250 300
CumulativeErrorProbability
(percentage)
Execution Time (seconds)
Mashups
Without Mashups
63. • Improvements in productivity and reliability provided
by the application of mashups demonstrate its
viability as a means for improving IT Service
Management
• The combined model allowed us to tackle lower
level inefficiencies of human-computer interactions,
and higher level inefficiencies of performing IT tasks
and subtasks
63
6CONCLUSIONS AND FUTURE WORK
FINAL CONSIDERATIONS
64. • The good fit between the real measurements with
the times predicted by the combined model
indicates its feasibility in predicting labor costs
savings
• The presented patterns and interaction elements
avoided the occurrence of action and retrieval
errors
64
6CONCLUSIONS AND FUTURE WORK
FINAL CONSIDERATIONS
65. • Inefficiencies due to the complexity and mechanical execution involved in
performing the activity.
• Four groups of inefficiencies: basic, information management, skill-
dependent, and synchronization.
• Errors can occur due to: attention span, memory, situation awareness, and
personal resources.
• Five common error-prone activities: action, retrieval, checking, decision, and
communication errors.
65
6CONCLUSIONS AND FUTURE WORK
FINAL CONSIDERATIONS
Q I. What are the major causes for a poor performance in the execution of IT Service
Management processes?
Hypothesis: The employment of mashups enhances the performance of
human-centered ITSM processes
66. • KLM provides a wealth of detail at the lower level human-computer interactions,
while the Complexity Model addresses both levels of inefficiencies.
• HEART can be used to quantify the human reliability of individual tasks. ETA was
used to evaluate the overall human error probability of ITSM processes.
66
6CONCLUSIONS AND FUTURE WORK
FINAL CONSIDERATIONS
Q II. How models available in the literature can be used to assess performance
improvements obtained with mashups?
Hypothesis: The employment of mashups enhances the performance of
human-centered ITSM processes
67. • Mashup patterns to tackle inefficiencies and error-prone activities in service
management processes: Alerter, Importer, Transform, and Displayer (SANTOS et
al., 2011).
• A new type of interaction elements, called Error Prevention modules (SANTOS et
al., 2013).
67
6CONCLUSIONS AND FUTURE WORK
FINAL CONSIDERATIONS
Q III. What methods could be employed in the development of mashups aiming at
performance enhancement?
Hypothesis: The employment of mashups enhances the performance of
human-centered ITSM processes
68. • Validation of mashup patterns through additional
supporting cases
• Investigate financial models to assess loss due to broken
SLAs
• Automation of mashup’s development
• Inclusion of confidentiality mechanisms in the mashup’s
development
• Investigation of rollback and exception handling in the
mashup composition logic
68
6CONCLUSIONS AND FUTURE WORK
NEXT STEPS
69. • 2009:
– Rafael Santos Bezerra, Carlos Raniery Paula dos ; Leandro Márcio
Bertholdo ; Lisandro Zambenedetti Granville ; Liane Margarida
Rockenbach Tarouco . Um Sistema de Gerenciamento de Redes
Baseado em Mashups. SBRC 2009
– Rafael Santos Bezerra, Carlos Raniery Paula dos ; Leandro Márcio
Bertholdo ; Lisandro Zambenedetti Granville ; Liane Margarida
Rockenbach Tarouco . Um Sistema de Gerenciamento de Redes
Baseado em Mashups. Revista Brasileira de Redes de Computadores
e Sistemas Distribuídos (RESD), v. 2, 2009.
69
6CONCLUSIONS AND FUTURE WORK
PUBLICATIONS
70. • 2010:
– Rafael Santos Bezerra, Carlos Raniery Paula dos ; Lisandro
Zambenedetti Granville ; Liane Margarida Rockenbach Tarouco . On
the Feasibility of Web 2.0 Technologies for Network Management:
A Mashup-Based Approach. 12th Network Operations & Management
Symposium (NOMS), 2010, Osaka, Japan
– Carlos Raniery Paula dos Santos, Rafael Santos Bezerra, João
Marcelo Ceron, Lisandro Zambenedetti Granville, Liane Margarida
Rockenbach Tarouco. On Using Mashups for Composing Network
Management Applications. IEEE Communications Magazine, Vol. 48,
Issue 12, December 2010
– Carlos Raniery Paula dos Santos, Rafael Santos Bezerra, João
Marcelo Ceron, Lisandro Zambenedetti Granville, Liane Margarida
Rockenbach Tarouco. Botnet Master Detection Using a Mashup-
based Approach. 6th IEEE International Conference on Network and
Service Management (CNSM), 2010, Niagara Falls, Canada
70
6CONCLUSIONS AND FUTURE WORK
PUBLICATIONS
71. • 2011:
– Carlos Raniery Paula dos Santos, Rafael Santos Bezerra, João
Marcelo Ceron, Lisandro Zambenedetti Granville, Liane Margarida
Rockenbach Tarouco. Identifying Botnet Communications Using a
Mashup-based Approach. LANOMS, 2011, Quito, Equador
– Carlos Raniery Paula dos Santos, Winnie Cheng, Rafael Santos
Bezerra, Lisandro Zambenedetti Granville, Nikos Anerousis. A Data
Confidentiality Architecture for Developing Management Mashups.
12th IFIP/IEEE International Symposium on Integrated Network
Management, 2011, Dublin, Ireland
– Carlos Raniery P. dos Santos, Lisandro Zambenedetti Granville, Winnie
Cheng, David Loewenstern, Larisa Shwartz, Nikos Anerousis.
Performance Management and Quantitative Modeling of IT Service
Processes Using Mashup Patterns. 7th International Conference on
Network and Services Management (CNSM 2011), 2011, Paris, France
71
6CONCLUSIONS AND FUTURE WORK
PUBLICATIONS
72. • 2012:
– Carlos Raniery Paula Dos Santos, Lisandro Zambenedetti Granville,
Nikolaos Anerousis, David Matthew Loewenstern, Louis Jonh Percello,
Winnie Cheng, Larisa Shwartz. Performance Management and
Quantitative Modeling of IT Service Processes Using Mashup
Patterns. US Patent Pending
72
6CONCLUSIONS AND FUTURE WORK
PUBLICATIONS
73. • 2013:
– Carlos Raniery Paula dos Santos, Lisandro Zambenedetti Granville,
Larisa Shwartz, Nikos Anerousis, David Loewenstern. Quality
Improvement and Quantitative Modeling – Using Mashups for
Human Error Prevention. 13th IFIP/IEEE Symposium on Integrated
Network and Service Management (IM 2013), 2013, Ghent, Belgium
73
6CONCLUSIONS AND FUTURE WORK
PUBLICATIONS
74. • Virtual Nodes Monitoring based on Mashup
– This paper provides a mashup-based mechanism
to monitor virtualized networks.
74
6CONCLUSIONS AND FUTURE WORK
NEXT PUBLICATIONS
75. • A Mashup-based Solution for Botnet
Mitigation
– This paper proposes a modular architecture
based on the dynamic integration of pre-existing
tools to achieve a more efficiently detection
solution.
75
6CONCLUSIONS AND FUTURE WORK
NEXT PUBLICATIONS
76. • Survey
– This work aims at gathering and organizing the
knowledge about mashups properties applied to
multiple management scenarios
76
6CONCLUSIONS AND FUTURE WORK
NEXT PUBLICATIONS
77. • Automation of mashups’ development
– Considering that the ITSM operators have a
strong knowledge of the process they use to
perform, but may not have expertise in mashups
development, the use of an automated
development system may ultimately provide a
significantly improved orchestration of the
process
77
6CONCLUSIONS AND FUTURE WORK
NEXT PUBLICATIONS
78. • Overview of the Thesis
– This paper will present all the performance
metrics analyzed and show the key concepts of
this thesis
78
6CONCLUSIONS AND FUTURE WORK
NEXT PUBLICATIONS
79. Carlos Raniery Paula dos Santos
Orientador: Lisandro Zambenedetti Granville
Instituto de Informática – UFRGS
Inf.ufrgs.br/~crpsantos
Some questions….
79
Computer
Networks
Group
Thank you for your attention!
80. • [01] ISACA. Control Objectives for Information and related
Technologies (COBIT). 2008
• [02] OGC. Information Technology Infrastructure Library v3 (ITIL
v3). 2008
• [03] PULTORAK, D.; HENRY, C.; LEENARDS, P. MOF 4. 0: a
pocket guide: (microsoft operations framework). [S.l.]: Van
Haren Publishing, 2008. (Van Haren Series)
• [04] MILLIKEN, K. R.; CRUISE, A. V.; ENNIS, R. L.; FINKEL, A.
J.; HELLERSTEIN, J. L.; LOEB, D. J.; KLEIN, D. A.; MASULLO,
M. J.; VANWOERKOM, H. M.;WAITE, N. B. YES/MVS and the
automation of operations for large computer complexes. IBM
System Journal, [S.l.], v.25, p.159–180, June 1986.
• [05] CANDEA, G.; KICIMAN, E.; KAWAMOTO, S.; FOX, A.
Autonomous recovery in componentized Internet applications.
Cluster Computing, Hingham, MA, USA, v.9, p.175–190, April
2006.
80
References
81. • [06] KELLER, A.; HELLERSTEIN, J. L.; WOLF, J. L.; WU, K.
L.; KRISHNAN, V. The CHAMPS system: change
management with planning and scheduling. In: NETWORK
OPERATIONS AND MANAGEMENT SYMPOSIUM, 2004.
NOMS 2004. IEEE/IFIP, 2004. Anais. . . [S.l.: s.n.], 2004. v.1,
p.395–408 Vol.1.
• [07] LIKER, J. The Toyota way: 14 management principles
from the world’s greatest manufacturer. [S.l.]: McGraw-Hill,
2004.
• [08] OGC. Information Technology Infrastructure Library v3
(ITIL v3). 2008.
• [09] Michael Ogrinz. Mashup Patterns: Designs and
Examples for the Modern Enterprise. 2009. ISBN 978-
0321579478
81
References
82. • [10] CARD, S. K.; NEWELL, A.; MORAN, T. P. The
Psychology of Human-Computer Interaction. Hillsdale, NJ,
USA: L. Erlbaum Associates Inc.,2000
• [12] BROWN, A. B.; HELLERSTEIN, J. L. An approach to
benchmarking configuration complexity. In: IN
PROCEEDINGS OF THE 11TH ACM SIGOPS EUROPEAN
WORKSHOP, 2004. Anais. . . [S.l.: s.n.], 2004.
• [13] DIAO, Y.; KELLER, A. Quantifying the Complexity of IT
Service Management Processes. In: DSOM, 2006. Anais. . .
[S.l.: s.n.], 2006. p.61–73
• [14] DIAO, Y.; KELLER, A.; PAREKH, S. S.; MARINOV, V. V.
Predicting Labor Cost through IT Management Complexity
Metrics. In: INTEGRATED NETWORK MANAGEMENT, 2007.
Anais. . . [S.l.: s.n.], 2007. p.274–283
82
References
83. • [15] REASON, J. Human Error. [S.l.]: Cambridge [England] ;
New York : Cambridge University Press, 1990. xv, 302 p.,
1990.
• [16] KIRWAN, B. The validation of three human reliability
quantification techniques THERP, HEART and JHEDI: part 1 -
ttechnique descriptions and validation issues. Applied
Ergonomics, [S.l.], v.27, n.6, p.359 – 373, 1996
83
References
87. • The focus is on the Request Fulfillment process
– Responsible for carrying out service requests, and that
interfaces with Service Desk, Incident Management, and
Change Management
• This process includes two types of human
operators:
– System administrators: technical personnel with
knowledge to resolve specific requests
– Dispatchers: responsible for monitoring new requests,
dispatching the requests to the appropriate SA, and
monitoring compliance with SLAs
87
PRELIMINARY EVALUATION
DISPATCH PROCESS
5
88. • Interaction Components:
– Visual: represent way data can be displayed,
such as map, tables, and trees
– Control: represent basic programming logic, such
as loops, and conditions
– Operation: perform operations over retrieved
information, such as filtering, merging, and
arithmetic operations
– Adaptation: represent external resources, these
are created based on wrapper meta-information
stored
– Reuse: this type of component represent existing
mashups, enabling their reuse in other masups
88
Mashup System
89. • Effectiveness: how to match the customers
requirements and what the service provides in fact
• Cost: may be defined in SLAs
• Security: probability of information leakage
89
Other metrics
90. • Checklists are increasingly being used in Scottish
hospitals, for example in pre-operative settings
• Minimize staff interruptions and distractions
• Prevent errors: procedures, training, UI design
(allow only valid choices)
• Recover errors: undo capability, confirmation
90
Other system improvements
92. 92
Gesture Time
K Keying 0.2 sec
B Holding/Releasing key 0.1 sec
P Pointing 1.1 sec
H Homing 0.4 sec
M Mentally Preparing 1.35 sec
KLM
93. • KLM model: provides a wealth of detail at the lower level of
human-computer interactions
• Complexity model: besides it addresses both levels of
inefficiencies, we discard all the complexity metrics except
the memory and decision metrics, which capture higher level
potential inefficiencies not addressed by KLM
93
Total time spend by a human
Human-computer
interactions
Cognitive
actions
Quantitative Modeling
94. • The approach can be summarized in three steps:
– Assessing the complexity and timing a baseline scenario
– Construction of the regression model and its quality
evaluation
– Employing the model to predict labor costs
94
Complexity Model
Hinweis der Redaktion
Boa dia a todos
Primeiramente gostaria de agradecer aos membros da banca, profa. Rossana, profa. Regina e prof. Luciano por sua disponibilidade em participar desta defesa.
Também gostaria de agradecer ao meu orientador, prof. Lisandro, por todo o apoio dado no desenvolvimento deste trabalho
E finalmente à plateia aqui hoje presente.
Eu sou o Carlos Raniery e o título deste trabalho é Gerenciamento de Desempenho de Processos de TI usando uma abordagem baseada em mashups
Inicialmente, farei uma breve introdução, contextualizando o problema, definido a hipótese investigada neste trabalho, bem como as perguntas de pesquisa que guiaram o desenvolvimento da tese
Em seguida, apresentarei o escopo das investigações realizadas
Logo depois, falarei a respeito das métricas, métodos e modelos que foram identificados para melhorar e avaliar o desempenho de processos de TI
Para então, examinar tais propostas através de um estudo de caso real
Finalmente, concluirei a apresentação com as respostas para as perguntas de pesquisa e com as próximas tarefas a serem realizadas
O aumento constante tanto em complexidade como em importância dos ambientes de TI tem contribuido para que pesquisadores, tanto na indústria como na academia, observem com mais atenção às práticas de gerênciamento empregadas.
Este aumento tem sido acompanhado pela crescente necessidade de boas práticas e processos efetivos para projetar, implantar, gerenciar o cliclo de vida, e mitigar a ocorrência de falhas na provisão dos serviços
Nesse contexto, diversos frameworks de boas práticas, tais como o COBIT, CMMI e o ITIL, têm sido propostos sendo que tanto esta apresentação como o texto da tese se concentra no ITIL por ser o framework utilizado como padrão na organização de TI investigada durante este trabalho
a Biblioteca de Infraestrutura de Tecnologia da Informação (ITIL) tem se mostrado como a mais aceita e utilizada pela indústria.
Em ITSM, uma grande parte do trabalho é realizada por humanos ao invés de máquinas. A presença destes humanos, apesar de necessária, degrada o desempenho e a qualidade dos serviços oferecidos.
Isto ocorre devido a natureza imprevisível do seu comportamento: por exemplo, os humanos podem executar processos diferentes a cada vez ou ser interrompidos por fatores externos.
Automação normalmente tem sido utilizada para eliminar completamente a presença dos operadores humanos, especialmente onde há um alto risco de erro ou quando os humanos não conseguem atender a uma alta carga de trabalho.
Contudo, há algumas áreas onde a presença do humano é crítica e este não pode ser substituído por máquinas. Nestes casos, uma solução híbrida, que automatize algumas tarefas mas que mantenha o foco nas necessidades dos humanos é a mais indicada.
Entre as diversas novas tecnologias disponíveis hoje, uma em especial não foi investigada apropriadamente no contexto de gerência de TI: os mashups.
Os mashups são aplicações Web, criadas a partir da composição de recursos disponíveis online (páginas HTML, feeds de notícias, Web services).
O desenvolvimento dos mashups é suportado por um conjunto de operadores básicos que abstraem detalhes técnincos dos usuários finais
7- Por exemplo, podemos imaginar um mashup criado a partir da integração dos mapas Google com informações sobre imóveis obtidos a partir do site Craigslist.
8- Motivados pelas características observadas em mashups, a hipótese investigada nesta tese é a de que seu uso pode melhorar o desempenho de processos de gerência de TI, especificamente, em processos que envolvem atividades humanas.
Com o objetivo de guiar a verificação desta hipótese, foram definidas 3 perguntas fundamentais, onde a primeira é: quais os principais fatores que contribuem para um baixo desempenho dos processos de gerência de serviços de TI
Segundo, de que formas os mashups podem ser desenvolvidos objetivando uma melhoria no desempenho?
E finalmente, como modelos e técnicas disponíveis na literatura podem ser usadas para avaliar e prever ganhos no desempenho obtidos com o uso de mashups?
Os trabalhos desenvolvidos durante esta tese foram realizados no ambiente de uma empresa prestadora de serviços, organizada de acordo com as práticas definidas pelo ITIL e que tem como objetivo fornecer serviços com uma alta qualidade a um baixo custo para os seus clientes.
É importante observar que, apesar de tocar temas de diversas áreas, as contribuições desta tese são principalmente na área de Gerência de Serviços.
Serviços, de acordo com a definição do ITIL são meios de entregar valor aos clientes, facilitando os resultados que os clientes querem alcançar, sem ter que assumir os custos e riscos associados
12- Basicamente, o ITIL fornece uma perspectiva holística sobre o ciclo de vida dos serviços, abrangendo a organização de TI inteira e todos os componentes de apoio necessários para prestar serviços ao cliente.
12- O ITIL define cinco estágios deste cliclo de vida do serviço, onde cada um possui processos e funções essenciais para um provedor de serviços de TI.
Processes: are closed-loop systems, providing changes and transformations towards a specific goal
Functions: specialized organizations with certain types of work and responsible for specific outcomes
13- As investigações realizadas no decorrer desta tese se concentram especificamente na Operação de Serviços, que engloba as práticas utilizadas no dia-a-dia dos profissionais de TI com o objetivo de manter o serviço em operação
13- Dentro da Operação de Serviços, nos concentramos no processo de Request Fulfillment, que é responsável por lidar com requisições feitas pelos clientes
O Request Fulfillmente por sua vez é composto por 2 grandes atividades:
primeira atividade é realizada por administradores de sistema que possuem conhecimentos tecnicos para resolver as requisições,
enquanto que a segunda é realizada por dispatchers, que monitoram por novas requisições e encaminham-nas para os SAs
Para a avaliação, que será apresentada em detalhes posteriormente, nos concentramos na atividade de dispatch.
De acordo com trabalhos disponíveis na literatura, esta atividade exige uma fração significativa do tempo necessário para resolver a requisição e é altamente dependente de humanos, portanto, passível de erro.
16- Como observamos, as atividades do Request Fullfilment são desempenhadas por operadores humanos, que mais uma vez, são imprevisíveis, dificultando assim a modelagem e otimização do processo
16- Mesmo se a natureza do trabalho for a mesma, o operador humano pode executá-lo de formas diferentes a cada vez. Por exemplo, ele pode ser interrompido, pode estar sobrecarregado, utilizar ferramentas diferentes ou seguir uma sequencia de passos diferentes
- Neste cenário, dois problemas principais podem ocorrer: o operador humano pode diminuir seu ritmo de trabalho, ou então errar na execução de suas atividades
- Desta forma, nos concentramos em 2 aspectos importantes e que têm impacto direto no desempenho:
Produtividade, que pode ser avaliada como o numero de unidades de trabalho realizadas por unidade de tempo.
Esta métrica é importante, por exemplo, porque menos tempo implantando, matendo e corrigindo problemas se traduz em um menor custo operacional. Dependendo da natureza da operação, economia de tempo também resulta em um maior retorno para o provedor de serviços; pois contribui para um aumento na satisfação dos clientes.
Também avaliamos a Confiabilidade, que pode ser medida como o número de unidades não defeituosas identificadas ao final do processo.
Assim como produtividade, é um dos principais indicadores do desempenho dos processos. Por exemplo, configurações erradas em sistemas críticos podem resultar em indisponibilidade dos sistemas, levando a perdas de receita e de credibilidade.
Considerando a diversidade de atividades humanas dentro do Request Fulfillment, o nosso foco específico é nas tarefas do processo que podem ser medidas através de intrumentação ou observação e que podem ser melhoradas através de reprojeto e automação parcial.
Eventos exógenos (atender um telefonema) não são avaliados. Afinal de contas, não podemos controlar quando um humano decide interromper ou diminuir seu ritmo de trabalho, mas podemos medir e controlar o ambiente onde o desempenho é limitado por conta de falta de ferramentas adequadas ou os processos são executados de forma ineficiente
Um dos principais fatores que contribuem para uma baixa produtividade em processos que envolvem atividades humanas são as ineficiências que podem surgir, fundamentalmente, em dois níveis:
De baixo nível por conta da execução mecanica na realização de uma tarefa
De alto nível devido a complexidade em realizar a tarefa em si
Com o objetivo de identificar quais os tipos mais comuns de ineficiências em processos de TI, analisamos as tarefas executadas por operadores humanos em um Service Delivery Center
Esta ativiade nos permitiu identificar 4 tipos principais de ineficiências:
Por exemplo, as ineficiências dependentes de habilidade se relacionam as capacidades de cognitivas do operador humano, por exemplo, se lembrar de uma informação
Enquanto que as ineficiencias de sincronização ocorrem devido a atrasos decorrentes de espera por elementos externos, por exemplo, quando o operador precisa falar com outra pessoa.
Basicas, Gerenciamento de informação, Dependentes de habilidade, Sincronização
Cada um destes tipos de ineficiências por sua vez, podem ser mitigados com o uso de mashups, mais especificamente, de padrões de mashup
Padrões de mashup são soluções reusáveis para problemas recorrentes e que são definidos a partir dos operadores básicos de mashup
Por exemplo, o mashup apresentado anteriormente foi construído usando dois operadores básicos, o Retrieve Data e o Display on Google maps
Esta mesma estrutura de operadores, pode ser utilizada para criar um outro mashup, que ao invés de mostrar informações de imóveis, apresenta informações sobre crimos ocorridos em uma determinada cidade
A observação destas ineficiências nos permitu definir um conjunto inicial de 4 candidatos a padrões de mashup. Nesse ponto, gostaria de agradecer à professora Rossana por seus comentários sobre a especificação dos padrões usando uma linguagem apropriada. Por isso no texto da tese nós apresentamos estes padrões usando um formato mais conscistente com o que é encontrado na literatura de padrões.
Estes padrões também foram observados no desenvolvimento de mashups em trabalhos passados. Por exemplo, o Displayer foi amplamente utilizado no desenvolvimento de um mashup para recuperar e apresentar informações relacionadas ao peering BGP.
Para avaliar produtividade, utilizamos diferentes modelos,
KLM é usado para medir ineficiências de baixo nível:
ele se baseia na sequencia de ações (clicar, mover o mouse) que um usuário executa ao interagir com um sistema
O modelo de complexidade, por sua vez, pode ser usado para avaliar ineficiências de nível mais alto e que são decorrentes da complexidade em executar uma tarefa. Também agradeço ao professor Luciano, por seu comentário sobre as métricas de complexidade. No volume da tese, deixamos mais claro que do conjunto total de métricas definidas pelo Yixin/Keller/Brown/Helerstein, nós usamos apenas as dos grupos de decisão e memória, reduzindo assim para 7 métricas avaliadas
Desta forma, para avliar ambos os níveis de ineficiência, um analista trabalha junto com operador humano, para inicialmente definir o conjunto de tarefas que são seguidas durante a execução de um processo
Depois, através de observação, o analista determina o modelo KLM, mede o tempo e define junto com o operador humano, valores para as metricas de complexidade. A relação entre tempo e métricas de complexidade é entao observada através de uma regressão linear multipla, que permite a geração de uma equação linar para prever o tempo devido a complexidade da tarefa.
Finalmente, junta-se a este tempo, o previsto pelo KLM para assim, termos o tempo total de execução de um processo
Um dos principais fatores que contribuem para uma baixa confiabilidade nos processos de gerência de TI, é a ocorrência de erros, especificamente, erros humanos.
Estes erros podem ser de dois tipos:
Involuntários: são os que se desviam das intenções planejadas, por exemplo, o usuário fecha uma janela porque clicou no botão errado
Voluntários: são os que ocorrem concientemente mas o resultado desejado não é alcançado, por exemplo, o usuário toma uma má decisão achando estar correta
Da mesma forma como as ineficiências, também analisamos um Service Delivery Center para identificar os tipos mais comuns de erros em gerência de serviços de TI
Os padrões de mashup apresentados anteriormente podem ser úteis não só para eliminar ineficiências que afetam a produtividade, mas também diminuir a probabilidade de erros humanos
Além dos padrões, um novo tipo de elemento de interação, chamado operadores de prevenção de error, foi introduzido para ser usados por desenvolvedores de mashup
Buffer: permite que se especifique uma janela de tempo que uma determinada ação deve ser atrazada antes de ser executada (por exemplo, o undo do gmail)
Forcing: pertmite que os desenvolvedores introduzam pontos de confirmação durante a execução das tarefas do processo
Duas técnicas foram utilizadas para prever a probabilidade de erro total em um processo de gerência de TI.
HEART é usado para avaliar a probabilidade de erro em tarefas individuais
Árvore de eventos é usada por sua vez, para determinar a probabilidade de ocorrer pelo menos uma falha em uma sequencia de eventos
Da mesma forma, o analista trabalha junto com um operador humano para determinar as tarefas individuais do processo, em seguida através da técninca HEART estima-se a probabilidade de falha em cada uma destas tarefas, e por fim, usando uma árvore de eventos se identifica a probabilidade total de falha do processo
Uma vez definido o cenário a ser investigado, foi realizada uma avaliação dos métodos e modelos propostos com o objetivo de atestar o uso de mashups como solução capaz de melhorar a produtividade e confiabilidade de processos de gerência de TI.
Relembrando o escopo das investigações, nós nos concentramos na atividade de dispatch, realizada por operadores humanos responsáveis principalmente por receber as requisições dos clientes e encaminhá-las para os administradores de sistemas mais apropriados.
Explicando em linhas gerais esta atividade, uma vez que o cliente cria uma requisição (ou ticket), este é encaminhado para um dispatcher que irá analisá-lo e determinar qual o SA apropriado para resolvê-lo. Usualmente, cada dispatcher é responsável por um time de administradores de sistema, cada um, com um conhecimento técninco diferente e específico.
Para atender aos comentários da professsora Regina, disponibilizei maiores informações sobre a coleta de dados e sobre o ambiente investigado. A coleta de dados deste ambiente foi realizadas ao longo de duas semanas em dois centros de delivery em uma empresa global de TI. Durante este período, cinco dispatchers foram acompanhados durante a execução de suas tarefas diárias e para cada um, foram observadas e medidas um total de 10 ações de atribuição de tickets para SAs.
As requisições, por sua vez, podem ser classficadas em 3 classes de severidade, cada uma associada a um tempo máximo de resolução. No caso de não atendimento destas requisições dentro do prazo especificado, o provedor de serviços é penalizado financeiramente pelo cliente.
- Através de observações, foi possível determinar a sequência de passos que diferentes dispatchers executam durante suas atividades.
Inicialmente o dispatcher, ao receber o ticket, analisa se foi direcionado para ele indevidamente.
Em seguida, o dispatcher investiga qual o nível de conhecimento necessário para resolver a requisição
Se ninguém do seu time for capaz de resolver o ticket, o dispatcher encaminha para outro dispatcher, responsável por outro time de SAs
Se tudo estiver correto, o dispatcher finalmente importa o ticket, procura pelo SA mais apropriado e faz a atribuição.
O Dispatcher também usa informações sobre a carga de trabalho de cada SA, agenda de férias, conhecimentos específicos e nível de experiência para realizar a atribuição.
Cada um dos padrões de mashup apresentados anteriormente podem ser aplicados a diferentes etapas deste processo. Por exemplo, o Displayer pattern é usado nas etapas 2, 5 e 9 para apresentar constantemente as informações mais importantes para o dispatcher tomar suas decisões. Assim, ele não precisa ficar alternando entre diferentes sistemas para buscar estas informações, nem confiar em sua memória.
Ambos os operadores de prevenção de erro também puderam ser aplicados na criação do mashup para dispatch. Os operadores foram aplicados ao final do processo, para que o dispatcher tenha que re-confirmar a atribuição e ainda assim, terá alguns segundos antes que esta ação seja executada de fato
A interface gráfica do mashup foi refeita para apresentar de uma forma mais apropriada as informações necessárias para o dispatcher.
Nela, as informações mais importantes são apresentadas em uma única tela, implementando assim o conceito de single pane of glass.
Após analisar os tempos medidos, observamos que a alta variabilidade deve-se principalmente a diferenças na complexidade dos tickets recebidos durante o período da investigação.
Alguns mais simples, eram rapidamente associados a um SA, enquanto que outros mais complexos exigiam que os dispatchers recuperassem informações mais detalhadas dos pedidos dos clientes
- Em seguida, usamos o KLM para determinar quanto deste tempo deve-se à execução mecanica da interação com as ferramentas
- Por exemplo, observamos que a tarefa de importação do ticket do sistema do cliente para o sistema interno do provedor de serviços, normalmente executada manualmente, leva 83 segundos apenas interagindo mecanicamente (por exemplo, copiando e colando informações)
Uma vez determinado o tempo de execução mecânica, podemos subtraí-lo do tempo total, para assim, descobrir quanto tempo é gasto com ações cognitivas, por exemplo, tomando uma decisão
Entrevistando os dispatchers, foi possível determinar os valores para todas as métricas de complexidade selecionadas neste trabalho.
Os resultados mostram um alto número de informações que o dispatcher precisa manter em memória durante a execução da atividade de dispatch (como pode ser observado através da métrica MemorySize). No pior caso, o dispatcher precisa reter em memória 10 itens, o que exede em 3 o número máximo que um humano pode manter em sua memória de curto prazo
Uma vez que temos os tempos e os valores para as métricas de complexidade, podemos investigar a relação entre eles com o uso da técnica de regressão linear múltipla, que permite gerar uma equação (ou modelo) linear que correlaciona o tempo gasto na execução de cada ação com as métricas de complexidade
A seleção das métricas deve ser feita em uma bordagem incremental e a qualidade do modelo é deve ser avaliada através de duas métricas: o R2 e o erro médio quadrático.
O R2 é definido como a proporção da variabilidade em um conjunto de dados que pode ser explicado por um modelo quantitativo. Um R2 igual a 1 indica que o modelo foi capaz de capturar toda a variabilidade
O Erro médio quadrático por sua vez é utilizado para comparar as diferenças entre os valores previstos por um modelo e os valores reais observados. Valores mais próximos de zero são mais desejados, pois indicam uma melhor precisão do modelo.
Ao ir adicionando as métricas de forma incremental, percebemos que a construção do modelo deve parar na etapa 3, que apresenta o maior R2, com o menor RMSE
Com isto, foi possível chegar à esta equação linear
Com o uso desta equação, foi possível prever o tempo gasto devido à complexidade para cada tarefa individual.
Como observamos através deste gráfico, os tempos previstos pelo modelo são muito próximos dos tempos reais medidos com os dispatchers
Após a aplicação dos mashups na atividade de dispatch, ocorreu uma redução tanto em complexidade como no número de interações com os sistemas que o dispatcher tinha que executar.
Com o uso da equação linear mais o tempo previsto pelo KLM, foi possível prever o tempo de execução da atividade com o uso de mashups.
Os resultados obtidos mostram uma significativa reducão no tempo de execução, onde a maior parte se deve a automação da etapa de importação do ticket através dos padrões importer/transformer.
O padrão displayer permitiu a redução no tempo das etapas 9 e 11 uma vez que o dispatcher não precisa mais procurar pelas informações em diferentes sistemas nem manter estas informações em memória
Com as entrevistas com os dispatchers, e após analisar documentos de incidentes foi possivel identificar quais são os erros mais comuns realizados pelos dispatchers
Estes mesmos relatórios de incidente, apontam que 10 em cada 150 execuções apresentam algum tipo de erro humano
Utilizando a técnica HEART e conhecendo quais são as principais causas de erro, foi possível determinar a probabilidade de erro humano de cada tarefa do processo
Para isto, identificamos as condições que podem contribuir para a ocorrência de cada erro e demos um peso para cada condição, conforme exemplificado aqui na tarefa 5, que corresponde à analise do nível de conhecimento necessário para resolver o ticket
Finalmente, utilizando esta equação proposta pelo HEART, identificamos a probabilidade de erro em cada tarefa do processo de dispatch
Para a tarefa 5, por exemplo, a chance de ocorrer algum erro humano é de 1.9%
Com as probabilidades individuais, usa-se a arvore de eventos para calcular a probabildiade total de que ocorra pelo menos um erro na execução do processo
Para a atividade de dispatch, encontramos o valor de 6.4% de probabilidade, o que é bastante próximo do valor apontado nos relatórios de incidente.
Com o uso dos padrões de mashup e dos operadores de prevenção de erro, foi possível obter uma diminuição das condições que contribuem para erro humano.
Assim, para a mesma tarefa 5, a probabilidade de erro humano, após a aplicação do mashup, diminuiu para 0.41%
E a probablidade de erro total do processo de dispatch, diminuiu para 1.1%
Apenas para efeitos comparativos, aqui apresento as probabilidades individuais para cada tarefa.
Mais uma vez, a automação da etapa de importação do ticket, foi a principal responsável pelo aumento na confiabilidade.
Uma vez que todas as informações são apresentadas na mesma tela, diminuiu-se a troca de contexto entre sistemas, reduzindo assim a chance de erro nas tarefas 5 e 9, que correspondem as falhas 2 e 4
Observando ambas as métricas, foi possível notar uma correlação razoável e positiva, que significa que uma redução no tempo (aumento de produtividade) também contribui para a redução de erros humanos (aumento na confiabilidade)
Neste gráfico, as marcações representam o instante de tempo em que cada tarefa é concluída e a probabilidade de erro correspondente. Curvas com marcações mais próximas da origem possuem um melhor desempenho.
Uma observaçao deste gráfico é que nas tarefas 5 e 9 a chance de erro humano aumenta rapidamente em um curto intervalo de tempo. Ambas as tarefas exigem um alto nível cognitivo e envolvem poucas ações mecânicas. Na tarefa 11, por outro lado, há pouco aumento na chance erro, mesmo necessitando um tempo signifcativo do processo. Esta tarefa envolve ações mecanicas, basicamente troca de sistemas e fornecimento de informações simples (nome do SA). Isso nos mostra que mashups são mais adequados para reduzir erros de ações cognitivas e aumentar a produtividade de ações mecâniicas.
Os resultados específicos observados ao longo deste trabalho indicam que o aumento em produtividade e confiabilidade demonstra a viabilidade dos mashups como solução para melhorar a gerência de TI
A composição dos modelos de complexidade e o KLM se demonstrou uma solução viável para avaliar ineficiências de baixo e alto nível. A proximidade entre os tempos reais observados no Service Delivery Center e os tempos previstos pelo modelo composto, demonstram sua viabilidade em prever economias de tempo.
Uso dos operadores de prevençao de erro, junto com os padrões de mashup, permitem que desnvolvedores de mashup criem aplicações que contribuem para a prevenção de erros humanos, ou no mínimo, reduzir sua frequencia
O uso de mashups possibilitou a diminuição de erros de ação e recuperação, que de acordo com investigações, correspondem a 89% de todos os erros humanos.
Relembrando a hipótese apresentada anteriormente, “O uso de mashup spode melhorar o desempenho de processos de gerência de TI, especificamente, em processos que envolvem atividades humanas
Chegamos a respostas para as perguntas fundamentais:
Ineficiências que degradam a produtividade ocorrem por dois motivos principais: complexidade e ações mecânicas e podem ser de 4 tipos principais
Erros podem ocorrer por 4 motivos e podem ser de cinco tipos
KLM e o Modelo de Complexidade podem ser utilizados em conjunto para avaliar ambos os níveis de ineficiências
HEART pode ser usado para avaliar a chance de erro em tarefas individuais e pode ser complementado com ETA para avaliar a probabilidade de erro total dos processos
Uso de padrões de mashup se apresenta como uma solução viável para eliminar ineficiências e diminuir a chance de erro, que por sua vez pode ser diminuido ainda mais com o uso de um novo tipo de operador de mashup.
Finalmente, os próximos passos incluem :
Validação dos padrões
Investigação de modelos para avaliar perdas financeiras devido a SLAs não atendidas
Automatizar, ou pelo menos guiar, o desenvolvimento dos mashups
Propor mecanismos de confidencialidade, rollback e tratamento de exceção no desenvolvimento dos mashups
Em 2011 ocorreu uma mudança no foco de nossas pesquisas.
Isto ocorreu porque tínhamos uma visão (gerência de redes) e depois fui fazer o meu sanduíche foi que percebemos que o Nikos trabalhava com gerência de TI (falar da confusão por conta do tutorial do Nikos)
Normalmente, os mashups são criados a partir de sistemas especiais
Several time-consuming issues can arise in the dispatching process, making it infeasible to resolve tickets within the times established in SLAs and therefore resulting in financial loss to service providers. For example, it is common for customers and service providers to use their own ticketing systems, making it necessary to import data and maintain consistency between the systems. Dispatchers need to deal
with data consistency and redundancy without violating any customer policies, such as data compliance for dealing with confidential information. In addition, the dispatcher and his team of SAs may be responsible for multiple customers, where each customer has a different ticketing system. This adds additional overhead in switching between multiple systems. Finally, information required for finding the most appropriate SA for one specific ticket could reside in various locations and require different tools to access it. For example, schedules tend to be managed by calendar-based systems, while the SA’s actual workloads would be most accurately represented in Request Fulfillment systems and finally it is common to have SA skills associated with their user profile in the service provider’s directory.
System administrators (SAs) resolve requests using their technical expertise.
Request Fulfillment is supported by dispatchers, whose responsibilities include
Monitorar por novas requisições
Encaminhar requisições para os administradores apropriados
Monitorar acordância dos acordos nível de serviço