Slt что это – Что означает SLT? -определения SLT — Primelens.ru-Зеркальные Фотоаппараты,Компактные Фотоаппараты,Видеокамеры,Объективы,Фотовспышки, и Аксессуары в Москве.

Slt что это – Что означает SLT? -определения SLT

Содержание

SLT — это… Что такое SLT?

SLT — is a three letter abbreviation that may refer to:* Short Loop Through, a signaling technique used in some DDR2 digital memory configurations, to be featured in the DDR3 memory standard. * Secondary lymphoid tissue, a component of the lymphatic… … Wikipedia

SLT — bezeichnet: die Stuttgarter Lasertage einen Schwerlasttransporter der Bundeswehr das Telekommunikationsunternehmen Sri Lanka Telekom die Selektive Lasertrabekuloplastie, ein medizinisches Verfahren aus der Augenheilkunde Diese Seite ist eine… … Deutsch Wikipedia

šlṭ — Definition: To dominate, rule, have power over. a. soldan, sultan, from Arabic sulṭān, power, authority, ruler, sultan, from Aramaic šulṭānā, power, authority, rule, ruler, from šǝlaṭ, to dominate, rule, prevail; b. sultana, from Arabic sulṭāna,… … The American Heritage dictionary of the English language

SLT — Схема Solid Logic Technology (SLT) Solid Logic Technology (SLT) гибридная технология компановки микроэлектронных схем на основе изолированных плоских, капсулированных в стекло, транзисторов и диодов, с экранированными щелком резисторами на… … Википедия

SLT — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français

Slt — Sous lieutenant Le grade militaire de sous lieutenant est le premier des grades d officiers dans nombre d armées. Sommaire 1 Armée belge 2 Forces armées canadiennes 3 Armée française 4 … Wikipédia en Français

šlṭ — To dominate, rule, have power over. a. soldan, sultan, from Arabic sulṭān, power, authority, ruler, sultan, from Aramaic šulṭānā, power, authority, rule, ruler, from šəlaṭ, to dominate, rule, prevail; b. sultana, from Arabic sulṭāna, feminine of… … Universalium

SLT — Slight (Medical » Physiology) ** Speech And Language Therapy (Academic & Science » Academic Degrees) ** Slit (Governmental » Military) * Selective Laser Trabeculoplasty (Computing » Networking) * Something Like That (Computing » SMS) * School… … Abbreviations dictionary

SLT — left sacrotransverse [fetal position, Lat. sacrolaeva transversa]; selective laser trabeculoplasty [for treatment of glaucoma]; single lumen tube; single lung transplantation; smokeless tobacco; solid logic technology * * * [L.] sacro laeva… … Medical dictionary

SLT — • Simulated Launch Test ( &GT; IEEE Standard Dictionary ) • Solid Logic Technique/Technology ( &GT; IEEE Standard Dictionary ) • Salida, CO, USA internationale Flughafen Kennung … Acronyms

SLT — ● sg. ►IRC Abrév. de Salut … Dictionnaire d’informatique francophone

dic.academic.ru

Sony Alpha SLT — это… Что такое Sony Alpha SLT?

Sony α SLT-A55

Годы выпуска	2010 — настоящее время
Тип	цифровой зеркальный фотоаппарат
Матрица	APS-C (кроп-фактор 1,5) CMOS (размер 23,5×15,6 мм).
Плотность пикселов	4,4 Мп/см²
Разрешение	16,2 миллионов пикселей.
Объектив	Байонет A.
Затвор	Контролируемый электроникой, вертикального хода, шторно-щелевого типа.
Диапазон выдержек	30 — 1/4000 сек., BULB
Экспозиция	TTL-замер при полностью открытой диафрагме.
Режимы экспозамера	Центрально-взвешенный, оценочный, точечный.
Брекетинг экспозиции	3 кадра, ±0.3EV, ±0.7EV
Зоны фокусировки	15-точечная автофокусировка с тремя крестообразными датчиками.
Серийная съемка	До 10 к/с при ручной фокусировке.
Видоискатель	Электронный, с полем зрения 100% и увеличением 1,1
Диапазон ISO	ISO 100-12800, до 25600 в режиме мультиэкспозиции.
Фотовспышка	Встроенная с автоподнятием и ВЧ 10. Внешняя TTL через «башмак».
Съемка видео	FullHD (1920×1080) в H.264, HDTV (1440×1080) в MP4.
Экран	Отклоняемый 3-дюймовый (7,5 см) TFT-экран, 921 600 пикс.
Накопитель	SD/SDHC/SDXC или Memory Stick Pro Duo/Memory Stick PRO-HG Duo.
Габаритные размеры	124 × 92 × 85 мм
Вес	441 г

Sony SLT-A55 с «китовым» объективом

Sony Alpha SLT — линейка цифровых зеркальных фотоаппаратов фирмы Sony (single-lens translucent). От традиционных DSLR отличается наличием полупрозрачного неподвижного зеркала вместо «прыгающего» зеркала. Первоначально, в августе 2010 были представлены две модели: Sony SLT-A33 (14,2 млн пикселов) и SLT-A55 (16,2 млн), в июне 2011 года появилась Sony SLT-A35, а в августе — SLT-A65 и SLT-A77.

Преимущества

Возможность достижения большой скорости серийной съемки (за счёт отсутствия необходимости поднимать и опускать зеркало) — до 12 кадров/с у Sony SLT-A77 (при разовом замере экспозиции и расстояния по первому кадру).
Возможность непрерывной работы фазового автофокуса не только при фотосъемке, но и в видеосъемке, а также в режиме LV (визирование по экрану) чего нет в камерах конкурентов
Отсутствие звука хлопающего зеркала

Более крупный видоискатель по сравнению с камерами подобного класса
Отображение в видоискателе всей информации включая электронный уровень, гистограммы и возможности работы с меню
Компактные размеры камеры

Недостатки

Полупрозрачное зеркало разделяет световой поток между матрицей и датчиками автофокуса, за счет чего на матрицу попадает меньшее количество света. Но это компенсируется светочувствительностью матрицы, а так как потеря света небольшая — подобные потери света практически не сказываются на качестве изображения. Однако, побочным эффектом повышения чувствительности является усиление цифрового шума. К тому же, постепенное загрязнение зеркала приводит к ухудшению качества снимков. С другой стороны, поскольку полупрозрачное зеркало неподвижное, вероятность попадания пыли непосредственно на матрицу значительно уменьшается, а полупрозрачное зеркало поддается чистке. Кроме того, в таких фотоаппаратах невозможно использование зеркального видоискателя, поэтому вместо него устанавливается электронный видоискатель, который обладает ограниченным временным, пространственным и цветовым разрешением. Однако, в сравнении с зеркальными видоискателями бюджетных DSLR, у него есть и преимущества — охват 100 % кадра, значительно большие размеры и большая информативность. Ghosting-эффект

Функционал

Sony SLT-A55 имеет следующие функции:

GPS-модуль
режим Sweep Panorama
режим 3D Panorama, для просмотра изображений на 3D телевизорах Sony.
серийная съёмка на скорости 3,6 или 10 (только у Sony SLT-A55) кадров в секунду.
съёмка в режимах оптимизации цветового диапазона и расширения цветового диапазона HDR (только для формата JPG)
режим многокадрового шумоподавления (только для формата JPG).

Sony Alpha SLT-A35

Представлена в июне 2011 как замена камеры SLT-А33.

Другие фотокамеры с полупрозрачным зеркалом

Canon Pellix — 1965 год
Canon F-1 High Speed — 1972 год

Nikon F2H — 1976 год
Canon EOS RT — 1989 год
Canon EOS-1N RS — 1995 год
Sony DSC-D700 — 1998 год
Olympus E-10 — 2000 год
Pentax EI-2000 — 2000 год
Olympus E-20 — 2001 год

Цифровые зеркальные фотоаппараты Konica Minolta/Sony α
Single-lens translucent (SLT) камеры

dic.academic.ru

SLT — это… Что такое SLT?

SLT — ● sg. ►IRC Abrév. de Salut … Dictionnaire d’informatique francophone

technical_abbreviations.academic.ru

SLT, OLA, SLA. Сложно о простых буквах::БИТ 10.2015

SLT, OLA, SLA. Сложно о простых буквах

Сергей Барамба, Заместитель ИТ-директора ООО «БФТ»

KPI не равно SLA

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

Разумеется, имеет смысл обратиться к официальному словарю ITIL [1] (см. врезку). Сразу же бросается в глаза ключевое различие в сути каждого из этих терминов. Если в SLA обязательно участвуют две стороны (заказчик и поставщик услуг), и это список измеряемых характеристик оказываемой услуги и сроков исправления нарушений ее предоставления, то KPI – это некий показатель, которым измеряют фактически предоставляемые услуги.

Краткий словарь терминов

SLA (Service Level Agreement) – Соглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон – поставщика ИТ-услуг и заказчика.

KPI (Key Performance Indicator) – Метрика, которая используется для управления ИТ-услугой, процессом, планом, проектом или другой деятельностью. Ключевые показатели эффективности используются для измерения реализации ключевых факторов успеха.

SLR (Service Level Requirement) – Требование к уровню услуг. Требование заказчика к ИТ-услуге. Требования к уровню услуг основаны на бизнес-целях и используются для переговоров и согласования целевых показателей уровня услуг.

Если в SLA, как в любом договоре, возможно внести санкции за некачественное исполнение, то KPI сам по себе только виртуальная полоса на графике взлетов и падений уровня сервиса. KPI всегда остается безучастным к невыполнению показателей, а только безмолвно фиксирует отклонение. Ну и последнее: хотелось бы отметить, что соблюдение требований, описанных в SLA, используется как основной ключевой показатель эффективности (KPI) ИТ-отдела.

В самом начале

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

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

Но это в идеальной картине книг ITIL. Чаще всего инертность и безразличие «бизнеса», а порой просто непонимание, что же конкретно требовать от ИТ, приводит к тому, что и SLR подготавливается в стенах ИТ-подразделения. А затем вся связка необходимых документов преподносится на обсуждение руководству компании исходя исключительно из цифр выделенного на ИТ бюджета. В ИТ-службе не до конца способны понимать такой параметр для оказываемых ими услуг, как «критичность для бизнеса», «затронутые бизнес-транзакции» и действительно требуемый уровень услуг для поддержания функционирования зависимых подразделений.

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

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

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

Если свести этот документ к некому формуляру, данные из которого можно смело переносить в SLA и использовать для создания KPI, то получится вот такой список (см. таблицу 1).

Таблица 1. Формуляр, данные из которого можно переносить в SLA и использовать для создания KPI

Описание услуги	Указывается общепонятное название услуги, которое должно быть понятно при использовании как внутри компании, так и за ее пределами. В этом же пункте описываются «Критерии успеха», т.е. в каких условиях данная услуга считается оказанной качественно. Например, если услуга в рабочие часы доступна 99% времени, значит, она оказывается успешно. Не лишним будет указать емкость данной услуги, описав, если возможно, такие параметры, как: возможность выполнять запросы «X» количества пользователей; количество транзакций в минуту/секунду; границы пиковых нагрузок
Распределение ролей и ответственных за услугу	В этом разделе отображаются конкретные имена владельцев и исполнителей, ответственных за услугу как со стороны бизнеса, так и от ИТ
Требования по поддержке услуги	Необходимо указать, каким образом бизнес-заказчик представляет временные рамки по доступности системы, ее регламентированному обслуживанию и исправлению возникших сбоев
Задействованные подразделения	Описываются зависимые от услуги подразделения компании. Если с почтой или 1С, как правило, все понятно, то с какой-нибудь новой CRM-системой или мобильным приложением может быть не все очевидно
Задействованные бизнес-транзакции	В этой части необходимо описать, какие важные для бизнеса действия осуществляются, используя именно этот сервис, что будет невозможно выполнить, если сервис перестанет функционировать. Данный параметр поможет более корректно выставлять приоритеты во время поступающих инцидентов
Инциденты и сбои	Первое, с чего необходимо начать заполнение данного раздела, – это описать способы корректных коммуникаций для того, чтобы обратиться в ИТ-подразделение, и, наоборот, ИТ-службе корректно информировать сотрудников о событиях, происходящих с данной услугой. Тут также описываются целевые показатели времени решения выявленных инцидентов и сбоев в зависимости от их приоритетов. Нелишним будет ввести таблицу передачи разрешения инцидента на более высокий уровень, распределив моменты эскалирования в зависимости от приоритета и прошедшего времени
Плановый простой услуги	Плановое обслуживание элементов, необходимых для качественного оказания услуги, требует планирования времени простоя (Downtime), которое не будет считаться как сбой или прерывание оказания услуги. В этом разделе необходимо описать возможную частоту, временные рамки и способы информирования, если необходимо, о фактах прерывания на плановое обслуживание, предоставления услуги
Запросы на обслуживание и обучение	Необходимо указать, каким образом формируются «запросы на обслуживание», в какие сроки и в каких объемах возможно исполнение обращения по данной услуге. Как правило, введя в действие услугу, редко задумываются о том, что необходимо произвести обучение по корректному использованию услуги, а это может оказаться важным элементом требований бизнеса

OLA (Operational Level Agreement, Соглашение операционного уровня)

Если услуги, описанные в SLR, зависят от действий других подразделений компании, возникает необходимость в создании отдельного регламента по взаимодействию между собой в целях соблюдения разрабатываемого SLA.

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

Словарь ITIL дает определение для OLA как «Соглашение между поставщиком ИТ-услуг и другой частью той же организации». Слова «той же организации» являются ключевыми.

Если, например, речь идет о соглашении по срокам исправления неисправности доступа в сеть интернет или качества самого соединения со стороны провайдера, то это с точки зрения ITIL будет «Внешний договор» (UC, Underpinning Contract).

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

Как правило, большинство организаций ограничивается регламентами взаимодействия между подразделениями и жестко зафиксированными сроками движения заявок внутри автоматизированных систем, например, СЭД, к которым имеют доступ все подразделения.

Ради чего все эти сложности

Собрав требования бизнеса (SLR) и договорившись с нужными для оказания услуг подразделениями (OLA), можно приступать к написанию итогового документа – «Соглашения об уровне услуг». Все зависимости документов изображены на рис. 1.

Рисунок 1. Схема создания SLA

На практике чаще всего запускают процесс разработки SLA в моменты внедрения в ИТ- службе Service Desk-системы, даже минуя этап SLR, сначала это не будет видно, но в процессе эксплуатации систем время расставит все на свои места. Разумеется, не надо забывать, что SLA является обязательной частью любых договоров, связанных с аутсорсингом ИТ-услуг. Итоговой целью создания SLA является то, что обе участвующие стороны переходят на единый понятийный уровень в отношении качества услуг.

С точки зрения здравого смысла и теоретических вкладок ITIL разработка SLA происходит на стадии Service Design, т.е. тогда, когда сервис еще не запущен в промышленную эксплуатацию и только готовится к внедрению. Для уже внедренных сервисов происходит пересмотр SLA и остальных параметров, тоже на стадии Service Design. Разработка SLA сама по себе влечет за собой пересмотр архитектуры ИТ- инфраструктуры для появления разрабатываемого сервиса, если по факту текущего состояния обеспечить выполнение условий не представляется возможным. Понятное дело, что также пересматриваются уже текущие бизнес-процессы, и внутрь них накладываются новые.

Само по себе соглашение (SLA) должно содержать четкие ответы на следующие четыре вопроса:

Какие сервисы?
Кому конкретно предоставляются?
Какого именно качества он должен быть?
В какие сроки должны быть устранены отклонения от описанных параметров в п. 3?

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

Разработка полноценного «Соглашения об уровне услуг» – показатель зрелости бизнес-процессов в ИТ-подразделении компании и определенный шаг вверх

По определению в официальной книге ITIL:Service Design в зависимости от разреза услуги SLA делятся на три группы [2]:

Service-based (От услуги) – все заказчики получают одинаковые условия на один и тот же сервис.
Customer-based (От потребителя) – условия различаются в зависимости от заказчика (и, разумеется, за разную цену).
Multi-level (Многоуровневый) – условия описываются для компании, клиентов и служб, при этом каждый раз они различаются.

Для упрощения написания SLA подходят к разработке некого единого общего «соглашения» (Default SLA), включенного в «Каталог услуг», при этом все потребители получают общий набор сервисов с единым уровнем обслуживания и максимальным сроком исполнения поступивших обращений. В случаях, если какое-либо бизнес-подразделение не устраивает общий уровень по группе сервисов или даже по всему списку, тогда разрабатывается отдельный документ, «специально» описывающий особые условия.

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

Как и что писать

Сразу отмечу, что настоящее SLA – это серьезно, потому что это часть юридически значимого документа. Не все внутренние ИТ-службы готовы включить «режим юриста» и заняться написанием умных слов о сервисах, которые они изо дня в день поддерживают на плаву. Термины и даже окончания терминов оказываются важны, потому что, появившись, документ, превращается в обоюдоострый меч, которым будут колоть как ИТ-подразделение, так и мы будем отбиваться от обоснованных и не очень обвинений.

Если невозможно распространить действие документа на всю организацию, тогда требуется создавать отдельные версии соглашения для различных площадок

Главным посылом при разработке документа должно выступать для обеих сторон желание устанавливать реальные нормы качества для SLA, с учетом возможностей подразделения и целевых показателей, описанных в SLR. Ну, конечно, нельзя подходить к процессу с точки зрения «генерации» договора с красивыми, но не отражающими реалии словами.

Собирать информацию для данного документа рекомендуется:

на основе опроса ключевых пользователей и руководителей;
с учетом важности и влияния каждого сервиса;
на основе совместного анализа предыдущего опыта работы службы;
разумного баланса между необходимой срочностью устранения инцидента и реальными возможностями.

Большинство SLA после преамбулы начинаются с раздела «Термины». Это очень хорошо, потому что этим достигается важная цель – единый понятийный аппарат в оценке сервисов.

Важно не забыть и дать описания таких понятий, как «Аварийная ситуация», «Инцидент», «Стандартное время регламентных работ (обслуживания)», «Доступность» и «Система регистрации заявок».

Обязательным требованием при создании документа является указание срока начала действия соглашения и даты следующего его пересмотра.

Если невозможно распространить действие документа на всю организацию, тогда требуется создавать отдельные версии соглашения для различных площадок.

Центральной частью документа является сводная таблица, в зависимости от требований к градации уровней сервиса она может иметь от трех до пяти различных уровней. Как правило, хватает всего трех: низкий, средний, аварийный. Критерием для определения уровня, под который попадает зафиксированный инцидент, в основном является «Количество вовлеченных пользователей», но иногда используются другие критерии, которые неплохо определять в специально отведенном разделе документа. В этом месте хочется обратить внимание, что измерение чего-либо стоит определенных денег.

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

Таблица 2. Уровни «деградации» сервиса

Уровень сервиса	Время реакции на запрос (передача запроса на исполнение ответственному специалисту)	Время выполнения (информирование заказчика о факте завершения запроса)
Аварийный	15 минут	1 час
Средний	20 минут	8 часов
Низкий	1 час	24 часа

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

SLA – не обязательно документ с подписями и печатями

Для внутренней ИТ-службы компании регулярно возникает вопрос: «Нужно ли такое соглашение внутри компании?» Может оказаться, что по политическим или культурным соображениям от ИТ-подразделения не требуется формировать полноценный двухсторонний документ, в рамках которого прописывать все необходимые требования и указать штрафные санкции. Но сроки устранения неисправностей никуда не деваются, и поэтому руководитель ИТ-службы заранее для подчиненных определяет некие «стандарты», которые окружающим подразделениям, как правило, не оглашаются или имеют общую формулу «Мы постараемся решить ваш вопрос в течение суток».

Вот такое внутреннее SLA еще называют соглашением о намерениях. Показатели SLA прописаны только внутри службы ИТ, и слежение за исполнением его требований производится только руководителем подразделения.

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

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

Как мы выяснили, просто так разбрасываться «умными» терминами не стоит, лучше понимать, что же скрывается за красивыми аббревиатурами.

Как пел капитан Врунгель в знаменитом мультике: «Как вы яхту назовете, так она и поплывет». Для нас же важно понимание того, что теми положениями, которые вписываются в документы, и будет возможность воспользоваться для защиты подразделения в сложные моменты и не свалиться в «хаосный штопор» от поступающих заявок от пользователей.

Словарь терминов и определений ITIL 2011 на русском языке – http://www.itsmforum.ru/ZAM-test.
«ITIL® Service Design 2011edition», London: TSO, ISBN 9780113313051, p.111.

Комментарии могут отставлять только зарегистрированные пользователи

bit.samag.ru

Slt — это… Что такое Slt?

SLT — ● sg. ►IRC Abrév. de Salut … Dictionnaire d’informatique francophone

universal_en_ru.academic.ru

SLT — это… Что такое SLT?

SLT — ● sg. ►IRC Abrév. de Salut … Dictionnaire d’informatique francophone

normative_en_ru.academic.ru

SLT — это… Что такое SLT?

SLT — ● sg. ►IRC Abrév. de Salut … Dictionnaire d’informatique francophone

it_en_ru.academic.ru