Comments 18
"ГОСТ"
Как связаны "ГОСТ" и текст из статьи???
Может имелись в виду Правила, Регламенты, СТО, ДИ и ПСП, Требования к ЗИ, Спецификации?.... но точно не ГОСТ.
Не используйте термин ГОСТ, если не знайте, кто их разрабатывает и как их внедрять в деятельность.
С точки зрения нотации схема безупречна: обе ветки закрыты, разработчику всё понятно.
Какой нотации?? Что здесь понятного?))))
Там же чёрным по белому написано - ГОСТ это отсылка с песни))
Закон — на улице натянутый канат,
Чтоб останавливать прохожих средь дороги,
Иль их сворачивать назад,
Или им путать ноги.
Но что ж?
Напрасный труд!
Никто назад нейдёт!
Никто и подождать не хочет!
Кто ростом мал — тот вниз проскочит,
А кто велик — перешагнет!
Василий Жуковский, октябрь 1814 года
ГОСТ это отсылка с песни))
Тогда Закон, уж двести лет просрочен,
Ошибка, в логике людей.
И если ГОСТ лишь строчка,
То нам не скрыться от больных идей....
Какой нотации?? Что здесь понятного?))))
На иллюстрации намеренно упрощённый фрагмент нотации BPMN - только шлюз и две ветки, без пулов, событий и остального маршрута. Подпись относится к тому, что для разработчика схема выглядит завершённой - обе ветки закрыты, программировать понятно.
Не стал портить статистику, но у нас в программировании микроконтроллеров регулярно приходится реализовывать правила, которые бизнес не принимал. А дальше уже после тестирования принимать решения, что оставляем как есть (исходная логика была верной) либо требуется данный процесс отладить. Расписать все по блок-схемам изначально мысль вполне себе неплохая, но когда в одном устройстве около 400 if, схему начинают рисовать для какого-то конкретного участка, где изначально либо сложная логика, либо сложный для поддержания код. А так там и правила, и константы, и даже устройства, которые бизнес не принимал).
ИТ не должно само придумывать бизнес-правила, но если бизнес годами работает «по ситуации», а потом требует от системы чёткой логики, проблема явно не только в разработчиках.
Вы совершенно правы. И вот тут я как раз говорю именно про это:
Дополнительно выяснилось, что разные филиалы исторически работали по-разному. Вопрос, на который будущая система требовала одного ответа, раньше просто не требовал единого корпоративного решения. Люди справлялись с неоднозначностью локально, а автоматизация впервые заставила организацию сделать выбор явным.
Тут вопрос и проблема в том, что фактически сейчас у бизнеса, хвала современным теориям экономики и менеджмента, в принципе нет критериев верности и корректности управлнческих решений, а раз так то и алгоритмов позволяющих принимать верные управленческие решения - нет.
Поэтому и автоматизация стоит так дорого и так не эффективна.
Ведь по-сути статья про то, как команда, которая должна была автоматизировать процесс слила вникуда кучу времени и бабок на абсолютно пустую работу и главное, при этом то, что эти слитые бабки вообще не гарантируют что с реальной экономической и производственной точки зрения реализованное решение - оптимально))))
Когда-то, преподавался такой предмет, как Основы Принятия Управленческих Решений, дак вот, там, в основном, была статистика... математика то есть... НО!!! Математика работает в управляемых условиях, а когда Условий (правил) нет вообще, то на что может рассчитывать руководитель/ владелец?
Поэтому и автоматизация стоит так дорого
Ещё один момент.... Откаты... это не статья УК.
И не всегда, владелец бизнеса, про них знает и вообще, как то может оценить затраты... показать на HH резюме/вакансиями с ЗП +500 000руб - легко...
команда, которая должна была автоматизировать процесс слила вникуда кучу времени и бабок на абсолютно пустую работу
Я вот почему, так на ГОСТ среагировал, а потому, что если бы "автоматизаторы" знали свою профессию, то не взялись бы "делать гвозди из хлебного мякиша".
Вынужден Вас все-таки поправить, так как не согласен вот с этим:
слила вникуда кучу времени и бабок на абсолютно пустую работу
Решение всё-таки было принято и внедрено. Да у ошибки была цена – петля через реализацию и тестовую эксплуатацию, но проект не был слит и оказался вполне экономически эффективен.
Уважаемый автор, не обижайтесь, но суть смысл и содержание фраз "слить бабки вникуда" и "завершить проект" принципиально разные)
И одно другому совершенно не мешает и никак не противоречит друг другу))))
Это не некое обвинение но круг который вы прошли вы прошли "за деньги заказчкика". Фактически это деньги которые одновременно заказчик потратил, а проект не приобрел, в качестве прибыли, а потратил в ФОТ.
Еще раз повторюсь это не обвинение именно потому, что ваша статья это очень хорошая иллюстрация среднестатистической эффективности российского промышленного бизнеса. С такими "кольцами неэффективности" работают все проекты и все процессное управление в сегменте промышленного бизнеса в РФ и теряют на этом триллионы рублей прибыли (ориентировочно это потери более 20 триллионов ежегодно).
Но такая "эффективность" в моменте - с одной стороны не причина принимать это за норму, а с другой - реальная иллюстрация размеров рынка автоматизации пром.управления и того, на сколько можно поднять маржинальность бизнеса, решив причины неэффективного управления)
Не буду говорить об управлении в широком смысле а коснусь только промышленного управления.
Я не знаком с опытом авторов поста и комментариев в производственных компаниях но мои наблюдения и наблюдения моих за почти 20 лет проектной работы почти со всеми игроками нефтехимической и нефтегазовой отрасли и их мелкими и средними "сателитами"-подрядчиками и наблюдение за процессами управления в них от нижнего уровня до уровня холдингов говорят о том, что сейчас в пром.управлении НЕТ никакой математики в принципе.
В одном из комментариев я увидел тезис, что "математика работает в управляемых условиях", но это не совсем верно. Математика это просто инструмент. Он работает всегда вне зависимости от условий. Т.к. всегда и любую задачу можно декомпозировать.
Из моих наблюдений следует, что дело именно в отсутствии внятной строгой научной теории управления, к которой можно было бы применять математику, а еще в том, что рос. управление эту проблему не прото и не только не видит и не понимает, но и абсолютно уверено что такой теории нет.
Для абсолютного большинства менеджмента низшего, среднего и высшего звена "вершина" и единственый критерий "правильности" решения это "здравый смысл", который у каждого отделтного руководителя здрав настолько, насколько здрав он сам).
Те, кто менее здрав - исходят из своего ограниченного опыта и пытаются его применить к действительности.
Самые здравые пытаются, как дети, собрать что-то из "кубиков" своего опыта, хороших практик и стандартов. Но и этот подход без теории, объясняющей каким образом это все собирать "правильно", что есть это "правильно" и какие критерии и законы должны быть положены в основу архитектуры управления, чтобы система работала предсказуемо после модернизации и могла давать статистические данные для развития и совершенствования.
И вот этого понимания более чем за 20 лет я не увидел ни у собственников, ни у пром. менеджмента, ни, тем более, у гос. управления уровня пром.министерств.
А итог в том, что бизнес не имея такой теории убедил себя в том, что ее нет и этот подход пытается распространить на промышленное управление)))
Именно поэтому в российской промке почти нигде нет правил, а те правил, что есть либо "дырявые", либо "формальные", либо только кажутся "правилами", а при ближайшем рассмотрении - НЕ правила и именно поэтому, как отмечалось в статье - нет единого лица которое определяет как именно правильно)
Именно поэтому в 2000х прошла регуляторная гильотина - видите ли стандарты и правила "мешали бизнесу". Именно поэтому сейчас идет "декриминализация" многих отраслей права находящихся "рядом" с промышленным управлением.
Все это звенья одной порочной цепи - деформализации управления.
Еще одна "беда" бизнеса в абсолютизации принципа разделения труда и в непонимании необходимости синтетического подхода к управлению - это вторая причина по которой в компаниях нет лица, которое бы решало "как надо в целом" - ведь для этого требуется не только освоить производство и в своей голове "соединить" различные отрасли знаний - технологию, механику, электрику и АСУ (таких спецов я встречал единицы...наверное пальцев 2х рук хватит, чтобы их сосчитать) но и освоить 2 различных типа управления - процессное и проектное, причем в промышленности есть еще процесс проектирования со своими особенностями (таких спецов я встречал единицы), а уже на это наложить хорошее знание процесса снабжения, закупок и учета и их особенности в каждом из 2х типов управлнния (таких спецов я не знаю ни одного).
А чтобы таким лицом стать надо очень много и долго учиться сочетая работу и учебу, ведь таких программ обучения в готовом виде - нет и без практического опыта теория, которую дают университетские преподаватели, оторванные от реального производства практически неприменима.
И суть тут в том, что сколько бы не трудились "автоматизаторщики" без нормальной теории и без понимания того как в комплексе должна работать система с низа до верха попытки автоматизировать управление даже в промке, где сложность управления - минимальна, не более разумны, чем занятия алхимией при современном уровне развития теоретической и практической химии)
Из всего этого есть 3 важных, именно для сферы IT, вывода и как мне видится именно таким должен был быть итог статьи...тогда она бвла бы более полной и более полезной и рядовым IT-инженерам и руководителям IT-сферы и IT-предпринимателям, не в обиду автору:
1. Ждать от бизнеса "решения" в текущих реалиях - бессмысленно и неразумно. Более разумно компании которая занимается автоматизацией приходить и давать готовые решения "как надо". Это сэкономит и бюджет, и сроки, и Opex заказчика (в последующем), это ведь "автоматизация").
А проекты стоит брать "под ключ" - автоматизация+пром.консалтинг.
Также при заключении договоров стоит предлагать бизнесу не абстрактную автоматизауию, а конкретное "снижение CAPEX/OPEX", это позволит более гибко "играть" ценой контракта и сделать цену контракта "прозрачной". Т.е. с одной стороны поставить стоимость автоматизации в зависимость от ее реального экономического эффекта, а с другой - снизить "моментальные выплаты" по договору за счет оплаты клиентом договора за счет % от снижения CAPEX/OPEX.
А на вопрос как это сделать реально эффективно, предсказуемо и с минимальными рисками отвечают остальные 2 вывода.
2. IT компании которые занимаются автоматизацией должны всерьез задуматься и найти применимые научные теории управления (для создания инструментов, алгоритмов и критериев эффективности, которые безбоязненно можно закладывать в т.ч. в ТЗ и не просто найти, а создать расчетные инструменты позволяющие критериально оптимизировать управление.
3. IT компаниям для проектов промышленной автоматизации стоит искать и брать в штат мультидисциплинарных специалистов прошедших путь от рабочего до руководителя, обладающих знаниями "на стыках" дисциплин (чего на рынке труда я не наблюдаю в принципе)
Надеюсь это полезно, а если интересно - готов обсудить)
Во многом согласен с диагнозом (кстати, я раньше писал про то, что мы часто начинаем "лечить" не имея диагноза), особенно с тем, что автоматизация очень быстро вскрывает места, где ручное управление держалось на опыте конкретных людей, а формального правила и владельца этого правила не было. В моём кейсе это буквально произошло: владельца процесса закупок в компании не существовало.
А вот с выводом «раз бизнес не умеет - интегратор должен приходить и говорить, как надо» я бы поспорил. На мой взгляд, интегратор действительно должен принести гораздо больше, чем просто вопрос «что вы хотите?»: модель, варианты, ограничения, экономику, риски и свою рекомендацию, пусть даже жёсткую, но последний шаг всё равно нельзя передавать консультанту.
Потому что решение «разделяем заявки» - это не настройка системы. После ухода интегратора бизнес по этому правилу будет работать (закупки, производство, инициаторы), изменится привычный процесс и ответственность. Консультант может лучше всех в комнате понимать последствия, но это ещё не делает его владельцем процесса.
Наверное правильнее было бы так - чем слабее управленческая зрелость, тем больше работы интегратор обязан сделать до выбора. Но право сказать «отныне компания работает именно так» должно остаться у того, кто потом отвечает за этот процесс. Это же кстати относится и к комментарию про потерянные деньги - чем ниже управленческая зрелость - тем выше цену платит заказчик. Эдакий "налог на некомпетентность".
И отдельно про математику: мне кажется, проблема всё же не в том, что для промышленного управления нет математического аппарата. Его много – от исследования операций и теории расписаний до управления запасами и статистического контроля. Проблема начинается раньше: если компания не определила цель, ограничения и критерий правильного результата, тот тут уж математике просто нечего оптимизировать. В этом смысле мы, кажется, говорим об одной и той же болезни с разных сторон.
для промышленного управления нет математического аппарата.
Я такого НЕ писал и НЕ заявлял.
Не стоит смешивать понятия "научная теория управления" и good practices.
Good practices очень много и "математика" со статистическими методами - лишь один из видов.
А вот собственно научной теории управления, которая обладала бы признаками доказательности, проверяемости, предсказательной силы и системности, а также давала воспроизводимые и предсказуемые результаты в зависимости от внешних условий - НЕТ в принципе.
Нет такой теории, которая бы четко и обоснованно позволяют объяснить причины эффективности good practices, границы их применимости и ограничения, обоснованно подбирать критерии, а также системно и обоснованно подбирать цели.
Именно от этого у организаций и компаний огромные проблемы.
И тут что важно - нормальной теории управления не то, чтобы нет в принципе... резличные аспекты такой теории разрабатывались и наработки есть. Важно то, что современная Economix и современная теория менеджмента исходящая из постмодернистского прагматизма и установки отсутствия истины вытеснили эти теории из академического поля в поле внутриорганизационеых процессов некоторых иностранных компаний, где эти теории продолжают развиваться ... правда без оглазки и без внимания общественности и бизнеса...
А вот с выводом «раз бизнес не умеет - интегратор должен приходить и говорить, как надо» я бы поспорил. На мой взгляд, интегратор действительно должен принести гораздо больше, чем просто вопрос «что вы хотите?»: модель, варианты, ограничения, экономику, риски и свою рекомендацию, пусть даже жёсткую, но последний шаг всё равно нельзя передавать консультанту.
Тут соль только в рисках и в умении консультанта. И тут нет смысла спорить. Это как в строительстве. Есть подряд, есть генподряд, есть смешаный договор, когда подрядчик вроде бы все делает под ключ, но заказчик в процессе руками и ногами и поэтому эффективность так себе но лучше, чем если бы управлял стройподрядчик который "ни в зуб ногой" в технологии и проектировании, за которые формально отвечает.
А есть ЕРС где заказчику сдается готовый объект, где с заказчиком не обсуждается каждый чих, а компетентный подрядчик делает качественный продукт и отвечает за качество объекта. Тут выше риски, выше требования к квалификации и организации работ НО гораздо выше чистая прибыль (настолько, что никакие серые схемы не могут ее поднять га такой уровень) и одновременно гораздо ниже себестоимость проекта. Что дает огромные конкурентные преимущества)
Зрелый интегратор действительно должен приносить не только «автоматизацию», а модель, варианты, ограничения, экономику и свою рекомендацию. Подход «заказчик сам всё придумай, а мы запрограммируем» это слабая позиция. Но здесь для меня проходит важная граница. Интегратор может сказать: «Мы рекомендуем разделять многокатегорийные заявки, вот почему и какие будут последствия». Это экспертиза. Но решение «теперь закупки работают именно так» это уже изменение бизнес-процесса. В моём кейсе проблема была не в отсутствии вариантов. Их было четыре. Проблема была в том, что не было механизма, который превращает несколько разумных вариантов в одно правило компании. Поэтому скорее так: интегратор должен помогать заказчику принимать решение и иногда жёстко рекомендовать вариант. Но право написать «ГОСТ для закупок» должно оставаться у того, кто потом отвечает за этот процесс. Иначе мы просто переносим автора ГОСТа от разработчика к консультанту.
Мы производим гвозди по ГОСТу: как идеально выполнить неправильное ТЗ