Войти в систему
Войти с помощью соц. сетей:
Большинство людей упускают свою возможность, потому что она одета в рабочий халат и похожа на работу.
Томас Эдисон
Рост и внедрение инноваций благодаря распределению персонала
В Amazon мы шутили, что Джефф Безос похож на Волшебника Страны Оз, тянущего за рычаги за занавесом, чтобы управлять своей империей. И как и Великий Оз, если бы Безос мог, он остался бы один за этим занавесом, свободно управляя всем механизмом без помех или срывов. Но увы, компании размером с Amazon так не работают. Amazon является одним из крупнейших работодателей в Соединенных Штатах, а мечта о полностью автоматизированной компании ничем не отличается от приключений Дороти – просто мечта. Однако реальностью является необходимость развиваться, автоматизировать и внедрять инновации в Amazon. Развитие и инновации – непростые задачи. Тем не менее большинство руководителей упускают из виду крайне важный инструмент, который есть в их распоряжении: планирование численности персонала и его распределение.
Идея 38. Определите и примите во внимание навыки и персонал, который занимается управлением бизнеса, по отношению к навыкам и персоналу, который помогает развивать бизнес и внедрять инновации, как правило, с помощью технологий и партнеров. Продумайте, как распределить персонал, отвечающий за «развитие и внедрение инноваций», и рассчитайте соответствующие расходы.
В Amazon корпоративные сотрудники в основном делятся на два типа: прямые и косвенные. Прямые сотрудники – это люди с такими навыками, которые помогают развивать бизнес или создавать новые возможности. К их умениям относятся технические навыки и навыки разработки программного обеспечения, архитектуры процессов и навыки корпоративной разработки, а также навыки менеджеров по продукту и специалистов, которые ведут переговоры по контрактам. Все остальные относятся к косвенным сотрудникам: из сферы управления, операций, обслуживания клиентов, – в основном люди, отвечающие за все процессы, которые не были автоматизированы, усовершенствованы или переданы для исполнения другими организациями.
Идеи о том, как развивать процессы или вводить инновации, изложены в Оперативном планировании 1 (Идея 37). Лучшие идеи передаются в работу прямым сотрудникам, например инженерам, архитекторам и менеджерам по продукту. Косвенных сотрудников впоследствии повышают или устраняют, чтобы оправдать распределение и продемонстрировать приверженность проекту.
Так что же происходит, когда компания ежегодно принимает стратегические решения по перераспределению навыков таким образом, чтобы создавать процессы и технологии для развития бизнеса? Со временем бизнес становится все более регламентированным, цифровым и способным к росту.
В 2017 году New York Times отметила, что ни одна компания не воплощает в себе все желания и надежды, связанные с автоматизацией, лучше, чем Amazon. По мере роста как на дрожжах компания ежемесячно нанимает тысячи американцев. И все же Джефф Безос давно понял, что почти 700 центров выполнения заказов Amazon по всему миру катастрофически препятствуют развитию.
В 2012 году Amazon купил компанию Kiva Systems за 775 миллионов долларов и переименовал ее в Amazon Robotics. Два года спустя роботы, разработанные Kiva, стали частью трудовых ресурсов Amazon на складах. К 2017 году у Amazon было более 100 000 роботов по всему миру, и компания на этом не остановилась.
В дополнение к амбициозному обещанию «Доставим за два дня» роботы также облегчают людям монотонный труд, выполняя самую скучную работу и оставляя увлекательные задачи своим коллегам из плоти и крови. Заменили ли роботы Kiva живых людей? По мнению Amazon, нет. Компания сообщила New York Times, что с момента появления роботов Kiva было нанято 80 000 сотрудников склада в Соединенных Штатах, при этом общая численность сотрудников склада составила более 125 000. Зайдите на сайт Amazon Robotics, и вас встретят лозунгом «Мы переосмысливаем сейчас», за которым следуют приглашения обучаться робототехнике и принять участие в конкурсе, чтобы создать больше инноваций в категории робототехники.
Конкуренты на протяжении многих лет сравнивали Amazon с акулой. Это удачная метафора в том смысле, что акулы никогда не перестают двигаться. В беспрецедентном стремлении Amazon к развитию Безос и его команда видят острые проблемы на много лет вперед. Никогда нельзя почивать на лаврах и не думать о завтрашнем дне. Если каждый день – это День 1, конца пути не видно.
Что касается вашей организации, тщательно выбирайте процессы, в которые вы инвестируете. Убедитесь, что они являются истинным сдерживающим или критическим фактором. Надеюсь, у вас будет много идей, но вы можете позволить себе только несколько. В конце концов вы же не хотите запланировать дом с одной спальней, а в итоге построить таинственный дом Винчестеров.
Вопросы для обсуждения
1. Как ваша организация управляет развитием?
2. Используется ли планирование работы персонала в качестве инструмента для перехода в цифровую среду и внедрения инноваций?
3. Можно ли распределять и перемещать сотрудников в соответствии с приоритетами бизнеса?
Архитектура – это не вдохновляющий бизнес, это рациональная процедура, благодаря которой можно сделать полезные и, надеюсь, красивые вещи; это все.
Гарри Сайдлер
Побеждайте с помощью технологий и архитектуры
Таинственный дом Винчестеров, расположенный в Сан-Хосе, был построен вдовой основателя компании огнестрельного оружия Уильямом Винчестером. Хотя в нем было примерно 160 комнат, у него не было одной важной черты – плана. Дом построили без архитектора; вдова Винчестер просто продолжала прибавлять комнаты случайным образом. В результате в доме можно найти множество странностей, таких как двери и лестницы, которые никуда не ведут, окна с видом на другие комнаты и ступеньки странного размера.
Это похоже на вашу технологию и архитектуру данных? Я работал со многими компаниями над бизнес-стратегиями и технологическими возможностями. Основное опасение большинства руководителей заключается в том, что «для того, чтобы внести небольшие изменения, обеспечивающие ценность бизнеса, требуется слишком много времени и слишком много денег». Большая часть бюджета IT направлена на поддержание текущих систем, а не на создание новых возможностей. Я бы называл их IT-архитектуру «Дом Винчестеров» – множество приложений, множество интерфейсов, но нет основного плана или архитектуры. Если вы хотите быстро что-то изменить, добавить функции или развить что-то, вы понимаете, насколько это выглядит топорно и безобразно.
Идея 39. То, как ваш бизнес разрабатывает и создает архитектуру данных и технологий и управляет ею, имеет значение и влияет на ценность бизнеса. Архитектура определяет, насколько вы можете быть гибким и какие у вас риски. Это деловые факторы, которые необходимо учитывать, и вы должны убедиться, что вы на нужной волне. Вкладывайте достаточно денег, уделяйте достаточно времени, применяйте свой талант.
С чего обычно начинается решение или дизайн? Во-первых, необходимо понять потребности пользователя, для которого предназначено решение, и задачу, которую оно должно выполнить. Перечислите «требования». Затем выясните самый короткий путь их реализации, он также называется «точечное решение».
Это целесообразный, но потенциально недальновидный способ создания вашей технологии. При таком большом количестве потребностей легко понять, каким сильным является искушение пойти самым коротким путем. Технарей иногда называют хакерами за использование таких путей. Но архитектура технологий, а именно разработка данных, программного обеспечения, интерфейсов, API, сетей и инфраструктуры, – это другое. Если вы создаете продукт исключительно для точечного решения, вы просто строите очередную комнату в доме Винчестеров, не задумываясь о дизайне. А не имея плана, вы не будете готовы к двум очень важным моментам: к завтрашнему дню и внештатным ситуациям.
Пол Тирнен, мой друг и бывший коллега в компании Alvarez & Marsal, является одним из лучших специалистов по архитектуре бизнес-технологий, которых я знаю. Он сказал мне, что «ваша архитектура должна обеспечивать – ость». Чего-чего, спросите вы? Суффикс – ость указывает на «обозначение качества или условия». Давайте разберемся, какие качества или условия идеально подходят для архитектуры данных и технологий.
• Масштабируем-ость: возможность быстрого увеличения или уменьшения производительности системы.
• Безопасн-ость: сохранение того, что вы хотите сохранить. Разве это не безопасность? Безопасность описана в Идее 36.
• Гибк-ость: многофункциональность и адаптивность для разных вариантов использования, разных географических регионов, схожих потребностей с переменными или условными требованиями к обработке.
• Функциональная совместим-ость: изящная интеграция и взаимодействие с другими типами технологий, в частности с различными технологиями и внешними системами. API-интерфейсы являются одним из способов обеспечения взаимодействия данных и процессов на предприятиях.
• Измерим-ость: измерительные системы и системы мониторинга должны позволять идентифицировать, сообщать и даже прогнозировать качество работы, а также определять возникновение потенциальных проблем или сбоев. Это будет полезно как для IT-операций, так и для бизнес-процессов, зависящих от таких мер, как взимание пошлины или выставление счетов.
• Доступн-ость: простота и интуитивное взаимодействие технологии и пользователей. Это эргономика и машинно-аппаратный интерфейс технологии. Простота использования также учитывает экологическую пригодность технологии к условиям эксплуатации.
• Прослеживаем-ость: возможность отслеживать, проверять или объяснять, как происходили транзакции, принимались решения и выполнялись системные процессы. Мы не воспринимаем «учет операций» как что-то привлекательное, но с законом Сарбейнса – Оксли и другими юридическими требованиями способность показать процесс по шагам, часто с точки зрения движения наличных, а также способность продемонстрировать, что все транзакции были проведены должным образом, является сутью контроля. Поскольку сейчас используется все больше автоматизации и машинного обучения, создание прозрачности и демонстрация того, как принимаются решения, – это проявление прослеживаемости.
• Продолжаем-ость: необходимое качество, позволяющее эффективно удовлетворять будущие потребности бизнеса при минимальных затратах, времени и усилиях.
• Многоразов-ость: элемент продолжаемости, свойство, которое позволяет использовать одну и ту же технологию для нескольких целей. Модульность, объектно-ориентированный дизайн и соответствующая абстрактная структура – все это подходы для создания возможности повторного использования.
• Целостн-ость: в распределенных архитектурах, где данные и технологии работают в нескольких центрах обработки данных, нескольких облачных зонах и охватывают широкую территорию, должны быть системность и надежность, особенно если дело касается данных, которые должны быть правильными и рабочими. Традиционный пример «атомарной транзакции», когда либо все аспекты транзакции успешно относятся к распределенной базе данных, либо происходит откат транзакции, является ключом, который дополняется концепцией «согласованности в конечном счете», когда допустимое значение данных в итоге находится во всех распределенных версиях данных.
• Модульн-ость: создание дискретных, четко определенных и разделенных функций возможностей программного обеспечения. Решение обычно объединяет несколько модульных сервисов. Важное стратегическое убеждение Amazon заключается в том, что модульные сервисы должны быть «самообслуживающимися», то есть при использовании ваших возможностей необязательно взаимодействовать с вами лично, чтобы понять, разработать, протестировать, применить ваш сервис или управлять им. Это помогает развивать не только технологию, но и организацию.
• Качественн-ость: система выполняет то, чего от нее ждут. В технологиях основные средства обеспечения включают простоту тестирования и верификации, применения, управления версиями и эффективного устранения ошибок программного обеспечения.
• Стабильн-ость: способность реагировать на новые требования и динамику работы, не влияя на основную архитектуру. Правильная абстракция в архитектуре является ключом к стабильности. В физической среде компьютеров, сетей и центров обработки данных стабильность также отражается в сценариях избыточности, отказоустойчивости и аварийного восстановления.
• Доступн-ость: способность реагировать сразу. Как часто говорят футбольные аналитики ESPN о спортсменах и травмах, «лучшая способность – это доступность». В розничной торговле, если товар недоступен, вы теряете не только заказ, но и покупателя. Технически это одно и то же. Системы должны быть доступны и реагировать в соответствии с требованиями пользователя и бизнеса. Оперативные системы (NRT) с минимальным отставанием по времени являются критически важными понятиями архитектуры (ни дешевыми, ни простыми), которые обеспечивают множество цифровых функциональных возможностей.
Кто забудет классическую сцену, когда Джерри Магуайер, спортивный агент, по душам беседует с игроком Родом Тидуэллом в раздевалке? Агент просит игрока делать некоторые маневры по-другому, чтобы команде продлили контракт. «Помоги мне помочь тебе!» – умоляет Магуайер. Как часто бизнесмены просто говорят своей команде технических специалистов: «Это ваша задача, ботаники!»
Если вы хотите победить в эпоху цифровых технологий, вам крайне важно стать лучшим деловым партнером и наладить сотрудничество с командой технических специалистов. (И называть их ботаниками бесполезно, конечно, если вы действительно так их называете.)
Какова ваша роль в качестве делового партнера команды технических специалистов? Во-первых, позаботьтесь о них и постарайтесь сформулировать, какие показатели необходимы и как их оценивать с точки зрения бизнеса. Подробно изучите кейсы и укажите, как именно все должно работать. Проявляйте интерес к тому, как реализуются эти сценарии, и задавайте вопросы про каждый из них. Во-вторых, сосредоточьтесь на долгосрочной перспективе. Вы должны быть готовы финансировать основные качества и возможности. И в-третьих, – вот где архитектура становится стратегией – переходите в наступление.
Вникните в то, как будет выстраиваться архитектура – ость, и разберитесь в компромиссных решениях. Узнайте, как обернуть эти -ость в свою пользу и дать им конкурентное преимущество, чтобы продавать их клиентам и выделяться на фоне конкурентов. Если вы можете четко заявить рынку, что по этим параметрам превосходите конкурентов, а также продемонстрировать клиентам, почему это для них важно, то финансирование – ость можно перевести с накладных расходов на прямые затраты. Прямые затраты, также известные как себестоимость проданных товаров (COGS), представляют собой затраты, связанные непосредственно с доходом. Архитектура теперь становится бизнесом!
Я стал свидетелем поворотного момента для компании Amazon. В 1999 году газета Barron опубликовала свою теперь уже ставшую классикой главную статью «Amazon.bomb», в которой прогнозировалось, что акции Amazon пойдут по пути Pets.com и Drugstore.com». Но вместо катастрофического исхода Amazon вышла из кризиса с точки зрения доверия участников рынка и стала одним из «четырех всадников технологии». Вскоре после публикации статьи мы стали признавать, что Amazon – это действительно два ключевых типа бизнеса.
Во-первых, конечно, это широкая, мультикатегорийная розничная сеть электронной торговли. Тогда я руководил площадкой Marketplace, или, как мы ее называли, бизнесом Merchants@. M@ был крайне важен для создания «магазина всего». Используя платформу M@, мы открыли более 14 категорий, таких как одежда, спортивные товары, музыкальные инструменты, деликатесы и ювелирные изделия.
Тем не менее именно в это время Amazon стал видеть себя в качестве платформы, обслуживающей многие другие компании, в дополнение к функциям ритейлера. Мы решили, что все системы должны взаимодействовать, внутренне и внешне, через API. Эти API должны были иметь защищенные интерфейсы, то есть они должны были быть хорошо спроектированы, совместимы и не реагировать на внезапные изменения. API должны были иметь параметры уровня сервиса с набором рабочих стандартов скорости и доступности. Параметры уровня сервиса должны были быть отказоустойчивыми, то есть предполагалось, что другие компоненты могут выйти из строя или их состояние может ухудшиться. Несмотря на это API-интерфейсы должны были корректно работать в тех ситуациях, когда другие компоненты системы не функционировали должным образом.
Как и любое крупное изменение, технология была сложной. Но самой большой проблемой было подготовить людей, сделать так, чтобы они были вовлечены в процесс и двигались в одном направлении. В этой классической прозрачной манере Безос в 2002 году предложил 10 заповедей.
Стив Йегге, бывший инженер Amazon, вспоминает их в своем блоге:
«Большой Наказ» выглядел примерно так:
1. Все команды отныне будут предоставлять свои данные и функционал через сервисные интерфейсы.
2. Команды должны взаимодействовать друг с другом через эти интерфейсы.
3. Никакой другой формы межпроцессной связи не будет: никакой прямой связи, никакого прямого считывания данных другой команды, никакой модели кластера с совместно используемой памятью, абсолютно никаких закулисных игр. Единственная разрешенная связь – звонки через сервисный интерфейс по сети.
4. Неважно, какую технологию они используют – HTTP, Corba, Pubsub, пользовательские протоколы, – не имеет значения. Безосу все равно.
5. Все сервисные интерфейсы без исключения должны быть спланированы и разработаны с нуля так, чтобы иметь возможность представить их другим разработчикам, вне компании. Без исключений.
6. Любой, кто это не сделает, будет уволен.
7. Всем спасибо, хорошего дня!
Ха! Вы, 150 с лишним бывших сотрудников Amazon, конечно, сразу же поймете, что пункт 7 был моей маленькой шуткой, потому что Безосу совершенно точно до лампочки, какой у вас день.
Зато пункт 6 был вполне реальным, поэтому люди приступали к работе. Безос назначил пару Главных Бульдогов, чтобы те наблюдали за стараниями сотрудников и обеспечивали прогресс, а во главе стоял Суперглавный Бульдог Рик Дэлзелл. Рик – бывший армейский рейнджер, выпускник Военной академии США (Академии Вест-Пойнта), бывший боксер, бывший главный палач – он же IT-директор в Walmart и большой, гениальный, страшный человек, который часто использовал словосочетание «защищенный интерфейс». Рик сам был ходячим, говорящим защищенным интерфейсом, так что, само собой, каждый добивался большого прогресса и убеждался в том, что Рик об этом знает.
Благодаря своей архитектуре Amazon реализовал как внутреннюю организацию, так и бизнес-модель. На сегодняшний день Amazon имеет сотни общедоступных API-интерфейсов – от API-интерфейсов, связанных с продуктами, до API-интерфейсов AWS, API-интерфейсов Echo и API-интерфейсов в области выполнения заказов Amazon.
В 1980-х и в начале 2000-х годов бушевали войны ERP (англ. Enterprise Resource Planning, «планирование ресурсов предприятия»). Компании спешили внедрить решения SAP, Oracle, PeopleSoft или другое пакетное программное обеспечение, которое отлично подходило для стандартизации основных бизнес-процессов, таких как производство, управление заказами, управление персоналом или финансами. Помогая развивать процессы и стимулировать их совершенствование, эти системы не изменили сути бизнес-модели компаний.
Теперь, когда технологии и оцифровка продуктов, услуг и опыта становятся все более важными, забота о создании проприетарного программного обеспечения является одним из наиболее важных принимаемых предприятием решений. Не позволяйте IT-директору принимать это решение. Заставьте его участвовать в принятии этого решения.
Wall Street Journal отмечает: «Новые данные свидетельствуют о том, что секрет успеха Amazon, Google и Facebook, не говоря уже о Walmart, CVS и UPS (ставших успешными еще до вышеперечисленной тройки), заключается в том, сколько они вкладывают в свои собственные технологии и IT-сферу, а именно в наем разработчиков и создание программного обеспечения, которое принадлежит данной фирме и используется исключительно ею. Такой подход отличается от нашего стандартного понимания НИОКР тем, что это программное обеспечение используется исключительно компанией и не является частью продуктов, разработанных для ее клиентов».
Ваша архитектура состоит из многих типов технологий, но в программном обеспечении задействованы бизнес-логика и клиентский опыт, и оно требует ключевого набора стратегических решений, в частности о том, какую область требуется больше развивать.
Вы, скорее всего, не технический архитектор системы, не разработчик программного обеспечения и не технический директор организации. Как бизнес-лидер, отвечающий за управление, вы должны быть в курсе ключевых технологических концепций и интересоваться ими. Каждый должен расширять свои знания о технологиях, чтобы идти в ногу со временем. Обсудите с технологической командой, что важно для компании. Проверьте, есть ли у вас показатели оценки и уровня сервиса, чтобы убедиться, соответствует ли производительность требованиям.
Сотрите границы между «обсуждением бизнеса» и «обсуждением технологий», и вы зададите курс на цифровизацию. Ведя переговоры, начинайте с вопросов.
Вопросы для обсуждения
1. Достаточно ли хорошо задокументированы ваши технологии и архитектура данных? Понимаете ли вы их?
2. Полагаетесь ли вы всецело на пакетное программное обеспечение, когда речь идет об основных возможностях? Пользовательское программное обеспечение в нескольких выбранных возможностях будет для вас стратегическим отличием?
3. есть ли у вашей технологической архитектуры план, соответствующий цифровой бизнес-стратегии?
Войти с помощью соц. сетей: