Samara Portal Technology, Computers

Самарский портал "Технологии, компьютеры"

После длительного перерыва, вызванного крайне напряжённым графиком, возвращаюсь к (как это называл «душелюб и людовед» Евгений Сазонов) «мемуаразмам».

Третью серию своих ИТ-воспоминаний я закончил тем, что администрация предприятия, на котором я работал, приказала передать все наши разработки «профессионалам» и вернуться исключительно к конструкторской работе.

Здесь важно напомнить, а может, и удивить: в СССР с интеллектуальной собственностью дело обстояло совсем не так, как в остальном мире. Точнее, собственность в СССР вообще пребывала в непонятном состоянии. Например, только в СССР (и ещё в Монголии) выдавались авторские свидетельства на открытия. Разумеется, такой документ не давал никаких прав, потому что его владелец, даже если он открыл закон всемирного тяготения, не мог контролировать использование его всеми остальными людьми или запретить им пользоваться. С изобретением было несколько иначе: всеми правами владело государство, и автор получал столько, сколько владелец ему назначал. Эта сумма, как правило, была равна 25 рублям, джинсы по госцене (кто не знает, что это такое, спросите у старших) стоили 100 рублей (на «барахолке» в несколько раз больше), итого, перефразируя Маркса, четыре изобретения стоили одних джинсов.

Как обстояло дело с интеллектуальной собственностью, выраженной в музыкальных произведениях, книгах, и прочем искусстве, я написал в материале под названием «Туча над рынком». А вот права на программный продукт не оформлялись вообще никак. Поэтому, с одной стороны, мы могли забрать свои наработки и продолжать их в другом месте, а с другой – их могли использовать все, кто хотел и мог. Я считаю понимание этих вещей очень важным: в советское время, когда компьютеры эксплуатировались исключительно на предприятиях, а предприятия были исключительно государственными, установленное на них ПО не было ворованным или пиратским, поскольку никаких прав собственности на софт официально не признавалось. Обратите, как описывается операционка для СМ-ок в Википедии:

ОСРВ СМ ЭВМ — операционная система разделения времени или реального времени для СМ ЭВМ. Являлась переведённой ОС RSX-11 для PDP-11.

И это была обычная практика: перевести, а заодно и переименовать, если оригинальное имя показалось неблагозвучным. И вот на персоналках появляется текстовый редактор Фотон, СУБД Карат и прочие продукты такого же статуса, как и ОСРВ.

Моя заводская история закончилась тем, что меня пригласили в институт заведовать лабораторией, и вся команда ушла вместе со мной. В скором времени выяснилась ужасная вещь: прежний руководитель лаборатории умудрился выбрать все деньги с договоров, ничего при этом не сделав. Но нет худа без добра: привлечь меня к ответственности всё равно бы не получилось, руководству института (которое, разумеется, подписывало все акты выполненных работ) скандал был тоже ни к чему, и мы получили карт-бланш. Смысл заключался в том, что нам не дают утонуть, а мы ударными темпами доводим свою идею и макет до товарного состояния и сдаём заказчику вместо того, что было ранее записано в ТЗ. Тем более что планировалось внедрить автоматизированное проектирование комплексных технологий – некий аналог упоминавшихся в позапрошлом материале комплексных чертежей. То есть программист даёт технологу этакий альбом «слепышей» на типичные детали-представители, в котором инженер должен найти «свою» технологию – а это нереально.

Мы же предлагали на первое время оставить полуручное проектирование технологии с выбором из справочников режимов резания, оборудования, оснастки и других компонентов. Работа на технологическом фронте послужила стимулом «привинтить» формирование технологии к конструкторскому скелету изделия: от каждой детали протянулись веточки операций, переходов, оборудования, оснастки и инструмента, нормирования труда, норм расхода материалов и прочих производственных вещей. Приделав над структурами изделий ещё один уровень – план выпуска (структурно – та же спецификация), мы получили потребности в номенклатуре компонентов (узлов) на плановый период, а указав времена производственного цикла для каждого компонента – дату запуска в производство каждого из них (точнее, запуск деталей самого нижнего уровня). То есть, по сути – сетевой график планирования производства, по которому потом можно было проводить диспетчирезацию и контролировать выполнение заданий.

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

Такую же картину впоследствии наблюдалась и на КАМАЗе, где мы тоже начинали внедрять систему. Пример с КАМАЗом более наглядный – потому что трёхосный грузовик все видели и представляют. Так вот, у этого автомобиля имеется тележка с задней и средней осью, которая в собранном виде поступает на главный конвейер. И эта тележка не получила своего конструкторского обозначения по весьма уважительной причине: не хватило уровня. Чтобы не гонять читателей к прошлому материалу, напомню, что конструкторское обозначение имеет вид ФИРМА. АВТОМОБИЛЬ. 000. 000. 000 (ВАЗ. 21093. 000. 000. 000), количество уровней определяется ещё до начала этапа рабочего проекта и остаётся неизменным. Как они промахнулись – не знаю, но уже много лет эта безымянная тележка гуляет по заводу, благополучно добираясь до главного конвейера. В общем виде задача выглядит так: не должно быть отдельно конструкторской и технологической структуры изделия. А поскольку подстраиваться надо под производство, то это означает переработку имеющейся конструкторской документации, а при новом проектировании согласование с технологами не только по критерию возможности изготовления, но ещё и соответствия порядку изготовления (сборки).

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

После нескольких успешных внедрений я осмелел настолько, что не постеснялся прийти в Alma Mater на кафедру «Детали машин», где продемонстрировал продукт, рассказал об идеях, заложенных в него, и предложил бесплатно использовать его в учебном процессе. Да, я читал о проекте Apple «Дети не могут ждать», и мне захотелось сделать что-то подобное. К сожалению, из этой затеи ничего не вышло. Что было тому виной, сейчас сказать трудно: скорее всего, компьютеризация ВУЗа и ИТ-шные навыки преподавателей были на таком уровне (то есть отсутствовало и то, и другое), что наша инициатива попросту оказалась преждевременной.

В это время ведущий программист нашей лаборатории сотворил чудо: он написал язык формирования учётных систем. Честно говоря, я тоже приложил руку к написанию языка, жёстко стандартизовав все компоненты: меню, таблицы (без возможности редактирования данных непосредственно в них – можно было только удалять записи), формы для редактирования и ввода, отчёты. Описал все атрибуты этих объектов. С появлением языка не поленился переписать на нём все приложения. К сожалению, все наши достижения имели смысл только при функционирующей промышленности, а как раз в середине 90-х годов отечественное машиностроение стало угасать. Старая командная система уже не работала, а начать взаимодействовать между собой на рыночных принципах у крупных предприятий никак не получалось. Сказывалось также отсутствие практики взаимодействия предприятий напрямую с зарубежными партнёрами – и как только бывшие республики СССР стали «заграницей», рухнули почти все экономические (я бы даже сказал – технологические) связи. На тот момент компьютеризация на предприятиях рассматривалась как перспективная, но очень дорогая игрушка, поэтому под сокращение попадали в первую очередь ИТ-бюджеты. В этой сложной ситуации ясно проявились человеческие качества наших партнёров. Как в песне:

Если друг оказался вдруг
И не друг, и не враг, а – так,
Если сразу не разберёшь,
Плох он или хорош, –
Парня в горы тяни – рискни!
Не бросай одного его,
Пусть он в связке в одной с тобой –
Там поймёшь, кто такой.

Руководство Саранского экскаваторного завода просто отказался оплачивать уже подписанные акты, на голубом глазу заявив нам, что если теперь им вся эта компьютеризация уже без надобности, а на дворе капитализм, то зачем они, капиталисты, в этом мире чистогана должны терпеть убытки. С Курганским автобусным заводом всё было с точностью до наоборот: начальник АСУПа Игорь Седов (дай бог ему здоровья) не только рассчитался до копейки, но ещё и провёл меня по всем машиностроительным предприятиям своего города. Только всё в ту пору было безуспешно. Запомнилась беседа со специалистами Курганмашзавода, как видно из нарочито нейтрального названия, выпускающего что-то военное. Они по старой традиции догоняли и перегоняли Америку, пытаясь создать собственный AutoCAD. Всё, чего мы достигли – это поставили им демонстрационную версию продукта для ознакомления. В общем, мы оказались на мели.

Вот тут нам и помог универсальный макроязык описания учётных систем. За короткий срок была написана бухгалтерия со складским учётом и зарплатой, использующая единую базу (до чего 1С добралась только в 8-й версии), строительная система с разработкой смет, графиков и контролем выполнения работ. Самой объёмной была работа по созданию интегрированной системы Самарского протезно-ортопедического предприятия. Начиналась она с регистратуры, где происходила первичная запись инвалида. Затем диспетчеризация врачебного приёма, постановка диагноза, назначение протезирования. Здесь уже можно было вести медицинскую статистику, тем более что мы не поленились и набили классификатор Всемирной организации здравоохранения. Изготовление протезов, примерки, обучение в стационаре (существуют курсы для пользователей протезов), выдача. Диспансеризация, замена протеза после планового срока эксплуатации. Здесь мы уже могли прогнозировать, планировать производственные мощности и заказ материалов. Разумеется, бухгалтерия в полном объёме. Связь бухгалтерии с ядром системы давала возможность отнесения затрат на конкретного инвалида, становилось понятно, кто сколько стоил для государства.

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

Таким образом, к нулевым мы пришли скорее закалёнными, чем потрёпанными. И по-прежнему полными надежд: мы были уверены, что обладаем лучшим продуктом, и это не даст нам пропасть на рынке.

Oracle: против течения

Oracle: против течения. Статья Владислава Боярова.

Самарское сообщество «ИТ для инноваций»: IT в воркинге

Самарское сообщество «ИТ для инноваций»: IT в воркинге. Статья Владислава Боярова.

Автоматизация и бардак

Автоматизация и бардак. Статья Владислава Боярова.