Всем привет!
Есть компания с двумя производственными филиалами и 10 торговыми филиалами по России.
Сейчас учет ведется на 7.7, Производство на слегка дописанной ТиС, торгуют через обычную торговлю.
Так же есть куча бухий и зиков, боле менее типовых. Поставлена задача перейти на 8.
Есть уже купленная УПП. Поскольку УПП вроде развиваться уже не будет дальше, имеет смысл видимо купить ERP.
Имеет ли смысл поочередно переносить все базы из 7.7 на ERP или лучше купить отдельно сначала БП,
перенести туда все бух 7.7, потом УТ и тд, и в конце уже переводить производственный блок на ERP?
Насколько вообще реально все запихнуть в ЕРП, если, как обычно, есть разница между упр и регл учетом?
И вообще насколько реально перейти своими силами (2 прога своих) при наличии
определенной квалификации? Или самим даже не стоит браться, а сразу приглашать стороннюю контору с опытом?
Поделитесь опытом перехода пж.

(29) ну в общей сложности около 300 наверно, а максимум одновременно работают на пр-ве около 40

(30) У автора нет опыта внедрения УПП. Есть только сама конфа - купленная, но не внедренная. Лежи на полке. Вряд ли это можно считать наличием опыта.

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

(32) > УПП все же пока еще на поддержке

Ключевое словосочетание "пока ещё".
Вопрос - что делать, когда поддержка закончится? Затевать следующий переход на ERP? Пытаться поддерживать УПП своими силами? Всё это весьма нетривиальные вопросы, ответы на которые требуют очень вдумчивого, внимательного и взвешенного подхода. Удовольствие то не из дешевых - подобные переходы. И решения будут иметь весьма далеко идущие последствия.

(36) Тоже самое можно сказать и про ERP. Ну с разницей в 3-4 года и она будет "пока еще"

(36) Внедрять УПП смысла нет, как внедрять ЕРП зависит от бюджета сего мероприятия

(37) > с разницей в 3-4 года...

ИМХО, это весьма существенная разница. Внедрять УПП, чтобы сразу по окончании внедрения начинать проект по переходу на ERP или мегаперепиливанию внендрённой УПП из-за того, что УПП больше не поддерживается, а законодатель вдруг решил переосмыслить учет НДС или НДФЛ, - это ответственное решение.

Но повторюсь - вопрос требует очень и очень взвешенного подхода.

(38) Склонен согласиться.
Внедрять устаревающий продукт, сроки завершения поддержки которого уже известны, - несколько странно (при любых преимуществах УПП по сравнению с ERP). Надо очень внимательно риски оценивать.

(40) А какие преимущества? Я сейчас все функциональные опции для одного проекта по отключал, и вполне простенький продукт получился

(40) какие преимущества?

(42) Количество спецов на рынке труда

(41)(42) Любые гипотетические, включая совершенно надуманные и высосанные из пальца.
Подробнее см. (22)(23)(32).

(40) "сроки завершения поддержки которого уже известны" - и какие же? и пожалуйста оф.ссылку на такую инфу

(40) "сроки завершения поддержки которого уже известны" - можно дать ссылку или озвучить?

https://solutions.1c.ru/news/news.html?news_id=4463
Об условиях сопровождения конфигурации "Управление производственным предприятием" и об исключении продукта из прайс-листа в 2018 г.

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

(45)(46) Инфаписьма не было об этом ;-)

(47) поддержка и сейчас за отдельные бабки.

(47) "исключение из прайса" и "прекращение поддержки" - совершенно разные вещи. с 2020 года планируется увеличить стоимость поддержки УПП, но о прекращении сопровождения/поддержки нигде ни слова не было

(48) так вот и я об этом же

(47) о прекращении поддержки заранее сообщат и не менее чем за 3 (три) года (см. п.2 по данной ссылке)

(52) Дык про поддержку УПП баян же ;-)

Вопрос только - сколько эта поддержка будет стоить после 2020 года (который не за горами) и как долго она продлится после...

> о прекращении поддержки заранее сообщат и не менее чем за 3 (три) года

Да. Только не известно когда об этом сообщат. Может через несколько лет, а может завтра. И если это вдруг случится завтра, то будет сложно объяснить руководству, что мы перешли на УПП ради того, чтобы уже через 2 года затевать новый проект по переходу на ERP.

Реально они смогут внедрить УПП не ранее чем с 2019 года. И то при условии, что начнут прямо сейчас, ничего глобального допиливать и переделывать не потребуется, а учёт у них достаточно простой и полностью ложиться в логику УПП. Гораздо более вероятные сроки - с 2020 года. А это уже год повышенной стоимости поддержки. И всё это время дамокловым мечом будет висеть угроза объявления 1С о прекращении поддержки УПП.

(47) Бухгалтерию 2.0 еще поддерживают, а когда грозились ее перестать поддерживать? лет 5 назад - громко прямо на шабашах объявляли "Бух 3.0 - наше все, кто не перейдет - сам виноват" и где эти все лозунги сейчас?

(54) и если, также как и пишется в (0) будут ещё и типовая Бух и ЗУП, то прекращение поддержки УПП ну никоим образом серъезно не скажется. Если конечно нормально распределить назначения ИС

и да, а 7.7 когда прекратить поддежку должны были? и до какого к ней оф.отчетные формы в новых форматах ваяют?

(54) "сколько эта поддержка будет стоить после 2020 года" - так один раз в кафе посидеть, нормально.... по сравнению с внедрением ЕРП "слезы"....

(25) >Кто нибудь реально работает в ЕРП с использованием всех разрезов учета в одной базе? чтоб без миллиона выгрузок туда сюда?

Шухард ьы тебе ответил, но похоже он завален внедрениями на много лет вперёд

(58) (25) Конечно работают,
Выгрузка в ЗУП требуется чтобы не обновлять корпоративную учетную систему каждую неделю
Выгрузка в БП требуется если необходимо упростить бух учет, при сложном упр учете

не взлетит

(60) Ёмко

(39) Есть разница.
Грубо говоря чтобы перейти с ТиС на УТ10. Нужно около X тысяч рублей (сюда входит обновления серверов, лицензии, обучение персонала и т.п.)

Чтобы перейти с ТиС на УТ11 уже нужно около (1,5-2,5)*Х денег, так как сервера нужны мощнее, возможно придется изменить сетевую инфраструктуру по УФ, обучения дороже, так как безнес-процессы в УТ10 практически слово в слово повторяют ТиС, а вот УТ11 - это совершенно другой продукт, с другим походом, а значит нужно ломать стереотипы и переписывать бизнес-процессы, что стоит время и денег


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

И вот уже через 5 лет переходить на УТ11.

Это позволить растянуть расходы по времени. Т.е. нужно не сразу вынуть 20 лямов на переход, а постепенно. Оценить масштаб угрозы, ибо скорость работы на 8-ке SQL несопоставима со скоростью работу 7-ки на ДБФ, а значит или чем то жертвовать надо или наращивать железо, но оценить это все на бумаге не получиться, нужна практика и опыт. А точно оценить масштаб угрозы перехода на железе на котором 7-ка еле дышит - ну достаточно проблематично

Поэтому иногда, проще переходить поэтапно

(62) попробуй применить свои подходы в строительстве.

Сначала фундамент, потом стены, потом проектирование коммуникаций, потом вырежешь окна ;-)

а какое производство? Простое? сложное? есть ли обе давальческие схемы? Есть ли сложный НДС?

По поводу ERP:
возьмите типовую, смоделируйте ваши процессы и ваш учет в ней, увидите разрывы - поймете, насколько овчинка близка к выделке.
К тому же, вопрос: насколько у вас УУ и БУ расходятся?

(64) > смоделируйте ваши процессы и ваш учет в ней

ИМХО, уже на этом этапе всё умрёт...
Тут квалификации программиста недостаточно.

(65) Ну чел же не РП, а программисты не боги, он или знает платформу или методологию

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

Может сначало построить кирпичный дом, посмотреть как это оно, а потом уже и за панельный дом браться

(67) почему глупо? Не жили хорошо, нечего и начинать?

Любой проект автоматизации-это кризис для организации, возможность преодоления кризиса говорит о состоянии организации, или она здоровая или она больная

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

(0)
если ...Производство на слегка дописанной ТиС...
то на ERP вы загнетесь - думаю ваш вариант УТ + БП

(70) Здоровые управленцы, как здоровые капитаны, могут вести свой корабль, хоть в штиль, хоть в бурю
(71) Ты ЕРП то видел?

(72) так ты из этих? - из франчей ? :)

(73) Технически на фикси я работал 8 месяцев, во франче не работал уже 7 лет ;-)

"насколько реально перейти своими силами (2 прога своих)" // Если один - это c компетенциями спеца-консльтанта по типовому продукту, а другой - с компетенциями разработчика-эксперта, то легко

Начинать надо с заказа моделирования целевых БП на типовом ПО

(75) Спеца по продукту хватит, пока не влезешь в себестоимость ;-) Но это обходится за счет знаний продукта

(36) Я так думаю, пока люди будут готовы платить за поддержку - УПП будет поддерживаться. И чем меньше таких людей будет - тем больше будет стоить подписка на год. Бухгалтерию 6.0 уже прекратили поддерживать, или все еще выпускают обновления? А 7.7?

(40) ERP еще сырая, и постоянно переделывается. Причем нередко кардинально - что-то исчезает, и вместо этого появляется новое видение. Так что риски не меньше.

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

(80) Ну чисто теоретически на каком-нибудь небольшом свечном заводике, где всего пара десятков пользователей, простое производство, все операции укладываются в логику ERP и речь идет только о внедрении производственного учета, БУ и НУ (без всяких там бюджетирований, сложных торговых бизнес-процессов, НДС, кадрового и зарплатного учета и пр. и пр.), а спецы действительно с хорошим опытом за плечами, то такое возможно. В адекватные сроки.

Проблема в том, что это явно не случай автора.

(80) На 70 пользаков внедрял в 1-го методолога и 1 программиста 7-шника УПП

ессно я не знаю программирования от слова совсем

(82) Ну то есть я правильно понимаю, что вы вдвоем: проводили предпроектное обследование областей автоматизации (закуп, торговля, казначейство, бюджетирование, производство, бухгалтерия, управление зарплатой и кадрами), агрегировали бизнес-требования, моделировали бизнес-процессы as is и to be, проектировали систему, подготавливали устав проекта для согласования с руководством, выявляли несоответствие to be с типовым функционалом и писали ТЗ (на разработку, карту ролей и т.д.), настраивали и программировали типовой продукт, писали по нему инструкции пользователей, обучали персонал компании работе (по карте ролей для каждого - отдельный курс), делали перенос данных из всех старых систем и производили запуск?

(84) Без ЗП, там был отдельный перец, а так -да, весь проект 5 месяцев, от старта до финиша и сдачи отчетности

вернее 5 месяцев тела проекта,2 месяца на 50% загрузки, модель учета делается по предприятию 2 недели, еще 2 недели нужно писанины и тестинга

(85) Скорее всего, поставили УПП, загнали туда бух. данные из старой базы и сказали - работайте. Под внедрением ERP мы с вами понимаем разные вещи.

(87) 87000 номенклатуры, 15к активных спецификаций ;-) тебе о чем-то говорит?

(87) Если вы не можете построить работу оптимально, это проблема ваша

(88) Как зависит качество внедрения ERP от объема номенклатурного справочника?

(90)  Себестоимость посчитана по итогам внедрения, которая до этого в компании не считалась? Так устроит?

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

(92) Заплати денег и все покажу ;-)

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

(92) ИМХО, качество внедрения определяется не документацией, а всего лишь двумя параметрами:
1. Достижение поставленных целей (в данном примере - расчет себестоимости в новой конфе)
2. Удовлетворенность заказчика.

Пренебрежение документацией, её полнотой и качеством вполне обычное явление в 1С. И кстати говоря, далеко не только в 1С, но и  в богомерзком SAP (который нахваливают за бизнес-процессы) тоже, и во многих других системах.

> я и за день могу типовую УПП в ларек поставить...

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

(95) Дружище, я внедрял как УПП, так и SAP (опа, сюрприз!). И то и другое с нуля. Не надо мне рассказывать сказки. Программный продукт без методологии, грамотно смоделированной и четко описанной на бумаге - кусок известной субстанции.

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

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

(96) > кусок известной субстанции.

Который зачастую работает без документации (опа, сюрприз!).
Раз уж у тебя есть опыт, то скажи честно - неужели ты не встречал не разу ситуаций, когда методист, консультант или менеджер модуля самостоятельно настраивали всю систему и её параметры (включая внесение ключевой НСИ), а для пользователей просто (чуть ли не вербально) давали инструкции - как выполнять те или иные операции и что нужно для получения результата (отчетов, расчетов, регламентов). А вся документация ограничивалась каким-то совсем уж минимальным набором инструкций и некоторым упоминанием в приложениях к приказу об учетной политике о порядке и методиках ведения учета.

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

(97) Да не хотел я вас обидеть, боже упаси. Ну ВНЕДРИЛИ вы вдвоем ERP-систему на огромном предприятии, автоматизировали все области, обучили всех, и потом не допиливали ее 2 года, ок, значит я лошара, я так не умею. А вы молодец. Поделитесь с ТС своим богатым опытом, их тоже двое.

(99) Я не встречал. У меня стандартный пакет документации на любом проекте: устав, моделирование, ТЗ, инструкции. У других, возможно, ничего нет, и это всех устраивает. Это на их совести.

(100) Какое огромное? 600 человек, это небольшое. Я сказал ТСу, что на 300 пользаков, у них нет шансов. Просто тупо не вытянут нагрузки, а ведь дорабатывать еще надо.

(101) Устав- в зависимости от типа клиента, у нас он тоже есть. По уставу обычно понятно, представляет ли клиент сложность перехода или нет, когда мы резервируем в рабочую группу лучших спецов с 50-100% участием ;-)

Моделирование- аналогично, обычно модель перехода ас ис, и целевая модель ту би, но это не момент перехода, а момент развития ИС
Инструкции- а ты без них не запустишься, 50-70 пользаков на 1 конса только при наличии инструкций, без инструкций- 20-30 в максимуме.

(80) Хз о чем ты. Кроме методолога-консультанта и хорошего разработчика никто в принципе больше и не нужен. Остальное - ненужная мишура.

(103) а кто будет бороться с саботажем сотрудников? консультант или разработчик?

(104) Консультант методолог ессно, разработчик только кодит

Кто будет жестко отсеивать левые хотелки?

(105) те нужно рп-консультант + кодер

(107) Методолог он же не просто так называется

(107) Программер, кодер не нужен, ТЗ же не будет

(103) А методолог-консультант, я так понимаю, у тебя разбирается досконально и в бюджетировании, и в производстве, и в бухгалтерии, и в зарплате, и в торговле, и в закупе. Право слово, тогда не понимаю, зачем программист нужен, за него методолог-консультант может все сделать. Он должен это уметь. Будет странно, если еще понадобится админ для развертки серверов, установки SQL и т.д. Это тоже должен методолог-консультант сделать. Один человек за месяц все должен сделать.
Чего компании парятся, проектные группы собирают, эджайлы всякие с вотерфолами придумывают... Главное, нужного человека найти!

(109) а консультант на что?

Хз о каком ты месяце, видимо ты на своей волне

(110) а если он еще и прогать будет уметь, то вообще в одного все сделает

(110) Но принципе да. Вся эта проектная шелуха - это теория о том как средними людьми поднять  большой проект

(114) Ты прав на 100%

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

(101) > стандартный пакет документации на любом проекте: устав, моделирование, ТЗ, инструкции

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

(116) проектная методология никак не соотносится с методологией сопровождения

(117) в жизни все эти инструкции и тз устаревают мгновенно и никто не поддероживает их актуальность

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

(119) никто не хочет за это платить, у меня эта часть режется 1-й, когда видят ценник ;-)

Поэтому обычно пишу 2 набора инструкций
на запуск
На  поддержку, когда функционал стабилизирован

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

(120) Не надо ничего классифицировать, мы уже выяснили, что вы вдвоем можете внедрить ERP-систему. Все, ТС как бы об этом спрашивал. Не надо мне ничего доказывать словами, помогите ТС делом.

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

проект вполне можно внедрить своими силами, если есть очень заинтересованные люди, которы еготовы быть рп "на стороне бизнеса"

например это может быть ГБ

(125) Не понял тебя сначала, ты про эджайлы.

Или директор, но директор должен не в слишком большой компании. в слишком  большой директор только стратегией занимается

(124) Ему уже тут все написали, заметь ТС, уже вопросов не задает

(130) да ТС просто в шоке, от того, что тут понаписали.

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