Анализ аналитики

😡 Стравил коллег Интересная история и выводы из неё. 🤔 На одном из проектов мне нужно было написать руководство администратора, но для него я не знал некоторую информации. У меня набрался немаленький список вопросов, который я разделил на 2 группы: одни вопросы для аналитика, другие вопросы для архитектора. Так как я думал, что каждый из них 100% понимает в своей теме, то он ответит на свою часть, а вопросы для другого ему видеть необязательно, потому что он всё равно в них глубоко не разбирается, что на самом деле оказалось не так... Архитектор сказал, что на все его вопросы нам ответит только Заказчик, поэтому я обратился к РП, написал письмо Заказчику, а в копию поставил и аналитика, и архитектора. ❓ Потом мне написал аналитик и спросил, что это я за вопросы такие направил, вроде бы обсуждали другие. Как оказалось, аналитик мог ответить на вопросы, которые я отправил архитектору, но он их не видел. В итоге аналитик и архитектор пошли всё обсуждать друг с другом: какие вопросы на нас, а с какими надо идти к Заказчику. 📌 Вывод из этого всего следующий: если есть вопросы, которые ты хочешь обсудить с командой, то лучше либо пиши весь список в общий чат и тегай каждого, кто должен увидеть хотя бы один вопрос оттуда, либо иди ко всем лично, скидывая все вопросы, не разделяя их 💬 Подписывайтесь на Telegram #советы

💡 Полезные советы для аналитика Да, джун без опыта делится своим опытом и учит других 😝 Мой хороший друг и по совместительству коллега, с которым мы начали наш путь одновременно, ведёт заметки с полезными советами, которые проверил на себе. Он разрешил поделиться ими в канале. Собственно, вот сами заметки: - Если есть возможность сделать легко - надо делать легко. - Если моя работа зависит от скорости выполнения работы другого - мне нужно его пингануть. - После получения задачи надо сразу узнать, а смогу ли я сделать её сам. Если нет - надо сразу обратиться за помощью (потом будет поздно). - Никогда не обновляй прод без согласования теста заказчиком. Никогда. Никогда не надо это делать. - Пожалуйста, тестируй все перед показом. Если показ на их тесте - протестируй сначала на их тесте. ℹ️ Как вы можете заметить, некоторые формулировки отлично передают боль и тяжесть, через которые пришлось пройти автору. ⭐️ Сохраняйте пост себе. Такие посты будут постоянной рубрикой. Ещё больше в Telegram

🤖 RPA - бессмысленная технология Нашёл следующую статью на Хабре: «Мы роботизировали почти всё, но один процесс заставил нас полностью переосмыслить подход к RPA», где сотрудники Ленты поделились своим опытом внедрения RPA и их ошибками, а также у меня уже давно накопились мысли насчёт этой технологии, поэтому считаю, что нужно поделиться. 📁 Саммари статьи Коллеги роботизировали всё, до чего могли дотянуться, но в какой-то момент неправильно расценили, что процесс подходит под RPA, внедрили робота, и это привело к большому количеству ошибок. Процесс был следующий: брали данные из системы, обрабатывали их и загружали обратно в эту же систему. 💡 В итоге команда пришла к выводу, что процесс можно было оптимизировать доработкой самой системы, а неудачный опыт привёл к тому, что пользователи начали с опаской относиться к роботизации в целом. ⬅️ Эта ситуация заставила их провести ретроспективу всех RPA-проектов. В ходе анализа они выяснили, почему бизнес вообще обращался к RPA (часто из-за скорости внедрения или отсутствия альтернатив), и сформулировали чёткие критерии, когда роботизация оправдана, а когда - нет. В результате они разработали классификацию процессов на три категории: RPA как постоянное, временное или нецелесообразное решение. Для тех, кому интересны детали, рекомендую прочитать статью. 🤔 Мои мысли У меня скептическое отношение к RPA как к самостоятельной отрасли. Мне кажется, это костыль, который по стечению обстоятельств вырос в отдельное направление по оптимизации процессов. Посудите сами. Если проанализировать опыт коллег из Ленты, а также добавить к этому информацию из свода знаний по управлению бизнес-процессами (таблицу прикрепил к посту), которые друг друга дополняют, то меня не оставляет мысль, что RPA должно быть не первостепенным решением, к которому нужно идти, а оно должно быть лишь альтернативным вариантом автоматизации процесса, который на проекте должен рассматриваться в двух случаях, помимо очевидной целесообразности роботизации: 1) Процесс реально нельзя автоматизировать. К сожалению, в силу отсутствия опыта, я вообще даже близко не могу представить ни одного такого кейса, поэтому буду рад почитать в комментариях. 2) Проект по внедрению робота получится быстрее и дешевле, но точно с таким же эффектом, как и доработка системы. Вот в этот вариант я больше верю и он более правдоподобный. Причём, бизнесу такой подход точно понравится. Больше смысла в роботизации я не вижу😔 🔵 И ещё, обсуждая RPA, нельзя не затронуть новости о выходе браузеров Comet от Perplexity и Atlas от OpenAI. Эти компании реализовали возможность автоматически выполнять несложные процессы через UI-взаимодействие, написав лишь текстовый промпт, что не требует от пользователя знаний в программировании. Сейчас это интегрировано только в браузер, но ведь возможно сделать то же самое и с какой-нибудь 1С. 🔗Резюмирую: я не понимаю RPA, как нечто самостоятельное. Для меня это лишь одна из технологий в арсенале аналитика, но не более. Буду рад вашему мнению в комментариях. Подписывайтесь на Telegram

Кейс-чемпионат по Process mining от Сбера В начале учебного года поучаствовал с командой в кейс-чемпионате по Process mining от Сбера. 🤖 Process mining привлекает тем, что используется в компаниях, у которых уже есть какая-то информационная система и автоматизация процессов, хотя бывает, что даже система не помогает и процесс протекает тысячами способов и Process mining как раз-таки помогает выявить это. Обычно он подразумевает под собой использование специализированных ПО, но почему-то в случае кейс-чемпионата или по крайней мере этапа, который застали мы, доступа к какому-либо инструменту у нас не было🤔. Нам лишь прислали выгрузку логов из системы и сказали решать любыми инструментами, которые посчитаем нужными. 🔎 Мы с командой, конечно же, не пальцем деланные и, поискав в Интернете, нашли Python библиотеку для Process mining от самого Сбера: SberPM. Даже наткнулись на видео с презентацией этой библиотеки. Как только мы совершили такое открытие, то сразу же все вопросы по тому, какой инструмент использовать отпали. 💡Результаты: мы успешно прошли этап тестирования и не прошли этап решения кейса, поэтому не вышли в финал. Полученный опыт всё равно стоит того и мы совершенно не грустим🙂 Подписывайтесь на Telegram