(2) Вобще проектирование логики любых сложных систем (в том числе планирование) — требует высокого уровня абстракции . Каким образом это реализовать в 1С — это вопрос. Я в свое время «споткнулся» об это на проектировании системы управления производственным процессом и после размышлений и «курения» всяких мануалов пришел вот к . Народ правда не особо оценил, возможно потому , что примеры привел слишком примитивные, но к сожалению других пока нет.
Теперь, собственно, главный вопрос: а где инструмент для настройки планирования и расчета обеспеченности, похожий по своей гибкости и возможностям на конвертацию данных, бюджетирование, и монитор ERP
если у вас есть какое то решение , или идеи поделитесь ими с сообществом
— простым ответом про наличие или отсутствие материала на складе пользователей не удовлетворяют. Сразу допы прут: А когда прибудет от поставщика? А сколько уже оплачено? А сколько из производства вернулось по браку? Главное, КТО ВИНОВАТ?
Короче, чтобы удовлетворить пользователя, необходимо расуручивать полную обеспеченность по заказу про:
— Готовую продукцию, ожидающую отгрузку
— Незавершенное производство, ожидающее выпуск
— МПЗ, ожидающее списания в производство
— Обязательства поставщиков по поступлениям товаров и услуг
— Денежные средства, ожидающие оплаты поставщикам
— Обязательства заказчиков по платежам за продукцию
А это, в одном запросе всю базу надо охватить, сотни справочников, документов и регистров. Сотни подзапросов для каждого случая (деньги по одним алгоритмам, материалы по другим).
Смысл же (7) в том, что независимо от деятельности:
— Управление денежными средствами;
— Расчеты с поставщиками и покупателями;
— Управление работниками;
— Эксплуатация оборудования;
— Управление запасами;
— Производство;
— Управление готовой продукцией;
Общие вопросы пользователя остаются одинаковые:
— Какие не исполнены приказы, требования? Кто виноват? Что делать?
— Какие просрочены графики, заявки? Кто виноват? Что делать?
— Какие не соблюдены нормы, стандарты? Кто виноват? Что делать?
Раз вопросы одинаковые, есть надежда (идея), что в ERP не нужны СОТНИ справочников, документов и алгоритмов, их можно сократить до дюжины (12 перечисленных) универсальных. Тогда и обеспеченность собирать можно.
— Ответсвенный за исполнение заказа покупателя, если не составил заявку (с крайней датой поставки) на ответвенного по поставщикам в соответствии со спецификацией
— Ответвенный по поставщикам, если не сформировал или нарушил график поставки по поступившим заявкам
Ответсвенный за исполнение заказа покупателя, если не составил заявку (с крайней датой поставки)
вам не кажется, что эта схема отдает излишней бюрократией? Человек принес потребность, которую надо простыми внутренними усилиями превратить в деньги. А мы заставляем его какую-то заявку составлять. Он итак все описал в заказе покупателя.
(68)То что внутри системы это выглядит бюрократией, не означает что пользователь с этой бюрократией обязан столкнуться. Если «Он итак все описал в заказе покупателя», возможно и заявка поставщику может сформироваться автоматически, незаметно для пользователя. Другой вопрос, некорректно смешивать в базе данных заказ покупателя и заявку поставщику.
(72)Все что я выше перечислил конкретно к УПП или ERP отношения не имеет. Проблема не в отсутствии системы, а глубже, в отсутствии понимания, какая это должна быть система.
Возможен ли сценарий, когда заказ покупателя есть, а заказа поставщику нет, и непонятно кто в этом виноват
На предприятии такая ситуация невозможна. Крайний всегда найдется…
Человек принес потребность, которую надо простыми внутренними усилиями превратить в деньги. А мы заставляем его какую-то заявку составлять. Он итак все описал в заказе покупателя.
мне кажется заявка от потребителя ( прод. менеджера) все таки нужна в виде заказа или какого-то задания на закуп (для снабженца) , во первых сроки поставки по одному заказу покупателя могут отличаться , во вторых ( если возможно) по этой заявке отслеживается состояние выполнения в третьих поступления на склад обосабливаются по каждой заявке
(76) можете пояснить, что это за сведения такие? Есть заказ покупателя, есть заказ поставщику. Заявка на закуп какую роль, кроме бюрократической играет?
Мы не знаем кто будет поставщиком. У нас их десятки-сотни. По одному заказу покупателя на изделие я должен сделать заказы тридцати поставщикам на разные комплектующие(материалы) которых на конкурсной основе я должен выбрать из сотни. На основании заявки на закупку формируются запросы к поставщикам, составляется конкурентный лист который потом проходит разные этапы согласования(нач отдела, производство, фин отдел, СБ итд) и выбора поставщика. И вот когда поставщики выбраны, заявка на закупку одобрена мы делаем заказ поставщику. По крайней мере в крупных компаниях где мне доводилось работать было так.
можете пояснить, что это за сведения такие?
Требования к материалам, условиям закупки, срокам проведения закупки, ценовому диапазону, срокам и условиям хранения на складе и тд.
Заявка на закуп какую роль, кроме бюрократической играет?
Ярлыки развешивать довольно простое занятие. А вот как определить что есть «бюрократия», а что производственная необходимость? Где та черта где мы можем сказать что вот это «бюрократия», а вот это правильно выстроенный процесс? Есть какие то измеримые, универсальные критерии?
(78) правильно я понял, вы каждый раз, после каждого заказа покупателя эту длинную цепочку проходите? Вот которую вы описали?
Я встречал такие цепочки, но они делались при первой сделке с поставщиком, включая аудит.
Требования к материалам, условиям закупки и т.д. — они разве не постоянны? Срок, если он не абсолютный, а относительный (30 дней, например) — вроде тоже константа.
[IS-QUOTE]Где та черта где мы можем сказать что вот это «бюрократия», а вот это правильно выстроенный процесс? Есть какие то измеримые, универсальные критерии?
[/IS-QUOTE]
Универсального ничего в жизни нет. Есть общепринятые. Например, прибыль. Или проход (в ТОС) — скорость генерации денег.
Лично мое мнение — такие длинные цепочки генерируют обслуживающие подразделения, которые не способны качественно выполнять свои обязанности. В данном случае качественно — это асинхронно.
Асинхронно — это когда обслуживающие не вмешиваются, не тормозят основной процесс. Синхронно — когда вмешиваются и тормозят (как в описанном вами случае).
Типичный пример — согласования. Зачем согласовывать каждую поставку материала или детали, если мы покупаем ее 10 раз в месяц, не меняя тех.требований, КД и т.д.?
Сроки проверять? Так они в договоре прописаны.
Условия оплаты проверять? Так они в договоре прописаны.
Фин.состояние поставщика проверять? Так подключите сервис и проверяйте сами, или сделайте подписку на изменение состояния.
Вроде бы — чего такого? Ну согласовывают люди, жалко что ли.
Жалко — они снижают скорость генерации денег.
Если без согласования от точки заказа покупателя до точки отгрузки пройдет 10 дней, а с согласованием — 15 (это еще оптимистично), то скорость генерации денег системой падает в 1.5 раза. Это — влияние синхронной бюрократии.
Но я не говорю, что не надо всех этих согласований — пусть будут. Главное — правильно момент для них выбрать. Не синхронно, не во время сделки, не на пути денег через систему, а асинхронно — параллельно, не мешая процессу.
Вот вам гиперболическая метафора. Впихивать все согласования и проверки в процесс продажи — все равно, что выполнять расчет себестоимости каждый раз, когда пользователь нажимает «Сформировать» в отчете «Ведомость по учету МПЗ и затрат».
Хотя, убрать согласования в асинхронный поток — это полумера. Еще лучше — сделать асинхронным снабжение. Это тоже ТОС.
Практикующий врач никогда не ставит диагноз не видя пациента и не зная истории болезни
тут два момента. Во-первых — ставят. И весьма успешно.
Во-вторых — мы ведь про глубинные причины проблем, а не про конкретные болезни. Бюрократия — это ошибка в фундаменте. Как неправильное питание, отсутствие двигательной активности, плохой воздух и т.д. Любой врач, занимаясь лечением конкретной болезни, понимает, что причина — глубже. Но уже не говорит об этом, т.к. задолбался. Люди ведь хотят таблетку, а не образ жизни или мыслей.
Но мы-то с вами не такие.
Вообще меня всегда удивляет как бизнес-консультанты раздают советы
совершенно верно. Только мы-то с вами не бизнес-консультанты, правда? Мы 1Сники, мы внутри компании сидим.
Проход в ТОС учитывает что если не пройти согласования и проверку СБшниками контрагента можно вообще остаться без денег с невероятной скоростью?
для управления рисками есть другая дисциплина, она так и называется — управление рисками. Там много статистики, вероятностей, думать много надо. Сейчас нейросети этому научили — например, в банках, чтобы оценивать риски выдачи кредита. Когда думать не хочется — просто проверяют все подряд. Как вахтеры.
При чём необходимая часть.
это ж проверить можно, есть масса методов. Разумеется, если хочется эффективность повысить, балансируя ее с надежностью и безопасностью.
Первая буква в слове ТОС это «теории». В теории всегда всё просто и легко. На практике иначе.
Расскажете о своей практике применения ТОС? Особенно о негативной. Позитивной полно итак, а негативной мало.
Так нет у нас никаких договоров. Мы не знаем кто у нас поставщиком будет. У нас 30 поставщиков на конкурсной основе.
Мой опыт работы в медицинском центре(больнице) и общение с врачами говорит об обратном
ок, у нас разный опыт общения с врачами.
То есть заявка на закупку это априори бюрократия?
конечно. Способ защиты системы и людей от рисков.
Если для управления рисками мне нужна процедура согласования(заявки на закупку), а по ТОС нет, что делать?
по ТОС не заявка не нужна, а скорость генерации денег надо контролировать. И любые изменения проверять на предмет влияния на эту скорость.
Ключевой вопрос — было ли управление рисками. Появилась ли заявка в результате анализа, прогнозирования и опыта, оправдана ли она. Или она как-то сама появилась, на всякий случай.
Не забывайте, что заявка — это просто один из способов избавиться от риска. Не единственный. Но самый простой для тех, кто за риски отвечает. Есть способы сложнее, меньше влияющие на скорость продаж. Другой вопрос, если управлятели рисков об этом не думали, ну или вообще не знают. Тогда они убедительно убедят директора, что только так можно гарантировать безопасность.
Такое часто у сис.админов плохих бывает. Ему говорят — нужна информационная безопасность. Он говорит — все, запрещаем интернет, личные ящики, флешки, ютуб, вайфай — все запрещаем, и будет тогда безопасность.
Можно просто поверить на слово, и вдвое удлинить все процессы, усложнить жизнь всей компании. А можно использовать современные технологии, с каждым риском разобраться по-отдельности, применить точечные меры и т.д., и никому жизнь не портить.
К любой теории я отношусь как к «теории» по этому не создаю культа из «модных» учений. Беру какие то приёмы если они мне интересны.
вы не уникальны — все так делают, вы не отличаетесь от остальных. И я о том же говорю постоянно.
Правильно понял, что вы не пробовали применять что-нибудь из ТОС на практике?
ассказывают много теории «бизнес тренеры без бизнеса»
еще раз — мы с вами не бизнес-тренеры и не бизнес-консультанты. Мы 1Сники. Вы не делаете вид, что вы бизнес-консультант, я не делаю вид, что я бизнес-консультант. Мы занимаемся одним и тем же делом. Говорим как коллеги, равные друг другу, делимся опытом, помогаем друг другу.
Что там делают бизнес-тренеры и бизнес-консультанты — нам не важно. Важно только, что у них плохо получается — значит, они нам не конкуренты. Мы не пойдем по их пути, потому что этот путь ошибочен.
Правильно понял, что вы не пробовали применять что-нибудь из ТОС на практике?
Беру какие то приёмы если они мне интересны.
вы не уникальны — все так делают, вы не отличаетесь от остальных.
Так я вроде и не говорил что я отличаюсь от остальных.
конечно.
Тогда можно вообще упростить. Делать всё в одном документе «Заказ покупателю» или «Заказ поставщику», а то наплодили тут сущностей бюрократы из 2х документов, так ещё и «заявки» какие то придумать хотят.
Не забывайте, что заявка — это просто один из способов избавиться от риска.
Заявка это не только способ избавится от риска, это так же элемент планирования и управления.
Есть способы сложнее, меньше влияющие на скорость продаж.
А откуда взялось предположение что это влияет на скорость продаж?
А откуда взялось предположение что это влияет на скорость продаж?
из практики. Вы же проверить можете.
Если продажа и с заявкой, и без заявки занимает одинаковое время — то влияния нет.
В магазине я пришел лампу ближнего света купить, она в наличии. Продажа заняла 3 минуты, отдал 400 рублей.
Потом пришел за пыльником шруса, его нет в наличии. Составили договор на поставку, через 4 дня привезли. Отдал те же 400 рублей, но продажа заняла 4 дня = 5760 минут.
Скорость генерации денег сами видите как отличается.
В первом случае снабжение и продажа работают асинхронно, во втором — синхронно. Асинхронно — это потому, что они знали, что я приду за лампочкой, и заблаговременно ее купили. Это по ТОС.
(93)Так мы живём в реальном мире, а не в теории. Мы не можем всегда держать 100% товаров на складе. И за наличие товара на складе мы должны чем то заплатить.
А это неликвид, замороженная в товаре «оборотка», площади хранения и тд. На одной скорости «генерации» мы так далеко не уедем. Наверное надо брать в расчёт все элементы и считать экономическую целесообразность ускорения «генерации», а то как бы не получилось что будем рубль по 90 копеек продавать. Вчера в один магазин заходил весь неликвид по закупочной выложен на прилавке.
Скорость генерации денег сами видите как отличается.
Быстро генерировать за счёт своей прибыли как то не по «бизнесменски». Так и без штанов легко остаться.
Асинхронно — это потому, что они знали, что я приду за лампочкой, и заблаговременно ее купили. Это по ТОС.
Это и до ТОС было. Всегда держали на под рукой ходовой товар, а то что редко продаётся под заказ. Для того кто пробовал что то сам продавать это и без ТОСа вполне очевидно.
(93) Но и в том, и в другом случае они свои деньги получили, а то, какие затраты были понесены продавцом в 1 и 2 случае, это вопрос интересный:) Но это так, лирика. Всеже ждем решения «боли планирования»
(95) скорость генерации денег — это внутреннее свойство системы. Еще его можно назвать «эффективность», если добавить затраты, которые вы отметили.
Имея систему со скоростью генерации денег 1 млн рублей в день, вы за месяц генерируете 30 млн. рублей.
Имея систему со скоростью генерации денег 10 млн рублей в день, вы за месяц генерируете 300 млн рублей.
Тут вроде все понятно, но обычно друзья не обращают внимания на ключевое понятие: эффективность — это внутреннее свойство системы. И как-то не обращают на него внимание, думая над вопросом «как увеличить продажи?».
Но вы правы, оффтоп пошел. Про ТОС напишу отдельно.
Тут вроде все понятно, но обычно друзья не обращают внимания на ключевое понятие: эффективность — это внутреннее свойство системы. И как-то не обращают на него внимание, думая над вопросом «как увеличить продажи?».
надо не поднять продажи, а ускорить систему, их генерирующую. Надо внутрь системы смотреть, а не вокруг нее — на рынки или новые технологии. Внутри все скрыто.
Вполне возможно, что в бюрократии, той же заявке. Это надо наблюдать и измерять.
На практике откройте магазинчик, на маленький островок в ТЦ надо 100 — 200 к рублей, вот там на собственных деньгах проверьте состоятельность теории. А именно увеличьте в 10 раз скорость генерации без увеличения продаж(количества продаж, среднего чека и тд).
Что будете генерировать если количество покупателей в единицу времени не увеличилось?
Что будете генерировать если количество покупателей в единицу времени не увеличилось?
это отличный вопрос, и он тоже в книге рассмотрен.
Это ограничение вне вашей системы, т.е. ограничение рынка. В этом случае нет смысла увеличивать внутреннюю эффективность системы, т.к. она будет избыточной.
Но, тут есть и обратная связь — повышение внутренней скорости может расширить ограничение рынка. Проще говоря, если все отгружают за 10 дней, а вы научитесь за 3 дня, то клиенты перейдут к вам.
Состоятельность теории я, разумеется, проверял, проверяю и буду проверять. И на своих деньгах, и на чужих.
Вы несколько раз уже повторили, что это все в теории. Вы же понимаете, что так оно и будет, пока вы не попробуете?
Не нужно рисковать большими чужими деньгами. Есть миллион дешевых процессов, на которых можно попробовать ТОС без риска для бизнеса. Если получится — взять что-то более крупное. И т.д.
Вы же понимаете, что так оно и будет, пока вы не попробуете?
Так пробуем. Не каждая теория подтверждается практикой. Или можно предположить что мы «не умеем её готовить», тут сложно дать однозначный ответ.
Это ограничение вне вашей системы, т.е. ограничение рынка. В этом случае нет смысла увеличивать внутреннюю эффективность системы, т.к. она будет избыточной.
Так в этом вся соль. Как раз ограничением и является количество этих самых покупателей в единицу времени.
(97) Это понятно, я к тому, что не зная конкретное предприятие нельзя сделать однозначный вывод, что увеличение прохода без изменения других, не известных нам, параметров приведет к увеличению прибыли.
(103) мне кажется, важно не искать отговорки вроде «не зная конкретное предприятие, нельзя сделать однозначный вывод, …».
Если есть предприятие, и там есть 1С, и оно не маленькое, значит что? Там есть программист 1С.
А он знает предприятие. А мы знаем его. Вместе разберемся.
А то сидим все по углам, огрызаемся друг на друга, типа «да вы не знаете, какие тут у меня условия», а дело на месте стоит.
ТОС — это фреймворк. Как платформа 1С. Сам по себе ТОС ничего не стоит, как и платформа 1С.
Есть такие проблемы, которые «голым 1С» не решить. Для некоторых нужен ТОС, для некоторых metadata.js, для некоторых Scrum, для некоторых яндекс clickhouse и т.д.
Хочешь решать проблемы — придется разбираться во фреймворках. Это, наверное, всем очевидно.
Захотел красивую диаграмму — пошел курить Google Charts, например. Покурил, попробовал на маленьком примере, встроил в продакшн.
Захотел снабжение улучшить — пошел курить ТОС. Покурил, попробовал на маленьком примере, встроил в продакшн.
Не пускают в снабжение — так снабжение и в ИТ-отделе есть. Я на сис.админах тренировался, на закупке компов (расскажу в статье про ТОС).
Как раз ограничением и является количество этих самых покупателей в единицу времени.
мне кажется, главное — себя не обманывать.
Я много — МНОГО — раз видел, как компании тратят массу сил, средств и времени на снятие такого ограничения — количества клиентов. Внедряют CRM, создают отдел маркетинга, делают красивый сайт с интернет-магазином.
А клиенты, которые были, есть, и будут, продолжали ЖДАТЬ, потому что внутренняя скорость системы только снижалась — как раз из-за тех самых заявок и внутренних согласований, про которые вы говорите.
Вот вам примеры из моей практики:
1. раньше согласовывали КД на детали один раз, при аудите поставщика, потом кто-то придумал согласовывать КД каждый раз, по каждой поставке. Это + 2 дня;
2. раньше согласовывали протокол цен на год, и не меняли их, потом кто-то придумал согласовывать цену каждый раз, по каждой поставке. Хотя цена не менялась. Это + 1-2 дня.
3. раньше согласовывали и сдавали юристам договор один раз в год, потом кто-то придумал согласовывать, подписывать на бумаге и сдавать юристам каждую спецификацию. Это + 1-7 дней.
4. раньше конкурентный лист составляли раз в год, потом кто-то придумал делать это на каждую закупку. Номенклатура та же, поставщик тот же, цена и условия лучшие (их же в начале года выбрали), но вот чот как-то так. Это + 1 день.
5. где-то посередине, когда уже был п.3, спецификацию согласовывал только начальник закупок. Потом решили добавить всю братию — юристов, бухгалтеров, главного инженера, финансистов. Это еще + 1-3 дня.
Это все — вариации на тему внутренней заявки. Безопасность закупа не изменилась. Как случались косяки, так и продолжили случаться.
А кто все это придумал? Бюрократы, обслуживающие подразделения, которым понравилось встраиваться в живой процесс генерации денег. Бухгалтерия, финансисты, юристы, служба менеджмента качества и т.д.
А клиенты продолжали ЖДАТЬ.
P.S. вы говорили, что нет грустных историй — вот она. Люди не хотели смотреть внутрь системы, искали проблемы снаружи. А система за это время быстро засралась.
Разумеется, я не утверждаю, что у вас также. Просто воочию видел, как люди ошибаются, думая, что надо только клиентов побольше привлекать, что в этом главная трудность.
(104) Есть такие проблемы, которые можно решить только сменой топ-менеджмента/собственников компании. Если в этом может помочь ТОС или Scrum хотелось бы о таких случаях услышать…
(106) да я не об этом. Вы вот посмотрите на свои комментарии со стороны. И на комментарии Боряна заодно.
Они однотипные — херня это все, веками так делалось, да они лучше знают, да мы рукожопые, куда нам, и ты рукожопый, и теории все от лукавого, у нас все не так, мы особенные, но делать ничего не будем, да там вообще ничего нельзя сделать, только ТОПов уволить, а лучше никого не уволить, вообще оставить все как есть, да нахер все это.
Мы ж не такие. Мы — инженеры, наше дело — создавать.
Про то, как поможет ТОС или Scrum, конечно расскажу — все что знаю. И жду, что вы расскажете все, что знаете. А что не знаете — попробуете, и расскажете. И я попробую, что не знаю, и расскажу.
(107) Странно вы комментарии читаете. Я нигде не говорил, что предлагаемые вами подходы не работают в принципе. Я говорил, что у любых теорий есть ограничения в применимости, и об этих ограничениях нужно знать, и их учитывать. И как из этого у вас получилось, что я предлагаю ничего не делать мне не понятно.
Статьи ваши безусловно полезны, читаю их с интересом. Если не хотите видеть от меня комментариев с критикой — их не будет.
В первом случае, к времени продажи нужно еще, как минимум, прибавить время нахождения лампы на складе, а во втором, вычесть время, когда была оплата поставщику за ШРУС, только после этого получится «Скорость генерации денег»
В моем представлении «Скорость генерации» — это «Больше денег» в единицу времени. Не?
Наверное.
Но когда вы пишите «Держа ШРУС на складе, получим ли мы от этого больше денег?» без указания «в единицу времени» то это сбивает с толку. Без указания в «единицу времени» можно предположить что «больше» от времени не зависит.
Производительность по денежному потоку (Throughput, Т) – это скорость, с которой система в целом генерирует доход в результате продаж. Строгое математическое определение для T и его связь с I и ОЕ вытекает из выражения баланса денежного потока:
CF (Cash Flow, денежный поток) = T – ОЕ ± I, где T – ОЕ = NP (Net Profit, чистая прибыль).
В динамическом виде это же выражение имеет вид:
dCF/dt = T – ОЕ – dl/dt,
где t – время. Его можно прочесть как «приращение денежного потока равно скорости генерации дохода минус операционные расходы и изменение связанного капитала компании»
В понедельник купили ШРУС, в пятницу продали ШРУС. Какая «скорость генерации дохода» на продаже ШРУСа?
А как посчитаете, так и будет. Я считал скорость конкретной цепочки — от появления покупателя до получения всех его денег. В вашем примере, если покупатель пришел в пятницу, и через 5 минут ушел со ШРУСом, то стоимость ШРУСа поделить на 5 минут.
Во втором вашем случае стоимость ШРУСа надо поделить на неделю.
Фишка в том, что формула прохода — абстрактная, это «скорость генерации единиц цели». Что есть единица цели — решаете вы, как архитектор системы.
Покупка ШРУСа — это не часть процесса генерации дохода. Это полностью переменные расходы в данном случае, и они одинаковы в любой момент покупки — хоть за день до продажи, хоть за неделю.
Об этом хорошо сказал Таичи Оно (цитату привел Голдратт в своей статье «Стоя на плечах гигантов»), отвечая на вопрос, чем занимается Toyota: «Все, что мы делаем, — это смотрим на время от момента поступления заказа от клиента до момента, когда мы получаем деньги. И мы работаем над сокращением этого времени».
Цель ТОС — ровно та же. Сократить время от появления потребности до ее удовлетворения и получения денег.
Разумеется, там еще хороший багаж методов, как держать низкий уровень запасов, как рассчитывать их уровни, и т.д.
Держа ШРУС на складе, получим ли мы от этого больше денег? — на первый взгляд не очевидно.
больше денег мы получим не от того, что он на складе, а от того, что когда придет покупатель, мы сразу получим его деньги. А затраты на покупку ШРУСа одинаковы как при покупке заранее, так и при покупке под заказ.
Ну и остальные клиенты будут приходить к нам, когда узнают, что ШРУС в наличии.
Я пошел в магазин, потому что в автосервисе ШРУС под заказ ждать 2 недели, а в магазине 4 дня. Автосервис сэкономил на складе, но не получил моих денег.
Насчет денег в системе переживать не стоит. Если работает ТОС, то при той же стоимости склада радикально меняется качество его наполнения, в результате чего увеличивается проход. Много хороших, качественных примеров из личной практики Голдратта есть в его книге «Выбор» — очень рекомендую, если не читали.
Вот давайте предположим, что у нас вместо лампочки, допустим, рама от Лэнд-Крузера. Рама от Лэнд-Крузера стоит чуть дешевле, чем сам Лэнд-Крузер, и как-бы желающих менять раму каждый день не так уж и много.
Я это к чему все… Было бы замечательно, если бы вы явно обозначали в каком контексте вы ведете рассуждения, какие границы применимости у данных методов, какие параметры вы принимаете как не существенные в конкретном примере.
Просто получается, когда люди примеряют ваши примеры к области деятельности отличной от вашей они получают некоторый когнитивный диссонанс, и выходит — «Фуфло все ваши теории»
(126) вроде все правильно пишете, только выхода не видно и вывод не ясен.
Ну, ежу понятно, что владелец рискует больше наемных рабочих.
Тому же ежу понятно, что большинство бизнесов пытаются что-то изменить — автоматизацию сделать, бизнес-процессы наладить, ТОС внедрить, систему сбалансированных показателей и прочие штуки.
Ежу-же понятно, что в большинстве случаев владельцы делают изменения чужими руками — руками людей, которые не владеют их деньгами.
Ваша-то мысль в чем? Вы, как бывший совладелец бизнеса, против изменений чужими руками? Ради Бога. Не верите в ТОС? Ради Бога. Не верите тому, кто говорит, что ТОС поможет? Ради Бога. Требуете от консультантов наличия собственного бизнеса? Ради Бога. Требуете финансовой ответственности за результат? Ради Бога. Ваше право.
Ну, не будут с вами работать, сами как-нибудь все сделаете.
Есть масса людей, которые сами не умеют или просто некогда. Рискуют, дают небольшой участок бизнеса для тестовых изменений. Смотрят на результат. Понравилось — продолжают. Не понравилось — думают, что делать дальше.
Или просто утверждаете, «что все это неправильно»? В смысле жизнь неправильно устроена.
Я с вами не спорю. Просто пытаюсь добавить «глубины» вашим рассуждениям. Давайте приведу аналогию…
Допустим, по радио передача «Вопрос адвокату», звонит человек и спрашивает: «У меня умер очень дальний и очень богатый родственник. Могу я претендовать на наследство?». Там обычно рассуждают, — «вот если к тому что вы сказали присутствует факт1 и факт2, то вы получите такой результат, если факт3 и факт4 то другой». Что на мой взгляд позволяет сторонним слушателям делать выводы по поводу своих ситуаций. Жизнь — она чуть более многогранна.
Для сторонних слушателей — публикации. В публикациях авторы стараются раскрыть тему.
Тут — комментарии, где конкретный человек задает вопрос конкретному человеку. В комментарии обычно не раскрывается контекст и тема. Если я предполагаю, что вы знаете ТОС, то пишу, исходя из этого предположения. И пишу конкретно вам.
В основном, конечно, наибольший эффект все теории дают на предприятиях с большим числом составляющих и решают они проблемы немного другого характера, чем те которые возникают у малых предприятий.
Лично мое мнение — такие длинные цепочки генерируют обслуживающие подразделения, которые не способны качественно выполнять свои обязанности. В данном случае качественно — это асинхронно.
А можно вернуться к Заявке?
Как заявка по Вашему тормозит скорость генерации денег?
Типичный пример — согласования. Зачем согласовывать каждую поставку материала или детали, если мы покупаем ее 10 раз в месяц,
Т.е. Вы в какой-то момент ранее сообщили поставщику устной или письменной Заявкой, что собираетесь покупать деталь 10 раз в месяц, Подписали с поставщиком договор. И поставщик вам гарантировал поставку.
А если Поставщику устной или письменной Заявкой ничего не сообщали, договора с поставщиком нет, то и риски что на 10 поставке Вы не получите товар вовремя ложатся на Вас.
Как заявка по Вашему тормозит скорость генерации денег?
вы же понимаете, как она тормозит. Пришел клиент, принес деньги, говорит дай товар. Без внутренней заявки вы можете отгрузить завтра. С внутренней заявкой получится только через 5 дней. Имея буфер на складе, вы можете отгрузить сейчас. Имея буфер на складе покупателя, вы можете отгрузить вчера.
Т.е. Вы в какой-то момент ранее сообщили поставщику устной или письменной Заявкой, что собираетесь покупать деталь 10 раз в месяц, Подписали с поставщиком договор. И поставщик вам гарантировал поставку.
да, в начале года мы согласовали цены, условия поставки, сроки исполнения и интегрировали наши системы, чтобы он узнавал о необходимости поставки раньше нас. Заодно прописали в договоре, что он должен иметь на складе 20 шт номенклатуры, которую нам поставляет.
А если Поставщику устной или письменной Заявкой ничего не сообщали, договора с поставщиком нет, то и риски что на 10 поставке Вы не получите товар вовремя ложатся на Вас.
в данном случае на вас ложатся риски за то, что вы наняли плохих юристов и снабженцев.
Все равно не понял…:-) У Вас Заявка есть, но не привязана к конкретному Заказу. Видимо считаете выгоднее брать на себя эти риски.
да, в начале года мы согласовали цены, условия поставки, сроки исполнения и интегрировали наши системы, чтобы он узнавал о необходимости поставки раньше нас. Заодно прописали в договоре, что он должен иметь на складе 20 шт номенклатуры, которую нам поставляет.
Перефразирую:
1. Заранее подали заявку Поставщику о планах закупки (ориентировочные сроки и объемы)
2. Поставщик Выставил спецификацию цен и свои доп условия (Наверняка поставщик изменит цену, если регулярно откажетесь закупать детали)
3. Подписали договор с графиком (для сохранения уровня цен) приобретения у Поставщика деталей
4. По поступлению Заказа от Заказчика система автоматически формирует (возможно виртуальное) поручение Поставщику отгрузить на Ваш склад деталь.
5. Заказчику отгружается деталь из имеющихся на складе.
Все документы присутствуют. И геде тут Бюрократия тормозящая генерацию денег? У кого-то процесс синхронный, у кого-то асинхронный, но набор документов одинаковый и алгоритм расчета дефицита деталей будет одинаковый.
Другое дело, что в существующих системах недостаточно учтено реквизитов, чтобы предоставлять универсальные решения.
(138) конечно, принципиальной разницы-то нет, на производственном циклы длиннее.
Я говорил про предприятие, которое производит железяки, собранные из множества деталей, часть которых оно производит само, часть заказывает у поставщиков.
(139) В моем понимании источником заказа на закупку является план производства, и все длительные согласования (договора на поставку, тендеры, спецификации) происходят на этапе запуска изделия в производство. Если под это изделие уже заключены договоры на поставку комплектующих, то единственное согласование, которое нужно — это согласование финансового блока на включение финансирования в БДДС.
Возвращаясь к инструменту планирования — он должен уметь отвечать на вопросы более высокого порядка, чем обеспеченность уже принятых заказов.
(142) Например, нам поступило одновременно 2 заказа, можем ли мы оба заказа взять, если нет, какой из них выгоднее, если надо взять оба, то какими уже запущенными заказами можно пожертвовать, и сколько нам это будет стоить и т.д…
Что-то непонятно, вы точно оба про производственное предприятие говорите?
Структура внутренней заявки не сильно отличается от структуры внешней заявки (Потребитель, Поставщик, Цель, Ресурс, Объем цели, Объем ресурса)
1. Заявка Заказчика службе Реализации
2. Заявка службы Реализации на Производство
3. Заявка Производства в службу Обеспечения
4. Заявка службы Обеспечения к Поставщикам
5. Заявка Поставщика Финансовой службе по оплате
Составлять заявки можно и независимо друг от друга. В вашем случае служба Реализации без заявок Заказчика берет на себя ответсвенность — заранее планирует резерв ресурсов у внутренних служб и внешних поставщиков
Скорость генерации единиц цели — любое количество картриджей за сутки.
Будем реалистами. Поставщик не может обслужить бесконечное число картриджей за фиксированный период времени, значит в любой момент может передвинуть время обслуживания, значит никакая система не ответит, какой очередной картридж не будет обеспечен заправкой.
(144) лично мое мнение — вопрос неправильный, технический. Чтобы на него ответить, городится большой огород из технических расчетных систем. Раз уж у нас веточка про ТОС, то ТОС рекомендует не заниматься сложными расчетами, а заниматься реальными проблемами.
В вашем примере — надо понять, почему вообще мы считаем проблемой поступление сразу двух заказов.
это все реальные заявки? Прям документы, бумажные или электронные?
Будем реалистами. Поставщик не может обслужить бесконечное число картриджей за фиксированный период времени
если будем реалистами, то будем реалистами — за 6 лет была одна задержка, когда понадобился барабан к очень древнему картриджу. Рассудили, что проще купить другой принтер.
это все реальные заявки? Прям документы, бумажные или электронные?
Все сложнее, разные службы, множество документов и подходов к их оформлению.
Но суть не в этом. Есть перечень направлений (финансы, закупки, производство, …), перечень этапов (планирование, управление, исполнение, учет), ключевые вопросы (что?, когда?, сколько?, кто?…) — их полный набор независим от деятельности предприятия и должен присутствовать в любой системе.
Проблема в том, что некоторые информационные процессы не отражаются в реальных документах (происходят устно), некоторые документы объединяются для упрощения процедуры их согласования, следовательно автоматизированные системы создаются не универсальными а урезанными или с оптимизацией под конкретное предприятие.
А чтобы система стала универсальной, она должна автоматизировать (грубо) декартово произведение 12 Этапов Х 10 Направлений Х 10 Направлений = 1200 Бизнес операций (очень грубо).
Для расчета обеспеченности по заказу необходимо анализировать все эти 1200 Бизнес операций.
(162)Вот уж эта задача особо сложной не выглядит с технической точки зрения, а вот организационно конечно вызывает большие вопросы. Но, кстати, все эти заявки могут иметь смысл, если продажи, снабжение, производство, финансы — это все разные юридические лица. И такое встречалось на практике…
..все эти заявки могут иметь смысл, если продажи, снабжение, производство, финансы — это все разные юридические лица…
Достаточно чтоб это были разные службы со своими подслужбами на крупном предприятии.
Но опять же, не могу донести суть…
В реальности на предприятии межет не создаваться такое количество заявок в бумажном виде. Действительно, если есть спецификация, маршрутная карта, то службы обеспечения и без производства сформируют свои графики поставки материалов расписывая в амбарных книгах в колонках партии реализуемой продукции, в строках перечень материалов, а всякие нестыковки с производством по времени, определение приоритета выдачи материалов корректируются с мастерами тут же приписками и зачеркиванниями в ячейках.
Но, в компьютерных системах нестыковки зачеркиванием не исправишь. Чтобы компьютерная система выдавала обеспеченность в соответсвии с приоритетами производства, ей необходимо как-то сообщать эту информацию, даже если мастер производства сообщил о своих приоритетах устно.
Заявки производства могут генерится (автоматически) незаметно для пользователей на основе сроков отгрузки продукции, маршрутных карт и спецификаций. Пользователи даже могут не знать, что в системе есть такие документы, если им нет потребности в корректировки производственных приоритетов.
ИМХО: Универсальная автоматизированная система контроля обеспеченности должна опираться на всю цепочку заявок и многих других документов, о существовании которых пользователи могут даже не догадываться и никогда в этой системе не регистрировать. Эти документы в упрощенном контроле могут генерироваться автоматически. Памяти на диске жалеть не стоит. Поддержка алгоритмов сбора отчета по обеспеченности для различных упрощенных случаев обойдется дороже.
вот есть универсальная система правда сам не пробовал
(1) спасибо, покурим.
(2) Вобще проектирование логики любых сложных систем (в том числе планирование) — требует высокого уровня абстракции . Каким образом это реализовать в 1С — это вопрос. Я в свое время «споткнулся» об это на проектировании системы управления производственным процессом и после размышлений и «курения» всяких мануалов пришел вот к . Народ правда не особо оценил, возможно потому , что примеры привел слишком примитивные, но к сожалению других пока нет.
(1) покурил, тема прикольная, но применительно к задачам из статьи — совсем не то. Просто цель другая, а соответственно — и подходы.
Но за ссылку — спасибо!
(3)
Наверное, 1С также отвечает. Мы ж из Челябинска, нас такой ерундой не запугаешь.
(5)
если у вас есть какое то решение , или идеи поделитесь ими с сообществом
Очень узкая постановка проблемы. Рассматриваю проблему несколько шире:
Нормирование (что, в какой пропорции, за какой срок?):
1. Номенклатурные справочники;
2. Спецификации, Курсы обмена, Замены (Пропорции и сроки);
Планирование (кто, кому, когда, в каком объеме?):
3. Справочник Потребителей и Поставщиков (подразделений, цехов, складов);
4. Заявки потребителей (Крайняя ожидаемая дата поставки, обьем продуктов)
5. Графики поставщиков (Начальная планируемая дата поставки, объем ресурсов)
Управление (кто МОЛ-исполнитель, в каком месте (по какому счету), в каком объеме?):
6. Реестр договоров с Контрагетами и МОЛ;
7. Реестр мест хранения, счетов;
8. Требование Потребителя (МОЛ-получатель, место (счет) получения, объем продукта)
9. Приказ (резерв) Поставщика (МОЛ-отправитель, место (счет) отправки (отпуска), объем ресурса);
Исполнение (факт расхода и прихода):
10. Справочник паспортов номенклатуры, партий;
11. Документ расхода отправителя (фактическая дата);
12. Документ прихода получателя (фактичекая дата);
Вот тут pain, про SQL и регистры тока мечтаю…
(6) поделюсь, конечно. Готовлюсь.
(7) список выглядит внушительно, но я не все понял.
Можете поподробнее рассказать, о какой задаче речь?
(9) ждем с нетерпением
(9) Вопрос
— простым ответом про наличие или отсутствие материала на складе пользователей не удовлетворяют. Сразу допы прут: А когда прибудет от поставщика? А сколько уже оплачено? А сколько из производства вернулось по браку? Главное, КТО ВИНОВАТ?
Короче, чтобы удовлетворить пользователя, необходимо расуручивать полную обеспеченность по заказу про:
— Готовую продукцию, ожидающую отгрузку
— Незавершенное производство, ожидающее выпуск
— МПЗ, ожидающее списания в производство
— Обязательства поставщиков по поступлениям товаров и услуг
— Денежные средства, ожидающие оплаты поставщикам
— Обязательства заказчиков по платежам за продукцию
А это, в одном запросе всю базу надо охватить, сотни справочников, документов и регистров. Сотни подзапросов для каждого случая (деньги по одним алгоритмам, материалы по другим).
Смысл же (7) в том, что независимо от деятельности:
— Управление денежными средствами;
— Расчеты с поставщиками и покупателями;
— Управление работниками;
— Эксплуатация оборудования;
— Управление запасами;
— Производство;
— Управление готовой продукцией;
Общие вопросы пользователя остаются одинаковые:
— Какие не исполнены приказы, требования? Кто виноват? Что делать?
— Какие просрочены графики, заявки? Кто виноват? Что делать?
— Какие не соблюдены нормы, стандарты? Кто виноват? Что делать?
Раз вопросы одинаковые, есть надежда (идея), что в ERP не нужны СОТНИ справочников, документов и алгоритмов, их можно сократить до дюжины (12 перечисленных) универсальных. Тогда и обеспеченность собирать можно.
Идея простая, но сходиться вот никак не хочет.
Надеюсь, «Боль планирования» Вас больше не мучит!
(15) ИМХО, вы перечислили неправильные вопросы.
Такие вопросы задают люди, которых интересуют не реальные проблемы предприятия, а мышиная возня с женским подходом (вопрос «кто виноват?» их выдает).
И вопросы эти — не для того, чтобы решить проблемы, а чтобы отсрочить их решение. Пользователи ведь знают, что вы не ответите.
(19)
Ответить просто. В каждом документе имеется ссылка на ответственное подразделение, ответственных лиц, на крайний случай, автора документа.
— Эт… был сарказм 😉
Вот к этому хотел прибавить «как глубока кроличья нора». Что свет есть, но это еще не выход…
(20)
а если нет документа 🙂
Есть заказ покупателя, но нет заказа поставщику, который бы его обеспечил?
(21)
— Потребность в поставщике описана в спецификации
Кто виноват:
— Ответсвенный за исполнение заказа покупателя, если не составил заявку (с крайней датой поставки) на ответвенного по поставщикам в соответствии со спецификацией
— Ответвенный по поставщикам, если не сформировал или нарушил график поставки по поступившим заявкам
(67)
вам не кажется, что эта схема отдает излишней бюрократией? Человек принес потребность, которую надо простыми внутренними усилиями превратить в деньги. А мы заставляем его какую-то заявку составлять. Он итак все описал в заказе покупателя.
(68)То что внутри системы это выглядит бюрократией, не означает что пользователь с этой бюрократией обязан столкнуться. Если «Он итак все описал в заказе покупателя», возможно и заявка поставщику может сформироваться автоматически, незаметно для пользователя. Другой вопрос, некорректно смешивать в базе данных заказ покупателя и заявку поставщику.
(69) так кто в итоге виноват, если заказ покупателя есть, а заказа поставщику нет?
программист?
(70)
На Ваше усмотрение, что в автоматическую заявку вставите.
(71) теперь вернемся к теме статьи.
Что из перечисленного есть в УПП или ERP?
Возможен ли сценарий, когда заказ покупателя есть, а заказа поставщику нет, и непонятно кто в этом виноват?
(72)Все что я выше перечислил конкретно к УПП или ERP отношения не имеет. Проблема не в отсутствии системы, а глубже, в отсутствии понимания, какая это должна быть система.
На предприятии такая ситуация невозможна. Крайний всегда найдется…
(68)
мне кажется заявка от потребителя ( прод. менеджера) все таки нужна в виде заказа или какого-то задания на закуп (для снабженца) , во первых сроки поставки по одному заказу покупателя могут отличаться , во вторых ( если возможно) по этой заявке отслеживается состояние выполнения в третьих поступления на склад обосабливаются по каждой заявке
(74) если у вас типовая конфигурация от 1С — да, конечно, заявка нужна.
(75)А если не типовая то где указываются сведения относящиеся к заявке на закупку?
(76) можете пояснить, что это за сведения такие? Есть заказ покупателя, есть заказ поставщику. Заявка на закуп какую роль, кроме бюрократической играет?
(77)
Мы не знаем кто будет поставщиком. У нас их десятки-сотни. По одному заказу покупателя на изделие я должен сделать заказы тридцати поставщикам на разные комплектующие(материалы) которых на конкурсной основе я должен выбрать из сотни. На основании заявки на закупку формируются запросы к поставщикам, составляется конкурентный лист который потом проходит разные этапы согласования(нач отдела, производство, фин отдел, СБ итд) и выбора поставщика. И вот когда поставщики выбраны, заявка на закупку одобрена мы делаем заказ поставщику. По крайней мере в крупных компаниях где мне доводилось работать было так.
Требования к материалам, условиям закупки, срокам проведения закупки, ценовому диапазону, срокам и условиям хранения на складе и тд.
Ярлыки развешивать довольно простое занятие. А вот как определить что есть «бюрократия», а что производственная необходимость? Где та черта где мы можем сказать что вот это «бюрократия», а вот это правильно выстроенный процесс? Есть какие то измеримые, универсальные критерии?
(78) правильно я понял, вы каждый раз, после каждого заказа покупателя эту длинную цепочку проходите? Вот которую вы описали?
Я встречал такие цепочки, но они делались при первой сделке с поставщиком, включая аудит.
Требования к материалам, условиям закупки и т.д. — они разве не постоянны? Срок, если он не абсолютный, а относительный (30 дней, например) — вроде тоже константа.
[/IS-QUOTE]
Универсального ничего в жизни нет. Есть общепринятые. Например, прибыль. Или проход (в ТОС) — скорость генерации денег.
Лично мое мнение — такие длинные цепочки генерируют обслуживающие подразделения, которые не способны качественно выполнять свои обязанности. В данном случае качественно — это асинхронно.
Асинхронно — это когда обслуживающие не вмешиваются, не тормозят основной процесс. Синхронно — когда вмешиваются и тормозят (как в описанном вами случае).
Типичный пример — согласования. Зачем согласовывать каждую поставку материала или детали, если мы покупаем ее 10 раз в месяц, не меняя тех.требований, КД и т.д.?
Сроки проверять? Так они в договоре прописаны.
Условия оплаты проверять? Так они в договоре прописаны.
Фин.состояние поставщика проверять? Так подключите сервис и проверяйте сами, или сделайте подписку на изменение состояния.
Вроде бы — чего такого? Ну согласовывают люди, жалко что ли.
Жалко — они снижают скорость генерации денег.
Если без согласования от точки заказа покупателя до точки отгрузки пройдет 10 дней, а с согласованием — 15 (это еще оптимистично), то скорость генерации денег системой падает в 1.5 раза. Это — влияние синхронной бюрократии.
Но я не говорю, что не надо всех этих согласований — пусть будут. Главное — правильно момент для них выбрать. Не синхронно, не во время сделки, не на пути денег через систему, а асинхронно — параллельно, не мешая процессу.
Вот вам гиперболическая метафора. Впихивать все согласования и проверки в процесс продажи — все равно, что выполнять расчет себестоимости каждый раз, когда пользователь нажимает «Сформировать» в отчете «Ведомость по учету МПЗ и затрат».
Хотя, убрать согласования в асинхронный поток — это полумера. Еще лучше — сделать асинхронным снабжение. Это тоже ТОС.
(79) Теория хорошая… но всё мимо.
(80) это все из личной практики стратегического управления.
(81) Ваш опыт не воспроизводим на большинстве предприятий, к сожалению.
(82) еще как воспроизводим, вы сами в этом убедитесь. Наберитесь терпения, мы в самом начале пути.
(83) На большинстве уже действующих предприятий воспроизводим? Сильное заявление…
(84)
спасибо, рад что понравилось.
(85) Видно, что тренинги личностного роста принесли результат.
(86) результат приносит все — и тренинги, и книги, и фильмы, и общение, и практика. Все вместе формирует личность во всех ее проявлениях.
P.S. на тренингах по личностному росту не бывал.
(87)
тут два момента. Во-первых — ставят. И весьма успешно.
Во-вторых — мы ведь про глубинные причины проблем, а не про конкретные болезни. Бюрократия — это ошибка в фундаменте. Как неправильное питание, отсутствие двигательной активности, плохой воздух и т.д. Любой врач, занимаясь лечением конкретной болезни, понимает, что причина — глубже. Но уже не говорит об этом, т.к. задолбался. Люди ведь хотят таблетку, а не образ жизни или мыслей.
Но мы-то с вами не такие.
совершенно верно. Только мы-то с вами не бизнес-консультанты, правда? Мы 1Сники, мы внутри компании сидим.
для управления рисками есть другая дисциплина, она так и называется — управление рисками. Там много статистики, вероятностей, думать много надо. Сейчас нейросети этому научили — например, в банках, чтобы оценивать риски выдачи кредита. Когда думать не хочется — просто проверяют все подряд. Как вахтеры.
это ж проверить можно, есть масса методов. Разумеется, если хочется эффективность повысить, балансируя ее с надежностью и безопасностью.
Расскажете о своей практике применения ТОС? Особенно о негативной. Позитивной полно итак, а негативной мало.
а с этими 30 поставщиками разве нет договоров?
(90)
ок, у нас разный опыт общения с врачами.
конечно. Способ защиты системы и людей от рисков.
по ТОС не заявка не нужна, а скорость генерации денег надо контролировать. И любые изменения проверять на предмет влияния на эту скорость.
Ключевой вопрос — было ли управление рисками. Появилась ли заявка в результате анализа, прогнозирования и опыта, оправдана ли она. Или она как-то сама появилась, на всякий случай.
Не забывайте, что заявка — это просто один из способов избавиться от риска. Не единственный. Но самый простой для тех, кто за риски отвечает. Есть способы сложнее, меньше влияющие на скорость продаж. Другой вопрос, если управлятели рисков об этом не думали, ну или вообще не знают. Тогда они убедительно убедят директора, что только так можно гарантировать безопасность.
Такое часто у сис.админов плохих бывает. Ему говорят — нужна информационная безопасность. Он говорит — все, запрещаем интернет, личные ящики, флешки, ютуб, вайфай — все запрещаем, и будет тогда безопасность.
Можно просто поверить на слово, и вдвое удлинить все процессы, усложнить жизнь всей компании. А можно использовать современные технологии, с каждым риском разобраться по-отдельности, применить точечные меры и т.д., и никому жизнь не портить.
вы не уникальны — все так делают, вы не отличаетесь от остальных. И я о том же говорю постоянно.
Правильно понял, что вы не пробовали применять что-нибудь из ТОС на практике?
еще раз — мы с вами не бизнес-тренеры и не бизнес-консультанты. Мы 1Сники. Вы не делаете вид, что вы бизнес-консультант, я не делаю вид, что я бизнес-консультант. Мы занимаемся одним и тем же делом. Говорим как коллеги, равные друг другу, делимся опытом, помогаем друг другу.
Что там делают бизнес-тренеры и бизнес-консультанты — нам не важно. Важно только, что у них плохо получается — значит, они нам не конкуренты. Мы не пойдем по их пути, потому что этот путь ошибочен.
(91)
Так я вроде и не говорил что я отличаюсь от остальных.
Тогда можно вообще упростить. Делать всё в одном документе «Заказ покупателю» или «Заказ поставщику», а то наплодили тут сущностей бюрократы из 2х документов, так ещё и «заявки» какие то придумать хотят.
Заявка это не только способ избавится от риска, это так же элемент планирования и управления.
А откуда взялось предположение что это влияет на скорость продаж?
(92)
из практики. Вы же проверить можете.
Если продажа и с заявкой, и без заявки занимает одинаковое время — то влияния нет.
В магазине я пришел лампу ближнего света купить, она в наличии. Продажа заняла 3 минуты, отдал 400 рублей.
Потом пришел за пыльником шруса, его нет в наличии. Составили договор на поставку, через 4 дня привезли. Отдал те же 400 рублей, но продажа заняла 4 дня = 5760 минут.
Скорость генерации денег сами видите как отличается.
В первом случае снабжение и продажа работают асинхронно, во втором — синхронно. Асинхронно — это потому, что они знали, что я приду за лампочкой, и заблаговременно ее купили. Это по ТОС.
(93)Так мы живём в реальном мире, а не в теории. Мы не можем всегда держать 100% товаров на складе. И за наличие товара на складе мы должны чем то заплатить.
А это неликвид, замороженная в товаре «оборотка», площади хранения и тд. На одной скорости «генерации» мы так далеко не уедем. Наверное надо брать в расчёт все элементы и считать экономическую целесообразность ускорения «генерации», а то как бы не получилось что будем рубль по 90 копеек продавать. Вчера в один магазин заходил весь неликвид по закупочной выложен на прилавке.
Быстро генерировать за счёт своей прибыли как то не по «бизнесменски». Так и без штанов легко остаться.
Это и до ТОС было. Всегда держали на под рукой ходовой товар, а то что редко продаётся под заказ. Для того кто пробовал что то сам продавать это и без ТОСа вполне очевидно.
(93) Но и в том, и в другом случае они свои деньги получили, а то, какие затраты были понесены продавцом в 1 и 2 случае, это вопрос интересный:) Но это так, лирика. Всеже ждем решения «боли планирования»
(94) это и ТОСу вполне очевидно, что всем это очевидно. Там так и написано, в книге — мы ничего нового не придумали, просто здравый смысл.
про это в ТОС много написано, там все эти вопросы решены. Почитайте, вам понравится, даже если применять не будете.
(95) скорость генерации денег — это внутреннее свойство системы. Еще его можно назвать «эффективность», если добавить затраты, которые вы отметили.
Имея систему со скоростью генерации денег 1 млн рублей в день, вы за месяц генерируете 30 млн. рублей.
Имея систему со скоростью генерации денег 10 млн рублей в день, вы за месяц генерируете 300 млн рублей.
Тут вроде все понятно, но обычно друзья не обращают внимания на ключевое понятие: эффективность — это внутреннее свойство системы. И как-то не обращают на него внимание, думая над вопросом «как увеличить продажи?».
Но вы правы, оффтоп пошел. Про ТОС напишу отдельно.
(97)
Имея систему со скоростью генерации денег 10 млн рублей в день, вы за месяц генерируете 300 млн рублей.
Осталось дело за малым, поднять продажи в 10 раз… делов то….
(98) вот ровно про это я и написал выше:
надо не поднять продажи, а ускорить систему, их генерирующую. Надо внутрь системы смотреть, а не вокруг нее — на рынки или новые технологии. Внутри все скрыто.
Вполне возможно, что в бюрократии, той же заявке. Это надо наблюдать и измерять.
(99)Это в теории так хорошо звучит.
На практике откройте магазинчик, на маленький островок в ТЦ надо 100 — 200 к рублей, вот там на собственных деньгах проверьте состоятельность теории. А именно увеличьте в 10 раз скорость генерации без увеличения продаж(количества продаж, среднего чека и тд).
Что будете генерировать если количество покупателей в единицу времени не увеличилось?
(100)
это отличный вопрос, и он тоже в книге рассмотрен.
Это ограничение вне вашей системы, т.е. ограничение рынка. В этом случае нет смысла увеличивать внутреннюю эффективность системы, т.к. она будет избыточной.
Но, тут есть и обратная связь — повышение внутренней скорости может расширить ограничение рынка. Проще говоря, если все отгружают за 10 дней, а вы научитесь за 3 дня, то клиенты перейдут к вам.
Состоятельность теории я, разумеется, проверял, проверяю и буду проверять. И на своих деньгах, и на чужих.
Вы несколько раз уже повторили, что это все в теории. Вы же понимаете, что так оно и будет, пока вы не попробуете?
Не нужно рисковать большими чужими деньгами. Есть миллион дешевых процессов, на которых можно попробовать ТОС без риска для бизнеса. Если получится — взять что-то более крупное. И т.д.
(101)
Так пробуем. Не каждая теория подтверждается практикой. Или можно предположить что мы «не умеем её готовить», тут сложно дать однозначный ответ.
Так в этом вся соль. Как раз ограничением и является количество этих самых покупателей в единицу времени.
(97) Это понятно, я к тому, что не зная конкретное предприятие нельзя сделать однозначный вывод, что увеличение прохода без изменения других, не известных нам, параметров приведет к увеличению прибыли.
(103) мне кажется, важно не искать отговорки вроде «не зная конкретное предприятие, нельзя сделать однозначный вывод, …».
Если есть предприятие, и там есть 1С, и оно не маленькое, значит что? Там есть программист 1С.
А он знает предприятие. А мы знаем его. Вместе разберемся.
А то сидим все по углам, огрызаемся друг на друга, типа «да вы не знаете, какие тут у меня условия», а дело на месте стоит.
ТОС — это фреймворк. Как платформа 1С. Сам по себе ТОС ничего не стоит, как и платформа 1С.
Есть такие проблемы, которые «голым 1С» не решить. Для некоторых нужен ТОС, для некоторых metadata.js, для некоторых Scrum, для некоторых яндекс clickhouse и т.д.
Хочешь решать проблемы — придется разбираться во фреймворках. Это, наверное, всем очевидно.
Захотел красивую диаграмму — пошел курить Google Charts, например. Покурил, попробовал на маленьком примере, встроил в продакшн.
Захотел снабжение улучшить — пошел курить ТОС. Покурил, попробовал на маленьком примере, встроил в продакшн.
Не пускают в снабжение — так снабжение и в ИТ-отделе есть. Я на сис.админах тренировался, на закупке компов (расскажу в статье про ТОС).
(102)
мне кажется, главное — себя не обманывать.
Я много — МНОГО — раз видел, как компании тратят массу сил, средств и времени на снятие такого ограничения — количества клиентов. Внедряют CRM, создают отдел маркетинга, делают красивый сайт с интернет-магазином.
А клиенты, которые были, есть, и будут, продолжали ЖДАТЬ, потому что внутренняя скорость системы только снижалась — как раз из-за тех самых заявок и внутренних согласований, про которые вы говорите.
Вот вам примеры из моей практики:
1. раньше согласовывали КД на детали один раз, при аудите поставщика, потом кто-то придумал согласовывать КД каждый раз, по каждой поставке. Это + 2 дня;
2. раньше согласовывали протокол цен на год, и не меняли их, потом кто-то придумал согласовывать цену каждый раз, по каждой поставке. Хотя цена не менялась. Это + 1-2 дня.
3. раньше согласовывали и сдавали юристам договор один раз в год, потом кто-то придумал согласовывать, подписывать на бумаге и сдавать юристам каждую спецификацию. Это + 1-7 дней.
4. раньше конкурентный лист составляли раз в год, потом кто-то придумал делать это на каждую закупку. Номенклатура та же, поставщик тот же, цена и условия лучшие (их же в начале года выбрали), но вот чот как-то так. Это + 1 день.
5. где-то посередине, когда уже был п.3, спецификацию согласовывал только начальник закупок. Потом решили добавить всю братию — юристов, бухгалтеров, главного инженера, финансистов. Это еще + 1-3 дня.
Это все — вариации на тему внутренней заявки. Безопасность закупа не изменилась. Как случались косяки, так и продолжили случаться.
А кто все это придумал? Бюрократы, обслуживающие подразделения, которым понравилось встраиваться в живой процесс генерации денег. Бухгалтерия, финансисты, юристы, служба менеджмента качества и т.д.
А клиенты продолжали ЖДАТЬ.
P.S. вы говорили, что нет грустных историй — вот она. Люди не хотели смотреть внутрь системы, искали проблемы снаружи. А система за это время быстро засралась.
Разумеется, я не утверждаю, что у вас также. Просто воочию видел, как люди ошибаются, думая, что надо только клиентов побольше привлекать, что в этом главная трудность.
(104) Есть такие проблемы, которые можно решить только сменой топ-менеджмента/собственников компании. Если в этом может помочь ТОС или Scrum хотелось бы о таких случаях услышать…
(106) да я не об этом. Вы вот посмотрите на свои комментарии со стороны. И на комментарии Боряна заодно.
Они однотипные — херня это все, веками так делалось, да они лучше знают, да мы рукожопые, куда нам, и ты рукожопый, и теории все от лукавого, у нас все не так, мы особенные, но делать ничего не будем, да там вообще ничего нельзя сделать, только ТОПов уволить, а лучше никого не уволить, вообще оставить все как есть, да нахер все это.
Мы ж не такие. Мы — инженеры, наше дело — создавать.
Про то, как поможет ТОС или Scrum, конечно расскажу — все что знаю. И жду, что вы расскажете все, что знаете. А что не знаете — попробуете, и расскажете. И я попробую, что не знаю, и расскажу.
(107) Странно вы комментарии читаете. Я нигде не говорил, что предлагаемые вами подходы не работают в принципе. Я говорил, что у любых теорий есть ограничения в применимости, и об этих ограничениях нужно знать, и их учитывать. И как из этого у вас получилось, что я предлагаю ничего не делать мне не понятно.
Статьи ваши безусловно полезны, читаю их с интересом. Если не хотите видеть от меня комментариев с критикой — их не будет.
(108) ладно, давайте забудем. На эмоции был.
(93)
Как-то странно вы считаете…
В первом случае, к времени продажи нужно еще, как минимум, прибавить время нахождения лампы на складе, а во втором, вычесть время, когда была оплата поставщику за ШРУС, только после этого получится «Скорость генерации денег»
(110) давайте переформулируем в «скорость генерации дохода», если так проще.
Зачем нам в скорости генерации дохода время нахождения ШРУСа на складе?
(111) Простой случай.
Никаких заказов нет.
В понедельник купили ШРУС, в пятницу продали ШРУС. Какая «скорость генерации дохода» на продаже ШРУСа?
Сложнее случай:
В понедельник получили заказ на ШРУС, получили предоплату, в четверг получили на руки запчасть, в пятницу отдали ШРУС. Какая скорость генерации?
Условие: До тех пор пока не выполнили обязательства перед покупателем никакой доход мы ещё не получили.
(112) а вы знаете ответ?
(113)Нет. Знал бы не спрашивал 🙂
Мне же нужно понять методику расчета скорости генерации денег. Она я так понимаю измерима и должна как то рассчитываться.
(111)
Просто у меня как-то возникло немного другое восприятие ТОС.
Держа ШРУС на складе, получим ли мы от этого больше денег? — на первый взгляд не очевидно.
Станем ли мы расходовать меньше денег? — вроде бы нет.
Уменьшатся ли связанные деньги внутри системы? — однозначно увеличатся.
(115)
Мы говорим про «больше денег» или про «скорость генерации» ?
(116)
В моем представлении «Скорость генерации» — это «Больше денег» в единицу времени. Не?
(117)
Наверное.
Но когда вы пишите «Держа ШРУС на складе, получим ли мы от этого больше денег?» без указания «в единицу времени» то это сбивает с толку. Без указания в «единицу времени» можно предположить что «больше» от времени не зависит.
Видимо не правильно вас прочитал.
(114)
По Детмеру —
Производительность по денежному потоку (Throughput, Т) – это скорость, с которой система в целом генерирует доход в результате продаж. Строгое математическое определение для T и его связь с I и ОЕ вытекает из выражения баланса денежного потока:
CF (Cash Flow, денежный поток) = T – ОЕ ± I, где T – ОЕ = NP (Net Profit, чистая прибыль).
В динамическом виде это же выражение имеет вид:
dCF/dt = T – ОЕ – dl/dt,
где t – время. Его можно прочесть как «приращение денежного потока равно скорости генерации дохода минус операционные расходы и изменение связанного капитала компании»
(112)
А как посчитаете, так и будет. Я считал скорость конкретной цепочки — от появления покупателя до получения всех его денег. В вашем примере, если покупатель пришел в пятницу, и через 5 минут ушел со ШРУСом, то стоимость ШРУСа поделить на 5 минут.
Во втором вашем случае стоимость ШРУСа надо поделить на неделю.
Фишка в том, что формула прохода — абстрактная, это «скорость генерации единиц цели». Что есть единица цели — решаете вы, как архитектор системы.
Покупка ШРУСа — это не часть процесса генерации дохода. Это полностью переменные расходы в данном случае, и они одинаковы в любой момент покупки — хоть за день до продажи, хоть за неделю.
Об этом хорошо сказал Таичи Оно (цитату привел Голдратт в своей статье «Стоя на плечах гигантов»), отвечая на вопрос, чем занимается Toyota: «Все, что мы делаем, — это смотрим на время от момента поступления заказа от клиента до момента, когда мы получаем деньги. И мы работаем над сокращением этого времени».
Цель ТОС — ровно та же. Сократить время от появления потребности до ее удовлетворения и получения денег.
Разумеется, там еще хороший багаж методов, как держать низкий уровень запасов, как рассчитывать их уровни, и т.д.
(119) есть отличия от моего примера?
Только я не учитывал I и OE, считая их постоянными в обоих примерах.
(115)
больше денег мы получим не от того, что он на складе, а от того, что когда придет покупатель, мы сразу получим его деньги. А затраты на покупку ШРУСа одинаковы как при покупке заранее, так и при покупке под заказ.
Ну и остальные клиенты будут приходить к нам, когда узнают, что ШРУС в наличии.
Я пошел в магазин, потому что в автосервисе ШРУС под заказ ждать 2 недели, а в магазине 4 дня. Автосервис сэкономил на складе, но не получил моих денег.
Насчет денег в системе переживать не стоит. Если работает ТОС, то при той же стоимости склада радикально меняется качество его наполнения, в результате чего увеличивается проход. Много хороших, качественных примеров из личной практики Голдратта есть в его книге «Выбор» — очень рекомендую, если не читали.
(122)
Всегда ли?
Вот давайте предположим, что у нас вместо лампочки, допустим, рама от Лэнд-Крузера. Рама от Лэнд-Крузера стоит чуть дешевле, чем сам Лэнд-Крузер, и как-бы желающих менять раму каждый день не так уж и много.
Я это к чему все… Было бы замечательно, если бы вы явно обозначали в каком контексте вы ведете рассуждения, какие границы применимости у данных методов, какие параметры вы принимаете как не существенные в конкретном примере.
Просто получается, когда люди примеряют ваши примеры к области деятельности отличной от вашей они получают некоторый когнитивный диссонанс, и выходит — «Фуфло все ваши теории»
(124)
нет, разумеется. Я подумал, что вы хорошо знаете ТОС и особенности его применения.
Держать или не держать раму крузера на складе — это предмет вычислений на основе фактического потребления.
(126) вроде все правильно пишете, только выхода не видно и вывод не ясен.
Ну, ежу понятно, что владелец рискует больше наемных рабочих.
Тому же ежу понятно, что большинство бизнесов пытаются что-то изменить — автоматизацию сделать, бизнес-процессы наладить, ТОС внедрить, систему сбалансированных показателей и прочие штуки.
Ежу-же понятно, что в большинстве случаев владельцы делают изменения чужими руками — руками людей, которые не владеют их деньгами.
Ваша-то мысль в чем? Вы, как бывший совладелец бизнеса, против изменений чужими руками? Ради Бога. Не верите в ТОС? Ради Бога. Не верите тому, кто говорит, что ТОС поможет? Ради Бога. Требуете от консультантов наличия собственного бизнеса? Ради Бога. Требуете финансовой ответственности за результат? Ради Бога. Ваше право.
Ну, не будут с вами работать, сами как-нибудь все сделаете.
Есть масса людей, которые сами не умеют или просто некогда. Рискуют, дают небольшой участок бизнеса для тестовых изменений. Смотрят на результат. Понравилось — продолжают. Не понравилось — думают, что делать дальше.
Или просто утверждаете, «что все это неправильно»? В смысле жизнь неправильно устроена.
(125)
Я с вами не спорю. Просто пытаюсь добавить «глубины» вашим рассуждениям. Давайте приведу аналогию…
Допустим, по радио передача «Вопрос адвокату», звонит человек и спрашивает: «У меня умер очень дальний и очень богатый родственник. Могу я претендовать на наследство?». Там обычно рассуждают, — «вот если к тому что вы сказали присутствует факт1 и факт2, то вы получите такой результат, если факт3 и факт4 то другой». Что на мой взгляд позволяет сторонним слушателям делать выводы по поводу своих ситуаций. Жизнь — она чуть более многогранна.
(128) так у нас другой формат.
Для сторонних слушателей — публикации. В публикациях авторы стараются раскрыть тему.
Тут — комментарии, где конкретный человек задает вопрос конкретному человеку. В комментарии обычно не раскрывается контекст и тема. Если я предполагаю, что вы знаете ТОС, то пишу, исходя из этого предположения. И пишу конкретно вам.
(126)
Теорию знать никогда лишним не будет. Человек нашел ответы на свои вопросы, возможно вы найдете ответы на свои.
(126)
В основном, конечно, наибольший эффект все теории дают на предприятиях с большим числом составляющих и решают они проблемы немного другого характера, чем те которые возникают у малых предприятий.
(79)
А можно вернуться к Заявке?
Как заявка по Вашему тормозит скорость генерации денег?
Т.е. Вы в какой-то момент ранее сообщили поставщику устной или письменной Заявкой, что собираетесь покупать деталь 10 раз в месяц, Подписали с поставщиком договор. И поставщик вам гарантировал поставку.
А если Поставщику устной или письменной Заявкой ничего не сообщали, договора с поставщиком нет, то и риски что на 10 поставке Вы не получите товар вовремя ложатся на Вас.
(134)
вы же понимаете, как она тормозит. Пришел клиент, принес деньги, говорит дай товар. Без внутренней заявки вы можете отгрузить завтра. С внутренней заявкой получится только через 5 дней. Имея буфер на складе, вы можете отгрузить сейчас. Имея буфер на складе покупателя, вы можете отгрузить вчера.
да, в начале года мы согласовали цены, условия поставки, сроки исполнения и интегрировали наши системы, чтобы он узнавал о необходимости поставки раньше нас. Заодно прописали в договоре, что он должен иметь на складе 20 шт номенклатуры, которую нам поставляет.
в данном случае на вас ложатся риски за то, что вы наняли плохих юристов и снабженцев.
(135)
Все равно не понял…:-) У Вас Заявка есть, но не привязана к конкретному Заказу. Видимо считаете выгоднее брать на себя эти риски.
Перефразирую:
1. Заранее подали заявку Поставщику о планах закупки (ориентировочные сроки и объемы)
2. Поставщик Выставил спецификацию цен и свои доп условия (Наверняка поставщик изменит цену, если регулярно откажетесь закупать детали)
3. Подписали договор с графиком (для сохранения уровня цен) приобретения у Поставщика деталей
4. По поступлению Заказа от Заказчика система автоматически формирует (возможно виртуальное) поручение Поставщику отгрузить на Ваш склад деталь.
5. Заказчику отгружается деталь из имеющихся на складе.
Все документы присутствуют. И геде тут Бюрократия тормозящая генерацию денег? У кого-то процесс синхронный, у кого-то асинхронный, но набор документов одинаковый и алгоритм расчета дефицита деталей будет одинаковый.
Другое дело, что в существующих системах недостаточно учтено реквизитов, чтобы предоставлять универсальные решения.
(136)(137) Что-то непонятно, вы точно оба про производственное предприятие говорите?
(138) конечно, принципиальной разницы-то нет, на производственном циклы длиннее.
Я говорил про предприятие, которое производит железяки, собранные из множества деталей, часть которых оно производит само, часть заказывает у поставщиков.
(139) В моем понимании источником заказа на закупку является план производства, и все длительные согласования (договора на поставку, тендеры, спецификации) происходят на этапе запуска изделия в производство. Если под это изделие уже заключены договоры на поставку комплектующих, то единственное согласование, которое нужно — это согласование финансового блока на включение финансирования в БДДС.
Возвращаясь к инструменту планирования — он должен уметь отвечать на вопросы более высокого порядка, чем обеспеченность уже принятых заказов.
(141)
какие, например?
Данная статья как раз о том, что нет ответов на элементарные вопросы.
(142) Например, нам поступило одновременно 2 заказа, можем ли мы оба заказа взять, если нет, какой из них выгоднее, если надо взять оба, то какими уже запущенными заказами можно пожертвовать, и сколько нам это будет стоить и т.д…
(137)
(138)
Структура внутренней заявки не сильно отличается от структуры внешней заявки (Потребитель, Поставщик, Цель, Ресурс, Объем цели, Объем ресурса)
1. Заявка Заказчика службе Реализации
2. Заявка службы Реализации на Производство
3. Заявка Производства в службу Обеспечения
4. Заявка службы Обеспечения к Поставщикам
5. Заявка Поставщика Финансовой службе по оплате
Составлять заявки можно и независимо друг от друга. В вашем случае служба Реализации без заявок Заказчика берет на себя ответсвенность — заранее планирует резерв ресурсов у внутренних служб и внешних поставщиков
Будем реалистами. Поставщик не может обслужить бесконечное число картриджей за фиксированный период времени, значит в любой момент может передвинуть время обслуживания, значит никакая система не ответит, какой очередной картридж не будет обеспечен заправкой.
(145) Вы что, реально так работаете? На каждый заказ вся цепочка полностью? А что производите, если не секрет?
(144) лично мое мнение — вопрос неправильный, технический. Чтобы на него ответить, городится большой огород из технических расчетных систем. Раз уж у нас веточка про ТОС, то ТОС рекомендует не заниматься сложными расчетами, а заниматься реальными проблемами.
В вашем примере — надо понять, почему вообще мы считаем проблемой поступление сразу двух заказов.
(145)
2. Заявка
3. Заявка
4. Заявка
5. Заявка
это все реальные заявки? Прям документы, бумажные или электронные?
если будем реалистами, то будем реалистами — за 6 лет была одна задержка, когда понадобился барабан к очень древнему картриджу. Рассудили, что проще купить другой принтер.
(148) Не считаем мы проблемой, а просто хотим знать ответы на эти вопросы. Видимо, пример слишком упростил, раз у вас экстраполировать не получилось…
(149) Объемы печати какие были? Тысяч 50-60 в день регулярно печатали?
(152) в таких единицах не измерял, если честно. Это важно?
Принтеров 20 наверное было, может 30 под конец.
(155) Если всего 20 принтеров, то да, не важно в общем…
(149)
Любое крупное производство с мелкими сериями.
(149)
Все сложнее, разные службы, множество документов и подходов к их оформлению.
Но суть не в этом. Есть перечень направлений (финансы, закупки, производство, …), перечень этапов (планирование, управление, исполнение, учет), ключевые вопросы (что?, когда?, сколько?, кто?…) — их полный набор независим от деятельности предприятия и должен присутствовать в любой системе.
Проблема в том, что некоторые информационные процессы не отражаются в реальных документах (происходят устно), некоторые документы объединяются для упрощения процедуры их согласования, следовательно автоматизированные системы создаются не универсальными а урезанными или с оптимизацией под конкретное предприятие.
А чтобы система стала универсальной, она должна автоматизировать (грубо) декартово произведение 12 Этапов Х 10 Направлений Х 10 Направлений = 1200 Бизнес операций (очень грубо).
Для расчета обеспеченности по заказу необходимо анализировать все эти 1200 Бизнес операций.
(160) вот, прошу прощения, типичный инженерно-исполнительный подход. Сказали сверху, что система должна учитывать
— все, побежали учитывать. Слава Богу, такой огромный балласт не поддается учету. Поэтому систем такого рода не существует.
(162)Вот уж эта задача особо сложной не выглядит с технической точки зрения, а вот организационно конечно вызывает большие вопросы. Но, кстати, все эти заявки могут иметь смысл, если продажи, снабжение, производство, финансы — это все разные юридические лица. И такое встречалось на практике…
(162)
Инженерный, потому-как все хотелось бы по полочкам разложить. Но ни как не исполнительский…
(165)
Достаточно чтоб это были разные службы со своими подслужбами на крупном предприятии.
Но опять же, не могу донести суть…
В реальности на предприятии межет не создаваться такое количество заявок в бумажном виде. Действительно, если есть спецификация, маршрутная карта, то службы обеспечения и без производства сформируют свои графики поставки материалов расписывая в амбарных книгах в колонках партии реализуемой продукции, в строках перечень материалов, а всякие нестыковки с производством по времени, определение приоритета выдачи материалов корректируются с мастерами тут же приписками и зачеркиванниями в ячейках.
Но, в компьютерных системах нестыковки зачеркиванием не исправишь. Чтобы компьютерная система выдавала обеспеченность в соответсвии с приоритетами производства, ей необходимо как-то сообщать эту информацию, даже если мастер производства сообщил о своих приоритетах устно.
Заявки производства могут генерится (автоматически) незаметно для пользователей на основе сроков отгрузки продукции, маршрутных карт и спецификаций. Пользователи даже могут не знать, что в системе есть такие документы, если им нет потребности в корректировки производственных приоритетов.
ИМХО: Универсальная автоматизированная система контроля обеспеченности должна опираться на всю цепочку заявок и многих других документов, о существовании которых пользователи могут даже не догадываться и никогда в этой системе не регистрировать. Эти документы в упрощенном контроле могут генерироваться автоматически. Памяти на диске жалеть не стоит. Поддержка алгоритмов сбора отчета по обеспеченности для различных упрощенных случаев обойдется дороже.