🤖Роботизация — это особый вид автоматизации. В отличие от обычной автоматизации, которая может изменить процесс кардинально, роботизация сохраняет процесс практически таким же, каким он был в ручном исполнении, но теперь работу выполняет "робот", а не человек.

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

🚘Возьмём уже знакомый пример автомобильной коробки передач. Автоматическая коробка по устройству сильно отличается от механической и стоит дороже. А вот роботизированная коробка представляет собой механическую коробку, но с роботом, который за водителя выжимает сцепление и переключает передачи. Механическая часть остаётся прежней, а за процесс переключения отвечает программа, которую можно адаптировать под разные стили вождения без изменения самой коробки.

☎️Простой пример роботизации в бизнесе.
Допустим, ваша компания принимает заказы по телефону. Оператор задаёт клиенту до 10 вопросов по скрипту и заносит заказ в CRM-систему. Затем вы внедряете telegram-бота, который выполняет ту же работу, что и оператор: задаёт клиенту вопросы и передаёт данные в CRM. Процесс остаётся таким же, но вместо оператора заказ принимает бот. Тем самым организация существенно сокращает затраты на колл-центр.
Голосовые роботы — ещё более продвинутый вариант роботизации. Они могут распознавать речь, общаться с клиентом по скрипту, как настоящий оператор, и работать 24/7 без усталости, больничных или отпусков. Однако, такой вариант роботизации будет дороже, чем простой текстовый бот.

*🤔Что выбрать?
Выгодное решение для бизнеса должен определять только сам бизнес.*

✅IT, как служба, должна выдать бизнесу предложения на цифровизацию, автоматизацию и роботизацию в доступных вариантах с оценкой стоимости внедрения и владения.

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

А в файле вы сможете найти полную и подробную инструкцию по выбору подрядчика для разработки ПО.

Удачи вам и хороших выходных!✨

*⚡️Наш опыт:
Что происходит с качеством в IТ?🫣***

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

Первое с чем мы столкнулись, было огромное количество откликов, нам приходило более 200 откликов в день. После того, как мы провели внушительное количество интервью с кандидатами, выяснилось, что при таком большом потоке откликов, релевантных из них практически нет.
Тогда мы составили небольшое тестовое задание и приняли решение, сначала предлагать кандидатам выполнить тестовое, только потом приглашать на встречу.
Мы собрали более 130 ответов от соискателей и проанализировали их. Как результат, подавляющее большинство кандидатов не смогло дать верное определение даже понятию «качество».😳

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

Сначала кандидат нам рассказывает о том, как осуществляется проверка качества, потом рассказывает об управлении качеством, а потом отвечает, а что именно проверяется и чем именно специалист управляет. И тут начинается беда с ответами… 

Дело в том, что люди пишут нам про «тестирование документации», при этом даже не заглядывая в ISO (есть международные стандарты качества), где описаны понятия QA (обеспечение качества) и QC (контроля качества).

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

Мы увидели, что в IT есть много специалистов по проверке качества (QC), но практически нет специалистов по обеспечению качества (QA). И дело не в том, как называется должность, а в том, какими компетенциями человек обладает.

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

Фактически преобладающее большинство специалистов сейчас это - специалисты QC, которые хотят больше денег и называться более модно — QA.😿

💡Для того же, чтобы действительно стать QA, специалисту необходимо для начала изучить метод 6 сигм, который был разработан для реального производства. После изучить, что такое бережливое производство и Кайдзен. Затем прочитать ISO либо ITIL (библиотека книг, описывающих лучшие практики на тему инфраструктуры IT) в части систем управления качеством. 

После чего можно отталкиваться от сформированной базы и начинать свой осознанный путь, как инженера по обеспечению качества. 

И это только первая ступень. Далее необходимо понимать, как работают процессы управления проектами и продуктами, необходимо понимать системную архитектуру, необходимо понимать процессы управления инцидентами и проблемами, необходимо понимать, как встраивать подсистемы самодиагностики в процессы и в код (отдельно!).

А как у вас дела с инженерами по обеспечению качества на проектах/продуктах?

Когда у нас заказывают диагностику работы внутренней IT-команды, мы часто слышим вопрос:
*⁉️"Как оценить качество разработки?*"

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

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

❌Если наблюдается устойчивый тренд на рост инцидентов, при сохранении интенсивности нагрузки на систему и скорости внесения изменений в систему, значит существуют проблемы с качеством.

— Второе, на что необходимо обратить внимание — какая у вас динамика затрат на исправление ошибок в IT-продукте.

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

*ℹ️То есть у любой ошибки есть:
— Стоимость владения ошибкой в деньгах. Это затраты на падение скорости работы пользователей. Это затраты на исправление ошибочных данных в системе. Это другие издержки, которые несёт бизнес из-за того, что такая ошибка происходит.
— Стоимость исправления ошибки.* То есть сколько денег нужно потратить на IT-команду, чтобы они исправили данную конкретную ошибку.

Зная эти показатели на дистанции вы можете оценивать ситуацию и принимать необходимые решения.

*?Теперь к конкретным действиям в этой сфере:*
Запросите у команды распределение времени на задачи по реализации нового функционала и исправлению существующего. А затем проследите за динамикой временных затрат. В нормальном соотношении исправлений должно быть не более 20-25%. Если больше, то ТОЧНО необходимо разбираться. Причины могут быть в разных частях процесса - низкое качество требований, низкое качество аналитики, недостаточное участие бизнес-заказчика, своеволие разработчиков, проблемы с контролем качества, проблемы с инфраструктурой работы, низкая квалификация продуктового специалиста, недостаточная синхронизация продуктовой и технической команды и тд.

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

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

▶️У вас есть подозрение, что IT обходится вам дороже, чем в среднем по рынку? ▶️Вам кажется, что IT – это безумные траты и вам будет дешевле вообще отказаться от развития этого направления в своем бизнесе? ▶️Вы не знаете, сколько и когда стоит либо не стоит…

Надо ли держаться за старое?! Всем, привет от Ильдара! Нашел в офисе случайно свою машину начала 10ых годов ?❤️‍??
А вообще свой первый ноут IBM купил в 2005 и с тех пор только они, потом Леново ?

Минутка философии - часто так бывает что мы привыкаем к чему-то, конкретному бренду, определенным практикам и фреймворкам, потом транслируем это командам, а через какое-то время спросив условного Васю - "а почему ты так делаешь?" можно услышать "ну тут всегда так делали!"

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

А делать это всегда лучше с профессионалами, и вы знаете как нам написать! ?⚡?

PS а кто помнит свой первый ноут или вообще есть сохранившиеся раритеты - кидайте фотки, пятница ж ? у меня был ровер бук кажется в 2002/03!

#itbp #itmegastar