Сейчас в интернете рассказывают про преимущества автоматизации. Типа мол снижает нагрузку на человека, делает Ваш бизнес более гибким, подкованным. Можете выявлять слабые места, точки роста, оптимизировать процессы. На базе накопленных данных делать бюджетирование, прогнозирование и оптимизировать склад и т.д. и т..п. Не отрицаю. Но достаточно часто такая автоматизация не ведет к оптимизации а только ухудшает ситуацию. Я знаком с вопросом не понаслышке и хотел бы рассказать о проблемах. Благо отвечал много времени за приложения на предприятии.
Вот представьте ситуацию: есть конкретный отдел, который вручную собирает статистику делает бюджетирование. Из нескольких систем выгружают данные, потом эти данные объединяет. На этапе объединения надо где то данные сгруппировать, где то дополнить, где - то почистить. Много муторной работы. И вот появляется в таком отделе человек, который не только слышал что автоматизация это круто, но и вполне умеет работать с базами данных, настраивает экстракторы, писать скрипты и на всем этом хозяйстве строить отчеты. Навыки, на самом деле, не сильно распространенные, потому что чаще всего конкретно желающий предполагает что он может все это сделать.
И вот ему для всего этого счастья требуется база данных и доступы к нужным системам. Приходит он к таком сатрапу вроде меня и говорит: дайте базу данных и доступы. Буду все делать в свободное время, но это поможет сократить n рабочих часов нашему отделу в месяц.
Ему вторит его руководитель: “...нам это очень надо, мы готовы даже бюджет выделить...”. Руководитель думает о том, что его сотрудники часто сидят до 11 часов вечера чтоб все это гавнище свести в единый отчет и очистить данные. Перепроверить. А тут ему предлагают золотой ключик. Инициативный сотрудник рассчитывает получить премию и внеочередное продвижение по службе. И вот приходят они к сатрапу айтишнику вроде меня. Который им говорит: “хрен вам а не база данных с доступами”.
Что в такой ситуации обычно делают сотрудник с менеджером: для начала начинают считать меня мудаком ретроградом. Потом жалуются на меня моему руководителю. Часто еще и вверх по вышестоящей лестницы. Но удивительным образом, со стороны и моего руководства чаще всего получают отказ.
И вот тут начинается самое интересное: они меня считают мудаком, потому что не знают всей кухни и последствий. Я же знаю к чему это приводит. Самые простые причины почему отказываю в улучшении бизнес процессов и оптимизации:
1. Лицензия на БД и железо.
Уже забыл все термины как это точно называется правильно с точки политики того же Микрософт, но используется одна лицензия на сервер (или ядро?) и на одном сервере можно располагать кучу БД. Так что стоимость одной бд получается недорогой. Но если давать базы данных всем желающим, очень быстро начинаешь налипать на новые сервера и новые лицензии. Отделов много, подразделений много, оптимизаторов еще больше и всем давай базы данных. Железо тоже стоит недешево под все это счастье. А еще это счастье надо бэкапировать и обслуживать. А бюджет на железо и лицензии не резиновый, и руководство и так долбит постоянно, что надо бы сократить расходы а не увеличить. У меня свои KPI у вас свои.
2. Есть штатные инструменты, которые не нравятся конкретному оптимизатору.
Простой пример: чаще всего выгружают и занимаются полной херней, ровно потому что учет сделать в корпоративной (так называемой ERP) непросто и дорого. Для примера SAP (1С чуть лучше но тоже не фонтан). Когда узнают сколько будет стоить нужная оптимизация в SAP (а там за самые небольшие поделки часто выставляется стоимость квартиры в Москве), все крутят пальцем у виска и говорят спасибо не надо. То есть, долго, дорого, херова (обычно еще и сроки все консультанты срывают).
А в это время оптимизатор показывает отчеты на каком нибудь power BI где в качестве источника данных используется несколько табличек. Конечно, это все запилить просто. И летает и красиво и вообще секси. А тут предлагают этот ужасный SAP. О чем Вы вообще?
Но как человек два десятка лет занимавшийся автоматизацией, я скорее отдам предпочтение сделать все штатными средствами на базе SAP, чем плодить сущности по желаниям. Пусть и дороже, но зато это будет работать и через 10 лет. А не 2-3 года пока есть оптимизатор. По факту выйдет дешевле (не топлю за САП, главное что в существующей ERP. SAP отстой)ю
Часто доходит до абсурда: одному оптимизатору не нравится SAP (и вполне заслуженно), другому оптимизатору не нравится power BI, третьему надо чего - нибудь на в tibco spotFire. Доходит до абсурда, когда в одном управлении одни и те же процессы сделаны разными инструментами. То есть, полный зоопарк. И вот тут подходим по сути к ключевому, почему такие ретрограды вроде меня отказывают.
3. Оптимизатор не имеет представления за что он берется.
Как ни странно, несмотря на огромное кол-во якобы инженеров, которое выпускают наши ВУЗы найти реального специалиста, который знаком и с базами данных, и с программированием (чтоб наладить те же экстракторы), чтоб еще писал запросы и умел визуализировать это все не так много. Вот тут писал про свой взгляд на возможности конкретных специалистов.
При этом, надо еще разбираться в конкретной области, которую ты оптимизируешь. К примеру, так как я автоматизировал управленческий учет, то во времена внедрения, разбирался в бухучете, складском учете или кадровом учете лучше рядового бухгалтера (при этом на всех участках учета). В качестве подтверждения своих слов могу привести факт работы в качестве руководителя кадрового подразделения. И не получил ни одного взыскания за это время (ИТ там не было никаким боком.. почти.. если не считать моего желания “оптимизировать” некоторые процессы).
Как вы понимаете, редко кто все это знает и умеет. Обычно человек даже не представляет тот объем, который он хочет оптимизировать. Было забавно наблюдать, как с одной и той же задачей ко мне приходили 4 раза из разных отделов, я им объяснял эту задачу (они узнавали много нового, вплоть до того, что я им отдавал мною лично написанное ТЗ из первой итерации), каждый раз брались решать и ни разу никто не сделал.
Хуже того, часто бывает что в результате “оптимизации”, время затрачиваемое на конкретную задачу увеличивается. И я это могу видеть сразу а оптимизаторы нет. Конкретный пример: приходит ко мне девушка, которая хочет повысить мотивацию работников для рацпредложений. Мне надо сделать такой то сайт, там должно быть это, это и это. И главное КРАСИВО! (за вот это красиво вообще убивать надо, но это уже отступление).
Общий смысл, что надо собрать рац предложения, сотрудники и руководители проставляют баллы по определенному алгоритму и всех надо оповестить. Причем баллы можно проставить в голосовалке в аутлуке, собрать рацухи через письма ну и выложить результаты уже на корпоративном сайте. Зачем под это все городить отдельный сайт, кто его будет делать и поддерживать она ведь не задумывается. Ей благодарность за такую инициативу надо получить. А я вижу что через отдельный сайт затраты на всю эту херню увеличиваются в разы. А еще вероятнее, что девочка побалуется с данным проектом пол года и потом успешно все забудут про эту супер пупер инициативу. Но конкретная девушка получила одобрение у высокого руководителя и уверена что ИТ должно все сделать. Благо я с этим руководителем был хорошо знаком (а он еще в придачу очень грамотный и знаком со всем написанным в сегодняшнем материале). На одном из совещаний в двух словах объяснил почему ей отказал. Он только посмеялся. В общем как говорится "Вам шашечки или поехать?".
4. Поддержка и развитие.
Практика показывает, что конкретные наработки на коленке, сделанные оптимизатором живут пока он работает на конкретном месте. Но стоит ему уйти с данной позиции, все это перестает жить. Хорошо, если это ведет только к увеличению работы конкретных сотрудников в отделе. Хуже когда производство уже заточено на данное приложение. Доходило до смешного, когда какое то корявое приложение, по 8-12 лет использовали и боялись трогать: не дай бог что-нибудь перестанет работать. А оно и переставало работать в нужный момент.
Но тут бизнес в первую очередь business first (сразу после safety first), IT это сервис, который помогает бизнесу зарабатывать деньги, так что давайте быстро делайте или вся компания без денег останется. И вот с помощью бубна, сверхурочных и т.д. с выходами в выходные у нас все работает.
Как Вы понимаете, как человек регулярно с этим сталкивающийся, имею естественное желание сократить количество выходов в выходные и праздники. За которые меня чаще всего и не платят как раз. И как в том анекдоте, хочу убивать такие наработки пока они маленькие.
А когда начинаешь объяснять, что в целом то если Ваше предложение правильное, то давайте делать по нашим правилам: анализ, документация, техническое задание, разработка, инструкции пользователя. Сразу вопрос: кто обучает пользователей? Кто поддерживает инструкции. И самое неприятное для желающих оптимизировать у нас есть очередь разработок, уже принятых в работу. Можем Вас поставить в очередь примерно через 9 -16 месяцев (серьезно). Очередь конечно обычно меньше, но всегда есть разработки вне очереди. Поэтому сразу говоришь максимальный срок.
Если будете делать сами, мы вам сможем оказывать консультационную поддержку, но только по нашим регламентам (все логично). В качестве инструментов будем использовать только те, по которым у нас есть штатные сотрудники и чьи должностные инструкции входит поддержка таких то инструментов.
Но оптимизаторы писать документацию не хотят вместе с ТЗ и инструкциями пользователей. Проводить семинары по обучению пользователей не хотят. Это все долго ведь, муторно и фи-фи. Вот же секси: power BI на базе пары табличек, работает супер. секси и все такое. Дайте доступы и сервак, чтоб все работало шустро.
И вот тут хотел бы отметить главное отличие российской компании в которой я работал от западной: в российской никакому оптимизатору не получится пропихнуть свою разработку мимо ИТ. Если ИТ сказало нет, то значит нет. А вот в иностранной есть разные способы, как пропихнуть. Через директоров, через свой личный бюджет или через низкую дисциплину.
Мне лично импонирует российский подход, так как если смотреть на дистанции в 5-10 лет он более эффективен. Долго принимают, долго согласовывают. Но коль уж согласовали, то будет работать и у всех во всех подразделениях одинаково. А в западной компании, где я работал, по данному вопросу зоопарк, с которым непонятно что делать.
Любой ИТ специалист прекрасно знает, что поддерживать одно приложение в рамках крупной компании дешевле и лучше чем штук 20 в разных инстанциях. Мое любимое выражение: лучше безобразно, но единообразно. Это дешевле и видна картина целиком и не надо все компилировать и сращивать.
5. Вот наше говнище. Это вам. Возьмите и распишитесь (ключевое).
Самое неприятное в такой ситуации, когда какой то оптимизатор (гораздо хуже когда это команда оптимизаторов) увольняется или переводится. На это завязаны бизнес процессы и надо поддерживать. Как результат, все “наработки” передают в ИТ. Как мы помним, чаще всего в такой ситуации, нет ни документации ни даже инструкций пользователей. А все сакральные знания оптимизатора находятся в его голове. При увольнении он там что - то напишет в hand overе, но это будет составлять в лучшем случае 10 процентов от необходимого. И что с этим счастьем делать непонятно.
Как мы помним, в ИТ проходят оптимизации и сокращения, люди и так завалены работой. А тут им дают еще кучу чужого говна. И это дополнительная работа чтоб привести в порядок.
Бывает что такие поделки живут еще 3-5-8 лет и их потом либо оптимизаторы другие оптимизаторы с оптимизируют, либо по регламентам переведут на общие рельсы.
Вывод
Условно говоря, когда оптимизатор приходит ко мне он не видит всей этой кухней, которая есть у нас. Более того, часто он даже не может понять о чем я говорю. Людям со стороны часто непонятно что говорит профессионал более высокого уровня. Забавно было, как в некоторых статьях меня пытались высмеять люди, вообще в ИТ слабо разбирающиеся. Условно говоря я им говорю про архитектуру, а они меня пытаются высмеять по поводу того, что я не знаю Phyton.
Когда ты не видишь всей кухни и не разбираешься в процессе, многие решения кажутся глупыми и бестолковыми. Если же тут уйти в сторону принятия решений высокопоставленными руководителями, то со стороны многие решения кажутся глупыми и бестолковыми. А по факту являются наиболее рациональными. Но не профессионалу они кажутся бестолковыми.
Хорошо, когда есть грамотный руководитель и плохо, когда левый человек, не разбираясь в процессах начинает руководить большими структурами. К примеру, плохо когда Оксана Пушкина девочка проводит закон о домашнем насилии принимает законы в которых не разбирается. По факту, сегодняшняя статья больше про внутреннюю кухню сложных процессов и как это выглядит со стороны для обывателя. Просто привел пример на базе собственного опыта. Но лучше перевести на то, как мы рассматриваем многие постановления или законы со стороны обывателей.
Специально для Anisiya: Вас разбанил, так как Вы много рассказывали про свою компетенцию. Будет интересно Ваше мнение.
Комментарии
не поделитесь успехами?
или просто скачете с одной руководящей должности на другую "в разных компаниях" и просто не паритесь как оно там после вашего руководства?
а то после такого вот руководства обычно зовут таких незнаек как я чтобы расковырять говно и заставить работать - как правило очень малый процент таких вот руководителей способен в принципе разобраться в ситуации а не просто спустить указивку - ибо проще чтоб талантливый мальчик чо то налабал и получить премию за успешное выполнение задание чем разбираться в проблеме с профи - знаем плавали
Можно давать возможность только с использованием штатных инструментов и с обязательным соблюдением регламентов.
И да, я описываю ситуацию, когда бухгалтер или инженер хотят оптимизировать свои процессы.
Если же просто дать доступы: то нахерачит, переведется и что потом делать с этим говнишем? В статье описаны проблемы.
Нужны конкретные примеры. В целом ваш подход понятен. Специалисты регулярно «костенеют» и приходится делать «массаж оргструктуры». Но при этом (приводил уже тут пример этот) попытка сделать полноценный MRP алгоритм на BI системе — это злое зло и отстреливать нужно было ещё на подлёте между этих самых горящих глаз.
Статья о том, что попытка заменить что-то в системе управления более чем одной командой неизбежно ведет к потере управления, а главное - она слишком дорога.
Ну и о том, что работник одной службы предприятия часто просто не имеет понятия о принципах работы другой службы.
А проблему масштабирования вы очень хорошо продемонстрировали примером. Если начинать на корабле перекладывать рули, как на маленькой лодочке, можно и потопить.
Кстати, инерция на большом корабле не проблема, а средство устойчивости. Она помогает ему проходить через такие шторма, где верткие лодки тонут.
А разумная модернизация на них проходит. Затухают, по большей части, импульсы по "модным", или как говорят сейчас "трендовым" изменениям, которые потом пришлось бы все равно демонтировать, с затратами.
Столкнулся тут с такой ситуацией. По моей просьбе программисты выгрузили мне часть базы данных - огромный объем значений измерений, произведённых нашим оборудованием. Однако после того, как я приступил к работе с ними я выяснил, что в базе масса ошибок. А это святая святых нашей компании, с ней носятся как с писаной тобой, а по факту никто толком и не знает как она организована.
Это я к тому, что перед тем, как заниматься автоматизациией, неплохо бы сначала разобраться с базами-вдруг что не так?
Кстати, перед увольнением замутил проект по внедрению системы проверки качества. Я инициатор, проект вел другой специалист. Idatanetric. Бизнес был в восторге. Проект взлетел просто.
Медалек бывший коллега получил недавно.
Пока внедрял ерп, были наборы скриптов для проверки качества данных. Особо радовало сообщения о колоссальных объёмвз работ на каждом предприятии. Вычислялись на раз. С предложением или работать или пойти со мной на разбор к руководству. Предпочитали начать работать.
Есть такая модная, но от этого не менее интересная тема роботизации процессов - RPA. Она позволяет направлять инициативу сотрудников в "мирное русло" и с ее помощью можно сделать,по аналогии с медициной временный костыль , а можно постоянный протез бионический. А вообще современные инструменты автоматизации все больше идут в сторону low-code и переносят разработку решений по автоматизации на прользователя ( квалифицированного конечно).
Это хорошая история, она должна дополнять, а не заменять. Попытка самим напилить например решение класса TMS или WMS — это очень плохая затея для бизнеса. Лоу код никакой не спасёт. Лоу код помогает если речь идёт об одной узкой предметной области, а если надо что-то побольше сделать, то мозгов одного человека не хватает и начинается цирк с конями.
Да, я до пяти лет в сказки верил. По факту реального выхлопа не видел.
Своими глазами видел зарплатную ведомость с разными цифрами на экране и в распечатке.
Своими глазами видел пользовательский интерфейс с чёрными буквами на красном фоне.
Ненавижу программистов.
1) так попросили сделать в отделе кадров
2) это было предупреждение о форматировании жёсткого диска
не спешите ненавидеть программистов :)
Есть здравые мысли, но в целом, не в обиду будь сказано, попахивает дилетантством.
:).
По существу есть что сказать? В целом и позиция и компания моя вычисляется в пару кликов с vpn.
Например вы в одну кучу валите людей, которые действительно могут, добавить/улучшить некий функционал своими силами с девочкой, которая хочет чтоб ей сделали сайт с кнопкой "сделать всё хорошо".
Что касается лицензий на ms-sql, есть два варианта, лицензирование по количеству задействованных ядер или по количеству юзеров. Во всяком случае до недавнего времени было так, прям щас не проверял.
Кроме того есть бесплатный с некоторых пор девелопер эдишен, в принципе, для ненавистных вам " оптимизаторов" можно сказать практически легально подходит.
Да, вещи сделанные энтузиастами трудно поддерживать или невозможно, но иногда нет других вариантов решения. Сам сталкивался с такой проблемой, когда бутылочным горлышком была производительность внешних разработчиков, и сам выступал в роли вашего "оптимизатора" чтоб порешать те задачи которые они не успевали/отказывались брать в разработку.
Ну я отметил, что насчёт решения"штатными" средствами" с соблюдением всех регламентов не имею ничего против.
Говно этот ваш поверби. Как-то однажды beck восхотел странного, загнать xml-выгрузку из БД приложения в табличку. Поверби пожжужал, сгенерил красивый код запрос, всё так красиво нарисовал, и... пролюбил половину полей. Либреофис просто сделал.
Даа, мне тоже сосед как то Шаляпина написал. Такая фигня. Вообще!!!
Beckу никто про поверби не рассказывал. У тебя либо с логикой проблемы, либо ты, как поверби, половину сообщения пролюбил.
Если в вы работали до этого с тибко, sap bi и решили сравнить с power bi, то он хороший. Даже по сравнению с ms access в части визуализации данных .
Проблема инициаторов, внедрения и последующего использования не в кривизне идей, или ресурсах, а в том что нет конечного потребителя продукта.
То есть оптимизация как процесс, а не как конечный нужный кому-то результат.
Лыко в строку:
Маша Гайдар с ее предложением перевести документооборот областной администрации (или куда там она прилипла) в ICQ.
ЗЫ. Отчего-то всякая оптимизация идет только по пути НАРАЩИВАНИЯ.
Больше подсистем, хороших и разных, общая шина и т.п.
Есть ли хоть один добрый IT-молодец, который СОКРАТИТ количество подсистем, самописок и примочек со всеми их свистелками-перделками?
Так я ж ровно про это.
Мы периодически пытаемся у заказчиков это сделать.
Успехов немного, оптимизаторов масса, каждый хочет добавить.
Хорошая штука Эксель. Любому оптимизатору можно сказать: «тебе надо, ты и добавляй».
:)
:) С Экселем у меня был случай. Заказчик предложил на нем простенькую бухгалтерию написать. Мотивировал тем, что его племянник учится на программиста и он, мол, сказал, что ничего сложного. А если я не соглашусь, он студентов надет.
Я заказчику ответил "КОГДА у вас это сломается, приходите, поставим и настроим вам нормальную систему.
Оно у него сломалось, естественно. Он пришел, просил вытащить данные. Мы объяснили, что дешевле их заново набить.
Нет. С момента начала обработки дерева количество инструментов столярных только увеличивалось. Качественно тренд понятно куда направлен и будет туда направлен.
Другое дело, что по аналогии будут все более совершенные конструкции и материалы инструментов. Некоторые конструкции безнадежно устареют и выйдут из использования, им на смену придут три других. Иногда может показаться, что количество инструментов уменьшается, но это только кажется. Посмотрите на функциональность ERP системы сейчас и 20 лет назад. А название вроде одно.
Человек результат не любит человека процесс потому что тот плавно перетекает в человека проблему
Какой интересный взгляд... С другой стороны баррикад, получается.
Ибо я - тоже упомянутый оптимизатор. И более того - даже не один, а представитель команды оптимизаторов.
Начнем с самого начала. Откуда мы такие красивые в белых пальто беремся /тут кто-то выше уже поднял этот вопрос в комментариях/? А оттуда, что отдел ИТ нихрена полезного не делает. А не делает просто потому, что не знает. Вообще ничего. Не, не так. Отдел ИТ в общем и целом хорошо разбирается в серверах и СУБД. И все! Но заводу /год ему от роду или второй век уже пошел - роли не играет/ и бизнесу все эти СУБД - пустой звук. Ему не эти всякие СУБД нужны, ему нужны реальные работы.
Простой пример: на нашем предприятии много лет проводится конференция молодых специалистов. Вот конференция этого года: инженер-технолог представляла систему собственной разработки /на FoxPro - уже отвал башки, но другой системы она не знает/ подбора режущего инструмента; переводчик представляла собственную систему комплектования документации /на Acess - это уже чуть лучше/; инженер-конструктор представляла программу /на Си/ подбора и конструирования пружин; инженер-программист из ИТ - чат; системный администратор из ИТ - Docker /что это такое - походу вообще кроме руководителя ИТ-отдела, который сидел в жюри, вообще никто из присутствующих не понял; из слайдов выходило, что эта хрень позволяет работать трем чатам независимо - упал один, всем остальным насрать/. Т.е. мы видим, что реальные работы проводятся оптимизаторами, а ИТ-шников только чатики и волнуют. Но завод зарабатывает не на чатиках. Завод получает деньги за готовые изделия. Вот те же пружины - подбор и конструирование вручную занимает до двух суток. С помощью предложенной инженером-конструктором программы /из конструкторского отдела на минуточку/ - время подбора сокращается до нескольких минут. Эту программу можно еще ускорить в разы, добавить полезного функционала: все прошлые разработки прописать - та-дам - в базу данных. НО! Отдел ИТ резко против: сервера же денег стоют, СУБД тоже недешевые. Потому на серверах в системе Docker крутятся чатики, а инженер-конструктор вместо своей работы пишет программу, которая и приносит доход... И получает заряд презрения от руководителя отдела ИТ на конференции.
И, что интересно, весь алгоритм этой программы уместился на один слайд. Но несколько сот инженеров-программистов отдела ИТ даже пальцем не шевельнули.
И таких случаев - десятками. И наш случай - ровно такой же: сотни документов, в каждом - тысячи цифр, все пишется от руки, исправления и помарки в документах не допускаются, поиск во всем этом - фильмы ужасов отдыхают. Пару лет дергали отдел ИТ - задолбало всех: от непосредственных работников, до начальника производства. И так появились мы, все такие в белых пальто...
Кстати, на той же самой конференции и мы представляли свои результаты. Возражения от руководителя отдела ИТ звучали вот прямо по статье - сервера, базы данных, лицензии, денюжки... Подумаешь, из-за какой-то вшивой бумажки единица продукции /и хорошо, если только одна/ ценой в пару-тройку лярдов зависнет на складе - сервер же бабосов стоит несусветных, лицензия...
Это что касается работы.
Теперь, что касается знаний.
Вы не поверите, но действительно очень забавно наблюдать, как приходит такой хрен из ИТ и начинает, растопыривая пальцы, рассказывать, что же нам надо, через слово вставляя всякие там аббревиатуры и англицизмы... И даже не понимает того простого момента, что его словесный понос почти никому не понятен, понятен только паре-тройке человек. Но эта пара-тройка человек прекрасно понимает не только то, что несет "этот из ИТ", но и то, что "этот из ИТ" не знает, что нам действительно надо, зачем и для чего.
Простой пример: детали у нас номерные, нам нужно фиксировать прохождение детали по каждой контрольной точке, отлавливать ошибки типа появления детали на точке без успешного прохождения предыдущей. Первое ТЗ: поставить в контрольных точках компьютеры. Прекрасно. Берем автора за руку и ведем его на точку: детали большие, считывающий стоит в позе зю. Куда ему подсунуть клаву и моник? Автор чешет затылок и выдает "планшет". Прекрасно. Цеплять ты его себе в нос будешь? Опять совет с затылком - "Wi-Fi". Прекрасно. А ты в курсе, что эта точка - вот эти три стеллажа? И что все три стеллажа одной точкой не накрыть? Две точки? Прекрасно. А где у тебя слова, что планшет должен сам, автоматически, переключаться между точками - оператор же тут ходит между стеллажами. Один. Если он еще и постоянно подключаться к точкам будет - планшет в печку "случайно" залетит...
Вот так, периодически гуляя с афтырем ТЗ на место, раза примерно с пятого-седьмого получаем то, что вроде бы с первого взгляда надо.
Все, что приносят потом показать, хочется выбросить на второй минуте. И это нам, кто в данной области хоть что-то понимает. Операторы выбросят сразу.
Было пару раз, что "эти из ИТ", пользуясь близостью к высшему руководству, продавливали свои решения. Где они сейчас? В лучшем случае на складе покрываются пылью веков. Ибо неудобно всем этим пользоваться.
Это вам, сидя в теплом светлом кабинетике с кондиционером, с чашечкой кофе под левой рукой, с эргономичной клавиатурой и мышкой, с стабильно работающей сеткой на 10 Гбит, с компом в худшем случае топовым позапрошлого года удобно и красиво. В полутемном цехе, где от нуля до плюс пятидесяти /и это - на расстоянии двух-трех шагов/, где пыль и грязь, где компьютеру может быть лет пятнадцать от роду, а то и больше, что на нем - не ваша вся такая няшечная десяточка или одна из тысяч копий линукса, а вся такая кондовая MS-DOS - удобства и красивости выглядят сильно иначе.
Да и откуда вы, ИТ-шники, можете знать, что и как крутится "на земле", что действительно надо непосредственному исполнителю работы? Вы ж из кабинетиков не вылазите. Тут же "на земле" нет кондиционеров, тут пыльно, грязно, тут брызги горячего масла, тут плохо пахнет...
То что вы пишите, это уже другая проблема вообще: рассогласование действия ИТ и производства.
Это другая уже проблема.
Более того, у нас как раз бизнес расставлял приоритеты по проектам. Не скажу,счто идеально. Но с бизнесом работали.
Кстати, вы описывали АСУ а не ИТ. Ну так, вроде мелочь, но принципиальная.
ПС: диплом у меня как раз инженер АСУ.
Как это назвать - дело сто пятьдесят девятое. Главное - это и есть первопричина появления оптимизаторов. Именно незнание отделом ИТ реальных потребностей.
Я вам больше скажу: потребностей вообще никто не знает. Это огромный темный лес. Но в этом лесу больше всех что-то знает как раз тот, кто по этому лесу шарится, т.е. тот, кто реально работает "на земле". Но ведь их мнение никого из отдела ИТ не интересует. Они ж сами все лучше всех знают.
Вот именно так в нашем случае отдел ИТ и отмораживается - "это АСУ, не ИТ". И мы, асушники, занимаемся оптимизацией документоформирования... Понимаете, не примет заказчик у завода изделие, если там в паспорте исправления. И паспорт подписывать не будет, если в бумагах, на основе которых выписан паспорт, исправления. Это, повторюсь, тысячи цифр /не фигура речи - средний сводный документ - тысяча цифр плюс пара сотен, специально считали/, многие "ползут" из документа в документ вместе с деталью. Я на своей АСУ могу дать наверх номер детали, ряд параметров, которые у меня получаются. Говорю, "ребята из ИТ, придите, заберите эти данные, помогите людям оформить таблицу" - "не, это ж АСУ". Бл..., так хоть не мешайте тогда. Просят вас дать сервер, СУБД - не делайте морду кирпичом, дайте. Или сами делайте. А то, б.., ни серверов, ни СУБД, нихера, только тонны презрения и палки в колеса.
И ладно бы свою работу нормально делали... Один из коллег, сидящих в одном кабинете, назначен на инвентаризацию станочного парка /или что-то в этом роде/. Его задача - из двух баз данных сделать выборку, и поместить данные в третью. Тупая механическая работа. Нужна не первый год. Никто не делает - нам доступа не дают, сами не хотят. Но это не самое интересное. Самое интересное: первыми двумя таблицами никто не пользуется - неудобно. Потому их наскоряк правят перед инвентаризацией по своим записям. И потому тупая механическая работа становится увлекательной и интересной - в одной таблице станок числится за цехом 1, во второй - за цехом 2, вот и надо выяснить, за кем же сей станок на самом деле числится, есть ли он на самом деле...
Не в обиду: диплом показывает, что вам знания дали, но не показывает, взяли ли вы эти знания.
Ещё раз: взять данные из производства, если они выдаются, это ИТ. Слить две базы данных в одну - это ИТ
У вас кто приоритеты проставлял? Бизнес или ИТ? Если ИТ, то хреновые процессы у ВАС.
Но ИТ этого не делает, это делаем мы, асушники - по вашему, оптимизаторы, ибо "это АСУ ТП, не ИТ" /это наши ИТ так отмораживаются/. В том числе и на больших совещаниях.
Как максимум - подсовывают какую конторку, которая сроду на производстве не работала и даже приблизительно не знает, какие тут есть нюансики.
У вас - ничем не лучше.
Вы думаете, та девочка с идеей сайтика - она как с Венеры прилетела, так сразу к вам с идеей прискакала? Таки нет - обычная девочка, чуть умнее остальных, и либо у ней совсем нет инструмента для выполнения рутинных операций ее работы или этот инструмент - полное г..о. Но ее, согласно ВАШИМ процессам, ВЫ послали лесом. Вывод? Она будет делать инструмент сама - как может и как умеет. А вы, весь такой в белом, "фу, оптимизаторша". Вам, б.., на таких молиться надо, холить и лееять: такие, как она, подсказывают, где проблемы, куда ВАМ руки приложить надо, а не окатывать потоками дерьма и презрения согласно процессов.
Но это же в ваши KPI не входит, верно?
Вопрос: сколько будет сэкономлено штатных единиц при реализации указанных поделок? Сколько денег? Может быть безопасность повысится? Готовы подписаться под свои утверждением перед руководством?
Нет лучше. На момент моего увольнения весь Ит вносил задачи в одно придложение и доступ к отчету с очередью и приоритетом разработок был в открытом доступе. Шах и мат. Вы опять облажались. При чем, если бы у Вас было меньше желчи, вы смогли бы это понять.
чего ???
несколько сот инженеров в ИТ? А можно завод Ваш? Просто в моем случае, Это Сахалин-2 проект. С тремя платформами, подводными трубопроводами, компрессорной станцией, кучей офисных зданий по острову и заводом СПГ с наливным терминалом. Всего (внимание ВСЕГО) в ИТ чуть больше 60 - ти человек. Инженеров примерно вполовину. Что это у Вас за завод такой? По-моему вы брешете насчет кол-ва ИТ-инженеров уж точно.
насчет меня Пруф.
Слабо сказать завод? Или только сказки рассказывать про свою крутость?
И пожалуйста, не хамите.
По деньгам - на данный текущий момент порядка четырех миллионов рублей. И не только подписаться - неоднократно озвучивал это. Последний раз - на конференции в этом году. В позапрошлом - коллега занял второе место на общероссийской конференции в Уфе /а перед этим - на корпоративной/.
Да. Удивлены, да? Полторы сотни - точно. Или где-то в этих порядках.
Уралвагонзавод.
4 млн рублей не сильно много конечно. У нас суммы значительно больше фигурировали. В общем, Ваш косяк что руководство Вас не слушает.
ну вот видите - с нескольких сотен уже сократили до полторы сотни. Мне сложно сказать что - то про Уралвагонзавод. предприятие конечно большое.
Ну да, суммы небольшие. Так и нас всего трое... И помимо своей основной работы.
А не слушает именно по изложенным вами же причинам - мы им KPI портим. Мы для них - оптимизаторы...
Да, критически важно.
В целом, экономия 4 млн это гарантированно плюс в карму при прдведении итогов. Хоть сумма и небольшая.
Я вас опять не понимаю. Если вы не смогли пробить доработку при очевидной экономии. Это ваша недоработка и косяк. Для коллектива в 3 человека на Уралвагонзаводе.
Я за такие хватался двумя руками.
Вы - отдел ИТ.
Мы - нет. И эта работа - не наша епархия. Ну не мы должны документы формировать, не мы должны отслеживать перемещение деталей. Обработку деталей - мы. Выдачу результатов обработки - мы. А дальше - нет. А дальше никому не хочется - если у них чат повиснет, за это не вздрючат, а вот если производство встанет - легко.
Вы успели меня назвать "...хреном с горы...". И много писали про ваши проблемы не поняв и половины, из того, что я говорю.
Не надо на меня экстраполировать проблемы Вашего ИТ.
А вот это кто написал:
?
Я таких забавников каждый месяц вижу /раньше, до пандемии, их больше было/, как они лихо, с первой итерации... Правда, ничего путнего такие забавники еще не принесли. Как наши собственные, так и сторонники. Вот как раз по причине непомерно раздутого самомнения и полного отсутствия знаний о процессах, которые они собрались оптимизировать.
Автоматизация на крупном предприятии всенгда начиналась с финансов-бухгалтерии. Потом продажи-склад-закупки. И только потом доходило до прямого производства, технологии, организации ремонтов оборудования, зданий и т.д. И все это на фоне оптимизации, аусорсинга и т.д. Чем дальше внедрялась автоматизация - тем сложнее, базы разрастались, ошибки накапливались, а запал пропадал. И еще процессы надо было адекватно описать. Чтобы не получалось, что надо производство под автоматизацию подстраивать, а наоборот.
А еще отдел ИТ пихал к месту и не к месту конторы, которые до этого автоматизировали бухгалтерию и склад. Которые вот ни разу не привыкли к тому, что, например, кабель связи банально могут перерубить. Случайно, конечно /хотя иногда в случайностях приходится очень сильно сомневаться/. И даже тогда ничего не должно вставать колом - нужны какие-то варианты. Ну, скажем, локальная база - во многих случаях же можно поработать и на своих данных, не тягая из общей.
Да много чего такого, что в офисе работает без шуму и пыли, а вот в грязном цеху "почему-то" перестает.
Отличный развёрнутый комментарий! Очевидно вам нужна нормальная ERP с механизмом ведения изменений мастер-данных (или/и PLM)+ MES. Пытаться что-то подобное запилить самостоятельно — самоубийство, удачных примеров не было.
Попробуйте творчески подойти к обоснованию выгод и с этим бизнес-кейсов к руководству. Иногда так получается.
Очевидно...
Но - то не наша епархия уже. Там - отдел ИТ...
А потом с описанным зверинцем кому-то придется жить. И поддерживать его жизненный цикл. Потому как "оптимизаторы" не знают простейшей истины - написание софтинки не более 10% затрат даже на этапе внедрения. Поддержка её в рабочем состоянии - это постоянные затраты. Использование различных платформ для написания - дополнительные люди в ИТ службу для её поддержки.
А так да. Всё здорово. "Молодые специалисты" написали софтинку и все вокруг должны радоваться этому......
Все верно, потом с этим зоопарком жить...
Но другого варианта нет. Я же приводил пример содержания докладов конференции этого года: технолог пишет программу для себя, переводчик, конструктор... А отдел ИТ развлекается чатами. Это проще - за неработоспособный чат не бьют, не выдергивают из-за праздничных столов, из постелей в ночь-заполночь разбираться в проблеме... А вот при сбое в работе производственной линии и неспособности оперативно-ремонтного персонала разобраться в проблеме - поднимают всех, кто может хоть что-то присоветовать. Не взирая на время и прочее. Потому каждый старается облегчить себе жизнь как может.
У нас, когда создавался отдел ИТ, нас хотели туда же - чтобы все специалисты примерно одного поля были под одним руководством. Но как только прознали создатели отдела ИТ за ночные вызовы и прочие нервы - так сразу сказали "да ну его нафиг". Сейчас у них все хорошо...
Ну да. А сколько затрат на переписывание десятков таблиц с тысячей цифр в каждой, ась? Без исправлений. И в смену таких таблиц одним человеком заполняется минимум два-три десятка. Исправление, помарка - переписывай. Иначе паспорта не будет и результат сотен людей идет в металлолом.
Нет, радоваться не должны. Вдруг кто из ба-а-а-альшого начальства узнает - это ж сразу KPI в жо..у. Лучше втоптать в грязь этих "оптимизаторов" как можно быстрее: нам хорошо, а их проблемы... Проблемы индейцев шерифа не волнуют. (с)
"Если звезды зажигаются - значит это кому-то надо"(С)Экзюпери. Если в конторе существует подобная ИТ-служба - значит это кому-то (из руководства) надо. Поэтому предлагаю разделять технические и организационные проблемы.
Есть в конторе где я сейчас работаю девушка-экономист. Развлекается табличками в excel. Заливает туда отчеты, как-то перестраивает и выдает руководству. Все было хорошо до тех пор пока бизнес-несколько не усложнился (появились новые направления). И тут выяснилось, что её таблички ни хрена не масштабируются. Что для того чтобы она успевала справится с выросшим объемом данных нужно нагрузить ещё 2-3 человек вводом дополнительной информации.
В общем закончилось как и должно было закончится - формирование нужной отчетности повесили на нормальную базу данных и забыли про её таблички (вернее они остались, но в какой-то очень вспомогательной форме).
Переписывание таблиц - это то самое "автоматизация бардака - приводит к автоматизированному бардаку". Начинаем с оптимизации бизнес-процессов и только потом тянем жадные рученки в область программирования и прочей ИТ.
Сталкивался я с конторами в которых наплодили подобных зверинцев. У них объем работы ИТ рос даже не по экспоненте, а по факториалу. И что самое противное - они ни хрена не масштабируются....
Касательно табличек: масштабируются. Структуру просто надо в БД заложить таким образом, чтоб один справочник мог выступать атрибутом другого справочника. Например, справочник людей может выступать атрибутом для других справочников, таких как: подразделение, (начальник подразделения), материально ответственный, просто руководитель, водитель автомобиля и так далее. В свою очередь статусы людей вынесены в отдельный атрибут: работник, материально ответственный, руководитель, руководитель подразделения и так далее.
Атрибуты должны быть объединены в измерения (просто набор атрибутов может выступать одиночным измерением). В частности в одно измерение требуется обьединять работника и статус.
Сущности при этом требуется нормализовать. То есть, при создании новой "таблички" желательно не объединять в одной таблице не измеряемые измерения. Например, при учете основных средств справочник сотрудников должен быть вынесен в отдельную таблицу, справочник подразделений в другую. При этом, справочник сотрудников должен использоваться один и для основных средств, и для материалов и для спецодежды и т.д.
Но создание БД - это очень редкая компетенция. По сути архитектор. От девочки администратора ожидать такое конечно глупо.
А хотите, я скажу, в чем на самом деле проблема?
Проблема в том, что этой девочке поставили задачу, она ее решает. Она - не программист, она не знает языков программирования, она не знает принципов построения баз данных... Но ей вот из этих циферок надо получить красивый график, который потом будет смотреть какой-то большой начальник. С линейкой и карандашиком - это первый раз, второй... Пошла она со своей проблемой в отдел ИТ, а ей там "у вас своя KPI, у нас - своя". Вот она и решает свою проблему как может. А может она с помощью таблиц Excel.
Более того. Рядом, за соседним столом сидит другая девочка и почти из тех же цифр готовит другие графики... И тоже в Excel. А за стеночкой - третья девочка. Эта девочка чуть менее сообразительная - она эта таблички из большей частью тех же цифр готовит в Word.
Бизнес несколько изменился и... "Ах, эти ... оптимизаторши!!!"
Даже можно не ждать, пока бизнес изменится. Просто однажды попадут все три таблички одновременно на стол большому начальнику и увидит он, что все три таблички разные. А какие они еще должны быть, если все три девочки одни и те же данные добывают сами. Каждая - для себя. Каждая берет блокнотик и бежит по нескольким местам промплощадки, где лежат нужные журналы. Десятки почерков, разные условия работы - где-то темновато, где-то холодновато, где-то дует постоянно... Одна прочитала "1", другая - "7", третья вообще решила, что это "2"... Для этих девочек это просто цифры. И начинает работать еще один принцип информационных систем дилетантов "мусор на входе - мусор на выходе". Но видно это только тому большому начальнику, который видит все три результата вместе. Он раз посетует, два посмотрит сквозь пальцы... А потом начнет страшно кричать и топать ногами... И мы тоже услышим "ах, эти ... оптимизаторши!!!"
Стесняюсь спросить: а когда эта проблема появилась, где был отдел ИТ? Чем он был в этот момент занят? Кто им не давал поставить сенсоры в точки появления нужных данных, поместить эти данные в свои базы данных, а потом, по мере надобности формировать отчеты? Какие начальству нравятся - в Excel, в PowerBi, в ... Да в чем угодно. Это даже оптимизаторам на откуп отдать можно - создать пользователя в СУБД с правами чтения из пары-тройки таблиц и пусть развлекается кто хочет и как хочет.
Походу, это правило такое: если в конторе зоопарк в области ИТ, то в данной конторе отделу ИТ совершенно неправильно назначили эти самые ключевые показатели. Отделу ИТ выгоднее кофий пить и чатиться, нежели работать.
> Стесняюсь спросить: а когда эта проблема появилась, где был отдел ИТ?
занимался задачами которое ставит руководство стоимостью в десятки миллионов вместо левых копеечных задач
Страницы