Вступить в Клуб Войти
Введите логин
Введите пароль
напомнить пароль

Сергей Горшенин, начальник управления информационных технологий и телекоммуникаций, ОАО «Светлана»: «Коробочное или самописное ПО: анатомия выбора»

03.02.2011

Не люди для СИСТЕМЫ, а система для ЛЮДЕЙ!

Когда мне предложили написать эту статью, я вспомнил одну очень старую историю. Шел далекий 1992 г. В учебный класс одной из сельских школ Ставропольского края впервые завезли компьютеры. Тогда это были советские БК 0010-01, они же «бытовые компьютеры».

По сути это был вариант БК-0010 с механической клавишной клавиатурой вместо пленочной и языком Бейсик-86 (BASIC-86), он же «вильнюсский бейсик» в ПЗУ. Интерпретатор языка Фокал перенесен в ПЗУ специального подключаемого модуля МСТД (мониторная система тестирования и диагностики). Этот модуль, помимо запуска тестовых программ, позволял вводить программы в кодах и работать с магнитофоном. Клавиатура данного компьютера приближалась по раскладке к современному стандарту де-факто с четырьмя клавишами управления курсором, но имела чудовищный дребезг контактов, в результате чего у пользователя вырабатывался специфический навык набора текстов аккуратными, но резкими и четкими движениями. Как сейчас помню, меня и еще несколько моих одноклассников привели в компьютерный класс и объявили, что отныне мы будем изучать «новые технологии». Новые технологии в различных вариациях и сейчас на слуху, но тогда для меня это было действительно чем-то новым и выдающимся, и именно тогда у меня появилась мечта: я решил стать программистом. Так что именно благодаря школе я теперь работаю в области ИТ и более того, мне нравится моя работа и профиль деятельности.

С тех пор прошло много лет и событий. Я сменил несколько школ, поступил на специальность 2204 («программное обеспечение вычислительной техники и автоматизированных систем»), получил два высших образования, работал в государственных и коммерческих компаниях, активно участвую в деятельности Санкт-Петербургского клуба ИТ-Директоров… 

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

ПО: границы понятий

Для начала приведу выведенные мной определения данным видам ПО. Поскольку «энциклопедического» разделения пока еще не существует, будем рассматривать вопрос в контексте статьи.

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

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

Очень часто в пользу коробочного ПО приводят доводы о наличии поддержки или детального руководства пользователя. Но за время работы в ИТ-области я видел примеры неудачных «коробок» и, в то же время встречал «самописки», эффективное использование которых позволяло оптимизировать работу в компаниях. Также мне известны случаи, когда самописное ПО впоследствии становилось коробочным.

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

ПО зарубежных разработчиков

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

Таблица 1. Плюсы и минусы ПО зарубежных разработчиков.

 Плюсы  Минусы
 Отсутствие кадровых рисков  Высокая начальная стоимость решения
 Высокая стабильность компании  Крайне низкая скорость реакции на изменения внешней среды
 Отсутствие проблемы ограниченности ресурса  Зачастую отсутствие сопровождения на территории страны заказчика
 Возможен учет мировых практик  Не всегда адекватная реакция на изменения
   Зачастую несоответствие законодательству

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

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

ПО отечественных разработчиков

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

Таблица 2. Плюсы и минусы ПО отечественных разработчиков

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

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

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

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

ПО собственной разработки

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

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

Плюсы и минусы самостоятельно разрабатываемого ПО нашли отражение в таблице 4.

Таблица 4. Плюсы и минусы ПО собственной разработки

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

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

Сразу оговорюсь, что вышесказанное применимо к большинству программного обеспечения собственной разработки. Но и здесь бывают исключения. К ним относятся. например, информационная система ERP класса «Каскад», разработанная и используемая на заводе «Ленполиграфмаш» или успешно эксплуатируемая на заводе «Светлана» ERP-система «Аристотель», предназначенная специально для автоматизации деятельности отечественных ИТ-подразделений, руководство пользователя к которой составляет более 400 страниц. Думаю, у каждого из вас найдется собственный пример.

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

Покупка готового решения вместе с услугами по внедрению

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

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

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

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

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

Разработка собственного решения

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

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

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

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

Но стоит отметить тот факт, что многие тиражируемые решения родились из самостоятельной разработки. Доведенные до финальной стадии, они вышли на коммерческие рельсы, например всем известная «1С:Бухгалтерия», которая как рассказывают, появилась из системы домашнего бюджета. Только уверены ли вы, что именно вашей команде посчастливиться создать успешный продукт и окупить затраты на разработку?

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

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

Источник: IT Manager №12

Сергей Горшенин

Начальник управления информационных технологий и телекоммуникаций

Другие публикации Сергей Горшенин