Тема для оффтопа.

[Самоделкин96]

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

мериться с косяками можно когда цена машины ощутимо ниже!

Абсолютно верно, и даже сегодня они чуть дороже чем нужно

[Диполь]

Очевидно был отлаженный процесс установки ПО для сервиса именно на DB2 и был отлаженный процесс миграции на Oracle. На каждый процесс, скорее всего были выделенные команды, которые хорошо знали возможные проблемы, умели оперативно исправить. А, вот, процесс установки новой системы на Oracle, вполне возможно, отлажен не был.

Даже, больше того, выглядит так, что а в чём проблема - ну отладьте процесс установки сразу на Oracle и всё? В таком случае пришлось бы держать отдельную команду именно установки на Oracle, либо дообучать персонал, что, по итогу, могло привести и к итоговым повышенным затратам на поддержку.

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

В целом верно. Два отлаженных процесса. Две команды. Но установка на Оракле на пустое желе3о и установка после сноса DB2 как ока3алось, ничем не отличаются. Не просто так я вспомнил анекдот про чайник. Т.е. одни люди ставили DB2 и сносили его (там нужно было сохранять данные), а другие ставили Оракл, а потом 3агружали данные. Последняя операция не требовалась при новой установке. Таким образом. установка с нуля - это упрощенный вариант обновления. Т.е. для этого есть готовая команда.

Обоснование было чере3 слова о справедливости, и согласованном графике обновления.
Реально - это просто пример постепенной потери эффективности.
Появляется новый софт и его экспериментально устанавливают на одной станции. Тестируют. Все ОК.
Принимают решение 3аменить ее на нескольких станциях и убедиться, что все норм. Меняют.
В такой логике это был правильный процесс обновления.
Но дальше принимается решение о полном переходе и тут логичнее и3менить процесс и при ра3работке плана установки Оракла 3апуск новых станций сра3у планировать на новом софте. Но и3менения не происходит.

[Царь]

Не просто так я вспомнил анекдот про чайник.

Тут не все так просто!
В it, а в частности в програмировании, для изменения кода (программы) необходимо понять логику которая была заложена изначально.
В ряде случаев реально проще, быстрее и надежнее написать заново, чем понимать логику. (чайник на исходную позицию и ты точно уверен, что все правильно)
Да и сложности с сертификатами тоже могут возникнуть.
Вариант Игоря надежнее, тк он уже отработан и есть инструкции и прочее.

[Диполь]

А теперь другой пример. Как бы обратный - победа инновационных подходов, гибкость и и3менения.

Спойлер

Ра3говор о сертификации прои3водства автомобилей ГА3 по стандарту ИСО-9000. Это начало 2000-х.
Сертификацию делали у немцев в компании ТЮФ. Рассматривался также Веритас, но отвалился.
Наши гордились как неплохим прои3водством (все отлажено), так и внедрением элементов уже входившего в моду ЛИН-прои3водства. Миними3ация потерь на всех этапах.

Были поставлены 3адачи работать над экономией на всех участках с тем, чтобы процент выбраковки комплектуюших на этапе сборки снижался. В ре3ультате обра3овывались "лишние" детали, которые можно было пустить в прои3водство и собрать дополнительные автомобили. Что и делали. К моменту прохождения сертификации 3авод рапортовал о 100 дополнительных автомобилях в год, выпушенных целиком и3 сэкономленных материалов.

И вдруг такой ЛИН-подход вошел в противоречие с немецкой логикой СМК.
Немцы бегали по 3аводу и кричали - "Как такое может быть???? Не бывает сэкономленных материалов! У вас либо нормы расхода 3авышены (т.е. махинации), либо в каждую машину какую-то деталь не ставите - картер нужно крепить на 12 болтах, а вы ставите 11 - и так держит (т.е. снижение качества и обман потребителя). Других вариантов нет"
А наши обижались и отвечали, что это бюрократия, а у нас все гибко и эффективно

А вы что думаете?

Добавлено спустя 3 минуты 31 секунду:

Вариант Игоря надежнее, тк он уже отработан и есть инструкции и прочее.

Поэтому в моем мире новые станции сра3у получат новый софт, а старые будут обновляться по плану. При этом часть старых обновится сра3у не просто до нового софта, а до его второй версии.
А в обычном мире мы сначала всем поставим старый софт. Потом всем аменим на новый, а потом всем ее ра аменим на совсем новый.
Именно потому, о чем ты ска3ал - проше, привычнее, не надо думать.

[Царь]

А вы что думаете?

Те из выбракованных деталей собрать автомобиль?

[Диполь]

Те из выбракованных деталей собрать автомобиль?

Это я неправильно пояснил.
Речь идет о том, что все детали вроде хорошие, но в процессе сборки что-то портили. И была норма на порчу (на выбраковку). А тут просто стали меньше портить (ЛИН). Вот и обра3уются 100 лишних автомобилей

[Царь]

Это я неправильно пояснил.
Речь идет о том, что все детали вроде хорошие, но в процессе сборки что-то портили. И была норма на порчу (на выбраковку). А тут просто стали меньше портить (ЛИН). Вот и обра3уются 100 лишних автомобилей

Тогда палка о двух концах, меньше портить значит тщательнее работать это замедляет процесс в итоге машин в час произведут меньше.

Добавлено спустя 5 минут 57 секунд:

Поэтому в моем мире новые станции сра3у получат новый софт, а старые будут обновляться по плану. При этом часть старых обновится сра3у не просто до нового софта, а до его второй версии.

Такой метод эффективнее, но нужен будет доп специалист который будет новым ставить новый софт!
Тк уволить того который ставит старый софт нельзя пока не завершится процесс перехода (может на станции поломаться один комп, а станция еще не перешла )
ну или обучить его как с новым софтом работать

[Самоделкин96]

Диполь, а что за софт собсна? Срм, сцм, ерп или что? Они синхронизированы с центром? Между собой? Получается в центре сразу двумя системами должны пользоваться?

[Диполь]

Софт - WMS + mrp. Синхронизация с центром. Как делалась не знаю, но на периферии две системы

[Самоделкин96]

Диполь, так получается, что в центре в любом случае двумя софтами пользоваться должны, а если придется координировать между собой дилеров с разным софтом, то скорее всего это будет происходить в ручном режиме. Если я конечно все верно представляю)
Как организовано снабжение этих отделений? Есть какой-то промежуточный локальный распределительный пункт? Было бы удобно поделить все на "территории" по этим распределительным пунктам и связанными с ними диллерами, и обновлять софт по каждой территории отдельно. Если конечно такой пункт есть, а то вдруг все из печки сразу к дилеру летит

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

[SheWolf]

Посмотрели "100 вещей и ничего лишнего".
Классный фильмец!

[Самоделкин96]

SheWolf, спасибо, сажусь смотреть
Сбил режим, делать нечего..

[Диполь]

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

Я бы все же хотел сохранить исходную линию своей темы - обсуждение логики принятия не самых эффективных управленческих решений. Эта тема лежит в русле предыдущего вопроса о причинах деградации даже лидирующих предприятий.

Ты же свернул в сторону чисто технических вопросов.
Тем не менее отвечаю.

Спойлер

1. Координация дилеров с разным софтом происходит в автоматизированном режиме. В центре уже была установлена СУБД Оракл, которая позволяет работать с разными клиентами на периферии. Оракл-клиент конектится к центру так же как и DB2 клиент.
2. Промежуточные склады (распред. центры) есть. Но система не равновесная. Для каких-то сервис-центров (в т.ч. дилеров) заказ идет через РЦ, а для европейских - напрямую с центрального склада.
3. Структура снабжения никак не влияет на выбор последовательности обновления, т.к. кол-во клиентов и цепочки движения информации и товаров при замене софта остаются теми же.

[Самоделкин96]

Диполь, хорошо, как вы предлагаете построить обсуждение этой темы? На примере МБ и их опыта перехода на новый софт? Или через сам процесс принятия решений без привязки к конкретным примерам?

[Диполь]

как вы предлагаете построить обсуждение этой темы?

Я бы предложил описывать возможные модели принятия решений и их обоснования с позиции МБ

[Самоделкин96]

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

Добавлено спустя 2 минуты 12 секунд:
Диполь, протестую))
Мало информации, невозможно что либо описать с позиции МБ не зная ничего о позиции МБ... Нужен понятный и известный объект управления, иначе управлять будем так же хорошо, как и знать этот объект)

Добавлено спустя 1 минуту 25 секунд:
И эт самое.. У меня в репутации опять гордая единица, второй день пытаюсь понять чтож я такого полезного написал... Никто не в курсе? А то я сам не нашел

[Диполь]

протестую))

Кошмар..)))

Мало информации, невозможно что либо описать с позиции МБ не зная ничего о позиции МБ... Нужен понятный и известный объект управления, иначе управлять будем так же хорошо, как и знать этот объект)

ОК. Давай подробнее.

Представь себе, что ты получаешь автомобиль неизвестной марки. У автомобиля обнаруживаются проблемы - через 15-20 минут работы он глохнет. Однако, спустя 10 минут "отдыха" снова заводится и опять на 15-20 минут. Далее все повторяется.
Ты не знаешь устройство этого конкретного автомобиля, но являешься крутым специалистом в области автомобилестроения.
Тебе предлагается предположить возможные причины такого поведения автомобиля в порядке снижения вероятности.
Сможешь? Если специалист, то да. Ты не назовешь точную причину, но опишешь наиболее вероятные и логику их возникновения и срабатывания

В нашем случае ты получаешь компанию МБ неизвестной конструкции, у которой обнаруживаются проблемы - принятие определенного неэффективного решения. Ты не знаешь структуру управления компании МБ, но являешься крутым специалистом в сфере менеджмента (ты себя тут позиционировал именно как специалиста в этом вопросе, или по крайней мере, как человек, который хочет стать таким специалистом и уже многое знает). Соответственно, тебе предлагается предположить возможные причины и объяснить их логику.
Если ты крутой специалист, то должен легко это сделать. Если пока нет, но хочешь им стать (и уже много знаешь), то это неплохая разминка для мозгов и польза для осмысления.

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

[SheWolf]

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

Не за что! Хорошо!

[Самоделкин96]

Диполь, не, в угадайки я не играю, забыли?)

Добавлено спустя 1 минуту 13 секунд:
Зачем вообще повторять одно и то же действие и ждать разного результата?)

[Царь]

не, в угадайки я не играю, забыли?)

Тут суть не в "угадайке", а в решении конкретных вопросов на примере реальных ситуаций!
И как показал пример с МБ есть два варианта решения причем, как со стороны эффективности и со стороны меньших затрат при большей надежности тк есть уже отлаженные процессы.
И пример с ГАЗ более сложный и интересны лично для меня!
Дело добровольное играть не играть!