Жанр: Учеба

Руководство по подготовке советского ПО для экспорта

сторінка №2

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

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

Этот критерий включает рассмотрение следующих вопросов:

- обладает ли пакет функциональными возможностями, которые
превосходят потребности клиента в настоящее время, но которые
потребуются в будущем;

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


7. В какой форме поставляется пакет.

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

8. Насколько сложен процесс установки пакета на ЭВМ и связанные
с ним работы.

При этом покупатель рассматривает следующие вопросы:

- какие изменения потребуется сделать в существующей у него
системе, процедурах и методиках;

- потребуется ли изменить структуру файлов и их размещение на
носителях, если да, то как это сделать и когда;

- участвует ли поставщик при установке пакета,на сколько
эффективна его помощь, стоимость такой помощи;

- потребуется ли разрабатывать специальную документацию в
дополнение к той, которую предоставляет поставщик;

- какие требуются людские ресурсы, какое обучение потребуется
для них.

9. Легкость экплуатации пакета пользователем, которая
оценивается по следующим основным моментам:

- разрабатывался ли пакет с ориентацией на вычислительную
систему пользователя и существует ли хорошая документация,
описывающая процедуру эксплуатации пакета на ЭВМ;

- являются ли входные формы и документы, а также инструкции по
их подготовке достаточно ясными и понятными;

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

10. Количество и качество документации, поставляемой с пакетом.
Требования к документации описаны в п. 4.3.

11. Какую поддержку пакета будет обеспечивать поставщик.

Требования к поддержке пакета описанны в п. 4.4.

12. Когда был разработан пакет, как долго он эксплуатируется и
сколько клиентов уже используют пакет.

Ответы на эти вопросы дадут представление об отлаженности,
качестве и эффективности пакета.


13. Какая общая стоимость приобретения и использования пакета.

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

14. Оценка поставщика пакета.

- оценка квалификации и опыта работы на рынке разработчика и
поставщика пакета;

- опыт и известность фирмы-агента, осуществляющий маркетинг
пакета на местном рынке.

15. На каких финансовых условиях продается пакет, т.е.

- возможность покупки и/или аренды;

- какие существуют специфические условия при покупке/аренде;

- существуют ли ограничения на использование или модификацию
пакета, а также на предоставление сервиса по обслуживанию
пакета и какие;

- какая предоставляется скидка при эксплуатации пакета на
нескольких ЭВМ у одного пользователя;

- существуют ли допольнительно оплачиваемые режимы у пакета,
если да, то какая их цена;

- цена за обслуживание и обучение.

4. ОСНОВНЫЕ ТРЕБОВАНИЯ ЗАПАДНОГО РЫНКА.

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

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


4.1. Функциональные требования.

Пакет должен :

- обеспечивать функциональные возможности, достаточные для
решения определенного класса проблем, удовлетворяющие
требованиям конкретной категории покупателей;

- поддерживать широко используемые на рынке ЭВМ и современное
периферийное оборудование;

- обрабатывать информацию и общаться с пользователем с
использованием алфавита и языка, понятного пользователю.

Функциональные возможности пакета 'закладываются' при
разработке пакета на основе анализа и изучения спроса рынка, и
должны соответствовать текущим потребностям рынка и даже
опережать их.

Функциональные возможности отражают те 'идеи', которые
реализует пакет для конкретной области применения.
Конкурентноспособность пакета на рынке в первую очередь
определяется современностью и ценностью алгоритмов и идей,
которые реализованы в пакете.

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

Пакет должен поддерживать современные периферийные устройства,
широко используемые на рынке с данным классом ЭВМ.

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

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


4.2. Характеристики качества.

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

- функциональность, т.е. способность пакета правильно выполнить
набор запланированных или подразумеваемых функций для
удовлетворения требо ваний пользователей ;

- надежность, т.е. способность обеспечить требуемый уровень
работоспособности (без сбойной работы ) при заданных условиях;

- простота использования, т.е. наличие таких атрибутов, которые
позволяют минимизировать усилия пользователя при изучении,
использовании и оценке пакета ;

- экономия ресурсов и времени, т.е. способность пакета
выполнить требуемые функции, используя допустимое количество
ресурсов в определенный отрезок времени ;

- переносимость, т.е. возможность быстрой и легкой настройки
пакета на другое оборудование (среду функционирования);

- сопровождаемость, т.е. наличие таких атрибутов, которые
способствуют минимизации усилий по модификации и внесению
исправлений в пакет;

4.3. Требования к документации.

Документация должна состоять из :
- рекламной,
- эксплуатационной,
- документации разработчика (сопровождения ).

Рекламная документация предназначена для маркетинга (нужд
продавца) и должна содержать основные сведения о пакете
(функциональные возможности, основные характеристики, включая
требования к ЭВМ и памяти, поддерживаемые устройства, условия
эксплуатации; количество уже имеющихся пользователей пакета,
достоинства пакета по сравнению с аналогичными пакетами).


Рекламная документация должна быть на английском или родном
языке пользователя и состоять из проспектов и общих описаний.


Эксплуатационная документация предназначена для пользователей
данного пакета, т.е. :

- системных аналистов, устанавливающих пакет на ЭВМ;

- прикладных аналистов и программистов, использующих пакет
при разработке алгоритма и программировании прикладных программ;

- операторов, осуществляющих прогон пакета на ЭВМ.

Она должна содержать, как правило, следующие документы :

- общее описание (концепции и возможности ) на английском
языке.

- инструкцию по установке пакета в среде операционной системы и
используемого оборудования (ЭВМ );

- иструкцию по эксплуатации ( использованию ) пакета.

- сообщения, выдаваемые пакетом.

- инструкцию по запуску контрольного примера.

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

Документация должна быть написана ясным, доступным языком,
особенно документация для пользователей ПЭВМ.

Документация разработчика предназначается для персонала,
осуществляющего развитие и поддержку данного пакета. Как правило,
должна состоять из :

- тексктового описания логики пакета;

- подробных блок-схем;

- листингов на исходном языке.

Документация разработчика может быть написана на родном языке
разработчика.


4.4. Требования по развитию пакета, обслуживанию и обучению.

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

Разработчик совместно с поставщиком пакета должен обеспечить
следующие основные услуги по обслуживанию пакета у клиентов :

- сгенерировать пакет у клиента, если потребуется ;
- периодически поставлять клиенту изменения к пакету и
документации;

- исправлять возникающие ошибки в программах пакета
(требования по быстроте исправления ошибок зависит от характера
ошибки, частоты использования пакета клиентом - ежедневно,
еженедельно, ежемесячно и т.д.);

- оказывать консультации клиентам по возможностям пакета и его
использованию и применению;

- участвовать в случае необходимости, в совместных с клиентом
проектах с применением данного пакета ;

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

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

4.5. Требования по ценам.

В общем смысле "продажа " программного обеспечения не
означает передачи прав собственности, как например, в случае
продажи оборудования. Под продажей программ понимается
предоставление пользователю лицензии на пользование этими
программами. Пользователь может получить лицензию на пользование
П О бессрочно или на определенный период. Условия оплаты могут
базироваться либо на единовременном платеже либо помесячном.
Обычно первый вариант оплаты применяется за пакеты для ПЭВМ,
второй - за пакеты для больших ЭВМ. Алгоритм образования цен на
программы (пакеты) зависит от многих факторов: конкуренции на
рынке аналогичных пакетов, стоимости разработки пакета, рыночного
спроса на данный класс пакетов, полноты соответствия пакета
требованиям рынка, потенциальной базы клиентов и т.д. Некоторые
из этих факторов, например, стоимость разработки пакета, для
пользователя являются несущественными. С точки зрения
пользователя ценность пакета определяется уровнем его соответствия
требованиям рынка. И, соответственно этому, влияние требований
рынка является определяющим в образовании цены на пакет. В
приложении 3 приведены сведения о стоимости наиболее
распространенных пакетов на рынке Финляндии.

4.6. Маркетинг пакета.

Разработчику (поставщику) пакета на западный рынок следует
четко понимать, что в условиях жесткой рыночной конкуренции
продажа ПО без организации и проведения маркетинга практически
невозможна. Под маркетингом следует понимать процесс выполнения
всего комплекса мероприятий, связанных с выходом на западный рынок
и работой там с клиентами. Как правило, эти мероприятия включают
: приобретение прав от разработчика на маркетинг пакета,
тестирование и 'приведение' пакета к товарному виду, подготовка и
выпуск рекламных, учебных и других информационных материалов,
организация рекламы и демонстрации пакета, определение реальной
цены на пакет, анализ и создание каналов сбыта пакета на рынке,
организация работы с клиентами (обучение, обслуживание, реакция на
жалобы клиентов и т.д.), разработка коммерческих принципов работы
с агентом и/или клиентами (финансовые вопросы, контроль за
сохранением права собственности на пакет), поставка пакета
местному агенту по продаже пакета и постоянная работа с агентом.
Работы по маркетингу выполняют обычно те фирмы, которые берут на
себя роль фирмы-издателя П О (s/w publisher) или фирмы-агента.

5. ТИПИЧНАЯ СХЕМА ОРГАНИЗАЦИИ ТОРГОВЛИ ПО
НА ЗАПАДНОМ РЫНКЕ

В процессе разработки и торговли ПО четко обозначились три
самостоятельных направления : разработка ПО, издание ПО в виде
товара для рынка, продажа и распространение программного товара на
местном рынке западной страны. В соответствии с этим
организационно в этом процессе участвуют, как правило,три стороны:
разработчик ПО, фирма, выполняющая роль издателя ПО (s/w
publisher), фирма-агент осуществляющая работу с пакетом на местном
рынке.

Разработчик проектирует и разрабатывает первоначальную версию
пакета. Он являтся собственником пакета и остается им в будущем,
когда пакет будет доведен до уровня товара и будет продаваться на
рынке. Разработчик ищет фирму, которая могла бы выполнять роль
фирмы-издателя его пакета как товара и которой он продает право на
такие работы.


Фирма-издатель (s/w publisher) берет на себя все функции по
доведению пакета до товарного вида, организации маркетинга и
продажи пакета.

Таким образом фирма-издатель ПО выполняет следующие основные
виды работ:

- приобретает от разработчика право маркетировать его пакет;

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

- разрабатывает и издает рекламные и другие материалы по
маркетингу пакета;


- оформляет внешний вид и издает пакет в 'товарном виде'
(наглядные и яркие обложки для документации, коробки для упаковки
пакета при поставке пользователям и т.д.);

- организует и проводит рекламу, демонстрации пакета
потенциальным пользователям;

- определяет цены на пакет, анализ и выбирает возможные каналы
сбыта пакета на рынке;

- разрабатывает основные принципы контракта с клиентами и
агентами по продаже пакета в других странах;

- организует работы по поддержке пользователей пакета
(обучение, обслуживание пакета, реакция на жалобы и отказы от
пользования пакетом);

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

Фирма-издатель организует продажу пакета через агентов.
Агенты работают на местном рынке (или определенном регионе страны)
и выполняют следующие основные работы:

- организацию тиражирования, складирования и быстрой поставки
пакета местным пользователям;

- поиск конкретных клиентов пакета на местном рынке или в своем
регионе рынка;

- заключение контрактов с пользователями, выставление счетов и
контроль своевременного получения оплаты от пользователей;

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

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

5.1. Соотношение затрат при разработке и торговле ПО

В западной (рыночной) системе хозяйствования любое дело
(работа) ориентировано на создание товара и продажу его на рынке и
называется общим термином - бизнес (английский эквивалент -
business).

Применительно к ПО имеется аналогичный термин - софтвер
бизнес (software business), который включает все работы , начиная
с разработки ПО, доведения его до уровня продукта и кончая
продажей этого продукта на рынке и получением коммерческого
результата. В дальнейшем будем пользоваться этим термином в
вышеприведенном смысле.



Любая западная фирма, занятая софтвер бизнесом, выполняет
(или должна организовать выполнение через кооперацию с другими
фирмами) следующие основные виды работ :

- управление деятельностью (бизнесом);
- разработку ПО;
- маркетинг и продажу;
- обслуживание и развитие.

Анализ деятельности американских фирм, занятых софтвер
бизнесом, показывает, что затраты на выполнение указанных
категорий работ по отношению к обороту фирмы варьируют в следующих
пределах :

- управление деятельностью - 15 - 30% ;
- программирование - 5 - 25% ;

(в источнике, откуда взята эта статистика, приводятся данные
только для этапа 'программирование', как наиболее понятной части
всего процесса разработки)

- маркетинг - 25 - 40% ;
- обслуживание и развитие - 10 - 25% .

Доход фирм от деятельности в софтвер бизнесе колеблется в
пределах 10 - 45% от оборота.

Применительно к Финляндии в обсолютном денежном исчислении
типичные затраты финской фирмы, занятой софтвер бизнесом,
составляют (в год):

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

---- около 400.000 финских марок;

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

---- около 500.000 финских марок.

6. ОБЩИЙ АНАЛИЗ СООТВЕТСТВИЯ СОВЕТСКОГО ПО
ТРЕБОВАНИЯМ ЗАПАДНОГО РЫНКА.

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

Из общих свойств ПО можно выделить как минимум пять, по
которым советское ПО может не соответствовать требованиям
западного рынка.


1. Общий уровень идей и знаний, реализованных в ПО.

Техническое и технологическое отставание Советского Союза от
мирового уровня во многих областях науки, техники и производства
непосредственно переносится и на то ПО, которое разрабатывается
или применяется в этих областях. Например, ПО, разработанное для
управления устарелыми технологическими линиями производства,
станками, роботами, приборами, и т.д. практического интереса на
Западе не представит. Аналогичная картина может быть и в науке,
медицинской практике и других областях, если в ПО реализованы идеи
и методы давно известные на Западе. Поэтому, одним из первых
моментов, которые должен оценить поставщик ПО на западный рынок, -
это вопрос соответствия мировому уровню (или опережение мирового
уровня) тех идей и методов (или уровня знаний из конкретной
области науки,техники и т.д.), которые реализованы в ПО. Только
ПО, которое в 'идейном' плане соответствует мировому уровню или
опережает его может претендовать на реальный коммерческий успех.


2. Уровень поддержки в ПО современного вычислительного
оборудования и современных операционных систем.

Отставание СССР в области вычислительной техники приводит еще
к одному общему несоответствию советского ПО требованиям западного
рынка. Как правило, советское ПО ориентировано на устаревшие, по
сравнению с западными, версии операционных систем, поколения ЭВМ и
периферийное оборудование. Реализация новых концепций (
направлений ) в разработке прикладного и системного ПО также
существенно отстает от Запада. Например, на Западе с 1989 г.
многие разработки систем ПО ориентированы на концепцию SAA фирмы
ИБМ (SAA- system application architecture).

3. Изолированность и существенное отличие советской системы
хозяйствования от общемировой (западной) не позволяет рассчитывать
на успех на западном рынке многим советским пакетам из области
экономики, финансов, управления производством, методике обучения и
других областях, ориентированных на обработку алгоритмов и
информации, связанных с политической, экономической и правовой
системами.

4. Важной характеристикой пакета является наличие
документации на английском языке ( или на языке западного
пользователя ). В СССР практически отсутствуют пакеты с такой
документацией. И в тех очень редких случаях, когда документация
на пакет подготовлена на английском языке, английская терминология
в ней отличается от принятой английской терминологии в области
обработки данных ( по-видимому, документация готовится методом
перевода с русского языка без редактирования специалистами в
области обработки данных).


5. Известно, что много советского ПО разработано методом
адаптации из западного (например, ПО линий ЕС ЭВМ, СМ ЭВМ, ПЭВМ ).
Адаптированное ПО не только всегда отстает от оригинального в
идейном плане ( т.е. за период адаптации ПО устаревает ), но и не
может соответствовать правовым нормам в области защиты прав
интеллектуальной собственности и патентной чистоты. Поэтому,
маркетинг советского ПО, адаптированного из западного, в общем
случае какой дибо западной фирмой невозможен, не считая
специфических случаев, например, приобретение советской ЭВМ вместе
с ПО с целью возврата их в Союз в составе западных проектов,
например, систем под ключ ( автоматизированные склады, гостиницы и
другие объекты )

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

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

В нижеприведенной таблице приведены основные критерии оценки
соответствия ПО требованиям западного рынка с учетом рассмотренных
в этом разделе вопросов.

Таблица
основных критериев оценки соответствия
советского ПО требованиям западного рынка
_____________________________________________________________

Список сторінок

Поділитися у соцмережах

☏ Замовлення реклами: +3805044-68-872

© Асоціація електронних бібліотек України

☝ Усі матеріали сайту (зокрема статті, зображення, рекламні оголошення тощо) призначені лише для попереднього ознайомлення. Усі права на публікації, представлені на сайті, належать їхнім законним власникам. Просимо Вас не зберігати копії інформації.