Существует 2 версии каждой технологической инфраструктуры: длинный список приложений, которые у вас есть, и короткий список тех, которые вы на самом деле используете. Посмотрите, как найти больше эффективности.
Существует две версии каждой технологической инфраструктуры: длинный список инструментов и платформ, которые у вас есть, и короткий список тех, которые вы на самом деле используете. По мере расширения технологической инфраструктуры и изменения рабочей силы, количество неактивных приложений в экосистеме компании (с низкой посещаемостью или без четких владельцев) может стать незаметным, превращаясь в утечку бюджета и риски безопасности. Даже процессы бюджетирования могут не решить проблему, с пунктами бюджета, оставшимися для слишком многих мест в в значительной мере неиспользуемых приложениях. На практике: я однажды работал в компании, которая предоставила мне лицензию на использование программного обеспечения для дизайна, которое я не знал — и никогда не научился — как использовать, только потому, что оно было частью стандартного маркетингового комплекта.
Это не значит, что вы не должны добавлять новые приложения в вашу инфраструктуру! На самом деле, рассматривая новые приложения, вы, вероятно, лучше поймете, какие приложения в вашей текущей настройке недоиспользуются и где вам возможно потребуется инвестиции.
Давайте рассмотрим, как провести всестороннюю оценку вашей технологической инфраструктуры, как понять, что включено в короткие и длинные списки, и как заполнить пробелы.
Как оценить вашу существующую технологическую инфраструктуру
Вы можете думать, что начать стоит с вашего бюджета. Это не так. Искусственный анализ вашего бюджета с самого начала может шокировать вас, заставив отказаться от широко используемого приложения. Это также не учитывает никаких бесплатных приложений, которые ваша команда может использовать (или которые все еще могут быть использованы, но все еще имеют доступ к вашим данным через SSO).
1. Лучший способ начать оценку — это… спросить вашу команду!
Есть причина, по которой ваш врач делает (или должен делать) запрос на перечисление ваших медикаментов каждый раз. У них могут быть старые назначения в их системе, которые могут негативно повлиять на рекомендации по новому подходу, и они хотят понимать, что именно вы принимаете. Чтобы сократить утомляемость от данных, вы можете предложить им заполнить форму, предварительно загруженную существующими инструментами, к которым вы знаете, что у них есть доступ, попросить их отметить те элементы, которые они используют, и добавить другие элементы, которые вы возможно еще не зафиксировали.
Вы также должны разделить вашу форму подачи, спросив людей оценить, как часто они используют каждый продукт (варианты: никогда, 1-2 раза в месяц, почти каждую неделю, несколько раз в неделю, каждый день) для более полного понимания их коротких и длинных списков.
Совет от профессионалов: убедитесь, что вы подчеркиваете, что это не «проверка». Люди могут не захотеть сказать, что они не используют продукт, который должны использовать.
2. Включите вашу ИТ-команду
Если вы используете метод SSO, такой как Google, который позволяет людям входить в приложения без настройки своей учетной записи, ваша ИТ-команда должна иметь возможность видеть, какие именно приложения они используют и как часто они используются. Это не только даст вам полное понимание их использования, но и может помочь вам выявить любые потенциальные риски безопасности.
3. Посмотрите на данные о использовании в продукте
Если у продукта есть данные об использовании, получите их! Если вы не можете найти панель управления, спросите команду поддержки, можно ли получить копию. В конце концов, данные объективны, в то время как личные отчеты субъективны.
4. Посмотрим на бюджет
Теперь пришло время оценить ваш бюджет. С учетом всех данных, самозаполненных вашей командой, данных SSO и данных о использовании в продукте, вы можете a) сопоставить это с пунктами бюджета и b) решить, является ли этот пункт бюджета хорошей тратой денег. Но даже это немного сложнее, чем может показаться на первый взгляд.
Если вы тратите $30 на человека в месяц на продукт, им пользуется 10 из 100 сотрудников, вы можете быть склонны автоматически отказаться от этой траты. Но вот что вы должны действительно учесть:
Почему мы купили этот продукт изначально?
Кто отвечает за него внутри компании?
Мы купили слишком много лицензий? (используют ли его люди, которые используют его, много?)
Нужно ли обучить пользователей вновь, чтобы показать ценность?
Вот удобная диаграмма для принятия решения:
Что учитывать при покупке нового инструмента или платформы
Теперь, когда вы понимаете, что ваша команда действительно использует, вы должны подумать, где могут быть пробелы. Если у вас, например, есть включенная в пакет вики, но никто ее не использует — даже после повторного обучения — вы можете рассмотреть возможность добавления новой платформы для обмена знаниями.
Когда многие поставщики предлагают аналогичные функции, как вы можете определить, делаете ли вы эффективные вложения и не просто добавляете приложение ради добавления приложения? Всегда спрашивайте у поставщика какие их метрики принятия на день и месяцпосле начального запуска.
Почему это важно? С любым новым приложением будет период восторга, когда ваша команда осознает его полезность. Тем не менее, после этого начального подъема вы можете начать замечать уменьшение использования (пока это просто не станет одним из тех инструментов, которые вам нужно пропустить через вашу диаграмму решения оставить или убрать). Узнав средние долгосрочные ежедневные и месячные показатели принятия, вы сможете понять, увидели ли другие компании реальную отдачу от инвестиций — и иметь метрики для оценки успеха вашей компании.
Эффективность — это постоянное упражнение
В конце концов, вы это знаете: уточнение вашей технологической инфраструктуры — это не разовая задача. То, что работает для вашей команды сейчас, может не сработать для них в будущем из-за роста, сокращения, условий отрасли или изменений в стратегии.
Сказав это, не практично проходить через этот процесс каждый месяц! Поэтому делайте это только после значимого события (например, перечисленных выше), и в начале вашего ежегодного бюджетного цикла.
Есть ли у вас другие мысли по поводу создания эффективной технологической инфраструктуры? Комментируйте ниже или отправляйте нам свои советы в Twitter.
Существует две версии каждой технологической инфраструктуры: длинный список инструментов и платформ, которые у вас есть, и короткий список тех, которые вы на самом деле используете. По мере расширения технологической инфраструктуры и изменения рабочей силы, количество неактивных приложений в экосистеме компании (с низкой посещаемостью или без четких владельцев) может стать незаметным, превращаясь в утечку бюджета и риски безопасности. Даже процессы бюджетирования могут не решить проблему, с пунктами бюджета, оставшимися для слишком многих мест в в значительной мере неиспользуемых приложениях. На практике: я однажды работал в компании, которая предоставила мне лицензию на использование программного обеспечения для дизайна, которое я не знал — и никогда не научился — как использовать, только потому, что оно было частью стандартного маркетингового комплекта.
Это не значит, что вы не должны добавлять новые приложения в вашу инфраструктуру! На самом деле, рассматривая новые приложения, вы, вероятно, лучше поймете, какие приложения в вашей текущей настройке недоиспользуются и где вам возможно потребуется инвестиции.
Давайте рассмотрим, как провести всестороннюю оценку вашей технологической инфраструктуры, как понять, что включено в короткие и длинные списки, и как заполнить пробелы.
Как оценить вашу существующую технологическую инфраструктуру
Вы можете думать, что начать стоит с вашего бюджета. Это не так. Искусственный анализ вашего бюджета с самого начала может шокировать вас, заставив отказаться от широко используемого приложения. Это также не учитывает никаких бесплатных приложений, которые ваша команда может использовать (или которые все еще могут быть использованы, но все еще имеют доступ к вашим данным через SSO).
1. Лучший способ начать оценку — это… спросить вашу команду!
Есть причина, по которой ваш врач делает (или должен делать) запрос на перечисление ваших медикаментов каждый раз. У них могут быть старые назначения в их системе, которые могут негативно повлиять на рекомендации по новому подходу, и они хотят понимать, что именно вы принимаете. Чтобы сократить утомляемость от данных, вы можете предложить им заполнить форму, предварительно загруженную существующими инструментами, к которым вы знаете, что у них есть доступ, попросить их отметить те элементы, которые они используют, и добавить другие элементы, которые вы возможно еще не зафиксировали.
Вы также должны разделить вашу форму подачи, спросив людей оценить, как часто они используют каждый продукт (варианты: никогда, 1-2 раза в месяц, почти каждую неделю, несколько раз в неделю, каждый день) для более полного понимания их коротких и длинных списков.
Совет от профессионалов: убедитесь, что вы подчеркиваете, что это не «проверка». Люди могут не захотеть сказать, что они не используют продукт, который должны использовать.
2. Включите вашу ИТ-команду
Если вы используете метод SSO, такой как Google, который позволяет людям входить в приложения без настройки своей учетной записи, ваша ИТ-команда должна иметь возможность видеть, какие именно приложения они используют и как часто они используются. Это не только даст вам полное понимание их использования, но и может помочь вам выявить любые потенциальные риски безопасности.
3. Посмотрите на данные о использовании в продукте
Если у продукта есть данные об использовании, получите их! Если вы не можете найти панель управления, спросите команду поддержки, можно ли получить копию. В конце концов, данные объективны, в то время как личные отчеты субъективны.
4. Посмотрим на бюджет
Теперь пришло время оценить ваш бюджет. С учетом всех данных, самозаполненных вашей командой, данных SSO и данных о использовании в продукте, вы можете a) сопоставить это с пунктами бюджета и b) решить, является ли этот пункт бюджета хорошей тратой денег. Но даже это немного сложнее, чем может показаться на первый взгляд.
Если вы тратите $30 на человека в месяц на продукт, им пользуется 10 из 100 сотрудников, вы можете быть склонны автоматически отказаться от этой траты. Но вот что вы должны действительно учесть:
Почему мы купили этот продукт изначально?
Кто отвечает за него внутри компании?
Мы купили слишком много лицензий? (используют ли его люди, которые используют его, много?)
Нужно ли обучить пользователей вновь, чтобы показать ценность?
Вот удобная диаграмма для принятия решения:
Что учитывать при покупке нового инструмента или платформы
Теперь, когда вы понимаете, что ваша команда действительно использует, вы должны подумать, где могут быть пробелы. Если у вас, например, есть включенная в пакет вики, но никто ее не использует — даже после повторного обучения — вы можете рассмотреть возможность добавления новой платформы для обмена знаниями.
Когда многие поставщики предлагают аналогичные функции, как вы можете определить, делаете ли вы эффективные вложения и не просто добавляете приложение ради добавления приложения? Всегда спрашивайте у поставщика какие их метрики принятия на день и месяцпосле начального запуска.
Почему это важно? С любым новым приложением будет период восторга, когда ваша команда осознает его полезность. Тем не менее, после этого начального подъема вы можете начать замечать уменьшение использования (пока это просто не станет одним из тех инструментов, которые вам нужно пропустить через вашу диаграмму решения оставить или убрать). Узнав средние долгосрочные ежедневные и месячные показатели принятия, вы сможете понять, увидели ли другие компании реальную отдачу от инвестиций — и иметь метрики для оценки успеха вашей компании.
Эффективность — это постоянное упражнение
В конце концов, вы это знаете: уточнение вашей технологической инфраструктуры — это не разовая задача. То, что работает для вашей команды сейчас, может не сработать для них в будущем из-за роста, сокращения, условий отрасли или изменений в стратегии.
Сказав это, не практично проходить через этот процесс каждый месяц! Поэтому делайте это только после значимого события (например, перечисленных выше), и в начале вашего ежегодного бюджетного цикла.
Есть ли у вас другие мысли по поводу создания эффективной технологической инфраструктуры? Комментируйте ниже или отправляйте нам свои советы в Twitter.
Опробуйте мощь платформы Гуру на практике - пройдите интерактивный тур по нашему продукту
