Сейчас в интернете рассказывают про преимущества автоматизации. Типа мол снижает нагрузку на человека, делает Ваш бизнес более гибким, подкованным. Можете выявлять слабые места, точки роста, оптимизировать процессы. На базе накопленных данных делать бюджетирование, прогнозирование и оптимизировать склад и т.д. и т..п. Не отрицаю. Но достаточно часто такая автоматизация не ведет к оптимизации а только ухудшает ситуацию. Я знаком с вопросом не понаслышке и хотел бы рассказать о проблемах. Благо отвечал много времени за приложения на предприятии.
Вот представьте ситуацию: есть конкретный отдел, который вручную собирает статистику делает бюджетирование. Из нескольких систем выгружают данные, потом эти данные объединяет. На этапе объединения надо где то данные сгруппировать, где то дополнить, где - то почистить. Много муторной работы. И вот появляется в таком отделе человек, который не только слышал что автоматизация это круто, но и вполне умеет работать с базами данных, настраивает экстракторы, писать скрипты и на всем этом хозяйстве строить отчеты. Навыки, на самом деле, не сильно распространенные, потому что чаще всего конкретно желающий предполагает что он может все это сделать.
И вот ему для всего этого счастья требуется база данных и доступы к нужным системам. Приходит он к таком сатрапу вроде меня и говорит: дайте базу данных и доступы. Буду все делать в свободное время, но это поможет сократить 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: Вас разбанил, так как Вы много рассказывали про свою компетенцию. Будет интересно Ваше мнение.
Комментарии
Он невменяем. Его на год забанил. Надоел он мне.
Ну тогда к чему тут вселенский плач, жалобы и стоны?
Давайте с другой стороны: в ИТ консалтинге в Москве работают в основном приезжие. Потому что надо летать в командировки и работать. Москвичи обычно не соглашаются. Это факт, можете поинтересоваться. Многие (как и я) уходят работать на предприятие, потому что устают работать в таком формате. На предприятии работать значительно проще. У меня в один год было 286 дней в командировке! При этом считалось вообще ненормальным в командировке уйти в 18:00 с работы. Это чуть ли не к саботажу приравнивалось. 21:00 - 23:00 и так каждый день. В выходные да, действительно можно было уйти в 18:00, но при условии что нет горячей работы.
Работая непосредственно на предприятии я один раз на проекте посчитал и получилось что у меня в месяц было более 340 рабочих часов. При рабочей недели в 40 часов и никто мне не оплачивал переработки. Почти каждый день уходил в 23 часа домой. Было и в 2 часа ночи. А с утра к 9:00 должен быть на рабочем месте, поглаженный и работоспособный. В том числе и в выходные. И да, еще дюлей за этот проект получил а не премию и сверхурочные. Руководство не могло оценить объём работы. Собственно, уход в 23:00 объяснялся просто - можно было добраться до дому, поспать 7 часов, отвести ребенка с утра в садик и как раз успеть в теплый светлый офис к 9:00.
вот ровно один "специалист" пытается в комментариях втоптать ИТ в грязь у меня в статье в комментариях, пытаясь свалить некомпетентность свою или своих Ит на все ИТ в целом.
Работал я в командировке... Вот ровно в таком режиме: к 8.00 чтобы был, уйти раньше 22-23 часов - как преступление. И в субботу и в воскресенье, если на предприятие пускали /чаще всего предприятия были непрерывного цикла, так что у них суббота-воскресенье-праздник - циферка на календарике другого цвета, не более/. И не потому, что вот так было надо - у меня дом, семья, жена, дети, хрена ли мне в какой дыре отираться, питаться в разных тошниловках или всухомятку? Быстрее все сделать и домой. Заплатят за сверхурочку - хорошо, нет - да и хрен бы с ними, запишу себе, с чем пришлось возиться, да в следующий раз учту это при разработке имитатора, чтобы больше дома поработать, а не тут...
Вот именно об этом я и говорю: втоптать, пока большое начальство не узнало да показатели не поменяло...
надоел мне этот поток сознания, из дальнейшей дискуссии выхожу.
Счастливого пути.
Что надо - я уже узнал.
Вот на этой фразе Вы и спалились.
Её могли сказать финансисты-экономисты, директор, акционеры, но никогда не скажет отдел ИТ.
Вы ба статейку для начала прочитали, что ли...
Это не я писал...
Хотя наши говорят точно так же.
У ИТ службы тоже есть свой бюджет. И есть куда его потратить помимо покупки новых серверов и лицензий.
Вы на пару с Капустиным интересные люди .
Бюджет составляется/планируется под конкретные будущие задачи + расходы на "текучку".
Не исключаю , конечно, что на ваших предприятиях это по другому и ваш годовой бюджет планируется примерно так :
- 12 млн - расходы на текучку
- 57 млн - внедрение SAP
- 48 млн - вдруг захочется странного.
Если ставится новая задача, то под неё выделяются дополнительные ресурсы.
И руководитель ИТ никогда не будет как Баба-Яга - "Отдел ИТ резко против: сервера же денег стоют, СУБД тоже недешевые."
Отдел ИТ может объяснить "хотельщикам" цену вопроса.
"ЗА" или "ПРОТИВ" отдел ИТ может ратовать только с точки зрения целесообразности внедрения/разработки новинок в плане общей концепции развития структуры ИТ предприятия.
вот. Приходит оптимизитор, ему надо "просто сервер" без согласования своей разработки на управляющем комитете. Вот прям здесь и сейчас.
бывали реальные ситуации, когда текучка съедалась на 80% в первые месяцы (ждали с прошлого года) и потом надо было экономить. Опять же, сервера в дата центр заказывались за 9 месяцев. И новые мощности вот просто взять не получится. Их тупо нет. И даже если клиент находит бюджет на железо, его просто взять негде. Ждать 9 месяцев. А по факту легко и 12-14. Сервера в дата центр должны быть в нужной спецификации и ближайшем магазине не купишь. Правда я сейчас рассказываю не про Москву а РКС.
Расходы на текучку могут быть в объёме одной четвертой от заявок.
У меня менеджер вел проект, так сервер ФСБ просто арестовало на 9 месяцев. На растаможке посчитали что подпадает под какой то закон и 9 месяцев (крипто чего то там) не могли документы все подготовить.
именно.
Ситуация приближенная к реальной : вводят санкции против глубоководного шельфа. наши платформы хоть и мелководные, взяли и по ошибке внесли в список. Соответственно куча софта потенциально не рабочее. Использовать можно, а обновлять нельзя. Так как там одно на другое накручивается и софт надо обновлять, идет срочная задача: выделить сервера под "песочницу" геологам для нового софта. 4 блейда а лучше 6. Сколько из указанных Вами 12 млн на это уйдет? Правильно, минимум 17. И бюджет новый никто не даст. А если не выделишь вот прям здесь и сейчас - тут не оптимизаторы а высшее руководство с главном съест. Да есть бюджет и на форс мажор, но и не один форс мажор в жизни случается. Да и сервера опять же, нельзя взять и купить. Надо ждать и думать об этом постоянно.
Не бывает так, чтобы оптимизатор появился на ровном месте. Точнее, бывает ровно в одном случае - есть сотрудник, которому решительно нечем заняться. Видел таких: у них идеи фонтанами брызжут... Делать они сами ничего не могут, что спасает. Если хоть что-то могут - тогда все еще хуже. Таких немного и они очень быстро вычисляются из общей массы: у них идеи часто из разных областей. У правильных - из одной области: он работает на одной работе, не на трех. Не может, скажем, сварщик фонтанировать идеями из области дизайна рекламного плаката, обработки углепластика и работы ходовой охотничьего вездехода директора. Одна-две идеи не из своей области у рационализатора появиться может, но никак не фонтаны.
Итак, появился нормальный оптимизатор. Это значит ровно одно - где-то появилась проблема, узкое место. Оптимизатор - сварщик, он в этих ваших процессах, бюджетах ни ухом, ни рылом. Оторвите свою ж..у от кресла, отставьте свой кофий и пойдите, выясните, в чем там дело. Там дело, чаще всего, выеденного яйца не стоит, если прихватить проблему на старте.
В общем, как с больным зубом: если побежал к врачу при первом неудобстве во рту - полчасика в кабинетике и счастливый бежишь домой; а отнесся "да ладно, я его водкой..." - операция и год-полтора ходишь на лечения и рентгены, а потом еще и к косметологу - шрамы от операций на морде маскировать.
Вы не замечаете, что в одном абзаце уже сами себе противоречите?
и
у меня оптимизаторы появлялись потому что я работу не работаю (хотя я в общем то и указал "оптимизацию от девушки" и почему не дал сервер для консолидации объёма информации). А вот у Вас все пучком. Но это другое. Я понял. Все вокруг мудаки, один Вы д'Артаньян. КОНЕЧНО.
Надо обратить внимание на что удобно.
А что сотрудников, которым решительно нечем заняться - единицы, вы, конечно, не заметили. Правильно, это удобнее: оптимизатор - значит, ему нечем заняться, значит пусть идет лесом. Я тут лучше кофеек под кондейчиком...
Я еще раз повторю: "оптимизация от девушки" - это решение проблемы, поставленной перед конкретным работником этим самым работником. Потому как его все просто бросили - задача поставлена, вот и решай. Вот они, эти работники /девочки, мальчики, дедки, бабки - не суть важно/, решают задачу как могут. Они, внезапно, не знают языков программирования, они не в курсе за архитектуру баз данных... Они что-то знают про Excel...
Не хотели решать проблему девушки - получите и распишитесь: вот вам куча немасштабируемых Excel-таблиц, живите с этим и стоните.
Давайте ближе к "природе". Не оптимизаторы, а энтузиасты - люди с повышенным содержанием железа в организме ( по народному - жило в ж...).
Такой энтузиаст берется за хобот и приводится к его ( энтузиаста ) начальнику. При нем он излагает свои идеи , начальник энтузиаста резюмирует - "Да годная идея , нам в наших бизнес/производственных процессах было бы полезно". После этого начальник энтузиаста дает ему задание на подробное описание планируемого процесса для последующей постановки задачи отделу ИТ. Потом , а иногда и никогда , отдел ИТ делает примерную оценку стоимости хотелок и получает ВЫХЛОП=Кайф от хотелок/Цена доработок.
И с этим транспорантом и с песнями вся компания идет к финансовому директору - получать
люлейсогласование доп.расходов.Примерно таким образом происходит
противоестественный отбор энтузиастов.Понятно что встречаются жесткие варианты типа дочка учредителя, которую посадили куда-нить в финансовый/юридический отдел.
Это правильный подход. Тут могут сделать следующим образом: берут на контракт (да и в целом в штат, но это сложнее) такого умника, и он чего то хреначит втихушку.
Так как за 20 лет было куча реорганизаций и увольнений, то остаются дырочки в системе безопасности. К примеру, дали одним энтузиастам сервер. Да так хорошо у них получилось что им целый отдел сделали (4-е человек). Смогли всем сэкономить компании большую. кучу денег. .Все счастливы. Но они ведь не остановились и за 7 лет столько нахерачили, что просто писец. Куча процессов, документации ноль. Все держится в голове исключительно двух человек (скорее полтора). Для понимания, под их нагрузку уже лезвие брали.
Часто политики не соблюдаются, отслеживание в части доступов в соотвентствии со штатным расписанием выполняется с регулярными косяками. К безопасности тоже куча вопросов.
И вот приходит следующий оптимизиатор, ему уже сервер не дают. Но зато ему дают втихушку место на сервере предыдущие оптимизаторы. 4-е года и опять куча процессов компании завязано и на эти поделки. Это все кстати до меня было.
ПРи чем, им уже нужна служба поддержки, обучать пользователей. Они сами не рады уже всему этому счастью. Хотят передать в ИТ. А как передать? Мы принимаем с документацией и инструкциями. Переписывать или разбираться тоже возможностей нет. Клинч. И они не рады и на аудитах все двойки получают. Потому что жопа. Но продолжают хреначить новые фичи.
И наступает момент когда "бизнесу" приходит понимание что лучше сейчас заплатить большие деньги чем потом влететь на огромные.
После чего нанимается фирма работающая на относительно стандартных распространенных инструментах, которая переписывает все с нуля.
Ну на самом деле реструктуризация процессов связанная с ростом масштабов фирмы - совершенно обычное дело во всех областях. ИТ здесь не исключение. То что было нормально для шараш-монтаж уже не прокатит для сети таких же шараш-монтажей. Просто в силу ограниченной масштабируемости используемых решений. И платить за новое придется в любом случае.
Вот именно об этом и речь: а вы эти семь лет что делали? Кто вам не давал взять проект в свои мозолистые руки? Сами же пишете: сэкономили кучу денег. Значит, делали что-то реально нужное. Цельных семь лет. Сами. Как могут и как умеют.
И вот мы видим стон и жалобы...
Давайте.
Оптимизатор из разряда "шило в ж..е" - это именно о них я и написал:
За всю свою многолетнюю практику /более четверти века/ такого видел ровно одного. Причем как раз наихудшую ипостась - он что-то умел. И, что еще хуже, кое-что знал.
Его бесполезно было брать за хобот - язык у него подвешен был как надо, обрывки знаний позволяли оформить словесный поток и даже был способен примерно распланировать процесс. К оценке стоимости нормального проекта вполне мог приложить собственную оценку, в разы ниже. Т.е. получалось, что вроде бы решает реальную задачу и куда лучше асушников и итшников вместе взятых /я с ним столкнулся как раз на совместной задаче: взять данные с приборов, закопить их в базе данных, нескольким потребителям дать возможность смотреть данные в реальном времени, печать отчетов/. Вот в данном случае он предложил не делать сбор данных с приборов - производитель приборов предоставляет свою программу сбора данных /однопользовательскую - показать возможности/, в базу данных ничего не писать /в той программе есть своя, своего закрытого формата/, не делать отчеты /в той программе есть свои/... Все что надо было сделать - предоставить компьютеры всем потребителям, сеть между ними, и TeamViewer. Это все - копейки, по сравнению с нормальным вариантом. Правда, на второй день эксплуатации кто-то из операторов /кому надо было только смотреть данные/ нажал кнопочку и стер все архивы и шаблоны отчетов: программа однопользовательская, потому там никаких защитных функций не было как класса... И сутки работы огромного цеха пошли в металлолом - ну кто ж допустит к использованию ответственные детали, которые неизвестно на каких режимах обрабатывались.
Гораздо чаще встречались правильные - которые только предлагали идеи по улучшению, облегчению собственного труда. Только предлагали. Своему начальству, нам, асушникам... А мы вместе уже готовили обоснование, ТЗ с разделением функций... Часто - помогали местным готовить документы для введения изменений в техпроцесс. И вот со всем пакетом уже шли к большому начальству...
Обычно никаких свистелок и перделок у нас не предлагают /или такие свистелки отсеиваются на уровне "начальник рационализатора"/ - до нас такое не доходит. Все, что предлагается, так или иначе облегчает труд или уменьшает вредный человеческий фактор: люди - самое слабое звено, они жутко ленивы - если есть возможность сделать вид выполненности работы не выполняя ее, они обязательно это сделают. Максимум - вводя улучшение тут, ухудшали где-то там. Это нормально - скажем, сварщик не обязан знать, как функционирует система управления, как формируются те или иные данные, как они передаются... Или улучшение требовало огромных усилий, не соответствующих ожидаемому улучшению.
Даже более того. У нас ежегодно проводятся конкурсы рационализаторов. Вот как раз для нормальных. Чтобы выявлять проблемы на ранних стадиях, не доводя до реальных головняков.
А что не так? Естественно сервера денег стоят. СУБД лицензии оракла и мискрософта inHouse стоят дорого. При этом, за бюджетом на лицензии и железо руководство постоянно следит и требует снижения. Суммы не буду говорить (коммерческая информация да и не помню уже), но они очень серьезные были. И всем направо и налево выдавать сервера с СУБД - нет. Они денег стоят.
Да, ИТ руководитель у которого бюджет на сервера и лицензии об этом говорит в первую очередь. Нужен сервер? где деньги брать под него. А если под сложные задачи в геологии требуется мощный вычислительный кластер, то там только сервера с ПО выйдут в очень круглую сумму.
Следите за
рукамиконтекстом. Исходный посыл.Типа пчелы против меда. Против никак не начальник ИТ, а "руководство которое постоянно следит и требует снижения"
Прям вижу такую картину маслом, касторовым, заходит директор в отдел ИТ:
- Слушай,Вася, бухгалтерия плачется что все медленно работает. Счет-фактуры по 15 минут формируются , квартальный отчет по 4 часа делается. Оборот растет и прибыль тоже, может прикупим пару-тройку сервачков? Базу на SQL пересадим, часть пользователей на терминал?
Вася в ответ:
- Да идут они лесом". Сервера же денег стоют, СУБД тоже недешевые. Деды ваще на dbf-ах работали и эти обойдутся.
Мне всего два раза встречались начальники ИТ, которые были "резко против" - один раз в кунсткамере Петра Великого, второй раз в музее мадам Тюссо , начальник ИТ стоял как раз между Дракулой и Мусолини.
Повторюсь единственная реальная причина "резко против" - это зоопарк систем.
Там я еще сразу не заметил, у него в профиле написано что он программист. Но по его же утверждению, не в ИТ. Понятно что бардак на Уралвагонзаводе.
на пресловутом OEBS на внедрении тестировал зарплатный квиток. Понимаю, что время линейно растет от кол-ва квитков. Протестил, четко 55 секунд на кол-во квитков. Внедряем, внимание на Сибирьтелекоме. 30+ тысяч сотрудников. То есть, понимаю что время формирования квитков на всех сотрудников поставит колом сервер (19 дней только квитки).
Говорю программисту:
у тебя руки из жопынадо переписать. Сначала выгружаешь агрегированные данные и по ним уже потом формируешь зарплатные листки. Самое забавное, что ни программист меня не понял, ни руководитель проектной группы. Могу ошибаться, но по-моему были из Открытых технологий. Типа одна из ведущих консалтинговых компаний России. Коры. А могли бы сервера прикупить.Коллега у меня рассказывал: устроился архитектором в швейцарский аукционный дом какой то. В самом начале ему устроили экскурсию во Францию (разработчики в России и Франции). Ок, слетал, посмотрел на дата центр где ему показывали сервера за туеву хучу баксов или евро.
Потом он переписал одну (!!!) функцию, и нагрузка в пике упала примерно в три раза. То есть, по сути стали не нужны больше половины серверов.
Бывает.
Гыыы.
Во времена когда продукция компании M$ считалась бесплатной и в моду вошли самописки, довелось переписывать зарплату для одной конторки, человек на тысячу.
Перевели с dbf на Interbase. Отдали свое творчество на тестирование у бухию. Они попроверяли - вроде все что надо есть, тока ЗП не считается.
Приходим выяснять - оказывается после нажатия кнопки "Расчет" нет, как обычно, "часиков" на полчаса. Расчет шел менее 3 сек.
Добавили окошко "Расчет окончен".
Вы представляете, программисты нужны не только в ИТ. В жизни есть не только базы данных и чатики. Вы даже представить себе не можете, сколько программ крутится "на земле" в производстве. И сколько тут самых разных программистов... Есть даже программисты в технологическом отделе: они пишут технологические программы для станков.
так еще и кого то откатов лишил)
Значит, причина нереальная. Ибо зоопарк систем лечится элементарно просто - тетеньку-разработчицу похвалить, программу ее стереть, взять у нее алгоритм /он не сложный - лист А4 весьма немелким почерком/ и поручить своим программистам сделать как надо. Даже за алгоритм платить не надо - он не тетенькой придуман, он стандартный.
Но по факту мы имеем: начальник ИТ против. Просто против. Даже в той ее версии, что была представлена на конференции и никаких серверов не требует.
у вас залежи слешей, что девать некуда и вы их случайным образом по тексту раскидываете? читать тяжело
Я на своём веку повидал тоже всякого, и зоопарк, и единообразного разнообразия. На глубине от 10 лет, всё обычно превращается в хаос. Если нет системы норм контроля. Такой я видел только на режимных предприятиях, связанных с военными. Во всяких федеральных агентствах и ведомствах процветает зоопарк и неразбериха. Потому как меняются руководители, меняются исполнители, уходят ответственные, зарплаты не очень высокие, тендеры проводятся и т д.
Также повидал сделанные на коленке средства малой автоматизации на базе excel или access. На базе таких штук работали отделы, а то и целые предприятия. В какой-то момент они начинали накрываться медным тазом, из-за накопленных ошибок, которые "разработчики" в силу отсутствия знания, или времени не могли исправить или развить дальше. Приходил я, который всё может, и вдыхал в это поделие второе дыхание. Переводя, например, на клиент серверную архитектуру. сервером становилась какая-нибудь взрослая СУБД, а клиентом так и оставался карманный access. И всё могло работать дальше и приносить прибыль конторе.
Сейчас я работаю в большом отечественном холдинге, чисто sql dev. Вот казалось бы всё хорошо аджайл, спринты, тфс, но.. Начиналось всё хорошо, а вот сейчас руководство "оптимизировано" штатную структуру. И сократило персонал по минимуму. Порезали аналитиков, тестировщиков, разработчиков не трогали у нас и так недобор и текучка. Даже должность тимлида упразднили.
В итоге теперь все задачи на разработку, не проходят проработку аналитиками, которые переведут мыслеформы заказчика в четкое ТЗ, напрямую к разработчикам. Причем много супер срочно, с приоритетом 0, наличие в разработке задача приоритетом 0, это не нормально, а наличие одновременно нескольких задач, на одних и тех же людей с таким приоритетом, это ненормально в степени кол-ва таких задач. Зачастую это напоминает бег по кругу, поскольку бешенный принтер печатает эти бесконечные доработки, которые порой противоречат тому что было сделано раньшеи опять нужно время, чтобы согласовать, что делать в этом случае.
Раньше все эти доработки, которые шли в реализацию попадали в ТЗ, то есть все укладывалось в изначальное тз, актуализируя его на текущее состояние и новый человек придя мог поднять документ изучить его, открыв параллельно реализацию понять что к чему и почему. Сейчас же такой возможности нет. И я прекрасно понимаю, что если уволюсь я, что человек который придет на мое место ничего толком не поймёт и будет мастерить костыли, чтобы работало.
Когда речь о больших системных процессах, то, безусловно, никого туда подпускать на пушечный выстрел нельзя.
Когда речь о мелочах, решающих рутину конкретного человека - почему бы и нет? На прошлой работе нужно было XML-ки из Росреестра переводить в читаемый вид, никаких программ (на тот момент), которые бы это делали не было, сайты по переводу были, но они работали медленно. Попросил коллегу из ИТ чем-то помочь, он за пару дней написал прогу, которая за 2-3 минуты переводила около 1000 выписок в читаемый вид. Были сложные выписки (порядка 25%, которые не переводились его программой), их уже через сайт преобразовывали (а там скорость 3 выписки в минуту). На другой работе нужно было регулярно считать неустойку по 44-ФЗ, сам себе написал формулу в Excel, времени экономило массу, вся контора пользовалась. А когда пришла проверка из контрольного управления, возник спор, кто правильнее считает (т.к. наши сотрудники подозрительно быстро считали), но наши победили :) [к слову, когда писал эту формулу, нашел ошибку в законе, там были условия до 50% и больше 50%, а точно 50% не было]
И последняя история как анекдот. Воронежский филиал компании "Гарант", 2001 год, есть девочка типа секретаря в обязанности которой входит заполнять договоры на поставку программы, так она постоянно косячила, ее постоянно ругали, но на ту мизерную зарплату никто бы не пошел. Предложил ей сделать шаблон в Word, чтобы она просто заполняла поля, выбирала варианты из выпадающего списка и пр. Согласилась, сделал ей шаблон, попробовала и выдала вердикт: "Я договор делаю 30 минут и в это время меня никто не трогает, а с твоим шаблоном я его сделаю за 5 и тогда мне поручат дополнительные обязанности". Вот так я не стал программистом :)
Прекрасный обзор проблемы. И да, в юриспруденции все точно так же. Но
- бывает по-всякому и там, и там)))
Мое любимое выражение по этому поводу "Автоматизация бардака - приводит к автоматизированному бардаку". Поэтому начинаем с упорядочивания и регламентирования практической деятельности сотрудников. Вот когда будет понятно кто чем и зачем занимается - тогда и приходите со своим "оптимизаторством". А до тех пор пор - нах с пляжа.
Без внятного ТЗ результат ХЗ
Я знаю это выражение. Вот только у заказчиков обычно полностью отсутствует понимание как пишется ТЗ. Поэтому до их мозга оно не доходит. Отсекается ещё на уровне ушей.
С этим не спорю. Поэтому зачастую автоматизация и обречена. Т.к. исполнитель прикрывает свой зад, а заказчику вешается лапша на уши, что он получит то что хочет. А когда получает продукт, то не доволен. А ему и показывают тз, в котором все ходы записаны и стоит подпись заказчика. Проходили.
Поэтомк заказчику и нужен спец, который проверит тз на вшивость и настоит на том, чтобы в из было то, что нужно заказчику. Но с людьми с такими компетенциями сложно. Человек должен разбираться досконально в бизнес-процессе, ну а также в it, хотя бы на уровне понимания возможностей внедряемого инструмента. Как показывает практика, для небольших предприятий это возможно, когда совладелец/владелец бизнеса имеет техническое образование и может адекватно оценить тз.
Я вам секрет страшный открою: заказчик не должен писать ТЗ. Он его должен только согласовать. Максимум - описать технологический процесс, какие данные и с какой точностью от этого процесса ему требуются.
А писать ТЗ должен исполнитель - он лучше всех знает, что и как делать.
Вы в очередной раз показываете свою некомпетентность. ТЗ может писать кто угодно. Это может быть стороння организация. Если идешь на тендер, ТЗ уже должно быть готово. Как вариант, можно тендерить отдельно ТЗ.
Если в составе заказчика есть компетентные специалисты, могут писать сами ТЗ и привлечь для отдельных разделов сторонних специалистов. Вариантов много.
В любом случае, для учета специфики предприятия требуется привлекать специалистов заказчика. Так что оптимально, когда ТЗ пишется совместно.
Более того, от грамотно написанного ТЗ зависит чаще всего объём работы. Поэтому ТЗ часто вообще отдельно тендерится. А кто будет постом исполнителем - решит лишь следующий тендер.
Так что утверждать
это демонстрация своей некомпетентности.
Да. И я видел, что туда пишут...
Не знает заказчик, что ему надо. Точнее, знает "сделайте большую красную кнопку, нажав на которую нам было бы хорошо". Если заказчик "продвинутый", то будет еще описание процесса, в результате которого заказчику становится хорошо. Причем описание будет примерно такое "мы кладем эту загогулину вот на эту плитку, нажимаем пимпочку, загорается лампочка". Чтобы по такому "ТЗ" сделать что-то внятное...
Самое свеженькое: немцам выкатили ТЗ, в котором одно из требований звучало "признаки брака по ГОСТ хххх". Пока немцы возились - мы тоже поработали на ниве модернизации почти такого же оборудования и нам было выкачено точно такое же ТЗ. Но нам оно не понравилось, и мы его переработали. Лично только по пункту "признаки брака" месяц из технологов мозги вынимал. Наше ТЗ стало больше раз в десять. Прошло какое-то время, наступило время сдачи проектов. Сначала была наша очередь "ой, а вот тут у вас сильно все неправильно, мы принимать не будем". Мы такие "вот это - ТЗ, а вот это - ваши подписи, а вот тут - все признаки расписаны, давайте составлять акт, что мы сделали не так". И все, пыл цеховых товарищей сильно пошел на убыль... А потом были немцы... Они отмотались только тем, что мол санкции и все такое.
А почему? А потому, что в ГОСТ признаки изложены для людей. Скажем, "сильная вибрация" - это как понимать? Какая величина размаха параметра будет означать "сильная"? 1 тс? 2? Или может быть 50? Люди смотрят на картинку - вот такой ширины линия - это "сильная", а если меньше - нет. Ну так та линия самописцем нарисована, компьютером так не получится.
В общем, в ГОСТ написано "куча орехов" и картинка нарисована, как выглядит куча. А надо - сколько конкретно орехов есть куча - два, три или пять.
Не исправлен пока тот ГОСТ очень приличного возраста под компьютерную технику. Единственно чего пока добились - ввели в него разрешение использовать не только обычные самописцы.
Совершенно верно.
Вы мне опять жалуетесь своими проблемами. И сообщаете про свои ошибки в ТЗ, допущенные из за вашей некомпетентности.
А вначале меня же оскорбляли.
Гениально. Супер.
Я жалуюсь???
П...ц. Нет слов...
У нас обычно написание ТЗ выглядело так.
Начальство, либо с его подачи инициатор темы, излагает хотелки.
Потом с этими "хотелками" специально обученные люди делают "флюрографию" рабочих мест - беседы по процессам , узнать "Кто на ком стоял".
Кстати, обычно на этом этапе делается много открытий, вплоть до того что уже есть какое-то решение по некоторым вопросам данной задачи, но его забросили/забыли по неясной причине.
Потом "Писатель ТЗ" компонует полученный материал , мы делаем примерную оценку и идем с этим к заказчику - утрясать детали и цены.
Причем неважно это "внутренний" или "внешний" заказ.
Смешно. Заказчику не нужно знать откуда и какие данные передаются. Ему нужно решение стоящей перед ним проблемы. Да-да. Заказчику продается не некий ПП, а решение стоящей перед ним проблемы. А каким образом она будет решена - ему абсолютно неважно. Важно её решение в заданных рамках.
Поэтому нормальное ТЗ пишется в терминах заказчика. И никак иначе. Причем пишется аналитиком понимающим процессы (бизнес, производственные и пр.) заказчика.
А разрядность передаваемых данных это не про ТЗ. Это про постановку задачи исполнителю.
Самое классное ТЗ от заказчика, которое у нас было - "Где мои деньги?"
Оптовая торговля продуктами питания с передачей товара между точками, возвратами, уценкой, списанием и недобросовестными экспедиторами.
У Анисьи Геленджик затопило.
Я ответила ниже. Правда, торопливо. Но тем не менее. А вот проблемы потопа меня не волнуют.
Как-то странно у вас там все организовано - ит-отдел принимает решение реализовывать ли фичу или нет. А где совещание с руководителем, ит-шниками, инициатором фичи, где как раз все базовые вопросы обсуждается: кто это будет делать, сколько это займет времени, сколько потребуется ресурсов, различные подводные камни, целесообразность и т.д и руководитель принимать всё-таки должен решение, а не подсылать девочек и оптимизаторов в ит-отдел после какой-то устной договоренности. Тогда никто никого не будет считать мудаком, если ответственность за принять/отклонить будет возлагать на себя управленец.
До выноса на руководство, обсуждается на уровне специалистов.
Если руководство поставило задачу обсудить возможность реализации предложения , то все равно должна быть обратная связь для него - если нельзя, то почему; если технически можно - то, что для этого надо, т.е. опять же в любом случае - какое то совещание. Не сами же специалисты должны между собой решать?
Ну так я и объяснял обычно. Ровно то что в статье написано. Обычно правда примеры приводил ещё из жизни, которые были им знакомы. На сайте ж не могу. Разглашение.
Вот и я посмеялась. Организационно все происходит не так. Мало того, потребность в оптимизации должны озвучить сначала руководители соответствующих служб, а не те, кто желает к ним залезть грязными ручками.
Страницы