?

Log in

Всем привет, друзья.
Сто лет не писал сюда, уж простите.

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

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

Но когда ты начинаешь туда погружаться, понимаешь, что все в 100 раз сложнее.
Во-первых, аналоги бывают односторонние. Это когда А ты можешь заменить на В, а наоборот нельзя. Ну, и соответственно бывают двухсторонние.
Во-вторых, аналоги бывают узловые. То есть А и В - аналоги, но только в этом узле.
В-третьих, управлять аналогами должен не человек, а система.

А теперь самое сложное. Это должна быть динамическая система. То есть управлять связкой аналог-оригинал система должна динамически. Сегодня в этом заказе нужно заменить оригинал на аналог и отправить в очередь производства. Но завтра ситуация в компании может измениться так, что в этом же заказе нужно вернуть на место оригинал и отправить его в закупку. Если, конечно, компания не начала работать на исполнением заказа.

Делали мы эту всю систему полгода ))
В марте запустили ее в Томске, в мае в Климовске.

А самое интересное - это наша новая система управления производством (на основании методик TOC). Это полностью динамическая система управления. Динамично в ней всё: управление запасами, резервами, очередями. То есть это такой уже кибер-мозг, который сам думает, что и как компания должна делать, чтобы исполнить все заказы вовремя.
Одно из важных обстоятельств - система безрезервная. Ну, почти безрезервная ))

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

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

Безрезервность новых методик - это еще не все ))

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

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

Короче говоря, эту проблему мы таки тоже решили похоже.

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

Сегодня на РБК видел передачу, посвященную автоматизации бизнес-процессов. Речь шла о двух лидерах российского рынка. 1C и SAP. Из уст одного из участников беседы (которого я на самом деле хорошо знаю и очень уважаю) прозвучала цифра 120-200EU. Вроде как именно во столько обходится автоматизация одного рабочего места на базе 1С.

Не знаю, с какого потолка взята эта цифра. Вот недавно был тендер в одной производственной компании. В тендере участвовали три компании. 1С, SAP и мы со своей скромной поделкой (находимся теперь в стадии подписания контракта). Самый высокий бюджет был у...1С. Да-да, не у SAP, а у 1С. Раза в полтора выше, чем у SAP и, как вы понимаете, это было не 200EU. Цена была настолько космична, что стало прям комично, услышав на РБК вот такие цифры. Вроде как у нас тут импортозамещение, а 1С вроде как бюджетное решение и все такое. Прям даже и не знаю.

Tags:


Вот так выглядит график чистой прибыли одного из наших клиентов. Работать с ними мы начали в конце 2014 года. Верней заключили договор. Компания была в тяжелейшем состоянии. Я убрал цифры по вертикали, но ноль оставил. Чтобы вы понимали, что компания была убыточна, когда пришла к нам. Стартовали систему примерно в начале 2015 года. Несколько месяцев на усушку-утруску, обучение, консалтинг. И где-то в середине года уже начали принимать управленческие решения. Верные решения.

Это я собственно к чему. Да к тому, что ERP-системы вообще-то для того и надо внедрять, чтобы это как-то повлияло на график именно этого показателя. Но это редко кому удается. В основном ERP-системы становятся просто еще одной статьей расходов.

В общем, это. Думали, мы думали, и решили таки открыто показать, что и как мы сделали в производстве.

Разработали новые методики управления производством. За основы взяты методики Теории Ограничений.


  • Полностью автоматическое формирование плана-графика производства.


  • Полностью автоматическое формирование связанного плана-графика закупок.


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


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


  • Избавились от функций ПДО. Сотрудники производства теперь сами видят что и когда они должны делать.


  • Система знает, что у вас может быть несколько независимых производственных площадок и четко их разделяет.


  • Работаем с аналогами. Двухсторонними (меняем туда-сюда), односторонними (меняем в одну сторону), узловыми (меняем туда-сюда, но только в конкретном узле).

Ключевое отличие от предыдущих версий — это безрезервная схема. Мы сделали так, что больше нет необходимости резервировать товары. Это ключевое отличие от всех предыдущих разработок.


В 2014м мы эту схему отработали на одном из наших проектов. Но там торговля. Там нам удалось довести удовлетворение спроса до 99%. Теперь мы эту схему распространили и на производство.


В данный момент (конец 2015 года) мы внедряем эту схему в компании ЭлеСи в Томске. Посмотрим, что выйдет, но я думаю там будет бомба.

Резерв товара — это потенциальный рост складских запасов и общее снижение уровня эффективности компании в целом. Что происходит, когда вы резервируете товар? Вы выводите его из оборота и не можете использовать!


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

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


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

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

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

А еще город на удивление красивый, много старинных купеческих домов. Там же находятся мощи Федора Кузьмича. Того самого, который вроде, как царь Александр I. По крайней мере этот федор Кузьмич прекрасно говорил по-французки (исторический факт), отлично знал дворцовый этикет и многие подробности Отечественной Войны 1812 года. Что конечно дает некоторые основания полагать...

А вот видос про производство

Вот статья. Руководитель Крока утверждает, что внедрение ERP-системы раз в пять лет - это норма.
А вы как считаете?
И как вы считаете, почему он так сказал?

http://www.pcweek.ru/business/article/detail.php?ID=180071

Какие новости

Всем привет.
Сто лет ничего не писал, люди даже спрашивать начали «куда пропал». Вот пишу, что у нас происходит.

Ну, во-первых, знаковая новость - с сегодняшнего дня на Коммерсантъ-ФМ начинается наша рекламная кампания.
Вот ролик даже замутили



Делаем проекты в Нижнем Новгороде, Питере, Москве. Собираемся в Томск.

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

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

Звонит мне и говорит, что вот сидим думаем, что внедрять будем, после твоего отказа. Внутри компании существует 1с-лобби. Я говорю, что это нормально, 1с - это лидер рынка, все так и должно быть.

Это при том, что компания и так уже внедрила 1с. Но правда закупки и производство работают в экселе, а конструторская документация в третьем продукте. Традиционное внедрение 1с. Короче он в шоке от перспективы, потому как с 1с уже сталкивался.

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

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

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

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

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

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

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




Видите там флажки разноцветные (приглядитесь, увидите). Ну, собственно, это все, что в системе есть про тос. Там тоже такие же цвета используются )))

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

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

Дальше я попытался выяснить, как вообще считаются вот эти флажки. Выяснить не удалось.

Ну, а потом презентующий сказал всем чудо-фразу: «Послушайте ребята, TOC - это все лишь теория, там нет никаких четких правил и алгоритмов». Такой вот эксперд нам попался))

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

Короче говоря до конца презентации досидел....только я. Представители клиента попросту ее покинули.

Такие вот новости. А вообще все прекрасно, ребятушки ))


Не так давно к нам в офис приехал собственник строительного бизнеса. Компания терпит убытки второй год подряд. Но это не самый печальный факт. Самый печальный заключается в том, что он не понимает почему это происходит.
У компании есть финансовая отчетность по прибылям и убыткам, там ясно, что у компании убыток. Но почему? Вот это понять достоверно невозможно. Потому что все сделки сложные, продолжительные, от полугода до двух лет. Сделки носят проектный характер. И какие сделки приносят убыток, а какие прибыль — понять очень непросто.

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

У нас это уже не первый подобный случай. Первый раз с этим мы столкнулись в 2010 году, когда к нам с этой же проблемой обратилось крупнейшее российское маркетинговое агентство.

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

1. Сумма, которую вам оплатит клиент за выполнение проекта зафиксирована в договоре с ним и именно ее вы получите. Но сумма ваших расходов на этот проект ни в каких договорах не прописана. Да это и невозможно. Вы никаких договоров с поставщиками и подрядчиками еще не подписывали.
И это одна из главных проблем. Во-первых, ваши расходы нужно правильно рассчитать, а во-вторых, что самое важное, удержать в этих рамках. В большинстве же случаев получается так, что вы планировали потратить на проект сумму N, а по факту потратили 2N. И ничего с этим сделать не можете.

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

2. Условия меняются в процессе проекта.

Эти меняющиеся условия ведут к увеличению ваших расходов, но не ведут к увеличению доходов.
Простой пример. Вы строите офис. Прорубили проем для двери, как и предусмотрено проектом и сметой. Затем заказчик просит перенести проем в другое место. Вы переносите проем, несете дополнительные убытки, но дополнительных прибылей вы иметь не будете. И вот почему: менеджеру проекта заниматься подписанием всей этой кучи бумажек (дополнительного соглашения об увеличении стоимости работ) нет никакого смысла. Это только увеличит сроки проекта и оттянет срок получения им премии. А зачем ему оттягивать сроки получения собственной премии? Он просто принесет тихонечко счет в бухгалтерию,как-то это объяснит и все, вы этот счет оплатите. Или, что тоже часто встречается, менеджер проекта просто забудет запустить процесс подписания доп. соглашения, а работы, разумеется, будут выполнены.

Из подобных ситуаций складывается огромное количество убытков.

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


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

4. Отклонения от бюджета.

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

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

Пишем сценарий рекламы на радио.
Помимо серьезных вариантов присутствуют и такие:

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

Или вот например:
- Дорогой, у меня строчки в экселе кончились и поэтому я не вижу убытков.
- Я купил ава ерп и вижу свои убытки, увидишь и ты.

Или вот еще:
- Дорогой, мне срочно нужна новая шуба
- Дорогуша, у меня в бизнесе сплошные убытки
- Ну ты и балбес. Давно бы купил ава ерп, получал бы одни прибыли.

Предлагайте в комментах еще варианты )))

Всем привет ))

Где-то год назад задумались над тем, как мы можем усовершенствовать в TOC. Что нового мы можем туда привнести.

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

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

И вот от этого-то резервирования мы и решили избавиться. Сначала сами себе не поверили)). Как же так, ведь это то самое резервирование, которым мы раньше так гордились.

Потому что, как это ни странно, вот такое ручное резервирование мешает эффективности всей компании. Мешает именно ручное резервирование, когда менеджер сам решает, что и кому зарезервировать. Это стермление к локальной эффективности. А она, как учит TOC, мешает эффективности всей компании.

Мы промониторили резервы у некоторых клиентов. О, ужас. Есть даже резервы, которым больше года!!! Если клиенты, у которых зарезервировано до половины склада. Вот такие дела.

А что такое резерв? Это выведенный из оборота товар, на котором компания не может заработать.

Короче говоря, решили разработать какую-то такую систему, которая:
а. Максимально увеличит удовлетворение спроса. Желательно до 100% )))
б. Максимально сократит количество зарезервированного товара на складе.

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

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

Пользователь сам ничего не резервирует. В определенный момент система, когда она понимает, что произвести/закупить мы это уже не успеем, резервирует таки твой товар.
Причем вся эта картина постоянно ведь меняется. Завтра добавился новый заказ, отменился старый, кинул поставщик и т.д. И, конечно, схема под все это подстраивается тут же.

И вот представился случай эту всю схему опробовать в жизни.
Мы начали проект с компанией Метротайл-Украина. Совершенно замечательные ребята. Я чертовски рад, что никакие говнюки-политики не помешали этому проекту.
Стартовали в начале ноября. Сразу запустили новую схему. Неделька ушла на усушку-утруску. Косякнули с четырмя заказами (толи мы девченкам не объяснили, толи девки нас не поняли))) ), по которым вовремя не отгрузили товар. За ноябрь в итоге отгружено 500 заказов (2500 наименований). Проблемы со своевременностью отгрузок возникли только с этими четырьмя заказами.

Latest Month

June 2016
S M T W T F S
   1234
567891011
12131415161718
19202122232425
2627282930  

Tags

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Lilia Ahner