Вне тиража - История изменений

BenderBot: 1 версия

2010-03-30T00:00:54Z

1 версия

GalinaTsaturyan в 14:04, 29 марта 2010

2010-03-29T14:04:38Z

BenderBot: 1 версия

2010-02-11T20:26:53Z

1 версия

StasFomin в 19:33, 11 февраля 2010

2010-02-11T19:33:03Z

BenderBot: 1 версия

2010-02-11T19:24:05Z

1 версия

StasFomin в 18:21, 11 февраля 2010

2010-02-11T18:21:22Z

BenderBot: 1 версия

2009-04-09T13:04:19Z

1 версия

StasFomin в 07:38, 9 апреля 2009

2009-04-09T07:38:12Z

WikiSysop: 1 версия

2008-10-23T16:47:58Z

1 версия

StasFomin: категория

2008-09-19T16:10:29Z

категория

Новая страница

[[Категория:Владимир Рахтеенко (Статьи)]]
[[Категория:CIO (Публикации)]]
[[Категория:2006 год (Статьи)]]

* [[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы».

«Вне тиража»<ref>Журнал CIO (Chief Information Officer), №8, 21 августа 2006, стр. 143, текст интервью Владимира Рахтеенко в статье «[http://offline.cio-world.ru/2006/51/282327/ Вне тиража]».</ref>

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

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

Внутренняя разработка — это разработка силами ИТ-специалистов внутри организации.

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

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

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

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

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

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

Гибкость архитектуры и возможность масштабирования при изменении бизнес-процессов не свойственны ПО собственной разработки, несмотря на то, что руководители зачастую убеждены в обратном. Бытует мнение, что «если своим прикажем — все сделают». Однако в реальности бессистемное развитие решений рано или поздно достигает своего предела. Для тиражных решений архитектурная гибкость может быть обеспечена только отчасти. Ее относительно несложно добиться для количественных, линейных характеристик в рамках заданной отраслевой модели, но гораздо труднее — для масштабирования логики бизнеса.

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

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

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

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

== Ссылки ==
<references />

{{replicate-from-custiswiki-to-lib}}

@@ Строка 1: / Строка 1: @@
-;Автор:[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы».
+;[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы» (CustIS).
-* «Вне тиража» («Риск под контролем. Внедрение коммунальной биллинговой системы»)<ref>Журнал CIO (Chief Information Officer), № 8, 21 августа 2006, стр. 143, текст интервью Владимира Рахтеенко в статье «[http://offline.cio-world.ru/2006/51/282327/ Вне тиража]».</ref>
+:Текст интервью Владимира Рахтеенко в материале Елены Некрасовой '''«Вне тиража»'''
 Многие предприятия уже отказались от программного обеспечения собственной разработки в пользу серийно выпускаемых систем. Тем не менее, нередко встречаются ситуации, когда необходимость информатизации какого-либо процесса уже назрела, а подходящее готовое решение, учитывающее необходимую специфику и проверенное на других российских предприятиях, найти невозможно. В каких сферах деятельности доля ПО собственной разработки, из-за дисбаланса спроса и предложения, пока велика? Создается оно штатными программистами или специализированными фирмами, в чем преимущества и недостатки каждого пути? Как обеспечить масштабируемость оригинального ПО и его интегрируемость с другими приложениями?
 На наш взгляд, следует различать три типа решений: внутренние разработки, тиражные и заказные.
@@ Строка 10: / Строка 13: @@
 Тиражное решение — это проект внедрения готового продукта с привлечением внешнего подрядчика. Нужно подчеркнуть, что именно продукта, а не платформы — последнее ближе к заказной разработке.
-Заказная разработка промышленной системы — это проект с участием внешнего профессионального подрядчика, который использует промышленную платформу или инструментарий.
+'''Заказная разработка промышленной системы — это проект с участием внешнего профессионального подрядчика, который использует промышленную платформу или инструментарий.'''
 <graph>

@@ Строка 1: / Строка 1: @@
 ;Автор:[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы».
-* «Вне тиража»<ref>Журнал CIO (Chief Information Officer), № 8, 21 августа 2006, стр. 143, текст интервью Владимира Рахтеенко в статье «[http://offline.cio-world.ru/2006/51/282327/ Вне тиража]».</ref>
+* «Вне тиража» («Риск под контролем. Внедрение коммунальной биллинговой системы»)<ref>Журнал CIO (Chief Information Officer), № 8, 21 августа 2006, стр. 143, текст интервью Владимира Рахтеенко в статье «[http://offline.cio-world.ru/2006/51/282327/ Вне тиража]».</ref>
 Многие предприятия уже отказались от программного обеспечения собственной разработки в пользу серийно выпускаемых систем. Тем не менее, нередко встречаются ситуации, когда необходимость информатизации какого-либо процесса уже назрела, а подходящее готовое решение, учитывающее необходимую специфику и проверенное на других российских предприятиях, найти невозможно. В каких сферах деятельности доля ПО собственной разработки, из-за дисбаланса спроса и предложения, пока велика? Создается оно штатными программистами или специализированными фирмами, в чем преимущества и недостатки каждого пути? Как обеспечить масштабируемость оригинального ПО и его интегрируемость с другими приложениями?

← Предыдущая	Версия 00:00, 30 марта 2010
(нет различий)

← Предыдущая	Версия 20:26, 11 февраля 2010
(нет различий)

@@ Строка 86: / Строка 86: @@
 [[Категория:CIO (Публикации)]]
 [[Категория:2006 год (Статьи)]]
+[[Категория:Технологии разработки ПО (Статьи)]]
-−
 {{replicate-from-custiswiki-to-lib}}

← Предыдущая	Версия 19:24, 11 февраля 2010
(нет различий)

← Предыдущая	Версия 13:04, 9 апреля 2009
(нет различий)

@@ Строка 1: / Строка 1: @@
-[[Категория:Владимир Рахтеенко (Статьи)]]
+;Автор:[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы».
-[[Категория:CIO (Публикации)]]
+* «Вне тиража»<ref>Журнал CIO (Chief Information Officer), № 8, 21 августа 2006, стр. 143, текст интервью Владимира Рахтеенко в статье «[http://offline.cio-world.ru/2006/51/282327/ Вне тиража]».</ref>
-[[Категория:2006 год (Статьи)]]
-−
-* [[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы».
-−
-«Вне тиража»<ref>Журнал CIO (Chief Information Officer), №8, 21 августа 2006, стр. 143, текст интервью Владимира Рахтеенко в статье «[http://offline.cio-world.ru/2006/51/282327/ Вне тиража]».</ref>
 Многие предприятия уже отказались от программного обеспечения собственной разработки в пользу серийно выпускаемых систем. Тем не менее, нередко встречаются ситуации, когда необходимость информатизации какого-либо процесса уже назрела, а подходящее готовое решение, учитывающее необходимую специфику и проверенное на других российских предприятиях, найти невозможно. В каких сферах деятельности доля ПО собственной разработки, из-за дисбаланса спроса и предложения, пока велика? Создается оно штатными программистами или специализированными фирмами, в чем преимущества и недостатки каждого пути? Как обеспечить масштабируемость оригинального ПО и его интегрируемость с другими приложениями?
@@ Строка 17: / Строка 12: @@
 Заказная разработка промышленной системы — это проект с участием внешнего профессионального подрядчика, который использует промышленную платформу или инструментарий.
-С моей точки зрения, выбор между этими тремя типами решений необходимо делать, опираясь на следующие критерии:
+<graph>
 * уникальность бизнес-процессов предприятия
-* требования к качеству решения, то есть к надежности, производительности и масштабируемости
+С моей точки зрения, выбор между этими тремя типами решений необходимо делать, опираясь на следующие критерии:
-* гибкость архитектуры решения, простота интеграции
+* уникальность бизнес-процессов предприятия;
-* уровень поддержки и сервиса, предоставляемые поставщиком
+* требования к качеству решения, то есть к надежности, производительности и масштабируемости;
 Возьмем предприятие с уникальными бизнес-процессами, которое намерено автоматизировать свои конкурентные преимущества. Если масштаб задачи невелик и она носит локальный характер, то ему имеет смысл идти по пути внутренней разработки. Если же проект захватит несколько подразделений и коснется жизненно важных бизнес-процессов, то лучшее решение — заказная разработка силами профессионального подрядчика с активным участием собственного департамента ИТ. Организациям с устоявшимися типовыми бизнес-процессами разумно искать тиражное решение.
@@ Строка 29: / Строка 41: @@
 Гибкость архитектуры и возможность масштабирования при изменении бизнес-процессов не свойственны ПО собственной разработки, несмотря на то, что руководители зачастую убеждены в обратном. Бытует мнение, что «если своим прикажем — все сделают». Однако в реальности бессистемное развитие решений рано или поздно достигает своего предела. Для тиражных решений архитектурная гибкость может быть обеспечена только отчасти. Ее относительно несложно добиться для количественных, линейных характеристик в рамках заданной отраслевой модели, но гораздо труднее — для масштабирования логики бизнеса.
 Соответственно, заказной проект, при надлежащем подходе, призван обеспечить наибольшую функциональную гибкость. Можно даже сказать больше: функциональная гибкость является необходимым условием выживания компании, которая специализируется на заказной разработке. Объясняется это достаточно просто. Клиенты готовы мириться с тем, что тиражный продукт не особенно «приспособляем», ведь этот продукт произведен для многих и не может в полной мере учитывать особенности каждой компании. В то же время, заказная разработка делается «на себя», и клиент выбирает подрядчика в полной уверенности, что тот будет поспевать за высокой динамикой требований к системе.
@@ Строка 40: / Строка 82: @@
 == Ссылки ==
 <references />
 {{replicate-from-custiswiki-to-lib}}

← Предыдущая	Версия 16:47, 23 октября 2008
(нет различий)