Боль планирования в 1С

26.10.17

Функциональные - Бюджетирование и планирование

Что не так с планированием в 1С, почему и есть ли свет в конце тоннеля?

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

Если же вы испытали, или сейчас испытываете боль планирования в 1С, то давайте поболеем вместе, и попробуем выздороветь.

Статья написана, в основном, про УПП. Часть проблем удалось снять в ERP (заодно добавив новых), но боль осталась и по сей день.

Итак, поехали.

Обеспеченность

Первое и главное – как узнать, какие потребности обеспечены, а какие нет? Вот есть у меня заказы покупателей, или план продаж, или внутренние заказы, или заказы на производство – это мои потребности (точнее, покупателей). Есть запасы на складах, есть заказы поставщикам (закупка и переработка), есть планы закупок в конце концов – это мои ресурсы. Как ответить на вопрос – какие потребности удовлетворены, а какие нет? Ну и сразу сопутствующий вопрос – а чего не хватает? Что надо купить или произвести?

Простого ответа на этот вопрос нет в конфигурациях 1С. Хотя задача, на первый взгляд, тривиальная – возьми все ресурсы, распредели по потребностям, и будет тебе счастье. Вроде должен несложный отчет помочь, но его нет.

Я, как наверняка и вы, такой отчет делал. Для грубого ответа на поставленный вопрос отчет вполне сгодится, но кому нужен грубый ответ? У людей же бизнес, от ответа на вопрос зависит расход денег, неликвиды, кассовые разрывы, отношения с покупателями.

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

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

Потом происходит очередной кошмар – меняется бизнес-процесс, заодно и штатная структура, подразделения перемешиваются, складов становится вдвое больше, появляются планы производства, придумывается новый документ типа «Заявка покупателя», который предшествует заказу покупателя и т.д. Короче, причин для смерти Отчета становится столько, что он перестает сопротивляться.

Помощник планирования

Часть вопросов расчета обеспеченности в УПП решает «Помощник планирования». Я раньше очень любил этот инструмент, в него заложены классные идеи и подходы. Но, увы, он так и остался прототипом для решения реальных задач бизнеса. Долго рассказывать по дедушку-помощника не буду, при желании вы без труда найдете массу информации про его ограничения (бутылочное горлышко, например).

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

Второй важный недостаток – помощник вообще не дает ответа на вопрос «за счет чего обеспечено?». Он только выдает, чего не хватает, т.е. отвечает на сопутствующий вопрос, пропуская главный.

Резервирование и размещение

В определенный момент я обратил внимание на резервирование (на складах) и размещение (в заказах поставщикам и внутренних заказах). Вот оно, казалось бы, то что мне и надо! Резервирование дает однозначный ответ на главный вопрос – за счет чего обеспечена потребность. Там прям написано – железяку с этого склада возьми и иди с миром, а деревяшка приедет через неделю от поставщика по заказу № 23123.

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

Мелькнула надежда в виде документа «Резервирование товаров» - он ведь позволяет за один присест провести корректировку всех резервов. Освободить, перенести, занять более актуальные ресурсы – т.е. нивелирует все недостатки, описанные выше

Надежда продержалась долго, даже переросла в несколько проектов. Я, а наверняка и вы, делали такие штуковины, типа автопересчета резервов или большого АРМ по управлению резервами, чтобы Большой Диспетчер мог перекидывать резервы туда-сюда, снимать и ставить, учитывая потребности и все изменения реальной жизни. Манипуляции этого человека легко укладываются в документ «Резервирование товаров», с  точки зрения программиста он просто прекрасен – почти прямая запись в регистры идет.

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

Плюс тот же недостаток, что и в помощнике планирования – резервированием, в т.ч. АРМом, нужно постоянно пользоваться. Заходить в него, следить за ним, чего-то нажимать. Большой Диспетчер, опять же, нужен.

Самое поганое, что резервирование, как таковое, мне не было нужно. Я просто хотел узнать, что у меня обеспечено, чем оно обеспечено, а чего мне не хватает. А резервирование – это «мое, не трогать!», т.е. целый бизнес-процесс. Который, к тому же, на производственных предприятиях любят нарушать ребята на складе (где нет крутых WMS-систем). Был такой один, душой болел за производство, и при поступлении дефицитных деталей просто прятал их в уголок, «чтобы треклятые продавцы не забрали». Какое уж тут резервирование.

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

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

Аналоги

Тема настолько избитая, что уже наверное и не поднимается на конференциях. Годы идут, воз с места не движется.

Везде, где я работал с планированием, нужно было учитывать аналоги.

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

Указать взаимозаменяемость таких деталей можно и в УПП, и в ERP. Где-то эта информация даже учтется – например, при подборе материалов в отчет производства за смену. А я хочу при планировании и расчете обеспеченности, чтобы не покупать деталь, аналог которой у меня уже есть на складе.

В реальной жизни учет аналогов, конечно, сложнее.

Например, заменяемость может зависеть от клиента – одному подходит разная сталь, другому кровь из носу надо 40Х. Одному подходит сделанная в Китае, другой – патриот.

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

Бывает и сложнее. Например, когда делают упаковку полимерную, берут пленку подходящей ширины. Если клиент заказал рулон упаковки шириной 1000 мм, мы берем ширину 1100 мм, срезаем по краям по 50 мм (чтоб ровненько было), и все счастливы. Но сложилась ситуация, когда у нас нет пленки шириной 1100, а есть 1105 мм. Мы, конечно, не паримся и берем ее – просто отходов будет чуть больше. А можем взять 1110 мм, можем 1115 мм, можем даже 1300 взять, если горящий заказ и клиент из любимых.

Получается сложносочиненная формула расчета аналога. Каждая пленка – отдельная номенклатура, т.е. сочетаний для каждой пленки будут десятки. Но применимость сочетаний аналогов зависит от контекста – ширины изделия, которую нам надо получить. Добавим сюда, что пленки одной ширины бывают разными по своим свойствам, но могут заменять друг друга при определенных условиях. А еще рулон шириной 1000 мм можно разрезать пополам, чтобы выполнить заказ, где требуется ширина 450 мм. А еще его на три части можно порезать, и не обязательно одинаковые.

Короче, ад адский. А хочется, чтобы это как-то учитывалось, и ответ на вопрос «обеспечены мы или нет?» система дала.

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

Гибкость

Точнее, не гибкость, а ее отсутствие. Я, наверное как и вы, много раз слышал фразу – надо не 1С подстраивать под свои процессы, а свои процессы под 1С. Когда работал во франче, сам любил этот лозунг повторять клиентам.

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

Я к УПП очень хорошо отношусь, но решение для планирования выбирать-то в ней особо не из чего. Это даже не гибкость, а Великое Ничто, вакуум, поле чистое. Можно же утверждать, что Ничто – гибкое? Конечно. В этом и прелесть УПП, за это его и люблю, особенно в части планирования – делай что хочешь, хуже не будет.

Например, приделать к УПП закуп по методу ББВ (барабан-буфер-веревка) – задача несложная, даже обычным программированием, безо всяких там универсальных инструментов. И ничего в системе испортить невозможно своими доработками, т.к. работа-то в Великом Ничто делается. Это как ядерную бомбу на полпути от Марса до Венеры взорвать – солнечная система ничего не заметит.

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

Тем не менее, начинание полезное, есть из чего выбрать. Я пообщался с разработчиками, задал им вопросы о своей боли, получил неутешительные ответы – боль этой таблеткой не лечится. Отчета по обеспеченности нет, аналогов нет, добавлять или изменять способы обеспечения – только через конфигуратор, учесть в схемах обеспечения свои объекты метаданных не получится.

Не знаю, как вам, а мне в таком сравнении ближе Великое Ничто.

Свои объекты метаданных

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

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

Если добавлен не прям объект, а реквизит, например, то еще куда ни шло – он хотя бы в отборе помощника планирования появится.

В контексте самодельных объектов даже хорошо, что в 1С такое планирование. Представьте себе, было бы оно как РАУЗ – цельное, проверенное, работающее, самодостаточное. Многие из нас рисковали жизнью, добавляя вообще совершенно новый документ движения товаров, и включали его во все цепочки РАУЗ? Или добавляли реквизиты в номенклатуру, которые бы влияли на решение СЛАУ? А планирование не такое – ему без разницы, что вы куда добавили, все равно мимо пройдет.

Резюме

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

После этой фразы я полюбил планирование, как класс задач.

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

С другой стороны, фраза окрылят внедренца – давай, действуй, на этом поле нет законов, правил, правильных и не правильных решений! Твори!

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

И все из-за этой фразы. Твори, каждый раз твори, потому что типового решения нет.

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

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

Но не пользователями едиными внедрения богаты, там есть еще и программисты 1С. Пользователь – он же только на кнопки нажимать умеет, да и то ошибается все время. Программист же – и код напишет, и схему компоновки, и схемы хранения данных знает, и метаданные видит, и цель планирования знает, и процессы знает… Понимаете?

Типового решения задачи планирования для пользователя – нет, а для программиста – есть. Должно быть типовое решение задачи планирования для программиста. Инструмент,

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

В общем, нужен инструмент, созданный программистами для программистов.

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

Конвертация почти полностью удовлетворяет критериям, которые я предъявил системе планирования:

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

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

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

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

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

Теперь, собственно, главный вопрос: а где инструмент для настройки планирования и расчета обеспеченности, похожий по своей гибкости и возможностям на конвертацию данных, бюджетирование, и монитор ERP?

Типовые конфигурации 1С – они, вроде, для «учета и управления». Основа управления – план и контроллинг. Контроллинг худо-бедно построить можно. Построить правильное, современное планирование, умеющее быстро реагировать на изменение среды, учитывающее особенности российского подхода к учету,  – практически невозможно.

Оттого и крен во фразе «учет и управление» на первое слово. А хочется, чтобы был баланс, одно ведь из другого следует.

Все изложенное является личным мнением автора, разумеется.

P.S. Ну и от себя спрошу, очень интересно, может знаете – а кто принимал решения, как инструмент в УПП или ERP делать правильным, а какой – неправильным? Почему бюджетирование – правильное, а планирование – неправильное

См. также

SALE! 20%

Автоматический заказ поставщику в 1С: загрузка прайсов и анализ цен поставщиков для УТ 10.3, УТ 11, КА2, УНФ, УПП, ERP, Розница 2

Бюджетирование и планирование Оптовая торговля Розничная торговля Логистика, склад и ТМЦ Анализ продаж Платформа 1С v7.7 Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Розница 2 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

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

28500 22800 руб.

21.04.2017    90169    105    39    

190

ФинОфис - контроль и управление финансами

Бюджетирование и планирование Управляемые формы Конфигурации 1cv8 Россия Управленческий учет Платные (руб)

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

20000 руб.

20.12.2017    49526    14    7    

85

ФинОфис (модуль Казначей)

Бюджетирование и планирование Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

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

25000 руб.

10.04.2020    21185    10    12    

35

ФинОфис (модуль Табула)

Бюджетирование и планирование Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Табула – это табличный редактор с формулами, разработанный на платформе 1С. Табула обеспечивает простоту создания таблиц, ранее доступную лишь в Excel.

25000 руб.

26.02.2019    96781    84    106    

217

ФинОфис (модуль Консолидатор)

Бюджетирование и планирование Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

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

25000 руб.

19.11.2019    25353    16    2    

38

ФинОфис (модуль Процессы)

Управление бизнес-процессами (BPMS) Бюджетирование и планирование Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Процессы – это конструктор бизнес-процессов и маршрутов согласования. Модуль встраивается в конфигурации 1С.

25000 руб.

10.04.2020    27044    3    4    

22

Вебинар-практикум "Управление IT-бюджетом" 27 марта 2024 г.

Бюджетирование и планирование Управление проектами Управление ИТ-департаментом Платные (руб)

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

7400 руб.

06.03.2024    610    1    0    

1
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. pm74 199 26.10.17 14:37 Сейчас в теме
вот тут есть универсальная система правда сам не пробовал
2. 1c-intelligence 12771 26.10.17 14:41 Сейчас в теме
3. pm74 199 26.10.17 14:55 Сейчас в теме
(2) Вобще проектирование логики любых сложных систем (в том числе планирование) - требует высокого уровня абстракции . Каким образом это реализовать в 1С - это вопрос. Я в свое время "споткнулся" об это на проектировании системы управления производственным процессом и после размышлений и "курения" всяких мануалов пришел вот к этому. Народ правда не особо оценил, возможно потому , что примеры привел слишком примитивные, но к сожалению других пока нет.
5. 1c-intelligence 12771 26.10.17 18:31 Сейчас в теме
(3)
Вобще проектирование логики любых сложных систем (в том числе планирование) - требует высокого уровня абстракции


Наверное, 1С также отвечает. Мы ж из Челябинска, нас такой ерундой не запугаешь.
6. pm74 199 26.10.17 21:26 Сейчас в теме
(5)
Теперь, собственно, главный вопрос: а где инструмент для настройки планирования и расчета обеспеченности, похожий по своей гибкости и возможностям на конвертацию данных, бюджетирование, и монитор ERP

если у вас есть какое то решение , или идеи поделитесь ими с сообществом
drug_com; +1 Ответить
8. 1c-intelligence 12771 26.10.17 21:42 Сейчас в теме
(6) поделюсь, конечно. Готовлюсь.
drug_com; +1 Ответить
4. 1c-intelligence 12771 26.10.17 18:28 Сейчас в теме
(1) покурил, тема прикольная, но применительно к задачам из статьи - совсем не то. Просто цель другая, а соответственно - и подходы.
Но за ссылку - спасибо!
7. sereginseregin 22 26.10.17 21:29 Сейчас в теме
Боль планирования....

Очень узкая постановка проблемы. Рассматриваю проблему несколько шире:

Нормирование (что, в какой пропорции, за какой срок?):
1. Номенклатурные справочники;
2. Спецификации, Курсы обмена, Замены (Пропорции и сроки);

Планирование (кто, кому, когда, в каком объеме?):
3. Справочник Потребителей и Поставщиков (подразделений, цехов, складов);
4. Заявки потребителей (Крайняя ожидаемая дата поставки, обьем продуктов)
5. Графики поставщиков (Начальная планируемая дата поставки, объем ресурсов)

Управление (кто МОЛ-исполнитель, в каком месте (по какому счету), в каком объеме?):
6. Реестр договоров с Контрагетами и МОЛ;
7. Реестр мест хранения, счетов;
8. Требование Потребителя (МОЛ-получатель, место (счет) получения, объем продукта)
9. Приказ (резерв) Поставщика (МОЛ-отправитель, место (счет) отправки (отпуска), объем ресурса);

Исполнение (факт расхода и прихода):
10. Справочник паспортов номенклатуры, партий;
11. Документ расхода отправителя (фактическая дата);
12. Документ прихода получателя (фактичекая дата);

Вот тут pain, про SQL и регистры тока мечтаю...
9. 1c-intelligence 12771 26.10.17 21:43 Сейчас в теме
(7) список выглядит внушительно, но я не все понял.
Можете поподробнее рассказать, о какой задаче речь?
10. pm74 199 26.10.17 21:46 Сейчас в теме
15. sereginseregin 22 26.10.17 23:53 Сейчас в теме
(9) Вопрос
Какие потребности удовлетворены, а какие нет?
- простым ответом про наличие или отсутствие материала на складе пользователей не удовлетворяют. Сразу допы прут: А когда прибудет от поставщика? А сколько уже оплачено? А сколько из производства вернулось по браку? Главное, КТО ВИНОВАТ?
Короче, чтобы удовлетворить пользователя, необходимо расуручивать полную обеспеченность по заказу про:
- Готовую продукцию, ожидающую отгрузку
- Незавершенное производство, ожидающее выпуск
- МПЗ, ожидающее списания в производство
- Обязательства поставщиков по поступлениям товаров и услуг
- Денежные средства, ожидающие оплаты поставщикам
- Обязательства заказчиков по платежам за продукцию
А это, в одном запросе всю базу надо охватить, сотни справочников, документов и регистров. Сотни подзапросов для каждого случая (деньги по одним алгоритмам, материалы по другим).

Смысл же (7) в том, что независимо от деятельности:
- Управление денежными средствами;
- Расчеты с поставщиками и покупателями;
- Управление работниками;
- Эксплуатация оборудования;
- Управление запасами;
- Производство;
- Управление готовой продукцией;

Общие вопросы пользователя остаются одинаковые:
- Какие не исполнены приказы, требования? Кто виноват? Что делать?
- Какие просрочены графики, заявки? Кто виноват? Что делать?
- Какие не соблюдены нормы, стандарты? Кто виноват? Что делать?

Раз вопросы одинаковые, есть надежда (идея), что в ERP не нужны СОТНИ справочников, документов и алгоритмов, их можно сократить до дюжины (12 перечисленных) универсальных. Тогда и обеспеченность собирать можно.

Идея простая, но сходиться вот никак не хочет.
Надеюсь, "Боль планирования" Вас больше не мучит!
19. 1c-intelligence 12771 27.10.17 06:42 Сейчас в теме
(15) ИМХО, вы перечислили неправильные вопросы.
Такие вопросы задают люди, которых интересуют не реальные проблемы предприятия, а мышиная возня с женским подходом (вопрос "кто виноват?" их выдает).
И вопросы эти - не для того, чтобы решить проблемы, а чтобы отсрочить их решение. Пользователи ведь знают, что вы не ответите.
20. sereginseregin 22 27.10.17 09:06 Сейчас в теме
(19)
Кто виноват?

Ответить просто. В каждом документе имеется ссылка на ответственное подразделение, ответственных лиц, на крайний случай, автора документа.
Что делать?
- Эт... был сарказм ;-)
Что не так с планированием ...., почему и есть ли свет в конце тоннеля?

Вот к этому хотел прибавить "как глубока кроличья нора". Что свет есть, но это еще не выход...
21. 1c-intelligence 12771 27.10.17 09:08 Сейчас в теме
(20)
Ответить просто. В каждом документе имеется ссылка на ответственное подразделение, ответственных лиц, на крайний случай, автора документа.


а если нет документа :)

Есть заказ покупателя, но нет заказа поставщику, который бы его обеспечил?
67. sereginseregin 22 03.11.17 21:23 Сейчас в теме
(21)
Есть заказ покупателя, но нет заказа поставщику

- Потребность в поставщике описана в спецификации
Кто виноват:
- Ответсвенный за исполнение заказа покупателя, если не составил заявку (с крайней датой поставки) на ответвенного по поставщикам в соответствии со спецификацией
- Ответвенный по поставщикам, если не сформировал или нарушил график поставки по поступившим заявкам
68. 1c-intelligence 12771 07.11.17 07:40 Сейчас в теме
(67)
Ответсвенный за исполнение заказа покупателя, если не составил заявку (с крайней датой поставки)

вам не кажется, что эта схема отдает излишней бюрократией? Человек принес потребность, которую надо простыми внутренними усилиями превратить в деньги. А мы заставляем его какую-то заявку составлять. Он итак все описал в заказе покупателя.
69. sereginseregin 22 07.11.17 11:09 Сейчас в теме
(68)То что внутри системы это выглядит бюрократией, не означает что пользователь с этой бюрократией обязан столкнуться. Если "Он итак все описал в заказе покупателя", возможно и заявка поставщику может сформироваться автоматически, незаметно для пользователя. Другой вопрос, некорректно смешивать в базе данных заказ покупателя и заявку поставщику.
70. 1c-intelligence 12771 07.11.17 11:18 Сейчас в теме
(69) так кто в итоге виноват, если заказ покупателя есть, а заказа поставщику нет?
возможно и заявка поставщику может сформироваться автоматически

программист?
71. sereginseregin 22 07.11.17 12:07 Сейчас в теме
(70)
программист?

На Ваше усмотрение, что в автоматическую заявку вставите.
72. 1c-intelligence 12771 07.11.17 12:24 Сейчас в теме
(71) теперь вернемся к теме статьи.
Что из перечисленного есть в УПП или ERP?
Возможен ли сценарий, когда заказ покупателя есть, а заказа поставщику нет, и непонятно кто в этом виноват?
73. sereginseregin 22 07.11.17 13:42 Сейчас в теме
(72)Все что я выше перечислил конкретно к УПП или ERP отношения не имеет. Проблема не в отсутствии системы, а глубже, в отсутствии понимания, какая это должна быть система.
Возможен ли сценарий, когда заказ покупателя есть, а заказа поставщику нет, и непонятно кто в этом виноват
На предприятии такая ситуация невозможна. Крайний всегда найдется...
74. pm74 199 07.11.17 14:12 Сейчас в теме
(68)
Человек принес потребность, которую надо простыми внутренними усилиями превратить в деньги. А мы заставляем его какую-то заявку составлять. Он итак все описал в заказе покупателя.

мне кажется заявка от потребителя ( прод. менеджера) все таки нужна в виде заказа или какого-то задания на закуп (для снабженца) , во первых сроки поставки по одному заказу покупателя могут отличаться , во вторых ( если возможно) по этой заявке отслеживается состояние выполнения в третьих поступления на склад обосабливаются по каждой заявке
75. 1c-intelligence 12771 08.11.17 07:59 Сейчас в теме
(74) если у вас типовая конфигурация от 1С - да, конечно, заявка нужна.
76. TODD22 18 08.11.17 18:36 Сейчас в теме
(75)А если не типовая то где указываются сведения относящиеся к заявке на закупку?
77. 1c-intelligence 12771 08.11.17 19:26 Сейчас в теме
(76) можете пояснить, что это за сведения такие? Есть заказ покупателя, есть заказ поставщику. Заявка на закуп какую роль, кроме бюрократической играет?
78. TODD22 18 09.11.17 06:44 Сейчас в теме
(77)
Есть заказ покупателя, есть заказ поставщику.

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

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

Ярлыки развешивать довольно простое занятие. А вот как определить что есть "бюрократия", а что производственная необходимость? Где та черта где мы можем сказать что вот это "бюрократия", а вот это правильно выстроенный процесс? Есть какие то измеримые, универсальные критерии?
79. 1c-intelligence 12771 09.11.17 07:25 Сейчас в теме
(78) правильно я понял, вы каждый раз, после каждого заказа покупателя эту длинную цепочку проходите? Вот которую вы описали?
Я встречал такие цепочки, но они делались при первой сделке с поставщиком, включая аудит.
Требования к материалам, условиям закупки и т.д. - они разве не постоянны? Срок, если он не абсолютный, а относительный (30 дней, например) - вроде тоже константа.
[IS-QUOTE]Где та черта где мы можем сказать что вот это "бюрократия", а вот это правильно выстроенный процесс? Есть какие то измеримые, универсальные критерии?
[/IS-QUOTE]
Универсального ничего в жизни нет. Есть общепринятые. Например, прибыль. Или проход (в ТОС) - скорость генерации денег.

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

Типичный пример - согласования. Зачем согласовывать каждую поставку материала или детали, если мы покупаем ее 10 раз в месяц, не меняя тех.требований, КД и т.д.?
Сроки проверять? Так они в договоре прописаны.
Условия оплаты проверять? Так они в договоре прописаны.
Фин.состояние поставщика проверять? Так подключите сервис и проверяйте сами, или сделайте подписку на изменение состояния.

Вроде бы - чего такого? Ну согласовывают люди, жалко что ли.
Жалко - они снижают скорость генерации денег.

Если без согласования от точки заказа покупателя до точки отгрузки пройдет 10 дней, а с согласованием - 15 (это еще оптимистично), то скорость генерации денег системой падает в 1.5 раза. Это - влияние синхронной бюрократии.

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

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

Хотя, убрать согласования в асинхронный поток - это полумера. Еще лучше - сделать асинхронным снабжение. Это тоже ТОС.
80. TODD22 18 09.11.17 07:37 Сейчас в теме
(79) Теория хорошая... но всё мимо.
81. 1c-intelligence 12771 09.11.17 07:41 Сейчас в теме
(80) это все из личной практики стратегического управления.
82. genayo 09.11.17 08:20 Сейчас в теме
(81) Ваш опыт не воспроизводим на большинстве предприятий, к сожалению.
83. 1c-intelligence 12771 09.11.17 08:50 Сейчас в теме
(82) еще как воспроизводим, вы сами в этом убедитесь. Наберитесь терпения, мы в самом начале пути.
84. genayo 09.11.17 09:04 Сейчас в теме
(83) На большинстве уже действующих предприятий воспроизводим? Сильное заявление...
85. 1c-intelligence 12771 09.11.17 09:07 Сейчас в теме
(84)
Сильное заявление

спасибо, рад что понравилось.
86. genayo 09.11.17 09:22 Сейчас в теме
(85) Видно, что тренинги личностного роста принесли результат.
88. 1c-intelligence 12771 09.11.17 10:39 Сейчас в теме
(86) результат приносит все - и тренинги, и книги, и фильмы, и общение, и практика. Все вместе формирует личность во всех ее проявлениях.
P.S. на тренингах по личностному росту не бывал.
87. TODD22 18 09.11.17 09:41 Сейчас в теме
(81)
это все из личной практики стратегического управления.

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

Где то работает система "Заказ покупателя - Заказ поставщику", где то появляются дополнительные элементы в виде "заявка на закупку", согласование и тд. Это определяется потребностью предприятия или процесса, а не субъективным ощущением того как должно быть правильно(по ТОСу и тд).

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

По поводу "Да я сто раз так делал". То же довольно сомнительно предприятия разные, процессы разные.
Из личного опыта то же могу рассказать как пришёл на одно предприятие где меня просили сделать одну систему. Думал да что там делов то на 2-3 месяца, к тому же с похожими предприятиями я уже работал. А потом я только 6 месяцев вникал в происходящее и это при том что я работал внутри организации по 8 часов и имею опыт и знания по анализу процессов и тд. Но когда приходили "сторонние" консалтеры, которые обещали сделать чудеса за 2-3 месяца я то понимал чего стоят их обещания.

Или проход (в ТОС) - скорость генерации денег.

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

Синхронно - когда вмешиваются и тормозят (как в описанном вами случае).

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

Зависит от суммы закупки. Где то до 1 млн рублей фин дир не глядя подписывает заявки, а где то и 100К надо согласовать в 3х кабинетах.
Еще лучше - сделать асинхронным снабжение. Это тоже ТОС.

Первая буква в слове ТОС это "теории". В теории всегда всё просто и легко. На практике иначе.

Сроки проверять? Так они в договоре прописаны.
Условия оплаты проверять? Так они в договоре прописаны.
Фин.состояние поставщика проверять? Так подключите сервис и проверяйте сами, или сделайте подписку на изменение состояния.

Так нет у нас никаких договоров. Мы не знаем кто у нас поставщиком будет. У нас 30 поставщиков на конкурсной основе.
89. 1c-intelligence 12771 09.11.17 10:48 Сейчас в теме
(87)
Практикующий врач никогда не ставит диагноз не видя пациента и не зная истории болезни

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

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

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

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

Расскажете о своей практике применения ТОС? Особенно о негативной. Позитивной полно итак, а негативной мало.
Так нет у нас никаких договоров. Мы не знаем кто у нас поставщиком будет. У нас 30 поставщиков на конкурсной основе.

а с этими 30 поставщиками разве нет договоров?
90. TODD22 18 09.11.17 11:28 Сейчас в теме
(89)
тут два момента. Во-первых - ставят. И весьма успешно.

Мой опыт работы в медицинском центре(больнице) и общение с врачами говорит об обратном. Ни один врач по описанию с чужих слов не ознакомившись с результатами анализов и историей болезни диагнозы не ставит и лечение не назначит потому что он за это ответственность несёт(вплоть до уголовной) и дорожит своей репутацией профессионала. Одни и те же симптомы могут быть у сотни различных заболеваний. И любой практикующий врач знает как пациенты любят придумывать себе симптомы и болезни про которые они смотрели в сериале "Доктор Хаус".
Как в анекдоте: "Объявление в приемной врача: «Просим пациентов не обмениваться симптомами. Это очень затрудняет диагноз»."

Бюрократия - это ошибка в фундаменте.

То есть заявка на закупку это априори бюрократия?

для управления рисками есть другая дисциплина, она так и называется - управление рисками.

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

Какие договора? Это "пул" поставщиков отбор из которых выполняется в процессе согласования закупки. И это не всегда "лучшие" условия исходя из рационального подхода(вроде самой низкой цены и тд).
Расскажете о своей практике применения ТОС?

К любой теории я отношусь как к "теории" по этому не создаю культа из "модных" учений. Беру какие то приёмы если они мне интересны.

Позитивной полно итак, а негативной мало.

О провалах никто не любит рассказывать. Все любят "истории успеха", наверное по этому и мало. Вы много пишите о провалах в соотношении с историями успеха, а они же были? Если учитывать что обычно выстреливает 10-15% из всех попыток. Где то конечно больше, где то меньше. Но в целом на одну удачную попытку приходится с десяток менее удачных.

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

скоринг это хорошо, но пока что не везде применимо. Нейросеть к сожалению пока не научилась выезжать на производство поставщика и проверять наличие необходимого у него оборудования и возможностей выполнить взятые на себя обязательства. Но когда нибудь наверное так и будет. Сам сейчас делаю похожую систему, на анализе данных и обучении нейросети. Но там не про риски... там немного другое, хотя то же прогнозирвоание.
91. 1c-intelligence 12771 09.11.17 11:53 Сейчас в теме
(90)
Мой опыт работы в медицинском центре(больнице) и общение с врачами говорит об обратном

ок, у нас разный опыт общения с врачами.
То есть заявка на закупку это априори бюрократия?

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

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

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

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

еще раз - мы с вами не бизнес-тренеры и не бизнес-консультанты. Мы 1Сники. Вы не делаете вид, что вы бизнес-консультант, я не делаю вид, что я бизнес-консультант. Мы занимаемся одним и тем же делом. Говорим как коллеги, равные друг другу, делимся опытом, помогаем друг другу.
Что там делают бизнес-тренеры и бизнес-консультанты - нам не важно. Важно только, что у них плохо получается - значит, они нам не конкуренты. Мы не пойдем по их пути, потому что этот путь ошибочен.
92. TODD22 18 09.11.17 12:05 Сейчас в теме
(91)
Правильно понял, что вы не пробовали применять что-нибудь из ТОС на практике?

Беру какие то приёмы если они мне интересны.


вы не уникальны - все так делают, вы не отличаетесь от остальных.

Так я вроде и не говорил что я отличаюсь от остальных.
конечно.

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

Заявка это не только способ избавится от риска, это так же элемент планирования и управления.
Есть способы сложнее, меньше влияющие на скорость продаж.

А откуда взялось предположение что это влияет на скорость продаж?
93. 1c-intelligence 12771 09.11.17 12:12 Сейчас в теме
(92)
А откуда взялось предположение что это влияет на скорость продаж?

из практики. Вы же проверить можете.
Если продажа и с заявкой, и без заявки занимает одинаковое время - то влияния нет.
В магазине я пришел лампу ближнего света купить, она в наличии. Продажа заняла 3 минуты, отдал 400 рублей.
Потом пришел за пыльником шруса, его нет в наличии. Составили договор на поставку, через 4 дня привезли. Отдал те же 400 рублей, но продажа заняла 4 дня = 5760 минут.
Скорость генерации денег сами видите как отличается.

В первом случае снабжение и продажа работают асинхронно, во втором - синхронно. Асинхронно - это потому, что они знали, что я приду за лампочкой, и заблаговременно ее купили. Это по ТОС.
94. TODD22 18 09.11.17 12:28 Сейчас в теме
(93)Так мы живём в реальном мире, а не в теории. Мы не можем всегда держать 100% товаров на складе. И за наличие товара на складе мы должны чем то заплатить.
А это неликвид, замороженная в товаре "оборотка", площади хранения и тд. На одной скорости "генерации" мы так далеко не уедем. Наверное надо брать в расчёт все элементы и считать экономическую целесообразность ускорения "генерации", а то как бы не получилось что будем рубль по 90 копеек продавать. Вчера в один магазин заходил весь неликвид по закупочной выложен на прилавке.
Скорость генерации денег сами видите как отличается.

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

Это и до ТОС было. Всегда держали на под рукой ходовой товар, а то что редко продаётся под заказ. Для того кто пробовал что то сам продавать это и без ТОСа вполне очевидно.
96. 1c-intelligence 12771 09.11.17 12:38 Сейчас в теме
(94) это и ТОСу вполне очевидно, что всем это очевидно. Там так и написано, в книге - мы ничего нового не придумали, просто здравый смысл.
А это неликвид, замороженная в товаре "оборотка", площади хранения и тд.

про это в ТОС много написано, там все эти вопросы решены. Почитайте, вам понравится, даже если применять не будете.
95. genayo 09.11.17 12:29 Сейчас в теме
(93) Но и в том, и в другом случае они свои деньги получили, а то, какие затраты были понесены продавцом в 1 и 2 случае, это вопрос интересный:) Но это так, лирика. Всеже ждем решения "боли планирования"
97. 1c-intelligence 12771 09.11.17 12:43 Сейчас в теме
(95) скорость генерации денег - это внутреннее свойство системы. Еще его можно назвать "эффективность", если добавить затраты, которые вы отметили.
Имея систему со скоростью генерации денег 1 млн рублей в день, вы за месяц генерируете 30 млн. рублей.
Имея систему со скоростью генерации денег 10 млн рублей в день, вы за месяц генерируете 300 млн рублей.

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

Но вы правы, оффтоп пошел. Про ТОС напишу отдельно.
98. TODD22 18 09.11.17 12:46 Сейчас в теме
(97)
Имея систему со скоростью генерации денег 1 млн рублей в день, вы за месяц генерируете 30 млн. рублей.
Имея систему со скоростью генерации денег 10 млн рублей в день, вы за месяц генерируете 300 млн рублей.

Осталось дело за малым, поднять продажи в 10 раз... делов то....
99. 1c-intelligence 12771 09.11.17 13:07 Сейчас в теме
(98) вот ровно про это я и написал выше:

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


надо не поднять продажи, а ускорить систему, их генерирующую. Надо внутрь системы смотреть, а не вокруг нее - на рынки или новые технологии. Внутри все скрыто.

Вполне возможно, что в бюрократии, той же заявке. Это надо наблюдать и измерять.
100. TODD22 18 09.11.17 13:35 Сейчас в теме
(99)Это в теории так хорошо звучит.
На практике откройте магазинчик, на маленький островок в ТЦ надо 100 - 200 к рублей, вот там на собственных деньгах проверьте состоятельность теории. А именно увеличьте в 10 раз скорость генерации без увеличения продаж(количества продаж, среднего чека и тд).
Что будете генерировать если количество покупателей в единицу времени не увеличилось?
101. 1c-intelligence 12771 09.11.17 13:58 Сейчас в теме
(100)
Что будете генерировать если количество покупателей в единицу времени не увеличилось?

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

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

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

Вы несколько раз уже повторили, что это все в теории. Вы же понимаете, что так оно и будет, пока вы не попробуете?
Не нужно рисковать большими чужими деньгами. Есть миллион дешевых процессов, на которых можно попробовать ТОС без риска для бизнеса. Если получится - взять что-то более крупное. И т.д.
102. TODD22 18 09.11.17 14:07 Сейчас в теме
(101)
Вы же понимаете, что так оно и будет, пока вы не попробуете?

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

Так в этом вся соль. Как раз ограничением и является количество этих самых покупателей в единицу времени.
105. 1c-intelligence 12771 09.11.17 20:57 Сейчас в теме
(102)
Как раз ограничением и является количество этих самых покупателей в единицу времени.

мне кажется, главное - себя не обманывать.
Я много - МНОГО - раз видел, как компании тратят массу сил, средств и времени на снятие такого ограничения - количества клиентов. Внедряют CRM, создают отдел маркетинга, делают красивый сайт с интернет-магазином.

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

Вот вам примеры из моей практики:
1. раньше согласовывали КД на детали один раз, при аудите поставщика, потом кто-то придумал согласовывать КД каждый раз, по каждой поставке. Это + 2 дня;
2. раньше согласовывали протокол цен на год, и не меняли их, потом кто-то придумал согласовывать цену каждый раз, по каждой поставке. Хотя цена не менялась. Это + 1-2 дня.
3. раньше согласовывали и сдавали юристам договор один раз в год, потом кто-то придумал согласовывать, подписывать на бумаге и сдавать юристам каждую спецификацию. Это + 1-7 дней.
4. раньше конкурентный лист составляли раз в год, потом кто-то придумал делать это на каждую закупку. Номенклатура та же, поставщик тот же, цена и условия лучшие (их же в начале года выбрали), но вот чот как-то так. Это + 1 день.
5. где-то посередине, когда уже был п.3, спецификацию согласовывал только начальник закупок. Потом решили добавить всю братию - юристов, бухгалтеров, главного инженера, финансистов. Это еще + 1-3 дня.

Это все - вариации на тему внутренней заявки. Безопасность закупа не изменилась. Как случались косяки, так и продолжили случаться.

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

А клиенты продолжали ЖДАТЬ.

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

Разумеется, я не утверждаю, что у вас также. Просто воочию видел, как люди ошибаются, думая, что надо только клиентов побольше привлекать, что в этом главная трудность.
103. genayo 09.11.17 14:35 Сейчас в теме
(97) Это понятно, я к тому, что не зная конкретное предприятие нельзя сделать однозначный вывод, что увеличение прохода без изменения других, не известных нам, параметров приведет к увеличению прибыли.
104. 1c-intelligence 12771 09.11.17 20:36 Сейчас в теме
(103) мне кажется, важно не искать отговорки вроде "не зная конкретное предприятие, нельзя сделать однозначный вывод, ...".
Если есть предприятие, и там есть 1С, и оно не маленькое, значит что? Там есть программист 1С.
А он знает предприятие. А мы знаем его. Вместе разберемся.
А то сидим все по углам, огрызаемся друг на друга, типа "да вы не знаете, какие тут у меня условия", а дело на месте стоит.

ТОС - это фреймворк. Как платформа 1С. Сам по себе ТОС ничего не стоит, как и платформа 1С.

Есть такие проблемы, которые "голым 1С" не решить. Для некоторых нужен ТОС, для некоторых metadata.js, для некоторых Scrum, для некоторых яндекс clickhouse и т.д.

Хочешь решать проблемы - придется разбираться во фреймворках. Это, наверное, всем очевидно.

Захотел красивую диаграмму - пошел курить Google Charts, например. Покурил, попробовал на маленьком примере, встроил в продакшн.

Захотел снабжение улучшить - пошел курить ТОС. Покурил, попробовал на маленьком примере, встроил в продакшн.

Не пускают в снабжение - так снабжение и в ИТ-отделе есть. Я на сис.админах тренировался, на закупке компов (расскажу в статье про ТОС).
106. genayo 09.11.17 21:57 Сейчас в теме
(104) Есть такие проблемы, которые можно решить только сменой топ-менеджмента/собственников компании. Если в этом может помочь ТОС или Scrum хотелось бы о таких случаях услышать...
107. 1c-intelligence 12771 09.11.17 22:19 Сейчас в теме
(106) да я не об этом. Вы вот посмотрите на свои комментарии со стороны. И на комментарии Боряна заодно.

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

Мы ж не такие. Мы - инженеры, наше дело - создавать.

Про то, как поможет ТОС или Scrum, конечно расскажу - все что знаю. И жду, что вы расскажете все, что знаете. А что не знаете - попробуете, и расскажете. И я попробую, что не знаю, и расскажу.
108. genayo 10.11.17 08:01 Сейчас в теме
(107) Странно вы комментарии читаете. Я нигде не говорил, что предлагаемые вами подходы не работают в принципе. Я говорил, что у любых теорий есть ограничения в применимости, и об этих ограничениях нужно знать, и их учитывать. И как из этого у вас получилось, что я предлагаю ничего не делать мне не понятно.
Статьи ваши безусловно полезны, читаю их с интересом. Если не хотите видеть от меня комментариев с критикой - их не будет.
109. 1c-intelligence 12771 10.11.17 08:14 Сейчас в теме
(108) ладно, давайте забудем. На эмоции был.
110. l1ike 10.11.17 08:43 Сейчас в теме
(93)
Как-то странно вы считаете...
В первом случае, к времени продажи нужно еще, как минимум, прибавить время нахождения лампы на складе, а во втором, вычесть время, когда была оплата поставщику за ШРУС, только после этого получится "Скорость генерации денег"
111. 1c-intelligence 12771 10.11.17 09:08 Сейчас в теме
(110) давайте переформулируем в "скорость генерации дохода", если так проще.
Зачем нам в скорости генерации дохода время нахождения ШРУСа на складе?
112. TODD22 18 10.11.17 09:26 Сейчас в теме
(111) Простой случай.

Никаких заказов нет.
В понедельник купили ШРУС, в пятницу продали ШРУС. Какая "скорость генерации дохода" на продаже ШРУСа?

Сложнее случай:
В понедельник получили заказ на ШРУС, получили предоплату, в четверг получили на руки запчасть, в пятницу отдали ШРУС. Какая скорость генерации?

Условие: До тех пор пока не выполнили обязательства перед покупателем никакой доход мы ещё не получили.
113. 1c-intelligence 12771 10.11.17 09:37 Сейчас в теме
114. TODD22 18 10.11.17 09:40 Сейчас в теме
(113)Нет. Знал бы не спрашивал :)
Мне же нужно понять методику расчета скорости генерации денег. Она я так понимаю измерима и должна как то рассчитываться.
119. l1ike 10.11.17 11:27 Сейчас в теме
(114)
По Детмеру -
Производительность по денежному потоку (Throughput, Т) – это скорость, с которой система в целом генерирует доход в результате продаж. Строгое математическое определение для T и его связь с I и ОЕ вытекает из выражения баланса денежного потока:
CF (Cash Flow, денежный поток) = T – ОЕ ± I, где T – ОЕ = NP (Net Profit, чистая прибыль).
В динамическом виде это же выражение имеет вид:
dCF/dt = T – ОЕ – dl/dt,
где t – время. Его можно прочесть как «приращение денежного потока равно скорости генерации дохода минус операционные расходы и изменение связанного капитала компании»
121. 1c-intelligence 12771 10.11.17 21:15 Сейчас в теме
(119) есть отличия от моего примера?
Только я не учитывал I и OE, считая их постоянными в обоих примерах.
120. 1c-intelligence 12771 10.11.17 21:14 Сейчас в теме
(112)
В понедельник купили ШРУС, в пятницу продали ШРУС. Какая "скорость генерации дохода" на продаже ШРУСа?

А как посчитаете, так и будет. Я считал скорость конкретной цепочки - от появления покупателя до получения всех его денег. В вашем примере, если покупатель пришел в пятницу, и через 5 минут ушел со ШРУСом, то стоимость ШРУСа поделить на 5 минут.

Во втором вашем случае стоимость ШРУСа надо поделить на неделю.

Фишка в том, что формула прохода - абстрактная, это "скорость генерации единиц цели". Что есть единица цели - решаете вы, как архитектор системы.

Покупка ШРУСа - это не часть процесса генерации дохода. Это полностью переменные расходы в данном случае, и они одинаковы в любой момент покупки - хоть за день до продажи, хоть за неделю.

Об этом хорошо сказал Таичи Оно (цитату привел Голдратт в своей статье "Стоя на плечах гигантов"), отвечая на вопрос, чем занимается Toyota: "Все, что мы делаем, - это смотрим на время от момента поступления заказа от клиента до момента, когда мы получаем деньги. И мы работаем над сокращением этого времени".
Цель ТОС - ровно та же. Сократить время от появления потребности до ее удовлетворения и получения денег.

Разумеется, там еще хороший багаж методов, как держать низкий уровень запасов, как рассчитывать их уровни, и т.д.
115. l1ike 10.11.17 10:34 Сейчас в теме
(111)
Просто у меня как-то возникло немного другое восприятие ТОС.
Держа ШРУС на складе, получим ли мы от этого больше денег? - на первый взгляд не очевидно.
Станем ли мы расходовать меньше денег? - вроде бы нет.
Уменьшатся ли связанные деньги внутри системы? - однозначно увеличатся.
116. TODD22 18 10.11.17 10:36 Сейчас в теме
(115)
Держа ШРУС на складе, получим ли мы от этого больше денег? - на первый взгляд не очевидно.

Мы говорим про "больше денег" или про "скорость генерации" ?
117. l1ike 10.11.17 11:13 Сейчас в теме
(116)
В моем представлении "Скорость генерации" - это "Больше денег" в единицу времени. Не?
118. TODD22 18 10.11.17 11:16 Сейчас в теме
(117)
В моем представлении "Скорость генерации" - это "Больше денег" в единицу времени. Не?

Наверное.
Но когда вы пишите "Держа ШРУС на складе, получим ли мы от этого больше денег?" без указания "в единицу времени" то это сбивает с толку. Без указания в "единицу времени" можно предположить что "больше" от времени не зависит.
Видимо не правильно вас прочитал.
122. 1c-intelligence 12771 10.11.17 21:22 Сейчас в теме
(115)
Держа ШРУС на складе, получим ли мы от этого больше денег? - на первый взгляд не очевидно.

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

Я пошел в магазин, потому что в автосервисе ШРУС под заказ ждать 2 недели, а в магазине 4 дня. Автосервис сэкономил на складе, но не получил моих денег.

Насчет денег в системе переживать не стоит. Если работает ТОС, то при той же стоимости склада радикально меняется качество его наполнения, в результате чего увеличивается проход. Много хороших, качественных примеров из личной практики Голдратта есть в его книге "Выбор" - очень рекомендую, если не читали.
124. l1ike 13.11.17 08:57 Сейчас в теме
(122)
Насчет денег в системе переживать не стоит.

Всегда ли?
Вот давайте предположим, что у нас вместо лампочки, допустим, рама от Лэнд-Крузера. Рама от Лэнд-Крузера стоит чуть дешевле, чем сам Лэнд-Крузер, и как-бы желающих менять раму каждый день не так уж и много.
Я это к чему все... Было бы замечательно, если бы вы явно обозначали в каком контексте вы ведете рассуждения, какие границы применимости у данных методов, какие параметры вы принимаете как не существенные в конкретном примере.
Просто получается, когда люди примеряют ваши примеры к области деятельности отличной от вашей они получают некоторый когнитивный диссонанс, и выходит - "Фуфло все ваши теории"
125. 1c-intelligence 12771 13.11.17 10:19 Сейчас в теме
(124)
Всегда ли?

нет, разумеется. Я подумал, что вы хорошо знаете ТОС и особенности его применения.

Держать или не держать раму крузера на складе - это предмет вычислений на основе фактического потребления.
128. l1ike 13.11.17 12:51 Сейчас в теме
(125)
Я с вами не спорю. Просто пытаюсь добавить "глубины" вашим рассуждениям. Давайте приведу аналогию...
Допустим, по радио передача "Вопрос адвокату", звонит человек и спрашивает: "У меня умер очень дальний и очень богатый родственник. Могу я претендовать на наследство?". Там обычно рассуждают, - "вот если к тому что вы сказали присутствует факт1 и факт2, то вы получите такой результат, если факт3 и факт4 то другой". Что на мой взгляд позволяет сторонним слушателям делать выводы по поводу своих ситуаций. Жизнь - она чуть более многогранна.
129. 1c-intelligence 12771 13.11.17 12:58 Сейчас в теме
(128) так у нас другой формат.
Для сторонних слушателей - публикации. В публикациях авторы стараются раскрыть тему.
Тут - комментарии, где конкретный человек задает вопрос конкретному человеку. В комментарии обычно не раскрывается контекст и тема. Если я предполагаю, что вы знаете ТОС, то пишу, исходя из этого предположения. И пишу конкретно вам.
126. TODD22 18 13.11.17 11:49 Сейчас в теме
(124)
Просто получается, когда люди примеряют ваши примеры к области деятельности отличной от вашей они получают некоторый когнитивный диссонанс, и выходит - "Фуфло все ваши теории"

Как в прошлом совладелец "автомастерской на 2 поста + автомойки" и магазинчика по продаже автосигнализаций, автоакустики, предпусковых подогревателей, лампочек :) , жидкостей, масла и прочего доп оборудования который я вместе с товарищем организовал с нуля. И ещё несколько малых бизнесов организовывал в строительстве и ещё в паре направлений. Платил зарплату, аренду, покупал товары, инструмент, оборудование, брал под реализацию товары, нанимал сотрудников, сидел без денег, ходил по судам, налоговым и тд
Все эти теории о том как надо торговать ШРУСами по ТОС у того кто ими торгует не вызывает диссонанса. Это просто теория 99.9% который для любого практика "баян".

Диссонанс вызывает уверенность людей, которые не продавали ШРУСы, в том что их теории работают и та лёгкость с которой они раздают советы по торговле ШРУСами. Откуда такая уверенность что нужно руководствоваться этой теорией, а не какой то другой, теорий вокруг десятки! Да и очевидны они.

(122)
Ну и остальные клиенты будут приходить к нам, когда узнают, что ШРУС в наличии.
Я пошел в магазин, потому что в автосервисе ШРУС под заказ ждать 2 недели, а в магазине 4 дня. Автосервис сэкономил на складе, но не получил моих денег.

Это заблуждение про ШРУСы в наличии. И надо смотреть сколько он сэкономил и сколько он мог бы заработать, вроде как сэкономить 1000 руб или заработать 500 руб разница вполне очевидна.

Фишка в том, что формула прохода - абстрактная

Именно, а деньги из которых нужно платить зарплату, аренду и тд они реальные. И их можно даже в руках подержать, если конечно получится заработать.
А затраты на покупку ШРУСа одинаковы как при покупке заранее, так и при покупке под заказ.

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

Насчет денег в системе переживать не стоит.

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

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

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

Держать или нет раму от крузера это не "предмет вычисления" на основе фактического потребления. А предположение о том как и когда она будет потреблена или продана. Покупать что либо на склад с целью "вычислить" на основе фактического потребления это верный путь к "затоварке" складов. Вычислить то что нашу раму никто не потребляет это уже посмертная регистрация свершившегося факта(читай потерянных денег). Так же как и узнать о том что из десяти рам мы за год продали одну, а могли бы продать 25 рам от Калины и заработать те же деньги. Если я не понимаю как я продам товар(или потреблю материал) и за какое время то я его не стану покупать, жизнь научила, без всяких книжек, после первого закупа товара. Да и обычно на практике "вычисляют" закупки и товарные остатки от планируемого потребления(продаж), а не от фактических потребления прошлого периода.
127. 1c-intelligence 12771 13.11.17 12:04 Сейчас в теме
(126) вроде все правильно пишете, только выхода не видно и вывод не ясен.

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

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

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

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

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

Или просто утверждаете, "что все это неправильно"? В смысле жизнь неправильно устроена.
130. l1ike 13.11.17 13:00 Сейчас в теме
(126)
Теорию знать никогда лишним не будет. Человек нашел ответы на свои вопросы, возможно вы найдете ответы на свои.
131. l1ike 13.11.17 13:11 Сейчас в теме
(126)
В основном, конечно, наибольший эффект все теории дают на предприятиях с большим числом составляющих и решают они проблемы немного другого характера, чем те которые возникают у малых предприятий.
134. sereginseregin 22 16.11.17 10:18 Сейчас в теме
(79)
Лично мое мнение - такие длинные цепочки генерируют обслуживающие подразделения, которые не способны качественно выполнять свои обязанности. В данном случае качественно - это асинхронно.

А можно вернуться к Заявке?
Как заявка по Вашему тормозит скорость генерации денег?
Типичный пример - согласования. Зачем согласовывать каждую поставку материала или детали, если мы покупаем ее 10 раз в месяц,
Т.е. Вы в какой-то момент ранее сообщили поставщику устной или письменной Заявкой, что собираетесь покупать деталь 10 раз в месяц, Подписали с поставщиком договор. И поставщик вам гарантировал поставку.
А если Поставщику устной или письменной Заявкой ничего не сообщали, договора с поставщиком нет, то и риски что на 10 поставке Вы не получите товар вовремя ложатся на Вас.
135. 1c-intelligence 12771 16.11.17 11:25 Сейчас в теме
(134)
Как заявка по Вашему тормозит скорость генерации денег?

вы же понимаете, как она тормозит. Пришел клиент, принес деньги, говорит дай товар. Без внутренней заявки вы можете отгрузить завтра. С внутренней заявкой получится только через 5 дней. Имея буфер на складе, вы можете отгрузить сейчас. Имея буфер на складе покупателя, вы можете отгрузить вчера.
Т.е. Вы в какой-то момент ранее сообщили поставщику устной или письменной Заявкой, что собираетесь покупать деталь 10 раз в месяц, Подписали с поставщиком договор. И поставщик вам гарантировал поставку.

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

в данном случае на вас ложатся риски за то, что вы наняли плохих юристов и снабженцев.
136. sereginseregin 22 16.11.17 16:15 Сейчас в теме
(135)
...вы же понимаете, как она тормозит...
Все равно не понял...:-) У Вас Заявка есть, но не привязана к конкретному Заказу. Видимо считаете выгоднее брать на себя эти риски.
да, в начале года мы согласовали цены, условия поставки, сроки исполнения и интегрировали наши системы, чтобы он узнавал о необходимости поставки раньше нас. Заодно прописали в договоре, что он должен иметь на складе 20 шт номенклатуры, которую нам поставляет.

Перефразирую:
1. Заранее подали заявку Поставщику о планах закупки (ориентировочные сроки и объемы)
2. Поставщик Выставил спецификацию цен и свои доп условия (Наверняка поставщик изменит цену, если регулярно откажетесь закупать детали)
3. Подписали договор с графиком (для сохранения уровня цен) приобретения у Поставщика деталей
4. По поступлению Заказа от Заказчика система автоматически формирует (возможно виртуальное) поручение Поставщику отгрузить на Ваш склад деталь.
5. Заказчику отгружается деталь из имеющихся на складе.

Все документы присутствуют. И геде тут Бюрократия тормозящая генерацию денег? У кого-то процесс синхронный, у кого-то асинхронный, но набор документов одинаковый и алгоритм расчета дефицита деталей будет одинаковый.

Другое дело, что в существующих системах недостаточно учтено реквизитов, чтобы предоставлять универсальные решения.
137. 1c-intelligence 12771 16.11.17 22:30 Сейчас в теме
(136) я уверен, что вы понимаете.
Мы изначально говорили о внутренней заявке, которую делают продавцы в адрес снабженцев. И которую потом обслуживающие подразделения согласовывают.

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

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

Как формируются эти остатки? Асинхронно. Их пересчитывает регламентное задание. Местами они считаются явно, кодом, об это позаботились разработчики типовой конфигурации - там, где это необходимо.

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

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

Хотите остатки? Считайте каждый раз, когда они вам нужны. Нажал пользователь в отчете "Сформировать" - считайте остатки. Открыл пользователь форму подбора - считайте остатки. И т.д.

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

Раньше, когда не нужно было считать остатки, отчет формировался 500 мс. Сейчас, когда надо считать остатки каждый раз, отчет стал формироваться 1500 мс.

Скорость генерации единиц цели, или проход, увеличился?

Вот еще другой пример. Мне надо заправлять картриджи для ч/б лазерных принтеров и МФУ. Я заключил договор с компанией. Суть договора проста: когда мне надо заправить картриджи, я им звоню/пишу, они в тот же день приезжают, забирают, заправляют, привозят на след.день вместе с бумажками (счет-фактура и акт).
Цены, сроки, условия - все в договоре написано.
Скорость генерации единиц цели - любое количество картриджей за сутки.

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

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

Это как замер производительности в 1С.
145. sereginseregin 22 19.11.17 15:26 Сейчас в теме
(137)
Мы изначально говорили о внутренней заявке, которую делают продавцы в адрес снабженцев. И которую потом обслуживающие подразделения согласовывают.

(138)
Что-то непонятно, вы точно оба про производственное предприятие говорите?


Структура внутренней заявки не сильно отличается от структуры внешней заявки (Потребитель, Поставщик, Цель, Ресурс, Объем цели, Объем ресурса)
1. Заявка Заказчика службе Реализации
2. Заявка службы Реализации на Производство
3. Заявка Производства в службу Обеспечения
4. Заявка службы Обеспечения к Поставщикам
5. Заявка Поставщика Финансовой службе по оплате
Составлять заявки можно и независимо друг от друга. В вашем случае служба Реализации без заявок Заказчика берет на себя ответсвенность - заранее планирует резерв ресурсов у внутренних служб и внешних поставщиков

Скорость генерации единиц цели - любое количество картриджей за сутки.
Будем реалистами. Поставщик не может обслужить бесконечное число картриджей за фиксированный период времени, значит в любой момент может передвинуть время обслуживания, значит никакая система не ответит, какой очередной картридж не будет обеспечен заправкой.
146. genayo 19.11.17 19:21 Сейчас в теме
(145) Вы что, реально так работаете? На каждый заказ вся цепочка полностью? А что производите, если не секрет?
149. 1c-intelligence 12771 19.11.17 21:38 Сейчас в теме
(145)
1. Заявка Заказчика службе Реализации
2. Заявка
3. Заявка
4. Заявка
5. Заявка

это все реальные заявки? Прям документы, бумажные или электронные?
Будем реалистами. Поставщик не может обслужить бесконечное число картриджей за фиксированный период времени

если будем реалистами, то будем реалистами - за 6 лет была одна задержка, когда понадобился барабан к очень древнему картриджу. Рассудили, что проще купить другой принтер.
152. genayo 19.11.17 22:06 Сейчас в теме
(149) Объемы печати какие были? Тысяч 50-60 в день регулярно печатали?
155. 1c-intelligence 12771 19.11.17 22:58 Сейчас в теме
(152) в таких единицах не измерял, если честно. Это важно?
Принтеров 20 наверное было, может 30 под конец.
157. genayo 20.11.17 07:51 Сейчас в теме
(155) Если всего 20 принтеров, то да, не важно в общем...
160. sereginseregin 22 20.11.17 12:19 Сейчас в теме
(149)
На каждый заказ вся цепочка полностью? А что производите, если не секрет?
Любое крупное производство с мелкими сериями.
(149)
это все реальные заявки? Прям документы, бумажные или электронные?
Все сложнее, разные службы, множество документов и подходов к их оформлению.

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

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

А чтобы система стала универсальной, она должна автоматизировать (грубо) декартово произведение 12 Этапов Х 10 Направлений Х 10 Направлений = 1200 Бизнес операций (очень грубо).

Для расчета обеспеченности по заказу необходимо анализировать все эти 1200 Бизнес операций.
162. 1c-intelligence 12771 20.11.17 21:21 Сейчас в теме
(160) вот, прошу прощения, типичный инженерно-исполнительный подход. Сказали сверху, что система должна учитывать
(финансы, закупки, производство, ...), перечень этапов (планирование, управление, исполнение, учет), ключевые вопросы (что?, когда?, сколько?, кто?...)

- все, побежали учитывать. Слава Богу, такой огромный балласт не поддается учету. Поэтому систем такого рода не существует.
165. genayo 20.11.17 21:49 Сейчас в теме
(162)Вот уж эта задача особо сложной не выглядит с технической точки зрения, а вот организационно конечно вызывает большие вопросы. Но, кстати, все эти заявки могут иметь смысл, если продажи, снабжение, производство, финансы - это все разные юридические лица. И такое встречалось на практике...
170. sereginseregin 22 20.11.17 23:08 Сейчас в теме
(162)
...инженерно-исполнительный подход...
Инженерный, потому-как все хотелось бы по полочкам разложить. Но ни как не исполнительский...
(165)
..все эти заявки могут иметь смысл, если продажи, снабжение, производство, финансы - это все разные юридические лица...
Достаточно чтоб это были разные службы со своими подслужбами на крупном предприятии.

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

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

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

ИМХО: Универсальная автоматизированная система контроля обеспеченности должна опираться на всю цепочку заявок и многих других документов, о существовании которых пользователи могут даже не догадываться и никогда в этой системе не регистрировать. Эти документы в упрощенном контроле могут генерироваться автоматически. Памяти на диске жалеть не стоит. Поддержка алгоритмов сбора отчета по обеспеченности для различных упрощенных случаев обойдется дороже.
138. genayo 16.11.17 22:49 Сейчас в теме
(136)(137) Что-то непонятно, вы точно оба про производственное предприятие говорите?
139. 1c-intelligence 12771 17.11.17 06:45 Сейчас в теме
(138) конечно, принципиальной разницы-то нет, на производственном циклы длиннее.
Я говорил про предприятие, которое производит железяки, собранные из множества деталей, часть которых оно производит само, часть заказывает у поставщиков.
141. genayo 17.11.17 07:47 Сейчас в теме
(139) В моем понимании источником заказа на закупку является план производства, и все длительные согласования (договора на поставку, тендеры, спецификации) происходят на этапе запуска изделия в производство. Если под это изделие уже заключены договоры на поставку комплектующих, то единственное согласование, которое нужно - это согласование финансового блока на включение финансирования в БДДС.
Возвращаясь к инструменту планирования - он должен уметь отвечать на вопросы более высокого порядка, чем обеспеченность уже принятых заказов.
142. 1c-intelligence 12771 17.11.17 07:51 Сейчас в теме
(141)
он должен уметь отвечать на вопросы более высокого порядка

какие, например?

Данная статья как раз о том, что нет ответов на элементарные вопросы.
144. genayo 17.11.17 07:56 Сейчас в теме
(142) Например, нам поступило одновременно 2 заказа, можем ли мы оба заказа взять, если нет, какой из них выгоднее, если надо взять оба, то какими уже запущенными заказами можно пожертвовать, и сколько нам это будет стоить и т.д...
148. 1c-intelligence 12771 19.11.17 21:36 Сейчас в теме
(144) лично мое мнение - вопрос неправильный, технический. Чтобы на него ответить, городится большой огород из технических расчетных систем. Раз уж у нас веточка про ТОС, то ТОС рекомендует не заниматься сложными расчетами, а заниматься реальными проблемами.
В вашем примере - надо понять, почему вообще мы считаем проблемой поступление сразу двух заказов.
150. genayo 19.11.17 21:58 Сейчас в теме
(148) Не считаем мы проблемой, а просто хотим знать ответы на эти вопросы. Видимо, пример слишком упростил, раз у вас экстраполировать не получилось...
Оставьте свое сообщение