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

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

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

С этим надо научиться жить. Если использовать старые методы, давление, критику и т.д. - любую агрессию - зумеры будут уходить.
Причём, молча, ничего не объясняя ни в процессе, ни после.

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

https://t.me/spim1c

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

Заказчик работает с сетями, а где сети - там какой-нибудь хитровыдуманный электронный документооборот.
В основе - просто модуль/обработка, написанная какой-нибудь известной компанией, но обязательно - доработанная на месте под требования сети.

И вроде бы - что может случиться, если мы переходим с УПП на ЕРП, и для обеих конфигураций есть версия модуля ЭДО?
Код модуля - открыт, доработки под сеть - известны. Что может пойти не так?

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

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

В декабре ребята честно что-то дорабатывали, под конец года отдали результат, и все торжественно ушли Новый Год встречать.
В январе, на каникулах, мы запускаем ЕРП, ну и... Доработанные ребятами модули, конечно, не работают.
Ну ладно, думаем, ничего страшного = серьёзные штуки никогда с первого раза не работают. Сейчас напишем ребятам, они помогут.

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

Через пару дней начала работать тех.поддержка, но вот незадача... Они ничем не могли помочь с нашим доработанным модулем.
Потому что помочь может только разработчик, который с их стороны модули допиливал. А он - на законных каникулах до 12 января. И связаться с ним нельзя никак и ни за какие деньги. А документации он никакой не передал, тех.поддержке ничего не объяснил, поэтому помочь они ничем не могут.

Тут у заказчика вторая волна отгрузок в сеть - ну, что поделать... Пришлось опять из УПП выгружать.

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

https://t.me/another1C

Попалась на глаза статья (https://infostart.ru/1c/articles/2636935/#5. В чем плюсы использования интервальных регистров) на Инфостарте, про интервальные регистры сведений в ЗУПе.
Вспомнил, что недавно использовал эту ЗУПовскую идею для совершенно другой задачи - интервального хранения цен.
Но цель использования интервальных РС - та же, оптимизация скорости выполнения запросов и удобства их написания.

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

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

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

Обновление интервального регистра делается рег.заданием - это быстро, где-то одна минута на всю номенклатуру.
Но всю номенклатуру обновлять надо редко. Я сделал регистр с очередью обновления, туда попадают номенклатуры из поступлений, которые записываются. Провели поступление с сотней номенклатур - сотня записей в очереди появилась. Рег.задание зашло и актуализировано интервальный регистр с ценами по сотне позиций.

Хорошая штука эти интервальные регистры. Рекомендую.

https://t.me/ywhite

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

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

Понятно, что недорогие переходы - не единственный формат проекта, и не всегда лучший.
Но спрос на него есть, вот мы его и придумали.

На данный момент мы сделали 6 таких проектов:

1. Два перехода УПП - ЕРП;

2. Два перехода УПП - КА2;

3. Один переход УНФ - КА2;

4. Один переход УПП - Аренда (там БП внутри).

Ещё два проекта в процессе, их рано включать в статистику.

Средний чек проекта - 1274 часа.

https://t.me/another1C

P.S. Думаю, надо статью написать, предметную - как такие проекты делать, чтобы экономить на переходе.

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

Перевёл потому, что один потенциальный клиент попросил - хотел посмотреть, что за штука это управление задачами Flowcon.

На момент публикации оно там сыровато всё, конечно, но пользоваться уже можно. Постепенно стабилизирую релиз.

Детальное описание всего Flowcon - https://infostart.ru/marketplace/976048/
В данном расширении - часть "Управление задачами". Ещё включил "Управление компетенциями", но пока не тестировал - сделаю это позже.

А вот на что точно стоит обратить внимание - на часть про регулярный менеджмент. Это штука, которой я сам пользуюсь каждый день. Что это, зачем, и как - описано в отдельной статье - https://infostart.ru/pm/998824/

Расширение можно скачать в тг-канале: t.me/another1C

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

В обновлениях больших и нагруженных баз есть такая проблема - пролезть в "окно" (ещё его называют технологическим окном).
Это время, на которое можно остановить базу 1С для обновления, без существенных потерь для бизнеса.
В нашем случае окно было размером в 40 часов.

Вообще, это не так уж и мало, но... Надо было обновить на 4 редакции - с УТ 11.4.14 до 11.5.22.
Кто помнит обновление на 11.5.8, в котором появились распределение запасов и объекты расчетов, понимают - там время обновления измерялось, скорее сутками.
Обращаю внимание - надо было обновить все 4 редакции в одно окно 40 часов.
Так сильно дешевле, чем накатывать по одному релизу и запускать пользователей. Причём, дешевле в разных всех смыслах - не надо адаптировать конфигурацию под каждый релиз (можно это сделать один раз в конце), не надо мучить людей (заставляя переживать 4 обновления, 4 смены некоторых интерфейсов и механизмов).

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

Короче, надо было сжать 300 часов времени обновления в 40, т.е. в 7-8 раз.

Ну и чё... Получилось 😁

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

Как-нибудь соберусь, напишу статью - там есть, что рассказать.

https://t.me/another1C

Снял видео про один из способов применения расширения "Рабочий стол" - дашборды рисовать. Лично для меня, как пользователя, это главный способ применения рабочих столов. Эдакий дешманский BI, с очень быстрой настройкой и перенастройкой.

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

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

А пока вот:

https://vkvideo.ru/video-208482299_456239491
https://youtu.be/1rln84eMBwc

Расширение можно скачать тут - https://t.me/another1C/48

Выложил новую версию расширения "Рабочий стол" - подрихтовал интерфейс. Он был старый, т.к. создавался под толстого клиента - см. картинку. Теперь выглядит почти как типовой 1Сный интерфейс.

Также снял видео-знакомство с простейшими функциями рабочего стола (для тех, кто раньше не видел это расширение)
https://youtu.be/-SMc-Q2EOiw
https://vkvideo.ru/video-208482299_456239487

Скачать решение можно в тг-канале https://t.me/another1C

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

Тут две ветки получается - обновление внутри одной редакции и переход между редакциями.
Если говорить про семейство ЕРП - т.е. ЕРП, ЕРПУХ, КА2 и УТ11 - то переход между редакциями там случается раз в год.

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

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

Ну а обновления с переходом между редакциями обходятся в 5-10 раз дороже, если основная часть доработок выполнена через расширения.
Разумеется, речь о большом количестве доработок. А то вдруг в системе 5 доработок, из которых 3 - в расширениях :)

Между редакциями сильно больше изменений архитектуры типового решения. Появляются и исчезают регистры, документы, меняется структура существующих, меняется версия БСП, прыгают и скачут общие модули и названия процедур, меняется режим совместимости.

Ну а все типовые процедуры, изменённые в расширении с инструкциями Вместо и ИзменениеИКонтроль, приходится почти вручную адаптировать под новый релиз. Буквально пересобирать заново - брать новый текст типовой процедуры и вручную помещать туда старые изменения.

Собственно, поэтому и дороже.

https://t.me/another1C

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

Обработка подсчитывает:

1. Количество модулей и строк в них;

2. Количество модулей с изменениями;

3. Количество процедур и функций, разбитое по категориям - новые, изменённые с инструкциями ИзменениеИКонтроль, Вместо, Перед/После;

4. Количество строк в процедурах каждой категории;

5. Для ИзменениеИКонтроль подсчитывает количество изменений и количество строк в этих изменениях.

Как пользоваться:

1. Выгружаем расширение в файлы (можно несколько расширений выгрузить и скопировать в одну папку);

2. Запускаем обработку, указываем папку с выгруженным расширением;

3. Жмём "Посчитать".

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

Но понять, сколько изменений содержится в расширении, крайне затруднительно. В платформе 1С инструменты оценки изменённости есть только для конфигураций.

Обработка тут - https://t.me/another1C/148

Пришлось недавно серьёзно повозиться со сложным обновлением, давно такое интересное не попадалось.

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

В семействе ЕРП регулярно случаются длинные обработчики обновления. Например, при переходе с 17 на 22 в регистр сведений "Реестр документов" добавили измерение с уникальным идентификатором, которое обработчик и заполняет - для всех записей. В моём случае записей было 9 млн, и выполнение обработчика занимало больше суток.

Если нужно сделать 1 шаг обновления, то не страшно - в течение этих суток пользователи могут работать. Но, во-первых, бывают обработчики, которые "отключают" отдельные виды документов или целые контуры учёта, вроде взаиморасчётов или резервов. Во-вторых, мне надо в одно технологическое окно обновить на 4 версии, поэтому ждать было нельзя.

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

И случилось чудо - обработчик выполнился часа за 4-5 (вместо 24+). Попробовал с другими обработчиками, которые столь же изолированные - результат по ускорению тот же.

Я думал, проблема в типовом распараллеливании, которое как-то не очень эффективно распределяет задания между потоками. Пошёл смотреть чужой опыт на партнёрке, нашёл относительно свежую тему (https://partners.v8.1c.ru/forum/t/2259464/m/2259464), где автор нашёл больше меня - дело и в распараллеливании, и в записи статистики. Правда, гарантированного и надёжного решения там найти не получилось - ребята из 1С сказали, что могут быть последствия, если просто отключить статистику. Но обещали что-нибудь придумать со скоростью обновлений.

А пока можете пользоваться тем же способом, что и я, коли возникнет схожая проблема.

https://t.me/ywhite

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

В современных, вроде ЕРП, УМП вполне себе работает. У одного клиента с 2021 г. всё обеспечение продаж и многопередельного производства на УМП держится.

Скачать расширение можно в тг-канале - https://t.me/another1C/130

Описание решения - vk.com/@ivan.belokamentsev-universalnyi-mehanizm-planirovaniya-ump

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

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

Итак, видео по автозадачам:

https://vk.com/video-208482299_456239480, оно же https://youtu.be/4Z6Z3tZTVKM

Видео по структуре затрат:

https://vk.com/video-208482299_456239481, оно же https://youtu.be/4Z6Z3tZTVKM

Сами решения (эти и остальные) можно скачать в тг-канале: https://t.me/another1C

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

Само решение можно скачать в моём тг-канале https://t.me/another1C

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

Итак, видео.

Первое - совсем простые примеры: https://vk.com/video-208482299_456239478

Второе - чутка посложнее, но всё равно просто: https://vk.com/video-208482299_456239479

В обоих видео показаны примеры использования без навыков программирования.

Выложил своё старое решение по планированию в 1С, можете брать и пользоваться. Проблематику планирования излагал тут, но, думаю, она и без меня понятна всем, кто сталкивался с реальными задачами планирования на практике.

Вообще, выложенное решение - для старых конфигураций, вроде УПП, УТ 10.3 и т.д. Но если не лень - можете и в ЕРП вставлять. У меня есть расширение, причешу и тоже выложу.

Детальное описание решения есть тут - https://infostart.ru/marketplace/690271/
Там же можете стоимость заценить :)

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

Внимание! Внедрить эту штуку можно только с участием программиста! Там надо запросы писать и отчёты делать.
Это несложно, просто предупреждаю, чтобы у вас ожиданий неоправданных не было.

Берите и пользуйтесь. Файл лежит в тг-канале - https://t.me/another1C/92

Как быстро обновить доработанную 1С УПП на много релизов

Один коллега тут обратился с вопросом – как обновить сильно доработанную 1С УПП на 100 релизов? Я говорю – а чего такого? Есть же стандартные технологии для решения таких задач. Оказалось, он их не знает.

Если и вы не знаете, я кратко расскажу.

Раньше все программисты так делали, потому что по-другому было просто нереально. Все вокруг внедряли УПП, в ходе проекта мало кто решался обновляться, релизы копились, и потом надо было шваркнуть сразу с десяток, а то и два. Вы, возможно, удивитесь, но бюджеты таких обновлений доходили до 500 часов (сейчас это 1.5-2.5 млн. руб.).

Итак, принципиально подхода два – «Потом доделаем» и «Прыжок».

«Потом доделаем» основан на одном простом факте: выполняя промежуточные обновления, нет смысла тащить изменения в модулях, формах и ролях.

На первом шаге запускаем обновление, ставим флаг «Показывать только дважды изменённые», и смело заменяем все модули (общие, менеджера, объекта), формы и роли типовыми. Добавленные объекты метаданных в этом режиме мы даже не увидим, с ними всё будет хорошо. Изменения в структуре данных (добавленные реквизиты типовых объектов, изменения типов) – аккуратно тащим дальше.

Любой, кто обновлял доработанные конфигурации, знает: 80-99 % времени работы программиста уходит на сравнение модулей и форм, до рези в глазах. В подходе «Потом доделаем» мы от этого избавлены.

Дальше накатываем остальные релизы, до последнего. Они идут быстро и красиво, потому что все модули, формы и роли мы заменили типовыми.

Ну а шваркнув последний релиз, поднимаем исходную конфигурацию и аккуратно переносим, через сравнение/объединение, все доработки. Это будет весьма муторно, т.к. переносить придётся почти вручную.

Нужно открыть два конфигуратора. В первом будет сравнение/объединение обновленной конфигурации и исходной. Во втором – сравнение/объединение исходной конфигурации поставщика и исходной основной конфигурации. Где-то изменения вкатятся легко, где-то – придётся покумекать.

Главное – покумекать придётся один раз, а не 100.

Подход «Прыжок» - несколько рискованный. Нужно хорошо понимать, что делаете.

Принцип здесь такой: мы делаем обновление на один шаг, сразу на последний релиз. Главное, что для этого надо сделать – вручную собрать все обработчики обновления и сделать заплатки там, где УПП скажет «ой, я с этого релиза на вон тот обновляться не умею». Ну и там, где она хранит версии подсистем. И, наверное, там, где в УПП проникла такая прелесть, как БСП.

Этот подход – для интеллектуалов и гиков. Пользоваться в реальности не рекомендую, лучше «Потом доделаем».

Про особенности обновления 1С ERP снял видео, текста нет:

https://youtu.be/7F02eshCKh4
https://vk.com/video-208482299_456239471

https://t.me/another1C

Я, кстати, в канале выкладываю свои старые разработки на 1С, можно забирать бесплатно. Идёте в закреплённое сообщение, там будет список, краткое описание, ссылки на полное описание и файлы для скачивания приложены.

Сейчас там доступны расширение "Проверка данных" (полное описание), расширение "Рабочий стол" (полное описание) и отчёт "Структура затрат" (всегда был здесь).

Сколько будет стоить проект перехода с УПП на ERP, если работать без ТЗ, аналитиков, дорожной карты, проектных технологий, графиков и прочих привычных атрибутов? Мне тоже было интересно, поэтому года полтора назад взялись делать такие проекты.

Мысль о том, что переходы можно делать быстрее и дешевле, пришла из прошлого опыта.

Во-первых, внедрения УПП в нулевых обходились сильно дешевле. Хотя все видели 1С впервые (внедренцы, зачастую, тоже :)), ТЗ не писали, аналитиков не было. Да, через задницу многое получалось, но бюджет в 1-2 тысячи часов был вполне средним чеком.

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

Так вот, 20-летний опыт проектов/внедрений/сопровождений говорил, что проекты можно делать за приемлемые деньги. Не было только подтверждения именно для ERP - в нулевых её не существовало, а в должности ИТ-директора только купить коробку успел.

Полтора года назад начали первые проекты делать по этой технологии. Первый завершился в апреле 24 года, обошёлся заказчику в 1930 часов. Можно, получается. Система в эксплуатации уже 11 месяцев.

Сейчас делаем ещё несколько таких проектов.

https://t.me/another1C

Частенько 1С тормозит из-за поднастроенных пользователями динамических списков.

Бывает, сразу всё понятно из описания – «пытаемся открыть список документов, а он висит" минут 5, прежде чем открыться». А бывает, пользователь говорит "документ записывается 5 минут". На самом деле, пользователь нажал в документе "Провести и закрыть", документ провёлся и закрылся быстро, но началось тормознутое обновление списка документов - те самые 5 минут. Но раз все 5 минут на экране подвисшая форма документа, пользователь и думает, что проведение тормозит.

В первый раз, столкнувшись с проблемой, провозился часа два - думал, дело в доработках или РЛС (ограничении прав доступа на уровне записей. При желании, можно доработками довести динамический список до ужасного состояния. Но доработок не было.

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

Удалил типовую форму списка и создал через расширение новую. Проблема сразу ушла. Стало понятно, что дело в настройках. Вернул типовую форму, сбросил настройки списк, и всё заколосилось.

С тех пор этот метод - сбросить настройки дин.списка - прочно вошёл в обиход. Если говорят «список» и «тормозит» - сначала сбрасываем настройки.

А для пользователей - магия.

https://t.me/another1C

Был недавно на встрече с клиентом - коллеги из другого офиса Первого Бита позвали поучаствовать, т.к. у клиента УПП (моя вечная любовь). Причем, клиент не хотел никуда с УПП переходить - ему всё нравилось, хоть оно и не работало, как задумано 😁.

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

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

Так вот, я говорю директору: зря вы так. Вот сказали, что уникальные - и сразу х2, а то и х3 к сумме проекта. А спросите потом, чё так дорого - скажут "так вы ж уникальные, вам шаблонные решения не подойдут". И слова назад не возьмёте, вы ж директор.

Не уверен, что он меня понял. Поэтому вам вот написал.

https://t.me/another1C