Модель SaaS: предостережения
Однако, те же самые ИТ поставщики одновременно с лихорадочной работой над тем, чтобы сделать некоторые свои продукты, доступными для SaaS, надеются выиграть некоторое время, ссылаясь на то, что до настоящего времени применение SaaS было хорошим решением только для конкретных, четко-определенных областей, внутри отдельных подразделений и типовых процессов.
Несмотря на успех перечисленных выше компаний, многие все еще скептически относятся к долгосрочному успеху SaaS. Восприимчивость к данным, конфиденциальность и безопасность (вне защитной системы пользователя), гибкость системы, и тревожные сообщения о недавних сбоях, получивших широкую огласку (которые переходят в беспокойство о производительности системы в целом), - это только некоторые из проблем, которые продлят жизнь приложениям «on-premise». Вдобавок к данным поводам, список сомнений возглавляют вопрос о том, могут ли хостинговые приложения «on-demand» быть корректно объединены с существующими приложениями «on-premise» и скептицизм по поводу возможности адаптации SaaS или решений «on-demand» к уникальным бизнес-процессам.
[Перепечатка материалов 12news.ru разрешается только с предварительного согласования с редакцией или автором. Если вы читаете этот материал на другом ресурсе, пожалуйста, сообщите нам об этом editor@12news.ru]
SalesforceСom и другие проповедники SaaS обычно предлагают рабочие решения для таких стандартных бизнес-операций, как расширение возможностей продаж и управление. Многопользовательская архитектура позволяет хранить большие объемы данных клиента в одном экземпляре СУБД на стороне сервера (очень большое количество метаданных, которое требуется поддерживать поставщику). Однако, используя эту архитектуру, их приложения часто не могут предложить компаниям (особенно большим и требовательным) отличительных качеств, которые нужны им для увеличения продаж, доходов и доли рынка. На самом деле, процессы SFA достаточно стандартны и не могут быть источниками дохода, в то время как их функциональность – это просто сбор мнений продавцов о перспективах и уверенность в том, что они соблюдают правила процесса продаж.
Универсальная модель процессов продаж весьма успешна при внедрении, т.к. до сих пор она является наименее изменяемой из всех функций бизнес-процесса. Это позволяет организации - клиенту быстро внедрять такие решения, потому что, инструменты, которые будут использоваться, не повлияют на другие подразделения внутри организации. При таком отношении нет смысла тщательно настраивать системы SFA, так как это не очень значимая часть процесса продаж.
Если подходить системно, процесс планирования упреждающе влияет на результат. И те организации, которые попытались объединить отдельную функцию SFA с прогнозированием, выполнением заказов и бухгалтерским учетом, выполненными на основе SaaS, натолкнулись на дополнительные трудности.
Другими словами, напоминая известное «правило 80-20», те итоговые 20 процентов или около того, которые отделяют компанию от ее конкурентов, часто нельзя обеспечить решениями SaaS. Необходимость дифференциации потребует от предприятий поиска более традиционных ИТ поставщиков, которые компетентны в специализированных областях и общей функциональности, чтобы обеспечить развивающиеся бизнес-процессы, используемые между департаментами.
По крайней мере, во многих организациях будут сосуществовать SaaS и приложения «on-premise» (Microsoft ссылается на существование двойственных моделей, в которых приложение, установленное на ПК, может быть усилено онлайновой функциональностью, это видно на примере медиа-плееров, таких как Windows Media Player).
Таким образом, SaaS сможет продвигаться не в направлении повышения эффективности оперативной деятельности, а в направлении помощи фирмам в повышении эффективности. Предоставление пользователям возможности настраивать названия полей на экране, как например, это реализовано в сервисе SalesforceСom, нельзя назвать настоящей дифференциацией. Так же как и предоставление пользователям возможности писать на JavaScript (или аналогах) и устанавливать унифицированный указатель ресурсов (URL) для записи в пользовательском поле или использовать доступ к вкладкам или таблицам стилей, - то, что SalesforceCom называет «настройкой».
Это напоминает понятие «a-ha» из «опыта пользователей iPod», которое позволяет пользователям слушать и обрабатывать любимую музыку по-новому, проще, понятнее и привлекательнее. Если компании стремятся выделиться, нельзя управлять бизнес-процессами так, как они это делали в прошлом, и это подразумевает создание новых свойств и потоков между подразделениями и между организациями. Таким образом, остается выяснить, насколько поможет в этом вопросе Apex - разработка SalesforceCom – наиболее свежий многопользовательский интерпретируемый язык. Apex, виртуальная машина, обладающая синтаксисом Java и функциональностью процедурного языка PLSQL (СУБД, используемая SalesforceCom от Oracle), был разработан для работы с интерфейсом прикладного программирования (API).
Apex ограничил функциональность, которая теперь выполняет только то, для чего он была разработана (например, специальные триггеры базы данных и хранимые процедуры), и на самом деле это - не язык программирования общего назначения, требуемый для обеспечения обычного пользовательского программирования. Повторим, преимущества управляемой среды приходят от недостатков ограничений в возможностях подгонки. Предприятия хотят в большей степени контролировать ПО, так как они вынуждены постоянно изменять конфигурацию, чтобы добавлять новые продукты, развивать более тесную интеграцию между системами и внедрять лучшие бизнес-процессы.
По перечисленным причинам даже SalesforceСom пытается расширить узко-определенную модель, которую они начинали как CRM/SFA компанию. Наибольшие усилия прикладываются к партнерской платформе AppExchange и системе сторонних приложений так, чтобы расширить их функциональные рамки и создать более дифференцированные бизнес-процессы с возможностью заказа.
Время покажет, как будет работать данная стратегия с бизнес-аналитикой поставщика (BI) и партнерами по интеграции данных (в том числе такие заметные компании, как например, Business Objects, Informatica, или Pervasive Software); партнерами в сфере управления стимулированием (EMI), например Centive, Xactly Corporation, Cellarstone, или PerksСom (чьи функциональные возможности и планируемые процессы «что, если…?» должны быть способны влиять на поведение торгового персонала в сторону увеличения дохода); партнерами по конфигурации продуктов и по управлению отношениями с партнерами (PRM)/управлению цепочкой запросов (DCM) (такими как Selectica, Comergent, Webcom Inc., Big Machines, Firepond и т.д.); партнерами по автоматизации маркетинга, по аналитике и т.д. Более того, недавнее усиление некоторых партнеров AppXchange идет от вертикального развития финансовых услуг и, впоследствии, построения стратегии к ближайшим областям, таким как страхование, СМИ, банковская деятельность и т.д.
Что касается Apex, он также построен на многопользовательской архитектуре, что означает, что каждая программа, созданная пользователем, отделяется от программ других пользователей, даже если все пользователи запускают один и тот же экземпляр SalesforceCom. В то время как это обособление программ должно увеличить возможности отдельных пользователей по настройке собственных систем, некоторые партнеры AppXchange выразили беспокойство по поводу дробления их бизнеса и потребностей для их решений.
Совсем недавно в середине декабря 2006 компания SalesforceCom представила свое видение AppStore и стратегии получения денег на рынке AppExchange (Apex). Клиенты смогут использовать AppStore в качестве единственного источника для опробования, покупки и использования приложений «on demand» на AppExchange. AppStore очевидно, обеспечит полным пакетом коммерческих услуг и программ по распределению доходов для разработчиков и партнеров (полностью автоматическая модель продаж, целиком управляемая ).
Разработчики и партнеры смогут использовать AppStore как общую распределительную сеть, чтобы рекламировать, продавать, выставлять счета и доставлять приложения, построенные с использованием языка программирования Apex и платформы, ставшей доступной через AppExchange. Есть надежда, что AppStore станет катализатором, раскрывающим ценность Apex и AppExchange, приближающим идею создания, поставки и успеха любого ПО «on demand». Идея здесь состоит в том, что AppStore сделает процесс покупки ПО «on demand» таким же легким, как покупка музыки через iTunes, поскольку AppStore снимет с партнеров нагрузку и затраты по построению канала продаж и распространения.
Дополнительно, глобальные инкубаторы AppExchange помогут компаниям разрабатывать новые продукты на платформе Apex и помогут увеличить успех уже существующих партнеров AppExchange. 10 компаний уже подписались на инкубатор AppExchange, включая Appirio, Avankia, Centive, Convenos, DomoDomain, InsideView, InvisibleCRM, Right90, VerticalResponse и Xactly.
SalesforceCom обещает обеспечить партнеров услугами AppStore за процент от дохода по заключенным сделкам, который будет зависеть от объема предоставляемых услуг. В настоящий момент планируется предлагать услуги AppStore поэтапно в течение 2007 года: Standard Referral в первом квартале 2007, Premium Referral в третьем квартале и AppStore Checkout – в четвертом. Клиенты, которые покупают приложения Salesforce.com, должны принимать решения о покупке, основываясь на свойствах, которые уже доступны на существующей платформе Apex, они не должны стоить дополнительных денег при использовании сервисов Apex. Как было объявлено ранее, следующий выпуск платформы Apex планируется сделать доступным в связке с выпуском Salesforce Winter 07, и в первой половине 2007 года планируется открыть доступ к языку программирования Apex.
Возвращаясь к списку реальных или осознаваемых ограничений SaaS, есть два основных повода для беспокойства: первый – как безопасно регулировать и управлять интеграцией между данными «on-premise» и содержимым, и, второй вопрос - что произойдет со множеством восприимчивых данных и собранной информацией, когда клиент расторгнет соглашение с поставщиком SaaS. Также, многие региональные IT-менеджеры будут недовольны идеей бросить часть их «IT вотчины» и необходимостью полагаться на способность внешнего хостинга безошибочно запускать их информационные центры, даже если хостинг надежен. В конце концов, основным остается вопрос, действительно ли распространение SaaS готово к круглосуточной поддержке сложных глобальных предприятий строго в соответствии с договором о сервисном обслуживании (SLAs).
Эти вопросы, вместе с новой, растущей осведомленностью рынка, могут объяснить результаты некоторых недавних исследований, показывающих, что свыше 60% предприятий в настоящее время все еще предпочитают постоянное лицензирование модели «on-premise» возможностям подписки. Фактически, большинство партнеров SalesforceCom AppXchange все еще ратуют за бизнес «on-premise» и обычно жалуются, что только от 10 до 30 процентов (максимум) дохода поступает от альянса с SalesforceCom. Также, большинство поставщиков SaaS представляют себя как поставщиков ПО, даже если на самом деле они смешивают ПО и консалтинговые услуги, из-за чего понимание этих услуг и их экономики (как от основного поставщика, так и от его партнерской сети) все еще в стадии разработки. К текущему моменту, такая постановка вопроса в основном выражается в виде фиксированной системы и платы за консалтинг до того, как клиент сможет перейти на услуги подписки в чистом виде. Отношения Accenture с SalesforceСom и благословенны, и противоречивы, этот партнер показывает серьезную поддержку модели поставок SaaS, но также следует ожидать значительных цен на консалтинг за определенные подключения, даже в среде SaaS.
Что касается вопроса лицензирования, наиболее распространенным путем для клиентов остается фиксированная оплата, в соответствии с производительностью используемой машины (или нескольких машин), или другая широко используемая альтернатива, когда предприятие (лицензиат) платит фиксированную плату в соответствии с количеством пользователей (или рабочих мест), использующих ПО.
По правде говоря, оба подхода относительно стабильны, клиент может составлять бюджет, зная формулу расходов, в то время как поставщик получает большой ломоть от дохода за лицензирование авансом и впоследствии стабильный поток ежегодного дохода (обычно от 15 до 20%). Это устойчивая, доходная модель, которая понятна и клиентам, и поставщикам, а привычки тяжело ломаются.
Другая сторона модели хостинга – это долгосрочные затраты на аренду сервисов для клиентов. Одно из основных преимуществ хостинга – это изначальный отказ от предварительных затрат, которые ассоциируются с более быстрым внедрением продуктивной системы (отсутствие необходимости вычищать данные, тестировать и интегрировать системы, обучать пользователей и т.д.). SaaS на самом деле отменяет потребность в отдельном серверном аппаратном обеспечении или хостинге, и уменьшает стоимость апгрейда, стоимость устранения ошибок и установки пакетов обновлений, донастройки, и другой поддержки, которую обычно приходится выполнять внутренней IT-команде предприятия. Однако после определенного периода времени, система по подписке будет обходиться дороже, чем собственная система, и, в конце концов, у клиента нет никаких прав собственности. Привлекательность SaaS - в немедленном удовлетворении потребностей вкупе с уменьшенными начальными затратами, так же как в случае аренды квартиры и мебели по сравнению с их покупкой.
P.J. Jakovljevic
Technology Evaluation Centers inc.
Перевод и адаптация: Алексей Маринин
12NEWS©
Сомнения в возможностях SaaS
Несмотря на успех перечисленных выше компаний, многие все еще скептически относятся к долгосрочному успеху SaaS. Восприимчивость к данным, конфиденциальность и безопасность (вне защитной системы пользователя), гибкость системы, и тревожные сообщения о недавних сбоях, получивших широкую огласку (которые переходят в беспокойство о производительности системы в целом), - это только некоторые из проблем, которые продлят жизнь приложениям «on-premise». Вдобавок к данным поводам, список сомнений возглавляют вопрос о том, могут ли хостинговые приложения «on-demand» быть корректно объединены с существующими приложениями «on-premise» и скептицизм по поводу возможности адаптации SaaS или решений «on-demand» к уникальным бизнес-процессам.
[Перепечатка материалов 12news.ru разрешается только с предварительного согласования с редакцией или автором. Если вы читаете этот материал на другом ресурсе, пожалуйста, сообщите нам об этом editor@12news.ru]
SalesforceСom и другие проповедники SaaS обычно предлагают рабочие решения для таких стандартных бизнес-операций, как расширение возможностей продаж и управление. Многопользовательская архитектура позволяет хранить большие объемы данных клиента в одном экземпляре СУБД на стороне сервера (очень большое количество метаданных, которое требуется поддерживать поставщику). Однако, используя эту архитектуру, их приложения часто не могут предложить компаниям (особенно большим и требовательным) отличительных качеств, которые нужны им для увеличения продаж, доходов и доли рынка. На самом деле, процессы SFA достаточно стандартны и не могут быть источниками дохода, в то время как их функциональность – это просто сбор мнений продавцов о перспективах и уверенность в том, что они соблюдают правила процесса продаж.
Универсальная модель процессов продаж весьма успешна при внедрении, т.к. до сих пор она является наименее изменяемой из всех функций бизнес-процесса. Это позволяет организации - клиенту быстро внедрять такие решения, потому что, инструменты, которые будут использоваться, не повлияют на другие подразделения внутри организации. При таком отношении нет смысла тщательно настраивать системы SFA, так как это не очень значимая часть процесса продаж.
Если подходить системно, процесс планирования упреждающе влияет на результат. И те организации, которые попытались объединить отдельную функцию SFA с прогнозированием, выполнением заказов и бухгалтерским учетом, выполненными на основе SaaS, натолкнулись на дополнительные трудности.
Другими словами, напоминая известное «правило 80-20», те итоговые 20 процентов или около того, которые отделяют компанию от ее конкурентов, часто нельзя обеспечить решениями SaaS. Необходимость дифференциации потребует от предприятий поиска более традиционных ИТ поставщиков, которые компетентны в специализированных областях и общей функциональности, чтобы обеспечить развивающиеся бизнес-процессы, используемые между департаментами.
По крайней мере, во многих организациях будут сосуществовать SaaS и приложения «on-premise» (Microsoft ссылается на существование двойственных моделей, в которых приложение, установленное на ПК, может быть усилено онлайновой функциональностью, это видно на примере медиа-плееров, таких как Windows Media Player).
Таким образом, SaaS сможет продвигаться не в направлении повышения эффективности оперативной деятельности, а в направлении помощи фирмам в повышении эффективности. Предоставление пользователям возможности настраивать названия полей на экране, как например, это реализовано в сервисе SalesforceСom, нельзя назвать настоящей дифференциацией. Так же как и предоставление пользователям возможности писать на JavaScript (или аналогах) и устанавливать унифицированный указатель ресурсов (URL) для записи в пользовательском поле или использовать доступ к вкладкам или таблицам стилей, - то, что SalesforceCom называет «настройкой».
Это напоминает понятие «a-ha» из «опыта пользователей iPod», которое позволяет пользователям слушать и обрабатывать любимую музыку по-новому, проще, понятнее и привлекательнее. Если компании стремятся выделиться, нельзя управлять бизнес-процессами так, как они это делали в прошлом, и это подразумевает создание новых свойств и потоков между подразделениями и между организациями. Таким образом, остается выяснить, насколько поможет в этом вопросе Apex - разработка SalesforceCom – наиболее свежий многопользовательский интерпретируемый язык. Apex, виртуальная машина, обладающая синтаксисом Java и функциональностью процедурного языка PLSQL (СУБД, используемая SalesforceCom от Oracle), был разработан для работы с интерфейсом прикладного программирования (API).
Apex ограничил функциональность, которая теперь выполняет только то, для чего он была разработана (например, специальные триггеры базы данных и хранимые процедуры), и на самом деле это - не язык программирования общего назначения, требуемый для обеспечения обычного пользовательского программирования. Повторим, преимущества управляемой среды приходят от недостатков ограничений в возможностях подгонки. Предприятия хотят в большей степени контролировать ПО, так как они вынуждены постоянно изменять конфигурацию, чтобы добавлять новые продукты, развивать более тесную интеграцию между системами и внедрять лучшие бизнес-процессы.
По перечисленным причинам даже SalesforceСom пытается расширить узко-определенную модель, которую они начинали как CRM/SFA компанию. Наибольшие усилия прикладываются к партнерской платформе AppExchange и системе сторонних приложений так, чтобы расширить их функциональные рамки и создать более дифференцированные бизнес-процессы с возможностью заказа.
Время покажет, как будет работать данная стратегия с бизнес-аналитикой поставщика (BI) и партнерами по интеграции данных (в том числе такие заметные компании, как например, Business Objects, Informatica, или Pervasive Software); партнерами в сфере управления стимулированием (EMI), например Centive, Xactly Corporation, Cellarstone, или PerksСom (чьи функциональные возможности и планируемые процессы «что, если…?» должны быть способны влиять на поведение торгового персонала в сторону увеличения дохода); партнерами по конфигурации продуктов и по управлению отношениями с партнерами (PRM)/управлению цепочкой запросов (DCM) (такими как Selectica, Comergent, Webcom Inc., Big Machines, Firepond и т.д.); партнерами по автоматизации маркетинга, по аналитике и т.д. Более того, недавнее усиление некоторых партнеров AppXchange идет от вертикального развития финансовых услуг и, впоследствии, построения стратегии к ближайшим областям, таким как страхование, СМИ, банковская деятельность и т.д.
Что касается Apex, он также построен на многопользовательской архитектуре, что означает, что каждая программа, созданная пользователем, отделяется от программ других пользователей, даже если все пользователи запускают один и тот же экземпляр SalesforceCom. В то время как это обособление программ должно увеличить возможности отдельных пользователей по настройке собственных систем, некоторые партнеры AppXchange выразили беспокойство по поводу дробления их бизнеса и потребностей для их решений.
Совсем недавно в середине декабря 2006 компания SalesforceCom представила свое видение AppStore и стратегии получения денег на рынке AppExchange (Apex). Клиенты смогут использовать AppStore в качестве единственного источника для опробования, покупки и использования приложений «on demand» на AppExchange. AppStore очевидно, обеспечит полным пакетом коммерческих услуг и программ по распределению доходов для разработчиков и партнеров (полностью автоматическая модель продаж, целиком управляемая ).
Разработчики и партнеры смогут использовать AppStore как общую распределительную сеть, чтобы рекламировать, продавать, выставлять счета и доставлять приложения, построенные с использованием языка программирования Apex и платформы, ставшей доступной через AppExchange. Есть надежда, что AppStore станет катализатором, раскрывающим ценность Apex и AppExchange, приближающим идею создания, поставки и успеха любого ПО «on demand». Идея здесь состоит в том, что AppStore сделает процесс покупки ПО «on demand» таким же легким, как покупка музыки через iTunes, поскольку AppStore снимет с партнеров нагрузку и затраты по построению канала продаж и распространения.
Дополнительно, глобальные инкубаторы AppExchange помогут компаниям разрабатывать новые продукты на платформе Apex и помогут увеличить успех уже существующих партнеров AppExchange. 10 компаний уже подписались на инкубатор AppExchange, включая Appirio, Avankia, Centive, Convenos, DomoDomain, InsideView, InvisibleCRM, Right90, VerticalResponse и Xactly.
SalesforceCom обещает обеспечить партнеров услугами AppStore за процент от дохода по заключенным сделкам, который будет зависеть от объема предоставляемых услуг. В настоящий момент планируется предлагать услуги AppStore поэтапно в течение 2007 года: Standard Referral в первом квартале 2007, Premium Referral в третьем квартале и AppStore Checkout – в четвертом. Клиенты, которые покупают приложения Salesforce.com, должны принимать решения о покупке, основываясь на свойствах, которые уже доступны на существующей платформе Apex, они не должны стоить дополнительных денег при использовании сервисов Apex. Как было объявлено ранее, следующий выпуск платформы Apex планируется сделать доступным в связке с выпуском Salesforce Winter 07, и в первой половине 2007 года планируется открыть доступ к языку программирования Apex.
Дополнительные предостережения
Возвращаясь к списку реальных или осознаваемых ограничений SaaS, есть два основных повода для беспокойства: первый – как безопасно регулировать и управлять интеграцией между данными «on-premise» и содержимым, и, второй вопрос - что произойдет со множеством восприимчивых данных и собранной информацией, когда клиент расторгнет соглашение с поставщиком SaaS. Также, многие региональные IT-менеджеры будут недовольны идеей бросить часть их «IT вотчины» и необходимостью полагаться на способность внешнего хостинга безошибочно запускать их информационные центры, даже если хостинг надежен. В конце концов, основным остается вопрос, действительно ли распространение SaaS готово к круглосуточной поддержке сложных глобальных предприятий строго в соответствии с договором о сервисном обслуживании (SLAs).
Эти вопросы, вместе с новой, растущей осведомленностью рынка, могут объяснить результаты некоторых недавних исследований, показывающих, что свыше 60% предприятий в настоящее время все еще предпочитают постоянное лицензирование модели «on-premise» возможностям подписки. Фактически, большинство партнеров SalesforceCom AppXchange все еще ратуют за бизнес «on-premise» и обычно жалуются, что только от 10 до 30 процентов (максимум) дохода поступает от альянса с SalesforceCom. Также, большинство поставщиков SaaS представляют себя как поставщиков ПО, даже если на самом деле они смешивают ПО и консалтинговые услуги, из-за чего понимание этих услуг и их экономики (как от основного поставщика, так и от его партнерской сети) все еще в стадии разработки. К текущему моменту, такая постановка вопроса в основном выражается в виде фиксированной системы и платы за консалтинг до того, как клиент сможет перейти на услуги подписки в чистом виде. Отношения Accenture с SalesforceСom и благословенны, и противоречивы, этот партнер показывает серьезную поддержку модели поставок SaaS, но также следует ожидать значительных цен на консалтинг за определенные подключения, даже в среде SaaS.
Что касается вопроса лицензирования, наиболее распространенным путем для клиентов остается фиксированная оплата, в соответствии с производительностью используемой машины (или нескольких машин), или другая широко используемая альтернатива, когда предприятие (лицензиат) платит фиксированную плату в соответствии с количеством пользователей (или рабочих мест), использующих ПО.
По правде говоря, оба подхода относительно стабильны, клиент может составлять бюджет, зная формулу расходов, в то время как поставщик получает большой ломоть от дохода за лицензирование авансом и впоследствии стабильный поток ежегодного дохода (обычно от 15 до 20%). Это устойчивая, доходная модель, которая понятна и клиентам, и поставщикам, а привычки тяжело ломаются.
Другая сторона модели хостинга – это долгосрочные затраты на аренду сервисов для клиентов. Одно из основных преимуществ хостинга – это изначальный отказ от предварительных затрат, которые ассоциируются с более быстрым внедрением продуктивной системы (отсутствие необходимости вычищать данные, тестировать и интегрировать системы, обучать пользователей и т.д.). SaaS на самом деле отменяет потребность в отдельном серверном аппаратном обеспечении или хостинге, и уменьшает стоимость апгрейда, стоимость устранения ошибок и установки пакетов обновлений, донастройки, и другой поддержки, которую обычно приходится выполнять внутренней IT-команде предприятия. Однако после определенного периода времени, система по подписке будет обходиться дороже, чем собственная система, и, в конце концов, у клиента нет никаких прав собственности. Привлекательность SaaS - в немедленном удовлетворении потребностей вкупе с уменьшенными начальными затратами, так же как в случае аренды квартиры и мебели по сравнению с их покупкой.
P.J. Jakovljevic
Technology Evaluation Centers inc.
Перевод и адаптация: Алексей Маринин
12NEWS©
© Галактика, 2007
© Издание 12NEWS (ИП Маринин А.Л.), 2007
