Имеется не маленькое, вполне среднее предприятие.
Два машиностроительных завода, около 2 000 производственных рабочих, производство позаказное.
Есть ERP 2.4, есть УНФ 1.6. Обе базы заполнены всей необходимой нормативкой
(структура предприятия, номенклатура, ресурсные спецификации и маршрутные карты, схемы обеспечения и др.), нормативка ежедневно обновляется, больше пока ничего в них не делаем.
Но планировать заказы и запускать их в производство можно прямо сейчас.
Смущает вот что, изделия сложные, до 10 уровней входимости, до 8 000 полуфабрикатов в изделии.
Очень уж неторопливо происходят все процессы в ERP, иногда половина рабочего дня уходит чтобы запланировать изделие.
Сервер новый, сервер мощный.
А если пойдёт реальный документооборот? 80 000 выпусков полуфабрикатов в месяц, их перемещения между цехами (до 5 переходов между цехами в процессе производства), списание на производство других полуфабрикатов, резервирования материалов и т.д.
К тому же сложна она, и для пользователей, и для постороннего вмешательства для реализации всяких хотелок.
И есть простая, лёгкая, быстрая и красивая УНФ-ка. Если уж и она не отработает как надо - есть план Б.
Делаем например каждый цех отдельной организацией, настраиваем РИБ по организациям, пишем свою обработку-планировщик, делаем обмен заказами и приходно-расходными накладными между организациями, как-то так.
Вот и не знаем по какому пути пойти. Как думаете?
Два машиностроительных завода, около 2 000 производственных рабочих, производство позаказное.
Есть ERP 2.4, есть УНФ 1.6. Обе базы заполнены всей необходимой нормативкой
(структура предприятия, номенклатура, ресурсные спецификации и маршрутные карты, схемы обеспечения и др.), нормативка ежедневно обновляется, больше пока ничего в них не делаем.
Но планировать заказы и запускать их в производство можно прямо сейчас.
Смущает вот что, изделия сложные, до 10 уровней входимости, до 8 000 полуфабрикатов в изделии.
Очень уж неторопливо происходят все процессы в ERP, иногда половина рабочего дня уходит чтобы запланировать изделие.
Сервер новый, сервер мощный.
А если пойдёт реальный документооборот? 80 000 выпусков полуфабрикатов в месяц, их перемещения между цехами (до 5 переходов между цехами в процессе производства), списание на производство других полуфабрикатов, резервирования материалов и т.д.
К тому же сложна она, и для пользователей, и для постороннего вмешательства для реализации всяких хотелок.
И есть простая, лёгкая, быстрая и красивая УНФ-ка. Если уж и она не отработает как надо - есть план Б.
Делаем например каждый цех отдельной организацией, настраиваем РИБ по организациям, пишем свою обработку-планировщик, делаем обмен заказами и приходно-расходными накладными между организациями, как-то так.
Вот и не знаем по какому пути пойти. Как думаете?
По теме из базы знаний
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
А что производите?
Это зависит от степени детализации изделия(от переделов). На одном предприятии сталкивался с похожей проблемой. Решили увеличением степени детализации передела в основной программе.
Если изделие состояло из 5 узлов, то не стали узлы дробить на комплектующие. Если узел состоит из 50 комплектующих то в учётной системе изделие состояло только из 5 узлов.
А комплектующие каждого узла вели в другой программе на уровне цеха. Там просто хотели считать всё до "винтика" и всё в "одной базе", но это не оправданно усложняло учёт. По этому сделали через крупные узлы. Но всё это зависит от требований к учёту и характера производства.
Смущает вот что, изделия сложные, до 10 уровней входимости, до 8 000 полуфабрикатов в изделии.
А что производите?
Смущает вот что, изделия сложные, до 10 уровней входимости, до 8 000 полуфабрикатов в изделии.
Это зависит от степени детализации изделия(от переделов). На одном предприятии сталкивался с похожей проблемой. Решили увеличением степени детализации передела в основной программе.
Если изделие состояло из 5 узлов, то не стали узлы дробить на комплектующие. Если узел состоит из 50 комплектующих то в учётной системе изделие состояло только из 5 узлов.
А комплектующие каждого узла вели в другой программе на уровне цеха. Там просто хотели считать всё до "винтика" и всё в "одной базе", но это не оправданно усложняло учёт. По этому сделали через крупные узлы. Но всё это зависит от требований к учёту и характера производства.
(2)
В учете и сейчас все укрупнено, узлов столько, сколько цехов участвует в выпуске готового изделия, в них все материалы собираются.
В производстве нужно вплоть до каждого узла и винтика, и спецификации изменять нельзя - госконтракты.
"А комплектующие каждого узла вели в другой программе на уровне цеха."
Вот и у нас такая же мысль возникала - УНФ на уровне цеха использовать.
В учете и сейчас все укрупнено, узлов столько, сколько цехов участвует в выпуске готового изделия, в них все материалы собираются.
В производстве нужно вплоть до каждого узла и винтика, и спецификации изменять нельзя - госконтракты.
"А комплектующие каждого узла вели в другой программе на уровне цеха."
Вот и у нас такая же мысль возникала - УНФ на уровне цеха использовать.
(5)Так что производите?
Это утопичный и не совсем правильный подход. Затраты на ведение такого учета многократно превысят профит.
Так спецификации ведите. Просто весь остальной объём данных(отражение операций) можно свернуть до приемлемого уровня.
У меня например предприятие выпускает электронное оборудование. Там не то что спецификацию менять нельзя. Там определённые детали нельзя менять на аналоги потому что иначе сертификаты на эти приборы станут не действительными, а без сертификата их никто не купит. Там наукоёмкое оборудование. Даже источник питания не можем заменить на аналог без прохождения повторной сертификации. Хотя казалось бы это просто батарейки.....
В производстве нужно вплоть до каждого узла и винтика
Это утопичный и не совсем правильный подход. Затраты на ведение такого учета многократно превысят профит.
и спецификации изменять нельзя - госконтракты.
Так спецификации ведите. Просто весь остальной объём данных(отражение операций) можно свернуть до приемлемого уровня.
У меня например предприятие выпускает электронное оборудование. Там не то что спецификацию менять нельзя. Там определённые детали нельзя менять на аналоги потому что иначе сертификаты на эти приборы станут не действительными, а без сертификата их никто не купит. Там наукоёмкое оборудование. Даже источник питания не можем заменить на аналог без прохождения повторной сертификации. Хотя казалось бы это просто батарейки.....
(8)
подвижных средств технического обслуживания, ремонта и эвакуации;
обитаемых модулей постоянного и переменного объема;
комплексов мобильной техники различного назначения;
энергетических комплексов.
И винтики считает военное представительство.
К каждому требованию-накладной на конкретный заказ надо ещё и приходную накладную и СФ поставщика приложить.
Это утопичный и не совсем правильный подход. Затраты на ведение такого учета многократно превысят профит.
подвижных средств технического обслуживания, ремонта и эвакуации;
обитаемых модулей постоянного и переменного объема;
комплексов мобильной техники различного назначения;
энергетических комплексов.
И винтики считает военное представительство.
К каждому требованию-накладной на конкретный заказ надо ещё и приходную накладную и СФ поставщика приложить.
Назад в прошлое к УПП уже как-то не хочется
"ЕРП слишком сложная и потребует очень больших сил и ресурсов по внедрению и настройке."
нам нужно только производство, никакого регламентированного учета, з/п, бюджетирования и т.д.
а для производства там все уже настроено
"ЕРП слишком сложная и потребует очень больших сил и ресурсов по внедрению и настройке."
нам нужно только производство, никакого регламентированного учета, з/п, бюджетирования и т.д.
а для производства там все уже настроено
(11)
Страшно же. Существующая система не 1С-ная вешается периодически.
База на Oraclе летает просто. На уровне сервера приложений - раза 3 в неделю висим до перезапуска.
Кстати построена система логически тоже так - каждый цех отдельное предприятие и отдельная база.
Страшно же. Существующая система не 1С-ная вешается периодически.
База на Oraclе летает просто. На уровне сервера приложений - раза 3 в неделю висим до перезапуска.
Кстати построена система логически тоже так - каждый цех отдельное предприятие и отдельная база.
(13)
Висяки это не совсем не главная причина почему про новую систему задумываться стали.
Там есть кое-какие более существенные минусы. Например: только количественный учет, без всякой себестоимости.
Но действительно, тут стоит трижды подумать стоит ли что-то делать.
Работает - не трогай )))
Висяки это не совсем не главная причина почему про новую систему задумываться стали.
Там есть кое-какие более существенные минусы. Например: только количественный учет, без всякой себестоимости.
Но действительно, тут стоит трижды подумать стоит ли что-то делать.
Работает - не трогай )))
Есть ERP 2.4, есть УНФ 1.6. Обе базы заполнены всей необходимой нормативкой
(структура предприятия, номенклатура, ресурсные спецификации и маршрутные карты, схемы обеспечения и др.), нормативка ежедневно обновляется, больше пока ничего в них не делаем.
Но планировать заказы и запускать их в производство можно прямо сейчас
(структура предприятия, номенклатура, ресурсные спецификации и маршрутные карты, схемы обеспечения и др.), нормативка ежедневно обновляется, больше пока ничего в них не делаем.
Но планировать заказы и запускать их в производство можно прямо сейчас
Кроме данных, все процессы тоже проработаны в двух системах?
(18)
А вот это пункт как раз в УНФ опробовали.
Производственные документы за месяц проводились около 4 суток.
Закрытие месяца с расчетом себестоимости (только прямые затраты) совсем быстро, полчаса максимум.
В ERP по ощущениям в разы медленнее будет, но пока не пробовали.
А вот это пункт как раз в УНФ опробовали.
Производственные документы за месяц проводились около 4 суток.
Закрытие месяца с расчетом себестоимости (только прямые затраты) совсем быстро, полчаса максимум.
В ERP по ощущениям в разы медленнее будет, но пока не пробовали.
(19)У меня вот то же есть сейчас база в которой 20К документов в месяц сутки проводятся.
Попробуйте в ЕРП ну и косвенные для полноты картины. Ещё посмотрите разные корректировки и тд которые реально вводились за месяц в текущую учётную систему. А то бывает что придут и просят что то скорректировать в уже закрытых периодах и когда СС уже рассчитана. Посмотрите как отработает.
Попробуйте в ЕРП ну и косвенные для полноты картины. Ещё посмотрите разные корректировки и тд которые реально вводились за месяц в текущую учётную систему. А то бывает что придут и просят что то скорректировать в уже закрытых периодах и когда СС уже рассчитана. Посмотрите как отработает.
Про закрытые периоды - не в нашем случае, приучены уже старой системой, там только оперативный учет.
Дата всегда в новый документ текущая подставляется. Не новые изменить нельзя, только отдельной корректировкой.
Ну и про косвенные затраты тоже речь не идёт, это всё в БП.
Документов за месяц (включая резервирования запасов) было 560К, правда многие из них однострочные.
А в остальном Вы наверное правы, надо пробовать повторять все это в ЕРП.
Дата всегда в новый документ текущая подставляется. Не новые изменить нельзя, только отдельной корректировкой.
Ну и про косвенные затраты тоже речь не идёт, это всё в БП.
Документов за месяц (включая резервирования запасов) было 560К, правда многие из них однострочные.
А в остальном Вы наверное правы, надо пробовать повторять все это в ЕРП.
(32)
Территориально и производство в разных, и то что делается в ЕРП в разных
Совместить то и то в одной базе - не вариант СОВСЕМ.
Задумывалось что в ЕРП производство будет отражаться как выше писали "менее детализировано".
Сейчас - там сейчас работают склады, совсем криво, себестоимость не рассчитывается совсем. Плюс какие-то планы бюджетов, сбора факта не предвидится.
База в полном ауте пару часов каждый день (вообще не запускается, сервис не найден).
Ах да, самое главное, это ЕРП + БИТФинанс холдинг, даже не спрашивайте кто до этого додумался.
Результат не нулевой, а очень сильно отрицательный о сравнению с тем что было до того.
НО! Конечно в этом не ЕРП виновато, причины совсем другие.
Территориально и производство в разных, и то что делается в ЕРП в разных
Совместить то и то в одной базе - не вариант СОВСЕМ.
Задумывалось что в ЕРП производство будет отражаться как выше писали "менее детализировано".
Сейчас - там сейчас работают склады, совсем криво, себестоимость не рассчитывается совсем. Плюс какие-то планы бюджетов, сбора факта не предвидится.
База в полном ауте пару часов каждый день (вообще не запускается, сервис не найден).
Ах да, самое главное, это ЕРП + БИТФинанс холдинг, даже не спрашивайте кто до этого додумался.
Результат не нулевой, а очень сильно отрицательный о сравнению с тем что было до того.
НО! Конечно в этом не ЕРП виновато, причины совсем другие.
(37)
И ведь там в обсуждении условия в разы получше наших будут, и количество пользователей меньше, и номенклатуры и документов в день.
Поэтому всё-таки УНФ.
Спасибо за содержательную беседу!
Ещё почитайте ветки про эксплуатацию УТ 11 и ЕРП с большим количеством пользователей что бы понимать что вас ждёт и какие механизмы лучше не использовать.
И ведь там в обсуждении условия в разы получше наших будут, и количество пользователей меньше, и номенклатуры и документов в день.
Поэтому всё-таки УНФ.
Спасибо за содержательную беседу!
(40)
Да, механизм там такой же.
Кстати говоря есть впечатление что 1С на УНФ все новинки и тестирует. И режим совместимости с платформой там повышается первым.
Можно и не использовать доп.реквизиты, свои с префиксом добавлять.
Наверное это быстрее должно быть. Обновляться не помешает, да и частое обновление производственной системе не особо и нужно.
Да, механизм там такой же.
Кстати говоря есть впечатление что 1С на УНФ все новинки и тестирует. И режим совместимости с платформой там повышается первым.
Можно и не использовать доп.реквизиты, свои с префиксом добавлять.
Наверное это быстрее должно быть. Обновляться не помешает, да и частое обновление производственной системе не особо и нужно.
(42)
2000 не будет, это количество рабочих такое
Сейчас в производственной системе 10-15 пользователей в каждом из 23 цехов.
Причем все одновременно они не работают, лицензий 150, хватает.
А если сделать как сейчас у нас, цех = организация, по базе на цех и РИБ по организациям, вообще проблем не ожидается.
А если вдруг - да хоть по отдельному серверу для каждого цеха.
2000 не будет, это количество рабочих такое
Сейчас в производственной системе 10-15 пользователей в каждом из 23 цехов.
Причем все одновременно они не работают, лицензий 150, хватает.
А если сделать как сейчас у нас, цех = организация, по базе на цех и РИБ по организациям, вообще проблем не ожидается.
А если вдруг - да хоть по отдельному серверу для каждого цеха.
(43)
Такой подход в рамках одного производства не грамотный, и скажу от себя: "не компетентен, выбравшие такою модель плохо понимают производственный процессы если вообще понимают их"
А если сделать как сейчас у нас, цех = организация, по базе на цех и РИБ по организациям, вообще проблем не ожидается.
А если вдруг - да хоть по отдельному серверу для каждого цеха.
А если вдруг - да хоть по отдельному серверу для каждого цеха.
Такой подход в рамках одного производства не грамотный, и скажу от себя: "не компетентен, выбравшие такою модель плохо понимают производственный процессы если вообще понимают их"
(46)
Рассчитаем.
В УНФ стоимость списания материалов по средней скользящей рассчитывается в момент проведения документов.
Корректировок задним числом нет и не будет. Закрытие месяца корректирует до средней взвешенной или ФИФО (условное).
Никаких других затрат затрат кроме прямых материальных не требуется отражать.
Месяц закрывать в таких условиях вообще нет необходимости.
Единственное что нужно сделать - в расходной накладной по передаче полуфабриката в другой цех подставлять автоматически цену и сумму, рассчитанную как себестоимость списанных на его изготовление материалов.
Рассчитаем.
В УНФ стоимость списания материалов по средней скользящей рассчитывается в момент проведения документов.
Корректировок задним числом нет и не будет. Закрытие месяца корректирует до средней взвешенной или ФИФО (условное).
Никаких других затрат затрат кроме прямых материальных не требуется отражать.
Месяц закрывать в таких условиях вообще нет необходимости.
Единственное что нужно сделать - в расходной накладной по передаче полуфабриката в другой цех подставлять автоматически цену и сумму, рассчитанную как себестоимость списанных на его изготовление материалов.
(54)Потому что при таком подходе мы получаем фактически тоже самое что при котловом, ну может по точнее. Мы не можем получить оперативную оценку НЗП, в переделе, себестоимость сформируется только когда продукция выйдет из производства, до этого она вся в материале, и хрен знает что там творится, по сути тот же котловой учет.
(63)
Не только из-за себестоимости, есть другие проблемы. Например нельзя перепланировать заказ.
Можно его только отменить и создать новый. Нет механизма использования аналогов материалов и т.д.
И себестоимость.
По средней за месяц - и экономиста не надо, сейчас считается по последнему приходу, можно легко сделать и по средней за период.
Но есть 275-ФЗ, "О государственном оборонном заказе".
Там даже закупаться какой нибудь болт М6 должен отдельно для каждого заказа. И оплачиваться с отдельного счета.
А без партионного учета никак, партионный учет придётся приделать )
Не только из-за себестоимости, есть другие проблемы. Например нельзя перепланировать заказ.
Можно его только отменить и создать новый. Нет механизма использования аналогов материалов и т.д.
И себестоимость.
По средней за месяц - и экономиста не надо, сейчас считается по последнему приходу, можно легко сделать и по средней за период.
Но есть 275-ФЗ, "О государственном оборонном заказе".
Там даже закупаться какой нибудь болт М6 должен отдельно для каждого заказа. И оплачиваться с отдельного счета.
А без партионного учета никак, партионный учет придётся приделать )
(49)
Все прочие расходы - как и сейчас, в БП. Там по тоже по цехам и по заказам (используются ном.группы).
Производство отражается укрупненно, но формируется по данным производственной системы.
В результате в БП не 5000 полуфабрикатов по заказу, а 5 например, по количеству цехов принимавших участие в изготовлении.
И про УНФ я немного неточно, там при проведении документа и материалы с себестоимостью списываются и полуфабрикат на склад с себестоимостью приходит.
Все прочие расходы - как и сейчас, в БП. Там по тоже по цехам и по заказам (используются ном.группы).
Производство отражается укрупненно, но формируется по данным производственной системы.
В результате в БП не 5000 полуфабрикатов по заказу, а 5 например, по количеству цехов принимавших участие в изготовлении.
И про УНФ я немного неточно, там при проведении документа и материалы с себестоимостью списываются и полуфабрикат на склад с себестоимостью приходит.
(66)Ну вообще то я не видел ни в УПП, ни в ERP, ни в УНФ партионного учета, только серийный, который можно косвенно назвать партионным в определенных случаях. И опять же в разрозненных базах вы этого не получите, партия должна быть сквозной до того момента пока не будет снята с учета. Ну разве что ваши 1С программисты смогут написать распределенное приложение.
(69)
В УПП тоже нет разве?
В УТ 10.3 есть, был у нас и такой вариант для производства)))
Партию сквозной сделают, в расходной накладной из цеха она будет, в приходной другого цеха какая-то ссылка на расходную будет.
Цепочку проследить можно. Как-то так примерно.
В УПП тоже нет разве?
В УТ 10.3 есть, был у нас и такой вариант для производства)))
Партию сквозной сделают, в расходной накладной из цеха она будет, в приходной другого цеха какая-то ссылка на расходную будет.
Цепочку проследить можно. Как-то так примерно.
(75)
Ну во-первых не в одной локальной сети, а во вторых мы сейчас имеем фактически РИБ на одном сервере ))
Вот на картинке, это базы данных цехов в Oracle.
Две центральные базы, по одной на каждую производственную площадку, остальные для каждого цеха-организации.
Центральные склады и другие цеха являются контрагентами для цеха.
Ну во-первых не в одной локальной сети, а во вторых мы сейчас имеем фактически РИБ на одном сервере ))
Вот на картинке, это базы данных цехов в Oracle.
Две центральные базы, по одной на каждую производственную площадку, остальные для каждого цеха-организации.
Центральные склады и другие цеха являются контрагентами для цеха.
Прикрепленные файлы:
(76)
А вот из описания системы:
"Это решение, основанное на распределенной сетевой модели производственной логистики, в которой отдельные производственные подразделения взаимодействуют между собой по принципу «заказчик-поставщик» и объединены в структуру, охватывающую все производство.
При таком децентрализованном подходе к построению модели управления производством сложно устроенная общая производственная система разветвляется на простые по своей структуре подсистемы, представляющие собой производственные подразделения."
"Так как Система имеет модульную структуру, то она практически неограниченно масштабируема."
А вот из описания системы:
"Это решение, основанное на распределенной сетевой модели производственной логистики, в которой отдельные производственные подразделения взаимодействуют между собой по принципу «заказчик-поставщик» и объединены в структуру, охватывающую все производство.
При таком децентрализованном подходе к построению модели управления производством сложно устроенная общая производственная система разветвляется на простые по своей структуре подсистемы, представляющие собой производственные подразделения."
"Так как Система имеет модульную структуру, то она практически неограниченно масштабируема."
(77)
"Гибкая настройка на любую производственную структуру путем объединения в сеть программных модулей, предварительно сконфигурированных под различные производственные единицы (рабочие центры, участки, цеха и т.д.);
Быстрая адаптивность к изменениям в организации или характере производства;
Поэтапность внедрения с получением существенного эффекта при внедрении даже в одном производственном подразделении;
Допустимость различной степени детализации нормативных данных (технологических маршрутов изготовления) для разных производственных подразделений;"
"Гибкая настройка на любую производственную структуру путем объединения в сеть программных модулей, предварительно сконфигурированных под различные производственные единицы (рабочие центры, участки, цеха и т.д.);
Быстрая адаптивность к изменениям в организации или характере производства;
Поэтапность внедрения с получением существенного эффекта при внедрении даже в одном производственном подразделении;
Допустимость различной степени детализации нормативных данных (технологических маршрутов изготовления) для разных производственных подразделений;"
(79)
Это не мы извращенцы, это немцы немецкие )))
Базы не тормозят, проблем с синхронизацией никаких нет.
Вот сервер приложений да, виснет иногда пару раз в неделю. Но 100% это тоже решаемая проблема, просто пока особо никого не напрягает.
А так, ну вот например рассчитать трудоемкость 5000 полуфабрикатов (в которые в свою очередь другие естественно входят) - не более пяти минут в понедельник заняло, простой обработкой запускаемой из 1С.
Это не мы извращенцы, это немцы немецкие )))
Базы не тормозят, проблем с синхронизацией никаких нет.
Вот сервер приложений да, виснет иногда пару раз в неделю. Но 100% это тоже решаемая проблема, просто пока особо никого не напрягает.
А так, ну вот например рассчитать трудоемкость 5000 полуфабрикатов (в которые в свою очередь другие естественно входят) - не более пяти минут в понедельник заняло, простой обработкой запускаемой из 1С.
(81)
Не сами немцы, у них тут "дистрибьюторы" есть. И не 1С конечно.
Суть в том что логика того что у нас сейчас работает, децентрализованная, распределенная,
может быть реализована на любой простой в том числе 1С системе,
что даст нам возможность сделать систему более гибкой
Не сами немцы, у них тут "дистрибьюторы" есть. И не 1С конечно.
Суть в том что логика того что у нас сейчас работает, децентрализованная, распределенная,
может быть реализована на любой простой в том числе 1С системе,
что даст нам возможность сделать систему более гибкой
(85)
Вообще-то немудрено конечно во всем этом запутаться.
Есть то что на картинке, немецкая система, работает лет 6-7 уже.
По ряду причин хотим ее заменить на другую.
ЕРП очевидно не вариант - не взлетит.
Мысль - построить такую же распределенную как та что сейчас работает,
но в качестве цехового модуля использовать что-либо из 1С, наиболее подходит для этого УНФ
Вообще-то немудрено конечно во всем этом запутаться.
Есть то что на картинке, немецкая система, работает лет 6-7 уже.
По ряду причин хотим ее заменить на другую.
ЕРП очевидно не вариант - не взлетит.
Мысль - построить такую же распределенную как та что сейчас работает,
но в качестве цехового модуля использовать что-либо из 1С, наиболее подходит для этого УНФ
(87)А зачем такую же архитектуру, у вас что сети по телефонным линиям, или к немецкому ПО подключено оборудование? Тем более немцы делали такую архитектуру 7 лет назад и исходя из возможностей своего приложения. Вы же не знаете как оно работает внутри по факту
(89)Не вижу серьезных проблем, у вас стоит Oracle у него большой ресурс, вы даже не загрузите его на 50% . Только вот сервера 1С боюсь придется ставить в каждом цехе, и выделять отдельную VPN сеть для этого (ну это системные администраторы без проблем сделают)
(93)
Точную формулировку уже никто не помнит, но его поставили, попробовали что-то, не получилось.
Выясняли сначала у представителей, потом и у самих немцев, те ответили что-то вроде слишком
большой объем расчетов, слишком большая детализация производства и т.д.
Точную формулировку уже никто не помнит, но его поставили, попробовали что-то, не получилось.
Выясняли сначала у представителей, потом и у самих немцев, те ответили что-то вроде слишком
большой объем расчетов, слишком большая детализация производства и т.д.
(67)Все можно сделать, главное заняться этим вопросом серьезно. Я же вам раньше писал что нужен серьезный анализ, а уже потом выбор ПО, если вы определились с ПО, значит определяйтесь с тем что будет в нем реализовывать, или ищите другое ПО с подходящими параметрами для вас.
Напишите ваше сообщение
(73) Полностью согласен.
Требуется понимать какие задачи решаем, как и с помощью чего.
Желательно, вплоть до описания функций сотрудников по должностям.
И желательно провести тест-драйв выполнения этих функций, особенно с учетом возможных корректировок на различных этапах.
(73) Полностью согласен.
Требуется понимать какие задачи решаем, как и с помощью чего.
Желательно, вплоть до описания функций сотрудников по должностям.
И желательно провести тест-драйв выполнения этих функций, особенно с учетом возможных корректировок на различных этапах.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот