Единичное производство и Pdm

[Елена 116]

Вот и получается, банальная ситуация с погоней малой группы программистов предприятия за 3..4 бОльшими группами программистов из фирм.

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

[Странник 6]

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

Есть несколько НО..

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

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

3. правящие предприятиями экономисты понимают в производстве ещё меньше программистов.

Таким образом ситуация складывается просто аховая.

"Склеить" отраслевые PDM в единую систему с силами одного машиностроительного предприятия, пусть даже очень могучего, фактически невозможно... разве что скупить акции этих самых разработчиков и создать ДОАО - аналог, например, DS.

[француз 0]

Есть несколько НО..

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

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

3. правящие предприятиями экономисты понимают в производстве ещё меньше программистов.

+1

Здесь бы хотел ещё добавить, что задачи и требования к PDM/ERP у подавляющего большинства предприятий практически одинаковы. А стремление у програмеров и экономистов доказать специфичность каждого предприятия - идёт от их некомпетентности + желания заработать побольше

разве что скупить акции этих самых разработчиков и создать ДОАО - аналог, например, DS.

Имхо, есть ещё один путь. Называется это явление "open source". И современные примеры в других областях ПО показывают, что это не полная утопия. По крайней мере зародыш такой ERP уже существует.

[Елена 116]

разве что скупить акции этих самых разработчиков и создать ДОАО - аналог, например, DS.

Каждый выбирает для себя. Я же сказала.

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

Программисты бывают разные, и если заканчивали технический ВУЗ - то разберуться в организации производства не хуже Вас (кибернетика как известно - наука об управлении). А делать нужно по уму через разработку ТЗ. А не так, что мы вам на словах что-то там объяснили, а потом постмотрим - что-нибудь добавим. Обычный подход, как к созданию любого изделия:

1. Технические требования (заказчик - в данном случае объединенный - ОГК, ОГТ, ОТД и тд)

2. Техническое задание (руководитель разработчиков ПО - согласовывая с заказчиком).

3. Разработка и отладка ПО.

4. Тестирование.

5. Технические замечания по результатам тестирования (заказчик ПО).

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

7. Опытно-промышленная эксплуатация.

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

Смею Вас заверить, что проработав 20 лет в ОГТ и разрабатывая и внедряя ПО в ОГТ и цехах (ТТ и ТЗ приходилось разрабатывать самой), понимаю в организации этого процесса не хуже многих производственников и вижу, что до оптимальной работы в плане организации очень и очень далеко (то ли специально, то ли так получается).

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

Из моего опыта - даже когда эффект был настолько очевиден при внедрении ПО (сокращал время в десятки раз) все-равно технологи в отчетах пытались увеличить время разработки для получения премий и т.д (сверхурочные, работа в выходные оплачивается по двойному тарифу).

[Странник 6]

Имхо, есть ещё один путь. Называется это явление "open source". И современные примеры в других областях ПО показывают, что это не полная утопия. По крайней мере зародыш такой ERP уже существует.

А подробнее можно?

Лучше всего в виде ссылки.

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

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

3. правящие предприятиями экономисты понимают в производстве ещё меньше программистов.

Но воровать - умеют.

Старые люди по этому поводу так говорят:

Начальнику нужно что бы вор воровал, да с ним делился. А если вора поймают - то начальник ни при чём.

В общем на самом-то деле противников в нашем производстве больше чем сторонников. А руководству нужен эффект в денежном выражении, а не только удобства работы ОГК, ОГТ.

И не только на вашем предприятии такая беда.

Правда надо непременно сделать ссылку ещё на банальное нежелание учиться среди тех кому более 50 и, к сожалению, часто имеющую в последнее время неспособность среди бОльшей части персонала.

Из моего опыта - даже когда эффект был настолько очевиден при внедрении ПО (сокращал время в десятки раз) все-равно технологи в отчетах пытались увеличить время разработки для получения премий и т.д (сверхурочные, работа в выходные оплачивается по двойному тарифу).

А вот это как раз то, за что и величают технологов саботажниками.

[Елена 116]

А вот это как раз то, за что и величают технологов саботажниками.

Конструкторы не лучше (в общем все хороши) - каждый как умеет на себя одеяло тянет.

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

[Странник 6]

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

Не знаю где как, а у нас это звено называется производственно-диспетчерский отдел (ПДО).

При внедрении системы - их необходимость просто отпадает, руководство без них сможет всю интересующую информацию (зачастую более объективную) получить с экрана монитора.

А вот тут согласиться не могу.

Функция ПДО - оперативное управление производством, разумеется в заданных рамках.

Например:

1. Форсировать или замедлить прохождение той или иной производственной ведомости ради оптимизации загрузки производства.

2. Выполнение внеплановых оперативных работ (расцеховать в имеющиеся "окна" и т.п.).

3. Догляд за снабженцами и комплектаторщиками.

4. Присмотр за цехами.

В общем это своего рода штаб директора завода, подразделение совершенно необходимое.

Не возможет директор разбираться в каждой мелочи, да и смешно бы это выглядело со стороны.

Эта категория самая агрессивная, бегает, кричит, топочет ногами, устанавливает сроки, в общем демонстрирует бурную деятельность.

Так оно и есть, только один нюанс - как правило эти люди пытаются захватить власти больше, чем им объективно необходимо и достаточно, отсюда и все проблемы. Это старая история.

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

На этом уровне потребно делать прогноз развития науки и техники на десятки лет вперёд, соответственно и в штаб этого командира входят службы более высокого уровня интеллектуальной работы: конструктора, рассчётчики, системные математики, службы безопасности и т.п.

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

ПДО этого не понять, а ещё важно не забывать древней мудрости, гласящей что:

нет иного пути к стяжанию многому, иначе как обокрав наемников своих

.

Подводя некоторые предварительные итоги беседы должен выделить 3 ключевые мысли:

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

задачи и требования к PDM/ERP у подавляющего большинства предприятий практически одинаковы. А стремление у програмеров и экономистов доказать специфичность каждого предприятия - идёт от их некомпетентности + желания заработать побольше

Чем больше занимаемая человеком должность, тем выше требования к самому человеку.

Ты же знаешь, Абдула, я мзды не беру, мне за Державу обидно!

[Елена 116]

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

[француз 0]

А подробнее можно?

Лучше всего в виде ссылки.

Пример open source ERP системы:

<noindex>http://www.openbravo.com/product/</noindex>

[Странник 6]

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

Не только у вас.

А вообще говоря, вот вам и столь любимая В.В.Путиным вертикаль власти.

Чёткое разделение обязанностей и ответственностей по специальностям и уровням компетенции.

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

Кадры решают всё! Слышишь, Лаврентий?

<noindex>http://www.openbravo.com/product/</noindex>

ага, поглянем что за птичка.

[француз 0]

ага, поглянем что за птичка.

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

[Странник 6]

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

Не спешите, отпуск кончится - покажу коллегам, тогда уже доложу.

[француз 0]

Не спешите, отпуск кончится - покажу коллегам, тогда уже доложу.

Не дождавшись вашего отзыва, решил сам поиграться. А то как-то неудобно - дал ссылку на то, что сам не выдел.

Закачал это дело и необходимые примочки и начал ставить согласно инстукции. Больших проблем не возникло, всё вроде понятно и цивильно. Но ставилась эта "системка" около 3 часов Только 40 минут разворачивалась база на sql сервере. А потом ещё 2 часа что-то там компилилось на яве.

Я в этом деле не силён. Что и как оно должно делать - представляю слабовато. Так, полазил немножко по менюшкам. Ничего особо интересного не обнаружил Разве что обратил внимание на кнопочку "экспорт в cvs", то есть существует возможность отслеживать версии документов или чего-то там ещё.

Так что отчёт о фунциональности лучше услышать от спецов. Ждём сообщений от ваших коллег.

Ещё хотел бы выразить своё ламерское мнение по-поводу современных технологий. Куда не плюнь - все старуются прикрутить web-интерфейс где надо и где не надо. И пишут на всяких тормознутых жабах и питонах. В итоге приходится пару секунд ждать, пока менюшка вывалится.

Кто-нить может объяснить чем эта мода вызвана? Я знаю только одно внятное объяснение - не надо ставить клиентский софт. На мой взгляд это преимущество не настолько важное по сравнению с полученными проблемами и потерей производительности.