Продолжается подписка на наши издания! Вы не забыли подписаться?

Идея открытого конструктора

Зачем нужно объединяться

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

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

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

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

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

Ни одна фирма не потянет создание универсального программного продукта, покрывающего все потребности предприятий. И дело здесь даже не в деньгах. Фирма Микрософт обладает миллиардами долларов, однако, она не пытается создавать программы:

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

Создание общего продукта

Возникает естественный вопрос: что будет базой объединения? Такая база не может ограничиваться пакетом документов, так как пользователям нужна фактическая, а не “бумажная” совместимость. И уж им совсем неинтересно разбираться, состоит ли проблема в:

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

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

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

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

Оценка объема рынка

Общий рынок

Оценим общий объем рынка. Всего в России имеется около 50 тысяч промышленных предприятий, из них прибыльных — порядка 6 тысяч. Полное число юридических лиц в России — около нескольких сот тысяч. Таким образом, можно оценить сверху и снизу объем рынка программных продуктов, измеряемый числом клиентов.

Для оценки объема рынка в долларовом исчислении целесообразно рассмотреть Внутренний Валовой Продукт (ВВП) России. Основная идея состоит в том, что ВВП складывается из объемов продаж предприятий (промышленных, торговых, обслуживания). Среднюю норму прибыли для оценки можно взять порядка 10-20%. При этом предприятие может платить за комплексное оказание услуг:

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

Можно выделить три рынка, связанных с созданием и использованием компьютерных продуктов для автоматизации предприятий:

Оценим каждый из этих трех рынков.

Рынок коробочных продуктов

Приблизительная оценка объема рынка для коробочных продуктов такова.

Предположим, что продукт покрывает все потребности своей рыночной ниши. Средняя цена коробочного программного продукта для автоматизации бизнеса составляет $300. Умножая $300 на 300 000 предприятий, получаем оценку объема рынка сверху в $90 000 000. При этом необходимо учесть, что коробочный продукт живет года три, то есть объем рынка составляет:

$90 000 000 / 3=$30 000 000.

Если же коробочный продукт стоит $100 и его upgrade осуществляется за полцены, то оценка сверху объема рынка падает до $5 000 000.

Не все юридические лица пользуются программными продуктами. А из тех, кто пользуется, часть удовлетворена пиратскими версиями. Все это уменьшает объем ниши отдельной компании на один — два порядка, то есть до сотен и десятков тысяч долларов.

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

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

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

Среднемесячную заработную плату можно принять за $500. Затрат на аренду помещения можно избежать, если, например, работать дома. В среднем на разработку коробочного продукта уходит года два. Таким образом, его себестоимость оказывается равной:

$500 в месяц на человека * 5 человек * 24 месяца = = $60 000.

Коробочный продукт живет года 3, поэтому при расчете точки самоокупаемости издержки по созданию “коробки” разносятся на три года, что определяет минимально допустимый объем продаж, равный $20 тысячам долларов в год.

Много это или мало? Попробуем разделить необходимый объем продаж на стоимость продукта в $300. Получим, что фирма должна осуществлять в год около

$20 000 / $300 = 67

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

Рис. 1. Объем рынка коробочных продуктов и точка самоокупаемости

Если же фирма реализует свой продукт через посредников, то ее доля в цене составляет от 75% до половины. При этом фирма не только продает новые продукты, но и производит обновление старых (upgrade). В случае upgrade делается скидка порядка 50%. Все это, даже при достаточно благоприятных предположениях, поднимает минимальную планку продаж до 12 коробок и обновлений в месяц. Другими словами, покупатель должен приходить каждый второй рабочий день. Фирмам же, производящим более дешевые модули, стоящие, например, порядка $100, приходится преодолевать планку уже в 3 покупателя за два рабочих дня.

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

Объединение фирм в рамках конструктора:

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

Концентрация усилий оборачивается:

Рынок корпоративных систем

Корпоративные системы стоят достаточно дорого: от нескольких тысяч до сотен тысяч долларов. Количество фирм, которые в силах приобрести корпоративную информационную систему (КИС), в общем составляет около нескольких тысяч. Но половина из них надеется справиться с задачей собственными силами, а значительная часть не готова платить реальную цену такой системы. Так как точной статистики нет, примем количество фирм, которые могут купить систему стоимостью до $10 000, за 3 000, а цену такого продукта определим в $5 000. Фирм же, которые могут приобрести информационную систему стоимостью в сотни тысяч долларов, очень немного, и зачастую выбор разработчика диктуют не рыночные условия и механизмы, а интересы тех или иных влиятельных лиц. Поэтому оценим такой рынок в сотню покупателей. Реальное количество клиентов на этом рынке, разумеется, больше, но следует учитывать то, что покупка КИС — одноразовое действие, и количество в 100 покупателей за год можно считать даже завышенным. Среднюю стоимость такой КИС примем за $100 000.

(3 000 * 5 000) + (100 * 100 000) = 15 000 000 + 10 000 000 = $25 000 000

Всего производителей крупных корпоративных систем около десятка. Разделив полный объем рынка на десять, получаем оценку сверху для ниши фирмы, равную нескольким миллионам долларов. Корпоративная система живет гораздо дольше коробочного продукта, поэтому следует учитывать, что приобретение КИС — не единовременное действие, но процесс. Значительную долю прибыли от продаж КИС составляют затраты на сопровождение продукта, достаточно крупные даже в сравнении со стоимостью самой системы.

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

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

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

Совместимость программных модулей маленьких фирм с крупными корпоративными системами дает:

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

Основной результат объединения заключается в том, что:

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

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

Сопровождение, обучение, внедрение

Рынок сопровождения можно оценить в 10% от суммарного объема рынков КИС и коробочных продуктов, то есть в $5 500 000.

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

Так как в случае КИС стоимость обучения и внедрения обычно входит в стоимость самого продукта, то этот рынок можно оценить как 30% от объема рынка коробочных продуктов — то есть приблизительно $10 000 000.

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

Расширение рынков

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

Реклама

Любая реклама систем, созданных с применением такого конструктора, работает на все фирмы, создающие модули, совместимые с конструктором.

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

Продажа

Формирование разветвленной дилерской сети слишком дорого для небольшой фирмы. Однако когда они собираются вместе, получается кумулятивный эффект. Дилеры продают модули всех производителей, а не только своих “родных” фирм. Ввиду специализации эти программные модули дополняют друг друга. Естественно, что объемы продаж стремятся к росту пропорционально числу участников объединения.

Совместная деятельность облегчает также создание инфраструктуры распространения, так как:

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

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

Маркетинг

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

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

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

Итак, если 20% фирм объединяются в рамках конструктора, то объем рынка они увеличивают в несколько раз только за счет оттеснения конкурентов. Однако, помимо углубления рынка, происходит уменьшение издержек. Все это благотворно сказывается на прибыли.

Снова проведем расчеты для фирмы, состоящей из пяти человек:

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

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

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

Что дает новая технология

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

Фирмам, производящим программные продукты

Фирмы, производящие прикладное обеспечение, избавляются от необходимости решать низкоуровневые проблемы. Это особенно важно для фирм, сидящих на “узких” сегментах. Снижение издержек на разработку продукта существенно улучшит их положение.

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

Снятие низкоуровневых проблем позволяет еще:

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

Концентрация на специфике ниши приводит к повышению потребительских качеств продукции, что улучшает ее:

Ускоренное обновление продукции позволяет оторваться от не вошедших в объединение конкурентов и оттеснить их с рынка.

Специализация приводит еще к одному интересному эффекту: конкуренция в рамках конструктора во многих случаях заменяется кооперацией. Классическая схема конкуренции учитывает соперничество:

Конкуренция между одинаковыми продуктами происходит за счет:

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

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

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

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

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

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

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

Трансформация продуктов-заместителей в продукты, дополняющие друг друга, стимулирует кооперацию, что укрепляет почву для оказания сплошных услуг “под ключ”. Оказание сплошных услуг “под ключ” углубляет рынок, так как: повышает качество услуг, увеличивает объем кошелька клиента.

Клиентам

Конструктор много дает и клиентам, что также обеспечивает его конкурентоспособность и право на жизнь. Прежде всего, это:

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

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

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

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

Интеграторам и консультантам

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

Гибкость в работе с клиентами (по цене и системе оплаты, времени, структуре системы, полноте оказываемых услуг)

Объединение в рамках конструктора информационных технологий сохраняет все права отдельных фирм, т.е. право определять:

Рис 2. Заказные системы

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

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

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

Принципы совместной работы

Полная финансовая самостоятельность

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

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

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

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

Ограничения на изменения цены ядра

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

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

Ограниченными для создания ядра ресурсами являются:

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

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

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

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

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

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

Кроме того, в рамках объединения можно договориться о политике контроля цен на ядро. Так, государство контролирует естественные монополии, например, Газпром и РАО ЕЭС. Если же фирма, производящая ядро, решит уйти из бизнеса, то, по условиям соглашения ей придется открыть его программные тексты.

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

Рис 3. Динамика цена во времени

Преимущества структуры, основанной на горизонтальных связях

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

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

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

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

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

Рис. 4. Расширение и сужение поля выбора

Рис. 5. Классическая схема производства и продаж

Рис. 6. Схема производства и продаж в рамках конструктора

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

Низкоуровневое ядро также начинает производиться разными фирмами, скорее всего двумя — тремя. Конкуренция между производителями ядра стимулирует их к:

Маркетинговые исследования, наоборот, производятся совместно, что приводит к экономии издержек. При этом объединяются дилерские и сервисные сети, что:

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

Особенности перехода на новую технологию

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

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

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

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

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

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

Интеграция с новыми технологиями (Internet)

В последнее время идет бурное развитие технологий, связанных с Интернет. У всех на языке крутятся такие слова, как ASP, JSP, DHTML, XML и т.п. Многие прикладные разработчики даже не понимают смысла этих аббревиатур, а некоторые знают, но никогда с ними не работали. С другой стороны, появляются технологии «Бизнес-бизнес» (B2B — Business-to-Business), «Бизнес-клиент» (B2C — Business-to-Client), однако, к сожалению, средней фирме-разработчику программного обеспечения совсем не до этих нововведений. Но перспективы, которые рисуются этими новомодными штучками, весьма радужны, и клиенты все настойчивее требуют от продукта, предлагаемого им, поддержки всех этих стандартов.

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

Ориентация на COM и .Net гарантирует поддержку всех современных технологий, а то, что ядро являются некоторым промежуточным слоем между этими технологиями и прикладным программистом, позволяет безболезненно встраивать поддержку новых технологий. Уже сейчас компоненты нижнего уровня могут легко использоваться совместно с перечисленными выше технологиями. Ведется работа над оптимизацией для платформы .Net, которая пока что находится на стадии Beta-версии.

Низкоуровневые компоненты (средства доступа к данным и средства создания динамических интерфейсов уже сейчас могут с успехом использоваться в ASP-средствах разработки, Delphi, VB, VC, C++Builder и продуктах линейки .Net, что позволяет создавать такие приложения, как Интернет-магазины, Интернет-витрины и корпоративные сайты как с открытой, так и с информацией для внутреннего использования.

Принцип совместной разработки несколькими компаниями позволяет части компаний специализироваться на таких продуктах и в дальнейшем развивать такие направления, как B2B и B2C. А так как компании будут специализироваться именно в этой узкой области, их решения будут наиболее оптимальными и продвинутыми. Наличие ядра сделает их универсальными и совместимыми с модулями, производимыми другими фирмами-разработчиками в других прикладных областях. Фирмам, занимающимся созданием каких-то решений для торговли не обязательно делать Интернет-магазин, они могут полностью специализироваться на розничной или оптовой торговле. При этом другая фирма может создать Интернет-магазин и за счет единого ядра продукты обеих фирм смогут работать с единым банком данных. Это позволяет третьей фирме создать, например, профессиональную систему анализа, которая позволит проводить комплексный анализ всей деятельности предприятия, независимо от того, с помощью какого модуля были внесены данные. А еще какая-то фирма сможет создать электронную витрину, размещающую данные в Интернета, причем данные могут быть получены как непосредственно от ядра, так и из аналитической системы, так как последняя становится программным модулем и позволяет взаимодействовать с собой программным образом.

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

Совместимость же со стандартами позволит взаимодействовать с другими внешними системами в Интернет.

Поддержка перспективных технологий

Как уже говорилось, на сегодня базисной технологией для данного проекта является MS COM. Но уже сейчас проводятся эксперименты и ведется работа по поддержанию новой перспективной технологии Microsoft .Net. Более подробно об этой технологии можно прочитать в журнале «Технология Клиент-Сервер» за 1-й квартал 2001 года, или на сайте www.k-press.ru.

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

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

Переносимость и совместимость

Как следует из нашего повествования, сегодняшнее видение такого многоуровневого конструктора ориентировано на технологии Microsoft, то есть на Windows NT-2000-Net. Мы не рьяные приверженцы Microsoft, но сегодня только Microsoft обеспечивает сервис и общую совокупность технологий, необходимые для решения поставленных задач. Есть, конечно, отдельный набор технологий (CORBA, Частично Java, Perl и др.), которые могут в совокупности обеспечить необходимые возможности для реализации данного проекта, но уровень их интеграции и сервис, который они могут предоставить, далек от идеала. На сегодня более или менее законченным решением можно признать Java, но вопросы производительности и выбора средств разработки неприемлемы для столь большого проекта, который призван объединить много различных компаний. Тем более, что на сегодня только под Windows можно обеспечить уровень сервиса, приемлемый для коробочных продуктов, продающихся большим тиражом.

Это особенно справедливо, если учесть, что на сегодня система Windows стала достаточно мощной операционной системой, поддерживающей многопроцессорность (до 32-х), большие объемы RAM (измеряющихся в гигабайтах), большие объемы жестких дисков (террабайты), а в скором времени появится поддержка 64-битных платформ. Если же технология .Net будет перенесена на другие платформы, то вопрос переносимости отпадет сам собой.

Тем не менее, мы не против использования других технологий, то есть для создания прикладных модулей можно использовать и Java, и CORBA, но при этом необходимо соблюсти программный интерфейс между модулями, то есть данные должны читаться и помещаться в системы с помощью компонентов ядра или низкоуровневых компонентов. Кроме того, необходимо, чтобы прикладные модули, созданные на других технологиях, могли экспортировать программный интерфейс в COM или .Net.

Также возможно создать некоторый слой «интероперабельности», который позволял бы автоматически интерпретировать объекты ядра и прикладные модули в виде, например, CORBA- или Java-интерфейсов, что позволило бы развивать продукт на CORBA или Java, и наоборот, сделать возможным экспорт CORBA- или Java-интерфейсов в универсальный формат COM или .Net, что позволит развивать системы несовместимыми с COM или .Net средствами разработки. Правда, за это должен взяться разработчик, владеющий обеими технологиями в совершенстве.

Рис. 7. Динамика перехода к работе в рамках конструктора

Будущее фирм-одиночек

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

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

Рис. 8. Кривая аккумулированного опыта

Снижение издержек объясняется тем, что по мере работы над программным продуктом происходит накопление знания о:

Создаются дилерские сети, и за фирмой закрепляется ее контингент покупателей. Все это снижает издержки:

При переходе к работе в рамках конструктора информационных технологий по началу придется решать ряд новых проблем:

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

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

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

В качестве примеров такой смены технологий можно привести переход от:

Рис. 9. Смена технологий

Заключение

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

Идеология объединения в рамках конструктора служит для устранения этих проблем.

Тренев Н.Н.

asc - концепция построения масштабируемых финансовых приложений на базе компонентной модели


Copyright © 1994-2016 ООО "К-Пресс"