ГОСТ Р 57321.2-2018 Менеджмент знаний. Менеджмент знаний в области инжиниринга. Часть 2. Проектирование на основе баз знаний

     6 Процедура общей реализации KBE-проектов

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

Процедуру реализации KBE-проекта подразделяют на четыре этапа (см. рисунок 2). В 6.1 описаны роли, которым в той или иной степени необходимо следовать на этапах осуществления проекта, в 6.2 рассмотрен первый этап - этап планирования. Основное внимание на этапе планирования уделено организации KBE-проектов, в частности выявлению (идентификации) необходимых знаний. В 6.3 на этапе разработки главным образом представлены стратегии и методы сбора, анализа и структурирования знаний, а также различные варианты реализации (применения) знаний. В 6.4 на этапе тестирования перечислены процедуры валидации и релиза. В 6.5 описаны работы по администрированию, поддержанию и обновлению знаний. Обеспечение безопасности и защиты знаний не является отдельным этапом KBE-проекта, однако эту процедуру следует рассматривать как проходящую через все этапы. В 6.6 приведены положения, указывающие на особую важность обеспечения безопасности и защиты знаний в KBE-приложениях, и установлены соответствующие меры ее обеспечения.

     
Рисунок 2 - Процедуры реализации (фазовая модель) KBE-проекта

6.1 Роли

На рисунке 3 приведены роли участников, связанные с реализацией KBE-проекта. "Мышление в ролях" (в отличие от "мышления в людях") позволяет каждому сотруднику компании выполнять одновременно несколько ролей. В то же время действующие роли конкретного сотрудника (например, CAD-проектировщик, инженер-расчетчик, IT-архитектор) не должны заменяться ролью, связанной с KBE-проектом, вместо этого в данный проект могут быть введены дополнительные специфические KBE-задачи. Наиболее существенные роли KBE-проекта приведены на рисунке 3.

     
Рисунок 3 - Основные роли участников KBE-проекта

6.1.1 Заказчик

Заказчик (например, менеджер проекта) должен инициировать KBE-проект и участвовать в нем с самого начала - с этапа планирования, так как именно он должен определить основные показатели проекта (например, тип и область применения KBE-приложения) и закрепить сотрудников за проектом. В процессе выполнения проекта заказчик должен выполнять функции более низкого уровня, ввиду того что управление проектом должен брать на себя инженер по знаниям (см. 6.1.4). На этапе тестирования заказчик должен участвовать в валидации KBE-приложения и проверять достижение целевых показателей. В случае выполнения KBE-проекта небольшого объема роли заказчика и инженера по знаниям может выполнять один специалист.

6.1.2 Эксперт

Эксперт (например, проектировщик или специалист планово-производственного отдела предприятия) должен активно участвовать на всех этапах (см. рисунок 2). На этапе планирования эксперт должен поддерживать процесс идентификации знаний, предлагая использовать собственные знания. Сбор знаний должен проводить инженер по знаниям на этапе разработки (совместно с экспертом), включая анализ и структурирование, а затем включать в KBE-приложение (экспертное обсуждение/дебрифинг). Эксперт также должен участвовать в проверке KBE-приложения на этапе тестирования (например, путем разработки тестового примера). На этапе эксплуатации эксперт должен оказывать поддержку инженеру по знаниям при работе с KBE-приложением, обеспечивая ввод новых знаний в базу знаний приложения. При этом важно, чтобы на протяжении реализации всего проекта у эксперта была соответствующая мотивация к сотрудничеству с другими сотрудниками компании, которую должен стимулировать менеджер KBE-проекта (как правило, это инженер по знаниям) и поддерживать заказчик в ходе реализации всего проекта (например, посредством соответствующих целевых соглашений).

6.1.3 Пользователь

Роль пользователя (например, CAD-проектировщика) прежде всего должна ограничиваться его участием на этапе эксплуатации (например, для проверки достижения заданных целей проектирования или компоновки). Тем не менее пожелания потенциального пользователя следует учитывать уже на этапах планирования и разработки. По возможности пользователя также необходимо привлекать к работам по проекту на этапе тестирования. В связи с тем что проектировщики достаточно часто являются и пользователями, необходимо использовать их опыт работы с внутренней корпоративной CAD-системой.

6.1.4 Инженер по знаниям

Центральная роль в рамках KBE-проекта принадлежит инженеру по знаниям или менеджеру проекта. Роль инженера по знаниям должна сохраняться и предпочтительно принадлежать одному и тому же специалисту на протяжении всего жизненного цикла KBE-приложения. Он должен выполнять роль посредника, прежде всего создавая "мост" между стратегическими целями, поставленными руководством компании или администраторами базы знаний, с одной стороны, и пользователями, осуществляющими бизнес-процессы, с другой. По этой причине еще одной задачей, стоящей перед инженером по знаниям, является контроль комплексного планирования, разработки и процессов эксплуатации KBE-системы, включая проведение предварительных исследований (например, разработку технико-экономического обоснования), выбор подходящих инструментальных средств (см. 6.3.1), получение знаний, интеграцию в IT-среду компании и последующую доработку KBE-приложения. Важнейшая задача инженера познаниям - сбор экспертных знаний отдельных специалистов и ввод явных и неявных знаний экспертов и пользователей в KBE-приложение. С этой целью инженеры по знаниям, работающие над конкретной проблемой и контекстом, объединяют знания в общую сеть, формализуют, чтобы сделать знания доступными для KBE-приложений. Задача данных специалистов заключается также в мотивации сотрудников компании, выполнении функции посредника между различными группами сотрудников по интересам и устранении барьеров на пути управления знаниями (например, страхов, связанных с рационализацией производства).

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

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

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

6.2 Планирование KBE-проекта

6.2.1 Организация KBE-проекта

Целью выполнения KBE-проекта является разработка KBE-приложения. Во многих случаях конечная техническая реализация KBE-приложения - наиболее узкое место, зависящее от сложности KBE-проекта.

Тем не менее этап планирования подобных систем для их интеграции в IT-среду компании является достаточно важным и часто недооценивается при разработке систем накопления, хранения и обработки знаний (KBE-систем). Квалифицированное и эффективное внедрение KBE-приложения гарантирует его признание и дальнейшее применение в компании. В конечном счете специалисты, принимающие решения в компании, должны быть привержены идее привлечения человеческих ресурсов и финансовых средств для разработки и использования системы. Для успешной реализации KBE-проекта необходимы его всеобъемлющая поддержка со стороны руководства компании, а также объединение всех ключевых специалистов. Руководство компании должно контролировать деятельность компании в более широком контексте и тем самым не допускать параллельной разработки приложений в различных подразделениях компании или четко определять их синергетический эффект. С учетом вышеперечисленного необходимо с самого начала тщательно планировать и готовить KBЕ-проект.

Существуют различные процедуры организации KBE-проектов, в соответствии с которыми СоmmonKADS-методология представлена в настоящем стандарте для примера в качестве наиболее эффективного применения в