Ср, 13.11.2024, 06:00
Приветствую Вас Гость | RSS
Главная | Каталог статей | Регистрация | Вход
Форма входа
Поиск

Меню сайта

Категории раздела
От AKost [29]
От других авторов [6]

Наш опрос
О регистрации на сайте с помощью соцсетей.
Всего ответов: 24

Метки
EGL ODM бизнес правила программирование SOA arcati блоги журналы Каталог мейнфреймы журнал z/os Freeware VM bigdata nosql zOS MVS OS SLES zLinux мейнфрейм Хабрахабр 50лет документы хранилище Java EE liberty WebSphere z/VM Share history GitHub OS/VS S/379 сообщение Форум DFSORT Hercules VSAM отчётность Linux Analytics Accelerator Netezza IMS IBM IDC продажа CHKPT GSam XRST гипервизор KVM Shutdown #hollywar mainframe Вакансии Санкт-Петербург видео Выступления Dis нагрузка пример Assembler VM/ESA НИЦЭВТ Docker Sie Kubernetes OpenShift Environment RedBook RedHat рынок LHI vs XR instruction to clear GPR z Seies CPU performance семинар впечатление доступность ЦБ цены аутсорсинг BMC CMS ZVM санкции Rockwell история z13 мобильность DB2 Java Coupling Facility Parallel Sysplex WebSphere AS MVT ОС ЕС ссср Tape VTL Вакансия БЛОГ Линукс Новое статьи Люксофт Польша Работа Москва

Статистика

Главная » Статьи » Мысли по поводу » От AKost


Размышления о лицензионных платежах, или Как делать деньги на мэйнфреймах
Эти загадочные лицензии
Я уверен, что если в нашем, ИТ-шном деле, есть место непознанному, то первое место, где оно может гнездиться – это механизмы формирования лицензионных платежей. Например, рассмотрим процесс создания ПО. Вот фирма-производитель Ф1 задумала создать программу П1. Она потратила деньги, наняла людей, арендовала или купила им офис, кофе-машины, компьютеры, заплатила им зарплату. Программный продукт П1 родился – очень славный, удачный такой продуктик, нужный массе народа. Мы не будем говорить о том, как фирма Ф1 может зарабатывать деньги на обучении, консультациях, поддержке и на всем таком прочем. Речь идет, повторю, только о лицензии. Итак – продукт родился, и вместе с ним, как это водится в мире жестоких корпоративных программных продуктов, родилась Лицензия! На нее (лицензию) выставили цену. Каким образом? Тут уже начинается мистика. Вот, например, вы покупаете лопату. Приходите в магазин, выбираете лопату – красивую, удобную, такую, как вам нравится. Платите в кассу – и получаете лопату вместе с правом собственности на нее. И в тех деньгах, которые вы платите за лопату, львиную долю составляют объективные издержки производителя. Другое дело – программное обеспечение. Вы прочитали рекламу или рекомендации консультантов – и решили, что вам дальше невозможно жить без программы П1. Вы приходите к продавцу этой программы – производителю, его партнеру или просто в интернет- или реальный магазин. Платите деньги. И что вы получаете? Вы получаете всего-навсего право использовать программу в строго определенных условиях, ну еще иногда вместе с правом потреблять некоторый объем услуг на определенное время. При этом доля издержек производителя в стоимости продукта может составлять сотые доли процента (если программный продукт стал массовым, как в случае с ОС Windows) или существенную долю – если продукт не такой массовый. Но в любом случае – для программных продуктов точная цифра издержек производителя в конкретном экземпляре программного продукта есть величина неизвестная. Объективная часть этих издержек – материалы и стоимость труда по изготовлению данного конкретного экземпляра – составляют ничтожную сумму, несоизмеримую со стоимостью лицензии. Остальное – это рассчитанная на основе прогноза популярности и других параметров некая надбавка, которая должна покрыть расходы на разработку и принести прибыль. Алгоритм расчета этой прибыли – самая загадочная и неформализованная вещь во всей ИТ-сфере. Как ее формируют на ПЭВМ – я не знаю. Поэтому поговорим о том, о чем я имею некоторое (может быть, неверное) представление.

Версия: как формируются величина лицензионных платежей на мэйнфреймах
Схему формирования стоимости лицензии на мэйнфреймах, мне (очень приблизительно) рассказали на одном из мероприятий. Идея вкратце такова. Каждый, кто работает в с мэйнфреймами, является по определению корпоративным пользователем, нацеленным на извлечение прибыли. А прибылью надо делиться. Поэтому в стоимость лицензии на программное обеспечение для КАЖДОГО ПОТЕНЦИАЛЬНОГО рабочего места вкладывается некая загадочная цифра, которая приблизительно уравнивает стоимость владения ПО одного пользователя на мэйнфрейме с аналогичным показателем на других платформах. То есть мы имеем дело с таким вот скрытым налогом на возможную прибыль. При этом главными критериями являются: 1) стоимость владения ПО на других платформах, а отнюдь не издержки 2) прогнозируемое количество рабочих мест – чем их больше, тем дешевле. На примере, приведенном мне, выглядит это так. Полноценно «упакованный» для работы в бизнес-структуре мэйнфрейм должен иметь «на борту» операционную систему, СУБД, некоторое количество коммуникационного ПО и набор серверных и частично клиентских приложений (например, Lotus или еще чего). Все это хозяйство с учетом мощности конкретного мэйнфрейма комфортно работает приблизительно на 500 пользователях. Стоимость владения аналогичным (по функционалу) набором ПО на другой платформе (на тех же персоналках), составляет около 2000 у.е. на одно рабочее место. Значит, купивший мэйнфрейм и указанный выше набор ПО должен будет заплатить за лицензию и машину порядка 500*2000 = 1 000 000 у.е. Ну, может быть, немножко меньше, так скажем – 850 000 у.е. А потом эту сумму раскусывают на разные составные части – стоимость железа, ОС и так далее. Все же знают, что давно уже нет однопроцессорных машин – есть машины с открытым одним процессом, а остальные пять присутствуют, следовательно, накладные расходы на производство оборудования – ничножны (а раньше – нет. Сколько процессоров заказали – столько получили, и каждый новый процессор – отдельный шкаф). Поэтому никого на мэйнфреймах не удивляет – почему это один и тот же железный ящик, в зависимости от настроек его микрокода, дает то 26 MIPS, то 1600 MIPS, и один и тот же набор ПО для двух этих ящиков стоит то 200 тыс у.е., то пару миллионов у.е. А дело всего в том, что производители ПО требуют не столько покрытия своих издержек, сколько имеют свое представление о том, какую прибыль получают их покупатели и сколько из этой прибыли должны получить они сами.
Наверное, в этом есть некая логика. Вот купили владельцы транспортного предприятия карьерный самосвал. Колеса – по три метра. Двигатель – размером с однокомнатную квартиру. Перевозит за раз три тонны песка, сжигая ванну дизтоплива в час. Новый владелец железяки (именно владелец! Не «взявший в аренду», как бывает в случае лизинга, и не владелец лицензии, то есть «имеющий право использовать»), заплатив всем денег, дальше свободен в своих решениях - возит он на грузовике тридцать тонн песка, или мешок цемента. Все продавцы с него все деньги взяли, и немаленькие, совершенно не задумываясь, как и сколько прибыли получит владелец грузовика. Так и думают иногда производители ПО – купил, дескать, бизнес-инструмент? Купил. Прибыль можешь извлекать? Можешь. Теоретически – много можешь извлечь? Много. Значит, делись! Ну чем не аналогия? Мне самому нравится. Однако есть в этой логике куча изъянов.

Почему мэйнфрейм не карьерный грузовик
Отличие мэйнфрейма от карьерного грузовика – в структуре расходов, а именно – в той доли объективных накладных расходов, которые несет производитель оборудования и ПО и той доле прибыли, которую он хочет оттяпать с помощью лицензии. Мэйнфрейм – он ведь ближе к железнодорожному транспорту. То есть, проводя аналогии, при нормально построенном бизнесе, никто не покупает локомотивы и не создает всю инфраструктуру железных дорог сразу оплатив их полную стоимость. За железные дороги и их компоненты владельцы ЖД платят годами и десятилетиями! Доля объективных издержек там огромна. Никому и в голову не придет, что стоит построить ветку и подогнать туда поезд, как в него набьется полный комплект народа, каждый из которых радостно заплатит за билет, поэтому оплата структурируется на основе данных, сколько же конкретно народа ездит, какими вагонами пользуются и с учетом массы дополнительных нюансов. Так и с мэйнфреймами – мэйнфрейм требует недешевой инфраструктуры в виде залов и персонала. Такие машины покупают редко, используют долго. Поэтому при покупке (понимая, что жить дорогой машине лет 5-7, не меньше, и новую купят не скоро) рачительный хозяин покупает с запасом вычислительных мощностей. Конкретный пример. У меня в организации вычислительные потребности мэйнфреймовсих приложений каждый год растут на 50-70%, и статистика такая сохраняется по меньшей мере последние 5 лет. Допустим, у меня подходит к завершению времени эксплуатации z800 в 170 MIPS. Какую машину я куплю? Правильно – ((((170*1,7)*1,7)*1,7)*1,7)*1,7)=2413 MIPS. Ну то есть около 2500 MIPS. То есть более чем на порядок мощнее, чем у меня была. Запросы на грузовики не растут такими темпами, и они неплохо структурируются. Грузовики можно покупать, как сервера – каждый год по паре-тройке-десятку штук. А мэйнфреймы покупают единицами, как локомотивы, раз в пять лет. Допустим, я наскреб денег и купил себе мэйнфрейм, поострил зал и обучил персонал. И что будет дальше? А дальше ко мне придут счета на уплату лицензионных платежей.

IBM и другие фирмы – разные способы быть жадным
Итак, машина есть, что нужно из ПО на нее – тоже понятно. Надо платить. Тут начинается форменный цирк. Я на мэйнфреймах имел дело с двумя поставщиками ПО - IBM и еще одна фирма, с штаб-квартирой в Германии, она делает распространенные ранее СУБД, назовем их ***BAS. А немецкую фирму назовем «FluffyWare AG» - сокращенно FAG. Обе фирмы уважаемые, и IBM, и FAG, обе давно работают на рынке, обе имеют представительства в России. Только FAG, имея безусловное преимущество в начале 90х среди СУБД на мэйнфреймах, уверенно это преимущество слил. А IBM медленно и верно отгребал рынок СУБД назад. Но самое главное – это два важных решения, принятые в IBM. Первое решение – это программа «Capacity on Demand». А второе – это внятные менеджеры в России. Про второе говорить не буду – это надо на личности переходить, а я этого не люблю. Будем считать, что FAG не повезло с менеджерами или со страной, где надо работать. А вот первое заслуживает внимания. Смысл этой программы в том, что можно динамически увеличивать и уменьшать вычислительную мощность, и, соответственно, величину лицензионных платежей. Можно купить мощную машину, и постепенно, с ростом количества пользователей и запросов на вычислительные ресурсы, повышать быстродействие, увеличивать количество открытых процессоров и, как следствие, постепенно увеличивать лицензионные платежи. Причем Capacity-on-Demand – это не уникальное изобретение IBM. Подобные программы есть у многих фирм, например, что-то подобное я слышал у SUN. Конечно, реализация данной программы в России – это непростое дело. Не все могут держать мэйнфрейм постоянно подключенным к интернету, не каждого устроит и ценовая политика. Но все понимают – есть со стороны производителя понимание того, что проблема неравномерного потребления ресурсов существует. Если не устраивает «Capacity on Demand», требующий держать мэйнфрейм подключенным к Интернет, то есть другие варианты, которые можно обсуждать. Забавно другое – FAG, прекрасно осведомленный о программе «Capacity on Demand», по-прежнему действует на основе вышедших из употребления представлений о том, что заказчик должен заплатить лицензионную плату не в зависимости от потребленных, а в зависимости от имеющихся в наличии ресурсов. Более того, возникает ощущение, что дешевле провести постепенный перевод программных продуктов на другую платформу, нежели каждый год вступать в объяснение с сотрудниками FAG на всех уровнях. Может, в том, что FAG потерял рынок, есть высшая справедливость?
Вообще контакты с IBM мне напоминают по своему внутреннему духу контакты с представителями советского министерства. Все спокойно и как-то отстраненно от конкретных «бумажных» денег – видно, что между инфраструктурными стратегическими преимуществами и сиюминутными финансовыми выгодами почти всегда выбираются первые. А вот общение с FAG – это общение с «чоткими пацанами» времен начала 90х, где баблос нужен быстрый, а потом хоть трава не расти.

Выводы
Первый вывод. Лицензионные платежи – это всегда непрозрачно, просто в силу информационного «неявного» характера самого продаваемого продукта. Фирма-производитель может как получать гипер-прибыли, так и нести убытки независимо от качества своего программного продукта.
Второй вывод. Корпоративный характер рынка мэйнфреймов поощряет тех, кто не стремится сразу получить много денег на лицензионных платежах. Тактический выигрыш в деньгах неизбежно приводит к проигрышу в стратегии. Если хочется зарабатывать на мэйнфреймовских проектах – читайте, как строили железные дороги в 19 веке в США.
Третий вывод. Поскольку рынок мэйнфреймов (опять же в силу корпоративности) консервативен, то выигрывают на нем игроки с высоким запасом прочности, те, которые могут строить долговременные отношения. Если не в состоянии строить свою политику на несколько лет вперед с учетом возможных проблем платежей, кризисов и прочих катаклизмов, то поищите другую область инвестиций.

Поэтому рынок мэйнфреймов – не область стартапов и огород шустрых менеджеров с ухватками оптовых торговцев скоропортящимися товарами. Это рынок для тех, кому уже некуда спешить (по разным причинам). И какими бы ни были загадочными механизмы формирования и управления лицензионными платежами, основную тенденцию они отражают правильно – выигрывает тот, кто понимает специфику рынка. Остальным место на базаре.
Категория: От AKost | Добавил: akost (05.07.2009) | Автор: Костырко Александр
Просмотров: 2963 | Комментарии: 7


Всего комментариев: 7
1 mramor  
Саша, привет!
Спасибо за как-всегда отличный текст!
Здесь хотелось бы отметить, что существует два подхода, дабы не возникло путаницы с терминами.

Capacity-on-Demand - это увеличение мощности машины, реализуемое в решениях HA(High Availability)/DR(Disaster Recovery) на договорной основе. Реализуется данное решение на железном уровне (с минимальными софтовыми вкраплениями вроде некоторых продуктов Tivoli), когда, к примеру, приобретается 2 машины, в GDPS (Geographically Dispersed Parallel Sysplex), одна в производстве, вторая - backup, скажем, с тестом и девелопментом. Первая машина может быть, к примеру с 5 CPU на 2500 MIPS, а вторая - с 1 CPU на, скажем, 560 MIPS (z9 EC 705 и 701 соответственно). В случае сбоя на первой машине, пользователь имеет возможность моментально подключить 4 процессора на второй машине, таким образом увеличив её мощность, на время, пока первая машина не будет снова поднята в бой (это время может быть до 45, 90 и более дней в год, как будет указано в договоре).

Sub-Capacity License Charge - это возможность использования ПО по фактической загрузке машины. Подробнее можно прочитать здесь (англ). В этом случае необходимо отправлять отчеты о загрузке LPARов в IBM. К сожалению, из-за повального увлечения секретностью (не в укор никому из заказчиков, я понимаю, что часто это оправданно), у нас данная практика не очень распространена. В забугорье же, она очень популярна, т.к. действительно позволяет экономить.


2 akost  
Леша, хорошо, что ты тут. А то я про Sub-Capacity вообще не знал. Так что оно еще более в тему. А про секретность - тут ты на 100% прав, отдавать любые данные с мэйнфрейма за бугор страшно для любого функционера от безопасности. А без его визы, сам понимаешь, никуда.
Однако проблемы с секретностью, слава Всевышнему, решаются через внятность российских менеджеров. А вот если тут у нас посадят малобюджетных управленцев, типа описанных в статье, вот тогда кранты.

3 mramor  
Cоглашусь, в свою очередь, что вопрос безопасности и отправки данных о загрузке LPAR за границу крайне важен для государственных заказчиков, там, где есть какая-то тайна. А вот в том же EU, к примеру,среди коммерческих организаций, бизнеса, это широко распространенная практика (sub-capacity), хотя они так же отправляют данные "за границу", в США. Просто они не позиционируют их как "вероятного противника", видимо. Да и деньги считать умеют smile У нас тут еще и психология зачастую включается и мешает. Хочется верить, что лет через *дцать и мы к этому придем.

4 akost  
Дык европейцы признают американские сертификаты безопасности. Если IBM отсертифицировала LPAR на всякие степени закрытости от врага и на то, что в передаваемых данных нет коммерческого контента, то европейские пользователи успокаиваются. А наши безопасностники - нет. Ибо мы помним, как у Хуссейна во время Бури в пустыне вся связная техника от Моторолы издохла (слух, сам не видел, разведка говорила, могли соврать, те еще сукины сыны). Так что звиняйте, никаких отдач информации из LPAR. Будем экономить другими способами.

5 mramor  
Экономьте с нами! Экономьте как мы! Экономьте лучше нас! smile

6 XOpen  
>Конкретный пример. У меня в организации вычислительные потребности мэйнфреймовсих приложений каждый год растут на 50-70%, и статистика такая сохраняется по меньшей мере последние 5 лет. Допустим, у меня подходит к завершению времени эксплуатации z800 в 170 MIPS. Какую машину я куплю? Правильно – ((((170*1,7)*1,7)*1,7)*1,7)*1,7)=2413 MIPS. Ну то есть около 2500 MIPS. То есть более чем на порядок мощнее, чем у меня была.

Разве не логичнее просто открывать по одному процессору в год ?


7 akost  
Конечно, логичнее. Только зачастую дороже и хлопотнее для России.
1) заплатить за железку сразу дешевле. машина с 4 процессорами стоит около 800 тыс (условно говорю), с одним процессором - 450 тыс, открытие каждого процессора - 220-250 тыс.
2) каждый год придется заключать новый договор - проводить его через юристов, бухгалтеров, финансистов, и проч. Легче сделать это 1 раз.
И самое главное - пока я буду проводить договор, платить и открывать, пользователям уже станет плохо. То есть я и им делаю ежегодный геморрой. Оно надо?

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]

Яндекс.Метрика