У нас в чате по СППР в телеграм (https://t.me/SPPR_1C) этой темой интересуются и были бы признательны, если бы вы к нам зашли и немного рассказали про опыт работы с СППР. Я писал в КРОК на почту контактов с общественностью, просил прийти в чат, рассказать, ответить на ряд вопросов, но ни ответа ни привета не получили.
А наши читатели следят за темой, они знают и помнят старую статью КРОКа нескольколетнейдавности про опыт с СППР и с проектированием архитектуры. Сравнивают с этой вашей статьёй, пытаются понять что изменилось, много ли сумел КРОК в части цифровизации проектирования продвинуться...
Здесь СППР назвали сервисом хранилищ конфигурации, а по тексту в статье там только требования фиксируются и бизнес-процессы и это всё связывается с метаданными из конф. Где ж тут аж цельный сервис хранилищ?
Пожалуйста, воспользуйтесь, своими же рекомендациями из вашего комментария!
Умоляю вас, перечитайте мой комментарий хотя бы четыре раза подряд, ведь он такой маленький и вполне посильный для понимания.
После этого посмотрите туда, почитайте там, изучите вон то и, тогда, вам может (?) откроется большая тайна, что умные люди отвечают на тот вопрос, который задали, а не на тот на который хочется ответить.
Если вы в таких делах не очень способны, то переформулирую смысл моего комментария - называть 1С:Аналитику BI-системой пока ещё слишком натянуто. Всё что вы говорите про OLAP, РИБ и куча иных умных слов перечислением которых вы явно гордитесь, можно было делать с с "Фабрикой отчетов".
На сегодня 1С:Аналитика лишь улучшенная и визуализированная СКД, заточенная под обычного юзера/менеджера - и точка. Внедрять её взамен имеющихся BI систем, пусть даже и потенциально подсанкционных, пока рискованно и затратно для бизнеса и толку и плюсов - ноль.
Вот когда научится сводить данные из разных систем собственными инструментами, тогда да, и все дела.
Большой, очень большой минус 1С:Аналитики - она не умеет работать со сводом информации из нескольких баз данных.
Т.е. работает строго с одной базой данных.
Получить данные о продажах из документа типа "Реализация товаров" из базы 1С:ERP и 1С:Бухгалтерия невозможно.
Получается 1С:Аналитика не BI-система, а визуальный конструктор отчетов из одной базы, что собственно её делает версией № 2 забытой "Фабрики отчётов" от 1С.
В WMS алгоритмы работают на основе выделенных аналитик к номенклатуре товаров и раскладка в ячейки происходит на основе заранее установленных соответствий между ячейками, аналитиками товара и правилами раскладки.
Когда вы применили алгоритм на уровне ИИ для оперативного установления этих связей ячейка-аналитики-правила, то вы аналитическую работу по связке, которую делают "до" раскладки перенесли, фактически, в момент самой раскладки.
Мало того, что алгоритм типа ИИ требует постоянной работы по его подправке за пределами этапа разработки и постоянного непрерывного обучения , что далеко не всегда под силу и квалификацию логистикам, т.е. он фактически всегда "сырой" и выдаёт энный процент ошибок, который, правда, уменьшается с течением, длительным течением времени, так ещё встают вопросы производительности расчета алгоритмов на больших массивах данных (больших складах и/или широкой номенклатуре и объёмных аналитиках).
Предложенный выше нормализатор куда лучшее решение, а вариант с анализом текста рискованный для бизнеса. Правильно заметили, что если процессы бизнеса ранее были уже отлажены, то новые попытки его улучшить будут выдавать всё меньший и меньший результат. И при этом при всё больших и больших затратах. Закон Парето во всей его красе, 20/80 и 80/20!
Вы столько потратили времени, усилий и затрат на найм соисполнителей, когда ответ на поставленный вопрос уже лет 20 как известен опытным работникам ЖКХ.
Никак дисциплина платежей от собственников не зависит от качества (SLA) оказываемых услуг, где SLA вы свели по сути к скорости выполнения заявки клиента (собственника).
У нас так построено законодательство, что клиент не может особо манипулировать "плачу-не плачу", он должен платить без звука и до 10 числа.
Большее значение может иметь качество той же воды поставляемой в дом - это фактор мгновенного возмущения. И то люди платят и не вякают, попробуй так просто оспорь и докажи качество коричневой жижи что идёт из труб. И это в ваше SLA не входит, не измеряется.
Статистика давно накоплена, что люди делятся на кластеры по платежам
1) те кто всегда платит
2) те кто никогда не платит
3) те кто платит когда и сколько может
Перемудрили вы ребята. Хотя, то что созрели до понимания, что в ЖКХ может быть реализован механизм аналогичный SLA в ИТ для управления качеством услуг - уже ваш плюс по сравнению со многими.
Прошло немного времени после написания этой статьи и пошли сбываться прогнозы и предположения:
(даю ссылку на статью с того же Хабра и цитаты из неё - статья про новые условия аккредитации ИТ-компаний)
Сайт компании становится важен
"обозначение ИТ-компанией своего места на рынке услуг через информацию в открытых источниках, в т. ч. на официальном сайте компаний;" - становится критерием аккредитации
" наличие права на ПО, включенное в реестр российского софта, и доход от реализации такого права в течение года, предшествующего году подачи заявления на аккредитацию"
И отдельно акцентирую внимание на то, что следует жестко соответствовать определениям ИТ-профессий/должностей, особенно в свете мобилизационной истории.
Картинка в хорошем качестве есть по ссылке на слове mindmap в статье. На всякий случай, приложу здесь общую картинку и отдельные картинки по веткам. Для улучшения качества картинку по ПКМ можно открыть в отдельной вкладке/окне.
Вы знаете, а ведь я с вами согласен. Я вот считаю что в стране недооценены инженеры, высококвалифицирвоанные рабочие, толковые военные и много других специальностей. Но, политику поддержки населения и работников определяю не я. Могу только руками развести.
Вы столько усилий потратили на фичу, без которой можно было бы обойтись. Она полезная, приятная, более удобная в обслуживании. Но прибавку доходности бизнесу она не даёт. А у IBS есть потенциально более выгодные точки приложения для внутренних проектов развития… Например, перестроить внутреннюю базу управления проектами так, чтобы она могла более точно рассчитывать прогнозируемые сроки исполнения проектов для заказчиков.
Вот и интересно как те кто описывал процессы их описывал и на каком инструменте фиксировал. СППР помогла бы зафиксировать и выявить слабость методологов и аналитиков на проекте и провести работу над ошибками, если конечно заказчик поганой метлой не вынес уже такую команду.
Ваш пример говорит лишь о том, что в данной компании не умеют планировать. Но процесс планирования у них есть. И изменились у них цифры — результат процесса планирования. Но ничего не говорит, что сам процесс изменился. Вобщем путаете процесс и результат процесса.
Мы о разных видах разработки говорим. Я работаю в той отрасли, где старт идёт не от идеи, а от чаще потребности реализовать давно ожидаемый функционал. И там другие темпы, расклады и требования, отсюда и подходы другие.
И где тут повышение маржи с проекта за счёт манипуляции оценкой?
Независимо от того есть ли манипуляция перед заказчиком или нету её, самому исполнителю важно для себя знать реальные затраты времени на проект и его потенциальную себестоимость.
У заказчика есть возможность ограничить манипуляции. Крупный заказчик обычно работает через тендер и может запросить оценку от нескольких исполнителей. Поэтому манипуляция исполнителя с занижением оценки ради контракта чревата работой в убыток, а манипуляция с завышением оценки чревата потерей контракта из-за лучших предложений конкурентов.
С пруфами всё сложно. Внедрение СППР идёт тяжко. Многие понимают, что инструменты типа СППР надо применять. НАДО. Но в большинстве случаев, где СППР используют её валят на разработчиков, а это неправильно (см. отдельную мою статью про это).
Использование СППР предполагает, что перед кодингом должно быть выполнено проектирование архитектуры системы, а ещё перед этим описание системы (анализ и фиксация бизнес-процессов и алгоритмов). Т.е. если ваш проект маленький и вам проще сесть и нахрапом (эджайлом) одолеть проблему («завалить врага кодом»), тогда проще обойтись без СППР и дополнительных членов команды. Если же проект крупный, создаёт или развивает систему с длительным жизненным циклом, то хватит уже многократно и однообразно повторившейся ситуации на проектах — ситуационным кодингом многочисленных «талантливых» программистских команд приводить любую систему в нереаботоспособное состояние. Путём победы тактики над стратегией (ща костылей понаставим — будет работать) очень большие деньги зарываются в песок. Денег в стране стало меньше и компании, после многократных бегов по кругу со многочисленными внедренцами, стали искать способы гарантированно продлить жизненный цикл сложных систем с меньшими затратами.
А для этого надо работать по определённой технологии. А СППР — это всего лишь инструмент для реализации такой технологии. Сказанное, повторяю, разумно для крупных проектов. В маленьких — проще кодить и кодить. В конце-концов СППР — проблема не разраба.
У нас в чате по СППР в телеграм (https://t.me/SPPR_1C) этой темой интересуются и были бы признательны, если бы вы к нам зашли и немного рассказали про опыт работы с СППР. Я писал в КРОК на почту контактов с общественностью, просил прийти в чат, рассказать, ответить на ряд вопросов, но ни ответа ни привета не получили.
А наши читатели следят за темой, они знают и помнят старую статью КРОКа нескольколетнейдавности про опыт с СППР и с проектированием архитектуры. Сравнивают с этой вашей статьёй, пытаются понять что изменилось, много ли сумел КРОК в части цифровизации проектирования продвинуться...
Здесь СППР назвали сервисом хранилищ конфигурации, а по тексту в статье там только требования фиксируются и бизнес-процессы и это всё связывается с метаданными из конф. Где ж тут аж цельный сервис хранилищ?
Вас поздравить соврамши?
"СОТНИ клиентов, которые уже внедрили 1С:Аналитику в качестве BI" !!!!!!!!!!
На сайте 1С дай бог 17 внедрений упомянуты, вот ссылка:
https://1c.ru/solutions/public/?searchModel={"itemsPerPage":25,"pageNumber":1,"orderBy":[],"archive":true,"onlyTitle":true,"fraze":true,"firstSolutionsDate":"1989-12-31T21:00:00.000Z","secondSolutionsDate":"2022-11-06T21:00:00.000Z","query":"Аналитика","findByCompanyGroup":true,"regions":[],"fresh":true,"grm":true,"nomenclatures":[3807]}
Кто ж вам после такого поверит что это BI-система.....
Пожалуйста, воспользуйтесь, своими же рекомендациями из вашего комментария!
Умоляю вас, перечитайте мой комментарий хотя бы четыре раза подряд, ведь он такой маленький и вполне посильный для понимания.
После этого посмотрите туда, почитайте там, изучите вон то и, тогда, вам может (?) откроется большая тайна, что умные люди отвечают на тот вопрос, который задали, а не на тот на который хочется ответить.
Если вы в таких делах не очень способны, то переформулирую смысл моего комментария - называть 1С:Аналитику BI-системой пока ещё слишком натянуто. Всё что вы говорите про OLAP, РИБ и куча иных умных слов перечислением которых вы явно гордитесь, можно было делать с с "Фабрикой отчетов".
На сегодня 1С:Аналитика лишь улучшенная и визуализированная СКД, заточенная под обычного юзера/менеджера - и точка. Внедрять её взамен имеющихся BI систем, пусть даже и потенциально подсанкционных, пока рискованно и затратно для бизнеса и толку и плюсов - ноль.
Вот когда научится сводить данные из разных систем собственными инструментами, тогда да, и все дела.
Большой, очень большой минус 1С:Аналитики - она не умеет работать со сводом информации из нескольких баз данных.
Т.е. работает строго с одной базой данных.
Получить данные о продажах из документа типа "Реализация товаров" из базы 1С:ERP и 1С:Бухгалтерия невозможно.
Получается 1С:Аналитика не BI-система, а визуальный конструктор отчетов из одной базы, что собственно её делает версией № 2 забытой "Фабрики отчётов" от 1С.
В WMS алгоритмы работают на основе выделенных аналитик к номенклатуре товаров и раскладка в ячейки происходит на основе заранее установленных соответствий между ячейками, аналитиками товара и правилами раскладки.
Когда вы применили алгоритм на уровне ИИ для оперативного установления этих связей ячейка-аналитики-правила, то вы аналитическую работу по связке, которую делают "до" раскладки перенесли, фактически, в момент самой раскладки.
Мало того, что алгоритм типа ИИ требует постоянной работы по его подправке за пределами этапа разработки и постоянного непрерывного обучения , что далеко не всегда под силу и квалификацию логистикам, т.е. он фактически всегда "сырой" и выдаёт энный процент ошибок, который, правда, уменьшается с течением, длительным течением времени, так ещё встают вопросы производительности расчета алгоритмов на больших массивах данных (больших складах и/или широкой номенклатуре и объёмных аналитиках).
Предложенный выше нормализатор куда лучшее решение, а вариант с анализом текста рискованный для бизнеса. Правильно заметили, что если процессы бизнеса ранее были уже отлажены, то новые попытки его улучшить будут выдавать всё меньший и меньший результат. И при этом при всё больших и больших затратах. Закон Парето во всей его красе, 20/80 и 80/20!
Вы столько потратили времени, усилий и затрат на найм соисполнителей, когда ответ на поставленный вопрос уже лет 20 как известен опытным работникам ЖКХ.
Никак дисциплина платежей от собственников не зависит от качества (SLA) оказываемых услуг, где SLA вы свели по сути к скорости выполнения заявки клиента (собственника).
У нас так построено законодательство, что клиент не может особо манипулировать "плачу-не плачу", он должен платить без звука и до 10 числа.
Большее значение может иметь качество той же воды поставляемой в дом - это фактор мгновенного возмущения. И то люди платят и не вякают, попробуй так просто оспорь и докажи качество коричневой жижи что идёт из труб. И это в ваше SLA не входит, не измеряется.
Статистика давно накоплена, что люди делятся на кластеры по платежам
1) те кто всегда платит
2) те кто никогда не платит
3) те кто платит когда и сколько может
Перемудрили вы ребята. Хотя, то что созрели до понимания, что в ЖКХ может быть реализован механизм аналогичный SLA в ИТ для управления качеством услуг - уже ваш плюс по сравнению со многими.
Прошло немного времени после написания этой статьи и пошли сбываться прогнозы и предположения:
(даю ссылку на статью с того же Хабра и цитаты из неё - статья про новые условия аккредитации ИТ-компаний)
Сайт компании становится важен
"обозначение ИТ-компанией своего места на рынке услуг через информацию в открытых источниках, в т. ч. на официальном сайте компаний;" - становится критерием аккредитации
" наличие права на ПО, включенное в реестр российского софта, и доход от реализации такого права в течение года, предшествующего году подачи заявления на аккредитацию"
И отдельно акцентирую внимание на то, что следует жестко соответствовать определениям ИТ-профессий/должностей, особенно в свете мобилизационной истории.
Кто б автору про ESB технологии рассказал, про архитектуру данных, проектирование интеграции.....
Картинка в хорошем качестве есть по ссылке на слове mindmap в статье. На всякий случай, приложу здесь общую картинку и отдельные картинки по веткам. Для улучшения качества картинку по ПКМ можно открыть в отдельной вкладке/окне.
Статья по ссылке совсем о другом.
Вы знаете, а ведь я с вами согласен. Я вот считаю что в стране недооценены инженеры, высококвалифицирвоанные рабочие, толковые военные и много других специальностей. Но, политику поддержки населения и работников определяю не я. Могу только руками развести.
Вы столько усилий потратили на фичу, без которой можно было бы обойтись. Она полезная, приятная, более удобная в обслуживании. Но прибавку доходности бизнесу она не даёт. А у IBS есть потенциально более выгодные точки приложения для внутренних проектов развития… Например, перестроить внутреннюю базу управления проектами так, чтобы она могла более точно рассчитывать прогнозируемые сроки исполнения проектов для заказчиков.
Независимо от того есть ли манипуляция перед заказчиком или нету её, самому исполнителю важно для себя знать реальные затраты времени на проект и его потенциальную себестоимость.
У заказчика есть возможность ограничить манипуляции. Крупный заказчик обычно работает через тендер и может запросить оценку от нескольких исполнителей. Поэтому манипуляция исполнителя с занижением оценки ради контракта чревата работой в убыток, а манипуляция с завышением оценки чревата потерей контракта из-за лучших предложений конкурентов.
Использование СППР предполагает, что перед кодингом должно быть выполнено проектирование архитектуры системы, а ещё перед этим описание системы (анализ и фиксация бизнес-процессов и алгоритмов). Т.е. если ваш проект маленький и вам проще сесть и нахрапом (эджайлом) одолеть проблему («завалить врага кодом»), тогда проще обойтись без СППР и дополнительных членов команды. Если же проект крупный, создаёт или развивает систему с длительным жизненным циклом, то хватит уже многократно и однообразно повторившейся ситуации на проектах — ситуационным кодингом многочисленных «талантливых» программистских команд приводить любую систему в нереаботоспособное состояние. Путём победы тактики над стратегией (ща костылей понаставим — будет работать) очень большие деньги зарываются в песок. Денег в стране стало меньше и компании, после многократных бегов по кругу со многочисленными внедренцами, стали искать способы гарантированно продлить жизненный цикл сложных систем с меньшими затратами.
А для этого надо работать по определённой технологии. А СППР — это всего лишь инструмент для реализации такой технологии. Сказанное, повторяю, разумно для крупных проектов. В маленьких — проще кодить и кодить. В конце-концов СППР — проблема не разраба.