Рубрика «TOC»

Термин «кайдзен» ввела компания Тойота, и про него много написано в толстенных книжках из серии «Дао Тойота».

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

Далее Вы узнаете про несколько случаев, которые постепенно подвели автора к пониманию кайдзен в разработке.Читать полностью »

В деятельности менеджера всегда есть какая-то доля работы связанная с постановкой бизнес-процессов. Как правило это необходимо когда появляются новые потребности компании, бОльший оборот, лучшая стабильность по денежному потоку или просто внедрить каике-то улучшения. Иногда бывает, что мы сталкиваемся только с симптомами или нежелательными явлениями, когда что-то идет не так: «продалбываем» сроки, заказчик недоволен, слишком большие расходы на содержание инфраструктуры или иные издержки. Между этими двумя позициями есть общая деталь: если есть потребность к изменению значит что-то эти улучшения сдерживает, и это можно расценивать как нежелательное явление. Когда мы начинаем разбираться в ситуации, то можем собрать множество разрозненных фактов из которых понятно только то, что изменения требуются. но с чего начать? Как минимальными усилиями провести изменения?

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

Читать полностью »

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

Также бывает и другая крайность, для реализации нового функционала или переделки существующего, один и разработчиков говорит: «Я знаю как сделать лучше!» после чего, вместо того чтобы дать идее «отлежаться» и оценить все плюсы и минусы, сразу начинает её делать. Где-то через месяц разработки может возникнуть ситуация, что чего-то он не предусмотрел, и приходится отказываться от разработки и выкидывать код или срочно искать варианты решения проблемы. Почти каждому разработчику в этом случае хочется сохранить лицо: «Как же так? Я же профессионал!» — думает он, «Если я признаю свою ошибку то все подумают, что я не настолько крут как всем говорю». И в этом случае Идея которая недостаточно проработана входит в проект и становится проблемой уже всей команды. Что также удорожает проект. А так как это становится заметно не сразу и внимания на причинно-следственные связи почти никто не обращает, то ситуация может повторяться снова и снова.
Читать полностью »

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

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

Месяц назад мы запустили проект на Украине, где опробовали наши новые решения в области Теории Ограничений (TOC). Теория Ограничений — это тоже методика управления предприятием, как и тойотовский канбан, но TOC более совершенна и, в отличие от канбана, хорошо работает в случае с рваным спросом, высокой вариативностью заказов. О некоторых показателях эффективности этого проекта в цифрах чуть ниже.
Читать полностью »

К слову сказать, на это понадобилось лет шесть изысканий.

Очевидно, что если вы что-то производите (или выполняете проекты, это не так принципиально), то очень-очень хочется делать это:
— быстро
— качественно
— точно в срок
— с минимальными затратами (инвестициями)
Это значит, что должно быть найдено какое-то решение, позволяющее делать именно так.

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

Свои изыскания в этой части мы начали году в 2006-м, полагая, что лучшее решение для производства — это MRP. В 2010-м году, после некоторых опытов по внедрению, мы поняли, что MRP не ведет к увеличению эффективности. Количество заказов, произведенных точно в срок, не увеличивается, запасы не уменьшаются, скорость производства не растет. А зачастую даже наоборот. Я написал статью об этом. Довольно эмоциональную. Видимо серьезно задев тех, кто зарабатывает на внедрении MRP. Но ведь целью внедрения любой системы менеджмента должно быть увеличение эффективности, не так ли? Многие об этом забывают, как, впрочем, и о том, что цель бизнеса – зарабатывать деньги. Поэтому внедрение MRP чаще всего превращается просто в проект по внедрению MRP, а в не в проект по улучшению эффективности производства.

Читать полностью »

На днях у меня состоялись переговоры с двумя разными компаниями. Главная тема обоих переговоров – управление запасами. В обоих случаях меня пытались убедить, что методы Теории Ограничений Голдратта им не подходят.
И происходило это каждый раз от банального незнания того, как эти методы работают.

Переговоры №1. Виноторговая компания.

Сначала в переговорной один человек от компании. Непосредственно тот, кто нас пригласил.
Выдержки из диалога:
«Я правильно понимаю, что ключевая тема переговоров – запасы?» — спрашиваю я.
— Да. Мы уже давно этим вопросом занимаемся и вот ищем решение. Мы слышали о решении компании X (не буду называть в этом посте), там очень красиво сглаживаются пики, все планируется. Они уже год применяют эту систему. Очень хорошая, эффективная система.
— Как изменились запасы этой компании за последний год?
— эээ, я не знаю. А зачем вам?
— Почему тогда вы говорите, что система эффективна? Мне кажется, что эффективность какой-либо системы управления запасами надо оценивать не по тому, как она сглаживает пики, а по тому, как изменились запасы. Если они снизились на сумму, превышающую инвестиции в эту систему, и при этом не пострадал объем продаж и удовлетворение спроса, то да, система эффективна. Все остальное – игра цифр и красивых графиков.
— Хм, интересно. Сейчас к нам в переговорную придут люди, вы не говорите им, что снижение запасов – это главный критерий работы такой системы. Низкие запасы – это не всегда хорошо.
— Не понял. А что, какие-то другие есть критерии эффективности? И насчет низких запасов можно поподробнее?
— Ну, вот если, например, ваши запасы вырастут, то банки вам с большим удовольствием будут давать кредиты.
Я вздыхаю. Это говорит, не какой-то студент на интернет-форуме, а человек из бизнеса. Слава Богу, что IT-директор. Уфффф, я с облегчением вздыхаю, что это не директор по логистике.
Читать полностью »

Как посчитать экономическую эффективность от внедрения ERP-системы. Таким вопросом задаются очень многие. Изложу свою точку зрения.

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

«Давай внедрим то, давай внедрим это». Предложения внедрить что-то звучат для него регулярно. Оно и понятно. Инициатива, так сказать. Однако очень скоро он приучил всех, что первый вопрос, который сотрудник услышит в ответ на свое предложение что-то внедрить, будет звучать так: «Насколько компания будет больше зарабатывать или насколько меньше она будет тратить, если мы сделаем это?»

Читать полностью »

Эффективное производство (да и вообще предприятие) удовлетворяет четырем простым требованиям:

  • Производит то, что нужно рынку
  • Производит это качественно
  • Производит это быстро и в срок
  • Производит это с минимальными затратами

Я здесь остановлюсь на двух требованиях из четырех:

  • как производить быстро и в срок
  • как производить с минимальными затратами

Читать полностью »

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

Вот, начинаю с запасов.

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

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

Читать полностью »

Оптимизация работы веб студии. Применение теории ограничений в производстве сайтов

В статье «12 тыс рублей за сайт. Есть ли бизнес за МКАДом?» я писал про наш подход к разработке сайтов на базе разработанной внутри компании технологии. На момент написания той статьи, мы выпускали «под ключ» 24 сайта в месяц. Это больше чем один сайт в день силами команды из 8 человек.

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

И тут наше производство затрещало по швам. Практически сразу заявки стали становиться в очередь, менеджеры начали путаться в проектах, дизайнеры стали проситься в отпуск. Ситуация становилась поистине напряженной...Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js