В коммерческом Office365 уже есть несколько месяцев. В Teams, Powerpoint, Word, Notes, Excel (по убыванию полезности). Только это дорого - 30 USD/month
Надо сказать, что тут даже не совсем "валидация данных", а сначала "валидация структуры", потом только - данных. Если говорить про валидацию "структурно чистых" данных - возможно, мы бы смотрели на какие-то другие фреймворки, как предлагал комментатор выше.
Честно говоря, мы не использовали фреймворки по качеству данных. Более того в нашей постановке задачи до работы таких фреймворков мог не дойти ход, если пользователь подсунет файл, "покореженный креативом", в котором колонки и листы переименованы "потому, что так удобнее".
Мда, все так... Надо копать глубже. Возможно найду как запустит внешний процесс и отдать управление обратно в event_loop. Беглый поиск результатов пока не дал. Если вдруг есть идеи как это сделать - поделитесь.
По поводу первого вопроса "зачем". Одной из причин можеть быть задача "обяснимости/интерпретируемости результатов". Без этого модели часто не могут применяться в некоторых областях - типа крдитного скоринга.
Понимание того, какие высокоуровневые признаки модель выявляет, может помочь интерпретировать финальный результат.
что практически вкладывается в понятие "слаженности"?
как учитывается период отсутствия взаимной работы между сотрудниками?
как методика показала себя за годы ковидной удаленной работы, когда сидеть в одном офисе не было возможности? Были ли корректировки методики?
как конкретно остлеживается "работа сотрудников над одним проектом" - просто по примерам они могут "скакать" между проектами почти ежедневно. Кто, где и как ведет эту информацию?
Кстати, "повышение уровня профессионального мастерства" как раз указывается как один ис способов борьбы с вызгоранием. Кто учится новому - реже выгорает.
По поводу эмоциональных стрессов, приводящий к выгоранию, слышал интересное утверждение, что основныи источником их являются "неразрешенные профессиональные конфликты"... Вот об этом стоит задуматься (и руководителю, и команде) и сосредоточится на выявлении и устранении таких факторов.
Конечная цель, вообще-то, чтобы все было сделано. Но да - напоминать помагает лучше всего, хотя и имеет неприятный побочный эффект "привыкания". Люди начинают слишком полагаться на напоминалку, и в худшем случае ничего не делают пока напоминалка не прийдет. А если она вдруг сломается, то, скорее всего, процесс остановится.
По поводу загрузки.
У нас в среднем порядка 900-1200 инцидентов в месяц, среднее время закрытия - около 4 дней (это инциденты не класса "компьютер не включается" - они связаны с сбоями функционирования нагруженной системы). Они в основном обрабатываются внешней подрядной организацией. Среднее количество открытых "тяжелых" тикетов (ченджи, проекты, деманды) - 80-90.
Среднее количество открытых тикетов разных типов на одном штатном сотруднике - около 8.
По аналитическим задачам - Ченджи и Деманды содержание и качество анализа контролируется тимлидом перед подписанием. Таких задач не много.
По обновлениям статуса инцидентов и проблем - да, иногда встречаются не содержательные ответы типа "подрядчики все еще работают и ничего не ответили". Но, к сожалению, очень часто так оно и есть. Хотя бы статистика накапливается.
Была идея, просматривать содержание комментариев в инцидентах, и проверять с помощью ML NLP модели - классифицировать на "полезный" / "отписка". Но до этого ход еще не дошел.
Задачи и их метрики Не все, но ключевые метрики для основных типов задач - в списке
Инциденты (время закрытия не долно превышать T1 дней, обновления статуса должны происходить не реже раз в T2 дней)
Проблемы (обновления статуса должны происходить не реже раз в T3 дней, источних проблемы должен быть найдет за не более чем T4 дней)
Чендж реквесты (запуск в рабоу, включая полный анализ, должно завершаться не более чем за T5 дней, завершение должно быть не позже утвержденной даты)
Деманды (полный анализ должен занимать не более T6 дней)
Хорошо, что подход в принципе может помочь контролировать любой процесс, отраженный в системе - была бы возможность сказать "чего не должно быть" и "кто за это отвечает". Мы используем ServiceNow и фактически там - вся IT жизнь.
Как проходит ежедневны контроль
Автоматически. Есть пакетный процесс. Он обегает контрольные отчеты, и для каждой строки отправляет напоминалку ответственному - какие "косяки" найдены. Письма персональные, с прямыми сылками на тикеты, требующие внимания. Также процесс публикует сводную таблицу косяков в каналы MS Teams.
Другой пакетный процесс запускается еженедельно, в оговоренный момент - если этот процесс находит "косяки" - то это уже фиксируется как "штрафные очки".
Сложности внутри команды
Были проблемы с "принятием" факта что теперь операционка очень серьезно контроллируется. Сопровождалась стандартными этапами - отрицание, гнев, торг, принятие.
В некоторых случаях происходило и происходит до сих пор уклонение, выражающееся в двух формах:
минимизация контроллируемой операционной нагрузи. Это либо переброс на внешних подрядчиков, на которых контроль не распространяется, либо на других коллег. Это плохое проявление и это задача руководителя контроллировать нагрузку. С другой стороны - контроль начал распространятся и на продрядчиков.
вывод работа за пределы стандартных контролей: был инцидент - стала проблема, был стандартный чендж - стал рутинный, или вообще сервис. С ченджами пример позитивный, поскольку на самом деле приводит к улучшению процесса, его формализации и ускорению. С проблемами - не очень. Но поскльку это изместно - оно под контролем.
Объяснения руководству
Изначально метрики распространяются top-down. Как я написал в комментарии ниже - они сформированы в результате получения откликов от внутренних заказчиков и таким образом отражают (в упрощенном виде, конечно) их ожидания.
ИТ руководство само регулярно, но гораздо реже, проводит контроль этих показателей. Так что объяснять показатели - не нужно.
Перевод показателей в измеримые элементы персональных годовых планов еще не распространены в дрыгих отделах - только в наших группах. Но поскольку результаты есть и они очевидны (наша группа не фигурирует или находится глубоко в нижней части в "штрафных" отчетах руководства - у нас все хорошо) то, возможно, практика распространится на другие отделы.
Однако тут нужна воля на уровне отдела. Наши непосредственные бизнес заказчики очень требовательны, и процессы в периметре нашей команды бизнес-критические. Поэтому нам нужно было приводить дела в порядок самим. В других командах возможно ситуация спокойнее.
Оставляя в стороне ваше частное оценочное мнение, расскажу, почему так происходит.
Есть определенные ожидания бизнеся от ИТ. В частности - "делайте быстро", "делайте к договоренному сроку", "информируйте, как идет работа", итд.
Такие ожидания трансформируются в формальные метрики поверх тикетинг-системы, и контроллируются на высоком уровне (С, С-1). Очевидно, исполнение этих метрик, вменяется в обязанности каждому линейному руководителю ИТ подразделения.
Теперь руководитель подразделения уже должен обеспечить чтобы каждый в его подразделении понимал и следовал ожиданиям, выраженным через метрики. Да, действительно люди начинают "чинить метрики" - это неизбежно. Но знаете, поскольку метрики отражают запрос клиента - бизнес доволен что мы "успеваем в срок", "своевременно и регулярно информируем" итд.
Можно ли обойтись без метрик вообще сохраняя качество клиентского сервиса? Теоретически - да. Просто надо набрать блестяще умных, мотивированных, лично эффективных, при этом все еще достаточно скромных людей которым не считают зазорным не только "творить великое", но еще и делать это в срок, и сопровождать это качественной коммуникацией в сторону клиента. Таких людей нужно "всего" порядка тысячи по всему миру.
После этого можно и всех "эффективных менеджеров" поувольнять.
В этом обсуждении мы здорово сместились с темы организации и оценки операционной деятельности отдела ИТ в сторону обеспечения производственного качества.
Однако, производственное качество, а точнее его контроль (не обеспечение и не улучшение) и представление результатов контроля упоминалось здесь только в качестве драйвера идеи. Ровно с той же точки зрения упомянут был и поход "функций потерь" из области машинного обучение, который, кстати, не вызвал обсуждения. Все это для того чтобы показать возможные подходы к переходу от "измеряемых но сложно/по-разному интепретируемых" понятий к абстракциям.
TQM прекрасен как набор мер именно повышения качества. Однако нельзя улучшить то, что не меряешь. А за "измрение" в качестве отвечает именно "контроль".
Можно, пожалуйста, подробнее? А то пока комментарий напоминет иллюстрацию к Бритве Хитченса из вот этой недавней статьи: https://habr.com/ru/post/710590/
Идея интегрального представления качества через "штрафные баллы" и "финальную оценку" - это подход контроля качества (Quality Control), а не обеспечения качества (Quality Assurance). Такой подход применяется в многопрофильных независимых лабораториях.
На самом деле, действительно, "настроение" - это показатель, у которого должна быть "сезонность": недельный (выходные - работа), месячные, готовые (день рождения, Новый год, лето-зима). Понятно, что данные за год не позволяют смотреть на годовую сезонность - но недельную и месячную наверное надо учитывать.
Я конечно не знаю полной постановки задачи, но если:
нужно только искать записи по уникальнму ключевому значению, и очень быстро
список помещается в оперативную память
не важно как хранить (поскольку автор несколько раз преобразовывал формат хранения: csv -> сжатый csv с частью колонок, parquet, база SQLight)
то, наверное, можно все записи преобразовать в что-то очень компактное, типа стандартного словаря, индексированного значением штрихода, и сохранять/загружать его из pickle внутри GZip файла.
Компактно на диске, быстрая десериализация, моментальный поиск, минимальный перерасход памяти.
В коммерческом Office365 уже есть несколько месяцев. В Teams, Powerpoint, Word, Notes, Excel (по убыванию полезности). Только это дорого - 30 USD/month
Да, нашлось решение - получилось даже проще, чем изначально. Статью дополнил, репо обновил. Спасибо за комментарий!
Надо сказать, что тут даже не совсем "валидация данных", а сначала "валидация структуры", потом только - данных. Если говорить про валидацию "структурно чистых" данных - возможно, мы бы смотрели на какие-то другие фреймворки, как предлагал комментатор выше.
Честно говоря, мы не использовали фреймворки по качеству данных.
Более того в нашей постановке задачи до работы таких фреймворков мог не дойти ход, если пользователь подсунет файл, "покореженный креативом", в котором колонки и листы переименованы "потому, что так удобнее".
Мда, все так... Надо копать глубже. Возможно найду как запустит внешний процесс и отдать управление обратно в event_loop. Беглый поиск результатов пока не дал.
Если вдруг есть идеи как это сделать - поделитесь.
По поводу первого вопроса "зачем". Одной из причин можеть быть задача "обяснимости/интерпретируемости результатов". Без этого модели часто не могут применяться в некоторых областях - типа крдитного скоринга.
Понимание того, какие высокоуровневые признаки модель выявляет, может помочь интерпретировать финальный результат.
А какое RPA решение/пакет использовался? Расскажите подробнее, пожалуйста.
Есть несколько вопросов по методике:
что практически вкладывается в понятие "слаженности"?
как учитывается период отсутствия взаимной работы между сотрудниками?
как методика показала себя за годы ковидной удаленной работы, когда сидеть в одном офисе не было возможности? Были ли корректировки методики?
как конкретно остлеживается "работа сотрудников над одним проектом" - просто по примерам они могут "скакать" между проектами почти ежедневно. Кто, где и как ведет эту информацию?
Интересная статья на сайте Роспортебназдора про выгорание и профилактику: https://39.rospotrebnadzor.ru/content/emocionalnoe-vygoranie-i-ego-profilaktika. Там есть хорошие рекомендации по контролю стресса и предупреждению выгорания.
Кстати, "повышение уровня профессионального мастерства" как раз указывается как один ис способов борьбы с вызгоранием. Кто учится новому - реже выгорает.
По поводу эмоциональных стрессов, приводящий к выгоранию, слышал интересное утверждение, что основныи источником их являются "неразрешенные профессиональные конфликты"... Вот об этом стоит задуматься (и руководителю, и команде) и сосредоточится на выявлении и устранении таких факторов.
Да уж. Именно из разряда "теоретически возможно, но практически неосуществимо"
Конечная цель, вообще-то, чтобы все было сделано. Но да - напоминать помагает лучше всего, хотя и имеет неприятный побочный эффект "привыкания". Люди начинают слишком полагаться на напоминалку, и в худшем случае ничего не делают пока напоминалка не прийдет. А если она вдруг сломается, то, скорее всего, процесс остановится.
По поводу загрузки.
У нас в среднем порядка 900-1200 инцидентов в месяц, среднее время закрытия - около 4 дней (это инциденты не класса "компьютер не включается" - они связаны с сбоями функционирования нагруженной системы). Они в основном обрабатываются внешней подрядной организацией.
Среднее количество открытых "тяжелых" тикетов (ченджи, проекты, деманды) - 80-90.
Среднее количество открытых тикетов разных типов на одном штатном сотруднике - около 8.
По аналитическим задачам - Ченджи и Деманды содержание и качество анализа контролируется тимлидом перед подписанием. Таких задач не много.
По обновлениям статуса инцидентов и проблем - да, иногда встречаются не содержательные ответы типа "подрядчики все еще работают и ничего не ответили". Но, к сожалению, очень часто так оно и есть. Хотя бы статистика накапливается.
Была идея, просматривать содержание комментариев в инцидентах, и проверять с помощью ML NLP модели - классифицировать на "полезный" / "отписка". Но до этого ход еще не дошел.
Постараюсь ответить на вопросы:
Задачи и их метрики
Не все, но ключевые метрики для основных типов задач - в списке
Инциденты (время закрытия не долно превышать T1 дней, обновления статуса должны происходить не реже раз в T2 дней)
Проблемы (обновления статуса должны происходить не реже раз в T3 дней, источних проблемы должен быть найдет за не более чем T4 дней)
Чендж реквесты (запуск в рабоу, включая полный анализ, должно завершаться не более чем за T5 дней, завершение должно быть не позже утвержденной даты)
Деманды (полный анализ должен занимать не более T6 дней)
Хорошо, что подход в принципе может помочь контролировать любой процесс, отраженный в системе - была бы возможность сказать "чего не должно быть" и "кто за это отвечает". Мы используем ServiceNow и фактически там - вся IT жизнь.
Как проходит ежедневны контроль
Автоматически. Есть пакетный процесс. Он обегает контрольные отчеты, и для каждой строки отправляет напоминалку ответственному - какие "косяки" найдены. Письма персональные, с прямыми сылками на тикеты, требующие внимания.
Также процесс публикует сводную таблицу косяков в каналы MS Teams.
Другой пакетный процесс запускается еженедельно, в оговоренный момент - если этот процесс находит "косяки" - то это уже фиксируется как "штрафные очки".
Сложности внутри команды
Были проблемы с "принятием" факта что теперь операционка очень серьезно контроллируется. Сопровождалась стандартными этапами - отрицание, гнев, торг, принятие.
В некоторых случаях происходило и происходит до сих пор уклонение, выражающееся в двух формах:
минимизация контроллируемой операционной нагрузи. Это либо переброс на внешних подрядчиков, на которых контроль не распространяется, либо на других коллег. Это плохое проявление и это задача руководителя контроллировать нагрузку. С другой стороны - контроль начал распространятся и на продрядчиков.
вывод работа за пределы стандартных контролей: был инцидент - стала проблема, был стандартный чендж - стал рутинный, или вообще сервис. С ченджами пример позитивный, поскольку на самом деле приводит к улучшению процесса, его формализации и ускорению. С проблемами - не очень. Но поскльку это изместно - оно под контролем.
Объяснения руководству
Изначально метрики распространяются top-down. Как я написал в комментарии ниже - они сформированы в результате получения откликов от внутренних заказчиков и таким образом отражают (в упрощенном виде, конечно) их ожидания.
ИТ руководство само регулярно, но гораздо реже, проводит контроль этих показателей. Так что объяснять показатели - не нужно.
Перевод показателей в измеримые элементы персональных годовых планов еще не распространены в дрыгих отделах - только в наших группах. Но поскольку результаты есть и они очевидны (наша группа не фигурирует или находится глубоко в нижней части в "штрафных" отчетах руководства - у нас все хорошо) то, возможно, практика распространится на другие отделы.
Однако тут нужна воля на уровне отдела. Наши непосредственные бизнес заказчики очень требовательны, и процессы в периметре нашей команды бизнес-критические. Поэтому нам нужно было приводить дела в порядок самим. В других командах возможно ситуация спокойнее.
Опять-же, пропуская обощенную оценку, расскажите, как вы формируете мотивацию к исполнению скучной рутины в веренном Вам отделе / подраделении?
Если есть хороший, позитивный личный опыт управления - ну дайте ссылку на свою статью, где вы все это описываете?
Оставляя в стороне ваше частное оценочное мнение, расскажу, почему так происходит.
Есть определенные ожидания бизнеся от ИТ. В частности - "делайте быстро", "делайте к договоренному сроку", "информируйте, как идет работа", итд.
Такие ожидания трансформируются в формальные метрики поверх тикетинг-системы, и контроллируются на высоком уровне (С, С-1). Очевидно, исполнение этих метрик, вменяется в обязанности каждому линейному руководителю ИТ подразделения.
Теперь руководитель подразделения уже должен обеспечить чтобы каждый в его подразделении понимал и следовал ожиданиям, выраженным через метрики. Да, действительно люди начинают "чинить метрики" - это неизбежно. Но знаете, поскольку метрики отражают запрос клиента - бизнес доволен что мы "успеваем в срок", "своевременно и регулярно информируем" итд.
Можно ли обойтись без метрик вообще сохраняя качество клиентского сервиса? Теоретически - да. Просто надо набрать блестяще умных, мотивированных, лично эффективных, при этом все еще достаточно скромных людей которым не считают зазорным не только "творить великое", но еще и делать это в срок, и сопровождать это качественной коммуникацией в сторону клиента. Таких людей нужно "всего" порядка тысячи по всему миру.
После этого можно и всех "эффективных менеджеров" поувольнять.
В этом обсуждении мы здорово сместились с темы организации и оценки операционной деятельности отдела ИТ в сторону обеспечения производственного качества.
Однако, производственное качество, а точнее его контроль (не обеспечение и не улучшение) и представление результатов контроля упоминалось здесь только в качестве драйвера идеи. Ровно с той же точки зрения упомянут был и поход "функций потерь" из области машинного обучение, который, кстати, не вызвал обсуждения.
Все это для того чтобы показать возможные подходы к переходу от "измеряемых но сложно/по-разному интепретируемых" понятий к абстракциям.
TQM прекрасен как набор мер именно повышения качества. Однако нельзя улучшить то, что не меряешь. А за "измрение" в качестве отвечает именно "контроль".
Можно, пожалуйста, подробнее?
А то пока комментарий напоминет иллюстрацию к Бритве Хитченса из вот этой недавней статьи: https://habr.com/ru/post/710590/
Идея интегрального представления качества через "штрафные баллы" и "финальную оценку" - это подход контроля качества (Quality Control), а не обеспечения качества (Quality Assurance). Такой подход применяется в многопрофильных независимых лабораториях.
На самом деле, действительно, "настроение" - это показатель, у которого должна быть "сезонность": недельный (выходные - работа), месячные, готовые (день рождения, Новый год, лето-зима).
Понятно, что данные за год не позволяют смотреть на годовую сезонность - но недельную и месячную наверное надо учитывать.
Я конечно не знаю полной постановки задачи, но если:
нужно только искать записи по уникальнму ключевому значению, и очень быстро
список помещается в оперативную память
не важно как хранить (поскольку автор несколько раз преобразовывал формат хранения: csv -> сжатый csv с частью колонок, parquet, база SQLight)
то, наверное, можно все записи преобразовать в что-то очень компактное, типа стандартного словаря, индексированного значением штрихода, и сохранять/загружать его из pickle внутри GZip файла.
Компактно на диске, быстрая десериализация, моментальный поиск, минимальный перерасход памяти.