Так, я ж про сопровождение не всё рассказал. В прошлый раз было про оплату в нерабочее время по обычной ставке.
Итак, у нас есть команда из нескольких человек, закреплённая за клиентом, есть продюсер (главный по клиенту), где-то на бэкграунде есть менеджер.
Очень быстро наткнулись на ожидаемую проблему - от клиента пришла задача, которую не могла решить назначенная команда. Ну т.е. как не могла... Могла, конечно. Я всегда программистам говорю - вы можете решить любую задачу, вопрос лишь в требуемом количестве времени. Это так, для мотивации, чтобы забыли слово "невозможно" :)
Так вот, мы реалисты, и понимаем - у любого клиента может случиться сложная задача. Сложная по комбинации факторов, один из которых, обычно - срочность. Хотя, бывает и не срочно. Что делать?
Традиционный подход, принятый во франчах - иметь в загашнике неких экспертов, которых можно Привлекать к решению задач. Звучит неплохо, но... В реальности это почти всегда жуть. Опять же, потому что франч - тут люди навроде ваших станков, которые должны быть всегда загружены. Ну, бизнес такой.
Обычно эксперт всегда занят. Его грузят в первую очередь, потому что он стоит дорого. Он не может и не должен простаивать. Чем же его грузят? По уму, это должны быть какие-то экспертные работы - что-то эдакое, где абы кто не справится. Но чтобы на полный день загрузить эксперта такой работой, нужно стадо менеджеров. Парадокс, но... Экспертные работы клиентам нужны редко. Ну, нет у них столько сложных и страшных проблем. Наверное, можно считать это комплиментом 1С. Или срочности у проблем нет.
Проще говоря, эксперта во франче грузят всем подряд - чтобы не простаивал. Эксперт - человек ответственный, поэтому делает всё, что ему поручили, качественно и в срок. Увы, для нас это означает, что в случае срочной необходимости эксперта нельзя отвлечь - он же обещал печатную форму к вечеру дорисовать. Поэтому толку от него - как от адронного коллайдера.
Такой эксперт нам не нужен, решили мы. И сделали так, что эксперт не занят никакими работами. Он просто сидит и помогает другим решать сложные задачи, это - ключевое его предназначение.
Как я написал выше, экспертных задач-то немного. Поэтому эксперт не сильно занят, не зашивается, не страдает.
Главное - чтобы он был в доступе, когда потребуется. Чтобы ждать его не надо было.
Сломалась база, команда не справляется известными ей методами - зовём эксперта, он сразу приходит. И починить поможет, и команда что-то новое узнает.
Надо принять сложное архитектурное решение - позвали эксперта, за 10 минут объяснили ситуацию, он 10 минут подумал, 10 минут поговорил - решение принято, за полчаса.
И самое удивительное - сколько в реальности нужно экспертов, чтобы поддерживать такую схему. У меня в отделе их всего два, а программистов - 30. И не сказать, что эксперты перерабатывают. Один из них успевает всем отделом управлять, продавать, программировать и всякую фигню в интернете писать про использование экспертов :)
Да, чуть не забыл. За помощь эксперта программистам клиент ничего не платит. Пару лет мы закладывали доплату за эксперта в часовую ставку, объясняя смысл клиентам и предоставляя право выбрать (с экспертом или без). Разница была рублей 200 вроде, 8% тогдашней ставки.
Никто ни разу не выбрал вариант без эксперта, поэтому мы убрали эту вилку - теперь эксперт всегда стоит за спиной программистов.
Итак, у нас есть команда из нескольких человек, закреплённая за клиентом, есть продюсер (главный по клиенту), где-то на бэкграунде есть менеджер.
Очень быстро наткнулись на ожидаемую проблему - от клиента пришла задача, которую не могла решить назначенная команда. Ну т.е. как не могла... Могла, конечно. Я всегда программистам говорю - вы можете решить любую задачу, вопрос лишь в требуемом количестве времени. Это так, для мотивации, чтобы забыли слово "невозможно" :)
Так вот, мы реалисты, и понимаем - у любого клиента может случиться сложная задача. Сложная по комбинации факторов, один из которых, обычно - срочность. Хотя, бывает и не срочно. Что делать?
Традиционный подход, принятый во франчах - иметь в загашнике неких экспертов, которых можно Привлекать к решению задач. Звучит неплохо, но... В реальности это почти всегда жуть. Опять же, потому что франч - тут люди навроде ваших станков, которые должны быть всегда загружены. Ну, бизнес такой.
Обычно эксперт всегда занят. Его грузят в первую очередь, потому что он стоит дорого. Он не может и не должен простаивать. Чем же его грузят? По уму, это должны быть какие-то экспертные работы - что-то эдакое, где абы кто не справится. Но чтобы на полный день загрузить эксперта такой работой, нужно стадо менеджеров. Парадокс, но... Экспертные работы клиентам нужны редко. Ну, нет у них столько сложных и страшных проблем. Наверное, можно считать это комплиментом 1С. Или срочности у проблем нет.
Проще говоря, эксперта во франче грузят всем подряд - чтобы не простаивал. Эксперт - человек ответственный, поэтому делает всё, что ему поручили, качественно и в срок. Увы, для нас это означает, что в случае срочной необходимости эксперта нельзя отвлечь - он же обещал печатную форму к вечеру дорисовать. Поэтому толку от него - как от адронного коллайдера.
Такой эксперт нам не нужен, решили мы. И сделали так, что эксперт не занят никакими работами. Он просто сидит и помогает другим решать сложные задачи, это - ключевое его предназначение.
Как я написал выше, экспертных задач-то немного. Поэтому эксперт не сильно занят, не зашивается, не страдает.
Главное - чтобы он был в доступе, когда потребуется. Чтобы ждать его не надо было.
Сломалась база, команда не справляется известными ей методами - зовём эксперта, он сразу приходит. И починить поможет, и команда что-то новое узнает.
Надо принять сложное архитектурное решение - позвали эксперта, за 10 минут объяснили ситуацию, он 10 минут подумал, 10 минут поговорил - решение принято, за полчаса.
И самое удивительное - сколько в реальности нужно экспертов, чтобы поддерживать такую схему. У меня в отделе их всего два, а программистов - 30. И не сказать, что эксперты перерабатывают. Один из них успевает всем отделом управлять, продавать, программировать и всякую фигню в интернете писать про использование экспертов :)
Да, чуть не забыл. За помощь эксперта программистам клиент ничего не платит. Пару лет мы закладывали доплату за эксперта в часовую ставку, объясняя смысл клиентам и предоставляя право выбрать (с экспертом или без). Разница была рублей 200 вроде, 8% тогдашней ставки.
Никто ни разу не выбрал вариант без эксперта, поэтому мы убрали эту вилку - теперь эксперт всегда стоит за спиной программистов.
👍14🔥4👏2
Один старый клиент обновил начал работать в УНФ - у него розничная сеть, которая работала на 1С:Рознице. Оказалось, с Розницы на УНФ можно просто обновиться.
В УНФ работать страшно, когда что-то более или менее серьёзное требуется. Не потому, что в УНФ чего-то нет - как раз наоборот.
Там с виду есть почти всё, что людям привычно в "больших" конфигурациях. Но оно... Как ты это сказать... Не доделано, короче.
На уровне прототипа, MVP. Сделано будто в предположении, что пользоваться никто не будет, поэтому отсутствующих деталей не заметит.
Из последнего: обмен с ЗУП. Клиент видит, что обмен в конфигурации присутствует, настраивает - а там почти никакие данные не ходят.
Читаем мнение разработчиков - а они не собирались "развивать" обмен с ЗУП (нафига тогда создавали "недоразвитый" обмен?). Потом читаем - ага, полгода назад передумали, начали развивать. Обновляем - стало получше, данных ходит больше, но...
Но мы не можем получить в УНФ хотя бы расходы по зарплате из ЗУПа. Потому что отражение зарплаты из ЗУПа приходит, но не делает никаких движений в регистрах 😁. А документ начисления зарплаты, который делает движения, не участвует в обмене 😂.
И это не в первый раз. До того был баланс, НДС в запасах, что-то ещё.
Так-то можно доработать, без проблем. Но когда клиенты покупают УНФ, они не планировали тратить кучу денег на доработки, особенно нацеленные на "просто чтобы работало".
В ЕРП такое тоже есть, но в менее востребованных кусках, вроде планирования. Уж отражение расходов по зарплате-то там работает.
В УНФ работать страшно, когда что-то более или менее серьёзное требуется. Не потому, что в УНФ чего-то нет - как раз наоборот.
Там с виду есть почти всё, что людям привычно в "больших" конфигурациях. Но оно... Как ты это сказать... Не доделано, короче.
На уровне прототипа, MVP. Сделано будто в предположении, что пользоваться никто не будет, поэтому отсутствующих деталей не заметит.
Из последнего: обмен с ЗУП. Клиент видит, что обмен в конфигурации присутствует, настраивает - а там почти никакие данные не ходят.
Читаем мнение разработчиков - а они не собирались "развивать" обмен с ЗУП (нафига тогда создавали "недоразвитый" обмен?). Потом читаем - ага, полгода назад передумали, начали развивать. Обновляем - стало получше, данных ходит больше, но...
Но мы не можем получить в УНФ хотя бы расходы по зарплате из ЗУПа. Потому что отражение зарплаты из ЗУПа приходит, но не делает никаких движений в регистрах 😁. А документ начисления зарплаты, который делает движения, не участвует в обмене 😂.
И это не в первый раз. До того был баланс, НДС в запасах, что-то ещё.
Так-то можно доработать, без проблем. Но когда клиенты покупают УНФ, они не планировали тратить кучу денег на доработки, особенно нацеленные на "просто чтобы работало".
В ЕРП такое тоже есть, но в менее востребованных кусках, вроде планирования. Уж отражение расходов по зарплате-то там работает.
👍5
Когда работал ИТ-директором, случалось заниматься настоящей автоматизацией, когда цель - как минимум освободить у сотрудников значительное количество времени. А в идеале - чтобы эти сотрудники стали не нужны. Кровожадно немного, конечно, но если разобраться, исходная цель автоматизации именно в этом.
Но, увы, такие задачи и цели бывают редко. А уж во франч с ними вообще почти не приходят.
Репутация такая у франчей - им же надо задачу ставить, а не проблему или цель озвучивать.
А как будет задача звучать? "Автоматизируйте деятельность этого человека, чтобы его можно было уволить"? И кто это сделать сможет?
Один раз за 5 лет была такая задача, но быстро отменилась (людей просто припугнуть хотел директор, они всё поняли и "исправились").
Я как-то статью писал на эту тему, некий кейс - как организовать увольнение людей через автоматизацию.
Выдержка:
"Автоматизация (по определению из Википедии) — одно из направлений научно-технического прогресса, использующее саморегулирующие технические средства и математические методы с целью освобождения человека от участия в процессах получения, преобразования, передачи и использования энергии, материалов, изделий или информации, либо существенного уменьшения степени этого участия или трудоёмкости выполняемых операций.
Ключевую фразу я выделил жирным шрифтом. Проще говоря, автоматизация нужна для того, чтобы освободить человека от каких-то обязанностей. Что это такое – освобождение человека от обязанностей? Вы ведь слышали фразу «освобожден от исполнения обязанностей»? Это – увольнение.
Если вы занимаетесь автоматизацией, то скажите честно – много ли людей были освобождены от обязанностей благодаря вашей работе? Только здесь важны факты, а не домыслы.
К сожалению, или к счастью, такая цель автоматизации, как увольнение людей, или сокращение персонала, или перевод его на другие должности, несколько подзабыта. Проекты автоматизации, по факту, скорее создают новые штатные единицы, которые заполняются бухгалтерами, менеджерами, программистами, администраторами, экономистами, разного рода операторами и так далее."
https://infostart.ru/pm/1017534/
Но, увы, такие задачи и цели бывают редко. А уж во франч с ними вообще почти не приходят.
Репутация такая у франчей - им же надо задачу ставить, а не проблему или цель озвучивать.
А как будет задача звучать? "Автоматизируйте деятельность этого человека, чтобы его можно было уволить"? И кто это сделать сможет?
Один раз за 5 лет была такая задача, но быстро отменилась (людей просто припугнуть хотел директор, они всё поняли и "исправились").
Я как-то статью писал на эту тему, некий кейс - как организовать увольнение людей через автоматизацию.
Выдержка:
"Автоматизация (по определению из Википедии) — одно из направлений научно-технического прогресса, использующее саморегулирующие технические средства и математические методы с целью освобождения человека от участия в процессах получения, преобразования, передачи и использования энергии, материалов, изделий или информации, либо существенного уменьшения степени этого участия или трудоёмкости выполняемых операций.
Ключевую фразу я выделил жирным шрифтом. Проще говоря, автоматизация нужна для того, чтобы освободить человека от каких-то обязанностей. Что это такое – освобождение человека от обязанностей? Вы ведь слышали фразу «освобожден от исполнения обязанностей»? Это – увольнение.
Если вы занимаетесь автоматизацией, то скажите честно – много ли людей были освобождены от обязанностей благодаря вашей работе? Только здесь важны факты, а не домыслы.
К сожалению, или к счастью, такая цель автоматизации, как увольнение людей, или сокращение персонала, или перевод его на другие должности, несколько подзабыта. Проекты автоматизации, по факту, скорее создают новые штатные единицы, которые заполняются бухгалтерами, менеджерами, программистами, администраторами, экономистами, разного рода операторами и так далее."
https://infostart.ru/pm/1017534/
👍11🔥4😐2👎1
Другой 1С
Вспомнил я тут старую добрую традицию, с моей первой работы - при продаже программ и лицензий 1С дарить часы работы программистов. Их называют "бесплатные", "коробочные", "установочные" и т.д. Не важно. В 2005-2009 г., в первом моём франче, была простая формула…
Акция ещё действует, за сентябрь отгрузили примерно 60 бесплатных часов, столько же висит пока неиспользованных клиентами.
За неделю октября ещё 12 бесплатных часов начислили - клиент купил лицензии.
За неделю октября ещё 12 бесплатных часов начислили - клиент купил лицензии.
Очень хочется узнать о вас побольше, чтобы слова правильнее выбирать. Не откажите, пожалуйста, тыкните подходящий вариант.
Итак, вы - ...
Итак, вы - ...
Anonymous Poll
6%
Работаете в моём отделе 101
3%
Работаете в Челябинском офисе Первого Бита
6%
Работаете в каком-то другом офисе Первого Бита
16%
Работаете в другом франче (конкуренты, т.е.)
2%
Клиент/партнёр, работаете с моим отделом
1%
Клиент/партнёр, работаете с Первым Битом, но не с моим отделом
7%
Клиент/партнёр, не работаете с Первым Битом
55%
Просто хороший человек
5%
Автор этого канала
Если верить результатам опроса, у нас тут, в основном, собрались просто хорошие люди 😏
Ну и конкуренты.
Штош, буду учитывать при выборе тем.
Ну и конкуренты.
Штош, буду учитывать при выборе тем.
😁8
Другой 1С
FlowconПроверкаДанных 202605071514.cfe
На случай, если вы ещё не используете "Проверку данных", я пару примеров применения напишу. И суть идеи.
Суть идеи: не программировать каждую мелкую, "глупую" проверку, привязанную к конкретным данным клиента.
Например, у вас есть номенклатура, которую вы больше не используете - вывели из оборота, поставщик пропал, перешли на аналог и т.д.
Вы её или на удаление помечаете, или в отдельную папку складываете, или "НЕ ИСПОЛЬЗОВАТЬ" дописываете в названии.
Как запретить пользователям указывать её, например, в заказах? Типовых средств нет. Программист может сделать, но это минимум 1 час работы, включая обновление базы. Ещё и ругаться будет, что в коде приходится обращаться к конкретной папке номенклатуры.
А в "Проверке данных" вы это сделаете минут за 5-10 без программирования. Просто укажете документ, и сделаете отбор, как в отчётах (типа "Номенклатуре Не в группе Удаленные). И всё.
Или вот хотите вы, чтобы пользователь в УПП в номенклатуре всегда указывал номенклатурную группу - для вас это важно, она используется в отчётах. А УПП позволяет не заполнять. Программист-то справится, через конфигуратор.
И "Проверка данных справится", только минут за 5 и без программирования.
Если заменить УПП на ЕРП, а номенклатурную группу на ГФУ - ответ будет тем же.
Чуть сложнее: хотите вы, чтобы указывали в номенклатуре артикул. Но не во всей, а только в папке "Товары". Тоже в проверку данных, тоже минут на 5.
Ну, вы поняли. Уровень сложности использования "Проверки данных" - как отбор в отчёте настроить. А мелких хотелок задёшево реализует - не сосчитать.
Суть идеи: не программировать каждую мелкую, "глупую" проверку, привязанную к конкретным данным клиента.
Например, у вас есть номенклатура, которую вы больше не используете - вывели из оборота, поставщик пропал, перешли на аналог и т.д.
Вы её или на удаление помечаете, или в отдельную папку складываете, или "НЕ ИСПОЛЬЗОВАТЬ" дописываете в названии.
Как запретить пользователям указывать её, например, в заказах? Типовых средств нет. Программист может сделать, но это минимум 1 час работы, включая обновление базы. Ещё и ругаться будет, что в коде приходится обращаться к конкретной папке номенклатуры.
А в "Проверке данных" вы это сделаете минут за 5-10 без программирования. Просто укажете документ, и сделаете отбор, как в отчётах (типа "Номенклатуре Не в группе Удаленные). И всё.
Или вот хотите вы, чтобы пользователь в УПП в номенклатуре всегда указывал номенклатурную группу - для вас это важно, она используется в отчётах. А УПП позволяет не заполнять. Программист-то справится, через конфигуратор.
И "Проверка данных справится", только минут за 5 и без программирования.
Если заменить УПП на ЕРП, а номенклатурную группу на ГФУ - ответ будет тем же.
Чуть сложнее: хотите вы, чтобы указывали в номенклатуре артикул. Но не во всей, а только в папке "Товары". Тоже в проверку данных, тоже минут на 5.
Ну, вы поняли. Уровень сложности использования "Проверки данных" - как отбор в отчёте настроить. А мелких хотелок задёшево реализует - не сосчитать.
🔥12👍9
Вы интеграцию с маркетплейсами как делаете? В типовых вроде до сих пор нормально не сделано.
У меня клиент на УПП, мебель делает. Два направления: одно - индивидуальное (дорого, красиво), второе - массовые продукты (тоже хорошие, но массовые). Прям два завода отдельных.
Года три назад начали на маркетплейсах работать. Сначала вручную, через личные кабинеты. Потом попёрло.
Озон, ЯМ, ВБ. Леруа по дороге, который Лемана про теперь ("промышленный" маркетплейс). Потом Хофф добавился.
Смотрели обработки, типа инфостартовских. Чот вроде так себе. Да и слишком высок шанс напороться.
В результате делали сами, без понтов, ровно необходимое. Работает потихоньку.
У вас как с этим?
У меня клиент на УПП, мебель делает. Два направления: одно - индивидуальное (дорого, красиво), второе - массовые продукты (тоже хорошие, но массовые). Прям два завода отдельных.
Года три назад начали на маркетплейсах работать. Сначала вручную, через личные кабинеты. Потом попёрло.
Озон, ЯМ, ВБ. Леруа по дороге, который Лемана про теперь ("промышленный" маркетплейс). Потом Хофф добавился.
Смотрели обработки, типа инфостартовских. Чот вроде так себе. Да и слишком высок шанс напороться.
В результате делали сами, без понтов, ровно необходимое. Работает потихоньку.
У вас как с этим?
❤1
Случайно узнал, что делали клиенту прогнозирование дефицита при увеличении плана продаж в ЕРП.
Системка, небольшая, которая отвечает на вопрос "Сколько ещё можем продать, сверх запланированного?".
Примерно так. Люди вбивают планы продаж на полгода вперёд. Из них делают планы производства.
Наша штуковина (на базе УМП, универсального механизма планирования) рассчитывает потребность в материалах и полуфабрикатах, исходя из плана, остатков на складах, заказов поставщикам, товаров в пути, сроков доставки и т.д.
Пересчитывает она где-то раз в полчаса, исходя из реалий - могут и планы поменять, и факт учитывает (отгрузки, выпуски).
Так вот, это - основная часть системы, которая просчитывает некий Утверждённый план и показывает его исполнимость на полгода вперёд.
А потом клиент подумал - так, а чё, вдруг можно больше продать? Ну мы и приделали нашлёпку.
Люди вбивают доп. планы продаж, по отдельному сценарию. Система берёт результаты расчёта по утвержденному плану (невостребованные материалы на складах, в пути, в заказах поставщику - их же всегда чуть больше берут), и показывает, сколько из этого доп.плана ещё можно продать.
Клиент смотрит на результаты по доп.плану, и может часть его перенести в Утверждённый - например, на следующий месяц. А можно и в текущий.
Система тут же пересчитывается, показывает обновлённый результат.
А там закупщики уже видят, по номенклатуре дефицитов и логистическому плечу, что прям реально не получится впихнуть, а что - вполне можно, просто болтиков не хватает, которые в соседнем магазине продаются.
P.S. А "случайно узнал" потому, что перенастраивали расчёт дефицитов для основного плана, и чутка сломали расчёт дополнительных планов.
А я и забыл, что такую штуку делали.
Системка, небольшая, которая отвечает на вопрос "Сколько ещё можем продать, сверх запланированного?".
Примерно так. Люди вбивают планы продаж на полгода вперёд. Из них делают планы производства.
Наша штуковина (на базе УМП, универсального механизма планирования) рассчитывает потребность в материалах и полуфабрикатах, исходя из плана, остатков на складах, заказов поставщикам, товаров в пути, сроков доставки и т.д.
Пересчитывает она где-то раз в полчаса, исходя из реалий - могут и планы поменять, и факт учитывает (отгрузки, выпуски).
Так вот, это - основная часть системы, которая просчитывает некий Утверждённый план и показывает его исполнимость на полгода вперёд.
А потом клиент подумал - так, а чё, вдруг можно больше продать? Ну мы и приделали нашлёпку.
Люди вбивают доп. планы продаж, по отдельному сценарию. Система берёт результаты расчёта по утвержденному плану (невостребованные материалы на складах, в пути, в заказах поставщику - их же всегда чуть больше берут), и показывает, сколько из этого доп.плана ещё можно продать.
Клиент смотрит на результаты по доп.плану, и может часть его перенести в Утверждённый - например, на следующий месяц. А можно и в текущий.
Система тут же пересчитывается, показывает обновлённый результат.
А там закупщики уже видят, по номенклатуре дефицитов и логистическому плечу, что прям реально не получится впихнуть, а что - вполне можно, просто болтиков не хватает, которые в соседнем магазине продаются.
P.S. А "случайно узнал" потому, что перенастраивали расчёт дефицитов для основного плана, и чутка сломали расчёт дополнительных планов.
А я и забыл, что такую штуку делали.
👍6❤1🔥1
Другой 1С
Неожиданно завершился проект перехода с УПП на ЕРП, который по экспертной технологии делали. Подбиваю стоимость: 1600 часов. Часовую ставку клиента говорить не буду - нельзя поди. Умножьте на известную вам, получите стоимость проекта. В экспертной технологии…
20 февраля писал, что проект завершился и обошёлся в 1600 часов, но он ещё немного подрыгался, до апреля 24 года. В принципе, так и положено - закрытие первого квартала можно считать какой-никакой точкой в проекте перехода. Хотя, там мнения разделились - то ли это был хвост проекта, то ли уже сопровождение.
Система в эксплуатации 11 месяцев, можно подбить-таки трудозатраты. Итак, переход стоил 1930 часов. Умножьте на известную вам ставку, получите стоимость.
Доработок было достаточно много, включая перенос части исторических данных из УПП в ЕРП - люди хотели смотреть отчёты, например, по продажам, за несколько лет в одной системе. Переносили в спец.регистры и писали отчёты, которые объединяют старые и новые данные.
Баз ЕРП там не одна, а две, и между ними обмен.
Короче, нормальный такой средний проект по составу работ.
С мая идёт сопровождение+развитие, средний бюджет часов 30 в месяц.
Система в эксплуатации 11 месяцев, можно подбить-таки трудозатраты. Итак, переход стоил 1930 часов. Умножьте на известную вам ставку, получите стоимость.
Доработок было достаточно много, включая перенос части исторических данных из УПП в ЕРП - люди хотели смотреть отчёты, например, по продажам, за несколько лет в одной системе. Переносили в спец.регистры и писали отчёты, которые объединяют старые и новые данные.
Баз ЕРП там не одна, а две, и между ними обмен.
Короче, нормальный такой средний проект по составу работ.
С мая идёт сопровождение+развитие, средний бюджет часов 30 в месяц.
👍11💘2
Линейный раскрой тут в 1С встроил. Сам алгоритм не делал, взял готовый у Евгения Малярова из Окнософта (я там работал 2 года). Там основные клиенты - оконщики, они без раскроя жить не могут, т.к. всё время что-то из чего-то нарезают, и хотят поменьше обрезков выкидывать.
А мне задача интересная пришла - у людей ЖБИ-завод, и там стометровую линию бетона заливают, а из неё как-то плиты разного размера нарезают. Не знал, что такое бывает.
Я спросил, как расрой делают - сказали на коленке как-то, по опыту, вручную. Предложил попробовать оптимизацию раскроя - вот, пробуем.
Суть задачи проста: есть портфель заказов из плит разной длины. Надо выбрать из портфеля такой набор, чтобы максимально использовать линию, оставив минимум остатка (лучше - ноль).
Понятно, что это лишь первый этап - надо будет как-то решать вопрос приоритетности, а то какие-нибудь негабаритные детали никогда не попадут на линию. Но это дальше.
А вы линейный раскрой используете?
А мне задача интересная пришла - у людей ЖБИ-завод, и там стометровую линию бетона заливают, а из неё как-то плиты разного размера нарезают. Не знал, что такое бывает.
Я спросил, как расрой делают - сказали на коленке как-то, по опыту, вручную. Предложил попробовать оптимизацию раскроя - вот, пробуем.
Суть задачи проста: есть портфель заказов из плит разной длины. Надо выбрать из портфеля такой набор, чтобы максимально использовать линию, оставив минимум остатка (лучше - ноль).
Понятно, что это лишь первый этап - надо будет как-то решать вопрос приоритетности, а то какие-нибудь негабаритные детали никогда не попадут на линию. Но это дальше.
А вы линейный раскрой используете?
🔥16👍6
Другой 1С
Линейный раскрой тут в 1С встроил. Сам алгоритм не делал, взял готовый у Евгения Малярова из Окнософта (я там работал 2 года). Там основные клиенты - оконщики, они без раскроя жить не могут, т.к. всё время что-то из чего-то нарезают, и хотят поменьше обрезков…
Эх, пропал зря наш линейный раскрой - директор предприятия, который его заказывал, уволился. А на новом месте ему раскраивать нечего.
Ладно, хоть потренировались.
Ладно, хоть потренировались.
😭6🙈2👍1
Конец 2024 и начало 2025 прошли под девизами "А-а-а-а-а надо срочно обновляться на 100500 релизов", "Блин, все-таки придётся переходить на другую конфигурацию" и "Никогда не обновлялись, как это вообще делается?".
Почти всех, кто пришёл, я обновлял/обновляю/буду обновлять сам. У меня странная, необъяснимая любовь к обновлениям. Хотя, большинство моих программистов тоже всё это умеют - научил. Особенно когда волна переходов в ЕРП шла, с 2.4 на 2.5 без вариантов.
Часть пришедших - владельцы УПП, которым нормально жилось на релизе годовалой давности (или старше). Изменения в законодательстве они или ручками переносили (вроде мелких, про сч/ф), или их они не касались, или отражали какие-то операции вручную (вроде 97.КР). А тут хлобысь - и НДС, и НДФЛ.
Технология обновления УПП на много релизов давно отработана, поэтому проблем не возникло. В том числе - если надо обеспечить работу на какой-нибудь старой версии платформы.
Другая часть обратившихся - владельцы ЕРП, КА2, УТ. Некоторые вели РУ рядом, в БП, а зарплату - в ЗУПе, поэтому особо не переживали за обновления. А тут раз - и НДС. Кто-то сейчас на 2.5.12 (этим повезло, переход на 2.5.17 несложен), некоторые на 2.4 (тут предстоит Большой Скачок на 2.5). Тут нельзя не похвалить политику релизов ЕРП и его младших - с 2.4 на 2.5 можно перейти за очень небольшое количество шагов. А с 2.5.12 на свежий 2.5.17 - вообще за один.
Ну а самые интересные - те, кто работал на чём-то очень старом, перелопаченном и в хлам кастомизированном. Например, на БП1, из которой своими руками сделали УХ (по функциональности). Пришли те, кто ранее заказывал у меня расширенный аудит конфигурации - не только технический, но и с обсуждением перспектив использования. Возможное изменение ставок НДС я указывал, как Чёрного Лебедя - риск, который может серьёзно осложнить жизнь в старой, необновляемой конфигурации.
Да, и сильно активизировались переходы зарплатной части в ЗУП. Неважно, откуда - из УПП, ЕРП, КА2. А то ведь релиз УПП с изменениями НДФЛ до сих пор не вышел ☺️
Почти всех, кто пришёл, я обновлял/обновляю/буду обновлять сам. У меня странная, необъяснимая любовь к обновлениям. Хотя, большинство моих программистов тоже всё это умеют - научил. Особенно когда волна переходов в ЕРП шла, с 2.4 на 2.5 без вариантов.
Часть пришедших - владельцы УПП, которым нормально жилось на релизе годовалой давности (или старше). Изменения в законодательстве они или ручками переносили (вроде мелких, про сч/ф), или их они не касались, или отражали какие-то операции вручную (вроде 97.КР). А тут хлобысь - и НДС, и НДФЛ.
Технология обновления УПП на много релизов давно отработана, поэтому проблем не возникло. В том числе - если надо обеспечить работу на какой-нибудь старой версии платформы.
Другая часть обратившихся - владельцы ЕРП, КА2, УТ. Некоторые вели РУ рядом, в БП, а зарплату - в ЗУПе, поэтому особо не переживали за обновления. А тут раз - и НДС. Кто-то сейчас на 2.5.12 (этим повезло, переход на 2.5.17 несложен), некоторые на 2.4 (тут предстоит Большой Скачок на 2.5). Тут нельзя не похвалить политику релизов ЕРП и его младших - с 2.4 на 2.5 можно перейти за очень небольшое количество шагов. А с 2.5.12 на свежий 2.5.17 - вообще за один.
Ну а самые интересные - те, кто работал на чём-то очень старом, перелопаченном и в хлам кастомизированном. Например, на БП1, из которой своими руками сделали УХ (по функциональности). Пришли те, кто ранее заказывал у меня расширенный аудит конфигурации - не только технический, но и с обсуждением перспектив использования. Возможное изменение ставок НДС я указывал, как Чёрного Лебедя - риск, который может серьёзно осложнить жизнь в старой, необновляемой конфигурации.
Да, и сильно активизировались переходы зарплатной части в ЗУП. Неважно, откуда - из УПП, ЕРП, КА2. А то ведь релиз УПП с изменениями НДФЛ до сих пор не вышел ☺️
👍8
Хотел снять короткое видео про обновление ERP, а получилось длинное. Прошу прощения.
https://youtu.be/7F02eshCKh4
https://vk.com/video-208482299_456239471
https://youtu.be/7F02eshCKh4
https://vk.com/video-208482299_456239471
YouTube
Про обновление ERP
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
🔥8👍2
флАвтоЗадачи 202609231228.cfe
137.1 KB
Решение с самой несчастной судьбой из всех, что я делал - "Автозадачи".
С одной стороны, это самое лучшее и полезное из всего, что я сделал на платформе 1С. Это реальная автоматизация управления. Сколько-нибудь приличных конкурентов я не видел.
С другой стороны - я уделял очень мало внимания его распространению, объяснению и т.д.
Поэтому решение так и осталось непонятным и малоиспользуемым. Единицы дошли до его широкого внедрения, но уж какие они после этого отзывы писали... Видно, что дошёл смысл решения и его польза.
Основное описание - https://vk.com/@-208482299-avtozadachi
Видео с демонстрацией возможностей:
1. https://vk.com/video-208482299_456239480
Из публичных упоминаний:
Статья о практике внедрения, написанная хорошим человеком - https://infostart.ru/pm/990710/
Ещё один человек упомянул тут - https://infostart.ru/pm/1889197/
С одной стороны, это самое лучшее и полезное из всего, что я сделал на платформе 1С. Это реальная автоматизация управления. Сколько-нибудь приличных конкурентов я не видел.
С другой стороны - я уделял очень мало внимания его распространению, объяснению и т.д.
Поэтому решение так и осталось непонятным и малоиспользуемым. Единицы дошли до его широкого внедрения, но уж какие они после этого отзывы писали... Видно, что дошёл смысл решения и его польза.
Основное описание - https://vk.com/@-208482299-avtozadachi
Видео с демонстрацией возможностей:
1. https://vk.com/video-208482299_456239480
Из публичных упоминаний:
Статья о практике внедрения, написанная хорошим человеком - https://infostart.ru/pm/990710/
Ещё один человек упомянул тут - https://infostart.ru/pm/1889197/
🔥13👍2👏1
Встретил тут канал со схожей тематикой - про 1С, но не для программистов.
Вдруг вам интересно.
Вдруг вам интересно.
Forwarded from Дневник 1с программиста
Как правильно поменять политику учета серий в 1С УТ
К нам обратились из торговой организации с проблемой, что программа 1С Управление торговлей не даёт провести реализацию. Ошибка касается остатков товара, которые на складе есть, но в документе они почему-то не видны. При анализе было обнаружено, что товар имеет маркировку, в базе ведется серийный учет, а сотрудник дополнительно сообщил, что с нового года у них внедрен на складе отбор товара с помощью терминала сбора данных и по требованию провайдера ТСД была изменена политика учета серий.
Надо отметить, что это как раз и явилось основной причиной. Ведь поступление серий товара было сделано по одной политике, а реализация идет уже по другой.
Очевидное решение - перепровести документы поступления не подходит. Программа не дает это сделать, потому что в каждой цепочке документов есть заказ, счет-фактура и приходный ордер на товары.
При этом, провайдер ТСД просто "слился", во франчайзи сказали, что будут думать. Руководство было реально в панике. Директор сказал, что готовы оплатить создание новой базы и перенос всех настроек и остатков. То есть, по сути, сделать новое внедрение.
Итак, моё решение. Я сделал второй склад и применил к нему политику учёта серий, которую настроил провайдер ТСД. На ордерный склад, где лежал весь остаток товара, вернул прежнюю политику. Далее, показал менеджерам документ "Перемещение товара" и как он работает. После того, как мы переместили все серии товара на новый склад, заработал наконец-то, ТСД и отгрузки пошли в штатном порядке.
Нет, нет и нет, я не хочу этой статьей сказать, что я самый умный. Решение со вторым складом пришло не сразу - это раз, кроме этого, переместить товар получилось не сразу. Да и повозится с анализом данных пришлось.
Хочу добавить, что в последних версиях УТ11 стало все НУ ОЧЕНЬ заморочено. Статусы на документ, политики учета, ордера, статусы ордеров.... Разбираемся - мы ж специалисты!
Дневник 1С программиста
К нам обратились из торговой организации с проблемой, что программа 1С Управление торговлей не даёт провести реализацию. Ошибка касается остатков товара, которые на складе есть, но в документе они почему-то не видны. При анализе было обнаружено, что товар имеет маркировку, в базе ведется серийный учет, а сотрудник дополнительно сообщил, что с нового года у них внедрен на складе отбор товара с помощью терминала сбора данных и по требованию провайдера ТСД была изменена политика учета серий.
Надо отметить, что это как раз и явилось основной причиной. Ведь поступление серий товара было сделано по одной политике, а реализация идет уже по другой.
Очевидное решение - перепровести документы поступления не подходит. Программа не дает это сделать, потому что в каждой цепочке документов есть заказ, счет-фактура и приходный ордер на товары.
При этом, провайдер ТСД просто "слился", во франчайзи сказали, что будут думать. Руководство было реально в панике. Директор сказал, что готовы оплатить создание новой базы и перенос всех настроек и остатков. То есть, по сути, сделать новое внедрение.
Итак, моё решение. Я сделал второй склад и применил к нему политику учёта серий, которую настроил провайдер ТСД. На ордерный склад, где лежал весь остаток товара, вернул прежнюю политику. Далее, показал менеджерам документ "Перемещение товара" и как он работает. После того, как мы переместили все серии товара на новый склад, заработал наконец-то, ТСД и отгрузки пошли в штатном порядке.
Нет, нет и нет, я не хочу этой статьей сказать, что я самый умный. Решение со вторым складом пришло не сразу - это раз, кроме этого, переместить товар получилось не сразу. Да и повозится с анализом данных пришлось.
Хочу добавить, что в последних версиях УТ11 стало все НУ ОЧЕНЬ заморочено. Статусы на документ, политики учета, ордера, статусы ордеров.... Разбираемся - мы ж специалисты!
Дневник 1С программиста
👍9🔥1
Год назад проводил мероприятие - неожиданные встречи.
Встречался онлайн с любым подписчиком канала, который этого пожелает.
Темы - на выбор человека.
С одним старым знакомым поговорили за жизнь, и он решил поработать с нашим отделом в качестве заказчика.
Был собственник франча, поделились друг с другом опытом организации сопровождения.
Был ИТ-директор крупного холдинга, обсудили особенности перехода на ЕРП.
Был человек из большого, не 1Сного IT - обсудили их проекты и разработки.
Если не всех вспомнил, прошу прощения - год прошёл.
Так вот, думаю повторить - вас стало сильно больше за год, вдруг ещё есть желающие.
Поговорим в течение 1 часа, совершенно бесплатно. На любые темы, в которых я потенциально могу быть чем-то полезен.
Количество встреч ограничу, конечно - пусть будет одна штука в неделю. Иногда больше, иногда - меньше.
Встреча ни к чему не обязывает ни вас, ни меня. Со стороны Бита буду только я. С вашей - кто угодно.
Если интересно - пишите на IEBelokamentsev@1cbit.ru или в личку @Ivan_Belokamentsev договоримся о времени и дате.
В письме в двух словах черкните, о чём хотите поговорить и кто вы по должности.
Встречался онлайн с любым подписчиком канала, который этого пожелает.
Темы - на выбор человека.
С одним старым знакомым поговорили за жизнь, и он решил поработать с нашим отделом в качестве заказчика.
Был собственник франча, поделились друг с другом опытом организации сопровождения.
Был ИТ-директор крупного холдинга, обсудили особенности перехода на ЕРП.
Был человек из большого, не 1Сного IT - обсудили их проекты и разработки.
Если не всех вспомнил, прошу прощения - год прошёл.
Так вот, думаю повторить - вас стало сильно больше за год, вдруг ещё есть желающие.
Поговорим в течение 1 часа, совершенно бесплатно. На любые темы, в которых я потенциально могу быть чем-то полезен.
Количество встреч ограничу, конечно - пусть будет одна штука в неделю. Иногда больше, иногда - меньше.
Встреча ни к чему не обязывает ни вас, ни меня. Со стороны Бита буду только я. С вашей - кто угодно.
Если интересно - пишите на IEBelokamentsev@1cbit.ru или в личку @Ivan_Belokamentsev договоримся о времени и дате.
В письме в двух словах черкните, о чём хотите поговорить и кто вы по должности.
👍15
Первая встреча прошла, отлично поговорили. Про УПП, ЕРП, самостоятельный переход, стоимость проектов и много чего ещё.
Узнал, что поддержка УПП будет до 27 года - я честно думал, что до 26. Не уследил, что сроки изменились. Получается, можно не спешить.
Хотя, с такими релизами УПП, как сейчас выходят, любимую конфигурацию уже жалко, если честно.
Узнал, что поддержка УПП будет до 27 года - я честно думал, что до 26. Не уследил, что сроки изменились. Получается, можно не спешить.
Хотя, с такими релизами УПП, как сейчас выходят, любимую конфигурацию уже жалко, если честно.
👍12
Попалась задача по производительности старой доброй УТ 10.3. Не то, чтобы прям попалась - сам напросился посмотреть.
Вообще, мы с клиентом не работаем, пока только разговариваем, но есть подписанный NDA, и в базу можно смотреть. Клиент сказал, что база сильно тормозит, уже 2 месяца смотрит текущий подрядчик и админы (со стороны железа), но прогресса нет. Собрались делать свёртку базы.
Я предложил поглядеть, чего база тормозит, а свёртку пока не делать - она необратимая. Ну и на производительность не особо влияет.
Поглядел, оказалось всё просто: доработки списков были не оптимально сделаны. В толстом клиенте был такой класс доработок - вывести что-нибудь в списке документов, форме выбора справочника или вообще в таблице товаров. Остатки товаров, статус документа, % отгрузки и т.д.
Сейчас, в тонком клиенте и с динамическими списками, такие доработки делать проще, и производительность не страдает. А в толстом клиенте надо было крепко думать, выполняя такие доработки.
Иначе был риск заставить базу делать несколько десятков, сотен или тысяч запросов в секунду. Например, если для каждой выводимой строки номенклатуры выполнять запрос к остаткам.
А тут доработки были сразу в 10-20 формах. Наиболее используемых, разумеется. Каждая доработка сама по себе не страшна, потеря производительности незаметная. Но умножаем на количество форм и количество активных пользователей - получаем клинч базы.
Дал клиенту рекомендации, ссылку на видео (где рассказывал приёмы оптимизации таких доработок). Они пошли к текущему подрядчику, чтобы тот исправил. Потом спрошу, чем кончилось.
Вообще, мы с клиентом не работаем, пока только разговариваем, но есть подписанный NDA, и в базу можно смотреть. Клиент сказал, что база сильно тормозит, уже 2 месяца смотрит текущий подрядчик и админы (со стороны железа), но прогресса нет. Собрались делать свёртку базы.
Я предложил поглядеть, чего база тормозит, а свёртку пока не делать - она необратимая. Ну и на производительность не особо влияет.
Поглядел, оказалось всё просто: доработки списков были не оптимально сделаны. В толстом клиенте был такой класс доработок - вывести что-нибудь в списке документов, форме выбора справочника или вообще в таблице товаров. Остатки товаров, статус документа, % отгрузки и т.д.
Сейчас, в тонком клиенте и с динамическими списками, такие доработки делать проще, и производительность не страдает. А в толстом клиенте надо было крепко думать, выполняя такие доработки.
Иначе был риск заставить базу делать несколько десятков, сотен или тысяч запросов в секунду. Например, если для каждой выводимой строки номенклатуры выполнять запрос к остаткам.
А тут доработки были сразу в 10-20 формах. Наиболее используемых, разумеется. Каждая доработка сама по себе не страшна, потеря производительности незаметная. Но умножаем на количество форм и количество активных пользователей - получаем клинч базы.
Дал клиенту рекомендации, ссылку на видео (где рассказывал приёмы оптимизации таких доработок). Они пошли к текущему подрядчику, чтобы тот исправил. Потом спрошу, чем кончилось.
🔥16👍6👏1🤡1
Два месяца 25-го года выдались напряжёнными. Наверное, как у всех в нашем деле, особенно кто проектами занимается.
У нас проектов несколько, они делятся примерно на 2 категории:
1. Когда мы (мой отдел) полностью делаем проект - наш менеджер, РП, программисты;
2. Когда мы на подряде у кого-то из соседей по Биту.
По первой категории, т.е. полностью свои проекты:
1. Запустили в январе ЗУП, вынесенный из УПП. С усложнениями проект был - не только выносили, но и организации объединяли;
2. Запускаем КА2 из УНФ, без полного переноса, только по кусочкам;
3. Запускаем 1С Аренду из УПП;
4. Готовимся скоро запускать ещё два ЗУПа из УПП;
5. Готовимся скоро запускать ЗУП 3 из ЗУПа 2;
6. Готовимся скоро запускать зарплатный кусок КА2, переход из УПП;
7. Делаем два проекта перехода из УПП в ЕРП (запуск в январе 26);
8. Делаем два проекта перехода из УПП в КА2.
Вторая, категория, когда "управление проектом" не у нас. Беру только те, где доля нашего участия от 50% и выше. Бывает, что несколько человек из отдела сидит на одном таком проекте.
1. Был большой запуск ЕРП из БП3+УТ11, частями - сначала упр.учёт (осенью), потом регл.учёт (в январе). Проект наших соседей по Биту;
2. Помогали запустить ЕРП из УПП, с января. Проект тех же наших соседей по Биту;
3. Помогали запустить часть ЕРП, чтобы работала в постоянном обмене с УПП, запуск был в феврале. Проект нашего партнёра, не из Бита. И такое бывает :)
Наверное, этот пост должен вам объяснить, почему я пишу в этом году пореже :)
У нас проектов несколько, они делятся примерно на 2 категории:
1. Когда мы (мой отдел) полностью делаем проект - наш менеджер, РП, программисты;
2. Когда мы на подряде у кого-то из соседей по Биту.
По первой категории, т.е. полностью свои проекты:
1. Запустили в январе ЗУП, вынесенный из УПП. С усложнениями проект был - не только выносили, но и организации объединяли;
2. Запускаем КА2 из УНФ, без полного переноса, только по кусочкам;
3. Запускаем 1С Аренду из УПП;
4. Готовимся скоро запускать ещё два ЗУПа из УПП;
5. Готовимся скоро запускать ЗУП 3 из ЗУПа 2;
6. Готовимся скоро запускать зарплатный кусок КА2, переход из УПП;
7. Делаем два проекта перехода из УПП в ЕРП (запуск в январе 26);
8. Делаем два проекта перехода из УПП в КА2.
Вторая, категория, когда "управление проектом" не у нас. Беру только те, где доля нашего участия от 50% и выше. Бывает, что несколько человек из отдела сидит на одном таком проекте.
1. Был большой запуск ЕРП из БП3+УТ11, частями - сначала упр.учёт (осенью), потом регл.учёт (в январе). Проект наших соседей по Биту;
2. Помогали запустить ЕРП из УПП, с января. Проект тех же наших соседей по Биту;
3. Помогали запустить часть ЕРП, чтобы работала в постоянном обмене с УПП, запуск был в феврале. Проект нашего партнёра, не из Бита. И такое бывает :)
Наверное, этот пост должен вам объяснить, почему я пишу в этом году пореже :)
👍17❤1💯1