Помимо знакомства с весьма перспективным и многообещающим проектом Vulkan приехавшие на Lotusphere журналисты имели возможность получить информацию о последних разработках из лабораторий IBM. Так же как на прошлом и позапрошлом мероприятиях нам вновь было представлено около двух десятков новейших концепций и их программных реализаций. Остановлюсь на заслуживающих внимания технологиях, которые мне удалось посмотреть.

Итак, прежде всего нужно рассказать о проекте Concord, в рамках которого сейчас ведутся работы по созданию онлайн-среды для индивидуальной и совместной работы с документами, электронными таблицами и презентациями. По словам авторов, это не будет еще один веб-офис, а нечто большее – с сильным упором на взаимодействие. Пока, конечно, технология не впечатляет, так как доступна лишь возможность редактирования текстов с базовыми возможностями форматирования и лишь зачатки реализации идей коллективной работы – пользователи могут следить за изменениями в документе в режиме реального времени, комментировать элементы текста и пр. Сообщается, что бета-версия описанной разработки станет доступна во II квартале текущего года на ресурсе LotusLive Labs (это своего рода инкубатор инновационных технологий в сфере «облачных» вычислений).

Понравилась идея Workboards – среды совместной работы над небольшими проектами. На такой себе двухмерной «доске» пользователи могут писать заметки произвольной формы, делать из них списки задач или выносить в отдельные документы, а также вести e-mail переписку. Доступна работа как в синхронном (все видят все происходящее), так и асинхронном режиме (если вам нужно подумать и набросать идеи для себя и вы не хотите в это время демонстрировать другим процесс творения). В главном окне приложения показывается окно чата, статус тех или иных заданий, отсюда можно получить доступ ко всей проектной документации и увидеть связи между причастными к проекту людьми и сведениями.

Весьма любопытной представляется концепция SaND (Social Networks & Discovery), платформы, предназначенной для обнаружения, сбора и анализа разного рода «социальной» информации: сообщений электронной почты, переписок, выполненных в IM-приложениях, записей в блогах, наконец, пользовательских профилей в социальных сетях. Главная идея здесь – возможность работы со всеми этими сведениями с учетом их связей между собой и другими сведениями, поиска информации не только по конкретным словам, но и по тегам, людям, источникам. Как отмечают представители IBM, функции социальной аналитики, обеспечиваемые такими технологиями, как SaND, постепенно находят отражение в приложениях Lotus.

Пожалуй, наиболее занятными и, что немаловажно, уже доступными всем желающим, я нашел технологии для визуализации и анализа неструктурированных данных Many Eyes. Это решение предоставляет возможности от анализа отдельных элементов текстов до демонстрации связей между различными версиями документов. Чтобы представить результаты наглядным образом можно выбрать наиболее подходящий вариант визуализации из множества доступных. Любопытно попробовать данный инструмент в действии на каких-нибудь политических речах, государственных актах, постановлениях, да и на тех же блогах...

В середине января по традиции проводится конференция Lotusphere для обсуждения подходов и технологий корпорации IBM для организации продуктивной совместной деятельности сотрудников и целых компаний. По традиции она проводится в отельном комплексе Walt Disney World Swan and Dolphin, что в Орландо (штат Флорида). По традиции представитель еженедельник КО приглашен на данное мероприятие…

По традиции открытие официальной части конференции сделал Боб Пиччиано (Bob Picciano), теперь уже бывший глава подразделения Lotus Software и новый руководитель по мировым продажам всего ПО IBM. Ничего особо нового он не сказал – все те же разговоры о важности сотрудничества и совместной работы. Он не назвал число участников конференции – видимо, их меньше прошлогодних 7 тыс., поэтому цифра не оглашалась, зато отметил, что число партнеров, занимающихся продукцией Lotus Software, за год выросло на 20%. Неплохой результат как для кризисного года. Уместно заметить, что как во время выступления г-на Пиччиано, так и в рамках других докладов, никаких упоминаний о таких вещах, как recession, turbulent economic times, unstable economic conditions etc не было. То ли это табуированная тема, то ли IBM в лице подразделения Lotus Software не ощущает дискомфорта для бизнеса. Впрочем, в последнее верится с трудом.

На сцене Боба Пиччиано по традиции сменил специальный гость мероприятия. На этот раз им был не кто иной, как канадский актер и прозаик Уильям Шетнер (William Shatner), широко известный в США благодаря блистательному исполнению роли капитана Кирка в сериале «Стар Трек». Он хорошенько сдабривая свою речь шутками, убеждал публику в важности совместных действий в современном бизнесе на примере съемки фильма «Аватар».

Новый глава Lotus Software Алистер Ренни (Alistair Rennie) в своем выступлении сделал акцент на трех событиях. Во-первых, Голубой Гигант подписал соглашение с японским производителем электроники Panasonic, согласно которому сотрудники последнего получат доступ к «облачным» сервисам комплекса LotusLive, отказавшись от ПО Microsoft Outlook и Exchange. На первых порах будет подключено порядка 100 тыс. человек, а затем еще свыше 200 тыс.

Во-вторых, он рассказал об инициативе Collaboration Agenda, представляющей собой основанные на лучших мировых практиках методика и инструментарий по повышению эффективности взаимодействия людей. Применяя их, можно выявить проблемные места в деловых связях между коллегами и партнерами и получить рекомендации о том, как их устранить. На данный момент Collaboration Agenda доступна для предприятий, представляющих четыре отрасли: государственное управление, здравоохранение, финансовые услуги и страхование.

В-третьих, с помпой был анонсирован проект под названием Vulkan, в его рамках корпорация должна разрабатывать технологии совместной работы следующего поколения, которые будут находить отражение в будущих релизах LotusLive, Lotus Notes/Domino, Connections и Quickr, а также WebSphere Portal. Мотив для его создания, в общем-то, понятен – IBM уже дышат в затылок конкуренты в виде Microsoft и Google и ей во что бы то ни стало необходимо оторваться от них, предложив рынку нечто принципиально новое. В двух словах это все о Project Vulkan, в репортаже о мероприятии мы попробуем более детально рассмотреть его концепцию.

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

В своем добротном отчете представители European Network and Information Security Agency (ENISA) основными трудностями, относящимися к эксплуатации решений класса cloud computing, называют потери контроля над данными, сложности с выполнением нормативных требований и дополнительные юридические риски при передаче информации сторонним организациям. Эксперты ENISA отмечают именно эти проблемы, поскольку они имеют самые серьезные последствия и чаще других возникают у компаний, использующих «облачные» сервисы.

Дыма без огня не бывает. Насущность темы стала причиной того, что на нее обратили пристальное внимание и в Новом Свете. На днях американская Федеральная комиссия по торговле начала собственное расследование с целью оценки сложившейся ситуации с набирающей популярность концепцией cloud computing и ее реализациями, и выработки методов повышения уровня защищенности данных, хранящихся в «облаках». Отмечается, что орган должен много внимания уделить системам управления правами пользователей и доступа к информации (identity management systems), т. е. процедурам аутентификации потребителей при регистрации на сайтах.

На мой взгляд, инициатива резонная и полезная, но очень много вопросов возникает с ее воплощением в жизнь. Посудите сами, еще нет четкого представления о том, чем, собственно говоря, является cloud computing. На данный момент создано множество расплывчатых определений этого понятия и еще больше конкретных «облачных» решений, противоречащих им, что здесь даже специалисты не всегда могут сориентироваться. Как в такой сложной ситуации должным образом проверить концепцию? Можно, конечно, ограничиться отдельными ее вариациями – Е-mail-as-a-Service (Gmail), Software-as-a-Service (salesforce.com CRM), Platform-as-a-Service (Amazon Web Services) и др. и уже на основе их анализа вырабатывать какие-то специальные стандарты, рекомендации и пр., но ведь это будут абсолютно разные по сути документы. Моему уму непостижимо, как свести все эти подходы и инструменты воедино. Видимо, специалисты комиссии решили, что лучше двигаться, не зная дороги, чем стоять. Посмотрим, что из этого выйдет.

Интернет-издание CIO.com - Business Technology Leadership определило лучшее бизнес-приложение последних десяти лет. В последнее время появилось немалое количество инновационных деловых программ, однако награда указанного ресурса Enterprise Software Unplugged Awards (ESUie) присуждается не тем инструментам, которые потенциально эффективны или перспективны, а тем, которые реально применяются пользователями, поскольку те находят их полезными и желают их эксплуатировать (их никто не заставляет это делать).

Награду заслужило ПО Microsoft Excel. Как отмечается, его применяют компании от мала до велика, практически во всех отделах – от финансового до ИТ-департамента для сбора, анализа и предоставления информации коллегам, бизнес-партнерам и пр. Данное приложение завоевало прочнейшее положение в информационных средах предприятий. Фактически наградой ESUie отмечается то обстоятельство, что бизнес, по всей видимости, не может жить без старого доброго Excel.

Невзирая на то, что современные ERP-системы все чаще оснащаются развитыми средствами бизнес-аналитики, пользователи по старой памяти продолжают наряду с ними использовать и Excel. По сути, благодаря стараниям Microsoft приложение Excel стало стандартом де факто для BI-нужд конечных пользователей, которых сотни миллионов, и с этой позиции сместить его будет проблематично.

18 декабря состоялось девятое, заключительное занятие Первого открытого сертификационного курса по управлению проектами. Так как я порядком отстал от графика по публикациям о ходе тренинга, то сделаю эту запись сразу о трех последних занятиях. На них поднимались такие темы, как управление рисками (Risk Management), поставками (Procurement Management) и интеграцией проекта (Integration Management), а также профессиональные обязанности руководителя проектов.

Risk Management

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

1. С точки зрения экзамена на получение сертификата PMP данная область считается не сложной, так как в достаточной мере формализована. Сама же по себе она весьма запутанная. В некоторых проектах, преимущественно крупных, создаются даже специальные комитеты по работе с рисками.

2. Очевидно, что снижение рисков увеличивает стоимость проекта. Стоимость проекта без указания затрат на работу с рисками – лишь декларация о намерениях.

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

4. Риск обычно оказывает отрицательное воздействие. Такова реальность. Поэтому их нужно вовремя обнаруживать и нивелировать. В Сети попадаются платные сведения о рисках для конкретных проектов. Если есть возможность, нужно покупать такие вещи, этим вы облегчите себе жизнь.

5. Успешный проект – тот, результатом которого является продукт, соответствующий определенным для него характеристикам, созданный в рамках ограничений, выставленных для проекта (железный треугольник), с учетом изменений, реализованных на основе утвержденной процедуры. Не всякий проект, вышедший за заданные рамки, следует относить к провальным. Если процесс не выходил из-под контроля руководителя и все изменения вовремя утверждались, находя отражение в базовом плане, проект считается успешным.

6. Вероятность успеха проекта всегда больше 0 и меньше 1 (как и провала). Для приоритезации рисков (которая идет после их идентификации) можно не ограничиваться шкалой 0-1, а взять, к примеру, 1-5 или 1-100.

7. Вот как выглядит иерархическая структура рисков:

В ней перечислены категории и подкатегории рисков, которые могут появиться на типичном проекте. Для разных проектов и организаций применяются различные иерархические структуры рисков. Одним из преимуществ этого подхода является то, что участники процесса идентификации рисков имеют представление о многочисленных источниках рисков проекта.

Procurement Management

0. Управление снабжением связано с процессами покупки и эксплуатации продуктов, услуг и ресурсов, требуемых для реализации проекта у сторонних организаций. Оно предполагает анализ цен поставщиков услуг и/или аппаратного/программного обеспечения; подготовку документов об инициировании предложений (requests for proposals, RFP), выбор поставщиков и субподрядчиков; составление контрактов и переговоры об их условиях; мониторинг выполнения их исполнения и закрытие сделки.

1. Это еще одна хорошо регламентированная область управления проектами. На практике процессы управления снабжением далеки от простых, особенно в девелоперской отрасли.

2. Едва ли не главная задача руководителя проекта в данной области – заключить справедливый контракт, который удовлетворяет требованиям всех сторон. Он должен быть формально оформлен и детален. Следует избегать дружеских соглашений и т. п.

3. Имеется два главных типа контрактов (не считая простого счета) – с фиксированной ценой (fixed price) и с ценой, определяемой по фактически выполненным работам и затраченным ресурсам (time & material). При первом покупателю проще управлять контрактом, он знает цену вопроса, а продавец сильно мотивирован к выполнению работ, но здесь имеет место большой финансовый риск для продавца, для покупателя же присутствует риск не закончить проект из-за остановки продавцом, кроме того, в данном случае, как правило, стоимость работ переоценена. Второй вариант выгоден продавцу, ему проще управлять изменениями, работы выполняются качественно, однако покупатель не знает стоимость проекта в его начале и велик риск конфликтов при увеличении стоимости.

4. Имеется три типа спецификации на работы: характеристики (performance), функциональность (functional) и дизайн (design). Первая описывает, что конкретный продукт проекта должен из себя представлять. Вторая предполагает отражение конечного результат или цели, а также (возможно) общих характеристик продукта. Третья детально определяет объем работ.

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

6. При ведении переговоров о закупках существуют различные тактики: ограничение времени принятия решения (deadline), сокрытие информации до поры (lying), недостаточность полномочий (limited authority), перекладывание ответственности (missing man), требование справедливости (fair and reasonable), навязывание задержек при рассмотрении вопросов (delay), вбрасывание информации для запутывания оппонента (extreme demands), имитация атаки (attacks) и пр.

Integration Management

0. Данная область знаний включает в себя процессы и операции, необходимые для выявления, определения, объединения, унификации и координации различных процессов и операций управления проектами в рамках групп процессов управления проектами.

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

2. Большинство руководителей и функциональных менеджеров предприятий, не знакомых с современной методикой управления, не имеют представления об интегрированном подходе и предлагают решения тех или иных вопросов, не учитывающие ее. В этом случае главная задача руководителя заключается в нахождении компромиссов между пересекающимися целями и альтернативами.

3. Планы проектов могут отличаться даже в рамках одной отрасли. Сравните разработку ПО с внедрением ERP-системы. Это две большие разницы.

4. Если план проекта содержит меньше 500 задач на несколько месяцев – это декларация о намерениях.

5. Без информационной системы управления проектами и их портфелями (Project Management Information System или Project and Portfolio Management System) работать проблематично. Бумажная волокита будет отнимать время. Здесь автоматизация необходима, это факт.

6. Ошибки в проектах – это данность, так как здесь слишком много факторов, с которыми нужно иметь дело: культура и структура организации, инфраструктура, администрирование персонала, толерантность к рискам, наличие информационной системы управления проектами, организационные активы и пр. На 100% правильный проект невозможен.

P.S.: Руководитель проектов обязуется выполнять кодекс профессиональной этики и поведения (Code of Ethics and Professional Conduct).

Очередное занятие Первого открытого сертификационного курса по управлению проектами было посвящено сразу трем областям: управлению качеством (Quality Management), человеческими ресурсами (Human Resource Management) и коммуникациями (Communications Management), поэтому было достаточно трудным для восприятия. Обо всем по порядку.

Quality Management

0. Управление качеством предполагает определение политик качества, целей и ответственности участников процесса так, чтобы проект соответствовал требованиям, для удовлетворения которых он был начат. Его процессы: планирование, гарантирование и контроль качества.

1. Так сложилось, что реальный опыт людей, касающийся управления качеством независимо от областей, как правило, не совпадает с тем, что описано в методике. Понятно, что имеют место особенности страны, наш менталитет и пр. Но такую специфику необходимо забыть, настроиться на новый лад.

2. Критерии качества (ожидания) задаются заказчиком, от руководителя проекта и его команды требуется их достижение. Если получается, что продукт не удовлетворяет заданным параметрам, необходимо возвращаться и вновь планировать – определять стандарты качества, применимые к проекту и цели, как этим стандартам соответствовать. В данном случае можно пользоваться правилом Парето. Порядок ранжирования элементов в диаграмме Парето используется для принятия решений о проведении корректирующих действий. Команда проекта должна в первую очередь принимать решения по тем проблемам, которые являются причиной наибольшего количества дефектов.

3. Нужно различать качество проекта и продукта. В первом случае качество определяется свойствами процесса – следованием методикам, полноте организационных активов и др. Во втором мы имеем дело с набором характеристик, которым конечный продукт должен соответствовать.

4. Следует различать качество и сорт продукта. Сорт – это категория (класс), присваиваемая продуктам или услугам, имеющим одно и тоже функциональное назначение, но различные технические характеристики. Низкое качество – это всегда проблема, чего нельзя сказать о низком сорте. Пример: вообще говоря китайские авто не являются низкокачественными, они сделаны такими намеренно (производитель ставил цель добиться дешевизны), но они низкосортные, так как по ряду параметров существенно уступают другим подобным продуктам.

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

6. Один из главных постулатов современной дисциплины управления проектами гласит, что качество планируется, разрабатывается и строится, но никак не ожидается. Иными словами, проблемы нужно решать (или избегать) до их возникновения.

7. Чтобы гарантировать качество, стоит привлекать внешних аудиторов или прибегать к помощи внутренних специалистов. «Взгляд со стороны» выявит несоответствия действий, выполняемых в проекте, организационным и проектным политикам, процессам и процедурам.

Human Resource Management

0. Управление человеческими ресурсами предполагает организацию и руководство проектной командой. Процессы здесь: планирование HR, приобретение, развитие и управление проектной командой.

1. Область знаний слабо формализована. Люди – особый ресурс, которым управлять сложнее всего, особенно в преобладающих у нас функциональных структурах.

2. При планировании человеческих ресурсов играют роль как внутренние, так и внешние факторы: организационная структура и культура компании, имеющиеся в наличии ресурсы, политики управления персоналом, а также рыночные условия.

3. Среди инструментов данного процесса – организационная теория и переговоры (общение). Первая предусматривает пять видов власти: власть, основанная на вознаграждении; экспертная власть (если руководитель – эксперт в своей области); власть, основанная на официальных полномочиях (должность); власть эталона, основанная на личных качествах руководителя; власть, базирующаяся на возможности применения или отмены наказания. Согласно PMI в области управления проектами наиболее действенной является экспертная власть.

4. «Жизненный цикл» команды включает 5 стадий: формирование, шторм, нормализация, выполнение и завершение. До того как команда начнет работать взаимозависимо, спокойно и эффективно (стадия выполнения), как правило, проходит треть выделенного под проект времени.

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

6. По статистике свыше 50% конфликтных ситуаций возникает вследствие трех причин: разногласий в проектной команде, некорректно расставленных приоритетов и выхода за рамки по времени. Такая ситуация имеет место в функциональных и матричных организациях, а также при работах на внешних проектах.

Communications Management

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

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

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

3. Важно корректно идентифицировать ключевые заинтересованные стороны, их роли, подразделения, интересы, уровень подготовки, ожидания и уровень влияния. Для представления влияния и поддержки проекта каждым из участников рекомендуется использовать технику SWOT-анализа, заключающуюся в разделении факторов и явлений на четыре категории: Strengths (сильные стороны), Weaknesses (слабые стороны), Opportunities (возможности) и Threats (угрозы).

4. Имеется три метода коммуникаций: интерактивное (interactive communication), «проталкивающее» (push communication) и «вытягивающее» общение (pull communication). Интерактивное общение предполагает многосторонний обмен информацией (встречи, видео-конференции, телефонные разговоры). «Проталкивающее» общение – предоставление информации в одностороннем порядке тем, кому она нужна (электронные письма, отчеты, голосовая почта и пр.). «Вытягивающее» общение используется для больших аудиторий (корпоративные порталы, всевозможные базы знаний). Наиболее эффективным с точки зрения PMI считается первый.

5. По статистике коммуникационные навыки являются наиболее важными для управления проектами. Согласно результатам опроса менеджеров проектов так считают 84% респондентов, 75% голосов набрали организационные навыки, 72% – навыки создания команды, 68% – лидерский качества, и только 48% получили технические знания.

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

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

К такому выводу пришли эксперты независимой компании Common Sense Advisory, которая провела исследование потребительских предпочтений при совершении онлайн-покупок. В опросе приняли участие 2400 человек из восьми стран: Бразилии, Китае, Франции, Германии, Японии, России, Испании и Турции. Они рассказали о своих впечатлениях и предпочтениях при посещении веб-сайтов, которые представлены на английском и их родном языках, а также при совершении онлайн-покупок разных групп товаров.

Результаты исследования подтверждают мнение многих аналитиков о важности языковых аспектов для международной онлайн-торговли. Так, 52,4% респондентов сообщили, что совершают покупки только на веб-сайтах, информация на которых представлена на их родном языке. Для покупателей из Франции и Японии этот показатель оказался еще выше и составил 60%, а среди тех участников исследования, кто владеет английским языком на недостаточном уровне, показатель возрастает уже до 89,3%. Большинство участников опроса отметили, что наличие перевода описания товара для них важнее низкой цены, т. е. они предпочтут более дорогой, но локализованный товар, чем более дешевый, но описанный только на английском языке.

Вот как комментирует данную ситуацию Иван Смольников, генеральный директор компании ABBYY Language Services, которая сделал доступным рассматриваемое исследование на русском языке: «Мнение, что для успешных онлайн-продаж на зарубежных рынках достаточно создать англоязычную версию сайта, очень распространено и среди российских компаний. Надежда на то, что потенциальные покупатели “вероятно, знают английский”, приводит к неадекватной локализации маркетинговых материалов, сопровождающих продукт, и, как следствие, к недостаточно высокому уровню продаж в странах, где английский язык не является родным».

По своему опыту могу сказать, что я, как и большинство опрошенных, тоже бы отдал предпочтение русскому (украинскому) языку в описании товаров. Но с другой стороны, человек ко всему привыкает. В свое время я делал много покупок на американском ebay и не чувствовал дискомфорта – мне нужен был определенный товар, который больше нигде нельзя было приобрести, и у меня просто не было выбора. Я смирился с таким положением вещей.

C некоторым опозданием отвечаю на вопрос, заданный одним из читателей по поводу статьи о патентовании бизнес-методов. Вообще говоря, патенты на бизнес-методы признаются в Соединенных Штатах, Австралии, Японии и Сингапуре. Ситуация с ними в Канаде, Корее и на Тайване не особо ясная. Сложности имеются в Израиле, Индии, Мексике и большинстве стран Европы.

Заявка на нашумевшее «изобретение» Amazon.com в Европе была отклонена. Согласно Европейской патентной конвенции, «схемы, правила и методы ведения бизнеса» не считаются изобретениями и, следовательно, не патентопригодны. Впрочем, если новый метод решает техническую, а не сугубо административную проблему, он, в принципе, может быть запатентован. Тем не менее, программы здесь защищаются, как правило, только авторским правом. Оно не запрещает «использование, изготовление и продажу защищенных программ», поэтому крупные поставщики вроде Microsoft считают это недостаточным.

Отрадно, что в рамках ЕС работа над решением этого вопроса ведется. На данный момент комиссия Европейского патентного офиса ищет единые границы, определяющие, при каких условиях ПО может быть запатентовано.