«Внедрение нейросетей на производстве — это часто скрытая война»
Камиль Гадеев
Предисловие
Каждый раз, когда начинается новый технологический бум, разговоры звучат очень похоже. Сегодня все обсуждают ИИ: как он заменит часть работы, ускорит процессы и изменит профессии. Примерно те же разговоры велись некоторое время назад, когда на заводах массово начали внедрять первые системы управления производством. Тогда тоже казалось, что компьютеры вот-вот начнут всё делать сами, а люди останутся не у дел. На практике всё оказалось прозаичнее: работы меньше не стало, просто она изменилась. Поэтому, глядя на нынешний шум вокруг ИИ, я невольно вспоминаю те времена и некоторые тогдашние истории.
Вступление, или о «социальной инженерии» на производстве
Когда говорят «социальная инженерия», обычно вспоминают хакеров, которые коварно выманивают пароли у доверчивых пользователей.
Но есть и другая «социальная инженерия» — та, которая сопровождает процесс автоматизации любого предприятия. Когда нужно убедить и руководство, и сотрудников, что программа будет им полезна, сэкономит время, принесёт прибыль и т. д. Когда нужно их замотивировать и обучить пользоваться новой программой. Когда нужно изменить бизнес-процессы и преодолеть сопротивление. Практически уверен, что это будет повторяться и сейчас с ИИ.
Интересно отметить, что хакерам люди доверяют больше. Главным образом потому, что те используют специальные приёмы завоевания доверия. А вот автоматизаторов в большинстве случаев вначале встречают насторожённо. По разным причинам: не верят, что это им нужно; боятся, что у них это не получится; боятся, что после автоматизации их сократят; просто не хотят ничего менять и т. д. Поэтому автоматизаторам тоже нужно использовать различные методы и приёмы завоевания доверия пользователей.
Но если хакер добивается доверия, чтобы в итоге принести зло, то автоматизатор, наоборот, хочет принести пользу. Но там и там — социальная инженерия, психология.
В этом есть и определённая специфика проектов по автоматизации предприятий в отличие от проектов, например, по созданию мобильных приложений, разработке веб-сайтов и игр. Там всё в основном сообщается через сам готовый продукт: насколько он красиво выглядит, насколько он интересен, насколько удобно им пользоваться и др. В проектах же по автоматизации большое количество времени приходится именно на непосредственное общение с людьми, пользователями программного обеспечения на всех уровнях, от рядового сотрудника до руководства предприятий.
В этом тексте для сезона Heavy Digital я хочу рассказать несколько историй о том, как внедрение систем автоматизации происходит не только за счёт написания правильного (чистого, масштабируемого) кода, но и через организацию взаимодействия между программистами и пользователями на всех уровнях предприятия. Не ждите от этого текста решения серьёзных проблем, это просто байки. В общем, relax and enjoy))
Типовые решения
С точки зрения собственно программного обеспечения для производственных предприятий специфической особенностью этого сегмента рынка является наличие готовых, так называемых типовых решений.
Обычно это ERP-системы (Enterprise Resource Planning), т. е. программные комплексы для учёта и планирования ресурсов производственного предприятия, в первую очередь сырья и материалов, в процессе создания готовой продукции. (В данном случае не рассматривается ПО для автоматизации проектных инженерных работ, типа AutoCAD, или системы автоматизации технологических процессов (АСУ ТП).
При разработке игр, сайтов, мобильных приложений тоже есть что-то похожее, но в меньшей мере. Это могут быть какие-то блоки кода, фреймворки, платформы, которые переиспользуются при создании новых продуктов. Но в проектах по автоматизации производства это уже готовые программные комплексы.
Скрытый текст
Сейчас уже редко кто рискует создавать такие программные комплексы с нуля. Разве только очень сильная команда с большими инвестициями. А на заре автоматизации таких желающих было много. Но потом, путём естественного отбора, на рынке остались считанные выжившие. Например, в те времена, о которых идёт речь, это были: немецкий супермонстр SAP, процветающий и поныне, а также отечественные «Галактика», «Парус» и др. И как раз в то время появилась 1C 8: «Управление производством», которую тогда ещё скромно не называли ERP.
И опять же видна аналогия с ИИ: сейчас очень много желающих написать свою модель или программу, которая с ней сопряжена. Достаточно вспомнить OpenClaw. Но уже видна тенденция к разработке типовых решений.
И причина здесь в том, что базовые процессы на любом производстве одинаковые. Это Снабжение, Производство и Сбыт.
А уже дальше, на следующих уровнях декомпозиции, появляются особенности. Например, где-то могут быть специальные отделы по проектированию новых изделий, многоступенчатое производство, соответственно разные склады, разные учётные политики и т. д.
Отсюда автоматизация, или к��к сейчас модно говорить, цифровизация производства, представляет собой не написание программы, а её так называемое «внедрение».
Внедрение
Такое внедрение включает в себя доработку программного комплекса под специфику предприятия, его развёртывание на серверах и компьютерах предприятия и обучение пользователей.
И если второй и третий блоки обычно более или менее отработаны, то первый — доработка под специфику предприятия — это как айсберг с маленькой надводной частью и большой подводной.
Главный момент здесь — это разобраться в этой самой специфике, в тех бизнес-процессах, которые сложились на предприятии, чтобы понять, как их совместить с программой.
Как заказчики составляют ТЗ, или с чего начинается автоматизация
Обычно руководитель/владелец предприятия, или тот, кто отвечает за автоматизацию, формулируют свои запросы очень просто. Перечисляют несколько отчётов, которые им хотелось бы видеть.
При этом, конечно, они как пользователи не представляют себе весь масштаб работ. Но когда у нас на руках готовое типовое решение, то мы уже заранее знаем, что должно быть и даже в какой последовательности это нужно делать.
В частности, на производстве главный момент, база автоматизации — это номенклатура, справочник товаров, т. е. перечень сырья, материалов, всего того, что используется на производстве.
Именно с неё всё начинается. Это как план счётов в бухгалтерском учёте.
Как раз хорошая задачка для ИИ, потому что обычно это делается практически вручную и совсем не быстро. Не говоря уже о разных головоломках по ходу.
Три номенклатуры для одной продукции
Например, на одном из предприятий столкнулись с тем, что одни и те же материалы в разных бизнес-процессах могли называться по-разному.
Например, у снабжения свои отраслевые справочники, по которым делаются закупки. У производственников свои названия, причём некоторые категории от снабжения делятся на более мелкие элементы, а некоторые, наоборот, считаются одинаковыми при разных названиях. В свою очередь, у отдела сбыта тоже есть различия в названиях, которые надо указывать в счетах и накладных.
Решили следующим образом: главным определили перечень материалов для производства, поскольку у них он был наиболее развёрнутым и использовался именно для создания продукции. А остальные две номенклатуры уже к нему приспособили, используя разные дополнительные поля и алиасы.
«С деньгами каждый сможет», или как решить проблему финансирования
Заказчики очень любят «решать вопросы». И когда они понимают, что без автоматизации не обойтись, то задают «конкретный» вопрос: «Сколько это будет стоить?»
И вот, глядя им в глаза, я часто думал: «Ну вот как вам сказать, что реальная стоимость будет где-то на уровне $50 000, а то и $300 000, а вы рассчитываете уложиться в $5 000»?
Скажешь реальную цифру — они испугаются и побегут искать какого-нибудь студента, который напишет пару форм и исчезнет. А они набьют ещё пару раз шишек и всё равно придут к тому же решению, что мы предлагали, но уже не с нами.
С другой стороны, пообещать им сделать за $5 000 — это работать себе в убыток и не в радость.
Как найти выход из этой, казалось бы, тупиковой ситуации. Ведь действительно, «с деньгами каждый сможет». А вот ты попробуй выкрутиться, когда проект хороший, а с деньгами затор?
На самом деле решение есть. А именно: изменить точку зрения заказчика, что это не проектная оплата, а бюджет, постоянный бюджет на всю оставшуюся жизнь предприятия. Точно так же как у предприятия есть, например, бюджет на рекламу, точно так же теперь нужно выделять ежемесячный бюджет на автоматизацию. Потому как она теперь будет навсегда!
И тогда уже в рамках этого бюджета строить работу по внедрению. В этом случае предприятие имеет возможность двигать работу по автоматизации, а компания, которая внедряет программное решение, может планировать свои действия, не улетая в благотворительность.
Как правило, делается, конечно, больше. Но, если проект даёт результаты, то бюджет постепенно увеличивается. Заодно подключаются и другие затраты: на закупку железа, обновление сети, на дополнительные должности и т. д.
«Сладкий скандал»
Ну хорошо, определились, что вначале надо сделать справочник номенклатуры. Но, как правило, на это уходит много времени. А в это время и начальство заказчика, и сотрудники смотрят на вас и думают: ну так и где эта самая автоматизация?
Т. е., как бы там ни было, какие бы стратегические вопросы ни решались, но нужно выдавать результаты уже на первом месяце.
И для этого очень подходит операция выписки накладных на отгрузку готовой продукции. Т. е., даже если справочник номенклатуры ещё полностью не готов, так же как и база клиентов, то всё равно можно изловчиться и наладить формирование и распечатку накладных. Пусть даже потом часть информации будет утеряна при переходе на более основательные решения, но самое главное — как можно быстрее получить эффект первых результатов!
И вот на одном из предприятий, а это была большая, современная типография со сложными технологическими операциями, у нас по этому поводу случился «Сладкий скандал». Я его так называю, потому что действительно это был скандал, но он был «сладким» для нас, автоматизаторов.
В общем, ситуация следующая: первый месяц работы на предприятии, сегодня установили первое рабочее место для менеджера отдела сбыта, выбрали девушку, которая неплохо работает с компьютером, уговорили её попробовать, чтобы она нам потестировала и выдала список вопросов.
Довольные, едем домой. И вдруг звонок: руководитель отдела сообщает — «У нас ЧП, скандал и всё такое». Оказывается, эта девушка быстренько освоила новую операцию и оформила свои накладные до окончания рабочего дня. В то время как её подруги по цеху должны были ещё возиться пару часов после работы. И вот они видят: она уходит домой, а им ещё оставаться. Тут же выясняется, что у неё новая программа. И конечно же, сразу же делегация разгневанных девушек вваливается в кабинет начальника отдела и негодует по поводу отсутствия у них такой программы.
В общем, пришлось нам разворачиваться и ехать обратно, ещё пару часов устанавливать рабочие места и объяснять, как оно работает.
Скандал получился настоящий, и домой мы в тот вечер попали заметно позже. Но для нас это оказался тот самый «сладкий скандал», как ветер в паруса. Пользователи сами увидели, что программа снимает с них пару часов работы. После этого разговоры на тему «мне некогда» закончились, и дальше мы просто показывали, как ею пользоваться, и step-by-step добавляли новые возможности.
Шпионские штучки
Продолжая разговор об этих девушках, надо сказать, что всего их было человек 8 в отделе и все как на подбор молодые, лет 25, незамужние и симпатичные.
Как-то это явно бросалось в глаза, и однажды спросил об этом владельца предприятия, с которым встречались пару раз в месяц.
И он выдал такую вещь, что где-то в тогдашнем интернете прочитал, как работают отечественные спецслужбы. В частности, что 90% вербовок осуществляются через женщин. И тогда он решил использовать этот приём у себя на предприятии, почему и набрали отдел исключительно из девушек, чтобы мужчины-клиенты быстрее и легче соглашались покупать продукцию предприятия))
В общем, не знаю, насколько это у них работало. Но мы тоже на всякий случай стали выезжать на этот объект в мужском составе)).
Может ли кто-то читать ваши мысли?
До прихода в автоматизацию я успел поработать в продажах (от менеджера до начальника отдела), а ещё раньше получил хороший психологический бэкграунд из отечественной академки и зарубежных практик, особенно по разрешению конфликтов и ведению переговоров. И когда потом спрашивали — «Помогает ли знание психологии в бизнесе?» — отвечал, не стесняясь: да, помогает!
Только не так, как некоторые думают, что ты знаешь ответы на все вопросы. Это нереально, потому как человек — это огромная и бесконечная вселенная. Просто, как и в любой другой профессии, человек знает больше других потому, что что-то читал, учил, делал. И когда общаешься с людьми, обращаешь внимание на некоторые вещи, мимо которых раньше прошёл бы, не заметив.
Скрытый текст
Предубеждения насчёт психологии
Одно время было так, что когда скажешь знакомым про психологию, они начинали на тебя смотреть с опаской. Типа, может ты мысли можешь читать (реально так некоторые и думали), можешь загипнотизировать, или просят сказать, хорошо они поступают или нет. Т. е., должен во всём разбираться и все вопросы решать прямо на лету.
Особенно этим, увы, грешит современная отечественная киношная индустрия, где чуть ли не в каждом фильме есть психолог, который или лечит, или калечит и разрубает все проблемы с плеча. Смотреть на это просто неловко, как говорят в южных странах, «позорят профессию». Сценаристы, режиссёры и странные консультанты делают из этих персонажей каких-то девиантных личностей. Самый первый признак, что это высосанный из чьего-то пальца «специалист», — что он даже слухом не слыхивал, что такое «активное слушание», которое для такой работы — как арифметика для математики. Хороший психолог даже не считает себя именно психологом и уж тем более не заявляет об этом демонстративно на каждом шагу, он просто делает свою работу. Тем более в бизнесе, где такие пустые понты вычисляются на раз.
Как вычислить «звезду» в коллективе и зачем она нужна для автоматизации
Вот, например, как преодолеть сопротивление персонала внедрению новой программы? А оно всегда будет, в той или иной форме («скрытая война»). Люди испытывают дискомфорт при любых переменах, даже если они ведут к лучшему. О том, что нужно делать, чтобы проект получился успешным и не завалился, написано много руководств и советов. Но там обычно главное внимание уделяется тому, что должна быть поддержка от кого-то из руководства предприятия.
Но вот представьте себе ситуацию: приходим в отдел из тех же 8 симпатичных девушек. Владелец бизнеса «за», начальник отдела в курсе, девушки тоже. Но когда мы на первых порах начинаем общаться, чтобы понять, как у них всё тут устроено (бизнес-процессы и т. д.), то в ответ слышим: «Я занята», «Мне надо ещё много накладных оформить» и т. д.
Почему это происходит — это отдельный вопрос. Можно долго в этом разбираться, но нам тоже некогда. Нам нужно двигать проект.
Что делать в этой ситуации? Пойти настучать ответственному заму за проект? Так у него тоже своих проблем хватает, и если ты ему принесёшь ещё одну, то это не сильно тебе добавит авторитета. Начальство ведь тоже нас оценивает, насколько мы справляемся с людьми.
И вот тогда мы используем самую настоящую социальную инженерию, основанную на психологии людей.
Вначале небольшая справка: был такой психолог и социолог Джейкоб Морено. О нём сейчас почти не вспоминают, но у него были очень ценные для бизнеса идеи. В частности, он придумал так называемую «социометрию», т. е. измерение социальных характеристик малых групп (7, 15, 30 человек). Про него ещё иногда говорят, что он первый начал изучать социальные сети, задолго до Фейсбука (он работал в 30-х годах прошлого века).
Например, с помощью этой социометрии было выявлено, что в каждой малой группе люди делятся на 4 категории: самые популярные, популярные, не очень популярные и совсем не очень популярные. Так вот, самые популярные, их ещё называют «звёздами» или лидерами, они могут не занимать должность руководителя, но негласно именно они руководят группой. И многое зависит от того, что эти звёзды скажут и как они оценивают те или иные ситуации.
Отсюда наш лайфхак состоял в том, чтобы войти в контакт с такой звездой и заручиться её поддержкой. Если это сделаем, то всех остальных уговаривать уже не придётся.
Это, конечно, хорошо сказано, но как это реально сделать? Ведь не будем же мы проводить там научные исследования. А сами участники группы и не совсем осознают такие моменты, и обычно не любят откровенничать с чужими людьми со стороны.
На самом деле сделать это можно так: надо понаблюдать за тем, как участники группы общаются между собой. И если человек — звезда, то в ходе разговора большинство лиц направлено именно в его/её сторону. Т. е., люди рассказывают как бы ему/ей. И второй признак — когда этот человек говорит, его/её не перебивают.
А дальше нужно войти в контакт с этой звездой и заручиться её поддержкой для внедренческих работ. Можно сделать это прямо, но если и здесь почувствуется скрытое сопротивление (именно скрытое, в открытую редко кто говорит), то можно упростить задачу и попросить звезду порекомендовать кого-нибудь из группы, кто мог бы выступить первым тестером. Этот ход хорош тем, что со звезды снимается какая-то обязанность лично что-то делать и срабатывает эффект «Google Maps», когда люди с удовольствием рассказывают, как пройти на такую-то улицу. В итоге звезда облегчённо вздыхает (что ей лично ничего не надо делать) и с удовольствием рекомендует кого-то из своих коллег.
И дальше уже дело техники, потому что названному сотруднику уже очень трудно отказаться, когда его порекомендовала звезда группы. Это для него/неё серьёзный момент, «предложение, от которого невозможно отказаться».
В случае со «Сладким скандалом», о котором сказано выше, именно так мы определяли первого тестера.
Сколько воруют со склада, который не автоматизирован
По нашим тогдашним оценкам — 20–30%. Себе на дачу, друзьям, знакомым, продажа ради денег, в том числе и конкурентам. Знал даже одного кладовщика с мебельной фабрики, который выстроил себе дачу из «сэкономленных» материалов. А один из владельцев бизнеса говорил так: «Знаю, что воруют. Но пока мало, так что нет смысла заморачиваться».
Поэтому автоматизация склада — вторая в списке и первая большая задача в проекте внедрения. И если выписка накладных помогает запустить проект в хорошем темпе, то склад даёт основу всем остальным операциям.
Если брать в целом, то здесь в принципе не так уж сложно. Если есть готовое программное решение, есть номенклатура, бизнес-процессы, где видно, кто что делает и в какой последовательности, то остаётся только донастроить документы в программе, прописать порядок действий пользователей и заставить их соблюдать.
Иногда, конечно, приходилось и что-то дописывать в коде, но внедренцы, как правило, не очень любят это делать, потому как это влечёт за собой специальные процедуры поддержания совместимости при обновлении базовой конфигурации программного комплекса.
Сложные задачи
Сложные задачи попадались не так уж часто. Помню только две такие.
В одном случае типография печатает разные виды упаковок, этикеток пищевой продукции, используя при этом наборы красок. И эти краски могут многократно смешиваться. В результате образуются новые цвета и оттенки. И надо было всё это учитывать, чтобы подбирать краски для новых заказов и чтобы не тратить лишнее.
Второй случай — на швейном производстве, где резали рулоны тканей на куски разной формы и размеров. И надо было свести к минимуму неизрасходуемые остатки.
Это одна из трёх классических задач программирования на поиск наиболее оптимального алгоритма: в одном случае речь шла о металлических отрезках, из которых нарезали более мелкие отрезки разной длины; второй — это как раз пример с отрезками ткани; и третий — это задача коммивояжёра, когда надо рассчитать наиболее оптимальный маршрут с минимумом затрачиваемого времени и бензина.
Тогда, при увеличении количества параметров, эти задачи считались неразрешимыми. Возможно, сейчас, с помощью ИИ, количество таких параметров будет увеличено.
Конкуренция и сотрудничество с бухгалтерией
Был однажды такой случай: владелец производственной фирмы, которая производит изделия из древесных материалов (уже не помню, что именно, помню только запах свежей древесины в помещениях этой компании)), устроил нам без предупреждения совещание со своими замами, чтобы мы рассказали, что мы предлагаем. И там по ходу сидит главбух, средних лет, хорошая женщина, которая выдаёт такую сентенцию: «Иван Иваныч, а зачем нам это? У нас же всё есть в бухгалтерской программе».
Этот аргумент на первых порах встречался довольно часто. С одной стороны, это ещё один пример скрытого сопротивления. С другой — в нём есть вроде бы какая-то доля истины. Действительно, первой программой на предприятии обычно является бухгалтерия. И там реально много информации.
Проблема в том, что задача бухгалтерии — оценивать стоимость предприятия. А производству нужен количественный учёт. Если думать по-бухгалтерски, то вроде как это легко узнать: надо просто общую стоимость соответствующих материалов разделить на цену, по которой их приобрели.
Но дьявол, как известно, кроется в деталях. Здесь немного поясню для тех, кто не сталкивался с вопросами учёта. Например, условно говоря, на складе 60 единиц запчастей для ремонта автомобилей по цене 110 руб. Их ещё не успели забрать в производство, как привезли ещё 20, но уже по цене 115 рублей. Бухгалтерия их оформляет как 60×110 + 20×115 = 8 900 руб. Эта цифра фигурирует в программе.
Как теперь производству узнать, сколько у них данных запчастей, т. е. на какую именно закупочную цену делить? Их ведь теперь 2 цены. А может быть и 3, и больше. Пойти спросить у бухгалтеров? Каждый раз не набегаешься. То же с кладовщиком. И дальше: как считать их в себестоимости готовой продукции, по какой цене? Хорошо, если кладовщик положил их отдельно или промаркировал. Но реально при большом потоке поступлений и расходований всё смешивается.
И тогда начинается свистопляска с системами учёта. Здесь уже с бухгалтерией надо плотно сотрудничать. И хорошо, если есть опытный бухгалтер, тогда этот вопрос решался достаточно быстро. Например, при поступлении материалов с новой ценой устанавливается средняя и данные в программах автоматически пересчитываются. Или, если колебания небольшие, то устанавливают постоянную закупочную цену. А если работа на складе уже налажена, то ещё проще: обычно выбирается либо схема FIFO (первый пришёл — первый ушёл), либо LIFO (последний пришёл — первый ушёл), в зависимости от того, что предприятию выгоднее.
Интересно ещё такое наблюдение: когда многие вещи по учёту автоматизируются, то часто программисты уже лучше бухгалтеров и других специалистов предприятия знают все тонкости учётных политик. Точнее сказать, они знают, где их найти. Т. е., получается, что программа становится хранилищем решений этих бизнес-задач пользователей.
Склад — это наше всё
Мы работали обычно с коммерческими предприятиями, средними и малыми. На большие и государственные тоже иногда захаживали, но там больше политики, чем бизнеса и, соответственно, другие «метрики» оценки эффективности внедрения.
По профилю предприятий в нашем портфолио были несколько мебельных фабрик, большой проект с типографией (для которого мы первыми в своём регионе завезли 1С 8: "Управление производством", чем очень гордились)), ремонт автомобилей, швейное производство, производство электротехнического оборудования, совместные предприятия по изготовлению медпрепаратов, строительных материалов и др.
И вот представьте, как часто выглядел в то время склад отечественного производителя. Как правило, это было какое-то полуподвальное помещение, где прямо на полу разложены все материалы и инструменты. Не то что стеллажей, там даже на полу не было никаких разметок. Хорошо, если ещё были какие-то прикреплённые бумажки. Я уже не говорю о том, что склад материалов мог быть в том же помещении, где и склад готовой продукции.
И между горками всех этих сокровищ сновал кладовщик. Почему-то это чаще всего был мужчина, уже в возрасте, в очках, с химическим карандашом, которым он записывал в потрёпанную общую тетрадку свои иероглифы, которые, как и у врачей, никто кроме него не мог нормально прочитать. И уже конечно, никто кроме него не мог бы там что-то найти. Те, кто в теме, понимают, во что это обычно превращается.
Можно было, конечно, сказать руководству, мол, сделайте нормальный склад, со стеллажами и т. д. Но тут опять возникает известная тема «с деньгами каждый сможет».
Поэтому начинали с простых операций: приход материалов на склад и расходование материалов со склада. И как бы не извивались кладовщики и другие участники процесса, требования были жёсткими: каждый приход и расход должен быть отражён в программе и как можно скорее.
Потом деление складов: материалы — отдельно, готовая продукция — отдельно. Затем, в проекте с типографией, например, сделали несколько складов материалов: первый — общий, закупки; второй, общий — производство, всё что идёт со склада материалов на производство; внутри производства ещё несколько складов по технологическим участкам.
На первый взгляд громоздко, но в реальности, когда система отлажена, это просто загляденье: в любой момент времени видно, где что находится. А поскольку у типографии бывают пробные прогоны и брак, то сделали ещё и склад брака.
И все эти склады не только в программе, но и реальные физические пространства, с материально ответственными, с электронным документооборотом и с новыми компьютерами на производстве. Не случайно потом, глядя на эти новые компьютеры в подсобках цехов, владельцы типографии начинали уже разговоры и об автоматизации собственно технологических процессов.
Инвентаризация как момент истины
Момент истины для складского учёта начинается в момент инвентаризации.
Здесь тоже встречается своё сопротивление, причём ещё более скрытное по известным причинам. Обычно это проявляется в разговорах о том, что это очень сложно сделать, что нет времени всё записывать, надо быстро передавать материалы на производство и т. д. Т. е., как бы «для пользы дела» надо всё делать быстро и не заморачиваться с бумажками.
В упоминавшейся ранее типографии, где было много проблем со старыми смешанными красками, дошло уже чуть ли не до официального признания, что с предыдущими остатками на складе так и не получится разобраться.
А у нас как раз в это время шёл параллельно небольшой проект на государственном молочном заводе. А там такой порядок, что если инвентаризация не сойдётся, то кладовщик может пойти и под суд. И если не изменяет память, то они делали инвентаризацию каждый день, а тут хотя бы раз в месяц сделать.
В общем, рассказали про это владельцу типографии и на очередном совещании он поставил перед производством вопрос ребром: «Мы здесь наведём порядок. С вами или без вас!» Сказано было очень резко, и всем стало понятно, что альтернатив для инвентаризации нет, и точка! Так что приходилось иногда использовать и вот такую авторитарную социальную инженерию.
В итоге, сделали первую инвентаризацию: она тянулась почти две недели; потом ещё надо было разбираться в нестыковках, а уже пришло время следующей инвентаризации. Тем не менее, с каждым разом всё проходило быстрее и точнее. И где-то через 3–4 месяца процесс вошёл в рабочий режим.
Скрытый текст
Задачка про морковки
В то время среди автоматизаторов ходила такая задачка-шутка:
Заяц купил 7 морковок. Потом он съел 3. Сколько у него осталось?
Ответ: не 4, как в обычной математике, а 6, потому что у него были ещё 2 в остатке.
Мораль: всегда учитывайте остатки на складе.))
Почему в этой статье нет примеров кода и технических подробностей
На то есть три причины:
Во-первых, это было давно и тот код уже не актуален. Как и технические решения. Современные производства довольно сильно отличаются от тех давних. Причём не только технически, но и организационно.
Затем, я был тогда руководителем проектов, т. е., в небольшой компании это специалист на все руки, кроме непосредственно работы с программой. В этом не было особой необходимости. Подключался только в случаях каких-то затруднений. А таких случаев особо и не было, вспомнил только две сложные задачи, о которых рассказано выше. В общем, если есть типовое решение, то остальная работа на 80–90% сводится к тому, чтобы организовывать взаимодействие между командой внедрения и сотрудниками предприятия. А это общение с людьми со всеми своими закономерностями и нюансами.
И в третьих, статья под названием «Байки…» предполагает наличие небольших историй, лёгких для чтения. Тем более, что об этом не так уж много говорят — как выглядит такое сопротивление ИТ-инновациям и как с ним бороться.
На что уходит много времени
Очень много времени уходило на устранение разных нестыковок в данных. Например, вносят в программу новое название номенклатуры, или новую компанию клиента, и по ходу не ту букву записали. И дальше как снежный ком: то накладные идут по разным наименованиям, то взаиморасчёты не сходятся, и т. д., и т. п. И таких моментов может быть много и разных.
В общем, тут человеческий фактор гуляет по полной программе. А ещё бывало, что находились такие умельцы, которые отпускали продукцию своим знакомым или ради денег, а потом удаляли накладные. Чем не хакеры?)) Там уже начинались настоящие FBI-расследования.
Были и более простые, немного даже весёлые случаи. Например, на предприятии по ремонту автомобилей при первом запуске программы оперативного учёта обнаружили, что данные не сходятся с бухгалтерской программой. В нашей программе двигатель ушёл со склада в производство, в бухгалтерии — об этом ничего нет. Начали разбираться — концов не найти, никто ничего не знает. И только через неделю-другую кто-то из бухгалтерии вспоминает, что они этот двигатель специально передвинули в своём учёте на другой месяц, потому что тогда надо было что-то такое провернуть с налоговой отчётностью. (Кстати, после этого нашу программу на данном предприятии зауважали именно по причине актуальности данных.)
Самая больная проблема с этими нестыковками в том, что на их выяснение уходит туева хуча времени. Ладно, если это просто ошибка в написании, тут понятно, что надо исправить. Хотя это тоже не всегда просто, потому как надо все старые записи каким-то образом интегрировать.
А если что-то не сходится в расчётах? Очень часто бывает, что на какую-то мелочь уходит столько времени, сколько не тратится на новые решения. Надо найти человека, который это сделал, ему надо вспомнить, зачем он это сделал. Тут же оценивается, то ли он это сделал по-доброму, или по глупости, по неопытности, либо с каким-то умыслом. Потом надо разобраться, как правильно должно быть, принять решение, как исправить, согласовать, внести изменения, протестировать, доработать, снова протестировать и т. д.
В больших проектах это называется сопровождение, эксплуатация, и здесь, конечно, тоже есть своя специфика. Оно как-то даже похоже на какую-то детективную работу: что-то там случилось, детектив начинает расследование, изучает подробности, встречается с людьми, собирает информацию, строит гипотезы, накапливает доказательства, ищет ответы и т. д.
В наших же случаях, когда проекты были не очень громадными, важно было создать новую должность админа базы. Т. е., не технического админа, который обслуживает компьютеры, сеть и общую работоспособность программы, а человека, который контролирует качество данных. Это как создать в программировании новый объект более высокого уровня абстракции: есть бизнес-процесс по исправлению ошибок в данных, мы создаём новую сущность (должность), которая инкапсулирует в себе все соответствующие операции. И там уже по ходу возникают и новые функции (методы объекта), например, что только такой админ может вносить новую номенклатуру, новых контрагентов и только он может делать какие-то исправления.
А дальше по цепочке могут появляться и новые бизнес-задачи. В частности, что чувствительные изменения в базу данных могут вноситься только по согласованию с руководителем подразделения. И это тоже может отражаться в программе.
Коучи и эксперты
Пришло время кинуть пару камешков в огороды смежных профессий. Но не с точки зрения сказать им, что у них что-то не так, а просто вспомнить с улыбкой пару запомнившихся случаев.
Случай первый: коуч и компьютеры
Итак, мебельное производство. Первое впечатление о компании, что в офисе как-то странно маловато компьютеров. Оказалось, что незадолго до этого здесь побывал коуч с модной технологией (угадайте с какой?), который посоветовал владельцу не слишком увлекаться компьютерами.
Причём самое, не знаю как даже это назвать, может «интересное», было в аргументации: мол, «главное — это не компьютеры, а люди». Когда впервые это услышал, то даже дыхание заняло от глубины мысли. Ну, подумаешь, действительно, какие-то там железки против мощи человеческого разума.
В итоге компания стала заметно проседать по сравнению с конкурентами.
Интересно так же, что точно такую же аргументацию приходится иногда слышать в других профессиях. Например: ну вот в других странах у врачей много разного оборудования, поэтому они отучиваются думать сами, а у нас таких аппаратов мало, поэтому врачи умные. Или в фильмах про полицейских: вот приходят новички, они активно используют новые методы, а старички задумчиво говорят крупным планом что-то типа — опытного специалиста не заменить никакой техникой. (Вам это, уважаемые читатели, ничего не напоминает?)
В общем, логика вроде как какая-то есть, но она со сдвинутой оптикой.
Случай второй: эксперт и программы 1С
Вначале небольшая справка для тех, кто не в теме, чтобы было понятно, в чём состоял юмор ситуации.
Гениальность, не побоюсь этого слова, компании 1С в том, что для типовых ситуаций автоматизации на предприятиях они начали создавать типовые решения. Помню, сколько было дискуссий на форумах, что типовое решение не выживет, что разные предприятия требуют индивидуальных решений и т. д. Оказалось, выжило и даже стало стандартом.
И второй момент — что 1С не стала сама внедрять свои решения, а организовала сеть франчайзи, которые покупали эти решения и внедряли их с возможностью изменений под конкретную ситуацию.
Мы тоже в своё время подключились к этой сети и начали активно использовать программные продукты 1С. И как многие тогда франчайзи, в определённый момент задумались о том, чтобы на базе 1С создать свою конфигурацию под определённый сегмент рынка, потому как работать с разными бизнесами довольно затратно.
В итоге разработали план и начали искать инвесторов, приходили к ним со своими презентациями, обсуждали, считали и т. д.
И вот в одной из таких консалтинговых компаний общаемся с директором, парень лет 30–35, его зам, женщина, очень боевая, и ещё один парень, лет 25 на вид, которого представили как эксперта.
По ходу разговора он, наверное, решил внести свой вклад в обсуждение, и говорит: «А как обстоят дела с авторскими правами? Как компания 1С относится к тому, что вы используете их программы?»
Я чуть не упал со стула)) Но сдержался. Больше мы в ту компанию не обращались.
Этот эпизод всегда вызывает по ассоциации воспоминание о другом случае. И хотя там речь была не о производстве, но я кратко попробую изложить, в чём там было дело и почему возникает ассоциация с «экспертом» по 1С.
Параллельно с автоматизацией у нас была и команда, которая занималась интернет-проектами. И вот мы планируем сделать новый сервис, но предварительно раз��овариваем со специалистами в этой области, насколько всё реально, взлетит ли оно в нашем регионе. Оценки были разные: например, у такого сервиса пользователей будет человек 300 компьютерных гиков; в других случаях — порядка 3 000 и т. д. Реально же через 7 месяцев в сервисе зарегистрировался 300-тысячный пользователь, причём не компьютерный гик, а женщина-пенсионерка. (Не называю регион и сервис, потому что не вижу в этом особого смысла. Сервис с тех пор уже претерпел несколько реинкарнаций.)
Поэтому отношение к экспертам сложилось такое: к ним надо прислушиваться, но их мнение — это не истина в последней инстанции, это один из взглядов на ситуацию. Когда ситуация типовая, то да, их оценка более значима. Когда же проект новый и у него нет известных аналогов, то тогда мнение эксперта приближается к случаю 50 на 50. Может быть, он прав, а может быть, и нет.
Это напоминает и нынешнюю ситуацию с ИИ-моделями в программировании. Когда проект уже сколько-то раз выполнялся и обсуждения с решениями по нему можно найти в интернете, тогда ИИ хорош и может действительно реализовать хорошее приложение. Но если идея проекта новая, то ИИ просто начинает фантазировать, пытаясь использовать уже известные ему подходы и блоки кода, чтобы создать требуемую конструкцию.
Агенты и менеджеры
Ещё одна байка. Только не подумайте, что это про ИИ-агентов. Нет, это ещё про тех агентов, которые занимались активными продажами.
Сразу мораль: иногда в ходе проектов нам приходилось не только создавать что-то новое, но и что-то разрушать. Как говорил один из наших программистов, «есть светлая сторона внедрения, а есть тёмная».
Но, с другой стороны, такое разрушение есть не что иное, как самый настоящий реинжиниринг (перепроектирование) бизнес-процессов, который тогда был очень популярен.
И вот с этой точки зрения хочу рассказать любопытный случай из нашей практики внедрения.
В общем, компания продаёт офисную мебель. Затем, набравшись опыта, запускает своё производство. Чтобы продавать производимую продукцию, разворачивается рекламная кампания и набирается отдел активных продаж. Их там было тогда человек пять менеджеров.
Но вот работают они как-то «не так», как хотелось бы руководству. Надо, как всегда, больше продаж, больше звонков, больше контактов и т. д., а они типа полусонные, сидят в офисе, никуда особо не ездят и т. п.
В это время берут на работу нового финансового директора, молодую амбициозную женщину с хорошим образованием и неплохим опытом. И вот она предлагает владельцу запустить в оборот такой способ подстегнуть менеджеров и увеличить продажи, который был тогда в ходу и который тоже можно назвать социальной инженерией.
Идея следующая: набирается ещё одна-две группы продавцов, по 3–5 человек, но уже не менеджеров, а агентов. У них нет рабочих мест в офисе, у них нет постоянной зарплаты. Им выдаётся рекламная информация, и они должны продавать в свободном режиме. Стимулом для них определяется более высокий процент выплат от совершённых продаж по сравнению со штатными менеджерами.
С точки зрения организаторов такого мероприятия всё круто: затрат на агентов почти никаких, они всё делают сами. А для менеджеров это конкуренция, которая их расшевелит и разбудит. Мол, если будете плохо работать, так мы вас заменим.
Процесс идёт пару месяцев. В это время мы запускаем учётную программу и проверяем качество данных на первых отчётах. И что мы видим: продаж у агентов как-то подозрительно мало.
Я до сих пор удивляюсь, почему руководство компании не видело этого раньше. Вот всё-таки, в чём сила автоматизации и цифровизации: руководитель вроде всё знает о своём бизнесе, но привыкает к ежедневной рутине и глаз как бы замыливается, не обращает на это внимание. А когда появляются конкретные цифры, то это уже выглядит как вопрос, с которым надо разбираться.
В общем, нам стало интересно: почему столь «мощно» организованное мероприятие выглядит как-то не очень. Пообщавшись с одним из агентов, удалось выяснить, что ��н один и остался. Остальные просто ушли.
Но самое интересное — почему он остался. И состояло оно в том, что этот агент договорился с одним из менеджеров, они находили клиента, оформляли его как результат работы агента и получали более высокий процент с продажи.
Я даже название придумал для такого случая — обратный реинжиниринг. Как говорят в народе, There is no lock without a key.
В итоге с нашей подачи эту аферу прикрыли. Оставшегося агента за изобретательность взяли в штат. А потом ещё по результатам всё той же аналитики из программы обнаружили, что есть отдельная группа клиентов, дилеры, которые перепродавали эту мебель кому-то ещё (опять же удивление по поводу «невидимости» этого момента для руководства). И тогда мы снова встряли и посоветовали руководству выделить дилеров в отдельную группу и добавить туда менеджеров.
Мы, конечно, могли этого не делать, заниматься только кодом и всё. Но, с другой стороны, такие моменты поднимали ценность внедряемой программы и нашей работы в целом. А это доверие со стороны заказчика, новые задачи и новые деньги.
Да и удовольствие от такой работы — реинжиниринга — тоже вещь немаленькая. Чувствуешь себя кем-то вроде корпоративного супермена, который может увидеть то, что не видят другие, и изменить то, что другим не под силу.
Как мы написали свою программу и опередили время
В конце позволю себе немного самопиара. На заре автоматизации мы тоже разработали свою собственную программу и… опередили с ней время. В буквальном смысле.
А именно: мы написали программу для управленческого анализа, а предприятия в то время только-только начали автоматизировать оперативный учёт. Т. е., чтобы руководитель мог анализировать данные, их нужно было вначале ввести в компьютер. Поэтому в большинстве случаев им было не до управленческого анализа, им нужно было хотя бы иметь возможность найти нужную накладную и видеть ситуацию с взаиморасчётами.
По этой причине нам пришлось перестраиваться: или дописывать в своей программе учётные модули, или пытаться извлечь данные из тех программ, которые уже были запущены на предприятии. Таким способом, где-то десятка полтора проектов мы на своей программе всё-таки реализовали. Дописали к ней потом ещё и CRM-модуль (Customer Relationship Management).
Вот здесь технические детали довольно интересные с сегодняшней точки зрения. Написана была эта программа на Microsoft Access. Долго выбирали платформу, пробовали Delphi, FoxPro и другие. Но в итоге сыграли свою роль такие моменты, как готовая база со всеми элементами управления, многочисленными настройками, возможностями создавать отчёты, формы, хорошая связка с Excel и Word. И, конечно, солидность и надёжность вендора.
Более того, мы с этой программой даже попали в список решений партнёров Microsoft, чем очень гордились. Заодно начали готовить и SaaS-версию (Software as a Service).
Скрытый текст
Про Access
Ради интереса сделал на днях ресёрч насчёт Access и вот что получил в ответ:
C середины 1990-х Access стал стандартным инструментом для малых корпоративных систем. Тысячи компаний сделали на ней: учёт клиентов, складские системы, бухгалтерские надстройки, CRM-программы, системы документооборота.
Так что, оказывается, не только мы выбрали эту настольную СУБД как базовую платформу.
И ещё мы очень гордились своей схемой анализа, т. е. набором отчётов для управленческой аналитики. И она действительно была удобной и эффективной. Например, у тогдашнего Oracle тоже была своя аналитика, но они загоняли туда все виды отчётов, которые могли найти в статистике. В результате ты вроде имеешь все возможности, но не знаешь, каким именно воспользоваться. 1С, в свою очередь, пошла от практики: т. е., они создавали те отчёты, которые у них запрашивали пользователи. Это очень хороший шаг, но тоже не хватало системности, какой-то концепции работы предприятия. Наконец, Microsoft начала уже создавать именно концепцию и под неё аналитические отчёты. Но они ушли немного в сторону от конкретной реальности и пошли по пути создания просто документации, т. е., вот представьте себе такую-то условную компанию, она работает так-то и может использовать такие-то отчёты.
В нашей же программе всё было завязано именно на концепцию управления предприятием с точки зрения реинжиниринга бизнес-процессов. Т. е., предлагалась готовая последовательность шагов по аналитическим отчётам, которые помогали выявлять узкие места, находить новые решения и совершенствовать основной бизнес-процесс предприятия.
Но потом пришла 1С и принесла уже готовые решения и для оперативного учёта, и CRM, и управленческий анализ. Так что мы поняли, что эту конкуренцию нам не вытянуть, поэтому переключились на другие задачи.
Как я переписывался с Майклом Хаммером, автором концепции реинжиниринга бизнес-процессов
Честно признаюсь, заголовок для этого раздела немного кликбейтный.
Но в действительности оно так и было, только переписка была одномоментной, т. е. я ему написал емайл, а он мне ответил. Вот и вся переписка))
Тем не менее это было здорово — получить ответ от одного из мировых гуру в области бизнеса и ИТ.
Скрытый текст
Чем знаменит Майкл Хаммер
Michael Hammer — один из главных авторов концепции реинжиниринга бизнес-процессов (Business Process Reengineering, BPR). Его книга Reengineering the Corporation (1993) в соавторстве с James Champy стала мировым бестселлером по менеджменту.
Реинжиниринг в ней определяется как «Фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов».
Одна из основных идей состоит в том, что информационные технологии не просто переносят на компьютер старые процедуры, а благодаря своим возможностям радикально меняют сами эти процессы.
Многие идеи BPR используются сегодня в области Software Engineering. Это, в частности, Agile, Product Teams, Domain-Driven Design, Event-driven-архитектура, Microservices и др.
Что примечательно, Хаммер по образованию ИТ-шник и работал как Professor of computer science в знаменитом MIT (Massachusetts Institute of Technology). А в момент нашей с ним переписки ещё и руководил собственной консалтинговой компанией, которая занималась как раз таки автоматизацией предприятий.
В нашей команде мы тогда были очень увлечены этими идеями, и время от времени в проектах действительно происходили эпизоды реинжиниринга, вызванные внедрением автоматизации.
Например, офис компании находится в центре города, а завод далеко на окраине, в промзоне. Заказчик, чтобы забрать свою продукцию, должен вначале приехать в офис, где менеджер выпишет ему накладную на отпуск. Только потом он едет на завод и загружается.
Этот порядок сложился когда-то давно, и все к нему привыкли, точно как и рассказывал о таких случаях Хаммер в своих работах.
Но вот появилась корпоративная сеть, и эта процедура была реализована иначе: менеджер по-прежнему формировал накладную и отправлял её на печать. Но не на офисный принтер, а на удалённый, который находился на складе готовой продукции в производственной локации.
И когда такие вещи происходят, то меняется отношение людей. Вместо сопротивления появляется заинтересованность, мотивация. И это очень хорошая энергия, которая помогает решать очень многие вопросы. Но она очень сложная, трудноуловимая и трудноуправляемая. Многие руководители компаний хотят сформировать так называемый корпоративный дух, но в реальности зачастую это выглядит как красивая картинка, за фасадом которой написано, что «они делают вид, что платят нам зарплату, а мы делаем вид, что работаем».
Вот по поводу этой мотивации я и задал вопрос Майклу Хаммеру. Формулировка была примерно такая: выполняете ли вы реинжиниринг мотивации персонала? Причём под персоналом понимались не только сотрудники, но и руководители, у которых тоже есть своя мотивация. Как их совместить между собой, чтобы все участники получали то, что им нужно?
Гуру ответил мне в вежливом американском стиле. Что, мол, обычно реинжиниринг используется для классических предметных бизнес-процессов, таких как закупки, производство продукции, сбыт и т. д. Но при этом добавил, что «вы можете использовать реинжиниринг и для мотивации».
В общем, гештальт не закрылся. Но я остался при своём мнении, что мотивация может быть предметом реинжиниринга, перепроектирования.
Не только хорошо сделать, но и хорошо показать
В продолжение темы о реинжиниринге мотивации хочу немного рассказать и о таком важном вопросе, как «оформление» выполняемых работ по автоматизации. Т. е., нужно не только хорошо всё делать, но нужно ещё и хорошо это показывать — и сотрудникам, и руководству.
Идея об этом пришла как раз из случаев преодоления сопротивления. Как управлять этим процессом, чтобы не пускать его на самотёк? Выше я уже приводил некоторые примеры такой работы. Но здесь хотел бы остановиться на этом более целенаправленно.
Главное — стало понятно, что это отдельный, самостоятельный бизнес-процесс в ходе внедрения, который надо планировать и который нужно реализовывать.
Например, ежемесячные встречи с владельцем/руководителем/ответственным за внедрение. Не только для того, чтобы получить оплату за выполненные работы, но и для информирования о том, как идёт проект. Обычно на первых порах они рассматривают автоматизацию как что-то дополнительное к основной своей работе. Мол, решили вопрос, поручили заму, процесс запущен, а я тут буду деньги делать и вы меня особо не отвлекайте. Но когда он получает информацию о том, как процесс идёт, и особенно как решаются те или иные задачи, то у него добавляется удовлетворённости от того, что он принял такое правильное решение и что оно работает. Соответственно, для нас это расширение платформы взаимодействия с предприятием, возможность увеличения объёмов работ и т. д.
В начале проекта желательно оповестить сотрудников предприятия. Несколько раз случался испорченный телефон. Владелец даёт распоряжение заму, мол, вот, будем автоматизировать. И на этом заканчивается. Мы приходим в отдел, а там не могут понять, кто мы такие и зачем сюда пришли.
Если есть однородная группа пользователей, как те же девушки отдела сбыта из типографии, то регулярно проводили с ними рабочие совещания, как минимум раз в месяц, а лучше раз в 1–2 недели. Там рассказываем, как продвигается проект, какие задачи сейчас в разработке. И самое важное — здесь же обсуждаем какой-то бизнес-процесс, который надо автоматизировать. Спрашиваем их мнения, выслушиваем, записываем.
Чисто технически это экономило массу времени. Например, если бы мы собирали эту информацию по отдельности у разных сотрудников, а потом бы ещё её и согласовывали между собой. И более того, потом надо было бы обратно уже готовые схемы распространять среди сотрудников, как выполнять ту или иную операцию. А здесь выполнялось всё за раз. Кстати, в той же типографии потом в этих совещаниях стали участвовать и начальник отдела, и зам, ответственный за внедрение.
И здесь же мы сделали одно удивительное открытие. Оказывается, сами того не зная, мы повторили знаменитый Хоторнский эксперимент. Если в двух словах, тогда, ещё в начале 20 века, на одном из американских заводов рабочих решили привлекать к решению вопросов об изменениях их условий работы. Например, с ними советовались, в какие цвета покрасить стены цехов, сколько повесить лампочек в рабочем помещении, как расположить столы и т. д. Оказалось, что это даёт очень большую прибавку и в плане результативности работ, и в плане удовлетворённости работников. Т. е., по сути, это мотивация и есть.
Так вот у нас получилось практически то же самое. Мы обсуждали с менеджерами, как построить тот или иной процесс, какие документы использовать, какие данные вносить, что делать, что не делать. И они во всём этом активно участвуют. Т. е., они видят, что их мнение имеет значение, что их активность даёт результат. Соответственно, повышаются и их информированность, и их заинтересованность, и их результативность.
Правда, случалась в такой работе и обратная сторона. Например, это порождало иногда гиперактивность некоторых сотрудников, которые приходили к нам и прям требовали добавить в программу ту или иную кнопку, изменить операцию, чтобы им было удобно, и т. д. Такие моменты регулировали через их непосредственных руководителей. Т. е., вводили ещё один процесс — согласование изменений, которые должны были утверждаться начальником отдела.
Но бывали и более сложные случаи, когда желание одного сотрудника противоречит желанию другого, и оба не хотят уступать, и оба хотят, чтобы их задача решалась в первую очередь, как можно быстрее. Тогда по ходу у нас получилось разрешить этот конфликт прямо на рабочей встрече. А именно: обычно мы рассказывали или прямо показывали список задач, над которыми сейчас работаем. И вот мы им говорим: смотрите, у нас такой-то перечень задач и мы планируем вначале делать вот это и это. Но если вы считаете, что нужно что-то здесь поменять, то давайте обсудим. Т. е., делали так, чтобы решение принимали не мы, а они сами. Естественно, начиналась дискуссия, иногда бурная. И там уже наглядно было видно, что какие-то хотелки отдельных товарищей выглядят очень мелкими по сравнению с более важными задачами, которые касаются буквально всех. И уже не надо спорить и уговаривать, они сами всё видят, и решение принимается всей группой. Это тоже элемент такой социальной инженерии в процессе внедрения.
Светлая и тёмная стороны внедрения
В байках о прошлых временах, как правило, остаются только приятные, светлые моменты. Но у каждой медали, как известно, есть и другая сторона. Точно так же у внедрения есть свои две стороны — светлая и тёмная.
Но поскольку организаторы сезона Heavy Digital попросили рассказывать об успехах, то, соответственно, сегодня мы задвинем тёмную сторону в тёмный угол.
А вместо этого кратко вспомним несколько самых воодушевляющих моментов по результатам внедренческих проектов.
Первый — когда при мне зам, ответственный за проект, открыл программу и показал владельцу предприятия, как рассчитывается себестоимость продукции прямо в режиме онлайн. Сопровождалось это словами «как небо и земля», т. е. сравнение того, что было раньше и теперь.
Второй момент — с уже упоминавшейся накладной, которая набиралась в офисе и отсылалась на заводской принтер. Когда мы запускали эту операцию в работу, пользователи смотрели на неё как на магию))
Третий — на основе наших схем по бизнес-процессам владелец осмелел и решил провести сертификацию предприятия по стандарту ISO 9001. Это уже был предмет специальной гордости.
Цифровая модель предприятия
В целом, когда автоматизированная система запущена и хорошо работает, то она выглядит как цифровая модель предприятия.
Это прямо как в объектно-ориентированном программировании: вот есть реальный объект — предприятие, а вот его цифровая, виртуальная копия, модель объекта. И у объекта есть свои свойства и методы, а ещё он взаимодействует с другими объектами.
Но самое главное ощущение — это ощущение управляемости. Что с помощью этой цифровой модели можно управлять реальным предприятием. Модель сообщает нам, где в реальной системе происходят сбои. И наоборот, найдя решение в цифровой модели, мы можем перенести его в реальные бизнес-процессы на предприятии.
В такие минуты чувствуешь себя каким-то всемогущим Богом. И это не святотатство, поскольку мы изначально созданы по образу и подобию Божьему, т. е. по умолчанию мы все уже немножко боги. Смысл этого ощущения в том, что мы из хаоса, неопределённости, неразберихи выстраиваем понятную, управляемую и по-своему красивую систему. И крутятся внутри неё разные цифровые шестерёночки как в часах. А сама система для нас уже как родная))
ИИ как новая сущность в процессе цифровизации
А сейчас вот бурно прогрессирует ИИ — новая сущность, интеллект, но какой-то особый. Меня поразила такая его характеристика: обычно мы понимаем интеллект как некую отдельную сущность. А здесь сущность, которая существует в миллионах копий одновременно. Как она себя осознаёт?
В любом случае, если смотреть на основные задачи производственного предприятия, там есть где развернуться ИИ. Это и расчёты себестоимости, и номенклатура, CRM, взаиморасчёты с контрагентами, служба поддержки (уже практически реализуется), та же бухгалтерия, финансовые потоки и др.
Скрытый текст
Что полезно знать из психологии для бизнеса
Иногда люди интересуются, что полезного можно взять из психологии для бизнеса. Мой список такой:
3 основные:
Зигмунд Фрейд. Понимание бессознательного — как общий фундамент. Как практическое применение — тема про защитные механизмы личности. Зная их, общение с людьми становится гораздо более понятным и продуктивным. Как вместо двухмерного изображения видеть трёхмерное.
Карл Роджерс. О нём как-то мало сейчас говорят, но он на том же уровне, что и Фрейд. Основная тема Роджерса — личностный рост, но не как отдельная личность, а через жизнь в группе. Основная работа на русском названа «Групповая психотерапия». Пусть не пугает слово «психотерапия» — это трудности перевода. На английском книга называется «Группа встреч», когда люди собираются и обсуждают какие-то вопросы. Очень большой, просто огромный объём материала о динамике развития группы: как она складывается, как развивается, какие происходят конфликты и как во всём этом котле событий происходит развитие личности человека. Это не методичка с бодрыми советами, это наблюдения и анализ. Но такого количества материала и глубины изложения у других авторов просто не найти. И если вы видите в фильмах группы людей, сидящих в кругу, это вот всё оттуда, от Роджерса. Это просто must have для руководителя, но нужна определённая работа, чтобы это переварить и перевести на язык своего бизнеса.
Роджер Фишер и Уильям Юри. Книга «Путь к согласию, или Переговоры без поражения». Бодрая американская инструкция, как разрешать конфликты и вести переговоры. Очень много ценных моментов. Описание технологии, основанной не на «позициях», а на «принципах». Здесь же своя техника «активного слушания». Тот случай, когда психология не называется психологией. 100%-й must have для бизнеса. Читать только первоисточник, пересказы сводят всё к банальностям.
Дополнительно:
«Язык телодвижений» — известная книга Аллана Пиза. Легко читается. Суперсила не появится, но помогает лучше понимать поведение людей.
Упоминавшаяся ранее социометрия Джейкоба Морено. Если у Роджерса о динамике группы, то у Морено — о структуре. Читается трудновато, но есть определённая ценность для развития общего кругозора. Поскольку он практически раньше всех (до него рассматривали только большие группы — толпа, классы, нации) пришёл к малым группам, ролям человека в группах, социальным сетям. И даже придумал психодраму (иногда называют социодрамой), т. е. психологический театр с проигрыванием реальных историй об отношениях между людьми в семье, на работе, в школе и т. д.
Технология НЛП (Нейролингвистическое программирование). Создатели позиционируют её как те��нологию общения для бизнеса. Есть некоторые интересные моменты (многие слышали про то, в какую сторону двигаются глаза, когда человек говорит правду или врёт), но в целом очередная бодренькая американская методичка.
Надо сказать, что в психологии очень много информации об отдельном человеке и гораздо меньше — о группах. В этом списке как раз немного это исправляется и показываются темы именно взаимодействия между людьми, либо те личностные свойства, которые влияют на общение.
И надо, конечно, упомянуть некоторые довольно экзотические направления в современной психологии. Например, телесно-ориентированная психология, трансперсональная, изменённые состояния сознания, холотропное дыхание и др. Они полезны главным образом для личностного самоисследования и саморазвития.