Преимущества разработки автоматизированной системы управления специализированной фирмой

В большинстве случаев целесообразно заказывать систему на стороне, а не

создавать собственное подразделение разработчиков. Почему так происходит, рассмотрим ниже.

Нередко случается так, что руководство нанимает "околокомпьютерного

мальчика", который приносит кучу дискет, на которых записано множество "неофициально" полученных пакетов программ (от редакторов текстов до пакетов трехмерной графики). После этого устанавливают на компьютеры весь этот ворох программ, который венчает легально приобретенная бухгалтерская программа, к примеру "Финансы без проблем". Теперь можно сказать, что офис компьютеризован. Бог в помощь такому руководителю и процветания его фирме!

Но бывает и иной подход. Руководитель дает объявление, что примет на

работу людей, умеющих то–то и то-то, и такие люди находятся. Перед ними

ставится задача создать автоматизированную систему для управления

предприятием... хорошую, очень хорошую, самую лучшую. Не исключено, что это будет "новое платье короля". Более того, нередко так и бывает. Но

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

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

Кратко обозначим основные преимущества внешнего разработчика, которые свойственны ему по определению.

Профессионализм. Внешний разработчик интегрирует не только опыт многих разработок, но и многих "живых" систем, которые ему пришлось автоматизировать.

Реализм. Разработчик должен отчетливо представлять степень реализуемости задания, тем самым предохраняя заказчика от неоправданных затрат финансов и/или времени на нереализуемые проекты. Это, на наш взгляд, самое важное преимущество.

Ответственность. Внешний разработчик несет перед заказчиком юридическую и финансовую ответственность за разработку в полном объеме (в отличие от собственного разработчика).

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

К созданию своих коллективов разработчиков обычно тяготеют те фирмы, которые сами специализируются в этой или близких областях. Собирая или приглашая к себе коллектив разработчиков, фирмы чаще всего имеют в виду, что, выполнив работу для них, данный коллектив впоследствии создаст рыночный продукт, который окупит разработку и сохранит коллектив для последующих усовершенствований созданной программы. Конечно, резон в таком

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

то это ведет к стремительному падению эффективности ее применения.

Руководство в этом случае требует ее доработки, даже когда оно уже

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

Дата добавления: 2014-01-13