Шрифт:
А с чем же останется наш заказчик? Никаких гарантийных обязательств по этой работе у него не осталось, так как работа производилась его персоналом. Со всеми пожеланиями о доработках ему придется обращаться теперь к самостоятельному коллективу и, как говорится, «за отдельную плату».
Следует вывод, что пойдя по пути самостоятельной разработки, при очень малой вероятности хорошего результата, он получает то, от чего хотел уйти [4] .
О преимуществах готовых продуктов
Нередко перед нами возникает проблема: купить готовое или заказать изготовление продукта по своему вкусу? Как мы подходим к ее решению?
Чаще всего, мы сначала поищем готовый продукт. Если подходящего не найдем, то принимаем решение заказать изготовление того, что нам необходимо. Но возникает очередная задача: у кого заказать? Конечно, у того, кто сделает то что нам нужно.
А вот здесь-то и возникает одна из главных проблем: как угадать того, кто это сделает?
Во-первых, поинтересуемся, делал ли он уже то, что надо нам.
Во-вторых, узнаем у прежнего заказчика, доволен ли он.
В-третьих (а может, и во-первых), узнаем, во что нам обойдутся услуги изготовителя.
Если все что мы узнали, нас устраивает, то заказываем работу.
А можем ли мы быть уверены, что получим то, что нам хотелось?
Вряд ли. Потому что осталось еще много вопросов, на которые мы не получили ответа из-за того, что не знали, как их задать.
Это длинное вступление – только для того, чтобы показать, что заказная работа, точнее ее результат, это всегда в той или иной степени «вещь в себе». Мы никогда не знаем заранее, как полученный продукт поведет себя в использовании и насколько будет подходить нам. По этой причине с момента вступления цивилизации в машинную эру люди предпочитают готовые продукты. В готовом продукте не надо угадывать, насколько он подойдет нам, это можно проверить сразу. Конечно, остается проблема скрытых дефектов, но она решаема.
Обо всем этом не стоило бы говорить, если бы речь шла о традиционных продуктах. Но на нашем рынке появились другие, новые продукты – программные. И подчас житейская мудрость не срабатывает.
Несть числа примерам, когда вместо того чтобы купить готовую программу, которая может быть и не отвечает всем интуитивным пожеланиям, но выполняет все необходимые функции, заказывается разработка того же самого, но «с перламутровыми пуговицами». В результате заказчик «перламутровые пуговицы», конечно, получает, но…
Рыночный продукт проверяется всеми, кто его приобрел, и ошибки, без которых программ не бывает, выявляются тем быстрее, чем больше покупателей у этого продукта.
Если фирма-производитель желает оставаться на рынке, то по мере выявления ошибок она их исправляет и программа становится все более надежной. Появляется опыт в использовании, который переносится производителем на его продукт, в результате чего этот продукт постоянно улучшается. Также постоянно улучшаются инструкции по его применению, что облегчает работу с ним пользователя.
Всего этого лишены программы, разработанные по заказу. Редкий разработчик согласится бесплатно в течение длительного времени вносить улучшения в сделанную и оплаченную работу.
Почему разработчик рыночного продукта это делает? Потому что надеется на дальнейшие продажи и расширение объема продаж. (Не одно и то же?)
Однако нет правил без исключений. Существуют фирмы, чьим продуктом является заказная разработка, но в этом случае разработка – такой же продукт. Это всегда разработка в определенной области, на одних и тех же средствах, с тем же стремлением к увеличению заказов, поэтому все выводы о продукте относятся к разработкам таких фирм.
4
Прошедшие более двадцати лет с момента опубликования этой статьи подтвердили справедливость приведенных рассуждений. Однако проявился еще один аспект. Известно несколько случаев, когда, заказав разработку системы автоматизации самостоятельной фирме, впоследствии предприятие, безусловно достаточно крупное, покупало всю фирму-разработчика и делало ее своим подразделением. Как всегда, эти исключения только подтвердили правильность вышеприведенных рассуждений. Альянс разработчика и заказчика целесообразен тогда, когда горизонт развития продукта интересен для разработчика, а риск потери полученных результатов опасен для заказчика. В этом случае фирма-разработчик уходит с рынка.
Кратко обозначим основные преимущества внешнего разработчика, которые свойственны ему по определению.
Профессионализм. Внешний разработчик интегрирует не только опыт многих разработок, но и многих «живых» систем, то есть реальных предприятий, которые ему пришлось автоматизировать.
Реализм. Внешний разработчик вынужден отчетливо представлять степень реализуемости задания, тем самым предохраняя заказчика от неоправданных затрат финансов и/или времени на нереализуемые проекты. На мой взгляд, это самое важное преимущество.
Грубовато, но ярко обозначил эту ситуацию Себастиан Брандт в «Корабле дураков»:
«Наобещает Вам дурак,То, что свершить нельзя никак:«Любую хворь я излечу,Я, мол, и горы сворочу!»Весь мир того не совершит,Что посулить дурак спешит.»Ответственность. Внешний разработчик (в отличие от собственного) несет перед заказчиком юридическую и финансовую ответственность за разработку в полном объеме.
Экономическая целесообразность. Разработку системы может выполнить только подготовленный коллектив, имеющий концептуальные, инструментальные и технологические заделы. На оснащение, обкатку и наработку всего этого уходит немало времени и средств, поэтому при относительно небольших планируемых сроках (до двух лет) на эту работу и несмотря на ее разовый характер на данном предприятии, разработка внешним исполнителем будет стоить дешевле, чем собственным. При иных условиях может быть не так, но это требует детального анализа.
К созданию своих коллективов разработчиков обычно тяготеют те фирмы, которые сами специализируются в этой или близких областях. Собирая или приглашая к себе коллектив разработчиков, они чаще всего имеют в виду, что выполнив работу для них, этот коллектив впоследствии создаст рыночный продукт, который окупит разработку и сохранит коллектив для последующих усовершенствований созданной программы. Конечно, резон в таком подходе есть, и есть примеры успешной его реализации. Однако есть и обратные примеры.
В общем случае, стимулы у коллектива, который находится «на прокорме» в организации (т. е. на постоянной зарплате), гораздо менее сильные, чем у фирмы, которая привлечена для выполнения конкретной работы за конкретное вознаграждение.
Есть еще один психологический момент, связанный с разработкой, выполненной собственным коллективом. После того как работа выполнена и ее стали использовать на предприятии, база данных системы начинает очень быстро насыщаться информацией. Если концепция и средства разработки были выбраны неправильно, то это ведет к стремительному падению эффективности ее применения. Руководство в этом случае требует ее доработки даже тогда, когда уже понимает, что неправильна сама концепция системы. Дело в том, что принять решение о создании или приобретении новой системы – значит, признать свою ошибку при принятии первоначального решения. А это всегда не просто.
Как бы то ни было, если принято решение о создании системы автоматизации организационно-управленческой деятельности, перед руководством может возникнуть, хотя пока и редко, следующий вопрос:
Автоматизация учета или… учет на базе автоматизации?
Главная цель, а также первый результат системной автоматизации в области организационного управления – учет.
Сейчас отчетливо проявилась эта самая больная проблема быстро растущих коммерческих фирм.
Все фирмы, которые уже приобрели нашу систему, на первое место среди причин, побудивших их это сделать, поставили проблему с учетом. Типичные ее следствия – воровство на складах, многократные продажи одного и того же товара, путаница во взаиморасчетах, штрафы за срыв сроков поставок, завышение цен продавцами в коммерческих магазинах и т. п. Несмотря на то что со школьной скамьи мы знали, что «социализм – это учет и контроль», в период развивающегося капитализма это понятие пришлось осваивать заново.