Комментарии 95
отчеты с совершенно бесполезной и часто оторванной от жизни информацие
Можно хотя бы поверхностно описать пример бесполезной информации от консалтинговых компаний?
Я видел обратные примеры, когда метрики снимали хорошие, рекомендации давали правильные, но топ менеджмент в силу недостатка знаний не понимал и не принимал изменения.
— Внедрение IoT
— Внедрение дронов
— Внедрение машинного обучения
Для каждого пункта с ведро воды пояснений, из которого нельзя выцедить ничего, кроме того, что можно почитать в Википедии. Конкретики — что именно они рекомендуют, какие кейсы покрывают эти технологии и какую пользу это принесет бизнесу нет.
Были конечно и конкретные рекоментации по улучшению бизнес процесса. Но главного — обоснования почему так не было. На такие вопросы у них один стандартный ответ — это наше экспертное мнение.
и поставить одного директора по фигне. То есть по развитию
чую, это если и сработает, то ненадолго.
любая активность в конторах требует внимания и на поддержку существующего, и на развитие.
и HR, и логистика, и оффлайн-ритейл, и онлайн-ритейл, и ит, и т.д. — все должны и прямо сейчас работать как часы, и одновременно перестраиваться под будущее.
Тот же пиар — он, в целом, как коммерческий инструмент нафиг никому отдельному в компании не нужен, потому что работает множителем.… Но оценить его шаманский эффект сложно, поэтому он выносится на уровень подчинения генерирующему прибыль модулю CEO (в нашем случае) и сидит там как стратегический ресурс.
Пиар то понятно что можно вынести.
А вот скажем оффлайн-ритейл. Как без человека, которые прямо сейчас отвечает за оффлайн-ритейл, можно думать и развивать завтрашний оффлайн-ритейл?
Понятно, что конфликт тактика-стратегия вечный. Но и вариант, поделить тактику и стратегию по разным людям, тоже не панацея.
А про начало — это вопрос лимита управляемости.
Хотя может быть это и прямо сейчас присутствует (или планируется), возможно неявно. Когда у конкретного ответственного две руки, правая отвечает за текущее состояние, левая — за change.
Когда у конкретного ответственного две руки, правая отвечает за текущее состояние, левая — за change.В результате и то и другое сделано отвратительно. Если не удаётся найти людей, которым нравится тактика и стратегия (чтобы посадить их на эти роли «на постоянку») — можно периодически меняться ролями, но устраивать постоянный внутренний конфликт внутри человека — это садизм.
P.S. Видимо это касается любого проекта, где есть долгосрочное развитие, а не бесконечный цикл «в беличьем колесе».
Например, мы уже поняли, что ИТ-отделов в компании должно быть два: тактический и стратегический. Тактический — это хелпдеск, железнячники, отслеживание ресурсов и лицензий, мониторинг и вообще всё то, что повторяется больше 2 раз. Стратегический — это реализация major-фич, планирование на 2-3 года вперёд и финансы.
Ну развитие телефонии и сайта, понятно, стратегическое направление.
А вот скажем, автоматизация в HR, бухгалтерии — тактика?
С этой колокольни запуск какого-нибудь документооборота для hr, бухгалтерии может бы ть и облегчит жизнь последних, но если это не почувствует основной бизнес — тогда резонный вопрос, а зачем внедряться.
То что неочевидно помогает основному бизнесу, но польза видится в рамках поддерживающей активности, оплачивается самой активностью. У активности (HR, бухгалтерия, ИТ и пр.) есть свои бюджеты для этого. Они, понятно, меньше бюджета развития основного бизнеса.
Предусмотрены ли какие-нибудь формальные методы противодействия ситуациям «эти проектанты из развития напроектировали и дальше пошли, а нам теперь со всей этой фигнёй взлетать»?
И это, мы этот уровень до конца не прошли, если что.
про риск того, что тот кто отвечает за развитие, что-то задумал, и это плохо соотносится с тем что есть «в поле», задуманное не взлетает
Я больше не ваш клиент, раз мои любимые игры уже до меня доставлены? Разве что одну (не вашу) сам доставил до друга на ДР, а теперь локти кусаю…
Как-то у вас все очень технично...
Могли бы, например, определять иногда стратегию развития, бросая руны. Или вести дерево навыков, давать ачивки, прокачивать бухгалтера до 80 уровня...
Еще свежа у меня душевная травма, когда я работая в одной компании по доброте душевной помог соседнему отделу, а потом ухх как меня дрючить за это начали. Потому что я, негодяй такой, потратил бюджет своего отдела (зарплату за потраченное время) на помощь другому, который, как оказалось, хоть и сидит в соседней комнате (и первое время я в нем и работал), но со вторым никак не связан юридически. И все должно было производиться через взаиморасчеты между их бюджетами и начальниками. В итоге попал как между молотом и наковальней.
То есть с моей точки зрения это выглядело как «трачу деньги компании чтобы сделать работу на благо компании, только в другом отделе в соседней комнате», а с точки зрения начальства это выглядело как «трачу их деньги на помощь посторонним людям»
При этом ходить на ковер и выбивать деньги на автоматизацию и дополнительные ресурсы никто не хочет, зато хотят, чтобы и дальше делали за них.
В больших компаниях все иначе. Большая компания — огромный и сложный механизм. Менеджмент годами налаживает процессы, чтоб на долгосрочных активностях получать от функциональных команд предсказуемый результат. И тут появляется альтруист, который делает что-то в обход процессов. Любое однократное нарушение процесса, если оно удобно всем участвующим, становится постоянным.
От одного раза ничего не случится. От повторения одного раза на протяжении года, может как сильно испортиться результат, так и сильно улучшиться. С испорченным результатом и так понятно. А вот видимое «лучше» — не всегда действительно «лучше». С позиции работника тяжело оценить реальную цену вашего поступка. Например, если вы нажали на педаль газа, а машина поехала быстрее, чем вы ожидали. На прямом участке дороги это хорошо — быстрее доедете. В городе на поворотах плохо — не успеете вовремя остановиться. С позиции педали газа, ей должно казаться, что она эффективнее других педалей и вообще очень помогла автомобилю.
Как вам будет ездиться на машине, которые сама без вашего ведома оптимизирует процессы внутри? Непредсказуемо тормозит сильнее чем нужно, разгоняется быстрее чем ожидаете, колеса и руль поворачиваются асинхронно. Сможете соревноваться на такой машине с другими? Вряд ли, даже если в отдельных показателях ваша машина будет лучше других. Бизнес гораздо сложнее автомобильных гонок.
Так я вас разочарует: подобное «резанье костов» без «горизонтальной помощи» приводит к краху ещё быстрее.
P.S. И скорее помогал не отделу, а конкретному человеку. Кто-то другой обратился бы, скорее сказал бы «пиши заявку на разработку нового отчёта», а не сделал бы сам отчёт.
Каждое подразделение было отдельным княжеством, и вмешательство в дела другого подразделения считалось недопустимым на всех уровнях иерархии. Когда руководитель одного департамента обратил внимание, что многочисленные слои краски на потолке нарушают пожарную безопасность, то услышал в ответ «занимайтесь своими делами, и никто не будет вам мешать»
То есть альтруисту, решившего действовать в обход процесса (на самом деле активному человеку, думающего не об отделе, а о компании) приказали сидеть ровно и не рыпаться.
В итоге строгая иерархичность и изоляция департаментов привели к масштабной трагедии. По результатам расследования, топ-менеджмент был уволен, а вся структура компании переделана.
Также замечу, что Сергей в своем посте рассказывает о пользе горизонтальных связей и распределении центров принятия решения. И не как о собственных открытиях, а как о best-practices. Это делается в том числе для более гибкой структуры и быстром «апгрейде» процессов — полная противоположность того, что вы написали.
И да, Мосигра — это не «маленькая компания».
То есть альтруисту, решившего действовать в обход процесса (на самом деле активному человеку, думающего не об отделе, а о компании)
Это разное. Одно дело активно влиять на процессы в рамках вашей функциональной команды, другое — без предупреждения лезть в процессы других команд. Благими намерениями сами знаете куда дорога вымощена. Или, думаете, альтруисты думающие о благе компании, не могут совершать фатальных ошибок?
приказали сидеть ровно и не рыпаться
Это совсем не то, о чем я писал выше. Компании, где все сидят ровно и не рыпаются, обычно представляют из себя старое неэффективное бюрократизированное болото, и если еще не разорились, то обычно это вопрос времени.
Я писал о том, что все внутри компании должны поддерживать налаженные процессы и
стараться действовать в их рамках. Потому что тот, кто эти процессы создавал, возможно, представляет себе картину в целом гораздо лучше. Потому что ваша искренняя помощь кому-то может на самом деле маскировать проблемы в другом отделе. Помощь может оказаться очередной таблеткой обезболивающего, когда зуб уже давно пора лечить.
Помогать нужно, но в рамках процессов. То есть, если возникают необходимость и есть возможность, сначала нужно уведомить руководителя, согласовать решение, и потом с чистой совестью помогать. Если ваша помощь не мешает, то никто вам не запретит работать на благо компании. И сотрудники довольны, и процессы целы.
Также замечу, что Сергей в своем посте рассказывает о пользе горизонтальных связей и распределении центров принятия решения. И не как о собственных открытиях, а как о best-practices. Это делается в том числе для более гибкой структуры и быстром «апгрейде» процессов — полная противоположность того, что вы написали.
Ничего подобного. Горизонтальные связи и распределенные центры принятия решений требуют такого же точно контроля за процессами внутри. Почему-то у многих гибкость ассоциируется с уменьшением контроля. Как раз горизонтальные связи требуют еще больше контроля и хорошо прописанных процессов. Матричная структура может дать гораздо большую производительность и сократить расходы, если процессы хорошо наладить — роли прописаны и строго соблюдаются. Любое нарушение правил обходится компании дорого. Простую функциональную структуру с классической пирамидой в основе гораздо удобнее контролировать, требования к соблюдению правил процессов более мягкие. Для гибкости, при сохранении эффективности, увы, нужен повышенный контроль.
Любое нарушение правил обходится компании дорого.Нет, т.к. правило может быть устаревшим. Опыт с обезьянами, не берущими банан вам знаком?
В книге правилам и обычаям в организациях посвящено несколько глав, а я пересказал полглавы с одним разбором в одном абзаце. Я опустил много чего. Ограничусь выводом: часто, но не всегда, следование правилам/обычаям обходится компании слишком дорого.
Я рекомендую прочитать книгу Дахигга там приводится статистика сколько правил по умолчанию складываются случайным образом, без весомых причин.
Компании, где все сидят ровно и не рыпаются, обычно представляют из себя старое неэффективное бюрократизированное болото
Но ведь в бюрократическом болоте процессы как раз сохраняются! Бюрократией мы обычно называем ситуацию, когда нелогичных, но устоявшихся процессов сильно больше, чем нужно для результата.
Я писал о том, что все внутри компании должны поддерживать налаженные процессы и стараться действовать в их рамкахВозможно, я не правильно вас понял, но увидел призыв безусловно сохранять процессы.
Моя критика — к призывам не менять процессы. Пример, когда процессы менять надо было, выше. Полагаю, вы тоже знаете такие примеры.
Обычаи (негласные процессы) приходится менять, преодолевая сопротивление и ломая упорство несогласных.
Имхо, изменения имеют право идти не только сверху, но и снизу (от рядового альтруиста), и сбоку (от конкурента/контрагента/приглашенного эксперта). При этом да, должен найтись кто-то с полномочиями, кто возьмет на себя ответственность за изменения. Но это второй этап. Сначала нужен вектор на изменения.
Чем критичнее ситуация, тем меньше внимания стоит уделять сохранению статус-кво. Банальный пример: нельзя обращаться напрямую к
Горизонтальные связи и распределенные центры принятия решений требуют такого же точно контроля за процессами внутриЯ говорю только про «сохранение процессов». Про контроль у меня нет ни знаний, ни опыта, поэтому не могу ничего сказать.
Milfgard, вы не могли бы прокомментировать:
1. Нужен ли больший контроль при наличии горизонтальных связей?
2. Необходимы ли хорошо прописанные процессы при наличии горизонтальных связей?
3. Нужен ли повышенный контроль «для гибкости, при сохранении эффективности»?
Я хочу подчеркнуть, что человек из моей цитаты увидел брак, плохую работу в соседнем отделе другого департамента. А текущий процесс был не вмешиваться в дела другого департамента (как вы и предлагаете).
Увидел брак — сообщи своему начальнику, согласуй, совместно сообщите другому департаменту и топам, получите фидбек. Не идти напрямую в другой отдел и помогать ему делать правильно. Рассмотрение жалоб, предложений и тд вышестоящим начальством — нормальный процесс в любой адекватной компании. То что в цитате — плохо отлаженный процесс. Если на проблемы в другом отделе нельзя никак указать топ менеджменту, то тут все печально в управлением в целом.
Нет, т.к. правило может быть устаревшим. Опыт с обезьянами, не берущими банан вам знаком?
Внимание вопрос: как реагировать на устаревшее правило, которое мешает? Молча его нарушать, помогая другим, или согласовать эту помощь с руководством, чтоб все были в курсе проблемы, разобрались с ее причинами, решили, нужна ли там помощь, одобрили ваше решение помочь, приняли меры по речению причин проблемы. О каком варианте писал я выше?
Ограничусь выводом: часто, но не всегда, следование правилам/обычаям обходится компании слишком дорого.
Уже вижу инженеров NASA, пилотов гражданских рейсов и хирургов в больницах скипающих чеклисты (кому нужны эти правила?).
Моя критика — к призывам не менять процессы.
Где я призываю не менять процессы? Как раз менять надо именно процессы. И инициирование изменений в эти процессы должно идти как сверху, так и снизу. Но не путем нарушение правил, а согласованно, через руководителей. Видите проблему — сообщите. И это, внимание, тоже процесс. Процессы можно менять, но их нельзя игнорировать. Если правила установлены, то их нужно соблюдать. Если правила мешают делать работу эффективно, их все равно нельзя нарушать. Потому что нарушение этих правил может помочь вам, но навредить другим. Например, правила дорожного движения — каким бы неудобным не был светофор на перекрестке, если вы его проигнорируете, то можете помешать другим. С позиции стоящего на красный свет, светофор — вселенское зло, а правило, запрещающее проезд на красный — неэффективное.
Банальный пример: нельзя обращаться напрямую кгенералутоп-руководству с предложениями. Только по цепочке. А если пожар? Или генерал пошел на минное поле? Искать полковника или нарушать процесс?
Давайте посчитаем. Например у вашего руководителя таких как вы примерно 10. Он может вас или другого члена команды выслушать в любое время. Таких как ваш руководитель у вашего директора тоже, к примеру, 10. Он может слушать ваших руководителей когда угодно. Но если все ваши сотрудники напрямую начнут обращаться к директору, он будет за день успевать слушать примерно треть. В лучшем случае. Если не будет заниматься остальной работой, ездить на встречи, согласовывать решения. Это неэффективно. Для такого придумали опытных руководителей, которые пропускают через призму своего опыта и компетенции ваши предложения, и если они удачные, доносят их вышестоящим.
Для критических ситуаций есть свои процедуры — сообщаете руководителю, если его нет — заму, нет зама — вышестоящим, если никого нет — берете ответственность на себя.
В конце концов для коллектива с хорошо налаженными процессами, можно допустить прямое обращение к любому руководству. И строгие правила помогут эти обращения сделать действительно эффективными.
То что в цитате — плохо отлаженный процесс.Видимо, я недостаточно акцентировал факт, что человек, говоривший о проблеме с краской — руководитель департамента, топ-менеджер, который говорит на совещании топ-менеджеров о проблеме. Проблема уже дошла до верха, но не получила решения, т.к. процесс менять никто не хотел.
Впрочем, это неважно в свете
Как раз менять надо именно процессы. И инициирование изменений в эти процессы должно идти как сверху, так и снизуЗначит я неверно понял ваш первый пост. Я именно в этом и хотел вас убедить :)
Ситуация там еще осложнялась тем, что я не просто помог какому-то отделу, а доделал часть работы для старого отдела после перехода в новый. Старый частично расформировали и сократили, но какая-то поддержка проекта там осталась. Меня перевели в другой отдел, но какое-то время что-то по мелочи по старой памяти я фиксил в старом в свободное время. А потом оказался виноват.
Особенно если никто этого не объяснил и не предупредил.
А это уже другая проблема — менеджмент, который должен был бы грамотно описать обязанности, очертить границу ответственности, установить правила. А когда проблемы возникла, не душевную травму вам оставлять, а спокойно объяснить, что было не так, как именно нужно было сделать, помочь разобраться в процессах, поблагодарить за инициативу, отметить вас, как перспективного сотрудника. В теории :)
Если «на благо гуглу» — это уже обычная работа. Вся идея состоит в том, чтобы люди попробовали что-то интересное. Может оказаться, что никто не ожидал, а из этого что-то офигенное появилось.
В одной из железячных компаний делают что попало — манипуляторы для NASA, системы активного шумоподавления для офисного туалета (чтобы смыва не было слышно) и т.д.
Штук пять у них ушло в крутейшее IP, остальное — так, игрушки. Но эти пять штук никто бы не придумал «на благо компании». Их придумали только потому, что прикольно.
директора по фигне. То есть по развитию.Скажите, а ваш директор по развитию не обижается, что вы уравняли развитие и фигню? ;-)
Директор по маркетингу в широком понимании это и есть директор по развитию. Во многих компаниях, к сожалению, заветы Котлера редуцированы до маркетинговых коммуникация. Могу ошибаться, но в "директор по фигне" чувствуется самоирония. Операционные блоки зачастую так и думают про соответствующих людей, а ГД имеют тенденцию подтрунивать над сим фактом...
Судя по посту, организационная структура меняется и непонятно, старое описание это баг или фича. Я рассчитывал на комментарий Сергея, но это чистое любопытство.
Или круче, запись в трудовой! Такого человека в будущем будут звать на собеседования только чтобы услышать эту историю! А история будет наравне с епископом — Senjor Developer
У нас в компании тоже сейчас активно меняют оргструктуру по рекомендациям Адизеса. Всё очень похоже :) Красные/жёлтые/зелёные, стратегия/тактика.
Но вот с IT сложнее.
Это по умолчанию operations для вас (т.е. IT не занимается разработкой продукта), поэтому, кмк, мало смысла делить его на прям разные отделы. Точнее не так — отделы могут быть разные (а-ля эксплуатация/развитие), но должны быть под одним CIO.
Сравнивать очень просто: известна цена за единицу игры нашего производства, известны критерии качества и SLA. Если кто-то делает дешевле при том же качестве и SLA — очевидно, все вызовы к производству могут переадресоваться на этот другой микросервис. Просто заменяется модуль в архитектуре.
Такой подход ещё Генри Форд использовал.
А теперь он, значит, называется «микросервисами» :)
И кстати, не планируете провести оффлайновые встречи с рассказами, как до такой жизни докатились? и опять таки, заработок… возможно, рассказывать о том, как делать игры, будет выгоднее, чем делать игры! ;)
Как у нас не получилось переделать архитектуру компании