«Паша! Я конечно не МГИМО финишед, но можешь хотя бы по‑русски, а?» — попросил Азиз когда я выпалил ему питч, заготовленый для грядущего ивента в 71 блоке на one North. Тогда я понял, что…
Потенциальный клиент для внедренца not!= специалист.
И я сделал то, что планирую сделать в этой серии статей — рассказал про интеграцию автоматизированного учёта в малом бизнесе простыми словами.
Четверть века индустрия учётных систем строила экранные формы. Журналы документов, обработки, консоли отчётов, подборы, помощники — всё это считалось главной ценностью продукта: за удобные формы платили, за неудобные ругали внедренцев. Последние полтора года я смотрю, как ИИ-агенты работают с нашей 1С напрямую, без единой открытой формы, — и вижу, что у экранного интерфейса учётных систем осталось немного времени. А следом встаёт вопрос и о самой учётной системе как посреднике между бизнесом и его данными.
Это первая статья цикла: манифест с прогнозом. Во второй будет экономика вопроса и что она сделает с b2b-компаниями, в третьей — подробный кейс, как мы к этому шли.
Кто я и почему об этом пишу Я CTO в b2b-компании: дистрибуция с внешнеэкономической деятельностью, 1С:УТ и 1С:Бухгалтерия, Битрикс24, десятки человек в бэкофисе, десятки тысяч номенклатур, около 28 тысяч контрагентов в справочнике. Мы внедряем мультиагентную систему с виртуальными сотрудниками — сейчас идёт третий этап. За предыдущие полгода на полностью ИИ-автоматизированном пайплайне разработки для 1С выполнено больше тысячи доработок и внедрений 1С + Битрикс24: архитектура учётного контура подготовлена под агентов, и мы перешли к пилотам. Первый виртуальный сотрудник — финансовый аналитик — уже отвечает руководству в чате цифрами из боевой базы.
Поэтому дальше — не футурология по мотивам твиттера, а экстраполяция того, что я вижу в проде каждый день.
Что такое учётная система, если убрать вежливость Разберём 1С (или любую ERP — SAP и Dynamics устроены так же) на слои:
В наши дни рынок корпоративного ПО переживает фундаментальную трансформацию. На мой взгляд, происходит то же самое, что мы уже наблюдали на рынке элитной недвижимости: если десять лет назад предприниматели сравнивали «квадратные метры», то сейчас большую роль играют комфорт и окружение. В этом посте поговорим о том, как меняется психология выбора B2B-решений и почему на первый план выходят «тихая роскошь» и когнитивная приватность, почему заказчиков все меньше интересуют интерфейсы, а истинной ценностью становится операционная тишина. Желающих подискутировать на эту тему приглашаю под кат.
Для разового запроса к данным 1С не всегда нужно заранее создавать отдельный отчет или обработку. Задачу можно сформулировать обычным языком: найти документы, проверить ошибки, сопоставить показатели или разобраться в устройстве конфигурации.
В статье разберем, как работает Codex для 1С — решение, которое подключает ИИ-помощника к информационным базам 1С. На примерах посмотрим, как он ищет данные, анализирует журнал регистрации, проверяет права пользователей, находит связанные документы и сравнивает показатели в нескольких базах.
Мне понадобилось разобраться, что происходит на большом проекте внедрения: почему сроки едут и куда девается ресурс. Разработку вела внешняя команда, живьём я её не вёл и контекста не имел — на руках были только следы: трекер, вики, гит, списания времени.
Начал я с самого очевидного — померить, кто из аналитиков сколько делает. Провозился неприлично долго, получил красивые графики и всё выбросил. Дальше — почему выбросил и что нашлось, когда я перестал смотреть на людей.
Сразу оговорюсь про две вещи. Первая: это не статья про оценку эффективности сотрудников, скорее наоборот — про то, почему у меня не получилось её написать.
Вторая — про сам кейс. Он тяжёлый. Спринт вдвое больше собственного лимита, треть незавершёнки без движения месяцами, задачи с семнадцатью сменами исполнителя. Нормальным этот проект не был, и типичным я его не выдаю. Полезен он ровно этим: в здоровой команде все описанные ниже эффекты тоже есть, но дают процентов пять и потому не видны. Здесь они дают триста и становятся различимы. Это стенд, а не образец, и интересен тут метод, а не кейс.
Большинство корпоративных платформ, которые сегодня работают на крупных предприятиях, проектировались 15-20 лет назад. С тех пор сменились языки программирования, подходы к разработке, требования к интеграциям и интерфейсам. Архитектура же во многих случаях осталась прежней.
Мы задумались – можно ли сохранить проверенную бизнес-логику, не переписывая накопленный за десятилетия код, и одновременно сделать платформу открытой для современных технологий?
Эту задачу мы и хотели решить при разработке «Галактики Сверхновой». Заглядывайте под кат и узнаете, как устроено это разделение: почему ядро осталось консервативным, а расширения можно писать на Python, Java и C#, и как метаданные стали основой для интеграций и ИИ.
Привет, Хабр! Меня зовут Евгений, я ведущий разработчик отдела SAP разработки, и в зависимости от настроения надеваю маски Техлида или Архитектора.
Большинству из нас рано или поздно приходится сталкиваться с ситуацией, когда есть проблема, достаточно сложная и долгоиграющая. Неважно даже, техническая она или организационная.
Главное что ее не решить с наскока, более того, даже чтобы эту самую проблему сформулировать, нужно поговорить с людьми, посидеть, подумать, описать, и... повторить раз несколько.
А еще есть одна особенность, что бы вы не решили, обязательно через некоторое время придет человек с вопросом «А почему так? А зачем?» и совсем немного подумав, скажет «Да у вас лапки не из того места растут. Я могу лучше!». Пфф.
Так как с этим приходится жить, то я решил сформулировать буквами некоторые наблюдения\выводы о подобных ситуациях. В первую очередь для себя, но может и вы что то полезное найдете.
Интересно? Читайте статью под катом.
Когда заказ, склад и оплата живут по разным правилам, сбой возникает на стыке систем — там, где нет владельца решения.
В статье — шесть шагов, которые помогают превратить разрозненные требования в управляемую архитектуру сквозного процесса.
После завершения функционального моделирования большинство проектов переходит к разработке, считая модель законченной. Именно здесь закладывается главная проблема ERP-проектов: документация постепенно устаревает и перестает отражать реальную систему. В этой статье я покажу альтернативный подход, в котором настройка, разработка и документация образуют единый непрерывный цикл.
В сегодняшнем дайджесте мы собрали популярные решения в Базе знаний Инфостарт за последние 14 дней. Сообщество 1C активно скачивает обработки, ставит лайки и комментирует эти публикации.
Если ваша работа связана с 1С, то эти статьи будут полезны для вас. Напишите в комментариях, какая из публикаций вызвала у вас интерес.
Меня зовут Ирина Гертовская. Много лет я проектирую, внедряю, развиваю и поддерживаю крупные ИТ-системы, анализировала, проектировала, разрабатывала, руководила командами аналитиков и разработчиков, руководила проектами.
Мой опыт показывает: внедрить систему иногда не проще, чем разработать. Часто учесть нужно больше, чем видится и значительно раньше самого периода внедрения. В этой статье с поделюсь таким опытом на примере небольшой доработки в эксплуатируемой ERP-системе крупной компании.
Четыре месяца работы, одиннадцать человек — и система, которая планировала хуже Excel. Технологи говорили, что их работу невозможно формализовать. История о том, где заканчивается экспертиза эксперта и что на самом деле делает руководитель проекта.
Это первая статья практической серии, продолжающей тему материала «Автоматизировать бардак нельзя навести порядок». В заглавной статье речь шла о праве ИТ остановить преждевременный переход к реализации. Теперь разберём, что делать после такой остановки: как проверить бизнес-инициативу, отделить проблему от уже выбранного решения и понять, существует ли проект в содержательном смысле.
Мы, как потребители, крайне редко задумываемся над тем, как создаются продукты, товары, которые делают нашу жизнь, быт проще, чище, интереснее, вкуснее и т.д.
На просторах интернета можно без особого труда найти видеоролики, рассказывающие о производителях различных товаров, о том, каким образом выстроены процессы производства.
Сегодня речь пойдет о процессе, без которого производство невозможно представить, но потребитель зачастую даже не задумывается об этом. Мы поговорим о процессе планирования производства, а именно, о формировании детального плана-графика, и тех задачах, которые находятся в зоне ответственности специалистов по планированию. С какой целью? Чтобы понять, какой большой объем работы сосредотачивается зачастую на одном специалисте, и какие возможности существуют, чтобы ему помочь.
Цель статьи
Цель данной статьи хотя бы в сжатом варианте рассказать о том, из каких шагов состоит построение графика производства и какой труд стоит за красивой картинкой в виде очереди ПЗ на диаграмме Ганта.
В предыдущей статье о ГОЭЛРО я писал о программе «А»: прежде чем строить новые мощности, план предусматривал восстановление и реконструкцию существовавшего энергохозяйства. Сначала вернуть основанию работоспособность — и лишь затем возводить на нём новое. Исторически эта часть плана действительно называлась программой «А»; такое описание приводит, в частности, Минэнерго России.
В автоматизации эту последовательность постоянно пытаются перепрыгнуть. Компании хотят сразу перейти к целевой архитектуре, единому информационному пространству, сквозным процессам, искусственному интеллекту и управлению на основе данных. Но нередко выясняется, что под будущей системой пока нет основания: бизнес не договорился, какой процесс строит, кто им владеет, какие данные считать достоверными и какой результат вообще должен измениться после внедрения.
За двадцать с лишним лет в ИТ я наблюдал эту ситуацию с разных сторон. Начинал программистом 1С, руководил ИТ розничной сети, был партнёром-интегратором, участвовал в крупных проектах замены зарубежных корпоративных систем российскими решениями, а затем оказался на стороне заказчика и стал принимать работу других интеграторов.
По обе стороны баррикады спор обычно формулируют одинаково: кто должен диктовать автоматизацию — бизнес или ИТ?
Я всё больше думаю, что это неправильный вопрос.
Бизнес должен иметь последнее слово в вопросах «зачем» и «что»: какую проблему решать, какого эффекта добиваться, чем пожертвовать и какие изменения считать приоритетными. ИТ отвечает за «как»: архитектуру, данные, технологические ограничения, интеграции и жизнеспособность будущего решения.
Склад может работать «в плюс» по всем видимым статьям — и при этом системно терять рентабельность. Не из-за ошибок персонала и не из-за дорогой аренды, а из-за структуры ассортимента.
Возьмём типичный пример: неликвидные позиции на складе оценены в 5 млн рублей. При обычной для рынка стоимости хранения запаса 20–30% в год, только за то, что эти позиции занимают место и держат замороженный капитал, склад теряет от 1 до 1,5 млн рублей ежегодно. Через 3–4 года такого хранения суммарные затраты превышают закупочную цену товара. Дальше держать — терять деньги наверняка, продать — терять деньги один раз.
Эта статья — о том, как увидеть эту математику в данных WMS и принять решение раньше, чем она окончательно съест маржу.
Десять человек на совещании: пятеро со стороны заказчика, пятеро со стороны подрядчика. Полтора часа обсуждают три поля в экранной форме. Не архитектуру, не интеграцию, не модель данных — три поля. Сначала долго не могут понять, что означают цифры в них. Потом понимают: одно число складывается с другим и должно давать третье. Договариваются переименовать поля и переставить их в логичном порядке. Попутно выясняется важное: корректировка данных не обязана делаться через сторно с повторным вводом, это может быть отдельный процесс.
Полтора часа на десятерых — пятнадцать человеко-часов. Само исправление занимает полчаса работы аналитика с разработчиком.
Обнаружение дефекта обошлось в тридцать раз дороже, чем его устранение. И это ещё удачный случай: дефект хотя бы всплыл.
Ключевое здесь не в том, что кто-то поленился. Ключевое в том, что до совещания в систему не заглянул никто. Ни один пользователь не открыл форму и не посмотрел на неё с интересом. Если бы посмотрел — те же три поля стоили бы тридцать минут переписки.
Проект к этому моменту шёл третий год.
Не только лишь Mistral
Что первое приходит вам в голову, когда вы слышите фразу «европейские LLM»? Опытный читатель наверняка вспомнит про французскую Mistral и... в целом, на этом всё.
Около девяти из десяти крупных строительных проектов в мире завершаются с превышением бюджета. Причины принято искать в технической сложности, погоде, откатах и действиях подрядчиков. Всё это важные факторы, но они не объясняют, почему перерасходы повторяются из проекта в проект. Объяснение проще: заказчик и исполнитель изначально владеют разным объёмом информации. Реальную стоимость и сроки хорошо понимает лишь та сторона, что строит, и раскрывать эти данные ей, как правило, невыгодно. Непрозрачность здесь - не болезнь отрасли, а её бизнес-модель. При этом любое информационное преимущество работает лишь до тех пор, пока сведения остаются закрытыми.
История других отраслей показывает, что происходит дальше. До Uber цену поездки знал только таксист, и пассажир зависел от его решения. Как только маршрут и стоимость стали видны на экране, преимущество водителя исчезло. Booking сделал прозрачными цены на отели, маркетплейсы - на товары, Google Maps - на логистику. Строительство пока остаётся одним из немногих крупных рынков, устроенных «как такси до Uber»: полной картиной по стоимости и срокам владеет только одна сторона, а вторая оплачивает эту асимметрию перерасходами.
Дальше в статье - нидерландский строительный картель с двойной бухгалтерией и 1300 оштрафованных фирм; алгоритмы, которые находят следы сговора прямо в цифрах торгов; два миллиарда долларов SoftBank, сгоревшие в «кнопке Uber для стройки»; и рынок жилья, который свою уберизацию уже прошёл. Через историю и паттерны видно, какими будут инструменты уберизации строительной отрасли в следующие десятилетия.
Привет, Хабр! Меня зовут Максим Вишняков, я ведущий разработчик в Axenix. За время работы я накопил обширные знания в части оптимизации, развития и поддержки различных решений на платформе 1С:Предприятие. В этой статье хотел бы рассказать об опыте оптимизации работы ERP-системы для лидера алкогольного рынка, который отгружает продукцию в режиме 24/7 и осуществляет огромный объем операций.
