Разработки: атлас компетенций

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

УЛЫБКА СТЭНА ШИ

ИР-проекты очень сильно отличаются друг от друга (см. Классификацию рынка ИР-проектов на стр. 64). При анализе конкретного проекта прежде всего следует понять, какую роль играет или собирается играть коллектив разработчиков, каким образом он уже встроен или рассчитывает встроиться в рыночное окружение. Для этого уместно посмотреть на «улыбку» от Стэна Ши (Stan Shih). С тех пор как в 1992 году Стэн, основатель Acer Inc., обосновал необходимость диверсификации корпоративного бизнеса на основе «улыбки» (Smiling Curve), этой парадигме начали следовать не только отдельные предприятия и промышленные группы, но и целые страны.

Двухтысячные полностью подтвердили прогнозы господина Ши: к 2005 году конкуренция в секторе промышленного выпуска электроники сделала производство наименее прибыльным этапом бизнес-процесса и заставила предприятия переходить от модели EMS (Electronic Manufacturing Service) к моделям OEM, ODM и OBM.

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

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

В общем случае нижняя часть «улыбки» остается, скорее, за Азией, а верхняя часть ветвей до недавнего времени была прерогативой Запада. Все это продолжалось до тех пор, пока Азия не стала самым перспективным по емкости рынком (вырос уровень потребления в Китае и ряде других стран) — тогда для западной цивилизации осталась самая прибыльная и «сладкая» левая ветвь «улыбки» (правая ветвь при этом немного опустилась, в результате «улыбка» превратилась в перекошенную гримасу). На рисунке выделана серым сфера деятельности большинства «производителей» смартфонов, в реальности размещающих свои заказы на сторонних производственных площадках (частично Samsung, Apple, Huawei, Oppo/BBK, Vivo/BBK, OnePlus/ BBK, XiaoMi, MeiZu, ZTE и т. д.).

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

УСПЕХИ И НЕУДАЧИ РОССИЙСКИХ ПРОЕКТОВ

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

Для подготовки этих документов создается группа заинтересованных лиц , в которую входят руководитель проекта (обычно он же — менеджер продукта, директор по продукту или очень плотно работает с этими специалистами) и, на разных стадиях, привлекаются разработчики с требуемыми компетенциями (это могут быть как отдельные специалисты, так и целые коллективы). Для вывода нового продукта на рынок могут понадобиться и разработка дизайна, макетов, прототипов продуктов для исследования на фокус-группах, опытные модели или даже серии для проверки разного рода концепций (концепт-макеты, концепт-прототипы). Может потребоваться создание нового ПО — это отдельный процесс, по сложности не уступающий аппаратным разработкам. Если всего этого или хотя бы каких-то отдельных элементов процесса подготовки разработки или самой разработки нет, то вероятность состоятельности проекта резко уменьшается. Обычно такого рода непроработанные проекты теряют конкурентоспособность и погибают на той или иной стадии. Согласно международной статистике, около 95% стартапов оказываются коммерчески не успешными.

ПРИМЕР ОШИБКИ

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

В числе «неудачников» есть и другие примеры: поликристаллический кремний от ООО «Усолье-Сибирский Силикон»/Роснано (маркетинговый промах, rusnano.com), гибкие дисплеи от PlasticLogic/Роснано (отсутствие стратегического планирования, plasticlogic. com), режущая проволока от Advanced Wire Technologies (недостаточная технологическая компетентность кадрового состава компании, advancedwiretechnologies.ru).

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

ПРИМЕРЫ ПРАВИЛЬНОГО ПОДХОДА

Давайте посмотрим на положительный пример — разработку специализированных пищевых оболочек «Атлантис-ПАК» (atlantis-pak.ru). Компания была создана «в чистом поле», основой ее успеха стали научные разработки, что совершенно не характерно для бизнеса 90-х годов. Это были не накопленные в советское время наработки государственных НИИ, а результат работы созданной на предприятии полноценной научной лаборатории, одной из лучших в стране по оснащению и с мощнейшим научным коллективом. Ростовская компания смогла войти в тройку мировых лидеров в своей отрасли. Ее специалистам удалось улучшить потребительские свойства оболочек для мясной/колбасной и молочной продукции по многим параметрам. В первую очередь за счет интенсивных научных и технологических изысканий, реализации результатов крупными сериями, полной технологической независимости, концентрации ИР-проектов исключительно внутри предприятия (с тремя контурами защиты тремя независимыми службами безопасности). Разработки «Атлантис-ПАК» оказались чрезвычайно востребованными потому, что решали технологические, логистические, маркетинговые и потребительские проблемы оболочек в пищевой промышленности.

По аналогичной схеме развивалась траектория успеха разработки технологии производства высокоэффективных волоконных лазеров и усилителей от НТО «ИРЭ-Полюс» (ipgphotonics.com). Однако основное ядро специалистов, менеджеров и владельцев бизнеса вышло из советского закрытого НИИ — Института радиоэлектроники Академии наук, а ключевые производственные мощности располагались за рубежом (как из соображений безопасности, так и по геополитическим причинам). В обеих компаниях всеми значимыми бизнес-процессами управляли квалифицированные руководители, процессы разработки и маркетинга контролировались независимо друг от друга, а их деятельность синхронизировалась на уровне формирования направлений и планов разработки. Структуры управления и распределение зон ответственности в «ИРЭ-Полюс» очень напоминают таковые в компании Casio в период ее становления. Первым руководителем департамента разработок фирмы был Тошио Касио (Toshio Kashio), а его братья Тадао (Tadao), Кацуо (Kazuo) и Юкио (Yukio), в свою очередь, возглавляли направления управления, продаж и производства соответственно.

Другими примерами успешных ИР-проектов можно назвать создание цифровых ТВ-приставок GS Group (gs-group.com), разработку технологии выращивания искусственных сапфиров концерна «Энергомера» (energomera.com), разработку оборудования и ПО для автоматизации торговли ГК «АТОЛ» (atol.ru), разработку систем комплексной автоматизации международным холдингом Tibbo (tibbo.com), разработку интегрированных систем безопасности консорциума «Интегра-С» (integra-s.com).

ПРАВИЛА ИГРЫ

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

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

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

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

КОМПОНЕНТЫ И ИХ СТАНДАРТЫ

Как же в таких условиях определить образ будущего продукта? Современные рыночные требования привели к разительным изменениям в бизнес-процессах и структуре компаний. Лучшие из них уходят от сложной «вертикальности» принятия решений и управления в пользу упрощения и «горизонтализации» структуры, что повышает гибкость и приспособленность к быстрым инновациям и изменениям. Это, в свою очередь, влечет изменения в методологиях и технологиях разработки и вывода продуктов на рынок. Фактически мы идем семимильными шагами к управляемому хаосу интернета вещей (Internet of Things, IoT), когда поток дешевых, но программируемых и конфигурируемых под специфические потребности заказчиков аппаратных узлов и решений из Азии захлестнет западные экономики.

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

Все очень похоже на траекторию раннего развития рынков персональных компьютеров и их комплектующих — mainframes из рук монополиста постепенно теряют рынки в пользу немалого числа поставщиков комплектующих, и эти комплектующие должны уметь самоконфигурироваться в распределенных, децентрализованных и масштабируемых сложных системах. Только мир сервисов — это почти исключительно программное обеспечение, взаимодействующее как с аппаратными компонентами, так и с другими частями ПО в рамках концепции сервис-ориентированной архитектуры (SOA, Service-Oriented Architecture). Привлекательность и популярность SOA объясняется рядом преимуществ для потребителя и разработчиков по сравнению с традиционной архитектурой «готовых решений».

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

2 Сервисы являются «черными ящиками» для пользователей и клиентов. Клиент ничего не знает ни о внутренней структуре сервисов, ни о том, как и по каким алгоритмам они работают — тем более что клиент никак не зависит ни от структуры сервисов, ни от их алгоритмов. Равно и сервис никак не ориентирован на использование тем или иным клиентом и никогда «не знает», когда и кем будет вызван. Это позволяет разрабатывать, совершенствовать и использовать отдельные сервисы безотносительно целевого применения и/или истории применений, использовать сервисы от конкурирующих поставщиков.

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

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

Современной интерпретацией SOA является концепция микросервисов и микро-SOA (μservices, μSOA), используемая для построения распределенных аппаратно-программных систем, тесно связанных с набирающими популярность распределенными вычислениями. Сервисами в μSOA называются процессы, которые осуществляют сетевой обмен между собой для достижения функциональных целей. В такой атомизированной системе важнейшим фактором стабильности и обеспечения функционирования является «оркестрация» — правила взаимодействия сервисов между собой с использованием обмена сообщениями, включая бизнес-логику и последовательность действий. Концепция μSOA оказывается востребованной как для облачных платформ, так и в IoT-системах.

С целью унификации принципов взаимодействия в США, Европе и Китае разработаны национальные и международные стандарты (с июня 2017 года действуют и в России) на структуру таких компонентов. Нам ближе всего международные стандарты IEC 62890, IEC 62264 и IEC 61512 на структуру подсоединяемого («цифрового») компонента в Reference Architecture Model Industry 4.0.

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

Парадигма предполагает выполнение моделирования и верификацию системы на этапе проектирования. Заниматься ли разработкой аппаратной части или взять готовый «полуфабрикат» и дополнить его своей оболочкой — каждый решает сам, исходя из обстоятельств и специфики ИР-проекта. Поскольку недавний XIX съезд Коммунистической партии Китая подтвердил стремление страны наращивать экспортные потоки в Европу, нет оснований полагать, что разработчики из России и западных стран будут испытывать нехватку в промышленных составляющих. Всеобъемлющая технологическая поддержка цифрового будущего была также подтверждена и на токийском Hitachi Social Innovation Forum 2017.

СЛОН НА ШАРИКАХ

Хотелось бы обратить внимание разработчиков, что ни μSOA, ни структура рассмотренной на стр. 60 схемы подсоединяемого компонента RAMI 4.0 (Reference Architectural Model Industry) не предполагают наличия каких-либо программных шин и платформ. Программные шины являются атавизмом и служат лишь для привязки клиентских компонентов к сервисам конкретной интеграционной платформы. Да и нет никаких других причин для отказа от использования в качестве шины стека сетевых протоколов и сервисов. Платформа в современном понимании — это набор минимально необходимых и достаточных сервисов и/или μ-сервисов. Даже если платформа «убегает» в облака, не следует за бывать, что «слон» без шариков-микросервисов, специфических именно для вашего бизнеса, не взлетит.

О РИСКАХ

Возвращаясь к вопросу успешности ИР-проектов, хотелось бы поговорить о рисках. ИР-проекты требуют огромного количества ресурсов, и любые препятствия существенным образом влияют на доходы, операционные расходы, результаты, ответственность и собственность.

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

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

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

1. Оценка рисков и управление ими.
2. Количественная оценка потенциала для потерь.
3. Определение характера и документирование масштабов потенциальных потерь.

ОЦЕНКА РИСКОВ И УПРАВЛЕНИЕ ИМИ

Даже если в компаниях, ведущих ИР-проекты, возникает желание оценить риски, то оно обычно упирается в непонимание подхода к проблеме. Ничего сложного здесь нет — достаточно выявить уязвимости и слабые места в процессах, процедурах, аудитории проекта. Следует отметить, что большинство выявленных рисков требует совсем немного времени и расходов на их минимизацию — достаточно концентрации на отвечающих за эти моменты процессах и учете результатов.

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

Существует множество подходов к оценке рисков. Выделим несколько правил, важных именно для ИР-направления.

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

2 Определять взаимозависимость проектов. Если один из проектов прерывается или прекращается, вызывает ли это задержки или прекращение в других проектах? Для эффективной защиты компании от потерь должно быть понимание, где и когда может произойти «эффект домино», приводящий к обширным потерям интеллектуальной собственности и финансовых ресурсов.

3 Контроль распределения кадровых ресурсов по проектам. Это очень важно, но часто упускается из виду. Если проект прерывается, тормозится или даже прекращается, а под этот проект привлечен специалист, найдется ли для него достаточная загрузка? Что будут делать со своим временем исследователи и инженеры? Будут ли они производительным ресурсом?

4 Какие препятствия возникнут при попытке реанимировать прерванный проект? Часто, зацикливаясь на деталях ИР-проекта, его менеджеры теряют из виду последствия такого прерывания. Будут ли материальные ресурсы, оборудование и кадры доступны? Будет ли возможность подтвердить уровень компетенций компании перед регулятором в разумное время? Каковы будут задержки и стоимость реанимации ИР-проекта?

5 Оценивайте картину в целом. Важно пересматривать общий ИР-бюджет по всем проектам. Идет ли отдельное бюджетирование по каждому из проектов? Какая часть бюджета расходуется внутренними ресурсами, а какая часть находится на аутсорсе? Следует постоянно помнить о текущих операционных расходах по проектам, понимать объем годовых инвестиций и систему расходования их на защиту корпоративных интересов.

6 Сохраняйте и защищайте результаты работы. Для ИР-проектов особенно важна мантра, главная для ИТ-специалистов: сохраняйтесь как можно раньше и чаще. В силу уникальности многих разработок выбор методик и систем архивирования не всегда прост. Для отдельных проектов следует разрабатывать индивидуальный подход с целью минимизации стоимости и времени прерываний.

7 Поиск дублирования, унификация и многократное использование технологий. Компании нарабатывают свои пулы технологий и ноу-хау; обычной практикой является использование в разных проектах общих ресурсов и оборудования. Какие шаги следует предпринять, чтобы обезопасить такие ресурсы от взаимного влияния проектов или сред их применения?