Ассоциация Предприятий Промышленной Автоматизации Украины

Слабая масштабируемость – как главный тормоз выхода на новые рынки. Часть 1.

Слабая масштабируемость технических решений и методов ведения бизнеса является главным тормозом нашей системной интеграции в выходе на зарубежные рынки и шире – на любые новые рынки.

В серии из 2-х статей мы проанализируем ситуацию в этой области и начнем важную дискуссию накануне очных мероприятий АППАУ по консолидации украинских интеграторов в экспортных инициативах.

Что такое масштабируемость, и зачем это нужно

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

Например, в информатике масштабируемость – это изменение вычислительной мощности без изменения базового ПО. Хороший пример в коммуникациях - сеть Интернет, технология которой (TCP/IP) оказалась способной поддерживать сеть в масштабах земного шара. Или социальные сети как Facebook (сайт!), которые со своего рождения способны поддерживать взаимодействие новых и новых миллионов пользователей без кардинального изменения исходного кода.

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

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

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

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

Кейс  инжиниринговой группы «Омега» 

Это реальная история известной инжиниринговой группы, которая в середине 2000-х решала ряд задач по унификации комплексных решений с целью выхода на новые рынки – отраслевые и географические.  В области системной интеграции АСУ менеджмент решил применить известные управленческие методы как: 

  • Лучшую сегментацию и фокус на целевых рынках и приложениях: в системной интеграции: невозможно быть мастером везде, - необходимо концентрироваться на нескольких целевых отраслях либо приложениях и особенно, если вы хотите включить в компетенции технологическую составляющую
  • Унификацию-стандартизацию решений и программного кода: вещи очевидные для системных архитекторов в любом программно-техническом комплексе.
  • Более автономные и независимые отделы продаж: речь о том, чтобы «освободить» менеджеров продаж от постоянной зависимости от проектных менеджеров и проектантов. Последние каждый новый проект рассматривали как нечто абсолютно новое и тем самым ставили менеджеров по продажам в очередь за выдачей коммерческих предложений. 
  • Более тесная интеграция с другими подразделениями группы: речь шла о выработке типовых решений, как на уровне АСУ, так и в составе комплексных технологических решений.

В целом, только 30-50% этих нововведений оказались реализованными.  Они встретили сильнейшее сопротивление со стороны менеджмента среднего звена, причем, самое сильное противодействие оказалось в самой старой, но и самой компетентной фирме группы. Основные ограничения и причины сопротивления, касались не столько технических компетенций, сколько ментальности и организационной культуры – назовем только 3 фактора:

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

Попытки менеджмента сломать сопротивление путем увольнения и замены руководителей фирм не имели успеха. В  результате в конце 2000-ых эта группа просто распалась, - сотрудники разошлись по разным компаниям.

Кейс машиностроительного предприятия «Альфа»

До начала 2000-ых «Альфа» было поставщиком серийных машин- агрегатов для нескольких секторов нефтегазовой отрасли, - в ряде случаев они были поставщиком №1 на территории  всего бывшего Советского Союза. Еще в середине 2000-х они имели самый большой инсталлированный парк, мощное КБ численностью под 1000 чел и лучшие производственные возможности. Когда в 2008 г. на предприятие вошла новая команда топ—менеджмента, она увидела множественные просчеты,  как во внешней стратегии, так и во внутреннем устройстве организации. За 10 последних лет, концепция ведения бизнеса значительно изменилась. Еще в конце 90-ых в связи с резким падением серийных заказов, предприятие начало мигрировать в сторону отдельных, но крупных инжиниринговых проектов – вплоть до строительства заводов «под ключ». И в 2008 новый менеджмент увидел странную ситуацию – большинство направлений, связанных с серийной продукций, были в полном упадке. Напротив, все, что касалось инжиниринга находилось полностью на ручном управлении и велось кустарными методами. На предприятии не существовало никаких современных практик проектного управления, существовали огромные барьеры между разными подразделениями, и даже конструктора, которые казалось бы, должны стремится к унификации, рьяно защищали позицию «что каждый технологический объект (в одних и тех же приложениях) - другой» - поэтому и КД на машину будет особенной. Здесь мы также видели полную и странную зависимость маркетинга и продаж от технарей – предложения выдавались долго, иногда – слишком поздно. Показательными были случаи, когда топ-менеджеры с управляющей компании находили новых потенциальных клиентов на Ближнем Востоке, однако коммерческих предложений им так и не поступило.

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

Общая картина украинского инжиниринга в области промышленных АСУ

Итак, что общего в этих двух случаях – на первый взгляд, столь разных по размеру предприятий, по истории и по потенциалу? В обоих кейсах мы видим:

  • Кустарные, доморощенные либо слишком локальные практики и методы в технической области, не позволяющие выходить на уровень тиражируемых решений
  • Устаревшая пост- советская орг. культура, тормозящая инновации. В частности, большие разрывы и барьеры между отделами – направлениями бизнесов, которые на корню тормозят любые нововведения, особенно, когда речь идет о решениях на уровне всей фирмы, - а не локальных изменениях в ПО либо в проектировании. Отдельного рассмотрения заслуживает вопрос «технологи – автоматчики»  - и те, и другие говорят на разных языках, общих стандартов–интерфейса нет.
  • Практически полное отсутствие бизнес-процессов по созданию новых решений на постоянной основе, см рис. 1. В процессном подходе, продажи, получающие запросы с рынка, должны иметь готовые шаблоны – примеры типовых решений и быть достаточно автономными для принятия решений. По крайней мере, для решений и ситуаций, действительно отработанных годами. Типичная проблема, как мы видим, в том, что бизнес-процессы по разработке системных (типовых) инжиниринговых решений отсутствуют как таковые. Процессы идут от проекта к проекту и каждый раз индивидуальные. 

Рис.1 

  • Незнание современных стандартов ведения проектного бизнеса – хотя бы общепринятых в инжиниринге, как PMI / Pmbok.  Это кажется очень странным, но среди участников форумов и тем более призеров конкурсов SpiderProject, ежегодно организуемых в Украине в области проектного управления, вы практически никогда не встретите инжиниринговых фирм. 

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

Что менять и на что?

Это классический вопрос в методе ТОС, - одном из самых популярных в управленческих практиках. В случае изменений – и особенно в случаях масштабирования системы, - не нужно браться сразу за все, а нужно сосредоточиться на ограничениях. В нашей начинающейся дискуссии о возможностях выхода зарубеж, нужно придти к консенсусу, что является нашими ограничениями в масштабировании украинского потенциала инжиниринга – действительно еще огромного по качеству исполнителей и в целом, наработанных решений. Но крайне слабого по возможностям тиражирования. Даже сейчас, если взять наших членов АППАУ и предположить, что мы можем  что-то предложить зарубежным клиентам, в большинстве случаев нам нечего сказать. Мы просто не знаем, а сами фирмы молчат – это и есть проблема, указанная на рис. 1. Конечно, с редкими фирмами, как ПГ «Техинсервис» мы уже достаточно проработали тему и решений, и понимания их ключевых компетенций, и сообщений рынку. Но это скорее исключение, которое подтверждает общее правило – наши фирмы не готовы тиражировать свои решения, - ни на уровне маркетинга-продаж (полное отсутствие месседжей), ни на уровне самих решений. Похоже на то, что фирмы не понимают, что это также нужно заказчикам в самой Украине – см выводы по Хакатону и о 4-х уровнях мышления.

Отвечая на вопрос «на что менять», мы видим 3 главных направления изменений для лучшей масштабируемости:

  1. Реальный выход на Типовые решения  - на уровне архитектур программно-технических комплексов, программного обеспечения, а также использования современных стандартов как ISA-88
  2. Современное Проектное управление: использование лучших практик PMI/IPMA, применительных к области АСУ, позволяет снять – оптимизировать многие ограничения, связанные с производительностью, ресурсом и управлением изменениями в новых проектах.
  3. Значительно лучшее взаимодействие с вендорами: здесь масса неиспользуемых либо малоиспользуемых возможностей – как на уровне инноваций, так и касательно кооперации на разных рынках.

Безусловно, отдельно нам нужно рассматривать изменения в области ментальности и орг. культуры – прежде всего, как преодолеть традиционные парадигмы «хуторянства», до сих присущие многим представителям малого-среднего бизнеса и не только в инжиниринге, и не только в пром. АСУ.  Лучшим примером и бенчмарк здесь является ИТ-индустрия. А также – изменения в области маркетинга-продаж и развития бизнеса. Это must be вещи, если говорить об экспорте.

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

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

 

 

Комментарии: