Как ускорить разработку в машиностроении в 4 раза. Ключевые моменты для успеха в машиностроении и не только
Мы живем в сильно ускоренном периоде грандиозных изменений — во время рождения, успехов и падений разных компаний, появления и исчезновения целых отраслей. По воле случая я оказался причастным к разработке сложных транспортных изделий и управлению ИТ системами на разных предприятиях в отрасли машиностроения и не только. Поэтому я хорошо знаю как устроен бизнес, в основе которого лежит разработка и конструирование, знаю типичные ошибки, а также ключевые факторы для достижения успеха в разработке и производстве новых сложных изделий, а также достижения конкурентных преимуществ в таком серьезном бизнесе как машиностроение.
В далеком 2006 году почти случайно я устроился на работу сисадмином в НТЦ на одном крупном предприятии почти в самый первоначальный момент создания нового направления по производству автобусов и троллейбусов, я наблюдал все первоначальные грабли и был причастен к определенным успехам этого направления. Подробнее и кому интересно — под катом.
Прием на работу был довольно необычным — НТЦ был в одном городе, а завод в другом. Первое собеседование с директором НТЦ прошел успешно — наверное чисто визуально и по адекватному общению, потому как технические вопросы были в стиле «знаешь?» с ответом «знаю». Второе было уже чисто по реальным знаниям сетей и прочего с главным ит специалистом корпорации, третье с начальником АСУП. Четвертое и самое трудное было с СБ — где был прям перекрестный допрос, целью которого было понять — «а не солью ли я информацию про разработки и прочее?» Вообще там ну очень с ИБ заморачивались и это сыграло положительную роль для предприятия. В итоге меня приняли на работу, но оформили не напрямую в НТЦ, а на главном предприятии, потому как я должен был контролировать ИБ и директора НТЦ в том числе.
На работе. Офис был идеальным — целый этаж в новом бизнес-центре, остекление на все внешние стены — все тогда было нереально круто по сравнению с типичными компаниями.
Директор — для меня это был разрыв шаблонов. Со старта кучу задач, термин — до конца дня! Ни тебе осмотреться и освоится, а сразу с места в карьер. Я сам не верил, но всё выполнил, как ни странно.
Коллектив уже был сложившийся — фактически все перешли из профильного института и перед этим уже принимали участие в разработке малых автобусов в составе КБ института. И состоял из отделов — кузова, шасси, электрики и дизайна. Возглавлял коллектив главный конструктор.
Самое важное и правильное решение при формировании такого НТЦ было оформить его как отдельное дочернее предприятие и назначить своего директора. Причем личность директора явно не вписывалась в конструкторский коллектив: в бывшем успешный владелец небольшого бизнеса и никаких познаний в автобусах не имел и даже не сталкивался! Для меня это было странно — потому как почти сразу увидел напряженность между коллективом и директором. По функционалу: директор — бизнес-функции и планирование, финансы, зарплата и администрирование (принятие на работу, увольнение и контроль дисциплины) и прочее.
Главный конструктор (ГК) и начальники отделов — вся техническая часть, директор не вмешивается. Отдельно нанят специалист по безопасности — подполковник полиции в отставке — из функции относящихся к НТЦ обеспечение инфо безопасности (со мной в паре), и просто чтобы люди боялись и даже не думали слить куда нибудь инфу по разработкам. По ИТ и ИБ главный я, поэтому отключены все usb, логи всех действий работников НТЦ и даже их распечаток — все записывалось и регулярно пересылалось на главное предприятие. У всех работников зарплаты выше среднего по рынку, зарплата начислялась 50% оклад и такая же по размеру премия, так что рычаги для финансового воздействия у директора были.
Начало первого проекта. Когда я пришел то ПК, сервер, сеть и прочее уже были куплены и настроены. В качестве основного софта было куплено PTC Pro/Engineer также оплачено обучение и поддержка. Софт, как ни странно, выбрал директор — руководствуясь:
- Западная система проектирование со сформированной методологией.
- Отличная локализация и поддержка ескд.
Итак, всё есть и после обучения первый проект — малый автобус на основе шасси небольшого грузовичка. При проектирование почти сразу проявилась инертность коллектива и вместо использования Pro/Engineer и проектирования в 3D, а потом создание чертежей с 3D модели в том же Pro/Engineer, конструктора массово начали делать работу в программе компас 2d. И как директор ни стимулировал работать в закупленной программе все попытки были тщетны, ведь авторитетный ГК был против чтобы конструкторам указывали в чем им работать, потому как «конструктор — человек творческий». И все работали по накатанной ранее схеме. В результате создание первого автобуса длилось 1,5 года, на производстве технологи и рабочие были в шоке от халтурной документации — много несостыковок — кузов несколько раз разрезали и делали по новой из-за нестыковок и постоянных изменений КД. Когда автобус поехал, то в загруженном состоянии на него было страшно смотреть — крен был покруче Пизанской башни, а дизайн автобуса настолько убогий, что я никому из знакомых не говорил, что был причастен к созданию такого шедевра. Остро встал вопрос о разгоне НТЦ, но ГК обладал определенной харизмой, да и просто был в дружеских отношения с руководством завода и уболтал продолжить работать — и вот мы получили новый проект на средний автобус.
Далее определяющую роль в НТЦ будет играть личность директора и моё скромное участие, поэтому отвлеченно опишу характерную историю по установке системы входа по карточкам в офис. Директор дает мне задание найти и установить такую систему, фирма предлагает контролер, замок и опционально — с установкой или без, с софтом учета времени или без.
Директор оплачивает только железо — «установим сами». Купили, установил, подключил к компу прописал карточки и думал, что всё — работа сделана. Директор: «напиши программу учета рабочего времени». — Вот, блин — засада! И не откажешь — скажет, что некомпетентен. Ладно на входе с контролера *.csv, на выходе агрегированный отчет на бумаге — ms Access идеальный инструмент для этого. Пару недель кодинга в SQL, макросах и прочем вот и несколько видов отчетов в любом виде за 2 минуты по первому требованию! Блин, сам не верил, но сделал. Директор нацелен на результат — не вникает в технические детали, интересует только выхлоп, категоричен в управлении, ощущается жесткий бизнес-подход к делу — это проявляется во всем, нужно уволить — уволит без раздумий. В то же время стимулирует дополнительно материально — всё справедливо.
Итак, мы работаем над новым проектом, дополнительно наняли двух спецов по средним автобусам и четырех по троллейбусам, так как на базе автобуса будет троллейбус.
В самом начале проекта проявляется консервативность и тщеславность ГК, который проигнорировал предложение от нанятых специалистов создать стандартный низкопольный автобус и продавил своим авторитетом создание трехуровневого!(пару лестничек внутри) автобуса с нестандартной шириной и 4 одностворчатыми! дверями! — ведь надо что-то сделать, блин, новое! Наверху одобрили (харизма и прочее) и понеслась работа.
В это время на одном специализированном форуме выложили PDM систему для тестов. PDM это система управления данными об изделии, которая позволяет проводит совместную разработку и которая обеспечивает актуальность структурированных данных в едином архиве, также поддерживает версионность, согласование КД, управление проектами и прочие плюшки — это как бы Git, но для конструкторов и с дополнительными опциями для КБ. Для нас внедрение PDM означало бы переход на новый качественный уровень разработки, где все изделие представляет полную и состыкованную и главное актуальную (с последними изменениями) 3D модель. А 2D чертежи вторичны и напрямую связаны с 3D моделью.
Моё руководство по ИТ на заводе сказали, чтобы не парился, денег не выделят, а сам я без вендора не справлюсь со столь сложной системой, но директор сказал — «давай ставь», и неделька другая прямо на боевом слабеньком файловом сервере запустил тестовую систему.
Думал протестировать еще так пару месяцев (так в мануале написано), а потом думать, что делать дальше. Директор:» у тебя два конструктора и два дня» — Вот, блин — засада! Начали пробовать вроде криво, медленно, но пошло! Директор: «начинайте проект в PDM по троллейбусу» (те два конструктора были из троллейбусного отдела). Потом подключились еще двое новых конструктора — спецов по средним автобусам. И тут начались проблемы с большими сборками, сервер приложения тупо перегружался и писал, что мало памяти. Целый вечер методом научного тыка ковыряюсь в десятках инициализационных файлах сервера приложений и «о чудо» — наконец то запустился, правда дико сваповал, так как памяти там было всего 2ГБ.
За пару дней докупили ещё 2Гб, но все равно нужен был новый сервер — старый не подходил по параметрам. Купили новый сервер, еле перенес рабочий сервер на новый. Потихоньку начали загонять в PDM и Pro/Engineer остальных контрукторов, но тут дикое сопротивление ГК и компании, саботаж и угрозы срывов сроков если всех заставят работать в PDM. Поэтому еще пару месяцев работали в основном по старому, но прогрессивная часть уже осваивала PDM и Pro/Engineer. В это время директор начал мне доверять и почти каждый вечер заходил ко мне в кабинет чтобы обсудить ситуацию в коллективе (я ведь был его частью и знал кто чем дышит на работе) и совместный план действий. На тот момент произошли некоторые организационные изменения так как проектов было уже три, то приняли решение назначить отдельных главных конструкторов проектов (ГКП), они отвечали за техническую часть проекта организацию и координацию конструкторских работ, а также им выделяли бюджет на проект, и фактически они распределяли оплату работ по проекту. ГК плавно сместили в отдел перспективного проектирования, но убедили что он по прежнему тут главный. И тут мне пришла в голову идея использовать метод принятия решений, который часто использует ГК- собирает на техническое совещание начальников отделов (по совместительству давние друзья), озвучивает свой вариант, голосуют и решение принято одногласно и без сомнений.
Есть три ГКП из них два уже осознавали преимущества и перспективы PDM, третий был человеком ГК, но молодой и неопытный во всяких подковерных делах. Идея такая — собираем техническое совещание три ГПК и директор для протокола и так как там будут подниматься вопрос оплаты работ, и ставиться на голосование вопрос о создании конструкторской документации (КД) в 3D модели (первичной) и 2D чертежей, если конструктор сдает только чертеж без 3D, то оплата 50%. Озвучили коллективу — то за 2 недели все быстро освоили для многих новую программу и способ проектирования, и без возмущений и прочего. И самое главное без срыва графиков производства! ГК вначале был скептичен, потом шокирован и попытался палки в колеса поставить, но директор спокойно отбил его попытки. ГК практически остался не у дел, и через пару месяцев уволился. Но остались его друзья, которые также фактически были против прогресса и представляли «старую школу», поэтому в техническом плане часто использовали устаревшие в машиностроении конструктивные решения в стиле «трехуровневый пол для автобуса». Почему неразумно оставлять таких людей в коллективе начальниками отделов?
Проект трехуровнего автобуса с четырьмя одностворчатыми дверями и нестандартной шириной полностью провалился, его даже даром не хотели брать. Снова встал вопрос о разгоне НТЦ, но директор и новый ГК убедили руководство что все в порядке, и нужно лишь небольшие
