[recovery mode] Станьте ежиками или немного о техническом мышлении и реальных процессах
Жили-были мыши. Все их обижали. Однажды пришли мыши к сове:
-Мудрая сова, помоги! Все нас едят. Скоро нас не останется. Что делать ?
Подумала сова и говорит:
-Мыши! Станьте ежами! Будете колючими и для охотников недоступны.
Побежали мыши радостно:
-Станем ежами! Станем ежами!
Вдруг одна остановилась:
-А кто-нибудь знает: как стать ежами?
Никто. Побежали обратно к сове.
-Сова! А как нам стать ежами???
-Мыши! Идите на … Я не тактик, я — стратег !
История про терминалы, монетаристское мышление и ценные советы.
Одна голландская контора, имевшая филиал со складами в России, озаботилась неээфективностью работы склада. На вызоде получалось много ошибок, да и людишек в процессах участововало поразительно много на квадратный метр площади. «Что делать?» — подумали быстрые разумом голландцы. — А, вот оно, надо автоматизировать входной и выходной контроль. 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. Наизусть выученая первая тысяча строчек списка номенклатуры. Регламентация переписок под шаблоны. Подстраивание кастомных выгрузок из систем.
И, наконец — можно что-то десктопное написать под текущие нужды — либо самому, либо на стороне заказать. Возможности для колхоза практически всегда есть.
И если мы видим колхоз, то это не потому, что хомячок тупой и не понимает, что можно сделать. Это потому, что в компании есть некоторые управленческие проблемы с обратной связью, из-за которых стать ежиком, как ни крутись, все равно не получится.
