Доклад на юбилее Аскона



Велогонка, в которой меняются лидеры:

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

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


САПР - сравнения, клиенты и проблемы

1) Одна из основных проблем на рынке САПР: пользуются одни люди, а платят совсем другие.

  • Поэтому, с одной стороны, АСУшникам вроде бы легче: главбух, финансовый директор, начальник планово-экономического отдела и прочие начальники чаще всего в той или иной форме реально пользуются их программами или результатами работы оных, а эти люди либо сами принимают решения, либо серьезно влияют на них. 
  •  С другой стороны, легче САПРовцам: большинство людей, называющих себя управленцами и занимающих высокие кресла, по образованию и способам мышления относятся к технарям (это бывшие конструкторы, технологи), они (сами того зачастую не осознавая и никогда в этом не признаваясь) лучше понимают технический язык, чем язык управления и принятия решений, который был и остается для них иностранным (сдать экзамен по нему еще можно, но думать на нем невмоготу). Кроме того, специалистам по САПР гораздо легче общаться с конечными пользователями, чем, к примеру, АСУшникам - их "клиентура" гораздо менее политизирована и амбициозна, более доступна, не имитирует безмерную занятость, не нацелена на лозунги, любит и, как правило, умеет делать свою работу. Кроме того, САПР, в отличие от корпоративных систем, не посягает на святая святых - систему власти и делегирования полномочий на предприятии.
2) Тех проблем, которые были несколько лет назад на рынке автоматизации проектирования, сегодня уже нет. В ту пору российских разработок было мало, западные не были русифицированы и отечественным пользователям было трудно найти нужный пакет. Сейчас есть из чего выбирать. Но как из нескольких вроде бы похожих программных средств выбрать «свое», нужное? Чаще всего перед заказчиками (в этом качестве выступают все, кому нужна техническая документация - промышленные предприятия и проектные институты, муниципальные и транспортные службы, милиция и пожарники, топографы и изыскатели, архитекторы и строители) встают такие вопросы:
  • что есть на рынке?
  • что с помощью данного пакета можно реально делать (универсальные пакеты бывают только в сказках)?
  • «уживется» ли новая программа с теми, что уже эксплуатируются?
  • насколько легко и быстро силами имеющихся специалистов ее можно освоить?
  • поможет ли это программное средство реально распараллелить работы?
  • какие перспективы у разработки и самое главное - разработчика?
  • когда окупится приобретение и т.д., и т.п.
3) Многие производственники уже дошли до мысли, что мощные или узкоспециальные проектные, конструкторские системы лучше покупать вместе с «головой и руками экспертов» (особенно если предприятие собирается с помощью этих систем зарабатывать деньги). "У экспертов - сказал мне недавно один опытный конструктор, работающий на крупном заводе, не просто есть различные методики сканирования, сколки, архивации или распознавания образов, они умеют обходить «подводные камни», связанные с оборудованием и программами, они знают, как создавать нужные чертежи и графики, знают, что делать с тем, что уже есть". Поэтому спрос на знания и опыт неуклонно растет. Но тех, кто создает системы автоматизированного проектирования, это не должно успокаивать.


САПР и бизнес: языковой барьер

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


История одной случайной продажи:

1) Приведу один конкретный забавный пример с комментариями. В начале прошлого года мои знакомые программисты привели ко мне домой в Нижнем Новгороде своих знакомых и те показали весьма мощный графический редактор и обработчик трехмерных изображений. Они сыпали словами: "слои", "разрезы", "полутени", "быстрое уничтожение невидимых линий", показывали какие-то сложные детали красивой расцветки и непонятного значения.
2) Честно говоря, было скучновато, программ всяческих я за свою жизнь насмотрелся в избытке (и у нас, и за рубежом), а вникать в тонкости не было ни желания, ни времени. Тем более, что я в те дни как раз выполнял крупный заказ по реорганизации системы управления и системы маркетинга довольно крупной местной оптово-розничной фирмы, торгующей канцелярией, банковским оборудованием и офисной мебелью.
3) Поскольку об их проблемах я в ту пору думал постоянно, я механически спросил у разработчиков графической программы: "а несколько вариантов расстановки мебели из каталогов в конкретном зале она смогла бы сделать?". "Нет проблем", - обиженно ответили разработчики на мой детский вопрос, и продолжили свой нудный рассказ о поворотах в пространстве, преобразованиях цветов и теней, каких-то метабиблиотеках.
4) На следующий день в разговоре с руководителем оптово-розничной фирмы я спросил: "А почему вы продаете только мебель по каталогам? Не лучше ли продавать сразу результат? Дизайнер у вас есть, варианты можно сделать быстро и красиво --на компьютере. "А что, разве есть такие программы? - удивился бизнесмен. "Есть, - сказал я, - одну из них я смотрел вчера у себя дома". "А как мне ее посмотреть?" - спросил бизнесмен. "Я не торгую ни мебелью, не программами, я торгую идеями и знаниями, - ответил я, - вот вам их рабочий телефон, звоните и договаривайтесь."
5) Выйдя от директора, я позвонил разработчикам сам, предупредил о возможном звонке солидного клиента (к которому сами они, кстати, даже не смогли попасть на прием) и попросил употреблять в разговоре слова "офис", "стулья", "столы", "шкафы", "свободная площадь", "удобство клиентов и сотрудников" и по возможности вообще не употреблять такие слова как "разрез", "слой", "полутень" и прочие.
6) Как я потом узнал от заказчика, встреча длилась не более 20 минут, бизнесмен задал несколько вопросов, получил ответы и немедленно купил программу. Впоследствии он успешно использовал ее, расширив тем самым спектр услуг и "вставив перо" конкурентам за счет чуть более глубокого видения и понимания рынка.
7) Попробую (с точки зрения бизнес-аналитика) проанализировать этот случай:

  • Прямой путь "разработчик-пользователь" или даже "продавец-заказчик" оказывается далеко не всегда самым коротким и эффективным. Важна не сила удара, а его точность. В данном случае, я, сам того не желая, выступил в роли агента влияния. С одной стороны, заказчик достаточно доверял мне, ибо доверил план реформирования управления собственной фирмой, и мое мнение было для него значимым, с другой, он не подозревал меня в личной корысти (получение процента от продажи программы грозило репутации консультанта, да и финансово было малоинтересно - по сравнению с консалтинговыми проектами). 
  • Я перевел разговор о продаже программы (именно это было целью разработчиков) совершенно в другую плоскость, я нашел (сгенерировал) у тогдашнего своего клиента еще неясную ему самому потребность в создании новой услуги (расстановка офисной мебели), которую этой программой можно было удовлетворить. Для меня рынок - это поиск розетки, поиск вилки и их совмещение (может быть, с помощью переходника). В данном случае "вилкой" была программа, "розеткой" - заказчик, "переходником" - я сам.
  • И третий важный момент: надо учить "иностранные" языки. Не столько английский и французский, сколько языки твоих потенциальных (да и нынешних тоже) клиентов, заказчиков, партнеров. Лучше объясняться жестами, как не знающие языков россияне в западных ресторанах или искать переводчиков, но только не разговаривать на своем собственном тарабарском языке. Для вас очень важно, что вы храните в электронной библиотеке не описания элементов, а к примеру, правила генерации этих описаний, а для, директора, подписывающего платежку, это просто не имеет никакого значения.
  • Нужно научиться смотреть на рынок с точки зрения нынешних и потенциальных клиентов, непрерывно "сканировать" рынок - в частности, собирать, накапливать, даже прогнозировать, угадывать конкретные требования конкретных клиентов (каждый должен получить конфетку, пусть типовую в нужной ему обертке). Мало знать, кому что нужно сегодня для решения важнейших проблем, нужно понять и что кому понадобится завтра, кто о чем думает и мечтает.
  • Нужно научиться слушать, слышать и согласовывать смыслы. И учебно-демонстрационные центры, коих немного (особенно в провинции) должны заботиться о том, чтобы демонстрировать потенциальному клиенту возможности чудо-программ на его конкретных, пусть простых тестовых примерах. Любому человеку приятно, когда говорят о нем и обсуждают его проблемы, он не хочет покупать "кота в мешке".


Поздравления:

За прошедшие две пятилетки "Аскон" (дважды столичная фирма, поскольку работает в Питере и в Москве) добился достаточной известности на достаточно узком рынке. Я желаю, чтобы в своей третьей пятилетке он добился широкой известности на широком рынке (тем более, что и зарубежные примеры - Microsoft, и отечественные - 1С у всех перед глазами), чтобы он ставил перед собой масштабные цели и достигал их (сохраняя темпы и не теряя качества).