Comments 33
Не обязательно. Возможно, у них просто по пункту "нетворкинг"(упомянут среди "Исследователи выделили пятерку самых актуальных навыков для специалистов сейчас:") высокий порог — и тогда все недостаточно хорошо умеющие в самопиар "не соответствуют требованиям".
То есть возможен вариант "попросту требования компаниями заявляются такие, что им соответствует менее 4% имеющихся на рынке труда специалистов".
Если менее 4% IT-специалистов имеют необходимые навыки, то вопросов к IDC я больше не имею. Подобный разрыв в ожидании и предложении говорит за себя о квалификации «исследователей».
Я понимаю, что обидно, но если откинуть эмоции.
Львинная доля ИТ-шников занимаются несерьезными вещами. Утрируя: эникейи и изготовители сайтов-визиток. То есть просто негде набить руку. Это нормально. Очень сложных задач не так уж и много в процентном соотношении.
Мол, айтишники, они же такие непонятные, на своем птичьем языке разговаривают. это у них какие-то детские фреймворки, деплои, роллбеки. Зачем вам, уважвемым людям, в эту муть лезть? Для серьезных господ такая понятная и очевидная цифровая трансформация есть.
У Пелевина это называлось Random Code Programming )))
IT-архитектуры и переход на новые архитектуры (например, облачные)
Читай: 96% специалистов не хочет переплачивать за Azure
Не стреляйте в исследователя, он показывает нам то что наисследовал.Так ЧТО он исследовал? Что конкретно подразумевается под цифровой трансформацией? Откуда и как получены цифры? Я не понимаю. Вы понимаете?
Так это вопросы к исходнику — то есть к той самой проводившей исследование IDC, которая это именно так у себя эту новость и написала(первая ссылка в статье).
Цифровая трансформация это переход к структурированному процессному взаимодействию, с оптимизацией и автоматизацией процессов, вовлеченных в трансформацию. Основными драйверами являются концепции Business Process Management/Business Activity Monitoring, которые утверждают, что любой бизнес-процесс должен быть измерим автоматически и иметь конкретную метрику эффективности. Для этого многие вендоры обьединяются в форумы (например, TMForum, 3gpp, ETSI) и разрабатывают общеотраслевые процессные фреймворки и спецификации (eTOM, SID, OpenAPI, ETSI NFVi), которые становятся отраслевыми стандартами.
Внедрение же этих или других подобны фреймворков выполняется путем развертывания и конфигурации соответствующих BPMS-систем и смежных business support systems. В рамках внедрения собирается картина «Как сейчас», у стейкхолдеров собираются требования на предмет «Как хотим чтобы было» и создается комплексное решение по трансформации от первого ко второму, включающее в себя развертывание (зачастую и доработку, а иногда даже и разработку) BPMS, а также доработку учавствующих в автоматизированных процессах IT-систем таким образом, чтобы они научились отчитываться об эффективности своих бизнес-процессов по выполнению каждого экземпляра такого бизнес-процесса, научились стартовать и останавливать экземпляры бизнес-процессов по команде из центральной системы BPMS ну и научились включаться в новые бизнес-процессы путём минимальной доработки.
Если же попытаться передать смысл цифровой трансформации образно, то это переход от ручного труда с вкраплениями автоматизации к автоматизированному управлению предприятием, с вкраплениями ручного труда.
Лично я специализируюсь на «цифровых трансформациях» операторов мобильной связи. Для этого мне приходится в деталях знать работу каждого типового отдела типового мобильного оператора, знать средства автоматизации всех этих работ, знать технологическую дорожную карту (от неё зависят появление новых отделов, процессов и технологий) с поправкой на уровень развития региона и уметь собрать из этого более оптимально и дешево работающий бизнес (обычно эти измеримые критерии наиболее интересны операторам-заказчикам), выписав список необходимого оборудования и ПО и человекочасов для его организациии, после чего используя этот ограниченный список выполнить/внедрить данные обязательства.
Предпосылкой к такой трансформации обычно происходит этап, когда бурный рост новоиспеченной компании со временем замедляется и она переходит в следующую фазу, фазу кровавого энтерпрайза. Основная суть выгоды — это вносить изменения в едином для всех отдела виде в BPMS сценарии нужно меньше компетенции, чем писать для этого in-house сервисы или покупать новое COTS-решение для поддержки ветки процессов нового отдела.
Можете для интереса на примере ДоДо-пиццы посмотреть. Все этапы приготовления продукта централизованно мониторятся и контролируются. Они натурально рецепты "деплоят" на всю сеть пиццерий.
Звучит как скопипащенное откуда-то введение в курсовую работу нерадивого студента, или какой-то корпоративный булщит. Куча аббревиатур, деепричастных оборотов, и сложноподчиненных предложений. Суть то в чем?
Как я понял, из личной переписки с товарищем выше — вся цифровая трансформация сводится к покупке и настройке BPM.
Впервые встречаю, чтобы меня понимали с точностью до наоборот, хоть у меня и присутствует некая косноязычность, присущая любому инженеру. Мне так и не удалось вам объяснить в личной переписке, поэтому попробую ещё раз здесь, в общей. Во-первых, позвольте остаться в рамках моей специализации, чтобы объяснить именно по сути, а не быть голословным (про ресторан вам уже корректно подсказали на примере ДоДо пицца). Во-вторых, начну именно с разъяснения того, что вы назвали «скопипащенным введением».
Каждая развивающаяся компания проходит этапы от бурно растущего стартапа до превращения в неповоротливую махину — энтерпрайз монстра (либо до покупки оным).На первом этапе очень мало, а то и совсем никакого времени не уделяется
анализу, моделированию и оптимизации бизнес-процессов компании, они создаются на ходу и автоматизируются подручными средствами. Так возникает silo-based структура предприятия, когда отдел по работе с клиентами закупает CRM-систему(B2C,B2B,B2G каждый свою),
бухгалтерия и HR каждая по своей ERP, каждый новый канал продаж приносит свою систему выполнения заявок и для каждой системы свой отдельный мониторинг её функционала (зачастую, близкого айтишникам, но совершенно нерелевантного бизнесу).
Часть этих систем подвязывается на дорогие 3rd party лицензии (например, Oracle) или проприетарные технологии/поддержку.
Рано или поздно, операционные расходы на весь этот зоопарк начинают парить CIO, а долгий Time to market для новых продуктов начинает расстраивать маркетинг, после чего они начинают поглядывать на способы решения этой проблемы и приходят к необходимости структурировать свои процессы в соответствии с неким отраслевым фреймворком. Поддержка ПО, к примеру, таким образом приходит к ITIL, мобильные операторы (а точнее вендоры мобильного ПО и оборудования, но это отдельная история, могу рассказать, если интересно) приходят к Frameworx (используется в том числе и совместно с ITIL, где-то встречал даже карту пересечения процессов).
Для вендоров телеком ПО и оборудования сейчас суть трансформации, как услуги для клиента, заключается в том, чтобы взять из этого фреймворка те ветви процессов, которые автоматизируются продуктами этого вендора и создать из них кастомное решение (с привлечением оговариваемого в контракте процента доработок), зачастую с широчайшим использованием открытых технологий: camel для API, camunda для BPMS, cassandra для базы абонентов мобильного оператора, hadoop для data-lake натекающего с каждой вышки-коммутатора-свича-финтранзакции и т.д.
При этом, задача вендора показать телеком оператору повышение эффективности бизнес-процессов в результате трансформации: ускорение времени вывода на рынок новых продуктов, а также снижение операционных расходов на усовершенствования и изменения бизнес-процессов и поддерживающих этих процессы соответствующих IT-систем от кучи сторонних производителей. Вторая же задача, показать инструмент/способ для простого выявления требующих оптимизации бизнес-процессов. Использование же именно этого фреймворка гарантирует межвендорное взаимодействие, так как сам фреймворк хоть и был разработан на базе открытых технологий, но сделано это было сообществом всех вендоров отрасли: от Хуавея, IBM и Microsoft c Red Hat до Нокии с Эрикссоном и VMware.
Использование BPMS системы (а не BPM, как вы ложно поняли из личной переписки) позволяет лишь перенести точку изменений с дорогой системы, на более дешевую, зачастую opensource, для которой вы найдете интеграторов/разработчиков с улицы, а управлять жизненным циклом типовых изменений смогут даже штатные бизнес-аналитики. Также, использование такой системы позволяет централизованно собирать метрики эффективности всех сервисов, реализующих те или иные субпроцессы и предоставлять аналитикам информацию, которую можно использовать впоследствии для оптимизации бизнеса.
Если попробовать привести пример далекий от BPMS, то это могут быть ETSI NFVi решения с доработанным Openstack, когда вендор предлагает свои решения по виртуализации, соответствующие отраслевому стандарту. Переход от дорогих проприетарных виртуальных машин к дешевым open-source контейнерам с использованием таких решений тоже можно назвать мини-трансформацией (минимально бизнесовой, максимально айтишной)
Я постарался привести примеры только открытых стандартов и технологий, но на самом деле фреймворки бизнес-процессов о которых я выше попытался рассказать, являются метастандартом, который может объединять в том числе и проприетарные дорогие вещи, как например решения на базе IBM BPM (WebSphere based) и на базе Oracle.
Лично вам рекомендую в качестве домашнего развлечения подёргать Nasa API с помощью Red Hat Process Automation Manager, это отрезвляет и уберегает от дальнейших огульных оценок технологий и концепций, которые на первый взгляд непонятны.
P.S.: Здесь , для понимания глубины кроличьей норы, можете ознакомиться с подробной, хоть и устаревшей, СТРУКТУРИРОВАННОЙ моделью бизнес-процессов типового мобильного оператора, если конечно что-то понимаете в UML. Стоит отметить, ни один мобильный оператор не переходит к её использованию сразу, так как сразу находится на фазе стартапа и это не несёт ему никакой выгоды. Очень надеюсь, что ваша проблема не в банальном незнании смысла слов «структурированный», «процессный», «оптимизация».
P.P.S.: Простите, что не про ресторан :(
Почему Румыния?
Например по причине налоговых льгот. Не могу найти первоисточник, но мне попадалось описание отрицательной прогрессии налога для ИТ. В качестве пруфа льгот
А ещё местные конторы осознают что платить надо конкурентно в масштабах Европы.
Касательно РФ вижу что конторы готовы ныть что специалистов нет. Только они забывают сказать что их нет на те деньги что конторы предлагают. Смотрю отчеты Моего Круга и из года в год медиана топчется где-то в районе 150-200К. Только несколько лет назад 200К рублей это 5К евро, а сегодня всего 2500. Спрашивается зачем жечь себе мозги за зарплату специалиста со средне-специальным образованием.
P.S. Другие интересные видеоматериалы с аналитикой с данной конференции и обсуждения на форуме OberonCore
Выводы каждый сделает сам, даже без рассмотрения реалий пропaганды прозападных тенденций.
Ну что, Гугл, MS и IDC, начинайте заваливать меня офферами, да побольше, побольше! /sarcasm
А если серьёзно — не понятен источник требований, больше похоже, что из шляпы вытянули по 5 хайповых вещей и назвали их «требования сегодня» и «требования через пару лет».
объясните дутрачку график
https://www.idc.com/getfile.dyn?containerId=prEUR245660119&attachmentId=47364292
на картинке с состояние 4% не релевантно/не началось
т.е. только у 4 процентов трансформации не случилось или они плохие?
Или перевод такой?
Что подразумевается под навыком "мобильность"?
IDC и Microsoft: менее 4% IT-специалистов РФ и Центральной и Восточной Европы имеют необходимые навыки и опыт