Итоги '20 и прогнозы на '21: Gartner - Приоритеты 2021 для лидеров ИТ

Простой отчет в котором для разных лидеров ИТ предложены их приоритеты на 2021.

Приоритеты для CIO, Security, Application, PPM, Data & Analytics, Infrastructure, Operations, Enterprise Architecture, закупщиков...

Приоритеты Enterprise Architecture в отчете совпадают с тем, что мне рассказал один топ-менеджер от бизнеса чего он ждет от ИТ. Опубликую это в одном из будущих постов.

#тренд #итстратегия #архитектура
via 📢@it_ace

💬 Комментировать

Спасибо, друзья!
Стало понятнее что вам интересно!

Когда нужно сделать Capability map по экономике и финансам #2 в холдинге и дочках (для коммуникаций с топ-менеджментом)

Исходник для работы 👉 здесь

#кейс #топ #архитектура #эффективнаяработа
via @it_ace

💬 Комментировать

Понять как рассказывать о стоимости утечек данных топ-менеджменту

Отчет о стоимости утечек данных от IBM - ситуация и что с этим делать.

Прислал для канала @Mikenavv, большое ему спасибо!

#итменеджмент #итстратегия #топ
via @it_ace

💬 Комментировать

Понять на что надо обратить внимание по безопаности когда создаете новое ИТ-решение

Чек-лист, который можно использовать для организации безопасности для новых ИТ-решений.

Прислал для канала @Mikenavv, большое ему спасибо!

#архитектура #итменеджмент
via @it_ace

💬 Комментировать

Как проектировать структуры команд, продуктов и работ

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

Смотрите законы 👉 здесь

#практика #итменеджмент #архитектура #лучшее
via 📢@it_ace

💬 Комментировать

Как обосновать расходы на ИТ

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

"Скучная классика обоснования: сократим людей, меньше затрат на зарплату.
Вариация - снизим риски убытков от человеческой ошибки. Считаем потенциальные убытки от ошибки, перемножаем на вероятность. Ну и сравниваем с совокупной стоимостью владения ИТ-решения.

Ну вот честно, не всегда получается кого-то уволить, и вероятности ошибок часто не так велики...

А как обосновывать?

Ответ #1 - иногда и не надо делать. Нужно иметь мужество отказаться от проекта и не делать как все.
Ответ #2 - есть иные мотивации, не такие очевидные:
1. PR топов перед стейкхолдерами "какие мы передовые цифровые". Например, мне надо было найти нишу, где можно было себя показать эффективным управленцем.
2. Поддержание бренда и среды современной компании перед работниками, чтобы шли работать более молодые и квалифицированные, чтобы им было интересно, а они родят новые идеи.
3. Появление новых ценностей, автоматизация одного процесса создает новый процесс с новым бизнес-результатом. Новые ценности надо искать всегда. Например, в результате одного из проекта по автоматизации появилась возможность собирать данные и управлять результатами на больших территориях, а не только оказывать услуги.
4. Мотивация сотрудников, все хотят делать что-то значимое и интересное, новое, нерутинное, побеждать в конкурсах... Люди раскрываются, креативные приходят. Цифровизация это дала. Она создает пассионарную среду: создание смыслов в работе для себя, сотрудников, стейкхолдеров. Люди любят перемены и идти за огнем, даже если эта движуха не приносит пользы, она повышает градус людей чтобы им нравилось творить. Они где-то в другом сделают круто на общем движе."

#топ #итстратегия #архитектура #итменеджмент #лучшее
via 📢@it_ace

💬 Комментировать

История про то, что важно понимать что вы на самом деле делаете в проекте

Как-то раз делали мы платформу на которой должны были автоматизироваться процессы управления бизнес-сервисами одной корпорации из РБК ТОП-50.

Проект состоял из двух частей - создание "Платформы для автоматизации сервисов" и "пилотирование Платформы на 10 реальных сервисах".

Мы спроектировали Платформу на основе экспертных мнений, опыта, анализа мирового рынка, запустили ее с успехом прямо в сжатый срок, оставалось всего-то за месяц на ней собрать эти 10 сервисов и... провал!

Как вы уже наверное догадались, Платформа не подходила под сервисы 😫. 3 месяца работы вместо 1 месяца, уход в минус со всеми вытекающими...

Что надо было делать - не "Платформу для автоматизации сервисов", а "Автоматизацию сервисов на Платформе".

Конкретно что бы поменял в создании Платформы:
1. Вначале много усилий потратить на анализ 10 реальных сервисов (и других сервисов в корпорации)
2. На основе результатов анализа, с дополнением из внешних источников, сделать Платформу.

#итменеджмент #выученныеуроки #геронимус #лучшее
via @it_ace

💬 Комментировать

Разобраться в архитектуре Big Data на Amazon WS / Google CP / MS Azure / 👐 Open Source

Читайте статью 👉 здесь

#архитектура #лучшее
via 📢@it_ace

💬 Комментировать

Понять о чем и как должен думать хороший ИТ-менеджер прежде всего

Один топ-менеджер сказал мне недавно:
🔝 "Лучшие менеджеры прежде всего думают о продукте, а не о менеджменте. Лучшие менеджеры создают лучший продукт, а не лучшую организацию".

❗ Эта мысль важная для понимания. Если делать наоборот, то получится "идеальный завод", который не может ничего выпустить.

Развитие этой мысли я вижу в последовательности шагов для установления менеджмента:
1️⃣ Сначала нужно сфокусировать внимание на проблемах и потребностях какой-то группы людей. При этом не нужно думать об этом через призму своего продукта. Проблемы и потребности не связаны с продуктом. Вполне возможно, что ваши конкуренты смогут решить проблемы этой группы. 
2️⃣ О самом продукте нужно думать только когда понятно кто и в чем нуждается. И тут важно определить требования к продукту, которые вытекают из потребностей.
3️⃣ Из требований определяется архитектура, т.е то из чего состоит наш продукт (из каких частей). 
4️⃣ Отсюда определяются необходимые capability (оргвозможности) для создания продукта и, далее, этапы проекта и работы. 
5️⃣ Под это уже оргструктура, оптимизация и т.д.

Такому подходу и, вообще, структурированному подходу к созданию продуктов, стратегий и оргдизайна хорошо учат здесь 👉 https://news.1rj.ru/str/system_school. Сам проходил их тренинги, очень полезно для работы в ролях стратега, архитектора и менеджера.

Поподробнее и правильнее с точки зрения классической науки идея этого поста описана у них 👉 здесь

#практика #топ #архитектура #итстратегия #геронимус #лучшее
via @it_ace

💬 Комментировать

Зачем и как переезжать в гибридное облако на примере банков + визуализации для топов

Презентация McKinsey. Пролистайте, будет интересно не только банкам, но всем кто думает о переезде в облака)
Будет полезно использовать "для продажи" топ-менеджменту.

Мифы, настоящие драйверы, ошибочные и правильные модели переезда, оргструктура, безопасность, общий подход.

#топ #тренд #итстратегия #архитектура #итменеджмент
via 📢@it_ace

💬 Комментировать

Понять какую ИТ-стратегию предлагать в зависимости от вертикали подчиненности CIO

Прекрасная матрица от классика - Gregory Hohpe.

Источник 👉 видео выступления

#итстратегия #фрейм #лучшее
via 📢@it_ace

💬 Комментировать

Разобраться в истории Machine Learning

Для общего образования и презентаций:-)

(взято с @rockyourdata)

#итстратегия
via 📢@it_ace

💬 Комментировать

​​Как делить на команды в большом корпоративном решении в Agile

Все формирую свой подход по формированию команд после создания дорожной карты. Пост 👉 здесь

Понравилась 👉 статья в SAFE, ниже сделал выводы на основе неё.

📌 Есть 4 типа команд:
1. Value Stream-aligned team – вокруг value, которое напрямую доставляется заказчику или пользователю. Самое главное – ориентация на заказчика.
2. Complicated subsystem team – вокруг сложной подсистемы, требуется экспертное знание
3. Platform team – делает сервисы для других команд. Фактически команда типа 1 для других команд.
4. Enabling team – команда предоставляет специальные capability и помогает другим командам становится лучше.

📌 Структурируем команды так:
- Все команды должны быть в основном «Value Stream-aligned»
- Команду «Complicated subsystem» создаем только если нужен очень большой уровень опыта, присутствует большая сложность или большие риски
- «Platform team» создаем, когда надо «расшить» и повысить автономию команд типа «Value Stream-aligned»

📌 В жизни вокруг одного value stream несколько команд. Эти команды формируем так, чтобы они были сфокусированы на:
- Конкретном решении или подмножества решений
- Наборе функций
- Определенном представителе клиента
- Конкретных шагах в customer journey
- Конкретном бизнес-домене
- Compliance или нормативных требованиях
- Новых продуктах (которых ещё нет)

#практика #итстратегия #итменеджмент
via 📢@it_ace

💬 Комментировать

Разобраться что такое и зачем архитектура с точки зрения системного подхода

Совпадает с моим мнением:
1️⃣ архитектура = решения о важном
2️⃣ важное = то, что стоит много денег на переделку

В 👉 видео на 10 мин рассказана теория: что такое архитектура, почему это слово используется в системном подходе, как использовать архитектурные описания в своей деятельности и как архитектурные решения влияют на систему.

#архитектура
via 📢@it_ace

💬 Комментировать

Когда нужно выстроить грамотную архитектуру ИТ-платформы “всего ИТ” или digital-продуктов

Обновилась референсная архитектура IT4IT - мой любимый фреймворк для платформ по созданию ИТ-продуктов / ИТ-сервисов.

Этот фреймворк мы применяли во многих местах и отраслях - он работает!

Кстати, мы его применяем и для платформ не-ИТ сервисов (Enterprise Service Management).

Фреймворк любимый так как в нем есть много всего - capability, процессы, функции (с описанием), модель данных с потоками и он поддерживает всякие Agile, SAFE, ITIL, мультисорсинг и т.д.

Хотя на самом деле он любимая из-за того, что это мы ее когда-то привезли в РФ от авторов из Амстердама 🚬 😉 (из Shell и HP) - см. пост выше

✔️ Новая версия 👉 здесь
✔️ Предыдущая версия 👉 здесь. Эта версия очень подробная - в ней от детального описания функций до готовой модели Archimate с примерами для загрузки в ваш любимый редактор
✔️ Исходник карты софта 👉 здесь

#архитектура #итстратегия #итменеджмент #геронимус #лучшее
via 📢@it_ace

💬 Комментировать

Понять какие компетенции нужно получить чтобы стать специалистом такого-то уровня в такой-то ИТ-области

Платформа от EPAM где практически по всем профессиям ИТ расписано какие компетенции должны быть у специалиста от стажера до топ-уровня.

Ресурс содержит пояснения по темам и, часто, ссылки на грамотные по мнению EPAM источники информации.

Крайне рекомендую!

1. Заходите по ссылке https://grow.telescopeai.com/
2. Авторизуетесь через google
3. Заходите на вторую вкладку «Skills»
4. Выбираете профессию и уровень
5. Смотрите вкладки «Hard skills», «Soft skills», «Business skills» и читаете что вам или вашим сотруднкам нужно знать 😄

P.S. EPAM - одна из топовых мировых фирм по заказной разработке ПО, у неё в клиентах все: от госорганов РФ до SAP и Microsoft.

#практика #лучшее
via @it_ace

💬 Комментировать

Как говорить с топ-менеджером? Как с семилетним ребенком

👶 Один из моих любимых приемов называется "разговаривай с топ-менеджером как с семилетним ребенком". Прием хорошо готовит к разговору с топ-менеджером и рассказывать другим как это делать.

📌 Когда вы готовите выступление перед топ-менеджером - представьте что перед вами семилетний ребенок и сделайте рассказ таким, чтобы ему было понятно. 
Если у вас есть есть 6-9 летний ребенок, то можно прямо на нем потренироваться.

📌 В форме сообщения от нас обычно есть 2 основные проблемы:
1. Не понятно что мы хотим донести
2. Использование терминов, которые для нас очевидны, а топ-менеджер не знает или понимает под ними другое

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

P.S. Также в презентации на слайде нельзя использовать сокращения, а если используете, то обязательно на этом же слайде должна быть расшифровка. Сокращения считаются издевкой над слушателем: ему предлагается поработать - понять что они значат. Это усугубляется тем, что сокращения в разных областях значат разное.
Угадайте, что такое "эмэрзе"? Меня один раз спросили, и я в ступор попал) Это на самом деле было -"эмпэтри", MP3. А топ-менеджер прочитал как "эмэрзе".

#практика #топ #геронимус #лучшее
via @it_ace

💬 Комментировать

Как быстро подобрать способ приоритизации бизнес-инициатив, проектов, бэклога

Обычно мы знаем 3-5 способов приоритизации типа «Эффект-затраты», MoSCoW, WSJF. Они не всегда подходят под ситуации, в которые мы попадаем.

В 👉 статье описаны 81 (‼️) фреймворков приоритизации бизнес-инициатив и фич с примерами визулализаций.

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

Статью нашел и поделился Илья Кузин @kuza555, спасибо ему!

#фрейм #практика #итстратегия #итменеджмент #лучшее
via @it_ace

💬 Комментировать

​​Как обсуждают метрики в Amazon

Weekly Business Review или WBR или Wall of Numbers - еженедельные встречи в Амазон, где обсуждаются метрики. Амазон же data-drive компания. Что это из себя представляет? Прежде всего отчет (обычно без графиков и визуализации, вообще) в формате PDF (экспорт из Tableau в лучшем случае) или просто Excel (в 80%). Вот вам ирония, самая data driven компания смотрит в статические отчеты и делает это раз в неделю.

Отсюда напрашиваются выводы:
1) Для бизнес метрик и целей, нужно ли нам делать near real time data pipelines? Конечно нужны, но все зависит от задачи и требований.
2) Нужно ли нам смотреть на наши показатели 5 раз в день, каждый день? Важно держать руку на пульсе для операционных метрик, но там нужно настраивать систему оповещения (alert) если что-то отклонилось от нормы.
3) Нужно ли нам много красиво графиков? Доказано, что визуализацию лучше цифр. Но бизнес лидеры предпочитаю смотреть на цифры. 
4) Нужны ли нам дорогие инструменты визуализации и аналитики? Для статистических отчетов типа WBR нет. Но для анлитиков, которые ковыряются в данных (deep dive), нужны.

Вывод простой, неважно каким образом мы строим отчеты, и что используем. Они должны помогать бизнесу делать их работу - смотреть на данные и принимать решения, которые нацелены всего на 3 цели:
1) Увеличить прибыль
2) Снизить издержки
3) Снизить риски

Пример WBR слайда. Обычно это 50 страниц, где могут смотреть на одни и те же метрики в разных разрезах. Всегда готовят 50 слайдов, но обсуждают только 10, которые важно обсудить. Перед встречей нужно, написать callouts (что значимого случилось), после встречи часто нужно делать deep dive, и объяснить отклонения, во многих случаях это ошибка в ETL (нет инструментов data quality, notifications).

Абсолютно все делают такие отчеты, и многие изобретают велосипед.

(взято с @rockyourdata)

#кейс #итменеджмент #лучшее
via 📢@it_ace

💬 Комментировать