Продолжаем data mining путешествие в погоне за удачей. Сегодня разберем как устроены жизненные факторы. Эти категория достаточно скучна, но статистически хорошо подтверждена. И интуитивно понятна большинству людей. Но влияние ее очень сильное. Поэтому рассмотрим ее подробнее.
Привет, Хабр! Не мне вам рассказывать, что мы живем в эпоху цифровизации производств — вы наверняка читали статьи о «тяжёлой цифре». Но история цифровизации, которой я хочу поделиться, еще сложнее — потому что это история из мира фармпроизводства.
Я Иван Колесников, директор по цифровой трансформации в Группе компаний «Промомед». Наш фармацевтический холдинг растёт стремительно — в 6 раз быстрее рынка. Больше товара, складов, сотрудников, дистрибьюторов... И это на фоне и без того сложной цепочки планирования, производства и контроля качества. Чтобы все работало чётко и слаженно, нам понадобилась хорошая система ERP. Вот было бы здорово, если бы существовало такое решение — готовое, российское и чтоб умело всё, что нам нужно.
С готовым и российским оказалось проще — есть 1С:ERP. А вот до «умело все, что нам нужно» пришлось ещё существенно доработать и объединить с другими платформенными решениями. Получился «спрут», запустивший «щупальца» не только во внутренние системы холдинга, но и во внешние источники данных — а без этого в Фарме никак.
Расскажем, как наша команда и партнеры создавали этого «спрута», что пришлось расширить в стандартной 1С:ERP, чтобы решение учитывало нашу специфику, что оно в итоге умеет и как мы планируем его улучшать дальше.
Всем привет! Я Ольга Матушевич, преподаватель курса «Нейросети для бизнеса», а в прошлом наставница на курсе «Аналитик данных». В этой статье я постараюсь дать рецепт хорошего промпта на все случаи жизни. Если вы пользуетесь популярными нейросетями вроде ChatGPT или Gemini, но при этом получаете стабильно разочаровывающие результаты — читайте дальше.
Привет, Хабр!
Я как всегда с аналитикой отчетов из мира IT – в этот раз в мои руки попал большой отчет MWS о перспективах IT-рынка. Как и ожидалось цифры растут от года к году:
в 2021 году рынок оценивался в 2,06 трлн рублей, в 2025-м – уже в 3,86 трлн, а в 2026 году, по прогнозу, должен дойти до красивых 4,44 трлн. Тенденция выглядит как бурный технологический рост, с преодолением ковидного и прочих кризисов. Однако ситуация (как всегда) немного сложнее – сейчас в целом меняется внутренняя природа рынка.
Возьмём рынок кэптивных IT-компаний (внутренних технологических структур, которые крупный бизнес создаёт под свои нужды, а не для открытого рынка) – его можно считать параллельной экономикой: в 2025 году сегмент оценивается в 1,964 трлн рублей против 628 млрд рублей в 2021.
Долгое время крупные корпорации для рынка были прежде всего заказчиками: они покупали софт, железо, интеграции, консалтинг, а кэптивный рынок жил тем, что продавал им технологии. Сейчас граница начала немного размываться: на 2025 год уже 21% выручки кэптивов стала чисто коммерческой. Иными словами, внутренние IT-центры крупнейших компаний начинают выходить наружу, брать внешний рынок и постепенно превращаться в самостоятельных игроков. И это только одна тенденция
Сегодня я хочу поговорить не про рост IT-рынка (цифры в отчете видны невооруженным взглядом) а поставить вопрос из кого вообще состоит этот рынок, поскольку мы видим новый слой – внутренние технологические фабрики банков, ритейлеров, нефтегазовых компаний, телекомов и логистических гигантов. И если этот сдвиг продолжится, Россия получит рынок другой природы, где крупнейшие заказчики сами станут производителями новых технологий.
Только недавно Reuters раскрыли личность Бэнкси, как парни из New York Times спешат сорвать покровы с легендарного создателя биткоина (вот здесь архивная версия лонгрида без пэйволла). Кратко пересказываю здесь основные аргументы расследования.
Привет, Хабр. Меня зовут Марат Мустафин, я архитектор стрима 1С в МТС. В крупных компаниях сегодня модно измерять технологическую зрелость команд по единым чек-листам и общим методологиям. Из-за этого команды 1С каждый раз оказываются в проигрышной позиции.
Реальные достижения — отказоустойчивые кластеры, еженедельные релизы через CI/CD, мониторинг бизнес-логики в Grafana — растворяются в общих формулировках вроде «У вас есть автоматизация тестирования?». А специфичные для платформы практики, такие как работа с хранилищем через gitsync, нагрузочное тестирование типовых операций, управление техническим долгом в конфигурации, просто не попадают в поле зрения.
В итоге сильная 1С-команда может получить средний балл, потому что ее инструменты незнакомы валидаторам оценки, а слабая — завышенный, потому что формально использует Jira. Под катом расскажу, почему общие модели зрелости плохо работают для 1С и какую модель оценки я предлагаю сообществу — с конкретными капабилити, практиками и открытыми инструментами.
С этой проблемой столкнулась и команда 1С в МТС. Корпоративная модель зрелости у нас есть, мы по ней проходим оценку и никуда от нее не деваемся. Но каждый раз при прохождении я видел одно и то же: реальные инженерные достижения команды не укладываются в общие формулировки, а специфичные для платформы практики просто выпадают из оценки.
Это натолкнуло меня на мысль: сообществу 1С нужен собственный инструмент — не замена корпоративным стандартам, а дополнение, которое говорит на языке платформы. Так появилась двухуровневая модель оценки для команд 1С, в которой важен не факт наличия процессов, а то, как именно они устроены и насколько осмысленно применяются. Она позволяет оценивать не только соответствие чек-листу, но и глубину инженерной культуры.
Хабровчане, приветствую! Меня зовут Михаил Казанцев, я ведущий системный аналитик в мобильном приложении Вайлдберриз. Работал и писал требования как в стартапах с монолитами, так и в банковском секторе с сотнями сервисов в одном контуре, рассказать есть что.
Я хочу рассказать о своём восприятии основной идеи книги Мартина Клепмана — Высоконагруженные приложения через призму своего ультрамарафонского опыта тренировок и соревнований и практики проведения чайных церемоний. Книга технически сложная, поэтому
Продолжаем data mining путешествие в погоне за удачей. Сегодня разберем как устроены богатство, социальные связи и образование. Эти категории достаточно сложны, но статистически хорошо подтверждены. Откалибровать их было довольно просто.
Проблема Zero Shot не в том, что он не умеет читать закон. Проблема в том, что закон нельзя честно превратить в требования одним действием. Всё, что скрыто между нормой и системой, модель слишком легко маскирует красивым ответом.
Разберём подробнее, как ZS выплёскивает с водой ребёнка:
В 2018 году мы начали разрабатывать CRM-систему, заточенную под сеть СТО. Разработка была масштабна, а цели — амбициозны: мы стремились учесть потребности всех участников процесса. Над проектом работали аналитики, программисты, тестировщики, настройщики Битрикс, дизайнеры и др. специалисты. Кроме того, работа продолжалась и после сдачи проекта. Я сейчас не только о поддержке системы — мы продолжали непрерывно улучшать ее, добавляли новые фичи, оптимизировали процессы.
И всё же, начав «за здравие», через 5 лет, в 2022 году, мы с заказчиком подошли к финалу известной поговорки. Эта статья про то, почему так получилось и какие уроки мы извлекли из этой истории.
Меня зовут Алексей Постригайло. Моя компания специализируется на системной интеграции и имеет 20-летний опыт реализации крупных проектов. В своих статьях я рассказываю о «закулисах» наших проектов.
Роли аналитиков в IT-компаниях давно вышли за рамки простых классификаций. Если раньше можно было уверенно разделить бизнес-аналитиков, фокусирующихся на требованиях заказчика, и системных аналитиков, отвечающих за техническую реализацию, то сегодня рынок диктует универсальность. Российские вакансии на том же hh.ru полны требований, где BPMN соседствует с SQL-оконными функциями, а знание REST API - с ГОСТами. И это не прихоть рекрутеров, а реальность цифровизации, импортозамещения и дефицита кадров.
Просматривая содержание курсов для аналитиков 1С, я заметил любопытную закономерность. Везде учат рисовать схемы бизнес-процессов. Но нигде не учат помещать в них ключевого участника — Систему. Ту самую учетную программу, ради демонстрации которой, вообще-то, вся эта красота и рисуется.
Вместо этого ее функции размазывают между участниками процесса, как масло по бутерброду. В результате Система есть везде и нигде. И по схемам невозможно понять, что она реально делает и за что бизнес платит деньги.
Вторая проблема - универсальность. Курсы учат рисовать одну схему для всех сотрудников заказчика разом. Как будто топ-менеджер, руководитель среднего звена и исполнитель — это один и тот же человек. На практике у них три разных видения мира. В итоге схемы работают усредненно — а значит, посредственно.
И наконец, схемы рисуют, не сообщая, а зачем они? Для презентации руководству, для инструкции рядовому исполнителю или для чего-то еще?
В этой статье я покажу, как встроить Систему в схемы бизнес-процессов, адаптировать схемы под разные уровни аудитории и применять на практике — под конкретные задачи.
Привет! Я Артём Юрченко — DS-инженер в команде Недвижимости Авито. Наши кол-центры совершают до 30 000 звонков в день, и вручную можно проверить лишь небольшую часть из них. Расскажу, как мы начали строить систему речевой аналитики и разработали первую модель, которая автоматически находит в звонках возражения клиентов и анализирует, как операторы их отрабатывают.
Статья будет полезна DS-инженерам, аналитикам и продакт-менеджерам, которые работают над продуктами построения речевой аналитики.
Анализ проблемы и формирование гипотезы — удача является важным фактором в жизни человека. Но главный вопрос — насколько? Какие категории параметров можно выделить для декомпозиции с целью анализа? Начинаем погружение в “кроличью нору”.
При использовании современных IDE сред разработка прикладных приложений и сервисов с использованием естественного языка уже становится привычным делом. Но вот с задачей создания процессных артефактов в нотации BPMN 2.0, ИИ-агенты пока еще плохо справляются. И если в визуальном представлении эти схемы становятся уже более-менее адекватными, то вот заставить их “работать” получается далеко не с первого раза. Почему так происходит и как помочь ИИ-агентам в решении поставленных задач разбираемся по мотивам перевода материалов от Тима Цёллера.
Самые интересные новости финансов и технологий в России и мире за неделю: лимит на зарубежный инет-трафик в России, банковская инфраструктура РФ поломалась на день, IPO SpaceX целит уже на $2 трлн, OpenAI купили подкаст для псиопов, а у Claude Code утек исходный код.
В Ташкенте курсируют около 1 800 активных автобусов на 170 маршрутах. Их GPS-координаты поступают каждые 10 секунд. В сутки это составляет порядка 15 миллионов координатных пингов. Но объём – не самая сложная часть.
Настоящая проблема в том, что отдельный GPS-пинг сам по себе ничего не значит. Координата автобуса на заданной широте/долготе не отвечает на вопросы:
Начну с контекста. Я играю в EA FC (ранее FIFA) в режиме Clubs (11×11), где каждым виртуальным игроком управляет человек. Сам по себе режим интересный, но мне, как человеку, который любит цифры и аналитику, довольно быстро стало не хватать доступной статистики.
Я пришёл в лигу, у которой уже был свой сайт (я в этой статье опущу тему о том, что я администрировал проект порядка 3 лет). Там статистику собирали вручную: люди пересматривали записи матчей и заносили базовые показатели — голы, ассисты, перехваты, отборы и так далее. На основе этих данных считались различные рейтинги: лучшие игроки, бомбардиры, разрушители и прочее.
Выглядело это примерно так: набор таблиц, где действия сгруппированы по категориям и амплуа.
Меня зовут Иван Васильев, я ведущий аналитик в Ви.Tech, IT-дочке ВсеИнструменты.ру. Хочу показать, как из на первый взгляд простой формулы KPI выросла инженерная задача: нам нужно было не просто посчитать интегральный показатель эффективности поставщика, а объяснить, какая именно закупка его ухудшила и почему. В статье разберу, почему для агрегированных метрик не работает наивный подход, как мы пришли к remove-one analysis и где пришлось отдельно фиксировать логику расчета, чтобы результат вообще можно было интерпретировать.
В одной из систем, над которой я работаю, мы рассчитываем интегральный показатель эффективности поставщика. Сначала задача казалась очень простой: несколько метрик, несколько весов, обычная агрегированная формула. Но однажды бизнес задал вопрос:
| Почему показатель поставщика снизился?
Ответить на него можно было бы общими словами. Но затем появился уточняющий вопрос:
| А какая именно закупка ухудшила показатель?
И в этот момент простая аналитическая задача внезапно превратилась в интересную инженерную проблему: с агрегированными метриками, нелинейными функциями и неожиданными эффектами, которые больше похожи на задачи из дискретной математики, чем на обычный backend.
Представьте: вы подходите к коллеге и спрашиваете: «Сколько у нас продаж в этом квартале?» Звучит просто. Но за кулисами начинается ад. О каком квартале речь — календарном или финансовом? А «продажи» — это отгруженные товары, оплаченные заказы или подписанные договоры?
Без семантического слоя ИИ работает напрямую с исходными данными, где названия колонок часто неоднозначны (сумма, количество, дата). Это приводит к тому, что ИИ не может корректно интерпретировать запрос и выдаёт ошибку или бессмысленный результат. Семантический слой выступает как «переводчик»: он определяет, что означает каждая колонка, как связаны таблицы и какие метрики считаются главными. Благодаря этому ИИ получает чёткие инструкции и отвечает на вопросы пользователей точно, а не наугад.