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