Абсолютно верно, и даже сегодня они чуть дороже чем нужноЦарь писал(а):мериться с косяками можно когда цена машины ощутимо ниже!
Абсолютно верно, и даже сегодня они чуть дороже чем нужноЦарь писал(а):мериться с косяками можно когда цена машины ощутимо ниже!
В целом верно. Два отлаженных процесса. Две команды. Но установка на Оракле на пустое желе3о и установка после сноса DB2 как ока3алось, ничем не отличаются. Не просто так я вспомнил анекдот про чайник. Т.е. одни люди ставили DB2 и сносили его (там нужно было сохранять данные), а другие ставили Оракл, а потом 3агружали данные. Последняя операция не требовалась при новой установке. Таким образом. установка с нуля - это упрощенный вариант обновления. Т.е. для этого есть готовая команда.GhostDog писал(а):Очевидно был отлаженный процесс установки ПО для сервиса именно на DB2 и был отлаженный процесс миграции на Oracle. На каждый процесс, скорее всего были выделенные команды, которые хорошо знали возможные проблемы, умели оперативно исправить. А, вот, процесс установки новой системы на Oracle, вполне возможно, отлажен не был.
Даже, больше того, выглядит так, что а в чём проблема - ну отладьте процесс установки сразу на Oracle и всё? В таком случае пришлось бы держать отдельную команду именно установки на Oracle, либо дообучать персонал, что, по итогу, могло привести и к итоговым повышенным затратам на поддержку.
Если в первую очередь, они хотели надежной работы сервисных центров, на мой взгляд, такой подход вполне оправдан.
Тут не все так просто!Диполь писал(а):Не просто так я вспомнил анекдот про чайник.
Поэтому в моем мире новые станции сра3у получат новый софт, а старые будут обновляться по плану. При этом часть старых обновится сра3у не просто до нового софта, а до его второй версии.Царь писал(а):Вариант Игоря надежнее, тк он уже отработан и есть инструкции и прочее.
Те из выбракованных деталей собрать автомобиль?Диполь писал(а):А вы что думаете?
Это я неправильно пояснил.Царь писал(а):Те из выбракованных деталей собрать автомобиль?
Тогда палка о двух концах, меньше портить значит тщательнее работать это замедляет процесс в итоге машин в час произведут меньше.Диполь писал(а):Это я неправильно пояснил.
Речь идет о том, что все детали вроде хорошие, но в процессе сборки что-то портили. И была норма на порчу (на выбраковку). А тут просто стали меньше портить (ЛИН). Вот и обра3уются 100 лишних автомобилей
Такой метод эффективнее, но нужен будет доп специалист который будет новым ставить новый софт!Диполь писал(а):Поэтому в моем мире новые станции сра3у получат новый софт, а старые будут обновляться по плану. При этом часть старых обновится сра3у не просто до нового софта, а до его второй версии.
Я бы все же хотел сохранить исходную линию своей темы - обсуждение логики принятия не самых эффективных управленческих решений. Эта тема лежит в русле предыдущего вопроса о причинах деградации даже лидирующих предприятий.Самоделкин96 писал(а):так получается, что в центре в любом случае двумя софтами пользоваться должны, а если придется координировать между собой дилеров с разным софтом, то скорее всего это будет происходить в ручном режиме. Если я конечно все верно представляю)
Я бы предложил описывать возможные модели принятия решений и их обоснования с позиции МБСамоделкин96 писал(а):как вы предлагаете построить обсуждение этой темы?
Кошмар..)))Самоделкин96 писал(а):протестую))
ОК. Давай подробнее.Самоделкин96 писал(а):Мало информации, невозможно что либо описать с позиции МБ не зная ничего о позиции МБ... Нужен понятный и известный объект управления, иначе управлять будем так же хорошо, как и знать этот объект)
Не за что! Хорошо!Самоделкин96 писал(а):SheWolf, спасибо за рекомендацию!
Полезный оказался для меня фильм, я давно и планомерно отказывался от лишних вещей, но не понимал почему. Оказалось я думал от конца к началу, впрочем как и всегда)
Тут суть не в "угадайке", а в решении конкретных вопросов на примере реальных ситуаций!Самоделкин96 писал(а):не, в угадайки я не играю, забыли?)
Сейчас этот раздел просматривают: 42 гостя