Жили-были мыши. Все их обижали. Однажды пришли мыши к сове:
-Мудрая сова, помоги! Все нас едят. Скоро нас не останется. Что делать ?
Подумала сова и говорит:
-Мыши! Станьте ежами! Будете колючими и для охотников недоступны.
Побежали мыши радостно:
-Станем ежами! Станем ежами!
Вдруг одна остановилась:
-А кто-нибудь знает: как стать ежами?
Никто. Побежали обратно к сове.
-Сова! А как нам стать ежами???
-Мыши! Идите на ... Я не тактик, я - стратег !
История про терминалы, монетаристское мышление и ценные советы.
Одна голландская контора, имевшая филиал со складами в России, озаботилась неээфективностью работы склада. На выходе получалось много ошибок, да и людишек в процессах участововало поразительно много на квадратный метр площади. «Что делать?» - подумали быстрые разумом голландцы. – А, вот оно, надо автоматизировать входной и выходной контроль. ERP у нас есть, система палетирования и этикеток работает, надо только к исходящим и входящим накладным присобачить контроль штрих-кодом с терминала.
Ура! – вскричали начальники складов и стали ждать, пока штаб-квартира выродит им эту супер-пупер систему.
Первый же затык вышел с терминалами. Дело в том, что головная контора имела договор с фирмой «Zebra», генпоставщик, и мимо него ни-ни. Один стандарт, один поставщик,один фюрер (ой, это не отсюда)... Но низкий порог цены на настоятельно рекомендуемые (читай, единственно возможные) девайсы оказалась около 3000 евро за штуку, а потому приобретено было менее 10 при имевшейся потребности в 50. «Ладно» - подумали начальники российской логистики. «Сначала один склад, потом – вся Россия, а дальше «нашим будет весь мир».» Разработчик поставил на терминалы уже разработанную приложуху, начали пробовать, и выяснилось чудесное. Оказалось, что приложуха для этой версии ПО терминала не работает корректно – а именно, сворачивает окно после каждой операции, чем весь автоматизирующий эффект летит в складскую уборную со скоростью фанеры над Парижем.
Фигня война – подумали российские айтишники. И завели тикет на доработку ПО у разработчика. Тикет, дойдя до разработчика, мертво завис на стадии согласования стоимости доработки, не знаю, что там было написано, но за доработку было выкачена сумма в энное количество у.е. Так как российская логистика с закупкой терминалов и так ушла в минус по бюджету, то само собой, что этот тикет так и завис на годы.
Чисто теоретически, российские айтишники могли и сами залезть в ПО и все подкрутить с помощью ломика и какой-то матери. Но таким образом нарушили бы соглашения. Капитализм, интеллектуальная собственность.
А ошибки все множились, таблички по управлению качеством пухли, складские обмазывались вазелином перед выходом на работу, ежедневные совещания по косякам и ошибкам стали нормой.
Амортизация мирно лежащих в тумбочке терминалов тем временем перевалила за стоимость доработки ПО. То есть, фирма уже понесла убытки в стоимости основных средств, потому что боялась понести убытки на разработке. Но тем не менее, сиюминутный монетаризм продолжал довлеть в мозгах согласующих, «мы не можем выделить на это дополнительный бюджет». От этого абсурда складу было ни хрена не легче.
На каждом совещании, в каждой переписке, где касался вопрос автоматизации и терминалов, все вздыхали и молча смотрели на стену бюрократического идиотизма. Потому что по-уму, да, черт возьми, надо стать колючими. Надо закупить более дешевые и менее пафосные терминалы локально в 4-5 раз дешевле, сэкономленные на закупке бюджеты направить на разработку приложения (там приложение-то по-сути, примитив, который бы сравнивал данные системы с полученными со сканера и закрывал накладные, ну, и просто собирал для инвентаризации штрих-кода). После чего опять закупить нужное количество терминалов и внедрить на складах. Но это все были мечты, нереализуемые в рамках регламентов и согласований в компании. Пределом возможного стала печать накладной с штрих-кодами из Экселя и полем отметки. На загрузке оператор отмечал номера паллет. В офисе оператор брал заказ, и с штрих-кода вводил в ERP загруженное в конкретную машину. Ну да, сократили время оператору на выбор из заказа в накладные. Но контроля на входе\выходе это не заменило.
При чем тут IT-мышление?
Что в этой ситуации посоветует человек, который работает с техническими, а не управленческими вопросами? В глазах такого человека есть целая куча решений – продать терминалы, купить новые, перешить их на другую версию андроида (к вопросу, не взлетело), выделить деньги, дописать ПО,ломануть приложуху и наколхозить в ней исправление. Наконец, написать свое приложение.
Но в условиях корпорации это все сущая абстракция – ни одно из решений подобного рода не удалось пробить по регламентам и согласованиям. Главный голландец по филиалу ездил в Эммен в штаб-квартиру с попыткой пробить решение, и демонстрировал ошибку, на что ему просто посоветовали списать терминалы по истечению амортизации. Когда я заезжал через какое-то время после увольнения на этот склад (проезжал мимо, заглянул поймать Wifi – на гостевой доступ пароль не поменялся, и хорошо ловился со стоянки), начальник склада, потирая лысину, приглашал на распродажу этих списанных терминалов. Говорил, что заказали новые, а старые будут продавать за черный нал.
Не так давно тут в комментариях меня обругали за то, что не построил-де подрядчиков, не откидывал от них документы не по форме, не сделал для них сайт с правильными формами, а пытался подладить автоматизацию под заведомо вероятностно некорректные формы и тупых подрядов. Можно же сделать по-уму, почему нет?
И это типичное IT-мышление. Вернее, даже, так – узко-техническое мышление. Оно исходит не из сложной системы регламентов, процессов, согласований, полномочий и управленческих решений, а из простой технической возможности решения технической проблемы. На хабре такой логики раскидано как дождевых червей после дождя.
Один, например, помнится, сокрушался, что советские инженеры цилиндр для какого-то копируемого станка сделали не цельноточенным из куска железа, как это делали немцы, а из стандартной трубы, и получилось хуже. Это техническое мышление. А там целая куча управленческих наслоений – труба технологичней и дешевле, в производстве проще, станки, которые могут точить такое детали, лимитированы, и вообще неясно, насколько на практике конкретных производств действительно требуются декларируемые немцами параметры. Соответственно, если посмотреть на все в комплексе, где техническое решение есть лишь ЧАСТЬ – то чисто техническое решение, которое кажется провальным в «чистом» виде, как минимум не столь однозначно. Аналогично и в остальном.
Любое техническое решение существует в определенной СОЦИАЛЬНОЙ среде в широком смысле этого слова – и оно должно соответствовать условиям этой среды. Оптимальность технического решения определяется не простым сравнением выходных параметров, а решением в первую очередь проблемы, возникающей в этой среде с минимальными издержками для среды.
В общем и целом, если для технического решения требуется изменить управленческие, экономические, социальные механизмы, нарушить налаженное взаимодействие – то издержки будут почти всегда сильно существенней чисто технических. Если мы меняем систему взаимодействия между контрагентами лишь потому, что IT-шник посчитал, что будет проще и по-уму, например, заказ хватать не из писем, а из TMS, например, то мы должны четко понимать, готовы ли мы идти на жертвы, ломая сложившуюся систему, даст ли новая система какие-либо плюсы во взаимодействии с контрагентами и не приведет ли к явному ухудшению качества.
Пример последнего. Компания Х имела свою WMS, которую частично открывала для подрядчиков, но склады имела исключительно на аутсорсе. То есть, Х посылает заявки на обработку, а аутсорс делает физические операции, залезает в WMS компании Х и делает проводки. Но встал вопрос – как будет выглядет эта заявка? Компании-поставщику складских услуг Л. удалось продавить хорошее ТЕХНИЧЕСКОЕ решение – в реальном времени заявки размещаются в некоторой форме броузерной версии WMS компании Л., эта версия синхронизируется с WMS компании Х., берет из нее состав заявок, после чего сотрудники подрядчика, закрывая заявки в своей WMS, вручную закрывают заявки в WMS заказчика. Звучит неплохо. С одной стороны – подрядчик имеет всегда задокументированный список заявок для обработки, к нему можно цеплять SLA, KPI, имеется выгрузка статистики для анализа. Заказчик ту же самую, уже структурированную информацию о физических статусах имеет в реальном времени, правда, как внешний источник.
Практика же показала следующее. Во-первых, компания-заказчик резко увеличила количество менеджеров по контролю и взаимодействию с подрядчиком, потому что внесение заявок через форму на сайте подрядчика требовало массу ручного труда. То, что можно было бы решить разовой отсылкой списка в 200-300 заявок по почте, выливалось в два дня напряженной и обезьяньей работы менеджера.
Для подрядчика – красота. Ни одной заявки не пропущено, каждой соответствует свое опорное время, нет переписок по размещению заявок. Но для заказчика полезли явно неочевидные до этого минусы. Во-первых, статусы проводки заявок в двух WMS систематически разнились. Много временеи жралось на выяснение фактического статуса. Во-вторых, с валом заявок нарастал временной гразрыв между получением информации о необходимом размещении менеджером и размещением заявки. При SLA в 1,5 суток на сбор заявки фактическое время от заявки в WMS заказчика до физического сбора вырастало до 2,5 суток. Потому что менеджер – не робот, и копипастом в форму не может заниматься 24/7. В-третьих, резко возросла необходимость синхронизации систем, которое осуществлялось через Эксель с массой ручного труда и кучей выгрузок.
А далее пошли уже чисто управленческие разговоры. У подрядчика было все хорошо, его все устраивало, заказчик же пытался продавить хотя бы заполнение мультизаявок из шаблона, за что подрядчик выкатывал сумму (за разработку его собственной системы, так мило). Многомесячные препирания, кофе на встречах выпито на астрономические суммы, такси озолотилось, перевозя туда-сюда на переговоры руководителей и неруководителей. Результатом стал отказ от хороших технических решений в пользу таблички в Экселе, высылаемой по почте по определенной форме с маской и установка на работе в WMS заказчика мимо всяких подрядных систем.
Риск пропуска или некорректности приема заявок по почте оказался менее затратен, чем хорошее техническое решение. По итогам были освобождены у заказчика половина менеджеров, которых перекинули на другие работы, у подрядчика операторы, как бы странно это не казалось, тоже разгрузились (потому что на одном конце обезьянкой менеджер заявки заводил в систему по одной, а на другом такой же обезьянкой оператор закрывал). Заявки высылались в течении нескольких минут после команды от проекта, и практически тут же начинались по ним шевеления. Статусы в WMS заказчика, наконец-то стали актуальными, и можно было без тонны схлопываний разных табличек проводить анализ по ним. Операторы подрядчика, наконец-то перестали бояться WMS заказчика и стали писать более понятные письма про проблемы с проводками. В целом качество сервиса серьезно улучшилось. При том что техническое решение стало так себе.
Но тут IT шник обязательно найдет аргумент – а как же возможности API, а как же встроенные B2B функции систем (был блок с функционалом, но под эти функции не годился), как же возможность доработки системы для мультизаявок, а как же....(сотня советов про общее облако)? Однако опять-таки, корпоративная среда и там, и там не позволяла реализовать ни одно техническое решение – что-то закрыла безопасность, что-то не смог реализовать подрядчик, что-то не прошло согласования по бюджетам. Технические решения, вытащенные из сферического вакуума, быстро чахли и дохли.
А что выжило? А выжили в этой суровой корпоративной среде Excel и Outlook. По ним просто не было никаких управленческих ограничений. Никому не надо было согласовывать принципиальную возможность отправки шаблонного списка по почте. Никому не надо было платить за разработку и доработку. Никто не писал из киберсекьюрити страшных писем о несанкционировании доступа подрядчиков в облако и наоборот, не грозил карами за перекидывание информации в облачный сервис подрядчика. Не надо было прогибать подряда на предоставление API. Ничего не надо было. Шли письма. Just do it.
Искусство возможного для офисного хомячка
Офисный хомячок, ака, конечный пользователь всех IT-систем, живет в мире очень жестких законов природы. Он маленький и беззащитный перед томами регламентов, инструкций, правил. Он не может достучаться до 90% лиц принимающих решения в корпоративной иерархии. А те, до кого удается достучаться, далеко не все готовы рассматривать всерьез его предложения. Потому пробегая снизу вверх инициатива на любое решение имеющихся у него проблем часто теряет свой импульс и глохнет на полпути. Его голос не слышан, даже если техническое решение, которое он предлагает, идеально. С его места даже не видно всего иерархического дерева, потому он часто просто кричит в никуда.
Увеличение количества хомячков тут помогает очень слабо. Например, долгое время я занимался тем, что интегрировал и анализировал ошибки, возникающие при работе с системами у отдела и эксалировал поддержку на исправление. И на каком-то этапе объем ошибок всех достал, и было принято решение не делать из нескольких типовых ошибок тикет, а каждому работнику слать свой тикет. Пусть будет много тикетов. На графике тикетов кривая резко рванула вверх, техподдержка в ужасе стала путаться в тикетах. Я, потирая ручки, пишу главарям поддержки системы объемное письмо с анализом и ужасающими графиками с требованиями оптимизации процессов, добавления и исключения функционала, улучшения алгоритма (отловил несколько явно некорректных обращений к записям). Подключаю регионального директора по логистике. Первая реакция – «we’ll feedback». Вторая – «all the tickets closed». А что с оптимизацией, ради которой хай и задумывался? А с оптимизацией ничего. На следующий месяц опять та же кривая и та же ситуация. И совершенно неясно, почему и куда идти дальше.
Со всех сторон на хомячка надвигаются стены – туда не ходи, там не делай. Это так делать нельзя, а так можно – видишь, вот тут написано. А за это тебя покарают (причем причина кары может быть совсем неочевидна). А туда ты точно не добежшь – до тебя уже сотня пыталась. Для него подавляющее большинство происходящего - это просто данность, на которое возможности повлиять никакой нет. Подрядчик шлет фигню, которую не можешь принять. Ок, не принимаешь. А начальник разводит руками "я сам под прессингом" и дает указание "принимать такое как-нибудь". В такой ситуации ежиком стать сложно, получается разве что раком.
Потому советовать офисному хомячку технически идеальное решение в ситуации, когда даже непосредственный руководитель не может его протолкнуть дальше себя, и нет возможности достучаться до небес – абсолютно бесполезное дело. Равно как и советы «увольняться из этой говноконторы». Если бы хомячок хотел увольняться, то он бы и не устраивался. Советовать имеет смысл только то, что хомячок сможет исполнить либо сам, либо совместно с такими же, или же хомячками уровня чуть выше омеги, в рамках доступных ему систем.
Что обычно доступно? Есть корпоративная ERP с правами на уровне его должности. То есть, никто ничего там исправлять или добавлять не даст. Есть офисные инструменты. Здесь попроще – например, с тем, что программная отправка писем закрыта на уровне админа, встретился только один раз. Некоторые конторы позволяют средства разработки. Бывает некоторые специфические программки самописные или под заказ. Кое в чем может помочь поддержка. И все.
Основные возможности сотрудника, как правило, сводятся к термину «колхоз-тюнинг». Таблички с кучей формул. Многостраничные таблички с формами на каждый чих. Скрипты в САП (где они открыты пользователю). Формы и шаблоны в Outlook,.Тысячи шаблонов в Word. Наизусть выученая первая тысяча строчек списка номенклатуры. Регламентация переписок под шаблоны. Подстраивание кастомных выгрузок из систем.
И, наконец – можно что-то десктопное написать под текущие нужды – либо самому, либо на стороне заказать. Возможности для колхоза практически всегда есть.
И если мы видим колхоз, то это не потому, что хомячок тупой и не понимает, что можно сделать. Это потому, что в компании есть некоторые управленческие проблемы с обратной связью, из-за которых стать ежиком, как ни крутись, все равно не получится.
Комментарии (33)
suslovas
19.07.2022 13:49+1Проблема с описанной системой не в том, что хорошие технические решения не приживаются, проблема в том, что техническое решение было плохим, бизнес-процесс не выстроен и в целом никто не был заинтересован в оптимизации процесса. Но практика показывает, что по итогу высокотехнологичные компании оказываются впереди, и выигрываю у тех, кто так и не продвинулся дальше Excel и Outlook.
А с "хомячками" другая проблема, в действительно больших компаниях такие сотрудники не владеют и 1% информации, но при этом склонны считать, что знают все лучше всех. Сам таким был. По этому идеи, которые они продвигают кажутся им идеальным, а реально могут вызвать только больше проблем. На предыдущем месте работы был "Банк идей", куда любой сотрудник мог прислать свою оптимизаторскую идею, и мне приходилось на некоторые из них писать отзыв. Так вот 99% этих идей реально бред сумасшедших. В основном они либо упрощают себе работу, не понимая, что усложняют работу десятку смежных отделов, либо нарушают законодательство и регламенты, либо требуют абсолютно неадекватных денежных вложений, которые не окупятся никогда.
IvanSTV Автор
19.07.2022 14:48+2Проблема с описанной системой не в том, что хорошие технические решения не приживаются, проблема в том, что техническое решение было плохим
Плохим конкретно для этой ситуации. а само по себе - неплохое. Одно и то же в разных обстоятельствах может быть различным. Диалектика, помнимаете ли.
Но практика показывает, что по итогу высокотехнологичные компании оказываются впереди, и выигрываю у тех, кто так и не продвинулся дальше Excel и Outlook.
По итогу высокотехнологические компании точно так же оказываются в жопе и бардаке, если не организована обратная связь c сотрудниками относительно систем. Такие компании берут общей массой и огромным колимчеством дешевой рабсилы. И эффективны они ТОЛЬКО И ИСКЛЮЧИТЕЛЬНО в монетаристских показателях - то есть, в денежном выражении. Производительность труда и организационные и административные потери дикие, закрывают только за счет сверх прибылей, берут человеческим мясом. К вопросу, одна из историй относится к Хуавею. Типичная история - вместо того, чтобы автоматизировать создание актов приемки работ в Хуавее наняли 20 инвалидов. Два месяца колупались - делали то, что программа делает за 5 минут, потому что не захотели прикручивать к системе формы для локального подразделения. И так почти везде.
По этому идеи, которые они продвигают кажутся им идеальным, а реально могут вызвать только больше проблем.
Я правильно вас понял, что вы воспеваете управленчески организованную невозможность оптимизировать работу для линейных сотрудников, а негибкость, зарегламентированность и полнейшее невнимание к оптимизации процессов со стороны корпораций считаете идеалом?
Но это же не снимает проблему. Если человек считает, что "так было бы проще", в 90% случаев оно действительно так. Вы, наверное, очень давно не сидели на рядовых должностях. Когда ты раз-два сталкиваешься с процессом, может, и рождаются завиральные идеи, а когда сидишь на этом процессе по полгода-год, то не понимать, что происходит, в принципе нельзя. И такой сигнал игнорировать только потому, что человек не видит общей картины, не сильно умно. Боль ниоткуда не берется, она имеет источник.
Конкретно касаясь IT систем - системы как раз то, что проще изменить, чем регламенты, но с одним условием - если это происходит не со стороны рядового сотрудника. Однако без хомячка этого просто не видно.. Вот есть, например, процесс - накладные на перемещение заводят ручками. Берут из справочника в системе построчкно артикул, вбивают ручками количество, кнопка "OK". Расскажите мне, какие смежные процессы повредятся, если этот процесс сделать загружаемым через табличный шаблон - например, из того же Экселя? А этого крупная европейская компания не сделала до сих пор, хотя стонут все операторы по всему миру. Почему? Потому что в корпорациях начальники этих проблем не решают. Набрали операторов, загрузили их на 146%, все хорошо. А то, что оператор на неделю вперед загружен обезьяньей работой и для сформирования по заказу накладной несколько дней ждать приходится и убивается время на проверки статусов и подпинывание операторов с выстроением системы приоритетов - всем насрать.
требуют абсолютно неадекватных денежных вложений, которые не окупятся никогда.
Относительно неокупаемых решений - они если не окупаются, то только на коротком плече. А на длинном окупаются, но в длинную корпоративные начальники не играют, так как их отчетность в лучшем случае поквартальная, и вообще плечо планирования небольшое на всех уровнях. И в таком случае хомячок действительно может видеть дальше, чем топы.
suslovas
19.07.2022 15:29+3Плохим конкретно для этой ситуации. а само по себе - неплохое. Одно и то же в разных обстоятельствах может быть различным. Диалектика, помнимаете ли.
Оставьте диалектику философам, здесь и сейчас оно плохое так как не выполняет ту задачу, ради которой внедрялось.
И эффективны они ТОЛЬКО И ИСКЛЮЧИТЕЛЬНО в монетаристских показателях - то есть, в денежном выражении.
Здрасьте - приехали. Если это коммерческая компания, то какие еще у нее могут быть показатели? Смысл ее существование - заработать денег. Если для компании финансово выгоднее нанять 20 инвалидов и завалить их мартышкиным трудом, чем внедрять автоматизацию, она так и сделает.
Я правильно вас понял, что вы воспеваете управленчески организованную невозможность оптимизировать работу для линейных сотрудников, а негибкость, зарегламентированность и полнейшее невнимание к оптимизации процессов со стороны корпораций считаете идеалом?
Нет, не правильно. Вы занимаетесь софистикой. Я сказал то, что чем ниже позиция человека, тем меньше у него реальной информации и понимание процессов. Обратную связь собирают в форме опросов и статистики. А так, я уже говорил, что все эти идеи по оптимизации труда снизу в 99% случае приводят к тому, что где-то становится сильно не оптимально по соседству, но линейного сотрудника это не колышет, главное, что у него стало меньше работы, а вот руководству приходится смотреть шире.
Расскажите мне, какие смежные процессы повредятся, если этот процесс сделать загружаемым через табличный шаблон - например, из того же Экселя?
Удобно просить проанализировать ситуацию о которой оппонент ничего не знает, можно потом его дураком выставить, да?) Что за табличный шаблон? Куда загружаем? Как загружаем? В целом проблем там может вырасти гора, начиная с того, кто будет поддерживать актуальное состояние этого шаблона и справочника в нем, и как разруливать некорректно введённые данные.
А может быть и другая проблема, люди, особенно на линейных должностях почему-то думают, что если они сейчас оптимизируют свою работу то сразу работать станет легче и полдня можно будет плевать в потолок. Неа, так это не работает. Если за счет оптимизации процесса удастся сократить трудозатраты на 20-30% то просто сократят 20-30% персонала а их работу раздадут оставшимся, посмотрите хотя бы на зеленый банк. По этому этой толпе операторов надо быть благодарными, что их не заменили автоматизацией, иначе их просто уволили бы. И это кстати одна из причин, почему во многих организациях "Социальной" направленности так плохо с автоматизацией. Мой бывший тесть мне рассказывал, как по молодости прибежал к своему начальнику с предложением, как можно оптимизировать работу бухгалтерии, на что начальник ему сказал, что ок, не вопрос, только он сам пойдет говорить тем бухгалтерам, которые сидят в соседней комнате и у которых дома семья с детьми, которых надо кормить, что они уволены. А если он не готов к этому, то пусть эту идею уберет подальше и не вспоминает о ней. Так и убрал. Так что подумайте, кого вы своей оптимизацией лишите работы..)
Относительно неокупаемых решений - они если не окупаются, то только на коротком плече. А на длинном окупаются, но в длинную корпоративные начальники не играют, так как их отчетность в лучшем случае поквартальная, и вообще плечо планирования небольшое на всех уровнях. И в таком случае хомячок действительно может видеть дальше, чем топы.
Они не окупаются за свой срок жизни, через 3-5 лет процессы придется снова менять, снова вкладывать деньги и если за 3-5 лет эта идея не окупилась, она уже никогда не окупится.
IvanSTV Автор
19.07.2022 19:06Вот благодаря тому, что диалектика оставлена философам, и получается, что вы за деревьями не видите леса. Вместо настройки систем и регламентов под изменчющиеся условия вы предлагаете массивной корплративной тушей проламываться на тягловой силе грубого и тупого человеческого труда.
Вы совершенно неверно считаете, что обратная связь получается опросом и статистикой. Формы обратной связи исключительно многооьразны, и названные вами формы лишь капля в море А статистика вообще не панацея - управление по цифрам сотни раз критиковано из-за того, что цифры осмыслить можно исключительно в контексте погружения в процессы. Одна и та же цифра в разном контексте вообще значит разное. Например, увеличение на стоке материалов с просроченные сроком годности может отражать как спад продаж, так и просчёт планирования, и задержки логистики, и отсутствие на складе WMS, и технологические измене ия в продукте, и ещё с десяток вариантов, вплоть.до декретногл отпуска ответственного за утилизацию. Опрос тоже имеет недостатки, ибо отвечают только то, что спрашивают. Попытки рулить, не слушая низового сотрудника - это для руководителя верный способ засадить себя в лужу.
И что же, вы такой большой специалист, и не осведомлёны о практике создания документов в ERP-системам с помощью табличеых шаблонов? Возьмите, например, 1С, или САП, неважно. Документ в ERP-системах-это просто запись в БДшке. Есть ли разница, оператор через GUU создаёт эту запись, или система считывает шаблон, где столбцы - поля? Разницы фактически нет при корректной обработке шаблона. Или вы специально пытаетесь увиливать от решенияв общем виде вопросов, чтобы утопить их в мелочах?
suslovas
19.07.2022 21:21+2Решение в общем виде не имеет никакой ценности, потому что в мелочах и кроется дьявол. Вы в другой своей статье уже рассказывали про опыт автоматизации табличек. Удачно вышло? А все из-за деталей. если вы заполняете форму не через специальную систему, которая валидирует поля и следит, что бы вы чуши не написали, а руками в эксель, то где гарантии, что вам не пришлют дату прописью, сумму в валюте и прочие приколы. Мало шаблон корректно обработать, его надо корректно составить и заполнить, проблемы, как правило уже на этом этапе.
Если вы хотите гибкости и легкости - вам в стартап. Когда в компании несколько тысяч или десятков тысяч сотрудников по всему земному шарику там уже не до гибкости. Регламенты и жесткие рамки, где каждый занимается своим делом, аналитики и энтерпрайз архитекторы занимаются оптимизацией процессов, а кладовщик принимает и раскладывает товар на складе и никак не наоборот, иначе все будет похоронено в хаосе.
Вы не очень понимаете видимо как используется статистика. Увеличение на стоке материалов с просроченным сроком годности отражает только увеличение на стоке материалов с просроченным сроком годности. Эта девиация является маркером, что что-то идет не так, есть критическое отклонение от нормальных показателей и дальше уже будет расследование. почему это произошло и где узкое горлышко.
Вместо настройки систем и регламентов под изменчющиеся условия вы предлагаете массивной корплративной тушей проламываться на тягловой силе грубого и тупого человеческого труда.
Я ничего не предлагаю, я лишь констатирую факт, что пока проламывать тупым человеческим трудом для корпораций будет дешевле, чем оптимизировать мелочи - они будут использовать тупой человеческий труд.
IvanSTV Автор
19.07.2022 21:34"... кто берется за частные вопросы без предварительного решения общих, тот неминуемо будет на каждом шагу бессознательно для себя «натыкаться» на эти общие вопросы"
Вообще, в ваших комментариях отчётливо читается "я начальник, ты дурак". Считаете подчиненных глупей себя? Ну-ну, ждите сюрпризов
suslovas
19.07.2022 21:44+1А у меня нет подчинённых. Представляете? ) Я поработал два года начальником и уволился, не нравится мне это занятие, предпочитаю быть техническим специалистом, чем мастером отчетов и совещаний.
Какой общий вопрос надо решить? Вы сами накидываете частных примеров, и требуете на них общие решения. Это так не работает. Я лишь говорю, что крупные корпорации не могут позволить себе выслушивать каждого грузчика с его бесценными советами, у них для этого есть штат специально обученных специалистов, которые могут принимать не всегда макисмально оптимальные решения но в целом по палате выдавать приемлемые результат для существования компании. А вот выслушивать и реализовывать бесценные предложения каждого младшего сотрудника просто не хватит времени. Предположим у вас в компании 10 000 сотрудников. У 10% из них каждый месяц появляется безумно важное рац.предложение, которое он излагает 10 минут. Что бы всех их выслушать уже необходимо 20 человекодней в месяц. То есть вам надо взять как минимум одного человека, который месяц будет работать просто ушами, даже не имея возможности оценить и уж тем более реализовать это предложение. Последующие шаги увеличивают этот штат еще больше.
IvanSTV Автор
20.07.2022 10:44+1Какой общий вопрос надо решить? Вы сами накидываете частных примеров, и требуете на них общие решения.
Сорри за переход на личности, но имхо, вот потому из вас начальника не получилось. что за частными проблемами вы не видитек общих :)
Я лишь говорю, что крупные корпорации не могут позволить себе выслушивать каждого грузчика с его бесценными советами, у них для этого есть штат специально обученных специалистов, которые могут принимать не всегда макисмально оптимальные решения но в целом по палате выдавать приемлемые результат для существования компании.
Не надо передергивать, речь идет не о выслушивании грузчиков (хотя умение послушать грузчика для процессов неплохо. Например, вот буквально вчера по жалобам грузчиков принято решение менять форму сборочного листа - оказывается, форма без данных о характере упаковки товара увеличивает время на сборку).
Обычно оптимизации предлагают специалисты. с образованием и опытом ничуть не хуже ваших "специально выделенных людей". И более глубоко понимающие процессы. Не выслушать, например, сток-менеджера своего подрядчика даже я, занимаясь стоками параллельно с ним и частично дублируя, себе позволить не мог. Потому что понимал, что в одиночку всех процессов и нюансов просто не сумею отследить, особенно в физической реализации.
И ваш безудержный оптимизм про сам факт существоания "штата специально обученных специалистов" по оптимизации - он, собственно, на чем основан? Я вот сколько работал в крупных организациях, ну ни разу не видел таких. Обычно вообще системы никакой в этом нет, и хорошо, если находятся случайные люди, которых можно чем-то озаботиь. Про оптимизацию системы. например, я писал человеку, ответственному за внедрение WMS, а больше некому было писать. Иногда эта девочка, которая обычно проводила, по-факту обучение настройке системы, будучи в хорошем настроении, после заваливания ее смайликами и котейками с "kind reminder", писала тикеты разработчикам под соусом исправления ошибок.
У 10% из них каждый месяц появляется безумно важное рац.предложение \
Если ситуация такова, что у 10% сотрудников каждый месяц появляется рацпредложение, то это значит, что В КОМПАНИИ БАРДАК и регламенты и системы не соответствуют физическим процессам.
suslovas
20.07.2022 11:00Сорри за переход на личности, но имхо, вот потому из вас начальника не получилось. что за частными проблемами вы не видитек общих :)
НУ так то очень даже получился, отпускать меня не хотели. но мне самому это не интересно. Вы демагог знатный. Я уже который комментарий подряд жду этот общий вопрос, который вы тут анонсируете, но никак не зададите.
Обычно оптимизации предлагают специалисты. с образованием и опытом ничуть не хуже ваших "специально выделенных людей". И более глубоко понимающие процессы.
Само собой на этапе построения или оптимизации процесса должна быть рабочая группа в которую входят и специалисты предметной области, но пять такие оббежать всех соответствующих специалистов нереально, это все равно будут отдельно назначенные люди.
И мой оптимизм основан на том, как это должно работать. То, что это не везде выстроено - другого рода проблема. Мне кажется мы все таки говорим о разного масштаба компаниях. Предположим мы приняли рацпредложение, и внесли изменение в какой-то регламент. Теперь этот новый регламент надо растиражировать по всем отделениям и филиалам по всей стране, или миру, обучить людей, что бы они изменили свой привычный ритм работы на новый, убедиться, что по дороге мы не сломали другие регламенты, что у нас нигде ничего не поплыло в системах. Проверить, что все работает и все это ради того, что бы кладовщик в нижнем урюпинске на 10% быстрее заполнял одну бумажку. И потом вы мне еще говорите. что это я за частным не вижу общего? Больше похоже, что это вы за локальным решением не видите глобальных последствий.
Если ситуация такова, что у 10% сотрудников каждый месяц появляется рацпредложение, то это значит, что В КОМПАНИИ БАРДАК и регламенты и системы не соответствуют физическим процессам.
Не. Это обычная история, которая еще в старые времена характеризовалась фразой "каждый суслик - агроном".
IvanSTV Автор
20.07.2022 16:51Я уже который комментарий подряд жду этот общий вопрос, который вы тут анонсируете, но никак не зададите.
Специалист должен видеть за частными проблемами общие, или нет? Вы на это ответьте? Если в процессе работы возникают частные вопросы, то они истекают из каких-то общих, или не так? Или частные ворпосы с общими никак не связаны?
В нашем случае вы согласны, что частные проблемы есть отражение некорректности общей организации работы - а конкретней, регламентов и систем - или нет? Если вы будете настаивать на том, что частные вопросы рождаются вне общих из воздуха, то в таком случае с таким "управленцем" обсуждать вообще нечего. Я бы начальника, будь у него такой подход, просто послал бы. .
Не. Это обычная история, которая еще в старые времена характеризовалась фразой "каждый суслик - агроном".
Ага, и после этого вы имеете некоторое нахальство отрицать подход "я начальник-ты дурак"... :)
Вы хотьь опнимаете, что корпорации берут свой профит ИСКЛЮЧИТЕЛЬНО размерами и огромным количеством грубого и неоптимального живого труда, а вовсе не квалификацией и компетенциями управления, особенно топов и среднего звена? Компетенции и квалификация там очень средние, и даже ниже среднего, особенно в госструктурах, где купленных дипломов у начальников овердофига. Мне не приходилось наблюдать руководителей, изображавших что-то больше, чем мог любой другой. Начальник считася крутым если... попросту добросовестно выполнял свою работу. Но как раз таких в корпорациях как бы не меньшинство. Потому что плох начальник или хорош - толпа хомячков вытащит его из любой задницы, практика, когда управленческие про...ы в организации закрываются хреновой тучей неоплаченных переработок линейных сотрудников, очень обычна. И настолько обычно, что вам с вашей колокольни ее может быть и не заметно.
Само собой на этапе построения или оптимизации процесса должна быть рабочая группа в которую входят и специалисты предметной области, но пять такие оббежать всех соответствующих специалистов нереально, это все равно будут отдельно назначенные люди.
Еще раз повторяю - у вас очень радужные представления об организации оптимизаций в корпорациях. Обычно никто оптимизациями регулярно не занимается от слова "совсем", а всплески активности на эту тему быстро гаснут, потому что эти обязанности кладутся на случайных людей, и обычно это малокомпетентные начальники, которых более некуда спихнуть.
Проверить, что все работает и все это ради того, что бы кладовщик в нижнем урюпинске на 10% быстрее заполнял одну бумажку.
Да конечно, давайте сказки не рассказывать, если такие глобальные изменения, то они коснутся не одного кладовщика, а всех складов сразу, а на каждом складе кладовщиков не один, и не два, а три смены, и взаимодействуют с этим кладовщиком по поводу этой бумажки еще с пяток человек из офиса. На круг получается немало, вообще-то. 10% от одной бумажки, а бумажек, например, сотня, а то и не одна... в день. Потому что ни один суслик не будет ради редкой бумажки трудиться составлять вам заявку на оптимизацию. Тут 10% закрыли, там 10% закрыли. Я вон как-то приспособил для печати этикеток напрямую из системы старые зебровские принтеры, которые пытились у подрядчика и ждали списания - и вместо 18 мобильных принтеров потребность снизилась до 12. А каждый мобильный принтер - это 1500 долларов. Плюс потери живого труда из-за того, что кладовщик не бегает расклеивает и отпикивает приему, а отлавливает мобильный принтер или бегает его заряжать. И все потому, что кладовщики пожаловались, что задолбались приемки печатать на мобильных принтерах - долго, принтер разряжается, и вообще его сначала еще надо найти, потому что все мобильные принтеры "в поле". Но это повезло, что формат этикеток совпал. А если бы нет - то я бы бился, как муха о стекло с просьбой сделать настраиваемый сохраняемый формат и открыть прямой порт. А если бы еще закупать стационарные принтеры - я бы эту стену вообще никогда не пробил, потому что какой-то умник посчитал бы, что "за три года не окупится".
suslovas
20.07.2022 17:28Специалист должен видеть за частными проблемами общие, или нет? Вы на это ответьте? Если в процессе работы возникают частные вопросы, то они истекают из каких-то общих, или не так? Или частные ворпосы с общими никак не связаны?
В нашем случае вы согласны, что частные проблемы есть отражение некорректности общей организации работы - а конкретней, регламентов и систем - или нет? Если вы будете настаивать на том, что частные вопросы рождаются вне общих из воздуха, то в таком случае с таким "управленцем" обсуждать вообще нечего. Я бы начальника, будь у него такой подход, просто послал бы. .
Вот за это вас, гуманитариев, и не любят. В двух абзацах воды хватило бы на то, что бы напоить деревню в Африке. А по факту то какую проблему решаем? Если вам кажется, что что-то работает некорректно, то не факт, что это работает некорректно, возможно вы просто не знаете всего.
Ага, и после этого вы имеете некоторое нахальство отрицать подход "я начальник-ты дурак"... :)
Так я и не начальник. Я отрицаю другой подход "Любая кухарка может управлять государством." ВЫ тут топите за общий подход, а сами скатываетесь в частные примеры. Госструктуры неоптимальны, это факт, но там другая система. Есть огромное количество громадных трансконтинентальных компаний, в которых регламенты такие, что госструктуры позавидуют их строгости. ВЫ их почему-то в расчет не берете. возможно просто никогда их не видели изнутри.
Еще раз повторяю - у вас очень радужные представления об организации оптимизаций в корпорациях. Обычно никто оптимизациями регулярно не занимается от слова "совсем", а всплески активности на эту тему быстро гаснут, потому что эти обязанности кладутся на случайных людей, и обычно это малокомпетентные начальники, которых более некуда спихнуть.
Туда же, вы скатываетесь в частные примеры, которые видели сами в нишевых госструктурах, я говорю о действительно крупных мировых компаниях с выстроенными процессами.
Ну и на самом деле во многих компаниях крупных есть специальные формы обратной связи, где можно описать свою идею. Только, как правило, они требуют какой-никакой проработки от заявителя и указания при подаче ожидаемого бизнес-импакта. За хорошую окупившуюся идею можно даже очень неплохую премию получить. я знаю случай, когда на такую премию квартиру в Москве купили. Но таких идей одна на десятилетие, а ящик ломится от писем. По этому я и говорю, что проблема в том, что чаще всего идеи переоцениваются авторами, потому что нет понимания реального влияния на процесс. Внедрили мы систему, которая сэкономит 10% времени кладовщику. Зарплата кладовщика допустим 30 000 в месяц, таких кладовщиков у нас пусть 200 по стране, итого получается 600 000 экономии в месяц. НА разработку этой системы, я оговорюсь, на нормальную промышленную разработку. а не колхоз вечером под пивко, нужна команда из двух разработчиков. тестировщика, аналитика и руководителя проекта. В среднем у каждого из них зарплата 200 000 в месяц. У кого-то больше, у кого-то меньше, но средняя на команду будет такая. И того получаем, что на разработку и поддержание этой системы надо 1 000 000 в месяц при экономии в 600 000. Бизнес импакт от идеи -400 000 в месяц, не говоря о затратах на железо, на котором эта система будет работать. Я не думаю. что кладовщик вел подобные расчеты. Вот когда выгода от внедрения системы ощутимо превысит стоимость владения системой - тогда и можно вести речь.
SerjV
20.07.2022 17:52Туда же, вы скатываетесь в частные примеры, которые видели сами в нишевых госструктурах, я говорю о действительно крупных мировых компаниях с выстроенными процессами.
Я бы сказал, что автор-то как раз и хочет сказать, что происходящее - оно не просто так и какой-то смысл в этом есть, просто не всегда понятное техническому подразделению. Просто от статьи возникло впечатление в духе "прикинь, мужики, а в конторе-то за пределами технического подразделения тоже жизнь есть!"
А вот что еще имеется ситуация "обобщения частного случая" - и что на самом деле не все корпорации закостенели в своей работе, и что там вполне могут существовать процессы по улучшению существующих процессов (если я вас правильно понял) - это тоже правильное замечание.
Antra
19.07.2022 21:10Если говорить о решении, где от формочек откатились на Excel через Outlook, в чем его техническая продвинутость?
Коль скоро уже есть данные (в том же Excel), почему не взять именно их? А дальше хоть на стороне закачика поставить свой скрипт, который из Excel в формочки перегонит (что там, несколько POST запросов отправить?), хоть пусть он свои Excel так и присылает по почте, а подрядчик у себя их парсит и в свою волшебную систему кладет.
Но в сделать удобно для себя, наплевам на клиента (который, насколько я понимаю, приносит деньги) - мне это напоминает не столько красивое техническое решение, сколько советскую сферу обслуживания, где клиент работать мешает.
suslovas
19.07.2022 21:36Есть гарантия нормализованности данных, присланных в Excel? Если нет (а их нет), то кто будет нести ответственность за неверно выгруженные данные? Отсюда и проблемы.
IvanSTV Автор
19.07.2022 22:05Они абсолютно такие же, как и внесение ручками в WMS. И таблицы, и формы заполняют (внезапно) люди
Antra
19.07.2022 22:09А когда сейчас присылают тот самый Excel с "неверными данными" - это ведь как решается? Например, при невозможности распознать поле отправляется письмо с уточняющим вопросом.
IvanSTV Автор
19.07.2022 21:42В корпоративных реалиях не срабатывают наипростейшие решения. Ну, и голый монетаризм. Заказчик - это только 10% складов, ради этого деньги на разработку не выделили, сказали снять с заказчика. Заказчик тоже не дурак и платить за развитие чужих инструментов не собирается. А грузы идут и идут, пока выясняют, чьё же кунг-фу сильнее.
Чем крупней бизнес, тем сложней менять подрядчиков, особенно генеральных, и это все знают, и лучше всех сам подрядчик.
Antra
19.07.2022 22:19В корпоративном бизнесе для запуска проекта и получения денег на него нужно доказать его необходимость, пользу (экономия, прибыль, окупаемость, вот это вот все).
Здесь же складывается впечатление, что подрядчик просто упростил себе жизнь, переложив затраты на клиента. Точнее просто о клиенте не думал. Так бывает. Особенно если договоренности о взаимоотношениях достигнуты "наверху".
Мой пассаж - скорее личное. С трудом могу назвать "красивым" решение, создаваемое без учета интересов его пользователей.
IvanSTV Автор
19.07.2022 22:58То, что затраты переложены на клиента-это в бизнесе норма, а не исключение.
Antra
20.07.2022 08:59Вопрос не в том, кто в конечном итоге платит, а учитывалось ли это.
Если ИТшники при проектировании предусмотрели недовольство клиента, а бизнес все равно дал добро - вопросов нет, с точки зрения ИТ решение красивое, а бизнес подрядчика лажанулся. Иначе же
С трудом могу назвать "красивым" решение, создаваемое без учета интересов его пользователей.
IvanSTV Автор
20.07.2022 09:13Целый ряд компаний клиента в задницу отнюдь не целуют, а строят, как старшина новобранцев. Например, "Деловые линии" для изменения только одного пункта - а конкретней, вопроса о процедуре уничтожении невостребованных отправлений, требовали гарантий многомиллионных объемов и платить им за воздух (то есть, просто ежемесячно платить им некоторую сумму вне зависимости от того, дотянули объемы отправок до нее или нет).
Недовольство клиента, когда уже договор есть и спрыгнуть с него не так просто (у клиента свои клиенты и обязательства перед ними), почти всегда закладывается. Вопрос в том, кто со стороны клиента будет недоволен. Если недоволен будет директор департамента саплай чейн - это одно, если главный менеджер по логистике - другое, если пойти на ступень ниже - начальник подразделения складской логистики, то третье. И, наконец, недовольство простых и ведущих манагеров вообще никак можно не учитывать - им надо сначала пробиться на некоторый уровень, чтобы подрядчик это недовольство просто заметил.
Я, к вопросу, многократно писал на различные уровни подрядчиков различные письма с анализом проблем и требованиями исправить. Встречался с гендиректорами. Обычно, когда подрядчик понимает, что лицо принимает очень ограниченные решения, то вообще не церемонится. Все разговоры скатывались на то, что "вы сами не выполняете договора по процедуре подаче заявок". И так полтора года, пока подрядчик просто перестал вытягивать объем чисто по валу.
Antra
20.07.2022 09:39Да, вы весьма жизненные ситуации описываете.
И, если при проектировании предусматривалось недовольство "простых и ведущих манагеров" и было принято решение его не учитывать - вопросов к разработчикам нет. Ничего против назвать такое решение технически красивым не имею.
IvanSTV Автор
20.07.2022 10:12Рядового пользователя никто не принимает в расчет в принципе.
На предыдущей работе делал табличку для поддержки WMS: операция - количество кликов в системе - количество реально информативных кликов. То есть, убрав лишние менюшки и комбобоксы, перенеся часть вводимых данных в настройки пользователя по умолчанию с автозаполнением (оставив возможность редактирования), перенеся часть операций в загрузку шаблонами, компания экономила почти 50% ручного труда по работе в системах и до 20% общего времени линейного персонала. Это был первый раз, когда я в штаб-квартиру писал экономическое обоснование доработки систем. Через год перешили на новую систему - ничего во внимание не приняли, по некоторым пунктам количество кликов не только не уменьшилось, но увеличилось. Потому что ТЗ разработчику никто дополнять, исправлять и редактировать не стал.
У руководства компаний вообще нет общего понимания, что мелкие технические вопросы есть проблема общая, так как жрут живой труд в значительных масштабах,
RusGar
19.07.2022 17:45+1Интересная статья, спасибо!
Её прочтение вызвало у меня несколько вопросов.
Кто виноват и что делать? И кому на Руси жить хорошо?Возможно, следует поднять статус CIO до первого зама Гендира? Второй чисто технический: "Раз такое дело, сшить все с помощью RPA?"SerjV
20.07.2022 02:05+3У меня тоже есть вопросы, но другие...
Во втором кейсе, про склад у аутсорсера Л. - а куда смотрел бизнес-аналитик перед внедрением этой системы?.. Или его вообще пригласить забыли, сразу перепрыгнули к этапу автоматизации? Если "забыли" или пуще того, на нём "сэкономили" - хорошо что всего лишь увеличением числа обезьянок отделались, могло быть и хуже.
В первом кейсе, про голландцев - в бОльшей части идёт рассказ про недоучёт рисков при внедрении системы, как это связано с проблемами "технического мышления" - непонятно. Хотя концовка "Ну да, сократили время оператору на выбор из заказа в накладные. Но контроля на входе\выходе это не заменило" - опять заставляет задуматься, делался ли там бизнес-анализ вообще, или решили "внедрить волшебную систему, которая чудесным образом решит все наши проблемы, включая те, о которых мы еще даже не подозреваем"? Впрочем, возможно, и недоучёт рисков произошел по той же причине - к внедрению не привлекли бизнес-аналитика?..
IvanSTV Автор
20.07.2022 08:51а куда смотрел бизнес-аналитик перед внедрением этой системы?.. Или его вообще пригласить забыли, сразу перепрыгнули к этапу автоматизации?
А кто слушает бизнес-аналитика? И вообще, все такие вещи - голый монетаризм. Все доводы глушатся вопросами цены вопроса для текущих бюджетов, без учета перспективы. Компания разыграла рамочный тендер на комплекс услуг, выиграли три компании, с ними позаключали договоры. Все, больше у региональной логистики нет возможностей для маневра. Теперь идет большой проект, нужен склад. компания А не имеет свободных площадей, у B дешевле транспорт, но склад дорогой, и есть С, которая может и по цене проходит в проект. Но в раме нигде не написано, как осуществляется заявка. И тут могут выкручивать руки. Это везде и рядом. А если в игре еще и откаты (а они есть практически всегда, потому что любой корпоративный чиновник стремится намыть бабла побыстрей, ибо "кавалергарда век недолог"), то плохо проработанные решения и выкручивание рук - норма.
делался ли там бизнес-анализ вообще
Не все компании фетишизируют "бизнес-анализ". Но в том конкретном случае ориентировались на опыт работы голландского и немецкого подразделений, у которых все нормально взлетало. Другое дело,что Россия с внедрением опоздала, и техническое решение пошло на новый виток, со своими детскими болезнями, и все скрытые корпоративные болячки с управлением вылезли.
Техническое мышление тут при том, что решение в такой ситуации имеется только техническое и в абстракции, а на практике его нет в принципе.
suslovas
20.07.2022 10:30+1Не все компании фетишизируют "бизнес-анализ".
Что значит "фетишизирует". Бизнес-анализ - это не фетиш и не религия, это нормальный процесс сбора и формализации требований и построения бизнес-процесса. Если его не было, а процесс зародился как-то тяп-ляп, то и не надо удивляться. что все пошло по одному месту. Как говорится без ТЗ результат ХЗ. И то, что вы тут описываете к техническим решениям отношения не имеет, это как раз таки исключительно административные и юридические решения. Техническими они станут, когда к аналитику придут и скажут "У нас есть система с такими-то интерфейсами, подключитесь к ней, что бы данные забирать или передавать". НУ или хотя бы "Давайте интегрируем наши системы". А пока у вас даже общение и договорные отношения с заказчиком не построены, о технике и речи не идет.
SerjV
20.07.2022 12:08Бизнес-анализ - это не фетиш и не религия, это нормальный процесс сбора и формализации требований и построения бизнес-процесса.
Ну если сертификат по СМК получен "для галочки и участия в конкурсах", как и профильные дипломы об образовании сотрудников на некоторых должностях, а так "мы и сами знаем, как работать" - то логично, что менеджмент не понимает, зачем нужен бизнес-анализ и считает его "фетишем" и "способом развести себя на деньги" и рождает идеи "а давайте купим волшебную программу ХХХ и она чудесным образом решит нам все проблемы, включая те, о которых мы и сами еще не знаем?".
SerjV
20.07.2022 12:01+1А кто слушает бизнес-аналитика?
Ну а тогда техническая часть тут вообще не причём, проблема прежде всего в менеджменте.
Техническое мышление тут при том, что решение в такой ситуации имеется только техническое и в абстракции, а на практике его нет в принципе.
Вот не соглашусь... Пока что вижу проблему другого плана:
- "технической" службе подавай конкретное ТЗ, успех её работы оценивается качеством исполнения по этому ТЗ;
- а вот с точки зрения бизнес-заказчика важно не исполнение ТЗ, а фактический экономический эффект от внедрения. Который может оказаться и отрицательным несмотря на 100%-е исполнение ТЗ.
- решение проблемы находится не в зоне компетенции технической службы, если, конечно, она не какой-нибудь "бизнес-опс" и совмещает в себе техническое исполнение и бизнес-анализ. Да и то - даже "бизнес-опс" не в состоянии решить проблему полностью без участия менеджмента: потому что в общем случае нельзя "автоматизировать и забыть", процесс улучшения в организации должен быть постоянно действующим (про что недвусмысленно говорит СМК).Потому техническое решение есть, но когда бизнес с технической частью пытается договориться напрямую "без переводчика с бизнесового на технический и обратно" - получается фигня хотя бы потому, что стороны друг друга не понимают.
Да, "технарям" не вредно лишний раз напомнить, что для не-ИТ бизнеса - ИТ это "расходная", а не доходная часть, потому в идеале бизнес вообще на ИТ не хочет тратиться, но это уже немного другая история.
0mogol0
знакомая картина...
по моему опыту чаще всего такая "попаболь" "да здесь здесь же всё можно в три строчки написать!" встречается у
разработчиковайтишников, которые пришли во взрослый как в плане возраста, так и техпроцессов, холдинг / концерн, из небольшой конторы или стартапа, где всё решалось на основе устных договорённостей между начальниками, и максимум подтверждалось в сообщениями в мессенджер (имейл).Другое дело, что как правильно отмечено, крупная контора - похожа на организм человека, и поменяв один маленький белок отвечающий за цвет глаз можно обнаружить, что одновременно стала отваливаться жопа при сочетании каких-то факторов.
Поэтому для выживания концерна лучше оказывается действовать в рамках довольно жёстких регламентов, которые с одной стороны снижают гибкость, с другой образуют скелет, который может нести всю эту огромную контору. А регламенты - они не только запирают нашего хомячка, они так же обепечивают ему защиту, если что-то пойдёт не так (или просто не дают возможности пойти не так).
IvanSTV Автор
На каком-то этапе развития регламенты действитеьно не дают возможности не туда пойти, но когда процесс или внешние условия меняются хоть чуточку, они только запирают.
Типично - пришел новый клиент со своими требованиями. И все, процесс встал, потому что подстроить под требования клиента ничего невозможно, все закрыто. Начинается колхоз. Прибегают "специалисты" по ERP, видят колхоз, давай в голос кричать. что "Это ж колхоз!" А что, есть какие-то варианты?
Вот с утра обсуждал возможность написать ПО для терминала, чтобы вываливал содержимое упаковок на экран по штрихкоду партии. Такая вещь нужна - потому что систематически идет пересорт, а менять техпроцессы на заводе тоже возможности нет (завод у поставщика не один). Полгода писали во все инстанции, чтобы маркировку поменяли - два артикула под одной маркировкой идут, причем часто в одной партии, т.е. на входе определяется только полным вскрытием, пересорт, куча возвратов, куча переупаковок, потери живого труда охренительны. Но так как живой труд за фиксированную сумму, никто не парится. Заказать разработку возможности нет, просто не одобрят локальную разработку с доступом к корпоративной сети, заявка внутри компании на оптимизацию утонула еще в декабре, и не выплывет. Выход - самому колхозить. Это что, сильно радует кого?
0mogol0
ну тут могут быть (гипотетические, как минимум) вопросы... например, если новый клиент не укладывается в имеющиеся стандарты, то стоит десять раз подумать, а стоит ли с ним возиться, если на улице ждёт ещё полста? Потому что, прежний процесс отсмотрели юрист, бухгалтер, экономист, внесли свои замечания, и теперь у концерна есть надежда, что налоговая к ним не прикопается. Колхоз - может означать, что где-то что-то срезали для простоты взаимодействия (вероятно сами о том не подозревая), в итоге после визита налоговой может оказаться, что вся прибыль что принёс новый клиент - съедена штрафом.
Повторюсь, может и обойдется, но может и не повезёт. Как в авиации - пилот забыл включить реверс, выпустить закрылки - и здравствуй авария, это может случаться во время одного рейса из ста тысяч, но теперь всех пилотов заставляют проходить по "бумажке" чеклисту, чтобы проверить, что ничего не забыли. В 99,9(9)% - это потерянное время, но в одном случае люди остаются живы.
Более того, допускаю так же ситуацию, когда "колхоз" проверят все необходимые стороны и скажут, что "ок, так можно", но прибыль с одного этого клиента не оправдает расходов на время затраченное всеми отделами на проверку изменений.
С другой стороны - если это ценное изменение, и потенциальная прибыль больше, чем расходы - то в нормальном концерне будет регламент по этим изменениям. Который пускай медленно, но проползёт по всем требуемым процедурам и внедрит изменения.
IvanSTV Автор
"Нормальный концерн", где все регламенты меняются когда надо, а не когда там что-то где-то каким-то чудом куда-то проползет - это такой же миф, как и сказки про "нормальные страны" с кисельными берегами и молочными реками. Крупные компании выращивают непробиваемый бюрократический аппарат именно с целью, чтобы процессы шли строго о регламентам. Потому что персонал нанимают как можно дешевле, и доверять сложней лопаты ему не доверяют.
Временные потери, пока изменения "проползут", могут быть критичны, и как правило. критичны. Например, в фулфилменте это везде и всюду. Тут была статья, про то, что логистические компании неуспешны в фулфилменте. Я там прокомментировал, что все упирается в гибкость подстраивания процессов под клиента - логистические монстры, имея транспортные и складские ресурсы, гнут клиентов под себя, для них изменения процессов для клиента - расходы, в результате выкатывают конский ценник. Потому клиент, помучившись и попытавшись сработаться, уходит, вынося опыт, как не надо делать, и организовывает свою систему фулфилмента и логистики, где собственно логистическим операторам отводится очень вторичная роль.