Боль планирования в 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 делать правильным, а какой – неправильным? Почему бюджетирование – правильное, а планирование – неправильное
См. также
Специальные предложения
если у вас есть какое то решение , или идеи поделитесь ими с сообществом
Очень узкая постановка проблемы. Рассматриваю проблему несколько шире:
Нормирование (что, в какой пропорции, за какой срок?):
1. Номенклатурные справочники;
2. Спецификации, Курсы обмена, Замены (Пропорции и сроки);
Планирование (кто, кому, когда, в каком объеме?):
3. Справочник Потребителей и Поставщиков (подразделений, цехов, складов);
4. Заявки потребителей (Крайняя ожидаемая дата поставки, обьем продуктов)
5. Графики поставщиков (Начальная планируемая дата поставки, объем ресурсов)
Управление (кто МОЛ-исполнитель, в каком месте (по какому счету), в каком объеме?):
6. Реестр договоров с Контрагетами и МОЛ;
7. Реестр мест хранения, счетов;
8. Требование Потребителя (МОЛ-получатель, место (счет) получения, объем продукта)
9. Приказ (резерв) Поставщика (МОЛ-отправитель, место (счет) отправки (отпуска), объем ресурса);
Исполнение (факт расхода и прихода):
10. Справочник паспортов номенклатуры, партий;
11. Документ расхода отправителя (фактическая дата);
12. Документ прихода получателя (фактичекая дата);
Вот тут pain, про SQL и регистры тока мечтаю...
Короче, чтобы удовлетворить пользователя, необходимо расуручивать полную обеспеченность по заказу про:
- Готовую продукцию, ожидающую отгрузку
- Незавершенное производство, ожидающее выпуск
- МПЗ, ожидающее списания в производство
- Обязательства поставщиков по поступлениям товаров и услуг
- Денежные средства, ожидающие оплаты поставщикам
- Обязательства заказчиков по платежам за продукцию
А это, в одном запросе всю базу надо охватить, сотни справочников, документов и регистров. Сотни подзапросов для каждого случая (деньги по одним алгоритмам, материалы по другим).
Смысл же (7) в том, что независимо от деятельности:
- Управление денежными средствами;
- Расчеты с поставщиками и покупателями;
- Управление работниками;
- Эксплуатация оборудования;
- Управление запасами;
- Производство;
- Управление готовой продукцией;
Общие вопросы пользователя остаются одинаковые:
- Какие не исполнены приказы, требования? Кто виноват? Что делать?
- Какие просрочены графики, заявки? Кто виноват? Что делать?
- Какие не соблюдены нормы, стандарты? Кто виноват? Что делать?
Раз вопросы одинаковые, есть надежда (идея), что в ERP не нужны СОТНИ справочников, документов и алгоритмов, их можно сократить до дюжины (12 перечисленных) универсальных. Тогда и обеспеченность собирать можно.
Идея простая, но сходиться вот никак не хочет.
Надеюсь, "Боль планирования" Вас больше не мучит!
Такие вопросы задают люди, которых интересуют не реальные проблемы предприятия, а мышиная возня с женским подходом (вопрос "кто виноват?" их выдает).
И вопросы эти - не для того, чтобы решить проблемы, а чтобы отсрочить их решение. Пользователи ведь знают, что вы не ответите.
Ответить просто. В каждом документе имеется ссылка на ответственное подразделение, ответственных лиц, на крайний случай, автора документа.
Вот к этому хотел прибавить "как глубока кроличья нора". Что свет есть, но это еще не выход...
- Потребность в поставщике описана в спецификации
Кто виноват:
- Ответсвенный за исполнение заказа покупателя, если не составил заявку (с крайней датой поставки) на ответвенного по поставщикам в соответствии со спецификацией
- Ответвенный по поставщикам, если не сформировал или нарушил график поставки по поступившим заявкам
вам не кажется, что эта схема отдает излишней бюрократией? Человек принес потребность, которую надо простыми внутренними усилиями превратить в деньги. А мы заставляем его какую-то заявку составлять. Он итак все описал в заказе покупателя.
мне кажется заявка от потребителя ( прод. менеджера) все таки нужна в виде заказа или какого-то задания на закуп (для снабженца) , во первых сроки поставки по одному заказу покупателя могут отличаться , во вторых ( если возможно) по этой заявке отслеживается состояние выполнения в третьих поступления на склад обосабливаются по каждой заявке
Мы не знаем кто будет поставщиком. У нас их десятки-сотни. По одному заказу покупателя на изделие я должен сделать заказы тридцати поставщикам на разные комплектующие(материалы) которых на конкурсной основе я должен выбрать из сотни. На основании заявки на закупку формируются запросы к поставщикам, составляется конкурентный лист который потом проходит разные этапы согласования(нач отдела, производство, фин отдел, СБ итд) и выбора поставщика. И вот когда поставщики выбраны, заявка на закупку одобрена мы делаем заказ поставщику. По крайней мере в крупных компаниях где мне доводилось работать было так.
Требования к материалам, условиям закупки, срокам проведения закупки, ценовому диапазону, срокам и условиям хранения на складе и тд.
Ярлыки развешивать довольно простое занятие. А вот как определить что есть "бюрократия", а что производственная необходимость? Где та черта где мы можем сказать что вот это "бюрократия", а вот это правильно выстроенный процесс? Есть какие то измеримые, универсальные критерии?
Я встречал такие цепочки, но они делались при первой сделке с поставщиком, включая аудит.
Требования к материалам, условиям закупки и т.д. - они разве не постоянны? Срок, если он не абсолютный, а относительный (30 дней, например) - вроде тоже константа.
Универсального ничего в жизни нет. Есть общепринятые. Например, прибыль. Или проход (в ТОС) - скорость генерации денег.
Лично мое мнение - такие длинные цепочки генерируют обслуживающие подразделения, которые не способны качественно выполнять свои обязанности. В данном случае качественно - это асинхронно.
Асинхронно - это когда обслуживающие не вмешиваются, не тормозят основной процесс. Синхронно - когда вмешиваются и тормозят (как в описанном вами случае).
Типичный пример - согласования. Зачем согласовывать каждую поставку материала или детали, если мы покупаем ее 10 раз в месяц, не меняя тех.требований, КД и т.д.?
Сроки проверять? Так они в договоре прописаны.
Условия оплаты проверять? Так они в договоре прописаны.
Фин.состояние поставщика проверять? Так подключите сервис и проверяйте сами, или сделайте подписку на изменение состояния.
Вроде бы - чего такого? Ну согласовывают люди, жалко что ли.
Жалко - они снижают скорость генерации денег.
Если без согласования от точки заказа покупателя до точки отгрузки пройдет 10 дней, а с согласованием - 15 (это еще оптимистично), то скорость генерации денег системой падает в 1.5 раза. Это - влияние синхронной бюрократии.
Но я не говорю, что не надо всех этих согласований - пусть будут. Главное - правильно момент для них выбрать. Не синхронно, не во время сделки, не на пути денег через систему, а асинхронно - параллельно, не мешая процессу.
Вот вам гиперболическая метафора. Впихивать все согласования и проверки в процесс продажи - все равно, что выполнять расчет себестоимости каждый раз, когда пользователь нажимает "Сформировать" в отчете "Ведомость по учету МПЗ и затрат".
Хотя, убрать согласования в асинхронный поток - это полумера. Еще лучше - сделать асинхронным снабжение. Это тоже ТОС.
То же приведу метафору. Практикующий врач никогда не ставит диагноз не видя пациента и не зная истории болезни. А вот люди занимающиеся разными оккультными вещами с удивительной лёгкостью ставят диагнозы и пытаются лечить по фотографии.
Где то работает система "Заказ покупателя - Заказ поставщику", где то появляются дополнительные элементы в виде "заявка на закупку", согласование и тд. Это определяется потребностью предприятия или процесса, а не субъективным ощущением того как должно быть правильно(по ТОСу и тд).
Можно придти и сказать: "А давайте формализуем процесс, выработаем критерии и уберём из цепочки заявку на закупку" и посмотрим какой будет результат. Но один собственник уже популярно на это объяснил. "Я как собственник за любое своё не правильное управленческое решение отвечаю рублём. Вы готовы ответить рублём в полном объёме за ваши решения?".
Вообще меня всегда удивляет как бизнес-консультанты раздают советы по ТОСам, Линам, сигмам и всегда железобетонно уверены в правильности их советов. Особенно удивляет когда они это делают не видя предприятия, не понимая масштабов, решаемых задач, проблем.
По поводу "Да я сто раз так делал". То же довольно сомнительно предприятия разные, процессы разные.
Из личного опыта то же могу рассказать как пришёл на одно предприятие где меня просили сделать одну систему. Думал да что там делов то на 2-3 месяца, к тому же с похожими предприятиями я уже работал. А потом я только 6 месяцев вникал в происходящее и это при том что я работал внутри организации по 8 часов и имею опыт и знания по анализу процессов и тд. Но когда приходили "сторонние" консалтеры, которые обещали сделать чудеса за 2-3 месяца я то понимал чего стоят их обещания.
Проход в ТОС учитывает что если не пройти согласования и проверку СБшниками контрагента можно вообще остаться без денег с невероятной скоростью?
Лично был свидетелем того как пропадали десятки, сотни миллионов и даже целые железнодорожные составы готовой продукции даже с проверкой СБшниками и с контрагентами с которыми давно вроде работали.
Так никто ничего не тормозит. Всё заложено в процесс. Согласование заявки на закупку просто часть процесса. При чём необходимая часть.
Зависит от суммы закупки. Где то до 1 млн рублей фин дир не глядя подписывает заявки, а где то и 100К надо согласовать в 3х кабинетах.
Первая буква в слове ТОС это "теории". В теории всегда всё просто и легко. На практике иначе.
Условия оплаты проверять? Так они в договоре прописаны.
Фин.состояние поставщика проверять? Так подключите сервис и проверяйте сами, или сделайте подписку на изменение состояния.
Так нет у нас никаких договоров. Мы не знаем кто у нас поставщиком будет. У нас 30 поставщиков на конкурсной основе.
тут два момента. Во-первых - ставят. И весьма успешно.
Во-вторых - мы ведь про глубинные причины проблем, а не про конкретные болезни. Бюрократия - это ошибка в фундаменте. Как неправильное питание, отсутствие двигательной активности, плохой воздух и т.д. Любой врач, занимаясь лечением конкретной болезни, понимает, что причина - глубже. Но уже не говорит об этом, т.к. задолбался. Люди ведь хотят таблетку, а не образ жизни или мыслей.
Но мы-то с вами не такие.
совершенно верно. Только мы-то с вами не бизнес-консультанты, правда? Мы 1Сники, мы внутри компании сидим.
для управления рисками есть другая дисциплина, она так и называется - управление рисками. Там много статистики, вероятностей, думать много надо. Сейчас нейросети этому научили - например, в банках, чтобы оценивать риски выдачи кредита. Когда думать не хочется - просто проверяют все подряд. Как вахтеры.
это ж проверить можно, есть масса методов. Разумеется, если хочется эффективность повысить, балансируя ее с надежностью и безопасностью.
Расскажете о своей практике применения ТОС? Особенно о негативной. Позитивной полно итак, а негативной мало.
а с этими 30 поставщиками разве нет договоров?
Мой опыт работы в медицинском центре(больнице) и общение с врачами говорит об обратном. Ни один врач по описанию с чужих слов не ознакомившись с результатами анализов и историей болезни диагнозы не ставит и лечение не назначит потому что он за это ответственность несёт(вплоть до уголовной) и дорожит своей репутацией профессионала. Одни и те же симптомы могут быть у сотни различных заболеваний. И любой практикующий врач знает как пациенты любят придумывать себе симптомы и болезни про которые они смотрели в сериале "Доктор Хаус".
Как в анекдоте: "Объявление в приемной врача: «Просим пациентов не обмениваться симптомами. Это очень затрудняет диагноз»."
То есть заявка на закупку это априори бюрократия?
Если для управления рисками мне нужна процедура согласования(заявки на закупку), а по ТОС нет, что делать? Вы же утверждаете что по ТОС правильно убрать лишний "бюрократический" элемент из цепочки. Но опять же у нас появляется управление рисками. Как тогда правильно то?
Какие договора? Это "пул" поставщиков отбор из которых выполняется в процессе согласования закупки. И это не всегда "лучшие" условия исходя из рационального подхода(вроде самой низкой цены и тд).
К любой теории я отношусь как к "теории" по этому не создаю культа из "модных" учений. Беру какие то приёмы если они мне интересны.
О провалах никто не любит рассказывать. Все любят "истории успеха", наверное по этому и мало. Вы много пишите о провалах в соотношении с историями успеха, а они же были? Если учитывать что обычно выстреливает 10-15% из всех попыток. Где то конечно больше, где то меньше. Но в целом на одну удачную попытку приходится с десяток менее удачных.
По поводу "негативных" рассказать можно,но это напоминает тренинги для "бизнесменов" когда рассказывают много теории "бизнес тренеры без бизнеса", а потом когда не взлетело говорят: "Теория у нас правильная, это у тебя руки кривые, так что ты сам виноват". По этому всегда можно сказать что теория правильная, реализация хромает.
скоринг это хорошо, но пока что не везде применимо. Нейросеть к сожалению пока не научилась выезжать на производство поставщика и проверять наличие необходимого у него оборудования и возможностей выполнить взятые на себя обязательства. Но когда нибудь наверное так и будет. Сам сейчас делаю похожую систему, на анализе данных и обучении нейросети. Но там не про риски... там немного другое, хотя то же прогнозирвоание.
ок, у нас разный опыт общения с врачами.
конечно. Способ защиты системы и людей от рисков.
по ТОС не заявка не нужна, а скорость генерации денег надо контролировать. И любые изменения проверять на предмет влияния на эту скорость.
Ключевой вопрос - было ли управление рисками. Появилась ли заявка в результате анализа, прогнозирования и опыта, оправдана ли она. Или она как-то сама появилась, на всякий случай.
Не забывайте, что заявка - это просто один из способов избавиться от риска. Не единственный. Но самый простой для тех, кто за риски отвечает. Есть способы сложнее, меньше влияющие на скорость продаж. Другой вопрос, если управлятели рисков об этом не думали, ну или вообще не знают. Тогда они убедительно убедят директора, что только так можно гарантировать безопасность.
Такое часто у сис.админов плохих бывает. Ему говорят - нужна информационная безопасность. Он говорит - все, запрещаем интернет, личные ящики, флешки, ютуб, вайфай - все запрещаем, и будет тогда безопасность.
Можно просто поверить на слово, и вдвое удлинить все процессы, усложнить жизнь всей компании. А можно использовать современные технологии, с каждым риском разобраться по-отдельности, применить точечные меры и т.д., и никому жизнь не портить.
вы не уникальны - все так делают, вы не отличаетесь от остальных. И я о том же говорю постоянно.
Правильно понял, что вы не пробовали применять что-нибудь из ТОС на практике?
еще раз - мы с вами не бизнес-тренеры и не бизнес-консультанты. Мы 1Сники. Вы не делаете вид, что вы бизнес-консультант, я не делаю вид, что я бизнес-консультант. Мы занимаемся одним и тем же делом. Говорим как коллеги, равные друг другу, делимся опытом, помогаем друг другу.
Что там делают бизнес-тренеры и бизнес-консультанты - нам не важно. Важно только, что у них плохо получается - значит, они нам не конкуренты. Мы не пойдем по их пути, потому что этот путь ошибочен.
Так я вроде и не говорил что я отличаюсь от остальных.
Тогда можно вообще упростить. Делать всё в одном документе "Заказ покупателю" или "Заказ поставщику", а то наплодили тут сущностей бюрократы из 2х документов, так ещё и "заявки" какие то придумать хотят.
Заявка это не только способ избавится от риска, это так же элемент планирования и управления.
А откуда взялось предположение что это влияет на скорость продаж?
из практики. Вы же проверить можете.
Если продажа и с заявкой, и без заявки занимает одинаковое время - то влияния нет.
В магазине я пришел лампу ближнего света купить, она в наличии. Продажа заняла 3 минуты, отдал 400 рублей.
Потом пришел за пыльником шруса, его нет в наличии. Составили договор на поставку, через 4 дня привезли. Отдал те же 400 рублей, но продажа заняла 4 дня = 5760 минут.
Скорость генерации денег сами видите как отличается.
В первом случае снабжение и продажа работают асинхронно, во втором - синхронно. Асинхронно - это потому, что они знали, что я приду за лампочкой, и заблаговременно ее купили. Это по ТОС.
А это неликвид, замороженная в товаре "оборотка", площади хранения и тд. На одной скорости "генерации" мы так далеко не уедем. Наверное надо брать в расчёт все элементы и считать экономическую целесообразность ускорения "генерации", а то как бы не получилось что будем рубль по 90 копеек продавать. Вчера в один магазин заходил весь неликвид по закупочной выложен на прилавке.
Быстро генерировать за счёт своей прибыли как то не по "бизнесменски". Так и без штанов легко остаться.
Это и до ТОС было. Всегда держали на под рукой ходовой товар, а то что редко продаётся под заказ. Для того кто пробовал что то сам продавать это и без ТОСа вполне очевидно.
про это в ТОС много написано, там все эти вопросы решены. Почитайте, вам понравится, даже если применять не будете.
Имея систему со скоростью генерации денег 1 млн рублей в день, вы за месяц генерируете 30 млн. рублей.
Имея систему со скоростью генерации денег 10 млн рублей в день, вы за месяц генерируете 300 млн рублей.
Тут вроде все понятно, но обычно друзья не обращают внимания на ключевое понятие: эффективность - это внутреннее свойство системы. И как-то не обращают на него внимание, думая над вопросом "как увеличить продажи?".
Но вы правы, оффтоп пошел. Про ТОС напишу отдельно.
Имея систему со скоростью генерации денег 10 млн рублей в день, вы за месяц генерируете 300 млн рублей.
Осталось дело за малым, поднять продажи в 10 раз... делов то....
надо не поднять продажи, а ускорить систему, их генерирующую. Надо внутрь системы смотреть, а не вокруг нее - на рынки или новые технологии. Внутри все скрыто.
Вполне возможно, что в бюрократии, той же заявке. Это надо наблюдать и измерять.
На практике откройте магазинчик, на маленький островок в ТЦ надо 100 - 200 к рублей, вот там на собственных деньгах проверьте состоятельность теории. А именно увеличьте в 10 раз скорость генерации без увеличения продаж(количества продаж, среднего чека и тд).
Что будете генерировать если количество покупателей в единицу времени не увеличилось?
это отличный вопрос, и он тоже в книге рассмотрен.
Это ограничение вне вашей системы, т.е. ограничение рынка. В этом случае нет смысла увеличивать внутреннюю эффективность системы, т.к. она будет избыточной.
Но, тут есть и обратная связь - повышение внутренней скорости может расширить ограничение рынка. Проще говоря, если все отгружают за 10 дней, а вы научитесь за 3 дня, то клиенты перейдут к вам.
Состоятельность теории я, разумеется, проверял, проверяю и буду проверять. И на своих деньгах, и на чужих.
Вы несколько раз уже повторили, что это все в теории. Вы же понимаете, что так оно и будет, пока вы не попробуете?
Не нужно рисковать большими чужими деньгами. Есть миллион дешевых процессов, на которых можно попробовать ТОС без риска для бизнеса. Если получится - взять что-то более крупное. И т.д.
Так пробуем. Не каждая теория подтверждается практикой. Или можно предположить что мы "не умеем её готовить", тут сложно дать однозначный ответ.
Так в этом вся соль. Как раз ограничением и является количество этих самых покупателей в единицу времени.
мне кажется, главное - себя не обманывать.
Я много - МНОГО - раз видел, как компании тратят массу сил, средств и времени на снятие такого ограничения - количества клиентов. Внедряют CRM, создают отдел маркетинга, делают красивый сайт с интернет-магазином.
А клиенты, которые были, есть, и будут, продолжали ЖДАТЬ, потому что внутренняя скорость системы только снижалась - как раз из-за тех самых заявок и внутренних согласований, про которые вы говорите.
Вот вам примеры из моей практики:
1. раньше согласовывали КД на детали один раз, при аудите поставщика, потом кто-то придумал согласовывать КД каждый раз, по каждой поставке. Это + 2 дня;
2. раньше согласовывали протокол цен на год, и не меняли их, потом кто-то придумал согласовывать цену каждый раз, по каждой поставке. Хотя цена не менялась. Это + 1-2 дня.
3. раньше согласовывали и сдавали юристам договор один раз в год, потом кто-то придумал согласовывать, подписывать на бумаге и сдавать юристам каждую спецификацию. Это + 1-7 дней.
4. раньше конкурентный лист составляли раз в год, потом кто-то придумал делать это на каждую закупку. Номенклатура та же, поставщик тот же, цена и условия лучшие (их же в начале года выбрали), но вот чот как-то так. Это + 1 день.
5. где-то посередине, когда уже был п.3, спецификацию согласовывал только начальник закупок. Потом решили добавить всю братию - юристов, бухгалтеров, главного инженера, финансистов. Это еще + 1-3 дня.
Это все - вариации на тему внутренней заявки. Безопасность закупа не изменилась. Как случались косяки, так и продолжили случаться.
А кто все это придумал? Бюрократы, обслуживающие подразделения, которым понравилось встраиваться в живой процесс генерации денег. Бухгалтерия, финансисты, юристы, служба менеджмента качества и т.д.
А клиенты продолжали ЖДАТЬ.
P.S. вы говорили, что нет грустных историй - вот она. Люди не хотели смотреть внутрь системы, искали проблемы снаружи. А система за это время быстро засралась.
Разумеется, я не утверждаю, что у вас также. Просто воочию видел, как люди ошибаются, думая, что надо только клиентов побольше привлекать, что в этом главная трудность.
Если есть предприятие, и там есть 1С, и оно не маленькое, значит что? Там есть программист 1С.
А он знает предприятие. А мы знаем его. Вместе разберемся.
А то сидим все по углам, огрызаемся друг на друга, типа "да вы не знаете, какие тут у меня условия", а дело на месте стоит.
ТОС - это фреймворк. Как платформа 1С. Сам по себе ТОС ничего не стоит, как и платформа 1С.
Есть такие проблемы, которые "голым 1С" не решить. Для некоторых нужен ТОС, для некоторых metadata.js, для некоторых Scrum, для некоторых яндекс clickhouse и т.д.
Хочешь решать проблемы - придется разбираться во фреймворках. Это, наверное, всем очевидно.
Захотел красивую диаграмму - пошел курить Google Charts, например. Покурил, попробовал на маленьком примере, встроил в продакшн.
Захотел снабжение улучшить - пошел курить ТОС. Покурил, попробовал на маленьком примере, встроил в продакшн.
Не пускают в снабжение - так снабжение и в ИТ-отделе есть. Я на сис.админах тренировался, на закупке компов (расскажу в статье про ТОС).
Они однотипные - херня это все, веками так делалось, да они лучше знают, да мы рукожопые, куда нам, и ты рукожопый, и теории все от лукавого, у нас все не так, мы особенные, но делать ничего не будем, да там вообще ничего нельзя сделать, только ТОПов уволить, а лучше никого не уволить, вообще оставить все как есть, да нахер все это.
Мы ж не такие. Мы - инженеры, наше дело - создавать.
Про то, как поможет ТОС или Scrum, конечно расскажу - все что знаю. И жду, что вы расскажете все, что знаете. А что не знаете - попробуете, и расскажете. И я попробую, что не знаю, и расскажу.
Статьи ваши безусловно полезны, читаю их с интересом. Если не хотите видеть от меня комментариев с критикой - их не будет.
Как-то странно вы считаете...
В первом случае, к времени продажи нужно еще, как минимум, прибавить время нахождения лампы на складе, а во втором, вычесть время, когда была оплата поставщику за ШРУС, только после этого получится "Скорость генерации денег"
Никаких заказов нет.
В понедельник купили ШРУС, в пятницу продали ШРУС. Какая "скорость генерации дохода" на продаже ШРУСа?
Сложнее случай:
В понедельник получили заказ на ШРУС, получили предоплату, в четверг получили на руки запчасть, в пятницу отдали ШРУС. Какая скорость генерации?
Условие: До тех пор пока не выполнили обязательства перед покупателем никакой доход мы ещё не получили.
По Детмеру -
Производительность по денежному потоку (Throughput, Т) – это скорость, с которой система в целом генерирует доход в результате продаж. Строгое математическое определение для T и его связь с I и ОЕ вытекает из выражения баланса денежного потока:
CF (Cash Flow, денежный поток) = T – ОЕ ± I, где T – ОЕ = NP (Net Profit, чистая прибыль).
В динамическом виде это же выражение имеет вид:
dCF/dt = T – ОЕ – dl/dt,
где t – время. Его можно прочесть как «приращение денежного потока равно скорости генерации дохода минус операционные расходы и изменение связанного капитала компании»
А как посчитаете, так и будет. Я считал скорость конкретной цепочки - от появления покупателя до получения всех его денег. В вашем примере, если покупатель пришел в пятницу, и через 5 минут ушел со ШРУСом, то стоимость ШРУСа поделить на 5 минут.
Во втором вашем случае стоимость ШРУСа надо поделить на неделю.
Фишка в том, что формула прохода - абстрактная, это "скорость генерации единиц цели". Что есть единица цели - решаете вы, как архитектор системы.
Покупка ШРУСа - это не часть процесса генерации дохода. Это полностью переменные расходы в данном случае, и они одинаковы в любой момент покупки - хоть за день до продажи, хоть за неделю.
Об этом хорошо сказал Таичи Оно (цитату привел Голдратт в своей статье "Стоя на плечах гигантов"), отвечая на вопрос, чем занимается Toyota: "Все, что мы делаем, - это смотрим на время от момента поступления заказа от клиента до момента, когда мы получаем деньги. И мы работаем над сокращением этого времени".
Цель ТОС - ровно та же. Сократить время от появления потребности до ее удовлетворения и получения денег.
Разумеется, там еще хороший багаж методов, как держать низкий уровень запасов, как рассчитывать их уровни, и т.д.
Просто у меня как-то возникло немного другое восприятие ТОС.
Держа ШРУС на складе, получим ли мы от этого больше денег? - на первый взгляд не очевидно.
Станем ли мы расходовать меньше денег? - вроде бы нет.
Уменьшатся ли связанные деньги внутри системы? - однозначно увеличатся.
Наверное.
Но когда вы пишите "Держа ШРУС на складе, получим ли мы от этого больше денег?" без указания "в единицу времени" то это сбивает с толку. Без указания в "единицу времени" можно предположить что "больше" от времени не зависит.
Видимо не правильно вас прочитал.
больше денег мы получим не от того, что он на складе, а от того, что когда придет покупатель, мы сразу получим его деньги. А затраты на покупку ШРУСа одинаковы как при покупке заранее, так и при покупке под заказ.
Ну и остальные клиенты будут приходить к нам, когда узнают, что ШРУС в наличии.
Я пошел в магазин, потому что в автосервисе ШРУС под заказ ждать 2 недели, а в магазине 4 дня. Автосервис сэкономил на складе, но не получил моих денег.
Насчет денег в системе переживать не стоит. Если работает ТОС, то при той же стоимости склада радикально меняется качество его наполнения, в результате чего увеличивается проход. Много хороших, качественных примеров из личной практики Голдратта есть в его книге "Выбор" - очень рекомендую, если не читали.
Всегда ли?
Вот давайте предположим, что у нас вместо лампочки, допустим, рама от Лэнд-Крузера. Рама от Лэнд-Крузера стоит чуть дешевле, чем сам Лэнд-Крузер, и как-бы желающих менять раму каждый день не так уж и много.
Я это к чему все... Было бы замечательно, если бы вы явно обозначали в каком контексте вы ведете рассуждения, какие границы применимости у данных методов, какие параметры вы принимаете как не существенные в конкретном примере.
Просто получается, когда люди примеряют ваши примеры к области деятельности отличной от вашей они получают некоторый когнитивный диссонанс, и выходит - "Фуфло все ваши теории"
Я с вами не спорю. Просто пытаюсь добавить "глубины" вашим рассуждениям. Давайте приведу аналогию...
Допустим, по радио передача "Вопрос адвокату", звонит человек и спрашивает: "У меня умер очень дальний и очень богатый родственник. Могу я претендовать на наследство?". Там обычно рассуждают, - "вот если к тому что вы сказали присутствует факт1 и факт2, то вы получите такой результат, если факт3 и факт4 то другой". Что на мой взгляд позволяет сторонним слушателям делать выводы по поводу своих ситуаций. Жизнь - она чуть более многогранна.
Для сторонних слушателей - публикации. В публикациях авторы стараются раскрыть тему.
Тут - комментарии, где конкретный человек задает вопрос конкретному человеку. В комментарии обычно не раскрывается контекст и тема. Если я предполагаю, что вы знаете ТОС, то пишу, исходя из этого предположения. И пишу конкретно вам.
Как в прошлом совладелец "автомастерской на 2 поста + автомойки" и магазинчика по продаже автосигнализаций, автоакустики, предпусковых подогревателей, лампочек :) , жидкостей, масла и прочего доп оборудования который я вместе с товарищем организовал с нуля. И ещё несколько малых бизнесов организовывал в строительстве и ещё в паре направлений. Платил зарплату, аренду, покупал товары, инструмент, оборудование, брал под реализацию товары, нанимал сотрудников, сидел без денег, ходил по судам, налоговым и тд
Все эти теории о том как надо торговать ШРУСами по ТОС у того кто ими торгует не вызывает диссонанса. Это просто теория 99.9% который для любого практика "баян".
Диссонанс вызывает уверенность людей, которые не продавали ШРУСы, в том что их теории работают и та лёгкость с которой они раздают советы по торговле ШРУСами. Откуда такая уверенность что нужно руководствоваться этой теорией, а не какой то другой, теорий вокруг десятки! Да и очевидны они.
(122)
Я пошел в магазин, потому что в автосервисе ШРУС под заказ ждать 2 недели, а в магазине 4 дня. Автосервис сэкономил на складе, но не получил моих денег.
Это заблуждение про ШРУСы в наличии. И надо смотреть сколько он сэкономил и сколько он мог бы заработать, вроде как сэкономить 1000 руб или заработать 500 руб разница вполне очевидна.
Именно, а деньги из которых нужно платить зарплату, аренду и тд они реальные. И их можно даже в руках подержать, если конечно получится заработать.
Купить за свои деньги и заморозить в товаре оборотку плюс нести затраты на хранение и риски того что товар испортится(устареет) придётся продать с дисконтом или его потом вообще никто не купит или продать за предоплату от клиента... разницы нет ага. Вот прям совсем никакой.
Это если у тебя нет денег и системы... то переживать конечно не о чем. Сейчас когда у меня нет "системы" я не переживаю. А вот когда была по ночам очень плохо спал.
Держать или нет раму от крузера это не "предмет вычисления" на основе фактического потребления. А предположение о том как и когда она будет потреблена или продана. Покупать что либо на склад с целью "вычислить" на основе фактического потребления это верный путь к "затоварке" складов. Вычислить то что нашу раму никто не потребляет это уже посмертная регистрация свершившегося факта(читай потерянных денег). Так же как и узнать о том что из десяти рам мы за год продали одну, а могли бы продать 25 рам от Калины и заработать те же деньги. Если я не понимаю как я продам товар(или потреблю материал) и за какое время то я его не стану покупать, жизнь научила, без всяких книжек, после первого закупа товара. Да и обычно на практике "вычисляют" закупки и товарные остатки от планируемого потребления(продаж), а не от фактических потребления прошлого периода.
Ну, ежу понятно, что владелец рискует больше наемных рабочих.
Тому же ежу понятно, что большинство бизнесов пытаются что-то изменить - автоматизацию сделать, бизнес-процессы наладить, ТОС внедрить, систему сбалансированных показателей и прочие штуки.
Ежу-же понятно, что в большинстве случаев владельцы делают изменения чужими руками - руками людей, которые не владеют их деньгами.
Ваша-то мысль в чем? Вы, как бывший совладелец бизнеса, против изменений чужими руками? Ради Бога. Не верите в ТОС? Ради Бога. Не верите тому, кто говорит, что ТОС поможет? Ради Бога. Требуете от консультантов наличия собственного бизнеса? Ради Бога. Требуете финансовой ответственности за результат? Ради Бога. Ваше право.
Ну, не будут с вами работать, сами как-нибудь все сделаете.
Есть масса людей, которые сами не умеют или просто некогда. Рискуют, дают небольшой участок бизнеса для тестовых изменений. Смотрят на результат. Понравилось - продолжают. Не понравилось - думают, что делать дальше.
Или просто утверждаете, "что все это неправильно"? В смысле жизнь неправильно устроена.
А можно вернуться к Заявке?
Как заявка по Вашему тормозит скорость генерации денег?
А если Поставщику устной или письменной Заявкой ничего не сообщали, договора с поставщиком нет, то и риски что на 10 поставке Вы не получите товар вовремя ложатся на Вас.
вы же понимаете, как она тормозит. Пришел клиент, принес деньги, говорит дай товар. Без внутренней заявки вы можете отгрузить завтра. С внутренней заявкой получится только через 5 дней. Имея буфер на складе, вы можете отгрузить сейчас. Имея буфер на складе покупателя, вы можете отгрузить вчера.
да, в начале года мы согласовали цены, условия поставки, сроки исполнения и интегрировали наши системы, чтобы он узнавал о необходимости поставки раньше нас. Заодно прописали в договоре, что он должен иметь на складе 20 шт номенклатуры, которую нам поставляет.
в данном случае на вас ложатся риски за то, что вы наняли плохих юристов и снабженцев.
Перефразирую:
1. Заранее подали заявку Поставщику о планах закупки (ориентировочные сроки и объемы)
2. Поставщик Выставил спецификацию цен и свои доп условия (Наверняка поставщик изменит цену, если регулярно откажетесь закупать детали)
3. Подписали договор с графиком (для сохранения уровня цен) приобретения у Поставщика деталей
4. По поступлению Заказа от Заказчика система автоматически формирует (возможно виртуальное) поручение Поставщику отгрузить на Ваш склад деталь.
5. Заказчику отгружается деталь из имеющихся на складе.
Все документы присутствуют. И геде тут Бюрократия тормозящая генерацию денег? У кого-то процесс синхронный, у кого-то асинхронный, но набор документов одинаковый и алгоритм расчета дефицита деталей будет одинаковый.
Другое дело, что в существующих системах недостаточно учтено реквизитов, чтобы предоставлять универсальные решения.
Мы изначально говорили о внутренней заявке, которую делают продавцы в адрес снабженцев. И которую потом обслуживающие подразделения согласовывают.
Набор документов, положим, одинаковый. Но вся разница в синхронности.
Если заявку надо делать каждый раз, на каждый заказ покупателя, то это синхронно. Если работа с поставщиком и согласование обслуживающих подразделений делается не от заказа покупателя, а само по себе, то это асинхронно.
Вот вы, положим, программист 1С. Вы привыкли получать остатки из регистров накопления в любой момент, когда захотите. Просто пишете запрос к виртуальной таблице, и вот они остатки.
Как формируются эти остатки? Асинхронно. Их пересчитывает регламентное задание. Местами они считаются явно, кодом, об это позаботились разработчики типовой конфигурации - там, где это необходимо.
Для вас остатки - само собой разумеющееся. Они есть всегда, о них не надо беспокоиться.
Синхронным этот процесс становится, если платформа и регл.задания перестанут считать остатки. Все, нет остатков. Вообще нет виртуальной таблицы регистра накопления, ни одной. Только реальная.
Хотите остатки? Считайте каждый раз, когда они вам нужны. Нажал пользователь в отчете "Сформировать" - считайте остатки. Открыл пользователь форму подбора - считайте остатки. И т.д.
Здесь можно посчитать тот же самый проход - скорость генерации единиц цели. Единица цели, допустим, сформированный отчет.
Раньше, когда не нужно было считать остатки, отчет формировался 500 мс. Сейчас, когда надо считать остатки каждый раз, отчет стал формироваться 1500 мс.
Скорость генерации единиц цели, или проход, увеличился?
Вот еще другой пример. Мне надо заправлять картриджи для ч/б лазерных принтеров и МФУ. Я заключил договор с компанией. Суть договора проста: когда мне надо заправить картриджи, я им звоню/пишу, они в тот же день приезжают, забирают, заправляют, привозят на след.день вместе с бумажками (счет-фактура и акт).
Цены, сроки, условия - все в договоре написано.
Скорость генерации единиц цели - любое количество картриджей за сутки.
Но еще есть 2 цветных лазерных принтера, которые используются не так интенсивно. По ним нет такого договора, как с ч/б. Мало того - я еще требую внутреннюю заявку от подразделения, в котором принтер стоит. С согласованием руководителя подразделения. И поставщику заявку пишу. И приезжают за картриджем только на след.день. И заправляют 2 дня. С учетом согласования внутренней заявки получается, что на заправку картриджа уходит 4 суток.
Скорость генерации единиц цели - не более 4 картриджей за 4 суток.
И опять вся разница - в синхронности. Достаточно для цветных картриджей обо всем договориться заранее - так же, как и для ч/б - и люди не будут сидеть по 4 дня без цветного принтера.
Это как замер производительности в 1С.
(138)
Структура внутренней заявки не сильно отличается от структуры внешней заявки (Потребитель, Поставщик, Цель, Ресурс, Объем цели, Объем ресурса)
1. Заявка Заказчика службе Реализации
2. Заявка службы Реализации на Производство
3. Заявка Производства в службу Обеспечения
4. Заявка службы Обеспечения к Поставщикам
5. Заявка Поставщика Финансовой службе по оплате
Составлять заявки можно и независимо друг от друга. В вашем случае служба Реализации без заявок Заказчика берет на себя ответсвенность - заранее планирует резерв ресурсов у внутренних служб и внешних поставщиков
2. Заявка
3. Заявка
4. Заявка
5. Заявка
это все реальные заявки? Прям документы, бумажные или электронные?
если будем реалистами, то будем реалистами - за 6 лет была одна задержка, когда понадобился барабан к очень древнему картриджу. Рассудили, что проще купить другой принтер.
(149)
Но суть не в этом. Есть перечень направлений (финансы, закупки, производство, ...), перечень этапов (планирование, управление, исполнение, учет), ключевые вопросы (что?, когда?, сколько?, кто?...) - их полный набор независим от деятельности предприятия и должен присутствовать в любой системе.
Проблема в том, что некоторые информационные процессы не отражаются в реальных документах (происходят устно), некоторые документы объединяются для упрощения процедуры их согласования, следовательно автоматизированные системы создаются не универсальными а урезанными или с оптимизацией под конкретное предприятие.
А чтобы система стала универсальной, она должна автоматизировать (грубо) декартово произведение 12 Этапов Х 10 Направлений Х 10 Направлений = 1200 Бизнес операций (очень грубо).
Для расчета обеспеченности по заказу необходимо анализировать все эти 1200 Бизнес операций.
- все, побежали учитывать. Слава Богу, такой огромный балласт не поддается учету. Поэтому систем такого рода не существует.
(165)
Но опять же, не могу донести суть...
В реальности на предприятии межет не создаваться такое количество заявок в бумажном виде. Действительно, если есть спецификация, маршрутная карта, то службы обеспечения и без производства сформируют свои графики поставки материалов расписывая в амбарных книгах в колонках партии реализуемой продукции, в строках перечень материалов, а всякие нестыковки с производством по времени, определение приоритета выдачи материалов корректируются с мастерами тут же приписками и зачеркиванниями в ячейках.
Но, в компьютерных системах нестыковки зачеркиванием не исправишь. Чтобы компьютерная система выдавала обеспеченность в соответсвии с приоритетами производства, ей необходимо как-то сообщать эту информацию, даже если мастер производства сообщил о своих приоритетах устно.
Заявки производства могут генерится (автоматически) незаметно для пользователей на основе сроков отгрузки продукции, маршрутных карт и спецификаций. Пользователи даже могут не знать, что в системе есть такие документы, если им нет потребности в корректировки производственных приоритетов.
ИМХО: Универсальная автоматизированная система контроля обеспеченности должна опираться на всю цепочку заявок и многих других документов, о существовании которых пользователи могут даже не догадываться и никогда в этой системе не регистрировать. Эти документы в упрощенном контроле могут генерироваться автоматически. Памяти на диске жалеть не стоит. Поддержка алгоритмов сбора отчета по обеспеченности для различных упрощенных случаев обойдется дороже.
Возвращаясь к инструменту планирования - он должен уметь отвечать на вопросы более высокого порядка, чем обеспеченность уже принятых заказов.
В вашем примере - надо понять, почему вообще мы считаем проблемой поступление сразу двух заказов.
Просмотры 24043
Загрузки 0
Комментарии 180
Создание 26.10.17 13:30
Обновление 26.10.17 13:30
№ Публикации 691491
Рубрики Практика учета
Кому Для всех
Тип файла Нет файла
Платформа Платформа 1С v8.x (все механизмы)
Конфигурация Конфигурации 1cv8
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Раздел учета Не имеет значения
Доступ к файлу Бесплатно (free)
Код открыт Да
