Григорий Циперман,
директор по консалтингу компании IBS

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

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

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

Если же не отвечать на вышеприведенные вопросы, то результат будет очень печальный. Я проводил аудит в больших компаниях, которые очень активно разрабатывали собственное ПО. И могу сказать: то, что там происходит, — это сущий кошмар. Развитие разработанной когда-то сложной ИУС было направлено только на улучшение пользовательских интерфейсов и переформатирование стандартных отчетов (ибо улучшать системное ядро было уже невозможно: разработчики уволились, а документации нет). В качестве рынка сбыта своих услуг ИТ-подразделение определило конечных пользователей (которых несколько тысяч и которые, естественно, ничего не платят) и постоянно, из года в год, принимало от них заказы на переустановку кнопок на экранных формах. Интересно, что объем работ постоянно возрастал. И вот уже число программистов в штате предприятия перевалило за четыре сотни...

А теперь давайте подумаем, кто стоит за аргументами в пользу индивидуального ПО. Ведь в вопросе индивидуальных и стандартных решений есть определенные программистские интересы, которые стараются повернуть общественное мнение в свою сторону.
Почему в 80-е годы превалировала идея самостоятельной разработки? Потому что риски плохой автоматизации предприятия больше нечем было покрыть. Не было стандартного ПО, и приходилось писать его заново. В 90-е риски покрывались тем, что покупалось стандартное ПО. Конечно, с его появлением возникают новые риски. В чём они состоят? В том, например, что адаптировать предприятие и внедрить систему так, чтобы она была полезна, не всегда удается. Но из этого совершенно не следует, что стандартное ПО надо выбрасывать. Не таким способом надо минимизировать подобные риски...

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

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