Вне тиража

Ссылки сюда (2) →

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы» (CustIS).

Текст интервью Владимира Рахтеенко в материале Елены Некрасовой «Вне тиража»

Публикация в журнале CIO (Chief Information Officer), № 8, 21 августа 2006, стр. 143

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

---

Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».