Lumier

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

Попытки применить ЭВМ для управления предприятием начались практически сразу после того, как первые, еще несовершенные машины вышли за заборы оборонных НИИ и стали доступны частному потребителю. С той поры времени прошло немало, и можно попробовать подвести некоторые итоги. Не будет преувеличением сказать, что именно в этой отрасли компьютеризации имел место наименьший прогресс, в сравнении с такими отраслями, как секретарско-делопроизводительская, бухгалтерско-экономическая или чертежно-конструкторско-дизайнерская. В банках и крупнейших магазинах (типа питерского «Максидома») можно увидеть нечто похожее на АСУ предприятием, но на производственных фирмах дела обстоят гораздо хуже. Можно смело утверждать, что в нашей стране сейчас нет ни одного предприятия, на котором имелась бы серьезная АСУ. Во всяком случае, сколько-нибудь доступного для широких масс опыта разработки и применения АСУ на реальном производстве не существует. А ведь именно на производстве имеют место наиболее сложные алгоритмы управления, следовательно, и потребность в компьютеризации здесь наибольшая.
С другой стороны, было бы ошибкой утверждать, что наши производственники совсем не занимаются автоматизацией. Еще как занимаются! А результат? А результат выражается очень-очень круглой цифрой из кинокомедии «Как украсть миллион». (Вот уж, действительно, как украсть! Если вы когда-нибудь будете киносценаристом и вам поручат написать сценарий фильма «Как украсть миллиард», то у меня для вас есть кое-что на тему компьютеров и программ).
Значит, снова на повестку дня встают традиционные русские вопросы: кто виноват? И что делать? Попробуем на них ответить.
Обычно используемые пути решения задач автоматизации управления предприятием можно разделить на следующие группы:
* Использование широкоуниверсального программного обеспечения типа Microsoft Excel;
* Приспособление для нужд производства различных складских и бухгалтерско-экономических программ, в изобилии имеющихся на рынке ПО;
* Создание домотканых программ на основе различных методик, от старого верного FoxPro до новомодных Python и др.
Если попытаться одним словом охарактеризовать общий недостаток всех перечисленных подходов, то слово это будет – стихийность. Каждый участник процесса имеет свое видение проблем и по-своему их решает. Если он чистый программист, то плохо представляет, как функционирует реальное производственное предприятие, а при решении каждой конкретной задачи старается применить самые простые алгоритмы. Если же он производственник, то не знает, что такое информация и с чем ее едят (а информацию потребляют – стало быть, едят; если она приготовлена в несъедобном виде, то и сыт ею не будешь). В результате:
* Степень автоматизации крайне низка;
* Отсутствие комплексности: компьютеры на разных рабочих местах не взаимодействуют между собой;
* Каждый работник автоматизирует только свою собственную работу, не задумываясь о том, как это отразится на экономических показателях фирмы в целом;
* Надежность программ низка: программы часто зависают, выдают необоснованные сообщения об ошибках, подолгу задумываются над несложными задачами, а то и просто выдают неверные данные;
* Программы весьма обременительны в эксплуатации: они сами по себе недешевы и работают только на современных высокопроизводительных компьютерах, требуют затраты большого количества человеко-часов на повседневное «окочегаривание», для обеспечения сколько-нибудь стабильной работы обычно необходим квалифицированный системный администратор. В общем, программа требует, требует и требует, и все это сводится к немалым денежным затратам, за которыми экономического эффекта не видно, даже если на самом деле он имеется;
* Невозможно распространение ни самих программ, ни опыта их эксплуатации на другие рабочие места этой же фирмы или на аналогичные рабочие места других фирм.
Это недостатки, лежащие на поверхности. Теперь остановимся подробно еще на нескольких проблемах, которые от внимания специалистов обычно ускользают.
Проблему номер 1 назовем: резерв безответственности. На каждом предприятии время от времени возникают всевозможные недоразумения типа «что-то где-то не так сосчитали». Когда работник замечает такую ситуацию, он сразу же инстинктивно начинает думать о том, на кого свалить вину. Казалось бы, что компьютер для того и нужен, чтобы избежать ошибок. Однако это возможно при условии, что он сам работает вполне надежно и снабжает пользователя всей необходимой информацией. Если же он хотя бы раз даст сбой, то можете не сомневаться: в дальнейшем на него будут вешать всех собак. Компьютер – идеальный козел отпущения: во-первых, он бессловесен, во-вторых, про него точно известно, что он иногда «глючит». Резерв безответственности – очень опасный недостаток, который не только может свести к нулю всю пользу от компьютеризации, но и дискредитирует саму идею. Можно ли его преодолеть? Здесь видится единственный путь: создание чрезвычайно надежных программ. Очевидно, дело это непростое.
Проблема номер 2: УСК – укрощение строптивого компьютера. В отличие от предыдущего абзаца, здесь я имею в виду компьютер, формально находящийся в исправном состоянии и укомплектованный всеми необходимыми программами для решения стоящей перед нами задачи. Однако сам он решать задачу не будет – его нужно заставить. Нынешний заводской специалист, будь то конструктор или технолог, начальник цеха или диспетчер, не имеет возможности работать на своем компьютере в режиме чистого потребителя. Решение любой задачи обрастает огромным количеством всевозможных вспомогательных действий: приходится выполнять замысловатые движения мышью, со снайперской точностью попадая в крошечные значки на панели инструментов… Выполнять эти вспомогательные действия «механически», не задумываясь (как шофер переключает передачи или как конструктор на кульмане чертит линии руками, а в голове держит общий замысел изделия) – невозможно: каждое действие приходится обдумывать. Кроме того, необходимо знать, как все эти операции выполняются, т. е. работнику необходима квалификация уверенного пользователя ПК. Способному инженеру приходится отказывать в приеме на работу только потому, что он не в ладах с Windows. Но даже если такая квалификация имеется, что делать с потерями времени и с огромной умственной и нервной нагрузкой? В конечном счете это выливается в нешуточное повышение трудозатрат, проблемы с кадрами и опять-таки в ошибки в расчетах.
Проблема номер 3 пока без определенного названия. Суть ее в том, что нужно создавать такие программы, которые тянули бы вперед всю нашу организацию, а в конечном счете способствовали бы экономическому развитию страны. Мы же вместо этого создаем их по принципу «от достигнутого» и консервируем в новых программах старые, неэффективные подходы к управлению предприятием. Но это же путь в никуда! Да и сроки создания программ чаще всего таковы, что разработчик просто не успевает за постоянно возрастающими требованиями промышленности.
Лет 15 назад, когда компьютеры еще были непонятны большинству народа, для разъяснения их возможностей специалисты использовали аналогию с каким-то более общедоступным техническим устройством, например с автомобилем. Чтобы вы лучше поняли сказанное, представьте себе такой автомобиль, у которого вместо традиционного руля и педалей – экран и коврик с мышью. Вот вам нужно выполнить правый поворот, и вы с помощью мыши выбираете меню «Повороты», затем «Направо»… В ответ на экран выдается панель для ввода множества параметров: наличие светофора, радиус закругления и т. п. Для полноты картины учтите, что программное обеспечение написано на основании старых правил и что в одном случае из 100000 вместо правого поворота будет выполнено что-то совсем другое. Вам понравится такой автомобиль? На первый взгляд, в таком способе управления есть некий своеобразный спортивный интерес. На самом деле совершенно ясно, что далеко на такой машине не уедешь. Именно поэтому сейчас, как и 100 лет назад, все выпускаемые мировой промышленностью автомобили снабжаются прадедовским рулем и педалями. И даже если руль электронно-бесконтактный, все равно основной принцип остался неизменным: рули направо – и поедешь направо. (Вот за что я люблю свои ржавые «Жигули» и за что ненавижу все компьютеры мира. К сожалению, те и другие в современной жизни равно необходимы).
Вообще параллель между автомобилями и компьютерами может завести очень далеко. Вы, вероятно, что-то слышали про антиблокировочные системы в тормозах, стабилизацию курсовой устойчивости и т. д. За последние годы автомобили стали намного сложнее. Однако управление современным автомобилем ничуть не усложнилось – скорее наоборот! И такие суперсовременные автомобили могут стоять на одном рынке с техникой попроще и подешевле. В мире выпускаются тысячи марок автомобилей, и каждая находит своего покупателя. И с другой стороны: как бы ни были строги ваши технические требования и как бы ни ограничивали вас финансы, вы всегда сможете найти некоторый компромиссный вариант.
Таков магистральный путь развития техники: машины и приборы, которые мы используем, с годами становятся все мощнее и сложнее по своему внутреннему устройству, а работа с ними – легче и приятнее, поэтому они становятся доступны все более широкому кругу пользователей, и в любой отрасли техники имеется широкая гамма продукции на любой вкус и кошелек. Если теперь попросить вас назвать такую отрасль мировой техники, которая развивается по прямо противоположному пути, то вы сразу скажете: компьютерно-программная. За последние 20 лет основные тактико-технические данные компьютеров (тактовая частота процессора, емкость оперативной памяти и винчестера) выросли примерно в тысячу раз. Примерно во столько же раз выросло общее число компьютеров в стране. Такого прогресса больше не было никогда ни в одной области техники! Однако общие субъективные впечатления конечных пользователей, как и производительность их труда, выросли незначительно и, во всяком случае, несоразмерно с параметрами компьютеров.
Что касается цен, то достаточно крутой современный компьютер вполне по карману квалифицированному рабочему или инженеру преуспевающей фирмы. Однако разнообразием компьютерный рынок не блещет. Те компьютеры, которые продаются в магазинах, различаются между собой главным образом внешне, а не техническими параметрами и не архитектурными особенностями. С программами дело еще хуже. Из того, что нужно работникам нашей сферы, практически предлагают лишь несколько вариаций одной и той же системы. По скорости и грузоподъемности эта система едва тянет на уровень «Москвича-401», а по удобству и надежности – сравнивать вообще не с чем: если бы какой-нибудь автомобильный завод стал так же относиться к качеству, его продукция просто не получила бы сертификата годности. Правда, и стоит эта система сущие копейки, так что формально претензий нет.
Однако меня такая дешевизна не очень радует. На своей работе я достаточно высокооплачиваемый специалист, и если мне предложат более мощную систему, я без колебаний выложу за нее сумму в 10 и даже в 100 раз больше. Однако никаких реальных программ, за которые не жалко было бы заплатить, до недавнего времени нам не предлагали. Налицо разрыв между количественным ростом компьютерного «железа» и качественным развитием программного обеспечения.

Здесь самое время обсудить вопрос качества и технического уровня компьютеров и программ вообще. Многие организаторы и руководители производства представляют эту тему совершенно превратно. Обычно считают: если Катя работает без компьютера, а Маша с компьютером, то у Кати технический уровень низкий, а у Маши высокий. И далее: если у Коли «286» и DOS, а у Васи Пентиум-10 и Windows-3000, то у Коли технический уровень низкий, а у Васи высокий. Это поверхностный взгляд на вещи, от реальной техники далекий. Если первое из этих утверждений имеет какое-то право на существование, хотя и не безоговорочно, то второе сплошь и рядом противоречит истине.
Прошу меня правильно понять. Я не призываю всех пользоваться только 286-ми компьютерами. Я просто хочу развеять некоторые мифы, один из которых состоит в том, что покупка дорогого компьютера автоматически влечет за собой повышение эффективности работы фирмы.
Между тем вопрос не так сложен, и здесь даже не надо быть глубоким специалистом. Достаточно понять, что программа представляет собой техническое устройство и промышленное изделие, такое же, как, к примеру, самолет-истребитель или газовая плита на вашей кухне. Качество программы можно оценить так же, как и качество любого другого изделия – путем сопоставления его важнейших параметров с теми задачами, которые это изделие должно решать в процессе эксплуатации. Хороший истребитель – тот, который позволяет раз за разом побеждать противника в бою, а хорошая плита – та, которая хорошо варит. Однако «хорошо варит» - понятие субъективное, здесь возможен какой-то компромисс или «сепаратный сговор» между задачей и тем, кто ее решает. Вероятность победы в бою – вот это нам ближе, потому что вероятность - строгая математическая категория: она поддается точному научному анализу, а никакие субъективные оценки не являются решающими. Давайте просто понимать эти слова в более широком смысле – как успешное решение некоторой достаточно сложной задачи при условии невозможности компромисса. Теперь все встает на свои места: хороший компьютер – тот, который с наивысшей вероятностью решает сложные информационно-поисковые и расчетно-аналитические задачи, которые жизнь ставит перед его пользователем. Однако сам компьютер никаких задач не решает – нужна программа. Компьютерное «железо» влияет на вероятность решения задачи только в двух аспектах: оно должно удовлетворять требованиям данной программы, чтобы она просто могла на нем работать, и должно быть достаточно надежно. Таким образом, качество следует оценивать применительно не к самому компьютеру, а ко всей компьютерно-программной системе, и определяющим компонентом в этой системе является именно программа.
Качество проявляется в процессе эксплуатации изделия. Чтобы изготовить хорошее изделие, его создателю приходится решать множество проблем, в том числе таких, для которых не существует стандартного, освоенного промышленностью решения. Технический уровень изделия можно определить как суммарную тяжесть тех проблем, которые были успешно решены при его разработке. В отличие от качества, технический уровень проявляется уже на этапе разработки изделия. Однако и по окончании разработки, когда изделие уже выпускается серийно, технический уровень можно определить как обратную величину от количества специалистов, способных создать аналогичное изделие.
Эти рассуждения применимы к любой компьютерно-программной системе делового назначения (игры не в счет – там критерии совершенно особые). Однако мы сейчас обсуждаем тему более конкретную – управление производством. Здесь главный критерий истины – производительность труда. Большинство рассуждает следующим образом: если мы купим новый станок, который работает в 10 раз быстрее старого, то и производительность труда вырастет в 10 раз. А если купить новый компьютер, который работает в 100 раз быстрее старого? И вот здесь-то и совершают ошибку. Ни в 100, ни в 10, ни даже в полтора раза – даже и не мечтайте!
Представим, что вышеупомянутые Катя и Маша занимаются каждая на своей фирме одной и той же работой: рассчитывают потребность в материалах для изготовления заказанных изделий. При этом сам расчет, т. е. арифметические действия, занимает не так уж много времени – допустим, 1 час в течение рабочего дня. Остальные 7 часов уходят на подготовку и завершение работы. Нужно выяснить: в отделе сбыта – какие изделия и в каком количестве заказаны; в конструкторско-технологическом бюро – потребность в материалах на каждое изделие. После этого можно произвести собственно расчет, а затем нужно еще по результатам расчета оформить заявку в отдел снабжения. Допустим, теперь мы приобрели компьютер, оснащенный только стандартным ПО (Windows, Word, Excel). Теперь сам расчет занимает не час, а несколько секунд. Этими секундами пренебрегаем, и получаем выигрыш в производительности труда 1/8, т. е. 12.5%. Негусто, однако! Надо срочно покупать более мощный компьютер! Купили. И что же? Расчет занимает не несколько секунд, а 0.1 секунды, но обе эти величины пренебрежимо малы по сравнению с 7 часами рабочего времени, так что дополнительного выигрыша в производительности труда не получаем. На практике покупка нового компьютера зачастую не повышает, а снижает производительность труда. Ведь новый компьютер – новые «глюки». И новые игры. Потери рабочего времени из-за игр – тема для совершенно отдельного обсуждения. Вы, вероятно, не догадываетесь, что система Windows позволяет пользователю практически мгновенно переключаться с одной программы на другую. Когда шеф входит в комнату, где работают его подчиненные, он видит на экранах их компьютеров нечто похожее на работу, но он не видит, что у них в головах. А в головах у них пасьянс-преферанс, которым они занимались секунду назад.
Здесь описан механизм, с помощью которого компьютерно-программная мафия, соблазняя нас якобы богатыми возможностями новых компьютеров, выкачивает из нас доллар за долларом. Мы же зачастую ведем себя как наркоманы: однажды сев на иглу модернизации компьютеров, не можем с нее соскочить.
Итак, рост производительности труда в разы после покупки нового компьютера – надежда совершенно несбыточная. Сколько-нибудь существенный выигрыш можно получить, если покупать не новые компьютеры, а новые программы. При этом покупать надо такую программу, которая качественно превосходит старую. В рассмотренном выше примере можно попробовать не вводить все исходные данные каждый раз заново, а импортировать их с другого компьютера либо синтезировать на основе каких-то баз данных или результатов предыдущих расчетов. А уж автоматизировать разработку заявки на снабжение при наличии готовых цифр материалоемкости – это вообще святое дело. Для программиста это задача на уровне студенческого курсовика.
На самом деле не только 286-й компьютер, но даже «Микроша» начала 80-х годов ушедшего века решает информационно-поисковые и расчетные задачи в сотни и тысячи раз быстрее, чем это может сделать человек. Теоретически любой компьютер имеет достаточное быстродействие для того, чтобы за доли секунды ответить на любой вопрос пользователя. Причем нам не важно, какие именно доли – десятые или тысячные, нас устроят и 1 секунда, и даже 3 секунды. Практически это возможно, если для этого имеются все необходимые программы и данные. Если же чего-то не хватает, то требуется вмешательство пользователя, и тогда наши секунды неминуемо вырастают до размера часа. Этот час обходится предприятию в немалую копеечку, а сэкономить здесь можно только одним способом: составлять программу так, чтобы компьютер мог сам находить в своей памяти все нужные данные и процедуры для их обработки. Именно это и подразумевается под выражением «высокий интеллектуальный уровень программы». Программист, решивший пойти по такому пути, первые этапы преодолевает сравнительно легко, но и результаты получаются скромные. Каждый следующий шаг дается все большим трудом, зато и результаты будут более впечатляющие. В итоге же получится, что разработка сложного программного продукта лишь на 10% состоит из собственно программных работ, а остальные 90% трудоемкости приходятся на поиск и отбор таких программных решений, которые обеспечили бы будущему продукту промышленную применимость.
Рассмотрим теперь с этих позиций какую-нибудь широко распространенную программу, например Microsoft Excel. Меню этой программы весьма богато, и даже если исключить из него те операции, которые не относятся к интеллектуальным, то все равно мало никому не покажется: формулы, макросы, поиск, сортировка… Неудивительно, что Excel получил такую популярность у пользователей в самых разных отраслях науки, инженерной деятельности, экономики и т. п. Но если мы попробуем решить с его помощью какую-то конкретную, жизненную задачу, то окажется, что каждую формулу, каждый макрос ему нужно разжевать и в рот положить. Затраты умственной и нервной энергии будут огромны, а сроки решения таковы, что в цехе нас просто не дождутся. То есть задача либо совсем не будет решена, либо будет решена фонарно-потолочными методами, что ненамного лучше. Если речь идет о какой-то нестандартной задаче, то Excel вполне может рассматриваться как оптимальный инструмент решения. Но в области управления производством 90% объема работы приходится на несколько десятков типовых задач, для решения которых хотелось бы иметь какие-то специализированные средства.
Вернемся теперь к Коле и Васе. Пользователь Windows в своей работе может опираться только на встроенные интеллектуальные возможности этой системы и ее стандартных приложений (Word, Excel, Access…). Эти возможности, как мы теперь видим, весьма ограничены, но на другое рассчитывать чаще всего не приходится: разработка специализированных прикладных программ под Windows – дело крайне трудоемкое и дорогое. Пользователь DOS на встроенные интеллектуальные возможности своей системы рассчитывать не может – их просто нет. Волей-неволей ему приходится заниматься разработкой специализированных программ. Сделает ли он это сам или пригласит мастера – в любом случае у него есть все шансы при скромных затратах получить ПО с достаточно высоким интеллектуальным уровнем.

Кстати о мастерах. Когда мы нанимаем программиста для работы на производственную фирму, почти всегда говорим: «Нам нужны профессионалы». Однако сами мы, не будучи профессионалами в программировании, плохо представляем себе, что подразумеваем под этим словом. А если и представляем, то уж точно не можем уверенно распознать профессионала в человеке, которого первый раз видим. Мне лично в этом отношении несколько повезло: я учился в электротехническом институте, а на «железячное» производство постперестроечная судьба закинула меня в 1993 году уже зрелым специалистом. Те азы программирования, которые нам давали в институте, наполовину забылись, наполовину устарели. И все-таки я еще не утратил способности отличить макароны от лапши, когда мне пытаются вешать их на уши. Мой опыт общения с программистами говорит о том, что не существует единой шкалы оценки «профессионал – непрофессионал». Оценку следует вести по двум взаимно-перпендикулярным шкалам: по горизонтали – знания и умения, по вертикали – отношение к работе. Отсюда возникает не 2, а 4 класса работников:
* Добросовестный умелец – Мастер (по нормам русского литературного языка это слово пишется с большой буквы);
* Добросовестный неумелец – дилетант;
* Недобросовестный неумелец – ломастер;
* Недобросовестный умелец – как его назвать? Сами они обычно называют себя профессионалами – что ж, давайте и мы примем этот термин.
Если всех перечисленных субъектов посадить рядом и дать задание на разработку программы, то едва ли вы увидите какие-то существенные отличия в их работе (и уж точно не увидите, если вы сами не программист). На самом деле отличие между ними не в работе как таковой, а в их отношении к некоторым «тонкостям» и «частностям», которые до поры-до времени незаметны, но обязательно всплывут в процессе эксплуатации программы. Для Мастера эти «тонкости» и «частности» – привычный образ жизни. Приступая к работе, он сразу предвидит, как его программа впишется в структуру промышленного предприятия, и создает такой продукт, за который потом не пришлось бы краснеть. Он не стесняется задавать вопросы по техзаданию: умно поставленный вопрос – не признак незнания, а половина решения. Ломастер ничего об этих тонкостях не знает. Дилетант и хотел бы знать, да не всегда получается. А профессионал знает, но молчит. Он ведь работает на прибыль, а пунктуальное соблюдение всех тонкостей росту прибыли не способствует. Потом ему будет стыдно, но хорошая зарплата поможет ему свой стыд пережить, а зависимость пользователя от профессионалов гарантирует новые престижные заказы в будущем. Мы же говорили: «Нам нужны профессионалы» – хотели как лучше, а получилось как всегда. За что боролись, на то и напоролись – на кого теперь жаловаться?
Вот так мы и подошли к ответу на первый традиционный русский вопрос: кто виноват. Виноваты, оказывается, мы сами! Я имею в виду конечных пользователей – организаторов и руководителей производства (если, конечно, вы к таковым относитесь). Нам бы сейчас собраться и обсудить, какую программу мы хотим. Учесть лучшие достижения в мировом программировании, взять их с коэффициентом 2 – чтобы работать на опережение, а не плестись у кого-то в кильватере, и на их основе составить единое техзадание. И выставить это техзадание на открытый конкурс, чтобы любой дееспособный программист мог предложить свое решение. В чем проблема? А в том, что мы по жизни – каждый сам за себя. Мы не хотим быть лучше других, и наши хаты с краю, и разговор об активной жизненной позиции остался воспоминанием о комсомольской юности.

Я прекрасно отдаю себе отчет в том, что такой ответ никого не удовлетворит, но другого предложить не могу. На этом позвольте перейти к следующему вопросу: что делать?
Собственно, на этот вопрос мы уже знаем ответ: если у нас нет такой АСУ, какую мы хотим, ее нужно создать. Но какую АСУ мы хотим, мы по-прежнему не знаем.
Вы, вероятно, уже догадываетесь, что эта статья написана не на пустом месте. Однако сейчас давайте вообразим, что никакой реальной программы еще не существует, и мы собрались, чтобы обсудить то самое техзадание, о котором я уже говорил. Начнем с общесистемных требований.
Требование N1 – комплексность. Долой многочисленные разрозненные программы, обслуживающие отдельные рабочие места и неспособные наладить плодотворную совместную работу. Нужна именно система, охватывающая всю фирму. В идеале – с бухгалтерией и экономическим отделом. Однако, поскольку у работников этих подразделений планы другие, придется ограничиться такой системой, которая, по крайней мере, охватывала бы основное производство.
В представлении многих людей комплексность сводится к установке локальной сети. Однако сеть для компьютеров – то же, что телефон для людей. Самый хороший телефон не поможет двум абонентам, которые не могут найти общий язык или просто не имеют друг к другу вопросов, представляющих взаимный интерес. Точно так же и полный комплект программ Microsoft Office не может считаться комплексной системой. И даже просто пакетом или системой этот продукт можно назвать только с большой натяжкой. Все программы этого пакета вместе могли бы обеспечить неплохие информационные возможности, но как раз вместе-то и не получается. Каждая из этих программ работает со своими файлами и не может обмениваться информацией с другими программами, и это сводит к нулю перспективы промышленного применения этого продукта. Настоящая комплексная система отличается тем, что отдельные рабочие места (подсистемы) в ее составе целенаправленно снабжают друг друга всей информацией, необходимой для высокоэффективной работы пользователей. А по каким каналам эта информация передается – это уже вопрос второй очереди.
Требование N2 – стабильность работы. Термин «стабильность» здесь используется вместо более привычного для нас термина «надежность» по двум причинам. Во-первых, надежность – величина вероятностная. То есть, как бы мы ни боролись за отказоустойчивость системы, некоторая вероятность сбоя все равно имеется. Во-вторых, надежность имеет место, если условия эксплуатации соответствуют требованиям, установленным разработчиком системы. Если программисту дать волю устанавливать требования к условиям эксплуатации программы, он вам такого напишет! На реальном производственном предприятии эти требования почти никогда не выполняются. Значит, наша система должна обладать не только надежностью, но и живучестью, т. е. должна сохранять работоспособность (хотя бы частичную) даже при наличии каких-то противодействующих факторов.
Программисты нынешнего поколения, с институтской скамьи пришедшие сразу в частный бизнес и не нюхавшие военно-промышленного пороха, о живучести программ обычно просто не задумываются. А если и задумаются, то для ее обеспечения они все равно никакими инструментами не располагают. Съели вирусы какой-то файл? Баба с возу – кобыле легче. Выдаем на экран соответствующее сообщение – и чао, бамбино. А если в результате обанкротится целый завод? Да кого же волнует чужое горе! Теперь представим ситуацию покруче: вирус не просто что-то подпортил на вашем диске, а намертво заблокировал все ваши компьютеры. Такая ситуация кажется нам маловероятной, но, между прочим, ЦРУ вынашивает планы «вирусной войны». И не рассказывайте мне, что противником США в этой войне будут международные террористы во главе с Бен Ладеном. Так какие будут предложения? Мы, конечно, помним, что в хламовнике на первом этаже который год пылится не то «эйтишка», не то «четверка», и подключить ее не проблема. Работать на таком компьютере – мука, но все-таки лучше, чем совсем ничего. Ведь производство должно работать сегодня, сейчас. Значит, должна работать и АСУ. Любой ценой. Вот только будет ли наша АСУ работать в таких экстремальных условиях – на одном слабом компьютере, без сети, без мыша, без Windows? Совершенно очевидно, что положительный ответ на этот вопрос должен быть заложен уже на этапе постановки техзадания. И это важнее, чем возможность использовать различные шрифты в выходном документе.
Требование N3 – эргономика. Мы уже упоминали и укрощение строптивых, и гипотетический автомобиль с мышью вместо руля. Теперь кое-что конкретизируем.
* 3А – открытие документа. Практически во всех общедоступных прикладных программах и операционных системах документы хранятся в файлах и каталогах. В Windows каталог обозвали папкой, но суть от этого не меняется: чтобы открыть документ, надо знать, в каком файле он находится, в какой папке. Этот принцип происходит отнюдь не из DOS, а из Александрийской библиотеки древнеегипетского царя Птолемея. А вам когда-нибудь приходилось по срочному заданию начальника найти файл в компьютере вашего коллеги, который в этот момент находился в отпуске? Если файлов не очень много, то это не проблема. Проблема в том, что на современном промышленном предприятии файлов не бывает не очень много! Поэтому нам нужен поиск документа не по файлам и папкам, а по назначению и наименованию. В наше время уровень развития компьютерно-программной техники это позволяет.
* 3Б – печать. Вспомните, как производится печать документа в Windows: на экран выдается панель, на которой множество органов настройки. Где-нибудь ошибешься – и вместо документа получишь кучу испорченной бумаги. А ведь перед тем как печатать, нужно еще задать ширину полей в меню «Параметры страницы». Это еще ничего, если у вас только один принтер. Если же их два и вы активно пользуетесь обоими, то перед вызовом меню «Параметры страницы» надо еще вызвать меню «Печать» и выбрать принтер. И боже вас упаси нажать при этом «ОК»! В общем, порядка 20 действий мышью только для того, чтобы напечатать документ. Я готов поверить, что все эти тонкость действительно кому-то изредка бывают нужны. Кому-то и изредка, но не нам и не каждый день. А нам нужна одна кнопка «Печать», чтобы нажать ее и сразу получить распечатку со всеми нужными полями, рамками, колонтитулами и т. п., чтобы не было стыдно положить ее на стол генеральному директору фирмы.
* 3В – структура документа и его отображение на экране или распечатке. Деление экрана на 80 колонок и 25 строк, принятое в DOS, возникло не с бухты-барахты. И белые буквы на синем фоне, как в нортоновском редакторе, – находка если и случайная, то гениальная. Именно такие решения обеспечивают наиболее легкую читаемость информации на экране и наименьшее утомление глаз. В наше время программисты любят создавать документы очень большой ширины с множеством колонок, которые зачастую непонятно чем заполнять. В результате документ получается «размазанным» и трудным для чтения, а при его печати получается ничем не оправданный значительный перерасход бумаги.
Резюме. Нынешние программисты при создании чертежно-конструкторских, бухгалтерско-экономических и других специализированных прикладных программ обычно копируют решения, принятые в Word и Excel. А эти решения, в свою очередь, ведут родословную от старых, отживших свой век операционных систем. Даже не от DOS, а от CP/M, RSX-11 и т. п., поскольку DOS тоже система не оригинальная. Но Word и Excel – программы широкоуниверсальные. При их создании не была обозначена какая-либо конкретная область применения, а круг пользователей был слишком широким и не вполне определенным. В какой-то мере это оправдывает описанные здесь программистские решения. Нам же нужна программа не универсальная, а специализированная, и принципы ее построения должны быть иными. Я не хочу сказать, что эти принципы представляют собой что-то совершенно новое. Скорее наоборот: в свое время, в 1980-е и в начале 1990-х годов, они были хорошо известны и даже реализованы в некоторых прикладных программах. Однако позже эти принципы не вписались в новую политику мировых программных монополистов и не нашли реализации в новых системах программирования, в результате чего были заброшены и забыты. Теперь они востребованы вновь.
Требование N4 – поставка программы пользователю «под ключ». Типичная политика изготовителей ПО состоит в том, чтобы заложить в программу лишь некоторый базовый набор процедур, приспосабливаемый к конкретному предприятию путем всевозможных настроек, выполняемых пользователем. В магазине такая программа выглядит чертовски привлекательно. Однако то, что на прилавке магазина выглядит как соблазнительная возможность, при поступлении денег в кассу оборачивается хлопотной необходимостью. По сути дела, изготовитель ПО перекладывает на нас часть своей работы. Поскольку нужными для этой работы технологиями мы не располагаем, приходится затрачивать на это дело труда в несколько раз больше, чем если бы разработчик сразу сделал все необходимое. А продать продукты этого труда чаще всего не удается – по той же самой причине. И хорошо, если пользователь оказался вменяемым и хоть сколько-нибудь квалифицированным, чтобы сделал все как надо, а не как бог на душу положит. В результате 10%-ная недоделка разработчика ПО оборачивается для нас убытками, многократно превышающими магазинную цену программы. И еще один момент: при таком подходе одна и та же программа на разных рабочих местах работает по-разному, вплоть до полной неузнаваемости. При переходе работника на другое место, а равно и при смене работника на некотором рабочем месте, возникают нешуточные проблемы. В особо тяжелых случаях вся накопленная прежде информация отправляется в корзину, и работу приходится начинать с чистого листа. Какой же из этого вывод? Нам нужна такая программа, чтобы максимум технических требований пользователя был бы учтен еще на этапе ее разработки, чтобы купить такую программу и сразу начать ее эксплуатировать, не тратя времени и сил на настройку программы и обучение персонала.
Требование N5 – необременительность в эксплуатации. Попросту говоря, программа должна требовать от нас по минимуму, а отдавать по максимуму. Я бы даже сказал еще сильнее: требуем мы (пользователи), а программа наши требования выполняет, но не наоборот. И вот здесь возникает ситуация, абсолютно не входящая в рамки моего понимания. Когда солдат (или, допустим, боевик-террорист) собирается на войну и говорит: «Мне нужен бронежилет» – это же всеми воспринимается вполне нормально. Или когда музыкант собирается на конкурс исполнителей-виртуозов и говорит: «Мне нужна скрипка» – что вы ему ответите? Наверно, скажете: «Скрипки нет, вот тебе веник – играй на венике»? Но это будет уже не музыка, это будет несколько другой жанр, более близкий к цирковому искусству, так? То есть необходимость снабдить солдата бронежилетом, а музыканта скрипкой (но не наоборот) ни у кого сомнений не вызывает. Но если я скажу, что мне нужна программа, то кое-кто недоуменно спрашивает: «А что это у вас Романов выпендривается?». Ничего противозаконного я в своих требованиях не вижу, и технически они вполне реальны – так за чем дело встало? Просто мы привыкли к тому, что программа – это от Бога, она какая есть, такую мы и должны с благодарностью принимать. Если использовать только программы фирмы «Микрософт», то именно так всегда и будет: найти какой-то рычаг влияния на эту фирму нереально. Если же мы найдем в себе силы отказаться от некоторых привычных приемов работы, обусловленных применением Windows, то перед нами откроются новые возможности. Теперь мы сможем найти такого изготовителя ПО, который не будет навязывать нам свои представления о жизни, а сделает программу, удовлетворяющую нашим запросам.
Мы обсудили требования к системе в целом, теперь перейдем к структуре и конкретным функциям АСУ. Для этого необходимо представить себе структуру самого производственного предприятия. Сразу оговоримся, что предприятий очень много, и все они различны. Но, чтобы создать хорошую АСУ, нам следует ориентироваться на такой класс предприятий, на котором имеют место наиболее сложные алгоритмы управления. Рассмотрим предприятие с детально-сборочным характером производства, которое закупает у поставщиков материалы, изготавливает из них детали, а из деталей собирает изделия и отправляет их заказчику. Под это определение подпадает большинство фирм, выпускающих техническую продукцию. Технологическую цепочку на таком предприятии в общем виде можно представить так: отдел снабжения – склад материалов – механический цех – склад деталей-полуфабрикатов – малярный цех – склад готовых деталей – сборочный цех – склад готовой продукции – отдел сбыта. По этой цепочке проходят материалы в процессе их превращения в изделия. Задача каждого подразделения в этой цепочке – обеспечить ритмичную работу следующего звена цепочки. В идеале каждая деталь должна быть готова как раз в тот момент, когда она нужна на сборке. В реальности точное согласование поставщика с потребителем обычно недостижимо, поэтому приходится вводить в цепочку склады.
Управление производством может быть более или менее сложным в зависимости от того, как меняется количество изделий от месяца к месяцу. Доктора экономических наук и профессора в учебниках по управлению предприятиями приводят замысловатые формулы для расчета производственной программы фирмы на длительные периоды времени: год или квартал. Не знаю, пробовали ли они сами что-нибудь по своим формулам рассчитать, но что они никогда не работали менеджерами или начальниками цехов, – это совершенно ясно. Отсюда возникает выражение «реальное производство», которое я часто употребляю как антоним теоретическому производству, существующему только в книгах. Когда выпускник института приходит на такое предприятие, первое, что ему говорят: «Забудь все, чему тебя учили в институте – у нас здесь все по-другому». На реальном производстве изготавливать приходится не то, что запланировано, а то, что закажут. При этом заказы имеют свойство приходить в случайные моменты времени, и каждый заказчик, произведя предоплату, хочет получить свои изделия в срок, определяемый теоретической трудоемкостью их изготовления. Хорошо, если есть возможность не приступать к выполнению следующего заказа, не завершив предыдущий, а загрузка производственных мощностей не превышает 50%. Но мы же заинтересованы в наиболее полном использовании производственных мощностей! Вот тут-то и возникает противоречие: чем больше заказов, тем труднее обеспечить своевременную сдачу каждого из них. Поэтому с ростом загрузки производственных мощностей затраты на управление растут опережающими темпами. Между тем даже на фирме с общим штатом 100 человек обычно невозможно держать планово-управленческую службу в составе более чем одного менеджера, да и тот зачастую совмещает обязанности технолога или инженера по качеству.
В таких условиях составление производственной программы не то что на месяц или квартал, а даже на неделю – пустое дело. Сегодня вы составите великолепнейший план, а завтра придет новый заказ – и вам придется своими же руками не оставить от вашего плана камня на камне. Возможность выполнить заказ качественно и в срок определяется не технологическими возможностями фирмы, а четкостью работы и интеллектуальным уровнем ее системы управления. Таким образом, именно при позаказном планировании выпуска продукции имеют место наиболее сложные алгоритмы управления предприятием, а значит и потребность в АСУ особенно велика, и технические требования к ней наиболее жестки. Соответственно и разработка АСУ для таких предприятий представляет собой наиболее увлекательную и перспективную задачу.
Чтобы эффективно управлять такой фирмой, нужно, чтобы информация проходила в направлении, противоположном направлению движения материалов по технологической цепочке. На входе – данные о том, какие изделия и в каком количестве нам заказаны. Эти данные дает заказчик, который не знает состава изделий, да ему и не нужно его знать. Таким образом, исходный документ содержит по одной строке на каждое изделие. Первое, что нам необходимо сделать, – это детализировать эту информацию, т. е. разложить каждое изделие на составные части. Среди них могут быть детали, стандартные и не очень стандартные изделия, сборочные единицы. На этом этапе от общей информационной реки ответвляется один рукав: формируется документ для сборочных цехов с указаниями о том, что из чего надлежит собрать. Здесь не нужна подробная информация о материалах, из которых детали изготавливаются – достаточно намека. На следующем этапе расчетов общий документ с перечнем всех деталей – назовем его спецификацией заказа – делится на части соответственно механическим цехам, ответственным за изготовление деталей: формируется расцеховка деталей. Теперь каждый цех точно знает, что требуется изготовить. Однако пока что только сборочные цеха знают, что требуется для изготовления этих предметов, т. е. что нужно затребовать со склада. Такой же информацией следует снабдить и механические цеха. Отсюда вытекает третий этап расчетов – переход с уровня деталей на уровень материалов. На этом этапе информационный поток снова делится: одна часть отправляется в отдел снабжения как план закупки материалов, вторая распределяется по механическим цехам. Теперь каждое подразделение фирмы имеет информацию о том, что у него на входе и на выходе. Это позволяет снять с цехов мелочную опеку и контроль, предоставив им вести текущее планирование и контроль исполнения работ на внутрицеховом уровне. Работу планового бюро на этом можно считать исчерпанной.
На этом можно было бы считать исчерпанными технические требования к программному обеспечению планового бюро, но я все же хочу остановиться на одном пункте. Если изделие имеет многоуровневую сборку, т. е. содержит в своем составе сборочные единицы, то и спецификация заказа с таким изделием должна описывать его состав по всем уровням вложенности сборочных единиц. Программирование такой спецификации теоретически не представляет собой ничего сверхъестественного. Во всяком случае, в институтах этому учат. На практике профессионалы программного рынка от такой работы открещиваются. Само выражение «сборочная единица» действует на них, как полная луна на голодного волка. Аргумент же приводят примерно такой: зачем расписывать все сборочные единицы, когда можно просто сосчитать количество для каждой детали и указать это количество в спецификации? Такая аргументация свойственна бухгалтерам, а значит, и программистам, работающим в области бухгалтерских программ. Для работников этой отрасли стремление выписать все статьи затрат в столбик, чтобы потом просуммировать, совершенно естественно и не вызывает возражений. Но у нас здесь – ПРОИЗВОДСТВО! Для нас не так важно суммирование затрат (вот пусть бухгалтеры этим и занимаются!), для нас гораздо важнее знать, что нужно будет сделать сначала, что потом. И здесь многоуровневое описание состава изделия по сборочным единицам совершенно необходимо.
Теперь рассмотрим алгоритм работы начальника цеха. Исходной информацией служат спецификации заказов, поступающие из планового бюро. План работы цеха по каждому заказу может быть весьма обширным, но это не значит, что все нужно изготовить сегодня. Задача начальника цеха в том и состоит, чтобы составить план работы на текущий день. При этом следует учесть множество факторов, например: любая деталь или сборочная единица может входить во множество изделий, а сборочный цех обычно сегодня собирает одни изделия, а завтра другие. Среди заказов могут быть более срочные и менее срочные. Невозможно в программе сразу учесть все эти нюансы, хотя по мере накопления опыта степень автоматизации можно будет повышать. Однако есть по крайней мере одна «толстая тонкость», которая видна уже сейчас: план работы на текущий день должен быть увязан с имеющимися на складе запасами материалов. Таким образом, автоматизированное рабочее место (АРМ) начальника цеха должно иметь на входе два источника данных: помимо спецификаций заказов, нужна еще складская информация. На выходе также образуется два потока взаимно-согласованных данных: на склад – требование на материалы, а для собственных рабочих – наряды на изготовление деталей или сборочных единиц.
Мы затронули тему склада – значит, никуда не деться от того, чтобы и здесь ясно сформулировать кое-какие требования. На рынке ПО имеется великое множество складских программ, а еще больше таких, которые создаются и используются на своих предприятиях и не выставляются на рынок. Многие из этих программ весьма замысловаты, но в основном в сфере формирования отчетных документов. Информационно-поисковые и аналитические возможности обычно сводятся к расчету остатков на складе по простейшей формуле для первоклассников: было – приняли – выдали – осталось. Бухгалтера и экономисты (ради которых, собственно, и составляются эти программы) утверждают, что их такая информация устраивает. Охотно верю…
Но у нас здесь, повторяю, – ПРОИЗВОДСТВО! Здесь постоянно и очень сильно ощущается давление времени. В сущности, вся моя работа на протяжении последних 10 лет – это прямо-таки автогонки формулы 1, это постоянная борьба за скорость. Только в этих гонках я чувствую себя не пилотом, а скорее тем незаметным специалистом, который день за днем рисует канавки на шинах с одной единственной целью: выиграть мгновение.
У экономистов ведь как? Копейка рубль бережет. Что и понятно: рубль всегда равен 100 копейкам. У нас все наоборот: день экономит секунды. Бывают дни затишья, которые не жалко потратить на какие-то перспективные дела, и бывают секунды, цена которых – почти как жизнь. Точнее, выживание фирмы на рынке. Поэтому наши требования к информации не просто иные, чем у бухгалтера или экономиста – наши требования значительно жестче. Продолжая высказанную выше мысль о том, что информацию едят, скажу так: в приличном ресторане не подают быка, а подают бифштекс. Наша информация должна быть легкоусвояемой. Она должна быстро приходить и так же быстро уходить. Бухгалтер может себе позволить провести целый день над одним каким-то документом, а мы – нет. Поэтому, когда мне говорят: «вот тебе ведомость остатков материалов на складе, вот ведомости материалов на очередные заказы, сопоставь их и выпиши, что надо закупать», – такой подход меня не устраивает. Руководителю и организатору производства нужна такая складская программа, которая бы владела информацией как об остатках на складе, так и о потребностях производства по всем имеющимся заказам, и выдавала бы эту информацию в сопоставлении: слева – потребность, справа – ресурсы для ее удовлетворения. Такая программа, в сущности, – уже почти готовая АСУ. Чтобы из «почти» сделать «совсем», надо лишь дополнить ее процедурами по выработке решения.
Если теперь сопоставить сказанное здесь с тем, что было сказано в предыдущих абзацах про рабочие места плановика и начальника цеха, то увидим наиболее общую схему любой программы, претендующей на название АСУ. Такая программа должна иметь на входе как минимум 2 источника информации. Каждый источник описывает одни и те же объекты, но с разных сторон. АСУ должна сопоставить эти данные и сформировать «композиционный» документ. Этот документ теоретически может служить основой для решения пользователем своей задачи. Практически такой документ не удовлетворяет требованию легкоусвояемости, поэтому он не должен рассматриваться как окончательный. На следующем этапе наша программа должна на основе этого композиционного документа выработать рекомендации для пользователя по принятию управленческого решения.
Именно процедура выработки рекомендаций для принятия решения и является характерной чертой, отличающей АСУ от бухгалтерских, экономических и складских программ. Бухгалтер и кладовщик работают «постфактум»: в своих документах они отражают уже свершившиеся события хозяйственной жизни предприятия. Но чтобы эти события произошли, кто-то должен принимать управленческие решения, а для этого нужна информация. Чем эта информация полнее и точнее, чем раньше она появится, чем легче пользователю ее получить, тем эффективнее будет управление. Отсюда три важных вывода. Первый: «чистый программист», не знающий реального производства, не сможет создать хорошую систему – эта задача может быть решена только при совместной работе программистов (причем достаточно серьезных) с руководителями производства. Второй: программисту, ранее работавшему в бухгалтерско-складской сфере и приступающему к созданию АСУ, многое придется пересмотреть в своих прежних взглядах, в противном случае в сферу АСУ лучше совсем не лезть. И третий: АСУ не следует рассматривать как конкурентный продукт по отношению к упомянутым программам – каждая из этих программ имеет свою область влияния и ответственности. По этой же самой причине не следует искать в АСУ процедуры для составления всевозможных отчетов и выражать недовольство по поводу их отсутствия.
Что касается взаимодействия АСУ с бухгалтерско-складскими программами при их совместной работе на одной фирме, то этот вопрос в обозримом будущем останется без ответа. Во-первых, эти программы создавались без какой-либо стандартизации, так что проблему их стыковки с АСУ придется решать для каждой такой программы индивидуально. Во что это выльется по времени и по деньгам, даже не возьмусь считать. Во-вторых, качество наших бухгалтерских и складских программ обычно таково, что не легче ли их заменить чем-то другим?
Используя описанную выше общую схему, нетрудно сформулировать техзадание на разработку ПО различных рабочих мест: начальников отделов снабжения, сбыта и т. д. Теперь, когда техзадание в общем виде сформулировано, можно составить подробные требования к каждому документу, к каждой процедуре. Но в настоящее время, поскольку программа уже существует, не вижу смысла на этом останавливаться. Давайте перейдем сразу к следующему вопросу: что может дать внедрение АСУ фирме?

Обычно считается, что автоматизация позволяет повысить производительность труда работников, занятых планово-управленческой подготовкой производства, и повысить эффективность их работы за счет минимизации вероятности ошибок. Применительно к нашей АСУ такой экономический эффект, безусловно, имеет место, но он не единственный и не главный. Гораздо важнее другое: ускорение производственного цикла и сокращение запасов незавершенного производства. Любой хороший экономист озабочен минимизацией сверхнормативных запасов, а любой хороший начальник цеха чувствует себя спокойнее, если может взять материал со склада, не дожидаясь, когда его привезут снабженцы. Так какой запас считать нормативным, а какой сверхнормативным? На этот вопрос при традиционном (неавтоматизированном) подходе к управлению предприятием точного ответа дать нельзя. В некоторых умных книгах по планированию производства можно найти формулы для вычисления нормативных запасов. Однако, во-первых, эти книги мало кто читает. Во-вторых, расчеты по этим формулам весьма трудоемки, и руки до них просто не доходят. В-третьих, как я уже неоднократно говорил, реальное производство далеко не всегда укладывается в рамки математических формул. В результате – типичная для многих заводов картина: заказов мало, работа в цехах то ли идет, то ли не идет, а на складах ржавеет металл, закупленный еще при советской власти (хорошо если не при царе). Эти запасы – мертвый капитал, на месяцы или годы выведенный из оборота фирмы. Кроме того, их еще надо где-то хранить, а это уже прямые расходы: отопление, охрана, земельная аренда складских площадей… Использование АСУ позволяет решить проблему радикально: работать «с колес» и вообще отказаться от запасов. Из экономики известно, что простое повышение оборачиваемости капитала (даже без увеличения его абсолютной величины) позволяет убыточное предприятие сделать прибыльным. Именно ускорение оборота капитала и даст основной экономический эффект, во много раз превышающий выгоду за счет роста производительности труда. Как показывает практика, решение этой задачи невозможно в рамках одной отдельно взятой программы типа АРМ начальника склада. Нужна именно комплексная АСУ, в которой каждое рабочее место снабжается всей необходимой информацией из всех необходимых источников.
Чего следует ожидать от АСУ рядовым работникам?
Первое – повышение порядка, дисциплины, ответственности. Если раньше любой работник мог оправдать практически любые свои ошибки, а стихийная компьютеризация ничего в этом смысле не изменила, то теперь от работников потребуется совершенно иное отношение к работе. Причем АСУ не столько предъявляет повышенные требования, сколько создает условия для их выполнения.
Второе – прозрачность. Раньше директор фирмы, желая оценить готовность продукции по срочному заказу, вынужден был обращаться к начальнику соответствующего цеха, который один владел исчерпывающей информацией и поэтому считал себя незаменимым. Теперь директор может получить всю информацию прямо на экране своего компьютера.
Третье – необходимость что-то качественно менять в своей работе, повышать свой технический уровень. На реальном производстве «новаторов» немного, а «консерваторов» больше, чем обычно считается. Иной работник считает существенной частью своей работы какие-то рутинные операции типа ввода в компьютер данных с распечатки, полученной на другом компьютере (хорошо если не на этом же самом, а ведь бывает и такое!). Предложи такому человеку автоматизироваться – и он будет озадачен: а чем же теперь заниматься весь день? По идее, высвободившееся время следует использовать для какой-то более квалифицированной работы. Но в том-то и дело, что вести квалифицированную работу не каждый сможет, да и не каждый захочет! В нынешней России к этому можно добавить еще аргумент типа «Мне зарплата не позволяет заниматься квалифицированной работой».
В свете сказанного очевидно, что комплексная АСУ не будет востребована работниками низового звена. Инициатива ее внедрения должна исходить от высшего руководства фирмы. Мне приходилось встречаться с руководителями фирм, которые вроде бы и готовы такую инициативу проявить, но что-то их удерживает. Что именно? С одной стороны, превратное понимание возможностей, которые открываются при использовании компьютеров, а с другой стороны - преувеличенное представление о тех сложностях, которые якобы ожидают человека, решившегося на такой шаг. Очень интересно, что те же самые люди действуют в иных ситуациях вполне рационально и даже прагматично, но совершенно теряют голову, как только речь заходит о компьютерах и программах. В чем причины? Причин я усматриваю четыре.
1) Реклама. Это она всегда ориентирует людей на ожидание чуда. Не берусь судить, бывают ли чудеса вообще, но что я знаю точно, – что в технике чудеса крайне редки. Если вы, увидев рекламу какого-то суперсовременного компьютера, сразу поспешите в магазин, то потом, когда этот компьютер окажется на вашем столе, окажется, что все его замечательные свойства были и у вашего старого компьютера. Просто вы о них не догадывались, пока не прочитали рекламу. Почти каждый, кто в наше время покупает компьютеры, уже 2-3 раза в своей жизни испытывал подобные разочарования. Что еще нужно для формирования стойкого предубеждения?
2) Игры. Взрослые дяди и тети, не наигравшиеся в детстве в «Дум» и «Квейк», рассматривают любую компьютерно-программную систему прежде всего как игрушку. И это, в общем-то, понятно: у тех компьютеров, которые сейчас везде продаются, на мо… пардон, на лицевой панели написано, что это игрушки. И комплектация-конфигурация, которая у них внутри, этому имиджу полностью соответствует. А настоящий заводской компьютер с настоящим ПО в нашей стране большая редкость, и можно по пальцам пересчитать людей, которые хотя бы раз в жизни что-то подобное видели. А в игрушечной отрасли критерии оценки совершенно иные, чем в промышленной. Попробуйте втолковать такому дяде, что АСУ – это совершенно не клево и не модно, что это вообще программа для работы, а не для развлечения, и это оправдывает ее серую внешность и занудные манеры, – и реакция будет примерно такая: «А пусть работает Володька-командир, ведь он у нас такой сознательный один».
3) Непрофессионализм. Иной директор фирмы чуть ли не гордится тем, что ничего в этих компьютерах не понимает. А продавцы в компьютерных и программных магазинах охотно этим пользуются. В своих интересах. Отсюда новые разочарования… Круг замкнулся. 4) Косность. Просьба не путать с консерватизмом. Здоровый консерватизм на промышленном предприятии совершенно необходим – он обеспечивает устойчивость, страхует нас от необдуманных решений. Он как балласт на корабле: с ним тяжело, но без него – гибель. Косность – это консерватизм, перешедший грань здорового, доведенный до абсурда. В особо тяжелых случаях эта болезнь приводит к полной утрате способности принимать решения.
Здесь я дал обобщенный, не лишенный некоторого преувеличения портрет руководителя производственной фирмы, мечтающего о крутой компьютеризации. Когда такой человек впервые видит АСУ, его реакция часто похожа на шок: настолько этот программный продукт контрастирует со всем тем, что нам знакомо. «Фу, какое старье» - обычно первое, что они говорят. Но это выражение не из нашего лексикона. Давайте отбросим беспочвенные эмоции.
Что касается внешнего вида, то во внешнем виде программ АСУ можно найти некий своеобразный ретро-шарм. У кого-то он может вызвать ассоциации с нортоновскими утилитами версии 4.5, лично у меня – со встраиваемыми микропроцессорными системами промышленного назначения. От таких систем обычно ждут простого управления и быстрых, четких, «со знанием дела» реакций на каждое управляющее воздействие. Эти ожидания АСУ полностью оправдывает. В остальном система достаточно аскетична. Такие прелести современной компьютерной жизни, как изменение цвета, размера и формы шрифта, при программировании АСУ были сочтены неактуальными. Все усилия разработчика были сосредоточены на проработке основных алгоритмов преобразования данных. Что касается шрифтов, то для установки нужного шрифта можно использовать штатную функцию Windows. Эта функция действует на все изображение и неприменима к отдельным частям документа. Интересный момент: эта функция применима для программ, написанных для DOS, и недоступна для программ, изначально рассчитанных на эксплуатацию в среде Windows. Разработчику специализированных прикладных программ под Windows следует использовать системную процедуру, аналогичную той, которая имеется в Word и Excel. Однако эта процедура существует чисто формально: ее реализация, по-видимому, достаточно хлопотна, и программисты ее просто игнорируют. В результате пользователь таких программ зачастую лишен даже таких маленьких радостей, которые доступны пользователю DOS’овских программ.
Что же касается внутреннего устройства, то я и сам готов признать, что многие технические решения, лежащие в основе АСУ, небесспорны. Также небесспорны и некоторые суждения, изложенные выше. Впрочем, говоря слово «небесспорно», я говорю только это слово и ничего более. Вот чего мне по жизни не хватало – это пытаться соперничать с авторами Библии и Корана! Задача любой технической книги в том, чтобы довести до читателя авторскую точку зрения и тем самым подтолкнуть читателя к поиску своей собственной точки зрения на рассматриваемые проблемы. А если у читателя возникнут возражения, то ничего плохого я в этом не вижу.
На этом тон моего повествования следовало бы изменить: посидели, поболтали, пофилософствовали – пора и честь знать, теперь ближе к делу. И все же несколько слов об истине вообще. Кое-кто из тех, с кем я обсуждал перспективы АСУ, склонны подходить к делу с позиций фундаментальной науки: выявить истину путем сложных расчетов, логических доказательств… Но у нас здесь не фундаментальная наука, и критерии истины здесь несколько другие. В технике истинно не то, что теоретически правильно, а то, что сегодня реально достижимо. Техника, подобно политике, – это искусство возможного. А в экономике истинно все, что прибыльно (и опять-таки прибыльно должно быть здесь и сейчас, а не в каком-то неопределенном будущем и не в Соединенных Штатах, где вообще вся экономика по-другому устроена). Здесь и сейчас – вот слова, которые могли бы стать девизом разработчика АСУ, да и нашим с вами тоже.
———————
Игорь Романов