PBL (LTMA, Абонентское обслуживание, далее по списку)

Strek

Местный
Уважаемые коллеги!!!

А не замутить ли нам темку на предмет деятельности, которая описывается разными терминами, например, Абонентское Обслуживание, Performance Based Logistic (PBL), Обеспечение Готовности, Full In-Service Support (FISS)?

Т.е., говоря по простому, поговорить о приципах, организации, составе, особенностях, тонкостях технических и юридических и т.д. по предоставлению Закачику услуг по обеспечению Заданного Коэффициента Готовности евойного парка.
 
Реклама
А также в свете вышесказанного еще и необходимость и возможность ГЧП (государственно-частного партнерства) между, например, Государством в лице МО и Промышленностью (Авиапром).
 
Хорошая тема. Правильная. Давно заметил - никто до сих пор по настоящему не брался перетереть важнейший вопрос: ЗА ШО И КАК ЭКСПЛУАТАНТ ДОЛЖОН ПЛАТИТЬ ПРОВАЙДЕРУ СЕРВИСНОЙ ПОДДЕРЖКИ. Бизнес-модель послепродажного сервиса авиационной техники по-прежнему для многих из нас остается темным пятном.
От себя добавлю наводящий вопросец принципиального значения - и шо такое SLA (Service Level Agreement) применительно к рассматриваемой теме? А точнее - что такое Service Level? В каких попугаях он меряется (а он же как пить дать - меряется!). И как потом этот самый Уровень Сервиса тарифицируется? Как строится расчет деньгами между клиентам и провайдером за полученный сервис в зависимости от его уровня?
P.S.:
"У нас никто ниче ни панимаит! Даже специалисты, которые лучше других этого ни панимают, молчат!" (с) М.Жванецкий (У нас будет лучше!) :)
 
Для затравки:
------------------------------------
ОАЭ заказали шесть C-17
Москва. 10 января. АвиаПорт - Американский авиапроизводитель Boeing и ВВС и ПВО Объединенных Арабских Эмиратов подписали контракт на поставку шести тяжелых транспортных самолетов C-17 Globemaster III, говорится в сообщении Boeing.

Согласно сообщению, ОАЭ получат первые четыре самолета в 2011 году, а оставшиеся два - в 2012 году. Стоимость и финансовые условия сделки не раскрываются. В рамках контракта предусмотрено послепродажное обслуживание, включая интегрированную логистическую поддержку.

===================

И
Индия закупает C-17
http://www.forumavia.ru/forum/5/2/940995057794711809541257779552_1.shtml?topiccount=58
 
А точнее - что такое Service Level? В каких попугаях он меряется (а он же как пить дать - меряется!). И как потом этот самый Уровень Сервиса тарифицируется? Как строится расчет деньгами между клиентам и провайдером за полученный сервис в зависимости от его уровня?

Если, честно, то я не слышал про SLA применительно к АТ. Хотя, "приципы в принципе" везде одинаковы. Наверное в IT это более проработано и развито, чем в авиации. Юр, спасибо за наводку! Энтэресное дело. Можно брать за матрицу. Ессно "мерять" это можно от простого определения достигнутого Ао (к-та Готовности), до какого нибудь "Показателя Удовлетворения Ожиданий Заказчика" :)
 
И, кстати, тут когда-то (несколько лет назад) теоретический спор был об за то, как заставить эксплуатанта делиться инфой с разработчиком. Чувствую, решение проблемы - как раз в бизнес-модели послепродажного сервиса. Ежли обратную связь от эксплуатанта "вплести" в формулу платежей за сервис, то все может очень даже аккуратно работать. Иными словами, если клиент платить провайдеру за достигнутый фактический перфоманс (Service Level), а его измерение базируется на отой самой обратной связи, то никуда клиент не денется. Будет аккуратно собирать необходимые данные и слать провайдеру. Ибо на этих данных в конце концов базируется выставляемый счет за сервис.. :)
 
Валер, вон - почитай тут:
***********************************************************************************
A service level agreement (frequently abbreviated as SLA) is a part of a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service) or performance.
***********************************************************************************
http://en.wikipedia.org/wiki/Service_level_agreement
Ноги канешна растут даже не из ИТ, а из телекомов. Вернее контрактов телекомов с корпоративными клиентами. Оттедва название SLA. Потом уже пошло-поехало приживаться повсюду, где продается сервис, а не продукт... :)
 
Последнее редактирование:
Согласен. В подобного рода отношениях между Заказчикм и Исполнителем вопрос информационного обмена является одним из ключевых.

Причем если со стороны Исполнителя это может быть элементов Информационной (Инженерной) составляющей пакета услуг (кстати, тоже тарифицируемая вещь), то со стороны Заказчика предоставление информации об эксплуатации должно быть обязательным условием для обеспечения выполнения SL. Ессно для военных контрактов это несколько сложнее, но тоже решаемо.
 
Юр, так на шо человеку голова и гугль! :) Уже нашел. Интересно. Есть полезные идеи.
 
Совершенно верно. Ежли, например, размер ежеквартального обязательного премиального вознаграждения провайдеру сервиса по контракту зависит от количества отказов той или иной категории в тех или иных системах, то клиент таки будет автоматом обязан вести учет всех отказов матчасти как положено и направлять эту инфу провайдеру ППО, а через него эта инфа естественным путем попадет к разработчику. Обратная связь замкнулась...
 
Реклама
Совершенно верно. Ежли, например, размер ежеквартального обязательного премиального вознаграждения провайдеру сервиса по контракту зависит от количества отказов той или иной категории в тех или иных системах, то клиент таки будет автоматом обязан вести учет всех отказов матчасти как положено и направлять эту инфу провайдеру ППО, а через него эта инфа естественным путем попадет к разработчику. Обратная связь замкнулась...

Видете ли Юра! Вопрос о вознаграждениях провайдеру (исполнителю сервисного контракта) весьма спорный. Не говорю, что не реальный, не простой. Особенно в области милитаризма. В связи с этим, связь между бонусами Провайдеру и информацией от Заказчика не так очевидна. Обязательства обмена информацией должны быть инкорпорированы в методику определения SL. Т.е. в целевую функцию, таким образом, чтобы недостаток информации реально учитывался при определении степени исполнения сервисного контракта.
 
Вобщее, подобного рода контрактах (Обеспечение готовности парка ВС) информационое взаимодействие между Исполнителем и Заказчиком намного сложеее, нежели просто информация об отказах. Предлагаю вернуться к этому позже. А сейчас обсудить непосредственно то, что называется Service Level - SL.

Сдается, что это комплексный показатель, состоящий как из измеряемых параметров, таких как Коэффициент Готовности (Ао), так и из экспертных (удовлетворенность, скорость реагирования, отношение к проблемам Заказчика). Нет? :)
 
Предлагаю вернуться к этому позже. А сейчас обсудить непосредственно то, что называется Service Level - SL.
Сдается, что это комплексный показатель, состоящий как из измеряемых параметров, таких как Коэффициент Готовности (Ао), так и из экспертных (удовлетворенность, скорость реагирования, отношение к проблемам Заказчика). Нет?
Почему же нет? Таки да! :)
Шо касается милитаризма - мот лучше перетереть этот вопрос с каким-нить профильным НИИ МО? Или лучше - с кем-то из известных ученых оттуда. Пока чисто в теоретическом плане. На моей памяти был когда-то был такой институт - НИИЭРАТ... Главный вопрос - как военным перейти от поштучной закупки запчастей и расходных материалов к сервисному контракту (SLA)? Для них это неслабая рэволюция... Конешно самый подходящий момент для такой рэволюции - перевооружение на новую технику. Аднака и авиапром должен быть готов к такому переходу! Вообще-то, по идее, за для "безударности" такой трансформации концепт нового подхода к сервису должен разрабатываться чуть ли не одновременно с разработкой новой системы ВВТ...
Кстати, у военных ученых можно поживиться и самими показателями. В полках, насколько я помню, всегда шла борьба за боеготовность. Типа - сколько машин полк готов поднять в воздух в любое время суток. Дальше нужно бить на составляющие - от чего зависит и их чего состоит боеготовность полка...
 
Последнее редактирование:
В целом тема безусловно актуальная. Только вот владеем мы ей пока слабо, обязуюсь почитать по мере сил...
Вот к этому
был такой институт - НИИЭРАТ...
добавить нечего, к сожалению :(


у военных ученых можно поживиться и самими показателями. В полках, насколько я помню, всегда шла борьба за боеготовность. Типа - сколько машин полк готов поднять в воздух в любое время суток.
Там больше липа была, поскольку долю боеготовых считали не от общего числа ЛА, а от текущего списочного состава, за вычетом направленных в капитальный ремонт (чего никогда не было у "главного супостата", там FMC/MC всегда считали по всему парку полка-крыла, вне зависимости от того, где простаивает конкретный борт)
 
Юр, не будем о грустном, я имею ввиду отечественных милитаристов.

Давай за SL поговорим. Вот как ты думаешь, стоит ли к понятной метрике Ао добавлять некие эмпирические коэффициенты и поправки? Или тупо считать, есть к примеру Ао=0,85 (допустим, что это задано в контракте) или нет. И в зависимости от этого либо штрафы, либо бонусы Исполнителю? Шо скажешь?

Т.е., SL = Ао?

Или таки , SL = Ao + K1 + K2 + Ki?

Что можно учитывать в Кi?
Например, в случае проработки контракта на абонентское обслуживание, обычно из области отвественности Исполнителя выбрасываются такие вещи:

- Нарушение требований инструкций по летной и технической эксплуатации, и любой другой документации, официально поставленной Поставщиком Самолета и оборудования;
- Нарушение правил транспортировки, хранения, испытаний самолета и его агрегатов и изделий;
- Авария, Авиационное Происшествие, случившаяся с Самолетом или любой его частью;
- Попадание посторонних предметов в работающий двигатель Самолета или повреждение любой части самолета, по вине Заказчика;
- Неисправности, связанные с попаданием самолета в сложные метеоусловия, грубая посадка, выкатывание самолета за пределы ВПП;
- Доработка, выполненная на каком-либо Самолете или его части персоналом Закачика или третьей стороной, без предварительного письменного согласия Поставщика Самолета;
- Отсутствие маркировки (таблички с заводской маркой на изделии/детали/блоке/модуле) Самолета или, в более общем случае, невозможность идентификации изделия/детали/блока/модуля Самолета, как первоначально установленные на Самолет;
- Возникновение отказов на оборудовании третьих сторон (стран) или по причине отказа такого оборудования;
- Отказ, неисправность или повреждения, возникшие на Самолете в результате воздействия третьих лиц;

т.е. за все вышеперечисленное Исполнитель отвественности не несет и простои самолета по этим причинам исключаются из методики расчета достигнутого коэффициента готовности. Соотвественно не применяются штрафные санкции, если готовность меньше заданной.

Так вот, а что если Исполнитель готов максимально быстро устранять простои вызванные причинами, указанными выше. Почему бы эту готовность и мероприятия с этим связанные не оформить в виде добавочных коэффициентов к SL?
 
Последнее редактирование:
Хех... Не все так легко складывается. Пока даже на уровне понятий и определений. Вот что об за SL говорит "Маркс" (CMMI v.1.2 for Services):
__________________________________________________________________
5. Define service levels.
Defined service levels make the levels of service that are offered specific and measurable. Service levels may help to balance cost and demand for services, and make roles and responsibilities between the service provider and user clear.
Determining service levels includes the following service requirements:
• The maximum acceptable continuous period of lost service
• The maximum acceptable period of degraded service
• Acceptable degraded service levels during the period of service recovery
• Redundancy requirements
Standard service levels may be reflected in standard SLAs or templates for SLAs.
Service level information includes the following:
• Provider and user responsibilities
• Availability of the service
• Agreed service hours and exceptions
• Anticipated service volume
• Response times for service incidents and requests
• Performance or quality targets
• Key measures to monitor
• Reporting and escalation procedures
• Consequences of failure to achieve a service level
• Variations available (e.g., “gold” service)
_____________________________________________________________________
Судя по всему, Ао в нашем клиническом случае - это Performance or quality targets. Т.е. - далеко не все, с чем нуна определиться при разработке бизнес-модели ППО...
 
Determining service levels includes the following service requirements:
• The maximum acceptable continuous period of lost service
• The maximum acceptable period of degraded service
• Acceptable degraded service levels during the period of service recovery
• Redundancy requirements
Это больше к системам непрерывного действия, как-то ..., т.е. сервис является внешней услугой, которую используют постоянно. К самолету это специально приспосабливать надо (с допущениями и оговорками), поскольку эксплуатант сам порождает service используя ВС, а внешние услуги ему нужны не постоянно, а в некий нужный момент, т.е. в целом система циклического действия с переменными циклами
 
Это больше к системам непрерывного действия, как-то ..., т.е. сервис является внешней услугой, которую используют постоянно. К самолету это специально приспосабливать надо (с допущениями и оговорками), поскольку эксплуатант сам порождает service используя ВС, а внешние услуги ему нужны не постоянно, а в некий нужный момент, т.е. в целом система циклического действия с переменными циклами
Хех... Не согласен. Аффтары утверждают следующее:
___________________________________________________________________
The CMMI-SVC model has been developed to be compatible with this broad definition. CMMI-SVC goals and practices are therefore potentially relevant to any organization concerned with the delivery of services, including enterprises in sectors such as defense, information technology (IT), health care, finance, and transportation. Early users of CMMI-SVC during its development and piloting report delivering services as varied as training, logistics, maintenance, refugee services, lawn care, book shelving, research, consulting, auditing, independent verification and validation, human resources, financial management, health care, and IT services.
__________________________________________________________________

Ну и вот еще об за непосредственных разработчиков:
__________________________________________________________________
The Version 1.2 CMMI-SVC Model Team collected input from reviewers and users to create CMMI-SVC, Version 1.2.
• Drew Allison, Systems and Software Consortium
• Rhonda Brown, Software Engineering Institute
• Brandon Buteau, Northrop Grumman
• Eileen Clark, SRA International, Inc.; Tidewaters Consulting, LLC
• Eileen Forrester, Software Engineering Institute
• Craig Hollenbach, Northrop Grumman
• Mike Konrad, Software Engineering Institute
• Frank Niessink, DNV
• M. Lynn Penn, Lockheed Martin
• Roy Porter, Northrop Grumman
• Rich Raphael, MITRE Corporation
• Pamela Schoppert, SAIC
• Sandy Shrum, Software Engineering Institute
• Jerry Simpson, SAIC
• Jeff Zeidler, Boeing
______________________________________________________________

А это - те, кто направлял дейтельность разработчиков:
______________________________________________________________
The CMMI Steering Group has guided and approved the plans of the version 1.2 CMMI Product Team, provided consultation on significant CMMI project issues, ensured involvement from a variety of interested communities, and approved the final release of the model:
• Kristen Baldwin, OUSD (AT&L) SSE/SSA
• Clyde Chittister, Software Engineering Institute
• Jim Gill, Boeing Integrated Defense Systems
• John Kelly, NASA HQ
• Kathy Lundeen, Defense Contract Management Agency
• Larry McCarthy, Motorola, Inc.
• Mike Nicol, U.S. Air Force ASC/EN
• Lawrence Osiecki, U.S. Army
• Bill Peterson, Software Engineering Institute
• Bob Rassa, Raytheon Space & Airborne Systems
• Kevin Stamey, AFMC/EN
• Joan Weszka, Lockheed Martin
• Hal Wilson, Northrop Grumman
• Brenda Zettervall, U.S. Navy, ASN/RDA CHENG
____________________________________________________________

Приспосабливать к самолету конечно нада, как и к любым другим областям. На то она и базовая модель, шоп ее можно было адаптировать. А насчет непрерывности действия - не согласен. Из того же источника:
____________________________________________________________
Service delivery is accomplished through the operation of the service system in response to service requests, which are communications from customers or end users that identify a need to deliver an agreed service. These requests are made within the context of an accepted service agreement.
There are two types of service requests:
• Those that are specified on a continuous or scheduled basis as determined by service agreements
• Those that are identified over time by customers or end users as their needs develop on an ad-hoc basis
Examples of ad-hoc requests include the following:
• Requesting a custom-made query on a database as part of a systems management service
• Calling for a package pick up as part of a package delivery service
• Identifying a broken component of a maintained system as part of a maintenance service
• Requesting a health check as part of a health program

Whatever the nature of a specific service request, it should be recorded, tracked, and resolved through some type of request management system. This approach helps to ensure that all service requests are fulfilled to meet service agreements. The response to service requests also encompasses performing any needed low-level planning as a detailed extension of broader project planning activities.
___________________________________________________________________

Ну и вот еще пара цитат из области понятий и определений, чтоб уже расставить все точки над Ё (оттуда же):
___________________________________________________________________
service system

An integrated and interdependent combination of component resources that satisfies service requirements. (See also “service system component” and “service requirements.”)
A service system encompasses everything required for service delivery, including work products, processes, facilities, tools, consumables, and human resources.
Note that a service system includes the people necessary to perform the service system’s processes. In contexts where end users must perform some processes for service delivery to be accomplished, those end users are also part of the service system (at least for the duration of those interactions).
A complex service system may be divisible into multiple distinct delivery and support systems or subsystems. While these divisions and distinctions may be significant to the service provider organization, they may not be as meaningful to other stakeholders.

service system component

A resource required for a service system to successfully deliver services.
Some components may remain owned by a customer, end user, or third party before service delivery begins and after service delivery ends. (See also “customer” and “end user.”)
Some components may be transient resources that are part of the service system for a limited time (e.g., items that are under repair in a maintenance shop).
Components may include processes and people.
The word “component” may be used in place of “service system component” for brevity when the context makes this meaning clear.
The word “infrastructure” may be used to refer collectively to service system components that are tangible and essentially permanent. Depending on the context and type of service, infrastructure may include human resources.

service system consumable

A service system component that ceases to be available or becomes permanently changed by its use during the delivery of a service.
Fuel, office supplies, and disposable containers are examples of commonly used consumables. Particular types of services may have their own specialized consumables (e.g., a health care service may require medications or blood supplies).
People are not consumables, but their labor time is a consumable.
 
Последнее редактирование:
Реклама
А вот и рояль в кустах.
Яркий пример обсуждаемой темы!

===================================================================

Boeing займется техобслуживанием бомбардировщиков B-52
15 января 2010
AVIA.RU/
15 января, AVIA.RU – ВВС США заключили с концерном Boeing контракт на полную поддержку действующего флота сверхдальних стратегических бомбардировщиков-ракетоносцев B-52H Stratofortress, сообщает Lenta.ru со ссылкой на Defense Industry Daily.

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

Стоимость контракта составляет $750 миллионов. Сейчас ВВС США располагают 94 бомбардировщиками B-52.
 
Назад