🔮 Битва против «титанов» или как работают «заклинания» системной диагностики
Иногда работа с маркировкой напоминает расследование, где приходится шаг за шагом раздвигать туман и вызывать на поверхность скрытые механизмы.
И последнее время такие кейсы встречаются всё чаще.
Недавно столкнулся с интересной ситуацией, связанной с товарами, для которых в маркировке есть особые правила учёта. Там важна каждая деталь: как описана карточка в Национальном каталоге, какие параметры передаются при продаже и что учитывается при приёмке.
🎭 Суть проблемы
Система вела себя как настоящий трикстер:
— Настраиваешь карточку правильно → продавать можно, но принимать упаковками — нельзя.
— Настраиваешь неправильно → принимать можно, но продавать корректно — нельзя.
То есть как ни поверни — где-то обязательно «рассыпается» логика.
🔍 Где искать проблемы?
Начал выстраивать гипотезы:
1. Неверное описание карточек у Поставщика
2. Ошибка в правилах маркировки на стороне ЧЗ
3. Разные версии конфигураций 1С между Поставщиком и Клиентом
4. Ошибки в ЭДО при передаче данных
И вот тут началась наша любимая «челночная дипломатия»:
ЧЗ, Поставщик, службы 1С, операторы ЭДО — каждый уверял, что «у нас всё хорошо».
Параллельно я пошёл копать глубже — в логи, форумы, чаты, старые обсуждения.
Перерыл реально тонны информации.
И наткнулся на других «счастливчиков», у которых ломалось всё точно так же.
✨ Переломный инсайт
Сложив разрозненные подсказки, ответы и наблюдения,
я решил проверить типовой запрос, который 1С отправляет в ЧЗ.
И там пазл неожиданно сложился — логика была нарушена именно в нём.
🏆 Итог — маленькая победа над большим механизмом
Смоделировав примеры и собрав все артефакты доказательств, я отправил развёрнутый разбор в техподдержку 1С.
И в этот раз — произошло то, чего я не ожидал:
1С официально признали глобальную ошибку.
Скажу честно: приятно, когда удаётся не просто «починить», а высветить проблему, которая долго пряталась в тени.
Это и есть магия: превращать хаос в ясность.
Если у тебя в маркировке тоже что-то «ведёт себя странно», или кажется, что в системе спрятан невидимый сбой — пиши.
Найдём, раскопаем, превратим в порядок ✨
Иногда работа с маркировкой напоминает расследование, где приходится шаг за шагом раздвигать туман и вызывать на поверхность скрытые механизмы.
И последнее время такие кейсы встречаются всё чаще.
Недавно столкнулся с интересной ситуацией, связанной с товарами, для которых в маркировке есть особые правила учёта. Там важна каждая деталь: как описана карточка в Национальном каталоге, какие параметры передаются при продаже и что учитывается при приёмке.
🎭 Суть проблемы
Система вела себя как настоящий трикстер:
— Настраиваешь карточку правильно → продавать можно, но принимать упаковками — нельзя.
— Настраиваешь неправильно → принимать можно, но продавать корректно — нельзя.
То есть как ни поверни — где-то обязательно «рассыпается» логика.
🔍 Где искать проблемы?
Начал выстраивать гипотезы:
1. Неверное описание карточек у Поставщика
2. Ошибка в правилах маркировки на стороне ЧЗ
3. Разные версии конфигураций 1С между Поставщиком и Клиентом
4. Ошибки в ЭДО при передаче данных
И вот тут началась наша любимая «челночная дипломатия»:
ЧЗ, Поставщик, службы 1С, операторы ЭДО — каждый уверял, что «у нас всё хорошо».
Параллельно я пошёл копать глубже — в логи, форумы, чаты, старые обсуждения.
Перерыл реально тонны информации.
И наткнулся на других «счастливчиков», у которых ломалось всё точно так же.
✨ Переломный инсайт
Сложив разрозненные подсказки, ответы и наблюдения,
я решил проверить типовой запрос, который 1С отправляет в ЧЗ.
И там пазл неожиданно сложился — логика была нарушена именно в нём.
🏆 Итог — маленькая победа над большим механизмом
Смоделировав примеры и собрав все артефакты доказательств, я отправил развёрнутый разбор в техподдержку 1С.
И в этот раз — произошло то, чего я не ожидал:
1С официально признали глобальную ошибку.
Скажу честно: приятно, когда удаётся не просто «починить», а высветить проблему, которая долго пряталась в тени.
Это и есть магия: превращать хаос в ясность.
Если у тебя в маркировке тоже что-то «ведёт себя странно», или кажется, что в системе спрятан невидимый сбой — пиши.
Найдём, раскопаем, превратим в порядок ✨
🔥2
Как настроить синхронизацию между УТ/КА2/ERP и БП
Когда данные в УТ/КА2/ERP живут своей жизнью, а бухгалтерия — своей, неизбежно появляются ошибки, задержки и лишняя работа. 🫠
Поэтому записал новый ролик, в котором объясняю, как с помощью синхронизации связать системы, упростить процессы и избежать двойного ввода — показываю настройку от начала и до проверки обменов.
Метод также работает и для синхронизации других Баз - УНФ, вместо ERP, ЗУП, вместо БП.
Если вы всё равно столкнулись со сложностями обмена - пишите, разберем ваш случай и поможем 🤓
Смотреть на RuTube
Смотреть на YouTube
Когда данные в УТ/КА2/ERP живут своей жизнью, а бухгалтерия — своей, неизбежно появляются ошибки, задержки и лишняя работа. 🫠
Поэтому записал новый ролик, в котором объясняю, как с помощью синхронизации связать системы, упростить процессы и избежать двойного ввода — показываю настройку от начала и до проверки обменов.
Метод также работает и для синхронизации других Баз - УНФ, вместо ERP, ЗУП, вместо БП.
Если вы всё равно столкнулись со сложностями обмена - пишите, разберем ваш случай и поможем 🤓
Смотреть на RuTube
Смотреть на YouTube
RUTUBE
Как настроить синхронизацию между 1С ERP/КА2/УТ и БП
Когда данные в УТ/КА2/ERP живут своей жизнью, а бухгалтерия — своей, неизбежно появляются ошибки, задержки и лишняя работа.
В ролике объясняю, как с помощью синхронизации связать системы, упростить процессы и избежать двойного ввода — показываю настройку…
В ролике объясняю, как с помощью синхронизации связать системы, упростить процессы и избежать двойного ввода — показываю настройку…
🔥2👍1
🕰️ «Хочу, чтобы было как раньше»
Почему при внедрении 1С всё идёт не так, как планировали
На этой неделе вспомнил одну тему, с которой сталкивался уже не раз 🙂
Компания долго работала «по-старому»:
в другой программе или в давней 1С 7.7.
И вот — долгожданное решение переходить на 1С 8.
Мы проводим предпроектный анализ:
изучаем процессы, ищем функциональные разрывы,
моделируем будущее решение — как всё должно работать.
🧑🏫 Обучение проведено, пользователи говорят «понятно».
День запуска.
И тут начинается новый сезон сериала:
«Я хочу, как раньше!» 😅
Причём:
«как раньше» = не всегда правильно
«как раньше» = не всегда можно
«как раньше» = не всегда было согласовано
У меня на одном проекте всё дошло до того, что пришлось
несколько дней жить у клиента, разбирая вопросы в режиме «нон-стоп».
Потому что люди столкнулись не с кнопками —
а с изменением привычной реальности.
🤔 Так что же делать?
Самое важное — привлекать реальных пользователей на этапе анализа и моделирования:
кладовщиков — в блок склада,
бухгалтеров — в блок учёта,
продажников — в CRM и документы реализации.
Потому что они лучше всех знают:
📌 как оно работает «на самом деле»
📌 где реальный процесс отличается от регламента
📌 какие мелочи решают комфорт работы
А каждый такой нюанс — это потенциальный функциональный разрыв,
который может превратиться в аврал на запуске.
🎯 Вывод
Успешный запуск 1С — это не только про настройки и доработки.
Это про работу с ожиданиями, вовлечение людей
и постепенное, грамотное изменение “как раньше” на “как лучше”.
А у вас на проектах звучала фраза «верните, как было»? 😄
Если планируете переход на 1С 8 — расскажу, как пройти этап изменений без потрясений 👇
Почему при внедрении 1С всё идёт не так, как планировали
На этой неделе вспомнил одну тему, с которой сталкивался уже не раз 🙂
Компания долго работала «по-старому»:
в другой программе или в давней 1С 7.7.
И вот — долгожданное решение переходить на 1С 8.
Мы проводим предпроектный анализ:
изучаем процессы, ищем функциональные разрывы,
моделируем будущее решение — как всё должно работать.
🧑🏫 Обучение проведено, пользователи говорят «понятно».
День запуска.
И тут начинается новый сезон сериала:
«Я хочу, как раньше!» 😅
Причём:
«как раньше» = не всегда правильно
«как раньше» = не всегда можно
«как раньше» = не всегда было согласовано
У меня на одном проекте всё дошло до того, что пришлось
несколько дней жить у клиента, разбирая вопросы в режиме «нон-стоп».
Потому что люди столкнулись не с кнопками —
а с изменением привычной реальности.
🤔 Так что же делать?
Самое важное — привлекать реальных пользователей на этапе анализа и моделирования:
кладовщиков — в блок склада,
бухгалтеров — в блок учёта,
продажников — в CRM и документы реализации.
Потому что они лучше всех знают:
📌 как оно работает «на самом деле»
📌 где реальный процесс отличается от регламента
📌 какие мелочи решают комфорт работы
А каждый такой нюанс — это потенциальный функциональный разрыв,
который может превратиться в аврал на запуске.
🎯 Вывод
Успешный запуск 1С — это не только про настройки и доработки.
Это про работу с ожиданиями, вовлечение людей
и постепенное, грамотное изменение “как раньше” на “как лучше”.
А у вас на проектах звучала фраза «верните, как было»? 😄
Если планируете переход на 1С 8 — расскажу, как пройти этап изменений без потрясений 👇
👍1🔥1
Как зарегистрировать Новый Личный Кабинет 1С и Программный продукт
Иногда сталкиваюсь с ситуациями, как на самом старте работы с 1С возникают вопросы:
куда заходить, что регистрировать и в каком порядке. 😵💫
В видео показываю, как создать личный кабинет 1С и зарегистрировать программный продукт — пошагово и без лишней путаницы 🤓
Смотреть на RuTube
Смотреть на YouTube
Иногда сталкиваюсь с ситуациями, как на самом старте работы с 1С возникают вопросы:
куда заходить, что регистрировать и в каком порядке. 😵💫
В видео показываю, как создать личный кабинет 1С и зарегистрировать программный продукт — пошагово и без лишней путаницы 🤓
Смотреть на RuTube
Смотреть на YouTube
RUTUBE
Как зарегистрировать Новый Личный Кабинет 1С и Программный продукт
Иногда сталкиваюсь с ситуациями, как на самом старте работы с 1С возникают вопросы:
куда заходить, что регистрировать и в каком порядке.
В видео показываю, как создать личный кабинет 1С и зарегистрировать программный продукт — пошагово и без лишней путаницы…
куда заходить, что регистрировать и в каком порядке.
В видео показываю, как создать личный кабинет 1С и зарегистрировать программный продукт — пошагово и без лишней путаницы…
👍2
Аутсорс или в штат — в чём на самом деле разница?
Недавно в разговоре с клиентами, пусть и в полушутку, прозвучало предложение:
Я ответил честно — мне комфортнее быть рядом, но в формате аутсорса.
На что получил вполне понятный аргумент:
И здесь я их понимаю.
Но за годы работы у меня сложилась немного другая картина.
Что я вижу на практике
1️⃣ Всё упирается не в формат, а в человека.
Профессионал — даст результат и в штате, и на аутсорсе.
Вопрос не «где он работает», а как он думает и за что берёт ответственность.
2️⃣ Сильный аутсорс растёт быстрее.
Работая с разными компаниями, процессами и ошибками,
специалист быстрее накапливает насмотренность и опыт.
И часто приносит компании больше ценности, чем человек, замкнутый внутри одной среды.
3️⃣ В аутсорсе вы платите за результат, а не за присутствие.
При нормальной постановке задач и взаимодействии
оплата идёт за решённые вопросы, а не за «отсидку часов».
4️⃣ Сильные специалисты редко идут в штат.
Не потому что «плохо»,
а потому что их рыночная ценность и доход в аутсорсе обычно выше.
При этом важно честно сказать:
плохой аутсорс — это действительно боль.
Но плохой специалист в штате — боль не меньшая, просто растянутая во времени.
Как выбрать хорошего специалиста — независимо от формата
Вот на что я бы смотрел в первую очередь:
1⃣Какие вопросы он задаёт
Обращайте внимание:
- связывает ли он бизнес-процессы между собой;
- пытается ли понять логику бизнеса, а не только ИТ;
- говорит ли «невозможно» или предлагает варианты;
- интересуется ли задачей или только бюджетом.
2⃣Как он рассказывает про свой опыт
Не столько важно «сколько лет», сколько:
- какие задачи решал;
- какие проекты запускал;
- сталкивался ли с похожими процессами;
- как он принимал решения в сложных ситуациях.
3⃣Дайте возможность показать работу
Одной встречи часто недостаточно.
Хорошие варианты:
- небольшой этап предпроектного обследования и моделирования,
где вы получаете модель «как должно работать»;
- или старт с небанальной задачи, по результату которой видно мышление, глубину и ответственность.
И уже после этого становится понятно —
хочется ли идти дальше вместе или нет.
Формат работы — это инструмент.
А результат всегда делают люди и то, как с ними выстроено взаимодействие.
Если интересно — могу отдельно рассказать, как выглядит хороший ППО и какие «красные флаги» я чаще всего вижу на старте проектов. 🙂
Недавно в разговоре с клиентами, пусть и в полушутку, прозвучало предложение:
«А давай ты к нам в штат?»
Я ответил честно — мне комфортнее быть рядом, но в формате аутсорса.
На что получил вполне понятный аргумент:
«Мы наработались с аутсорсерами — спросить потом не с кого, а качество часто оставляет вопросы».
И здесь я их понимаю.
Но за годы работы у меня сложилась немного другая картина.
Что я вижу на практике
1️⃣ Всё упирается не в формат, а в человека.
Профессионал — даст результат и в штате, и на аутсорсе.
Вопрос не «где он работает», а как он думает и за что берёт ответственность.
2️⃣ Сильный аутсорс растёт быстрее.
Работая с разными компаниями, процессами и ошибками,
специалист быстрее накапливает насмотренность и опыт.
И часто приносит компании больше ценности, чем человек, замкнутый внутри одной среды.
3️⃣ В аутсорсе вы платите за результат, а не за присутствие.
При нормальной постановке задач и взаимодействии
оплата идёт за решённые вопросы, а не за «отсидку часов».
4️⃣ Сильные специалисты редко идут в штат.
Не потому что «плохо»,
а потому что их рыночная ценность и доход в аутсорсе обычно выше.
При этом важно честно сказать:
плохой аутсорс — это действительно боль.
Но плохой специалист в штате — боль не меньшая, просто растянутая во времени.
Как выбрать хорошего специалиста — независимо от формата
Вот на что я бы смотрел в первую очередь:
1⃣Какие вопросы он задаёт
Обращайте внимание:
- связывает ли он бизнес-процессы между собой;
- пытается ли понять логику бизнеса, а не только ИТ;
- говорит ли «невозможно» или предлагает варианты;
- интересуется ли задачей или только бюджетом.
2⃣Как он рассказывает про свой опыт
Не столько важно «сколько лет», сколько:
- какие задачи решал;
- какие проекты запускал;
- сталкивался ли с похожими процессами;
- как он принимал решения в сложных ситуациях.
3⃣Дайте возможность показать работу
Одной встречи часто недостаточно.
Хорошие варианты:
- небольшой этап предпроектного обследования и моделирования,
где вы получаете модель «как должно работать»;
- или старт с небанальной задачи, по результату которой видно мышление, глубину и ответственность.
И уже после этого становится понятно —
хочется ли идти дальше вместе или нет.
Формат работы — это инструмент.
А результат всегда делают люди и то, как с ними выстроено взаимодействие.
Если интересно — могу отдельно рассказать, как выглядит хороший ППО и какие «красные флаги» я чаще всего вижу на старте проектов. 🙂
🔥5
Ciao Venti Venticinque
Друзья и коллеги, этот пост я хотел посвятить не работе, а простым и тёплым поздравлениям 🎄
Но вместе с этим на днях появились интересные размышления.
Случайно услышал песню Ciao 2020 из «Вечернего Урганта» — и мгновенно накрыло тем временем.
Кажется, что тогда мы жили как будто проще и беззаботнее.
Да, сложности были и тогда, но спустя пять лет они вспоминаются как мелочи.
Иногда даже ловишь себя на мысли: «верните мне мой 2020» 🫠
Но если остановиться и посмотреть честно — за эти пять лет произошло очень многое.
Были яркие моменты, были непростые испытания, были падения и подъемы.
И, проходя через всё это, я точно стал сильнее и научился вставать после сложных периодов.
Поэтому сегодня, глядя на текущую точку, я уже не скажу «верните мой 2020».
Я готов двигаться дальше — и мне особенно приятно делать это вместе с вами.
Этот год был хорошим.
А в следующем я желаю всем нам достойно проходить новые вызовы,
чаще фокусироваться на позитиве
и, что особенно важно, научиться создавать его для себя самим.
Так что — Ciao Venti Venticinque!
Поздравляю вас всех с наступающим Новым годом 🎆✨
Друзья и коллеги, этот пост я хотел посвятить не работе, а простым и тёплым поздравлениям 🎄
Но вместе с этим на днях появились интересные размышления.
Случайно услышал песню Ciao 2020 из «Вечернего Урганта» — и мгновенно накрыло тем временем.
Кажется, что тогда мы жили как будто проще и беззаботнее.
Да, сложности были и тогда, но спустя пять лет они вспоминаются как мелочи.
Иногда даже ловишь себя на мысли: «верните мне мой 2020» 🫠
Но если остановиться и посмотреть честно — за эти пять лет произошло очень многое.
Были яркие моменты, были непростые испытания, были падения и подъемы.
И, проходя через всё это, я точно стал сильнее и научился вставать после сложных периодов.
Поэтому сегодня, глядя на текущую точку, я уже не скажу «верните мой 2020».
Я готов двигаться дальше — и мне особенно приятно делать это вместе с вами.
Этот год был хорошим.
А в следующем я желаю всем нам достойно проходить новые вызовы,
чаще фокусироваться на позитиве
и, что особенно важно, научиться создавать его для себя самим.
Так что — Ciao Venti Venticinque!
Поздравляю вас всех с наступающим Новым годом 🎆✨
🎄6❤2🔥2
Управление изменениями на разных проектах
За праздники получилось много работы и одновременного участия в разных проектах — где-то я вёл их напрямую, а где-то подключался как участник или консультант 🤓
Было много задач:
- обновления баз разной степени сложности,
- проекты с переездом,
- системы с доработками, где требовалось повышенное внимание и контроль.
Честно — устал.
Но опыт получился очень показательный 🫠
В первый рабочий день после праздников все выходят на работу,
а я сижу с 9 утра наготове — в ожидании, где и что может пойти не так.
И картина оказалась разной:
- в каких-то проектах — тишина и спокойствие,
- в каких-то — вопросы, аврал и срочные разборы 😁
Не как оценка, а скорее как наблюдение:
там, где изменения были заранее хорошо структурированы и контроль был выстроен по этапам, запуск проходил заметно спокойнее и управляемее.
Это ещё раз подтвердило мысль, что правильно расставленные контрольные точки и фокус внимания сильно снижают риски.
Что помогло пройти этот период относительно спокойно
1️⃣ Заранее составленный подробный план
Практически с первых дней праздников я сел и разложил по полочкам:
- что именно нужно сделать по каждому проекту,
- какие задачи зависят только от меня, а где участвуют другие,
- разбил крупные этапы на подзадачи,
- оценил время на каждую из них,
- отдельно заложил время на отдых и личные дела,
- распределил задачи по дням и часовым блокам.
2️⃣ Контрольные точки по каждому проекту
Для себя фиксировал:
- что именно нужно проверить,
- в какой момент,
- кого предупредить заранее,
- где возможны риски и как их отловить.
3️⃣ Движение по плану с поправкой на реальность
Конечно, человеческий фактор никуда не делся — где-то были сдвиги, где-то корректировки.
Но за счёт общего плана они не становились критичными.
В таком формате — с планом почти на две недели вперёд — я, пожалуй, работал впервые.
И результат меня действительно порадовал 🙂
Что кажется особенно важным на финальном этапе
После любого большого блока изменений — обновлений, переезда или запуска системы — очень помогает рефлексия:
- что сработало хорошо,
- где можно было сделать лучше,
- какие решения стоит сохранить как шаблон на будущее.
Фиксация этих выводов позволяет в следующий раз не изобретать всё заново и не упускать важные детали.
Именно так проекты со временем перестают быть хаотичными и становятся управляемыми.
С каждым таким запуском всё больше убеждаюсь: управление изменениями — это отдельный навык, который часто недооценивают.
За праздники получилось много работы и одновременного участия в разных проектах — где-то я вёл их напрямую, а где-то подключался как участник или консультант 🤓
Было много задач:
- обновления баз разной степени сложности,
- проекты с переездом,
- системы с доработками, где требовалось повышенное внимание и контроль.
Честно — устал.
Но опыт получился очень показательный 🫠
В первый рабочий день после праздников все выходят на работу,
а я сижу с 9 утра наготове — в ожидании, где и что может пойти не так.
И картина оказалась разной:
- в каких-то проектах — тишина и спокойствие,
- в каких-то — вопросы, аврал и срочные разборы 😁
Не как оценка, а скорее как наблюдение:
там, где изменения были заранее хорошо структурированы и контроль был выстроен по этапам, запуск проходил заметно спокойнее и управляемее.
Это ещё раз подтвердило мысль, что правильно расставленные контрольные точки и фокус внимания сильно снижают риски.
Что помогло пройти этот период относительно спокойно
1️⃣ Заранее составленный подробный план
Практически с первых дней праздников я сел и разложил по полочкам:
- что именно нужно сделать по каждому проекту,
- какие задачи зависят только от меня, а где участвуют другие,
- разбил крупные этапы на подзадачи,
- оценил время на каждую из них,
- отдельно заложил время на отдых и личные дела,
- распределил задачи по дням и часовым блокам.
2️⃣ Контрольные точки по каждому проекту
Для себя фиксировал:
- что именно нужно проверить,
- в какой момент,
- кого предупредить заранее,
- где возможны риски и как их отловить.
3️⃣ Движение по плану с поправкой на реальность
Конечно, человеческий фактор никуда не делся — где-то были сдвиги, где-то корректировки.
Но за счёт общего плана они не становились критичными.
В таком формате — с планом почти на две недели вперёд — я, пожалуй, работал впервые.
И результат меня действительно порадовал 🙂
Что кажется особенно важным на финальном этапе
После любого большого блока изменений — обновлений, переезда или запуска системы — очень помогает рефлексия:
- что сработало хорошо,
- где можно было сделать лучше,
- какие решения стоит сохранить как шаблон на будущее.
Фиксация этих выводов позволяет в следующий раз не изобретать всё заново и не упускать важные детали.
Именно так проекты со временем перестают быть хаотичными и становятся управляемыми.
С каждым таким запуском всё больше убеждаюсь: управление изменениями — это отдельный навык, который часто недооценивают.
🔥2🥱1
Аудит и моделирование: зачем это нужно и что важно в подходе
Аудит и моделирование — по сути, то, с чего начинается любой проект.🚀
Особенно проект внедрения новой системы.
Именно на этом этапе мы пытаемся честно ответить на ключевые вопросы:
— что есть сейчас
— что хочется получить в итоге
— какие процессы нужно изменить, зачем и каким образом
Это критически важная часть проекта, в рамках которой:
— определяется конфигурация 1С
— описываются бизнес-процессы
— выявляются проблемные зоны в бизнесе
— выстраивается ИТ-архитектура
(как настраиваются справочники, какой документооборот планируется, какие автоматизации и интеграции нужны и как они должны работать)
Обычно всё начинается с серии встреч: мы разбираем процессы бизнеса, после чего переходим к моделированию в 1С и демонстрации Заказчику.
На демонстрациях становится видно:
— что закрывается типовым функционалом
— где возникают функциональные разрывы
— что можно решить организационно или изменением процессов
— а где без доработок не обойтись, если хотим упростить и ускорить работу пользователей
Сложность, с которой я стал сталкиваться всё чаще 💩
— На ряде последних проектов (особенно при переходе из других систем — МойСклад, 1С 7 и т.п.) стало заметно, что:
— руководству и пользователям сложно сразу воспринять большой объём новой информации
— логика системы кажется «чужой»:
раньше было по-другому, почему товары и цены теперь в разных местах, что это за документы и зачем они нужны
— сами процессы внутри компании часто не формализованы и работают по принципу «как привыкли»
В такой ситуации классический подход «давайте сразу покажем всё в базе» начинает давать сбои.
Как я попробовал изменить подход 🤓
Я не считаю этот подход каким-то ноу-хау — но на практике используют его далеко не все.
После аудита я стал договариваться с Клиентами о следующем:
моделирование в 1С идёт параллельно с описанием и визуализацией бизнес-процессов, а на старте фокус смещается именно на схемы процессов.
Да, на первый взгляд этот путь может показаться более длинным, чем «просто показать всё сразу в базе».
Но у него есть важные плюсы.
Что это даёт на этапе моделирования
1. Первые встречи посвящены согласованию схем бизнес-процессов
— мы их отлаживаем, делаем прозрачными и понятными всем участникам
2. Далее демонстрация в 1С идёт через призму этих схем
Клиенту проще понять:
— зачем нужен конкретный документ
— на каком этапе он возникает
— кто за него отвечает
— как он связан с другими блоками
При необходимости мы постоянно возвращаемся к схеме
3. Корректно сформированные схемы:
— ускоряют и упрощают настройку системы
— минимизируют переделки моделирования
— помогают не упустить важные настройки
(справочники, параметры объектов, связи между блоками),
особенно когда всё это нужно воспроизвести уже в рабочей базе
Плюсы, которые особенно проявляются на запуске
Когда мы переходим к вводу рабочей базы в эксплуатацию:
1. Каждый сотрудник получает схему своей работы
— это закрывает значительную часть вопросов ещё до старта
2. Существенно снижается аврал на запуске
— и по пользователям, и по руководству
потому что большая часть неопределённости снимается на ранних этапах
Если коротко:
чем больше ясности мы создаём до системы, тем спокойнее система начинает работать. 🙂
Аудит и моделирование — по сути, то, с чего начинается любой проект.🚀
Особенно проект внедрения новой системы.
Именно на этом этапе мы пытаемся честно ответить на ключевые вопросы:
— что есть сейчас
— что хочется получить в итоге
— какие процессы нужно изменить, зачем и каким образом
Это критически важная часть проекта, в рамках которой:
— определяется конфигурация 1С
— описываются бизнес-процессы
— выявляются проблемные зоны в бизнесе
— выстраивается ИТ-архитектура
(как настраиваются справочники, какой документооборот планируется, какие автоматизации и интеграции нужны и как они должны работать)
Обычно всё начинается с серии встреч: мы разбираем процессы бизнеса, после чего переходим к моделированию в 1С и демонстрации Заказчику.
На демонстрациях становится видно:
— что закрывается типовым функционалом
— где возникают функциональные разрывы
— что можно решить организационно или изменением процессов
— а где без доработок не обойтись, если хотим упростить и ускорить работу пользователей
Сложность, с которой я стал сталкиваться всё чаще 💩
— На ряде последних проектов (особенно при переходе из других систем — МойСклад, 1С 7 и т.п.) стало заметно, что:
— руководству и пользователям сложно сразу воспринять большой объём новой информации
— логика системы кажется «чужой»:
раньше было по-другому, почему товары и цены теперь в разных местах, что это за документы и зачем они нужны
— сами процессы внутри компании часто не формализованы и работают по принципу «как привыкли»
В такой ситуации классический подход «давайте сразу покажем всё в базе» начинает давать сбои.
Как я попробовал изменить подход 🤓
Я не считаю этот подход каким-то ноу-хау — но на практике используют его далеко не все.
После аудита я стал договариваться с Клиентами о следующем:
моделирование в 1С идёт параллельно с описанием и визуализацией бизнес-процессов, а на старте фокус смещается именно на схемы процессов.
Да, на первый взгляд этот путь может показаться более длинным, чем «просто показать всё сразу в базе».
Но у него есть важные плюсы.
Что это даёт на этапе моделирования
1. Первые встречи посвящены согласованию схем бизнес-процессов
— мы их отлаживаем, делаем прозрачными и понятными всем участникам
2. Далее демонстрация в 1С идёт через призму этих схем
Клиенту проще понять:
— зачем нужен конкретный документ
— на каком этапе он возникает
— кто за него отвечает
— как он связан с другими блоками
При необходимости мы постоянно возвращаемся к схеме
3. Корректно сформированные схемы:
— ускоряют и упрощают настройку системы
— минимизируют переделки моделирования
— помогают не упустить важные настройки
(справочники, параметры объектов, связи между блоками),
особенно когда всё это нужно воспроизвести уже в рабочей базе
Плюсы, которые особенно проявляются на запуске
Когда мы переходим к вводу рабочей базы в эксплуатацию:
1. Каждый сотрудник получает схему своей работы
— это закрывает значительную часть вопросов ещё до старта
2. Существенно снижается аврал на запуске
— и по пользователям, и по руководству
потому что большая часть неопределённости снимается на ранних этапах
Если коротко:
чем больше ясности мы создаём до системы, тем спокойнее система начинает работать. 🙂
🔥2👍1
Как выгрузить документы из 1С ERP/КА2/УТ в 1С БП
Продолжаю разбирать практические вопросы по обменам между конфигурациями 1С.
В новом видео показываю, как после настройки обмена между ERP / КА2 / УТ и БП правильно выгружать документы, сопоставлять их в БП и управлять регистрацией документов — в том числе массово и по отбору.
Это не «шаблонный» разбор, а сценарий, собранный на основе реальных болей и ошибок, с которыми регулярно сталкиваются компании при работе с обменами между базами. 🫡
Смотреть на RuTube
Смотреть на YouTube
Продолжаю разбирать практические вопросы по обменам между конфигурациями 1С.
В новом видео показываю, как после настройки обмена между ERP / КА2 / УТ и БП правильно выгружать документы, сопоставлять их в БП и управлять регистрацией документов — в том числе массово и по отбору.
Это не «шаблонный» разбор, а сценарий, собранный на основе реальных болей и ошибок, с которыми регулярно сталкиваются компании при работе с обменами между базами. 🫡
Смотреть на RuTube
Смотреть на YouTube
👍4
Мастер сложных вопросов
Иногда за последний год за мной закрепилась неожиданная «специализация».
Хотя, если честно, я к ней не стремился.
Меня всё чаще зовут туда, где:
— проект кажется слишком сложным,
— накопилось много взаимосвязанных проблем,
— непонятно, с чего вообще начать,
— или никто не хочет брать ответственность за разбор ситуации.
И это не про героизм.
Скорее — про привычку не бояться хаоса.
Когда вместо реакции «всё плохо» появляется вопрос:
а где здесь точка сборки?
Почему так происходит?
Наверное, это сочетание:
1. Накопленной экспертности
2. Насмотренности на десятки разных сценариев
Со временем начинаешь видеть структуру там, где другим видится только шум.
1️⃣ Маркировка
Сейчас всё больше сложных кейсов по маркировке.
Каждая товарная категория — со своей спецификой.
Ошибки дорого стоят.
Разбираться долго и местами непросто.
Но шаг за шагом:
— проверяем гипотезы
— смотрим логи
— моделируем сценарии
— общаемся с ЧЗ, 1С, поставщиками
И постепенно туман рассеивается.
Проблема перестаёт быть «непонятной» — становится управляемой.
2️⃣ Клубок интеграций
Клиент, с которым уже работали ранее, пришёл с большим объёмом острых задач.
Первое время ушло не на решение, а на то, чтобы:
— структурировать проблемы
— разложить на блоки
— расставить приоритеты
— понять взаимосвязи
До этого звучало:
«Это проблема 1С, нужна доработка за 50 000».
По факту:
разобрались, нашли причину, решили типовыми средствами значительно дешевле.
Иногда система работает.
Просто никто не посмотрел в правильное место.
3️⃣ Новый вид маркировки
Появляется новый тип требований.
Вместо паники:
— определяем первоисточник
— составляем список уточняющих вопросов
— строим алгоритм действий
И только потом принимаем решение.
Этот образ стал сравним с Мистером Вульфом из «Криминального чтива», которого звали в особых случаях.
В таких ситуациях, как я считаю - естественно всегда может быть риск:
- твоя гипотеза не сработает и нужно генерировать новую
- система зацепится за новую системную ошибку, которая была неочевидной
- ты продумал все на 89%, а нужно было на 95% 😁
И что то еще.
Но пожалуй всё, о чем я пишу - это про то, что в таких ситуациях важно иметь смелость идти вперед, понимая эти самые риски и стараться управлять ими, но это уже совершенно другая история 🙂
Наверное, в этом и есть та самая «магия» — не создавать чудо, а превращать хаос в систему.
А вы куда идёте, когда «всё начинает ломаться»?
Иногда за последний год за мной закрепилась неожиданная «специализация».
Хотя, если честно, я к ней не стремился.
Меня всё чаще зовут туда, где:
— проект кажется слишком сложным,
— накопилось много взаимосвязанных проблем,
— непонятно, с чего вообще начать,
— или никто не хочет брать ответственность за разбор ситуации.
И это не про героизм.
Скорее — про привычку не бояться хаоса.
Когда вместо реакции «всё плохо» появляется вопрос:
а где здесь точка сборки?
Почему так происходит?
Наверное, это сочетание:
1. Накопленной экспертности
2. Насмотренности на десятки разных сценариев
Со временем начинаешь видеть структуру там, где другим видится только шум.
1️⃣ Маркировка
Сейчас всё больше сложных кейсов по маркировке.
Каждая товарная категория — со своей спецификой.
Ошибки дорого стоят.
Разбираться долго и местами непросто.
Но шаг за шагом:
— проверяем гипотезы
— смотрим логи
— моделируем сценарии
— общаемся с ЧЗ, 1С, поставщиками
И постепенно туман рассеивается.
Проблема перестаёт быть «непонятной» — становится управляемой.
2️⃣ Клубок интеграций
Клиент, с которым уже работали ранее, пришёл с большим объёмом острых задач.
Первое время ушло не на решение, а на то, чтобы:
— структурировать проблемы
— разложить на блоки
— расставить приоритеты
— понять взаимосвязи
До этого звучало:
«Это проблема 1С, нужна доработка за 50 000».
По факту:
разобрались, нашли причину, решили типовыми средствами значительно дешевле.
Иногда система работает.
Просто никто не посмотрел в правильное место.
3️⃣ Новый вид маркировки
Появляется новый тип требований.
Вместо паники:
— определяем первоисточник
— составляем список уточняющих вопросов
— строим алгоритм действий
И только потом принимаем решение.
Этот образ стал сравним с Мистером Вульфом из «Криминального чтива», которого звали в особых случаях.
В таких ситуациях, как я считаю - естественно всегда может быть риск:
- твоя гипотеза не сработает и нужно генерировать новую
- система зацепится за новую системную ошибку, которая была неочевидной
- ты продумал все на 89%, а нужно было на 95% 😁
И что то еще.
Но пожалуй всё, о чем я пишу - это про то, что в таких ситуациях важно иметь смелость идти вперед, понимая эти самые риски и стараться управлять ими, но это уже совершенно другая история 🙂
Наверное, в этом и есть та самая «магия» — не создавать чудо, а превращать хаос в систему.
А вы куда идёте, когда «всё начинает ломаться»?
🔥5
Глобализация задач с точки зрения ценности
Недавно пошёл целый ряд интересных кейсов. 🤓
Их объединяет одна вещь: одну и ту же задачу можно сделать по-разному — и ценность для Клиента будет совершенно разной.
Например, обсуждали с Клиентом финансовые инструменты, которые могли бы быть полезны компании для дальнейшего роста.
Я предлагал внедрить отчёты по оборачиваемости активов, метрики эффективности и другие показатели.
Но в процессе обсуждения стало понятно:
сейчас важнее начать с Платёжного календаря.
И здесь можно было пойти простым путём —
привести его в порядок, проверить данные и «сдать результат». 🫠 (Ситуация распространена у многих, особенно после изменений его логики самой 1С чуть меньше года назад)
Но я решил немного расширить рамку.
Во-первых, выяснить — какую конкретно ценность Клиент хочет получить.
Во-вторых, договориться о правилах использования:
как инструмент будет жить внутри компании,
кто отвечает за актуальность данных,
как поддерживается дисциплина работы с цифрами.
Потому что любой отчёт легко превращается в «красивую таблицу»,
если им не пользоваться системно.
И вот здесь, на мой взгляд, и находится настоящая ценность для бизнеса и моральный кайф для меня: 🚀
Не просто внедрить инструмент.
А выстроить систему вокруг него —
зачем он нужен,
как им пользоваться,
и как сделать так, чтобы он продолжал работать без внешнего контроля.
В этом и есть разница между «сделать задачу» и «дать результат». 🙌
Если я дочитываю сообщение до этого момента, то я стараюсь не лениться и ставлю "царский лайк", как пишет один коллега по цеху 😁
А если у вас были случаи, когда вы пытались что-то внедрить, тратили деньги, а оно не взлетало - ставь огонёк - ситуация знакома и я сам с этим сталкивался. Поэтому стараюсь, чтобы любое решение приводило к пользе 🙏
Недавно пошёл целый ряд интересных кейсов. 🤓
Их объединяет одна вещь: одну и ту же задачу можно сделать по-разному — и ценность для Клиента будет совершенно разной.
Например, обсуждали с Клиентом финансовые инструменты, которые могли бы быть полезны компании для дальнейшего роста.
Я предлагал внедрить отчёты по оборачиваемости активов, метрики эффективности и другие показатели.
Но в процессе обсуждения стало понятно:
сейчас важнее начать с Платёжного календаря.
И здесь можно было пойти простым путём —
привести его в порядок, проверить данные и «сдать результат». 🫠 (Ситуация распространена у многих, особенно после изменений его логики самой 1С чуть меньше года назад)
Но я решил немного расширить рамку.
Во-первых, выяснить — какую конкретно ценность Клиент хочет получить.
Во-вторых, договориться о правилах использования:
как инструмент будет жить внутри компании,
кто отвечает за актуальность данных,
как поддерживается дисциплина работы с цифрами.
Потому что любой отчёт легко превращается в «красивую таблицу»,
если им не пользоваться системно.
И вот здесь, на мой взгляд, и находится настоящая ценность для бизнеса и моральный кайф для меня: 🚀
Не просто внедрить инструмент.
А выстроить систему вокруг него —
зачем он нужен,
как им пользоваться,
и как сделать так, чтобы он продолжал работать без внешнего контроля.
В этом и есть разница между «сделать задачу» и «дать результат». 🙌
Если я дочитываю сообщение до этого момента, то я стараюсь не лениться и ставлю "царский лайк", как пишет один коллега по цеху 😁
А если у вас были случаи, когда вы пытались что-то внедрить, тратили деньги, а оно не взлетало - ставь огонёк - ситуация знакома и я сам с этим сталкивался. Поэтому стараюсь, чтобы любое решение приводило к пользе 🙏
🔥3👍2
Карточка номенклатуры в 1С без ошибок: от структуры до маркировки
Часть 1 — Архитектура номенклатуры: группы, виды и аналитика
Запускаю серию роликов о правильном создании номенклатуры в 1С.
Начинаем с фундамента — архитектуры: группы, виды номенклатуры и настройки, от которых зависит вся дальнейшая работа системы.
Если структура продумана слабо — ошибки «всплывут» позже в документах, отчётах и маркировке.
Один из реальных примеров - сотрудники некорректно завели карточки номенклатуры, связанные с маркировкой, разбив один и тот же товар на несколько карточек с разными настройками (разделили штуки и упаковки) - в результате чего - маркировка стала работать неправильно в документах отгрузки, а другой подрядчик, не доразобравшись в проблеме предлагал сделать доработки на 50 тысяч. 🙈
В итоге исправили ситуацию типовыми методами и гораздо дешевле, даже с учётом различных взаимосвязей и интеграций. 🤓
В следующих видео разберём практическое заполнение карточки и работу с маркированными товарами.
Смотреть на RuTube
Смотреть на YouTube
Часть 1 — Архитектура номенклатуры: группы, виды и аналитика
Запускаю серию роликов о правильном создании номенклатуры в 1С.
Начинаем с фундамента — архитектуры: группы, виды номенклатуры и настройки, от которых зависит вся дальнейшая работа системы.
Если структура продумана слабо — ошибки «всплывут» позже в документах, отчётах и маркировке.
Один из реальных примеров - сотрудники некорректно завели карточки номенклатуры, связанные с маркировкой, разбив один и тот же товар на несколько карточек с разными настройками (разделили штуки и упаковки) - в результате чего - маркировка стала работать неправильно в документах отгрузки, а другой подрядчик, не доразобравшись в проблеме предлагал сделать доработки на 50 тысяч. 🙈
В итоге исправили ситуацию типовыми методами и гораздо дешевле, даже с учётом различных взаимосвязей и интеграций. 🤓
В следующих видео разберём практическое заполнение карточки и работу с маркированными товарами.
Смотреть на RuTube
Смотреть на YouTube
rutube.ru
Архитектура номенклатуры: группы, виды и аналитика
В этом видео начинаю серию о создании номенклатуры в 1С УТ / КА2 / ERP.
Разбираем не просто «как создать карточку», а архитектуру: иерархию групп, виды номенклатуры и настройки, которые влияют на работу склада, продаж, финансов и маркировки.
В следующих…
Разбираем не просто «как создать карточку», а архитектуру: иерархию групп, виды номенклатуры и настройки, которые влияют на работу склада, продаж, финансов и маркировки.
В следующих…
👍3
Магия интеграций с Битрикс
Последние пару лет так сложилось, что я всё чаще погружаюсь в тему интеграций между 1С и Битрикс — будь то сайт на Битрикс или CRM Битрикс24.
И это интересное ощущение.
Потому что лет 10–15 назад у меня уже был опыт попытки внедрения Битрикс24 в одном из бизнесов. Тогда, честно говоря, не взлетело практически ничего.
А сейчас, наблюдая за развитием продукта, приятно видеть, насколько сильно он вырос: 💪
интерфейс, возможности автоматизации, интеграции.
Но при этом, если поговорить с коллегами по рынку, вокруг интеграций 1С и Битрикс до сих пор можно услышать знакомые фразы:
— «Ни разу нормально не интегрировалось»
— «Работает только базово, а под реальные задачи нужны огромные доработки»
— «Мы на стороне Битрикс всё настроим, а дальше вы как-нибудь разберётесь с 1С»
Знакомо? 🙂
За последние годы я прошёл через достаточно много таких проектов — не только с Битрикс, но сегодня решил поделиться именно этим направлением.
За последние полгода на нескольких проектах мне удалось посмотреть на интеграцию с обеих сторон:
и со стороны 1С, и со стороны Битрикс.
И это оказалось очень полезно.
Потому что многие проблемы возникают не из-за самой технологии обмена, а из-за вещей, о которых редко говорят заранее.
Например:
— разные термины в системах (что считать заказом, сделкой, клиентом) 😵💫
— различия в логике документов
— несогласованная архитектура данных
Иногда достаточно просто синхронизировать словарь понятий между системами, чтобы снять половину будущих проблем.
Постепенно, проверяя гипотезы и разбирая архитектуру обменов, я начал реализовывать интеграции типовыми или почти типовыми методами — там, где раньше звучали оценки на серьёзные бюджеты доработок.
И самое интересное — информация об этом в принципе существует.
Но когда начинаешь её искать, сталкиваешься с нюансами:
1️⃣ Чтобы найти нужную информацию, нужно очень точно сформулировать технический запрос.
2️⃣ Во многих материалах объясняют архитектуру и теорию интеграций, но практических примеров того, как это реализовать на реальном проекте, почти нет. 🫠
Чаще всего это остаётся внутри команд, которые этим занимаются.
Поэтому особенно ценными кажутся знания, которые приходят через реальные проекты.
Например, за последнее время удалось реализовать:
— связь нетиповых документов между системами
— синхронизацию нетиповых справочников
— сценарии, когда пользователи работают с документами в CRM, а вся логика обработки и учёта происходит в 1С — без прямого доступа пользователей к базе
И постепенно начинаешь видеть, как два разных мира начинают говорить на одном языке.
А у вас был опыт интеграции 1С и Битрикс?
Работает стабильно или тоже проходили через «танцы с бубном»? 👀
Последние пару лет так сложилось, что я всё чаще погружаюсь в тему интеграций между 1С и Битрикс — будь то сайт на Битрикс или CRM Битрикс24.
И это интересное ощущение.
Потому что лет 10–15 назад у меня уже был опыт попытки внедрения Битрикс24 в одном из бизнесов. Тогда, честно говоря, не взлетело практически ничего.
А сейчас, наблюдая за развитием продукта, приятно видеть, насколько сильно он вырос: 💪
интерфейс, возможности автоматизации, интеграции.
Но при этом, если поговорить с коллегами по рынку, вокруг интеграций 1С и Битрикс до сих пор можно услышать знакомые фразы:
— «Ни разу нормально не интегрировалось»
— «Работает только базово, а под реальные задачи нужны огромные доработки»
— «Мы на стороне Битрикс всё настроим, а дальше вы как-нибудь разберётесь с 1С»
Знакомо? 🙂
За последние годы я прошёл через достаточно много таких проектов — не только с Битрикс, но сегодня решил поделиться именно этим направлением.
За последние полгода на нескольких проектах мне удалось посмотреть на интеграцию с обеих сторон:
и со стороны 1С, и со стороны Битрикс.
И это оказалось очень полезно.
Потому что многие проблемы возникают не из-за самой технологии обмена, а из-за вещей, о которых редко говорят заранее.
Например:
— разные термины в системах (что считать заказом, сделкой, клиентом) 😵💫
— различия в логике документов
— несогласованная архитектура данных
Иногда достаточно просто синхронизировать словарь понятий между системами, чтобы снять половину будущих проблем.
Постепенно, проверяя гипотезы и разбирая архитектуру обменов, я начал реализовывать интеграции типовыми или почти типовыми методами — там, где раньше звучали оценки на серьёзные бюджеты доработок.
И самое интересное — информация об этом в принципе существует.
Но когда начинаешь её искать, сталкиваешься с нюансами:
1️⃣ Чтобы найти нужную информацию, нужно очень точно сформулировать технический запрос.
2️⃣ Во многих материалах объясняют архитектуру и теорию интеграций, но практических примеров того, как это реализовать на реальном проекте, почти нет. 🫠
Чаще всего это остаётся внутри команд, которые этим занимаются.
Поэтому особенно ценными кажутся знания, которые приходят через реальные проекты.
Например, за последнее время удалось реализовать:
— связь нетиповых документов между системами
— синхронизацию нетиповых справочников
— сценарии, когда пользователи работают с документами в CRM, а вся логика обработки и учёта происходит в 1С — без прямого доступа пользователей к базе
И постепенно начинаешь видеть, как два разных мира начинают говорить на одном языке.
А у вас был опыт интеграции 1С и Битрикс?
Работает стабильно или тоже проходили через «танцы с бубном»? 👀
🔥3
Карточка номенклатуры в 1С без ошибок: от структуры до маркировки
Часть 2 — Создание карточки номенклатуры в 1С без ошибок
Продолжаем серию роликов про архитектуру номенклатуры в 1С УТ / КА2 / ERP. 🚀
В этом видео разбираем практическое заполнение карточки товара:
как правильно задавать наименование, артикул, единицы измерения, характеристики, упаковки и штрихкоды, а также какие проверки стоит сделать перед использованием товара в документах.
Это второй шаг после архитектуры номенклатуры — дальше перейдём к отдельному блоку маркированных товаров и типовым ошибкам при работе с ними.
Смотреть на RuTube
Смотреть на YouTube
🙌
Если вдруг Telegram станет менее доступен — меня можно найти здесь:
🌐 mvasilev.pro
Часть 2 — Создание карточки номенклатуры в 1С без ошибок
Продолжаем серию роликов про архитектуру номенклатуры в 1С УТ / КА2 / ERP. 🚀
В этом видео разбираем практическое заполнение карточки товара:
как правильно задавать наименование, артикул, единицы измерения, характеристики, упаковки и штрихкоды, а также какие проверки стоит сделать перед использованием товара в документах.
Это второй шаг после архитектуры номенклатуры — дальше перейдём к отдельному блоку маркированных товаров и типовым ошибкам при работе с ними.
Смотреть на RuTube
Смотреть на YouTube
🙌
Кстати, на всякий случай собрал все свои площадки и проектный опыт в одном месте.Если вдруг Telegram станет менее доступен — меня можно найти здесь:
🌐 mvasilev.pro
👍3
Куда дублировать контент
Anonymous Poll
44%
ВКонтакте (VK)
11%
Дзен
11%
VC / статьи / кейсы
44%
Другое
Куда дальше? 🤔
Коллеги, хочу с вами немного синхронизироваться. 🙏
Сейчас вокруг всё чаще обсуждают возможные ограничения Telegram — и, честно говоря, не хочется в какой-то момент просто потерять связь.
Поэтому думаю начать дублировать контент на другие площадки, чтобы:
вам было удобно читать/смотреть
и чтобы мы в любом случае оставались на связи
👉 Подскажите, где вам было бы удобнее следить за материалами?
Другой вариант можно в сообщения канала или в личку 🙂
Параллельно собрал все свои площадки, материалы и проектный опыт в одном месте — на случай, если Telegram всё-таки станет менее доступен:
🔗 mvasilev.pro
Коллеги, хочу с вами немного синхронизироваться. 🙏
Сейчас вокруг всё чаще обсуждают возможные ограничения Telegram — и, честно говоря, не хочется в какой-то момент просто потерять связь.
Поэтому думаю начать дублировать контент на другие площадки, чтобы:
вам было удобно читать/смотреть
и чтобы мы в любом случае оставались на связи
👉 Подскажите, где вам было бы удобнее следить за материалами?
Другой вариант можно в сообщения канала или в личку 🙂
Параллельно собрал все свои площадки, материалы и проектный опыт в одном месте — на случай, если Telegram всё-таки станет менее доступен:
🔗 mvasilev.pro
Новый этап 🙂
Поймал себя на мысли, что за последний год многое поменялось.
Постепенно из разрозненных задач, кейсов и проектов начала складываться более цельная картина —
с пониманием архитектуры, систем и того, как наводить порядок там, где его изначально нет.
И, кажется, это даёт свои результаты.
В апреле буду выступать на конференции Merge в Иннополисе🚀
📍 17–18 апреля
Для меня это первый опыт участия в подобном формате как спикера в ИТ-сфере — и, честно, немного волнительно, но при этом очень интересно.
Планирую разобрать тему, с которой всё чаще сталкиваюсь в проектах:
👉 Аудит и моделирование в 1С: как из хаоса задач собрать управляемую систему
Без «теории ради теории» — с практическими кейсами, ошибками и тем, что реально работает.
Если вдруг кто-то тоже планирует быть на конференции — буду рад пересечься 🙂
🔗 Подробнее о мероприятии:
Merge Conf 2026
🔗 Все мои площадки, материалы и проектный опыт
mvasilev.pro
Поймал себя на мысли, что за последний год многое поменялось.
Постепенно из разрозненных задач, кейсов и проектов начала складываться более цельная картина —
с пониманием архитектуры, систем и того, как наводить порядок там, где его изначально нет.
И, кажется, это даёт свои результаты.
В апреле буду выступать на конференции Merge в Иннополисе🚀
📍 17–18 апреля
Для меня это первый опыт участия в подобном формате как спикера в ИТ-сфере — и, честно, немного волнительно, но при этом очень интересно.
Планирую разобрать тему, с которой всё чаще сталкиваюсь в проектах:
👉 Аудит и моделирование в 1С: как из хаоса задач собрать управляемую систему
Без «теории ради теории» — с практическими кейсами, ошибками и тем, что реально работает.
Если вдруг кто-то тоже планирует быть на конференции — буду рад пересечься 🙂
🔗 Подробнее о мероприятии:
Merge Conf 2026
🔗 Все мои площадки, материалы и проектный опыт
mvasilev.pro
🔥5❤1
Финал серии про номенклатуру в 1С
Закрываю цикл роликов про архитектуру номенклатуры в 1С УТ / КА2 / ERP.
В этом видео разбираю один из самых сложных и чувствительных блоков — маркированные товары.
Показываю:
как правильно настроить карточку маркируемого товара
где чаще всего допускаются ошибки
как работает сканирование кодов в документах
и почему проблемы с Честным знаком чаще всего возникают не там, где их ищут
По опыту, именно маркировка чаще всего «ломается» не из-за 1С, а из-за архитектуры и настроек на старте.
Если выстраивать номенклатуру правильно — этот блок становится вполне управляемым.
🔗 Видео:
Смотреть YouTube
Смотреть RuTube
📚 Вся серия:
1️⃣ Архитектура номенклатуры
2️⃣ Карточка товара
3️⃣ Маркировка
💡 Если тема откликнулась — ставьте огонёк или пишите вопросы в личку - дальше могу разобрать более узкие кейсы по маркировке или интеграциям.
🔗 Все мои площадки, материалы и проектный опыт
mvasilev.pro
Закрываю цикл роликов про архитектуру номенклатуры в 1С УТ / КА2 / ERP.
В этом видео разбираю один из самых сложных и чувствительных блоков — маркированные товары.
Показываю:
как правильно настроить карточку маркируемого товара
где чаще всего допускаются ошибки
как работает сканирование кодов в документах
и почему проблемы с Честным знаком чаще всего возникают не там, где их ищут
По опыту, именно маркировка чаще всего «ломается» не из-за 1С, а из-за архитектуры и настроек на старте.
Если выстраивать номенклатуру правильно — этот блок становится вполне управляемым.
🔗 Видео:
Смотреть YouTube
Смотреть RuTube
📚 Вся серия:
1️⃣ Архитектура номенклатуры
2️⃣ Карточка товара
3️⃣ Маркировка
💡 Если тема откликнулась — ставьте огонёк или пишите вопросы в личку - дальше могу разобрать более узкие кейсы по маркировке или интеграциям.
🔗 Все мои площадки, материалы и проектный опыт
mvasilev.pro
👍3👏1
Forwarded from Профессиональная ИТ-конференция Синтез | Merge
На конференции Синтез | Merge Татарстан мы выделили доклады по 1С в отдельный трек
В числе экспертов направления:
— Директор департамента ИИ и сервисных проектов Яков Кротов «Построение управления сервисами поддержки 1С по модели «Follow the sun»: вызовы, выгоды, кейсы»
— Руководитель направления по развитию инженерных практик разработки решений 1С в Газпромнефть-ЦР Игорь Мокеев «От проектной разработки к фабрике изменений: промышленная модель для 1С»
— Технический архитектор в ИТ-холдинг Т1 Олег Каратаев «Как легко и эффективно поддерживать дымовые тесты в Vanessa Automation»
— Функциональный архитектор в MDev Михаил Васильев «Аудит и моделирование в проектах 1С: как избежать риска и построить управляемый запуск»
— Руководитель проектов в РСМ системы/ERP-IT Дмитрий Изыбаев «1С: Продано! Как донести ценность внедрения ERP системы до тех, кто привык работать по-старому»
— Менеджер по развитию продуктов 1С в Столото Кирилл Медников «SaaS на 1С за 5 дней: как в корпорации запустить облачный сервис для физического производства и подключить AI-агента-аналитика»
👉🏻Полная программа и подробнее о спикерах на сайте.
❗️Пройти опрос от нашей команды и получить скидку 40%
В числе экспертов направления:
— Директор департамента ИИ и сервисных проектов Яков Кротов «Построение управления сервисами поддержки 1С по модели «Follow the sun»: вызовы, выгоды, кейсы»
— Руководитель направления по развитию инженерных практик разработки решений 1С в Газпромнефть-ЦР Игорь Мокеев «От проектной разработки к фабрике изменений: промышленная модель для 1С»
— Технический архитектор в ИТ-холдинг Т1 Олег Каратаев «Как легко и эффективно поддерживать дымовые тесты в Vanessa Automation»
— Функциональный архитектор в MDev Михаил Васильев «Аудит и моделирование в проектах 1С: как избежать риска и построить управляемый запуск»
— Руководитель проектов в РСМ системы/ERP-IT Дмитрий Изыбаев «1С: Продано! Как донести ценность внедрения ERP системы до тех, кто привык работать по-старому»
— Менеджер по развитию продуктов 1С в Столото Кирилл Медников «SaaS на 1С за 5 дней: как в корпорации запустить облачный сервис для физического производства и подключить AI-агента-аналитика»
👉🏻Полная программа и подробнее о спикерах на сайте.
❗️Пройти опрос от нашей команды и получить скидку 40%
👍3
А ты чем вообще занимаешься? 🤓
Недавно разговаривал с одним знакомым предпринимателем.
Зашла речь про 1С — у них она давно внедрена, сейчас делают интеграцию с Битрикс24.
Тема мне близка — решил аккуратно проверить картину:
совпадает ли то, что вижу я, с тем, что происходит у них.
И дальше разговор пошёл интересно.
Сначала я сказал, что занимаюсь архитектурой 1С.
А потом мне начали рассказывать:
— не понимаем, что делать с номенклатурой
— не понимаем, как считать себестоимость
— считаем «на глаз» и кассовым методом
— материалы списываем сразу, а потом просто идём на склад и считаем остатки по факту
При том, что:
- материалы могут использоваться месяцами
- бизнес работает давно
- компания — не маленькая
И вот после этого мне задают вопрос:
«А ты чем вообще занимаешься?»
Я ответил так:
Я занимаюсь тем, чтобы таких проблем не было. 🙂
И лучше — с самого старта проекта, хотя и не обязательно.
Так что же такое архитектура и зачем она нужна?
Если упростить:
1. Архитектура — это про устойчивость системы
Система должна работать стабильно, а риски — быть управляемыми.
2. Архитектура — это не только про технику, но и про мышление
Это творческий процесс, но в рамках строгих правил и логики бизнеса.
Задача архитектора —
взять реальный бизнес (с его хаосом, нюансами и «как привыкли работать»)
и аккуратно наложить его на систему:
- структуру номенклатуры
- логику себестоимости
- движения товаров и денег
- роли пользователей
- интеграции
Так, чтобы:
- это не ломалось через полгода
- это можно было развивать
- и чтобы система помогала, а не мешала
Можно ли обойтись без архитектора?
Конечно можно.
Но тогда почти всегда включается другой сценарий:
- себестоимость считается криво
- остатки «где-то есть»
- пользователи делают лишние действия
- маркировка начинает «сыпаться»
- бухгалтерия страдает перед сдачей отчетности
- обновления становятся дорогими и болезненными
Иногда это заканчивается полной пересборкой системы с нуля.
И это уже совсем другие бюджеты и нервы.
Если чувствуете, что в вашей 1С
что-то работает «не так, как должно» —
напишите.
Разберёмся, где именно система начала идти не туда.
🔗 Все мои площадки, материалы и проектный опыт
mvasilev.pro
Недавно разговаривал с одним знакомым предпринимателем.
Зашла речь про 1С — у них она давно внедрена, сейчас делают интеграцию с Битрикс24.
Тема мне близка — решил аккуратно проверить картину:
совпадает ли то, что вижу я, с тем, что происходит у них.
И дальше разговор пошёл интересно.
Сначала я сказал, что занимаюсь архитектурой 1С.
А потом мне начали рассказывать:
— не понимаем, что делать с номенклатурой
— не понимаем, как считать себестоимость
— считаем «на глаз» и кассовым методом
— материалы списываем сразу, а потом просто идём на склад и считаем остатки по факту
При том, что:
- материалы могут использоваться месяцами
- бизнес работает давно
- компания — не маленькая
И вот после этого мне задают вопрос:
«А ты чем вообще занимаешься?»
Я ответил так:
Я занимаюсь тем, чтобы таких проблем не было. 🙂
И лучше — с самого старта проекта, хотя и не обязательно.
Так что же такое архитектура и зачем она нужна?
Если упростить:
1. Архитектура — это про устойчивость системы
Система должна работать стабильно, а риски — быть управляемыми.
2. Архитектура — это не только про технику, но и про мышление
Это творческий процесс, но в рамках строгих правил и логики бизнеса.
Задача архитектора —
взять реальный бизнес (с его хаосом, нюансами и «как привыкли работать»)
и аккуратно наложить его на систему:
- структуру номенклатуры
- логику себестоимости
- движения товаров и денег
- роли пользователей
- интеграции
Так, чтобы:
- это не ломалось через полгода
- это можно было развивать
- и чтобы система помогала, а не мешала
Можно ли обойтись без архитектора?
Конечно можно.
Но тогда почти всегда включается другой сценарий:
- себестоимость считается криво
- остатки «где-то есть»
- пользователи делают лишние действия
- маркировка начинает «сыпаться»
- бухгалтерия страдает перед сдачей отчетности
- обновления становятся дорогими и болезненными
Иногда это заканчивается полной пересборкой системы с нуля.
И это уже совсем другие бюджеты и нервы.
Если чувствуете, что в вашей 1С
что-то работает «не так, как должно» —
напишите.
Разберёмся, где именно система начала идти не туда.
🔗 Все мои площадки, материалы и проектный опыт
mvasilev.pro
👍3🔥1
ИИ тебе не поможет
Пост провокационный — но давай разберёмся 🙂
Сейчас ИИ — везде.
И это действительно мощный инструмент.
Но есть один нюанс, о котором редко говорят:
Если ты не понимаешь основу — ИИ не усилит тебя.
Он ускорит твои ошибки.
Я это особенно сильно чувствую в работе с 1С и интеграциями.
Можно сгенерировать код.
Можно «навайбкодить» интеграцию.
Можно даже заставить системы как-то обмениваться данными.
Но.
Если ты не понимаешь:
как устроены регистры
как работает себестоимость
что такое двойная запись
как строится структура данных
как устроена логика обмена
Ты не проверишь результат.
И самое опасное —
ты даже не поймёшь, что сделал неправильно.
Я сейчас сам углубляюсь дальше:
в разные языки, в структуры данных, в логику интеграций.
Не потому что «модно»,
а потому что без этого невозможно строить устойчивые решения.
Сегодня много «интеграторов».
Но часто это уровень:
👉 подключить систему к системе
👉 настроить воронку
👉 «чтобы что-то работало»
А вот сделать так, чтобы:
данные не ломались
процессы сходились
система жила годами
— для этого нужна глубина.
Поэтому моя позиция простая:
ИИ — это инструмент.
Очень сильный.
Но опираться нужно не на него,
а на свои знания.
А уже сверху — усиливать себя инструментами.
Если хотите, чтобы ваши проекты:
не рассыпались через полгода
не требовали переделки с нуля
и реально работали
— тут уже важна не генерация,
а архитектура.
На этой неделе буду выступать на Merge — как раз буду разбирать,
почему проекты ломаются ещё до старта.
Думаю, будет полезно 🙂
🔗 Все мои площадки, материалы и проектный опыт
mvasilev.pro
Пост провокационный — но давай разберёмся 🙂
Сейчас ИИ — везде.
И это действительно мощный инструмент.
Но есть один нюанс, о котором редко говорят:
Если ты не понимаешь основу — ИИ не усилит тебя.
Он ускорит твои ошибки.
Я это особенно сильно чувствую в работе с 1С и интеграциями.
Можно сгенерировать код.
Можно «навайбкодить» интеграцию.
Можно даже заставить системы как-то обмениваться данными.
Но.
Если ты не понимаешь:
как устроены регистры
как работает себестоимость
что такое двойная запись
как строится структура данных
как устроена логика обмена
Ты не проверишь результат.
И самое опасное —
ты даже не поймёшь, что сделал неправильно.
Я сейчас сам углубляюсь дальше:
в разные языки, в структуры данных, в логику интеграций.
Не потому что «модно»,
а потому что без этого невозможно строить устойчивые решения.
Сегодня много «интеграторов».
Но часто это уровень:
👉 подключить систему к системе
👉 настроить воронку
👉 «чтобы что-то работало»
А вот сделать так, чтобы:
данные не ломались
процессы сходились
система жила годами
— для этого нужна глубина.
Поэтому моя позиция простая:
ИИ — это инструмент.
Очень сильный.
Но опираться нужно не на него,
а на свои знания.
А уже сверху — усиливать себя инструментами.
Если хотите, чтобы ваши проекты:
не рассыпались через полгода
не требовали переделки с нуля
и реально работали
— тут уже важна не генерация,
а архитектура.
На этой неделе буду выступать на Merge — как раз буду разбирать,
почему проекты ломаются ещё до старта.
Думаю, будет полезно 🙂
🔗 Все мои площадки, материалы и проектный опыт
mvasilev.pro
👍4