1. У техники нет, если это не робототехника, свойства боеготовности. Давайте говорить терминологически выверенно. Боеготовность свойство системы человек-оружие (экипаж-самолет, пара, звено, эскадрилья и т.д.).
А никто и не утверждал, что боеготовность - свойство техники. Сие есть показатель, характеризующий ее текущее состояние. На данный конкретным момент времени. Уже писал ведь - совершенно исправная техники небоеготова, если она не заправлена и не снаряжена. Так что действительно - давайте говорить терминологически выверенно...
И вообще, давайте не возвращаться к теме боеготовности. Это всегда было и будет исключительной компетенцией военных. Только военные могут решать, когда и сколько заливать керосина в баки и какие АСП подвешивать на самолет для решения тех или иных задач. Наше, промышленников, дело - обеспечить исправность техники.
Однако есть одна причина ЗА. Промышленность никаки не отвечает за эксплуатационные свойства принятых заказчиком изделий, на которые истекла гарантия. При этом если волнует стоимость владения то задача по ее оптимизации лежит на заказчике, которую он пытается решить заранее во время принятия решения о закупки техники.
Если понимать Вас буквально, уже не ОДНА, а как минимум - ДВЕ
На самом деле из много больше...
3. А заказчик имеет опыт эксплуатации техники по принципам PBL?
Вопрос некорректен в своей сути. Ибо в нашей стране опыта использования PBL нет НИ У КОГО. Скажу больше - у тех, кто ее придумал и впервые применил на практике - тоже не было такого опыта
. И если уж быть терминологически точным, как Вы этого хотите, то PBL - это не приципы эксплуатации техники, а стратегия приобретения поддержки эксплуатации этой техники со стороны промышленности. Стратегия, ориентированная на конечный результат.
4. Обе системы имеют плюсы и минусы, примененние какой либо в конкретном случае надо выбирать. Полагаю обе будут еще долго существовать.
Совершенно верно. Обе стратегии будут иметь место. Причем даже в рамках одного контракта. Вот Вам пример:
http://aviaforum.ru/attachment.php?attachmentid=365076&d=1360510548
Стратегия PBL применима только к регулярным сервисам, прямо влияющим на показатели конечного результата: эксплуатационную готовность (исправность) техники, ее надежность в эксплуатации, эксплуатационные затраты, простои. Все разовые (нерегулярные сервисы), а также то, что прямо не влияет на упомянутые показатели разумнее приобретать традиционным способом. Ибо здесь у PBL нет никаких "плюсов". Как и в применении традиционного подхода к большинству регулярных сервисов. Там, у традиционного подхода - одни только "минусы". Если можете читать по английски, вот Вам аргументы (уже приводил здесь):
***
Transaction-Based versus Performance-Based Contracts
2.29.
To better appreciate the benefits of PBCs, it is useful to look at an alternative approach, which is termed transaction-based contracting. In a transaction-based c ontract, the contract refers to a list of individual work activities that the contractor is required to perform, and payment is calculated from the sum of individual activities. This alternative approach involves the acquirer controlling the flow of work (eg, the flow of RIs into a maintenance venue), with the contractor expected to provide a consistent response (eg, turn-around time) regardless of the current needs of the capability or options for more efficient work flow (eg, through better scheduling). This alternative approach can lead to higher management overheads, lower efficiency and higher overall costs; lower efficiency because the contractor is often excluded from work planning until late in the process, and higher overall costs because both the contractor and the acquirer require additional personnel to manage the number of transactions.
2.30.
In a transaction-based contract, profit is generally included within each transaction; hence, the more transactions, the greater the profit. This is often contrary to Defence’s objectives because more transactions (eg, maintenance actions resulting in system downtime) can mean poorer system availability and increased cost. Opposing desires for greater and fewer transactions can result in inefficient contracting solutions and counter-productive contractual relationships.
2.31.
Notwithstanding, transaction-based contracts can be appropriate where there are a relatively small number of expected transactions over a period of interest (eg, a year), particularly at the component level. With small quantities of low failure-rate items, for example, it can be much more cost-effective for the DMO to implement standing-offer arrangements where maintenance is initiated only when required. The performance outcomes for these types of transaction-based contracts are often internal to the contract and not related to the true customer’s needs (eg, turn-around time or delivery lead-time).
2.32.
Under a PBC, all services can be priced under groups of activities (eg, all maintenance services), whereas under a transaction-based contract a separate price is required for each transaction (eg, maintenance of RI #1, maintenance of RI #2, and so on). A transaction-based contract for whole-of-system support, therefore, would require considerable resources to initiate and monitor each of the transactions. PBCs provide a better option for large-scale support contracts because individual activities are not the focus of attention. Notwithstanding, one of the downsides with PBCs is that there is a much less tangible link between the payments being made and the actual activities being performed, which can make the cost of non-performance much more difficult to assess. Typically, therefore, the financial implications of non-performance under a PBC are addressed through a performance-management frame work that is defined upfront by the acquirer in its solicitation pack age (and modified, as required, through the processes leading to contract signature). This framework, which links performance to payment, is addressed later in the paper under Achieving Enhanced Performance: Rewards, Remedies and Performance Measurement.
2.33.
Under certain types of PBCs (eg, whole-of-system support contracts), elements of these contracts may need to be transaction-based because it is cost-effective for these elements to be managed in this way. Under ASDEFCON (Support), these categories of services are known as either Task-Priced Services or S&Q Services. These categories of services typically sit outside the main performance framework for a contract; however, some of the individual services with in these categories can be brought under the main performance framework through other mechanisms (eg, using Pre-Authorised Ad Hoc Services).
***
Первоисточник:
http://aviaforum.ru/attachment.php?attachmentid=370140&d=1363106644
