Переставляя кровати
«Если лень работать — скажи, что надо всё поменять» © (только что придумал).
«Когда в борделе продажи падают, надо работниц менять, а не кровати переставлять» © (какой-то анекдот).
Ну всё, хватит цитат и умстований. Расскажу, как переставляли кровати на одном милом и уютном предприятии. Их прям хлебом кормить не надо было, дай только кроватки подвигать.
Снабжение
На предприятии, сколько оно существовало, была проблема со снабжением. Суть её была очень проста: чуваки-закупщики плохо работали. Надо заказать сегодня — они протянут неделю. Проще и дешевле купить в соседнем городе — они закажут на Дальнем Востоке. Требуется сто втулок, они обязательно закажут или десять, или тысячу.
Все знали, в чём суть проблемы — и снабженцы, и продавцы, и производство, и руководство. Но как-то… Нельзя же прийти и дать людям по башке? Всё надо делать по-умному. С помощью организационных изменений.
Любимое дело руководителей на деревенских заводах — изменения организационной структуры предприятия. Но наши герои решили, что это слишком трудоёмко — рисовать и утверждать новую структуру, оформлять кадровые перемещения, переделывать кучу бумажек вроде процессов и положений об отделах.
Поэтому решили просто поменять названия отделов на вывесках. Эдакая лайт-реструктуризация. Придумали названия, распечатали на обычных листах А4, открутили старые таблички и превратили коридоры заводоуправления в собес. «Отдел снабжения» стал «Отделом логистики», «Отдел продаж» — «Клиентским отделом» и т.д.
Посидели, подождали — нет, не работает. Нужно всё поменять.
Не исключено, что дальше поучаствовал программист, т.к. изменить решили «метаданные организационной структуры» — в названии «Отдел снабжения» надо менять не слово «снабжение», а слово «отдел». И понеслась забавная чехарда.
Сначала самое простое выбрали — «служба». И звучит солиднее, и вроде как намекает, что служить надо. Где-то годик были службы, но не сработало. Тогда решили, что нечего тут совок разводить — отделы, службы, нужно радикальное решение. Пусть будут департаменты.
Департамент — это уже красиво, по-западному. Переделали орг.структуру, сели ждать. Блин, опять не работает. Нужно что-то еще более крутое и вдохновляющее. Решили, что будут дивизионы. «Дивизион снабжения» — как звучит, а? Прям готовое название для нового фильма Кристофера Нолана.
Но, увы, и это не помогло. Однако, надежда зажглась вновь: вылез на свет божий умник, который сказал — у вас названия разделяющие, а нужны объединяющие. Например, «отдел» — от слова «делить», «департамент» — от английского «part» (часть), а «дивизион» — в чистом виде деление («division»). Наверное, это тоже был программист.
Решили — хватит делиться. Пусть будут «команды». Но быстро передумали — стало стыдно перед внешним миром. Представьте — приезжает клиент на переговоры, его встречает человек и говорит: «Я — Вася, из команды продаж». В деревне таких не любят.
Поняли, что не работает подход. Нужно всё поменять.
Теперь уже пошла серьёзная реорганизация. Начали переставлять людей и менять конфигурацию отделов. Снабженцев было человек пять, и остро встал вопрос — по какому признаку их поделить? Пришёл умный чувак и сказал — сейчас в моде т.н. «категорийный закуп». Типа Вася отвечает за категорию «Литьё и поковки», Гена за «Метизы», а Валя — за «Металлопрокат (в т.ч. листовой)» и т.д. Так и поделили. На пять отделов.
Сразу, конечно, обозначили, что каждый отдел будет расти, там появится начальник, свой кабинет и т.д. Ну, чтобы люди не переживали. Однако, к счастью, эксперимент продлился недолго — лишь несколько месяцев.
Поняли, что не работает, и надо всё менять.
Поделили по другому признаку — серийная и заказная номенклатура. Серийная — это всё, что производится разными заводами и можно купить в любой момент. Заказная, соответственно — то, что на складе не лежит, и надо заказывать заранее.
Подвели теоретическое обоснование — прочитали статью Эрика Триста, как он делением и перестановкой шахты в порядок приводил. Сейчас всё точно было по уму — люди поделены по принципиальной разнице в энергетической структуре ежедневной деятельности. Что бы это ни значило.
Однако, не помогло. Поняли, что надо всё менять.
Тут кто-то прочитал книжку про бизнес-единицы. Решили, что у нас, конечно, тоже должны быть бизнес-единицы, матричное управление, а еще лучше — проектное. Но это в отдалённой перспективе.
Бизнес-единица внутри завода — это когда садят в один отдел пару продавцов, пару снабженцев и, допустим, инженера-конструктора. Получается маленькая команда, внутри которой нет границ, препятствий, бюрократии и т.д. Каждая бизнес-единица занимается чем-то своим — или продуктом, или регионом, или клиентурой. Тут поделили по продуктовому признаку.
А всех «непонятно кого» садят в т.н. Корпоративный Центр, он же КЦ. Бухгалтерия, программисты, экономисты, юристы и т.д. Ну и соответственно КЦ состоит «на службе» у бизнес-единиц, оказывая им услуги. Примерно, как государство состоит на службе у граждан и бизнеса.
В общем, рассадили трех снабженцев по бизнес-единицам, двоих оставили в корпоративном центре — на закуп «общей номенклатуры». В каждой бизнес-единице назначили начальника. И, как назло, все начальники были из продавцов. Тех самых, которые на протяжении всей истории существования компании сталкивались с проблемой Дяди Фёдора — чтобы что-то продать, надо это купить. А кто у нас покупал не то и не тогда, мы с вами уже знаем.
Внутри бизнес-единицы, накоротке, старые приёмчики снабженцев действовать перестали. Начальник-продавец говорил чётко, что надо купить, в каком количестве, и когда. А снабженец так не умеет, у него что-то вроде дислексии подчинения. Взвыли парни в бизнес-единицах.
А у тех, что остались в КЦ, всё было по-прежнему — уютно и спокойно. Ну и, после пары месяцев мучений, парни из бизнес-единиц тоже попросились в КЦ. Подвели какое-то обоснование даже — мол, закуп должен быть централизованным, это современный тренд, нечего дублировать функции. Привели пример — один поставщик получает заказы от разных бизнес-единиц, и отгружает по завышенной цене из-за малых размеров партий. Идею отмазки взяли с MBA, на котором тогда учился самый главный снабженец.
Ну и чего делать? Перевели всех снабженцев в КЦ. Потом конструкторов. В бизнес-единицах остались одни продавцы. Весь смысл потерялся, и вернулись в исходную стадию эксперимента — просто отделы. Правда, продолжать эксперимент не стали. Просто смирились и потерялись в кризис.
Айтишники
Параллельно существовали айтишники — программисты и системные администраторы. Поначалу они как-то работали — ну, как попало, безо всяких таск-менеджеров и ITIL«ов. Работали откровенно плохо, ровно так, как принято на заводах — до уровня «чтоб не уволили».
Поглядев на снабженцев и перестановку их кроватей, поняли — вот оно! Хватит выслушивать, какие айтишники плохие, нужно всё поменять.
Решили так — нечего нам, айтишникам, звонить по телефону и орать, что не работает принтер, не формируется отчет или не приходит заявка с сайта. Хотите, чтобы айтишник что-то сделал — пишите служебную записку. Теперь у нас всё будет серьёзно.
Пошли к директору и обосновали изменения. Спорить было трудно — дело ведь именно в отсутствии записей и согласования, а никак не в плохой работе айтишников. Директор, зная и искренне любя стандарт ISO 9001, который утверждает «по процессу всегда должны вестись записи», подход одобрил.
Естественно, сразу прошла индульгенция — все текущие задачи забылись, протухшая просрочка вновь стала свежатиной. Если кто-то хочет, чтобы выполнилась его старая задача, пусть пишет служебку.
Люди не дураки, и с радостью начали клепать служебные записки. Айтишникам пришлось вытащить из серверной старый пыльный стол, чтобы складывать на него тонны бумаги — в ящики столов уже давно ничего не помещалось. Однако, крики и ругань на тему «айтишники работают, как в штаны навалили» поднялись с новой силой.
Ок, объявили айтишники, проблема есть, надо всё поменять. Корень проблемы в том, что служебки — бумажные. Тупо не понятно, что и когда надо делать, и как всё это контролировать.
Решение? Автоматизировать служебные записки! Погибли сразу два зайца — айтишники получили две индульгенции. Во-первых, автоматизацию надо сначала сделать –, а это, «вы понимаете», не так просто. Система должна быть гибкой, настраиваемой, удобной и прозрачной. Во-вторых, служебки уже можно не выполнять. А в системе задач нет, потому что еще нет системы.
С разработкой системы провозились полгода. С фанфарами запустили, с треском провалились. Еще полгода исправляли косяки. Народ кипел — не получалось в системе оформить служебку на доработку системы служебок.
К тому моменту, когда система нормально заработала, уже было понятно, что её надо менять. Айтишники, на всякий случай, посыпали голову пеплом, и сказали — не надо было разрабатывать систему. Надо использовать готовую, коих миллион. В этом проблема, а не в том, что айтишники плохо работают. Надо всё поменять.
Взяли паузу на поиск готового решения. Месяца через три выбрали Битрикс — самую дешевую коробку для развёртывания корпоративного портала. Еще месяца три разворачивали и настраивали. Хотя тут, пожалуй, соглашусь: не айтишники виноваты. Три месяца на разворачивание коробки Битрикса и приведение его в работоспособное состояние — это еще по-божески.
Всё это время жили, как попало. Кто-то толкал служебки в прежнюю систему, некоторые печатали, а самые наглые по старинке звонили и орали.
Когда корпоративный портал на Битриксе заработал, история повторилась. Завал задач, который успел пожить в головах, на пыльном столе, в автоматизированной системе, дружно переехал в знаменитый «гибкий адаптивный интерфейс».
С «гибкостью» и «адаптивностью» ковырялись где-то полгода. По дороге поняли, что у пыльного стола и служебок гибкости-то побольше будет. Особенно помогало то, что среди айтишников никто не знал PHP, поэтому тыкались в формы настройки только мышкой. Никто особо не торопился, ведь пока «осуществляется настройка и внедрение системы» — решать текущие задачи не особо нужно.
Плюнули на Битрикс где-то в момент «так и не получилось настроить уведомления в почту, похоже ошибка в платформе». Поняли, что система не подходит для производственных предприятий. Надо что-то менять, радикально.
Взяли месяцок на анализ ситуации. Кто-то сказал айтишникам про скрам: доска, стикеры, гибкость, никаких компьютерных систем. Таким макаром кровати они еще не переставляли. Почему-то решили попробовать скрам. Меняться ведь надо радикально.
Тут же столкнулись с проблемой — скрам запускается за один день. Стикеры есть, маркеры тоже, а белая доска из переговорки давно валяется в серверной. Вытащили, повесили, и погнали. В смысле сели и стали ждать задач.
Вбежал первый орущий, изложил задачу, записали на стикер, повесили на доску. Как ни странно, сразу пошли делать. Пока ходили, прибежали еще пара человек — с них тоже сняли задачи, записали и наклеили. Время было к обеду, собрались вместе и пошли кушать.
Когда вернулись, то чуть не упали: вся доска была в стикерах — желтые, розовые, белые, синие. Кто-то прилепил на магнит листок А4 с распечатанной служебкой. Несколько стикеров валялось на полу, под доской, со следами подошв.
Обед был у всего завода, поэтому решили так: не видел — значит не было. Сняли все стикеры и бумажки, сбегали в курилку, бросили в урну и сожгли. Оставшиеся полдня скандалили с двумя категориями граждан: одни орали «где мой розовый стикер?», другие — «дайте налеплю!». До утра скрам не дожил.
Совместно было принято решение, что скрам не подходит для производственных предприятий. Это — развлечение для хипстерских стартапов, в которых люди только щёки надувают, а работать не хотят, вот и выдумывают себе приключения со стикерами. Мы — люди серьёзные, нам нужна Система.
Перебрали Issues в GitHub (?!), Jira, 1С: Документооборот, какой-то продукт по ITIL, задачи в аутлуке, Битрикс24, Trello, Яндекс.Трекер, Канбан (с забором вокруг доски), еще одну свою систему сваяли.
В общем, испробовали множество вариантов расстановки кроватей. Манипуляции эти заняли несколько лет, по одному и тому же алгоритму. Признаем, что старая система или методика не годятся. Надо всё поменять. Берем время на анализ рынка и подбор новой системы. Потом — на её внедрение и настройку. Учим пользователей. Запускам. Получаем тот же вал задач, который быстро краснеет. Возвращаемся к исходной стадии.
А работали по-прежнему — до уровня, чтоб не уволили.
Директор
Ну и напоследок еще один любитель переставлять кровати — директор. Его любимой стезёй были системы оплаты и мотивации.
Говоря по-простому, проблемой было то, что директор мало платил — всем, включая своих заместителей. Но он вовремя понял ключевую стратегию, которую я слышал много раз, начиная с 2006 года, на деревенских заводах. Сейчас кратко изложу, только своему директору не показывайте.
Надо постоянно менять систему оплаты. Цель — платить меньше. Но людям должно казаться, что они стали получать больше.
Делается очень просто — через систему премирования, грейдов или, лучше всего, KPI (КПЭ).
В самом начале были оклады, у некоторых, вроде продавцов — премии. Директор через некоторое время попал в неприятную ситуацию. С одной стороны, оклады давно не менялись, и люди стали роптать, травить байки про «компании, в которых каждый год индексируют». С другой стороны, его и текущий ФОТ уже напрягал — хотелось уменьшить.
Ну он и решил всё поменять. Сделал всем КПЭ, от зам.директора до уборщицы. Зарплата поделилась на окладную часть (примерно половина от предыдущего оклада), и премию по результатам работы. Естественно, железное правило внедрения новой системы КПЭ было соблюдено: она позволяла, чисто теоретически, получать больше, где-то на 30%.
Эту цифру (30%) директор постоянно озвучивал: я, такой хороший, увеличил вам зарплату на 30%, а вы не хотите работать. По факту, конечно, люди стали получать в районе 70% от предыдущего уровня дохода. Но докопаться было нельзя.
Недоволен, что мало получаешь? Так ты не получать, а зарабатывать пришел. Вот и зарабатывай. Я, директор, не могу за тебя работать, я создаю возможности, условия и перспективы. Работай и радуйся.
Люди постепенно приноровились к противоестественным показателям, вроде «Отсутствие замечаний по чистоте в местах общего пользования», как-то договорились — перестали друг другу жизнь портить, и с горем пополам вышли на прежний уровень дохода.
Директор это заметил, и решил всё поменять. Сильно возиться было лень, поэтому просто придумал другие показатели, не меняя принципиально всю систему. ФОТ опять снизился, и какое-то время директор жил спокойно.
Когда люди научились за один месяц переучиваться на новые показатели, директору пришлось поднапрячься, придумать и внедрить систему грейдов. Теперь снова был оклад, но его размер зависел от грейда — это типа категории специалиста. Естественно, на старте системы всем был присвоен низший грейд — прошлые заслуги не учитывались. Менять — так менять.
Если следовать стратегии директора, то главное при внедрении грейдов — сделать алгоритм повышения уровня максимально сложным и непонятным. Что надо делать, как готовиться, какие результаты показать, кому экзамен сдать, куда шоколадку принести — ничего известно не было. Директор сказал — посмотрим 2–3 месяца, как пойдёт внедрение системы, и решим.
Через полгода нанял девочку лично себе в подчинение, назвал её «Менеджер по квалификациям», велел придумать алгоритм повышения грейдов и исполнять его. Не то чтобы велел — скорее предложил, или рекомендовал. Чтобы не особо торопилась.
К моменту, когда алгоритм был готов, директор опять решил, что надо всё поменять. Снова заскрипели ножки кроватей по старым истерзанным половицам. На этот раз — в сторону хозрасчёта.
P.S.
Не исключаю, все проблемы предприятия, и конкретно — снабженцев и программистов, были вызваны любовью директора к перестановке кроватей. Вы как думаете?
