Что отражает специфику цифрового продукта
Внутренние цифровые продукты и их особенности
Привет! Меня зовут Дмитрий Крупенин, я руковожу продуктовой разработкой в Первой грузовой компании (ПГК). Создаю интересные внутренние продукты по оптимизации управления вагонами, которых у нас достаточно много – 113 тысяч. У меня более 5 лет опыта работы в промышленных и логистических компаниях, где я разрабатывал продукты «про железную дорогу и вагоны». Сегодня хочу рассказать о том, чем отличаются внутренние продукты и работа над ними.
Что такое внутренний продукт
Когда мы говорим про цифровые продукты, обычно вспоминаются какие-то стартапы либо сервисы и приложения больших компаний, направленные на рынок b2с, массовых пользователей. Внутренний продукт – это продукт для пользователей, работающих внутри компании, то есть для внутреннего клиента.
Из чего состоят внутренние продукты
Внутренние цифровые продукты имеют довольно большой арсенал различных современных технологий, которые ничуть не хуже, чем у известных технологических компаний или стартапов. Мы говорим и про Data Science, и про прогнозные модели, оптимизационные алгоритмы, работу с большими данными и бесчисленное поле возможностей для применения автоматизации (от вездесущих excel-файлов с макросами до бесчисленных интеграций с внешними системами).
У нас в команде, как и в большинстве продуктов, есть бэкэнд- и фронтэнд-разработчики, которые программируют интерфейсы. Есть продуктовые дизайнеры, задача которых состоит в том, чтобы сложные продукты имели адекватные интерфейсы, удобные пользователю и способные решить его задачу. Да, во внутренних продуктах есть определенная специфика хотя бы потому, что их интерфейсы часто содержат большой объем информации, на основе которой будут принимать решения эксперты. Тогда на помощь часто приходит инфографика или нестандартные решения, чтобы не переложить очередную табличку из файла в веб-интерфейс, заставляя пользователя работать на трех мониторах.
Источник: ru.sputnik.kg
Симбиоз цифрового советчика и человека
В моей практике внутренние продукты – это цифровые советчики. Они по тому или иному каналу доносят до лиц, принимающих решения (в ПГК это диспетчера, планировщики, движенцы), советы, как оптимально решать ежедневные рабочие задачи. Фактически, такие советчики дают эффект только тогда, когда их советы реализованы, воплощены в жизнь специалистами.
Да, есть цифровые советчики, которые делают все автоматически, но по большей части продукты промышленных компаний вряд ли будут стопроцентно автоматизированы. Просто потому, что невозможно запрограммировать все потенциальные ситуации, никогда нельзя точно предсказать, какой вагон внезапно окажется непригоден под погрузку или какой кусок железнодорожных путей может оказаться перекрыт.
Другими словами, есть много внешних факторов для модели, и есть человек, который контролирует ситуацию с учетом советов цифровой модели. В критические моменты человек может принять решение, отличное от того, что рекомендует ему модель, так как цифровая модель не всегда учитывает внезапно произошедший инцидент.
Самое важное в создании внутреннего продукта (советчика, цифровой модели) – его полезность и приживаемость. То есть на выходе он должен быть таким, чтобы эксперты им действительно пользовались, прислушивались к советам, которые он производит. Только тогда можно говорить о крутости продукта и его экономической эффективности.
Источник legkopolesno.ru
Экономический эффект
На разных курсах для владельцев продукта мы изучаем, как можно измерить результаты с помощью метрик типа MAU, LTV, NPS и прочих. Продуктовые решения принимаются на основе данных: сколько пользователей заходит в сервис, сколько совершают покупку или делают заказ и т.д.
Однако наши внутренние продукты оперируют совершенно другими метриками и показателями. Например, когда речь идет о числе пользователей – внутри компании обычно может быть всего несколько десятков человек, которые пользуются этой разработкой. Не сотни тысяч или миллионы пользователей, как в b2с продуктах. Эта небольшая группа экспертов с помощью нашего продукта приносит компании значительный экономический эффект.
В моей практике интересные внутренние продукты – это обычно десятки миллионов рублей затрат на команду и инфраструктуру и сопоставимый экономический эффект в первый же год. Отличные проекты приносят в десятки и сотни раз превышающий свою стоимость экономический эффект. Это сопоставимо с цифровыми продуктами и сервисами, направленными на b2с.
Мы уже говорили, что внутренние цифровые продукты большой компании фактически нацелены на решение двух задач. Это либо снижение рисков, либо снижение затрат компании. В нашем случае мы, к примеру, снижаем риски получения нерелевантного парка или риски возникновения критического дефицита вагонов в том или ином регионе и, конечно же, снижаем затраты на управление парком вагонов.
Если говорить о каких-либо внутренних продуктах ПГК или других операторов железнодорожного транспорта, то одна из важнейших целей – повышение качества вагонов. Речь о контроле за коммерческой пригодностью вагонов в формате цифровых советчиков, созданных в помощь экспертам. Или, к примеру, снижение затрат на ремонты вагонов и дополнительные расходы.
Главная задача продакта при защите экономических эффектов – доказать, что именно цифровой советчик позволил добиться таких экономических показателей, а человек без подсказчика так бы не сделал. Поэтому часто приходится досконально разбираться в бизнес-процессах, просчитывая влияние других инициатив, мероприятий менеджмента и действий сотрудников. Тут на помощь приходят различные методы оценки изменений (гэпа) показателей относительно прошлых периодов, рынка, базовой линии и прочее. Обычно формулы расчета эффекта от цифрового продукта довольно сложные. Но пока ты пройдешь все стадии согласования, погружение в бизнес-процессы получается очень глубоким. Ты действительно начинаешь понимать, как работает то или иное направление бизнеса компании.
Источник: mygenetics.ru
Типовые проблемы
Первая проблема – приживаемость. Если мы говорим про Facebook или Instagram, где пользователь не пользуется какой-то фичей, то мы берем и что-то меняем. Когда мы делаем какой-либо производственный советчик, призванный помогать выполнять ту или иную деятельность, то может оказаться так, что модель сделана так хорошо, что она выявляет человеческие недостатки и недоработки. И для того, чтобы скрыть их, эксперты могут начать продукт бойкотировать.
В этом случае внедрять продукт нужно обязательно с заказчиком. Это прописная истина – поддержка руководства нужна обязательно, потому что часть пользователей точно будет сопротивляться внедрению цифрового советчика. Им может показаться, что человек будет не нужен – машина будет решать все за него.
Важно выстроить хорошие отношения с конечными пользователями, рассказывая им о том, что нет, цифровой советчик не сможет заменить их. Никого не уволят, наоборот, с сотрудников снимаются рутинные операции, которые заменяет машинный расчет. Так, специалист из линейного работника, который руками выполняет расчеты, становится экспертом, который работает с инцидентами, отклонениями математической модели. Он подключается, когда нужно реально разруливать проблему и решает неординарные задачи. Например, идет ремонт на конкретном участке железной дороги, и нужно ехать в обход, но компьютер про это не знает, потому что невозможно запрограммировать все подобные случаи. Только люди могут решить такие задачи.
Вторая типовая проблема заключается в том, что большая часть заказчиков, если мы говорим про какие-то промышленные компании, еще не привыкли к agile. Для нас подход к гибкой разработке – это что-то понятное и привычное, поэтому надо не забывать обновлять знания, что MVP не равняется «промышленный продукт».
Когда мы превращаем идею в цифровой продукт, на начальном этапе проверяем гипотезы: можем ли мы сделать так или не можем; достаточно ли в компании накоплено исходных данных, на основе которых модель будет выдавать решения; какого качества эти данные. Поэтому на старте речь не идет о создании промышленного продукта: это долго, дорого и результат неизвестен. Сначала делаем минимально жизнеспособный продукт.
На защите бюджета на создание МVP ваш заказчик может подумать, что это конечная цифра расходов для получения промышленного продукта. Мы же на этом этапе говорим только об МVP и проверке гипотез. Так как это минимально жизнеспособный продукт, в нем могут быть ограничения. Где-то мы не делаем интеграцию со сложными системами или сложными модулями SAP, делаем загрузку из Excel. Не настраиваем все возможные логи, не создаем целевую инфраструктуру и т.п.
Конечно же, после того, как мы закончим проект и захотим все это передать на поддержку, его надо будет доделывать. То есть преобразовать модель, созданную для проверки гипотез, в полноценный продукт, который будет максимально стабильно работать. У него будет целевое быстродействие и его можно будет эксплуатировать так, что служба поддержки сможет разруливать проблемы с этим цифровым продуктом с минимальным вовлечением команды.
Требования к команде
Отдельно стоит отметить степень погружения в предметную область. В моей практике, если речь идет о разработке каких-либо продуктов b2c, которыми мы привыкли пользоваться, каждый разработчик, как правило, с этим сталкивался и понимает, что и зачем он делает. А когда ты набираешь команду в логистический продукт для того, чтобы управлять вагонами, задачу понимает далеко не каждый разработчик. Даже продакты и бизнес-аналитики не всегда знают, как маршрутизируют вагоны, что такое конвенции РЖД, как вагоны ремонтируются и т.д.…
Приходится очень глубоко погружаться в предметную область, потому что нужно понимать, что вы делаете и какие данные есть в цифровом продукте. И почему они должны быть именно в таком виде.
Требуется глубокое погружение в предметную область
Один из краеугольных камней решения проблемы – наличие бизнес-заказчика и бизнес-транслятора внутри компании. Если в команде разработчиков для индустриальной компании нет людей, которые имеют большой опыт работы, к примеру, в РЖД, нефтехимии или металлургии, результата не достичь. Ровно потому, что без такого человека в команде любой цифровой советчик будет попросту похоронен после релиза, так как не будет учитывать те искомые «пятьдесят два параметра».
И конечно, важно иметь ввиду, если кто-то покидает команду, и приходится набирать новых людей, то потребуется значительно больше времени на их погружение в предметную область, то есть до того момента, когда начнут появляться первые результаты для компании. Невозможно просто вот так прийти, набрать за месяц команду, чтобы она через два месяца выдала какие-то результаты. Это очень сложно. И скорее всего месяц, а то и больше, команда будет погружаться в профессиональную сферу, чтобы выявить технологии производства, управления вагонным парком или особенности получения данных от РЖД – то есть научится разговаривать с заказчиком на одном языке.
Приживаемость продуктовой разработки
Еще один важный фактор – в промышленности цифровизация только начинается. Поэтому здесь важны фреймворки продуктовых команд.
Не все заказчики, бизнес-трансляторы и эксперты понимают, что такое user-story, Customer Journey Map и другие модные словечки. Им понятно, что такое «написать ТЗ» и совершенно непонятно, что такое «проверить гипотезу».
Часто представители бизнеса думают, что они ТЗ написали – значит, так и будет, не понимая, что это может не сработать, не прижиться и не взлететь. Поэтому важно донесение правил: как мы работаем, как работает IT-команда, как формируется бэклог, и в каком формате мы собираем данные. Почему у нас agile, а не fools ТЗ, какие результаты мы даем каждый спринт и почему делаем работу именно в таком порядке.
Источник: vashepravo.kz
Все это нужно постоянно рассказывать заказчикам, особенно тем, кто никогда не работал с IT-продуктами. Правила работы, особенности сбора бизнес-требований, формат взаимодействия – все это привычно для цифровизаторов, но может быть абсолютно непонятно железнодорожникам, нефтяникам или металлургам.
Суперважно фреймворки не только разрабатывать, но и постоянно о них напоминать, возвращаться к ним в течение всего проекта. Жестко отслеживать эти правила, чтобы цифровой продукт в конце концов получился четким и работоспособным с точки зрения IT-моделей, удобным для заказчика и конечных пользователей. Потому что цель каждого IT-разработчика, чтобы его продукт, в который вложено столько сил и труда, прижился и качественно работал. Ведь не секрет, что это не только польза для конкретной компании, но качественный вклад в ваше личное портфолио.
Состав и структура концепции цифрового продукта
Вы читаете вторую статью цикла о «нулевом» этапе проектирования – концепции продукта. В прошлый раз мы говорили о том, зачем вообще нужна концепция и какие последствия влечёт за собой её отсутствие.
Сейчас же речь пойдёт о том, что входит в состав концепции, какие артефакты нужны для того, чтобы она успешно выполняла свою роль и как я предпочитаю структурировать подобную информацию.
Состав и структура разделены специально – в моём понимании это разные вещи. Вы сначала собираете определённую информацию, а потом распихиваете её по разделам. Например, результаты исследования конкурентов могут уйти как в проектную часть (полезные кейсы, референсы), так и в бизнес (модель монетизации, риски). Каждый проект уникален, и идеальной схемы не существует – это нужно учитывать, и руководствоваться здравым смыслом.
§ 1. Состав концепции
Есть шесть обязательных моментов, которые я прорабатываю на каждом проекте. У вас их может быть больше, но вот меньше – вряд ли. Не могу себе представить проекта, на котором позволил бы себе хоть что-то отсюда исключить.
§ 1.1. Краткое описание проекта
Буквально пара-тройка предложений о том, что это за проект, какую он решает задачу и в чём воплощён. Если вы не можете сформулировать идею продукта в нескольких тезисах, то это большой вопрос к идеологу. Да, иногда продукты сложные и многогранные, но даже их можно как-то коротко описать. Обычно у меня краткое описание занимает не больше, чем абзац теста, который вы читаете прямо сейчас.
Эта часть нужна для того, чтобы:
Почти всегда в этой части работ я ещё базово исследую конкурентов: прямых и относительных.
§ 1.2. Цели и задачи бизнеса
Цели бизнеса (или кто там у вас вместо него на проекте) всегда про деньги, но не всегда напрямую. Даже если вы создаёте исключительно волонтёрский продукт, всё равно польза от него может быть выведена метрически (например, в количестве сэкономленных человеко-часов).
Но и у классического бизнеса цели не всегда явно материальны. Например: «укрепить имидж бренда в молодежной среде», «увеличить лояльность пожилых клиентов». Вот тут важно: вы должны вытащить эти цели из бизнеса, хотя он (особенно некрупный) зачастую отмахивается фразами типа «да что тут непонятного, нам бы бабла заработать». Конкретизируйте.
Целей может быть несколько, но их всегда можно разложить на конкретные задачи. Очень часто такие задачи и становятся, в свою очередь, целями продуктового дизайна.
§ 1.3. Потребности пользователей
И способы удовлетворения этих потребностей. Понятно, что на старте редко есть какая-то реальная пользовательская аналитика. Если бизнес принёс вам на тарелочке результаты работы с фокус-группами – вам крупно повезло. Чаще всего пользовательские потребности берутся из самой идеи сервиса. И чаще всего, они не совсем соответствуют действительности – просто потому что проистекают из представлений владельца бизнеса о своей аудитории. Иногда уже на этапе концепции приходится провести небольшое исследование – чтобы понять, а что же действительно нужно пользователям в данном контексте. И суть сервиса после этого порой немножко меняется. Особенно часто подобное встречается в стартапах.
§ 1.4. Описание основной механики
Основная механика – это, по сути, более развёрнутый первый пункт. Здесь вы должны понять, как именно вы собираетесь достигать целей бизнеса и закрывать задачи пользователей. Какая предполагается функциональность, с помощью чего планируется привлекать и удерживать клиентов, на чём зарабатывать. Но помните, что это – лишь ядро будущего проекта. Не увлекайтесь деталями и поменьше фантазируйте.
Обычно основная механика – самый объёмный этап концепции, она может содержать в себе значительное количество дополнительной информации, в зависимости от сложности проекта, количества вводных и прочих факторов. Если вы смелый, можете даже попробовать набросать примерную структуру разделов. Но с оговоркой, что она именно «примерная», иначе этим вы сами загоните себя в ограничения.
§ 1.5. Состав продукта и его технические особенности
Самый технологический пункт. Здесь мы решаем, из чего будет состоять наш продукт: мобильное ли это будет приложение, или хватит качественного адаптивного сайта; чат-бот нужен нашим клиентам или полноценный голосовой помощник.
Кроме того, именно здесь прорабатывается примерный состав компонентов и интеграций (внешних и внутренних): сервер, базы данных, системы аналитики, пуш-уведомления, платёжный агрегатор и так далее. Желательно кратко описать каждый компонент – это сильно упростит дальнейшую работу аналитикам и инженерам.
Иногда при описании компонентов не хватает даже моих познаний бывшего fullstack-разработчика. Тогда я прибегаю к помощи более опытных технарей, в этом нет ничего зазорного.
§ 1.6. Ограничения
Они есть в любом проекте. Технические, имиджевые, бизнесовые, конкурентные и ещё лютая тьма других. Поверьте, будет крайне полезно, если об этих ограничениях вся команда узнает сильно заранее, до начала работ над проектом.
Например, в сервисе категорически нельзя использовать персональные данные пользователей, так как это сервис по анонимайзингу (услуги географически распределенных VPN, например). Или наоборот: у вас в сервисе хранятся сканы личных документов пользователей – а это значит, что серверы должны находиться на территории РФ.
Один раз мне довелось работать с известной компанией, производящей прохладительные напитки. Так вот в ходе работы над концепцией представители клиента внезапно «вспомнили», что в данном продукте ни в коем случае нельзя использовать синий цвет в виде акцентного.
А в другой раз мне пришлось столкнуться с сервисом для фондовой биржи – и там оказалась важна мгновенная реакция интерфейса на внешние изменения. А значит, в приоритет вышел быстрый обмен данными и ширина канала сервера.
§ 2. Структура концепции
Обычно здесь у меня четыре ключевых слоя: проект, бизнес, пользователи и техническая экспертиза. Я предпочитаю вести документацию в Confluence, завожу там раздел «Концепция», а в нём 4 подраздела:
§ 2.1. Проект
Всё, что касается непосредственно самого продукта, его функций и особенностей. Как правило, это наиболее крупный раздел концепции.
Именно сюда входит большая основной механики, иногда вплоть до верхнеуровневых функциональных разделов.
Здесь базово расписывается состав продукта (например, в двух словах перечисляются особенности сайта, мобильного приложения, админки и сервера).
§ 2.2. Бизнес
Сюда ложится вся информация о бизнесе: цели и задачи, монетизация, конкуренты, масштабируемость, векторы развития, метрики эффективности и так далее.
Этот раздел прорабатывается довольно тщательно, иногда даже с привлечением внешних бизнес-аналитиков, если это позволяют сделать ресурсы. От того, правильно ли вы поймёте бизнес, зависит судьба проекта: интерфейсы можно переделать, техническую часть переписать. Изменить бизнес-реалии куда сложнее.
§ 2.3. Пользователи
Результаты предварительной пользовательской аналитики. Описания целевой аудитории, задачи и потребности, предполагаемые способы удержания и решения задач. Частенько сюда же снова попадают конкуренты – но уже в разрезе конкретных механизмов, которыми они закрывают пользовательские потребности.
§ 2.4. Техническая экспертиза
Это именно «экспертиза», а не полноценное техническое проектирование – на этапе концепции на него обычно нет проектных ресурсов. Однако даже базовая экспертиза позволяет уберечь дальнейший процесс от неверных (и подчас довольно дорогих) шагов.
В этом разделе я обычно собираю более детальное описание компонентов, внешних и внутренних интеграций, технические ограничения и риски.
В заключение
Концепция продукта должна быть полной, однозначной и отчуждаемой. Работать над ней должен не просто условный «юиксер», а специальный аналитик + привлечённые им специалисты. Именно этот аналитик засунет в свой мозг проектные бизнес-реалии, натянет их на реалии технические, задаст огромное количество вопросов, нарисует себе чудовищные схемы, и в финале выдаст единый документ с обозначением подводных камней, средств реализации и даже иногда рекомендаций по изменению внутренних бизнес-процессов клиента.
Этот документ станет основой всего проектирования, библией вашего проекта. На его основе родятся пользовательские сценарии, детализированные схемы бизнес-процессов с привязкой к программной среде, различные диаграммы классов, программная, информационная, навигационная архитектуры — и ещё множество артефактов, без которых создание сложного продукта если и не обратится в прах, то станет значительно менее стабильным и более дорогим.
Откуда это всё?
Идея концепции в том виде, которую я здесь изложил, родилась в стенах Цифровой Артели Eleven. Если интересно подробнее узнать о нашем подходе – можете полистать книгу моего партнёра по артели, Вадима Митякина, там много интересного. И да, все свои посты я аккумулирую в своём камерном телеграм-канале, подписывайтесь.
2| Специфика цифрового продукта и влияние на товарную политику
Цифровые продукты обладают большим количеством специфических характеристик, имеющих некоторое влияние на товарную политику компании. Ниже мы рассмотрим только основные их особенности.
а) Цифровые продукты не разрушаются при потреблении
Традиционно экономическая наука определяет потребление как «разрушение» товара. Использование некоторых товаров, например стирального порошка, шампуня или продуктов питания, приводит к их уничтожению. Некоторые товары длительного пользования также разрушаются в ходе применения, но в течение более продолжительного периода: виниловый диск или аудиокассета изнашиваются в процессе использования, как и холодильник, и автомобиль.
Что касается цифровых продуктов, то они не разрушаются в процессе потребления. МРЗ-файл может быть проигран бесчисленное количество раз без малейших признаков износа. Таким образом, цифровой продукт неосязаем в двух смыслах: он не зависит от материального носителя и не приходит в негодность в процессе использования.
Основной вывод, который можно сделать из этой особенности, состоит в том, что компании, выпускающие в продажу новую цифровую продукцию, конкурируют со своей собственной продукцией. Обновление рынка программного обеспечения происходит не из-за снижения качества продукта, а из- за его устаревания, которое не всегда происходит в краткие сроки.
Производители программного обеспечения могут применять политику, направленную на ускорение процесса устаревания: продвигая новые технологии, которые заставят покупателей заменить свое оборудование и обновить связанные с ним продукты: Super-CD (SACD), DVD и т.д., выпуская новые версии программ, заставляющие клиентов обновлять продукты. Так, компания «Microsoft» каждые два-три года выпускает новую версию Office, увеличивая тем самым объем продаж; предыдущие версии работают без сбоев, однако предлагаются новые, улучшенные и более мощные.
б) Цифровые продукты могут тиражироваться бесконечно
Цифровой продукт, каким бы он ни был, полностью кодирован и имеет форму информационных файлов. Нет ничего проще, чем растиражировать эти файлы в большом количестве экземпляров, не отказываясь при этом от пользования оригиналом.
Аналоговая копия (например, классическая фотокопия или запись на аудиокассете) имеет худшее качество, чем оригинал. Цифровая копия идентична оригиналу — это его клон. Цифровое копирование имеет отрицательные последствия с точки зрения защиты прав производителей. Действительно, упущенная производителями выгода может быть довольно значительной.
В 2001 г. профессиональная ассоциация Business Software Association (BSA) оценила упущенную выгоду, обусловленную незаконным тиражированием (или пиратством) программного обеспечения по всему миру, в 11 млрд долларов. Лидером здесь является Азия (более 4,5 млрд долларов), далее следуют Восточная Европа (2,5 млрд), Северная Америка (2 млрд) и Латинская Америка (1 млрд). Средний уровень незаконного тиражирования (отношение доли нелегального программного обеспечения ко всему установленному программному обеспечению) составлял 40% по всему миру, начиная от Великобритании (25%) и США и заканчивая Китаем (92%)1.
В 2002 г. в США продажи компакт-дисков упали на 9%, и ведущие производители связывают это падение с незаконным тиражированием цифровых продуктов. Согласно исследованию, проведенному компанией «Forrester Research», в 2001 г. 35 млн пользователей Интернета в Европе загрузили 2 млрд документов. По подсчетам компании «Nielsen/NetRatings» в сентябре 2002 г. 12% пользователей Интернета в Европе использовали сайт файлообменной сети Kazaa.
в) Цифровые продукты характеризуются маленькими предельными издержками и незначительной стоимостью распространения
В то время как предельные издержки (стоимость производства каждой последующей единицы продукции) производства автомобиля или станка составляют значительную часть отпускной цены и служат основой ценовой политики компании, предельные издержки для цифрового продукта являются незначительными.
Основные издержки, связанные с цифровым продуктом, состоят из инвестиционных расходов. Так, производители устанавливают цену цифрового продукта в зависимости не от текущих издержек производства, а от общей стоимости, включающей инвестиционные расходы и предположительный объем продаж. Поэтому можно наблюдать различную ценовую политику в отношении цифровых продуктов, принимающую в некоторых случаях форму практически бесплатных предложений (стратегия, связанная с ценовой политикой цифровых продуктов, будет рассматриваться в главе 6, посвященной ценовой политике).
?ег В качестве примера ценовой политики в отношении цифровых продуктов можно привести компанию «Microsoft». Производство CD-ROM стоит несколько евроцентов, но «Microsoft» продает копии программного обес-
печения «Office ХР» за 760 евро. Компания завоевала доминирующее положение на рынке пользовательских систем и оргтехники, и ее продажи уже давно превысили порог рентабельности: в 2002 г. «Microsoft» объявила об астрономических уровнях рентабельности — 85% для Windows и 80% — для Office.