Хотелось бы не просто накапливать знания для службы поддержки, но и управлять содержимым, проверять его перед публикацией. Вам повезло если все ваши мысли уже реализованы в системе и вы только используете готовые возможности.
Для систем с открытым кодом, не всегда бывает очевидным и описанным реализованный в ПО процесс, именно с этим мы и столкнулись в OTRS.
Мы попробовали построить следующий простой процесс: сотрудник пишет FAQ статью, статья проходит утверждение, при необходимости вносятся правки, статья проходит повторное утверждение.
При этом появляются следующие сценарии: проверить написанные статьи, проверить модифицированные статьи FAQ. Кроме этого на связи между процессами управления проблем/инцидентами и процессом управления знаниями хотелось бы посмотреть сколько FAQ статей было связано с какими обращениями и сколько времени было потрачено на обработку (при этом ваши административные регламенты должны требовать связь статей FAQ с обращениями/заявками Клиентов).
Для этого пришлось договориться о том, что в поле Комментарий мы проставляем по системе признак «Принято.» статьи. И написать короткий отчет, который можно либо выполнить из вкладки «Администрирование->Запрос SQL» либо воспользоваться другими, более дружественными к SQL инструментами.
Сам SQL запрос приведен в конце статьи.
Отчет далее загружается в xls где и делаются различные срезы.
Какие результаты мы получили?
1) Все статьи управляемо модерируются.
2) Можно что-то поменять, но нельзя уйти от ответственности.
3) Появляется интересный разрез аналитики в части управления проблемами, «куда уходит время», «где массовые обращения к FAQ».
Производительность приведенного запроса сильно зависит от размера базы. Был бы рад услышать комментарии как его можно оптимизировать. Большая часть времени тратится на фильтрацию по списанному времени.
Для систем с открытым кодом, не всегда бывает очевидным и описанным реализованный в ПО процесс, именно с этим мы и столкнулись в OTRS.
Мы попробовали построить следующий простой процесс: сотрудник пишет FAQ статью, статья проходит утверждение, при необходимости вносятся правки, статья проходит повторное утверждение.
При этом появляются следующие сценарии: проверить написанные статьи, проверить модифицированные статьи FAQ. Кроме этого на связи между процессами управления проблем/инцидентами и процессом управления знаниями хотелось бы посмотреть сколько FAQ статей было связано с какими обращениями и сколько времени было потрачено на обработку (при этом ваши административные регламенты должны требовать связь статей FAQ с обращениями/заявками Клиентов).
Для этого пришлось договориться о том, что в поле Комментарий мы проставляем по системе признак «Принято.» статьи. И написать короткий отчет, который можно либо выполнить из вкладки «Администрирование->Запрос SQL» либо воспользоваться другими, более дружественными к SQL инструментами.
Сам SQL запрос приведен в конце статьи.
Отчет далее загружается в xls где и делаются различные срезы.
Какие результаты мы получили?
1) Все статьи управляемо модерируются.
2) Можно что-то поменять, но нельзя уйти от ответственности.
3) Появляется интересный разрез аналитики в части управления проблемами, «куда уходит время», «где массовые обращения к FAQ».
Производительность приведенного запроса сильно зависит от размера базы. Был бы рад услышать комментарии как его можно оптимизировать. Большая часть времени тратится на фильтрацию по списанному времени.
select fi.f_number as FAQnumber,fc.name,fi.valid_id,fi.approved,fi.f_subject as FAQsubj,fi.f_keywords as FAQkeywords,fi.f_field6 as FAQComment,fi.created as FAQCreateTime,fi.changed as FAQChangeTime,uscr.login as FAQCreatedBy,usch.login as FAQChangerBy,sum(ta.time_unit) as minutes,count(distinct lrs.source_key,lrs.target_key) as FAQlinks
from faq_item as fi
left join users as uscr on uscr.id= fi.created_by
left join users as usch on usch.id= fi.changed_by
left join faq_category as fc on fc.id= fi.category_id
left join link_relation as lrs on lrs.target_object_id=3 and fi.id=lrs.target_key and lrs.source_object_id=1 or lrs.source_object_id=3 and fi.id=lrs.source_key and lrs.target_object_id=1
left join time_accounting as ta FORCE INDEX FOR JOIN (TIME_ACCOUNTING_TICKET_ID) on
(ta.create_time between STR_TO_DATE('20/01/2016', '%d/%m/%Y') AND SYSDATE() and lrs.target_key=ta.ticket_id and lrs.target_object_id=1) or (lrs.source_key=ta.ticket_id and lrs.source_object_id=1 and ta.create_time between STR_TO_DATE('20/01/2016', '%d/%m/%Y') AND SYSDATE())
group by fi.f_number