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

0. Иван Белокаменцев (1c-intelligence) 1891 26.10.17 00:53 Сейчас в теме
Что не так с планированием в 1С, почему и есть ли свет в конце тоннеля?

Перейти к публикации

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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