Использование базы знаний на предприятии

Размещено на http://www.allbest.ru/

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

Под управлением знаниями (англ. knowledge management) понимают систематические процессы, благодаря которым распознаются, создаются, сохраняются, распределяются и применяются необходимые для успеха предприятия знания [1]. Основная цель управления знаниями -- превратить знания и опыт сотрудников в интеллектуальный капитал предприятия

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

Удобство использования базы знаний на предприятии:

· «все в одном» -- все объекты бизнес-архитектуры имеют ссылочную связь и находятся в одном файле, что снижает трудоемкость одновременного использования нескольких документов (и имеет определенную аналогию с HTML-публикацией);

· с помощью простой «прокрутки» доступен листинг (длинный иерархический перечень) всех объектов соответствующего справочника системы;

· для удобства просмотра доступно «скрытие и отображение» взаимосвязанных ссылочных объектов (например, для Процессов приведены ссылки на Участников, Показатели и Документы);

· легко обнаружить «сущности» и объекты системы, нарушающие «целостность» бизнес-модели;

· по соответствующим ссылкам можно проследить логическую связь объектов бизнес-архитектуры: Цель > Показатель > Процесс > Документ (НСД) > Требования.

Для построения базы знаний строительного предприятия можно использовать систему бизнес-моделирования Business Studio, при этом экономическое представление деятельности может быть представлено объектами раздела «Управление», функциональное -- объектами раздела «Процессы», информационное и ресурсное -- объектами раздела «Объекты деятельности», организационное -- объектами раздела «Субъекты».

Модель представления знаний на основе объектов системы Business Studio можно отобразить в виде семантической сети (рис. 1).

Рис. 1. Модель представления знаний в системе Business Studio

Excel-отчет по работе строительного предприятия строится с помощью средств OLE-автоматизации и включает следующие разделы.

1.Лист «Цели» (рис. 2):

- стратегическая карта цели и соответствующего показателя;

- плановое и фактическое достижение цели в отчетном периоде;

- плановые и фактические показатели достижения цели в отчетном периоде;

- показателей для измерения достижения цели;

- наименование цели;

- имя сотрудника, ответственного за достижение цели;

- проекты, реализация которых способствует достижению цели, и процессы, улучшение которых способствует достижению цели.

Рис. 2. Лист «Цели» отчета о базе знаний

2.Лист «Показатели» (рис. 3):

- временной горизонт измерения показателя (стратегия, тактика, операции);

- интервал (период) измерения значений показателя;

- плановые значения показателя;

- фактические значения показателя;

- наименование показателя;

- регламентирующие документы;

- наименование цели, достижение которой измеряется с помощью соответствующего показателя;

- процесс, в рамках которого измеряется показатель;

- сотрудники, ответственные за показатель и контролирующие его значения;

- целевая тенденция в изменении значений показателя;

- единицы измерения показателя;

- целевое, минимальное и максимальное значения показателя.

Рис. 3. Лист «Показатели» отчета о базе знаний

Лист «Проекты» содержит следующие сведения (рис. 4):

- имя сотрудника в роли руководителя проекта;

- наименование проекта;

- регламентирующие документы;

- плановая и фактическая даты начала и завершения проекта;

- бюджет проекта;

- единицы измерения бюджета проекта.

Рис. 4. Лист «Проекты» отчета о базе знаний

4.Лист «Процессы» (рис. 5):

- тип процесса (нотация);

- уровень декомпозиции в модели деятельности;

- показатели, с помощью которых измеряется процесс;

- название процесса;

- сотрудники в роли владельца и исполнителя процесса;

- регламентирующие документы;

- результат (выход) процесса;

- комментарий к выполнению процесса.

Рис. 5. Лист «Процессы» отчета о базе знаний

6.Лист «Документы» (рис. 6):

- тип документа;

- уровень иерархии документа в структуре электронного каталога;

- наименование документа;

- процесс-предшественник (для связи на основе документа);

- процесс-последователь (для связи на основе документа);

- тип связи процессов;

- наименование файла документа.

Рис. 6. Лист «Документы» отчета о базе знаний

7.Лист «Субъекты» (рис. 7):

- тип субъекта;

- показатели сотрудника в роли владельца и исполнителя процесса;

- процессы сотрудника в роли владельца и исполнителя процесса;

- роли сотрудника и соответствующие процессы.

Рис. 7. Лист «Субъекты» отчета о базе знаний

8.Лист «События» (рис. 8):

- период возникновения события (день, неделя, месяц, год);

- наименование события;

- периодичность построения;

- временной интервал возникновения события;

- закон распределения количества событий;

- количество событий на временном интервале возникновения.

Рис. 8. Лист «События» отчета о базе знаний

Для оперативного перехода между страницами в отчете автоматически создаются соответствующие перекрестные гиперссылки.

9. В результате автоматического формирования лист «Знания» отчета будет содержать следующее (рис. 9):

- тип субъекта знаний;

- тип регламентирующего документа и соответствующие требования к компетенциям участника процесса;

- наименование должности;

- процессы, в которых участвует должность;

- роли для должности;

- показатели, которые измеряют процессы с участием должности и роли. нормативный документ база знание

Рис. 9. Лист «Знания» отчета о базе знаний

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

Рабочий поток анализа требований

Анализ требований - один из основных рабочих потоков (Workflow) программной инженерии, наряду, допустим, с такими, как проектирование интерфейса пользователя, либо программирование. Для его обозначения в англоязычной литературе, как правило, используется понятие "Requirement Process"

SWEBOK SoftWare Engineering Body Of Knowledge - свод знаний о программной инженерии (гиперссылка http://www.computer.org). Представляет собой международный стандарт, подготовленный координационным комитетом программной инженерии (Software Engineering Coordinating Committee) под эгидой АСМ и IEEE. Цель документа - определить необходимый набор знаний и рекомендуемые практики, которыми должны владеть специалисты в области программной инженерии.

SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:

· Requirements Elicitation (Извлечение требований),

· Requirements Analysis (Анализ требований в узком смысле),

· Requirements Specification (Специфицирование требований),

· Requirements Validation (Проверка требований).

В качестве примера альтернативной декомпозиции потока работ можно рассмотреть взгляд, предложенный в RUP [4.1]. RUP предлагает выделить в основном потоке анализа требований такие компоненты, как:

- Analyze the Problem (Анализ проблемы),

- Understand Stakeholder Needs (Понимание потребностей совладельцев),

- Define the System (Определение системы),

- Manage the Scope of the System (Управление контекстом системы),

- Refine the System Definition (Уточнение определения системы).

RUP (Rational Unified Process - "рациональный унифицированный процесс") - методология разработки программного обеспечения от IBM. RUP развивался десятилетиями и отражает коллективный опыт множества людей и компаний. Методология оформлена в виде базы знаний, которая в настоящее время доступна в рамках продукта IBM Rational Method Composer.

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

Хорошо проработанные требования позволяют:

- выработать общее понимание между Заказчиком и Разработчиком;

- определить рамки проекта;

- более точно определить финансовые и временные характеристики проекта;

- обезопасить Заказчика от риска получить продукт, в котором он не сможет работать;

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

Размещено на Allbest.ru