Книга: ИТ Сервис-менеджмент. Введение

Сноски из книги

· #1

ITIL является зарегистрированной торговой маркой агентства CCTA/OGC

· #2

Термин «ИТ Сервис-менеджмент», с одной стороны, используется как синоним термина «Управление ИТ-услугами», но, с другой стороны, усиливает его, имея в виду централизованный подход к менеджменту всей ИТ-организацией как современным сервисным подразделением, направленным на предоставление услуг бизнес-подразделения и являющихся неотъемлемым звеном в производственном процессе.

· #3

Framework (здесь и далее – англ.).

· #4

Policy (англ.). В данном случае – линии поведения, правила работы компании. Иногда переводится термином «внутренние политики компании».

· #5

Transformation

· #6

Ad hoc.

· #7

Под «цепочкой» понимается цепь создания прибавочной стоимости. – Прим. ред.

· #8

Total quality.

· #9

Ad hoc.

· #10

Policies

· #11

Stakeholders.

· #12

Actions.

· #13

Tasks.

· #14

Perspectives.

· #15

Период времени, который требует планирования. – Прим. ред.

· #16

Applications.

· #17

Human Resource Management – HRM.

· #18

Empowerment – данный английский термин имеет очень широкое значение и подразумевает «усиление» коллектива за счет оказания ему доверия, предоставления дополнительных полномочий, организации доступа к накопленным знаниям и т. д.

· #19

Accountability.

· #20

Competence management.

· #21

Mentors and coachers.

· #22

IT Customer Relationship Management – IT CRM.

· #23

Service Level Management – CLM.

· #24

Используемый здесь английский термин «alignment» дословно переводится как «выравнивание», «согласование», однако по сути отражает необходимость организации диалога между бизнесом и ИТ-департаментом таким образом, чтобы как стратегические, так и важнейшие тактические и оперативные вопросы обсуждались совместно.

· #25

Request for Change – RFC.

· #26

В данной книге в качестве перевода «activities» используются понятия «виды деятельности (работа)»

· #27

Суть терминов «effective» и «efficient» можно также проиллюстрировать выражения «делать правильные вещи» и «делать вещи правильно».

· #28

Вопрос владения и руководства процессом является сложным и в разных организациях решается по-разному. Далее в рамках этой книги будет использоваться термин «Руководитель Процесса» как перевод понятия «Process manager», объединяющий роли владельца и менеджера процесса. Это может иметь смысл для организаций, хотя это объединение не является единственным решением. – Прим. ред.

· #29

Performance indicators.

· #30

Capacity.

· #31

Framework.

· #32

Точным переводом названия «IT Infrastructure Library» является «Библиотека инфраструктуры информационных технологий», но, по мнению коллектива русской редакции, название «Библиотека передового опыта организации ИТ» более точно отражает ключевые принципы управления, используемые в мире при организации работы ИТ-подразделений, и отраженные в настоящее время в библиотеке ITIL.

· #33

Effective and efficient.

· #34

Framework

· #35

Efficient.

· #36

Effective.

· #37

Commitment of personnel at all levels in organization.

· #38

«OGC aims to modernize procurement in government, and deliver substantial value for money improvements».

· #39

«Best practices».

· #40

«Codes of practice».

· #41

Effective and Efficient.

· #42

User group.

· #43

Task forces.

· #44

Frameworks.

· #45

Generic Framework.

· #46

Service Support.

· #47

Service Delivery.

· #48

Business Perspective Set.

· #49

Customer Focus.

· #50

Demand Pull.

· #51

Supply Push.

· #52

Underpinning Contracts.

· #53

Costing.

· #54

Application Sizing.

· #55

Contingency Planning.

· #56

Request for Change.

· #57

Configuration Item (CI).

· #58

В литературе по ITIL понятие «функция» ассоциировано с вертикальным (линейным) подразделением организации, выполняющим соответствующие функциональные обязанности и фактически является его синонимом. – Прим. ред.

· #59

Incident.

· #60

Service Request.

· #61

Request for Change (RFC).

· #62

Configuration Item (CI).

· #63

Impact.

· #64

Urgency.

· #65

Priority.

· #66

Quick Fixes.

· #67

«Down».

· #68

Key Performance Indicators – KPI.

· #69

Knowledge Base.

· #70

Performance Indicators.

· #71

Effectiveness and Efficiency.

· #72

Т.е. программного обеспечения. – Прим. ред.

· #73

Commitment.

· #74

Request for Change – RFC.

· #75

Quick Fixes – быстрые исправления, быстрые решения или «заплатки», т.е решения, позволяющие быстро устранить инцидент, но не устраняющие ошибку.

· #76

Long-term Errors.

· #77

Historical Data.

· #78

Quick Fix.

· #79

Post Implementation Review – PIR.

· #80

Т.е. во время сопоставления новых инцидентов с известными ошибками. – Прим. ред.

· #81

Post Implementation Review – PIR.

· #82

Effectiveness.

· #83

Effectiveness and Efficiency.

· #84

Configuration Items – CI.

· #85

Configuration Management Database – CMDB.

· #86

Economic Value.

· #87

Scope.

· #88

Stakeholder.

· #89

Scope.

· #90

Service Request.

· #91

Варианты используются, если имеются несколько существующих одновременно форм Конфигурационной Единицы, т. е. если существуют параллельные отношения. Версии появляются, например, если одновременно используется и новая, и старая версии Конфигурационной Единицы, т. е. когда существуют последовательные отношения. Использование этих двух концептуальных понятий помогает при планировании изменений. Если в последующем каждый из вариантов будет разрабатываться отдельно, то для каждого из них нужно вводить отдельную систему нумерации версий, что нежелательно, т. к. это делает ИТ-инфраструктуру более сложной и ведет к увеличению работ по сопровождению. В большинстве случаев рекомендуется продолжать разработку исходного экземпляра всех вариантов, а там, где возможно, использовать новую версию для создания необходимых вариантов. – Прим. автора.

· #92

Naming Convention.

· #93

Definitive Software Library – DSL.

· #94

Т. е. меню со списком выбора вариантов. -Прим. ред.

· #95

Starting point.

· #96

В то же время Управление Конфигурациями сохраняет наивысшую ответственность за актуальность Конфигурационной Базы Данных, то есть возможно делегирование полномочий (но не ответственности) по регистрации результатов изменений из процесса Управления Конфигурациями в процесс Управления Изменениями. – Прим. ред.

· #97

Quick Wins.

· #98

Long-term errors.

· #99

Request for Change – RFC.

· #100

Steering Committee.

· #101

Executive Committee.

· #102

Change Advisory Board – CAB.

· #103

Emergency Committee – EC.

· #104

Scope.

· #105

Pre-authorized.

· #106

Account.

· #107

Forward Schedule of Change – FSC.

· #108

Projected Service Availability – RCA.

· #109

Upgrades.

· #110

Quick Fix.

· #111

IT Steering Committee.

· #112

Emergency Committee.

· #113

Forward Schedule of Change – FSC.

· #114

Back-out.

· #115

Building.

· #116

Performance Indicators.

· #117

Operational Acceptance.

· #118

Implementing.

· #119

Post Implementation Review – PIR.

· #120

Previous Trusted State.

· #121

Performance Indicators.

· #122

Effective.

· #123

Efficient.

· #124

Production Environment.

· #125

Definitive Software Library – DSL.

· #126

Definitive Hardware Store – DHS.

· #127

Work-arounds.

· #128

Quick Fixes.

· #129

Upgrades.

· #130

Previous Trusted State.

· #131

Standard Installation Scripts.

· #132

Definitive Software Library – DSL.

· #133

Installation Scripts.

· #134

Back-up.

· #135

Definitive Hardware Store – DHS.

· #136

Efficient.

· #137

Creating Images.

· #138

Build Management.

· #139

Previous Trusted State.

· #140

Disaster Recovery Plans.

· #141

Installation Scripts.

· #142

Rollout Scripts.

· #143

Т.е. как был определен релиз.

· #144

Operating Instructions.

· #145

Кроме того, для осуществления эффективной поддержки пользователей необходимо обеспечить информирование службы Service Desk о планируемом тиражировании (распространении) новых версий. – Прим. ред.

· #146

Accessibility.

· #147

Scripts.

· #148

Business Operations Support Desk.

· #149

Operations Bridge.

· #150

Под отделом эксплуатации (операционным отделом) понимается группа обеспечения операционной деятельности – Operations Department. – Прим. ред.

· #151

Production, Operations.

· #152

Service Requests.

· #153

Accounts.

· #154

Operations.

· #155

Effectiveness.

· #156

Service Level Agreements – SLA.

· #157

Operational Level Agreements – OLA.

· #158

Underpinning Contracts – UC.

· #159

Service Quality Plan – SQP.

· #160

Promotion.

· #161

Scope.

· #162

Quantifying.

· #163

Compose Service.

· #164

Service Specifications (Spec Sheets).

· #165

Charging.

· #166

Capacity.

· #167

Effectiveness and Efficiency.

· #168

Management Reports.

· #169

Operations.

· #170

Charges.

· #171

Direct Costs.

· #172

Indirect Costs.

· #173

Fixed Costs.

· #174

Variable Costs.

· #175

Capital Costs.

· #176

Operational Costs.

· #177

Budgeting.

· #178

Accounting.

· #179

Costing.

· #180

Charging.

· #181

По мнению редакторов, в настоящее время для ИТ этот период составляет 6-12 месяцев, при периоде долгосрочного планирования около 3-х лет.

· #182

Business Unit.

· #183

Rates.

· #184

KPI.

· #185

Cost-benefit analysis (CBA).

· #186

Capacity Management – более точным переводом является Управление «емкостью», т.е. управление мощностью вычислительных и телекоммуникационных средств и их потенциальными возможностями. – Прим. ред.

· #187

Advantages.

· #188

Efficiency.

· #189

Efficiently.

· #190

В данном случае это перевод словосочетания ad hoc.

· #191

Effectively.

· #192

Operational Processes.

· #193

Scripts.

· #194

Change Advisory Board – CAB.

· #195

Capacity Plan.

· #196

Request for Change – RFC.

· #197

Capacity Database – CDB.

· #198

Cost/benefit analysis.

· #199

Capacity Plan.

· #200

Simulation.

· #201

Baseline Assessment (Benchmark).

· #202

Host.

· #203

Application Sizing.

· #204

Application Sizing.

· #205

Operations.

· #206

Profiles.

· #207

Designers.

· #208

Benchmarks.

· #209

PABX.

· #210

Denial of Service – DoS.

· #211

Benefits.

· #212

Scope.

· #213

Business Impact Analysis.

· #214

Scope.

· #215

Stronghold/Fortress approach.

· #216

Skirmish Capability.

· #217

Recovery Options.

· #218

Cold Stand-by.

· #219

Fixed Facility.

· #220

Mobile Facility.

· #221

Warm Stand-by.

· #222

Upgrade.

· #223

Hot Start, Hot Stand-by.

· #224

Contingency Plan.

· #225

Host Computers.

· #226

Crisis Manager.

· #227

Fault-tolerant Systems.

· #228

Midrange Platform.

· #229

Effective.

· #230

Assurance.

· #231

Reliability.

· #232

Resilience – устойчивость: способность сервиса сохранять доступность при себе одного или нескольких ИТ-компонент. – Прим. ред.

· #233

Maintainability.

· #234

Recoverability.

· #235

Serviceability.

· #236

Availability Plan.

· #237

Recoverability.

· #238

Single Points of Failures – SPOF.

· #239

Component Failure Impact Analysis – CFIA.

· #240

CCTA Risk Analysis and Management – CRAMM.

· #241

Component Failure Impact Analysis – CFIA.

· #242

Recoverability.

· #243

Serviceability.

· #244

Availability Plan.

· #245

Component Failure Impact Analysis – CFIA.

· #246

Fault Tree Analysis – FTA.

· #247

CCTA Risk Analysis and Management Method – CRAMM.

· #248

System Outage Analysis – SOA.

· #249

Technical Observation Post – TOP.

· #250

Policy.

· #251

Management Framework.

· #252

Information Security Steering Committee.