All streams
Search
Write a publication
Pull to refresh
0
0

User

Send message

Ваше решение проблемы выглядит так:

1) Провели ревизию дублей задач. Это сразу уменьшило очередь на 50% почти.

2) Провели организационные меры - добавили статусы задач, переносящие часть задач на инициаторов задачи

2.1) Ввели статус типа "на приёмке у инициатора"

2.2) Ввели статус "на согласовании у инициатора"

что ещё больше сократило очередь (точнее перекинуло часть очереди с вашего отдела а инициаторов)

3) Ограничили работу 4-мя задачами, остальные в мусор-неважные-делаемпостолькупосколькуможем

Подозреваю, что такие мусорные задачи убедили руководство вынести из KPI вашего отдела (иначе смысла бы в этом решении не было).

Гениально! Но банально. Годик стажа так можно прожить пока до всех дойдёт.

Все решения организационного вида. Не ИТшные.

Технологических решений и причин, как видно, не было выявлено:

  • причины такого большого потока задач от пользователей (некачественный код и архитектура, например)

  • задачи пользователей не проходят фильтрацию/согласование у руководителей пользователей или сотрудников тех же отделов, у которых более долгий срок жизни в компании

  • неправильно выстроена оргструктура техподдержки - вашему отделу не подчиняются службы, без которых решение задач не возможно или им не установлен регламент и KPI на взаимодействие с вашей службой

  • не установлен принцип поддержки отсекающий задачи не соответствующие KPI бизнеса. Не каждая хотелка пользователей должна реализовываться.

  • Не введён принцип техподдержки - задач должно быть не больше, чем ресурсов на их решение

  • (есть подозрение) нет типологии задач и типового времени на их решение.

О, смотрю карму минуснули за статью. Хабр так жесток бывает....

Что ж, убрал тег "Схемотехника"

У нас в чате по СППР в телеграм (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 в ИТ для управления качеством услуг - уже ваш плюс по сравнению со многими.

Прошло немного времени после написания этой статьи и пошли сбываться прогнозы и предположения:

(даю ссылку на статью с того же Хабра и цитаты из неё - статья про новые условия аккредитации ИТ-компаний)

  1. Сайт компании становится важен

    "обозначение ИТ-компанией своего места на рынке услуг через информацию в открытых источниках, в т. ч. на официальном сайте компаний;" - становится критерием аккредитации

  2. " наличие права на ПО, включенное в реестр российского софта, и доход от реализации такого права в течение года, предшествующего году подачи заявления на аккредитацию"

И отдельно акцентирую внимание на то, что следует жестко соответствовать определениям ИТ-профессий/должностей, особенно в свете мобилизационной истории.

Кто б автору про ESB технологии рассказал, про архитектуру данных, проектирование интеграции.....

Картинка в хорошем качестве есть по ссылке на слове mindmap в статье. На всякий случай, приложу здесь общую картинку и отдельные картинки по веткам. Для улучшения качества картинку по ПКМ можно открыть в отдельной вкладке/окне.

Статья по ссылке совсем о другом.

Вы знаете, а ведь я с вами согласен. Я вот считаю что в стране недооценены инженеры, высококвалифицирвоанные рабочие, толковые военные и много других специальностей. Но, политику поддержки населения и работников определяю не я. Могу только руками развести.

Вы столько усилий потратили на фичу, без которой можно было бы обойтись. Она полезная, приятная, более удобная в обслуживании. Но прибавку доходности бизнесу она не даёт. А у IBS есть потенциально более выгодные точки приложения для внутренних проектов развития… Например, перестроить внутреннюю базу управления проектами так, чтобы она могла более точно рассчитывать прогнозируемые сроки исполнения проектов для заказчиков.

Вот и интересно как те кто описывал процессы их описывал и на каком инструменте фиксировал. СППР помогла бы зафиксировать и выявить слабость методологов и аналитиков на проекте и провести работу над ошибками, если конечно заказчик поганой метлой не вынес уже такую команду.
И вы утверждаете, что все эти процессы автоматизировались без всякого описания, а сразу в код?
Ваш пример говорит лишь о том, что в данной компании не умеют планировать. Но процесс планирования у них есть. И изменились у них цифры — результат процесса планирования. Но ничего не говорит, что сам процесс изменился. Вобщем путаете процесс и результат процесса.

Information

Rating
Does not participate
Registered
Activity

Specialization

Project Director, Software Architect
Lead
People management
Organization of business processes
Strategic planning
Development of tech specifications
Development management
Building a team
Project planning
Project management
Business process management