Сейчас в интернете рассказывают про преимущества автоматизации. Типа мол снижает нагрузку на человека, делает Ваш бизнес более гибким, подкованным. Можете выявлять слабые места, точки роста, оптимизировать процессы. На базе накопленных данных делать бюджетирование, прогнозирование и оптимизировать склад и т.д. и т..п. Не отрицаю. Но достаточно часто такая автоматизация не ведет к оптимизации а только ухудшает ситуацию. Я знаком с вопросом не понаслышке и хотел бы рассказать о проблемах. Благо отвечал много времени за приложения на предприятии.
Вот представьте ситуацию: есть конкретный отдел, который вручную собирает статистику делает бюджетирование. Из нескольких систем выгружают данные, потом эти данные объединяет. На этапе объединения надо где то данные сгруппировать, где то дополнить, где - то почистить. Много муторной работы. И вот появляется в таком отделе человек, который не только слышал что автоматизация это круто, но и вполне умеет работать с базами данных, настраивает экстракторы, писать скрипты и на всем этом хозяйстве строить отчеты. Навыки, на самом деле, не сильно распространенные, потому что чаще всего конкретно желающий предполагает что он может все это сделать.
И вот ему для всего этого счастья требуется база данных и доступы к нужным системам. Приходит он к таком сатрапу вроде меня и говорит: дайте базу данных и доступы. Буду все делать в свободное время, но это поможет сократить 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: Вас разбанил, так как Вы много рассказывали про свою компетенцию. Будет интересно Ваше мнение.
Комментарии
Коль уж на то пошло...
потребность в оптимизации должны озвучить сначала руководители соответствующих служб - я сам был руководитель данной службы со стороны ИТ, которая отвечала за оптимизацию. И встречались с Руководителями управлений / отделов / департаментов с другой стороны. Но у них есть обычно ключевые специалисты, которые озвучивают хотелки.
Далее можно идти на управляющий совет ИТ, но если я не одобрил, шансов утвердить на совете практически нет (да, я уже год не исполняю данную функцию, а являюсь просто блогером). Собственно и с моим утверждением, где требовалось одобрения совета в большом количестве случаев не утверждалось. Как вариант, обойти сбоку - через директоров или толкнуть на какой нибудь свой контракт мимо ИТ. И когда я говорил: "приходят ко мне", то имел ввиду именно такие рабочие совещания с руководством отделов / управлений.
Честно сказать ситуаций много всяких разных было, поэтому все расписывать смысла вообще нет. К примеру, в бытность моей работы консультантом, была у нас со стороны заказчика ключевой специалист, мнение которой значило больше, чем руководителя управления, а систему она знала лучше большинства наших консультантов. Но это уже другая история.
Вы не поняли. Интерес в оптимизации должны озвучить руководители реальных производственных, или управленческих служб. А не будущие IT-оптимизаторы
Именно они в первую очередь должны быть заинтересованы в оптимизации, ведь от этого их зарплата зависит.
И, - да - это не мнение, а просто реплика. Мнение я высказала ниже.
а кто по вашему является руководителем управлений или отделов (реже департаментов или деректоратов) ? Это они и есть.
И зачем вы за ними ходили? Это они должны были за вами ходить.
даже по тексту если смотреть:
"...Приходит он к таком сатрапу вроде меня и говорит: дайте базу данных и доступы..."
"...И вот приходят они к сатрапу айтишнику вроде меня...."
"...как с одной и той же задачей ко мне приходили 4 раза из разных отделов..."
"...приходит ко мне девушка...".
Справедливости ради обычно созвон (перед созвоном может быть или заявка по регламенту или письмо или еще что либо): обсуждение конкретного вопроса и договоренность встретится. Потом ищется место и время когда все заинтересованные могут встретится, а так как офисов было три основных, потом кто-нибудь к кому нибудь идет. регулярные встречи же проходили в нашем офисе. Ну это если с руководителями. Кому то с ходу по телефону отказывал. Или на регулярной встрече.
Девушки и юноши должны не к айтишнику приходить, а к своему непосредственному руководителю. И предлагать ему. А руководитель уже, обдумав данную идею, может написать. Только не айтишнику, простите великодушно 😅😅😅
Годный срач. Ахтунг - пахнет трольчатиной! Автор, нет ли в обсуждении упырей? Сим повелеваю - внести запись в реестр самых обсуждаемых за день.
Статья зацепила, т.к. значительное время работал в качестве "оптимизатора". Даже без BI, но задачи были во многом похожими. При этом "оптимизаторство" было лишь одной из многочисленных обязанностей. И как раз, прямо как у вас написано, недавно перешел на другую позицию и у людей, в чьи руки попали мои "поделки", появились проблемы. :)
Все, что вы пишете, во многом справедливо, но это слегка однобокий взгляд - сделать, чтобы все было правильно и устойчиво. Но, к сожалению, есть и другие факторы, которые бизнесу и руководству разных уровней приходится учитывать и балансировать между "правильно", "дешево" и "быстро". Вы правильно заметили, что в SAP любой чих имеет стоимость не самой плохой квартирки, а серьезные изменения тянут уже на виллу за пределами РФ. Если можно получить тот же функционал бесплатно (т.е. за зарплату подчиненных сотрудников, которую они и так получат), не пробивая новый проект с серьезным бюджетом, всегда будет большой соблазн так и поступить. То, что "поделки" живут 3-5-8 лет - скорее им в плюс, т.к. людей, лично заинтересованных в более продолжительной их жизни, как правило, нет. Руководителю, в чьей зоне ответственности находится бизнес-процесс, в первую очередь нужно, чтобы у него все работало, желательно дешево и оперативно. А лет через 5 он уйдет (например, на более высокую позицию) и ему будет наплевать. Кроме того, на практике в IT-компаниях и департаментах на ключевых позициях нередко сидят не очень компетентные люди, которые даже не в состоянии обеспечить нормальное ТЗ. Видел немало руководителей, которые после долгих обсуждений с консультантами и менеджерами проектов из IT-компаний, устав от бесплодных попыток объяснить свои потребности, выкручивались собственными силами, и не без успеха.
Ваша правда.
Однако все что я написал тоже имеет место быть. Хуже становится, когда они не останавливаются в процессе разработки. И в случае их увольнения все бизнес процессы встают колом.
Я сталкивался с подобным.
Но и со мной, непонятливым, уверен, тоже сталкивались (знать бы когда и где).
Как будто бы эту статью писал эникейщик из мелкой региональной шаражки, которому лишь бы его не трогали и не мешали сидеть на жопе ровно.
Какой развернутый и содержательный комментарий. Сразу видно глубокое понимание вопроса.
Ну для начала, поговорим про стоимость инфраструктуры... Для того чтобы проверить какую-то теорию и запустить тестовый сервис -- стоимость даже выделенного сервера копеечная и если руководство прям жмоты, то всегда можно арендовать виртуалку за 100-500р в месяц, на которой можно провести тестирование с ограниченным набором данных.
Что там до "разрастания" инфраструктуры, то есть такое понятие -- "инфраструктура как код", которое нам говорит про автоматизацию поддержки инфраструктуры + тысячи разных мониторингов, что в итоге для "админа" выливается в сидение на жопе ровно и простое наблюдение.
Поддержка приложений, на данный момент, наверное, самый автоматизированный процесс, просто надо это один раз нормально настроить.
То что ничего не хочется изучать нового -- это понятно, просто бы до пенсии досидеть и класс было бы, да?)
Это ваще-то армейское - "В армии должен быть порядок - пусть безобразный, но единообразный"
Не знал. Где то услышал видать и повторял :)
дел
Таких оптимизаторов нужно сцаными тряпками гнать.
Естественно, что должен быть штат тех, кто обучает даже последнюю уборщицу. Постоянно обучает всем новинкам и изменениям.
Бегает, как скорая помощь, по всем цехам и службам. Это называется внедрение и сопровождение. Для этого должны работать специальные люди в штате. А не по договору.
Специалисты, которые программируют, должны оставлять тоже свои разработки в доступе для тех, у кого есть компетенция, чтобы знакомиться с этим всем (а не править что попало).
Программисты не должны заниматься улучшениями. Их дело - только чётко выполнять поставленные ТЗ, которые им ставит руклводитель/начальник всех проектов
Руклводитель/начальник проектов потребность в том или ином новом проекте или даже изменении обсуждает/согласовывает с заинтересованными начальниками цехов и служб, которые хотят эти изменения /улучшения/проекты получить, а не самостоятельно высосав из пальца на основании какого-нибудь блеяния какого-нибудь старшего помощника младшего менеджера
Потребность в глобальном проекте/переделке часто от руководителей служб/отделов не получишь. Зачим им лишний головняк, если все и так работает? Потребность в глобальных проектах обычно получают от владельца бизнеса. И все тут начинают усиленно думать))) пока очередь не докатывается до программы. Но до этого нужно обсудить и внедрить реальные процессы (новые).
Короче. Всё должно быть так: сначала новый проект нужен кому-то из руководителей. Потом это докатывается до начальника службы/проектов виртуальной, потом это доводится до сисадминов и программиста. И потом они начинают работать. После того, как обсудили, как это повлияет на систему в целом, а потом уже разные регистры, примочки, отчёты и так далее
Но позволить себе такие вещи могут не все. Только большие компании. А в маленьких я не работала и не знаю, как там дела делаются.
ну слава богу :).
И-да- дайте своим быашим коллегам совет: так как система постоянно развивается - инструкций не напишешься. Мы ролики записывали. Специальной программой, которая показывает то, что делается на экране, виден мышка-укащатель и слышен голос комментирующего происходящее на экране. Таких программок превеликое множество. У нас была библиотека роликов. Я своих девочек научила и они своими свежими бодрыми голосами даже мотивировали слушающих.
Роликов была целая библиотека. Более 400-т. Все строго каталогизированно.
Сергей, раз у вас большой опыт работы со сложными системами, можете порекомендовать литературу для самообразования?
Вряд ли посоветую.
Я вообще за то, чтоб изучать в реальной жизни. За деньги. ну и параллельно что - то изучая. ПО возможности. При возникновении необходимости. А там уже или программирование, или умение общаться, излагать мысли, анализировать БП и так далее.
"На базе накопленных данных делать бюджетирование, прогнозирование и оптимизировать склад и т.д."
Хочу немножко уточнить, что я не занималась "бюджетированием, прогнозированием, оптимизированием". Это дело плановиков, аналитиков, руководителей складов.
Я занималась автоматмзацией производственных процессов. Своё вИдение, как это должно выглядеть на выходе мне давали руководители производства, а такжею
" бюджетисты, оптимизаторы и аналитики".
Слишком большое у меня было "хозяйство", чтобы этим заниматься в одиночку)) Да и не моя это поляна, чтобы на неё лезть. Для этого были свои службы, департамент и отделы.
У меня было производство. Альфа и омега всего.
Ну вот, расскажу: на любом предприятии со сложным производством есть, как правило, переделы . Автору статьи знакомо это понятие?
Первый передел, второй передел. Ну, можно назвать этапами производства.
На каждом пределе может быть несколько разных производственных операций. Ну, например, нулевой этап. Когда печатные платы про гоняют я через станки ЧПУ и на них ставятся сотни транзисторов, резисторов и разных других чип -компонентов. Потом эти платы проходят проверку на станке оптическим методом. Кроме этого, на данном этапе есть поступление со склада данных чип-компонентов, которые находятся на складе.
Что здесь нужно автоматизировать? Ну, во-первых, это информация, какие именно печатные платы должны делать в эту смену рабочие. Отсюда - какие именно платы и чип-компоненты должны податься со склада в цех. А для этого нужно знать заказ покупателей, что именно они заказали.
Плюс стандартные приборы, которые делаются не по заказу покупателя, а на склад.
Вот тут программа должна "сообразить", какие именно задания дать на 1 этап. Потому что заказы покупателей приоритетнее, чем стандартная продукция. И выдать заказ на склад. По этому заказу кладовщик должен собрать комплектующие и привезти в цех.
Комплектующие не валом, кучкой, а под маршрутно-технолгические карты. По этим МТК рабочий начнёт выполнять заказ. Программа выдаст ему МТК, с перечнем компонентов и рабочий начинает делать.
Также программа должна подсказать рабочему, на каком конкретно станке ЧПУ рабочий должен делать МТК и в каком порядке за смену. Затем оптический контроль, рабочий на контроле должно внести определённую информацию в программу.
Понятно? В основном производственная деятельность. Потому что она альфа и омега всего того, что вокруг накручено. И
Ну и потом эти МТК идут дальше по всем производственным переделам. До упаковки и выпуска. Далее на склад готовой продукции и отгрузка конкретным заказчикам.
И только потом на все эти производственные манипуляции накручиваются и бюджетирование, и анализ и так далее.
Так как я не занималась бюджетированием и анализом, то чем же занималась я? Принимала заказы от различных депертаментов, которым нужны были ИНСТРУМЕНТЫ для анализа, бюджетирование, оптимизации, прогнозирования и графики поставок от поставщиков. И так далее. Плюс бухгалтерия хотела в определённом виде слить в свою бухгалтерскую программу все производственные данные. Но без таких подробностей, как я описала выше.
Ну вот я и делала инструменты для всех вышеперечисленных товарищей. Они мне делали заказ на инструмент и я долго думала, каким образом должны в этот инструмент собираться данные. Из каких регистров и так далее.
Писала ТЗ программисту, который тоже возмущался, что это слишком сложно и вообще невозможно. И мы с ним вместе искали консенсус)))
Меня вообще данные, как таковые, не интересовали. И так голова была, как дом советов.
Я описала только самое главное, без подробностей.
Ну и, соответственно, у меня была служба, в которую входили в том числе, программисты, внедренцы, сопровожденцы и так далее.
Нельзя было, чтобы что-то остановилось на заводе из-за нас. Издержки безбумажнлй технологии. Всё только в программе. Так требовало руководство.
Это очень сложная работа, предполагающая огромную ответственность.
Извиняюсь за ошибки. Со смартфона исправить не могу. Текст сразу уезжает наверх.
Страницы