• Девушка под водопадом
    +2
    Как человек, работающий внутри завода в ИТ, могу объяснить.
    Есть два типа заводов:
    1) созданные для работы с бумажными журналами и документацией. Как правило, это заводы, запущенные до середины нулевых;
    2) те заводы, при создании которых упор делался изначально на ИТ-системы. Бумажных доков почти нет, все контролирует система.
    В первом варианте завод может работать без ИТ-системы. Криво, косо, но может. Где-то не будут выполняться сроки, где-то не будет контроля качества, но оно будет выдавать продукцию. ИТ-система дает кучу точек контроля и много информации для оценки качества, дает возможность ускорить производство. То есть — это средство оптимизации.
    Во втором варианте завод просто не будет работать, т.к. сотрудники в массе не особо владеют ситуацией. Это, например, автоматизированный завод Черкизона — при желании руками что-то можно делать, но практически нереально работать эффективно.

    Большинство заводов — первый тип. На работающую человеческую систему наложили ИТ-систему и они зачастую не органично срощены, а сосуществуют и от степени конфликта в их сосуществовании зависит количество ненависти между теми, кто поддерживает и ведет эту систему и остальными сотрудниками.
  • Теперь хороших разрабов меряют по просмотрам и подписчикам — и это плохо
    –3
    Похоже, у ТС есть знакомые в HR в возрасте, кто занимается тем, что он осуждает.
  • Место проклятое?
    0

    Дак это не мораль, а вполне очевидная истина.

  • Квантовое будущее (продолжение)
    0
    Откровенно говоря, пролистал почти всё, чтобы почитать только концовку этой части. Начало не зацепило.
  • Место проклятое?
    +2
    Как и во всех притчах — «а смысл ищи сам». А есть он?
  • Как я нашел пасхалку в защите Android и не получил работу в Google
    +1
    Читая эту статью и заранее даже зная о том, что не получилось, искренне болел за автора в надежде, что всё срастется ) это как Войну Бесконечности пересматривать — знаешь, что в конце будет печально, но болеешь за положительный результат))
  • Менеджер vs Программист
    0

    Иван, вы бы свой же термин "суррогаты" применили про плохого программистов) https://m.habr.com/ru/post/344844/

  • Жёлтое — Вакуум — Облако
    0
    Не только пищепром. Всё, что связано с химическими преобразованиями — туда же. Производство красок, специй, лекарств. Мехобработка, запчасти — это вообще самое простое, что только может быть. Склад может лежать годами, сроки годности огромные, сложности возникают только тогда, когда заказ превышает производительность и её пытаются повысить путем оптимизации, а не наращивания мощностей.
  • Жёлтое — Вакуум — Облако
    +3
    nmivan, тут на Хабре с Вами не меньше половины согласится, это головная боль современности. Проблема-то в подходах к работе.
    Привилегированное положение 1С в том, что моду задает разработчик платформы, то есть головная компания. Весь фреймворк, доступные возможности разрабатываются ими. Что дали — тем пользуйся. Делаешь коммерческую конфигурацию — изволь сертифицировать по жестким правилам. Отсюда растут ноги у кучи ограничений с расширением конфигураций. Я не 1С-ник, но от наших ребят наслушался много. Правда, говорят, в восьмерке сейчас расширять существующие формы стало легче, но тут уже хз.
    Но вот опять же, 1С оперирует терминами и понятими бухучета, в основном.
    Разработчик бизнес-приложения оперирует чуть большим набором понятий. В базе те же заказы, ордера и движения, но для оформления этих движений нужно вводить дополнительные моменты. Например, в том же интернет-магазине есть скидки и промоакции. В форме заказа надо добавить учет скидок, добавить учет промокода, провести их каким-то образом, применить скидку по цене, добавить доп. товары к заказу и так далее. К объектам «номенклатура» и «движение» прибавляется «акция», добавляется сложная связка между «акция» и «номенклатура» с условием акции… Вроде всё несложно, но, чтобы избежать нагромождения костылей, начинаешь думать про применение паттернов. Какой-никакой интерфейс, фабрика объектов и так далее (зависит от степени извращенности автора).
    Двигаемся дальше, находим новые объекты и сложность схемы растет еще больше. Приходится применять новые архитектурные решения. Некоторые архитектурные решения сложноприменимы в рамках одного языка — уткнулись в ограничение.
    Если же готовая архитектура есть, но она плохо расширяема и не подходит — та же беда. В итоге скатываемся к тому, что лучше использовать что-то гибкое и расширяемое, то есть берем другую платформу языка.
    Ок, ладно, почему бы не сделать бизнес-решение на каком-то гибком языке? Ок, давайте выберем… ну, например, c#.
    1. Строим архитектуру, делаем крутое решение в коде. Оно даже расширяемое, замечательно!
    2. И тут здрасьте — мы строили его на asp.net mvc, а сейчас в тренде asp.net core. Вроде бы ничего особенного, но разработчики, которые ищут себе сейчас бизнес-продукт, хотят на core. Ок, ладно, мы переписываем основу решения, делаем возможность запускать его на asp.net mvc и asp.net core. Супер!
    3. Теперь к нам приходят клиенты и говорят — знаете, мы ваше решение взяли, но наши крутые современные итшники говорят, что у нас какая-то там морда на каком-то реакторе, а у вас старый жуквэри и переносить наш модный интерфейс, в который мы бухнули кучу бабла, на старые рельсы нерентабельно. Хорошо… садимся и делаем так, чтобы клиент мог переработать интерфейс на любую фронтенд-платформу — react, vue, node, angular, старый-добрый html+jquery и так далее. Ну и дописываем еще WebApi, потому что какой еще модный фронтенд без вебапи?
    4. Всё, у нас гибкое масштабируемое решение, можно переделать бизнес-логику, расширить, можно сменить морду… мы потратили пять лет и 100500тыщмильёнов на разработку. Нам бы еще отбить эти траты? Цена на внедрение потихоньку растет :) Мелкий бизнес отвалился, средний думает, крупный давно внедрил свои велосипеды. Наше типовое решение мелкому бизнесу неудобно, надо дорабатывать, но дороговато. Средний бизнес на типовое решение согласится со скрипом, если найдутся грамотные «впариватели». А крупный где-то там наверху лениво дернет ухом и дальше будет разрабатывать чекблойн-технологии.

    P.S. Я еще вот чего не понимаю — как вообще можно разрабатывать бизнес-решение в отрыве от бизнеса? Это как игровой движок разрабатывать в отрыве от игр. А как понять, что именно в геймдизайне применять придется-то? Ну, можно сделать ту часть движка, которая отвечает за графические эффекты, физические эффекты, а всё остальное — модели, взаимодействие их друг с другом, всю «бизнес-логику игры» придется писать под себя на конкретную игровую механику.
    Вот если ты игру разрабатываешь и делаешь под неё движок — отлично. Все моменты, которые там используются, реализуются под себя, в итоге получается какое-то готовое решение. И вот его и можно и нужно тиражировать, предварительно чуть универсализировав!
    Скажите мне, сажал ли кто-то команду разработчиков MES-части в ERP на существующее производство, чтобы они написали то, что реально покрыло все процессы на производстве и упростило их ведение? То есть не по чьему-то универсальному ТЗ что-то написали как платформу, а реально внедрили полностью? А потом из этого попытались сделать универсальный продукт. Да ничего у них не вышло бы. А если бы и вышло, то это был бы такой чудовищный монстр, что его только изучать надо несколько лет.
    У нас вот есть MES-система, я её вдоль и поперек знаю и понимаю, что её можно при желании стиражировать, но её писали мы сами и под нас, то есть она реально рабочая и учитывающая все моменты. И перестроить её можно, чтобы вообще универсальной стала. Но как бы мы смогли такую сделать, не работай с производством — ума не приложу. Тут никаких ТЗ не хватит.
  • Жёлтое — Вакуум — Облако
    0
    Да, я понял — вы с Егорьевска :-)

    Чёрт! Шеф, валим… :)
    Бизнес-логика не расширяется со стороны пользователя.

    Как-то нехорошо звучит. Но ведь наш процесс может отличаться от заложенного в системе. Это же не бухучет, мы можем работать как вздумается. Это поведение нельзя изменить?
  • Жёлтое — Вакуум — Облако
    0
    У нас было липро, с 2005-07 года где-то по 2008, пока свою не запустили. Куча ограничений. Банально — всего 100 техкарт при планировании сырья. Может быть, сейчас ситуация и изменилась, но если в системе тех лет не было самого банального и очевидного, то я не верю, что что-то изменилось кардинально. Липро еще до 2011го года работало потом исключительно на складской учет по складам МТС, а потом убили этого зомби, на УПП перешли.

    P.S. LS12 поддерживает разработку нового типа рабочего места на существующей базе? То есть, если на универсальной платформе управленческого учета надо сделать новые типы операций, насколько легко разработать новые формы, логику обработки данных и запустить как отдельное рабочее место? На старой липро разработка превращалась в создание новой формочки с новым списком полей, не более, без какой-то особой логики обработки данных.
  • Жёлтое — Вакуум — Облако
    0
    Работаем с пищевым производством в Подмосковье, так у нас аж с 2009 года своя собственная управленческая система. За все годы мониторили продукты, которые мелькают на рынке — ничего даже близко подошедшего по детализации управления процессом не нашли. Но свою систему никогда не планировали тиражировать, несмотря на то, что строили её как универсальную.
  • Карьерные стероиды. Реальные истории
    0
    Блин, идея-то хорошая, но сколько рисков? А если ипотека есть или любой кредит и с новой работой не сложится и придется уйти? А если подходящих вариантов поблизости нет и смена работы ведет к поездкам в пусть и близкий, но другой город?
    Вот эти принципы в плане смены контор, хитрых способов поиска работ и так далее рождаются в очень крупных городах, как мне кажется. Ну о какой смене работы будет думать Саня из Мусохранска, если ему переезжать не резон (ремонт в квартире, домосед по характеру, жена из дома через дверь не пролезает, либо еще какой вариант), текущая работа осточертела, а других вариантов нет, либо они не дадут бОльшей ЗП?
  • Карьерные стероиды. Реальные истории
    0
    А Вы уверены, что в другой конторе не закисли бы и не отстали бы в технологии?
  • Карьерные стероиды. Реальные истории
    0
    Лояльность работодателю прямо пропорциональна уровню зарплаты и лояльности работодателя. Это результат формулы, а не одна из её составляющих. От этого отталкиваться надо. Во всяком случае, если Вы не в той ситуации, когда вынуждены упрашивать работодателя взять Вас на работу.
  • Корпоративная реальность
    0
    nmivan, крутой поворот в жизни?
  • DevOps
    0
    Мммм… я немного торможу, но не совсем понял суть вопроса в конце рассказа. Про остальных обучаемых.
  • Про одного парня
    0
    Есть участок — есть рабочие, есть мастера, есть руководитель. Возникает проблема — она решается. И даже быстро решается. Эффективность работы участков не низкая, на работу никто не забивает. Все участки покрыты ПО.
    Это то, что нужно.
    Но вот руководству нужно внедрять дополнительные отчеты для улучшения процессов, чтобы повысить эффективность с 80% до 100%. И там уже надо догружать людей сверх их текущей работы дополнительными элементами контроля, пытаться управлять неуправляемыми процессами (типа прогноза заказа от поставщиков, хотя это легкое пищевое — тут каждый день разные цифры и их почти нереально прогнозировать, а далекое приближение никому не нужно). Руководство хочет — ок, пытаемся. Но не внедряется. Не взлетает, не работает. Те сферы, где нужно интуитивное, а не простая математика (как те же заказы поставщиков) — не формализуются. Поэтому сидит человек и играет цифрами и догадками. И умудряется балансировать все производство. А его хотят автоматизировать. Ну нафига? Эта математика не даст бОльшей эффективности. Но надо же! Вот и внедряются эти 20% годами — разные алгоритмы, способы как-то решить проблему и прочее.
  • Про одного парня
    0
    Помощники могут выйти из программиста любой сферы. И необязательно программиста, достаточно подходящего склада ума и опыта.
    Кстати, встречал ИТ-директоров в крупных ИТ-отделах, которые сидели на попе ровно и ничего не делали. И не против изменений были, просто эти изменения объективно не были нужны, хотя их хотели все подряд. Просто познали дзен — 80% усилий не стоят 20% результата :)
  • Про одного парня
    0
    Я работаю в крупной фирме, тут есть всё — и 1с, и свои системы, и хорошая структура управления, и работаю уже 9 лет, так что прекрасно знаю что к чему (учитывая, что на мне полностью висит местная управленческая ERP). Так вот — чем крупнее организация, тем сложнее внедрение изменений. Закон Парето начинает работать с ужасающей силой, доделать 20% недостающего функционала или довнедрить оставшиеся 20% просто нереально — сопротивление людей и инертность существующей схемы просто не дают это сделать. Воля собственника есть, гендира есть, руководители вроде не против, авотхрен — некоторые вещи силимся сделать уже годами. Так сложилось. Не уволишь же весь персонал, который уже привык работать в сложившемся режиме. А внедрять что-то мелкими этапами тоже нереально — сделал первый этап, второй, взялся за третий — уже первое похерили… И карт-бланш не поможет, применение полномочий такого уровня повлечет смену половины персонала.
  • Про одного парня
    0
    nmivan, удачи Вам на новом месте :) Не растеряйте свой редкий опыт.
  • Дополненная реальность Господина Старшего Консультанта (рассказ)
    0
    Страшновато.
  • Кодекс читателя
    0
    Прочел про комиссионное чтение и внезапно подумал, что особо не замечал ответов автора на комментарии в статьях. Это сознательное, чтобы не ввязываться в дискуссии или тоже часть какого-то кредо? :)
  • Скорлупа треснула
    +1
    К сожалению, тут надо не забыть про «дано» и «не дано». Научиться круто играть могут почти все, но для кого-то это элементарно и приходит почти что «само», а для кого-то это чтение статей, зубрение карт и так далее. Просто потому, что у кого-то восприятие настроено так, что все эти нюансы заходят сами, легко усваиваются и их применение включается само по себе, без дополнительных зубрежек. А вот кто-то всего этого не видит и ему надо изучать, зубрить, вбивать себе в голову, чтобы в нужный момент нужное знание включалось.
  • Скорлупа треснула
    0
    Имхо, у автора как всегда сложноватая формулировка этого самого «нафига». Он клонит к тому, что изучать и пробовать вещи, которые вам кажутся лишними, нужно, потому что однажды вы поймете, что они нифига не лишние и очень даже нужны и их надо применить.
  • Патологическая анатомия на производстве
    0
    В начале статьи есть фраза «Попробую рассказать то, что я успел узнать за свою жизнь про «нормальное» управление качеством.». Резюмируя по всей статье, тут есть анализ ситуации, но нет ничего непосредственно про управление. Ну, ок, «это никому не нужно» — знакомо очень сильно, у нас так же. Ну, ок, «Но руководство не хочет заниматься процессами, производящими продукт» — да, так же.
    Ну а дальше-то что? Как стимулировать нужных людей заниматься нужными вещами? Только не говорите, что это уже из другой области — раз мы улучшаем процесс и нашли проблему, то нам и проблему решать. Вот Сергей из вашего чтива в амплуа бизнес-программиста определит, что руководители забивают на решение задач — что делать будет?
  • Метод плавательных дорожек
    0
    Статья больше подходит для менеджеров или аналитиков, но написана настолько доступно, что мне, просто прикладному программисту без любви к менеджерам всё очень понятно :)
  • Поддержка Razor в Visual Studio Code
    0
    Интересно, а если были переопределены базовые классы типа custom razor view, подтянутся ли изменения к design-time?
  • Старение это не процесс износа (перевод)
    0
    Перевод ужасен с точки зрения чтения текста — вместо вникания в подробности приходится напрягаться, чтобы игнорировать отсутствие знаков препинания и дословные речевые обороты вместо адекватной адаптации.
  • Пара скирмион-антискирмион как возможное будущее хранения данных
    0
    Не тянет ни на научпоп, ни на серьезную статью. Для познавательного чтива слишком много зауми, для специализированного чтения слишком просто. И таки да, какие перспективы увеличения объемов-то?
  • EmDrive — это просто
    0
    Оно будет создавать еще бОльшую тягу, если воздух будет забираться через заборную трубу, имеющую вход по направлению движения.
  • Мангровый лес: крутейший биом планеты
    0
    Люто плюсую — побольше бы таких статей на ресурсе!
  • Как я качество работы техподдержки измерял
    +1
    Тут очень много всего написано и в посте и в комметариях. Но что-то нигде не видно главного — а что было сделано, чтобы упростить сотрудникам ведение всех задач? Не знаю, как Вам, а я уже не раз сталкивался с тем, что если нововведение не работает — основная причина в том, что оно усложняет жизнь.
    Каждая система стремится к самобалансированию. Когда количество обращений равно N, а количество заявок в сервис-деске равно M и M очевидно меньше N, надо анализировать причину того, почему система дала дисбаланс и M стало меньше N. Стимулирование, мотивация — это громадный «костыль», которым многие пытаются подпереть криво настроенную и созданную систему, с которой никто не хочет работать. И это основные грабли, на которые натыкаются почти все.
    Живой пример: на производстве была цепочка из 4х технологических операций. Первые две регистрировались двумя движениями. Для регистрации третьей операции необходимо было сделать около 5ти движений. Для регистрации четвертой — тоже два. Операторов чуть ли не угрозой лишения примий заставляли регистрировать всё как положено, тем не менее третью операцию мало кто пробивал, соответственно в системе учета продукция зависала там, где ей не положено было быть. Перенастроили сами цепочки, сделали ветвление в самом начале, в итоге получили три новых параллельных цепочки взамен одной старой, но по 3 операции (взамен четырех) с двумя действиями на каждой. Вуаля — проблемы нет.
    Если брать ситуацию автора поста — банальным решением может стать учет количества входящих звонков оператору и количества открытх им писем и учет количества действий, произведенных по результатам обработки звонков и писем. Один звонок/одно открытое письмо — одно действие в сервис-деске (нажатие кнопки с описанием стандартного действия, ввод краткого описания действий, закрытие заявки либо какое-то другое действие). В конце дня — контроль чисел. Удержал N=M — молодец. Расхождение в 30% — повод руководителю заинтересоваться причиной.
  • Весы и штрих-коды: Как ритейлеры и производители оказались в глубокой… луже
    0
    Как я Вас понимаю… С ноября с этим колупаемся.
  • Весы и штрих-коды: Как ритейлеры и производители оказались в глубокой… луже
    0
    Маркировочная линия стоит от нескольких сотен тысяч рублей до нескольких сотен тысяч евро (автоматизированная линия нарезки с упаковкой в лотки и маркировкой — на входе баран, на выходе лотки).
  • Весы и штрих-коды: Как ритейлеры и производители оказались в глубокой… луже
    0
    хоть на трехмерный. только промышленные маркираторы на большинстве производств старые и про QR код не знают.
  • Весы и штрих-коды: Как ритейлеры и производители оказались в глубокой… луже
    0
    Поищите про Юнискан
  • Весы и штрих-коды: Как ритейлеры и производители оказались в глубокой… луже
    0
    Как работник организации-производителя продукции могу сказать, что «мы технически давно уже готовы» означает, что все гордые монополисты рынка накидали производителям своих разношерстных требований и ждут, что им сразу выкатят готовые этикетки. А то, что у производителей логистика и производство давно оптимизированы под определенный процесс маркировки, и изменение маркировки под новые реалии требует переделывать половину рабочих схем и замедлять производство — никого не колышет.
  • Спросите Итана: можем ли мы спасти Землю, переехав подальше от Солнца?
    0
    Вот интересно.
    В настоящее время Земля получает от Солнца порядка 1500 Вт энергии на квадратный метр. Чтобы собрать достаточно энергии для того, чтобы отодвинуть Землю за нужное время, нам нужно будет построить космический массив, собирающий 4,7 × 1035 Дж энергии, постоянно, в течение всех двух миллиардов лет.

    В расчетах не стали учитывать, что излучаемая Солнцем энергия как раз будет расти в течение этих самых двух миллиардов лет?
  • Гонки по вертикали. Как, зачем и куда едут лифты Лахта Центра
    +2
    Ядро, имея высший из существующих предел огнестойкости

    В случае возгорания ВНУТРИ ядра оно превращается в высокогерметичную печку с минимальными шансами выжить, нет?