Недавно была встреча с клиентом, который хотел MES. Думал, будет как обычно - грустно. Скажу "нет никакого MES на 1С", клиент расстроится, подумает что я вру и перестанет отвечать (обычно так и бывает). Но не тут-то было.

Начинаю говорить "вы знаете, MES на 1С...", а клиент "знаю, знаю, не работает, нет его". И рассказал, как посетил несколько предприятий (прям съездил!) в поисках работающего MES. Не нашёл. Судя по изменению тона беседы, моё уныние про MES послужило чем-то вроде пропуска доверия. Начал бы я "конечно, сделаем вам MES!" - попросили бы прислать КП, и на этом всё.

А тут вроде дальше продвинулись. Рассказал, что MES можно только сделать, своими руками. Собственно, MES-то я делал несколько раз, но обычно проблема - показать/доказать, это всегда доработка под конкретного клиента. Показывать решения без разрешения мне не позволит ни совесть, ни NDA, а спрашивать разрешения мне лень. Раньше пробовал - толку особо нет, начинается "нуууууу у нас-то всё сложнее/проще/по-другому, это не то, покажите предприятие нашего профиля".

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

Так что, может и появится в этом мире MES от 1С.

Расскажу о сопровождении, наверное в нескольких постах. Там, как мне кажется, интересна не столько текущая модель, сколько история появления и развития. Речь про сопровождении, которое у меня в отделе 101 делается.

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

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

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

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

Ну а дальше - как повезёт. В прямом смысле, как лотерея.

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

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

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

Наверное, пока хватит 😒
Продолжение следует.

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

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

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

В качестве "Системы" вполне сгодился чат в телеге, куда я добавил всех менеджеров и программистов. На "разработку системы" ушла 1 минута. Написал короткие правила и в тот же день началось распределение задач. Назвал чат, разумеется, "Свободная касса". Менеджеров было человек 10-15 (точно не помню, дело было в 2019 году), программистов - человек 6-8 вместе со мной.

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

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

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

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

Один отзыв особенно запомнился. Во-первых, он на одном из сайтов Сбера. Во-вторых, весь проект занял два трудодня 😁.
У клиента была старая УТ 11, он хотел купить Бит.Финанс, но сомневался, что на старой конфигурации будет работать. Соответственно, не мог решить, покупать или нет. Релизов для такой старой УТ 11 не было - во времена выхода релиза клиента ещё не было сборки Бит.Финанса для УТ 11, её то ли ещё делали, то ли собирались.

Менеджеры не смогли убедить клиента, что всё будет хорошо, только счёт оплати. Я предложил так: клиент даёт свою конфигурацию, мы на свой страх и риск, за свой счёт, впихиваем туда Бит.Финанс, устраняем неизбежные ошибки совместимости, а если всё получится - клиент покупает коробку и оплачивает работы по объединению конфигураций.

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

Это был первый трудодень проекта.

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

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

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

Итого, на всю помощь клиенту с его вопросами, мелкими настройками, отладкой, проверкой и т.д. ушло ещё 9 часов работы программиста. Это был второй трудодень проекта.

Собственно, всё 🤦‍♀️

P.S. А теперь сравните мой рассказ с текстом отзыва 🙈
https://sber.pro/digital/publication/konfeti-i-finansi-kak-produktovii-distribyutor-tsifroviziroval-byudzhetnie-protsessi/

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

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

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

Если хотите со мной бесплатно поговорить - добро пожаловать. Пишите на nmivan@mail.ru, договоримся о времени и дате.
В письме в двух словах черкните, о чём хотите поговорить и кто вы по должности.
Обещаю не вносить вашу почту ни в какую базу.

Второе бесплатное решение - старый добрый "Рабочий стол", в виде расширения. Можете брать и пользоваться.

Понадобится помощь программистов - пишите, мои люди по нему экзамен сдают.

Почитать про "Рабочий стол" можно здесь - https://infostart.ru/marketplace/957530/

Видео:
1. https://vkvideo.ru/video-208482299_456239487
2. https://vkvideo.ru/video-208482299_456239491
3. https://vkvideo.ru/video-208482299_456239497?list=ln-BKsiW5Xfu9tyPmSipy

Так, у меня тут небольшой левел ап - с мая в моём отделе проектов 101 появились менеджеры по продажам.

Я в Бите 5 лет работаю, всё это время в периметре были только программисты, иногда - аналитики. Продавцы всегда были из других отделов, мы с ними сотрудничали, как-то вместе пытались организовывать работу с клиентом. Не всегда удачно, увы.
Ну, оно и понятно. Каждый отдел - это чьё-то племя, со своими целями, стратегией, процессами и правилами. Кроссфункциональное взаимодействие - всегда риск.

Так что теперь у нас полный цикл по 1С - от продажи ПО/лицензий до экспертных работ. Всё в одном месте.
Захотите купить коробочку - обращайтесь.

Ещё учебный центр открыли, но он пока только внутри Бита работает, так что просто порадуйтесь за нас 😁

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

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

Но я не про это сейчас. Проблема в том, что спец - новый. Он не знает, как подключиться. Где база рабочая, а где - копия. Можно ли в этой копии трогать документы, или там другой спец что-то моделирует. Есть ли хранилище конфигурации. Кто и как обновляет рабочую базу. Не говоря уж про тысячи особенностей в системе клиента, известных только... Никому не известных, потому что спецы регулярно меняются.

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

Что делать?

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

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

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

Согласитесь, просто. Потому и заработало быстро.

Продолжим про сопровождение. Итак, появилась у нас команда, закреплённая за клиентом. Понятно, что каждый программист закреплён не за одним клиентом, а за несколькими, состоит в нескольких командах сопровождения. Хотя, в основном команды почти постоянные.

Получалась конфигурация клиент+менеджер+команда программистов. Менеджеров звали в эту команду - отказались. Звали и в плане процессов (встроить в общую работу, распределить обязанности и ответственность), и чисто по-человечески - сидеть вместе, работать вместе, обсуждать все задачи и проблемы клиента и т.д. Не интересно менеджерам с программистами, как правило. Ну и ладно.

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

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

Итак, проблема понятна. Как её решить?

Перед глазами были два успешных примера: руководитель проекта и начальник ИТ-отдела.

Руководитель проекта - это человек, который делал клиенту переход, например, с УПП на ЕРП. Или просто внедрил ту систему, с которой клиент работает. Пока шёл проект, РП всё про клиента узнал, разумеется, со всеми познакомился, все доработки и особенности знает. Короче, он - ровно тот, кто нужен! Но, упс... Он руководитель проектов. Закончился один проект - он идёт на другой.

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

Начальник ИТ-отдела - я им работал несколько лет, в смысле сидя у клиента в офисе заводоуправлении, поэтому работа знакомая. Это когда ты знаешь всё, что происходило, происходит и будет происходить в 1С. И на вопросы ответить, и доработки сделаешь, и починишь всё что угодно, и помнишь кто из программистов что делал, и кому что лучше поручить, и т.д. Но, у нас франч, и никаких начальников ИТ-отдела у нас нет.

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

Круто же было бы? У клиента задача - он обращается напрямую к программисту, который всё про него знает. И он всегда доступен, программист этот (мы ж его начальником ИТ-отдела на аутсорсинге назвали). Доступен для поговорить, на вопрос ответить, задачу взять в работу. И отдать делать кому-то из команды сопровождения. И проконтролировать исполнение, помочь, подсказать (программист ведь знает меньше нашего внешнего начальника ИТ).

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

Короче, назвал я их продюсерами. Ну а чё.

Старый, добрый, неповторимый отчёт-легенда "Структура затрат" для УПП, который тайно рекомендовали партнёрам даже сотрудники 1С.

Детальное описание - https://infostart.ru/1c/reports/93020/

Видео
https://vk.com/video-208482299_456239481
https://youtu.be/xfxYiaQrG8g

Надо как-нибудь устроить конференцию по теме "Стратегический ИТ-тупик: "ещё рано" против "уже поздно"".
"Ещё рано" - клиенты, которые вступают на путь, ведущий в стратегический тупик.
"Уже поздно" - клиенты, которые уже в тупике, осознают его и пытаются выбраться.

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

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

А друг другу наверняка поверят.

Или, как вариант - не конференцию проводить, а кейсы собирать. Да, это, наверное, проще и эффективнее.
Кейсы ошибочных решений и стратегических тупиков. Ищут же клиенты кейсы и, прошу прощения, референсы перед покупкой ПО или внедрением. Просят "покажите мне схожее по профилю и масштабу предприятие, где вы внедряли".

А теперь смогут сказать "покажите мне схожее по профилю и масштабу предприятие, которое пошло тем же путём и зашло в тупик". Хотя, наверное, вряд ли кто-то захочет рассказывать о своих ошибках... Это же немножко вроде как позорище. Собственнику, директору, может, и нормально об ошибках рассказывать, а вот ИТ-директору или программисту - ни-ни. Репутация, резюме. Вдруг потом придёшь на собеседование к тем, перед кем эмоциональный стриптиз устраивал.

Как думаете, интересно ли такие "кейсы наоборот", антикейсы читать?

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

А на этих программистах, допустим, всё по 1С завязано - и поддержка, и развитие. Ладно развитие, его можно в случае чего приостановить. А сопровождение? А если система не типовая, и критичность высокая? У знакомого ровно такая ситуация.

Он думал про документирование, я предложил диверсификацию в двух вариантах.

Первый - добавить 1-2 стажёров, пусть сидят и учатся, занимаясь в основном сопровождением. И недорого, и найти проще, и старые немного меньше нос задирать будут.

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

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

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


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

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

15 программистов в доступе по цене одного. Так, что ли, получается 😁

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

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

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

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

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

Продолжим про сопровождение, которое мы тут выстраивали. Предыдущий пост тут.

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

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

Например, мы работаем до 18:00, а клиент - до 21:00, или круглосуточно. Не часто, но случается какая-нибудь фигня, требующая внимания программиста. Ещё разница во времени играет роль - география клиентов и их филиалов может быть очень обширной.

Всем клиентам, опять же, рано или поздно нужно рабочую базу обновлять - релиз накатывать или изменения вносить. Если это ЗУП на 2 пользователей - ладно, можно днём. А если ERP или УПП на 100+ человек? Выгнать днём можно только в критической ситуации.

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

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

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

Сна и выходных нет в случае, когда клиент замкнут на одного человека. А у нас команда из нескольких человек, и всегда есть кому подключиться и порешать.

Видео вам снял.
Про то, как выбирать отраслевые решения 1С.

https://youtu.be/5fyRks28SUI

Кто из Челябинска, тут мероприятие 1С организовала, про ЕРП, 11 сентября.
Бесплатно для руководящего состава предприятий.
Если кто желает быть приглашённым 😁 - черкните в личку @Ivan_Belokamentsev, повелю моим любимым менеджерам с вами связаться и пригласить.

https://1c.ru/news/info.jsp?id=31941

Видео вам снял - https://youtu.be/sJS-BsZvw-U

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

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

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

Приятно.

Видео вам снял, вторую серию про экономию на проектах перехода.
https://youtu.be/57KBrDUi-wc

Снимал для программистов, но вам, наверное, тоже может быть полезно. Тут больше про подходы к решению проблемы.

Видео вам снял - https://youtu.be/XvdMYRcyKlE