Pull to refresh

Comments 16

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

«ловить бабочек рыболовной сетью» — мне кажется должно быть продуктивно.

Бирки — цветовой статус временнОго буфера по каждой позиции (согласно ТОС, 1/3 — 2/3 — 1).

Полуфабрикаты есть. Стараемся свести к минимуму. Для этого ведём перепланировку цеха. Размещаем оборудование в одну технологическую цепочку. Например: рубка — накатка — формовка. Между этими операциями стараемся «убить» ящики с заготовками. Нарубили, сразу накатывать резьбу. Накатали, сразу формуем. И так далее.

Контрольная дата устанавливается после диалога между менеджером по продажам и представителем производства. И, благодаря опыту обоих, почти всегда эта дата назначается очень точно. Хотя и эту процедуру мы хотим лишить души — поручить выполнять рациональной машине. Программа сама должна информировать ещё до размещения заказа в план, сколько времени понадобится на выполнение конкретной задачи. Дедлайны есть конечно. Но они не критичны и их количество тонет в массе вовремя выполненных заказов. Конечно и им мы уделяем внимание (про раздел MTA в следующем рассказе).

Да, и это не велосипед. Скорее моноцикл. Именно в таком положении находится автоматизация любых процессов на малых предприятиях.

P.S. Будете ловить бабочек рыболовной сетью, переловите всех конечно одним взмахом, а зачем вам раздавленная красота?
Полуфабрикаты есть. Стараемся свести к минимуму.

Это конечно хорошо, если возможно. У нас например очень разные скорости выполнения операций и маленькие партии, конвейер не построить никак. И полуфабрикатов тысячи наименований, хотя и стараемся унифицировать по максимуму.
Но всё же, как вы реализовали спецификацию или технологическую карту? Как учитываете нормы?

поручить выполнять рациональной машине
хорошо, что движетесь в этом направлении, но задача очень не простая.
Дедлайны есть конечно.
Формально — дедлайн это и есть ваша контрольная дата, у любого заказа, даже вовремя выполненного.
Конечно у вас будет мало не вовремя выполненных заказов, если срок ставит представитель производства. Он то себя не обидит. А вот как только начнет ставить бездушная машина строго по спецификациям и нормам, вот ту то всё и начнется.

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

"

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

С трудоёмкостью всё сложнее. Мало знать нормочасы, а их мы знаем, для расчёта себестоимости (хотя ТОС не оперирует этим понятием). Важно их подключить к расчёту времени выполнения заказов. Этим занимаемся. Здесь нужно учитывать много факторов. Количество работников, простои оборудования, текущие заказы и т.д. Вся эта информация у нас есть в этой программе. Осталось всё это связать.
Для себестоимости и ТОС этого конечно уже почти достаточно, но вы же хотите и сроки автоматом считать, а тут уже без календарного планирования ресурсов не обойтись.
Ресурсы (рабочие центры, работники, приспособления) к тех.операциям уже подключены? Вы же не по названию будете понимать какие ресурсы надо занять на эту операцию.
Конечно не по названию. Идея такая. База данных. У нас в ней уже есть:

  • Оборудование
  • Сотрудники
  • Оснастка
  • Склад готовой продукции
  • Склад ТМЦ
  • ...




Осталось сделать привязки. Например, штамп №56 можно ставить на пресс №5 и №4. Операция из карты изделия X выполняется на станке №12, сотрудниками с меткой «штамповщик». Табель рабочего времени у нас электронный. Кто болеет, в отпуске, загулял (всякое бывает) — информация всегда актуальная.



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

Или просто взяли некоторые инструменты из ТоС и все?
Нам и не нужно искать ограничения. Мы о них знаем. Если штамповка 10 дет/час, а сварка 5 дет/час, что здесь искать? Да, у нас так всё просто. Я уверен, на многих производственных предприятиях, если бы управленцы меньше грели стулья и больше топтали ботинки, вопросы с поиском ограничений отпали бы сами собой. Вопрос был в том, как этим управлять и улучшать ситуацию. Не знаю кто сказал: «Не можете что-то измерить, значит не можете это улучшить». Учимся измерять и улучшать.

Как пришлось перестраивать? Отдельная тема (запишем в блокнот), может напишу об этом.
Вы верно подметили, мы взяли некоторые инструменты из ТОС, только самые важные для нас.
Либо заголовок не соответствует статье, либо одно из двух. Я не понял, что за теория ограничений, что за программа и где её можно скачать в исходных текстах для адаптации под свои нужды?
Что-то мне подсказывает, что это рассказ про бравых ребят, которые написали закрытое решение для своих нужд, использовали какую-то теорию, про которую не расскажут, но зато смотрите какие у нас скриншоты…
Имхо, не место такой статье на хабре: ни сути технологии, ни особенностей реализации, ни даже исходников.
icoz Вы ужасно правы только в одном — всё под свои нужды. Все остальные ваши замечания в молоко. Или для вас статья без кода это не статья? Заметка не про программирование, а про подход к применению разных инструментов для управления производством/предприятием (рассказываем про теорию Поиск ТОС). И раз уж статья доступна на сайте, то что-то мне подсказывает, что не вы принимаете решение где чьё место. А так да, мы ребята бравые.
Не обижайтесь, но открывая статью на хабре про некую неизвестную для меня теорию, в первую очередь хотелось бы узнать про саму теорию.
Из статьи ничего не узнал, кроме названия. Сам-то я информацию в Интернете найду и разберусь, но на хабр я прихожу за уже подготовленными данными. Хоть за каким-то базовым пониманием. А у вас даже ни одной ссылки на теорию в статье нет. Даже на Википедию.
Теперь про код. Был бы исходник, можно было бы в нем поизучать матмодель. Не из статьи за 5 минут, так хоть из кода за 1.5 часа. Всяко быстрее, чем вики изучать и самому с нуля матмодель писать.

А в чём смысл статьи с вашей точки зрения?
Из вашего замечания я делаю вывод, что статья имеет только следующую суть: есть такая теория, мы написали программу, оказалось эффективно и нам очень помогло, рекомендуем попробовать и вам.
Если не прав, поправьте.
И ещё — не я принимаю решение где чьё место, а сообщество. Я же предлагаю вам направление для развития. Вы меня тоже поймите — вкусный заголовок, а прочитал то, что и не стоило потраченного времени.
Про теорию теперь уже знаете. Оказалось, что и время вы потратили зря. Я думаю, моя миссия для вас закончена. Для всех остальных уточню. Эта статья не про теорию и не про программирование, украшенная картинками. Это попытка изменить подход к управлению производством на малых предприятиях. Желание поделиться своими велосипедами, узнать на чём ездят другие.

У меня техническое образование. И этот факт стер любые слова с корнем «обид» из моего восприятия мира. Холод. Рационализм. Факты. Без обид.
Спасибо за понимание
По информации из Вики:
Теория ограничений — популярная методология управления производством, разработанная в 1980-е годы Элияху Голдраттом, в основе которой лежит нахождение и управление ключевым ограничением системы, которое предопределяет успех и эффективность всей системы в целом. Основной особенностью методологии является то, что делая усилия над управлением очень малым количеством аспектов системы, достигается эффект, намного превышающий результат одновременного воздействия на все или большинство проблемных областей системы сразу.
Самари:
Берем книгу А, читаем, отбрасываем все «лишнее», то есть то что нам не понятно или не нравится.
Берем книгу Б, не всю — достаточно одной цитаты, переосмысленной «своими словами», которая к книге А вообще никак не относится.
2 книги надо бо для построения сильнодействующей в реальности теории одной маловато будет, не удастся заразить идеей массы.

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

Sign up to leave a comment.

Articles