Comments 6
по-моему алгоритмы управления инцидентами проблемами и конфигурациями уже давно весьма известны, но удивляет что до сих пор нет решений на пример в области медицины создание без данных с иерархией полезности методов решения инцидентов, отслеживания проблем,. ведь такие знания уже есть в различных справочниках, и по сути можно использовать для диагностики, подбора анализов для уточнения диагноза, и избежания осложнений
Честно говоря на ваш комментарий могу сказать, что для медицины есть. Еще точнее могу сказать, что есть способ. И был уже давно реализован. Еще в СССР. Еще до компьютеров.
Я сам заимствовал для своей системы именно наработку из медицины. На одном из акселераторов мне сказали, что моя система может называться интераетивной базой знаний. Мне это описание понравилось.
А в общем я писал алгоритм для службы поддержки. так как двигать в медицине нет возможности и сил жалко.)))
Применительно к самой статье могу привести примеры, когда не всегда удается найти решение по похожей проблеме. Так как бывает, что проблема одна, а причины разные. Следовательно, пути решения окажутся другими.
так можно несколько решений отображать, и ранжировать их по количеству кому помогло… да и есть управление инцидентами, а есть проблемами, если инцидент повторяется, или инциденты возникают связано, то это переходит в критерий проблемы и решается уже на архитектурном уровне
Мое мнение, что ранжирование вряд ли может помочь. И способы решения проблем могут накопиться в большом количестве.
Применительно к базе знаний. Она должна решать конкретную проблему определенными шагами. но, часто, вы столкнетесь с первичной задачей определения источника проблемы. И уж потом вам понадобятся конкретные шаги по устранению причин.
Я могу привести пример из практики. Пост самообслуживания пациентов. Эт о компьютер с тачскрин экраном, с динамиком, кардридером, принтером, с подключенными к нему весами и измерителем давления. Так же установлено программное обеспечение. Как то что взаимодействует с подключенным оборудованием, так и интерфейс общения с пользователем. Выход из строя чего-либо одного автоматически делает такой пост неработоспособным.
Общее первичное описание проблемы — "Не работает". Само по себе определения того что именно не работает достойно хорошей статьи в базе знаний. Дальше больше. нужно отдельную статью на каждый случай. Случаи так же в себе делятся на различные причины. И так далее. Попытка это отобразить в виде статей имеет громоздкую и неудобную структуру. Иногда поиск займет больше времени, чем нужно реально на устранение.
Я использовал несколько другой подход. Каждый раз сталкиваясь с проблемой в интерактивную базу знаний вносились шаги по диагностике и исправлению. Самый оптимальный вариант. Ведь выводы можно сделать по итогам проведенной работы. и уже после решить что лишнее, а что необходимое. В итоге решение многих проблем превращалось в набор нескольких оптимальных шагов.
Причиной к такому решению стало то, что нужно было обслуживать систему, которая установлена в различных регионах. Уровень специалистов на местах был различным. Заявки люди по одной и той же проблеме заполняли различным образом. часто не собрав необходимой информации. Отвлекались ресурсы более высоких уровней поддержки по вполне уже рутинным вопросам. И всегда можно было отследить по каким шагам прошел специалист по ходу решения.
А чем собственно msdmanuals не угодил?
Почему «погугли сам» — не наш метод и как мы прокачиваем Базу знаний для техподдержки