powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Поделитесь опытом неудачных внедрений учетных систем
25 сообщений из 200, страница 4 из 8
Поделитесь опытом неудачных внедрений учетных систем
    #33372322
A_S_U
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GaryaЕсть подразделение "конструкторский отдел", есть подразделение "технологический отдел", есть подразделение "ОМТС" и есть ПДО - и того четыре взаимодействующих подразделения, которые в принципе интересует состав изделия. Поступает заявка - разработать и произвести некоторый блок-модуль, который обеспечит... и далее длинный перечень ТУ. Садятся конструктора, рисуют чертежи, получают конструкторский состав изделия. Далее то, что они нарисовали, они передают технологам. Технологи смотрят на детали и говорят "вот это получается фрезерованием, вот это - литьем, здесь нужны такие-то и такие-то технологические операции, а вот это мы сделать не сможем, нужно покупать на стороне". И расписывают техпроцесс. Далее по техпроцессу составляется определяются потребности в материалах, составляется план закупок и план производства, которые передаются в ПДО и в ОМТС. Если схема взаимодействия подразделений налажена более оптимально, значит конструктора, а затем технологи на каждом своем этапе получают консультации в ОМТС по вопросам целесообразности и возможности применения различных вариантов решений. Но даже и после запуска в производство могут возникнуть (и возникают, причем весьма часто!) корректировки, уточнение и дполонение изначальных ТУ, что приводит к изменению конструкторской и технологической документации, пересмотру производственных планов и планов закупки материалов Все правильно, только вместо постоянных согласований с ОМТС, целесообразнее, на мой взгляд, вести экономическую проработку проекта, от заявки до готового изделия. Помимо того, что исчезают постоянные согласования, и появляются экономически обоснованные решения, на выходе будем иметь детальную калькуляцию затрат по всем стадиям работ. В принципе, то, что Вы описали, есть ничто иное, как проектное производство. Оно имеет свои особенности (по сравнению с материальным производством), но это, как правило, не критично.

Garya"Значит технологи должны..." - звучит как-то "антидемократично" и "антирыночно", не находите? Нет, не нахожу. Они должны в силу а) своей профессии; б) занимаемой должности; в) получаемой заработной(!) платы.

GaryaСамое интересное, что должны ВСЕ. И конструктора должны, и технологи должны, и производственники тоже. Но если каждый из них станет вводить в некоторую программу весь состав изделия с нуля своими руками (а некоторые конструкции, которые мы производим, насчитывают до 10000 деталей), дополняя и уточняя ту информацию, которая имеет отношение именно к специфике деятельности этого подразделения, то у клиента просто лопнет терпение, и он уйдет к конкуренту, у которого конструкторская информация может плавно и автоматически сама попасть к технологам а от технологов - к производственникам Совершенно верно. Я где-то говорил о том, что надо много раз заводить одно и тоже? Нет, я говорил только о том, что ЧАСТЬ информации является РАЗДЕЛЯЕМОЙ . Неужели это так трудно для понимания?

GaryaКонструкторам удобно работать с групповыми спецификациями. Технологам и производственникам - не удобно. Вы выступаете за предоставление свободы подразделениям в выборе способов обмена информацией Garya Это уже неспортивно...

GaryaА я полагаю, что кто-то сверху громогласно должен гаркнуть на конструкторов - плевать, что вам удобнее. Вы обязаны предоставлять спецификации в таком виде, чтобы они легко разворачивались в иерархические структуры Гаркнуть – это демократично? Может быть надо было просто объяснить конструкторам, что является результатом их деятельности? (Можете написать целью процесса или целевой функцией или... как Вам заблагорассудится).

GaryaПо-моему, информация о составе изделия возникает задолго до того, как у производства возникнут потребности, как-либо ним связанные. Если производство ЕЩЕ РАЗ формирует состав изделия после того, как он был сформирован конструкторами и технолгами, значит "что-то не так в датском королевстве" Производство говорит, что ему необходимо для ПРОИЗВОДСТВА изделия, оно не формирует состав изделия...

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

Garya[quot A_S_U]Проводки - это учет поступившего платежа. Заведение платежа и учет - это не одно и то же.Я вообще перестаю понимать, о чем вы говорите. Что такое "заведение платежа"? Насколько мне известно, инициатором платежа выступает сторонняя организация, она же оплачивает деньги. Информация о поступлении денег формируется банком (тоже сторонней организацией). О каких распорядительных функциях вы говорите? Платеж – это некоторый [промежуточный] результат деятельности. Финансисты спланировали бюджет, просчитали доходы и расходы, распределили лимиты, согласовали планы сбыта и снабжения... Они связали счет, выставленный клиенту, с доходными статьями. И вот деньги поступили на счет. Теперь можно оплатить какие-то другие счета, можно применить какую-то процедуру обслуживания платежных средств (которые обладают разной ликвидностью, например, оплата прошла векселем по номиналу, а какова рыночная цена этого векселя?). По поступлению платежа мог сформироваться избыток оборотных средств, а, следовательно, надо запустить программу размещения и т.д. и т.п. Это далеко не все распорядительные функции...

Garya A_S_U[quot Garya]И почему вы решили, что ввод информации о поступивших платежах - это распорядительная функция, а не учетная? Потому, что финансист распорядился получить/потратить деньги, спланировал эти поступления/расходы, теперь он должен получить фактическое подтверждение завершения транзакции.Ну и пусть получает подтверждение в виде констатации факта, то есть, в виде учетной информации. Распорядительные функции связаны с принятием решений, которые могут изменить состояние хозяйствующего субъекта. Когда деньги пришли, этот факт уже изменил состояние хозяйствующего субъекта, осталось только отметить (зарегистрировать, учесть ) этот факт. Инвариантность действий на этом этапе исключена Откуда Вы это взяли? Вы понимаете, что движение денег (cash flow), – это исполнение бюджета? И [возможно] не только в доходной его части... (остальное см. выше)

Garya A_S_UМоя категоричность имеет нескольку иную природу... IMHO.Какую же? Вы отстаиваете знания, а я смысл...

Garya A_S_UА распорядительные функции у бухгалтеров лучше все-таки изъять, хотя бы следуя здравому смыслу.Я предпочитаю искать те управляющие воздействия, которые от меня как-то зависят Понимаю, искать удобнее там, где светло, а не там, где потерял...
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33372327
Garya весьма скрупулезен и точен. Но со сложностью "главной цели", мне кажется, преувеличивает. Отдела планирования просто не должно быть на предприятии, изготавливающем конкретные изделия по конкретным спецификациям и конкретным технологиям. Если, конечно, целью является ВЫПОЛНЕНИЕ ОБЯЗАТЕЛЬСТВ (вот такая простая "главная цель", а "прибыли" и "рентабельности" - это очевидные и производные цели), а не получение удовольствия, как при "бытовом планировании" (запланировал купить носки, но подвернулась интересная книга). Какой же тут отдел планирования ? Как же маркетинг скажет заказчику, что его заявка будет выполнена (гарантированно !) такого-то числа в момент поступления заявки (к этому же нужно стремиться), если уже в этот момент не будут учтены ресурсы с учетом переналадок и т.п., то есть не будет выполнено планирование ? Как же клиент не будет обманут, если планирование будет делаться потом, 25 раз через три структуры и 10 человек ?
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33372335
A_S_U, я думаю, ошибается. Вся информация, касающаяся деятельности предприятия, является разделяемой, в той или иной степени. Неразделяемая "информация" - это, возможно, сны и т.п. Если "информация" данного подразделения никому не нужна, то существование такого подразделения вызывает сомнения. Конечно, многое (все что угодно) можно хранить в личных записных книжках, но какое это имеет отношение к корпоративной информационной системе ?
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33372611
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garya Привилегированный пользователь
Участник
Сахават ЮсифовНа этот счет есть ГОСТы...Вот как раз ГОСТом и допускается составление групповых спецификаций, которые создают большие проблемы при попытке состыковать информацию этих четырех подразделений. ГОСТы хороши тогда, когда их актуальность своевремено отслеживается теми, кто их составляет.
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33372637
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А почему это групповая спецификация препятствие? Какие трудности понимания она превносит? Даже очень интересно
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33372747
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garya Привилегированный пользователь
Участник
A_S_UОткуда Вы это взяли? Вы понимаете, что движение денег (cash flow), – это исполнение бюджета? И [возможно] не только в доходной его части... (остальное см. выше)Да, я это понимаю. Составление бюджета, внесение в него изменений - это распорядительная функция. Она выполнена ДО поступления денег. Выполнение функций, связанных с ИСПОЛЬЗОВАНИЕМ поступивших денежных средств, это тоже распорядительная функция, которая выполняется ПОСЛЕ поступления денежных средств. Отражение факта поступления денежных средств, происходит МЕЖДУ этими моментами и никак не связан с распорядительными функциями. Просто распоряжаться в этот момент нечем. Нужно просто зафиксировать факт прихода денег. Фиксация фактов - это и есть учетная функция. Если эта операция может фиксироваться автоматически благодаря связки с системой клиент-банк (как, например, у нас и происходит), никаких шевелений руками и мозгами никаким финансистам в этот момент делать не требуется. Им требуется лишь ОТРЕАГИРОВАТЬ на этот факт. Но реакция на факт происходит уже ПОСЛЕ отражения этого факта.
То же касается регистрации списание денежных средств с банковского счета. Акцептование счета, выставленного поставщиком, - это распорядительная функция. Подписание главбухом платежки (например, электронной подписью в системе "клиент-банк") - это тоже распорядительная функция (подпишет - пойдет платеж, не подпишет - не пойдет). Но выполнение этих действий происходит ДО фактического выполнения платежа. Когда из банка приходит информация, что платежки приняты к исполнению, отражение этого факта - учетная функция. Отражение того факта, что платежки не только приняты, но уже и исполнены - тоже учетная.
Если вы с этим не согласны, прошу аргументировать.

A_S_UВы отстаиваете знания, а я смысл...Я отстаиваю и то, и другое в тесной взаимосвязи. Не думаю, что постижение смысла возможно без достаточного уровня знаний. Также как и знания нельзя считать полученными, если не постигнут смысл.
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33372802
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Групповая спецификация удобна для конструкторов, да и для всех, кроме разработчика. Но, никто не мешает хранить данные в удобном для разработчика виде (спецификации).
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33372856
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сахават Юсифов Но, никто не мешает хранить данные в удобном для разработчика виде (спецификации).
Согласен. Я бы только сказал так - в удобном для ИС виде. А плодить их по каждому варианту исполнения - конечно производственники взвоют... Сам бы взвыл, если бы приходилось ради различий в 5 деталях поддерживать десяток спецификаций
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33372894
A_S_U
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GaryaНужно просто зафиксировать факт прихода денег. Фиксация фактов - это и есть учетная функция. Если эта операция может фиксироваться автоматически благодаря связки с системой клиент-банк (как, например, у нас и происходит), никаких шевелений руками и мозгами никаким финансистам в этот момент делать не требуется. Им требуется лишь ОТРЕАГИРОВАТЬ на этот факт. Но реакция на факт происходит уже ПОСЛЕ отражения этого факта Мне кажется, что Вы сильно упрощаете ситуацию. Повторю еще раз. Во-первых, платеж не всегда проходит через банк и в рублях. Во-вторых, поступление платежа еще не означает оприходования денежных средств. Деньги могут поступить на счет в результате чьей-то ошибки или, например, в грязных целях каких-то людей. В-третьих, ответственность «размазанная» по разным людям и службам – это безответственность (если ответственность лежит на всех, значит она не лежит не на ком).
Кто здесь говорил о «процессном подходе»? Теперь Вы сами же вырезаете отдельную функцию, отбрасывая то, что «до», и то, что «после». Где же логика?
A_S_UВы отстаиваете знания, а я смысл...Я отстаиваю и то, и другое в тесной взаимосвязи. Не думаю, что постижение смысла возможно без достаточного уровня знаний. Также как и знания нельзя считать полученными, если не постигнут смысл[/quot] Очень мудрый человек (Лао-Цзы) сказал: «Мудрый многого не знает, знающий много – не мудр»... К сожалению, данную мудрость не всегда легко понять и принять...
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373031
A_S_U
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Приношу извинения за ошибки в цитировании.
Цитата из последнего сообщения:
Garya A_S_UВы отстаиваете знания, а я смысл...Я отстаиваю и то, и другое в тесной взаимосвязи. Не думаю, что постижение смысла возможно без достаточного уровня знаний. Также как и знания нельзя считать полученными, если не постигнут смысл Очень мудрый человек (Лао-Цзы) сказал: «Мудрый многого не знает, знающий много – не мудр»... К сожалению, данную мудрость не всегда легко понять и принять...
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373057
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmСогласен. Я бы только сказал так - в удобном для ИС виде. А плодить их по каждому варианту исполнения - конечно производственники взвоют... Сам бы взвыл, если бы приходилось ради различий в 5 деталях поддерживать десяток спецификаций

Когда я с этим столкнулся в 1 раз (87г.), то заставил!!! :) переделать (ввести в прогу) все групповые спецификации на ПО "Химтекстильмаш" при унификации почти 90%!!! (модификации отличалась количеством модулей и связующих элементов и кое-какой мелочью!!!) Как меня терпели ? - до сих пор не пойму.
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373094
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garya Привилегированный пользователь
Участник
iscrafmА почему это групповая спецификация препятствие? Какие трудности понимания она превносит? Даже очень интересноГрупповые спцификации нарушают древовидную структуру представления ифнормации. Эта проблема не является совсем уж непреодолимой, поскольку позволяет преобразовать граф определенного вида в дерево. Но она исключает обратное преобразование. Отсюда следует, что передавать информацию можно только из CAD в CAM и в ERP. Обратная передача информации невозможна. И, значит, невозможна организация обратных связей, работающих в циклах непрерыного изменения конструкторской и технологической документации по информации, поступающей, например, от отдела ОМТС, финансистов, специалистов, контактирующих с клиентами и использующих CRM-систему (где фиксируются изменения ТУ, например)... А это очень важный аспект "проектного производства", как его называет A_S_U, или "проектирования под заказ", как его называл я.
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373120
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garya Привилегированный пользователь
Участник
2 A_S_U. По поводу учетных/распорядительный функция я остался при своем мнении. Мне есть, что возразить, но я не буду это делать, дабы не превращать тред в пустую перепалку и оффтоп.
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373159
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Garya,
Вы посмотрели B2ML?
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373185
A_S_U
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Garya2 A_S_U. По поводу учетных/распорядительный функция я остался при своем мнении. Мне есть, что возразить, но я не буду это делать, дабы не превращать тред в пустую перепалку и оффтоп. Иметь свое мнение - это Ваше законное право. Надо только иметь ввиду, что учетные и распорядительные функции появляются на перечении модели управления и модели предприятия. Тогда свою позицию можно смело отстаивать.
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373213
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Garya iscrafmА почему это групповая спецификация препятствие? Какие трудности понимания она превносит? Даже очень интересноГрупповые спцификации нарушают древовидную структуру представления ифнормации. Эта проблема не является совсем уж непреодолимой, поскольку позволяет преобразовать граф определенного вида в дерево. Но она исключает обратное преобразование. Отсюда следует, что передавать информацию можно только из CAD в CAM и в ERP. Обратная передача информации невозможна. И, значит, невозможна организация обратных связей, работающих в циклах непрерыного изменения конструкторской и технологической документации по информации, поступающей, например, от отдела ОМТС, финансистов, специалистов, контактирующих с клиентами и использующих CRM-систему (где фиксируются изменения ТУ, например)... А это очень важный аспект "проектного производства", как его называет A_S_U, или "проектирования под заказ", как его называл я.
Групповую спецификацию можно преобразовать во множество единичных.
Т.е. это сугубо способ реализации работы с групповыми спецификациями
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373219
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
p.s. есть такое понятие - наследование.
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373267
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garya Привилегированный пользователь
Участник
Сахават ЮсифовGarya,
Вы посмотрели B2ML?Где?
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373270
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garya Привилегированный пользователь
Участник
iscrafmГрупповую спецификацию можно преобразовать во множество единичных.
Т.е. это сугубо способ реализации работы с групповыми спецификациямиСогласен. Только делать это нужно у конструкторов.
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373286
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garya Привилегированный пользователь
Участник
P.S. Не так давно очень подробно общался по этому поводу с представителем Аскона. Они рекомендуют, причем, очень настойчиво, уходить от использования конструкторами групповых спецификаций. Хотя ГОСТом и разрешено их использование.
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373287
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Garya iscrafmГрупповую спецификацию можно преобразовать во множество единичных.
Т.е. это сугубо способ реализации работы с групповыми спецификациямиСогласен. Только делать это нужно у конструкторов.
Ну да, конечно. В производстве обращаются уже конкрентные варианты
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373353
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373361
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GaryaP.S. Не так давно очень подробно общался по этому поводу с представителем Аскона. Они рекомендуют, причем, очень настойчиво, уходить от использования конструкторами групповых спецификаций. Хотя ГОСТом и разрешено их использование.
Еще бы, без них проще софт разрабатывать. :)
А каково конструкторам при большом проценте унификации и множестве вариантов исполнения?
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373383
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafm Garya iscrafmГрупповую спецификацию можно преобразовать во множество единичных.
Т.е. это сугубо способ реализации работы с групповыми спецификациямиСогласен. Только делать это нужно у конструкторов.
Ну да, конечно. В производстве обращаются уже конкрентные варианты

На основании групповых технологий разрабатываются (иногда автоматом) групповые технологии, а на их основе возможно планирование производства в приведенных изделиях, но с специфированным выходом.
А та компания лапшу вешает, начинали, небось, как я, а теперь лен переделать (может еще какие проблемы).
Одним словом, групповуха - хорошо!
...
Рейтинг: 0 / 0
Поделитесь опытом неудачных внедрений учетных систем
    #33373851
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garya Привилегированный пользователь
Участник
2 Сахават Юсифов. Спасибо за ссылочку на B2MML. Ранее не слышал. Насколько я понял, это что-то вроде CommerceML, только для целей стандартизации "языка общения" собственных подразделений. Стандарт требует углубленного изучения. Мне известно, что принятые за рубежом стандарты CommerceML в российских условиях оказались не очень удобными (точнее, очень не удобными), в результате 1С, Microsoft и кто-то там еще (уже не помню) сели за разработку специального стандарта для российских условий. У меня есть подозрение, что B2MML ожидает примерно такая же судьба. Предметно сказать не могу - нужно время на детальное изучение стандарта.
...
Рейтинг: 0 / 0
25 сообщений из 200, страница 4 из 8
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Поделитесь опытом неудачных внедрений учетных систем
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]