Size: a a a

Архитектура ИТ-решений

2020 August 23

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Daria Kaftan
Имхо, управляемый хаос - это порядок, структурированный неформально и неочевидно. Как только способ управления становится формализованным и прозрачным, это перестает быть хаосом.
+
источник

AN

Andrew Nilove 💔 in Архитектура ИТ-решений
Gennadiy Kruglov
Орг структуру можно скопировать у Spotify, а менталитет, дух компании - нет. Ту самую культуру, про которую нельзя говорить.

И не нужно путать хаос с бардаком.
Соррян конечно за оффтоп чата. Бардак и так убьет бизнес-структуру. Больше интересует как создать систему, которая убьет конкурента в большой долей вероятности (систему с управляемым хаосом), но так чтобы топ-менеджеры не поняли этого на начальных этапах. А когда механизм будет запущен, то должно быть поздно.
источник

DS

Daniyar S in Архитектура ИТ-решений
Andrew Nilove 💔
Соррян конечно за оффтоп чата. Бардак и так убьет бизнес-структуру. Больше интересует как создать систему, которая убьет конкурента в большой долей вероятности (систему с управляемым хаосом), но так чтобы топ-менеджеры не поняли этого на начальных этапах. А когда механизм будет запущен, то должно быть поздно.
Отдайте конкуренту своих "лучших людей", и ждите.
источник

AN

Andrew Nilove 💔 in Архитектура ИТ-решений
Daniyar S
Отдайте конкуренту своих "лучших людей", и ждите.
Уже наблюдал такое, когда 200 человек менеджмента перетекло из X5 в Магнит. Однако система имеет свойство самоочищаться, и их участь была предрешена. В итоге все же Магнит потерял свое стратегическое преимущество.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Andrew Nilove 💔
Соррян конечно за оффтоп чата. Бардак и так убьет бизнес-структуру. Больше интересует как создать систему, которая убьет конкурента в большой долей вероятности (систему с управляемым хаосом), но так чтобы топ-менеджеры не поняли этого на начальных этапах. А когда механизм будет запущен, то должно быть поздно.
Как вы будете противостоять корп. выживалам? Весь смысл деятельности которых - демонстрировать любовь к начальнику

Вы же вступите с ними в политическое противостояние.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Нужно понимать, что ваши результаты будут оцениваться по тому, как это будет транслироваться наверх. Вы будете работать на результат (value), а ваши оппоненты на демонстрацию.
источник

AZ

Anton Zhbankov in Архитектура ИТ-решений
Gennadiy Kruglov
Орг структуру можно скопировать у Spotify, а менталитет, дух компании - нет. Ту самую культуру, про которую нельзя говорить.

И не нужно путать хаос с бардаком.
Расскажите, а сколько человек и как устроен spotify?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Anton Zhbankov
Расскажите, а сколько человек и как устроен spotify?
Зачем?
источник

AN

Andrew Nilove 💔 in Архитектура ИТ-решений
Gennadiy Kruglov
Как вы будете противостоять корп. выживалам? Весь смысл деятельности которых - демонстрировать любовь к начальнику

Вы же вступите с ними в политическое противостояние.
Подкуп, сбор компромата, политика разделяй и властвуй, но у меня больше вопросов, чем ответов.
источник

AN

Andrew Nilove 💔 in Архитектура ИТ-решений
и  главное — не возможность определить центр управления
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Andrew Nilove 💔
Подкуп, сбор компромата, политика разделяй и властвуй, но у меня больше вопросов, чем ответов.
Вчитайтесь в свои слова - вы будете свою энергию тратить на политическую борьбу.

У меня нет ответа. Работать в подразделениях, где руководители действительно нуждаются в изменениях и готовы быть "волнорезами", то есть брать на себя политику.

Когда результаты будут уже настолько очевидными, что их трудно будет исказить и полкомпании захотят работать у вас, вот тогда возможно и появятся предпосылки для распространения изменений на всю компанию.
источник

AN

Andrew Nilove 💔 in Архитектура ИТ-решений
Gennadiy Kruglov
Вчитайтесь в свои слова - вы будете свою энергию тратить на политическую борьбу.

У меня нет ответа. Работать в подразделениях, где руководители действительно нуждаются в изменениях и готовы быть "волнорезами", то есть брать на себя политику.

Когда результаты будут уже настолько очевидными, что их трудно будет исказить и полкомпании захотят работать у вас, вот тогда возможно и появятся предпосылки для распространения изменений на всю компанию.
все зависит от того, кто заказчик управляемого хаоса. На мелочь размениваться смысла нет. Нужно валить крупные федеральные бизнес-структуры.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Andrew Nilove 💔
все зависит от того, кто заказчик управляемого хаоса. На мелочь размениваться смысла нет. Нужно валить крупные федеральные бизнес-структуры.
Кстати, да. Заказчик - ключевое звено. У заказчика должно быть влияние и ему должен быть важен успех на рынке, позитивный опыт клиентов.

Тогда заказчик будет одним из каналов трансляции ваших результатов руководству.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Во всех известных мне кейсах, когда внутри "традиционной" компании людям удавалось делать что-то крутое и действительно конкурентное, были два условия: энергичный и сильные ЛИДЕР в роли руководителя и влиятельный клиент нацеленный на результат.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Но есть нюанс - это работает до первой серьёзной ошибки, и вы ошибётесь рано или поздно. А если делать так как хочет руководство, то ошибиться по определению невозможно.

Отношение к ошибкам - часть культуры.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
В чатике по работе @mxsmirnov установил требование - указывать позицию и фамилию руководителя. С моей точки зрения - это один из шагов к изменениям.
источник

AZ

Anton Zhbankov in Архитектура ИТ-решений
Gennadiy Kruglov
Зачем?
Интересно, вы же на них ссылаетесь
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Anton Zhbankov
Интересно, вы же на них ссылаетесь
А вы попробуйте уловить контекст и тогда вам возможно станет понятно, что ваш вопрос не уместен в данном контексте. В любом случае, это вопрос к Гулгу и отвечать на него я не буду.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Как мне кажется, авторы кратко и предельно понятно описали, когда нужен контроль, а когда допустимо управление с помощью контекста. Всё что они говорят кореллируется и с Адизесом тоже
источник