Введение

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

В XX веке доминировала методология управления производством получившая название «Фордизм», по имени своего основоположника Генри Форда. Фордизм — модель массового производства стандартизированных товаров на сборочных конвейерах с использованием низкоквалифицированных работников, занятых простыми операциями и объединенных на крупных фабриках. Такое производство обладает «эффектом масштаба» и отличается низкой себестоимостью единицы продукции, доступной массовому потребителю. Один из основных постулатов фордизма: «Производить большие партии изделий выгоднее, чем мелкие», прочно укоренился в головах управленцев XX века.

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

Рождение новых методологий

Со второй половины XX века (после второй мировой войны) предпринималось множество попыток модифицировать фордистскую модель. В частности на заводах «Тойота» в 50х годах стали ставить эксперименты, адаптируя американские концепции массового производства к реалиям послевоенной промышленности Японии. Тогда была переделана система крепления прессового инструмента, чтобы сделать его замену более быстрой. Потом были и другие новаторские решения и открытия, со временем сложившиеся в новую методологию — Lean Manufacturing (LM) – Бережливое производство.

В 80х и 90х появился целый зоопарк методологий и парадигм по управлению производством, среди которых подробнее остановлюсь на двух: Quick Response Manufacturing (QRM) – Быстрореагирующее производство и Agile Manufacturing (AM) – Активное производство. Современные, более гибкие по сравнению с фордизмом методологии, часто объединяют термином «постфордизм».

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

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

Ниже приведена таблица основных отличий фордисткой и постфордисткой концепций промышленного производства [1].

Признак	Фордизм	Постфордизм
Базисная ориентация	Продукт	Клиент
Снижение стоимости единицы продукции	За счет объёмов	За счет быстрой переналадки оборудования
Работник	Рабочая сила (Узкие, малоквалифицированные рабочие)	Носитель компетенций (вектор развития, многофункциональные специалисты)
Организационная форма	Отдельные рабочие места	Командная работа
Отношение к браку	Допустимый уровень	Абсолютное качество
Инновации осуществляются	Специалистами	Всем персоналом

Сейчас подробнее о каждой из рассматриваемых новых методологий

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



Чем планирование софтверных проектов похоже на написание книги, как гуры экспертного управления планировали бы написание продолжения “Войны и мира”, и что такое метод оценки трех П — обо всем этом в новом видео.

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



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

Многих из вас, возможно, посещала крамольная мысль «а тем ли я занимаюсь, чем должен?». На правильном ли вы пути? Действительно ли расходуете отведенное вам на планете время на нужные и значимые дела? Стоит ли вообще заниматься тем, чем вы занимаетесь? Как найти свое предназначение и не пожалеть о потраченных впустую годах? Позволим же себе предаться философии чтобы в очередной раз осмыслить свое предназначение.

Этот пост понравится мизантропам: ведь он про то, что нет ничего бесполезнее, чем чужой успех. Вот если бы было место, где люди честно бы делились своими планами, а потом можно было бы следить поэтапно за их реализацией и фиксировать не только удачи, но и провалы в итоге… Ой, я же пишу в блоге такого проекта. Заходим на «СмартПрогресс», выбираем меню Цели, сортировку «проваленные», добавляем параметр «лучшие за все время» — и смотрим список самых громких фейлов на проекте.



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

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

Итак, про каждый изученный мною объект по отдельности.

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

Сначала немного о фундаменте.
Итак, что же нужно, чтобы в компании была внедрена ERP система? Ну, во-первых в туалетах должно быть чисто. Состояние туалетов — это состояние компании в целом. Вы будете смеяться, но это так и есть. Если в туалетах грязно, то вначале надо решить системные проблемы в компании, а потом уж и за ERP можно браться.

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

В одном из комментариев к посту автора, многоуважаемого пользователями Habr, я ответил, что основной причиной неудач проекта является не использование методологий «через %опу» или «как получится», а наличие только операционного управления в рамках проекта. Проектный подход у таких менеджеров заканчивается уже после составления сметы проекта.
В этом посте проведу более детальное сравнение операционного подхода с проектным.

Уровни управления проектом

Прочитал, что пишут на хабре про мозговые штурмы и нашел, что такого еще не писали. Последняя статья про мозговые штурмы называется «Миф об эффективности мозговых штурмов», но при этом наоборот преподносит мозговые штурмы как один из наиболее эффективных инструментов исследования. Основная мысль той статьи — это позволять критиковать во время обсуждений, тогда все будет хорошо. На самом деле не все так просто и есть другая проблема мозговых штурмов.

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

Существуют три вида лжи: ложь, наглая ложь и статистика (источник)

Есть такой замечательный жанр — "вредные советы", в котором детям дают советы, а дети, как известно, всё делают наоборот и получается всё как раз правильно. Может быть и со всем остальным так получится?

Статистика, инфографика, big data, анализ данных и data science — этим сейчас кто только не занят. Все знают как правильно всем этим заниматься, осталось только кому-то написать как НЕ нужно этого делать. В данной статье мы именно этим и займемся.


Hazen Robert "Curve fitting". 1978, Science.

Структура статьи:

1. Введение
2. Предвзятая выборка (Sampling bias)
3. Правильно выбираем среднее (Well-chosen average)
4. И еще 10 неудачных экспериментов, про которые мы не написали
5. Играем со шкалой
6. Выбираем 100%
7. Скрываем нужные числа
8. Визуальная метафора
9. Пример качественной визуализации
10. Заключение и дальнейшее чтение

Введение

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

Оно суть головная боль и корм для корпоративной жабы компании-разработчика. С точки зрения «типового интегратора», это некий побочный процесс, результаты которого в основном нужны для закрытия официальных требований контрактов. Не будь требований – сколько можно было бы высвободить ресурсов! Да еще и не отвлекать от работы истинных кормильцев компании: продавцов, менеджеров и в некоторой степени программистов. Картина комплектование и организации работы «мощностей» по разработке документации – отдельная грустная песня, не для этой статьи.

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

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

Уважаемые сейлы, менеджеры продуктов и проектов – давайте активнее продвигать документацию. Давайте на ней зарабатывать!

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

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

На 3-м месте оказался Scrum (14%)

2-е место досталось нашей любимой методологии “Как получится” (21%)

А 1-е место с большим отрывом заняла методология… (18+)

Дисклеймер:

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

Под проектом здесь я подразумеваю проект разработки и продвижения сайта или ПО.

О моем опыте, позволяющем мне делать выводы:

Первый мой стартап был в 2005 году. Это был интернет-магазин, для раскрутки которого использовались дорвеи и постинг по форумам. С 2006 года активно занимаюсь SEO и продвижением стартапов. Последний (самый свежий) мой стартап начался более года назад. Заморожен месяц назад. Скажу сразу, мировой известности ни один мой стартап не получил, однако шишек набито достаточно много, а сколько еще предстоит набить!

Я разработал около сотни проектов, в том числе — стартапов. Многие из них достигали пика и умирали, некоторые работают до сих пор. Делал как B2C, так и B2B.

В последнее время наблюдается поток вопросов от знакомых и друзей, которые делают одни и те же ошибки. Я хотел бы рассказать о своем опыте в посте тезисов. И если он будет успешен — продолжить серию.

Если лень читать — ролик, выражающий основной дух и главный смысл, находится внизу. Ролик вызовет восхищение — отлично, идите делать очередной релиз. Ролик вызовет отторжение — читайте пост до другой реакции сколько угодно :)

1. Важнее всего — желание

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

Внезапное отключение российских банков от международных платёжных систем свалилось неожиданнее снега в декабре. Неожиданно выяснилось, что использование платёжных системах вероятного противника может вызывать побочные эффекты вроде валютного запора или дистанционного разрушения банков. Знаете, есть такая фобия — Гимнофобия, что означает “боязнь оказаться голым на публике”. Судя по всему, наше правительство ею не страдает (что могло бы радовать, но — нет). В итоге, все мы оказались именно в таком положении.

Из этого положения есть разумный выход — переключится на Национальную Платёжную Систему вместо вражеских visa/mastercard. Но её не существует даже в виде проекта. Существует лишь законодательная инициатива и смутные желания, этой самой инициативой вызванные. И поэтому огромное количество людей в костюмах сейчас нервничают и требуют начать её немедленную разработку. Собираются заседания, куда вдруг приглашают не только людей в клетчатых рубашках, но даже одного-двух избранных в растянутых свитерах. Приказывают начать разработку прямо сейчас. Ну, или понедельника. Ладно, в этот не успели — начните со следующего. А ещё лучше начать сразу внедрение какой-нибудь системы и одновременно вести её разработку. Как бы не вышло так, что на гос.тендере заказ получит какая-то no-name компания, которая возьмёт, скажем, Кибер-плат, перекрасит, назовёт SUPERVISA, а потом стране с этим жить.

“Кто будет её проектировать и какие задачи каких пользователей она будет решать?” — это на порядок более важный вопрос, чем кажется. Если её будут разрабатывать люди из банковской сферы — то она будет нацелена на создание удобства банкам, а для людей и бизнеса — уж как получится (привет, Сбербанк!). Если её будут делать люди из онлайн-систем, то она в первую очередь будет решать задачи онлайн-бизнеса (банковские задачи им интересны в последнюю очередь). Если её будут делать бухгалтера, то это будет облачная 1С. Если её будут делать Erlang-программисты, то задачей будет показать его преимущества, перед другими унылыми языками. Если её будут делать любители короткошерстных терьеров, то… нет, не хочу даже искать ответ на этот вопрос.

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

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

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