Суз программа что это

10.4. Технология создания систем управления знаниями

Проектирование систем управления знаниями (СУЗ) декомпозируется на этапы, которые свойственны любой другой ИИ-системе. Вместе с тем имеется ряд особенностей:

• коллективное использование знаний предполагает объединение и распределение источников знаний по различным субъектам, а следовательно, решение организационных вопросов администрирования и оптимизации деловых процессов, связывающих пользователей СУЗ;
• задача проектирования СУЗ носит непрерывный характер, поскольку постоянно добавляются внешние источники данных;
• поскольку СУЗ имеет многоцелевое значение, возникает потребность в интеграции разнообразных источников знаний на основе единого семантического описания пространства знаний.

Этапы проектирования СУЗ:

• идентификация проблемной области:

– определение типов решаемых задач; – отбор источников знаний; – определение категорий пользователей;

• концептуализация:

– выявление понятий (категорий); – выявление свойств (отношений); – построение правил (ограничений);

• формализация:

– выбор метода представления знаний; – представление знаний;

• реализация:

– создание онтологий; – аннотирование и подключение источников знаний; – настройка (создание) приложений;

• внедрение:

– тестирование; – развитие. Онтология – это точное (явное) описание концептуализации знаний (от греч. онтос – сущее, логос — учение) – учение о сущем. Идентификация проблемной области. В первую очередь определяется состав решаемых задач. Возможно создание узкоспециализированных систем по отдельным функциям управления: маркетинга, менеджмента, финансов. Разработка СУЗ может начинаться с отдельных областей, например с маркетинга, не требуя одновременной разработки всех необходимых онтологий и источников знаний. Для создания БЗ прецедентов требуется определить набор типовых бизнес-процессов, для которых будут отбираться прецеденты, например, разработка проектов, заключение договоров, проведение PR-акций. Центральное место в проектировании СУЗ занимает онтология, которая определяет и интегрирует все источники знаний. Требования разработки онтологий оформляются в виде спецификации требований (табл. 3) Таблица 3

Предметная область	Подбор и повышение квалификации персонала компании
Назначение	Онтология служит для обмена знаниями между департаментом управления и менеджерами проектов при отборе персонала. Используется для семантического поиска квалификационных характеристик для выполнения определенных видов работ
Область значений	Онтология содержит концепты (категории) управления персоналом. Концепты используемых квалификаций в технологиях рассматриваются детально
Поддерживающие приложения	Система управления квалификацией персонала в ИНТРАНЕТ-среде
Источники знания	Web-страницы департамента управления персоналом Руководство о развитии персонала Спецификация продукции и технологий Интервью с работниками департамента управления персоналом и менеджерами проектов

Концептуализация знаний с помощью онтологий Назначение онтологий – обеспечение возможностей:

• повышение интеллектуальности СУЗ на основе того, что остается неявным;
• стандартизация на основе описания целевого мира в виде словаря, согласованного среди людей, разделение знаний между различными пользователями и компьютерными системами;
• систематизация знаний, позволяющая интегрировать разнородные источники знаний на основе единой многоаспектной таксономии, представляемой в общем словаре;
• снабжение необходимыми понятиями, отношениями и ограничениями, которые используются как строительные блоки для создания конкретной модели решения задач;
• постепенное обобщение понятий конкретной проблемной области.

Требования к проектированию онтологий знаний:

• ясность – четкая передача смысла введенных терминов (концептов);
• согласованность – логическая непротиворечивость определений;
• расширяемость – возможность монотонного расширения и специализации без необходимости пересмотра уже существующих понятий;
• инвариантность к методам представления знаний;
• отражение только наиболее существенных предположений о моделируемом мире.

Онтологическое знание организуется на трех уровнях: онтология верхнего уровня (метаонтология); онтология предметной области; онтология задач. Метаонтология отражает такие общие понятия, как «сущность», «класс», «свойство», «значение», «типы данных», «типы отношений», «процесс», «событие». Определение общих категорий позволяет системе контролировать синтаксические конструкции понятий предметных и проблемных областей, которые объявляются как наследники общих категорий. Онтология предметной области определяет набор понятий, используемых при решении различных интеллектуальных задач и не зависимых от самого метода решения задач. При построении онтологии предметной области выявляются свойства и отношения понятий, строятся логические правила, расширяющие семантику модели предметной области. Онтология задач имеет дело с понятиями, описывающими методы преобразования объектов предметной области в процессе решения задач. Например, для задач обучения в качестве методов обучения могут использоваться дедуктивный (от общего к частному), индуктивный (от частного к общему) и абдуктивный (от частного к частному). С помощью понятий, свойств и отношений описывается сущность используемых методов, устанавливается последовательность их выполнения. Введение онтологии задач позволяет расширить класс интеллектуальных задач, решаемых с помощью СУЗ, в частности перейти от простых поисковых задач к задаче конфигурации, когда система автоматически разбивает задачу на подзадачи, для каждой подзадачи выбирает метод решения задачи, а для каждого метода выбирает необходимые единицы предметных знаний. Такая СУЗ является не просто интеллектуальной информационно-поисковой системой, но и системой, которая планирует и генерирует решение задачи. В этом аспекте СУЗ должна обладать развитым механизмом вывода и по своей реализации сближается с классом ЭС, но на более развитой семантической основе. Формализация онтологического знания В основе формализации онтологий, с одной стороны, лежат общепризнанные методы представления знаний (исчисление предикатов, семантические сети и фреймы), с другой  методы описания онтологических знаний с помощью специальных семантических конструкций. В качестве языков представления онтологического знания используются:

• языки, основанные на исчислении предикатов;
• HTML-подобные языки;
• XML-подобные языки.

Языки, основанные на исчислении предикатов, построены на декларативной семантике и обеспечивают выражение произвольных логических предложений. С помощью этих языков хорошо представляется метазнание. Это позволяет пользователю представлять знания в явном виде и разрешает пользователю новые конструкции представления знаний без изменения самого языка. Одним из таких языков является KIF, разработанный для обмена знаниями между различными программными агентами (ЛИСП-подобный язык). HTML-подобные языки (Hypertext Markup Language). Язык разметки гипертекста. С использованием HTML создано более 60% ресурсов современного Интерента. Браузер – специальная клиентская программа, предназначенная для просмотра содержимого Web-узлов и отображения документов HTML. В качестве основы для описания онтологий и онтологического аннотирования текстов может выступать язык разметки данных HTML, дополненный специальными тегами (указателями). С помощью тегов происходит выделение семантических фрагментов текста, которые унифицированно интерпретируются семантическими анализаторами различных ПС. Языки данной группы позволяют описать объекты онтологии (концепты), отношения между ними и определить правила вывода. Основное назначение таких языков состоит в возможности описания онтологии, аннотирования необходимых Web-страниц концептами онтологии и дальнейшее осуществление поиска данных Web-страниц с помощью специальной поисковой машины. XML-подобные языки. В качестве основы для таких языков выступает расширяемый язык разметки. В настоящее время существует около 20 различных языков, основанных на XML. Основным достоинством языка является то, что для работы с документами, подготовленными с помощью него, достаточно обычного интернет-браузера, т.е. не требуется никаких дополнительных средств. XML-документ представляет собой размеченное дерево, например, структура XML представления описания обычного учебного курса приведена на рис. 10.2. Рис.10.2. Размеченное дерево Сам язык XML в принципе не обладает практически никакими возможностями в области представления онтологий. В нем отсутствуют специальные конструкции, позволяющие описать взаимоотношения между концептами онтологии, правила вывода. Он предназначен исключительно для представления данных. Язык RDF, представляющий расширение XML, позволяет описать концепты, отношения между ними, поддерживает иерархию концептов и их наследование, задает некоторые правила вывода. Базовыми строительными блоками в RDF является триплет «объект-атрибут-значение», часто записываемый в виде A (O, V), который читается как объект О, имеет атрибут А со значением V. В семантической сети эту связь можно представить как ребро с меткой А, соединяющее два узла О и V. Выбор ИС реализации СУЗ во многом определяется требуемой функциональностью использования СУЗ: информационный поиск в источниках знаний, коллективное решение задач, обучение и др. Для узкоспециализированных целей, ориентированных на поиск в интернет- ресурсах, используются специализированные системы, например SHOE, которая обеспечивает аннотацию документов, сбор знаний в централизованную БЗ, выполнение поисковых запросов. ИС должны обеспечивать две основные группы функций.

1. Создание и поддержание источников знаний:

– создание и поддержание онтологий; – аннотирование источников знаний; – подключение источников знаний; – автоматическая рубрикация и индексирование источников знаний;

1. Доступ к источникам знаний:

– реализация запросов; – навигация и просмотр; – коммуникация пользователей; – распространение знаний.

Что такое и как работает система управления знаний (СУЗ) для компаний: Полина Сурчалова, Эквио

Что такое система управления знаниями?

Источник: studfile.net

Станция управления заказа (СУЗ) Честного Знака

Честный знак

На чтение 5 мин. Просмотров 5k. Опубликовано 31.10.2020

СУЗ — система контроля за различными заказами кодов маркировки, которая находится у оператора маркировки и состоит из полноценного аппаратного и программного комплекса.

При этом производитель для заказа КМ обращается с необходимым запросом непосредственно к СУЗ для получения определенных КМ. На практике же все намного легче и проще. Заявки на выпуск КМ образуются в личном аккаунте, запрос полностью проходит проверку и затем идет в СУЗ. В аккаунте участника оборота демонстрируются созданные КМ.

Как получить Регистратор Эмиссии?

Регистратор эмиссии — это система криптографической защиты кодов, которая была утверждена действующим российским правительством. Она собой представляет особое оборудование, предоставляющее закодированным символам крипто-хвосты с целью достижения определенной информационной безопасности.

Регистраторы эмиссии, в согласии с правовой информацией, для генерации кода предоставлены будут производителю полностью бесплатно.

Для получения регистратора эмиссии потребуется:

• Пройти регистрацию в ИС МП (информационной системе маркировки и прослеживаемости). Для этого нужен УКЭП.
• Оформить внутри кабинета заявку на получения устройства эмиссии. Установить на производство СУЗ, а также принтер этикеток.
• Подключить регистратор к уже готовой линии производства.

Кто может делать бизнес заказ?

Чтобы сделать бизнес заказ, потребуется обязательно пройти регистрацию в специальной системе Честный знак. Разумеется, лишь после этого можно будет делать полноценный бизнес заказы.

Как создать производственный заказ в СУЗ личного кабинет Честного Знака

Для создания производственного заказа в личном аккаунте СУЗ, потребуется выполнить следующее.

1. Пройдите официальную регистрацию в ГИС МТ.

2. Заключите с Оператором ГИС МТ:

• Соглашение о подключении к системе мониторинга.
• Соглашение с условиями предоставления устройств регистрации эмиссии, а также их регламентного обслуживания.
• Соглашение на оказание сервиса по предоставлению КМ.

3. Зарегистрируйте, опишите, а также получите коды товаров (КТ) на:

• Остатки продукции по упрощенному атрибутивному составу в ГИС МТ.
• Товары на официальном портале Ассоциации автоматической идентификации.

4. Пополните на необходимую сумму денег счет для предоплаты за оказание сервиса по предоставлению КМ:

• По реквизитам.
• По счету.

5. Перейдите в «Станцию управления заказами», выбрав необходимую вкладку в меню сверху слева экрана.

6. Сверху слева на экране выберите пункт под названием «Бизнес заказы» и нажмите на кнопку «Создать».

7. Выберите в новой форме нужную группу товаров и подтвердите собственные действия с помощью кнопки «Подтвердить».

8. Заполните поля новой формы с характеристиками заказа:

• Если код определенного товара состоит из меньше, чем четырнадцати цифр, то слева потребуется его увеличить цифрой «0» до четырнадцати.
• Для оформления в одном заказе КМ для товаров с различными КТ, или же с иными параметрами, потребуется нажать на клавишу «+Добавить», а затем указать нужные характеристики.
• Если был выбран метод создания серийного номера «Пользователем», потребуется загрузить перечень серийных номеров в форме файла CSV.

9. Сделайте подтверждение сохранения характеристик заказа с помощью нажатия клавиши «Сохранить». Сохраненный заказ будет показан в перечне заказов под статусом «Черновик». После этого нужно будет нажать на клавишу «Подписать и отправить», дабы подписать документ отправляемый Оператору ГИС МТ посредством УКЭП, а в новом окне сделать подтверждение операции нажатием клавиши «Да».

10. После непосредственно подписания заказа проверьте корректность и правильность введенных данных. Анализ не будет успешным и заказ обязательно будет «Отклонен», если будут представлены сведения, не подходяще действующим правилам.

11. Если проверки будут выполнены успешно, то заказ будет показан в перечне заказов со специальным статусом «Доступен». Если на счету есть достаточно денежных средств, то участник оборота товаров сможет получить КМ на протяжение шестидесяти рабочих дней. По завершении данного срока не забранные КМ в обязательном порядке аннулируются.

12. Для эмиссии КМ потребуется найти нужный заказ в перечне. Специальная форма с детальными сведениями о заказе появляется после нажатия на графу в пункте под названием «Бизнес заказы».

13. С левой стороны от идентификатора заказа следует нажать на значок плюсика, а после на клавишу «Напечатать» в поле с КТ со специальным статусом «Активный».

14. Выберите подходящий тип получения и число КМ и нажмите на клавишу «Печать». С лицевого счета спишется нужная денежная сумма за услуги по предоставлению КМ. Можно выбрать один из вариантов этикетки либо загрузить свой в личном аккаунте СУЗ под администратором во вкладке «Этикетки» посредством специального «Руководства по созданию и загрузке шаблона этикетки пользователя».

15. Когда будут эмитированы полностью все КМ по КТ, заказу сразу присвоится специальный статус «Закрыт». Если эмитированы все КМ по всем КТ из заказа, то в СУЗ он вообще не проявляется.

16. Когда регистратор эмиссии отдаст данные в электронной форме, что заказанные коды маркировки эмитированы, они сразу будут показаны в официальном реестре КМ в пункте под названием «Коды маркировки».

Источник: markirovvka.ru

Управление знаниями, создание базы знаний. А что на практике?

Продолжая тему двух предыдущих постов (первый и второй), в которых проводилось исследование на тему управления знаниями и были рассказаны основные результаты, хотелось бы углубиться в практическую составляющую данной проблемы. Вопросов для обсуждения здесь предостаточно, но основной — существуют ли инструменты, позволяющие удовлетворить все потребности бизнеса в части управления знаниями? Попробуем ответить на этот вопрос со своей «колокольни».

Классификация систем управления знаниями

Рынок программного обеспечения по управлению знаниями крайне неоднозначен. Это связано с тем, что направление относительно молодое, а само определение понятия «управление знаниями» трактуется разными авторами по-разному, о чем мы уже говорили в первом топике на эту тему. Наиболее известная классификация приведена на картинке ниже (по материалам — www.bigc.ru/publications/bigspb/km/itkm). Отнесение такого широкого класса ПО к системам управления знаниями (СУЗ) объясняется тем, что в СУЗ знаниями называют все виды информации, включая неструктурированный контент (письма, эскизы, фото), данные (в базах данных и хранилищах данных), и знания (как закономерности предметной области, позволяющие специалистам решать свои задачи).

Конечно же, анализировать каждую ветвь этого пусть и небольшого дерева не имеет смысла, поэтому направление для детализации было сильно сужено с учетом жизненных реалий и результатов исследования. Полноты ради не могу не упомянуть про два примера создания базы знаний (БЗ) именно в ИТ области. Первый, это БЗ крупной консалтинговой компании IBS. Информация достаточно старая, с тех пор наверняка что-то поменялось. Упомянуть хотелось бы лишь некоторые основные моменты, остальное вы сами можете посмотреть в презентации.

Основным понятием в БЗ IBS является документ. Вся работа с БЗ от пополнения до использования вертится именно вокруг документов. В качестве ПП для такого, казалось бы, простого подхода используются сразу три разнородных и дорогостоящих решения. Это Documentim, SAP R/3 и Lotus. Согласитесь, троица впечатляющая.

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

Второй пример, это компания «ЭлиСи», занимающая АСУ ТП в нефтегазовой отрасли. Там в качестве базиса корпоративной СУЗ предлагается внедрять депозитарии знаний с использованием метаданных, метаописаний и онтологий. Таким обазом можно найти компромисс между необходимой кодификацией знаний и дороговизной этого процесса.

Т.е. в качестве СУЗ компании будет выступать семантическая надстройка над информационной системой предприятия. Подход более современный и осмысленный, потому что появляется семантика, а значит попытка заглянуть внутрь, поближе именно к знаниям. Примечательно, что инициатором проекта был генеральный директор компании, параллельно защищавший диссертацию на данную тему.

А что нам нужно

1. Использование семантических технологий. При работе со знаниями, семантику игнорировать не стоит. Один из основополагающих моментов.
2. Ориентация на малый и средний бизнес. Понятно, что с помощью Documentum можно закрыть массу вопросов, связанных с ИТ-инфраструктурой, а SharePoint по мнению Microsoft умеет вообще всё, но нужно что-то более приземленное.
3. Поддержка совместной работы и высокая степень интероперабельности. Если с коллаборативностью у большинства корпоративных информационных систем дела более-менее, то интеропребельность (не люблю заимствованные термины) везде разная. Очевидно, что БЗ не должна быть закрытой и обособленной ИС.
4. Мелочи-полезности, которые проявились из опроса, а именно: увязка БЗ с workflow и использование визуализации (в частности, mind mapping).

Учитывая все эти факторы, направление сузилось до вики-систем. По многим причинам, одна из которых — результат опроса, который показал, что вики уже активно используются, а значит хорошо знакомы своим потенциальным пользователям. Ну и конечно же их простота, легкость развертывания и зачастую открытость.

Возник главный вопрос, а где же использование семантических технологий, ведь оно стоит на первом месте? Оказалось, что среди вики-систем уже давно выделяют семантические вики, и именно этому контексту будет посвящен остаток этой статьи. Был очень удивлен, что на хабре упоминаний, посвященных этой теме совсем немного. Если вкратце, то основная отличительная особенность по сравнению с традиционными вики — возможность указывать тип ссылок между статьями, типы данных внутри статей, а также информацию о страницах. Это предложение из одноименной статьи в википедии, за полным описанием туда.

Другими словами, семантические вики позволяют организовывать и структурировать информацию более эффективно. Многие семантические вики поддерживают rdf и owl, что позволяет добиться более жесткой формализации, а вместе с ризонерами (reasoner) и поддержки логического вывода. С первого взгляда кажется, что всё это — лишнее усложнение, которое станет еще одним препятствием для конечного пользователя. Однако на практике работу с типизированными данными можно организовать с помощью семантических форм, и для пользователя это будет выглядеть как очередная анкета, с которой просто оперировать.

Семантические вики. Увы их тоже много

Самым показательным примером семантических вики является надстройка над движком MediaWiki, называющаяся лаконично и понятно Semantic MediaWiki. Распространяется под хорошей лицензией GNU GPL v.2 Идеально для тех, кто уже использует media wiki, хочет открытости, простоты и прочих возможностей подобной политики лицензирования. Расширений у нее очень много, полезных и не очень. В общем взглянуть стоит.

Среди всех прочих семантических вики я остановлюсь только на двух, с которыми имел возможность хоть немного, но поработать. Обе они распространяются под коммерческими лицензиями, но имеют также и community версию с несколько ограниченным функционалом. Почему на них? потому что они имеют бОльшую корпоративную направленность.

Первая — это semantic media wiki plus. Базируется на том же самом расширении semantic media wiki и дополнена богатым и крайне важным функционалом, упрощающим и одновременно расширяющим возможности семантических вики. Плюс всё необходимое сразу собрано в один пакет, что было важно для меня, когда я присматривался и выбирал конкретную систему. Рекламировать больше не буду, за меня гораздо эффективнее это сделает сайт продукта. Что понравилось:

Прекрасные возможности по интеграции, в т.ч. числе и уже разработанные. Например, с продуктами Microsoft Office (Word, Project), электронной почтой, тем же SharePoint. Сюда же — возможность написания коннекторов для своих приложений.
В качестве примера использования можно установить уже созданные онтологии project и risk management. Наглядно, понятно, еще бы кто-нибудь попробовал на деле. В случае чего структуру всегда можно изменить под себя, это на самом деле несложно. Так же понравилось, что в вики с описанием самой системы были выделены типичные роли, которые показательны для такого класса систем: ontologist, gardener, end user, developer, administrator. Пожалуй, двух абзацев достаточно, подробнее можно и на сайте посмотреть.

Второй продукт, с которым довелось совсем немного познакомиться, подойдет для тех, кто по тем или иным причинам предпочитает java-технологии. Называется Information Workbench (IWB). Продукт ровно как и компания его разработавшая относительно молодые. Не буду писать про возможности и прочие полезности, предлагаю взглянуть на архитектуру и отправиться на сайт разработчика за всей информацией. Отмечу лишь то, что реализация пока сыровата, но все делается грамотно и профессионально. и научно;) Как мне сказала представитель компании: «оба наших директора Ph.D.»

Визуализация — Mind map, WorkFlow и Confulence

В данной части вкратце остановлюсь на этих трех разнородных словах.

Не таю, что визуализации с самого начала уделял много внимания. Даже вопрос отдельный завел в опроснике. Причина — информацию мы воспринимаем лучше в визуальной форме (перечитывал свой текст, еще раз убедился в этом). Для работы со знаниями самая лучшая визуализация — использование mind map (тут кстати статья неплохая была про данную методологию).
Так вот. Во всех вики с этим дела обстоят так себе. У freemind только есть возможность вставки (embed), уже хорошо. Может, конечно, где-нибудь что-нибудь опустил.

Впрочем есть и альтернативные подходы. Например в IWB есть представление онтологии, лежащей в основе вики в виде графа. Очень удобно. Это можно эффективно использовать. Если семантическая вики поддерживает SPARQL endpoint можно попробовать прикрутить RelFinder, который будет сторонним визуализатором БЗ.

Чтобы понять механизм действия можно посмотреть самостоятельно выяснить, что общего, например, у Москвы и Пушкина.

WorkFlow. Знания в отрыве от практической деятельности не нужны. Какой в них смысл, если их не применять. Повседневная деятельность может быть отражена в WorkFlow. Что здесь?

А здесь тоже не очень. С одной стороны тот же SMW+ заявляет, что smw+ “tool that well suited for organizations or teams dealing with heterogeneous and informal workflows”. Но нормального прагматичного решения увязки workflow и базы знаний нет. Вот хороший комментарий на этот счет:

Some first ideas (I deliberately don’t make a real distinction between a workflow and a BP here)
— using the wiki to create/improve workflows/processes => The ideal is if you can generate a process from the (final) wiki info
— using the wiki do document workflows/processes
— using the wiki to support running workflows/processes (info on background, how to, share experiences, Q push info, trigger people/apps, collect info,
— using the workflow/BPM to steer wiki publishing => approvals etc

Впрочем у BPM пакета Bizagi process modeler есть выгрузка всех отрисованных блоков построенных моделей в категории и статьи Media Wiki. Можно очень удобно их использовать в связки, облегчая себе работу.

Автор комментария на английском дал мне ссылку, где wiki и workflow работают более тесно — www.adhocworkflows.com Это плагин сторонних разработчиков к Confluence. Не ставил, не пробовал, не тестил. Никак прокомментировать не могу, но поделиться считаю, что нужно. Тем более Confulence и Jira совсем рядом, а последней много кто пользуется.

Так же для Confluence есть и семантическая надстройка — www.zagile.com/products/wikidsmart.html Отличная альтернатива для тех кто строит вики не с нуля, а перепроектирует уже наполненную имеющуюся. Тоже не тестил, ничего добавить от себя не могу.

А что еще

Как известно, основная проблема в управлении знании в целом и создании базы знаний в частности — нехватка времени и нежелание наполнять базу знаний. Свободное время зачастую тратится на серфинг Интернета, на общение с коллегами. Мысль вслух: «пусть в следующий раз выполняя схожую задачу, мне придется что-то судорожно вспоминать и заново искать, все равно сейчас базой знаний я не займусь, хоть она и поспособствует более благоприятной работе в далеком будущем». Но от этого никуда не деться, только как-то дополнительно стимулировать сотрудников.

В качестве альтернативы рассмотренных выше вики, есть подход, ставящий во главу угла процесс коммуникации. Отчасти здесь фигурирует знание, что подтверждается наличием одного из процесса трансформации знания по известному японскому специалисту Нонака — социализации, левый верхний квадрант.

Здесь я прежде всего имею в виду проект rizzoma. Когда только начинал заниматься поднятым вопросом, очень понравилась одна из их первых статей. Тогда проект был еще под старым именем.

Если вкратце, то rizzoma — это продолжение концепции Google Wave, где всё обсуждение строится волнами или blip-ами. «Rizzoma — collaboration-сервис, включающий в себя wiki-систему, мессенджер и, в скором будущем, таск-трекер.» Сервису еще много чего нужно докручивать, тех же тасков сейчас нет, да и вики в привычном понимании не угадывается, но перспективы развития есть. Мне особенно в нем понравилось отображение структуры волн в mindmap. При грамотной организации получается хорошо воспринимая для постороннего человека структура. Имхо — такой подход лучше всего работать будет в связке с семантическими вики, если привить культуру общения в rizzoma, а структурирование возложить на вики.

Жду ваших комментариев. Может быть кто-нибудь пользовался упомянутыми продуктами. Интересно было бы узнать стороннее мнение.

P.s. извините за простыню. не хотелось разбивать топик на несколько, чтобы в очередной раз не затягивать со следующим постом.

Источник: habr.com

Система управления знаниями: зачем она нужна в технической поддержке

Система управления знаниями для технической поддержки

Качественная система управления знаниями повышает эффективность любой корпоративной функции (клиентское обслуживание, продажи, маркетинг). Она помогает преодолевать затруднения во внутренних коммуникациях и оптимизирует обмен бизнес-информацией.

Сейчас технической поддержке приходится сегодня иметь дело с постоянно усложняющимися задачами. Требования к обслуживанию постоянно растут, ИТ-ландшафты компаний постоянно усложняются. Кроме того, все сейчас стремятся как можно больше использовать для работы собственные устройства. Это также создаёт дополнительные сложности.

Польза от системы управления знаниями для службы технической поддержки хорошо известна и её легко измерить. Ниже я привожу несколько примеров того, как СУЗ влияет на работу этой службы.

• Благодаря системе управления знаниями сотрудники начинают более тесно сотрудничать, особенно это важно, когда компании быстро растут.
• Снижается время вынужденного простоя из технических сбоев, растёт продуктивность;
• Оптимизируется использование квалифицированных кадров;
• Новые сотрудники быстрее адаптируются и обучаются;
• Снижаются операционные траты из-за повышения эффективности работы.

Положительные результаты от использования системы управления знаниями легко измерить. Но несмотря на это многие компании по-прежнему не используют СУЗ на полную мощность.

Система управления знаниями для самообслуживания пользователей

Как часто специалистам технической поддержки приходится отвечать на вопросы с одним и тем же ответом? Оптимальнее было бы дать возможность клиентам самим находить ответы на несложные вопросы, на которые специалисты службы поддержки уже давали ответ. Для этого достаточно дать доступ пользователям к базе часто задаваемых вопросов в системе управления знаниями.

Система управления знаниями для решения сложных технических проблем

Специалистам технической поддержки нужно где-то хранить информацию в удобном формате? Базовые технические факты и информацию обычно сравнительно легко найти. Гораздо сложнее найти ответы на вопросы, которые требуют более предметного рассмотрения и технической экспертизы. Такие вопросы требуют достаточно специфичной информации.

Именно поэтому очень важно использовать систему управления знаниями с хорошим поисковым алгоритмом. Она поможет эффективно извлекать любую информацию в один клик мыши.

Система управления знаниями для сокращения технических ошибок

Актуальная техническая информация в компании устарела и плохо поддерживается? Это грозит постоянными ошибками, циркуляция неточной информации окажет разрушительное действие на операционную деятельность. C системой управления знаниями с такими проблемами справиться намного проще. Она упростит обновление и редакцию существующих статей с технической информацией. Кроме того, с ней будет легче создавать новый контент и распространять его среди сотрудников, которым он нужен.

Система управления знаниями для повышения вовлечённости сотрудников

Специалисты технической поддержки не умеют определять приоритетные задачи? Здесь система управления знаниями также будет полезна. Чёткое структурирование информации на основе ключевых метрик позволяет определять приоритетность запросов в техническую поддержку. Это не только снижает затраты, но и повышает вовлечённость сотрудников и удовлетворённость своей работой.

Система управления знаниями с искусственным интеллектом

Другими словами, эффективная система управления знаниями обеспечивает специалистов службы поддержки всей необходимой информацией. А эффект от этого расходится по всей компании, как круги по воде: улучшается способность организации к развитию, мотивирует сотрудников продуктивнее работать, обеспечивает поддержку руководства.

На практике всё оказывается не так идеально. Для того, чтобы всё сделать правильно, нужно значительное количество времени, внимания, энергии. А именно этого не хватает во многих организациях. Поэтому важно, чтобы в системе управления знаниями был искусственный интеллект. Искусственный интеллект упрощает процесс сбора информации, её поиск и поддержку.

В основе работы искусственного интеллекта лежат такие технологии, как сематический поиск, обработка естественных языков, машинное обучение.

Это помогает различным отделам и различным сотрудникам одинаково собирать информацию и обмениваться ей. При этом информация из множества источников соединяется и комбинируется. Кроме того, контент системы управления знаниями эффективно поддерживается в актуальном состоянии. Сотрудникам постоянно приходят уведомления о необходимости обновить информацию. Инструменты с искусственным интеллектом позволяют измерять важные метрики, легко следить за операционными затраты и продуктивностью.

Система управления знаниями станет важным преимуществом

Система управления знаниями обеспечивает реальные, измеримые результаты для технической поддержки. Именно благодаря СУЗ сотрудники, процессы и технологии объединяются для того, чтобы компания могла добиваться более высоких бизнес-результатов быстрее. Качественная система управления знаниями в технической поддержке станет важным конкурентным преимуществом для вашей компании.

• KMS Lighthouse
• техническая поддержка

Источник: dis-group.ru

Система управления знаниями

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

Процессы

Для успешного управления знаниями в организации должны быть налажены соответствующие процессы, такие как:

• Поиск знаний
• Извлечение знаний
• Классификация и хранение
• Оценка знаний
• Распространение знаний
• Реализация знаний (в виде продуктов, услуг, документов)
• Защита знаний

Информационные технологии

Информационные технологии обеспечивают создание технической инфраструктуры которая позволяет:

• Систематизировать знания
• Накапливать знания
• Хранить знания
• Осуществлять обмен
• Для этого используется такие системы, как например: ERP, KRM, CMS и другие.

Система управления знаниями

Механизмы Системы управления знаниями

Экономические эффекты СУЗ

Задачи СУЗ технологические решения

Преимущества Системы управления знаниями

Внедрив СУЗ компания приобретёт следующие преимущества:

Значительно повысит эффективность производства, так как свободный доступ к знаниям позволяет решать проблемы более оперативно и результативно.

Сократить статьи расходов. Первыми в бизнес — сообществе СУЗ стали внедрять нефтегазовые корпорации. Так например, благодаря внедрению СУЗ компания ВР сэкономила 7,4 млрд долларов.

Ликвидировать зависимость знаний от владеющих ими людей. Вам больше не придётся сталкиваться с проблемой, когда уход сотрудника из компании был равен потере бизнесом знаний, которыми он владел.

Наконец, Ваша компания сможет производить собственные знания, тем самым приобретая новые конкурентные преимущества.

Критерии успеха при внедрении СУЗ

Проект внедрения СУЗ считается успешным, если по его результатам:

• Компания производит новые знания
• Знания принимают участие в решении задач

Источник: hr-portal.ru