Студопедия

КАТЕГОРИИ:

АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника


Коммодитизация программного обеспечения.




 

Но есть еще и программное обеспечение. Как продукт оно, в отличие от компьютерной техники, не имеет осязаемой материальной формы и неизменного облика. Теоретически ПО может принимать неограниченное количество форм для решения неограниченного количества задач. Оно кажется столь же абстрактным и текучим, как сама мысль. Как пишет в своей книге «Переход» (Go To) корреспондент газеты New York Times Стив Лор (Steve Lohr), «программное обеспечение является воплощением человеческой мысли»[45]. Как же текучая и изменчивая человеческая мысль превращается в массовый товар?

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

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

В начале 1950-х годов, когда компьютеры впервые стали использоваться в бизнесе, у компаний не было другого выхода, кроме как разрабатывать собственные программы. Производители компьютерной техники почти не занимались разработкой ПО, а соответствующей специализированной отрасли еще не существовало. Каждая компания, покупающая мейнфрейм, должна была создавать программы для выполнения даже самых элементарных функций, таких как преобразование двоичных чисел в десятичные и наоборот. Учитывая сложность и высокие затраты, разработка надежной программы требовала колоссальных (и, как вскоре выяснилось, бесполезных) усилий. Опасаясь, что затраты на разработку ПО могут отпугнуть покупателей компьютеров, IBM помогла объединиться пользователям ее мейнфреймов серии 700, которые в то время были основными бизнес-компьютерами. Ассоциация, получившая говорящее название Share («Делись»), имела одну главную цель: снижение затрат компаний на ИТ за счет обмена программным обеспечением. В первый год существования Share среди ее членов были распространены около 300 программ, что, по оценке специалистов, позволило сэкономить не менее $1,5 млн[46].

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

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

По мере накопления опыта централизованного обслуживания самых разных клиентов новые фирмы смогли гораздо полнее использовать эффект масштаба, изначально присущего этой отрасли. В то же время их появление способствовало дальнейшей коммодитизации программного обеспечения для бизнеса, инициировав его трансформацию из внутреннего корпоративного ресурса в закупаемый извне. Хотя фирмы-контракторы разрабатывали для клиентов так называемые клиентские приложения, на самом деле эта тенденция кастомизации была скорее кажущейся, чем реальной. Чтобы иметь возможность неоднократно использовать большие фрагменты уже написанных единожды программ для выполнения разных заказов, подрядчики специализировались на конкретных отраслях или бизнес-процессах. Как поясняет специалист по истории программного обеспечения Мартин Кэмпбелл-Келли (Martin Campbell-Kelly), «по мере того как фирмы получали все больше и больше заказов из одной области применения, происходило накопление знаний в области программных средств и ресурсов, благодаря чему они могли и различных сочетаниях использоваться для выполнения заказов от самых разных клиентов»[47]. Только за счет такого многократного использования сложные программы оставались доступными для широкого круга компаний, а разработчики программ получали прибыль.

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

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

Кульминацией развития пакетов программ для бизнеса в 1990-е годы стало введение систем планирования ресурсов предприятия (ERP). Пионером в этой области разработки стала немецкая фирма SAP. Программы, которые разрабатывала эта фирма, должны были решить (и иногда действительно решали) одну из самых болезненных и «дорогих» проблем, стоящих перед современными компаниями: проблему хаоса узкоспециализированных приложений. По мере того как компании, отдельные предприятия или подразделения компьютеризировали одну функцию за другой, возникала проблема, связанная с необходимостью синхронного управления огромным количеством несовместимых программ, написанных на разных языках и требующих разной техники и операционных систем. Несовместимое программное обеспечение не только обусловливало высокие затраты на обслуживание и устранение неполадок. Оно также требовало дополнительной работы и увеличивало количество ошибок, поскольку одни и те же данные приходилось вводить в разные программы в разных форматах. Из-за этого руководители компаний не могли получить целостного представления о работе компании. Они могли видеть только отдельные ее аспекты.

В программном обеспечении SAP и других систем планирования ресурсов, появившихся вслед за ним, основные приложения для управления предприятием (бухгалтерский учет, управление персоналом, планирование производства, ценообразование, продажи) служили модулями единой интегрированной системы. Использование всеми модулями единой базы данных устраняло необходимость в повторном вводе информации, снижало вероятность ошибок и позволяло менеджерам получить гораздо более точное представление о работе компании. Хотя изначально можно было создавать отдельные уникальные элементы системы планирования ресурсов для конкретной отрасли или компании, внешние консультанты при выполнении заказов обычно «подгоняли» стандартные программы к потребностям отдельных потребителей на основе использования стандартизованных средств изменения конфигурации. Таким образом, любая ценная модификация могла быть скопирована другими компаниями. К концу 1990-х годов стало ясно, что масштабная «подгонка» редко стоила затраченных усилий. Компании все чаще предпочитали готовую базовую конфигурацию, понимая, что изменение комплексных программ потребует значительных затрат времени и денег, но не приведет к значимой дифференциации[48].

Более того, системы от разных поставщиков почти не имели функциональных различий. Вне зависимости от того, у кого вы покупали систему управления ресурсами - у SAP, Oracle, PeopleSoft или Вааn, вы получали одни и те же базовые функциональные возможности и одни и те же плюсы и минусы. Различия между программами продолжали стираться, так как поставщики быстро копировали друг у друга все более или менее значимые новшества и каждое новое поколение программ было все более унифицированным. К 1998 году Рей Лэйн (Ray Lane), занимавший тогда пост президента Oracle, признавался, что «потребители не могут обнаружить даже пятипроцентного отличия между продуктами SAP, PeopleSoft и нашей компании»[49].

Как и другие корпоративные системы, которые автоматизировали, например, управление поставками или связями с клиентами, системы управления ресурсами предприятия были крайне сложными, а их создание требовало больших затрат. Даже после того как SAP разработала версию программы для мейнфреймов, ей пришлось дополнительно потратить около $1 млрд на разработку версии для клиентских серверов[50]. Самостоятельно написать для себя подобную программу не смогла бы ни одна компания. Комплексные корпоративные системы могли быть созданы только внешними поставщиками, способными переложить затраты на их разработку на многочисленных заказчиков. Поэтому когда крупные компании выстроились в очередь к поставщикам таких программ, стандартное, массовое программное обеспечение начало работать «в самом сердце» предприятий. И снова в глазах руководителей компаний эффективность от использования единого ПО оказалась ценнее утраченной исключительности.

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

Первые механические станки представляли собой простейшие зажимы, то есть деревянные панели, которые использовались при работе с пилой или фрезой. Чем удачнее мастер продумывал конструкцию такого станка, тем выше была скорость работы и качество продукции. Это давало преимущество и мастеру, и его работодателю. Появление в конце XIX века электроэнергии и электромоторов позволило создавать гораздо более совершенные станки, и возникла новая отрасль экономики - станкостроение. Продавая свое оборудование различным компаниям, такие производители, как Cincinnati Milling Machine Company, смогли добиться экономии за счет эффекта масштаба и распределить высокие затраты на разработку станков между многочисленными потребителями. В первой половине XX века станки быстро совершенствовались благодаря ряду технических изобретений, например зубчатой передачи, гидравлического пресса и электромеханических рычагов. Каждое такое изобретение увеличивало сложность станков, что позволяло повысить точность, скорость и гибкость производственных операций.

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

 


Поделиться:

Дата добавления: 2015-09-13; просмотров: 65; Мы поможем в написании вашей работы!; Нарушение авторских прав





lektsii.com - Лекции.Ком - 2014-2024 год. (0.012 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав
Главная страница Случайная страница Контакты