Модель систем - это прежде всего структура, которая упрощает понимание сложности. Любая сложная система может быть разобрана на простые и понятные составляющие. Модель систем — это методология, в рамках которой мы рассматриваем реальность как состоящую из взаимодействующих систем.
Привет, Хабр! Меня зовут Лера, я руководитель группы BIM-управления строительством в Sminex. Я уже делилась нашим опытом применения BIM-технологий и внедрения СИМ. В этой статье расскажу о том, как мы организовали электронную исполнительную документацию, какие сложности встретили и чего удалось достичь.
На стройке исполнительная документация — это все записи и акты о том, как выполняются работы, что проверено, что построено, какие материалы использованы. Раньше документооборот вели в бумажном виде — кипы журналов, актов, чертежей. Это было трудоёмко, долго и порой не удобно: документы легко терялись, сроки соблюдались не всегда, а контролировать весь процесс полностью было почти невозможно. Часто возникала путаница, кто что подписал, какие изменения внесены и на каком этапе находится проект.
29 ноября 2022 года вышел приказ Минстроя России № 1015, который с 1 сентября 2023 года разрешил вести исполнительную документацию в электронном формате — без обязательного дублирования на бумаге. Для нас это стало возможностью наконец вывести процесс работы с документацией из «серой зоны» и сделать его прозрачным.
Перевод ЭИД в электронный формат позволил нам:
Вычислительные системы в настоящее время присутствуют повсюду и становятся основной частью человеческой жизни. Во многих ситуациях мы полагаемся на них, чтобы помочь нам контролировать высококритичные виды деятельности, такие как медицинские процедуры, перевозка людей, аэрокосмические и оборонные системы, а также управление высокими энергиями.
Системы, критичные к безопасности, — это те, использование которых может создавать риски для человеческих жизней, поэтому требования становятся чрезвычайно важными и являются неотъемлемой частью любого процесса разработки программного и аппаратного обеспечения. Чтобы включить и учитывать аспекты безопасности в процесс разработки, более двух десятилетий назад была создана концепция функциональной безопасности вместе с некоторыми стандартами.
На старте у клиента уже были дашборды, но они не закрывали текущие задачи бизнеса. Данные находились в разных системах — 1С, Excel, Google Таблицы, XML-выгрузки и внутренняя система.
Клиент принял решение выстроить аналитику заново и выбрал Apache Superset как инструмент визуализации. Сначала собрали единый слой в PostgreSQL, настроили загрузку через Python, привели метрики к одной логике и зафиксировали правила расчётов.
После этого уже собрали дашборды под управленческие задачи клиента. Визуализация строилась так, чтобы быстро находить отклонения и принимать решения, а не просто смотреть отчёты.
В результате у клиента появилась система, где данные считаются одинаково для всех, автоматически обновляются и используются в работе без дополнительных проверок.
Продолжаем 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 выплёскивает с водой ребёнка:
Всем привет. Да мы снова про Excel и да мы уверены что более совершенного инструмента для первичной обработки информации нет ( и возможно не будет). Мы не ставим себе цель убедить вас отказаться от любимого табличного редактора, и стать адептом других дата инструментов. В этой статье обсудим всего лишь одну задачу — это что делать , когда нужно перенести прототип (или живую модель) дата приложения созданного в Excel VBA и Power Query в другую систему — это может быть как BI, так и Ms Access или другой инструмент из семейства LowCode | NoCode. А вдруг вы занимаетесь импортозамещением, то миграция на Р7 офис / Мой Офис / … наверняка стало вашей головной болью.
В 2018 году мы начали разрабатывать CRM-систему, заточенную под сеть СТО. Разработка была масштабна, а цели — амбициозны: мы стремились учесть потребности всех участников процесса. Над проектом работали аналитики, программисты, тестировщики, настройщики Битрикс, дизайнеры и др. специалисты. Кроме того, работа продолжалась и после сдачи проекта. Я сейчас не только о поддержке системы — мы продолжали непрерывно улучшать ее, добавляли новые фичи, оптимизировали процессы.
И всё же, начав «за здравие», через 5 лет, в 2022 году, мы с заказчиком подошли к финалу известной поговорки. Эта статья про то, почему так получилось и какие уроки мы извлекли из этой истории.
Меня зовут Алексей Постригайло. Моя компания специализируется на системной интеграции и имеет 20-летний опыт реализации крупных проектов. В своих статьях я рассказываю о «закулисах» наших проектов.
Роли аналитиков в IT-компаниях давно вышли за рамки простых классификаций. Если раньше можно было уверенно разделить бизнес-аналитиков, фокусирующихся на требованиях заказчика, и системных аналитиков, отвечающих за техническую реализацию, то сегодня рынок диктует универсальность. Российские вакансии на том же hh.ru полны требований, где BPMN соседствует с SQL-оконными функциями, а знание REST API - с ГОСТами. И это не прихоть рекрутеров, а реальность цифровизации, импортозамещения и дефицита кадров.
Просматривая содержание курсов для аналитиков 1С, я заметил любопытную закономерность. Везде учат рисовать схемы бизнес-процессов. Но нигде не учат помещать в них ключевого участника — Систему. Ту самую учетную программу, ради демонстрации которой, вообще-то, вся эта красота и рисуется.
Вместо этого ее функции размазывают между участниками процесса, как масло по бутерброду. В результате Система есть везде и нигде. И по схемам невозможно понять, что она реально делает и за что бизнес платит деньги.
Вторая проблема - универсальность. Курсы учат рисовать одну схему для всех сотрудников заказчика разом. Как будто топ-менеджер, руководитель среднего звена и исполнитель — это один и тот же человек. На практике у них три разных видения мира. В итоге схемы работают усредненно — а значит, посредственно.
И наконец, схемы рисуют, не сообщая, а зачем они? Для презентации руководству, для инструкции рядовому исполнителю или для чего-то еще?
В этой статье я покажу, как встроить Систему в схемы бизнес-процессов, адаптировать схемы под разные уровни аудитории и применять на практике — под конкретные задачи.
Привет! Я Артём Юрченко — DS-инженер в команде Недвижимости Авито. Наши кол-центры совершают до 30 000 звонков в день, и вручную можно проверить лишь небольшую часть из них. Расскажу, как мы начали строить систему речевой аналитики и разработали первую модель, которая автоматически находит в звонках возражения клиентов и анализирует, как операторы их отрабатывают.
Статья будет полезна DS-инженерам, аналитикам и продакт-менеджерам, которые работают над продуктами построения речевой аналитики.
Анализ проблемы и формирование гипотезы — удача является важным фактором в жизни человека. Но главный вопрос — насколько? Какие категории параметров можно выделить для декомпозиции с целью анализа? Начинаем погружение в “кроличью нору”.
При использовании современных IDE сред разработка прикладных приложений и сервисов с использованием естественного языка уже становится привычным делом. Но вот с задачей создания процессных артефактов в нотации BPMN 2.0, ИИ-агенты пока еще плохо справляются. И если в визуальном представлении эти схемы становятся уже более-менее адекватными, то вот заставить их “работать” получается далеко не с первого раза. Почему так происходит и как помочь ИИ-агентам в решении поставленных задач разбираемся по мотивам перевода материалов от Тима Цёллера.