Статья о CAD CAM-системах.



Уважаемая редакция!

В августовском номере журнала «САПР и графика» мое внимание привлекли две весьма разноплановые статьи - одна, «SolidWorks шагает по России (провинциальные истории)», другая - «Сравнительный анализ CAD/CAM систем». На первый взгляд, в них нет ничего общего. В одной, в весьма свободной форме с юмором, излагается опыт поиска и выбора системы на рынке, в другой делается попытка отвлечься от эмоций и сравнить функционал различных систем применительно к ряду важнейших задач, возникающих на машиностроительных предприятиях.

Обе статьи считаю весьма полезными (и описание опыта, и аналитика сегодня очень нужны). Вместе с тем, хотел бы предостеречь читателей весьма уважаемого мной журнала от абсолютизации положений и выводов, содержащихся в этих статьях. Попробую изложить и обосновать собственную точку зрения.

Для простоты подход саратовских коллег, авторов «провинциальных историй», будем называть «эмоциональным», а подход А.Погребинского и А.Павлова, авторов сравнительного анализа систем, «функциональным». Не сомневаясь в возможности и важности обоих этих подходов, хотел бы здесь поговорить об их односторонности и, следовательно, ограниченной применимости.

Самолет на пробу?

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

Сразу хочу заметить, что коллеги наступают здесь на типичные «стратегические грабли». Во-первых, считается, что специалист конструкторского отдела или отдела автоматизации хорошо представляет себе цели и задачи предприятия, бизнеса в целом. Во-вторых, считается, что главное - освоить возможности сложного программного продукта, а уж применить его для решения конкретных задач фирмы специалисты сумеют без всяких внешних консультантов. Внедрим пакет и будем «печь конструкторскую документацию как блины».

Я, между прочим, чуть ли не еженедельно получаю по электронной почте письма типа «я работаю в отделе АСУ завода Н в городе А, какую корпоративную систему Вы, автор самого термина КИС и признанный специалист по этим вопросам, посоветуете нам выбрать?». Что-то вроде: доктор, я принимаю анальгин, поможет ли это? Ни подробного описания завода и его продукции, ни информации о клиентах и конкурентах. Слепая вера в то, что есть некий универсальный «золотой ключик», надо только найти хорошего специалиста, который подскажет, где он лежит.

Между тем, не все так просто, как кажется. Современные системы автоматизации управления и проектирования слишком сложны - и, прежде всего, с точки зрения организационно-психологической. Предприятие, решившее внедрять подобные системы, вынужденно проходит через целый ряд существенных изменений, далеко не всегда быстрых и безболезненных.

Как научиться водить самолет? Достаточно ли для этого прослушать курс лекций или взять его «на пробу»? Любая сложная система требует не только знаний, но и навыков. Сначала люди учатся летать, глядя на действия летчика-инструктора, потом им доверяют штурвал, но тоже под наблюдением опытного инструктора. Скажем больше - знаний и навыков тоже недостаточно, крайне важна технология и организация работы. Самолет ведь существует не в безвоздушном пространстве, он тесно связан с наземными службами. Если воспарить в одиночку ему случайно и удастся, то приземлиться вряд ли. То же касается и подразделения САПР - не удастся ему воспарить над уровнем завода в целом, сильно оторваться от уровня маркетинга, производства и управления.

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

Нужно не обучение ради обучения, а обучение по мере необходимости. Создание на заводе учебного центра по программному продукту - это «изящный» шаг в сторону, к перепрофилированию предприятия. Я не думаю, что следует превращать завод в ВУЗ, где зачастую изучают предметы вообще, а не применительно к решению конкретной практической или перспективной задачи. Превращать завод, пусть неявно, в филиал вуза имеет смысл только в том случае, если таким оригинальным способом ищется новое место работы.

Если же речь идет все-таки не о поиске работы для себя лично, а о развитии фирмы, то обязательно нужен пилотный проект, в котором совместными усилиями поставщика и потенциального заказчика будет на базе данной системы решена конкретная, важная для потенциального заказчика и им самим выбранная задача (или набор задач). Будет ли этот пилотный проект платным или бесплатным, могут ли применяться гибкие финансовые схемы - это важно, но это не главное. Главное - показать, что с помощью данной системы и с участием специалистов предприятия намеченная работа может быть успешно завершена в плановые сроки. Еще раз повторюсь, это не технический вопрос, а вопрос организационный и психологический.

Мочь-то она может, да кто ж ей даст?

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

Анализ функциональности - дело необходимое, но совершенно не достаточное. В этом должны отдавать себе отчет все, кто занимается поиском, выбором и внедрением сложных систем. Технологические и ценовые сравнения, конечно, требуют значительных затрат, но развитие рынка неизбежно приведет к появлению независимых фирм, агентств, которые такую информацию будут готовить (естественно, потенциальные заказчики должны дозреть до того, что такая «многомерная» информация дорогого стоит).

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

Есть еще один важный момент, который нельзя не учитывать - интересы человека, интересы подразделения и интересы предприятия совершенно различны, а нередко и противоположны. Выявление, формализация и согласование этих уровней интересов - дело достаточно сложное и мне совершенно не хочется отбивать хлеб у себя и своих коллег, профессиональных консультантов по управлению. Замечу лишь, что если исходить исключительно из интересов конкретного подразделения (САПР, АСУ или иного) или тем более конкретных специалистов (желающих себя показать и карьеру сделать), это нередко оказывается гибельным для бизнеса в целом.

Опыт показывает, что организационные изменения легче инициировать внешним специалистам или самому руководству предприятия. Инициировать серьезные изменения изнутри, особенно с уровня инженеров и конструкторов, крайне сложно.

Жизнь сложилась так, что прежде чем стать (в 1993 году) профессиональным консультантом по управлению и оргразвитию, я успел поработать в течение почти 20 лет в различных отраслях, занимаясь САПР, потом АСУ ТП, затем АСУ, прошел путь от программиста до начальника крупного отдела автоматизации, а затем заместителя директора известной компьютерной фирмы. Благодаря этому мне удается смотреть на различные проблемы с самых разных точек зрения.

А на бензин вам хватает?

Можно, например, смотреть на все с точки зрения недостатка финансовых ресурсов. У нас нет денег, поэтому покупаем самое дешевое, откликаемся на «ласку» поставщиков, надеемся, что добрые дяди не бросят нас в море в трудную минуту. Это классическая позиция жертвы - «не я виноват, виноваты обстоятельства».

Я часто провожу стратегические семинары для руководителей предприятий, и как только речь заходит о корпоративных информационных системах, сразу раздаются голоса: «Да у нас денег нет, да где мы возьмем 50 или 100 тыс. долларов?». Тогда я задаю вопрос: «Поднимите, пожалуйста, руку те, кто ходит на работу пешком ввиду отсутствия денег на бензин для служебного автомобиля?» Ни разу не видел ни одной поднятой руки. Тогда следует второй вопрос: «Поднимите руку те, у кого служебный автомобиль жигули?» Затем третий вопрос: «Поднимите руку те, кто за последний год ни разу не был в заграничных командировках?».

После этого блиц-анкетирования я спокойно делаю вывод, и аудитория немедленно с ним соглашается. Дело, оказывается, совсем не в нехватке денег на автоматизацию проектирования, управления или технологических процессов. Дело в том, что все это не входит в число стратегических приоритетов предприятия и финансируется, естественно, по остаточному принципу, как и любые другие второстепенные с точки зрения руководства направления.

Начальник отдела автоматизации крупного химкомбината несколько лет назад жаловался мне, что никак не может выпросить 2 тысячи долларов у высшего руководства на модернизацию безнадежно устаревших 286-х компьютеров. Через некоторое время я встретился с этим самым высшим руководством (меня пригласили для консультаций) и мы выяснили, что оно испытывает огромную потребность в информации. Мы нарисовали вместе табличку, которую руководству хотелось бы на столе иметь ежедневно с утра, и я сказал, что технически это сделать несложно, но нужно модернизировать компьютерный парк, закупить сервер, четко мотивировать людей на оперативное получение данной информации.

«Сколько для этого нужно денег?» - спросил руководитель комбината. «Для первого этапа информационных преобразований 10-15 тысяч долларов должно хватить», - ответил я. «Нет вопросов, найдем. Мы из-за отсутствия этой информации теряем гораздо больше». Предвижу возражения - нет пророков в своем отечестве, внешних консультантов ценят больше, да к генеральному и на прием-то не попадешь. Но факт остается фактом. Начальник АСУ увлекался мелкотемьем, не воспринимал высшее руководство комбината как своих клиентов, не пытался предложить им то, что могло бы их заинтересовать. Потому отдел АСУ оставался отделом третьего сорта, не заслуживавшим даже минимальных капиталовложений. Между тем сильные специалисты по автоматизации (и такие примеры мне известны), достаточно быстро разобравшись в особенностях конкретного бизнеса, обычно быстро делают карьеру и пробиваются на уровень вторых лиц предприятия.

Классический вопрос - а ты меня уважаешь?

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

Можно смотреть на все с точки зрения собственного персонала - конструкторов и автоматизаторов - насколько привлекателен продукт и/или поставщики этого продукта. Насколько удобен интерфейс, проста и понятна документация, доброжелательны представители поставщика? Все это, конечно, надо учитывать, но этого мало. Потому что конечной целью данного продукта является не получение удовольствия конкретными специалистами на рабочих местах, а встраивание его в принятую или вновь разрабатываемую технологию, помогающую получать прибыль и развивать бизнес.

Во время командировок в США даже в достаточно известных фирмах я не раз обнаруживал некрасивые и неудобные системы с недружественным интерфейсом. «Почему вы их не замените?» - спрашивал я руководителей этих фирм. «Потому что мы здесь не развлекаемся, - отвечали мне, - а деньги делаем. Они не очень удобны для конкретных сотрудников, но в целом для бизнеса по соотношению результативность-стоимость являются весьма эффективными. Зачем же их менять?».

Итак, каждый, взявшийся выбирать систему, руководствуется собственными критериями - один простотой освоения (чтобы не напрягаться), другой - сложностью освоения (чтобы выделиться в среде товарищей) и так далее. Если у предприятия нет бизнес-стратегии или она не доведена до всех сотрудников, не понята и не принята ими, трудно обвинять сотрудников в том, что они руководствуются чем угодно, но только не стратегическими интересами предприятия.

Бизнес-подход связан с другим взглядом. «Плясать» нужно не от недостатка ресурсов, капризов собственного персонала или красоты конкретного продукта, а от бизнес-задач предприятия в целом и бизнес-перспектив, определенных стратегией его развития. Нужен генплан развития (интересующихся могу отослать к своей подробной статье «Какая фирма без генплана?», опубликованной в журнале «Компьютер Пресс», № 12, 1998 год).

Конечно, со своим начальством бороться (за позицию на предприятии и за первоочередное выделение ресурсов) тяжело. Тяжело возбуждать начальство на реальные изменения ситуации на предприятии, добиваясь уважения и понимания. Не очень легко добиться уважения и понимания и от клиентов. Но все это - не повод для того, чтобы тешить свое самолюбие и капризничать перед поставщиками оборудования или программных продуктов, превращать заводы в филиалы ВУЗов или центры по опробованию систем.

Понимаю, что путь, связанный с выработкой стратегии, генплана развития, с осуществлением пилотного проекта, значительно выходит за рамки «эмоционального» и «функционального» подходов. Этот путь недешев и непрост, но кто сказал, что у современных сложных задач проектирования и управления есть простые решения?