Добрый день!
На 24м году работы с 1с внезапно понял, что хочу (хотя бы частично) специализироваться на обновлении сложных нетиповых.
Люблю это дело, и получается, что умею в него достаточно изрядно))
Может ли существовать вообще среди нашего сообщества "рынок" таких услуг?
(Если вдруг у кого-то есть сразу конкретика - обращайтесь:-))

Может ли существовать вообще среди нашего сообщества "рынок" таких услуг
за 24 года не в курсе за рынок ?

Свежая регистрация и первое же сообщение с прицелом на рекламу. Подстраховался от возможных последствий? =)

(0) Муахаха
Это реально смешно

Представь на проекте допиленную ЕРПУХ (+ бесшовка с ДО) релиз дважды догоняли
Каждый раз месяц примерно выделенный спец обновлял (update) пытаясь учесть все доработки
С неоднократным тестированием аналитиками и заказчиком
И все осложнялось что проектные доработки в процессе update на старом релизе вперед убегали и приходилось каким-то местом совмещать доработки и новый релиз

И потом еще месяц-два уже в процессе на проде ошибки всплывали
И командой (2-3 аналитика и столько же разрабов) исправляли как поломанное типовое так и восстановление требуемого доработанного функционала

(0) специализироваться на обновлении сложных нетиповых.
ну, что такое нетиповые, это вроде бы понятно.
ЕРПУХ сюда не катит, она же типовая? Хоть и доработанная, но типовая? Так?
Аналогично всякие УПП и все такое прочее БП УТ и т.д.? Так?

Вот у меня и вопрос - что ты подразумеваешь под сложными нетиповыми? Доработанные-переработанные типовые или реально только исключительно нетиповые?
А то как-то непонятно у тебя сформулировано - сложные нетиповые... хм.

(3) Ничего смешного не вижу.
Страшного впрочем тоже.
Брать в работу и делать))
"Законные" типовые объекты, типовые объекты, взятые из других релизов, и объекты, добавленные собственными программистами, отличаются на этапе сравнения/обьединения довольно явственно. Код впрочем тоже, дописки как правило имеют неповторимую, не свойственную для типовых стилистику, даже если программер принципиально не ставит метки..

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

(5) Это к тому что если не в курсе типового и допиленного функционала
Не понимаешь что это и зачем? И спросить некого кто знает
То нифига не сделаешь в разумные сроки и нормально, без кучи ошибок и итераций

(4) В первую очередь конечно допиленные/перепиленные, но не снятые с поддержки 1сные (включая ЕРПУХ) и отраслевые конфигурации.
В качестве отдельного извр... развлечения можно конечно и снятые с поддержки, слепленные из нескольких, частично обновленные и тд
Само собой не самописки, для них обновлений не выпускают))

(6)+ Вот банальный пример в теме
1С ДО 2 - настройка заполнения файла шаблона

В ДО работала вставка таблиц скриптами в режиме предприятия в шаблонах
А потом опс и перестала
И вперед самому (часто в инете ничего нет) разбираться/копаться с отладкой в куче модулей и кода почему перестало работать

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

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

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

(9)
Эмм
Может ты и хочешь но походу не умеешь

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

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

3. Проверяем что работает, если нечто не работает комментим доработки, возвращая по максимуму к типовому

4. Когда база-конфа обновлена до нужного типового и типовой функционал работает - приступаем к восстановлению всех доработок, используя сохраненное/проанализированное в п.1

5. Итерации возможно придется повторять несколько раз и писать свои обработчики
Если некие данные не сохранились или не сконвертировались правильно
Например был один регистра а стало два или наоборот
А доработки с данными не в том регистре что надо

6. Когда все отлажено на тестовых можно писать регламент/процесс обновления для базы прода
Возможно потребуются несколько скачков по релизам с запуском на каждом не только типовых но и своих обработчиков данных

(0) Рынок есть, например: https://1с-ижтиси.рф/автоматизированное_обновление_измененных_конфигураций_1с

(11) Хмм.. Как раз-таки вроде как умею, но пытаюсь упростить))
Я описал случай, когда конфа поставщика в порядке. Если ее отрезали для облегчения - да, это проблемка, и процесс максимально приближается к развернутому варианту из 6 пунктов.
Но насколько вообще часто так делают на практике? Может мне так повезло по жизни, но видел я такое в единичных случаях
Если же она в порядке, то она очень помогает нам по жизни, и на этапе обьединения можно сохранить не только добавленные объекты, но и большинство доработок вообще (меньшинство, которое надо будет потом добавить вручную, к сожалению тоже будет..)

(11) А если конфу поддержки действительно отрезали, то никто же нам не мешает прикрутить ее в копии перед началом процесса?

А ветка согласована? Это все-таки коммерческое предложение.

(0) А очень сильно упиленную УПП до ERP обновите, чтобы вся упилленная функциональность сохранилась?
Или есть попроще: вхлам перекоцанную УТ10 до УТ11 поднять?

(13) (14) Ты предлагаешь в (9) использовать первый "скачок" специально же вставил цитирование в (11)

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

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

(16) Начать следовало с "обновить ТиС до УТ11"

"А очень сильно упиленную УПП до ERP обновите, чтобы вся упилленная функциональность сохранилась?"
Примерно год работы проектной команды человек так 10-15.

(18) нету ТиС. Но специально для (0) могу предложить УТ10.2 от 2008 года внедрения

Месяц работы по настройке правил на КД2 и небольшой доработке конечной конфы, правда в УНФ 3 перенос был. Но думаю в УТ11 того же порядка сроки.

(20) И даже ПУБ нету до КА/ЕРП?

(19) ты забыл ещё к этому число указать с 6-7 цифрами.
так я и сам могу, но за год не справимся.

(21) Это ты разогнался про месяц
Там может куча обменов/интеграций на ftp и текстовых файликах своего формата
Все от конкретной ситуации и функционала же зависит

(0) ИжТиСи, залогиньтесь.

(22) у меня вот ощущения такие, что с 7.7 на 8.0/8.1 как-то проще перескакивали что ли. То ли давно уже было, то ли я моложе был...

(23) ну по ценнику я не совсем в теме, но думаю да, миллионов 10+ проект стоит.

(26) Да было сильно проще
Ценники были ниже
И требуемого функционала меньше

(24) ну я про свой проект написал, там месяц заняло, ЭДО штатный заюзали, интеграций других не было. То есть наименьший срок взял.

(17) дык я к тому, что процесс сравнения при обновлении (а не обычном объединении!) УЖЕ трехсторонний:
Основная конфа со старой конфой поставщика
Старая конфа поставщика с новой конфой поставщика
Основная конфа с новой конфой поставщика
Это дает нам много интересных возможностей)) но конфа поставщика для этого таки нужна, да.. (Без нее возни сильно больше)

Реально сейчас намного проще перейти с 77 или с SAP на современную типовую на УФ
Чем с конфы ОФ на УФ

Конфы на ОФ уже сильно замудрены и заточены обычно
На типовое оно не ложится легко
Где легко там уже давно сами перешли

(30) Старую конфу поставщика с новой поставщика нет смысла сравнивать
Тупо по шагам поднимаем релизы и все, соблюдая последовательность и выполняя обработчики

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

(33) фу ты, коллега, моё почтение, не узнал сразу, богатым будешь!
Мы ж тут сначала наезжаем, а потом на лицо (е-мейл в данном случае) смотрим.

(34) Взаимное))

(34) Богатым, говоришь? :) Твои слова бы да Богу в уши )))
... эпическая битва, говорите? ;)))

Если рассуждать логически.
У некой компании есть измененная типовая. Не важно какая, но сильно измененная. Вот прям напрочь.
Раз измененная. Значит ее кто-то менял, не сама же она.
Значит есть в штате разработчики и даже несколько.
Отсюда логически вытекает вопрос, а ты этой компании нафига?
Там сами разработчики прекрасно справятся.

(0) Как правильно обновить доработанную базу, в которой в справочнике есть типовые и добавленные/измененные предопределенные элементы, а в новой редакции тоже есть изменения?

(38) Правильно дорабатывать :)

(38) а шо предопределенные элементы опять в моде? Вроде в одно время все так наелись ими, что ушли константы и регистры настроек.

(39), (40), вот я пытаюсь понять, знает ли ТС хоть чего-нить или лезет свиным рылом в калашный ряд
А вы-то нахрена вперед него наперебой радостно захрюкали? :))

(40) Открой виды информации, свойства объектов, да хоть тот же план счетов
И да, какая разница, что план счетов — это не справочник, это что, что-то принципиально меняет?

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

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

(37) был такой опыт году этак в 2012м - ИТотдел, где было 4-5 1сников на фултайме, выдавал по мере необходимости мне на обновление свою БП КОРП 2.0 (потом этот отдел сменился на других людей и связь с ними потерялась)
Видимо самим было лень))
В этой БПшке было тысяч 9 меток в коде от разных авторов + примерно столько же непомеченных изменений.
Обновлял не на копии, а вслепую (на пустой либо демке)

(44) хехе
там все хитрей с уидами
особенно при двух хранах и ручном переносе между ними доработок

(44) Понятно
Судя по ответу, лучше не суйся в обновления, наломаешь дров

Первым делом надо выяснить какие доработки нафик не нужны уже

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

(45)
Без данных ты хрень порол или постоянно спрашивал/выяснял а вот это вам надо?

(48)+ Если предопределенного элемента нет нигде в данных в базе или в коде (нужном) - вероятно его можно смело сносить
Если нужен - заново добавится из типовой

(49) ни разу не жаловались на результат, не просили ничего допилить, а в следующем квартале обращались снова...))

(51) Ошибка выжившего

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

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

(53) А как иначе работать командой над одной конфой на больших и сложных проектах?
В одиночку можно только небольшую конфу

Так что вместо поиска подработки - просто поменяй работу
И будет тебе полная загрузка, при большем доходе

Сам делаю сейчас такое

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

После винды сервера и экосистемы на линухе - будто писали студенты на досуге. Такая фигня

Даже один рабочий стол линуха это винда 3.1
Баля, я уже устал. Придумайте нормальные вещи. Они даже шрифт не придумали.

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

Предел есть

Я даже название ему придумал - идеологическая разработка. Берёшь задачу целиком и делаешь.

В смысле я сейчас прямо этим занимаюсь. Даже такие контракты на обновление. Фишки прикольные. Решаем по доработке. Если косметически - берём, если слишком доработано - думаем.

самый просто ответ - идите в жопу
нафига возиться с этим. там ещё аннотация ИзменениеИКонтроль
это сколько времени потратить надо
лишь только оценка стоит много часов и денег
так что - нет

Не хотел говорить, на да ладно. Работал над сильно изменённой конфигурацией ERP УХ. В корпоративных стандартах всё написано гладок - толь аннотация После. И что? Да основную конфигурацию переписали сто раз. Тим лид - огонь, классный программист, такое по запросам выдаёт, но он не палит разработку десятков кодеров. И, честно, хочется сказать - сожгите это

Я хотел остаться на обновление и отрефакторить всё, но у меня контракт закончился, хотя все надеялись.  Проза жизни

Это самая тупая работа. Я сейчас обновляю ERP, и ещё одну надо.

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

(55) да и речь не о подработке (сейчас-то не проблема найти всякую подработку), а о том, что "выделить в пробирке" любимую работу, и отчистить ее от всегда ей сопутствующей чуть менее любимой))
Ну если конечно такое реально))

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

(68) замысел - как раз-таки обновлять, почти не вникая в доработки))
Если к возможностям стандартного восьмерочного обновления добавить немного интуиции - многое возможно в этом направлении))
Но основную засаду вы обозначили верно - каждый, кто дорабатывал конфу, может ее и обновить, более того, при прочих равных из-за знания нюансов он сделает это проще. И описанный выше мной опыт "чернового" обновления на аутсорсе - это возможно случайная блажь+нехватка времени конкретных людей... (.. Либо нет, и такая потребность существует, вот это я и хотел своим постом выяснить)))
Наверное проще продавать обновление монструозных конф "под ключ" (ИжТиСи же так делает?) но тогда сразу ряд аспектов:
-милые особенности хранилища (вон опытные коллеги выше упоминали про спецэффекты с предопределенными, которые видимо не суждено огрести, обновляя без хранилища)
-необходимость производить "финальный этап" обновления на проде не когда хочется, а в "технологическое окно", причем хитроумно допиливать обработчики, если в это окно не вмещаешься...
-качественное тестирование (и вот тут уже желательно знать назначение доработок)
-возможно какое-то время придется побыть типа "линией поддержки" пользователей после обновления...
При таком раскладе я представляю "снежный ком" трудозатрат, который сообразительностью и задором конкретного физлица не покроешь, тут уже всяко нужна команда...

(69) такая работа по определению разовая, в одноразовой пробирке то есть

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

(73) ну а для вас это как, нормальный уровень развития?
шиномонтаж какой-то...
Он там в (55) про постоянную работу, где адаптация, изучение, не побоюсь слова "погружение" и остальное.
Впрочем, и такой аутсорс наверно должно быть, просто это не всегда хорошо заканчивается.
И если в конторе есть более-менее адекватный разработчик, вас туда просто не пустят(
Хотя всякое бывает..

(72) такая работа разовая в другом смысле: "один раз пригласили - больше не пригласят".

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

(0) как можно любить обновлять чужие нетиповые базы ?...  Это прям извращение какое-то ?...

Когда что-то в хлам переписанное очень давно не обновлялось, а потом вдруг принято решение, что надо - то скорее всего вариантов 2.
1. Забить болт на доработки, в новом релизе сами бизнес-процессы уже другие.
2. Если никак не хочется менять процессы - наверняка им нахрен не нужно ничего обновлять.

(26) Я как-то давно переводил холдинг с наглухо переписанной бухи 7.7 (там еще по-моему даже старый план счетов светился и она годами вообще не обновлялась, а только прилеплялась возможность сдавать отчетность) на 8 (вроде еще 8.2 тогда). Сейчас уже здоровья не хватило бы за такое браться.

(77) ну вот я именно это извращение и люблю)))

(0) "Может ли существовать вообще среди нашего сообщества "рынок" таких услуг?"

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

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

+(80) Это что касается допиленных типовых. А в нетиповых - разве что БСП обновлять.

(79) как вариант написать про свои извращения в резюме и отправить на сайты по поиску работы / фриланса

(82) А "извращенец" писать в проф. навыки или хобби? :))

"А в нетиповых - разве что БСП обновлять." Полно самописок и без БСП.

(84) И тогда что там автор собирается обновлять? Самописка на то и самописка, что её сами написали под нужды предприятия.

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

(86) Т.е., по сути, надо доработать эту самописку. А тот, кто это делал ранее, по каким-то причинам сбежал.
Имхо, это не называется обновлением.

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

(88) Да понятно, что бывают разные случаи. Просто автор спросил про рынок таких услуг - я примерно предположил категорию клиентов, которым может такое потребоваться.

+(89) Ну и опять же: обновление и перевод самописки на типовую 1С - это совершенно разные вещи.
Про перевод нетиповых на типовые автор не писал.

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

(0) >> Может ли существовать вообще среди нашего сообщества "рынок" таких услуг?

Рынок такой безусловно существует.
Его проблема в том, что он крайне узок и очень специфичен.
Большинство заказчиков - счастливых обладателей сильно перепиленных типовых либо уже имеют в штате собственных специалистов, кто этим занимается, либо решаются на большие обновления крайне редко (зная о неминуемо последующих после обновления проблемах).
Короче. Это высокорискованный рынок одноразовых работ.
Одноразовых потому, что даже успешно выполненные обновления каждый клиент будет стараться повторять как можно реже и оттягивать этот прекрасный момент на как можно более поздний срок.
Высокорисковый он потому, что, во-первых, всегда есть риск провалить обновление. В моей практике было такое, когда вроде как протестированное обновление после перевода в продуктив не смогло корректна заработать с каким-то торговым оборудованием. В результате было принято решение о срочном откате, с последующим разбором косяков, поиском виноватых, взаимных обвинениях и претензиях. А во-вторых, обновление таких конфигураций подразумевает наличие некоего гарантийного срока на исправление косяков, которые непременно вылезут после обновления. И эти самые косяки "после вашего обновления" - отдельная очень проблемная история. Опыт показывает, что иногда чуть ли не до 70% доходит доля косяков, которые на самом деле никак с обновлением не связаны (оно на самом деле и раньше работало некорректно или даже не работало вовсе) или связаны косвенно. Например, когда поменялась в обновлении какая-то логика и то, что раньше приложение позволяло делать, теперь делать стало нельзя или надо делать как-то по-другому, а у заказчика под закрытую ныне особенность значительная часть работы была заложена. Вопрос - кто, что и за чей счёт должен дорабатывать в таких случаях, всегда предмет потенциального конфликта.
Если предусмотреть все минусы и потенциальные риски, то цена таких услуг становится просто конской. Может даже иногда достигать величин сопоставимых со стоимостью повторного внедрения всех доработок с нуля на новой версии типового решения.
Строить бизнес-модель на таких клиентах я бы не стал.
Но имеет право на существование примерно такое же как фрилансеры на проектах внедрения. По сути одно большое обновление сильно переписанного типового решения - это и есть отдельный проект. Со всеми стадиями - обследование, оценка, планирование, реализация, тестирование, внедрение с пусконаладкой (перевод в продуктив), постпроектное гарантийное обслуживание и/или поддержка. Продавать как готовый продукт под ключ с ценой, включающей все озвученные этапы (кроме поддержки, которая либо почасовая, либо включает только ограниченное количество часов).

(92) "По сути одно большое обновление сильно переписанного типового решения - это и есть отдельный проект." Пару лет назад попалась оценка рынка подобных услуг, цены начинались: для конфигураций типа БП - от 12 млн.; типа УТ 10/11/УНФ от 25 млн.; Для КА и УПП - от 30 млн. Жирно, но в одиночку не потянуть, нужна крепкая команда.

(92) неистово плюсую))
Все по делу, от и до по полочкам, и в большинстве совпадает с моим представлением о сабже))

По сути это надо просто устраиваться фиксиком на сопровождение старых легаси. С обещание обновления и т.д. Тогда все вопросы в стиле "кто и что делает и на какие деньги" - отпадут. Делаете Вы и на свою ЗП :-) Сколько времени на каждой конкретной фирме будет видно по ходу дела.

На удалёнке естественно, чтобы искать варианты "по всея Руси"...

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

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

(97) Да вроде в таких случаях дают доступ к тестовой базе без этих самых "маленьких секретиках".

(98) чтоб сделать нормальную тестовую базу нужен фикси, а привлекать со стороны при наличии своего фикси - смысл?

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

(93) >> типа БП - от 12 млн.; типа УТ 10/11/УНФ от 25 млн.; Для КА и УПП - от 30 млн

Судя по суммам, речь тут идёт об обновлениях на новый релиз (БП с 2 на 3, УТ с 10 на 11, УПП на ERP), а не в рамках одного релиза. Переход на новый релиз зачастую означает повторное внедрение (перевнедрение).
Я же говорю о более лайтовом варианте обновления внутри одного релиза. Когда типовую типовую конфигурацию за годы перепилили вдоль и поперёк (зачастую разные люди, в разное время, руководствуясь разными принципами и методиками доработок и по задачам от заказчика, которые тоже меняли свои требования, иногда на противоречащие друг другу и здравому смыслу). Но всё же обновление требуется в рамках одного релиза, где вендор (1С) не вносил кардинальных глобальных и революционных методологических переделок.
В таком варианте цены должны быть, на мой взгляд, пониже.
Если я верно понимаю, автор ветки интересуется рынком, где цена одного такого обновления будет примерно в стоимости работы одного хорошего специалиста за месяц или немного выше. Примерно от 200 до 500 К₽, максимум - до миллиона. За всё, под ключ. И с соответствующими сроками - до одного месяца, начиная от предварительного обследования с оценкой, до перевода в продуктив (сроки гарантийной поддержки - отдельно). Цены и условия могут варьироваться в зависимости от наличия и качества документации ко всем доработкам, специалистов со стороны заказчика (есть ли они вообще), которые могут доработки откомментировать или даже взять на себя часть работы до доработке самих доработок под новый релиз (такое часто тоже нужно), и кучи других обстоятельств.

>> Жирно, но в одиночку не потянуть, нужна крепкая команда.

Задачи есть и на одного и на команду.
Всё зависит от сроков, объёмов и уровня требований.
Всё как обычно. Из трёх пунктов - быстро/качественно/дёшево - выбрать можно одновременно только два. Хочешь быстро и качественно - готовься раскошелиться на команду. Готов потерпеть - можно справиться силами одного специалиста, но придётся подождать.

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

(102) Получается, что ты и так всё знаешь и более или менее представляешь.
В чём тогда смысл этой ветки? Поиск критики или поддержки?
Но все риски и проблемы тут и так на поверхности.
Для тебя основные риски - это одноразовость.
Ещё не завершив один заказ, уже надо искать следующий. Чтобы не иметь разрывов. И при этом нет возможности вести работы параллельно. То есть заказчики (если их много) будут стоять в очереди. А не все готовы ждать.
И нет никакого стабильного дохода, который бы покрывал разрывы в случае отказов запланированных клиентов и невозможности быстро найти новых.
У франча все такие риски диверсифицированы. Пока тормозит или буксует проектно-внедренческий отдел (как было в кризис, когда куча проектов были заморожены, а не начавшиеся отменены), какие-то деньги приносят отделы сопровождения, поддержки и продажи.
У фрилансера, специализирующегося на обсуждаемого рода обновлениях, нет подушки безопасности в виде постоянных клиентов на поддержке, на которых можно какую-то копейку в голодное время заработать.

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

(102) // Естественно, я имел в виду обновления методом обновления)), без переносов в новую версию/редакцию

Ну вот переписанная конфа. Например УПП. Ясно же что её и дальше будут переписывать. Так зачем же обновлять ? Ведь ясно же что не удастся вот так вот взять и без проблем перенести работу скажем 10 лет и нескольких поколений программистов. А завтра её опять надо будет обновлять трахаясь полностью по новой.

Просто ставят рядом типовую конфу, делают обмены и решают проблемы регл. отчётов.

Вопрос встаёт когда они хотят перейти на другую конфу, типа ЕРП. Но это полноценное внедрение. Но нормальные люди будут работать с франчи. Ибо там команда с компетенциями, которые редко бывают у одного человека.

(104)
"Но на досуге хочется время от времени играться с монструозными конфигурациями"

своими деньгами готов ответь за "кривое" обновление?

после таких поиграться

(104) что может быть интересного в обновлении ?
Смотреть как база уходит в реструктуризацию на n сутки ?
Караулить ночью ? Играть в игру « обновись без реструктуризации»? :)

(92) Есть среди заказчиков любители не брать программиста в штат. Наймут "под проект" какого-то Васю, он им наколбасит в конфигурации доработок, а потом выставляет счет на поддержку всего этого. Жадный заказчик само собой возмущенно отказывается, ведь проект сделан - разработка и внедрение произведены, всё само должно работать. И начинает искать одинесника на аутсорс за копейки, чтобы поддерживал нетиповое решение со словами "да там всё уже сделано до вас". Бежать надо от таких сверкая пятками)

(108) Сейчас у таких звездный час наступает. Теперь они могут поглядывать на других свысока и говорить: "ну, и кто был прав?"

(109) У кого "таких"? У заказчиков, Вась или "одинесников за копейки"?

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

(110) У заказчиков.
То, о чем вы говорите, сегодня уже не так.

(111) С чего вдруг? Что поменялось то? Наоборот, сложнее всё стало.

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

(109) почему именно у таких заказчиков сейчас звездный час?

(114) Сейчас он начнёт лить в уши опять какую-нибудь лабуду про искусственного идиота, который выполняет всю работу по одной просьбе.

(112) (114) (115) КМК, mmg про то, что, в целом, конфа навроде УПП и ERP может годами деградировать без программиста (как и с оными). Конечно, если есть админ, делающий бэкапы, и несколько продвинутых пользователей, делающих регл. процедуры закрытия. Да даже подобные базы ТиС видел как-то, уже давно никто им не занимаются, а люди как-то работают. В одной даже видел интеграцию с брокером сообщений (заброшенный уже обмен).

(116) "КМК, mmg про то..." - Нет, Миша теперь адепт ИИ, всегда только про это.

(107) лично мне нравится окно с галочками))

(117) он хочет отдать УПП и ЕРП на поддержку ИИ? А самому сидеть при этой ИИ этаким Карабасом, директором погорелого театра, и стричь бабосики?

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

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

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

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

(123) Как это будет выглядеть ? Как-то так :

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

Ну и зачем им это надо ?

(124) Не надо будет, только если кто-то предложит альтернативу "за копейки - все проблемы" (и справится с этим на ура)
А так честность обычно окупается..

(124) А когда они обратятся к нему поправить ошибки за доп.денежку, окажется, что он взял другой заказ и обновляет конфу кому-то ещё и надо подождать месяцок.

"Ну и зачем им это надо ?" - +100500.

(126) ... Особенности рынка...))
Тут главный вопрос - есть ли более надежная альтернатива? (у данного клиента, в данный момент времени)

(127) Если альтернативы нет прямо сейчас - можно её ещё поискать. Не обязательно хвататься за первое встречное предложение.

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